[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA5qM4C+UGB_SXW5OeWKPtNkXyVCfwwB_ct9wps0Lj6VhvTawg@mail.gmail.com>
Date: Tue, 3 Nov 2020 08:52:32 -0500
From: Tong Zhang <ztong0001@...il.com>
To: David Laight <David.Laight@...lab.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
On Tue, Nov 3, 2020 at 5:54 AM David Laight <David.Laight@...lab.com> wrote:
>
> From: Tong Zhang
> > Sent: 02 November 2020 23:14
> >
> > qnx4_block_map() may return -EIO on funny qnx4 fs image, in this case do
> > not interpret -EIO as a correct block number
>
> That commit message is now wrong.
ouch -- what would you suggest here?
> 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.
> Is there actually an 'out of range' blknum value
> that can be used to signify an error without
> changing the return value to 'long long'.
>
> David
>
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
>
Powered by blists - more mailing lists