linux-kernel - Re: [PATCH v6 5/6] pmem: refactor pmem_clear

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

Message-ID: <20fba522-c978-8d6b-5498-8e768897a129@oracle.com>
Date:   Tue, 22 Mar 2022 23:45:38 +0000
From:   Jane Chu <jane.chu@...cle.com>
To:     Christoph Hellwig <hch@...radead.org>
CC:     "david@...morbit.com" <david@...morbit.com>,
        "djwong@...nel.org" <djwong@...nel.org>,
        "dan.j.williams@...el.com" <dan.j.williams@...el.com>,
        "vishal.l.verma@...el.com" <vishal.l.verma@...el.com>,
        "dave.jiang@...el.com" <dave.jiang@...el.com>,
        "agk@...hat.com" <agk@...hat.com>,
        "snitzer@...hat.com" <snitzer@...hat.com>,
        "dm-devel@...hat.com" <dm-devel@...hat.com>,
        "ira.weiny@...el.com" <ira.weiny@...el.com>,
        "willy@...radead.org" <willy@...radead.org>,
        "vgoyal@...hat.com" <vgoyal@...hat.com>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-xfs@...r.kernel.org" <linux-xfs@...r.kernel.org>
Subject: Re: [PATCH v6 5/6] pmem: refactor pmem_clear_poison()

On 3/22/2022 1:53 AM, Christoph Hellwig wrote:
>> -static void hwpoison_clear(struct pmem_device *pmem,
>> -		phys_addr_t phys, unsigned int len)
>> +static phys_addr_t to_phys(struct pmem_device *pmem, phys_addr_t offset)
>>   {
>> +	return pmem->phys_addr + offset;
>> +}
>> +
>> +static sector_t to_sect(struct pmem_device *pmem, phys_addr_t offset)
>> +{
>> +	return (offset - pmem->data_offset) / 512;
>> +}
>> +
>> +static phys_addr_t to_offset(struct pmem_device *pmem, sector_t sector)
>> +{
>> +	return sector * 512 + pmem->data_offset;
>> +}
> 
> The multiplicate / divison using 512 could use shifts using
> SECTOR_SHIFT.

Nice, will do.

> 
>> +
>> +static void clear_hwpoison(struct pmem_device *pmem, phys_addr_t offset,
>> +		unsigned int len)
> 
>> +static void clear_bb(struct pmem_device *pmem, sector_t sector, long blks)
> 
> All these functions lack a pmem_ prefix.

Did you mean all of the helpers or just "clear_hwpoison" and "clear_bb"? 
   The reason I ask is that there are existing static helpers without 
pmem_ prefix, just short function names.

> 
>> +static blk_status_t __pmem_clear_poison(struct pmem_device *pmem,
>> +		phys_addr_t offset, unsigned int len,
>> +		unsigned int *blks)
>> +{
>> +	phys_addr_t phys = to_phys(pmem, offset);
>>   	long cleared;
>> +	blk_status_t rc;
>>   
>> +	cleared = nvdimm_clear_poison(to_dev(pmem), phys, len);
>> +	*blks = cleared / 512;
>> +	rc = (cleared < len) ? BLK_STS_IOERR : BLK_STS_OK;
>> +	if (cleared <= 0 || *blks == 0)
>> +		return rc;
> 
> This look odd.  I think just returing the cleared byte value would
> make much more sense:
> 
> static long __pmem_clear_poison(struct pmem_device *pmem,
> 		phys_addr_t offset, unsigned int len)
> {
> 	long cleared = nvdimm_clear_poison(to_dev(pmem), phys, len);
> 
> 	if (cleared > 0) {
> 		clear_hwpoison(pmem, offset, cleared);
> 		arch_invalidate_pmem(pmem->virt_addr + offset, len);
> 	}
> 
> 	return cleared;
> }

Yes, this is cleaner, will do.

Thanks!
-jane