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: <20121214.153825.1087482329989146130.davem@davemloft.net>
Date:	Fri, 14 Dec 2012 15:38:25 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	caiqian@...hat.com
Cc:	netdev@...r.kernel.org
Subject: Re: request to queue patches for stable

From: CAI Qian <caiqian@...hat.com>
Date: Mon, 10 Dec 2012 21:03:15 -0500 (EST)

> 
> 
> ----- Original Message -----
>> From: "David Miller" <davem@...emloft.net>
>> To: caiqian@...hat.com
>> Cc: greg@...ah.com, stable@...r.kernel.org, mbizon@...ebox.fr, ja@....bg
>> Sent: Friday, December 7, 2012 11:23:21 AM
>> Subject: Re: [PATCH] ipv4: do not cache looped multicasts
>> 
>> From: CAI Qian <caiqian@...hat.com>
>> Date: Thu, 6 Dec 2012 21:56:35 -0500 (EST)
>> 
>> > OK, I have a few network patches in the queue that looks applicable
>> > to
>> > the stable as well. I think I'll send them out here too to seek
>> > their
>> > ACKs. David, please let me know if I should stop doing this.
>> 
>> Please stop doing this.
>> 
>> If you want networking patches to reach stable, first
>> consult:
>> 
>> http://patchwork.ozlabs.org/bundle/davem/stable/
>> 
>> to see if the patch you want isn't queued up already.
>> 
>> If it is not, ask me to queue it up on netdev@...r.kernel.org
>> 
>> But note that I like to let networking patches "cook" upstream
>> in Linus's tree for a certain amount of time before I submit
>> them to -stable.  There can be up to even a week or two.
> Dave, the following patches looks applicable for the stable
> releases. Please queue them up if you agree.
> 
> 0e376bd0b791ac6ac6bdb051492df0769c840848 (for 3.0.x, 3.4.x and 3.6.x)
> e196c0e579902f42cf72414461fb034e5a1ffbf7 (for 3.0.x, 3.4.x and 3.6.x)
> 6e51fe7572590d8d86e93b547fab6693d305fd0d (for 3.0.x, 3.4.x and 3.6.x)
> e1a676424c290b1c8d757e3860170ac7ecd89af4 (for 3.6.x)
> 636174219b52b5a8bc51bc23bbcba97cd30a65e3 (for 3.6.x)

What is the point of my publishing the pending networking -stable
queue if you're not even going to check it?  Those last two patches
were already queued up.

Furthermore, it is erroneous to suggest the -ENOMEM SCTP fix without
the memory leak fix that happens in the commit right before it.

I've queued things up appropriately, but I really don't appreciate
how you've handled this at all.  It makes a lot more work for me than
necessary.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ