- 03 Oct, 2011 40 commits
-
-
Jiri Pirko authored
[ Upstream commit c5114cd5 ] It's after all necessary to do reset headers here. The reason is we cannot depend that it gets reseted in __netif_receive_skb once skb is reinjected. For incoming vlanids without vlan_dev, vlan_do_receive() returns false with skb != NULL and __netif_reveive_skb continues, skb is not reinjected. This might be good material for 3.0-stable as well Reported-by:
Mike Auty <mike.auty@gmail.com> Signed-off-by:
Jiri Pirko <jpirko@redhat.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mike Waychison authored
[ Upstream commit f0e3d068 ] Using a gcc 4.4.3, warnings are emitted for a possibly uninitialized use of ecn_ok. This can happen if cookie_check_timestamp() returns due to not having seen a timestamp. Defaulting to ecn off seems like a reasonable thing to do in this case, so initialized ecn_ok to false. Signed-off-by:
Mike Waychison <mikew@google.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Zheng Yan authored
[ Upstream commit f779b2d6 ] D-SACK is allowed to reside below snd_una. But the corresponding check in tcp_is_sackblock_valid() is the exact opposite. It looks like a typo. Signed-off-by:
Zheng Yan <zheng.z.yan@intel.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Tim Chen authored
[ Upstream commit e33f7a9f ] This patch corrects an erroneous update of credential's gid with uid introduced in commit 257b5358 since 2.6.36. Signed-off-by:
Tim Chen <tim.c.chen@linux.intel.com> Acked-by:
Eric Dumazet <eric.dumazet@gmail.com> Reviewed-by:
James Morris <jmorris@namei.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Ben Hutchings authored
[ Upstream commit 86c432ca ] This reverts commits 65f0b417, d88d6b05, fcfa0604, 747df225 and 867955f5. Depending on the processor model, write-combining may result in reordering that the NIC will not tolerate. This typically results in a DMA error event and reset by the driver, logged as: sfc 0000:0e:00.0: eth2: TX DMA Q reports TX_EV_PKT_ERR. sfc 0000:0e:00.0: eth2: resetting (ALL) Signed-off-by:
Ben Hutchings <bhutchings@solarflare.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Florian Westphal authored
[ Upstream commit 3557619f ] commit 07bd8df5 (sch_sfq: fix peek() implementation) changed sfq to use generic peek helper. This makes HFSC complain about a non-work-conserving child qdisc, if prio with sfq child is used within hfsc: hfsc peeks into prio qdisc, which will then peek into sfq. returned skb is stashed in sch->gso_skb. Next, hfsc tries to dequeue from prio, but prio will call sfq dequeue directly, which may return NULL instead of previously peeked-at skb. Have prio call qdisc_dequeue_peeked, so sfq->dequeue() is not called in this case. Cc: Eric Dumazet <eric.dumazet@gmail.com> Signed-off-by:
Florian Westphal <fw@strlen.de> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Julian Anastasov authored
[ Upstream commit 797fd391 ] TCP in some cases uses different global (raw) socket to send RST and ACK. The transparent flag is not set there. Currently, it is a problem for rerouting after the previous change. Fix it by simplifying the checks in ip_route_me_harder and use FLOWI_FLAG_ANYSRC even for sockets. It looks safe because the initial routing allowed this source address to be used and now we just have to make sure the packet is rerouted. As a side effect this also allows rerouting for normal raw sockets that use spoofed source addresses which was not possible even before we eliminated the ip_route_input call. Signed-off-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Yan, Zheng authored
[ Upstream commit e05c4ad3 ] Should check use count of include mode filter instead of total number of include mode filters. Signed-off-by:
Zheng Yan <zheng.z.yan@intel.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Daniel Baluta authored
[ Upstream commit 98e77438 ] IPV6_2292PKTOPTIONS is broken for 32-bit applications running in COMPAT mode on 64-bit kernels. The same problem was fixed for IPv4 with the patch: ipv4: Fix ip_getsockopt for IP_PKTOPTIONS, commit dd23198eSigned-off-by:
Sorin Dumitru <sdumitru@ixiacom.com> Signed-off-by:
Daniel Baluta <dbaluta@ixiacom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Julian Anastasov authored
[ Upstream commit 97a80410 ] As rt_iif represents input device even for packets coming from loopback with output route, it is not an unique key specific to input routes. Now rt_route_iif has such role, it was fl.iif in 2.6.38, so better to change the checks at some places to save CPU cycles and to restore 2.6.38 semantics. compare_keys: - input routes: only rt_route_iif matters, rt_iif is same - output routes: only rt_oif matters, rt_iif is not used for matching in __ip_route_output_key - now we are back to 2.6.38 state ip_route_input_common: - matching rt_route_iif implies input route - compared to 2.6.38 we eliminated one rth->fl.oif check because it was not needed even for 2.6.38 compare_hash_inputs: Only the change here is not an optimization, it has effect only for output routes. I assume I'm restoring the original intention to ignore oif, it was using fl.iif - now we are back to 2.6.38 state Signed-off-by:
Julian Anastasov <ja@ssi.bg> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Gao feng authored
[ Upstream commit 561dac2d ] add new fib rule can cause BUG_ON happen the reproduce shell is ip rule add pref 38 ip rule add pref 38 ip rule add to 192.168.3.0/24 goto 38 ip rule del pref 38 ip rule add to 192.168.3.0/24 goto 38 ip rule add pref 38 then the BUG_ON will happen del BUG_ON and use (ctarget == NULL) identify whether this rule is unresolved Signed-off-by:
Gao feng <gaofeng@cn.fujitsu.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@suse.de>
-
Eric Dumazet authored
[ Upstream commit 11f3a6bd ] Jan Beulich reported a possible net_device leak in bridge code after commit bb900b27 (bridge: allow creating bridge devices with netlink) Reported-by:
Jan Beulich <JBeulich@novell.com> Signed-off-by:
Eric Dumazet <eric.dumazet@gmail.com> Acked-by:
Stephen Hemminger <shemminger@vyatta.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Eric Dumazet authored
[ Upstream commit 20e6074e ] Dave Jones reported a lockdep splat triggered by an arp_process() call from parp_redo(). Commit faa9dcf7 (arp: RCU changes) is the origin of the bug, since it assumed arp_process() was called under rcu_read_lock(), which is not true in this particular path. Instead of adding rcu_read_lock() in parp_redo(), I chose to add it in neigh_proxy_process() to take care of IPv6 side too. =================================================== [ INFO: suspicious rcu_dereference_check() usage. ] --------------------------------------------------- include/linux/inetdevice.h:209 invoked rcu_dereference_check() without protection! other info that might help us debug this: rcu_scheduler_active = 1, debug_locks = 0 4 locks held by setfiles/2123: #0: (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [<ffffffff8114cbc4>] walk_component+0x1ef/0x3e8 #1: (&isec->lock){+.+.+.}, at: [<ffffffff81204bca>] inode_doinit_with_dentry+0x3f/0x41f #2: (&tbl->proxy_timer){+.-...}, at: [<ffffffff8106a803>] run_timer_softirq+0x157/0x372 #3: (class){+.-...}, at: [<ffffffff8141f256>] neigh_proxy_process +0x36/0x103 stack backtrace: Pid: 2123, comm: setfiles Tainted: G W 3.1.0-0.rc2.git7.2.fc16.x86_64 #1 Call Trace: <IRQ> [<ffffffff8108ca23>] lockdep_rcu_dereference+0xa7/0xaf [<ffffffff8146a0b7>] __in_dev_get_rcu+0x55/0x5d [<ffffffff8146a751>] arp_process+0x25/0x4d7 [<ffffffff8146ac11>] parp_redo+0xe/0x10 [<ffffffff8141f2ba>] neigh_proxy_process+0x9a/0x103 [<ffffffff8106a8c4>] run_timer_softirq+0x218/0x372 [<ffffffff8106a803>] ? run_timer_softirq+0x157/0x372 [<ffffffff8141f220>] ? neigh_stat_seq_open+0x41/0x41 [<ffffffff8108f2f0>] ? mark_held_locks+0x6d/0x95 [<ffffffff81062bb6>] __do_softirq+0x112/0x25a [<ffffffff8150d27c>] call_softirq+0x1c/0x30 [<ffffffff81010bf5>] do_softirq+0x4b/0xa2 [<ffffffff81062f65>] irq_exit+0x5d/0xcf [<ffffffff8150dc11>] smp_apic_timer_interrupt+0x7c/0x8a [<ffffffff8150baf3>] apic_timer_interrupt+0x73/0x80 <EOI> [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158 [<ffffffff814fc285>] ? __slab_free+0x30/0x24c [<ffffffff814fc283>] ? __slab_free+0x2e/0x24c [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f [<ffffffff81204e74>] ? inode_doinit_with_dentry+0x2e9/0x41f [<ffffffff81130cb0>] kfree+0x108/0x131 [<ffffffff81204e74>] inode_doinit_with_dentry+0x2e9/0x41f [<ffffffff81204fc6>] selinux_d_instantiate+0x1c/0x1e [<ffffffff81200f4f>] security_d_instantiate+0x21/0x23 [<ffffffff81154625>] d_instantiate+0x5c/0x61 [<ffffffff811563ca>] d_splice_alias+0xbc/0xd2 [<ffffffff811b17ff>] ext4_lookup+0xba/0xeb [<ffffffff8114bf1e>] d_alloc_and_lookup+0x45/0x6b [<ffffffff8114cbea>] walk_component+0x215/0x3e8 [<ffffffff8114cdf8>] lookup_last+0x3b/0x3d [<ffffffff8114daf3>] path_lookupat+0x82/0x2af [<ffffffff8110fc53>] ? might_fault+0xa5/0xac [<ffffffff8110fc0a>] ? might_fault+0x5c/0xac [<ffffffff8114c564>] ? getname_flags+0x31/0x1ca [<ffffffff8114dd48>] do_path_lookup+0x28/0x97 [<ffffffff8114df2c>] user_path_at+0x59/0x96 [<ffffffff811467ad>] ? cp_new_stat+0xf7/0x10d [<ffffffff811469a6>] vfs_fstatat+0x44/0x6e [<ffffffff811469ee>] vfs_lstat+0x1e/0x20 [<ffffffff81146b3d>] sys_newlstat+0x1a/0x33 [<ffffffff8108f439>] ? trace_hardirqs_on_caller+0x121/0x158 [<ffffffff812535fe>] ? trace_hardirqs_on_thunk+0x3a/0x3f [<ffffffff8150af82>] system_call_fastpath+0x16/0x1b Reported-by:
Dave Jones <davej@redhat.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@suse.de>
-
Youquan Song authored
commit a34668f6 upstream. Add support to Romely-EP SandyBridge. Signed-off-by:
Youquan Song <youquan.song@intel.com> Signed-off-by:
Anhua Xu <anhua.xu@intel.com> Signed-off-by:
Lin Ming <ming.m.lin@intel.com> Signed-off-by:
Peter Zijlstra <a.p.zijlstra@chello.nl> Link: http://lkml.kernel.org/r/1312264895-2010-1-git-send-email-youquan.song@intel.comSigned-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kashyap, Desai authored
commit ab3e5f60 upstream. Signed-off-by:
Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kashyap, Desai authored
commit 7821578c upstream. Driver should not call shutdown call from _scsih_remove otherwise, The scsi midlayer can be deadlocked when devices are removed from the driver pci_driver->shutdown handler. Signed-off-by:
Kashyap Desai <kashyap.desai@lsi.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kiran Patil authored
commit 1ff9918b upstream. Problem: When initiator sends write command to target, target tries to assign new sequence. It allocates new exchangeID (RX_ID) always from non-offloaded pool (Non-offload EMA) Fix: Enhanced fcoe_oem_match routine to look at F_CTL flags and if it is exchange responder and command type is WRITEDATA, then function returns TRUE instead of FALSE. This function is used to determine which pool to use (offload pool of exchange is used only if this function returns TRUE). Technical Notes: N/A Signed-off-by:
Kiran Patil <kiran.patil@intel.com> Signed-off-by:
Robert Love <robert.w.love@intel.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Kiran Patil authored
commit 48058481 upstream. Problem: Existing RPORT state machine continues witg FLOGI/PLOGI process only after it receices beacon from other end. Once claiming stage is over (either clain notify or clain repose), beacon is sent and state machine enters into operational mode where it initiates the rlogin process (FLOGI/PLOGI) to the peer but before this rlogin is initiated, exitsing implementation checks if it received beacon from other end, it beacon is not received yet, rlogin process is not initiated. Other end initiates FLOGI but peer end keeps on rejecting FLOGI, hence after 3 retries other end deletes associated rport, then sends a beacon. Once the beacon is received, peer end now initiates rlogin to the peer end but since associated rport is deleted FLOGI is neither accepted nor the reject response send out because rport is deleted. Hence unable to proceed withg FLOGI/PLOGI process and fails to establish VN2VN connection. Fix: VN2VN spec is not standard yet but based on exitsing collateral on T11, it appears that, both end shall send beacon and enter into 'operational mode' without explictly waiting for beacon from other end. Fix is to allow the RPORT login process as long as respective RPORT is created (as part of claim notification / claim response) even though state of RPORT is INIT. Means don't wait for beacon from peer end, if peer end initiates FLOGI (means peer end exist and responding). Notes: This patch is preparing the FCoE stack for target wrt offload. This is generic patch and harmless even if applied on storage initiator because 'else if' condition of function 'fcoe_oem_found' shall evaluate to TRUE only for targets. Dependencies: None Signed-off-by:
Kiran Patil <kiran.patil@intel.com> Signed-off-by:
Robert Love <robert.w.love@intel.com> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Giuseppe Scrivano authored
commit 36c35416 upstream. Fix a misusage of the struct usb_cdc_notification to pass arguments to the usb_control_msg function. The usb_control_msg function expects host endian arguments but usb_cdc_notification stores these values as little endian. Now usb_control_msg is directly invoked with host endian values. Signed-off-by:
Giuseppe Scrivano <giuseppe@southpole.se> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Marek Vasut authored
commit 30885909 upstream. This device can be found in Acer Iconia TAB W500 tablet dock. Signed-off-by:
Marek Vasut <marek.vasut@gmail.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Michal Sroczynski authored
commit 8d48fdf6 upstream. PL2303: correctly handle baudrates above 115200 Signed-off-by:
Michal Sroczynski <msroczyn@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Anisse Astier authored
commit 0c42a4e8 upstream. Add another variant of the Pegatron tablet used by Ordissimo, and apparently RM Slate 100, to the list of models that should skip the negociation for the handoff of the EHCI controller. Signed-off-by:
Anisse Astier <anisse@astier.eu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Anisse Astier authored
commit 03c75362 upstream. In commit 3610ea53 (ehci: workaround for pci quirk timeout on ExoPC), a workaround was added to skip the negociation for the handoff of the EHCI controller. Refactor the DMI detection code to use standard dmi_check_system function. Signed-off-by:
Anisse Astier <anisse@astier.eu> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Matt Carlson authored
commit 3aa1cdf8 upstream. This patch fixes interrupt selftest failures for recent devices (57765, 5717, 5718. 5719, 5720) by disabling MSI one-shot mode and applying the status tag workaround to the selftest code. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Reviewed-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Matt Carlson authored
commit 5baa5e9a upstream. This patch adds the 5719 and the 5720 to the list of devices that are EEE capable. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Reviewed-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jan Glauber authored
commit b02f0c2e upstream. The following race can occur with qdio devices that use the shared device state change indicator: Device (Shared DSCI) CPU0 CPU1 =============================================================================== 1. DSCI 0 => 1, INT pending 2. Thinint handler * si_used = 1 * Inbound tasklet_schedule * DSCI 1 => 0 3. DSCI 0 => 1, INT pending 4. Thinint handler * si_used = 1 * Inbound tasklet_schedu le => NOP 5. Inbound tasklet run 6. DSCI = 1, INT surpressed 7. DSCI 1 => 0 The race would lead to a stall where new data in the input queue is not recognized so the device stops working in case of no further traffic. Fix the race by resetting the DSCI before scheduling the inbound tasklet so the device generates an interrupt if new data arrives in the above scenario in step 6. Reviewed-by:
Ursula Braun <ursula.braun@de.ibm.com> Signed-off-by:
Jan Glauber <jang@linux.vnet.ibm.com> Signed-off-by:
Martin Schwidefsky <schwidefsky@de.ibm.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wu Fengguang authored
commit 94c3dcbb upstream. Explicitly update .dirtied_when on synced inodes, so that they are no longer considered for writeback in the next round. It can prevent both of the following livelock schemes: - while true; do echo data >> f; done - while true; do touch f; done (in theory) The exact livelock condition is, during sync(1): (1) no new inodes are dirtied (2) an inode being actively dirtied On (2), the inode will be tagged and synced with .nr_to_write=LONG_MAX. When finished, it will be redirty_tail()ed because it's still dirty and (.nr_to_write > 0). redirty_tail() won't update its ->dirtied_when on condition (1). The sync work will then revisit it on the next queue_io() and find it eligible again because its old ->dirtied_when predates the sync work start time. We'll do more aggressive "keep writeback as long as we wrote something" logic in wb_writeback(). The "use LONG_MAX .nr_to_write" trick in commit b9543dac ("writeback: avoid livelocking WB_SYNC_ALL writeback") will no longer be enough to stop sync livelock. Reviewed-by:
Jan Kara <jack@suse.cz> Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wu Fengguang authored
commit 6e6938b6 upstream. sync(2) is performed in two stages: the WB_SYNC_NONE sync and the WB_SYNC_ALL sync. Identify the first stage with .tagged_writepages and do livelock prevention for it, too. Jan's commit f446daae ("mm: implement writeback livelock avoidance using page tagging") is a partial fix in that it only fixed the WB_SYNC_ALL phase livelock. Although ext4 is tested to no longer livelock with commit f446daae, it may due to some "redirty_tail() after pages_skipped" effect which is by no means a guarantee for _all_ the file systems. Note that writeback_inodes_sb() is called by not only sync(), they are treated the same because the other callers also need livelock prevention. Impact: It changes the order in which pages/inodes are synced to disk. Now in the WB_SYNC_NONE stage, it won't proceed to write the next inode until finished with the current inode. Acked-by:
Jan Kara <jack@suse.cz> CC: Dave Chinner <david@fromorbit.com> Signed-off-by:
Wu Fengguang <fengguang.wu@intel.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
commit d40dcdb0 upstream. We return ENOMEM from mqueue_get_inode even when we have enough memory. Namely in case the system rlimit of mqueue was reached. This error propagates to mq_queue and user sees the error unexpectedly. So fix this up to properly return EMFILE as described in the manpage: EMFILE The process already has the maximum number of files and message queues open. instead of: ENOMEM Insufficient memory. With the previous patch we just switch to ERR_PTR/PTR_ERR/IS_ERR error handling here. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Jiri Slaby authored
commit 04715206 upstream. If new_inode fails to allocate an inode we need only to return with NULL. But now we test the opposite and have all the work in a nested block. So do the opposite to save one indentation level (and remove unnecessary line breaks). This is only a preparation/cleanup for the next patch where we fix up return values from mqueue_get_inode. Signed-off-by:
Jiri Slaby <jslaby@suse.cz> Cc: Manfred Spraul <manfred@colorfullife.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Matt Carlson authored
commit 9e975cc2 upstream. Commit f2096f94, entitled "tg3: Add 5720 H2BMC support", needed to add code to preserve some bits set by firmware. Unfortunately the new code causes throughput to stop after a chip reset because it enables state machines before they are ready. This patch undoes the problematic code. The bits will be restored later in the init sequence. Signed-off-by:
Matt Carlson <mcarlson@broadcom.com> Reviewed-by:
Michael Chan <mchan@broadcom.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Mike Christie authored
commit 03adb5f9 upstream. iscsi_sw_tcp_conn_restore_callbacks could have set the sk_user_data field to NULL then iscsi_sw_tcp_data_ready could read that and try to access the NULL pointer. This adds some checks for NULL sk_user_data in the sk callback functions and it uses the sk_callback_lock to set/get that sk_user_data field. Signed-off-by:
Mike Christie <michaelc@cs.wisc.edu> Signed-off-by:
James Bottomley <JBottomley@Parallels.com> Signed-off-by:
Hannes Reinecke <hare@suse.de> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Wanlong Gao authored
commit d11bb446 upstream. The bug is we're not able to remove the device from blkio cgroup's per-device control files if it gets unplugged. To reproduce the bug: # mount -t cgroup -o blkio xxx /cgroup # cd /cgroup # echo "8:0 1000" > blkio.throttle.read_bps_device # unplug the device # cat blkio.throttle.read_bps_device 8:0 1000 # echo "8:0 0" > blkio.throttle.read_bps_device -bash: echo: write error: No such device After patching, the device removal will succeed. Thanks for the comments of Paul, Zefan, and Vivek. Signed-off-by:
Wanlong Gao <gaowanlong@cn.fujitsu.com> Cc: Li Zefan <lizf@cn.fujitsu.com> Cc: Paul Menage <paul@paulmenage.org> Acked-by:
Vivek Goyal <vgoyal@redhat.com> Cc: Jens Axboe <axboe@kernel.dk> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Don Fry authored
commit 2249b011 upstream. This patch reverts commit 9b768832 which was introduced in 2.6.38-rc1. It works around a problem where the iwlagn driver stimulates a bug crashing (requiring power cycle to recover) some APs under heavy traffic. Signed-off-by:
Don Fry <donald.h.fry@intel.com> SIgned-off-by:
Wey-Yi Guy <wey-yi.w.guy@intel.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Larry Finger authored
commit daabead1 upstream. The eeprom data is stored in little-endian order in the rt2x00 library. As it was converted to cpu order in the read routines, the data need to be converted to LE on a big-endian platform. Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Rajkumar Manoharan authored
commit aa3d7eef upstream. During the association, the regulatory is updated by country IE that reaps the previously found beacons. The impact is that after a STA disconnects *or* when for any reason a regulatory domain change happens the beacon hint flag is not cleared therefore preventing future beacon hints to be learned. This is important as a regulatory domain change or a restore of regulatory settings would set back the passive scan and no-ibss flags on the channel. This is the right place to do this given that it covers any regulatory domain change. Reviewed-by:
Luis R. Rodriguez <mcgrof@gmail.com> Signed-off-by:
Rajkumar Manoharan <rmanohar@qca.qualcomm.com> Acked-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by:
John W. Linville <linville@tuxdriver.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Vrabel authored
commit e3b73c4a upstream. The patch "xen: use maximum reservation to limit amount of usable RAM" (d312ae87) breaks machines that do not use 'dom0_mem=' argument with: reserve RAM buffer: 000000133f2e2000 - 000000133fffffff (XEN) mm.c:4976:d0 Global bit is set to kernel page fffff8117e (XEN) domain_crash_sync called from entry.S (XEN) Domain 0 (vcpu#0) crashed on cpu#0: ... The reason being that the last E820 entry is created using the 'extra_pages' (which is based on how many pages have been freed). The mentioned git commit sets the initial value of 'extra_pages' using a hypercall which returns the number of pages (if dom0_mem has been used) or -1 otherwise. If the later we return with MAX_DOMAIN_PAGES as basis for calculation: return min(max_pages, MAX_DOMAIN_PAGES); and use it: extra_limit = xen_get_max_pages(); if (extra_limit >= max_pfn) extra_pages = extra_limit - max_pfn; else extra_pages = 0; which means we end up with extra_pages = 128GB in PFNs (33554432) - 8GB in PFNs (2097152, on this specific box, can be larger or smaller), and then we add that value to the E820 making it: Xen: 00000000ff000000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 000000133f2e2000 (usable) which is clearly wrong. It should look as so: Xen: 00000000ff000000 - 0000000100000000 (reserved) Xen: 0000000100000000 - 000000027fbda000 (usable) Naturally this problem does not present itself if dom0_mem=max:X is used. Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
David Vrabel authored
commit d312ae87 upstream. Use the domain's maximum reservation to limit the amount of extra RAM for the memory balloon. This reduces the size of the pages tables and the amount of reserved low memory (which defaults to about 1/32 of the total RAM). On a system with 8 GiB of RAM with the domain limited to 1 GiB the kernel reports: Before: Memory: 627792k/4472000k available After: Memory: 549740k/11132224k available A increase of about 76 MiB (~1.5% of the unused 7 GiB). The reserved low memory is also reduced from 253 MiB to 32 MiB. The total additional usable RAM is 329 MiB. For dom0, this requires at patch to Xen ('x86: use 'dom0_mem' to limit the number of pages for dom0') (c/s 23790) Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Signed-off-by:
Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dave Hansen authored
commit 32ef4384 upstream. This is modeled after the smaps code. It detects transparent hugepages and then does a single gather_stats() for the page as a whole. This has two benifits: 1. It is more efficient since it does many pages in a single shot. 2. It does not have to break down the huge page. Signed-off-by:
Dave Hansen <dave@linux.vnet.ibm.com> Acked-by:
Hugh Dickins <hughd@google.com> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
Dave Hansen authored
commit 3200a8aa upstream. gather_pte_stats() does a number of checks on a target page to see whether it should even be considered for statistics. This breaks that code out in to a separate function so that we can use it in the transparent hugepage case in the next patch. Signed-off-by:
Dave Hansen <dave@linux.vnet.ibm.com> Acked-by:
Hugh Dickins <hughd@google.com> Reviewed-by:
Christoph Lameter <cl@gentwo.org> Acked-by:
David Rientjes <rientjes@google.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-