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

Replace old README with shiny new Markdown-based README #162

Closed
wants to merge 3 commits into from
Closed

Replace old README with shiny new Markdown-based README #162

wants to merge 3 commits into from

Conversation

nhubbard
Copy link

Fine tuned and tested, this new README is 100% Markdown. It has (some) syntax highlighting, code recognition and more!

This commit replaces the default text document with a GitHub Flavored Markdown-compatible README.
@0xAX
Copy link
Contributor

0xAX commented Feb 20, 2015

@joshumax
Copy link

That's a lovely addition, but alas, Linus doesn't accept pull requests on GitHub for many important reasons... You can always try to submit this as a patch on the LKML, but AFAIK the kernel README isn't already in markdown for other important reasons, so you will most likely just get yelled at...good luck with whatever you do, and if the worst happens, you'll always have your own fork!

@icePrograms
Copy link

Sorry I am a fairly new dev. And I just joined gethub so I was learning what everything does. I'm not sure what I requested but I wasn't trying to edit anything. I'm here only to read code not submit yet.

Sent from my iPhone

On Feb 20, 2015, at 4:03 PM, Josh Max notifications@github.com wrote:

That's a lovely addition, but alas, Linus doesn't accept pull requests on GitHub for many important reasons... You can always try to submit this as a patch on the LKML, but AFAIK the kernel README isn't already in markdown for other important reasons, so you will most likely get yelled at...good luck with whatever you do, and if the worst happens, you'll always have your own fork!


Reply to this email directly or view it on GitHub.

@adymitruk
Copy link

Gethub and iPhone
On Feb 21, 2015 8:11 AM, "icePrograms" notifications@github.com wrote:

Sorry I am a fairly new dev. And I just joined gethub so I was learning
what everything does. I'm not sure what I requested but I wasn't trying to
edit anything. I'm here only to read code not submit yet.

Sent from my iPhone

On Feb 20, 2015, at 4:03 PM, Josh Max notifications@github.com wrote:

That's a lovely addition, but alas, Linus doesn't accept pull requests
on GitHub for many important reasons... You can always try to submit this
as a patch on the LKML, but AFAIK the kernel README isn't already in
markdown for other important reasons, so you will most likely get yelled
at...good luck with whatever you do, and if the worst happens, you'll
always have your own fork!


Reply to this email directly or view it on GitHub.


Reply to this email directly or view it on GitHub
#162 (comment).

@nhubbard
Copy link
Author

Hi @joshumax:
I just wanted this on the GitHub clone of the repository, so that it only displays on GitHub.
If that is possible...

@Parker8283
Copy link

No, Linus just pushes the changes from the official Linux git repo.

0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Apr 21, 2016
lockdep reports the following circular locking dependency.

======================================================
INFO: possible circular locking dependency detected ]
4.6.0-rc3-00191-gfabf418 torvalds#162 Not tainted
-------------------------------------------------------
systemd/1 is trying to acquire lock:
((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280

but task is already holding lock:

(&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190

which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:

-> #1 (&wd_data->lock){+.+...}:
	[<80662310>] mutex_lock_nested+0x64/0x4a8
	[<804aca4c>] watchdog_ping_work+0x18/0x4c
	[<80143128>] process_one_work+0x1ac/0x500
	[<801434b4>] worker_thread+0x38/0x554
	[<80149510>] kthread+0xf4/0x108
	[<80107c10>] ret_from_fork+0x14/0x24

-> #0 ((&(&wd_data->work)->work)){+.+...}:
	[<8017c4e8>] lock_acquire+0x70/0x90
	[<8014169c>] flush_work+0x4c/0x280
	[<801440f8>] __cancel_work_timer+0x9c/0x1e0
	[<804acfcc>] watchdog_release+0x3c/0x190
	[<8022c5e8>] __fput+0x80/0x1c8
	[<80147b28>] task_work_run+0x94/0xc8
	[<8010b998>] do_work_pending+0x8c/0xb4
	[<80107ba8>] slow_work_pending+0xc/0x20

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0                    CPU1
----                    ----
lock(&wd_data->lock);
                        lock((&(&wd_data->work)->work));
                        lock(&wd_data->lock);
lock((&(&wd_data->work)->work));

*** DEADLOCK ***

1 lock held by systemd/1:

stack backtrace:
CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 torvalds#162
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[<8010f5e4>] (unwind_backtrace) from [<8010c038>] (show_stack+0x10/0x14)
[<8010c038>] (show_stack) from [<8039d7fc>] (dump_stack+0xa8/0xd4)
[<8039d7fc>] (dump_stack) from [<80177ee0>] (print_circular_bug+0x214/0x334)
[<80177ee0>] (print_circular_bug) from [<80179230>] (check_prevs_add+0x4dc/0x8e8)
[<80179230>] (check_prevs_add) from [<8017b3d8>] (__lock_acquire+0xc6c/0x14ec)
[<8017b3d8>] (__lock_acquire) from [<8017c4e8>] (lock_acquire+0x70/0x90)
[<8017c4e8>] (lock_acquire) from [<8014169c>] (flush_work+0x4c/0x280)
[<8014169c>] (flush_work) from [<801440f8>] (__cancel_work_timer+0x9c/0x1e0)
[<801440f8>] (__cancel_work_timer) from [<804acfcc>] (watchdog_release+0x3c/0x190)
[<804acfcc>] (watchdog_release) from [<8022c5e8>] (__fput+0x80/0x1c8)
[<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8)
[<80147b28>] (task_work_run) from [<8010b998>] (do_work_pending+0x8c/0xb4)
[<8010b998>] (do_work_pending) from [<80107ba8>] (slow_work_pending+0xc/0x20)

Turns out the call to cancel_delayed_work_sync() in watchdog_release()
is not necessary and can be dropped. If the worker is no longer necessary,
the subsequent call to watchdog_update_worker() will cancel it. If it is
already running, it won't do anything, since the worker function checks
if it needs to ping the watchdog or not.

Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Fixes: 11d7aba ("watchdog: imx2: Convert to use infrastructure triggered keepalives")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request May 16, 2016
lockdep reports the following circular locking dependency.

======================================================
INFO: possible circular locking dependency detected ]
4.6.0-rc3-00191-gfabf418 torvalds#162 Not tainted
-------------------------------------------------------
systemd/1 is trying to acquire lock:
((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280

but task is already holding lock:

(&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190

which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:

-> #1 (&wd_data->lock){+.+...}:
	[<80662310>] mutex_lock_nested+0x64/0x4a8
	[<804aca4c>] watchdog_ping_work+0x18/0x4c
	[<80143128>] process_one_work+0x1ac/0x500
	[<801434b4>] worker_thread+0x38/0x554
	[<80149510>] kthread+0xf4/0x108
	[<80107c10>] ret_from_fork+0x14/0x24

-> #0 ((&(&wd_data->work)->work)){+.+...}:
	[<8017c4e8>] lock_acquire+0x70/0x90
	[<8014169c>] flush_work+0x4c/0x280
	[<801440f8>] __cancel_work_timer+0x9c/0x1e0
	[<804acfcc>] watchdog_release+0x3c/0x190
	[<8022c5e8>] __fput+0x80/0x1c8
	[<80147b28>] task_work_run+0x94/0xc8
	[<8010b998>] do_work_pending+0x8c/0xb4
	[<80107ba8>] slow_work_pending+0xc/0x20

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0                    CPU1
----                    ----
lock(&wd_data->lock);
                        lock((&(&wd_data->work)->work));
                        lock(&wd_data->lock);
lock((&(&wd_data->work)->work));

*** DEADLOCK ***

1 lock held by systemd/1:

stack backtrace:
CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 torvalds#162
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[<8010f5e4>] (unwind_backtrace) from [<8010c038>] (show_stack+0x10/0x14)
[<8010c038>] (show_stack) from [<8039d7fc>] (dump_stack+0xa8/0xd4)
[<8039d7fc>] (dump_stack) from [<80177ee0>] (print_circular_bug+0x214/0x334)
[<80177ee0>] (print_circular_bug) from [<80179230>] (check_prevs_add+0x4dc/0x8e8)
[<80179230>] (check_prevs_add) from [<8017b3d8>] (__lock_acquire+0xc6c/0x14ec)
[<8017b3d8>] (__lock_acquire) from [<8017c4e8>] (lock_acquire+0x70/0x90)
[<8017c4e8>] (lock_acquire) from [<8014169c>] (flush_work+0x4c/0x280)
[<8014169c>] (flush_work) from [<801440f8>] (__cancel_work_timer+0x9c/0x1e0)
[<801440f8>] (__cancel_work_timer) from [<804acfcc>] (watchdog_release+0x3c/0x190)
[<804acfcc>] (watchdog_release) from [<8022c5e8>] (__fput+0x80/0x1c8)
[<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8)
[<80147b28>] (task_work_run) from [<8010b998>] (do_work_pending+0x8c/0xb4)
[<8010b998>] (do_work_pending) from [<80107ba8>] (slow_work_pending+0xc/0x20)

Turns out the call to cancel_delayed_work_sync() in watchdog_release()
is not necessary and can be dropped. If the worker is no longer necessary,
the subsequent call to watchdog_update_worker() will cancel it. If it is
already running, it won't do anything, since the worker function checks
if it needs to ping the watchdog or not.

Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
Fixes: 11d7aba ("watchdog: imx2: Convert to use infrastructure triggered keepalives")
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
Cc: stable <stable@vger.kernel.org>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request May 25, 2016
Hi Linus,

Please pull from 'master' branch of
	git://www.linux-watchdog.org/linux-watchdog.git

This adds following changes:
* Add support for Fintek F81865 Super-IO chip
* Add support for watchdogs (RWDT and SWDT) found on RCar Gen3 based SoCs from Renesas
* octeon: Handle the FROZEN hot plug notifier actions
* f71808e_wdt fixes and cleanups
* Some small improvements in code and documentation

This will update the following files:

 Documentation/devicetree/bindings/watchdog/fsl-imx-wdt.txt |    4
 Documentation/devicetree/bindings/watchdog/renesas-wdt.txt |   25 +
 Documentation/watchdog/hpwdt.txt                           |   57 +--
 Documentation/watchdog/watchdog-parameters.txt             |    4
 MAINTAINERS                                                |    1
 arch/arm64/configs/defconfig                               |    2
 drivers/watchdog/Kconfig                                   |    8
 drivers/watchdog/Makefile                                  |    1
 drivers/watchdog/cpwd.c                                    |    4
 drivers/watchdog/f71808e_wdt.c                             |   30 +
 drivers/watchdog/imx2_wdt.c                                |   19 +
 drivers/watchdog/jz4740_wdt.c                              |    4
 drivers/watchdog/octeon-wdt-main.c                         |    2
 drivers/watchdog/qcom-wdt.c                                |    7
 drivers/watchdog/renesas_wdt.c                             |  213 +++++++++++++
 drivers/watchdog/shwdt.c                                   |    4
 drivers/watchdog/sp5100_tco.c                              |   15
 drivers/watchdog/watchdog_core.c                           |    2
 drivers/watchdog/watchdog_dev.c                            |    1
 19 files changed, 349 insertions(+), 54 deletions(-)

with these Changes:

commit 540be8b
Author: Geert Uytterhoeven <geert@linux-m68k.org>
Date:   Sun May 22 11:06:29 2016 +0200

    MAINTAINERS: Add file patterns for watchdog device tree bindings

    Submitters of device tree binding documentation may forget to CC
    the subsystem maintainer if this is missing.

    Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Cc: linux-watchdog@vger.kernel.org

commit ae67643
Author: William Breathitt Gray <vilhelm.gray@gmail.com>
Date:   Wed May 11 08:47:46 2016 -0400

    Documentation: Add ebc-c384_wdt watchdog-parameters.txt entry

    The WinSystems EBC-C384 watchdog timer driver supports two module
    parameters: timeout and nowayout. These parameters should be documented
    in the watchdog-parameters.txt file.

    Signed-off-by: William Breathitt Gray <vilhelm.gray@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit 12fe36e
Author: Muhammad Falak R Wani <falakreyaz@gmail.com>
Date:   Fri May 6 18:29:41 2016 +0530

    watchdog: shwdt: Use setup_timer()

    The function setup_timer combines the initialization of a timer with
    the initialization of the timer's function and data fields.
    The multiline code for timer initialization is now replaced
    with function setup_timer.

    Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit d904ac3
Author: Muhammad Falak R Wani <falakreyaz@gmail.com>
Date:   Fri May 6 18:29:40 2016 +0530

    watchdog: cpwd: Use setup_timer()

    The function setup_timer combines the initialization of a timer with
    the initialization of the timer's function and data fields.
    The multiline code for timer initialization is now replaced
    with function setup_timer.

    Signed-off-by: Muhammad Falak R Wani <falakreyaz@gmail.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit fc4d2c7
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Fri Apr 1 13:56:26 2016 +0200

    arm64: defconfig: enable Renesas Watchdog Timer

    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit bd99b68
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Fri Apr 1 13:56:23 2016 +0200

    watchdog: renesas-wdt: add driver

    Add support for watchdogs (RWDT and SWDT) found on RCar Gen3 based SoCs
    from Renesas.

    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit e26e74b
Author: Colin Ian King <colin.king@canonical.com>
Date:   Tue Apr 26 18:18:49 2016 +0100

    watchdog: remove error message when unable to allocate watchdog device

    The dev_err message is superfluous because the failure is already
    printed by dev_kzalloc, so remove it.

    Signed-off-by: Colin Ian King <colin.king@canonical.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit b97cb21
Author: Knud Poulsen <knpo@ieee.org>
Date:   Tue Apr 26 08:44:16 2016 +0200

    watchdog: f71808e_wdt: Fix WDTMOUT_STS register read

    Tested and verified on Lanner LEC-3030 Industrial PC (with F81865)

    Datasheet verified for
     F71808, F71858, F71862, F71869, F71869A, F71882, F71889, F81865

    Datasheet references:
    F71808A:
     http://www.electronicsdatasheets.com/download/534cf560e34e2406135f4658.pdf?format=pdf
    F71858:
     http://www.electronicsdatasheets.com/download/534cf55fe34e2406135f4635.pdf?format=pdf
    F71862:
     http://www.hardwaresecrets.com/datasheets/F71862_V027P.pdf
    F71869:
     http://www.clubedohardware.com.br/datasheets/366451_F71869.pdf
    F71869A:
     http://www.chipset-ic.com/datasheet/F71869AD.pdf
    F71882:
     http://www.digchip.com/datasheets/parts/datasheet/931/F71882-pdf.php
    F71889:
     http://pdf1.alldatasheet.com/datasheet-pdf/view/406312/FINTEK/F71889.html
    F81865:
     http://www.hardwaresecrets.com/datasheets/F81865_V028P.pdf
     http://www.alldatasheet.com/datasheet-pdf/pdf/406317/FINTEK/F81865.html

    Signed-off-by: Knud Poulsen <knpo@ieee.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit 85c130a
Author: Knud Poulsen <knpo@ieee.org>
Date:   Mon Apr 25 17:34:47 2016 +0200

    watchdog: f71808e_wdt: Fix typo

    Spelling/ typo

    Signed-off-by: Knud Poulsen <knpo@ieee.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit ea0c03e
Author: Knud Poulsen <knpo@ieee.org>
Date:   Mon Apr 25 12:28:51 2016 +0200

    watchdog: f71808e_wdt: Add F81865 support

    Adds watchdog enable support for Fintek F81865 Super-IO chip to
    Fintek wdt driver (f71808e_wdt)

    Tested and verified on Lanner LEC-3030 Industrial PC

    Datasheet references:
    http://www.hardwaresecrets.com/datasheets/F81865_V028P.pdf
    http://www.alldatasheet.com/datasheet-pdf/pdf/406317/FINTEK/F81865.html

    Signed-off-by: Knud Poulsen <knpo@ieee.org>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit 46856fa
Author: Lucas Stach <dev@lynxeye.de>
Date:   Tue May 3 19:15:58 2016 +0200

    watchdog: sp5100_tco: properly check for new register layouts

    Commits 190aa43 (Add AMD Mullins platform support) and
    cca118f (Add AMD Carrizo platform support) enabled the
    driver on a lot more devices, but the following commit missed
    a single location in the code when checking if the SB800 register
    offsets should be used. This leads to the wrong register being
    written which in turn causes ACPI to go haywire.

    Fix this by introducing a helper function to check for the new
    register layout and use this consistently.

    https://bugzilla.kernel.org/show_bug.cgi?id=114201
    https://bugzilla.redhat.com/show_bug.cgi?id=1329910
    Fixes: bdecfcd (sp5100_tco: fix the device check for SB800
    and later chipsets)
    Cc: stable@vger.kernel.org (4.5+)
    Signed-off-by: Lucas Stach <dev@lynxeye.de>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit e1f3028
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Thu Apr 21 07:38:14 2016 -0700

    watchdog: core: Fix circular locking dependency

    lockdep reports the following circular locking dependency.

    ======================================================
    INFO: possible circular locking dependency detected ]
    4.6.0-rc3-00191-gfabf418 torvalds#162 Not tainted
    -------------------------------------------------------
    systemd/1 is trying to acquire lock:
    ((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280

    but task is already holding lock:

    (&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190

    which lock already depends on the new lock.
    the existing dependency chain (in reverse order) is:

    -> #1 (&wd_data->lock){+.+...}:
    	[<80662310>] mutex_lock_nested+0x64/0x4a8
    	[<804aca4c>] watchdog_ping_work+0x18/0x4c
    	[<80143128>] process_one_work+0x1ac/0x500
    	[<801434b4>] worker_thread+0x38/0x554
    	[<80149510>] kthread+0xf4/0x108
    	[<80107c10>] ret_from_fork+0x14/0x24

    -> #0 ((&(&wd_data->work)->work)){+.+...}:
    	[<8017c4e8>] lock_acquire+0x70/0x90
    	[<8014169c>] flush_work+0x4c/0x280
    	[<801440f8>] __cancel_work_timer+0x9c/0x1e0
    	[<804acfcc>] watchdog_release+0x3c/0x190
    	[<8022c5e8>] __fput+0x80/0x1c8
    	[<80147b28>] task_work_run+0x94/0xc8
    	[<8010b998>] do_work_pending+0x8c/0xb4
    	[<80107ba8>] slow_work_pending+0xc/0x20

    other info that might help us debug this:
    Possible unsafe locking scenario:

    CPU0                    CPU1
    ----                    ----
    lock(&wd_data->lock);
                            lock((&(&wd_data->work)->work));
                            lock(&wd_data->lock);
    lock((&(&wd_data->work)->work));

    *** DEADLOCK ***

    1 lock held by systemd/1:

    stack backtrace:
    CPU: 2 PID: 1 Comm: systemd Not tainted 4.6.0-rc3-00191-gfabf418 torvalds#162
    Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
    [<8010f5e4>] (unwind_backtrace) from [<8010c038>] (show_stack+0x10/0x14)
    [<8010c038>] (show_stack) from [<8039d7fc>] (dump_stack+0xa8/0xd4)
    [<8039d7fc>] (dump_stack) from [<80177ee0>] (print_circular_bug+0x214/0x334)
    [<80177ee0>] (print_circular_bug) from [<80179230>] (check_prevs_add+0x4dc/0x8e8)
    [<80179230>] (check_prevs_add) from [<8017b3d8>] (__lock_acquire+0xc6c/0x14ec)
    [<8017b3d8>] (__lock_acquire) from [<8017c4e8>] (lock_acquire+0x70/0x90)
    [<8017c4e8>] (lock_acquire) from [<8014169c>] (flush_work+0x4c/0x280)
    [<8014169c>] (flush_work) from [<801440f8>] (__cancel_work_timer+0x9c/0x1e0)
    [<801440f8>] (__cancel_work_timer) from [<804acfcc>] (watchdog_release+0x3c/0x190)
    [<804acfcc>] (watchdog_release) from [<8022c5e8>] (__fput+0x80/0x1c8)
    [<8022c5e8>] (__fput) from [<80147b28>] (task_work_run+0x94/0xc8)
    [<80147b28>] (task_work_run) from [<8010b998>] (do_work_pending+0x8c/0xb4)
    [<8010b998>] (do_work_pending) from [<80107ba8>] (slow_work_pending+0xc/0x20)

    Turns out the call to cancel_delayed_work_sync() in watchdog_release()
    is not necessary and can be dropped. If the worker is no longer necessary,
    the subsequent call to watchdog_update_worker() will cancel it. If it is
    already running, it won't do anything, since the worker function checks
    if it needs to ping the watchdog or not.

    Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com>
    Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
    Fixes: 11d7aba ("watchdog: imx2: Convert to use infrastructure triggered keepalives")
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>
    Cc: stable <stable@vger.kernel.org>

commit 358d5a5
Author: Wolfram Sang <wsa+renesas@sang-engineering.com>
Date:   Tue Apr 12 17:56:11 2016 +0200

    watchdog: core: fix trivial typo in a comment

    Let's have balanced round brackets.

    Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit 84df082
Author: Nigel Croxon <nigel.croxon@hpe.com>
Date:   Wed Apr 6 14:40:05 2016 -0400

    watchdog: hpwdt: Adjust documentation to match latest kernel module parameters.

    Adjust documentation to match latest kernel module parameters.

    Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit bc677ff
Author: Tim Harvey <tharvey@gateworks.com>
Date:   Fri Apr 1 08:16:43 2016 -0700

    watchdog: imx2_wdt: add external reset support via dt prop

    The IMX6 watchdog supports assertion of a signal (WDOG_B) which
    can be pinmux'd to an external pin. This is typically used for boards that
    have PMIC's in control of the IMX6 power rails. In fact, failure to use
    such an external reset on boards with external PMIC's can result in various
    hangs due to the IMX6 not being fully reset [1] as well as the board failing
    to reset because its PMIC has not been reset to provide adequate voltage for
    the CPU when coming out of reset at 800Mhz.

    This uses a new device-tree property 'fsl,ext-reset-output' to indicate the
    board has such a reset and to cause the watchdog to be configured to assert
    WDOG_B instead of an internal reset both on a watchdog timeout and in
    system_restart.

    [1] http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/333689.html

    Cc: Fabio Estevam <festevam@gmail.com>
    Cc: Lucas Stach <l.stach@pengutronix.de>
    Cc: Stefan Roese <sr@denx.de>
    Cc: Iain Paton <ipaton0@gmail.com>
    Cc: Sascha Hauer <s.hauer@pengutronix.de>
    Signed-off-by: Tim Harvey <tharvey@gateworks.com>
    Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
    Acked-by: Shawn Guo <shawn.guo@linaro.org>
    Tested-by: Akshay Bhat <akshay.bhat@timesys.com>
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit ebbf677
Author: Richard Cochran <rcochran@linutronix.de>
Date:   Fri Mar 18 22:26:08 2016 +0100

    watchdog: octeon: Handle the FROZEN hot plug notifier actions.

    When performing a suspend operation, the kernel brings all of the
    non-boot CPUs offline, calling the hot plug notifiers with the flag,
    CPU_TASKS_FROZEN, set in the action code.  Similarly, during resume,
    the CPUs are brought back online, but again the notifiers have the
    FROZEN flag set.

    While some very few drivers really need to treat suspend/resume
    specially, this driver unintentionally ignores the notifications.

    This patch changes the driver to disable the watchdog interrupt
    whenever the CPU goes offline, and to enable it whenever the CPU goes
    back online.  As a result, the suspended state is no longer a special
    case that leaves the watchdog active.

    Signed-off-by: Richard Cochran <rcochran@linutronix.de>
    Cc: linux-watchdog@vger.kernel.org
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

commit b6ef36d
Author: Guenter Roeck <groeck@chromium.org>
Date:   Mon Apr 4 17:37:46 2016 -0700

    watchdog: qcom: Report reboot reason

    The Qualcom watchdog timer block reports if the system was reset by the
    watchdog. Pass the information to user space.

    Reviewed-by: Grant Grundler <grundler@chromium.org>
    Tested-by: Grant Grundler <grundler@chromium.org>
    Signed-off-by: Guenter Roeck <groeck@chromium.org>
    Signed-off-by: Wim Van Sebroeck <wim@iguana.be>

For completeness, I added the overal diff below.

Greetings,
Wim.

================================================================================
eegorov referenced this pull request in eegorov/zen-kernel Jun 2, 2016
commit e1f3028 upstream.

lockdep reports the following circular locking dependency.

======================================================
INFO: possible circular locking dependency detected ]
4.6.0-rc3-00191-gfabf418 zen-kernel#162 Not tainted
-------------------------------------------------------
systemd/1 is trying to acquire lock:
((&(&wd_data->work)->work)){+.+...}, at: [<80141650>] flush_work+0x0/0x280

but task is already holding lock:

(&wd_data->lock){+.+...}, at: [<804acfa8>] watchdog_release+0x18/0x190

which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:

-> zen-kernel#1 (&wd_data->lock){+.+...}:
	[<80662310>] mutex_lock_nested+0x64/0x4a8
	[<804aca4c>] watchdog_ping_work+0x18/0x4c
	[<80143128>] process_one_work+0x1ac/0x500
	[<801434b4>] worker_thread+0x38/0x554
	[<80149510>] kthread+0xf4/0x108
	[<80107c10>] ret_from_fork+0x14/0x24

-> #0 ((&(&wd_data->work)->work)){+.+...}:
	[<8017c4e8>] lock_acquire+0x70/0x90
	[<8014169c>] flush_work+0x4c/0x280
	[<801440f8>] __cancel_work_timer+0x9c/0x1e0
	[<804acfcc>] watchdog_release+0x3c/0x190
	[<8022c5e8>] __fput+0x80/0x1c8
	[<80147b28>] task_work_run+0x94/0xc8
	[<8010b998>] do_work_pending+0x8c/0xb4
	[<80107ba8>] slow_work_pending+0xc/0x20

other info that might help us debug this:
Possible unsafe locking scenario:

CPU0                    CPU1
----                    ----
lock(&wd_data->lock);
                        lock((&(&wd_data->work)->work));
                        lock(&wd_data->lock);
lock((&(&wd_data->work)->work));
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Dec 20, 2016
Christopher Covington reported a crash on aarch64 on recent Fedora
kernels:

kernel BUG at ./include/linux/scatterlist.h:140!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc torvalds#162
Hardware name: linux,dummy-virt (DT)
task: ffff80007c650080 task.stack: ffff800008910000
PC is at sg_init_one+0xa0/0xb8
LR is at sg_init_one+0x24/0xb8
...
[<ffff000008398db8>] sg_init_one+0xa0/0xb8
[<ffff000008350a44>] test_acomp+0x10c/0x438
[<ffff000008350e20>] alg_test_comp+0xb0/0x118
[<ffff00000834f28c>] alg_test+0x17c/0x2f0
[<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
[<ffff0000080dac70>] kthread+0xf8/0x128
[<ffff000008082ec0>] ret_from_fork+0x10/0x50

The test vectors used for input are part of the kernel image. These
inputs are passed as a buffer to sg_init_one which eventually blows up
with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
false for the kernel image since virt_to_page will not return the
correct page. The kernel image is also aliased to the linear map so get
the linear alias and pass that to the scatterlist instead.

Reported-by: Christopher Covington <cov@codeaurora.org>
Fixes: d7db7a8 ("crypto: acomp - update testmgr with support for acomp")
Signed-off-by: Laura Abbott <labbott@redhat.com>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Dec 22, 2016
Christopher Covington reported a crash on aarch64 on recent Fedora
kernels:

kernel BUG at ./include/linux/scatterlist.h:140!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc torvalds#162
Hardware name: linux,dummy-virt (DT)
task: ffff80007c650080 task.stack: ffff800008910000
PC is at sg_init_one+0xa0/0xb8
LR is at sg_init_one+0x24/0xb8
...
[<ffff000008398db8>] sg_init_one+0xa0/0xb8
[<ffff000008350a44>] test_acomp+0x10c/0x438
[<ffff000008350e20>] alg_test_comp+0xb0/0x118
[<ffff00000834f28c>] alg_test+0x17c/0x2f0
[<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
[<ffff0000080dac70>] kthread+0xf8/0x128
[<ffff000008082ec0>] ret_from_fork+0x10/0x50

The test vectors used for input are part of the kernel image. These
inputs are passed as a buffer to sg_init_one which eventually blows up
with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
false for the kernel image since virt_to_page will not return the
correct page. Fix this by copying the input vectors to heap buffer
before setting up the scatterlist.

Reported-by: Christopher Covington <cov@codeaurora.org>
Fixes: d7db7a8 ("crypto: acomp - update testmgr with support for acomp")
Signed-off-by: Laura Abbott <labbott@redhat.com>
torvalds pushed a commit that referenced this pull request Dec 30, 2016
Christopher Covington reported a crash on aarch64 on recent Fedora
kernels:

kernel BUG at ./include/linux/scatterlist.h:140!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 752 Comm: cryptomgr_test Not tainted 4.9.0-11815-ge93b1cc #162
Hardware name: linux,dummy-virt (DT)
task: ffff80007c650080 task.stack: ffff800008910000
PC is at sg_init_one+0xa0/0xb8
LR is at sg_init_one+0x24/0xb8
...
[<ffff000008398db8>] sg_init_one+0xa0/0xb8
[<ffff000008350a44>] test_acomp+0x10c/0x438
[<ffff000008350e20>] alg_test_comp+0xb0/0x118
[<ffff00000834f28c>] alg_test+0x17c/0x2f0
[<ffff00000834c6a4>] cryptomgr_test+0x44/0x50
[<ffff0000080dac70>] kthread+0xf8/0x128
[<ffff000008082ec0>] ret_from_fork+0x10/0x50

The test vectors used for input are part of the kernel image. These
inputs are passed as a buffer to sg_init_one which eventually blows up
with BUG_ON(!virt_addr_valid(buf)). On arm64, virt_addr_valid returns
false for the kernel image since virt_to_page will not return the
correct page. Fix this by copying the input vectors to heap buffer
before setting up the scatterlist.

Reported-by: Christopher Covington <cov@codeaurora.org>
Fixes: d7db7a8 ("crypto: acomp - update testmgr with support for acomp")
Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jan 12, 2017
Due to alignment requirements of the hardware transmissions are split
into two DMA requests, a small padding request of 0 - 4 bytes in length
followed by the a request for rest of the packet.

In the case of IP packets the first request will never be zero due
to the way that the stack aligns buffers for IP packets. However, for
non-IP packets it may be zero.

In this case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA request and thus the packet
is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] ------------[ cut here ]------------
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f torvalds#162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[   20.436019] sp : ffff80063a71f9b0
[   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[   20.449944] x25: 000000067abe2adc x24: 0000000000000000
[   20.455252] x23: 0000000000200000 x22: 0000000000000001
[   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
[   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[   20.931867] Call trace:
[   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[   21.094611] ---[ end trace 5bc544ad491f3814 ]---
[   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[   21.105587] Kernel Offset: disabled
[   21.109073] Memory Limit: none
[   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 2f45d19 ("ravb: minimize TX data copying")
Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jan 14, 2017
Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.

In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.

In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] ------------[ cut here ]------------
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f torvalds#162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[   20.436019] sp : ffff80063a71f9b0
[   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[   20.449944] x25: 000000067abe2adc x24: 0000000000000000
[   20.455252] x23: 0000000000200000 x22: 0000000000000001
[   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
[   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[   20.931867] Call trace:
[   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[   21.094611] ---[ end trace 5bc544ad491f3814 ]---
[   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[   21.105587] Kernel Offset: disabled
[   21.109073] Memory Limit: none
[   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 2f45d19 ("ravb: minimize TX data copying")
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jan 16, 2017
Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.

In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.

In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] ------------[ cut here ]------------
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f torvalds#162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[   20.436019] sp : ffff80063a71f9b0
[   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[   20.449944] x25: 000000067abe2adc x24: 0000000000000000
[   20.455252] x23: 0000000000200000 x22: 0000000000000001
[   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
[   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[   20.931867] Call trace:
[   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[   21.094611] ---[ end trace 5bc544ad491f3814 ]---
[   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[   21.105587] Kernel Offset: disabled
[   21.109073] Memory Limit: none
[   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 2f45d19 ("ravb: minimize TX data copying")
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jan 16, 2017
Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.

In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.

In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] ------------[ cut here ]------------
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f torvalds#162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[   20.436019] sp : ffff80063a71f9b0
[   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[   20.449944] x25: 000000067abe2adc x24: 0000000000000000
[   20.455252] x23: 0000000000200000 x22: 0000000000000001
[   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
[   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[   20.931867] Call trace:
[   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[   21.094611] ---[ end trace 5bc544ad491f3814 ]---
[   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[   21.105587] Kernel Offset: disabled
[   21.109073] Memory Limit: none
[   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 2f45d19 ("ravb: minimize TX data copying")
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
ddstreet pushed a commit to ddstreet/linux that referenced this pull request Jan 19, 2017
GIT fa19a769f82fb9a5ca000b83cacd13fcaeda51ac

commit 5eb7c0d04f04a667c049fe090a95494a8de2955c
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date:   Sun Jan 1 20:25:25 2017 -0600

    taint/module: Fix problems when out-of-kernel driver defines true or false
    
    Commit 7fd8329ba502 ("taint/module: Clean up global and module taint
    flags handling") used the key words true and false as character members
    of a new struct. These names cause problems when out-of-kernel modules
    such as VirtualBox include their own definitions of true and false.
    
    Fixes: 7fd8329ba502 ("taint/module: Clean up global and module taint flags handling")
    Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
    Cc: Petr Mladek <pmladek@suse.com>
    Cc: Jessica Yu <jeyu@redhat.com>
    Cc: Rusty Russell <rusty@rustcorp.com.au>
    Reported-by: Valdis Kletnieks <Valdis.Kletnieks@vt.edu>
    Reviewed-by: Petr Mladek <pmladek@suse.com>
    Acked-by: Rusty Russell <rusty@rustcorp.com.au>
    Signed-off-by: Jessica Yu <jeyu@redhat.com>

commit 4e71de7986386d5fd3765458f27d612931f27f5e
Author: Zhou Chengming <zhouchengming1@huawei.com>
Date:   Mon Jan 16 11:21:11 2017 +0800

    perf/x86/intel: Handle exclusive threadid correctly on CPU hotplug
    
    The CPU hotplug function intel_pmu_cpu_starting() sets
    cpu_hw_events.excl_thread_id unconditionally to 1 when the shared exclusive
    counters data structure is already availabe for the sibling thread.
    
    This works during the boot process because the first sibling gets threadid
    0 assigned and the second sibling which shares the data structure gets 1.
    
    But when the first thread of the core is offlined and onlined again it
    shares the data structure with the second thread and gets exclusive thread
    id 1 assigned as well.
    
    Prevent this by checking the threadid of the already online thread.
    
    [ tglx: Rewrote changelog ]
    
    Signed-off-by: Zhou Chengming <zhouchengming1@huawei.com>
    Cc: NuoHan Qiao <qiaonuohan@huawei.com>
    Cc: ak@linux.intel.com
    Cc: peterz@infradead.org
    Cc: kan.liang@intel.com
    Cc: dave.hansen@linux.intel.com
    Cc: eranian@google.com
    Cc: qiaonuohan@huawei.com
    Cc: davidcc@google.com
    Cc: guohanjun@huawei.com
    Link: http://lkml.kernel.org/r/1484536871-3131-1-git-send-email-zhouchengming1@huawei.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    ---					---
     arch/x86/events/intel/core.c |    7 +++++--
     1 file changed, 5 insertions(+), 2 deletions(-)

commit bc7c36eedb0c7004aa06c2afc3c5385adada8fa3
Author: Joonyoung Shim <jy0922.shim@samsung.com>
Date:   Tue Jan 17 13:54:36 2017 +0900

    clocksource/exynos_mct: Clear interrupt when cpu is shut down
    
    When a CPU goes offline a potentially pending timer interrupt is not
    cleared. When the CPU comes online again then the pending interrupt is
    delivered before the per cpu clockevent device is initialized. As a
    consequence the tick interrupt handler dereferences a NULL pointer.
    
    [   51.251378] Unable to handle kernel NULL pointer dereference at virtual address 00000040
    [   51.289348] task: ee942d00 task.stack: ee960000
    [   51.293861] PC is at tick_periodic+0x38/0xb0
    [   51.298102] LR is at tick_handle_periodic+0x1c/0x90
    
    Clear the pending interrupt in the cpu dying path.
    
    Fixes: 56a94f13919c ("clocksource: exynos_mct: Avoid blocking calls in the cpu hotplug notifier")
    Reported-by: Seung-Woo Kim <sw0312.kim@samsung.com>
    Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
    Cc: linux-samsung-soc@vger.kernel.org
    Cc: cw00.choi@samsung.com
    Cc: daniel.lezcano@linaro.org
    Cc: stable@vger.kernel.org
    Cc: javier@osg.samsung.com
    Cc: kgene@kernel.org
    Cc: krzk@kernel.org
    Cc: linux-arm-kernel@lists.infradead.org
    Link: http://lkml.kernel.org/r/1484628876-22065-1-git-send-email-jy0922.shim@samsung.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit 0faa9cb5b3836a979864a6357e01d2046884ad52
Author: Jamal Hadi Salim <jhs@mojatatu.com>
Date:   Sun Jan 15 10:14:06 2017 -0500

    net sched actions: fix refcnt when GETing of action after bind
    
    Demonstrating the issue:
    
    .. add a drop action
    $sudo $TC actions add action drop index 10
    
    .. retrieve it
    $ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 2 bind 0 installed 29 sec used 29 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    ... bug 1 above: reference is two.
        Reference is actually 1 but we forget to subtract 1.
    
    ... do a GET again and we see the same issue
        try a few times and nothing changes
    ~$ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 2 bind 0 installed 31 sec used 31 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    ... lets try to bind the action to a filter..
    $ sudo $TC qdisc add dev lo ingress
    $ sudo $TC filter add dev lo parent ffff: protocol ip prio 1 \
      u32 match ip dst 127.0.0.1/32 flowid 1:1 action gact index 10
    
    ... and now a few GETs:
    $ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 3 bind 1 installed 204 sec used 204 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    $ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 4 bind 1 installed 206 sec used 206 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    $ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 5 bind 1 installed 235 sec used 235 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    .... as can be observed the reference count keeps going up.
    
    After the fix
    
    $ sudo $TC actions add action drop index 10
    $ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 1 bind 0 installed 4 sec used 4 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    $ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 1 bind 0 installed 6 sec used 6 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    $ sudo $TC qdisc add dev lo ingress
    $ sudo $TC filter add dev lo parent ffff: protocol ip prio 1 \
      u32 match ip dst 127.0.0.1/32 flowid 1:1 action gact index 10
    
    $ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 2 bind 1 installed 32 sec used 32 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    $ sudo $TC -s actions get action gact index 10
    
    	action order 1: gact action drop
    	 random type none pass val 0
    	 index 10 ref 2 bind 1 installed 33 sec used 33 sec
     	Action statistics:
    	Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    	backlog 0b 0p requeues 0
    
    Fixes: aecc5cefc389 ("net sched actions: fix GETing actions")
    Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 9577b174cd0323d287c994ef0891db71666d0765
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Mon Jan 16 18:31:39 2017 +0200

    net/mlx4_core: Eliminate warning messages for SRQ_LIMIT under SRIOV
    
    When running SRIOV, warnings for SRQ LIMIT events flood the Hypervisor's
    message log when (correct, normally operating) apps use SRQ LIMIT events
    as a trigger to post WQEs to SRQs.
    
    Add more information to the existing debug printout for SRQ_LIMIT, and
    output the warning messages only for the SRQ CATAS ERROR event.
    
    Fixes: acba2420f9d2 ("mlx4_core: Add wrapper functions and comm channel and slave event support to EQs")
    Fixes: e0debf9cb50d ("mlx4_core: Reduce warning message for SRQ_LIMIT event to debug level")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 7c3945bc2073554bb2ecf983e073dee686679c53
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Mon Jan 16 18:31:38 2017 +0200

    net/mlx4_core: Fix when to save some qp context flags for dynamic VST to VGT transitions
    
    Save the qp context flags byte containing the flag disabling vlan stripping
    in the RESET to INIT qp transition, rather than in the INIT to RTR
    transition. Per the firmware spec, the flags in this byte are active
    in the RESET to INIT transition.
    
    As a result of saving the flags in the incorrect qp transition, when
    switching dynamically from VGT to VST and back to VGT, the vlan
    remained stripped (as is required for VST) and did not return to
    not-stripped (as is required for VGT).
    
    Fixes: f0f829bf42cd ("net/mlx4_core: Add immediate activate for VGT->VST->VGT")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 291c566a28910614ce42d0ffe82196eddd6346f4
Author: Jack Morgenstein <jackm@dev.mellanox.co.il>
Date:   Mon Jan 16 18:31:37 2017 +0200

    net/mlx4_core: Fix racy CQ (Completion Queue) free
    
    In function mlx4_cq_completion() and mlx4_cq_event(), the
    radix_tree_lookup requires a rcu_read_lock.
    This is mandatory: if another core frees the CQ, it could
    run the radix_tree_node_rcu_free() call_rcu() callback while
    its being used by the radix tree lookup function.
    
    Additionally, in function mlx4_cq_event(), since we are adding
    the rcu lock around the radix-tree lookup, we no longer need to take
    the spinlock. Also, the synchronize_irq() call for the async event
    eliminates the need for incrementing the cq reference count in
    mlx4_cq_event().
    
    Other changes:
    1. In function mlx4_cq_free(), replace spin_lock_irq with spin_lock:
       we no longer take this spinlock in the interrupt context.
       The spinlock here, therefore, simply protects against different
       threads simultaneously invoking mlx4_cq_free() for different cq's.
    
    2. In function mlx4_cq_free(), we move the radix tree delete to before
       the synchronize_irq() calls. This guarantees that we will not
       access this cq during any subsequent interrupts, and therefore can
       safely free the CQ after the synchronize_irq calls. The rcu_read_lock
       in the interrupt handlers only needs to protect against corrupting the
       radix tree; the interrupt handlers may access the cq outside the
       rcu_read_lock due to the synchronize_irq calls which protect against
       premature freeing of the cq.
    
    3. In function mlx4_cq_event(), we change the mlx_warn message to mlx4_dbg.
    
    4. We leave the cq reference count mechanism in place, because it is
       still needed for the cq completion tasklet mechanism.
    
    Fixes: 6d90aa5cf17b ("net/mlx4_core: Make sure there are no pending async events when freeing CQ")
    Fixes: 225c7b1feef1 ("IB/mlx4: Add a driver Mellanox ConnectX InfiniBand adapters")
    Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
    Signed-off-by: Matan Barak <matanb@mellanox.com>
    Signed-off-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit b618ab4561d40664492cf9f9507f19a1c8272970
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Sun Jan 15 19:19:00 2017 +0100

    net: stmmac: don't use netdev_[dbg, info, ..] before net_device is registered
    
    Don't use netdev_info and friends before the net_device is registered.
    This avoids ugly messages like
    "meson8b-dwmac c9410000.ethernet (unnamed net_device) (uninitialized):
    Enable RX Mitigation via HW Watchdog Timer"
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit abeffce90c7f6ce74de9794ad0977a168edf8ef6
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Sun Jan 15 19:50:46 2017 +0200

    net/mlx5e: Fix a -Wmaybe-uninitialized warning
    
    As found by Olof's build bot, we gain a harmless warning about a
    potential uninitialized variable reference in mlx5:
    
    drivers/net/ethernet/mellanox/mlx5/core/en_tc.c: In function 'parse_tc_fdb_actions':
    drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:769:13: warning: 'out_dev' may be used uninitialized in this function [-Wmaybe-uninitialized]
    drivers/net/ethernet/mellanox/mlx5/core/en_tc.c:811:21: note: 'out_dev' was declared here
    
    This was introduced through the addition of an 'IS_ERR/PTR_ERR' pair
    that gcc is unfortunately unable to completely figure out.
    
    The problem being gcc cannot tell that if(IS_ERR()) in
    mlx5e_route_lookup_ipv4() is equivalent to checking if(err) later,
    so it assumes that 'out_dev' is used after the 'return PTR_ERR(rt)'.
    
    The PTR_ERR_OR_ZERO() case by comparison is fairly easy to detect
    by gcc, so it can't get that wrong, so it no longer warns.
    
    Hadar Hen Zion already attempted to fix the warning earlier by adding fake
    initializations, but that ended up not fully addressing all warnings, so
    I'm reverting it now that it is no longer needed.
    
    Link: http://arm-soc.lixom.net/buildlogs/mainline/v4.10-rc3-98-gcff3b2c/
    Fixes: a42485eb0ee4 ("net/mlx5e: TC ipv4 tunnel encap offload error flow fixes")
    Fixes: a757d108dc1a ("net/mlx5e: Fix kbuild warnings for uninitialized parameters")
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 8a367e74c0120ef68c8c70d5a025648c96626dff
Author: Basil Gunn <basil@pacabunga.com>
Date:   Sat Jan 14 12:18:55 2017 -0800

    ax25: Fix segfault after sock connection timeout
    
    The ax.25 socket connection timed out & the sock struct has been
    previously taken down ie. sock struct is now a NULL pointer. Checking
    the sock_flag causes the segfault.  Check if the socket struct pointer
    is NULL before checking sock_flag. This segfault is seen in
    timed out netrom connections.
    
    Please submit to -stable.
    
    Signed-off-by: Basil Gunn <basil@pacabunga.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit f1f7714ea51c56b7163fb1a5acf39c6a204dd758
Author: Daniel Borkmann <daniel@iogearbox.net>
Date:   Fri Jan 13 23:38:15 2017 +0100

    bpf: rework prog_digest into prog_tag
    
    Commit 7bd509e311f4 ("bpf: add prog_digest and expose it via
    fdinfo/netlink") was recently discussed, partially due to
    admittedly suboptimal name of "prog_digest" in combination
    with sha1 hash usage, thus inevitably and rightfully concerns
    about its security in terms of collision resistance were
    raised with regards to use-cases.
    
    The intended use cases are for debugging resp. introspection
    only for providing a stable "tag" over the instruction sequence
    that both kernel and user space can calculate independently.
    It's not usable at all for making a security relevant decision.
    So collisions where two different instruction sequences generate
    the same tag can happen, but ideally at a rather low rate. The
    "tag" will be dumped in hex and is short enough to introspect
    in tracepoints or kallsyms output along with other data such
    as stack trace, etc. Thus, this patch performs a rename into
    prog_tag and truncates the tag to a short output (64 bits) to
    make it obvious it's not collision-free.
    
    Should in future a hash or facility be needed with a security
    relevant focus, then we can think about requirements, constraints,
    etc that would fit to that situation. For now, rework the exposed
    parts for the current use cases as long as nothing has been
    released yet. Tested on x86_64 and s390x.
    
    Fixes: 7bd509e311f4 ("bpf: add prog_digest and expose it via fdinfo/netlink")
    Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
    Acked-by: Alexei Starovoitov <ast@kernel.org>
    Cc: Andy Lutomirski <luto@kernel.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 613f050d68a8ed3c0b18b9568698908ef7bbc1f7
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Jan 11 15:01:57 2017 +0900

    perf probe: Fix to probe on gcc generated functions in modules
    
    Fix to probe on gcc generated functions on modules. Since
    probing on a module is based on its symbol name, it should
    be adjusted on actual symbols.
    
    E.g. without this fix, perf probe shows probe definition
    on non-exist symbol as below.
    
      $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -F in_range*
      in_range.isra.12
      $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
      p:probe/in_range nf_nat:in_range+0
    
    With this fix, perf probe correctly shows a probe on
    gcc-generated symbol.
    
      $ perf probe -m build-x86_64/net/netfilter/nf_nat.ko -D in_range
      p:probe/in_range nf_nat:in_range.isra.12+0
    
    This also fixes same problem on online module as below.
    
      $ perf probe -m i915 -D assert_plane
      p:probe/assert_plane i915:assert_plane.constprop.134+0
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/148411450673.9978.14905987549651656075.stgit@devbox
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

commit 3e96dac7c956089d3f23aca98c4dfca57b6aaf8a
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Jan 11 15:00:47 2017 +0900

    perf probe: Add error checks to offline probe post-processing
    
    Add error check codes on post processing and improve it for offline
    probe events as:
    
     - post processing fails if no matched symbol found in map(-ENOENT)
       or strdup() failed(-ENOMEM).
    
     - Even if the symbol name is the same, it updates symbol address
       and offset.
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/148411443738.9978.4617979132625405545.stgit@devbox
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

commit 57d5f64d83ab5b5a5118b1597386dd76eaf4340d
Author: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
Date:   Fri Jan 13 15:46:25 2017 +0100

    tipc: allocate user memory with GFP_KERNEL flag
    
    Until now, we allocate memory always with GFP_ATOMIC flag.
    When the system is under memory pressure and a user tries to send,
    the send fails due to low memory. However, the user application
    can wait for free memory if we allocate it using GFP_KERNEL flag.
    
    In this commit, we use allocate memory with GFP_KERNEL for all user
    allocation.
    
    Reported-by: Rune Torgersen <runet@innovsys.com>
    Acked-by: Jon Maloy <jon.maloy@ericsson.com>
    Signed-off-by: Parthasarathy Bhuvaragan <parthasarathy.bhuvaragan@ericsson.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 34c55cf2fc75f8bf6ba87df321038c064cf2d426
Author: Karicheri, Muralidharan <m-karicheri2@ti.com>
Date:   Fri Jan 13 09:32:34 2017 -0500

    net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types
    
    Currently dp83867 driver returns error if phy interface type
    PHY_INTERFACE_MODE_RGMII_RXID is used to set the rx only internal
    delay. Similarly issue happens for PHY_INTERFACE_MODE_RGMII_TXID.
    Fix this by checking also the interface type if a particular delay
    value is missing in the phy dt bindings. Also update the DT document
    accordingly.
    
    Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
    Signed-off-by: Sekhar Nori <nsekhar@ti.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 02ca0423fd65a0a9c4d70da0dbb8f4b8503f08c7
Author: Jakub Sitnicki <jkbs@redhat.com>
Date:   Fri Jan 13 10:12:20 2017 +0100

    ip6_tunnel: Account for tunnel header in tunnel MTU
    
    With ip6gre we have a tunnel header which also makes the tunnel MTU
    smaller. We need to reserve room for it. Previously we were using up
    space reserved for the Tunnel Encapsulation Limit option
    header (RFC 2473).
    
    Also, after commit b05229f44228 ("gre6: Cleanup GREv6 transmit path,
    call common GRE functions") our contract with the caller has
    changed. Now we check if the packet length exceeds the tunnel MTU after
    the tunnel header has been pushed, unlike before.
    
    This is reflected in the check where we look at the packet length minus
    the size of the tunnel header, which is already accounted for in tunnel
    MTU.
    
    Fixes: b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE functions")
    Signed-off-by: Jakub Sitnicki <jkbs@redhat.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d2d4edbebe07ddb77980656abe7b9bc7a9e0cdf7
Author: Masami Hiramatsu <mhiramat@kernel.org>
Date:   Wed Jan 11 14:59:38 2017 +0900

    perf probe: Fix to show correct locations for events on modules
    
    Fix to show correct locations for events on modules by relocating given
    address instead of retrying after failure.
    
    This happens when the module text size is big enough, bigger than
    sh_addr, because the original code retries with given address + sh_addr
    if it failed to find CU DIE at the given address.
    
    Any address smaller than sh_addr always fails and it retries with the
    correct address, but addresses bigger than sh_addr will get a CU DIE
    which is on the given address (not adjusted by sh_addr).
    
    In my environment(x86-64), the sh_addr of ".text" section is 0x10030.
    Since i915 is a huge kernel module, we can see this issue as below.
    
      $ grep "[Tt] .*\[i915\]" /proc/kallsyms | sort | head -n1
      ffffffffc0270000 t i915_switcheroo_can_switch	[i915]
    
    ffffffffc0270000 + 0x10030 = ffffffffc0280030, so we'll check
    symbols cross this boundary.
    
      $ grep "[Tt] .*\[i915\]" /proc/kallsyms | grep -B1 ^ffffffffc028\
      | head -n 2
      ffffffffc027ff80 t haswell_init_clock_gating	[i915]
      ffffffffc0280110 t valleyview_init_clock_gating	[i915]
    
    So setup probes on both function and see what happen.
    
      $ sudo ./perf probe -m i915 -a haswell_init_clock_gating \
            -a valleyview_init_clock_gating
      Added new events:
        probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
        probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
    
      You can now use it in all perf tools, such as:
    
      	perf record -e probe:valleyview_init_clock_gating -aR sleep 1
    
      $ sudo ./perf probe -l
        probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
        probe:valleyview_init_clock_gating (on i915_vga_set_decode:4@gpu/drm/i915/i915_drv.c in i915)
    
    As you can see, haswell_init_clock_gating is correctly shown,
    but valleyview_init_clock_gating is not.
    
    With this patch, both events are shown correctly.
    
      $ sudo ./perf probe -l
        probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
        probe:valleyview_init_clock_gating (on valleyview_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
    
    Committer notes:
    
    In my case:
    
      # perf probe -m i915 -a haswell_init_clock_gating -a valleyview_init_clock_gating
      Added new events:
        probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
        probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
    
      You can now use it in all perf tools, such as:
    
    	  perf record -e probe:valleyview_init_clock_gating -aR sleep 1
    
      # perf probe -l
        probe:haswell_init_clock_gating (on i915_getparam+432@gpu/drm/i915/i915_drv.c in i915)
        probe:valleyview_init_clock_gating (on __i915_printk+240@gpu/drm/i915/i915_drv.c in i915)
      #
    
      # readelf -SW /lib/modules/4.9.0+/build/vmlinux | egrep -w '.text|Name'
       [Nr] Name   Type      Address          Off    Size   ES Flg Lk Inf Al
       [ 1] .text  PROGBITS  ffffffff81000000 200000 822fd3 00  AX  0   0 4096
      #
    
      So both are b0rked, now with the fix:
    
      # perf probe -m i915 -a haswell_init_clock_gating -a valleyview_init_clock_gating
      Added new events:
        probe:haswell_init_clock_gating (on haswell_init_clock_gating in i915)
        probe:valleyview_init_clock_gating (on valleyview_init_clock_gating in i915)
    
      You can now use it in all perf tools, such as:
    
    	perf record -e probe:valleyview_init_clock_gating -aR sleep 1
    
      # perf probe -l
        probe:haswell_init_clock_gating (on haswell_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
        probe:valleyview_init_clock_gating (on valleyview_init_clock_gating@gpu/drm/i915/intel_pm.c in i915)
      #
    
    Both looks correct.
    
    Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Namhyung Kim <namhyung@kernel.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: http://lkml.kernel.org/r/148411436777.9978.1440275861947194930.stgit@devbox
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

commit 1666d49e1d416fcc2cce708242a52fe3317ea8ba
Author: Hangbin Liu <liuhangbin@gmail.com>
Date:   Thu Jan 12 21:19:37 2017 +0800

    mld: do not remove mld souce list info when set link down
    
    This is an IPv6 version of commit 24803f38a5c0 ("igmp: do not remove igmp
    souce list..."). In mld_del_delrec(), we will restore back all source filter
    info instead of flush them.
    
    Move mld_clear_delrec() from ipv6_mc_down() to ipv6_mc_destroy_dev() since
    we should not remove source list info when set link down. Remove
    igmp6_group_dropped() in ipv6_mc_destroy_dev() since we have called it in
    ipv6_mc_down().
    
    Also clear all source info after igmp6_group_dropped() instead of in it
    because ipv6_mc_down() will call igmp6_group_dropped().
    
    Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 90f92c631b210c1e97080b53a9d863783281a932
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Tue Sep 13 12:31:17 2016 +0100

    ARM: 8613/1: Fix the uaccess crash on PB11MPCore
    
    The following patch was sketched by Russell in response to my
    crashes on the PB11MPCore after the patch for software-based
    priviledged no access support for ARMv8.1. See this thread:
    http://marc.info/?l=linux-arm-kernel&m=144051749807214&w=2
    
    I am unsure what is going on, I suspect everyone involved in
    the discussion is. I just want to repost this to get the
    discussion restarted, as I still have to apply this patch
    with every kernel iteration to get my PB11MPCore Realview
    running.
    
    Testing by Neil Armstrong on the Oxnas NAS has revealed that
    this bug exist also on that widely deployed hardware, so
    we are probably currently regressing all ARM11MPCore systems.
    
    Cc: Russell King <linux@armlinux.org.uk>
    Cc: Will Deacon <will.deacon@arm.com>
    Fixes: a5e090acbf54 ("ARM: software-based priviledged-no-access support")
    Tested-by: Neil Armstrong <narmstrong@baylibre.com>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

commit 34393529163af7163ef8459808e3cf2af7db7f16
Author: Ivan Vecera <cera@cera.cz>
Date:   Fri Jan 13 22:38:29 2017 +0100

    be2net: fix MAC addr setting on privileged BE3 VFs
    
    During interface opening MAC address stored in netdev->dev_addr is
    programmed in the HW with exception of BE3 VFs where the initial
    MAC is programmed by parent PF. This is OK when MAC address is not
    changed when an interfaces is down. In this case the requested MAC is
    stored to netdev->dev_addr and later is stored into HW during opening.
    But this is not done for all BE3 VFs so the NIC HW does not know
    anything about this change and all traffic is filtered.
    
    This is the case of bonding if fail_over_mac == 0 where the MACs of
    the slaves are changed while they are down.
    
    The be2net behavior is too restrictive because if a BE3 VF has
    the FILTMGMT privilege then it is able to modify its MAC without
    any restriction.
    
    To solve the described problem the driver should take care about these
    privileged BE3 VFs so the MAC is programmed during opening. And by
    contrast unpriviled BE3 VFs should not be allowed to change its MAC
    in any case.
    
    Cc: Sathya Perla <sathya.perla@broadcom.com>
    Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
    Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
    Cc: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Ivan Vecera <cera@cera.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 6d928ae590c8d58cfd5cca997d54394de139cbb7
Author: Ivan Vecera <cera@cera.cz>
Date:   Fri Jan 13 22:38:28 2017 +0100

    be2net: don't delete MAC on close on unprivileged BE3 VFs
    
    BE3 VFs without FILTMGMT privilege are not allowed to modify its MAC,
    VLAN table and UC/MC lists. So don't try to delete MAC on such VFs.
    
    Cc: Sathya Perla <sathya.perla@broadcom.com>
    Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
    Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
    Cc: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Ivan Vecera <cera@cera.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit fe68d8bfe59c561664aa87d827aa4b320eb08895
Author: Ivan Vecera <cera@cera.cz>
Date:   Fri Jan 13 22:38:27 2017 +0100

    be2net: fix status check in be_cmd_pmac_add()
    
    Return value from be_mcc_notify_wait() contains a base completion status
    together with an additional status. The base_status() macro need to be
    used to access base status.
    
    Fixes: e3a7ae2 be2net: Changing MAC Address of a VF was broken
    Cc: Sathya Perla <sathya.perla@broadcom.com>
    Cc: Ajit Khaparde <ajit.khaparde@broadcom.com>
    Cc: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
    Cc: Somnath Kotur <somnath.kotur@broadcom.com>
    Signed-off-by: Ivan Vecera <cera@cera.cz>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit d43e6fb4ac4abfe4ef7c102833ed02330ad701e0
Author: Arnd Bergmann <arnd@arndb.de>
Date:   Mon Jan 16 14:20:54 2017 +0100

    cpmac: remove hopeless #warning
    
    The #warning was present 10 years ago when the driver first got merged.
    As the platform is rather obsolete by now, it seems very unlikely that
    the warning will cause anyone to fix the code properly.
    
    kernelci.org reports the warning for every build in the meantime, so
    I think it's better to just turn it into a code comment to reduce
    noise.
    
    Signed-off-by: Arnd Bergmann <arnd@arndb.de>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 8ec3e8a192ba6f13be4522ee81227c792c86fb1a
Author: Masaru Nagai <masaru.nagai.vx@renesas.com>
Date:   Mon Jan 16 11:45:21 2017 +0100

    ravb: do not use zero-length alignment DMA descriptor
    
    Due to alignment requirements of the hardware transmissions are split into
    two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
    followed by a descriptor for rest of the packet.
    
    In the case of IP packets the first descriptor will never be zero due to
    the way that the stack aligns buffers for IP packets. However, for non-IP
    packets it may be zero.
    
    In that case it has been reported that timeouts occur, presumably because
    transmission stops at the first zero-length DMA descriptor and thus the
    packet is not transmitted. However, in my environment a BUG is triggered as
    follows:
    
    [   20.381417] ------------[ cut here ]------------
    [   20.386054] kernel BUG at lib/swiotlb.c:495!
    [   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [   20.395805] Modules linked in:
    [   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f #162
    [   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
    [   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
    [   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
    [   20.424625] LR is at map_single+0x4c/0x98
    [   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
    [   20.436019] sp : ffff80063a71f9b0
    [   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
    [   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
    [   20.449944] x25: 000000067abe2adc x24: 0000000000000000
    [   20.455252] x23: 0000000000200000 x22: 0000000000000001
    [   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
    [   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
    [   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
    [   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
    [   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
    [   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
    [   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
    [   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
    [   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
    [   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
    [   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
    [   20.518958]
    [   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
    [   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
    [   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
    [   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
    [   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
    [   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
    [   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
    [   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
    [   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
    [   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
    [   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
    [   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
    [   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
    [   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
    [   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
    [   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
    [   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
    [   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
    [   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
    [   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
    [   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
    [   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
    [   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
    [   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
    [   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
    [   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
    [   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
    [   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
    [   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
    [   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
    [   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
    [   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
    [   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    [   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
    [   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
    [   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
    [   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
    [   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
    [   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
    [   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
    [   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
    [   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
    [   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
    [   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
    [   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
    [   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
    [   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
    [   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
    [   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
    [   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
    [   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
    [   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
    [   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
    [   20.931867] Call trace:
    [   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
    [   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
    [   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
    [   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
    [   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
    [   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
    [   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
    [   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
    [   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
    [   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
    [   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
    [   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
    [   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
    [   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
    [   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
    [   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
    [   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
    [   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
    [   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
    [   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
    [   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
    [   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
    [   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
    [   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
    [   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
    [   21.094611] ---[ end trace 5bc544ad491f3814 ]---
    [   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
    [   21.105587] Kernel Offset: disabled
    [   21.109073] Memory Limit: none
    [   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt
    
    Fixes: 2f45d1902acf ("ravb: minimize TX data copying")
    Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
    Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
    Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 0d7f4f0594fc38531e37b94a73ea3ebcc9d9bc11
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Tue Nov 1 20:27:13 2016 +0000

    MAINTAINERS: update rmk's entries
    
    Update my entries in the MAINTAINERS file with the same email address
    for kernel work, and, now that the git tree is hosted on more suitable
    hardware, add git tree references where appropriate.
    
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

commit 8cf699ec849f4ca1413cea01289bd7d37dbcc626
Author: Eric Dumazet <edumazet@google.com>
Date:   Fri Jan 13 08:39:24 2017 -0800

    mlx4: do not call napi_schedule() without care
    
    Disable BH around the call to napi_schedule() to avoid following warning
    
    [   52.095499] NOHZ: local_softirq_pending 08
    [   52.421291] NOHZ: local_softirq_pending 08
    [   52.608313] NOHZ: local_softirq_pending 08
    
    Fixes: 8d59de8f7bb3 ("net/mlx4_en: Process all completions in RX rings after port goes up")
    Signed-off-by: Eric Dumazet <edumazet@google.com>
    Cc: Erez Shitrit <erezsh@mellanox.com>
    Cc: Eugenia Emantayev <eugenia@mellanox.com>
    Cc: Tariq Toukan <tariqt@mellanox.com>
    Acked-by: Tariq Toukan <tariqt@mellanox.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ee6ff743e3a4b697e8286054667d7e4e1b56510d
Author: Ulf Hansson <ulf.hansson@linaro.org>
Date:   Fri Jan 13 12:05:03 2017 +0100

    mmc: core: Restore parts of the polling policy when switch to HS/HS DDR
    
    Regressions for not being able to detect an eMMC HS DDR mode card has been
    reported for the sdhci-esdhc-imx driver, but potentially other sdhci
    variants may suffer from the similar problem.
    
    The commit e173f8911f09 ("mmc: core: Update CMD13 polling policy when
    switch to HS DDR mode"), is causing the problem. It seems that change moved
    one step to far, regarding changing the host's timing before polling for a
    busy card.
    
    To fix this, let's move back to the behaviour when the host's timing is
    updated after the polling, but before the switch status is fetched and
    validated.
    
    In cases when polling with CMD13, we keep validating the switch status at
    each attempt. However, to align with the other card busy detections
    mechanism, let's fetch and validate the switch status also after the host's
    timing is updated.
    
    Reported-by: Clemens Gruber <clemens.gruber@pqgruber.com>
    Reported-by: Gary Bisson <gary.bisson@boundarydevices.com>
    Fixes: e173f8911f09 ("mmc: core: Update CMD13 polling policy when switch..")
    Cc: Shawn Lin <shawn.lin@rock-chips.com>
    Cc: Dong Aisheng <aisheng.dong@nxp.com>
    Cc: Haibo Chen <haibo.chen@nxp.com>
    Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
    Tested-by: Clemens Gruber <clemens.gruber@pqgruber.com>
    Tested-by: Jagan Teki <jagan@amarulasolutions.com>
    Reviewed-by: Shawn Lin <shawn.lin@rock-chips.com>
    Tested-by: Haibo Chen <haibo.chen@nxp.com>
    Reviewed-by: Dong Aisheng <aisheng.dong@nxp.com>

commit 4205e4786d0b9fc3b4fec7b1910cf645a0468307
Author: Thomas Gleixner <tglx@linutronix.de>
Date:   Tue Jan 10 14:01:05 2017 +0100

    cpu/hotplug: Provide dynamic range for prepare stage
    
    Mathieu reported that the LTTNG modules are broken as of 4.10-rc1 due to
    the removal of the cpu hotplug notifiers.
    
    Usually I don't care much about out of tree modules, but LTTNG is widely
    used in distros. There are two ways to solve that:
    
    1) Reserve a hotplug state for LTTNG
    
    2) Add a dynamic range for the prepare states.
    
    While #1 is the simplest solution, #2 is the proper one as we can convert
    in tree users, which do not care about ordering, to the dynamic range as
    well.
    
    Add a dynamic range which allows LTTNG to request states in the prepare
    stage.
    
    Reported-and-tested-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Sebastian Sewior <bigeasy@linutronix.de>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701101353010.3401@nanos
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

commit 75f01a4c9cc291ff5cb28ca1216adb163b7a20ee
Author: Lance Richardson <lrichard@redhat.com>
Date:   Thu Jan 12 19:33:18 2017 -0500

    openvswitch: maintain correct checksum state in conntrack actions
    
    When executing conntrack actions on skbuffs with checksum mode
    CHECKSUM_COMPLETE, the checksum must be updated to account for
    header pushes and pulls. Otherwise we get "hw csum failure"
    logs similar to this (ICMP packet received on geneve tunnel
    via ixgbe NIC):
    
    [  405.740065] genev_sys_6081: hw csum failure
    [  405.740106] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G          I     4.10.0-rc3+ #1
    [  405.740108] Call Trace:
    [  405.740110]  <IRQ>
    [  405.740113]  dump_stack+0x63/0x87
    [  405.740116]  netdev_rx_csum_fault+0x3a/0x40
    [  405.740118]  __skb_checksum_complete+0xcf/0xe0
    [  405.740120]  nf_ip_checksum+0xc8/0xf0
    [  405.740124]  icmp_error+0x1de/0x351 [nf_conntrack_ipv4]
    [  405.740132]  nf_conntrack_in+0xe1/0x550 [nf_conntrack]
    [  405.740137]  ? find_bucket.isra.2+0x62/0x70 [openvswitch]
    [  405.740143]  __ovs_ct_lookup+0x95/0x980 [openvswitch]
    [  405.740145]  ? netif_rx_internal+0x44/0x110
    [  405.740149]  ovs_ct_execute+0x147/0x4b0 [openvswitch]
    [  405.740153]  do_execute_actions+0x22e/0xa70 [openvswitch]
    [  405.740157]  ovs_execute_actions+0x40/0x120 [openvswitch]
    [  405.740161]  ovs_dp_process_packet+0x84/0x120 [openvswitch]
    [  405.740166]  ovs_vport_receive+0x73/0xd0 [openvswitch]
    [  405.740168]  ? udp_rcv+0x1a/0x20
    [  405.740170]  ? ip_local_deliver_finish+0x93/0x1e0
    [  405.740172]  ? ip_local_deliver+0x6f/0xe0
    [  405.740174]  ? ip_rcv_finish+0x3a0/0x3a0
    [  405.740176]  ? ip_rcv_finish+0xdb/0x3a0
    [  405.740177]  ? ip_rcv+0x2a7/0x400
    [  405.740180]  ? __netif_receive_skb_core+0x970/0xa00
    [  405.740185]  netdev_frame_hook+0xd3/0x160 [openvswitch]
    [  405.740187]  __netif_receive_skb_core+0x1dc/0xa00
    [  405.740194]  ? ixgbe_clean_rx_irq+0x46d/0xa20 [ixgbe]
    [  405.740197]  __netif_receive_skb+0x18/0x60
    [  405.740199]  netif_receive_skb_internal+0x40/0xb0
    [  405.740201]  napi_gro_receive+0xcd/0x120
    [  405.740204]  gro_cell_poll+0x57/0x80 [geneve]
    [  405.740206]  net_rx_action+0x260/0x3c0
    [  405.740209]  __do_softirq+0xc9/0x28c
    [  405.740211]  irq_exit+0xd9/0xf0
    [  405.740213]  do_IRQ+0x51/0xd0
    [  405.740215]  common_interrupt+0x93/0x93
    
    Fixes: 7f8a436eaa2c ("openvswitch: Add conntrack action")
    Signed-off-by: Lance Richardson <lrichard@redhat.com>
    Acked-by: Pravin B Shelar <pshelar@ovn.org>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 602d9858f07c72eab64f5f00e2fae55f9902cfbe
Author: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Date:   Wed Jan 11 21:56:31 2017 +0300

    swiotlb: ensure that page-sized mappings are page-aligned
    
    Some drivers do depend on page mappings to be page aligned.
    
    Swiotlb already enforces such alignment for mappings greater than page,
    extend that to page-sized mappings as well.
    
    Without this fix, nvme hits BUG() in nvme_setup_prps(), because that routine
    assumes page-aligned mappings.
    
    Signed-off-by: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
    Reviewed-by: Christoph Hellwig <hch@lst.de>
    Reviewed-by: Sagi Grimberg <sagi@grimberg.me>
    Signed-off-by: Konrad Rzeszutek Wilk <konrad@kernel.org>

commit 52d7e48b86fc108e45a656d8e53e4237993c481d
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Tue Jan 10 02:28:26 2017 -0800

    rcu: Narrow early boot window of illegal synchronous grace periods
    
    The current preemptible RCU implementation goes through three phases
    during bootup.  In the first phase, there is only one CPU that is running
    with preemption disabled, so that a no-op is a synchronous grace period.
    In the second mid-boot phase, the scheduler is running, but RCU has
    not yet gotten its kthreads spawned (and, for expedited grace periods,
    workqueues are not yet running.  During this time, any attempt to do
    a synchronous grace period will hang the system (or complain bitterly,
    depending).  In the third and final phase, RCU is fully operational and
    everything works normally.
    
    This has been OK for some time, but there has recently been some
    synchronous grace periods showing up during the second mid-boot phase.
    This code worked "by accident" for awhile, but started failing as soon
    as expedited RCU grace periods switched over to workqueues in commit
    8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue").
    Note that the code was buggy even before this commit, as it was subject
    to failure on real-time systems that forced all expedited grace periods
    to run as normal grace periods (for example, using the rcu_normal ksysfs
    parameter).  The callchain from the failure case is as follows:
    
    early_amd_iommu_init()
    |-> acpi_put_table(ivrs_base);
    |-> acpi_tb_put_table(table_desc);
    |-> acpi_tb_invalidate_table(table_desc);
    |-> acpi_tb_release_table(...)
    |-> acpi_os_unmap_memory
    |-> acpi_os_unmap_iomem
    |-> acpi_os_map_cleanup
    |-> synchronize_rcu_expedited
    
    The kernel showing this callchain was built with CONFIG_PREEMPT_RCU=y,
    which caused the code to try using workqueues before they were
    initialized, which did not go well.
    
    This commit therefore reworks RCU to permit synchronous grace periods
    to proceed during this mid-boot phase.  This commit is therefore a
    fix to a regression introduced in v4.9, and is therefore being put
    forward post-merge-window in v4.10.
    
    This commit sets a flag from the existing rcu_scheduler_starting()
    function which causes all synchronous grace periods to take the expedited
    path.  The expedited path now checks this flag, using the requesting task
    to drive the expedited grace period forward during the mid-boot phase.
    Finally, this flag is updated by a core_initcall() function named
    rcu_exp_runtime_mode(), which causes the runtime codepaths to be used.
    
    Note that this arrangement assumes that tasks are not sent POSIX signals
    (or anything similar) from the time that the first task is spawned
    through core_initcall() time.
    
    Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
    Reported-by: "Zheng, Lv" <lv.zheng@intel.com>
    Reported-by: Borislav Petkov <bp@alien8.de>
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Tested-by: Stan Kain <stan.kain@gmail.com>
    Tested-by: Ivan <waffolz@hotmail.com>
    Tested-by: Emanuel Castelo <emanuel.castelo@gmail.com>
    Tested-by: Bruno Pesavento <bpesavento@infinito.it>
    Tested-by: Borislav Petkov <bp@suse.de>
    Tested-by: Frederic Bezies <fredbezies@gmail.com>
    Cc: <stable@vger.kernel.org> # 4.9.0-

commit f466ae66fa6a599f9a53b5f9bafea4b8cfffa7fb
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date:   Mon Jan 9 23:23:15 2017 -0800

    rcu: Remove cond_resched() from Tiny synchronize_sched()
    
    It is now legal to invoke synchronize_sched() at early boot, which causes
    Tiny RCU's synchronize_sched() to emit spurious splats.  This commit
    therefore removes the cond_resched() from Tiny RCU's synchronize_sched().
    
    Fixes: 8b355e3bc140 ("rcu: Drive expedited grace periods from workqueue")
    Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: <stable@vger.kernel.org> # 4.9.0-

commit c6180a6237174f481dc856ed6e890d8196b6f0fb
Author: Trond Myklebust <trond.myklebust@primarydata.com>
Date:   Fri Jan 13 13:31:32 2017 -0500

    NFSv4: Fix client recovery when server reboots multiple times
    
    If the server reboots multiple times, the client should rely on the
    server to tell it that it cannot reclaim state as per section 9.6.3.4
    in RFC7530 and section 8.4.2.1 in RFC5661.
    Currently, the client is being to conservative, and is assuming that
    if the server reboots while state recovery is in progress, then it must
    ignore state that was not recovered before the reboot.
    
    Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>

commit 003c941057eaa868ca6fedd29a274c863167230d
Author: Shannon Nelson <shannon.nelson@oracle.com>
Date:   Thu Jan 12 14:24:58 2017 -0800

    tcp: fix tcp_fastopen unaligned access complaints on sparc
    
    Fix up a data alignment issue on sparc by swapping the order
    of the cookie byte array field with the length field in
    struct tcp_fastopen_cookie, and making it a proper union
    to clean up the typecasting.
    
    This addresses log complaints like these:
        log_unaligned: 113 callbacks suppressed
        Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
        Kernel unaligned access at TPC[9764ac] tcp_try_fastopen+0x2ec/0x360
        Kernel unaligned access at TPC[9764c8] tcp_try_fastopen+0x308/0x360
        Kernel unaligned access at TPC[9764e4] tcp_try_fastopen+0x324/0x360
        Kernel unaligned access at TPC[976490] tcp_try_fastopen+0x2d0/0x360
    
    Cc: Eric Dumazet <eric.dumazet@gmail.com>
    Signed-off-by: Shannon Nelson <shannon.nelson@oracle.com>
    Acked-by: Eric Dumazet <edumazet@google.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit fa79581ea66ca43d56ef065346ac5be767fcb418
Author: David Lebrun <david.lebrun@uclouvain.be>
Date:   Thu Jan 12 21:30:01 2017 +0100

    ipv6: sr: fix several BUGs when preemption is enabled
    
    When CONFIG_PREEMPT=y, CONFIG_IPV6=m and CONFIG_SEG6_HMAC=y,
    seg6_hmac_init() is called during the initialization of the ipv6 module.
    This causes a subsequent call to smp_processor_id() with preemption
    enabled, resulting in the following trace.
    
    [   20.451460] BUG: using smp_processor_id() in preemptible [00000000] code: systemd/1
    [   20.452556] caller is debug_smp_processor_id+0x17/0x19
    [   20.453304] CPU: 0 PID: 1 Comm: systemd Not tainted 4.9.0-rc5-00973-g46738b1 #1
    [   20.454406]  ffffc9000062fc18 ffffffff813607b2 0000000000000000 ffffffff81a7f782
    [   20.455528]  ffffc9000062fc48 ffffffff813778dc 0000000000000000 00000000001dcf98
    [   20.456539]  ffffffffa003bd08 ffffffff81af93e0 ffffc9000062fc58 ffffffff81377905
    [   20.456539] Call Trace:
    [   20.456539]  [<ffffffff813607b2>] dump_stack+0x63/0x7f
    [   20.456539]  [<ffffffff813778dc>] check_preemption_disabled+0xd1/0xe3
    [   20.456539]  [<ffffffff81377905>] debug_smp_processor_id+0x17/0x19
    [   20.460260]  [<ffffffffa0061f3b>] seg6_hmac_init+0xfa/0x192 [ipv6]
    [   20.460260]  [<ffffffffa0061ccc>] seg6_init+0x39/0x6f [ipv6]
    [   20.460260]  [<ffffffffa006121a>] inet6_init+0x21a/0x321 [ipv6]
    [   20.460260]  [<ffffffffa0061000>] ? 0xffffffffa0061000
    [   20.460260]  [<ffffffff81000457>] do_one_initcall+0x8b/0x115
    [   20.460260]  [<ffffffff811328a3>] do_init_module+0x53/0x1c4
    [   20.460260]  [<ffffffff8110650a>] load_module+0x1153/0x14ec
    [   20.460260]  [<ffffffff81106a7b>] SYSC_finit_module+0x8c/0xb9
    [   20.460260]  [<ffffffff81106a7b>] ? SYSC_finit_module+0x8c/0xb9
    [   20.460260]  [<ffffffff81106abc>] SyS_finit_module+0x9/0xb
    [   20.460260]  [<ffffffff810014d1>] do_syscall_64+0x62/0x75
    [   20.460260]  [<ffffffff816834f0>] entry_SYSCALL64_slow_path+0x25/0x25
    
    Moreover, dst_cache_* functions also call smp_processor_id(), generating
    a similar trace.
    
    This patch uses raw_cpu_ptr() in seg6_hmac_init() rather than this_cpu_ptr()
    and disable preemption when using dst_cache_* functions.
    
    Signed-off-by: David Lebrun <david.lebrun@uclouvain.be>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit 148d3d021cf9724fcf189ce4e525a094bbf5ce89
Author: Florian Fainelli <f.fainelli@gmail.com>
Date:   Thu Jan 12 12:09:09 2017 -0800

    net: systemport: Decouple flow control from __bcm_sysport_tx_reclaim
    
    The __bcm_sysport_tx_reclaim() function is used to reclaim transmit
    resources in different places within the driver. Most of them should
    not affect the state of the transit flow control.
    
    Introduce bcm_sysport_tx_clean() which cleans the ring, but does not
    re-enable flow control towards the networking stack, and make
    bcm_sysport_tx_reclaim() do the actual transmit queue flow control.
    
    Fixes: 80105befdb4b ("net: systemport: add Broadcom SYSTEMPORT Ethernet MAC driver")
    Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ed79c9d34f4f4c5842b66cab840315e7ac29f666
Author: Nicolas Dichtel <nicolas.dichtel@6wind.com>
Date:   Fri Jan 13 11:46:39 2017 +0100

    ARM: put types.h in uapi
    
    Due to the way kbuild works, this header was unintentionally exported
    back in 2013 when it was created, despite it not being in a uapi/
    directory.  This is very non-intuitive behaviour by Kbuild.
    
    However, we've had this include exported to userland for almost four
    years, and searching google for "ARM types.h __UINTPTR_TYPE__" gives
    no hint that anyone has complained about it.  So, let's make it
    officially exported in this state.
    
    Signed-off-by: Nicolas Dichtel <nicolas.dichtel@6wind.com>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>

commit dbef53621116474bb883f76f0ba6b7640bc42332
Author: Michal Kazior <michal.kazior@tieto.com>
Date:   Fri Jan 13 13:32:51 2017 +0100

    mac80211: prevent skb/txq mismatch
    
    Station structure is considered as not uploaded
    (to driver) until drv_sta_state() finishes. This
    call is however done after the structure is
    attached to mac80211 internal lists and hashes.
    This means mac80211 can lookup (and use) station
    structure before it is uploaded to a driver.
    
    If this happens (structure exists, but
    sta->uploaded is false) fast_tx path can still be
    taken. Deep in the fastpath call the sta->uploaded
    is checked against to derive "pubsta" argument for
    ieee80211_get_txq(). If sta->uploaded is false
    (and sta is actually non-NULL) ieee80211_get_txq()
    effectively downgraded to vif->txq.
    
    At first glance this may look innocent but coerces
    mac80211 into a state that is almost guaranteed
    (codel may drop offending skb) to crash because a
    station-oriented skb gets queued up on
    vif-oriented txq. The ieee80211_tx_dequeue() ends
    up looking at info->control.flags and tries to use
    txq->sta which in the fail case is NULL.
    
    It's probably pointless to pretend one can
    downgrade skb from sta-txq to vif-txq.
    
    Since downgrading unicast traffic to vif->txq must
    not be done there's no txq to put a frame on if
    sta->uploaded is false. Therefore the code is made
    to fall back to regular tx() op path if the
    described condition is hit.
    
    Only drivers using wake_tx_queue were affected.
    
    Example crash dump before fix:
    
     Unable to handle kernel paging request at virtual address ffffe26c
     PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
     [<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
     [<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
     [<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
     [<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
     [<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
     [<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
     [<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
     [<c0572e90>] (net_rx_action+0xac/0x160)
    
    Reported-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
    Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit 43071d8fb3b7f589d72663c496a6880fb097533c
Author: Felix Fietkau <nbd@nbd.name>
Date:   Fri Jan 13 11:28:25 2017 +0100

    mac80211: initialize SMPS field in HT capabilities
    
    ibss and mesh modes copy the ht capabilites from the band without
    overriding the SMPS state. Unfortunately the default value 0 for the
    SMPS field means static SMPS instead of disabled.
    
    This results in HT ibss and mesh setups using only single-stream rates,
    even though SMPS is not supposed to be active.
    
    Initialize SMPS to disabled for all bands on ieee80211_hw_register to
    ensure that the value is sane where it is not overriden with the real
    SMPS state.
    
    Reported-by: Elektra Wagenrad <onelektra@gmx.net>
    Signed-off-by: Felix Fietkau <nbd@nbd.name>
    [move VHT TODO comment to a better place]
    Signed-off-by: Johannes Berg <johannes.berg@intel.com>

commit 7aa4865506a26c607e00bd9794a85785b55ebca7
Author: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
Date:   Thu Jan 12 07:28:06 2017 -0800

    net: thunderx: acpi: fix LMAC initialization
    
    While probing BGX we requesting appropriate QLM for it's configuration
    and get LMAC count by that request. Then, while reading configured
    MAC values from SSDT table we need to save them in proper mapping:
      BGX[i]->lmac[j].mac = <MAC value>
    to later provide for initialization stuff. In order to fill
    such mapping properly we need to add lmac index to be used while
    acpi initialization since at this moment bgx->lmac_count already contains
    actual value.
    
    Signed-off-by: Vadim Lomovtsev <Vadim.Lomovtsev@caviumnetworks.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ce1ca7d2d140a1f4aaffd297ac487f246963dd2f
Author: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Date:   Mon Jan 9 16:00:44 2017 +0530

    svcrdma: avoid duplicate dma unmapping during error recovery
    
    In rdma_read_chunk_frmr() when ib_post_send() fails, the error code path
    invokes ib_dma_unmap_sg() to unmap the sg list. It then invokes
    svc_rdma_put_frmr() which in turn tries to unmap the same sg list through
    ib_dma_unmap_sg() again. This second unmap is invalid and could lead to
    problems when the iova being unmapped is subsequently reused. Remove
    the call to unmap in rdma_read_chunk_frmr() and let svc_rdma_put_frmr()
    handle it.
    
    Fixes: 412a15c0fe53 ("svcrdma: Port to new memory registration API")
    Cc: stable@vger.kernel.org
    Signed-off-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
    Reviewed-by: Chuck Lever <chuck.lever@oracle.com>
    Reviewed-by: Yuval Shaia <yuval.shaia@oracle.com>
    Signed-off-by: J. Bruce Fields <bfields@redhat.com>

commit 8e38b7d4d71479b23b77f01cf0e5071610b8f357
Author: Stefan Schmidt <stefan@osg.samsung.com>
Date:   Mon Jan 2 16:58:13 2017…
Noltari pushed a commit to Noltari/linux that referenced this pull request Feb 4, 2017
[ Upstream commit 8ec3e8a ]

Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.

In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.

In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] ------------[ cut here ]------------
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f torvalds#162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[   20.436019] sp : ffff80063a71f9b0
[   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[   20.449944] x25: 000000067abe2adc x24: 0000000000000000
[   20.455252] x23: 0000000000200000 x22: 0000000000000001
[   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
[   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[   20.931867] Call trace:
[   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[   21.094611] ---[ end trace 5bc544ad491f3814 ]---
[   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[   21.105587] Kernel Offset: disabled
[   21.109073] Memory Limit: none
[   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 2f45d19 ("ravb: minimize TX data copying")
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Noltari pushed a commit to Noltari/linux that referenced this pull request Feb 4, 2017
[ Upstream commit 8ec3e8a ]

Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.

In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.

In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] ------------[ cut here ]------------
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f torvalds#162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[   20.436019] sp : ffff80063a71f9b0
[   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[   20.449944] x25: 000000067abe2adc x24: 0000000000000000
[   20.455252] x23: 0000000000200000 x22: 0000000000000001
[   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
[   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[   20.931867] Call trace:
[   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[   21.094611] ---[ end trace 5bc544ad491f3814 ]---
[   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[   21.105587] Kernel Offset: disabled
[   21.109073] Memory Limit: none
[   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 2f45d19 ("ravb: minimize TX data copying")
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017
lkl: Add a debug utility to access LKL file system.
@nhubbard nhubbard closed this May 11, 2017
bgly pushed a commit to powervm/ibmvscsis that referenced this pull request Aug 18, 2017
BugLink: http://bugs.launchpad.net/bugs/1662507

[ Upstream commit 8ec3e8a ]

Due to alignment requirements of the hardware transmissions are split into
two DMA descriptors, a small padding descriptor of 0 - 3 bytes in length
followed by a descriptor for rest of the packet.

In the case of IP packets the first descriptor will never be zero due to
the way that the stack aligns buffers for IP packets. However, for non-IP
packets it may be zero.

In that case it has been reported that timeouts occur, presumably because
transmission stops at the first zero-length DMA descriptor and thus the
packet is not transmitted. However, in my environment a BUG is triggered as
follows:

[   20.381417] ------------[ cut here ]------------
[   20.386054] kernel BUG at lib/swiotlb.c:495!
[   20.390324] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[   20.395805] Modules linked in:
[   20.398862] CPU: 0 PID: 2089 Comm: mz Not tainted 4.10.0-rc3-00001-gf13ad2db193f torvalds#162
[   20.406689] Hardware name: Renesas Salvator-X board based on r8a7796 (DT)
[   20.413474] task: ffff80063b1f1900 task.stack: ffff80063a71c000
[   20.419404] PC is at swiotlb_tbl_map_single+0x178/0x2ec
[   20.424625] LR is at map_single+0x4c/0x98
[   20.428629] pc : [<ffff00000839c4c0>] lr : [<ffff00000839c680>] pstate: 800001c5
[   20.436019] sp : ffff80063a71f9b0
[   20.439327] x29: ffff80063a71f9b0 x28: ffff80063a20d500
[   20.444636] x27: ffff000008ed5000 x26: 0000000000000000
[   20.449944] x25: 000000067abe2adc x24: 0000000000000000
[   20.455252] x23: 0000000000200000 x22: 0000000000000001
[   20.460559] x21: 0000000000175ffe x20: ffff80063b2a0010
[   20.465866] x19: 0000000000000000 x18: 0000ffffcae6fb20
[   20.471173] x17: 0000ffffa09ba018 x16: ffff0000087c8b70
[   20.476480] x15: 0000ffffa084f588 x14: 0000ffffa09cfa14
[   20.481787] x13: 0000ffffcae87ff0 x12: 000000000063abe2
[   20.487098] x11: ffff000008096360 x10: ffff80063abe2adc
[   20.492407] x9 : 0000000000000000 x8 : 0000000000000000
[   20.497718] x7 : 0000000000000000 x6 : ffff000008ed50d0
[   20.503028] x5 : 0000000000000000 x4 : 0000000000000001
[   20.508338] x3 : 0000000000000000 x2 : 000000067abe2adc
[   20.513648] x1 : 00000000bafff000 x0 : 0000000000000000
[   20.518958]
[   20.520446] Process mz (pid: 2089, stack limit = 0xffff80063a71c000)
[   20.526798] Stack: (0xffff80063a71f9b0 to 0xffff80063a720000)
[   20.532543] f9a0:                                   ffff80063a71fa30 ffff00000839c680
[   20.540374] f9c0: ffff80063b2a0010 ffff80063b2a0010 0000000000000001 0000000000000000
[   20.548204] f9e0: 000000000000006e ffff80063b23c000 ffff80063b23c000 0000000000000000
[   20.556034] fa00: ffff80063b23c000 ffff80063a20d500 000000013b1f1900 0000000000000000
[   20.563864] fa20: ffff80063ffd18e0 ffff80063b2a0010 ffff80063a71fa60 ffff00000839cd10
[   20.571694] fa40: ffff80063b2a0010 0000000000000000 ffff80063ffd18e0 000000067abe2adc
[   20.579524] fa60: ffff80063a71fa90 ffff000008096380 ffff80063b2a0010 0000000000000000
[   20.587353] fa80: 0000000000000000 0000000000000001 ffff80063a71fac0 ffff00000864f770
[   20.595184] faa0: ffff80063b23caf0 0000000000000000 0000000000000000 0000000000000140
[   20.603014] fac0: ffff80063a71fb60 ffff0000087e6498 ffff80063a20d500 ffff80063b23c000
[   20.610843] fae0: 0000000000000000 ffff000008daeaf0 0000000000000000 ffff000008daeb00
[   20.618673] fb00: ffff80063a71fc0c ffff000008da7000 ffff80063b23c090 ffff80063a44f000
[   20.626503] fb20: 0000000000000000 ffff000008daeb00 ffff80063a71fc0c ffff000008da7000
[   20.634333] fb40: ffff80063b23c090 0000000000000000 ffff800600000037 ffff0000087e63d8
[   20.642163] fb60: ffff80063a71fbc0 ffff000008807510 ffff80063a692400 ffff80063a20d500
[   20.649993] fb80: ffff80063a44f000 ffff80063b23c000 ffff80063a69249c 0000000000000000
[   20.657823] fba0: 0000000000000000 ffff80063a087800 ffff80063b23c000 ffff80063a20d500
[   20.665653] fbc0: ffff80063a71fc10 ffff0000087e67dc ffff80063a20d500 ffff80063a692400
[   20.673483] fbe0: ffff80063b23c000 0000000000000000 ffff80063a44f000 ffff80063a69249c
[   20.681312] fc00: ffff80063a5f1a10 000000103a087800 ffff80063a71fc70 ffff0000087e6b24
[   20.689142] fc20: ffff80063a5f1a80 ffff80063a71fde8 000000000000000f 00000000000005ea
[   20.696972] fc40: ffff80063a5f1a10 0000000000000000 000000000000000f ffff00000887fbd0
[   20.704802] fc60: fffffff43a5f1a80 0000000000000000 ffff80063a71fc80 ffff000008880240
[   20.712632] fc80: ffff80063a71fd90 ffff0000087c7a34 ffff80063afc7180 0000000000000000
[   20.720462] fca0: 0000ffffcae6fe18 0000000000000014 0000000060000000 0000000000000015
[   20.728292] fcc0: 0000000000000123 00000000000000ce ffff0000088d2000 ffff80063b1f1900
[   20.736122] fce0: 0000000000008933 ffff000008e7cb80 ffff80063a71fd80 ffff0000087c50a4
[   20.743951] fd00: 0000000000008933 ffff000008e7cb80 ffff000008e7cb80 000000100000000e
[   20.751781] fd20: ffff80063a71fe4c 0000ffff00000300 0000000000000123 0000000000000000
[   20.759611] fd40: 0000000000000000 ffff80063b1f0000 000000000000000e 0000000000000300
[   20.767441] fd60: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[   20.775271] fd80: 0000000000000000 0000000000000000 ffff80063a71fda0 ffff0000087c8c20
[   20.783100] fda0: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.790930] fdc0: ffffffffffffffff 0000ffffa0903078 0000000000000000 000000001ea87232
[   20.798760] fde0: 000000000000000f ffff80063a71fe40 ffff800600000014 ffff000000000001
[   20.806590] fe00: 0000000000000000 0000000000000000 ffff80063a71fde8 0000000000000000
[   20.814420] fe20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
[   20.822249] fe40: 0000000203000011 0000000000000000 0000000000000000 ffff80063a68aa00
[   20.830079] fe60: ffff80063a68aa00 0000000000000003 0000000000008933 ffff0000081f1b9c
[   20.837909] fe80: 0000000000000000 ffff000008082f30 0000000000000000 0000800637260000
[   20.845739] fea0: ffffffffffffffff 0000ffffa07ca81c 0000000060000000 0000000000000015
[   20.853569] fec0: 0000000000000003 000000001ea87232 000000000000000f 0000000000000000
[   20.861399] fee0: 0000ffffcae6fe18 0000000000000014 0000000000000300 0000000000000000
[   20.869228] ff00: 00000000000000ce 0000000000000000 00000000ffffffff 0000000000000000
[   20.877059] ff20: 0000000000000002 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   20.884888] ff40: 0000000000000000 0000ffffa09ba018 0000ffffcae6fb20 000000001ea87010
[   20.892718] ff60: 0000ffffa09b9000 0000ffffcae6fe30 0000ffffcae6fe18 000000000000000f
[   20.900548] ff80: 0000000000000003 000000001ea87232 0000000000000000 0000000000000000
[   20.908378] ffa0: 0000000000000000 0000ffffcae6fdc0 0000ffffa09a7824 0000ffffcae6fdc0
[   20.916208] ffc0: 0000ffffa0903078 0000000060000000 0000000000000003 00000000000000ce
[   20.924038] ffe0: 0000000000000000 0000000000000000 ffffffffffffffff ffffffffffffffff
[   20.931867] Call trace:
[   20.934312] Exception stack(0xffff80063a71f7e0 to 0xffff80063a71f910)
[   20.940750] f7e0: 0000000000000000 0001000000000000 ffff80063a71f9b0 ffff00000839c4c0
[   20.948580] f800: ffff80063a71f840 ffff00000888a6e4 ffff80063a24c418 ffff80063a24c448
[   20.956410] f820: 0000000000000000 ffff00000811cd54 ffff80063a71f860 ffff80063a24c458
[   20.964240] f840: ffff80063a71f870 ffff00000888b258 ffff80063a24c418 0000000000000001
[   20.972070] f860: ffff80063a71f910 ffff80063a7b7028 ffff80063a71f890 ffff0000088825e4
[   20.979899] f880: 0000000000000000 00000000bafff000 000000067abe2adc 0000000000000000
[   20.987729] f8a0: 0000000000000001 0000000000000000 ffff000008ed50d0 0000000000000000
[   20.995560] f8c0: 0000000000000000 0000000000000000 ffff80063abe2adc ffff000008096360
[   21.003390] f8e0: 000000000063abe2 0000ffffcae87ff0 0000ffffa09cfa14 0000ffffa084f588
[   21.011219] f900: ffff0000087c8b70 0000ffffa09ba018
[   21.016097] [<ffff00000839c4c0>] swiotlb_tbl_map_single+0x178/0x2ec
[   21.022362] [<ffff00000839c680>] map_single+0x4c/0x98
[   21.027411] [<ffff00000839cd10>] swiotlb_map_page+0xa4/0x138
[   21.033072] [<ffff000008096380>] __swiotlb_map_page+0x20/0x7c
[   21.038821] [<ffff00000864f770>] ravb_start_xmit+0x174/0x668
[   21.044484] [<ffff0000087e6498>] dev_hard_start_xmit+0x8c/0x120
[   21.050407] [<ffff000008807510>] sch_direct_xmit+0x108/0x1a0
[   21.056064] [<ffff0000087e67dc>] __dev_queue_xmit+0x194/0x4cc
[   21.061807] [<ffff0000087e6b24>] dev_queue_xmit+0x10/0x18
[   21.067214] [<ffff000008880240>] packet_sendmsg+0xf40/0x1220
[   21.072873] [<ffff0000087c7a34>] sock_sendmsg+0x18/0x2c
[   21.078097] [<ffff0000087c8c20>] SyS_sendto+0xb0/0xf0
[   21.083150] [<ffff000008082f30>] el0_svc_naked+0x24/0x28
[   21.088462] Code: d34bfef7 2a1803f3 1a9f86d6 35fff878 (d4210000)
[   21.094611] ---[ end trace 5bc544ad491f3814 ]---
[   21.099234] Kernel panic - not syncing: Fatal exception in interrupt
[   21.105587] Kernel Offset: disabled
[   21.109073] Memory Limit: none
[   21.112126] ---[ end Kernel panic - not syncing: Fatal exception in interrupt

Fixes: 2f45d19 ("ravb: minimize TX data copying")
Signed-off-by: Masaru Nagai <masaru.nagai.vx@renesas.com
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@canonical.com>
mrchapp pushed a commit to mrchapp/linux that referenced this pull request May 29, 2019
…lock

Lockdep debug reported lock inversion related with the iommu code
caused by dmar_insert_one_dev_info() grabbing the iommu->lock and
the device_domain_lock out of order versus the code path in
iommu_flush_dev_iotlb(). Expanding the scope of the iommu->lock and
reversing the order of lock acquisition fixes the issue.

[   76.238180] dsa_bus wq0.0: dsa wq wq0.0 disabled
[   76.248706]
[   76.250486] ========================================================
[   76.257113] WARNING: possible irq lock inversion dependency detected
[   76.263736] 5.1.0-rc5+ torvalds#162 Not tainted
[   76.267854] --------------------------------------------------------
[   76.274485] systemd-journal/521 just changed the state of lock:
[   76.280685] 0000000055b330f5 (device_domain_lock){..-.}, at: iommu_flush_dev_iotlb.part.63+0x29/0x90
[   76.290099] but this lock took another, SOFTIRQ-unsafe lock in the past:
[   76.297093]  (&(&iommu->lock)->rlock){+.+.}
[   76.297094]
[   76.297094]
[   76.297094] and interrupts could create inverse lock ordering between them.
[   76.297094]
[   76.314257]
[   76.314257] other info that might help us debug this:
[   76.321448]  Possible interrupt unsafe locking scenario:
[   76.321448]
[   76.328907]        CPU0                    CPU1
[   76.333777]        ----                    ----
[   76.338642]   lock(&(&iommu->lock)->rlock);
[   76.343165]                                local_irq_disable();
[   76.349422]                                lock(device_domain_lock);
[   76.356116]                                lock(&(&iommu->lock)->rlock);
[   76.363154]   <Interrupt>
[   76.366134]     lock(device_domain_lock);
[   76.370548]
[   76.370548]  *** DEADLOCK ***

Fixes: 745f258 ("iommu/vt-d: Simplify function get_domain_for_dev()")
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
gs0622 pushed a commit to gs0622/linux that referenced this pull request Jun 25, 2019
…lock

Lockdep debug reported lock inversion related with the iommu code
caused by dmar_insert_one_dev_info() grabbing the iommu->lock and
the device_domain_lock out of order versus the code path in
iommu_flush_dev_iotlb(). Expanding the scope of the iommu->lock and
reversing the order of lock acquisition fixes the issue.

[   76.238180] dsa_bus wq0.0: dsa wq wq0.0 disabled
[   76.248706]
[   76.250486] ========================================================
[   76.257113] WARNING: possible irq lock inversion dependency detected
[   76.263736] 5.1.0-rc5+ torvalds#162 Not tainted
[   76.267854] --------------------------------------------------------
[   76.274485] systemd-journal/521 just changed the state of lock:
[   76.280685] 0000000055b330f5 (device_domain_lock){..-.}, at: iommu_flush_dev_iotlb.part.63+0x29/0x90
[   76.290099] but this lock took another, SOFTIRQ-unsafe lock in the past:
[   76.297093]  (&(&iommu->lock)->rlock){+.+.}
[   76.297094]
[   76.297094]
[   76.297094] and interrupts could create inverse lock ordering between them.
[   76.297094]
[   76.314257]
[   76.314257] other info that might help us debug this:
[   76.321448]  Possible interrupt unsafe locking scenario:
[   76.321448]
[   76.328907]        CPU0                    CPU1
[   76.333777]        ----                    ----
[   76.338642]   lock(&(&iommu->lock)->rlock);
[   76.343165]                                local_irq_disable();
[   76.349422]                                lock(device_domain_lock);
[   76.356116]                                lock(&(&iommu->lock)->rlock);
[   76.363154]   <Interrupt>
[   76.366134]     lock(device_domain_lock);
[   76.370548]
[   76.370548]  *** DEADLOCK ***

Fixes: 745f258 ("iommu/vt-d: Simplify function get_domain_for_dev()")
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Oct 13, 2019
The aim of this patch is to correct a recursive locking warning,
detected when setting CONFIG_PROVE_LOCKING flag (as shown in message below).
This message was initially triggered by the following call sequence
in stm32-dfsdm-adc.c driver, when using IIO hardware consumer interface.

in stm32_dfsdm_read_raw()
	iio_device_claim_direct_mode
		mutex_lock(&indio_dev->mlock);			-> lock on dfsdm device
	iio_hw_consumer_enable
		iio_update_buffers
			mutex_lock(&indio_dev->mlock);		-> lock on hw consumer device

Here two instances of the same lock class are requested
on two different objects.
The locking validator needs to be informed of the nesting level
of each lock to avoid a false positive.

This patch introduces a class hierarchy in iio device lock,
assuming that hardware consumer is at a lower level than iio device.

[   52.086174]
[   52.086223] ============================================
[   52.091516] WARNING: possible recursive locking detected
[   52.096825] 4.19.49 torvalds#162 Not tainted
[   52.100384] --------------------------------------------
[   52.105691] cat/823 is trying to acquire lock:
[   52.110132] 37acb703 (&dev->mlock){+.+.}, at: iio_update_buffers+0x3c/0xd0
[   52.116995]
[   52.116995] but task is already holding lock:
[   52.122821] 368bb908 (&dev->mlock){+.+.}, at: iio_device_claim_direct_mode+0x18/0x34
[   52.130560]
[   52.130560] other info that might help us debug this:
[   52.137083]  Possible unsafe locking scenario:
[   52.137083]
[   52.142995]        CPU0
[   52.145430]        ----
[   52.147864]   lock(&dev->mlock);
[   52.151082]   lock(&dev->mlock);
[   52.154301]
[   52.154301]  * DEADLOCK *
[   52.154301]
[   52.160215]  May be due to missing lock nesting notation
[   52.160215]
[   52.167000] 5 locks held by cat/823:
[   52.170563]  #0: 96d6554b (&p->lock){+.+.}, at: seq_read+0x34/0x51c
[   52.176824]  #1: 3cf6739a (&of->mutex){+.+.}, at: kernfs_seq_start+0x1c/0x8c
[   52.183866]  #2: a6090e0a (kn->count#29){.+.+}, at: kernfs_seq_start+0x24/0x8c
[   52.191083]  #3: 368bb908 (&dev->mlock){+.+.}, at: iio_device_claim_direct_mode+0x18/0x34
[   52.199257]  #4: 77e2bcfe (&dev->info_exist_lock){+.+.}, at: iio_update_buffers+0x30/0xd0
[   52.207431]
[   52.207431] stack backtrace:
[   52.211787] CPU: 0 PID: 823 Comm: cat Not tainted 4.19.49 torvalds#162
[   52.217606] Hardware name: STM32 (Device Tree Support)
[   52.222756] [<c0112420>] (unwind_backtrace) from [<c010df5c>] (show_stack+0x10/0x14)
[   52.230487] [<c010df5c>] (show_stack) from [<c0af5c88>] (dump_stack+0xc4/0xf0)
[   52.237703] [<c0af5c88>] (dump_stack) from [<c01865bc>] (__lock_acquire+0x874/0x1344)
[   52.245525] [<c01865bc>] (__lock_acquire) from [<c0187be8>] (lock_acquire+0xd8/0x268)
[   52.253353] [<c0187be8>] (lock_acquire) from [<c0b0dcf8>] (__mutex_lock+0x70/0xab0)
[   52.261005] [<c0b0dcf8>] (__mutex_lock) from [<c0b0e754>] (mutex_lock_nested+0x1c/0x24)
[   52.269001] [<c0b0e754>] (mutex_lock_nested) from [<c09282b8>] (iio_update_buffers+0x3c/0xd0)
[   52.277523] [<c09282b8>] (iio_update_buffers) from [<c09329cc>] (iio_hw_consumer_enable+0x34/0x70)
[   52.286476] [<c09329cc>] (iio_hw_consumer_enable) from [<c0932134>] (stm32_dfsdm_read_raw+0xf4/0x3fc)
[   52.295695] [<c0932134>] (stm32_dfsdm_read_raw) from [<c0922eb4>] (iio_read_channel_info+0xa8/0xb0)
[   52.304738] [<c0922eb4>] (iio_read_channel_info) from [<c067a7fc>] (dev_attr_show+0x1c/0x48)
[   52.313170] [<c067a7fc>] (dev_attr_show) from [<c03724a4>] (sysfs_kf_seq_show+0x84/0xec)
[   52.321256] [<c03724a4>] (sysfs_kf_seq_show) from [<c0312afc>] (seq_read+0x154/0x51c)
[   52.329082] [<c0312afc>] (seq_read) from [<c02e7a00>] (__vfs_read+0x2c/0x15c)
[   52.336209] [<c02e7a00>] (__vfs_read) from [<c02e7bc0>] (vfs_read+0x90/0x15c)
[   52.343339] [<c02e7bc0>] (vfs_read) from [<c02e81ac>] (ksys_read+0x5c/0xdc)
[   52.350296] [<c02e81ac>] (ksys_read) from [<c0101000>] (ret_fast_syscall+0x0/0x28)
[   52.357852] Exception stack(0xe5761fa8 to 0xe5761ff0)
[   52.362904] 1fa0:                   0000006c 7ff00000 00000003 b6e06000 00020000 00000000
[   52.371077] 1fc0: 0000006c 7ff00000 00020000 00000003 00000003 00000000 00020000 00000000
[   52.379245] 1fe0: 00000003 beb6e790 b6eb17b7 b6e3e6c6

Signed-off-by: Olivier Moysan <olivier.moysan@st.com>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 23, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 23, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 23, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 23, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 23, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 23, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 23, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 23, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 24, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 25, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 25, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 25, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 25, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 25, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 25, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Aug 25, 2022
[ Upstream commit 0fe6ee8 ]

2d186af ("profiling: fix shift-out-of-bounds bugs") limits shift
value by [0, BITS_PER_LONG -1], which means [0, 63].

However, syzbot found that the max shift value should be the bit number of
(_etext - _stext).  If shift is outside of this, the "buffer_bytes" will
be zero and will cause kzalloc(0).  Then the kernel panics due to
dereferencing the returned pointer 16.

This can be easily reproduced by passing a large number like 60 to enable
profiling and then run readprofile.

LOGS:
 BUG: kernel NULL pointer dereference, address: 0000000000000010
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD 6148067 P4D 6148067 PUD 6142067 PMD 0
 PREEMPT SMP
 CPU: 4 PID: 184 Comm: readprofile Not tainted 5.18.0+ torvalds#162
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
 RIP: 0010:read_profile+0x104/0x220
 RSP: 0018:ffffc900006fbe80 EFLAGS: 00000202
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
 RDX: ffff888006150000 RSI: 0000000000000001 RDI: ffffffff82aba4a0
 RBP: 000000000188bb60 R08: 0000000000000010 R09: ffff888006151000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82aba4a0
 R13: 0000000000000000 R14: ffffc900006fbf08 R15: 0000000000020c30
 FS:  000000000188a8c0(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000010 CR3: 0000000006144000 CR4: 00000000000006e0
 Call Trace:
  <TASK>
  proc_reg_read+0x56/0x70
  vfs_read+0x9a/0x1b0
  ksys_read+0xa1/0xe0
  ? fpregs_assert_state_consistent+0x1e/0x40
  do_syscall_64+0x3a/0x80
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x4d4b4e
 RSP: 002b:00007ffebb668d58 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
 RAX: ffffffffffffffda RBX: 000000000188a8a0 RCX: 00000000004d4b4e
 RDX: 0000000000000400 RSI: 000000000188bb60 RDI: 0000000000000003
 RBP: 0000000000000003 R08: 000000000000006e R09: 0000000000000000
 R10: 0000000000000041 R11: 0000000000000246 R12: 000000000188bb60
 R13: 0000000000000400 R14: 0000000000000000 R15: 000000000188bb60
  </TASK>
 Modules linked in:
 CR2: 0000000000000010
Killed
 ---[ end trace 0000000000000000 ]---

Check prof_len in profile_init() to prevent it be zero.

Link: https://lkml.kernel.org/r/20220531012854.229439-1-chenzhongjin@huawei.com
Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
mj22226 pushed a commit to mj22226/linux that referenced this pull request Jul 30, 2023
Update for ROCK 3A:
  * Add WiFi
  * Add Bluetooth
  * Add PWM fan

Signed-off-by: Stephen Chen <stephen@radxa.com>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Aug 29, 2024
ACPICA commit 49fe4f25483feec2f685b204ef19e28d92979e95

In Haiku, semaphores are represented by integers, not pointers.
So, we can't use NULL as the invalid/destroyed value, the correct value
is -1. Introduce a platform overridable define to allow this.

Fixes torvalds#162 (which was closed after coming to the conclusion that this
should be done, but the change was never done).

Link: acpica/acpica@49fe4f25
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
vlsunil pushed a commit to vlsunil/linux that referenced this pull request Aug 30, 2024
ACPICA commit 49fe4f25483feec2f685b204ef19e28d92979e95

In Haiku, semaphores are represented by integers, not pointers.
So, we can't use NULL as the invalid/destroyed value, the correct value
is -1. Introduce a platform overridable define to allow this.

Fixes torvalds#162 (which was closed after coming to the conclusion that this
should be done, but the change was never done).

Link: acpica/acpica@49fe4f25
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
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.

6 participants