linux-kernel - Re: fix 2.4.33.3 / sun partition size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 12 Sep 2006 17:17:08 -0500
From:	"Tom 'spot' Callaway" <tcallawa@...hat.com>
To:	Willy Tarreau <w@....eu>
Cc:	"Jurzitza, Dieter" <DJurzitza@...manbecker.com>,
	davem@...emloft.net, linux-kernel@...r.kernel.org,
	Jeff Mahoney <jeffm@...e.com>, sparclinux@...r.kernel.org
Subject: Re: fix 2.4.33.3 / sun partition size

On Tue, 2006-09-12 at 21:17 +0200, Willy Tarreau wrote:
> On Tue, Sep 12, 2006 at 01:23:56PM +0200, Jurzitza, Dieter wrote:
> > Kernel: 2.4.33
> > 
> > Issue: really fix size display for sun partitions larger than 1TByte
> > 
> > Signed off by: Dieter Jurzitza DJurzitza@...manBecker.com
> > 
> > Problem: the last fix introduced by Jeff Mahoney for kernel 2.6 was not complete for kernel 2.4 (as applied)
> > I found out that add_gd_partition is called by any type of partition (2.4). add_gd_partition is defined as add_gd_partition (int, int), what makes no sense to me as negative numbers should never occur here. As long as add_gd_partition is not changed to add_gd_partition (unsigned, unsigned), /proc/partitions will keep showing negative numbers.
> 
> It seems fair. David, what's your opinion ?
> 
> > If ever someone could look into this, within the different partition type files in linux/fs/partitions the parameters to add_gd_partitions seem to be chosen arbitrarily between int, unsigned and unsigned long, whatever seemed to be appropriate, I think it would make sense to get consistent parameters to add_gd_partition from all partition types here.
> > Especially if one takes into account that sizeof (long) and sizeof (int) may differ significantly i. e. on sparc.
> 
> It would really depend on the on-disk format. If the partition table really
> stores 32 bit ints for sector counts, there's no point switching from ints
> to longs. But if it already stores 64 bits, then we're limiting it to 2 TB
> with 32 bit ints. I haven't checked the code right now, so I don't know. I
> hope Davem will enlighten us on this matter.

I think Davem may be on vacation...

~spot
-- 
Tom "spot" Callaway || Red Hat || Fedora || Aurora || GPG ID: 93054260

"We must not confuse dissent with disloyalty. We must remember always
that accusation is not proof and that conviction depends upon evidence
and due process of law. We will not walk in fear, one of another. We
will not be driven by fear into an age of unreason, if we dig deep in
our history and our doctrine, and remember that we are not descended
from fearful men -- not from men who feared to write, to speak, to
associate and to defend causes that were, for the moment, unpopular."
-- Edward R. Murrow, March 9, 1954

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/