diff mbox series

[CIFS] Do not build smb1ops.c if legacy support is disabled

Message ID CAH2r5mtUe2f0xi5zu0Np0bkyv7K9BKKgUkUJp2b25BteHBFjeg@mail.gmail.com (mailing list archive)
State New, archived
Headers show
Series [CIFS] Do not build smb1ops.c if legacy support is disabled | expand

Commit Message

Steve French June 2, 2022, 2:39 a.m. UTC
We should not be including unused SMB1/CIFS functions when legacy
support is disabled (CONFIG_CIFS_ALLOW_INSECURE_LEGACY turned
off), but especially obvious is not needing to build smb1ops.c
at all when legacy support is disabled. Over time we can move
more SMB1/CIFS and SMB2.0 legacy functions into ifdefs but this
is a good start (and shrinks the module size a few percent).

Comments

Steve French June 2, 2022, 3:45 a.m. UTC | #1
Another minor one to remove some unneeded SMB20 code when legacy is disabled


On Wed, Jun 1, 2022 at 9:39 PM Steve French <smfrench@gmail.com> wrote:
>
> We should not be including unused SMB1/CIFS functions when legacy
> support is disabled (CONFIG_CIFS_ALLOW_INSECURE_LEGACY turned
> off), but especially obvious is not needing to build smb1ops.c
> at all when legacy support is disabled. Over time we can move
> more SMB1/CIFS and SMB2.0 legacy functions into ifdefs but this
> is a good start (and shrinks the module size a few percent).
>
> --
> Thanks,
>
> Steve
ronnie sahlberg June 2, 2022, 3:50 a.m. UTC | #2
looks good   reviewed by me

On Thu, 2 Jun 2022 at 13:47, Steve French via samba-technical
<samba-technical@lists.samba.org> wrote:
>
> Another minor one to remove some unneeded SMB20 code when legacy is disabled
>
>
> On Wed, Jun 1, 2022 at 9:39 PM Steve French <smfrench@gmail.com> wrote:
> >
> > We should not be including unused SMB1/CIFS functions when legacy
> > support is disabled (CONFIG_CIFS_ALLOW_INSECURE_LEGACY turned
> > off), but especially obvious is not needing to build smb1ops.c
> > at all when legacy support is disabled. Over time we can move
> > more SMB1/CIFS and SMB2.0 legacy functions into ifdefs but this
> > is a good start (and shrinks the module size a few percent).
> >
> > --
> > Thanks,
> >
> > Steve
>
>
>
> --
> Thanks,
>
> Steve
Tom Talpey June 2, 2022, 6:39 p.m. UTC | #3
LGTM, but I had some additional suggestions that I found when
researching how to yank the entire SMB1 code into a module.
Which actually looks quite possible, but for another day.

This patch doesn't actually stop building smb1ops.c and cifssmb.c
however. Don't you want to deselect them in the kconfig?

Feel free to add my
Reviewed-by: Tom Talpey <tom@talpey.com>


On 6/1/2022 11:45 PM, Steve French wrote:
> Another minor one to remove some unneeded SMB20 code when legacy is disabled
> 
> 
> On Wed, Jun 1, 2022 at 9:39 PM Steve French <smfrench@gmail.com> wrote:
>>
>> We should not be including unused SMB1/CIFS functions when legacy
>> support is disabled (CONFIG_CIFS_ALLOW_INSECURE_LEGACY turned
>> off), but especially obvious is not needing to build smb1ops.c
>> at all when legacy support is disabled. Over time we can move
>> more SMB1/CIFS and SMB2.0 legacy functions into ifdefs but this
>> is a good start (and shrinks the module size a few percent).
>>
>> --
>> Thanks,
>>
>> Steve
> 
> 
>
Steve French June 3, 2022, 1:26 a.m. UTC | #4
---------- Forwarded message ---------
From: Steve French <smfrench@gmail.com>
Date: Thu, Jun 2, 2022 at 8:23 PM
Subject: Re: [PATCH][CIFS] Do not build smb1ops.c if legacy support is disabled
To: Tom Talpey <tom@talpey.com>
Cc: CIFS <linux-cifs@vger.kernel.org>, samba-technical
<samba-technical@lists.samba.org>


I was thinking about staging smb1 removal gradually over about a year
and a half (assuming that Samba has the SMB3.1.1 POSIX Extensions
merged in from jra's tree by then so no excuses functionally to
removing smb1)
- marking the CONFIG_CIFS_ALLOW_INSECURE_LEGACY as recommended 'N'
starting in next release 5.20 and move some additional SMB1 code into
the #ifdef
- in 5.21 pulling some of those smb1 specific pieces into a new helper
module (perhaps smb1.ko??)
- in 5.20 or 5.21 renaming fs/cifs directory to fs'smbfs_client (or
something similar)
- evaluate whether we can change the default module name to smb3.ko
from cifs.ko (we already have a module alias for cifs.ko of "smb3" and
have for years been able to "mount -t smb3" with cifs.ko)
- in 5.21 note that insecure legacy support is scheduled for removal
(perhaps a year later), and if anyone mounts with "vers=1.0" (or
vers=2.0) print a warning that it is scheduled for removal in a year.

Thoughts?


On Thu, Jun 2, 2022, 11:39 Tom Talpey <tom@talpey.com> wrote:
>
> LGTM, but I had some additional suggestions that I found when
> researching how to yank the entire SMB1 code into a module.
> Which actually looks quite possible, but for another day.
>
> This patch doesn't actually stop building smb1ops.c and cifssmb.c
> however. Don't you want to deselect them in the kconfig?
>
> Feel free to add my
> Reviewed-by: Tom Talpey <tom@talpey.com>
>
>
> On 6/1/2022 11:45 PM, Steve French wrote:
> > Another minor one to remove some unneeded SMB20 code when legacy is disabled
> >
> >
> > On Wed, Jun 1, 2022 at 9:39 PM Steve French <smfrench@gmail.com> wrote:
> >>
> >> We should not be including unused SMB1/CIFS functions when legacy
> >> support is disabled (CONFIG_CIFS_ALLOW_INSECURE_LEGACY turned
> >> off), but especially obvious is not needing to build smb1ops.c
> >> at all when legacy support is disabled. Over time we can move
> >> more SMB1/CIFS and SMB2.0 legacy functions into ifdefs but this
> >> is a good start (and shrinks the module size a few percent).
> >>
> >> --
> >> Thanks,
> >>
> >> Steve
> >
> >
> >
diff mbox series

Patch

From 41db7a9e28f09d57c145df814f0fb6f200c8d2a6 Mon Sep 17 00:00:00 2001
From: Steve French <stfrench@microsoft.com>
Date: Wed, 1 Jun 2022 21:25:43 -0500
Subject: [PATCH] cifs: do not build smb1ops if legacy support is disabled

We should not be including unused SMB1/CIFS functions when legacy
support is disabled (CONFIG_CIFS_ALLOW_INSECURE_LEGACY turned
off), but especially obvious is not needing to build smb1ops.c
at all when legacy support is disabled. Over time we can move
more SMB1/CIFS and SMB2.0 legacy functions into ifdefs but this
is a good start (and shrinks the module size a few percent).

Signed-off-by: Steve French <stfrench@microsoft.com>
---
 fs/cifs/Makefile | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/cifs/Makefile b/fs/cifs/Makefile
index cc8fdcb35b71..8c9f2c00be72 100644
--- a/fs/cifs/Makefile
+++ b/fs/cifs/Makefile
@@ -8,7 +8,7 @@  obj-$(CONFIG_CIFS) += cifs.o
 cifs-y := trace.o cifsfs.o cifssmb.o cifs_debug.o connect.o dir.o file.o \
 	  inode.o link.o misc.o netmisc.o smbencrypt.o transport.o \
 	  cifs_unicode.o nterr.o cifsencrypt.o \
-	  readdir.o ioctl.o sess.o export.o smb1ops.o unc.o winucase.o \
+	  readdir.o ioctl.o sess.o export.o unc.o winucase.o \
 	  smb2ops.o smb2maperror.o smb2transport.o \
 	  smb2misc.o smb2pdu.o smb2inode.o smb2file.o cifsacl.o fs_context.o \
 	  dns_resolve.o cifs_spnego_negtokeninit.asn1.o asn1.o
@@ -30,3 +30,5 @@  cifs-$(CONFIG_CIFS_FSCACHE) += fscache.o
 cifs-$(CONFIG_CIFS_SMB_DIRECT) += smbdirect.o
 
 cifs-$(CONFIG_CIFS_ROOT) += cifsroot.o
+
+cifs-$(CONFIG_CIFS_ALLOW_INSECURE_LEGACY) += smb1ops.o
-- 
2.34.1