Some code paths cannot guarantee the inode have any dentry alias. So
WARN_ON() all !dentry may flood the kernel logs.
For example, when an overlayfs inode is watched by inotifywait (1), and
someone is trying to read the /proc/$(pidof inotifywait)/fdinfo/INOTIFY_FD,
at that time if the dentry has been reclaimed by kernel (such as
echo 2 > /proc/sys/vm/drop_caches), there will be a WARN_ON(). The
printed call stack would be like:
? show_mark_fhandle+0xf0/0xf0
show_mark_fhandle+0x4a/0xf0
? show_mark_fhandle+0xf0/0xf0
? seq_vprintf+0x30/0x50
? seq_printf+0x53/0x70
? show_mark_fhandle+0xf0/0xf0
inotify_fdinfo+0x70/0x90
show_fdinfo.isra.4+0x53/0x70
seq_show+0x130/0x170
seq_read+0x153/0x440
vfs_read+0x94/0x150
ksys_read+0x5f/0xe0
do_syscall_64+0x59/0x1e0
entry_SYSCALL_64_after_hwframe+0x44/0xa9
So let's replace WARN_ON() with WARN_ON_ONCE() to avoid kernel log
flooding.
Reported-by: Hongbo Yin <[email protected]>
Signed-off-by: Jiachen Zhang <[email protected]>
Signed-off-by: Tianci Zhang <[email protected]>
---
fs/overlayfs/export.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/overlayfs/export.c b/fs/overlayfs/export.c
index 2eada97bbd23..3a8650442aec 100644
--- a/fs/overlayfs/export.c
+++ b/fs/overlayfs/export.c
@@ -259,7 +259,7 @@ static int ovl_encode_fh(struct inode *inode, u32 *fid, int *max_len,
return FILEID_INVALID;
dentry = d_find_any_alias(inode);
- if (WARN_ON(!dentry))
+ if (WARN_ON_ONCE(!dentry))
return FILEID_INVALID;
bytes = ovl_dentry_to_fid(ofs, dentry, fid, buflen);
--
2.20.1
On Thu, 28 Jul 2022 at 08:39, Jiachen Zhang
<[email protected]> wrote:
>
> Some code paths cannot guarantee the inode have any dentry alias. So
> WARN_ON() all !dentry may flood the kernel logs.
>
> For example, when an overlayfs inode is watched by inotifywait (1), and
> someone is trying to read the /proc/$(pidof inotifywait)/fdinfo/INOTIFY_FD,
> at that time if the dentry has been reclaimed by kernel (such as
> echo 2 > /proc/sys/vm/drop_caches), there will be a WARN_ON(). The
> printed call stack would be like:
>
> ? show_mark_fhandle+0xf0/0xf0
> show_mark_fhandle+0x4a/0xf0
> ? show_mark_fhandle+0xf0/0xf0
> ? seq_vprintf+0x30/0x50
> ? seq_printf+0x53/0x70
> ? show_mark_fhandle+0xf0/0xf0
> inotify_fdinfo+0x70/0x90
> show_fdinfo.isra.4+0x53/0x70
> seq_show+0x130/0x170
> seq_read+0x153/0x440
> vfs_read+0x94/0x150
> ksys_read+0x5f/0xe0
> do_syscall_64+0x59/0x1e0
> entry_SYSCALL_64_after_hwframe+0x44/0xa9
>
> So let's replace WARN_ON() with WARN_ON_ONCE() to avoid kernel log
> flooding.
Better just drop the WARN_ON() completely in that case, since it's a
normally occurring condition.
Thanks,
Miklos
On Thu, Jul 28, 2022 at 4:57 PM Miklos Szeredi <[email protected]> wrote:
>
> On Thu, 28 Jul 2022 at 08:39, Jiachen Zhang
> <[email protected]> wrote:
> >
> > Some code paths cannot guarantee the inode have any dentry alias. So
> > WARN_ON() all !dentry may flood the kernel logs.
> >
> > For example, when an overlayfs inode is watched by inotifywait (1), and
> > someone is trying to read the /proc/$(pidof inotifywait)/fdinfo/INOTIFY_FD,
> > at that time if the dentry has been reclaimed by kernel (such as
> > echo 2 > /proc/sys/vm/drop_caches), there will be a WARN_ON(). The
> > printed call stack would be like:
> >
> > ? show_mark_fhandle+0xf0/0xf0
> > show_mark_fhandle+0x4a/0xf0
> > ? show_mark_fhandle+0xf0/0xf0
> > ? seq_vprintf+0x30/0x50
> > ? seq_printf+0x53/0x70
> > ? show_mark_fhandle+0xf0/0xf0
> > inotify_fdinfo+0x70/0x90
> > show_fdinfo.isra.4+0x53/0x70
> > seq_show+0x130/0x170
> > seq_read+0x153/0x440
> > vfs_read+0x94/0x150
> > ksys_read+0x5f/0xe0
> > do_syscall_64+0x59/0x1e0
> > entry_SYSCALL_64_after_hwframe+0x44/0xa9
> >
> > So let's replace WARN_ON() with WARN_ON_ONCE() to avoid kernel log
> > flooding.
>
> Better just drop the WARN_ON() completely in that case, since it's a
> normally occurring condition.
>
> Thanks,
> Miklos
OK. I will send the v2 patch later.
Thanks,
Jiachen