Turn it into (for example):

[    0.073380] x86: Booting SMP configuration:
[    0.074005] .... node   #0, CPUs:          #1   #2   #3   #4   #5   torvalds#6   torvalds#7
[    0.603005] .... node   #1, CPUs:     torvalds#8   torvalds#9  torvalds#10  torvalds#11  torvalds#12  torvalds#13  torvalds#14  torvalds#15
[    1.200005] .... node   #2, CPUs:    torvalds#16  torvalds#17  torvalds#18  torvalds#19  torvalds#20  torvalds#21  torvalds#22  torvalds#23
[    1.796005] .... node   #3, CPUs:    torvalds#24  torvalds#25  torvalds#26  torvalds#27  torvalds#28  torvalds#29  torvalds#30  torvalds#31
[    2.393005] .... node   #4, CPUs:    torvalds#32  torvalds#33  torvalds#34  torvalds#35  torvalds#36  torvalds#37  torvalds#38  torvalds#39
[    2.996005] .... node   #5, CPUs:    torvalds#40  torvalds#41  torvalds#42  torvalds#43  torvalds#44  torvalds#45  torvalds#46  torvalds#47
[    3.600005] .... node   torvalds#6, CPUs:    torvalds#48  torvalds#49  torvalds#50  torvalds#51  #52  #53  torvalds#54  torvalds#55
[    4.202005] .... node   torvalds#7, CPUs:    torvalds#56  torvalds#57  #58  torvalds#59  torvalds#60  torvalds#61  torvalds#62  torvalds#63
[    4.811005] .... node   torvalds#8, CPUs:    torvalds#64  torvalds#65  torvalds#66  torvalds#67  torvalds#68  torvalds#69  #70  torvalds#71
[    5.421006] .... node   torvalds#9, CPUs:    torvalds#72  torvalds#73  torvalds#74  torvalds#75  torvalds#76  torvalds#77  torvalds#78  torvalds#79
[    6.032005] .... node  torvalds#10, CPUs:    torvalds#80  torvalds#81  torvalds#82  torvalds#83  torvalds#84  torvalds#85  torvalds#86  torvalds#87
[    6.648006] .... node  torvalds#11, CPUs:    torvalds#88  torvalds#89  torvalds#90  torvalds#91  torvalds#92  torvalds#93  torvalds#94  torvalds#95
[    7.262005] .... node  torvalds#12, CPUs:    torvalds#96  torvalds#97  torvalds#98  torvalds#99 torvalds#100 torvalds#101 torvalds#102 torvalds#103
[    7.865005] .... node  torvalds#13, CPUs:   torvalds#104 torvalds#105 torvalds#106 torvalds#107 torvalds#108 torvalds#109 torvalds#110 torvalds#111
[    8.466005] .... node  torvalds#14, CPUs:   torvalds#112 torvalds#113 torvalds#114 torvalds#115 torvalds#116 torvalds#117 torvalds#118 torvalds#119
[    9.073006] .... node  torvalds#15, CPUs:   torvalds#120 torvalds#121 torvalds#122 torvalds#123 torvalds#124 torvalds#125 torvalds#126 torvalds#127
[    9.679901] x86: Booted up 16 nodes, 128 CPUs

and drop useless elements.

Change num_digits() to hpa's division-avoiding, cell-phone-typed
version which he went at great lengths and pains to submit on a
Saturday evening.

Signed-off-by: Borislav Petkov <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: Linus Torvalds <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Ingo Molnar <[email protected]>

Revert "Revert "Rtc""

When a transition occurs between alternate settings that do not use the
same synchronization method, the substream pointers were not reset.
This prevents audio from being played during the second transition.

Identified and tested with M-Audio Transit device
(0763:2006 Midiman M-Audio Transit)

Details of the issue:

First playback to adaptive endpoint:
$ aplay -Dhw:1,0 ~/24_96.wav
Playing WAVE '/home/plb/24_96.wav' : Signed 24 bit Little Endian in 3bytes,
Rate 96000 Hz, Stereo

[ 3169.297556] usb 1-2: setting usb interface 1:1
[ 3169.297568] usb 1-2: Creating new playback data endpoint #3
[ 3169.298563] usb 1-2: Setting params for ep #3 (type 0, 3 urbs), ret=0
[ 3169.298574] usb 1-2: Starting data EP @ffff880035fc8000

first playback to asynchronous endpoint:
$ aplay -Dhw:1,0 ~/16_48.wav
Playing WAVE '/home/plb/16_48.wav' : Signed 16 bit Little Endian,
Rate 48000 Hz, Stereo

[ 3204.520251] usb 1-2: setting usb interface 1:3
[ 3204.520264] usb 1-2: Creating new playback data endpoint #3
[ 3204.520272] usb 1-2: Creating new capture sync endpoint torvalds#83
[ 3204.521162] usb 1-2: Setting params for ep #3 (type 0, 4 urbs), ret=0
[ 3204.521177] usb 1-2: Setting params for ep torvalds#83 (type 1, 4 urbs), ret=0
[ 3204.521182] usb 1-2: Starting data EP @ffff880035fce000
[ 3204.521204] usb 1-2: Starting sync EP @ffff8800bd616000

second playback to adaptive endpoint: no audio and error on terminal:
$ aplay -Dhw:1,0 ~/24_96.wav
Playing WAVE '/home/plb/24_96.wav' : Signed 24 bit Little Endian in 3bytes,
Rate 96000 Hz, Stereo
aplay: pcm_write:1939: write error: Input/output error

[ 3239.483589] usb 1-2: setting usb interface 1:1
[ 3239.483601] usb 1-2: Re-using EP 3 in iface 1,1 @ffff880035fc8000
[ 3239.484590] usb 1-2: Setting params for ep #3 (type 0, 4 urbs), ret=0
[ 3239.484606] usb 1-2: Setting params for ep torvalds#83 (type 1, 4 urbs), ret=0

This last line shows that a sync endpoint is used when it shouldn't.
The sync endpoint is no longer valid and the pointers are corrupted

Signed-off-by: Pierre-Louis Bossart <[email protected]>
Signed-off-by: Takashi Iwai <[email protected]>

GIT fc4597fb8f32648009bfbe2793bef4a9cd3e9460

commit b9e43f49f67229f5135b8f0f5abdbf72fa31caa1
Author: Theodore Ts'o <[email protected]>
Date:   Sun Aug 16 10:03:57 2015 -0400

    Revert "ext4: remove block_device_ejected"
    
    This reverts commit 08439fec266c3cc5702953b4f54bdf5649357de0.
    
    Unfortunately we still need to test for bdi->dev to avoid a crash when a
    USB stick is yanked out while a file system is mounted:
    
       usb 2-2: USB disconnect, device number 2
       Buffer I/O error on dev sdb1, logical block 15237120, lost sync page write
       JBD2: Error -5 detected when updating journal superblock for sdb1-8.
       BUG: unable to handle kernel paging request at 34beb000
       IP: [<c136ce88>] __percpu_counter_add 0x18/0xc0
       *pdpt = 0000000023db9001 *pde = 0000000000000000
       Oops: 0000 [#1] SMP
       CPU: 0 PID: 4083 Comm: umount Tainted: G     U     OE   4.1.1-040101-generic #201507011435
       Hardware name: LENOVO 7675CTO/7675CTO, BIOS 7NETC2WW (2.22 ) 03/22/2011
       task: ebf06b50 ti: ebebc000 task.ti: ebebc000
       EIP: 0060:[<c136ce88>] EFLAGS: 00010082 CPU: 0
       EIP is at __percpu_counter_add 0x18/0xc0
       EAX: f21c8e88 EBX: f21c8e88 ECX: 00000000 EDX: 00000001
       ESI: 00000001 EDI: 00000000 EBP: ebebde60 ESP: ebebde40
        DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
       CR0: 8005003b CR2: 34beb000 CR3: 33354200 CR4: 000007f0
       Stack:
        c1abe100 edcb0098 edcb00ec ffffffff f21c8e68 ffffffff f21c8e68 f286d160
        ebebde84 c1160454 00000010 00000282 f72a77f8 00000984 f72a77f8 f286d160
        f286d170 ebebdea0 c11e613f 00000000 00000282 f72a77f8 edd7f4d0 00000000
       Call Trace:
        [<c1160454>] account_page_dirtied 0x74/0x110
        [<c11e613f>] __set_page_dirty 0x3f/0xb0
        [<c11e6203>] mark_buffer_dirty 0x53/0xc0
        [<c124a0cb>] ext4_commit_super 0x17b/0x250
        [<c124ac71>] ext4_put_super 0xc1/0x320
        [<c11f04ba>] ? fsnotify_unmount_inodes 0x1aa/0x1c0
        [<c11cfeda>] ? evict_inodes 0xca/0xe0
        [<c11b925a>] generic_shutdown_super 0x6a/0xe0
        [<c10a1df0>] ? prepare_to_wait_event 0xd0/0xd0
        [<c1165a50>] ? unregister_shrinker 0x40/0x50
        [<c11b92f6>] kill_block_super 0x26/0x70
        [<c11b94f5>] deactivate_locked_super 0x45/0x80
        [<c11ba007>] deactivate_super 0x47/0x60
        [<c11d2b39>] cleanup_mnt 0x39/0x80
        [<c11d2bc0>] __cleanup_mnt 0x10/0x20
        [<c1080b51>] task_work_run 0x91/0xd0
        [<c1011e3c>] do_notify_resume 0x7c/0x90
        [<c1720da5>] work_notify
       Code: 8b 55 e8 e9 f4 fe ff ff 90 90 90 90 90 90 90 90 90 90 90 55 89 e5 83 ec 20 89 5d f4 89 c3 89 75 f8 89 d6 89 7d fc 89 cf 8b 48 14 <64> 8b 01 89 45 ec 89 c2 8b 45 08 c1 fa 1f 01 75 ec 89 55 f0 89
       EIP: [<c136ce88>] __percpu_counter_add 0x18/0xc0 SS:ESP 0068:ebebde40
       CR2: 0000000034beb000
       ---[ end trace dd564a7bea834ecd ]---
    
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=101011
    
    Signed-off-by: Theodore Ts'o <[email protected]>

commit 395ae54bd8775508a9616817188cabbcd6f53260
Author: Pierre-Louis Bossart <[email protected]>
Date:   Fri Aug 14 17:19:43 2015 -0500

    ALSA: usb: handle descriptor with SYNC_NONE illegal value
    
    The M-Audio Transit exposes an interface with a SYNC_NONE attribute.
    This is not a valid value according to the USB audio classspec. However
    there is a sync endpoint associated to this record. Changing the logic to
    try to use this sync endpoint allows for seamless transitions between
    altset 2 and altset 3. If any errors happen, the behavior remains the same.
    
    $ more /proc/asound/card1/stream0
    M-Audio Transit USB at usb-0000:00:14.0-2, full speed : USB Audio
    
    Playback:
      Status: Stop
      Interface 1
        Altset 1
        Format: S24_3LE
        Channels: 2
        Endpoint: 3 OUT (ADAPTIVE)
        Rates: 48001 - 96000 (continuous)
      Interface 1
        Altset 2
        Format: S24_3LE
        Channels: 2
        Endpoint: 3 OUT (NONE)
        Rates: 8000 - 48000 (continuous)
      Interface 1
        Altset 3
        Format: S16_LE
        Channels: 2
        Endpoint: 3 OUT (ASYNC)
        Rates: 8000 - 48000 (continuous)
    
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>

commit 630184477e7eccb2b31ee4c20b6905ca5fa4b3a8
Author: Pierre-Louis Bossart <[email protected]>
Date:   Fri Aug 14 17:19:42 2015 -0500

    ALSA: usb: fix corrupted pointers due to interface setting change
    
    When a transition occurs between alternate settings that do not use the
    same synchronization method, the substream pointers were not reset.
    This prevents audio from being played during the second transition.
    
    Identified and tested with M-Audio Transit device
    (0763:2006 Midiman M-Audio Transit)
    
    Details of the issue:
    
    First playback to adaptive endpoint:
    $ aplay -Dhw:1,0 ~/24_96.wav
    Playing WAVE '/home/plb/24_96.wav' : Signed 24 bit Little Endian in 3bytes,
    Rate 96000 Hz, Stereo
    
    [ 3169.297556] usb 1-2: setting usb interface 1:1
    [ 3169.297568] usb 1-2: Creating new playback data endpoint #3
    [ 3169.298563] usb 1-2: Setting params for ep #3 (type 0, 3 urbs), ret=0
    [ 3169.298574] usb 1-2: Starting data EP @ffff880035fc8000
    
    first playback to asynchronous endpoint:
    $ aplay -Dhw:1,0 ~/16_48.wav
    Playing WAVE '/home/plb/16_48.wav' : Signed 16 bit Little Endian,
    Rate 48000 Hz, Stereo
    
    [ 3204.520251] usb 1-2: setting usb interface 1:3
    [ 3204.520264] usb 1-2: Creating new playback data endpoint #3
    [ 3204.520272] usb 1-2: Creating new capture sync endpoint #83
    [ 3204.521162] usb 1-2: Setting params for ep #3 (type 0, 4 urbs), ret=0
    [ 3204.521177] usb 1-2: Setting params for ep #83 (type 1, 4 urbs), ret=0
    [ 3204.521182] usb 1-2: Starting data EP @ffff880035fce000
    [ 3204.521204] usb 1-2: Starting sync EP @ffff8800bd616000
    
    second playback to adaptive endpoint: no audio and error on terminal:
    $ aplay -Dhw:1,0 ~/24_96.wav
    Playing WAVE '/home/plb/24_96.wav' : Signed 24 bit Little Endian in 3bytes,
    Rate 96000 Hz, Stereo
    aplay: pcm_write:1939: write error: Input/output error
    
    [ 3239.483589] usb 1-2: setting usb interface 1:1
    [ 3239.483601] usb 1-2: Re-using EP 3 in iface 1,1 @ffff880035fc8000
    [ 3239.484590] usb 1-2: Setting params for ep #3 (type 0, 4 urbs), ret=0
    [ 3239.484606] usb 1-2: Setting params for ep #83 (type 1, 4 urbs), ret=0
    
    This last line shows that a sync endpoint is used when it shouldn't.
    The sync endpoint is no longer valid and the pointers are corrupted
    
    Signed-off-by: Pierre-Louis Bossart <[email protected]>
    Signed-off-by: Takashi Iwai <[email protected]>

commit 493f133f47750aa5566fafa9403617e3f0506f8c
Author: Len Brown <[email protected]>
Date:   Wed Mar 25 23:20:37 2015 -0400

    intel_idle: Skylake Client Support
    
    Skylake Client CPU idle Power states (C-states)
    are similar to the previous generation, Broadwell.
    However, Skylake does get its own table with updated
    worst-case latency and average energy-break-even residency values.
    
    Signed-off-by: Len Brown <[email protected]>

commit d248b61f611463cca906d5663a9a0de63ade97a9
Author: Hai Li <[email protected]>
Date:   Thu Aug 13 17:49:29 2015 -0400

    drm/msm/dsi: Introduce DSI configuration module
    
    With more platforms supported, the DSI host
    configuration array keeps expanding. This change
    moves those to a separate dsi_cfg module.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 1bf4d7c5651a7cfcdcd77389b42d266441ecf444
Author: Hai Li <[email protected]>
Date:   Thu Aug 13 17:45:53 2015 -0400

    drm/msm/dsi: Make each PHY type compilation independent
    
    On a certain platform, only one type of DSI PHY is used.
    This change allows the user to only compile the PHY type
    which is being used.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 5c8290284402bf7d2c12269402b3177b899c78b7
Author: Hai Li <[email protected]>
Date:   Thu Aug 13 17:45:52 2015 -0400

    drm/msm/dsi: Split PHY drivers to separate files
    
    This change moves each PHY type specific code into
    separate files.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 29e61690130adb1c27053558d2f21af88ae0334e
Author: Hai Li <[email protected]>
Date:   Thu Aug 13 17:45:51 2015 -0400

    drm/msm/dsi: Return void from msm_dsi_phy_disable()
    
    We are not checking the return value from msm_dsi_phy_disable().
    Change the return type to void.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit fae11c1106ad8304c09e3b9bf95dd6d03f4a5afa
Author: Hai Li <[email protected]>
Date:   Thu Aug 13 17:45:50 2015 -0400

    drm/msm/dsi: Specify bitmask to set source PLL
    
    The bit position to configure source PLL will change
    on new types of PHYs. The caller should pass down
    this information.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 29f034d776209042f7aaaf1518a66841c1d42233
Author: jilai wang <[email protected]>
Date:   Wed Aug 5 15:33:29 2015 -0400

    drm/msm/mdp: Clear pending interrupt status before enable interrupt
    
    Pending interrupt status needs to be cleared before enable the
    interrupt. Otherwise it's possible to get a pending interrupt instead
    of an incoming interrupt.
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 8089082fae1975ad9d5abbd37c0ee8f688be28a0
Author: jilai wang <[email protected]>
Date:   Fri Jul 31 10:13:26 2015 -0400

    drm/msm/mdp5: Add rotation (hflip/vflip) support to MDP5 planes (v2)
    
    MDP5 SSPPs can flip the input source horizontally or vertically.
    This change is to add this support to MDP5 planes.
    
    v1: Initial change
    v2: Use existing "rotation" property instead of creating msm specific
        properties. In order to be compatiable with legacy non-atomic
        set_property, switch to drm_atomic_helper_plane_set_property
        helper function.
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 095022b9aa0546a0f3d3fb5f42c82b4004103864
Author: Srinivas Kandagatla <[email protected]>
Date:   Mon Jul 27 15:12:39 2015  0100

    drm/msm: add calls to prepare and unprepare panel
    
    Prepare the panel before it's enabled and un-prepare after disable, this
    will make sure that the regulators are switched on and off correctly.
    
    Tested it on APQ8064 based IFC6410 with panel.
    
    Signed-off-by: Srinivas Kandagatla <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 09992e4d46935798b4a1cf3a734e6a0f3470f107
Author: Archit Taneja <[email protected]>
Date:   Mon Aug 3 14:09:36 2015  0530

    drm/msm/dsi: Modify dsi manager bridge ops to work with external bridges
    
    The dsi bridge ops call drm_panel functions to set up the connected
    drm_panel. Add checks to make sure these aren't called when we're
    connected to an external bridge.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c118e29033aa5b38b593ebd0e02f8b1224c20ed3
Author: Archit Taneja <[email protected]>
Date:   Fri Jul 31 14:06:10 2015  0530

    drm/msm/dsi: Allow dsi to connect to an external bridge
    
    There are platforms where the DSI output can be connected to another
    encoder bridge chip (DSI to HDMI, DSI to LVDS etc).
    
    Add support for external bridge support to the dsi driver. We assume that
    the external bridge chip would be of the type drm_bridge. The dsi driver's
    internal drm_bridge (msm_dsi->bridge) is linked to the external bridge's
    drm_bridge struct.
    
    In the case we're connected to an external bridge, we don't need to create
    and manage a connector within our driver, it's the bridge driver's
    responsibility to create one.
    
    v2:
    - Move the external bridge attaching stuff to dsi manager to make things
      cleaner.
    - Force the bridge to connect to a video mode encoder for now (the dsi
      mode flags may have not been populated by modeset_init)
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 6f054ec5b9ced3041f29541ae79402198678fc06
Author: Archit Taneja <[email protected]>
Date:   Mon Aug 3 14:08:33 2015  0530

    drm/msm/dsi: Create a helper to check if there is a connected device
    
    Create a helper msm_dsi_device_connected() which checks whether we have a
    device connected to the dsi host or not. This check gets messy when we
    have support external bridges too. Having an inline function makes it
    more legible.
    
    For now, the check only consists of msm_dsi->panel being non-NULL. Later,
    this will check if we have an external bridge or not.
    
    This helper isn't used in dsi_connector related code as that's specific
    to only when a drm_panel is connected.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit a9ddac9c5765712fa7eace55feeaf7c4ac75e32b
Author: Archit Taneja <[email protected]>
Date:   Mon Aug 3 14:05:45 2015  0530

    drm/msm/dsi: Refer to connected device as 'device' instead of 'panel'
    
    We currently support only panels connected to dsi output. We're going to
    also support external bridge chips now.
    
    Change 'panel_node' to 'device_node' in the struct msm_dsi_host and
    'panel_flags' to 'device_flags' in msm_dsi. This makes things sound a
    bit more generic.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 60d05cb4eabcfcab00784677c2a55ed1b9bda2ec
Author: Archit Taneja <[email protected]>
Date:   Thu Jun 25 14:36:35 2015  0530

    drm/msm/dsi: Make TE gpio optional
    
    Platforms containing only DSI video mode devices don't need a TE gpio.
    Make TE gpio optional.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 3d6df06249277aabaf895951855c4ed704b038bb
Author: Archit Taneja <[email protected]>
Date:   Tue Jun 9 14:17:22 2015  0530

    drm/msm: mdp4 lvds: get panel node via of graph parsing
    
    We currently get the output connected to LVDS by looking for a phandle
    called 'qcom,lvds-panel' under the mdp DT node.
    
    Use the more standard of_graph approach to create an lvds output port,
    and retrieve the panel node from the port's endpoint data.
    
    v3
    - Fix return value checks of of_graph_* calls.
    
    Tested-by: Srinivas Kandagatla <[email protected]>
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit f7009d266d8b2f4b54da42399aaa536d74fe3e7c
Author: Archit Taneja <[email protected]>
Date:   Thu Jun 25 11:43:40 2015  0530

    drm/msm: dsi host: Use device graph parsing to parse connected panel
    
    The dsi host looks for the connected panel node by parsing for a child
    named 'panel'. This hierarchy isn't very flexible. The connected
    panel is forced to be a child to the dsi host, and hence, a mipi dsi
    device. This isn't suitable for dsi devices that don't use mipi dsi
    as their control bus.
    
    Follow the of_graph approach of creating ports and endpoints to
    represent the connections between the dsi host and the panel connected
    to it. In our case, the dsi host will only have one output port, linked
    to the panel's input port.
    
    Update DT binding documentation with device graph usage info.
    
    v3:
    - Fix return value checks of of_graph_* calls.
    - Don't make port a mandatory DT property
    - Fix defer check when no panel node specified
    - Rename parse_dt func to align with other dsi_host funcs
    
    Reviewed-by: Hai Li <[email protected]>
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 14bb28b0f91f868f081f71eb0c7b590e13527c3c
Author: Archit Taneja <[email protected]>
Date:   Thu Jun 4 15:01:57 2015  0530

    drm/msm: dsi host: add missing of_node_put()
    
    Decrement device node refcount if of_get_child_by_name is successfully
    called.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 78b1d470d57dd7a6e0efda63ebad97f0d44e817c
Author: Hai Li <[email protected]>
Date:   Mon Jul 27 13:49:45 2015 -0400

    drm/msm: Enable clocks during enable/disable_vblank() callbacks
    
    AHB clock should be enabled before accessing registers during
    enable/disable_vblank(). Since these 2 callbacks are called in
    atomic context while clk_prepare may cause thread sleep, a work
    is scheduled to control vblanks.
    
    v2: fixup spinlock initialization
    
    Signed-off-by: Hai Li <[email protected]>
    [add comment about cancel_work_sync() before drm_irq_uninstall()]
    Signed-off-by: Rob Clark <[email protected]>

commit 8a94b0aa372ebf7375c8ea861cb9bbf84b39d2df
Author: jilai wang <[email protected]>
Date:   Wed Jul 8 18:25:40 2015 -0400

    drm/msm/mdp5: Add support for msm8x74v1
    
    msm8x74v1 has different MDP5 version (v1.0) from msm8x74v2 (v1.2).
    Add a separate config data to support msm8x74v1.
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 8155ad4ce67d2f3418a4a72144c10114d21f0ece
Author: jilai wang <[email protected]>
Date:   Tue Jul 7 17:17:28 2015 -0400

    drm/msm/mdp5: Add DMA pipe planes for MDP5
    
    This change is to add planes which use DMA pipes for MDP5.
    
    Signed-off-by: Jilai Wang <[email protected]>
    [slight comment adjust to s/Construct public planes/Construct video
    planes/ since DMA planes are public planes too, they just can't scale
    or CSC]
    Signed-off-by: Rob Clark <[email protected]>

commit 3498409f0315b93f969f87c31d014a9819f6fa7d
Author: jilai wang <[email protected]>
Date:   Wed Jul 8 18:12:40 2015 -0400

    drm/msm/mdp: Add capabilities to MDP planes (v2)
    
    MDP planes can be implemented using different type of HW pipes,
    RGB/VIG/DMA pipes for MDP5 and RGB/VG/DMA pipes for MDP4. Each type
    of pipe has different HW capabilities such as scaling, color space
    conversion, decimation... Add a variable in plane data structure
    to specify the difference of each plane which comes from mdp5_cfg data
    and use it to differenciate the plane operation.
    V1: Initial change
    V2: Fix a typo in mdp4_kms.h
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit bef799fb77dc30d32362b6850e997f1c29fc99eb
Author: Stephane Viau <[email protected]>
Date:   Mon Jul 6 16:35:31 2015 -0400

    drm/msm/mdp5: add more YUV formats for MDP5
    
    Add packed YUV422 and planar YUV420 formats to MDP supported
    formats.
    
    Signed-off-by: Stephane Viau <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 9cc137a3ffa3162a0d5af822149a5cec1b42c24e
Author: Wentao Xu <[email protected]>
Date:   Mon Jul 6 16:35:30 2015 -0400

    drm/msm/mdp5: use 2 memory clients for YUV formats on newer mdp5
    
    Newer MDP5 uses 2 shared memory pool clients for certain YUV formats.
    For example, if VIG0 is used to fetch data in YUYV format, it will use
    VIG0_Y for Y component, and VIG0_Cr for UV packed.
    
    Signed-off-by: Wentao Xu <[email protected]>
    [rebase]
    Signed-off-by: Stephane Viau <[email protected]>

commit ff78a6b3771f48d1d5585e5d08ab4ae6fd606ab0
Author: Wentao Xu <[email protected]>
Date:   Mon Jul 6 16:35:29 2015 -0400

    drm/msm/mdp: mark if a MDP format is YUV at definition
    
    This makes it easy to determine if a format is YUV. The old
    method of using chroma sample type incorrectly marks YUV444 as
    RGB format.
    
    Signed-off-by: Wentao Xu <[email protected]>
    [rebase]
    Signed-off-by: Stephane Viau <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 02b3ee466443ba6780562fb2af5fe0ad5bf059f6
Author: Uwe Kleine-König <[email protected]>
Date:   Mon Jul 6 11:09:41 2015  0200

    drm/msm/dp: use flags argument of devm_gpiod_get to set direction
    
    Since 39b2bbe3d715 (gpio: add flags argument to gpiod_get*() functions)
    which appeared in v3.17-rc1, the gpiod_get* functions take an additional
    parameter that allows to specify direction and initial value for output.
    
    Use this to simplify the driver. Furthermore this is one caller less
    that stops us making the flags argument to gpiod_get*() mandatory.
    
    Acked-by: Alexandre Courbot <[email protected]>
    Acked-by: Linus Walleij <[email protected]>
    Signed-off-by: Uwe Kleine-König <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 328e1a633c9bc26c36ecd320246e4a9b2726e81a
Author: Hai Li <[email protected]>
Date:   Fri Jul 3 10:09:46 2015 -0400

    drm/msm/dsi: Save/Restore PLL status across PHY reset
    
    Reset DSI PHY silently changes its PLL registers to reset status,
    which will make cached status in clock driver invalid and result
    in wrong output rate of link clocks. The current restore mechanism
    in DSI PLL does not cover all the cases. This change is to recover
    PLL status after PHY reset to match HW status with cached status
    in clock driver.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit da882cd1ee132ecbb4a4848a6b0797ea2ed4bee7
Author: Markus Elfring <[email protected]>
Date:   Sat Jun 27 22:23:28 2015  0200

    drm/msm/dsi: One function call less in dsi_init() after error detection
    
    The dsi_destroy() function was called in two cases by the dsi_init() function
    during error handling even if the passed variable contained a null pointer.
    
    * This implementation detail could be improved by adjustments for jump
      targets according to the Linux coding style convention.
    
    * Drop an unnecessary initialisation for the variable "msm_dsi" then.
    
    Signed-off-by: Markus Elfring <[email protected]>
    [add couple missing ERR_PTR()'s]
    Signed-off-by: Rob Clark <[email protected]>

commit a60bbb2764b73a3f54c7462f3d28f960b7811682
Author: Markus Elfring <[email protected]>
Date:   Sat Jun 27 22:05:31 2015  0200

    drm/msm/dsi: Delete an unnecessary check before the function call "dsi_destroy"
    
    The dsi_destroy() function tests whether its argument is NULL and then
    returns immediately. Thus the test around the call is not needed.
    
    This issue was detected by using the Coccinelle software.
    
    Signed-off-by: Markus Elfring <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit b96b3a06d1211ba86674db99a6aafe39ef4cbed2
Author: Hai Li <[email protected]>
Date:   Fri Jun 26 16:03:26 2015 -0400

    drm/msm/mdp5: Allocate CTL0/1 for dual DSI single FLUSH
    
    This change takes advantage of a HW feature that synchronize
    flush operation on CTL1 to CTL0, to keep dual DSI pipes in
    sync.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c71716b17bc772e9c38f85a4b496bbfac0dd32f0
Author: Hai Li <[email protected]>
Date:   Fri Jun 26 16:03:25 2015 -0400

    drm/msm/mdp5: Allocate CTL for each display interface
    
    In MDP5, CTL contains information of the whole pipeline whose
    output goes down to a display interface. In various cases, one
    interface may require 2 CRTCs, but only one CTL. Some interfaces
    also require to use certain CTLs.
    
    Instead of allocating CTL for each active CRTC, this change is to
    associate a CTL with each interface.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 129877819c0a5f8d419fe67ae08a8a7c811afa5e
Author: jilai wang <[email protected]>
Date:   Thu Jun 25 17:37:42 2015 -0400

    drm/msm/mdp5: Add plane blending operation support for MDP5 (v2)
    
    This change is to add properties alpha/zpos/blend_mode to mdp5 plane
    for alpha blending operation to generate the blended output.
    v1: Initial change
    v2: Change "premultilied" property to enum (Rob's comment)
    
    Signed-off-by: Jilai Wang <[email protected]>
    [Don't actually expose alpha/premultiplied props to userspace yet
    pending a chance for discussion and some userspace to exercise it]
    Signed-off-by: Rob Clark <[email protected]>

commit 4ff696eafaa50d6d649d256d20528b475104a500
Author: Rob Clark <[email protected]>
Date:   Tue Jul 28 11:05:03 2015 -0400

    drm/msm: don't install plane properties on crtc
    
    This was a hold-over from the pre-atomic days and legacy userspace that
    only understood CRTCs.  Fortunately we don't have any properties, so
    this doesn't change anything.  But before we start growing some plane
    properties, we should fix this.
    
    Signed-off-by: Rob Clark <[email protected]>

commit 01199361c665245d557b8eefef56d648ddb3867a
Author: Archit Taneja <[email protected]>
Date:   Thu Jun 25 11:29:24 2015  0530

    drm/msm/dsi: Report PHY errors only when they really occur
    
    DSI PHY errors are falsely reported whenever a dsi error occurs. This is
    because DSI_DLN0_PHY_ERR isn't only used as a status register, but also
    used to mask PHY errors. Currently, we end up reading the mask bits too
    and therefore always report errors.
    
    Ignore the register mask bits and check for only the status/clear bits.
    
    Signed-off-by: Archit Taneja <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 9b7a9fc29a48026d797cbf237121850c1c241df4
Author: Hai Li <[email protected]>
Date:   Wed Jun 24 19:13:40 2015 -0400

    drm/msm: Set different display size limitation on each target
    
    The maximum output width of one pipeline depends on the LayerMixer's
    capability. It may be different on each target. Also, MDP5 doesn't
    have vertical limitation in one frame, as long as the pixel clock
    can be supported.
    
    This change obtains the maximum LM resolution from configuration
    table and treat it as the whole pipe's limitation for MDP5. The size
    limit on MDP4 is not changed.
    
    Signed-off-by: Hai Li <[email protected]>

commit 5cf3a4553fc8395c4ad38077f8cee6c91f832393
Author: Rob Clark <[email protected]>
Date:   Mon Jul 27 20:52:50 2015 -0400

    drm/msm/hdmi: standardize on lead chip for compatible names
    
    For all of these devices, msm89xy was the lead chip, so standardize the
    compatible names to align with convention used by rest of the qcom/msm
    drivers.
    
    Signed-off-by: Rob Clark <[email protected]>

commit 3a84f8469e2687b9fdcf83d615b8001a2443566a
Author: Stephane Viau <[email protected]>
Date:   Fri Jun 19 16:04:47 2015 -0400

    drm/msm: Add support for msm8x94
    
    This change adds the MDP and HDMI support for msm8x94.
    Note that HDMI PHY registers are not being accessed anymore from
    the driver.
    
    Signed-off-by: Stephane Viau <[email protected]>
    [rename compatible s/8x94/8994/ since preference is to not trust the
    marketing folks who invent chip #'s but instead name things after the
    lead chip.. we should rename some 80XY to 89XY to standardize on the
    lead chip but leave that for another patch.  Also, update dt bindings
    doc]
    Signed-off-by: Rob Clark <[email protected]>

commit da32855219f86f27cad1b12be2264ffb0b97b9fa
Author: Stephane Viau <[email protected]>
Date:   Fri Jun 19 16:04:46 2015 -0400

    drm/msm/hdmi: remove ->reset() from HDMI PHY
    
    ->reset() currently only accesses HDMI core registers, and yet it
    is located in hdmi_phy*. Since no PHY registers are being
    accessed during ->reset(), it would be better to bring that
    function in hdmi core module where HDMI core registers are
    usually being accessed.
    
    This will also help for msm8x94 for which no PHY registers
    accesses are done (->phy_init == NULL) but the HDMI PHY reset
    from HDMI core still needs to be done.
    
    Note:
    SW_RESET_PLL bit is not written in hdmi_phy_8x60_reset(); this
    write should not affect anything if the corresponding field is
    not writable.
    
    Signed-off-by: Stephane Viau <[email protected]>
    [fixed warning about unused 'phy' in hpd_enable() while merging]
    Signed-off-by: Rob Clark <[email protected]>

commit dcefc117cc192f215d04c4e7cbae6b76a9bafcf4
Author: Hai Li <[email protected]>
Date:   Thu Jun 18 10:14:21 2015 -0400

    drm/msm/dsi: Add support for msm8x94
    
    DSI controller on msm8x94 is version 1.3, which requires different
    power supplies and works with 20nm DSI PHY. This change is to add
    the basic support for this version.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit ab8909b032ffccc15384879dd5798b8647d6ab8a
Author: Hai Li <[email protected]>
Date:   Thu Jun 11 10:56:46 2015 -0400

    drm/msm/dsi: Use pinctrl in DSI driver
    
    Some targets use pinctrl framework to configure some
    pins. This change allows DSI driver to set default and
    sleep pinctrl status.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 678565c3cb2100a8f03c23592f13f6b78e69a590
Author: Hai Li <[email protected]>
Date:   Wed Jun 10 13:18:18 2015 -0400

    drm/msm/dsi: Rename *dual panel* to *dual DSI*
    
    The current term of *dual panel* in DSI driver code causes confusion.
    It is supposed to indicate the panel using two DSI links. Rename it
    to *dual DSI*.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 13351cd17791694f2dcc96dc920e58b090b18c31
Author: Hai Li <[email protected]>
Date:   Wed Jun 10 13:18:17 2015 -0400

    drm/msm/dsi: Update source PLL selection in DSI PHY
    
    The source PLL to be used by each DSI PHY should be decided by
    DSI manager based on dual DSI information, while the register
    programming to select PLL is different from one type of PHY to
    another. This change adds the H/W difference to PHY configuration
    and updates the interface between DSI manager and PHY.
    
    With this change, PLL selection can be supported on different
    targets.
    
    Signed-off-by: Hai Li <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit c6a57a50ad562a2e6fc6ac3218b710caea73a58b
Author: jilai wang <[email protected]>
Date:   Thu Apr 2 17:49:01 2015 -0400

    drm/msm/hdmi: add hdmi hdcp support (V3)
    
    Add HDMI HDCP support including HDCP PartI/II/III authentication.
    V1: Initial Change
    V2: Address Bjorn&Rob's comments
        Refactor the authentication process to use single work instead
        of multiple work for different authentication stages.
    V3: Update to align with qcom SCM api.
    
    Signed-off-by: Jilai Wang <[email protected]>
    Signed-off-by: Rob Clark <[email protected]>

commit 2d3584eb871da2a6fa72e3d50781f33b0312589a
Author: Rob Clark <[email protected]>
Date:   Mon Jul 27 19:37:12 2015 -0400

    drm/msm: update generated headers
    
    Signed-off-by: Rob Clark <[email protected]>

commit c0015bf3a34961342a27b021672049e535ab36a1
Author: Alexander Aring <[email protected]>
Date:   Sat Aug 15 11:00:33 2015  0200

    ieee802154: 6lowpan: fix non-lowpan wpan interfaces
    
    We receive all 802.15.4 frames on the packet handler "lowpan_rcv" this
    patch checks if the wpan device belongs to a lowpan interface.
    
    Signed-off-by: Alexander Aring <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 0751272880f3a0c74c786ecfaba2b3d98748482f
Author: Alexander Aring <[email protected]>
Date:   Sat Aug 15 11:00:32 2015  0200

    ieee802154: 6lowpan: fix packet layer registration
    
    This patch fixes 802.15.4 packet layer registration when mutliple
    lowpan interfaces will be added. We need to register the packet layer at
    the first lowpan interface and deregister it at the last interface. This
    done by open_count variable which is protected by rtnl.
    
    Additional do a quiet fix by adding dev_put(real_dev) when netdev
    registration fails, which fix the refcount for the wpan dev.
    
    Signed-off-by: Alexander Aring <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit 4481c0767e52eea674794de4b9123c9bc3d24f24
Author: Peter Poklop <[email protected]>
Date:   Sat Aug 15 20:47:09 2015  0200

    Bluetooth: btusb: mark 0c10:0000 devices with BTUSB_SWAVE
    
    This patch enables quirk handling for Silicon Wave based devices and
    fixes kernel bug with id 42985.
    
    T:  Bus=01 Lev=01 Prnt=01 Port=07 Cnt=04 Dev#=  6 Spd=12   MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=0c10 ProdID=0000 Rev=15.00
    S:  Manufacturer=SiW
    S:  Product=SiW
    S:  SerialNumber=340A05F61100
    C:* #Ifs= 2 Cfg#= 1 Atr=a0 MxPwr= 50mA
    I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
    E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
    I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
    I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
    I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
    I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
    I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
    I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
    
    Signed-off-by: Peter Poklop <[email protected]>
    Signed-off-by: Marcel Holtmann <[email protected]>

commit e294a5371b2e0bd22d4a917d4c354a52a7057b6e
Author: Theodore Ts'o <[email protected]>
Date:   Sat Aug 15 14:59:44 2015 -0400

    ext4: ratelimit the file system mounted message
    
    The xfstests ext4/305 will mount and unmount the same file system over
    4,000 times, and each one of these will cause a system log message.
    Ratelimit this message since if we are getting more than a few dozen
    of these messages, they probably aren't going to be helpful.
    
    Signed-off-by: Theodore Ts'o <[email protected]>

commit 0048b4837affd153897ed1222283492070027aa9
Author: Ming Lei <[email protected]>
Date:   Sun Aug 9 03:41:51 2015 -0400

    blk-mq: fix race between timeout and freeing request
    
    Inside timeout handler, blk_mq_tag_to_rq() is called
    to retrieve the request from one tag. This way is obviously
    wrong because the request can be freed any time and some
    fiedds of the request can't be trusted, then kernel oops
    might be triggered[1].
    
    Currently wrt. blk_mq_tag_to_rq(), the only special case is
    that the flush request can share same tag with the request
    cloned from, and the two requests can't be active at the same
    time, so this patch fixes the above issue by updating tags->rqs[tag]
    with the active request(either flush rq or the request cloned
    from) of the tag.
    
    Also blk_mq_tag_to_rq() gets much simplified with this patch.
    
    Given blk_mq_tag_to_rq() is mainly for drivers and the caller must
    make sure the request can't be freed, so in bt_for_each() this
    helper is replaced with tags->rqs[tag].
    
    [1] kernel oops log
    [  439.696220] BUG: unable to handle kernel NULL pointer dereference at 0000000000000158^M
    [  439.697162] IP: [<ffffffff812d89ba>] blk_mq_tag_to_rq 0x21/0x6e^M
    [  439.700653] PGD 7ef765067 PUD 7ef764067 PMD 0 ^M
    [  439.700653] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M
    [  439.700653] Dumping ftrace buffer:^M
    [  439.700653]    (ftrace buffer empty)^M
    [  439.700653] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw^M
    [  439.700653] CPU: 6 PID: 2779 Comm: stress-ng-sigfd Not tainted 4.2.0-rc5-next-20150805  #265^M
    [  439.730500] Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011^M
    [  439.730500] task: ffff880605308000 ti: ffff88060530c000 task.ti: ffff88060530c000^M
    [  439.730500] RIP: 0010:[<ffffffff812d89ba>]  [<ffffffff812d89ba>] blk_mq_tag_to_rq 0x21/0x6e^M
    [  439.730500] RSP: 0018:ffff880819203da0  EFLAGS: 00010283^M
    [  439.730500] RAX: ffff880811b0e000 RBX: ffff8800bb465f00 RCX: 0000000000000002^M
    [  439.730500] RDX: 0000000000000000 RSI: 0000000000000202 RDI: 0000000000000000^M
    [  439.730500] RBP: ffff880819203db0 R08: 0000000000000002 R09: 0000000000000000^M
    [  439.730500] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000202^M
    [  439.730500] R13: ffff880814104800 R14: 0000000000000002 R15: ffff880811a2ea00^M
    [  439.730500] FS:  00007f165b3f5740(0000) GS:ffff880819200000(0000) knlGS:0000000000000000^M
    [  439.730500] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b^M
    [  439.730500] CR2: 0000000000000158 CR3: 00000007ef766000 CR4: 00000000000006e0^M
    [  439.730500] Stack:^M
    [  439.730500]  0000000000000008 ffff8808114eed90 ffff880819203e00 ffffffff812dc104^M
    [  439.755663]  ffff880819203e40 ffffffff812d9f5e 0000020000000000 ffff8808114eed80^M
    [  439.755663] Call Trace:^M
    [  439.755663]  <IRQ> ^M
    [  439.755663]  [<ffffffff812dc104>] bt_for_each 0x6e/0xc8^M
    [  439.755663]  [<ffffffff812d9f5e>] ? blk_mq_rq_timed_out 0x6a/0x6a^M
    [  439.755663]  [<ffffffff812d9f5e>] ? blk_mq_rq_timed_out 0x6a/0x6a^M
    [  439.755663]  [<ffffffff812dc1b3>] blk_mq_tag_busy_iter 0x55/0x5e^M
    [  439.755663]  [<ffffffff812d88b4>] ? blk_mq_bio_to_request 0x38/0x38^M
    [  439.755663]  [<ffffffff812d8911>] blk_mq_rq_timer 0x5d/0xd4^M
    [  439.755663]  [<ffffffff810a3e10>] call_timer_fn 0xf7/0x284^M
    [  439.755663]  [<ffffffff810a3d1e>] ? call_timer_fn 0x5/0x284^M
    [  439.755663]  [<ffffffff812d88b4>] ? blk_mq_bio_to_request 0x38/0x38^M
    [  439.755663]  [<ffffffff810a46d6>] run_timer_softirq 0x1ce/0x1f8^M
    [  439.755663]  [<ffffffff8104c367>] __do_softirq 0x181/0x3a4^M
    [  439.755663]  [<ffffffff8104c76e>] irq_exit 0x40/0x94^M
    [  439.755663]  [<ffffffff81031482>] smp_apic_timer_interrupt 0x33/0x3e^M
    [  439.755663]  [<ffffffff815559a4>] apic_timer_interrupt 0x84/0x90^M
    [  439.755663]  <EOI> ^M
    [  439.755663]  [<ffffffff81554350>] ? _raw_spin_unlock_irq 0x32/0x4a^M
    [  439.755663]  [<ffffffff8106a98b>] finish_task_switch 0xe0/0x163^M
    [  439.755663]  [<ffffffff8106a94d>] ? finish_task_switch 0xa2/0x163^M
    [  439.755663]  [<ffffffff81550066>] __schedule 0x469/0x6cd^M
    [  439.755663]  [<ffffffff8155039b>] schedule 0x82/0x9a^M
    [  439.789267]  [<ffffffff8119b28b>] signalfd_read 0x186/0x49a^M
    [  439.790911]  [<ffffffff8106d86a>] ? wake_up_q 0x47/0x47^M
    [  439.790911]  [<ffffffff811618c2>] __vfs_read 0x28/0x9f^M
    [  439.790911]  [<ffffffff8117a289>] ? __fget_light 0x4d/0x74^M
    [  439.790911]  [<ffffffff811620a7>] vfs_read 0x7a/0xc6^M
    [  439.790911]  [<ffffffff8116292b>] SyS_read 0x49/0x7f^M
    [  439.790911]  [<ffffffff81554c17>] entry_SYSCALL_64_fastpath 0x12/0x6f^M
    [  439.790911] Code: 48 89 e5 e8 a9 b8 e7 ff 5d c3 0f 1f 44 00 00 55 89
    f2 48 89 e5 41 54 41 89 f4 53 48 8b 47 60 48 8b 1c d0 48 8b 7b 30 48 8b
    53 38 <48> 8b 87 58 01 00 00 48 85 c0 75 09 48 8b 97 88 0c 00 00 eb 10
    ^M
    [  439.790911] RIP  [<ffffffff812d89ba>] blk_mq_tag_to_rq 0x21/0x6e^M
    [  439.790911]  RSP <ffff880819203da0>^M
    [  439.790911] CR2: 0000000000000158^M
    [  439.790911] ---[ end trace d40af58949325661 ]---^M
    
    Cc: <[email protected]>
    Signed-off-by: Ming Lei <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 596f5aad2a704b72934e5abec1b1b4114c16f45b
Author: Ming Lei <[email protected]>
Date:   Sun Aug 9 03:41:50 2015 -0400

    blk-mq: fix buffer overflow when reading sysfs file of 'pending'
    
    There may be lots of pending requests so that the buffer of PAGE_SIZE
    can't hold them at all.
    
    One typical example is scsi-mq, the queue depth(.can_queue) of
    scsi_host and blk-mq is quite big but scsi_device's queue_depth
    is a bit small(.cmd_per_lun), then it is quite easy to have lots
    of pending requests in hw queue.
    
    This patch fixes the following warning and the related memory
    destruction.
    
    [  359.025101] fill_read_buffer: blk_mq_hw_sysfs_show 0x0/0x7d returned bad count^M
    [  359.055595] irq event stamp: 15537^M
    [  359.055606] general protection fault: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC ^M
    [  359.055614] Dumping ftrace buffer:^M
    [  359.055660]    (ftrace buffer empty)^M
    [  359.055672] Modules linked in: nbd ipv6 kvm_intel kvm serio_raw^M
    [  359.055678] CPU: 4 PID: 21631 Comm: stress-ng-sysfs Not tainted 4.2.0-rc5-next-20150805 #434^M
    [  359.055679] Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011^M
    [  359.055682] task: ffff8802161cc000 ti: ffff88021b4a8000 task.ti: ffff88021b4a8000^M
    [  359.055693] RIP: 0010:[<ffffffff811541c5>]  [<ffffffff811541c5>] __kmalloc 0xe8/0x152^M
    
    Cc: <[email protected]>
    Signed-off-by: Ming Lei <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit da0b5e40ab10f44019a1ecec09fadfcd5bdb76b6
Author: Dan Carpenter <[email protected]>
Date:   Sat Aug 15 11:38:13 2015 -0400

    ext4: silence a format string false positive
    
    Static checkers complain that the format string should be "%s".  It does
    not make a difference for the current code.
    
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>

commit 9810446836ab5a4b34a749bb77f3eb5836f982cc
Author: Dan Carpenter <[email protected]>
Date:   Sat Aug 15 11:30:31 2015 -0400

    ext4: simplify some code in read_mmp_block()
    
    My static check complains because we have:
    
    	if (!*bh)
    		return -ENOMEM;
    	if (*bh) {
    
    The second check is unnecessary.
    
    I've simplified this code by moving the "if (!*bh)" checks around.  Also
    Andreas Dilger says we should probably print a warning if sb_getblk()
    fails.
    
    [ Restructured the code so that we print a warning message as well if
      the mmp block doesn't check out, and to print the error code to
      disambiguate between the error cases.  - TYT ]
    
    Reviewed-by: Andreas Dilger <[email protected]>
    Signed-off-by: Dan Carpenter <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>

commit c642dc9e1aaed953597e7092d7df329e6234096e
Author: Eric Sandeen <[email protected]>
Date:   Sat Aug 15 10:45:06 2015 -0400

    ext4: don't manipulate recovery flag when freezing no-journal fs
    
    At some point along this sequence of changes:
    
    f6e63f9 ext4: fold ext4_nojournal_sops into ext4_sops
    bb04457 ext4: support freezing ext2 (nojournal) file systems
    9ca9238 ext4: Use separate super_operations structure for no_journal filesystems
    
    ext4 started setting needs_recovery on filesystems without journals
    when they are unfrozen.  This makes no sense, and in fact confuses
    blkid to the point where it doesn't recognize the filesystem at all.
    
    (freeze ext2; unfreeze ext2; run blkid; see no output; run dumpe2fs,
    see needs_recovery set on fs w/ no journal).
    
    To fix this, don't manipulate the INCOMPAT_RECOVER feature on
    filesystems without journals.
    
    Reported-by: Stu Mark <[email protected]>
    Reviewed-by: Jan Kara <[email protected]>
    Signed-off-by: Eric Sandeen <[email protected]>
    Signed-off-by: Theodore Ts'o <[email protected]>
    Cc: [email protected]

commit 3c1dd7411ccc1d151bd4f5d2b6d07c7272d86dc0
Author: Benjamin Cama <[email protected]>
Date:   Tue Jul 14 16:25:58 2015  0200

    ARM: orion5x: fix legacy orion5x IRQ numbers
    
    Since v3.18, attempts to deliver IRQ0 are rejected, breaking orion5x.
    Fix this by increasing all interrupts by one, as did 5d6bed2a9c8b for
    dove. Also, force MULTI_IRQ_HANDLER for all orion platforms (including
    dove) as the specific handler is needed to shift back IRQ numbers by
    one.
    
    [[email protected]]: moved the select
    MULTI_IRQ_HANDLER from PLAT_ORION_LEGACY to ARCH_ORION5X as it broke
    the build for dove.
    
    Fixes: a71b092a9c68 ("ARM: Convert handle_IRQ to use __handle_domain_irq")
    Signed-off-by: Benjamin Cama <[email protected]>
    Signed-off-by: Gregory CLEMENT <[email protected]>
    Cc: <[email protected]>

commit 601e4576863543200bde9201e4d23242e73a778b
Author: Ricard Wanderlof <[email protected]>
Date:   Thu Aug 13 15:10:19 2015  0200

    ASoC: ssm2518: Add explicit device tree support
    
    Add OF match table to SSM2518 to allow direct matching without going
    through I2C subsystem.
    
    Signed-off-by: Ricard Wanderlof <[email protected]>
    Acked-by: Lars-Peter Clausen <[email protected]>
    Signed-off-by: Mark Brown <[email protected]>

commit 1afb9c539daebc2c8a7b33d0e0b8fc9f74671b02
Author: Viresh Kumar <[email protected]>
Date:   Thu Jul 30 12:40:35 2015  0530

    thermal/cpu_cooling: update policy limits if clipped_freq < policy->max
    
    policy->max is the maximum allowed frequency defined by user and
    clipped_freq is the maximum that thermal constraints allow.
    
    If clipped_freq is lower than policy->max, then we need to readjust
    policy->max.
    
    But, if clipped_freq is greater than policy->max, we don't need to do
    anything. We used to call cpufreq_verify_within_limits() in this case,
    but it doesn't change anything in this case.
    
    Lets skip this unnecessary call and write a comment that explains this.
    
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Eduardo Valentin <[email protected]>

commit abcbcc25cb3edfc3c9af210a88c9386e353191fe
Author: Viresh Kumar <[email protected]>
Date:   Thu Jul 30 12:40:34 2015  0530

    thermal/cpu_cooling: rename max_freq as clipped_freq in notifier
    
    That's what it is for, lets name it properly.
    
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Eduardo Valentin <[email protected]>

commit 59f0d21883f39d27f14408d4ca211dce80658963
Author: Viresh Kumar <[email protected]>
Date:   Thu Jul 30 12:40:33 2015  0530

    thermal/cpu_cooling: rename cpufreq_val as clipped_freq
    
    That's what it is for, lets name it properly.
    
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Eduardo Valentin <[email protected]>

commit a24af233a1fd09002cabc05d6da248cc5656a2e1
Author: Viresh Kumar <[email protected]>
Date:   Thu Jul 30 12:40:32 2015  0530

    thermal/cpu_cooling: convert 'switch' block to 'if' block in notifier
    
    We just need to take care of single event here and there is no need to
    increase indentation level of most of the code (which causes lines
    longer that 80 columns to break).
    
    Kill the switch block.
    
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Eduardo Valentin <[email protected]>

commit 166529c9b6f91b97d771e2e7ebf748aadb239b44
Author: Viresh Kumar <[email protected]>
Date:   Thu Jul 30 12:40:31 2015  0530

    thermal/cpu_cooling: quit early after updating policy
    
    If a valid cpufreq_dev is found for policy->cpu, we should update the
    policy and quit the for loop. There is no need to keep traversing the
    list of cpufreq_dev's.
    
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Eduardo Valentin <[email protected]>

commit 76fd38ce21de506a3867768fac42729eb6d7dedf
Author: Viresh Kumar <[email protected]>
Date:   Thu Jul 30 12:40:30 2015  0530

    thermal/cpu_cooling: No need to initialize max_freq to 0
    
    Its always set before getting used, don't initialize it.
    
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Eduardo Valentin <[email protected]>

commit 02373d7c69b4270bbab930f8a81b0721be794347
Author: Russell King <rmk [email protected]>
Date:   Wed Aug 12 15:22:16 2015  0530

    thermal: cpu_cooling: fix lockdep problems in cpu_cooling
    
    A recent change to the cpu_cooling code introduced a AB-BA deadlock
    scenario between the cpufreq_policy_notifier_list rwsem and the
    cooling_cpufreq_lock.  This is caused by cooling_cpufreq_lock being held
    before the registration/removal of the notifier block (an operation
    which takes the rwsem), and the notifier code itself which takes the
    locks in the reverse order:
    
    ======================================================
    [ INFO: possible circular locking dependency detected ]
    3.18.0  #1453 Not tainted
    -------------------------------------------------------
    rc.local/770 is trying to acquire lock:
     (cooling_cpufreq_lock){ . . .}, at: [<c04abfc4>] cpufreq_thermal_notifier 0x34/0xfc
    
    but task is already holding lock:
     ((cpufreq_policy_notifier_list).rwsem){    . }, at: [<c0042f04>]  __blocking_notifier_call_chain 0x34/0x68
    
    which lock already depends on the new lock.
    
    the existing dependency chain (in reverse order) is:
    
    -> #1 ((cpufreq_policy_notifier_list).rwsem){    . }:
           [<c06bc3b0>] down_write 0x44/0x9c
           [<c0043444>] blocking_notifier_chain_register 0x28/0xd8
           [<c04ad610>] cpufreq_register_notifier 0x68/0x90
           [<c04abe4c>] __cpufreq_cooling_register.part.1 0x120/0x180
           [<c04abf44>] __cpufreq_cooling_register 0x98/0xa4
           [<c04abf8c>] cpufreq_cooling_register 0x18/0x1c
           [<bf0046f8>] imx_thermal_probe 0x1c0/0x470 [imx_thermal]
           [<c037cef8>] platform_drv_probe 0x50/0xac
           [<c037b710>] driver_probe_device 0x114/0x234
           [<c037b8cc>] __driver_attach 0x9c/0xa0
           [<c0379d68>] bus_for_each_dev 0x5c/0x90
           [<c037b204>] driver_attach 0x24/0x28
           [<c037ae7c>] bus_add_driver 0xe0/0x1d8
           [<c037c0cc>] driver_register 0x80/0xfc
           [<c037cd80>] __platform_driver_register 0x50/0x64
           [<bf007018>] 0xbf007018
           [<c0008a5c>] do_one_initcall 0x88/0x1d8
           [<c0095da4>] load_module 0x1768/0x1ef8
           [<c0096614>] SyS_init_module 0xe0/0xf4
           [<c000ec00>] ret_fast_syscall 0x0/0x48
    
    -> #0 (cooling_cpufreq_lock){ . . .}:
           [<c00619f8>] lock_acquire 0xb0/0x124
           [<c06ba3b4>] mutex_lock_nested 0x5c/0x3d8
           [<c04abfc4>] cpufreq_thermal_notifier 0x34/0xfc
           [<c0042bf4>] notifier_call_chain 0x4c/0x8c
           [<c0042f20>] __blocking_notifier_call_chain 0x50/0x68
           [<c0042f58>] blocking_notifier_call_chain 0x20/0x28
           [<c04ae62c>] cpufreq_set_policy 0x7c/0x1d0
           [<c04af3cc>] store_scaling_governor 0x74/0x9c
           [<c04ad418>] store 0x90/0xc0
           [<c0175384>] sysfs_kf_write 0x54/0x58
           [<c01746b4>] kernfs_fop_write 0xdc/0x190
           [<c010dcc0>] vfs_write 0xac/0x1b4
           [<c010dfec>] SyS_write 0x44/0x90
           [<c000ec00>] ret_fast_syscall 0x0/0x48
    
    other info that might help us debug this:
    
     Possible unsafe locking scenario:
    
           CPU0                    CPU1
           ----                    ----
      lock((cpufreq_policy_notifier_list).rwsem);
                                   lock(cooling_cpufreq_lock);
                                   lock((cpufreq_policy_notifier_list).rwsem);
      lock(cooling_cpufreq_lock);
    
     *** DEADLOCK ***
    
    7 locks held by rc.local/770:
     #0:  (sb_writers#6){. . . }, at: [<c010dda0>] vfs_write 0x18c/0x1b4
     #1:  (&of->mutex){ . . .}, at: [<c0174678>] kernfs_fop_write 0xa0/0x190
     #2:  (s_active#52){. . . }, at: [<c0174680>] kernfs_fop_write 0xa8/0x190
     #3:  (cpu_hotplug.lock){      }, at: [<c0026a60>] get_online_cpus 0x34/0x90
     #4:  (cpufreq_rwsem){. . . }, at: [<c04ad3e0>] store 0x58/0xc0
     #5:  (&policy->rwsem){ . . .}, at: [<c04ad3f8>] store 0x70/0xc0
     #6:  ((cpufreq_policy_notifier_list).rwsem){    . }, at: [<c0042f04>] __blocking_notifier_call_chain 0x34/0x68
    
    stack backtrace:
    CPU: 0 PID: 770 Comm: rc.local Not tainted 3.18.0  #1453
    Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
    Backtrace:
    [<c00121c8>] (dump_backtrace) from [<c0012360>] (show_stack 0x18/0x1c)
     r6:c0b85a80 r5:c0b75630 r4:00000000 r3:00000000
    [<c0012348>] (show_stack) from [<c06b6c48>] (dump_stack 0x7c/0x98)
    [<c06b6bcc>] (dump_stack) from [<c06b42a4>] (print_circular_bug 0x28c/0x2d8)
     r4:c0b85a80 r3:d0071d40
    [<c06b4018>] (print_circular_bug) from [<c00613b0>] (__lock_acquire 0x1acc/0x1bb0)
     r10:c0b50660 r8:c09e6d80 r7:d0071d40 r6:c11d0f0c r5:00000007 r4:d0072240
    [<c005f8e4>] (__lock_acquire) from [<c00619f8>] (lock_acquire 0xb0/0x124)
     r10:00000000 r9:c04abfc4 r8:00000000 r7:00000000 r6:00000000 r5:c0a06f0c
     r4:00000000
    [<c0061948>] (lock_acquire) from [<c06ba3b4>] (mutex_lock_nested 0x5c/0x3d8)
     r10:ec853800 r9:c0a06ed4 r8:d0071d40 r7:c0a06ed4 r6:c11d0f0c r5:00000000
     r4:c04abfc4
    [<c06ba358>] (mutex_lock_nested) from [<c04abfc4>] (cpufreq_thermal_notifier 0x34/0xfc)
     r10:ec853800 r9:ec85380c r8:d00d7d3c r7:c0a06ed4 r6:d00d7d3c r5:00000000
     r4:fffffffe
    [<c04abf90>] (cpufreq_thermal_notifier) from [<c0042bf4>] (notifier_call_chain 0x4c/0x8c)
     r7:00000000 r6:00000000 r5:00000000 r4:fffffffe
    [<c0042ba8>] (notifier_call_chain) from [<c0042f20>] (__blocking_notifier_call_chain 0x50/0x68)
     r8:c0a072a4 r7:00000000 r6:d00d7d3c r5:ffffffff r4:c0a06fc8 r3:ffffffff
    [<c0042ed0>] (__blocking_notifier_call_chain) from [<c0042f58>] (blocking_notifier_call_chain 0x20/0x28)
     r7:ec98b540 r6:c13ebc80 r5:ed76e600 r4:d00d7d3c
    [<c0042f38>] (blocking_notifier_call_chain) from [<c04ae62c>] (cpufreq_set_policy 0x7c/0x1d0)
    [<c04ae5b0>] (cpufreq_set_policy) from [<c04af3cc>] (store_scaling_governor 0x74/0x9c)
     r7:ec98b540 r6:0000000c r5:ec98b540 r4:ed76e600
    [<c04af358>] (store_scaling_governor) from [<c04ad418>] (store 0x90/0xc0)
     r6:0000000c r5:ed76e6d4 r4:ed76e600
    [<c04ad388>] (store) from [<c0175384>] (sysfs_kf_write 0x54/0x58)
     r8:0000000c r7:d00d7f78 r6:ec98b540 r5:0000000c r4:ec853800 r3:0000000c
    [<c0175330>] (sysfs_kf_write) from [<c01746b4>] (kernfs_fop_write 0xdc/0x190)
     r6:ec98b540 r5:00000000 r4:00000000 r3:c0175330
    [<c01745d8>] (kernfs_fop_write) from [<c010dcc0>] (vfs_write 0xac/0x1b4)
     r10:0162aa70 r9:d00d6000 r8:0000000c r7:d00d7f78 r6:0162aa70 r5:0000000c
     r4:eccde500
    [<c010dc14>] (vfs_write) from [<c010dfec>] (SyS_write 0x44/0x90)
     r10:0162aa70 r8:0000000c r7:eccde500 r6:eccde500 r5:00000000 r4:00000000
    [<c010dfa8>] (SyS_write) from [<c000ec00>] (ret_fast_syscall 0x0/0x48)
     r10:00000000 r8:c000edc4 r7:00000004 r6:000216cc r5:0000000c r4:0162aa70
    
    Solve this by moving to finer grained locking - use one mutex to protect
    the cpufreq_dev_list as a whole, and a separate lock to ensure correct
    ordering of cpufreq notifier registration and removal.
    
    cooling_list_lock is taken within cooling_cpufreq_lock on
    (un)registration to preserve the behavior of the code, i.e. to
    atomically add/remove to the list and (un)register the notifier.
    
    Fixes: 2dcd851fe4b4 ("thermal: cpu_cooling: Update always cpufreq policy with
    Reviewed-by: Viresh Kumar <[email protected]>
    Signed-off-by: Russell King <rmk [email protected]>
    Signed-off-by: Viresh Kumar <[email protected]>
    Signed-off-by: Eduardo Valentin <[email protected]>

commit 92f26189b181a65fcb1ff6220a4bf45d44502e4a
Author: Sudip Mukherjee <[email protected]>
Date:   Thu Aug 13 19:06:05 2015  0530

    auxdisplay: ks0108: initialize local parport variable
    
    The local variable ks0108_parport is used by other functions to write to
    the parallel port. We missed initializing it when we converted the
    driver to use new Parallel Port codes.
    
    Fixes: 4edd70c133f3 ("auxdisplay: ks0108: use new parport device model")
    Reported-by: Fengguang Wu <[email protected]>
    Signed-off-by: Sudip Mukherjee <[email protected]>
    Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 22de5f8bf8c0c03b775cc35cbe0e2c4d43d75f5a
Author: Jaegeuk Kim <[email protected]>
Date:   Tue Aug 11 21:59:49 2015 -0700

    f2fs: skip checkpoint if there is no dirty and prefree segments
    
    We should avoid needless checkpoints when there is no dirty and prefree segment.
    
    eviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>

commit 133acc6fa7c50d11da0138ad5039bb299c343dd5
Author: Chao Yu <[email protected]>
Date:   Tue Jul 28 18:33:46 2015  0800

    f2fs: shrink free_nids entries
    
    This patch introduces __count_free_nids/try_to_free_nids and registers
    them in slab shrinker for shrinking under memory pressure.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>

commit 2d69049ad68145747641e336681a43d17bfb0aaf
Author: Chao Yu <[email protected]>
Date:   Wed Aug 12 17:48:21 2015  0800

    f2fs: avoid clear valid page
    
    In f2fs_delete_entry, if last dirent is remove from the dentry page,
    we will try to punch that page since it has no valid date in it.
    
    But truncate_hole which is used for punching could fail because of
    no memory or IO error, if that happened, we'd better skip clearing
    this valid dentry page.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>

commit 19b1f190271a345137c1139bef3573173d714cfd
Author: Chao Yu <[email protected]>
Date:   Wed Aug 12 17:47:08 2015  0800

    MAINTAINERS: add myself as a dedicated reviewer of f2fs
    
    I volunteer to be a dedicated reviewer of f2fs, add my email address in
    maintainship entry of f2fs.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>

commit f706ffe3f7a6b8fdc7251d68d8689a0d9546500c
Author: Jaegeuk Kim <[email protected]>
Date:   Tue Aug 11 12:45:39 2015 -0700

    f2fs: do not write any node pages related to orphan inodes
    
    We should not write node pages when deleting orphan inodes.
    In order to do that, we can eaisly set POR_DOING flag earlier before entering
    orphan inode routine.
    
    Signed-off-by: Jaegeuk Kim <[email protected]>

commit 4c278394b0feb7aadc538be12ab0474b106a7255
Author: Jaegeuk Kim <[email protected]>
Date:   Tue Aug 11 16:01:30 2015 -0700

    f2fs: avoid a build warning
    
    If F2FS_CHECK_FS is turned off, we can get a build warning for unused variable.
    
    Signed-off-by: Jaegeuk Kim <[email protected]>

commit 8c14bfadeac2a01b305ef4434907295b81b58db2
Author: Chao Yu <[email protected]>
Date:   Fri Aug 7 17:58:43 2015  0800

    f2fs: handle error of f2fs_iget correctly
    
    In recover_orphan_inode, whenever f2fs_iget fail, we will make kernel panic,
    but it's not reasonable, because f2fs_iget can fail due to a lot of reasons
    including out of memory.
    
    So we change error handling method as below:
    a) when finding no entry for the orphan inode, bug_on for catching bugs;
    b) for other reasons, report it to caller.
    
    Signed-off-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>

commit 47e70ca46f9074efe6573263c0de5bef0af829de
Author: Jaegeuk Kim <[email protected]>
Date:   Tue Aug 11 10:17:27 2015 -0700

    f2fs: do not assign a new segment for dio under space shortage
    
    If there is not enough free segment, we should not assign a new segment
    explicitly. Otherwise, we can run out of free segment.
    
    Reviewed-by: Chao Yu <[email protected]>
    Signed-off-by: Jaegeuk Kim <[email protected]>

commit 4d283ec908e617fa28bcb06bce310206f0655d67
Author: Andy Lutomirski <[email protected]>
Date:   Thu Aug 13 13:18:48 2015 -0700

    x86/kvm: Rename VMX's segment access rights defines
    
    VMX encodes access rights differently from LAR, and the latter is
    most likely what x86 people think of when they think of "access
    rights".
    
    Rename them to avoid confusion.
    
    Cc: [email protected]
    Signed-off-by: Andy Lutomirski <[email protected]>
    Signed-off-by: Paolo Bonzini <[email protected]>

commit 5417cb576a80d3fab0437c13163e8f71aa58dc50
Author: Alexandre Belloni <[email protected]>
Date:   Tue Aug 4 11:33:59 2015  0200

    rtc: rx8025: check time validity when necessary
    
    Check time validity when reading time as this is when we need to know.
    
    Signed-off-by: Alexandre Belloni <[email protected]>

commit 115a7a530d303f47a37468b3c284dcba999a8ac5
Author: Alexandre Belloni <[email protected]>
Date:   Tue Aug 4 11:24:33 2015  0200

    rtc: rx8025: fix RX8025_BIT_CTRL2_CTFG initialization
    
    RX8025_BIT_CTRL2_CTFG was set to 0 only when it was already 0.
    
    Signed-off-by: Alexandre Belloni <[email protected]>

commit bf4b02d33764ce8d06a1e6091a7ea673cd7d3935
Author: Alexandre Belloni <[email protected]>
Date:   Tue Aug 4 10:56:50 2015  0200

    rtc: rx8025: remove useless initialization
    
    irq_freq is already initialized to 1 in rtc_device_register()
    
    Signed-off-by: Alexandre Belloni <[email protected]>

commit 25f8014d5f584803d1706a2c785d4b4f12c874d5
Author: Alexandre Belloni <[email protected]>
Date:   Tue Aug 4 10:48:20 2015  0200

    rtc: rx8025: reset validity when setting time
    
    Wait for the user to set the time to reset the validity bits. Until then,
    the time may be invalid.
    
    Signed-off-by: Alexandre Belloni <[email protected]>

commit 647ce61d8fbfd69c4743a5e8aff935954cae326c
Author: Alexandre Belloni <[email protected]>
Date:   Tue Aug 4 10:46:22 2015  0200

    rtc: rx8025: fix rx8025_init_client()
    
    rx8025_init_client is modifying ctrl[0] and writing it to RX8025_REG_CTRL2
    but ctrl[0] is actually RX8025_REG_CTRL1.
    
    Signed-off-by: Alexandre Belloni <[email protected]>

commit 42e0f616eff588f4d211511b76e17af846ad5bf7
Author: Alexandre Belloni <[email protected]>
Date:   Tue Aug 4 00:45:37 2015  0200

    rtc: rx8025: continue without alarm when irq request fails
    
    Instead of bailing out, disable alarms and continue when
    devm_request_threaded_irq() fails. This allows to still provide some
    functionality.
    
    Signed-off-by: Alexandre Belloni <[email protected]>

commit 89b43e9954f105656cea8985a361be45b107495f
Author: Alexandre Belloni <[email protected]>
Date:   Tue Aug 4 00:40:25 2015  0200

    rtc: rx8025: cleanup accessors
    
    Remove useless error messages, at that point, the user already knows
    something went wrong but will not be able to do anything about it anyway.
    It is also highly unlikely that some registers are readable/writable
    but not some other ones.
    
    Also, transform rx8025_read_reg to be more resemblant to
    i2c_smbus_read_byte_data()
    
    Signed-off-by: Alexandre Belloni <[email protected]>

commit 8f2e038d69db32e113a09c0e74616d5dc0637740
Author: Alexandre Belloni <[email protected]>
Date:   Sun Jul 26 10:13:31 2015  0200

    rtc: rx8025: don't reset the time
    
    Stop setting the time to epoch when it is invalid. The proper way to handle
    that is to return an error whe…

kasan reported the following error when i ran xfstest:

[  701.826854] ==================================================================
[  701.826864] BUG: KASAN: use-after-free in dio_bio_complete 0x41a/0x600 at addr ffff880080b95f94
[  701.826870] Read of size 4 by task loop2/3874
[  701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping:          (null) index:0x0
[  701.826890] flags: 0x100000000000000()
[  701.826895] page dumped because: kasan: bad access detected
[  701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G    B   W    L  4.5.0-rc1-next-20160129 torvalds#83
[  701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[  701.826917]  ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3
[  701.826941]  ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c
[  701.826963]  0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540
[  701.826987] Call Trace:
[  701.826997]  [<ffffffff81ca67bb>] dump_stack 0x97/0xdc
[  701.827005]  [<ffffffff81ca6724>] ? _atomic_dec_and_lock 0xc4/0xc4
[  701.827014]  [<ffffffff8161c05c>] ? __dump_page 0x32c/0x490
[  701.827023]  [<ffffffff816b0d03>] kasan_report_error 0x5f3/0x8b0
[  701.827033]  [<ffffffff817c302a>] ? dio_bio_complete 0x41a/0x600
[  701.827040]  [<ffffffff816b1119>] __asan_report_load4_noabort 0x59/0x80
[  701.827048]  [<ffffffff817c302a>] ? dio_bio_complete 0x41a/0x600
[  701.827053]  [<ffffffff817c302a>] dio_bio_complete 0x41a/0x600
[  701.827057]  [<ffffffff81bd19c8>] ? blk_queue_exit 0x108/0x270
[  701.827060]  [<ffffffff817c32b0>] dio_bio_end_aio 0xa0/0x4d0
[  701.827063]  [<ffffffff817c3210>] ? dio_bio_complete 0x600/0x600
[  701.827067]  [<ffffffff81bd2806>] ? blk_account_io_completion 0x316/0x5d0
[  701.827070]  [<ffffffff81bafe89>] bio_endio 0x79/0x200
[  701.827074]  [<ffffffff81bd2c9f>] blk_update_request 0x1df/0xc50
[  701.827078]  [<ffffffff81c02c27>] blk_mq_end_request 0x57/0x120
[  701.827081]  [<ffffffff81c03670>] __blk_mq_complete_request 0x310/0x590
[  701.827084]  [<ffffffff812348d8>] ? set_next_entity 0x2f8/0x2ed0
[  701.827088]  [<ffffffff8124b34d>] ? put_prev_entity 0x22d/0x2a70
[  701.827091]  [<ffffffff81c0394b>] blk_mq_complete_request 0x5b/0x80
[  701.827094]  [<ffffffff821e2a33>] loop_queue_work 0x273/0x19d0
[  701.827098]  [<ffffffff811f6578>] ? finish_task_switch 0x1c8/0x8e0
[  701.827101]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller 0x18/0x6c0
[  701.827104]  [<ffffffff821e27c0>] ? lo_read_simple 0x890/0x890
[  701.827108]  [<ffffffff8129dd60>] ? debug_check_no_locks_freed 0x350/0x350
[  701.827111]  [<ffffffff811f63b0>] ? __hrtick_start 0x130/0x130
[  701.827115]  [<ffffffff82a0c8f6>] ? __schedule 0x936/0x20b0
[  701.827118]  [<ffffffff811dd6bd>] ? kthread_worker_fn 0x3ed/0x8d0
[  701.827121]  [<ffffffff811dd4ed>] ? kthread_worker_fn 0x21d/0x8d0
[  701.827125]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller 0x18/0x6c0
[  701.827128]  [<ffffffff811dd57f>] kthread_worker_fn 0x2af/0x8d0
[  701.827132]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827135]  [<ffffffff82a1ea46>] ? _raw_spin_unlock_irqrestore 0x36/0x60
[  701.827138]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827141]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827144]  [<ffffffff811dd00b>] kthread 0x24b/0x3a0
[  701.827148]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827151]  [<ffffffff8129d70d>] ? trace_hardirqs_on 0xd/0x10
[  701.827155]  [<ffffffff8116d41d>] ? do_group_exit 0xdd/0x350
[  701.827158]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827161]  [<ffffffff82a1f52f>] ret_from_fork 0x3f/0x70
[  701.827165]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827167] Memory state around the buggy address:
[  701.827170]  ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827172]  ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827177]                          ^
[  701.827179]  ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827182]  ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827183] ==================================================================

The problem is that bio_check_pages_dirty calls bio_put, so we must
not access bio fields after bio_check_pages_dirty.

Fixes: 9b81c84 ("block: don't access bio->bi_error after
       bio_put()").

Signed-off-by: Mike Krinkin <[email protected]>

kasan reported the following error when i ran xfstest:

[  701.826854] ==================================================================
[  701.826864] BUG: KASAN: use-after-free in dio_bio_complete 0x41a/0x600 at addr ffff880080b95f94
[  701.826870] Read of size 4 by task loop2/3874
[  701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping:          (null) index:0x0
[  701.826890] flags: 0x100000000000000()
[  701.826895] page dumped because: kasan: bad access detected
[  701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G    B   W    L  4.5.0-rc1-next-20160129 #83
[  701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[  701.826917]  ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3
[  701.826941]  ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c
[  701.826963]  0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540
[  701.826987] Call Trace:
[  701.826997]  [<ffffffff81ca67bb>] dump_stack 0x97/0xdc
[  701.827005]  [<ffffffff81ca6724>] ? _atomic_dec_and_lock 0xc4/0xc4
[  701.827014]  [<ffffffff8161c05c>] ? __dump_page 0x32c/0x490
[  701.827023]  [<ffffffff816b0d03>] kasan_report_error 0x5f3/0x8b0
[  701.827033]  [<ffffffff817c302a>] ? dio_bio_complete 0x41a/0x600
[  701.827040]  [<ffffffff816b1119>] __asan_report_load4_noabort 0x59/0x80
[  701.827048]  [<ffffffff817c302a>] ? dio_bio_complete 0x41a/0x600
[  701.827053]  [<ffffffff817c302a>] dio_bio_complete 0x41a/0x600
[  701.827057]  [<ffffffff81bd19c8>] ? blk_queue_exit 0x108/0x270
[  701.827060]  [<ffffffff817c32b0>] dio_bio_end_aio 0xa0/0x4d0
[  701.827063]  [<ffffffff817c3210>] ? dio_bio_complete 0x600/0x600
[  701.827067]  [<ffffffff81bd2806>] ? blk_account_io_completion 0x316/0x5d0
[  701.827070]  [<ffffffff81bafe89>] bio_endio 0x79/0x200
[  701.827074]  [<ffffffff81bd2c9f>] blk_update_request 0x1df/0xc50
[  701.827078]  [<ffffffff81c02c27>] blk_mq_end_request 0x57/0x120
[  701.827081]  [<ffffffff81c03670>] __blk_mq_complete_request 0x310/0x590
[  701.827084]  [<ffffffff812348d8>] ? set_next_entity 0x2f8/0x2ed0
[  701.827088]  [<ffffffff8124b34d>] ? put_prev_entity 0x22d/0x2a70
[  701.827091]  [<ffffffff81c0394b>] blk_mq_complete_request 0x5b/0x80
[  701.827094]  [<ffffffff821e2a33>] loop_queue_work 0x273/0x19d0
[  701.827098]  [<ffffffff811f6578>] ? finish_task_switch 0x1c8/0x8e0
[  701.827101]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller 0x18/0x6c0
[  701.827104]  [<ffffffff821e27c0>] ? lo_read_simple 0x890/0x890
[  701.827108]  [<ffffffff8129dd60>] ? debug_check_no_locks_freed 0x350/0x350
[  701.827111]  [<ffffffff811f63b0>] ? __hrtick_start 0x130/0x130
[  701.827115]  [<ffffffff82a0c8f6>] ? __schedule 0x936/0x20b0
[  701.827118]  [<ffffffff811dd6bd>] ? kthread_worker_fn 0x3ed/0x8d0
[  701.827121]  [<ffffffff811dd4ed>] ? kthread_worker_fn 0x21d/0x8d0
[  701.827125]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller 0x18/0x6c0
[  701.827128]  [<ffffffff811dd57f>] kthread_worker_fn 0x2af/0x8d0
[  701.827132]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827135]  [<ffffffff82a1ea46>] ? _raw_spin_unlock_irqrestore 0x36/0x60
[  701.827138]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827141]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827144]  [<ffffffff811dd00b>] kthread 0x24b/0x3a0
[  701.827148]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827151]  [<ffffffff8129d70d>] ? trace_hardirqs_on 0xd/0x10
[  701.827155]  [<ffffffff8116d41d>] ? do_group_exit 0xdd/0x350
[  701.827158]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827161]  [<ffffffff82a1f52f>] ret_from_fork 0x3f/0x70
[  701.827165]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827167] Memory state around the buggy address:
[  701.827170]  ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827172]  ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827177]                          ^
[  701.827179]  ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827182]  ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827183] ==================================================================

The problem is that bio_check_pages_dirty calls bio_put, so we must
not access bio fields after bio_check_pages_dirty.

Fixes: 9b81c84 ("block: don't access bio->bi_error after bio_put()").
Signed-off-by: Mike Krinkin <[email protected]>
Cc: [email protected]
Signed-off-by: Jens Axboe <[email protected]>

commit 7ddc971 upstream.

kasan reported the following error when i ran xfstest:

[  701.826854] ==================================================================
[  701.826864] BUG: KASAN: use-after-free in dio_bio_complete 0x41a/0x600 at addr ffff880080b95f94
[  701.826870] Read of size 4 by task loop2/3874
[  701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping:          (null) index:0x0
[  701.826890] flags: 0x100000000000000()
[  701.826895] page dumped because: kasan: bad access detected
[  701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G    B   W    L  4.5.0-rc1-next-20160129 torvalds#83
[  701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[  701.826917]  ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3
[  701.826941]  ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c
[  701.826963]  0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540
[  701.826987] Call Trace:
[  701.826997]  [<ffffffff81ca67bb>] dump_stack 0x97/0xdc
[  701.827005]  [<ffffffff81ca6724>] ? _atomic_dec_and_lock 0xc4/0xc4
[  701.827014]  [<ffffffff8161c05c>] ? __dump_page 0x32c/0x490
[  701.827023]  [<ffffffff816b0d03>] kasan_report_error 0x5f3/0x8b0
[  701.827033]  [<ffffffff817c302a>] ? dio_bio_complete 0x41a/0x600
[  701.827040]  [<ffffffff816b1119>] __asan_report_load4_noabort 0x59/0x80
[  701.827048]  [<ffffffff817c302a>] ? dio_bio_complete 0x41a/0x600
[  701.827053]  [<ffffffff817c302a>] dio_bio_complete 0x41a/0x600
[  701.827057]  [<ffffffff81bd19c8>] ? blk_queue_exit 0x108/0x270
[  701.827060]  [<ffffffff817c32b0>] dio_bio_end_aio 0xa0/0x4d0
[  701.827063]  [<ffffffff817c3210>] ? dio_bio_complete 0x600/0x600
[  701.827067]  [<ffffffff81bd2806>] ? blk_account_io_completion 0x316/0x5d0
[  701.827070]  [<ffffffff81bafe89>] bio_endio 0x79/0x200
[  701.827074]  [<ffffffff81bd2c9f>] blk_update_request 0x1df/0xc50
[  701.827078]  [<ffffffff81c02c27>] blk_mq_end_request 0x57/0x120
[  701.827081]  [<ffffffff81c03670>] __blk_mq_complete_request 0x310/0x590
[  701.827084]  [<ffffffff812348d8>] ? set_next_entity 0x2f8/0x2ed0
[  701.827088]  [<ffffffff8124b34d>] ? put_prev_entity 0x22d/0x2a70
[  701.827091]  [<ffffffff81c0394b>] blk_mq_complete_request 0x5b/0x80
[  701.827094]  [<ffffffff821e2a33>] loop_queue_work 0x273/0x19d0
[  701.827098]  [<ffffffff811f6578>] ? finish_task_switch 0x1c8/0x8e0
[  701.827101]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller 0x18/0x6c0
[  701.827104]  [<ffffffff821e27c0>] ? lo_read_simple 0x890/0x890
[  701.827108]  [<ffffffff8129dd60>] ? debug_check_no_locks_freed 0x350/0x350
[  701.827111]  [<ffffffff811f63b0>] ? __hrtick_start 0x130/0x130
[  701.827115]  [<ffffffff82a0c8f6>] ? __schedule 0x936/0x20b0
[  701.827118]  [<ffffffff811dd6bd>] ? kthread_worker_fn 0x3ed/0x8d0
[  701.827121]  [<ffffffff811dd4ed>] ? kthread_worker_fn 0x21d/0x8d0
[  701.827125]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller 0x18/0x6c0
[  701.827128]  [<ffffffff811dd57f>] kthread_worker_fn 0x2af/0x8d0
[  701.827132]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827135]  [<ffffffff82a1ea46>] ? _raw_spin_unlock_irqrestore 0x36/0x60
[  701.827138]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827141]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827144]  [<ffffffff811dd00b>] kthread 0x24b/0x3a0
[  701.827148]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827151]  [<ffffffff8129d70d>] ? trace_hardirqs_on 0xd/0x10
[  701.827155]  [<ffffffff8116d41d>] ? do_group_exit 0xdd/0x350
[  701.827158]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827161]  [<ffffffff82a1f52f>] ret_from_fork 0x3f/0x70
[  701.827165]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827167] Memory state around the buggy address:
[  701.827170]  ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827172]  ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827177]                          ^
[  701.827179]  ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827182]  ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827183] ==================================================================

The problem is that bio_check_pages_dirty calls bio_put, so we must
not access bio fields after bio_check_pages_dirty.

Fixes: 9b81c84 ("block: don't access bio->bi_error after bio_put()").
Signed-off-by: Mike Krinkin <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

commit 7ddc971 upstream.

kasan reported the following error when i ran xfstest:

[  701.826854] ==================================================================
[  701.826864] BUG: KASAN: use-after-free in dio_bio_complete 0x41a/0x600 at addr ffff880080b95f94
[  701.826870] Read of size 4 by task loop2/3874
[  701.826879] page:ffffea000202e540 count:0 mapcount:0 mapping:          (null) index:0x0
[  701.826890] flags: 0x100000000000000()
[  701.826895] page dumped because: kasan: bad access detected
[  701.826904] CPU: 3 PID: 3874 Comm: loop2 Tainted: G    B   W    L  4.5.0-rc1-next-20160129 torvalds#83
[  701.826910] Hardware name: LENOVO 23205NG/23205NG, BIOS G2ET95WW (2.55 ) 07/09/2013
[  701.826917]  ffff88008fadf800 ffff88008fadf758 ffffffff81ca67bb 0000000041b58ab3
[  701.826941]  ffffffff830d1e74 ffffffff81ca6724 ffff88008fadf748 ffffffff8161c05c
[  701.826963]  0000000000000282 ffff88008fadf800 ffffed0010172bf2 ffffea000202e540
[  701.826987] Call Trace:
[  701.826997]  [<ffffffff81ca67bb>] dump_stack 0x97/0xdc
[  701.827005]  [<ffffffff81ca6724>] ? _atomic_dec_and_lock 0xc4/0xc4
[  701.827014]  [<ffffffff8161c05c>] ? __dump_page 0x32c/0x490
[  701.827023]  [<ffffffff816b0d03>] kasan_report_error 0x5f3/0x8b0
[  701.827033]  [<ffffffff817c302a>] ? dio_bio_complete 0x41a/0x600
[  701.827040]  [<ffffffff816b1119>] __asan_report_load4_noabort 0x59/0x80
[  701.827048]  [<ffffffff817c302a>] ? dio_bio_complete 0x41a/0x600
[  701.827053]  [<ffffffff817c302a>] dio_bio_complete 0x41a/0x600
[  701.827057]  [<ffffffff81bd19c8>] ? blk_queue_exit 0x108/0x270
[  701.827060]  [<ffffffff817c32b0>] dio_bio_end_aio 0xa0/0x4d0
[  701.827063]  [<ffffffff817c3210>] ? dio_bio_complete 0x600/0x600
[  701.827067]  [<ffffffff81bd2806>] ? blk_account_io_completion 0x316/0x5d0
[  701.827070]  [<ffffffff81bafe89>] bio_endio 0x79/0x200
[  701.827074]  [<ffffffff81bd2c9f>] blk_update_request 0x1df/0xc50
[  701.827078]  [<ffffffff81c02c27>] blk_mq_end_request 0x57/0x120
[  701.827081]  [<ffffffff81c03670>] __blk_mq_complete_request 0x310/0x590
[  701.827084]  [<ffffffff812348d8>] ? set_next_entity 0x2f8/0x2ed0
[  701.827088]  [<ffffffff8124b34d>] ? put_prev_entity 0x22d/0x2a70
[  701.827091]  [<ffffffff81c0394b>] blk_mq_complete_request 0x5b/0x80
[  701.827094]  [<ffffffff821e2a33>] loop_queue_work 0x273/0x19d0
[  701.827098]  [<ffffffff811f6578>] ? finish_task_switch 0x1c8/0x8e0
[  701.827101]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller 0x18/0x6c0
[  701.827104]  [<ffffffff821e27c0>] ? lo_read_simple 0x890/0x890
[  701.827108]  [<ffffffff8129dd60>] ? debug_check_no_locks_freed 0x350/0x350
[  701.827111]  [<ffffffff811f63b0>] ? __hrtick_start 0x130/0x130
[  701.827115]  [<ffffffff82a0c8f6>] ? __schedule 0x936/0x20b0
[  701.827118]  [<ffffffff811dd6bd>] ? kthread_worker_fn 0x3ed/0x8d0
[  701.827121]  [<ffffffff811dd4ed>] ? kthread_worker_fn 0x21d/0x8d0
[  701.827125]  [<ffffffff8129d058>] ? trace_hardirqs_on_caller 0x18/0x6c0
[  701.827128]  [<ffffffff811dd57f>] kthread_worker_fn 0x2af/0x8d0
[  701.827132]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827135]  [<ffffffff82a1ea46>] ? _raw_spin_unlock_irqrestore 0x36/0x60
[  701.827138]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827141]  [<ffffffff811dd2d0>] ? __init_kthread_worker 0x170/0x170
[  701.827144]  [<ffffffff811dd00b>] kthread 0x24b/0x3a0
[  701.827148]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827151]  [<ffffffff8129d70d>] ? trace_hardirqs_on 0xd/0x10
[  701.827155]  [<ffffffff8116d41d>] ? do_group_exit 0xdd/0x350
[  701.827158]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827161]  [<ffffffff82a1f52f>] ret_from_fork 0x3f/0x70
[  701.827165]  [<ffffffff811dcdc0>] ? kthread_create_on_node 0x4c0/0x4c0
[  701.827167] Memory state around the buggy address:
[  701.827170]  ffff880080b95e80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827172]  ffff880080b95f00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827175] >ffff880080b95f80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827177]                          ^
[  701.827179]  ffff880080b96000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827182]  ffff880080b96080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[  701.827183] ==================================================================

The problem is that bio_check_pages_dirty calls bio_put, so we must
not access bio fields after bio_check_pages_dirty.

Fixes: 9b81c84 ("block: don't access bio->bi_error after bio_put()").
Signed-off-by: Mike Krinkin <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

Signed-off-by: Sasha Levin <[email protected]>

There is at least one Chelsio 10Gb card which uses VPD area to store
some custom blocks (example below). However pci_vpd_size() returns
the length of the first block only assuming that there can be only
one VPD "End Tag" and VFIO blocks access beyond that offset
(since 4e1a635) which leads to the situation when the guest "cxgb3"
driver fails to probe the device. The host system does not have this
problem as the drives accesses the config space directly without
pci_read_vpd()/...

This adds a quirk to override the VPD size to a bigger value.
The maximum size is taken from EEPROMSIZE in
drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag
as the cxgb3 driver does as the driver supports writing to EEPROM/VPD
and when it writes, it only checks for 8192 bytes boundary. The quirk
is registerted for all devices supported by the cxgb3 driver.

This adds a quirk to the PCI layer (not to the cxgb3 driver) as
the cxgb3 driver itself accesses VPD directly and the problem only exists
with the vfio-pci driver (when cxgb3 is not running on the host and
may not be even loaded) which blocks accesses beyond the first block
of VPD data. However vfio-pci itself does not have quirks mechanism so
we add it to PCI.

Tested on:
Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]

This is its VPD:
0000 Large item 42 bytes; name 0x2 Identifier String
	b'10 Gigabit Ethernet-SR PCI Express Adapter'
	#00 [EC] len=7: b'D76809 '
	#0a [FN] len=7: b'46K7897'
	torvalds#14 [PN] len=7: b'46K7897'
	#1e [MN] len=4: b'1037'
	torvalds#25 [FC] len=4: b'5769'
	#2c [SN] len=12: b'YL102035603V'
	#3b [NA] len=12: b'00145E992ED1'

0c00 Large item 16 bytes; name 0x2 Identifier String
        b'S310E-SR-X      '
0c13 Large item 234 bytes; name 0x10
        #00 [PN] len=16: b'TBD             '
        torvalds#13 [EC] len=16: b'110107730D2     '
        torvalds#26 [SN] len=16: b'97YL102035603V  '
        torvalds#39 [NA] len=12: b'00145E992ED1'
        torvalds#48 [V0] len=6: b'175000'
        torvalds#51 [V1] len=6: b'266666'
        #5a [V2] len=6: b'266666'
        torvalds#63 [V3] len=6: b'2000  '
        #6c [V4] len=2: b'1 '
        torvalds#71 [V5] len=6: b'c2    '
        #7a [V6] len=6: b'0     '
        torvalds#83 [V7] len=2: b'1 '
        torvalds#88 [V8] len=2: b'0 '
        #8d [V9] len=2: b'0 '
        torvalds#92 [VA] len=2: b'0 '
        torvalds#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
0d00 Large item 252 bytes; name 0x11
        #00 [VC] len=16: b'122310_1222 dp  '
        torvalds#13 [VD] len=16: b'610-0001-00 H1\x00\x00'
        torvalds#26 [VE] len=16: b'122310_1353 fp  '
        torvalds#39 [VF] len=16: b'610-0001-00 H1\x00\x00'
        #4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
0dff Small item 0 bytes; name 0xf End Tag

Signed-off-by: Alexey Kardashevskiy <[email protected]>

There is at least one Chelsio 10Gb card which uses VPD area to store
some custom blocks (example below). However pci_vpd_size() returns
the length of the first block only assuming that there can be only
one VPD "End Tag" and VFIO blocks access beyond that offset
(since 4e1a635) which leads to the situation when the guest "cxgb3"
driver fails to probe the device. The host system does not have this
problem as the drives accesses the config space directly without
pci_read_vpd()/...

This adds a quirk to override the VPD size to a bigger value.
The maximum size is taken from EEPROMSIZE in
drivers/net/ethernet/chelsio/cxgb3/common.h. We do not read the tag
as the cxgb3 driver does as the driver supports writing to EEPROM/VPD
and when it writes, it only checks for 8192 bytes boundary. The quirk
is registerted for all devices supported by the cxgb3 driver.

This adds a quirk to the PCI layer (not to the cxgb3 driver) as
the cxgb3 driver itself accesses VPD directly and the problem only exists
with the vfio-pci driver (when cxgb3 is not running on the host and
may not be even loaded) which blocks accesses beyond the first block
of VPD data. However vfio-pci itself does not have quirks mechanism so
we add it to PCI.

This is the controller:
Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]

This is what I parsed from its vpd:
===
b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K'
 0000 Large item 42 bytes; name 0x2 Identifier String
	b'10 Gigabit Ethernet-SR PCI Express Adapter'
 002d Large item 74 bytes; name 0x10
	#00 [EC] len=7: b'D76809 '
	#0a [FN] len=7: b'46K7897'
	torvalds#14 [PN] len=7: b'46K7897'
	#1e [MN] len=4: b'1037'
	torvalds#25 [FC] len=4: b'5769'
	#2c [SN] len=12: b'YL102035603V'
	#3b [NA] len=12: b'00145E992ED1'
 007a Small item 1 bytes; name 0xf End Tag

 0c00 Large item 16 bytes; name 0x2 Identifier String
	b'S310E-SR-X      '
 0c13 Large item 234 bytes; name 0x10
	#00 [PN] len=16: b'TBD             '
	torvalds#13 [EC] len=16: b'110107730D2     '
	torvalds#26 [SN] len=16: b'97YL102035603V  '
	torvalds#39 [NA] len=12: b'00145E992ED1'
	torvalds#48 [V0] len=6: b'175000'
	torvalds#51 [V1] len=6: b'266666'
	#5a [V2] len=6: b'266666'
	torvalds#63 [V3] len=6: b'2000  '
	#6c [V4] len=2: b'1 '
	torvalds#71 [V5] len=6: b'c2    '
	#7a [V6] len=6: b'0     '
	torvalds#83 [V7] len=2: b'1 '
	torvalds#88 [V8] len=2: b'0 '
	#8d [V9] len=2: b'0 '
	torvalds#92 [VA] len=2: b'0 '
	torvalds#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
 0d00 Large item 252 bytes; name 0x11
	#00 [VC] len=16: b'122310_1222 dp  '
	torvalds#13 [VD] len=16: b'610-0001-00 H1\x00\x00'
	torvalds#26 [VE] len=16: b'122310_1353 fp  '
	torvalds#39 [VF] len=16: b'610-0001-00 H1\x00\x00'
	#4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
 0dff Small item 0 bytes; name 0xf End Tag

10f3 Large item 13315 bytes; name 0x62
!!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00'
===

Signed-off-by: Alexey Kardashevskiy <[email protected]>

Linus Torvalds wrote:
> On Tue, Nov 1, 2016 at 8:36 AM, Tetsuo Handa
> <[email protected]> wrote:
> >
> > I got an Oops with khungtaskd. This kernel was built with CONFIG_THREAD_INFO_IN_TASK=y .
> > Is this same reason?
>
> CONFIG_THREAD_INFO_IN_TASK is always set on x86, but I assume you also
> did VMAP_STACK

Yes. And I wrote a reproducer.

---------- Reproducer start ----------
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
	if (fork() == 0)
		_exit(0);
	sleep(1);
	system("echo t > /proc/sysrq-trigger");
	return 0;
}
---------- Reproducer end ----------

---------- Serial console log start ----------
[  328.528734] a.out           x
[  328.529293] BUG: unable to handle kernel
[  328.530655] paging request at ffffc95001f43e18
[  328.531837] IP: [<ffffffff81026feb>] thread_saved_pc 0xb/0x20
[  328.533512] PGD 7f4c0067
[  328.533972] PUD 7f4c1067
[  328.535065] PMD 74cba067
[  328.535296] PTE 0

[  328.537173] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  328.538698] Modules linked in: ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter coretemp pcspkr sg i2c_piix4 shpchp vmw_vmci ip_tables sd_mod ata_generic pata_acpi serio_raw mptspi vmwgfx scsi_transport_spi drm_kms_helper ahci syscopyarea sysfillrect sysimgblt mptscsih e1000 fb_sys_fops libahci ttm drm mptbase ata_piix i2c_core libata
[  328.552465] CPU: 0 PID: 4299 Comm: sh Tainted: G        W       4.9.0-rc3  torvalds#83
[  328.554403] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/02/2015
[  328.556939] task: ffff8800792b5380 task.stack: ffffc95001f58000
[  328.558686] RIP: 0010:[<ffffffff81026feb>]  [<ffffffff81026feb>] thread_saved_pc 0xb/0x20
[  328.560926] RSP: 0018:ffffc95001f5bd28  EFLAGS: 00010202
[  328.562603] RAX: ffffc95001f43de8 RBX: ffff88007826d380 RCX: 0000000000000006
[  328.564507] RDX: 0000000000000000 RSI: ffffffff8197f2d1 RDI: ffff88007826d380
[  328.566437] RBP: ffffc95001f5bd28 R08: 0000000000000001 R09: 0000000000000001
[  328.568354] R10: 0000000000000001 R11: 0000000000000004 R12: 0000000000000007
[  328.570266] R13: ffff88007826d638 R14: ffff88007826d380 R15: 0000000000000002
[  328.572197] FS:  00007ff7b501e740(0000) GS:ffff88007c200000(0000) knlGS:0000000000000000
[  328.574303] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  328.576006] CR2: ffffc95001f43e18 CR3: 000000007894c000 CR4: 00000000001406f0
[  328.577995] Stack:
[  328.579024]  ffffc95001f5bd50 ffffffff810974c0 ffffc95001f5bd50 ffff88007826d380
[  328.581219]  0000000000000000 ffffc95001f5bd88 ffffffff81097767 ffffffff810976b0
[  328.583300]  ffffffff81c74e60 0000000000000074 0000000000000000 0000000000000007
[  328.585404] Call Trace:
[  328.586531]  [<ffffffff810974c0>] sched_show_task 0x50/0x240
[  328.588184]  [<ffffffff81097767>] show_state_filter 0xb7/0x190
[  328.589860]  [<ffffffff810976b0>] ? sched_show_task 0x240/0x240
[  328.591553]  [<ffffffff813fd4fb>] sysrq_handle_showstate 0xb/0x20
[  328.593304]  [<ffffffff813fdce6>] __handle_sysrq 0x136/0x220
[  328.863992]  [<ffffffff813fdbb0>] ? __sysrq_get_key_op 0x30/0x30
[  328.596678]  [<ffffffff813fe1f1>] write_sysrq_trigger 0x41/0x50
[  328.598386]  [<ffffffff81249c88>] proc_reg_write 0x38/0x70
[  328.600038]  [<ffffffff811dc802>] __vfs_write 0x32/0x140
[  328.601604]  [<ffffffff810dc797>] ? rcu_read_lock_sched_held 0x87/0x90
[  328.603365]  [<ffffffff810dcb2a>] ? rcu_sync_lockdep_assert 0x2a/0x50
[  328.605111]  [<ffffffff811e0279>] ? __sb_start_write 0x189/0x240
[  328.606735]  [<ffffffff811dd642>] ? vfs_write 0x182/0x1b0
[  328.608278]  [<ffffffff811dd570>] vfs_write 0xb0/0x1b0
[  328.609777]  [<ffffffff81002240>] ? syscall_trace_enter 0x1b0/0x240
[  328.611513]  [<ffffffff811dea13>] SyS_write 0x53/0xc0
[  328.612989]  [<ffffffff81353b63>] ? __this_cpu_preempt_check 0x13/0x20
[  328.614757]  [<ffffffff81002511>] do_syscall_64 0x61/0x1d0
[  328.616329]  [<ffffffff816a4aa4>] entry_SYSCALL64_slow_path 0x25/0x25
[  328.618057] Code: 55 48 8b bf d0 01 00 00 be 00 00 00 02 48 89 e5 e8 6b 58 3f 00 5d c3 66 0f 1f 84 00 00 00 00 00 55 48 8b 87 e0 15 00 00 48 89 e5 <48> 8b 40 30 5d c3 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00
[  328.624402] RIP  [<ffffffff81026feb>] thread_saved_pc 0xb/0x20
[  328.626124]  RSP <ffffc95001f5bd28>
[  328.627375] CR2: ffffc95001f43e18
[  328.628646] ---[ end trace 70b31f25a2ce0c0c ]---
---------- Serial console log end ----------

> Considering that we just print out  a useless hex number, not even a
> symbol, and there's a big question mark whether this even makes sense
> anyway, I suspect we should just remove it all.  The real information
> would have come later as part of "show_stack()", which seems to be
> doing the proper  try_get_task_stack().
>
> So I _think_ the fix is to just remove this. Perhaps something like
> the attached? Adding scheduler people since this is in their code..

That is not sufficient, for another Oops occurs inside stack_not_used().
Since I don't want to break stack_not_used(), can we tolerate nested
try_get_task_stack() usage and protect the whole sched_show_task()?

----------------------------------------
>From 9cf83a0a8c48d281434b040694835743940a88b2 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa <[email protected]>
Date: Wed, 2 Nov 2016 19:31:07  0900
Subject: [PATCH] sched: Fix oops in sched_show_task()

When CONFIG_VMAP_STACK=y, it is possible that an exited thread remains in
the task list after its stack pointer was already set to NULL. Therefore,
thread_saved_pc() and stack_not_used() in sched_show_task() will trigger
NULL pointer dereference if an attempt to dump such thread's traces
(e.g. SysRq-t, khungtaskd) is made.

Since show_stack() in sched_show_task() calls try_get_task_stack() and
sched_show_task() is called from interrupt context, calling
try_get_task_stack() from sched_show_task() will be safe as well.

Signed-off-by: Tetsuo Handa <[email protected]>

There is at least one Chelsio 10Gb card which uses VPD area to store some
non-standard blocks (example below).  However pci_vpd_size() returns the
length of the first block only assuming that there can be only one VPD "End
Tag".

Since 4e1a635 ("vfio/pci: Use kernel VPD access functions"), VFIO
blocks access beyond that offset, which prevents the guest "cxgb3" driver
from probing the device.  The host system does not have this problem as its
driver accesses the config space directly without pci_read_vpd().

Add a quirk to override the VPD size to a bigger value.  The maximum size
is taken from EEPROMSIZE in drivers/net/ethernet/chelsio/cxgb3/common.h.
We do not read the tag as the cxgb3 driver does as the driver supports
writing to EEPROM/VPD and when it writes, it only checks for 8192 bytes
boundary.  The quirk is registered for all devices supported by the cxgb3
driver.

This adds a quirk to the PCI layer (not to the cxgb3 driver) as the cxgb3
driver itself accesses VPD directly and the problem only exists with the
vfio-pci driver (when cxgb3 is not running on the host and may not be even
loaded) which blocks accesses beyond the first block of VPD data.  However
vfio-pci itself does not have quirks mechanism so we add it to PCI.

This is the controller:
Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]

This is what I parsed from its VPD:
===
b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K'
 0000 Large item 42 bytes; name 0x2 Identifier String
	b'10 Gigabit Ethernet-SR PCI Express Adapter'
 002d Large item 74 bytes; name 0x10
	#00 [EC] len=7: b'D76809 '
	#0a [FN] len=7: b'46K7897'
	torvalds#14 [PN] len=7: b'46K7897'
	#1e [MN] len=4: b'1037'
	torvalds#25 [FC] len=4: b'5769'
	#2c [SN] len=12: b'YL102035603V'
	#3b [NA] len=12: b'00145E992ED1'
 007a Small item 1 bytes; name 0xf End Tag

 0c00 Large item 16 bytes; name 0x2 Identifier String
	b'S310E-SR-X      '
 0c13 Large item 234 bytes; name 0x10
	#00 [PN] len=16: b'TBD             '
	torvalds#13 [EC] len=16: b'110107730D2     '
	torvalds#26 [SN] len=16: b'97YL102035603V  '
	torvalds#39 [NA] len=12: b'00145E992ED1'
	torvalds#48 [V0] len=6: b'175000'
	torvalds#51 [V1] len=6: b'266666'
	#5a [V2] len=6: b'266666'
	torvalds#63 [V3] len=6: b'2000  '
	#6c [V4] len=2: b'1 '
	torvalds#71 [V5] len=6: b'c2    '
	#7a [V6] len=6: b'0     '
	torvalds#83 [V7] len=2: b'1 '
	torvalds#88 [V8] len=2: b'0 '
	#8d [V9] len=2: b'0 '
	torvalds#92 [VA] len=2: b'0 '
	torvalds#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
 0d00 Large item 252 bytes; name 0x11
	#00 [VC] len=16: b'122310_1222 dp  '
	torvalds#13 [VD] len=16: b'610-0001-00 H1\x00\x00'
	torvalds#26 [VE] len=16: b'122310_1353 fp  '
	torvalds#39 [VF] len=16: b'610-0001-00 H1\x00\x00'
	#4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
 0dff Small item 0 bytes; name 0xf End Tag

10f3 Large item 13315 bytes; name 0x62
!!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00'
===

Signed-off-by: Alexey Kardashevskiy <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

There is at least one Chelsio 10Gb card which uses VPD area to store some
non-standard blocks (example below).  However pci_vpd_size() returns the
length of the first block only assuming that there can be only one VPD "End
Tag".

Since 4e1a635 ("vfio/pci: Use kernel VPD access functions"), VFIO
blocks access beyond that offset, which prevents the guest "cxgb3" driver
from probing the device.  The host system does not have this problem as its
driver accesses the config space directly without pci_read_vpd().

Add a quirk to override the VPD size to a bigger value.  The maximum size
is taken from EEPROMSIZE in drivers/net/ethernet/chelsio/cxgb3/common.h.
We do not read the tag as the cxgb3 driver does as the driver supports
writing to EEPROM/VPD and when it writes, it only checks for 8192 bytes
boundary.  The quirk is registered for all devices supported by the cxgb3
driver.

This adds a quirk to the PCI layer (not to the cxgb3 driver) as the cxgb3
driver itself accesses VPD directly and the problem only exists with the
vfio-pci driver (when cxgb3 is not running on the host and may not be even
loaded) which blocks accesses beyond the first block of VPD data.  However
vfio-pci itself does not have quirks mechanism so we add it to PCI.

This is the controller:
Ethernet controller [0200]: Chelsio Communications Inc T310 10GbE Single Port Adapter [1425:0030]

This is what I parsed from its VPD:
===
b'\x82*\x0010 Gigabit Ethernet-SR PCI Express Adapter\x90J\x00EC\x07D76809 FN\x0746K'
 0000 Large item 42 bytes; name 0x2 Identifier String
	b'10 Gigabit Ethernet-SR PCI Express Adapter'
 002d Large item 74 bytes; name 0x10
	#00 [EC] len=7: b'D76809 '
	#0a [FN] len=7: b'46K7897'
	torvalds#14 [PN] len=7: b'46K7897'
	#1e [MN] len=4: b'1037'
	torvalds#25 [FC] len=4: b'5769'
	#2c [SN] len=12: b'YL102035603V'
	#3b [NA] len=12: b'00145E992ED1'
 007a Small item 1 bytes; name 0xf End Tag

 0c00 Large item 16 bytes; name 0x2 Identifier String
	b'S310E-SR-X      '
 0c13 Large item 234 bytes; name 0x10
	#00 [PN] len=16: b'TBD             '
	torvalds#13 [EC] len=16: b'110107730D2     '
	torvalds#26 [SN] len=16: b'97YL102035603V  '
	torvalds#39 [NA] len=12: b'00145E992ED1'
	torvalds#48 [V0] len=6: b'175000'
	torvalds#51 [V1] len=6: b'266666'
	#5a [V2] len=6: b'266666'
	torvalds#63 [V3] len=6: b'2000  '
	#6c [V4] len=2: b'1 '
	torvalds#71 [V5] len=6: b'c2    '
	#7a [V6] len=6: b'0     '
	torvalds#83 [V7] len=2: b'1 '
	torvalds#88 [V8] len=2: b'0 '
	#8d [V9] len=2: b'0 '
	torvalds#92 [VA] len=2: b'0 '
	torvalds#97 [RV] len=80: b's\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
 0d00 Large item 252 bytes; name 0x11
	#00 [VC] len=16: b'122310_1222 dp  '
	torvalds#13 [VD] len=16: b'610-0001-00 H1\x00\x00'
	torvalds#26 [VE] len=16: b'122310_1353 fp  '
	torvalds#39 [VF] len=16: b'610-0001-00 H1\x00\x00'
	#4c [RW] len=173: b'\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'...
 0dff Small item 0 bytes; name 0xf End Tag

10f3 Large item 13315 bytes; name 0x62
!!! unknown item name 98: b'\xd0\x03\x00@`\x0c\x08\x00\x00\x00\x00\x00\x00\x00\x00\x00'
===

Signed-off-by: Alexey Kardashevskiy <[email protected]>
Signed-off-by: Bjorn Helgaas <[email protected]>

lkl: add mailing list address

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================

This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================

This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================



This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================



This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================



This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================



This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================



This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read and a
little more detailed.  Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

  ==================================================================
  BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
  Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

  CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  #84
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   dump_stack 0x292/0x398
   print_address_description 0x73/0x280
   kasan_report.part.2 0x207/0x2f0
   __asan_report_store1_noabort 0x2c/0x30
   kmalloc_uaf 0xaa/0xb6 [test_kasan]
   kmalloc_tests_init 0x4f/0xa48 [test_kasan]
   do_one_initcall 0xf3/0x390
   do_init_module 0x215/0x5d0
   load_module 0x54de/0x82b0
   SYSC_init_module 0x3be/0x430
   SyS_init_module 0x9/0x10
   entry_SYSCALL_64_fastpath 0x1f/0xc2
  RIP: 0033:0x7f22cfd0b9da
  RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
  RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
  RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
  RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
  R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
  R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

  Allocated by task 3951:
   save_stack_trace 0x16/0x20
   save_stack 0x43/0xd0
   kasan_kmalloc 0xad/0xe0
   kmem_cache_alloc_trace 0x82/0x270
   kmalloc_uaf 0x56/0xb6 [test_kasan]
   kmalloc_tests_init 0x4f/0xa48 [test_kasan]
   do_one_initcall 0xf3/0x390
   do_init_module 0x215/0x5d0
   load_module 0x54de/0x82b0
   SYSC_init_module 0x3be/0x430
   SyS_init_module 0x9/0x10
   entry_SYSCALL_64_fastpath 0x1f/0xc2

  Freed by task 3951:
   save_stack_trace 0x16/0x20
   save_stack 0x43/0xd0
   kasan_slab_free 0x72/0xc0
   kfree 0xe8/0x2b0
   kmalloc_uaf 0x85/0xb6 [test_kasan]
   kmalloc_tests_init 0x4f/0xa48 [test_kasan]
   do_one_initcall 0xf3/0x390
   do_init_module 0x215/0x5d0
   load_module 0x54de/0x82b0
   SYSC_init_module 0x3be/0x430
   SyS_init_module 0x9/0x10
   entry_SYSCALL_64_fastpath 0x1f/0xc

  The buggy address belongs to the object at ffff88006aa59da0
   which belongs to the cache kmalloc-16 of size 16
  The buggy address is located 8 bytes inside of
   16-byte region [ffff88006aa59da0, ffff88006aa59db0)
  The buggy address belongs to the page:
  page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
  flags: 0x100000000000100(slab)
  raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
  raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
  page dumped because: kasan: bad access detected

  Memory state around the buggy address:
   ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
   ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
  >ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                    ^
   ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
   ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
  ==================================================================

from:

  ==================================================================
  BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
  Write of size 1 by task insmod/3984
  CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  #83
  Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
  Call Trace:
   dump_stack 0x292/0x398
   kasan_object_err 0x1c/0x70
   kasan_report.part.1 0x20e/0x4e0
   __asan_report_store1_noabort 0x2c/0x30
   kmalloc_uaf 0xaa/0xb6 [test_kasan]
   kmalloc_tests_init 0x4f/0xa48 [test_kasan]
   do_one_initcall 0xf3/0x390
   do_init_module 0x215/0x5d0
   load_module 0x54de/0x82b0
   SYSC_init_module 0x3be/0x430
   SyS_init_module 0x9/0x10
   entry_SYSCALL_64_fastpath 0x1f/0xc2
  RIP: 0033:0x7feca0f779da
  RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
  RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
  RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
  RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
  R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
  R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
  Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
  Allocated:
  PID = 3984
   save_stack_trace 0x16/0x20
   save_stack 0x43/0xd0
   kasan_kmalloc 0xad/0xe0
   kmem_cache_alloc_trace 0x82/0x270
   kmalloc_uaf 0x56/0xb6 [test_kasan]
   kmalloc_tests_init 0x4f/0xa48 [test_kasan]
   do_one_initcall 0xf3/0x390
   do_init_module 0x215/0x5d0
   load_module 0x54de/0x82b0
   SYSC_init_module 0x3be/0x430
   SyS_init_module 0x9/0x10
   entry_SYSCALL_64_fastpath 0x1f/0xc2
  Freed:
  PID = 3984
   save_stack_trace 0x16/0x20
   save_stack 0x43/0xd0
   kasan_slab_free 0x73/0xc0
   kfree 0xe8/0x2b0
   kmalloc_uaf 0x85/0xb6 [test_kasan]
   kmalloc_tests_init 0x4f/0xa48 [test_kasan]
   do_one_initcall 0xf3/0x390
   do_init_module 0x215/0x5d0
   load_module 0x54de/0x82b0
   SYSC_init_module 0x3be/0x430
   SyS_init_module 0x9/0x10
   entry_SYSCALL_64_fastpath 0x1f/0xc2
  Memory state around the buggy address:
   ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
   ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
  >ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                    ^
   ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
   ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
  ==================================================================

This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type
based on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================



This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================

This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Patch series "kasan: improve error reports", v2.

This patchset improves KASAN reports by making them easier to read
and a little more detailed.
Also improves mm/kasan/report.c readability.

Effectively changes a use-after-free report to:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan]
Write of size 1 at addr ffff88006aa59da8 by task insmod/3951

CPU: 1 PID: 3951 Comm: insmod Tainted: G    B           4.10.0  torvalds#84
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 print_address_description 0x73/0x280
 kasan_report.part.2 0x207/0x2f0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7f22cfd0b9da
RSP: 002b:00007ffe69118a78 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 0000555671242090 RCX: 00007f22cfd0b9da
RDX: 00007f22cffcaf88 RSI: 000000000004df7e RDI: 00007f22d0399500
RBP: 00007f22cffcaf88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007f22cfd07d0a R11: 0000000000000206 R12: 0000555671243190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004

Allocated by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2

Freed by task 3951:
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x72/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc

The buggy address belongs to the object at ffff88006aa59da0
 which belongs to the cache kmalloc-16 of size 16
The buggy address is located 8 bytes inside of
 16-byte region [ffff88006aa59da0, ffff88006aa59db0)
The buggy address belongs to the page:
page:ffffea0001aa9640 count:1 mapcount:0 mapping:          (null) index:0x0
flags: 0x100000000000100(slab)
raw: 0100000000000100 0000000000000000 0000000000000000 0000000180800080
raw: ffffea0001abe380 0000000700000007 ffff88006c401b40 0000000000000000
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 ffff88006aa59c80: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
 ffff88006aa59d00: 00 00 fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
>ffff88006aa59d80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006aa59e00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006aa59e80: fb fb fc fc 00 00 fc fc 00 00 fc fc 00 00 fc fc
==================================================================

from:

==================================================================
BUG: KASAN: use-after-free in kmalloc_uaf 0xaa/0xb6 [test_kasan] at addr ffff88006c4dcb28
Write of size 1 by task insmod/3984
CPU: 1 PID: 3984 Comm: insmod Tainted: G    B           4.10.0  torvalds#83
Hardware name: QEMU Standard PC (i440FX   PIIX, 1996), BIOS Bochs 01/01/2011
Call Trace:
 dump_stack 0x292/0x398
 kasan_object_err 0x1c/0x70
 kasan_report.part.1 0x20e/0x4e0
 __asan_report_store1_noabort 0x2c/0x30
 kmalloc_uaf 0xaa/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
RIP: 0033:0x7feca0f779da
RSP: 002b:00007ffdfeae5218 EFLAGS: 00000206 ORIG_RAX: 00000000000000af
RAX: ffffffffffffffda RBX: 000055a064c13090 RCX: 00007feca0f779da
RDX: 00007feca1236f88 RSI: 000000000004df7e RDI: 00007feca1605000
RBP: 00007feca1236f88 R08: 0000000000000003 R09: 0000000000000000
R10: 00007feca0f73d0a R11: 0000000000000206 R12: 000055a064c14190
R13: 000000000001fe81 R14: 0000000000000000 R15: 0000000000000004
Object at ffff88006c4dcb20, in cache kmalloc-16 size: 16
Allocated:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_kmalloc 0xad/0xe0
 kmem_cache_alloc_trace 0x82/0x270
 kmalloc_uaf 0x56/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Freed:
PID = 3984
 save_stack_trace 0x16/0x20
 save_stack 0x43/0xd0
 kasan_slab_free 0x73/0xc0
 kfree 0xe8/0x2b0
 kmalloc_uaf 0x85/0xb6 [test_kasan]
 kmalloc_tests_init 0x4f/0xa48 [test_kasan]
 do_one_initcall 0xf3/0x390
 do_init_module 0x215/0x5d0
 load_module 0x54de/0x82b0
 SYSC_init_module 0x3be/0x430
 SyS_init_module 0x9/0x10
 entry_SYSCALL_64_fastpath 0x1f/0xc2
Memory state around the buggy address:
 ffff88006c4dca00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dca80: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
>ffff88006c4dcb00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
                                  ^
 ffff88006c4dcb80: fb fb fc fc 00 00 fc fc fb fb fc fc fb fb fc fc
 ffff88006c4dcc00: fb fb fc fc fb fb fc fc fb fb fc fc fb fb fc fc
==================================================================

This patch (of 9):

Introduce get_shadow_bug_type() function, which determines bug type based
on the shadow value for a particular kernel address.  Introduce
get_wild_bug_type() function, which determines bug type for addresses
which don't have a corresponding shadow value.

Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Andrey Konovalov <[email protected]>
Acked-by: Dmitry Vyukov <[email protected]>
Cc: Andrey Ryabinin <[email protected]>
Cc: Alexander Potapenko <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

Test for probestack linking errors

This commit fixes the following checkpatch.pl warnings:

    WARNING: do not add new typedefs
    torvalds#83: FILE: include/osdep_service.h:83:
     typedef enum mstat_status {

Signed-off-by: Marco Cesati <[email protected]>

This commit fixes the following checkpatch.pl warnings:

    WARNING: do not add new typedefs
    torvalds#83: FILE: include/osdep_service.h:83:
     typedef enum mstat_status {

Signed-off-by: Marco Cesati <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#12: FILE: ./hal/odm_CfoTracking.c:12:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#13: FILE: ./hal/odm_CfoTracking.c:13:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#42: FILE: ./hal/odm_CfoTracking.c:42:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #52: FILE: ./hal/odm_CfoTracking.c:52:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #53: FILE: ./hal/odm_CfoTracking.c:53:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #70: FILE: ./hal/odm_CfoTracking.c:70:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#82: FILE: ./hal/odm_CfoTracking.c:82:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#83: FILE: ./hal/odm_CfoTracking.c:83:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#94: FILE: ./hal/odm_CfoTracking.c:94:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#95: FILE: ./hal/odm_CfoTracking.c:95:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#121: FILE: ./hal/odm_CfoTracking.c:121:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#122: FILE: ./hal/odm_CfoTracking.c:122:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#300: FILE: ./hal/odm_CfoTracking.c:300:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#302: FILE: ./hal/odm_CfoTracking.c:302:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

Signed-off-by: Marco Cesati <[email protected]>

This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#12: FILE: ./hal/odm_CfoTracking.c:12:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#13: FILE: ./hal/odm_CfoTracking.c:13:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#42: FILE: ./hal/odm_CfoTracking.c:42:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #52: FILE: ./hal/odm_CfoTracking.c:52:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #53: FILE: ./hal/odm_CfoTracking.c:53:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #70: FILE: ./hal/odm_CfoTracking.c:70:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#82: FILE: ./hal/odm_CfoTracking.c:82:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#83: FILE: ./hal/odm_CfoTracking.c:83:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#94: FILE: ./hal/odm_CfoTracking.c:94:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#95: FILE: ./hal/odm_CfoTracking.c:95:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#121: FILE: ./hal/odm_CfoTracking.c:121:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#122: FILE: ./hal/odm_CfoTracking.c:122:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#300: FILE: ./hal/odm_CfoTracking.c:300:
     	struct DM_ODM_T * pDM_Odm = (struct DM_ODM_T *)pDM_VOID;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#302: FILE: ./hal/odm_CfoTracking.c:302:
     	struct CFO_TRACKING * pCfoTrack = &pDM_Odm->DM_CfoTrack;

Reviewed-by: Dan Carpenter <[email protected]>
Signed-off-by: Marco Cesati <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

If we bring up secondaries in parallel they might get confused unless we
impose some ordering here:

[    1.360149] x86: Booting SMP configuration:
[    1.360221] .... node  #0, CPUs:        #1  #2  #3  #4  #5  torvalds#6  torvalds#7  torvalds#8  torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23
[    1.366225] .... node  #1, CPUs:   torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47
[    1.370219] .... node  #0, CPUs:   torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71
[    1.378226] .... node  #1, CPUs:   torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95
[    1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles
[    0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1
[    0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2
[    0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3
[    0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2
[    0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4
[    1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles
[    1.395285] Brought CPUs online in 28930764 cycles
[    1.395469] smp: Brought up 2 nodes, 96 CPUs
[    1.395689] smpboot: Max logical packages: 2
[    1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS)

Do the full topology update in smp_store_cpu_info() under a spinlock
to ensure that things remain consistent.

Signed-off-by: David Woodhouse <[email protected]>

PD#150097: driver defect clean up:
torvalds#35
torvalds#39
torvalds#54
torvalds#55
torvalds#83
torvalds#94
torvalds#96
torvalds#102
torvalds#649
torvalds#690
torvalds#695

Change-Id: I1b9a9384100f4e39da246c5242de8e506671454d
Signed-off-by: Evoke Zhang <[email protected]>

PD#150097: driver defect clean up:
torvalds#35
torvalds#39
torvalds#54
torvalds#55
torvalds#83
torvalds#94
torvalds#96
torvalds#102
torvalds#649
torvalds#690
torvalds#695

Change-Id: I1b9a9384100f4e39da246c5242de8e506671454d
Signed-off-by: Evoke Zhang <[email protected]>

If we bring up secondaries in parallel they might get confused unless we
impose some ordering here:

[    1.360149] x86: Booting SMP configuration:
[    1.360221] .... node  #0, CPUs:        #1  #2  #3  #4  #5  torvalds#6  torvalds#7  torvalds#8  torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23
[    1.366225] .... node  #1, CPUs:   torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47
[    1.370219] .... node  #0, CPUs:   torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71
[    1.378226] .... node  #1, CPUs:   torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95
[    1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles
[    0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1
[    0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2
[    0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3
[    0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2
[    0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4
[    1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles
[    1.395285] Brought CPUs online in 28930764 cycles
[    1.395469] smp: Brought up 2 nodes, 96 CPUs
[    1.395689] smpboot: Max logical packages: 2
[    1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS)

Do the full topology update in smp_store_cpu_info() under a spinlock
to ensure that things remain consistent.

[Usama Arif: fixed rebase conflict]
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Usama Arif <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>

The toplogy update is performed by the AP via smp_callin() after the BSP
has called do_wait_cpu_initialized(), setting the AP's bit in
cpu_callout_mask to allow it to proceed.

In preparation to enable further parallelism of AP bringup, add locking to
serialize the update even if multiple APs are (in future) permitted to
proceed through the next stages of bringup in parallel.

Without such ordering (and with that future extra parallelism), confusion
ensues:

[    1.360149] x86: Booting SMP configuration:
[    1.360221] .... node  #0, CPUs:        #1  #2  #3  #4  #5  torvalds#6  torvalds#7  torvalds#8  torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23
[    1.366225] .... node  #1, CPUs:   torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47
[    1.370219] .... node  #0, CPUs:   torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71
[    1.378226] .... node  #1, CPUs:   torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95
[    1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles
[    0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1
[    0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2
[    0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3
[    0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2
[    0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4
[    1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles
[    1.395285] Brought CPUs online in 28930764 cycles
[    1.395469] smp: Brought up 2 nodes, 96 CPUs
[    1.395689] smpboot: Max logical packages: 2
[    1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS)

[Usama Arif: fixed rebase conflict]
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Usama Arif <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>

The toplogy update is performed by the AP via smp_callin() after the BSP
has called do_wait_cpu_initialized(), setting the AP's bit in
cpu_callout_mask to allow it to proceed.

In preparation to enable further parallelism of AP bringup, add locking to
serialize the update even if multiple APs are (in future) permitted to
proceed through the next stages of bringup in parallel.

Without such ordering (and with that future extra parallelism), confusion
ensues:

[    1.360149] x86: Booting SMP configuration:
[    1.360221] .... node  #0, CPUs:        #1  #2  #3  #4  #5  torvalds#6  torvalds#7  torvalds#8  torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23
[    1.366225] .... node  #1, CPUs:   torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47
[    1.370219] .... node  #0, CPUs:   torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71
[    1.378226] .... node  #1, CPUs:   torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95
[    1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles
[    0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1
[    0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2
[    0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3
[    0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2
[    0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4
[    1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles
[    1.395285] Brought CPUs online in 28930764 cycles
[    1.395469] smp: Brought up 2 nodes, 96 CPUs
[    1.395689] smpboot: Max logical packages: 2
[    1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS)

[Usama Arif: fixed rebase conflict]
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Usama Arif <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>

The toplogy update is performed by the AP via smp_callin() after the BSP
has called do_wait_cpu_initialized(), setting the AP's bit in
cpu_callout_mask to allow it to proceed.

In preparation to enable further parallelism of AP bringup, add locking to
serialize the update even if multiple APs are (in future) permitted to
proceed through the next stages of bringup in parallel.

Without such ordering (and with that future extra parallelism), confusion
ensues:

[    1.360149] x86: Booting SMP configuration:
[    1.360221] .... node  #0, CPUs:        #1  #2  #3  #4  #5  torvalds#6  torvalds#7  torvalds#8  torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23
[    1.366225] .... node  #1, CPUs:   torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47
[    1.370219] .... node  #0, CPUs:   torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71
[    1.378226] .... node  #1, CPUs:   torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95
[    1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles
[    0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1
[    0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2
[    0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3
[    0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2
[    0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4
[    1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles
[    1.395285] Brought CPUs online in 28930764 cycles
[    1.395469] smp: Brought up 2 nodes, 96 CPUs
[    1.395689] smpboot: Max logical packages: 2
[    1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS)

[Usama Arif: fixed rebase conflict]
Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Usama Arif <[email protected]>
Signed-off-by: Paul E. McKenney <[email protected]>

The toplogy update is performed by the AP via smp_callin() after the BSP
has called do_wait_cpu_initialized(), setting the AP's bit in
cpu_callout_mask to allow it to proceed.

In preparation to enable further parallelism of AP bringup, add locking to
serialize the update even if multiple APs are (in future) permitted to
proceed through the next stages of bringup in parallel.

Without such ordering (and with that future extra parallelism), confusion
ensues:

[    1.360149] x86: Booting SMP configuration:
[    1.360221] .... node  #0, CPUs:        #1  #2  #3  #4  #5  torvalds#6  torvalds#7  torvalds#8  torvalds#9 torvalds#10 torvalds#11 torvalds#12 torvalds#13 torvalds#14 torvalds#15 torvalds#16 torvalds#17 torvalds#18 torvalds#19 torvalds#20 torvalds#21 torvalds#22 torvalds#23
[    1.366225] .... node  #1, CPUs:   torvalds#24 torvalds#25 torvalds#26 torvalds#27 torvalds#28 torvalds#29 torvalds#30 torvalds#31 torvalds#32 torvalds#33 torvalds#34 torvalds#35 torvalds#36 torvalds#37 torvalds#38 torvalds#39 torvalds#40 torvalds#41 torvalds#42 torvalds#43 torvalds#44 torvalds#45 torvalds#46 torvalds#47
[    1.370219] .... node  #0, CPUs:   torvalds#48 torvalds#49 torvalds#50 torvalds#51 #52 #53 torvalds#54 torvalds#55 torvalds#56 torvalds#57 #58 torvalds#59 torvalds#60 torvalds#61 torvalds#62 torvalds#63 torvalds#64 torvalds#65 torvalds#66 torvalds#67 torvalds#68 torvalds#69 #70 torvalds#71
[    1.378226] .... node  #1, CPUs:   torvalds#72 torvalds#73 torvalds#74 torvalds#75 torvalds#76 torvalds#77 torvalds#78 torvalds#79 torvalds#80 torvalds#81 torvalds#82 torvalds#83 torvalds#84 torvalds#85 torvalds#86 torvalds#87 torvalds#88 torvalds#89 torvalds#90 torvalds#91 torvalds#92 torvalds#93 torvalds#94 torvalds#95
[    1.382037] Brought 96 CPUs to x86/cpu:kick in 72232606 cycles
[    0.104104] smpboot: CPU 26 Converting physical 0 to logical die 1
[    0.104104] smpboot: CPU 27 Converting physical 1 to logical package 2
[    0.104104] smpboot: CPU 24 Converting physical 1 to logical package 3
[    0.104104] smpboot: CPU 27 Converting physical 0 to logical die 2
[    0.104104] smpboot: CPU 25 Converting physical 1 to logical package 4
[    1.385609] Brought 96 CPUs to x86/cpu:wait-init in 9269218 cycles
[    1.395285] Brought CPUs online in 28930764 cycles
[    1.395469] smp: Brought up 2 nodes, 96 CPUs
[    1.395689] smpboot: Max logical packages: 2
[    1.396222] smpboot: Total of 96 processors activated (576000.00 BogoMIPS)

[Usama Arif: fixed rebase conflict]

Signed-off-by: David Woodhouse <[email protected]>
Signed-off-by: Usama Arif <[email protected]>

Currently, test_progs outputs all stdout/stderr as it runs, and when it
is done, prints a summary.

It is non-trivial for tooling to parse that output and extract meaningful
information from it.

This change adds a new option, `--json-summary`/`-J` that let the caller
specify a file where `test_progs{,-no_alu32}` can write a summary of the
run in a json format that can later be parsed by tooling.

Currently, it creates a summary section with successes/skipped/failures
followed by a list of failed tests and subtests.

A test contains the following fields:
- name: the name of the test
- number: the number of the test
- message: the log message that was printed by the test.
- failed: A boolean indicating whether the test failed or not. Currently
we only output failed tests, but in the future, successful tests could
be added.
- subtests: A list of subtests associated with this test.

A subtest contains the following fields:
- name: same as above
- number: sanme as above
- message: the log message that was printed by the subtest.
- failed: same as above but for the subtest

An example run and json content below:
```
$ sudo ./test_progs -a $(grep -v '^#' ./DENYLIST.aarch64 | awk '{print
$1","}' | tr -d '\n') -j -J /tmp/test_progs.json
$ jq < /tmp/test_progs.json | head -n 30
{
  "success": 29,
  "success_subtest": 23,
  "skipped": 3,
  "failed": 28,
  "results": [
    {
      "name": "bpf_cookie",
      "number": 10,
      "message": "test_bpf_cookie:PASS:skel_open 0 nsec\n",
      "failed": true,
      "subtests": [
        {
          "name": "multi_kprobe_link_api",
          "number": 2,
          "message": "kprobe_multi_link_api_subtest:PASS:load_kallsyms 0
nsec\nlibbpf: extern 'bpf_testmod_fentry_test1' (strong): not
resolved\nlibbpf: failed to load object 'kprobe_multi'\nlibbpf: failed
to load BPF skeleton 'kprobe_multi':
-3\nkprobe_multi_link_api_subtest:FAIL:fentry_raw_skel_load unexpected
error: -3\n",
          "failed": true
        },
        {
          "name": "multi_kprobe_attach_api",
          "number": 3,
          "message": "libbpf: extern 'bpf_testmod_fentry_test1'
(strong): not resolved\nlibbpf: failed to load object
'kprobe_multi'\nlibbpf: failed to load BPF skeleton 'kprobe_multi':
-3\nkprobe_multi_attach_api_subtest:FAIL:fentry_raw_skel_load unexpected
error: -3\n",
          "failed": true
        },
        {
          "name": "lsm",
          "number": 8,
          "message": "lsm_subtest:PASS:lsm.link_create 0
nsec\nlsm_subtest:FAIL:stack_mprotect unexpected stack_mprotect: actual
0 != expected -1\n",
          "failed": true
        }
```

The file can then be used to print a summary of the test run and list of
failing tests/subtests:

```
$ jq -r < /tmp/test_progs.json '"Success:
\(.success)/\(.success_subtest), Skipped: \(.skipped), Failed:
\(.failed)"'

Success: 29/23, Skipped: 3, Failed: 28
$ jq -r < /tmp/test_progs.json '.results | map([
    if .failed then "#\(.number) \(.name)" else empty end,
    (
        . as {name: $tname, number: $tnum} | .subtests | map(
            if .failed then "#\($tnum)/\(.number) \($tname)/\(.name)"
else empty end
        )
    )
]) | flatten | .[]' | head -n 20
 torvalds#10 bpf_cookie
 torvalds#10/2 bpf_cookie/multi_kprobe_link_api
 torvalds#10/3 bpf_cookie/multi_kprobe_attach_api
 torvalds#10/8 bpf_cookie/lsm
 torvalds#15 bpf_mod_race
 torvalds#15/1 bpf_mod_race/ksym (used_btfs UAF)
 torvalds#15/2 bpf_mod_race/kfunc (kfunc_btf_tab UAF)
 torvalds#36 cgroup_hierarchical_stats
 torvalds#61 deny_namespace
 torvalds#61/1 deny_namespace/unpriv_userns_create_no_bpf
 torvalds#73 fexit_stress
 torvalds#83 get_func_ip_test
 torvalds#99 kfunc_dynptr_param
 torvalds#99/1 kfunc_dynptr_param/dynptr_data_null
 torvalds#99/4 kfunc_dynptr_param/dynptr_data_null
 torvalds#100 kprobe_multi_bench_attach
 torvalds#100/1 kprobe_multi_bench_attach/kernel
 torvalds#100/2 kprobe_multi_bench_attach/modules
 torvalds#101 kprobe_multi_test
 torvalds#101/1 kprobe_multi_test/skel_api
```

Signed-off-by: Manu Bretelle <[email protected]>

Currently, test_progs outputs all stdout/stderr as it runs, and when it
is done, prints a summary.

It is non-trivial for tooling to parse that output and extract meaningful
information from it.

This change adds a new option, `--json-summary`/`-J` that let the caller
specify a file where `test_progs{,-no_alu32}` can write a summary of the
run in a json format that can later be parsed by tooling.

Currently, it creates a summary section with successes/skipped/failures
followed by a list of failed tests and subtests.

A test contains the following fields:
- name: the name of the test
- number: the number of the test
- message: the log message that was printed by the test.
- failed: A boolean indicating whether the test failed or not. Currently
we only output failed tests, but in the future, successful tests could
be added.
- subtests: A list of subtests associated with this test.

A subtest contains the following fields:
- name: same as above
- number: sanme as above
- message: the log message that was printed by the subtest.
- failed: same as above but for the subtest

An example run and json content below:
```
$ sudo ./test_progs -a $(grep -v '^#' ./DENYLIST.aarch64 | awk '{print
$1","}' | tr -d '\n') -j -J /tmp/test_progs.json
$ jq < /tmp/test_progs.json | head -n 30
{
  "success": 29,
  "success_subtest": 23,
  "skipped": 3,
  "failed": 28,
  "results": [
    {
      "name": "bpf_cookie",
      "number": 10,
      "message": "test_bpf_cookie:PASS:skel_open 0 nsec\n",
      "failed": true,
      "subtests": [
        {
          "name": "multi_kprobe_link_api",
          "number": 2,
          "message": "kprobe_multi_link_api_subtest:PASS:load_kallsyms 0 nsec\nlibbpf: extern 'bpf_testmod_fentry_test1' (strong): not resolved\nlibbpf: failed to load object 'kprobe_multi'\nlibbpf: failed to load BPF skeleton 'kprobe_multi': -3\nkprobe_multi_link_api_subtest:FAIL:fentry_raw_skel_load unexpected error: -3\n",
          "failed": true
        },
        {
          "name": "multi_kprobe_attach_api",
          "number": 3,
          "message": "libbpf: extern 'bpf_testmod_fentry_test1' (strong): not resolved\nlibbpf: failed to load object 'kprobe_multi'\nlibbpf: failed to load BPF skeleton 'kprobe_multi': -3\nkprobe_multi_attach_api_subtest:FAIL:fentry_raw_skel_load unexpected error: -3\n",
          "failed": true
        },
        {
          "name": "lsm",
          "number": 8,
          "message": "lsm_subtest:PASS:lsm.link_create 0 nsec\nlsm_subtest:FAIL:stack_mprotect unexpected stack_mprotect: actual 0 != expected -1\n",
          "failed": true
        }
```

The file can then be used to print a summary of the test run and list of
failing tests/subtests:

```
$ jq -r < /tmp/test_progs.json '"Success: \(.success)/\(.success_subtest), Skipped: \(.skipped), Failed: \(.failed)"'

Success: 29/23, Skipped: 3, Failed: 28
$ jq -r < /tmp/test_progs.json '.results | map([
    if .failed then "#\(.number) \(.name)" else empty end,
    (
        . as {name: $tname, number: $tnum} | .subtests | map(
            if .failed then "#\($tnum)/\(.number) \($tname)/\(.name)" else empty end
        )
    )
]) | flatten | .[]' | head -n 20
 torvalds#10 bpf_cookie
 torvalds#10/2 bpf_cookie/multi_kprobe_link_api
 torvalds#10/3 bpf_cookie/multi_kprobe_attach_api
 torvalds#10/8 bpf_cookie/lsm
 torvalds#15 bpf_mod_race
 torvalds#15/1 bpf_mod_race/ksym (used_btfs UAF)
 torvalds#15/2 bpf_mod_race/kfunc (kfunc_btf_tab UAF)
 torvalds#36 cgroup_hierarchical_stats
 torvalds#61 deny_namespace
 torvalds#61/1 deny_namespace/unpriv_userns_create_no_bpf
 torvalds#73 fexit_stress
 torvalds#83 get_func_ip_test
 torvalds#99 kfunc_dynptr_param
 torvalds#99/1 kfunc_dynptr_param/dynptr_data_null
 torvalds#99/4 kfunc_dynptr_param/dynptr_data_null
 torvalds#100 kprobe_multi_bench_attach
 torvalds#100/1 kprobe_multi_bench_attach/kernel
 torvalds#100/2 kprobe_multi_bench_attach/modules
 torvalds#101 kprobe_multi_test
 torvalds#101/1 kprobe_multi_test/skel_api
```

Signed-off-by: Manu Bretelle <[email protected]>
Signed-off-by: Andrii Nakryiko <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]

scx: Update print_scx_info()

KSAN calls into rcu code which then triggers a write that reenters into KSAN
getting the system stuck doing infinite recursion.

#0  kmsan_get_context () at mm/kmsan/kmsan.h:106
#1  __msan_get_context_state () at mm/kmsan/instrumentation.c:331
#2  0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42
#3  rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
#4  __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
#5  0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#6  pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#7  kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#8  virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#9  0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
#52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
#53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
#58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
#70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82
torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75
torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97
torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36
torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:92
torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397
torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task 1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500
torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285
torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324
torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296
torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262
torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932
torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks 28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555
torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks 28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536
torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461
torvalds#93 0x0000000000000000 in ??

As of 5ec8e8e(mm/sparsemem: fix race in accessing memory_section->usage) KMSAN
now calls into RCU tree code during kmsan_get_metadata. This will trigger a
write that will reenter into KMSAN getting the system stuck doing infinite
recursion.

#0  kmsan_get_context () at mm/kmsan/kmsan.h:106
#1  __msan_get_context_state () at mm/kmsan/instrumentation.c:331
#2  0xffffffff81495671 in get_current () at ./arch/x86/include/asm/current.h:42
#3  rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
#4  __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
#5  0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#6  pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#7  kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#8  virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#9  0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#10 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#11 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#12 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#13 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#14 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#15 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#16 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#17 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#18 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#19 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#20 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#21 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#22 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#23 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#24 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#25 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#26 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#27 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#28 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#29 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#30 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#31 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#32 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#33 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#34 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#35 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#36 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#37 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#38 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#39 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#40 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#41 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#42 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#43 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#44 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#45 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#46 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#47 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#48 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#49 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#50 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#51 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
#52 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
#53 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#54 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#55 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#56 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#57 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
#58 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#59 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#60 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#61 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#62 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#63 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#64 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#65 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#66 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#67 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff8620d974 <init_task 1012>) at ./arch/x86/include/asm/kmsan.h:82
torvalds#68 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/shadow.c:75
torvalds#69 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff8620d974 <init_task 1012>, is_origin=false) at mm/kmsan/shadow.c:143
#70 kmsan_get_shadow_origin_ptr (address=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/shadow.c:97
torvalds#71 0xffffffff81b1dbd2 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=4, store=false) at mm/kmsan/instrumentation.c:36
torvalds#72 __msan_metadata_ptr_for_load_4 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:91
torvalds#73 0xffffffff8149568f in rcu_preempt_read_enter () at kernel/rcu/tree_plugin.h:379
torvalds#74 __rcu_read_lock () at kernel/rcu/tree_plugin.h:402
torvalds#75 0xffffffff81b2054b in rcu_read_lock () at ./include/linux/rcupdate.h:748
torvalds#76 pfn_valid (pfn=<optimized out>) at ./include/linux/mmzone.h:2016
torvalds#77 kmsan_virt_addr_valid (addr=addr@entry=0xffffffff86203c90) at ./arch/x86/include/asm/kmsan.h:82
torvalds#78 virt_to_page_or_null (vaddr=vaddr@entry=0xffffffff86203c90) at mm/kmsan/shadow.c:75
torvalds#79 0xffffffff81b2023c in kmsan_get_metadata (address=0xffffffff86203c90, is_origin=false) at mm/kmsan/shadow.c:143
torvalds#80 kmsan_get_shadow_origin_ptr (address=0xffffffff86203c90, size=8, store=false) at mm/kmsan/shadow.c:97
torvalds#81 0xffffffff81b1dc72 in get_shadow_origin_ptr (addr=0xffffffff8620d974 <init_task 1012>, size=8, store=false) at mm/kmsan/instrumentation.c:36
torvalds#82 __msan_metadata_ptr_for_load_8 (addr=0xffffffff8620d974 <init_task 1012>) at mm/kmsan/instrumentation.c:92
torvalds#83 0xffffffff814fdb9e in filter_irq_stacks (entries=<optimized out>, nr_entries=4) at kernel/stacktrace.c:397
torvalds#84 0xffffffff829520e8 in stack_depot_save_flags (entries=0xffffffff8620d974 <init_task 1012>, nr_entries=4, alloc_flags=0, depot_flags=0) at lib/stackdepot.c:500
torvalds#85 0xffffffff81b1e560 in __msan_poison_alloca (address=0xffffffff86203da0, size=24, descr=<optimized out>) at mm/kmsan/instrumentation.c:285
torvalds#86 0xffffffff8562821c in _printk (fmt=0xffffffff85f191a5 "\0016Attempting lock1") at kernel/printk/printk.c:2324
torvalds#87 0xffffffff81942aa2 in kmem_cache_create_usercopy (name=0xffffffff85f18903 "mm_struct", size=1296, align=0, flags=270336, useroffset=<optimized out>, usersize=<optimized out>, ctor=0x0 <fixed_percpu_data>) at mm/slab_common.c:296
torvalds#88 0xffffffff86f337a0 in mm_cache_init () at kernel/fork.c:3262
torvalds#89 0xffffffff86eacb8e in start_kernel () at init/main.c:932
torvalds#90 0xffffffff86ecdf94 in x86_64_start_reservations (real_mode_data=0x140e0 <exception_stacks 28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:555
torvalds#91 0xffffffff86ecde9b in x86_64_start_kernel (real_mode_data=0x140e0 <exception_stacks 28896> <error: Cannot access memory at address 0x140e0>) at arch/x86/kernel/head64.c:536
torvalds#92 0xffffffff810001d3 in secondary_startup_64 () at /pool/workspace/linux/arch/x86/kernel/head_64.S:461
torvalds#93 0x0000000000000000 in ??

Recent additions in BPF like cpu v4 instructions, test_bpf module
exhibits the following failures:

  test_bpf: torvalds#82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)

  test_bpf: torvalds#165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)
  test_bpf: torvalds#166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)

  test_bpf: torvalds#169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)
  test_bpf: torvalds#170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: torvalds#172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: torvalds#313 BSWAP 16: 0x0123456789abcdef -> 0xefcd
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 301 PASS
  test_bpf: torvalds#314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 555 PASS
  test_bpf: torvalds#315 BSWAP 64: 0x0123456789abcdef -> 0x67452301
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 268 PASS
  test_bpf: torvalds#316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 269 PASS
  test_bpf: torvalds#317 BSWAP 16: 0xfedcba9876543210 -> 0x1032
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 460 PASS
  test_bpf: torvalds#318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 320 PASS
  test_bpf: torvalds#319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 222 PASS
  test_bpf: torvalds#320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 273 PASS

  test_bpf: torvalds#344 BPF_LDX_MEMSX | BPF_B
  eBPF filter opcode 0091 (@5) unsupported
  jited:0 432 PASS
  test_bpf: torvalds#345 BPF_LDX_MEMSX | BPF_H
  eBPF filter opcode 0089 (@5) unsupported
  jited:0 381 PASS
  test_bpf: torvalds#346 BPF_LDX_MEMSX | BPF_W
  eBPF filter opcode 0081 (@5) unsupported
  jited:0 505 PASS

  test_bpf: torvalds#490 JMP32_JA: Unconditional jump: if (true) return 1
  eBPF filter opcode 0006 (@1) unsupported
  jited:0 261 PASS

  test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed]

Fix them by adding missing processing.

Fixes: daabb2b ("bpf/tests: add tests for cpuv4 instructions")
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu

[ Upstream commit 8ecf3c1 ]

Recent additions in BPF like cpu v4 instructions, test_bpf module
exhibits the following failures:

  test_bpf: torvalds#82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)

  test_bpf: torvalds#165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)
  test_bpf: torvalds#166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)

  test_bpf: torvalds#169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)
  test_bpf: torvalds#170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: torvalds#172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: torvalds#313 BSWAP 16: 0x0123456789abcdef -> 0xefcd
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 301 PASS
  test_bpf: torvalds#314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 555 PASS
  test_bpf: torvalds#315 BSWAP 64: 0x0123456789abcdef -> 0x67452301
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 268 PASS
  test_bpf: torvalds#316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 269 PASS
  test_bpf: torvalds#317 BSWAP 16: 0xfedcba9876543210 -> 0x1032
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 460 PASS
  test_bpf: torvalds#318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 320 PASS
  test_bpf: torvalds#319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 222 PASS
  test_bpf: torvalds#320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 273 PASS

  test_bpf: torvalds#344 BPF_LDX_MEMSX | BPF_B
  eBPF filter opcode 0091 (@5) unsupported
  jited:0 432 PASS
  test_bpf: torvalds#345 BPF_LDX_MEMSX | BPF_H
  eBPF filter opcode 0089 (@5) unsupported
  jited:0 381 PASS
  test_bpf: torvalds#346 BPF_LDX_MEMSX | BPF_W
  eBPF filter opcode 0081 (@5) unsupported
  jited:0 505 PASS

  test_bpf: torvalds#490 JMP32_JA: Unconditional jump: if (true) return 1
  eBPF filter opcode 0006 (@1) unsupported
  jited:0 261 PASS

  test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed]

Fix them by adding missing processing.

Fixes: daabb2b ("bpf/tests: add tests for cpuv4 instructions")
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 8ecf3c1 ]

Recent additions in BPF like cpu v4 instructions, test_bpf module
exhibits the following failures:

  test_bpf: torvalds#82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)

  test_bpf: torvalds#165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)
  test_bpf: torvalds#166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)

  test_bpf: torvalds#169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)
  test_bpf: torvalds#170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: torvalds#172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: torvalds#313 BSWAP 16: 0x0123456789abcdef -> 0xefcd
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 301 PASS
  test_bpf: torvalds#314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 555 PASS
  test_bpf: torvalds#315 BSWAP 64: 0x0123456789abcdef -> 0x67452301
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 268 PASS
  test_bpf: torvalds#316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 269 PASS
  test_bpf: torvalds#317 BSWAP 16: 0xfedcba9876543210 -> 0x1032
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 460 PASS
  test_bpf: torvalds#318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 320 PASS
  test_bpf: torvalds#319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 222 PASS
  test_bpf: torvalds#320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 273 PASS

  test_bpf: torvalds#344 BPF_LDX_MEMSX | BPF_B
  eBPF filter opcode 0091 (@5) unsupported
  jited:0 432 PASS
  test_bpf: torvalds#345 BPF_LDX_MEMSX | BPF_H
  eBPF filter opcode 0089 (@5) unsupported
  jited:0 381 PASS
  test_bpf: torvalds#346 BPF_LDX_MEMSX | BPF_W
  eBPF filter opcode 0081 (@5) unsupported
  jited:0 505 PASS

  test_bpf: torvalds#490 JMP32_JA: Unconditional jump: if (true) return 1
  eBPF filter opcode 0006 (@1) unsupported
  jited:0 261 PASS

  test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed]

Fix them by adding missing processing.

Fixes: daabb2b ("bpf/tests: add tests for cpuv4 instructions")
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <[email protected]>

[ Upstream commit 8ecf3c1 ]

Recent additions in BPF like cpu v4 instructions, test_bpf module
exhibits the following failures:

  test_bpf: torvalds#82 ALU_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#83 ALU_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#84 ALU64_MOVSX | BPF_B jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#85 ALU64_MOVSX | BPF_H jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)
  test_bpf: torvalds#86 ALU64_MOVSX | BPF_W jited:1 ret 2 != 1 (0x2 != 0x1)FAIL (1 times)

  test_bpf: torvalds#165 ALU_SDIV_X: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)
  test_bpf: torvalds#166 ALU_SDIV_K: -6 / 2 = -3 jited:1 ret 2147483645 != -3 (0x7ffffffd != 0xfffffffd)FAIL (1 times)

  test_bpf: torvalds#169 ALU_SMOD_X: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)
  test_bpf: torvalds#170 ALU_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: torvalds#172 ALU64_SMOD_K: -7 % 2 = -1 jited:1 ret 1 != -1 (0x1 != 0xffffffff)FAIL (1 times)

  test_bpf: torvalds#313 BSWAP 16: 0x0123456789abcdef -> 0xefcd
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 301 PASS
  test_bpf: torvalds#314 BSWAP 32: 0x0123456789abcdef -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 555 PASS
  test_bpf: torvalds#315 BSWAP 64: 0x0123456789abcdef -> 0x67452301
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 268 PASS
  test_bpf: torvalds#316 BSWAP 64: 0x0123456789abcdef >> 32 -> 0xefcdab89
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 269 PASS
  test_bpf: torvalds#317 BSWAP 16: 0xfedcba9876543210 -> 0x1032
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 460 PASS
  test_bpf: torvalds#318 BSWAP 32: 0xfedcba9876543210 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 320 PASS
  test_bpf: torvalds#319 BSWAP 64: 0xfedcba9876543210 -> 0x98badcfe
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 222 PASS
  test_bpf: torvalds#320 BSWAP 64: 0xfedcba9876543210 >> 32 -> 0x10325476
  eBPF filter opcode 00d7 (@2) unsupported
  jited:0 273 PASS

  test_bpf: torvalds#344 BPF_LDX_MEMSX | BPF_B
  eBPF filter opcode 0091 (@5) unsupported
  jited:0 432 PASS
  test_bpf: torvalds#345 BPF_LDX_MEMSX | BPF_H
  eBPF filter opcode 0089 (@5) unsupported
  jited:0 381 PASS
  test_bpf: torvalds#346 BPF_LDX_MEMSX | BPF_W
  eBPF filter opcode 0081 (@5) unsupported
  jited:0 505 PASS

  test_bpf: torvalds#490 JMP32_JA: Unconditional jump: if (true) return 1
  eBPF filter opcode 0006 (@1) unsupported
  jited:0 261 PASS

  test_bpf: Summary: 1040 PASSED, 10 FAILED, [924/1038 JIT'ed]

Fix them by adding missing processing.

Fixes: daabb2b ("bpf/tests: add tests for cpuv4 instructions")
Signed-off-by: Christophe Leroy <[email protected]>
Signed-off-by: Michael Ellerman <[email protected]>
Link: https://msgid.link/91de862dda99d170697eb79ffb478678af7e0b27.1709652689.git.christophe.leroy@csgroup.eu
Signed-off-by: Sasha Levin <[email protected]>

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#83: FILE: arch/csky/kernel/vdso.c:81:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#97: FILE: arch/csky/kernel/vdso.c:92:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#213: FILE: arch/sh/kernel/vsyscall/vsyscall.c:84:
 	if (unlikely(IS_ERR(vma)))

total: 0 errors, 3 warnings, 249 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-remove-legacy-install_special_mapping-code.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Anton Ivanov <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jeff Xu <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Liam R. Howlett <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Pedro Falcato <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Rob Landley <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#83: FILE: arch/csky/kernel/vdso.c:81:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#97: FILE: arch/csky/kernel/vdso.c:92:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#213: FILE: arch/sh/kernel/vsyscall/vsyscall.c:84:
 	if (unlikely(IS_ERR(vma)))

total: 0 errors, 3 warnings, 249 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-remove-legacy-install_special_mapping-code.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Anton Ivanov <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jeff Xu <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Liam R. Howlett <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Pedro Falcato <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Rob Landley <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#83: FILE: arch/csky/kernel/vdso.c:81:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#97: FILE: arch/csky/kernel/vdso.c:92:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#213: FILE: arch/sh/kernel/vsyscall/vsyscall.c:84:
 	if (unlikely(IS_ERR(vma)))

total: 0 errors, 3 warnings, 249 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-remove-legacy-install_special_mapping-code.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Anton Ivanov <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jeff Xu <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Liam R. Howlett <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Pedro Falcato <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Rob Landley <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#83: FILE: arch/csky/kernel/vdso.c:81:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#97: FILE: arch/csky/kernel/vdso.c:92:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#213: FILE: arch/sh/kernel/vsyscall/vsyscall.c:84:
 	if (unlikely(IS_ERR(vma)))

total: 0 errors, 3 warnings, 249 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-remove-legacy-install_special_mapping-code.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Anton Ivanov <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jeff Xu <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Liam R. Howlett <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Pedro Falcato <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Rob Landley <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#83: FILE: arch/csky/kernel/vdso.c:81:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#97: FILE: arch/csky/kernel/vdso.c:92:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#213: FILE: arch/sh/kernel/vsyscall/vsyscall.c:84:
 	if (unlikely(IS_ERR(vma)))

total: 0 errors, 3 warnings, 249 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-remove-legacy-install_special_mapping-code.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Anton Ivanov <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jeff Xu <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Liam R. Howlett <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Pedro Falcato <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Rob Landley <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#83: FILE: arch/csky/kernel/vdso.c:81:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#97: FILE: arch/csky/kernel/vdso.c:92:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#213: FILE: arch/sh/kernel/vsyscall/vsyscall.c:84:
 	if (unlikely(IS_ERR(vma)))

total: 0 errors, 3 warnings, 249 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-remove-legacy-install_special_mapping-code.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Anton Ivanov <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jeff Xu <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Liam R. Howlett <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Pedro Falcato <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Rob Landley <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#83: FILE: arch/csky/kernel/vdso.c:81:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#97: FILE: arch/csky/kernel/vdso.c:92:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#213: FILE: arch/sh/kernel/vsyscall/vsyscall.c:84:
 	if (unlikely(IS_ERR(vma)))

total: 0 errors, 3 warnings, 249 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-remove-legacy-install_special_mapping-code.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Anton Ivanov <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jeff Xu <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Liam R. Howlett <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Pedro Falcato <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Rob Landley <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#83: FILE: arch/csky/kernel/vdso.c:81:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#97: FILE: arch/csky/kernel/vdso.c:92:
 	if (unlikely(IS_ERR(vma))) {

WARNING: nested (un)?likely() calls, IS_ERR already uses unlikely() internally
torvalds#213: FILE: arch/sh/kernel/vsyscall/vsyscall.c:84:
 	if (unlikely(IS_ERR(vma)))

total: 0 errors, 3 warnings, 249 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
      mechanically convert to the typical style using --fix or --fix-inplace.

./patches/mm-remove-legacy-install_special_mapping-code.patch has style problems, please review.

NOTE: If any of the errors are false positives, please report
      them to the maintainer, see CHECKPATCH in MAINTAINERS.

Please run checkpatch prior to sending patches

Cc: Anton Ivanov <[email protected]>
Cc: Brian Cain <[email protected]>
Cc: Christophe Leroy <[email protected]>
Cc: Dinh Nguyen <[email protected]>
Cc: Guo Ren <[email protected]>
Cc: Jeff Xu <[email protected]>
Cc: Johannes Berg <[email protected]>
Cc: John Paul Adrian Glaubitz <[email protected]>
Cc: Liam R. Howlett <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicholas Piggin <[email protected]>
Cc: Pedro Falcato <[email protected]>
Cc: Richard Weinberger <[email protected]>
Cc: Rich Felker <[email protected]>
Cc: Rob Landley <[email protected]>
Cc: Yoshinori Sato <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>