Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1631032 > unrolled thread

Re: linux-next: build failure after merge of the nvdimm tree

Started byDan Williams <dan.j.williams@intel.com>
First post2017-04-26 00:30 +0200
Last post2017-04-26 00:30 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: linux-next: build failure after merge of the nvdimm tree Dan Williams <dan.j.williams@intel.com> - 2017-04-26 00:30 +0200

#1631032 — Re: linux-next: build failure after merge of the nvdimm tree

FromDan Williams <dan.j.williams@intel.com>
Date2017-04-26 00:30 +0200
SubjectRe: linux-next: build failure after merge of the nvdimm tree
Message-ID<tAh85-29H-1@gated-at.bofh.it>
On Mon, Apr 24, 2017 at 1:39 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Mon, Apr 24, 2017 at 04:11:30PM +1000, Stephen Rothwell wrote:
>> Hi Dan,
>>
>> After merging the nvdimm tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvdimm/x86.c: In function 'pmem_from_user':
>> drivers/nvdimm/x86.c:115:11: error: implicit declaration of function '__copy_from_user_nocache' [-Werror=implicit-function-declaration]
>>   int rc = __copy_from_user_nocache(dst, src, size);
>>            ^
>>
>> Caused by commit
>>
>>   6e704ff67315 ("uio, libnvdimm, pmem: implement cache bypass for all copy_from_iter() operations")
>>
>> interacting with commit
>>
>>   3f763453e6f2 ("kill __copy_from_user_nocache()")
>>
>> from the vfs tree.
>>
>> I have no idea why Al removed that function,
>
> Because the entire nocache pile is messy and misguided and the fewer of
> those we have, the easier it will be to untangle the damn thing.  This
> particular turdlet had no users in mainline.  Unfortunately, it has
> grown one in nvdimm, so we'll probably have to drop that removal for now
> and hope that it won't be too painful to untangle come next cycle.
>
> Oh, well...  Guess we'll need to resurrect memcpy_nocache() threads from
> December and deal witht that mess for good.

Al, I've kicked this new usage of __copy_from_user_nocache out of
-next and I'll rebase my pmem vs uaccess work on vfs.git/for-next.

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web