2007-10-12 kernel 2.6.5 bug fix patch 44 ("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-44-april2004.tar.gz / MD5 ... accumulated patch, recommended (2007-10-12)

linux-2.6.5-s390-44-april2004-patches.tar.gz / MD5 ... per-problem-patches, recommended (2007-10-12)

These patches contain the following linux kernel bug fixes:

Description:
hypfs: Inode corruption due to missing locking.
Symptom:
Kernel panic.
Problem:
hypfs removes the whole hypfs directory tree and creates a new one, when a process triggers an update by writing to the "update" attribute. When removing and creating files, it is necessary to lock the inode of the parent directory where the files reside. Currently hypfs does not lock the parent inode, which can lead to inode corruption.
Solution:
Introduce correct locking and fix i_nlink reference counting for inodes, when creating directories.
Problem-ID:
37643
Description:
kernel: out of memory notifier.
Symptom:
Processes get terminated by the oom killer (out of memory killer).
Problem:
The balancing of memory by use of the cmm memory balloon should not cause the termination of processes while there are pages in the balloon.
Solution:
Add a notifer chain to the out of memory killer. If one of the registered callbacks could release some memory, do not kill the process but return and retry the allocation that forced the oom killer to run.
Note:
This patch is useful for Cooperative Memory Management (cmm) when the Linux guest is severely stressed.
Problem-ID:
29030
Description:
qdio/qeth: Make sure sent skbs are freed in time.
Symptom:
Re-boot hang during iptables shutdown.
Problem:
qdio/qeth does not always free up sent skbs in a finite amount of time (as documented in Documentation/networking/driver.txt)
Solution:
Always check for the completion of an skb sent, because freeing of sent skbs in qeth is triggered by such a final completion check.
Problem-ID:
30634
Description:
zfcp: Adapter fails after several hours chpid off/on.
Symptom:
zfcp adapters go into failed state and can not be recovered manually.
Problem:
zfcp error recovery is waiting for a successful return or timeout of an exchange config data. The timeout is not set up correctly. As a result the error recovery waits forever, when the exchange config data has been sent but the response could not be received because the adapter was disabled in this moment.
Solution:
Set up timer correctly (add missing add_timer call).
Problem-ID:
35232
Description:
zfcp: Avoid possible memory corruptions.
Symptom:
Adapter goes into failed state after SVC port bypass. Sometimes random parts of memory are overwritten.
Problem:
zfcp has to register and un-register devices in newer SCSI stacks. Registration of SCSI devices leads to SCSI commands. If these SCSI commands fail there is a deadlock, because the zfcp ERP that will try recovery already waits for the registration to return. The old workaround was to sometimes dismiss all zfcp requests. But the requests were still active in the adapter, the hardware wrote the responses back in now invalid memory, causing all kinds of strange errors.
Solution:
Do not dismiss the FSF requests while the queues are still active. The dismiss_all function can only be called safely while the queues are down.
Problem-ID:
35294
Description:
zfcp: I/O stall when performing FC cable pulls.
Symptom:
After performing 15s-off/120s-on cable pulls, all paths were marked as failed/faulty in multipath.
Problem:
Some adapter status flags have not been reset during adapter re-open.
Solution:
Correctly clear adapter flags during adapter re-open.
Problem-ID:
35237
Description:
zfcp: I/O stall after deleting zfcp device and path checker changes after re-enabling zfcp device.
Symptom:
Setting one zfcp device offline using chccwdev in a multipath environment and waiting will lead to I/O stall on all paths. After setting the zfcp device back online using chccwdev, the devices with I/O stall will have a different path checker.
Problem:
Devices corresponding to the deleted units are never freed. This has the effect that 'slave_destroy' is never called and zfcp still thinks that this unit is registered (ZFCP_STATUS_UNIT_REGISTERED is still set). Hence the ERP routine is not called correctly and the unit is not enabled properly.
Solution:
Do not delete rport and the sdev. Just set the host to block on 'offline'. Host online would then just remove the blocked status.
Problem-ID:
32746
Description:
zfcp: Locking for req_seq_no.
Symptom:
Kernel message "bug: Sequence number mismatch between driver (0x37768c) and adapter 0.0.b31a (0x3776c8). Restarting all operations on this adapter." zfcp triggers an adapter re-open in this case.
Problem:
req_seq_no is read without locking. There is a race condition when two threads read these counters at the same time and get the same id.
Solution:
Re-order the calls in zfcp_req_create: First call zfcp_fsf_req_sbal_get to get the queue lock, then read req_seq_no in zfcp_fsf_req_qtcb_init.
Problem-ID:
34405
Description:
zfcp: Units are reported as BOXED.
Symptom:
zfcp units are reported as BOXED, although I/O is running without problems.
Problem:
During adapter re-open the BOXED flag is not cleared. Although the unit was boxed before the re-open, this is no longer the case after the re-open.
Solution:
Clear the BOXED flags in zfcp on adapter re-open to correctly report the unit status.
Problem-ID:
35239
Description:
zfcp: Adapter in failed state after successful recovery.
Symptom:
After an FSF request times out the adapter is re-opened and recovers.
Problem:
Clearing of the ZFCP_STATUS_COMMON_ERP_FAILED flag missing.
Solution:
Clear the ZFCP_STATUS_COMMON_ERP_FAILED flag during re-open.
Problem-ID:
35244
Description:
zfcp: Fix incorrect usage of fsf_req_list_lock.
Symptom:
Kernel message "BUG: illegal lock usage!"
Problem:
Incorrect usage of fsf_req_list_lock.
Solution:
Fix incorrect usage of fsf_req_list_lock. It is used in tasklet context (IRQs on) as well as in IRQ context. Therefore use the spin_lock_irqsave variant to avoid deadlocks.
Problem-ID:
35282
Description:
zfcp: Incorrect usage of erp_lock might lead to deadlocks.
Symptom:
Possible deadlock in zfcp.
Problem:
write_lock() instead of write_lock_irq() is used in zfcp_erp_adapter_strategy_open_fsf_xconf and zfcp_erp_adapter_strategy_open_fsf_xport.
Solution:
Replace write_lock() with write_lock_irq() calls.
Problem-ID:
35248
Description:
zfcp: Might hang while registering devices with SCSI.
Symptom:
zfcp might hang while registering devices with the SCSI stack.
Problem:
A change in the SCSI stack requires low level drivers to register and un-register devices. For zfcp this leads to the situation where zfcp calls the SCSI stack, the SCSI stack tries to scan the new device and the scan SCSI command fails. This would require the zfcp ERP, but the ERP thread is already blocked in the register call.
Solution:
Keep the calls from the zfcp ERP to the SCSI, since that is the place where zfcp knows about device changes, but make sure that the calls do not block the zfcp ERP thread. In detail:
  1. Use a workqueue to avoid blocking of the scsi_add_device calls.
  2. When removing a unit make sure that no scsi_add_device call is pending.
Problem-ID:
35235

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)
+ linux-2.6.5-s390-29-april2004.diff (IBM)
+ linux-2.6.5-s390-30-april2004.diff (IBM)
+ linux-2.6.5-s390-31-april2004.diff (IBM)
+ linux-2.6.5-s390-32-april2004.diff (IBM)
+ linux-2.6.5-s390-33-april2004.diff (IBM)
+ linux-2.6.5-s390-34-april2004.diff (IBM)
+ linux-2.6.5-s390-35-april2004.diff (IBM)
+ linux-2.6.5-s390-36-april2004.diff (IBM)
+ linux-2.6.5-s390-37-april2004.diff (IBM)
+ linux-2.6.5-s390-38-april2004.diff (IBM)
+ linux-2.6.5-s390-39-april2004.diff (IBM)
+ linux-2.6.5-s390-40-april2004.diff (IBM)
+ linux-2.6.5-s390-41-april2004.diff (IBM)
+ linux-2.6.5-s390-42-april2004.diff (IBM)
+ linux-2.6.5-s390-43-april2004.diff (IBM)
+ linux-2.6.5-s390-44-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.