From: Greg KH <gregkh@linuxfoundation.org>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
arnd@arndb.de, linux-kernel@vger.kernel.org,
linux-pm@vger.kernel.org
Subject: Re: [PATCH] char: misc: make misc_open() and misc_register() killable
Date: Mon, 4 Jul 2022 16:31:01 +0200 [thread overview]
Message-ID: <YsL5pUuydMWJ9dSQ@kroah.com> (raw)
In-Reply-To: <01a93294-e323-b9ca-7e95-a33d4b89dc47@I-love.SAKURA.ne.jp>
On Mon, Jul 04, 2022 at 09:34:04PM +0900, Tetsuo Handa wrote:
> On 2022/07/04 20:01, Greg KH wrote:
> > On Mon, Jul 04, 2022 at 07:25:44PM +0900, Tetsuo Handa wrote:
> >> On 2022/07/04 16:29, Greg KH wrote:
> >>> On Mon, Jul 04, 2022 at 03:44:07PM +0900, Tetsuo Handa wrote:
> >>>> syzbot is reporting hung task at misc_open() [1], for snapshot_open() from
> >>>> misc_open() might sleep for long with misc_mtx held whereas userspace can
> >>>> flood with concurrent misc_open() requests. Mitigate this problem by making
> >>>> misc_open() and misc_register() killable.
> >>>
> >>> I do not understand, why not just fix snapshot_open()? Why add this
> >>> complexity to the misc core for a foolish individual misc device? Why
> >>> not add the fix there where it is spinning instead?
> >>
> >> Quoting an example from [1]. Multiple processes are calling misc_open() and
> >> all but one processes are blocked at mutex_lock(&misc_mtx). The one which is
> >> not blocked at mutex_lock(&misc_mtx) is also holding system_transition_mutex.
> >
> > And that is because of that one misc device, right? Why not fix that
> > instead of papering over the issue in the misc core?
>
> Since "struct file_operations"->open() is allowed to sleep, calling
> "struct file_operations"->open() via reassignment by "struct miscdevice"->fops
> with locks held can cause problems.
>
> Assuming that this is not a deadlock hidden by device_initialize(), current
> mutex_lock(&misc_mtx) is as problematic as major_names_lock mentioned at
> https://lkml.kernel.org/r/b2af8a5b-3c1b-204e-7f56-bea0b15848d6@i-love.sakura.ne.jp .
>
> >> If you don't like mutex_lock_killable(&misc_mtx), we will need to consider moving
> >> file->f_op->open() from misc_open() to after mutex_unlock(&misc_mtx).
>
> Below is minimal changes for avoid calling "struct file_operations"->open() with
> misc_mtx held. This would be nothing but moving hung task warning from misc_open()
> to snapshot_open() (and therefore we would need to introduce killable version of
> lock_system_sleep()), but we can avoid making misc_mtx like major_names_lock above.
>
> Greg, can you accept this minimal change?
>
> drivers/char/misc.c | 4 ++++
> include/linux/miscdevice.h | 1 +
> kernel/power/user.c | 1 +
> 3 files changed, 6 insertions(+)
I don't understand what you are trying to "fix" here. What is userspace
doing (as a normal user) that is causing a problem, and what problem is
it causing and for what device/hardware/driver is this a problem?
Yes, you can sleep in open(), but you shouldn't sleep long, if at all
possible as it can be annoying. So why not fix up the offending driver
not to sleep to long?
thanks,
greg k-h
next prev parent reply other threads:[~2022-07-04 14:31 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-13 12:38 INFO: task hung in misc_open (4) syzbot
2022-07-04 6:44 ` [PATCH] char: misc: make misc_open() and misc_register() killable Tetsuo Handa
2022-07-04 7:29 ` Greg KH
2022-07-04 10:25 ` Tetsuo Handa
2022-07-04 11:01 ` Greg KH
2022-07-04 12:34 ` Tetsuo Handa
2022-07-04 12:59 ` Wedson Almeida Filho
2022-07-04 13:48 ` Tetsuo Handa
2022-07-04 13:57 ` Wedson Almeida Filho
2022-07-04 14:07 ` Tetsuo Handa
2022-07-04 14:46 ` Wedson Almeida Filho
2022-07-04 14:31 ` Greg KH [this message]
2022-07-05 5:21 ` Tetsuo Handa
2022-07-05 5:37 ` Greg KH
[not found] ` <a1fcc07e-51ef-eaad-f14b-33f1263e45ac@I-love.SAKURA.ne.jp>
2022-07-05 7:20 ` Dmitry Vyukov
2022-07-05 10:10 ` Greg Kroah-Hartman
2022-07-08 6:06 ` Dmitry Vyukov
2022-07-05 14:01 ` Tetsuo Handa
2022-07-05 14:16 ` Greg KH
2022-07-05 14:35 ` Tetsuo Handa
2022-07-06 6:21 ` Tetsuo Handa
2022-07-06 6:34 ` Greg KH
2022-07-06 10:26 ` Tetsuo Handa
2022-07-06 11:04 ` Oliver Neukum
2022-07-07 5:06 ` Tetsuo Handa
2022-07-07 8:04 ` Greg KH
2022-07-08 13:37 ` Greg KH
2022-07-10 2:27 ` Tetsuo Handa
2022-07-06 12:17 ` Oliver Neukum
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=YsL5pUuydMWJ9dSQ@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=rafael@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox