Re: [PATCH v2] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Tetsuo Handa
On 2020/07/17 1:29, Christian Brauner wrote: > Does this need a Cc: stable? Up to someone who applies this patch. I think this race is hard to hit. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listin

[PATCH v2] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Tetsuo Handa
com/bug?id=bc9e7303f537c41b2b0cc2dfcea3fc42964c2d45 Reported-by: syzbot Reported-by: syzbot Signed-off-by: Tetsuo Handa --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c index 42c672f1584e..cbe6aa77d50d 10

Re: [PATCH] binder: Don't use mmput() from shrinker function.

2020-07-16 Thread Tetsuo Handa
On 2020/07/16 17:35, Michal Hocko wrote: > On Thu 16-07-20 08:36:52, Tetsuo Handa wrote: >> syzbot is reporting that mmput() from shrinker function has a risk of >> deadlock [1]. Don't start synchronous teardown of mm when called from >> shrinker function. >

[PATCH] binder: Don't use mmput() from shrinker function.

2020-07-15 Thread Tetsuo Handa
d-off-by: Tetsuo Handa --- drivers/android/binder_alloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/android/binder_alloc.c b/drivers/android/binder_alloc.c index 42c672f1584e..cbe6aa77d50d 100644 --- a/drivers/android/binder_alloc.c +++ b/drivers/android/binder_al

Re: [PATCH] staging: android: ashmem: Avoid range_alloc() allocation with ashmem_mutex held.

2019-02-25 Thread Tetsuo Handa
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: >> mutex_unlock(&ashmem_mutex); >> +if (range) >> +kmem_cache_free(ashmem_range_cachep, range); > > This seems a b

[PATCH] staging: android: ashmem: Avoid range_alloc() allocation with ashmem_mutex held.

2019-02-22 Thread Tetsuo Handa
range_alloc() not to fail. This patch is mostly meant for backporting purpose for fuzz testing on stable/distributor kernels, for there is a plan to remove this code in near future. Signed-off-by: Tetsuo Handa Cc: sta...@vger.kernel.org --- drivers/staging/android/ashmem.c | 42

Re: [PATCH 2/2] staging: android: ashmem: Don't allow range_alloc() to fail.

2019-02-14 Thread Tetsuo Handa
Joel Fernandes wrote: > I am sorry, what has changed in the updated patch? Please send clear diff > notes in your patches or at least mention exactly what changed since previous > patch revision. It is very difficult to review if you don't even mention what > changed since previous revision. Please

Re: [PATCH 2/2] staging: android: ashmem: Don't allow range_alloc() to fail.

2019-02-08 Thread Tetsuo Handa
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: >>>> ashmem_pin() is calling range_shrink() without checking whethe

Re: [PATCH 2/2] staging: android: ashmem: Don't allow range_alloc() to fail.

2019-02-05 Thread Tetsuo Handa
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 allocation fault injection might > > force range_alloc() to fail while range_

[PATCH 2/2] staging: android: ashmem: Don't allow range_alloc() to fail.

2019-02-05 Thread Tetsuo Handa
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() request, make range_alloc() not to fail. Signed-off-by: Tetsuo Handa

[PATCH 1/2] staging: android: ashmem: Don't call fallocate() with ashmem_mutex held.

2019-02-05 Thread Tetsuo Handa
?id=7ebea492de7521048355fc84210220e1038a7908 [3] https://syzkaller.appspot.com/bug?id=e02419c12131c24e2a957ea050c2ab6dcbbc3270 Reported-by: syzbot Reported-by: syzbot Reported-by: syzbot Signed-off-by: Tetsuo Handa Cc: sta...@vger.kernel.org --- drivers/staging/android/ashmem.c | 25 -

Re: [PATCH] ANDROID: binder: Latelimit binder_debug().

2018-09-07 Thread Tetsuo Handa
On 2018/07/10 21:40, Martijn Coenen wrote: > On Tue, Jul 10, 2018 at 2:09 PM, Tetsuo Handa > wrote: >> I don't have benchmark data (I'm not an Android user). But an example log at >> https://syzkaller.appspot.com/text?tag=CrashLog&x=12f316fc40 got >> abo

Re: [PATCH] ANDROID: binder: Latelimit binder_debug().

2018-07-10 Thread Tetsuo Handa
On 2018/07/09 23:29, Tetsuo Handa wrote: > On 2018/07/09 23:02, Martijn Coenen wrote: >> On Mon, Jul 9, 2018 at 3:27 PM, Dmitry Vyukov wrote: >>> I know almost nothing about binder. How these debug messages are >>> enabled? I don't see anything like CONFIG_BINDER

Re: [PATCH] ANDROID: binder: Latelimit binder_debug().

2018-07-09 Thread Tetsuo Handa
On 2018/07/09 23:02, Martijn Coenen wrote: > On Mon, Jul 9, 2018 at 3:27 PM, Dmitry Vyukov wrote: >> I know almost nothing about binder. How these debug messages are >> enabled? I don't see anything like CONFIG_BINDER_VERBOSE_DEBUG in the >> config: >> https://github.com/google/syzkaller/blob/mas

Re: [PATCH] ANDROID: binder: Latelimit binder_debug().

2018-07-09 Thread Tetsuo Handa
Dmitry, do you know how/why syzbot is enabling debug messages? On 2018/07/09 16:38, Greg Kroah-Hartman wrote: > On Mon, Jul 09, 2018 at 10:10:34AM +0900, Tetsuo Handa wrote: >> >From 62ddef96020cb397dcbf4b8574f1859b32f983de Mon Sep 17 00:00:00 2001 >> From: Tetsuo Handa >&g

[PATCH] ANDROID: binder: Latelimit binder_debug().

2018-07-08 Thread Tetsuo Handa
>From 62ddef96020cb397dcbf4b8574f1859b32f983de Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Mon, 9 Jul 2018 09:54:01 +0900 Subject: [PATCH] ANDROID: binder: Latelimit binder_debug(). syzbot is reporting hung tasks [1] [2]. This might be due to flooding of printk() messages from bin

[PATCH] staging: android: ion: Check for register_shrinker() failure.

2017-11-29 Thread Tetsuo Handa
register_shrinker() might return -ENOMEM error since Linux 3.12. But since callers of ion_device_add_heap() are not ready to receive an error and it is not simple enough to fix within this patch, this patch just prints a warning line when register_shrinker() failed. Signed-off-by: Tetsuo Handa

[PATCH] android: binder: Check for errors in binder_alloc_shrinker_init().

2017-11-29 Thread Tetsuo Handa
Both list_lru_init() and register_shrinker() might return an error. Signed-off-by: Tetsuo Handa Cc: Sherry Yang Cc: Greg Kroah-Hartman Cc: Michal Hocko --- drivers/android/binder.c | 4 +++- drivers/android/binder_alloc.c | 12 +--- drivers/android/binder_alloc.h | 2 +- 3

[PATCH] staging: android: ashmem: Check for register_shrinker() failure.

2017-11-29 Thread Tetsuo Handa
register_shrinker() might return -ENOMEM error since Linux 3.12. Signed-off-by: Tetsuo Handa Cc: Robert Love Cc: Marco Nelissen Cc: John Stultz Cc: Greg Kroah-Hartman Cc: Michal Hocko --- drivers/staging/android/ashmem.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff

Re: [patch] staging: lowmemorykiller: remove bogus NULL check

2016-04-08 Thread Tetsuo Handa
;mm != NULL. > > Signed-off-by: Dan Carpenter Acked-by: Tetsuo Handa > > diff --git a/drivers/staging/android/lowmemorykiller.c > b/drivers/staging/android/lowmemorykiller.c > index c79f224..24d2745 100644 > --- a/drivers/staging/android/lowmemorykiller.c > +++ b/dri

Re: android,lowmemorykiller: Don't abuse TIF_MEMDIE.

2016-04-07 Thread Tetsuo Handa
Dan Carpenter wrote: > On Thu, Apr 07, 2016 at 06:49:58AM +0900, Tetsuo Handa wrote: > > Dan Carpenter wrote: > > > Hello Tetsuo Handa, > > > > Hello, Dan. > > > > > > > > This is a semi-automatic email about new static checker w

Re: android,lowmemorykiller: Don't abuse TIF_MEMDIE.

2016-04-06 Thread Tetsuo Handa
Dan Carpenter wrote: > Hello Tetsuo Handa, Hello, Dan. > > This is a semi-automatic email about new static checker warnings. > > The patch 77ed2c5745d9: "android,lowmemorykiller: Don't abuse > TIF_MEMDIE." from Mar 8, 2016, leads to the following Smatch

Re: [PATCH] android,lowmemorykiller: Don't abuse TIF_MEMDIE.

2016-04-04 Thread Tetsuo Handa
Greg KH wrote: > On Mon, Mar 21, 2016 at 08:00:49PM +0900, Tetsuo Handa wrote: > > Greg Kroah-Hartman wrote: > > > On Tue, Mar 08, 2016 at 03:18:59PM +0100, Michal Hocko wrote: > > > > On Tue 08-03-16 20:01:32, Tetsuo Handa wrote: > > > > > Currently,

Re: [PATCH] android,lowmemorykiller: Don't abuse TIF_MEMDIE.

2016-03-21 Thread Tetsuo Handa
Greg Kroah-Hartman wrote: > On Tue, Mar 08, 2016 at 03:18:59PM +0100, Michal Hocko wrote: > > On Tue 08-03-16 20:01:32, Tetsuo Handa wrote: > > > Currently, lowmemorykiller (LMK) is using TIF_MEMDIE for two purposes. > > > One is to remember processes killed

[PATCH] android,lowmemorykiller: Don't abuse TIF_MEMDIE.

2016-03-08 Thread Tetsuo Handa
patch, assumption by mark_oom_victim() becomes true. Signed-off-by: Tetsuo Handa Cc: Michal Hocko Cc: Greg Kroah-Hartman Cc: Arve Hjonnevag Cc: Riley Andrews --- drivers/staging/android/lowmemorykiller.c | 9 ++--- include/linux/sched.h | 4 2 files changed, 6

Re: [PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and sending SIGKILL.

2015-09-04 Thread Tetsuo Handa
--- >From 118609fa25700af11791b1b7e8349f8973a9e7e4 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Sat, 5 Sep 2015 02:58:12 +0900 Subject: [PATCH] android, lmk: Send SIGKILL before setting TIF_MEMDIE. It was observed that setting TIF_MEMDIE before sending SIGKILL at oom_kill_process() allows me

Re: [PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and sending SIGKILL.

2015-08-26 Thread Tetsuo Handa
Reposting updated version as it turned out that we can call do_send_sig_info() with task_lock held. ;-) ( http://marc.info/?l=linux-mm&m=144059948628905&w=2 ) Tetsuo Handa wrote: > Should selected_tasksize be added to rem even when TIF_MEMDIE was not set? Commit e1099a69a624 "and

[PATCH 1/2] android, lmk: Protect task->comm with task_lock.

2015-08-26 Thread Tetsuo Handa
Hello. Next patch is mm-related but this patch is not. Via which tree should these patches go? >From 48c1b457eb32d7a029e9a078ee0a67974ada9261 Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Wed, 26 Aug 2015 20:49:17 +0900 Subject: [PATCH 1/2] andr

[PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and sending SIGKILL.

2015-08-26 Thread Tetsuo Handa
Mon Sep 17 00:00:00 2001 From: Tetsuo Handa Date: Wed, 26 Aug 2015 20:52:39 +0900 Subject: [PATCH 2/2] android, lmk: Reverse the order of setting TIF_MEMDIE and sending SIGKILL. If we set TIF_MEMDIE before sending SIGKILL, memory reserves could be spent for allocations which are not needed

Re: [RFC PATCH] vsnprintf: Remove use of %n and convert existing uses

2013-09-11 Thread Tetsuo Handa
Joe Perches wrote: > - seq_printf(m, "%s%d%n", con->name, con->index, &len); > + len = seq_printf(m, "%s%d", con->name, con->index); Isn't len always 0 or -1 ? int seq_vprintf(struct seq_file *m, const char *f, va_list args) { int len; if (m->count < m->size) {