1. 03 3月, 2016 2 次提交
  2. 01 3月, 2016 1 次提交
  3. 17 2月, 2016 3 次提交
  4. 13 2月, 2016 2 次提交
    • L
      IB/mlx5: Fix RC transport send queue overhead computation · 75c1657e
      Leon Romanovsky 提交于
      Fix the RC QPs send queue overhead computation to take into account
      two additional segments in the WQE which are needed for registration
      operations.
      
      The ATOMIC and UMR segments can't coexist together, so chose maximum out
      of them.
      
      The commit 9e65dc37 ("IB/mlx5: Fix RC transport send queue overhead
      computation") was intended to update RC transport as commit messages
      states, but added the code to UC transport.
      
      Fixes: 9e65dc37 ("IB/mlx5: Fix RC transport send queue overhead computation")
      Signed-off-by: NKamal Heib <kamalh@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Reviewed-by: NSagi Grimberg <sagig@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      75c1657e
    • A
      IB/ipoib: fix for rare multicast join race condition · 08bc3276
      Alex Estrin 提交于
      A narrow window for race condition still exist between
      multicast join thread and *dev_flush workers.
      A kernel crash caused by prolong erratic link state changes
      was observed (most likely a faulty cabling):
      
      [167275.656270] BUG: unable to handle kernel NULL pointer dereference at
      0000000000000020
      [167275.665973] IP: [<ffffffffa05f8f2e>] ipoib_mcast_join+0xae/0x1d0 [ib_ipoib]
      [167275.674443] PGD 0
      [167275.677373] Oops: 0000 [#1] SMP
      ...
      [167275.977530] Call Trace:
      [167275.982225]  [<ffffffffa05f92f0>] ? ipoib_mcast_free+0x200/0x200 [ib_ipoib]
      [167275.992024]  [<ffffffffa05fa1b7>] ipoib_mcast_join_task+0x2a7/0x490
      [ib_ipoib]
      [167276.002149]  [<ffffffff8109d5fb>] process_one_work+0x17b/0x470
      [167276.010754]  [<ffffffff8109e3cb>] worker_thread+0x11b/0x400
      [167276.019088]  [<ffffffff8109e2b0>] ? rescuer_thread+0x400/0x400
      [167276.027737]  [<ffffffff810a5aef>] kthread+0xcf/0xe0
      Here was a hit spot:
      ipoib_mcast_join() {
      ..............
            rec.qkey      = priv->broadcast->mcmember.qkey;
                                             ^^^^^^^
      .....
       }
      Proposed patch should prevent multicast join task to continue
      if link state change is detected.
      Signed-off-by: NAlex Estrin <alex.estrin@intel.com>
      
      Changes from v4:
      - as suggested by Doug Ledford, optimized spinlock usage,
      i.e. ipoib_mcast_join() is called with lock held.
      Changes from v3:
      - sync with priv->lock before flag check.
      Chages from v2:
      - Move check for OPER_UP flag state to mcast_join() to
      ensure no event worker is in progress.
      - minor style fixes.
      Changes from v1:
      - No need to lock again if error detected.
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      08bc3276
  5. 12 2月, 2016 2 次提交
  6. 06 2月, 2016 4 次提交
  7. 04 2月, 2016 5 次提交
  8. 03 2月, 2016 5 次提交
  9. 30 1月, 2016 1 次提交
  10. 29 1月, 2016 10 次提交
  11. 28 1月, 2016 5 次提交
    • G
      hwmon: (fam15h_power) Add bit masking for tdp_limit · 60dee3ca
      Gioh Kim 提交于
      Add bit masking to read ApmTdpLimit precisely
      Signed-off-by: NGioh Kim <gi-oh.kim@profitbricks.com>
      Acked-by: NBorislav Petkov <bp@suse.de>
      Acked-by: NHuang Rui <ray.huang@amd.com>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      60dee3ca
    • A
      cpufreq: cpufreq-dt: avoid uninitialized variable warnings: · b331bc20
      Arnd Bergmann 提交于
      gcc warns quite a bit about values returned from allocate_resources()
      in cpufreq-dt.c:
      
      cpufreq-dt.c: In function 'cpufreq_init':
      cpufreq-dt.c:327:6: error: 'cpu_dev' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      cpufreq-dt.c:197:17: note: 'cpu_dev' was declared here
      cpufreq-dt.c:376:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      cpufreq-dt.c:199:14: note: 'cpu_clk' was declared here
      cpufreq-dt.c: In function 'dt_cpufreq_probe':
      cpufreq-dt.c:461:2: error: 'cpu_clk' may be used uninitialized in this function [-Werror=maybe-uninitialized]
      cpufreq-dt.c:447:14: note: 'cpu_clk' was declared here
      
      The problem is that it's slightly hard for gcc to follow return
      codes across PTR_ERR() calls.
      
      This patch uses explicit assignments to the "ret" variable to make
      it easier for gcc to verify that the code is actually correct,
      without the need to add a bogus initialization.
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      b331bc20
    • A
      cpufreq: pxa2xx: fix pxa_cpufreq_change_voltage prototype · fb2a24a1
      Arnd Bergmann 提交于
      There are two definitions of pxa_cpufreq_change_voltage, with slightly
      different prototypes after one of them had its argument marked 'const'.
      Now the other one (for !CONFIG_REGULATOR) produces a harmless warning:
      
      drivers/cpufreq/pxa2xx-cpufreq.c: In function 'pxa_set_target':
      drivers/cpufreq/pxa2xx-cpufreq.c:291:36: warning: passing argument 1 of 'pxa_cpufreq_change_voltage' discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
         ret = pxa_cpufreq_change_voltage(&pxa_freq_settings[idx]);
                                          ^
      drivers/cpufreq/pxa2xx-cpufreq.c:205:12: note: expected 'struct pxa_freqs *' but argument is of type 'const struct pxa_freqs *'
       static int pxa_cpufreq_change_voltage(struct pxa_freqs *pxa_freq)
                  ^
      
      This changes the prototype in the same way as the other, which
      avoids the warning.
      
      Fixes: 03c22990 (cpufreq: pxa: make pxa_freqs arrays const)
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Cc: 4.2+ <stable@vger.kernel.org> # 4.2+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      fb2a24a1
    • G
      cpufreq: Use list_is_last() to check last entry of the policy list · 2dadfd75
      Gautham R Shenoy 提交于
      Currently next_policy() explicitly checks if a policy is the last
      policy in the cpufreq_policy_list. Use the standard list_is_last
      primitive instead.
      Signed-off-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2dadfd75
    • V
      cpufreq: Fix NULL reference crash while accessing policy->governor_data · e4b133cc
      Viresh Kumar 提交于
      There is a race discovered by Juri, where we are able to:
      - create and read a sysfs file before policy->governor_data is being set
        to a non NULL value.
        OR
      - set policy->governor_data to NULL, and reading a file before being
        destroyed.
      
      And so such a crash is reported:
      
      Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      pgd = edfc8000
      [0000000c] *pgd=bfc8c835
      Internal error: Oops: 17 [#1] SMP ARM
      Modules linked in:
      CPU: 4 PID: 1730 Comm: cat Not tainted 4.5.0-rc1+ #463
      Hardware name: ARM-Versatile Express
      task: ee8e8480 ti: ee930000 task.ti: ee930000
      PC is at show_ignore_nice_load_gov_pol+0x24/0x34
      LR is at show+0x4c/0x60
      pc : [<c058f1bc>]    lr : [<c058ae88>]    psr: a0070013
      sp : ee931dd0  ip : ee931de0  fp : ee931ddc
      r10: ee4bc290  r9 : 00001000  r8 : ef2cb000
      r7 : ee4bc200  r6 : ef2cb000  r5 : c0af57b0  r4 : ee4bc2e0
      r3 : 00000000  r2 : 00000000  r1 : c0928df4  r0 : ef2cb000
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      Control: 10c5387d  Table: adfc806a  DAC: 00000051
      Process cat (pid: 1730, stack limit = 0xee930210)
      Stack: (0xee931dd0 to 0xee932000)
      1dc0:                                     ee931dfc ee931de0 c058ae88 c058f1a4
      1de0: edce3bc0 c07bfca4 edce3ac0 00001000 ee931e24 ee931e00 c01fcb90 c058ae48
      1e00: 00000001 edce3bc0 00000000 00000001 ee931e50 ee8ff480 ee931e34 ee931e28
      1e20: c01fb33c c01fcb0c ee931e8c ee931e38 c01a5210 c01fb314 ee931e9c ee931e48
      1e40: 00000000 edce3bf0 befe4a00 ee931f78 00000000 00000000 000001e4 00000000
      1e60: c00545a8 edce3ac0 00001000 00001000 befe4a00 ee931f78 00000000 00001000
      1e80: ee931ed4 ee931e90 c01fbed8 c01a5038 ed085a58 00020000 00000000 00000000
      1ea0: c0ad72e4 ee931f78 ee8ff488 ee8ff480 c077f3fc 00001000 befe4a00 ee931f78
      1ec0: 00000000 00001000 ee931f44 ee931ed8 c017c328 c01fbdc4 00001000 00000000
      1ee0: ee8ff480 00001000 ee931f44 ee931ef8 c017c65c c03deb10 ee931fac ee931f08
      1f00: c0009270 c001f290 c0a8d968 ef2cb000 ef2cb000 ee8ff480 00000020 ee8ff480
      1f20: ee8ff480 befe4a00 00001000 ee931f78 00000000 00000000 ee931f74 ee931f48
      1f40: c017d1ec c017c2f8 c019c724 c019c684 ee8ff480 ee8ff480 00001000 befe4a00
      1f60: 00000000 00000000 ee931fa4 ee931f78 c017d2a8 c017d160 00000000 00000000
      1f80: 000a9f20 00001000 befe4a00 00000003 c000ffe4 ee930000 00000000 ee931fa8
      1fa0: c000fe40 c017d264 000a9f20 00001000 00000003 befe4a00 00001000 00000000
      Unable to handle kernel NULL pointer dereference at virtual address 0000000c
      1fc0: 000a9f20 00001000 befe4a00 00000003 00000000 00000000 00000003 00000001
      pgd = edfc4000
      [0000000c] *pgd=bfcac835
      1fe0: 00000000 befe49dc 000197f8 b6e35dfc 60070010 00000003 3065b49d 134ac2c9
      
      [<c058f1bc>] (show_ignore_nice_load_gov_pol) from [<c058ae88>] (show+0x4c/0x60)
      [<c058ae88>] (show) from [<c01fcb90>] (sysfs_kf_seq_show+0x90/0xfc)
      [<c01fcb90>] (sysfs_kf_seq_show) from [<c01fb33c>] (kernfs_seq_show+0x34/0x38)
      [<c01fb33c>] (kernfs_seq_show) from [<c01a5210>] (seq_read+0x1e4/0x4e4)
      [<c01a5210>] (seq_read) from [<c01fbed8>] (kernfs_fop_read+0x120/0x1a0)
      [<c01fbed8>] (kernfs_fop_read) from [<c017c328>] (__vfs_read+0x3c/0xe0)
      [<c017c328>] (__vfs_read) from [<c017d1ec>] (vfs_read+0x98/0x104)
      [<c017d1ec>] (vfs_read) from [<c017d2a8>] (SyS_read+0x50/0x90)
      [<c017d2a8>] (SyS_read) from [<c000fe40>] (ret_fast_syscall+0x0/0x1c)
      Code: e5903044 e1a00001 e3081df4 e34c1092 (e593300c)
      ---[ end trace 5994b9a5111f35ee ]---
      
      Fix that by making sure, policy->governor_data is updated at the right
      places only.
      
      Cc: 4.2+ <stable@vger.kernel.org> # 4.2+
      Reported-and-tested-by: NJuri Lelli <juri.lelli@arm.com>
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e4b133cc