On 20 June 2013 09:38, Otto Moerbeek <[email protected]> wrote: > On Wed, Jun 19, 2013 at 07:39:15PM +0000, Miod Vallat wrote: > >> > > > - p->p_sigmask = mask &~ sigcantmask; >> > > > + p->p_sigmask = mask; >> > >> > On the right architecture where a word store isn't atomic enough and >> > with the right compiler that decides to put p_sigmask on an address >> > ending with 0xFFF with 4k-sized pages, we have two problems already. >> >> Holy Pumpkin forbid, struct proc layout is sane enough for fields to be >> aligned to their natural alignment, and the allocator will return >> properly aligned structs as well. >> >> > I'm only asking if such a situation can happen, or if there is some >> > ensure_this_assignment_is_always_atomic(&p->p_sigmask, mask); function >> > that I missed. >> >> If such a function exists, it should be shot, if only for having a too >> long name. >> >> Miod > > But watch out, as kettenis@ already mentioned elsewhere, this can only > be safe if *all* reads and modifications to the mask are done in an > atomic way. >
I think this is only changed on the context of curproc, so there will only be one dude modifying it at a time. Problem I see is if there is other code which reads p_sigmask twice, since it losed the atomicity between two reads, don't know what can happen. On a quick look it doesn't seem to happen. Also, is there any situation where reading the old value is not ok ? this would only happen if another cpu tries to check p_sigmask of something else than curproc. Anyway I don't know the code but it is worth looking. > Straight read and assignment of int values is safe, afaik, but e.g. > struct assignment and memcpy are *not* atomic. > > -Otto > >
