[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AM0PR04MB42907C7E4A7E1B09ED7B6BBEEEC80@AM0PR04MB4290.eurprd04.prod.outlook.com>
Date: Sat, 3 Nov 2018 15:49:43 +0000
From: Leonard Crestez <leonard.crestez@....com>
To: David Howells <dhowells@...hat.com>,
Trond Myklebust <trond.myklebust@...merspace.com>,
Stephen Rothwell <sfr@...b.auug.org.au>
CC: kernel test robot <rong.a.chen@...el.com>,
"J. Bruce Fields" <bfields@...ldses.org>,
Jeff Layton <jlayton@...nel.org>,
Alexander Viro <viro@...iv.linux.org.uk>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"lkp@...org" <lkp@...org>
Subject: Re: [LKP] [sunrpc] 6a7da2a288: kernel_BUG_at_lib/iov_iter.c
On 11/2/2018 2:50 AM, David Howells wrote:
> kernel test robot <rong.a.chen@...el.com> wrote:
>
>> FYI, we noticed the following commit (built with gcc-7):
>>
>> commit: 6a7da2a288ce412d7ac117a2912a7b0d9104ee6d ("[RFC] sunrpc: Fix flood of warnings from iov_iter_kvec in linux-next")
>> url: https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2F0day-ci%2Flinux%2Fcommits%2FLeonard-Crestez%2Fsunrpc-Fix-flood-of-warnings-from-iov_iter_kvec-in-linux-next%2F20181101-070713&data=02%7C01%7Cleonard.crestez%40nxp.com%7C0b22a6d58a5242277ca008d6405d28b3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636767166190134069&sdata=335WGS8H6GRfqp%2BDmocDQ8mowhe7a0RxKbfM6rSgJ3g%3D&reserved=0
>> base: git://git.linux-nfs.org/projects/trondmy/linux-nfs.git linux-next
>>
>> in testcase: boot
>>
>> on test machine: qemu-system-x86_64 -enable-kvm -cpu kvm64,+ssse3 -smp 2 -m 8G
>>
>> caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
>
> Ummm... You can't just apply that commit to Trond's linux-next branch unless
> that branch also includes the iov_iter changes from my afs-next branch.
>
> Before those changes, ITER_KVEC is required:
>
> BUG_ON(!(direction & ITER_KVEC));
>
> and after, it will be prohibited:
>
> WARN_ON(direction & ~(READ | WRITE));
>
> The reason for this is that have yet more patches that split the direction
> from the iov_iter::type member into their own member and turn the types into a
> simple integer sequence instead of a bit mask.
It's not clear how such conflicts should be handled. Maybe patches from
one tree should be pulled into the other earlier so that merging "just
works"?
--
Regards,
Leonard
Powered by blists - more mailing lists