[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFwXqv6uYmW0kC=c+yyumO_T0CJrz6m+MQCQX6bR5gRBQw@mail.gmail.com>
Date: Fri, 25 Nov 2016 10:00:46 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Nicholas Piggin <npiggin@...il.com>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Ingo Molnar <mingo@...nel.org>,
Al Viro <viro@...iv.linux.org.uk>,
Adam Borowski <kilobyte@...band.pl>,
Michal Marek <mmarek@...e.com>,
Philip Muller <philm@...jaro.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
linux-arch <linux-arch@...r.kernel.org>,
linux-kbuild <linux-kbuild@...r.kernel.org>
Subject: Re: [PATCH] x86/kbuild: enable modversions for symbols exported from asm
On Thu, Nov 24, 2016 at 4:40 PM, Nicholas Piggin <npiggin@...il.com> wrote:
>>
>> Yes, manual "marking" is never going to be a viable solution.
>
> I guess it really depends on how exactly you want to use it. For distros
> that do stable ABI but rarely may have to break something for security
> reasons, it should work and give exact control.
No. Because nobody else will care, so unless it's like a single symbol
or something, it will just be a maintenance nightmare.
> What else do people *actually* use it for? Preventing mismatched modules
> when .git version is not attached and release version of the kernel has
> not been bumped. Is that it?
It used to be very useful for avoiding loading stale modules and then
wasting days on debugging something that wasn't the case when you had
forgotten to do "make modules_install". Change some subtle internal
ABI issue (add/remove a parameter, whatever) and it would really help.
These days, for me, LOCALVERSION_AUTO and module signing are what I
personally tend to use.
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.
So I'd personally be ok with just saying "let's disable it for now",
and see if anybody even notices and cares, and then has a good enough
explanation of why. It's entirely possible that most users are "I
enabled it ten years ago, I didn't even realize it was still in my
defconfig".
Linus
Powered by blists - more mailing lists