aboutsummaryrefslogtreecommitdiffstats
path: root/init/do_mounts_md.c (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2012-05-04hfsplus: Fix potential buffer overflowsGreg Kroah-Hartman2-0/+15
Commit ec81aecb2966 ("hfs: fix a potential buffer overflow") fixed a few potential buffer overflows in the hfs filesystem. But as Timo Warns pointed out, these changes also need to be made on the hfsplus filesystem as well. Reported-by: Timo Warns <warns@pre-sense.de> Acked-by: WANG Cong <amwang@redhat.com> Cc: Alexey Khoroshilov <khoroshilov@ispras.ru> Cc: Miklos Szeredi <mszeredi@suse.cz> Cc: Sage Weil <sage@newdream.net> Cc: Eugene Teo <eteo@redhat.com> Cc: Roman Zippel <zippel@linux-m68k.org> Cc: Al Viro <viro@zeniv.linux.org.uk> Cc: Christoph Hellwig <hch@lst.de> Cc: Alexey Dobriyan <adobriyan@gmail.com> Cc: Dave Anderson <anderson@redhat.com> Cc: stable <stable@vger.kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-04CPU frequency drivers MAINTAINERS updateDave Jones1-3/+0
Remove myself as cpufreq maintainer. x86 driver changes can go through the regular x86/ACPI trees. ARM driver changes through the ARM trees. cpufreq core changes are rare these days, and can just go to lkml/direct. Signed-off-by: Dave Jones <davej@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-04seqlock: add 'raw_seqcount_begin()' functionLinus Torvalds1-0/+21
The normal read_seqcount_begin() function will wait for any current writers to exit their critical region by looping until the sequence count is even. That "wait for sequence count to stabilize" is the right thing to do if the read-locker will just retry the whole operation on contention: no point in doing a potentially expensive reader sequence if we know at the beginning that we'll just end up re-doing it all. HOWEVER. Some users don't actually retry the operation, but instead will abort and do the operation with proper locking. So the sequence count case may be the optimistic quick case, but in the presense of writers you may want to do full locking in order to guarantee forward progress. The prime example of this would be the RCU name lookup. And in that case, you may well be better off without the "retry early", and are in a rush to instead get to the failure handling. Thus this "raw" interface that just returns the sequence number without testing it - it just forces the low bit to zero so that read_seqcount_retry() will always fail such a "active concurrent writer" scenario. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-04Fix __read_seqcount_begin() to use ACCESS_ONCE for sequence value readLinus Torvalds1-1/+1
We really need to use a ACCESS_ONCE() on the sequence value read in __read_seqcount_begin(), because otherwise the compiler might end up reloading the value in between the test and the return of it. As a result, it might end up returning an odd value (which means that a write is in progress). If the reader is then fast enough that that odd value is still the current one when the read_seqcount_retry() is done, we might end up with a "successful" read sequence, even despite the concurrent write being active. In practice this probably never really happens - there just isn't anything else going on around the read of the sequence count, and the common case is that we end up having a read barrier immediately afterwards. So the code sequence in which gcc might decide to reaload from memory is small, and there's no reason to believe it would ever actually do the reload. But if the compiler ever were to decide to do so, it would be incredibly annoying to debug. Let's just make sure. Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-04drm/radeon: clarify and extend wb setup on APUs and NI+ asicsAlex Deucher1-2/+2
Use family rather than DCE check for clarity, also always use wb on APUs, there will never be AGP variants. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-04md/bitmap: fix calculation of 'chunks' - missing shift.NeilBrown2-5/+1
commit 61a0d80c "md/bitmap: discard CHUNK_BLOCK_SHIFT macro" replaced CHUNK_BLOCK_RATIO() by the same text that was replacing CHUNK_BLOCK_SHIFT() - which is clearly wrong. The result is that 'chunks' is often too small by 1, which can sometimes result in a crash (not sure how). So use the correct replacement, and get rid of CHUNK_BLOCK_RATIO which is no longe used. Reported-by: Karl Newman <siliconfiend@gmail.com> Tested-by: Karl Newman <siliconfiend@gmail.com> Signed-off-by: NeilBrown <neilb@suse.de>
2012-05-03fs/cifs: fix parsing of dfs referralsStefan Metzmacher1-1/+5
The problem was that the first referral was parsed more than once and so the caller tried the same referrals multiple times. The problem was introduced partly by commit 066ce6899484d9026acd6ba3a8dbbedb33d7ae1b, where 'ref += le16_to_cpu(ref->Size);' got lost, but that was also wrong... Cc: <stable@vger.kernel.org> Signed-off-by: Stefan Metzmacher <metze@samba.org> Tested-by: Björn Jacke <bj@sernet.de> Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-03efivars: Improve variable validationMatthew Garrett1-16/+30
Ben Hutchings pointed out that the validation in efivars was inadequate - most obviously, an entry with size 0 would server as a DoS against the kernel. Improve this based on his suggestions. Signed-off-by: Matthew Garrett <mjg@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-03vfs: make word-at-a-time accesses handle a non-existing pageLinus Torvalds4-7/+58
It turns out that there are more cases than CONFIG_DEBUG_PAGEALLOC that can have holes in the kernel address space: it seems to happen easily with Xen, and it looks like the AMD gart64 code will also punch holes dynamically. Actually hitting that case is still very unlikely, so just do the access, and take an exception and fix it up for the very unlikely case of it being a page-crosser with no next page. And hey, this abstraction might even help other architectures that have other issues with unaligned word accesses than the possible missing next page. IOW, this could do the byte order magic too. Peter Anvin fixed a thinko in the shifting for the exception case. Reported-and-tested-by: Jana Saout <jana@saout.de> Cc: Peter Anvin <hpa@zytor.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2012-05-03cifs: make sure we ignore the credentials= and cred= optionsJeff Layton1-0/+2
Older mount.cifs programs passed this on to the kernel after parsing the file. Make sure the kernel ignores that option. Should fix: https://bugzilla.kernel.org/show_bug.cgi?id=43195 Cc: Sachin Prabhu <sprabhu@redhat.com> Reported-by: Ronald <ronald645@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-03[CIFS] Update cifs version to 1.78Steve French1-1/+1
Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-03cifs - check S_AUTOMOUNT in revalidateIan Kent1-5/+12
When revalidating a dentry, if the inode wasn't known to be a dfs entry when the dentry was instantiated, such as when created via ->readdir(), the DCACHE_NEED_AUTOMOUNT flag needs to be set on the dentry in ->d_revalidate(). The false return from cifs_d_revalidate(), due to the inode now being marked with the S_AUTOMOUNT flag, might not invalidate the dentry if there is a concurrent unlazy path walk. This is because the dentry reference count will be at least 2 in this case causing d_invalidate() to return EBUSY. So the asumption that the dentry will be discarded then correctly instantiated via ->lookup() might not hold. Signed-off-by: Ian Kent <raven@themaw.net> Reviewed-by: Jeff Layton <jlayton@redhat.com> Cc: Steve French <smfrench@gmail.com> Cc: linux-cifs@vger.kernel.org Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-03ata: ahci_platform: Add synopsys ahci controller in DT's compatible listViresh Kumar2-3/+3
SPEAr13xx series of SoCs contain Synopsys AHCI SATA Controller which shares ahci_platform driver with other controller versions. This patch updates DT compatible list for ahci_platform. It also updates and renames binding documentation to more generic name. Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Cc: Rob Herring <rob.herring@calxeda.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2012-05-03ata/pata_arasan_cf: Move arasan_cf_pm_ops out of #ifdef, #endif macrosViresh Kumar1-3/+1
#ifdef, #endif is not required in definition/usage of arasan_cf_pm_ops. So, move this definition and its usage outside of them. Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2012-05-03libata: init ata_print_id to 0Tero Roponen1-1/+1
When comparing the dmesg between 3.4-rc3 and 3.4-rc4 I found the following differences: -ata1: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff100 irq 47 -ata2: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff180 irq 47 -ata3: DUMMY +ata2: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff100 irq 47 +ata3: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff180 irq 47 ata4: DUMMY ata5: DUMMY -ata6: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff380 irq 47 +ata6: DUMMY +ata7: SATA max UDMA/133 abar m2048@0xf9fff000 port 0xf9fff380 irq 47 The change of numbering comes from commit 85d6725b7c0d7e3f ("libata: make ata_print_id atomic") that changed lines like ap->print_id = ata_print_id++; to ap->print_id = atomic_inc_return(&ata_print_id); As the latter behaves like ++ata_print_id, we must initialize it to zero to start the numbering from one. Signed-off-by: Tero Roponen <tero.roponen@gmail.com> Acked-by: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2012-05-03ahci: Detect Marvell 88SE9172 SATA controllerMatt Johnson1-0/+2
The Marvell 88SE9172 SATA controller (PCI ID 1b4b 917a) already worked once it was detected, but was missing an ahci_pci_tbl entry. Boot tested on a Gigabyte Z68X-UD3H-B3 motherboard. Signed-off-by: Matt Johnson <johnso87@illinois.edu> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2012-05-03libata: skip old error history when counting probe trialsLin Ming1-1/+2
Commit d902747("[libata] Add ATA transport class") introduced ATA_EFLAG_OLD_ER to mark entries in the error ring as cleared. But ata_count_probe_trials_cb() didn't check this flag and it still counts the old error history. So wrong probe trials count is returned and it causes problem, for example, SATA link speed is slowed down from 3.0Gbps to 1.5Gbps. Fix it by checking ATA_EFLAG_OLD_ER in ata_count_probe_trials_cb(). Cc: stable <stable@vger.kernel.org> # 2.6.37+ Signed-off-by: Lin Ming <ming.m.lin@intel.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
2012-05-03drm/i915: enable dip before writing data on gen4Paulo Zanoni1-1/+1
While testing with the intel_infoframes tool on gen4, I see that when video DIP is disabled, what we write to the DATA memory is not exactly what we read back later. This regression has been introduce in commit 64a8fc0145a1d0fdc25fc9367c2e6c621955fb3b Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Sep 22 11:16:00 2011 +0530 drm/i915: fix ILK+ infoframe support That commit was setting VIDEO_DIP_CTL to 0 when initializing, which caused the problem. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=43947 Cc: stable@kernel.org Tested-by: Yang Guang <guang.a.yang@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Eugeni Dodonov <eugeni.dodonov@intel.com> [danvet: Pimped commit message by using the usual commit citation layout.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-03nouveau: initialise has_optimus variable.Dave Airlie1-1/+1
We should initialise this to 0 really to avoid getting false positives. Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
2012-05-03sungem: Fix WakeOnLanGerard Lledo1-1/+1
WakeOnLan was broken in this driver because gp->asleep_wol is a 1-bit bitfield and it was being assigned WAKE_MAGIC, which is (1 << 5). gp->asleep_wol remains 0 and the machine never wakes up. Fixed by casting gp->wake_on_lan to bool. Tested on an iBook G4. Signed-off-by: Gerard Lledo <gerard.lledo@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-02tcp: change tcp_adv_win_scale and tcp_rmem[2]Eric Dumazet3-7/+8
tcp_adv_win_scale default value is 2, meaning we expect a good citizen skb to have skb->len / skb->truesize ratio of 75% (3/4) In 2.6 kernels we (mis)accounted for typical MSS=1460 frame : 1536 + 64 + 256 = 1856 'estimated truesize', and 1856 * 3/4 = 1392. So these skbs were considered as not bloated. With recent truesize fixes, a typical MSS=1460 frame truesize is now the more precise : 2048 + 256 = 2304. But 2304 * 3/4 = 1728. So these skb are not good citizen anymore, because 1460 < 1728 (GRO can escape this problem because it build skbs with a too low truesize.) This also means tcp advertises a too optimistic window for a given allocated rcvspace : When receiving frames, sk_rmem_alloc can hit sk_rcvbuf limit and we call tcp_prune_queue()/tcp_collapse() too often, especially when application is slow to drain its receive queue or in case of losses (netperf is fast, scp is slow). This is a major latency source. We should adjust the len/truesize ratio to 50% instead of 75% This patch : 1) changes tcp_adv_win_scale default to 1 instead of 2 2) increase tcp_rmem[2] limit from 4MB to 6MB to take into account better truesize tracking and to allow autotuning tcp receive window to reach same value than before. Note that same amount of kernel memory is consumed compared to 2.6 kernels. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Neal Cardwell <ncardwell@google.com> Cc: Tom Herbert <therbert@google.com> Cc: Yuchung Cheng <ycheng@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-02net: l2tp: unlock socket lock before returning from l2tp_ip_sendmsgSasha Levin1-1/+2
l2tp_ip_sendmsg could return without releasing socket lock, making it all the way to userspace, and generating the following warning: [ 130.891594] ================================================ [ 130.894569] [ BUG: lock held when returning to user space! ] [ 130.897257] 3.4.0-rc5-next-20120501-sasha #104 Tainted: G W [ 130.900336] ------------------------------------------------ [ 130.902996] trinity/8384 is leaving the kernel with locks still held! [ 130.906106] 1 lock held by trinity/8384: [ 130.907924] #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550 Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c"). Signed-off-by: Sasha Levin <levinsasha928@gmail.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-02drop_monitor: prevent init path from scheduling on the wrong cpuNeil Horman1-5/+7
I just noticed after some recent updates, that the init path for the drop monitor protocol has a minor error. drop monitor maintains a per cpu structure, that gets initalized from a single cpu. Normally this is fine, as the protocol isn't in use yet, but I recently made a change that causes a failed skb allocation to reschedule itself . Given the current code, the implication is that this workqueue reschedule will take place on the wrong cpu. If drop monitor is used early during the boot process, its possible that two cpus will access a single per-cpu structure in parallel, possibly leading to data corruption. This patch fixes the situation, by storing the cpu number that a given instance of this per-cpu data should be accessed from. In the case of a need for a reschedule, the cpu stored in the struct is assigned the rescheule, rather than the currently executing cpu Tested successfully by myself. Signed-off-by: Neil Horman <nhorman@tuxdriver.com> CC: David Miller <davem@davemloft.net> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-02usbnet: fix failure handling in usbnet_probetom.leiming@gmail.com1-1/+3
If register_netdev returns failure, the dev->interrupt and its transfer buffer should be released, so just fix it. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-02usbnet: fix leak of transfer buffer of dev->interrupttom.leiming@gmail.com1-0/+1
The transfer buffer of dev->interrupt is allocated in .probe path, but not freed in .disconnet path, so mark the interrupt URB as URB_FREE_BUFFER to free the buffer when the URB is destroyed. Signed-off-by: Ming Lei <tom.leiming@gmail.com> Acked-by: Oliver Neukum <oneukum@suse.de> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-02ucc_geth: Add 16 bytes to max TX frame for VLANsJoakim Tjernlund1-3/+3
Creating a VLAN interface on top of ucc_geth adds 4 bytes to the frame and the HW controller is not prepared to TX a frame bigger than 1518 bytes which is 4 bytes too small for a full VLAN frame. Add 16 bytes which will handle the a simple VLAN and leaves 12 bytes for future expansion. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-02net: ucc_geth, increase no. of HW RX descriptorsJoakim Tjernlund1-1/+1
In a busy network we see ucc_geth is dropping RX pkgs every now and then. Increase the RX queues HW descriptors from 16 to 32 to deal with this. Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-02fixing dmi match for hp t5745 and hp st5747 thin clientMarc Gariepy1-2/+2
Match the correct information which is DMI_PRODUCT_NAME instead of DMI_BOARD_NAME See dmidecode information on launchpad for both thin client: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911920 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/911916 Signed-off-by: Marc Gariepy <mgariepy@ubuntu.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-02drm/i915: Only enable IPS polling for gen5Chris Wilson2-5/+13
On SandyBridge IPS was entirely implemented in hardware and not reliant on the driver monitoring power consumption and feeding back desired run states, so the hardware is able to adapt quicker and more flexibly. Which is a huge relief for us as we no longer have to carry empirically derived magic algorithms. Yet despite the advance in technology, the driver was still doing its IPS polling on all machines. Restrict it to the only supported hardware, Clarkdale/Arrandale. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-02drm/i915: Do not read non-existent DPLL registers on PCH hardwareChris Wilson1-4/+5
We only execute intel_decrease_pllclock for pre-PCH hardware, typically gen4 mobiles. However, in the variable declaration we did read from the non-PCH DPLL register, quite naughty and detected by SandyBridge. Reported-and-tested-by: Andrey Rahmatullin <wrar@wrar.name> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=49025 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-05-01cifs: add missing initialization of server->req_lockJeff Layton1-0/+1
Cc: Pavel Shilovsky <piastryyy@gmail.com> Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-01cifs: don't cap ra_pages at the same level as default_backing_dev_infoJeff Layton1-17/+1
While testing, I've found that even when we are able to negotiate a much larger rsize with the server, on-the-wire reads often end up being capped at 128k because of ra_pages being capped at that level. Lifting this restriction gave almost a twofold increase in sequential read performance on my craptactular KVM test rig with a 1M rsize. I think this is safe since the actual ra_pages that the VM requests is run through max_sane_readahead() prior to submitting the I/O. Under memory pressure we should end up with large readahead requests being suppressed anyway. Signed-off-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-01CIFS: Fix indentation in cifs_show_optionsSachin Prabhu1-1/+1
Trivial patch which fixes a misplaced tab in cifs_show_options(). Signed-off-by: Sachin Prabhu <sprabhu@redhat.com> Signed-off-by: Steve French <sfrench@us.ibm.com>
2012-05-01USB: ehci-tegra: remove redundant gpio_set_valueStephen Warren1-1/+0
The immediately preceding gpio_direction_output() already set the value, so there's no need to repeat it. This also prevents gpio_set_value() from WARNing when the GPIO is sleepable (e.g. is on an I2C expander); the set direction API is always sleepable, but plain set_value isn't. Cc: <stable@vger.kernel.org> # v3.3 Signed-off-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-01EHCI: update PM methods in ehci-tegra.cAlan Stern1-180/+195
This patch (as1547) rearranges the Power Management parts of the ehci-tegra driver to match the conventions used in other EHCI platform drivers. In particular, the controller should not be powered down by the root hub's suspend routine; the controller's power level should be managed by the controller's own PM methods. The end result of the patch is that the standard ehci_bus_suspend() and ehci_bus_resume() methods can be used instead of special-purpose routines. The driver now uses the standard dev_pm_ops methods instead of legacy power management. Since there is no supported wakeup mechanism for the controller, runtime suspend is forbidden by default (this can be overridden via sysfs, if desired). These adjustments are needed in order to make ehci-tegra compatible with recent changes to the USB core. The core now checks the root hub's status following bus suspend; if the controller is automatically powered down during bus suspend then the check will fail and the root hub will be resumed immediately. Doing the controller power-down in a separate method avoids this problem. Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Acked-by: Stephen Warren <swarren@wwwdotorg.org> Tested-by: Stephen Warren <swarren@wwwdotorg.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-01vt: Fix deadlock on scroll-lockAlan Cox1-7/+19
Fixing the locking accidentally replaced a race in the scroll lock handling with a deadlock. Turn it back into a race for now. The basic problem is that there are two paths into the tty stop/start helpers. One via the tty layer ^S/^Q handling where we need to take the kbd_event_lock and one via the special keyboard handler for fn_hold where we already hold it. Probably we need to split out into a separate LED lock but for now just go back to the race as it's a bit close to release. Reported-by: Clemens Ladisch <clemens@ladisch.de> Cc: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2012-05-01netem: fix possible skb leakEric Dumazet1-4/+2
skb_checksum_help(skb) can return an error, we must free skb in this case. qdisc_drop(skb, sch) can also be feeded with a NULL skb (if skb_unshare() failed), so lets use this generic helper. Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Stephen Hemminger <shemminger@osdl.org> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-01sky2: fix receive length error in mixed non-VLAN/VLAN trafficstephen hemminger2-12/+17
Bug: The VLAN bit of the MAC RX Status Word is unreliable in several older supported chips. Sometimes the VLAN bit is not set for valid VLAN packets and also sometimes the VLAN bit is set for non-VLAN packets that came after a VLAN packet. This results in a receive length error when VLAN hardware tagging is enabled. Fix: Variation on original fix proposed by Mirko. The VLAN information is decoded in the status loop, and can be applied to the received SKB there. This eliminates the need for the separate tag field in the interface data structure. The tag has to be copied and cleared if packet is copied. This version checked out with vlan and normal traffic. Note: vlan_tx_tag_present should be renamed vlan_tag_present, but that is outside scope of this. Reported-by: Mirko Lindner <mlindner@marvell.com> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-01sky2: propogate rx hash when packet is copiedstephen hemminger1-0/+3
When a small packet is received, the driver copies it to a new skb to allow reusing the full size Rx buffer. The copy was propogating the checksum offload but not the receive hash information. The bug is impact was mostly harmless and therefore not observed until reviewing this area of code. Signed-off-by: Stephen Hemminger <shemminger@vyatta.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-01hwmon: (coretemp) Increase CPU core limitGuenter Roeck1-1/+1
CPU core ID is used to index the core_data[] array. The core ID is, however, not sequential; 10-core CPUS can have a core ID as high as 25. Increase the limit to 32 to be able to deal with current CPUs. Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com> Cc: stable@vger.kernel.org # 3.0+ Acked-by: Jean Delvare <khali@linux-fr.org> Acked-by: Durgadoss R <durgadoss.r@intel.com>
2012-05-01hwmon: (coretemp) fix oops on cpu unplugKirill A. Shutemov1-0/+4
coretemp tries to access core_data array beyond bounds on cpu unplug if core id of the cpu if more than NUM_REAL_CORES-1. BUG: unable to handle kernel NULL pointer dereference at 000000000000013c IP: [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] PGD 673e5a067 PUD 66e9b3067 PMD 0 Oops: 0000 [#1] SMP CPU 79 Modules linked in: sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter nf_conntrack_ipv4 nf_defrag_ipv4 ip6_tables xt_state nf_conntrack coretemp crc32c_intel asix tpm_tis pcspkr usbnet iTCO_wdt i2c_i801 microcode mii joydev tpm i2c_core iTCO_vendor_support tpm_bios i7core_edac igb ioatdma edac_core dca megaraid_sas [last unloaded: oprofile] Pid: 3315, comm: set-cpus Tainted: G W 3.4.0-rc5+ #2 QCI QSSC-S4R/QSSC-S4R RIP: 0010:[<ffffffffa00159af>] [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] RSP: 0018:ffff880472fb3d48 EFLAGS: 00010246 RAX: 0000000000000124 RBX: 0000000000000034 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000046 RDI: 0000000000000246 RBP: ffff880472fb3d88 R08: ffff88077fcd36c0 R09: 0000000000000001 R10: ffffffff8184bc48 R11: 0000000000000000 R12: ffff880273095800 R13: 0000000000000013 R14: ffff8802730a1810 R15: 0000000000000000 FS: 00007f694a20f720(0000) GS:ffff88077fcc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 000000000000013c CR3: 000000067209b000 CR4: 00000000000007e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process set-cpus (pid: 3315, threadinfo ffff880472fb2000, task ffff880471fa0000) Stack: ffff880277b4c308 0000000000000003 ffff880472fb3d88 0000000000000005 0000000000000034 00000000ffffffd1 ffffffff81cadc70 ffff880472fb3e14 ffff880472fb3dc8 ffffffff8161f48d ffff880471fa0000 0000000000000034 Call Trace: [<ffffffff8161f48d>] notifier_call_chain+0x4d/0x70 [<ffffffff8107f1be>] __raw_notifier_call_chain+0xe/0x10 [<ffffffff81059d30>] __cpu_notify+0x20/0x40 [<ffffffff815fa251>] _cpu_down+0x81/0x270 [<ffffffff815fa477>] cpu_down+0x37/0x50 [<ffffffff815fd6a3>] store_online+0x63/0xc0 [<ffffffff813c7078>] dev_attr_store+0x18/0x30 [<ffffffff811f02cf>] sysfs_write_file+0xef/0x170 [<ffffffff81180443>] vfs_write+0xb3/0x180 [<ffffffff8118076a>] sys_write+0x4a/0x90 [<ffffffff816236a9>] system_call_fastpath+0x16/0x1b Code: 48 c7 c7 94 60 01 a0 44 0f b7 ac 10 ac 00 00 00 31 c0 e8 41 b7 5f e1 41 83 c5 02 49 63 c5 49 8b 44 c4 10 48 85 c0 74 56 45 31 ff <39> 58 18 75 4e eb 1f 49 63 d7 4c 89 f7 48 89 45 c8 48 6b d2 28 RIP [<ffffffffa00159af>] coretemp_cpu_callback+0x93/0x1ba [coretemp] RSP <ffff880472fb3d48> CR2: 000000000000013c Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Cc: stable@vger.kernel.org # 3.0+ Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
2012-05-01net: fix two typos in skbuff.hEric Dumazet1-2/+2
fix kernel doc typos in function names Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-05-01ktest: Fix reboot on success stopping all rebootsSteven Rostedt1-2/+8
The change to let individual tests decide to reboot the machine on success of the entire test also prevented errors from rebooting when an error was detected. The "no_reboot" variable was only cleared if the test had reboot_on_success set. But the no_reboot variable also prevents the test rebooting when an error was detected even when REBOOT_ON_ERROR was set. Add a new "reboot_success" variable that is used to determine if the test should reboot on success and not touch the no_reboot variable. Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2012-05-01ktest.pl: Fix combined usage of BISECT_REVERSE and BISECT_SKIPRuss Dill1-1/+1
When BISECT_REVERSE and BISECT_SKIP are used together with boot or test testing, build failures are treated as boot or test failures and 'git bisect bad' is executed instead of 'git bisect skip'. This is because the $ret value of -1 is treated as a build failure, but the $reverse_bisect logic does not properly handle this. Simple fix, only invert it if it is positive. Link: http://lkml.kernel.org/r/1335235380-8509-1-git-send-email-Russ.Dill@ti.com Signed-off-by: Russ Dill <Russ.Dill@ti.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
2012-05-01mfd: Fix build breakage in omap-usb-host.cRuss Dill1-0/+1
'ARM: OMAP3: USB: Fix the EHCI ULPI PHY reset issue' removes the include for linux/gpio.h from omap-usb-host.c. This include indirectly includes plat/cpu.h which is required by omap-usb-host.c. Fix the build breakage by including it directly. Acked-by: Keshava Munegowda <keshava_mgowda@ti.com> Acked-by: Kevin Hilman <khilman@ti.com> Tested-by: Arend van Spriel <arend@broadcom.com> Signed-off-by: Russ Dill <Russ.Dill@ti.com> Signed-off-by: Samuel Ortiz <sameo@linux.intel.com>
2012-04-30cxgb3: Don't call cxgb_vlan_mode until q locks are initializedRoland Dreier1-46/+46
The driver calls cxgb_vlan_mode() from init_one(). This calls into synchronize_rx(), which locks all the q locks, but the q locks are not initialized until cxgb_up() -> setup_sge_qsets(). So move the call to cxgb_vlan_mode() into cxgb_up(), after the call to setup_sge_qsets(). We also move the body of these functions up higher to avoid having to a forward declaration. This was found because of the lockdep warning: INFO: trying to register non-static key. the code is fine but needs lockdep annotation. turning off the locking correctness validator. Pid: 323, comm: work_for_cpu Not tainted 3.4.0-rc5 #28 Call Trace: [<ffffffff8106e767>] register_lock_class+0x108/0x2d0 [<ffffffff8106ff42>] __lock_acquire+0xd3/0xd06 [<ffffffff81070fd0>] lock_acquire+0xbf/0xfe [<ffffffff813862a6>] _raw_spin_lock_irq+0x36/0x45 [<ffffffffa01e71aa>] cxgb_vlan_mode+0x96/0xcb [cxgb3] [<ffffffffa01f90eb>] init_one+0x8c4/0x980 [cxgb3] [<ffffffff811fcbf0>] local_pci_probe+0x3f/0x70 [<ffffffff81042206>] do_work_for_cpu+0x10/0x22 [<ffffffff810482de>] kthread+0xa1/0xa9 [<ffffffff8138e234>] kernel_thread_helper+0x4/0x10 Contrary to what lockdep says, the code is not fine: we are locking an uninitialized spinlock. Signed-off-by: Roland Dreier <roland@purestorage.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2012-04-30ixgbe: fix calling skb_put on nonlinear skb assertion bugYi Zou1-0/+1
With the support to bounce buffer added, the skb is coming as nonlinear in the case of non-DDPed data frames for FCoE, which is mostly ok as the FCoE stack would take care of that. However, for target mode, we have to set the FC CRC and FC EOF field to allow the protocol stack to not drop the frame for the last data frame of that sequence. So fix this by linearizing the skb first before doing skb_put(). Signed-off-by: Yi Zou <yi.zou@intel.com> Tested-by: Marcus Dennis <marcusx.e.dennis@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-30ixgbe: Fix a memory leak in IEEE DCBAlexander Duyck1-4/+5
The driver was freeing memory in shutdown instead of remove. As a result we were leaking memory if IEEE DCB was enabled and we loaded/unloaded the driver. This change moves the freeing of the memory into the remove routine where it belongs. Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com> Acked-by: John Fastabend <john.r.fastabend@intel.com> Tested-by: Ross Brattain <ross.b.brattain@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-30igbvf: fix the bug when initializing the igbvfSamuel Liao1-2/+2
Maybe it's a typo, but it cause that igbvf can't be initialized successfully. Set perm_addr value using valid dev_addr, although which is equal to hw.mac.addr. Signed-off-by: Samuel Liao <samuelliao@tencent.com> Signed-off-by: Shan Wei <davidshan@tencent.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2012-04-30smsc75xx: enable mac to detect speed/duplex from phySteve Glendinning1-0/+8
This patch sets the automatic speed and duplex detection bits in MAC_CR to enable the mac to determine its speed automatically from the phy. Note this must be done BEFORE the receiver or transmitter is enabled. Signed-off-by: Stephane Fillod <fillods@users.sf.net> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net> Signed-off-by: David S. Miller <davem@davemloft.net>