On 1/29/19 9:18 AM, Arnd Bergmann wrote: > 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. Damnit! OK, I'll keep what I currently have then. -- Jens Axboe
