All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzk@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Josef Bacik <josef@toxicpanda.com>,
	linux-kernel@vger.kernel.org, stable <stable@kernel.org>
Subject: Re: [PATCH 7/9] w1: don't hold list_mutex while a slave is torn down
Date: Fri, 30 Oct 2026 14:42:50 +0100	[thread overview]
Message-ID: <172b2180-a15e-4b7c-98a2-ee62090057d3@kernel.org> (raw)
In-Reply-To: <20261027-llm-char-misc-w1-v1-7-d2e6bfafb6a4@linuxfoundation.org>

On 27/10/2026 17:04, Greg Kroah-Hartman wrote:
> From: Josef Bacik <josef@toxicpanda.com>
> 
> When the last reference to a slave is dropped, w1_unref_slave() holds
> list_mutex of the master until the slave has been freed.  In between it
> calls the ->remove_slave() callback of the family driver and
> device_unregister().  Both wait for others: for the sysfs callbacks
> which are running, and in the case of w1_therm also for the file
> therm_bulk_read of the master and for everybody who is talking to the
> sensor.  None of those can therefore take list_mutex, although the
> callbacks of therm_bulk_read walk the list which it protects.
> 
> The mutex is only needed to make the decrement of the reference count and
> the removal from the list one step for w1_search_slave() and
> w1_slave_search_device(), which look the slave up in the list and, in the
> first case, take a reference.  Once the slave is off the list, nobody can
> find it any more.  Drop the mutex at that point.
> 
> The callers which hold the mutex of the master, which serialises
> attaching and detaching, are not affected.  The one which does not is
> w1_process_cb(), when it drops the last reference to a slave which has
> been detached while a netlink command for it was queued.  Somebody who
> attaches a slave with the same ID through sysfs or netlink at that very
> moment used to wait until the old device was gone.  Now the registration
> of the new device may fail because the name is still in use.
> 
> This is a preparation for "w1: w1_therm: lock the list of slaves for the
> bulk read".
> 
> Cc: stable <stable@kernel.org>
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>

Best regards,
Krzysztof

  reply	other threads:[~2026-10-30 13:42 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-27 16:04 [PATCH 0/9] w1: a bunch of llm-found fixes Greg Kroah-Hartman
2026-10-27 16:04 ` [PATCH 1/9] w1: use the bus mutex for the "rw" file Greg Kroah-Hartman
2026-10-30 12:23   ` Krzysztof Kozlowski
2026-10-27 16:04 ` [PATCH 2/9] w1: remove the master's files before taking its locks Greg Kroah-Hartman
2026-10-30 12:56   ` Krzysztof Kozlowski
2026-10-27 16:04 ` [PATCH 3/9] w1: ds2482: set the strong pull-up with its byte Greg Kroah-Hartman
2026-10-30 13:09   ` Krzysztof Kozlowski
2026-10-27 16:04 ` [PATCH 4/9] w1: ds28e04: use the bus mutex to talk on the bus Greg Kroah-Hartman
2026-10-30 13:10   ` Krzysztof Kozlowski
2026-10-27 16:04 ` [PATCH 5/9] w1: ds2805: " Greg Kroah-Hartman
2026-10-30 13:11   ` Krzysztof Kozlowski
2026-10-30 13:17   ` Krzysztof Kozlowski
2026-10-27 16:04 ` [PATCH 6/9] w1: netlink: drop the slave after the bus is unlocked Greg Kroah-Hartman
2026-10-30 13:41   ` Krzysztof Kozlowski
2026-10-27 16:04 ` [PATCH 7/9] w1: don't hold list_mutex while a slave is torn down Greg Kroah-Hartman
2026-10-30 13:42   ` Krzysztof Kozlowski [this message]
2026-10-27 16:04 ` [PATCH 8/9] w1: w1_therm: lock the list of slaves for the bulk read Greg Kroah-Hartman
2026-10-30 13:44   ` Krzysztof Kozlowski
2026-10-27 16:04 ` [PATCH 9/9] w1: w1_therm: leave the slaves of other families alone Greg Kroah-Hartman
2026-10-30 13:45   ` Krzysztof Kozlowski
2026-10-30  8:14 ` [PATCH 0/9] w1: a bunch of llm-found fixes Krzysztof Kozlowski
2026-10-30  8:22   ` Greg Kroah-Hartman
2026-10-30  8:43     ` Krzysztof Kozlowski
2026-10-30 13:45 ` Krzysztof Kozlowski
2026-10-30 13:49   ` Greg Kroah-Hartman
2026-11-04 13:09   ` Greg Kroah-Hartman

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=172b2180-a15e-4b7c-98a2-ee62090057d3@kernel.org \
    --to=krzk@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=josef@toxicpanda.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@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.