Re: Linux 5.19-rc2

[Jan Kara]

On Tue 14-06-22 10:03:16, Guenter Roeck wrote:
> On Mon, Jun 13, 2022 at 08:46:42AM -0700, Guenter Roeck wrote:
> > 
> > There are also various UAF and "spinlock bad magic" BUG/WARNING logs in arm
> > boot tests. I don't know if those are new or if I just see them now because
> > I enabled KFENCE. Here is an (incomplete) sample.
> > 
> > [    0.430290] printk: console [ramoops-1] printing thread started
> > [    0.436219] BUG: spinlock bad magic on CPU#0, kdevtmpfs/23
> > [    0.436250]  lock: noop_backing_dev_info+0x6c/0x3b0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> > [    0.436808] CPU: 0 PID: 23 Comm: kdevtmpfs Not tainted 5.19.0-rc2 #1
> > 
> 
> This is caused by commit 10e14073107dd0 ("writeback: Fix inode->i_io_list
> not be protected by inode->i_lock error"). Reverting this commit fixes
> the problem. Here is a complete backtrace:

Yeah, I've already queued a fix into my tree, I'll send it to Linus
tomorrow. With kdevtmpfs inode gets dirtied before noop_backing_dev_info is
initialized...

								Honza

> 
> BUG: spinlock bad magic on CPU#0, kdevtmpfs/16
>  lock: noop_backing_dev_info+0x6c/0x3b0, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
> CPU: 0 PID: 16 Comm: kdevtmpfs Not tainted 5.19.0-rc2-00001-g8bd0807eb95c #1
> Hardware name: ARM RealView Machine (Device Tree Support)
>  unwind_backtrace from show_stack+0x10/0x14
>  show_stack from dump_stack_lvl+0x68/0x90
>  dump_stack_lvl from do_raw_spin_lock+0xa8/0xf4
>  do_raw_spin_lock from __mark_inode_dirty+0x1a4/0x664
>  __mark_inode_dirty from simple_setattr+0x44/0x5c
>  simple_setattr from notify_change+0x404/0x460
>  notify_change from devtmpfsd+0x1ec/0x2b8
>  devtmpfsd from kthread+0xe0/0x104
>  kthread from ret_from_fork+0x14/0x24
> Exception stack(0xe0851fb0 to 0xe0851ff8)
> 1fa0:                                     00000000 00000000 00000000 00000000
> 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
> 
> Guenter
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR