linux-kernel - Re: [RFC PATCH v1 22/57] sound: Remove PAGE

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: <6258fd24-e708-444b-88a3-792c14527817@arm.com>
Date: Tue, 15 Oct 2024 12:35:23 +0100
From: Ryan Roberts <ryan.roberts@....com>
To: Mark Brown <broonie@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Anshuman Khandual <anshuman.khandual@....com>,
 Ard Biesheuvel <ardb@...nel.org>, Catalin Marinas <catalin.marinas@....com>,
 David Hildenbrand <david@...hat.com>, Greg Marsden
 <greg.marsden@...cle.com>, Ivan Ivanov <ivan.ivanov@...e.com>,
 Jaroslav Kysela <perex@...ex.cz>, Kalesh Singh <kaleshsingh@...gle.com>,
 Marc Zyngier <maz@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Matthias Brugger <mbrugger@...e.com>, Miroslav Benes <mbenes@...e.cz>,
 Takashi Iwai <tiwai@...e.com>, Will Deacon <will@...nel.org>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, linux-sound@...r.kernel.org
Subject: Re: [RFC PATCH v1 22/57] sound: Remove PAGE_SIZE compile-time
 constant assumption

On 14/10/2024 17:01, Mark Brown wrote:
> On Mon, Oct 14, 2024 at 01:24:02PM +0100, Ryan Roberts wrote:
>> On 14/10/2024 12:38, Mark Brown wrote:
>>> On Mon, Oct 14, 2024 at 11:58:29AM +0100, Ryan Roberts wrote:
> 
>>>> ***NOTE***
>>>> Any confused maintainers may want to read the cover note here for context:
>>>> https://lore.kernel.org/all/20241014105514.3206191-1-ryan.roberts@arm.com/
> 
>>> As documented in submitting-patches.rst please send patches to the 
>>> maintainers for the code you would like to change.  The normal kernel
>>> workflow is that people apply patches from their inboxes, if they aren't
>>> copied they are likely to not see the patch at all and it is much more
>>> difficult to apply patches.
> 
>> Sure. I think you're implying that you would have liked to be in To: for this
>> patch? I went to quite a lot of trouble to ensure all maintainers were at least
>> in the To: field for patches touching their code. But get_maintainer.pl lists
>> you as a supporter, not a maintainer when I ran this patch through. Could you
>> clarify what would have been the correct thing to do? I could include all
>> reviewers and supporters as well as maintainers but then I'd be banging up
>> against the limits for some of the patches.
> 
> The entry in MAINTAINERS for me is a M:, supporter is just the usual
> get_maintainers noise.  Supported is exactly equivalent to a maintainer.

Ugh, In my head I always thought "supporter" was somebody who engaged with the
subsystem but did not have an official role (like a football supporter). But now
that I've gone and read the MAINTAINERS file, I see it's actually referring to
status (supported vs maintained). Sorry about this. Due to this buggy filtering,
I've missed a few others off other patches in this series. I'll fix that by
forwarding to them.

> Generally if you're going to filter people you should be filtering less
> specific matches out rather than more and if you're looking to filter
> very aggressively look at who actually commits changes to whatever
> you're trying to change, less specific maintainers will generally
> delegate down to the more specific ones.
> 
>>> It's probably better to just use PAGE_SIZE_MAX here and avoid the
>>> deferred patching, like the comment says we don't particularly care what
>>> the value actually is here given that it's a dummy.
> 
>> OK, so would that be:
> 
>> 	.buffer_bytes_max	= 128*1024,
>> 	.period_bytes_min	= PAGE_SIZE_MAX,      <<<<<
>> 	.period_bytes_max	= PAGE_SIZE_MAX*2,    <<<<<
>> 	.periods_min		= 2,
>> 	.periods_max		= 128,
> 
>> It's not really clear to me how all the parameters interact; the buffer size
>> 128K, which, if PAGE_SIZE_MAX is 64K, would hold 1 period of the maximum size.
>> But periods_min is 2. So not sure that works? Or perhaps I'm trying to apply too
>> much meaning to the param names...
> 
> Like Takashi says just using absolute numbers here is probably just as
> sensible, the numbers are there to stop userspace tripping over itself
> but like I say it shouldn't ever get as far as actually using them for
> anything.  So long as we end up with some numbers that don't need any
> late init patching the specifics aren't super important, the use of
> PAGE_SIZE was kind of random.

OK, I'll post a respin of this patch independently of the rest of the series,
given it no longer has a dependency.

Thanks,
Ryan