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:   Thu, 5 Oct 2017 15:48:59 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Doug Ledford <dledford@...hat.com>
cc:     Kees Cook <keescook@...omium.org>, linux-kernel@...r.kernel.org,
        Faisal Latif <faisal.latif@...el.com>,
        Sean Hefty <sean.hefty@...el.com>,
        Hal Rosenstock <hal.rosenstock@...il.com>,
        linux-rdma@...r.kernel.org
Subject: Re: [PATCH] RDMA/nes: Convert timers to use timer_setup()

On Thu, 5 Oct 2017, Doug Ledford wrote:

> On 10/4/2017 8:45 PM, Kees Cook wrote:
> > In preparation for unconditionally passing the struct timer_list pointer to
> > all timer callbacks, switch to using the new timer_setup() and from_timer()
> > to pass the timer pointer explicitly. A pointer from nesadapter back to
> > nesdev was added.
> > 
> > Cc: Faisal Latif <faisal.latif@...el.com>
> > Cc: Doug Ledford <dledford@...hat.com>
> > Cc: Sean Hefty <sean.hefty@...el.com>
> > Cc: Hal Rosenstock <hal.rosenstock@...il.com>
> > Cc: linux-rdma@...r.kernel.org
> > Cc: Thomas Gleixner <tglx@...utronix.de>
> > Signed-off-by: Kees Cook <keescook@...omium.org>
> > ---
> > This requires commit 686fef928bba ("timer: Prepare to change timer
> > callback argument type") in v4.14-rc3, but should be otherwise
> > stand-alone.
> 
> What is your intention with this, and the other RDMA related, patches?
> Is it your intention that I should pick these up or is someone else
> supposed to (you sent it to linux-kernel and only Cc:ed linux-rdma)?
> Also, are you intending this to go into -rc?  If so, why is it dependent
> on a patch that didn't land until -rc3?

That's 4.15 material and should preferrably be picked up by the relevant
maintainers. The 4.14-rc3 reference is there just in case a maintainer tree
is based on pre 4.14-rc3, so applying the patch would break the build.

Thanks,

	tglx

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ