netdev - Re: [PATCH]: Schedule correct qdisc in watchdog.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 19 Aug 2008 05:37:45 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	denys@...p.net.lb, netdev@...r.kernel.org
Subject: Re: [PATCH]: Schedule correct qdisc in watchdog.

On Mon, Aug 18, 2008 at 04:56:38PM -0700, David Miller wrote:
> From: Jarek Poplawski <jarkao2@...il.com>
> Date: Mon, 18 Aug 2008 12:58:05 +0000
> 
> > On Mon, Aug 18, 2008 at 03:45:29PM +0300, Denys Fedoryshchenko wrote:
> > > Patch applied, got another warning.
> > 
> > I hope I'll figure this out before evening. Probably it's safer
> > to stop testing for a while.
> 
> We have to put the kfree() of the qdisc back into an RCU handler,
> that's all.

As a matter of fact, I still have some doubts about this. Top level
qdiscs must be deactivated before destroy and during this process we
make sure nothing can use them anymore. So, since this all is under
rtnl_lock(), I wonder if we really need this qdisc root_lock around
qdisc_destroy() for root qdiscs at all.

Maybe there are some common lists which depend on this and rtnl_lock
isn't enough for them. If so, maybe it's easier to change locking in
these places. But, of course, I can miss something.

I'm not against RCU here if it's really needed. Otherwise, this
destroying in softirq context, without rtnl_lock() looks like a
potential obstacle for the future.

Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html