kernel August 2019

kernel@lists.fedoraproject.org

17 participants
19 discussions

[PATCH 0/9] Clean up some old patches post F31
by Laura Abbott 04 Nov '19

04 Nov '19

I'd like to drop a bunch of patches Fedora has been carrying since forever. Most of these are fairly minor tweaks most people forgot we had and nobody cares about. My motivation is both in the spirit of cleaning up and also to better align Fedora + RHEL (I had a talk about this at Flock, video should be up soon). If someone wants to make an effort at upstreaming any of these, feel free to do so but I really think most of these are cruft. Thanks, Laura Laura Abbott (9): Drop namespaces config tweak Drop cpumask auto select patch Drop scsi warning patch Remove ancient ath9k workaround Drop old lis3 patch Remove some old modalias adjustments Remove old keyboard logging patch Remove patch for GCC VTA Remove crash driver Kbuild-Add-an-option-to-enable-GCC-VTA.patch | 94 --- ath9k-rx-dma-stop-check.patch | 38 - .../fedora/generic/x86/x86_64/CONFIG_NR_CPUS | 2 +- crash-driver.patch | 722 ------------------ die-floppy-die.patch | 29 - input-kill-stupid-messages.patch | 30 - kernel.spec | 20 - ...-CPUMASK_OFFSTACK-usable-without-deb.patch | 34 - lis3-improve-handling-of-null-rate.patch | 75 -- namespaces-no-expert.patch | 27 - no-pcspkr-modalias.patch | 22 - ...validate_disk-prevent-NULL-ptr-deref.patch | 39 - 12 files changed, 1 insertion(+), 1131 deletions(-) delete mode 100644 Kbuild-Add-an-option-to-enable-GCC-VTA.patch delete mode 100644 ath9k-rx-dma-stop-check.patch delete mode 100644 crash-driver.patch delete mode 100644 die-floppy-die.patch delete mode 100644 input-kill-stupid-messages.patch delete mode 100644 lib-cpumask-Make-CPUMASK_OFFSTACK-usable-without-deb.patch delete mode 100644 lis3-improve-handling-of-null-rate.patch delete mode 100644 namespaces-no-expert.patch delete mode 100644 no-pcspkr-modalias.patch delete mode 100644 scsi-sd_revalidate_disk-prevent-NULL-ptr-deref.patch -- 2.21.0

8 26

Support buildid in kernel-headers
by Paul Moore 06 Oct '19

06 Oct '19

Hello, Last year there was a change to how the kernel-headers package is built, and unfortunately that change made it so that changes to the kernel's buildid variable do not carryover to the the kernel-header's build. While I recognize that this is problem that only affects a small number of people, it would be nice to see this fixed. I'm attaching a small patch which fixes this for my use case, and while I think it is a generic solution, I can't say I've spent enough time looking at it to say for certain. I'm putting it out here as a way to help describe the problem as well as one possible solution. If you have a different/better approach that's fine with me, I just want to see the buildid reflected in the kernel-header package build so I can drop this patch from my build process :) -- paul moore www.paul-moore.com

3 6

Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy 28 Aug '19

28 Aug '19

On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson <adamwill(a)fedoraproject.org> wrote: > So, there was recently a Thing where btrfs installs were broken, and > this got accepted as a release blocker: > > https://bugzilla.redhat.com/show_bug.cgi?id=1733388 Summary: This bug was introduced and discovered in linux-next, it started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug resulted in a somewhat transient deadlock which caused installs to hang, but no corruption. The fix, 2 files changed, 12 insertions, 8 deletions (1/2 the insertions are comments). How remarkable or interesting is this bug? And in particular, exactly how much faster should it have been fixed in order to avoid worrying about it being a blocker bug? 7/25 14:27 utc bug patch was submitted to linux-btrfs@ 7/25 22:33 utc bug was first reported in Fedora bugzilla 7/26 19:20 utc I confirmed upstream's patch related to this bug with upstream and updated the Fedora bug 7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora bug So in the context of status quo, where Btrfs is presented as an option in the installer and if there are bugs they Beta blocking, how could or should this have been fixed sooner? What about the handling should have been different? I note here that ext2 and ext3 are offered as file systems in Custom/Advanced partitioning and in this sense have parity with Btrfs. If this same bug occurred in ext2 or ext3 would or should that cause discussion to drop them from the installer, even if the bug were fixed within 24 hours of discovery and patch? What about vfat? That's literally the only truly required filesystem that must work, for the most commonly supported hardware so it can't be dropped, we'd just be stuck until it got fixed. That work would have to be done upstream, yes? -- Chris Murphy

6 10

Re: Discussion: what would not blocking on btrfs look like?
by Neal Gompa 28 Aug '19

28 Aug '19

On Tue, Aug 27, 2019 at 1:30 PM Laura Abbott <labbott(a)fedoraproject.org> wrote: > > > > I also think there are other perspectives that might at least > > potentially be useful here. Right now we've mainly heard from a couple > > of community folks who are very passionate about btrfs, and Red Hat > > folks from anaconda/kernel development and RHEL management who > > essentially see it as a burden that is not aligned with their > > priorities. Is that all the perspectives we have to make a decision > > with? I think we should at least talk to the Facebook team that > > apparently uses btrfs on Fedora extensively about whether they'd be sad > > to see installer btrfs support die and, if so, whether they'd perhaps > > be interested in helping support it. And more broadly, community folks > > on all the lists this is going to: are there more people who actually > > are interested in this functionality and would be sad to see it go? If > > btrfs isn't a part of Red Hat's product roadmaps but is important to > > lots of folks in the wider Fedora community, maybe that's another > > indicator we can use....or indeed, if it turns out not many folks > > actually care. > > As an on the record btrfs skeptic, I think it would help to have an end-to-end picture of what's missing or needs to be added across all packages. If someone comes to me today and says "I want to help btrfs be successful in Fedora", I'd like to know where to point them besides just suggesting they get added on the btrfs kernel alias. Forgive me, but I had missed this in the sea of other messages (this thread is long and crazy now!). The Fedora Btrfs folks over the past few years have implemented the following: * Developed a DNF plugin to invoke snapper correctly for full system snapshots * Ported over the change set from SUSE to the Fedora grub2 package to support btrfs boot to snapshot * Fixed grubby to handle snapshot menu items for grub (this is kind of deprecated with BLS, though) The things that I'm looking to do: * Develop a libdnf plugin to replace the existing DNF snapper plugin (so that PackageKit is also covered) * Adapt the boot to snapshot stuff to use BLS (with boom, presumably?) The things I've been pushing off (for obvious reasons): * Enable Anaconda to allow /boot to be a btrfs subvolume (PR is in limbo...) * Ensure Anaconda configures snapper automatically when btrfs rootfs is selected * Design a sensible default btrfs layout (perhaps based on the current openSUSE one?) The mid-/long-term things I'm thinking of: * Consideration of moving the rpmdb to /usr/lib/sysimage/rpm (unifying standard Fedora and OSTree Fedora...) * A libdnf plugin to implement atomic package management using btrfs snapshots (like transactional-update, except done properly...) That's basically the full scope of the Btrfs enablement work I've planned right now. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy 27 Aug '19

27 Aug '19

On Tue, Aug 27, 2019 at 1:02 PM David Cantrell <dcantrell(a)redhat.com> wrote: > > On 8/27/19 2:00 PM, Chris Murphy wrote: > > The Fedora working group's technical specification states Btrfs is to > > be the default. Yet the working group has said it's uncomfortable > > taking action on this decision expressly because the Federal kernel > > team's official recommendation is to not recommend Btrfs. And I agree. > > I trust the Fedora kernel team as they've clearly stated limited > > resources and interest in Btrfs, the expectations and parameters for > > properly supporting Btrfs either as bug blocker worthy, and as a > > default file system from a user advocacy point of view. > > OK, so 8 years has gone by and the landscape around btrfs looks > different in Fedora. Given the kernel team's position, is it worth > still having the FESCo decision and kernel team's recommendation at odds? They aren't at odds. 8 years ago FESCo decision on Btrfs 5 years ago Workstation working group decision on Btrfs (their requirements and specs docs were signed off by FESCo) 3 years ago kernel team said while they don't recommend it, they acknowledged it was ultimately up to the working group to decide, and noted they were sick of having this conversation every release The Workstation working group has, correctly in my view, put their own decision in abeyance, as a result of the kernel team's official recommendation. How does the Btrfs landscape in Fedora look different to you in three years? The way the landscape looks different to me: One, the possibility of getting a kernel engineer who works on Btrfs to join the Fedora kernel team, so that the team has the capacity to support and recommend (at least as a team, not that any individual needs to give up one tiny bit of their Btrfs scepticism) is an important development. Two, that in the interim, Red Hat is where the landscape has really changed has occurred with respect to Btrfs, and I see indications of this bias being injected back into Fedora: suggesting that a Red Hat shift away from Btrfs somehow is actually a Fedora shift away from Btrfs, suggesting a do over vote in the Workstation working group, or even an undo vote by FESCo to set aside the Workstation working group vote. And to what end? All that's needed is for the Anaconda team to provided the same courtesy of clear expectations and parameters, as the kernel team has done. > > >> If it's a best effort thing, then that makes it easier for > >> projects and contributors. Going back to Adam's original list, I would > >> suggest a FESCo decision like this should require explicit opt-in by the > >> user to enable btrfs functionality in the application in question. For > >> example, in the installer that could be enabled via a boot parameter (we > >> did this initially when btrfs functionality was first enabled in anaconda). > > > > That can only be considered to be a remarkable regression, not just in > > the context of Fedora, but in the context of the top 10 linux > > distributions all of which have visible Btrfs support in their GUI > > installers. Fedora's installer being the first to make Btrfs invisible > > by default would be a remarkable first indeed. > > I'm merely offering an example scenario. > > This does illustrate a problem with expectations among users. It's > visible now, but not a priority, which leads to frustration. Just like today's kernel team, Anaconda today are not obligated to make it a priority. But qualifying what "not a priority" actually means is necessary. The question is what are the preconditions for others who will make it a priority? And whether Anaconda is going to slow walk every PR that tries to improve Btrfs support? What about simplifying the Btrfs support in Anaconda to make it easier to maintain with priority parity with other file systems? Gut all the multiple device stuff, perhaps? Btrfs can easily do quite a lot of adjustments post-install, it's one of it's most central features. Few options are mkfs only. > >> I'm not advocating one way or another for btrfs. But it seems we as a > >> project need a larger decision and policy around btrfs in general so we > >> can set expectations for users and developers. > > > > That decision and policy has already been made. Do you want it reverted? > > I guess I meant to say "FESCo needs to revisit this decision for a > potential change". I can't parse this. Which decision, and what potential change? -- Chris Murphy

1 0

Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy 27 Aug '19

27 Aug '19

On Tue, Aug 27, 2019 at 11:25 AM David Cantrell <dcantrell(a)redhat.com> wrote: > > The installer team rejecting btrfs patches is going to be based on their > resources to support the functionality. I would say "btrfs in Fedora" > needs a FESCo decision to set expectations and policy for the project. > Is it something that Fedora wants to offer and if so, what does that > look like? FESCo already voted 8 years ago to make Btrfs the default file system, and then allowed that to wither and become moot rather than revert the decision. Then later when the editions were created, part of Fedora.next, the decision of default file systems was handed to the working groups to decide. And the Fedora kernel team has also said this is a working group decision. The Fedora working group's technical specification states Btrfs is to be the default. Yet the working group has said it's uncomfortable taking action on this decision expressly because the Federal kernel team's official recommendation is to not recommend Btrfs. And I agree. I trust the Fedora kernel team as they've clearly stated limited resources and interest in Btrfs, the expectations and parameters for properly supporting Btrfs either as bug blocker worthy, and as a default file system from a user advocacy point of view. > If it's a best effort thing, then that makes it easier for > projects and contributors. Going back to Adam's original list, I would > suggest a FESCo decision like this should require explicit opt-in by the > user to enable btrfs functionality in the application in question. For > example, in the installer that could be enabled via a boot parameter (we > did this initially when btrfs functionality was first enabled in anaconda). That can only be considered to be a remarkable regression, not just in the context of Fedora, but in the context of the top 10 linux distributions all of which have visible Btrfs support in their GUI installers. Fedora's installer being the first to make Btrfs invisible by default would be a remarkable first indeed. > I'm not advocating one way or another for btrfs. But it seems we as a > project need a larger decision and policy around btrfs in general so we > can set expectations for users and developers. That decision and policy has already been made. Do you want it reverted? -- Chris Murphy

1 2

Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy 27 Aug '19

27 Aug '19

On Tue, Aug 27, 2019 at 7:49 AM Samantha Bueno <sbueno(a)redhat.com> wrote: > > On Fri, Aug 23, 2019 at 9:17 PM Adam Williamson > <adamwill(a)fedoraproject.org> wrote: > > So...what should we do? Here are the options as I see 'em: > > > > 1. Keep supporting btrfs > > 2. Just modify the criterion with a btrfs exception, even if it's weird > > 3. Rewrite the criterion entirely > > 4. Keep btrfs support in the installer (and blivet-gui) but hide it as > > we used to - require a special boot argument for it to be visible > > 5. Drop btrfs support from the installer > This thread has diverged wildly into a lot of delightful > invective-slinging at my team. In the interest of getting back to the > original topic at hand: I would be in support of three -- five. This clearly means Btrfs related bugs in Fedora's Anaconda will not block release, and by extension Btrfs could not be the default file system either. "Btrfs is not a priority" does not at all answer the central question of what level of support and resources are expected to exist in the Fedora community to maintain Btrfs in both the bug blocking, and default file system contexts. I think Laura Abbott's emails on the kernel side are quite clear ground rules for serious Btrfs bugs to remain blocker worthy, along with a path to discuss any additional expectations for Btrfs to be a default file system in some capacity. Unqualified statements like "it is safe to say btrfs will not be the default" and "Btrfs is not a priority" and this 'zero chance Btrfs' comment [1] are completely compatible with assuming that no matter how much work is done by others, those things will not appear in Anaconda because the decision has been made, it is a fait accompli. It is very important to have clarity exactly to what degree Btrfs is not a priority. If the Anaconda team cannot state the terms and expectations for the #1 option in Adam's list, that's troubling. Again, I think it's completely fine if Red Hat Anaconda folks are disinterested in Btrfs, but it's a very different thing if there's resistance to it, and I'm getting a lot of language that is compatible with resisting Btrfs no matter what. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1717728#c10 -- Chris Murphy

1 0

Simple Firmware Interface being deprecated
by Laura Abbott 27 Aug '19

27 Aug '19

https://lore.kernel.org/lkml/20190826181956.6918-1-lukas.bulwahn@gmail.com/ menuconfig SFI bool "SFI (Simple Firmware Interface) Support" ---help--- The Simple Firmware Interface (SFI) provides a lightweight method for platform firmware to pass information to the operating system via static tables in memory. Kernel SFI support is required to boot on SFI-only platforms. Currently, all SFI-only platforms are based on the 2nd generation Intel Atom processor platform, code-named Moorestown. For more information, see http://simplefirmware.org Say 'Y' here to enable the kernel to boot on SFI-only platforms. I have no idea how common this is but Fedora does enable this option. If you are interested in salvaging this, please speak up! Thanks, Laura

3 3

Re: Discussion: what would not blocking on btrfs look like?
by Neal Gompa 27 Aug '19

27 Aug '19

On Tue, Aug 27, 2019 at 5:55 AM <jkonecny(a)redhat.com> wrote: > > On Mon, 2019-08-26 at 23:54 -0400, Neal Gompa wrote: > > On Mon, Aug 26, 2019 at 7:16 AM <jkonecny(a)redhat.com> wrote: > > > > > > I understand them. The point is, for them and even us (the > > > installer) > > > is work on BTRFS not a priority. It's something we can't benefit on > > > RHEL and it could be almost completely replaced by LVM + xfs > > > solution. > > > However, it still giving us bugs and making our test surface > > > bigger. > > > > > > > From the Anaconda team PoV it would make our lives easier to not > > > support BTRFS at all. I'm not saying that we should drop BTRFS in > > > Fedora, only that it would be easier for Anaconda team to be > > > without > > > that on Fedora. > > > > This is flat-out a trap. This is what makes Anaconda such a failure > > as > > a community project. Why does the past (RHEL) affect the present and > > future (Fedora)? There's basically no way whatsoever to make anything > > better with this logic. The Anaconda releases that any improvements > > would be going into aren't even landing into the RHEL 8 branch that > > governs the latest iteration of Fedora's past. From any reasonable > > person's perspective, this answer makes no sense unless you're using > > RHEL as an excuse to not support Fedora. > > > > RHEL is not the past. Everything we do we have to think that it will go > to RHEL and if it is Fedora specific we have to create a way to disable > the functionality for another RHEL branching. And yes, we have a few > things (not only a BTRFS) specific to Fedora the same way as a few > things specific to RHEL which are disabled on Fedora. > > And as I wrote before, I'm not saying that we will remove the BTRFS > support from Fedora. The point is that making the list specific to > releases smaller will make our live easier. > By definition, RHEL *is* the past from a Fedora context. It's forked from an old version of Fedora that's not supported anymore. It is the result of decisions that aren't supposed to apply to Fedora. And it is the result of a different bias that should never apply to Fedora if the RH ecosystem is supposed to be able to evolve. From the way you describe it, Fedora is just something occasionally give lip service to while your main focus is RHEL. That's fine, but that is a problem for the Fedora context. -- 真実はいつも一つ！/ Always, there's only one truth!

2 6

Re: Discussion: what would not blocking on btrfs look like?
by Chris Murphy 27 Aug '19

27 Aug '19

On Mon, Aug 26, 2019 at 5:16 AM <jkonecny(a)redhat.com> wrote: > I understand them. The point is, for them and even us (the installer) > is work on BTRFS not a priority. It's something we can't benefit on > RHEL and it could be almost completely replaced by LVM + xfs solution. > However, it still giving us bugs and making our test surface bigger. > > >From the Anaconda team PoV it would make our lives easier to not > support BTRFS at all. I'm not saying that we should drop BTRFS in > Fedora, only that it would be easier for Anaconda team to be without > that on Fedora. It would also be easier if Custom and Advanced partitioning UIs were dropped entirely. Most Linux distros now support Btrfs. All the top 10 do. One, currently ranked #7 Solus, supports it via a point and shoot installer, deferring to Gparted to actually set it up. All the others have a custom interface that supports Btrfs directly. Meanwhile, #23 Parrot uses Btrfs by default for home and root. And so does openSUSE for a while now. And the idea being floated, is that Fedora shouldn't have a sense of adventure, but to maybe drop Btrfs from the installer. Fedora would be the first, if it did. It is completely reasonable for Red Hat to have maintainability concerns about Btrfs for RHEL, and it's entirely fair for Red Hat to have a bias against it. If it were true that Red Hat is, however unintentionally, injecting its Btrfs bias into Fedora, that would be troubling. -- Chris Murphy

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel August 2019