Re: [PATCH] 9p: trans_fd, initialize recv fcall properly if not set

From: Eric Van Hensbergen
Date: Sat Sep 05 2015 - 23:15:38 EST

On Thu, Sep 3, 2015 at 4:38 AM, Dominique Martinet
<dominique.martinet@xxxxxx> wrote:
> That code really should never be called (rc is allocated in
> tag_alloc), but if it had been it couldn't have worked...
> Signed-off-by: Dominique Martinet <dominique.martinet@xxxxxx>
> ---
> net/9p/trans_fd.c | 3 +++
> 1 file changed, 3 insertions(+)
> To be honest, I think it might be better to just bail out if we get in
> this switch (m->req->rc == NULL after p9_tag_lookup) and not try to
> allocate more, because if we get there it's likely a race condition and
> silently re-allocating will end up in more troubles than trying to
> recover is worth.
> Thoughts ?

Hmmm...trying to rattle my brain and remember why I put it in there
back in 2008.
It might have just been over-defensive programming -- or more likely it just
pre-dated all the zero copy infrastructure which pretty much guaranteed we had
an rc allocated and what is there is vestigial. I'm happy to accept a
patch which
makes this an assert, or perhaps just resets the connection because something
has gone horribly wrong (similar to the ENOMEM path that is there now).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at