linux-kernel - Re: [PATCH v2 2/2] riscv: Make __fstate

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:   Wed, 11 Sep 2019 09:22:43 +0200
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Andreas Schwab <schwab@...ux-m68k.org>
Cc:     Palmer Dabbelt <palmer@...ive.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        vincent.chen@...ive.com, linux-riscv@...ts.infradead.org,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] riscv: Make __fstate_clean() work correctly.

Hi Andreas,

On Thu, Aug 15, 2019 at 12:37 AM Andreas Schwab <schwab@...ux-m68k.org> wrote:
> On Aug 14 2019, Palmer Dabbelt <palmer@...ive.com> wrote:
> > On Wed, 14 Aug 2019 13:32:50 PDT (-0700), Paul Walmsley wrote:
> >> On Wed, 14 Aug 2019, Vincent Chen wrote:
> >>> Make the __fstate_clean() function correctly set the
> >>> state of sstatus.FS in pt_regs to SR_FS_CLEAN.
> >>>
> >>> Fixes: 7db91e5 ("RISC-V: Task implementation")
> >>> Cc: linux-stable <stable@...r.kernel.org>
> >>> Signed-off-by: Vincent Chen <vincent.chen@...ive.com>
> >>> Reviewed-by: Anup Patel <anup@...infault.org>
> >>> Reviewed-by: Christoph Hellwig <hch@....de>
> >>
> >> Thanks, I extended the "Fixes" commit ID to 12 digits, as is the usual
> >> practice here, and have queued the following for v5.3-rc.
> >
> > For reference, something like "git config core.abbrev=12" (or whatever you
> > write to get this in your .gitconfig)
> >
> >    https://github.com/palmer-dabbelt/home/blob/master/.gitconfig.in#L23
> >
> > causes git to do the right thing.
>
> Actually, the right setting is core.abbrev=auto (or leaving it unset).
> It lets git chose the appropriate length depending on the repository
> contents.  For the linux repository it will chose 13 right now.

Does that depend on the git version?
For me (git version 2.17.1), it still uses 12 when using the auto setting.

Should we update Documentation/process/submitting-patches.rst
to increase to e.g. 16 (which is what I've been using for quite a while)?
When can we expect old 12 hexit references to start breaking?

Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds