26 Jan, 2019

40 commits

  • [ Upstream commit fbac5977d81cb2b2b7e37b11c459055d9585273c ]

    An unterminated string literal followed by new line is passed to the
    parser (with "multi-line strings not supported" warning shown), then
    handled properly there.

    On the other hand, an unterminated string literal at end of file is
    never passed to the parser, then results in memory leak.

    [Test Code]

    ----------(Kconfig begin)----------
    source "Kconfig.inc"

    config A
    bool "a"
    -----------(Kconfig end)-----------

    --------(Kconfig.inc begin)--------
    config B
    bool "b\No new line at end of file
    ---------(Kconfig.inc end)---------

    [Summary from Valgrind]

    Before the fix:

    LEAK SUMMARY:
    definitely lost: 16 bytes in 1 blocks
    ...

    After the fix:

    LEAK SUMMARY:
    definitely lost: 0 bytes in 0 blocks
    ...

    Eliminate the memory leak path by handling this case. Of course, such
    a Kconfig file is wrong already, so I will add an error message later.

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Sasha Levin

    Masahiro Yamada
     
  • [ Upstream commit 77c1c0fa8b1477c5799bdad65026ea5ff676da44 ]

    Currently, warn_ignore_character() displays invalid file name and
    line number.

    The lexer should use current_file->name and yylineno, while the parser
    should use zconf_curname() and zconf_lineno().

    This difference comes from that the lexer is always going ahead
    of the parser. The parser needs to look ahead one token to make a
    shift/reduce decision, so the lexer is requested to scan more text
    from the input file.

    This commit fixes the warning message from warn_ignored_character().

    [Test Code]

    ----(Kconfig begin)----
    /
    -----(Kconfig end)-----

    [Output]

    Before the fix:

    :0:warning: ignoring unsupported character '/'

    After the fix:

    Kconfig:1:warning: ignoring unsupported character '/'

    Signed-off-by: Masahiro Yamada
    Signed-off-by: Sasha Levin

    Masahiro Yamada
     
  • [ Upstream commit e434b8cdf788568ba65a0a0fd9f3cb41f3ca1803 ]

    Currently, the destination register is marked as unknown for 32-bit
    sub-register move (BPF_MOV | BPF_ALU) whenever the source register type is
    SCALAR_VALUE.

    This is too conservative that some valid cases will be rejected.
    Especially, this may turn a constant scalar value into unknown value that
    could break some assumptions of verifier.

    For example, test_l4lb_noinline.c has the following C code:

    struct real_definition *dst

    1: if (!get_packet_dst(&dst, &pckt, vip_info, is_ipv6))
    2: return TC_ACT_SHOT;
    3:
    4: if (dst->flags & F_IPV6) {

    get_packet_dst is responsible for initializing "dst" into valid pointer and
    return true (1), otherwise return false (0). The compiled instruction
    sequence using alu32 will be:

    412: (54) (u32) r7 &= (u32) 1
    413: (bc) (u32) r0 = (u32) r7
    414: (95) exit

    insn 413, a BPF_MOV | BPF_ALU, however will turn r0 into unknown value even
    r7 contains SCALAR_VALUE 1.

    This causes trouble when verifier is walking the code path that hasn't
    initialized "dst" inside get_packet_dst, for which case 0 is returned and
    we would then expect verifier concluding line 1 in the above C code pass
    the "if" check, therefore would skip fall through path starting at line 4.
    Now, because r0 returned from callee has became unknown value, so verifier
    won't skip analyzing path starting at line 4 and "dst->flags" requires
    dereferencing the pointer "dst" which actually hasn't be initialized for
    this path.

    This patch relaxed the code marking sub-register move destination. For a
    SCALAR_VALUE, it is safe to just copy the value from source then truncate
    it into 32-bit.

    A unit test also included to demonstrate this issue. This test will fail
    before this patch.

    This relaxation could let verifier skipping more paths for conditional
    comparison against immediate. It also let verifier recording a more
    accurate/strict value for one register at one state, if this state end up
    with going through exit without rejection and it is used for state
    comparison later, then it is possible an inaccurate/permissive value is
    better. So the real impact on verifier processed insn number is complex.
    But in all, without this fix, valid program could be rejected.

    >From real benchmarking on kernel selftests and Cilium bpf tests, there is
    no impact on processed instruction number when tests ares compiled with
    default compilation options. There is slightly improvements when they are
    compiled with -mattr=+alu32 after this patch.

    Also, test_xdp_noinline/-mattr=+alu32 now passed verification. It is
    rejected before this fix.

    Insn processed before/after this patch:

    default -mattr=+alu32

    Kernel selftest

    ===
    test_xdp.o 371/371 369/369
    test_l4lb.o 6345/6345 5623/5623
    test_xdp_noinline.o 2971/2971 rejected/2727
    test_tcp_estates.o 429/429 430/430

    Cilium bpf
    ===
    bpf_lb-DLB_L3.o: 2085/2085 1685/1687
    bpf_lb-DLB_L4.o: 2287/2287 1986/1982
    bpf_lb-DUNKNOWN.o: 690/690 622/622
    bpf_lxc.o: 95033/95033 N/A
    bpf_netdev.o: 7245/7245 N/A
    bpf_overlay.o: 2898/2898 3085/2947

    NOTE:
    - bpf_lxc.o and bpf_netdev.o compiled by -mattr=+alu32 are rejected by
    verifier due to another issue inside verifier on supporting alu32
    binary.
    - Each cilium bpf program could generate several processed insn number,
    above number is sum of them.

    v1->v2:
    - Restrict the change on SCALAR_VALUE.
    - Update benchmark numbers on Cilium bpf tests.

    Signed-off-by: Jiong Wang
    Signed-off-by: Alexei Starovoitov
    Signed-off-by: Sasha Levin

    Jiong Wang
     
  • [ Upstream commit 33309ecda0070506c49182530abe7728850ebe78 ]

    The dcache_by_line_op macro suffers from a couple of small problems:

    First, the GAS directives that are currently being used rely on
    assembler behavior that is not documented, and probably not guaranteed
    to produce the correct behavior going forward. As a result, we end up
    with some undefined symbols in cache.o:

    $ nm arch/arm64/mm/cache.o
    ...
    U civac
    ...
    U cvac
    U cvap
    U cvau

    This is due to the fact that the comparisons used to select the
    operation type in the dcache_by_line_op macro are comparing symbols
    not strings, and even though it seems that GAS is doing the right
    thing here (undefined symbols by the same name are equal to each
    other), it seems unwise to rely on this.

    Second, when patching in a DC CVAP instruction on CPUs that support it,
    the fallback path consists of a DC CVAU instruction which may be
    affected by CPU errata that require ARM64_WORKAROUND_CLEAN_CACHE.

    Solve these issues by unrolling the various maintenance routines and
    using the conditional directives that are documented as operating on
    strings. To avoid the complexity of nested alternatives, we move the
    DC CVAP patching to __clean_dcache_area_pop, falling back to a branch
    to __clean_dcache_area_poc if DCPOP is not supported by the CPU.

    Reported-by: Ard Biesheuvel
    Suggested-by: Robin Murphy
    Signed-off-by: Will Deacon
    Signed-off-by: Sasha Levin

    Will Deacon
     
  • [ Upstream commit f7542d817733f461258fd3a47d77da35b2d9fc81 ]

    The exclusive gates may be set up in the wrong way by software running
    before the clock driver comes up. In that case the exclusive setup is
    locked in its initial state, as the complementary function can't be
    activated without disabling the initial setup first.

    To avoid this lock situation, reset the exclusive gates to the off
    state and allow the kernel to provide the proper setup.

    Signed-off-by: Lucas Stach
    Reviewed-by: Dong Aisheng
    Signed-off-by: Stephen Boyd
    Signed-off-by: Sasha Levin

    Lucas Stach
     
  • [ Upstream commit 6e8830674ea77f57d57a33cca09083b117a71f41 ]

    If the kernel is configured with KASAN_EXTRA, the stack size is
    increased significantly due to setting the GCC -fstack-reuse option to
    "none" [1]. As a result, it can trigger a stack overrun quite often with
    32k stack size compiled using GCC 8. For example, this reproducer

    https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/madvise/madvise06.c

    can trigger a "corrupted stack end detected inside scheduler" very
    reliably with CONFIG_SCHED_STACK_END_CHECK enabled. There are other
    reports at:

    https://lore.kernel.org/lkml/1542144497.12945.29.camel@gmx.us/
    https://lore.kernel.org/lkml/721E7B42-2D55-4866-9C1A-3E8D64F33F9C@gmx.us/

    There are just too many functions that could have a large stack with
    KASAN_EXTRA due to large local variables that have been called over and
    over again without being able to reuse the stacks. Some noticiable ones
    are,

    size
    7536 shrink_inactive_list
    7440 shrink_page_list
    6560 fscache_stats_show
    3920 jbd2_journal_commit_transaction
    3216 try_to_unmap_one
    3072 migrate_page_move_mapping
    3584 migrate_misplaced_transhuge_page
    3920 ip_vs_lblcr_schedule
    4304 lpfc_nvme_info_show
    3888 lpfc_debugfs_nvmestat_data.constprop

    There are other 49 functions over 2k in size while compiling kernel with
    "-Wframe-larger-than=" on this machine. Hence, it is too much work to
    change Makefiles for each object to compile without
    -fsanitize-address-use-after-scope individually.

    [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81715#c23

    Signed-off-by: Qian Cai
    Signed-off-by: Will Deacon
    Signed-off-by: Sasha Levin

    Qian Cai
     
  • [ Upstream commit b708a3cc9600390ccaa2b68a88087dd265154b2b ]

    I've stumbled over the current macro-expand behaviour of the test
    harness:

    $ gcc -Wall -xc - <:4:global.macro:Expected 0 (0) != (((signed char) (((status) & 0x7f) + 1) >> 1) > 0) (0)
    global.macro: Test terminated by assertion
    [ FAIL ] global.macro
    [==========] 0 / 1 tests passed.
    [ FAILED ]

    With this change the output of the same test looks much more
    comprehensible:

    [==========] Running 1 tests from 1 test cases.
    [ RUN ] global.macro
    :4:global.macro:Expected 0 (0) != WIFSIGNALED(status) (0)
    global.macro: Test terminated by assertion
    [ FAIL ] global.macro
    [==========] 0 / 1 tests passed.
    [ FAILED ]

    The issue is very similar to the bug fixed in glibc assert(3)
    three years ago:
    https://sourceware.org/bugzilla/show_bug.cgi?id=18604

    Cc: Shuah Khan
    Cc: Kees Cook
    Cc: Andy Lutomirski
    Cc: Will Drewry
    Cc: linux-kselftest@vger.kernel.org
    Signed-off-by: Dmitry V. Levin
    Acked-by: Kees Cook
    Signed-off-by: Shuah Khan
    Signed-off-by: Sasha Levin

    Dmitry V. Levin
     
  • [ Upstream commit ad669505c4e9db9af9faeb5c51aa399326a80d91 ]

    A session must only be released after all code that accesses the session
    structure has finished. Make sure that this is the case by introducing a
    new command counter per session that is only decremented after the
    .release_cmd() callback has finished. This patch fixes the following crash:

    BUG: KASAN: use-after-free in do_raw_spin_lock+0x1c/0x130
    Read of size 4 at addr ffff8801534b16e4 by task rmdir/14805
    CPU: 16 PID: 14805 Comm: rmdir Not tainted 4.18.0-rc2-dbg+ #5
    Call Trace:
    dump_stack+0xa4/0xf5
    print_address_description+0x6f/0x270
    kasan_report+0x241/0x360
    __asan_load4+0x78/0x80
    do_raw_spin_lock+0x1c/0x130
    _raw_spin_lock_irqsave+0x52/0x60
    srpt_set_ch_state+0x27/0x70 [ib_srpt]
    srpt_disconnect_ch+0x1b/0xc0 [ib_srpt]
    srpt_close_session+0xa8/0x260 [ib_srpt]
    target_shutdown_sessions+0x170/0x180 [target_core_mod]
    core_tpg_del_initiator_node_acl+0xf3/0x200 [target_core_mod]
    target_fabric_nacl_base_release+0x25/0x30 [target_core_mod]
    config_item_release+0x9c/0x110 [configfs]
    config_item_put+0x26/0x30 [configfs]
    configfs_rmdir+0x3b8/0x510 [configfs]
    vfs_rmdir+0xb3/0x1e0
    do_rmdir+0x262/0x2c0
    do_syscall_64+0x77/0x230
    entry_SYSCALL_64_after_hwframe+0x49/0xbe

    Cc: Nicholas Bellinger
    Cc: Mike Christie
    Cc: Christoph Hellwig
    Cc: David Disseldorp
    Cc: Hannes Reinecke
    Signed-off-by: Bart Van Assche
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin

    Bart Van Assche
     
  • [ Upstream commit 0de263577de5d5e052be5f4f93334e63cc8a7f0b ]

    spc5r17.pdf specifies:

    4.3.1 ASCII data field requirements
    ASCII data fields shall contain only ASCII printable characters (i.e.,
    code values 20h to 7Eh) and may be terminated with one or more ASCII null
    (00h) characters. ASCII data fields described as being left-aligned
    shall have any unused bytes at the end of the field (i.e., highest
    offset) and the unused bytes shall be filled with ASCII space characters
    (20h).

    LIO currently space-pads the T10 VENDOR IDENTIFICATION and PRODUCT
    IDENTIFICATION fields in the standard INQUIRY data. However, the PRODUCT
    REVISION LEVEL field in the standard INQUIRY data as well as the T10 VENDOR
    IDENTIFICATION field in the INQUIRY Device Identification VPD Page are
    zero-terminated/zero-padded.

    Fix this inconsistency by using space-padding for all of the above fields.

    Signed-off-by: David Disseldorp
    Reviewed-by: Christoph Hellwig
    Reviewed-by: Bryant G. Ly
    Reviewed-by: Lee Duncan
    Reviewed-by: Hannes Reinecke
    Reviewed-by: Roman Bolshakov
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin

    David Disseldorp
     
  • [ Upstream commit 0fbe82e628c817e292ff588cd5847fc935e025f2 ]

    after set SO_DONTROUTE to 1, the IP layer should not route packets if
    the dest IP address is not in link scope. But if the socket has cached
    the dst_entry, such packets would be routed until the sk_dst_cache
    expires. So we should clean the sk_dst_cache when a user set
    SO_DONTROUTE option. Below are server/client python scripts which
    could reprodue this issue:

    server side code:

    ==========================================================================
    import socket
    import struct
    import time

    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.bind(('0.0.0.0', 9000))
    s.listen(1)
    sock, addr = s.accept()
    sock.setsockopt(socket.SOL_SOCKET, socket.SO_DONTROUTE, struct.pack('i', 1))
    while True:
    sock.send(b'foo')
    time.sleep(1)
    ==========================================================================

    client side code:
    ==========================================================================
    import socket
    import time

    s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    s.connect(('server_address', 9000))
    while True:
    data = s.recv(1024)
    print(data)
    ==========================================================================

    Signed-off-by: yupeng
    Signed-off-by: David S. Miller
    Signed-off-by: Sasha Levin

    yupeng
     
  • [ Upstream commit 848bd9acdcd00c164b42b14aacec242949ecd471 ]

    The root cause is the race as follows:
    Thread #0 Thread #1

    z_erofs_vle_unzip_kickoff z_erofs_submit_and_unzip

    struct z_erofs_vle_unzip_io io[]
    atomic_add_return()
    wait_event()
    [end of function]
    wake_up()

    Fix it by taking the waitqueue lock between atomic_add_return and
    wake_up to close such the race.

    kernel message:

    Unable to handle kernel paging request at virtual address 97f7052caa1303dc
    ...
    Workqueue: kverityd verity_work
    task: ffffffe32bcb8000 task.stack: ffffffe3298a0000
    PC is at __wake_up_common+0x48/0xa8
    LR is at __wake_up+0x3c/0x58
    ...
    Call trace:
    ...
    [] __wake_up_common+0x48/0xa8
    [] __wake_up+0x3c/0x58
    [] z_erofs_vle_unzip_kickoff+0x40/0x64
    [] z_erofs_vle_read_endio+0x94/0x134
    [] bio_endio+0xe4/0xf8
    [] dec_pending+0x134/0x32c
    [] clone_endio+0x90/0xf4
    [] bio_endio+0xe4/0xf8
    [] verity_work+0x210/0x368
    [] process_one_work+0x188/0x4b4
    [] worker_thread+0x140/0x458
    [] kthread+0xec/0x108
    [] ret_from_fork+0x10/0x1c
    Code: d1006273 54000260 f9400804 b9400019 (b85fc081)
    ---[ end trace be9dde154f677cd1 ]---

    Reviewed-by: Chao Yu
    Signed-off-by: Gao Xiang
    Signed-off-by: Greg Kroah-Hartman

    Signed-off-by: Sasha Levin

    Gao Xiang
     
  • [ Upstream commit de2563bce7a157f5296bab94f3843d7d64fb14b4 ]

    Turning on CONFIG_DMA_API_DEBUG_SG results in the following error:

    [ 460.308650] ------------[ cut here ]------------
    [ 460.313490] qcom-venus aa00000.video-codec: DMA-API: mapping sg segment longer than device claims to support [len=4194304] [max=65536]
    [ 460.326017] WARNING: CPU: 3 PID: 3555 at src/kernel/dma/debug.c:1301 debug_dma_map_sg+0x174/0x254
    [ 460.338888] Modules linked in: venus_dec venus_enc videobuf2_dma_sg videobuf2_memops hci_uart btqca bluetooth venus_core v4l2_mem2mem videobuf2_v4l2 videobuf2_common ath10k_snoc ath10k_core ath lzo lzo_compress zramjoydev
    [ 460.375811] CPU: 3 PID: 3555 Comm: V4L2DecoderThre Tainted: G W 4.19.1 #82
    [ 460.384223] Hardware name: Google Cheza (rev1) (DT)
    [ 460.389251] pstate: 60400009 (nZCv daif +PAN -UAO)
    [ 460.394191] pc : debug_dma_map_sg+0x174/0x254
    [ 460.398680] lr : debug_dma_map_sg+0x174/0x254
    [ 460.403162] sp : ffffff80200c37d0
    [ 460.406583] x29: ffffff80200c3830 x28: 0000000000010000
    [ 460.412056] x27: 00000000ffffffff x26: ffffffc0f785ea80
    [ 460.417532] x25: 0000000000000000 x24: ffffffc0f4ea1290
    [ 460.423001] x23: ffffffc09e700300 x22: ffffffc0f4ea1290
    [ 460.428470] x21: ffffff8009037000 x20: 0000000000000001
    [ 460.433936] x19: ffffff80091b0000 x18: 0000000000000000
    [ 460.439411] x17: 0000000000000000 x16: 000000000000f251
    [ 460.444885] x15: 0000000000000006 x14: 0720072007200720
    [ 460.450354] x13: ffffff800af536e0 x12: 0000000000000000
    [ 460.455822] x11: 0000000000000000 x10: 0000000000000000
    [ 460.461288] x9 : 537944d9c6c48d00 x8 : 537944d9c6c48d00
    [ 460.466758] x7 : 0000000000000000 x6 : ffffffc0f8d98f80
    [ 460.472230] x5 : 0000000000000000 x4 : 0000000000000000
    [ 460.477703] x3 : 000000000000008a x2 : ffffffc0fdb13948
    [ 460.483170] x1 : ffffffc0fdb0b0b0 x0 : 000000000000007a
    [ 460.488640] Call trace:
    [ 460.491165] debug_dma_map_sg+0x174/0x254
    [ 460.495307] vb2_dma_sg_alloc+0x260/0x2dc [videobuf2_dma_sg]
    [ 460.501150] __vb2_queue_alloc+0x164/0x374 [videobuf2_common]
    [ 460.507076] vb2_core_reqbufs+0xfc/0x23c [videobuf2_common]
    [ 460.512815] vb2_reqbufs+0x44/0x5c [videobuf2_v4l2]
    [ 460.517853] v4l2_m2m_reqbufs+0x44/0x78 [v4l2_mem2mem]
    [ 460.523144] v4l2_m2m_ioctl_reqbufs+0x1c/0x28 [v4l2_mem2mem]
    [ 460.528976] v4l_reqbufs+0x30/0x40
    [ 460.532480] __video_do_ioctl+0x36c/0x454
    [ 460.536610] video_usercopy+0x25c/0x51c
    [ 460.540572] video_ioctl2+0x38/0x48
    [ 460.544176] v4l2_ioctl+0x60/0x74
    [ 460.547602] do_video_ioctl+0x948/0x3520
    [ 460.551648] v4l2_compat_ioctl32+0x60/0x98
    [ 460.555872] __arm64_compat_sys_ioctl+0x134/0x20c
    [ 460.560718] el0_svc_common+0x9c/0xe4
    [ 460.564498] el0_svc_compat_handler+0x2c/0x38
    [ 460.568982] el0_svc_compat+0x8/0x18
    [ 460.572672] ---[ end trace ce209b87b2f3af88 ]---

    >From above warning one would deduce that the sg segment will overflow
    the device's capacity. In reality, the hardware can accommodate larger
    sg segments.
    So, initialize the max segment size properly to weed out this warning.

    Based on a similar patch sent by Sean Paul for mdss:
    https://patchwork.kernel.org/patch/10671457/

    Signed-off-by: Vivek Gautam
    Acked-by: Stanimir Varbanov
    Signed-off-by: Hans Verkuil
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Sasha Levin

    Vivek Gautam
     
  • [ Upstream commit 23aa128bb28d9da69bb1bdb2b70e50128857884a ]

    AMD platform device acp_audio_dma can only be created by parent PCI
    device driver (drivers/gpu/drm/amd/amdgpu/amdgpu_acp.c). Pass struct
    device of the parent to snd_pcm_lib_preallocate_pages() so
    dma_alloc_coherent() can use correct dma_ops. Otherwise, it will
    use default dma_ops which is nommu_dma_ops on x86_64 even when
    IOMMU is enabled and set to non passthrough mode.

    Though platform device inherits some dma related fields during its
    creation in mfd_add_device(), we can't simply pass its struct device
    to snd_pcm_lib_preallocate_pages() because dma_ops is not among the
    inherited fields. Even it were, drivers/iommu/amd_iommu.c would
    ignore it because get_device_id() doesn't handle platform device.

    This change shouldn't give us any trouble even struct device of the
    parent becomes null or represents some non PCI device in the future,
    because get_dma_ops() correctly handles null struct device or uses
    the default dma_ops if struct device doesn't have it set.

    Signed-off-by: Yu Zhao
    Signed-off-by: Mark Brown
    Signed-off-by: Sasha Levin

    Yu Zhao
     
  • [ Upstream commit b2e9a4eda11fd2cb1e6714e9ad3f455c402568ff ]

    Clang warns:

    drivers/media/firewire/firedtv-avc.c:999:45: warning: implicit
    conversion from 'int' to 'char' changes value from 159 to -97
    [-Wconstant-conversion]
    app_info[0] = (EN50221_TAG_APP_INFO >> 16) & 0xff;
    ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
    drivers/media/firewire/firedtv-avc.c:1000:45: warning: implicit
    conversion from 'int' to 'char' changes value from 128 to -128
    [-Wconstant-conversion]
    app_info[1] = (EN50221_TAG_APP_INFO >> 8) & 0xff;
    ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
    drivers/media/firewire/firedtv-avc.c:1040:44: warning: implicit
    conversion from 'int' to 'char' changes value from 159 to -97
    [-Wconstant-conversion]
    app_info[0] = (EN50221_TAG_CA_INFO >> 16) & 0xff;
    ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
    drivers/media/firewire/firedtv-avc.c:1041:44: warning: implicit
    conversion from 'int' to 'char' changes value from 128 to -128
    [-Wconstant-conversion]
    app_info[1] = (EN50221_TAG_CA_INFO >> 8) & 0xff;
    ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~
    4 warnings generated.

    Change app_info's type to unsigned char to match the type of the
    member msg in struct ca_msg, which is the only thing passed into the
    app_info parameter in this function.

    Link: https://github.com/ClangBuiltLinux/linux/issues/105

    Signed-off-by: Nathan Chancellor
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Sasha Levin

    Nathan Chancellor
     
  • [ Upstream commit 2b038cbc5fcf12a7ee1cc9bfd5da1e46dacdee87 ]

    When booting a pseries kernel with PREEMPT enabled, it dumps the
    following warning:

    BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
    caller is pseries_processor_idle_init+0x5c/0x22c
    CPU: 13 PID: 1 Comm: swapper/0 Not tainted 4.20.0-rc3-00090-g12201a0128bc-dirty #828
    Call Trace:
    [c000000429437ab0] [c0000000009c8878] dump_stack+0xec/0x164 (unreliable)
    [c000000429437b00] [c0000000005f2f24] check_preemption_disabled+0x154/0x160
    [c000000429437b90] [c000000000cab8e8] pseries_processor_idle_init+0x5c/0x22c
    [c000000429437c10] [c000000000010ed4] do_one_initcall+0x64/0x300
    [c000000429437ce0] [c000000000c54500] kernel_init_freeable+0x3f0/0x500
    [c000000429437db0] [c0000000000112dc] kernel_init+0x2c/0x160
    [c000000429437e20] [c00000000000c1d0] ret_from_kernel_thread+0x5c/0x6c

    This happens because the code calls get_lppaca() which calls
    get_paca() and it checks if preemption is disabled through
    check_preemption_disabled().

    Preemption should be disabled because the per CPU variable may make no
    sense if there is a preemption (and a CPU switch) after it reads the
    per CPU data and when it is used.

    In this device driver specifically, it is not a problem, because this
    code just needs to have access to one lppaca struct, and it does not
    matter if it is the current per CPU lppaca struct or not (i.e. when
    there is a preemption and a CPU migration).

    That said, the most appropriate fix seems to be related to avoiding
    the debug_smp_processor_id() call at get_paca(), instead of calling
    preempt_disable() before get_paca().

    Signed-off-by: Breno Leitao
    Signed-off-by: Michael Ellerman
    Signed-off-by: Sasha Levin

    Breno Leitao
     
  • [ Upstream commit 8d4a862276a9c30a269d368d324fb56529e6d5fd ]

    Currently xmon needs to get devtree_lock (through rtas_token()) during its
    invocation (at crash time). If there is a crash while devtree_lock is being
    held, then xmon tries to get the lock but spins forever and never get into
    the interactive debugger, as in the following case:

    int *ptr = NULL;
    raw_spin_lock_irqsave(&devtree_lock, flags);
    *ptr = 0xdeadbeef;

    This patch avoids calling rtas_token(), thus trying to get the same lock,
    at crash time. This new mechanism proposes getting the token at
    initialization time (xmon_init()) and just consuming it at crash time.

    This would allow xmon to be possible invoked independent of devtree_lock
    being held or not.

    Signed-off-by: Breno Leitao
    Reviewed-by: Thiago Jung Bauermann
    Signed-off-by: Michael Ellerman
    Signed-off-by: Sasha Levin

    Breno Leitao
     
  • [ Upstream commit 10e1fdb95809ed21406f53b5b4f064673a1b9ceb ]

    Currently, disconnecting a USB webcam while it is in use prints out a
    number of warnings, such as:

    WARNING: CPU: 2 PID: 3118 at /build/linux-ezBi1T/linux-4.8.0/fs/sysfs/group.c:237 sysfs_remove_group+0x8b/0x90
    sysfs group ffffffffa7cd0780 not found for kobject 'event13'

    This has been noticed before. [0]

    This is because of the order in which things are torn down.

    If there are no streams active during a USB disconnect:

    - uvc_disconnect() is invoked via device_del() through the bus
    notifier mechanism.

    - this calls uvc_unregister_video().

    - uvc_unregister_video() unregisters the video device for each
    stream,

    - because there are no streams open, it calls uvc_delete()

    - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
    input device.

    - uvc_delete() calls media_device_unregister(), which cleans up the
    media device

    - uvc_delete(), uvc_unregister_video() and uvc_disconnect() all
    return, and we end up back in device_del().

    - device_del() then cleans up the sysfs folder for the camera with
    dpm_sysfs_remove(). Because uvc_status_cleanup() and
    media_device_unregister() have already been called, this all works
    nicely.

    If, on the other hand, there *are* streams active during a USB disconnect:

    - uvc_disconnect() is invoked

    - this calls uvc_unregister_video()

    - uvc_unregister_video() unregisters the video device for each
    stream,

    - uvc_unregister_video() and uvc_disconnect() return, and we end up
    back in device_del().

    - device_del() then cleans up the sysfs folder for the camera with
    dpm_sysfs_remove(). Because the status input device and the media
    device are children of the USB device, this also deletes their
    sysfs folders.

    - Sometime later, the final stream is closed, invoking uvc_release().

    - uvc_release() calls uvc_delete()

    - uvc_delete() calls uvc_status_cleanup(), which cleans up the status
    input device. Because the sysfs directory has already been removed,
    this causes a WARNing.

    - uvc_delete() calls media_device_unregister(), which cleans up the
    media device. Because the sysfs directory has already been removed,
    this causes another WARNing.

    To fix this, we need to make sure the devices are always unregistered
    before the end of uvc_disconnect(). To this, move the unregistration
    into the disconnect path:

    - split uvc_status_cleanup() into two parts, one on disconnect that
    unregisters and one on delete that frees.

    - move v4l2_device_unregister() and media_device_unregister() into
    the disconnect path.

    [0]: https://lkml.org/lkml/2016/12/8/657

    [Renamed uvc_input_cleanup() to uvc_input_unregister()]

    Signed-off-by: Daniel Axtens
    Acked-by: Greg Kroah-Hartman
    Signed-off-by: Laurent Pinchart
    Signed-off-by: Mauro Carvalho Chehab
    Signed-off-by: Sasha Levin

    Daniel Axtens
     
  • [ Upstream commit 30696378f68a9e3dad6bfe55938b112e72af00c2 ]

    The ramoops backend currently calls persistent_ram_save_old() even
    if a buffer is empty. While this appears to work, it is does not seem
    like the right thing to do and could lead to future bugs so lets avoid
    that. It also prevents misleading prints in the logs which claim the
    buffer is valid.

    I got something like:

    found existing buffer, size 0, start 0

    When I was expecting:

    no valid data in buffer (sig = ...)

    This bails out early (and reports with pr_debug()), since it's an
    acceptable state.

    Signed-off-by: Joel Fernandes (Google)
    Co-developed-by: Kees Cook
    Signed-off-by: Kees Cook
    Signed-off-by: Sasha Levin

    Joel Fernandes (Google)
     
  • [ Upstream commit 9e5ef7a57ca75a1b9411c46caeeb6881124284a3 ]

    As the commit 2893c379461a ("clk: make strings in parent name arrays
    const"), let's make the parent strings const, otherwise we may meet
    the following warning when compiling:

    drivers/clk/imx/clk-imx7ulp.c: In function 'imx7ulp_clocks_init':
    drivers/clk/imx/clk-imx7ulp.c:73:35: warning: passing argument 5 of
    'imx_clk_mux_flags' discards 'const' qualifier from pointer target type

    clks[IMX7ULP_CLK_APLL_PRE_SEL] = imx_clk_mux_flags("apll_pre_sel", base + 0x508, 0,
    1, pll_pre_sels, ARRAY_SIZE(pll_pre_sels), CLK_SET_PARENT_GATE);
    ^
    In file included from drivers/clk/imx/clk-imx7ulp.c:23:0:
    drivers/clk/imx/clk.h:200:27: note: expected 'const char **' but argument is
    of type 'const char * const*'
    ...

    Cc: Stephen Boyd
    Cc: Michael Turquette
    Cc: Shawn Guo
    Signed-off-by: Dong Aisheng
    Signed-off-by: Stephen Boyd
    Signed-off-by: Sasha Levin

    A.s. Dong
     
  • [ Upstream commit a788c5272769ddbcdbab297cf386413eeac04463 ]

    jffs2_sync_fs makes the assumption that if CONFIG_JFFS2_FS_WRITEBUFFER
    is defined then a write buffer is available and has been initialized.
    However, this does is not the case when the mtd device has no
    out-of-band buffer:

    int jffs2_nand_flash_setup(struct jffs2_sb_info *c)
    {
    if (!c->mtd->oobsize)
    return 0;
    ...

    The resulting call to cancel_delayed_work_sync passing a uninitialized
    (but zeroed) delayed_work struct forces lockdep to become disabled.

    [ 90.050639] overlayfs: upper fs does not support tmpfile.
    [ 90.652264] INFO: trying to register non-static key.
    [ 90.662171] the code is fine but needs lockdep annotation.
    [ 90.673090] turning off the locking correctness validator.
    [ 90.684021] CPU: 0 PID: 1762 Comm: mount_root Not tainted 4.14.63 #0
    [ 90.696672] Stack : 00000000 00000000 80d8f6a2 00000038 805f0000 80444600 8fe364f4 805dfbe7
    [ 90.713349] 80563a30 000006e2 8068370c 00000001 00000000 00000001 8e2fdc48 ffffffff
    [ 90.730020] 00000000 00000000 80d90000 00000000 00000106 00000000 6465746e 312e3420
    [ 90.746690] 6b636f6c 03bf0000 f8000000 20676e69 00000000 80000000 00000000 8e2c2a90
    [ 90.763362] 80d90000 00000001 00000000 8e2c2a90 00000003 80260dc0 08052098 80680000
    [ 90.780033] ...
    [ 90.784902] Call Trace:
    [ 90.789793] [] show_stack+0xb8/0x148
    [ 90.798659] [] register_lock_class+0x270/0x55c
    [ 90.809247] [] __lock_acquire+0x13c/0xf7c
    [ 90.818964] [] lock_acquire+0x194/0x1dc
    [ 90.828345] [] flush_work+0x200/0x24c
    [ 90.837374] [] __cancel_work_timer+0x158/0x210
    [ 90.847958] [] jffs2_sync_fs+0x20/0x54
    [ 90.857173] [] iterate_supers+0xf4/0x120
    [ 90.866729] [] sys_sync+0x44/0x9c
    [ 90.875067] [] syscall_common+0x34/0x58

    Signed-off-by: Daniel Santos
    Reviewed-by: Hou Tao
    Signed-off-by: Boris Brezillon
    Signed-off-by: Sasha Levin

    Daniel Santos
     
  • [ Upstream commit 3db5e0ba8b8f4aee631d7ee04b7a11c56cfdc213 ]

    When building the kernel with Clang, some disabled warnings appear
    because this Makefile overrides KBUILD_CFLAGS for x86{,_64}. Add them to
    this list so that the build is clean again.

    -Wpointer-sign was disabled for the whole kernel before the beginning of Git history.

    -Waddress-of-packed-member was disabled for the whole kernel and for
    the early boot code in these commits:

    bfb38988c51e ("kbuild: clang: Disable 'address-of-packed-member' warning")
    20c6c1890455 ("x86/boot: Disable the address-of-packed-member compiler warning").

    -Wgnu was disabled for the whole kernel and for the early boot code in
    these commits:

    61163efae020 ("kbuild: LLVMLinux: Add Kbuild support for building kernel with Clang")
    6c3b56b19730 ("x86/boot: Disable Clang warnings about GNU extensions").

    [ mingo: Made the changelog more readable. ]

    Tested-by: Sedat Dilek
    Signed-off-by: Nathan Chancellor
    Signed-off-by: Ard Biesheuvel
    Reviewed-by: Sedat Dilek
    Cc: Andy Lutomirski
    Cc: Arend van Spriel
    Cc: Bhupesh Sharma
    Cc: Borislav Petkov
    Cc: Dave Hansen
    Cc: Eric Snowberg
    Cc: Hans de Goede
    Cc: Joe Perches
    Cc: Jon Hunter
    Cc: Julien Thierry
    Cc: Linus Torvalds
    Cc: Marc Zyngier
    Cc: Matt Fleming
    Cc: Peter Zijlstra
    Cc: Sai Praneeth Prakhya
    Cc: Thomas Gleixner
    Cc: YiFei Zhu
    Cc: linux-efi@vger.kernel.org
    Link: http://lkml.kernel.org/r/20181129171230.18699-8-ard.biesheuvel@linaro.org
    Link: https://github.com/ClangBuiltLinux/linux/issues/112
    Signed-off-by: Ingo Molnar
    Signed-off-by: Sasha Levin

    Nathan Chancellor
     
  • [ Upstream commit b024dd0eba6e6d568f69d63c5e3153aba94c23e3 ]

    FRWR memory registration is done with a series of calls and WRs.
    1. ULP invokes ib_dma_map_sg()
    2. ULP invokes ib_map_mr_sg()
    3. ULP posts an IB_WR_REG_MR on the Send queue

    Step 2 generates an iova. It is permissible for ULPs to change this
    iova (with certain restrictions) between steps 2 and 3.

    rxe_map_mr_sg captures the MR's iova but later when rxe processes the
    REG_MR WR, it ignores the MR's iova field. If a ULP alters the MR's iova
    after step 2 but before step 3, rxe never captures that change.

    When the remote sends an RDMA Read targeting that MR, rxe looks up the
    R_key, but the altered iova does not match the iova stored in the MR,
    causing the RDMA Read request to fail.

    Reported-by: Anna Schumaker
    Signed-off-by: Chuck Lever
    Reviewed-by: Sagi Grimberg
    Signed-off-by: Jason Gunthorpe
    Signed-off-by: Sasha Levin

    Chuck Lever
     
  • [ Upstream commit 3b34c14fd50c302db091f020f26dd00ede902c80 ]

    As amd_uvd_resume() accesses the uvd ring, it must be initialised first
    or else we trigger errors like:

    [ 5.595963] [drm] Found UVD firmware Version: 1.87 Family ID: 17
    [ 5.595969] [drm] PSP loading UVD firmware
    [ 5.596266] ------------[ cut here ]------------
    [ 5.596268] ODEBUG: assert_init not available (active state 0) object type: timer_list hint: (null)
    [ 5.596285] WARNING: CPU: 0 PID: 507 at lib/debugobjects.c:329 debug_print_object+0x6a/0x80
    [ 5.596286] Modules linked in: amdgpu(+) hid_logitech_hidpp(+) chash gpu_sched amd_iommu_v2 ttm drm_kms_helper crc32c_intel drm hid_sony ff_memless igb hid_logitech_dj nvme dca i2c_algo_bit nvme_core wmi pinctrl_amd uas usb_storage
    [ 5.596299] CPU: 0 PID: 507 Comm: systemd-udevd Tainted: G W 4.20.0-0.rc1.git4.1.fc30.x86_64 #1
    [ 5.596301] Hardware name: System manufacturer System Product Name/ROG STRIX X470-I GAMING, BIOS 0901 07/23/2018
    [ 5.596303] RIP: 0010:debug_print_object+0x6a/0x80
    [ 5.596305] Code: 8b 43 10 83 c2 01 8b 4b 14 4c 89 e6 89 15 e6 82 b0 02 4c 8b 45 00 48 c7 c7 60 fd 34 a6 48 8b 14 c5 a0 da 08 a6 e8 6a 6a b8 ff 0b 5b 83 05 d0 45 3e 01 01 5d 41 5c c3 83 05 c5 45 3e 01 01 c3
    [ 5.596306] RSP: 0018:ffffa02ac863f8c0 EFLAGS: 00010282
    [ 5.596307] RAX: 0000000000000000 RBX: ffffa02ac863f8e0 RCX: 0000000000000006
    [ 5.596308] RDX: 0000000000000007 RSI: ffff9160e9a7bfe8 RDI: ffff9160f91d6c60
    [ 5.596310] RBP: ffffffffa6742740 R08: 0000000000000002 R09: 0000000000000000
    [ 5.596311] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffffa634ff69
    [ 5.596312] R13: 00000000000b79d0 R14: ffffffffa80f76d8 R15: 0000000000266000
    [ 5.596313] FS: 00007f762abf7940(0000) GS:ffff9160f9000000(0000) knlGS:0000000000000000
    [ 5.596314] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [ 5.596315] CR2: 000055fdc593f000 CR3: 00000007e999c000 CR4: 00000000003406f0
    [ 5.596317] Call Trace:
    [ 5.596321] debug_object_assert_init+0x14a/0x180
    [ 5.596327] del_timer+0x2e/0x90
    [ 5.596383] amdgpu_fence_process+0x47/0x100 [amdgpu]
    [ 5.596430] amdgpu_uvd_resume+0xf6/0x120 [amdgpu]
    [ 5.596475] uvd_v7_0_sw_init+0xe0/0x280 [amdgpu]
    [ 5.596523] amdgpu_device_init.cold.30+0xf97/0x14b6 [amdgpu]
    [ 5.596563] ? amdgpu_driver_load_kms+0x53/0x330 [amdgpu]
    [ 5.596604] amdgpu_driver_load_kms+0x86/0x330 [amdgpu]
    [ 5.596614] drm_dev_register+0x115/0x150 [drm]
    [ 5.596654] amdgpu_pci_probe+0xbd/0x120 [amdgpu]
    [ 5.596658] local_pci_probe+0x41/0x90
    [ 5.596661] pci_device_probe+0x188/0x1a0
    [ 5.596666] really_probe+0xf8/0x3b0
    [ 5.596669] driver_probe_device+0xb3/0xf0
    [ 5.596672] __driver_attach+0xe1/0x110
    [ 5.596674] ? driver_probe_device+0xf0/0xf0
    [ 5.596676] bus_for_each_dev+0x79/0xc0
    [ 5.596679] bus_add_driver+0x155/0x230
    [ 5.596681] ? 0xffffffffc07d9000
    [ 5.596683] driver_register+0x6b/0xb0
    [ 5.596685] ? 0xffffffffc07d9000
    [ 5.596688] do_one_initcall+0x5d/0x2be
    [ 5.596691] ? rcu_read_lock_sched_held+0x79/0x80
    [ 5.596693] ? kmem_cache_alloc_trace+0x264/0x290
    [ 5.596695] ? do_init_module+0x22/0x210
    [ 5.596698] do_init_module+0x5a/0x210
    [ 5.596701] load_module+0x2137/0x2430
    [ 5.596703] ? lockdep_hardirqs_on+0xed/0x180
    [ 5.596714] ? __do_sys_init_module+0x150/0x1a0
    [ 5.596715] __do_sys_init_module+0x150/0x1a0
    [ 5.596722] do_syscall_64+0x60/0x1f0
    [ 5.596725] entry_SYSCALL_64_after_hwframe+0x49/0xbe
    [ 5.596726] RIP: 0033:0x7f762b877dee
    [ 5.596728] Code: 48 8b 0d 9d 20 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 af 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d 6a 20 0c 00 f7 d8 64 89 01 48
    [ 5.596729] RSP: 002b:00007ffc777b8558 EFLAGS: 00000246 ORIG_RAX: 00000000000000af
    [ 5.596730] RAX: ffffffffffffffda RBX: 000055fdc48da320 RCX: 00007f762b877dee
    [ 5.596731] RDX: 00007f762b9f284d RSI: 00000000006c5fc6 RDI: 000055fdc527a060
    [ 5.596732] RBP: 00007f762b9f284d R08: 0000000000000003 R09: 0000000000000002
    [ 5.596733] R10: 000055fdc48ad010 R11: 0000000000000246 R12: 000055fdc527a060
    [ 5.596734] R13: 000055fdc48dca20 R14: 0000000000020000 R15: 0000000000000000
    [ 5.596740] irq event stamp: 134618
    [ 5.596743] hardirqs last enabled at (134617): [] console_unlock+0x45e/0x610
    [ 5.596744] hardirqs last disabled at (134618): [] trace_hardirqs_off_thunk+0x1a/0x1c
    [ 5.596746] softirqs last enabled at (133146): [] __do_softirq+0x365/0x47c
    [ 5.596748] softirqs last disabled at (133139): [] irq_exit+0x119/0x120
    [ 5.596749] ---[ end trace eaee508abfebccdc ]---

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108709
    Reviewed-by: Christian König
    Signed-off-by: Chris Wilson
    Cc: Alex Deucher
    Signed-off-by: Alex Deucher
    Signed-off-by: Sasha Levin

    Chris Wilson
     
  • [ Upstream commit d5632b11f0a17efa6356311e535ae135d178438d ]

    The kernel panic was observed after switch side perturbation,

    BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [] strcmp+0x20/0x40
    PGD 0 Oops: 0000 [#1] SMP
    CPU: 8 PID: 647 Comm: kworker/8:1 Tainted: G W OE ------------ 3.10.0-693.el7.x86_64 #1
    Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/20/2018
    Workqueue: slowpath-13:00. qed_slowpath_task [qed]
    task: ffff880429eb8fd0 ti: ffff880429190000 task.ti: ffff880429190000
    RIP: 0010:[] [] strcmp+0x20/0x40
    RSP: 0018:ffff880429193c68 EFLAGS: 00010202
    RAX: 000000000000000a RBX: 0000000000000002 RCX: 0000000000000000
    RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff88042bda7a41
    RBP: ffff880429193c68 R08: 000000000000ffff R09: 000000000000ffff
    R10: 0000000000000007 R11: ffff88042b3af338 R12: ffff880420b007a0
    R13: ffff88081aa56af8 R14: 0000000000000001 R15: ffff88081aa50410
    FS: 0000000000000000(0000) GS:ffff88042fe00000(0000) knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 0000000000000000 CR3: 00000000019f2000 CR4: 00000000003407e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Stack:
    ffff880429193d20 ffffffffc02a0c90 ffffc90004b32000 ffff8803fd3ec600
    ffff88042bda7800 ffff88042bda7a00 ffff88042bda7840 ffff88042bda7a40
    0000000129193d10 2e3836312e323931 ff000a342e363232 ffffffffc01ad99d
    Call Trace:
    [] qedi_get_protocol_tlv_data+0x270/0x470 [qedi]
    [] ? qed_mfw_process_tlv_req+0x24d/0xbf0 [qed]
    [] qed_mfw_fill_tlv_data+0x5e/0xd0 [qed]
    [] qed_mfw_process_tlv_req+0x269/0xbf0 [qed]

    Fix kernel NULL pointer deref by checking for session is online before
    getting iSCSI TLV data.

    Signed-off-by: Manish Rangankar
    Reviewed-by: Lee Duncan
    Signed-off-by: Martin K. Petersen
    Signed-off-by: Sasha Levin

    Manish Rangankar
     
  • [ Upstream commit 489db5d941500249583ec6b49fa70e006bd8f632 ]

    pcm3168 codec support runtime_[resume|suspend], whenever it
    is not active, it enters suspend mode, and it's clock and regulators
    will be disabled. so there is no need to disable them again in
    remove callback. Otherwise we got following kernel warnings,
    when unload pcm3168a driver

    [ 222.257514] unbalanced disables for amp-en-regulator
    [ 222.262526] ------------[ cut here ]------------
    [ 222.267158] WARNING: CPU: 0 PID: 2423 at drivers/regulator/core.c:2264 _regulator_disable+0x28/0x108
    [ 222.276291] Modules linked in:
    [ 222.279343] snd_soc_pcm3168a_i2c(-)
    [ 222.282916] snd_aloop
    [ 222.285272] arc4
    [ 222.287194] wl18xx
    [ 222.289289] wlcore
    [ 222.291385] mac80211
    [ 222.293654] cfg80211
    [ 222.295923] aes_ce_blk
    [ 222.298366] crypto_simd
    [ 222.300896] cryptd
    [ 222.302992] aes_ce_cipher
    [ 222.305696] crc32_ce
    [ 222.307965] ghash_ce
    [ 222.310234] aes_arm64
    [ 222.312590] gf128mul
    [ 222.314860] snd_soc_rcar
    [ 222.317476] sha2_ce
    [ 222.319658] xhci_plat_hcd
    [ 222.322362] sha256_arm64
    [ 222.324978] xhci_hcd
    [ 222.327247] sha1_ce
    [ 222.329430] renesas_usbhs
    [ 222.332133] evdev
    [ 222.334142] sha1_generic
    [ 222.336758] rcar_gen3_thermal
    [ 222.339810] cpufreq_dt
    [ 222.342253] ravb_streaming(C)
    [ 222.345304] wlcore_sdio
    [ 222.347834] thermal_sys
    [ 222.350363] udc_core
    [ 222.352632] mch_core(C)
    [ 222.355161] usb_dmac
    [ 222.357430] snd_soc_pcm3168a
    [ 222.360394] snd_soc_ak4613
    [ 222.363184] gpio_keys
    [ 222.365540] virt_dma
    [ 222.367809] nfsd
    [ 222.369730] ipv6
    [ 222.371652] autofs4
    [ 222.373834] [last unloaded: snd_soc_pcm3168a_i2c]
    [ 222.378629] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457
    [ 222.388196] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
    [ 222.396199] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
    [ 222.402117] PC is at _regulator_disable+0x28/0x108
    [ 222.406906] LR is at _regulator_disable+0x28/0x108
    [ 222.411695] pc : [] lr : [] pstate: 00000145
    [ 222.419089] sp : ffff00000a0a3c80
    [ 222.422401] x29: ffff00000a0a3c80
    [ 222.425799] x28: ffff8006fa8c6200
    [ 222.429199] x27: ffff0000086f1000
    [ 222.432597] x26: 000000000000006a
    [ 222.435997] x25: 0000000000000124
    [ 222.439395] x24: 0000000000000018
    [ 222.442795] x23: 0000000000000006
    [ 222.446193] x22: ffff8006f925d490
    [ 222.449592] x21: ffff8006f9ac2068
    [ 222.452991] x20: ffff8006f9ac2000
    [ 222.456390] x19: 0000000000000005
    [ 222.459787] x18: 000000000000000a
    [ 222.463186] x17: 0000000000000000
    [ 222.466584] x16: 0000000000000000
    [ 222.469984] x15: 000000000d3f616a
    [ 222.473382] x14: 0720072007200720
    [ 222.476781] x13: 0720072007200720
    [ 222.480179] x12: 0720072007200720
    [ 222.483578] x11: 0720072007200720
    [ 222.486975] x10: 0720072007200720
    [ 222.490375] x9 : 0720072007200720
    [ 222.493773] x8 : 07200772076f0774
    [ 222.497172] x7 : 0000000000000000
    [ 222.500570] x6 : 0000000000000007
    [ 222.503969] x5 : 0000000000000000
    [ 222.507367] x4 : 0000000000000000
    [ 222.510766] x3 : 0000000000000000
    [ 222.514164] x2 : c790b852091e2600
    [ 222.517563] x1 : 0000000000000000
    [ 222.520961] x0 : 0000000000000028
    [ 222.524361] Call trace:
    [ 222.526805] Exception stack(0xffff00000a0a3b40 to 0xffff00000a0a3c80)
    [ 222.533245] 3b40: 0000000000000028 0000000000000000 c790b852091e2600 0000000000000000
    [ 222.541075] 3b60: 0000000000000000 0000000000000000 0000000000000007 0000000000000000
    [ 222.548905] 3b80: 07200772076f0774 0720072007200720 0720072007200720 0720072007200720
    [ 222.556735] 3ba0: 0720072007200720 0720072007200720 0720072007200720 000000000d3f616a
    [ 222.564564] 3bc0: 0000000000000000 0000000000000000 000000000000000a 0000000000000005
    [ 222.572394] 3be0: ffff8006f9ac2000 ffff8006f9ac2068 ffff8006f925d490 0000000000000006
    [ 222.580224] 3c00: 0000000000000018 0000000000000124 000000000000006a ffff0000086f1000
    [ 222.588053] 3c20: ffff8006fa8c6200 ffff00000a0a3c80 ffff0000083bd89c ffff00000a0a3c80
    [ 222.595883] 3c40: ffff0000083bd89c 0000000000000145 0000000000000000 0000000000000000
    [ 222.603713] 3c60: 0000ffffffffffff ffff00000a0a3c30 ffff00000a0a3c80 ffff0000083bd89c
    [ 222.611543] [] _regulator_disable+0x28/0x108
    [ 222.617375] [] regulator_disable+0x48/0x68
    [ 222.623033] [] regulator_bulk_disable+0x58/0xc0
    [ 222.629134] [] pcm3168a_remove+0x30/0x50 [snd_soc_pcm3168a]
    [ 222.636270] [] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
    [ 222.644106] [] i2c_device_remove+0x38/0x70
    [ 222.649766] [] device_release_driver_internal+0xd0/0x1c0
    [ 222.656640] [] driver_detach+0x70/0x7c
    [ 222.661951] [] bus_remove_driver+0x74/0xa0
    [ 222.667609] [] driver_unregister+0x48/0x4c
    [ 222.673268] [] i2c_del_driver+0x24/0x30
    [ 222.678666] [] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
    [ 222.687019] [] SyS_delete_module+0x198/0x1d4
    [ 222.692850] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
    [ 222.699289] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
    [ 222.707119] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
    [ 222.714948] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
    [ 222.722778] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
    [ 222.730607] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
    [ 222.738436] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
    [ 222.746266] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
    [ 222.754096] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
    [ 222.761926] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
    [ 222.769755] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    [ 222.777589] [] el0_svc_naked+0x34/0x38
    [ 222.782899] ---[ end trace eaf8939a3698b1a8 ]---
    [ 222.787609] Failed to disable VCCDA2: -5
    [ 222.791649] ------------[ cut here ]------------
    [ 222.796283] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:595 clk_core_disable+0xc/0x1d8
    [ 222.804460] Modules linked in:
    [ 222.807511] snd_soc_pcm3168a_i2c(-)
    [ 222.811083] snd_aloop
    [ 222.813439] arc4
    [ 222.815360] wl18xx
    [ 222.817456] wlcore
    [ 222.819551] mac80211
    [ 222.821820] cfg80211
    [ 222.824088] aes_ce_blk
    [ 222.826531] crypto_simd
    [ 222.829060] cryptd
    [ 222.831155] aes_ce_cipher
    [ 222.833859] crc32_ce
    [ 222.836127] ghash_ce
    [ 222.838396] aes_arm64
    [ 222.840752] gf128mul
    [ 222.843020] snd_soc_rcar
    [ 222.845637] sha2_ce
    [ 222.847818] xhci_plat_hcd
    [ 222.850522] sha256_arm64
    [ 222.853138] xhci_hcd
    [ 222.855407] sha1_ce
    [ 222.857589] renesas_usbhs
    [ 222.860292] evdev
    [ 222.862300] sha1_generic
    [ 222.864917] rcar_gen3_thermal
    [ 222.867968] cpufreq_dt
    [ 222.870410] ravb_streaming(C)
    [ 222.873461] wlcore_sdio
    [ 222.875991] thermal_sys
    [ 222.878520] udc_core
    [ 222.880789] mch_core(C)
    [ 222.883318] usb_dmac
    [ 222.885587] snd_soc_pcm3168a
    [ 222.888551] snd_soc_ak4613
    [ 222.891341] gpio_keys
    [ 222.893696] virt_dma
    [ 222.895965] nfsd
    [ 222.897886] ipv6
    [ 222.899808] autofs4
    [ 222.901990] [last unloaded: snd_soc_pcm3168a_i2c]
    [ 222.906783] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457
    [ 222.916349] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
    [ 222.924351] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
    [ 222.930270] PC is at clk_core_disable+0xc/0x1d8
    [ 222.934799] LR is at clk_core_disable_lock+0x20/0x34
    [ 222.939761] pc : [] lr : [] pstate: 800001c5
    [ 222.947154] sp : ffff00000a0a3cf0
    [ 222.950466] x29: ffff00000a0a3cf0
    [ 222.953864] x28: ffff8006fa8c6200
    [ 222.957263] x27: ffff0000086f1000
    [ 222.960661] x26: 000000000000006a
    [ 222.964061] x25: 0000000000000124
    [ 222.967458] x24: 0000000000000015
    [ 222.970858] x23: ffff8006f9ffa8d0
    [ 222.974256] x22: ffff8006faf16480
    [ 222.977655] x21: ffff0000007e7040
    [ 222.981053] x20: ffff8006faadd100
    [ 222.984452] x19: 0000000000000140
    [ 222.987850] x18: 000000000000000a
    [ 222.991249] x17: 0000000000000000
    [ 222.994647] x16: 0000000000000000
    [ 222.998046] x15: 000000000d477819
    [ 223.001444] x14: 0720072007200720
    [ 223.004843] x13: 0720072007200720
    [ 223.008242] x12: 0720072007200720
    [ 223.011641] x11: 0720072007200720
    [ 223.015039] x10: 0720072007200720
    [ 223.018438] x9 : 0720072007200720
    [ 223.021837] x8 : 0720072007200720
    [ 223.025236] x7 : 0000000000000000
    [ 223.028634] x6 : 0000000000000007
    [ 223.032034] x5 : 0000000000000000
    [ 223.035432] x4 : 0000000000000000
    [ 223.038831] x3 : 0000000000000000
    [ 223.042229] x2 : 0000000004720471
    [ 223.045628] x1 : 0000000000000000
    [ 223.049026] x0 : ffff8006faadd100
    [ 223.052426] Call trace:
    [ 223.054870] Exception stack(0xffff00000a0a3bb0 to 0xffff00000a0a3cf0)
    [ 223.061309] 3ba0: ffff8006faadd100 0000000000000000
    [ 223.069139] 3bc0: 0000000004720471 0000000000000000 0000000000000000 0000000000000000
    [ 223.076969] 3be0: 0000000000000007 0000000000000000 0720072007200720 0720072007200720
    [ 223.084798] 3c00: 0720072007200720 0720072007200720 0720072007200720 0720072007200720
    [ 223.092628] 3c20: 0720072007200720 000000000d477819 0000000000000000 0000000000000000
    [ 223.100458] 3c40: 000000000000000a 0000000000000140 ffff8006faadd100 ffff0000007e7040
    [ 223.108287] 3c60: ffff8006faf16480 ffff8006f9ffa8d0 0000000000000015 0000000000000124
    [ 223.116117] 3c80: 000000000000006a ffff0000086f1000 ffff8006fa8c6200 ffff00000a0a3cf0
    [ 223.123947] 3ca0: ffff0000083acd28 ffff00000a0a3cf0 ffff0000083ab9b8 00000000800001c5
    [ 223.131777] 3cc0: ffff00000a0a3cf0 ffff0000083acd1c 0000ffffffffffff ffff8006faadd100
    [ 223.139606] 3ce0: ffff00000a0a3cf0 ffff0000083ab9b8
    [ 223.144483] [] clk_core_disable+0xc/0x1d8
    [ 223.150054] [] clk_disable+0x1c/0x28
    [ 223.155198] [] pcm3168a_remove+0x3c/0x50 [snd_soc_pcm3168a]
    [ 223.162334] [] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
    [ 223.170167] [] i2c_device_remove+0x38/0x70
    [ 223.175826] [] device_release_driver_internal+0xd0/0x1c0
    [ 223.182700] [] driver_detach+0x70/0x7c
    [ 223.188012] [] bus_remove_driver+0x74/0xa0
    [ 223.193669] [] driver_unregister+0x48/0x4c
    [ 223.199329] [] i2c_del_driver+0x24/0x30
    [ 223.204726] [] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
    [ 223.213079] [] SyS_delete_module+0x198/0x1d4
    [ 223.218909] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
    [ 223.225349] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
    [ 223.233179] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
    [ 223.241008] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
    [ 223.248838] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
    [ 223.256668] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
    [ 223.264497] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
    [ 223.272327] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
    [ 223.280157] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
    [ 223.287986] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
    [ 223.295816] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    [ 223.303648] [] el0_svc_naked+0x34/0x38
    [ 223.308958] ---[ end trace eaf8939a3698b1a9 ]---
    [ 223.313752] ------------[ cut here ]------------
    [ 223.318383] WARNING: CPU: 0 PID: 2423 at drivers/clk/clk.c:477 clk_core_unprepare+0xc/0x1ac
    [ 223.326733] Modules linked in:
    [ 223.329784] snd_soc_pcm3168a_i2c(-)
    [ 223.333356] snd_aloop
    [ 223.335712] arc4
    [ 223.337633] wl18xx
    [ 223.339728] wlcore
    [ 223.341823] mac80211
    [ 223.344092] cfg80211
    [ 223.346360] aes_ce_blk
    [ 223.348803] crypto_simd
    [ 223.351332] cryptd
    [ 223.353428] aes_ce_cipher
    [ 223.356131] crc32_ce
    [ 223.358400] ghash_ce
    [ 223.360668] aes_arm64
    [ 223.363024] gf128mul
    [ 223.365293] snd_soc_rcar
    [ 223.367909] sha2_ce
    [ 223.370091] xhci_plat_hcd
    [ 223.372794] sha256_arm64
    [ 223.375410] xhci_hcd
    [ 223.377679] sha1_ce
    [ 223.379861] renesas_usbhs
    [ 223.382564] evdev
    [ 223.384572] sha1_generic
    [ 223.387188] rcar_gen3_thermal
    [ 223.390239] cpufreq_dt
    [ 223.392682] ravb_streaming(C)
    [ 223.395732] wlcore_sdio
    [ 223.398261] thermal_sys
    [ 223.400790] udc_core
    [ 223.403059] mch_core(C)
    [ 223.405588] usb_dmac
    [ 223.407856] snd_soc_pcm3168a
    [ 223.410820] snd_soc_ak4613
    [ 223.413609] gpio_keys
    [ 223.415965] virt_dma
    [ 223.418234] nfsd
    [ 223.420155] ipv6
    [ 223.422076] autofs4
    [ 223.424258] [last unloaded: snd_soc_pcm3168a_i2c]
    [ 223.429050] CPU: 0 PID: 2423 Comm: rmmod Tainted: G WC 4.14.63-04798-gd456126e4a42-dirty #457
    [ 223.438616] Hardware name: Renesas H3ULCB Kingfisher board based on r8a7795 ES2.0+ (DT)
    [ 223.446618] task: ffff8006fa8c6200 task.stack: ffff00000a0a0000
    [ 223.452536] PC is at clk_core_unprepare+0xc/0x1ac
    [ 223.457239] LR is at clk_unprepare+0x28/0x3c
    [ 223.461506] pc : [] lr : [] pstate: 60000145
    [ 223.468900] sp : ffff00000a0a3d00
    [ 223.472211] x29: ffff00000a0a3d00
    [ 223.475609] x28: ffff8006fa8c6200
    [ 223.479009] x27: ffff0000086f1000
    [ 223.482407] x26: 000000000000006a
    [ 223.485807] x25: 0000000000000124
    [ 223.489205] x24: 0000000000000015
    [ 223.492604] x23: ffff8006f9ffa8d0
    [ 223.496003] x22: ffff8006faf16480
    [ 223.499402] x21: ffff0000007e7040
    [ 223.502800] x20: ffff8006faf16420
    [ 223.506199] x19: ffff8006faadd100
    [ 223.509597] x18: 000000000000000a
    [ 223.512997] x17: 0000000000000000
    [ 223.516395] x16: 0000000000000000
    [ 223.519794] x15: 0000000000000000
    [ 223.523192] x14: 00000033fe89076c
    [ 223.526591] x13: 0000000000000400
    [ 223.529989] x12: 0000000000000400
    [ 223.533388] x11: 0000000000000000
    [ 223.536786] x10: 00000000000009e0
    [ 223.540185] x9 : ffff00000a0a3be0
    [ 223.543583] x8 : ffff8006fa8c6c40
    [ 223.546982] x7 : ffff8006fa8c6400
    [ 223.550380] x6 : 0000000000000001
    [ 223.553780] x5 : 0000000000000000
    [ 223.557178] x4 : ffff8006fa8c6200
    [ 223.560577] x3 : 0000000000000000
    [ 223.563975] x2 : ffff8006fa8c6200
    [ 223.567374] x1 : 0000000000000000
    [ 223.570772] x0 : ffff8006faadd100
    [ 223.574170] Call trace:
    [ 223.576615] Exception stack(0xffff00000a0a3bc0 to 0xffff00000a0a3d00)
    [ 223.583054] 3bc0: ffff8006faadd100 0000000000000000 ffff8006fa8c6200 0000000000000000
    [ 223.590884] 3be0: ffff8006fa8c6200 0000000000000000 0000000000000001 ffff8006fa8c6400
    [ 223.598714] 3c00: ffff8006fa8c6c40 ffff00000a0a3be0 00000000000009e0 0000000000000000
    [ 223.606544] 3c20: 0000000000000400 0000000000000400 00000033fe89076c 0000000000000000
    [ 223.614374] 3c40: 0000000000000000 0000000000000000 000000000000000a ffff8006faadd100
    [ 223.622204] 3c60: ffff8006faf16420 ffff0000007e7040 ffff8006faf16480 ffff8006f9ffa8d0
    [ 223.630033] 3c80: 0000000000000015 0000000000000124 000000000000006a ffff0000086f1000
    [ 223.637863] 3ca0: ffff8006fa8c6200 ffff00000a0a3d00 ffff0000083ace4c ffff00000a0a3d00
    [ 223.645693] 3cc0: ffff0000083ab5a4 0000000060000145 0000000000000140 ffff8006faadd100
    [ 223.653523] 3ce0: 0000ffffffffffff ffff0000083ace44 ffff00000a0a3d00 ffff0000083ab5a4
    [ 223.661353] [] clk_core_unprepare+0xc/0x1ac
    [ 223.667103] [] pcm3168a_remove+0x44/0x50 [snd_soc_pcm3168a]
    [ 223.674239] [] pcm3168a_i2c_remove+0x10/0x1c [snd_soc_pcm3168a_i2c]
    [ 223.682070] [] i2c_device_remove+0x38/0x70
    [ 223.687731] [] device_release_driver_internal+0xd0/0x1c0
    [ 223.694604] [] driver_detach+0x70/0x7c
    [ 223.699915] [] bus_remove_driver+0x74/0xa0
    [ 223.705572] [] driver_unregister+0x48/0x4c
    [ 223.711230] [] i2c_del_driver+0x24/0x30
    [ 223.716628] [] pcm3168a_i2c_driver_exit+0x10/0xf98 [snd_soc_pcm3168a_i2c]
    [ 223.724980] [] SyS_delete_module+0x198/0x1d4
    [ 223.730811] Exception stack(0xffff00000a0a3ec0 to 0xffff00000a0a4000)
    [ 223.737250] 3ec0: 0000aaaafeb4b268 0000000000000800 14453f6470497100 0000fffffaa520d8
    [ 223.745079] 3ee0: 0000fffffaa520d9 000000000000000a 1999999999999999 0000000000000000
    [ 223.752909] 3f00: 000000000000006a 0000ffffa8f7d1d8 000000000000000a 0000000000000005
    [ 223.760739] 3f20: 0000000000000000 0000000000000000 000000000000002d 0000000000000000
    [ 223.768568] 3f40: 0000aaaae19b9f68 0000ffffa8f411f0 0000000000000000 0000aaaae19b9000
    [ 223.776398] 3f60: 0000fffffaa533b8 0000fffffaa531f0 0000000000000000 0000000000000001
    [ 223.784227] 3f80: 0000fffffaa53ec6 0000000000000000 0000aaaafeb4b200 0000aaaafeb4a010
    [ 223.792057] 3fa0: 0000000000000000 0000fffffaa53130 0000aaaae199f36c 0000fffffaa53130
    [ 223.799886] 3fc0: 0000ffffa8f411f8 0000000000000000 0000aaaafeb4b268 000000000000006a
    [ 223.807715] 3fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
    [ 223.815546] [] el0_svc_naked+0x34/0x38
    [ 223.820855] ---[ end trace eaf8939a3698b1aa ]---

    Fix this issue by only disable clock and regulators in remove callback
    when CONFIG_PM isn't defined

    Signed-off-by: Jiada Wang
    Signed-off-by: Mark Brown
    Signed-off-by: Sasha Levin

    Jiada Wang
     
  • [ Upstream commit 2cbdcb882f97a45f7475c67ac6257bbc16277dfe ]

    If a superblock has the MS_SUBMOUNT flag set, we should always allow
    mounting it. These mounts are done automatically by the kernel either as
    part of mounting some parent mount (e.g. debugfs always mounts tracefs
    under "tracing" for compatibility) or they are mounted automatically as
    needed on subdirectory accesses (e.g. NFS crossmnt mounts). Since such
    automounts are either an implicit consequence of the parent mount (which
    is already checked) or they can happen during regular accesses (where it
    doesn't make sense to check against the current task's context), the
    mount permission check should be skipped for them.

    Without this patch, attempts to access contents of an automounted
    directory can cause unexpected SELinux denials.

    In the current kernel tree, the MS_SUBMOUNT flag is set only via
    vfs_submount(), which is called only from the following places:
    - AFS, when automounting special "symlinks" referencing other cells
    - CIFS, when automounting "referrals"
    - NFS, when automounting subtrees
    - debugfs, when automounting tracefs

    In all cases the submounts are meant to be transparent to the user and
    it makes sense that if mounting the master is allowed, then so should be
    the automounts. Note that CAP_SYS_ADMIN capability checking is already
    skipped for (SB_KERNMOUNT|SB_SUBMOUNT) in:
    - sget_userns() in fs/super.c:
    if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) &&
    !(type->fs_flags & FS_USERNS_MOUNT) &&
    !capable(CAP_SYS_ADMIN))
    return ERR_PTR(-EPERM);
    - sget() in fs/super.c:
    /* Ensure the requestor has permissions over the target filesystem */
    if (!(flags & (SB_KERNMOUNT|SB_SUBMOUNT)) && !ns_capable(user_ns, CAP_SYS_ADMIN))
    return ERR_PTR(-EPERM);

    Verified internally on patched RHEL 7.6 with a reproducer using
    NFS+httpd and selinux-tesuite.

    Fixes: 93faccbbfa95 ("fs: Better permission checking for submounts")
    Signed-off-by: Ondrej Mosnacek
    Signed-off-by: Paul Moore
    Signed-off-by: Sasha Levin

    Ondrej Mosnacek
     
  • [ Upstream commit 30522a951f9d02f261d0697c35cb42205b1fae17 ]

    Currently registering CvP managers works only for first probed CvP
    device, for all other devices it is refused due to duplicated chkcfg
    sysfs entry:

    fpga_manager fpga3: Altera CvP FPGA Manager @0000:0c:00.0 registered
    sysfs: cannot create duplicate filename '/bus/pci/drivers/altera-cvp/chkcfg'
    CPU: 0 PID: 3808 Comm: bash Tainted: G O 4.19.0-custom+ #5
    Call Trace:
    dump_stack+0x46/0x5b
    sysfs_warn_dup+0x53/0x60
    sysfs_add_file_mode_ns+0x16d/0x180
    sysfs_create_file_ns+0x51/0x60
    altera_cvp_probe+0x16f/0x2a0 [altera_cvp]
    local_pci_probe+0x3f/0xa0
    ? pci_match_device+0xb1/0xf0
    pci_device_probe+0x116/0x170
    really_probe+0x21b/0x2c0
    driver_probe_device+0x4b/0xe0
    bind_store+0xcb/0x130
    kernfs_fop_write+0xfd/0x180
    __vfs_write+0x21/0x150
    ? selinux_file_permission+0xdc/0x130
    vfs_write+0xa8/0x1a0
    ? find_vma+0xd/0x60
    ksys_write+0x3d/0x90
    do_syscall_64+0x44/0xf0
    entry_SYSCALL_64_after_hwframe+0x44/0xa9
    ...
    altera-cvp 0000:0c:00.0: Can't create sysfs chkcfg file
    fpga_manager fpga3: fpga_mgr_unregister Altera CvP FPGA Manager @0000:0c:00.0

    Move chkcfg creation to module init as suggested by Alan.

    Signed-off-by: Anatolij Gustschin
    Acked-by: Alan Tull
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Sasha Levin

    Anatolij Gustschin
     
  • [ Upstream commit ceb94bc52c437463f0903e61060a94a2226fb672 ]

    This patch adds a safety connection way for "forced_b_device" with
    "workaround_for_vbus" like below:

    < Example for R-Car E3 Ebisu >
    # modprobe
    # echo 1 > /sys/kernel/debug/ee020000.usb/b_device
    (connect a usb cable to host side.)
    # echo 2 > /sys/kernel/debug/ee020000.usb/b_device

    Previous code should have connected a usb cable before the "b_device"
    is set to 1 on the Ebisu board. However, if xHCI driver on the board
    is probed, it causes some troubles:
    - Conflicts USB VBUS/signals between the board and another host.
    - "Cannot enable. Maybe the USB cable is bad?" might happen on
    both the board and another host with a usb hub.
    - Cannot enumerate a usb gadget correctly because an interruption
    of VBUS change happens unexpectedly.

    Reported-by: Kazuya Mizuguchi
    Signed-off-by: Yoshihiro Shimoda
    Signed-off-by: Felipe Balbi
    Signed-off-by: Sasha Levin

    Yoshihiro Shimoda
     
  • [ Upstream commit 5a863813216ce79e16a8c1503b2543c528b778b6 ]

    Currently, kprobe_events failure won't be handled properly.
    Due to calling system() indirectly to write to kprobe_events,
    it can't be identified whether an error is derived from kprobe or system.

    // buf = "echo '%c:%s %s' >> /s/k/d/t/kprobe_events"
    err = system(buf);
    if (err < 0) {
    printf("failed to create kprobe ..");
    return -1;
    }

    For example, running ./tracex7 sample in ext4 partition,
    "echo p:open_ctree open_ctree >> /s/k/d/t/kprobe_events"
    gets 256 error code system() failure.
    => The error comes from kprobe, but it's not handled correctly.

    According to man of system(3), it's return value
    just passes the termination status of the child shell
    rather than treating the error as -1. (don't care success)

    Which means, currently it's not working as desired.
    (According to the upper code snippet)

    ex) running ./tracex7 with ext4 env.
    # Current Output
    sh: echo: I/O error
    failed to open event open_ctree

    # Desired Output
    failed to create kprobe 'open_ctree' error 'No such file or directory'

    The problem is, error can't be verified whether from child ps
    or system. But using write() directly can verify the command
    failure, and it will treat all error as -1. So I suggest using
    write() directly to 'kprobe_events' rather than calling system().

    Signed-off-by: Daniel T. Lee
    Signed-off-by: Daniel Borkmann
    Signed-off-by: Sasha Levin

    Daniel T. Lee
     
  • [ Upstream commit ad9b2b8e53af61375322e3c7d624acf3a3ef53b0 ]

    The public S805 datasheet only mentions that
    HHI_SYS_CPU_CLK_CNTL1[20:29] contains a divider called "cpu_scale_div".
    Unfortunately it does not mention how to use the register contents.

    The Amlogic 3.10 GPL kernel sources are using the following code to
    calculate the CPU clock based on that register (taken from
    arch/arm/mach-meson8/clock.c in the 3.10 Amlogic kernel, shortened to
    make it easier to read):
    N = (aml_read_reg32(P_HHI_SYS_CPU_CLK_CNTL1) >> 20) & 0x3FF;
    if (sel == 3) /* use cpu_scale_div */
    div = 2 * N;
    else
    div = ... /* not relevant for this example */
    cpu_clk = parent_clk / div;

    This suggests that the formula is: parent_rate / 2 * register_value
    However, running perf (which can measure the CPU clock rate thanks to
    the ARM PMU) shows that this formula is not correct.
    This can be reproduced with the following steps:
    1. boot into u-boot
    2. let the CPU clock run off the XTAL clock:
    mw.l 0xC110419C 0x30 1
    3. set the cpu_scale_div register:
    to value 0x1: mw.l 0xC110415C 0x801016A2 1
    to value 0x2: mw.l 0xC110415C 0x802016A2 1
    to value 0x5: mw.l 0xC110415C 0x805016A2 1
    4. let the CPU clock run off cpu_scale_div:
    mw.l 0xC110419C 0xbd 1
    5. boot Linux
    6. run: perf stat -aB stress --cpu 4 --timeout 10
    7. check the "cycles" value

    I get the following results depending on the cpu_scale_div value:
    - (cpu_in_sel - this is the input clock for cpu_scale_div - runs at
    1.2GHz)
    - 0x1 = 300MHz
    - 0x2 = 200MHz
    - 0x5 = 100MHz

    This means that the actual formula to calculate the output of the
    cpu_scale_div clock is: parent_rate / 2 * (register value + 1).

    The register value 0x0 is reserved. When letting the CPU clock run off
    the cpu_scale_div while the value is 0x0 the whole board hangs (even in
    u-boot).

    I also verified this with the TWD timer: when adding this to the .dts
    without specifying it's clock it will auto-detect the PERIPH (which is
    the input clock of the TWD) clock rate (and the result is shown in the
    kernel log). On Meson8, Meson8b and Meson8m2 the PERIPH clock is CPUCLK
    divided by 4. This also matched for all three test-cases from above (in
    all cases the TWD timer clock rate was approx. one fourth of the CPU
    clock rate).

    A small note regarding the "fixes" tag: the original issue seems to
    exist virtually since forever. Even commit 28b9fcd016126e ("clk:
    meson8b: Add support for Meson8b clocks") seems to handle this wrong. I
    still decided to use commit 251b6fd38bcb9c ("clk: meson: rework meson8b
    cpu clock") because this is the first commit which gets the CPU hiearchy
    correct and thus it's the first commit where the cpu_scale_div register
    is used correctly (apart from the bug in the cpu_scale_table).

    Fixes: 251b6fd38bcb9c ("clk: meson: rework meson8b cpu clock")
    Signed-off-by: Martin Blumenstingl
    Signed-off-by: Neil Armstrong
    Link: https://lkml.kernel.org/r/20180927085921.24627-2-martin.blumenstingl@googlemail.com
    Signed-off-by: Sasha Levin

    Martin Blumenstingl
     
  • [ Upstream commit 2de42f79bb21a412f40ade8831eb6fc445cb78a4 ]

    Consider the following scenario:
    1. nonblocking enable crtc
    2. wait for the event
    3. nonblocking disable crtc

    On i915 this can lead to a spurious -EBUSY from step 3 on
    account of non-enabled planes getting the fake_commit in step 1
    and we don't complete the fake_commit-> flip_done until
    drm_atomic_helper_commit_hw_done() which can happen a long
    time after the flip event was sent out.

    This will become somewhat easy to hit on SKL+ once we start
    to add all the planes for the crtc to every modeset commit
    for the purposes of forcing a watermark register programming
    [1].

    To make the race a little less pronounced let's complete
    fake_commit->flip_done after drm_atomic_helper_wait_for_flip_done().
    For the single crtc case this should make the race quite
    theoretical, assuming drm_atomic_helper_wait_for_flip_done()
    actually has to wait for the real commit flip_done. In case
    the real commit flip_done gets completed singificantly before
    drm_atomic_helper_wait_for_flip_done(), or we are dealing with
    multiple crtcs whose vblanks don't line up nicely the race still
    exists.

    [1] https://patchwork.freedesktop.org/patch/262670/

    Cc: Maarten Lankhorst
    Fixes: 080de2e5be2d ("drm/atomic: Check for busy planes/connectors before setting the commit")
    Testcase: igt/kms_cursor_legacy/*nonblocking-modeset-vs-cursor-atomic
    Signed-off-by: Ville Syrjälä
    Link: https://patchwork.freedesktop.org/patch/msgid/20181122143412.11655-1-ville.syrjala@linux.intel.com
    Reviewed-by: Maarten Lankhorst
    Signed-off-by: Sasha Levin

    Ville Syrjälä
     
  • [ Upstream commit 81e9fa8bab381f8b6eb04df7cdf0f71994099bd4 ]

    The armv8_pmuv3 driver doesn't have a remove function, and when the test
    'CONFIG_DEBUG_TEST_DRIVER_REMOVE=y' is enabled, the following Call trace
    can be seen.

    [ 1.424287] Failed to register pmu: armv8_pmuv3, reason -17
    [ 1.424870] WARNING: CPU: 0 PID: 1 at ../kernel/events/core.c:11771 perf_event_sysfs_init+0x98/0xdc
    [ 1.425220] Modules linked in:
    [ 1.425531] CPU: 0 PID: 1 Comm: swapper/0 Tainted: G W 4.19.0-rc7-next-20181012-00003-ge7a97b1ad77b-dirty #35
    [ 1.425951] Hardware name: linux,dummy-virt (DT)
    [ 1.426212] pstate: 80000005 (Nzcv daif -PAN -UAO)
    [ 1.426458] pc : perf_event_sysfs_init+0x98/0xdc
    [ 1.426720] lr : perf_event_sysfs_init+0x98/0xdc
    [ 1.426908] sp : ffff00000804bd50
    [ 1.427077] x29: ffff00000804bd50 x28: ffff00000934e078
    [ 1.427429] x27: ffff000009546000 x26: 0000000000000007
    [ 1.427757] x25: ffff000009280710 x24: 00000000ffffffef
    [ 1.428086] x23: ffff000009408000 x22: 0000000000000000
    [ 1.428415] x21: ffff000009136008 x20: ffff000009408730
    [ 1.428744] x19: ffff80007b20b400 x18: 000000000000000a
    [ 1.429075] x17: 0000000000000000 x16: 0000000000000000
    [ 1.429418] x15: 0000000000000400 x14: 2e79726f74636572
    [ 1.429748] x13: 696420656d617320 x12: 656874206e692065
    [ 1.430060] x11: 6d616e20656d6173 x10: 2065687420687469
    [ 1.430335] x9 : ffff00000804bd50 x8 : 206e6f7361657220
    [ 1.430610] x7 : 2c3376756d705f38 x6 : ffff00000954d7ce
    [ 1.430880] x5 : 0000000000000000 x4 : 0000000000000000
    [ 1.431226] x3 : 0000000000000000 x2 : ffffffffffffffff
    [ 1.431554] x1 : 4d151327adc50b00 x0 : 0000000000000000
    [ 1.431868] Call trace:
    [ 1.432102] perf_event_sysfs_init+0x98/0xdc
    [ 1.432382] do_one_initcall+0x6c/0x1a8
    [ 1.432637] kernel_init_freeable+0x1bc/0x280
    [ 1.432905] kernel_init+0x18/0x160
    [ 1.433115] ret_from_fork+0x10/0x18
    [ 1.433297] ---[ end trace 27fd415390eb9883 ]---

    Rework to set suppress_bind_attrs flag to avoid removing the device when
    CONFIG_DEBUG_TEST_DRIVER_REMOVE=y, since there's no real reason to
    remove the armv8_pmuv3 driver.

    Cc: Arnd Bergmann
    Co-developed-by: Arnd Bergmann
    Signed-off-by: Anders Roxell
    Signed-off-by: Will Deacon
    Signed-off-by: Sasha Levin

    Anders Roxell
     
  • [ Upstream commit 3da2c1dfdb802b184eea0653d1e589515b52d74b ]

    ecc_point_mult is supposed to be used with a regularized scalar,
    otherwise, it's possible to deduce the position of the top bit of the
    scalar with timing attack. This is important when the scalar is a
    private key.

    ecc_point_mult is already using a regular algorithm (i.e. having an
    operation flow independent of the input scalar) but regularization step
    is not implemented.

    Arrange scalar to always have fixed top bit by adding a multiple of the
    curve order (n).

    References:
    The constant time regularization step is based on micro-ecc by Kenneth
    MacKay and also referenced in the literature (Bernstein, D. J., & Lange,
    T. (2017). Montgomery curves and the Montgomery ladder. (Cryptology
    ePrint Archive; Vol. 2017/293). s.l.: IACR. Chapter 4.6.2.)

    Signed-off-by: Vitaly Chikunov
    Cc: kernel-hardening@lists.openwall.com
    Signed-off-by: Herbert Xu
    Signed-off-by: Sasha Levin

    Vitaly Chikunov
     
  • [ Upstream commit e4849aff1e169b86c561738daf8ff020e9de1011 ]

    The Broadcom SiByte BCM1250, BCM1125, and BCM1125H SOCs have an onchip
    DRAM controller that supports memory amounts of up to 16GiB, and due to
    how the address decoder has been wired in the SOC any memory beyond 1GiB
    is actually mapped starting from 4GiB physical up, that is beyond the
    32-bit addressable limit[1]. Consequently if the maximum amount of
    memory has been installed, then it will span up to 19GiB.

    Many of the evaluation boards we support that are based on one of these
    SOCs have their memory soldered and the amount present fits in the
    32-bit address range. The BCM91250A SWARM board however has actual DIMM
    slots and accepts, depending on the peripherals revision of the SOC, up
    to 4GiB or 8GiB of memory in commercially available JEDEC modules[2].
    I believe this is also the case with the BCM91250C2 LittleSur board.
    This means that up to either 3GiB or 7GiB of memory requires 64-bit
    addressing to access.

    I believe the BCM91480B BigSur board, which has the BCM1480 SOC instead,
    accepts at least as much memory, although I have no documentation or
    actual hardware available to verify that.

    Both systems have PCI slots installed for use by any PCI option boards,
    including ones that only support 32-bit addressing (additionally the
    32-bit PCI host bridge of the BCM1250, BCM1125, and BCM1125H SOCs limits
    addressing to 32-bits), and there is no IOMMU available. Therefore for
    PCI DMA to work in the presence of memory beyond enable swiotlb for the
    affected systems.

    All the other SOC onchip DMA devices use 40-bit addressing and therefore
    can address the whole memory, so only enable swiotlb if PCI support and
    support for DMA beyond 4GiB have been both enabled in the configuration
    of the kernel.

    This shows up as follows:

    Broadcom SiByte BCM1250 B2 @ 800 MHz (SB1 rev 2)
    Board type: SiByte BCM91250A (SWARM)
    Determined physical RAM map:
    memory: 000000000fe7fe00 @ 0000000000000000 (usable)
    memory: 000000001ffffe00 @ 0000000080000000 (usable)
    memory: 000000000ffffe00 @ 00000000c0000000 (usable)
    memory: 0000000087fffe00 @ 0000000100000000 (usable)
    software IO TLB: mapped [mem 0xcbffc000-0xcfffc000] (64MB)

    in the bootstrap log and removes failures like these:

    defxx 0000:02:00.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
    fddi0: Receive buffer allocation failed
    fddi0: Adapter open failed!
    IP-Config: Failed to open fddi0
    defxx 0000:09:08.0: dma_direct_map_page: overflow 0x0000000185bc6080+4608 of device mask ffffffff bus mask 0
    fddi1: Receive buffer allocation failed
    fddi1: Adapter open failed!
    IP-Config: Failed to open fddi1

    when memory beyond 4GiB is handed out to devices that can only do 32-bit
    addressing.

    This updates commit cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need
    DMA32.").

    References:

    [1] "BCM1250/BCM1125/BCM1125H User Manual", Revision 1250_1125-UM100-R,
    Broadcom Corporation, 21 Oct 2002, Section 3: "System Overview",
    "Memory Map", pp. 34-38

    [2] "BCM91250A User Manual", Revision 91250A-UM100-R, Broadcom
    Corporation, 18 May 2004, Section 3: "Physical Description",
    "Supported DRAM", p. 23

    Signed-off-by: Maciej W. Rozycki
    [paul.burton@mips.com: Remove GPL text from dma.c; SPDX tag covers it]
    Signed-off-by: Paul Burton
    Reviewed-by: Christoph Hellwig
    Patchwork: https://patchwork.linux-mips.org/patch/21108/
    References: cce335ae47e2 ("[MIPS] 64-bit Sibyte kernels need DMA32.")
    Cc: Ralf Baechle
    Cc: linux-mips@linux-mips.org
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Sasha Levin

    Maciej W. Rozycki
     
  • [ Upstream commit 68b5e4326e4b8ac9080835005d8254fed0fb3c56 ]

    Add the proper includes and make smca_get_name() static.

    Fix an actual bug too which the warning triggered:

    arch/x86/kernel/cpu/mcheck/therm_throt.c:395:39: error: conflicting \
    types for ‘smp_thermal_interrupt’
    asmlinkage __visible void __irq_entry smp_thermal_interrupt(struct pt_regs *r)
    ^~~~~~~~~~~~~~~~~~~~~
    In file included from arch/x86/kernel/cpu/mcheck/therm_throt.c:29:
    ./arch/x86/include/asm/traps.h:107:17: note: previous declaration of \
    ‘smp_thermal_interrupt’ was here
    asmlinkage void smp_thermal_interrupt(void);

    Signed-off-by: Borislav Petkov
    Cc: Yi Wang
    Cc: Michael Matz
    Cc: x86@kernel.org
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1811081633160.1549@nanos.tec.linutronix.de
    Signed-off-by: Sasha Levin

    Borislav Petkov
     
  • [ Upstream commit fba43f454cdf9caa3185219d116bd2a6e6354552 ]

    This commit adds support for APOGEE duet FireWire, launched 2007, already
    discontinued. This model uses Oxford Semiconductor FW971 as its
    communication engine. Below is information on Configuration ROM of this
    unit. The unit supports some AV/C commands defined by Audio subunit
    specification and vendor dependent commands.

    $ ./hinawa-config-rom-printer /dev/fw1
    { 'bus-info': { 'adj': False,
    'bmc': False,
    'chip_ID': 42949742248,
    'cmc': False,
    'cyc_clk_acc': 255,
    'generation': 0,
    'imc': False,
    'isc': True,
    'link_spd': 3,
    'max_ROM': 0,
    'max_rec': 64,
    'name': '1394',
    'node_vendor_ID': 987,
    'pmc': False},
    'root-directory': [ ['VENDOR', 987],
    ['DESCRIPTOR', 'Apogee Electronics'],
    ['MODEL', 122333],
    ['DESCRIPTOR', 'Duet'],
    [ 'NODE_CAPABILITIES',
    { 'addressing': {'64': True, 'fix': True, 'prv': False},
    'misc': {'int': False, 'ms': False, 'spt': True},
    'state': { 'atn': False,
    'ded': False,
    'drq': True,
    'elo': False,
    'init': False,
    'lst': True,
    'off': False},
    'testing': {'bas': False, 'ext': False}}],
    [ 'UNIT',
    [ ['SPECIFIER_ID', 41005],
    ['VERSION', 65537],
    ['MODEL', 122333],
    ['DESCRIPTOR', 'Duet']]]]}

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai
    Signed-off-by: Sasha Levin

    Takashi Sakamoto
     
  • [ Upstream commit 46f53a65d2de3e1591636c22b626b09d8684fd71 ]

    Currently BPF verifier allows narrow loads for a context field only with
    offset zero. E.g. if there is a __u32 field then only the following
    loads are permitted:
    * off=0, size=1 (narrow);
    * off=0, size=2 (narrow);
    * off=0, size=4 (full).

    On the other hand LLVM can generate a load with offset different than
    zero that make sense from program logic point of view, but verifier
    doesn't accept it.

    E.g. tools/testing/selftests/bpf/sendmsg4_prog.c has code:

    #define DST_IP4 0xC0A801FEU /* 192.168.1.254 */
    ...
    if ((ctx->user_ip4 >> 24) == (bpf_htonl(DST_IP4) >> 24) &&

    where ctx is struct bpf_sock_addr.

    Some versions of LLVM can produce the following byte code for it:

    8: 71 12 07 00 00 00 00 00 r2 = *(u8 *)(r1 + 7)
    9: 67 02 00 00 18 00 00 00 r2 <

    where `*(u8 *)(r1 + 7)` means narrow load for ctx->user_ip4 with size=1
    and offset=3 (7 - sizeof(ctx->user_family) = 3). This load is currently
    rejected by verifier.

    Verifier code that rejects such loads is in bpf_ctx_narrow_access_ok()
    what means any is_valid_access implementation, that uses the function,
    works this way, e.g. bpf_skb_is_valid_access() for __sk_buff or
    sock_addr_is_valid_access() for bpf_sock_addr.

    The patch makes such loads supported. Offset can be in [0; size_default)
    but has to be multiple of load size. E.g. for __u32 field the following
    loads are supported now:
    * off=0, size=1 (narrow);
    * off=1, size=1 (narrow);
    * off=2, size=1 (narrow);
    * off=3, size=1 (narrow);
    * off=0, size=2 (narrow);
    * off=2, size=2 (narrow);
    * off=0, size=4 (full).

    Reported-by: Yonghong Song
    Signed-off-by: Andrey Ignatov
    Signed-off-by: Alexei Starovoitov
    Signed-off-by: Sasha Levin

    Andrey Ignatov
     
  • [ Upstream commit 646097940ad35aa2c1f2012af932d55976a9f255 ]

    When the test 'CONFIG_DEBUG_TEST_DRIVER_REMOVE=y' is enabled,
    arch_initcall(pl011_init) came before subsys_initcall(default_bdi_init).
    devtmpfs gets killed because we try to remove a file and decrement the
    wb reference count before the noop_backing_device_info gets initialized.

    [ 0.332075] Serial: AMBA PL011 UART driver
    [ 0.485276] 9000000.pl011: ttyAMA0 at MMIO 0x9000000 (irq = 39, base_baud = 0) is a PL011 rev1
    [ 0.502382] console [ttyAMA0] enabled
    [ 0.515710] Unable to handle kernel paging request at virtual address 0000800074c12000
    [ 0.516053] Mem abort info:
    [ 0.516222] ESR = 0x96000004
    [ 0.516417] Exception class = DABT (current EL), IL = 32 bits
    [ 0.516641] SET = 0, FnV = 0
    [ 0.516826] EA = 0, S1PTW = 0
    [ 0.516984] Data abort info:
    [ 0.517149] ISV = 0, ISS = 0x00000004
    [ 0.517339] CM = 0, WnR = 0
    [ 0.517553] [0000800074c12000] user address but active_mm is swapper
    [ 0.517928] Internal error: Oops: 96000004 [#1] PREEMPT SMP
    [ 0.518305] Modules linked in:
    [ 0.518839] CPU: 0 PID: 13 Comm: kdevtmpfs Not tainted 4.19.0-rc5-next-20180928-00002-g2ba39ab0cd01-dirty #82
    [ 0.519307] Hardware name: linux,dummy-virt (DT)
    [ 0.519681] pstate: 80000005 (Nzcv daif -PAN -UAO)
    [ 0.519959] pc : __destroy_inode+0x94/0x2a8
    [ 0.520212] lr : __destroy_inode+0x78/0x2a8
    [ 0.520401] sp : ffff0000098c3b20
    [ 0.520590] x29: ffff0000098c3b20 x28: 00000000087a3714
    [ 0.520904] x27: 0000000000002000 x26: 0000000000002000
    [ 0.521179] x25: ffff000009583000 x24: 0000000000000000
    [ 0.521467] x23: ffff80007bb52000 x22: ffff80007bbaa7c0
    [ 0.521737] x21: ffff0000093f9338 x20: 0000000000000000
    [ 0.522033] x19: ffff80007bbb05d8 x18: 0000000000000400
    [ 0.522376] x17: 0000000000000000 x16: 0000000000000000
    [ 0.522727] x15: 0000000000000400 x14: 0000000000000400
    [ 0.523068] x13: 0000000000000001 x12: 0000000000000001
    [ 0.523421] x11: 0000000000000000 x10: 0000000000000970
    [ 0.523749] x9 : ffff0000098c3a60 x8 : ffff80007bbab190
    [ 0.524017] x7 : ffff80007bbaa880 x6 : 0000000000000c88
    [ 0.524305] x5 : ffff0000093d96c8 x4 : 61c8864680b583eb
    [ 0.524567] x3 : ffff0000093d6180 x2 : ffffffffffffffff
    [ 0.524872] x1 : 0000800074c12000 x0 : 0000800074c12000
    [ 0.525207] Process kdevtmpfs (pid: 13, stack limit = 0x(____ptrval____))
    [ 0.525529] Call trace:
    [ 0.525806] __destroy_inode+0x94/0x2a8
    [ 0.526108] destroy_inode+0x34/0x88
    [ 0.526370] evict+0x144/0x1c8
    [ 0.526636] iput+0x184/0x230
    [ 0.526871] dentry_unlink_inode+0x118/0x130
    [ 0.527152] d_delete+0xd8/0xe0
    [ 0.527420] vfs_unlink+0x240/0x270
    [ 0.527665] handle_remove+0x1d8/0x330
    [ 0.527875] devtmpfsd+0x138/0x1c8
    [ 0.528085] kthread+0x14c/0x158
    [ 0.528291] ret_from_fork+0x10/0x18
    [ 0.528720] Code: 92800002 aa1403e0 d538d081 8b010000 (c85f7c04)
    [ 0.529367] ---[ end trace 5a3dee47727f877c ]---

    Rework to set suppress_bind_attrs flag to avoid removing the device when
    CONFIG_DEBUG_TEST_DRIVER_REMOVE=y. This applies for pic32_uart and
    xilinx_uartps as well.

    Co-developed-by: Arnd Bergmann
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Anders Roxell
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Sasha Levin

    Anders Roxell
     
  • [ Upstream commit 347a28b586802d09604a149c1a1f6de5dccbe6fa ]

    This happened while running in qemu-system-aarch64, the AMBA PL011 UART
    driver when enabling CONFIG_DEBUG_TEST_DRIVER_REMOVE.
    arch_initcall(pl011_init) came before subsys_initcall(default_bdi_init),
    devtmpfs' handle_remove() crashes because the reference count is a NULL
    pointer only because wb->bdi hasn't been initialized yet.

    Rework so that wb_put have an extra check if wb->bdi before decrement
    wb->refcnt and also add a WARN_ON_ONCE to get a warning if it happens again
    in other drivers.

    Fixes: 52ebea749aae ("writeback: make backing_dev_info host cgroup-specific bdi_writebacks")
    Co-developed-by: Arnd Bergmann
    Signed-off-by: Arnd Bergmann
    Signed-off-by: Anders Roxell
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Sasha Levin

    Anders Roxell
     
  • [ Upstream commit 7c528e457d53c75107d5aa56892316d265c778de ]

    The refcount of a newly added overlay node decrements to one
    (instead of zero) when the overlay changeset is destroyed. This
    change will cause the final decrement be to zero.

    After applying this patch, new validation warnings will be
    reported from the devicetree unittest during boot due to
    a pre-existing devicetree bug. The warnings will be similar to:

    OF: ERROR: memory leak before free overlay changeset, /testcase-data/overlay-node/test-bus/test-unittest4

    This pre-existing devicetree bug will also trigger a WARN_ONCE() from
    refcount_sub_and_test_checked() when an overlay changeset is
    destroyed without having first been applied. This scenario occurs
    when an error in the overlay is detected during the overlay changeset
    creation:

    WARNING: CPU: 0 PID: 1 at lib/refcount.c:187 refcount_sub_and_test_checked+0xa8/0xbc
    refcount_t: underflow; use-after-free.

    (unwind_backtrace) from (show_stack+0x10/0x14)
    (show_stack) from (dump_stack+0x6c/0x8c)
    (dump_stack) from (__warn+0xdc/0x104)
    (__warn) from (warn_slowpath_fmt+0x44/0x6c)
    (warn_slowpath_fmt) from (refcount_sub_and_test_checked+0xa8/0xbc)
    (refcount_sub_and_test_checked) from (kobject_put+0x24/0x208)
    (kobject_put) from (of_changeset_destroy+0x2c/0xb4)
    (of_changeset_destroy) from (free_overlay_changeset+0x1c/0x9c)
    (free_overlay_changeset) from (of_overlay_remove+0x284/0x2cc)
    (of_overlay_remove) from (of_unittest_apply_revert_overlay_check.constprop.4+0xf8/0x1e8)
    (of_unittest_apply_revert_overlay_check.constprop.4) from (of_unittest_overlay+0x960/0xed8)
    (of_unittest_overlay) from (of_unittest+0x1cc4/0x2138)
    (of_unittest) from (do_one_initcall+0x4c/0x28c)
    (do_one_initcall) from (kernel_init_freeable+0x29c/0x378)
    (kernel_init_freeable) from (kernel_init+0x8/0x110)
    (kernel_init) from (ret_from_fork+0x14/0x2c)

    Tested-by: Alan Tull
    Signed-off-by: Frank Rowand
    Signed-off-by: Sasha Levin

    Frank Rowand