possible bug in proc fast scan code

[walter harms]

Hello List,
i was refactoring the code and noticed the the FAST_TOP code is less robust.
It leaves fields uninitialized if no enough data is presented.

The most easy way would be to disable the FAST_TOP part for 2.4 kernels.

re,
 wh



Am 17.02.2012 12:58, schrieb walter harms:
> Hello List,
> it it possible that the fast code for proc has a bug.
> I notice that top shows funny results for CPU
> 
>     4   137 root     SWN      0   0% -3028   0% [kswapd]
>     6   139 root     SWN      0   0% -3028   0% [kupdated]
>     2   138 root     SWN      0   0% -2728   0% [keventd]
>     5   138 root     SWN      0   0% -31328   0% [bdflush]
>     8   136 root     SWN      0   0% -41280   0% [khubd]
> 
> 
> Disabling the fast code (aka:CONFIG_FEATURE_FAST_TOP)
> makes it work again.
> 
>    3     1 root     SWN      0   0%   0   0% [ksoftirqd_CPU0]
>     4     1 root     SW       0   0%   0   0% [kswapd]
>     5     1 root     SW       0   0%   0   0% [bdflush]
>     8     1 root     SW       0   0%   0   0% [khubd]
>    14     1 root     SWN      0   0%   0   0% [jffs2_gcd_mtd2]
> 
> here is an example stat line:
>  cat /proc/1/stat
> 1 (init) S 0 0 0 0 -1 256 72 4615 142 5616 7 97 245 270 8 0 0 0 25 983040 69 4294967295 524288 547478 2684354368 2684353268 895410242 0 0
> 1475401980 671819267 0 0 0 0 0
> 
> i am a bit busy so no patch and it is also possible that there is compiler bug.
> i hope that helps if someone would like to investigate further.
> 
> The kernel is a 2.4.36.
> 
> re,
>  wh
> _______________________________________________
> busybox mailing list
> busybox at busybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
> 
>