All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Mingyu Wang <25181214217@stu.xidian.edu.cn>
Cc: w15303746062@163.com, David Laight <david.laight.linux@gmail.com>,
	jlayton@kernel.org, chuck.lever@oracle.com,
	viro@zeniv.linux.org.uk, brauner@kernel.org,
	alex.aring@gmail.com, jack@suse.cz,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling
Date: Mon, 12 Oct 2026 19:33:19 +0200	[thread overview]
Message-ID: <as0Z302oRQpI7rgX@redhat.com> (raw)
In-Reply-To: <as0K5CT8IIaCWsfR@redhat.com>

perhaps it is time to add pid->tasks_lock or abuse pid->lock we already
have (we would need to make it irq-safe) but this doesn't look nice...

Oleg.

On 10/12, Oleg Nesterov wrote:
>
> On 10/13, Mingyu Wang wrote:
> >
> > report7.txt corresponds to the warning quoted in my previous reply
> > (syz.2.658/3606).
>
> ...
>
> >   kill_fasync fs/fcntl.c:1159 [inline]
> >   kill_fasync+0x13c/0x520 fs/fcntl.c:1152
> >   __pass_event drivers/input/evdev.c:240 [inline]
> >   evdev_pass_values.part.0+0x62a/0x8f0 drivers/input/evdev.c:278
> >   evdev_pass_values drivers/input/evdev.c:253 [inline]
> >   evdev_events+0x3ba/0x440 drivers/input/evdev.c:306
> >   input_pass_values+0x70c/0x860 drivers/input/input.c:128
> >   input_event_dispose drivers/input/input.c:353 [inline]
> >   input_handle_event+0xdb3/0x1490 drivers/input/input.c:370
> >   input_inject_event+0x1ea/0x3b0 drivers/input/input.c:424
> >   evdev_do_ioctl+0x547/0x1980 drivers/input/evdev.c:1070
> >   evdev_ioctl_handler drivers/input/evdev.c:1270 [inline]
> >   evdev_ioctl+0x14f/0x1b0 drivers/input/evdev.c:1279
> >   vfs_ioctl fs/ioctl.c:51 [inline]
> >   __do_sys_ioctl fs/ioctl.c:597 [inline]
> >   __se_sys_ioctl fs/ioctl.c:583 [inline]
> >   __x64_sys_ioctl+0x194/0x210 fs/ioctl.c:583
>
> Thanks. So yes, this is what I suspected...
>
> kill_fasync() is called under dev->event_lock (input_inject_event() abobe)
> in process contect.
>
> If another CPU takes the same dev->event_lock in softirq context and we race
> with write_lock(tasklist) on yet another CPU, deadlock is indeed possible...
>
> I'll try to take a look, but I can't promise too much ;)
>
> Oleg.


  reply	other threads:[~2026-10-12 17:33 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-23  8:02 [PATCH] fs/fcntl: fix SOFTIRQ-unsafe lock order in send_sigio() w15303746062
2026-05-23 11:08 ` Jeff Layton
2026-05-23 13:52   ` [PATCH v2] fs/fcntl: fix SOFTIRQ-unsafe lock order in fasync signaling w15303746062
2026-05-28 12:40     ` Christian Brauner
2026-10-04 11:31     ` Oleg Nesterov
2026-10-11 15:57       ` Oleg Nesterov
2026-10-12  1:42         ` Mingyu Wang
2026-10-12 15:39           ` Oleg Nesterov
2026-10-12 16:00             ` Mingyu Wang
2026-10-12 16:29               ` Oleg Nesterov
2026-10-12 17:33                 ` Oleg Nesterov [this message]
2026-10-13  1:36                   ` Mingyu Wang
2026-10-12 11:59         ` Jeff Layton
2026-10-12 15:15           ` Oleg Nesterov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=as0Z302oRQpI7rgX@redhat.com \
    --to=oleg@redhat.com \
    --cc=25181214217@stu.xidian.edu.cn \
    --cc=alex.aring@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=david.laight.linux@gmail.com \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=w15303746062@163.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.