On Fri, Nov 03, 2000 at 10:03:48PM +0300, kuznet@ms2.inr.ac.ru wrote:
> Hello!
>
> > It is not safe, just not worse than 2.2.
>
> Andi...... 8)
>
> That issue, which was meant here, it is 100% safe.
>
> I start to suspect you did not look into this code since 2.2.
I actually did, and that is when all this started. I found lots of code
that does hardware register access without protecting against interrupts
or checking if the interface is up.
Tulip, eepro100 seem to be ok.
3c59x seems to be buggy
de4x5 is probably also buggy in regard to this.
It also does this:
case DE4X5_GET_STATS: /* Get the driver statistics */
ioc->len = sizeof(lp->pktStats);
spin_lock_irqsave(&lp->lock, flags);
if (copy_to_user(ioc->data, &lp->pktStats, ioc->len)) return -EFAULT;
spin_unlock_irqrestore(&lp->lock, flags);
break;
rrunner does GFP_KERNEL kmallocs and copy_to_user with a spin lock held. The
hardware register access is probably also racy with interrupts (not 100% sure)
depca seems to be buggy too.
... [this was just a 5 minutes grep session. I suspect most of these bugs
were also in 2.2]
Of course the window is very small because nobody really uses these interrupts
regularly.
> I acn assume that nothing has changed in ISDN,
> in other drivers big changes happened. 8)
ISDN syncppp seems to be slightly buggy (module unload race with slhc, compressor
init dubious, racy device management that could be cured by the kernel lock),
non PPP ISDN does not have a network ioctl.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Nov 07 2000 - 21:00:14 EST