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]

Date:   Tue, 9 Jan 2018 09:24:47 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     James Simmons <jsimmons@...radead.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 06:04:33PM +0000, James Simmons wrote:
> 
> > 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. 

And how in the world am I supposed to know that your work is somehow
better than his?  I don't see your work in my inbox at all, so am I
supposed to just guess?

Come on, you all know how kernel development works, and it sure isn't
this way.

> > 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.

reverts are trivial, delaying patch acceptance for no good reason is
not.

thanks,

greg k-h