aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2013-12-11ARM: pxa: tosa: fix keys mappingDmitry Eremin-Solenikov1-51/+51
When converting from tosa-keyboard driver to matrix keyboard, tosa keys received extra 1 column shift. Replace that with correct values to make keyboard work again. Fixes: f69a6548c9d5 ('[ARM] pxa/tosa: make use of the matrix keypad driver') Signed-off-by: Dmitry Eremin-Solenikov <[email protected]> Signed-off-by: Haojian Zhuang <[email protected]> Cc: [email protected] Signed-off-by: Olof Johansson <[email protected]>
2013-12-12Merge remote-tracking branches 'asoc/fix/atmel', 'asoc/fix/fsl', ↵Mark Brown7-15/+54
'asoc/fix/tegra' and 'asoc/fix/wm8962' into asoc-linus
2013-12-12Merge remote-tracking branch 'asoc/fix/dma' into asoc-linusMark Brown1-11/+27
2013-12-12Merge remote-tracking branch 'asoc/fix/core' into asoc-linusMark Brown1-2/+3
2013-12-11qla2xxx: Fix schedule_delayed_work() for target timeout calculationsShivaram Upadhyayula1-4/+5
This patch fixes two cases in qla_target.c code where the schedule_delayed_work() value was being incorrectly calculated from sess->expires - jiffies. Signed-off-by: Shivaram U <[email protected]> Cc: <[email protected]> #3.6+ Signed-off-by: Nicholas Bellinger <[email protected]>
2013-12-11Merge remote-tracking branches 'regulator/fix/as3722' and ↵Mark Brown2-2/+2
'regulator/fix/pfuze100' into regulator-linus
2013-12-11Revert "8390 : Replace ei_debug with msg_enable/NETIF_MSG_* feature"David S. Miller16-426/+302
This reverts commit 99023e90fe5c147ea0665bda86764ea44f08a622. Accidently checked this into 'net' instead of 'net-next'. Signed-off-by: David S. Miller <[email protected]>
2013-12-118390 : Replace ei_debug with msg_enable/NETIF_MSG_* featureMatthew Whitehead16-302/+426
Removed the shared ei_debug variable. Replaced it by adding u32 msg_enable to the private struct ei_device. Now each 8390 ethernet instance has a per-device logging variable. Changed older style printk() calls to more canonical forms. Tested on: ne, ne2k-pci, smc-ultra, and wd hardware. V4.0 - Substituted pr_info() and pr_debug() for printk() KERN_INFO and KERN_DEBUG V3.0 - Checked for cases where pr_cont() was most appropriate choice. - Changed module parameter from 'debug' to 'msg_enable' because debug was no longer the best description. V2.0 - Changed netif_msg_(drv|probe|ifdown|rx_err|tx_err|tx_queued|intr|rx_status|hw) to netif_(dbg|info|warn|err) where possible. Signed-off-by: Matthew Whitehead <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11xen-netback: make sure skb linear area covers checksum fieldPaul Durrant1-32/+28
skb_partial_csum_set requires that the linear area of the skb covers the checksum field. The checksum setup code in netback was only doing that pullup in the case when the pseudo header checksum was being recalculated though. This patch makes that pullup unconditional. (I pullup the whole transport header just for simplicity; the requirement is only for the check field but in the case of UDP this is the last field in the header and in the case of TCP it's the last but one). The lack of pullup manifested as failures running Microsoft HCK network tests on a pair of Windows 8 VMs and it has been verified that this patch fixes the problem. Suggested-by: Jan Beulich <[email protected]> Signed-off-by: Paul Durrant <[email protected]> Cc: Wei Liu <[email protected]> Cc: Ian Campbell <[email protected]> Cc: David Vrabel <[email protected]> Reviewed-by: Jan Beulich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11hwmon: HIH-6130: Support I2C bus drivers without I2C_FUNC_SMBUS_QUICKJosé Miguel Gonçalves1-2/+14
Some I2C bus drivers do not allow zero-length data transfers which are required to start a measurement with the HIH6130/1 sensor. Nevertheless, we can overcome this limitation by writing a zero dummy byte. This byte is ignored by the sensor and was verified to be working with the OMAP I2C bus driver in a BeagleBone board. Signed-off-by: José Miguel Gonçalves <[email protected]> [Guenter Roeck: Simplified complexity of write_length initialization] Cc: [email protected] # v3.10+ Signed-off-by: Guenter Roeck <[email protected]>
2013-12-11net: smc91x: Fix device tree based configuration so it's usableTony Lindgren2-10/+39
Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c) added minimal device tree support to smc91x, but it's not working on many platforms because of the lack of some key configuration bits. Fix the issue by parsing the necessary configuration like the smc911x driver is doing. As most smc91x users seem to use 16-bit access, let's default to that if no reg-io-width is specified. Cc: Nicolas Pitre <[email protected]> Cc: Mark Rutland <[email protected]> Cc: [email protected] Cc: [email protected] Acked-by: Nishanth Menon <[email protected]> Signed-off-by: Tony Lindgren <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11udp: ipv4: fix potential use after free in udp_v4_early_demux()Eric Dumazet1-3/+6
pskb_may_pull() can reallocate skb->head, we need to move the initialization of iph and uh pointers after its call. Fixes: 421b3885bf6d ("udp: ipv4: Add udp early demux") Signed-off-by: Eric Dumazet <[email protected]> Cc: Shawn Bohrer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11macvtap: signal truncated packetsJason Wang1-5/+6
macvtap_put_user() never return a value grater than iov length, this in fact bypasses the truncated checking in macvtap_recvmsg(). Fix this by always returning the size of packet plus the possible vlan header to let the trunca checking work. Cc: Vlad Yasevich <[email protected]> Cc: Zhi Yong Wu <[email protected]> Cc: Michael S. Tsirkin <[email protected]> Signed-off-by: Jason Wang <[email protected]> Acked-by: Vlad Yasevich <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11tun: unbreak truncated packet signallingJason Wang1-7/+9
Commit 6680ec68eff47d36f67b4351bc9836fd6cba9532 (tuntap: hardware vlan tx support) breaks the truncated packet signal by nev return a length greater than iov length in tun_put_user(). This patch fixes by always return the length of packet plus possible vlan header. Caller can detect the truncated packet by comparing the return value and the size of io length. Cc: Zhi Yong Wu <[email protected]> Cc: Michael S. Tsirkin <[email protected]> Signed-off-by: Vlad Yasevich <[email protected]> Signed-off-by: Jason Wang <[email protected]> Acked-by: Michael S. Tsirkin <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11net: sched: htb: fix the calculation of quantumYang Yingliang1-8/+12
Now, 32bit rates may be not the true rate. So use rate_bytes_ps which is from max(rate32, rate64) to calcualte quantum. Signed-off-by: Yang Yingliang <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11net: sched: tbf: fix the calculation of max_sizeYang Yingliang1-45/+70
Current max_size is caluated from rate table. Now, the rate table has been replaced and it's wrong to caculate max_size based on this rate table. It can lead wrong calculation of max_size. The burst in kernel may be lower than user asked, because burst may gets some loss when transform it to buffer(E.g. "burst 40kb rate 30mbit/s") and it seems we cannot avoid this loss. Burst's value(max_size) based on rate table may be equal user asked. If a packet's length is max_size, this packet will be stalled in tbf_dequeue() because its length is above the burst in kernel so that it cannot get enough tokens. The max_size guards against enqueuing packet sizes above q->buffer "time" in tbf_enqueue(). To make consistent with the calculation of tokens, this patch add a helper psched_ns_t2l() to calculate burst(max_size) directly to fix this problem. After this fix, we can support to using 64bit rates to calculate burst as well. Signed-off-by: Yang Yingliang <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11iser-target: fix error return code in isert_create_device_ib_res()Wei Yongjun1-4/+12
Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Signed-off-by: Wei Yongjun <[email protected]> Cc: <[email protected]> #3.10+ Signed-off-by: Nicholas Bellinger <[email protected]>
2013-12-11iscsi-target: Fix-up all zero data-length CDBs with R/W_BIT setNicholas Bellinger1-14/+12
This patch changes special case handling for ISCSI_OP_SCSI_CMD where an initiator sends a zero length Expected Data Transfer Length (EDTL), but still sets the WRITE and/or READ flag bits when no payload transfer is requested. Many, many moons ago two special cases where added for an ancient version of ESX that has long since been fixed, so instead of adding a new special case for the reported bug with a Broadcom 57800 NIC, go ahead and always strip off the incorrect WRITE + READ flag bits. Also, avoid sending a reject here, as RFC-3720 does mandate this case be handled without protocol error. Reported-by: Witold Bazakbal <[email protected]> Tested-by: Witold Bazakbal <[email protected]> Cc: <[email protected]> #3.1+ Signed-off-by: Nicholas Bellinger <[email protected]>
2013-12-11target: Remove write-only stats fields and lock from struct se_node_aclRoland Dreier2-6/+0
Commit 04f3b31bff72 ("iscsi-target: Convert iscsi_session statistics to atomic_long_t") removed the updating of these fields in iscsi (the only fabric driver that ever touched these counters), and the core has no way to report or otherwise use the values. Remove the last remnants of these counters. Signed-off-by: Roland Dreier <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]>
2013-12-11iscsi-target: return -EINVAL on oversized configfs parameterEric Seppanen1-1/+2
The iSCSI CHAP auth parameters are already copied with respect for the destination buffer size. Return -EINVAL instead of silently truncating the input. Signed-off-by: Eric Seppanen <[email protected]> Signed-off-by: Nicholas Bellinger <[email protected]>
2013-12-11micrel: add support for KSZ8041RNLISergei Shtylyov2-0/+17
Renesas R-Car development boards use KSZ8041RNLI PHY which for some reason has ID of 0x00221537 that is not documented for KSZ8041-family PHYs and does not match the documented ID of 0x0022151x (where 'x' is the revision). We have to add the new #define PHY_ID_* and new ksphy_driver[] entry, almost the same as KSZ8041 one, differing only in the 'phy_id' and 'name' fields. Signed-off-by: Sergei Shtylyov <[email protected]> Tested-by: Geert Uytterhoeven <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-11Merge branch 'for-davem' of ↵David S. Miller1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless John W. Linville says: ==================== Just one patch this time -- a fix from Felix Fietkau to fix the duration calculation for non-aggregated packets in ath9k. This is a small change and it is obviously specific to ath9k. Please let me know if there are problems! ==================== Signed-off-by: David S. Miller <[email protected]>
2013-12-11MAINTAINERS: Add DesignWare, i.MX6, Armada, R-Car PCI host maintainersBjorn Helgaas1-0/+33
Add entries for PCI host controller drivers in drivers/pci/host/. Signed-off-by: Mohit Kumar <[email protected]> # DESIGNWARE Signed-off-by: Pratyush Anand <[email protected]> # DESIGNWARE Signed-off-by: Bjorn Helgaas <[email protected]> Acked-by: Simon Horman <[email protected]> # R-CAR Double-Plus-Acked-by: Jason Cooper <[email protected]> # MVEBU Acked-by: Jingoo Han <[email protected]> Acked-by: Thierry Reding <[email protected]> Acked-by: Thomas Petazzoni <[email protected]> Acked-by: Richard Zhu <[email protected]> # IMX6
2013-12-11arm: xen: foreign mapping PTEs are special.Ian Campbell1-1/+1
These mappings are in fact special and require special handling in privcmd, which already exists. Failure to mark the PTE as special on arm64 causes all sorts of bad PTE fun. e.g. e.g.: BUG: Bad page map in process xl pte:e0004077b33f53 pmd:4079575003 page:ffffffbce1a2f328 count:1 mapcount:-1 mapping: (null) index:0x0 page flags: 0x4000000000000014(referenced|dirty) addr:0000007fb5259000 vm_flags:040644fa anon_vma: (null) mapping:ffffffc03a6fda58 index:0 vma->vm_ops->fault: privcmd_fault+0x0/0x38 vma->vm_file->f_op->mmap: privcmd_mmap+0x0/0x2c CPU: 0 PID: 2657 Comm: xl Not tainted 3.12.0+ #102 Call trace: [<ffffffc0000880f8>] dump_backtrace+0x0/0x12c [<ffffffc000088238>] show_stack+0x14/0x1c [<ffffffc0004b67e0>] dump_stack+0x70/0x90 [<ffffffc000125690>] print_bad_pte+0x12c/0x1bc [<ffffffc0001268f4>] unmap_single_vma+0x4cc/0x700 [<ffffffc0001273b4>] unmap_vmas+0x68/0xb4 [<ffffffc00012c050>] unmap_region+0xcc/0x1d4 [<ffffffc00012df20>] do_munmap+0x218/0x314 [<ffffffc00012e060>] vm_munmap+0x44/0x64 [<ffffffc00012ed78>] SyS_munmap+0x24/0x34 Where unmap_single_vma contains inlined -> unmap_page_range -> zap_pud_range -> zap_pmd_range -> zap_pte_range -> print_bad_pte. Or: BUG: Bad page state in process xl pfn:4077b4d page:ffffffbce1a2f8d8 count:0 mapcount:-1 mapping: (null) index:0x0 page flags: 0x4000000000000014(referenced|dirty) Modules linked in: CPU: 0 PID: 2657 Comm: xl Tainted: G B 3.12.0+ #102 Call trace: [<ffffffc0000880f8>] dump_backtrace+0x0/0x12c [<ffffffc000088238>] show_stack+0x14/0x1c [<ffffffc0004b67e0>] dump_stack+0x70/0x90 [<ffffffc00010f798>] bad_page+0xc4/0x110 [<ffffffc00010f8b4>] free_pages_prepare+0xd0/0xd8 [<ffffffc000110e94>] free_hot_cold_page+0x28/0x178 [<ffffffc000111460>] free_hot_cold_page_list+0x38/0x60 [<ffffffc000114cf0>] release_pages+0x190/0x1dc [<ffffffc00012c0e0>] unmap_region+0x15c/0x1d4 [<ffffffc00012df20>] do_munmap+0x218/0x314 [<ffffffc00012e060>] vm_munmap+0x44/0x64 [<ffffffc00012ed78>] SyS_munmap+0x24/0x34 x86 already gets this correct. 32-bit arm gets away with this because there is not PTE_SPECIAL bit in the PTE there and the vm_normal_page fallback path does the right thing. Signed-off-by: Ian Campbell <[email protected]> Signed-off-by: Stefano Stabellini <[email protected]>
2013-12-11xen/arm64: do not call the swiotlb functions twiceStefano Stabellini1-4/+0
On arm64 the dma_map_ops implementation is based on the swiotlb. swiotlb-xen, used by default in dom0 on Xen, is also based on the swiotlb. Avoid calling into the default arm64 dma_map_ops functions from xen_dma_map_page, xen_dma_unmap_page, xen_dma_sync_single_for_cpu, and xen_dma_sync_single_for_device otherwise we end up calling into the swiotlb twice. When arm64 gets a non-swiotlb based implementation of dma_map_ops, we'll probably have to reintroduce dma_map_ops calls in page-coherent.h. Signed-off-by: Stefano Stabellini <[email protected]> CC: [email protected] CC: [email protected] CC: [email protected]
2013-12-11Merge branch 'master' of ↵John W. Linville1-0/+4
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless into for-davem
2013-12-11sched/fair: Rework sched_fair time accountingPeter Zijlstra2-81/+66
Christian suffers from a bad BIOS that wrecks his i5's TSC sync. This results in him occasionally seeing time going backwards - which crashes the scheduler ... Most of our time accounting can actually handle that except the most common one; the tick time update of sched_fair. There is a further problem with that code; previously we assumed that because we get a tick every TICK_NSEC our time delta could never exceed 32bits and math was simpler. However, ever since Frederic managed to get NO_HZ_FULL merged; this is no longer the case since now a task can run for a long time indeed without getting a tick. It only takes about ~4.2 seconds to overflow our u32 in nanoseconds. This means we not only need to better deal with time going backwards; but also means we need to be able to deal with large deltas. This patch reworks the entire code and uses mul_u64_u32_shr() as proposed by Andy a long while ago. We express our virtual time scale factor in a u32 multiplier and shift right and the 32bit mul_u64_u32_shr() implementation reduces to a single 32x32->64 multiply if the time delta is still short (common case). For 64bit a 64x64->128 multiply can be used if ARCH_SUPPORTS_INT128. Reported-and-Tested-by: Christian Engelmayer <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: Paul Turner <[email protected]> Cc: Stanislaw Gruszka <[email protected]> Cc: Andy Lutomirski <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: Andrew Morton <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-12-11math64: Add mul_u64_u32_shr()Peter Zijlstra3-0/+37
Introduce mul_u64_u32_shr() as proposed by Andy a while back; it allows using 64x64->128 muls on 64bit archs and recent GCC which defines __SIZEOF_INT128__ and __int128. (This new method will be used by the scheduler.) Signed-off-by: Peter Zijlstra <[email protected]> Cc: [email protected] Cc: Andy Lutomirski <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-12-11sched: Remove PREEMPT_NEED_RESCHED from generic codePeter Zijlstra3-26/+22
While hunting a preemption issue with Alexander, Ben noticed that the currently generic PREEMPT_NEED_RESCHED stuff is horribly broken for load-store architectures. We currently rely on the IPI to fold TIF_NEED_RESCHED into PREEMPT_NEED_RESCHED, but when this IPI lands while we already have a load for the preempt-count but before the store, the store will erase the PREEMPT_NEED_RESCHED change. The current preempt-count only works on load-store archs because interrupts are assumed to be completely balanced wrt their preempt_count fiddling; the previous preempt_count load will match the preempt_count state after the interrupt and therefore nothing gets lost. This patch removes the PREEMPT_NEED_RESCHED usage from generic code and pushes it into x86 arch code; the generic code goes back to relying on TIF_NEED_RESCHED. Boot tested on x86_64 and compile tested on ppc64. Reported-by: Benjamin Herrenschmidt <[email protected]> Reported-and-Tested-by: Alexander Graf <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-12-11sched: Initialize power_orig for overlapping groupsPeter Zijlstra1-0/+1
Yinghai reported that he saw a /0 in sg_capacity on his EX parts. Make sure to always initialize power_orig now that we actually use it. Ideally build_sched_domains() -> init_sched_groups_power() would also initialize this; but for some yet unexplained reason some setups seem to miss updates there. Reported-by: Yinghai Lu <[email protected]> Tested-by: Yinghai Lu <[email protected]> Signed-off-by: Peter Zijlstra <[email protected]> Link: http://lkml.kernel.org/n/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2013-12-11drm/i915: don't update the dri1 breadcrumb with modesettingDaniel Vetter1-0/+8
The update is horribly racy since it doesn't protect at all against concurrent closing of the master fd. And it can't really since that requires us to grab a mutex. Instead of jumping through hoops and offloading this to a worker thread just block this bit of code for the modesetting driver. Note that the race is fairly easy to hit since we call the breadcrumb function for any interrupt. So the vblank interrupt (which usually keeps going for a bit) is enough. But even if we'd block this and only update the breadcrumb for user interrupts from the CS we could hit this race with kms/gem userspace: If a non-master is waiting somewhere (and hence has interrupts enabled) and the master closes its fd (probably due to crashing). v2: Add a code comment to explain why fixing this for real isn't really worth it. Also improve the commit message a bit. v3: Fix the spelling in the comment. Reported-by: Eugene Shatokhin <[email protected]> Cc: Eugene Shatokhin <[email protected]> Cc: [email protected] Acked-by: Chris Wilson <[email protected]> Tested-by: Eugene Shatokhin <[email protected]> Signed-off-by: Daniel Vetter <[email protected]>
2013-12-11netfilter: SYNPROXY target: restrict to INPUT/FORWARDPatrick McHardy2-0/+2
Fix a crash in synproxy_send_tcp() when using the SYNPROXY target in the PREROUTING chain caused by missing routing information. Reported-by: Nicki P. <[email protected]> Signed-off-by: Patrick McHardy <[email protected]> Signed-off-by: Pablo Neira Ayuso <[email protected]>
2013-12-11ALSA: hda - Add static DAC/pin mapping for AD1986A codecTakashi Iwai3-1/+35
AD1986A codec is a pretty old codec and has really many hidden restrictions. One of such is that each DAC is dedicated to certain pin although there are possible connections. Currently, the generic parser tries to assign individual DACs as much as possible, and this lead to two bad situations: connections where the sound actually doesn't work, and connections conflicting other channels. We may fix this by trying to find the best connections more harder, but as of now, it's easier to give some hints for paired DAC/pin connections and honor them if available, since such a hint is needed only for specific codecs (right now only AD1986A, and there will be unlikely any others in future). Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=64971 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=66621 Cc: <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-12-11ALSA: hda - One more Dell headset detection quirkHui Wang1-0/+1
On the Dell machines with codec whose Subsystem Id is 0x10280624, no external microphone can be detected when plugging a 3-ring headset. If we add "model=dell-headset-multi" for the snd-hda-intel.ko, the problem will disappear. BugLink: https://bugs.launchpad.net/bugs/1259790 Cc: David Henningsson <[email protected]> Cc: [email protected] Signed-off-by: Hui Wang <[email protected]> Signed-off-by: Takashi Iwai <[email protected]>
2013-12-11ALSA: hda - hdmi: Fix IEC958 ctl indexes for some simple HDMI devicesAnssi Hannula1-2/+3
In case a single HDA card has both HDMI and S/PDIF outputs, the S/PDIF outputs will have their IEC958 controls created starting from index 16 and the HDMI controls will be created starting from index 0. However, HDMI simple_playback_build_controls() as used by old VIA and NVIDIA codecs incorrectly requests the IEC958 controls to be created with an S/PDIF type instead of HDMI. In case the card has other codecs that have HDMI outputs, the controls will be created with wrong index=16, causing them to e.g. be unreachable by the ALSA "hdmi" alias. Fix that by making simple_playback_build_controls() request controls with HDMI indexes. Not many cards have an affected configuration, but e.g. ASUS M3N78-VM contains an integrated NVIDIA HDA "card" with: - a VIA codec that has, among others, an S/PDIF pin incorrectly labelled as an HDMI pin, and - an NVIDIA MCP7x HDMI codec. Reported-by: MysterX on #openelec Tested-by: MysterX on #openelec Signed-off-by: Anssi Hannula <[email protected]> Cc: <[email protected]> # 3.8+ Signed-off-by: Takashi Iwai <[email protected]>
2013-12-10udp: ipv4: fix an use after free in __udp4_lib_rcv()Eric Dumazet1-10/+6
Dave Jones reported a use after free in UDP stack : [ 5059.434216] ========================= [ 5059.434314] [ BUG: held lock freed! ] [ 5059.434420] 3.13.0-rc3+ #9 Not tainted [ 5059.434520] ------------------------- [ 5059.434620] named/863 is freeing memory ffff88005e960000-ffff88005e96061f, with a lock still held there! [ 5059.434815] (slock-AF_INET){+.-...}, at: [<ffffffff8149bd21>] udp_queue_rcv_skb+0xd1/0x4b0 [ 5059.435012] 3 locks held by named/863: [ 5059.435086] #0: (rcu_read_lock){.+.+..}, at: [<ffffffff8143054d>] __netif_receive_skb_core+0x11d/0x940 [ 5059.435295] #1: (rcu_read_lock){.+.+..}, at: [<ffffffff81467a5e>] ip_local_deliver_finish+0x3e/0x410 [ 5059.435500] #2: (slock-AF_INET){+.-...}, at: [<ffffffff8149bd21>] udp_queue_rcv_skb+0xd1/0x4b0 [ 5059.435734] stack backtrace: [ 5059.435858] CPU: 0 PID: 863 Comm: named Not tainted 3.13.0-rc3+ #9 [loadavg: 0.21 0.06 0.06 1/115 1365] [ 5059.436052] Hardware name: /D510MO, BIOS MOPNV10J.86A.0175.2010.0308.0620 03/08/2010 [ 5059.436223] 0000000000000002 ffff88007e203ad8 ffffffff8153a372 ffff8800677130e0 [ 5059.436390] ffff88007e203b10 ffffffff8108cafa ffff88005e960000 ffff88007b00cfc0 [ 5059.436554] ffffea00017a5800 ffffffff8141c490 0000000000000246 ffff88007e203b48 [ 5059.436718] Call Trace: [ 5059.436769] <IRQ> [<ffffffff8153a372>] dump_stack+0x4d/0x66 [ 5059.436904] [<ffffffff8108cafa>] debug_check_no_locks_freed+0x15a/0x160 [ 5059.437037] [<ffffffff8141c490>] ? __sk_free+0x110/0x230 [ 5059.437147] [<ffffffff8112da2a>] kmem_cache_free+0x6a/0x150 [ 5059.437260] [<ffffffff8141c490>] __sk_free+0x110/0x230 [ 5059.437364] [<ffffffff8141c5c9>] sk_free+0x19/0x20 [ 5059.437463] [<ffffffff8141cb25>] sock_edemux+0x25/0x40 [ 5059.437567] [<ffffffff8141c181>] sock_queue_rcv_skb+0x81/0x280 [ 5059.437685] [<ffffffff8149bd21>] ? udp_queue_rcv_skb+0xd1/0x4b0 [ 5059.437805] [<ffffffff81499c82>] __udp_queue_rcv_skb+0x42/0x240 [ 5059.437925] [<ffffffff81541d25>] ? _raw_spin_lock+0x65/0x70 [ 5059.438038] [<ffffffff8149bebb>] udp_queue_rcv_skb+0x26b/0x4b0 [ 5059.438155] [<ffffffff8149c712>] __udp4_lib_rcv+0x152/0xb00 [ 5059.438269] [<ffffffff8149d7f5>] udp_rcv+0x15/0x20 [ 5059.438367] [<ffffffff81467b2f>] ip_local_deliver_finish+0x10f/0x410 [ 5059.438492] [<ffffffff81467a5e>] ? ip_local_deliver_finish+0x3e/0x410 [ 5059.438621] [<ffffffff81468653>] ip_local_deliver+0x43/0x80 [ 5059.438733] [<ffffffff81467f70>] ip_rcv_finish+0x140/0x5a0 [ 5059.438843] [<ffffffff81468926>] ip_rcv+0x296/0x3f0 [ 5059.438945] [<ffffffff81430b72>] __netif_receive_skb_core+0x742/0x940 [ 5059.439074] [<ffffffff8143054d>] ? __netif_receive_skb_core+0x11d/0x940 [ 5059.442231] [<ffffffff8108c81d>] ? trace_hardirqs_on+0xd/0x10 [ 5059.442231] [<ffffffff81430d83>] __netif_receive_skb+0x13/0x60 [ 5059.442231] [<ffffffff81431c1e>] netif_receive_skb+0x1e/0x1f0 [ 5059.442231] [<ffffffff814334e0>] napi_gro_receive+0x70/0xa0 [ 5059.442231] [<ffffffffa01de426>] rtl8169_poll+0x166/0x700 [r8169] [ 5059.442231] [<ffffffff81432bc9>] net_rx_action+0x129/0x1e0 [ 5059.442231] [<ffffffff810478cd>] __do_softirq+0xed/0x240 [ 5059.442231] [<ffffffff81047e25>] irq_exit+0x125/0x140 [ 5059.442231] [<ffffffff81004241>] do_IRQ+0x51/0xc0 [ 5059.442231] [<ffffffff81542bef>] common_interrupt+0x6f/0x6f We need to keep a reference on the socket, by using skb_steal_sock() at the right place. Note that another patch is needed to fix a race in udp_sk_rx_dst_set(), as we hold no lock protecting the dst. Fixes: 421b3885bf6d ("udp: ipv4: Add udp early demux") Reported-by: Dave Jones <[email protected]> Signed-off-by: Eric Dumazet <[email protected]> Cc: Shawn Bohrer <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10Merge branch 'sctp'David S. Miller2-19/+89
Wang Weidong says: ==================== sctp: check the rto_min and rto_max v6 -> v7: -patch2: fix the whitespace issues which pointed out by Daniel v5 -> v6: split the v5' first patch to patch1 and patch2, and remove the macro in constants.h -patch1: do rto_min/max socket option handling in its own patch, and fix the check of rto_min/max. -patch2: do rto_min/max sysctl handling in its own patch. -patch3: add Suggested-by Daniel. v4 -> v5: - patch1: add marco in constants.h and fix up spacing as suggested by Daniel - patch2: add a patch for fix up do_hmac_alg for according to do_rto_min[max] v3 -> v4: -patch1: fix use init_net directly which suggested by Vlad. v2 -> v3: -patch1: add proc_handler for check rto_min and rto_max which suggested by Vlad v1 -> v2: -patch1: fix the From Name which pointed out by David, and add the ACK by Neil ==================== Signed-off-by: David S. Miller <[email protected]>
2013-12-10sctp: fix up a spacingwangweidong1-5/+2
fix up spacing of proc_sctp_do_hmac_alg for according to the proc_sctp_do_rto_min[max] in sysctl.c Suggested-by: Daniel Borkmann <[email protected]> Signed-off-by: Wang Weidong <[email protected]> Acked-by: Vlad Yasevich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10sctp: add check rto_min and rto_max in sysctlwangweidong1-4/+65
rto_min should be smaller than rto_max while rto_max should be larger than rto_min. Add two proc_handler for the checking. Suggested-by: Vlad Yasevich <[email protected]> Signed-off-by: Wang Weidong <[email protected]> Acked-by: Vlad Yasevich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10sctp: check the rto_min and rto_max in setsockoptwangweidong1-10/+22
When we set 0 to rto_min or rto_max, just not change the value. Also we should check the rto_min > rto_max. Suggested-by: Vlad Yasevich <[email protected]> Signed-off-by: Wang Weidong <[email protected]> Acked-by: Vlad Yasevich <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10ipv6: do not erase dst address with flow label destinationFlorent Fourcot6-6/+0
This patch is following b579035ff766c9412e2b92abf5cab794bff102b6 "ipv6: remove old conditions on flow label sharing" Since there is no reason to restrict a label to a destination, we should not erase the destination value of a socket with the value contained in the flow label storage. This patch allows to really have the same flow label to more than one destination. Signed-off-by: Florent Fourcot <[email protected]> Reviewed-by: Hannes Frederic Sowa <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10sctp: properly latch and use autoclose value from sock to associationNeil Horman5-17/+13
Currently, sctp associations latch a sockets autoclose value to an association at association init time, subject to capping constraints from the max_autoclose sysctl value. This leads to an odd situation where an application may set a socket level autoclose timeout, but sliently sctp will limit the autoclose timeout to something less than that. Fix this by modifying the autoclose setsockopt function to check the limit, cap it and warn the user via syslog that the timeout is capped. This will allow getsockopt to return valid autoclose timeout values that reflect what subsequent associations actually use. While were at it, also elimintate the assoc->autoclose variable, it duplicates whats in the timeout array, which leads to multiple sources for the same information, that may differ (as the former isn't subject to any capping). This gives us the timeout information in a canonical place and saves some space in the association structure as well. Signed-off-by: Neil Horman <[email protected]> Acked-by: Vlad Yasevich <[email protected]> CC: Wang Weidong <[email protected]> CC: David Miller <[email protected]> CC: Vlad Yasevich <[email protected]> CC: [email protected] Signed-off-by: David S. Miller <[email protected]>
2013-12-10Merge branch 'tipc'David S. Miller2-6/+12
Jon Maloy says: ==================== tipc: corrections related to tasklet job mechanism These commits correct two bugs related to tipc' service for launching functions for asynchronous execution in a separate tasklet. ==================== Signed-off-by: David S. Miller <[email protected]>
2013-12-10tipc: protect handler_enabled variable with qitem_lock spin lockYing Xue1-3/+8
'handler_enabled' is a global flag indicating whether the TIPC signal handling service is enabled or not. The lack of lock protection for this flag incurs a risk for contention, so that a tipc_k_signal() call might queue a signal handler to a destroyed signal queue, with unpredictable results. To correct this, we let the already existing 'qitem_lock' protect the flag, as it already does with the queue itself. This way, we ensure that the flag always is consistent across all cores. Signed-off-by: Ying Xue <[email protected]> Reviewed-by: Paul Gortmaker <[email protected]> Signed-off-by: Jon Maloy <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10tipc: correct the order of stopping services at rmmodJon Paul Maloy1-3/+4
The 'signal handler' service in TIPC is a mechanism that makes it possible to postpone execution of functions, by launcing them into a job queue for execution in a separate tasklet, independent of the launching execution thread. When we do rmmod on the tipc module, this service is stopped after the network service. At the same time, the stopping of the network service may itself launch jobs for execution, with the risk that these functions may be scheduled for execution after the data structures meant to be accessed by the job have already been deleted. We have seen this happen, most often resulting in an oops. This commit ensures that the signal handler is the very first to be stopped when TIPC is shut down, so there are no surprises during the cleanup of the other services. Signed-off-by: Jon Maloy <[email protected]> Reviewed-by: Paul Gortmaker <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10tg3: Initialize REG_BASE_ADDR at PCI config offset 120 to 0Nat Gurumoorthy1-0/+3
The new tg3 driver leaves REG_BASE_ADDR (PCI config offset 120) uninitialized. From power on reset this register may have garbage in it. The Register Base Address register defines the device local address of a register. The data pointed to by this location is read or written using the Register Data register (PCI config offset 128). When REG_BASE_ADDR has garbage any read or write of Register Data Register (PCI 128) will cause the PCI bus to lock up. The TCO watchdog will fire and bring down the system. Signed-off-by: Nat Gurumoorthy <[email protected]> Acked-by: Michael Chan <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10net: Revert macvtap/tun truncation signalling changes.David S. Miller2-26/+24
Jason Wang and Michael S. Tsirkin are still discussing how to properly fix this. Signed-off-by: David S. Miller <[email protected]>
2013-12-10macvtap: signal truncated packetsJason Wang1-13/+14
macvtap_put_user() never return a value grater than iov length, this in fact bypasses the truncated checking in macvtap_recvmsg(). Fix this by always returning the size of packet plus the possible vlan header to let the truncated checking work. Cc: Vlad Yasevich <[email protected]> Cc: Zhi Yong Wu <[email protected]> Signed-off-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10tun: unbreak truncated packet signallingJason Wang1-11/+12
Commit 6680ec68eff47d36f67b4351bc9836fd6cba9532 (tuntap: hardware vlan tx support) breaks the truncated packet signal by never return a length greater than iov length in tun_put_user(). This patch fixes this by always return the length of packet plus possible vlan header. Caller can detect the truncated packet by comparing the return value and the size of iov length. Reported-by: Vlad Yasevich <[email protected]> Cc: Vlad Yasevich <[email protected]> Cc: Zhi Yong Wu <[email protected]> Signed-off-by: Jason Wang <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2013-12-10vxlan: release rt when found circular routeFan Du1-1/+1
Otherwise causing dst memory leakage. Have Checked all other type tunnel device transmit implementation, no such things happens anymore. Signed-off-by: Fan Du <[email protected]> Acked-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.