All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	linux-kernel@vger.kernel.org,
	"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
	Dirk Behme <dirk.behme@de.bosch.com>
Subject: Re: [PATCH 1/2] Revert "drivers: core: synchronize really_probe() and dev_uevent()"
Date: Mon, 24 Feb 2025 18:17:36 -0800	[thread overview]
Message-ID: <Z70oQKHjvjutqom5@google.com> (raw)
In-Reply-To: <9232C7B6-627B-43F9-AD5C-1EA4BB69E40D@gmail.com>

On Wed, Feb 19, 2025 at 11:22:25PM -0800, Dmitry Torokhov wrote:
> On February 19, 2025 11:13:00 PM PST, Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> >On Wed, Feb 19, 2025 at 10:46:44PM -0800, Dmitry Torokhov wrote:
> >> This reverts commit c0a40097f0bc81deafc15f9195d1fb54595cd6d0.
> >> 
> >> Probing a device can take arbitrary long time. In the field we observed
> >> that, for example, probing a bad micro-SD cards in an external USB card
> >> reader (or maybe cards were good but cables were flaky) sometimes takes
> >> longer than 2 minutes due to multiple retries at various levels of the
> >> stack. We can not block uevent_show() method for that long because udev
> >> is reading that attribute very often and that blocks udev and interferes
> >> with booting of the system.
> >> 
> >> The change that introduced locking was concerned with dev_uevent()
> >> racing with unbinding the driver. However we can handle it without
> >> locking (which will be done in subsequent patch).
> >
> >So shouldn't we take the second patch first to prevent any issues here?
> 
> I think the potential for the NULL dereference is extremely small, we
> lived with it for many years. But if you prefer the patches can be
> swapped.

Greg, I was looking at this again and I do not think it makes sense to
swap the patches, as then explanation and justification makes no sense.
So we can either keep it as a straight revert and then address the
driver pointer handling, or combine the 2. What would be your
preference?

I will need to respin to address Rafael's comment anyways.

Thanks.

-- 
Dmitry

  reply	other threads:[~2025-02-25  2:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-02-20  6:46 [PATCH 1/2] Revert "drivers: core: synchronize really_probe() and dev_uevent()" Dmitry Torokhov
2025-02-20  6:46 ` [PATCH 2/2] driver core: fix potential NULL pointer dereference in dev_uevent() Dmitry Torokhov
2025-02-20 10:59   ` Rafael J. Wysocki
2025-02-25  2:12     ` Dmitry Torokhov
2025-02-20  7:13 ` [PATCH 1/2] Revert "drivers: core: synchronize really_probe() and dev_uevent()" Greg Kroah-Hartman
2025-02-20  7:22   ` Dmitry Torokhov
2025-02-25  2:17     ` Dmitry Torokhov [this message]
2025-02-25  6:21       ` 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=Z70oQKHjvjutqom5@google.com \
    --to=dmitry.torokhov@gmail.com \
    --cc=dakr@kernel.org \
    --cc=dirk.behme@de.bosch.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --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.