linux-kernel - Re: [RESEND][PATCH 0/7] Avoid overflow at boundary

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: <20200901091105.GA4959@lst.de>
Date:   Tue, 1 Sep 2020 11:11:05 +0200
From:   Christoph Hellwig <hch@....de>
To:     Nicolin Chen <nicoleotsuka@...il.com>
Cc:     Christoph Hellwig <hch@....de>, mpe@...erman.id.au,
        benh@...nel.crashing.org, paulus@...ba.org, rth@...ddle.net,
        ink@...assic.park.msu.ru, mattst88@...il.com, tony.luck@...el.com,
        fenghua.yu@...el.com, schnelle@...ux.ibm.com,
        gerald.schaefer@...ux.ibm.com, hca@...ux.ibm.com,
        gor@...ux.ibm.com, borntraeger@...ibm.com, davem@...emloft.net,
        tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, x86@...nel.org,
        hpa@...or.com, James.Bottomley@...senPartnership.com,
        deller@....de, sfr@...b.auug.org.au, linuxppc-dev@...ts.ozlabs.org,
        linux-kernel@...r.kernel.org, linux-alpha@...r.kernel.org,
        linux-ia64@...r.kernel.org, linux-s390@...r.kernel.org,
        sparclinux@...r.kernel.org, linux-parisc@...r.kernel.org
Subject: Re: [RESEND][PATCH 0/7] Avoid overflow at boundary_size

On Tue, Sep 01, 2020 at 12:54:01AM -0700, Nicolin Chen wrote:
> Hi Christoph,
> 
> On Tue, Sep 01, 2020 at 09:36:23AM +0200, Christoph Hellwig wrote:
> > I really don't like all the open coded smarts in the various drivers.
> > What do you think about a helper like the one in the untested patch
> 
> A helper function will be actually better. I was thinking of
> one yet not very sure about the naming and where to put it.
> 
> > below (on top of your series).  Also please include the original
> > segment boundary patch with the next resend so that the series has
> > the full context.
> 
> I will use your change instead and resend with the ULONG_MAX
> change. But in that case, should I make separate changes for
> different files like this series, or just one single change
> like yours?
> 
> Asking this as I was expecting that those changes would get
> applied by different maintainers. But now it feels like you
> will merge it to your tree at once?

I guess one patch is fine.  I can queue it up in the dma-mapping
tree as a prep patch for the default boundary change.