[RFC 1/2] nvme: add whitelisting infrastructure

[Joel Granados]

Hey Kieth

On Mon, Sep 26, 2022 at 10:16:36AM -0600, Keith Busch wrote:
> On Sun, Sep 18, 2022 at 06:19:17PM +0200, Joel Granados wrote:
> > On Fri, Sep 09, 2022 at 10:03:06PM +0530, Kanchan Joshi wrote:
> > >  
> > > +bool nvme_io_cmd_allowed(u8 opcode, fmode_t mode)
> > > +{
> > > +	/* allow write/read based on what was allowed for open */
> > > +	/* TBD: try to use nvme_is_write() here */
> > > +	if (opcode & 1)
> > I know that this is an RFC, but this would eventually be nvme_cmd_write
> > instead of 1.
> > right?
> 
> '1' is the data direction bit of the opcdoe, and nvme_cmd_write is just an
> opcode that happens to also be '1'.

Thx for the clarification, but as I read it the nvme_is_write function
actually checks for this direction. In his new patch
(https://lore.kernel.org/linux-nvme/20220927183620.12583-1-joshi.k@samsung.com/)
Kanchan actually did what he originally intended which is to use
the nvme_is_write function.

I see that there is a data transfer direction of the command in the
nvme base specification:
00b -> no transfer,
01b -> host to controller,
10b -> controller to host
11b -> bidirectional.
The nvme_is_write() function in the kernel checks the direction.
And there is, of course, a write opcode named nvme_cmd_write.

Best

Joel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-nvme/attachments/20221003/bcef5f6c/attachment-0001.sig>