All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wedson Almeida Filho <wedsonaf@google.com>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	"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 13:57:56 +0000	[thread overview]
Message-ID: <YsLx5JckMbx/4V4/@google.com> (raw)
In-Reply-To: <19598d43-de61-c663-25e8-17b6f5d5ef80@I-love.SAKURA.ne.jp>

On Mon, Jul 04, 2022 at 10:48:32PM +0900, Tetsuo Handa wrote:
> On 2022/07/04 21:59, Wedson Almeida Filho wrote:
> >> @@ -139,6 +139,10 @@ static int misc_open(struct inode *inode, struct file *file)
> >>  
> >>  	err = 0;
> >>  	replace_fops(file, new_fops);
> >> +	if (iter->unlocked_open && file->f_op->open) {
> >> +		mutex_unlock(&misc_mtx);
> >> +		return file->f_op->open(inode, file);
> >> +	}
> > 
> > One of the invariants of miscdev is that once misc_deregister() returns,
> > no new calls to f_op->open() are made. (Although, of course, you can
> > still have open files but that's a whole different problem.)
> 
> The point of this change is that file->f_op after mutex_unlock(&misc_mtx) is
>  from new_fops which is guaranteed to hold a ref on "struct file_operations"
> via new_fops = fops_get("struct miscdevice"->fops).
> That is, a module ref remains valid even after mutex_unlock(&misc_mtx).
> 
> And as with major_names_lock case quoted below, this change assumes that
> misc_deregister() is called from module's __exit function, and fops_get()
> is preventing the module owning new_fops from calling __exit function.

Your assumption is not sound. misc_deregister() can be (and is)
legitimately called from other places, for example, a driver's remove()
callback. In fact, when I grep for misc_deregister(), the second
instance is such a case.

Anyway, I agree that something should be done about the issue you
report, I'm just arguing that this proposal isn't a good one because it
breaks an invariant that makes it really hard for drivers to properly
cleanup.

> 
> +		if ((*n)->major != major || !(*n)->probe)
> +			continue;
> +		if (!try_module_get((*n)->owner))
> +			break;
> +		/*
> +		 * Calling probe function with major_names_lock held causes
> +		 * circular locking dependency problem. Thus, call it after
> +		 * releasing major_names_lock.
> +		 */
> +		probe_fn = (*n)->probe;
> +		mutex_unlock(&major_names_lock);
> +		/*
> +		 * Assuming that unregister_blkdev() is called from module's
> +		 * __exit function, a module refcount taken above allows us
> +		 * to safely call probe function without major_names_lock held.
> +		 */
> +		probe_fn(devt);
> +		module_put((*n)->owner);
> +		return;
> 

  reply	other threads:[~2022-07-04 13:58 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 [this message]
2022-07-04 14:07                 ` Tetsuo Handa
2022-07-04 14:46                   ` Wedson Almeida Filho
2022-07-04 14:31           ` Greg KH
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=YsLx5JckMbx/4V4/@google.com \
    --to=wedsonaf@google.com \
    --cc=arnd@arndb.de \
    --cc=gregkh@linuxfoundation.org \
    --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 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.