Eric Lee / smarc-fsl-linux-kernel

03 Jun, 2020

1 commit

18 Jan, 2020

1 commit

18 Jul, 2019

3 commits

  • 5f33141d2   net/rds: Wait for the FRMR_IS_FREE (or FRMR_IS_STALE) transition after posting IB_WR_LOCAL_INV ... Browse Code »

    In order to:
    1) avoid a silly bouncing between "clean_list" and "drop_list"
    triggered by function "rds_ib_reg_frmr" as it is releases frmr
    regions whose state is not "FRMR_IS_FREE" right away.

    2) prevent an invalid access error in a race from a pending
    "IB_WR_LOCAL_INV" operation with a teardown ("dma_unmap_sg", "put_page")
    and de-registration ("ib_dereg_mr") of the corresponding
    memory region.

    Signed-off-by: Gerd Rausch
    Acked-by: Santosh Shilimkar
    Signed-off-by: David S. Miller

    Gerd Rausch
     
  • c9467447f   net/rds: Get rid of "wait_clean_list_grace" and add locking ... Browse Code »

    Waiting for activity on the "clean_list" to quiesce is no substitute
    for proper locking.

    We can have multiple threads competing for "llist_del_first"
    via "rds_ib_reuse_mr", and a single thread competing
    for "llist_del_all" and "llist_del_first" via "rds_ib_flush_mr_pool".

    Since "llist_del_first" depends on "list->first->next" not to change
    in the midst of the operation, simply waiting for all current calls
    to "rds_ib_reuse_mr" to quiesce across all CPUs is woefully inadequate:

    By the time "wait_clean_list_grace" is done iterating over all CPUs to see
    that there is no concurrent caller to "rds_ib_reuse_mr", a new caller may
    have just shown up on the first CPU.

    Furthermore, explicitly calls out the need for locking:
    * Cases where locking is needed:
    * If we have multiple consumers with llist_del_first used in one consumer,
    * and llist_del_first or llist_del_all used in other consumers,
    * then a lock is needed.

    Also, while at it, drop the unused "pool" parameter
    from "list_to_llist_nodes".

    Signed-off-by: Gerd Rausch
    Acked-by: Santosh Shilimkar
    Signed-off-by: David S. Miller

    Gerd Rausch
     
  • 2c7da8e6b   net/rds: Give fr_state a chance to transition to FRMR_IS_FREE ... Browse Code »

    In the context of FRMR (ib_frmr.c):

    Memory regions make it onto the "clean_list" via "rds_ib_flush_mr_pool",
    after the memory region has been posted for invalidation via
    "rds_ib_post_inv".

    At that point in time, "fr_state" may still be in state "FRMR_IS_INUSE",
    since the only place where "fr_state" transitions to "FRMR_IS_FREE"
    is in "rds_ib_mr_cqe_handler", which is triggered by a tasklet.

    So in case we notice that "fr_state != FRMR_IS_FREE" (see below),
    we wait for "fr_inv_done" to trigger with a maximum of 10msec.
    Then we check again, and only put the memory region onto the drop_list
    (via "rds_ib_free_frmr") in case the situation remains unchanged.

    This avoids the problem of memory-regions bouncing between "clean_list"
    and "drop_list" before they even have a chance to be properly invalidated.

    Signed-off-by: Gerd Rausch
    Acked-by: Santosh Shilimkar
    Signed-off-by: David S. Miller

    Gerd Rausch
     

03 Aug, 2018

1 commit

27 Jul, 2018

1 commit

  • 9e630bcb7   RDS: RDMA: Fix the NULL-ptr deref in rds_ib_get_mr ... Browse Code »

    Registration of a memory region(MR) through FRMR/fastreg(unlike FMR)
    needs a connection/qp. With a proxy qp, this dependency on connection
    will be removed, but that needs more infrastructure patches, which is a
    work in progress.

    As an intermediate fix, the get_mr returns EOPNOTSUPP when connection
    details are not populated. The MR registration through sendmsg() will
    continue to work even with fast registration, since connection in this
    case is formed upfront.

    This patch fixes the following crash:
    kasan: GPF could be caused by NULL-ptr deref or user memory access
    general protection fault: 0000 [#1] SMP KASAN
    Modules linked in:
    CPU: 1 PID: 4244 Comm: syzkaller468044 Not tainted 4.16.0-rc6+ #361
    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
    Google 01/01/2011
    RIP: 0010:rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544
    RSP: 0018:ffff8801b059f890 EFLAGS: 00010202
    RAX: dffffc0000000000 RBX: ffff8801b07e1300 RCX: ffffffff8562d96e
    RDX: 000000000000000d RSI: 0000000000000001 RDI: 0000000000000068
    RBP: ffff8801b059f8b8 R08: ffffed0036274244 R09: ffff8801b13a1200
    R10: 0000000000000004 R11: ffffed0036274243 R12: ffff8801b13a1200
    R13: 0000000000000001 R14: ffff8801ca09fa9c R15: 0000000000000000
    FS: 00007f4d050af700(0000) GS:ffff8801db300000(0000)
    knlGS:0000000000000000
    CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 00007f4d050aee78 CR3: 00000001b0d9b006 CR4: 00000000001606e0
    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
    Call Trace:
    __rds_rdma_map+0x710/0x1050 net/rds/rdma.c:271
    rds_get_mr_for_dest+0x1d4/0x2c0 net/rds/rdma.c:357
    rds_setsockopt+0x6cc/0x980 net/rds/af_rds.c:347
    SYSC_setsockopt net/socket.c:1849 [inline]
    SyS_setsockopt+0x189/0x360 net/socket.c:1828
    do_syscall_64+0x281/0x940 arch/x86/entry/common.c:287
    entry_SYSCALL_64_after_hwframe+0x42/0xb7
    RIP: 0033:0x4456d9
    RSP: 002b:00007f4d050aedb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
    RAX: ffffffffffffffda RBX: 00000000006dac3c RCX: 00000000004456d9
    RDX: 0000000000000007 RSI: 0000000000000114 RDI: 0000000000000004
    RBP: 00000000006dac38 R08: 00000000000000a0 R09: 0000000000000000
    R10: 0000000020000380 R11: 0000000000000246 R12: 0000000000000000
    R13: 00007fffbfb36d6f R14: 00007f4d050af9c0 R15: 0000000000000005
    Code: fa 48 c1 ea 03 80 3c 02 00 0f 85 cc 01 00 00 4c 8b bb 80 04 00 00
    48
    b8 00 00 00 00 00 fc ff df 49 8d 7f 68 48 89 fa 48 c1 ea 03 3c 02
    00 0f
    85 9c 01 00 00 4d 8b 7f 68 48 b8 00 00 00 00 00
    RIP: rds_ib_get_mr+0x5c/0x230 net/rds/ib_rdma.c:544 RSP:
    ffff8801b059f890
    ---[ end trace 7e1cea13b85473b0 ]---

    Reported-by: syzbot+b51c77ef956678a65834@syzkaller.appspotmail.com
    Signed-off-by: Santosh Shilimkar
    Signed-off-by: Avinash Repaka

    Signed-off-by: David S. Miller

    Avinash Repaka
     

24 Jul, 2018

1 commit

  • b7ff8b103   rds: Extend RDS API for IPv6 support ... Browse Code »

    There are many data structures (RDS socket options) used by RDS apps
    which use a 32 bit integer to store IP address. To support IPv6,
    struct in6_addr needs to be used. To ensure backward compatibility, a
    new data structure is introduced for each of those data structures
    which use a 32 bit integer to represent an IP address. And new socket
    options are introduced to use those new structures. This means that
    existing apps should work without a problem with the new RDS module.
    For apps which want to use IPv6, those new data structures and socket
    options can be used. IPv4 mapped address is used to represent IPv4
    address in the new data structures.

    v4: Revert changes to SO_RDS_TRANSPORT

    Signed-off-by: Ka-Cheong Poon
    Acked-by: Santosh Shilimkar
    Signed-off-by: David S. Miller

    Ka-Cheong Poon
     

14 Mar, 2017

1 commit

02 Mar, 2017

1 commit

  • 4f7bfb398   rds: ib: add the static type to the variables ... Browse Code »

    The variables rds_ib_mr_1m_pool_size and rds_ib_mr_8k_pool_size
    are used only in the ib.c file. As such, the static type is
    added to limit them in this file.

    Cc: Joe Jin
    Cc: Junxiao Bi
    Signed-off-by: Zhu Yanjun
    Acked-by: Santosh Shilimkar
    Signed-off-by: David S. Miller

    Zhu Yanjun
     

25 Jan, 2017

1 commit

03 Mar, 2016

6 commits