[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <08e4e9d8-2c42-115a-f440-d7f44fb19280@arm.com>
Date: Tue, 7 Dec 2021 12:41:52 +0530
From: Amit Kachhap <amit.kachhap@....com>
To: Christoph Hellwig <hch@....de>
Cc: linux-kernel@...r.kernel.org,
Vincenzo Frascino <Vincenzo.Frascino@....com>,
Kevin Brodsky <kevin.brodsky@....com>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>,
kexec <kexec@...ts.infradead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Young <dyoung@...hat.com>, Baoquan He <bhe@...hat.com>,
Vivek Goyal <vgoyal@...hat.com>, x86 <x86@...nel.org>
Subject: Re: [RFC PATCH 01/14] fs/proc/vmcore: Update read_from_oldmem() for
user pointer
On 12/6/21 7:34 PM, Christoph Hellwig wrote:
> On Fri, Dec 03, 2021 at 04:12:18PM +0530, Amit Daniel Kachhap wrote:
>> + return read_from_oldmem_to_kernel(buf, count, ppos,
>> + cc_platform_has(CC_ATTR_GUEST_MEM_ENCRYPT));
>
> Overly long line.
>
>> +ssize_t read_from_oldmem(char __user *ubuf, char *kbuf, size_t count,
>> + u64 *ppos, bool encrypted)
>> {
>> unsigned long pfn, offset;
>> size_t nr_bytes;
>> @@ -156,19 +163,27 @@ ssize_t read_from_oldmem(char *buf, size_t count,
>> /* If pfn is not ram, return zeros for sparse dump files */
>> if (!pfn_is_ram(pfn)) {
>> tmp = 0;
>> - if (!userbuf)
>> - memset(buf, 0, nr_bytes);
>> - else if (clear_user(buf, nr_bytes))
>> + if (kbuf)
>> + memset(kbuf, 0, nr_bytes);
>> + else if (clear_user(ubuf, nr_bytes))
>> tmp = -EFAULT;
>
> This looks like a huge mess. What speak against using an iov_iter
> here?
iov_iter seems to be a reasonable way. As a start I thought of adding
minimal changes.
>
Powered by blists - more mailing lists