Re: [PATCH v3 -next] binder: simplify the return expression of binder_mmap

Thanks! On Tue, Sep 29, 2020 at 3:30 AM Liu Shixin wrote: > > Simplify the return expression. > > Signed-off-by: Liu Shixin Acked-by: Martijn Coenen > --- > v3: Add the change description. > v2: Get rid of the "ret" and "failure string" variab

Re: LOOP_CONFIGURE ioctl doesn't work if lo_offset/lo_sizelimit are set

Hi, I just sent a patch to fix the issue. The loop device would have respected the configuration, but indeed the size of the underlying block device was not set correctly, so reading back the size would give the wrong result. Thanks, Martijn On Mon, Aug 24, 2020 at 8:24 PM Martijn Coenen wrote

Re: LOOP_CONFIGURE ioctl doesn't work if lo_offset/lo_sizelimit are set

Hi Lennart, Thanks for the report, I'll look into it. FWIW, we've been using LOOP_CONFIGURE on Android with lo_offset/lo_sizelimit without issues, but it may be a particular configuration that's causing issues. Thanks, Martijn On Mon, Aug 24, 2020 at 5:44 PM Lennart Poettering wrote: > > Hi! >

[PATCH v3] binder: print warnings when detecting oneway spamming.

-off-by: Martijn Coenen --- v2: fixed call-site in binder_alloc_selftest v3: include size of struct binder_buffer in calculation, fix comments drivers/android/binder.c| 2 +- drivers/android/binder_alloc.c | 55 +++-- drivers/android/binder_alloc.h

[PATCH v2] ANDROID: binder: print warnings when detecting oneway spamming.

-off-by: Martijn Coenen --- v2: fixed call-site in binder_alloc_selftest drivers/android/binder.c| 2 +- drivers/android/binder_alloc.c | 49 +++-- drivers/android/binder_alloc.h | 5 ++- drivers/android/binder_alloc_selftest.c | 2 +- 4

Re: [PATCH] binder: print warnings when detecting oneway spamming.

t tree, kindly drop us a note. > And when submitting patch, we suggest to use '--base' as documented in > https://git-scm.com/docs/git-format-patch] > > url: > https://github.com/0day-ci/linux/commits/Martijn-Coenen/binder-print-warnings-when-detecting-oneway-spamming

[PATCH] binder: print warnings when detecting oneway spamming.

-off-by: Martijn Coenen --- drivers/android/binder.c | 2 +- drivers/android/binder_alloc.c | 49 +++--- drivers/android/binder_alloc.h | 5 +++- 3 files changed, 51 insertions(+), 5 deletions(-) diff --git a/drivers/android/binder.c b/drivers/android/binder.c

Re: [PATCH v2] loop: unset GENHD_FL_NO_PART_SCAN on LOOP_CONFIGURE

evice with partition scanning doesn't actually work when LOOP_CONFIGURE > is issued, though it works fine with LOOP_SETSTATUS. > > Let's correct that and propagate the flag in LOOP_CONFIGURE too. > > Fixes: 3448914e8cc5("loop: Add LOOP_CONFIGURE ioctl") > >

Re: [PATCH] loop: unset GENHD_FL_NO_PART_SCAN on LOOP_CONFIGURE

On Fri, Aug 7, 2020 at 5:31 PM Lennart Poettering wrote: > Thanks for the review. I'll fix this up and send a v2. Are you OK with > me adding your Ack to the patch? Yeah, sure! > And also should this geta cc for stable? LOOP_CONFIGURE was just added in v5.8, and stable is v5.7 now, so I don't t

Re: [PATCH] loop: unset GENHD_FL_NO_PART_SCAN on LOOP_CONFIGURE

Hi Lennart, Thanks again for the patch, I tested it and it looks good to me. I'll also add a test case to LTP for this. Two minor nits on the patch: On Thu, Aug 6, 2020 at 9:32 AM Lennart Poettering wrote: > Let's correct that and propagate the flag in LOOP_SETSTATUS too. Think you meant LOOP_C

Re: [PATCH v2] binder: Prevent context manager from incrementing ref 0

Thanks a lot for the detailed explanation, I understood now. Martijn On Tue, Jul 28, 2020 at 4:50 PM Jann Horn wrote: > > On Tue, Jul 28, 2020 at 3:50 PM Martijn Coenen wrote: > > On Mon, Jul 27, 2020 at 2:04 PM Jann Horn wrote: > > > - task B opens /dev/binder once,

Re: [PATCH v2] binder: Prevent context manager from incrementing ref 0

anager to do > that. > > Additionally, print a warning if someone manages to find another way to > trigger a transaction-to-self bug in the future. > > Cc: sta...@vger.kernel.org > Fixes: 457b9a6f09f0 ("Staging: android: add binder driver") > Acked-by: Todd Kjos Rev

Re: [LTP] LTP: syscalls: regression on mainline - ioctl_loop01 mknod07 setns01

; - /* Mask out flags that can't be set using LOOP_SET_STATUS. */ > >>> - lo->lo_flags &= ~LOOP_SET_STATUS_SETTABLE_FLAGS; > >>> - /* For those flags, use the previous values instead */ > >>> - lo->lo_flags |= prev_lo_f

Re: [LTP] LTP: syscalls: regression on mainline - ioctl_loop01 mknod07 setns01

OOP_SET_STATUS_SETTABLE_FLAGS; > > - /* For flags that can't be cleared, use previous values too */ > > + /* Mask out flags that can be set using LOOP_SET_STATUS. */ > > + lo->lo_flags &= LOOP_SET_STATUS_SETTABLE_FLAGS; > > + /* For flags th

Re: LTP: syscalls: regression on mainline - ioctl_loop01 mknod07 setns01

Hi Naresh, I just sent a patch and cc'd you. I verified all the loop tests pass again with that patch. Thanks, Martijn On Thu, Jun 4, 2020 at 9:10 PM Martijn Coenen wrote: > > Hi Naresh, > > I suspect the loop failures are due to > faf1d25440d6ad06d509dada4b6fe62fea844

[PATCH] loop: Fix wrong masking of status flags

: access /sys/block/loop0/loop0p1 succeeds Summary: passed 8 failed 0 skipped 0 warnings 0 Fixes: faf1d25440d6 ("loop: Clean up LOOP_SET_STATUS lo_flags handling") Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --g

Re: LTP: syscalls: regression on mainline - ioctl_loop01 mknod07 setns01

Hi Naresh, I suspect the loop failures are due to faf1d25440d6ad06d509dada4b6fe62fea844370 ("loop: Clean up LOOP_SET_STATUS lo_flags handling"), I will investigate and get back to you. Thanks, Martijn On Thu, Jun 4, 2020 at 7:19 PM Naresh Kamboju wrote: > > + linux-bl...@vger.kernel.org > > On

Re: Writeback bug causing writeback stalls

On Mon, Jun 1, 2020 at 11:09 AM Jan Kara wrote: > Thanks for testing! My test run has completed fine so I'll submit patches > for review. But I'm curious what's causing the dips in throughput in your > test... It turned out to be unrelated to your patch. Sorry for the noise! We have the patch in

Re: Writeback bug causing writeback stalls

Hi Jan, On Fri, May 29, 2020 at 5:20 PM Jan Kara wrote: > I understand. I have written a fix (attached). Currently its under testing > together with other cleanups. If everything works fine, I plan to submit > the patches on Monday. Thanks a lot for the quick fix! I ran my usual way to reproduce

Re: Writeback bug causing writeback stalls

Hi Jan, On Mon, May 25, 2020 at 9:31 AM Jan Kara wrote: > Well, most importantly filesystems like ext4, xfs, btrfs don't hold i_rwsem > when writing back inode and that's deliberate because of performance. We > don't want to block writes (or event reads in case of XFS) for the inode > during writ

Re: Writeback bug causing writeback stalls

, 0); but there are also some that don't (eg fat, fuse, orangefs). Thanks, Martijn On Fri, May 22, 2020 at 5:36 PM Jan Kara wrote: > > On Fri 22-05-20 17:23:30, Martijn Coenen wrote: > > [ dropped android-storage-c...@google.com from CC: since that list > > can't

Re: Writeback bug causing writeback stalls

[ dropped android-storage-c...@google.com from CC: since that list can't receive emails from outside google.com - sorry about that ] Hi Jan, On Fri, May 22, 2020 at 4:41 PM Jan Kara wrote: > > The easiest way to fix this, I think, is to call requeue_inode() at the end > > of > > writeback_singl

Writeback bug causing writeback stalls

Hi, We've been working on implementing a FUSE filesystem in Android, and have run into what appears to be a bug in the kernel writeback code. The problem that we observed is that an inode in the filesystem is on the b_dirty_time list, but its i_state field does have I_DIRTY_PAGES set, which I thin

Re: [PATCH v4 10/10] loop: Add LOOP_CONFIGURE ioctl

On Wed, May 13, 2020 at 12:22 PM Christoph Hellwig wrote: > > On Wed, May 13, 2020 at 09:07:43AM +0200, Martijn Coenen wrote: > > On Wed, May 13, 2020 at 4:30 AM Jens Axboe wrote: > > > > Looks acceptable to me, but I'm getting a failure applying it to > >

[PATCH v5 01/11] loop: Call loop_config_discard() only after new config is applied

discard configuration based on the new configuration. Reviewed-by: Christoph Hellwig Reviewed-by: Bob Liu Reviewed-by: Bart Van Assche Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block

[PATCH v5 02/11] loop: Remove sector_t truncation checks

sector_t is now always u64, so we don't need to check for truncation. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 21 +++-- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index f1754262fc94..00de7fe

[PATCH v5 11/11] loop: Add LOOP_CONFIGURE ioctl

seq 30 100`; do losetup -r -o 4096 /dev/block/loop$i com.android.adbd.apex; done 0m01.94s real 0m00.01s user 0m00.01s system Reviewed-by: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 104 -- include/uapi/linux/loop.h |

[PATCH v5 10/11] loop: Clean up LOOP_SET_STATUS lo_flags handling

. The implementation can then blindly take over the passed in flags, and use the previous flags for those flags that can't be set / cleared using LOOP_SET_STATUS. Reviewed-by: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 19 +-- include/uapi/

[PATCH v5 06/11] loop: Remove figure_loop_size()

This function was now only used by loop_set_capacity(). Just open code the remaining code in the caller instead. Reviewed-by: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/block

[PATCH v5 09/11] loop: Rework lo_ioctl() __user argument casting

In preparation for a new ioctl that needs to copy_from_user(); makes the code easier to read as well. Reviewed-by: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/block/loop.c b

[PATCH v5 03/11] loop: Factor out setting loop device size

This code is used repeatedly. Reviewed-by: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 30 +- 1 file changed, 21 insertions(+), 9 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 00de7fec0ed5..e69ff3c19eff

[PATCH v5 07/11] loop: Factor out configuring loop from status

Factor out this code into a separate function, so it can be reused by other code more easily. Reviewed-by: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 117 +-- 1 file changed, 67 insertions(+), 50 deletions(-) diff --git a

[PATCH v5 04/11] loop: Switch to set_capacity_revalidate_and_notify()

This was recently added to block/genhd.c, and takes care of both updating the capacity and notifying userspace of the new size. Reviewed-by: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers

[PATCH v5 08/11] loop: Move loop_set_status_from_info() and friends up

So we can use it without forward declaration. This is a separate commit to make it easier to verify that this is just a move, without functional modifications. Reviewed-by: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 206

[PATCH v5 00/11] Add a new LOOP_CONFIGURE ioctl

-- Cleaned up some __user pointer handling in lo_ioctl -- Pass in a stack-initialized loop_info64 for the legacy LOOP_SET_FD case Martijn Coenen (11): loop: Call loop_config_discard() only after new config is applied loop: Remove sector_t truncation checks loop: Factor out sett

[PATCH v5 05/11] loop: Refactor loop_set_status() size calculation

: Christoph Hellwig Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 37 +++-- 1 file changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index d9a756f8abd5..c134b3439483 100644 --- a/drivers/block/loop.c +++ b

Re: [PATCH v4 10/10] loop: Add LOOP_CONFIGURE ioctl

On Wed, May 13, 2020 at 4:30 AM Jens Axboe wrote: > > Looks acceptable to me, but I'm getting a failure applying it to > > for-5.8/drivers on this patch: > > > > Applying: loop: Refactor loop_set_status() size calculation > > > > So you'll probably want to respin on the right branch. This series

Re: [PATCH v4 10/10] loop: Add LOOP_CONFIGURE ioctl

Hi Jens, What do you think of this series? Thanks, Martijn On Wed, Apr 29, 2020 at 4:03 PM Martijn Coenen wrote: > > This allows userspace to completely setup a loop device with a single > ioctl, removing the in-between state where the device can be partially > configured - eg the

Re: [PATCH v4 10/10] loop: Add LOOP_CONFIGURE ioctl

On Wed, May 6, 2020 at 11:44 AM Michael Kerrisk (man-pages) > > Can we have also a patch for the loop.4 manual page please? Ack, will do when the series lands. Best, Martijn > > Thanks, > > Michael > > > -- > Michael Kerrisk > Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ > Li

Re: [PATCH v4 10/10] loop: Add LOOP_CONFIGURE ioctl

On Wed, May 6, 2020 at 8:09 AM Christoph Hellwig wrote: > > Thanks, this looks very nice! Thanks! And thanks for all the feedback, it has made this series a lot cleaner. > > Reviewed-by: Christoph Hellwig > > Are you also going to submit a patch to util-linux to use the new > ioctl? Yeah, I'm

Re: [PATCH] loop: Call loop_config_discard() only after new config is applied.

Hi Jens, Are you ok with this one? One of my later series depends on it, but so far I've kept it separate because it's a bug fix. Thanks, Martijn On Sat, Apr 18, 2020 at 5:46 PM Bart Van Assche wrote: > > On 2020-03-31 04:41, Martijn Coenen wrote: > > l

Re: [PATCH v4 04/10] loop: Refactor loop_set_status() size calculation

On Fri, May 1, 2020 at 7:30 PM Christoph Hellwig wrote: > > For some reason this fails to apply for me against both > Jens' for-5.8/block and Linus' current tree. > > What is the baseline for this series? This was based on Linus' tree from a week or two ago or so, but I think you're most likely m

Re: [PATCH v4 01/10] loop: Factor out loop size validation

Hi Ming, On Wed, Apr 29, 2020 at 4:12 PM Ming Lei wrote: > Now sector_t has been switched to u64 unconditionally, do we still need such > validation? I think you're right; I hadn't seen that change, but truncating because of sector_t shouldn't be an issue anymore. I wondered if we could actually

Re: [PATCH v3 0/9] Add a new LOOP_SET_FD_AND_STATUS ioctl

On Tue, Apr 28, 2020 at 4:57 PM Martijn Coenen wrote: > and it allows requesting a partition scan. It makes sense to maintain > that behavior, but what about LO_FLAGS_DIRECT_IO? I think you're > proposing LOOP_SET_STATUS(64) should keep ignoring that like it used > to? I'v

[PATCH v4 01/10] loop: Factor out loop size validation

Ensuring we don't truncate loff_t when casting to sector_t is done in multiple places; factor it out. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 25 - 1 file changed, 20 insertions(+), 5 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/l

[PATCH v4 06/10] loop: Factor out configuring loop from status

Factor out this code into a separate function, so it can be reused by other code more easily. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 117 +-- 1 file changed, 67 insertions(+), 50 deletions(-) diff --git a/drivers/block/loop.c b/drivers

[PATCH v4 02/10] loop: Factor out setting loop device size

This code is used repeatedly. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 31 ++- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 396b8bd4d75c..6643e48ad71c 100644 --- a/drivers/block

[PATCH v4 05/10] loop: Remove figure_loop_size()

This function was now only used by loop_set_capacity(). Just open code the remaining code in the caller instead. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 28 1 file changed, 12 insertions(+), 16 deletions(-) diff --git a/drivers/block/loop.c b

[PATCH v4 09/10] loop: Clean up LOOP_SET_STATUS lo_flags handling.

. The implementation can then blindly take over the passed in flags, and use the previous flags for those flags that can't be set / cleared using LOOP_SET_STATUS. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 19 +-- include/uapi/linux/loop.h | 10 -- 2

[PATCH v4 08/10] loop: Rework lo_ioctl() __user argument casting

In preparation for a new ioctl that needs to copy_from_user(); makes the code easier to read as well. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index

[PATCH v4 10/10] loop: Add LOOP_CONFIGURE ioctl

seq 30 100`; do losetup -r -o 4096 /dev/block/loop$i com.android.adbd.apex; done 0m01.94s real 0m00.01s user 0m00.01s system Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 107 +++--- include/uapi/linux/loop.h | 21 2 files changed

[PATCH v4 07/10] loop: Move loop_set_status_from_info() and friends up

So we can use it without forward declaration. This is a separate commit to make it easier to verify that this is just a move, without functional modifications. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 206 +-- 1 file changed, 103

[PATCH v4 00/10] Add a new LOOP_CONFIGURE ioctl

us -- Cleaned up some __user pointer handling in lo_ioctl -- Pass in a stack-initialized loop_info64 for the legacy LOOP_SET_FD case Martijn Coenen (10): loop: Factor out loop size validation loop: Factor out setting loop device size loop: Switch to set_capacity_revalidate

[PATCH v4 04/10] loop: Refactor loop_set_status() size calculation

: Martijn Coenen --- drivers/block/loop.c | 44 +++- 1 file changed, 23 insertions(+), 21 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block/loop.c index 8f3194c2b8aa..9f5913879921 100644 --- a/drivers/block/loop.c +++ b/drivers/block/loop.c

[PATCH v4 03/10] loop: Switch to set_capacity_revalidate_and_notify()

This was recently added to block/genhd.c, and takes care of both updating the capacity and notifying userspace of the new size. Signed-off-by: Martijn Coenen --- drivers/block/loop.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/block/loop.c b/drivers/block

Re: [PATCH v3 0/9] Add a new LOOP_SET_FD_AND_STATUS ioctl

On Tue, Apr 28, 2020 at 9:02 AM Christoph Hellwig wrote: > I think reusing LO_FLAGS_DIRECT_IO makes sense to me - we have 32 > flags in the existing flags field (at least for loop_info64), so > we might as well use the field and the flags. Then we need flags > validation in that we don't accept n

Re: [PATCH 4.9 30/47] ANDROID: binder: remove waitqueue when thread exits.

On Sun, Oct 6, 2019 at 7:23 PM Greg Kroah-Hartman wrote: > > From: Martijn Coenen > > commit f5cb779ba16334b45ba8946d6bfa6d9834d1527f upstream. > > binder_poll() passes the thread->wait waitqueue that > can be slept on for work. When a thread that uses > e

Re: [PATCH 4.9 30/47] ANDROID: binder: remove waitqueue when thread exits.

On Mon, Oct 7, 2019 at 8:28 AM Mattias Nissler wrote: > Jann's PoC calls the BINDER_THREAD_EXIT ioctl to free the > binder_thread which will then cause the UAF, and this is cut off by > the patch. IIUC, you are worried about a similar AUF on the proc->wait > access. I am not 100% sure, but I think

[PATCH] binder: Set end of SG buffer area properly.

: ec74136ded79 ("binder: create node flag to request sender's security context") Signed-off-by: Martijn Coenen Cc: sta...@vger.kernel.org # 5.1+ --- drivers/android/binder.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/android/binder.c b/drivers/android

Re: [PATCH] MAINTAINERS: update Android binder

Thanks Christian for signing up! On Thu, Dec 20, 2018 at 12:09 PM Greg KH wrote: > Ok, no objection from me, Todd/Martijn/Joel/Arve, can I get an ack from > someone? Acked-By: Martijn Coenen > > thanks, > > greg k-h

[PATCH v2] ANDROID: binder: Add BINDER_GET_NODE_INFO_FOR_REF ioctl.

information can then be passed on to the process holding the node, which can in turn decide whether it wants to shut down to reduce resource usage. Signed-off-by: Martijn Coenen --- v2: made sure reserved fields are aligned, and enforce caller zeroes all fields except handle, as suggested by Dan

Re: [PATCH] ANDROID: binder: Add BINDER_GET_NODE_INFO_FOR_REF ioctl.

On Wed, Sep 5, 2018 at 11:09 AM, Dan Carpenter wrote: > What's the reserved for? On 64 bit systems there is a 4 byte struct > hole between weak_count and reserved. There's many more pieces of information that we hold for a node. While we don't have a use for most of that now, we may want some of

[PATCH] ANDROID: binder: Add BINDER_GET_NODE_INFO_FOR_REF ioctl.

information can then be passed on to the process holding the node, which can in turn decide whether it wants to shut down to reduce resource usage. Signed-off-by: Martijn Coenen --- drivers/android/binder.c| 50 + include/uapi/linux/android/binder.h | 8

Re: KASAN: null-ptr-deref Write in binder_update_page_range

Thanks Minchan! On Thu, Aug 23, 2018 at 7:29 AM, Minchan Kim wrote: > Signed-off-by: Todd Kjos > Signed-off-by: Minchan Kim Reviewed-by: Martijn Coenen > --- > drivers/android/binder_alloc.c | 43 +++--- > 1 file changed, 35 insertions(+), 8 deleti

Re: [PATCH] android: binder: no outgoing transaction when thread todo has transaction

threads that are waiting for proc work can directly > receive work from another thread, and no work is allowed to be queued > on such a thread without waking up the thread. This patch also enforces > that a thread is not waiting for proc work when a work is directly > enqueued to its to

Re: [PATCH 1/4] file: export __alloc_fd()

On Tue, Jul 31, 2018 at 12:07 PM, Christian Brauner wrote: > Ah, this wasn't brought up in the original thread when discussing to > turn this into a module. If using internal functions like this is going > away it makes sense to wait for this work to happen first. Is there a > time-frame for this?

Re: [PATCH 1/4] file: export __alloc_fd()

On Mon, Jul 30, 2018 at 10:36 PM, Matthew Wilcox wrote: > I'm not entirely sure I understand the binder code (... does anyone?) > but from what I can see, it intends to open a file descriptor in the > process which is the target of the message being sent. You're right. > That strikes > me as wro

Re: [PATCH 2/6] module: add support for symbol namespaces.

>> >> Jessica >> >> > >> >> >> >> On x86_64 I saw no difference in binary size (compression), but at >> >> runtime this will require a word of memory per export to hold the >> >> namespace. An alternative could be to store n

Re: drivers/android/.tmp_gl_binder.o:undefined reference to `__user_bad'

Hi Michal, See below - this error was introduced because the binder driver uses a 64-bit get_user(), even on a 32-bit architecture. Would it be possible to implement a 64-bit get_user() for microblaze? Thanks, Martijn On Mon, Jul 2, 2018 at 6:53 AM kbuild test robot wrote: > > Hi Martijn, > > F

Re: [PATCH 2/2 v2] staging: android: ashmem: Fix mmap size validation

hmem as well. Since its size is fixed after creation, preventing anyone from mapping a larger size seems reasonable to me. Reviewed-by: Martijn Coenen > > thanks! > > - Joel >

Re: [PATCH v6] ANDROID: binder: change down_write to down_read

gt; > > >> > > > > > Ganesh Mahendran tested app launching and binder throughput test >> > > > > > and he said he couldn't find any problem and I did binder latency >> > > > > > test per Greg KH request(Thanks Martijn to teach me how I can do) >>

Re: [PATCH] m68k/uaccess: Revive 64-bit get_user()

warning otherwise. Can't vouch for the existing asm, but the changes to it look good to me otherwise. > > Signed-off-by: Geert Uytterhoeven Acked-by: Martijn Coenen > --- > arch/m68k/include/asm/uaccess_mm.h | 16 +--- > 1 file changed, 9 insertions(+), 7 delet

Re: [PATCH] ANDROID: binder: remove 32-bit binder interface.

On Mon, May 14, 2018 at 4:00 PM, Geert Uytterhoeven wrote: > Patch sent. Thanks for the quick turn-around! > > BTW, sh also doesn't seem to have 64-bit get_user(). > There may be others. I checked quickly, nios2 is the only other arch that explicitly doesn't support it and would result in a bui

[PATCH v2] ANDROID: binder: remove 32-bit binder interface.

From: Martijn Coenen New devices launching with Android P need to use the 64-bit binder interface, even on 32-bit SoCs [0]. This change removes the Kconfig option to select the 32-bit binder interface. We don't think this will affect existing userspace for the following reasons: 1) The l

Re: [PATCH] ANDROID: binder: remove 32-bit binder interface.

On Fri, May 11, 2018 at 10:08 AM, Greg KH wrote: > I think using !CONFIG_M68K is a good start. We can blacklist any other > arch that doesn't support this, and that list should be small as I doubt > any new ones will be added without this support. Thanks, I will send a v2. > > thanks, > > greg

Re: [PATCH] ANDROID: binder: remove 32-bit binder interface.

On Sat, May 5, 2018 at 2:10 PM, kbuild test robot wrote: >drivers/android/binder.o: In function `binder_thread_write': >>> binder.c:(.text+0x6a16): undefined reference to `__get_user_bad' Looks like m68k doesn't support 64-bit get_user(). I could just have binder depend on !CONFIG_M68K, but t

Re: [PATCH] android: binder: Fix a possible data race in binder_alloc_mmap_handler

On Tue, May 8, 2018 at 2:06 AM, Jia-Ju Bai wrote: > The write operations to "alloc->buffer" are protected by > the lock on line 679 and 730, but the read operation to > this data on line 712 is not protected by the lock. > Thus, there may exist a data race for "alloc->buffer". It's read by the sa

[PATCH] ANDROID: binder: remove 32-bit binder interface.

tains 32-bit support for devices that are upgrading. This will be removed as well in 2-3 years, at which point we can remove the code from the UAPI as well. [0]: https://android-review.googlesource.com/c/platform/build/+/595193 Signed-off-by: Martijn Coenen --- drivers/android/Kconfig | 13 ---

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

On Wed, Apr 25, 2018 at 10:55 AM, Luis R. Rodriguez wrote: > Android became the primary user of CONFIG_FW_LOADER_USER_HELPER_FALLBACK. > > It would be good for us to hear from Android folks if their current use of > request_firmware_into_buf() is designed in practice to *never* use the direct > fi

Re: [PATCH v3 2/5] efi: Add embedded peripheral firmware support

On Thu, May 3, 2018 at 5:21 PM, Luis R. Rodriguez wrote: > Android folks, poke below. otherwise we'll have no option but to seriously > consider Mimi's patch to prevent these calls when IMA appraisal is enforced: Sorry, figuring out who's the right person to answer this, will get back to you ASAP

Re: [PATCH] ANDROID: binder: fix binder work return error is wrongly consumed

On Wed, May 2, 2018 at 7:30 AM, wrote: > But there is potential risks in the future, future functional extensions > need to consider nesting issues, maybe extending more methods where we > push to thread->todo. I think that using queueing return error transaction > to the head of thread todo list

Re: INFO: task hung in fsnotify_mark_destroy_workfn

On Wed, Apr 18, 2018 at 11:36 AM, Jan Kara wrote: > OK, so we are waiting for the grace period on fsnotify_mark_srcu. Seems > like someone is holding fsnotify_mark_srcu too long or srcu period cannot > finish for some other reason. However the reproducer basically contains > only one binder ioctl

Re: KASAN: use-after-free Read in binder_release_work

On Mon, Apr 23, 2018 at 12:17 PM, Dmitry Vyukov wrote: > syzbot does not extract this info from patch emails. Ok so IIUC, Reported-By tags will only be considered when they are actually part of commits in one of the tested trees - makes sense. So does sending "#syz fix: xyz" cause syzbot to look

Re: KASAN: use-after-free Read in binder_release_work

On Mon, Apr 23, 2018 at 11:49 AM, Dmitry Vyukov wrote: > Since it's already in Greg's queue, it's not worth bothering. We can > fix up things here with these "#syz fix" tags in emails, which > associate fixes with bugs. I meant, when I sent the original patch a month or so ago, could syzbot have

Re: KASAN: use-after-free Read in binder_release_work

On Mon, Apr 23, 2018 at 11:28 AM, Dmitry Vyukov wrote: > https://syzkaller.appspot.com/bug?extid=09e05aba06723a94d43d > and that happened in binder. But then syzkaller found a reproducer for > it, but it turned out to be in rdma subsystem. It's generally not > possible to properly distinguish diff

Re: KASAN: use-after-free Read in binder_release_work

On Thu, Apr 19, 2018 at 11:35 PM, Eric Biggers wrote: > Martijn, this is going to be fixed by > https://patchwork.kernel.org/patch/10312345/ > ("ANDROID: binder: prevent transactions into own process"), right? > The syzbot bug ID in that patch is for a bug that is already closed, > so if it's not

Re: [PATCH v2] ANDROID: binder: prevent transactions into own process.

On Wed, Mar 28, 2018 at 1:34 PM, Martijn Coenen wrote: > On Wed, Mar 28, 2018 at 1:28 PM, Greg KH wrote: >> What is different from "v2" you sent before this? No change information >> from v1? Greg, is this in your queue, or should I just send a v3 to clean this up?

Re: [PATCH] ANDROID: binder: prevent transactions into own process.

On Wed, Mar 28, 2018 at 1:29 PM, Greg KH wrote: > I can mark it for stable, and then when you get the "this did not apply > to this tree" email, you can send a backported patch to me so I know to > take that one then. Ack, thanks. > > thanks, > > greg k-h

Re: [PATCH v2] ANDROID: binder: prevent transactions into own process.

On Wed, Mar 28, 2018 at 1:28 PM, Greg KH wrote: > What is different from "v2" you sent before this? No change information > from v1? Sorry I messed this up - the first resend did not have "v2" in the subject but did contain v2 change information, the second resend had the v2 subject and did not

[PATCH v2] ANDROID: binder: prevent transactions into own process.

a06723a94d...@syzkaller.appspotmail.com Signed-off-by: Martijn Coenen --- drivers/android/binder.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index 764b63a5aade..e578eee31589 100644 --- a/drivers/android/binder.c +++ b/drivers/androi

[v2] ANDROID: binder: prevent transactions into own process.

a06723a94d...@syzkaller.appspotmail.com Signed-off-by: Martijn Coenen --- Changed in v2: - Use target_proc directly to avoid dereference. drivers/android/binder.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index 764b63a5aade..e5

Re: [PATCH] ANDROID: binder: prevent transactions into own process.

On Wed, Mar 28, 2018 at 10:19 AM, Greg KH wrote: > Does this need to go to older kernels as well? Yes, this should apply cleanly to 4.14 as well. It won't apply to pre-4.14 kernels because of the fine-grained locking changes, but the same issue exists there and I suspect it would cause the same c

[PATCH] ANDROID: binder: prevent transactions into own process.

a06723a94d...@syzkaller.appspotmail.com Signed-off-by: Martijn Coenen --- drivers/android/binder.c | 8 1 file changed, 8 insertions(+) diff --git a/drivers/android/binder.c b/drivers/android/binder.c index e7e4560e4c6e..57d4ba926ed0 100644 --- a/drivers/android/binder.c +++ b/drivers/androi

Re: [PATCH] ANDROID: binder: change down_write to down_read

me which is > already hold a mmap_sem as down_write so binder_update_page_range > doesn't need to hold a mmap_sem as down_write. > > Android suffers from mmap_sem contention so let's reduce mmap_sem > down_write. > > Cc: Martijn Coenen > Cc: Todd Kjos > Cc: Greg Kroa

Re: KASAN: use-after-free Read in __list_del_entry_valid (3)

On Tue, Mar 6, 2018 at 9:30 AM, syzbot wrote: > Hello, > > syzbot hit the following crash on upstream commit > 094b58e1040a44f991d7ab628035e69c4d6b79c9 (Mon Mar 5 19:57:06 2018 +) > Merge tag 'linux-kselftest-4.16-rc5' of > git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest I

Re: [PATCH] ANDROID: binder: synchronize_rcu() when using POLLFREE.

Greg, This is for 4.14 LTS and 4.16. Thanks, Martijn On Fri, Feb 16, 2018 at 9:47 AM, Martijn Coenen wrote: > To prevent races with ep_remove_waitqueue() removing the > waitqueue at the same time. > > Reported-by: syzbot+a2a3c4909716e2714...@syzkaller.appspotmail.com > Signed-

[PATCH] ANDROID: binder: synchronize_rcu() when using POLLFREE.

To prevent races with ep_remove_waitqueue() removing the waitqueue at the same time. Reported-by: syzbot+a2a3c4909716e2714...@syzkaller.appspotmail.com Signed-off-by: Martijn Coenen --- drivers/android/binder.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/android

Re: KASAN: use-after-free Read in remove_wait_queue

On Mon, Feb 12, 2018 at 7:31 PM, Al Viro wrote: > Any chance of bisecting it? Perhaps my fix introduced another (related) problem, I'm looking into it.

Re: [PATCH v3] android: binder: use VM_ALLOC to get vm area

On Mon, Jan 22, 2018 at 4:54 PM, Greg KH wrote: > Martijn and Todd, any objections to this patch? Looks good to me. > > thanks, > > greg k-h

Re: [PATCH] ANDROID: binder: remove waitqueue when thread exits.

On Fri, Jan 5, 2018 at 1:20 PM, Greg KH wrote: > Should this be a 4.15-final thing, as well as backported to any range of > older kernels? This was found by syzkaller and wouldn't be hit in normal code paths, so I think it's not critical for 4.15. This code was introduced in 4.14, so it should be

  1   2   >