* Re: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()
From: Matthew Wilcox @ 2020-09-21 14:48 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, linux-arch, linux-s390, linux-scsi, Arnd Bergmann,
linux-block, Alexander Viro, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, David Laight, linux-fsdevel, Andrew Morton,
linuxppc-dev
In-Reply-To: <20200921143434.707844-3-hch@lst.de>
On Mon, Sep 21, 2020 at 04:34:25PM +0200, Christoph Hellwig wrote:
> {
> - WARN_ON(direction & ~(READ | WRITE));
> + WARN_ON(direction & ~(READ | WRITE | CHECK_IOVEC_ONLY));
This is now a no-op because:
include/linux/fs.h:#define CHECK_IOVEC_ONLY -1
I'd suggest we renumber it to 2?
(READ is 0, WRITE is 1. This WARN_ON should probably be
WARN_ON(direction > CHECK_IOVEC_ONLY)
^ permalink raw reply
* Re: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()
From: Al Viro @ 2020-09-21 15:02 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, linux-arch, linux-s390, linux-scsi, Arnd Bergmann,
linux-block, io-uring, linux-arm-kernel, Jens Axboe, linux-parisc,
netdev, linux-kernel, linux-security-module, David Laight,
linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200921143434.707844-3-hch@lst.de>
On Mon, Sep 21, 2020 at 04:34:25PM +0200, Christoph Hellwig wrote:
> From: David Laight <David.Laight@ACULAB.COM>
>
> This is the only direct call of rw_copy_check_uvector(). Removing it
> will allow rw_copy_check_uvector() to be inlined into import_iovec(),
> while only paying a minor price by setting up an otherwise unused
> iov_iter in the process_vm_readv/process_vm_writev syscalls that aren't
> in a super hot path.
> @@ -443,7 +443,7 @@ void iov_iter_init(struct iov_iter *i, unsigned int direction,
> const struct iovec *iov, unsigned long nr_segs,
> size_t count)
> {
> - WARN_ON(direction & ~(READ | WRITE));
> + WARN_ON(direction & ~(READ | WRITE | CHECK_IOVEC_ONLY));
> direction &= READ | WRITE;
Ugh...
> - rc = rw_copy_check_uvector(CHECK_IOVEC_ONLY, rvec, riovcnt, UIO_FASTIOV,
> - iovstack_r, &iov_r);
> + rc = import_iovec(CHECK_IOVEC_ONLY, rvec, riovcnt, UIO_FASTIOV, &iov_r,
> + &iter_r);
> if (rc <= 0)
> goto free_iovecs;
>
> - rc = process_vm_rw_core(pid, &iter, iov_r, riovcnt, flags, vm_write);
> + rc = process_vm_rw_core(pid, &iter_l, iter_r.iov, iter_r.nr_segs,
> + flags, vm_write);
... and ugh^2, since now you are not only setting a meaningless iov_iter,
you are creating a new place that pokes directly into struct iov_iter
guts.
Sure, moving rw_copy_check_uvector() over to lib/iov_iter.c makes sense.
But I would rather split the access_ok()-related checks out of that thing
and bury CHECK_IOVEC_ONLY.
Step 1: move the damn thing to lib/iov_iter.c (same as you do, but without
making it static)
Step 2: split it in two:
ssize_t rw_copy_check_uvector(const struct iovec __user * uvector,
unsigned long nr_segs, unsigned long fast_segs,
struct iovec *fast_pointer,
struct iovec **ret_pointer)
{
unsigned long seg;
ssize_t ret;
struct iovec *iov = fast_pointer;
*ret_pointer = fast_pointer;
/*
* SuS says "The readv() function *may* fail if the iovcnt argument
* was less than or equal to 0, or greater than {IOV_MAX}. Linux has
* traditionally returned zero for zero segments, so...
*/
if (nr_segs == 0)
return 0;
/*
* First get the "struct iovec" from user memory and
* verify all the pointers
*/
if (nr_segs > UIO_MAXIOV)
return -EINVAL;
if (nr_segs > fast_segs) {
iov = kmalloc_array(nr_segs, sizeof(struct iovec), GFP_KERNEL);
if (!iov)
return -ENOMEM;
*ret_pointer = iov;
}
if (copy_from_user(iov, uvector, nr_segs*sizeof(*uvector)))
return -EFAULT;
/*
* According to the Single Unix Specification we should return EINVAL
* if an element length is < 0 when cast to ssize_t or if the
* total length would overflow the ssize_t return value of the
* system call.
*
* Linux caps all read/write calls to MAX_RW_COUNT, and avoids the
* overflow case.
*/
ret = 0;
for (seg = 0; seg < nr_segs; seg++) {
void __user *buf = iov[seg].iov_base;
ssize_t len = (ssize_t)iov[seg].iov_len;
/* see if we we're about to use an invalid len or if
* it's about to overflow ssize_t */
if (len < 0)
return -EINVAL;
if (len > MAX_RW_COUNT - ret) {
len = MAX_RW_COUNT - ret;
iov[seg].iov_len = len;
}
ret += len;
}
return ret;
}
/*
* This is merely an early sanity check; we do _not_ rely upon
* it when we get to the actual memory accesses.
*/
static bool check_iovecs(const struct iovec *iov, int nr_segs)
{
for (seg = 0; seg < nr_segs; seg++) {
void __user *buf = iov[seg].iov_base;
ssize_t len = (ssize_t)iov[seg].iov_len;
if (unlikely(!access_ok(buf, len)))
return false;
}
return true;
}
ssize_t import_iovec(int type, const struct iovec __user * uvector,
unsigned nr_segs, unsigned fast_segs,
struct iovec **iov, struct iov_iter *i)
{
struct iovec *p;
ssize_t n;
n = rw_copy_check_uvector(uvector, nr_segs, fast_segs, *iov, &p);
if (n > 0 && !check_iovecs(p, nr_segs))
n = -EFAULT;
if (n < 0) {
if (p != *iov)
kfree(p);
*iov = NULL;
return n;
}
iov_iter_init(i, type, p, nr_segs, n);
*iov = p == *iov ? NULL : p;
return n;
}
kill CHECK_IOVEC_ONLY and use rw_copy_check_uvector() without the type
argument in mm/process_vm_access.c
Saner that way, IMO...
^ permalink raw reply
* RE: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector
From: David Laight @ 2020-09-21 15:05 UTC (permalink / raw)
To: 'Christoph Hellwig', Alexander Viro
Cc: Jens Axboe, linux-s390@vger.kernel.org,
linux-arch@vger.kernel.org, linux-parisc@vger.kernel.org,
Arnd Bergmann, linux-aio@kvack.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
David Howells, linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
linux-block@vger.kernel.org, linux-mm@kvack.org,
linux-scsi@vger.kernel.org, sparclinux@vger.kernel.org,
Andrew Morton, linuxppc-dev@lists.ozlabs.org,
io-uring@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200921143434.707844-5-hch@lst.de>
From: Christoph Hellwig
> Sent: 21 September 2020 15:34
>
> Explicitly check for the magic value insted of implicitly relying on
> its numeric representation. Also drop the rather pointless unlikely
> annotation.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> lib/iov_iter.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/lib/iov_iter.c b/lib/iov_iter.c
> index d7e72343c360eb..a64867501a7483 100644
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1709,8 +1709,7 @@ static ssize_t rw_copy_check_uvector(int type,
> ret = -EINVAL;
> goto out;
> }
> - if (type >= 0
> - && unlikely(!access_ok(buf, len))) {
> + if (type != CHECK_IOVEC_ONLY && !access_ok(buf, len)) {
> ret = -EFAULT;
> goto out;
> }
> @@ -1824,7 +1823,7 @@ static ssize_t compat_rw_copy_check_uvector(int type,
> }
> if (len < 0) /* size_t not fitting in compat_ssize_t .. */
> goto out;
> - if (type >= 0 &&
> + if (type != CHECK_IOVEC_ONLY &&
> !access_ok(compat_ptr(buf), len)) {
> ret = -EFAULT;
> goto out;
> --
> 2.28.0
I've actually no idea:
1) Why there is an access_ok() check here.
It will be repeated by the user copy functions.
2) Why it isn't done when called from mm/process_vm_access.c.
Ok, the addresses refer to a different process, but they
must still be valid user addresses.
Is 2 a legacy from when access_ok() actually checked that the
addresses were mapped into the process's address space?
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector
From: Al Viro @ 2020-09-21 15:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, linux-arch, linux-s390, linux-scsi, Arnd Bergmann,
linux-block, io-uring, linux-arm-kernel, Jens Axboe, linux-parisc,
netdev, linux-kernel, linux-security-module, David Laight,
linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200921143434.707844-5-hch@lst.de>
On Mon, Sep 21, 2020 at 04:34:27PM +0200, Christoph Hellwig wrote:
> Explicitly check for the magic value insted of implicitly relying on
> its numeric representation. Also drop the rather pointless unlikely
> annotation.
See above - I would rather have CHECK_IOVEC_ONLY gone.
The reason for doing these access_ok() in the same loop is fairly weak,
especially since you are checking type on each iteration. Might as
well do that in a separate loop afterwards.
^ permalink raw reply
* Re: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector
From: Al Viro @ 2020-09-21 15:11 UTC (permalink / raw)
To: David Laight
Cc: linux-aio@kvack.org, linux-mips@vger.kernel.org, David Howells,
linux-mm@kvack.org, keyrings@vger.kernel.org,
sparclinux@vger.kernel.org, 'Christoph Hellwig',
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, Arnd Bergmann,
linux-block@vger.kernel.org, io-uring@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jens Axboe,
linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <7336624280b8444fb4cb00407317741b@AcuMS.aculab.com>
On Mon, Sep 21, 2020 at 03:05:32PM +0000, David Laight wrote:
> I've actually no idea:
> 1) Why there is an access_ok() check here.
> It will be repeated by the user copy functions.
Early sanity check.
> 2) Why it isn't done when called from mm/process_vm_access.c.
> Ok, the addresses refer to a different process, but they
> must still be valid user addresses.
>
> Is 2 a legacy from when access_ok() actually checked that the
> addresses were mapped into the process's address space?
It never did. 2 is for the situation when a 32bit process
accesses 64bit one; addresses that are perfectly legitimate
for 64bit userland (and fitting into the first 4Gb of address
space, so they can be represented by 32bit pointers just fine)
might be rejected by access_ok() if the caller is 32bit.
^ permalink raw reply
* Re: [PATCH 05/11] iov_iter: merge the compat case into rw_copy_check_uvector
From: Al Viro @ 2020-09-21 15:14 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, linux-arch, linux-s390, linux-scsi, Arnd Bergmann,
linux-block, io-uring, linux-arm-kernel, Jens Axboe, linux-parisc,
netdev, linux-kernel, linux-security-module, David Laight,
linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200921143434.707844-6-hch@lst.de>
On Mon, Sep 21, 2020 at 04:34:28PM +0200, Christoph Hellwig wrote:
> +static int compat_copy_iovecs_from_user(struct iovec *iov,
> + const struct iovec __user *uvector, unsigned long nr_segs)
> +{
> + const struct compat_iovec __user *uiov =
> + (const struct compat_iovec __user *)uvector;
> + unsigned long i;
^^^^
Huh?
^ permalink raw reply
* Re: [PATCH 06/11] iov_iter: handle the compat case in import_iovec
From: Al Viro @ 2020-09-21 15:20 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, linux-arch, linux-s390, linux-scsi, Arnd Bergmann,
linux-block, io-uring, linux-arm-kernel, Jens Axboe, linux-parisc,
netdev, linux-kernel, linux-security-module, David Laight,
linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200921143434.707844-7-hch@lst.de>
On Mon, Sep 21, 2020 at 04:34:29PM +0200, Christoph Hellwig wrote:
> Use in compat_syscall to import either native or the compat iovecs, and
> remove the now superflous compat_import_iovec, which removes the need for
> special compat logic in most callers. Only io_uring needs special
> treatment given that it can call import_iovec from kernel threads acting
> on behalf of native or compat syscalls. Expose the low-level
> __import_iovec helper and use it in io_uring to explicitly pick a iovec
> layout.
fs/aio.c part is not obvious... Might be better to use __import_iovec()
there as well and leave the rest of aio.c changes to followup.
> --- a/lib/iov_iter.c
> +++ b/lib/iov_iter.c
> @@ -1683,7 +1683,7 @@ static int compat_copy_iovecs_from_user(struct iovec *iov,
> return ret;
> }
>
> -static ssize_t __import_iovec(int type, const struct iovec __user *uvector,
> +ssize_t __import_iovec(int type, const struct iovec __user *uvector,
> unsigned nr_segs, unsigned fast_segs, struct iovec **iovp,
> struct iov_iter *i, bool compat)
> {
Don't make it static in the first place, perhaps?
^ permalink raw reply
* RE: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()
From: David Laight @ 2020-09-21 15:21 UTC (permalink / raw)
To: 'Al Viro', Christoph Hellwig
Cc: Jens Axboe, linux-s390@vger.kernel.org,
linux-arch@vger.kernel.org, linux-parisc@vger.kernel.org,
Arnd Bergmann, linux-aio@kvack.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mips@vger.kernel.org,
David Howells, linux-fsdevel@vger.kernel.org,
linux-security-module@vger.kernel.org, keyrings@vger.kernel.org,
linux-block@vger.kernel.org, linux-mm@kvack.org,
linux-scsi@vger.kernel.org, sparclinux@vger.kernel.org,
Andrew Morton, linuxppc-dev@lists.ozlabs.org,
io-uring@vger.kernel.org, linux-arm-kernel@lists.infradead.org
In-Reply-To: <20200921150211.GS3421308@ZenIV.linux.org.uk>
From: Al Viro
> Sent: 21 September 2020 16:02
>
> On Mon, Sep 21, 2020 at 04:34:25PM +0200, Christoph Hellwig wrote:
> > From: David Laight <David.Laight@ACULAB.COM>
> >
> > This is the only direct call of rw_copy_check_uvector(). Removing it
> > will allow rw_copy_check_uvector() to be inlined into import_iovec(),
> > while only paying a minor price by setting up an otherwise unused
> > iov_iter in the process_vm_readv/process_vm_writev syscalls that aren't
> > in a super hot path.
>
> > @@ -443,7 +443,7 @@ void iov_iter_init(struct iov_iter *i, unsigned int direction,
> > const struct iovec *iov, unsigned long nr_segs,
> > size_t count)
> > {
> > - WARN_ON(direction & ~(READ | WRITE));
> > + WARN_ON(direction & ~(READ | WRITE | CHECK_IOVEC_ONLY));
> > direction &= READ | WRITE;
>
> Ugh...
>
> > - rc = rw_copy_check_uvector(CHECK_IOVEC_ONLY, rvec, riovcnt, UIO_FASTIOV,
> > - iovstack_r, &iov_r);
> > + rc = import_iovec(CHECK_IOVEC_ONLY, rvec, riovcnt, UIO_FASTIOV, &iov_r,
> > + &iter_r);
> > if (rc <= 0)
> > goto free_iovecs;
> >
> > - rc = process_vm_rw_core(pid, &iter, iov_r, riovcnt, flags, vm_write);
> > + rc = process_vm_rw_core(pid, &iter_l, iter_r.iov, iter_r.nr_segs,
> > + flags, vm_write);
>
> ... and ugh^2, since now you are not only setting a meaningless iov_iter,
> you are creating a new place that pokes directly into struct iov_iter
> guts.
>
> Sure, moving rw_copy_check_uvector() over to lib/iov_iter.c makes sense.
> But I would rather split the access_ok()-related checks out of that thing
> and bury CHECK_IOVEC_ONLY.
>
> Step 1: move the damn thing to lib/iov_iter.c (same as you do, but without
> making it static)
>
> Step 2: split it in two:
>
> ssize_t rw_copy_check_uvector(const struct iovec __user * uvector,
> unsigned long nr_segs, unsigned long fast_segs,
> struct iovec *fast_pointer,
> struct iovec **ret_pointer)
> {
> unsigned long seg;
...
> ret = 0;
> for (seg = 0; seg < nr_segs; seg++) {
> void __user *buf = iov[seg].iov_base;
> ssize_t len = (ssize_t)iov[seg].iov_len;
>
> /* see if we we're about to use an invalid len or if
> * it's about to overflow ssize_t */
> if (len < 0)
> return -EINVAL;
> if (len > MAX_RW_COUNT - ret) {
> len = MAX_RW_COUNT - ret;
> iov[seg].iov_len = len;
> }
> ret += len;
> }
> return ret;
> }
>
> /*
> * This is merely an early sanity check; we do _not_ rely upon
> * it when we get to the actual memory accesses.
> */
> static bool check_iovecs(const struct iovec *iov, int nr_segs)
> {
> for (seg = 0; seg < nr_segs; seg++) {
> void __user *buf = iov[seg].iov_base;
> ssize_t len = (ssize_t)iov[seg].iov_len;
>
> if (unlikely(!access_ok(buf, len)))
> return false;
> }
> return true;
> }
You really don't want to be looping through the array twice.
In fact you don't really want to be doing all those tests at all.
This code makes a significant fraction of the not-insignificant
difference between the 'costs' of send() and sendmsg().
I think the 'length' check can be optimised to do something like:
for (...) {
ssize_t len = (ssize_t)iov[seg].iov_len;
ret += len;
len_hi += (unsigned long)len >> 20;
}
if (len_hi) {
/* Something potentially odd in the lengths.
* Might just be a very long fragment.
* Check the individial values. */
Add the exiting loop here.
}
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* RE: [PATCH 04/11] iov_iter: explicitly check for CHECK_IOVEC_ONLY in rw_copy_check_uvector
From: David Laight @ 2020-09-21 15:26 UTC (permalink / raw)
To: 'Al Viro'
Cc: linux-aio@kvack.org, linux-mips@vger.kernel.org, David Howells,
linux-mm@kvack.org, keyrings@vger.kernel.org,
sparclinux@vger.kernel.org, 'Christoph Hellwig',
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, Arnd Bergmann,
linux-block@vger.kernel.org, io-uring@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jens Axboe,
linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20200921151119.GU3421308@ZenIV.linux.org.uk>
From: Al Viro
> Sent: 21 September 2020 16:11
> On Mon, Sep 21, 2020 at 03:05:32PM +0000, David Laight wrote:
>
> > I've actually no idea:
> > 1) Why there is an access_ok() check here.
> > It will be repeated by the user copy functions.
>
> Early sanity check.
>
> > 2) Why it isn't done when called from mm/process_vm_access.c.
> > Ok, the addresses refer to a different process, but they
> > must still be valid user addresses.
> >
> > Is 2 a legacy from when access_ok() actually checked that the
> > addresses were mapped into the process's address space?
>
> It never did. 2 is for the situation when a 32bit process
> accesses 64bit one; addresses that are perfectly legitimate
> for 64bit userland (and fitting into the first 4Gb of address
> space, so they can be represented by 32bit pointers just fine)
> might be rejected by access_ok() if the caller is 32bit.
Can't 32 bit processes on a 64bit system access all the way to 4GB?
Mapping things by default above 3GB will probably break things.
But there is no reason to disallow explicit maps.
And in any case access_ok() can use the same limit as it does for
64bit processes - the page fault handler will sort it all out.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()
From: Al Viro @ 2020-09-21 15:29 UTC (permalink / raw)
To: David Laight
Cc: linux-aio@kvack.org, linux-mips@vger.kernel.org, David Howells,
linux-mm@kvack.org, keyrings@vger.kernel.org,
sparclinux@vger.kernel.org, Christoph Hellwig,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, Arnd Bergmann,
linux-block@vger.kernel.org, io-uring@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jens Axboe,
linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <ef67787edb2f48548d69caaaff6997ba@AcuMS.aculab.com>
On Mon, Sep 21, 2020 at 03:21:35PM +0000, David Laight wrote:
> You really don't want to be looping through the array twice.
Profiles, please.
> I think the 'length' check can be optimised to do something like:
> for (...) {
> ssize_t len = (ssize_t)iov[seg].iov_len;
> ret += len;
> len_hi += (unsigned long)len >> 20;
> }
> if (len_hi) {
> /* Something potentially odd in the lengths.
> * Might just be a very long fragment.
> * Check the individial values. */
> Add the exiting loop here.
> }
Far too ugly to live.
^ permalink raw reply
* Re: [PATCH -next] ocxl: simplify the return expression of free_function_dev()
From: Frederic Barrat @ 2020-09-21 15:34 UTC (permalink / raw)
To: Qinglang Miao, Andrew Donnellan, Arnd Bergmann,
Greg Kroah-Hartman
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20200921131047.92526-1-miaoqinglang@huawei.com>
Le 21/09/2020 à 15:10, Qinglang Miao a écrit :
> Simplify the return expression.
>
> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
> ---
Thanks!
Acked-by: Frederic Barrat <fbarrat@linux.ibm.com>
> drivers/misc/ocxl/core.c | 7 +------
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/misc/ocxl/core.c b/drivers/misc/ocxl/core.c
> index b7a09b21a..aebfc53a2 100644
> --- a/drivers/misc/ocxl/core.c
> +++ b/drivers/misc/ocxl/core.c
> @@ -327,14 +327,9 @@ static void free_function_dev(struct device *dev)
>
> static int set_function_device(struct ocxl_fn *fn, struct pci_dev *dev)
> {
> - int rc;
> -
> fn->dev.parent = &dev->dev;
> fn->dev.release = free_function_dev;
> - rc = dev_set_name(&fn->dev, "ocxlfn.%s", dev_name(&dev->dev));
> - if (rc)
> - return rc;
> - return 0;
> + return dev_set_name(&fn->dev, "ocxlfn.%s", dev_name(&dev->dev));
> }
>
> static int assign_function_actag(struct ocxl_fn *fn)
>
^ permalink raw reply
* RE: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()
From: David Laight @ 2020-09-21 15:44 UTC (permalink / raw)
To: 'Al Viro'
Cc: linux-aio@kvack.org, linux-mips@vger.kernel.org, David Howells,
linux-mm@kvack.org, keyrings@vger.kernel.org,
sparclinux@vger.kernel.org, Christoph Hellwig,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, Arnd Bergmann,
linux-block@vger.kernel.org, io-uring@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jens Axboe,
linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20200921152937.GX3421308@ZenIV.linux.org.uk>
From: Al Viro
> Sent: 21 September 2020 16:30
>
> On Mon, Sep 21, 2020 at 03:21:35PM +0000, David Laight wrote:
>
> > You really don't want to be looping through the array twice.
>
> Profiles, please.
I did some profiling of send() v sendmsg() much earlier in the year.
I can't remember the exact details but the extra cost of sendmsg()
is far more than you might expect.
(I was timing sending fully built IPv4 UDP packets using a raw socket.)
About half the difference does away if you change the
copy_from_user() to __copy_from_user() when reading the struct msghdr
and iov[] from userspace (user copy hardening is expensive).
The rest is just code path, my gut feeling is that a lot of that
is in import_iovec().
Remember semdmsg() is likely to be called with an iov count of 1.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH V2] Doc: admin-guide: Add entry for kvm_cma_resv_ratio kernel param
From: Randy Dunlap @ 2020-09-21 15:58 UTC (permalink / raw)
To: sathnaga, linux-doc
Cc: Jonathan Corbet, linux-kernel, kvm-ppc, Paul Mackerras,
linuxppc-dev
In-Reply-To: <20200921090220.14981-1-sathnaga@linux.vnet.ibm.com>
On 9/21/20 2:02 AM, sathnaga@linux.vnet.ibm.com wrote:
> From: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
>
> Add document entry for kvm_cma_resv_ratio kernel param which
> is used to alter the KVM contiguous memory allocation percentage
> for hash pagetable allocation used by hash mode PowerPC KVM guests.
>
> Cc: linux-kernel@vger.kernel.org
> Cc: kvm-ppc@vger.kernel.org
> Cc: linuxppc-dev@lists.ozlabs.org
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
Hi,
> ---
>
> V2:
> Addressed review comments from Randy.
>
> V1: https://lkml.org/lkml/2020/9/16/72
In reply to V1, I didn't add a Reviewed-by: tag, but I can now.
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index a1068742a6df..932ed45740c9 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -2258,6 +2258,14 @@
> [KVM,ARM] Allow use of GICv4 for direct injection of
> LPIs.
>
> + kvm_cma_resv_ratio=n [PPC]
> + Reserves given percentage from system memory area for
> + contiguous memory allocation for KVM hash pagetable
> + allocation.
> + By default it reserves 5% of total system memory.
> + Format: <integer>
> + Default: 5
> +
> kvm-intel.ept= [KVM,Intel] Disable extended page tables
> (virtualized MMU) support on capable Intel chips.
> Default is 1 (enabled)
>
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()
From: Christoph Hellwig @ 2020-09-21 16:12 UTC (permalink / raw)
To: Al Viro
Cc: linux-aio@kvack.org, linux-mips@vger.kernel.org, David Howells,
linux-mm@kvack.org, keyrings@vger.kernel.org,
sparclinux@vger.kernel.org, Christoph Hellwig,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, Arnd Bergmann,
linux-block@vger.kernel.org, io-uring@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jens Axboe,
linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org, David Laight,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20200921152937.GX3421308@ZenIV.linux.org.uk>
On Mon, Sep 21, 2020 at 04:29:37PM +0100, Al Viro wrote:
> On Mon, Sep 21, 2020 at 03:21:35PM +0000, David Laight wrote:
>
> > You really don't want to be looping through the array twice.
>
> Profiles, please.
Given that the iov array should be cache hot I'd be surprised to
see a huge difference.
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Pavel Begunkov @ 2020-09-21 16:10 UTC (permalink / raw)
To: Andy Lutomirski, Arnd Bergmann
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390,
Linux SCSI List, X86 ML, linux-block, Al Viro, Andy Lutomirski,
io-uring, linux-arm-kernel, Jens Axboe, Parisc List,
Network Development, LKML, LSM List, Linux FS Devel,
Andrew Morton, linuxppc-dev
In-Reply-To: <D0791499-1190-4C3F-A984-0A313ECA81C7@amacapital.net>
On 20/09/2020 01:22, Andy Lutomirski wrote:
>
>> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>
>> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski <luto@kernel.org> wrote:
>>>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig <hch@lst.de> wrote:
>>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>>>> Said that, why not provide a variant that would take an explicit
>>>>> "is it compat" argument and use it there? And have the normal
>>>>> one pass in_compat_syscall() to that...
>>>>
>>>> That would help to not introduce a regression with this series yes.
>>>> But it wouldn't fix existing bugs when io_uring is used to access
>>>> read or write methods that use in_compat_syscall(). One example that
>>>> I recently ran into is drivers/scsi/sg.c.
>>
>> Ah, so reading /dev/input/event* would suffer from the same issue,
>> and that one would in fact be broken by your patch in the hypothetical
>> case that someone tried to use io_uring to read /dev/input/event on x32...
>>
>> For reference, I checked the socket timestamp handling that has a
>> number of corner cases with time32/time64 formats in compat mode,
>> but none of those appear to be affected by the problem.
>>
>>> Aside from the potentially nasty use of per-task variables, one thing
>>> I don't like about PF_FORCE_COMPAT is that it's one-way. If we're
>>> going to have a generic mechanism for this, shouldn't we allow a full
>>> override of the syscall arch instead of just allowing forcing compat
>>> so that a compat syscall can do a non-compat operation?
>>
>> The only reason it's needed here is that the caller is in a kernel
>> thread rather than a system call. Are there any possible scenarios
>> where one would actually need the opposite?
>>
>
> I can certainly imagine needing to force x32 mode from a kernel thread.
>
> As for the other direction: what exactly are the desired bitness/arch semantics of io_uring? Is the operation bitness chosen by the io_uring creation or by the io_uring_enter() bitness?
It's rather the second one. Even though AFAIR it wasn't discussed
specifically, that how it works now (_partially_).
--
Pavel Begunkov
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Pavel Begunkov @ 2020-09-21 16:13 UTC (permalink / raw)
To: Andy Lutomirski, Arnd Bergmann
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390,
Linux SCSI List, X86 ML, linux-block, Al Viro, Andy Lutomirski,
io-uring, linux-arm-kernel, Jens Axboe, Parisc List,
Network Development, LKML, LSM List, Linux FS Devel,
Andrew Morton, linuxppc-dev
In-Reply-To: <563138b5-7073-74bc-f0c5-b2bad6277e87@gmail.com>
On 21/09/2020 19:10, Pavel Begunkov wrote:
> On 20/09/2020 01:22, Andy Lutomirski wrote:
>>
>>> On Sep 19, 2020, at 2:16 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>
>>> On Sat, Sep 19, 2020 at 6:21 PM Andy Lutomirski <luto@kernel.org> wrote:
>>>>> On Fri, Sep 18, 2020 at 8:16 AM Christoph Hellwig <hch@lst.de> wrote:
>>>>> On Fri, Sep 18, 2020 at 02:58:22PM +0100, Al Viro wrote:
>>>>>> Said that, why not provide a variant that would take an explicit
>>>>>> "is it compat" argument and use it there? And have the normal
>>>>>> one pass in_compat_syscall() to that...
>>>>>
>>>>> That would help to not introduce a regression with this series yes.
>>>>> But it wouldn't fix existing bugs when io_uring is used to access
>>>>> read or write methods that use in_compat_syscall(). One example that
>>>>> I recently ran into is drivers/scsi/sg.c.
>>>
>>> Ah, so reading /dev/input/event* would suffer from the same issue,
>>> and that one would in fact be broken by your patch in the hypothetical
>>> case that someone tried to use io_uring to read /dev/input/event on x32...
>>>
>>> For reference, I checked the socket timestamp handling that has a
>>> number of corner cases with time32/time64 formats in compat mode,
>>> but none of those appear to be affected by the problem.
>>>
>>>> Aside from the potentially nasty use of per-task variables, one thing
>>>> I don't like about PF_FORCE_COMPAT is that it's one-way. If we're
>>>> going to have a generic mechanism for this, shouldn't we allow a full
>>>> override of the syscall arch instead of just allowing forcing compat
>>>> so that a compat syscall can do a non-compat operation?
>>>
>>> The only reason it's needed here is that the caller is in a kernel
>>> thread rather than a system call. Are there any possible scenarios
>>> where one would actually need the opposite?
>>>
>>
>> I can certainly imagine needing to force x32 mode from a kernel thread.
>>
>> As for the other direction: what exactly are the desired bitness/arch semantics of io_uring? Is the operation bitness chosen by the io_uring creation or by the io_uring_enter() bitness?
>
> It's rather the second one. Even though AFAIR it wasn't discussed
> specifically, that how it works now (_partially_).
Double checked -- I'm wrong, that's the former one. Most of it is based
on a flag that was set an creation.
--
Pavel Begunkov
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Pavel Begunkov @ 2020-09-21 16:20 UTC (permalink / raw)
To: William Kucharski, Matthew Wilcox
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390, linux-scsi,
x86, Arnd Bergmann, linux-block, Alexander Viro, io-uring,
linux-arm-kernel, Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <76A432F3-4532-42A4-900E-16C0AC2D21D8@gmail.com>
On 20/09/2020 18:55, William Kucharski wrote:
> I really like that as it’s self-documenting and anyone debugging it can see what is actually being used at a glance.
Also creates special cases for things that few people care about,
and makes it a pain for cross-platform (cross-bitness) development.
>
>> On Sep 20, 2020, at 09:15, Matthew Wilcox <willy@infradead.org> wrote:
>>
>> On Fri, Sep 18, 2020 at 02:45:25PM +0200, Christoph Hellwig wrote:
>>> Add a flag to force processing a syscall as a compat syscall. This is
>>> required so that in_compat_syscall() works for I/O submitted by io_uring
>>> helper threads on behalf of compat syscalls.
>>
>> Al doesn't like this much, but my suggestion is to introduce two new
>> opcodes -- IORING_OP_READV32 and IORING_OP_WRITEV32. The compat code
>> can translate IORING_OP_READV to IORING_OP_READV32 and then the core
>> code can know what that user pointer is pointing to.
--
Pavel Begunkov
^ permalink raw reply
* Re: [PATCH 02/11] mm: call import_iovec() instead of rw_copy_check_uvector() in process_vm_rw()
From: Al Viro @ 2020-09-21 16:27 UTC (permalink / raw)
To: David Laight
Cc: linux-aio@kvack.org, linux-mips@vger.kernel.org, David Howells,
linux-mm@kvack.org, keyrings@vger.kernel.org,
sparclinux@vger.kernel.org, Christoph Hellwig,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
linux-scsi@vger.kernel.org, Arnd Bergmann,
linux-block@vger.kernel.org, io-uring@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jens Axboe,
linux-parisc@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, Andrew Morton,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <226e03bf941844eba4d64af31633c177@AcuMS.aculab.com>
On Mon, Sep 21, 2020 at 03:44:00PM +0000, David Laight wrote:
> From: Al Viro
> > Sent: 21 September 2020 16:30
> >
> > On Mon, Sep 21, 2020 at 03:21:35PM +0000, David Laight wrote:
> >
> > > You really don't want to be looping through the array twice.
> >
> > Profiles, please.
>
> I did some profiling of send() v sendmsg() much earlier in the year.
> I can't remember the exact details but the extra cost of sendmsg()
> is far more than you might expect.
> (I was timing sending fully built IPv4 UDP packets using a raw socket.)
>
> About half the difference does away if you change the
> copy_from_user() to __copy_from_user() when reading the struct msghdr
> and iov[] from userspace (user copy hardening is expensive).
Wha...? So the difference is within 4 times the overhead of the
hardening checks done for one call of copy_from_user()?
> The rest is just code path, my gut feeling is that a lot of that
> is in import_iovec().
>
> Remember semdmsg() is likely to be called with an iov count of 1.
... which makes that loop unlikely to be noticable in the entire
mess, whether you pass it once or twice. IOW, unless you can show
profiles where that loop is sufficiently hot or if you can show
the timings change from splitting it in two, I'll remain very
sceptical about that assertion.
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Pavel Begunkov @ 2020-09-21 16:26 UTC (permalink / raw)
To: Matthew Wilcox, Al Viro
Cc: linux-aio, linux-mips, David Howells, linux-mm, keyrings,
sparclinux, Christoph Hellwig, linux-arch, linux-s390, linux-scsi,
x86, Arnd Bergmann, linux-block, io-uring, linux-arm-kernel,
Jens Axboe, linux-parisc, netdev, linux-kernel,
linux-security-module, linux-fsdevel, Andrew Morton, linuxppc-dev
In-Reply-To: <20200920192259.GU32101@casper.infradead.org>
On 20/09/2020 22:22, Matthew Wilcox wrote:
> On Sun, Sep 20, 2020 at 08:10:31PM +0100, Al Viro wrote:
>> IMO it's much saner to mark those and refuse to touch them from io_uring...
>
> Simpler solution is to remove io_uring from the 32-bit syscall list.
> If you're a 32-bit process, you don't get to use io_uring. Would
> any real users actually care about that?
There were .net and\or wine (which AFAIK often works in compat) guys
experimenting with io_uring, they might want it.
--
Pavel Begunkov
^ permalink raw reply
* Re: [patch RFC 00/15] mm/highmem: Provide a preemptible variant of kmap_atomic & friends
From: Linus Torvalds @ 2020-09-21 16:24 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Juri Lelli, Peter Zijlstra, Sebastian Andrzej Siewior,
Joonas Lahtinen, dri-devel, linux-mips, Ben Segall, Max Filippov,
Guo Ren, linux-sparc, Vincent Chen, Will Deacon, Ard Biesheuvel,
linux-arch, Vincent Guittot, Herbert Xu, the arch/x86 maintainers,
Russell King, linux-csky, David Airlie, Mel Gorman,
open list:SYNOPSYS ARC ARCHITECTURE, linux-xtensa, Paul McKenney,
intel-gfx, linuxppc-dev, Steven Rostedt, Jani Nikula,
Rodrigo Vivi, Dietmar Eggemann, Linux ARM, Chris Zankel,
Michal Simek, Thomas Bogendoerfer, Nick Hu, Linux-MM,
Vineet Gupta, LKML, Arnd Bergmann, Daniel Vetter, Paul Mackerras,
Andrew Morton, Daniel Bristot de Oliveira, David S. Miller,
Greentime Hu
In-Reply-To: <87a6xjd1dw.fsf@nanos.tec.linutronix.de>
On Mon, Sep 21, 2020 at 12:39 AM Thomas Gleixner <tglx@linutronix.de> wrote:
>
> If a task is migrated to a different CPU then the mapping address will
> change which will explode in colourful ways.
Heh.
Right you are.
Maybe we really *could* call this new kmap functionality something
like "kmap_percpu()" (or maybe "local" is good enough), and make it
act like your RT code does for spinlocks - not disable preemption, but
only disabling CPU migration.
That would probably be good enough for a lot of users that don't want
to expose excessive latencies, but where it's really not a huge deal
to say "stick to this CPU for a short while".
The crypto code certainly sounds like one such case.
Linus
^ permalink raw reply
* Re: [PATCH 1/9] kernel: add a PF_FORCE_COMPAT flag
From: Pavel Begunkov @ 2020-09-21 16:31 UTC (permalink / raw)
To: David Laight, 'Arnd Bergmann', Andy Lutomirski
Cc: linux-aio, open list:MIPS, David Howells, Linux-MM,
keyrings@vger.kernel.org, sparclinux, Christoph Hellwig,
linux-arch, linux-s390, Linux SCSI List, X86 ML, Matthew Wilcox,
linux-block, Al Viro, io-uring@vger.kernel.org, linux-arm-kernel,
Jens Axboe, Parisc List, Network Development, LKML, LSM List,
Linux FS Devel, Andrew Morton, linuxppc-dev
In-Reply-To: <8363d874e503470f8caa201e85e9fbd4@AcuMS.aculab.com>
On 21/09/2020 00:13, David Laight wrote:
> From: Arnd Bergmann
>> Sent: 20 September 2020 21:49
>>
>> On Sun, Sep 20, 2020 at 9:28 PM Andy Lutomirski <luto@kernel.org> wrote:
>>> On Sun, Sep 20, 2020 at 12:23 PM Matthew Wilcox <willy@infradead.org> wrote:
>>>>
>>>> On Sun, Sep 20, 2020 at 08:10:31PM +0100, Al Viro wrote:
>>>>> IMO it's much saner to mark those and refuse to touch them from io_uring...
>>>>
>>>> Simpler solution is to remove io_uring from the 32-bit syscall list.
>>>> If you're a 32-bit process, you don't get to use io_uring. Would
>>>> any real users actually care about that?
>>>
>>> We could go one step farther and declare that we're done adding *any*
>>> new compat syscalls :)
>>
>> Would you also stop adding system calls to native 32-bit systems then?
>>
>> On memory constrained systems (less than 2GB a.t.m.), there is still a
>> strong demand for running 32-bit user space, but all of the recent Arm
>> cores (after Cortex-A55) dropped the ability to run 32-bit kernels, so
>> that compat mode may eventually become the primary way to run
>> Linux on cheap embedded systems.
>>
>> I don't think there is any chance we can realistically take away io_uring
>> from the 32-bit ABI any more now.
>
> Can't it just run requests from 32bit apps in a kernel thread that has
> the 'in_compat_syscall' flag set?
> Not that i recall seeing the code where it saves the 'compat' nature
> of any requests.
>
> It is already completely f*cked if you try to pass the command ring
> to a child process - it uses the wrong 'mm'.
And how so? io_uring uses mm of a submitter. The exception is SQPOLL
mode, but it requires CAP_SYS_ADMIN or CAP_SYS_NICE anyway.
> I suspect there are some really horrid security holes in that area.
>
> David.
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
--
Pavel Begunkov
^ permalink raw reply
* error: redefinition of ‘dax_supported’
From: Nick Desaulniers @ 2020-09-21 18:34 UTC (permalink / raw)
To: Dan Williams, Vishal Verma, dave.jiang
Cc: kernelci.org bot, linux-nvdimm, LKML, clang-built-linux,
linuxppc-dev
Hello DAX maintainers,
I noticed our PPC64LE builds failing last night:
https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047043
https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047056
https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047099
and looking on lore, I see a fresh report from KernelCI against arm:
https://lore.kernel.org/linux-next/?q=dax_supported
Can you all please take a look? More concerning is that I see this
failure on mainline. It may be interesting to consider how this was
not spotted on -next.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: [PATCH -next v2] KVM: PPC: Book3S HV: XIVE: Convert to DEFINE_SHOW_ATTRIBUTE
From: Cédric Le Goater @ 2020-09-21 18:44 UTC (permalink / raw)
To: Qinglang Miao, Paul Mackerras, Michael Ellerman,
Benjamin Herrenschmidt
Cc: linuxppc-dev, linux-kernel, kvm-ppc
In-Reply-To: <20200919012925.174377-1-miaoqinglang@huawei.com>
On 9/19/20 3:29 AM, Qinglang Miao wrote:
> Use DEFINE_SHOW_ATTRIBUTE macro to simplify the code.
>
> Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
> ---
> v2: based on linux-next(20200917), and can be applied to
> mainline cleanly now.
>
> arch/powerpc/kvm/book3s_xive_native.c | 12 +-----------
> 1 file changed, 1 insertion(+), 11 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_xive_native.c b/arch/powerpc/kvm/book3s_xive_native.c
> index bdea91df1..d0c2db0e0 100644
> --- a/arch/powerpc/kvm/book3s_xive_native.c
> +++ b/arch/powerpc/kvm/book3s_xive_native.c
> @@ -1227,17 +1227,7 @@ static int xive_native_debug_show(struct seq_file *m, void *private)
> return 0;
> }
>
> -static int xive_native_debug_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, xive_native_debug_show, inode->i_private);
> -}
> -
> -static const struct file_operations xive_native_debug_fops = {
> - .open = xive_native_debug_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = single_release,
> -};
> +DEFINE_SHOW_ATTRIBUTE(xive_native_debug);
>
> static void xive_native_debugfs_init(struct kvmppc_xive *xive)
> {
>
^ permalink raw reply
* Re: error: redefinition of ‘dax_supported’
From: Dan Williams @ 2020-09-21 18:47 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Dave Jiang, kernelci.org bot, linux-nvdimm, LKML,
clang-built-linux, Vishal Verma, linuxppc-dev
In-Reply-To: <CAKwvOdkGd6mPw_OKHwmpVs_xxFW2oqAoXyr7M8hu3PCCwkqCEQ@mail.gmail.com>
On Mon, Sep 21, 2020 at 11:35 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> Hello DAX maintainers,
> I noticed our PPC64LE builds failing last night:
> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047043
> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047056
> https://travis-ci.com/github/ClangBuiltLinux/continuous-integration/jobs/388047099
> and looking on lore, I see a fresh report from KernelCI against arm:
> https://lore.kernel.org/linux-next/?q=dax_supported
>
> Can you all please take a look? More concerning is that I see this
> failure on mainline. It may be interesting to consider how this was
> not spotted on -next.
The failure is fixed with commit 88b67edd7247 ("dax: Fix compilation
for CONFIG_DAX && !CONFIG_FS_DAX"). I rushed the fixes that led to
this regression with insufficient exposure because it was crashing all
users. I thought the 2 kbuild-robot reports I squashed covered all the
config combinations, but there was a straggling report after I sent my
-rc6 pull request.
The baseline process escape for all of this was allowing a unit test
triggerable insta-crash upstream in the first instance necessitating
an urgent fix.
^ permalink raw reply
* [PATCH v2 0/2] DAI driver for new XCVR IP
From: Viorel Suman (OSS) @ 2020-09-21 19:08 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Jaroslav Kysela,
Takashi Iwai, Timur Tabi, Nicolin Chen, Xiubo Li, Fabio Estevam,
Shengjiu Wang, Philipp Zabel, Viorel Suman, Matthias Schiffer,
Cosmin-Gabriel Samoila, alsa-devel, devicetree, linux-kernel,
linuxppc-dev
Cc: Viorel Suman, NXP Linux Team
From: Viorel Suman <viorel.suman@nxp.com>
DAI driver for new XCVR IP found in i.MX8MP.
Viorel Suman (2):
ASoC: fsl_xcvr: Add XCVR ASoC CPU DAI driver
ASoC: dt-bindings: fsl_xcvr: Add document for XCVR
Changes since v1:
- improved 6- and 12-ch layout comment
- used regmap polling function, improved
clocks handling in runtime_resume
- added FW size check in FW load function,
improved IRQ handler, removed dummy IRQ handlers
- fixed yaml file
.../devicetree/bindings/sound/fsl,xcvr.yaml | 103 ++
sound/soc/fsl/Kconfig | 10 +
sound/soc/fsl/Makefile | 2 +
sound/soc/fsl/fsl_xcvr.c | 1343 ++++++++++++++++++++
sound/soc/fsl/fsl_xcvr.h | 266 ++++
5 files changed, 1724 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/fsl,xcvr.yaml
create mode 100644 sound/soc/fsl/fsl_xcvr.c
create mode 100644 sound/soc/fsl/fsl_xcvr.h
--
2.7.4
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox