lkml.org 
[lkml]   [2001]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NETDEV_CHANGE events when __LINK_STATE_NOCARRIER is modified
kuznet@ms2.inr.ac.ru 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 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/

\
 
 \ /
  Last update: 2005-03-22 13:17    [W:0.055 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site