A race condition can occur under corner case conditions because of the interaction between the buffer high watermark management code and the threads that handle the input and output from the managed ring buffer. If the input data is extremely short, the input thread can signal "buffer filled to the high watermark" before the output thread is fully initialized and waiting on that semaphore. A very small delay (1ms) between starting the output thread and the input thread addresses the race condition. Patch coming. - John
Correction. Version 20091227 is from my local overlay but the latest in-tree version (20090113) also exhibits the issue. I'll also report this upstream. - John
Created attachment 233717 [details, diff] Source patch corrects the reported issue.
Created attachment 233719 [details, diff] Patch to the ebuild to apply the race condtion patch.
does this apply to 20100526 ? have you reported this upstream ? the mbuffer author is pretty responsive to e-mail.
Yes it does, and yes I did. Upstream is working with me on a more robust modification, so my patch can be considered just a smoking gun proof and not what we should put into the tree. In addition, 20100526 has a bug with its autoloader support which 20091227 doesn't have so it's not time to just bump to the latest version.
ive already bumped it :p once a new release has been made, let us know and i'll bump it in the tree
is this still relevant for mbuffer-20110724? I'm about to bump it...
This is still relevant with all versions of mbuffer that have been in the tree since the version I reported 7 years ago. Upstream couldn't reproduce the error on his Solaris system with my Linux-developed test case, but I intend to try again. Meanwhile, I continue to apply my patch.
(In reply to John R. Graham from comment #8) > This is still relevant with all versions of mbuffer that have been in the > tree since the version I reported 7 years ago. Upstream couldn't reproduce > the error on his Solaris system with my Linux-developed test case, but I > intend to try again. Meanwhile, I continue to apply my patch. So what happened with upstream, given they were working on something with you?
Upstream eventually said "works for me" and "I don't even use tape anymore so I can't verify your test case properly". I even offered to /give/ him a tape drive but apparently my drive wasn't attractive enough to him for him to even consider paying customs. I think it's obvious that my patch is a kludge and that refactoring of the initialization code so that the race condition can't occur is the correct solution. Alas, I haven't made the time to do that either.
I will test out the current in-tree versions and report back.
