linux-kernel - Re: [PATCH v2 2/2] PCI: Clean up resource_alignment parameter to not require static buffer

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]

Date:   Fri, 12 Apr 2019 14:53:02 -0600
From:   Logan Gunthorpe <logang@...tatee.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH v2 2/2] PCI: Clean up resource_alignment parameter to not
 require static buffer



On 2019-04-12 2:44 p.m., Bjorn Helgaas wrote:
> On Wed, Apr 10, 2019 at 03:05:32PM -0600, Logan Gunthorpe wrote:
>> Clean up the 'resource_alignment' parameter code to use kstrdup
>> in the initcall routine instead of a static buffer that wastes memory
>> regardless of whether the feature is used. This allows us to drop
>> 'COMMAND_LINE_SIZE' bytes (typically 256-4096 depending on architecture)
>> of static data.
>>
>> This is similar to what has been done for the 'disable_acs_redir'
>> parameter.
>>
>> This conversion also allows us to use RCU instead of the spinlock to
>> deal with the concurrency issue which further reduces memory usage.
> 
> I'm unconvinced about this part.  Spinlocks are CS 101 material and
> I'm a little hesitant to use a graduate-level technique like RCU in a
> case where it doesn't really buy us much -- we don't need the
> performance advantage and the size advantage seems minimal.  But I'm
> an RCU ignoramus and maybe need to be educated.

That's a reasonable point. I didn't think it was that difficult and the
kernel's RCU API is pretty straightforward. But I can resubmit later
keeping the spinlock. You're right that it's not that big of a gain.

>> As part of the clean up we also squash pci_get_resource_alignment_param()
>> into resource_alignment_show() and pci_set_resource_alignment_param()
>> into resource_alignment_store() seeing these functions only had one
>> caller and the show/store wrappers were needlessly thin.
> 
> Squashing makes sense and would be nice as a separate patch.

Ok, will do.

Logan