On Mon, Sep 28, 2020 at 01:34:31PM -0700, Kees Cook wrote:
> On Sun, Sep 27, 2020 at 07:35:26PM -0400, Joel Fernandes wrote:
> > On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote:
> > > This patch series is a result of discussion at the refcount_t BOF
> > > th
version doesn't change the overflow wrap around behavior.
>
> Signed-off-by: Shuah Khan
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> ---
> drivers/android/binder.c | 41 ---
> drivers/android/binder_internal.h | 3 ++-
>
On Fri, Sep 25, 2020 at 05:47:14PM -0600, Shuah Khan wrote:
> This patch series is a result of discussion at the refcount_t BOF
> the Linux Plumbers Conference. In this discussion, we identified
> a need for looking closely and investigating atomic_t usages in
> the kernel when it is used strictly
27;s not used, and is only causing problems
> > > > for everyone involved.
> > > >
> > > > Cc: "Arve Hjønnevåg"
> > > > Cc: "Christian König"
> > > > Cc: Christian Brauner
> > > > Cc: Ch
ed memory. Therefore the race
> that lockdep is warning about is not valid. Resolve this by introducing a
> separate lockdep class for the backing shmem inodes.
>
> [1]: https://lkml.kernel.org/lkml/0b5f9d059aa20...@google.com/
>
> Signed-off-by: Suren Baghda
nr_to_scan is the number of pages to be freed however ashmem doesn't
discount nr_to_scan correctly as it frees ranges. It should be
discounting them by pages than by ranges. Correct the issue.
Cc: sur...@google.com
Signed-off-by: Joel Fernandes (Google)
---
drivers/staging/android/ashmem.
.
>
> Cc: Greg Kroah-Hartman
> Cc: Joel Fernandes
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> Cc: Greg Hartman
> Cc: kernel-t...@android.com
> Cc: de...@driverdev.osuosl.org
> Signed-off-by: Alistair Delva
> ---
> drivers/staging/android/Kcon
map is done on the ashmem
> region, then the permission checks will be skipped. Fix that by disallowing
> mapping operation on the backing shmem file.
Reviewed-by: Joel Fernandes (Google)
thanks!
- Joel
>
> Reported-by: Jann Horn
> Signed-off-by: Suren Baghdasaryan
> Cc: stab
On Wed, Oct 09, 2019 at 05:10:45PM +0200, Christian Brauner wrote:
> On Wed, Oct 09, 2019 at 10:55:58AM -0400, Joel Fernandes wrote:
> > On Wed, Oct 09, 2019 at 04:29:11PM +0200, Christian Brauner wrote:
> > > On Wed, Oct 09, 2019 at 10:21:29AM -0400, Joel Fernandes wrote:
>
On Wed, Oct 09, 2019 at 04:29:11PM +0200, Christian Brauner wrote:
> On Wed, Oct 09, 2019 at 10:21:29AM -0400, Joel Fernandes wrote:
> > On Wed, Oct 09, 2019 at 12:40:12PM +0200, Christian Brauner wrote:
> > > On Tue, Oct 08, 2019 at 02:05:16PM -0400, Joel Fernandes wrote:
>
On Wed, Oct 09, 2019 at 12:40:12PM +0200, Christian Brauner wrote:
> On Tue, Oct 08, 2019 at 02:05:16PM -0400, Joel Fernandes wrote:
> > On Tue, Oct 08, 2019 at 03:01:59PM +0200, Christian Brauner wrote:
> > > When a binder transaction is initiated on a binder device coming fro
copying
> the name of the binder device instead of stashing a pointer to it.
>
> Reported-by: Jann Horn
> Fixes: 03e2e07e3814 ("binder: Make transaction_log available in binderfs")
> Link:
> https://lore.kernel.org/r/cag48ez14q0-f8lqsvcnbyr2o6gpw8shxsm4u5jmd9mpstem...@mail
binder_alloc_buffer_lookup() doesn't exist and is named
"binder_alloc_prepare_to_free()". Correct the code comments to reflect
this.
Signed-off-by: Joel Fernandes (Google)
---
drivers/android/binder_alloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/
On September 4, 2019 7:19:35 AM EDT, Christian Brauner
wrote:
>On Tue, Sep 03, 2019 at 09:16:51AM -0700, Hridya Valsaraju wrote:
>> Currently, the only way to access binder state and
>> statistics is through debugfs. We need a way to
>> access the same even when debugfs is not mounted.
>> These pa
On Thu, Aug 29, 2019 at 08:42:29AM +0200, Greg KH wrote:
> On Thu, Aug 29, 2019 at 01:49:53PM +0800, Peikan Tsai wrote:
[snip]
> > The allocated size for each binder_thread is 512 bytes by kzalloc.
> > Because the size of binder_thread is fixed and it's only 304 bytes.
> > It will save 208 bytes p
kmem_cache
> for the binder_thread.
Awesome change and observation!!!
Reviewed-by: Joel Fernandes (Google)
(Another thought: how did you discover this? Are you using some tools to look
into slab fragmentation?).
thanks,
- Joel
> Signed-off-by: Peikan Tsai
> ---
> drivers/android/bin
inderfs instance instead of global devices
> being created by the binder driver.
>
> Co-developed-by: Christian Brauner
> Signed-off-by: Christian Brauner
> Signed-off-by: Hridya Valsaraju
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> ---
>
> Changes in v2:
&
inderfs instance instead of global devices
> being created by the binder driver.
>
> Co-developed-by: Christian Brauner
> Signed-off-by: Christian Brauner
> Signed-off-by: Hridya Valsaraju
> ---
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
>
> Changes in v2:
&
nce.
>
> Co-developed-by: Christian Brauner
> Signed-off-by: Christian Brauner
> Signed-off-by: Hridya Valsaraju
> ---
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> drivers/android/binderfs.c | 12
> 1 file changed, 12 insertions(+)
>
> diff --git
On Wed, Jul 24, 2019 at 4:24 PM John Stultz wrote:
>
> On Wed, Jul 24, 2019 at 1:18 PM John Stultz wrote:
> >
> > On Wed, Jul 24, 2019 at 12:36 PM Laura Abbott wrote:
> > >
> > > On 7/17/19 12:31 PM, Alexander Popov wrote:
> > > > Hello!
> > > >
> > > > The syzkaller [1] has a trouble with fuzzi
L, Tim
> Murray, Michal Hocko, Suren Baghdasaryan, linux-mm, Arve Hjønnevåg,
> Ingo Molnar, Steven Rostedt, Oleg Nesterov, Joel Fernandes, Andy
> Lutomirski, kernel-team
>
> > On Tue, May 07, 2019 at 01:12:36AM -0700, Sultan Alsawaf wrote:
> > > On Tue, May 07, 2019 at
On Wed, Mar 20, 2019 at 07:51:57PM +0100, Christian Brauner wrote:
[snip]
> > > translate_pid() should just return you a pidfd. Having it return a pidfd
> > > and a status fd feels like stuffing too much functionality in there. If
> > > you're fine with it I'll finish prototyping what I had in mind
On Wed, Mar 20, 2019 at 07:26:50PM +0100, Christian Brauner wrote:
> On Wed, Mar 20, 2019 at 07:33:51AM -0400, Joel Fernandes wrote:
> >
> >
> > On March 20, 2019 3:02:32 AM EDT, Daniel Colascione
> > wrote:
> > >On Tue, Mar 19, 2019 at 8:59 PM Christian B
On March 20, 2019 3:02:32 AM EDT, Daniel Colascione wrote:
>On Tue, Mar 19, 2019 at 8:59 PM Christian Brauner
> wrote:
>>
>> On Tue, Mar 19, 2019 at 07:42:52PM -0700, Daniel Colascione wrote:
>> > On Tue, Mar 19, 2019 at 6:52 PM Joel Fernandes
> wrote:
>> &
On Wed, Mar 20, 2019 at 12:10:23AM +0100, Christian Brauner wrote:
> On Tue, Mar 19, 2019 at 03:48:32PM -0700, Daniel Colascione wrote:
> > On Tue, Mar 19, 2019 at 3:14 PM Christian Brauner
> > wrote:
> > > So I dislike the idea of allocating new inodes from the procfs super
> > > block. I would
On Tue, Mar 19, 2019 at 11:14:17PM +0100, Christian Brauner wrote:
[snip]
> >
> > ---8<---
> >
> > From: Joel Fernandes
> > Subject: [PATCH] Partial skeleton prototype of pidfd_wait frontend
> >
> > Signed-off-by: Joel Fe
On Mon, Mar 18, 2019 at 01:29:51AM +0100, Christian Brauner wrote:
> On Sun, Mar 17, 2019 at 08:40:19AM -0700, Daniel Colascione wrote:
> > On Sun, Mar 17, 2019 at 4:42 AM Christian Brauner
> > wrote:
> > >
> > > On Sat, Mar 16, 2019 at 09:53:06PM -0400, Joel Fer
> > wrote:
> > > >
> > > > On Fri, Mar 15, 2019 at 11:49 AM Joel Fernandes
> > > > wrote:
> > > > >
> > > > > On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote:
> > > > > [..]
> > >
On Fri, Mar 15, 2019 at 07:24:28PM +0100, Christian Brauner wrote:
[..]
> > why do we want to add a new syscall (pidfd_wait) though? Why not just use
> > standard poll/epoll interface on the proc fd like Daniel was suggesting.
> > AFAIK, once the proc file is opened, the struct pid is essentially p
On Fri, Mar 15, 2019 at 07:03:07PM +0100, Christian Brauner wrote:
> On Thu, Mar 14, 2019 at 09:36:43PM -0700, Daniel Colascione wrote:
> > On Thu, Mar 14, 2019 at 8:16 PM Steven Rostedt wrote:
> > >
> > > On Thu, 14 Mar 2019 13:49:11 -0700
> > > Sultan Alsawaf wrote:
> > >
> > > > Perhaps I'm mi
On Thu, Mar 14, 2019 at 09:36:43PM -0700, Daniel Colascione wrote:
[snip]
> > If you can solve this with an ebpf program, I
> > strongly suggest you do that instead.
>
> Regarding process death notification: I will absolutely not support
> putting aBPF and perf trace events on the critical path o
On Thu, Mar 14, 2019 at 01:49:11PM -0700, Sultan Alsawaf wrote:
> On Thu, Mar 14, 2019 at 10:47:17AM -0700, Joel Fernandes wrote:
> > About the 100ms latency, I wonder whether it is that high because of
> > the way Android's lmkd is observing that a process has died. There
Hi Tim,
Thanks for the detailed and excellent write-up. It will serve as a
good future reference for low memory killer requirements. I made some
comments below on the "how to kill" part.
On Tue, Mar 12, 2019 at 10:17 AM Tim Murray wrote:
>
> On Tue, Mar 12, 2019 at 9:37 AM Sultan Alsawaf wrote:
On Mon, Mar 11, 2019 at 01:46:26PM -0700, Sultan Alsawaf wrote:
> On Mon, Mar 11, 2019 at 01:10:36PM -0700, Suren Baghdasaryan wrote:
> > The idea seems interesting although I need to think about this a bit
> > more. Killing processes based on failed page allocation might backfire
> > during transi
On Mon, Mar 11, 2019 at 12:32:33PM -0400, Joel Fernandes wrote:
> On Sun, Mar 10, 2019 at 01:34:03PM -0700, Sultan Alsawaf wrote:
> [...]
> >
> > /* Perform scheduler related setup. Assign this task to a CPU. */
> > retval = sched_fork(clone_flags, p);
> >
On Sun, Mar 10, 2019 at 01:34:03PM -0700, Sultan Alsawaf wrote:
[...]
>
> /* Perform scheduler related setup. Assign this task to a CPU. */
> retval = sched_fork(clone_flags, p);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 3eb01dedf..fd0d697c6 100644
> --- a/mm/page_alloc
ult in
> > > calling zap_page_range() with an invalid vma which manifests as a
> > > use-after-free in zap_page_range().
> > >
> > > The fix is to check alloc->vma after acquiring the mmap_sem (which we
> > > were acquiring anyway) and skip zap_page_range
Signed-off-by: Tetsuo Handa
> Cc: sta...@vger.kernel.org
Properly this time,
Reviewed-by: Joel Fernandes
thanks,
- Joel
> ---
> drivers/staging/android/ashmem.c | 42
> +++-
> 1 file changed, 24 insertions(+), 18 deletions(-)
>
> diff -
On Mon, Feb 25, 2019 at 2:11 PM Tetsuo Handa
wrote:
>
> On 2019/02/26 6:55, Joel Fernandes wrote:
> >> @@ -763,6 +767,8 @@ static int ashmem_pin_unpin(struct ashmem_area *asma,
> >> unsigned long cmd,
> >>
> >> out_unlock:
> >>
t; Signed-off-by: Tetsuo Handa
> Cc: sta...@vger.kernel.org
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> ---
> drivers/staging/android/ashmem.c | 42
> +++-
> 1 file changed, 24 insertions(+), 18 deletions(-)
>
> diff --gi
On Thu, Feb 14, 2019 at 01:55:19PM -0800, 'Todd Kjos' via kernel-team wrote:
> On Thu, Feb 14, 2019 at 1:25 PM Joel Fernandes wrote:
> >
> > On Thu, Feb 14, 2019 at 03:53:54PM -0500, Joel Fernandes wrote:
> > > On Thu, Feb 14, 2019 at 3:42 PM Todd Kjos wrote:
&g
On Thu, Feb 14, 2019 at 03:53:54PM -0500, Joel Fernandes wrote:
> On Thu, Feb 14, 2019 at 3:42 PM Todd Kjos wrote:
> >
> > On Thu, Feb 14, 2019 at 11:45 AM Joel Fernandes wrote:
> [snip]
> > > > + * check_buffer() - verify that buffer/offset is safe to access
> &
On Thu, Feb 14, 2019 at 3:42 PM Todd Kjos wrote:
>
> On Thu, Feb 14, 2019 at 11:45 AM Joel Fernandes wrote:
[snip]
> > > + * check_buffer() - verify that buffer/offset is safe to access
> > > + * @alloc: binder_alloc for this proc
> > > + * @buffer: binder buffer
On Sat, Feb 09, 2019 at 11:24:03AM +0900, Tetsuo Handa wrote:
> On 2019/02/08 23:45, Joel Fernandes wrote:
> > On Wed, Feb 06, 2019 at 08:45:32AM +0900, Tetsuo Handa wrote:
> >> Joel Fernandes wrote:
> >>> On Tue, Feb 05, 2019 at 07:28:41PM +0900, Tetsuo Handa wrote:
On Wed, Feb 06, 2019 at 08:45:32AM +0900, Tetsuo Handa wrote:
> Joel Fernandes wrote:
> > On Tue, Feb 05, 2019 at 07:28:41PM +0900, Tetsuo Handa wrote:
> > > ashmem_pin() is calling range_shrink() without checking whether
> > > range_alloc() succeeded. Since memory alloc
On Thu, Feb 07, 2019 at 12:30:50AM +0100, Hugo Lefeuvre wrote:
> Hi Joel,
>
> > I'm curious did you try the freezing process and see if pointless wakeups
> > are
> > reduced? That would be an added bonus if you did.
>
> I'm currently testing these changes. I hope to be able to come back with
>
off-by: Hugo Lefeuvre
> ---
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
> include/linux/wait.h | 25 +
> 1 file changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index 5f3efabc36f4..c4
sleeping.
>
> The result is a potential performance gain during freeze, since less
> tasks have to be awaken.
Reviewed-by: Joel Fernandes (Google)
thanks,
- Joel
>
> Signed-off-by: Hugo Lefeuvre
> ---
> include/linux/wait.h | 6 +++---
> 1 file changed, 3 insertions(+),
: syzbot
> Signed-off-by: Tetsuo Handa
> Cc: sta...@vger.kernel.org
> ---
Please in the future, include some information about what changed from
previous patches, or atleast add a cover letter. And use patch revision
numbers. It is hard to know what changed from previous review.
Th
On Tue, Feb 05, 2019 at 07:28:41PM +0900, Tetsuo Handa wrote:
> ashmem_pin() is calling range_shrink() without checking whether
> range_alloc() succeeded. Since memory allocation fault injection might
> force range_alloc() to fail while range_alloc() is called for only once
> for one ioctl() reques
I think you sent to wrong address of Alistair on these and other patches.
Corrected address.
On Fri, Feb 01, 2019 at 06:39:03AM +0100, Hugo Lefeuvre wrote:
> simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using newly
> added wait_event_freezable_hrtimeout helper and remove useles
On Fri, Feb 01, 2019 at 06:38:05AM +0100, Hugo Lefeuvre wrote:
> Replace schedule(); try_to_freeze() by freezable_schedule().
>
> Tasks calling freezable_schedule() set the PF_FREEZER_SKIP flag
> before calling schedule(). Unlike tasks calling schedule();
> try_to_freeze() tasks calling freezable_
On Sat, Jan 19, 2019 at 11:29:12AM +0100, Hugo Lefeuvre wrote:
> > > as far as I understand this code, freezable_schedule() avoids blocking the
> > > freezer during the schedule() call, but in the end try_to_freeze() is
> > > still
> > > called so the result is the same, right?
> > > I wonder why
On Fri, Jan 18, 2019 at 06:08:01PM +0100, Hugo Lefeuvre wrote:
[...]
> > > +/*
> > > + * like wait_event_hrtimeout() -- except it uses TASK_INTERRUPTIBLE to
> > > avoid
> > > + * increasing load and is freezable.
> > > + */
> > > +#define wait_event_freezable_hrtimeout(wq_head, condition, timeout
Hi Hugo,
On Thu, Jan 17, 2019 at 11:41:35PM +0100, Hugo Lefeuvre wrote:
> introduce wait_event_freezable_hrtimeout, an interruptible and freezable
> version of wait_event_hrtimeout.
>
> simplify handle_vsoc_cond_wait (drivers/staging/android/vsoc.c) using this
> newly added helper and remove usel
On Mon, Jan 14, 2019 at 10:50:24AM -0800, Todd Kjos wrote:
> On Mon, Jan 14, 2019 at 10:33 AM Joel Fernandes wrote:
> >
> > On Mon, Jan 14, 2019 at 09:10:21AM -0800, Todd Kjos wrote:
> > > To allow servers to verify client identity, allow a node
> > > flag t
On Mon, Jan 14, 2019 at 09:10:21AM -0800, Todd Kjos wrote:
> To allow servers to verify client identity, allow a node
> flag to be set that causes the sender's security context
> to be delivered with the transaction. The BR_TRANSACTION
> command is extended in BR_TRANSACTION_SEC_CTX to
> contain a
On Thu, Dec 06, 2018 at 03:52:43PM +, Daniel Bovensiepen wrote:
> Fixed spelling in comment section.
>
> Signed-off-by: Daniel Bovensiepen
Acked-by: Joel Fernandes (Google)
> ---
> drivers/staging/android/ashmem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 dele
On Mon, Oct 08, 2018 at 09:46:01PM -0700, Joel Fernandes wrote:
> On Fri, Apr 06, 2018 at 10:23:04AM -0400, Mauro Carvalho Chehab wrote:
> > As warned:
> > drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1834 vpfe_ipipe_init()
> > error: we previously assumed 're
On Fri, Apr 06, 2018 at 10:23:04AM -0400, Mauro Carvalho Chehab wrote:
> As warned:
> drivers/staging/media/davinci_vpfe/dm365_ipipe.c:1834 vpfe_ipipe_init()
> error: we previously assumed 'res' could be null (see line 1797)
>
> There's something wrong at vpfe_ipipe_init():
>
> 1) it cache
On Mon, Jul 16, 2018 at 11:48:51AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jul 06, 2018 at 02:44:16PM -0700, Joel Fernandes wrote:
> > From: Tobias Lindskog
> >
> > When ashmem_shrink is called from direct reclaim on a user thread, a
> > call to do_fallocate will ch
areas.
Because we know that we have a shmem file underneath, call the shmem
implementation of fallocate directly instead of going through the
user-space interface for fallocate.
Bug: 21951515
Signed-off-by: Tobias Lindskog
Signed-off-by: Jeff Vander Stoep
Signed-off-by: Joel Fernandes (G
On Wed, Jun 20, 2018 at 02:21:57PM -0700, Daniel Colascione wrote:
> On Tue, Jun 19, 2018 at 9:32 PM, Joel Fernandes
> wrote:
> > On Tue, Jun 19, 2018 at 05:57:35PM -0700, Alistair Strachan wrote:
> > > The ashmem driver did not check that the size/offset of the vma pass
x-ker...@vger.kernel.org
> Cc: kernel-t...@android.com
> Cc: Joel Fernandes
> Suggested-by: Greg Kroah-Hartman
> Signed-off-by: Alistair Strachan
Acked-by: Joel Fernandes (Google)
thanks,
- Joel
___
devel mailing li
Hjønnevåg
> Cc: Todd Kjos
> Cc: Martijn Coenen
> Cc: de...@driverdev.osuosl.org
> Cc: linux-ker...@vger.kernel.org
> Cc: kernel-t...@android.com
> Cc: Joel Fernandes
> Signed-off-by: Alistair Strachan
> ---
> v2: Removed unnecessary use of unlikely() macro
>
>
On Tue, Feb 27, 2018 at 10:59 PM, Yisheng Xie wrote:
> ashmem_mutex may create a chain of dependencies like:
>
> CPU0CPU1
> mmap syscall ioctl syscall
> -> mmap_sem (acquired) -> ashmem_ioctl
> -> ashmem_mmap
66 matches
Mail list logo
