Message ID | 20200628070057.820213-1-ebiggers@kernel.org (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | reiserfs: only call unlock_new_inode() if I_NEW | expand |
On Sun, Jun 28, 2020 at 12:00:57AM -0700, Eric Biggers wrote: > From: Eric Biggers <ebiggers@google.com> > > unlock_new_inode() is only meant to be called after a new inode has > already been inserted into the hash table. But reiserfs_new_inode() can > call it even before it has inserted the inode, triggering the WARNING in > unlock_new_inode(). Fix this by only calling unlock_new_inode() if the > inode has the I_NEW flag set, indicating that it's in the table. > > This addresses the syzbot report "WARNING in unlock_new_inode" > (https://syzkaller.appspot.com/bug?extid=187510916eb6a14598f7). > > Reported-by: syzbot+187510916eb6a14598f7@syzkaller.appspotmail.com > Signed-off-by: Eric Biggers <ebiggers@google.com> Anyone interested in taking this patch? - Eric
On Mon, Jul 27, 2020 at 09:52:15AM -0700, Eric Biggers wrote: > On Sun, Jun 28, 2020 at 12:00:57AM -0700, Eric Biggers wrote: > > From: Eric Biggers <ebiggers@google.com> > > > > unlock_new_inode() is only meant to be called after a new inode has > > already been inserted into the hash table. But reiserfs_new_inode() can > > call it even before it has inserted the inode, triggering the WARNING in > > unlock_new_inode(). Fix this by only calling unlock_new_inode() if the > > inode has the I_NEW flag set, indicating that it's in the table. > > > > This addresses the syzbot report "WARNING in unlock_new_inode" > > (https://syzkaller.appspot.com/bug?extid=187510916eb6a14598f7). > > > > Reported-by: syzbot+187510916eb6a14598f7@syzkaller.appspotmail.com > > Signed-off-by: Eric Biggers <ebiggers@google.com> > > Anyone interested in taking this patch? Jan, you seem to be taking some reiserfs patches... Any interest in taking this one? - Eric
On Tue 15-09-20 21:01:18, Eric Biggers wrote: > On Mon, Jul 27, 2020 at 09:52:15AM -0700, Eric Biggers wrote: > > On Sun, Jun 28, 2020 at 12:00:57AM -0700, Eric Biggers wrote: > > > From: Eric Biggers <ebiggers@google.com> > > > > > > unlock_new_inode() is only meant to be called after a new inode has > > > already been inserted into the hash table. But reiserfs_new_inode() can > > > call it even before it has inserted the inode, triggering the WARNING in > > > unlock_new_inode(). Fix this by only calling unlock_new_inode() if the > > > inode has the I_NEW flag set, indicating that it's in the table. > > > > > > This addresses the syzbot report "WARNING in unlock_new_inode" > > > (https://syzkaller.appspot.com/bug?extid=187510916eb6a14598f7). > > > > > > Reported-by: syzbot+187510916eb6a14598f7@syzkaller.appspotmail.com > > > Signed-off-by: Eric Biggers <ebiggers@google.com> > > > > Anyone interested in taking this patch? > > Jan, you seem to be taking some reiserfs patches... Any interest in > taking this one? Sure, the patch looks good to me so I've added it to my tree. Thanks! Honza
diff --git a/fs/reiserfs/inode.c b/fs/reiserfs/inode.c index 1509775da040..e3af44c61524 100644 --- a/fs/reiserfs/inode.c +++ b/fs/reiserfs/inode.c @@ -2163,7 +2163,8 @@ int reiserfs_new_inode(struct reiserfs_transaction_handle *th, out_inserted_sd: clear_nlink(inode); th->t_trans_id = 0; /* so the caller can't use this handle later */ - unlock_new_inode(inode); /* OK to do even if we hadn't locked it */ + if (inode->i_state & I_NEW) + unlock_new_inode(inode); iput(inode); return err; }