Bug 58944

Summary: 2.4.9-21 makes major change to task_struct
Product: [Retired] Red Hat Linux Reporter: Alan Peckham <20010226redhat>
Component: kernelAssignee: Arjan van de Ven <arjanv>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-01-28 14:30:06 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alan Peckham 2002-01-28 14:16:12 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i686; en-US; 0.7) Gecko/20010316

Description of problem:
The addition of timer_ticks to the middle of task_struct forces
providers of binary loadable modules to re-evaluate each of your kernels and
re-spin their modules each time you put out a kernel. Was this your intention?
You could at least have added it to the end of the structure!

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.Look at sources
2.
3.
	

Actual Results:  Our dcedfs.o module built for 2.4.9-12 no longer works on a
kernel that was supposed to be a security update of your kernel.

Expected Results:  Kernel structures and interfaces for 2.4.9 should be
backwards compatible.

Additional info:

Comment 1 Arjan van de Ven 2002-01-28 14:30:01 UTC
This field was added to enable a modification to the scheduler which increases
performance under threaded applications by 20% or more.

> You could at least have added it to the end of the structure!

The task struct is ordered very carefully for the "hot path" accessed fields to
be in the first cacheline. Adding this field to the end of the structure would
have added an extra cacheline access to the hotpath -> not acceptible.



> Actual Results:  Our dcedfs.o module built for 2.4.9-12 no longer works on a
> kernel that was supposed to be a security update of your kernel.

I sincerely hope that you as binary only kernel module provider do not ask your
customers to use modules compiled for different kernel versions. 

> Expected Results:  Kernel structures and interfaces for 2.4.9 should be
> backwards compatible.

The INTERNAL kernel ABI is NOT a guaranteed interface, and there is no way for
Red Hat to even verify that it has not changed. This happens to be what Open
Source is about as well: you have the source so for internal changes it's
trivial to recompile. 

People who think they found a loophole in the GPL license of the kernel and ship
binary only modules have one pain: every new kernel needs a recompile. Comes
with the teratory...