[#LU-190] random mode opencreate will LBUG lustre client

[LU-190] random mode opencreate will LBUG lustre client Created: 04/Apr/11 Updated: 25/Jul/12 Resolved: 08/Dec/11
Status:	Resolved
Project:	Lustre
Component/s:	None
Affects Version/s:	Lustre 2.1.0
Fix Version/s:	Lustre 2.1.0

Type:

Bug

Priority:

Minor

Reporter:

Liang Zhen (Inactive)

Assignee:

Liang Zhen (Inactive)

Resolution:

Fixed

Votes:

Labels:

None

Issue Links:

Duplicate
is duplicated by	~~LU-361~~	Lustre Client crashes due to ASSERTIO...	Resolved
is duplicated by	~~LU-1674~~	calling open() with an invalid `mode'...	Resolved

Severity:

Rank (Obsolete):

5068

Description

we can easily get LBUG if calling open with O_CREATE but without specified mode:

fd = open(filename, O_CREAT |O_RDWR);

Apr 4 06:12:01 prime kernel: LustreError: 6697:0:(client.c:2083:__ptlrpc_free_req()) ASSERTION(!request->rq_replay) failed: req ffff81021d734800
Apr 4 06:12:01 prime kernel: LustreError: 6697:0:(client.c:2083:__ptlrpc_free_req()) LBUG
Apr 4 06:12:01 prime kernel: Pid: 6697, comm: foo
Apr 4 06:12:01 prime kernel:
Apr 4 06:12:01 prime kernel: Call Trace:
Apr 4 06:12:01 prime kernel: [<ffffffff887cf5f1>] libcfs_debug_dumpstack+0x51/0x60 [libcfs]
Apr 4 06:12:01 prime kernel: [<ffffffff887cfb2a>] lbug_with_loc+0x7a/0xd0 [libcfs]
Apr 4 06:12:01 prime kernel: [<ffffffff8899fbdc>] __ptlrpc_req_finished+0x44c/0x850 [ptlrpc]
Apr 4 06:12:01 prime kernel: [<ffffffff88e637aa>] ll_intent_release+0x11a/0x190 [lustre]
Apr 4 06:12:01 prime kernel: [<ffffffff88eaa761>] ll_lookup_nd+0x291/0x400 [lustre]
Apr 4 06:12:01 prime kernel: [<ffffffff800228d9>] d_alloc+0x174/0x1a9
Apr 4 06:12:01 prime kernel: [<ffffffff80036d71>] __lookup_hash+0x10b/0x12f
Apr 4 06:12:01 prime kernel: [<ffffffff8001afef>] open_namei+0xf2/0x6d5
Apr 4 06:12:01 prime kernel: [<ffffffff80066b88>] do_page_fault+0x4fe/0x874
Apr 4 06:12:01 prime kernel: [<ffffffff800274e7>] do_filp_open+0x1c/0x38
Apr 4 06:12:01 prime kernel: [<ffffffff80019e1e>] do_sys_open+0x44/0xbe
Apr 4 06:12:01 prime kernel: [<ffffffff8005d28d>] tracesys+0xd5/0xe0

after reading into code, I found it's because VFS will not check & validate nameidata::intent::open::create_mode before calling into lookup of llite, so llite will get a totally random lookup_intent::it_create_mode, meanwhile, llite will use high bits of it_create_mode to store M_CHECK_STALE, so it will see an unexpected M_CHECK_STALE and totally screw up logic.

Comments

Comment by Build Master (Inactive) [ 04/Apr/11 ]

Integrated in reviews-centos5 #649
~~LU-190~~ opencreate without mode can crash llite

Liang Zhen : d03399a030bd520557e7a3afe831420ad2caf1d4
Files :

lustre/llite/namei.c

Comment by Oleg Drokin [ 04/Apr/11 ]

This mostly looks like a kernel bug, though I agree we should not fall into this trap.
In fact I remember I asked people to stop using user-submitted variables to store these values.

Comment by Liang Zhen (Inactive) [ 05/Apr/11 ]

yes, I agree it is a kernel bug.

Comment by Oleg Drokin [ 18/Apr/11 ]

I landed the patch, but please note that I think a better fix is still needed so probably a bad idea to close this bug.
(btw it also exists in 1.8 I think)