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
-
Below is a patch for the original problem reported by syzbot
( https://syzkaller.appspot.com/text?tag=CrashLog=11bb246ea0 ).
>From e0758655727044753399fb4f7c5f3eb25ac5cccd Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
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
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
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 inten
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
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
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 as we
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, 15
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:
>>>>>>
://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 100644
--- a/
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 getting
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()
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,
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
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 ->
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
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
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
illed 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
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, blac
, will 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 cha
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()
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.
>
"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 the mai
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 wi
have 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 whe
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
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
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
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
anic) 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/hung_task
, and
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 changed, 20
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=1720cac
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:
>
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)!",
Hello.
We are again getting corrupted reports where message from WARN() is missing.
For example, https://syzkaller.appspot.com/text?tag=CrashLog=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"
?tag=CrashLog=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 threa
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
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
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
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 value.
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:
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 stackable? Tha
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
=" 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 list.
was just a confusion, and I
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
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
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
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:
> >
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
d 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 +++
1 fi
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
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?
>
>
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
>
Hello.
I found a corrupted report at
https://syzkaller.appspot.com/text?tag=CrashLog=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
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
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 propo
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
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
(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__
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
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
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" with min
Forwarding to NMVE people:
kernel test robot found that
flush_work(>async_event_work) is called from nvmet_ctrl_free()
without INIT_WORK(>async_event_work, nvmet_async_event_work)
after ctrl was allocated (probably initialized with 0).
Will you make sure that INIT_WORK() is always called?
On
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 th
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
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
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:
On 2019/02/28 2:02, 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=15336f14c0
> kernel config:
301 - 400 of 3818 matches
Mail list logo
