public inbox for linux-crypto@vger.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>
Cc: Alexander Graf <graf@amazon.com>, Len Brown <lenb@kernel.org>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	ACPI Devel Maling List <linux-acpi@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ard Biesheuvel <ardb@kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Subject: Re: [PATCH v5 2/3] ACPI: allow longer device IDs
Date: Tue, 1 Mar 2022 11:31:51 +0100	[thread overview]
Message-ID: <7769e728-5864-115d-c3b8-8f52faa40f1a@redhat.com> (raw)
In-Reply-To: <CAJZ5v0h_Z9XS9ZgSF4CWrZ4RU7=Oa02MY3_g0Y_rcgRNzsizfQ@mail.gmail.com>

Hi,

On 2/28/22 19:19, Rafael J. Wysocki wrote:
> +Mika, Andy and Hans in case they have something to add

Thanks, I don't really have anything to add to the discussion
on v6 of this patch.

Regards,

Hans



> 
> On Mon, Feb 28, 2022 at 12:27 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>>
>> Hey again,
>>
>> On Sun, Feb 27, 2022 at 1:43 PM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>>>
>>> Hi Alex,
>>>
>>> On Sun, Feb 27, 2022 at 12:42:03PM +0100, Alexander Graf wrote:
>>>>> To allow device drivers to match identifiers that exceed the 9 byte
>>>>> limit, this simply ups the length to 16, just like it was before the
>>>>> aforementioned commit. Empirical testing indicates that this
>>>>
>>>>
>>>> This is only true for 64bit systems where padding automatically bloated
>>>> to 9 byte array to 16. I still believe the patch is fine as it is, but
>>>> there will be minor .rodata overhead on 32bit targets which you may want
>>>> to quantify in the patch description.
>>>
>>> Good point. So I just tried this out with a 32-bit i686 kernel and the
>>> results are the same again for the size of vmlinux. I then ran `objdump
>>> --headers` and looked at the size of the .rodata section, where it's
>>> also the same. I'm not quite sure what to make of this, as it's not what
>>> I was expecting, but I think I tested it right. So maybe we're lucky
>>> here?
>>
>> I tried a little harder to get _some_ difference on 32-bit, and
>> managed to get one by doing i386_defconfig and then switching off
>> modules to make all M into Y, and then compared sizes:
>>
>> vmlinux: 25590780 -> 25598972, so a 0.032% increase.
>> bzImage: 8698944 -> 8699424, so a 0.0055% increase.
>>
>> So it does increase, ever so slightly, but a) on 32-bit, and b) a
>> super, super tiny amount.
>>
>> In other words, I still think this patch is very much a-okay. But very
>> eager to hear from Rafael on the approach.
> 
> Increasing the ACPI_ID_LEN value is fine with me, but the patch
> changelog is not entirely accurate.
> 
> The ACPI subsystem uses struct acpi_device_id mostly (if not only) for
> device ID matching and it is generally used for creating lists of ACPI
> device IDs in drivers (and allow/deny lists etc).  The device IDs
> extracted from the ACPI tables can be longer than ACPI_ID_LEN.
> 
> This means that drivers cannot match device IDs longer than 8
> characters (excluding the terminating 0), because the IDs in the lists
> used by them for ID matching cannot be longer than this and not
> because the ACPI subsystem is limited by that value.
> 


  parent reply	other threads:[~2022-03-01 10:31 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-26 22:06 [PATCH v5 0/3] ACPI: VM fork detection for RNG Jason A. Donenfeld
2022-02-26 22:06 ` [PATCH v5 1/3] random: add mechanism for VM forks to reinitialize crng Jason A. Donenfeld
2022-02-26 22:06 ` [PATCH v5 2/3] ACPI: allow longer device IDs Jason A. Donenfeld
2022-02-27  7:31   ` Ard Biesheuvel
2022-02-27  7:37     ` Ard Biesheuvel
2022-02-27 10:03     ` Jason A. Donenfeld
2022-02-27 10:30       ` Ard Biesheuvel
2022-02-27 10:47         ` Ard Biesheuvel
2022-02-27 11:38           ` Alexander Graf
2022-02-27 11:43             ` Ard Biesheuvel
2022-02-27 11:48               ` Alexander Graf
2022-02-27 11:59                 ` Ard Biesheuvel
2022-02-27 11:42   ` Alexander Graf
2022-02-27 12:43     ` Jason A. Donenfeld
2022-02-27 23:27       ` Jason A. Donenfeld
2022-02-28 18:19         ` Rafael J. Wysocki
2022-02-28 18:21           ` Jason A. Donenfeld
2022-02-28 18:33             ` [PATCH 2/3 v6] " Jason A. Donenfeld
2022-02-28 20:46               ` Andy Shevchenko
2022-02-28 20:58                 ` Jason A. Donenfeld
2022-02-28 21:02                 ` Ard Biesheuvel
2022-02-28 21:27                   ` Andy Shevchenko
2022-02-28 21:54                     ` Jason A. Donenfeld
2022-02-28 22:14                       ` Michael Kelley (LINUX)
2022-02-28 22:17                         ` Jason A. Donenfeld
2022-02-28 22:21                         ` Ard Biesheuvel
2022-02-28 22:38                           ` Michael Kelley (LINUX)
2022-02-28 22:46                             ` Ard Biesheuvel
2022-03-22 19:58                               ` Michael Kelley (LINUX)
2022-03-22 20:11                                 ` Jason A. Donenfeld
2022-03-24 19:25                                   ` Michael Kelley (LINUX)
2022-03-22 22:06                                 ` Ard Biesheuvel
2022-03-24 19:24                                   ` Michael Kelley (LINUX)
2022-03-24 19:45                                     ` Jason A. Donenfeld
2022-03-24 20:14                                       ` Michael Kelley (LINUX)
2022-03-01 13:12                         ` Andy Shevchenko
2022-02-28 22:00                     ` Alexander Graf
2022-02-28 22:17                       ` Ard Biesheuvel
2022-03-01 10:35               ` Hans de Goede
2022-03-01 10:38                 ` Jason A. Donenfeld
2022-03-01 10:49                   ` Hans de Goede
2022-03-01 14:25                 ` Andy Shevchenko
2022-03-01 14:48                   ` Jason A. Donenfeld
2022-03-01 12:29               ` Rafael J. Wysocki
2022-03-01 10:31           ` Hans de Goede [this message]
2022-02-26 22:06 ` [PATCH v5 3/3] virt: vmgenid: introduce driver for reinitializing RNG on VM fork Jason A. Donenfeld
2022-03-06 16:02   ` Michael Kelley (LINUX)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7769e728-5864-115d-c3b8-8f52faa40f1a@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=Jason@zx2c4.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=ardb@kernel.org \
    --cc=graf@amazon.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=rafael@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox