Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Update acct.c #104

Closed
wants to merge 1 commit into from
Closed

Update acct.c #104

wants to merge 1 commit into from

Conversation

hosembafer
Copy link

No description provided.

hubcapsc pushed a commit to hubcapsc/linux that referenced this pull request Jul 2, 2014
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]>
@hosembafer hosembafer closed this Jul 8, 2014
tom3q pushed a commit to tom3q/linux that referenced this pull request Oct 2, 2014
At boot we display a bunch of low level settings which can be useful to
know, and can help to spot bugs when things are fundamentally
misconfigured.

At the moment they are very widely spaced, so that we can accommodate
the line:

  ppc64_caches.dcache_line_size = 0xYY

But we only print that line when the cache line size is not 128, ie.
almost never, so it just makes the display look odd usually.

The ppc64_caches prefix is redundant so remove it, which means we can
align things a bit closer for the common case. While we're there
replace the last use of camelCase (physicalMemorySize), and use
phys_mem_size.

Before:
  Starting Linux PPC64 torvalds#104 SMP Wed Aug 6 18:41:34 EST 2014
  -----------------------------------------------------
  ppc64_pft_size                = 0x1a
  physicalMemorySize            = 0x200000000
  ppc64_caches.dcache_line_size = 0xf0
  ppc64_caches.icache_line_size = 0xf0
  htab_address                  = 0xdeadbeef
  htab_hash_mask                = 0x7ffff
  physical_start                = 0xf000bar
  -----------------------------------------------------

After:
  Starting Linux PPC64 torvalds#103 SMP Wed Aug 6 18:38:04 EST 2014
  -----------------------------------------------------
  ppc64_pft_size    = 0x1a
  phys_mem_size     = 0x200000000
  dcache_line_size  = 0xf0
  icache_line_size  = 0xf0
  htab_address      = 0xdeadbeef
  htab_hash_mask    = 0x7ffff
  physical_start    = 0xf000bar
  -----------------------------------------------------

This patch is final, no bike shedding ;)

Signed-off-by: Michael Ellerman <[email protected]>
aryabinin referenced this pull request in aryabinin/linux Oct 3, 2014
GIT 6fe676b243e5a0cb4cc4d9a4b094de8db0cdbf74

commit e500f488c27659bb6f5d313b336621f3daa67701
Author: Fabian Frederick <[email protected]>
Date:   Wed Oct 1 06:52:06 2014 +0200

    net/dccp/ccid.c: add __init to ccid_activate
    
    ccid_activate is only called by __init ccid_initialize_builtins in same module.
    
    Signed-off-by: Fabian Frederick <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0c5b8a46294d43fc63788839d3c18de0961ec1bc
Author: Fabian Frederick <[email protected]>
Date:   Wed Oct 1 06:48:03 2014 +0200

    net/dccp/proto.c: add __init to dccp_mib_init
    
    dccp_mib_init is only called by __init dccp_init in same module.
    
    Signed-off-by: Fabian Frederick <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 082f58ac4a48d3f5cb4597232cb2ac6823a96f43
Author: Quinn Tran <[email protected]>
Date:   Thu Sep 25 06:22:28 2014 -0400

    target: Fix queue full status NULL pointer for SCF_TRANSPORT_TASK_SENSE
    
    During temporary resource starvation at lower transport layer, command
    is placed on queue full retry path, which expose this problem.  The TCM
    queue full handling of SCF_TRANSPORT_TASK_SENSE currently sends the same
    cmd twice to lower layer.  The 1st time led to cmd normal free path.
    The 2nd time cause Null pointer access.
    
    This regression bug was originally introduced v3.1-rc code in the
    following commit:
    
    commit e057f53308a5f071556ee80586b99ee755bf07f5
    Author: Christoph Hellwig <[email protected]>
    Date:   Mon Oct 17 13:56:41 2011 -0400
    
        target: remove the transport_qf_callback se_cmd callback
    
    Signed-off-by: Quinn Tran <[email protected]>
    Signed-off-by: Saurav Kashyap <[email protected]>
    Cc: <[email protected]> # v3.1+
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit db3a99b9921f27fe71ca8c0f218ee810e0e7fb69
Author: Joern Engel <[email protected]>
Date:   Tue Sep 16 16:23:19 2014 -0400

    qla_target: rearrange struct qla_tgt_prm
    
    On most (non-x86) 64bit platforms this will remove 8 padding bytes
    from the structure.
    
    Signed-off-by: Joern Engel <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit f9b6721a9cef94908467abf7a2cacbd15a7d23cb
Author: Joern Engel <[email protected]>
Date:   Tue Sep 16 16:23:18 2014 -0400

    qla_target: improve qlt_unmap_sg()
    
    Remove the inline attribute.  Modern compilers ignore it and the
    function has grown beyond where inline made sense anyway.
    Remove the BUG_ON(!cmd->sg_mapped), and instead return if sg_mapped is
    not set.  Every caller is doing this check, so we might as well have it
    in one place instead of four.
    
    Signed-off-by: Joern Engel <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 55a9066fffd2f533e7ed434b072469ef09d6c476
Author: Joern Engel <[email protected]>
Date:   Tue Sep 16 16:23:15 2014 -0400

    qla_target: make some global functions static
    
    Also removes the declarations from the header - including two
    declarations without function definitions or callers.
    
    Signed-off-by: Joern Engel <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit c57010420654aca179c500f61e86315a337244ca
Author: Joern Engel <[email protected]>
Date:   Tue Sep 16 16:23:14 2014 -0400

    qla_target: remove unused parameter
    
    Signed-off-by: Joern Engel <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit f81ccb489a7a641c1bed41b49cf8d72c199c68d5
Author: Joern Engel <[email protected]>
Date:   Tue Sep 16 16:23:13 2014 -0400

    target: simplify core_tmr_abort_task
    
    list_for_each_entry_safe is necessary if list objects are deleted from
    the list while traversing it.  Not the case here, so we can use the base
    list_for_each_entry variant.
    
    Signed-off-by: Joern Engel <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 33940d09937276cd3c81f2874faf43e37c2db0e2
Author: Joern Engel <[email protected]>
Date:   Tue Sep 16 16:23:12 2014 -0400

    target: encapsulate smp_mb__after_atomic()
    
    The target code has a rather generous helping of smp_mb__after_atomic()
    throughout the code base.  Most atomic operations were followed by one
    and none were preceded by smp_mb__before_atomic(), nor accompanied by a
    comment explaining the need for a barrier.
    
    Instead of trying to prove for every case whether or not it is needed,
    this patch introduces atomic_inc_mb() and atomic_dec_mb(), which
    explicitly include the memory barriers before and after the atomic
    operation.  For now they are defined in a target header, although they
    could be of general use.
    
    Most of the existing atomic/mb combinations were replaced by the new
    helpers.  In a few cases the atomic was sandwiched in
    spin_lock/spin_unlock and I simply removed the barrier.
    
    I suspect that in most cases the correct conversion would have been to
    drop the barrier.  I also suspect that a few cases exist where a) the
    barrier was necessary and b) a second barrier before the atomic would
    have been necessary and got added by this patch.
    
    Signed-off-by: Joern Engel <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 74ed7e62289dc6d388996d7c8f89c2e7e95b9657
Author: Joern Engel <[email protected]>
Date:   Tue Sep 16 16:23:11 2014 -0400

    target: remove some smp_mb__after_atomic()s
    
    atomic_inc_return() already does an implicit memory barrier and the
    second case was moved from an atomic to a plain flag operation.  If a
    barrier were needed in the second case, it would have to be smp_mb(),
    not a variant optimized away for x86 and other architectures.
    
    Signed-off-by: Joern Engel <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 8f83269048628d7b139dacbfc6cc97befcbdd2e9
Author: Joern Engel <[email protected]>
Date:   Tue Sep 16 16:23:10 2014 -0400

    target: simplify core_tmr_release_req()
    
    And while at it, do minimal coding style fixes in the area.
    
    Signed-off-by: Joern Engel <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 9c7d6154bc4b9dfefd580490cdca5f7c72321464
Author: Andy Grover <[email protected]>
Date:   Mon Jun 30 16:39:46 2014 -0700

    target: Remove core_tpg_release_virtual_lun0 function
    
    Simple and just called from one place.
    
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Andy Grover <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit cd9d7cbaec8b622eee4edcd8bf481c4047f74915
Author: Andy Grover <[email protected]>
Date:   Mon Jun 30 16:39:44 2014 -0700

    target: Change core_dev_del_lun to take a se_lun instead of unpacked_lun
    
    Remove core_tpg_pre_dellun entirely, since we don't need to get/check
    a pointer we already have.
    
    Nothing else can return an error, so core_dev_del_lun can return void.
    
    Rename core_tpg_post_dellun to remove_lun - a clearer name, now that
    pre_dellun is gone.
    
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Andy Grover <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit cc83881f2c57caaf4b14adaffa65595640a59661
Author: Andy Grover <[email protected]>
Date:   Mon Jun 30 16:39:43 2014 -0700

    target: core_tpg_post_dellun can return void
    
    Nothing in it can raise an error.
    
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Andy Grover <[email protected]>
    Signed-off-by: Nicholas Bellinger <[email protected]>

commit 49be17235c0acd96f2ff0fe282867fe3a83f554c
Author: hayeswang <[email protected]>
Date:   Wed Oct 1 13:25:11 2014 +0800

    r8152: disable power cut for RTL8153
    
    The firmware would be clear when the power cut is enabled for
    RTL8153.
    
    Signed-off-by: Hayes Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 204c8704128943bf3f8b605f4b40bdc2b6bd89dc
Author: hayeswang <[email protected]>
Date:   Wed Oct 1 13:25:10 2014 +0800

    r8152: remove clearing bp
    
    The xxx_clear_bp() is used to halt the firmware. It only necessary
    for updating the new firmware. Besides, depend on the version of
    the current firmware, it may have problem to halt the firmware
    directly. Finally, halt the firmware would let the firmware code
    useless, and the bugs which are fixed by the firmware would occur.
    
    Signed-off-by: Hayes Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit aa55c8e2f7a395dfc9e67fc6637321e19ce9bfe1
Author: Masahiro Yamada <[email protected]>
Date:   Tue Sep 9 20:02:24 2014 +0900

    kbuild: handle C=... and M=... after entering into build directory
    
    This commit avoids processing C=... and M=... twice
    when O=... is also given.
    
    Besides, we can also remove KBUILD_EXTMOD="$(KBUILD_EXTMOD)"
    in the sub-make target.
    
    Signed-off-by: Masahiro Yamada <[email protected]>
    Acked-by: Peter Foley <[email protected]>
    Signed-off-by: Michal Marek <[email protected]>

commit 745a254322c898dadf019342cd7140f7867d2d0f
Author: Masahiro Yamada <[email protected]>
Date:   Tue Sep 9 20:02:23 2014 +0900

    kbuild: use $(Q) for sub-make target
    
    Since commit 066b7ed9558087a7957a1128f27d7a3462ff117f
    (kbuild: Do not print the build directory with make -s),
    "Q" is defined above the sub-make target.
    
    This commit takes advantage of that and replaces
    "$(if $(KBUILD_VERBOSE:1=),@)" with "$(Q)".
    
    Signed-off-by: Masahiro Yamada <[email protected]>
    Acked-by: Peter Foley <[email protected]>
    Signed-off-by: Michal Marek <[email protected]>

commit 7ff525712acf9325e9acdb27bbc93049ea2e850c
Author: Masahiro Yamada <[email protected]>
Date:   Tue Sep 9 20:02:22 2014 +0900

    kbuild: fake the "Entering directory ..." message more simply
    
    Commit c2e28dc975ea87feed84415006ae143424912ac7
    (kbuild: Print the name of the build directory)
    added a gimmick to show the "Entering directory ...".
    
    Instead of echoing the hard-coded message (that is, we need to know
    the exact message), moving --no-print-directory would be easier.
    
    Signed-off-by: Masahiro Yamada <[email protected]>
    Acked-by: Peter Foley <[email protected]>
    Signed-off-by: Michal Marek <[email protected]>

commit 1b0ecb28b0cc216535ce6477d39aa610c3ff68a1
Author: Vlad Yasevich <[email protected]>
Date:   Tue Sep 30 19:39:37 2014 -0400

    bnx2: Correctly receive full sized 802.1ad fragmes
    
    This driver, similar to tg3, has a check that will
    cause full sized 802.1ad frames to be dropped.  The
    frame will be larger then the standard mtu due to the
    presense of vlan header that has not been stripped.
    The driver should not drop this frame and should process
    it just like it does for 802.1q.
    
    CC: Sony Chacko <[email protected]>
    CC: [email protected]
    Signed-off-by: Vladislav Yasevich <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 7d3083ee36b51e425b6abd76778a2046906b0fd3
Author: Vlad Yasevich <[email protected]>
Date:   Tue Sep 30 19:39:36 2014 -0400

    tg3: Allow for recieve of full-size 8021AD frames
    
    When receiving a vlan-tagged frame that still contains
    a vlan header, the length of the packet will be greater
    then MTU+ETH_HLEN since it will account of the extra
    vlan header.  TG3 checks this for the case for 802.1Q,
    but not for 802.1ad.  As a result, full sized 802.1ad
    frames get dropped by the card.
    
    Add a check for 802.1ad protocol when receving full
    sized frames.
    
    Suggested-by: Prashant Sreedharan <[email protected]>
    CC: Prashant Sreedharan <[email protected]>
    CC: Michael Chan <[email protected]>
    Signed-off-by: Vladislav Yasevich <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 1e918876853aa85435e0f17fd8b4a92dcfff53d6
Author: Florian Westphal <[email protected]>
Date:   Wed Oct 1 13:38:03 2014 +0200

    r8169: add support for Byte Queue Limits
    
    tested on RTL8168d/8111d model using 'super_netperf 40' with TCP/UDP_STREAM.
    
    Output of
    while true; do
        for n in inflight limit; do
              echo -n $n\ ; cat $n;
        done;
        sleep 1;
    done
    
    during netperf run, 100mbit peer:
    
    inflight 0
    limit 3028
    inflight 6056
    limit 4542
    
    [ trimmed output for brevity, no limit/inflight changes during
      test steady-state ]
    
    limit 4542
    inflight 3028
    limit 6122
    inflight 0
    limit 6122
    [ changed cable to 1gbit peer, restart netperf ]
    inflight 37850
    limit 36336
    inflight 33308
    limit 31794
    inflight 33308
    limit 31794
    inflight 27252
    limit 25738
    [ again, no changes during test ]
    inflight 27252
    limit 25738
    inflight 0
    limit 28766
    [ change cable to 100mbit peer, restart netperf ]
    limit 28766
    inflight 27370
    limit 28766
    inflight 4542
    limit 5990
    inflight 6056
    limit 4542
    [ .. ]
    inflight 6056
    limit 4542
    inflight 0
    
    [end of test]
    
    Cc: Francois Romieu <[email protected]>
    Cc: Hayes Wang <[email protected]>
    Signed-off-by: Florian Westphal <[email protected]>
    Acked-by: Eric Dumazet <[email protected]>
    Acked-by: Tom Herbert <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d0bf4a9e92b9a93ffeeacbd7b6cb83e0ee3dc2ef
Author: Eric Dumazet <[email protected]>
Date:   Mon Sep 29 13:29:15 2014 -0700

    net: cleanup and document skb fclone layout
    
    Lets use a proper structure to clearly document and implement
    skb fast clones.
    
    Then, we might experiment more easily alternative layouts.
    
    This patch adds a new skb_fclone_busy() helper, used by tcp and xfrm,
    to stop leaking of implementation details.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0f1ca65ee50df042051e8fa3a14f73b0c71d45b9
Author: Arianna Avanzini <[email protected]>
Date:   Fri Aug 22 13:20:02 2014 +0200

    xen, blkfront: factor out flush-related checks from do_blkif_request()
    
    This commit factors out some checks related to the request insertion
    path, which can be done in an function instead of by itself.
    
    Reviewed-by: David Vrabel <[email protected]>
    Signed-off-by: Arianna Avanzini <[email protected]>
    Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>

commit 61cecca865280bef4f8a9748d0a9afa5df351ac2
Author: Roger Pau Monné <[email protected]>
Date:   Mon Sep 15 11:55:27 2014 +0200

    xen-blkback: fix leak on grant map error path
    
    Fix leaking a page when a grant mapping has failed.
    
    CC: [email protected]
    Signed-off-by: Roger Pau Monné <[email protected]>
    Reported-and-Tested-by: Tao Chen <[email protected]>
    Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>

commit 12ea729645ace01e08f9654df155622898d3aae6
Author: Vitaly Kuznetsov <[email protected]>
Date:   Mon Sep 8 15:21:33 2014 +0200

    xen/blkback: unmap all persistent grants when frontend gets disconnected
    
    blkback does not unmap persistent grants when frontend goes to Closed
    state (e.g. when blkfront module is being removed). This leads to the
    following in guest's dmesg:
    
    [  343.243825] xen:grant_table: WARNING: g.e. 0x445 still in use!
    [  343.243825] xen:grant_table: WARNING: g.e. 0x42a still in use!
    ...
    
    When load module -> use device -> unload module sequence is performed multiple times
    it is possible to hit BUG() condition in blkfront module:
    
    [  343.243825] kernel BUG at drivers/block/xen-blkfront.c:954!
    [  343.243825] invalid opcode: 0000 [#1] SMP
    [  343.243825] Modules linked in: xen_blkfront(-) ata_generic pata_acpi [last unloaded: xen_blkfront]
    ...
    [  343.243825] Call Trace:
    [  343.243825]  [<ffffffff814111ef>] ? unregister_xenbus_watch+0x16f/0x1e0
    [  343.243825]  [<ffffffffa0016fbf>] blkfront_remove+0x3f/0x140 [xen_blkfront]
    ...
    [  343.243825] RIP  [<ffffffffa0016aae>] blkif_free+0x34e/0x360 [xen_blkfront]
    [  343.243825]  RSP <ffff88001eb8fdc0>
    
    We don't need to keep these grants if we're disconnecting as frontend might already
    forgot about them. Solve the issue by moving xen_blkbk_free_caches() call from
    xen_blkif_free() to xen_blkif_disconnect().
    
    Now we can see the following:
    [  928.590893] xen:grant_table: WARNING: g.e. 0x587 still in use!
    [  928.591861] xen:grant_table: WARNING: g.e. 0x372 still in use!
    ...
    [  929.592146] xen:grant_table: freeing g.e. 0x587
    [  929.597174] xen:grant_table: freeing g.e. 0x372
    ...
    
    Backend does not keep persistent grants any more, reconnect works fine.
    
    CC: [email protected]
    Signed-off-by: Vitaly Kuznetsov <[email protected]>
    Signed-off-by: Konrad Rzeszutek Wilk <[email protected]>

commit b248230c34970a6c1c17c591d63b464e8d2cfc33
Author: Yuchung Cheng <[email protected]>
Date:   Mon Sep 29 13:20:38 2014 -0700

    tcp: abort orphan sockets stalling on zero window probes
    
    Currently we have two different policies for orphan sockets
    that repeatedly stall on zero window ACKs. If a socket gets
    a zero window ACK when it is transmitting data, the RTO is
    used to probe the window. The socket is aborted after roughly
    tcp_orphan_retries() retries (as in tcp_write_timeout()).
    
    But if the socket was idle when it received the zero window ACK,
    and later wants to send more data, we use the probe timer to
    probe the window. If the receiver always returns zero window ACKs,
    icsk_probes keeps getting reset in tcp_ack() and the orphan socket
    can stall forever until the system reaches the orphan limit (as
    commented in tcp_probe_timer()). This opens up a simple attack
    to create lots of hanging orphan sockets to burn the memory
    and the CPU, as demonstrated in the recent netdev post "TCP
    connection will hang in FIN_WAIT1 after closing if zero window is
    advertised." http://www.spinics.net/lists/netdev/msg296539.html
    
    This patch follows the design in RTO-based probe: we abort an orphan
    socket stalling on zero window when the probe timer reaches both
    the maximum backoff and the maximum RTO. For example, an 100ms RTT
    connection will timeout after roughly 153 seconds (0.3 + 0.6 +
    .... + 76.8) if the receiver keeps the window shut. If the orphan
    socket passes this check, but the system already has too many orphans
    (as in tcp_out_of_resources()), we still abort it but we'll also
    send an RST packet as the connection may still be active.
    
    In addition, we change TCP_USER_TIMEOUT to cover (life or dead)
    sockets stalled on zero-window probes. This changes the semantics
    of TCP_USER_TIMEOUT slightly because it previously only applies
    when the socket has pending transmission.
    
    Signed-off-by: Yuchung Cheng <[email protected]>
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: Neal Cardwell <[email protected]>
    Reported-by: Andrey Dmitrov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 3edfe0030bb7a82dab2a30a29ea6e1800e600c4b
Author: Helge Deller <[email protected]>
Date:   Wed Oct 1 22:11:01 2014 +0200

    parisc: Fix serial console for machines with serial port on superio chip
    
    Fix the serial console on machines where the serial port is located on
    the SuperIO chip.
    
    Signed-off-by: Helge Deller <[email protected]>
    Cc: Peter Hurley <[email protected]>

commit baf378126b08474de2e2428b16e62a69df0339d9
Author: Michael Opdenacker <[email protected]>
Date:   Wed Oct 1 14:07:39 2014 -0600

    rsxx: Remove deprecated IRQF_DISABLED
    
    This removes the use of the IRQF_DISABLED flag
    from drivers/block/rsxx/core.c
    
    It's a NOOP since 2.6.35 and it will be removed one day.
    
    Signed-off-by: Michael Opdenacker <[email protected]>
    Acked-by Philip Kelleher <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit cb57659a15c6c0576493cc8a10474ce7ffd44eb3
Author: Fabian Frederick <[email protected]>
Date:   Wed Oct 1 19:30:03 2014 +0200

    cipso: add __init to cipso_v4_cache_init
    
    cipso_v4_cache_init is only called by __init cipso_v4_init
    
    Signed-off-by: Fabian Frederick <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 57a02c39c1c20ed03a86f8014c11a8c18b94cac3
Author: Fabian Frederick <[email protected]>
Date:   Wed Oct 1 19:18:57 2014 +0200

    inet: frags: add __init to ip4_frags_ctl_register
    
    ip4_frags_ctl_register is only called by __init ipfrag_init
    
    Signed-off-by: Fabian Frederick <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 47d7a88c188f06ffaea3a539f84fe10cb4e77787
Author: Fabian Frederick <[email protected]>
Date:   Wed Oct 1 18:27:50 2014 +0200

    tcp: add __init to tcp_init_mem
    
    tcp_init_mem is only called by __init tcp_init.
    
    Signed-off-by: Fabian Frederick <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit ee7a1beb9759c94aea67dd887faf5e447a5c6710
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:21 2014 +0800

    r8169:call "rtl8168_driver_start" "rtl8168_driver_stop" only when hardware dash function is enabled
    
    These two functions are used to inform dash firmware that driver is been
    brought up or brought down. So call these two functions only when hardware dash
    function is enabled.
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 2a9b4d9670e71784896d95c41c9b0acd50db1dbb
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:20 2014 +0800

    r8169:modify the behavior of function "rtl8168_oob_notify"
    
    In function "rtl8168_oob_notify", using function "rtl_eri_write" to access
    eri register 0xe8, instead of using MAC register "ERIDR" and "ERIAR" to
    access it.
    
    For using function "rtl_eri_write" in function "rtl8168_oob_notify", need to
    move down "rtl8168_oob_notify" related functions under the function
    "rtl_eri_write".
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 2f8c040ce6791ef0477e6d59768ee3d5fd0df0fd
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:19 2014 +0800

    r8169:change the name of function "r8168dp_check_dash" to "r8168_check_dash"
    
    DASH function not only RTL8168DP can support, but also RTL8168EP.
    So change the name of function "r8168dp_check_dash" to "r8168_check_dash".
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 706123d06c18b55da5e9da21e2d138ee789bf8f4
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:18 2014 +0800

    r8169:change the name of function"rtl_w1w0_eri"
    
    Change the name of function "rtl_w1w0_eri" to "rtl_w0w1_eri".
    
    In this function, the local variable "val" is "write zeros then write ones".
    Please see below code.
    
    (val & ~m) | p
    
    In this patch, change the function name from "xx_w1w0_xx" to "xx_w0w1_xx".
    The changed function name is more suitable for it's behavior.
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 7656442824f6174b56a19c664fe560972df56ad4
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:17 2014 +0800

    r8169:for function "rtl_w1w0_phy" change its name and behavior
    
    Change function name from "rtl_w1w0_phy" to "rtl_w0w1_phy".
    And its behavior from "write ones then write zeros" to
    "write zeros then write ones".
    
    In Realtek internal driver, bitwise operations are almost "write zeros then
    write ones". For easy to port hardware parameters from Realtek internal driver
    to Linux kernal driver "r8169", we would like to change this function's
    behavior and its name.
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit ac85bcdbc0ffd3903d6db4abcd769ecacf98605b
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:16 2014 +0800

    r8169:add more chips to support magic packet v2
    
    For RTL8168F RTL8168FB RTL8168G RTL8168GU RTL8411 RTL8411B RTL8402 RTL8107E,
    the magic packet enable bit is changed to eri 0xde bit0.
    
    In this patch, change magic packet enable bit of these chips to eri 0xde bit0.
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 89cceb2729c752e6ff9b3bc8650a70f29884f116
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:15 2014 +0800

    r8169:add support more chips to get mac address from backup mac address register
    
    RTL8168FB RTL8168G RTL8168GU RTL8411 RTL8411B RTL8106EUS RTL8402 can
    support get mac address from backup mac address register.
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 42fde7371035144037844f41bd16950de9912bdb
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:14 2014 +0800

    r8169:add disable/enable RTL8411B pll function
    
    RTL8411B can support disable/enable pll function.
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit b8e5e6ad7115befef13a4493f1d2b8e438abc058
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:13 2014 +0800

    r8169:add disable/enable RTL8168G pll function
    
    RTL8168G also can disable/enable pll function.
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 05b9687bb3606190304f08c2e4cd63de8717e30b
Author: Chun-Hao Lin <[email protected]>
Date:   Wed Oct 1 23:17:12 2014 +0800

    r8169:change uppercase number to lowercase number
    
    Signed-off-by: Chun-Hao Lin <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a29c9c43bb633a9965909cd548879fee4aa789a4
Author: David L Stevens <[email protected]>
Date:   Wed Oct 1 11:05:27 2014 -0400

    sunvnet: fix potential NULL pointer dereference
    
    One of the error cases for vnet_start_xmit()'s "out_dropped" label
    is port == NULL, so only mess with port->clean_timer when port is not NULL.
    
    Signed-off-by: David L Stevens <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit e506d405ac7d34d03996c97ac68aa2ac010be64a
Author: Thierry Reding <[email protected]>
Date:   Wed Oct 1 13:59:00 2014 +0200

    net: dsa: Fix build warning for !PM_SLEEP
    
    The dsa_switch_suspend() and dsa_switch_resume() functions are only used
    when PM_SLEEP is enabled, so they need #ifdef CONFIG_PM_SLEEP protection
    to avoid a compiler warning.
    
    Signed-off-by: Thierry Reding <[email protected]>
    Acked-by: Florian Fainelli <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 84ac1f2ca41f5888cc995944c073a5220f3ed549
Author: Tanmay Inamdar <[email protected]>
Date:   Fri Sep 26 14:08:25 2014 -0700

    arm64: dts: Add APM X-Gene PCIe device tree nodes
    
    Add the device tree nodes for APM X-Gene PCIe host controller and PCIe
    clock interface.  Since X-Gene SOC supports maximum 5 ports, 5 dts nodes
    are added.
    
    Signed-off-by: Tanmay Inamdar <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 2896e4418b17363f211e084471b589e3c06a7248
Author: Bjorn Helgaas <[email protected]>
Date:   Wed Oct 1 13:01:35 2014 -0600

    PCI: xgene: Add APM X-Gene PCIe driver
    
    Add the AppliedMicro X-Gene SOC PCIe host controller driver.  The X-Gene
    PCIe controller supports up to 8 lanes and GEN3 speed.  The X-Gene SOC
    supports up to 5 PCIe ports.
    
    [bhelgaas: folded in MAINTAINERS and bindings updates]
    Tested-by: Ming Lei <[email protected]>
    Tested-by: Dann Frazier <[email protected]>
    Signed-off-by: Tanmay Inamdar <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Liviu Dudau <[email protected]> (driver)

commit 3c87dcbfb36ce6d3d9087f0163c02ba5690d9a85
Author: Subbaraya Sundeep Bhatta <[email protected]>
Date:   Wed Oct 1 11:01:17 2014 +0200

    net: ll_temac: Remove unnecessary ether_setup after alloc_etherdev
    
    Calling ether_setup is redundant since alloc_etherdev calls it.
    
    Signed-off-by: Subbaraya Sundeep Bhatta <[email protected]>
    Signed-off-by: Michal Simek <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 8493ecca74a7b4a66e19676de1a0f14194179941
Author: Benjamin Tissoires <[email protected]>
Date:   Wed Oct 1 11:59:47 2014 -0400

    HID: uHID: fix excepted report type
    
    When uhid_get_report() or uhid_set_report() are called, they emit on the
    char device a UHID_GET_REPORT or UHID_SET_REPORT message. Then, the
    protocol says that the user space asnwers with UHID_GET_REPORT_REPLY
    or UHID_SET_REPORT_REPLY.
    
    Unfortunatelly, the current code waits for an event of type UHID_GET_REPORT
    or UHID_SET_REPORT instead of the reply one.
    Add 1 to UHID_GET_REPORT or UHID_SET_REPORT to actually wait for the
    reply, and validate the reply.
    
    Signed-off-by: Benjamin Tissoires <[email protected]>
    Reviewed-by: David Herrmann <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>

commit c8df6ac9452e8f47a6f660993c526d13e858a6f3
Author: Lucas Stach <[email protected]>
Date:   Tue Sep 30 18:36:27 2014 +0200

    PCI: designware: Remove open-coded bitmap operations
    
    Replace them by using the standard kernel bitmap ops.  No functional
    change, but makes the code a lot cleaner.
    
    Signed-off-by: Lucas Stach <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Reviewed-by: Pratyush Anand <[email protected]>
    Acked-by: Jingoo Han <[email protected]>

commit 2199f0608864cf4e8c93d37842a5ee50c8d79843
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: sort writes
    
    Write requests are sorted in a red-black tree structure and are
    submitted in the sorted order.
    
    In theory the sorting should be performed by the underlying disk
    scheduler, however, in practice the disk scheduler only accepts and
    sorts a finite number of requests.  To allow the sorting of all
    requests, dm-crypt needs to implement its own own sorting.
    
    The overhead associated with rbtree-based sorting is considered
    negligible so it is not used conditionally.  Even on SSD sorting can be
    beneficial since in-order request dispatch promotes lower latency IO
    completion to the upper layers.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 648fee35be4c75667aa18bf513f7e7e65c01640b
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: offload writes to thread
    
    Submitting write bios directly in the encryption thread caused serious
    performance degradation.  On a multiprocessor machine, encryption requests
    finish in a different order than they were submitted.  Consequently, write
    requests would be submitted in a different order and it could cause severe
    performance degradation.
    
    Move the submission of write requests to a separate thread so that the
    requests can be sorted before submitting.  But this commit improves
    dm-crypt performance even without having dm-crypt perform request
    sorting (in particular it enables IO schedulers like CFQ to sort more
    effectively).
    
    Note: it is required that a previous commit ("dm crypt: don't allocate
    pages for a partial request") be applied before applying this patch.
    Otherwise, this commit could introduce a crash.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 4a0d7e0464226eee625a5b77484c339334453882
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 28 15:51:55 2014 -0400

    dm crypt: use unbound workqueue for request processing
    
    Use unbound workqueue so that work is automatically balanced between
    available CPUs.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 72bfc40ca3b393cb0bc6b5e2ce364e6c6ce0f390
Author: Mikulas Patocka <[email protected]>
Date:   Thu May 29 14:18:12 2014 -0400

    dm crypt: remove io_pending refcount member from dm_crypt_io
    
    Commit "dm crypt: don't allocate pages for a partial request" changed
    the code to allocate all pages for one request.  There is always just
    one pending request, so the io_pending refcount may be removed.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 42196fec8945cc84c032b7f59deaffee82036245
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: remove unused io_pool and _crypt_io_pool
    
    The previous commits ("dm crypt: use per-bio data") and ("dm crypt:
    don't allocate pages for a partial request") stopped using the
    io_pool slab mempool and backing _crypt_io_pool kmem cache.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit ebfda24b1e1bf483accdb900f8625151d8f01383
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: avoid deadlock in mempools
    
    Fix a theoretical deadlock introduced in the previous commit ("dm crypt:
    don't allocate pages for a partial request").
    
    The function crypt_alloc_buffer may be called concurrently.  If we allocate
    from the mempool concurrently, there is a possibility of deadlock.  For
    example, if we have mempool of 256 pages, two processes, each wanting
    256, pages allocate from the mempool concurrently, it may deadlock in a
    situation where both processes have allocated 128 pages and the mempool
    is exhausted.
    
    In order to avoid such a scenario, we allocate the pages under a mutex.
    
    In order to not degrade performance with excessive locking, we try
    non-blocking allocations without a mutex first and if it fails, we
    fallback to a blocking allocation with a mutex.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit b9ea7cb3fb237078be400522880932008c630fb7
Author: Mikulas Patocka <[email protected]>
Date:   Fri Mar 28 15:51:56 2014 -0400

    dm crypt: don't allocate pages for a partial request
    
    Change crypt_alloc_buffer so that it only ever allocates pages for a
    full request.
    
    This change is a prerequisite for the commit "dm crypt: offload writes
    to thread".  Which implies this change is effectively required for the
    upcoming cpu parallelization changes.
    
    But this change simplifies the dm-crypt code at the expense of reduced
    throughput in low memory conditions (where allocation for a partial
    request is most useful).
    
    This change also enables the removal of the io_pending refcount.
    
    Note: the next commit ("dm-crypt: avoid deadlock in mempools") is needed
    to fix a theoretical deadlock.
    
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 117cd3e12232afea97dd31489fbde8888ad22b3e
Author: Heinz Mauelshagen <[email protected]>
Date:   Wed Sep 24 17:47:19 2014 +0200

    dm raid: add discard support for RAID levels 4, 5 and 6
    
    In case of RAID levels 4, 5 and 6 we have to verify each RAID members'
    ability to zero data on discards to avoid stripe data corruption -- if
    discard_zeroes_data is not set for each RAID member discard support must
    be disabled.
    
    Also add an 'ignore_discard' table argument to the target in order to
    ignore discard processing completely on a RAID array, hence not passing
    down discards to MD personalities.
    
    This 'ignore_discard' control provides the ability to:
    - prohibit discards in case of _potential_ data corruptions in RAID4/5/6
      (e.g. if ability to zero data on discard is flawed in a RAID member)
    - avoid discard processing overhead
    
    Signed-off-by: Heinz Mauelshagen <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>

commit 04c308f43a90a9b3b84c344b324d6af29288da05
Author: Mikulas Patocka <[email protected]>
Date:   Wed Oct 1 13:29:48 2014 -0400

    dm bufio: when done scanning return from __scan immediately
    
    When __scan frees the required number of buffer entries that the
    shrinker requested (nr_to_scan becomes zero) it must return.  Before
    this fix the __scan code exited only the inner loop and continued in the
    outer loop.
    
    Also, move dm_bufio_cond_resched to __scan's inner loop, so that
    iterating the bufio client's lru lists doesn't result in scheduling
    latency.
    
    Reported-by: Joe Thornber <[email protected]>
    Signed-off-by: Mikulas Patocka <[email protected]>
    Signed-off-by: Mike Snitzer <[email protected]>
    Cc: [email protected] # 3.2+

commit 5ec094057c7df5ff80f5e7fe282f47ad205fb976
Author: Bjorn Helgaas <[email protected]>
Date:   Tue Sep 23 14:38:28 2014 -0600

    PCI/MSI: Remove unnecessary temporary variable
    
    The only use of "status" is to hold a value which is immediately returned,
    so just return and remove the variable directly.
    
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 56b72b40957947f7c08771f030102351d4c906df
Author: Yijing Wang <[email protected]>
Date:   Mon Sep 29 18:35:16 2014 -0600

    PCI/MSI: Use __write_msi_msg() instead of write_msi_msg()
    
    default_restore_msi_irq() already has the struct msi_desc pointer required
    by __write_msi_msg(), so call it directly instead of having write_msi_msg()
    look it up from the IRQ.
    
    No functional change.
    
    [bhelgaas: split into separate patch]
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 1e8f4cc82eded0c3c97ef6e2f119782e42deda35
Author: Yijing Wang <[email protected]>
Date:   Wed Sep 24 11:09:45 2014 +0800

    MSI/powerpc: Use __read_msi_msg() instead of read_msi_msg()
    
    rtas_setup_msi_irqs() already has the struct msi_desc pointer required by
    __read_msi_msg(), so call it directly instead of having read_msi_msg() look
    it up from the IRQ.
    
    No functional change.
    
    [bhelgaas: changelog]
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Michael Ellerman <[email protected]>
    CC: Benjamin Herrenschmidt <[email protected]>
    CC: [email protected]

commit 2b260085e466c345e78f23b1c9ad1d123d509ef8
Author: Yijing Wang <[email protected]>
Date:   Tue Sep 23 13:27:25 2014 +0800

    PCI/MSI: Use __get_cached_msi_msg() instead of get_cached_msi_msg()
    
    Both callers of get_cached_msi_msg() start with a struct irq_data pointer,
    look up the corresponding IRQ number, and pass it to get_cached_msi_msg(),
    which then uses irq_get_irq_data() to look up the struct irq_data again to
    call __get_cached_msi_msg().
    
    Since we already have the struct irq_data, call __get_cached_msi_msg()
    directly and skip the lookup work done by get_cached_msi_msg().
    
    No functional change.
    
    [bhelgaas: changelog]
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    CC: Tony Luck <[email protected]>
    CC: [email protected]

commit 468ff15a3ab98ed7153c29c68229ffb97f15a251
Author: Yijing Wang <[email protected]>
Date:   Tue Sep 23 13:27:24 2014 +0800

    PCI/MSI: Add "msi_bus" sysfs MSI/MSI-X control for endpoints
    
    The "msi_bus" sysfs file for bridges sets a bus flag to allow or disallow
    future driver requests for MSI or MSI-X.  Previously, the sysfs file
    existed for endpoints but did nothing.
    
    Add "msi_bus" support for endpoints, so an administrator can prevent the
    use of MSI and MSI-X for individual devices.
    
    Note that as for bridges, these changes only affect future driver requests
    for MSI or MSI-X, so drivers may need to be reloaded.
    
    Add documentation for the "msi_bus" sysfs file.
    
    [bhelgaas: changelog, comments, add "subordinate", add endpoint printk,
    rework bus_flags setting, make bus_flags printk unconditional]
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 48c3c38f003c25d50a09d3da558667c5ecd530aa
Author: Yijing Wang <[email protected]>
Date:   Tue Sep 23 11:02:42 2014 -0600

    PCI/MSI: Remove "pos" from the struct msi_desc msi_attrib
    
    "msi_attrib.pos" is only used for MSI (not MSI-X), and we already cache the
    MSI capability offset in "dev->msi_cap".
    
    Remove "pos" from the struct msi_attrib and use "dev->msi_cap" directly.
    
    [bhelgaas: changelog, fix whitespace]
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 81052769e48609525c452d8f078a5786b673e178
Author: Yijing Wang <[email protected]>
Date:   Tue Sep 23 13:27:22 2014 +0800

    PCI/MSI: Remove unused kobject from struct msi_desc
    
    After commit 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not
    kobjects"), the kobject in struct msi_desc is unused.
    
    Remove the unused struct kobject from struct msi_desc.
    
    [bhelgaas: changelog]
    Fixes: 1c51b50c2995 ("PCI/MSI: Export MSI mode using attributes, not kobjects")
    Signed-off-by: Yijing Wang <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Greg Kroah-Hartman <[email protected]>

commit a06cd74cefe754341f747ddc4cf7b0058fa9bff8
Author: Alexander Gordeev <[email protected]>
Date:   Tue Sep 23 12:45:58 2014 -0600

    PCI/MSI: Rename pci_msi_check_device() to pci_msi_supported()
    
    Rename pci_msi_check_device() to pci_msi_supported() for clarity.  Note
    that pci_msi_supported() returns true if MSI/MSI-X is supported, so code
    like:
    
      if (pci_msi_supported(...))
    
    reads naturally.
    
    [bhelgaas: changelog, split to separate patch, reverse sense]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 27e20603c54ba633ed259284d006275f13c9f95b
Author: Alexander Gordeev <[email protected]>
Date:   Tue Sep 23 14:25:11 2014 -0600

    PCI/MSI: Move D0 check into pci_msi_check_device()
    
    Both callers of pci_msi_check_device() check that the device is in D0
    state, so move the check from the callers into pci_msi_check_device()
    itself.
    
    In pci_enable_msi_range(), note that pci_msi_check_device() never returns a
    positive value any more, so the loop that called it until it returns zero
    or negative is no longer necessary.
    
    [bhelgaas: changelog, split to separate patch]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit ad975ebad4c3ce8dcc7d0bb4db26ea5aca4cfc99
Author: Alexander Gordeev <[email protected]>
Date:   Tue Sep 23 12:39:54 2014 -0600

    PCI/MSI: Remove arch_msi_check_device()
    
    No architectures implement arch_msi_check_device() or the struct msi_chip
    .check_device() method, so remove them.
    
    Remove the "type" parameter to pci_msi_check_device() because it was only
    used to call arch_msi_check_device() and is no longer needed.
    
    [bhelgaas: changelog, split to separate patch]
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit 3930115e0dd67f61b3b1882c7a34d0baeff1bb4c
Author: Alexander Gordeev <[email protected]>
Date:   Sun Sep 7 20:57:54 2014 +0200

    irqchip: armada-370-xp: Remove arch_msi_check_device()
    
    Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs().
    This makes the code more compact and allows removing
    arch_msi_check_device() from generic MSI code.
    
    Tested-by: Thomas Petazzoni <[email protected]>
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Jason Cooper <[email protected]>
    CC: Thomas Gleixner <[email protected]>

commit 6b2fd7efeb888fa781c1f767de6c36497ac1596b
Author: Alexander Gordeev <[email protected]>
Date:   Sun Sep 7 20:57:53 2014 +0200

    PCI/MSI/PPC: Remove arch_msi_check_device()
    
    Move MSI checks from arch_msi_check_device() to arch_setup_msi_irqs().
    This makes the code more compact and allows removing
    arch_msi_check_device() from generic MSI code.
    
    Signed-off-by: Alexander Gordeev <[email protected]>
    Signed-off-by: Bjorn Helgaas <[email protected]>
    Acked-by: Michael Ellerman <[email protected]>

commit 977104ece1568f2e2ad3f5fd8e55bd640e8ab55a
Author: Mark Charlebois <[email protected]>
Date:   Thu Sep 4 14:16:17 2014 -0700

    arm: LLVMLinux: Use global stack register variable for percpu
    
    Using global current_stack_pointer works on both clang and gcc.
    current_stack_pointer is an unsigned long and needs to be cast
    as a pointer to dereference.
    
    KernelVersion: 3.17.0-rc6
    Signed-off-by: Mark Charlebois <[email protected]>
    Signed-off-by: Behan Webster <[email protected]>

commit a35dc594542b29935cd3a92e53233ad4ba4e622f
Author: Behan Webster <[email protected]>
Date:   Tue Sep 3 22:27:27 2013 -0400

    arm: LLVMLinux: Use current_stack_pointer in unwind_backtrace
    
    Use the global current_stack_pointer to get the value of the stack pointer.
    This change supports being able to compile the kernel with both gcc and clang.
    
    KernelVersion: 3.17.0-rc6
    Signed-off-by: Behan Webster <[email protected]>
    Reviewed-by: Mark Charlebois <[email protected]>
    Reviewed-by: Jan-Simon Möller <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>

commit 5c5da6724d8e1767405a3f4b611451a11ece99e2
Author: Behan Webster <[email protected]>
Date:   Tue Sep 3 22:27:27 2013 -0400

    arm: LLVMLinux: Calculate current_thread_info from current_stack_pointer
    
    Use the global current_stack_pointer to get the value of the stack pointer.
    This change supports being able to compile the kernel with both gcc and clang.
    
    KernelVersion: 3.17.0-rc6
    Signed-off-by: Behan Webster <[email protected]>
    Reviewed-by: Mark Charlebois <[email protected]>
    Reviewed-by: Jan-Simon Möller <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>

commit f2b6d8c6c56c9a164a2d885ba34a09d613c959c9
Author: Behan Webster <[email protected]>
Date:   Tue Sep 3 22:27:27 2013 -0400

    arm: LLVMLinux: Use current_stack_pointer in save_stack_trace_tsk
    
    Use the global current_stack_pointer to get the value of the stack pointer.
    This change supports being able to compile the kernel with both gcc and clang.
    
    KernelVersion: 3.17.0-rc6
    Signed-off-by: Behan Webster <[email protected]>
    Reviewed-by: Mark Charlebois <[email protected]>
    Reviewed-by: Jan-Simon Möller <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>

commit 40802b84566a3d9731a8fea43b144301d9ac450d
Author: Behan Webster <[email protected]>
Date:   Tue Sep 3 22:27:27 2013 -0400

    arm: LLVMLinux: Use current_stack_pointer for return_address
    
    Use the global current_stack_pointer to get the value of the stack pointer.
    This change supports being able to compile the kernel with both gcc and Clang.
    
    KernelVersion: 3.17.0-rc6
    Signed-off-by: Behan Webster <[email protected]>
    Reviewed-by: Mark Charlebois <[email protected]>
    Reviewed-by: Jan-Simon Möller <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>

commit d80ced5236764b8c4ffda5545d5b357cf88c77c1
Author: Behan Webster <[email protected]>
Date:   Tue Sep 3 22:27:27 2013 -0400

    arm: LLVMLinux: Use current_stack_pointer to calculate pt_regs address
    
    Use the global current_stack_pointer to calculate the end of the stack for
    current_pt_regs()
    
    KernelVersion: 3.17.0-rc6
    Signed-off-by: Behan Webster <[email protected]>
    Reviewed-by: Mark Charlebois <[email protected]>
    Reviewed-by: Jan-Simon Möller <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>

commit 9d0d6994806b36891453beb1e94b6253f853af61
Author: Behan Webster <[email protected]>
Date:   Tue Sep 3 22:27:26 2013 -0400

    arm: LLVMLinux: Add global named register current_stack_pointer for ARM
    
    Define a global named register for current_stack_pointer. The use of this new
    variable guarantees that both gcc and clang can access this register in C code.
    
    KernelVersion: 3.17.0-rc6
    Signed-off-by: Behan Webster <[email protected]>
    Reviewed-by: Jan-Simon Möller <[email protected]>
    Reviewed-by: Mark Charlebois <[email protected]>
    Acked-by: Will Deacon <[email protected]>
    Acked-by: Nicolas Pitre <[email protected]>

commit 2c804d0f8fc7799981d9fdd8c88653541b28c1a7
Author: Eric Dumazet <[email protected]>
Date:   Tue Sep 30 22:12:05 2014 -0700

    ipv4: mentions skb_gro_postpull_rcsum() in inet_gro_receive()
    
    Proper CHECKSUM_COMPLETE support needs to adjust skb->csum
    when we remove one header. Its done using skb_gro_postpull_rcsum()
    
    In the case of IPv4, we know that the adjustment is not really needed,
    because the checksum over IPv4 header is 0. Lets add a comment to
    ease code comprehension and avoid copy/paste errors.
    
    Signed-off-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit eb51bbaf8dedf142a54a7ff58514a29b40d515bb
Author: Stephen Rothwell <[email protected]>
Date:   Wed Oct 1 17:00:49 2014 +1000

    fm10k: using vmalloc requires including linux/vmalloc.h
    
    Signed-off-by: Stephen Rothwell <[email protected]>
    Acked-by: Jeff Kirsher <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 078efae00ffc76381c3248006e9cf0988163488f
Author: Anish Bhatt <[email protected]>
Date:   Mon Sep 15 17:44:18 2014 -0700

    [SCSI] cxgb4i: avoid holding mutex in interrupt context
    
    cxgbi_inet6addr_handler() can be called in interrupt context, so use rcu
    protected list while finding netdev.  This is observed as a scheduling in
    atomic oops when running over ipv6.
    
    Fixes: fc8d0590d914 ("libcxgbi: Add ipv6 api to driver")
    Fixes: 759a0cc5a3e1 ("cxgb4i: Add ipv6 code to driver, call into libcxgbi ipv6 api")
    
    Signed-off-by: Anish Bhatt <[email protected]>
    Signed-off-by: Karen Xie <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: James Bottomley <[email protected]>

commit 34549ab09e62db9703811c6ed4715f2ffa1fd7fb
Author: Jeff Layton <[email protected]>
Date:   Wed Oct 1 08:05:22 2014 -0400

    nfsd: eliminate "to_delegation" define
    
    We now have cb_to_delegation and to_delegation, which do the same thing
    and are defined separately in different .c files. Move the
    cb_to_delegation definition into a header file and eliminate the
    redundant to_delegation definition.
    
    Reviewed-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jeff Layton <[email protected]>

commit 4a0efdc933680d908de11712a774a2c9492c3d5a
Author: Hannes Reinecke <[email protected]>
Date:   Wed Oct 1 14:32:31 2014 +0200

    block: misplaced rq_complete tracepoint
    
    The rq_complete tracepoint was never issued for empty requests,
    causing the resulting blktrace information to never show any
    completion for those request.
    
    Signed-off-by: Hannes Reinecke <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit fc2021fb9baf9ed375c8161b40b68e120e75c60e
Author: Michael Opdenacker <[email protected]>
Date:   Wed Oct 1 12:07:07 2014 +0200

    block: hd: remove deprecated IRQF_DISABLED
    
    This patch removes the use of the IRQF_DISABLED flag
    from drivers/block/hd.c
    
    It's a NOOP since 2.6.35 and it will be removed one day.
    
    This also removes a related comment which is obsolete too.
    
    Signed-off-by: Michael Opdenacker <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 19aeb5a65f1a6504fc665466c188241e7393d66f
Author: Bob Peterson <[email protected]>
Date:   Mon Sep 29 08:52:04 2014 -0400

    GFS2: Make rename not save dirent location
    
    This patch fixes a regression in the patch "GFS2: Remember directory
    insert point", commit 2b47dad866d04f14c328f888ba5406057b8c7d33.
    The problem had to do with the rename function: The function found
    space for the new dirent, and remembered that location. But then the
    old dirent was removed, which often moved the eligible location for
    the renamed dirent. Putting the new dirent at the saved location
    caused file system corruption.
    
    This patch adds a new "save_loc" variable to struct gfs2_diradd.
    If 1, the dirent location is saved. If 0, the dirent location is not
    saved and the buffer_head is released as per previous behavior.
    
    Signed-off-by: Bob Peterson <[email protected]>
    Signed-off-by: Steven Whitehouse <[email protected]>

commit 5235166fbc332c8b5dcf49e3a498a8b510a77449
Author: Oliver Neukum <[email protected]>
Date:   Tue Sep 30 12:54:56 2014 +0200

    HID: usbhid: add another mouse that needs QUIRK_ALWAYS_POLL
    
    There is a second mouse sharing the same vendor strings but different IDs.
    
    Signed-off-by: Oliver Neukum <[email protected]>
    Signed-off-by: Jiri Kosina <[email protected]>

commit 2013add4ce73c93ae2148969a9ec3ecc8b1e26fa
Author: Gavin Shan <[email protected]>
Date:   Wed Oct 1 14:34:51 2014 +1000

    powerpc/eeh: Show hex prefix for PE state sysfs
    
    As Michael suggested, the hex prefix for the output of EEH PE
    state sysfs entry (/sys/bus/pci/devices/xxx/eeh_pe_state) is
    always informative to users.
    
    Suggested-by: Michael Ellerman <[email protected]>
    Signed-off-by: Gavin Shan <[email protected]>
    Signed-off-by: Michael Ellerman <[email protected]>

commit 24c20f10583647e30afe87b6f6d5e14bc7b1cbc6
Author: Christoph Hellwig <[email protected]>
Date:   Tue Sep 30 16:43:46 2014 +0200

    scsi: add a CONFIG_SCSI_MQ_DEFAULT option
    
    Add a Kconfig option to enable the blk-mq path for SCSI by default
    to ease testing and deployment in setups that know they benefit
    from blk-mq.
    
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Martin K. Petersen <[email protected]>
    Reviewed-by: Robert Elliott <[email protected]>
    Tested-by: Robert Elliott <[email protected]>

commit e785060ea3a1c8e37a8bc1449c79e36bff2b5b13
Author: Dolev Raviv <[email protected]>
Date:   Thu Sep 25 15:32:36 2014 +0300

    ufs: definitions for phy interface
    
    - Adding some of the definitions missing in unipro.h, including power
      enumeration.
    - Read Modify Write Line helper function
    - Indication for the type of suspend
    
    Signed-off-by: Dolev Raviv <[email protected]>
    Signed-off-by: Subhash Jadavani <[email protected]>
    Signed-off-by: Yaniv Gardi <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>

commit 374a246e4ebda1fc55d537877bf2412e511ecc7b
Author: Subhash Jadavani <[email protected]>
Date:   Thu Sep 25 15:32:35 2014 +0300

    ufs: tune bkops while power managment events
    
    Add capability to control the auto bkops during suspend.
    If host explicitly enables the auto bkops (background operation) on device
    then only device would perform the bkops on its own. If auto bkops is not
    enabled explicitly and if the device reaches to state where it must do
    background operation, device would raise the urgent bkops exception event
    to host and then host will enable the auto bkops on device. This patch
    adds the option to choose whether auto bkops should be enabled during
    runtime suspend or not. Since we don't want to keep the device active to
    perform the non critical bkops, host will enable urgent bkops only.
    
    Keep auto-bkops enabled after resume if urgent bkops needed.
    If device bkops status shows that its in critical need of executing
    background operations, host should allow the device to continue doing
    background operations.
    
    Signed-off-by: Subhash Jadavani <[email protected]>
    Signed-off-by: Dolev Raviv <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>

commit 856b348305c98d4e0c8e5eafa97c61443197f8d3
Author: Sahitya Tummala <[email protected]>
Date:   Thu Sep 25 15:32:34 2014 +0300

    ufs: Add support for clock scaling using devfreq framework
    
    The clocks for UFS device will be managed by generic DVFS (Dynamic
    Voltage and Frequency Scaling) framework within kernel. This devfreq
    framework works with different governors to scale the clocks. By default,
    UFS devices uses simple_ondemand governor which scales the clocks up if
    the load is more than upthreshold and scales down if the load is less than
    downthreshold.
    
    Signed-off-by: Sahitya Tummala <[email protected]>
    Signed-off-by: Dolev Raviv <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>

commit 4cff6d991e4a291cf50fe2659da2ea9ad46620bf
Author: Sahitya Tummala <[email protected]>
Date:   Thu Sep 25 15:32:33 2014 +0300

    ufs: Add freq-table-hz property for UFS device
    
    Add freq-table-hz propery for UFS device to keep track of
    <min max> frequencies supported by UFS clocks.
    
    Signed-off-by: Sahitya Tummala <[email protected]>
    Signed-off-by: Dolev Raviv <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>

commit 1ab27c9cf8b63dd8dec9e17b5c17721c7f3b6cc7
Author: Sahitya Tummala <[email protected]>
Date:   Thu Sep 25 15:32:32 2014 +0300

    ufs: Add support for clock gating
    
    The UFS controller clocks can be gated after certain period of
    inactivity, which is typically less than runtime suspend timeout.
    In addition to clocks the link will also be put into Hibern8 mode
    to save more power.
    
    The clock gating can be turned on by enabling the capability
    UFSHCD_CAP_CLK_GATING. To enable entering into Hibern8 mode as part of
    clock gating, set the capability UFSHCD_CAP_HIBERN8_WITH_CLK_GATING.
    
    The tracing events for clock gating can be enabled through debugfs as:
    echo 1 > /sys/kernel/debug/tracing/events/ufs/ufshcd_clk_gating/enable
    cat /sys/kernel/debug/tracing/trace_pipe
    
    Signed-off-by: Sahitya Tummala <[email protected]>
    Signed-off-by: Dolev Raviv <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>

commit 7eb584db73bebbc9852a14341431ed6935419bec
Author: Dolev Raviv <[email protected]>
Date:   Thu Sep 25 15:32:31 2014 +0300

    ufs: refactor configuring power mode
    
    Sometimes, the device shall report its maximum power and speed
    capabilities, but we might not wish to configure it to use those
    maximum capabilities.
    This change adds support for the vendor specific host driver to
    implement power change notify callback.
    
    To enable configuring different power modes (number of lanes,
    gear number and fast/slow modes) it is necessary to split the
    configuration stage from the stage that reads the device max power mode.
    In addition, it is not required to read the configuration more than
    once, thus the configuration is stored after reading it once.
    
    Signed-off-by: Dolev Raviv <[email protected]>
    Signed-off-by: Yaniv Gardi <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>

commit 57d104c153d3d6d7bea60089e80f37501851ed2c
Author: Subhash Jadavani <[email protected]>
Date:   Thu Sep 25 15:32:30 2014 +0300

    ufs: add UFS power management support
    
    This patch adds support for UFS device and UniPro link power management
    during runtime/system PM.
    
    Main idea is to define multiple UFS low power levels based on UFS device
    and UFS link power states. This would allow any specific platform or pci
    driver to choose the best suited low power level during runtime and
    system suspend based on their power goals.
    
    bkops handlig:
    To put the UFS device in sleep state when bkops is disabled, first query
    the bkops status from the device and enable bkops on device only if
    device needs time to perform the bkops.
    
    START_STOP handling:
    Before sending START_STOP_UNIT to the device well-known logical unit
    (w-lun) to make sure that the device w-lun unit attention condition is
    cleared.
    
    Write protection:
    UFS device specification allows LUs to be write protected, either
    permanently or power on write protected. If any LU is power on write
    protected and if the card is power cycled (by powering off VCCQ and/or
    VCC rails), LU's write protect status would be lost. So this means those
    LUs can be written now. To ensures that UFS device is power cycled only
    if the power on protect is not set for any of the LUs, check if power on
    write protect is set and if device is in sleep/power-off state & link in
    inactive state (Hibern8 or OFF state).
    If none of the Logical Units on UFS device is power on write protected
    then all UFS device power rails (VCC, VCCQ & VCCQ2) can be turned off if
    UFS device is in power-off state and UFS link is in OFF state. But current
    implementation would disable all device power rails even if UFS link is
    not in OFF state.
    
    Low power mode:
    If UFS link is in OFF state then UFS host controller can be power collapsed
    to avoid leakage current from it. Note that if UFS host controller is power
    collapsed, full UFS reinitialization will be required on resume to
    re-establish the link between host and device.
    
    Signed-off-by: Subhash Jadavani <[email protected]>
    Signed-off-by: Dolev Raviv <[email protected]>
    Signed-off-by: Sujit Reddy Thumma <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>

commit 0ce147d48a3e3352859f0c185e98e8392bee7a25
Author: Subhash Jadavani <[email protected]>
Date:   Thu Sep 25 15:32:29 2014 +0300

    ufs: introduce well known logical unit in ufs
    
    UFS device may have standard LUs and LUN id could be from 0x00 to 0x7F.
    UFS device specification use "Peripheral Device Addressing Format"
    (SCSI SAM-5) for standard LUs.
    
    UFS device may also have the Well Known LUs (also referred as W-LU) which
    again could be from 0x00 to 0x7F. For W-LUs, UFS device specification only
    allows the "Extended Addressing Format" (SCSI SAM-5) which means the W-LUNs
    would start from 0xC100 onwards.
    
    This means max. LUN number reported from UFS device could be 0xC17F hence
    this patch advertise the "max_lun" as 0xC17F which will allow SCSI mid
    layer to detect the W-LUs as well.
    
    But once the W-LUs are detected, UFSHCD driver may get the commands with
    SCSI LUN id upto 0xC17F but UPIU LUN id field is only 8-bit wide so it
    requires the mapping of SCSI LUN id to UPIU LUN id. This patch also add
    support for this mapping.
    
    Signed-off-by: Subhash Jadavani <[email protected]>
    Signed-off-by: Dolev Raviv <[email protected]>
    Signed-off-by: Sujit Reddy Thumma <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>

commit 2a8fa600445c45222632810a4811ce820279d106
Author: Subhash Jadavani <su…
pstglia pushed a commit to pstglia/linux that referenced this pull request Oct 6, 2014
This reverts commit 716fb91.

That commit caused a regression which would end up in a kernel
BUG() as below:

[  101.554300] g_ether gadget: full-speed config #1: CDC Subset/SAFE
[  101.585186] ------------[ cut here ]------------
[  101.600587] kernel BUG at include/linux/netdevice.h:495!
[  101.615850] Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
[  101.645539] Modules linked in:
[  101.660483] CPU: 0 PID: 0 Comm: swapper Not tainted 3.15.0-rc1+ torvalds#104
[  101.690175] task: c05dc5c8 ti: c05d2000 task.ti: c05d2000
[  101.705579] PC is at eth_start+0x64/0x8c
[  101.720981] LR is at __netif_schedule+0x7c/0x90
[  101.736455] pc : [<c0299174>]    lr : [<c036a134>]    psr: 60000093
[  101.736455] sp : c05d3d18  ip : c05d3cf8  fp : c05d3d2c
[  101.782340] r10: 00000000  r9 : c196c1f0  r8 : c196c1a0
[  101.797823] r7 : 00000000  r6 : 00000002  r5 : c1976400  r4 : c1976400
[  101.828058] r3 : 00000000  r2 : c05d3ce8  r1 : 00000001  r0 : 00000002
[  101.858722] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM Segment kernel

Reported-by: Robert Jarzmik <[email protected]>
Signed-of-by: Felipe Balbi <[email protected]>
torvalds pushed a commit that referenced this pull request Nov 7, 2014
If PM_RUNTIME is enabled, it is easy to trigger the following backtrace
on pxa2xx hosts:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104
[<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14)
[<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c)
[<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24)
[<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8)
[<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34)
[<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54)
[<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74)
[<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8)
[<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208)
[<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0)
[<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8)
[<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc)
[<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc)
[<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4)
[<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec)
[<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24)
---[ end trace 46524156d8faa4f6 ]---

This happens because suspend function tries to disable a clock that is
already disabled by runtime_suspend callback. Add if
(!pm_runtime_suspended()) checks to suspend/resume path.

Fixes: 7d94a50 (spi/pxa2xx: add support for runtime PM)
Signed-off-by: Dmitry Eremin-Solenikov <[email protected]>
Reported-by: Andrea Adami <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
dabrace referenced this pull request in dabrace/linux Nov 10, 2014
If PM_RUNTIME is enabled, it is easy to trigger the following backtrace
on pxa2xx hosts:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104
[<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14)
[<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c)
[<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24)
[<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8)
[<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34)
[<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54)
[<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74)
[<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8)
[<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208)
[<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0)
[<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8)
[<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc)
[<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc)
[<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4)
[<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec)
[<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24)
---[ end trace 46524156d8faa4f6 ]---

This happens because suspend function tries to disable a clock that is
already disabled by runtime_suspend callback. Add if
(!pm_runtime_suspended()) checks to suspend/resume path.

Fixes: 7d94a50 (spi/pxa2xx: add support for runtime PM)
Signed-off-by: Dmitry Eremin-Solenikov <[email protected]>
Reported-by: Andrea Adami <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Cc: [email protected]
kernelOfTruth pushed a commit to kernelOfTruth/linux that referenced this pull request Nov 14, 2014
commit 2b9375b upstream.

If PM_RUNTIME is enabled, it is easy to trigger the following backtrace
on pxa2xx hosts:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty torvalds#104
[<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14)
[<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c)
[<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24)
[<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8)
[<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34)
[<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54)
[<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74)
[<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8)
[<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208)
[<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0)
[<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8)
[<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc)
[<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc)
[<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4)
[<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec)
[<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24)
---[ end trace 46524156d8faa4f6 ]---

This happens because suspend function tries to disable a clock that is
already disabled by runtime_suspend callback. Add if
(!pm_runtime_suspended()) checks to suspend/resume path.

Fixes: 7d94a50 (spi/pxa2xx: add support for runtime PM)
Signed-off-by: Dmitry Eremin-Solenikov <[email protected]>
Reported-by: Andrea Adami <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
mdrjr referenced this pull request in hardkernel/linux Nov 21, 2014
commit 2b9375b upstream.

If PM_RUNTIME is enabled, it is easy to trigger the following backtrace
on pxa2xx hosts:

------------[ cut here ]------------
WARNING: CPU: 0 PID: 1 at /home/lumag/linux/arch/arm/mach-pxa/clock.c:35 clk_disable+0xa0/0xa8()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 3.17.0-00007-g1b3d2ee-dirty #104
[<c000de68>] (unwind_backtrace) from [<c000c078>] (show_stack+0x10/0x14)
[<c000c078>] (show_stack) from [<c001d75c>] (warn_slowpath_common+0x6c/0x8c)
[<c001d75c>] (warn_slowpath_common) from [<c001d818>] (warn_slowpath_null+0x1c/0x24)
[<c001d818>] (warn_slowpath_null) from [<c0015e80>] (clk_disable+0xa0/0xa8)
[<c0015e80>] (clk_disable) from [<c02507f8>] (pxa2xx_spi_suspend+0x2c/0x34)
[<c02507f8>] (pxa2xx_spi_suspend) from [<c0200360>] (platform_pm_suspend+0x2c/0x54)
[<c0200360>] (platform_pm_suspend) from [<c0207fec>] (dpm_run_callback.isra.14+0x2c/0x74)
[<c0207fec>] (dpm_run_callback.isra.14) from [<c0209254>] (__device_suspend+0x120/0x2f8)
[<c0209254>] (__device_suspend) from [<c0209a94>] (dpm_suspend+0x50/0x208)
[<c0209a94>] (dpm_suspend) from [<c00455ac>] (suspend_devices_and_enter+0x8c/0x3a0)
[<c00455ac>] (suspend_devices_and_enter) from [<c0045ad4>] (pm_suspend+0x214/0x2a8)
[<c0045ad4>] (pm_suspend) from [<c04b5c34>] (test_suspend+0x14c/0x1dc)
[<c04b5c34>] (test_suspend) from [<c000880c>] (do_one_initcall+0x8c/0x1fc)
[<c000880c>] (do_one_initcall) from [<c04aecfc>] (kernel_init_freeable+0xf4/0x1b4)
[<c04aecfc>] (kernel_init_freeable) from [<c0378078>] (kernel_init+0x8/0xec)
[<c0378078>] (kernel_init) from [<c0009590>] (ret_from_fork+0x14/0x24)
---[ end trace 46524156d8faa4f6 ]---

This happens because suspend function tries to disable a clock that is
already disabled by runtime_suspend callback. Add if
(!pm_runtime_suspended()) checks to suspend/resume path.

Fixes: 7d94a50 (spi/pxa2xx: add support for runtime PM)
Signed-off-by: Dmitry Eremin-Solenikov <[email protected]>
Reported-by: Andrea Adami <[email protected]>
Signed-off-by: Mark Brown <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
sashalevin added a commit to sashalevin/linux-stable-security that referenced this pull request Apr 29, 2016
[ Upstream commit 84768ed ]

l2tp_ip_sendmsg could return without releasing socket lock, making it all the
way to userspace, and generating the following warning:

[  130.891594] ================================================
[  130.894569] [ BUG: lock held when returning to user space! ]
[  130.897257] 3.4.0-rc5-next-20120501-sasha torvalds#104 Tainted: G        W
[  130.900336] ------------------------------------------------
[  130.902996] trinity/8384 is leaving the kernel with locks still held!
[  130.906106] 1 lock held by trinity/8384:
[  130.907924]  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550

Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c").

Signed-off-by: Sasha Levin <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
sashalevin added a commit to sashalevin/linux-stable-security that referenced this pull request Apr 29, 2016
[ Upstream commit 84768ed ]

l2tp_ip_sendmsg could return without releasing socket lock, making it all the
way to userspace, and generating the following warning:

[  130.891594] ================================================
[  130.894569] [ BUG: lock held when returning to user space! ]
[  130.897257] 3.4.0-rc5-next-20120501-sasha torvalds#104 Tainted: G        W
[  130.900336] ------------------------------------------------
[  130.902996] trinity/8384 is leaving the kernel with locks still held!
[  130.906106] 1 lock held by trinity/8384:
[  130.907924]  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550

Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c").

Signed-off-by: Sasha Levin <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
sashalevin added a commit to sashalevin/linux-stable-security that referenced this pull request Apr 29, 2016
[ Upstream commit 84768ed ]

l2tp_ip_sendmsg could return without releasing socket lock, making it all the
way to userspace, and generating the following warning:

[  130.891594] ================================================
[  130.894569] [ BUG: lock held when returning to user space! ]
[  130.897257] 3.4.0-rc5-next-20120501-sasha torvalds#104 Tainted: G        W
[  130.900336] ------------------------------------------------
[  130.902996] trinity/8384 is leaving the kernel with locks still held!
[  130.906106] 1 lock held by trinity/8384:
[  130.907924]  #0:  (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff82b9503f>] l2tp_ip_sendmsg+0x2f/0x550

Introduced by commit 2f16270 ("l2tp: Fix locking in l2tp_ip.c").

Signed-off-by: Sasha Levin <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
Signed-off-by: Ben Hutchings <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jun 4, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a
("bpf: allow bpf programs to tail-call other bpf programs").

bpf_tail_call() arguments:
  ctx   - context pointer passed to next program
  array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY
  index - index inside array that selects specific program to run

In this implementation arm64 JIT jumps into callee program after prologue,
so callee program reuses the same stack. For tail_call_cnt, we use the
callee-saved R26 (which was already saved/restored but previously unused
by JIT).

With this patch a tail call generates the following code on arm64:

  if (index >= array->map.max_entries)
      goto out;

  34:   mov     x10, #0x10                      // torvalds#16
  38:   ldr     w10, [x1,x10]
  3c:   cmp     w2, w10
  40:   b.ge    0x0000000000000074

  if (tail_call_cnt > MAX_TAIL_CALL_CNT)
      goto out;
  tail_call_cnt++;

  44:   mov     x10, #0x20                      // torvalds#32
  48:   cmp     x26, x10
  4c:   b.gt    0x0000000000000074
  50:   add     x26, x26, #0x1

  prog = array->ptrs[index];
  if (prog == NULL)
      goto out;

  54:   mov     x10, #0x68                      // torvalds#104
  58:   ldr     x10, [x1,x10]
  5c:   ldr     x11, [x10,x2]
  60:   cbz     x11, 0x0000000000000074

  goto *(prog->bpf_func + prologue_size);

  64:   mov     x10, #0x20                      // torvalds#32
  68:   ldr     x10, [x11,x10]
  6c:   add     x10, x10, #0x20
  70:   br      x10
  74:

Signed-off-by: Zi Shen Lim <[email protected]>
zlim added a commit to zlim/linux that referenced this pull request Jun 7, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a
("bpf: allow bpf programs to tail-call other bpf programs").

bpf_tail_call() arguments:
  ctx   - context pointer passed to next program
  array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY
  index - index inside array that selects specific program to run

In this implementation arm64 JIT jumps into callee program after prologue,
so callee program reuses the same stack. For tail_call_cnt, we use the
callee-saved R26 (which was already saved/restored but previously unused
by JIT).

With this patch a tail call generates the following code on arm64:

  if (index >= array->map.max_entries)
      goto out;

  34:   mov     x10, #0x10                      // torvalds#16
  38:   ldr     w10, [x1,x10]
  3c:   cmp     w2, w10
  40:   b.ge    0x0000000000000074

  if (tail_call_cnt > MAX_TAIL_CALL_CNT)
      goto out;
  tail_call_cnt++;

  44:   mov     x10, #0x20                      // torvalds#32
  48:   cmp     x26, x10
  4c:   b.gt    0x0000000000000074
  50:   add     x26, x26, #0x1

  prog = array->ptrs[index];
  if (prog == NULL)
      goto out;

  54:   mov     x10, #0x68                      // torvalds#104
  58:   ldr     x10, [x1,x10]
  5c:   ldr     x11, [x10,x2]
  60:   cbz     x11, 0x0000000000000074

  goto *(prog->bpf_func + prologue_size);

  64:   mov     x10, #0x20                      // torvalds#32
  68:   ldr     x10, [x11,x10]
  6c:   add     x10, x10, #0x20
  70:   br      x10
  74:

Signed-off-by: Zi Shen Lim <[email protected]>
zlim added a commit to zlim/linux that referenced this pull request Jun 9, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a
("bpf: allow bpf programs to tail-call other bpf programs").

bpf_tail_call() arguments:
  ctx   - context pointer passed to next program
  array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY
  index - index inside array that selects specific program to run

In this implementation arm64 JIT jumps into callee program after prologue,
so callee program reuses the same stack. For tail_call_cnt, we use the
callee-saved R26 (which was already saved/restored but previously unused
by JIT).

With this patch a tail call generates the following code on arm64:

  if (index >= array->map.max_entries)
      goto out;

  34:   mov     x10, #0x10                      // torvalds#16
  38:   ldr     w10, [x1,x10]
  3c:   cmp     w2, w10
  40:   b.ge    0x0000000000000074

  if (tail_call_cnt > MAX_TAIL_CALL_CNT)
      goto out;
  tail_call_cnt++;

  44:   mov     x10, #0x20                      // torvalds#32
  48:   cmp     x26, x10
  4c:   b.gt    0x0000000000000074
  50:   add     x26, x26, #0x1

  prog = array->ptrs[index];
  if (prog == NULL)
      goto out;

  54:   mov     x10, #0x68                      // torvalds#104
  58:   ldr     x10, [x1,x10]
  5c:   ldr     x11, [x10,x2]
  60:   cbz     x11, 0x0000000000000074

  goto *(prog->bpf_func + prologue_size);

  64:   mov     x10, #0x20                      // torvalds#32
  68:   ldr     x10, [x11,x10]
  6c:   add     x10, x10, #0x20
  70:   br      x10
  74:

Signed-off-by: Zi Shen Lim <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jun 9, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a
("bpf: allow bpf programs to tail-call other bpf programs").

bpf_tail_call() arguments:
  ctx   - context pointer passed to next program
  array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY
  index - index inside array that selects specific program to run

In this implementation arm64 JIT jumps into callee program after prologue,
so callee program reuses the same stack. For tail_call_cnt, we use the
callee-saved R26 (which was already saved/restored but previously unused
by JIT).

With this patch a tail call generates the following code on arm64:

  if (index >= array->map.max_entries)
      goto out;

  34:   mov     x10, #0x10                      // torvalds#16
  38:   ldr     w10, [x1,x10]
  3c:   cmp     w2, w10
  40:   b.ge    0x0000000000000074

  if (tail_call_cnt > MAX_TAIL_CALL_CNT)
      goto out;
  tail_call_cnt++;

  44:   mov     x10, #0x20                      // torvalds#32
  48:   cmp     x26, x10
  4c:   b.gt    0x0000000000000074
  50:   add     x26, x26, #0x1

  prog = array->ptrs[index];
  if (prog == NULL)
      goto out;

  54:   mov     x10, #0x68                      // torvalds#104
  58:   ldr     x10, [x1,x10]
  5c:   ldr     x11, [x10,x2]
  60:   cbz     x11, 0x0000000000000074

  goto *(prog->bpf_func + prologue_size);

  64:   mov     x10, #0x20                      // torvalds#32
  68:   ldr     x10, [x11,x10]
  6c:   add     x10, x10, #0x20
  70:   br      x10
  74:

Signed-off-by: Zi Shen Lim <[email protected]>
0day-ci pushed a commit to 0day-ci/linux that referenced this pull request Jun 11, 2016
Add support for JMP_CALL_X (tail call) introduced by commit 04fd61a
("bpf: allow bpf programs to tail-call other bpf programs").

bpf_tail_call() arguments:
  ctx   - context pointer passed to next program
  array - pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY
  index - index inside array that selects specific program to run

In this implementation arm64 JIT jumps into callee program after prologue,
so callee program reuses the same stack. For tail_call_cnt, we use the
callee-saved R26 (which was already saved/restored but previously unused
by JIT).

With this patch a tail call generates the following code on arm64:

  if (index >= array->map.max_entries)
      goto out;

  34:   mov     x10, #0x10                      // torvalds#16
  38:   ldr     w10, [x1,x10]
  3c:   cmp     w2, w10
  40:   b.ge    0x0000000000000074

  if (tail_call_cnt > MAX_TAIL_CALL_CNT)
      goto out;
  tail_call_cnt++;

  44:   mov     x10, #0x20                      // torvalds#32
  48:   cmp     x26, x10
  4c:   b.gt    0x0000000000000074
  50:   add     x26, x26, #0x1

  prog = array->ptrs[index];
  if (prog == NULL)
      goto out;

  54:   mov     x10, #0x68                      // torvalds#104
  58:   ldr     x10, [x1,x10]
  5c:   ldr     x11, [x10,x2]
  60:   cbz     x11, 0x0000000000000074

  goto *(prog->bpf_func + prologue_size);

  64:   mov     x10, #0x20                      // torvalds#32
  68:   ldr     x10, [x11,x10]
  6c:   add     x10, x10, #0x20
  70:   br      x10
  74:

Signed-off-by: Zi Shen Lim <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
torvalds pushed a commit that referenced this pull request Aug 13, 2016
When nvme_delete_queue fails in the first pass of the
nvme_disable_io_queues() loop, we return early, failing to suspend all
of the IO queues.  Later, on the nvme_pci_disable path, this causes us
to disable MSI without actually having freed all the IRQs, which
triggers the BUG_ON in free_msi_irqs(), as show below.

This patch refactors nvme_disable_io_queues to suspend all queues before
start submitting delete queue commands.  This way, we ensure that we
have at least returned every IRQ before continuing with the removal
path.

[  487.529200] kernel BUG at ../drivers/pci/msi.c:368!
cpu 0x46: Vector: 700 (Program Check) at [c0000078c5b83650]
    pc: c000000000627a50: free_msi_irqs+0x90/0x200
    lr: c000000000627a40: free_msi_irqs+0x80/0x200
    sp: c0000078c5b838d0
   msr: 9000000100029033
  current = 0xc0000078c5b40000
  paca    = 0xc000000002bd7600   softe: 0        irq_happened: 0x01
    pid   = 1376, comm = kworker/70:1H
kernel BUG at ../drivers/pci/msi.c:368!
Linux version 4.7.0.mainline+ (root@iod76) (gcc version 5.3.1 20160413
(Ubuntu/IBM 5.3.1-14ubuntu2.1) ) #104 SMP Fri Jul 29 09:20:17 CDT 2016
enter ? for help
[c0000078c5b83920] d0000000363b0cd8 nvme_dev_disable+0x208/0x4f0 [nvme]
[c0000078c5b83a10] d0000000363b12a4 nvme_timeout+0xe4/0x250 [nvme]
[c0000078c5b83ad0] c0000000005690e4 blk_mq_rq_timed_out+0x64/0x110
[c0000078c5b83b40] c00000000056c930 bt_for_each+0x160/0x170
[c0000078c5b83bb0] c00000000056d928 blk_mq_queue_tag_busy_iter+0x78/0x110
[c0000078c5b83c00] c0000000005675d8 blk_mq_timeout_work+0xd8/0x1b0
[c0000078c5b83c50] c0000000000e8cf0 process_one_work+0x1e0/0x590
[c0000078c5b83ce0] c0000000000e9148 worker_thread+0xa8/0x660
[c0000078c5b83d80] c0000000000f2090 kthread+0x110/0x130
[c0000078c5b83e30] c0000000000095f0 ret_from_kernel_thread+0x5c/0x6c

Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
Cc: Brian King <[email protected]>
Cc: Keith Busch <[email protected]>
Cc: [email protected]
Signed-off-by: Jens Axboe <[email protected]>
bgly pushed a commit to powervm/ibmvscsis that referenced this pull request Nov 2, 2016
BugLink: http://bugs.launchpad.net/bugs/1602724

When nvme_delete_queue fails in the first pass of the
nvme_disable_io_queues() loop, we return early, failing to suspend all
of the IO queues.  Later, on the nvme_pci_disable path, this causes us
to disable MSI without actually having freed all the IRQs, which
triggers the BUG_ON in free_msi_irqs(), as show below.

This patch refactors nvme_disable_io_queues to suspend all queues before
start submitting delete queue commands.  This way, we ensure that we
have at least returned every IRQ before continuing with the removal
path.

[  487.529200] kernel BUG at ../drivers/pci/msi.c:368!
cpu 0x46: Vector: 700 (Program Check) at [c0000078c5b83650]
    pc: c000000000627a50: free_msi_irqs+0x90/0x200
    lr: c000000000627a40: free_msi_irqs+0x80/0x200
    sp: c0000078c5b838d0
   msr: 9000000100029033
  current = 0xc0000078c5b40000
  paca    = 0xc000000002bd7600   softe: 0        irq_happened: 0x01
    pid   = 1376, comm = kworker/70:1H
kernel BUG at ../drivers/pci/msi.c:368!
Linux version 4.7.0.mainline+ (root@iod76) (gcc version 5.3.1 20160413
(Ubuntu/IBM 5.3.1-14ubuntu2.1) ) torvalds#104 SMP Fri Jul 29 09:20:17 CDT 2016
enter ? for help
[c0000078c5b83920] d0000000363b0cd8 nvme_dev_disable+0x208/0x4f0 [nvme]
[c0000078c5b83a10] d0000000363b12a4 nvme_timeout+0xe4/0x250 [nvme]
[c0000078c5b83ad0] c0000000005690e4 blk_mq_rq_timed_out+0x64/0x110
[c0000078c5b83b40] c00000000056c930 bt_for_each+0x160/0x170
[c0000078c5b83bb0] c00000000056d928 blk_mq_queue_tag_busy_iter+0x78/0x110
[c0000078c5b83c00] c0000000005675d8 blk_mq_timeout_work+0xd8/0x1b0
[c0000078c5b83c50] c0000000000e8cf0 process_one_work+0x1e0/0x590
[c0000078c5b83ce0] c0000000000e9148 worker_thread+0xa8/0x660
[c0000078c5b83d80] c0000000000f2090 kthread+0x110/0x130
[c0000078c5b83e30] c0000000000095f0 ret_from_kernel_thread+0x5c/0x6c

Signed-off-by: Gabriel Krisman Bertazi <[email protected]>
Cc: Brian King <[email protected]>
Cc: Keith Busch <[email protected]>
Cc: [email protected]
Signed-off-by: Jens Axboe <[email protected]>
(cherry picked from commit c21377f)
Signed-off-by: Tim Gardner <[email protected]>
Acked-by: Stefan Bader <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
laijs pushed a commit to laijs/linux that referenced this pull request Feb 13, 2017
lkl: Don't specify different compiler/linker flags for elf32-littlearm.
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Apr 22, 2017
systemd-sysctl is triggering a suspicious RCU usage message when
net.ipv4.tcp_early_demux or net.ipv4.udp_early_demux is changed via
a sysctl config file:

[   33.896184] ===============================
[   33.899558] [ ERR: suspicious RCU usage.  ]
[   33.900624] 4.11.0-rc7+ torvalds#104 Not tainted
[   33.901698] -------------------------------
[   33.903059] /home/dsa/kernel-2.git/net/ipv4/sysctl_net_ipv4.c:305 suspicious rcu_dereference_check() usage!
[   33.905724]
other info that might help us debug this:

[   33.907656]
rcu_scheduler_active = 2, debug_locks = 0
[   33.909288] 1 lock held by systemd-sysctl/143:
[   33.910373]  #0:  (sb_writers#5){.+.+.+}, at: [<ffffffff8123a370>] file_start_write+0x45/0x48
[   33.912407]
stack backtrace:
[   33.914018] CPU: 0 PID: 143 Comm: systemd-sysctl Not tainted 4.11.0-rc7+ torvalds#104
[   33.915631] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
[   33.917870] Call Trace:
[   33.918431]  dump_stack+0x81/0xb6
[   33.919241]  lockdep_rcu_suspicious+0x10f/0x118
[   33.920263]  proc_configure_early_demux+0x65/0x10a
[   33.921391]  proc_udp_early_demux+0x3a/0x41

add rcu locking to proc_configure_early_demux.

Fixes: dddb64b ("net: Add sysctl to toggle early demux for tcp and udp")
Signed-off-by: David Ahern <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jan 21, 2018
GIT dda3e15231b35840fe6f0973f803cc70ddb86281

commit b0f2853b56a2acaff19cca2c6a608f8ec268d21a
Author: Christoph Hellwig <[email protected]>
Date:   Wed Jan 17 22:04:38 2018 +0100

    nvme-pci: take sglist coalescing in dma_map_sg into account
    
    Some iommu implementations can merge physically and/or virtually
    contiguous segments inside sg_map_dma.  The NVMe SGL support does not take
    this into account and will warn because of falling off a loop.  Pass the
    number of mapped segments to nvme_pci_setup_sgls so that the SGL setup
    can take the number of mapped segments into account.
    
    Reported-by: Fangjian (Turing) <[email protected]>
    Fixes: a7a7cbe3 ("nvme-pci: add SGL support")
    Signed-off-by: Christoph Hellwig <[email protected]>
    Reviewed-by: Keith Busch <[email protected]>
    Reviewed-by: Sagi Grimberg <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 20469a37aed12a886d0deda5a07c04037923144a
Author: Keith Busch <[email protected]>
Date:   Wed Jan 17 22:04:37 2018 +0100

    nvme-pci: check segement valid for SGL use
    
    The driver needs to verify there is a payload with a command before
    seeing if it should use SGLs to map it.
    
    Fixes: 955b1b5a00ba ("nvme-pci: move use_sgl initialization to nvme_init_iod()")
    Reported-by: Paul Menzel <[email protected]>
    Reviewed-by: Paul Menzel <[email protected]>
    Signed-off-by: Keith Busch <[email protected]>
    Signed-off-by: Christoph Hellwig <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 091f02483df7b56615b524491f404e574c5e0668
Author: Russell King <[email protected]>
Date:   Sat Jan 13 12:11:26 2018 +0000

    ARM: net: bpf: clarify tail_call index
    
    As per 90caccdd8cc0 ("bpf: fix bpf_tail_call() x64 JIT"), the index used
    for array lookup is defined to be 32-bit wide. Update a misleading
    comment that suggests it is 64-bit wide.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit ec19e02b343db991d2d1610c409efefebf4e2ca9
Author: Russell King <[email protected]>
Date:   Sat Jan 13 21:06:16 2018 +0000

    ARM: net: bpf: fix LDX instructions
    
    When the source and destination register are identical, our JIT does not
    generate correct code, which leads to kernel oopses.
    
    Fix this by (a) generating more efficient code, and (b) making use of
    the temporary earlier if we will overwrite the address register.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit 02088d9b392f605c892894b46aa8c83e3abd0115
Author: Russell King <[email protected]>
Date:   Sat Jan 13 22:38:18 2018 +0000

    ARM: net: bpf: fix register saving
    
    When an eBPF program tail-calls another eBPF program, it enters it after
    the prologue to avoid having complex stack manipulations.  This can lead
    to kernel oopses, and similar.
    
    Resolve this by always using a fixed stack layout, a CPU register frame
    pointer, and using this when reloading registers before returning.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit 0005e55a79cfda88199e41a406a829c88d708c67
Author: Russell King <[email protected]>
Date:   Sat Jan 13 22:51:27 2018 +0000

    ARM: net: bpf: correct stack layout documentation
    
    The stack layout documentation incorrectly suggests that the BPF JIT
    scratch space starts immediately below BPF_FP. This is not correct,
    so let's fix the documentation to reflect reality.
    
    Signed-off-by: Russell King <[email protected]>

commit 70ec3a6c2c11e4b0e107a65de943a082f9aff351
Author: Russell King <[email protected]>
Date:   Sat Jan 13 21:26:14 2018 +0000

    ARM: net: bpf: move stack documentation
    
    Move the stack documentation towards the top of the file, where it's
    relevant for things like the register layout.
    
    Signed-off-by: Russell King <[email protected]>

commit d1220efd23484c72c82d5471f05daeb35b5d1916
Author: Russell King <[email protected]>
Date:   Sat Jan 13 16:10:07 2018 +0000

    ARM: net: bpf: fix stack alignment
    
    As per 2dede2d8e925 ("ARM EABI: stack pointer must be 64-bit aligned
    after a CPU exception") the stack should be aligned to a 64-bit boundary
    on EABI systems.  Ensure that the eBPF JIT appropraitely aligns the
    stack.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit f4483f2cc1fdc03488c8a1452e545545ae5bda93
Author: Russell King <[email protected]>
Date:   Sat Jan 13 11:39:54 2018 +0000

    ARM: net: bpf: fix tail call jumps
    
    When a tail call fails, it is documented that the tail call should
    continue execution at the following instruction.  An example tail call
    sequence is:
    
      12: (85) call bpf_tail_call#12
      13: (b7) r0 = 0
      14: (95) exit
    
    The ARM assembler for the tail call in this case ends up branching to
    instruction 14 instead of instruction 13, resulting in the BPF filter
    returning a non-zero value:
    
      178:  ldr     r8, [sp, #588]  ; insn 12
      17c:  ldr     r6, [r8, r6]
      180:  ldr     r8, [sp, #580]
      184:  cmp     r8, r6
      188:  bcs     0x1e8
      18c:  ldr     r6, [sp, #524]
      190:  ldr     r7, [sp, #528]
      194:  cmp     r7, #0
      198:  cmpeq   r6, #32
      19c:  bhi     0x1e8
      1a0:  adds    r6, r6, #1
      1a4:  adc     r7, r7, #0
      1a8:  str     r6, [sp, #524]
      1ac:  str     r7, [sp, #528]
      1b0:  mov     r6, #104
      1b4:  ldr     r8, [sp, #588]
      1b8:  add     r6, r8, r6
      1bc:  ldr     r8, [sp, #580]
      1c0:  lsl     r7, r8, #2
      1c4:  ldr     r6, [r6, r7]
      1c8:  cmp     r6, #0
      1cc:  beq     0x1e8
      1d0:  mov     r8, #32
      1d4:  ldr     r6, [r6, r8]
      1d8:  add     r6, r6, #44
      1dc:  bx      r6
      1e0:  mov     r0, #0          ; insn 13
      1e4:  mov     r1, #0
      1e8:  add     sp, sp, #596    ; insn 14
      1ec:  pop     {r4, r5, r6, r7, r8, sl, pc}
    
    For other sequences, the tail call could end up branching midway through
    the following BPF instructions, or maybe off the end of the function,
    leading to unknown behaviours.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit e9062481824384f00299971f923fecf6b3668001
Author: Russell King <[email protected]>
Date:   Sat Jan 13 11:35:15 2018 +0000

    ARM: net: bpf: avoid 'bx' instruction on non-Thumb capable CPUs
    
    Avoid the 'bx' instruction on CPUs that have no support for Thumb and
    thus do not implement this instruction by moving the generation of this
    opcode to a separate function that selects between:
    
            bx      reg
    
    and
    
            mov     pc, reg
    
    according to the capabilities of the CPU.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit 45d55e7bac4028af93f5fa324e69958a0b868e96
Author: Thomas Gleixner <[email protected]>
Date:   Tue Jan 16 12:20:18 2018 +0100

    x86/apic/vector: Fix off by one in error path
    
    Keith reported the following warning:
    
    WARNING: CPU: 28 PID: 1420 at kernel/irq/matrix.c:222 irq_matrix_remove_managed+0x10f/0x120
      x86_vector_free_irqs+0xa1/0x180
      x86_vector_alloc_irqs+0x1e4/0x3a0
      msi_domain_alloc+0x62/0x130
    
    The reason for this is that if the vector allocation fails the error
    handling code tries to free the failed vector as well, which causes the
    above imbalance warning to trigger.
    
    Adjust the error path to handle this correctly.
    
    Fixes: b5dc8e6c21e7 ("x86/irq: Use hierarchical irqdomain to manage CPU interrupt vectors")
    Reported-by: Keith Busch <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Tested-by: Keith Busch <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161217300.1823@nanos

commit d47924417319e3b6a728c0b690f183e75bc2a702
Author: Thomas Gleixner <[email protected]>
Date:   Tue Jan 16 19:59:59 2018 +0100

    x86/intel_rdt/cqm: Prevent use after free
    
    intel_rdt_iffline_cpu() -> domain_remove_cpu() frees memory first and then
    proceeds accessing it.
    
     BUG: KASAN: use-after-free in find_first_bit+0x1f/0x80
     Read of size 8 at addr ffff883ff7c1e780 by task cpuhp/31/195
     find_first_bit+0x1f/0x80
     has_busy_rmid+0x47/0x70
     intel_rdt_offline_cpu+0x4b4/0x510
    
     Freed by task 195:
     kfree+0x94/0x1a0
     intel_rdt_offline_cpu+0x17d/0x510
    
    Do the teardown first and then free memory.
    
    Fixes: 24247aeeabe9 ("x86/intel_rdt/cqm: Improve limbo list processing")
    Reported-by: Joseph Salisbury <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Cc: Ravi Shankar <[email protected]>
    Cc: Peter Zilstra <[email protected]>
    Cc: Stephane Eranian <[email protected]>
    Cc: Vikas Shivappa <[email protected]>
    Cc: Andi Kleen <[email protected]>
    Cc: "Roderick W. Smith" <[email protected]>
    Cc: [email protected]
    Cc: Fenghua Yu <[email protected]>
    Cc: Tony Luck <[email protected]>
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801161957510.2366@nanos

commit 6cfb521ac0d5b97470883ff9b7facae264b7ab12
Author: Andi Kleen <[email protected]>
Date:   Tue Jan 16 12:52:28 2018 -0800

    module: Add retpoline tag to VERMAGIC
    
    Add a marker for retpoline to the module VERMAGIC. This catches the case
    when a non RETPOLINE compiled module gets loaded into a retpoline kernel,
    making it insecure.
    
    It doesn't handle the case when retpoline has been runtime disabled.  Even
    in this case the match of the retcompile status will be enforced.  This
    implies that even with retpoline run time disabled all modules loaded need
    to be recompiled.
    
    Signed-off-by: Andi Kleen <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Greg Kroah-Hartman <[email protected]>
    Acked-by: David Woodhouse <[email protected]>
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Cc: [email protected]
    Link: https://lkml.kernel.org/r/[email protected]

commit 4fdec2034b7540dda461c6ba33325dfcff345c64
Author: Paolo Bonzini <[email protected]>
Date:   Tue Jan 16 16:42:25 2018 +0100

    x86/cpufeature: Move processor tracing out of scattered features
    
    Processor tracing is already enumerated in word 9 (CPUID[7,0].EBX),
    so do not duplicate it in the scattered features word.
    
    Besides being more tidy, this will be useful for KVM when it presents
    processor tracing to the guests.  KVM selects host features that are
    supported by both the host kernel (depending on command line options,
    CPU errata, or whatever) and KVM.  Whenever a full feature word exists,
    KVM's code is written in the expectation that the CPUID bit number
    matches the X86_FEATURE_* bit number, but this is not the case for
    X86_FEATURE_INTEL_PT.
    
    Signed-off-by: Paolo Bonzini <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Luwei Kang <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Radim Krčmář <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ingo Molnar <[email protected]>

commit 07c7b6a52503ac13ae357a8b3ef3456590a64b65
Author: Linus Walleij <[email protected]>
Date:   Tue Jan 16 09:51:51 2018 +0100

    gpio: mmio: Also read bits that are zero
    
    The code for .get_multiple() has bugs:
    
    1. The simple .get_multiple() just reads a register, masks it
    and sets the return value. This is not correct: we only want to
    assign values (whether 0 or 1) to the bits that are set in the
    mask. Fix this by using &= ~mask to clear all bits in the mask
    and then |= val & mask to set the corresponding bits from the
    read.
    
    2. The bgpio_get_multiple_be() call has a similar problem: it
    uses the |= operator to set the bits, so only the bits in the
    mask are affected, but it misses to clear all returned bits
    from the mask initially, so some bits will be returned
    erroneously set to 1.
    
    3. The bgpio_get_set_multiple() again fails to clear the bits
    from the mask.
    
    4. find_next_bit() wasn't handled correctly, use a totally
    different approach for one function and change the other
    function to follow the design pattern of assigning the first
    bit to -1, then use bit + 1 in the for loop and < num_iterations
    as break condition.
    
    Fixes: 80057cb417b2 ("gpio-mmio: Use the new .get_multiple() callback")
    Cc: Bartosz Golaszewski <[email protected]>
    Reported-by: Clemens Gruber <[email protected]>
    Tested-by: Clemens Gruber <[email protected]>
    Reported-by: Lukas Wunner <[email protected]>
    Signed-off-by: Linus Walleij <[email protected]>

commit 81d947e2b8dd2394586c3eaffdd2357797d3bf59
Author: Daniel Borkmann <[email protected]>
Date:   Mon Jan 15 23:12:09 2018 +0100

    net, sched: fix panic when updating miniq {b,q}stats
    
    While working on fixing another bug, I ran into the following panic
    on arm64 by simply attaching clsact qdisc, adding a filter and running
    traffic on ingress to it:
    
      [...]
      [  178.188591] Unable to handle kernel read from unreadable memory at virtual address 810fb501f000
      [  178.197314] Mem abort info:
      [  178.200121]   ESR = 0x96000004
      [  178.203168]   Exception class = DABT (current EL), IL = 32 bits
      [  178.209095]   SET = 0, FnV = 0
      [  178.212157]   EA = 0, S1PTW = 0
      [  178.215288] Data abort info:
      [  178.218175]   ISV = 0, ISS = 0x00000004
      [  178.222019]   CM = 0, WnR = 0
      [  178.224997] user pgtable: 4k pages, 48-bit VAs, pgd = 0000000023cb3f33
      [  178.231531] [0000810fb501f000] *pgd=0000000000000000
      [  178.236508] Internal error: Oops: 96000004 [#1] SMP
      [...]
      [  178.311855] CPU: 73 PID: 2497 Comm: ping Tainted: G        W        4.15.0-rc7+ #5
      [  178.319413] Hardware name: FOXCONN R2-1221R-A4/C2U4N_MB, BIOS G31FB18A 03/31/2017
      [  178.326887] pstate: 60400005 (nZCv daif +PAN -UAO)
      [  178.331685] pc : __netif_receive_skb_core+0x49c/0xac8
      [  178.336728] lr : __netif_receive_skb+0x28/0x78
      [  178.341161] sp : ffff00002344b750
      [  178.344465] x29: ffff00002344b750 x28: ffff810fbdfd0580
      [  178.349769] x27: 0000000000000000 x26: ffff000009378000
      [...]
      [  178.418715] x1 : 0000000000000054 x0 : 0000000000000000
      [  178.424020] Process ping (pid: 2497, stack limit = 0x000000009f0a3ff4)
      [  178.430537] Call trace:
      [  178.432976]  __netif_receive_skb_core+0x49c/0xac8
      [  178.437670]  __netif_receive_skb+0x28/0x78
      [  178.441757]  process_backlog+0x9c/0x160
      [  178.445584]  net_rx_action+0x2f8/0x3f0
      [...]
    
    Reason is that sch_ingress and sch_clsact are doing mini_qdisc_pair_init()
    which sets up miniq pointers to cpu_{b,q}stats from the underlying qdisc.
    Problem is that this cannot work since they are actually set up right after
    the qdisc ->init() callback in qdisc_create(), so first packet going into
    sch_handle_ingress() tries to call mini_qdisc_bstats_cpu_update() and we
    therefore panic.
    
    In order to fix this, allocation of {b,q}stats needs to happen before we
    call into ->init(). In net-next, there's already such option through commit
    d59f5ffa59d8 ("net: sched: a dflt qdisc may be used with per cpu stats").
    However, the bug needs to be fixed in net still for 4.15. Thus, include
    these bits to reduce any merge churn and reuse the static_flags field to
    set TCQ_F_CPUSTATS, and remove the allocation from qdisc_create() since
    there is no other user left. Prashant Bhole ran into the same issue but
    for net-next, thus adding him below as well as co-author. Same issue was
    also reported by Sandipan Das when using bcc.
    
    Fixes: 46209401f8f6 ("net: core: introduce mini_Qdisc and eliminate usage of tp->q for clsact fastpath")
    Reference: https://lists.iovisor.org/pipermail/iovisor-dev/2018-January/001190.html
    Reported-by: Sandipan Das <[email protected]>
    Co-authored-by: Prashant Bhole <[email protected]>
    Co-authored-by: John Fastabend <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>
    Cc: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 70eeff66c4696cee4076d6388b6bede5bd7ff71c
Author: Roland Dreier <[email protected]>
Date:   Mon Jan 15 12:24:49 2018 -0800

    qed: Fix potential use-after-free in qed_spq_post()
    
    We need to check if p_ent->comp_mode is QED_SPQ_MODE_EBLOCK before
    calling qed_spq_add_entry().  The test is fine is the mode is EBLOCK,
    but if it isn't then qed_spq_add_entry() might kfree(p_ent).
    
    Signed-off-by: Roland Dreier <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0d9c9f0f40ca262b67fc06a702b85f3976f5e1a1
Author: Jakub Kicinski <[email protected]>
Date:   Mon Jan 15 11:47:53 2018 -0800

    nfp: use the correct index for link speed table
    
    sts variable is holding link speed as well as state.  We should
    be using ls to index into ls_to_ethtool.
    
    Fixes: 265aeb511bd5 ("nfp: add support for .get_link_ksettings()")
    Signed-off-by: Jakub Kicinski <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a5b1379afbfabf91e3a689e82ac619a7157336b3
Author: Yuiko Oshino <[email protected]>
Date:   Mon Jan 15 13:24:28 2018 -0500

    lan78xx: Fix failure in USB Full Speed
    
    Fix initialize the uninitialized tx_qlen to an appropriate value when USB
    Full Speed is used.
    
    Fixes: 55d7de9de6c3 ("Microchip's LAN7800 family USB 2/3 to 10/100/1000 Ethernet device driver")
    Signed-off-by: Yuiko Oshino <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit c5006b8aa74599ce19104b31d322d2ea9ff887cc
Author: Xin Long <[email protected]>
Date:   Mon Jan 15 17:02:00 2018 +0800

    sctp: do not allow the v4 socket to bind a v4mapped v6 address
    
    The check in sctp_sockaddr_af is not robust enough to forbid binding a
    v4mapped v6 addr on a v4 socket.
    
    The worse thing is that v4 socket's bind_verify would not convert this
    v4mapped v6 addr to a v4 addr. syzbot even reported a crash as the v4
    socket bound a v6 addr.
    
    This patch is to fix it by doing the common sa.sa_family check first,
    then AF_INET check for v4mapped v6 addrs.
    
    Fixes: 7dab83de50c7 ("sctp: Support ipv6only AF_INET6 sockets.")
    Reported-by: [email protected]
    Acked-by: Neil Horman <[email protected]>
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a0ff660058b88d12625a783ce9e5c1371c87951f
Author: Xin Long <[email protected]>
Date:   Mon Jan 15 17:01:36 2018 +0800

    sctp: return error if the asoc has been peeled off in sctp_wait_for_sndbuf
    
    After commit cea0cc80a677 ("sctp: use the right sk after waking up from
    wait_buf sleep"), it may change to lock another sk if the asoc has been
    peeled off in sctp_wait_for_sndbuf.
    
    However, the asoc's new sk could be already closed elsewhere, as it's in
    the sendmsg context of the old sk that can't avoid the new sk's closing.
    If the sk's last one refcnt is held by this asoc, later on after putting
    this asoc, the new sk will be freed, while under it's own lock.
    
    This patch is to revert that commit, but fix the old issue by returning
    error under the old sk's lock.
    
    Fixes: cea0cc80a677 ("sctp: use the right sk after waking up from wait_buf sleep")
    Reported-by: [email protected]
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Neil Horman <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 625637bf4afa45204bd87e4218645182a919485a
Author: Xin Long <[email protected]>
Date:   Mon Jan 15 17:01:19 2018 +0800

    sctp: reinit stream if stream outcnt has been change by sinit in sendmsg
    
    After introducing sctp_stream structure, sctp uses stream->outcnt as the
    out stream nums instead of c.sinit_num_ostreams.
    
    However when users use sinit in cmsg, it only updates c.sinit_num_ostreams
    in sctp_sendmsg. At that moment, stream->outcnt is still using previous
    value. If it's value is not updated, the sinit_num_ostreams of sinit could
    not really work.
    
    This patch is to fix it by updating stream->outcnt and reiniting stream
    if stream outcnt has been change by sinit in sendmsg.
    
    Fixes: a83863174a61 ("sctp: prepare asoc stream for stream reconf")
    Signed-off-by: Xin Long <[email protected]>
    Acked-by: Neil Horman <[email protected]>
    Acked-by: Marcelo Ricardo Leitner <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 3d1661304f0b2b51a8a43785b764822611dbdd53
Author: Thomas Falcon <[email protected]>
Date:   Wed Jan 10 19:39:52 2018 -0600

    ibmvnic: Fix pending MAC address changes
    
    Due to architecture limitations, the IBM VNIC client driver is unable
    to perform MAC address changes unless the device has "logged in" to
    its backing device. Currently, pending MAC changes are handled before
    login, resulting in an error and failure to change the MAC address.
    Moving that chunk to the end of the ibmvnic_login function, when we are
    sure that it was successful, fixes that.
    
    The MAC address can be changed when the device is up or down, so
    only check if the device is in a "PROBED" state before setting the
    MAC address.
    
    Fixes: c26eba03e407 ("ibmvnic: Update reset infrastructure to support tunable parameters")
    Signed-off-by: Thomas Falcon <[email protected]>
    Reviewed-by: John Allen <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit c96f5471ce7d2aefd0dda560cc23f08ab00bc65d
Author: Josh Snyder <[email protected]>
Date:   Mon Dec 18 16:15:10 2017 +0000

    delayacct: Account blkio completion on the correct task
    
    Before commit:
    
      e33a9bba85a8 ("sched/core: move IO scheduling accounting from io_schedule_timeout() into scheduler")
    
    delayacct_blkio_end() was called after context-switching into the task which
    completed I/O.
    
    This resulted in double counting: the task would account a delay both waiting
    for I/O and for time spent in the runqueue.
    
    With e33a9bba85a8, delayacct_blkio_end() is called by try_to_wake_up().
    In ttwu, we have not yet context-switched. This is more correct, in that
    the delay accounting ends when the I/O is complete.
    
    But delayacct_blkio_end() relies on 'get_current()', and we have not yet
    context-switched into the task whose I/O completed. This results in the
    wrong task having its delay accounting statistics updated.
    
    Instead of doing that, pass the task_struct being woken to delayacct_blkio_end(),
    so that it can update the statistics of the correct task.
    
    Signed-off-by: Josh Snyder <[email protected]>
    Acked-by: Tejun Heo <[email protected]>
    Acked-by: Balbir Singh <[email protected]>
    Cc: <[email protected]>
    Cc: Brendan Gregg <[email protected]>
    Cc: Jens Axboe <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Cc: [email protected]
    Fixes: e33a9bba85a8 ("sched/core: move IO scheduling accounting from io_schedule_timeout() into scheduler")
    Link: http://lkml.kernel.org/r/[email protected]
    Signed-off-by: Ingo Molnar <[email protected]>

commit 107cd2532181b96c549e8f224cdcca8631c3076b
Author: Tom Lendacky <[email protected]>
Date:   Wed Jan 10 13:26:34 2018 -0600

    x86/mm: Encrypt the initrd earlier for BSP microcode update
    
    Currently the BSP microcode update code examines the initrd very early
    in the boot process.  If SME is active, the initrd is treated as being
    encrypted but it has not been encrypted (in place) yet.  Update the
    early boot code that encrypts the kernel to also encrypt the initrd so
    that early BSP microcode updates work.
    
    Tested-by: Gabriel Craciunescu <[email protected]>
    Signed-off-by: Tom Lendacky <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: Linus Torvalds <[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]>

commit cc5f01e28d6c60f274fd1e33b245f679f79f543c
Author: Tom Lendacky <[email protected]>
Date:   Wed Jan 10 13:26:26 2018 -0600

    x86/mm: Prepare sme_encrypt_kernel() for PAGE aligned encryption
    
    In preparation for encrypting more than just the kernel, the encryption
    support in sme_encrypt_kernel() needs to support 4KB page aligned
    encryption instead of just 2MB large page aligned encryption.
    
    Update the routines that populate the PGD to support non-2MB aligned
    addresses.  This is done by creating PTE page tables for the start
    and end portion of the address range that fall outside of the 2MB
    alignment.  This results in, at most, two extra pages to hold the
    PTE entries for each mapping of a range.
    
    Tested-by: Gabriel Craciunescu <[email protected]>
    Signed-off-by: Tom Lendacky <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: Linus Torvalds <[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]>

commit 2b5d00b6c2cdd94f6d6a494a6f6c0c0fc7b8e711
Author: Tom Lendacky <[email protected]>
Date:   Wed Jan 10 13:26:16 2018 -0600

    x86/mm: Centralize PMD flags in sme_encrypt_kernel()
    
    In preparation for encrypting more than just the kernel during early
    boot processing, centralize the use of the PMD flag settings based
    on the type of mapping desired.  When 4KB aligned encryption is added,
    this will allow either PTE flags or large page PMD flags to be used
    without requiring the caller to adjust.
    
    Tested-by: Gabriel Craciunescu <[email protected]>
    Signed-off-by: Tom Lendacky <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: Linus Torvalds <[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]>

commit bacf6b499e11760aef73a3bb5ce4e5eea74a3fd4
Author: Tom Lendacky <[email protected]>
Date:   Wed Jan 10 13:26:05 2018 -0600

    x86/mm: Use a struct to reduce parameters for SME PGD mapping
    
    In preparation for follow-on patches, combine the PGD mapping parameters
    into a struct to reduce the number of function arguments and allow for
    direct updating of the next pagetable mapping area pointer.
    
    Tested-by: Gabriel Craciunescu <[email protected]>
    Signed-off-by: Tom Lendacky <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: Linus Torvalds <[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]>

commit 1303880179e67c59e801429b7e5d0f6b21137d99
Author: Tom Lendacky <[email protected]>
Date:   Wed Jan 10 13:25:56 2018 -0600

    x86/mm: Clean up register saving in the __enc_copy() assembly code
    
    Clean up the use of PUSH and POP and when registers are saved in the
    __enc_copy() assembly function in order to improve the readability of the code.
    
    Move parameter register saving into general purpose registers earlier
    in the code and move all the pushes to the beginning of the function
    with corresponding pops at the end.
    
    We do this to prepare fixes.
    
    Tested-by: Gabriel Craciunescu <[email protected]>
    Signed-off-by: Tom Lendacky <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Cc: Borislav Petkov <[email protected]>
    Cc: Brijesh Singh <[email protected]>
    Cc: Linus Torvalds <[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]>

commit 385d11b152c4eb638eeb769edcb3249533bb9a00
Author: Josh Poimboeuf <[email protected]>
Date:   Mon Jan 15 08:17:08 2018 -0600

    objtool: Improve error message for bad file argument
    
    If a nonexistent file is supplied to objtool, it complains with a
    non-helpful error:
    
      open: No such file or directory
    
    Improve it to:
    
      objtool: Can't open 'foo': No such file or directory
    
    Reported-by: Markus <[email protected]>
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Link: http://lkml.kernel.org/r/406a3d00a21225eee2819844048e17f68523ccf6.1516025651.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar <[email protected]>

commit 2a0098d70640dda192a79966c14d449e7a34d675
Author: Josh Poimboeuf <[email protected]>
Date:   Mon Jan 15 08:17:07 2018 -0600

    objtool: Fix seg fault with gold linker
    
    Objtool segfaults when the gold linker is used with
    CONFIG_MODVERSIONS=y and CONFIG_UNWINDER_ORC=y.
    
    With CONFIG_MODVERSIONS=y, the .o file gets passed to the linker before
    being passed to objtool.  The gold linker seems to strip unused ELF
    symbols by default, which confuses objtool and causes the seg fault when
    it's trying to generate ORC metadata.
    
    Objtool should really be running immediately after GCC anyway, without a
    linker call in between.  Change the makefile ordering so that objtool is
    called before the linker.
    
    Reported-and-tested-by: Markus <[email protected]>
    Signed-off-by: Josh Poimboeuf <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Thomas Gleixner <[email protected]>
    Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder")
    Link: http://lkml.kernel.org/r/355f04da33581f4a3bf82e5b512973624a1e23a2.1516025651.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar <[email protected]>

commit ae59c3f0b6cfd472fed96e50548a799b8971d876
Author: Leon Romanovsky <[email protected]>
Date:   Fri Jan 12 07:58:39 2018 +0200

    RDMA/mlx5: Fix out-of-bound access while querying AH
    
    The rdma_ah_find_type() accesses the port array based on an index
    controlled by userspace. The existing bounds check is after the first use
    of the index, so userspace can generate an out of bounds access, as shown
    by the KASN report below.
    
    ==================================================================
    BUG: KASAN: slab-out-of-bounds in to_rdma_ah_attr+0xa8/0x3b0
    Read of size 4 at addr ffff880019ae2268 by task ibv_rc_pingpong/409
    
    CPU: 0 PID: 409 Comm: ibv_rc_pingpong Not tainted 4.15.0-rc2-00031-gb60a3faf5b83-dirty #3
    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
    Call Trace:
     dump_stack+0xe9/0x18f
     print_address_description+0xa2/0x350
     kasan_report+0x3a5/0x400
     to_rdma_ah_attr+0xa8/0x3b0
     mlx5_ib_query_qp+0xd35/0x1330
     ib_query_qp+0x8a/0xb0
     ib_uverbs_query_qp+0x237/0x7f0
     ib_uverbs_write+0x617/0xd80
     __vfs_write+0xf7/0x500
     vfs_write+0x149/0x310
     SyS_write+0xca/0x190
     entry_SYSCALL_64_fastpath+0x18/0x85
    RIP: 0033:0x7fe9c7a275a0
    RSP: 002b:00007ffee5498738 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
    RAX: ffffffffffffffda RBX: 00007fe9c7ce4b00 RCX: 00007fe9c7a275a0
    RDX: 0000000000000018 RSI: 00007ffee5498800 RDI: 0000000000000003
    RBP: 000055d0c8d3f010 R08: 00007ffee5498800 R09: 0000000000000018
    R10: 00000000000000ba R11: 0000000000000246 R12: 0000000000008000
    R13: 0000000000004fb0 R14: 000055d0c8d3f050 R15: 00007ffee5498560
    
    Allocated by task 1:
     __kmalloc+0x3f9/0x430
     alloc_mad_private+0x25/0x50
     ib_mad_post_receive_mads+0x204/0xa60
     ib_mad_init_device+0xa59/0x1020
     ib_register_device+0x83a/0xbc0
     mlx5_ib_add+0x50e/0x5c0
     mlx5_add_device+0x142/0x410
     mlx5_register_interface+0x18f/0x210
     mlx5_ib_init+0x56/0x63
     do_one_initcall+0x15b/0x270
     kernel_init_freeable+0x2d8/0x3d0
     kernel_init+0x14/0x190
     ret_from_fork+0x24/0x30
    
    Freed by task 0:
    (stack is not available)
    
    The buggy address belongs to the object at ffff880019ae2000
     which belongs to the cache kmalloc-512 of size 512
    The buggy address is located 104 bytes to the right of
     512-byte region [ffff880019ae2000, ffff880019ae2200)
    The buggy address belongs to the page:
    page:000000005d674e18 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
    flags: 0x4000000000008100(slab|head)
    raw: 4000000000008100 0000000000000000 0000000000000000 00000001000c000c
    raw: dead000000000100 dead000000000200 ffff88001a402000 0000000000000000
    page dumped because: kasan: bad access detected
    
    Memory state around the buggy address:
     ffff880019ae2100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff880019ae2180: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
    >ffff880019ae2200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                              ^
     ffff880019ae2280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
     ffff880019ae2300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    ==================================================================
    Disabling lock debugging due to kernel taint
    
    Cc: <[email protected]>
    Fixes: 44c58487d51a ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
    Signed-off-by: Leon Romanovsky <[email protected]>
    Signed-off-by: Jason Gunthorpe <[email protected]>

commit 6311b7ce42e0c1d6d944bc099dc47e936c20cf11
Author: Johannes Berg <[email protected]>
Date:   Mon Jan 15 12:42:25 2018 +0100

    netlink: extack: avoid parenthesized string constant warning
    
    NL_SET_ERR_MSG() and NL_SET_ERR_MSG_ATTR() lead to the following warning
    in newer versions of gcc:
      warning: array initialized from parenthesized string constant
    
    Just remove the parentheses, they're not needed in this context since
    anyway since there can be no operator precendence issues or similar.
    
    Signed-off-by: Johannes Berg <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit cd9ff4de0107c65d69d02253bb25d6db93c3dbc1
Author: Jim Westfall <[email protected]>
Date:   Sun Jan 14 04:18:51 2018 -0800

    ipv4: Make neigh lookup keys for loopback/point-to-point devices be INADDR_ANY
    
    Map all lookup neigh keys to INADDR_ANY for loopback/point-to-point devices
    to avoid making an entry for every remote ip the device needs to talk to.
    
    This used the be the old behavior but became broken in a263b3093641f
    (ipv4: Make neigh lookups directly in output packet path) and later removed
    in 0bb4087cbec0 (ipv4: Fix neigh lookup keying over loopback/point-to-point
    devices) because it was broken.
    
    Signed-off-by: Jim Westfall <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 096b9854c04df86f03b38a97d40b6506e5730919
Author: Jim Westfall <[email protected]>
Date:   Sun Jan 14 04:18:50 2018 -0800

    net: Allow neigh contructor functions ability to modify the primary_key
    
    Use n->primary_key instead of pkey to account for the possibility that a neigh
    constructor function may have modified the primary_key value.
    
    Signed-off-by: Jim Westfall <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 17d0fb0caa68f2bfd8aaa8125ff15abebfbfa1d7
Author: Sergei Shtylyov <[email protected]>
Date:   Sat Jan 13 20:22:01 2018 +0300

    sh_eth: fix dumping ARSTR
    
    ARSTR  is always located at the start of the TSU register region, thus
    using add_reg()  instead of add_tsu_reg() in __sh_eth_get_regs() to dump it
    causes EDMR or EDSR (depending on the register layout) to be dumped instead
    of ARSTR.  Use the correct condition/macro there...
    
    Fixes: 6b4b4fead342 ("sh_eth: Implement ethtool register dump operations")
    Signed-off-by: Sergei Shtylyov <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 95a332088ecb113c2e8753fa3f1df9b0dda9beec
Author: William Tu <[email protected]>
Date:   Fri Jan 12 12:29:22 2018 -0800

    Revert "openvswitch: Add erspan tunnel support."
    
    This reverts commit ceaa001a170e43608854d5290a48064f57b565ed.
    
    The OVS_TUNNEL_KEY_ATTR_ERSPAN_OPTS attr should be designed
    as a nested attribute to support all ERSPAN v1 and v2's fields.
    The current attr is a be32 supporting only one field.  Thus, this
    patch reverts it and later patch will redo it using nested attr.
    
    Signed-off-by: William Tu <[email protected]>
    Cc: Jiri Benc <[email protected]>
    Cc: Pravin Shelar <[email protected]>
    Acked-by: Jiri Benc <[email protected]>
    Acked-by: Pravin B Shelar <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 30be8f8dba1bd2aff73e8447d59228471233a3d4
Author: [email protected] <[email protected]>
Date:   Fri Jan 12 15:42:06 2018 +0100

    net/tls: Fix inverted error codes to avoid endless loop
    
    sendfile() calls can hang endless with using Kernel TLS if a socket error occurs.
    Socket error codes must be inverted by Kernel TLS before returning because
    they are stored with positive sign. If returned non-inverted they are
    interpreted as number of bytes sent, causing endless looping of the
    splice mechanic behind sendfile().
    
    Signed-off-by: Robert Hering <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 95ef498d977bf44ac094778fd448b98af158a3e6
Author: Eric Dumazet <[email protected]>
Date:   Thu Jan 11 22:31:18 2018 -0800

    ipv6: ip6_make_skb() needs to clear cork.base.dst
    
    In my last patch, I missed fact that cork.base.dst was not initialized
    in ip6_make_skb() :
    
    If ip6_setup_cork() returns an error, we might attempt a dst_release()
    on some random pointer.
    
    Fixes: 862c03ee1deb ("ipv6: fix possible mem leaks in ipv6_make_skb()")
    Signed-off-by: Eric Dumazet <[email protected]>
    Reported-by: syzbot <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 68e76e034b6b1c1ce2eece1ab8ae4008e14be470
Author: Randy Dunlap <[email protected]>
Date:   Mon Jan 15 11:07:27 2018 -0800

    tracing: Prevent PROFILE_ALL_BRANCHES when FORTIFY_SOURCE=y
    
    I regularly get 50 MB - 60 MB files during kernel randconfig builds.
    These large files mostly contain (many repeats of; e.g., 124,594):
    
    In file included from ../include/linux/string.h:6:0,
                     from ../include/linux/uuid.h:20,
                     from ../include/linux/mod_devicetable.h:13,
                     from ../scripts/mod/devicetable-offsets.c:3:
    ../include/linux/compiler.h:64:4: warning: '______f' is static but declared in inline function 'strcpy' which is not static [enabled by default]
        ______f = {     \
        ^
    ../include/linux/compiler.h:56:23: note: in expansion of macro '__trace_if'
                           ^
    ../include/linux/string.h:425:2: note: in expansion of macro 'if'
      if (p_size == (size_t)-1 && q_size == (size_t)-1)
      ^
    
    This only happens when CONFIG_FORTIFY_SOURCE=y and
    CONFIG_PROFILE_ALL_BRANCHES=y, so prevent PROFILE_ALL_BRANCHES if
    FORTIFY_SOURCE=y.
    
    Link: http://lkml.kernel.org/r/[email protected]
    
    Signed-off-by: Randy Dunlap <[email protected]>
    Signed-off-by: Steven Rostedt (VMware) <[email protected]>

commit 37f47bc90c7481e7959703ad1defc4fc9f5d85e3
Author: Marcelo Ricardo Leitner <[email protected]>
Date:   Thu Jan 11 14:22:06 2018 -0200

    sctp: avoid compiler warning on implicit fallthru
    
    These fall-through are expected.
    
    Signed-off-by: Marcelo Ricardo Leitner <[email protected]>
    Acked-by: Neil Horman <[email protected]>
    Reviewed-by: Xin Long <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 6503a30440962f1e1ccb8868816b4e18201218d4
Author: Lorenzo Colitti <[email protected]>
Date:   Thu Jan 11 18:36:26 2018 +0900

    net: ipv4: Make "ip route get" match iif lo rules again.
    
    Commit 3765d35ed8b9 ("net: ipv4: Convert inet_rtm_getroute to rcu
    versions of route lookup") broke "ip route get" in the presence
    of rules that specify iif lo.
    
    Host-originated traffic always has iif lo, because
    ip_route_output_key_hash and ip6_route_output_flags set the flow
    iif to LOOPBACK_IFINDEX. Thus, putting "iif lo" in an ip rule is a
    convenient way to select only originated traffic and not forwarded
    traffic.
    
    inet_rtm_getroute used to match these rules correctly because
    even though it sets the flow iif to 0, it called
    ip_route_output_key which overwrites iif with LOOPBACK_IFINDEX.
    But now that it calls ip_route_output_key_hash_rcu, the ifindex
    will remain 0 and not match the iif lo in the rule. As a result,
    "ip route get" will return ENETUNREACH.
    
    Fixes: 3765d35ed8b9 ("net: ipv4: Convert inet_rtm_getroute to rcu versions of route lookup")
    Tested: https://android.googlesource.com/kernel/tests/+/master/net/test/multinetwork_test.py passes again
    Signed-off-by: Lorenzo Colitti <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit cbbdf8433a5f117b1a2119ea30fc651b61ef7570
Author: David Ahern <[email protected]>
Date:   Wed Jan 10 13:00:39 2018 -0800

    netlink: extack needs to be reset each time through loop
    
    syzbot triggered the WARN_ON in netlink_ack testing the bad_attr value.
    The problem is that netlink_rcv_skb loops over the skb repeatedly invoking
    the callback and without resetting the extack leaving potentially stale
    data. Initializing each time through avoids the WARN_ON.
    
    Fixes: 2d4bc93368f5a ("netlink: extended ACK reporting")
    Reported-by: [email protected]
    Signed-off-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 59b36613e85fb16ebf9feaf914570879cd5c2a21
Author: Cong Wang <[email protected]>
Date:   Wed Jan 10 12:50:25 2018 -0800

    tipc: fix a memory leak in tipc_nl_node_get_link()
    
    When tipc_node_find_by_name() fails, the nlmsg is not
    freed.
    
    While on it, switch to a goto label to properly
    free it.
    
    Fixes: be9c086715c ("tipc: narrow down exposure of struct tipc_node")
    Reported-by: Dmitry Vyukov <[email protected]>
    Cc: Jon Maloy <[email protected]>
    Cc: Ying Xue <[email protected]>
    Signed-off-by: Cong Wang <[email protected]>
    Acked-by: Ying Xue <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 749439bfac6e1a2932c582e2699f91d329658196
Author: Mike Maloney <[email protected]>
Date:   Wed Jan 10 12:45:10 2018 -0500

    ipv6: fix udpv6 sendmsg crash caused by too small MTU
    
    The logic in __ip6_append_data() assumes that the MTU is at least large
    enough for the headers.  A device's MTU may be adjusted after being
    added while sendmsg() is processing data, resulting in
    __ip6_append_data() seeing any MTU.  For an mtu smaller than the size of
    the fragmentation header, the math results in a negative 'maxfraglen',
    which causes problems when refragmenting any previous skb in the
    skb_write_queue, leaving it possibly malformed.
    
    Instead sendmsg returns EINVAL when the mtu is calculated to be less
    than IPV6_MIN_MTU.
    
    Found by syzkaller:
    kernel BUG at ./include/linux/skbuff.h:2064!
    invalid opcode: 0000 [#1] SMP KASAN
    Dumping ftrace buffer:
       (ftrace buffer empty)
    Modules linked in:
    CPU: 1 PID: 14216 Comm: syz-executor5 Not tainted 4.13.0-rc4+ #2
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
    task: ffff8801d0b68580 task.stack: ffff8801ac6b8000
    RIP: 0010:__skb_pull include/linux/skbuff.h:2064 [inline]
    RIP: 0010:__ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617
    RSP: 0018:ffff8801ac6bf570 EFLAGS: 00010216
    RAX: 0000000000010000 RBX: 0000000000000028 RCX: ffffc90003cce000
    RDX: 00000000000001b8 RSI: ffffffff839df06f RDI: ffff8801d9478ca0
    RBP: ffff8801ac6bf780 R08: ffff8801cc3f1dbc R09: 0000000000000000
    R10: ffff8801ac6bf7a0 R11: 43cb4b7b1948a9e7 R12: ffff8801cc3f1dc8
    R13: ffff8801cc3f1d40 R14: 0000000000001036 R15: dffffc0000000000
    FS:  00007f43d740c700(0000) GS:ffff8801dc100000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f7834984000 CR3: 00000001d79b9000 CR4: 00000000001406e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
     ip6_finish_skb include/net/ipv6.h:911 [inline]
     udp_v6_push_pending_frames+0x255/0x390 net/ipv6/udp.c:1093
     udpv6_sendmsg+0x280d/0x31a0 net/ipv6/udp.c:1363
     inet_sendmsg+0x11f/0x5e0 net/ipv4/af_inet.c:762
     sock_sendmsg_nosec net/socket.c:633 [inline]
     sock_sendmsg+0xca/0x110 net/socket.c:643
     SYSC_sendto+0x352/0x5a0 net/socket.c:1750
     SyS_sendto+0x40/0x50 net/socket.c:1718
     entry_SYSCALL_64_fastpath+0x1f/0xbe
    RIP: 0033:0x4512e9
    RSP: 002b:00007f43d740bc08 EFLAGS: 00000216 ORIG_RAX: 000000000000002c
    RAX: ffffffffffffffda RBX: 00000000007180a8 RCX: 00000000004512e9
    RDX: 000000000000002e RSI: 0000000020d08000 RDI: 0000000000000005
    RBP: 0000000000000086 R08: 00000000209c1000 R09: 000000000000001c
    R10: 0000000000040800 R11: 0000000000000216 R12: 00000000004b9c69
    R13: 00000000ffffffff R14: 0000000000000005 R15: 00000000202c2000
    Code: 9e 01 fe e9 c5 e8 ff ff e8 7f 9e 01 fe e9 4a ea ff ff 48 89 f7 e8 52 9e 01 fe e9 aa eb ff ff e8 a8 b6 cf fd 0f 0b e8 a1 b6 cf fd <0f> 0b 49 8d 45 78 4d 8d 45 7c 48 89 85 78 fe ff ff 49 8d 85 ba
    RIP: __skb_pull include/linux/skbuff.h:2064 [inline] RSP: ffff8801ac6bf570
    RIP: __ip6_make_skb+0x18cf/0x1f70 net/ipv6/ip6_output.c:1617 RSP: ffff8801ac6bf570
    
    Reported-by: syzbot <[email protected]>
    Signed-off-by: Mike Maloney <[email protected]>
    Reviewed-by: Eric Dumazet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 6200b430220f3b9207861b16f57916950f4ecd8e
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jan 10 17:30:22 2018 +0100

    net: cs89x0: add MODULE_LICENSE
    
    This driver lacks a MODULE_LICENSE tag, leading to a Kbuild warning:
    
    WARNING: modpost: missing MODULE_LICENSE() in drivers/net/ethernet/cirrus/cs89x0.o
    
    This adds license, author, and description according to the
    comment block at the start of the file.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0171c41835591e9aa2e384b703ef9a6ae367c610
Author: Guillaume Nault <[email protected]>
Date:   Wed Jan 10 16:24:45 2018 +0100

    ppp: unlock all_ppp_mutex before registering device
    
    ppp_dev_uninit(), which is the .ndo_uninit() handler of PPP devices,
    needs to lock pn->all_ppp_mutex. Therefore we mustn't call
    register_netdevice() with pn->all_ppp_mutex already locked, or we'd
    deadlock in case register_netdevice() fails and calls .ndo_uninit().
    
    Fortunately, we can unlock pn->all_ppp_mutex before calling
    register_netdevice(). This lock protects pn->units_idr, which isn't
    used in the device registration process.
    
    However, keeping pn->all_ppp_mutex locked during device registration
    did ensure that no device in transient state would be published in
    pn->units_idr. In practice, unlocking it before calling
    register_netdevice() doesn't change this property: ppp_unit_register()
    is called with 'ppp_mutex' locked and all searches done in
    pn->units_idr hold this lock too.
    
    Fixes: 8cb775bc0a34 ("ppp: fix device unregistration upon netns deletion")
    Reported-and-tested-by: [email protected]
    Signed-off-by: Guillaume Nault <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 66940f35d5a81d5969bb5543171c70a434fc5110
Author: Michael S. Tsirkin <[email protected]>
Date:   Wed Jan 10 16:03:05 2018 +0200

    ptr_ring: document usage around __ptr_ring_peek
    
    This explains why is the net usage of __ptr_ring_peek
    actually ok without locks.
    
    Signed-off-by: Michael S. Tsirkin <[email protected]>
    Acked-by: John Fastabend <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d542296a4d0d9f41d0186edcac2baba1b674d02f
Author: Stephen Hemminger <[email protected]>
Date:   Mon Jan 8 08:23:18 2018 -0800

    9p: add missing module license for xen transport
    
    The 9P of Xen module is missing required license and module information.
    See https://bugzilla.kernel.org/show_bug.cgi?id=198109
    
    Reported-by: Alan Bartlett <[email protected]>
    Fixes: 868eb122739a ("xen/9pfs: introduce Xen 9pfs transport driver")
    Signed-off-by: Stephen Hemminger <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a0e3a18f4baf8e3754ac1e56f0ade924d0c0c721
Author: Steven Rostedt (VMware) <[email protected]>
Date:   Mon Jan 15 10:47:09 2018 -0500

    ring-buffer: Bring back context level recursive checks
    
    Commit 1a149d7d3f45 ("ring-buffer: Rewrite trace_recursive_(un)lock() to be
    simpler") replaced the context level recursion checks with a simple counter.
    This would prevent the ring buffer code from recursively calling itself more
    than the max number of contexts that exist (Normal, softirq, irq, nmi). But
    this change caused a lockup in a specific case, which was during suspend and
    resume using a global clock. Adding a stack dump to see where this occurred,
    the issue was in the trace global clock itself:
    
      trace_buffer_lock_reserve+0x1c/0x50
      __trace_graph_entry+0x2d/0x90
      trace_graph_entry+0xe8/0x200
      prepare_ftrace_return+0x69/0xc0
      ftrace_graph_caller+0x78/0xa8
      queued_spin_lock_slowpath+0x5/0x1d0
      trace_clock_global+0xb0/0xc0
      ring_buffer_lock_reserve+0xf9/0x390
    
    The function graph tracer traced queued_spin_lock_slowpath that was called
    by trace_clock_global. This pointed out that the trace_clock_global() is not
    reentrant, as it takes a spin lock. It depended on the ring buffer recursive
    lock from letting that happen.
    
    By removing the context detection and adding just a max number of allowable
    recursions, it allowed the trace_clock_global() to be entered again and try
    to retake the spinlock it already held, causing a deadlock.
    
    Fixes: 1a149d7d3f45 ("ring-buffer: Rewrite trace_recursive_(un)lock() to be simpler")
    Reported-by: David Weinehall <[email protected]>
    Signed-off-by: Steven Rostedt (VMware) <[email protected]>

commit 499ed50f603b4c9834197b2411ba3bd9aaa624d4
Author: Benoît Thébaudeau <[email protected]>
Date:   Sun Jan 14 19:43:05 2018 +0100

    mmc: sdhci-esdhc-imx: Fix i.MX53 eSDHCv3 clock
    
    Commit 5143c953a786 ("mmc: sdhci-esdhc-imx: Allow all supported
    prescaler values") made it possible to set SYSCTL.SDCLKFS to 0 in SDR
    mode, thus bypassing the SD clock frequency prescaler, in order to be
    able to get higher SD clock frequencies in some contexts. However, that
    commit missed the fact that this value is illegal on the eSDHCv3
    instance of the i.MX53. This seems to be the only exception on i.MX,
    this value being legal even for the eSDHCv2 instances of the i.MX53.
    
    Fix this issue by changing the minimum prescaler value if the i.MX53
    eSDHCv3 is detected. According to the i.MX53 reference manual, if
    DLLCTRL[10] can be set, then the controller is eSDHCv3, else it is
    eSDHCv2.
    
    This commit fixes the following issue, which was preventing the i.MX53
    Loco (IMX53QSB) board from booting Linux 4.15.0-rc5:
    [    1.882668] mmcblk1: error -84 transferring data, sector 2048, nr 8, cmd response 0x900, card status 0xc00
    [    2.002255] mmcblk1: error -84 transferring data, sector 2050, nr 6, cmd response 0x900, card status 0xc00
    [   12.645056] mmc1: Timeout waiting for hardware interrupt.
    [   12.650473] mmc1: sdhci: ============ SDHCI REGISTER DUMP ===========
    [   12.656921] mmc1: sdhci: Sys addr:  0x00000000 | Version:  0x00001201
    [   12.663366] mmc1: sdhci: Blk size:  0x00000004 | Blk cnt:  0x00000000
    [   12.669813] mmc1: sdhci: Argument:  0x00000000 | Trn mode: 0x00000013
    [   12.676258] mmc1: sdhci: Present:   0x01f8028f | Host ctl: 0x00000013
    [   12.682703] mmc1: sdhci: Power:     0x00000002 | Blk gap:  0x00000000
    [   12.689148] mmc1: sdhci: Wake-up:   0x00000000 | Clock:    0x0000003f
    [   12.695594] mmc1: sdhci: Timeout:   0x0000008e | Int stat: 0x00000000
    [   12.702039] mmc1: sdhci: Int enab:  0x107f004b | Sig enab: 0x107f004b
    [   12.708485] mmc1: sdhci: AC12 err:  0x00000000 | Slot int: 0x00001201
    [   12.714930] mmc1: sdhci: Caps:      0x07eb0000 | Caps_1:   0x08100810
    [   12.721375] mmc1: sdhci: Cmd:       0x0000163a | Max curr: 0x00000000
    [   12.727821] mmc1: sdhci: Resp[0]:   0x00000920 | Resp[1]:  0x00000000
    [   12.734265] mmc1: sdhci: Resp[2]:   0x00000000 | Resp[3]:  0x00000000
    [   12.740709] mmc1: sdhci: Host ctl2: 0x00000000
    [   12.745157] mmc1: sdhci: ADMA Err:  0x00000001 | ADMA Ptr: 0xc8049200
    [   12.751601] mmc1: sdhci: ============================================
    [   12.758110] print_req_error: I/O error, dev mmcblk1, sector 2050
    [   12.764135] Buffer I/O error on dev mmcblk1p1, logical block 0, lost sync page write
    [   12.775163] EXT4-fs (mmcblk1p1): mounted filesystem without journal. Opts: (null)
    [   12.782746] VFS: Mounted root (ext4 filesystem) on device 179:9.
    [   12.789151] mmcblk1: response CRC error sending SET_BLOCK_COUNT command, card status 0x900
    
    Signed-off-by: Benoît Thébaudeau <[email protected]>
    Reported-by: Wladimir J. van der Laan <[email protected]>
    Tested-by: Wladimir J. van der Laan <[email protected]>
    Fixes: 5143c953a786 ("mmc: sdhci-esdhc-imx: Allow all supported prescaler values")
    Cc: <[email protected]> # v4.13+
    Signed-off-by: Ulf Hansson <[email protected]>

commit 59b179b48ce2a6076448a44531242ac2b3f6cef2
Author: Johannes Berg <[email protected]>
Date:   Mon Jan 15 09:58:27 2018 +0100

    cfg80211: check dev_set_name() return value
    
    syzbot reported a warning from rfkill_alloc(), and after a while
    I think that the reason is that it was doing fault injection and
    the dev_set_name() failed, leaving the name NULL, and we didn't
    check the return value and got to rfkill_alloc() with a NULL name.
    Since we really don't want a NULL name, we ought to check the
    return value.
    
    Fixes: fb28ad35906a ("net: struct device - replace bus_id with dev_name(), dev_set_name()")
    Reported-by: [email protected]
    Signed-off-by: Johannes Berg <[email protected]>

commit 51a1aaa631c90223888d8beac4d649dc11d2ca55
Author: Johannes Berg <[email protected]>
Date:   Mon Jan 15 09:32:36 2018 +0100

    mac80211_hwsim: validate number of different channels
    
    When creating a new radio on the fly, hwsim allows this
    to be done with an arbitrary number of channels, but
    cfg80211 only supports a limited number of simultaneous
    channels, leading to a warning.
    
    Fix this by validating the number - this requires moving
    the define for the maximum out to a visible header file.
    
    Reported-by: [email protected]
    Fixes: b59ec8dd4394 ("mac80211_hwsim: fix number of channels in interface combinations")
    Signed-off-by: Johannes Berg <[email protected]>

commit b71d856ab536f25eb97c011a351ecddf5518de41
Author: Benjamin Beichler <[email protected]>
Date:   Wed Jan 10 17:42:51 2018 +0100

    mac80211_hwsim: add workqueue to wait for deferred radio deletion on mod unload
    
    When closing multiple wmediumd instances with many radios and try to
    unload the  mac80211_hwsim module, it may happen that the work items live
    longer than the module. To wait especially for this deletion work items,
    add a work queue, otherwise flush_scheduled_work would be necessary.
    
    Signed-off-by: Benjamin Beichler <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>

commit 7a94b8c2eee7083ddccd0515830f8c81a8e44b1a
Author: Dominik Brodowski <[email protected]>
Date:   Mon Jan 15 08:12:15 2018 +0100

    nl80211: take RCU read lock when calling ieee80211_bss_get_ie()
    
    As ieee80211_bss_get_ie() derefences an RCU to return ssid_ie, both
    the call to this function and any operation on this variable need
    protection by the RCU read lock.
    
    Fixes: 44905265bc15 ("nl80211: don't expose wdev->ssid for most interfaces")
    Signed-off-by: Dominik Brodowski <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>

commit a48a52b7bea81c046fe1c1288f84d0eba214cba0
Author: Johannes Berg <[email protected]>
Date:   Mon Jan 15 09:12:05 2018 +0100

    cfg80211: fully initialize old channel for event
    
    Paul reported that he got a report about undefined behaviour
    that seems to me to originate in using uninitialized memory
    when the channel structure here is used in the event code in
    nl80211 later.
    
    He never reported whether this fixed it, and I wasn't able
    to trigger this so far, but we should do the right thing and
    fully initialize the on-stack structure anyway.
    
    Reported-by: Paul Menzel <[email protected]>
    Signed-off-by: Johannes Berg <[email protected]>

commit 28d437d550e1e39f805d99f9f8ac399c778827b7
Author: Tom Lendacky <[email protected]>
Date:   Sat Jan 13 17:27:30 2018 -0600

    x86/retpoline: Add LFENCE to the retpoline/RSB filling RSB macros
    
    The PAUSE instruction is currently used in the retpoline and RSB filling
    macros as a speculation trap.  The use of PAUSE was originally suggested
    because it showed a very, very small difference in the amount of
    cycles/time used to execute the retpoline as compared to LFENCE.  On AMD,
    the PAUSE instruction is not a serializing instruction, so the pause/jmp
    loop will use excess power as it is speculated over waiting for return
    to mispredict to the correct target.
    
    The RSB filling macro is applicable to AMD, and, if software is unable to
    verify that LFENCE is serializing on AMD (possible when running under a
    hypervisor), the generic retpoline support will be used and, so, is also
    applicable to AMD.  Keep the current usage of PAUSE for Intel, but add an
    LFENCE instruction to the speculation trap for AMD.
    
    The same sequence has been adopted by GCC for the GCC generated retpolines.
    
    Signed-off-by: Tom Lendacky <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Reviewed-by: Borislav Petkov <[email protected]>
    Acked-by: David Woodhouse <[email protected]>
    Acked-by: Arjan van de Ven <[email protected]>
    Cc: Rik van Riel <[email protected]>
    Cc: Andi Kleen <[email protected]>
    Cc: Paul Turner <[email protected]>
    Cc: Peter Zijlstra <[email protected]>
    Cc: Tim Chen <[email protected]>
    Cc: Jiri Kosina <[email protected]>
    Cc: Dave Hansen <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: Josh Poimboeuf <[email protected]>
    Cc: Dan Williams <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Kees Cook <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]

commit c995efd5a740d9cbafbf58bde4973e8b50b4d761
Author: David Woodhouse <[email protected]>
Date:   Fri Jan 12 17:49:25 2018 +0000

    x86/retpoline: Fill RSB on context switch for affected CPUs
    
    On context switch from a shallow call stack to a deeper one, as the CPU
    does 'ret' up the deeper side it may encounter RSB entries (predictions for
    where the 'ret' goes to) which were populated in userspace.
    
    This is problematic if neither SMEP nor KPTI (the latter of which marks
    userspace pages as NX for the kernel) are active, as malicious code in
    userspace may then be executed speculatively.
    
    Overwrite the CPU's return prediction stack with calls which are predicted
    to return to an infinite loop, to "capture" speculation if this
    happens. This is required both for retpoline, and also in conjunction with
    IBRS for !SMEP && !KPTI.
    
    On Skylake+ the problem is slightly different, and an *underflow* of the
    RSB may cause errant branch predictions to occur. So there it's not so much
    overwrite, as *filling* the RSB to attempt to prevent it getting
    empty. This is only a partial solution for Skylake+ since there are many
    other conditions which may result in the RSB becoming empty. The full
    solution on Skylake+ is to use IBRS, which will prevent the problem even
    when the RSB becomes empty. With IBRS, the RSB-stuffing will not be
    required on context switch.
    
    [ tglx: Added missing vendor check and slighty massaged comments and
            changelog ]
    
    Signed-off-by: David Woodhouse <[email protected]>
    Signed-off-by: Thomas Gleixner <[email protected]>
    Acked-by: Arjan van de Ven <[email protected]>
    Cc: [email protected]
    Cc: Rik van Riel <[email protected]>
    Cc: Andi Kleen <[email protected]>
    Cc: Josh Poimboeuf <[email protected]>
    Cc: [email protected]
    Cc: Peter Zijlstra <[email protected]>
    Cc: Linus Torvalds <[email protected]>
    Cc: Jiri Kosina <[email protected]>
    Cc: Andy Lutomirski <[email protected]>
    Cc: Dave Hansen <[email protected]>
    Cc: Kees Cook <[email protected]>
    Cc: Tim Chen <[email protected]>
    Cc: Greg Kroah-Hartman <[email protected]>
    Cc: Paul Turner <[email protected]>
    Link: https://lkml.kernel.org/r/[email protected]

commit 0d39e…
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jan 21, 2018
GIT d320e9ba19cf1a183eb5c6a677b7ff541c317d15

commit 666b9a02698f3b52f3530536e130e54965af650b
Author: Arnd Bergmann <[email protected]>
Date:   Wed Jan 17 16:16:48 2018 +0100

    scsi: fnic: use 64-bit timestamps
    
    struct timespec is deprecated since it overflows in 2038 on 32-bit
    architectures, so we should use timespec64 consistently.
    
    I'm slightly adapting the format strings here, to make sure we print the
    nanoseconds with the correct number of leading zeroes.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Acked-by: Satish Kharat <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>

commit 8d0130d42a361ff98020d39a3e31f4a691cec573
Author: Wei Yongjun <[email protected]>
Date:   Wed Jan 17 12:42:41 2018 +0000

    scsi: qedf: Fix error return code in __qedf_probe()
    
    Fix to return error code -ENOMEM from the error handling case instead of
    0, as done elsewhere in this function.
    
    Signed-off-by: Wei Yongjun <[email protected]>
    Acked-by: Chad Dupuis <[email protected]>
    Signed-off-by: Martin K. Petersen <[email protected]>

commit e65935969d0fac9df28d9c49bdbab5d8d8286a20
Author: Jiong Wang <[email protected]>
Date:   Tue Jan 16 16:05:21 2018 -0800

    tools: bpftool: improve architecture detection by using ifindex
    
    The current architecture detection method in bpftool is designed for host
    case.
    
    For offload case, we can't use the architecture of "bpftool" itself.
    Instead, we could call the existing "ifindex_to_name_ns" to get DEVNAME,
    then read pci id from /sys/class/dev/DEVNAME/device/vendor, finally we map
    vendor id to bfd arch name which will finally be used to select bfd backend
    for the disassembler.
    
    Reviewed-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Jiong Wang <[email protected]>
    Acked-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>

commit eb1d7db927a9653f1402473c777839e0456a7836
Author: Jiong Wang <[email protected]>
Date:   Tue Jan 16 16:05:20 2018 -0800

    nfp: bpf: set new jit info fields
    
    This patch set those new jit info fields introduced in this patch set.
    
    Reviewed-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Jiong Wang <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>

commit fcfb126defda3cee3f1d9460dbe9a2ccac4fbd21
Author: Jiong Wang <[email protected]>
Date:   Tue Jan 16 16:05:19 2018 -0800

    bpf: add new jited info fields in bpf_dev_offload and bpf_prog_info
    
    For host JIT, there are "jited_len"/"bpf_func" fields in struct bpf_prog
    used by all host JIT targets to get jited image and it's length. While for
    offload, targets are likely to have different offload mechanisms that these
    info are kept in device private data fields.
    
    Therefore, BPF_OBJ_GET_INFO_BY_FD syscall needs an unified way to get JIT
    length and contents info for offload targets.
    
    One way is to introduce new callback to parse device private data then fill
    those fields in bpf_prog_info. This might be a little heavy, the other way
    is to add generic fields which will be initialized by all offload targets.
    
    This patch follow the second approach to introduce two new fields in
    struct bpf_dev_offload and teach bpf_prog_get_info_by_fd about them to fill
    correct jited_prog_len and jited_prog_insns in bpf_prog_info.
    
    Reviewed-by: Jakub Kicinski <[email protected]>
    Signed-off-by: Jiong Wang <[email protected]>
    Acked-by: Alexei Starovoitov <[email protected]>
    Signed-off-by: Daniel Borkmann <[email protected]>

commit ae17a87dd7c79fa742ef5dcf06d1095eec4e1925
Author: Masanari Iida <[email protected]>
Date:   Thu Jan 11 20:00:28 2018 +0900

    linux-next: docs-rst: Fix typos in kfigure.py
    
    This patch fixes some spelling typos found in kfigure.py
    
    Signed-off-by: Masanari Iida <[email protected]>
    Signed-off-by: Jonathan Corbet <[email protected]>

commit 5d87a33782d36c5f2192c93612262deaaa57ad50
Author: Masanari Iida <[email protected]>
Date:   Thu Jan 11 22:28:37 2018 +0900

    linux-next: DOC: HWPOISON: Fix path to debugfs in hwpoison.txt
    
    This patch fixes an incorrect path for debugfs in hwpoison.txt
    
    Signed-off-by: Masanari Iida <[email protected]>
    Signed-off-by: Jonathan Corbet <[email protected]>

commit 423860a65ae54fa1fbd3abb224bdc62124dcdb90
Author: Matthew Wilcox <[email protected]>
Date:   Tue Jan 16 19:40:55 2018 -0800

    Documentation: Fix misconversion of #if
    
    At some stage of the conversion pipeline, something thought that the
    DocBook entity &num; should be rendered as NUM instead of #.
    
    Signed-off-by: Matthew Wilcox <[email protected]>
    Signed-off-by: Jonathan Corbet <[email protected]>

commit 5bacb56b2b56283ab26fea9e15f06ebe27afbe3d
Author: Wolfram Sang <[email protected]>
Date:   Thu Jan 18 00:18:17 2018 +0100

    i2c: rk3x: add proper kerneldoc header
    
    gcc noticed the kerneldoc was wrongly formatted. Fix it!
    
    drivers/i2c/busses/i2c-rk3x.c:164: warning:
      Cannot understand  * @grf_offset: ...
      on line 164 - I thought it was a doc line
    
    Signed-off-by: Wolfram Sang <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>

commit d032a2eb2e3b9fc2def41c22bfb58e1efc2c6823
Author: Julia Lawall <[email protected]>
Date:   Tue Jan 2 14:28:03 2018 +0100

    i2c: rk3x: account for const type of of_device_id.data
    
    This driver creates a number of const structures that it stores in
    the data field of an of_device_id array.
    
    The data field of an of_device_id structure has type const void *, so
    there is no need for a const-discarding cast when putting const values
    into such a structure.
    
    Furthermore, adding const to the declaration of the location that
    receives a const value from such a field ensures that the compiler
    will continue to check that the value is not modified.  The
    const-discarding cast on the extraction from the data field is thus
    no longer needed.
    
    Done using Coccinelle.
    
    Signed-off-by: Julia Lawall <[email protected]>
    Reviewed-by: Heiko Stuebner <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>

commit f89813ec8ba4b46c7926325eb9835ef1c6793496
Author: Wolfram Sang <[email protected]>
Date:   Mon Jan 15 18:41:39 2018 +0100

    i2c: acorn: remove outdated path from file header
    
    That path has gone away for a long time. Move the HW name upwards for a
    proper header.
    
    Signed-off-by: Wolfram Sang <[email protected]>

commit e199c285b66705bec2f63a9230f50dadfa6dc0fb
Author: Arnd Bergmann <[email protected]>
Date:   Mon Jan 15 21:28:39 2018 +0100

    i2c: acorn: add MODULE_LICENSE tag
    
    As of v4.15, Kbuild warns about missing MODULE_LICENSE tags:
    
    WARNING: modpost: missing MODULE_LICENSE() in drivers/i2c/busses/i2c-acorn.o
    
    This adds a license, author and description tag, matching the
    comment at the start of the acorn i2c driver.
    
    Signed-off-by: Arnd Bergmann <[email protected]>
    Signed-off-by: Wolfram Sang <[email protected]>

commit 5ef7e0ba1039d65c4eefde92056769548b214273
Author: Luis de Bethencourt <[email protected]>
Date:   Tue Jan 16 15:03:32 2018 +0000

    vxlan: Fix trailing semicolon
    
    The trailing semicolon is an empty statement that does no operation.
    It is completely stripped out by the compiler. Removing it since it doesn't do
    anything.
    
    Fixes: 5f35227ea34b ("net: Generalize ndo_gso_check to ndo_features_check")
    Signed-off-by: Luis de Bethencourt <[email protected]>
    Acked-by: Stephen Hemminger <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit baf5086840ab1815003e6ece5a51c1a803f81f47
Author: Ganesh Goudar <[email protected]>
Date:   Tue Jan 16 16:17:40 2018 +0530

    cxgb4: restructure VF mgmt code
    
    restructure the code which adds support for configuring
    PCIe VF via mgmt netdevice. which was added by
    commit 7829451c695e ("cxgb4: Add control net_device for
    configuring PCIe VF")
    
    Original work by: Casey Leedom <[email protected]>
    Signed-off-by: Ganesh Goudar <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 793e4f7551c7b637952405d35282d3cc5f1a779f
Author: Sascha Hauer <[email protected]>
Date:   Fri Nov 24 12:17:14 2017 +0100

    ubi: Fix copy/paste error in function documentation
    
    The function documentation of leb_write_trylock is copied from
    leb_write_lock. Replace the function name with the correct one.
    
    Signed-off-by: Sascha Hauer <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 0e099a38ea5a8d546a9ca8bac1fc43c61b210df6
Author: Sascha Hauer <[email protected]>
Date:   Fri Nov 24 12:14:06 2017 +0100

    ubi: Fastmap: Fix typo
    
    Fix misspelling of 'available' in function name.
    
    Signed-off-by: Sascha Hauer <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 088594d6d8eb16ae2f43c032d46901c6237e7658
Author: Rock Lee <[email protected]>
Date:   Wed Jan 10 21:08:24 2018 -0500

    ubifs: remove error message in ubifs_xattr_get
    
    There is a situation that other modules, like overlayfs, try to get
    xattr value with a small buffer, if they get -ERANGE, they will try
    again with the proper buffer size. No need to report an error.
    
    Signed-off-by: Rock Lee <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 9a2cebc6e2368072490a574eafe0f0747d330bbd
Author: Eric Biggers <[email protected]>
Date:   Fri Jan 5 11:30:03 2018 -0800

    ubifs: free the encrypted symlink target
    
    ubifs_symlink() forgot to free the kmalloc()'ed buffer holding the
    encrypted symlink target, creating a memory leak.  Fix it.
    
    (UBIFS could actually encrypt directly into ui->data, removing the
    temporary buffer, but that is left for the patch that switches to use
    the symlink helper functions.)
    
    Fixes: ca7f85be8d6c ("ubifs: Add support for encrypted symlinks")
    Cc: <[email protected]> # v4.10+
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit f78e5623f45bab2b726eec29dc5cefbbab2d0b1c
Author: Sascha Hauer <[email protected]>
Date:   Tue Dec 5 16:01:20 2017 +0100

    ubi: fastmap: Erase outdated anchor PEBs during attach
    
    The fastmap update code might erase the current fastmap anchor PEB
    in case it doesn't find any new free PEB. When a power cut happens
    in this situation we must not have any outdated fastmap anchor PEB
    on the device, because that would be used to attach during next
    boot.
    The easiest way to make that sure is to erase all outdated fastmap
    anchor PEBs synchronously during attach.
    
    Signed-off-by: Sascha Hauer <[email protected]>
    Reviewed-by: Richard Weinberger <[email protected]>
    Fixes: dbb7d2a88d2a ("UBI: Add fastmap core")
    Cc: <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 252153ba518ac0bcde6b7152c63380d4415bfe5d
Author: Eric Biggers <[email protected]>
Date:   Wed Nov 29 12:43:17 2017 -0800

    ubifs: switch to fscrypt_prepare_setattr()
    
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit a0b3ccd9636014664e5dec80a86ef624399c105c
Author: Eric Biggers <[email protected]>
Date:   Wed Nov 29 12:43:16 2017 -0800

    ubifs: switch to fscrypt_prepare_lookup()
    
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 0c1ad5242d4f7c155661449a766e98f0018799ee
Author: Eric Biggers <[email protected]>
Date:   Wed Nov 29 12:43:15 2017 -0800

    ubifs: switch to fscrypt_prepare_rename()
    
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 5653878c8ca417b2f7b283df0db0141bb3c185f7
Author: Eric Biggers <[email protected]>
Date:   Wed Nov 29 12:43:14 2017 -0800

    ubifs: switch to fscrypt_prepare_link()
    
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 7e35c4dac3e7b02bbf1588af52edf155537e5b61
Author: Eric Biggers <[email protected]>
Date:   Wed Nov 29 12:43:13 2017 -0800

    ubifs: switch to fscrypt_file_open()
    
    Signed-off-by: Eric Biggers <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit f50629df49f59b044c89f99a4bcd02cafdb38258
Author: Colin Ian King <[email protected]>
Date:   Sun Oct 29 13:14:26 2017 +0000

    ubi: fastmap: Clean up the initialization of pointer p
    
    The pointer p is being initialized with one value and a few lines
    later being set to a newer replacement value. Clean up the code by
    using the latter assignment to p as the initial value. Cleans up
    clang warning:
    
    drivers/mtd/ubi/fastmap.c:217:19: warning: Value stored to 'p'
    during its initialization is never read
    
    Signed-off-by: Colin Ian King <[email protected]>
    Reviewed-by: Boris Brezillon <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit af7bcee27652bbf2502207500ad200763707a160
Author: Pan Bian <[email protected]>
Date:   Sun Oct 29 20:40:02 2017 +0800

    ubi: fastmap: Use kmem_cache_free to deallocate memory
    
    Memory allocated by kmem_cache_alloc() should not be deallocated with
    kfree(). Use kmem_cache_free() instead.
    
    Signed-off-by: Pan Bian <[email protected]>
    Reviewed-by: Boris Brezillon <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit a51a0c8d213594bc094cb8e54aad0cb6d7f7b9a6
Author: Clay McClure <[email protected]>
Date:   Thu Sep 21 19:01:34 2017 -0700

    ubi: Fix race condition between ubi volume creation and udev
    
    Similar to commit 714fb87e8bc0 ("ubi: Fix race condition between ubi
    device creation and udev"), we should make the volume active before
    registering it.
    
    Signed-off-by: Clay McClure <[email protected]>
    Cc: <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 42157277af17d5c05946c700eb03877d60760d3c
Author: Kirill Tkhai <[email protected]>
Date:   Tue Jan 16 12:31:54 2018 +0300

    net: Remove spinlock from get_net_ns_by_id()
    
    idr_find() is safe under rcu_read_lock() and
    maybe_get_net() guarantees that net is alive.
    
    Signed-off-by: Kirill Tkhai <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0c06bea919f3289368a023d1a62a1bc319617fa3
Author: Kirill Tkhai <[email protected]>
Date:   Tue Jan 16 12:31:41 2018 +0300

    net: Fix possible race in peernet2id_alloc()
    
    peernet2id_alloc() is racy without rtnl_lock() as refcount_read(&peer->count)
    under net->nsid_lock does not guarantee, peer is alive:
    
    rcu_read_lock()
    peernet2id_alloc()                            ..
      spin_lock_bh(&net->nsid_lock)               ..
      refcount_read(&peer->count) (!= 0)          ..
      ..                                          put_net()
      ..                                            cleanup_net()
      ..                                              for_each_net(tmp)
      ..                                                spin_lock_bh(&tmp->nsid_lock)
      ..                                                __peernet2id(tmp, net) == -1
      ..                                                    ..
      ..                                                    ..
        __peernet2id_alloc(alloc == true)                   ..
      ..                                                    ..
    rcu_read_unlock()                                       ..
    ..                                                synchronize_rcu()
    ..                                                kmem_cache_free(net)
    
    After the above situation, net::netns_id contains id pointing to freed memory,
    and any other dereferencing by the id will operate with this freed memory.
    
    Currently, peernet2id_alloc() is used under rtnl_lock() everywhere except
    ovs_vport_cmd_fill_info(), and this race can't occur. But peernet2id_alloc()
    is generic interface, and better we fix it before someone really starts
    use it in wrong context.
    
    v2: Don't place refcount_read(&net->count) under net->nsid_lock
        as suggested by Eric W. Biederman <[email protected]>
    v3: Rebase on top of net-next
    
    Signed-off-by: Kirill Tkhai <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 0b1655143df00ac5349f27b765b2ed13a3ac40ca
Author: Kai-Heng Feng <[email protected]>
Date:   Tue Jan 16 16:46:27 2018 +0800

    r8152: disable RX aggregation on Dell TB16 dock
    
    r8153 on Dell TB15/16 dock corrupts rx packets.
    
    This change is suggested by Realtek. They guess that the XHCI controller
    doesn't have enough buffer, and their guesswork is correct, once the RX
    aggregation gets disabled, the issue is gone.
    
    ASMedia is currently working on a real sulotion for this issue.
    
    Dell and ODM confirm the bcdDevice and iSerialNumber is unique for TB16.
    
    Note that TB15 has different bcdDevice and iSerialNumber, which are not
    unique values. If you still have TB15, please contact Dell to replace it
    with TB16.
    
    BugLink: https://bugs.launchpad.net/bugs/1729674
    Cc: Mario Limonciello <[email protected]>
    Signed-off-by: Kai-Heng Feng <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit aff3d70a07fffc0abb53663e4a4acb059d2f36af
Author: Jason Wang <[email protected]>
Date:   Tue Jan 16 16:31:02 2018 +0800

    tun: allow to attach ebpf socket filter
    
    This patch allows userspace to attach eBPF filter to tun. This will
    allow to implement VM dataplane filtering in a more efficient way
    compared to cBPF filter by allowing either qemu or libvirt to
    attach eBPF filter to tun.
    
    Signed-off-by: Jason Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit cd5681d7d8903bf43a571aaf96cf6d2e2e00118c
Author: Jason Wang <[email protected]>
Date:   Tue Jan 16 16:31:01 2018 +0800

    tuntap: rename struct tun_steering_prog to struct tun_prog
    
    To be reused by other eBPF program other than queue selection.
    
    Signed-off-by: Jason Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 8bbfbc2df6e9a37bc5c9ee674c496ea277b0bd39
Author: Eugeniy Paltsev <[email protected]>
Date:   Wed Jan 17 16:39:17 2018 +0300

    ARCv2: cache: fix slc_entire_op: flush only instead of flush-n-inv
    
    slc_entire_op with OP_FLUSH command also invalidates it.
    
    This is a preventive fix as the current use of slc_entire_op is only
    with OP_FLUSH_N_INV where the invalidate is required.
    
    Signed-off-by: Eugeniy Paltsev <[email protected]>
    [vgupta: fixed changelog]
    Signed-off-by: Vineet Gupta <[email protected]>

commit 01353bbea50334847d4a7f9e0e8a31c609a21300
Author: Fengguang Wu <[email protected]>
Date:   Thu Jan 18 01:51:18 2018 +0800

    phy: brcm-sata: fix semicolon.cocci warnings
    
    drivers/phy/broadcom/phy-brcm-sata.c:534:2-3: Unneeded semicolon
    
     Remove unneeded semicolon.
    
    Generated by: scripts/coccinelle/misc/semicolon.cocci
    
    Fixes: 3e507769d15e ("phy: brcm-sata: Implement calibrate callback")
    CC: Florian Fainelli <[email protected]>
    Signed-off-by: Fengguang Wu <[email protected]>
    Signed-off-by: Tejun Heo <[email protected]>

commit 4df0bfc79904b7169dc77dcce44598b1545721f9
Author: Cong Wang <[email protected]>
Date:   Mon Jan 15 11:37:29 2018 -0800

    tun: fix a memory leak for tfile->tx_array
    
    tfile->tun could be detached before we close the tun fd,
    via tun_detach_all(), so it should not be used to check for
    tfile->tx_array.
    
    As Jason suggested, we probably have to clean it up
    unconditionally both in __tun_deatch() and tun_detach_all(),
    but this requires to check if it is initialized or not.
    Currently skb_array_cleanup() doesn't have such a check,
    so I check it in the caller and introduce a helper function,
    it is a bit ugly but we can always improve it in net-next.
    
    Reported-by: Dmitry Vyukov <[email protected]>
    Fixes: 1576d9860599 ("tun: switch to use skb array for tx")
    Cc: Jason Wang <[email protected]>
    Signed-off-by: Cong Wang <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 4b23258d6a1b0040c1e7d2d997800cfd09294b7f
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:57 2018 +0100

    mlxsw: spectrum_acl: Pass mlxsw_sp_port down to ruleset bind/unbind ops
    
    No need to convert from mlxsw_sp_port to net_device and back again.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 3aaff323044e221b7233eddcc2fe094c662df3b0
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:56 2018 +0100

    mlxsw: spectrum_acl: Implement TC block sharing
    
    Benefit from the prepared TC and in-driver ACL infrastructure and
    introduce block sharing offload. For that, a new struct "block" is
    introduced in spectrum_acl in order to hold a list of specific
    block-port bindings.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 02caf4995ad07c592d5bbf045f6198c08cd63e87
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:55 2018 +0100

    mlxsw: spectrum_acl: Don't store netdev and ingress for ruleset unbind
    
    Instead, pass netdev and ingress flag to ruleset unbind op.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 9fe5fdf27e543c340d97f69f379bcd29a59f5723
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:54 2018 +0100

    mlxsw: spectrum_acl: Reshuffle code around mlxsw_sp_acl_ruleset_create/destroy
    
    In order to prepare for follow-up changes, make the bind/unbind helpers
    very simple. That required move of ht insertion/removal and bind/unbind
    calls into mlxsw_sp_acl_ruleset_create/destroy.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 51ab2994c387c80b45caf8b8067b3f3b97771d25
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:53 2018 +0100

    net: sched: allow ingress and clsact qdiscs to share filter blocks
    
    Benefit from the previously introduced shared filter blocks
    infrastructure and allow ingress and clsact qdisc instances to share
    filter blocks. The block index is coming from userspace as qdisc option.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit d47a6b0e7c492a4ba4524d557db388e34fd0a47a
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:52 2018 +0100

    net: sched: introduce ingress/egress block index attributes for qdisc
    
    Introduce two new attributes to be used for qdisc creation and dumping.
    One for ingress block, one for egress block. Introduce a set of ops that
    qdisc which supports block sharing would implement.
    
    Passing block indexes in qdisc change is not supported yet and it is
    checked and forbidded.
    
    In future, these attributes are to be reused for specifying block
    indexes for classes as well. As of this moment however, it is not
    supported so a check is in place to forbid it.
    
    Suggested-by: Roopa Prabhu <[email protected]>
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 7960d1daf278cbe23bb48974fe6ae6a1e44c3c15
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:51 2018 +0100

    net: sched: use block index as a handle instead of qdisc when block is shared
    
    As the tcm_ifindex with value TCM_IFINDEX_MAGIC_BLOCK is invalid ifindex,
    use it to indicate that we work with block, instead of qdisc.
    So if tcm_ifindex is set to TCM_IFINDEX_MAGIC_BLOCK, tcm_parent is used
    to carry block_index.
    
    If the block is set to be shared between at least 2 qdiscs, it is
    forbidden to use the qdisc handle to add/delete filters. In that case,
    userspace has to pass block_index.
    
    Also, for dump of the filters, in case the block is shared in between at
    least 2 qdiscs, the each filter is dumped with tcm_ifindex value
    TCM_IFINDEX_MAGIC_BLOCK and tcm_parent set to block_index. That gives
    the user clear indication, that the filter belongs to a shared block
    and not only to one qdisc under which it is dumped.
    
    Suggested-by: David Ahern <[email protected]>
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit caa7260156eb3a1496348a2c69fa68e85183d5d7
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:50 2018 +0100

    net: sched: keep track of offloaded filters and check tc offload feature
    
    During block bind, we need to check tc offload feature. If it is
    disabled yet still the block contains offloaded filters, forbid the
    bind. Also forbid to register callback for a block that already
    contains offloaded filters, as the play back is not supported now.
    For keeping track of offloaded filters there is a new counter
    introduced, alongside with couple of helpers called from cls_* code.
    These helpers set and clear TCA_CLS_FLAGS_IN_HW flag.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit edf6711c9840fd92e0047f98c411c94114168f19
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:49 2018 +0100

    net: sched: remove classid and q fields from tcf_proto
    
    Both are no longer used, so remove them.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit f36fe1c498c8959812415c57b683abaa4527dec5
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:48 2018 +0100

    net: sched: introduce block mechanism to handle netif_keep_dst calls
    
    Couple of classifiers call netif_keep_dst directly on q->dev. That is
    not possible to do directly for shared blocke where multiple qdiscs are
    owning the block. So introduce a infrastructure to keep track of the
    block owners in list and use this list to implement block variant of
    netif_keep_dst.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 9d3aaff3d8523264ff7082a90759cb8a340200be
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:47 2018 +0100

    net: sched: avoid usage of tp->q in tcf_classify
    
    Use block index in the messages instead.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 4861738775d70e0165d04fe014f32b41bcb5414a
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:46 2018 +0100

    net: sched: introduce shared filter blocks infrastructure
    
    Allow qdiscs to share filter blocks among them. Each qdisc type has to
    use block get/put extended modifications that enable sharing.
    Shared blocks are tracked within each net namespace and identified
    by u32 index. This index is passed from user during the qdisc creation.
    If user passes index that is not used by any other qdisc, new block
    is created. If user passes index that is already used, the existing
    block will be re-used.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit a9b19443edbaac97c5c094f3cc903c1f1548b3f5
Author: Jiri Pirko <[email protected]>
Date:   Wed Jan 17 11:46:45 2018 +0100

    net: sched: introduce support for multiple filter chain pointers registration
    
    So far, there was possible only to register a single filter chain
    pointer to block->chain[0]. However, when the blocks will get shareable,
    we need to allow multiple filter chain pointers registration.
    
    Signed-off-by: Jiri Pirko <[email protected]>
    Acked-by: Jamal Hadi Salim <[email protected]>
    Acked-by: David Ahern <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit dd4ea1da12495e1b3c400a28df11528892199f68
Author: Sathya Perla <[email protected]>
Date:   Wed Jan 17 03:21:16 2018 -0500

    bnxt_en: export a common switchdev PARENT_ID for all reps of an adapter
    
    Currently the driver exports different switchdev PARENT_IDs for
    representors belonging to different SR-IOV PF-pools of an adapter.
    This is not correct as the adapter can switch across all vports
    of an adapter. This patch fixes this by exporting a common switchdev
    PARENT_ID for all reps of an adapter. The PCIE DSN is used as the id.
    
    Signed-off-by: Sathya Perla <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit c3480a603773cfc5d8aa44dbbee6c96e0f9d4d9d
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:15 2018 -0500

    bnxt_en: Add cache line size setting to optimize performance.
    
    The chip supports 64-byte and 128-byte cache line size for more optimal
    DMA performance when matched to the CPU cache line size.  The default is 64.
    If the system is using 128-byte cache line size, set it to 128.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 91cdda40714178497cbd182261b2ea6ec5cb9276
Author: Vasundhara Volam <[email protected]>
Date:   Wed Jan 17 03:21:14 2018 -0500

    bnxt_en: Forward VF MAC address to the PF.
    
    Forward hwrm_func_vf_cfg command from VF to PF driver, to store
    VF MAC address in PF's context.  This will allow "ip link show"
    to display all VF MAC addresses.
    
    Maintain 2 locations of MAC address in VF info structure, one for
    a PF assigned MAC and one for VF assigned MAC.
    
    Display VF assigned MAC in "ip link show", only if PF assigned MAC is
    not valid.
    
    Signed-off-by: Vasundhara Volam <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 92abef361bd233ea2a99db9e9a637626f523f82e
Author: Vasundhara Volam <[email protected]>
Date:   Wed Jan 17 03:21:13 2018 -0500

    bnxt_en: Add BCM5745X NPAR device IDs
    
    Signed-off-by: Vasundhara Volam <[email protected]>
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 8f23d638b36b4ff0fe5785cf01f9bdc41afb9c06
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:12 2018 -0500

    bnxt_en: Expand bnxt_check_rings() to check all resources.
    
    bnxt_check_rings() is called by ethtool, XDP setup, and ndo_setup_tc()
    to see if there are enough resources to support the new configuration.
    Expand the call to test all resources if the firmware supports the new
    API.  With the more flexible resource allocation scheme, this call must
    be made to check that all resources are available before committing to
    allocate the resources.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 4673d66468b80dc37abd1159a4bd038128173d48
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:11 2018 -0500

    bnxt_en: Implement new method for the PF to assign SRIOV resources.
    
    Instead of the old method of evenly dividing the resources to the VFs,
    use the new firmware API to specify min and max resources for each VF.
    This way, there is more flexibility for each VF to allocate more or less
    resources.
    
    The min is the absolute minimum for each VF to function.  The max is the
    global resources minus the resources used by the PF.  Each VF is
    guaranteed the min.  Up to max resources may be available for some VFs.
    
    The PF driver can use one of 2 strategies specified in NVRAM to assign
    the resources.  The old legacy strategy of evenly dividing the resources
    or the new flexible strategy.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 6a1eef5b9079742ecfad647892669bd5fe6b0e3f
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:10 2018 -0500

    bnxt_en: Reserve resources for RFS.
    
    In bnxt_rfs_capable(), add call to reserve vnic resources to support
    NTUPLE.  Return true if we can successfully reserve enough vnics.
    Otherwise, reserve the minimum 1 VNIC for normal operations not
    supporting NTUPLE and return false.
    
    Also, suppress warning message about not enough resources for NTUPLE when
    only 1 RX ring is in use.  NTUPLE filters by definition require multiple
    RX rings.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 674f50a5b026151f4109992cb594d89f5334adde
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:09 2018 -0500

    bnxt_en: Implement new method to reserve rings.
    
    The new method will call firmware to reserve the desired tx, rx, cmpl
    rings, ring groups, stats context, and vnic resources.  A second query
    call will check the actual resources that firmware is able to reserve.
    The driver will then trim and adjust based on the actual resources
    provided by firmware.  The driver will then reserve the final resources
    in use.
    
    This method is a more flexible way of using hardware resources.  The
    resources are not fixed and can by adjusted by firmware.  The driver
    adapts to the available resources that the firmware can reserve for
    the driver.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 58ea801ac4c166cdcaa399ce7f9b3e9095ff2842
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:08 2018 -0500

    bnxt_en: Set initial default RX and TX ring numbers the same in combined mode.
    
    In combined mode, the driver is currently not setting RX and TX ring
    numbers the same when firmware can allocate more RX than TX or vice versa.
    This will confuse the user as the ethtool convention assumes they are the
    same in combined mode.  Fix it by adding bnxt_trim_dflt_sh_rings() to trim
    RX and TX ring numbers to be the same as the completion ring number in
    combined mode.
    
    Note that if TCs are enabled and/or XDP is enabled, the number of TX rings
    will not be the same as RX rings in combined mode.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit be0dd9c4100c9549fe50258e3d928072e6c31590
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:07 2018 -0500

    bnxt_en: Add the new firmware API to query hardware resources.
    
    The new API HWRM_FUNC_RESOURCE_QCAPS provides min and max hardware
    resources.  Use the new API when it is supported by firmware.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 6a4f29470569c5a158c1871a2f752ca22e433420
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:06 2018 -0500

    bnxt_en: Refactor hardware resource data structures.
    
    In preparation for new firmware APIs to allocate hardware resources,
    add a new struct bnxt_hw_resc to hold various min, max and reserved
    resources.  This new structure is common for PFs and VFs.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 80fcaf46c09262a71f32bb577c976814c922f864
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:05 2018 -0500

    bnxt_en: Restore MSIX after disabling SRIOV.
    
    After SRIOV has been enabled and disabled, the MSIX vectors assigned to
    the VFs have to be re-initialized.  Otherwise they cannot be re-used by
    the PF.  For example, increasing the number of PF rings after disabling
    SRIOV may fail if the PF uses MSIX vectors previously assigned to the VFs.
    
    To fix this, we add logic in bnxt_restore_pf_fw_resources() to close the
    NIC, clear and re-init MSIX, and re-open the NIC.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 86e953db0114f396f916344395160aa267bf2627
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:04 2018 -0500

    bnxt_en: Refactor bnxt_close_nic().
    
    Add a new __bnxt_close_nic() function to do all the work previously done
    in bnxt_close_nic() except waiting for SRIOV configuration.  The new
    function will be used in the next patch as part of SRIOV cleanup.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 894aa69a90932907f3de9d849ab9970884151d0e
Author: Michael Chan <[email protected]>
Date:   Wed Jan 17 03:21:03 2018 -0500

    bnxt_en: Update firmware interface to 1.9.0.
    
    The version has new firmware APIs to allocate PF/VF resources more
    flexibly.
    
    New toolchains were used to generate this file, resulting in a one-time
    large diffstat.
    
    Signed-off-by: Michael Chan <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 4ec1dea0b2d2404200c348517bfca8b72037632d
Author: Bjorn Helgaas <[email protected]>
Date:   Tue Jan 16 17:37:50 2018 -0600

    PCI/DPC: Add and use DPC Status register field definitions
    
    Add definitions for DPC Status register fields and use them in the code.
    No functional change intended.
    
    Signed-off-by: Bjorn Helgaas <[email protected]>

commit fb7d38a70e1d8ffd54f7a7464dcc4889d7e490ad
Author: Martin Blumenstingl <[email protected]>
Date:   Mon Jan 15 18:10:15 2018 +0100

    net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock
    
    On Meson8b the only valid input clock is MPLL2. The bootloader
    configures that to run at 500002394Hz which cannot be divided evenly
    down to 125MHz using the m250_div clock. Currently the common clock
    framework chooses a m250_div of 2 - with the internal fixed
    "divide by 10" this results in a RGMII TX clock of 125001197Hz (120Hz
    above the requested 125MHz).
    
    Letting the common clock framework propagate the rate changes up to the
    parent of m250_mux allows us to get the best possible clock rate. With
    this patch the common clock framework calculates a rate of
    very-close-to-250MHz (249999701Hz to be exact) for the MPLL2 clock
    (which is the mux input). Dividing that by 2 (which is an internal,
    fixed divider for the RGMII TX clock) gives us an RGMII TX clock of
    124999850Hz (which is only 150Hz off the requested 125MHz, compared to
    1197Hz based on the MPLL2 rate set by u-boot and the Amlogic GPL kernel
    sources).
    
    SoCs from the Meson GX series are not affected by this change because
    the input clock is FCLK_DIV2 whose rate cannot be changed (which is fine
    since it's running at 1GHz, so it's already a multiple of 250MHz and
    125MHz).
    
    Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
    Suggested-by: Jerome Brunet <[email protected]>
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Reviewed-by: Jerome Brunet <[email protected]>
    Tested-by: Jerome Brunet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 433c6cab9d298687c097f6ee82e49157044dc7c6
Author: Martin Blumenstingl <[email protected]>
Date:   Mon Jan 15 18:10:14 2018 +0100

    net: stmmac: dwmac-meson8b: fix setting the RGMII TX clock on Meson8b
    
    Meson8b only supports MPLL2 as clock input. The rate of the MPLL2 clock
    set by Odroid-C1's u-boot is close to (but not exactly) 500MHz. The
    exact rate is 500002394Hz, which is calculated in
    drivers/clk/meson/clk-mpll.c using the following formula:
    DIV_ROUND_UP_ULL((u64)parent_rate * SDM_DEN, (SDM_DEN * n2) + sdm)
    Odroid-C1's u-boot configures MPLL2 with the following values:
    - SDM_DEN = 16384
    - SDM = 1638
    - N2 = 5
    
    The 250MHz clock (m250_div) inside dwmac-meson8b driver is derived from
    the MPLL2 clock. Due to MPLL2 running slightly faster than 500MHz the
    common clock framework chooses a divider which is too big to generate
    the 250MHz clock (a divider of 2 would be needed, but this is rounded up
    to a divider of 3). This breaks the RTL8211F RGMII PHY on Odroid-C1
    because it requires a (close to) 125MHz RGMII TX clock (on Gbit speeds,
    the IP block internally divides that down to 25MHz on 100Mbit/s
    connections and 2.5MHz on 10Mbit/s connections - we don't need any
    special configuration for that).
    
    Round the divider to the closest value to prevent this issue on Meson8b.
    This means we'll now end up with a clock rate for the RGMII TX clock of
    125001197Hz (= 125MHz plus 1197Hz), which is close-enough to 125MHz.
    This has no effect on the Meson GX SoCs since there fclk_div2 is used as
    input clock, which has a rate of 1000MHz (and thus is divisible cleanly
    to 250MHz and 125MHz).
    
    Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
    Reported-by: Emiliano Ingrassia <[email protected]>
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Reviewed-by: Jerome Brunet <[email protected]>
    Tested-by: Jerome Brunet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 4f6a71b84e1afdf13827741e7421a844203cf8d0
Author: Martin Blumenstingl <[email protected]>
Date:   Mon Jan 15 18:10:13 2018 +0100

    net: stmmac: dwmac-meson8b: fix internal RGMII clock configuration
    
    Tests (using an oscilloscope and an Odroid-C1 board with a RTL8211F
    RGMII PHY) have shown that the PRG_ETH0 register behaves as follows:
    - bit 4 is a mux to choose between two parent clocks. according to the
      public S805 datasheet the only supported parent clock is MPLL2 (this
      was not verified using the oscilloscope).
      The public S805/S905 datasheet claims that this bit is reserved.
    - bits 9:7 control a one-based divider (register value 1 means "divide
      by 1", etc.) for the input clock. we call this clock the "m250_div"
      clock because it's value is always supposed to be (close to) 250MHz
      (see below for an explanation).
      The description in the public S805/S905 datasheet is a bit cryptic,
      but it comes down to "input clock = 250MHz * value" (which could also
      be expressed as "250MHz = input clock / value")
    - there seems to be an internal fixed divide-by-2 clock which takes the
      output from the m250_div and divides it by 2. This is not unusual on
      Amlogic SoCs, since the SDIO (MMC) driver also uses an internal fixed
      divide-by-2 clock.
      This is not documented in the public S805/S905 datasheet
    - bit 10 controls a gate clock which enables or disables the RGMII TX
      clock (which is an output on the MAC/SoC and an input in the PHY). we
      call this the "rgmii_tx_en" clock. if this bit is set to "0" the RGMII
      TX clock output is close to 0
      The description for this bit in the public S805/S905 datasheet is
      "Generate 25MHz clock for PHY". Based on these tests it's believed
      that this is wrong, and should probably read "Generate the 125MHz
      RGMII TX clock for the PHY"
    - the RGMII TX clock has to be set to 125MHz - the IP block adjusts the
      output (automatically) depending on the line speed (RGMII specifies
      that Gbit connections use a 125MHz clock, 100Mbit/s connections use a
      25MHz clock and 10Mbit/s connections use a 2.5MHz clock. only Gbit and
      100Mbit/s were tested with an oscilloscope). Due to the requirement
      that this clock always has to be set to 125MHz and due to the fixed
      divide-by-2 parent clock this means that m250_div will always end up
      with a rate of (close to) 250MHz.
    - bits 6:5 are the TX delay, which is also named "clock phase" in some
      of Amlogic's older GPL kernel sources.
    
    The PHY also has an XTAL_IN pin where a 25MHz clock has to be provided.
    Tests with the oscilloscope have shown that this is routed to a crystal
    right next to the RTL8211F PHY. The same seems to be true on the Khadas
    VIM2 (which uses a GXM SoC) board - however the 25MHz crystal is on the
    other side of the PCB there.
    
    This updates the clocks in the dwmac-meson8b driver by replacing the
    "m25_div" with the "rgmii_tx_en" clock and additionally introducing a
    fixed divide-by-2 clock between "m250_div" and "rgmii_tx_en".
    Now we also need to set a frequency of 125MHz on the RGMII clock
    (opposed to the 25MHz we set before, with that non-existing
    divide-by-5-or-10 divider).
    
    Special thanks go to Linus Lüssing for testing the various bits and
    checking the results with an oscilloscope on his Odroid-C1!
    
    Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
    Reported-by: Emiliano Ingrassia <[email protected]>
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Acked-by: Jerome Brunet <[email protected]>
    Tested-by: Jerome Brunet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 37512b42f082d784a012c3734ef109f25d199786
Author: Martin Blumenstingl <[email protected]>
Date:   Mon Jan 15 18:10:12 2018 +0100

    net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode
    
    Neither the m25_div_clk nor the m250_div_clk or m250_mux_clk are used in
    RMII mode. The m25_div_clk output is routed to the RGMII PHY's "RGMII
    clock".
    This means that we don't need to configure the clocks in RMII mode. The
    driver however did this - with no effect since the clocks are not routed
    to the PHY in RMII mode.
    
    While here also rename meson8b_init_clk to meson8b_init_rgmii_tx_clk to
    make it easier to understand the code.
    
    Fixes: 566e8251625304 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
    Signed-off-by: Martin Blumenstingl <[email protected]>
    Tested-by: Jerome Brunet <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit 091f02483df7b56615b524491f404e574c5e0668
Author: Russell King <[email protected]>
Date:   Sat Jan 13 12:11:26 2018 +0000

    ARM: net: bpf: clarify tail_call index
    
    As per 90caccdd8cc0 ("bpf: fix bpf_tail_call() x64 JIT"), the index used
    for array lookup is defined to be 32-bit wide. Update a misleading
    comment that suggests it is 64-bit wide.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit ec19e02b343db991d2d1610c409efefebf4e2ca9
Author: Russell King <[email protected]>
Date:   Sat Jan 13 21:06:16 2018 +0000

    ARM: net: bpf: fix LDX instructions
    
    When the source and destination register are identical, our JIT does not
    generate correct code, which leads to kernel oopses.
    
    Fix this by (a) generating more efficient code, and (b) making use of
    the temporary earlier if we will overwrite the address register.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit 02088d9b392f605c892894b46aa8c83e3abd0115
Author: Russell King <[email protected]>
Date:   Sat Jan 13 22:38:18 2018 +0000

    ARM: net: bpf: fix register saving
    
    When an eBPF program tail-calls another eBPF program, it enters it after
    the prologue to avoid having complex stack manipulations.  This can lead
    to kernel oopses, and similar.
    
    Resolve this by always using a fixed stack layout, a CPU register frame
    pointer, and using this when reloading registers before returning.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit 0005e55a79cfda88199e41a406a829c88d708c67
Author: Russell King <[email protected]>
Date:   Sat Jan 13 22:51:27 2018 +0000

    ARM: net: bpf: correct stack layout documentation
    
    The stack layout documentation incorrectly suggests that the BPF JIT
    scratch space starts immediately below BPF_FP. This is not correct,
    so let's fix the documentation to reflect reality.
    
    Signed-off-by: Russell King <[email protected]>

commit 70ec3a6c2c11e4b0e107a65de943a082f9aff351
Author: Russell King <[email protected]>
Date:   Sat Jan 13 21:26:14 2018 +0000

    ARM: net: bpf: move stack documentation
    
    Move the stack documentation towards the top of the file, where it's
    relevant for things like the register layout.
    
    Signed-off-by: Russell King <[email protected]>

commit d1220efd23484c72c82d5471f05daeb35b5d1916
Author: Russell King <[email protected]>
Date:   Sat Jan 13 16:10:07 2018 +0000

    ARM: net: bpf: fix stack alignment
    
    As per 2dede2d8e925 ("ARM EABI: stack pointer must be 64-bit aligned
    after a CPU exception") the stack should be aligned to a 64-bit boundary
    on EABI systems.  Ensure that the eBPF JIT appropraitely aligns the
    stack.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit f4483f2cc1fdc03488c8a1452e545545ae5bda93
Author: Russell King <[email protected]>
Date:   Sat Jan 13 11:39:54 2018 +0000

    ARM: net: bpf: fix tail call jumps
    
    When a tail call fails, it is documented that the tail call should
    continue execution at the following instruction.  An example tail call
    sequence is:
    
      12: (85) call bpf_tail_call#12
      13: (b7) r0 = 0
      14: (95) exit
    
    The ARM assembler for the tail call in this case ends up branching to
    instruction 14 instead of instruction 13, resulting in the BPF filter
    returning a non-zero value:
    
      178:  ldr     r8, [sp, #588]  ; insn 12
      17c:  ldr     r6, [r8, r6]
      180:  ldr     r8, [sp, #580]
      184:  cmp     r8, r6
      188:  bcs     0x1e8
      18c:  ldr     r6, [sp, #524]
      190:  ldr     r7, [sp, #528]
      194:  cmp     r7, #0
      198:  cmpeq   r6, #32
      19c:  bhi     0x1e8
      1a0:  adds    r6, r6, #1
      1a4:  adc     r7, r7, #0
      1a8:  str     r6, [sp, #524]
      1ac:  str     r7, [sp, #528]
      1b0:  mov     r6, #104
      1b4:  ldr     r8, [sp, #588]
      1b8:  add     r6, r8, r6
      1bc:  ldr     r8, [sp, #580]
      1c0:  lsl     r7, r8, #2
      1c4:  ldr     r6, [r6, r7]
      1c8:  cmp     r6, #0
      1cc:  beq     0x1e8
      1d0:  mov     r8, #32
      1d4:  ldr     r6, [r6, r8]
      1d8:  add     r6, r6, #44
      1dc:  bx      r6
      1e0:  mov     r0, #0          ; insn 13
      1e4:  mov     r1, #0
      1e8:  add     sp, sp, #596    ; insn 14
      1ec:  pop     {r4, r5, r6, r7, r8, sl, pc}
    
    For other sequences, the tail call could end up branching midway through
    the following BPF instructions, or maybe off the end of the function,
    leading to unknown behaviours.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit e9062481824384f00299971f923fecf6b3668001
Author: Russell King <[email protected]>
Date:   Sat Jan 13 11:35:15 2018 +0000

    ARM: net: bpf: avoid 'bx' instruction on non-Thumb capable CPUs
    
    Avoid the 'bx' instruction on CPUs that have no support for Thumb and
    thus do not implement this instruction by moving the generation of this
    opcode to a separate function that selects between:
    
            bx      reg
    
    and
    
            mov     pc, reg
    
    according to the capabilities of the CPU.
    
    Fixes: 39c13c204bb1 ("arm: eBPF JIT compiler")
    Signed-off-by: Russell King <[email protected]>

commit 416ef9b15c688b91edbf654ebe7bc349c9151147
Author: Jakub Kicinski <[email protected]>
Date:   Sun Jan 14 20:01:26 2018 -0800

    net: sched: red: don't reset the backlog on every stat dump
    
    Commit 0dfb33a0d7e2 ("sch_red: report backlog information") copied
    child's backlog into RED's backlog.  Back then RED did not maintain
    its own backlog counts.  This has changed after commit 2ccccf5fb43f
    ("net_sched: update hierarchical backlog too") and commit d7f4f332f082
    ("sch_red: update backlog as well").  Copying is no longer necessary.
    
    Tested:
    
    $ tc -s qdisc show dev veth0
    qdisc red 1: root refcnt 2 limit 400000b min 30000b max 30000b ecn
     Sent 20942 bytes 221 pkt (dropped 0, overlimits 0 requeues 0)
     backlog 1260b 14p requeues 14
      marked 0 early 0 pdrop 0 other 0
    qdisc tbf 2: parent 1: rate 1Kbit burst 15000b lat 3585.0s
     Sent 20942 bytes 221 pkt (dropped 0, overlimits 138 requeues 0)
     backlog 1260b 14p requeues 14
    
    Recently RED offload was added.  We need to make sure drivers don't
    depend on resetting the stats.  This means backlog should be treated
    like any other statistic:
    
      total_stat = new_hw_stat - prev_hw_stat;
    
    Adjust mlxsw.
    
    Signed-off-by: Jakub Kicinski <[email protected]>
    Acked-by: Nogah Frankel <[email protected]>
    Acked-by: Jiri Pirko <[email protected]>
    Signed-off-by: David S. Miller <[email protected]>

commit c0e860ba034ead2a0f47052c87266e90f23cdb7b
Author: Jeff Westfahl <[email protected]>
Date:   Tue Jan 10 13:30:18 2017 -0600

    mtd: ubi: Use 'max_bad_blocks' to compute bad_peb_limit if available
    
    If the user has not set max_beb_per1024 using either the cmdline or
    Kconfig options for doing so, use the MTD function 'max_bad_blocks' to
    compute the UBI bad_peb_limit.
    
    Signed-off-by: Jeff Westfahl <[email protected]>
    Signed-off-by: Zach Brown <[email protected]>
    Acked-by: Boris Brezillon <[email protected]>
    Acked-by: Richard Weinberger <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit c877154d307f4a91e0b5b85b75535713dab945ae
Author: Geert Uytterhoeven <[email protected]>
Date:   Sun Sep 17 10:32:20 2017 +0200

    ubifs: Fix uninitialized variable in search_dh_cookie()
    
    fs/ubifs/tnc.c: In function ‘search_dh_cookie’:
    fs/ubifs/tnc.c:1893: warning: ‘err’ is used uninitialized in this function
    
    Indeed, err is always used uninitialized.
    
    According to an original review comment from Hyunchul, acknowledged by
    Richard, err should be initialized to -ENOENT to avoid the first call to
    tnc_next().  But we can achieve the same by reordering the code.
    
    Fixes: 781f675e2d7e ("ubifs: Fix unlink code wrt. double hash lookups")
    Reported-by: Hyunchul Lee <[email protected]>
    Signed-off-by: Geert Uytterhoeven <[email protected]>
    Signed-off-by: Richard Weinberger <[email protected]>

commit 698c03b4745006e14eccb8270f714d52fac1c97e
Author: Julia Lawall <[email protected]>
Date:   Tue Jan 16 16:56:54 2018 -0800

    Input: inline macros for MODULE_LICENSE, etc
    
    Inline macro for MODULE_LICENSE to make the license information easy to
    find, eg with grep.  Inline the other module-related macros at the same
    time.
    
    A simplified version of the semantic patch for the MODULE_LICENSE
    case is as follows: (http://coccinelle.lip6.fr/)
    
    // <smpl>
    @s@
    identifier i; expression e;
    @@
    
    @@
    declarer name MODULE_LICENSE;
    identifier s.i;
    expression s.e;
    @@
    MODULE_LICENSE(
    - i
    + e
     );
    // </smpl>
    
    Signed-off-by: Julia Lawall <[email protected]>
    [dtor: added a couple of drivers missed by the script, removed a few unused
     DRIVER_VERSION macros]
    Signed-off-by: Dmitry Torokhov <[email protected]>

commit 75ea1aabdba38daaeaaa4e5922ac85907b0a68b0
Author: Ulf Magnusson <[email protected]>
Date:   Sun Jan 14 10:56:20 2018 +0100

    kconfig: Document SYMBOL_OPTIONAL logic
    
    Not obvious, especially if you don't already know how choices are
    implemented.
    
    No functional changes. Only comments added.
    
    Signed-off-by: Ulf Magnusson <[email protected]>
    Signed-off-by: Masahiro Yamada <[email protected]>

commit 9afcc6e739403694593a6cdfde09d87f0c2c81b1
Author: Masahiro Yamada <[email protected]>
Date:   Fri Jan 12 00:51:52 2018 +0900

    kbuild: remove unnecessary LEX_PREFIX and YACC_PREFIX
    
    Kconfig was the only user of these.  With Kconfig converted to use
    the default 'yy' prefix, we do not need them any more.
    
    Signed-off-by: Masahiro Yamada <[email protected]>
    Reviewed-by: Ulf Magnusson <[email protected]>

commit bb6e15ae0127436cf4cbc10e7f82696538b7cabc
Author: Masahiro Yamada <[email protected]>
Date:   Fri Jan 12 00:50:50 2018 +0900

    kconfig: use default 'yy' prefix for lexer and parser
    
    Flex and Bison provide an option to change the prefix of globally-
    visible symbols.  This is useful to link multiple lexers and/or
    parsers into the same executable.  However, Kconfig (and any other
    host programs in kernel) uses a single lexer and parser.  I do not
    see a good reason to change the default 'yy' prefix.
    
    Signed-off-by: Masahiro Yamada <[email protected]>
    Reviewed-by: Ulf Magnusson <[email protected]>

commit de99a346884f019387230bc549de74456daca248
Author: Bart Van Assche <[email protected]>
Date:   Tue Jan 16 10:31:39 2018 -0800

    block: Fix __bio_integrity_endio() documentation
    
    Fixes: 4246a0b63bd8 ("block: add a bi_error field to struct bio")
    Reviewed-by: Martin K. Petersen <[email protected]>
    Signed-off-by: Bart Van Assche <[email protected]>
    Signed-off-by: Jens Axboe <[email protected]>

commit 5badd82f5ac0a2945914e6fe973cd79ec63c3c2f
Author: Masahiro Yamada <[email protected]>
Date:   Thu Jan 11 22:39:41 2018 +0900

    kconfig: make conf_unsaved a local variable of conf_read()
    
    conf_unsaved is initialized by conf_read_simple(), but it is possible
    to move it to conf_read() so that it can be a local variable.
    
    Signed-off-by: Masahiro Yamada <[email protected]>

commit d7daabf8e860fd0a9c2f8a3acac09ff2d4375fd2
Author: Masahiro Yamada <[email protected]>
Date:   Thu Jan 11 22:39:40 2018 +0900

    kconfig: make xfgets() really static
    
    Sparse reports:
      warning: symbol 'xfgets' was not declared. Should it be static?
    
    It is declared as static, but it is missing in the definition part.
    Move the definition up and remove the forward declaration.
    
    Signed-off-by: Masahiro Yamada <[email protected]>

commit 1c884d196f50442206f4f4797123062da4ff8a62
Author: Masahiro Yamada <[email protected]>
Date:   Thu Jan 11 22:39:39 2018 +0900

    kconfig: make input_mode static
    
    Sparse reports:
      warning: symbol 'input_mode' was not declared. Should it be static?
    
    Signed-off-by: Masahiro Yamada <[email protected]>

commit 4c93867aeb260b01a7983f9aaff39b61067dea97
Author: Lucas Stach <[email protected]>
Date:   Wed Dec 6 10:53:27 2017 +0100

    drm/etnaviv: replace hangcheck with scheduler timeout
    
    This replaces the etnaviv internal hangcheck logic with the job timeout
    handling provided by the DRM scheduler. This simplifies the driver further
    and allows to replay jobs after a GPU reset, so only minimal state is lost.
    
    This introduces a user-visible change in that we don't allow jobs to run
    indefinitely as long as they make progress anymore, as this introduces
    quality of service issues when multiple processes are using the GPU.
    Userspace is now responsible to flush jobs in a way that the finish in a
    reasonable time, where reasonable is currently defined as less than 500ms.
    
    Signed-off-by: Lucas Stach <[email protected]>

commit a5a76c4b88c8fa50ae58fd55f023116a04cb6e70
Author: Lucas Stach <[email protected]>
Date:   Tue Dec 5 10:55:02 2017 +0100

    drm/etnaviv: lock BOs after all other submit work is done
    
    Populating objects, adding them to the GPU VM and patching/validating
    the command stream might take a lot of CPU time. There is no reason to
    hold all object reservations during that time.
    
    Signed-off-by: Lucas Stach <[email protected]>

commit b98a98076f6951408e054247e32951cf858d5772
Author: Lucas Stach <[email protected]>
Date:   Mon Dec 4 19:24:06 2017 +0100

    drm/etnaviv: move dependency handling to scheduler
    
    Move the fence dependency handling to the scheduler where it belongs.
    Jobs with unsignaled dependencies just get to sit in the scheduler queue
    without holding any locks.
    
    Signed-off-by: Lucas Stach <[email protected]>

commit 2ffdcf4aca80379a99386b750b0fc8a80e62d702
Author: Lucas Stach <[email protected]>
Date:   Mon Dec 4 18:41:58 2017 +0100

    drm/etnaviv: hook up DRM GPU scheduler
    
    This hooks in the DRM GPU scheduler. No improvement yet, as all the
    dependency handling is still done in etnaviv_gem_submit. This just
    replaces the actual GPU submit by passing through the scheduler.
    
    Allows to get rid of the retire worker, as this is now driven by the
    scheduler.
    
    Signed-off-by: Lucas Stach <[email protected]>

commit 9e97d2951a7e6ee6e204f87f6bda4ff754a8cede
Author: Mike Snitzer <[email protected]>
Date:   Wed Jan 17 11:25:58 2018 -0500

    blk-mq-sched: remove unused 'can_block' arg from blk_mq_sched_insert_request
    
    After commit:
    
    923218f6166a ("blk-mq: don't allocate driver tag upfront for flush rq")
    
    we no longer use the 'can_block' argument in
    blk_mq_sched_insert_request(). Kill it.
    
    Signed-off-by: Mike Snitzer <[email protected]>
    
    Added actual commit message as to why it's being removed.
    
    Signed-off-by: Jens Axboe <[email protected]>

commit 47b8e8ce7ddc72710feda874bb9732a3c2156204
Author: Lucas Stach <[email protected]>
Date:   Wed Nov 29 14:49:04 2017 +0100

    drm/etnaviv: track fences by IDR instead of seqno
    
    This moves away from using the internal seqno as the userspace fence
    reference. By moving to a generic ID, we can later replace the internal
    fence by something different than the etnaviv seqno fence.
    
    Signed-off-by: Lucas Stach <[email protected]>
    Reviewed-by: Philipp Zabel <[email protected]>

commit 82fc7a3eea66fec5c8a3eaaaaac9fd88f8ab5a31
Author: Lucas Stach <[email protected]>
Date:   Thu Jan 4 13:50:14 2018 +0100

    drm/etnaviv: add missing major features field to debugfs
    
    This can be useful when dealing with a new GPU core.
    
    Signed-off-by: Lucas Stach <[email protected]>

commit 16f9560aa73331fb9311418de36b573a1b65d08f
Aut…
otavio referenced this pull request in Freescale/linux-fslc Feb 1, 2018
commit f4483f2 upstream.

When a tail call fails, it is documented that the tail call should
continue execution at the following instruction.  An example tail call
sequence is:

  12: (85) call bpf_tail_call#12
  13: (b7) r0 = 0
  14: (95) exit

The ARM assembler for the tail call in this case ends up branching to
instruction 14 instead of instruction 13, resulting in the BPF filter
returning a non-zero value:

  178:	ldr	r8, [sp, #588]	; insn 12
  17c:	ldr	r6, [r8, r6]
  180:	ldr	r8, [sp, #580]
  184:	cmp	r8, r6
  188:	bcs	0x1e8
  18c:	ldr	r6, [sp, #524]
  190:	ldr	r7, [sp, #528]
  194:	cmp	r7, #0
  198:	cmpeq	r6, #32
  19c:	bhi	0x1e8
  1a0:	adds	r6, r6, #1
  1a4:	adc	r7, r7, #0
  1a8:	str	r6, [sp, #524]
  1ac:	str	r7, [sp, #528]
  1b0:	mov	r6, #104
  1b4:	ldr	r8, [sp, #588]
  1b8:	add	r6, r8, r6
  1bc:	ldr	r8, [sp, #580]
  1c0:	lsl	r7, r8, #2
  1c4:	ldr	r6, [r6, r7]
  1c8:	cmp	r6, #0
  1cc:	beq	0x1e8
  1d0:	mov	r8, #32
  1d4:	ldr	r6, [r6, r8]
  1d8:	add	r6, r6, #44
  1dc:	bx	r6
  1e0:	mov	r0, #0		; insn 13
  1e4:	mov	r1, #0
  1e8:	add	sp, sp, #596	; insn 14
  1ec:	pop	{r4, r5, r6, r7, r8, sl, pc}

For other sequences, the tail call could end up branching midway through
the following BPF instructions, or maybe off the end of the function,
leading to unknown behaviours.

Fixes: 39c13c2 ("arm: eBPF JIT compiler")
Signed-off-by: Russell King <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
iaguis pushed a commit to kinvolk/linux that referenced this pull request Feb 6, 2018
alaahl pushed a commit to alaahl/linux that referenced this pull request May 13, 2018
This addresses 3 separate problems:

1. When using NVME over Fabrics we may end up sending IP
packets in interrupt context, we should defer this work
to a tasklet.

[   50.939957] WARNING: CPU: 3 PID: 0 at kernel/softirq.c:161 __local_bh_enable_ip+0x1f/0xa0
[   50.942602] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G        W         4.17.0-rc3-ARCH+ torvalds#104
[   50.945466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[   50.948163] RIP: 0010:__local_bh_enable_ip+0x1f/0xa0
[   50.949631] RSP: 0018:ffff88009c183900 EFLAGS: 00010006
[   50.951029] RAX: 0000000080010403 RBX: 0000000000000200 RCX: 0000000000000001
[   50.952636] RDX: 0000000000000000 RSI: 0000000000000200 RDI: ffffffff817e04ec
[   50.954278] RBP: ffff88009c183910 R08: 0000000000000001 R09: 0000000000000614
[   50.956000] R10: ffffea00021d5500 R11: 0000000000000001 R12: ffffffff817e04ec
[   50.957779] R13: 0000000000000000 R14: ffff88009566f400 R15: ffff8800956c7000
[   50.959402] FS:  0000000000000000(0000) GS:ffff88009c180000(0000) knlGS:0000000000000000
[   50.961552] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   50.963798] CR2: 000055c4ec0ccac0 CR3: 0000000002209001 CR4: 00000000000606e0
[   50.966121] Call Trace:
[   50.966845]  <IRQ>
[   50.967497]  __dev_queue_xmit+0x62d/0x690
[   50.968722]  dev_queue_xmit+0x10/0x20
[   50.969894]  neigh_resolve_output+0x173/0x190
[   50.971244]  ip_finish_output2+0x2b8/0x370
[   50.972527]  ip_finish_output+0x1d2/0x220
[   50.973785]  ? ip_finish_output+0x1d2/0x220
[   50.975010]  ip_output+0xd4/0x100
[   50.975903]  ip_local_out+0x3b/0x50
[   50.976823]  rxe_send+0x74/0x120
[   50.977702]  rxe_requester+0xe3b/0x10b0
[   50.978881]  ? ip_local_deliver_finish+0xd1/0xe0
[   50.980260]  rxe_do_task+0x85/0x100
[   50.981386]  rxe_run_task+0x2f/0x40
[   50.982470]  rxe_post_send+0x51a/0x550
[   50.983591]  nvmet_rdma_queue_response+0x10a/0x170
[   50.985024]  __nvmet_req_complete+0x95/0xa0
[   50.986287]  nvmet_req_complete+0x15/0x60
[   50.987469]  nvmet_bio_done+0x2d/0x40
[   50.988564]  bio_endio+0x12c/0x140
[   50.989654]  blk_update_request+0x185/0x2a0
[   50.990947]  blk_mq_end_request+0x1e/0x80
[   50.991997]  nvme_complete_rq+0x1cc/0x1e0
[   50.993171]  nvme_pci_complete_rq+0x117/0x120
[   50.994355]  __blk_mq_complete_request+0x15e/0x180
[   50.995988]  blk_mq_complete_request+0x6f/0xa0
[   50.997304]  nvme_process_cq+0xe0/0x1b0
[   50.998494]  nvme_irq+0x28/0x50
[   50.999572]  __handle_irq_event_percpu+0xa2/0x1c0
[   51.000986]  handle_irq_event_percpu+0x32/0x80
[   51.002356]  handle_irq_event+0x3c/0x60
[   51.003463]  handle_edge_irq+0x1c9/0x200
[   51.004473]  handle_irq+0x23/0x30
[   51.005363]  do_IRQ+0x46/0xd0
[   51.006182]  common_interrupt+0xf/0xf
[   51.007129]  </IRQ>

2. Work must always be offloaded to tasklet for rxe_post_send_kernel()
when using NVMEoF in order to solve lock ordering between neigh->ha_lock
seqlock and the nvme queue lock:

[   77.833783]  Possible interrupt unsafe locking scenario:
[   77.833783]
[   77.835831]        CPU0                    CPU1
[   77.837129]        ----                    ----
[   77.838313]   lock(&(&n->ha_lock)->seqcount);
[   77.839550]                                local_irq_disable();
[   77.841377]                                lock(&(&nvmeq->q_lock)->rlock);
[   77.843222]                                lock(&(&n->ha_lock)->seqcount);
[   77.845178]   <Interrupt>
[   77.846298]     lock(&(&nvmeq->q_lock)->rlock);
[   77.847986]
[   77.847986]  *** DEADLOCK ***

3. Same goes for the lock ordering between sch->q.lock and nvme queue lock:

[   47.634271]  Possible interrupt unsafe locking scenario:
[   47.634271]
[   47.636452]        CPU0                    CPU1
[   47.637861]        ----                    ----
[   47.639285]   lock(&(&sch->q.lock)->rlock);
[   47.640654]                                local_irq_disable();
[   47.642451]                                lock(&(&nvmeq->q_lock)->rlock);
[   47.644521]                                lock(&(&sch->q.lock)->rlock);
[   47.646480]   <Interrupt>
[   47.647263]     lock(&(&nvmeq->q_lock)->rlock);
[   47.648492]
[   47.648492]  *** DEADLOCK ***

Using NVMEoF after this patch seems to finally be stable, without it,
rxe eventually deadlocks the whole system and causes RCU stalls.

Signed-off-by: Alexandru Moise <[email protected]>
Reviewed-by: Zhu Yanjun <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
alaahl pushed a commit to alaahl/linux that referenced this pull request May 17, 2018
This addresses 3 separate problems:

1. When using NVME over Fabrics we may end up sending IP
packets in interrupt context, we should defer this work
to a tasklet.

[   50.939957] WARNING: CPU: 3 PID: 0 at kernel/softirq.c:161 __local_bh_enable_ip+0x1f/0xa0
[   50.942602] CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G        W         4.17.0-rc3-ARCH+ torvalds#104
[   50.945466] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
[   50.948163] RIP: 0010:__local_bh_enable_ip+0x1f/0xa0
[   50.949631] RSP: 0018:ffff88009c183900 EFLAGS: 00010006
[   50.951029] RAX: 0000000080010403 RBX: 0000000000000200 RCX: 0000000000000001
[   50.952636] RDX: 0000000000000000 RSI: 0000000000000200 RDI: ffffffff817e04ec
[   50.954278] RBP: ffff88009c183910 R08: 0000000000000001 R09: 0000000000000614
[   50.956000] R10: ffffea00021d5500 R11: 0000000000000001 R12: ffffffff817e04ec
[   50.957779] R13: 0000000000000000 R14: ffff88009566f400 R15: ffff8800956c7000
[   50.959402] FS:  0000000000000000(0000) GS:ffff88009c180000(0000) knlGS:0000000000000000
[   50.961552] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   50.963798] CR2: 000055c4ec0ccac0 CR3: 0000000002209001 CR4: 00000000000606e0
[   50.966121] Call Trace:
[   50.966845]  <IRQ>
[   50.967497]  __dev_queue_xmit+0x62d/0x690
[   50.968722]  dev_queue_xmit+0x10/0x20
[   50.969894]  neigh_resolve_output+0x173/0x190
[   50.971244]  ip_finish_output2+0x2b8/0x370
[   50.972527]  ip_finish_output+0x1d2/0x220
[   50.973785]  ? ip_finish_output+0x1d2/0x220
[   50.975010]  ip_output+0xd4/0x100
[   50.975903]  ip_local_out+0x3b/0x50
[   50.976823]  rxe_send+0x74/0x120
[   50.977702]  rxe_requester+0xe3b/0x10b0
[   50.978881]  ? ip_local_deliver_finish+0xd1/0xe0
[   50.980260]  rxe_do_task+0x85/0x100
[   50.981386]  rxe_run_task+0x2f/0x40
[   50.982470]  rxe_post_send+0x51a/0x550
[   50.983591]  nvmet_rdma_queue_response+0x10a/0x170
[   50.985024]  __nvmet_req_complete+0x95/0xa0
[   50.986287]  nvmet_req_complete+0x15/0x60
[   50.987469]  nvmet_bio_done+0x2d/0x40
[   50.988564]  bio_endio+0x12c/0x140
[   50.989654]  blk_update_request+0x185/0x2a0
[   50.990947]  blk_mq_end_request+0x1e/0x80
[   50.991997]  nvme_complete_rq+0x1cc/0x1e0
[   50.993171]  nvme_pci_complete_rq+0x117/0x120
[   50.994355]  __blk_mq_complete_request+0x15e/0x180
[   50.995988]  blk_mq_complete_request+0x6f/0xa0
[   50.997304]  nvme_process_cq+0xe0/0x1b0
[   50.998494]  nvme_irq+0x28/0x50
[   50.999572]  __handle_irq_event_percpu+0xa2/0x1c0
[   51.000986]  handle_irq_event_percpu+0x32/0x80
[   51.002356]  handle_irq_event+0x3c/0x60
[   51.003463]  handle_edge_irq+0x1c9/0x200
[   51.004473]  handle_irq+0x23/0x30
[   51.005363]  do_IRQ+0x46/0xd0
[   51.006182]  common_interrupt+0xf/0xf
[   51.007129]  </IRQ>

2. Work must always be offloaded to tasklet for rxe_post_send_kernel()
when using NVMEoF in order to solve lock ordering between neigh->ha_lock
seqlock and the nvme queue lock:

[   77.833783]  Possible interrupt unsafe locking scenario:
[   77.833783]
[   77.835831]        CPU0                    CPU1
[   77.837129]        ----                    ----
[   77.838313]   lock(&(&n->ha_lock)->seqcount);
[   77.839550]                                local_irq_disable();
[   77.841377]                                lock(&(&nvmeq->q_lock)->rlock);
[   77.843222]                                lock(&(&n->ha_lock)->seqcount);
[   77.845178]   <Interrupt>
[   77.846298]     lock(&(&nvmeq->q_lock)->rlock);
[   77.847986]
[   77.847986]  *** DEADLOCK ***

3. Same goes for the lock ordering between sch->q.lock and nvme queue lock:

[   47.634271]  Possible interrupt unsafe locking scenario:
[   47.634271]
[   47.636452]        CPU0                    CPU1
[   47.637861]        ----                    ----
[   47.639285]   lock(&(&sch->q.lock)->rlock);
[   47.640654]                                local_irq_disable();
[   47.642451]                                lock(&(&nvmeq->q_lock)->rlock);
[   47.644521]                                lock(&(&sch->q.lock)->rlock);
[   47.646480]   <Interrupt>
[   47.647263]     lock(&(&nvmeq->q_lock)->rlock);
[   47.648492]
[   47.648492]  *** DEADLOCK ***

Using NVMEoF after this patch seems to finally be stable, without it,
rxe eventually deadlocks the whole system and causes RCU stalls.

Signed-off-by: Alexandru Moise <[email protected]>
Reviewed-by: Zhu Yanjun <[email protected]>
Signed-off-by: Doug Ledford <[email protected]>
mrchapp pushed a commit to mrchapp/linux that referenced this pull request Apr 1, 2020
commit d0bab0c upstream.

On a system with only one CPU online, when another one CPU panics while
starting-up, smp_send_stop() will fail to send any STOP message to the
other already online core, resulting in a system still responsive and
alive at the end of the panic procedure.

[  186.700083] CPU3: shutdown
[  187.075462] CPU2: shutdown
[  187.162869] CPU1: shutdown
[  188.689998] ------------[ cut here ]------------
[  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
[  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[  188.692444] Modules linked in:
[  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104
[  188.693175] Hardware name: Foundation-v8A (DT)
[  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
[  188.694183] pc : has_cpuid_feature+0xf0/0x348
[  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
[  188.694410] sp : ffff800011b1bf60
[  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
[  188.694707] x27: 0000000000000000 x26: 0000000000000000
[  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
[  188.694905] x23: 0000000000000000 x22: 0000000000000000
[  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
[  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
[  188.695187] x17: 0000000000000000 x16: 0000000000000000
[  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
[  188.695371] x13: 0000000000000002 x12: 0000000000002592
[  188.695472] x11: 0000000000000080 x10: 00400032b5503510
[  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
[  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
[  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
[  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
[  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
[  188.696253] Call trace:
[  188.696410]  has_cpuid_feature+0xf0/0x348
[  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
[  188.696591]  check_local_cpu_capabilities+0x44/0x128
[  188.696666]  secondary_start_kernel+0xf4/0x188
[  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
[  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
[  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
[  188.699546] Kernel Offset: disabled
[  188.699828] CPU features: 0x00004,20c02008
[  188.700012] Memory Limit: none
[  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[root@arch ~]# echo Helo
Helo
[root@arch ~]# cat /proc/cpuinfo | grep proce
processor	: 0

Make smp_send_stop() account also for the online status of the calling CPU
while evaluating how many CPUs are effectively online: this way, the right
number of STOPs is sent, so enforcing a proper freeze of the system at the
end of panic even under the above conditions.

Fixes: 08e875c ("arm64: SMP support")
Reported-by: Dave Martin <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Noltari pushed a commit to Noltari/linux that referenced this pull request Apr 2, 2020
commit d0bab0c upstream.

On a system with only one CPU online, when another one CPU panics while
starting-up, smp_send_stop() will fail to send any STOP message to the
other already online core, resulting in a system still responsive and
alive at the end of the panic procedure.

[  186.700083] CPU3: shutdown
[  187.075462] CPU2: shutdown
[  187.162869] CPU1: shutdown
[  188.689998] ------------[ cut here ]------------
[  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
[  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[  188.692444] Modules linked in:
[  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104
[  188.693175] Hardware name: Foundation-v8A (DT)
[  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
[  188.694183] pc : has_cpuid_feature+0xf0/0x348
[  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
[  188.694410] sp : ffff800011b1bf60
[  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
[  188.694707] x27: 0000000000000000 x26: 0000000000000000
[  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
[  188.694905] x23: 0000000000000000 x22: 0000000000000000
[  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
[  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
[  188.695187] x17: 0000000000000000 x16: 0000000000000000
[  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
[  188.695371] x13: 0000000000000002 x12: 0000000000002592
[  188.695472] x11: 0000000000000080 x10: 00400032b5503510
[  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
[  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
[  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
[  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
[  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
[  188.696253] Call trace:
[  188.696410]  has_cpuid_feature+0xf0/0x348
[  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
[  188.696591]  check_local_cpu_capabilities+0x44/0x128
[  188.696666]  secondary_start_kernel+0xf4/0x188
[  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
[  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
[  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
[  188.699546] Kernel Offset: disabled
[  188.699828] CPU features: 0x00004,20c02008
[  188.700012] Memory Limit: none
[  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[root@arch ~]# echo Helo
Helo
[root@arch ~]# cat /proc/cpuinfo | grep proce
processor	: 0

Make smp_send_stop() account also for the online status of the calling CPU
while evaluating how many CPUs are effectively online: this way, the right
number of STOPs is sent, so enforcing a proper freeze of the system at the
end of panic even under the above conditions.

Fixes: 08e875c ("arm64: SMP support")
Reported-by: Dave Martin <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Noltari pushed a commit to Noltari/linux that referenced this pull request Apr 2, 2020
commit d0bab0c upstream.

On a system with only one CPU online, when another one CPU panics while
starting-up, smp_send_stop() will fail to send any STOP message to the
other already online core, resulting in a system still responsive and
alive at the end of the panic procedure.

[  186.700083] CPU3: shutdown
[  187.075462] CPU2: shutdown
[  187.162869] CPU1: shutdown
[  188.689998] ------------[ cut here ]------------
[  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
[  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[  188.692444] Modules linked in:
[  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104
[  188.693175] Hardware name: Foundation-v8A (DT)
[  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
[  188.694183] pc : has_cpuid_feature+0xf0/0x348
[  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
[  188.694410] sp : ffff800011b1bf60
[  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
[  188.694707] x27: 0000000000000000 x26: 0000000000000000
[  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
[  188.694905] x23: 0000000000000000 x22: 0000000000000000
[  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
[  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
[  188.695187] x17: 0000000000000000 x16: 0000000000000000
[  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
[  188.695371] x13: 0000000000000002 x12: 0000000000002592
[  188.695472] x11: 0000000000000080 x10: 00400032b5503510
[  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
[  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
[  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
[  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
[  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
[  188.696253] Call trace:
[  188.696410]  has_cpuid_feature+0xf0/0x348
[  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
[  188.696591]  check_local_cpu_capabilities+0x44/0x128
[  188.696666]  secondary_start_kernel+0xf4/0x188
[  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
[  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
[  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
[  188.699546] Kernel Offset: disabled
[  188.699828] CPU features: 0x00004,20c02008
[  188.700012] Memory Limit: none
[  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[root@arch ~]# echo Helo
Helo
[root@arch ~]# cat /proc/cpuinfo | grep proce
processor	: 0

Make smp_send_stop() account also for the online status of the calling CPU
while evaluating how many CPUs are effectively online: this way, the right
number of STOPs is sent, so enforcing a proper freeze of the system at the
end of panic even under the above conditions.

Fixes: 08e875c ("arm64: SMP support")
Reported-by: Dave Martin <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Noltari pushed a commit to Noltari/linux that referenced this pull request Apr 2, 2020
commit d0bab0c upstream.

On a system with only one CPU online, when another one CPU panics while
starting-up, smp_send_stop() will fail to send any STOP message to the
other already online core, resulting in a system still responsive and
alive at the end of the panic procedure.

[  186.700083] CPU3: shutdown
[  187.075462] CPU2: shutdown
[  187.162869] CPU1: shutdown
[  188.689998] ------------[ cut here ]------------
[  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
[  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[  188.692444] Modules linked in:
[  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104
[  188.693175] Hardware name: Foundation-v8A (DT)
[  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
[  188.694183] pc : has_cpuid_feature+0xf0/0x348
[  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
[  188.694410] sp : ffff800011b1bf60
[  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
[  188.694707] x27: 0000000000000000 x26: 0000000000000000
[  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
[  188.694905] x23: 0000000000000000 x22: 0000000000000000
[  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
[  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
[  188.695187] x17: 0000000000000000 x16: 0000000000000000
[  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
[  188.695371] x13: 0000000000000002 x12: 0000000000002592
[  188.695472] x11: 0000000000000080 x10: 00400032b5503510
[  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
[  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
[  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
[  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
[  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
[  188.696253] Call trace:
[  188.696410]  has_cpuid_feature+0xf0/0x348
[  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
[  188.696591]  check_local_cpu_capabilities+0x44/0x128
[  188.696666]  secondary_start_kernel+0xf4/0x188
[  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
[  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
[  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
[  188.699546] Kernel Offset: disabled
[  188.699828] CPU features: 0x00004,20c02008
[  188.700012] Memory Limit: none
[  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[root@arch ~]# echo Helo
Helo
[root@arch ~]# cat /proc/cpuinfo | grep proce
processor	: 0

Make smp_send_stop() account also for the online status of the calling CPU
while evaluating how many CPUs are effectively online: this way, the right
number of STOPs is sent, so enforcing a proper freeze of the system at the
end of panic even under the above conditions.

Fixes: 08e875c ("arm64: SMP support")
Reported-by: Dave Martin <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
jackpot51 referenced this pull request in pop-os/linux Apr 13, 2020
BugLink: https://bugs.launchpad.net/bugs/1869061

commit d0bab0c upstream.

On a system with only one CPU online, when another one CPU panics while
starting-up, smp_send_stop() will fail to send any STOP message to the
other already online core, resulting in a system still responsive and
alive at the end of the panic procedure.

[  186.700083] CPU3: shutdown
[  187.075462] CPU2: shutdown
[  187.162869] CPU1: shutdown
[  188.689998] ------------[ cut here ]------------
[  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
[  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[  188.692444] Modules linked in:
[  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 #104
[  188.693175] Hardware name: Foundation-v8A (DT)
[  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
[  188.694183] pc : has_cpuid_feature+0xf0/0x348
[  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
[  188.694410] sp : ffff800011b1bf60
[  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
[  188.694707] x27: 0000000000000000 x26: 0000000000000000
[  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
[  188.694905] x23: 0000000000000000 x22: 0000000000000000
[  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
[  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
[  188.695187] x17: 0000000000000000 x16: 0000000000000000
[  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
[  188.695371] x13: 0000000000000002 x12: 0000000000002592
[  188.695472] x11: 0000000000000080 x10: 00400032b5503510
[  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
[  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
[  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
[  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
[  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
[  188.696253] Call trace:
[  188.696410]  has_cpuid_feature+0xf0/0x348
[  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
[  188.696591]  check_local_cpu_capabilities+0x44/0x128
[  188.696666]  secondary_start_kernel+0xf4/0x188
[  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
[  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
[  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
[  188.699546] Kernel Offset: disabled
[  188.699828] CPU features: 0x00004,20c02008
[  188.700012] Memory Limit: none
[  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[root@arch ~]# echo Helo
Helo
[root@arch ~]# cat /proc/cpuinfo | grep proce
processor	: 0

Make smp_send_stop() account also for the online status of the calling CPU
while evaluating how many CPUs are effectively online: this way, the right
number of STOPs is sent, so enforcing a proper freeze of the system at the
end of panic even under the above conditions.

Fixes: 08e875c ("arm64: SMP support")
Reported-by: Dave Martin <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Kamal Mostafa <[email protected]>
lag-linaro pushed a commit to lag-linaro/linux that referenced this pull request Apr 16, 2020
commit d0bab0c upstream.

On a system with only one CPU online, when another one CPU panics while
starting-up, smp_send_stop() will fail to send any STOP message to the
other already online core, resulting in a system still responsive and
alive at the end of the panic procedure.

[  186.700083] CPU3: shutdown
[  187.075462] CPU2: shutdown
[  187.162869] CPU1: shutdown
[  188.689998] ------------[ cut here ]------------
[  188.691645] kernel BUG at arch/arm64/kernel/cpufeature.c:886!
[  188.692079] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[  188.692444] Modules linked in:
[  188.693031] CPU: 3 PID: 0 Comm: swapper/3 Not tainted 5.6.0-rc4-00001-g338d25c35a98 torvalds#104
[  188.693175] Hardware name: Foundation-v8A (DT)
[  188.693492] pstate: 200001c5 (nzCv dAIF -PAN -UAO)
[  188.694183] pc : has_cpuid_feature+0xf0/0x348
[  188.694311] lr : verify_local_elf_hwcaps+0x84/0xe8
[  188.694410] sp : ffff800011b1bf60
[  188.694536] x29: ffff800011b1bf60 x28: 0000000000000000
[  188.694707] x27: 0000000000000000 x26: 0000000000000000
[  188.694801] x25: 0000000000000000 x24: ffff80001189a25c
[  188.694905] x23: 0000000000000000 x22: 0000000000000000
[  188.694996] x21: ffff8000114aa018 x20: ffff800011156a38
[  188.695089] x19: ffff800010c944a0 x18: 0000000000000004
[  188.695187] x17: 0000000000000000 x16: 0000000000000000
[  188.695280] x15: 0000249dbde5431e x14: 0262cbe497efa1fa
[  188.695371] x13: 0000000000000002 x12: 0000000000002592
[  188.695472] x11: 0000000000000080 x10: 00400032b5503510
[  188.695572] x9 : 0000000000000000 x8 : ffff800010c80204
[  188.695659] x7 : 00000000410fd0f0 x6 : 0000000000000001
[  188.695750] x5 : 00000000410fd0f0 x4 : 0000000000000000
[  188.695836] x3 : 0000000000000000 x2 : ffff8000100939d8
[  188.695919] x1 : 0000000000180420 x0 : 0000000000180480
[  188.696253] Call trace:
[  188.696410]  has_cpuid_feature+0xf0/0x348
[  188.696504]  verify_local_elf_hwcaps+0x84/0xe8
[  188.696591]  check_local_cpu_capabilities+0x44/0x128
[  188.696666]  secondary_start_kernel+0xf4/0x188
[  188.697150] Code: 52805001 72a00301 6b01001f 54000ec0 (d4210000)
[  188.698639] ---[ end trace 3f12ca47652f7b72 ]---
[  188.699160] Kernel panic - not syncing: Attempted to kill the idle task!
[  188.699546] Kernel Offset: disabled
[  188.699828] CPU features: 0x00004,20c02008
[  188.700012] Memory Limit: none
[  188.700538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

[root@arch ~]# echo Helo
Helo
[root@arch ~]# cat /proc/cpuinfo | grep proce
processor	: 0

Make smp_send_stop() account also for the online status of the calling CPU
while evaluating how many CPUs are effectively online: this way, the right
number of STOPs is sent, so enforcing a proper freeze of the system at the
end of panic even under the above conditions.

Fixes: 08e875c ("arm64: SMP support")
Reported-by: Dave Martin <[email protected]>
Acked-by: Mark Rutland <[email protected]>
Signed-off-by: Cristian Marussi <[email protected]>
Signed-off-by: Will Deacon <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Change-Id: I0c793f1f6bd21b038a15ef577345432dc4d7e3ca
torvalds pushed a commit that referenced this pull request Jun 11, 2020
While testing io_uring in arm, we found sometimes io_sq_thread() keeps
polling io requests even though there are not inflight io requests in
block layer. After some investigations, found a possible race about
io_kiocb.flags, see below race codes:
  1) in the end of io_write() or io_read()
    req->flags &= ~REQ_F_NEED_CLEANUP;
    kfree(iovec);
    return ret;

  2) in io_complete_rw_iopoll()
    if (res != -EAGAIN)
        req->flags |= REQ_F_IOPOLL_COMPLETED;

In IOPOLL mode, io requests still maybe completed by interrupt, then
above codes are not safe, concurrent modifications to req->flags, which
is not protected by lock or is not atomic modifications. I also had
disassemble io_complete_rw_iopoll() in arm:
   req->flags |= REQ_F_IOPOLL_COMPLETED;
   0xffff000008387b18 <+76>:    ldr     w0, [x19,#104]
   0xffff000008387b1c <+80>:    orr     w0, w0, #0x1000
   0xffff000008387b20 <+84>:    str     w0, [x19,#104]

Seems that the "req->flags |= REQ_F_IOPOLL_COMPLETED;" is  load and
modification, two instructions, which obviously is not atomic.

To fix this issue, add a new iopoll_completed in io_kiocb to indicate
whether io request is completed.

Signed-off-by: Xiaoguang Wang <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
snajpa pushed a commit to vpsfreecz/linux that referenced this pull request Jun 24, 2020
[ Upstream commit 65a6543 ]

While testing io_uring in arm, we found sometimes io_sq_thread() keeps
polling io requests even though there are not inflight io requests in
block layer. After some investigations, found a possible race about
io_kiocb.flags, see below race codes:
  1) in the end of io_write() or io_read()
    req->flags &= ~REQ_F_NEED_CLEANUP;
    kfree(iovec);
    return ret;

  2) in io_complete_rw_iopoll()
    if (res != -EAGAIN)
        req->flags |= REQ_F_IOPOLL_COMPLETED;

In IOPOLL mode, io requests still maybe completed by interrupt, then
above codes are not safe, concurrent modifications to req->flags, which
is not protected by lock or is not atomic modifications. I also had
disassemble io_complete_rw_iopoll() in arm:
   req->flags |= REQ_F_IOPOLL_COMPLETED;
   0xffff000008387b18 <+76>:    ldr     w0, [x19,torvalds#104]
   0xffff000008387b1c <+80>:    orr     w0, w0, #0x1000
   0xffff000008387b20 <+84>:    str     w0, [x19,torvalds#104]

Seems that the "req->flags |= REQ_F_IOPOLL_COMPLETED;" is  load and
modification, two instructions, which obviously is not atomic.

To fix this issue, add a new iopoll_completed in io_kiocb to indicate
whether io request is completed.

Signed-off-by: Xiaoguang Wang <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 9, 2021
This commit fixes the following checkpatch.pl warnings:

    WARNING: do not add new typedefs
    torvalds#19: FILE: hal/HalBtc8723b2Ant.h:19:
    +typedef enum _BT_INFO_SRC_8723B_2ANT {

    WARNING: do not add new typedefs
    torvalds#26: FILE: hal/HalBtc8723b2Ant.h:26:
    +typedef enum _BT_8723B_2ANT_BT_STATUS {

    WARNING: do not add new typedefs
    torvalds#36: FILE: hal/HalBtc8723b2Ant.h:36:
    +typedef enum _BT_8723B_2ANT_COEX_ALGO {

    WARNING: do not add new typedefs
    torvalds#51: FILE: hal/HalBtc8723b2Ant.h:51:
    +typedef struct _COEX_DM_8723B_2ANT {

    WARNING: do not add new typedefs
    torvalds#104: FILE: hal/HalBtc8723b2Ant.h:104:
    +typedef struct _COEX_STA_8723B_2ANT {

Signed-off-by: Marco Cesati <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 10, 2021
This commit fixes the following checkpatch.pl warnings:

    WARNING: do not add new typedefs
    torvalds#19: FILE: hal/HalBtc8723b2Ant.h:19:
    +typedef enum _BT_INFO_SRC_8723B_2ANT {

    WARNING: do not add new typedefs
    torvalds#26: FILE: hal/HalBtc8723b2Ant.h:26:
    +typedef enum _BT_8723B_2ANT_BT_STATUS {

    WARNING: do not add new typedefs
    torvalds#36: FILE: hal/HalBtc8723b2Ant.h:36:
    +typedef enum _BT_8723B_2ANT_COEX_ALGO {

    WARNING: do not add new typedefs
    torvalds#51: FILE: hal/HalBtc8723b2Ant.h:51:
    +typedef struct _COEX_DM_8723B_2ANT {

    WARNING: do not add new typedefs
    torvalds#104: FILE: hal/HalBtc8723b2Ant.h:104:
    +typedef struct _COEX_STA_8723B_2ANT {

Signed-off-by: Marco Cesati <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 15, 2021
This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #70: FILE: ./hal/hal_btcoex.c:70:
    +static u8 halbtcoutsrc_IsBtCoexistAvailable(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#104: FILE: ./hal/hal_btcoex.c:104:
    +static void halbtcoutsrc_LeaveLps(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#117: FILE: ./hal/hal_btcoex.c:117:
    +static void halbtcoutsrc_EnterLps(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#130: FILE: ./hal/hal_btcoex.c:130:
    +static void halbtcoutsrc_NormalLps(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#152: FILE: ./hal/hal_btcoex.c:152:
    +static void halbtcoutsrc_LeaveLowPower(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#187: FILE: ./hal/hal_btcoex.c:187:
    +static void halbtcoutsrc_NormalLowPower(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#196: FILE: ./hal/hal_btcoex.c:196:
    +static void halbtcoutsrc_DisableLowPower(struct BTC_COEXIST * pBtCoexist, u8 bLowPwrDisable)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#205: FILE: ./hal/hal_btcoex.c:205:
    +static void halbtcoutsrc_AggregationCheck(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#283: FILE: ./hal/hal_btcoex.c:283:
    +static u32 halbtcoutsrc_GetWifiLinkStatus(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#311: FILE: ./hal/hal_btcoex.c:311:
    +static u32 halbtcoutsrc_GetBtPatchVer(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#342: FILE: ./hal/hal_btcoex.c:342:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#448: FILE: ./hal/hal_btcoex.c:448:
    +			struct RT_LINK_DETECT_T * plinkinfo;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#510: FILE: ./hal/hal_btcoex.c:510:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#645: FILE: ./hal/hal_btcoex.c:645:
    +static void halbtcoutsrc_DisplayFwPwrModeCmd(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#661: FILE: ./hal/hal_btcoex.c:661:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#673: FILE: ./hal/hal_btcoex.c:673:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#685: FILE: ./hal/hal_btcoex.c:685:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#697: FILE: ./hal/hal_btcoex.c:697:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#709: FILE: ./hal/hal_btcoex.c:709:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#749: FILE: ./hal/hal_btcoex.c:749:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#761: FILE: ./hal/hal_btcoex.c:761:
    +	struct BTC_COEXIST *	pBtCoexist = (struct BTC_COEXIST *)pBtcContext;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#772: FILE: ./hal/hal_btcoex.c:772:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #785: FILE: ./hal/hal_btcoex.c:785:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#797: FILE: ./hal/hal_btcoex.c:797:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#809: FILE: ./hal/hal_btcoex.c:809:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#821: FILE: ./hal/hal_btcoex.c:821:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#857: FILE: ./hal/hal_btcoex.c:857:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#869: FILE: ./hal/hal_btcoex.c:869:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#891: FILE: ./hal/hal_btcoex.c:891:
    +	struct BTC_COEXIST *		pBtCoexist = &GLBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#917: FILE: ./hal/hal_btcoex.c:917:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#963: FILE: ./hal/hal_btcoex.c:963:
    +void EXhalbtcoutsrc_PowerOnSetting(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#975: FILE: ./hal/hal_btcoex.c:975:
    +void EXhalbtcoutsrc_InitHwConfig(struct BTC_COEXIST * pBtCoexist, u8 bWifiOnly)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#988: FILE: ./hal/hal_btcoex.c:988:
    +void EXhalbtcoutsrc_InitCoexDm(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#1003: FILE: ./hal/hal_btcoex.c:1003:
    +void EXhalbtcoutsrc_IpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#1030: FILE: ./hal/hal_btcoex.c:1030:
    +void EXhalbtcoutsrc_LpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#1053: FILE: ./hal/hal_btcoex.c:1053:
    +void EXhalbtcoutsrc_ScanNotify(struct BTC_COEXIST * pBtCoexist, u8 type)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#1082: FILE: ./hal/hal_btcoex.c:1082:
    +void EXhalbtcoutsrc_ConnectNotify(struct BTC_COEXIST * pBtCoexist, u8 action)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1108: FILE: ./hal/hal_btcoex.c:1108:
    +void EXhalbtcoutsrc_MediaStatusNotify(struct BTC_COEXIST * pBtCoexist, enum RT_MEDIA_STATUS mediaStatus)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1135: FILE: ./hal/hal_btcoex.c:1135:
    +void EXhalbtcoutsrc_SpecialPacketNotify(struct BTC_COEXIST * pBtCoexist, u8 pktType)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1166: FILE: ./hal/hal_btcoex.c:1166:
    +void EXhalbtcoutsrc_BtInfoNotify(struct BTC_COEXIST * pBtCoexist, u8 *tmpBuf, u8 length)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1184: FILE: ./hal/hal_btcoex.c:1184:
    +void EXhalbtcoutsrc_HaltNotify(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1197: FILE: ./hal/hal_btcoex.c:1197:
    +void EXhalbtcoutsrc_PnpNotify(struct BTC_COEXIST * pBtCoexist, u8 pnpState)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1213: FILE: ./hal/hal_btcoex.c:1213:
    +void EXhalbtcoutsrc_Periodical(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1258: FILE: ./hal/hal_btcoex.c:1258:
    +void EXhalbtcoutsrc_DisplayBtCoexInfo(struct BTC_COEXIST * pBtCoexist)

Signed-off-by: Marco Cesati <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Mar 16, 2021
This commit fixes the following checkpatch.pl errors:

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #70: FILE: ./hal/hal_btcoex.c:70:
    +static u8 halbtcoutsrc_IsBtCoexistAvailable(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#104: FILE: ./hal/hal_btcoex.c:104:
    +static void halbtcoutsrc_LeaveLps(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#117: FILE: ./hal/hal_btcoex.c:117:
    +static void halbtcoutsrc_EnterLps(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#130: FILE: ./hal/hal_btcoex.c:130:
    +static void halbtcoutsrc_NormalLps(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#152: FILE: ./hal/hal_btcoex.c:152:
    +static void halbtcoutsrc_LeaveLowPower(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#187: FILE: ./hal/hal_btcoex.c:187:
    +static void halbtcoutsrc_NormalLowPower(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#196: FILE: ./hal/hal_btcoex.c:196:
    +static void halbtcoutsrc_DisableLowPower(struct BTC_COEXIST * pBtCoexist, u8 bLowPwrDisable)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#205: FILE: ./hal/hal_btcoex.c:205:
    +static void halbtcoutsrc_AggregationCheck(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#283: FILE: ./hal/hal_btcoex.c:283:
    +static u32 halbtcoutsrc_GetWifiLinkStatus(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#311: FILE: ./hal/hal_btcoex.c:311:
    +static u32 halbtcoutsrc_GetBtPatchVer(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#342: FILE: ./hal/hal_btcoex.c:342:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#448: FILE: ./hal/hal_btcoex.c:448:
    +			struct RT_LINK_DETECT_T * plinkinfo;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#510: FILE: ./hal/hal_btcoex.c:510:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#645: FILE: ./hal/hal_btcoex.c:645:
    +static void halbtcoutsrc_DisplayFwPwrModeCmd(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#661: FILE: ./hal/hal_btcoex.c:661:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#673: FILE: ./hal/hal_btcoex.c:673:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#685: FILE: ./hal/hal_btcoex.c:685:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#697: FILE: ./hal/hal_btcoex.c:697:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#709: FILE: ./hal/hal_btcoex.c:709:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#749: FILE: ./hal/hal_btcoex.c:749:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo *	bar" should be "foo *bar"
    torvalds#761: FILE: ./hal/hal_btcoex.c:761:
    +	struct BTC_COEXIST *	pBtCoexist = (struct BTC_COEXIST *)pBtcContext;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#772: FILE: ./hal/hal_btcoex.c:772:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #785: FILE: ./hal/hal_btcoex.c:785:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#797: FILE: ./hal/hal_btcoex.c:797:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#809: FILE: ./hal/hal_btcoex.c:809:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#821: FILE: ./hal/hal_btcoex.c:821:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#857: FILE: ./hal/hal_btcoex.c:857:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#869: FILE: ./hal/hal_btcoex.c:869:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo *		bar" should be "foo *bar"
    torvalds#891: FILE: ./hal/hal_btcoex.c:891:
    +	struct BTC_COEXIST *		pBtCoexist = &GLBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#917: FILE: ./hal/hal_btcoex.c:917:
    +	struct BTC_COEXIST * pBtCoexist;

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#963: FILE: ./hal/hal_btcoex.c:963:
    +void EXhalbtcoutsrc_PowerOnSetting(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#975: FILE: ./hal/hal_btcoex.c:975:
    +void EXhalbtcoutsrc_InitHwConfig(struct BTC_COEXIST * pBtCoexist, u8 bWifiOnly)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#988: FILE: ./hal/hal_btcoex.c:988:
    +void EXhalbtcoutsrc_InitCoexDm(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#1003: FILE: ./hal/hal_btcoex.c:1003:
    +void EXhalbtcoutsrc_IpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#1030: FILE: ./hal/hal_btcoex.c:1030:
    +void EXhalbtcoutsrc_LpsNotify(struct BTC_COEXIST * pBtCoexist, u8 type)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#1053: FILE: ./hal/hal_btcoex.c:1053:
    +void EXhalbtcoutsrc_ScanNotify(struct BTC_COEXIST * pBtCoexist, u8 type)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    torvalds#1082: FILE: ./hal/hal_btcoex.c:1082:
    +void EXhalbtcoutsrc_ConnectNotify(struct BTC_COEXIST * pBtCoexist, u8 action)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1108: FILE: ./hal/hal_btcoex.c:1108:
    +void EXhalbtcoutsrc_MediaStatusNotify(struct BTC_COEXIST * pBtCoexist, enum RT_MEDIA_STATUS mediaStatus)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1135: FILE: ./hal/hal_btcoex.c:1135:
    +void EXhalbtcoutsrc_SpecialPacketNotify(struct BTC_COEXIST * pBtCoexist, u8 pktType)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1166: FILE: ./hal/hal_btcoex.c:1166:
    +void EXhalbtcoutsrc_BtInfoNotify(struct BTC_COEXIST * pBtCoexist, u8 *tmpBuf, u8 length)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1184: FILE: ./hal/hal_btcoex.c:1184:
    +void EXhalbtcoutsrc_HaltNotify(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1197: FILE: ./hal/hal_btcoex.c:1197:
    +void EXhalbtcoutsrc_PnpNotify(struct BTC_COEXIST * pBtCoexist, u8 pnpState)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1213: FILE: ./hal/hal_btcoex.c:1213:
    +void EXhalbtcoutsrc_Periodical(struct BTC_COEXIST * pBtCoexist)

    ERROR:POINTER_LOCATION: "foo * bar" should be "foo *bar"
    #1258: FILE: ./hal/hal_btcoex.c:1258:
    +void EXhalbtcoutsrc_DisplayBtCoexInfo(struct BTC_COEXIST * pBtCoexist)

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]>
ojeda pushed a commit to ojeda/linux that referenced this pull request Mar 17, 2021
Add a condition variable implementation to the `sync` module.
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jul 21, 2021
Performing the following:

 ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events
 ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger
 ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\
      > events/sched/sched_switch/trigger
 ># echo 1 > events/synthetic/enable

Crashed the kernel:

 BUG: kernel NULL pointer dereference, address: 000000000000001b
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ torvalds#104
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
 RIP: 0010:strlen+0x0/0x20
 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc
  20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10
  48 89 f8 48 83 c0 01 80 38 9 f8 c3 31
 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046
 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000
 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b
 RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8
 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320
 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018
 FS:  0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0
 Call Trace:
  trace_event_raw_event_synth+0x90/0x1d0
  action_trace+0x5b/0x70
  event_hist_trigger+0x4bd/0x4e0
  ? cpumask_next_and+0x20/0x30
  ? update_sd_lb_stats.constprop.0+0xf6/0x840
  ? __lock_acquire.constprop.0+0x125/0x550
  ? find_held_lock+0x32/0x90
  ? sched_clock_cpu+0xe/0xd0
  ? lock_release+0x155/0x440
  ? update_load_avg+0x8c/0x6f0
  ? enqueue_entity+0x18a/0x920
  ? __rb_reserve_next+0xe5/0x460
  ? ring_buffer_lock_reserve+0x12a/0x3f0
  event_triggers_call+0x52/0xe0
  trace_event_buffer_commit+0x1ae/0x240
  trace_event_raw_event_sched_switch+0x114/0x170
  __traceiter_sched_switch+0x39/0x50
  __schedule+0x431/0xb00
  schedule_idle+0x28/0x40
  do_idle+0x198/0x2e0
  cpu_startup_entry+0x19/0x20
  secondary_startup_64_no_verify+0xc2/0xcb

The reason is that the dynamic events array keeps track of the field
position of the fields array, via the field_pos variable in the
synth_field structure. Unfortunately, that field is a boolean for some
reason, which means any field_pos greater than 1 will be a bug (in this
case it was 2).

Cc: [email protected]
Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events")
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Jul 23, 2021
Performing the following:

 ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events
 ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger
 ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\
      > events/sched/sched_switch/trigger
 ># echo 1 > events/synthetic/enable

Crashed the kernel:

 BUG: kernel NULL pointer dereference, address: 000000000000001b
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ torvalds#104
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
 RIP: 0010:strlen+0x0/0x20
 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc
  20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10
  48 89 f8 48 83 c0 01 80 38 9 f8 c3 31
 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046
 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000
 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b
 RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8
 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320
 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018
 FS:  0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0
 Call Trace:
  trace_event_raw_event_synth+0x90/0x1d0
  action_trace+0x5b/0x70
  event_hist_trigger+0x4bd/0x4e0
  ? cpumask_next_and+0x20/0x30
  ? update_sd_lb_stats.constprop.0+0xf6/0x840
  ? __lock_acquire.constprop.0+0x125/0x550
  ? find_held_lock+0x32/0x90
  ? sched_clock_cpu+0xe/0xd0
  ? lock_release+0x155/0x440
  ? update_load_avg+0x8c/0x6f0
  ? enqueue_entity+0x18a/0x920
  ? __rb_reserve_next+0xe5/0x460
  ? ring_buffer_lock_reserve+0x12a/0x3f0
  event_triggers_call+0x52/0xe0
  trace_event_buffer_commit+0x1ae/0x240
  trace_event_raw_event_sched_switch+0x114/0x170
  __traceiter_sched_switch+0x39/0x50
  __schedule+0x431/0xb00
  schedule_idle+0x28/0x40
  do_idle+0x198/0x2e0
  cpu_startup_entry+0x19/0x20
  secondary_startup_64_no_verify+0xc2/0xcb

The reason is that the dynamic events array keeps track of the field
position of the fields array, via the field_pos variable in the
synth_field structure. Unfortunately, that field is a boolean for some
reason, which means any field_pos greater than 1 will be a bug (in this
case it was 2).

Link: https://lkml.kernel.org/r/[email protected]

Cc: Masami Hiramatsu <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events")
Reviewed-by: Tom Zanussi <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
torvalds pushed a commit that referenced this pull request Jul 23, 2021
Performing the following:

 ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events
 ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger
 ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\
      > events/sched/sched_switch/trigger
 ># echo 1 > events/synthetic/enable

Crashed the kernel:

 BUG: kernel NULL pointer dereference, address: 000000000000001b
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ #104
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
 RIP: 0010:strlen+0x0/0x20
 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc
  20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10
  48 89 f8 48 83 c0 01 80 38 9 f8 c3 31
 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046
 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000
 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b
 RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8
 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320
 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018
 FS:  0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0
 Call Trace:
  trace_event_raw_event_synth+0x90/0x1d0
  action_trace+0x5b/0x70
  event_hist_trigger+0x4bd/0x4e0
  ? cpumask_next_and+0x20/0x30
  ? update_sd_lb_stats.constprop.0+0xf6/0x840
  ? __lock_acquire.constprop.0+0x125/0x550
  ? find_held_lock+0x32/0x90
  ? sched_clock_cpu+0xe/0xd0
  ? lock_release+0x155/0x440
  ? update_load_avg+0x8c/0x6f0
  ? enqueue_entity+0x18a/0x920
  ? __rb_reserve_next+0xe5/0x460
  ? ring_buffer_lock_reserve+0x12a/0x3f0
  event_triggers_call+0x52/0xe0
  trace_event_buffer_commit+0x1ae/0x240
  trace_event_raw_event_sched_switch+0x114/0x170
  __traceiter_sched_switch+0x39/0x50
  __schedule+0x431/0xb00
  schedule_idle+0x28/0x40
  do_idle+0x198/0x2e0
  cpu_startup_entry+0x19/0x20
  secondary_startup_64_no_verify+0xc2/0xcb

The reason is that the dynamic events array keeps track of the field
position of the fields array, via the field_pos variable in the
synth_field structure. Unfortunately, that field is a boolean for some
reason, which means any field_pos greater than 1 will be a bug (in this
case it was 2).

Link: https://lkml.kernel.org/r/[email protected]

Cc: Masami Hiramatsu <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events")
Reviewed-by: Tom Zanussi <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
intersectRaven pushed a commit to intersectRaven/linux that referenced this pull request Jul 28, 2021
commit 3b13911 upstream.

Performing the following:

 ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events
 ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger
 ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\
      > events/sched/sched_switch/trigger
 ># echo 1 > events/synthetic/enable

Crashed the kernel:

 BUG: kernel NULL pointer dereference, address: 000000000000001b
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ torvalds#104
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
 RIP: 0010:strlen+0x0/0x20
 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc
  20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10
  48 89 f8 48 83 c0 01 80 38 9 f8 c3 31
 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046
 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000
 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b
 RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8
 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320
 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018
 FS:  0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0
 Call Trace:
  trace_event_raw_event_synth+0x90/0x1d0
  action_trace+0x5b/0x70
  event_hist_trigger+0x4bd/0x4e0
  ? cpumask_next_and+0x20/0x30
  ? update_sd_lb_stats.constprop.0+0xf6/0x840
  ? __lock_acquire.constprop.0+0x125/0x550
  ? find_held_lock+0x32/0x90
  ? sched_clock_cpu+0xe/0xd0
  ? lock_release+0x155/0x440
  ? update_load_avg+0x8c/0x6f0
  ? enqueue_entity+0x18a/0x920
  ? __rb_reserve_next+0xe5/0x460
  ? ring_buffer_lock_reserve+0x12a/0x3f0
  event_triggers_call+0x52/0xe0
  trace_event_buffer_commit+0x1ae/0x240
  trace_event_raw_event_sched_switch+0x114/0x170
  __traceiter_sched_switch+0x39/0x50
  __schedule+0x431/0xb00
  schedule_idle+0x28/0x40
  do_idle+0x198/0x2e0
  cpu_startup_entry+0x19/0x20
  secondary_startup_64_no_verify+0xc2/0xcb

The reason is that the dynamic events array keeps track of the field
position of the fields array, via the field_pos variable in the
synth_field structure. Unfortunately, that field is a boolean for some
reason, which means any field_pos greater than 1 will be a bug (in this
case it was 2).

Link: https://lkml.kernel.org/r/[email protected]

Cc: Masami Hiramatsu <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events")
Reviewed-by: Tom Zanussi <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
snajpa pushed a commit to vpsfreecz/linux that referenced this pull request Jul 30, 2021
commit 3b13911 upstream.

Performing the following:

 ># echo 'wakeup_lat s32 pid; u64 delta; char wake_comm[]' > synthetic_events
 ># echo 'hist:keys=pid:__arg__1=common_timestamp.usecs' > events/sched/sched_waking/trigger
 ># echo 'hist:keys=next_pid:pid=next_pid,delta=common_timestamp.usecs-$__arg__1:onmatch(sched.sched_waking).trace(wakeup_lat,$pid,$delta,prev_comm)'\
      > events/sched/sched_switch/trigger
 ># echo 1 > events/synthetic/enable

Crashed the kernel:

 BUG: kernel NULL pointer dereference, address: 000000000000001b
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: 0000 [#1] PREEMPT SMP
 CPU: 7 PID: 0 Comm: swapper/7 Not tainted 5.13.0-rc5-test+ torvalds#104
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
 RIP: 0010:strlen+0x0/0x20
 Code: f6 82 80 2b 0b bc 20 74 11 0f b6 50 01 48 83 c0 01 f6 82 80 2b 0b bc
  20 75 ef c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 <80> 3f 00 74 10
  48 89 f8 48 83 c0 01 80 38 9 f8 c3 31
 RSP: 0018:ffffaa75000d79d0 EFLAGS: 00010046
 RAX: 0000000000000002 RBX: ffff9cdb55575270 RCX: 0000000000000000
 RDX: ffff9cdb58c7a320 RSI: ffffaa75000d7b40 RDI: 000000000000001b
 RBP: ffffaa75000d7b40 R08: ffff9cdb40a4f010 R09: ffffaa75000d7ab8
 R10: ffff9cdb4398c700 R11: 0000000000000008 R12: ffff9cdb58c7a320
 R13: ffff9cdb55575270 R14: ffff9cdb58c7a000 R15: 0000000000000018
 FS:  0000000000000000(0000) GS:ffff9cdb5aa00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 000000000000001b CR3: 00000000c0612006 CR4: 00000000001706e0
 Call Trace:
  trace_event_raw_event_synth+0x90/0x1d0
  action_trace+0x5b/0x70
  event_hist_trigger+0x4bd/0x4e0
  ? cpumask_next_and+0x20/0x30
  ? update_sd_lb_stats.constprop.0+0xf6/0x840
  ? __lock_acquire.constprop.0+0x125/0x550
  ? find_held_lock+0x32/0x90
  ? sched_clock_cpu+0xe/0xd0
  ? lock_release+0x155/0x440
  ? update_load_avg+0x8c/0x6f0
  ? enqueue_entity+0x18a/0x920
  ? __rb_reserve_next+0xe5/0x460
  ? ring_buffer_lock_reserve+0x12a/0x3f0
  event_triggers_call+0x52/0xe0
  trace_event_buffer_commit+0x1ae/0x240
  trace_event_raw_event_sched_switch+0x114/0x170
  __traceiter_sched_switch+0x39/0x50
  __schedule+0x431/0xb00
  schedule_idle+0x28/0x40
  do_idle+0x198/0x2e0
  cpu_startup_entry+0x19/0x20
  secondary_startup_64_no_verify+0xc2/0xcb

The reason is that the dynamic events array keeps track of the field
position of the fields array, via the field_pos variable in the
synth_field structure. Unfortunately, that field is a boolean for some
reason, which means any field_pos greater than 1 will be a bug (in this
case it was 2).

Link: https://lkml.kernel.org/r/[email protected]

Cc: Masami Hiramatsu <[email protected]>
Cc: Namhyung Kim <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: [email protected]
Fixes: bd82631 ("tracing: Add support for dynamic strings to synthetic events")
Reviewed-by: Tom Zanussi <[email protected]>
Signed-off-by: Steven Rostedt (VMware) <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Oct 21, 2021
Commit 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak")
breaks boot on EFI systems with kmemleak and VM_DEBUG enabled:

efi: Processing EFI memory map:
efi:   0x000090000000-0x000091ffffff [Conventional|   |  |  |  |  |  |  |  |  |   |WB|WT|WC|UC]
efi:   0x000092000000-0x0000928fffff [Runtime Data|RUN|  |  |  |  |  |  |  |  |   |WB|WT|WC|UC]
------------[ cut here ]------------
kernel BUG at mm/kmemleak.c:1140!
Internal error: Oops - BUG: 0 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ torvalds#104
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kmemleak_free_part_phys+0x64/0x8c
lr : kmemleak_free_part_phys+0x38/0x8c
sp : ffff800011eafbc0
x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068
x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0
x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000
x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730
x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c
x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7
x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000
x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0
x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99
x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff
Call trace:
 kmemleak_free_part_phys+0x64/0x8c
 memblock_mark_nomap+0x5c/0x78
 reserve_regions+0x294/0x33c
 efi_init+0x2d0/0x490
 setup_arch+0x80/0x138
 start_kernel+0xa0/0x3ec
 __primary_switched+0xc0/0xc8
Code: 34000041 97d526e7 f9418e80 36000040 (d4210000)
random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0
---[ end trace 0000000000000000 ]---

The crash happens because kmemleak_free_part_phys() tries to use __va()
before memstart_addr is initialized and this triggers a VM_BUG_ON() in
arch/arm64/include/asm/memory.h:

Revert 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak"), the
issue it is fixing will be fixed differently.

Reported-by: Qian Cai <[email protected]>
Signed-off-by: Mike Rapoport <[email protected]>
torvalds pushed a commit that referenced this pull request Oct 22, 2021
Commit 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak")
breaks boot on EFI systems with kmemleak and VM_DEBUG enabled:

  efi: Processing EFI memory map:
  efi:   0x000090000000-0x000091ffffff [Conventional|   |  |  |  |  |  |  |  |  |   |WB|WT|WC|UC]
  efi:   0x000092000000-0x0000928fffff [Runtime Data|RUN|  |  |  |  |  |  |  |  |   |WB|WT|WC|UC]
  ------------[ cut here ]------------
  kernel BUG at mm/kmemleak.c:1140!
  Internal error: Oops - BUG: 0 [#1] SMP
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ #104
  pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  pc : kmemleak_free_part_phys+0x64/0x8c
  lr : kmemleak_free_part_phys+0x38/0x8c
  sp : ffff800011eafbc0
  x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068
  x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0
  x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000
  x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730
  x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c
  x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7
  x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000
  x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0
  x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99
  x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff
  Call trace:
   kmemleak_free_part_phys+0x64/0x8c
   memblock_mark_nomap+0x5c/0x78
   reserve_regions+0x294/0x33c
   efi_init+0x2d0/0x490
   setup_arch+0x80/0x138
   start_kernel+0xa0/0x3ec
   __primary_switched+0xc0/0xc8
  Code: 34000041 97d526e7 f9418e80 36000040 (d4210000)
  random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0
  ---[ end trace 0000000000000000 ]---

The crash happens because kmemleak_free_part_phys() tries to use __va()
before memstart_addr is initialized and this triggers a VM_BUG_ON() in
arch/arm64/include/asm/memory.h:

Revert 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak"),
the issue it is fixing will be fixed differently.

Reported-by: Qian Cai <[email protected]>
Signed-off-by: Mike Rapoport <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
staging-kernelci-org pushed a commit to kernelci/linux that referenced this pull request Oct 23, 2021
Commit 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak")
breaks boot on EFI systems with kmemleak and VM_DEBUG enabled:

efi: Processing EFI memory map:
efi:   0x000090000000-0x000091ffffff [Conventional|   |  |  |  |  |  |  |  |  |   |WB|WT|WC|UC]
efi:   0x000092000000-0x0000928fffff [Runtime Data|RUN|  |  |  |  |  |  |  |  |   |WB|WT|WC|UC]
------------[ cut here ]------------
kernel BUG at mm/kmemleak.c:1140!
Internal error: Oops - BUG: 0 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ torvalds#104
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kmemleak_free_part_phys+0x64/0x8c
lr : kmemleak_free_part_phys+0x38/0x8c
sp : ffff800011eafbc0
x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068
x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0
x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000
x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730
x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c
x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7
x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000
x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0
x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99
x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff
Call trace:
 kmemleak_free_part_phys+0x64/0x8c
 memblock_mark_nomap+0x5c/0x78
 reserve_regions+0x294/0x33c
 efi_init+0x2d0/0x490
 setup_arch+0x80/0x138
 start_kernel+0xa0/0x3ec
 __primary_switched+0xc0/0xc8
Code: 34000041 97d526e7 f9418e80 36000040 (d4210000)
random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0
---[ end trace 0000000000000000 ]---

The crash happens because kmemleak_free_part_phys() tries to use __va()
before memstart_addr is initialized and this triggers a VM_BUG_ON() in
arch/arm64/include/asm/memory.h:

Revert 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak"), the
issue it is fixing will be fixed differently.

Reported-by: Qian Cai <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Mike Rapoport <[email protected]>
fengguang pushed a commit to 0day-ci/linux that referenced this pull request Oct 25, 2021
Commit 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak")
breaks boot on EFI systems with kmemleak and VM_DEBUG enabled:

efi: Processing EFI memory map:
efi:   0x000090000000-0x000091ffffff [Conventional|   |  |  |  |  |  |  |  |  |   |WB|WT|WC|UC]
efi:   0x000092000000-0x0000928fffff [Runtime Data|RUN|  |  |  |  |  |  |  |  |   |WB|WT|WC|UC]
------------[ cut here ]------------
kernel BUG at mm/kmemleak.c:1140!
Internal error: Oops - BUG: 0 [#1] SMP
Modules linked in:
CPU: 0 PID: 0 Comm: swapper Not tainted 5.15.0-rc6-next-20211019+ torvalds#104
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : kmemleak_free_part_phys+0x64/0x8c
lr : kmemleak_free_part_phys+0x38/0x8c
sp : ffff800011eafbc0
x29: ffff800011eafbc0 x28: 1fffff7fffb41c0d x27: fffffbfffda0e068
x26: 0000000092000000 x25: 1ffff000023d5f94 x24: ffff800011ed84d0
x23: ffff800011ed84c0 x22: ffff800011ed83d8 x21: 0000000000900000
x20: ffff800011782000 x19: 0000000092000000 x18: ffff800011ee0730
x17: 0000000000000000 x16: 0000000000000000 x15: 1ffff0000233252c
x14: ffff800019a905a0 x13: 0000000000000001 x12: ffff7000023d5ed7
x11: 1ffff000023d5ed6 x10: ffff7000023d5ed6 x9 : dfff800000000000
x8 : ffff800011eaf6b7 x7 : 0000000000000001 x6 : ffff800011eaf6b0
x5 : 00008ffffdc2a12a x4 : ffff7000023d5ed7 x3 : 1ffff000023dbf99
x2 : 1ffff000022f0463 x1 : 0000000000000000 x0 : ffffffffffffffff
Call trace:
 kmemleak_free_part_phys+0x64/0x8c
 memblock_mark_nomap+0x5c/0x78
 reserve_regions+0x294/0x33c
 efi_init+0x2d0/0x490
 setup_arch+0x80/0x138
 start_kernel+0xa0/0x3ec
 __primary_switched+0xc0/0xc8
Code: 34000041 97d526e7 f9418e80 36000040 (d4210000)
random: get_random_bytes called from print_oops_end_marker+0x34/0x80 with crng_init=0
---[ end trace 0000000000000000 ]---

The crash happens because kmemleak_free_part_phys() tries to use __va()
before memstart_addr is initialized and this triggers a VM_BUG_ON() in
arch/arm64/include/asm/memory.h:

Revert 6e44bd6 ("memblock: exclude NOMAP regions from kmemleak"), the
issue it is fixing will be fixed differently.

Reported-by: Qian Cai <[email protected]>
Signed-off-by: Mike Rapoport <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Reviewed-by: David Hildenbrand <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Nov 20, 2021
statfs calculates Total/Used/Avail disk space in block unit,
so we should translate soft/hard prjquota limit to block unit
as well.

Below testing result shows the block/inode numbers of
Total/Used/Avail from df command are all correct afer
applying this patch.

[root@localhost quota-tools]\# ./repquota -P /dev/sdb1
*** Report for project quotas on device /dev/sdb1
Block grace time: 7days; Inode grace time: 7days
              Block limits                File limits
Project   used soft    hard  grace  used  soft  hard  grace
-----------------------------------------------------------
\#0   --   4       0       0         1     0     0
\torvalds#101 --   0       0       0         2     0     0
\torvalds#102 --   0   10240       0         2    10     0
\torvalds#103 --   0       0   20480         2     0    20
\torvalds#104 --   0   10240   20480         2    10    20
\torvalds#105 --   0   20480   10240         2    20    10

[root@localhost sdb1]\# lsattr -p t{1,2,3,4,5}
  101 ----------------N-- t1/a1
  102 ----------------N-- t2/a2
  103 ----------------N-- t3/a3
  104 ----------------N-- t4/a4
  105 ----------------N-- t5/a5

[root@localhost sdb1]\# df -hi t{1,2,3,4,5}
Filesystem     Inodes IUsed IFree IUse% Mounted on
/dev/sdb1        2.4M    21  2.4M    1% /mnt/sdb1
/dev/sdb1          10     2     8   20% /mnt/sdb1
/dev/sdb1          20     2    18   10% /mnt/sdb1
/dev/sdb1          10     2     8   20% /mnt/sdb1
/dev/sdb1          10     2     8   20% /mnt/sdb1

[root@localhost sdb1]\# df -h t{1,2,3,4,5}
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        10G  489M  9.6G   5% /mnt/sdb1
/dev/sdb1        10M     0   10M   0% /mnt/sdb1
/dev/sdb1        20M     0   20M   0% /mnt/sdb1
/dev/sdb1        10M     0   10M   0% /mnt/sdb1
/dev/sdb1        10M     0   10M   0% /mnt/sdb1

Fixes: 909110c ("f2fs: choose hardlimit when softlimit is larger than hardlimit in f2fs_statfs_project()")
Signed-off-by: Chengguang Xu <[email protected]>
Reviewed-by: Chao Yu <[email protected]>
Signed-off-by: Jaegeuk Kim <[email protected]>
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Mar 25, 2022
The BPF STX/LDX instruction uses offset relative to the FP to address
stack space. Since the BPF_FP locates at the top of the frame, the offset
is usually a negative number. However, arm64 str/ldr immediate instruction
requires that offset be a positive number.  Therefore, this patch tries to
convert the offsets.

The method is to find the negative offset furthest from the FP firstly.
Then add it to the FP, calculate a bottom position, called FPB, and then
adjust the offsets in other STR/LDX instructions relative to FPB.

FPB is saved using the callee-saved register x27 of arm64 which is not
used yet.

Before adjusting the offset, the patch checks every instruction to ensure
that the FP does not change in run-time. If the FP may change, no offset
is adjusted.

For example, for the following bpftrace command:

  bpftrace -e 'kprobe:do_sys_open { printf("opening: %s\n", str(arg1)); }'

Without this patch, jited code(fragment):

   0:   bti     c
   4:   stp     x29, x30, [sp, #-16]!
   8:   mov     x29, sp
   c:   stp     x19, x20, [sp, #-16]!
  10:   stp     x21, x22, [sp, #-16]!
  14:   stp     x25, x26, [sp, #-16]!
  18:   mov     x25, sp
  1c:   mov     x26, #0x0                       // #0
  20:   bti     j
  24:   sub     sp, sp, #0x90
  28:   add     x19, x0, #0x0
  2c:   mov     x0, #0x0                        // #0
  30:   mov     x10, #0xffffffffffffff78        // #-136
  34:   str     x0, [x25, x10]
  38:   mov     x10, #0xffffffffffffff80        // #-128
  3c:   str     x0, [x25, x10]
  40:   mov     x10, #0xffffffffffffff88        // #-120
  44:   str     x0, [x25, x10]
  48:   mov     x10, #0xffffffffffffff90        // #-112
  4c:   str     x0, [x25, x10]
  50:   mov     x10, #0xffffffffffffff98        // #-104
  54:   str     x0, [x25, x10]
  58:   mov     x10, #0xffffffffffffffa0        // #-96
  5c:   str     x0, [x25, x10]
  60:   mov     x10, #0xffffffffffffffa8        // #-88
  64:   str     x0, [x25, x10]
  68:   mov     x10, #0xffffffffffffffb0        // #-80
  6c:   str     x0, [x25, x10]
  70:   mov     x10, #0xffffffffffffffb8        // #-72
  74:   str     x0, [x25, x10]
  78:   mov     x10, #0xffffffffffffffc0        // #-64
  7c:   str     x0, [x25, x10]
  80:   mov     x10, #0xffffffffffffffc8        // #-56
  84:   str     x0, [x25, x10]
  88:   mov     x10, #0xffffffffffffffd0        // #-48
  8c:   str     x0, [x25, x10]
  90:   mov     x10, #0xffffffffffffffd8        // #-40
  94:   str     x0, [x25, x10]
  98:   mov     x10, #0xffffffffffffffe0        // #-32
  9c:   str     x0, [x25, x10]
  a0:   mov     x10, #0xffffffffffffffe8        // #-24
  a4:   str     x0, [x25, x10]
  a8:   mov     x10, #0xfffffffffffffff0        // #-16
  ac:   str     x0, [x25, x10]
  b0:   mov     x10, #0xfffffffffffffff8        // #-8
  b4:   str     x0, [x25, x10]
  b8:   mov     x10, #0x8                       // torvalds#8
  bc:   ldr     x2, [x19, x10]
  [...]

With this patch, jited code(fragment):

   0:   bti     c
   4:   stp     x29, x30, [sp, #-16]!
   8:   mov     x29, sp
   c:   stp     x19, x20, [sp, #-16]!
  10:   stp     x21, x22, [sp, #-16]!
  14:   stp     x25, x26, [sp, #-16]!
  18:   stp     x27, x28, [sp, #-16]!
  1c:   mov     x25, sp
  20:   sub     x27, x25, #0x88
  24:   mov     x26, #0x0                       // #0
  28:   bti     j
  2c:   sub     sp, sp, #0x90
  30:   add     x19, x0, #0x0
  34:   mov     x0, #0x0                        // #0
  38:   str     x0, [x27]
  3c:   str     x0, [x27, torvalds#8]
  40:   str     x0, [x27, torvalds#16]
  44:   str     x0, [x27, torvalds#24]
  48:   str     x0, [x27, torvalds#32]
  4c:   str     x0, [x27, torvalds#40]
  50:   str     x0, [x27, torvalds#48]
  54:   str     x0, [x27, torvalds#56]
  58:   str     x0, [x27, torvalds#64]
  5c:   str     x0, [x27, torvalds#72]
  60:   str     x0, [x27, torvalds#80]
  64:   str     x0, [x27, torvalds#88]
  68:   str     x0, [x27, torvalds#96]
  6c:   str     x0, [x27, torvalds#104]
  70:   str     x0, [x27, torvalds#112]
  74:   str     x0, [x27, torvalds#120]
  78:   str     x0, [x27, torvalds#128]
  7c:   ldr     x2, [x19, torvalds#8]
  [...]

Signed-off-by: Xu Kuohai <[email protected]>
ammarfaizi2 pushed a commit to ammarfaizi2/linux-fork that referenced this pull request Mar 31, 2022
The BPF STX/LDX instruction uses offset relative to the FP to address
stack space. Since the BPF_FP locates at the top of the frame, the offset
is usually a negative number. However, arm64 str/ldr immediate instruction
requires that offset be a positive number.  Therefore, this patch tries to
convert the offsets.

The method is to find the negative offset furthest from the FP firstly.
Then add it to the FP, calculate a bottom position, called FPB, and then
adjust the offsets in other STR/LDX instructions relative to FPB.

FPB is saved using the callee-saved register x27 of arm64 which is not
used yet.

Before adjusting the offset, the patch checks every instruction to ensure
that the FP does not change in run-time. If the FP may change, no offset
is adjusted.

For example, for the following bpftrace command:

  bpftrace -e 'kprobe:do_sys_open { printf("opening: %s\n", str(arg1)); }'

Without this patch, jited code(fragment):

   0:   bti     c
   4:   stp     x29, x30, [sp, #-16]!
   8:   mov     x29, sp
   c:   stp     x19, x20, [sp, #-16]!
  10:   stp     x21, x22, [sp, #-16]!
  14:   stp     x25, x26, [sp, #-16]!
  18:   mov     x25, sp
  1c:   mov     x26, #0x0                       // #0
  20:   bti     j
  24:   sub     sp, sp, #0x90
  28:   add     x19, x0, #0x0
  2c:   mov     x0, #0x0                        // #0
  30:   mov     x10, #0xffffffffffffff78        // #-136
  34:   str     x0, [x25, x10]
  38:   mov     x10, #0xffffffffffffff80        // #-128
  3c:   str     x0, [x25, x10]
  40:   mov     x10, #0xffffffffffffff88        // #-120
  44:   str     x0, [x25, x10]
  48:   mov     x10, #0xffffffffffffff90        // #-112
  4c:   str     x0, [x25, x10]
  50:   mov     x10, #0xffffffffffffff98        // #-104
  54:   str     x0, [x25, x10]
  58:   mov     x10, #0xffffffffffffffa0        // #-96
  5c:   str     x0, [x25, x10]
  60:   mov     x10, #0xffffffffffffffa8        // #-88
  64:   str     x0, [x25, x10]
  68:   mov     x10, #0xffffffffffffffb0        // #-80
  6c:   str     x0, [x25, x10]
  70:   mov     x10, #0xffffffffffffffb8        // #-72
  74:   str     x0, [x25, x10]
  78:   mov     x10, #0xffffffffffffffc0        // #-64
  7c:   str     x0, [x25, x10]
  80:   mov     x10, #0xffffffffffffffc8        // #-56
  84:   str     x0, [x25, x10]
  88:   mov     x10, #0xffffffffffffffd0        // #-48
  8c:   str     x0, [x25, x10]
  90:   mov     x10, #0xffffffffffffffd8        // #-40
  94:   str     x0, [x25, x10]
  98:   mov     x10, #0xffffffffffffffe0        // #-32
  9c:   str     x0, [x25, x10]
  a0:   mov     x10, #0xffffffffffffffe8        // #-24
  a4:   str     x0, [x25, x10]
  a8:   mov     x10, #0xfffffffffffffff0        // #-16
  ac:   str     x0, [x25, x10]
  b0:   mov     x10, #0xfffffffffffffff8        // #-8
  b4:   str     x0, [x25, x10]
  b8:   mov     x10, #0x8                       // torvalds#8
  bc:   ldr     x2, [x19, x10]
  [...]

With this patch, jited code(fragment):

   0:   bti     c
   4:   stp     x29, x30, [sp, #-16]!
   8:   mov     x29, sp
   c:   stp     x19, x20, [sp, #-16]!
  10:   stp     x21, x22, [sp, #-16]!
  14:   stp     x25, x26, [sp, #-16]!
  18:   stp     x27, x28, [sp, #-16]!
  1c:   mov     x25, sp
  20:   sub     x27, x25, #0x88
  24:   mov     x26, #0x0                       // #0
  28:   bti     j
  2c:   sub     sp, sp, #0x90
  30:   add     x19, x0, #0x0
  34:   mov     x0, #0x0                        // #0
  38:   str     x0, [x27]
  3c:   str     x0, [x27, torvalds#8]
  40:   str     x0, [x27, torvalds#16]
  44:   str     x0, [x27, torvalds#24]
  48:   str     x0, [x27, torvalds#32]
  4c:   str     x0, [x27, torvalds#40]
  50:   str     x0, [x27, torvalds#48]
  54:   str     x0, [x27, torvalds#56]
  58:   str     x0, [x27, torvalds#64]
  5c:   str     x0, [x27, torvalds#72]
  60:   str     x0, [x27, torvalds#80]
  64:   str     x0, [x27, torvalds#88]
  68:   str     x0, [x27, torvalds#96]
  6c:   str     x0, [x27, torvalds#104]
  70:   str     x0, [x27, torvalds#112]
  74:   str     x0, [x27, torvalds#120]
  78:   str     x0, [x27, torvalds#128]
  7c:   ldr     x2, [x19, torvalds#8]
  [...]

Signed-off-by: Xu Kuohai <[email protected]>
Signed-off-by: Daniel Borkmann <[email protected]>
Link: https://lore.kernel.org/bpf/[email protected]
lluchs pushed a commit to KIT-OSGroup/linux that referenced this pull request May 10, 2022
nova/Kconfig: Add LIBNVDIMM dependency
Damenly pushed a commit to Damenly/linux that referenced this pull request Jul 25, 2023
mj22226 pushed a commit to mj22226/linux that referenced this pull request Jul 30, 2023
logic10492 pushed a commit to logic10492/linux-amd-zen2 that referenced this pull request Jan 18, 2024
Allow dispatching from ops.select_cpu()
intel-lab-lkp pushed a commit to intel-lab-lkp/linux that referenced this pull request Aug 4, 2024
The kernel sleep profile is no longer working due to a recursive locking
bug introduced by commit 42a20f8 ("sched: Add wrapper for get_wchan()
to keep task blocked"); either booting with

  profile=sleep

kernel command line option added or executing

  # echo -n sleep > /sys/kernel/profiling

after boot causes the system to lock up.

  ============================================
  WARNING: possible recursive locking detected
  5.15.0-rc4+ torvalds#104 Not tainted
  --------------------------------------------
  kthreadd/3 is trying to acquire lock:
  ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: get_wchan+0x32/0x70

  but task is already holding lock:
  ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: try_to_wake_up+0x53/0x370

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

         CPU0
         ----
    lock(&p->pi_lock);
    lock(&p->pi_lock);

   *** DEADLOCK ***

   May be due to missing lock nesting notation

  3 locks held by kthreadd/3:
   #0: ffffae5ac2833d68 (&x->wait){....}-{2:2}, at: complete+0x18/0x40
   #1: ffff93ac82e08d58 (&p->pi_lock){....}-{2:2}, at: try_to_wake_up+0x53/0x370
   #2: ffff93ad29fe9458 (&rq->__lock){-...}-{2:2}, at: try_to_wake_up+0x19f/0x370

  stack backtrace:
  CPU: 0 PID: 3 Comm: kthreadd Not tainted 5.15.0-rc4+ torvalds#104
  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020
  Call Trace:
   dump_stack_lvl+0x57/0x72
   validate_chain.cold+0x122/0x127
   __lock_acquire+0x4d2/0x930
   lock_acquire+0xc8/0x2f0
   ? get_wchan+0x32/0x70
   ? rcu_read_lock_sched_held+0x3f/0x80
   _raw_spin_lock_irq+0x47/0x90
   ? get_wchan+0x32/0x70
   get_wchan+0x32/0x70
   __update_stats_enqueue_sleeper+0x151/0x430
   enqueue_entity+0x4b0/0x520
   enqueue_task_fair+0x92/0x6b0
   ? lock_is_held_type+0xa7/0x120
   ttwu_do_activate+0x73/0x140
   try_to_wake_up+0x213/0x370
   swake_up_locked+0x20/0x50
   complete+0x2f/0x40
   ? __cancel_work_timer+0x1b0/0x1b0
   kthread+0xfb/0x180
   ? set_kthread_struct+0x40/0x40
   ret_from_fork+0x22/0x30

However, since nobody noticed this regression for more than 2 years, let's
remove profile=sleep support based on an assumption that nobody needs this
functionality.

Fixes: 42a20f8 ("sched: Add wrapper for get_wchan() to keep task blocked")
Cc: [email protected] # v5.16+
Signed-off-by: Tetsuo Handa <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant