linux-kernel - Re: [PATCH 04/19] staging: lustre: discard cfs_time

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: <alpine.LFD.2.21.1801081708220.9942@casper.infradead.org>
Date:   Mon, 8 Jan 2018 18:04:33 +0000 (GMT)
From:   James Simmons <jsimmons@...radead.org>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc:     NeilBrown <neilb@...e.com>, Oleg Drokin <oleg.drokin@...el.com>,
        Andreas Dilger <andreas.dilger@...el.com>,
        lkml <linux-kernel@...r.kernel.org>,
        lustre <lustre-devel@...ts.lustre.org>
Subject: Re: [PATCH 04/19] staging: lustre: discard cfs_time_seconds()


> On Mon, Jan 08, 2018 at 04:52:35PM +0000, James Simmons wrote:
> > 
> > > cfs_time_seconds() converts a number of seconds to the
> > > matching number of jiffies.
> > > The standard way to do this in Linux is  "* HZ".
> > > So discard cfs_time_seconds() and use "* HZ" instead.
> >  
> > Just to make you aware I have been working for several months on 
> > moving lustre away from using jiffies as much as possible. The
> > problem with using HZ is that it can vary. So when you have a
> > parallel file system with batches of nodes that have different
> > values of HZ you can get very interesting corner cases. So I have
> > been moving everything over to time64_t and ktime. Also I mostly
> > have killed off the cfs_time_shift* and crap as well. You see all
> > work under https://jira.hpdd.intel.com/browse/LU-9019. So many
> > of the cases you did below don't event exist any more. I was
> > planning to push those changes after the next merge window.
> 
> First patch to me "wins", none of this "don't touch this code because
> I'm going to work on it in the future" stuff.  That has been documented
> to kill contributions and in one case, a whole opensource kernel
> project.
> 
> So Neil's patches should be evaluated first, don't develop behind closed
> walls like you are doing

What I'm saying is my work had been tested and various bugs have
been worked out before it gets to you. His work is new and untested. His 
work can be evaluated first but that doesn't mean it ready to land first. 
The wait event changes is a pretty big change that can have unseen 
consequences. 

> I've merged almost all of them now, except for the ones that broke the
> build :)

He just posted a updated the version of the l_wait_event changes a few 
hours ago based on feed back. Please give it more than a few hours to 
bake. I like to test them to make sure things don't break. I hate to 
find out it breaks things and have it reverted. Please.