On 29.09.2018 00:15, Andrew Morton wrote:
> On Fri, 28 Sep 2018 14:28:32 +0300 Kirill Tkhai wrote:
>
>> do_shrink_slab() returns unsigned long value, and
>> the placing into int variable cuts high bytes off.
>> Then we compare ret and 0xfffe (since SHRINK_EMPTY
>> is converted to ret type).
>
On Fri, Sep 28, 2018 at 02:15:09PM -0700, Andrew Morton wrote:
> What did he report? Was it code inspection? Did the kernel explode?
> etcetera. I'm thinking that the fix should be backported but to
> determine that, we need to understand the end-user runtime effects, as
> always. Please.
I'v
On Fri, 28 Sep 2018 14:28:32 +0300 Kirill Tkhai wrote:
> do_shrink_slab() returns unsigned long value, and
> the placing into int variable cuts high bytes off.
> Then we compare ret and 0xfffe (since SHRINK_EMPTY
> is converted to ret type).
>
> Thus, big number of objects returned by do_shr
On Fri, Sep 28, 2018 at 02:28:32PM +0300, Kirill Tkhai wrote:
> do_shrink_slab() returns unsigned long value, and
> the placing into int variable cuts high bytes off.
> Then we compare ret and 0xfffe (since SHRINK_EMPTY
> is converted to ret type).
>
> Thus, big number of objects returned by d
On Fri, Sep 28, 2018 at 02:28:32PM +0300, Kirill Tkhai wrote:
> do_shrink_slab() returns unsigned long value, and
> the placing into int variable cuts high bytes off.
> Then we compare ret and 0xfffe (since SHRINK_EMPTY
> is converted to ret type).
>
> Thus, big number of objects returned by d
do_shrink_slab() returns unsigned long value, and
the placing into int variable cuts high bytes off.
Then we compare ret and 0xfffe (since SHRINK_EMPTY
is converted to ret type).
Thus, big number of objects returned by do_shrink_slab()
may be interpreted as SHRINK_EMPTY, if low bytes of
their
6 matches
Mail list logo