On Tue, Jan 29, 2019 at 4:20 PM Jens Axboe <axboe@xxxxxxxxx> wrote:
> On 1/29/19 4:58 AM, Arnd Bergmann wrote:
> > On Tue, Jan 29, 2019 at 7:30 AM Christoph Hellwig <hch@xxxxxx> wrote:
> >>> On Mon, Jan 28, 2019 at 11:25:12AM -0700, Jens Axboe wrote:
> >>>> Especially with poll support now in the series, don't we need a ѕigmask
> >>>> argument similar to pselect/ppoll/io_pgetevents now to deal with signal
> >>>> blocking during waiting for events?
> >>>
> >>> Is there any way to avoid passing in the sigset_t size? If it's just a
> >>> 32-bit/64-bit thing, surely the in_compat_syscall() could cover it? Or
> >>> are there other cases that need to be catered to?
> >>
> >> As far as I can tell we never look at it, never looked at it and don't
> >> have any plans to look at it anytime soon. But when I tried to omit
> >> it for io_pgetevents I got stong pushback and thus had to add the
> >> crazy double indirection calling convention.
>
> That's good info. I am currently using set_user_sigmask() for it.
> I'd really like to avoid having to pass in a sigset_t size for the
> system call, however.
I really wouldn't do it, given that all other signal handling interfaces
are prepared for longer signal masks. You /could/ probably extend
it later with a flags bit to signify a longer mask instead of using
the entire register to hold the bit length, it just seems really
inconsistent with all other system calls.
Arnd
> What's the best way of achieving that? Can I get
> away with doing something like this:
>
> if (in_compat_syscall()) {
> const compat_sigset_t __user *compat_sig;
>
> compat_sig = (const compat_sigset_t __user *) sig;
> ret = set_compat_user_sigmask(compat_sig, &ksigmask,
> &sigsaved, _NSIG_WORDS);
> } else {
> ret = set_user_sigmask(sig, &ksigmask, &sigsaved,
> _NSIG_WORDS);
> }
