Hello,
Andrew Morton wrote:
>> Hoang-Nam Nguyen reported a bug in idr_get_new_above()
>> which occurred with a starting id value like 0x3ffc.
>> His test module easily reproduced the problem. Thanks.
>>
>> The test revealed the following bugs:
>>
>> 1. Relying on shift operations which have
On 07/12/2007 05:35 PM, Andrew Morton wrote:
>>
>> With this patch, idr.c should work as advertised allocating id
>> values in the range 0...0x7fff. Andrew had speculated that
>> it should allow the full range 0...0x to be used. I was
>> tempted to make changes to allow this, but it w
On Tue, 10 Jul 2007 16:05:31 -0400
Jim Houston <[EMAIL PROTECTED]> wrote:
> Hoang-Nam Nguyen reported a bug in idr_get_new_above()
> which occurred with a starting id value like 0x3ffc.
> His test module easily reproduced the problem. Thanks.
>
> The test revealed the following bugs:
>
> 1
> With this patch, idr.c should work as advertised allocating id
> values in the range 0...0x7fff. Andrew had speculated that
> it should allow the full range 0...0x to be used. I was
> tempted to make changes to allow this, but it would require changes
> to API, e.g. making the start
Hi Everyone,
Hoang-Nam Nguyen reported a bug in idr_get_new_above()
which occurred with a starting id value like 0x3ffc.
His test module easily reproduced the problem. Thanks.
The test revealed the following bugs:
1. Relying on shift operations which have undefined results
e.g.: 1 << n
