linux-kernel - Re: [RFC PATCH 0/3] Rename "cifs" module to "smbfs"

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: <809ae8167a074e9e50d6102453339a7b21932b7f.camel@kernel.org>
Date:   Thu, 04 Aug 2022 16:48:53 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Enzo Matsumiya <ematsumiya@...e.de>, Tom Talpey <tom@...pey.com>,
        linux-cifs@...r.kernel.org, smfrench@...il.com, pc@....nz,
        ronniesahlberg@...il.com, nspmangalore@...il.com,
        linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
        samba-technical@...ts.samba.org, pshilovsky@...ba.org
Subject: Re: [RFC PATCH 0/3] Rename "cifs" module to "smbfs"

On Thu, 2022-08-04 at 21:23 +0100, Matthew Wilcox wrote:
> On Thu, Aug 04, 2022 at 03:03:23PM -0400, Jeff Layton wrote:
> > On Tue, 2022-08-02 at 22:56 -0300, Enzo Matsumiya wrote:
> > > On 08/02, Tom Talpey wrote:
> > > > The initial goal is to modularize the SMB1 code, so it can be completely
> > > > removed from a running system. The extensive refactoring logically leads
> > > > to this directory renaming, but renaming is basically a side effect.
> > > > 
> > 
> > This is a great technical goal. Splitting up cifs.ko into smaller
> > modules would be great, in addition to being able to turn off smb1
> > support.
> 
> I don't know the CIFS module that well.  How do you see it being split
> up?  It's #4 in the list of filesystems:
> 

Probably by SMB protocol version, similar to how nfs.ko was split. Some
of the files are already version-specific. Some others will need to be
split up or moved into a common helper module, etc. It's not as
mechanical a change, but it would be nice to move in that direction.

To be clear for Enzo, if you have to do enough moving things around,
then it may make sense to go ahead and rename the directory too. It sort
of depends on what the final delta looks like.

> $ size /lib/modules/5.18.0-3-amd64/kernel/fs/*/*.ko |sort -n |tail
>  369020	  28460	    132	 397612	  6112c	/lib/modules/5.18.0-3-amd64/kernel/fs/ubifs/ubifs.ko
>  395793	  50398	    960	 447151	  6d2af	/lib/modules/5.18.0-3-amd64/kernel/fs/ceph/ceph.ko
>  477909	  58883	  10512	 547304	  859e8	/lib/modules/5.18.0-3-amd64/kernel/fs/nfsd/nfsd.ko
>  609260	  84848	    640	 694748	  a99dc	/lib/modules/5.18.0-3-amd64/kernel/fs/f2fs/f2fs.ko
>  622638	 252078	   1008	 875724	  d5ccc	/lib/modules/5.18.0-3-amd64/kernel/fs/nfs/nfsv4.ko
>  717343	 111314	   1176	 829833	  ca989	/lib/modules/5.18.0-3-amd64/kernel/fs/ext4/ext4.ko
>  884247	 206051	    504	1090802	 10a4f2	/lib/modules/5.18.0-3-amd64/kernel/fs/cifs/cifs.ko
>  890155	 159520	    240	1049915	 10053b	/lib/modules/5.18.0-3-amd64/kernel/fs/ocfs2/ocfs2.ko
> 1193834	 274148	    456	1468438	 166816	/lib/modules/5.18.0-3-amd64/kernel/fs/xfs/xfs.ko
> 1393088	 126501	  15072	1534661	 176ac5	/lib/modules/5.18.0-3-amd64/kernel/fs/btrfs/btrfs.ko
> 
> ... but if you look at how NFS is split up:
> 
>  311322	  76200	    392	 387914	  5eb4a	/lib/modules/5.18.0-3-amd64/kernel/fs/nfs/nfs.ko
>   25157	   1100	     72	  26329	   66d9	/lib/modules/5.18.0-3-amd64/kernel/fs/nfs/nfsv2.ko
>   49332	   1544	    120	  50996	   c734	/lib/modules/5.18.0-3-amd64/kernel/fs/nfs/nfsv3.ko
>  622638	 252078	   1008	 875724	  d5ccc	/lib/modules/5.18.0-3-amd64/kernel/fs/nfs/nfsv4.ko
> 
> you can save a lot of RAM if you don't need NFSv4 (then there's also
> nfs_common, 408kB of sunrpc.ko, etc, etc).

The memory savings is nice, but the real gain is in being able to
eventually drop SMB1 support. The SMB1 protocol is notoriously awful, so
there is legitimate interest in doing so. Moving it into a separate
module (built under a new Kconfig option) would be a great first step in
that direction.

-- 
Jeff Layton <jlayton@...nel.org>