| Message ID | 20180815220731.29176-1-mfo@canonical.com |
|---|---|
| Headers | show |
| Series | Fixes for partition scan of corrupted AIX disk | expand |
On 08/16/18 00:07, Mauricio Faria de Oliveira wrote: > BugLink: https://bugs.launchpad.net/bugs/1787281 > > [Impact] > > * Users with disks/LUNs used for AIX operating system installations > previously, which possibly undergone overwrites/corruption on the > partition table, might hit kernel failures during partition scan > of such disk/LUN, and possibly hang the system (seen with retries). > > * The Linux kernel should be robust to corrupted disk data, performing > a better sanitization/checks and not failing. > > * The fix are a couple of simple logic changes to make the code > of the AIX partition table parser more robust. > > [Test Case] > > * Run the partition scan on the (trimmed) disk image of the AIX lun. > (It's not provided here since it contains customer data), with this > command: > > $ sudo losetup --find --show --partscan rlv_grkgld.1mb > > * On failure, the command hangs, and messages like these are printed > to the console, depending on the kernel version (see tests below) > > [ 270.506420] partition (null) (3 pp's found) is not contiguous > > [ 270.597428] BUG: unable to handle kernel paging request at 0000000000001000 > [ 270.599525] IP: [<ffffffff81379d4d>] strnlen+0xd/0x40 > > * On success, the command prints a loop device name, for example: > > /dev/loop0 > > [Regression Potential] > > * Low. Both changes are simple improvements in logic. > > * This affects users which mount disks/LUNs from the AIX OS; > it should only change behavior for users which relied on a > uninitialized variables to work correctly during partition > scan of those disks/LUNs which should be rare as the code > is likely to fail as we observe in this scenario. > > * This has been tested on Cosmic, Bionic, Xenial, and Trusty. > > Mauricio Faria de Oliveira (2): > partitions/aix: fix usage of uninitialized lv_info and lvname > structures > partitions/aix: append null character to print data from disk > > block/partitions/aix.c | 13 +++++++++---- > 1 file changed, 9 insertions(+), 4 deletions(-) > These patches have been re-submitted. Thanks, Kleber
BugLink: https://bugs.launchpad.net/bugs/1787281 [Impact] * Users with disks/LUNs used for AIX operating system installations previously, which possibly undergone overwrites/corruption on the partition table, might hit kernel failures during partition scan of such disk/LUN, and possibly hang the system (seen with retries). * The Linux kernel should be robust to corrupted disk data, performing a better sanitization/checks and not failing. * The fix are a couple of simple logic changes to make the code of the AIX partition table parser more robust. [Test Case] * Run the partition scan on the (trimmed) disk image of the AIX lun. (It's not provided here since it contains customer data), with this command: $ sudo losetup --find --show --partscan rlv_grkgld.1mb * On failure, the command hangs, and messages like these are printed to the console, depending on the kernel version (see tests below) [ 270.506420] partition (null) (3 pp's found) is not contiguous [ 270.597428] BUG: unable to handle kernel paging request at 0000000000001000 [ 270.599525] IP: [<ffffffff81379d4d>] strnlen+0xd/0x40 * On success, the command prints a loop device name, for example: /dev/loop0 [Regression Potential] * Low. Both changes are simple improvements in logic. * This affects users which mount disks/LUNs from the AIX OS; it should only change behavior for users which relied on a uninitialized variables to work correctly during partition scan of those disks/LUNs which should be rare as the code is likely to fail as we observe in this scenario. * This has been tested on Cosmic, Bionic, Xenial, and Trusty. Mauricio Faria de Oliveira (2): partitions/aix: fix usage of uninitialized lv_info and lvname structures partitions/aix: append null character to print data from disk block/partitions/aix.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)