[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#582281: Partition starting sector and partition size calculated incorrectly for reserved CMS minidisk on FBA DASD with blocksize > 512 using DIAG driver (s390 architecture only)



Package: linux-source-2.6.32
Version: 2.6.32-12

I have discovered a bug in the Linux kernel.  The partition starting
sector and partition size are miscalculated under certain conditions.
These conditions are as follows:

(1) The Linux kernel is executing on the s390/s390x architecture
(2) The Linux kernel is executing in a virtual machine under z/VM
(3) The disk is FBA DASD
(4) The disk is CMS formatted (the only disk format supported on FBA DASD)
(5) The CMS logical block size is greater than 512
(6) the CMS RESERVE command has been issued to allocate all available space
    to a single CMS file
(7) The DIAG driver (as opposed to the FBA driver) is being used for that
    disk.

Under these conditions, the Linux kernel will treat the CMS RESERVEd minidisk
as a non-reserved minidisk.  Thus, once a file system or a swap space has
been built on the disk by the Linux kernel, the CMS metadata gets clobbered,
and the CMS minidisk can no longer be accessed by CMS.

The problem is in fs/partitions/ibm.c, function ibm_partition.  The algorithm
used to calculate the sector in which the volume label is stored is incorrect.
For FBA DASD, the volume label is always stored in the second physical 512-byte
block (block number one with the blocks numbered starting with zero).  This
is true regardless of the logical block size.  The FBA driver always uses
a logical block size of 512 internally, regardless of the CMS logical block size;
but the DIAG driver honors the CMS logical block size.  As a result, if the
CMS logical block size is greater than 512, the sector number of the disk
label is calculated incorrectly, and garbage is read in for the disk label.
For FBA DASD, one must always read sector number 1 to get the disk label,
regardless of the logical block size.

The following patch fixes the problem:

   http://www.wowway.com/~zlinuxman/kernel/ibm.c.diff

This patch used the source code for kernel 2.6.32 as a base, but it will
probably apply to multiple versions, since this routine doesn't get much
maintenance.

There is one down side to fixing this problem: data on existing partitions,
if they are affected by the miscalculation, may become unreadable.
Fortunately, there is a simple fix for this problem, and it can be applied
beforehand.  Set the disk_offset field of the volume label to zero.
This will cause the disk to be treated as a non-reserved CMS minidisk,
and the partition location and size will be calculated as before.  I
am working on a little utility to do this and will post it to my web site
when I am finished.

Please send this upstream.  Or, if you prefer, I can send it upstream myself.
Nevertheless, I wanted a Debian bug report created to serve as a problem
log.

-- 
  .''`.     Stephen Powell    
 : :'  :
 `. `'`
   `-



Reply to: