linux-kernel - Re: [PATCH v5 RESEND 10/17] s390: mm: Convert to GENERIC

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, 17 May 2023 09:58:26 +0200
From:   Niklas Schnelle <schnelle@...ux.ibm.com>
To:     Christoph Hellwig <hch@...radead.org>, Baoquan He <bhe@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-mm@...ck.org, arnd@...db.de, christophe.leroy@...roup.eu,
        agordeev@...ux.ibm.com, wangkefeng.wang@...wei.com,
        David.Laight@...lab.com, shorne@...il.com, willy@...radead.org,
        deller@....de, Gerald Schaefer <gerald.schaefer@...ux.ibm.com>,
        Heiko Carstens <hca@...ux.ibm.com>,
        Vasily Gorbik <gor@...ux.ibm.com>,
        Christian Borntraeger <borntraeger@...ux.ibm.com>,
        Sven Schnelle <svens@...ux.ibm.com>, linux-s390@...r.kernel.org
Subject: Re: [PATCH v5 RESEND 10/17] s390: mm: Convert to GENERIC_IOREMAP

On Tue, 2023-05-16 at 23:36 -0700, Christoph Hellwig wrote:
> On Mon, May 15, 2023 at 05:08:41PM +0800, Baoquan He wrote:
> > +#define ioremap_wc(addr, size)  \
> > +	ioremap_prot((addr), (size), pgprot_val(pgprot_writecombine(PAGE_KERNEL)))
> 
> I'd move this out of line and just apply mio_wb_bit_mask directly
> instead of the unbox/box/unbox/box dance.
> 
> > +#define ioremap_wt(addr, size)  \
> > +	ioremap_prot((addr), (size), pgprot_val(pgprot_writethrough(PAGE_KERNEL)))
> 
> and just define this to ioremap_wc.  Note that defining _wt to _wc is
> very odd and seems wrong, but comes from the existing code.  Maybe the
> s390 maintainers can chime on on the background and we can add a comment
> while we're at it.

I'm a bit confused where you see ioremap_wt() defined to ioremap_wc()
in the existing code? Our current definitions are:


void __iomem *ioremap_wc(phys_addr_t addr, size_t size)
{
	return __ioremap(addr, size,
pgprot_writecombine(PAGE_KERNEL));
}

void __iomem *ioremap_wt(phys_addr_t addr, size_t size)
{
	return __ioremap(addr, size,
pgprot_writethrough(PAGE_KERNEL));
}

Now if we don't have support for the enhanced PCI load/store
instructions (memory I/O aka MIO) then yes this gets ignored and both
.._wc() and .._wt() act the same but if we do have them
pgprot_writecombine() / pgprot_writethrough() set respectively clear 
the mio_wb bit in the PTE. It's a bit odd here because the exact
position of the bit is read from a firmware interface and could in
theory change but other than that it looks fine to me and yes I agree
that it would be odd and broken to define _wt to _wc.

Thanks,
Niklas