mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Johannes Berg <johannes@sipsolutions.net>
To: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: linux-kernel@vger.kernel.org, Jose Souza <jose.souza@intel.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	 "Rafael J . Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH 1/2] devcoredump: Remove devcoredump device if failing device is gone
Date: Tue, 30 Jan 2024 16:19:18 +0100	[thread overview]
Message-ID: <8681168464fa85061db4a7234f89cead65cb0261.camel@sipsolutions.net> (raw)
In-Reply-To: <ZbkSvcEtRgTXuzgJ@intel.com>

On Tue, 2024-01-30 at 10:16 -0500, Rodrigo Vivi wrote:
> > 
> > But I'd rather not, it
> > feels weird to have a need for it.
> 
> We could change or CI and instruct our devs to always write
> something to 'data' to ensure that devcoredump is deleted
> before we can reload our module. Maybe that's the right
> approach indeed, although I would really prefer to have
> a direct way.

That's not really what I meant :-) I think we can agree that it's wrong
for the kernel to be _able_ to run into some kind of use-after-free if
userspace isn't doing the right thing here!

What I meant though is: it's weird for 'data' to actually depend on the
struct device being still around, no? Whatever you want 'data' to be,
couldn't you arrange it so that it's valid as long as the module isn't
removed, so that the 'data' pointer literally encapsulates the needed
data, doesn't depend on anything else, and the method you pass is more
like a 'format' method.

johannes

  reply	other threads:[~2024-01-30 15:19 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-26 15:11 Rodrigo Vivi
2024-01-26 15:11 ` [PATCH 2/2] devcoredump: Remove the mutex serialization Rodrigo Vivi
2024-01-29 15:50   ` Souza, Jose
2024-01-30 12:02   ` Mukesh Ojha
2024-01-30 15:34     ` Rodrigo Vivi
2024-01-31 16:15       ` Mukesh Ojha
2024-01-29 15:50 ` [PATCH 1/2] devcoredump: Remove devcoredump device if failing device is gone Souza, Jose
2024-01-29 17:48 ` Johannes Berg
2024-01-29 21:29   ` Rodrigo Vivi
2024-01-29 21:51     ` Johannes Berg
2024-01-30 15:16       ` Rodrigo Vivi
2024-01-30 15:19         ` Johannes Berg [this message]
2024-01-30 15:49           ` Rodrigo Vivi
2024-01-30 15:51             ` Johannes Berg
2024-01-31 17:22   ` Mukesh Ojha

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=8681168464fa85061db4a7234f89cead65cb0261.camel@sipsolutions.net \
    --to=johannes@sipsolutions.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jose.souza@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=rafael@kernel.org \
    --cc=rodrigo.vivi@intel.com \
    /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

all inboxes | Powered by JetHome®