* [PATCH 3.4 01/12] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-19 10:50 ` Luis Henriques
2013-11-18 18:41 ` [PATCH 3.4 02/12] xen-netback: use jiffies_64 value to calculate credit timeout Greg Kroah-Hartman
` (13 subsequent siblings)
14 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Ben Hutchings, David S. Miller
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ben Hutchings <ben@decadent.org.uk>
[ Upstream commit 262e827fe745642589450ae241b7afd3912c3f25 ]
The length calculation here is now invalid on 32-bit architectures,
since sk_buff::tail is a pointer and sk_buff::transport_header is
an integer offset:
drivers/net/ethernet/chelsio/cxgb3/sge.c: In function 'write_ofld_wr':
drivers/net/ethernet/chelsio/cxgb3/sge.c:1603:9: warning: passing argument 4 of 'make_sgl' makes integer from pointer without a cast [enabled by default]
adap->pdev);
^
drivers/net/ethernet/chelsio/cxgb3/sge.c:964:28: note: expected 'unsigned int' but argument is of type 'sk_buff_data_t'
static inline unsigned int make_sgl(const struct sk_buff *skb,
^
Use the appropriate skb accessor functions.
Compile-tested only.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Fixes: 1a37e412a022 ('net: Use 16bits for *_headers fields of struct skbuff')
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/ethernet/chelsio/cxgb3/sge.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
+++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
@@ -1600,7 +1600,8 @@ static void write_ofld_wr(struct adapter
flits = skb_transport_offset(skb) / 8;
sgp = ndesc == 1 ? (struct sg_ent *)&d->flit[flits] : sgl;
sgl_flits = make_sgl(skb, sgp, skb_transport_header(skb),
- skb->tail - skb->transport_header,
+ skb_tail_pointer(skb) -
+ skb_transport_header(skb),
adap->pdev);
if (need_skb_unmap()) {
setup_deferred_unmapping(skb, adap->pdev, sgp, sgl_flits);
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 3.4 01/12] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures
2013-11-18 18:41 ` [PATCH 3.4 01/12] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures Greg Kroah-Hartman
@ 2013-11-19 10:50 ` Luis Henriques
2013-11-19 23:09 ` Greg Kroah-Hartman
0 siblings, 1 reply; 22+ messages in thread
From: Luis Henriques @ 2013-11-19 10:50 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, stable, Ben Hutchings, David S. Miller
Hi Greg,
On Mon, Nov 18, 2013 at 10:41:34AM -0800, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
I guess you can drop this commit because, as Ben has already pointed
out, it is required for kernels >= 3.11.
Cheers,
--
Luis
> ------------------
>
> From: Ben Hutchings <ben@decadent.org.uk>
>
> [ Upstream commit 262e827fe745642589450ae241b7afd3912c3f25 ]
>
> The length calculation here is now invalid on 32-bit architectures,
> since sk_buff::tail is a pointer and sk_buff::transport_header is
> an integer offset:
>
> drivers/net/ethernet/chelsio/cxgb3/sge.c: In function 'write_ofld_wr':
> drivers/net/ethernet/chelsio/cxgb3/sge.c:1603:9: warning: passing argument 4 of 'make_sgl' makes integer from pointer without a cast [enabled by default]
> adap->pdev);
> ^
> drivers/net/ethernet/chelsio/cxgb3/sge.c:964:28: note: expected 'unsigned int' but argument is of type 'sk_buff_data_t'
> static inline unsigned int make_sgl(const struct sk_buff *skb,
> ^
>
> Use the appropriate skb accessor functions.
>
> Compile-tested only.
>
> Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
> Fixes: 1a37e412a022 ('net: Use 16bits for *_headers fields of struct skbuff')
> Signed-off-by: David S. Miller <davem@davemloft.net>
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> ---
> drivers/net/ethernet/chelsio/cxgb3/sge.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- a/drivers/net/ethernet/chelsio/cxgb3/sge.c
> +++ b/drivers/net/ethernet/chelsio/cxgb3/sge.c
> @@ -1600,7 +1600,8 @@ static void write_ofld_wr(struct adapter
> flits = skb_transport_offset(skb) / 8;
> sgp = ndesc == 1 ? (struct sg_ent *)&d->flit[flits] : sgl;
> sgl_flits = make_sgl(skb, sgp, skb_transport_header(skb),
> - skb->tail - skb->transport_header,
> + skb_tail_pointer(skb) -
> + skb_transport_header(skb),
> adap->pdev);
> if (need_skb_unmap()) {
> setup_deferred_unmapping(skb, adap->pdev, sgp, sgl_flits);
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe stable" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 3.4 01/12] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures
2013-11-19 10:50 ` Luis Henriques
@ 2013-11-19 23:09 ` Greg Kroah-Hartman
2013-11-20 4:53 ` Guenter Roeck
0 siblings, 1 reply; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-19 23:09 UTC (permalink / raw)
To: Luis Henriques; +Cc: linux-kernel, stable, Ben Hutchings, David S. Miller
On Tue, Nov 19, 2013 at 10:50:00AM +0000, Luis Henriques wrote:
> Hi Greg,
>
> On Mon, Nov 18, 2013 at 10:41:34AM -0800, Greg Kroah-Hartman wrote:
> > 3.4-stable review patch. If anyone has any objections, please let me know.
> >
>
> I guess you can drop this commit because, as Ben has already pointed
> out, it is required for kernels >= 3.11.
Good point, now dropped, thanks.
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3.4 01/12] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures
2013-11-19 23:09 ` Greg Kroah-Hartman
@ 2013-11-20 4:53 ` Guenter Roeck
0 siblings, 0 replies; 22+ messages in thread
From: Guenter Roeck @ 2013-11-20 4:53 UTC (permalink / raw)
To: Greg Kroah-Hartman, Luis Henriques
Cc: linux-kernel, stable, Ben Hutchings, David S. Miller
On 11/19/2013 03:09 PM, Greg Kroah-Hartman wrote:
> On Tue, Nov 19, 2013 at 10:50:00AM +0000, Luis Henriques wrote:
>> Hi Greg,
>>
>> On Mon, Nov 18, 2013 at 10:41:34AM -0800, Greg Kroah-Hartman wrote:
>>> 3.4-stable review patch. If anyone has any objections, please let me know.
>>>
>>
>> I guess you can drop this commit because, as Ben has already pointed
>> out, it is required for kernels >= 3.11.
>
> Good point, now dropped, thanks.
>
No negative impact on builds:
total: 103 pass: 89 skipped: 10 fail: 4
qemu tests still pass.
Guenter
^ permalink raw reply [flat|nested] 22+ messages in thread
* [PATCH 3.4 02/12] xen-netback: use jiffies_64 value to calculate credit timeout
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 01/12] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 03/12] net: flow_dissector: fail on evil iph->ihl Greg Kroah-Hartman
` (12 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jan Beulich, Wei Liu, David Vrabel,
Ian Campbell, Jason Luan, David S. Miller
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Wei Liu <wei.liu2@citrix.com>
[ Upstream commit 059dfa6a93b779516321e5112db9d7621b1367ba ]
time_after_eq() only works if the delta is < MAX_ULONG/2.
For a 32bit Dom0, if netfront sends packets at a very low rate, the time
between subsequent calls to tx_credit_exceeded() may exceed MAX_ULONG/2
and the test for timer_after_eq() will be incorrect. Credit will not be
replenished and the guest may become unable to send packets (e.g., if
prior to the long gap, all credit was exhausted).
Use jiffies_64 variant to mitigate this problem for 32bit Dom0.
Suggested-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Jason Luan <jianhai.luan@oracle.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/net/xen-netback/common.h | 1 +
drivers/net/xen-netback/interface.c | 3 +--
drivers/net/xen-netback/netback.c | 10 +++++-----
3 files changed, 7 insertions(+), 7 deletions(-)
--- a/drivers/net/xen-netback/common.h
+++ b/drivers/net/xen-netback/common.h
@@ -88,6 +88,7 @@ struct xenvif {
unsigned long credit_usec;
unsigned long remaining_credit;
struct timer_list credit_timeout;
+ u64 credit_window_start;
/* Statistics */
unsigned long rx_gso_checksum_fixup;
--- a/drivers/net/xen-netback/interface.c
+++ b/drivers/net/xen-netback/interface.c
@@ -273,8 +273,7 @@ struct xenvif *xenvif_alloc(struct devic
vif->credit_bytes = vif->remaining_credit = ~0UL;
vif->credit_usec = 0UL;
init_timer(&vif->credit_timeout);
- /* Initialize 'expires' now: it's used to track the credit window. */
- vif->credit_timeout.expires = jiffies;
+ vif->credit_window_start = get_jiffies_64();
dev->netdev_ops = &xenvif_netdev_ops;
dev->hw_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_TSO;
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1197,9 +1197,8 @@ out:
static bool tx_credit_exceeded(struct xenvif *vif, unsigned size)
{
- unsigned long now = jiffies;
- unsigned long next_credit =
- vif->credit_timeout.expires +
+ u64 now = get_jiffies_64();
+ u64 next_credit = vif->credit_window_start +
msecs_to_jiffies(vif->credit_usec / 1000);
/* Timer could already be pending in rare cases. */
@@ -1207,8 +1206,8 @@ static bool tx_credit_exceeded(struct xe
return true;
/* Passed the point where we can replenish credit? */
- if (time_after_eq(now, next_credit)) {
- vif->credit_timeout.expires = now;
+ if (time_after_eq64(now, next_credit)) {
+ vif->credit_window_start = now;
tx_add_credit(vif);
}
@@ -1220,6 +1219,7 @@ static bool tx_credit_exceeded(struct xe
tx_credit_callback;
mod_timer(&vif->credit_timeout,
next_credit);
+ vif->credit_window_start = next_credit;
return true;
}
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 03/12] net: flow_dissector: fail on evil iph->ihl
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 01/12] cxgb3: Fix length calculation in write_ofld_wr() on 32-bit architectures Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 02/12] xen-netback: use jiffies_64 value to calculate credit timeout Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 04/12] PCI: fix truncation of resource size to 32 bits Greg Kroah-Hartman
` (11 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Jason Wang, Eric Dumazet,
Petr Matousek, Michael S. Tsirkin, Daniel Borkmann,
David S. Miller
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Jason Wang <jasowang@redhat.com>
[ Upstream commit 6f092343855a71e03b8d209815d8c45bf3a27fcd ]
We don't validate iph->ihl which may lead a dead loop if we meet a IPIP
skb whose iph->ihl is zero. Fix this by failing immediately when iph->ihl
is evil (less than 5).
This issue were introduced by commit ec5efe7946280d1e84603389a1030ccec0a767ae
(rps: support IPIP encapsulation).
Signed-off-by: Jason Wang <jasowang@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Petr Matousek <pmatouse@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Cc: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/core/flow_dissector.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/core/flow_dissector.c
+++ b/net/core/flow_dissector.c
@@ -35,7 +35,7 @@ again:
struct iphdr _iph;
ip:
iph = skb_header_pointer(skb, nhoff, sizeof(_iph), &_iph);
- if (!iph)
+ if (!iph || iph->ihl < 5)
return false;
if (ip_is_fragment(iph))
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 04/12] PCI: fix truncation of resource size to 32 bits
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (2 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 03/12] net: flow_dissector: fail on evil iph->ihl Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 05/12] USB: add new zte 3g-dongles pid to option.c Greg Kroah-Hartman
` (10 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nikhil P Rao, Bjorn Helgaas,
Jiri Slaby
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nikhil P Rao <nikhil.rao@intel.com>
commit d6776e6d5c2f8db0252f447b09736075e1bbe387 upstream.
_pci_assign_resource() took an int "size" argument, which meant that
sizes larger than 4GB were truncated. Change type to resource_size_t.
[bhelgaas: changelog]
Signed-off-by: Nikhil P Rao <nikhil.rao@intel.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/setup-res.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -206,7 +206,8 @@ static int pci_revert_fw_address(struct
return ret;
}
-static int _pci_assign_resource(struct pci_dev *dev, int resno, int size, resource_size_t min_align)
+static int _pci_assign_resource(struct pci_dev *dev, int resno,
+ resource_size_t size, resource_size_t min_align)
{
struct resource *res = dev->resource + resno;
struct pci_bus *bus;
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 05/12] USB: add new zte 3g-dongles pid to option.c
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (3 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 04/12] PCI: fix truncation of resource size to 32 bits Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 06/12] ALSA: hda - Move one-time init codes from generic_hdmi_init() Greg Kroah-Hartman
` (9 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Rui li
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Rui li <li.rui27@zte.com.cn>
commit 0636fc507a976cdc40f21bdbcce6f0b98ff1dfe9 upstream.
Signed-off-by: Rui li <li.rui27@zte.com.cn>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/serial/option.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -1391,6 +1391,23 @@ static const struct usb_device_id option
.driver_info = (kernel_ulong_t)&net_intf2_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1426, 0xff, 0xff, 0xff), /* ZTE MF91 */
.driver_info = (kernel_ulong_t)&net_intf2_blacklist },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1533, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1534, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1535, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1545, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1546, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1547, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1565, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1566, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1567, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1589, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1590, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1591, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1592, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1594, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1596, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1598, 0xff, 0xff, 0xff) },
+ { USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1600, 0xff, 0xff, 0xff) },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x2002, 0xff,
0xff, 0xff), .driver_info = (kernel_ulong_t)&zte_k3765_z_blacklist },
{ USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x2003, 0xff, 0xff, 0xff) },
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 06/12] ALSA: hda - Move one-time init codes from generic_hdmi_init()
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (4 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 05/12] USB: add new zte 3g-dongles pid to option.c Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 07/12] netfilter: nf_ct_sip: dont drop packets with offsets pointing outside the packet Greg Kroah-Hartman
` (8 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Takashi Iwai, David Henningsson
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Takashi Iwai <tiwai@suse.de>
commit 8b8d654b55648561287bd8baca0f75f964a17038 upstream.
The codes to initialize work struct or create a proc interface should
be called only once and never although it's called many times through
the init callback. Move that stuff into patch_generic_hdmi() so that
it's called only once.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
BugLink: https://bugs.launchpad.net/bugs/1212160
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
sound/pci/hda/patch_hdmi.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
--- a/sound/pci/hda/patch_hdmi.c
+++ b/sound/pci/hda/patch_hdmi.c
@@ -1282,23 +1282,34 @@ static int generic_hdmi_build_controls(s
return 0;
}
-static int generic_hdmi_init(struct hda_codec *codec)
+static int generic_hdmi_init_per_pins(struct hda_codec *codec)
{
struct hdmi_spec *spec = codec->spec;
int pin_idx;
for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) {
struct hdmi_spec_per_pin *per_pin = &spec->pins[pin_idx];
- hda_nid_t pin_nid = per_pin->pin_nid;
struct hdmi_eld *eld = &per_pin->sink_eld;
- hdmi_init_pin(codec, pin_nid);
- snd_hda_jack_detect_enable(codec, pin_nid, pin_nid);
-
per_pin->codec = codec;
INIT_DELAYED_WORK(&per_pin->work, hdmi_repoll_eld);
snd_hda_eld_proc_new(codec, eld, pin_idx);
}
+ return 0;
+}
+
+static int generic_hdmi_init(struct hda_codec *codec)
+{
+ struct hdmi_spec *spec = codec->spec;
+ int pin_idx;
+
+ for (pin_idx = 0; pin_idx < spec->num_pins; pin_idx++) {
+ struct hdmi_spec_per_pin *per_pin = &spec->pins[pin_idx];
+ hda_nid_t pin_nid = per_pin->pin_nid;
+
+ hdmi_init_pin(codec, pin_nid);
+ snd_hda_jack_detect_enable(codec, pin_nid, pin_nid);
+ }
snd_hda_jack_report_sync(codec);
return 0;
}
@@ -1343,6 +1354,7 @@ static int patch_generic_hdmi(struct hda
return -EINVAL;
}
codec->patch_ops = generic_hdmi_patch_ops;
+ generic_hdmi_init_per_pins(codec);
init_channel_allocations();
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 07/12] netfilter: nf_ct_sip: dont drop packets with offsets pointing outside the packet
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (5 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 06/12] ALSA: hda - Move one-time init codes from generic_hdmi_init() Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 08/12] tracing: Fix potential out-of-bounds in trace_get_user() Greg Kroah-Hartman
` (7 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Patrick McHardy, Pablo Neira Ayuso,
William Roberts
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Patrick McHardy <kaber@trash.net>
commit 3a7b21eaf4fb3c971bdb47a98f570550ddfe4471 upstream.
Some Cisco phones create huge messages that are spread over multiple packets.
After calculating the offset of the SIP body, it is validated to be within
the packet and the packet is dropped otherwise. This breaks operation of
these phones. Since connection tracking is supposed to be passive, just let
those packets pass unmodified and untracked.
Signed-off-by: Patrick McHardy <kaber@trash.net>
Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: William Roberts <bill.c.roberts@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/netfilter/nf_conntrack_sip.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/net/netfilter/nf_conntrack_sip.c
+++ b/net/netfilter/nf_conntrack_sip.c
@@ -1468,7 +1468,7 @@ static int sip_help_tcp(struct sk_buff *
msglen = origlen = end - dptr;
if (msglen > datalen)
- return NF_DROP;
+ return NF_ACCEPT;
ret = process_sip_msg(skb, ct, dataoff, &dptr, &msglen);
if (ret != NF_ACCEPT)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 08/12] tracing: Fix potential out-of-bounds in trace_get_user()
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (6 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 07/12] netfilter: nf_ct_sip: dont drop packets with offsets pointing outside the packet Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 09/12] ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations Greg Kroah-Hartman
` (6 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Andrey Konovalov, Steven Rostedt
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Steven Rostedt <rostedt@goodmis.org>
commit 057db8488b53d5e4faa0cedb2f39d4ae75dfbdbb upstream.
Andrey reported the following report:
ERROR: AddressSanitizer: heap-buffer-overflow on address ffff8800359c99f3
ffff8800359c99f3 is located 0 bytes to the right of 243-byte region [ffff8800359c9900, ffff8800359c99f3)
Accessed by thread T13003:
#0 ffffffff810dd2da (asan_report_error+0x32a/0x440)
#1 ffffffff810dc6b0 (asan_check_region+0x30/0x40)
#2 ffffffff810dd4d3 (__tsan_write1+0x13/0x20)
#3 ffffffff811cd19e (ftrace_regex_release+0x1be/0x260)
#4 ffffffff812a1065 (__fput+0x155/0x360)
#5 ffffffff812a12de (____fput+0x1e/0x30)
#6 ffffffff8111708d (task_work_run+0x10d/0x140)
#7 ffffffff810ea043 (do_exit+0x433/0x11f0)
#8 ffffffff810eaee4 (do_group_exit+0x84/0x130)
#9 ffffffff810eafb1 (SyS_exit_group+0x21/0x30)
#10 ffffffff81928782 (system_call_fastpath+0x16/0x1b)
Allocated by thread T5167:
#0 ffffffff810dc778 (asan_slab_alloc+0x48/0xc0)
#1 ffffffff8128337c (__kmalloc+0xbc/0x500)
#2 ffffffff811d9d54 (trace_parser_get_init+0x34/0x90)
#3 ffffffff811cd7b3 (ftrace_regex_open+0x83/0x2e0)
#4 ffffffff811cda7d (ftrace_filter_open+0x2d/0x40)
#5 ffffffff8129b4ff (do_dentry_open+0x32f/0x430)
#6 ffffffff8129b668 (finish_open+0x68/0xa0)
#7 ffffffff812b66ac (do_last+0xb8c/0x1710)
#8 ffffffff812b7350 (path_openat+0x120/0xb50)
#9 ffffffff812b8884 (do_filp_open+0x54/0xb0)
#10 ffffffff8129d36c (do_sys_open+0x1ac/0x2c0)
#11 ffffffff8129d4b7 (SyS_open+0x37/0x50)
#12 ffffffff81928782 (system_call_fastpath+0x16/0x1b)
Shadow bytes around the buggy address:
ffff8800359c9700: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
ffff8800359c9780: fd fd fd fd fd fd fd fd fa fa fa fa fa fa fa fa
ffff8800359c9800: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
ffff8800359c9880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
ffff8800359c9900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>ffff8800359c9980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00[03]fb
ffff8800359c9a00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
ffff8800359c9a80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
ffff8800359c9b00: fa fa fa fa fa fa fa fa 00 00 00 00 00 00 00 00
ffff8800359c9b80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
ffff8800359c9c00: 00 00 00 00 00 00 00 00 fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap redzone: fa
Heap kmalloc redzone: fb
Freed heap region: fd
Shadow gap: fe
The out-of-bounds access happens on 'parser->buffer[parser->idx] = 0;'
Although the crash happened in ftrace_regex_open() the real bug
occurred in trace_get_user() where there's an incrementation to
parser->idx without a check against the size. The way it is triggered
is if userspace sends in 128 characters (EVENT_BUF_SIZE + 1), the loop
that reads the last character stores it and then breaks out because
there is no more characters. Then the last character is read to determine
what to do next, and the index is incremented without checking size.
Then the caller of trace_get_user() usually nulls out the last character
with a zero, but since the index is equal to the size, it writes a nul
character after the allocated space, which can corrupt memory.
Luckily, only root user has write access to this file.
Link: http://lkml.kernel.org/r/20131009222323.04fd1a0d@gandalf.local.home
Reported-by: Andrey Konovalov <andreyknvl@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
kernel/trace/trace.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -590,9 +590,12 @@ int trace_get_user(struct trace_parser *
if (isspace(ch)) {
parser->buffer[parser->idx] = 0;
parser->cont = false;
- } else {
+ } else if (parser->idx < parser->size - 1) {
parser->cont = true;
parser->buffer[parser->idx++] = ch;
+ } else {
+ ret = -EINVAL;
+ goto out;
}
*ppos += read;
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 09/12] ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (7 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 08/12] tracing: Fix potential out-of-bounds in trace_get_user() Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 10/12] ARM: 7670/1: fix the memset fix Greg Kroah-Hartman
` (5 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Ivan Djelic, Nicolas Pitre,
Dirk Behme, Russell King, Eric Bénard
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Ivan Djelic <ivan.djelic@parrot.com>
commit 455bd4c430b0c0a361f38e8658a0d6cb469942b5 upstream.
Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.
For instance in the following function:
void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
waiter->magic = waiter;
INIT_LIST_HEAD(&waiter->list);
}
compiled as:
800554d0 <debug_mutex_lock_common>:
800554d0: e92d4008 push {r3, lr}
800554d4: e1a00001 mov r0, r1
800554d8: e3a02010 mov r2, #16 ; 0x10
800554dc: e3a01011 mov r1, #17 ; 0x11
800554e0: eb04426e bl 80165ea0 <memset>
800554e4: e1a03000 mov r3, r0
800554e8: e583000c str r0, [r3, #12]
800554ec: e5830000 str r0, [r3]
800554f0: e5830004 str r0, [r3, #4]
800554f4: e8bd8008 pop {r3, pc}
GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.
This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:
Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).
Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:
save r8:
- str lr, [sp, #-4]!
+ stmfd sp!, {r8, lr}
and restore r8 on both exit paths:
- ldmeqfd sp!, {pc} @ Now <64 bytes to go.
+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
(...)
tst r2, #16
stmneia ip!, {r1, r3, r8, lr}
- ldr lr, [sp], #4
+ ldmfd sp!, {r8, lr}
Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:
save r8:
- stmfd sp!, {r4-r7, lr}
+ stmfd sp!, {r4-r8, lr}
and restore r8 on both exit paths:
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmeqfd sp!, {r4-r8, pc}
(...)
tst r2, #16
stmneia ip!, {r4-r7}
- ldmfd sp!, {r4-r7, lr}
+ ldmfd sp!, {r4-r8, lr}
Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".
Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/lib/memset.S | 85 +++++++++++++++++++++++++-------------------------
1 file changed, 44 insertions(+), 41 deletions(-)
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -19,9 +19,9 @@
1: subs r2, r2, #4 @ 1 do we have enough
blt 5f @ 1 bytes to align with?
cmp r3, #2 @ 1
- strltb r1, [r0], #1 @ 1
- strleb r1, [r0], #1 @ 1
- strb r1, [r0], #1 @ 1
+ strltb r1, [ip], #1 @ 1
+ strleb r1, [ip], #1 @ 1
+ strb r1, [ip], #1 @ 1
add r2, r2, r3 @ 1 (r2 = r2 - (4 - r3))
/*
* The pointer is now aligned and the length is adjusted. Try doing the
@@ -29,10 +29,14 @@
*/
ENTRY(memset)
- ands r3, r0, #3 @ 1 unaligned?
+/*
+ * Preserve the contents of r0 for the return value.
+ */
+ mov ip, r0
+ ands r3, ip, #3 @ 1 unaligned?
bne 1b @ 1
/*
- * we know that the pointer in r0 is aligned to a word boundary.
+ * we know that the pointer in ip is aligned to a word boundary.
*/
orr r1, r1, r1, lsl #8
orr r1, r1, r1, lsl #16
@@ -43,29 +47,28 @@ ENTRY(memset)
#if ! CALGN(1)+0
/*
- * We need an extra register for this loop - save the return address and
- * use the LR
+ * We need 2 extra registers for this loop - use r8 and the LR
*/
- str lr, [sp, #-4]!
- mov ip, r1
+ stmfd sp!, {r8, lr}
+ mov r8, r1
mov lr, r1
2: subs r2, r2, #64
- stmgeia r0!, {r1, r3, ip, lr} @ 64 bytes at a time.
- stmgeia r0!, {r1, r3, ip, lr}
- stmgeia r0!, {r1, r3, ip, lr}
- stmgeia r0!, {r1, r3, ip, lr}
+ stmgeia ip!, {r1, r3, r8, lr} @ 64 bytes at a time.
+ stmgeia ip!, {r1, r3, r8, lr}
+ stmgeia ip!, {r1, r3, r8, lr}
+ stmgeia ip!, {r1, r3, r8, lr}
bgt 2b
- ldmeqfd sp!, {pc} @ Now <64 bytes to go.
+ ldmeqfd sp!, {r8, pc} @ Now <64 bytes to go.
/*
* No need to correct the count; we're only testing bits from now on
*/
tst r2, #32
- stmneia r0!, {r1, r3, ip, lr}
- stmneia r0!, {r1, r3, ip, lr}
+ stmneia ip!, {r1, r3, r8, lr}
+ stmneia ip!, {r1, r3, r8, lr}
tst r2, #16
- stmneia r0!, {r1, r3, ip, lr}
- ldr lr, [sp], #4
+ stmneia ip!, {r1, r3, r8, lr}
+ ldmfd sp!, {r8, lr}
#else
@@ -74,54 +77,54 @@ ENTRY(memset)
* whole cache lines at once.
*/
- stmfd sp!, {r4-r7, lr}
+ stmfd sp!, {r4-r8, lr}
mov r4, r1
mov r5, r1
mov r6, r1
mov r7, r1
- mov ip, r1
+ mov r8, r1
mov lr, r1
cmp r2, #96
- tstgt r0, #31
+ tstgt ip, #31
ble 3f
- and ip, r0, #31
- rsb ip, ip, #32
- sub r2, r2, ip
- movs ip, ip, lsl #(32 - 4)
- stmcsia r0!, {r4, r5, r6, r7}
- stmmiia r0!, {r4, r5}
- tst ip, #(1 << 30)
- mov ip, r1
- strne r1, [r0], #4
+ and r8, ip, #31
+ rsb r8, r8, #32
+ sub r2, r2, r8
+ movs r8, r8, lsl #(32 - 4)
+ stmcsia ip!, {r4, r5, r6, r7}
+ stmmiia ip!, {r4, r5}
+ tst r8, #(1 << 30)
+ mov r8, r1
+ strne r1, [ip], #4
3: subs r2, r2, #64
- stmgeia r0!, {r1, r3-r7, ip, lr}
- stmgeia r0!, {r1, r3-r7, ip, lr}
+ stmgeia ip!, {r1, r3-r8, lr}
+ stmgeia ip!, {r1, r3-r8, lr}
bgt 3b
- ldmeqfd sp!, {r4-r7, pc}
+ ldmeqfd sp!, {r4-r8, pc}
tst r2, #32
- stmneia r0!, {r1, r3-r7, ip, lr}
+ stmneia ip!, {r1, r3-r8, lr}
tst r2, #16
- stmneia r0!, {r4-r7}
- ldmfd sp!, {r4-r7, lr}
+ stmneia ip!, {r4-r7}
+ ldmfd sp!, {r4-r8, lr}
#endif
4: tst r2, #8
- stmneia r0!, {r1, r3}
+ stmneia ip!, {r1, r3}
tst r2, #4
- strne r1, [r0], #4
+ strne r1, [ip], #4
/*
* When we get here, we've got less than 4 bytes to zero. We
* may have an unaligned pointer as well.
*/
5: tst r2, #2
- strneb r1, [r0], #1
- strneb r1, [r0], #1
+ strneb r1, [ip], #1
+ strneb r1, [ip], #1
tst r2, #1
- strneb r1, [r0], #1
+ strneb r1, [ip], #1
mov pc, lr
ENDPROC(memset)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 10/12] ARM: 7670/1: fix the memset fix
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (8 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 09/12] ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 11/12] PCI/PM: Clear state_saved during suspend Greg Kroah-Hartman
` (4 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Nicolas Pitre, Alexander Holler,
Russell King, Eric Bénard
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Nicolas Pitre <nicolas.pitre@linaro.org>
commit 418df63adac56841ef6b0f1fcf435bc64d4ed177 upstream.
Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value. However the memset itself became broken
by that patch for misaligned pointers.
This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.
Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.
While at it, the entry instructions are slightly reworked to help dual
issue pipelines.
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
arch/arm/lib/memset.S | 33 +++++++++++++--------------------
1 file changed, 13 insertions(+), 20 deletions(-)
--- a/arch/arm/lib/memset.S
+++ b/arch/arm/lib/memset.S
@@ -14,31 +14,15 @@
.text
.align 5
- .word 0
-
-1: subs r2, r2, #4 @ 1 do we have enough
- blt 5f @ 1 bytes to align with?
- cmp r3, #2 @ 1
- strltb r1, [ip], #1 @ 1
- strleb r1, [ip], #1 @ 1
- strb r1, [ip], #1 @ 1
- add r2, r2, r3 @ 1 (r2 = r2 - (4 - r3))
-/*
- * The pointer is now aligned and the length is adjusted. Try doing the
- * memset again.
- */
ENTRY(memset)
-/*
- * Preserve the contents of r0 for the return value.
- */
- mov ip, r0
- ands r3, ip, #3 @ 1 unaligned?
- bne 1b @ 1
+ ands r3, r0, #3 @ 1 unaligned?
+ mov ip, r0 @ preserve r0 as return value
+ bne 6f @ 1
/*
* we know that the pointer in ip is aligned to a word boundary.
*/
- orr r1, r1, r1, lsl #8
+1: orr r1, r1, r1, lsl #8
orr r1, r1, r1, lsl #16
mov r3, r1
cmp r2, #16
@@ -127,4 +111,13 @@ ENTRY(memset)
tst r2, #1
strneb r1, [ip], #1
mov pc, lr
+
+6: subs r2, r2, #4 @ 1 do we have enough
+ blt 5b @ 1 bytes to align with?
+ cmp r3, #2 @ 1
+ strltb r1, [ip], #1 @ 1
+ strleb r1, [ip], #1 @ 1
+ strb r1, [ip], #1 @ 1
+ add r2, r2, r3 @ 1 (r2 = r2 - (4 - r3))
+ b 1b
ENDPROC(memset)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 11/12] PCI/PM: Clear state_saved during suspend
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (9 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 10/12] ARM: 7670/1: fix the memset fix Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-18 18:41 ` [PATCH 3.4 12/12] usb: fix cleanup after failure in hub_configure() Greg Kroah-Hartman
` (3 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Bjorn Helgaas, Yijing Wang,
Konstantin Khlebnikov
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
commit 82fee4d67ab86d6fe5eb0f9a9e988ca9d654d765 upstream.
This patch clears pci_dev->state_saved at the beginning of suspending.
PCI config state may be saved long before that. Some drivers call
pci_save_state() from the ->probe() callback to get snapshot of sane
configuration space to use in the ->slot_reset() callback.
[wangyj: adjust context]
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org> # add comment
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Yijing Wang <wangyijing@huawei.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/pci/pci-driver.c | 4 ++++
1 file changed, 4 insertions(+)
--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -680,6 +680,7 @@ static int pci_pm_suspend(struct device
goto Fixup;
}
+ pci_dev->state_saved = false;
if (pm->suspend) {
pci_power_t prev = pci_dev->current_state;
int error;
@@ -826,6 +827,7 @@ static int pci_pm_freeze(struct device *
return 0;
}
+ pci_dev->state_saved = false;
if (pm->freeze) {
int error;
@@ -914,6 +916,7 @@ static int pci_pm_poweroff(struct device
goto Fixup;
}
+ pci_dev->state_saved = false;
if (pm->poweroff) {
int error;
@@ -1032,6 +1035,7 @@ static int pci_pm_runtime_suspend(struct
if (!pm || !pm->runtime_suspend)
return -ENOSYS;
+ pci_dev->state_saved = false;
error = pm->runtime_suspend(dev);
suspend_report_result(pm->runtime_suspend, error);
if (error)
^ permalink raw reply [flat|nested] 22+ messages in thread* [PATCH 3.4 12/12] usb: fix cleanup after failure in hub_configure()
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (10 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 11/12] PCI/PM: Clear state_saved during suspend Greg Kroah-Hartman
@ 2013-11-18 18:41 ` Greg Kroah-Hartman
2013-11-19 3:07 ` [PATCH 3.4 00/12] 3.4.70-stable review Guenter Roeck
` (2 subsequent siblings)
14 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-18 18:41 UTC (permalink / raw)
To: linux-kernel; +Cc: Greg Kroah-Hartman, stable, Krzysztof Mazur, Alan Stern
3.4-stable review patch. If anyone has any objections, please let me know.
------------------
From: Krzysztof Mazur <krzysiek@podlesie.net>
commit d0308d4b6b02597f39fc31a9bddf7bb3faad5622 upstream.
If the hub_configure() fails after setting the hdev->maxchild
the hub->ports might be NULL or point to uninitialized kzallocated
memory causing NULL pointer dereference in hub_quiesce() during cleanup.
Now after such error the hdev->maxchild is set to 0 to avoid cleanup
of uninitialized ports.
Signed-off-by: Krzysztof Mazur <krzysiek@podlesie.net>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/usb/core/hub.c | 1 +
1 file changed, 1 insertion(+)
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1335,6 +1335,7 @@ static int hub_configure(struct usb_hub
return 0;
fail:
+ hdev->maxchild = 0;
dev_err (hub_dev, "config failed, %s (err %d)\n",
message, ret);
/* hub_disconnect() frees urb and descriptor */
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 3.4 00/12] 3.4.70-stable review
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (11 preceding siblings ...)
2013-11-18 18:41 ` [PATCH 3.4 12/12] usb: fix cleanup after failure in hub_configure() Greg Kroah-Hartman
@ 2013-11-19 3:07 ` Guenter Roeck
2013-11-19 18:51 ` Greg Kroah-Hartman
2013-11-20 11:04 ` Satoru Takeuchi
2013-11-20 15:28 ` Shuah Khan
14 siblings, 1 reply; 22+ messages in thread
From: Guenter Roeck @ 2013-11-19 3:07 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable
On Mon, Nov 18, 2013 at 10:41:33AM -0800, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.70 release.
> There are 12 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Nov 20 18:41:11 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.70-rc1.gz
> and the diffstat can be found below.
>
Build test results:
total: 103 pass: 89 skipped: 10 fail: 4
qemu tests all pass.
Results match the results seen with the previous release and are as expected.
Guenter
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 3.4 00/12] 3.4.70-stable review
2013-11-19 3:07 ` [PATCH 3.4 00/12] 3.4.70-stable review Guenter Roeck
@ 2013-11-19 18:51 ` Greg Kroah-Hartman
0 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-19 18:51 UTC (permalink / raw)
To: Guenter Roeck; +Cc: linux-kernel, torvalds, akpm, stable
On Mon, Nov 18, 2013 at 07:07:29PM -0800, Guenter Roeck wrote:
> On Mon, Nov 18, 2013 at 10:41:33AM -0800, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.70 release.
> > There are 12 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Nov 20 18:41:11 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.70-rc1.gz
> > and the diffstat can be found below.
> >
>
> Build test results:
> total: 103 pass: 89 skipped: 10 fail: 4
>
> qemu tests all pass.
>
> Results match the results seen with the previous release and are as expected.
Thanks for testing all 4 of these and letting me know all is well.
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3.4 00/12] 3.4.70-stable review
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (12 preceding siblings ...)
2013-11-19 3:07 ` [PATCH 3.4 00/12] 3.4.70-stable review Guenter Roeck
@ 2013-11-20 11:04 ` Satoru Takeuchi
2013-11-20 16:28 ` Greg Kroah-Hartman
2013-11-20 15:28 ` Shuah Khan
14 siblings, 1 reply; 22+ messages in thread
From: Satoru Takeuchi @ 2013-11-20 11:04 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: linux-kernel, torvalds, akpm, stable
At Mon, 18 Nov 2013 10:41:33 -0800,
Greg Kroah-Hartman wrote:
>
> This is the start of the stable review cycle for the 3.4.70 release.
> There are 12 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Nov 20 18:41:11 UTC 2013.
> Anything received after that time might be too late.
This kernel can be built and boot without any problem.
Building a kernel with this kernel also works fine.
- Build Machine: debian jessy x86_64
CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
memory: 8GB
- Test machine: debian jessy x86_64(KVM guest on the Build Machine)
vCPU: x2
memory: 2GB
Thanks,
Satoru
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 3.4 00/12] 3.4.70-stable review
2013-11-20 11:04 ` Satoru Takeuchi
@ 2013-11-20 16:28 ` Greg Kroah-Hartman
0 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-20 16:28 UTC (permalink / raw)
To: Satoru Takeuchi; +Cc: linux-kernel, torvalds, akpm, stable
On Wed, Nov 20, 2013 at 08:04:45PM +0900, Satoru Takeuchi wrote:
> At Mon, 18 Nov 2013 10:41:33 -0800,
> Greg Kroah-Hartman wrote:
> >
> > This is the start of the stable review cycle for the 3.4.70 release.
> > There are 12 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Nov 20 18:41:11 UTC 2013.
> > Anything received after that time might be too late.
>
> This kernel can be built and boot without any problem.
> Building a kernel with this kernel also works fine.
>
> - Build Machine: debian jessy x86_64
> CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4
> memory: 8GB
>
> - Test machine: debian jessy x86_64(KVM guest on the Build Machine)
> vCPU: x2
> memory: 2GB
Thanks for testing this one, and the 3 others and letting me know they
all work.
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [PATCH 3.4 00/12] 3.4.70-stable review
2013-11-18 18:41 [PATCH 3.4 00/12] 3.4.70-stable review Greg Kroah-Hartman
` (13 preceding siblings ...)
2013-11-20 11:04 ` Satoru Takeuchi
@ 2013-11-20 15:28 ` Shuah Khan
2013-11-20 16:28 ` Greg Kroah-Hartman
14 siblings, 1 reply; 22+ messages in thread
From: Shuah Khan @ 2013-11-20 15:28 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-kernel
Cc: torvalds, akpm, stable, Shuah Khan, shuahkhan@gmail.com
On 11/18/2013 11:41 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.4.70 release.
> There are 12 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Nov 20 18:41:11 UTC 2013.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.70-rc1.gz
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
>
3.4.70:
patches applied cleanly
Compile test - passed
Boot tests - passed
dmesg regression tests - passed
[dmesgs look good. No regressions compared to the previous dmesgs for
this release. dmesg emerg, crit, alert, err are clean. No regressions in
warn.]
Cross-compile testing - limited tests passed (alpha, arm, arm64,
blackfin, c6x, powerpc, sh, sparc, tile)
Test systems:
Samsung Series 9 900X4C Intel Corei5 (3.4 and later)
HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile testing)
-- Shuah
--
Shuah Khan
Senior Linux Kernel Developer - Open Source Group
Samsung Research America(Silicon Valley)
shuah.kh@samsung.com | (970) 672-0658
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [PATCH 3.4 00/12] 3.4.70-stable review
2013-11-20 15:28 ` Shuah Khan
@ 2013-11-20 16:28 ` Greg Kroah-Hartman
0 siblings, 0 replies; 22+ messages in thread
From: Greg Kroah-Hartman @ 2013-11-20 16:28 UTC (permalink / raw)
To: Shuah Khan; +Cc: linux-kernel, torvalds, akpm, stable, shuahkhan@gmail.com
On Wed, Nov 20, 2013 at 08:28:34AM -0700, Shuah Khan wrote:
> On 11/18/2013 11:41 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.4.70 release.
> > There are 12 patches in this series, all will be posted as a response
> > to this one. If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Nov 20 18:41:11 UTC 2013.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.70-rc1.gz
> > and the diffstat can be found below.
> >
> > thanks,
> >
> > greg k-h
> >
>
> 3.4.70:
>
> patches applied cleanly
> Compile test - passed
> Boot tests - passed
>
> dmesg regression tests - passed
> [dmesgs look good. No regressions compared to the previous dmesgs for
> this release. dmesg emerg, crit, alert, err are clean. No regressions in
> warn.]
>
> Cross-compile testing - limited tests passed (alpha, arm, arm64,
> blackfin, c6x, powerpc, sh, sparc, tile)
>
> Test systems:
> Samsung Series 9 900X4C Intel Corei5 (3.4 and later)
> HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics
> HP Compaq dc7700 SFF desktop: x86-64 Intel Core-i2 (cross-compile testing)
Thanks for testing all 4 kernels and letting me know they work.
greg k-h
^ permalink raw reply [flat|nested] 22+ messages in thread