From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>, Jason Gunthorpe <jgg@mellanox.com>
Cc: Leon Romanovsky <leonro@mellanox.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Feras Daoud <ferasda@mellanox.com>,
Haggai Eran <haggaie@mellanox.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Saeed Mahameed <saeedm@mellanox.com>,
linux-netdev <netdev@vger.kernel.org>
Subject: [PATCH rdma-next 0/6] BAR mappings fixes in RDMA
Date: Tue, 16 Apr 2019 14:07:24 +0300 [thread overview]
Message-ID: <20190416110730.32230-1-leon@kernel.org> (raw)
From: Leon Romanovsky <leonro@mellanox.com>
>From Jason,
Upon review it turns out there are some long standing problems in BAR
mapping area:
* BAR pages are being allowed to be executable.
* BAR pages intended for read-only can be switched to writable via mprotect.
* Missing use of rdma_user_mmap_io for the mlx5 clock BAR page.
* Disassociate causes SIGBUS when touching the pages.
* CPU pages are being mapped through to the process via remap_pfn_range
instead of the more appropriate vm_insert_page, causing weird behaviors
during disassociation.
This series adds the missing VM_* flag manipulation, adds faulting a zero
page for disassociation and revises the CPU page mappings to use vm_insert_page.
Thanks
Jason Gunthorpe (6):
RDMA/mlx5: Do not allow the user to write to the clock page
RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages
RDMA/ucontext: Do not allow BAR mappings to be executable
RDMA/ucontext: Fix regression with disassociate
RDMA/mlx5: Use get_zeroed_page() for clock_info
RDMA: Remove rdma_user_mmap_page
drivers/infiniband/core/uverbs.h | 1 +
drivers/infiniband/core/uverbs_main.c | 115 ++++++++++--------
drivers/infiniband/hw/mlx5/main.c | 21 ++--
.../ethernet/mellanox/mlx5/core/lib/clock.c | 30 ++---
include/linux/mlx5/driver.h | 1 -
include/rdma/ib_verbs.h | 9 --
6 files changed, 85 insertions(+), 92 deletions(-)
WARNING: multiple messages have this Message-ID (diff)
From: Leon Romanovsky <leon@kernel.org>
To: Doug Ledford <dledford@redhat.com>, Jason Gunthorpe <jgg@mellanox.com>
Cc: Leon Romanovsky <leonro@mellanox.com>,
RDMA mailing list <linux-rdma@vger.kernel.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Feras Daoud <ferasda@mellanox.com>,
Haggai Eran <haggaie@mellanox.com>,
Jason Gunthorpe <jgg@ziepe.ca>,
Saeed Mahameed <saeedm@mellanox.com>,
linux-netdev <netdev@vger.kernel.org>
Subject: [PATCH rdma-next 0/6] BAR mappings fixes in RDMA
Date: Tue, 16 Apr 2019 14:07:24 +0300 [thread overview]
Message-ID: <20190416110730.32230-1-leon@kernel.org> (raw)
From: Leon Romanovsky <leonro@mellanox.com>
From Jason,
Upon review it turns out there are some long standing problems in BAR
mapping area:
* BAR pages are being allowed to be executable.
* BAR pages intended for read-only can be switched to writable via mprotect.
* Missing use of rdma_user_mmap_io for the mlx5 clock BAR page.
* Disassociate causes SIGBUS when touching the pages.
* CPU pages are being mapped through to the process via remap_pfn_range
instead of the more appropriate vm_insert_page, causing weird behaviors
during disassociation.
This series adds the missing VM_* flag manipulation, adds faulting a zero
page for disassociation and revises the CPU page mappings to use vm_insert_page.
Thanks
Jason Gunthorpe (6):
RDMA/mlx5: Do not allow the user to write to the clock page
RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages
RDMA/ucontext: Do not allow BAR mappings to be executable
RDMA/ucontext: Fix regression with disassociate
RDMA/mlx5: Use get_zeroed_page() for clock_info
RDMA: Remove rdma_user_mmap_page
drivers/infiniband/core/uverbs.h | 1 +
drivers/infiniband/core/uverbs_main.c | 115 ++++++++++--------
drivers/infiniband/hw/mlx5/main.c | 21 ++--
.../ethernet/mellanox/mlx5/core/lib/clock.c | 30 ++---
include/linux/mlx5/driver.h | 1 -
include/rdma/ib_verbs.h | 9 --
6 files changed, 85 insertions(+), 92 deletions(-)
--
2.20.1
next reply other threads:[~2019-04-16 11:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-16 11:07 Leon Romanovsky [this message]
2019-04-16 11:07 ` [PATCH rdma-next 0/6] BAR mappings fixes in RDMA Leon Romanovsky
2019-04-16 11:07 ` [PATCH rdma-next 1/6] RDMA/mlx5: Do not allow the user to write to the clock page Leon Romanovsky
2019-04-16 11:07 ` [PATCH rdma-next 2/6] RDMA/mlx5: Use rdma_user_map_io for mapping BAR pages Leon Romanovsky
2019-04-16 11:07 ` [PATCH rdma-next 3/6] RDMA/ucontext: Do not allow BAR mappings to be executable Leon Romanovsky
2019-04-17 19:05 ` Ruhl, Michael J
2019-04-18 5:58 ` Jason Gunthorpe
2019-04-18 6:30 ` Kees Cook
2019-04-18 7:01 ` Jason Gunthorpe
2019-04-18 7:23 ` Kees Cook
2019-04-18 7:23 ` Kees Cook
2019-04-22 12:51 ` Jason Gunthorpe
2019-04-16 11:07 ` [PATCH rdma-next 4/6] RDMA/ucontext: Fix regression with disassociate Leon Romanovsky
2019-04-16 11:07 ` [PATCH mlx5-next 5/6] RDMA/mlx5: Use get_zeroed_page() for clock_info Leon Romanovsky
2019-04-16 11:07 ` [PATCH rdma-next 6/6] RDMA: Remove rdma_user_mmap_page Leon Romanovsky
2019-04-24 19:24 ` [PATCH rdma-next 0/6] BAR mappings fixes in RDMA Jason Gunthorpe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190416110730.32230-1-leon@kernel.org \
--to=leon@kernel.org \
--cc=aarcange@redhat.com \
--cc=dledford@redhat.com \
--cc=ferasda@mellanox.com \
--cc=haggaie@mellanox.com \
--cc=jgg@mellanox.com \
--cc=jgg@ziepe.ca \
--cc=leonro@mellanox.com \
--cc=linux-rdma@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=saeedm@mellanox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.