Skip to content
  1. Jun 27, 2016
    • Rafael J. Wysocki's avatar
      intel_pstate: Do not clear utilization update hooks on policy changes · 5ab666e0
      Rafael J. Wysocki authored 
      

intel_pstate_set_policy() is invoked by the cpufreq core during
driver initialization, on changes of policy attributes (minimim and
maximum frequency, for example) via sysfs and via CPU notifications
from the platform firmware.  On some platforms the latter may occur
relatively often.

Commit bb6ab52f (intel_pstate: Do not set utilization update hook
too early) made intel_pstate_set_policy() clear the CPU's utilization
update hook before updating the policy attributes for it (and set the
hook again after doind that), but that involves invoking
synchronize_sched() and adds overhead to the CPU notifications
mentioned above and to the sched-RCU handling in general.

That extra overhead is arguably not necessary, because updating
policy attributes when the CPU's utilization update hook is active
should not lead to any adverse effects, so drop the clearing of
the hook from intel_pstate_set_policy() and make it check if
the hook has been set already when attempting to set it.

Fixes: bb6ab52f (intel_pstate: Do not set utilization update hook too early)
Reported-by: default avatarJisheng Zhang <jszhang@marvell.com>
Tested-by: default avatarJisheng Zhang <jszhang@marvell.com>
Tested-by: default avatarDoug Smythies <dsmythies@telus.net>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      5ab666e0
  3. Jun 25, 2016
    • Michal Hocko's avatar
      tree wide: get rid of __GFP_REPEAT for order-0 allocations part I · 32d6bd90
      Michal Hocko authored 
      This is the third version of the patchset previously sent [1].  I have
basically only rebased it on top of 4.7-rc1 tree and dropped "dm: get
rid of superfluous gfp flags" which went through dm tree.  I am sending
it now because it is tree wide and chances for conflicts are reduced
considerably when we want to target rc2.  I plan to send the next step
and rename the flag and move to a better semantic later during this
release cycle so we will have a new semantic ready for 4.8 merge window
hopefully.

Motivation:

While working on something unrelated I've checked the current usage of
__GFP_REPEAT in the tree.  It seems that a majority of the usage is and
always has been bogus because __GFP_REPEAT has always been about costly
high order allocations while we are using it for order-0 or very small
orders very often.  It seems that a big pile of them is just a
copy&paste when a code has been adopted from one arch to another.

I think it makes some sense to get rid of them because they are just
making the semantic more unclear.  Please note that GFP_REPEAT is
documented as

* __GFP_REPEAT: Try hard to allocate the memory, but the allocation attempt

* _might_ fail.  This depends upon the particular VM implementation.
  while !costly requests have basically nofail semantic.  So one could
  reasonably expect that order-0 request with __GFP_REPEAT will not loop
  for ever.  This is not implemented right now though.

I would like to move on with __GFP_REPEAT and define a better semantic
for it.

  $ git grep __GFP_REPEAT origin/master | wc -l
  111
  $ git grep __GFP_REPEAT | wc -l
  36

So we are down to the third after this patch series.  The remaining
places really seem to be relying on __GFP_REPEAT due to large allocation
requests.  This still needs some double checking which I will do later
after all the simple ones are sorted out.

I am touching a lot of arch specific code here and I hope I got it right
but as a matter of fact I even didn't compile test for some archs as I
do not have cross compiler for them.  Patches should be quite trivial to
review for stupid compile mistakes though.  The tricky parts are usually
hidden by macro definitions and thats where I would appreciate help from
arch maintainers.

[1] http://lkml.kernel.org/r/1461849846-27209-1-git-send-email-mhocko@kernel.org

This patch (of 19):

__GFP_REPEAT has a rather weak semantic but since it has been introduced
around 2.6.12 it has been ignored for low order allocations.  Yet we
have the full kernel tree with its usage for apparently order-0
allocations.  This is really confusing because __GFP_REPEAT is
explicitly documented to allow allocation failures which is a weaker
semantic than the current order-0 has (basically nofail).

Let's simply drop __GFP_REPEAT from those places.  This would allow to
identify place which really need allocator to retry harder and formulate
a more specific semantic for what the flag is supposed to do actually.

Link: http://lkml.kernel.org/r/1464599699-30131-2-git-send-email-mhocko@kernel.org


Signed-off-by: default avatarMichal Hocko <mhocko@suse.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: "Theodore Ts'o" <tytso@mit.edu>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Chen Liqin <liqin.linux@gmail.com>
Cc: Chris Metcalf <cmetcalf@mellanox.com> [for tile]
Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Helge Deller <deller@gmx.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Cc: John Crispin <blogic@openwrt.org>
Cc: Lennox Wu <lennox.wu@gmail.com>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Rich Felker <dalias@libc.org>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vineet Gupta <vgupta@synopsys.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      32d6bd90
  5. Jun 24, 2016
    • Jan Beulich's avatar
      xen-pciback: return proper values during BAR sizing · d2bd05d8
      Jan Beulich authored 
      

Reads following writes with all address bits set to 1 should return all
changeable address bits as one, not the BAR size (nor, as was the case
for the upper half of 64-bit BARs, the high half of the region's end
address). Presumably this didn't cause any problems so far because
consumers use the value to calculate the size (usually via val & -val),
and do nothing else with it.

But also consider the exception here: Unimplemented BARs should always
return all zeroes.

And finally, the check for whether to return the sizing address on read
for the ROM BAR should ignore all non-address bits, not just the ROM
Enable one.

Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      d2bd05d8
    • Scott Bauer's avatar
      HID: hiddev: validate num_values for HIDIOCGUSAGES, HIDIOCSUSAGES commands · 93a2001b
      Scott Bauer authored 
      

This patch validates the num_values parameter from userland during the
HIDIOCGUSAGES and HIDIOCSUSAGES commands. Previously, if the report id was set
to HID_REPORT_ID_UNKNOWN, we would fail to validate the num_values parameter
leading to a heap overflow.

Cc: stable@vger.kernel.org
Signed-off-by: default avatarScott Bauer <sbauer@plzdonthack.me>
Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      93a2001b
    • Maarten Lankhorst's avatar
      drm/atomic: Make drm_atomic_legacy_backoff reset crtc->acquire_ctx · 81e257e9
      Maarten Lankhorst authored 
      

Atomic updates may acquire more state than initially locked through
drm_modeset_lock_crtc, running with heavy stress can cause a
WARN_ON(crtc->acquire_ctx) in drm_modeset_lock_crtc:

[  601.491296] ------------[ cut here ]------------
[  601.491366] WARNING: CPU: 0 PID: 2411 at
drivers/gpu/drm/drm_modeset_lock.c:191 drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[  601.491369] Modules linked in: drm i915 drm_kms_helper
[  601.491414] CPU: 0 PID: 2411 Comm: kms_cursor_lega Tainted: G     U 4.7.0-rc4-patser+ #4798
[  601.491417] Hardware name: Intel Corporation Skylake Client
[  601.491420]  0000000000000000 ffff88044d153c98 ffffffff812ead28 0000000000000000
[  601.491425]  0000000000000000 ffff88044d153cd8 ffffffff810868e6 000000bf58058030
[  601.491431]  ffff880088b415e8 ffff880458058030 ffff88008a271548 ffff88008a271568
[  601.491436] Call Trace:
[  601.491443]  [<ffffffff812ead28>] dump_stack+0x4d/0x65
[  601.491447]  [<ffffffff810868e6>] __warn+0xc6/0xe0
[  601.491452]  [<ffffffff81086968>] warn_slowpath_null+0x18/0x20
[  601.491472]  [<ffffffffc00d4ffb>] drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[  601.491491]  [<ffffffffc00c5526>] drm_mode_cursor_common+0x66/0x180 [drm]
[  601.491509]  [<ffffffffc00c91cc>] drm_mode_cursor_ioctl+0x3c/0x40 [drm]
[  601.491524]  [<ffffffffc00bc94d>] drm_ioctl+0x14d/0x530 [drm]
[  601.491540]  [<ffffffffc00c9190>] ? drm_mode_setcrtc+0x520/0x520 [drm]
[  601.491545]  [<ffffffff81176aeb>] ? handle_mm_fault+0x106b/0x1430
[  601.491550]  [<ffffffff81108441>] ? stop_one_cpu+0x61/0x70
[  601.491556]  [<ffffffff811bb71d>] do_vfs_ioctl+0x8d/0x570
[  601.491560]  [<ffffffff81290d7e>] ? security_file_ioctl+0x3e/0x60
[  601.491565]  [<ffffffff811bbc74>] SyS_ioctl+0x74/0x80
[  601.491571]  [<ffffffff810e321c>] ? posix_get_monotonic_raw+0xc/0x10
[  601.491576]  [<ffffffff8175b11b>] entry_SYSCALL_64_fastpath+0x13/0x8f
[  601.491581] ---[ end trace 56f3d3d85f000d00 ]---

For good measure, test mode_config.acquire_ctx too, although this should
never happen.

Testcase: kms_cursor_legacy
Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      81e257e9
  7. Jun 23, 2016
  9. Jun 22, 2016