linux-kernel - Re: [PATCH 01/23] ns: Add common refcount into ns_common add use it as counter for net

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 for Android: free password hash cracker in your pocket

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

Date:   Thu, 30 Jul 2020 17:59:17 +0200
From:   Christian Brauner <christian.brauner@...ntu.com>
To:     Kirill Tkhai <ktkhai@...tuozzo.com>
Cc:     akpm@...ux-foundation.org, viro@...iv.linux.org.uk,
        adobriyan@...il.com, davem@...emloft.net, ebiederm@...ssion.com,
        areber@...hat.com, serge@...lyn.com, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 01/23] ns: Add common refcount into ns_common add use it
 as counter for net_ns

On Thu, Jul 30, 2020 at 05:07:05PM +0300, Kirill Tkhai wrote:
> On 30.07.2020 16:35, Christian Brauner wrote:
> > On Thu, Jul 30, 2020 at 02:59:25PM +0300, Kirill Tkhai wrote:
> >> Currently, every type of namespaces has its own counter,
> >> which is stored in ns-specific part. Say, @net has
> >> struct net::count, @pid has struct pid_namespace::kref, etc.
> >>
> >> This patchset introduces unified counter for all types
> >> of namespaces, and converts net namespace to use it first.
> >>
> >> Signed-off-by: Kirill Tkhai <ktkhai@...tuozzo.com>
> >> ---
> > 
> > Any reason the refcount changes need to be tied to the procfs changes?
> > Seems that should be a separate cleanup patchset which we can take
> > independent of procfs changes.
> 
> Yes, patches [1-8] are cleanup, it may go separately. 
> 
> For me there is no a problem to resend them also as a separate patchset,
> say at v2, or if there is a change in 1-8, but I'm afraid to bomb mailboxes.
> 
> If there is no a request for rework in 1-8, can they be picked directly from here?

Apart from the missing include that might be an issue in ns_common.h
this looks fine to me and seems like a good cleanup overall. Afaict it
even loses more code than it adds.

I think resending this part separately is worth it given that we're not
sure whether this series will be part of procfs or a spearate thing.

This won't make it for the merge window of course but unless there are
technical issues with this conversion I'd pick this up for later.

Thanks!
Christian