On 29/10/14 23:33, Emmanuel Dreyfus wrote:
Antti Kantee <pooka%iki.fi@localhost> wrote:That comment is close to 10 years old. If you haven't, start by checking that it still applies and perhaps do a quick check to see what goes wrong (I don't remember exactly, some sort of kernel panic I think) and if it can be fixed.I just tried removing this if (error != ENOMEM) error = 0 and it seems work fine on netbsd-7. The error is reported to the calling layers without a hitch. Are there some corner cases where it could cause problem?
Don't recall it being a corner case.
And why does NF has to save the error in np->n_error to recover it in upper layer? Obsolete code that was never touched?
Not sure, but per a quick examination it looks like nfs wants to save the error for the next caller. As long as puffs is synchronous, it won't be an issue. Notably, though, a puffs file server might like to be asynchronous in handling a write and report an error later, but that's getting complicated. Optimization is not a substitute for correctness ...