Oleg Nesterov wrote:
On 07/26, Pavel Emelyanov wrote:TODO: This is more an exploratory patch and modifies only interfaces necessary to implement correct signal semantics in pid namespaces. If the approach is feasible, we could consistently use 'kern_siginfo' in other signal interfaces and possibly in 'struct sigqueue'.We could modify dequeue_signal() to directly work with 'kern_siginfo' and remove dequeue_signal_kern_info().Well... I know, it is very easy to blame somebody else's patch, and probably my taste is not good... But honestly, I personally think this approach is a horror, and any alternative is better :) I'd rather change dequeue_signal() so that it takes "struct sigqueue *" parameter instead of "siginfo_t *", or add a new "int *flags". OK, this doesn't work anyway, we should do something different. Perhaps just do all checks on sender's side.
Yes. Signal handling in namespaces turned out to be the most complicated part of the set. I start thinking to drop this part till we have the "core" in -mm tree. Suka, what do you think?
It is a bit strange that this patch is 3/15, and the rest bits in 11/15, not very convenient for the review.
Well, I thought that a split like 1. patches for kernel to prepare it for the set 2. the set itself is the best to review. Maybe I was wrong, but how to make this then? E.g. I have a MS_KERNOUNT patch, but its changes are used *much* later.
Oleg.
Thanks, Pavel _______________________________________________ Devel mailing list [email protected] https://openvz.org/mailman/listinfo/devel
