On Sun, Aug 17, 2008 at 02:34:44PM -0700, David Miller wrote:

quoted text
> From: Jarek Poplawski

> Date: Sun, 17 Aug 2008 15:42:54 +0200

>

> > Jarek Poplawski wrote, On 08/14/2008 01:24 PM:

> >

> > > On Wed, Aug 13, 2008 at 03:19:18PM -0700, David Miller wrote:

> > > ...

> > >> Ok, so what I'm going to do is check in my patch and then try

> > >> to figure out how to resolve this "both bits clear" scenerio.

> > >

> > > BTW, here is my older doubt revisited, where I hope to be re-considered/

> > > re-convinced, if possible...

> >

> >

> > After problems while testing this by Denys in another thread

> > I withdraw this patch.

>

> Well, I knew it was completely wrong from the beginning, sorry

> to say :-)

>

> This stuff can't be done outside of RCU, period.  I moved all of this

> work into RCU for a reason, I really meant it, and none of the reasons

> for that move have changed :-)

>

> If we want to do it under RTNL we have to do something like schedule a

> workqueue from the RCU handler and then take the RTNL there.

Actually, I've only asked you to withdraw this patch for now, but I'm

still not convinced you're right. You should better show me first the

place where this can make a difference. (I think this test broke for

some other non RCU reason.) So, maybe you're right, but I've to check

this more.
BTW, I guess you've seen this other thread: "panic 2.6.27-rc3-git2,

qdisc_dequeue_head" where Denys and I fight with this new locking.

Alas, it looks to me as a real mess, and I currently try with this

previous idea of netdev_queue->qdisc_lock, which you didn't like too.

But, after looking at the current bugs shown by debugging I really

think we'll have bugs here all the time without simplifying this.

I think my concept should work soon, but if you don't agree with

this at all we can stop and wait for better ideas.
Thanks,

Jarek P.
--

To unsubscribe from this list: send the line "unsubscribe netdev" in

the body of a message to majordomo@vger.kernel.org

More majordomo info at  http://vger.kernel.org/majordomo-info.html