https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-5346 Lustre <p>If mdd_create_data() fails after calling mdd_object_make_hint() then the lod object will have ldo_stripenr set. A second call to mdd_create_data() will then trigger the failed assertion in lod_ah_init().</p> <p>This was found by memory allocation fault injection.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>llmount.sh cd /mnt/lustre sys_mknod f0 echo /root/lustre-release/lustre/osd-ldiskfs/osd_handler.c:945 &gt; /proc/fs/lustre/alloc_fail # fail to allocate the transaction in osd_trans_create() sys_open f0 w # open("f0", O_WRONLY) sys_open f0 w # open("f0", O_WRONLY) </pre> </div></div> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>[ 338.633638] LustreError: 5233:0:(lod_object.c:2606:lod_ah_init()) ASSERTION( lc-&gt;ldo_stripenr == 0 ) failed: [ 338.635476] LustreError: 5233:0:(lod_object.c:2606:lod_ah_init()) LBUG [ 338.636652] Pid: 5233, comm: mdt00_005 [ 338.637354] [ 338.637355] Call Trace: [ 338.638094] [&lt;ffffffffa02be8c5&gt;] libcfs_debug_dumpstack+0x55/0x80 [libcfs] [ 338.639359] [&lt;ffffffffa02beec7&gt;] lbug_with_loc+0x47/0xb0 [libcfs] [ 338.640490] [&lt;ffffffffa0d5e43c&gt;] lod_ah_init+0xadc/0xb40 [lod] [ 338.641591] [&lt;ffffffffa0817339&gt;] mdd_object_make_hint+0x139/0x180 [mdd] [ 338.642804] [&lt;ffffffffa08062a9&gt;] mdd_create_data+0x359/0x7f0 [mdd] [ 338.644047] [&lt;ffffffffa0cc67dd&gt;] mdt_mfd_open+0xc1d/0xf40 [mdt] [ 338.645182] [&lt;ffffffffa0cc6d00&gt;] mdt_finish_open+0x200/0xc50 [mdt] [ 338.646351] [&lt;ffffffffa0cc1255&gt;] ? mdt_object_open_lock+0x345/0x9d0 [mdt] [ 338.647603] [&lt;ffffffffa0cc7cce&gt;] mdt_open_by_fid_lock+0x57e/0x900 [mdt] [ 338.648821] [&lt;ffffffffa0cc8c28&gt;] mdt_reint_open+0x8c8/0x20b0 [mdt] [ 338.649974] [&lt;ffffffff815547cb&gt;] ? _spin_unlock+0x2b/0x40 [ 338.650985] [&lt;ffffffffa02dc60c&gt;] ? upcall_cache_get_entry+0x3dc/0x8a0 [libcfs] [ 338.652347] [&lt;ffffffffa0475890&gt;] ? lu_ucred+0x20/0x30 [obdclass] [ 338.653490] [&lt;ffffffffa0c93b85&gt;] ? mdt_ucred+0x15/0x20 [mdt] [ 338.654580] [&lt;ffffffffa0cac90c&gt;] ? mdt_root_squash+0x2c/0x3f0 [mdt] [ 338.655786] [&lt;ffffffffa06b4236&gt;] ? __req_capsule_get+0x166/0x6e0 [ptlrpc] [ 338.657037] [&lt;ffffffffa0cb07a1&gt;] mdt_reint_rec+0x41/0xe0 [mdt] [ 338.658132] [&lt;ffffffffa0c9baf3&gt;] mdt_reint_internal+0x4c3/0x7c0 [mdt] [ 338.659314] [&lt;ffffffffa0c9bfe6&gt;] mdt_intent_reint+0x1f6/0x520 [mdt] [ 338.660473] [&lt;ffffffffa0c9a6c9&gt;] mdt_intent_policy+0x499/0xca0 [mdt] [ 338.661691] [&lt;ffffffffa0645422&gt;] ldlm_lock_enqueue+0x302/0x920 [ptlrpc] [ 338.662931] [&lt;ffffffffa066d651&gt;] ldlm_handle_enqueue0+0x341/0x11e0 [ptlrpc] [ 338.664249] [&lt;ffffffffa06ec9a2&gt;] tgt_enqueue+0x62/0x1d0 [ptlrpc] [ 338.665403] [&lt;ffffffffa06ebc35&gt;] tgt_request_handle+0x245/0xad0 [ptlrpc] [ 338.666663] [&lt;ffffffffa069ed91&gt;] ptlrpc_main+0xcf1/0x1880 [ptlrpc] [ 338.667841] [&lt;ffffffffa069e0a0&gt;] ? ptlrpc_main+0x0/0x1880 [ptlrpc] [ 338.668982] [&lt;ffffffff8109eab6&gt;] kthread+0x96/0xa0 [ 338.669902] [&lt;ffffffff8100c30a&gt;] child_rip+0xa/0x20 [ 338.670806] [&lt;ffffffff81554710&gt;] ? _spin_unlock_irq+0x30/0x40 [ 338.671868] [&lt;ffffffff8100bb10&gt;] ? restore_args+0x0/0x30 [ 338.672848] [&lt;ffffffff8109ea20&gt;] ? kthread+0x0/0xa0 [ 338.673761] [&lt;ffffffff8100c300&gt;] ? child_rip+0x0/0x20 [ 338.674690] </pre> </div></div> LU-5346

lod_ah_init()) ASSERTION( lc->ldo_stripenr == 0 ) failed

Bug Minor Open Unresolved WC Triage John Hammond lod malloc Mon, 14 Jul 2014 23:36:58 +0000 Tue, 23 Feb 2016 08:08:21 +0000 Lustre 2.6.0 0 8 <p>Alex can you suggest the best way to clean up the partially set striping data (ldo_stripenr, ldo_stripe) that is created by a failure in mdd_create_data()? Should we add a function to the DT API (dt_create_data_fini()) to handle this case?</p> <p>given all this data created by lod_ah_init() is in-core only, I'd suggest to either: 1) recognize we have it set and return immediately 2) just re-set everything from the beginning? would it be possible?</p> <p>I'm OK with that but it's not enough. If mdd_create_data() fails after lod_ah_init() has returned then we have an object with ldo_stripenr != 0 but ldo_stripe == NULL. Operations on this object will trigger several assertions on lod. If it fails after lod_declare_xattr_set() then we need to call lod_object_free_striping() but the API does not offer us a convenient way to do so.</p> <p>The first problem is not so hard to fix. I think that lod_ah_init() should not be setting ldo_stripenr. We have some holes in lod_object where lod_ah_init() could put a ldo_stripe_count_hint that we pickup later.</p> <p>The second problem of failure after declare is trickier.</p> <p>iirc, we discussed a related issue in the past - currently locks are supposed to be taken "inside" transaction (still an open question how good is that, but benefits are known). this mean that intermediate state between "declare" and "execute" is exposed to other threads. which isn't good, of course. Ideally "declare" should be working with own copy of data (say, stored somewhere in transaction which is private), while "execute" should use that private data and apply changes atomically. this would solve this issue as well because that private data would be released automatically with -&gt;do_trans_stop(). I'll think of that (again, sorry).</p> Development Rank 1|hzwrfj: Rank (Obsolete) 14912 Severity