~thopiekar/linux/+git/linux-stable:linux-2.6.35.y

Last commit made on 2011-08-01
Get this branch:
git clone -b linux-2.6.35.y https://git.launchpad.net/~thopiekar/linux/+git/linux-stable

Branch merges

Branch information

Name:
linux-2.6.35.y
Repository:
lp:~thopiekar/linux/+git/linux-stable

Recent commits

675f766... by Andi Kleen <email address hidden>

release 2.6.35.14

Signed-off-by: Andi Kleen <email address hidden>

ef0c3e7... by =?utf-8?q?Fernando_Luis_V=C3=A1zquez_Cao?= <email address hidden>

IGMP snooping: set mrouters_only flag for IPv6 traffic

[ upstream commit fc2af6c73fc9449cd5894a36bb76b8f8c0e49fd8 ]
 properly

Upon reception of a MGM report packet the kernel sets the mrouters_only flag
in a skb that is a clone of the original skb, which means that the bridge
loses track of MGM packets (cb buffers are tied to a specific skb and not
shared) and it ends up forwading join requests to the bridge interface.

This can cause unexpected membership timeouts and intermitent/permanent loss
of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:

    A snooping switch should forward IGMP Membership Reports only to
    those ports where multicast routers are attached.
    [...]
    Sending membership reports to other hosts can result, for IGMPv1
    and IGMPv2, in unintentionally preventing a host from joining a
    specific multicast group.

Signed-off-by: Fernando Luis Vazquez Cao <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>

8904f07... by =?utf-8?q?Fernando_Luis_V=C3=A1zquez_Cao?= <email address hidden>

IGMP snooping: set mrouters_only flag for IPv4 traffic

[ upstream commit 62b2bcb49cca72f6d3f39f831127a6ab315a475d ]
 properly

Upon reception of a IGMP/IGMPv2 membership report the kernel sets the
mrouters_only flag in a skb that may be a clone of the original skb, which
means that sometimes the bridge loses track of membership report packets (cb
buffers are tied to a specific skb and not shared) and it ends up forwading
join requests to the bridge interface.

This can cause unexpected membership timeouts and intermitent/permanent loss
of connectivity as described in RFC 4541 [2.1.1. IGMP Forwarding Rules]:

    A snooping switch should forward IGMP Membership Reports only to
    those ports where multicast routers are attached.
    [...]
    Sending membership reports to other hosts can result, for IGMPv1
    and IGMPv2, in unintentionally preventing a host from joining a
    specific multicast group.

Signed-off-by: Fernando Luis Vazquez Cao <email address hidden>
Tested-by: Hayato Kakuta <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>

ea626c8... by Thomas Graf <email address hidden>

ipv6: add special mode forwarding=2 to send RS while

[ upstream commit c3bccac2fa76f1619dfe4fb7b9bee69de7f066d8 ]
 configured as router

Similar to accepting router advertisement, the IPv6 stack does not send router
solicitations if forwarding is enabled.

This patch enables this behavior to be overruled by setting forwarding to the
special value 2.

Signed-off-by: Thomas Graf <email address hidden>
Signed-off-by: David S. Miller <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>

22950d2... by Suresh Siddha

x86, mtrr: lock stop machine during MTRR rendezvous sequence

[ upstream commit 6d3321e8e2b3bf6a5892e2ef673c7bf536e3f904 ]

MTRR rendezvous sequence using stop_one_cpu_nowait() can potentially
happen in parallel with another system wide rendezvous using
stop_machine(). This can lead to deadlock (The order in which
works are queued can be different on different cpu's. Some cpu's
will be running the first rendezvous handler and others will be running
the second rendezvous handler. Each set waiting for the other set to join
for the system wide rendezvous, leading to a deadlock).

MTRR rendezvous sequence is not implemented using stop_machine() as this
gets called both from the process context aswell as the cpu online paths
(where the cpu has not come online and the interrupts are disabled etc).
stop_machine() works with only online cpus.

For now, take the stop_machine mutex in the MTRR rendezvous sequence that
gets called from an online cpu (here we are in the process context
and can potentially sleep while taking the mutex). And the MTRR rendezvous
that gets triggered during cpu online doesn't need to take this stop_machine
lock (as the stop_machine() already ensures that there is no cpu hotplug
going on in parallel by doing get_online_cpus())

    TBD: Pursue a cleaner solution of extending the stop_machine()
         infrastructure to handle the case where the calling cpu is
         still not online and use this for MTRR rendezvous sequence.

fixes: https://bugzilla.novell.com/show_bug.cgi?id=672008

Reported-by: Vadim Kotelnikov <email address hidden>
Signed-off-by: Suresh Siddha <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>
Link: http://<email address hidden>
Cc: <email address hidden> # 2.6.35+, backport a week or two after this gets more testing in mainline
Signed-off-by: H. Peter Anvin <email address hidden>

552fe3d... by Ralf Baechle <email address hidden>

SERIAL: SC26xx: Fix link error.

[ upstream commit f2eb3cdf14457fccb14ae8c4d7d7cee088cd3957 ]

Kconfig allows enabling console support for the SC26xx driver even when
it's configured as a module resulting in a:

ERROR: "uart_console_device" [drivers/tty/serial/sc26xx.ko] undefined!

modpost error since the driver was merged in
eea63e0e8a60d00485b47fb6e75d9aa2566b989b [SC26XX: New serial driver for
SC2681 uarts] in 2.6.25. Fixed by only allowing console support to be
enabled if the driver is builtin.

Signed-off-by: Ralf Baechle <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Cc: <email address hidden>
Cc: stable <email address hidden>
Acked-by: Alan Cox <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>

507e949... by Mark Brown

ASoC: Ensure we delay long enough for WM8994 FLL to lock

[ upstream commit 8e9ddf811ba021506d2316fcfe619faa0ab3f567 ]
 when starting

This delay is very conservative.

Signed-off-by: Mark Brown <email address hidden>
Acked-by: Liam Girdwood <email address hidden>
Cc: <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>

64779cb... by Will Deacon

ARM: 6989/1: perf: do not start the PMU when no events are

[ upstream commit f4f38430c94c38187db73a2cf3892cc8b12a2713 ]
 present

armpmu_enable can be called in situations where no events are present
(for example, from the event rotation tick after a profiled task has
exited). In this case, we currently start the PMU anyway which may
leave it active inevitably without any events being monitored.

This patch adds a simple check to the enabling code so that we avoid
starting the PMU when no events are present.

Cc: <email address hidden>
Reported-by: Ashwin Chaugle <email address hidden>
Signed-off-by: Will Deacon <email address hidden>
Signed-off-by: Russell King <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>

2256865... by K Y Srinivasan

Staging: hv: netvsc: Fix a bug in accounting transmit slots

[ upstream commit 9079ce691255792009c446d8c3382507b8d38635 ]

The transmit slots were manipulated without proper locking. Fix this bug by
making the variable tracking the transmit slots atomic.

This patch should be ported to prior stable kernels 2.6.32 and later.

Signed-off-by: K. Y. Srinivasan <email address hidden>
Signed-off-by: Haiyang Zhang <email address hidden>
Signed-off-by: Hank Janssen <email address hidden>
Cc: stable <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>

8df2d58... by Vasily Kulikov

staging: comedi: fix infoleak to userspace

[ upstream commit 819cbb120eaec7e014e5abd029260db1ca8c5735 ]

driver_name and board_name are pointers to strings, not buffers of size
COMEDI_NAMELEN. Copying COMEDI_NAMELEN bytes of a string containing
less than COMEDI_NAMELEN-1 bytes would leak some unrelated bytes.

Signed-off-by: Vasiliy Kulikov <email address hidden>
Cc: stable <email address hidden>
Signed-off-by: Greg Kroah-Hartman <email address hidden>
Signed-off-by: Andi Kleen <email address hidden>