> On Oct 31, 2016, at 13:31, Vitaliy Gusev <gusev.vitaliy@xxxxxxxxx> wrote:
>
>
>> On 31 Oct 2016, at 18:46, Trond Myklebust <trondmy@xxxxxxxxxxxxxxx> wrote:
>>
>>
>>> On Oct 30, 2016, at 21:18, Vitaliy Gusev <gusev.vitaliy@xxxxxxxxx> wrote:
>>>
>>> Hi.
>>>
>>> During some tests I’ve seen nfs-client crashes. It was just reading file via NFSv4.1 protocol.
>>>
>>> The panic message is below, fixing patch is attached.
>>
>> Why does this need to be fixed on the client? It looks like a server bug… In any case, the fix you propose is going to leave the client with broken open state.
>
> 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 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.��.n��������+%������w��{.n�����{��w��� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
