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: <20200726125325.GC80756@lianli.shorne-pla.net>
Date:   Sun, 26 Jul 2020 21:53:25 +0900
From:   Stafford Horne <shorne@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>
Cc:     LKML <linux-kernel@...r.kernel.org>, Arnd Bergmann <arnd@...db.de>,
        Wei Xu <xuwei5@...ilicon.com>,
        John Garry <john.garry@...wei.com>,
        Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH] io: Fix return type of _inb and _inl

On Sun, Jul 26, 2020 at 12:00:37PM +0300, Andy Shevchenko wrote:
> On Sun, Jul 26, 2020 at 6:14 AM Stafford Horne <shorne@...il.com> wrote:
> >
> > The return type of functions _inb, _inw and _inl are all u16 which looks
> > wrong.  This patch makes them u8, u16 and u32 respectively.
> >
> > The original commit text for these does not indicate that these should
> > be all forced to u16.
> 
> Is it in alight with all architectures? that support this interface natively?
> 
> (Return value is arch-dependent AFAIU, so it might actually return
> 16-bit for byte read, but I agree that this is weird for 32-bit value.
> I think you have elaborate more in the commit message)

Well, this is the generic io code,  at least these api's appear to not be different
for each architecture.  The output read by the architecture dependant code i.e.
__raw_readb() below is getting is placed into a u8.  So I think the output of
the function will be u8.

static inline u8 _inb(unsigned long addr)
{
	u8 val;

	__io_pbr();
	val = __raw_readb(PCI_IOBASE + addr);
	__io_par(val);
	return val;
}

I can expand the commit text, but I would like to get some comments from the
original author to confirm if this is an issue.

-Stafford

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ