On Wed, 2007-09-12 at 05:34 -0700, David Miller wrote:
> From: Johannes Berg <[EMAIL PROTECTED]>
> Date: Thu, 06 Sep 2007 17:19:55 +0200
>
> >
> > Oh btw. Can we stick a might_sleep() into dev_close() *before* the test
> > whether the device is up? That way, we'd have seen the bug, but
> > appare
From: Johannes Berg <[EMAIL PROTECTED]>
Date: Thu, 06 Sep 2007 17:19:55 +0200
>
> Oh btw. Can we stick a might_sleep() into dev_close() *before* the test
> whether the device is up? That way, we'd have seen the bug, but
> apparently nobody before Florian ever did a 'ip link set wmaster0 down'
> w
On Fri, 2007-09-07 at 18:01 +0200, Michael Buesch wrote:
> What's the problem with trying to lock it?
I think I had a problem with it once when I inserted it into some code
that was atomic and it all blew up badly ;) Nothing important really but
it sort of made me not like it much.
johannes
si
On Friday 07 September 2007, Johannes Berg wrote:
> On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
>
> > Looks good to me from an RCU viewpoint. I cannot claim familiarity with
> > this code. I therefore especially like the indications of where RTNL
> > is held and not!!!
>
> :)
>
On Fri, 2007-09-07 at 07:25 -0700, Paul E. McKenney wrote:
> > > > @@ -226,22 +225,22 @@ void ieee80211_if_reinit(struct net_devi
> > > > /* Remove all virtual interfaces that use this BSS
> > > > * as their sdata->bss */
> > > > struct ieee80211_su
On Fri, 2007-09-07 at 07:25 -0700, Paul E. McKenney wrote:
> > I don't like ASSERT_RTNL() much because it actually tries to lock it.
> > I'd be much happer if it was WARN_ON(!mutex_locked(&rtnl_mutex)) or
> > something equivalent.
>
> Ah! It would indeed be nice to have a lower-overhead ASSERT_R
On Fri, Sep 07, 2007 at 03:27:15PM +0200, Johannes Berg wrote:
> On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
>
> > Looks good to me from an RCU viewpoint. I cannot claim familiarity with
> > this code. I therefore especially like the indications of where RTNL
> > is held and not!!
On Thu, 2007-09-06 at 08:46 -0700, Paul E. McKenney wrote:
> Looks good to me from an RCU viewpoint. I cannot claim familiarity with
> this code. I therefore especially like the indications of where RTNL
> is held and not!!!
:)
> Some questions below based on a quick scan. And a global questi
On Thu, Sep 06, 2007 at 03:36:55PM +0200, Johannes Berg wrote:
> On Thu, 2007-09-06 at 20:36 +0800, Herbert Xu wrote:
>
> > Yeah I think they're all under RTNL too. So you don't need to
> > take the lock here at all since you should already have the RTNL.
>
> Ok, this patch gets rid of the lock.
On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
> On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> >
> > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
>
> This is where the bug is. You cannot call dev_close f
On Thu, 2007-09-06 at 20:36 +0800, Herbert Xu wrote:
> Yeah I think they're all under RTNL too. So you don't need to
> take the lock here at all since you should already have the RTNL.
Ok, this patch gets rid of the lock. I'd appreciate if you could give it
a quick look for obvious RCU abuse as
On Thu, 2007-09-06 at 18:22 +0530, Satyam Sharma wrote:
> Unless I missed something obvious (let me know if that's the case! :-)
> an RCU-protected list would suffer the same fate. list_for_each_xxx_rcu()
> must be under rcu_read_lock() which == preempt_disable() ...
Right. But I'm thinking that
On Thu, 2007-09-06 at 20:36 +0800, Herbert Xu wrote:
> Johannes Berg <[EMAIL PROTECTED]> wrote:
> >
> > Hah, I suspected as much but didn't have a chance to look yet. I had
> > plans to replace that sub_if_list with an RCU list and not require the
> > lock there, but that's far off. Any ideas how t
On Thu, 6 Sep 2007, Johannes Berg wrote:
> On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
> > On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> > >
> > > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d
> > > > > [mac8
Johannes Berg <[EMAIL PROTECTED]> wrote:
>
> Hah, I suspected as much but didn't have a chance to look yet. I had
> plans to replace that sub_if_list with an RCU list and not require the
> lock there, but that's far off. Any ideas how to fix this? We can't
> reject the master stop so we have to wal
On Thu, 2007-09-06 at 16:23 +0800, Herbert Xu wrote:
> On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> >
> > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
>
> This is where the bug is. You cannot call dev_close f
On Thu, Sep 06, 2007 at 02:11:46PM +0530, Satyam Sharma wrote:
> On Thu, 6 Sep 2007, Herbert Xu wrote:
>
> > On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> > >
> > > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d
> > > >
On Thu, 6 Sep 2007, Herbert Xu wrote:
> On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
> >
> > > > [ 382.529041] [] dev_close+0x24/0x67
> > > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
>
> This is where the bug is. You cannot call dev_close from an
> ato
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
>
> > > [ 382.529041] [] dev_close+0x24/0x67
> > > [ 382.529052] [] ieee80211_master_stop+0x4a/0x6d [mac80211]
This is where the bug is. You cannot call dev_close from an
atomic context as i33380211_master_stop does it within spi
On Thu, Sep 06, 2007 at 10:32:33AM +0530, Satyam Sharma wrote:
>
> Probably tangential, but Herbert, is the call to synchronize_rcu() in
> dev_deactivate() really correct?
Yes it's still correct as of today's tree. Of course patches
such as preemptible RCU may change things but they'll need to
a
the wireless to eth1) and when issueing an
> > ifconfig eth1 down i get a
> >
> > BUG: scheduling while atomic: ifconfig/0x0002/4170
Is this reproducible? Also, please send your .config.
BTW the calltrace below shows that eth1 was the wireless interface when
y
e: authenticate with AP 00:0c:41:de:12:e1
> [ 142.976883] wlan0_rename: RX authentication from 00:0c:41:de:12:e1 (alg=0
> transaction=2 status=0)
> [ 142.976891] wlan0_rename: authenticated
> [ 142.976895] wlan0_rename: associate with AP 00:0c:41:de:12:e1
> [ 142.979389] wlan0_r
ue. Then i see
a eth1394 mac address on an interface which typically shouldn exist
(udev should rename the wireless to eth1) and when issueing an
ifconfig eth1 down i get a
BUG: scheduling while atomic: ifconfig/0x0002/4170
On the next boot i see the eth1394 mac address on th
23 matches
Mail list logo
