2005-10-04 kernel 2.6.5 bug fix patch 28 ("April 2004")

If you download any software from this web site please be aware of the Warranty Disclaimer and Limitation of Liabilities.

linux-2.6.5-s390-28-april2004.tar.gz / MD5 ... accumulated patch, recommended (2005-10-04)

linux-2.6.5-s390-28-april2004-patches.tar.gz / MD5 ... per-problem-patches, recommended (2005-10-04)

These patches contain the following linux kernel bug fixes:

Description:
ctcmpc: Missing skb reference.
Symptom:
Slow leak of size-131072(DMA) buffers on system using ctcmpc channels.
Problem:
ctcmpc de-referenced a sweep skb when freeing but reference was not increased when allocated. Occurs more frequently when there are inactive mpc connections.
Solution:
Add skb reference when allocate sweep skb.
Problem-ID:
18161
Description:
kernel: pfault interrupt race.
Symptom:
Oops in __wake_up.
Problem:
There is a race in pfault_interrupt. That function gets called two times for each pfault notification. Once with a subcode of 0 (to indicate that a real page is not available) and once with a subcode of 0x80 (to indicate that the page is present again). Since the two external interrupts can be delivered on two different CPUs the order in which the two calls are made is unpredictable. To synchronize the two interrupts the pfault_wait entry in the thread structure is used. Now if the subcode 0x80 interrupt is delivered, first the pfault_wait variable is set to zero before the wake_up of the process is done. If the virtual CPU gets re-scheduled, the execution of the code can stop between clearing pfault_wait and waking up the process for an indefinite period of time. In the meantime the process which faulted on the missing host page can complete the subcode 0 interrupt and can run to completion. That will remove the task structure, but that is still needed for the wake up call.
Solution:
Add proper task structure reference counting. Increase the reference counter in the subcode 0 interrupt before setting pfault_wait to zero and return the reference after the wake_up call.
Problem-ID:
17661
Description:
kernel: spin lock re-try.
Symptom:
High diag 44 rate.
Problem:
The spinlock code issues a diag 44 after the first unsuccessful try to get a lock. Even for short lived locks the chances are good that a (virtual) CPU yields the CPU timeslice.
Solution:
Split spin lock and r/w lock implementation into a single try which is done inline and an out-of-line function that repeatedly tries to get the lock before doing the cpu_relax(). Add a system control to set the number of re-tries before a CPU is yielded. The default re-try count is 1000.
Problem-ID:
17469
Description:
SCSI device offlined although multipath is used.
Symptom:
Offlined SCSI device during long cable pulls. This should not happen when multipath is used because then requests should be re-submitted to alternate paths in case of path failures.
Problem:
Error recovery escalation during handling of timed out SCSI commands leads to offlined SCSI device.
Solution:
Notify zfcp on time out of a SCSI command and subsequently finish the command. Thus avoiding escalation during error handling of the timed out command in the SCSI stack. The introduced timed_out_handler in zfcp ensures that scsi_done is never called for the timed out SCSI command.
Problem-ID:
15666
Description:
zfcp: Kernel Oops during cable pull.
Symptom:
Adressing exception while walking through erp_action list.
Problem:
Race when accessing erp_action lists.
Solution:
Always use locking when changing erp_action lists and avoid escalation to ERP_ACTION_REOPEN_PORT_FORCED if erp_action is still in use for ERP_ACTION_REOPEN_PORT.
Problem-ID:
17782

Everybody should apply this patch.

To create the complete linux kernel sources, the following patches need to be applied in sequence:

linux-2.6.5.tar.gz (see www.kernel.org/pub/linux/kernel/v2.6)
+ linux-2.6.5-s390-base-april2004.diff (IBM)
+ linux-2.6.5-s390-01-april2004.diff (IBM)
+ xipfs612 (see linuxvm.org/patches/index.html)
+ xipfs622 (see linuxvm.org/patches/index.html)
+ linux-2.6.5-s390-02-april2004.diff (IBM)
+ linux-2.6.5-s390-03-april2004.diff (IBM)
+ single threaded workqueue patch (see marc.theaimsgroup.com/?l=bk-commits-head&m=108305028322900&q=raw)
+ linux-2.6.5-s390-04-april2004.diff (IBM)
+ linux-2.6.5-s390-05-april2004.diff (IBM)
+ linux-2.6.5-s390-06-april2004.diff (IBM)
+ linux-2.6.5-s390-07-april2004.diff (IBM)
+ linux-2.6.5-s390-08-april2004.diff (IBM)
+ linux-2.6.5-s390-09-april2004.diff (IBM)
+ linux-2.6.5-s390-10-april2004.diff (IBM)
+ linux-2.6.5-s390-11-april2004.diff (IBM)
+ linux-2.6.5-s390-12-april2004.diff (IBM)
+ linux-2.6.5-s390-13-april2004.diff (IBM)
+ linux-2.6.5-s390-14-april2004.diff (IBM)
+ linux-2.6.5-s390-15-april2004.diff (IBM)
+ linux-2.6.5-s390-16-april2004.diff (IBM)
+ linux-2.6.5-s390-17-april2004.diff (IBM)
+ linux-2.6.5-s390-18-april2004.diff (IBM)
+ linux-2.6.5-s390-19-april2004.diff (IBM)
+ linux-2.6.5-s390-20-april2004.diff (IBM)
+ linux-2.6.5-s390-21-april2004.diff (IBM)
+ linux-2.6.5-s390-22-april2004.diff (IBM)
+ linux-2.6.5-s390-23-april2004.diff (IBM)
+ linux-2.6.5-s390-24-april2004.diff (IBM)
+ linux-2.6.5-s390-25-april2004.diff (IBM)
+ linux-2.6.5-s390-26-april2004.diff (IBM)
+ linux-2.6.5-s390-27-april2004.diff (IBM)
+ linux-2.6.5-s390-28-april2004.diff (IBM)

Contact the IBM team

If you want to contact the Linux on System z IBM team refer to the Contact the Linux on System z IBM team page.