Oleg Nesterov [[email protected]] wrote:
| Small nit... siginfo_from_user() is only called by siginfo_from_ancestor_ns().
| The first helper depends on CONFIG_PID_NS, the second is not. A bit strange.
|
| Isn't it cleaner to do
|
| #ifdef CONFIG_PID_NS
| static inline int siginfo_from_user(siginfo_t *info)
| {
| ...
| }
| static inline int siginfo_from_ancestor_ns(...)
| {
| ...
| }
| #else
| static inline int siginfo_from_ancestor_ns(...)
| {
| return 0;
| }
| #endif
|
| ?
Yes, it was that way in the earlier version, but I thought we introduced
CONFIG_PID_NS only to hide the ugliness resulting from pid-ns. Ok. I
will revert.
|
| > +#ifdef CONFIG_PID_NS
| > +/*
| > + * siginfo_from_user() assumes that si_code SI_ASYNCIO comes only from
| > + * within the kernel. If an application is passing in SI_ASYNCIO we
| > + * want to know about it.
| > + */
| > +static void warn_on_asyncio(siginfo_t *info)
| > +{
| > + WARN_ON_ONCE(info->si_code == SI_ASYNCIO);
| > +}
| > +#else
| > +#define warn_on_asyncio(info) {}
| > +#endif
| > +
| > asmlinkage long
| > sys_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t __user *uinfo)
| > {
| > @@ -2324,6 +2388,9 @@ sys_rt_sigqueueinfo(pid_t pid, int sig, siginfo_t
__user *uinfo)
| > Nor can they impersonate a kill(), which adds source info. */
| > if (info.si_code >= 0)
| > return -EPERM;
| > +
| > + warn_on_asyncio(&info);
|
| Hmm... why do you want this? The user-space can use any si_code >= 0,
| why should we uglify the code?
I thought losing a SIGKILL, however twisted the path, was serious enough
to justify the ugliness. Again, I am not particular.
|
| And, SI_ASYNCIO only matters when we send the signal to the subnamespace,
| and in that case we will probably mangle .si_pid. So why don't we warn
| when .si_code == SI_USER?
I was wondering if I should there too :-) But what do you think ?
_______________________________________________
Containers mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers
_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel
