linux-kernel - RE: [PATCH v3] qnx4: qnx4_block

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <2e1ec234135349c58993097b84ea10b2@AcuMS.aculab.com>
Date:   Tue, 3 Nov 2020 21:57:32 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Tong Zhang' <ztong0001@...il.com>
CC:     Anders Larsen <al@...rsen.net>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v3] qnx4: qnx4_block_map error handling

From: Tong Zhang
> Sent: 03 November 2020 13:53
...
> > Also 'blknum' is only 'unsigned long' so ~0ull is wrong.
> > It can be worth injecting an error and checking the error
> > propagation works.
> >
> > What is the actual maximum file size?

> The maximum file size is 2GB-1, but from my understanding
> qnx4_block_map() returns a physical block number.
> The max disk size supported is 2**64 bytes, however
> it is limited to unsigned long (2**32)
> -- so I am actually very hesitant to encode an error code in the return value
> without changing the function return type, which will introduce more
> changes I don't like.
> The original -EIO in qnx4_block_map() is also dodgy btw.

You've put your hand into a bag of worms...

Looks like a load of the 'long' need to be 64bit.

I'm actually surprised how often 'long' appears in the
linux kernel.
I don't believe there was ever a 16bit version (eg 286)
where 'long' was 32bit.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)