linux-kernel - Re: [GIT PULL] smb3 client fixes

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: <CAHk-=wiCPoGieS-hkV+ze6UqvzNyPNT7WoD_v54ZuVwi-d5Bmw@mail.gmail.com>
Date:   Wed, 30 Aug 2023 21:21:31 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Steve French <smfrench@...il.com>
Cc:     Dave Kleikamp <shaggy@...nel.org>,
        "Dr. David Alan Gilbert" <linux@...blig.org>,
        CIFS <linux-cifs@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] smb3 client fixes

On Wed, 30 Aug 2023 at 13:48, Steve French <smfrench@...il.com> wrote:
>
> - move UCS-2 conversion code to fs/nls and update cifs.ko and jfs.ko to use them

I've pulled this, but I think the new NLS_UCS2_UTILS config option
shouldn't be something that is asked about. The filesystems that want
it already select it, and users shouldn't be asked about a module with
no use.

The way to do that is to simply not have a user query string for it,
ie instead of

  config NLS_UCS2_UTILS
          tristate "NLS UCS-2 UTILS"

it could be (an dI think should be) just

  config NLS_UCS2_UTILS
          tristate

which tells the config system not to ask users about it.

Because users really shouldn't be asked questions that there is no point in.

And then, on a purely visual commentary about your pull request -
lines like these are just noise:

>  fs/{smb/server/uniupr.h => nls/nls_ucs2_utils.c} | 156
> +++++-------------------------------------
>  fs/nls/nls_ucs2_utils.h                          | 285
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

and the problem seems to be that you generate the diffstat in a very
wide terminal (where git tries to be helpful and give you lots of
detail), and then you cut-and-paste the result.

If you pipe it to a tool instead (xsel, perhaps), git will limit the
width of the diffstat to something sane.

Or, if you really want to use a terminal and cut-and-paste it
manually, you could try to tell git to use '--stat=72' to limit the
stat to 72 characters (which is the canonical "width for email", as
the Lord spake unto us all in rfc822, even if the Lord was confused
and also mentioned the number 65).

                         Linus