user/sven/linux.git, branch v2.6.35.10

Release 2.6.35.10

2010-12-14T22:40:18Z

Signed-off-by: Andi Kleen

Fix pktcdvd ioctl dev_minor range check

2010-12-14T22:40:18Z

Upstream 252a52aa4fa22a668f019e55b3aac3ff71ec1c29 The PKT_CTRL_CMD_STATUS device ioctl retrieves a pointer to a pktcdvd_device from the global pkt_devs array. The index into this array is provided directly by the user and is a signed integer, so the comparison to ensure that it falls within the bounds of this array will fail when provided with a negative index. This can be used to read arbitrary kernel memory or cause a crash due to an invalid pointer dereference. This can be exploited by users with permission to open /dev/pktcdvd/control (on many distributions, this is readable by group "cdrom"). Signed-off-by: Dan Rosenberg [ Rather than add a cast, just make the function take the right type -Linus ] Signed-off-by: Linus Torvalds Signed-off-by: Andi Kleen

Un-inline get_pipe_info() helper function

2010-12-14T22:40:18Z

commit 72083646528d4887b920deb71b37e09bc7d227bb upstream. This avoids some include-file hell, and the function isn't really important enough to be inlined anyway. Reported-by: Ingo Molnar Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

Export 'get_pipe_info()' to other users

2010-12-14T22:40:18Z

commit c66fb347946ebdd5b10908866ecc9fa05ee2cf3d upstream. And in particular, use it in 'pipe_fcntl()'. The other pipe functions do not need to use the 'careful' version, since they are only ever called for things that are already known to be pipes. The normal read/write/ioctl functions are called through the file operations structures, so if a file isn't a pipe, they'd never get called. But pipe_fcntl() is special, and called directly from the generic fcntl code, and needs to use the same careful function that the splice code is using. Cc: Jens Axboe Cc: Andrew Morton Cc: Al Viro Cc: Dave Jones Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

Rename 'pipe_info()' to 'get_pipe_info()'

2010-12-14T22:40:18Z

commit 71993e62a47dabddf10302807d6aa260455503f4 upstream. .. and change it to take the 'file' pointer instead of an inode, since that's what all users want anyway. The renaming is preparatory to exporting it to other users. The old 'pipe_info()' name was too generic and is already used elsewhere, so before making the function public we need to use a more specific name. Cc: Jens Axboe Cc: Andrew Morton Cc: Al Viro Cc: Dave Jones Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

nmi: fix clock comparator revalidation

2010-12-14T22:40:18Z

commit e8129c642155616d9e2160a75f103e127c8c3708 upstream. On each machine check all registers are revalidated. The save area for the clock comparator however only contains the upper most seven bytes of the former contents, if valid. Therefore the machine check handler uses a store clock instruction to get the current time and writes that to the clock comparator register which in turn will generate an immediate timer interrupt. However within the lowcore the expected time of the next timer interrupt is stored. If the interrupt happens before that time the handler won't be called. In turn the clock comparator won't be reprogrammed and therefore the interrupt condition stays pending which causes an interrupt loop until the expected time is reached. On NOHZ machines this can result in unresponsive machines since the time of the next expected interrupted can be a couple of days in the future. To fix this just revalidate the clock comparator register with the expected value. In addition the special handling for udelay must be changed as well. Signed-off-by: Heiko Carstens Signed-off-by: Martin Schwidefsky Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

r8169: fix checksum broken

2010-12-14T22:40:18Z

commit d5d3ebe3be5c5123f2d444e186717f45284151e2 upstream. If r8196 received packets with invalid sctp/igmp(not tcp, udp) checksum, r8196 set skb->ip_summed wit CHECKSUM_UNNECESSARY. This cause that upper protocol don't check checksum field. I am not family with r8196 driver. I try to guess the meaning of RxProtoIP and IPFail. RxProtoIP stands for received IPv4 packet that upper protocol is not tcp and udp. !(opts1 & IPFail) is true means that driver correctly to check checksum in IPv4 header. If it's right, I think we should not set ip_summed wit CHECKSUM_UNNECESSARY for my sctp packets with invalid checksum. If it's not right, please tell me. Signed-off-by: Shan Wei Acked-by: Francois Romieu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

r8169: (re)init phy on resume

2010-12-14T22:40:18Z

commit fccec10b33503a2b1197c8e7a3abd30443bedb08 upstream. Fix switching device to low-speed mode after resume reported in: https://bugzilla.redhat.com/show_bug.cgi?id=502974 Reported-and-tested-by: Laurentiu Badea Signed-off-by: Stanislaw Gruszka Signed-off-by: David S. Miller Cc: Francois Romieu Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

r8169: fix rx checksum offload

2010-12-14T22:40:18Z

commit adea1ac7effbddbe60a9de6d63462bfe79289e59 upstream. While porting GRO to r8169, I found this driver has a bug in its rx path. All skbs given to network stack had their ip_summed set to CHECKSUM_NONE, while hardware said they had correct TCP/UDP checksums. The reason is driver sets skb->ip_summed on the original skb before the copy eventually done by copybreak. The fresh skb gets the ip_summed = CHECKSUM_NONE value, forcing network stack to recompute checksum, and preventing my GRO patch to work. Fix is to make the ip_summed setting after skb copy. Note : rx_copybreak current value is 16383, so all frames are copied... Signed-off-by: Eric Dumazet Acked-by: Francois Romieu Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen

cfg80211: fix extension channel checks to initiate communication

2010-12-14T22:40:18Z

commit 9236d838c920e90708570d9bbd7bb82d30a38130 upstream. When operating in a mode that initiates communication and using HT40 we should fail if we cannot use both primary and secondary channels to initiate communication. Our current ht40 allowmap only covers STA mode of operation, for beaconing modes we need a check on the fly as the mode of operation is dynamic and there other flags other than disable which we should read to check if we can initiate communication. Do not allow for initiating communication if our secondary HT40 channel has is either disabled, has a passive scan flag, a no-ibss flag or is a radar channel. Userspace now has similar checks but this is also needed in-kernel. Reported-by: Jouni Malinen Signed-off-by: Luis R. Rodriguez Signed-off-by: John W. Linville Signed-off-by: Greg Kroah-Hartman Signed-off-by: Andi Kleen