Re: ioctl cleanups: enable sg_io and serial stuff to be shared

Arnd Bergmann (arnd@arndb.de)
Wed, 7 May 2003 17:46:15 +0200


On Wednesday 07 May 2003 17:16, Pavel Machek wrote:

> > Has anyone solved the register_ioctl32_conversion() from module problem
> > yet? The patch will break if you build scsi as a module because you
> > never unregister the conversion helper on unload.
> > Even if you do the unregister from a module_exit() function, there
> > will still be a small race against running ioctl handlers. I suppose
> > we have to add an 'owner' field to struct ioctl_trans in order to
> > get it right.
>
> Its in drivers/block/scsi_ioctl.c. AFAICS, its always compiled in, so
> I'm not hitting that problem *yet*.

No, it has indeed been possible to build scsi as a module for a long
time and in that case, scsi_ioctl becomes part of that module. The same
problem also exists for any user of register_ioctl32_conversion(), e.g.
ieee1394.

> > > + ss.iomem_base = (void *)((unsigned long)ss.iomem_base & 0xffffffff);
> >
> > you need compat_ptr() for iomem_base as well
>
> Its not pointer, AFAICS (at least it can not be dereferenced by
> userspace).

Right, it appears to be a physical address, which therefore would require
a new mapping macro to be really correct. If this were used on s390, that
macro would be the same as compat_ptr(), the other architectures probably
need a simple cast (again, like compat_ptr()). Either of 1. new macro, 2.
compat_ptr() or 3. the existing code works correctly here, so just do
whichever you prefer. Maybe somebody else has a strong opinion on it.

Arnd <><

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/