On Wed, May 13, 2020 at 03:33:35PM -0300, Jason Gunthorpe wrote:
> On Thu, May 07, 2020 at 01:59:21PM -0500, Gustavo A. R. Silva wrote:
> > The current codebase makes use of the zero-length array language
> > extension to the C90 standard, but the preferred mechanism to declare
> > variable-length
On Tue, May 12, 2020 at 05:33:20PM +0200, Andrey Konovalov wrote:
> The kasan_report() functions belongs to report.c, as it's a common
> functions that does error reporting.
>
> Reported-by: Leon Romanovsky
> Signed-off-by: Andrey Konovalov
> ---
&g
On Tue, May 12, 2020 at 05:33:21PM +0200, Andrey Konovalov wrote:
> KASAN is currently missing declarations for __asan_report* and
> __hwasan* functions. This can lead to compiler warnings.
>
> Reported-by: Leon Romanovsky
> Signed-off-by: Andrey Konovalov
> ---
>
On Tue, May 12, 2020 at 05:34:10PM +0200, Andrey Konovalov wrote:
> On Tue, May 12, 2020 at 8:37 AM Leon Romanovsky wrote:
> >
> > From: Leon Romanovsky
> >
> > Hi,
> >
> > The following two fixes are adding missing function prototypes
> > decl
On Tue, May 12, 2020 at 09:37:26AM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Hi,
>
> The following two fixes are adding missing function prototypes
> declarations to internal kasan header in order to eliminate compilation
> warnings.
>
> Thanks
So
From: Leon Romanovsky
Hi,
The following two fixes are adding missing function prototypes
declarations to internal kasan header in order to eliminate compilation
warnings.
Thanks
Leon Romanovsky (2):
kasan: fix compilation warnings due to missing function prototypes
kasan: add missing
From: Leon Romanovsky
Use internal kasan header to declare missing prototypes to fix the
following compilation warnings.
mm/kasan/report.c:457:6: warning: no previous prototype for 'report_enabled'
[-Wmissing-prototypes]
457 | bool report_enabled(void)
| ^
From: Leon Romanovsky
__asan_report_* function generates the following warnings while compiling
kernel, add them to the internal header to be aligned with other __asan_*
function prototypes.
mm/kasan/generic_report.c:130:6: warning: no previous prototype for
'__asan_report_load1_no
olin Ian King
> ---
> drivers/infiniband/hw/mlx5/qp.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
Fixes: 8bde2c509e40 ("RDMA/mlx5: Update all DRIVER QP places to use QP subtype")
Thanks,
Acked-by: Leon Romanovsky
/core/en/tc_tun.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky
From: Leon Romanovsky
Hi,
Two changes, pretty straightforward.
Thanks
Jason Gunthorpe (2):
RDMA/uverbs: Do not discard the IB_EVENT_DEVICE_FATAL event
RDMA/uverbs: Move IB_EVENT_DEVICE_FATAL to destroy_uobj
drivers/infiniband/core/rdma_core.c | 3 +-
drivers/infiniband/core
On Wed, May 06, 2020 at 12:23:29PM -0700, Jakub Kicinski wrote:
> On Wed, 6 May 2020 22:16:11 +0300 Leon Romanovsky wrote:
> > > +#define MTK_MAC_DRVNAME"mtk_eth_mac"
> > > +#define MTK_MAC_VERSION"
On Tue, May 5, 2020 at 5:03 PM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> This adds the driver for the MediaTek Ethernet MAC used on the MT8* SoC
> family. For now we only support full-duplex.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> drivers/net/ethernet/mediatek/Kconfig
From: Leon Romanovsky
Changelog:
v1: Forgot to add patch "IB/uverbs: Move QP, SRQ, WQ type and flags to UAPI"
v0: https://lore.kernel.org/lkml/20200506074049.8347-1-l...@kernel.org
---
>From Yishai:
This s
From: Leon Romanovsky
>From Jason,
These are intended to be no-functional change edits that tidy up the
code flow or coding style.
Thanks
Danit Goldberg (1):
RDMA/cm: Remove unused store to ret in cm_rej_handler
Jason Gunthorpe (9):
RDMA/addr: Mark addr_resolve as might_sleep()
RDMA
From: Leon Romanovsky
>From Yishai:
This series enables applicable events objects (i.e. QP, SRQ, CQ, WQ) to
be created with their own asynchronous event FD.
Before this series any affiliated event on an object was reported on the
first asynchronous event FD that was created on the cont
From: Leon Romanovsky
Hi,
This short series continue to cleanup qp.c file, which grew
to be completely unmaintainable.
Thanks
Leon Romanovsky (2):
RDMA/mlx5: Update mlx5_ib to use new cmd interface
RDMA/mlx5: Move all WR logic from qp.c to separate file
Max Gurtovoy (1):
RDMA/mlx5
On Mon, May 04, 2020 at 05:41:56PM +0200, Arnd Bergmann wrote:
> On Sun, May 3, 2020 at 7:30 AM Leon Romanovsky wrote:
> > On Thu, Apr 30, 2020 at 04:37:14PM +0200, Arnd Bergmann wrote:
> > > On Thu, Apr 30, 2020 at 7:22 AM Leon Romanovsky wrote:
> > >
> > > W
From: Leon Romanovsky
Changelog:
v3: Rebased on latest rdma-nex, which includes HCA set capability patch
and LAG code and this is why new patch from Maor was added.
v2: https://lore.kernel.org/linux-rdma/20200413133703.932731-1-l...@kernel.org
Dropped patch "RDMA/cm: Set flow lab
On Thu, Apr 30, 2020 at 04:37:14PM +0200, Arnd Bergmann wrote:
> On Thu, Apr 30, 2020 at 7:22 AM Leon Romanovsky wrote:
> > On Tue, Apr 28, 2020 at 11:23:47PM +0200, Arnd Bergmann wrote:
> > > Moving the mlx5_ifc_query_qp_out_bits structure on the stack was a bit
> > &g
On Fri, May 01, 2020 at 12:48:36PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the net-next tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/steering/dr_send.c
>
> between commit:
>
> 8075411d93b6 ("net/mlx5: DR, On creation set CQ's arm_db member
On Tue, Apr 28, 2020 at 11:23:47PM +0200, Arnd Bergmann wrote:
> Moving the mlx5_ifc_query_qp_out_bits structure on the stack was a bit
> excessive and now causes the compiler to complain on 32-bit architectures:
>
> drivers/net/ethernet/mellanox/mlx5/core/debugfs.c: In function
> 'qp_read_field':
On Wed, Oct 09, 2019 at 09:44:58PM -0700, Yizhuo Zhai wrote:
> Hi All:
> drivers/infiniband/sw/rxe/rxe_verbs.c:
> The function to_rdev() could return NULL, but no caller in this file
> checks the return value but directly dereference them, which seems
> potentially unsafe. Callers include rxe_query
On Wed, Oct 02, 2019 at 04:35:06PM -0500, Navid Emamdoost wrote:
> Hi Jason,
>
> Thanks for the feedback. Yes, you are right if the skb release is
> moved under err4 label it will cause a double free as
> c4iw_ref_send_wait will release skb in case of error.
> So, in order to avoid leaking skb in c
On Fri, Sep 27, 2019 at 05:37:28PM -0500, Navid Emamdoost wrote:
> In mlx5_fw_fatal_reporter_dump if mlx5_crdump_collect fails the
> allocated memory for cr_data must be released otherwise there will be
> memory leak. To fix this, this commit changes the return instruction
> into goto error handlin
On Fri, Sep 06, 2019 at 05:42:37PM +0200, Arnd Bergmann wrote:
> On some 32-bit architectures, size_t is defined as 'int' rather
> than 'long', causing a harmless warning:
>
> drivers/infiniband/core/umem_odp.c:220:7: error: comparison of distinct
> pointer types ('typeof (umem_odp->umem.address)
quot;microblaze: fix get_user/put_user side-effects")
> Reported-by: kbuild test robot
> Signed-off-by: Randy Dunlap
> Cc: Al Viro
> Cc: Steven J. Magnani
> Cc: Michal Simek
> Cc: Jason Gunthorpe
> Cc: Leon Romanovsky
> Cc: Andrew Morton
> Cc: Doug Ledford
>
On Wed, Aug 28, 2019 at 08:57:19AM +0530, Souptick Joarder wrote:
> On Tue, Aug 27, 2019 at 9:19 PM Jason Gunthorpe wrote:
> >
> > On Tue, Aug 27, 2019 at 01:48:57AM +0530, Souptick Joarder wrote:
> > > On Mon, Aug 26, 2019 at 5:50 PM Jason Gunthorpe wrote:
> > > >
> > > > On Mon, Aug 26, 2019 at
On Tue, Aug 27, 2019 at 10:08:30AM -0500, Josh Poimboeuf wrote:
> On Mon, Aug 26, 2019 at 04:38:29PM -0700, Nathan Chancellor wrote:
> > Looks like that comes from tune_qsfp, which gets inlined into
> > tune_serdes but I am far from an objtool expert so I am not
> > really sure what kind of issues
On Thu, Aug 22, 2019 at 05:05:51AM +, Haiyang Zhang wrote:
> From: Eran Ben Elisha
>
> HV VHCA is a layer which provides PF to VF communication channel based on
> HyperV PCI config channel. It implements Mellanox's Inter VHCA control
> communication protocol. The protocol contains control bloc
On Thu, Aug 22, 2019 at 05:05:47AM +, Haiyang Zhang wrote:
> From: Eran Ben Elisha
>
> Add wrapper functions for HyperV PCIe read / write /
> block_invalidate_register operations. This will be used as an
> infrastructure in the downstream patch for software communication.
>
> This will be ena
On Thu, Aug 22, 2019 at 06:52:19AM +, YueHaibing wrote:
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Signed-off-by: YueHaibing
> ---
> drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
Than
ee_data' label
> to free 'data' before returning the error.
>
> Signed-off-by: Wenwen Wang
> ---
> drivers/infiniband/hw/hfi1/fault.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
Thanks,
Reviewed-by: Leon Romanovsky
e error.
>
> Signed-off-by: Wenwen Wang
> ---
> drivers/infiniband/hw/hfi1/fault.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
Thanks,
Reviewed-by: Leon Romanovsky
ree
> 'tun_qp->tx_ring' whenever an error occurs.
>
> Signed-off-by: Wenwen Wang
> ---
> drivers/infiniband/hw/mlx4/mad.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Thanks,
Acked-by: Leon Romanovsky
On Sun, Aug 11, 2019 at 12:53:07AM +0900, Masahiro Yamada wrote:
> Now that the single target build descends into sub-directories
> in the same ways as the normal build, these dummy Makefiles
> are not needed any more.
>
> Signed-off-by: Masahiro Yamada
> ---
>
It is hard to test/review/ack on th
On Sat, Aug 10, 2019 at 01:25:45PM +0200, Pavel Machek wrote:
> Hi!
>
> > From: Edward Srouji
> >
> > [ Upstream commit 7a32f2962c56d9d8a836b4469855caeee8766bd4 ]
> >
> > Fix modify_cq_in alignment to match the device specification.
> > After this fix the 'cq_umem_valid' field will be in the right
quot;microblaze: fix get_user/put_user side-effects")
> Reported-by: kbuild test robot
> Signed-off-by: Randy Dunlap
> Cc: Al Viro
> Cc: Steven J. Magnani
> Cc: Michal Simek
> Cc: Jason Gunthorpe
> Cc: Leon Romanovsky
> Cc: Andrew Morton
> ---
> arch/microblaze/include/asm/uaccess.h |6 ++
> 1 file changed, 6 insertions(+)
>
Thanks, it works for us.
Reviewed-by: Leon Romanovsky
.c | 6 +++---
> > drivers/net/ethernet/mellanox/mlx5/core/qp.c | 6 +++---
> > include/linux/mlx5/driver.h | 3 ++-
> > 3 files changed, 8 insertions(+), 7 deletions(-)
> >
>
> LGTM, Leon, let me know if you are happy with this version,
> this should go to mlx5-next.
Thanks,
Acked-by: Leon Romanovsky
On Mon, Aug 05, 2019 at 08:06:36PM +, Saeed Mahameed wrote:
> On Mon, 2019-08-05 at 14:55 +0800, Chuhong Yuan wrote:
> > On Mon, Aug 5, 2019 at 2:13 PM Leon Romanovsky
> > wrote:
> > > On Sun, Aug 04, 2019 at 10:44:47PM +0800, Chuhong Yuan wrote:
> > > >
On Sun, Aug 04, 2019 at 10:44:47PM +0800, Chuhong Yuan wrote:
> On Sun, Aug 4, 2019 at 8:59 PM Leon Romanovsky wrote:
> >
> > On Sat, Aug 03, 2019 at 12:48:28AM +0800, Chuhong Yuan wrote:
> > > refcount_t is better for reference counters since its
> > > imp
On Sun, Aug 04, 2019 at 10:58:19PM +0800, Chuhong Yuan wrote:
> On Sun, Aug 4, 2019 at 8:48 PM Leon Romanovsky wrote:
> >
> > On Fri, Aug 02, 2019 at 08:10:35PM +0800, Chuhong Yuan wrote:
> > > Reference counters are preferred to use refcount_t instead of
> > > at
On Sun, Aug 04, 2019 at 09:50:50PM -0700, Randy Dunlap wrote:
> On 4/2/19 7:38 PM, Randy Dunlap wrote:
> > On 2/28/19 1:03 AM, kbuild test robot wrote:
> >> Hi Jason,
> >>
> >> FYI, the error/warning still remains.
> >>
> >> tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
On Sat, Aug 03, 2019 at 12:48:28AM +0800, Chuhong Yuan wrote:
> refcount_t is better for reference counters since its
> implementation can prevent overflows.
> So convert atomic_t ref counters to refcount_t.
I'm not thrilled to see those automatic conversion patches, especially
for flows which can
On Sat, Aug 03, 2019 at 01:23:34AM +0800, Chuhong Yuan wrote:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
>
> First convert the refcount field to refcount_t
On Fri, Aug 02, 2019 at 08:10:35PM +0800, Chuhong Yuan wrote:
> Reference counters are preferred to use refcount_t instead of
> atomic_t.
> This is because the implementation of refcount_t can prevent
> overflows and detect possible use-after-free.
>
> First convert the refcount field to refcount_t
c | 2 --
> 1 file changed, 2 deletions(-)
>
I'm hitting this error too.
Thanks,
Reviewed-by: Leon Romanovsky
1 deletion(-)
>
Thanks,
Reviewed-by: Leon Romanovsky
On Mon, Jul 29, 2019 at 05:26:30AM +, Parav Pandit wrote:
>
>
> > -Original Message-
> > From: linux-kernel-ow...@vger.kernel.org > ow...@vger.kernel.org> On Behalf Of Parav Pandit
> > Sent: Monday, July 29, 2019 10:55 AM
> > To: Jia-Ju Bai ; l...@kernel.org;
> > dledf...@redhat.com; j
On Mon, Jul 29, 2019 at 10:16:30AM +0800, Jia-Ju Bai wrote:
> In set_roce_addr(), there is an if statement on line 589 to check whether
> gid is NULL:
> if (gid)
>
> When gid is NULL, it is used on line 613:
> return mlx5_core_roce_gid_set(..., gid->raw, ...);
>
> Thus, a possible null-poin
On Tue, Jul 23, 2019 at 09:34:02AM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 23, 2019 at 10:43:39AM +0300, Leon Romanovsky wrote:
> > On Tue, Jul 23, 2019 at 10:49:08AM +0800, YueHaibing wrote:
> > > If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
> > > but INFINIBA
On Tue, Jul 23, 2019 at 06:06:22PM +0800, Yuehaibing wrote:
>
> On 2019/7/23 15:43, Leon Romanovsky wrote:
> > On Tue, Jul 23, 2019 at 10:49:08AM +0800, YueHaibing wrote:
> >> If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
> >> but INFINIBAND_HNS is y, bui
On Tue, Jul 23, 2019 at 10:49:08AM +0800, YueHaibing wrote:
> If INFINIBAND_HNS_HIP08 is selected and HNS3 is m,
> but INFINIBAND_HNS is y, building fails:
>
> drivers/infiniband/hw/hns/hns_roce_hw_v2.o: In function `hns_roce_hw_v2_exit':
> hns_roce_hw_v2.c:(.exit.text+0xd): undefined reference to
On Thu, Jul 11, 2019 at 01:16:03PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 11 Jul 2019 13:13:44 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 11 Jul 2019 02:26:27 + Jason Gunthorpe
> > wrote:
> > >
> > > On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote:
> > >
ments
> that return early so that the code is easier to follow.
>
> Suggested-by: Leon Romanovsky
> Suggested-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
> ---
Thanks again,
Reviewed-by: Leon Romanovsky
ead1f360e8 ("net/mlx5e: Add kTLS TX HW offload support")
> Link: https://github.com/ClangBuiltLinux/linux/issues/590
> Suggested-by: Leon Romanovsky
> Suggested-by: Nick Desaulniers
> Signed-off-by: Nathan Chancellor
> ---
>
> v1 -> v2:
>
> * Refactor switch
On Wed, Jul 10, 2019 at 02:31:58PM +1000, Stephen Rothwell wrote:
> Hi Leon,
>
> On Tue, 9 Jul 2019 09:43:46 +0300 Leon Romanovsky wrote:
> >
> > From 56c9e15ec670af580daa8c3ffde9503af3042d67 Mon Sep 17 00:00:00 2001
> > From: Leon Romanovsky
> > Date: Sun, 7 Ju
On Wed, Jul 10, 2019 at 09:50:09AM +0800, YueHaibing wrote:
> In iw_create_tx_threads(), if we failed to create kthread,
> we should print the 'rv', this fix gcc warning:
>
> drivers/infiniband/sw/siw/siw_main.c: In function 'siw_create_tx_threads':
> drivers/infiniband/sw/siw/siw_main.c:91:11: war
On Tue, Jul 09, 2019 at 04:10:24PM -0700, Nathan Chancellor wrote:
> On Tue, Jul 09, 2019 at 03:44:59PM -0700, Nick Desaulniers wrote:
> > On Mon, Jul 8, 2019 at 4:13 PM Nathan Chancellor
> > wrote:
> > >
> > > clang warns:
> > >
> > > drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_tx.c:251
On Tue, Jul 09, 2019 at 10:43:56PM +1000, Stephen Rothwell wrote:
> Hi Leon,
>
> On Tue, 9 Jul 2019 07:18:00 +0000 Leon Romanovsky wrote:
> >
> > For some reason, I wasn't in initial email report, can you please check why?
>
> Sorry about that, I manually grab e
On Tue, Jul 09, 2019 at 10:04:16AM +0300, Mark Zhang wrote:
> Hi Stephen,
Stephen,
For some reason, I wasn't in initial email report, can you please check why?
I need to be aware of any issues related to patches with my name on it
for tracking and improving internal submission flows/checks.
>
>
27;t know why this didn't fail after I mereged
> that tree.
I had the same question, because I have this fix for a couple of days already.
From 56c9e15ec670af580daa8c3ffde9503af3042d67 Mon Sep 17 00:00:00 2001
From: Leon Romanovsky
Date: Sun, 7 Jul 2019 10:43:42 +0300
Subject: [PATCH] Fixup to build SI
On Fri, Jul 05, 2019 at 07:49:06AM +0530, Parav Pandit wrote:
> On Fri, Jun 28, 2019 at 2:20 PM Dag Moxnes wrote:
> >
> > Use neighbour lock when copying MAC address from neighbour data struct
> > in dst_fetch_ha.
> >
> > When not using the lock, it is possible for the function to race with
> > ne
On Thu, Jul 04, 2019 at 12:47:38PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
> drivers/infiniband/hw/mlx5/cq.c
>
> between commit:
>
> e39afe3d6dbd ("RDMA: Convert CQ allocations to be under core
> responsibility")
>
> from
On Tue, Jul 02, 2019 at 10:05:33AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> In commit
>
> 16fff98a7e82 ("net/mlx5: E-Switch, Reg/unreg function changed event at
> correct stage")
>
> Fixes tag
>
> Fixes: 61fc880839e6 ("net/mlx5: E-Switch, Handle representors creation in
> handler context"
On Tue, Jul 02, 2019 at 01:13:27PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
> drivers/net/ethernet/mellanox/mlx5/core/eswitch_offloads.c
>
> between commit:
>
> 955858009708 ("net/mlx5e: Fix number of vports for ingress ACL
On Mon, Jun 17, 2019 at 12:19:59PM +1000, Stephen Rothwell wrote:
> Hi Leon,
>
> Today's linux-next merge of the mlx5-next tree got a conflict in:
>
> include/linux/mlx5/eswitch.h
>
> between commit:
>
> 02f3afd97556 ("net/mlx5: E-Switch, Correct type to u16 for vport_num and
> int for vport_i
On Fri, Jun 14, 2019 at 03:46:50PM -0400, Doug Ledford wrote:
> On Fri, 2019-06-14 at 14:59 +0100, Colin Ian King wrote:
> > Hi,
> >
> > Static analysis with Coverity reported an issue with the following
> > commit:
> >
> > commit a52c8e2469c30cf7ac
On Mon, Jun 10, 2019 at 10:28:49AM -0300, Jason Gunthorpe wrote:
> On Sat, Jun 08, 2019 at 12:22:31PM +0300, Dan Carpenter wrote:
> > The ucmd->log_sq_bb_count is a u8 that comes from the user. If it's
> > larger than the number of bits in an int then that's undefined behavior.
> > It turns out th
On Tue, Jun 04, 2019 at 10:42:22AM -0500, Gustavo A. R. Silva wrote:
> Make use of the struct_size() helper instead of an open-coded version
> in order to avoid any potential type mistakes, in particular in the
> context in which this code is being used.
What does "in particular in the context in
On Thu, May 30, 2019 at 04:35:44AM -0700, Guenter Roeck wrote:
> 32-bit builds fail with errors such as
>
> ERROR: "__udivdi3" [drivers/infiniband/hw/mlx5/mlx5_ib.ko] undefined!
It is fixed in rdma-rc.
https://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git/commit/?h=wip/jgg-for-rc&id=37eb86
On Mon, May 20, 2019 at 02:28:35PM +0300, Leon Romanovsky wrote:
> On Mon, May 20, 2019 at 01:19:02PM +0200, Michal Kubecek wrote:
> > Commit 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
> > breaks i386 build by introducing three 64-bit divisio
On Mon, May 20, 2019 at 06:34:49AM -0700, Joe Perches wrote:
> On Mon, 2019-05-20 at 13:16 +, Michal Kalderon wrote:
> > > From: Joe Perches
> > > Sent: Monday, May 20, 2019 3:57 PM
> > > Subject: [EXT] Re: [PATCH] checkpatch: add test for empty line after Fixes
> > > statement
> > >
> > > Ext
On Mon, May 20, 2019 at 05:56:36AM -0700, Joe Perches wrote:
> On Mon, 2019-05-20 at 15:42 +0300, Michal Kalderon wrote:
> > Check that there is no empty line after a fixes statement
>
> why?
It is common mistake for Gerrit users, they are removing
their ChangeID crap with some wrong sed command w
On Mon, May 20, 2019 at 01:19:02PM +0200, Michal Kubecek wrote:
> Commit 25c13324d03d ("IB/mlx5: Add steering SW ICM device memory type")
> breaks i386 build by introducing three 64-bit divisions. As the divisor
> is MLX5_SW_ICM_BLOCK_SIZE() which is always a power of 2, we can replace
> the divisi
On Thu, May 16, 2019 at 02:12:15PM +0100, Colin King wrote:
> From: Colin Ian King
>
> It is possible that nlmsg_put can return a null pointer, currently
> this will lead to a null pointer dereference when passing a null
> nlh pointer to nlmsg_end. Fix this by adding a null pointer check.
>
> Add
On Wed, May 15, 2019 at 12:34:00AM +, Jason Gunthorpe wrote:
> On Tue, May 14, 2019 at 12:45:10PM -0700, Nathan Chancellor wrote:
> > DIV_ROUND_UP is u64 / u32 in this case. I think DIV_ROUND_UP_ULL is
> > needed but I am not sure if that has any unintended side effects so I
> > didn't want to
On Mon, May 06, 2019 at 04:50:20PM -0300, Jason Gunthorpe wrote:
> On Mon, May 06, 2019 at 06:30:59PM +0200, Andrey Konovalov wrote:
> > This patch is a part of a series that extends arm64 kernel ABI to allow to
> > pass tagged user pointers (with the top byte set to something else other
> > than 0
On Mon, Apr 29, 2019 at 01:13:01PM -0400, Doug Ledford wrote:
> On Mon, 2019-04-29 at 09:48 -0700, Linus Torvalds wrote:
> > On Mon, Apr 29, 2019 at 9:29 AM Doug Ledford wrote:
> > >
> > > drivers/infiniband/core/uverbs_main.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Th
On Mon, Apr 29, 2019 at 10:30:06AM +0200, Geert Uytterhoeven wrote:
> On Mon, Apr 29, 2019 at 10:28 AM Geert Uytterhoeven
> wrote:
> > JFYI, when comparing v5.1-rc7[1] to v5.1-rc6[3], the summaries are:
> > - build errors: +1/-0
>
> + /kisskb/src/drivers/infiniband/core/uverbs_main.c: error: '
On Mon, Apr 29, 2019 at 11:00:40AM +0200, Michal Kubecek wrote:
> On Mon, Apr 29, 2019 at 08:40:37AM +, Jason Gunthorpe wrote:
> > On Mon, Apr 29, 2019 at 08:09:47AM +0200, Heiko Carstens wrote:
> > > On Sun, Apr 28, 2019 at 11:52:12AM +, Jason Gunthorpe wrote:
> > > > Hi Linus,
> > > >
> >
E on ARM) split the
> HMM_MIRROR option dependency from the HMM_DEVICE dependency.
>
> Signed-off-by: Jérôme Glisse
> Cc: Leon Romanovsky
> Cc: Jason Gunthorpe
> Cc: Andrew Morton
> Cc: Ralph Campbell
> Cc: John Hubbard
> ---
> mm/Kconfig | 17 ++-
On Fri, Apr 12, 2019 at 04:30:24PM -0300, Jason Gunthorpe wrote:
> On Mon, Mar 04, 2019 at 06:27:26AM +, Parav Pandit wrote:
>
> > I think we should use rdma_nl_register(RDMA_NL_RDMA_CM, cma_cb_table) which
> > was removed as part of ID stats removal.
> > Because of below reasons.
> > 1. rdma
an King
> ---
> drivers/infiniband/hw/mlx5/qp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Thanks,
Acked-by: Leon Romanovsky
signature.asc
Description: PGP signature
On Wed, Apr 10, 2019 at 11:41:24AM -0400, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> Changes since v1/v2 are about rebase and better comments in the code.
> Previous cover letter slightly updated.
>
>
> This patchset convert RDMA ODP to use HMM underneath this is motivated
> by stronger c
On Tue, Apr 02, 2019 at 04:39:12PM -0700, Bart Van Assche wrote:
> On Mon, 2019-04-01 at 21:29 +0300, Leon Romanovsky wrote:
> > On Mon, Apr 01, 2019 at 02:45:54PM -0300, Jason Gunthorpe wrote:
> > > On Mon, Apr 01, 2019 at 10:36:05AM -0700, syzbot wrote:
> > > >
#syz dup: WARNING in cma_exit_net
On Mon, Apr 01, 2019 at 10:35:06AM -0700, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:e3ecb83e Add linux-next specific files for 20190401
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt
On Mon, Apr 01, 2019 at 02:45:54PM -0300, Jason Gunthorpe wrote:
> On Mon, Apr 01, 2019 at 10:36:05AM -0700, syzbot wrote:
> > Hello,
> >
> > syzbot found the following crash on:
> >
> > HEAD commit:e3ecb83e Add linux-next specific files for 20190401
> > git tree: linux-next
> > console o
On Wed, Mar 27, 2019 at 12:49:17PM +0100, Borislav Petkov wrote:
> On Wed, Mar 27, 2019 at 01:36:28PM +0200, Leon Romanovsky wrote:
> > At the end, it is reduced to our usage, we are running QEMU inside
> > docker to test kernel changes with limitation on number of CPUs to use.
>
On Wed, Mar 27, 2019 at 12:14:52PM +0100, Borislav Petkov wrote:
> On Wed, Mar 27, 2019 at 12:50:24PM +0200, Leon Romanovsky wrote:
> > It is how we are internally running verification and development,
> > with KERN_DEBUG level, we need it to catch bugs.
>
> And what is the
On Wed, Mar 27, 2019 at 11:18:15AM +0100, Borislav Petkov wrote:
> On Wed, Mar 27, 2019 at 12:11:33PM +0200, Leon Romanovsky wrote:
> > ok, I tested your variant and it still prints a t least on my systems,
>
> Probably because your loglevel is set to debug. And no, we don'
On Wed, Mar 27, 2019 at 11:53:37AM +0200, Leon Romanovsky wrote:
> On Wed, Mar 27, 2019 at 02:49:02AM -0700, Joe Perches wrote:
> > On Wed, 2019-03-27 at 11:38 +0200, Leon Romanovsky wrote:
> > > On Wed, Mar 27, 2019 at 02:17:40AM -0700, Joe Perches wrote:
> > > > On
On Wed, Mar 27, 2019 at 02:49:02AM -0700, Joe Perches wrote:
> On Wed, 2019-03-27 at 11:38 +0200, Leon Romanovsky wrote:
> > On Wed, Mar 27, 2019 at 02:17:40AM -0700, Joe Perches wrote:
> > > On Wed, 2019-03-27 at 11:09 +0200, Leon Romanovsky wrote:
> > > > Kernel is
On Wed, Mar 27, 2019 at 02:17:40AM -0700, Joe Perches wrote:
> On Wed, 2019-03-27 at 11:09 +0200, Leon Romanovsky wrote:
> > Kernel is booted with less possible CPUs (possible_cpus kernel boot
> > option) than available CPUs will have prints like this:
> []
> > diff --gi
From: Leon Romanovsky
Kernel is booted with less possible CPUs (possible_cpus kernel boot
option) than available CPUs will have prints like this:
[1.131039] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor
55/0x1f ignored.
[1.132228] ACPI: Unable to map lapic to logical cpu
On Tue, Mar 26, 2019 at 07:08:07PM +0100, Rafael J. Wysocki wrote:
> On Tue, Mar 26, 2019 at 6:53 PM Leon Romanovsky wrote:
> >
> > On Tue, Mar 26, 2019 at 05:30:22PM +0100, Rafael J. Wysocki wrote:
> > > On Tue, Mar 26, 2019 at 4:32 PM Leon Romanovsky wrote:
> > &g
On Tue, Mar 26, 2019 at 05:30:22PM +0100, Rafael J. Wysocki wrote:
> On Tue, Mar 26, 2019 at 4:32 PM Leon Romanovsky wrote:
> >
> > On Tue, Mar 26, 2019 at 04:12:27PM +0100, Rafael J. Wysocki wrote:
> > > On Tue, Mar 26, 2019 at 3:41 PM Leon Romanovsky wrote:
> > &g
On Tue, Mar 26, 2019 at 04:12:27PM +0100, Rafael J. Wysocki wrote:
> On Tue, Mar 26, 2019 at 3:41 PM Leon Romanovsky wrote:
> >
> > On Tue, Mar 26, 2019 at 01:29:54PM +0100, Rafael J. Wysocki wrote:
> > > On Tue, Mar 26, 2019 at 1:02 PM Leon Romanovsky wrote:
&g
On Tue, Mar 26, 2019 at 01:29:54PM +0100, Rafael J. Wysocki wrote:
> On Tue, Mar 26, 2019 at 1:02 PM Leon Romanovsky wrote:
> >
> > From: Leon Romanovsky
> >
> > Kernel is booted with less possible CPUs (possible_cpus kernel boot
> > option) than availabl
From: Leon Romanovsky
Kernel is booted with less possible CPUs (possible_cpus kernel boot
option) than available CPUs will have prints like this:
[1.131039] APIC: NR_CPUS/possible_cpus limit of 8 reached. Processor
55/0x1f ignored.
[1.132228] ACPI: Unable to map lapic to logical cpu
501 - 600 of 1001 matches
Mail list logo