chrome-platform.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Greg KH <gregkh@linuxfoundation.org>
To: Tzung-Bi Shih <tzungbi@kernel.org>
Cc: bleung@chromium.org, dawidn@google.com,
	chrome-platform@lists.linux.dev, mhiramat@kernel.org
Subject: Re: [PATCH v3 5/8] platform/chrome: Introduce cros_ec_device_alloc()
Date: Fri, 1 Aug 2025 09:50:01 +0100	[thread overview]
Message-ID: <2025080159-grandma-overpass-bc1e@gregkh> (raw)
In-Reply-To: <aIx9vDcqdX8WBTmh@google.com>

On Fri, Aug 01, 2025 at 08:41:32AM +0000, Tzung-Bi Shih wrote:
> On Fri, Aug 01, 2025 at 10:22:18AM +0200, Greg KH wrote:
> > On Fri, Aug 01, 2025 at 07:25:55AM +0000, Tzung-Bi Shih wrote:
> > > On Fri, Jul 25, 2025 at 06:58:23AM +0200, Greg KH wrote:
> > > > On Thu, Jul 24, 2025 at 01:32:01PM +0000, Tzung-Bi Shih wrote:
> > > > > On Thu, Jul 24, 2025 at 12:36:18PM +0200, Greg KH wrote:
> > > > > > NEVER attempt to increment/decrement refcounts on open/release.  That
> > > > > > way lies madness and should not be needed at all, the underlying
> > > > > > infrastructure should keep things working properly here, right?
> > > > > [...]
> > > > You are attempting to have one reference count for one object that has
> > > > different lifecycles.  That doesn't work well, if at all.  See the
> > > > numerous talks at the Linux Plumbers conference over the past few years
> > > > about why this is a "bad idea" and for ideas on how to redesign it to
> > > > fix the issue.
> > > > 
> > > > Hint, 2 objects, different reference counts :)
> > > 
> > > Referenced the talk [1] and its related works and hope I understand it
> > > correctly.
> > > 
> > > [1] https://lpc.events/event/17/contributions/1627/
> > > 
> > > Summarize the proposed fix and I hope it makes sense:
> > > 
> > > Introduce a new helper: ref_proxy for managing "weak" references to the
> > > object that may be gone at any time.  `ref` is the target pointer (i.e.
> > > the resource) which could be released asynchronously (from the resource
> > > consumers' point of view).  The struct ref_proxy_struct is for resource
> > > providers and is only freed on dropping the final reference.
> > 
> > <snip>
> > 
> > Nice!  At a quick glance, this does look like what we need (and if it
> > helps, matches what was just done in the Rust kernel apis, right?)
> 
> Thanks for the review.  I'd need to check.  I wasn't aware of what was just
> done in the Rust kernel APIs.

Take a look at that, if there's any way it can align up with what the
rust code does, if possible, that would be good as we all are going to
be crossing between the two different languages a lot :)

> > Want to turn this into something real and submit it for review after you
> > test it out with your driver to see if it does work?
> 
> Have tested on the draft version and it works.  Will consolidate the patches
> and send them for further reviews.

Great!  No rush, we can't do anything until after -rc1 is out.

thanks,

greg k-h

  reply	other threads:[~2025-08-01  8:50 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-21  4:44 [PATCH v3 0/8] platform/chrome: cros_ec_chardev: Fix a possible UAF Tzung-Bi Shih
2025-07-21  4:44 ` [PATCH v3 1/8] platform/chrome: cros_ec_chardev: Remove redundant struct field Tzung-Bi Shih
2025-07-21  4:44 ` [PATCH v3 2/8] platform/chrome: cros_ec: Unregister notifier in cros_ec_unregister() Tzung-Bi Shih
2025-07-21  6:13   ` Greg KH
2025-07-21  9:30     ` Tzung-Bi Shih
2025-07-21  4:44 ` [PATCH v3 3/8] platform/chrome: cros_ec_chardev: Decouple fops from struct cros_ec_dev Tzung-Bi Shih
2025-07-21  4:44 ` [PATCH v3 4/8] platform/chrome: Disallow sending commands through unregistered ec_dev Tzung-Bi Shih
2025-07-21  5:47   ` Greg KH
2025-07-21  9:31     ` Tzung-Bi Shih
2025-07-21 10:23       ` Greg KH
2025-07-21  4:44 ` [PATCH v3 5/8] platform/chrome: Introduce cros_ec_device_alloc() Tzung-Bi Shih
2025-07-21  6:15   ` Greg KH
2025-07-24  9:58     ` Tzung-Bi Shih
2025-07-24 10:36       ` Greg KH
2025-07-24 13:32         ` Tzung-Bi Shih
2025-07-25  4:58           ` Greg KH
2025-08-01  7:25             ` Tzung-Bi Shih
2025-08-01  8:22               ` Greg KH
2025-08-01  8:41                 ` Tzung-Bi Shih
2025-08-01  8:50                   ` Greg KH [this message]
2025-08-14  9:24                     ` Tzung-Bi Shih
2025-07-21  4:44 ` [PATCH v3 6/8] platform/chrome: Don't initialize common utilities when registering Tzung-Bi Shih
2025-07-21  4:44 ` [PATCH v3 7/8] platform/chrome: cros_ec_chardev: Hold refcount of struct cros_ec_device Tzung-Bi Shih
2025-07-21  4:44 ` [PATCH v3 8/8] platform/chrome: Manage struct cros_ec_device lifecycle by its refcount Tzung-Bi Shih

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=2025080159-grandma-overpass-bc1e@gregkh \
    --to=gregkh@linuxfoundation.org \
    --cc=bleung@chromium.org \
    --cc=chrome-platform@lists.linux.dev \
    --cc=dawidn@google.com \
    --cc=mhiramat@kernel.org \
    --cc=tzungbi@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).