netdev - Re: [PATCH 1/2] Revert "genetlink: fix family dump race"

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]

Message-Id: <20130822.132631.2273195424430844661.davem@davemloft.net>
Date:	Thu, 22 Aug 2013 13:26:31 -0700 (PDT)
From:	David Miller <davem@...emloft.net>
To:	johannes@...solutions.net
Cc:	netdev@...r.kernel.org, tgraf@...g.ch, johannes.berg@...el.com
Subject: Re: [PATCH 1/2] Revert "genetlink: fix family dump race"

From: Johannes Berg <johannes@...solutions.net>
Date: Wed, 21 Aug 2013 16:08:02 +0200

> From: Johannes Berg <johannes.berg@...el.com>
> 
> This reverts commit 58ad436fcf49810aa006016107f494c9ac9013db.
> 
> It turns out that the change introduced a potential deadlock
> by causing a locking dependency with netlink's cb_mutex. I
> can't seem to find a way to resolve this without doing major
> changes to the locking, so revert this.
> 
> Signed-off-by: Johannes Berg <johannes.berg@...el.com>

So I've applied this since everyone agrees that we should revert
this change.

How to deal with the problem we were attempting to solve is still
under discussion.  It seems that even if we go to RCU we must also
address to module reference count issue.

I think the existing locking is very messy, and RCU looks a lot
cleaner and has potential for future improvements to the scalability
of dumps.

So I'd like to propose that we combine Johannes's RCU conversion
with some variant of the module reference count fix.

Can you guys work together and come up with something I can apply?

Thanks.
--
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