Re: [PATCH v2 1/2] vmscan: don't subtraction of unsined

[Minchan Kim]

On Fri, Jul 9, 2010 at 10:16 AM, KOSAKI Motohiro
<kosaki.motohiro@xxxxxxxxxxxxxx> wrote:
>
>> > @@ -2628,16 +2628,16 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order)
>> > Â Â Â Â Â Â Â* take a long time.
>> > Â Â Â Â Â Â Â*/
>> > Â Â Â Â Â Â while (shrink_slab(sc.nr_scanned, gfp_mask, order) &&
>> > - Â Â Â Â Â Â Â Â Â zone_page_state(zone, NR_SLAB_RECLAIMABLE) >
>> > - Â Â Â Â Â Â Â Â Â Â Â Â Â slab_reclaimable - nr_pages)
>> > + Â Â Â Â Â Â Â Â Â(zone_page_state(zone, NR_SLAB_RECLAIMABLE) + nr_pages > n))
>> > Â Â Â Â Â Â Â Â Â Â ;
>> >
>> > Â Â Â Â Â Â /*
>> > Â Â Â Â Â Â Â* Update nr_reclaimed by the number of slab pages we
>> > Â Â Â Â Â Â Â* reclaimed from this zone.
>> > Â Â Â Â Â Â Â*/
>> > - Â Â Â Â Â sc.nr_reclaimed += slab_reclaimable -
>> > - Â Â Â Â Â Â Â Â Â zone_page_state(zone, NR_SLAB_RECLAIMABLE);
>> > + Â Â Â Â Â m = zone_page_state(zone, NR_SLAB_RECLAIMABLE);
>> > + Â Â Â Â Â if (m < n)
>> > + Â Â Â Â Â Â Â Â Â sc.nr_reclaimed += n - m;
>>
>> And it's not a completly trivial objection. ÂYour patch made the above
>> code snippet quite a lot harder to read (and hence harder to maintain).
>
> Initially, I proposed following patch to Christoph. but he prefer n and m.
> To be honest, I don't think this naming is big matter. so you prefer following
> I'll submit it.
>
>
>
>
> =====================================================================
> From 397199d69860061eaa5e1aaadac45c46c76b0522 Mon Sep 17 00:00:00 2001
> From: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
> Date: Wed, 30 Jun 2010 13:35:16 +0900
> Subject: [PATCH] vmscan: don't subtraction of unsined
>
> 'slab_reclaimable' and 'nr_pages' are unsigned. so, subtraction is
> unsafe.
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@xxxxxxxxxxxxxx>
Reviewed-by: Minchan Kim <minchan.kim@xxxxxxxxx>

I like this than n,m.

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