- 11 May, 2012 40 commits
-
-
Eric Dumazet authored
[ Upstream commit 87151b86 ] Marc Merlin reported many order-1 allocations failures in TX path on its wireless setup, that dont make any sense with MTU=1500 network, and non SG capable hardware. Turns out part of the problem comes from pskb_expand_head() not using ksize() to get exact head size given by kmalloc(). Doing the same thing than __alloc_skb() allows more tailroom in skb and can prevent future reallocations. As a bonus, struct skb_shared_info becomes cache line aligned. Reported-by:
Marc MERLIN <marc@merlins.org> Tested-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Ben Hutchings <ben@decadent.org.uk>
-
Neal Cardwell authored
[ Upstream commit 18a223e0 ] 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:
-
Eric Dumazet authored
[ Upstream commit 110c4330 ] 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 authored
[ Upstream commit 4a7e7c2a ] 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:
-
Phil Sutter authored
[ Upstream commit 4eee6a3a ] 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:
-
Veaceslav Falico authored
[ Upstream commit 5a430974 ] 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:
-
Sasha Levin authored
[ Upstream commit bcf1b70a ] 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:
-
RongQing.Li authored
[ Upstream commit 78d50217 ] 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:
-
Herbert Xu authored
[ Upstream commit 996304bb ] 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:
-
Thomas Graf authored
[ Upstream commit acdd5985 ] 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:
-
Eric Dumazet authored
[ This combines upstream commit 2f533844 and the follow-on bug fix commit 35f9c09f ] 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:
-
David Woodhouse authored
[ This combines upstream commit e675f0cc and follow-on bug fix commit 9a5d2bd9 ] 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:
-
J. Bruce Fields authored
commit 9dc4e6c4 upstream. Allow a v3 unchecked open of a non-regular file succeed as if it were a lookup; typically a client in such a case will want to fall back on a local open, so succeeding and giving it the filehandle is more useful than failing with nfserr_exist, which makes it appear that nothing at all exists by that name. Similarly for v4, on an open-create, return the same errors we would on an attempt to open a non-regular file, instead of returning nfserr_exist. This fixes a problem found doing a v4 open of a symlink with O_RDONLY|O_CREAT, which resulted in the current client returning EEXIST. Thanks also to Trond for analysis. Reported-by:
Orion Poplawski <orion@cora.nwra.com> Tested-by:
J. Bruce Fields <bfields@redhat.com> [bwh: Backported to 3.2: use &resfh, not resfh] Signed-off-by:
-
Eric Dumazet authored
[ Upstream commit 2def16ae ] Commit f04565dd (dev: use name hash for dev_seq_ops) added a second regression, as some devices are missing from /proc/net/dev if many devices are defined. When seq_file buffer is filled, the last ->next/show() method is canceled (pos value is reverted to value prior ->next() call) Problem is after above commit, we dont restart the lookup at right position in ->start() method. Fix this by removing the internal 'pos' pointer added in commit, since we need to use the 'loff_t *pos' provided by seq_file layer. This also reverts commit 5cac98dd (net: Fix corruption in /proc/*/net/dev_mcast), since its not needed anymore. Reported-by:
Ben Greear <greearb@candelatech.com> Signed-off-by:
-
Felipe Balbi authored
commit cd423dd3 upstream. due to a HW limitation we have a bounce buffer for ep0 out transfers which are not aligned with MaxPacketSize. On such case we were not increment r->actual as we should. This patch fixes that mistake. Signed-off-by:
Felipe Balbi <balbi@ti.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Al Viro authored
commit e847469b upstream. comparing be32 values for < is not doing the right thing... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
-
Al Viro authored
commit 72094e43 upstream. le16, not le32... Signed-off-by:
-
Al Viro authored
commit 28748b32 upstream. le16, not le32... Signed-off-by:
-
Al Viro authored
commit e1bf4cc6 upstream. it's le16, not le32 or le64... Signed-off-by:
-
Al Viro authored
commit 3a251f04 upstream. It's le16, not le32... Signed-off-by:
-
Al Viro authored
commit 6ed3cf2c 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 authored
commit efe39651 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 authored
commit 02f5fde5 upstream. ->ts_id_status gets nfs errno, i.e. it's already big-endian; no need to apply htonl() to it. Broken by commit 174568 (NFSD: Added TEST_STATEID operation) last year... Signed-off-by:
-
Al Viro authored
commit 04da6e9d upstream. nfsd_open() already returns an NFS error value; only vfs_test_lock() result needs to be fed through nfserrno(). Broken by commit 55ef12 (nfsd: Ensure nfsv4 calls the underlying filesystem on LOCKT) three years ago... Signed-off-by:
-
Al Viro authored
commit 96f6f985 upstream. ..._want_write() returns -EROFS on failure, _not_ an NFS error value. Signed-off-by:
Jonathan Nieder <jrnieder@gmail.com> Signed-off-by:
-
Gertjan van Wingerde authored
commit bc93eda7 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> [bwh: Backported to 3.2: adjust context for previously cherry-picked commit d42a179b 'rt2x00: Add support for D-Link DWA-127 to rt2800usb'] Signed-off-by:
-
Alan Cox authored
commit 3ac44670 upstream. Just another USB identifier. Signed-off-by:
Alan Cox <alan@linux.intel.com> Acked-by:
-
Kenth Eriksson authored
commit 5039a869 upstream. Commit 178db7d3, "spi: Fix device unregistration when unregistering the bus master", changed device initialization to be children of the bus master, not children of the bus masters parent device. The pdata pointer used in fsl_spi_chipselect must updated to reflect the changed initialization. Signed-off-by:
Kenth Eriksson <kenth.eriksson@transmode.com> Acked-by:
Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by:
Grant Likely <grant.likely@secretlab.ca> Signed-off-by:
-
Laurent Pinchart authored
commit 178db7d3 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:
-
Jason Baron authored
commit 93dc6107 upstream. Commit 28d82dc1 ("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=681578Signed-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:
-
AceLan Kao authored
commit 55ed7d4d 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:
-
AceLan Kao authored
commit 2d5de9e8 upstream. Touchpad LED will not turn on after S3, it will make the touchpad status doesn't consist with the LED. By adding one flag to let the LED device restore it's status. Signed-off-by:
Matthew Garrett <mjg@redhat.com> Signed-off-by:
-
AceLan Kao authored
commit 2a748853 upstream. Add "Vostro 3555", "Inspiron N311z", and "Inspiron M5110" into quirks, so that they could have touchpad LED function work. Signed-off-by:
-
Alex Williamson authored
commit 32f6daad upstream. We've been adding new mappings, but not destroying old mappings. This can lead to a page leak as pages are pinned using get_user_pages, but only unpinned with put_page if they still exist in the memslots list on vm shutdown. A memslot that is destroyed while an iommu domain is enabled for the guest will therefore result in an elevated page reference count that is never cleared. Additionally, without this fix, the iommu is only programmed with the first translation for a gpa. This can result in peer-to-peer errors if a mapping is destroyed and replaced by a new mapping at the same gpa as the iommu will still be pointing to the original, pinned memory address. Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by:
-
Al Viro authored
commit af1584f5 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:
-
Thomas Jarosch authored
commit f67fd55f 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> [bwh: Backported to 3.2: adjust context] Signed-off-by:
-
Shubhrajyoti D authored
commit ad579699 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:
-
Kishon Vijay Abraham I authored
commit 3006dc8c 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:
-
Andrzej Pietrasiewicz authored
commit 92b0abf8 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:
-
Alan Stern authored
commit 320cd1e7 upstream. This patch (as1548) fixes a recently-introduced incompatibility between the UDC core and the dummy-hcd driver. Commit 8ae8090c (usb: gadget: udc-core: fix asymmetric calls in remove_driver) moved the usb_gadget_udc_stop() call in usb_gadget_remove_driver() below the usb_gadget_disconnect() call. As a result, usb_gadget_disconnect() gets called at a time when the gadget driver believes it has been unbound but dummy-hcd believes it has not. A nasty error ensues when dummy-hcd calls the gadget driver's disconnect method a second time. To fix the problem, this patch moves the gadget driver's unbind notification after the usb_gadget_disconnect() call. Now nothing happens between the two unbind notifications, so nothing goes wrong. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Tested-by:
Alexander Shishkin <alexander.shishkin@linux.intel.com> Signed-off-by:
-
