Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
* Adam Borowski wrote: > Here's some history: > The day of -rc1, multiple people immediately reported the breakage; it was > quickly found out that reverting 784d5699eddc fixes it. A "going forward" > patch has been posted but was insufficient; when the real devs went to bed > the last message was > https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1250370.html > which ends with instructions and "Care to do a patch for x86?". > > Then a random person (me) did the legwork, gathered affected symbols, wrote > and tested the x86 patch. It was then tested by multiple people; Arnd > Bergmann wrote the ARM equivalent. Whenever a new lkml thread reporting the > breakage popped up, we pointed people to the patches and everyone was happy. > As for upstreaming, there was a delay because Michal Marek was on vacation. > > Michal returned and sent you the pull request, you merged it as 04e36857 on > Nov 18. For some reason the per-arch pieces were excluded; I was instructed > to send my part to x86 maintainers. > > I did so; the patch later got a better description by Nick and a bunch of > Tested-by -- but alas, nary a comment or action from x86 guys, despite > pings/resends (last one: https://lkml.org/lkml/2016/11/23/706). I guess I'm > lacking the secret handshake or something -- thus, it looks like it's my > fault, the rest of you can be blamed mostly for letting a > not-a-real-kernel-dev unsupervised. My part of the story is easy to explain: the reason I skipped the 11/23 patch was because it was tagged 'kbuild' and because the commit that broke it was never acked by (or was upstreamed via) the x86 maintainers - we never upstreamed any modversions changes in the past AFAIR - so I assumed it would be handled via whatever path got the breakage upstream (turns out it was via the VFS tree?), or via the kbuild tree. > On Nov 24 finally Ingo responded, the discussion ended with you marking > modversions as BROKEN. Yeah, that was when my internal timer ran out: modversions breakage was reported against -rc1 already and it still wasn't working (a seemingly working kernel build resulted in an unbootable system) - due to the timeline and confusion you explained. I totally agree with marking it BROKEN: it was the simplest, most robust way to fix it and nobody seemed to be owning the modversions feature. Thanks, Ingo
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
* da...@lang.hm wrote: > On Wed, 18 Jul 2012, Ingo Molnar wrote: > > >* da...@lang.hm wrote: > > > >>>Anybody who says "I want to run Fedora without SELINUX > >>>because I do my own security development" is by *definition* > >>>not relevant to the whole feature. > >> > >>Don't mistake the example for the feature. the SELINUX thing > >>is just an example. As Alan Cox commented, taking a distro > >>config and disabling one thing is a common troubleshooting > >>request from kernel developers. > > > >It's still irrelevant: > > > >- if a user chooses a distro config it means that he is using > > that distro. Disabling an essential component of the distro > > config, even if a kernel developer asks for it, will likely > > break that distro and is thus a dumb thing to do. (the > > typical user will also be unlikely to be *able* to edit a > > .config and make sure it works.) > > that's assuming that everything listed really is essential. See the requirements in Linus's earlier mail: -> The *two* requirements (and they're really the same theme) I personally think we should have for this are - I think every single "select" for these things should come with a comment about what it is about and why the distro needs it (to show there was some thought involved and not just a blind "took it from the distro config") - It should be about *minimal* settings. I'd rather have too few things and the occasional complaint about "oh, it didn't work because it missed XYZ" than have it grow to contain all the options just because somebody decided to just add random things until things worked. <- Thanks, Ingo -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120718091313.ga13...@gmail.com
Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues
* da...@lang.hm wrote: > > Anybody who says "I want to run Fedora without SELINUX > > because I do my own security development" is by *definition* > > not relevant to the whole feature. > > Don't mistake the example for the feature. the SELINUX thing > is just an example. As Alan Cox commented, taking a distro > config and disabling one thing is a common troubleshooting > request from kernel developers. It's still irrelevant: - if a user chooses a distro config it means that he is using that distro. Disabling an essential component of the distro config, even if a kernel developer asks for it, will likely break that distro and is thus a dumb thing to do. (the typical user will also be unlikely to be *able* to edit a .config and make sure it works.) - Furthermore, there's *already* over ten thousand select's in our Kconfig's, and it's already hard at times to disable dependent options. - I've been using what Linus suggested for many years via private patches to do bootable randconfig testing and the concept works just fine - enabling a distro specific minconfig is absolutely useful, I'm glad it's being pursued upstream as well... So what you are arguing about is IMO irrelevant, it is immaterial to the problem at hand and the concept works just fine in practice. Thanks, Ingo -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120718070458.ga10...@gmail.com
Bug#603229: Scheduler grouping failure; division by zero in select_task_rq_fair
* Ben Hutchings wrote: > On Mon, Nov 29, 2010 at 12:50:25PM +0100, Peter Zijlstra wrote: > > On Sun, 2010-11-28 at 20:14 +, Ben Hutchings wrote: > > > > > [0.856002] Pid: 2, comm: kthreadd Not tainted 2.6.32-5-amd64 #1 > > > W1100z/2100z > > > > What's in that kernel? is that simply the latest .32-stable? > > No, we have quite a few backported driver features and some bug fixes > that aren't in stable yet. No scheduler or topology changes except > reverting 669c55e9f99b90e46eaa0f98a67ec53d46dc969a for ABI reasons > (which I guess we don't actually need to do). > > > > [0.536554] CPU0 attaching sched-domain: > > > [0.540004] domain 0: span 0-1 level MC > > > [0.548002] groups: 0 1 > > > [0.560003] domain 1: span 0-3 level NODE > > > [0.568002]groups: > > > [0.574179] ERROR: domain->cpu_power not set > > > [0.576002] > > > [0.580002] ERROR: groups don't span domain->span > > > [0.584004] CPU1 attaching sched-domain: > > > [0.588007] domain 0: span 0-1 level MC > > > [0.596002] groups: 1 0 (cpu_power = 1023) > > > [0.612002] ERROR: parent span is not a superset of domain->span > > > [0.616003] domain 1: span 1-3 level CPU > > > [0.624002]groups: 1 (cpu_power = 2048) 2-3 (cpu_power = 2048) > > > [0.644003]domain 2: span 0-3 level NODE > > > [0.652004] groups: 1-3 (cpu_power = 4096) > > > [0.668002] ERROR: domain->cpu_power not set > > > [0.672002] > > > [0.676002] ERROR: groups don't span domain->span > > > [0.680004] CPU2 attaching sched-domain: > > > [0.684003] domain 0: span 2-3 level MC > > > [0.692003] groups: 2 3 > > > [0.704003] domain 1: span 1-3 level CPU > > > [0.712003]groups: 2-3 (cpu_power = 2048) 1 (cpu_power = 2048) > > > [0.736003]domain 2: span 0-3 level NODE > > > [0.744003] groups: 1-3 (cpu_power = 4096) > > > [0.760003] ERROR: domain->cpu_power not set > > > [0.764003] > > > [0.768003] ERROR: groups don't span domain->span > > > [0.772004] CPU3 attaching sched-domain: > > > [0.776003] domain 0: span 2-3 level MC > > > [0.784003] groups: 3 2 > > > [0.794183] domain 1: span 1-3 level CPU > > > [0.83]groups: 2-3 (cpu_power = 2048) 1 (cpu_power = 2048) > > > [0.822183]domain 2: span 0-3 level NODE > > > [0.828003] groups: 1-3 (cpu_power = 4096) > > > [0.842180] ERROR: domain->cpu_power not set > > > [0.844003] > > > [0.848003] ERROR: groups don't span domain->span > > > > Hrm that smells like the architecture topology setup is wrecked, looks > > like the NUMA setup is bonkers. > [...] > > Right, that's what I thought. Question is whether the topology setup > code should fix this up or whether the schedular init should (as it > appears to have done before 2.6.32). We definitely want to robustify scheduler init code to not crash and to (if possible) print a warning about the borkage. Thanks, Ingo -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101129180605.gc14...@elte.hu
