Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Sat, Dec 3, 2016 at 11:44 PM, Alan Modra wrote: > > As far as reverting the binutils commit goes, I'm quite willing to do > that if necessary I think we have the proper fix in the kernel now, witht he "mark weak asm symbols with value 0". Or if not "proper", then at least

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Fri, Dec 2, 2016 at 2:55 AM, Arnd Bergmann wrote: > > Yes, it's always been just the assembly symbols that broke, these were > the ones that Al's original patch changed and that ended up with > no version information. Ok, and the reason is because even if we have a weak symbol

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Thu, Dec 1, 2016 at 5:58 AM, Arnd Bergmann wrote: > > WARNING: EXPORT symbol "mcount" [arch/x86/entry/built-in.ko] version > generation failed, symbol will not be versioned. > WARNING: EXPORT symbol "mcount" [arch/x86/built-in.ko] version generation > failed, symbol will not

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Wed, Nov 30, 2016 at 10:18 AM, Nicholas Piggin wrote: > > Here's an initial rough hack at removing modversions. It gives an idea > of the complexity we're carrying for this feature (keeping in mind most > of the lines removed are generated parser). You definitely don't have

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Tue, Nov 29, 2016 at 11:57 AM, Ben Hutchings wrote: > > If the modversion is missing then the fallback should be to a full > vermagic match, i.e. including the release string. Something like > this (untested): This really seems way too complicated for this situation.

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds <torva...@linux-foundation.org> wrote: > > So quite frankly, I don't want to make our kernel sources worse due to > broken shit tools getting something wrong that we shouldn't even care > about. And yes, I'm on binutils 2.26 (w

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Tue, Nov 29, 2016 at 9:05 AM, Adam Borowski wrote: > > Thus, if it's indeed binutils, you'll see the breakage as soon as Fedora > recovers from the freeze. So quite frankly, I don't want to make our kernel sources worse due to broken shit tools getting something wrong

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Tue, Nov 29, 2016 at 8:03 AM, Michal Marek wrote: > > The original and easily observable bug is that were are not generating > symbol checksums for the asm-exported symbols, so they default to 0. > This can be seen e.g. in the Module.symvers file. This seemed like a > minor

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Nov 29, 2016 5:51 AM, "Adam Borowski" wrote: > > > > > (a) tested > > By many people. No. I've tested the build *without* this, and it works fine. > > (b) explains it > > The actual logic is in 4efca4ed0. It wants C prototypes defined in > asm/asm-prototypes.h that

Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm

On Mon, Nov 28, 2016 at 5:15 PM, Ben Hutchings wrote: >> >> The modversions stuff may just be too painful to bother with. Very few >> people probably use it, and the ones that do likely don't have any >> overriding reason why. > [...] > > Debian has some strong reasons:

Bug#815787: May be a kernel problem not a pulseaudio one?

On Feb 28, 2016 9:36 AM, "Cristian Ionescu-Idbohrn" < cristian.ionescu-idbo...@axis.com> wrote: > > > "Apparently there is some work under way to allow both ZONE_DEVICE > (needed for DAX) and ZONE_DMA (needed by the sound drivers) to be > supported in the same kernel configuration." Yeah, but do

Bug#815787: May be a kernel problem not a pulseaudio one?

On Sat, Feb 27, 2016 at 1:52 PM, Cristian Ionescu-Idbohrn wrote: > Background: https://bugs.debian.org/815787 > > "Until recently the Sound Blaster Live! card in my workstation worked > fine. Sometime recently it has stopped working." > > On Sat, 27 Feb 2016,

Re: Random panic in load_balance() with 3.16-rc

On Mon, Jul 28, 2014 at 5:26 AM, Frank Ch. Eigler f...@redhat.com wrote: Please note that the data produced by -g -fvar-tracking is consumed by tools like systemtap, perf, crash, and makes a significant difference to the observability of debug AND non-debug kernels. Yeah, and compared to

Re: Random panic in load_balance() with 3.16-rc

On Sun, Jul 27, 2014 at 8:47 PM, Michel Dänzer mic...@daenzer.net wrote: On 27.07.2014 04:56, Linus Torvalds wrote: Also, Michel - can you try this patch if you still have your gcc-4.9.0 install, and send me the resulting fair.s file again? Attached. The frame setup looks fine to me now

Re: Random panic in load_balance() with 3.16-rc

On Mon, Jul 28, 2014 at 11:09 AM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: It shouldn't be too hard to implement a simple check for the bug in the next release. Just compile the gcc/testsuite/gcc.target/i386/pr61801.c testcase with -fcompare-debug. If gcc returns 0 then

Re: Random panic in load_balance() with 3.16-rc

On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds torva...@linux-foundation.org wrote: I'm sure it's possible, but it sounds potentially complicated. Hmm. The bugzilla entry just taught me a new gcc flag: -fcompare-debug. That apparently makes gcc compile things twice, once with debugging

Re: Random panic in load_balance() with 3.16-rc

On Sat, Jul 26, 2014 at 11:28 AM, Linus Torvalds torva...@linux-foundation.org wrote: That's a bit worrisome. I haven't actually checked if the code generation differs in significant ways yet.. Nope. Just three instructions that got re-ordered from ABC to CAB in a way that makes no difference

Re: Random panic in load_balance() with 3.16-rc

On Sat, Jul 26, 2014 at 12:35 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: But fortunately the workaround for the new inode.c bug is the same as for the original bug: -fno-var-tracking-assignments. It would make sense to enabled it unconditionally for all debug configurations for

Re: Random panic in load_balance() with 3.16-rc

On Sat, Jul 26, 2014 at 12:56 PM, Linus Torvalds torva...@linux-foundation.org wrote: Also, Michel - can you try this patch if you still have your gcc-4.9.0 install, and send me the resulting fair.s file again? Hmm. The good news is that with that patch, the GCC_COMPARE_DEBUG build succeeds

Re: Random panic in load_balance() with 3.16-rc

On Sat, Jul 26, 2014 at 1:19 PM, Markus Trippelsdorf mar...@trippelsdorf.de wrote: Yes. The option only affects -g builds. Ok, good. I'll wait a bit to hopefully get confirmation from Michel's setup, but this does seem to be the solution. So, the option should only be enabled for debugging

Re: Random panic in load_balance() with 3.16-rc

On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt rost...@goodmis.org wrote: But wouldn't it be rather trivial to run a static analyzer on the final vmlinux to make sure there are no red zones? I mean, you would only need to read each function and check to make sure that the offset of rbp is

Re: Random panic in load_balance() with 3.16-rc

On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds torva...@linux-foundation.org wrote: Some simple pattern to make sure that the sub $frame-size,%rsp comes before any accesses to (%rbp) (when frame pointers are enabled) *might* work, but it might also end up missing things. You're going

Re: Random panic in load_balance() with 3.16-rc

On Thu, Jul 24, 2014 at 6:25 PM, Michel Dänzer mic...@daenzer.net wrote: Attached is fair.s from Debian gcc 4.8.3-5. Does that look better? I'm going to try reproducing the problem with a kernel built by that now. This looks better. For roughly that same code sequence it does (ignoring the

Re: [RFC] Simplifying kernel configuration for distro issues

On Thu, Jul 19, 2012 at 8:26 AM, Steven Rostedt rost...@goodmis.org wrote: Side note, and this is for the 1%. If you want a true minconfig for your system, ktest can do that for you. Try it, it's actually much harder than it seems. Like allmodconfig, it handles the minimum hardware well, but

Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov b...@amd64.org wrote: Seriously, this helps only in the cases where the stuff the distro actually needs is in modules. So, there probably are obscure situations where you need to enable stuff which is bool and not M. Sadly, not obscure at all.

Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

On Mon, Jul 16, 2012 at 9:43 AM, da...@lang.hm wrote: The problem is that you can't select the Fedora profile and then unselect SELINUX, so the profile will do you no good. Guys, stop it now. Your problem isn't what any sane person cares about, and isn't what I started the RFC for.

Re: [opensuse-kernel] Re: [RFC] Simplifying kernel configuration for distro issues

On Mon, Jul 16, 2012 at 12:26 PM, da...@lang.hm wrote: Some of the proposed ways to implement the minimum distro kernel would not allow you to override the distro defaults because they would be implemented by setting dependancies, not by selecting options that you as the user could then

[RFC] Simplifying kernel configuration for distro issues

So this has long been one of my pet configuration peeves: as a user I am perfectly happy answering the questions about what kinds of hardware I want the kernel to support (I kind of know that), but many of the support infrastructure questions are very opaque, and I have no idea which of the them

Re: [RFC] Simplifying kernel configuration for distro issues

On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones da...@redhat.com wrote: As long as you don't mind these being added after the fact, I suppose it would be workable. The reason I say that is sometimes, it even catches *us* by surprise. We recently found out our virtualisation guys started using

Re: [RFC] Simplifying kernel configuration for distro issues

On Fri, Jul 13, 2012 at 2:17 PM, Casey Schaufler ca...@schaufler-ca.com wrote: Oh dear. I would expect Fedora to say that they require SELinux, thereby making it unusable by anyone doing LSM development. Oh, *absolutely*. These options would *not* be meant for people doing odd things and

Re: [PATCH 1/2] topology: Check for missing CPU devices

On Sun, Jan 8, 2012 at 6:56 PM, Ben Hutchings b...@decadent.org.uk wrote: I mean to say that we could have no CPU devices after the *second* patch.  So the first patch is an extra defence against that.  (Though we could just as well panic if register_cpu() fails at boot time.) I think I'd

Re: [PATCH 1/2] topology: Check for missing CPU devices

Ok, both of the patches look sane to me, but it would really be nice to hear from somebody with the actual affected architectures, and get a tested-by. Testing it on hacked-up x86 sounds fine, but doesn't quite have the same kind of yes, this fixes the actual problem feel to it. Also, can you

Re: [PATCH 1/2] topology: Check for missing CPU devices

On Sun, Jan 8, 2012 at 5:06 PM, richard -rw- weinberger richard.weinber...@gmail.com wrote: On Mon, Jan 9, 2012 at 1:18 AM, Linus Torvalds torva...@linux-foundation.org wrote: Ok, both of the patches look sane to me, but it would really be nice to hear from somebody with the actual affected

Bug#563313: [165/197] ACPI: EC: Allow multibyte access to EC

On Thu, 22 Apr 2010, Greg KH wrote: From: Alexey Starikovskiy astarikovs...@suse.de commit dadf28a10c3eb29421837a2e413ab869ebd upstream Hmm. Doesn't this need commit 2060c44576c79086ff24718878d7edaa7384a985 to fix things up for crazy access_bit_width values? Maybe it's there in the