On 2019/07/01 23:02, Sumit Semwal wrote:
>> Acked-by: Laura Abbott
> fwiw, Acked-by: Sumit Semwal
Thank you for responding. You can carry this patch via whichever tree you like.
By the way, is "memory allocation from ion_system_heap_allocate() is calling
ion_system_heap_shrink()"
(
https://lkm
Andrew, can you pick up this patch? No response from Laura Abbott nor Sumit
Semwal.
On 2019/06/21 18:58, Tetsuo Handa wrote:
> From e0758655727044753399fb4f7c5f3eb25ac5cccd Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Fri, 21 Jun 2019 11:22:51 +0900
> Subject: [PATCH] stag
Andrew, can you pick up this patch? We might miss next merge window, for
Eric Biederman seems to be offline for two weeks.
On 2019/06/14 19:16, Tetsuo Handa wrote:
> syzbot found that a thread can stall for minutes inside kexec_load() after
> that thread was killed by SIGKILL [1]. It turn
On 2019/06/25 17:55, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit e80b18599a39a625bc8b2e39ba3004a62f78805a
> Author: Tetsuo Handa
> Date: Fri Apr 12 11:04:54 2019 +
>
> tomoyo: Add a kernel config option for fuzzing testing.
>
On 2019/06/19 5:49, Al Viro wrote:
> On Sun, Jun 16, 2019 at 03:49:00PM +0900, Tetsuo Handa wrote:
>> Hello, Al.
>>
>> Q1: Do you agree that we should fix TOMOYO side rather than SOCKET_I()->sk
>> management.
>
> You do realize that sockets are not unique
03606e0
Below is a patch for the original problem reported by syzbot
( https://syzkaller.appspot.com/text?tag=CrashLog&x=11bb246ea0 ).
>From e0758655727044753399fb4f7c5f3eb25ac5cccd Mon Sep 17 0
On 2019/06/20 19:10, Yafang Shao wrote:
>>> With this patch, hung task warnings will be reset with
>>> sys_hung_task_warnings setting in evenry check interval.
>>
>> Since it is uncommon that the messages are printed for more than 10
>> times for one check_hung_uninterruptible_tasks() call, this pa
On 2019/06/20 14:55, Yafang Shao wrote:
> When sys_hung_task_warnings reaches 0, the hang task messages will not
> be reported any more.
It is a common mistake that sys_hung_task_warnings is already 0 when
a real problem which should be reported occurred.
>
> If the user want to get more hung ta
On 2019/06/17 15:33, Michal Hocko wrote:
> On Sat 15-06-19 09:11:37, Shakeel Butt wrote:
>> On Sat, Jun 15, 2019 at 6:50 AM Michal Hocko wrote:
> [...]
>>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
>>> index 5a58778c91d4..43eb479a5dc7 100644
>>> --- a/mm/oom_kill.c
>>> +++ b/mm/oom_kill.c
>>> @@
On 2019/06/16 16:37, Tetsuo Handa wrote:
> On 2019/06/16 6:33, Tetsuo Handa wrote:
>> On 2019/06/16 3:50, Shakeel Butt wrote:
>>>> While dump_tasks() traverses only each thread group,
>>>> mem_cgroup_scan_tasks()
>>>> traverses each thread.
>&
On 2019/06/16 6:33, Tetsuo Handa wrote:
> On 2019/06/16 3:50, Shakeel Butt wrote:
>>> While dump_tasks() traverses only each thread group, mem_cgroup_scan_tasks()
>>> traverses each thread.
>>
>> I think mem_cgroup_scan_tasks() traversing threads is not intentional
Hello, Al.
Q1: Do you agree that we should fix TOMOYO side rather than SOCKET_I()->sk
management.
Q2: Do you see any problem with using f->f_path.dentry->d_inode ?
Do we need to use d_backing_inode() or d_inode() ?
Regards.
On 2019/06/09 15:41, Tetsuo Handa wrote:
> syzbot
On 2019/06/16 3:50, Shakeel Butt wrote:
>> While dump_tasks() traverses only each thread group, mem_cgroup_scan_tasks()
>> traverses each thread.
>
> I think mem_cgroup_scan_tasks() traversing threads is not intentional
> and css_task_iter_start in it should use CSS_TASK_ITER_PROCS as the
> oom ki
On 2019/06/16 1:11, Shakeel Butt wrote:
> On Sat, Jun 15, 2019 at 6:50 AM Michal Hocko wrote:
>> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
>> index 5a58778c91d4..43eb479a5dc7 100644
>> --- a/mm/oom_kill.c
>> +++ b/mm/oom_kill.c
>> @@ -161,8 +161,8 @@ static bool oom_unkillable_task(struct task_st
On 2019/06/15 10:10, Tetsuo Handa wrote:
> I'm not sure this patch is correct/safe. Can you try memcg OOM torture
> test (including memcg group OOM killing enabled) with this patch applied?
Well, I guess this patch was wrong. The ordering of removing threads
does not matter as long
I'm not sure this patch is correct/safe. Can you try memcg OOM torture
test (including memcg group OOM killing enabled) with this patch applied?
>From a436624c73d106fad9b880a6cef5abd83b2329a2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat
emory
allocation.
[1]
https://syzkaller.appspot.com/bug?id=a0e3436829698d5824231251fad9d8e998f94f5e
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
---
kernel/kexec_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index fd5c95f..2b25d95 100644
On 2019/06/12 0:10, Petr Mladek wrote:
> On Sat 2019-06-08 11:45:45, Tetsuo Handa wrote:
>> On 2019/06/08 2:09, Pavel Machek wrote:
>>> On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
>>>> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
>>>>>> You
[1]
https://syzkaller.appspot.com/bug?id=73d590010454403d55164cca23bd0565b1eb3b74
Signed-off-by: Tetsuo Handa
Reported-by: syzbot
---
security/tomoyo/tomoyo.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/security/tomoyo/tomoyo.c b/security/tomoyo/tomoyo.c
index 716c92e..9661b86 100
On 2019/06/08 2:09, Pavel Machek wrote:
> On Tue 2019-05-28 19:15:43, Tetsuo Handa wrote:
>> On 2019/05/28 17:51, Sergey Senozhatsky wrote:
>>>> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit
>>>> printk
>>>> context i
Tetsuo Handa wrote:
> The problem is that TOMOYO is accessing already freed socket from
> security_file_open()
> which later fails with -ENXIO (because we can't get file descriptor of
> sockets via
> /proc/pid/fd/n interface), and the file descriptor is get
Here is a reproducer.
The problem is that TOMOYO is accessing already freed socket from
security_file_open()
which later fails with -ENXIO (because we can't get file descriptor of sockets
via
/proc/pid/fd/n interface), and the file descriptor is getting released before
security_file_open() compl
Hello, Al.
syzbot found that SOCKET_I(d_backing_inode("struct path"->dentry))->sk
was already kfree()d when trying to calculate pathname for open().
"struct path"->dentry should remain valid but portion of memory
reachable via inode already became invalid. What should we do?
On 2019/06/06 3:42, s
On 2019/05/28 22:42, Petr Mladek wrote:
> On Tue 2019-05-28 13:46:19, Sergey Senozhatsky wrote:
>> On (05/28/19 13:15), Sergey Senozhatsky wrote:
>>> On (05/28/19 01:24), Dmitry Safonov wrote:
>>> [..]
While handling sysrq the console_loglevel is bumped to default to print
sysrq headers.
On 2019/05/29 0:03, Petr Mladek wrote:
>> But is context dependent buffer large enough to hold SysRq-t output?
>> I think that only main logbuf can become large enough to hold SysRq-t output.
>
> SysRq messages are stored directly into the main log buffer.
>
> The limited per-CPU buffers are need
On 2019/05/28 22:42, Petr Mladek wrote:
>> Ahh.. OK, now I sort of remember why I gave up on this idea (see [1]
>> at the bottom, when it comes to uv_nmi_dump_state()) - printk_NMI and
>> printk-safe redirections.
>>
>> NMI
>> loglevel = NEW
>> printk -> printk_safe_n
On 2019/05/28 17:51, Sergey Senozhatsky wrote:
>> You are trying to omit passing KERN_UNSUPPRESSED by utilizing implicit printk
>> context information. But doesn't such attempt resemble find_printk_buffer() ?
>
> Adding KERN_UNSUPPRESSED to all printks down the op_p->handler()
> line is hardly pos
On 2019/05/28 13:22, Sergey Senozhatsky wrote:
> On (05/28/19 12:21), Tetsuo Handa wrote:
> [..]
>> What I suggested in my proposal ("printk: Introduce "store now but print
>> later" prefix." at
>> https://lore.kernel.org/lkml/1550896930-12324-1-git-sen
Well, I don't think this is a TOMOYO's problem.
On 2019/05/28 14:48, syzbot wrote:
> CPU: 1 PID: 11697 Comm: syz-executor.3 Not tainted 5.2.0-rc1+ #2
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Call Trace:
(...snipped...)
> kfree+0xcf/0x220 mm/
On 2019/05/28 9:24, Dmitry Safonov wrote:
> Provide KERN_UNSUPPRESSED printk() annotation for such legacy places.
> Make sysrq print the headers unsuppressed instead of changing
> console_loglevel.
I think that kdb also wants to use KERN_UNSUPPRESSED for making sure
that messages are printed. But
or
monitoring killed threads. But let's start as linux-next.git patch
without introducing new sysctl settings. We can add sysctl settings
before sending to linux.git.
Signed-off-by: Tetsuo Handa
Cc: Dmitry Vyukov
---
include/linux/sched.h | 1 +
kernel/hung_task.c| 44 +++
On 2019/05/25 2:17, Linus Torvalds wrote:
> A config option or two that help syzbot doesn't sound like a bad idea to me.
Thanks for suggestion. I think that #ifdef'ing
static bool suppress_message_printing(int level)
{
return (level >= console_loglevel && !ignore_loglevel);
}
is si
On 2019/05/24 16:55, Dmitry Vyukov wrote:
> On Thu, May 23, 2019 at 11:57 AM Tetsuo Handa
> wrote:
>>
>> Well, the culprit of this problem might be syz_execute_func().
>>
>> https://twitter.com/ed_maste/status/1131165065485398016
>>
>> Then, blacklis
you send this patch to linux-next.git ?
syzbot would identify which syz_execute_func() call is triggering
this problem.
>From 96e0741839f56c461f85d83e20bf5ae6baac9a3a Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Thu, 23 May 2019 05:57:52 +0900
Subject: [PATCH] printk: Monitor change
Andrew Morton wrote:
> On Thu, 23 May 2019 07:39:25 +1000 Stephen Rothwell
> wrote:
>
> > > I put an example patch into my subversion repository:
> > >
> > > svn checkout
> > > https://svn.osdn.net/svnroot/tomoyo/branches/syzbot-patches/
> > >
> > > To fetch up-to-date debug printk() patche
On 2019/05/22 23:58, Tetsuo Handa wrote:
> On 2019/05/22 22:41, Stephen Rothwell wrote:
>> Hi Tetsuo,
>>
>> On Wed, 22 May 2019 21:38:45 +0900 Tetsuo Handa
>> wrote:
>>>
>>> I want to send debug printk() patches to linux-next.git. Petr Mladek
>
On 2019/05/22 22:41, Stephen Rothwell wrote:
> Hi Tetsuo,
>
> On Wed, 22 May 2019 21:38:45 +0900 Tetsuo Handa
> wrote:
>>
>> I want to send debug printk() patches to linux-next.git. Petr Mladek
>> is suggesting me to have a git tree for debug printk() patches.
>
nding "git pull"
requests. Therefore, just ignoring "git quiltimport" failure is fine.
What do you think?
On 2019/05/16 21:38, Tetsuo Handa wrote:
> On 2019/05/16 20:57, Petr Mladek wrote:
>> CCed Stephen to discuss linux-next related question at the bottom
>> of th
On 2019/05/16 22:19, Alexander Potapenko wrote:
>> commit e6193f78bb689f3f424559bb45f4a091c8b314df
>> Author: Tetsuo Handa
>> Date: Fri Apr 12 19:59:36 2019 +0900
>>
>> tomoyo: Check address length before reading address family
>>
>> KMSAN will
ave any reproducer for this crash yet.
This should be already fixed in linux.git.
#syz fix: tomoyo: Check address length before reading address family
commit e6193f78bb689f3f424559bb45f4a091c8b314df
Author: Tetsuo Handa
Date: Fri Apr 12 19:59:36 2019 +0900
tomoyo: Check address length b
On 2019/05/16 20:57, Petr Mladek wrote:
> CCed Stephen to discuss linux-next related question at the bottom
> of the mail.
>
> On Thu 2019-05-16 17:19:12, Tetsuo Handa wrote:
>> On 2019/05/15 19:55, Petr Mladek wrote:
>> But in the context of syzbot's testing where th
On 2019/05/15 19:55, Petr Mladek wrote:
>> +if (!stamp) {
>> +stamp = jiffies;
>> +if (!stamp)
>> +stamp++;
>> +t->killed_time = stamp;
>> +return;
>> +}
>
> I might be too dumb but the above code looks pretty tricky to me
On 2019/05/14 18:19, Sergey Senozhatsky wrote:
> On (05/11/19 00:19), Tetsuo Handa wrote:
>> We are seeing syzbot reports [1] where printk() messages prior to panic()
>> are missing for unknown reason. To test whether it is due to some testcase
>> changing console loglevel,
On 2019/05/15 19:21, Jan Kara wrote:
> The question is how to fix this problem. The simplest fix I can see is that
> we'd just refuse to do LOOP_SET_FD if someone has the block device
> exclusively open as there are high chances such user will be unpleasantly
> surprised by the device changing unde
Since lo_ioctl() is calling sb_set_blocksize() immediately after udf_load_vrs()
called sb_set_blocksize(), udf_tread() can't use expected i_blkbits settings...
[ 48.685672][ T7322] fs/block_dev.c:135 bdev=14fa0ec2 12 -> 9
[ 48.694675][ T7322] CPU: 4 PID: 7322 Comm: a.out Not tainted 5.
Hello, Jan.
syzbot is still reporting livelocks inside __getblk_gfp() [1] (similar to
commit 04906b2f542c2362 ("blockdev: Fix livelocks on loop device")).
[1]
https://syzkaller.appspot.com/bug?id=835a0b9e75b14b55112661cbc61ca8b8f0edf767
A debug printk() patch shown below revealed that since b
to panic) used for detecting TASK_UNINTERRUPTIBLE
threads, for I don't know whether people want to use a new kernel
config option and different sysctl settings for monitoring killed
threads.
Signed-off-by: Tetsuo Handa
Cc: Dmitry Vyukov
---
include/linux/sched.h | 1 +
kernel
will be removed after we found what is wrong.
[1]
https://lkml.kernel.org/r/127c9c3b-f878-174f-7065-66dc50fca...@i-love.sakura.ne.jp
Signed-off-by: Tetsuo Handa
Cc: Dmitry Vyukov
Cc: Sergey Senozhatsky
Cc: Petr Mladek
---
kernel/printk/printk.c | 20
1 file change
On 2019/05/10 23:12, Petr Mladek wrote:
> On Wed 2019-05-08 19:31:06, Tetsuo Handa wrote:
>> Hello.
>>
>> We are again getting corrupted reports where message from WARN() is missing.
>> For example,
>> https://syzkaller.appspot.com/text?tag=CrashLog&x=1720ca
On 2019/05/09 19:18, Sergey Senozhatsky wrote:
> What are these lines right before the kernel panic output?
> TTY writes (user space logging)?
I guess that the user space is calling printf() on stdout
which will be readable as console output.
>
>
> 03:54:05 executing program 5:
> syz_mount_imag
On 2019/05/09 18:58, Sergey Senozhatsky wrote:
>> +#ifdef CONFIG_DEBUG_AID_FOR_SYZBOT
>> +static int initial_loglevel;
>> +static void check_loglevel(struct timer_list *timer)
>> +{
>> +if (console_loglevel < initial_loglevel)
>> +panic("Console loglevel changed (%d->%d)!", initial_
Hello.
We are again getting corrupted reports where message from WARN() is missing.
For example, https://syzkaller.appspot.com/text?tag=CrashLog&x=1720cac8a0
was
titled as "WARNING in cgroup_exit" because the
"WARNING: CPU: 0 PID: 7870 at kernel/cgroup/cgroup.c:6008
cgroup_exit+0x51a/0x5d0"
.com/text?tag=CrashLog&x=135ff034a0
On 2019/04/29 20:52, Tetsuo Handa wrote:
> Since trigger_all_cpu_backtrace() uses NMI interface, printk() from other
> CPUs are called from interrupt context. Therefore, CONFIG_PRINTK_CALLER=y
> needlessly separates printk() from khungtaskd kernel
On 2019/05/01 0:34, Tetsuo Handa wrote:
> I still cannot understand what the problem is.
(...snipped...)
> I guessed that something went wrong with 8083 inside __getblk_gfp().
> How can loop_ctl_mutex be relevant to this problem?
>
syzbot got similar NMI backtrace. No loop_ctl_mutex
On 2019/05/03 1:28, Casey Schaufler wrote:
> On 5/2/2019 8:48 AM, Mimi Zohar wrote:
>> [Cc'ing Paul, John, Casey]
>>
>> On Mon, 2019-04-22 at 20:18 -0400, Mimi Zohar wrote:
>>> [Cc'ing LSM mailing list]
>>>
>>> On Fri, 2019-04-19 at 17:30 -0700, prakhar srivastava wrote:
>>>
2) Adding a LSM ho
On 2019/05/01 0:07, Jan Kara wrote:
> Ah, right. I've missed that in your patch. So your patch should be really
> fixing the problem. Will you post it officially? Thanks!
I still cannot understand what the problem is.
According to console output,
--
INFO: task syz-executor274:8097 blocked
threads (except khungtaskd kernel thread itself) which
are on the scheduler using task traversal approach. This allows syzbot to
include backtrace of running threads into its report files.
Signed-off-by: Tetsuo Handa
---
kernel/hung_task.c | 19 ++-
1 file changed, 18 insertions(+), 1
On 2019/04/29 3:51, Al Viro wrote:
> ioctl(..., BLKRRPART) blocked on ->s_umount in __get_super().
> The trouble is, the only things holding ->s_umount appears to be
> these:
Not always true. lockdep_print_held_locks() from debug_show_all_locks() can not
report locks held by TASK_RUNNING threads.
On 2019/04/11 10:43, Suren Baghdasaryan wrote:
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 3a2484884cfd..6449710c8a06 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -1102,6 +1102,21 @@ bool out_of_memory(struct oom_control *oc)
> return !!oc->chosen;
> }
>
> +bool expedit
On 2019/04/25 2:08, Greg Kroah-Hartman wrote:
> [ Upstream commit 71492580571467fb7177aade19c18ce7486267f5 ]
>
> Tetsuo Handa had reported he saw an incorrect "downgrading a read lock"
> warning right after a previous lockdep warning. It is likely that the
> previou
On 2019/03/30 20:09, Borislav Petkov wrote:
> On Sat, Mar 30, 2019 at 07:57:50PM +0900, Tetsuo Handa wrote:
>> Yes. But what such threshold be? 0.1 second? 1 second? 10 seconds?
>> Can we find a threshold where everyone can agree on?
>
> This is what we do all day on lkml:
On 2019/03/30 19:45, Borislav Petkov wrote:
> On Sat, Mar 30, 2019 at 07:40:11PM +0900, Tetsuo Handa wrote:
>> But how can the scheduler be aware of various watchdogs' thresholds?
>
> I think what tglx means is sched_setattr() should be fixed to fail due
> to the bogus v
On 2019/03/30 16:46, Thomas Gleixner wrote:
> On Sat, 30 Mar 2019, Tetsuo Handa wrote:
>> This reproducer does sched_setattr(SCHED_DEADLINE) with bogus value, as with
>> a reproducer for "INFO: rcu detected stall in sys_sendfile64" did.
>>
>> sched
On 2019/03/30 7:34, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 8c2ffd91 Linux 5.1-rc2
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=15099d2b20
> kernel config: https://syzkaller.appspot.com/x/.config?x=8dcdce25
On 2019/03/30 4:36, Kees Cook wrote:
> Note that since TOMOYO can be fully stacked against the other legacy
> major LSMs, when it is selected, it explicitly disables the other LSMs
> to avoid them also initializing since TOMOYO does not expect this
> currently.
Excuse me, but isn't this exception
On 2019/03/28 6:43, Kees Cook wrote:
>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>> situation where this is not true?
>>
>> There should be no problem except some TOMOYO messages are printed.
>
>
On 2019/03/28 5:45, Kees Cook wrote:
> On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
> wrote:
>>
>> On 2019/03/28 4:16, Kees Cook wrote:
>>> The part I don't understand is what you've said about TOMOYO being
>>> primary and not wanting the others stac
On 2019/03/28 4:16, Kees Cook wrote:
> The part I don't understand is what you've said about TOMOYO being
> primary and not wanting the others stackable? That kind of goes
> against the point, but I'm happy to do that if you want it that way.
Automatically enabling multiple legacy major LSMs might
rd-compat for the "security=" line. If a system is
booted with CONFIG_LSM="minors...,apparmor" and "security=selinux",
neither apparmor nor selinux will be initialized. The logic on
"security=..." depends on the other LSMs being present in the
On 2019/03/23 7:45, Kees Cook wrote:
> It breaks the backward-compat for the "security=" line. If a system is
> booted with CONFIG_LSM="minors...,apparmor" and "security=selinux",
> neither apparmor nor selinux will be initialized. The logic on
> "security=..." depends on the other LSMs being prese
On 2019/03/22 1:38, Kees Cook wrote:
> This is mostly good. I'd like to keep the other LSMs listed though
> (similar to what I had originally) so that if a legacy-major doesn't
> initialize, later ones will be. I want to remove the concept of
> "major" LSMs. The only thing that should matter is ini
On 2019/03/21 0:25, Petr Mladek wrote:
>> This requires serialization among threads using "rs". I already
>> proposed ratelimit_reset() for memcg's OOM problem at
>> https://lkml.kernel.org/r/201810180246.w9i2koi3011...@www262.sakura.ne.jp
>> but it was not accepted.
>
> IMHO, the main problem was
Since Kees Cook seems to be busy now, here is my version...
>From 885553e4793d9af2d4e9e99c7d137b0ec7b5f8ad Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Tue, 19 Mar 2019 19:52:31 +0900
Subject: [PATCH] LSM: Revive CONFIG_DEFAULT_SECURITY_* for "make oldconfig"
Commit 70b
Dmitry Vyukov wrote:
> On Mon, Mar 18, 2019 at 1:32 PM Dmitry Vyukov wrote:
> > Wait, but isn't SYSLOG_ACTION_CONSOLE_LEVEL what we are looking for?
> > syzkaller knows about the syslog syscall:
> > https://github.com/google/syzkaller/blob/13026d10f09f0e801c342e6c009ff580d49b894b/sys/linux/sys.txt
console_silent() is no longer used after the removal of
arch/mn10300/kernel/mn10300-watchdog.c in Linux 4.17-rc1.
Signed-off-by: Tetsuo Handa
---
include/linux/printk.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index d7c77ed..65b6d4f
Dmitry Vyukov wrote:
> > Then, we need to find what test is changing console_loglevel.
> > Maybe add debug BUG_ON() in linux-next.git using
> > CONFIG_DEBUG_AID_FOR_SYZBOT ?
>
> Is there a single place to catch this? I could run syzkaller locally
> first with the check.
>
There is no such place
7;t be triggered twice.
[1]
https://syzkaller.appspot.com/bug?id=8b17c134fe938bbddd75a45afaa9e68af43a362d
Reported-by: syzbot
Analyzed-by: Dmitry Torokhov
Fixes: 0f4dafc0563c6c49 ("Kobject: auto-cleanup on final unref")
Cc: Kay Sievers
Signed-off-by: Tetsuo Handa
---
lib/kobject_uevent.c | 11 ++
On 2019/03/16 23:57, Dmitry Vyukov wrote:
> On Sat, Mar 16, 2019 at 3:53 PM Tetsuo Handa
> wrote:
>>
>> On 2019/03/16 23:16, Dmitry Vyukov wrote:
>>>>> Maybe try running with "ignore_loglevel" kernel command line option added?
>>>>
>>
On 2019/03/16 23:16, Dmitry Vyukov wrote:
>>> Maybe try running with "ignore_loglevel" kernel command line option added?
>>
>> Right, that's something I would expect 0-day and syzkaller to do.
>
> to double-check: enabling this won't lead to verbose/debug level of logging?
>
I don't know what "v
On 2019/03/16 18:11, Dmitry Vyukov wrote:
> Such reports showed up always with low frequency. For all that I
> looked at we also always had a normal non-truncated version, so I was
> never too worried.
>
> If something would write from userspace, that would show up in the
> output, or not?
>
> P
On 2019/03/16 14:38, Kees Cook wrote:
> config LSM
> string "Ordered list of enabled LSMs"
> + default
> "yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor" if
> DEFAULT_SECURITY_SMACK
> + default
> "yama,loadpin,safesetid,integrity,tomoyo,selinux,smack,apparmor
Hello.
I found a corrupted report at
https://syzkaller.appspot.com/text?tag=CrashLog&x=17c6b82b20 .
The panic() was caused by by WARN_ON() from generic_make_request_checks(), but
there
was no printk() messages from WARN_ON(). Moreover, there was no printk()
messages
for (at least) nearly o
On 2019/03/16 6:00, Kangjie Lu wrote:
> securityfs_create_file may fail. The fix checks its status and
> returns the error code upstream if it fails.
Failure in __init functions of vmlinux means that the system failed
before the global /sbin/init process starts. There is little value
with continu
On 2019/03/07 3:24, Tetsuo Handa wrote:
> On 2019/03/06 19:04, Petr Mladek wrote:
> I'm planning to allow any shared functions which can be called from e.g.
> warn_alloc(), out_of_memory(), SysRq-t by allowing such shared functions
> to accept loglevel argument.
Calvin Owens is
On 2019/03/15 5:42, Alexey Dobriyan wrote:
> PTR_ERR((void *)map_addr) == -EEXIST
>
> is a very complicated way of doing the obvious.
Michal suggested me to explicitly use PTR_ERR() for documentation purpose in
a reply mail to https://lkml.kernel.org/r/20180418115546.gz17...@dhcp22.suse.cz
Petr Mladek wrote:
> It might be even more straightforward when the per-console value
> defines the effective console level. I mean the following semantic:
>
>+ "console_loglevel" would define the default loglevel used
> by consoles at runtime.
>
>+ the per-console loglevel could ove
On 2019/03/14 8:40, Eric Biggers wrote:
> On Wed, Mar 13, 2019 at 07:43:38AM +0100, 'Dmitry Vyukov' via syzkaller-bugs
> wrote:
>>> Also, humans can sometimes find more simpler C reproducers from syzbot
>>> provided
>>> reproducers. It would be nice if syzbot can accept and use a user defined C
>
On 2019/03/13 2:15, Dmitry Vyukov wrote:
>> Also, this bisection is finding multiple different crash patterns, which
>> suggests that the crashed tests are not giving correct feedback to syzbot.
>
> Treating different crashes as just "crash" is intended. Kernel bugs
> can manifest in very differen
(Moving most recipients to bcc: in order to avoid flooding.)
On 2019/03/12 13:08, Al Viro wrote:
> Umm... Might be a good idea to add some plausibility filters - it is,
> in theory, possible that adding a line in a comment changes behaviour
> (without compiler bugs, even - playing with __LINE__ i
F.Y.I. Nothing is wrong with that commit. That commit merely allows enabling
TOMOYO and
one of SELinux/Smack/AppArmor at the same time for syzbot's kernel command line
options.
This problem will be handled by a patch at
https://lore.kernel.org/linux-security-module/1551362770-8655-1-git-send-emai
Commit b30b61ff6b1dc37f in linux-next.git did not get in time for closing
previous report. I assume that a pull request will be sent shortly from
Daniel Vetter.
#syz fix: drm/vkms: Fix flush_work() without INIT_WORK().
On 2019/03/06 19:04, Petr Mladek wrote:
>> I'm suggesting to use a non-async printk() for $trailer_text_line line. I
>> think
>> that changing all printk() called from out_of_memory() to async is doable, if
>> the caller of out_of_memory() wakes up a dedicated kthread described below.
>
> This is
Petr Mladek wrote:
> On Mon 2019-03-04 20:40:37, Tetsuo Handa wrote:
> > On 2019/03/04 12:22, Sergey Senozhatsky wrote:
> > > On (02/23/19 13:42), Tetsuo Handa wrote:
> > > [..]
> > >> This patch tries to address "don't lockup the system" wit
Forwarding to NMVE people:
kernel test robot found that
flush_work(&ctrl->async_event_work) is called from nvmet_ctrl_free()
without INIT_WORK(&ctrl->async_event_work, nvmet_async_event_work)
after ctrl was allocated (probably initialized with 0).
Will you make sure that INIT_WORK() is always call
On 2019/03/04 12:22, Sergey Senozhatsky wrote:
> On (02/23/19 13:42), Tetsuo Handa wrote:
> [..]
>> This patch tries to address "don't lockup the system" with minimal risk of
>> failing to "print out printk() messages", by allowing printk() callers to
>
Can this patch go to Linux 5.1?
On 2019/02/22 18:59, Tetsuo Handa wrote:
> When commit 5becfb1df5ac8e49 ("kmsg: merge continuation records while
> printing") introduced LOG_PREFIX, we used KERN_DEFAULT etc. as a flag
> for setting LOG_PREFIX in order to tell whether to cal
On 2019/02/28 19:58, Tetsuo Handa wrote:
> But the problem is that since syzbot is automated, there is no chance to
> edit the content of security/tomoyo/policy/ directory when building the
> kernels.
Thinking again, I realized that it would be possible to automatically
generate the c
On 2019/02/28 19:23, Dmitry Vyukov wrote:
> On Thu, Feb 28, 2019 at 11:20 AM Tetsuo Handa
> wrote:
>>
>> On 2019/02/28 15:51, Dmitry Vyukov wrote:
>>> On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
>>>>
>>>> Thank you. The LSM stacking seems to b
On 2019/02/28 15:51, Dmitry Vyukov wrote:
> On Wed, Feb 27, 2019 at 11:37 PM Tetsuo Handa
>>
>> Thank you. The LSM stacking seems to be working as expected.
>> But this one should not be considered as a bug.
>>
>> If something went wrong before loading access con
On 2019/02/28 15:42, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 7b827ff9af88 Add linux-next specific files for 20190227
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=10f71894c0
> kernel config: https://syzkal
301 - 400 of 1464 matches
Mail list logo