Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Min Li <min.li.xe@renesas.com>
To:     Greg KH <gregkh@linuxfoundation.org>
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
Thread-Topic: [PATCH net-next v2] misc: Add Renesas Synchronization Management
 Unit (SMU) support
Thread-Index: AQHXANy3Kc3xxVsbt0Wl/bCSqSMNqapUIqQAgACD5GCAAATlAIAAAqeg
Date:   Fri, 12 Feb 2021 16:02:14 +0000
Message-ID: <OSBPR01MB47734853C9CAAE5AD9C4AD0FBA8B9@OSBPR01MB4773.jpnprd01.prod.outlook.com>
References: <1613092575-17311-1-git-send-email-min.li.xe@renesas.com>
 <YCYwrNE8547uuODo@kroah.com>
 <OSBPR01MB47733A5CB20E20E48EE84602BA8B9@OSBPR01MB4773.jpnprd01.prod.outlook.com>
 <YCajam09pnhVHqkQ@kroah.com>
In-Reply-To: <YCajam09pnhVHqkQ@kroah.com>
Accept-Language: en-CA, en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 77e9e5d4-fdb1-47f7-b7aa-08d8cf6f90c9
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2021 16:02:14.9054
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 53d82571-da19-47e4-9cb4-625a166a4a2a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EXGBdoJJ62PnxDJtYolG08KHkaLEsrD/nz8Q3Ups6WGTf9IMxBb+7/De9JVWYCGEbY4AgawtlY6NAf54GvdxdA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSYPR01MB5509
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

>=20
> xilinx_sdfec.c has:
>=20
> 	static int xsdfec_dev_open(struct inode *iptr, struct file *fptr)
> 	{
> 	        return 0;
> 	}
>=20
> Which isn't even needed at all, but it is NOT trying to keep people from
> calling open multiple times.
>=20
> 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.
>=20
> So don't even try, it's not worth it.
>=20
> > I mean if an application failed at opening the device, how can it
> > proceed to talk the device without a file descriptor?
>=20
> See above for how to do this.
>=20
> thanks,
>=20
> 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. =20