Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 2月, 2018 1 次提交
  3. 16 2月, 2018 5 次提交
    • T
      mei: set device client to the disconnected state upon suspend. · 7ae079ac
      由 Tomas Winkler 提交于 
      This fixes regression introduced by
commit 8d52af67 ("mei: speed up the power down flow")

In mei_cldev_disable during device power down flow, such as
suspend or system power off, it jumps over disconnecting function
to speed up the power down process, however, because the client is
unlinked from the file_list (mei_cl_unlink) mei_cl_set_disconnected
is not called from mei_cl_all_disconnect leaving resource leaking.
The most visible is reference counter on underlying HW module is
not decreased preventing to remove modules after suspend/resume cycles.
Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
Fixes: 8d52af67 ("mei: speed up the power down flow")
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ae079ac
    • M
      ANDROID: binder: synchronize_rcu() when using POLLFREE. · 5eeb2ca0
      由 Martijn Coenen 提交于 
      To prevent races with ep_remove_waitqueue() removing the
waitqueue at the same time.

Reported-by: syzbot+a2a3c4909716e271487e@syzkaller.appspotmail.com
Signed-off-by: NMartijn Coenen <maco@android.com>
Cc: stable <stable@vger.kernel.org> # 4.14+
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5eeb2ca0
    • T
      binder: replace "%p" with "%pK" · 8ca86f16
      由 Todd Kjos 提交于 
      The format specifier "%p" can leak kernel addresses. Use
"%pK" instead. There were 4 remaining cases in binder.c.
Signed-off-by: NTodd Kjos <tkjos@google.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ca86f16
    • T
      ANDROID: binder: remove WARN() for redundant txn error · e46a3b3b
      由 Todd Kjos 提交于 
      binder_send_failed_reply() is called when a synchronous
transaction fails. It reports an error to the thread that
is waiting for the completion. Given that the transaction
is synchronous, there should never be more than 1 error
response to that thread -- this was being asserted with
a WARN().

However, when exercising the driver with syzbot tests, cases
were observed where multiple "synchronous" requests were
sent without waiting for responses, so it is possible that
multiple errors would be reported to the thread. This testing
was conducted with panic_on_warn set which forced the crash.

This is easily reproduced by sending back-to-back
"synchronous" transactions without checking for any
response (eg, set read_size to 0):

    bwr.write_buffer = (uintptr_t)&bc1;
    bwr.write_size = sizeof(bc1);
    bwr.read_buffer = (uintptr_t)&br;
    bwr.read_size = 0;
    ioctl(fd, BINDER_WRITE_READ, &bwr);
    sleep(1);
    bwr2.write_buffer = (uintptr_t)&bc2;
    bwr2.write_size = sizeof(bc2);
    bwr2.read_buffer = (uintptr_t)&br;
    bwr2.read_size = 0;
    ioctl(fd, BINDER_WRITE_READ, &bwr2);
    sleep(1);

The first transaction is sent to the servicemanager and the reply
fails because no VMA is set up by this client. After
binder_send_failed_reply() is called, the BINDER_WORK_RETURN_ERROR
is sitting on the thread's todo list since the read_size was 0 and
the client is not waiting for a response.

The 2nd transaction is sent and the BINDER_WORK_RETURN_ERROR has not
been consumed, so the thread's reply_error.cmd is still set (normally
cleared when the BINDER_WORK_RETURN_ERROR is handled). Therefore
when the servicemanager attempts to reply to the 2nd failed
transaction, the error is already set and it triggers this warning.

This is a user error since it is not waiting for the synchronous
transaction to complete. If it ever does check, it will see an
error.

Changed the WARN() to a pr_warn().
Signed-off-by: NTodd Kjos <tkjos@android.com>
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e46a3b3b
    • E
      binder: check for binder_thread allocation failure in binder_poll() · f8898267
      由 Eric Biggers 提交于 
      If the kzalloc() in binder_get_thread() fails, binder_poll()
dereferences the resulting NULL pointer.

Fix it by returning POLLERR if the memory allocation failed.

This bug was found by syzkaller using fault injection.
Reported-by: Nsyzbot <syzkaller@googlegroups.com>
Fixes: 457b9a6f ("Staging: android: add binder driver")
Cc: stable@vger.kernel.org
Signed-off-by: NEric Biggers <ebiggers@google.com>
Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f8898267
  5. 14 2月, 2018 1 次提交
    • H
      extcon: int3496: process id-pin first so that we start with the right status · 0434352d
      由 Hans de Goede 提交于 
      Some other drivers may be waiting for our extcon to show-up, exiting their
probe methods with -EPROBE_DEFER until we show up.

These drivers will typically get the cable state directly after getting
the extcon, this commit changes the int3496 code to wait for the initial
processing of the id-pin to complete before exiting probe() with 0, which
will cause devices waiting on the defered probe to get reprobed.

This fixes a race where the initial work might still be running while other
drivers were already calling extcon_get_state().

Fixes: 2f556bdb ("extcon: int3496: Add Intel INT3496 ACPI ... driver")
Cc: stable@vger.kernel.org
Signed-off-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NChanwoo Choi <cw00.choi@samsung.com>
      0434352d
  7. 13 2月, 2018 2 次提交
  9. 12 2月, 2018 1 次提交
    • L
      vfs: do bulk POLL* -> EPOLL* replacement · a9a08845
      由 Linus Torvalds 提交于 
      This is the mindless scripted replacement of kernel use of POLL*
variables as described by Al, done by this script:

    for V in IN OUT PRI ERR RDNORM RDBAND WRNORM WRBAND HUP RDHUP NVAL MSG; do
        L=`git grep -l -w POLL$V | grep -v '^t' | grep -v /um/ | grep -v '^sa' | grep -v '/poll.h$'|grep -v '^D'`
        for f in $L; do sed -i "-es/^\([^\"]*\)\(\<POLL$V\>\)/\\1E\\2/" $f; done
    done

with de-mangling cleanups yet to come.

NOTE! On almost all architectures, the EPOLL* constants have the same
values as the POLL* constants do.  But they keyword here is "almost".
For various bad reasons they aren't the same, and epoll() doesn't
actually work quite correctly in some cases due to this on Sparc et al.

The next patch from Al will sort out the final differences, and we
should be all done.
Scripted-by: NAl Viro <viro@zeniv.linux.org.uk>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a9a08845
  11. 10 2月, 2018 10 次提交
  13. 09 2月, 2018 10 次提交
  15. 08 2月, 2018 10 次提交