All of lore.kernel.org
 help / color / mirror / Atom feed
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 17:22:37 +0100	[thread overview]
Message-ID: <YCarTeNR/Jxd2inD@kroah.com> (raw)
In-Reply-To: <OSBPR01MB47734853C9CAAE5AD9C4AD0FBA8B9@OSBPR01MB4773.jpnprd01.prod.outlook.com>

On Fri, Feb 12, 2021 at 04:02:14PM +0000, Min Li wrote:
> > 
> > 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
> 
> Hi Greg
> 
> Thanks for your insight for this. Now I can see this change doesn't prevent deliberate hacker from opening the driver multiple times.
> 
> What I had in mind is that it does prevent some unintentional mistake like some one accidentally opens the application twice. The second
> one would fail due to the change here.

Do not add kernel code that does not work for it's intended purpose :)

thanks,

greg k-h

  reply	other threads:[~2021-02-12 16:23 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
2021-02-12 16:02       ` Min Li
2021-02-12 16:22         ` Greg KH [this message]
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=YCarTeNR/Jxd2inD@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 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.