1. 19 6月, 2015 5 次提交
  2. 18 6月, 2015 3 次提交
    • L
      x86/mm/pat, drivers/infiniband/ipath: Use arch_phys_wc_add() and require PAT disabled · 7ea402d0
      Luis R. Rodriguez 提交于
      We are burrying direct access to MTRR code support on
      x86 in order to take advantage of PAT. In the future, we
      also want to make the default behaviour of ioremap_nocache()
      to use strong UC, use of mtrr_add() on those systems
      would make write-combining void.
      
      In order to help both enable us to later make strong
      UC default and in order to phase out direct MTRR access
      code port the driver over to arch_phys_wc_add() and
      annotate that the device driver requires systems to
      boot with PAT disabled, with the 'nopat' kernel parameter.
      
      This is a workable compromise given that the ipath device
      driver powers the old HTX bus cards that only work in
      AMD systems, while the newer IB/qib device driver
      powers all PCI-e cards. The ipath device driver is
      obsolete, hardware is hard to find and because of this
      its a reasonable compromise to require users of ipath
      to boot with 'nopat'.
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NDoug Ledford <dledford@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Andy Walls <awalls@md.metrocast.net>
      Cc: Antonino Daplas <adaplas@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Hal Rosenstock <hal.rosenstock@gmail.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Mike Marciniszyn <mike.marciniszyn@intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
      Cc: Roger Pau Monné <roger.pau@citrix.com>
      Cc: Roland Dreier <roland@purestorage.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Stefan Bader <stefan.bader@canonical.com>
      Cc: Suresh Siddha <sbsiddha@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
      Cc: Ville Syrjälä <syrjala@sci.fi>
      Cc: infinipath@intel.com
      Cc: jbeulich@suse.com
      Cc: konrad.wilk@oracle.com
      Cc: linux-rdma@vger.kernel.org
      Cc: mchehab@osg.samsung.com
      Cc: toshi.kani@hp.com
      Link: http://lkml.kernel.org/r/1434053994-2196-4-git-send-email-mcgrof@do-not-panic.com
      Link: http://lkml.kernel.org/r/1434356898-25135-5-git-send-email-bp@alien8.deSigned-off-by: NIngo Molnar <mingo@kernel.org>
      7ea402d0
    • L
      x86/mm/pat, drivers/media/ivtv: Use arch_phys_wc_add() and require PAT disabled · 1bf1735b
      Luis R. Rodriguez 提交于
      We are burrying direct access to MTRR code support on
      x86 in order to take advantage of PAT. In the future, we
      also want to make the default behavior of ioremap_nocache()
      to use strong UC, at which point the use of mtrr_add() on
      those systems would make write-combining void.
      
      In order to help both enable us to later make strong
      UC default and in order to phase out direct MTRR access
      code, port the driver over to the arch_phys_wc_add() API
      and annotate that the device driver requires systems to
      boot with PAT disabled, with the 'nopat' kernel parameter.
      
      This is a workable compromise given that the hardware is
      really rare these days, and perhaps only some lost souls
      stuck with obsolete hardware are expected to be using this
      feature of the device driver.
      Signed-off-by: NLuis R. Rodriguez <mcgrof@suse.com>
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NAndy Walls <awalls@md.metrocast.net>
      Acked-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Antonino Daplas <adaplas@gmail.com>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Doug Ledford <dledford@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roger Pau Monné <roger.pau@citrix.com>
      Cc: Stefan Bader <stefan.bader@canonical.com>
      Cc: Suresh Siddha <sbsiddha@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ville Syrjälä <syrjala@sci.fi>
      Cc: bhelgaas@google.com
      Cc: konrad.wilk@oracle.com
      Cc: linux-media@vger.kernel.org
      Cc: tomi.valkeinen@ti.com
      Cc: toshi.kani@hp.com
      Link: http://lkml.kernel.org/r/1434053994-2196-2-git-send-email-mcgrof@do-not-panic.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1bf1735b
    • M
      Kconfig: disable Media Controller for DVB · 6cea28d0
      Mauro Carvalho Chehab 提交于
      Since when we start discussions about the usage Media Controller for
      complex hardware, one thing become clear: the way it is, MC fails to
      map anything different than capture/output/m2m video-only streaming.
      
      The point is that MC has entities named as devnodes, but the only
      devnode used (before the DVB patches) is MEDIA_ENT_T_DEVNODE_V4L.
      Due to the way MC got implemented, however, this entity actually
      doesn't represent the devnode, but the hardware I/O engine that
      receives data via DMA.
      
      By coincidence, such DMA is associated with the V4L device node
      on webcam hardware, but this is not true even for other V4L2
      devices. For example, on USB hardware, the DMA is done via the
      USB controller. The data passes though a in-kernel filter that
      strips off the URB headers. Other V4L2 devices like radio may not
      even have DMA. When it have, the DMA is done via ALSA, and not
      via the V4L devnode.
      
      In other words, MC is broken as a whole, but tagging it as BROKEN
      right now would do more harm than good.
      
      So, instead, let's mark, for now, the DVB part as broken and
      block all new changes to MC while we fix this mess, whith
      we hopefully will do for the next Kernel version.
      Requested-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6cea28d0
  3. 16 6月, 2015 3 次提交
    • S
      crypto: caam - fix RNG buffer cache alignment · 412c98c1
      Steve Cornelius 提交于
      The hwrng output buffers (2) are cast inside of a a struct (caam_rng_ctx)
      allocated in one DMA-tagged region. While the kernel's heap allocator
      should place the overall struct on a cacheline aligned boundary, the 2
      buffers contained within may not necessarily align. Consenquently, the ends
      of unaligned buffers may not fully flush, and if so, stale data will be left
      behind, resulting in small repeating patterns.
      
      This fix aligns the buffers inside the struct.
      
      Note that not all of the data inside caam_rng_ctx necessarily needs to be
      DMA-tagged, only the buffers themselves require this. However, a fix would
      incur the expense of error-handling bloat in the case of allocation failure.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: NVictoria Milhoan <vicki.milhoan@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      412c98c1
    • S
      crypto: caam - improve initalization for context state saves · 6fd4b156
      Steve Cornelius 提交于
      Multiple function in asynchronous hashing use a saved-state block,
      a.k.a. struct caam_hash_state, which holds a stash of information
      between requests (init/update/final). Certain values in this state
      block are loaded for processing using an inline-if, and when this
      is done, the potential for uninitialized data can pose conflicts.
      Therefore, this patch improves initialization of state data to
      prevent false assignments using uninitialized data in the state block.
      
      This patch addresses the following traceback, originating in
      ahash_final_ctx(), although a problem like this could certainly
      exhibit other symptoms:
      
      kernel BUG at arch/arm/mm/dma-mapping.c:465!
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = 80004000
      [00000000] *pgd=00000000
      Internal error: Oops: 805 [#1] PREEMPT SMP
      Modules linked in:
      CPU: 0    Not tainted  (3.0.15-01752-gdd441b9-dirty #40)
      PC is at __bug+0x1c/0x28
      LR is at __bug+0x18/0x28
      pc : [<80043240>]    lr : [<8004323c>]    psr: 60000013
      sp : e423fd98  ip : 60000013  fp : 0000001c
      r10: e4191b84  r9 : 00000020  r8 : 00000009
      r7 : 88005038  r6 : 00000001  r5 : 2d676572  r4 : e4191a60
      r3 : 00000000  r2 : 00000001  r1 : 60000093  r0 : 00000033
      Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
      Control: 10c53c7d  Table: 1000404a  DAC: 00000015
      Process cryptomgr_test (pid: 1306, stack limit = 0xe423e2f0)
      Stack: (0xe423fd98 to 0xe4240000)
      fd80:                                                       11807fd1 80048544
      fda0: 88005000 e4191a00 e5178040 8039dda0 00000000 00000014 2d676572 e4191008
      fdc0: 88005018 e4191a60 00100100 e4191a00 00000000 8039ce0c e423fea8 00000007
      fde0: e4191a00 e4227000 e5178000 8039ce18 e419183c 80203808 80a94a44 00000006
      fe00: 00000000 80207180 00000000 00000006 e423ff08 00000000 00000007 e5178000
      fe20: e41918a4 80a949b4 8c4844e2 00000000 00000049 74227000 8c4844e2 00000e90
      fe40: 0000000e 74227e90 ffff8c58 80ac29e0 e423fed4 8006a350 8c81625c e423ff5c
      fe60: 00008576 e4002500 00000003 00030010 e4002500 00000003 e5180000 e4002500
      fe80: e5178000 800e6d24 007fffff 00000000 00000010 e4001280 e4002500 60000013
      fea0: 000000d0 804df078 00000000 00000000 00000000 00000000 00000000 00000000
      fec0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      fee0: 00000000 00000000 e4227000 e4226000 e4753000 e4752000 e40a5000 e40a4000
      ff00: e41e7000 e41e6000 00000000 00000000 00000000 e423ff14 e423ff14 00000000
      ff20: 00000400 804f9080 e5178000 e4db0b40 00000000 e4db0b80 0000047c 00000400
      ff40: 00000000 8020758c 00000400 ffffffff 0000008a 00000000 e4db0b40 80206e00
      ff60: e4049dbc 00000000 00000000 00000003 e423ffa4 80062978 e41a8bfc 00000000
      ff80: 00000000 e4049db4 00000013 e4049db0 00000013 00000000 00000000 00000000
      ffa0: e4db0b40 e4db0b40 80204cbc 00000013 00000000 00000000 00000000 80204cfc
      ffc0: e4049da0 80089544 80040a40 00000000 e4db0b40 00000000 00000000 00000000
      ffe0: e423ffe0 e423ffe0 e4049da0 800894c4 80040a40 80040a40 00000000 00000000
      [<80043240>] (__bug+0x1c/0x28) from [<80048544>] (___dma_single_dev_to_cpu+0x84)
      [<80048544>] (___dma_single_dev_to_cpu+0x84/0x94) from [<8039dda0>] (ahash_fina)
      [<8039dda0>] (ahash_final_ctx+0x180/0x428) from [<8039ce18>] (ahash_final+0xc/0)
      [<8039ce18>] (ahash_final+0xc/0x10) from [<80203808>] (crypto_ahash_op+0x28/0xc)
      [<80203808>] (crypto_ahash_op+0x28/0xc0) from [<80207180>] (test_hash+0x214/0x5)
      [<80207180>] (test_hash+0x214/0x5b8) from [<8020758c>] (alg_test_hash+0x68/0x8c)
      [<8020758c>] (alg_test_hash+0x68/0x8c) from [<80206e00>] (alg_test+0x7c/0x1b8)
      [<80206e00>] (alg_test+0x7c/0x1b8) from [<80204cfc>] (cryptomgr_test+0x40/0x48)
      [<80204cfc>] (cryptomgr_test+0x40/0x48) from [<80089544>] (kthread+0x80/0x88)
      [<80089544>] (kthread+0x80/0x88) from [<80040a40>] (kernel_thread_exit+0x0/0x8)
      Code: e59f0010 e1a01003 eb126a8d e3a03000 (e5833000)
      ---[ end trace d52a403a1d1eaa86 ]---
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NSteve Cornelius <steve.cornelius@freescale.com>
      Signed-off-by: NVictoria Milhoan <vicki.milhoan@freescale.com>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6fd4b156
    • A
      drm/mgag200: Reject non-character-cell-aligned mode widths · 25161084
      Adam Jackson 提交于
      Turns out 1366x768 does not in fact work on this hardware.
      Signed-off-by: NAdam Jackson <ajax@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NDave Airlie <airlied@redhat.com>
      25161084
  4. 15 6月, 2015 2 次提交
  5. 13 6月, 2015 1 次提交
  6. 12 6月, 2015 14 次提交
  7. 11 6月, 2015 9 次提交
    • M
      drm/radeon: Make sure radeon_vm_bo_set_addr always unreserves the BO · ee18e599
      Michel Dänzer 提交于
      Some error paths didn't unreserve the BO. This resulted in a deadlock
      down the road on the next attempt to reserve the (still reserved) BO.
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90873
      Cc: stable@vger.kernel.org
      Reviewed-by: NChristian König <christian.koenig@amd.com>
      Signed-off-by: NMichel Dänzer <michel.daenzer@amd.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      ee18e599
    • A
      Revert "drm/radeon: adjust pll when audio is not enabled" · ebb9bf18
      Alex Deucher 提交于
      This reverts commit 7fe04d6f.
      
      Fixes some systems at the expense of others.  Need to properly
      fix the pll divider selection.
      
      bug:
      https://bugzilla.kernel.org/show_bug.cgi?id=99651
      
      Cc: stable@vger.kernel.org
      ebb9bf18
    • A
      Revert "drm/radeon: don't share plls if monitors differ in audio support" · 6fb3c025
      Alex Deucher 提交于
      This reverts commit a10f0df0.
      
      Fixes some systems at the expense of others.  Need to properly
      fix the pll divider selection.
      
      bug:
      https://bugzilla.kernel.org/show_bug.cgi?id=99651
      
      Cc: stable@vger.kernel.org
      6fb3c025
    • J
      drm/radeon: fix freeze for laptop with Turks/Thames GPU. · 6dfd1972
      Jérôme Glisse 提交于
      Laptop with Turks/Thames GPU will freeze if dpm is enabled. It seems
      the SMC engine is relying on some state inside the CP engine. CP needs
      to chew at least one packet for it to get in good state for dynamic
      power management.
      
      This patch simply disabled and re-enable DPM after the ring test which
      is enough to avoid the freeze.
      Signed-off-by: NJérôme Glisse <jglisse@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      6dfd1972
    • D
      ntb: initialize max_mw for Atom before using it · ebaad132
      Daniel Verkamp 提交于
      Commit ab760a0c (ntb: Adding split BAR support for Haswell platforms)
      changed ntb_device's mw from a fixed-size array into a pointer that is
      allocated based on limits.max_mw; however, on Atom platforms, max_mw
      is not initialized until ntb_device_setup(), which happens after the
      allocation.
      
      Fill out max_mw in ntb_atom_detect() to match ntb_xeon_detect(); this
      happens before the use of max_mw in the ndev->mw allocation.
      
      Fixes a null pointer dereference on Atom platforms with ntb hardware.
      
      v2: fix typo (mw_max should be max_mw)
      Signed-off-by: NDaniel Verkamp <daniel.verkamp@intel.com>
      Acked-by: NDave Jiang <dave.jiang@intel.com>
      Signed-off-by: NJon Mason <jdmason@kudzu.us>
      ebaad132
    • G
      enic: fix memory leak in rq_clean · 8b13b4e0
      Govindarajulu Varadarajan 提交于
      When incoming packet qualifies for rx_copybreak, we copy the data to newly
      allocated skb. We do not free/unmap the original buffer. At this point driver
      assumes this buffer is unallocated. When enic_rq_alloc_buf() is called for
      buffer allocation, it checks if buf->os_buf is NULL. If its not NULL that means
      buffer can be re-used.
      
      When vnic_rq_clean() is called for freeing all rq buffers, and if the
      rx_copybreak reused buffer falls outside the used desc, we do not free the
      buffer. The following trace is observer when dma-debug is enabled.
      
      Fix is to walk through complete ring and clean if buffer is present.
      
      [   40.555386] ------------[ cut here ]------------
      [   40.555396] WARNING: CPU: 0 PID: 491 at lib/dma-debug.c:971 dma_debug_device_change+0x188/0x1f0()
      [   40.555400] pci 0000:06:00.0: DMA-API: device driver has pending DMA allocations while released from device [count=4]
                     One of leaked entries details: [device address=0x00000000ff4cc040] [size=9018 bytes] [mapped with DMA_FROM_DEVICE] [mapped as single]
      [   40.555402] Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw joydev mousedev gf128mul hid_generic glue_helper mgag200 usbhid ttm hid drm_kms_helper drm ablk_helper syscopyarea sysfillrect sysimgblt i2c_algo_bit i2c_core iTCO_wdt cryptd mac_hid evdev pcspkr sb_edac edac_core tpm_tis iTCO_vendor_support ipmi_si wmi tpm ipmi_msghandler shpchp lpc_ich processor acpi_power_meter hwmon button ac sch_fq_codel nfs lockd grace sunrpc fscache sd_mod ehci_pci ehci_hcd megaraid_sas usbcore scsi_mod usb_common enic(-) crc32c_generic crc32c_intel btrfs xor raid6_pq ext4 crc16 mbcache jbd2
      [   40.555467] CPU: 0 PID: 491 Comm: rmmod Not tainted 4.1.0-rc7-ARCH-01305-gf59b71f #118
      [   40.555469] Hardware name: Cisco Systems Inc UCSB-B200-M4/UCSB-B200-M4, BIOS B200M4.2.2.2.23.061220140128 06/12/2014
      [   40.555471]  0000000000000000 00000000e2f8a5b7 ffff880275f8bc48 ffffffff8158d6f0
      [   40.555474]  0000000000000000 ffff880275f8bca0 ffff880275f8bc88 ffffffff8107b04a
      [   40.555477]  ffff8802734e0000 0000000000000004 ffff8804763fb3c0 ffff88027600b650
      [   40.555480] Call Trace:
      [   40.555488]  [<ffffffff8158d6f0>] dump_stack+0x4f/0x7b
      [   40.555492]  [<ffffffff8107b04a>] warn_slowpath_common+0x8a/0xc0
      [   40.555494]  [<ffffffff8107b0d5>] warn_slowpath_fmt+0x55/0x70
      [   40.555498]  [<ffffffff812fa408>] dma_debug_device_change+0x188/0x1f0
      [   40.555503]  [<ffffffff8109aaef>] notifier_call_chain+0x4f/0x80
      [   40.555506]  [<ffffffff8109aecb>] __blocking_notifier_call_chain+0x4b/0x70
      [   40.555510]  [<ffffffff8109af06>] blocking_notifier_call_chain+0x16/0x20
      [   40.555514]  [<ffffffff813f8066>] __device_release_driver+0xf6/0x120
      [   40.555518]  [<ffffffff813f8b08>] driver_detach+0xc8/0xd0
      [   40.555523]  [<ffffffff813f7c59>] bus_remove_driver+0x59/0xe0
      [   40.555527]  [<ffffffff813f93a0>] driver_unregister+0x30/0x70
      [   40.555534]  [<ffffffff8131532d>] pci_unregister_driver+0x2d/0xa0
      [   40.555542]  [<ffffffffa0200ec2>] enic_cleanup_module+0x10/0x14e [enic]
      [   40.555547]  [<ffffffff8110158f>] SyS_delete_module+0x1cf/0x280
      [   40.555551]  [<ffffffff811e284e>] ? ____fput+0xe/0x10
      [   40.555554]  [<ffffffff810980ec>] ? task_work_run+0xbc/0xf0
      [   40.555558]  [<ffffffff815930ee>] system_call_fastpath+0x12/0x71
      [   40.555561] ---[ end trace 4988cadc77c2b236 ]---
      [   40.555562] Mapped at:
      [   40.555563]  [<ffffffff812fa865>] debug_dma_map_page+0x95/0x150
      [   40.555566]  [<ffffffffa01f4a88>] enic_rq_alloc_buf+0x1b8/0x360 [enic]
      [   40.555570]  [<ffffffffa01f7658>] enic_open+0xf8/0x820 [enic]
      [   40.555574]  [<ffffffff8148d50e>] __dev_open+0xce/0x150
      [   40.555579]  [<ffffffff8148d851>] __dev_change_flags+0xa1/0x170
      Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b13b4e0
    • G
      enic: check return value for stat dump · 19b596bd
      Govindarajulu Varadarajan 提交于
      We do not check the return value of enic_dev_stats_dump(). If allocation
      fails, we will hit NULL pointer reference.
      
      Return only if memory allocation fails. For other failures, we return the
      previously recorded values.
      Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      19b596bd
    • G
      enic: unlock napi busy poll before unmasking intr · 6286e828
      Govindarajulu Varadarajan 提交于
      There is a small window between vnic_intr_unmask() and enic_poll_unlock_napi().
      In this window if an irq occurs and napi is scheduled on different cpu, it tries
      to acquire enic_poll_lock_napi() and hits the following WARN_ON message.
      
      Fix is to unlock napi_poll before unmasking the interrupt.
      
      [  781.121746] ------------[ cut here ]------------
      [  781.121789] WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/cisco/enic/vnic_rq.h:228 enic_poll_msix_rq+0x36a/0x3c0 [enic]()
      [  781.121834] Modules linked in: nfsv3 nfs_acl rpcsec_gss_krb5 auth_rpcgss oid_registry nfsv4 dns_resolver coretemp intel_rapl iosf_mbi x86_pkg_temp_thermal intel_powerclamp kvm_intel kvm crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel mgag200 ttm drm_kms_helper joydev aes_x86_64 lrw drm gf128mul mousedev glue_helper sb_edac ablk_helper iTCO_wdt iTCO_vendor_support evdev ipmi_si syscopyarea sysfillrect sysimgblt i2c_algo_bit i2c_core edac_core lpc_ich mac_hid cryptd pcspkr ipmi_msghandler shpchp tpm_tis acpi_power_meter tpm wmi processor hwmon button ac sch_fq_codel nfs lockd grace sunrpc fscache hid_generic usbhid hid ehci_pci ehci_hcd sd_mod megaraid_sas usbcore scsi_mod usb_common enic crc32c_generic crc32c_intel btrfs xor raid6_pq ext4 crc16 mbcache jbd2
      [  781.122176] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.1.0-rc6-ARCH-00040-gc46a024e-dirty #106
      [  781.122210] Hardware name: Cisco Systems Inc UCSB-B200-M4/UCSB-B200-M4, BIOS B200M4.2.2.2.23.061220140128 06/12/2014
      [  781.122252]  0000000000000000 bddbbc9d655ec96e ffff880277e43da8 ffffffff81583fe8
      [  781.122286]  0000000000000000 0000000000000000 ffff880277e43de8 ffffffff8107acfa
      [  781.122319]  ffff880272c01000 ffff880273f18000 ffff880273f1a100 0000000000000000
      [  781.122352] Call Trace:
      [  781.122364]  <IRQ>  [<ffffffff81583fe8>] dump_stack+0x4f/0x7b
      [  781.122399]  [<ffffffff8107acfa>] warn_slowpath_common+0x8a/0xc0
      [  781.122425]  [<ffffffff8107ae2a>] warn_slowpath_null+0x1a/0x20
      [  781.122455]  [<ffffffffa01fa9ca>] enic_poll_msix_rq+0x36a/0x3c0 [enic]
      [  781.122487]  [<ffffffff8148525a>] net_rx_action+0x22a/0x370
      [  781.122512]  [<ffffffff8107ed3d>] __do_softirq+0xed/0x2d0
      [  781.122537]  [<ffffffff8107f06e>] irq_exit+0x7e/0xa0
      [  781.122560]  [<ffffffff8158c424>] do_IRQ+0x64/0x100
      [  781.122582]  [<ffffffff8158a42e>] common_interrupt+0x6e/0x6e
      [  781.122605]  <EOI>  [<ffffffff810bd331>] ? cpu_startup_entry+0x121/0x480
      [  781.122638]  [<ffffffff810bd2fc>] ? cpu_startup_entry+0xec/0x480
      [  781.122667]  [<ffffffff810f2ed3>] ? clockevents_register_device+0x113/0x1f0
      [  781.122698]  [<ffffffff81050ab6>] start_secondary+0x196/0x1e0
      [  781.122723] ---[ end trace cec2e9dd3af7b9db ]---
      Signed-off-by: NGovindarajulu Varadarajan <_govind@gmx.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6286e828
    • W
      zram: clear disk io accounting when reset zram device · d7ad41a1
      Weijie Yang 提交于
      Clear zram disk io accounting when resetting the zram device.  Otherwise
      the residual io accounting stat will affect the diskstat in the next
      zram active cycle.
      Signed-off-by: NWeijie Yang <weijie.yang@samsung.com>
      Acked-by: NSergey Senozhatsky <sergey.senozhatsky@gmail.com>
      Acked-by: NMinchan Kim <minchan@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      d7ad41a1
  8. 09 6月, 2015 3 次提交
    • H
      SSB: Fix handling of ssb_pmu_get_alp_clock() · 36f6ea2b
      Hauke Mehrtens 提交于
      Dan Carpenter reported missing brackets which resulted in reading a
      wrong crystalfreq value. I also noticed that the result of this
      function is ignored.
      Reported-By: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NHauke Mehrtens <hauke@hauke-m.de>
      Signed-off-by: NMichael Buesch <m@bues.ch>
      Cc: davem@davemloft.net
      Cc: netdev@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/10536/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      36f6ea2b
    • J
      drm/i915: Fix DDC probe for passive adapters · 3f5f1554
      Jani Nikula 提交于
      Passive DP->DVI/HDMI dongles on DP++ ports show up to the system as HDMI
      devices, as they do not have a sink device in them to respond to any AUX
      traffic. When probing these dongles over the DDC, sometimes they will
      NAK the first attempt even though the transaction is valid and they
      support the DDC protocol. The retry loop inside of
      drm_do_probe_ddc_edid() would normally catch this case and try the
      transaction again, resulting in success.
      
      That, however, was thwarted by the fix for [1]:
      
      commit 9292f37e
      Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
      Date:   Thu Jan 5 09:34:28 2012 -0200
      
          drm: give up on edid retries when i2c bus is not responding
      
      This added code to exit immediately if the return code from the
      i2c_transfer function was -ENXIO in order to reduce the amount of time
      spent in waiting for unresponsive or disconnected devices. That was
      possible because the underlying i2c bit banging algorithm had retries of
      its own (which, of course, were part of the reason for the bug the
      commit fixes).
      
      Since its introduction in
      
      commit f899fc64
      Author: Chris Wilson <chris@chris-wilson.co.uk>
      Date:   Tue Jul 20 15:44:45 2010 -0700
      
          drm/i915: use GMBUS to manage i2c links
      
      we've been flipping back and forth enabling the GMBUS transfers, but
      we've settled since then. The GMBUS implementation does not do any
      retries, however, bailing out of the drm_do_probe_ddc_edid() retry loop
      on first encounter of -ENXIO. This, combined with Eugeni's commit, broke
      the retry on -ENXIO.
      
      Retry GMBUS once on -ENXIO on first message to mitigate the issues with
      passive adapters.
      
      This patch is based on the work, and commit message, by Todd Previte
      <tprevite@gmail.com>.
      
      [1] https://bugs.freedesktop.org/show_bug.cgi?id=41059
      
      v2: Don't retry if using bit banging.
      
      v3: Move retry within gmbux_xfer, retry only on first message.
      
      v4: Initialize GMBUS0 on retry (Ville).
      
      v5: Take index reads into account (Ville).
      
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=85924
      Cc: Todd Previte <tprevite@gmail.com>
      Cc: stable@vger.kernel.org
      Tested-by: Oliver Grafe <oliver.grafe@ge.com> (v2)
      Tested-by: NJim Bride <jim.bride@linux.intel.com>
      Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      3f5f1554
    • S
      iser-target: Fix possible use-after-free · 524630d5
      Sagi Grimberg 提交于
      iser connection termination process happens in 2 stages:
      - isert_wait_conn:
        - resumes rdma disconnect
        - wait for session commands
        - wait for flush completions (post a marked wr to signal we are done)
        - wait for logout completion
        - queue work for connection cleanup (depends on disconnected/timewait
          events)
      - isert_free_conn
        - last reference put on the connection
      
      In case we are terminating during IOs, we might be posting send/recv
      requests after we posted the last work request which might lead
      to a use-after-free condition in isert_handle_wc.
      After we posted the last wr in isert_wait_conn we are guaranteed that
      no successful completions will follow (meaning no new work request posts
      may happen) but other flush errors might still come. So before we
      put the last reference on the connection, we repeat the process of
      posting a marked work request (isert_wait4flush) in order to make sure all
      pending completions were flushed.
      Signed-off-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NJenny Falkovich <jennyf@mellanox.com>
      Cc: stable@vger.kernel.org # 3.10+
      Signed-off-by: NNicholas Bellinger <nab@linux-iscsi.org>
      524630d5
新手
引导
客服 返回
顶部