1. 11 2月, 2016 5 次提交
    • T
      ARM: 8508/2: videobuf2-dc: Let drivers specify DMA attrs · ccc66e73
      Tomasz Figa 提交于
      DMA allocations might be subject to certain requirements specific to the
      hardware using the buffers, such as availability of kernel mapping (for
      contents fix-ups in the driver). The only entity that knows them is the
      driver, so it must share this knowledge with vb2-dc.
      
      This patch extends the alloc_ctx initialization interface to let the
      driver specify DMA attrs, which are then stored inside the allocation
      context and will be used for all allocations with that context.
      
      As a side effect, all dma_*_coherent() calls are turned into
      dma_*_attrs() calls, because the attributes need to be carried over
      through all DMA operations.
      Signed-off-by: NTomasz Figa <tfiga@chromium.org>
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
      Acked-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      ccc66e73
    • D
      ARM: 8507/1: dma-mapping: Use DMA_ATTR_ALLOC_SINGLE_PAGES hint to optimize alloc · 14d3ae2e
      Doug Anderson 提交于
      If we know that TLB efficiency will not be an issue when memory is
      accessed then it's not terribly important to allocate big chunks of
      memory.  The whole point of allocating the big chunks was that it would
      make TLB usage efficient.
      
      As Marek Szyprowski indicated:
          Please note that mapping memory with larger pages significantly
          improves performance, especially when IOMMU has a little TLB
          cache. This can be easily observed when multimedia devices do
          processing of RGB data with 90/270 degree rotation
      Image rotation is distinctly an operation that needs to bounce around
      through memory, so it makes sense that TLB efficiency is important
      there.
      
      Video decoding, on the other hand, is a fairly sequential operation.
      During video decoding it's not expected that we'll be jumping all over
      memory.  Decoding video is also pretty heavy and the TLB misses aren't a
      huge deal.  Presumably most HW video acceleration users of dma-mapping
      will not care about huge pages and will set DMA_ATTR_ALLOC_SINGLE_PAGES.
      
      Allocating big chunks of memory is quite expensive, especially if we're
      doing it repeadly and memory is full.  In one (out of tree) usage model
      it is common that arm_iommu_alloc_attrs() is called 16 times in a row,
      each one trying to allocate 4 MB of memory.  This is called whenever the
      system encounters a new video, which could easily happen while the
      memory system is stressed out.  In fact, on certain social media
      websites that auto-play video and have infinite scrolling, it's quite
      common to see not just one of these 16x4MB allocations but 2 or 3 right
      after another.  Asking the system even to do a small amount of extra
      work to give us big chunks in this case is just not a good use of time.
      
      Allocating big chunks of memory is also expensive indirectly.  Even if
      we ask the system not to do ANY extra work to allocate _our_ memory,
      we're still potentially eating up all big chunks in the system.
      Presumably there are other users in the system that aren't quite as
      flexible and that actually need these big chunks.  By eating all the big
      chunks we're causing extra work for the rest of the system.  We also may
      start making other memory allocations fail.  While the system may be
      robust to such failures (as is the case with dwc2 USB trying to allocate
      buffers for Ethernet data and with WiFi trying to allocate buffers for
      WiFi data), it is yet another big performance hit.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      14d3ae2e
    • D
      ARM: 8506/1: common: DMA-mapping: add DMA_ATTR_ALLOC_SINGLE_PAGES attribute · df05c6f6
      Doug Anderson 提交于
      This patch adds the DMA_ATTR_ALLOC_SINGLE_PAGES attribute to the
      DMA-mapping subsystem.
      
      This attribute can be used as a hint to the DMA-mapping subsystem that
      it's likely not worth it to try to allocate large pages behind the
      scenes.  Large pages are likely to make an IOMMU TLB work more
      efficiently but may not be worth it.  See the Documentation contained in
      this patch for more details about this attribute and when to use it.
      
      Note that the name of the hint (DMA_ATTR_ALLOC_SINGLE_PAGES) is loosely
      based on the name MADV_NOHUGEPAGE.  Just as there is MADV_NOHUGEPAGE
      vs. MADV_HUGEPAGE we could also add an "opposite" attribute to
      DMA_ATTR_ALLOC_SINGLE_PAGES.  Without having the "opposite" attribute
      the lack of DMA_ATTR_ALLOC_SINGLE_PAGES means "use your best judgement
      about whether to use small pages or large pages".
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      df05c6f6
    • D
      ARM: 8505/1: dma-mapping: Optimize allocation · 33298ef6
      Doug Anderson 提交于
      The __iommu_alloc_buffer() is expected to be called to allocate pretty
      sizeable buffers.  Upon simple tests of video I saw it trying to
      allocate 4,194,304 bytes.  The function tries to allocate large chunks
      in order to optimize IOMMU TLB usage.
      
      The current function is very, very slow.
      
      One problem is the way it keeps trying and trying to allocate big
      chunks.  Imagine a very fragmented memory that has 4M free but no
      contiguous pages at all.  Further imagine allocating 4M (1024 pages).
      We'll do the following memory allocations:
      - For page 1:
        - Try to allocate order 10 (no retry)
        - Try to allocate order 9 (no retry)
        - ...
        - Try to allocate order 0 (with retry, but not needed)
      - For page 2:
        - Try to allocate order 9 (no retry)
        - Try to allocate order 8 (no retry)
        - ...
        - Try to allocate order 0 (with retry, but not needed)
      - ...
      - ...
      
      Total number of calls to alloc() calls for this case is:
        sum(int(math.log(i, 2)) + 1 for i in range(1, 1025))
        => 9228
      
      The above is obviously worse case, but given how slow alloc can be we
      really want to try to avoid even somewhat bad cases.  I timed the old
      code with a device under memory pressure and it wasn't hard to see it
      take more than 120 seconds to allocate 4 megs of memory! (NOTE: testing
      was done on kernel 3.14, so possibly mainline would behave
      differently).
      
      A second problem is that allocating big chunks under memory pressure
      when we don't need them is just not a great idea anyway unless we really
      need them.  We can make due pretty well with smaller chunks so it's
      probably wise to leave bigger chunks for other users once memory
      pressure is on.
      
      Let's adjust the allocation like this:
      
      1. If a big chunk fails, stop trying to hard and bump down to lower
         order allocations.
      2. Don't try useless orders.  The whole point of big chunks is to
         optimize the TLB and it can really only make use of 2M, 1M, 64K and
         4K sizes.
      
      We'll still tend to eat up a bunch of big chunks, but that might be the
      right answer for some users.  A future patch could possibly add a new
      DMA_ATTR that would let the caller decide that TLB optimization isn't
      important and that we should use smaller chunks.  Presumably this would
      be a sane strategy for some callers.
      Signed-off-by: NDouglas Anderson <dianders@chromium.org>
      Acked-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      Reviewed-by: NRobin Murphy <robin.murphy@arm.com>
      Reviewed-by: NTomasz Figa <tfiga@chromium.org>
      Tested-by: NJavier Martinez Canillas <javier@osg.samsung.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      33298ef6
    • N
      ARM: 8504/1: __arch_xprod_64(): small optimization · 73e592f3
      Nicolas Pitre 提交于
      The tmp variable is used twice: first to pose as a register containing
      a value of zero, and then to provide a temporary register that initially
      is zero and get added some value. But somehow gcc decides to split those
      two usages in different registers.
      
      Example code:
      
      u64 div64const1000(u64 x)
      {
      	u32 y = 1000;
      	do_div(x, y);
      	return x;
      }
      
      Result:
      
      div64const1000:
      	push	{r4, r5, r6, r7, lr}
      	mov	lr, #0
      	mov	r6, r0
      	mov	r7, r1
      	adr	r5, .L8
      	ldrd	r4, [r5]
      	mov	r1, lr
      	umull	r2, r3, r4, r6
      	cmn	r2, r4
      	adcs	r3, r3, r5
      	adc	r2, lr, #0
      	umlal	r3, r2, r5, r6
      	umlal	r3, r1, r4, r7
      	mov	r3, #0
      	adds	r2, r1, r2
      	adc	r3, r3, #0
      	umlal	r2, r3, r5, r7
      	lsr	r0, r2, #9
      	lsr	r1, r3, #9
      	orr	r0, r0, r3, lsl #23
      	pop	{r4, r5, r6, r7, pc}
      	.align	3
      .L8:
      	.word	-1924145349
      	.word	-2095944041
      
      Full kernel build size:
      
         text	   data	    bss	    dec	    hex	filename
      13663814	1553940	 351368	15569122	 ed90e2	vmlinux
      
      Here the two instances of 'tmp' are assigned to r1 and lr.
      
      To avoid that, let's mark the first 'tmp' usage in __arch_xprod_64()
      with a "+r" constraint even if the register is not written to, so to
      create a dependency for the second usage with the effect of enforcing
      a single temporary register throughout.
      
      Result:
      
      div64const1000:
      	push	{r4, r5, r6, r7}
      	movs	r3, #0
      	adr	r5, .L8
      	ldrd	r4, [r5]
      	umull	r6, r7, r4, r0
      	cmn	r6, r4
      	adcs	r7, r7, r5
      	adc	r6, r3, #0
      	umlal	r7, r6, r5, r0
      	umlal	r7, r3, r4, r1
      	mov	r7, #0
      	adds	r6, r3, r6
      	adc	r7, r7, #0
      	umlal	r6, r7, r5, r1
      	lsr	r0, r6, #9
      	lsr	r1, r7, #9
      	orr	r0, r0, r7, lsl #23
      	pop	{r4, r5, r6, r7}
      	bx	lr
      	.align	3
      .L8:
      	.word	-1924145349
      	.word	-2095944041
      
         text	   data	    bss	    dec	    hex	filename
      13663438	1553940	 351368	15568746	 ed8f6a	vmlinux
      
      This time 'tmp' is assigned to r3 and used throughout. However, by being
      assigned to r3, that blocks usage of the r2-r3 double register slot for
      64-bit values, forcing more registers to be spilled on the stack. Let's
      try to help it by forcing 'tmp' to the caller-saved ip register.
      
      Result:
      
      div64const1000:
      	stmfd	sp!, {r4, r5}
      	mov	ip, #0
      	adr	r5, .L8
      	ldrd	r4, [r5]
      	umull	r2, r3, r4, r0
      	cmn	r2, r4
      	adcs	r3, r3, r5
      	adc	r2, ip, #0
      	umlal	r3, r2, r5, r0
      	umlal	r3, ip, r4, r1
      	mov	r3, #0
      	adds	r2, ip, r2
      	adc	r3, r3, #0
      	umlal	r2, r3, r5, r1
      	mov	r0, r2, lsr #9
      	mov	r1, r3, lsr #9
      	orr	r0, r0, r3, asl #23
      	ldmfd	sp!, {r4, r5}
      	bx	lr
      	.align	3
      .L8:
      	.word	-1924145349
      	.word	-2095944041
      
         text	   data	    bss	    dec	    hex	filename
      13662838	1553940	 351368	15568146	 ed8d12	vmlinux
      
      We could make the code marginally smaller yet by forcing 'tmp' to lr
      instead, but that would have a negative inpact on branch prediction for
      which "bx lr" is optimal.
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      73e592f3
  2. 08 2月, 2016 3 次提交
    • K
      ARM: 8501/1: mm: flip priority of CONFIG_DEBUG_RODATA · 25362dc4
      Kees Cook 提交于
      The use of CONFIG_DEBUG_RODATA is generally seen as an essential part of
      kernel self-protection:
      http://www.openwall.com/lists/kernel-hardening/2015/11/30/13
      Additionally, its name has grown to mean things beyond just rodata. To
      get ARM closer to this, we ought to rearrange the names of the configs
      that control how the kernel protects its memory. What was called
      CONFIG_ARM_KERNMEM_PERMS is realy doing the work that other architectures
      call CONFIG_DEBUG_RODATA.
      
      This redefines CONFIG_DEBUG_RODATA to actually do the bulk of the
      ROing (and NXing). In the place of the old CONFIG_DEBUG_RODATA, use
      CONFIG_DEBUG_ALIGN_RODATA, since that's what the option does: adds
      section alignment for making rodata explicitly NX, as arm does not split
      the page tables like arm64 does without _ALIGN_RODATA.
      
      Also adds human readable names to the sections so I could more easily
      debug my typos, and makes CONFIG_DEBUG_RODATA default "y" for CPU_V7.
      
      Results in /sys/kernel/debug/kernel_page_tables for each config state:
      
       # CONFIG_DEBUG_RODATA is not set
       # CONFIG_DEBUG_ALIGN_RODATA is not set
      
      ---[ Kernel Mapping ]---
      0x80000000-0x80900000           9M     RW x  SHD
      0x80900000-0xa0000000         503M     RW NX SHD
      
       CONFIG_DEBUG_RODATA=y
       CONFIG_DEBUG_ALIGN_RODATA=y
      
      ---[ Kernel Mapping ]---
      0x80000000-0x80100000           1M     RW NX SHD
      0x80100000-0x80700000           6M     ro x  SHD
      0x80700000-0x80a00000           3M     ro NX SHD
      0x80a00000-0xa0000000         502M     RW NX SHD
      
       CONFIG_DEBUG_RODATA=y
       # CONFIG_DEBUG_ALIGN_RODATA is not set
      
      ---[ Kernel Mapping ]---
      0x80000000-0x80100000           1M     RW NX SHD
      0x80100000-0x80a00000           9M     ro x  SHD
      0x80a00000-0xa0000000         502M     RW NX SHD
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NLaura Abbott <labbott@fedoraproject.org>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      25362dc4
    • R
      ARM: use virt_to_idmap() for soft_restart() · 4138323e
      Russell King 提交于
      Code run via soft_restart() is run with the MMU disabled, so we need to
      pass the identity map physical address rather than the address obtained
      from virt_to_phys().  Therefore, replace virt_to_phys() with
      virt_to_idmap() for all callers of soft_restart().
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      4138323e
    • R
      ARM: make virt_to_idmap() return unsigned long · 28410293
      Russell King 提交于
      Make virt_to_idmap() return an unsigned long rather than phys_addr_t.
      
      Returning phys_addr_t here makes no sense, because the definition of
      virt_to_idmap() is that it shall return a physical address which maps
      identically with the virtual address.  Since virtual addresses are
      limited to 32-bit, identity mapped physical addresses are as well.
      
      Almost all users already had an implicit narrowing cast to unsigned long
      so let's make this official and part of this interface.
      Tested-by: NGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      28410293
  3. 27 1月, 2016 3 次提交
  4. 25 1月, 2016 11 次提交
    • L
      Linux 4.5-rc1 · 92e963f5
      Linus Torvalds 提交于
      92e963f5
    • L
      Merge branch 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus · e2464688
      Linus Torvalds 提交于
      Pull MIPS updates from Ralf Baechle:
       "This is the main pull request for MIPS for 4.5 plus some 4.4 fixes.
      
        The executive summary:
      
         - ATH79 platform improvments, use DT bindings for the ATH79 USB PHY.
         - Avoid useless rebuilds for zboot.
         - jz4780: Add NEMC, BCH and NAND device tree nodes
         - Initial support for the MicroChip's DT platform.  As all the device
           drivers are missing this is still of limited use.
         - Some Loongson3 cleanups.
         - The unavoidable whitespace polishing.
         - Reduce clock skew when synchronizing the CPU cycle counters on CPU
           startup.
         - Add MIPS R6 fixes.
         - Lots of cleanups across arch/mips as fallout from KVM.
         - Lots of minor fixes and changes for IEEE 754-2008 support to the
           FPU emulator / fp-assist software.
         - Minor Ralink, BCM47xx and bcm963xx platform support improvments.
         - Support SMP on BCM63168"
      
      * 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus: (84 commits)
        MIPS: zboot: Add support for serial debug using the PROM
        MIPS: zboot: Avoid useless rebuilds
        MIPS: BMIPS: Enable ARCH_WANT_OPTIONAL_GPIOLIB
        MIPS: bcm63xx: nvram: Remove unused bcm63xx_nvram_get_psi_size() function
        MIPS: bcm963xx: Update bcm_tag field image_sequence
        MIPS: bcm963xx: Move extended flash address to bcm_tag header file
        MIPS: bcm963xx: Move Broadcom BCM963xx image tag data structure
        MIPS: bcm63xx: nvram: Use nvram structure definition from header file
        MIPS: bcm963xx: Add Broadcom BCM963xx board nvram data structure
        MAINTAINERS: Add KVM for MIPS entry
        MIPS: KVM: Add missing newline to kvm_err()
        MIPS: Move KVM specific opcodes into asm/inst.h
        MIPS: KVM: Use cacheops.h definitions
        MIPS: Break down cacheops.h definitions
        MIPS: Use EXCCODE_ constants with set_except_vector()
        MIPS: Update trap codes
        MIPS: Move Cause.ExcCode trap codes to mipsregs.h
        MIPS: KVM: Make kvm_mips_{init,exit}() static
        MIPS: KVM: Refactor added offsetof()s
        MIPS: KVM: Convert EXPORT_SYMBOL to _GPL
        ...
      e2464688
    • L
      Merge tag 'platform-drivers-x86-v4.5-2' of... · e1c10879
      Linus Torvalds 提交于
      Merge tag 'platform-drivers-x86-v4.5-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86
      
      Pull x86 platform driver updates from Darren Hart:
       "Emergency travel prevented me from completing my final testing on this
        until today.  Nothing here that couldn't wait until RC1 fixes, but I
        thought it best to get it out sooner rather than later as it does
        contain a build warning fix.
      
        Summary:
      
        A build warning fix, MAINTAINERS cleanup, and a new DMI quirk:
      
        ideapad-laptop:
         - Add Lenovo Yoga 700 to no_hw_rfkill dmi list
      
        MAINTAINERS:
         - Combine multiple telemetry entries
      
        intel_telemetry_debugfs:
         - Fix unused warnings in telemetry debugfs"
      
      * tag 'platform-drivers-x86-v4.5-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
        ideapad-laptop: Add Lenovo Yoga 700 to no_hw_rfkill dmi list
        MAINTAINERS: Combine multiple telemetry entries
        intel_telemetry_debugfs: Fix unused warnings in telemetry debugfs
      e1c10879
    • L
      Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux · 81f05fee
      Linus Torvalds 提交于
      Pull thermal management updates from Zhang Rui:
       "The top merge commit was re-generated yesterday because two topic
        branches were dropped from this pull request in the last minute due to
        some unaddressed comments.  All the other material has been in
        linux-next for quite a while.
      
        Specifics:
      
         - Enhance thermal core to handle unexpected device cooling states
           after fresh boot and system resume.  From Zhang Rui and Chen Yu.
      
         - Several fixes and cleanups on Rockchip and RCAR thermal drivers.
           From Caesar Wang and Kuninori Morimoto.
      
         - Add Broxton support for Intel processor thermal reporting device
           driver.  From Amy Wiles"
      
      * 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
        thermal: trip_point_temp_store() calls thermal_zone_device_update()
        thermal: rcar: rcar_thermal_get_temp() return error if strange temp
        thermal: rcar: check irq possibility in rcar_thermal_irq_xxx()
        thermal: rcar: check every rcar_thermal_update_temp() return value
        thermal: rcar: move rcar_thermal_dt_ids to upside
        thermal: rockchip: Support the RK3399 SoCs in thermal driver
        thermal: rockchip: Support the RK3228 SoCs in thermal driver
        dt-bindings: rockchip-thermal: Support the RK3228/RK3399 SoCs compatible
        thermal: rockchip: fix a trivial typo
        Thermal: Enable Broxton SoC thermal reporting device
        thermal: constify pch_dev_ops structure
        Thermal: do thermal zone update after a cooling device registered
        Thermal: handle thermal zone device properly during system sleep
        Thermal: initialize thermal zone device correctly
      81f05fee
    • L
      Merge tag 'for-linus-4.5-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs · c52cb431
      Linus Torvalds 提交于
      Pull 9p updates from Eric Van Hensbergen:
       "Sorry for the last minute pull request, there's was a change that
        didn't get pulled into for-next until two weeks ago and I wanted to
        give it some bake time.
      
        Summary:
      
        Rework and error handling fixes, primarily in the fscatch and fd
        transports"
      
      * tag 'for-linus-4.5-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/ericvh/v9fs:
        fs/9p: use fscache mutex rather than spinlock
        9p: trans_fd, bail out if recv fcall if missing
        9p: trans_fd, read rework to use p9_parse_header
        net/9p: Add device name details on error
      c52cb431
    • L
      Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client · 00e3f5cc
      Linus Torvalds 提交于
      Pull Ceph updates from Sage Weil:
       "The two main changes are aio support in CephFS, and a series that
        fixes several issues in the authentication key timeout/renewal code.
      
        On top of that are a variety of cleanups and minor bug fixes"
      
      * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client:
        libceph: remove outdated comment
        libceph: kill off ceph_x_ticket_handler::validity
        libceph: invalidate AUTH in addition to a service ticket
        libceph: fix authorizer invalidation, take 2
        libceph: clear messenger auth_retry flag if we fault
        libceph: fix ceph_msg_revoke()
        libceph: use list_for_each_entry_safe
        ceph: use i_size_{read,write} to get/set i_size
        ceph: re-send AIO write request when getting -EOLDSNAP error
        ceph: Asynchronous IO support
        ceph: Avoid to propagate the invalid page point
        ceph: fix double page_unlock() in page_mkwrite()
        rbd: delete an unnecessary check before rbd_dev_destroy()
        libceph: use list_next_entry instead of list_entry_next
        ceph: ceph_frag_contains_value can be boolean
        ceph: remove unused functions in ceph_frag.h
      00e3f5cc
    • L
      Merge branch 'for-next' of git://git.samba.org/sfrench/cifs-2.6 · 772950ed
      Linus Torvalds 提交于
      Pull SMB3 fixes from Steve French:
       "A collection of CIFS/SMB3 fixes.
      
        It includes a couple bug fixes, a few for improved debugging of
        cifs.ko and some improvements to the way cifs does key generation.
      
        I do have some additional bug fixes I expect in the next week or two
        (to address a problem found by xfstest, and some fixes for SMB3.11
        dialect, and a couple patches that just came in yesterday that I am
        reviewing)"
      
      * 'for-next' of git://git.samba.org/sfrench/cifs-2.6:
        cifs_dbg() outputs an uninitialized buffer in cifs_readdir()
        cifs: fix race between call_async() and reconnect()
        Prepare for encryption support (first part). Add decryption and encryption key generation. Thanks to Metze for helping with this.
        cifs: Allow using O_DIRECT with cache=loose
        cifs: Make echo interval tunable
        cifs: Check uniqueid for SMB2+ and return -ESTALE if necessary
        Print IP address of unresponsive server
        cifs: Ratelimit kernel log messages
      772950ed
    • J
      ideapad-laptop: Add Lenovo Yoga 700 to no_hw_rfkill dmi list · 6b31de3e
      Josh Boyer 提交于
      Like the Yoga 900 models the Lenovo Yoga 700 does not have a
      hw rfkill switch, and trying to read the hw rfkill switch through the
      ideapad module causes it to always reported blocking breaking wifi.
      
      This commit adds the Lenovo Yoga 700 to the no_hw_rfkill dmi list, fixing
      the wifi breakage.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1295272
      Tested-by: <dinyar.rabady+spam@gmail.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      6b31de3e
    • S
      MAINTAINERS: Combine multiple telemetry entries · f1fc3cd8
      Souvik Kumar Chakravarty 提交于
      This patch combines all the telemetry file entries in MAINTAINERS via
      wildcard.
      Signed-off-by: NSouvik Kumar Chakravarty <souvik.k.chakravarty@intel.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      f1fc3cd8
    • S
      intel_telemetry_debugfs: Fix unused warnings in telemetry debugfs · 7885f2f9
      Souvik Kumar Chakravarty 提交于
      This patch fixes compile time warnings when CONFIG_PM_SLEEP
      is undefined. In this case sleep related counters are unused.
      Signed-off-by: NSouvik Kumar Chakravarty <souvik.k.chakravarty@intel.com>
      Signed-off-by: NDarren Hart <dvhart@linux.intel.com>
      7885f2f9
    • C
      vmstat: Remove BUG_ON from vmstat_update · 587198ba
      Christoph Lameter 提交于
      If we detect that there is nothing to do just set the flag and do not
      check if it was already set before.  Races really do not matter.  If the
      flag is set by any code then the shepherd will start dealing with the
      situation and reenable the vmstat workers when necessary again.
      
      Since commit 0eb77e98 ("vmstat: make vmstat_updater deferrable again
      and shut down on idle") quiet_vmstat might update cpu_stat_off and mark
      a particular cpu to be handled by vmstat_shepherd.  This might trigger a
      VM_BUG_ON in vmstat_update because the work item might have been
      sleeping during the idle period and see the cpu_stat_off updated after
      the wake up.  The VM_BUG_ON is therefore misleading and no more
      appropriate.  Moreover it doesn't really suite any protection from real
      bugs because vmstat_shepherd will simply reschedule the vmstat_work
      anytime it sees a particular cpu set or vmstat_update would do the same
      from the worker context directly.  Even when the two would race the
      result wouldn't be incorrect as the counters update is fully idempotent.
      Reported-by: NSasha Levin <sasha.levin@oracle.com>
      Signed-off-by: NChristoph Lameter <cl@linux.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      587198ba
  5. 24 1月, 2016 18 次提交