On Tuesday, January 2 2007 2:58 am, Adam J. Richter wrote: > I have not yet performed the 21 steps of > linux-2.6.20-rc3/Documentation/SubmitChecklist, which I think is a > great objectives list for future automation or some kind of community > web site. I hope to find time to make progress through that > checklist, but, in the meantime, I think the world may nevertheless be > infinitesmally better off if I post the patch that I'm currently > using that seems to fix the problem, seeing as how rc3 has passed > with no fix incorporated. > > I think the intent of the offending code was to avoid doing > a lock_sock() in a presumably common case where there was no need to > take the lock. So, I have kept the presumably fast test to exit > early. > > When it turns out to be necessary to take lock_sock(), RCU is > unlocked, then lock_sock is taken, the RCU is locked again, and > the test is repeated.
Hi Adam, I'm sorry I just saw this mail (mail not sent directly to me get shuffled off to a folder). I agree with your patch, I think dropping and then re-taking the RCU lock is the best way to go, although I'm curious to see what others have to say. The only real comment I have with the patch is that there is some extra whitespace which could probably be removed, but that is more of a style nit than anything substantial. > By the way, in a change not included in this patch, > I also tried consolidating the RCU locking in this file into a macro > IF_NLBL_REQUIRE(sksec, action), where "action" is the code > fragment to be executed with rcu_read_lock() held, although this > required splitting a couple of functions in half. >From your description above I'm not sure I like that approach so much, however, I could be misunderstanding something. Do you have a small example you could send? -- paul moore linux security @ hp - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
