aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/media/parport (unfollow)
AgeCommit message (Collapse)AuthorFilesLines
2014-05-17sparc64: Add membar to Niagara2 memcpy code.David S. Miller1-0/+1
This is the prevent previous stores from overlapping the block stores done by the memcpy loop. Based upon a glibc patch by Jose E. Marchesi Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-08sparc64: Fix huge TSB mapping on pre-UltraSPARC-III cpus.David S. Miller2-3/+17
Access to the TSB hash tables during TLB misses requires that there be an atomic 128-bit quad load available so that we fetch a matching TAG and DATA field at the same time. On cpus prior to UltraSPARC-III only virtual address based quad loads are available. UltraSPARC-III and later provide physical address based variants which are easier to use. When we only have virtual address based quad loads available this means that we have to lock the TSB into the TLB at a fixed virtual address on each cpu when it runs that process. We can't just access the PAGE_OFFSET based aliased mapping of these TSBs because we cannot take a recursive TLB miss inside of the TLB miss handler without risking running out of hardware trap levels (some trap combinations can be deep, such as those generated by register window spill and fill traps). Without huge pages it's working perfectly fine, but when the huge TSB got added another chunk of fixed virtual address space was not allocated for this second TSB mapping. So we were mapping both the 8K and 4MB TSBs to the same exact virtual address, causing multiple TLB matches which gives undefined behavior. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-06sparc64: Don't bark so loudly about 32-bit tasks generating 64-bit fault addresses.David S. Miller1-15/+1
This was found using Dave Jone's trinity tool. When a user process which is 32-bit performs a load or a store, the cpu chops off the top 32-bits of the effective address before translating it. This is because we run 32-bit tasks with the PSTATE_AM (address masking) bit set. We can't run the kernel with that bit set, so when the kernel accesses userspace no address masking occurs. Since a 32-bit process will have no mappings in that region we will properly fault, so we don't try to handle this using access_ok(), which can safely just be a NOP on sparc64. Real faults from 32-bit processes should never generate such addresses so a bug check was added long ago, and it barks in the logs if this happens. But it also barks when a kernel user access causes this condition, and that _can_ happen. For example, if a pointer passed into a system call is "0xfffffffc" and the kernel access 4 bytes offset from that pointer. Just handle such faults normally via the exception entries. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05slab: Fix off by one in object max number tests.David Miller1-1/+1
If freelist_idx_t is a byte, SLAB_OBJ_MAX_NUM should be 255 not 256, and likewise if freelist_idx_t is a short, then it should be 65535 not 65536. This was leading to all kinds of random crashes on sparc64 where PAGE_SIZE is 8192. One problem shown was that if spinlock debugging was enabled, we'd get deadlocks in copy_pte_range() or do_wp_page() with the same cpu already holding a lock it shouldn't hold, or the lock belonging to a completely unrelated process. Fixes: a41adfaa23df ("slab: introduce byte sized index for the freelist of a slab") Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-05-05slab: fix the type of the index on freelist index accessorJoonsoo Kim1-2/+2
Commit a41adfaa23df ("slab: introduce byte sized index for the freelist of a slab") changes the size of freelist index and also changes prototype of accessor function to freelist index. And there was a mistake. The mistake is that although it changes the size of freelist index correctly, it changes the size of the index of freelist index incorrectly. With patch, freelist index can be 1 byte or 2 bytes, that means that num of object on on a slab can be more than 255. So we need more than 1 byte for the index to find the index of free object on freelist. But, above patch makes this index type 1 byte, so slab which have more than 255 objects cannot work properly and in consequence of it, the system cannot boot. This issue was reported by Steven King on m68knommu which would use 2 bytes freelist index: https://lkml.org/lkml/2014/4/16/433 To fix is easy. To change the type of the index of freelist index on accessor functions is enough to fix this bug. Although 2 bytes is enough, I use 4 bytes since it have no bad effect and make things more easier. This fix was suggested and tested by Steven in his original report. Signed-off-by: Joonsoo Kim <iamjoonsoo.kim@lge.com> Reported-and-acked-by: Steven King <sfking@fdwdc.com> Acked-by: Christoph Lameter <cl@linux.com> Tested-by: James Hogan <james.hogan@imgtec.com> Tested-by: David Miller <davem@davemloft.net> Cc: Pekka Enberg <penberg@kernel.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-05-05net: macb: Fix race between HW and driverSoren Brinkmann1-10/+0
Under "heavy" RX load, the driver cannot handle the descriptors fast enough. In detail, when a descriptor is consumed, its used flag is cleared and once the RX budget is consumed all descriptors with a cleared used flag are prepared to receive more data. Under load though, the HW may constantly receive more data and use those descriptors with a cleared used flag before they are actually prepared for next usage. The head and tail pointers into the RX-ring should always be valid and we can omit clearing and checking of the used flag. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05net: macb: Remove 'unlikely' optimizationSoren Brinkmann1-1/+1
Coverage data suggests that the unlikely case of receiving data while the receive handler is running may not be that unlikely. Coverage data after running iperf for a while: 91320: 891: work_done = bp->macbgem_ops.mog_rx(bp, budget); 91320: 892: if (work_done < budget) { 2362: 893: napi_complete(napi); -: 894: -: 895: /* Packets received while interrupts were disabled */ 4724: 896: status = macb_readl(bp, RSR); 2362: 897: if (unlikely(status)) { 762: 898: if (bp->caps & MACB_CAPS_ISR_CLEAR_ON_WRITE) 762: 899: macb_writel(bp, ISR, MACB_BIT(RCOMP)); -: 900: napi_reschedule(napi); -: 901: } else { 1600: 902: macb_writel(bp, IER, MACB_RX_INT_FLAGS); -: 903: } -: 904: } Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05net: macb: Re-enable RX interrupt only when RX is doneSoren Brinkmann1-7/+6
When data is received during the driver processing received data the NAPI is re-scheduled. In that case the RX interrupt should not be re-enabled. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05net: macb: Clear interrupt flagsSoren Brinkmann1-0/+10
A few interrupt flags were not cleared in the ISR, resulting in a sytem trapped in the ISR in cases one of those interrupts occurred. Clear all flags to avoid such situations. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05net: macb: Pass same size to DMA_UNMAP as used for DMA_MAPSoren Brinkmann1-1/+1
Just as commit "net: macb: DMA-unmap full rx-buffer" (48330e08fa168395b9fd9f369f06cca1df204361), pass the size that was used for mapping the memory also to the unmap routine to avoid warnings from the DMA_API. Signed-off-by: Soren Brinkmann <soren.brinkmann@xilinx.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05ip_tunnel: Set network header properly for IP_ECN_decapsulate()Ying Cai1-0/+2
In ip_tunnel_rcv(), set skb->network_header to inner IP header before IP_ECN_decapsulate(). Without the fix, IP_ECN_decapsulate() takes outer IP header as inner IP header, possibly causing error messages or packet drops. Note that this skb_reset_network_header() call was in this spot when the original feature for checking consistency of ECN bits through tunnels was added in eccc1bb8d4b4 ("tunnel: drop packet if ECN present with not-ECT"). It was only removed from this spot in 3d7b46cd20e3 ("ip_tunnel: push generic protocol handling to ip_tunnel module."). Fixes: 3d7b46cd20e3 ("ip_tunnel: push generic protocol handling to ip_tunnel module.") Reported-by: Neal Cardwell <ncardwell@google.com> Signed-off-by: Ying Cai <ycai@google.com> Acked-by: Neal Cardwell <ncardwell@google.com> Acked-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05e1000e: Restrict MDIO Slow Mode workaround to relevant partsDavid Ertman1-6/+8
It has been determined that the workaround of putting the PHY into MDIO slow mode to access the PHY id is not necessary with Lynx Point and newer parts. The issue that necessitated the workaround has been fixed on the newer hardware. We will maintains, as a last ditch attempt, the conversion to MDIO Slow Mode in the failure branch when attempting to access the PHY id so as to cover all contingencies. Signed-off-by: Dave Ertman <davidx.m.ertman@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-05-05e1000e: Fix issue with link flap on 82579David Ertman2-0/+13
Several customers have reported a link flap issue on 82579. The symptoms are random and intermittent link losses when 82579 is connected to specific link partners. Issue has been root caused as interoperability problem between 82579 and at least some Broadcom PHYs in the Energy Efficient Ethernet wake mechanism. To fix the issue, we are disabling the Phase Locked Loop shutdown in 100M Low Power Idle. This solution will cause an increase of power in 100M EEE link. It will cost additional 28mW in this specific mode. Cc: Lukasz Adamczuk <lukasz.adamczuk@intel.com> Signed-off-by: Dave Ertman <davidx.m.ertman@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-05-05e1000e: Expand workaround for 10Mb HD throughput bugDavid Ertman2-4/+12
In commit 772d05c51c4f4896c120ad418b1e91144a2ac813 "e1000e: slow performance between two 82579 connected via 10Mbit hub", a workaround was put into place to address the overaggressive transmit behavior of 82579 parts when connecting at 10Mbs half-duplex. This same behavior is seen on i217 and i218 parts as well. This patch expands the original workaround to encompass these parts. Signed-off-by: Dave Ertman <davidx.m.ertman@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-05-05e1000e: Workaround for dropped packets in Gig/100 speeds on 82579David Ertman2-19/+13
This is a workaround for a HW erratum on 82579 devices. Erratum is #23 in Intel 6 Series Chipset and Intel C200 Series Chipset specification Update June 2013. Problem: 82579 parts experience packet loss in Gig and 100 speeds when interconnect between PHY and MAC is exiting K1 power saving state. This was previously believed to only affect 1Gig speed, but has been observed at 100Mbs also. Workaround: Disable K1 for 82579 devices at Gig and 100 speeds. Signed-off-by: Dave Ertman <davidx.m.ertman@intel.com> Tested-by: Aaron Brown <aaron.f.brown@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
2014-05-05net/mlx4_core: Don't issue PCIe speed/width checks for VFsEyal Perry1-1/+2
Carrying out PCI speed/width checks through pcie_get_minimum_link() on VFs yield wrong results, so remove them. Fixes: b912b2f ('net/mlx4_core: Warn if device doesn't have enough PCI bandwidth') Signed-off-by: Eyal Perry <eyalpe@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05net/mlx4_core: Load the Eth driver firstOr Gerlitz1-2/+2
When running in SRIOV mode, VM that is assigned with a non-provisioned Ethernet VFs get themselves a random mac when the Eth driver starts. In this case, if the IB driver startup code that deals with RoCE runs first, it will use a zero mac as the source mac for the Para-Virtual CM MADs which is buggy. To handle that, we change the order of loading. Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05net/mlx4_core: Fix slave id computation for single port VFMatan Barak1-15/+20
The code that deals with computing the slave id based on a given GID gave wrong results when the number of single port VFs wasn't the same for port 1 vs. port 2 and the relevant VF is single ported on port 2. As a result, incoming CM MADs were dispatched to the wrong VF. Fixed that and added documentation to clarify the computation steps. Fixes: 449fc48 ('net/mlx4: Adapt code for N-Port VF') Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05net/mlx4_core: Adjust port number in qp_attach wrapper when detachingJack Morgenstein1-0/+23
When using single ported VFs and the VF is using port 2, we need to adjust the port accordingly (change it from 1 to 2). Fixes: 449fc48 ('net/mlx4: Adapt code for N-Port VF') Signed-off-by: Matan Barak <matanb@mellanox.com> Signed-off-by: Jack Morgenstein <jackm@mellanox.com> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05net: cdc_ncm: fix buffer overflowBjørn Mork1-1/+1
Commit 4d619f625a60 ("net: cdc_ncm: no point in filling up the NTBs if we send ZLPs") changed the padding logic for devices with the ZLP flag set. This meant that frames of any size will be sent without additional padding, except for the single byte added if the size is a multiple of the USB packet size. But if the unpadded size is identical to the maximum frame size, and the maximum size is a multiplum of the USB packet size, then this one-byte padding will overflow the buffer. Prevent padding if already at maximum frame size, letting usbnet transmit a ZLP instead in this case. Fixes: 4d619f625a60 ("net: cdc_ncm: no point in filling up the NTBs if we send ZLPs") Reported by: Yu-an Shih <yshih@nvidia.com> Signed-off-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05Altera TSE: ALTERA_TSE should depend on HAS_DMAGeert Uytterhoeven1-0/+1
If NO_DMA=y: drivers/built-in.o: In function `altera_tse_probe': altera_tse_main.c:(.text+0x25ec2e): undefined reference to `dma_set_mask' altera_tse_main.c:(.text+0x25ec78): undefined reference to `dma_supported' altera_tse_main.c:(.text+0x25ecb6): undefined reference to `dma_supported' drivers/built-in.o: In function `sgdma_async_read': altera_sgdma.c:(.text+0x25f620): undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `sgdma_uninitialize': (.text+0x25f678): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `sgdma_uninitialize': (.text+0x25f696): undefined reference to `dma_unmap_single' drivers/built-in.o: In function `sgdma_initialize': (.text+0x25f6f0): undefined reference to `dma_map_single' drivers/built-in.o: In function `sgdma_initialize': (.text+0x25f702): undefined reference to `dma_mapping_error' drivers/built-in.o: In function `sgdma_tx_buffer': (.text+0x25f92a): undefined reference to `dma_sync_single_for_cpu' drivers/built-in.o: In function `sgdma_rx_status': (.text+0x25fa24): undefined reference to `dma_sync_single_for_cpu' make[3]: *** [vmlinux] Error 1 Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Acked-by: Vince Bridgers <vbridgers2013@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05vsock: Make transport the proto ownerAndy King2-26/+27
Right now the core vsock module is the owner of the proto family. This means there's nothing preventing the transport module from unloading if there are open sockets, which results in a panic. Fix that by allowing the transport to be the owner, which will refcount it properly. Includes version bump to 1.0.1.0-k Passes checkpatch this time, I swear... Acked-by: Dmitry Torokhov <dtor@vmware.com> Signed-off-by: Andy King <acking@vmware.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-05xtensa: ISS: don't depend on CONFIG_TTYMax Filippov2-2/+2
Build console support only when CONFIG_TTY is selected. This restores ISS as the default platform for allnoconfig builds. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Chris Zankel <chris@zankel.net>
2014-05-05fix quoting of Ted's name in MAINTAINERSChristoph Hellwig1-1/+1
Unpaired quotes really confuse mutt when copy & pasting it into the To: form. Signed-off-by: Christoph Hellwig <hch@lst.de> [ I'm going to remove all silly quotes entirely one day, but that day is not today. So I'll just apply this - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-05-05floppy: don't write kernel-only members to FDRAWCMD ioctl outputMatthew Daley1-1/+4
Do not leak kernel-only floppy_raw_cmd structure members to userspace. This includes the linked-list pointer and the pointer to the allocated DMA space. Signed-off-by: Matthew Daley <mattd@bugfuzz.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-05-05floppy: ignore kernel-only members in FDRAWCMD ioctl inputMatthew Daley1-3/+3
Always clear out these floppy_raw_cmd struct members after copying the entire structure from userspace so that the in-kernel version is always valid and never left in an interdeterminate state. Signed-off-by: Matthew Daley <mattd@bugfuzz.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-05-05UBI: avoid workqueue format string leakKees Cook1-1/+1
When building the name for the workqueue thread, make sure a format string cannot leak in from the disk name. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2014-05-05UBI: fix ubi free PEBs count calculationTanya Brokhman1-0/+3
The ubi->free_count should be updated with every insert/remove to/from the ubi->free list. Signed-off-by: Tanya Brokhman <tlinder@codeaurora.org> Reviewed-by: Dolev Raviv <draviv@codeaurora.org> Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2014-05-05UBI: fix error path in __wl_get_pebTanya Brokhman1-0/+3
In case of an error (if there are not free PEB's for example), __wl_get_peb will return a negative value. In order to prevent access violation we need to test the returned value prior to using it later on. Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org> Reviewed-by: Dolev Raviv <draviv@codeaurora.org> Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2014-05-05UBIFS: fix remount error pathArtem Bityutskiy1-1/+1
Dan's "smatch" checker found out that there was a bug in the error path of the 'ubifs_remount_rw()' function. Instead of jumping to the "out" label which cleans-things up, we just returned. This patch fixes the problem. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Artem Bityutskiy <artem.bityutskiy@linux.intel.com>
2014-05-04Linux 3.15-rc4Linus Torvalds1-1/+1
2014-05-04net: sched: lock imbalance in hhf qdiscJohn Fastabend1-5/+6
hhf_change() takes the sch_tree_lock and releases it but misses the error cases. Fix the missed case here. To reproduce try a command like this, # tc qdisc change dev p3p2 root hhf quantum 40960 non_hh_weight 300000 Signed-off-by: John Fastabend <john.r.fastabend@intel.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-04vexpress: Initialise the sysregs before setting up the clocksCatalin Marinas1-0/+2
Following arm64 commit bc3ee18a7a57 (arm64: init: Move of_clk_init to time_init()), vexpress_osc_of_setup() is called via of_clk_init() long before initcalls are issued. Initialising the vexpress oscillators requires the vespress sysregs to be already initialised, so this patch adds an explicit call to vexpress_sysreg_of_early_init() in vexpress oscillator setup function. Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Will Deacon <will.deacon@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Tested-by: Pawel Moll <pawel.moll@arm.com> Acked-by: Pawel Moll <pawel.moll@arm.com> Cc: Mike Turquette <mturquette@linaro.org>
2014-05-03sparc64: Give more detailed information in {pgd,pmd}_ERROR() and kill pte_ERROR().David S. Miller1-3/+6
pte_ERROR() is not used anywhere, delete it. For pgd_ERROR() and pmd_ERROR(), output something similar to x86, giving the address of the pgd/pmd as well as it's value. Also provide the caller, since these macros are invoked from pgd_clear_bad() and pmd_clear_bad() which provides little context as to what high level operation was occuring when the BAD state was detected. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Add basic validations to {pud,pmd}_bad().David S. Miller1-15/+31
Instead of returning false we should at least check the most basic things, otherwise page table corruptions will be very difficult to debug. PMD and PTE tables are of size PAGE_SIZE, so none of the sub-PAGE_SIZE bits should be set. We also complement this with a check that the physical address the pud/pmd points to is valid memory. PowerPC was used as a guide while implementating this. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Use 'ILOG2_4MB' instead of constant '22'.David S. Miller4-10/+10
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Fix range check in kern_addr_valid().David S. Miller1-1/+1
In commit b2d438348024b75a1ee8b66b85d77f569a5dfed8 ("sparc64: Make PAGE_OFFSET variable."), the MAX_PHYS_ADDRESS_BITS value was increased (to 47). This constant reference to '41UL' was missed. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Fix top-level fault handling bugs.David S. Miller1-30/+52
Make get_user_insn() able to cope with huge PMDs. Next, make do_fault_siginfo() more robust when get_user_insn() can't actually fetch the instruction. In particular, use the MMU announced fault address when that happens, instead of calling compute_effective_address() and computing garbage. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Handle 32-bit tasks properly in compute_effective_address().David S. Miller1-3/+9
If we have a 32-bit task we must chop off the top 32-bits of the 64-bit value just as the cpu would. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Don't use _PAGE_PRESENT in pte_modify() mask.David S. Miller1-4/+4
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Fix hex values in comment above pte_modify().David S. Miller1-2/+2
When _PAGE_SPECIAL and _PAGE_PMD_HUGE were added to the mask, the comment was not updated. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Fix bugs in get_user_pages_fast() wrt. THP.David S. Miller2-2/+2
The large PMD path needs to check _PAGE_VALID not _PAGE_PRESENT, to decide if it needs to bail and return 0. pmd_large() should therefore just check _PAGE_PMD_HUGE. Calls to gup_huge_pmd() are guarded with a check of pmd_large(), so we just need to add a valid bit check. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Fix huge PMD invalidation.David S. Miller3-15/+17
On sparc64 "present" and "valid" are seperate PTE bits, this allows us to naturally distinguish between the user explicitly asking for PROT_NONE with mprotect() and other situations. However we weren't handling this properly in the huge PMD paths. First of all, the page table walker in the TSB miss path only checks for _PAGE_PMD_HUGE. So the generic pmdp_invalidate() would clear _PAGE_PRESENT but the TLB miss paths would still load it into the TLB as a valid huge PMD. Fix this by clearing the valid bit in pmdp_invalidate(), and also checking the valid bit in USER_PGTABLE_CHECK_PMD_HUGE using "brgez" since _PAGE_VALID is bit 63 in both the sun4u and sun4v pte layouts. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Fix executable bit testing in set_pmd_at() paths.David S. Miller1-6/+9
This code was mistakenly using the exec bit from the PMD in all cases, even when the PMD isn't a huge PMD. If it's not a huge PMD, test the exec bit in the individual ptes down in tlb_batch_pmd_scan(). Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03sparc64: Normalize NMI watchdog logging and behavior.David S. Miller1-16/+5
Bring this code in line with the perf based generic NMI watchdog in kernel/watchdog.c (which we should convert over to at some point). In particular, don't do anything super fancy when the watchdog triggers, and specifically don't do a do_exit() which only makes things worse. Either panic(), or WARN(). The latter of which will do all of the actions such as give us a stack backtrace. Signed-off-by: David S. Miller <davem@davemloft.net>
2014-05-03USB: Nokia 5300 should be treated as unusual devDaniele Forsi1-0/+7
Signed-off-by: Daniele Forsi <dforsi@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-03USB: Nokia 305 should be treated as unusual devVictor A. Santos1-0/+7
Signed-off-by: Victor A. Santos <victoraur.santos@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-03tty: Fix lockless tty buffer racePeter Hurley1-3/+14
Commit 6a20dbd6caa2358716136144bf524331d70b1e03, "tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc" correctly identifies an unsafe race condition between __tty_buffer_request_room() and flush_to_ldisc(), where the consumer flush_to_ldisc() prematurely advances the head before consuming the last of the data committed. For example: CPU 0 | CPU 1 __tty_buffer_request_room | flush_to_ldisc ... | ... | count = head->commit - head->read n = tty_buffer_alloc() | b->commit = b->used | b->next = n | | if (!count) /* T */ | if (head->next == NULL) /* F */ | buf->head = head->next In this case, buf->head has been advanced but head->commit may have been updated with a new value. Instead of reintroducing an unnecessary lock, fix the race locklessly. Read the commit-next pair in the reverse order of writing, which guarantees the commit value read is the latest value written if the head is advancing. Reported-by: Manfred Schlaegl <manfred.schlaegl@gmx.at> Cc: <stable@vger.kernel.org> # 3.12.x+ Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-03Revert "tty: Fix race condition between __tty_buffer_request_room and flush_to_ldisc"Peter Hurley2-15/+2
This reverts commit 6a20dbd6caa2358716136144bf524331d70b1e03. Although the commit correctly identifies an unsafe race condition between __tty_buffer_request_room() and flush_to_ldisc(), the commit fixes the race with an unnecessary spinlock in a lockless algorithm. The follow-on commit, "tty: Fix lockless tty buffer race" fixes the race locklessly. Signed-off-by: Peter Hurley <peter@hurleysoftware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-05-03drivers/tty/hvc: don't free hvc_console_setup after initTomoki Sekiyama1-1/+1
When 'console=hvc0' is specified to the kernel parameter in x86 KVM guest, hvc console is setup within a kthread. However, that will cause SEGV and the boot will fail when the driver is builtin to the kernel, because currently hvc_console_setup() is annotated with '__init'. This patch removes '__init' to boot the guest successfully with 'console=hvc0'. Signed-off-by: Tomoki Sekiyama <tomoki.sekiyama@hds.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>