fs/partition/msdos: Fix unusable extended partition for > 512B sector
in [Kernel]
|
Prev: fs: fat: use hex_asc_lo/hex_asc_hi instead of custom one
Next: ST SPEAr: Added basic header files for SPEAr platform
From: Daniel Taylor on 10 Mar 2010 18:20 In the near future, WD will be releasing products that need this patch. Wouldn't it be a better Linux user experience to never have the problem, rather than wait for a bug-fix cycle on the kernel? OTOH, it would be reasonable to wait until someone else had a chance to test the change. We are awaiting NDAs from RedHat, Canonical, and Novell/SUSE to send them the affected products for library/application development. Regards, Dan > -----Original Message----- > From: OGAWA Hirofumi [mailto:hirofumi(a)mail.parknet.co.jp] > Sent: Wednesday, March 10, 2010 7:52 AM > To: Andrew Morton > Cc: H. Peter Anvin; Daniel Taylor; linux-kernel(a)vger.kernel.org > Subject: [PATCH 2/2] fs/partition/msdos: Fix unusable > extended partition for > 512B sector > > We can drop this patch, if we want to delay until someone notice this > and have some real requests to this. > > > > > Smaller size than a minimum blocksize can't be used, after all it's > handled like 0 size. > > For extended partition itself, this makes sure to use bigger size than > one logical sector size at least. > > Signed-off-by: OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> > --- > > fs/partitions/msdos.c | 13 ++++++++++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff -puN fs/partitions/msdos.c~part-support-4k-block-fix > fs/partitions/msdos.c > --- linux-2.6/fs/partitions/msdos.c~part-support-4k-block-fix > 2010-03-08 20:11:39.000000000 +0900 > +++ linux-2.6-hirofumi/fs/partitions/msdos.c 2010-03-08 > 20:32:19.000000000 +0900 > @@ -492,9 +492,16 @@ int msdos_partition(struct parsed_partit > if (!size) > continue; > if (is_extended_partition(p)) { > - /* prevent someone doing mkfs or mkswap on an > - extended partition, but leave room > for LILO */ > - put_partition(state, slot, start, size > == 1 ? 1 : 2); > + /* > + * prevent someone doing mkfs or mkswap on an > + * extended partition, but leave room for LILO > + * FIXME: this uses one logical sector > for > 512b > + * sector, although it may not be enough/proper. > + */ > + sector_t n = 2; > + n = min(size, max(sector_size, n)); > + put_partition(state, slot, start, n); > + > printk(" <"); > parse_extended(state, bdev, start, size); > printk(" >"); > _ > > -- > OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: OGAWA Hirofumi on 11 Mar 2010 07:00 "Daniel Taylor" <Daniel.Taylor(a)wdc.com> writes: > In the near future, WD will be releasing products that need this patch. > > Wouldn't it be a better Linux user experience to never have the problem, > rather than wait for a bug-fix cycle on the kernel? Of course, if we can fix, it's better. However, probably, users of this patch would be only boot loader, because this is a first sector on extended-partition itself, not logical-partitions in extended-partition. So, maybe this wouldn't be so major problem for normal users, and what is needed actually is not sure to me for now (I guess it might be depending to BIOS, if boot loader is using BIOS call.). So, this patch provides one logical sector, but it's just guess. > OTOH, it would be reasonable to wait until someone else had a chance to > test the change. We are awaiting NDAs from RedHat, Canonical, and > Novell/SUSE to send them the affected products for library/application > development. Thanks. -- OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Taylor on 11 Mar 2010 16:40 > -----Original Message----- > From: OGAWA Hirofumi [mailto:hirofumi(a)mail.parknet.co.jp] > Sent: Thursday, March 11, 2010 3:58 AM > To: Daniel Taylor > Cc: Andrew Morton; H. Peter Anvin; linux-kernel(a)vger.kernel.org > Subject: Re: [PATCH 2/2] fs/partition/msdos: Fix unusable > extended partition for > 512B sector > > "Daniel Taylor" <Daniel.Taylor(a)wdc.com> writes: > > > In the near future, WD will be releasing products that need > this patch. > > > > Wouldn't it be a better Linux user experience to never have > the problem, > > rather than wait for a bug-fix cycle on the kernel? > > Of course, if we can fix, it's better. > > However, probably, users of this patch would be only boot loader, > because this is a first sector on extended-partition itself, not > logical-partitions in extended-partition. I have not yet tried booting from one of these disks. They are in USB-attached enclosures, attached well after boot, so the bootloader has never seen them. They simply refuse to mount to a running Linux system because, when the storage for partition size and start was expanded to 64-bit, no one bothered to fix the intermediate storage in msdos.c, so the kernel cannot locate the start nor figure the size of the partitions. Logically, this patch is not complicated. The data types in msdos.c are flat-out wrong, given that the real stored data is of type sector_t. The intermediate variables should not be u32. For users of small disks, that are not shared with Windows XP, the patch is totally innocuous. It does not diminish any existing working behavior, for anyone, nor change any API, so I do not understand the resistance to using it. > > So, maybe this wouldn't be so major problem for normal users, and what > is needed actually is not sure to me for now (I guess it might be > depending to BIOS, if boot loader is using BIOS call.). > > So, this patch provides one logical sector, but it's just guess. > > > OTOH, it would be reasonable to wait until someone else had > a chance to > > test the change. We are awaiting NDAs from RedHat, Canonical, and > > Novell/SUSE to send them the affected products for > library/application > > development. > > Thanks. > -- > OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Daniel Taylor on 11 Mar 2010 17:10 > -----Original Message----- > From: H. Peter Anvin [mailto:hpa(a)zytor.com] > Sent: Thursday, March 11, 2010 1:58 PM > To: Daniel Taylor > Cc: OGAWA Hirofumi; Andrew Morton; linux-kernel(a)vger.kernel.org > Subject: Re: [PATCH 2/2] fs/partition/msdos: Fix unusable > extended partition for > 512B sector > > On 03/11/2010 01:25 PM, Daniel Taylor wrote: > > > > I have not yet tried booting from one of these disks. > > > > They are in USB-attached enclosures, > > Right... > > > attached well after boot, so the > > bootloader has never seen them. > > Wrong. A lot of BIOSes will attempt to boot from USB > storage. Worse, a > fair number of BIOSes will hang during startup if a USB > storage device > that confuses them -- even if not the primary boot device. BIOS failures prior to loading the kernel are not Linux' responsibility. Confused BIOS will still fail, even if the patch is not implemented, so how does that effect the acceptance of a patch that fixes post-boot behavior? >> They simply refuse to mount to a running >> Linux system because, when the storage for partition size and start was >> expanded to 64-bit, no one bothered to fix the intermediate storage in >> msdos.c, so the kernel cannot locate the start nor figure the size of >> the partitions. >> >> Logically, this patch is not complicated. The data types in msdos.c >> are flat-out wrong, given that the real stored data is of type sector_t. >> The intermediate variables should not be u32. > > I would consider this a bugfix. As such, it should be pushed outside > the merge window. > > -hpa > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: OGAWA Hirofumi on 11 Mar 2010 17:20
"Daniel Taylor" <Daniel.Taylor(a)wdc.com> writes: >> Of course, if we can fix, it's better. >> >> However, probably, users of this patch would be only boot loader, >> because this is a first sector on extended-partition itself, not >> logical-partitions in extended-partition. > > I have not yet tried booting from one of these disks. > > They are in USB-attached enclosures, attached well after boot, so the > bootloader has never seen them. They simply refuse to mount to a running > Linux system because, when the storage for partition size and start was > expanded to 64-bit, no one bothered to fix the intermediate storage in > msdos.c, so the kernel cannot locate the start nor figure the size of > the partitions. > > Logically, this patch is not complicated. The data types in msdos.c > are flat-out wrong, given that the real stored data is of type sector_t. > The intermediate variables should not be u32. > > For users of small disks, that are not shared with Windows XP, the patch > is totally innocuous. It does not diminish any existing working behavior, > for anyone, nor change any API, so I do not understand the resistance to > using it. Those are all about the first (1/2) patch, not this second patch. Personally, I'm thinking we should apply the first patch as bugfix. I'm talking about only second (2/2) patch in here. Thanks. -- OGAWA Hirofumi <hirofumi(a)mail.parknet.co.jp> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |