[OS-BUILD PATCH] kernel/rh_messages.c: Another gcc12 warning on redundant NULL test

[Florian Weimer (via Email Bridge)]

From: Florian Weimer 

kernel/rh_messages.c: Another gcc12 warning on redundant NULL test

Upstream Status: RHEL only
Bugzilla: https://bugzilla.redhat.com/2216678

Commit f27fc648898bdba50204e9d6eb34cecd ("kernel/rh_messages.c:
gcc12 warning on redundant NULL test") missed the mod->name check
added in commit 5d3565f9ffcb927868fc7baf1bf37707f934bdc("Add Partner
Supported taint flag").


Signed-off-by: Florian Weimer 

diff --git a/kernel/rh_messages.c b/kernel/rh_messages.c
index blahblah..blahblah 100644
--- a/kernel/rh_messages.c
+++ b/kernel/rh_messages.c
@@ -193,7 +193,7 @@ void mark_partner_supported(const char *msg, struct module 
*mod)
if (msg)
str = msg;
 #ifdef CONFIG_MODULES
-   else if (mod && mod->name)
+   else if (mod)
str = mod->name;
 #endif
 

--
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/2527
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Florian Weimer]

* Adam Williamson:

> On Thu, 2022-12-08 at 07:57 +0100, Florian Weimer wrote:
>> * Adam Williamson:
>> 
>> > 1. /usr/lib/locale/locale-archive , from glibc-all-langpacks - this is
>> > 224M uncompressed. A quick test just compressing the file with xz on my
>> > system shows it compresses to around 11M, though, so that's probably
>> > all it adds up to after compression (the image is an xz-compressed
>> > squashfs)
>> 
>> Isn't the compression block-based?  I think it would be interesting to
>> measure the image size with the file removed.
>
> I'll try it tomorrow, it's not too hard.

Have you posted the outcome of the experiment somewhere?

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Florian Weimer]

* Richard W. M. Jones:

> You only need network / wifi firmware blobs (although I'm sure they
> are in themselves large) and then you can fetch anything else needed
> for the hardware including graphics, right?

I think you need graphics to set up wifi.

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Small rant: installer environment size

[Florian Weimer]

* Adam Williamson:

> 1. /usr/lib/locale/locale-archive , from glibc-all-langpacks - this is
> 224M uncompressed. A quick test just compressing the file with xz on my
> system shows it compresses to around 11M, though, so that's probably
> all it adds up to after compression (the image is an xz-compressed
> squashfs)

Isn't the compression block-based?  I think it would be interesting to
measure the image size with the file removed.

For the non-live installer, we can *significantly* cut down its size,
without degrading localization of the installer itself.

> 2. /usr/lib64/libLLVM-15.so, which is 114M on its own, compresses to
> 23M. We are, I think, basically stuck with this for mesa-dri-drivers ,
> but does it have to be so *big*?

It has all the targets in it.  As it's for JIT, we'd only need one
target.

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390

[Florian Weimer (via Email Bridge)]

From: Florian Weimer on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_598979089

Current GCC compiles this code to use the `msrkc` instruction:

```c
#include 

int
f (int a, int b)
{
  int result;
  if (__builtin_mul_overflow (a, b, &result))
abort ();
  return result;
}

int
main (int argc, char **argv)
{
  return f (atoi (argv[1]), atoi (argv[2]));
}
```

Maybe not exactly common, but also not super-obscure.  I think the kernel uses
`__builtin_mul_overflow` in some places.  `s390.md` in GCC has patterns for
the other instructions, too, search for `TARGET_Z14`.

The sort-of working aspect was the reason why I added the run-time check to
glibc.  I was worried that without it, some z14 binaries will appear to work,
but crash in obscure ways for some operations because GCC happened to emit one
of the new instructions.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCHv3 0/5] ark: Set Architecture Level Set to Z14 for s390

[Florian Weimer (via Email Bridge)]

From: Florian Weimer on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595913747

glibc 2.34 will detect `-march=z14` and refuse to run on z13 or earlier, to
avoid hard-to-diagnose crashes later. We learned the hard way that this very
desirable during the ppc64le bringup.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCHv2 0/5] ark: Set Architecture Level Set to Z14 for s390

[Florian Weimer (via Email Bridge)]

From: Florian Weimer on gitlab.com
https://gitlab.com/cki-project/kernel-ark/-/merge_requests/1144#note_595258853

As far as I know, Fedora infrastructure is not ready for this because it's
still z13. Is this going to a problem for ARK or Fedora? Thanks.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: aarch64 build failures in rawhide

[Florian Weimer]

* Peter Robinson:

> On Fri, May 7, 2021 at 7:58 AM Florian Weimer  wrote:
>>
>> We want to use kernel rebuilds as a gating test for toolchain updates.
>> Unfortunately, per
>>
>>   Information for package kernel
>>   <https://koji.fedoraproject.org/koji/packageinfo?packageID=8>
>>
>> the last successful rawhide kernel build was on 2021-04-28.
>>
>> The question is what we should do about build failures like this.
>> Should we use non-rawhide kernels for our gating tests?
>
> Well rawhide is generally OK, but it's not unusual for kernels to fail
> during the two week upstream merge window, I've seen all arches in x86
> cause issues during the merge window. Outside of that things tend to
> be OK.

Hmm.  Currently our gating check simply does

  koji build --scratch --wait --fail-fast f34-build-side-40913 
git+https://src.fedoraproject.org/rpms/kernel#rawhide

(Well, it's a bug that we use the rawhide kernel branch on the f34
branch, but we'd still be impacted for actual rawhide builds of
toolchain packages, of course.)

This koji command is nice and short, but it assumes that the dist-git
branch is actually buildable.

Should we use a SRPM from a compose instead?  But composes can be really
old, and if we need a kernel fix to get things building again with newer
toolchains, then this could potentially block toolchain upgrades for a
long time.

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

aarch64 build failures in rawhide

[Florian Weimer]

We want to use kernel rebuilds as a gating test for toolchain updates.
Unfortunately, per

  Information for package kernel
  

the last successful rawhide kernel build was on 2021-04-28.

The question is what we should do about build failures like this.
Should we use non-rawhide kernels for our gating tests?

(The bug appears to be in BTF generation: it is not valid to assume that
static functions or variables are emitted under their declared names, or
that they have any particular calling convention or data layout.  It's
probably best to drop the static if symbols are used for BTF extraction.
An alternative would be to use __attribute__ ((used)) instead, but then
the linker won't check for name collisions, which would result in
incorrect BTF.)

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: [OS-BUILD PATCH] Turn off vdso_install for ppc

[Florian Weimer]

* Justin Forbes:

> On Mon, Jan 4, 2021 at 7:42 PM GitLab Bridge on behalf of Don Zickus
>  wrote:
>>
>> From: Don Zickus on gitlab.com
>> https://gitlab.com/cki-project/kernel-ark/-/merge_requests/842#note_477950659
>>
>> Seems right.  I would be interested if that compiles, installs and
>> boots.
>
> It compiles, I did a koji scratch build before submitting this.  No
> clue on boots though.

Do the vdso files still end up in the RPM?  If not, I suspect that's
going to cause issues when debugging.

There should be a file /lib/modules/*/vdso/vdso64.so.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Test reply Re: System no longer distributes load to multiple cores for long running task

[Florian Weimer]

* Justin Forbes:

> Reverted, but no, I do not see such an option for the list. I am
> wondering if it is something set at the overall list server config,
> and not available per list by policy there.

Apparently, someone has installed a Python handler to perform the
message transformation:



Since it involves arbitrary Python code, maybe list admins don't have
access?

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: System no longer distributes load to multiple cores for long running task

[Florian Weimer]

* Justin Forbes:

> On Thu, Sep 24, 2020 at 4:34 AM Florian Weimer  wrote:
>>
>> * Chris Murphy:
>>
>> > On Wed, Sep 23, 2020 at 1:44 PM stan  wrote:
>> >
>> > For what it's worth, gmail puts your emails into spam because of the
>> > your domain's DMARC policy:
>> >
>> >
>> > Authentication-Results: mx.google.com;
>> >arc=fail (body hash mismatch);
>>
>> That's a Fedora mailing list configuration issue.  It alters the body.
>>
>> These days, mailing lists need to be configured in such a way that they
>> do not add such footers (adding headers is generally fine).
>>
>
> I don't see any option to change that in the list settings.

As a user/subscriber?  Yes, I think it's a list administrator setting.

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: System no longer distributes load to multiple cores for long running task

[Florian Weimer]

* Chris Murphy:

> On Wed, Sep 23, 2020 at 1:44 PM stan  wrote:
>
> For what it's worth, gmail puts your emails into spam because of the
> your domain's DMARC policy:
>
>
> Authentication-Results: mx.google.com;
>arc=fail (body hash mismatch);

That's a Fedora mailing list configuration issue.  It alters the body.

These days, mailing lists need to be configured in such a way that they
do not add such footers (adding headers is generally fine).

Thanks,
Florian
-- 
Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Corrupt RPM package in Fedora 31 compose: perf-debuginfo-5.5.9-200.fc31.x86_64

[Florian Weimer]

* Petr Pisar:

> On Mon, Apr 06, 2020 at 12:14:23PM +0200, Florian Weimer wrote:
>> Installation fails like this:
>> 
>> Running transaction
>>   Preparing:   
>> 1/1 
>>   Installing   : perf-debuginfo-5.5.15-200.fc31.x86_64 
>> 1/1 
>> Error unpacking rpm package perf-debuginfo-5.5.15-200.fc31.x86_64
>>   Verifying: perf-debuginfo-5.5.15-200.fc31.x86_64 
>> 1/1 
>> 
>> The RPM headers look okay, but the payload seems to be missing
>> completely.
>> 
>> perf-debuginfo-5.5.9-200.fc31.x86_64 seems to be affected as well, so
>> this might be a deterministic issue. 8-(
>> 
>> Any suggestions how to debug this further?
>> 
> Downloading the package from Koji
> <https://kojipkgs.fedoraproject.org//packages/kernel-tools/5.5.15/200.fc31/x86_64/perf-debuginfo-5.5.15-200.fc31.x86_64.rpm>
> hangs. It looks like a storage failure and a compose process just did not
> verify that the download finished successfully and copied the incomplete
> package to the repository.
>
> I recommend you reporting it to the Fedora Infrastracture.

Done: https://pagure.io/fedora-infrastructure/issue/8816

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Corrupt RPM package in Fedora 31 compose: perf-debuginfo-5.5.9-200.fc31.x86_64

[Florian Weimer]

Installation fails like this:

Running transaction
  Preparing:   1/1 
  Installing   : perf-debuginfo-5.5.15-200.fc31.x86_64 1/1 
Error unpacking rpm package perf-debuginfo-5.5.15-200.fc31.x86_64
  Verifying: perf-debuginfo-5.5.15-200.fc31.x86_64 1/1 

The RPM headers look okay, but the payload seems to be missing
completely.

perf-debuginfo-5.5.9-200.fc31.x86_64 seems to be affected as well, so
this might be a deterministic issue. 8-(

Any suggestions how to debug this further?

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: nvidia kernel is tainted following updates

[Florian Weimer]

* Chris Murphy:

> But I'm not sure what else I can infer about kernel taint. Are all the
> other lockdowns still in place?

If you can load kernel modules which do not pass signature verification,
kernel lockdown is not active.

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: Have the 5.6 kernels dropped support for user input of entropy to the kernel?

[Florian Weimer]

* stan:

> I built my first 5.6 custom kernel from the src.rpm yesterday in F31.
> And my patch to enable the use of a daemon I run to gather entropy from
> an rtl2832 (atmospheric) and put it into the kernel to keep the entropy
> pool full failed.  This has happened in the past, that's why I have to
> patch, but the interface was never removed before.  If it has been
> removed, can you point me to the discussion that led to that decision.

How does the removal of the interface materialize itself?

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: socket path length

[Florian Weimer]

* Neil Horman:

> On Thu, Jan 02, 2020 at 02:35:22PM +0100, Florian Weimer wrote:
>> * Damian Ivanov:
>> 
>> > I could not find any information if having the socket length limited
>> > is still something that is required nowadays as it seems this is
>> > mostly for compatibility reasons?
>> 
>> I don't know why the kernel limits the socket length.  There is no
>> strict requirement to do so because the userspace interfaces all have
>> explicit lengths.  struct sockaddr_un has a fixed-size buffer, but
>> that could be worked around, similar to struct dirent.
>> 
> The kernel doesn't limit this length for any particular technical
> reason, it limits it as a matter of maintaining ABI compatibility.
> When the unix address family was written back in the 80's, they
> decided that the sun_path component was coded to a length of 108
> bytes, and so that is now part of the ABI, and can't be changed.
> Any systemcall expecting a strict 108 byte path may encounter what
> would appear to be an unterminated string, even if the only thing
> you did was lengthen the path name.

The kernel would return an error in this case.  It would be similar to
readlink with a buffer that is to small.  The situation is actually
far more benign than with struct dirent, where the kernel happily
returns data that does not fit in the d_name array.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: socket path length

[Florian Weimer]

* Damian Ivanov:

> I could not find any information if having the socket length limited
> is still something that is required nowadays as it seems this is
> mostly for compatibility reasons?

I don't know why the kernel limits the socket length.  There is no
strict requirement to do so because the userspace interfaces all have
explicit lengths.  struct sockaddr_un has a fixed-size buffer, but
that could be worked around, similar to struct dirent.

The internal kernel interfaces are built on top of struct
sockaddr_storage and do not pass explicit lengths, but those could be
changed.
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: [PATCH 2/9] Drop cpumask auto select patch

[Florian Weimer]

* Laura Abbott:

> On 8/16/19 6:58 AM, Josh Boyer wrote:
>> On Thu, Aug 15, 2019 at 3:57 PM Laura Abbott  wrote:
>>>
>>> We've been carrying a patch to make CPUMASK_OFFSTACK selectable
>>> without debugging for a long time now. The comment said this was
>>> going to be replaced with something else but that never seemed
>>> to happen. We're carrying it to have a higher number of CPUs but
>>> at this point I don't think it's worth it since the upper bound is
>>> now 512. This should be enough for most Fedora use cases so just
>>> drop the patch.
>>
>> I likely agree, but copying Prarit because this was something he and I
>> poked at forever ago.
>>
>
> Given that RHEL no longer bothers with this I hope he would be
> okay with it :)

RHEL has a larger NR_CPU value, though.  For example, it's 8192 on
x86-64, while Fedora 31 has 1024.

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

5.3.0-rc kernel-headers in rawhide and mass rebuild

[Florian Weimer]

Do you plan to leave in the -rc kernel headers for the mass rebuild?

We see some rather odd issues with it when building glibc, and have
trouble getting glibc ready for the mass rebuild.

Thanks,
Florian
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/kernel@lists.fedoraproject.org

Re: /proc/sys/net/core/optmem_max on armv7l

[Florian Weimer]

* Björn 'besser82' Esser:

> I just checked and found `unsigned long` to be 32 bits on %{arm},
> only.  All other arches (even %{ix86}) have it set to 64 bits.

Huh?  I'm not aware of *any* vaguely Linux-compatible 32-bit
architecture which has 64-bit longs (unsigned or signed).
___
kernel mailing list -- kernel@lists.fedoraproject.org
To unsubscribe send an email to kernel-le...@lists.fedoraproject.org