ers and are
merged in Android's common kernel trees.
Martijn Coenen (6):
ANDROID: binder: add support for RT prio inheritance.
ANDROID: binder: add min sched_policy to node.
ANDROID: binder: improve priority inheritance.
ANDROID: binder: add RT inheritance flag to node.
ANDROID: binder:
tting T1 change the priority
of T2 *before* waking it up.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 217 ---
1 file changed, 188 insertions(+), 29 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
ind
This allows to easily trace and visualize priority inheritance
in the binder driver.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 4
drivers/android/binder_trace.h | 24
2 files changed, 28 insertions(+)
diff --git a/drivers/android/binder.c
apply CAP_SYS_NICE or RLIMIT_RT_PRIO,
for now it seems reasonable to not check permissions
on the restore path.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/android/binder.c b/dr
Allows a binder node to specify whether it wants to
inherit real-time scheduling policy from a caller. This
inheritance may not always be desirable, for example in
cases where the binder call runs untrusted and therefore
potentially unbounded code.
Signed-off-by: Martijn Coenen
---
drivers
]
for the SCHED_NORMAL/SCHED_BATCH policies.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c| 28 +
include/uapi/linux/android/binder.h | 41 -
2 files changed, 60 insertions(+), 9 deletions(-)
diff --git a/drivers
By raising the priority of a thread selected for
a transaction *before* we wake it up.
Delay restoring the priority when doing a reply
until after we wake-up the process receiving
the reply.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 74
If a call to put_user() fails, we failed to
properly free a transaction and send a failed
reply (if necessary).
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 40 +++-
1 file changed, 31 insertions(+), 9 deletions(-)
diff --git a/drivers
Show the high watermark of the index into the alloc->pages
array, to facilitate sizing the buffer on a per-process
basis.
Signed-off-by: Martijn Coenen
---
drivers/android/binder_alloc.c | 4
drivers/android/binder_alloc.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/driv
On Mon, Nov 13, 2017 at 10:49 AM, Greg KH wrote:
> Is this relevant for 4.14 and any older kernels as well?
The problem was introduced with fine-grained locking, which is 4.14 and up only.
Thanks,
Martijn
On Mon, Nov 13, 2017 at 10:49 AM, Greg KH wrote:
> Who can use this? A userspace tool? Or something else?
The output is part of Android bugreports, it's not parsed
automatically but the information is very useful even to manually look
at. Since Treble, we have more processes using binder, and s
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
>
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
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
>>
>> 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
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
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?
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
oll cleanup
code tries to access the waitlist, which results in
a use-after-free.
Prevent this by using POLLFREE when the thread exits.
Signed-off-by: Martijn Coenen
Reported-by: syzbot
---
drivers/android/binder.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/android/binde
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
>>
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")
>
>
-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
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
-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
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
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
limit should already be updated while we're trying to reclaim memory
from that cgroup, since it's that exact reclaim which could be causing
pressure on the cgroup.
Signed-off-by: Martijn Coenen
---
include/linux/vmpressure.h | 36 +++--
mm/memcontrol.c|
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
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
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
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
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
: 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
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
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
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
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
.
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
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
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
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
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
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
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
: 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
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
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
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
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?
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
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
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
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
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
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
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
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
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 ---
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
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
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
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
Move the context manager state into a separate
struct context, and allow for each process to have
its own context associated with it.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 61 +++-
1 file changed, 40 insertions(+), 21 deletions
From: Arve Hjønnevåg
Prevent using a binder_ref with only weak references where a strong
reference is required.
Signed-off-by: Arve Hjønnevåg
---
drivers/android/binder.c | 30 +-
1 file changed, 21 insertions(+), 9 deletions(-)
diff --git a/drivers/android/binder.
ER_DEVICES can
be used to set the default value of the parameter.
This approach was favored over using IPC namespaces,
mostly because we require a single process to be a
part of multiple binder contexts, which seemed harder
to achieve with namespaces.
Signed-off-by: Martijn Coenen
---
drive
-off-by: Martijn Coenen
---
drivers/android/binder.c | 41 -
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index f2a0ae6..18a3254 100644
--- a/drivers/android/binder.c
+++ b/drivers/android
: Martijn Coenen
---
drivers/android/binder.c| 244 ++--
include/uapi/linux/android/binder.h | 44 +++
2 files changed, 275 insertions(+), 13 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 18a3254..76dda7b 100644
--- a
Moved handling of fixup for binder objects,
handles and file descriptors into separate
functions.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 309 ++-
1 file changed, 172 insertions(+), 137 deletions(-)
diff --git a/drivers/android
hat code.
Arve Hjønnevåg (2):
ANDROID: binder: Add strong ref checks
ANDROID: binder: Clear binder and cookie when setting handle in flat
binder struct
Martijn Coenen (8):
android: binder: split flat_binder_object.
android: binder: support multiple context managers.
android: binder: dea
ining backwards compatibility to
existing user-space clients. All binder objects
just share a header.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c| 158 +---
include/uapi/linux/android/binder.h | 31 ++-
2 files changed, 137 inser
Properly print the context in debugfs entries.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c | 36 +++-
1 file changed, 23 insertions(+), 13 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 3358156..ed4e432 100644
From: Arve Hjønnevåg
Prevents leaking pointers between processes
Signed-off-by: Arve Hjønnevåg
---
drivers/android/binder.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index 3681759..3c71b98 100644
--- a/drivers/android/binder.c
This patch introduces a new binder_fd_array object,
that allows us to support one or more file descriptors
embedded in a buffer that is scatter-gathered.
Signed-off-by: Martijn Coenen
---
drivers/android/binder.c| 141
include/uapi/linux/android
On Mon, Oct 24, 2016 at 3:20 PM, Martijn Coenen wrote:
> From: Arve Hjønnevåg
>
> Prevents leaking pointers between processes
>
> Signed-off-by: Arve Hjønnevåg
Signed-off-by: Martijn Coenen
> ---
> drivers/android/binder.c | 5 +
> 1 file changed, 5 insert
On Mon, Oct 24, 2016 at 3:20 PM, Martijn Coenen wrote:
> From: Arve Hjønnevåg
>
> Prevent using a binder_ref with only weak references where a strong
> reference is required.
>
> Signed-off-by: Arve Hjønnevåg
Signed-off-by: Martijn Coenen
> ---
> drive
On Thu, Feb 23, 2017 at 9:24 PM, John Stultz wrote:
>
> So, just for context, Android does have a userland LMK daemon (using
> the mempressure notifiers) as you mentioned, but unfortunately I'm
> unaware of any devices that ship with that implementation.
I've previously worked on enabling userspa
ed in receiving notifications
for every 2MB scanned.
This patch makes vmpressure_window a sysctl tunable.
Signed-off-by: Martijn Coenen
---
Documentation/sysctl/vm.txt | 15 +++
include/linux/vmpressure.h | 1 +
kernel/sysctl.c | 11 +++
mm/vmpressure.c | 5
On Wed, Feb 3, 2016 at 5:19 PM, Johannes Weiner wrote:
>
> If the machine is just cleaning up use-once cache, frequent events
> make no sense. And if the machine is struggling, the notifications
> better be in time.
>
> That's hardly a tunable. It's a factor that needs constant dynamic
> adjustmen
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
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
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
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
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
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
: 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
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
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
1 - 100 of 186 matches
Mail list logo
