linux-kernel - Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1440712555.32300.112.camel@j-VirtualBox>
Date:	Thu, 27 Aug 2015 14:55:55 -0700
From:	Jason Low <jason.low2@...com>
To:	George Spelvin <linux@...izon.com>
Cc:	linux-kernel@...r.kernel.org, jason.low2@...com
Subject: Re: [PATCH 3/3] timer: Reduce unnecessary sighand lock contention

On Wed, 2015-08-26 at 21:28 -0400, George Spelvin wrote:
> > I can include your patch in the series and then use boolean for the new
> > checking_timer field. However, it looks like this applies on an old
> > kernel. For example, the spin_lock field has already been removed from
> > the structure.
> 
> Apologies; that was 4.1.6.  A 4.2-rc8 patch is appended (it's a pretty
> trivial merge once you look at it).

Frederic suggested that we just use a single "status" variable and
access the bits for the running and checking field. I am leaning towards
that method, so I might not include the rest of the boolean changes in
this patchset.

> > The spinlock call has already been removed from a previous patch. The
> > issue now is with contention with the sighand lock.
> 
> I'll look some more and try to wrap my head around it.
> 
> >> Or is it basically okay if this is massively racey, since process-wide
> >> CPU timers are inherently sloppy.  A race will just cause an expiration
> >> check to be missed, but it will be retried soon anyway.
> 
> > Yes, the worst case scenario is that we wait until the next thread to
> > come along and handle the next expired timer. However, this "delay"
> > already occurs now (for example: a timer can expire right after a thread
> > exits check_process_timers()).
> 
> Ad is this polled, or is there some non-polled system that will trigger
> another call to check_process_timers().
> 
> E.g. suppose a process fails to notice that it blew past a CPU time
> timeout before blocking.  Does anything guarantee that it will get
> the timeout signal in finite real time?

Yep, the check_process_timers will get called again during the next
scheduler interrupt (approximately after 1 jiffy) and send the signal if
it finds that the timer expired then.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/