From: Greg KH <gregkh@linuxfoundation.org>
To: Min Li <min.li.xe@renesas.com>
Cc: "derek.kiernan@xilinx.com" <derek.kiernan@xilinx.com>,
"dragan.cvetic@xilinx.com" <dragan.cvetic@xilinx.com>,
"arnd@arndb.de" <arnd@arndb.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next v2] misc: Add Renesas Synchronization Management Unit (SMU) support
Date: Fri, 12 Feb 2021 16:48:58 +0100 [thread overview]
Message-ID: <YCajam09pnhVHqkQ@kroah.com> (raw)
In-Reply-To: <OSBPR01MB47733A5CB20E20E48EE84602BA8B9@OSBPR01MB4773.jpnprd01.prod.outlook.com>
On Fri, Feb 12, 2021 at 03:39:03PM +0000, Min Li wrote:
> > > +
> > > + /* Only one open per device at a time */
> > > + if (!atomic_dec_and_test(&rsmu->open_count)) {
> > > + atomic_inc(&rsmu->open_count);
> > > + return -EBUSY;
> >
> > This does not do what you think it does, and does not prevent multiple
> > applications from talking to your device at the same time.
> >
> > There is no need for this at all, as it does not work, sorry. If multiple apps
> > talk to your device, it's their fault, not the kernel's fault, that things go
> > wrong.
> >
> > And I thought that Arnd already told you to fix this?
> >
>
> Hi Greg
>
> Sorry for not replying to the list, I am new so not very familiar with the process.
>
> Can you elaborate why it doesn't work? I kind of borrow the idea from
> xilinx_sdfec.c and I don't see why it doesn't work.
xilinx_sdfec.c has:
static int xsdfec_dev_open(struct inode *iptr, struct file *fptr)
{
return 0;
}
Which isn't even needed at all, but it is NOT trying to keep people from
calling open multiple times.
As for why the above logic does not work in your driver, think of what
happens if someone opens the character device node, and then calls
dup(2) on it and passes that file descriptor off to another program. Or
just calls it multiple times from different threads in the same program.
The kernel does not know what is happening here, and so, "do not allow
to be opened multiple times" does not do anything to keep userspace from
actually writing to the device node from multiple processes or threads.
So don't even try, it's not worth it.
> I mean if an application failed at opening the device, how can it
> proceed to talk the device without a file descriptor?
See above for how to do this.
thanks,
greg k-h
next prev parent reply other threads:[~2021-02-12 15:49 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-12 1:16 [PATCH net-next v2] misc: Add Renesas Synchronization Management Unit (SMU) support min.li.xe
2021-02-12 7:39 ` Greg KH
2021-02-12 15:39 ` Min Li
2021-02-12 15:48 ` Greg KH [this message]
2021-02-12 16:02 ` Min Li
2021-02-12 16:22 ` Greg KH
2021-02-12 7:40 ` Greg KH
2021-02-12 15:44 ` Min Li
2021-02-12 15:55 ` Greg KH
2021-02-12 16:04 ` Min Li
2021-02-12 19:06 ` Min Li
2021-02-13 8:28 ` Greg KH
2021-02-16 19:50 ` Min Li
2021-02-17 7:11 ` 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=YCajam09pnhVHqkQ@kroah.com \
--to=gregkh@linuxfoundation.org \
--cc=arnd@arndb.de \
--cc=derek.kiernan@xilinx.com \
--cc=dragan.cvetic@xilinx.com \
--cc=linux-kernel@vger.kernel.org \
--cc=min.li.xe@renesas.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