<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p> Hi Lars,<br>
<br>
Thanks for the suggested changes, it solves the problem. <br>
<br>
</p>
<pre style="color: rgb(0, 0, 0); font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px;">> 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
</pre>
</body>
</html>