Re: [RFC][PATCH 3/7][v4] Define siginfo_from_ancestor_ns()

From: Sukadev Bhattiprolu
Date: Wed Dec 24 2008 - 16:26:51 EST


Oleg Nesterov [oleg@xxxxxxxxxx] 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 ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/