All of lore.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: minchan@kernel.org, jeyu@kernel.org, ngupta@vflare.org,
	sergey.senozhatsky.work@gmail.com, axboe@kernel.dk,
	mbenes@suse.com, jpoimboe@redhat.com, tglx@linutronix.de,
	keescook@chromium.org, jikos@kernel.org, rostedt@goodmis.org,
	peterz@infradead.org, linux-block@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 3/3] drivers/base/core: refcount kobject and bus on device attribute read / store
Date: Tue, 22 Jun 2021 09:46:26 +0200	[thread overview]
Message-ID: <YNGVUk18pmTFZqAB@kroah.com> (raw)
In-Reply-To: <20210621233651.597220-1-mcgrof@kernel.org>

On Mon, Jun 21, 2021 at 04:36:51PM -0700, Luis Chamberlain wrote:
> It's possible today to have a device attribute read or store
> race against device removal. When this happens there is a small
> chance that the derefence for the private data area of the driver
> is NULL.
> 
> Let's consider the zram driver as an example. Its possible to run into
> a race where a sysfs knob is being used, we get preempted, and a zram
> device is removed before we complete use of the sysfs knob. This can happen
> for instance on block devices, where for instance the zram block devices
> just part of the private data of the block device.
> 
> For instance this can happen in the following two situations
> as examples to illustrate this better:
> 
>         CPU 1                            CPU 2
> destroy_devices
> ...
>                                  compact_store()
>                                  zram = dev_to_zram(dev);
> idr_for_each(zram_remove_cb
>   zram_remove
>   ...
>   kfree(zram)
>                                  down_read(&zram->init_lock);
> 
>         CPU 1                            CPU 2
> hot_remove_store
>                                  compact_store()
>                                  zram = dev_to_zram(dev);
>   zram_remove
>     kfree(zram)
>                                  down_read(&zram->init_lock);
> 
> To ensure the private data pointer is valid we could use bdget() / bdput()
> in between access, however that would mean doing that in all sysfs
> reads/stores on the driver. Instead a generic solution for all drivers
> is to ensure the device kobject is still valid and also the bus, if
> a bus is present.
> 
> This issue does not fix a known crash, however this race was
> spotted by Minchan Kim through code inspection upon code review
> of another zram patch.
> 
> Suggested-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
> ---
>  drivers/base/base.h |  2 ++
>  drivers/base/bus.c  |  4 ++--
>  drivers/base/core.c | 42 ++++++++++++++++++++++++++++++++++++++----
>  3 files changed, 42 insertions(+), 6 deletions(-)

Please make this an independent patch of the zram mess and I will be
glad to consider it for the driver core tree then.

thanks,

greg k-h

  reply	other threads:[~2021-06-22  7:46 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 23:30 [PATCH v3 0/3] zram: fix few sysfs races Luis Chamberlain
2021-06-21 23:30 ` [PATCH v3 1/3] zram: fix crashes due to use of cpu hotplug multistate Luis Chamberlain
2021-06-22  7:39   ` Greg KH
2021-06-22 15:12     ` Luis Chamberlain
2021-06-21 23:36 ` [PATCH v3 2/3] zram: fix deadlock with sysfs attribute usage and driver removal Luis Chamberlain
2021-06-22  7:41   ` Greg KH
2021-06-22 15:27     ` Luis Chamberlain
2021-06-22 16:27       ` Greg KH
2021-06-22 16:40         ` Luis Chamberlain
2021-06-22 16:51           ` Greg KH
2021-06-22 17:00             ` Luis Chamberlain
2021-06-22  7:45   ` Greg KH
2021-06-22 16:32     ` Luis Chamberlain
2021-06-22 17:16       ` Greg KH
2021-06-22 17:27         ` Luis Chamberlain
2021-06-22 18:05           ` Greg KH
2021-06-22 19:57             ` Luis Chamberlain
2021-06-21 23:36 ` [PATCH v3 3/3] drivers/base/core: refcount kobject and bus on device attribute read / store Luis Chamberlain
2021-06-22  7:46   ` Greg KH [this message]
2021-06-22 16:44     ` Luis Chamberlain
2021-06-22 16:48       ` Greg KH

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=YNGVUk18pmTFZqAB@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --cc=axboe@kernel.dk \
    --cc=jeyu@kernel.org \
    --cc=jikos@kernel.org \
    --cc=jpoimboe@redhat.com \
    --cc=keescook@chromium.org \
    --cc=linux-block@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbenes@suse.com \
    --cc=mcgrof@kernel.org \
    --cc=minchan@kernel.org \
    --cc=ngupta@vflare.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky.work@gmail.com \
    --cc=tglx@linutronix.de \
    /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.