LOCALVERSION_AUTO considered harmful

LOCALVERSION_AUTO considered harmful

[Pavel Machek]

LOCALVERSION_AUTO has nasty interaction with modules, warn about it.

Signed-off-by: Pavel Machek <pavel@ucw.cz>

diff --git a/init/Kconfig b/init/Kconfig
index eb77e8c..5d33072 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -88,7 +88,6 @@ config LOCALVERSION
 
 config LOCALVERSION_AUTO
 	bool "Automatically append version information to the version string"
-	default y
 	help
 	  This will try to automatically determine if the current tree is a
 	  release tree by looking for git tags that belong to the current
@@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
 	  appended after any matching localversion* files, and after the value
 	  set in CONFIG_LOCALVERSION.
 
+	  Unfortunately, such finegrained versioning will mean that you will
+	  not be able to use modules for development; even "make modules"
+	  will change module versions, making recompiled modules impossible
+	  to insert into old kernel. 
+
 	  (The actual string used here is the first eight characters produced
 	  by running the command:
 

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: LOCALVERSION_AUTO considered harmful

[Geert Uytterhoeven]

On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
>> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>>         appended after any matching localversion* files, and after the value
>>         set in CONFIG_LOCALVERSION.
>>
>> +       Unfortunately, such finegrained versioning will mean that you will
>> +       not be able to use modules for development; even "make modules"
>> +       will change module versions, making recompiled modules impossible
>> +       to insert into old kernel.
>
> That's conditional BS.
> Turn off CONFIG_MODVERSIONS already.

Yeah, I disabled it ages ago. Even then (before git, probably even
before bitkeeper)
I had hard times inserting modules...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: LOCALVERSION_AUTO considered harmful

[Pavel Machek]

On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
> On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
> >> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
> >>         appended after any matching localversion* files, and after the value
> >>         set in CONFIG_LOCALVERSION.
> >>
> >> +       Unfortunately, such finegrained versioning will mean that you will
> >> +       not be able to use modules for development; even "make modules"
> >> +       will change module versions, making recompiled modules impossible
> >> +       to insert into old kernel.
> >
> > That's conditional BS.
> > Turn off CONFIG_MODVERSIONS already.
> 
> Yeah, I disabled it ages ago. Even then (before git, probably even
> before bitkeeper)
> I had hard times inserting modules...

I _had_ it off

 # CONFIG_MODVERSIONS is not set

It seems some checking survives CONFIG_MODVERSIONS unset and that
checking is strict enough to refuse module load after one "make
modules" with LOCALVERSION_AUTO on...
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: LOCALVERSION_AUTO considered harmful

[Thomas Gleixner]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1297 bytes --]

On Sun, 11 Apr 2010, Pavel Machek wrote:

> On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
> > On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <adobriyan@gmail.com> wrote:
> > > On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
> > >> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
> > >>         appended after any matching localversion* files, and after the value
> > >>         set in CONFIG_LOCALVERSION.
> > >>
> > >> +       Unfortunately, such finegrained versioning will mean that you will
> > >> +       not be able to use modules for development; even "make modules"
> > >> +       will change module versions, making recompiled modules impossible
> > >> +       to insert into old kernel.
> > >
> > > That's conditional BS.
> > > Turn off CONFIG_MODVERSIONS already.
> > 
> > Yeah, I disabled it ages ago. Even then (before git, probably even
> > before bitkeeper)
> > I had hard times inserting modules...
> 
> I _had_ it off
> 
>  # CONFIG_MODVERSIONS is not set
> 
> It seems some checking survives CONFIG_MODVERSIONS unset and that
> checking is strict enough to refuse module load after one "make
> modules" with LOCALVERSION_AUTO on...

So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
of killing LOCALVERSION_AUTO ? Brilliant.

Thanks,

	tglx

Re: LOCALVERSION_AUTO considered harmful

[rdunlap]

On Sun, April 11, 2010 3:24 pm, Thomas Gleixner wrote:
> On Sun, 11 Apr 2010, Pavel Machek wrote:
>
>
>> On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
>>
>>> On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <adobriyan@gmail.com>
>>> wrote:
>>>
>>>> On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
>>>>
>>>>> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>>>>>         appended after any matching localversion* files, and after
>>>>> the value         set in CONFIG_LOCALVERSION.
>>>>>
>>>>>
>>>>> +       Unfortunately, such finegrained versioning will mean that
>>>>> you will +       not be able to use modules for development; even
>>>>> "make modules"
>>>>> +       will change module versions, making recompiled modules
>>>>> impossible +       to insert into old kernel.
>>>>>
>>>>
>>>> That's conditional BS.
>>>> Turn off CONFIG_MODVERSIONS already.
>>>>
>>>
>>> Yeah, I disabled it ages ago. Even then (before git, probably even
>>> before bitkeeper) I had hard times inserting modules...
>>>
>>
>> I _had_ it off
>>
>>
>> # CONFIG_MODVERSIONS is not set
>>
>>
>> It seems some checking survives CONFIG_MODVERSIONS unset and that
>> checking is strict enough to refuse module load after one "make modules"
>> with LOCALVERSION_AUTO on...
>
> So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> of killing LOCALVERSION_AUTO ? Brilliant.

so it works for you?  how so, please?

> Thanks,

(saving bits)

~Randy

Re: LOCALVERSION_AUTO considered harmful

[rdunlap]

On Sun, April 11, 2010 3:24 pm, Thomas Gleixner wrote:
> On Sun, 11 Apr 2010, Pavel Machek wrote:
>
>
>> On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
>>
>>> On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <adobriyan@gmail.com>
>>> wrote:
>>>
>>>> On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
>>>>
>>>>> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>>>>>         appended after any matching localversion* files, and after
>>>>> the value         set in CONFIG_LOCALVERSION.
>>>>>
>>>>>
>>>>> +       Unfortunately, such finegrained versioning will mean that
>>>>> you will +       not be able to use modules for development; even
>>>>> "make modules"
>>>>> +       will change module versions, making recompiled modules
>>>>> impossible +       to insert into old kernel.
>>>>>
>>>>
>>>> That's conditional BS.
>>>> Turn off CONFIG_MODVERSIONS already.
>>>>
>>>
>>> Yeah, I disabled it ages ago. Even then (before git, probably even
>>> before bitkeeper) I had hard times inserting modules...
>>>
>>
>> I _had_ it off
>>
>>
>> # CONFIG_MODVERSIONS is not set
>>
>>
>> It seems some checking survives CONFIG_MODVERSIONS unset and that
>> checking is strict enough to refuse module load after one "make modules"
>> with LOCALVERSION_AUTO on...
>
> So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> of killing LOCALVERSION_AUTO ? Brilliant.

Pavel's original example (afaik) was on April 5:
Subject: 2.6.34-rc3: Can't insmod after make, because versions now differ?!

Apr  5 07:33:16 amd kernel: udlfb: version magic
'2.6.34-rc3-00345-ge8240f9-dirty SMP mod_unload CORE2 ' should be
'2.6.34-rc3-00344-g548fc0a-dirty SMP mod_unload CORE2 '


So what do you suggest?  If the "magic" strings contain "-dirty ",
then ignore that and the 2 preceding hyphen-separated fields?

That could be dangerous if some kernel internal structures have changed.
I.e., user/developer beware.

Maybe ignore those strings iff some override has been set somewhere?

---
~Randy

Re: LOCALVERSION_AUTO considered harmful

[Randy Dunlap]

On 04/11/10 19:56, rdunlap@xenotime.net wrote:
> On Sun, April 11, 2010 3:24 pm, Thomas Gleixner wrote:
>> On Sun, 11 Apr 2010, Pavel Machek wrote:
>>
>>
>>> On Sun 2010-04-11 20:58:58, Geert Uytterhoeven wrote:
>>>
>>>> On Mon, Apr 12, 2010 at 20:51, Alexey Dobriyan <adobriyan@gmail.com>
>>>> wrote:
>>>>
>>>>> On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
>>>>>
>>>>>> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>>>>>>         appended after any matching localversion* files, and after
>>>>>> the value         set in CONFIG_LOCALVERSION.
>>>>>>
>>>>>>
>>>>>> +       Unfortunately, such finegrained versioning will mean that
>>>>>> you will +       not be able to use modules for development; even
>>>>>> "make modules"
>>>>>> +       will change module versions, making recompiled modules
>>>>>> impossible +       to insert into old kernel.
>>>>>>
>>>>>
>>>>> That's conditional BS.
>>>>> Turn off CONFIG_MODVERSIONS already.
>>>>>
>>>>
>>>> Yeah, I disabled it ages ago. Even then (before git, probably even
>>>> before bitkeeper) I had hard times inserting modules...
>>>>
>>>
>>> I _had_ it off
>>>
>>>
>>> # CONFIG_MODVERSIONS is not set
>>>
>>>
>>> It seems some checking survives CONFIG_MODVERSIONS unset and that
>>> checking is strict enough to refuse module load after one "make modules"
>>> with LOCALVERSION_AUTO on...
>>
>> So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
>> of killing LOCALVERSION_AUTO ? Brilliant.
> 
> Pavel's original example (afaik) was on April 5:
> Subject: 2.6.34-rc3: Can't insmod after make, because versions now differ?!
> 
> Apr  5 07:33:16 amd kernel: udlfb: version magic
> '2.6.34-rc3-00345-ge8240f9-dirty SMP mod_unload CORE2 ' should be
> '2.6.34-rc3-00344-g548fc0a-dirty SMP mod_unload CORE2 '
> 
> 
> So what do you suggest?  If the "magic" strings contain "-dirty ",
> then ignore that and the 2 preceding hyphen-separated fields?
> 
> That could be dangerous if some kernel internal structures have changed.
> I.e., user/developer beware.
> 
> Maybe ignore those strings iff some override has been set somewhere?

Pavel, does "modprobe --force" work?

-- 
~Randy

Re: LOCALVERSION_AUTO considered harmful

[Theodore Tso]

On Apr 11, 2010, at 10:56 PM, rdunlap@xenotime.net wrote:
> 
> So what do you suggest?  If the "magic" strings contain "-dirty ",
> then ignore that and the 2 preceding hyphen-separated fields?

I have a standard local patch that I've been carrying for I-don't-know-how-long which just nukes the "-dirty" suffix, which I needed because make-kpkg modifies some kernel build files, so the version string would always have 
-dirty.

It's not hard to fix...

-- Ted

Re: LOCALVERSION_AUTO considered harmful

[Pavel Machek]

Hi!

> > > > That's conditional BS.
> > > > Turn off CONFIG_MODVERSIONS already.
> > > 
> > > Yeah, I disabled it ages ago. Even then (before git, probably even
> > > before bitkeeper)
> > > I had hard times inserting modules...
> > 
> > I _had_ it off
> > 
> >  # CONFIG_MODVERSIONS is not set
> > 
> > It seems some checking survives CONFIG_MODVERSIONS unset and that
> > checking is strict enough to refuse module load after one "make
> > modules" with LOCALVERSION_AUTO on...
> 
> So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> of killing LOCALVERSION_AUTO ? Brilliant.

In previous discussion, I was told that there's no bug to fix, that
everything works as intended.

I believe current behaiour is stupid, and I'd prefer *some* fix.

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: LOCALVERSION_AUTO considered harmful

[Linus Torvalds]

On Mon, 12 Apr 2010, Pavel Machek wrote:

> Hi!
> 
> > > > > That's conditional BS.
> > > > > Turn off CONFIG_MODVERSIONS already.
> > > > 
> > > > Yeah, I disabled it ages ago. Even then (before git, probably even
> > > > before bitkeeper)
> > > > I had hard times inserting modules...
> > > 
> > > I _had_ it off
> > > 
> > >  # CONFIG_MODVERSIONS is not set
> > > 
> > > It seems some checking survives CONFIG_MODVERSIONS unset and that
> > > checking is strict enough to refuse module load after one "make
> > > modules" with LOCALVERSION_AUTO on...
> > 
> > So instead of fixing the CONFIG_MODVERSIONS=n case you go the easy way
> > of killing LOCALVERSION_AUTO ? Brilliant.
> 
> In previous discussion, I was told that there's no bug to fix, that
> everything works as intended.

The problem is that you guys are looking at CONFIG_MODVERSIONS the wrong 
way around.

It's the _off_ case that is broken. Always was, always will be.

If CONFIG_MODVERSIONS is off, we remove the symbol versioning, and replace 
it with the _insane_ kernel version check. That is never valid. The fact 
that the kernel version is the same doesn't mean that the module will 
work, since we often do lots of changes within the same version.

So the solution is to say CONFIG_MODVERSIONS=y, and everybody is happy. 
Your modules will actually test things that _matter_, and will stop 
loading if the data types or function prototypes have changed. 

		Linus

Re: LOCALVERSION_AUTO considered harmful

[Alexey Dobriyan]

On Sun, Apr 11, 2010 at 06:47:01PM +0200, Pavel Machek wrote:
> @@ -99,6 +98,11 @@ config LOCALVERSION_AUTO
>  	  appended after any matching localversion* files, and after the value
>  	  set in CONFIG_LOCALVERSION.
>  
> +	  Unfortunately, such finegrained versioning will mean that you will
> +	  not be able to use modules for development; even "make modules"
> +	  will change module versions, making recompiled modules impossible
> +	  to insert into old kernel. 

That's conditional BS.
Turn off CONFIG_MODVERSIONS already.