* [PATCH mlx5-next 2/5] net/mlx5: Improve functions documentation
From: Saeed Mahameed @ 2019-08-15 19:46 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org
In-Reply-To: <20190815194543.14369-1-saeedm@mellanox.com>
Fix documentation of mlx5_eq_enable/disable to cleanup compiler warnings.
drivers/net/ethernet/mellanox/mlx5/core//eq.c:334:
warning: Function parameter or member 'dev' not described in 'mlx5_eq_enable'
warning: Function parameter or member 'eq' not described in 'mlx5_eq_enable'
warning: Function parameter or member 'nb' not described in 'mlx5_eq_enable'
drivers/net/ethernet/mellanox/mlx5/core//eq.c:355:
warning: Function parameter or member 'dev' not described in 'mlx5_eq_disable'
warning: Function parameter or member 'eq' not described in 'mlx5_eq_disable'
warning: Function parameter or member 'nb' not described in 'mlx5_eq_disable'
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 22 ++++++++++++--------
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/eq.c b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
index 2df9aaa421c6..a0e78ab64618 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/eq.c
@@ -324,10 +324,13 @@ create_map_eq(struct mlx5_core_dev *dev, struct mlx5_eq *eq,
/**
* mlx5_eq_enable - Enable EQ for receiving EQEs
- * @dev - Device which owns the eq
- * @eq - EQ to enable
- * @nb - notifier call block
- * mlx5_eq_enable - must be called after EQ is created in device.
+ * @dev : Device which owns the eq
+ * @eq : EQ to enable
+ * @nb : Notifier call block
+ *
+ * Must be called after EQ is created in device.
+ *
+ * @return: 0 if no error
*/
int mlx5_eq_enable(struct mlx5_core_dev *dev, struct mlx5_eq *eq,
struct notifier_block *nb)
@@ -344,11 +347,12 @@ int mlx5_eq_enable(struct mlx5_core_dev *dev, struct mlx5_eq *eq,
EXPORT_SYMBOL(mlx5_eq_enable);
/**
- * mlx5_eq_disable - Enable EQ for receiving EQEs
- * @dev - Device which owns the eq
- * @eq - EQ to disable
- * @nb - notifier call block
- * mlx5_eq_disable - must be called before EQ is destroyed.
+ * mlx5_eq_disable - Disable EQ for receiving EQEs
+ * @dev : Device which owns the eq
+ * @eq : EQ to disable
+ * @nb : Notifier call block
+ *
+ * Must be called before EQ is destroyed.
*/
void mlx5_eq_disable(struct mlx5_core_dev *dev, struct mlx5_eq *eq,
struct notifier_block *nb)
--
2.21.0
^ permalink raw reply related
* [PATCH mlx5-next 3/5] net/mlx5: Add support for VNIC_ENV internal rq counter
From: Saeed Mahameed @ 2019-08-15 19:46 UTC (permalink / raw)
To: Saeed Mahameed, Leon Romanovsky
Cc: netdev@vger.kernel.org, linux-rdma@vger.kernel.org, Moshe Shemesh
In-Reply-To: <20190815194543.14369-1-saeedm@mellanox.com>
From: Moshe Shemesh <moshe@mellanox.com>
Add mlx5 interface support for reading internal rq out of buffer counter
as part of QUERY_VNIC_ENV command. The command is used by the driver to
query vnic diagnostic statistics from FW.
Signed-off-by: Moshe Shemesh <moshe@mellanox.com>
Signed-off-by: Saeed Mahameed <saeedm@mellanox.com>
---
include/linux/mlx5/mlx5_ifc.h | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/include/linux/mlx5/mlx5_ifc.h b/include/linux/mlx5/mlx5_ifc.h
index ab6ae723aae6..c788f895b350 100644
--- a/include/linux/mlx5/mlx5_ifc.h
+++ b/include/linux/mlx5/mlx5_ifc.h
@@ -1116,7 +1116,9 @@ struct mlx5_ifc_cmd_hca_cap_bits {
u8 cache_line_128byte[0x1];
u8 reserved_at_165[0x4];
u8 rts2rts_qp_counters_set_id[0x1];
- u8 reserved_at_16a[0x5];
+ u8 reserved_at_16a[0x2];
+ u8 vnic_env_int_rq_oob[0x1];
+ u8 reserved_at_16d[0x2];
u8 qcam_reg[0x1];
u8 gid_table_size[0x10];
@@ -2772,7 +2774,11 @@ struct mlx5_ifc_vnic_diagnostic_statistics_bits {
u8 transmit_discard_vport_down[0x40];
- u8 reserved_at_140[0xec0];
+ u8 reserved_at_140[0xa0];
+
+ u8 internal_rq_out_of_buffer[0x20];
+
+ u8 reserved_at_200[0xe00];
};
struct mlx5_ifc_traffic_counter_bits {
--
2.21.0
^ permalink raw reply related
* Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf
From: Kees Cook @ 2019-08-15 19:46 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Andy Lutomirski, Song Liu, Networking, bpf, Alexei Starovoitov,
Daniel Borkmann, Kernel Team, Lorenz Bauer, Jann Horn, Greg KH,
Linux API, LSM List
In-Reply-To: <20190813215823.3sfbakzzjjykyng2@ast-mbp>
On Tue, Aug 13, 2019 at 02:58:25PM -0700, Alexei Starovoitov wrote:
> agree that containers (namespaces) reduce amount of trust necessary
> for apps to run, but the end goal is not security though.
Unsurprisingly, I totally disagree: this is the very definition of
improved "security": reduced attack surface, confined trust, etc.
> Linux has become a single user system.
I hope this is just hyperbole, because it's not true in reality. I agree
that the vast majority of Linux devices are single-user-at-a-time
systems now (rather than the "shell servers" of yore), but the system
still has to be expected to confine users from each other, root, and the
hardware. Switching users on Chrome OS or a distro laptop, etc is still
very much expected to _mean_ something.
> If user can ssh into the host they can become root.
> If arbitrary code can run on the host it will be break out of any sandbox.
> Containers are not providing the level of security that is enough
> to run arbitrary code. VMs can do it better, but cpu bugs don't make it easy.
I'm not sure why you draw the line for VMs -- they're just as buggy
as anything else. Regardless, I reject this line of thinking: yes,
all software is buggy, but that isn't a reason to give up. In fact,
we should be trying very hard to create safe code (*insert arguments
for sane languages and toolchains here*).
If you look at software safety as a binary, you will always be
disappointed. If you look at it as it manifests in the real world,
then there is some perspective to be had. Reachability of flaws becomes
a major factor; exploit chain length becomes a factor. There are very
real impacts to be had from security hardening, sandboxing, etc. Of
course nothing is perfect, but the current state of the world isn't
as you describe. (And I say this with the knowledge of how long
the lifetime of bugs are in the kernel.)
> Containers are used to make production systems safer.
Yes.
> Some people call it more 'secure', but it's clearly not secure for
> arbitrary code
Perhaps it's just a language issue. "More secure" and "safer" mean
mostly the same thing to me. I tend to think "safer" is actually
a superset that includes things that wreck the user experience but
aren't actually in the privilege manipulation realm. In the traditional
"security" triad of confidentiality, integrity, and availability, I tend
to weigh availability less highly, but a bug that stops someone from
doing their work but doesn't wreck data, let them switch users, etc,
is still considered a "security" issue by many folks. The fewer bugs
someone is exposed to improves their security, safety, whatever. The
easiest way to do that is confinement and its associated attack surface
reduction. tl;dr: security and safety are very use-case-specific
continuum, not a binary state.
> When we say 'unprivileged bpf' we really mean arbitrary malicious bpf program.
> It's been a constant source of pain. The constant blinding, randomization,
> verifier speculative analysis, all spectre v1, v2, v4 mitigations
> are simply not worth it. It's a lot of complex kernel code without users.
> There is not a single use case to allow arbitrary malicious bpf
> program to be loaded and executed.
The world isn't binary (safe code/malicious code), and we need to build
systems that can be used safely even when things go wrong. Yes, probably
no one has a system that _intentionally_ feeds eBPF into the kernel from
a web form. But there is probably someone who does it unintentionally,
or has a user login exposed on a system where unpriv BPF is enabled. The
point is to create primitives as safely as possible so when things DO
go wrong, they fail safe instead of making things worse.
I'm all for a "less privileged than root" API for eBPF, but I get worried
when I see "security" being treated as a binary state. Especially when
it is considered an always-failed state. :)
--
Kees Cook
^ permalink raw reply
* [PATCH] net: cavium: fix driver name
From: Stephen Hemminger @ 2019-08-15 19:49 UTC (permalink / raw)
To: yuehaibing; +Cc: netdev, Stephen Hemminger
The driver name gets exposed in sysfs under /sys/bus/pci/drivers
so it should look like other devices. Change it to be common
format (instead of "Cavium PTP").
This is a trivial fix that was observed by accident because
Debian kernels were building this driver into kernel (bug).
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
drivers/net/ethernet/cavium/common/cavium_ptp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cavium/common/cavium_ptp.c b/drivers/net/ethernet/cavium/common/cavium_ptp.c
index 73632b843749..b821c9e1604c 100644
--- a/drivers/net/ethernet/cavium/common/cavium_ptp.c
+++ b/drivers/net/ethernet/cavium/common/cavium_ptp.c
@@ -10,7 +10,7 @@
#include "cavium_ptp.h"
-#define DRV_NAME "Cavium PTP Driver"
+#define DRV_NAME "cavium_ptp"
#define PCI_DEVICE_ID_CAVIUM_PTP 0xA00C
#define PCI_DEVICE_ID_CAVIUM_RST 0xA00E
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next v4 0/2] qed*: Support for NVM config attributes.
From: David Miller @ 2019-08-15 19:54 UTC (permalink / raw)
To: skalluru; +Cc: netdev, mkalderon, aelior
In-Reply-To: <20190814081153.18889-1-skalluru@marvell.com>
From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
Date: Wed, 14 Aug 2019 01:11:51 -0700
> The patch series adds support for managing the NVM config attributes.
> Patch (1) adds functionality to update config attributes via MFW.
> Patch (2) adds driver interface for updating the config attributes.
>
> Changes from previous versions:
> -------------------------------
> v4: Added more details on the functionality and its usage.
> v3: Removed unused variable.
> v2: Removed unused API.
>
> Please consider applying this series to "net-next".
Series applied.
^ permalink raw reply
* Re: [PATCH] net: pch_gbe: Fix memory leaks
From: Wenwen Wang @ 2019-08-15 20:03 UTC (permalink / raw)
To: David Miller
Cc: Richard Fontana, Allison Randal, Alexios Zavras,
Greg Kroah-Hartman, Thomas Gleixner,
open list:NETWORKING [GENERAL], open list, Wenwen Wang
In-Reply-To: <20190815.123430.831231953098536795.davem@davemloft.net>
On Thu, Aug 15, 2019 at 3:34 PM David Miller <davem@davemloft.net> wrote:
>
> From: Wenwen Wang <wenwen@cs.uga.edu>
> Date: Tue, 13 Aug 2019 20:33:45 -0500
>
> > In pch_gbe_set_ringparam(), if netif_running() returns false, 'tx_old' and
> > 'rx_old' are not deallocated, leading to memory leaks. To fix this issue,
> > move the free statements after the if branch.
> >
> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
>
> Why would they be "deallocated"? They are still assigned to
> adapter->tx_ring and adapter->rx_ring.
'adapter->tx_ring' and 'adapter->rx_ring' has been covered by newly
allocated 'txdr' and 'rxdr' respectively before this if statement.
Wenwen
^ permalink raw reply
* Re: [PATCH] wimax/i2400m: fix a memory leak bug
From: Wenwen Wang @ 2019-08-15 20:05 UTC (permalink / raw)
To: Wenwen Wang, Inaky Perez-Gonzalez,
supporter:INTEL WIRELESS WIMAX CONNECTION 2400, David S. Miller,
open list:NETWORKING DRIVERS, open list
In-Reply-To: <20190815184505.o7o2ojt7ag4shh7u@oracle.com>
On Thu, Aug 15, 2019 at 2:45 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> * Wenwen Wang <wenwen@cs.uga.edu> [190815 14:05]:
> > In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
> > to hold the original command line options. Then, the options are parsed.
> > However, if an error occurs during the parsing process, 'options_orig' is
> > not deallocated, leading to a memory leak bug. To fix this issue, free
> > 'options_orig' before returning the error.
> >
> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> > ---
> > drivers/net/wimax/i2400m/fw.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
> > index e9fc168..6b36f6d 100644
> > --- a/drivers/net/wimax/i2400m/fw.c
> > +++ b/drivers/net/wimax/i2400m/fw.c
> > @@ -342,6 +342,7 @@ int i2400m_barker_db_init(const char *_options)
> > "a 32-bit number\n",
> > __func__, token);
> > result = -EINVAL;
> > + kfree(options_orig);
> > goto error_parse;
> > }
> > if (barker == 0) {
> > @@ -350,8 +351,10 @@ int i2400m_barker_db_init(const char *_options)
> > continue;
> > }
> > result = i2400m_barker_db_add(barker);
> > - if (result < 0)
> > + if (result < 0) {
> > + kfree(options_orig);
> > goto error_add;
>
> I know that you didn't add this error_add label, but it seems like the
> incorrect goto label. Although looking at the caller indicates an add
> failed, this label is used prior to and after the memory leak you are
> trying to fix. It might be better to change this label to something
> like error_parse_add and move the kfree to the unwinding. If a new
> label is used, it becomes more clear as to what is being undone and
> there aren't two jumps into an unwind from two very different stages of
> the function. Adding a new label also has the benefit of moving the
> kfree to the unwind of error_parse.
Thanks for your suggestion! I will rework the patch.
Wenwen
^ permalink raw reply
* Re: [PATCH bpf] tools: bpftool: close prog FD before exit on showing a single program
From: Andrii Nakryiko @ 2019-08-15 20:16 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Quentin Monnet, Alexei Starovoitov, Daniel Borkmann, bpf,
Networking, oss-drivers
In-Reply-To: <20190815110917.657de4e3@cakuba.netronome.com>
On Thu, Aug 15, 2019 at 11:09 AM Jakub Kicinski
<jakub.kicinski@netronome.com> wrote:
>
> On Thu, 15 Aug 2019 11:05:16 -0700, Andrii Nakryiko wrote:
> > > > Would it be better to make show_prog(fd) close provided fd instead or
> > > > is it used in some other context where FD should live longer (I
> > > > haven't checked, sorry)?
> > >
> > > I think it used to close that's how the bug crept in. Other than the bug
> > > it's fine the way it is.
> >
> > So are you saying that show_prog() should or should not close FD?
>
> Yup, it we'd have to rename it to indicate it closes the fd, and it's
> only called in two places. Not worth the churn.
OK, I'm fine with that.
Acked-by: Andrii Nakryiko <andriin@fb.com>
^ permalink raw reply
* Re: [PATCH v3 1/2] rtw88: pci: Rearrange the memory usage for skb in RX ISR
From: Brian Norris @ 2019-08-15 20:25 UTC (permalink / raw)
To: Jian-Hong Pan
Cc: Yan-Hsuan Chuang, Kalle Valo, David S . Miller, Larry Finger,
David Laight, Christoph Hellwig, linux-wireless,
<netdev@vger.kernel.org>, Linux Kernel, linux, Daniel Drake,
stable
In-Reply-To: <20190710083825.7115-1-jian-hong@endlessm.com>
Hi all,
I realize this already is merged, and it had some previous review
comments that led to the decisions in this patch, but I'd still like
to ask here, where I think I'm reaching the relevant parties:
On Wed, Jul 10, 2019 at 1:43 AM Jian-Hong Pan <jian-hong@endlessm.com> wrote:
...
> This patch allocates a new, data-sized skb first in RX ISR. After
> copying the data in, we pass it to the upper layers. However, if skb
> allocation fails, we effectively drop the frame. In both cases, the
> original, full size ring skb is reused.
>
> In addition, by fixing the kernel crash, the RX routine should now
> generally behave better under low memory conditions.
>
> Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=204053
> Signed-off-by: Jian-Hong Pan <jian-hong@endlessm.com>
> Cc: <stable@vger.kernel.org>
> ---
> v2:
> - Allocate new data-sized skb and put data into it, then pass it to
> mac80211. Reuse the original skb in RX ring by DMA sync.
Is it really wise to force an extra memcpy() for *every* delivery?
Isn't there some other strategy that could be used to properly handle
low-memory scenarios while still passing the original buffer up to
higher layers most of the time? Or is it really so bad to keep
re-allocating RTK_PCI_RX_BUF_SIZE (>8KB) of contiguous memory, to
re-fill the RX ring? And if that is so bad, can we reduce the
requirement for contiguous memory instead? (e.g., keep with smaller
buffers, and perform aggregation / scatter-gather only for frames that
are really larger?)
Anyway, that's mostly a long-term thought, as this patch is good for
fixing the important memory errors, even if it's not necessarily the
ideal solution.
Regards,
Brian
^ permalink raw reply
* [PATCH v2] wimax/i2400m: fix a memory leak bug
From: Wenwen Wang @ 2019-08-15 20:29 UTC (permalink / raw)
To: Wenwen Wang
Cc: Inaky Perez-Gonzalez,
supporter:INTEL WIRELESS WIMAX CONNECTION 2400, David S. Miller,
open list:NETWORKING DRIVERS, open list
In i2400m_barker_db_init(), 'options_orig' is allocated through kstrdup()
to hold the original command line options. Then, the options are parsed.
However, if an error occurs during the parsing process, 'options_orig' is
not deallocated, leading to a memory leak bug. To fix this issue, free
'options_orig' before returning the error.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/wimax/i2400m/fw.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wimax/i2400m/fw.c b/drivers/net/wimax/i2400m/fw.c
index e9fc168..489cba9 100644
--- a/drivers/net/wimax/i2400m/fw.c
+++ b/drivers/net/wimax/i2400m/fw.c
@@ -351,13 +351,15 @@ int i2400m_barker_db_init(const char *_options)
}
result = i2400m_barker_db_add(barker);
if (result < 0)
- goto error_add;
+ goto error_parse_add;
}
kfree(options_orig);
}
return 0;
+error_parse_add:
error_parse:
+ kfree(options_orig);
error_add:
kfree(i2400m_barker_db);
return result;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] net: pch_gbe: Fix memory leaks
From: David Miller @ 2019-08-15 20:42 UTC (permalink / raw)
To: wenwen
Cc: rfontana, allison, alexios.zavras, gregkh, tglx, netdev,
linux-kernel
In-Reply-To: <CAAa=b7ft-crBJm+H9U7Bn2dcgfjQsE8o53p2ryBWK3seQoF3Cg@mail.gmail.com>
From: Wenwen Wang <wenwen@cs.uga.edu>
Date: Thu, 15 Aug 2019 16:03:39 -0400
> On Thu, Aug 15, 2019 at 3:34 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Wenwen Wang <wenwen@cs.uga.edu>
>> Date: Tue, 13 Aug 2019 20:33:45 -0500
>>
>> > In pch_gbe_set_ringparam(), if netif_running() returns false, 'tx_old' and
>> > 'rx_old' are not deallocated, leading to memory leaks. To fix this issue,
>> > move the free statements after the if branch.
>> >
>> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
>>
>> Why would they be "deallocated"? They are still assigned to
>> adapter->tx_ring and adapter->rx_ring.
>
> 'adapter->tx_ring' and 'adapter->rx_ring' has been covered by newly
> allocated 'txdr' and 'rxdr' respectively before this if statement.
That only happens inside of the if() statement, that's why rx_old and
tx_old are only freed in that code path.
^ permalink raw reply
* Re: [PATCH] net: pch_gbe: Fix memory leaks
From: Wenwen Wang @ 2019-08-15 20:46 UTC (permalink / raw)
To: David Miller
Cc: Richard Fontana, Allison Randal, Alexios Zavras,
Greg Kroah-Hartman, Thomas Gleixner,
open list:NETWORKING [GENERAL], open list, Wenwen Wang
In-Reply-To: <20190815.134230.1028411309377288636.davem@davemloft.net>
On Thu, Aug 15, 2019 at 4:42 PM David Miller <davem@davemloft.net> wrote:
>
> From: Wenwen Wang <wenwen@cs.uga.edu>
> Date: Thu, 15 Aug 2019 16:03:39 -0400
>
> > On Thu, Aug 15, 2019 at 3:34 PM David Miller <davem@davemloft.net> wrote:
> >>
> >> From: Wenwen Wang <wenwen@cs.uga.edu>
> >> Date: Tue, 13 Aug 2019 20:33:45 -0500
> >>
> >> > In pch_gbe_set_ringparam(), if netif_running() returns false, 'tx_old' and
> >> > 'rx_old' are not deallocated, leading to memory leaks. To fix this issue,
> >> > move the free statements after the if branch.
> >> >
> >> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
> >>
> >> Why would they be "deallocated"? They are still assigned to
> >> adapter->tx_ring and adapter->rx_ring.
> >
> > 'adapter->tx_ring' and 'adapter->rx_ring' has been covered by newly
> > allocated 'txdr' and 'rxdr' respectively before this if statement.
>
> That only happens inside of the if() statement, that's why rx_old and
> tx_old are only freed in that code path.
That happens not only inside of the if statement, but also before the
if statement, just after 'txdr' and 'rxdr' are allocated.
Wenwen
^ permalink raw reply
* Re: [PATCH] net: pch_gbe: Fix memory leaks
From: David Miller @ 2019-08-15 20:51 UTC (permalink / raw)
To: wenwen
Cc: rfontana, allison, alexios.zavras, gregkh, tglx, netdev,
linux-kernel
In-Reply-To: <CAAa=b7duRXsiVBfzbvHhoU000gGh53Mme3ZKCO5SoiTdgRaXtg@mail.gmail.com>
From: Wenwen Wang <wenwen@cs.uga.edu>
Date: Thu, 15 Aug 2019 16:46:05 -0400
> On Thu, Aug 15, 2019 at 4:42 PM David Miller <davem@davemloft.net> wrote:
>>
>> From: Wenwen Wang <wenwen@cs.uga.edu>
>> Date: Thu, 15 Aug 2019 16:03:39 -0400
>>
>> > On Thu, Aug 15, 2019 at 3:34 PM David Miller <davem@davemloft.net> wrote:
>> >>
>> >> From: Wenwen Wang <wenwen@cs.uga.edu>
>> >> Date: Tue, 13 Aug 2019 20:33:45 -0500
>> >>
>> >> > In pch_gbe_set_ringparam(), if netif_running() returns false, 'tx_old' and
>> >> > 'rx_old' are not deallocated, leading to memory leaks. To fix this issue,
>> >> > move the free statements after the if branch.
>> >> >
>> >> > Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
>> >>
>> >> Why would they be "deallocated"? They are still assigned to
>> >> adapter->tx_ring and adapter->rx_ring.
>> >
>> > 'adapter->tx_ring' and 'adapter->rx_ring' has been covered by newly
>> > allocated 'txdr' and 'rxdr' respectively before this if statement.
>>
>> That only happens inside of the if() statement, that's why rx_old and
>> tx_old are only freed in that code path.
>
> That happens not only inside of the if statement, but also before the
> if statement, just after 'txdr' and 'rxdr' are allocated.
Then the assignments inside of the if() statement are redundant.
Something doesn't add up here, please make the code consistent.
^ permalink raw reply
* [PATCH bpf 1/1] xdp: unpin xdp umem pages in error path
From: Ivan Khoronzhuk @ 2019-08-15 20:56 UTC (permalink / raw)
To: bjorn.topel
Cc: magnus.karlsson, jonathan.lemon, davem, ast, daniel,
jakub.kicinski, hawk, john.fastabend, netdev, bpf, linux-kernel,
Ivan Khoronzhuk
Fix mem leak caused by missed unpin routine for umem pages.
Fixes: 8aef7340ae9695 ("commit xsk: introduce xdp_umem_page")
Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
---
Based on bpf/master
net/xdp/xdp_umem.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/xdp/xdp_umem.c b/net/xdp/xdp_umem.c
index 83de74ca729a..688aac7a6943 100644
--- a/net/xdp/xdp_umem.c
+++ b/net/xdp/xdp_umem.c
@@ -365,7 +365,7 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
umem->pages = kcalloc(umem->npgs, sizeof(*umem->pages), GFP_KERNEL);
if (!umem->pages) {
err = -ENOMEM;
- goto out_account;
+ goto out_pin;
}
for (i = 0; i < umem->npgs; i++)
@@ -373,6 +373,8 @@ static int xdp_umem_reg(struct xdp_umem *umem, struct xdp_umem_reg *mr)
return 0;
+out_pin:
+ xdp_umem_unpin_pages(umem);
out_account:
xdp_umem_unaccount_pages(umem);
return err;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next] r8152: divide the tx and rx bottom functions
From: David Miller @ 2019-08-15 20:58 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel
In-Reply-To: <1394712342-15778-301-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 14 Aug 2019 16:30:17 +0800
> Move the tx bottom function from NAPI to a new tasklet. Then, for
> multi-cores, the bottom functions of tx and rx may be run at same
> time with different cores. This is used to improve performance.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Theoretically, yes.
But do you have actual performance numbers showing this to be worth
the change?
Always provide performance numbers with changes that are supposed to
improve performance.
^ permalink raw reply
* Re: [PATCH net] net/packet: fix race in tpacket_snd()
From: David Miller @ 2019-08-15 21:00 UTC (permalink / raw)
To: edumazet; +Cc: netdev, eric.dumazet, syzkaller
In-Reply-To: <20190814091157.215108-1-edumazet@google.com>
From: Eric Dumazet <edumazet@google.com>
Date: Wed, 14 Aug 2019 02:11:57 -0700
> packet_sendmsg() checks tx_ring.pg_vec to decide
> if it must call tpacket_snd().
>
> Problem is that the check is lockless, meaning another thread
> can issue a concurrent setsockopt(PACKET_TX_RING ) to flip
> tx_ring.pg_vec back to NULL.
>
> Given that tpacket_snd() grabs pg_vec_lock mutex, we can
> perform the check again to solve the race.
>
> syzbot reported :
...
> Fixes: 69e3c75f4d54 ("net: TX_RING and packet mmap")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: syzbot <syzkaller@googlegroups.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH bpf 1/1] xdp: unpin xdp umem pages in error path
From: Jonathan Lemon @ 2019-08-15 21:01 UTC (permalink / raw)
To: Ivan Khoronzhuk
Cc: bjorn.topel, magnus.karlsson, davem, ast, daniel, jakub.kicinski,
hawk, john.fastabend, netdev, bpf, linux-kernel
In-Reply-To: <20190815205635.6536-1-ivan.khoronzhuk@linaro.org>
On 15 Aug 2019, at 13:56, Ivan Khoronzhuk wrote:
> Fix mem leak caused by missed unpin routine for umem pages.
> Fixes: 8aef7340ae9695 ("commit xsk: introduce xdp_umem_page")
>
> Signed-off-by: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Acked-by: Jonathan Lemon <jonathan.lemon@gmail.com>
^ permalink raw reply
* Re: [PATCH 0/7] Netfilter fixes for net
From: David Miller @ 2019-08-15 21:02 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190814092440.20087-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 14 Aug 2019 11:24:33 +0200
> This patchset contains Netfilter fixes for net:
>
> 1) Extend selftest to cover flowtable with ipsec, from Florian Westphal.
>
> 2) Fix interaction of ipsec with flowtable, also from Florian.
>
> 3) User-after-free with bound set to rule that fails to load.
>
> 4) Adjust state and timeout for flows that expire.
>
> 5) Timeout update race with flows in teardown state.
>
> 6) Ensure conntrack id hash calculation use invariants as input,
> from Dirk Morris.
>
> 7) Do not push flows into flowtable for TCP fin/rst packets.
>
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, thanks.
^ permalink raw reply
* [PATCH] ath10k: add cleanup in ath10k_sta_state()
From: Wenwen Wang @ 2019-08-15 21:04 UTC (permalink / raw)
To: Wenwen Wang
Cc: Kalle Valo, David S. Miller,
open list:QUALCOMM ATHEROS ATH10K WIRELESS DRIVER,
open list:NETWORKING DRIVERS (WIRELESS),
open list:NETWORKING DRIVERS, open list
If 'sta->tdls' is false, no cleanup is executed, leading to memory/resource
leaks, e.g., 'arsta->tx_stats'. To fix this issue, perform cleanup before
go to the 'exit' label.
Signed-off-by: Wenwen Wang <wenwen@cs.uga.edu>
---
drivers/net/wireless/ath/ath10k/mac.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 0606416..f99e6d2 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6548,8 +6548,12 @@ static int ath10k_sta_state(struct ieee80211_hw *hw,
spin_unlock_bh(&ar->data_lock);
- if (!sta->tdls)
+ if (!sta->tdls) {
+ ath10k_peer_delete(ar, arvif->vdev_id, sta->addr);
+ ath10k_mac_dec_num_stations(arvif, sta);
+ kfree(arsta->tx_stats);
goto exit;
+ }
ret = ath10k_wmi_update_fw_tdls_state(ar, arvif->vdev_id,
WMI_TDLS_ENABLE_ACTIVE);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net-next 1/3] net/tls: use RCU protection on icsk->icsk_ulp_data
From: Jakub Kicinski @ 2019-08-15 21:32 UTC (permalink / raw)
To: Davide Caratti
Cc: Boris Pismenny, John Fastabend, Dave Watson, Aviad Yehezkel,
David S. Miller, netdev
In-Reply-To: <b7c351a5ad6c756129d036fd87db6b4edcd3cb6a.1565882584.git.dcaratti@redhat.com>
On Thu, 15 Aug 2019 18:00:42 +0200, Davide Caratti wrote:
> From: Jakub Kicinski <jakub.kicinski@netronome.com>
>
> We need to make sure context does not get freed while diag
> code is interrogating it. Free struct tls_context with
> kfree_rcu().
>
> We add the __rcu annotation directly in icsk, and cast it
> away in the datapath accessor. Presumably all ULPs will
> do a similar thing.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> ---
> include/net/inet_connection_sock.h | 2 +-
> include/net/tls.h | 9 +++++++--
> net/core/sock_map.c | 2 +-
> net/tls/tls_device.c | 2 +-
> net/tls/tls_main.c | 31 +++++++++++++++++++++++-------
> 5 files changed, 34 insertions(+), 12 deletions(-)
>
> diff --git a/include/net/inet_connection_sock.h b/include/net/inet_connection_sock.h
> index c57d53e7e02c..895546058a20 100644
> --- a/include/net/inet_connection_sock.h
> +++ b/include/net/inet_connection_sock.h
> @@ -97,7 +97,7 @@ struct inet_connection_sock {
> const struct tcp_congestion_ops *icsk_ca_ops;
> const struct inet_connection_sock_af_ops *icsk_af_ops;
> const struct tcp_ulp_ops *icsk_ulp_ops;
> - void *icsk_ulp_data;
> + void __rcu *icsk_ulp_data;
> void (*icsk_clean_acked)(struct sock *sk, u32 acked_seq);
> struct hlist_node icsk_listen_portaddr_node;
> unsigned int (*icsk_sync_mss)(struct sock *sk, u32 pmtu);
> diff --git a/include/net/tls.h b/include/net/tls.h
> index 41b2d41bb1b8..4997742475cd 100644
> --- a/include/net/tls.h
> +++ b/include/net/tls.h
> @@ -41,6 +41,7 @@
> #include <linux/tcp.h>
> #include <linux/skmsg.h>
> #include <linux/netdevice.h>
> +#include <linux/rcupdate.h>
>
> #include <net/tcp.h>
> #include <net/strparser.h>
> @@ -290,6 +291,7 @@ struct tls_context {
>
> struct list_head list;
> refcount_t refcount;
> + struct rcu_head rcu;
> };
>
> enum tls_offload_ctx_dir {
> @@ -348,7 +350,7 @@ struct tls_offload_context_rx {
> #define TLS_OFFLOAD_CONTEXT_SIZE_RX \
> (sizeof(struct tls_offload_context_rx) + TLS_DRIVER_STATE_SIZE_RX)
>
> -void tls_ctx_free(struct tls_context *ctx);
> +void tls_ctx_free(struct sock *sk, struct tls_context *ctx);
> int wait_on_pending_writer(struct sock *sk, long *timeo);
> int tls_sk_query(struct sock *sk, int optname, char __user *optval,
> int __user *optlen);
> @@ -467,7 +469,10 @@ static inline struct tls_context *tls_get_ctx(const struct sock *sk)
> {
> struct inet_connection_sock *icsk = inet_csk(sk);
>
> - return icsk->icsk_ulp_data;
> + /* Use RCU on icsk_ulp_data only for sock diag code,
> + * TLS data path doesn't need rcu_dereference().
> + */
> + return (__force void *)icsk->icsk_ulp_data;
> }
>
> static inline void tls_advance_record_sn(struct sock *sk,
> diff --git a/net/core/sock_map.c b/net/core/sock_map.c
> index 1330a7442e5b..01998860afaa 100644
> --- a/net/core/sock_map.c
> +++ b/net/core/sock_map.c
> @@ -345,7 +345,7 @@ static int sock_map_update_common(struct bpf_map *map, u32 idx,
> return -EINVAL;
> if (unlikely(idx >= map->max_entries))
> return -E2BIG;
> - if (unlikely(icsk->icsk_ulp_data))
> + if (unlikely(rcu_access_pointer(icsk->icsk_ulp_data)))
> return -EINVAL;
>
> link = sk_psock_init_link();
> diff --git a/net/tls/tls_device.c b/net/tls/tls_device.c
> index d184230665eb..436df5b4bb60 100644
> --- a/net/tls/tls_device.c
> +++ b/net/tls/tls_device.c
> @@ -61,7 +61,7 @@ static void tls_device_free_ctx(struct tls_context *ctx)
> if (ctx->rx_conf == TLS_HW)
> kfree(tls_offload_ctx_rx(ctx));
>
> - tls_ctx_free(ctx);
> + tls_ctx_free(NULL, ctx);
> }
>
> static void tls_device_gc_task(struct work_struct *work)
> diff --git a/net/tls/tls_main.c b/net/tls/tls_main.c
> index 9cbbae606ced..04829bef514c 100644
> --- a/net/tls/tls_main.c
> +++ b/net/tls/tls_main.c
> @@ -251,14 +251,31 @@ static void tls_write_space(struct sock *sk)
> ctx->sk_write_space(sk);
> }
>
> -void tls_ctx_free(struct tls_context *ctx)
> +/**
> + * tls_ctx_free() - free TLS ULP context
> + * @sk: socket to with @ctx is attached
> + * @ctx: TLS context structure
> + *
> + * Free TLS context. If @sk is %NULL caller guarantees that the socket
> + * to which @ctx was attached has no outstanding references.
> + */
> +void tls_ctx_free(struct sock *sk, struct tls_context *ctx)
> {
> + struct inet_connection_sock *icsk;
> +
> if (!ctx)
> return;
>
> memzero_explicit(&ctx->crypto_send, sizeof(ctx->crypto_send));
> memzero_explicit(&ctx->crypto_recv, sizeof(ctx->crypto_recv));
> - kfree(ctx);
> +
> + if (sk) {
> + icsk = inet_csk(sk);
> + rcu_assign_pointer(icsk->icsk_ulp_data, NULL);
Now that we kind of want to set the icsk_ulp_data to NULL under the
callback_lock I think we should let the callers do it.
> + kfree_rcu(ctx, rcu);
> + } else {
> + kfree(ctx);
> + }
> }
>
> static void tls_sk_proto_cleanup(struct sock *sk,
> @@ -306,7 +323,7 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
>
> write_lock_bh(&sk->sk_callback_lock);
> if (free_ctx)
> - icsk->icsk_ulp_data = NULL;
> + rcu_assign_pointer(icsk->icsk_ulp_data, NULL);
> sk->sk_prot = ctx->sk_proto;
> write_unlock_bh(&sk->sk_callback_lock);
> release_sock(sk);
> @@ -319,7 +336,7 @@ static void tls_sk_proto_close(struct sock *sk, long timeout)
> ctx->sk_proto_close(sk, timeout);
>
> if (free_ctx)
> - tls_ctx_free(ctx);
> + tls_ctx_free(sk, ctx);
> }
>
> static int do_tls_getsockopt_tx(struct sock *sk, char __user *optval,
> @@ -608,7 +625,7 @@ static struct tls_context *create_ctx(struct sock *sk)
> if (!ctx)
> return NULL;
>
> - icsk->icsk_ulp_data = ctx;
> + rcu_assign_pointer(icsk->icsk_ulp_data, ctx);
> ctx->setsockopt = sk->sk_prot->setsockopt;
> ctx->getsockopt = sk->sk_prot->getsockopt;
> ctx->sk_proto_close = sk->sk_prot->close;
> @@ -649,8 +666,8 @@ static void tls_hw_sk_destruct(struct sock *sk)
>
> ctx->sk_destruct(sk);
> /* Free ctx */
> - tls_ctx_free(ctx);
> - icsk->icsk_ulp_data = NULL;
> + tls_ctx_free(sk, ctx);
> + rcu_assign_pointer(icsk->icsk_ulp_data, NULL);
Let's reorder the assignment before the free.
> }
>
> static int tls_hw_prot(struct sock *sk)
^ permalink raw reply
* Re: [PATCH net-next 2/3] tcp: ulp: add functions to dump ulp-specific information
From: Jakub Kicinski @ 2019-08-15 21:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Davide Caratti, Boris Pismenny, John Fastabend, Dave Watson,
Aviad Yehezkel, David S. Miller, netdev
In-Reply-To: <228db5cc-9b10-521f-9031-e0f86f5ded3e@gmail.com>
On Thu, 15 Aug 2019 20:46:01 +0200, Eric Dumazet wrote:
> On 8/15/19 6:00 PM, Davide Caratti wrote:
>
> >
> > + if (net_admin) {
> > + const struct tcp_ulp_ops *ulp_ops;
> > +
> > + rcu_read_lock();
> > + ulp_ops = icsk->icsk_ulp_ops;
> > + if (ulp_ops)
> > + err = tcp_diag_put_ulp(skb, sk, ulp_ops);
> > + rcu_read_unlock();
> > + if (err)
> > + return err;
> > + }
> > return 0;
>
>
> Why is rcu_read_lock() and rcu_read_unlock() used at all ?
>
> icsk->icsk_ulp_ops does not seem to be rcu protected ?
>
> If this was, then an rcu_dereference() would be appropriate.
Indeed it's ulp_data not ulp_ops that are protected. Davide,
perhaps we could push the RCU lock into tls_get_info(), after all?
And tls_context has to use rcu_deference there, as Eric points out,
plus we should probably NULL-check it.
^ permalink raw reply
* linux-next: Fixes tags need some work in the net-next tree
From: Stephen Rothwell @ 2019-08-15 21:51 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
Srinivas Neeli, Marc Kleine-Budde, Appana Durga Kedareswara rao,
Michal Simek, Venkatesh Yadav Abbarapu
[-- Attachment #1: Type: text/plain, Size: 2073 bytes --]
Hi all,
In commit
3e994ff28f86 ("can: xilinx_can: xcan_set_bittiming(): fix the data phase btr1 calculation")
Fixes tag
Fixes: c223da6 ("can: xilinx_can: Add support for CANFD FD frames")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
In commit
9d06bcb9aa48 ("can: xilinx_can: xcan_rx_fifo_get_next_frame(): fix FSR register FL and RI mask values for canfd 2.0")
Fixes tag
Fixes: c223da6 ("can: xilinx_can: Add support for CANFD FD frames")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
In commit
e6997dd26884 ("can: xilinx_can: fix the data update logic for CANFD FD frames")
Fixes tag
Fixes: c223da6 ("can: xilinx_can: Add support for CANFD FD frames")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
In commit
93bbd6c5eeb1 ("can: xilinx_can: xcanfd_rx(): fix FSR register handling in the RX path")
Fixes tag
Fixes: c223da6 ("can: xilinx_can: Add support for CANFD FD frames")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
In commit
6b0d35891c83 ("can: xilinx_can: xcan_probe(): skip error message on deferred probe")
Fixes tag
Fixes: b1201e44 ("can: xilinx CAN controller support")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for git v2.11
or later) just making sure it is not set (or set to "auto").
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: memory leak in nr_loopback_queue
From: syzbot @ 2019-08-15 21:53 UTC (permalink / raw)
To: davem, linux-hams, linux-kernel, netdev, ralf, syzkaller-bugs
In-Reply-To: <000000000000a7f012058a0c7a65@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 41de5963 Merge tag 'Wimplicit-fallthrough-5.3-rc5' of git:..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12408f1c600000
kernel config: https://syzkaller.appspot.com/x/.config?x=6c5e70dcab57c6af
dashboard link: https://syzkaller.appspot.com/bug?extid=470d1a4a7b7a7c225881
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=164de5ee600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1114f222600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+470d1a4a7b7a7c225881@syzkaller.appspotmail.com
executing program
executing program
executing program
executing program
executing program
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 50.960s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 50.960s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.030s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.030s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.100s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.100s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.160s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.160s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.240s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.240s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.300s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.300s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.370s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.370s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff888116c16b00 (size 224):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.430s)
hex dump (first 32 bytes):
d0 38 61 0c 81 88 ff ff d0 38 61 0c 81 88 ff ff .8a......8a.....
00 00 00 00 00 00 00 00 00 98 95 0b 81 88 ff ff ................
backtrace:
[<00000000e2ee4d2c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000e2ee4d2c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000e2ee4d2c>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000e2ee4d2c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<0000000082f0e53e>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810de28200 (size 512):
comm "syz-executor241", pid 7513, jiffies 4295078074 (age 51.430s)
hex dump (first 32 bytes):
bb bb bb 00 00 00 60 bb bb bb 01 00 00 61 10 01 ......`......a..
9c 00 00 01 04 bb bb bb 00 00 00 60 bb bb bb 00 ...........`....
backtrace:
[<000000006183266a>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006183266a>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006183266a>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000006183266a>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<00000000425795e2>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<00000000425795e2>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<00000000e438b171>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<000000005727e112>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000b73f5aed>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000b73f5aed>] nr_loopback_queue+0x26/0xc0
net/netrom/nr_loopback.c:34
[<00000000e8738211>] nr_route_frame+0x2d1/0x340
net/netrom/nr_route.c:772
[<00000000f3c3ea99>] nr_transmit_buffer+0x86/0xc0
net/netrom/nr_out.c:209
[<00000000aa3080e2>] nr_write_internal+0x133/0x2e0
net/netrom/nr_subr.c:205
[<00000000d4e53049>] nr_establish_data_link+0x2d/0x60
net/netrom/nr_out.c:227
[<000000008eb58c4a>] nr_connect+0x13b/0x490 net/netrom/af_netrom.c:713
[<00000000d6b40196>] __sys_connect+0x11d/0x170 net/socket.c:1828
[<0000000059057e91>] __do_sys_connect net/socket.c:1839 [inline]
[<0000000059057e91>] __se_sys_connect net/socket.c:1836 [inline]
[<0000000059057e91>] __x64_sys_connect+0x1e/0x30 net/socket.c:1836
[<0000000068560e8c>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<000000009035e9ed>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
^ permalink raw reply
* linux-next: Signed-off-by missing for commits in the net-next tree
From: Stephen Rothwell @ 2019-08-15 21:53 UTC (permalink / raw)
To: David Miller, Networking
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Andy Grover,
Gerd Rausch, Chris Mason
[-- Attachment #1: Type: text/plain, Size: 253 bytes --]
Hi all,
Commits
11740ef44829 ("rds: check for excessive looping in rds_send_xmit")
65dedd7fe1f2 ("RDS: limit the number of times we loop in rds_send_xmit")
are missing a Signed-off-by from their authors.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: linux-next: Signed-off-by missing for commits in the net-next tree
From: Gerd Rausch @ 2019-08-15 22:06 UTC (permalink / raw)
To: Stephen Rothwell, David Miller, Networking, Chris Mason, andy
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Andy Grover,
Chris Mason
In-Reply-To: <20190816075312.64959223@canb.auug.org.au>
Hi,
Just added the e-mail addresses I found using a simple "google search",
in order to reach out to the original authors of these commits:
Chris Mason and Andy Grover.
I'm hoping they still remember their work from 7-8 years ago.
Thanks,
Gerd
On 15/08/2019 14.53, Stephen Rothwell wrote:
> Hi all,
>
> Commits
>
> 11740ef44829 ("rds: check for excessive looping in rds_send_xmit")
> 65dedd7fe1f2 ("RDS: limit the number of times we loop in rds_send_xmit")
>
> are missing a Signed-off-by from their authors.
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox