Philippe Gerum wrote: > Jan Kiszka wrote: > >> Philippe Gerum wrote: >> >>> Jan Kiszka wrote: >>> >>>> Jan Kiszka wrote: >>>> >>>> >>>>> ... >>>>> A patch says more than thousand words. ;) >>>>> >>>>> As a first approach, I picked the second variant and implemented a new >>>>> function called rt_pipe_setpool. I also had to extend rt_pipe_alloc >>>>> and >>>>> rt_pipe_free so that the right pool is used by them. >>>>> >>>> >>>> >>>> I thought about this variant again, and it seems to me rather unsafe in >>>> case some buffer allocation takes place between rt_pipe_create and >>>> rt_pipe_setpool. So, here is a patch which extends rt_pipe_create >>>> with a >>>> new argument poolsize instead. >>>> >>> >>> Yep, looks safer to me too. >>> >> >> >> Ok, I addressed most your comments, and here is round 2 of variant 2. >> The only question for me is if we should rt_pipe_create in kernel space >> from RT context with poolsize=0 if this is prevented effectively for >> userspace task? > > > This is not prevented for user-space, since there is an automatic switch > to secondary mode caused by the lostage exec bit.
That's what I meant. Anyway, this doesn't change the situation: rt_pipe_create is not called in primary context from userspace, so the questions if we should allow this for kernelspace and poolsize=0. > > So far, I deny any non-RT invocation. > >> > > You likely mean, any non-Linux invocation. > Of course, I did. Jan
signature.asc
Description: OpenPGP digital signature
