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

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] [day] [month] [year] [list]

Message-ID: <CAPcyv4iszMZ60gbjTHjY5gSuieQTD9wEoUmHSWMfeb6KMS4tWQ@mail.gmail.com>
Date:   Tue, 25 Apr 2017 15:22:15 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Stephen Rothwell <sfr@...b.auug.org.au>,
        Linux-Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: linux-next: build failure after merge of the nvdimm tree

On Mon, Apr 24, 2017 at 1:39 AM, Al Viro <viro@...iv.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.