Home Home > GIT Browse
AgeCommit message (Collapse)Author
2012-04-27Linux 3.0.30v3.0.30Greg Kroah-Hartman
2012-04-27tcp: fix TCP_MAXSEG for established IPv6 passive socketsNeal Cardwell
[ Upstream commit d135c522f1234f62e81be29cebdf59e9955139ad ] Commit f5fff5d forgot to fix TCP_MAXSEG behavior IPv6 sockets, so IPv6 TCP server sockets that used TCP_MAXSEG would find that the advmss of child sockets would be incorrect. This commit mirrors the advmss logic from tcp_v4_syn_recv_sock in tcp_v6_syn_recv_sock. Eventually this logic should probably be shared between IPv4 and IPv6, but this at least fixes this issue. Signed-off-by: Neal Cardwell <ncardwell@google.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>
2012-04-27net ax25: Reorder ax25_exit to remove races.Eric W. Biederman
[ Upstream commit 3adadc08cc1e2cbcc15a640d639297ef5fcb17f5 ] While reviewing the sysctl code in ax25 I spotted races in ax25_exit where it is possible to receive notifications and packets after already freeing up some of the data structures needed to process those notifications and updates. Call unregister_netdevice_notifier early so that the rest of the cleanup code does not need to deal with network devices. This takes advantage of my recent enhancement to unregister_netdevice_notifier to send unregister notifications of all network devices that are current registered. Move the unregistration for packet types, socket types and protocol types before we cleanup any of the ax25 data structures to remove the possibilities of other races. Signed-off-by: Eric W. Biederman <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27ksz884x: don't copy too much in netdev_set_mac_address()Dan Carpenter
[ Upstream commit 716af4abd6e6370226f567af50bfaca274515980 ] MAX_ADDR_LEN is 32. ETH_ALEN is 6. mac->sa_data is a 14 byte array, so the memcpy() is doing a read past the end of the array. I asked about this on netdev and Ben Hutchings told me it's supposed to be copying ETH_ALEN bytes (thanks Ben). Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27netns: do not leak net_generic data on failed initJulian Anastasov
[ Upstream commit b922934d017f1cc831b017913ed7d1a56c558b43 ] ops_init should free the net_generic data on init failure and __register_pernet_operations should not call ops_free when NET_NS is not enabled. Signed-off-by: Julian Anastasov <ja@ssi.bg> Reviewed-by: "Eric W. Biederman" <ebiederm@xmission.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27tcp: fix tcp_grow_window() for large incoming framesEric Dumazet
[ Upstream commit 4d846f02392a710f9604892ac3329e628e60a230 ] tcp_grow_window() has to grow rcv_ssthresh up to window_clamp, allowing sender to increase its window. tcp_grow_window() still assumes a tcp frame is under MSS, but its no longer true with LRO/GRO. This patch fixes one of the performance issue we noticed with GRO on. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Tom Herbert <therbert@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27dummy: Add ndo_uninit().Hiroaki SHIMODA
[ Upstream commit 890fdf2a0cb88202d1427589db2cf29c1bdd3c1d ] In register_netdevice(), when ndo_init() is successful and later some error occurred, ndo_uninit() will be called. So dummy deivce is desirable to implement ndo_uninit() method to free percpu stats for this case. And, ndo_uninit() is also called along with dev->destructor() when device is unregistered, so in order to prevent dev->dstats from being freed twice, dev->destructor is modified to free_netdev(). Signed-off-by: Hiroaki SHIMODA <shimoda.hiroaki@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27net: usb: smsc75xx: fix mtuStephane Fillod
[ Upstream commit a99ff7d0123b19ecad3b589480b6542716ab6b52 ] Make smsc75xx recalculate the hard_mtu after adjusting the hard_header_len. Without this, usbnet adjusts the MTU down to 1492 bytes, and the host is unable to receive standard 1500-byte frames from the device. Inspired by same fix on cdc_eem 78fb72f7936c01d5b426c03a691eca082b03f2b9. Tested on ARM/Omap3 with EVB-LAN7500-LC. Signed-off-by: Stephane Fillod <fillods@users.sf.net> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27net_sched: gred: Fix oops in gred_dump() in WRED modeDavid Ward
[ Upstream commit 244b65dbfede788f2fa3fe2463c44d0809e97c6b ] A parameter set exists for WRED mode, called wred_set, to hold the same values for qavg and qidlestart across all VQs. The WRED mode values had been previously held in the VQ for the default DP. After these values were moved to wred_set, the VQ for the default DP was no longer created automatically (so that it could be omitted on purpose, to have packets in the default DP enqueued directly to the device without using RED). However, gred_dump() was overlooked during that change; in WRED mode it still reads qavg/qidlestart from the VQ for the default DP, which might not even exist. As a result, this command sequence will cause an oops: tc qdisc add dev $DEV handle $HANDLE parent $PARENT gred setup \ DPs 3 default 2 grio tc qdisc change dev $DEV handle $HANDLE gred DP 0 prio 8 $RED_OPTIONS tc qdisc change dev $DEV handle $HANDLE gred DP 1 prio 8 $RED_OPTIONS This fixes gred_dump() in WRED mode to use the values held in wred_set. Signed-off-by: David Ward <david.ward@ll.mit.edu> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27net/ethernet: ks8851_mll fix rx frame buffer overflowDavide Ciminaghi
[ Upstream commit 8a9a0ea6032186e3030419262678d652b88bf6a8 ] At the beginning of ks_rcv(), a for loop retrieves the header information relevant to all the frames stored in the mac's internal buffers. The number of pending frames is stored as an 8 bits field in KS_RXFCTR. If interrupts are disabled long enough to allow for more than 32 frames to accumulate in the MAC's internal buffers, a buffer overflow occurs. This patch fixes the problem by making the driver's frame_head_info buffer big enough. Well actually, since the chip appears to have 12K of internal rx buffers and the shortest ethernet frame should be 64 bytes long, maybe the limit could be set to 12*1024/64 = 192 frames, but 255 should be safer. Signed-off-by: Davide Ciminaghi <ciminaghi@gnudd.com> Signed-off-by: Raffaele Recalcati <raffaele.recalcati@bticino.it> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27net: smsc911x: fix skb handling in receive pathWill Deacon
[ Upstream commit 3c5e979bd037888dd7d722da22da4b43659af485 ] The SMSC911x driver resets the ->head, ->data and ->tail pointers in the skb on the reset path in order to avoid buffer overflow due to packet padding performed by the hardware. This patch fixes the receive path so that the skb pointers are fixed up after the data has been read from the device, The error path is also fixed to use number of words consistently and prevent erroneous FIFO fastforwarding when skipping over bad data. Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-278139cp: set intr mask after its handler is registeredJason Wang
[ Upstream commit a8c9cb106fe79c28d6b7f1397652cadd228715ff ] We set intr mask before its handler is registered, this does not work well when 8139cp is sharing irq line with other devices. As the irq could be enabled by the device before 8139cp's hander is registered which may lead unhandled irq. Fix this by introducing an helper cp_irq_enable() and call it after request_irq(). Signed-off-by: Jason Wang <jasowang@redhat.com> Reviewed-by: Flavio Leitner <fbl@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27atl1: fix kernel panic in case of DMA errorsTony Zelenoff
[ Upstream commit 03662e41c7cff64a776bfb1b3816de4be43de881 ] Problem: There was two separate work_struct structures which share one handler. Unfortunately getting atl1_adapter structure from work_struct in case of DMA error was done from incorrect offset which cause kernel panics. Solution: The useless work_struct for DMA error removed and handler name changed to more generic one. Signed-off-by: Tony Zelenoff <antonz@parallels.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27tcp: fix tcp_rcv_rtt_update() use of an unscaled RTT sampleNeal Cardwell
[ Upstream commit 18a223e0b9ec8979320ba364b47c9772391d6d05 ] Fix a code path in tcp_rcv_rtt_update() that was comparing scaled and unscaled RTT samples. The intent in the code was to only use the 'm' measurement if it was a new minimum. However, since 'm' had not yet been shifted left 3 bits but 'new_sample' had, this comparison would nearly always succeed, leading us to erroneously set our receive-side RTT estimate to the 'm' sample when that sample could be nearly 8x too high to use. The overall effect is to often cause the receive-side RTT estimate to be significantly too large (up to 40% too large for brief periods in my tests). Signed-off-by: Neal Cardwell <ncardwell@google.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>
2012-04-27net: fix a race in sock_queue_err_skb()Eric Dumazet
[ Upstream commit 110c43304db6f06490961529536c362d9ac5732f ] As soon as an skb is queued into socket error queue, another thread can consume it, so we are not allowed to reference skb anymore, or risk use after free. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27netlink: fix races after skb queueingEric Dumazet
[ Upstream commit 4a7e7c2ad540e54c75489a70137bf0ec15d3a127 ] As soon as an skb is queued into socket receive_queue, another thread can consume it, so we are not allowed to reference skb anymore, or risk use after free. Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27wimax: i2400m - prevent a possible kernel bug due to missing fw_name stringPhil Sutter
[ Upstream commit 4eee6a3a04e8bb53fbe7de0f64d0524d3fbe3f80 ] This happened on a machine with a custom hotplug script calling nameif, probably due to slow firmware loading. At the time nameif uses ethtool to gather interface information, i2400m->fw_name is zero and so a null pointer dereference occurs from within i2400m_get_drvinfo(). Signed-off-by: Phil Sutter <phil.sutter@viprinet.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27bonding: properly unset current_arp_slave on slave link upVeaceslav Falico
[ Upstream commit 5a4309746cd74734daa964acb02690c22b3c8911 ] When a slave comes up, we're unsetting the current_arp_slave without removing active flags from it, which can lead to situations where we have more than one slave with active flags in active-backup mode. To avoid this situation we must remove the active flags from a slave before removing it as a current_arp_slave. Signed-off-by: Veaceslav Falico <vfalico@redhat.com> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com> Signed-off-by: Andy Gospodarek <andy@greyhouse.net> Signed-off-by: Marcelo Ricardo Leitner <mleitner@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27phonet: Check input from user before allocatingSasha Levin
[ Upstream commit bcf1b70ac6eb0ed8286c66e6bf37cb747cbaa04c ] A phonet packet is limited to USHRT_MAX bytes, this is never checked during tx which means that the user can specify any size he wishes, and the kernel will attempt to allocate that size. In the good case, it'll lead to the following warning, but it may also cause the kernel to kick in the OOM and kill a random task on the server. [ 8921.744094] WARNING: at mm/page_alloc.c:2255 __alloc_pages_slowpath+0x65/0x730() [ 8921.749770] Pid: 5081, comm: trinity Tainted: G W 3.4.0-rc1-next-20120402-sasha #46 [ 8921.756672] Call Trace: [ 8921.758185] [<ffffffff810b2ba7>] warn_slowpath_common+0x87/0xb0 [ 8921.762868] [<ffffffff810b2be5>] warn_slowpath_null+0x15/0x20 [ 8921.765399] [<ffffffff8117eae5>] __alloc_pages_slowpath+0x65/0x730 [ 8921.769226] [<ffffffff81179c8a>] ? zone_watermark_ok+0x1a/0x20 [ 8921.771686] [<ffffffff8117d045>] ? get_page_from_freelist+0x625/0x660 [ 8921.773919] [<ffffffff8117f3a8>] __alloc_pages_nodemask+0x1f8/0x240 [ 8921.776248] [<ffffffff811c03e0>] kmalloc_large_node+0x70/0xc0 [ 8921.778294] [<ffffffff811c4bd4>] __kmalloc_node_track_caller+0x34/0x1c0 [ 8921.780847] [<ffffffff821b0e3c>] ? sock_alloc_send_pskb+0xbc/0x260 [ 8921.783179] [<ffffffff821b3c65>] __alloc_skb+0x75/0x170 [ 8921.784971] [<ffffffff821b0e3c>] sock_alloc_send_pskb+0xbc/0x260 [ 8921.787111] [<ffffffff821b002e>] ? release_sock+0x7e/0x90 [ 8921.788973] [<ffffffff821b0ff0>] sock_alloc_send_skb+0x10/0x20 [ 8921.791052] [<ffffffff824cfc20>] pep_sendmsg+0x60/0x380 [ 8921.792931] [<ffffffff824cb4a6>] ? pn_socket_bind+0x156/0x180 [ 8921.794917] [<ffffffff824cb50f>] ? pn_socket_autobind+0x3f/0x90 [ 8921.797053] [<ffffffff824cb63f>] pn_socket_sendmsg+0x4f/0x70 [ 8921.798992] [<ffffffff821ab8e7>] sock_aio_write+0x187/0x1b0 [ 8921.801395] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0 [ 8921.803501] [<ffffffff8111842c>] ? __lock_acquire+0x42c/0x4b0 [ 8921.805505] [<ffffffff821ab760>] ? __sock_recv_ts_and_drops+0x140/0x140 [ 8921.807860] [<ffffffff811e07cc>] do_sync_readv_writev+0xbc/0x110 [ 8921.809986] [<ffffffff811958e7>] ? might_fault+0x97/0xa0 [ 8921.811998] [<ffffffff817bd99e>] ? security_file_permission+0x1e/0x90 [ 8921.814595] [<ffffffff811e17e2>] do_readv_writev+0xe2/0x1e0 [ 8921.816702] [<ffffffff810b8dac>] ? do_setitimer+0x1ac/0x200 [ 8921.818819] [<ffffffff810e2ec1>] ? get_parent_ip+0x11/0x50 [ 8921.820863] [<ffffffff810e325e>] ? sub_preempt_count+0xae/0xf0 [ 8921.823318] [<ffffffff811e1926>] vfs_writev+0x46/0x60 [ 8921.825219] [<ffffffff811e1a3f>] sys_writev+0x4f/0xb0 [ 8921.827127] [<ffffffff82658039>] system_call_fastpath+0x16/0x1b [ 8921.829384] ---[ end trace dffe390f30db9eb7 ]--- Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Acked-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27ipv6: fix array index in ip6_mc_add_src()RongQing.Li
[ Upstream commit 78d50217baf36093ab320f95bae0d6452daec85c ] Convert array index from the loop bound to the loop index. And remove the void type conversion to ip6_mc_del1_src() return code, seem it is unnecessary, since ip6_mc_del1_src() does not use __must_check similar attribute, no compiler will report the warning when it is removed. v2: enrich the commit header Signed-off-by: RongQing.Li <roy.qing.li@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27bridge: Do not send queries on multicast group leavesHerbert Xu
[ Upstream commit 996304bbea3d2a094b7ba54c3bd65d3fffeac57b ] As it stands the bridge IGMP snooping system will respond to group leave messages with queries for remaining membership. This is both unnecessary and undesirable. First of all any multicast routers present should be doing this rather than us. What's more the queries that we send may end up upsetting other multicast snooping swithces in the system that are buggy. In fact, we can simply remove the code that send these queries because the existing membership expiry mechanism doesn't rely on them anyway. So this patch simply removes all code associated with group queries in response to group leave messages. Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27sctp: Allow struct sctp_event_subscribe to grow without breaking binariesThomas Graf
[ Upstream commit acdd5985364f8dc511a0762fab2e683f29d9d692 ] getsockopt(..., SCTP_EVENTS, ...) performs a length check and returns an error if the user provides less bytes than the size of struct sctp_event_subscribe. Struct sctp_event_subscribe needs to be extended by an u8 for every new event or notification type that is added. This obviously makes getsockopt fail for binaries that are compiled against an older versions of <net/sctp/user.h> which do not contain all event types. This patch changes getsockopt behaviour to no longer return an error if not enough bytes are being provided by the user. Instead, it returns as much of sctp_event_subscribe as fits into the provided buffer. This leads to the new behavior that users see what they have been aware of at compile time. The setsockopt(..., SCTP_EVENTS, ...) API is already behaving like this. Signed-off-by: Thomas Graf <tgraf@suug.ch> Acked-by: Vlad Yasevich <vladislav.yasevich@hp.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27tcp: allow splice() to build full TSO packetsEric Dumazet
[ This combines upstream commit 2f53384424251c06038ae612e56231b96ab610ee and the follow-on bug fix commit 35f9c09fe9c72eb8ca2b8e89a593e1c151f28fc2 ] vmsplice()/splice(pipe, socket) call do_tcp_sendpages() one page at a time, adding at most 4096 bytes to an skb. (assuming PAGE_SIZE=4096) The call to tcp_push() at the end of do_tcp_sendpages() forces an immediate xmit when pipe is not already filled, and tso_fragment() try to split these skb to MSS multiples. 4096 bytes are usually split in a skb with 2 MSS, and a remaining sub-mss skb (assuming MTU=1500) This makes slow start suboptimal because many small frames are sent to qdisc/driver layers instead of big ones (constrained by cwnd and packets in flight of course) In fact, applications using sendmsg() (adding an additional memory copy) instead of vmsplice()/splice()/sendfile() are a bit faster because of this anomaly, especially if serving small files in environments with large initial [c]wnd. Call tcp_push() only if MSG_MORE is not set in the flags parameter. This bit is automatically provided by splice() internals but for the last page, or on all pages if user specified SPLICE_F_MORE splice() flag. In some workloads, this can reduce number of sent logical packets by an order of magnitude, making zero-copy TCP actually faster than one-copy :) Reported-by: Tom Herbert <therbert@google.com> Cc: Nandita Dukkipati <nanditad@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Yuchung Cheng <ycheng@google.com> Cc: H.K. Jerry Chu <hkchu@google.com> Cc: Maciej Żenczykowski <maze@google.com> Cc: Mahesh Bandewar <maheshb@google.com> Cc: Ilpo Järvinen <ilpo.jarvinen@helsinki.fi> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27ppp: Don't stop and restart queue on every TX packetDavid Woodhouse
[ This combines upstream commit e675f0cc9a872fd152edc0c77acfed19bf28b81e and follow-on bug fix commit 9a5d2bd99e0dfe9a31b3c160073ac445ba3d773f ] For every transmitted packet, ppp_start_xmit() will stop the netdev queue and then, if appropriate, restart it. This causes the TX softirq to run, entirely gratuitously. This is "only" a waste of CPU time in the normal case, but it's actively harmful when the PPP device is a TEQL slave — the wakeup will cause the offending device to receive the next TX packet from the TEQL queue, when it *should* have gone to the next slave in the list. We end up seeing large bursts of packets on just *one* slave device, rather than using the full available bandwidth over all slaves. This patch fixes the problem by *not* unconditionally stopping the queue in ppp_start_xmit(). It adds a return value from ppp_xmit_process() which indicates whether the queue should be stopped or not. It *doesn't* remove the call to netif_wake_queue() from ppp_xmit_process(), because other code paths (especially from ppp_output_wakeup()) need it there and it's messy to push it out to the other callers to do it based on the return value. So we leave it in place — it's a no-op in the case where the queue wasn't stopped, so it's harmless in the TX path. Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27lockd: fix the endianness bugAl Viro
commit e847469bf77a1d339274074ed068d461f0c872bc upstream. comparing be32 values for < is not doing the right thing... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: "J. Bruce Fields" <bfields@fieldses.org> Cc: Trond Myklebust <Trond.Myklebust@netapp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27ocfs2: ->e_leaf_clusters endianness breakageAl Viro
commit 72094e43e3af5020510f920321d71f1798fa896d upstream. le16, not le32... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27ocfs2: ->rl_count endianness breakageAl Viro
commit 28748b325dc2d730ccc312830a91c4ae0c0d9379 upstream. le16, not le32... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27ocfs: ->rl_used breakage on big-endianAl Viro
commit e1bf4cc620fd143766ddfcee3b004a1d1bb34fd0 upstream. it's le16, not le32 or le64... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27ocfs2: ->l_next_free_req breakage on big-endianAl Viro
commit 3a251f04fe97c3d335b745c98e4b377e3c3899f2 upstream. It's le16, not le32... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Mark Fasheh <mfasheh@suse.com> Cc: Joel Becker <jlbec@evilplan.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27btrfs: btrfs_root_readonly() broken on big-endianAl Viro
commit 6ed3cf2cdfce4c9f1d73171bd3f27d9cb77b734e upstream. ->root_flags is __le64 and all accesses to it go through the helpers that do proper conversions. Except for btrfs_root_readonly(), which checks bit 0 as in host-endian... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Chris Mason <chris.mason@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27nfsd: fix compose_entry_fh() failure exitsAl Viro
commit efe39651f08813180f37dc508d950fc7d92b29a8 upstream. Restore the original logics ("fail on mountpoints, negatives and in case of fh_compose() failures"). Since commit 8177e (nfsd: clean up readdirplus encoding) that got broken - rv = fh_compose(fhp, exp, dchild, &cd->fh); if (rv) goto out; if (!dchild->d_inode) goto out; rv = 0; out: is equivalent to rv = fh_compose(fhp, exp, dchild, &cd->fh); out: and the second check has no effect whatsoever... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: "J. Bruce Fields" <bfields@fieldses.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27rt2x00: Identify rt2800usb chipsets.Gertjan van Wingerde
commit bc93eda7e903ff75cefcb6e247ed9b8e9f8e9783 upstream. According to the latest USB ID database these are all RT2770 / RT2870 / RT307x devices. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27rt2800: Add support for the Fujitsu Stylistic Q550Alan Cox
commit 3ac44670ad0fca8b6c43b3e4d8494c67c419f494 upstream. Just another USB identifier. Signed-off-by: Alan Cox <alan@linux.intel.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27rt2x00: Add USB device ID of Buffalo WLI-UC-GNHP.Gertjan van Wingerde
commit c18b7806e4f3373b2f296a65fb19251a3b49a532 upstream. This is reported to be an RT3070 based device. Reported-by: Teika Kazura <teika@lavabit.com> Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Acked-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27rt2800usb: Add new device ID for BelkinEduardo Bacchi Kienetz
commit 43bf8c245237b8309153aa39d4e8f1586cf56af0 upstream. Belkin's Connect N150 Wireless USB Adapter, model F7D1101 version 2, uses ID 0x945b. Chipset info: rt: 3390, rf: 000b, rev: 3213. I have just bought one, which started to work perfectly after the ID was added through this patch. Signed-off-by: Eduardo Bacchi Kienetz <eduardo@kienetz.com> Acked-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27rt2x00: Properly identify rt2800usb devices.Gertjan van Wingerde
commit acb56120d2c386d6dd104a6515c1a15dabc1ef87 upstream. Sitecom WLA4000 (USB ID 0x0df6:0x0060) is an RT3072 chipset. Sitecom WLA5000 (USB ID 0x0df6:0x0062) is an RT3572 chipset. Signed-off-by: Gertjan van Wingerde <gwingerde@gmail.com> Signed-off-by: Ivo van Doorn <IvDoorn@gmail.com> Signed-off-by: John W. Linville <linville@tuxdriver.com> Cc: Ben Hutchings <ben@decadent.org.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27spi: Fix device unregistration when unregistering the bus masterLaurent Pinchart
commit 178db7d30f94707efca1a189753c105ef69942ed upstream. Device are added as children of the bus master's parent device, but spi_unregister_master() looks for devices to unregister in the bus master's children. This results in the child devices not being unregistered. Fix this by registering devices as direct children of the bus master. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Grant Likely <grant.likely@secretlab.ca> Cc: Takahiro AKASHI <akashi@jp.fujitsu.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27Don't limit non-nested epoll pathsJason Baron
commit 93dc6107a76daed81c07f50215fa6ae77691634f upstream. Commit 28d82dc1c4ed ("epoll: limit paths") that I did to limit the number of possible wakeup paths in epoll is causing a few applications to longer work (dovecot for one). The original patch is really about limiting the amount of epoll nesting (since epoll fds can be attached to other fds). Thus, we probably can allow an unlimited number of paths of depth 1. My current patch limits it at 1000. And enforce the limits on paths that have a greater depth. This is captured in: https://bugzilla.redhat.com/show_bug.cgi?id=681578 Signed-off-by: Jason Baron <jbaron@redhat.com> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27Bluetooth: Add support for Atheros [04ca:3005]AceLan Kao
commit 55ed7d4d1469eafbe3ad7e8fcd44f5af27845a81 upstream. Add another vendor specific ID for Atheros AR3012 device. This chip is wrapped by Lite-On Technology Corp. output of usb-devices: T: Bus=04 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#= 2 Spd=12 MxCh= 0 D: Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs= 1 P: Vendor=04ca ProdID=3005 Rev=00.02 S: Manufacturer=Atheros Communications S: Product=Bluetooth USB Host Controller S: SerialNumber=Alaska Day 2006 C: #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb I: If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb Signed-off-by: AceLan Kao <acelan.kao@canonical.com> Signed-off-by: Gustavo Padovan <gustavo@padovan.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27ext4: fix endianness breakage in ext4_split_extent_at()Al Viro
commit af1584f570b19b0285e4402a0b54731495d31784 upstream. ->ee_len is __le16, so assigning cpu_to_le32() to it is going to do Bad Things(tm) on big-endian hosts... Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Cc: Ted Ts'o <tytso@mit.edu> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27PCI: Add quirk for still enabled interrupts on Intel Sandy Bridge GPUsThomas Jarosch
commit f67fd55fa96f7d7295b43ffbc4a97d8f55e473aa upstream. Some BIOS implementations leave the Intel GPU interrupts enabled, even though no one is handling them (f.e. i915 driver is never loaded). Additionally the interrupt destination is not set up properly and the interrupt ends up -somewhere-. These spurious interrupts are "sticky" and the kernel disables the (shared) interrupt line after 100.000+ generated interrupts. Fix it by disabling the still enabled interrupts. This resolves crashes often seen on monitor unplug. Tested on the following boards: - Intel DH61CR: Affected - Intel DH67BL: Affected - Intel S1200KP server board: Affected - Asus P8H61-M LE: Affected, but system does not crash. Probably the IRQ ends up somewhere unnoticed. According to reports on the net, the Intel DH61WW board is also affected. Many thanks to Jesse Barnes from Intel for helping with the register configuration and to Intel in general for providing public hardware documentation. Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com> Tested-by: Charlie Suffin <charlie.suffin@stratus.com> Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27usb: musb: omap: fix the error check for pm_runtime_get_syncShubhrajyoti D
commit ad579699c4f0274bf522a9252ff9b20c72197e48 upstream. pm_runtime_get_sync returns a signed integer. In case of errors it returns a negative value. This patch fixes the error check by making it signed instead of unsigned thus preventing register access if get_sync_fails. Also passes the error cause to the debug message. Cc: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Shubhrajyoti D <shubhrajyoti@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27usb: musb: omap: fix crash when musb glue (omap) gets initializedKishon Vijay Abraham I
commit 3006dc8c627d738693e910c159630e4368c9e86c upstream. pm_runtime_enable is being called after omap2430_musb_init. Hence pm_runtime_get_sync in omap2430_musb_init does not have any effect (does not enable clocks) resulting in a crash during register access. It is fixed here. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27usb: gadget: eliminate NULL pointer dereference (bugfix)Andrzej Pietrasiewicz
commit 92b0abf80c5c5f0e0d71d1309688a330fd74731b upstream. usb: gadget: eliminate NULL pointer dereference (bugfix) This patch fixes a bug which causes NULL pointer dereference in ffs_ep0_ioctl. The bug happens when the FunctionFS is not bound (either has not been bound yet or has been bound and then unbound) and can be reproduced with running the following commands: $ insmod g_ffs.ko $ mount -t functionfs func /dev/usbgadget $ ./null where null.c is: #include <fcntl.h> #include <linux/usb/functionfs.h> int main(void) { int fd = open("/dev/usbgadget/ep0", O_RDWR); ioctl(fd, FUNCTIONFS_CLEAR_HALT); return 0; } Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> Signed-off-by: Felipe Balbi <balbi@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27USB: fix deadlock in bConfigurationValue attribute methodAlan Stern
commit 8963c487a80b4688c9e68dcc504a90074aacc145 upstream. This patch (as154) fixes a self-deadlock that occurs when userspace writes to the bConfigurationValue sysfs attribute for a hub with children. The task tries to lock the bandwidth_mutex at a time when it already owns the lock: The attribute's method calls usb_set_configuration(), which calls usb_disable_device() with the bandwidth_mutex held. usb_disable_device() unregisters the existing interfaces, which causes the hub driver to be unbound. The hub_disconnect() routine calls hub_quiesce(), which calls usb_disconnect() for each of the hub's children. usb_disconnect() attempts to acquire the bandwidth_mutex around a call to usb_disable_device(). The solution is to make usb_disable_device() acquire the mutex for itself instead of requiring the caller to hold it. Then the mutex can cover only the bandwidth deallocation operation and not the region where the interfaces are unregistered. This has the potential to change system behavior slightly when a config change races with another config or altsetting change. Some of the bandwidth released from the old config might get claimed by the other config or altsetting, make it impossible to restore the old config in case of a failure. But since we don't try to recover from config-change failures anyway, this doesn't matter. [This should be marked for stable kernels that contain the commit fccf4e86200b8f5edd9a65da26f150e32ba79808 "USB: Free bandwidth when usb_disable_device is called." That commit was marked for stable kernels as old as 2.6.32.] Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27EHCI: always clear the STS_FLR status bitAlan Stern
commit 2fbe2bf1fd37f9d99950bd8d8093623cf22cf08b upstream. This patch (as1544) fixes a problem affecting some EHCI controllers. They can generate interrupts whenever the STS_FLR status bit is turned on, even though that bit is masked out in the Interrupt Enable register. Since the driver doesn't use STS_FLR anyway, the patch changes the interrupt routine to clear that bit whenever it is set, rather than leaving it alone. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Reported-and-tested-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27USB: sierra: avoid QMI/wwan interface on MC77xxBjørn Mork
commit 749541d19e70905e3971f2a08335a206a98e4d0c upstream. These devices have a number of non serial interfaces as well. Use the existing "Direct IP" blacklist to prevent binding to interfaces which are handled by other drivers. We also extend the "Direct IP" blacklist with with interfaces only seen in "QMI" mode, assuming that these devices use the same interface numbers for serial interfaces both in "Direct IP" and in "QMI" mode. Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27drivers/tty/amiserial.c: add missing tty_unlockJulia Lawall
commit d3a7b83f865b46bb7b5e1ed18a129ce1af349db4 upstream. tty_unlock is used on all other exits from the function. Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr> Acked-by: Jiri Slaby <jslaby@suse.cz> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27pch_uart: Fix dma channel unallocated issueTomoya MORINAGA
commit af6d17cdc8c89aeb3101f0d27cd32fc0592b40b2 upstream. This driver anticipates pch_uart_verify_port() is not called during installation. However, actually pch_uart_verify_port() is called during installation. As a result, memory access violation occurs like below. 0. initial value: use_dma=0 1. starup() - dma channel is not allocated because use_dma=0 2. pch_uart_verify_port() - Set use_dma=1 3. UART processing acts DMA mode because use_dma=1 - memory access violation occurs! This patch fixes the issue. Solution: Whenever pch_uart_verify_port() is called and then dma channel is not allocated, the channel should be allocated. Signed-off-by: Tomoya MORINAGA <tomoya.rohm@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-04-27USB: serial: cp210x: Fixed usb_control_msg timeout valuesYuri Matylitski
commit 2d5733fcd33dd451022d197cb6b476e970519ca7 upstream. Fixed too small hardcoded timeout values for usb_control_msg in driver for SiliconLabs cp210x-based usb-to-serial adapters. Replaced with USB_CTRL_GET_TIMEOUT/USB_CTRL_SET_TIMEOUT. Signed-off-by: Yuri Matylitski <ym@tekinsoft.com> Acked-by: Kirill A. Shutemov <kirill@shutemov.name> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>