Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
Hi Lars, Thanks for the suggested changes, it solves the problem. > So the context that drbd_md_endio() runs in was not scheduled > for all the time it takes for drbd_adm_attach() to go all the way from > "drbd_md_read()" to ... "device->ldev = nbc;", several lock/unlock, > memory barriers and so on... and only then the drbd_md_endio() context > managed to evaluate the next line of code? I don't see an issue with drbd_md_endio() scheduling, its schedules properly. The only problem was 'drbd_md_put_buffer' which basically wakes up drbd_adm_attach process and makes ldev as valid pointer in case of drbd_md_read(). > I find it hard to believe that this would actually occur, > but if you can reproduce without above patch, > and no longer reproduce with above patch, > I'd consider it empirically proven. No doubt, Issue is reproducing without above changes, and the above changes fixes the issue. Tested it for more than 24 hours, test still in progress. Not found a single instance of put_ldev() called from drbd_md_endio() which is trigger/initiated from the 'drbd_md_read(), now system is running fine without a single ASSERT. Thanks & Regards Sunil Kumar -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20170228/c030341b/attachment.htm> -------------- next part -------------- A non-text attachment was scrubbed... Name: test_drbd.sh Type: application/x-shellscript Size: 1101 bytes Desc: not available URL: <http://lists.linbit.com/pipermail/drbd-user/attachments/20170228/c030341b/attachment.bin>