| Message ID | 20191217221708.3730997-1-arnd@arndb.de |
|---|---|
| Headers | show |
| Series | block, scsi: final compat_ioctl cleanup | expand |
On Tue, Dec 17, 2019 at 11:17 PM Arnd Bergmann <arnd@arndb.de> wrote: > My plan was originally to keep the SCSI and block parts separate. > This did not work easily because of interdependencies: I cannot > do the final SCSI cleanup in a good way without first addressing the > CDROM ioctls, so this is one series that I hope could be merged through > either the block or the scsi git trees, or possibly both if you can > pull in the same branch. I have included the branch in my y2038 branch now, it should show up in the following linux-next snapshots, but I'm still hoping for the block or scsi maintainers to merge the pull request into their trees for v5.6 Jens, James, Martin: Any suggestion for how this should be merged? Arnd
On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote: > Most of the HDIO ioctls are only used by the obsolete drivers/ide > subsystem, these can be handled by changing ide_cmd_ioctl() to be aware > of compat mode and doing the correct transformations in place and using > it as both native and compat handlers for all drivers. > > The SCSI drivers implementing the same commands are already doing > this in the drivers, so the compat_blkdev_driver_ioctl() function > is no longer needed now. > > The BLKSECTSET and HDIO_GETGEO_BIG ioctls are not implemented > in any driver any more and no longer need any conversion. [...] I noticed that HDIO_DRIVE_TASKFILE, handled by ide_taskfile_ioctl() in drivers/ide/ide-taskfile.c, never had compat handling before. After this patch it does, but its argument isn't passed through compat_ptr(). Again, doesn't really matter because IDE isn't a thing on s390. Ben. -- Ben Hutchings, Software Developer Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom
On Wed, Dec 18, 2019 at 10:11 PM Ben Hutchings <ben.hutchings@codethink.co.uk> wrote: > On Tue, 2019-12-17 at 23:17 +0100, Arnd Bergmann wrote: > > Most of the HDIO ioctls are only used by the obsolete drivers/ide > > subsystem, these can be handled by changing ide_cmd_ioctl() to be aware > > of compat mode and doing the correct transformations in place and using > > it as both native and compat handlers for all drivers. > > > > The SCSI drivers implementing the same commands are already doing > > this in the drivers, so the compat_blkdev_driver_ioctl() function > > is no longer needed now. > > > > The BLKSECTSET and HDIO_GETGEO_BIG ioctls are not implemented > > in any driver any more and no longer need any conversion. > [...] > > I noticed that HDIO_DRIVE_TASKFILE, handled by ide_taskfile_ioctl() in > drivers/ide/ide-taskfile.c, never had compat handling before. After > this patch it does, but its argument isn't passed through compat_ptr(). > Again, doesn't really matter because IDE isn't a thing on s390. I checked again, and I think it's worse than that: ide_taskfile_ioctl() takes an ide_task_request_t argument, which is not compatible at all (it has two long members). I suspect what happened here is that I confused it with ide_cmd_ioctl(), which takes a 'struct ide_taskfile' argument that /is/ compatible. I don't think there is a point in adding a handler now: most users of drivers/ide are 32-bit only, and nobody complained so far, but I would add this change if you agree: diff --git a/drivers/ide/ide-ioctls.c b/drivers/ide/ide-ioctls.c index f6497c817493..83afee3983fe 100644 --- a/drivers/ide/ide-ioctls.c +++ b/drivers/ide/ide-ioctls.c @@ -270,6 +270,9 @@ int generic_ide_ioctl(ide_drive_t *drive, struct block_device *bdev, case HDIO_DRIVE_TASKFILE: if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SYS_RAWIO)) return -EACCES; + /* missing compat handler for HDIO_DRIVE_TASKFILE */ + if (in_compat_syscall()) + return -ENOTTY; if (drive->media == ide_disk) return ide_taskfile_ioctl(drive, arg); return -ENOMSG; Arnd
Hi Arnd!
> Any suggestion for how this should be merged?
I'm pretty flexible. When you post v3 I'll try to set up a branch to get
an idea what conflicts we might have to deal with. And then we can take
it from there.
--
Martin K. Petersen Oracle Linux Engineering