About BLKSECTGET in sg

About BLKSECTGET in sg

[Tom Yan]

Hi,

Is BLKSECTGET in sg intentionally kept "broken" (i.e. it gives out
max_sectors in bytes) or is it just a miss? I'm just wondering if I
should send a patch to fix it (and implement BLKSSZGET).

Also, shouldn't max_sectors_bytes() in both drivers/scsi/sg.c and
block/scsi_ioctl.c use queue_logical_block_size() instead?

Regards,
Tom

Re: About BLKSECTGET in sg

[Douglas Gilbert]

On 2020-09-04 12:42 a.m., Tom Yan wrote:
> Hi,
> 
> Is BLKSECTGET in sg intentionally kept "broken" (i.e. it gives out
> max_sectors in bytes) or is it just a miss? I'm just wondering if I
> should send a patch to fix it (and implement BLKSSZGET).
> 
> Also, shouldn't max_sectors_bytes() in both drivers/scsi/sg.c and
> block/scsi_ioctl.c use queue_logical_block_size() instead?

Tom,
I have no idea! One of the great things about maintaining a driver in
Linux is that virtually anyone can send patches and get them accepted
without and Ack from the maintainer. And when bugs are found in those
patches, the culprits can't be found or have no inclination to fix them.

'git blame' will show you that I had nothing to do with the BLK*
ioctl()s added to the sg driver. That said, if they are broken, they
should be fixed. I would be interested in getting some test code as
I'm not familiar with using those ioctl()s.

Would you like to send some patches?

Doug Gilbert

Re: About BLKSECTGET in sg

[Tom Yan]

Hi Doug,

On Sat, 5 Sep 2020 at 00:28, Douglas Gilbert <dgilbert@interlog.com> wrote:
>
> On 2020-09-04 12:42 a.m., Tom Yan wrote:
> > Hi,
> >
> > Is BLKSECTGET in sg intentionally kept "broken" (i.e. it gives out
> > max_sectors in bytes) or is it just a miss? I'm just wondering if I
> > should send a patch to fix it (and implement BLKSSZGET).
> >
> > Also, shouldn't max_sectors_bytes() in both drivers/scsi/sg.c and
> > block/scsi_ioctl.c use queue_logical_block_size() instead?
>
> Tom,
> I have no idea! One of the great things about maintaining a driver in
> Linux is that virtually anyone can send patches and get them accepted
> without and Ack from the maintainer. And when bugs are found in those
> patches, the culprits can't be found or have no inclination to fix them.
>
> 'git blame' will show you that I had nothing to do with the BLK*
> ioctl()s added to the sg driver. That said, if they are broken, they
> should be fixed. I would be interested in getting some test code as

You can test them easily with `blockdev` (--getmaxsect and --getss) in
util-linux.

max_sectors_bytes() are used in sg_add_sfp() and the
SG_{GET,SET}_RESERVED_SIZE ioctls. I am not familiar with those but I
don't see why they shouldn't use the queue_logical_sector_size() (when
they use queue_max_sectors()).

For the BLKSECTGET fix, I think the sg version needs to be bumped (so
that userspace programs like qemu can work as properly as possible
with different versions). Can you point me to some guidance on how
exactly it should be bumped (e.g. which component(s), the "step
size"...)? Or would you do that after the patches are accepted?

> I'm not familiar with using those ioctl()s.
>
> Would you like to send some patches?

They are on the way.

>
> Doug Gilbert
>
>

Regards,
Tom

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

[Tom Yan]

It should give out the maximum number of sectors per request
instead of maximum number of bytes.

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
 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,
-- 
2.28.0

[PATCH 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

Provide an ioctl to get the logical sector size so that the maximum
bytes per request can be derived.

Follow-up of the BLKSECTGET fix.

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index e57831910228..0e3f084141a3 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1118,6 +1118,8 @@ sg_ioctl_common(struct file *filp, Sg_device *sdp, Sg_fd *sfp,
 		max_sectors = min_t(unsigned int, USHRT_MAX,
 				    queue_max_sectors(sdp->device->request_queue));
 		return put_user(max_sectors, ip);
+	case BLKSSZGET:
+		return put_user(queue_logical_block_size(sdp->device->request_queue), ip);
 	case BLKTRACESETUP:
 		return blk_trace_setup(sdp->device->request_queue,
 				       sdp->disk->disk_name,
-- 
2.28.0

Re: [PATCH 2/4] scsi: sg: implement BLKSSZGET

[Douglas Gilbert]

On 2020-09-04 4:05 p.m., Tom Yan wrote:
> Provide an ioctl to get the logical sector size so that the maximum
> bytes per request can be derived.
> 
> Follow-up of the BLKSECTGET fix.
> 
> Signed-off-by: Tom Yan <tom.ty89@gmail.com>

Acked-by: Douglas Gilbert <dgilbert@interlog.com>

> ---
>   drivers/scsi/sg.c | 2 ++
>   1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index e57831910228..0e3f084141a3 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -1118,6 +1118,8 @@ sg_ioctl_common(struct file *filp, Sg_device *sdp, Sg_fd *sfp,
>   		max_sectors = min_t(unsigned int, USHRT_MAX,
>   				    queue_max_sectors(sdp->device->request_queue));
>   		return put_user(max_sectors, ip);
> +	case BLKSSZGET:
> +		return put_user(queue_logical_block_size(sdp->device->request_queue), ip);
>   	case BLKTRACESETUP:
>   		return blk_trace_setup(sdp->device->request_queue,
>   				       sdp->disk->disk_name,
> 

[PATCH 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 0e3f084141a3..deeab4855172 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -848,10 +848,11 @@ static int srp_done(Sg_fd *sfp, Sg_request *srp)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static void
-- 
2.28.0

Re: [PATCH 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes()

[Douglas Gilbert]

On 2020-09-04 4:05 p.m., Tom Yan wrote:
> Signed-off-by: Tom Yan <tom.ty89@gmail.com>

Acked-by: Douglas Gilbert <dgilbert@interlog.com>

> ---
>   drivers/scsi/sg.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index 0e3f084141a3..deeab4855172 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -848,10 +848,11 @@ static int srp_done(Sg_fd *sfp, Sg_request *srp)
>   static int max_sectors_bytes(struct request_queue *q)
>   {
>   	unsigned int max_sectors = queue_max_sectors(q);
> +	unsigned int logical_block_size = queue_logical_block_size(q);
>   
> -	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
> +	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
>   
> -	return max_sectors << 9;
> +	return max_sectors * logical_block_size;
>   }
>   
>   static void
> 

[PATCH 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
 block/scsi_ioctl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index ef722f04f88a..ae6aae40a8b6 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -73,10 +73,11 @@ static int sg_set_timeout(struct request_queue *q, int __user *p)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static int sg_get_reserved_size(struct request_queue *q, int __user *p)
-- 
2.28.0

Re: [PATCH 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes()

[Douglas Gilbert]

On 2020-09-04 4:05 p.m., Tom Yan wrote:
> Signed-off-by: Tom Yan <tom.ty89@gmail.com>

Reviewed-by: Douglas Gilbert <dgilbert@interlog.com>

> ---
>   block/scsi_ioctl.c | 5 +++--
>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
> index ef722f04f88a..ae6aae40a8b6 100644
> --- a/block/scsi_ioctl.c
> +++ b/block/scsi_ioctl.c
> @@ -73,10 +73,11 @@ static int sg_set_timeout(struct request_queue *q, int __user *p)
>   static int max_sectors_bytes(struct request_queue *q)
>   {
>   	unsigned int max_sectors = queue_max_sectors(q);
> +	unsigned int logical_block_size = queue_logical_block_size(q);
>   
> -	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
> +	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
>   
> -	return max_sectors << 9;
> +	return max_sectors * logical_block_size;
>   }
>   
>   static int sg_get_reserved_size(struct request_queue *q, int __user *p)
> 

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

[Douglas Gilbert]

On 2020-09-04 4:05 p.m., 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@gmail.com>

Acked-by: Douglas Gilbert <dgilbert@interlog.com>

> ---
>   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,
> 

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

[Bart Van Assche]

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@gmail.com>
> ---
>  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@vger.kernel.org, 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"

Thanks,

Bart.

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

[Douglas Gilbert]

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@gmail.com>
>> ---
>>   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@vger.kernel.org, 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 :-)

Doug Gilbert

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

[Tom Yan]

It was my concern as well, that for this sort of
"backwards-incompatible reason", it has been kept broken
intentionally.

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@interlog.com> 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@gmail.com>
> >> ---
> >>   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@vger.kernel.org, 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

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

[Tom Yan]

It should give out the maximum number of sectors per request
instead of maximum number of bytes.

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
 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,
-- 
2.28.0

[PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

Provide an ioctl to get the logical sector size so that the maximum
bytes per request can be derived.

Follow-up of the BLKSECTGET fix.

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index e57831910228..0e3f084141a3 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1118,6 +1118,8 @@ sg_ioctl_common(struct file *filp, Sg_device *sdp, Sg_fd *sfp,
 		max_sectors = min_t(unsigned int, USHRT_MAX,
 				    queue_max_sectors(sdp->device->request_queue));
 		return put_user(max_sectors, ip);
+	case BLKSSZGET:
+		return put_user(queue_logical_block_size(sdp->device->request_queue), ip);
 	case BLKTRACESETUP:
 		return blk_trace_setup(sdp->device->request_queue,
 				       sdp->disk->disk_name,
-- 
2.28.0

[PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 0e3f084141a3..deeab4855172 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -848,10 +848,11 @@ static int srp_done(Sg_fd *sfp, Sg_request *srp)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static void
-- 
2.28.0

[PATCH RESEND 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
 block/scsi_ioctl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index ef722f04f88a..ae6aae40a8b6 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -73,10 +73,11 @@ static int sg_set_timeout(struct request_queue *q, int __user *p)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static int sg_get_reserved_size(struct request_queue *q, int __user *p)
-- 
2.28.0

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

[Tom Yan]

It should give out the maximum number of sectors per request
instead of maximum number of bytes.

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
 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,
-- 
2.28.0

[PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

Provide an ioctl to get the logical sector size so that the maximum
bytes per request can be derived.

Follow-up of the BLKSECTGET fix.

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index e57831910228..0e3f084141a3 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1118,6 +1118,8 @@ sg_ioctl_common(struct file *filp, Sg_device *sdp, Sg_fd *sfp,
 		max_sectors = min_t(unsigned int, USHRT_MAX,
 				    queue_max_sectors(sdp->device->request_queue));
 		return put_user(max_sectors, ip);
+	case BLKSSZGET:
+		return put_user(queue_logical_block_size(sdp->device->request_queue), ip);
 	case BLKTRACESETUP:
 		return blk_trace_setup(sdp->device->request_queue,
 				       sdp->disk->disk_name,
-- 
2.28.0

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Christoph Hellwig]

On Sun, Sep 06, 2020 at 09:27:14AM +0800, Tom Yan wrote:
> Provide an ioctl to get the logical sector size so that the maximum
> bytes per request can be derived.
> 
> Follow-up of the BLKSECTGET fix.

I don't think this has any business going in.  /dev/sg is a generic
interface that is not specific to block based command sets.  Just issue
your command set specific command to query the logical block size if
you care about it.

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

Feel free to omit this. But then you will probably want to ditch
BLKSECTGET as well, and then any usage of queue_max_sectors(), and
maybe more/all queue_*().

I'm not really interested in discussing/arguing whether
general/ideally-speaking it's appropriate/necessary to keep BLKSECTGET
/ add BLKSSZGET. The only reason I added this is that, when BLKSECTGET
was introduced to sg long time ago, it was wrongly implemented to
gives out the limit in bytes, so now when I'm fixing it, I'm merely
making sure that whatever has been relying on the ioctl (e.g. qemu)
will only need to do one more ioctl (instead of e.g. doing SCSI in its
non-SCSI-specific part), if they want/need the limit in bytes. If they
can be implemented more "generic"-ly, feel free to improve/extend them
to make them "SG_*-qualified".

Even if you can do SCSI from the userspace, or even should, I don't
see any reason that we shouldn't provide an ioctl to do
queue_logical_block_size() *while we provide one to do
queue_max_sectors()*.

On Mon, 7 Sep 2020 at 14:09, Christoph Hellwig <hch@lst.de> wrote:
>
> On Sun, Sep 06, 2020 at 09:27:14AM +0800, Tom Yan wrote:
> > Provide an ioctl to get the logical sector size so that the maximum
> > bytes per request can be derived.
> >
> > Follow-up of the BLKSECTGET fix.
>
> I don't think this has any business going in.  /dev/sg is a generic
> interface that is not specific to block based command sets.  Just issue
> your command set specific command to query the logical block size if
> you care about it.

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Christoph Hellwig]

On Mon, Sep 07, 2020 at 05:01:34PM +0800, Tom Yan wrote:
> Feel free to omit this. But then you will probably want to ditch
> BLKSECTGET as well, and then any usage of queue_max_sectors(), and
> maybe more/all queue_*().
> 
> I'm not really interested in discussing/arguing whether
> general/ideally-speaking it's appropriate/necessary to keep BLKSECTGET
> / add BLKSSZGET. The only reason I added this is that, when BLKSECTGET
> was introduced to sg long time ago, it was wrongly implemented to
> gives out the limit in bytes, so now when I'm fixing it, I'm merely
> making sure that whatever has been relying on the ioctl (e.g. qemu)
> will only need to do one more ioctl (instead of e.g. doing SCSI in its
> non-SCSI-specific part), if they want/need the limit in bytes. If they
> can be implemented more "generic"-ly, feel free to improve/extend them
> to make them "SG_*-qualified".
> 
> Even if you can do SCSI from the userspace, or even should, I don't
> see any reason that we shouldn't provide an ioctl to do
> queue_logical_block_size() *while we provide one to do
> queue_max_sectors()*.

Well, the different definition in bytes for sg actually makes sense
to me, as a bytes based limit is what fundamentally makes sense for
the passthrough interface.  Only that it reuses the same cmd value
is a bit confusing.  So instead of changing anything and potentially
breaking applications I'd suggest to just better document the semantics.

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

If we rename it to e.g. SG_GET_MAX_XFER_BYTES, it will still break
applications unless we also keep the wrong/ugly/confusing name (and
you lose the advantage/generality that the two ioctls can be used on
both sg and "pure" block devices; which seems to be the case of some
SG_* ioctls as well).

I don't see what it has to do with passthrough. Either way, it's just
a matter of whether you want to decouple it and make things more
flexible. The only real disadvantage is, you will have to do two
ioctls instead of one, but no more than that, and for good reasons.

I don't really care enough though. I mean, I'm okay with
SG_GET_MAX_XFER_BYTES *and* NO "improper" BLKSECTGET. If that will get
the patch series in, I am willing to send a new version. If not, I'm
just gonna drop this.

On Tue, 8 Sep 2020 at 16:43, Christoph Hellwig <hch@lst.de> wrote:
>
> On Mon, Sep 07, 2020 at 05:01:34PM +0800, Tom Yan wrote:
> > Feel free to omit this. But then you will probably want to ditch
> > BLKSECTGET as well, and then any usage of queue_max_sectors(), and
> > maybe more/all queue_*().
> >
> > I'm not really interested in discussing/arguing whether
> > general/ideally-speaking it's appropriate/necessary to keep BLKSECTGET
> > / add BLKSSZGET. The only reason I added this is that, when BLKSECTGET
> > was introduced to sg long time ago, it was wrongly implemented to
> > gives out the limit in bytes, so now when I'm fixing it, I'm merely
> > making sure that whatever has been relying on the ioctl (e.g. qemu)
> > will only need to do one more ioctl (instead of e.g. doing SCSI in its
> > non-SCSI-specific part), if they want/need the limit in bytes. If they
> > can be implemented more "generic"-ly, feel free to improve/extend them
> > to make them "SG_*-qualified".
> >
> > Even if you can do SCSI from the userspace, or even should, I don't
> > see any reason that we shouldn't provide an ioctl to do
> > queue_logical_block_size() *while we provide one to do
> > queue_max_sectors()*.
>
> Well, the different definition in bytes for sg actually makes sense
> to me, as a bytes based limit is what fundamentally makes sense for
> the passthrough interface.  Only that it reuses the same cmd value
> is a bit confusing.  So instead of changing anything and potentially
> breaking applications I'd suggest to just better document the semantics.

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Christoph Hellwig]

On Thu, Sep 10, 2020 at 09:59:05AM +0800, Tom Yan wrote:
> If we rename it to e.g. SG_GET_MAX_XFER_BYTES, it will still break
> applications unless we also keep the wrong/ugly/confusing name (and
> you lose the advantage/generality that the two ioctls can be used on
> both sg and "pure" block devices; which seems to be the case of some
> SG_* ioctls as well).

How is that an advantage?  Applications that works with block devices
don't really work with a magic passthrough character device.

> I don't really care enough though. I mean, I'm okay with
> SG_GET_MAX_XFER_BYTES *and* NO "improper" BLKSECTGET. If that will get
> the patch series in, I am willing to send a new version. If not, I'm
> just gonna drop this.

You must assume that there are applications already that depend in the
"weird" BLKSECTGET on sg, given that it has been around so long.  Any
change to the semantics will break them.

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

On Thu, 10 Sep 2020 at 13:28, Christoph Hellwig <hch@lst.de> wrote:
>
> On Thu, Sep 10, 2020 at 09:59:05AM +0800, Tom Yan wrote:
> > If we rename it to e.g. SG_GET_MAX_XFER_BYTES, it will still break
> > applications unless we also keep the wrong/ugly/confusing name (and
> > you lose the advantage/generality that the two ioctls can be used on
> > both sg and "pure" block devices; which seems to be the case of some
> > SG_* ioctls as well).
>
> How is that an advantage?  Applications that works with block devices
> don't really work with a magic passthrough character device.

You must assume that there are applications already assuming that
work. (And it will, at least in some cases, if this series get
merged.)

And you have not been giving me a solid point anyway, as I said, it's
just queue_*() at the end of the day; regardless of whether those
would work in all sg cases, we have been using them in the sg driver
anyway.

And it's not like we have to guarantee that (the) ioctls can work in
every case anyway, right? (Especially when they aren't named SG_*).

I mean, what's even your point? How do you propose we fix this? Should
we just leave it broken/wrong/rotten as-is (including the case that
you don't consider it being so)? If that's what you are trying to say
then please just say it, I'll just walk away quietly. I'm really kind
of done with this sort of looping that leads to nowhere.

>
> > I don't really care enough though. I mean, I'm okay with
> > SG_GET_MAX_XFER_BYTES *and* NO "improper" BLKSECTGET. If that will get
> > the patch series in, I am willing to send a new version. If not, I'm
> > just gonna drop this.
>
> You must assume that there are applications already that depend in the
> "weird" BLKSECTGET on sg, given that it has been around so long.  Any
> change to the semantics will break them.

While you forgot to assume that there are applications assuming
BLKSECTGET is as "weird" in the block layer at the same time. (That's
exactly what has happened in qemu.) You don't get the slightest
advantage in "trying not to break things" by doing the wrong thing. It
only goes on making more things broken.

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Christoph Hellwig]

On Fri, Sep 11, 2020 at 10:52:19AM +0800, Tom Yan wrote:
> > How is that an advantage?  Applications that works with block devices
> > don't really work with a magic passthrough character device.
> 
> You must assume that there are applications already assuming that
> work. (And it will, at least in some cases, if this series get
> merged.)

Why "must" I assume that?

> And you have not been giving me a solid point anyway, as I said, it's
> just queue_*() at the end of the day; regardless of whether those
> would work in all sg cases, we have been using them in the sg driver
> anyway.
> 
> And it's not like we have to guarantee that (the) ioctls can work in
> every case anyway, right? (Especially when they aren't named SG_*).

No.  While it is unfortunte we have all kinds of cases of ioctls working
differnetly on different devices.

> 
> I mean, what's even your point? How do you propose we fix this?

I propose to not "fix" anything, because nothing is broken except for
maybe a lack of documentation.

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Douglas Gilbert]

On 2020-09-11 2:48 a.m., Christoph Hellwig wrote:
> On Fri, Sep 11, 2020 at 10:52:19AM +0800, Tom Yan wrote:
>>> How is that an advantage?  Applications that works with block devices
>>> don't really work with a magic passthrough character device.
>>
>> You must assume that there are applications already assuming that
>> work. (And it will, at least in some cases, if this series get
>> merged.)
> 
> Why "must" I assume that?
> 
>> And you have not been giving me a solid point anyway, as I said, it's
>> just queue_*() at the end of the day; regardless of whether those
>> would work in all sg cases, we have been using them in the sg driver
>> anyway.
>>
>> And it's not like we have to guarantee that (the) ioctls can work in
>> every case anyway, right? (Especially when they aren't named SG_*).
> 
> No.  While it is unfortunte we have all kinds of cases of ioctls working
> differnetly on different devices.
> 
>>
>> I mean, what's even your point? How do you propose we fix this?
> 
> I propose to not "fix" anything, because nothing is broken except for
> maybe a lack of documentation.

Alan Stern are you reading this thread? Why do I ask, you may ask?
Because 'git blame' fingers you:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

commit 44ec95425c1d9dce6e4638c29e4362cfb44814e7
Author: Alan Stern <stern@rowland.harvard.edu>
Date:   Tue Feb 20 11:01:57 2007 -0500

     [SCSI] sg: cap reserved_size values at max_sectors

     This patch (as857) modifies the SG_GET_RESERVED_SIZE and
     SG_SET_RESERVED_SIZE ioctls in the sg driver, capping the values at
     the device's request_queue's max_sectors value.  This will permit
     cdrecord to obtain a legal value for the maximum transfer length,
     fixing Bugzilla #7026.

     The patch also caps the initial reserved_size value.  There's no
     reason to have a reserved buffer larger than max_sectors, since it
     would be impossible to use the extra space.

     The corresponding ioctls in the block layer are modified similarly,
     and the initial value for the reserved_size is set as large as
     possible.  This will effectively make it default to max_sectors.
     Note that the actual value is meaningless anyway, since block devices
     don't have a reserved buffer.

     Finally, the BLKSECTGET ioctl is added to sg, so that there will be a
     uniform way for users to determine the actual max_sectors value for
     any raw SCSI transport.

     Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
     Acked-by: Jens Axboe <jens.axboe@oracle.com>
     Acked-by: Douglas Gilbert <dougg@torque.net>
     Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Oops, I ack-ed this patch from 2007:-) Anyway it would seem BLKSECTGET ioctl
was meant to be a "uniform way to determine the actual max_sectors value for
any raw SCSI transport." Given that the initial implementation of BLKSECTGET
now seems to be at odds with other implementations, what should we do?

It is possible that it was correct on 2007 and the BLKSECTGET ioctl has
changed elsewhere but failed to fix the sg driver's implementation.

If I get a vote then it would be for Tom Yan's approach: reduce entropy or
it will overwhelm us :-)


So Christoph, it IS documented, both in the above commit message and:
    https://doug-gilbert.github.io/sg_v40.html

in Table 8. So please stop with your "maybe a lack of documentation" line.

Doug Gilbert

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Alan Stern]

On Fri, Sep 11, 2020 at 01:52:07PM -0400, Douglas Gilbert wrote:
> On 2020-09-11 2:48 a.m., Christoph Hellwig wrote:
> > On Fri, Sep 11, 2020 at 10:52:19AM +0800, Tom Yan wrote:
> > > > How is that an advantage?  Applications that works with block devices
> > > > don't really work with a magic passthrough character device.
> > > 
> > > You must assume that there are applications already assuming that
> > > work. (And it will, at least in some cases, if this series get
> > > merged.)
> > 
> > Why "must" I assume that?
> > 
> > > And you have not been giving me a solid point anyway, as I said, it's
> > > just queue_*() at the end of the day; regardless of whether those
> > > would work in all sg cases, we have been using them in the sg driver
> > > anyway.
> > > 
> > > And it's not like we have to guarantee that (the) ioctls can work in
> > > every case anyway, right? (Especially when they aren't named SG_*).
> > 
> > No.  While it is unfortunte we have all kinds of cases of ioctls working
> > differnetly on different devices.
> > 
> > > 
> > > I mean, what's even your point? How do you propose we fix this?
> > 
> > I propose to not "fix" anything, because nothing is broken except for
> > maybe a lack of documentation.
> 
> Alan Stern are you reading this thread? Why do I ask, you may ask?
> Because 'git blame' fingers you:
> 
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
> 
> commit 44ec95425c1d9dce6e4638c29e4362cfb44814e7
> Author: Alan Stern <stern@rowland.harvard.edu>
> Date:   Tue Feb 20 11:01:57 2007 -0500
> 
>     [SCSI] sg: cap reserved_size values at max_sectors
> 
>     This patch (as857) modifies the SG_GET_RESERVED_SIZE and
>     SG_SET_RESERVED_SIZE ioctls in the sg driver, capping the values at
>     the device's request_queue's max_sectors value.  This will permit
>     cdrecord to obtain a legal value for the maximum transfer length,
>     fixing Bugzilla #7026.
> 
>     The patch also caps the initial reserved_size value.  There's no
>     reason to have a reserved buffer larger than max_sectors, since it
>     would be impossible to use the extra space.
> 
>     The corresponding ioctls in the block layer are modified similarly,
>     and the initial value for the reserved_size is set as large as
>     possible.  This will effectively make it default to max_sectors.
>     Note that the actual value is meaningless anyway, since block devices
>     don't have a reserved buffer.
> 
>     Finally, the BLKSECTGET ioctl is added to sg, so that there will be a
>     uniform way for users to determine the actual max_sectors value for
>     any raw SCSI transport.
> 
>     Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
>     Acked-by: Jens Axboe <jens.axboe@oracle.com>
>     Acked-by: Douglas Gilbert <dougg@torque.net>
>     Signed-off-by: James Bottomley <James.Bottomley@SteelEye.com>
> 
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Oops, I ack-ed this patch from 2007:-)

The Bugzilla entry it talks about is from 2006!

>  Anyway it would seem BLKSECTGET ioctl
> was meant to be a "uniform way to determine the actual max_sectors value for
> any raw SCSI transport."

Right.  The question at hand was: Given an open file descriptor for an 
SG device, how can a program determine the largest amount it can send in 
a single transfer?  This ioctl seemed to be the best answer.

See comment #26 (https://bugzilla.kernel.org/show_bug.cgi?id=7026#c26) 
and following for the viewpoint of the notoriously prickly author of 
cdrecord.

>  Given that the initial implementation of BLKSECTGET
> now seems to be at odds with other implementations, what should we do?
> 
> It is possible that it was correct on 2007 and the BLKSECTGET ioctl has
> changed elsewhere but failed to fix the sg driver's implementation.

Could be.  Also, I'm not sure how careful people were back then to 
distinguish between logical and physical sector sizes.

> If I get a vote then it would be for Tom Yan's approach: reduce entropy or
> it will overwhelm us :-)
> 
> 
> So Christoph, it IS documented, both in the above commit message and:
>    https://doug-gilbert.github.io/sg_v40.html
> 
> in Table 8. So please stop with your "maybe a lack of documentation" line.

My vote is not to change an interface which a program like cdrecord may 
currently rely on.

I can understand Christoph's point about documentation.  It would be 
good to have something in the actual kernel source, rather than in the 
history or somebody's github files.

Alan Stern

Re: [PATCH RESEND 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

On Fri, 11 Sep 2020 at 14:48, Christoph Hellwig <hch@lst.de> wrote:
>
> On Fri, Sep 11, 2020 at 10:52:19AM +0800, Tom Yan wrote:
> > > How is that an advantage?  Applications that works with block devices
> > > don't really work with a magic passthrough character device.
> >
> > You must assume that there are applications already assuming that
> > work. (And it will, at least in some cases, if this series get
> > merged.)
>
> Why "must" I assume that?

Because of the name. The whole discussion was about the name. (Well,
also because 'I must assume that some applications has already been
"relying" on the wrong name.')

>
> > And you have not been giving me a solid point anyway, as I said, it's
> > just queue_*() at the end of the day; regardless of whether those
> > would work in all sg cases, we have been using them in the sg driver
> > anyway.
> >
> > And it's not like we have to guarantee that (the) ioctls can work in
> > every case anyway, right? (Especially when they aren't named SG_*).
>
> No.  While it is unfortunte we have all kinds of cases of ioctls working
> differnetly on different devices.
>
> >
> > I mean, what's even your point? How do you propose we fix this?
>
> I propose to not "fix" anything, because nothing is broken except for
> maybe a lack of documentation.

It won't really help anyway. Documenting something wrong won't make it
correct anyway. It's just wrong, semantically wrong, logically wrong;
expecting people to "rtfm and realize the difference" only makes it
even more wrong. End of story.

This was never about whether it is "broken" or whether we should
provide means to fetch the limit in the number of bytes or sectors. It
was always just about the name.

Just one last question. So should we not even replace the bit shift
with queue_logicial_block_size() in max_sectors_bytes()? Given that we
"must assume that it has been that way for long enough so applications
must have been dealing with the flaw on their own already and fixing
it will only breaks them"?

[PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 0e3f084141a3..deeab4855172 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -848,10 +848,11 @@ static int srp_done(Sg_fd *sfp, Sg_request *srp)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static void
-- 
2.28.0

Re: [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes()

[Greg KH]

On Sun, Sep 06, 2020 at 09:27:15AM +0800, Tom Yan wrote:
> Signed-off-by: Tom Yan <tom.ty89@gmail.com>
> ---
>  drivers/scsi/sg.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

I know I don't take patches without any changelog text at all, but maybe
the scsi maintainers are more leniant.

You should write changelogs that explain _why_ you are doing what you
are doing, you just say what you did, with no reasoning at all.

Same for another patch in this series.

thanks,

greg k-h

Re: [PATCH RESEND 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

The resend is done to add linux-api@vger.kernel.org to the CC list. I
also removed some CC because the email addresses no longer exist (and
accidentally made a typo to one that still does, hence the second
resend). I don't know if that counts as a change.

I didn't think 3/4 and 4/4 requires further explanation, as I thought
they are self-explanatory enough (logical sector size has never been,
or at least is no longer, necessarily 512). I can add that to the
commit message.

P.S. Even I myself isn't exactly sure what/which clamping should be
used in max_sectors_bytes(). The reason I picked USHRT_MAX is that
BLKSECTGET in sg should work identically to its equivalence in the
block layer, regardless of whether that is
technically/programmatically necessary. So I decided to use the same
clamping in max_sector_bytes(). But it seems fine/correct to clamp
(max_sectors * logical_sector_size) to INT_MAX instead
(https://github.com/torvalds/linux/blob/v5.9-rc3/block/blk-mq.c#L3211).
(On the other hand, in that case it could end up being inconsistent to
what BLKSECTGET + BLKSSZGET reports). Perhaps I should add my
uncertainty / the alternative to the commit message.

Regards,
Tom

On Sun, 6 Sep 2020 at 14:26, Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Sun, Sep 06, 2020 at 09:27:15AM +0800, Tom Yan wrote:
> > Signed-off-by: Tom Yan <tom.ty89@gmail.com>
> > ---
> >  drivers/scsi/sg.c | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
>
> I know I don't take patches without any changelog text at all, but maybe
> the scsi maintainers are more leniant.
>
> You should write changelogs that explain _why_ you are doing what you
> are doing, you just say what you did, with no reasoning at all.
>
> Same for another patch in this series.
>
> thanks,
>
> greg k-h

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

[Tom Yan]

It should give out the maximum number of sectors per request
instead of maximum number of bytes, as that is what its equivalence
in the block layer does (that is also the reason for the USHRT_MAX
clamp; they should always have identical behaviour when possbile).

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
v2: add more details in commit messages
 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,
-- 
2.28.0

[PATCH v2 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

Provide an ioctl to get the logical sector size so that the maximum
bytes per request can be derived.

Follow-up of the BLKSECTGET fix.

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index e57831910228..0e3f084141a3 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1118,6 +1118,8 @@ sg_ioctl_common(struct file *filp, Sg_device *sdp, Sg_fd *sfp,
 		max_sectors = min_t(unsigned int, USHRT_MAX,
 				    queue_max_sectors(sdp->device->request_queue));
 		return put_user(max_sectors, ip);
+	case BLKSSZGET:
+		return put_user(queue_logical_block_size(sdp->device->request_queue), ip);
 	case BLKTRACESETUP:
 		return blk_trace_setup(sdp->device->request_queue,
 				       sdp->disk->disk_name,
-- 
2.28.0

[PATCH v2 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

Logical sector size was never / is no longer necessarily 512.

Programatically speaking it may not be necessary for us to clamp
max_sectors to USHRT_MAX here, but since such clamping is used in
BLKSECTGET, it's probably a good idea to have it here too, so that
what the function returns is consistent to what the ioctl reports.

Alternatively we can clamp (max_sectors * logical_block_size) to
INT_MAX instead, or maybe even not clamping it at all.

P.S. sg_reserved_size is initially set to INT_MAX by
blk_mq_init_allocated_queue().

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 0e3f084141a3..deeab4855172 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -848,10 +848,11 @@ static int srp_done(Sg_fd *sfp, Sg_request *srp)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static void
-- 
2.28.0

[PATCH v2 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

Programatically speaking it may not be necessary for us to clamp
max_sectors to USHRT_MAX here, but since such clamping is used in
BLKSECTGET, it's probably a good idea to have it here too, so that
what the function returns is consistent to what the ioctl reports.

Alternatively we can clamp (max_sectors * logical_block_size) to
INT_MAX instead, or maybe even not clamping it at all.

P.S. sg_reserved_size is initially set to INT_MAX by
blk_mq_init_allocated_queue().

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
 block/scsi_ioctl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index ef722f04f88a..ae6aae40a8b6 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -73,10 +73,11 @@ static int sg_set_timeout(struct request_queue *q, int __user *p)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static int sg_get_reserved_size(struct request_queue *q, int __user *p)
-- 
2.28.0

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

[Tom Yan]

It should give out the maximum number of sectors per request
instead of maximum number of bytes, as that is what its equivalence
in the block layer does (that is also the reason for the USHRT_MAX
clamp; they should always have identical behaviour when possbile).

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
v2: add more details in commit messages
v3: add a missed line back to the commit message of the last patch
 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,
-- 
2.28.0

[PATCH v3 2/4] scsi: sg: implement BLKSSZGET

[Tom Yan]

Provide an ioctl to get the logical sector size so that the maximum
bytes per request can be derived.

Follow-up of the BLKSECTGET fix.

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index e57831910228..0e3f084141a3 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -1118,6 +1118,8 @@ sg_ioctl_common(struct file *filp, Sg_device *sdp, Sg_fd *sfp,
 		max_sectors = min_t(unsigned int, USHRT_MAX,
 				    queue_max_sectors(sdp->device->request_queue));
 		return put_user(max_sectors, ip);
+	case BLKSSZGET:
+		return put_user(queue_logical_block_size(sdp->device->request_queue), ip);
 	case BLKTRACESETUP:
 		return blk_trace_setup(sdp->device->request_queue,
 				       sdp->disk->disk_name,
-- 
2.28.0

[PATCH v3 3/4] scsi: sg: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

Logical sector size was never / is no longer necessarily 512.

Programatically speaking it may not be necessary for us to clamp
max_sectors to USHRT_MAX here, but since such clamping is used in
BLKSECTGET, it's probably a good idea to have it here too, so that
what the function returns is consistent to what the ioctl reports.

Alternatively we can clamp (max_sectors * logical_block_size) to
INT_MAX instead, or maybe even not clamping it at all.

P.S. sg_reserved_size is initially set to INT_MAX by
blk_mq_init_allocated_queue().

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

diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 0e3f084141a3..deeab4855172 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -848,10 +848,11 @@ static int srp_done(Sg_fd *sfp, Sg_request *srp)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static void
-- 
2.28.0

[PATCH v3 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

Logical sector size was never / is no longer necessarily 512.

Programatically speaking it may not be necessary for us to clamp
max_sectors to USHRT_MAX here, but since such clamping is used in
BLKSECTGET, it's probably a good idea to have it here too, so that
what the function returns is consistent to what the ioctl reports.

Alternatively we can clamp (max_sectors * logical_block_size) to
INT_MAX instead, or maybe even not clamping it at all.

P.S. sg_reserved_size is initially set to INT_MAX by
blk_mq_init_allocated_queue().

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
 block/scsi_ioctl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index ef722f04f88a..ae6aae40a8b6 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -73,10 +73,11 @@ static int sg_set_timeout(struct request_queue *q, int __user *p)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static int sg_get_reserved_size(struct request_queue *q, int __user *p)
-- 
2.28.0

[PATCH RESEND 4/4] block/scsi_ioctl.c: use queue_logical_sector_size() in max_sectors_bytes()

[Tom Yan]

Signed-off-by: Tom Yan <tom.ty89@gmail.com>
---
 block/scsi_ioctl.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/block/scsi_ioctl.c b/block/scsi_ioctl.c
index ef722f04f88a..ae6aae40a8b6 100644
--- a/block/scsi_ioctl.c
+++ b/block/scsi_ioctl.c
@@ -73,10 +73,11 @@ static int sg_set_timeout(struct request_queue *q, int __user *p)
 static int max_sectors_bytes(struct request_queue *q)
 {
 	unsigned int max_sectors = queue_max_sectors(q);
+	unsigned int logical_block_size = queue_logical_block_size(q);
 
-	max_sectors = min_t(unsigned int, max_sectors, INT_MAX >> 9);
+	max_sectors = min_t(unsigned int, max_sectors, USHRT_MAX);
 
-	return max_sectors << 9;
+	return max_sectors * logical_block_size;
 }
 
 static int sg_get_reserved_size(struct request_queue *q, int __user *p)
-- 
2.28.0

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

[Douglas Gilbert]

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@interlog.com), 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@interlog.com> 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@gmail.com>
>>>> ---
>>>>    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@vger.kernel.org, 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
> 

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

[Tom Yan]

On Sun, 6 Sep 2020 at 13:09, Douglas Gilbert <dgilbert@interlog.com> wrote:
>
> 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@interlog.com), notes:
>
>
> And bumping the version number is appropriate for an interface
> tweak/correction.

I wasn't (and still isn't) sure how much I should bump.  Maybe 36000 /
3.6.0 will do? (Seems to deserve the bigger bump)

>
> 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.

"this ioctl value replicates what a block layer device file (e.g.
/dev/sda) will do with the same value. It calls the
queue_max_sectors() helper on the owning device's command queue. The
resulting number represents the maximum number of logical sectors of a
single request that the block layer will accept."? and for BLKSSZGET
"the resulting number represents the logical sector size"?

>
> 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@interlog.com> 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@gmail.com>
> >>>> ---
> >>>>    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@vger.kernel.org, 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
> >
>