linux-kernel - Re: Regression in 5.1.20: Reading long directory fails

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] [day] [month] [year] [list]

Message-ID: <E3D5BD21-8D9D-4EBE-A607-5D4BC9692C63@redhat.com>
Date:   Thu, 12 Sep 2019 09:35:08 -0400
From:   "Benjamin Coddington" <bcodding@...hat.com>
To:     "Trond Myklebust" <trondmy@...merspace.com>
Cc:     bfields@...ldses.org, tibbs@...h.uh.edu, linux@...m.de,
        linux-nfs@...r.kernel.org, linux-kernel@...r.kernel.org,
        km@...all.com, chuck.lever@...cle.com
Subject: Re: Regression in 5.1.20: Reading long directory fails

On 12 Sep 2019, at 9:25, Trond Myklebust wrote:

> On Thu, 2019-09-12 at 09:13 -0400, J. Bruce Fields wrote:
>> (Unless I'm missing something.  I haven't looked at this code in a
>> while.  Though it was problem me that wrote it originally--apologies
>> for
>> that....)
>>
>
> The function itself is fine. It was just the name I'm objecting to,
> since we're actually moving the last 'n' bytes in the message in order
> to be able to read them.

Ok, that's helpful guidance since it saves me from doing a stable fix and
then an attempt to rename/optimize/breakitagain.

I'll just rename it at the same time as the fix.. but now I wonder if that
can potentially mess up other fixes that might retroactively get sent to
stable.  Maybe I'm over thinking it.  I guess I'll send the fix and then the
rename separately, and maintainers can squash at will.

Ben