* [PATCH V3 02/15] vhost: remove the unnecessary parameter of vhost_vq_avail_empty()
From: Jason Wang @ 2019-07-17 10:52 UTC (permalink / raw)
To: mst, jasowang
Cc: kvm, virtualization, netdev, linux-kernel, jfreimann, tiwei.bie,
maxime.coquelin
In-Reply-To: <20190717105255.63488-1-jasowang@redhat.com>
Its dev parameter is not even used, so remove it.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
drivers/vhost/net.c | 8 ++++----
drivers/vhost/vhost.c | 2 +-
drivers/vhost/vhost.h | 2 +-
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 3beb401235c0..7d34e8cbc89b 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -498,7 +498,7 @@ static int sock_has_rx_data(struct socket *sock)
static void vhost_net_busy_poll_try_queue(struct vhost_net *net,
struct vhost_virtqueue *vq)
{
- if (!vhost_vq_avail_empty(&net->dev, vq)) {
+ if (!vhost_vq_avail_empty(vq)) {
vhost_poll_queue(&vq->poll);
} else if (unlikely(vhost_enable_notify(&net->dev, vq))) {
vhost_disable_notify(&net->dev, vq);
@@ -540,8 +540,8 @@ static void vhost_net_busy_poll(struct vhost_net *net,
}
if ((sock_has_rx_data(sock) &&
- !vhost_vq_avail_empty(&net->dev, rvq)) ||
- !vhost_vq_avail_empty(&net->dev, tvq))
+ !vhost_vq_avail_empty(rvq)) ||
+ !vhost_vq_avail_empty(tvq))
break;
cpu_relax();
@@ -638,7 +638,7 @@ static int get_tx_bufs(struct vhost_net *net,
static bool tx_can_batch(struct vhost_virtqueue *vq, size_t total_len)
{
return total_len < VHOST_NET_WEIGHT &&
- !vhost_vq_avail_empty(vq->dev, vq);
+ !vhost_vq_avail_empty(vq);
}
#define SKB_FRAG_PAGE_ORDER get_order(32768)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 7f51c74d9aee..ec3534bcd51b 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2946,7 +2946,7 @@ void vhost_add_used_and_signal_n(struct vhost_dev *dev,
EXPORT_SYMBOL_GPL(vhost_add_used_and_signal_n);
/* return true if we're sure that avaiable ring is empty */
-bool vhost_vq_avail_empty(struct vhost_dev *dev, struct vhost_virtqueue *vq)
+bool vhost_vq_avail_empty(struct vhost_virtqueue *vq)
{
__virtio16 avail_idx;
int r;
diff --git a/drivers/vhost/vhost.h b/drivers/vhost/vhost.h
index 819296332913..e0451c900177 100644
--- a/drivers/vhost/vhost.h
+++ b/drivers/vhost/vhost.h
@@ -247,7 +247,7 @@ void vhost_add_used_and_signal_n(struct vhost_dev *, struct vhost_virtqueue *,
struct vring_used_elem *heads, unsigned count);
void vhost_signal(struct vhost_dev *, struct vhost_virtqueue *);
void vhost_disable_notify(struct vhost_dev *, struct vhost_virtqueue *);
-bool vhost_vq_avail_empty(struct vhost_dev *, struct vhost_virtqueue *);
+bool vhost_vq_avail_empty(struct vhost_virtqueue *vq);
bool vhost_enable_notify(struct vhost_dev *, struct vhost_virtqueue *);
int vhost_log_write(struct vhost_virtqueue *vq, struct vhost_log *log,
--
2.18.1
^ permalink raw reply related
* [PATCH V3 00/15] Packed virtqueue support for vhost
From: Jason Wang @ 2019-07-17 10:52 UTC (permalink / raw)
To: mst, jasowang
Cc: kvm, virtualization, netdev, linux-kernel, jfreimann, tiwei.bie,
maxime.coquelin
Hi all:
This series implements packed virtqueues which were described
at [1]. In this version we try to address the performance regression
saw by V2. The root cause is packed virtqueue need more times of
userspace memory accesssing which turns out to be very
expensive. Thanks to the help of 7f466032dc9e ("vhost: access vq
metadata through kernel virtual address"), such overhead cold be
eliminated. So in this version, we can see about 2% improvement for
packed virtqueue on PPS.
More optimizations (e.g IN_ORDER) is on the road.
Please review.
[1] https://docs.oasis-open.org/virtio/virtio/v1.1/csprd01/virtio-v1.1-csprd01.html#x1-610007
This version were tested with:
- zercopy/datacopy
- mergeable buffer on/off
- TCP stream & virtio-user
Changes from V2:
- rebase on top of vhost metadata accelreation series
- introduce shadow used ring API
- new SET_VRING_BASE/GET_VRING_BASE that takes care about warp counter
and index for both avail and used
- various twaeaks
Changes from V1:
- drop uapi patch and use Tiwei's
- split the enablement of packed virtqueue into a separate patch
Changes from RFC V5:
- save unnecessary barriers during vhost_add_used_packed_n()
- more compact math for event idx
- fix failure of SET_VRING_BASE when avail_wrap_counter is true
- fix not copy avail_wrap_counter during GET_VRING_BASE
- introduce SET_VRING_USED_BASE/GET_VRING_USED_BASE for syncing
- last_used_idx
- rename used_wrap_counter to last_used_wrap_counter
- rebase to net-next
Changes from RFC V4:
- fix signalled_used index recording
- track avail index correctly
- various minor fixes
Changes from RFC V3:
- Fix math on event idx checking
- Sync last avail wrap counter through GET/SET_VRING_BASE
- remove desc_event prefix in the driver/device structure
Changes from RFC V2:
- do not use & in checking desc_event_flags
- off should be most significant bit
- remove the workaround of mergeable buffer for dpdk prototype
- id should be in the last descriptor in the chain
- keep _F_WRITE for write descriptor when adding used
- device flags updating should use ADDR_USED type
- return error on unexpected unavail descriptor in a chain
- return false in vhost_ve_avail_empty is descriptor is available
- track last seen avail_wrap_counter
- correctly examine available descriptor in get_indirect_packed()
- vhost_idx_diff should return u16 instead of bool
Changes from RFC V1:
- Refactor vhost used elem code to avoid open coding on used elem
- Event suppression support (compile test only).
- Indirect descriptor support (compile test only).
- Zerocopy support.
- vIOMMU support.
- SCSI/VSOCK support (compile test only).
- Fix several bugs
Jason Wang (15):
vhost: simplify meta data pointer accessing
vhost: remove the unnecessary parameter of vhost_vq_avail_empty()
vhost: remove unnecessary parameter of
vhost_enable_notify()/vhost_disable_notify
vhost-net: don't use vhost_add_used_n() for zerocopy
vhost: introduce helpers to manipulate shadow used ring
vhost_net: switch TX to use shadow used ring API
vhost_net: calculate last used length once for mergeable buffer
vhost_net: switch to use shadow used ring API for RX
vhost: do not export vhost_add_used_n() and
vhost_add_used_and_signal_n()
vhost: hide used ring layout from device
vhost: do not use vring_used_elem
vhost: vhost_put_user() can accept metadata type
vhost: packed ring support
vhost: event suppression for packed ring
vhost: enable packed virtqueues
drivers/vhost/net.c | 200 +++---
drivers/vhost/scsi.c | 72 +-
drivers/vhost/test.c | 6 +-
drivers/vhost/vhost.c | 1508 +++++++++++++++++++++++++++++++++++------
drivers/vhost/vhost.h | 78 ++-
drivers/vhost/vsock.c | 57 +-
6 files changed, 1513 insertions(+), 408 deletions(-)
--
2.18.1
^ permalink raw reply
* Re: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
From: Firo Yang @ 2019-07-17 10:25 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Ajit Khaparde, Sathya Perla, Somnath Kotur, Sriharsha Basavapatna,
David Miller, Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <20190717093208.GA6511@f1>
Crystal clear. Many thanks.
// Firo
^ permalink raw reply
* Re: [PATCH bpf] bpf: fix narrower loads on s390
From: Ilya Leoshkevich @ 2019-07-17 10:36 UTC (permalink / raw)
To: Y Song; +Cc: bpf, netdev, gor, heiko.carstens
In-Reply-To: <98C6AA13-A44D-4FF1-BA73-1BD446BD773A@linux.ibm.com>
> Am 17.07.2019 um 11:21 schrieb Ilya Leoshkevich <iii@linux.ibm.com>:
>
>> Am 17.07.2019 um 07:11 schrieb Y Song <ys114321@gmail.com>:
>>
>> [sorry, resend again as previous one has come text messed out due to
>> networking issues]
>>
>> On Tue, Jul 16, 2019 at 10:08 PM Y Song <ys114321@gmail.com> wrote:
>>>
>>> On Tue, Jul 16, 2019 at 4:59 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>>>>
>>>> test_pkt_md_access is failing on s390, since the associated eBPF prog
>>>> returns TC_ACT_SHOT, which in turn happens because loading a part of a
>>>> struct __sk_buff field produces an incorrect result.
>>>>
>>>> The problem is that when verifier emits the code to replace partial load
>>>> of a field with a full load, a shift and a bitwise AND, it assumes that
>>>> the machine is little endian.
>>>>
>>>> Adjust shift count calculation to account for endianness.
>>>>
>>>> Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
>>>> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>>>> ---
>>>> kernel/bpf/verifier.c | 8 ++++++--
>>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>>> index 5900cbb966b1..3f9353653558 100644
>>>> --- a/kernel/bpf/verifier.c
>>>> +++ b/kernel/bpf/verifier.c
>>>> @@ -8616,8 +8616,12 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
>>>> }
>>>>
>>>> if (is_narrower_load && size < target_size) {
>>>> - u8 shift = (off & (size_default - 1)) * 8;
>>>> -
>>>> + u8 load_off = off & (size_default - 1);
>>>> +#ifdef __LITTLE_ENDIAN
>>>> + u8 shift = load_off * 8;
>>>> +#else
>>>> + u8 shift = (size_default - (load_off + size)) * 8;
>>>> +#endif
>>>
>> All the values are in register. The shifting operations should be the
>> same for big endian and little endian, e.g., value 64 >> 2 = 16 when
>> value "64" is in register. So I did not see a problem here.
>>
>> Could you elaborate which field access in test_pkt_md_access
>> caused problem?
>
> The very first one: TEST_FIELD(__u8, len, 0xFF);
>
>> It would be good if you can give detailed memory layout and register values
>> to illustrate the problem.
>
> Suppose len = 0x11223344. On a big endian system, this would be
>
> 11 22 33 44
>
> Now, we would like to do *(u8 *)&len, the desired result is 0x11.
> Verifier should emit the following: ((*(u32 *)&len) >> 24) & 0xff, but as
> of today it misses the shift.
>
> On a little endian system the layout is:
>
> 44 33 22 11
>
> and the desired result is different - 0x44. Verifier correctly emits
> (*(u32 *)&len) & 0xff.
I’ve just realized, that this example does not reflect what the test is
doing on big-endian systems (there is an #ifdef for those).
Here is a better one: len=0x11223344 and we would like to do
((u8 *)&len)[3].
len is represented as `11 22 33 44` in memory, so the desired result is
0x44. It can be obtained by doing (*(u32 *)&len) & 0xff, but today the
verifier does ((*(u32 *)&len) >> 24) & 0xff instead.
^ permalink raw reply
* [PATCH v2] net/mlx5: Replace kfree with kvfree
From: Chuhong Yuan @ 2019-07-17 10:14 UTC (permalink / raw)
Cc: Saeed Mahameed, Leon Romanovsky, David S . Miller, netdev,
linux-rdma, linux-kernel, Chuhong Yuan
Variable allocated by kvmalloc should not be freed by kfree.
Because it may be allocated by vmalloc.
So replace kfree with kvfree here.
Fixes: 9b1f298236057 ("net/mlx5: Add support for FW fatal reporter dump")
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
Changes in v2:
- Add corresponding Fixes tag
drivers/net/ethernet/mellanox/mlx5/core/health.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c b/drivers/net/ethernet/mellanox/mlx5/core/health.c
index 2fe6923f7ce0..9314777d99e3 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
@@ -597,7 +597,7 @@ mlx5_fw_fatal_reporter_dump(struct devlink_health_reporter *reporter,
err = devlink_fmsg_arr_pair_nest_end(fmsg);
free_data:
- kfree(cr_data);
+ kvfree(cr_data);
return err;
}
--
2.20.1
^ permalink raw reply related
* Re: KASAN: use-after-free Write in check_noncircular
From: Tetsuo Handa @ 2019-07-17 10:13 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, ast, daniel, john.fastabend, linux-kernel, netdev,
syzkaller-bugs
In-Reply-To: <0000000000001e443b058ddcb128@google.com>
This is not a TOMOYO's bug. But
On 2019/07/17 17:58, syzbot wrote:
> ==================================================================
> BUG: KASAN: use-after-free in check_noncircular+0x91/0x560 kernel/locking/lockdep.c:1722
> Write of size 56 at addr ffff888089815160 by task syz-executor.4/8772
>
> CPU: 1 PID: 8772 Comm: syz-executor.4 Not tainted 5.2.0+ #31
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> Call Trace:
>
what happened here? No trace was printed to console output?
> Allocated by task 8457:
^ permalink raw reply
* Re: WARNING: held lock freed in nr_release
From: syzbot @ 2019-07-17 10:05 UTC (permalink / raw)
To: davem, linux-hams, linux-kernel, netdev, ralf, syzkaller-bugs,
xiyou.wangcong
In-Reply-To: <00000000000015d943058ddcb1b3@google.com>
syzbot has bisected this bug to:
commit c8c8218ec5af5d2598381883acbefbf604e56b5e
Author: Cong Wang <xiyou.wangcong@gmail.com>
Date: Thu Jun 27 21:30:58 2019 +0000
netrom: fix a memory leak in nr_rx_frame()
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14022e8fa00000
start commit: a5b64700 fix: taprio: Change type of txtime-delay paramete..
git tree: net
final crash: https://syzkaller.appspot.com/x/report.txt?x=16022e8fa00000
console output: https://syzkaller.appspot.com/x/log.txt?x=12022e8fa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=87305c3ca9c25c70
dashboard link: https://syzkaller.appspot.com/bug?extid=a34e5f3d0300163f0c87
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1460b458600000
Reported-by: syzbot+a34e5f3d0300163f0c87@syzkaller.appspotmail.com
Fixes: c8c8218ec5af ("netrom: fix a memory leak in nr_rx_frame()")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.2 226/249] selftests: bpf: fix inlines in test_lwt_seg6local
From: Jiri Benc @ 2019-07-17 9:43 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-kernel, stable, Yonghong Song, Daniel Borkmann,
linux-kselftest, netdev, bpf, clang-built-linux
In-Reply-To: <20190715134655.4076-226-sashal@kernel.org>
On Mon, 15 Jul 2019 09:46:31 -0400, Sasha Levin wrote:
> From: Jiri Benc <jbenc@redhat.com>
>
> [ Upstream commit 11aca65ec4db09527d3e9b6b41a0615b7da4386b ]
>
> Selftests are reporting this failure in test_lwt_seg6local.sh:
I don't think this is critical in any way and I don't think this is a
stable material. How was this selected?
Jiri
^ permalink raw reply
* Re: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
From: Benjamin Poirier @ 2019-07-17 9:32 UTC (permalink / raw)
To: Firo Yang
Cc: Ajit Khaparde, Sathya Perla, Somnath Kotur, Sriharsha Basavapatna,
David Miller, Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <CH2PR18MB3189AD09E590F16443D8D5BA88C90@CH2PR18MB3189.namprd18.prod.outlook.com>
On 2019/07/17 17:56, Firo Yang wrote:
> I don't think this change could fix this problem because if SMP, dev_watchdog() could run on a different CPU.
hmm, SMP is clearly part of the picture here. The change I proposed
revolves around the synchronization offered by dev->tx_global_lock:
we have
\ dev_watchdog
\ netif_tx_lock
spin_lock(&dev->tx_global_lock);
...
\ netif_tx_unlock
and
\ be_update_queues
\ netif_tx_lock_bh
\ netif_tx_lock
spin_lock(&dev->tx_global_lock);
Makes sense?
^ permalink raw reply
* [PATCH] usb: qmi_wwan: add D-Link DWM-222 A2 device ID
From: Rogan Dawes @ 2019-07-17 9:14 UTC (permalink / raw)
To: Bjørn Mork; +Cc: David S. Miller, netdev, linux-usb
In-Reply-To: <20190717091134.GA5179@lisa.dawes.za.net>
Signed-off-by: Rogan Dawes <rogan@dawes.za.net>
---
drivers/net/usb/qmi_wwan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 8b4ad10cf940..69e0a2acfcb0 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -1292,6 +1292,7 @@ static const struct usb_device_id products[] = {
{QMI_FIXED_INTF(0x2001, 0x7e16, 3)}, /* D-Link DWM-221 */
{QMI_FIXED_INTF(0x2001, 0x7e19, 4)}, /* D-Link DWM-221 B1 */
{QMI_FIXED_INTF(0x2001, 0x7e35, 4)}, /* D-Link DWM-222 */
+ {QMI_FIXED_INTF(0x2001, 0x7e3d, 4)}, /* D-Link DWM-222 A2 */
{QMI_FIXED_INTF(0x2020, 0x2031, 4)}, /* Olicard 600 */
{QMI_FIXED_INTF(0x2020, 0x2033, 4)}, /* BroadMobi BM806U */
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)}, /* Sierra Wireless MC7700 */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH bpf] bpf: fix narrower loads on s390
From: Ilya Leoshkevich @ 2019-07-17 9:21 UTC (permalink / raw)
To: Y Song; +Cc: bpf, netdev, gor, heiko.carstens
In-Reply-To: <CAH3MdRU-u1Gn6uj2D=mzXvdC2RDWas3Ec0QXObKsLac1GwuREQ@mail.gmail.com>
> Am 17.07.2019 um 07:11 schrieb Y Song <ys114321@gmail.com>:
>
> [sorry, resend again as previous one has come text messed out due to
> networking issues]
>
> On Tue, Jul 16, 2019 at 10:08 PM Y Song <ys114321@gmail.com> wrote:
>>
>> On Tue, Jul 16, 2019 at 4:59 AM Ilya Leoshkevich <iii@linux.ibm.com> wrote:
>>>
>>> test_pkt_md_access is failing on s390, since the associated eBPF prog
>>> returns TC_ACT_SHOT, which in turn happens because loading a part of a
>>> struct __sk_buff field produces an incorrect result.
>>>
>>> The problem is that when verifier emits the code to replace partial load
>>> of a field with a full load, a shift and a bitwise AND, it assumes that
>>> the machine is little endian.
>>>
>>> Adjust shift count calculation to account for endianness.
>>>
>>> Fixes: 31fd85816dbe ("bpf: permits narrower load from bpf program context fields")
>>> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>>> ---
>>> kernel/bpf/verifier.c | 8 ++++++--
>>> 1 file changed, 6 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
>>> index 5900cbb966b1..3f9353653558 100644
>>> --- a/kernel/bpf/verifier.c
>>> +++ b/kernel/bpf/verifier.c
>>> @@ -8616,8 +8616,12 @@ static int convert_ctx_accesses(struct bpf_verifier_env *env)
>>> }
>>>
>>> if (is_narrower_load && size < target_size) {
>>> - u8 shift = (off & (size_default - 1)) * 8;
>>> -
>>> + u8 load_off = off & (size_default - 1);
>>> +#ifdef __LITTLE_ENDIAN
>>> + u8 shift = load_off * 8;
>>> +#else
>>> + u8 shift = (size_default - (load_off + size)) * 8;
>>> +#endif
>>
> All the values are in register. The shifting operations should be the
> same for big endian and little endian, e.g., value 64 >> 2 = 16 when
> value "64" is in register. So I did not see a problem here.
>
> Could you elaborate which field access in test_pkt_md_access
> caused problem?
The very first one: TEST_FIELD(__u8, len, 0xFF);
> It would be good if you can give detailed memory layout and register values
> to illustrate the problem.
Suppose len = 0x11223344. On a big endian system, this would be
11 22 33 44
Now, we would like to do *(u8 *)&len, the desired result is 0x11.
Verifier should emit the following: ((*(u32 *)&len) >> 24) & 0xff, but as
of today it misses the shift.
On a little endian system the layout is:
44 33 22 11
and the desired result is different - 0x44. Verifier correctly emits
(*(u32 *)&len) & 0xff.
>
>>
>>> if (ctx_field_size <= 4) {
>>> if (shift)
>>> insn_buf[cnt++] = BPF_ALU32_IMM(BPF_RSH,
>>> --
>>> 2.21.0
^ permalink raw reply
* Re: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
From: Firo Yang @ 2019-07-17 8:56 UTC (permalink / raw)
To: Benjamin Poirier
Cc: Ajit Khaparde, Sathya Perla, Somnath Kotur, Sriharsha Basavapatna,
David Miller, Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <20190717082340.GA6015@f1>
I don't think this change could fix this problem because if SMP, dev_watchdog() could run on a different CPU.
Thanks,
Firo
^ permalink raw reply
* Re: [PATCH bpf] selftests/bpf: make directory prerequisites order-only
From: Ilya Leoshkevich @ 2019-07-17 9:10 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Daniel Borkmann, bpf, Network Development, Vasily Gorbik,
Heiko Carstens, Andrii Nakryiko
In-Reply-To: <CAADnVQKzZQ_mbaMHEU6HA-JEy=1jXvBWULg8yKQY_2zwSmU86g@mail.gmail.com>
> Am 16.07.2019 um 19:49 schrieb Alexei Starovoitov <alexei.starovoitov@gmail.com>:
>
> On Mon, Jul 15, 2019 at 3:22 PM Daniel Borkmann <daniel@iogearbox.net> wrote:
>>
>> On 7/12/19 3:56 PM, Ilya Leoshkevich wrote:
>>> When directories are used as prerequisites in Makefiles, they can cause
>>> a lot of unnecessary rebuilds, because a directory is considered changed
>>> whenever a file in this directory is added, removed or modified.
>>>
>>> If the only thing a target is interested in is the existence of the
>>> directory it depends on, which is the case for selftests/bpf, this
>>> directory should be specified as an order-only prerequisite: it would
>>> still be created in case it does not exist, but it would not trigger a
>>> rebuild of a target in case it's considered changed.
>>>
>>> Signed-off-by: Ilya Leoshkevich <iii@linux.ibm.com>
>>
>> Applied, thanks!
>
> Hi Ilya,
>
> this commit breaks map_tests.
> To reproduce:
> rm map_tests/tests.h
> make
> tests.h will not be regenerated.
> Please provide a fix asap.
> We cannot ship bpf tree with such failure.
Hi Alexei,
Sorry about this! I actually had the following in my local tree:
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile
index f1f2b82b8fb8..95795cf5805c 100644
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@ -231,7 +231,7 @@ ifeq ($(DWARF2BTF),y)
endif
PROG_TESTS_H := $(OUTPUT)/prog_tests/tests.h
-test_progs.c: $(PROG_TESTS_H)
+$(OUTPUT)/test_progs: $(PROG_TESTS_H)
$(OUTPUT)/test_progs: CFLAGS += $(TEST_PROGS_CFLAGS)
$(OUTPUT)/test_progs: prog_tests/*.c
@@ -258,7 +258,7 @@ MAP_TESTS_DIR = $(OUTPUT)/map_tests
$(MAP_TESTS_DIR):
<------>mkdir -p $@
MAP_TESTS_H := $(MAP_TESTS_DIR)/tests.h
-test_maps.c: $(MAP_TESTS_H)
+$(OUTPUT)/test_maps: $(MAP_TESTS_H)
$(OUTPUT)/test_maps: CFLAGS += $(TEST_MAPS_CFLAGS)
MAP_TESTS_FILES := $(wildcard map_tests/*.c)
$(MAP_TESTS_H): $(MAP_TESTS_FILES) | $(MAP_TESTS_DIR)
@@ -275,7 +275,7 @@ $(MAP_TESTS_H): $(MAP_TESTS_FILES) | $(MAP_TESTS_DIR)
<------><------> ) > $(MAP_TESTS_H))
VERIFIER_TESTS_H := $(OUTPUT)/verifier/tests.h
-test_verifier.c: $(VERIFIER_TESTS_H)
+$(OUTPUT)/test_verifier: $(VERIFIER_TESTS_H)
$(OUTPUT)/test_verifier: CFLAGS += $(TEST_VERIFIER_CFLAGS)
VERIFIER_TESTS_DIR = $(OUTPUT)/verifier
but did not realise that this is a pre-requisite for my directories change.
I should have tested it separately, then I would have noticed.
Andrii,
Thanks for helping out and providing the fix!
Best regards,
Ilya
^ permalink raw reply related
* Re: OOM triggered by SCTP
From: Marek Majkowski @ 2019-07-17 9:08 UTC (permalink / raw)
To: malc; +Cc: vyasevich, nhorman, marcelo.leitner, Linux SCTP, netdev,
kernel-team
In-Reply-To: <CAPkQJpRJadEqxOcdb_U5Tz6NPE3h3FzootQt3r2GgPP0aYsVvA@mail.gmail.com>
Malc, thanks taking a look.
I'm able to trigger the problem on non-SMP virtme with 4GiB ram, but
I'm not able to trigger it on my SMP host with 16GiB.
The slab info from dmesg (on 4GiB run):
Unreclaimable slab info:
SCTPv6 31068KB 31068KB
sctp_chunk 24321KB 24990KB
sctp_bind_bucket 972KB 972KB
skbuff_head_cache 28484KB 29051KB
kmalloc-8k 82KB 148KB
kmalloc-4k 81897KB 82943KB
kmalloc-2k 314KB 382KB
kmalloc-1k 27446KB 29547KB
kmalloc-512 30312KB 30915KB
The biggest issue is that the OOM is often unrecoverable:
---[ end Kernel panic - not syncing: System is deadlocked on memory ]---
Out of memory and no killable processes...
Kernel panic - not syncing: System is deadlocked on memory
I noticed sctp_mem toggle. Would tweaking it change anything?
net.sctp.sctp_mem = 80976 107969 161952
net.sctp.sctp_rmem = 4096 865500 3455008
net.sctp.sctp_wmem = 4096 16384 3455008
For the record, stuffing "shutdown(sd, SHUT_RDWR)" before the "close"
doesn't solve the problem.
Marek
On Wed, Jul 17, 2019 at 1:59 AM malc <mlashley@gmail.com> wrote:
>
> On Tue, Jul 16, 2019 at 10:49 PM Marek Majkowski <marek@cloudflare.com> wrote:
> >
> > Morning,
> >
> > My poor man's fuzzer found something interesting in SCTP. It seems
> > like creating large number of SCTP sockets + some magic dance, upsets
> > a memory subsystem related to SCTP. The sequence:
> >
> > - create SCTP socket
> > - call setsockopts (SCTP_EVENTS)
> > - call bind(::1, port)
> > - call sendmsg(long buffer, MSG_CONFIRM, ::1, port)
> > - close SCTP socket
> > - repeat couple thousand times
> >
> > Full code:
> > https://gist.github.com/majek/bd083dae769804d39134ce01f4f802bb#file-test_sctp-c
> >
> > I'm running it on virtme the simplest way:
> > $ virtme-run --show-boot-console --rw --pwd --kimg bzImage --memory
> > 512M --script-sh ./test_sctp
> >
> > Originally I was running it inside net namespace, and just having a
> > localhost interface is sufficient to trigger the problem.
> >
> > Kernel is 5.2.1 (with KASAN and such, but that shouldn't be a factor).
> > In some tests I saw a message that might indicate something funny
> > hitting neighbor table:
> >
> > neighbour: ndisc_cache: neighbor table overflow!
> >
> > I'm not addr-decoding the stack trace, since it seems unrelated to the
> > root cause.
> >
> > Cheers,
> > Marek
>
> I _think_ this is an 'expected' peculiarity of SCTP on loopback - you
> test_sctp.c ends up creating actual associations to itself on the same
> socket (you can test safely by reducing the port range (say
> 30000-32000) and setting the for-loop-clause to 'run < 1')
> You'll see a bunch of associations established like the following
> (note that I(kernel) was dropping packets for this capture - even with
> /only/ 2000 sockets used...)
>
> $ tshark -r sctp.pcap -Y 'sctp.assoc_index==4'
> 21 0.000409127 ::1 → ::1 SCTP INIT
> 22 0.000436281 ::1 → ::1 SCTP INIT_ACK
> 23 0.000442106 ::1 → ::1 SCTP COOKIE_ECHO
> 24 0.000463007 ::1 → ::1 SCTP COOKIE_ACK DATA
> (Message Fragment)
> presumably your close()
> happens here and we enter SHUTDOWN-PENDING, where we wait for pending
> data to be acknowledged, I'm not convinced that we shouldn't be
> SACK'ing the data from the 'peer' at this point - but for whatever
> reason, we aren't.
> We then run thru
> path-max-retrans, and finally ABORT (the abort indication also shows
> the PMR-exceeded indication in the 'Cause Information')
> 25 0.000476083 ::1 → ::1 SCTP SACK
> 13619 3.017788109 ::1 → ::1 SCTP DATA (retransmission)
> 14022 3.222690889 ::1 → ::1 SCTP SACK
> 18922 21.938217449 ::1 → ::1 SCTP SACK
> 33476 69.831029904 ::1 → ::1 SCTP HEARTBEAT
> 33561 69.831310796 ::1 → ::1 SCTP HEARTBEAT_ACK
> 40816 94.102667600 ::1 → ::1 SCTP SACK
> 40910 95.942741287 ::1 → ::1 SCTP DATA (retransmission)
> 41039 96.152023010 ::1 → ::1 SCTP SACK
> 41100 100.182685237 ::1 → ::1 SCTP SACK
> 41212 108.230746764 ::1 → ::1 SCTP DATA (retransmission)
> 41345 108.439061392 ::1 → ::1 SCTP SACK
> 41407 116.422688507 ::1 → ::1 SCTP HEARTBEAT
> 41413 116.423183124 ::1 → ::1 SCTP HEARTBEAT_ACK
> 41494 124.823749255 ::1 → ::1 SCTP SACK
> 41576 126.663648718 ::1 → ::1 SCTP ABORT
>
> With your entire 512M - you'd only have about 16KB for each of these
> 31K associations tops, I suspect that having a 64KB pending data chunk
> (fragmented ULP msg) for each association for >= 90s is what is
> exhausting memory here - although I'm sure Neil or Michael will be
> along to correct me ;-)
>
> What's interesting - as you reduce the payload size - we end up
> bundling DATA from the 'initiator' side (in COOKIE ECHO) - and
> everything works as expected... (the SACK here is for the bundled DATA
> chunks TSN.
>
> mlashley@duality /tmp $ tshark -r /tmp/sctp_index4_10K.pcap
> 1 0.000000000 ::1 → ::1 SCTP INIT
> 2 0.000014491 ::1 → ::1 SCTP INIT_ACK
> 3 0.000024190 ::1 → ::1 SCTP COOKIE_ECHO DATA
> 4 0.000034833 ::1 → ::1 SCTP COOKIE_ACK
> 5 0.000040646 ::1 → ::1 SCTP SACK
> 6 0.000050287 ::1 → ::1 SCTP ABORT
>
> In short - the SCTP associations /can/ persist after user-space calls
> close() whilst there is outstanding data (for path.max.retrans *
> rto-with-doubling[due to T3-rtx expiry])
>
> (My tests on 5.2.0 as it is what I had to hand...)
>
> Cheers,
> malc.
^ permalink raw reply
* Re: [PATCH 1/2] net/macb: bindings doc: add sifive fu540-c000 binding
From: Yash Shah @ 2019-07-17 9:07 UTC (permalink / raw)
To: Nicolas Ferre
Cc: Rob Herring, David Miller, netdev,
linux-kernel@vger.kernel.org List, linux-riscv, devicetree,
Mark Rutland, Palmer Dabbelt, Albert Ou, Petr Štetiar,
Paul Walmsley, Sachin Ghadi
In-Reply-To: <b0c60ec9-2f57-c3f5-c3b4-ee83a5ec4c45@microchip.com>
On Mon, Jun 24, 2019 at 9:08 PM <Nicolas.Ferre@microchip.com> wrote:
>
> On 23/05/2019 at 22:50, Rob Herring wrote:
> > On Thu, May 23, 2019 at 6:46 AM Yash Shah <yash.shah@sifive.com> wrote:
> >>
> >> Add the compatibility string documentation for SiFive FU540-C0000
> >> interface.
> >> On the FU540, this driver also needs to read and write registers in a
> >> management IP block that monitors or drives boundary signals for the
> >> GEMGXL IP block that are not directly mapped to GEMGXL registers.
> >> Therefore, add additional range to "reg" property for SiFive GEMGXL
> >> management IP registers.
> >>
> >> Signed-off-by: Yash Shah <yash.shah@sifive.com>
> >> ---
> >> Documentation/devicetree/bindings/net/macb.txt | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
> >> index 9c5e944..91a2a66 100644
> >> --- a/Documentation/devicetree/bindings/net/macb.txt
> >> +++ b/Documentation/devicetree/bindings/net/macb.txt
> >> @@ -4,6 +4,7 @@ Required properties:
> >> - compatible: Should be "cdns,[<chip>-]{macb|gem}"
> >> Use "cdns,at91rm9200-emac" Atmel at91rm9200 SoC.
> >> Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs.
> >> + Use "cdns,fu540-macb" for SiFive FU540-C000 SoC.
> >
> > This pattern that Atmel started isn't really correct. The vendor
> > prefix here should be sifive. 'cdns' would be appropriate for a
> > fallback.
>
> Ok, we missed this for the sam9x60 SoC that we added recently then.
>
> Anyway a little too late, coming back to this machine, and talking to
> Yash, isn't "sifive,fu540-c000-macb" more specific and a better match
> for being future proof? I would advice for the most specific possible
> with other compatible strings on the same line in the DT, like:
>
> "sifive,fu540-c000-macb", "sifive,fu540-macb"
>
Yes, I agree that "sifive,fu540-c000-macb" is a better match.
> Moreover, is it really a "macb" or a "gem" type of interface from
> Cadence? Not a big deal, but just to discuss the topic to the bone...
I believe it should be "gem". I will plan to submit the patch for
these changes. Thanks for pointing it out.
- Yash
>
> Note that I'm fine if you consider that what you have in net-next new is
> correct.
>
> Regards,
> Nicolas
>
> >> Use "cdns,sam9x60-macb" for Microchip sam9x60 SoC.
> >> Use "cdns,np4-macb" for NP4 SoC devices.
> >> Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
> >> @@ -17,6 +18,8 @@ Required properties:
> >> Use "cdns,zynqmp-gem" for Zynq Ultrascale+ MPSoC.
> >> Or the generic form: "cdns,emac".
> >> - reg: Address and length of the register set for the device
> >> + For "cdns,fu540-macb", second range is required to specify the
> >> + address and length of the registers for GEMGXL Management block.
> >> - interrupts: Should contain macb interrupt
> >> - phy-mode: See ethernet.txt file in the same directory.
> >> - clock-names: Tuple listing input clock names.
> >> --
> >> 1.9.1
> >>
> >
>
>
> --
> Nicolas Ferre
^ permalink raw reply
* WARNING: held lock freed in nr_release
From: syzbot @ 2019-07-17 8:58 UTC (permalink / raw)
To: davem, linux-hams, linux-kernel, netdev, ralf, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 3eb51486 Merge tag 'arc-5.3-rc1' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=144104d0600000
kernel config: https://syzkaller.appspot.com/x/.config?x=1044f14a33f8bb44
dashboard link: https://syzkaller.appspot.com/bug?extid=a34e5f3d0300163f0c87
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=174ef948600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12475834600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+a34e5f3d0300163f0c87@syzkaller.appspotmail.com
=========================
WARNING: held lock freed!
5.2.0+ #66 Not tainted
-------------------------
syz-executor290/9125 is freeing memory ffff8880936e02c0-ffff8880936e0abf,
with a lock still held there!
000000005bf1c8ae (sk_lock-AF_NETROM){+.+.}, at: lock_sock
include/net/sock.h:1522 [inline]
000000005bf1c8ae (sk_lock-AF_NETROM){+.+.}, at: nr_release+0x130/0x3e0
net/netrom/af_netrom.c:522
2 locks held by syz-executor290/9125:
#0: 0000000027c540ab (&sb->s_type->i_mutex_key#12){+.+.}, at: inode_lock
include/linux/fs.h:778 [inline]
#0: 0000000027c540ab (&sb->s_type->i_mutex_key#12){+.+.}, at:
__sock_release+0x89/0x280 net/socket.c:585
#1: 000000005bf1c8ae (sk_lock-AF_NETROM){+.+.}, at: lock_sock
include/net/sock.h:1522 [inline]
#1: 000000005bf1c8ae (sk_lock-AF_NETROM){+.+.}, at: nr_release+0x130/0x3e0
net/netrom/af_netrom.c:522
stack backtrace:
CPU: 0 PID: 9125 Comm: syz-executor290 Not tainted 5.2.0+ #66
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_freed_lock_bug kernel/locking/lockdep.c:5185 [inline]
debug_check_no_locks_freed.cold+0x9d/0xa9 kernel/locking/lockdep.c:5218
kfree+0xec/0x2c0 mm/slab.c:3753
sk_prot_free net/core/sock.c:1640 [inline]
__sk_destruct+0x4f7/0x6e0 net/core/sock.c:1726
sk_destruct+0x86/0xa0 net/core/sock.c:1734
__sk_free+0xfb/0x360 net/core/sock.c:1745
sk_free+0x42/0x50 net/core/sock.c:1756
sock_put include/net/sock.h:1725 [inline]
nr_destroy_socket+0x3ea/0x4b0 net/netrom/af_netrom.c:288
nr_release+0x347/0x3e0 net/netrom/af_netrom.c:530
__sock_release+0xce/0x280 net/socket.c:586
sock_close+0x1e/0x30 net/socket.c:1264
__fput+0x2ff/0x890 fs/file_table.c:280
____fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x904/0x2eb0 kernel/exit.c:877
do_group_exit+0x135/0x370 kernel/exit.c:981
get_signal+0x48a/0x2510 kernel/signal.c:2728
do_signal+0x87/0x1670 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x286/0x380 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x442609
Code: Bad RIP value.
RSP: 002b:00007ffc16869ec8 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
RAX: 0000000000000003 RBX: 0000000000000003 RCX: 0000000000442609
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 0000000000017e2c R08: 0000000000000003 R09: 0000000400000009
R10: 0000000400000009 R11: 0000000000000246 R12: 0000000000403440
R13: 00000000004034d0 R14: 0000000000000000 R15: 0000000000000000
==================================================================
BUG: KASAN: use-after-free in debug_spin_lock_before
kernel/locking/spinlock_debug.c:83 [inline]
BUG: KASAN: use-after-free in do_raw_spin_lock+0x28a/0x2e0
kernel/locking/spinlock_debug.c:112
Read of size 4 at addr ffff8880936e034c by task syz-executor290/9125
CPU: 0 PID: 9125 Comm: syz-executor290 Not tainted 5.2.0+ #66
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
print_address_description.cold+0xd4/0x306 mm/kasan/report.c:351
__kasan_report.cold+0x1b/0x36 mm/kasan/report.c:482
kasan_report+0x12/0x20 mm/kasan/common.c:612
__asan_report_load4_noabort+0x14/0x20 mm/kasan/generic_report.c:131
debug_spin_lock_before kernel/locking/spinlock_debug.c:83 [inline]
do_raw_spin_lock+0x28a/0x2e0 kernel/locking/spinlock_debug.c:112
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
_raw_spin_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:175
spin_lock_bh include/linux/spinlock.h:343 [inline]
release_sock+0x20/0x1c0 net/core/sock.c:2932
nr_release+0x303/0x3e0 net/netrom/af_netrom.c:553
__sock_release+0xce/0x280 net/socket.c:586
sock_close+0x1e/0x30 net/socket.c:1264
__fput+0x2ff/0x890 fs/file_table.c:280
____fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x904/0x2eb0 kernel/exit.c:877
do_group_exit+0x135/0x370 kernel/exit.c:981
get_signal+0x48a/0x2510 kernel/signal.c:2728
do_signal+0x87/0x1670 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x286/0x380 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x442609
Code: Bad RIP value.
RSP: 002b:00007ffc16869ec8 EFLAGS: 00000246 ORIG_RAX: 000000000000002b
RAX: 0000000000000003 RBX: 0000000000000003 RCX: 0000000000442609
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 0000000000017e2c R08: 0000000000000003 R09: 0000000400000009
R10: 0000000400000009 R11: 0000000000000246 R12: 0000000000403440
R13: 00000000004034d0 R14: 0000000000000000 R15: 0000000000000000
Allocated by task 9130:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc mm/kasan/common.c:487 [inline]
__kasan_kmalloc.constprop.0+0xcf/0xe0 mm/kasan/common.c:460
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
__do_kmalloc mm/slab.c:3655 [inline]
__kmalloc+0x163/0x780 mm/slab.c:3664
kmalloc include/linux/slab.h:557 [inline]
sk_prot_alloc+0x23a/0x310 net/core/sock.c:1603
sk_alloc+0x39/0xf70 net/core/sock.c:1657
nr_make_new net/netrom/af_netrom.c:476 [inline]
nr_rx_frame+0x733/0x1e80 net/netrom/af_netrom.c:959
nr_loopback_timer+0x7b/0x170 net/netrom/nr_loopback.c:59
call_timer_fn+0x1ac/0x780 kernel/time/timer.c:1322
expire_timers kernel/time/timer.c:1366 [inline]
__run_timers kernel/time/timer.c:1685 [inline]
__run_timers kernel/time/timer.c:1653 [inline]
run_timer_softirq+0x697/0x17a0 kernel/time/timer.c:1698
__do_softirq+0x262/0x98c kernel/softirq.c:292
Freed by task 9125:
save_stack+0x23/0x90 mm/kasan/common.c:69
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x102/0x150 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x10a/0x2c0 mm/slab.c:3756
sk_prot_free net/core/sock.c:1640 [inline]
__sk_destruct+0x4f7/0x6e0 net/core/sock.c:1726
sk_destruct+0x86/0xa0 net/core/sock.c:1734
__sk_free+0xfb/0x360 net/core/sock.c:1745
sk_free+0x42/0x50 net/core/sock.c:1756
sock_put include/net/sock.h:1725 [inline]
nr_destroy_socket+0x3ea/0x4b0 net/netrom/af_netrom.c:288
nr_release+0x347/0x3e0 net/netrom/af_netrom.c:530
__sock_release+0xce/0x280 net/socket.c:586
sock_close+0x1e/0x30 net/socket.c:1264
__fput+0x2ff/0x890 fs/file_table.c:280
____fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
exit_task_work include/linux/task_work.h:22 [inline]
do_exit+0x904/0x2eb0 kernel/exit.c:877
do_group_exit+0x135/0x370 kernel/exit.c:981
get_signal+0x48a/0x2510 kernel/signal.c:2728
do_signal+0x87/0x1670 arch/x86/kernel/signal.c:815
exit_to_usermode_loop+0x286/0x380 arch/x86/entry/common.c:159
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x5a9/0x6a0 arch/x86/entry/common.c:299
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8880936e02c0
which belongs to the cache kmalloc-2k of size 2048
The buggy address is located 140 bytes inside of
2048-byte region [ffff8880936e02c0, ffff8880936e0ac0)
The buggy address belongs to the page:
page:ffffea00024db800 refcount:1 mapcount:0 mapping:ffff8880aa400e00
index:0x0 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea000257f988 ffffea00024ef988 ffff8880aa400e00
raw: 0000000000000000 ffff8880936e02c0 0000000100000003 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff8880936e0200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff8880936e0280: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
> ffff8880936e0300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff8880936e0380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff8880936e0400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* kernel panic: stack is corrupted in pointer
From: syzbot @ 2019-07-17 8:58 UTC (permalink / raw)
To: airlied, alexander.deucher, amd-gfx, ast, christian.koenig,
daniel, david1.zhou, dri-devel, leo.liu, linux-kernel, netdev,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 1438cde7 Add linux-next specific files for 20190716
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=13988058600000
kernel config: https://syzkaller.appspot.com/x/.config?x=3430a151e1452331
dashboard link: https://syzkaller.appspot.com/bug?extid=79f5f028005a77ecb6bb
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=111fc8afa00000
The bug was bisected to:
commit 96a5d8d4915f3e241ebb48d5decdd110ab9c7dcf
Author: Leo Liu <leo.liu@amd.com>
Date: Fri Jul 13 15:26:28 2018 +0000
drm/amdgpu: Make sure IB tests flushed after IP resume
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=14a46200600000
final crash: https://syzkaller.appspot.com/x/report.txt?x=16a46200600000
console output: https://syzkaller.appspot.com/x/log.txt?x=12a46200600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+79f5f028005a77ecb6bb@syzkaller.appspotmail.com
Fixes: 96a5d8d4915f ("drm/amdgpu: Make sure IB tests flushed after IP
resume")
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in:
pointer+0x702/0x750 lib/vsprintf.c:2187
Shutting down cpus with NMI
Kernel Offset: disabled
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* KASAN: use-after-free Write in check_noncircular
From: syzbot @ 2019-07-17 8:58 UTC (permalink / raw)
To: ast, daniel, jmorris, john.fastabend, linux-kernel,
linux-security-module, netdev, penguin-kernel, serge,
syzkaller-bugs, takedakn
Hello,
syzbot found the following crash on:
HEAD commit: 9637d517 Merge tag 'for-linus-20190715' of git://git.kerne..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=12f42e1fa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=88095c4f62402bcd
dashboard link: https://syzkaller.appspot.com/bug?extid=f5ceb7c55f59455035ca
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12cfbe1fa00000
The bug was bisected to:
commit e9db4ef6bf4ca9894bb324c76e01b8f1a16b2650
Author: John Fastabend <john.fastabend@gmail.com>
Date: Sat Jun 30 13:17:47 2018 +0000
bpf: sockhash fix omitted bucket lock in sock_close
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=109c3078600000
final crash: https://syzkaller.appspot.com/x/report.txt?x=129c3078600000
console output: https://syzkaller.appspot.com/x/log.txt?x=149c3078600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+f5ceb7c55f59455035ca@syzkaller.appspotmail.com
Fixes: e9db4ef6bf4c ("bpf: sockhash fix omitted bucket lock in sock_close")
==================================================================
BUG: KASAN: use-after-free in check_noncircular+0x91/0x560
kernel/locking/lockdep.c:1722
Write of size 56 at addr ffff888089815160 by task syz-executor.4/8772
CPU: 1 PID: 8772 Comm: syz-executor.4 Not tainted 5.2.0+ #31
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
Allocated by task 8457:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_kmalloc+0x11c/0x1b0 mm/kasan/common.c:487
kasan_kmalloc+0x9/0x10 mm/kasan/common.c:501
kmem_cache_alloc_trace+0x221/0x2f0 mm/slab.c:3550
kmalloc include/linux/slab.h:552 [inline]
tomoyo_print_header security/tomoyo/audit.c:156 [inline]
tomoyo_init_log+0x176/0x1f20 security/tomoyo/audit.c:255
tomoyo_supervisor+0x39c/0x13f0 security/tomoyo/common.c:2095
tomoyo_audit_path_log security/tomoyo/file.c:168 [inline]
tomoyo_path_permission security/tomoyo/file.c:587 [inline]
tomoyo_check_open_permission+0x488/0x9e0 security/tomoyo/file.c:777
tomoyo_file_open+0x141/0x190 security/tomoyo/tomoyo.c:319
security_file_open+0x65/0x2f0 security/security.c:1457
do_dentry_open+0x397/0x1060 fs/open.c:765
vfs_open+0x73/0x80 fs/open.c:887
do_last fs/namei.c:3416 [inline]
path_openat+0x136d/0x4400 fs/namei.c:3533
do_filp_open+0x1f7/0x430 fs/namei.c:3563
do_sys_open+0x343/0x620 fs/open.c:1070
__do_sys_open fs/open.c:1088 [inline]
__se_sys_open fs/open.c:1083 [inline]
__x64_sys_open+0x87/0x90 fs/open.c:1083
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 8457:
save_stack mm/kasan/common.c:69 [inline]
set_track mm/kasan/common.c:77 [inline]
__kasan_slab_free+0x12a/0x1e0 mm/kasan/common.c:449
kasan_slab_free+0xe/0x10 mm/kasan/common.c:457
__cache_free mm/slab.c:3425 [inline]
kfree+0x115/0x200 mm/slab.c:3756
tomoyo_init_log+0x1bf7/0x1f20 security/tomoyo/audit.c:294
tomoyo_supervisor+0x39c/0x13f0 security/tomoyo/common.c:2095
tomoyo_audit_path_log security/tomoyo/file.c:168 [inline]
tomoyo_path_permission security/tomoyo/file.c:587 [inline]
tomoyo_check_open_permission+0x488/0x9e0 security/tomoyo/file.c:777
tomoyo_file_open+0x141/0x190 security/tomoyo/tomoyo.c:319
security_file_open+0x65/0x2f0 security/security.c:1457
do_dentry_open+0x397/0x1060 fs/open.c:765
vfs_open+0x73/0x80 fs/open.c:887
do_last fs/namei.c:3416 [inline]
path_openat+0x136d/0x4400 fs/namei.c:3533
do_filp_open+0x1f7/0x430 fs/namei.c:3563
do_sys_open+0x343/0x620 fs/open.c:1070
__do_sys_open fs/open.c:1088 [inline]
__se_sys_open fs/open.c:1083 [inline]
__x64_sys_open+0x87/0x90 fs/open.c:1083
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
The buggy address belongs to the object at ffff8880898146c0
which belongs to the cache kmalloc-4k of size 4096
The buggy address is located 2720 bytes inside of
4096-byte region [ffff8880898146c0, ffff8880898156c0)
The buggy address belongs to the page:
page:ffffea0002260500 refcount:1 mapcount:0 mapping:ffff8880aa402000
index:0x0 compound_mapcount: 0
flags: 0x1fffc0000010200(slab|head)
raw: 01fffc0000010200 ffffea0002263b08 ffffea0002916d08 ffff8880aa402000
raw: 0000000000000000 ffff8880898146c0 0000000100000001 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
ffff888089815000: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888089815080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> ffff888089815100: fb fb fb fb f1 f1 f1 f1 00 f2 f2 f2 fb fb fb fb
^
ffff888089815180: fb fb fb f3 f3 f3 f3 f3 fb fb fb fb fb fb fb fb
ffff888089815200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] net/mlx5: Replace kfree with kvfree
From: Eric Dumazet @ 2019-07-17 8:33 UTC (permalink / raw)
To: Chuhong Yuan; +Cc: Saeed Mahameed, Leon Romanovsky, David S . Miller, netdev
In-Reply-To: <20190717080322.13631-1-hslester96@gmail.com>
On 7/17/19 10:03 AM, Chuhong Yuan wrote:
> Variable allocated by kvmalloc should not be freed by kfree.
> Because it may be allocated by vmalloc.
> So replace kfree with kvfree here.
>
> Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
> ---
Please add corresponding Fixes: tag, thanks !
> drivers/net/ethernet/mellanox/mlx5/core/health.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> index 2fe6923f7ce0..9314777d99e3 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
> @@ -597,7 +597,7 @@ mlx5_fw_fatal_reporter_dump(struct devlink_health_reporter *reporter,
> err = devlink_fmsg_arr_pair_nest_end(fmsg);
>
> free_data:
> - kfree(cr_data);
> + kvfree(cr_data);
> return err;
> }
>
>
^ permalink raw reply
* Re: [PATCH net] be2net: Signal that the device cannot transmit during reconfiguration
From: Benjamin Poirier @ 2019-07-17 8:23 UTC (permalink / raw)
To: Firo Yang
Cc: David Miller, Ajit Khaparde, Sathya Perla, Somnath Kotur,
Sriharsha Basavapatna, Saeed Mahameed, netdev@vger.kernel.org
In-Reply-To: <CH2PR18MB31898E033896F9760D36BFF288C90@CH2PR18MB3189.namprd18.prod.outlook.com>
On 2019/07/17 13:23, Firo Yang wrote:
> I think there is a problem if dev_watchdog() is triggered before netif_carrier_off(). dev_watchdog() might call ->ndo_tx_timeout(), i.e. be_tx_timeout(), if txq timeout happens. Thus be_tx_timeout() could still be able to access the memory which is being freed by be_update_queues().
Good point. That's a separate problem which would occur in case of real
tx timeout. How about this followup change:
--- a/drivers/net/ethernet/emulex/benet/be_main.c
+++ b/drivers/net/ethernet/emulex/benet/be_main.c
@@ -4698,8 +4698,13 @@ int be_update_queues(struct be_adapter *adapter)
int status;
if (netif_running(netdev)) {
+ /* be_tx_timeout() must not run concurrently with this
+ * function, synchronize with an already-running dev_watchdog
+ */
+ netif_tx_lock_bh(netdev);
/* device cannot transmit now, avoid dev_watchdog timeouts */
netif_carrier_off(netdev);
+ netif_tx_unlock_bh(netdev);
be_close(netdev);
}
^ permalink raw reply
* Re: [PATCH 0/2] arm/arm64: Add support for function error injection
From: Leo Yan @ 2019-07-17 8:14 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Russell King, Oleg Nesterov, Catalin Marinas, Will Deacon,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Arnd Bergmann, linux-arm-kernel, linux-kernel,
netdev, bpf, Justin He
In-Reply-To: <20190717165222.62e02b99ebc16e23c3b81de2@kernel.org>
On Wed, Jul 17, 2019 at 04:52:22PM +0900, Masami Hiramatsu wrote:
> On Tue, 16 Jul 2019 19:12:59 +0800
> Leo Yan <leo.yan@linaro.org> wrote:
>
> > This small patch set is to add support for function error injection;
> > this can be used to eanble more advanced debugging feature, e.g.
> > CONFIG_BPF_KPROBE_OVERRIDE.
> >
> > I only tested the first patch on arm64 platform Juno-r2 with below
> > steps; the second patch is for arm arch, but I absent the platform
> > for the testing so only pass compilation.
> >
> > - Enable kernel configuration:
> > CONFIG_BPF_KPROBE_OVERRIDE
> > CONFIG_BTRFS_FS
> > CONFIG_BPF_EVENTS=y
> > CONFIG_KPROBES=y
> > CONFIG_KPROBE_EVENTS=y
> > CONFIG_BPF_KPROBE_OVERRIDE=y
> > - Build samples/bpf on Juno-r2 board with Debian rootFS:
> > # cd $kernel
> > # make headers_install
> > # make samples/bpf/ LLC=llc-7 CLANG=clang-7
> > - Run the sample tracex7:
> > # ./tracex7 /dev/sdb1
> > [ 1975.211781] BTRFS error (device (efault)): open_ctree failed
> > mount: /mnt/linux-kernel/linux-cs-dev/samples/bpf/tmpmnt: mount(2) system call failed: Cannot allocate memory.
>
> This series looks good to me from the view point of override usage :)
>
> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
>
> For this series.
>
> Thank you,
Thank you for reviewing, Masami.
> >
> >
> > Leo Yan (2):
> > arm64: Add support for function error injection
> > arm: Add support for function error injection
> >
> > arch/arm/Kconfig | 1 +
> > arch/arm/include/asm/error-injection.h | 13 +++++++++++++
> > arch/arm/include/asm/ptrace.h | 5 +++++
> > arch/arm/lib/Makefile | 2 ++
> > arch/arm/lib/error-inject.c | 19 +++++++++++++++++++
> > arch/arm64/Kconfig | 1 +
> > arch/arm64/include/asm/error-injection.h | 13 +++++++++++++
> > arch/arm64/include/asm/ptrace.h | 5 +++++
> > arch/arm64/lib/Makefile | 2 ++
> > arch/arm64/lib/error-inject.c | 19 +++++++++++++++++++
> > 10 files changed, 80 insertions(+)
> > create mode 100644 arch/arm/include/asm/error-injection.h
> > create mode 100644 arch/arm/lib/error-inject.c
> > create mode 100644 arch/arm64/include/asm/error-injection.h
> > create mode 100644 arch/arm64/lib/error-inject.c
> >
> > --
> > 2.17.1
> >
>
>
> --
> Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* Re: memory leak in llc_ui_create (2)
From: syzbot @ 2019-07-17 8:09 UTC (permalink / raw)
To: davem, linux-kernel, netdev, syzkaller-bugs, xiyou.wangcong
In-Reply-To: <000000000000058a0f058bd50068@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 3eb51486 Merge tag 'arc-5.3-rc1' of git://git.kernel.org/p..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15ca2548600000
kernel config: https://syzkaller.appspot.com/x/.config?x=cd93db730dc81f01
dashboard link: https://syzkaller.appspot.com/bug?extid=6bf095f9becf5efef645
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=174254d0600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13bb0d84600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+6bf095f9becf5efef645@syzkaller.appspotmail.com
executing program
executing program
executing program
executing program
BUG: memory leak
unreferenced object 0xffff88811e6f1800 (size 2048):
comm "syz-executor273", pid 7002, jiffies 4294943426 (age 13.700s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
1a 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00 ...@............
backtrace:
[<0000000014a2e1ad>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<0000000014a2e1ad>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<0000000014a2e1ad>] slab_alloc mm/slab.c:3319 [inline]
[<0000000014a2e1ad>] __do_kmalloc mm/slab.c:3653 [inline]
[<0000000014a2e1ad>] __kmalloc+0x169/0x300 mm/slab.c:3664
[<00000000ba2cba1e>] kmalloc include/linux/slab.h:557 [inline]
[<00000000ba2cba1e>] sk_prot_alloc+0x112/0x170 net/core/sock.c:1603
[<00000000f1d9d4df>] sk_alloc+0x35/0x2f0 net/core/sock.c:1657
[<00000000d33ee81e>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
[<00000000f9f972a8>] llc_ui_create+0x7b/0x150 net/llc/af_llc.c:173
[<00000000d9cdf850>] __sock_create+0x164/0x250 net/socket.c:1414
[<00000000ca906883>] sock_create net/socket.c:1465 [inline]
[<00000000ca906883>] __sys_socket+0x69/0x110 net/socket.c:1507
[<00000000e00ea1b3>] __do_sys_socket net/socket.c:1516 [inline]
[<00000000e00ea1b3>] __se_sys_socket net/socket.c:1514 [inline]
[<00000000e00ea1b3>] __x64_sys_socket+0x1e/0x30 net/socket.c:1514
[<00000000dfc2afaa>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000702ee9bf>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88810acb0a00 (size 32):
comm "syz-executor273", pid 7002, jiffies 4294943426 (age 13.700s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
e1 00 00 00 03 00 00 00 0f 00 00 00 00 00 00 00 ................
backtrace:
[<000000006d098b11>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000006d098b11>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000006d098b11>] slab_alloc mm/slab.c:3319 [inline]
[<000000006d098b11>] kmem_cache_alloc_trace+0x145/0x2c0 mm/slab.c:3548
[<00000000f45530b8>] kmalloc include/linux/slab.h:552 [inline]
[<00000000f45530b8>] kzalloc include/linux/slab.h:748 [inline]
[<00000000f45530b8>] selinux_sk_alloc_security+0x48/0xb0
security/selinux/hooks.c:5073
[<000000003ff46bd8>] security_sk_alloc+0x49/0x70
security/security.c:2029
[<000000007c679d89>] sk_prot_alloc+0x12d/0x170 net/core/sock.c:1606
[<00000000f1d9d4df>] sk_alloc+0x35/0x2f0 net/core/sock.c:1657
[<00000000d33ee81e>] llc_sk_alloc+0x35/0x170 net/llc/llc_conn.c:950
[<00000000f9f972a8>] llc_ui_create+0x7b/0x150 net/llc/af_llc.c:173
[<00000000d9cdf850>] __sock_create+0x164/0x250 net/socket.c:1414
[<00000000ca906883>] sock_create net/socket.c:1465 [inline]
[<00000000ca906883>] __sys_socket+0x69/0x110 net/socket.c:1507
[<00000000e00ea1b3>] __do_sys_socket net/socket.c:1516 [inline]
[<00000000e00ea1b3>] __se_sys_socket net/socket.c:1514 [inline]
[<00000000e00ea1b3>] __x64_sys_socket+0x1e/0x30 net/socket.c:1514
[<00000000dfc2afaa>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000702ee9bf>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff88812ad27400 (size 224):
comm "syz-executor273", pid 7002, jiffies 4294943426 (age 13.700s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 50 a3 2a 81 88 ff ff 00 18 6f 1e 81 88 ff ff .P.*......o.....
backtrace:
[<000000003b74814c>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<000000003b74814c>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<000000003b74814c>] slab_alloc_node mm/slab.c:3262 [inline]
[<000000003b74814c>] kmem_cache_alloc_node+0x163/0x2f0 mm/slab.c:3574
[<000000005ec232c8>] __alloc_skb+0x6e/0x210 net/core/skbuff.c:197
[<00000000051d15bd>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000051d15bd>] alloc_skb_with_frags+0x5f/0x250
net/core/skbuff.c:5628
[<000000006b5faf6f>] sock_alloc_send_pskb+0x269/0x2a0
net/core/sock.c:2223
[<00000000c32ec5bd>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2240
[<00000000068e05dd>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
[<00000000776b0139>] sock_sendmsg_nosec net/socket.c:633 [inline]
[<00000000776b0139>] sock_sendmsg+0x54/0x70 net/socket.c:653
[<0000000028377a2b>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2307
[<00000000f74197f6>] __sys_sendmsg+0x80/0xf0 net/socket.c:2352
[<00000000084b8970>] __do_sys_sendmsg net/socket.c:2361 [inline]
[<00000000084b8970>] __se_sys_sendmsg net/socket.c:2359 [inline]
[<00000000084b8970>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2359
[<00000000dfc2afaa>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000702ee9bf>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
BUG: memory leak
unreferenced object 0xffff8881137ed400 (size 512):
comm "syz-executor273", pid 7002, jiffies 4294943426 (age 13.700s)
hex dump (first 32 bytes):
7a 0f 00 00 00 00 00 00 2f 31 37 20 30 38 3a 30 z......./17 08:0
35 3a 32 39 00 c6 bf 81 03 00 69 6c 65 3d 30 20 5:29......ile=0
backtrace:
[<00000000f10c8cea>] kmemleak_alloc_recursive
include/linux/kmemleak.h:43 [inline]
[<00000000f10c8cea>] slab_post_alloc_hook mm/slab.h:522 [inline]
[<00000000f10c8cea>] slab_alloc_node mm/slab.c:3262 [inline]
[<00000000f10c8cea>] kmem_cache_alloc_node_trace+0x161/0x2f0
mm/slab.c:3592
[<0000000082c86374>] __do_kmalloc_node mm/slab.c:3614 [inline]
[<0000000082c86374>] __kmalloc_node_track_caller+0x38/0x50
mm/slab.c:3629
[<000000009e316c15>] __kmalloc_reserve.isra.0+0x40/0xb0
net/core/skbuff.c:141
[<00000000817024aa>] __alloc_skb+0xa0/0x210 net/core/skbuff.c:209
[<00000000051d15bd>] alloc_skb include/linux/skbuff.h:1055 [inline]
[<00000000051d15bd>] alloc_skb_with_frags+0x5f/0x250
net/core/skbuff.c:5628
[<000000006b5faf6f>] sock_alloc_send_pskb+0x269/0x2a0
net/core/sock.c:2223
[<00000000c32ec5bd>] sock_alloc_send_skb+0x32/0x40 net/core/sock.c:2240
[<00000000068e05dd>] llc_ui_sendmsg+0x10a/0x540 net/llc/af_llc.c:933
[<00000000776b0139>] sock_sendmsg_nosec net/socket.c:633 [inline]
[<00000000776b0139>] sock_sendmsg+0x54/0x70 net/socket.c:653
[<0000000028377a2b>] ___sys_sendmsg+0x393/0x3c0 net/socket.c:2307
[<00000000f74197f6>] __sys_sendmsg+0x80/0xf0 net/socket.c:2352
[<00000000084b8970>] __do_sys_sendmsg net/socket.c:2361 [inline]
[<00000000084b8970>] __se_sys_sendmsg net/socket.c:2359 [inline]
[<00000000084b8970>] __x64_sys_sendmsg+0x23/0x30 net/socket.c:2359
[<00000000dfc2afaa>] do_syscall_64+0x76/0x1a0
arch/x86/entry/common.c:296
[<00000000702ee9bf>] entry_SYSCALL_64_after_hwframe+0x44/0xa9
^ permalink raw reply
* [PATCH] net/mlx5: Replace kfree with kvfree
From: Chuhong Yuan @ 2019-07-17 8:03 UTC (permalink / raw)
Cc: Saeed Mahameed, Leon Romanovsky, David S . Miller, netdev,
linux-rdma, linux-kernel, Chuhong Yuan
Variable allocated by kvmalloc should not be freed by kfree.
Because it may be allocated by vmalloc.
So replace kfree with kvfree here.
Signed-off-by: Chuhong Yuan <hslester96@gmail.com>
---
drivers/net/ethernet/mellanox/mlx5/core/health.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/health.c b/drivers/net/ethernet/mellanox/mlx5/core/health.c
index 2fe6923f7ce0..9314777d99e3 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/health.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/health.c
@@ -597,7 +597,7 @@ mlx5_fw_fatal_reporter_dump(struct devlink_health_reporter *reporter,
err = devlink_fmsg_arr_pair_nest_end(fmsg);
free_data:
- kfree(cr_data);
+ kvfree(cr_data);
return err;
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCH 0/2] arm/arm64: Add support for function error injection
From: Masami Hiramatsu @ 2019-07-17 7:52 UTC (permalink / raw)
To: Leo Yan
Cc: Russell King, Oleg Nesterov, Catalin Marinas, Will Deacon,
Alexei Starovoitov, Daniel Borkmann, Martin KaFai Lau, Song Liu,
Yonghong Song, Arnd Bergmann, linux-arm-kernel, linux-kernel,
netdev, bpf, Justin He
In-Reply-To: <20190716111301.1855-1-leo.yan@linaro.org>
On Tue, 16 Jul 2019 19:12:59 +0800
Leo Yan <leo.yan@linaro.org> wrote:
> This small patch set is to add support for function error injection;
> this can be used to eanble more advanced debugging feature, e.g.
> CONFIG_BPF_KPROBE_OVERRIDE.
>
> I only tested the first patch on arm64 platform Juno-r2 with below
> steps; the second patch is for arm arch, but I absent the platform
> for the testing so only pass compilation.
>
> - Enable kernel configuration:
> CONFIG_BPF_KPROBE_OVERRIDE
> CONFIG_BTRFS_FS
> CONFIG_BPF_EVENTS=y
> CONFIG_KPROBES=y
> CONFIG_KPROBE_EVENTS=y
> CONFIG_BPF_KPROBE_OVERRIDE=y
> - Build samples/bpf on Juno-r2 board with Debian rootFS:
> # cd $kernel
> # make headers_install
> # make samples/bpf/ LLC=llc-7 CLANG=clang-7
> - Run the sample tracex7:
> # ./tracex7 /dev/sdb1
> [ 1975.211781] BTRFS error (device (efault)): open_ctree failed
> mount: /mnt/linux-kernel/linux-cs-dev/samples/bpf/tmpmnt: mount(2) system call failed: Cannot allocate memory.
This series looks good to me from the view point of override usage :)
Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org>
For this series.
Thank you,
>
>
> Leo Yan (2):
> arm64: Add support for function error injection
> arm: Add support for function error injection
>
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/error-injection.h | 13 +++++++++++++
> arch/arm/include/asm/ptrace.h | 5 +++++
> arch/arm/lib/Makefile | 2 ++
> arch/arm/lib/error-inject.c | 19 +++++++++++++++++++
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/error-injection.h | 13 +++++++++++++
> arch/arm64/include/asm/ptrace.h | 5 +++++
> arch/arm64/lib/Makefile | 2 ++
> arch/arm64/lib/error-inject.c | 19 +++++++++++++++++++
> 10 files changed, 80 insertions(+)
> create mode 100644 arch/arm/include/asm/error-injection.h
> create mode 100644 arch/arm/lib/error-inject.c
> create mode 100644 arch/arm64/include/asm/error-injection.h
> create mode 100644 arch/arm64/lib/error-inject.c
>
> --
> 2.17.1
>
--
Masami Hiramatsu <mhiramat@kernel.org>
^ permalink raw reply
* [PATCH v2 2/3] Bluetooth: btusb: Load firmware exclusively for Intel BT
From: Kai-Heng Feng @ 2019-07-17 7:49 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, marcel,
johan.hedberg
Cc: linuxwifi, linux-wireless, netdev, linux-bluetooth, linux-kernel,
Kai-Heng Feng
In-Reply-To: <20190717074920.21624-1-kai.heng.feng@canonical.com>
To avoid the firmware loading race between Bluetooth and WiFi on Intel
8260, load firmware exclusively when IWLWIFI is enabled.
BugLink: https://bugs.launchpad.net/bugs/1832988
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
v2:
- Add bug report link.
- Rebase on latest wireless-next.
drivers/bluetooth/btusb.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 50aed5259c2b..ca7a5757a2ba 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2272,8 +2272,16 @@ static int btusb_setup_intel_new(struct hci_dev *hdev)
set_bit(BTUSB_DOWNLOADING, &data->flags);
+#if IS_ENABLED(CONFIG_IWLWIFI)
+ btintel_firmware_lock();
+#endif
+
/* Start firmware downloading and get boot parameter */
err = btintel_download_firmware(hdev, fw, &boot_param);
+
+#if IS_ENABLED(CONFIG_IWLWIFI)
+ btintel_firmware_unlock();
+#endif
if (err < 0)
goto done;
--
2.17.1
^ permalink raw reply related
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