Em 10-09-2015 10:02, David Laight escreveu:
From: Marcelo Ricardo Leitner
Sent: 10 September 2015 13:54
Em 09-09-2015 21:16, David Miller escreveu:
From: Marcelo Ricardo Leitner <marcelo.leitner@xxxxxxxxx>
Date: Wed, 9 Sep 2015 17:03:01 -0300
So the fix then is to invert the initialization order inside
register_pernet_subsys() so that the control socket is created by last
and also block socket creation if netns initialization wasn't yet
performed.
If we really need to we could make ->create() fail with -EAFNOSUPPORT
if kern==1 until the protocol is fully setup.
Or, instead of failing, we could make such ->create() calls block
until the control sock init is complete or fails.
I guess I should have written that paragraph in another order, perhaps like:
So the fix then is to deny any sctp socket creation until netns
initialization is sufficiently done. And due to that, we have to
initialize the control socket as last step in netns initialization, as
now it can't be created earlier anymore.
Is it clearer on the intention?
And my emphasis on userspace sockets was to highlight that a random user
could trigger it, but yes both users are affected by the issue.
Strictly speaking, we would have to block ->create() not until the
control socket init is done but until the protocol is fully loaded. Such
condition, with this patch, is after net->sctp.auto_asconf_splist is
initialized. But for blocking until instead of just denying, we would
need some other mechanism.
It would be better from the (sctp) user point of view but then such
solution may better belong to another layer instead and protect all
protocols at once. (I checked and couldn't find other protocols at risk
like sctp)
Given that the first ->create() blocks while the protocol code loads
it really wouldn't be right to error a subsequent ->create() because
the load hasn't completed.
Can't say I don't agree with you, but at the same time, there are other
temporary errors that can happen and that the user should just retry.
This would be just another condition in a trade off for avoiding complexity.
I hold a semaphore across sock_create_kern() because of issues with sctp.
(Current kernels are nowhere near as bad as really old ones though.)
Oh, that's not good to hear. I'll experiment with that later, try to
catch some bugs. :)
Marcelo
--
To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
