On 04-12-2007 23:26, Jarek Poplawski wrote:
...
> But, IMHO, blowing ASSERT_RTNL up in a few places shouldn't be much
> worse. After all, how long such a debugging code should be kept. It
> seems, at least sometimes we should be a bit more confident of how
> it's called.
I see this won't be done t
2007/12/5, Herbert Xu <[EMAIL PROTECTED]>:
> The idea is to not touch the unicast stuff at all on the multicast path.
>
> Anyway, this was discussed on netdev so please check the archives because
> there is more to this than just changing the multicast handling. We also
> talked about consolidatin
On Wed, Dec 05, 2007 at 02:30:10PM +0900, Joonwoo Park wrote:
>
> @@ -140,9 +147,11 @@ int dev_mc_sync(struct net_device *to, struct net_device
> *from)
> da = next;
> }
> if (!err)
> - __dev_set_rx_mode(to);
> + pending = __dev_set_rx_mode(to);
>
2007/12/5, Herbert Xu <[EMAIL PROTECTED]>:
> Joonwoo Park <[EMAIL PROTECTED]> wrote:
> > Hi,
> > dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
> > netif_tx_lock_bh)
> > therefore __dev_set_promiscuity can be called with softirq disabled.
> > It will cause in_interrupt() to retu
Joonwoo Park <[EMAIL PROTECTED]> wrote:
> Hi,
> dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
> netif_tx_lock_bh)
> therefore __dev_set_promiscuity can be called with softirq disabled.
> It will cause in_interrupt() to return true and ASSERT_RTNL warning.
> Is there a good solu
Joonwoo Park wrote, On 12/04/2007 10:48 AM:
> Hi,
> dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
> netif_tx_lock_bh)
> therefore __dev_set_promiscuity can be called with softirq disabled.
> It will cause in_interrupt() to return true and ASSERT_RTNL warning.
> Is there a good
Hi,
dev_set_rx_mode calls __dev_set_rx_mode with softirq disabled (by
netif_tx_lock_bh)
therefore __dev_set_promiscuity can be called with softirq disabled.
It will cause in_interrupt() to return true and ASSERT_RTNL warning.
Is there a good solution to fix it besides blowing ASSERT_RTNL up?
Than
