Re: [Nbd] 3.12 BUG() on ext4, kernel crash on nbd-client when nbd server rebooting

[Wouter Verhelst <w@...112...>]

Op 19-11-13 02:43, Paul Clements schreef:
> 
> 
> On Monday, November 18, 2013, Wouter Verhelst wrote:
> 
>     Op 18-11-13 23:17, Paul Clements schreef:
>     [...]
>     > Right, some rearrangement of the ioctls would be required too...we'd
>     > probably want alternate versions of SET_SOCK and DO_IT that are
>     > re-entrant (right now those will error on an already-configured
>     device,
>     > and they're doing some setup and teardown that is unneeded in the
>     > reconnect case).
> 
>     Since all this is a significant departure of the current API, I suppose
>     it would be good if there would be a way for the client to detect what
>     the currently-running kernel supports, without having to resort to
>     things like calling 'uname -r' (or equivalent in C code) or extensive
>     error handling based on "that ioctl isn't supported, so let's fall back
>     to previous API versions."
> 
> 
> Anything specific that would make it easier from your perspective?  One
> thought is to have SET_FLAGS fail when an unknown flag is passed. Or
> say a get_capabilities() type call?

A get_capabilities() would be most useful, yes. While having SET_FLAGS
fail for unknown flags would be useful in and of itself, it wouldn't be
as useful, since then you know one of the flags which were set aren't
supported, but you don't know which ones.

Alternatively, SET_FLAGS could just mask out the flags it doesn't know
about, and return the resulting set of flags that are left to userspace.
If we then find that the result isn't what we asked, it should be easy
to figure out what's missing by just inspecting the bitmask.

-- 
This end should point toward the ground if you want to go to space.

If it starts pointing toward space you are having a bad problem and you
will not go to space today.

  -- http://xkcd.com/1133/