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
acceptable. So I thin
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 from C, it
would
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 be versioned.
> W
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 to try to convince
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.
And it's wrong too. The
On Tue, Nov 29, 2016 at 9:10 AM, Linus Torvalds
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 (with no issues), so it c
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 that we shouldn't even ca
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 issue, because with
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 lists symbols defined
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:
Honestly, I'd just like to
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 y
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, Ben Hutchings wrote:
>> On Sat, 2016-0
On Mon, Jul 28, 2014 at 11:09 AM, Markus Trippelsdorf
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
> -fvar-tracking-assignments coul
On Sun, Jul 27, 2014 at 8:47 PM, Michel Dänzer 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
On Mon, Jul 28, 2014 at 5:26 AM, Frank Ch. Eigler 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 having a buggy
On Sat, Jul 26, 2014 at 1:19 PM, Markus Trippelsdorf
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 builds. Something
> li
On Sat, Jul 26, 2014 at 12:56 PM, 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?
Hmm. The good news is that with that patch, the GCC_COMPARE_DEBUG
build succeeds. At least for
On Sat, Jul 26, 2014 at 12:35 PM, Markus Trippelsdorf
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 now.
So how is cod
On Sat, Jul 26, 2014 at 11:28 AM, Linus Torvalds
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. But
On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds
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 an
On Fri, Jul 25, 2014 at 11:29 AM, Linus Torvalds
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 goin
On Fri, Jul 25, 2014 at 7:02 AM, Steven Rostedt 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
> within the change
On Thu, Jul 24, 2014 at 6:25 PM, Michel Dänzer 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 debug line and cfi
On Thu, Jul 19, 2012 at 9:48 AM, Borislav Petkov 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.
Most of th
On Thu, Jul 19, 2012 at 8:26 AM, Steven Rostedt 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 it tends to handle
On Mon, Jul 16, 2012 at 12:26 PM, 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 unselect.
Th
On Mon, Jul 16, 2012 at 9:43 AM, 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.
Seriously. NOBODY
On Fri, Jul 13, 2012 at 2:17 PM, Casey Schaufler 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
experienting with config
On Fri, Jul 13, 2012 at 2:02 PM, Dave Jones 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 sch_htb fo
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
On Sun, Jan 8, 2012 at 6:56 PM, Ben Hutchings 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 rather just panic -
On Sun, Jan 8, 2012 at 5:06 PM, richard -rw- weinberger
wrote:
> On Mon, Jan 9, 2012 at 1:18 AM, Linus Torvalds
> wrote:
>> 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
>>
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 c
On Thu, 22 Apr 2010, Greg KH wrote:
>
> From: Alexey Starikovskiy
>
> 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 series somewhere, but I
34 matches
Mail list logo
