From: Neill Kapron <nkapron@google.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: corbet@lwn.net, skhan@linuxfoundation.org,
linux-usb@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, kernel-team@android.com
Subject: Re: [PATCH 3/3] usb: gadget: f_fs: Introduce rw_proxy file descriptors
Date: Mon, 15 Jun 2026 20:35:30 +0000 [thread overview]
Message-ID: <ajBiEqs_Nhu6HSL-@google.com> (raw)
In-Reply-To: <2026061503-ripening-jokingly-eb4e@gregkh>
On Mon, Jun 15, 2026 at 04:35:39AM +0200, Greg KH wrote:
> On Sun, Jun 14, 2026 at 06:10:02PM +0000, Neill Kapron wrote:
> > diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
> > index 4c1bafb3eef5..0ccfdcfb1810 100644
> > --- a/drivers/usb/gadget/function/f_fs.c
> > +++ b/drivers/usb/gadget/function/f_fs.c
> > @@ -159,7 +159,9 @@ struct ffs_epfile {
> > struct mutex mutex;
> >
> > struct ffs_data *ffs;
> > - struct ffs_ep *ep; /* P: ffs->eps_lock */
> > + struct ffs_ep *ep; /* P: ffs->eps_lock */
> > + struct ffs_epfile *epfile_in; /* P: ffs->eps_lock */
> > + struct ffs_epfile *epfile_out; /* P: ffs->eps_lock */
> >
> > /*
> > * Buffer for holding data from partial reads which may happen since
> > @@ -219,17 +221,20 @@ struct ffs_epfile {
> > struct ffs_buffer *read_buffer;
> > #define READ_BUFFER_DROP ((struct ffs_buffer *)ERR_PTR(-ESHUTDOWN))
> >
> > - char name[5];
> > + char name[10];
>
> Why change the size? Shouldn't that be a separate patch?
The size change is to handle the new proxy file, in the format of
'epXX_rw' (with a null terminator). The size of 10 is a remnant of an
earlier version of this patch which had a slightly different naming
scheme. I will update v2 with name[8] to which will properly reflect the
necessary size required.
> > atomic_t seqno;
> > +
> > + int opened_count; /* P: ffs->eps_lock */
>
> Attempting to track "is this file open or not" almost always fails
> horribly. Think about file descriptors that can be dup() and passed
> around, the kernel has no idea what is going on with them, nor does it
> have to.
>
> Yes, we do track if the file is opened or not already, but I'd argue
> that too is broken and should probably be removed and just use the
> normal file descriptor logic instead.
>
Ack, responded below.
>
> > @@ -1378,8 +1393,18 @@ ffs_epfile_release(struct inode *inode, struct file *file)
> >
> > mutex_unlock(&epfile->dmabufs_mutex);
> >
> > - __ffs_epfile_read_buffer_free(epfile);
> > - ffs_data_closed(epfile->ffs);
> > + spin_lock_irq(&ffs->eps_lock);
> > + if (epfile->is_rw_proxy) {
> > + epfile->epfile_in->opened_count--;
> > + if (--epfile->epfile_out->opened_count == 0)
> > + __ffs_epfile_read_buffer_free(epfile->epfile_out);
> > + } else {
> > + if (--epfile->opened_count == 0)
> > + __ffs_epfile_read_buffer_free(epfile);
>
> If you drop the opened_count, shouldn't these buffers just get freed
> when the structure themselves get freed? You are treating the count as
> a "reference counted structure" in a hand-rolled way that might not
> really be right here as it's kind of hard to prove.
>
> Either use a real reference count for the whole structure (i.e. kref)
> because you need to, or just tie the lifetime of the buffer to the
> larger structure itself. Otherwise these fake references are going to
> be a pain to track that all is correct with them...
>
I was concerned about the implementation of opened_count, and was
pursuing a proper kref approach, but it became a somewhat invasive patch
and I didn't want to pollute this patchset with said change, as I didn't
want to potentially introduce issues for users which did not need this
series.
Changing the buffer lifetime to match the larger structure is
straightforward and clean. I will implement that in v2 of this series,
as it fixes an existing issue.
Thanks for the suggestions,
Neill
next prev parent reply other threads:[~2026-06-15 20:35 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-14 18:09 [PATCH 0/3] usb: gadget: f_fs: Add R/W proxy EPs and ZLP support Neill Kapron
2026-06-14 18:10 ` [PATCH 1/3] usb: gadget: f_fs: Initialize epfile->in early to fix endpoint direction checks Neill Kapron
2026-06-15 2:30 ` Greg KH
2026-06-15 20:19 ` Neill Kapron
2026-06-14 18:10 ` [PATCH 2/3] usb: gadget: f_fs: Add zero-length packet ioctl Neill Kapron
2026-06-14 18:10 ` [PATCH 3/3] usb: gadget: f_fs: Introduce rw_proxy file descriptors Neill Kapron
2026-06-15 2:35 ` Greg KH
2026-06-15 20:35 ` Neill Kapron [this message]
2026-06-15 2:30 ` [PATCH 0/3] usb: gadget: f_fs: Add R/W proxy EPs and ZLP support Greg KH
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=ajBiEqs_Nhu6HSL-@google.com \
--to=nkapron@google.com \
--cc=corbet@lwn.net \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=skhan@linuxfoundation.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.