linux-kernel - Re: [PATCH v2 0/2] enable hires timer to timeout datagram socket

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: <1504897909.15310.89.camel@edumazet-glaptop3.roam.corp.google.com>
Date:   Fri, 08 Sep 2017 12:11:49 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Eduardo Valentin <eduval@...zon.com>,
        Thomas Gleixner <tglx@...utronix.de>
Cc:     David Miller <davem@...emloft.net>, dwmw2@...radead.org,
        vallish@...zon.com, shuah@...nel.org, richardcochran@...il.com,
        xiyou.wangcong@...il.com, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org, anchalag@...zon.com, dwmw@...zon.com
Subject: Re: [PATCH v2 0/2] enable hires timer to timeout datagram socket

On Fri, 2017-09-08 at 11:55 -0700, Eduardo Valentin wrote:
> Hello,
> 
> On Fri, Sep 08, 2017 at 10:26:45AM -0700, David Miller wrote:
> > From: David Woodhouse <dwmw2@...radead.org>
> > Date: Fri, 08 Sep 2017 18:23:22 +0100
> > 
> > > I don't know that anyone's ever tried saying "show me the chapter
> and
> > > verse of the documentation"
> > 
> > Do you know why I brought this up?  Because the person I am replying
> > to told me that the syscall documentation should have suggested this
> > or that.
> > 
> > That's why.
> 
> :-) My intention was for sure not to upset anybody.
> 
> Just to reiterate, the point of patch is simple, there was a change in
> behavior in the system call from one kernel version to the other. As I
> mentioned, I agree that the userspace could use other means to achieve
> the same, but still the system call behavior has changed.
> 
> > 
> > So let's concentrate on the other aspects of my reply, ok?
> 
> I agree. I would prefer to understand here what is the technical
> reason not to accept these patches other than "use other system
> calls".

So if we need to replace all 'legacy' timers to high resolution timer,
because some application was _relying_ on jiffies being kind of precise,
maybe it is better to revert the change done on legacy timers.

Or continue the migration and make them use high res internally.

select() and poll() are the standard way to have precise timeouts,
it is silly we have to maintain a timeout handling in the datagram fast
path.