On Tue, Sep 01, 2020 at 10:24:11AM -0500, Scott Cheloha wrote:
> On Mon, Aug 17, 2020 at 05:55:34PM -0500, Scott Cheloha wrote:
> >
> > [...]
>
> Two week bump.
>
> In summary:
>
> - Merge the critical sections so that "timer swap" with setitimer(2)
> is atomic.
>
> - To do this, move
On Mon, Aug 17, 2020 at 05:55:34PM -0500, Scott Cheloha wrote:
>
> [...]
Two week bump.
In summary:
- Merge the critical sections so that "timer swap" with setitimer(2)
is atomic.
- To do this, move error-free operations into a common kernel
subroutine, setitimer(). Now we have one
On Mon, Aug 17, 2020 at 12:57:33PM -0600, Theo de Raadt wrote:
> Scott Cheloha wrote:
>
> > There is one behavior change: in the setitimer(2) swap case it is now
> > possible to EFAULT on copyout(9) *after* you have written the new
> > timer value and (possibly) started the ITIMER_REAL timeout.
Scott Cheloha wrote:
> There is one behavior change: in the setitimer(2) swap case it is now
> possible to EFAULT on copyout(9) *after* you have written the new
> timer value and (possibly) started the ITIMER_REAL timeout.
>
> For example, the following code now yields EFAULT even though a new
On Fri, Aug 14, 2020 at 06:11:25PM -0600, Theo de Raadt wrote:
> > It has occurred to me that we could do a trial copyout(9) in
> > sys_setitimer() before entering the critical section. This is a *bit*
> > wasteful, but is relatively inexpensive and narrows the behavior
> > change I mentioned
> It has occurred to me that we could do a trial copyout(9) in
> sys_setitimer() before entering the critical section. This is a *bit*
> wasteful, but is relatively inexpensive and narrows the behavior
> change I mentioned down to truly improbable cases involving multiple
> threads and munmap(2).
On Wed, Aug 12, 2020 at 01:58:08PM -0500, Scott Cheloha wrote:
>
> [...]
>
> There is one behavior change: in the setitimer(2) swap case it is now
> possible to EFAULT on copyout(9) *after* you have written the new
> timer value and (possibly) started the ITIMER_REAL timeout.
>
> For example,
Hi,
Things in getitimer(2) and setitimer(2) have been rearranged
adequately. Their critical sections are ready to be combined.
Merging these critical sections is necessary to make getitimer(2) and
setitimer(2) MP-safe. They are not ready to run without the kernel
lock just yet, but this diff
