>From 2642b4a1904259384f2018ea8df03ac49509c57a Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 10 Jul 2018 15:01:20 +0900
Subject: [PATCH] locking/rwsem: Convert the other sem->count to 'atomic_long_t'
Since "locking/rwsem: Convert sem->count to 'atomic_long_t'" forgot
Andrew Morton wrote:
> On Sat, 7 Jul 2018 08:26:32 +0900 Tetsuo Handa
> wrote:
>
> > Hello Andrew,
> >
> > It seems that syzbot (experimentally ?) restarted testing linux-next.
> >
> > May I ask you to carry temporarily debug printk() patch at
> &
Andrew Morton wrote:
> On Sat, 7 Jul 2018 08:26:32 +0900 Tetsuo Handa
> wrote:
>
> > Hello Andrew,
> >
> > It seems that syzbot (experimentally ?) restarted testing linux-next.
> >
> > May I ask you to carry temporarily debug printk() patch at
> &
On 2018/07/09 23:24, Matthew Wilcox wrote:
>> Anyway, linux-next-20180709 still does not have this fix.
>> What is the title of your fix you pushed on Saturday?
>
> I folded it into shmem: Convert shmem_add_to_page_cache to XArray.
> I can see it's fixed in today's linux-next. I fixed it
On 2018/07/09 23:24, Matthew Wilcox wrote:
>> Anyway, linux-next-20180709 still does not have this fix.
>> What is the title of your fix you pushed on Saturday?
>
> I folded it into shmem: Convert shmem_add_to_page_cache to XArray.
> I can see it's fixed in today's linux-next. I fixed it
On 2018/07/09 22:32, Matthew Wilcox wrote:
>> >From d6f24d6eecd79836502527624f8086f4e3e4c331 Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa
>> Date: Mon, 9 Jul 2018 15:58:44 +0900
>> Subject: [PATCH] shmem: Fix crash upon xas_store() failure.
>>
>>
On 2018/07/09 22:32, Matthew Wilcox wrote:
>> >From d6f24d6eecd79836502527624f8086f4e3e4c331 Mon Sep 17 00:00:00 2001
>> From: Tetsuo Handa
>> Date: Mon, 9 Jul 2018 15:58:44 +0900
>> Subject: [PATCH] shmem: Fix crash upon xas_store() failure.
>>
>>
rom d6f24d6eecd79836502527624f8086f4e3e4c331 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 9 Jul 2018 15:58:44 +0900
Subject: [PATCH] shmem: Fix crash upon xas_store() failure.
syzbot is reporting list corruption [1]. This is because xas_store() from
shmem_add_to_page_cache() is not handling memory allocation fail
rom d6f24d6eecd79836502527624f8086f4e3e4c331 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Mon, 9 Jul 2018 15:58:44 +0900
Subject: [PATCH] shmem: Fix crash upon xas_store() failure.
syzbot is reporting list corruption [1]. This is because xas_store() from
shmem_add_to_page_cache() is not handling memory allocation fail
v4.18-rc3]
> [cannot apply to tip/auto-latest tip/sched/core linus/master v4.18-rc3
> v4.18-rc2 v4.18-rc1]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Tetsuo-Hand
v4.18-rc3]
> [cannot apply to tip/auto-latest tip/sched/core linus/master v4.18-rc3
> v4.18-rc2 v4.18-rc1]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improve the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Tetsuo-Hand
On 2018/07/07 20:12, Ingo Molnar wrote:
>
> * Tetsuo Handa wrote:
>
>> From: Tetsuo Handa
>>
>> Since syzbot is confused by concurrent printk() messages [1],
>> this patch changes show_opcodes() to use snprintf().
>>
>> When we start adding
On 2018/07/07 20:12, Ingo Molnar wrote:
>
> * Tetsuo Handa wrote:
>
>> From: Tetsuo Handa
>>
>> Since syzbot is confused by concurrent printk() messages [1],
>> this patch changes show_opcodes() to use snprintf().
>>
>> When we start adding
tps://syzkaller.appspot.com/bug?id=287aa8708bc940d0ca1645223c53dd4c2d203be6
Signed-off-by: Tetsuo Handa
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Dmitry Vyukov
---
include/linux/sched.h | 1 +
kernel/hung_task.c| 25 +
kernel/locking/percpu-rwse
tps://syzkaller.appspot.com/bug?id=287aa8708bc940d0ca1645223c53dd4c2d203be6
Signed-off-by: Tetsuo Handa
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Will Deacon
Cc: Dmitry Vyukov
---
include/linux/sched.h | 1 +
kernel/hung_task.c| 25 +
kernel/locking/percpu-rwse
From: Tetsuo Handa
Since syzbot is confused by concurrent printk() messages [1],
this patch changes show_opcodes() to use snprintf().
When we start adding prefix to each line of printk() output,
we will be able to handle concurrent printk() messages.
[1] https://syzkaller.appspot.com/text?tag
From: Tetsuo Handa
Since syzbot is confused by concurrent printk() messages [1],
this patch changes show_opcodes() to use snprintf().
When we start adding prefix to each line of printk() output,
we will be able to handle concurrent printk() messages.
[1] https://syzkaller.appspot.com/text?tag
Jul 6, 2018 at 3:07 AM Tetsuo Handa
>> wrote:
>>>
>>> I noticed that makedumpfile utility is failing to check kernel version, for
>>> it depends on offset of "struct uts_namespace"->name being sizeof(int).
>>
>> For something like this, we
Jul 6, 2018 at 3:07 AM Tetsuo Handa
>> wrote:
>>>
>>> I noticed that makedumpfile utility is failing to check kernel version, for
>>> it depends on offset of "struct uts_namespace"->name being sizeof(int).
>>
>> For something like this, we
Hello Andrew,
It seems that syzbot (experimentally ?) restarted testing linux-next.
May I ask you to carry temporarily debug printk() patch at
https://groups.google.com/d/msg/syzkaller-bugs/E8M8WTqt034/OpadOICfCAAJ
for "INFO: task hung in __sb_start_write" case?
The bug should be reproduced
Hello Andrew,
It seems that syzbot (experimentally ?) restarted testing linux-next.
May I ask you to carry temporarily debug printk() patch at
https://groups.google.com/d/msg/syzkaller-bugs/E8M8WTqt034/OpadOICfCAAJ
for "INFO: task hung in __sb_start_write" case?
The bug should be reproduced
us Torvalds wrote:
> On Fri, Jul 6, 2018 at 3:07 AM Tetsuo Handa
> wrote:
>>
>> I noticed that makedumpfile utility is failing to check kernel version, for
>> it depends on offset of "struct uts_namespace"->name being sizeof(int).
>
> For something like t
us Torvalds wrote:
> On Fri, Jul 6, 2018 at 3:07 AM Tetsuo Handa
> wrote:
>>
>> I noticed that makedumpfile utility is failing to check kernel version, for
>> it depends on offset of "struct uts_namespace"->name being sizeof(int).
>
> For something like t
}
--
Since there is no way to tell the offset to userspace, let's not randomize
"struct uts_namespace".
Signed-off-by: Tetsuo Handa
Fixes: 3859a271a003aba0 ("randstruct: Mark various structs for randomization")
Cc: stable # v4.13+
---
include/linux/utsname.h | 2
}
--
Since there is no way to tell the offset to userspace, let's not randomize
"struct uts_namespace".
Signed-off-by: Tetsuo Handa
Fixes: 3859a271a003aba0 ("randstruct: Mark various structs for randomization")
Cc: stable # v4.13+
---
include/linux/utsname.h | 2
On 2018/06/27 5:37, Tetsuo Handa wrote:
> I think that syzbot can stop deciding email recipients and leave it to those
> who
> diagnose bugs, for the ratio of sending to wrong subsystem maintainers is not
> low.
> For example, syzbot assumed that "INFO: task hung in __get_sup
On 2018/06/27 5:37, Tetsuo Handa wrote:
> I think that syzbot can stop deciding email recipients and leave it to those
> who
> diagnose bugs, for the ratio of sending to wrong subsystem maintainers is not
> low.
> For example, syzbot assumed that "INFO: task hung in __get_sup
Hello.
Today I was testing conditions when/how stall watchdog fires. I noticed that
printing NMI backtraces to consoles is delayed till IRQ is enabled or somebody
else schedules printk(). This is not a welcomed behavior when the cause of
lock up is doing nearly-infinite loop with IRQ disabled.
Hello.
Today I was testing conditions when/how stall watchdog fires. I noticed that
printing NMI backtraces to consoles is delayed till IRQ is enabled or somebody
else schedules printk(). This is not a welcomed behavior when the cause of
lock up is doing nearly-infinite loop with IRQ disabled.
On 2018/06/29 21:52, Paul E. McKenney wrote:
> The effect of RCU's current OOM code is to speed up callback invocation
> by at most a few seconds (assuming no stalled CPUs, in which case
> it is not possible to speed up callback invocation).
>
> Given that, I should just remove RCU's OOM code
On 2018/06/29 21:52, Paul E. McKenney wrote:
> The effect of RCU's current OOM code is to speed up callback invocation
> by at most a few seconds (assuming no stalled CPUs, in which case
> it is not possible to speed up callback invocation).
>
> Given that, I should just remove RCU's OOM code
On 2018/06/27 8:50, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 05:10:48AM +0900, Tetsuo Handa wrote:
>> As far as I can see,
>>
>> -atomic_set(_callback_count, 1);
>> +atomic_inc(_callback_count);
>>
>> should be sufficient.
>
> I do
On 2018/06/27 8:50, Paul E. McKenney wrote:
> On Wed, Jun 27, 2018 at 05:10:48AM +0900, Tetsuo Handa wrote:
>> As far as I can see,
>>
>> -atomic_set(_callback_count, 1);
>> +atomic_inc(_callback_count);
>>
>> should be sufficient.
>
> I do
On 2018/06/25 18:36, Dmitry Vyukov wrote:
> On Mon, Jun 25, 2018 at 3:41 AM, Sergey Senozhatsky
> wrote:
>> On (06/22/18 22:06), Tetsuo Handa wrote:
>>>>
>>>> Awesome. If you and Fengguang can combine forces and lead the
>>>> whole thing towards &qu
On 2018/06/25 18:36, Dmitry Vyukov wrote:
> On Mon, Jun 25, 2018 at 3:41 AM, Sergey Senozhatsky
> wrote:
>> On (06/22/18 22:06), Tetsuo Handa wrote:
>>>>
>>>> Awesome. If you and Fengguang can combine forces and lead the
>>>> whole thing towards &qu
On 2018/06/26 23:54, Guenter Roeck wrote:
> On Tue, Jun 26, 2018 at 7:38 AM Dmitry Vyukov wrote:
>>
>> On Tue, Jun 26, 2018 at 4:16 PM, Theodore Y. Ts'o wrote:
>>> On Tue, Jun 26, 2018 at 07:54:53PM +0900, Tetsuo Handa wrote:
>>>> I hope we can accept
On 2018/06/26 23:54, Guenter Roeck wrote:
> On Tue, Jun 26, 2018 at 7:38 AM Dmitry Vyukov wrote:
>>
>> On Tue, Jun 26, 2018 at 4:16 PM, Theodore Y. Ts'o wrote:
>>> On Tue, Jun 26, 2018 at 07:54:53PM +0900, Tetsuo Handa wrote:
>>>> I hope we can accept
On 2018/06/27 2:03, Paul E. McKenney wrote:
> There are a lot of ways it could be made concurrency safe. If you need
> me to do this, please do let me know.
>
> That said, the way it is now written, if you invoke rcu_oom_notify()
> twice in a row, the second invocation will wait until the memory
On 2018/06/27 2:03, Paul E. McKenney wrote:
> There are a lot of ways it could be made concurrency safe. If you need
> me to do this, please do let me know.
>
> That said, the way it is now written, if you invoke rcu_oom_notify()
> twice in a row, the second invocation will wait until the memory
On 2018/06/10 7:17, Linus Torvalds wrote:
> On Fri, Jun 8, 2018 at 11:36 PM Tetsuo Handa
> wrote:
>> On 2018/01/22 22:32, Dmitry Vyukov wrote:
>>>
>>> FTR I've just dropped linux-next and mmots from syzbot.
>>
>> I hope that we can test linux-next on syz
On 2018/06/10 7:17, Linus Torvalds wrote:
> On Fri, Jun 8, 2018 at 11:36 PM Tetsuo Handa
> wrote:
>> On 2018/01/22 22:32, Dmitry Vyukov wrote:
>>>
>>> FTR I've just dropped linux-next and mmots from syzbot.
>>
>> I hope that we can test linux-next on syz
On 2018/06/15 5:42, David Rientjes wrote:
> Note: I understand there is an objection based on timeout based delays.
> This is currently the only possible way to avoid oom killing important
> processes completely unnecessarily. If the oom reaper can someday free
> all memory, including mlocked
On 2018/06/15 5:42, David Rientjes wrote:
> Note: I understand there is an objection based on timeout based delays.
> This is currently the only possible way to avoid oom killing important
> processes completely unnecessarily. If the oom reaper can someday free
> all memory, including mlocked
On 2018/06/20 22:06, Sergey Senozhatsky wrote:
> On (06/20/18 13:32), Dmitry Vyukov wrote:
>>> So, if we could get rid of pr_cont() from the most important parts
>>> (instruction dumps, etc) then I would just vote to leave pr_cont()
>>> alone and avoid any handling of it in printk context
On 2018/06/20 22:06, Sergey Senozhatsky wrote:
> On (06/20/18 13:32), Dmitry Vyukov wrote:
>>> So, if we could get rid of pr_cont() from the most important parts
>>> (instruction dumps, etc) then I would just vote to leave pr_cont()
>>> alone and avoid any handling of it in printk context
On 2018/06/21 7:36, David Rientjes wrote:
>> @@ -1010,6 +1010,33 @@ int unregister_oom_notifier(struct notifier_block *nb)
>> EXPORT_SYMBOL_GPL(unregister_oom_notifier);
>>
>> /**
>> + * try_oom_notifier - Try to reclaim memory from OOM notifier list.
>> + *
>> + * Returns non-zero if notifier
On 2018/06/21 7:36, David Rientjes wrote:
>> @@ -1010,6 +1010,33 @@ int unregister_oom_notifier(struct notifier_block *nb)
>> EXPORT_SYMBOL_GPL(unregister_oom_notifier);
>>
>> /**
>> + * try_oom_notifier - Try to reclaim memory from OOM notifier list.
>> + *
>> + * Returns non-zero if notifier
On 2018/06/20 20:55, Michal Hocko wrote:
> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
>> Sleeping with oom_lock held can cause AB-BA lockup bug because
>> __alloc_pages_may_oom() does not wait for oom_lock. Since
>> blocking_notifier_call_chain() in out_of_memory()
On 2018/06/20 20:55, Michal Hocko wrote:
> On Wed 20-06-18 20:20:38, Tetsuo Handa wrote:
>> Sleeping with oom_lock held can cause AB-BA lockup bug because
>> __alloc_pages_may_oom() does not wait for oom_lock. Since
>> blocking_notifier_call_chain() in out_of_memory()
a OOM
notifier after OOM killer is disabled (that is, suspend/hibernate is in
progress). But such change should be safe because of pm_suspended_storage()
check.
Signed-off-by: Tetsuo Handa
---
include/linux/oom.h | 1 +
mm/oom_kill.c | 35 ++--
mm/p
a OOM
notifier after OOM killer is disabled (that is, suspend/hibernate is in
progress). But such change should be safe because of pm_suspended_storage()
check.
Signed-off-by: Tetsuo Handa
---
include/linux/oom.h | 1 +
mm/oom_kill.c | 35 ++--
mm/p
Dmitry Vyukov wrote:
> On Tue, Jun 19, 2018 at 4:10 PM, Tetsuo Handa
> wrote:
> > On 2018/06/19 20:53, Dmitry Vyukov wrote:
> >> On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
> >> wrote:
> >>> This bug report is getting no feedback, but I guess that t
Dmitry Vyukov wrote:
> On Tue, Jun 19, 2018 at 4:10 PM, Tetsuo Handa
> wrote:
> > On 2018/06/19 20:53, Dmitry Vyukov wrote:
> >> On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
> >> wrote:
> >>> This bug report is getting no feedback, but I guess that t
On 2018/06/19 20:53, Dmitry Vyukov wrote:
> On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
> wrote:
>> This bug report is getting no feedback, but I guess that this bug is in
>> block or mm or locking layer rather than fs layer.
>>
>> NMI backtrace for this bug tends
On 2018/06/19 20:53, Dmitry Vyukov wrote:
> On Tue, Jun 19, 2018 at 1:44 PM, Tetsuo Handa
> wrote:
>> This bug report is getting no feedback, but I guess that this bug is in
>> block or mm or locking layer rather than fs layer.
>>
>> NMI backtrace for this bug tends
On 2018/06/19 20:47, Dmitry Vyukov wrote:
>> If no, we would want a git tree for testing under syzbot.
>
> Thinking of this, we could setup a sandbox instance that won't report
> anything over email at all, but crashes will be available on the web.
> We could point this instance to a custom git
On 2018/06/19 20:47, Dmitry Vyukov wrote:
>> If no, we would want a git tree for testing under syzbot.
>
> Thinking of this, we could setup a sandbox instance that won't report
> anything over email at all, but crashes will be available on the web.
> We could point this instance to a custom git
This bug report is getting no feedback, but I guess that this bug is in
block or mm or locking layer rather than fs layer.
NMI backtrace for this bug tends to report that sb_bread() from fill_super()
from mount_bdev() is stalling is the cause of keep holding s_umount_key for
more than 120
This bug report is getting no feedback, but I guess that this bug is in
block or mm or locking layer rather than fs layer.
NMI backtrace for this bug tends to report that sb_bread() from fill_super()
from mount_bdev() is stalling is the cause of keep holding s_umount_key for
more than 120
On 2018/06/16 4:40, Tetsuo Handa wrote:
> Hmm, there might be other locations calling percpu_rwsem_release() ?
There are other locations calling percpu_rwsem_release(), but quite few.
include/linux/fs.h:1494:#define __sb_writers_release(sb, lev) \
include/linux/fs.h-1
On 2018/06/16 4:40, Tetsuo Handa wrote:
> Hmm, there might be other locations calling percpu_rwsem_release() ?
There are other locations calling percpu_rwsem_release(), but quite few.
include/linux/fs.h:1494:#define __sb_writers_release(sb, lev) \
include/linux/fs.h-1
On 2018/06/15 18:19, Dmitry Vyukov wrote:
> On Thu, Jun 14, 2018 at 12:33 PM, Tetsuo Handa
> wrote:
>> On 2018/06/11 16:39, Dmitry Vyukov wrote:
>>> On Mon, Jun 11, 2018 at 9:30 AM, Peter Zijlstra
>>> wrote:
>>>> On Sun, Jun 10, 20
On 2018/06/15 18:19, Dmitry Vyukov wrote:
> On Thu, Jun 14, 2018 at 12:33 PM, Tetsuo Handa
> wrote:
>> On 2018/06/11 16:39, Dmitry Vyukov wrote:
>>> On Mon, Jun 11, 2018 at 9:30 AM, Peter Zijlstra
>>> wrote:
>>>> On Sun, Jun 10, 20
On 2018/06/11 16:39, Dmitry Vyukov wrote:
> On Mon, Jun 11, 2018 at 9:30 AM, Peter Zijlstra wrote:
>> On Sun, Jun 10, 2018 at 11:47:56PM +0900, Tetsuo Handa wrote:
>>
>>> This looks quite strange that nobody is holding percpu_rw_semaphore for
>>> write but
On 2018/06/11 16:39, Dmitry Vyukov wrote:
> On Mon, Jun 11, 2018 at 9:30 AM, Peter Zijlstra wrote:
>> On Sun, Jun 10, 2018 at 11:47:56PM +0900, Tetsuo Handa wrote:
>>
>>> This looks quite strange that nobody is holding percpu_rw_semaphore for
>>> write but
On 2018/06/05 17:57, Michal Hocko wrote:
>> For this reason, we see testing harnesses often oom killed immediately
>> after running a unittest that stresses reclaim or compaction by inducing a
>> system-wide oom condition. The harness spawns the unittest which spawns
>> an antagonist memory
On 2018/06/05 17:57, Michal Hocko wrote:
>> For this reason, we see testing harnesses often oom killed immediately
>> after running a unittest that stresses reclaim or compaction by inducing a
>> system-wide oom condition. The harness spawns the unittest which spawns
>> an antagonist memory
On 2018/06/11 20:16, Dmitry Vyukov wrote:
>> timeout = 60 and period = 1 would allow hung task to be reported as soon
>> as it remained uninterruptible for 60 seconds. That makes me easier to
>> narrow down relevant kernel messages and syzbot program.
>>
>> Well, showing exact slept time, along
On 2018/06/11 20:16, Dmitry Vyukov wrote:
>> timeout = 60 and period = 1 would allow hung task to be reported as soon
>> as it remained uninterruptible for 60 seconds. That makes me easier to
>> narrow down relevant kernel messages and syzbot program.
>>
>> Well, showing exact slept time, along
khugepaged is trying to hold mm->mmap_sem for write, which is held
for read by a thread which is stuck at __sb_start_write(). Therefore,
#syz dup: INFO: task hung in __sb_start_write
khugepaged is trying to hold mm->mmap_sem for write, which is held
for read by a thread which is stuck at __sb_start_write(). Therefore,
#syz dup: INFO: task hung in __sb_start_write
I haven't succeeded reproducing this bug using original C reproducer.
Instead, I'm observing XFS warning using modified reproducer shown below.
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
I haven't succeeded reproducing this bug using original C reproducer.
Instead, I'm observing XFS warning using modified reproducer shown below.
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
Hello.
Commits
401c636a0eeb0d51 "kernel/hung_task.c: show all hung tasks before panic"
8cc05c71ba5f7936 "locking/lockdep: Move sanity check to inside
lockdep_print_held_locks()"
arrived at linux.git and syzbot started giving us more hints.
Quoting from
Hello.
Commits
401c636a0eeb0d51 "kernel/hung_task.c: show all hung tasks before panic"
8cc05c71ba5f7936 "locking/lockdep: Move sanity check to inside
lockdep_print_held_locks()"
arrived at linux.git and syzbot started giving us more hints.
Quoting from
On 2018/06/09 6:58, Andrew Morton wrote:
> On Fri, 8 Jun 2018 15:30:43 +0200 Dmitry Vyukov wrote:
>
>> Currently task hung checking period is equal to timeout,
>> as the result hung is detected anywhere between timeout and 2*timeout.
>> This is fine for most interactive environments, but this
On 2018/06/09 6:58, Andrew Morton wrote:
> On Fri, 8 Jun 2018 15:30:43 +0200 Dmitry Vyukov wrote:
>
>> Currently task hung checking period is equal to timeout,
>> as the result hung is detected anywhere between timeout and 2*timeout.
>> This is fine for most interactive environments, but this
On 2018/01/22 22:32, Dmitry Vyukov wrote:
> On Tue, Jan 16, 2018 at 6:34 PM, Greg Kroah-Hartman
> wrote:
>>> The problem is testing linux-next and then using get-maintainer.pl to
>>> report the problem.
>>>
>>> If you are resource limited I would start by testing Linus's tree to
>>> find the
On 2018/01/22 22:32, Dmitry Vyukov wrote:
> On Tue, Jan 16, 2018 at 6:34 PM, Greg Kroah-Hartman
> wrote:
>>> The problem is testing linux-next and then using get-maintainer.pl to
>>> report the problem.
>>>
>>> If you are resource limited I would start by testing Linus's tree to
>>> find the
On 2018/06/07 20:00, Petr Mladek wrote:
>> ---
>>
>> drivers/tty/tty_buffer.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index c996b6859c5e..71958ef6a831 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++
On 2018/06/07 20:00, Petr Mladek wrote:
>> ---
>>
>> drivers/tty/tty_buffer.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/tty/tty_buffer.c b/drivers/tty/tty_buffer.c
>> index c996b6859c5e..71958ef6a831 100644
>> --- a/drivers/tty/tty_buffer.c
>> +++
ing to be submitted "properly" so that I can
> queue it up? :)
>
> thanks,
>
> greg k-h
>
On 2018/05/26 9:53, Tetsuo Handa wrote:
> syzbot is reporting stalls at n_tty_receive_char_special() [1]. This is
> because comparison is not working as e
ing to be submitted "properly" so that I can
> queue it up? :)
>
> thanks,
>
> greg k-h
>
On 2018/05/26 9:53, Tetsuo Handa wrote:
> syzbot is reporting stalls at n_tty_receive_char_special() [1]. This is
> because comparison is not working as e
On 2018/06/02 20:58, yuzhoujian wrote:
> -void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct
> *p)
> +void mem_cgroup_print_oom_context(struct mem_cgroup *memcg, struct
> task_struct *p,
> + enum oom_constraint constraint, nodemask_t *nodemask)
> {
>
On 2018/06/02 20:58, yuzhoujian wrote:
> -void mem_cgroup_print_oom_info(struct mem_cgroup *memcg, struct task_struct
> *p)
> +void mem_cgroup_print_oom_context(struct mem_cgroup *memcg, struct
> task_struct *p,
> + enum oom_constraint constraint, nodemask_t *nodemask)
> {
>
>From 8a8222698163d1fe180258566e9a3ff43f54fcd9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Sun, 27 May 2018 11:08:20 +0900
Subject: [PATCH] bdi: Fix another oops in wb_workfn()
syzbot is still hitting NULL pointer dereference at wb_wo
>From 8a8222698163d1fe180258566e9a3ff43f54fcd9 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sun, 27 May 2018 11:08:20 +0900
Subject: [PATCH] bdi: Fix another oops in wb_workfn()
syzbot is still hitting NULL pointer dereference at wb_workfn() [1].
This might be because we overloo
Forwarding
http://lkml.kernel.org/r/201805251915.fgh64517.hvfjoolffmq...@i-love.sakura.ne.jp
.
Jan Kara wrote:
> > void delayed_work_timer_fn(struct timer_list *t)
> > {
> > struct delayed_work *dwork = from_timer(dwork, t, timer);
> >
> > /* should have been called from irqsafe timer
Forwarding
http://lkml.kernel.org/r/201805251915.fgh64517.hvfjoolffmq...@i-love.sakura.ne.jp
.
Jan Kara wrote:
> > void delayed_work_timer_fn(struct timer_list *t)
> > {
> > struct delayed_work *dwork = from_timer(dwork, t, timer);
> >
> > /* should have been called from irqsafe timer
race bugs should no longer
exist. Thus, it will be easy to test whether this patch broke something.
[1]
https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3
[2]
https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889
Signed-off-by: Tetsuo Handa &
race bugs should no longer
exist. Thus, it will be easy to test whether this patch broke something.
[1]
https://syzkaller.appspot.com/bug?id=f3cfe26e785d85f9ee259f385515291d21bd80a3
[2]
https://syzkaller.appspot.com/bug?id=bf154052f0eea4bc7712499e4569505907d15889
Signed-off-by: Tetsuo Handa
Rep
9f27fd
Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Reported-by: syzbot <syzbot+ae590932da6e45d65...@syzkaller.appspotmail.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: Len Brown <len.br...@intel.com>
Cc: Pavel Machek <pa...@ucw.cz>
---
kernel/power
9f27fd
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Cc: Rafael J. Wysocki
Cc: Len Brown
Cc: Pavel Machek
---
kernel/power/user.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/kernel/power/user.c b/kernel/power/user.c
index 75c959d..abd2255 100644
--- a/kernel/power/user.c
+++ b/kernel
r.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8
Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Reported-by: syzbot <syzbot+18df353d7540aa6b5...@syzkaller.appspotmail.com>
Fixes: bc5a5e3f45d04784 ("n_tty: Don't wrap input buffer indices at buffe
r.appspot.com/bug?id=3d7481a346958d9469bebbeb0537d5f056bdd6e8
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Fixes: bc5a5e3f45d04784 ("n_tty: Don't wrap input buffer indices at buffer
size")
Cc: Peter Hurley
---
drivers/tty/n_tty.c | 13 -
1 file changed, 8 insertions(+
e" loop.
[1]
https://syzkaller.appspot.com/bug?id=17f23b094cd80df750e5b0f8982c521ee6bcbf40
Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Reported-by: syzbot <syzbot+108696293d7a21ab6...@syzkaller.appspotmail.com>
Cc: Peter Hurley <pe...@hurleysoftware.com>
---
drivers/t
e" loop.
[1]
https://syzkaller.appspot.com/bug?id=17f23b094cd80df750e5b0f8982c521ee6bcbf40
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
Cc: Peter Hurley
---
drivers/tty/n_tty.c | 42 --
1 file changed, 24 insertions(+), 18 deletions(-)
diff --git a/drivers/t
David Rientjes wrote:
> The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> it cannot reap an mm. This can happen for a variety of reasons,
> including:
>
> - the inability to grab mm->mmap_sem in a sufficient amount of time,
>
> - when the mm has blockable mmu
David Rientjes wrote:
> The oom reaper ensures forward progress by setting MMF_OOM_SKIP itself if
> it cannot reap an mm. This can happen for a variety of reasons,
> including:
>
> - the inability to grab mm->mmap_sem in a sufficient amount of time,
>
> - when the mm has blockable mmu
Sergey Senozhatsky wrote:
> On (05/17/18 20:21), Sergey Senozhatsky wrote:
> > Dunno...
> > For instance, can we store context tracking info as a extended record
> > data? We have that dict/dict_len thing. So may we can store tracking
> > info there? Extended records will appear on the serial
1001 - 1100 of 3819 matches
Mail list logo
