On Thu, Dec 13, 2007 at 04:20:27PM -0600, Tom Tucker wrote: > > On Thu, 2007-12-13 at 16:45 -0500, Chuck Lever wrote: > > On Dec 13, 2007, at 4:33 PM, J. Bruce Fields wrote: > > > On Wed, Dec 12, 2007 at 01:10:17PM -0500, Chuck Lever wrote: > > >> On Dec 11, 2007, at 6:32 PM, Tom Tucker wrote: > > >>> + required = atomic_read(&svsk->sk_reserved) + serv->sv_max_mesg; > > >>> + wspace = sk_stream_wspace(svsk->sk_sk); > > >>> + > > >>> + if (wspace < sk_stream_min_wspace(svsk->sk_sk)) > > >>> + return 0; > > >>> + if (required * 2 > wspace) > > >>> + return 0; > > >> > > >> Since "required" is an int, this test can behave differently than > > >> the one > > >> it replaces. > > > > > > If sk_reserved can approach half of 2^31, for example, then surely we > > > have bigger problems? > > > > > > What stops sk_reserved from going negative? > > Nothing actively _stops_ it from going negative. Indirectly it is > prevented by the "fact" that sv_max_mesg is always greater than the > amount returned by any read on the socket. If this is not true, then > sk_reserved can go negative. That would occur in svc_recv when the > difference between the amount currently reserved (worst case > sv_max_mesg) and the amount read is subtracted from the amount reserved. > If the amount read were greater than sv_max_mesg then the result would > be negative (both meanings intended). > > I could add a BUG_ON and run some tests.
I have to admit, I'm completely and utterly lost here. Chuck, could you explain exactly, in detail, how you think this change could cause a bug? --b. - To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
