Re: [PATCH 0/2] cgroup: seq_file .next functions should increase position index

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 1/28/20 8:27 PM, Michal Koutný wrote:
> I agree with your changes, however, I have some suggestions:
> 
> 1) squash [PATCH 2/2] "cgroup_procs_next should increase position index"
>    and [PATCH] "__cgroup_procs_start cleanup"
>    - make it clear in the commit message that it's fixing the small
>      buffer listing, it's not a mere cleanup(!)
> 2) for completeness, I propose squashing also this change (IOW,
>    cgroup_procs_start should only initialize the iterator, not move it):

got it

> 3) I was not able to reproduce the corrupted listing into small buffer
>    on v1 hierarchy, i.e. the [PATCH 1/2] "cgroup_pidlist_next should update
>    position index" log message should just explain the change is to
>    satisfy seq_file iterator requirements.

[root@localhost ~]# uname -a
Linux localhost.localdomain 5.4.7-200.fc31.x86_64 #1 SMP Tue Dec 31 22:25:12 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# mount | grep cgroup
cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,seclabel,nsdelegate)
cgroup on /mnt type cgroup (rw,relatime,seclabel,cpu)

[root@localhost ~]# dd if=/mnt/cgroup.procs bs=1  # normal output
...
1294
1295
1296
1304
1382
584+0 records in
584+0 records out
584 bytes copied, 0.00281916 s, 207 kB/s

[root@localhost ~]# dd if=/mnt/cgroup.procs bs=581 skip=1  # read after lseek in middle of last line
dd: /mnt/cgroup.procs: cannot skip to specified offset
83  <<< generates end of last line
1383  <<< ... and whole last line once again
0+1 records in
0+1 records out
8 bytes copied, 0.000171759 s, 46.6 kB/s

[root@localhost ~]# dd if=/mnt/cgroup.procs bs=1000 skip=1  # read after lseek beyond end of file
dd: /mnt/cgroup.procs: cannot skip to specified offset
1386  <<< generates last line anyway
0+1 records in
0+1 records out
5 bytes copied, 0.000198117 s, 25.2 kB/s

    
> I can send my complete diffs if the suggestions are unclear.
> 
> Michal
> 
> P.S. I really recommend using `git send-email` for sending out the
> patches, it makes mail threading more readable.

thank you, will resent v2 
   Vasily Averin



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux