Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync up with Linus #127

Merged
merged 115 commits into from
Oct 23, 2015
Merged

Sync up with Linus #127

merged 115 commits into from
Oct 23, 2015

Conversation

dabrace
Copy link
Owner

@dabrace dabrace commented Oct 23, 2015

No description provided.

Fabio Estevam and others added 30 commits September 30, 2015 09:48
The UART2 memory space starts at address 0x30890000 (UART2_URXD).

Fix it so that UART2 can be used.

Signed-off-by: Fabio Estevam <[email protected]>
Fixes: 9496734 ("ARM: dts: add imx7d soc dtsi file")
Cc: <[email protected]>
Signed-off-by: Shawn Guo <[email protected]>
Currently, BG2Q shares a compatible with BG2. This is incorrect, since
BG2 and BG2Q use different USB PLL dividers. In reality, BG2Q shares a
divider with BG2CD. Change BG2Q's USB PHY compatible string to reflect
that.

Cc: <[email protected]> # v4.2.0-
Signed-off-by: Thomas Hebb <[email protected]>
Signed-off-by: Sebastian Hesselbarth <[email protected]>
DSA expects the host_dev pointer to be the device structure associated
with the MDIO bus controller driver. First commit breaking that was
c3a0713 ("mv643xx_eth: convert to use the Marvell Orion MDIO
driver"), and then, it got completely under the radar for a while.

Reported-by: Frans van de Wiel <[email protected]>
Fixes: c3a0713 ("mv643xx_eth: convert to use the Marvell Orion MDIO driver")
CC: [email protected]
Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Gregory CLEMENT <[email protected]>
… loop

When using idle=poll, the preemptoff tracer is always showing
the idle task as the culprit for long latencies. That happens
because critical timings are not stopped before idle loop. This
patch stops critical timings before entering the idle loop,
starting it again after the idle loop.

This problem does not affect the irqsoff tracer because
interruptions are enabled before entering the idle loop.

Signed-off-by: Daniel Bristot de Oliveira <[email protected]>
Reviewed-by: Luis Claudio R. Goncalves <[email protected]>
Acked-by: Steven Rostedt <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/10fc3705874aef11dbe152a068b591a7be1899b4.1444314899.git.bristot@redhat.com
Signed-off-by: Ingo Molnar <[email protected]>
On each next iteration of for_each_compatible_node() the reference
counter for current device node is already decreased by the loop
iterator. The manual call to of_node_get() is required only on loop
break which is not happening here.

The double of_node_get() (with enabled CONFIG_OF_DYNAMIC) lead to
decreasing the counter below expected, initial value.

Fixes: fe4034a ("ARM: EXYNOS: Add missing of_node_put() when parsing power domains")
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Cc: <[email protected]>
Signed-off-by: Kukjin Kim <[email protected]>
Since commit 2fad972 ("ARM: dts: Add mclk entry for Peach boards"),
sound card detection is broken on peach boards and gives below errors:

[    3.630457] max98090 7-0010: MAX98091 REVID=0x51
[    3.634233] max98090 7-0010: use default 2.8v micbias
[    3.640985] snow-audio sound: HiFi <-> 3830000.i2s mapping ok
[    3.645307] max98090 7-0010: Invalid master clock frequency
[    3.650824] snow-audio sound: ASoC: Peach-Pi-I2S-MAX98091 late_probe() failed: -22
[    3.658914] snow-audio sound: snd_soc_register_card failed (-22)
[    3.664366] snow-audio: probe of sound failed with error -22

This patch adds missing assigned-clocks and assigned-clock-parents for
pmu_system_controller node which is used as "mclk" for audio codec.

Fixes: 2fad972 ("ARM: dts: Add mclk entry for Peach boards")
Signed-off-by: Alim Akhtar <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Cc: <[email protected]>
Signed-off-by: Kukjin Kim <[email protected]>
LDO1 regulator (VDD_SD) is connected to SoC's vddshv8. vddshv8 needs to
be kept always powered (see commit 5a0f93c ("ARM: dts: Add
am57xx-beagle-x15"), but at the moment VDD_SD is enabled/disabled
depending on whether an SD card is inserted or not.

This patch sets LDO1 regulator to always-on.

This patch has a side effect of fixing another issue, HDMI DDC not
working when SD card is not inserted:

Why this happens is that the tpd12s015 (HDMI level shifter/ESD
protection chip) has LS_OE GPIO input, which needs to be enabled for the
HDMI DDC to work. LS_OE comes from gpio6_28. The pin that provides
gpio6_28 is powered by vddshv8, and vddshv8 comes from VDD_SD.

So when SD card is not inserted, VDD_SD is disabled, and LS_OE stays
off.

The proper fix for the HDMI DDC issue would be to maybe have the pinctrl
framework manage the pin specific power.

Apparently this fixes also a third issue (copy paste from Kishon's
patch):

ldo1_reg in addition to being connected to the io lines is also
connected to the card detect line. On card removal, omap_hsmmc
driver does a regulator_disable causing card detect line to be
pulled down. This raises a card insertion interrupt and once the
MMC core detects there is no card inserted, it does a
regulator disable which again raises a card insertion interrupt.
This happens in a loop causing infinite MMC interrupts.

Fixes: 5a0f93c ("ARM: dts: Add am57xx-beagle-x15")
Cc: Kishon Vijay Abraham I <[email protected]>
Signed-off-by: Tomi Valkeinen <[email protected]>
Reported-by: Louis McCarthy <[email protected]>
Acked-by: Nishanth Menon <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Commit 63aa945 ("memory: omap-gpmc: Add Kconfig option for debug")
added a debug option for GPMC, but somehow managed to keep it unselectable.

This probably happened because I had some uncommitted changes and the
GPMC option is selected in the platform specific Kconfig.

Let's also update the description a bit, it does not mention that
enabling the debug option also disables the reset of GPMC controller
during the init as pointed out by Uwe Kleine-König
<[email protected]> and Roger Quadros <[email protected]>.

Fixes: 63aa945 ("memory: omap-gpmc: Add Kconfig option for debug")
Reported-by: Uwe Kleine-König <[email protected]>
Acked-by: Roger Quadros <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
When gpmc_cs_show_timings is called in gpmc_cs_set_timings()
gpmc_cs_program_settings() was already run which modifies the CONFIG1
register. So to be more useful do the "before" dump earlier.

Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Roger Quadros <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>
Earlier the PBIAS regulator was optional, not so with recent
omap_hsmmc changes. To make things easier for people with
custom .config files, let's add minimal documentation for it
as suggested by Russell King <[email protected]>.

Signed-off-by: Tony Lindgren <[email protected]>
Compiling the hdac extended core on arm fails with below error:

  sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_writel':
>> sound/hda/ext/hdac_ext_bus.c:29:2: error: implicit declaration of
>> function
+'writel' [-Werror=implicit-function-declaration]
     writel(value, addr);
     ^
   sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_readl':
>> sound/hda/ext/hdac_ext_bus.c:34:2: error: implicit declaration of
>> function
+'readl' [-Werror=implicit-function-declaration]
     return readl(addr);

This is fixed by explicitly including io.h

Fixes: 99463b3 - ('ALSA: hda: provide default bus io ops extended hdac')
Reported-by: kbuild test robot <[email protected]>
Suggested-by: Mark Brown <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo
mic input where one channel has reverse polarity.

Alsa-info available at:
https://launchpadlibrarian.net/220846272/AlsaInfo.txt

Cc: [email protected]
BugLink: https://bugs.launchpad.net/bugs/1504778
Signed-off-by: David Henningsson <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>
I've botched this in

commit eb0b44a
Author: Daniel Vetter <[email protected]>
Date:   Wed Mar 18 14:47:59 2015 +0100

    drm/i915: kerneldoc for i915_gem_shrinker.c

so let's fix it.

Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
In order to flush the results from in-batch pipecontrol writes (used for
example in glQuery) before declaring the batch complete (and so declaring
the query results coherent), we need to set the FlushEnable bit in our
flushing pipecontrol. The FlushEnable bit "waits until all previous
writes of immediate data from post-sync circles are complete before
executing the next command".

I get GPU hangs on byt without flushing these writes (running ue4).
piglit has examples where the flush is required for correct rendering.

Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Ville Syrjälä <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Cc: [email protected]
Signed-off-by: Jani Nikula <[email protected]>
We accidentally lost the initial DPLL register write in
1c4e027 drm/i915: Fix DVO 2x clock enable on 830M

The "three times for luck" hack probably saved us from a total
disaster. But anyway, bring the initial write back so that the
code actually makes some sense.

Reported-and-tested-by: Nick Bowler <[email protected]>
References: http://mid.gmane.org/CAN_QmVyMaArxYgEcVVsGvsMo7-6ohZr8HmF5VhkkL4i9KOmrhw@mail.gmail.com
Cc: [email protected]
Cc: Nick Bowler <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Apparently writing the DPLL register P1/P2 divider fields won't trigger
an actual change in the DPLL output unless VGA mode is enabled for
prior to the register write that changes the P1/P2 dividers. The write
with the new P1/P2 divider can itself disable VGA mode again without
problems.

I tested the behaviour on my 946GZ, and when manually frobbing the
register with the display on, the behaviour is very clear. However I
can't explain why this machine actually works. The P1/P2 divider
changes caused by normal modesets do seem to make it through to the
hardware somehow since I get a stable picture on the monitor with
any resolution. Maybe it's the "three times for luck" stuff that
somehow masks the problem, or something.

But apparently there are machines (eg. Nick Bowler's G45) where that
isn't the case and we fail to get the correct clock from the DPLL.

Things used to work because we enabled VGA mode for disabled DPLLs,
so when re-enabling the DPLL VGA mode was enabled just prior to the
first register write, and hence the P1/P2 change went through without
a hitch. That got changed in

b8afb91 drm/i915: Keep GMCH DPLL VGA mode always disabled

in the name of consistency. In order to keep the consistency part,
leave VGA mode disabled for disabled DPLLs, but turn it on just prior
to updating the P1/P2 dividers to make sure the hardware picks up
on the new values.

Cc: Nick Bowler <[email protected]>
Reported-by: Nick Bowler <[email protected]>
Tested-by: Nick Bowler <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Reviewed-by: Daniel Vetter <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Pinning a userptr onto the hardware raises interesting questions about
the lifetime of such a surface as the framebuffer extends that life
beyond the client's address space. That is the hardware will need to
keep scanning out from the backing storage even after the client wants
to remap its address space. As the hardware pins the backing storage,
the userptr becomes invalid and this raises a WARN when the clients
tries to unmap its address space. The situation can be even more
complicated when the buffer is passed between processes, between a
client and display server, where the lifetime and hardware access is
even more confusing. Deny it.

Signed-off-by: Chris Wilson <[email protected]>
Cc: Daniel Vetter <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Michał Winiarski <[email protected]>
Cc: [email protected]
Reviewed-by: Tvrtko Ursulin <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
This reverts commit 721a09f.

There is nothing wrong with the commit per se. We had two versions of
the commit, one in -next headed for v4.4 and this one for v4.3. Turns
out we'll need to backport more fixes from -next, and they conflict with
the v4.3 version. It gets messy. It will be easiest to revert this one,
and backport all the relevant commits from -next without modifications;
they apply cleanly after this revert.

Requested-by: Joseph Yasi <[email protected]>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910#c4
Cc: Maarten Lankhorst <[email protected]>
Acked-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
The dotclock is often calculated in encoder .get_config(), so we
shouldn't copy the adjusted_mode to hwmode until we have read out the
dotclock.

Gets rid of some warnings like these:
[drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 21: Can't calculate constants, dotclock = 0!
[drm:i915_get_vblank_timestamp] crtc 0 is disabled

v2: Steal Maarten's idea to move crtc->mode etc. assignment too

Cc: Maarten Lankhorst <[email protected]>
Cc: Patrik Jakobsson <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91428
Reviewed-by: Patrik Jakobsson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Move the sprite/cursor plane disabling to occur in intel_sanitize_crtc()
where it belongs instead of doing it in intel_modeset_readout_hw_state().

The plane disabling was first added in
4cf0ebb drm/i915: Rework plane readout.

I got the idea from some patches from Partik and/or Maarten but those
moved also the plane state readout to intel_sanitize_crtc() which isn't
quite right in my opinion.

Cc: Maarten Lankhorst <[email protected]>
Cc: Patrik Jakobsson <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
References: https://bugs.freedesktop.org/show_bug.cgi?id=91910
Reviewed-by: Patrik Jakobsson <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
This fixes the warnings like

"plane A assertion failure, should be disabled but not"

that on the initial modeset during boot. This can happen if
the primary plane is enabled by the firmware, but inheriting
it fails because the DMAR is active or for other reasons.

Most likely caused by

commit 36750f2
Author: Maarten Lankhorst <[email protected]>
Date:   Mon Jun 1 12:49:54 2015 +0200

    drm/i915: update plane state during init

This is a new version of

commit 721a09f
Author: Maarten Lankhorst <[email protected]>
Date:   Tue Sep 15 14:28:54 2015 +0200

    drm/i915: Add primary plane to mask if it's visible

That was reverted in order to facilitate easier backporting of some
commits from -next to v4.3.

Reported-by: Andreas Reis <[email protected]>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91429
Reported-and-tested-by: Emil Renner Berthing <[email protected]>
Tested-by: Andreas Reis <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
[Jani: cherry-picked from -next to v4.3]
Acked-by: Maarten Lankhorst <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
When multiple GOP devices exists, but none of them implements
ConOut, the code should just choose the first GOP (according to
the comments). But currently 'fb_base' will refer to the last GOP,
while other parameters to the first GOP, which will likely
result in a garbled display.

I can reliably reproduce this bug using my ASRock Z87M Extreme4
motherboard with CSM and integrated GPU disabled, and two PCIe
video cards (NVidia GT640 and GTX980), booting from efi-stub
(booting from grub works fine).  On the primary display the
ASRock logo remains and on the secondary screen it is garbled
up completely.

Signed-off-by: Kővágó, Zoltán <[email protected]>
Signed-off-by: Matt Fleming <[email protected]>
Cc: <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Matthew Garrett <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
…into fixes

Merge "mvebu fixes for 4.3 (part 1)" from Gregory CLEMENT:

DSA fixes for orion platform

* tag 'mvebu-fixes-4.3-1' of git://git.infradead.org/linux-mvebu:
  ARM: orion: Fix DSA platform device after mvmdio conversion
…esselba/linux-berlin into fixes

Merge "Marvell Berlin fixes for v4.3 take 1" from Sebastian Hesselbarth:
- BG2Q USB PHY compatible fix (also tagged for stable v4.2)

* tag 'berlin-fixes-for-4.3-1' of git://git.infradead.org/users/hesselba/linux-berlin:
  ARM: dts: berlin: change BG2Q's USB PHY compatible
…nel/git/shawnguo/linux into fixes

Pull "The i.MX fixes for 4.3, 2nd round:" from Shawn Guo:

It includes a single fix for i.MX7D, which corrects the base address of
UART2 in device tree.

* tag 'imx-fixes-4.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  ARM: dts: imx7d: Fix UART2 base address
Some recently added code to avoid a bug introduced a build error
when CONFIG_PM is disabled and a macro is hidden:

arch/arm/mach-pxa/pxa3xx.c: In function 'pxa3xx_init':
arch/arm/mach-pxa/pxa3xx.c:439:3: error: 'NDCR' undeclared (first use in this function)
   NDCR = (NDCR & ~NDCR_ND_ARB_EN) | NDCR_ND_ARB_CNTL;
   ^

This moves the macro outside of the #ifdef so it can be
referenced correctly.

Signed-off-by: Arnd Bergmann <[email protected]>
Fixes: adf3442 ("ARM: pxa: fix DFI bus lockups on startup")
Acked-by: Robert Jarzmik <[email protected]>
commit 1d8aca9
"ARM: ux500: fix MMC/SD card regression"
fixed broken the level shifter: it should be default ON
but became default OFF.

Fixes: 1d8aca9 "ARM: ux500: fix MMC/SD card regression"
Reported-and-tested-by: Ulf Hansson <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Add Chen-Yu Tsai as a co-maintainer to the ARM sunxi support.

While we are doing so, also update the entry for new SoCs.

Signed-off-by: Maxime Ripard <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
The DTS erronously uses the wrong reg mapping and IRQ numbers for some
UART, WDT and timer nodes. Fix this.

Reported-by: John Wehle <[email protected]>
Signed-off-by: Carlo Caione <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
broonie and others added 22 commits October 23, 2015 08:44
…/fix/wm8904' and 'asoc/fix/wm8962' into asoc-linus
…ernel/git/broonie/sound into for-linus

ASoC: Fixes for v4.3

A bunch of driver fixes plus one core fix which fixes problems with
misreporting values from _SX controls following a recent refactoring.
This had gone unnoticed as such controls are quite rare.
call_usermodehelper_exec_sync() does fork() + wait() with "unignored"
SIGCHLD.  What we have missed is that this worker thread can have other
children previously forked by call_usermodehelper_exec_work() without
UMH_WAIT_PROC.  If such a child exits in between it becomes a zombie
because auto-reaping only works if SIGCHLD is ignored, and nobody can
reap it (unless/until this worker thread exits too).

Change the !UMH_WAIT_PROC case to use CLONE_PARENT.

Note: this is only first step.  All PF_KTHREAD tasks, even created by
kernel_thread() should have ->parent == kthreadd by default.

Fixes: bb304a5 ("kmod: handle UMH_WAIT_PROC from system unbound workqueue")
Signed-off-by: Oleg Nesterov <[email protected]>
Acked-by: Frederic Weisbecker <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Christoph Lameter <[email protected]>
Cc: Tejun Heo <[email protected]>
Cc: Rusty Russell <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
This was found during userspace fuzzing test when a large size dma cma
allocation is made by driver(like ion) through userspace.

  show_stack+0x10/0x1c
  dump_stack+0x74/0xc8
  kasan_report_error+0x2b0/0x408
  kasan_report+0x34/0x40
  __asan_storeN+0x15c/0x168
  memset+0x20/0x44
  __dma_alloc_coherent+0x114/0x18c

Signed-off-by: Rohit Vaswani <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Cc: Marek Szyprowski <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Nominate myself as a zsmalloc reviewer.

Signed-off-by: Sergey Senozhatsky <[email protected]>
Cc: Minchan Kim <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
The get_maintainer script still reports my old Collabora email based on
old commits but that address no longer exist so update mailmap to report
my current email and avoid people sending to the old address.

Signed-off-by: Javier Martinez Canillas <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Use is_zero_pfn() on pteval only after pte_present() check on pteval
(It might be better idea to introduce is_zero_pte() which checks
pte_present() first).

Otherwise when working on a swap or migration entry and if pte_pfn's
result is equal to zero_pfn by chance, we lose user's data in
__collapse_huge_page_copy().  So if you're unlucky, the application
segfaults and finally you could see below message on exit:

BUG: Bad rss-counter state mm:ffff88007f099300 idx:2 val:3

Fixes: ca0984c ("mm: incorporate zero pages into transparent huge pages")
Signed-off-by: Minchan Kim <[email protected]>
Reviewed-by: Andrea Arcangeli <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: Mel Gorman <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Cc: Hugh Dickins <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: <[email protected]>	[4.1+]
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Currently a simple program below issues a sendfile(2) system call which
takes about 62 days to complete in my test KVM instance.

        int fd;
        off_t off = 0;

        fd = open("file", O_RDWR | O_TRUNC | O_SYNC | O_CREAT, 0644);
        ftruncate(fd, 2);
        lseek(fd, 0, SEEK_END);
        sendfile(fd, fd, &off, 0xfffffff);

Now you should not ask kernel to do a stupid stuff like copying 256MB in
2-byte chunks and call fsync(2) after each chunk but if you do, sysadmin
should have a way to stop you.

We actually do have a check for fatal_signal_pending() in
generic_perform_write() which triggers in this path however because we
always succeed in writing something before the check is done, we return
value > 0 from generic_perform_write() and thus the information about
signal gets lost.

Fix the problem by doing the signal check before writing anything.  That
way generic_perform_write() returns -EINTR, the error gets propagated up
and the sendfile loop terminates early.

Signed-off-by: Jan Kara <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
Cc: Al Viro <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
When the kernel compiled with KASAN=y, GCC adds redzones for each
variable on stack.  This enlarges function's stack frame and causes:

	'warning: the frame size of X bytes is larger than Y bytes'

The worst case I've seen for now is following:

   ../net/wireless/nl80211.c: In function `nl80211_send_wiphy':
   ../net/wireless/nl80211.c:1731:1: warning: the frame size of 5448 bytes is larger than 2048 bytes [-Wframe-larger-than=]

That kind of warning becomes useless with KASAN=y.  It doesn't
necessarily indicate that there is some problem in the code, thus we
should turn it off.

(The KASAN=y stack size in increased from 16k to 32k for this reason)

Signed-off-by: Andrey Ryabinin <[email protected]>
Reported-by: Fengguang Wu <[email protected]>
Acked-by: Abylay Ospan <[email protected]>
Cc: Andi Kleen <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Mauro Carvalho Chehab <[email protected]>
Cc: Kozlov Sergey <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
interval displays the probability and vice versa.

Fixes: 6adc4a2 ("fault-inject: add ratelimit option")
Acked-by: Akinobu Mita <[email protected]>
Cc: <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
dlm_lockres_put will call dlm_lockres_release if it is the last
reference, and then it may call dlm_print_one_lock_resource and
take lockres spinlock.

So unlock lockres spinlock before dlm_lockres_put to avoid deadlock.

Signed-off-by: Joseph Qi <[email protected]>
Cc: Mark Fasheh <[email protected]>
Cc: Joel Becker <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
Pull drm fixes from Dave Airlie:
 "I've been a bit slow gathering these:

   - drm/mst: one mutex leak in a fail path

   - radeon: two oops fixes, one dpm fix

   - i915: one messy set of fixes, where we revert the original fix, and
           pull back the proper set of fixes from -next on top.

   - nouveau: one fix for an illegal buffer placement.

  Doesn't look too bad, hopefully shouldn't be too much more"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/nouveau/gem: return only valid domain when there's only one
  drm: fix mutex leak in drm_dp_get_mst_branch_device
  drm/amdgpu: add missing dpm check for KV dpm late init
  drm/amdgpu/dpm: don't add pwm attributes if DPM is disabled
  drm/radeon/dpm: don't add pwm attributes if DPM is disabled
  drm/i915: Add primary plane to mask if it's visible
  drm/i915: Move sprite/cursor plane disable to intel_sanitize_crtc()
  drm/i915: Assign hwmode after encoder state readout
  Revert "drm/i915: Add primary plane to mask if it's visible"
  drm/i915: Deny wrapping an userptr into a framebuffer
  drm/i915: Enable DPLL VGA mode before P1/P2 divider write
  drm/i915: Restore lost DPLL register write on gen2-4
  drm/i915: Flush pipecontrol post-sync writes
  drm/i915: Fix kerneldoc for i915_gem_shrink_all
…/git/mchehab/linux-media

Pull media fixes from Mauro Carvalho Chehab:
 "Some regression fixes and potential security issues:

   - netup_unidvb: fix potential crash when spi is NULL
   - rtl28xxu: fix control message flaws
   - m88ds3103: fix a regression on Kernel 4.2
   - c8sectpfe: fix some issues on this new driver
   - v4l2-flash-led-class: fix a Kbuild dependency
   - si2157 and si2158: check for array boundary when uploading firmware
     files
   - horus3a and lnbh25: fix some building troubles when some options
     aren't selected
   - ir-hix5hd2: drop the use of IRQF_NO_SUSPEND"

* tag 'media/v4.3-4' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media:
  [media] m88ds3103: use own reg update_bits() implementation
  [media] rtl28xxu: fix control message flaws
  [media] v4l2-flash-led-class: Add missing VIDEO_V4L2 Kconfig dependency
  [media] netup_unidvb: fix potential crash when spi is NULL
  [media] si2168: Bounds check firmware
  [media] si2157: Bounds check firmware
  [media] ir-hix5hd2: drop the use of IRQF_NO_SUSPEND
  [media] c8sectpfe: fix return of garbage
  [media] c8sectpfe: fix ininitialized error return on firmware load failure
  [media] lnbh25: Fix lnbh25_attach() function return type
  [media] horus3a: Fix horus3a_attach() function parameters
…l/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "There is nothing to worry you much, only a few small & stable patches
  are found for usual stuff, HD-audio (a Lenovo laptop quirk, a fix for
  minor error handling) and ASoC (trivial fixes for RT298 and WM
  codecs).

  The only remaining major change is the fix for ASoC SX_TLV control
  that was overseen during refactoring, but the fix itself is trivial
  and safe"

* tag 'sound-4.3-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ASoC: wm8962: mark cache_dirty flag after software reset in pm_resume
  ASoC: rt298: fix wrong setting of gpio2_en
  ASoC: wm8904: Correct number of EQ registers
  ALSA: hda - Fix deadlock at error in building PCM
  ASoC: Add info callback for SX_TLV controls
  ASoC: rt298: correct index default value
  ALSA: hda - Fix inverted internal mic on Lenovo G50-80
  ALSA: hdac: Explicitly add io.h
…x/kernel/git/rostedt/linux-trace

Pull tracing fixes from Steven Rostedt:
 "Running tests on other changes, the system locked up due to lots of
  warnings.  It was caused by the stack tracer triggering a warning
  about using rcu_dereference() when RCU was not watching.  This can
  happen due to the fact that the stack tracer uses the function tracer
  to check each function, and there are functions that may be called and
  traced when RCU stopped watching.  Namely when a function is called
  just before going idle or to userspace and after RCU stopped watching
  that current CPU.

  The first patch makes sure that RCU is watching when the stack tracer
  uses RCU.  The second patch is to make sure that the stack tracer does
  not get called by functions in NMI, as it's not NMI safe"

* tag 'trace-fixes-v4.3-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  tracing: Do not allow stack_tracer to record stack in NMI
  tracing: Have stack tracer force RCU to be watching
Pull KVM bugfixes from Paolo Bonzini:
 "Bug fixes for ARM, mostly 4.3 regressions related to virtual interrupt
  controller changes"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  arm/arm64: KVM: Fix disabled distributor operation
  arm/arm64: KVM: Clear map->active on pend/active clear
  arm/arm64: KVM: Fix arch timer behavior for disabled interrupts
  KVM: arm: use GIC support unconditionally
  KVM: arm/arm64: Fix memory leak if timer initialization fails
  KVM: arm/arm64: Do not inject spurious interrupts
…nel/git/arm/arm-soc

Pull ARM SoC fixes from Arnd Bergmann:
 "Most of the changes this time are for incorrect device nodes in
  various ways, on on imx, berlin, exynos, ux500, uniphier, omap and
  meson.

  Chen-Yu Tsai now co-maintains mach-sunxi (Allwinner).

  Other bug fixes include
   - a partial revert of a broken tegra gpio patch
   - irq affinity for arm ccn
   - suspend on one Armada 385 machine
   - enable ZONE_DMA to avoid an OMAP crash for over 2GB RAM
   - turning on a regulator on beagleboard-x15 for HDMI
   - making the omap gpmc debug code visible
   - setup of orion network switch
   - a rare build regression for pxa"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (22 commits)
  ARM: OMAP2+: Fix imprecise external abort caused by bogus SRAM init
  thermal: exynos: Fix register read in TMU
  ARM: OMAP2+: Fix oops with LPAE and more than 2GB of memory
  ARM: tegra: Comment out gpio-ranges properties
  ARM: dts: uniphier: fix IRQ number for devices on PH1-LD6b ref board
  drivers/perf: arm_pmu: avoid CPU device_node reference leak
  bus: arm-ccn: Fix irq affinity setting on CPU migration
  bus: arm-ccn: Handle correctly no-more-cpus case
  ARM: mvebu: correct a385-db-ap compatible string
  ARM: meson6: DTS: Fix wrong reg mapping and IRQ numbers
  MAINTAINERS: Update Allwinner entry and add new maintainer
  ARM: ux500: modify initial levelshifter status
  ARM: pxa: fix pxa3xx DFI lockup hack
  Documentation: ARM: List new omap MMC requirements
  memory: omap-gpmc: dump "before" state before first modification
  memory: omap-gpmc: Fix unselectable debug option for GPMC
  ARM: dts: am57xx-beagle-x15: set VDD_SD to always-on
  ARM: dts: Fix audio card detection on Peach boards
  ARM: EXYNOS: Fix double of_node_put() when parsing child power domains
  ARM: orion: Fix DSA platform device after mvmdio conversion
  ...
…l/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:

 - Revert "Use the POWER8 Micro Partition Prefetch Engine in KVM HV on
   POWER8" from Paul
 - Handle irq_happened flag correctly in off-line loop from Paul
 - Validate rtas.entry before calling enter_rtas() from Vasant

* tag 'powerpc-4.3-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc/rtas: Validate rtas.entry before calling enter_rtas()
  powerpc/powernv: Handle irq_happened flag correctly in off-line loop
  powerpc: Revert "Use the POWER8 Micro Partition Prefetch Engine in KVM HV on POWER8"
Luca and Wanpeng reported two missing annotations that led to
false lockdep complaints. Add the missing annotations.

Reported-by: Luca Abeni <[email protected]>
Reported-by: Wanpeng Li <[email protected]>
Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Cc: Juri Lelli <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Mike Galbraith <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Fixes: cbce1a6 ("sched,lockdep: Employ lock pinning")
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>
Merge fixes from Andrew Morton:
 "9 fixes"

* emailed patches from Andrew Morton <[email protected]>:
  ocfs2/dlm: unlock lockres spinlock before dlm_lockres_put
  fault-inject: fix inverted interval/probability values in printk
  lib/Kconfig.debug: disable -Wframe-larger-than warnings with KASAN=y
  mm: make sendfile(2) killable
  thp: use is_zero_pfn() only after pte_present() check
  mailmap: update Javier Martinez Canillas' email
  MAINTAINERS: add Sergey as zsmalloc reviewer
  mm: cma: fix incorrect type conversion for size during dma allocation
  kmod: don't run async usermode helper as a child of kworker thread
…/linux/kernel/git/tip/tip

Pull scheduler fixes from Ingo Molnar:
 "Misc fixes all around the map: an instrumentation fix, a nohz
  usability fix, a lockdep annotation fix and two task group scheduling
  fixes"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/core: Add missing lockdep_unpin() annotations
  sched/deadline: Fix migration of SCHED_DEADLINE tasks
  nohz: Revert "nohz: Set isolcpus when nohz_full is set"
  sched/fair: Update task group's load_avg after task migration
  sched/fair: Fix overly small weight for interactive group entities
  sched, tracing: Stop/start critical timings around the idle=poll idle loop
…inux/kernel/git/tip/tip

Pull x86 fixes from Ingo Molnar:
 "Misc fixes: two KASAN fixes, two EFI boot fixes, two boot-delay
  optimization fixes, and a fix for a IRQ handling hang observed on
  virtual platforms"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/mm, kasan: Silence KASAN warnings in get_wchan()
  compiler, atomics, kasan: Provide READ_ONCE_NOCHECK()
  x86, kasan: Fix build failure on KASAN=y && KMEMCHECK=y kernels
  x86/smpboot: Fix CPU #1 boot timeout
  x86/smpboot: Fix cpu_init_udelay=10000 corner case boot parameter misbehavior
  x86/ioapic: Disable interrupts when re-routing legacy IRQs
  x86/setup: Extend low identity map to cover whole kernel range
  x86/efi: Fix multiple GOP device support
dabrace added a commit that referenced this pull request Oct 23, 2015
@dabrace dabrace merged commit c8b19fc into dabrace:master Oct 23, 2015
dabrace pushed a commit that referenced this pull request Jul 25, 2016
Lockdep complains about potential recursive locking during mount
because the client configuration log is holding a lock on the MGC
obd_device to prevent it from being torn down, while also getting
mutexes on the MDC and OSC devices as they are instantiated:

 Lustre: Mounted myth-client
=============================================
[ INFO: possible recursive locking detected ]
4.7.0-rc2-vm-nfs+ #127 Tainted: G         C
---------------------------------------------

 May be due to missing lock nesting notation
2 locks held by ll_cfg_requeue/5928:
 #0:  (&cli->cl_sem){.+.+.+}, at: mgc_requeue_thread+0x15d/0x730 [mgc]
 #1:  (&cld->cld_lock){+.+.+.}, at: mgc_process_log+0x5e/0xf80 [mgc]
CPU: 0 PID: 5928 Comm: ll_cfg_requeue
Call Trace:
 [<ffffffff814a0855>] dump_stack+0x86/0xc1
 [<ffffffff810e7766>] __lock_acquire+0x726/0x1210
 [<ffffffff810e86be>] lock_acquire+0xfe/0x1f0
 [<ffffffff81888171>] down_read+0x51/0xa0
 [<ffffffffa04a8477>] sptlrpc_conf_client_adapt+0x47/0x150 [ptlrpc]
 [<ffffffffa0186b16>] mdc_set_info_async+0x2b6/0x470 [mdc]
 [<ffffffffa0294090>] class_notify_sptlrpc_conf+0x190/0x360 [obdclass]
 [<ffffffffa01a9e85>] mgc_process_log+0x925/0xf80 [mgc]
 [<ffffffffa01abafa>] mgc_requeue_thread+0x1fa/0x730 [mgc]
 [<ffffffff810af331>] kthread+0x101/0x120
 [<ffffffff8188ad6f>] ret_from_fork+0x1f/0x40

Add a separate lock class for the MGC callpath, since it will always
be held first, and none of the other obd_device locks should ever
be held concurrently.

Signed-off-by: Andreas Dilger <[email protected]>
Signed-off-by: Oleg Drokin <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
dabrace pushed a commit that referenced this pull request Mar 15, 2017
Dmitry reported crashes in DCCP stack [1]

Problem here is that when I got rid of listener spinlock, I missed the
fact that DCCP stores a complex state in struct dccp_request_sock,
while TCP does not.

Since multiple cpus could access it at the same time, we need to add
protection.

[1]
BUG: KASAN: use-after-free in dccp_feat_activate_values+0x967/0xab0
net/dccp/feat.c:1541 at addr ffff88003713be68
Read of size 8 by task syz-executor2/8457
CPU: 2 PID: 8457 Comm: syz-executor2 Not tainted 4.10.0-rc7+ #127
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 <IRQ>
 __dump_stack lib/dump_stack.c:15 [inline]
 dump_stack+0x292/0x398 lib/dump_stack.c:51
 kasan_object_err+0x1c/0x70 mm/kasan/report.c:162
 print_address_description mm/kasan/report.c:200 [inline]
 kasan_report_error mm/kasan/report.c:289 [inline]
 kasan_report.part.1+0x20e/0x4e0 mm/kasan/report.c:311
 kasan_report mm/kasan/report.c:332 [inline]
 __asan_report_load8_noabort+0x29/0x30 mm/kasan/report.c:332
 dccp_feat_activate_values+0x967/0xab0 net/dccp/feat.c:1541
 dccp_create_openreq_child+0x464/0x610 net/dccp/minisocks.c:121
 dccp_v6_request_recv_sock+0x1f6/0x1960 net/dccp/ipv6.c:457
 dccp_check_req+0x335/0x5a0 net/dccp/minisocks.c:186
 dccp_v6_rcv+0x69e/0x1d00 net/dccp/ipv6.c:711
 ip6_input_finish+0x46d/0x17a0 net/ipv6/ip6_input.c:279
 NF_HOOK include/linux/netfilter.h:257 [inline]
 ip6_input+0xdb/0x590 net/ipv6/ip6_input.c:322
 dst_input include/net/dst.h:507 [inline]
 ip6_rcv_finish+0x289/0x890 net/ipv6/ip6_input.c:69
 NF_HOOK include/linux/netfilter.h:257 [inline]
 ipv6_rcv+0x12ec/0x23d0 net/ipv6/ip6_input.c:203
 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190
 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228
 process_backlog+0xe5/0x6c0 net/core/dev.c:4839
 napi_poll net/core/dev.c:5202 [inline]
 net_rx_action+0xe70/0x1900 net/core/dev.c:5267
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902
 </IRQ>
 do_softirq.part.17+0x1e8/0x230 kernel/softirq.c:328
 do_softirq kernel/softirq.c:176 [inline]
 __local_bh_enable_ip+0x1f2/0x200 kernel/softirq.c:181
 local_bh_enable include/linux/bottom_half.h:31 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:971 [inline]
 ip6_finish_output2+0xbb0/0x23d0 net/ipv6/ip6_output.c:123
 ip6_finish_output+0x302/0x960 net/ipv6/ip6_output.c:148
 NF_HOOK_COND include/linux/netfilter.h:246 [inline]
 ip6_output+0x1cb/0x8d0 net/ipv6/ip6_output.c:162
 ip6_xmit+0xcdf/0x20d0 include/net/dst.h:501
 inet6_csk_xmit+0x320/0x5f0 net/ipv6/inet6_connection_sock.c:179
 dccp_transmit_skb+0xb09/0x1120 net/dccp/output.c:141
 dccp_xmit_packet+0x215/0x760 net/dccp/output.c:280
 dccp_write_xmit+0x168/0x1d0 net/dccp/output.c:362
 dccp_sendmsg+0x79c/0xb10 net/dccp/proto.c:796
 inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
 sock_sendmsg_nosec net/socket.c:635 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:645
 SYSC_sendto+0x660/0x810 net/socket.c:1687
 SyS_sendto+0x40/0x50 net/socket.c:1655
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458b9
RSP: 002b:00007f8ceb77bb58 EFLAGS: 00000282 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000017 RCX: 00000000004458b9
RDX: 0000000000000023 RSI: 0000000020e60000 RDI: 0000000000000017
RBP: 00000000006e1b90 R08: 00000000200f9fe1 R09: 0000000000000020
R10: 0000000000008010 R11: 0000000000000282 R12: 00000000007080a8
R13: 0000000000000000 R14: 00007f8ceb77c9c0 R15: 00007f8ceb77c700
Object at ffff88003713be50, in cache kmalloc-64 size: 64
Allocated:
PID = 8446
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
 save_stack+0x43/0xd0 mm/kasan/kasan.c:502
 set_track mm/kasan/kasan.c:514 [inline]
 kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:605
 kmem_cache_alloc_trace+0x82/0x270 mm/slub.c:2738
 kmalloc include/linux/slab.h:490 [inline]
 dccp_feat_entry_new+0x214/0x410 net/dccp/feat.c:467
 dccp_feat_push_change+0x38/0x220 net/dccp/feat.c:487
 __feat_register_sp+0x223/0x2f0 net/dccp/feat.c:741
 dccp_feat_propagate_ccid+0x22b/0x2b0 net/dccp/feat.c:949
 dccp_feat_server_ccid_dependencies+0x1b3/0x250 net/dccp/feat.c:1012
 dccp_make_response+0x1f1/0xc90 net/dccp/output.c:423
 dccp_v6_send_response+0x4ec/0xc20 net/dccp/ipv6.c:217
 dccp_v6_conn_request+0xaba/0x11b0 net/dccp/ipv6.c:377
 dccp_rcv_state_process+0x51e/0x1650 net/dccp/input.c:606
 dccp_v6_do_rcv+0x213/0x350 net/dccp/ipv6.c:632
 sk_backlog_rcv include/net/sock.h:893 [inline]
 __sk_receive_skb+0x36f/0xcc0 net/core/sock.c:479
 dccp_v6_rcv+0xba5/0x1d00 net/dccp/ipv6.c:742
 ip6_input_finish+0x46d/0x17a0 net/ipv6/ip6_input.c:279
 NF_HOOK include/linux/netfilter.h:257 [inline]
 ip6_input+0xdb/0x590 net/ipv6/ip6_input.c:322
 dst_input include/net/dst.h:507 [inline]
 ip6_rcv_finish+0x289/0x890 net/ipv6/ip6_input.c:69
 NF_HOOK include/linux/netfilter.h:257 [inline]
 ipv6_rcv+0x12ec/0x23d0 net/ipv6/ip6_input.c:203
 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190
 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228
 process_backlog+0xe5/0x6c0 net/core/dev.c:4839
 napi_poll net/core/dev.c:5202 [inline]
 net_rx_action+0xe70/0x1900 net/core/dev.c:5267
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
Freed:
PID = 15
 save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
 save_stack+0x43/0xd0 mm/kasan/kasan.c:502
 set_track mm/kasan/kasan.c:514 [inline]
 kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
 slab_free_hook mm/slub.c:1355 [inline]
 slab_free_freelist_hook mm/slub.c:1377 [inline]
 slab_free mm/slub.c:2954 [inline]
 kfree+0xe8/0x2b0 mm/slub.c:3874
 dccp_feat_entry_destructor.part.4+0x48/0x60 net/dccp/feat.c:418
 dccp_feat_entry_destructor net/dccp/feat.c:416 [inline]
 dccp_feat_list_pop net/dccp/feat.c:541 [inline]
 dccp_feat_activate_values+0x57f/0xab0 net/dccp/feat.c:1543
 dccp_create_openreq_child+0x464/0x610 net/dccp/minisocks.c:121
 dccp_v6_request_recv_sock+0x1f6/0x1960 net/dccp/ipv6.c:457
 dccp_check_req+0x335/0x5a0 net/dccp/minisocks.c:186
 dccp_v6_rcv+0x69e/0x1d00 net/dccp/ipv6.c:711
 ip6_input_finish+0x46d/0x17a0 net/ipv6/ip6_input.c:279
 NF_HOOK include/linux/netfilter.h:257 [inline]
 ip6_input+0xdb/0x590 net/ipv6/ip6_input.c:322
 dst_input include/net/dst.h:507 [inline]
 ip6_rcv_finish+0x289/0x890 net/ipv6/ip6_input.c:69
 NF_HOOK include/linux/netfilter.h:257 [inline]
 ipv6_rcv+0x12ec/0x23d0 net/ipv6/ip6_input.c:203
 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190
 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228
 process_backlog+0xe5/0x6c0 net/core/dev.c:4839
 napi_poll net/core/dev.c:5202 [inline]
 net_rx_action+0xe70/0x1900 net/core/dev.c:5267
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
Memory state around the buggy address:
 ffff88003713bd00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff88003713bd80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88003713be00: fc fc fc fc fc fc fc fc fc fc fb fb fb fb fb fb
                                                          ^

Fixes: 079096f ("tcp/dccp: install syn_recv requests into ehash table")
Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
Tested-by: Dmitry Vyukov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
dabrace pushed a commit that referenced this pull request Apr 3, 2017
Yang Li has reported that drain_all_pages triggers a WARN_ON which means
that this function is called earlier than the mm_percpu_wq is
initialized on arm64 with CMA configured:

  WARNING: CPU: 2 PID: 1 at mm/page_alloc.c:2423 drain_all_pages+0x244/0x25c
  Modules linked in:
  CPU: 2 PID: 1 Comm: swapper/0 Not tainted 4.11.0-rc1-next-20170310-00027-g64dfbc5 #127
  Hardware name: Freescale Layerscape 2088A RDB Board (DT)
  task: ffffffc07c4a6d00 task.stack: ffffffc07c4a8000
  PC is at drain_all_pages+0x244/0x25c
  LR is at start_isolate_page_range+0x14c/0x1f0
  [...]
   drain_all_pages+0x244/0x25c
   start_isolate_page_range+0x14c/0x1f0
   alloc_contig_range+0xec/0x354
   cma_alloc+0x100/0x1fc
   dma_alloc_from_contiguous+0x3c/0x44
   atomic_pool_init+0x7c/0x208
   arm64_dma_init+0x44/0x4c
   do_one_initcall+0x38/0x128
   kernel_init_freeable+0x1a0/0x240
   kernel_init+0x10/0xfc
   ret_from_fork+0x10/0x20

Fix this by moving the whole setup_vmstat which is an initcall right now
to init_mm_internals which will be called right after the WQ subsystem
is initialized.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Michal Hocko <[email protected]>
Reported-by: Yang Li <[email protected]>
Tested-by: Yang Li <[email protected]>
Tested-by: Xiaolong Ye <[email protected]>
Cc: Mel Gorman <[email protected]>
Cc: Vlastimil Babka <[email protected]>
Cc: Tetsuo Handa <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
dabrace pushed a commit that referenced this pull request Oct 23, 2017
When syzkaller team brought us a C repro for the crash [1] that
had been reported many times in the past, I finally could find
the root cause.

If FlowLabel info is merged by fl6_merge_options(), we leave
part of the opt_space storage provided by udp/raw/l2tp with random value
in opt_space.tot_len, unless a control message was provided at sendmsg()
time.

Then ip6_setup_cork() would use this random value to perform a kzalloc()
call. Undefined behavior and crashes.

Fix is to properly set tot_len in fl6_merge_options()

At the same time, we can also avoid consuming memory and cpu cycles
to clear it, if every option is copied via a kmemdup(). This is the
change in ip6_setup_cork().

[1]
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 6613 Comm: syz-executor0 Not tainted 4.14.0-rc4+ #127
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
task: ffff8801cb64a100 task.stack: ffff8801cc350000
RIP: 0010:ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168
RSP: 0018:ffff8801cc357550 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: ffff8801cc357748 RCX: 0000000000000010
RDX: 0000000000000002 RSI: ffffffff842bd1d9 RDI: 0000000000000014
RBP: ffff8801cc357620 R08: ffff8801cb17f380 R09: ffff8801cc357b10
R10: ffff8801cb64a100 R11: 0000000000000000 R12: ffff8801cc357ab0
R13: ffff8801cc357b10 R14: 0000000000000000 R15: ffff8801c3bbf0c0
FS:  00007f9c5c459700(0000) GS:ffff8801db200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020324000 CR3: 00000001d1cf2000 CR4: 00000000001406f0
DR0: 0000000020001010 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000600
Call Trace:
 ip6_make_skb+0x282/0x530 net/ipv6/ip6_output.c:1729
 udpv6_sendmsg+0x2769/0x3380 net/ipv6/udp.c:1340
 inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
 sock_sendmsg_nosec net/socket.c:633 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:643
 SYSC_sendto+0x358/0x5a0 net/socket.c:1750
 SyS_sendto+0x40/0x50 net/socket.c:1718
 entry_SYSCALL_64_fastpath+0x1f/0xbe
RIP: 0033:0x4520a9
RSP: 002b:00007f9c5c458c08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000718000 RCX: 00000000004520a9
RDX: 0000000000000001 RSI: 0000000020fd1000 RDI: 0000000000000016
RBP: 0000000000000086 R08: 0000000020e0afe4 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000216 R12: 00000000004bb1ee
R13: 00000000ffffffff R14: 0000000000000016 R15: 0000000000000029
Code: e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 ea 0f 00 00 48 8d 79 04 48 b8 00 00 00 00 00 fc ff df 45 8b 74 24 04 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85
RIP: ip6_setup_cork+0x274/0x15c0 net/ipv6/ip6_output.c:1168 RSP: ffff8801cc357550

Signed-off-by: Eric Dumazet <[email protected]>
Reported-by: Dmitry Vyukov <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
dabrace pushed a commit that referenced this pull request Nov 9, 2017
…ully

The 0day bot reports the below failure which happens occasionally, with
their randconfig testing (once every ~100 boots).  The Code points at
the private pointer ->driver_data being NULL, which hints at a race of
sorts where the private driver_data descriptor has disappeared by the
time we get to run the workqueue.

So let's check that pointer before we continue with issuing the command
to the drive.

This fix is of the brown paper bag nature but considering that IDE is
long deprecated, let's do that so that random testing which happens to
enable CONFIG_IDE during randconfig builds, doesn't fail because of
this.

Besides, failing the TEST_UNIT_READY command because the drive private
data is gone is something which we could simply do anyway, to denote
that there was a problem communicating with the device.

  BUG: unable to handle kernel NULL pointer dereference at 000001c0
  IP: cdrom_check_status
  *pde = 00000000
  Oops: 0000 [#1] SMP
  CPU: 1 PID: 155 Comm: kworker/1:2 Not tainted 4.14.0-rc8 #127
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1 04/01/2014
  Workqueue: events_freezable_power_ disk_events_workfn
  task: 4fe90980 task.stack: 507ac000
  EIP: cdrom_check_status+0x2c/0x90
  EFLAGS: 00210246 CPU: 1
  EAX: 00000000 EBX: 4fefec00 ECX: 00000000 EDX: 00000000
  ESI: 00000003 EDI: ffffffff EBP: 467a9340 ESP: 507aded0
   DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
  CR0: 80050033 CR2: 000001c0 CR3: 06e0f000 CR4: 00000690
  Call Trace:
   ? ide_cdrom_check_events_real
   ? cdrom_check_events
   ? disk_check_events
   ? process_one_work
   ? process_one_work
   ? worker_thread
   ? kthread
   ? process_one_work
   ? __kthread_create_on_node
   ? ret_from_fork
  Code: 53 83 ec 14 89 c3 89 d1 be 03 00 00 00 65 a1 14 00 00 00 89 44 24 10 31 c0 8b 43 18 c7 44 24 04 00 00 00 00 c7 04 24 00 00 00 00 <8a> 80 c0 01 00 00 c7 44 24 08 00 00 00 00 83 e0 03 c7 44 24 0c
  EIP: cdrom_check_status+0x2c/0x90 SS:ESP: 0068:507aded0
  CR2: 00000000000001c0
  ---[ end trace 2410e586dd8f88b2 ]---

Reported-and-tested-by: Fengguang Wu <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Cc: "David S. Miller" <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Bart Van Assche <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
dabrace pushed a commit that referenced this pull request Mar 20, 2018
This is to fix warning got as:

[ 6730.476938] ------------[ cut here ]------------
[ 6730.476979] Bad or missing usercopy whitelist? Kernel memory exposure attempt detected from SLAB object 'gvt-g_vgpu_workload' (offset 120, size 4)!
[ 6730.477021] WARNING: CPU: 2 PID: 441 at mm/usercopy.c:81 usercopy_warn+0x7e/0xa0
[ 6730.477042] Modules linked in: tun(E) bridge(E) stp(E) llc(E) kvmgt(E) x86_pkg_temp_thermal(E) vfio_mdev(E) intel_powerclamp(E) mdev(E) coretemp(E) vfio_iommu_type1(E) vfio(E) kvm_intel(E) kvm(E) hid_generic(E) irqbypass(E) crct10dif_pclmul(E) crc32_pclmul(E) usbhid(E) i915(E) crc32c_intel(E) hid(E) ghash_clmulni_intel(E) pcbc(E) aesni_intel(E) aes_x86_64(E) crypto_simd(E) cryptd(E) glue_helper(E) intel_cstate(E) idma64(E) evdev(E) virt_dma(E) iTCO_wdt(E) intel_uncore(E) intel_rapl_perf(E) intel_lpss_pci(E) sg(E) shpchp(E) mei_me(E) pcspkr(E) iTCO_vendor_support(E) intel_lpss(E) intel_pch_thermal(E) prime_numbers(E) mei(E) mfd_core(E) video(E) acpi_pad(E) button(E) binfmt_misc(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) fscrypto(E) sd_mod(E) e1000e(E) xhci_pci(E) sdhci_pci(E)
[ 6730.477244]  ptp(E) cqhci(E) xhci_hcd(E) pps_core(E) sdhci(E) mmc_core(E) i2c_i801(E) usbcore(E) thermal(E) fan(E)
[ 6730.477276] CPU: 2 PID: 441 Comm: gvt workload 0 Tainted: G            E    4.16.0-rc1-gvt-staging-0213+ #127
[ 6730.477303] Hardware name:  /NUC6i5SYB, BIOS SYSKLi35.86A.0039.2016.0316.1747 03/16/2016
[ 6730.477326] RIP: 0010:usercopy_warn+0x7e/0xa0
[ 6730.477340] RSP: 0018:ffffba6301223d18 EFLAGS: 00010286
[ 6730.477355] RAX: 0000000000000000 RBX: ffff8f41caae9838 RCX: 0000000000000006
[ 6730.477375] RDX: 0000000000000007 RSI: 0000000000000082 RDI: ffff8f41dad166f0
[ 6730.477395] RBP: 0000000000000004 R08: 0000000000000576 R09: 0000000000000000
[ 6730.477415] R10: ffffffffb1293fb2 R11: 00000000ffffffff R12: 0000000000000001
[ 6730.477447] R13: ffff8f41caae983c R14: ffff8f41caae9838 R15: 00007f183ca2b000
[ 6730.477467] FS:  0000000000000000(0000) GS:ffff8f41dad00000(0000) knlGS:0000000000000000
[ 6730.477489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6730.477506] CR2: 0000559462817291 CR3: 000000028b46c006 CR4: 00000000003626e0
[ 6730.477526] Call Trace:
[ 6730.477537]  __check_object_size+0x9c/0x1a0
[ 6730.477562]  __kvm_write_guest_page+0x45/0x90 [kvm]
[ 6730.477585]  kvm_write_guest+0x46/0x80 [kvm]
[ 6730.477599]  kvmgt_rw_gpa+0x9b/0xf0 [kvmgt]
[ 6730.477642]  workload_thread+0xa38/0x1040 [i915]
[ 6730.477659]  ? do_wait_intr_irq+0xc0/0xc0
[ 6730.477673]  ? finish_wait+0x80/0x80
[ 6730.477707]  ? clean_workloads+0x120/0x120 [i915]
[ 6730.477722]  kthread+0x111/0x130
[ 6730.477733]  ? _kthread_create_worker_on_cpu+0x60/0x60
[ 6730.477750]  ? exit_to_usermode_loop+0x6f/0xb0
[ 6730.477766]  ret_from_fork+0x35/0x40
[ 6730.477777] Code: 48 c7 c0 20 e3 25 b1 48 0f 44 c2 41 50 51 41 51 48 89 f9 49 89 f1 4d 89 d8 4c 89 d2 48 89 c6 48 c7 c7 78 e3 25 b1 e8 b2 bc e4 ff <0f> ff 48 83 c4 18 c3 48 c7 c6 09 d0 26 b1 49 89 f1 49 89 f3 eb
[ 6730.477849] ---[ end trace cae869c1c323e45a ]---

By whitelist guest page write from workload struct allocated from kmem cache.

Reviewed-by: Hang Yuan <[email protected]>
Signed-off-by: Zhenyu Wang <[email protected]>
(cherry picked from commit 5627705)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.