在 2021/4/8 下午5:10, Eli Cohen 写道:
struct mlx5_core_dev has a bar_addr field that contains the correct bar
address for the function regardless of whether it is pci function or sub
function. Use it.
Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver")
Signed-off-by:
struct mlx5_core_dev has a bar_addr field that contains the correct bar
address for the function regardless of whether it is pci function or sub
function. Use it.
Fixes: 1958fc2f0712 ("net/mlx5: SF, Add auxiliary device driver")
Signed-off-by: Eli Cohen
Reviewed-by: Parav Pandit
--
On Tue, 27 Oct 2020 09:42:01 +0800 Yunsheng Lin wrote:
> On 2020/10/27 9:25, Jakub Kicinski wrote:
> > On Tue, 27 Oct 2020 09:24:10 +0800 Yunsheng Lin wrote:
> >>> Fixes: 862d969a3a4d ("net: hns3: do VF's pci re-initialization while PF
> >>> doing FLR")
> >>
> >> The correct Fixes tag should
On 2020/10/27 9:25, Jakub Kicinski wrote:
> On Tue, 27 Oct 2020 09:24:10 +0800 Yunsheng Lin wrote:
>>> Fixes: 862d969a3a4d ("net: hns3: do VF's pci re-initialization while PF
>>> doing FLR")
>>
>> The correct Fixes tag should be:
>>
>> Fixes: e3338205f0c7 ("net: hns3: uninitialize pci in the hcl
On Tue, 27 Oct 2020 09:24:10 +0800 Yunsheng Lin wrote:
> > Fixes: 862d969a3a4d ("net: hns3: do VF's pci re-initialization while PF
> > doing FLR")
>
> The correct Fixes tag should be:
>
> Fixes: e3338205f0c7 ("net: hns3: uninitialize pci in the hclgevf_uninit")
Why is that?
Isn't the issue t
On 2020/10/27 7:13, Jakub Kicinski wrote:
> On Fri, 23 Oct 2020 15:01:14 +0800 Zenghui Yu wrote:
>> On 2020/10/23 14:22, Yunsheng Lin wrote:
>>> On 2020/10/23 13:15, Zenghui Yu wrote:
When unbinding the hns3 driver with the HNS3 VF, I got the following
kernel panic:
[ 265.709
On Fri, 23 Oct 2020 15:01:14 +0800 Zenghui Yu wrote:
> On 2020/10/23 14:22, Yunsheng Lin wrote:
> > On 2020/10/23 13:15, Zenghui Yu wrote:
> >> When unbinding the hns3 driver with the HNS3 VF, I got the following
> >> kernel panic:
> >>
> >> [ 265.709989] Unable to handle kernel paging request a
] ksys_write+0x74/0xf8
[ 266.055677] __arm64_sys_write+0x24/0x30
[ 266.059584] el0_svc_common.constprop.3+0x84/0x270
[ 266.064354] do_el0_svc+0x34/0xa0
[ 266.067658] el0_svc+0x38/0x40
[ 266.070700] el0_sync_handler+0x8c/0xb0
[ 266.074519] el0_sync+0x140/0x180
It looks like the BAR
> [ 266.059584] el0_svc_common.constprop.3+0x84/0x270
> [ 266.064354] do_el0_svc+0x34/0xa0
> [ 266.067658] el0_svc+0x38/0x40
> [ 266.070700] el0_sync_handler+0x8c/0xb0
> [ 266.074519] el0_sync+0x140/0x180
>
> It looks like the BAR memory region had already be
] el0_svc_common.constprop.3+0x84/0x270
[ 266.064354] do_el0_svc+0x34/0xa0
[ 266.067658] el0_svc+0x38/0x40
[ 266.070700] el0_sync_handler+0x8c/0xb0
[ 266.074519] el0_sync+0x140/0x180
It looks like the BAR memory region had already been unmapped before we
start clearing CMDQ registers in it
it_waitqueue_head(&efx->flush_wq);
+ efx->mem_bar = UINT_MAX;
+
rc = efx_init_channels(efx);
if (rc)
goto fail;
@@ -996,7 +998,9 @@ int efx_init_io(struct efx_nic *efx, int bar, dma_addr_t
dma_mask,
struct pci_dev *pci_dev = efx->pci
it_waitqueue_head(&efx->flush_wq);
+ efx->mem_bar = UINT_MAX;
+
rc = efx_init_channels(efx);
if (rc)
goto fail;
@@ -996,7 +998,9 @@ int efx_init_io(struct efx_nic *efx, int bar, dma_addr_t
dma_mask,
struct pci_dev *pci_dev = efx->pci
From: Adam Ludkiewicz
This patch fixes the problem with a kernel panic occurring when trying
to bind the i40e driver to a non-i40e port. The problem is fixed by
checking if the BAR size in the device is large enough by reading the
highest register.
Signed-off-by: Adam Ludkiewicz
Tested-by
From: Adam Ludkiewicz
This patch fixes the problem with a kernel panic occurring when trying
to bind the i40e driver to a non-i40e port. The problem is fixed by
checking if the BAR size in the device is large enough by reading the
highest register.
Signed-off-by: Adam Ludkiewicz
Tested-by
From: Shalom Toledo
Add free running clock PCI BAR and offset to query firmware command.
Signed-off-by: Shalom Toledo
Reviewed-by: Petr Machata
Acked-by: Jiri Pirko
Signed-off-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/cmd.h | 12
1 file changed, 12 insertions
From: Shalom Toledo
Query free running clock PCI BAR and offsets during the pci_init.
Signed-off-by: Shalom Toledo
Acked-by: Jiri Pirko
Reviewed-by: Petr Machata
Signed-off-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/pci.c| 32
drivers/net/ethernet
From: Shalom Toledo
Query free running clock PCI BAR and offsets during the pci_init.
Signed-off-by: Shalom Toledo
Acked-by: Jiri Pirko
Reviewed-by: Petr Machata
Signed-off-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/pci.c| 32
drivers/net/ethernet
From: Shalom Toledo
Add free running clock PCI BAR and offset to query firmware command.
Signed-off-by: Shalom Toledo
Reviewed-by: Petr Machata
Acked-by: Jiri Pirko
Signed-off-by: Ido Schimmel
---
drivers/net/ethernet/mellanox/mlxsw/cmd.h | 12
1 file changed, 12 insertions
On Tue, Apr 16, 2019 at 02:07:24PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> >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 in
On Thu, Apr 18, 2019 at 02:23:26AM -0500, Kees Cook wrote:
> On Thu, Apr 18, 2019 at 2:01 AM Jason Gunthorpe wrote:
> >
> > On Thu, Apr 18, 2019 at 01:30:07AM -0500, Kees Cook wrote:
> >
> > > Anything running with READ_IMPLIES_EXEC (i.e. a gnu stack marked WITH
> > > execute) should be considered
On Thu, Apr 18, 2019 at 2:01 AM Jason Gunthorpe wrote:
>
> On Thu, Apr 18, 2019 at 01:30:07AM -0500, Kees Cook wrote:
>
> > Anything running with READ_IMPLIES_EXEC (i.e. a gnu stack marked WITH
> > execute) should be considered broken. Now, the trouble is that this
> > personality flag is carried
On Thu, Apr 18, 2019 at 01:30:07AM -0500, Kees Cook wrote:
> Anything running with READ_IMPLIES_EXEC (i.e. a gnu stack marked WITH
> execute) should be considered broken. Now, the trouble is that this
> personality flag is carried across execve(), so if you have a launcher
> that doesn't fix up th
> > commit 7709b0dc265f28695487712c45f02bbd1f98415d
> > IB/hfi1: Remove overly conservative VM_EXEC flag check
> >
> > to resolve this issue.
> >
> > I am not sure if this is an equivalent issue, but the code path
> > appears very similar.
>
> It does
an equivalent issue, but the code path
> appears very similar.
It does seem problematic here too
Kees: You have worked in this W^X area in other parts of the kernel,
what should drivers do here?
The situation is we have a driver providing mmap against BAR memory
that is absolutely not intended f
rg>; Andrea Arcangeli ; Feras
>Daoud ; Haggai Eran ;
>Jason Gunthorpe ; Saeed Mahameed
>; linux-netdev
>Subject: [PATCH rdma-next 3/6] RDMA/ucontext: Do not allow BAR mappings
>to be executable
>
>From: Jason Gunthorpe
>
>These are not code pages and should neve
From: Jason Gunthorpe
Since mlx5 supports device disassociate it must use this API for all
BAR page mmaps, otherwise the pages can remain mapped after the device
is unplugged causing a system crash.
Cc: sta...@vger.kernel.org
Fixes: 5f9794dc94f5 ("RDMA/ucontext: Add a core API for mm
From: Jason Gunthorpe
These are not code pages and should never be executed.
Cc: sta...@vger.kernel.org
Fixes: 5f9794dc94f5 ("RDMA/ucontext: Add a core API for mmaping driver IO
memory")
Signed-off-by: Jason Gunthorpe
Signed-off-by: Leon Romanovsky
---
drivers/infiniband/core/uverbs_main.c |
From: Leon Romanovsky
>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 m
Soon we will try to write to the vNIC mailbox without RTNL held.
Add a new mutex to protect access to specific parts of the PCI
control BAR.
Move the mailbox size checking to the mailbox lock() helper, where
it can be more effective (happen prior to potential overwrite of
other data).
Signed-off
From: Huy Nguyen
Add bar_addr field to store bar-0 address to avoid calling
pci_resource_start with hard-coded bar-0 as parameter.
Also note that different mlx5 device types will have bar_addr
on different bars.
This patch does not change any functionality.
Signed-off-by: Huy Nguyen
Signed
NFP is entirely programmable, including the PCI data interface.
Using a fixed control BAR layout certainly makes implementations
easier, but require careful considerations when space is allocated.
Once BAR area is allocated to one feature nothing else can use it.
Allocating space statically also
From: Netanel Belgazal
This failure is rare and only found on testing where deliberately fail
devm_ioremap()
[ 451.170464] ena :04:00.0: failed to remap regs bar
451.170549] Workqueue: pciehp-1 pciehp_power_thread
[ 451.170551] task: 88085a5f2d00 task.stack: c9000756c000
VFs are currently not mapping their doorbell bar, instead relying
on the small doorbell window they have in their limited regview bar.
In order to increase the number of possible Tx connections [queues]
employeed by VF past 16, we need to start using the doorbell bar if
one such is exposed - VF
NFP_NET_CFG_RX_OFFSET is 32bit wide, make sure what we read from
there is reasonable for packet headroom. This allows us to store
the rx_offset in a 8bit variable.
Signed-off-by: Jakub Kicinski
---
drivers/net/ethernet/netronome/nfp/nfp_net.h| 6 +++---
drivers/net/ethernet/netronome/n
Control BAR pointer is used to unmask interrupts so it should be
in the first cacheline of adapter structure.
Signed-off-by: Jakub Kicinski
---
drivers/net/ethernet/netronome/nfp/nfp_net.h| 21 +++--
.../net/ethernet/netronome/nfp/nfp_net_ethtool.c| 14
From: Ram Amrani
Reserving doorbell BAR space according to the currently active CPUs
may result in a bug if disabled CPUs are later enabled but no
doorbell space was reserved for them.
Signed-off-by: Ram Amrani
Signed-off-by: Yuval Mintz
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 2
From: Ram Amrani
Reserving doorbell BAR space according to the currently active CPUs
may result in a bug if disabled CPUs are later enabled but no
doorbell space was reserved for them.
Signed-off-by: Ram Amrani
Signed-off-by: Yuval Mintz
---
drivers/net/ethernet/qlogic/qed/qed_dev.c | 2
/netronome/nfp/nfp_net.h
b/drivers/net/ethernet/netronome/nfp/nfp_net.h
index e744acc18ef4..690635660195 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net.h
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net.h
@@ -63,7 +63,7 @@
#define NFP_NET_POLL_TIMEOUT 5
/* Bar allocation */
-#define
From: Sudarsana Reddy Kalluru
Date: Tue, 28 Jun 2016 07:46:03 -0400
> SPQ doorbell is currently protected with the compilation barrier. Under the
> stress scenarios, we may get into a state where (due to the weak ordering)
> several ramrod doorbells were written to the BAR with an out
SPQ doorbell is currently protected with the compilation barrier. Under the
stress scenarios, we may get into a state where (due to the weak ordering)
several ramrod doorbells were written to the BAR with an out-of-order
producer values. Need to change the barrier type to a write barrier to make
From: Ram Amrani
Driver learns the inner bar sized from a register configured by management
firmware, but older versions are not setting this register.
But since we know which values were configured back then, use them instead.
Signed-off-by: Ram Amrani
Signed-off-by: Yuval Mintz
---
drivers
From: Ariel Elior
Can't rely on pci config space to discover bar size,
as in some environments this returns a wrong, too large value.
Instead, rely on device register, which contains the value
provided by MFW at preboot.
Signed-off-by: Ariel Elior
Signed-off-by: Manish Chopra
---
driver
This is the i40e equivalent of commit c762dff24c06 ("ixgbe: Look up MAC
address in Open Firmware or IDPROM").
As with that fix, attempt to look up the MAC address in Open Firmware
on systems that support it, and use IDPROM on SPARC if no OF address
is found.
In the case of the i40e there is an a
From: Ariel Elior
Can't rely on pci config space to discover bar size,
as in some environments this returns a wrong, too large value.
Instead, rely on device register, which contains the value
provided by MFW at preboot.
Signed-off-by: Ariel Elior
Signed-off-by: Manish Chopra
---
driver
44 matches
Mail list logo
