[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201022200914.GY3576660@ZenIV.linux.org.uk>
Date: Thu, 22 Oct 2020 21:09:14 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Arnd Bergmann <arnd@...db.de>,
David Laight <David.Laight@...lab.com>,
Christoph Hellwig <hch@....de>,
David Hildenbrand <david@...hat.com>,
Greg KH <gregkh@...uxfoundation.org>,
"kernel-team@...roid.com" <kernel-team@...roid.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>,
David Howells <dhowells@...hat.com>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mips@...r.kernel.org" <linux-mips@...r.kernel.org>,
"linux-parisc@...r.kernel.org" <linux-parisc@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
"sparclinux@...r.kernel.org" <sparclinux@...r.kernel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-aio@...ck.org" <linux-aio@...ck.org>,
"io-uring@...r.kernel.org" <io-uring@...r.kernel.org>,
"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"keyrings@...r.kernel.org" <keyrings@...r.kernel.org>,
"linux-security-module@...r.kernel.org"
<linux-security-module@...r.kernel.org>
Subject: Re: Buggy commit tracked to: "Re: [PATCH 2/9] iov_iter: move
rw_copy_check_uvector() into lib/iov_iter.c"
On Thu, Oct 22, 2020 at 09:06:29PM +0100, Al Viro wrote:
> On Thu, Oct 22, 2020 at 08:24:58PM +0100, Al Viro wrote:
>
> > Depending upon the calling conventions, compiler might do truncation in caller or
> > in a callee, but it must be done _somewhere_.
>
> Unless I'm misreading AAPCS64,
> "Unlike in the 32-bit AAPCS, named integral values must be narrowed by the callee
> rather than the caller"
> in 6.4.2 means that callee must not _not_ expect the upper 32 bits of %x0..%x7 to contain
Sorry, artefact of editing - that's
"in 6.4.2 means that callee must _not_ expect the upper 32 bits of %x0..%x7 to contain"
obviously.
Powered by blists - more mailing lists