lishan
2020-Mar-21 04:24 UTC
[Ocfs2-devel] Fwd: Re: [PATCH v2 0/4] ocfs2: seq_file .next functions should increase position index
test environment: kernel version: 5.6.0-rc5 lockres_seq_next --> /sys/kernel/debug/o2dlm/2C9B43EBE44D4715A0B0DBE4D72016A3/locking_state The output content is incomplete and endless, and the subsequent output is skip reading. The operation and print is as follows: dd if=/sys/kernel/debug/o2dlm/2C9B43EBE44D4715A0B0DBE4D72016A3/locking_state bs=40 skip=1 S:1,5,0,0,0,0,0,0,0,0,3 RMAP: LVBX:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 LOCK:1,0,5,-1,5,5:1,0,0,0,0,0,0,0,0,2 NAME:M0000000000000000000042e7349704 LRES:1,5,0,0,0,0,0,0,0,0,3 RMAP: LVBX:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 LOCK:1,0,5,-1,5,5:2,0,0,0,0,0,0,0,0,2 ........ NAME:M0000000000000000000042e7349704 LRES:1,5,0,0,0,0,0,0,0,0,3 RMAP: LVBX:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 LOCK:1,0,5,-1,5,5:2,0,0,0,0,0,0,0,0,2 NAME:M0000000000000000000010e7349704 ...... but, there is no endless output using the following script: linux-EalnPD:~ # q=;while read -r r;do echo "$((++q)) $r";done < /sys/kernel/debug/o2dlm/2C9B43EBE44D4715A0B0DBE4D72016A3/locking_state 1 NAME:S000000000000000000000200000000 2 LRES:1,5,0,0,0,0,0,0,0,0,3 3 RMAP: 4 LVBX:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 5 LOCK:1,0,5,-1,5,5:6,0,0,0,0,0,0,0,0,2 6 7 8 NAME:M0000000000000000000016e7349704 9 NAME:M0000000000000000000018e7349704 10 NAME:M000000000000000000001ae7349704 11 NAME:M000000000000000000001ce7349704 12 NAME:M000000000000000000001ee7349704 13 NAME:M0000000000000000000020e7349704 .... 534 NAME:W00000000000000000843c81d0b7768 535 NAME:O00000000000000000843c800000000 Other interface test results: nst_seq_next --> /sys/kernel/debug/o2net/send_tracking sc_seq_next --> /sys/kernel/debug/o2net/stats File content is empty, so, read it like use dd command, No effect. ocfs2_dlm_seq_next --> /sys/kernel/debug/ocfs2/2C9B43EBE44D4715A0B0DBE4D72016A3/locking_state Read file normal output. And, output is still endless, after adding Vasily Averin's modifications, patch are as follow: [Ocfs2-devel] [PATCH v2 1/4] lockres_seq_next should increase position index Vasily Averin [Ocfs2-devel] [PATCH v2 2/4] ocfs2_dlm_seq_next should increase position index Vasily Averin [Ocfs2-devel] [PATCH v2 3/4] nst_seq_next should increase position index Vasily Averin [Ocfs2-devel] [PATCH v2 4/4] sc_seq_next should increase position index I added the log in seq_read, use the 'dd' read command above, print as follows: 2020-03-21T11:27:50.691302+08:00|notice|kernel[-]|[92756.285422] [22000/dd] --> seq_read, init, start ppos 250434, max read size 10, m->read_pos 250434, mem index 1028, mem size 4096, mem from 233, mem count 11. 2020-03-21T11:27:50.691328+08:00|notice|kernel[-]|[92756.285430] [22000/dd] --> seq_read, init, start ppos 250444, max read size 10, m->read_pos 250444, mem index 1028, mem size 4096, mem from 243, mem count 1. 2020-03-21T11:27:50.691355+08:00|notice|kernel[-]|[92756.285442] [22000/dd] --> seq_read, read start, m->read_pos 250444, mem index 1028, mem size 4096, mem from 0, mem count 0. 2020-03-21T11:27:50.691381+08:00|notice|kernel[-]|[92756.285444] [22000/dd] --> seq_read, before go to file, mem file count 244, mem file size 4096 2020-03-21T11:27:50.691406+08:00|notice|kernel[-]|[92756.285453] [22000/dd] --> seq_read, init, start ppos 250454, max read size 10, m->read_pos 250454, mem index 1029, mem size 4096, mem from 9, mem count 235. 2020-03-21T11:27:50.691434+08:00|notice|kernel[-]|[92756.285458] [22000/dd] --> seq_read, init, start ppos 250464, max read size 10, m->read_pos 250464, mem index 1029, mem size 4096, mem from 19, mem count 225. ...... I haven't figured out what the reason is, but the result is not as expected. On 2020/3/9 16:27, piaojun wrote:> > > > -------- Forwarded Message -------- > Subject: Re: [PATCH v2 0/4] ocfs2: seq_file .next functions should increase position index > Date: Wed, 26 Feb 2020 16:32:30 +0800 > From: Joseph Qi <joseph.qi at linux.alibaba.com> > To: Vasily Averin <vvs at virtuozzo.com>, ocfs2-devel at oss.oracle.com, piaojun <piaojun at huawei.com> > CC: Mark Fasheh <mark at fasheh.com>, Joel Becker <jlbec at evilplan.org> > > Looks good. > Jun, could you please help verify these changes and give your tested-by? Since I don't have ocfs2 cluster locally... > > Thanks, > Joseph > > On 2020/2/26 14:52, Vasily Averin wrote: >> v2: resend with improved patch description >> >> In Aug 2018 NeilBrown noticed >> commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") >> "Some ->next functions do not increment *pos when they return NULL... >> Note that such ->next functions are buggy and should be fixed. >> A simple demonstration is >> >> dd if=/proc/swaps bs=1000 skip=1 >> >> Choose any block size larger than the size of /proc/swaps. This will >> always show the whole last line of /proc/swaps" >> >> /proc/swaps output was fixed recently, however there are lot of other >> affected files and 4 of them are related to ocfs2. >> >> Unfortunately I'm not familiar with ocfs2 and cannot verify the patches locally. >> >> Usually you can observe following related problems: >> - read after lseek beyond end of file, described above by NeilBrown >> "dd if=<AFFECTED_FILE> bs=1000 skip=1" will incorrectly generate whole last line >> >> - read after lseek on into middle of last line will output expected rest of >> last line but then repeat whole last line once again. >> >> - If .show() function generates multi-line output following bash script will never finish. >> >> $ q=;while read -r r;do echo "$((++q)) $r";done < AFFECTED_FILE >> >> Link: https://urldefense.com/v3/__https://bugzilla.kernel.org/show_bug.cgi?id=206283__;!!GqivPVa7Brio!KCKPYUMw_U1HxUL22F1ZSc3jh5A-b_7ZVR-iw9uPAprEKFstRKwLXaJmpXuqsTjpGIByXQ$ >> >> Vasily Averin (4): >> lockres_seq_next should increase position index >> ocfs2_dlm_seq_next should increase position index >> nst_seq_next should increase position index >> sc_seq_next should increase position index >> >> fs/ocfs2/cluster/netdebug.c | 2 ++ >> fs/ocfs2/dlm/dlmdebug.c | 1 + >> fs/ocfs2/dlmglue.c | 1 + >> 3 files changed, 4 insertions(+) >> > . > > > . >
Vasily Averin
2020-Mar-22 07:27 UTC
[Ocfs2-devel] Fwd: Re: [PATCH v2 0/4] ocfs2: seq_file .next functions should increase position index
Dear lishan, thank you for your experiments. Dear all, please drop my patch-set, they are incomplete. seq_opetations used in ocfs2 are incorrect -- they ignores position index provided by seq_read(). by design .start() functions should skip first elements specified by *pos argument, however lockres_seq_start(), ocfs2_dlm_seq_start() and other igores *pos, and uses own logic instead. It should be reworked. Thank you, Vasily Averin On 3/21/20 7:24 AM, lishan wrote:> test environment: > kernel version: 5.6.0-rc5 > > lockres_seq_next --> > /sys/kernel/debug/o2dlm/2C9B43EBE44D4715A0B0DBE4D72016A3/locking_state > The output content is incomplete and endless, and the subsequent output is skip reading. > The operation and print is as follows: > dd if=/sys/kernel/debug/o2dlm/2C9B43EBE44D4715A0B0DBE4D72016A3/locking_state bs=40 skip=1 > S:1,5,0,0,0,0,0,0,0,0,3 > RMAP: > LVBX:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > LOCK:1,0,5,-1,5,5:1,0,0,0,0,0,0,0,0,2 > > NAME:M0000000000000000000042e7349704 > LRES:1,5,0,0,0,0,0,0,0,0,3 > RMAP: > LVBX:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > LOCK:1,0,5,-1,5,5:2,0,0,0,0,0,0,0,0,2 > ........ > NAME:M0000000000000000000042e7349704 > LRES:1,5,0,0,0,0,0,0,0,0,3 > RMAP: > LVBX:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > LOCK:1,0,5,-1,5,5:2,0,0,0,0,0,0,0,0,2 > > NAME:M0000000000000000000010e7349704 > ...... > > but, there is no endless output using the following script: > linux-EalnPD:~ # q=;while read -r r;do echo "$((++q)) $r";done < /sys/kernel/debug/o2dlm/2C9B43EBE44D4715A0B0DBE4D72016A3/locking_state > 1 NAME:S000000000000000000000200000000 > 2 LRES:1,5,0,0,0,0,0,0,0,0,3 > 3 RMAP: > 4 LVBX:00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > 5 LOCK:1,0,5,-1,5,5:6,0,0,0,0,0,0,0,0,2 > 6 > 7 > 8 NAME:M0000000000000000000016e7349704 > 9 NAME:M0000000000000000000018e7349704 > 10 NAME:M000000000000000000001ae7349704 > 11 NAME:M000000000000000000001ce7349704 > 12 NAME:M000000000000000000001ee7349704 > 13 NAME:M0000000000000000000020e7349704 > .... > 534 NAME:W00000000000000000843c81d0b7768 > 535 NAME:O00000000000000000843c800000000 > > Other interface test results: > nst_seq_next --> /sys/kernel/debug/o2net/send_tracking > sc_seq_next --> /sys/kernel/debug/o2net/stats > File content is empty, so, read it like use dd command, No effect. > ocfs2_dlm_seq_next --> > /sys/kernel/debug/ocfs2/2C9B43EBE44D4715A0B0DBE4D72016A3/locking_state > Read file normal output. > > And, output is still endless, after adding Vasily Averin's modifications, patch are as follow: > [Ocfs2-devel] [PATCH v2 1/4] lockres_seq_next should increase position index Vasily Averin > [Ocfs2-devel] [PATCH v2 2/4] ocfs2_dlm_seq_next should increase position index Vasily Averin > [Ocfs2-devel] [PATCH v2 3/4] nst_seq_next should increase position index Vasily Averin > [Ocfs2-devel] [PATCH v2 4/4] sc_seq_next should increase position index > > I added the log in seq_read, use the 'dd' read command above, print as follows: > 2020-03-21T11:27:50.691302+08:00|notice|kernel[-]|[92756.285422] [22000/dd] --> seq_read, init, start ppos 250434, max read size 10, m->read_pos 250434, mem index 1028, mem size 4096, mem from 233, mem count 11. > 2020-03-21T11:27:50.691328+08:00|notice|kernel[-]|[92756.285430] [22000/dd] --> seq_read, init, start ppos 250444, max read size 10, m->read_pos 250444, mem index 1028, mem size 4096, mem from 243, mem count 1. > 2020-03-21T11:27:50.691355+08:00|notice|kernel[-]|[92756.285442] [22000/dd] --> seq_read, read start, m->read_pos 250444, mem index 1028, mem size 4096, mem from 0, mem count 0. > 2020-03-21T11:27:50.691381+08:00|notice|kernel[-]|[92756.285444] [22000/dd] --> seq_read, before go to file, mem file count 244, mem file size 4096 > 2020-03-21T11:27:50.691406+08:00|notice|kernel[-]|[92756.285453] [22000/dd] --> seq_read, init, start ppos 250454, max read size 10, m->read_pos 250454, mem index 1029, mem size 4096, mem from 9, mem count 235. > 2020-03-21T11:27:50.691434+08:00|notice|kernel[-]|[92756.285458] [22000/dd] --> seq_read, init, start ppos 250464, max read size 10, m->read_pos 250464, mem index 1029, mem size 4096, mem from 19, mem count 225. > ...... > > I haven't figured out what the reason is, but the result is not as expected. > > On 2020/3/9 16:27, piaojun wrote: >> >> >> >> -------- Forwarded Message -------- >> Subject: Re: [PATCH v2 0/4] ocfs2: seq_file .next functions should increase position index >> Date: Wed, 26 Feb 2020 16:32:30 +0800 >> From: Joseph Qi <joseph.qi at linux.alibaba.com> >> To: Vasily Averin <vvs at virtuozzo.com>, ocfs2-devel at oss.oracle.com, piaojun <piaojun at huawei.com> >> CC: Mark Fasheh <mark at fasheh.com>, Joel Becker <jlbec at evilplan.org> >> >> Looks good. >> Jun, could you please help verify these changes and give your tested-by? Since I don't have ocfs2 cluster locally... >> >> Thanks, >> Joseph >> >> On 2020/2/26 14:52, Vasily Averin wrote: >>> v2: resend with improved patch description >>> >>> In Aug 2018 NeilBrown noticed >>> commit 1f4aace60b0e ("fs/seq_file.c: simplify seq_file iteration code and interface") >>> "Some ->next functions do not increment *pos when they return NULL... >>> Note that such ->next functions are buggy and should be fixed. >>> A simple demonstration is >>> >>> dd if=/proc/swaps bs=1000 skip=1 >>> >>> Choose any block size larger than the size of /proc/swaps. This will >>> always show the whole last line of /proc/swaps" >>> >>> /proc/swaps output was fixed recently, however there are lot of other >>> affected files and 4 of them are related to ocfs2. >>> >>> Unfortunately I'm not familiar with ocfs2 and cannot verify the patches locally. >>> >>> Usually you can observe following related problems: >>> - read after lseek beyond end of file, described above by NeilBrown >>> "dd if=<AFFECTED_FILE> bs=1000 skip=1" will incorrectly generate whole last line >>> >>> - read after lseek on into middle of last line will output expected rest of >>> last line but then repeat whole last line once again. >>> >>> - If .show() function generates multi-line output following bash script will never finish. >>> >>> $ q=;while read -r r;do echo "$((++q)) $r";done < AFFECTED_FILE >>> >>> Link: https://urldefense.com/v3/__https://bugzilla.kernel.org/show_bug.cgi?id=206283__;!!GqivPVa7Brio!NwJIBH5pk_PU0nl3GdikAyWr88AIZXuC-YDPoiMU1ltEcROIRtcSY_EHVaiSzeRD-Jpafw$ >>> >>> Vasily Averin (4): >>> lockres_seq_next should increase position index >>> ocfs2_dlm_seq_next should increase position index >>> nst_seq_next should increase position index >>> sc_seq_next should increase position index >>> >>> fs/ocfs2/cluster/netdebug.c | 2 ++ >>> fs/ocfs2/dlm/dlmdebug.c | 1 + >>> fs/ocfs2/dlmglue.c | 1 + >>> 3 files changed, 4 insertions(+) >>> >> . >> >> >> . >> >