Re: [PATCH 1/4] scsi: sg: fix BLKSECTGET ioctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2020-09-05 9:19 p.m., Tom Yan wrote:
It was my concern as well, that for this sort of
"backwards-incompatible reason", it has been kept broken
intentionally.

Bumping the sg driver version number is simple:

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 20472aaaf630..c9763b85961f 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -11,8 +11,8 @@
  *        Copyright (C) 1998 - 2014 Douglas Gilbert
  */

-static int sg_version_num = 30536;     /* 2 digits for each component */
-#define SG_VERSION_STR "3.5.36"
+static int sg_version_num = 30537;     /* 2 digits for each component */
+#define SG_VERSION_STR "3.5.37"

 /*
  *  D. P. Gilbert (dgilbert@xxxxxxxxxxxx), notes:


And bumping the version number is appropriate for an interface
tweak/correction.

I'm rewriting the sg driver currently (12 months and counting) and am up
to version 11 of the _first_ half. So far I'm using a sg_version_num of
> 40000 for the rewritten code. Please keep away from version numbers
40000 and above.

The rewritten driver is documented here:
    https://doug-gilbert.github.io/sg_v40.html

and its ioctls are listed in Table 8, including the BLK* ones. Perhaps you
could suggest some corrections. Obviously BLKSSZGET needs to be added
when your patches are accepted.

Doug Gilbert

I am not sure if queue_max_sectors() or BLKSECTGET has ever been
implemented in the block layer to give out the limit in bytes, but it
certainly isn't the case anymore.

I am not in position to say whether it's "right" or "wrong" to
implement BLKSECTGET/BLKSSZGET in the sg driver, but they is
definitely useful in some cases (as long as the queue_* functions work
for the given underlying device). Is it not okay if they don't
ultimately work on *some* devices, even when they aren't named SG_*?

Perhaps we can consider having them removed as well (and implement
them as e.g. SG_GET_MAX_SECTORS and SG_GET_LBS; but IMHO that only
makes a point if they can be made to work on more than block devices).


On Sun, 6 Sep 2020 at 04:37, Douglas Gilbert <dgilbert@xxxxxxxxxxxx> wrote:

On 2020-09-05 3:32 p.m., Bart Van Assche wrote:
On 2020-09-04 13:05, Tom Yan wrote:
It should give out the maximum number of sectors per request
instead of maximum number of bytes.

Signed-off-by: Tom Yan <tom.ty89@xxxxxxxxx>
---
   drivers/scsi/sg.c | 6 ++++--
   1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 20472aaaf630..e57831910228 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -922,6 +922,7 @@ sg_ioctl_common(struct file *filp, Sg_device *sdp, Sg_fd *sfp,
      int result, val, read_only;
      Sg_request *srp;
      unsigned long iflags;
+    unsigned int max_sectors;

      SCSI_LOG_TIMEOUT(3, sg_printk(KERN_INFO, sdp,
                                 "sg_ioctl: cmd=0x%x\n", (int) cmd_in));
@@ -1114,8 +1115,9 @@ sg_ioctl_common(struct file *filp, Sg_device *sdp, Sg_fd *sfp,
              sdp->sgdebug = (char) val;
              return 0;
      case BLKSECTGET:
-            return put_user(max_sectors_bytes(sdp->device->request_queue),
-                            ip);
+            max_sectors = min_t(unsigned int, USHRT_MAX,
+                                queue_max_sectors(sdp->device->request_queue));
+            return put_user(max_sectors, ip);
      case BLKTRACESETUP:
              return blk_trace_setup(sdp->device->request_queue,
                                     sdp->disk->disk_name,

Is this perhaps a backwards-incompatible change to the kernel ABI, the
kind of change Linus totally disagrees with?

Additionally, please Cc linux-api for patches that modify the kernel ABI.
>From https://www.kernel.org/doc/man-pages/linux-api-ml.html: "The kernel
source file Documentation/SubmitChecklist notes that all Linux kernel
patches that change userspace interfaces should be CCed to
linux-api@xxxxxxxxxxxxxxx, so that the various parties who are interested
in API changes are informed. For further information, see
https://www.kernel.org/doc/man-pages/linux-api-ml.html";

Hmm,
The BLK* ioctl()s in the sg driver were an undocumented addition by others.
Plus it is not clear to me why a char device such as the sg driver should
be supporting BLK* ioctl(2)s. For example, how should an enclosure react to
those ioctls or a WLUN?

If they are going to be supported for storage devices and /dev/sdb and
/dev/sg2 are the same device then if:
     blockdev --getmaxsect /dev/sg1

gives a different result to:
     blockdev --getmaxsect /dev/sdb

then I would consider that a bug. So fixing it is making the kernel ABI
more consistent :-)

That's exactly my point. They should work identically as the ones
implemented in the block layer, because of their names.

With that said, sg_version needs to be bumped once the fix gets in, so
that there's a way to differentiate the "different implementations" in
userspace.


Doug Gilbert




Regards,
Tom





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux