netdev - Re: [PATCH] GENETLINK: Global lock refined to family granularity

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:	Mon, 31 Mar 2008 12:33:50 +0200
From:	Thomas Graf <tgraf@...g.ch>
To:	Richard MUSIL <richard.musil@...com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] GENETLINK: Global lock refined to family granularity

* Richard MUSIL <richard.musil@...com> 2008-03-27 13:05
> This patch is a revive of the patch I posted half a year ago. In that time
> Thomas Graf (who was acting as maintainer of genetlink module) accepted
> the idea, but suggested to do it using RCU lists. Since I did not have
> and experience with RCU lists, we agreed, he will implement it himself.
> 
> Since that time, he neither did it, nor replied to my recent emails and
> I guess he is no longer active.

Sorry but I didn't receive any recent emails.

> I am asking, whomever maintains genetlink right now, for including this
> patch. (Currently, this is patch to linux-2.6.25-rc7.)
> 
> The idea behind (i.e. why I needed it) is device driver, which uses
> genetlink to talk to userspace and which creates virtual devices and
> registers families for them in the runtime. So these devices can also
> talk to userspace using genetlink.
> 
> Current implementation prevents that, because processing any single
> genetlink message blocks complete genetlink infrastructure (i.e.
> registrations, and deregistrations).

On a first sight your patch seemed very legitimate although the amount
of locks taken for every single message received was very irritating.
Also your patch explicitely allows registration operations but when the
family being currently received on is manipulated, it will simply deadlock.
So this patch is about allowing registration of operations for other
families at the cost of two additional locks for every message received
combined with complex locking logic. All a bit much for something that
can be easly solved using a workqueue.

BTW, your patch does not account for multicast group registration.
--
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