From: Lee Jones <lee@kernel.org>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: balbi@kernel.org, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 1/1] usb: gadget: f_hid: Conduct proper refcounting on shared f_hidg pointer
Date: Thu, 17 Nov 2022 13:46:26 +0000 [thread overview]
Message-ID: <Y3Y7MlwV0UFcA3w8@google.com> (raw)
In-Reply-To: <Y3YuL8rSE9pNfIZN@kroah.com>
On Thu, 17 Nov 2022, Greg KH wrote:
> On Thu, Nov 17, 2022 at 12:08:13PM +0000, Lee Jones wrote:
> > +static inline bool f_hidg_is_open(struct f_hidg *hidg)
> > +{
> > + return !!kref_read(&hidg->cdev.kobj.kref);
> > +}
>
> Ick, sorry, no, that's not going to work and is not allowed at all.
> That's some major layering violations there, AND it can change after you
> get the value as well.
This cdev belongs solely to this driver. Hence the *.*.* and not
*->*->*. What is preventing us from reading our own data? If we
cannot do this directly, can I create an API to do it 'officially'?
I do, however, appreciate that a little locking wouldn't go amiss.
If this solution is not acceptable either, then we're left up the
creak without a paddle. The rules you've communicated are not
compatible with each other.
Rule 1: Only one item in a data structure can reference count.
Due to the embedded cdev struct, this rules out my first solution of
giving f_hidg its own kref so that it can conduct its own life-time
management.
A potential option to satisfy this rule would be to remove the cdev
attribute and create its data dynamically instead. However, the
staticness of cdev is used to obtain f_hidg (with container_of()) in
the character device handling component, so it cannot be removed.
Rule 2: Reading the present refcount causes a laying violation
So we're essentially saying, if data is already being reference
counted, you have to use the present implementation instead of adding
additional counts, but there is no way to actually do that, which
kind of puts us at stalemate.
Since this is a genuine issue, doing anything is not really an option
either. So where do we go from here?
--
Lee Jones [李琼斯]
next prev parent reply other threads:[~2022-11-17 13:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-17 12:08 [PATCH 1/1] usb: gadget: f_hid: Conduct proper refcounting on shared f_hidg pointer Lee Jones
2022-11-17 12:50 ` Greg KH
2022-11-17 13:26 ` Lee Jones
2022-11-17 17:38 ` Greg KH
2022-11-17 12:50 ` Greg KH
2022-11-17 13:46 ` Lee Jones [this message]
2022-11-17 16:47 ` Alan Stern
2022-11-18 8:54 ` Lee Jones
2022-11-18 15:59 ` Alan Stern
2022-11-18 16:37 ` John Keeping
2022-11-18 21:07 ` Alan Stern
2022-11-20 17:22 ` John Keeping
2022-11-20 20:46 ` Alan Stern
2022-11-21 12:30 ` Lee Jones
2022-11-21 12:38 ` John Keeping
2022-11-21 16:18 ` Alan Stern
2022-11-21 18:54 ` John Keeping
2022-11-21 19:17 ` Alan Stern
2022-11-22 11:52 ` John Keeping
2022-11-22 8:31 ` Lee Jones
2022-11-22 11:55 ` John Keeping
-- strict thread matches above, loose matches on Subject: below --
2022-10-17 11:27 Lee Jones
2022-10-22 12:52 ` Greg Kroah-Hartman
2022-10-24 7:17 ` Lee Jones
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=Y3Y7MlwV0UFcA3w8@google.com \
--to=lee@kernel.org \
--cc=balbi@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.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