[EMAIL PROTECTED] wrote:
>
> Hello!
>
> > It protects the as-yet-unchanged PCI and Cardbus drivers from a
> > fatal race.
>
> Fatal race remained.
Don't think so. We have exclusion against all netdevice ioctls
across probe. Still. It doesn't matter.
> Andrew, you start again the story about white bull. 8)
> We have already discussed this. Device cannot stay in device list
> uninitialzied. Period.
>
> I am sorry, but no compromise is possible. With Jeff's approach all
> the references to init_etherdev and dev_probe_lock must be eliminated
> in 2.4.
Once init_etherdev() has gone, yes, dev_probe_lock() can go.
> > and sys_ioctl() both do lock_kernel(). If xxx_probe() drops the BKL,
>
> Again, BKL has nothing to do with this (and ioctl does not hold it)
asmlinkage long sys_ioctl(unsigned int fd, unsigned int cmd, unsigned long arg)
{
struct file * filp;
unsigned int flag;
int on, error = -EBADF;
filp = fget(fd);
if (!filp)
goto out;
error = 0;
lock_kernel();
The CPU running ifconfig spins here.
> It looks like you forgot all the discussion around your own patch. 8)
>
> If you want I can retransmit the mails which resulted in your patch?
It doesn't matter... I think we agree that init_etherdev() must
die, and dev_probe_lock() with it, and that Jeff's alloc_etherdev()
is an appropriate way of doing it?
Actually, yes. Please tell me what problem you think we
still have in current kernels, which dev_probe_lock()
does not prevent?
-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
