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
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
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.
>
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
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
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
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
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
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_
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
?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 -
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
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
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
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
>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
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
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
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
;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
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
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
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,
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, 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
---
>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
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
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
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
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) {
30 matches
Mail list logo