> On 31 Oct 2016, at 20:54, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote: > >> >> On Oct 31, 2016, at 13:31, Vitaliy Gusev <gusev.vitaliy@xxxxxxxxx> wrote: >> Do you like to get crash every time a remote side sends improper datas? I believe not. > > There are a million other ways to screw a client over if your server is buggy or compromised. I agree, but crashes are not right way to work with incorrect datas and that’s why I reported problem. >> >> I proposed just ignore the flag OPEN4_RESULT_CONFIRM for nfs4.1+ clients. >> RFC5661 has description that allows a client to do that: >> >> o OPEN4_RESULT_CONFIRM is deprecated and MUST NOT be returned by an >> NFSv4.1 server. > > I know what the spec says. The point is that the client will leak memory, and fail to handle the situation correctly when the server returns OPEN4_RESULT_CONFIRM with or with the patch that you are proposing. > The right thing to do here would rather be to print out a big fat warning to the user, and then possibly also to kill the mount. That’s a good point. What if return error for OPEN operation instead of kill the mount? ——— Thanks, Vitaliy Gusev --- Vitaliy Gusev -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
