Bug 58944 - 2.4.9-21 makes major change to task_struct
2.4.9-21 makes major change to task_struct
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-01-28 09:16 EST by Alan Peckham
Modified: 2007-04-18 12:39 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-28 09:30:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alan Peckham 2002-01-28 09:16:12 EST
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 09:30:01 EST
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...

Note You need to log in before you can comment on or make changes to this bug.