* Re: [PATCH 38/42] isdn: replace ->proc_fops with ->proc_show
From: Paul Bolle @ 2018-05-18 8:43 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Andrew Morton, Alexander Viro, Alexey Dobriyan,
Greg Kroah-Hartman, Jiri Slaby, Alessandro Zummo,
Alexandre Belloni, linux-acpi, drbd-dev, linux-ide, netdev,
linux-rtc, megaraidlinux.pdl, linux-scsi, devel, linux-afs,
linux-ext4, jfs-discussion, netfilter-devel, linux-kernel
In-Reply-To: <20180516094346.20506-39-hch@lst.de>
Hi Christoph,
(I don't think the patches of this series ever hit the ISDN related addresses
still found in MAINTAINERS. And now I might be a bit late.)
Christoph Hellwig schreef op wo 16-05-2018 om 11:43 [+0200]:
> diff --git a/drivers/isdn/gigaset/capi.c b/drivers/isdn/gigaset/capi.c
> index ccec7778cad2..dac5cd35e901 100644
> --- a/drivers/isdn/gigaset/capi.c
> +++ b/drivers/isdn/gigaset/capi.c
> @@ -2437,19 +2437,6 @@ static int gigaset_proc_show(struct seq_file *m, void *v)
> return 0;
> }
>
> -static int gigaset_proc_open(struct inode *inode, struct file *file)
> -{
> - return single_open(file, gigaset_proc_show, PDE_DATA(inode));
> -}
> -
> -static const struct file_operations gigaset_proc_fops = {
> - .owner = THIS_MODULE,
> - .open = gigaset_proc_open,
> - .read = seq_read,
> - .llseek = seq_lseek,
> - .release = single_release,
> -};
> -
> /**
> * gigaset_isdn_regdev() - register device to LL
> * @cs: device descriptor structure.
> @@ -2478,8 +2465,7 @@ int gigaset_isdn_regdev(struct cardstate *cs, const char *isdnid)
> iif->ctr.register_appl = gigaset_register_appl;
> iif->ctr.release_appl = gigaset_release_appl;
> iif->ctr.send_message = gigaset_send_message;
> - iif->ctr.procinfo = gigaset_procinfo;
Is this intentional? You didn't touch the procinfo method in the other ISDN
drivers, as far as I can see.
(If it was intentional, gigaset_procinfo() can of course be removed.)
> - iif->ctr.proc_fops = &gigaset_proc_fops;
> + iif->ctr.proc_show = gigaset_proc_show,
> INIT_LIST_HEAD(&iif->appls);
> skb_queue_head_init(&iif->sendqueue);
> atomic_set(&iif->sendqlen, 0);
Thanks,
Paul Bolle
^ permalink raw reply
* Re: [PATCH 38/42] isdn: replace ->proc_fops with ->proc_show
From: Christoph Hellwig @ 2018-05-18 8:58 UTC (permalink / raw)
To: Paul Bolle
Cc: linux-rtc-u79uwXL29TY76Z2rM5mHXA, Alessandro Zummo,
Alexandre Belloni, devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b,
linux-afs-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jfs-discussion-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
Christoph Hellwig, linux-acpi-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA, Alexander Viro,
Jiri Slaby, Andrew Morton, linux-ext4-u79uwXL29TY76Z2rM5mHXA,
Alexey Dobriyan, megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w,
drbd-dev-cunTk1MwBs8qoQakbn7OcQ
In-Reply-To: <4e7091873e8a220c454a7ce5a3f52edc5b5c3e3a.camel-IWqWACnzNjzz+pZb47iToQ@public.gmane.org>
On Fri, May 18, 2018 at 10:43:46AM +0200, Paul Bolle wrote:
> > iif->ctr.release_appl = gigaset_release_appl;
> > iif->ctr.send_message = gigaset_send_message;
> > - iif->ctr.procinfo = gigaset_procinfo;
>
> Is this intentional? You didn't touch the procinfo method in the other ISDN
> drivers, as far as I can see.
>
> (If it was intentional, gigaset_procinfo() can of course be removed.)
Already fixed in the branch in Als tree.
^ permalink raw reply
* Re: [net-next 3/6] ixgbe: release lock for the duration of ixgbe_suspend_close()
From: Sergei Shtylyov @ 2018-05-18 8:59 UTC (permalink / raw)
To: Jeff Kirsher, davem; +Cc: Pavel Tatashin, netdev, nhorman, sassmann, jogreene
In-Reply-To: <20180517163732.30910-4-jeffrey.t.kirsher@intel.com>
Hello!
On 5/17/2018 7:37 PM, Jeff Kirsher wrote:
> From: Pavel Tatashin <pasha.tatashin@oracle.com>
>
> Currently, during device_shutdown() ixgbe holds rtnl_lock for the duration
> of lengthy ixgbe_close_suspend(). On machines with multiple ixgbe cards
> this lock prevents scaling if device_shutdown() function is multi-threaded.
>
> It is not necessary to hold this lock during ixgbe_close_suspend()
> as it is not held when ixgbe_close() is called also during shutdown but for
> kexec case.
>
> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>
> Tested-by: Andrew Bowers <andrewx.bowers@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> index a52d92e182ee..5ddfb93ed491 100644
> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> @@ -6698,8 +6698,15 @@ static int __ixgbe_shutdown(struct pci_dev *pdev, bool *enable_wake)
> rtnl_lock();
> netif_device_detach(netdev);
>
> - if (netif_running(netdev))
> + if (netif_running(netdev)) {
> + /* Suspend takes a long time, device_shutdown may be
> + * parallelized this function, so drop lock for the
Parallelizing? Else the sentence doesn't parse for me. :-)
> + * duration of this call.
> + */
> + rtnl_unlock();
> ixgbe_close_suspend(adapter);
> + rtnl_lock();
> + }
>
> ixgbe_clear_interrupt_scheme(adapter);
> rtnl_unlock();
MBR, Sergei
^ permalink raw reply
* Re: general protection fault in qdisc_hash_add
From: Dmitry Vyukov @ 2018-05-18 9:14 UTC (permalink / raw)
To: Hangbin Liu; +Cc: syzkaller, Paolo Abeni, Marcelo Ricardo Leitner, netdev
In-Reply-To: <20180518083820.GM8958@leo.usersys.redhat.com>
On Fri, May 18, 2018 at 10:38 AM, Hangbin Liu <liuhangbin@gmail.com> wrote:
> Hi Dmitry,
>
> I got a kasan GPF error when run netlink sched test. The syzkaller log file
> and call trace attached.
>
> What interested me is the TCA_RED_PARMS. Here is the log
>
> r0 = socket$nl_route(0x10, 0x3, 0x0)
> ioctl$sock_SIOCGIFINDEX(r0, 0x8933, &(0x7f0000000740)={'lo\x00', <r1=>0x0})
> sendmsg$nl_route_sched(r0, &(0x7f00000000c0)={&(0x7f0000000000)={0x10}, 0xc, &(0x7f0000000180)={&(0x7f00000002c0)=@newqdisc={0x148, 0x24, 0x421, 0x0, 0x0, {0x0, r1, {}, {0x0, 0xffff}}, [@qdisc_kind_options=@q_red={{0x8, 0x1, 'red\x00'}, {0x11c, 0x2, [@TCA_RED_PARMS={0x14, 0x1, {0x0, 0x0, 0x0, 0x1f}}, @TCA_RED_STAB={0x104, 0x2, "18ac558f2dba9315851070f6e8d2533e755bb93a10146fbf3450d1c5096ce5e8e25674655d985acf1dde6c6283858c71ba0c8c2ba63e82d8168ddaccb0e656849ad10cc603fdac12346de63f934064095e194ee7a3d129ccc57b3c15056f2c5b04584fa0986e2e284a1b4d74577f7b61c20772219d7c01a8f2164d27a074a37f6af6ea6415d6d80c578ff5e656f5bedf074b2d38a8b5b119ba1ef5e206952614d9951ef4027a8bc397208890380c6d6a1ec9994cfceef8675ab30395cc0115a850a4a327a00195903f1d6272567b734776754842f7c4d87da1b4cea9a7330329e290b1d7a7bb77f4e87640340c6c6d704655bd351f47a09af6e2f37583ea5b7e"}]}}]}, 0x148}, 0x1}, 0x0)
>
>
> From the log it sendmsg with TCA_RED_PARMS={0x14, 0x1, {0x0, 0x0, 0x0, 0x1f}}.
> But we defined tc_red_qopt like
> tc_red_qopt {
> limit int32
> qth_min int32
> qth_max int32
> Wlog int8[0:32]
> Plog int8[0:32]
> Scell_log int8[0:32]
> flag int8[0:8]
> }
>
> The items in the structer seems missmatch. Would you help explain how
> syzkaller fuzz the structer?
TCA_RED_PARMS union option is defined as:
q_red_options [
TCA_RED_PARMS nlattr[TCA_RED_PARMS, tc_red_qopt]
...
] [varlen]
and nlattr is defined as:
type nlattr[TYPE, PAYLOAD] nlattr_t[const[TYPE, int16], PAYLOAD]
type nlattr_t[TYPE, PAYLOAD] {
nla_len len[parent, int16]
nla_type TYPE
payload PAYLOAD
} [packed, align_4]
So here:
@TCA_RED_PARMS={0x14, 0x1, {0x0, 0x0, 0x0, 0x1f}}
first 2 numbers are nlattr len and type, and then the inner struct is
tc_red_qopt with truncated trailing zero values.
^ permalink raw reply
* Re: [PATCH v2 net-next 00/12] net: stmmac: Clean-up and tune-up
From: Jose Abreu @ 2018-05-18 9:17 UTC (permalink / raw)
To: David Miller, Jose.Abreu
Cc: f.fainelli, netdev, Joao.Pinto, Vitor.Soares, peppe.cavallaro,
alexandre.torgue
In-Reply-To: <20180517.144709.898265283908363051.davem@davemloft.net>
Hi David,
On 17-05-2018 19:47, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 17 May 2018 14:41:17 -0400 (EDT)
>
>> From: Jose Abreu <Jose.Abreu@synopsys.com>
>> Date: Thu, 17 May 2018 14:24:42 +0100
>>
>>> Given that the difference between better/worst is < 1%, I think
>>> we can conclude patches 3-13 don't affect the overall
>>> performance. I didn't profile the cache hits/miss though ...
>> Ok, thanks for making an effort to look into this more thoroughly.
>>
>> I'll apply this series to net-next, thank you.
> Sorry, I had to revert.
>
> It is one thing to say that you lack the hardware to physically test
> the changes on all chip types.
>
> It is yet another to not even test the build properly:
>
> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:494:10: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> .init = sun8i_dwmac_dma_init,
> ^~~~~~~~~~~~~~~~~~~~
> drivers/net/ethernet/stmicro/stmmac/dwmac-sun8i.c:494:10: note: (near initialization for ‘sun8i_dwmac_dma_ops.init’)
> cc1: some warnings being treated as errors
Yeah, I was missing CONFIG_COMPILE_TEST=y. Sorry about that. Will
respin.
Thanks and Best Regards,
Jose Miguel Abreu
^ permalink raw reply
* [PATCH] net/atheros: fix spelling mistake: "Ddescription" -> "Description"
From: Colin King @ 2018-05-18 9:22 UTC (permalink / raw)
To: Jay Cliburn, Chris Snook, David S . Miller, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistakes in name field text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/ethernet/atheros/atl1e/atl1e_param.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/atheros/atl1e/atl1e_param.c b/drivers/net/ethernet/atheros/atl1e/atl1e_param.c
index fa314282c9ad..6a375f4bd054 100644
--- a/drivers/net/ethernet/atheros/atl1e/atl1e_param.c
+++ b/drivers/net/ethernet/atheros/atl1e/atl1e_param.c
@@ -192,7 +192,7 @@ void atl1e_check_options(struct atl1e_adapter *adapter)
{ /* Transmit Ring Size */
struct atl1e_option opt = {
.type = range_option,
- .name = "Transmit Ddescription Count",
+ .name = "Transmit Description Count",
.err = "using default of "
__MODULE_STRING(ATL1E_DEFAULT_TX_DESC_CNT),
.def = ATL1E_DEFAULT_TX_DESC_CNT,
--
2.17.0
^ permalink raw reply related
* Re: KASAN: use-after-free Read in vhost_chr_write_iter
From: Jason Wang @ 2018-05-18 9:24 UTC (permalink / raw)
To: DaeRyong Jeong, mst
Cc: kvm, virtualization, netdev, linux-kernel, byoungyoung, kt0755,
bammanag
In-Reply-To: <20180517134544.GA20646@dragonet.kaist.ac.kr>
On 2018年05月17日 21:45, DaeRyong Jeong wrote:
> We report the crash: KASAN: use-after-free Read in vhost_chr_write_iter
>
> This crash has been found in v4.17-rc1 using RaceFuzzer (a modified
> version of Syzkaller), which we describe more at the end of this
> report. Our analysis shows that the race occurs when invoking two
> syscalls concurrently, write$vnet and ioctl$VHOST_RESET_OWNER.
>
>
> Analysis:
> We think the concurrent execution of vhost_process_iotlb_msg() and
> vhost_dev_cleanup() causes the crash.
> Both of functions can run concurrently (please see call sequence below),
> and possibly, there is a race on dev->iotlb.
> If the switch occurs right after vhost_dev_cleanup() frees
> dev->iotlb, vhost_process_iotlb_msg() still sees the non-null value and it
> keep executing without returning -EFAULT. Consequently, use-after-free
> occures
>
>
> Thread interleaving:
> CPU0 (vhost_process_iotlb_msg) CPU1 (vhost_dev_cleanup)
> (In the case of both VHOST_IOTLB_UPDATE and
> VHOST_IOTLB_INVALIDATE)
> ===== =====
> vhost_umem_clean(dev->iotlb);
> if (!dev->iotlb) {
> ret = -EFAULT;
> break;
> }
> dev->iotlb = NULL;
>
>
> Call Sequence:
> CPU0
> =====
> vhost_net_chr_write_iter
> vhost_chr_write_iter
> vhost_process_iotlb_msg
>
> CPU1
> =====
> vhost_net_ioctl
> vhost_net_reset_owner
> vhost_dev_reset_owner
> vhost_dev_cleanup
Thanks a lot for the analysis.
This could be addressed by simply protect it with dev mutex.
Will post a patch.
^ permalink raw reply
* Re: [PATCH v2] netfilter: properly initialize xt_table_info structure
From: Florian Westphal @ 2018-05-18 9:27 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Jan Engelhardt, Eric Dumazet, Greg Hackmann, Pablo Neira Ayuso,
Jozsef Kadlecsik, Florian Westphal, Michal Kubecek,
netfilter-devel, coreteam, netdev
In-Reply-To: <20180517132012.GA29160@kroah.com>
Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> On Thu, May 17, 2018 at 12:42:00PM +0200, Jan Engelhardt wrote:
> >
> > On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
> > >> > --- a/net/netfilter/x_tables.c
> > >> > +++ b/net/netfilter/x_tables.c
> > >> > @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
> > >> > * than shoot all processes down before realizing there is nothing
> > >> > * more to reclaim.
> > >> > */
> > >> > - info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > >> > + info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > >> > if (!info)
> > >> > return NULL;
> > >>
> > >> I am curious, what particular path does not later overwrite the whole zone ?
> > >
> > >In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
> > >can be larger than the size of the structure itself.
> > >
> > >Then the data is copied to userspace in copy_entries_to_user() for ipv4
> > >and v6, and that's where the "bad data"
> >
> > If the kernel incorrectly copies more bytes than it should, isn't that
> > a sign that may be going going past the end of the info buffer?
> > (And thus, zeroing won't truly fix the issue)
>
> No, the buffer size is correct, we just aren't filling up the whole
> buffer as the data requested is smaller than the buffer size.
I have no objections to the patch but I'd like to understand what
problem its fixing.
Normal pattern is:
newinfo = xt_alloc_table_info(tmp.size);
copy_from_user(newinfo->entries, user + sizeof(tmp), tmp.size);
So inital value of the rule blob area should not matter.
Furthermore, when copying the rule blob back to userspace,
the kernel is not supposed to copy any padding back to userspace either,
since commit f32815d21d4d8287336fb9cef4d2d9e0866214c2 only the
user-relevant parts should be copied (some matches and targets allocate
kernel-private data such as pointers, and we did use to leak such pointer
values back to userspace).
^ permalink raw reply
* Re: Request for -stable inclusion: time stamping fix for nfp
From: Guillaume Nault @ 2018-05-18 9:55 UTC (permalink / raw)
To: David Miller; +Cc: jakub.kicinski, netdev
In-Reply-To: <20180517.140903.1581758299927078395.davem@davemloft.net>
On Thu, May 17, 2018 at 02:09:03PM -0400, David Miller wrote:
> From: Guillaume Nault <g.nault@alphalink.fr>
> Date: Thu, 17 May 2018 19:41:47 +0200
>
> > On Thu, Nov 16, 2017 at 10:13:28AM +0900, David Miller wrote:
> >> From: Guillaume Nault <g.nault@alphalink.fr>
> >> Date: Wed, 15 Nov 2017 17:20:46 +0100
> >>
> >> > Can you please queue commit 46f1c52e66db
> >> > ("nfp: TX time stamp packets before HW doorbell is rung") for -stable?
> >> > We got hit but this bug in the late summer. We run this fix internally
> >> > since a couple of months, but that'd be better to have it officially
> >> > backported so everyone can benefit of it.
> >>
> >> Queued up.
> >
> > I guess this one got lost somewhere as it doesn't appear in linux-4.9.y
> > (other trees aren't relevant).
> > If that's unintentional, than can you please re-queue
> > 46f1c52e66db ("nfp: TX time stamp packets before HW doorbell is rung")
> > to -stable?
>
> I only submit patches to -stable for the two most recent active branches
> which right now consists of 4.16 and 4.14 as per www.kernel.org
>
Sorry, I didn't know precisely which branches you were actually
handling. I'll remember that for next time.
^ permalink raw reply
* Re: [PATCH] wcn36xx: Add support for Factory Test Mode (FTM)
From: Ramon Fried @ 2018-05-18 10:06 UTC (permalink / raw)
To: Jeff Johnson
Cc: kvalo, linux-kernel, wcn36xx, linux-wireless, netdev, Eyal Ilsar,
linux-wireless-owner
In-Reply-To: <58c8d2d16995e80f5527370e224045e2@codeaurora.org>
On 17 May 2018 at 21:37, Jeff Johnson <jjohnson@codeaurora.org> wrote:
> On 2018-05-17 04:32, Ramon Fried wrote:
>>
>> From: Eyal Ilsar <eilsar@codeaurora.org>
>
> ...
>>
>> +int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
>> + struct ieee80211_vif *vif, void *ptt_msg,
>> size_t len,
>> + void **ptt_rsp_msg)
>> +{
>> + struct wcn36xx_hal_process_ptt_msg_req_msg *p_msg_body;
>> + int ret = 0;
>> +
>> + mutex_lock(&wcn->hal_mutex);
>> + p_msg_body = kmalloc(
>> + sizeof(struct wcn36xx_hal_process_ptt_msg_req_msg) + len,
>> + GFP_ATOMIC);
>
>
> NULL check required?
>
>> + INIT_HAL_PTT_MSG(p_msg_body, len);
>> +
Thanks Jeff. will fix it and send again :)
^ permalink raw reply
* [PATCH] hippi: fix spelling mistake: "Framming" -> "Framing"
From: Colin King @ 2018-05-18 10:09 UTC (permalink / raw)
To: Jes Sorensen, David S . Miller, linux-hippi, netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
Trivial fix to spelling mistake in printk message text
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/hippi/rrunner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/hippi/rrunner.c b/drivers/net/hippi/rrunner.c
index 1ab97d99b9ba..f41116488079 100644
--- a/drivers/net/hippi/rrunner.c
+++ b/drivers/net/hippi/rrunner.c
@@ -867,7 +867,7 @@ static u32 rr_handle_event(struct net_device *dev, u32 prodidx, u32 eidx)
dev->name);
goto drop;
case E_FRM_ERR:
- printk(KERN_WARNING "%s: Framming Error\n",
+ printk(KERN_WARNING "%s: Framing Error\n",
dev->name);
goto drop;
case E_FLG_SYN_ERR:
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v3 2/2] bpf: add selftest for rawir_event type program
From: Quentin Monnet @ 2018-05-18 10:13 UTC (permalink / raw)
To: Sean Young, Y Song
Cc: linux-media, linux-kernel, Alexei Starovoitov,
Mauro Carvalho Chehab, Daniel Borkmann, netdev, Matthias Reichl,
Devin Heitmueller
In-Reply-To: <20180517210140.ck225yuckq6onheb@gofer.mess.org>
2018-05-17 22:01 UTC+0100 ~ Sean Young <sean@mess.org>
> On Thu, May 17, 2018 at 10:17:59AM -0700, Y Song wrote:
>> On Wed, May 16, 2018 at 2:04 PM, Sean Young <sean@mess.org> wrote:
>>> This is simple test over rc-loopback.
>>>
>>> Signed-off-by: Sean Young <sean@mess.org>
>>> ---
>>> tools/bpf/bpftool/prog.c | 1 +
>>> tools/include/uapi/linux/bpf.h | 57 +++++++-
>>> tools/lib/bpf/libbpf.c | 1 +
>>> tools/testing/selftests/bpf/Makefile | 8 +-
>>> tools/testing/selftests/bpf/bpf_helpers.h | 6 +
>>> tools/testing/selftests/bpf/test_rawir.sh | 37 +++++
>>> .../selftests/bpf/test_rawir_event_kern.c | 26 ++++
>>> .../selftests/bpf/test_rawir_event_user.c | 130 ++++++++++++++++++
>>> 8 files changed, 261 insertions(+), 5 deletions(-)
>>> create mode 100755 tools/testing/selftests/bpf/test_rawir.sh
>>> create mode 100644 tools/testing/selftests/bpf/test_rawir_event_kern.c
>>> create mode 100644 tools/testing/selftests/bpf/test_rawir_event_user.c
[...]
>> Most people probably not really familiar with lircN device. It would be
>> good to provide more information about how to enable this, e.g.,
>> CONFIG_RC_CORE=y
>> CONFIG_BPF_RAWIR_EVENT=y
>> CONFIG_RC_LOOPBACK=y
>> ......
>
> Good point. I'll add some words explaining what is and how to make it work.
>
> Thanks
> Sean
By the way, shouldn't the two eBPF helpers bpf_rc_keydown() and
bpf_rc_repeat() be compiled out in patch 1 if e.g.
CONFIG_BPF_RAWIR_EVENT is not set? There are some other helpers that are
compiled only if relevant config options are set (bpf_get_xfrm_state()
for example).
(If you were to change that, please also update helper documentations to
indicate what configuration options are required to be able to use the
helpers.)
Best regards,
Quentin
^ permalink raw reply
* Re: general protection fault in qdisc_hash_add
From: Hangbin Liu @ 2018-05-18 10:13 UTC (permalink / raw)
To: Dmitry Vyukov; +Cc: syzkaller, Paolo Abeni, Marcelo Ricardo Leitner, netdev
In-Reply-To: <CACT4Y+a=R1G=iN2vuv1hkf9JAw3jSjp6fXd6DHrR8tPn4KFgYQ@mail.gmail.com>
On Fri, May 18, 2018 at 11:14:07AM +0200, Dmitry Vyukov wrote:
> On Fri, May 18, 2018 at 10:38 AM, Hangbin Liu <liuhangbin@gmail.com> wrote:
> > Hi Dmitry,
> >
> > I got a kasan GPF error when run netlink sched test. The syzkaller log file
> > and call trace attached.
> >
> > What interested me is the TCA_RED_PARMS. Here is the log
> >
> > r0 = socket$nl_route(0x10, 0x3, 0x0)
> > ioctl$sock_SIOCGIFINDEX(r0, 0x8933, &(0x7f0000000740)={'lo\x00', <r1=>0x0})
> > sendmsg$nl_route_sched(r0, &(0x7f00000000c0)={&(0x7f0000000000)={0x10}, 0xc, &(0x7f0000000180)={&(0x7f00000002c0)=@newqdisc={0x148, 0x24, 0x421, 0x0, 0x0, {0x0, r1, {}, {0x0, 0xffff}}, [@qdisc_kind_options=@q_red={{0x8, 0x1, 'red\x00'}, {0x11c, 0x2, [@TCA_RED_PARMS={0x14, 0x1, {0x0, 0x0, 0x0, 0x1f}}, @TCA_RED_STAB={0x104, 0x2, "18ac558f2dba9315851070f6e8d2533e755bb93a10146fbf3450d1c5096ce5e8e25674655d985acf1dde6c6283858c71ba0c8c2ba63e82d8168ddaccb0e656849ad10cc603fdac12346de63f934064095e194ee7a3d129ccc57b3c15056f2c5b04584fa0986e2e284a1b4d74577f7b61c20772219d7c01a8f2164d27a074a37f6af6ea6415d6d80c578ff5e656f5bedf074b2d38a8b5b119ba1ef5e206952614d9951ef4027a8bc397208890380c6d6a1ec9994cfceef8675ab30395cc0115a850a4a327a00195903f1d6272567b734776754842f7c4d87da1b4cea9a7330329e290b1d7a7bb77f4e8
7640340c6c6d704655bd351f47a09af6e2f37583ea5b7e"}]}}]}, 0x148}, 0x1}, 0x0)
> >
> >
> > From the log it sendmsg with TCA_RED_PARMS={0x14, 0x1, {0x0, 0x0, 0x0, 0x1f}}.
> > But we defined tc_red_qopt like
> > tc_red_qopt {
> > limit int32
> > qth_min int32
> > qth_max int32
> > Wlog int8[0:32]
> > Plog int8[0:32]
> > Scell_log int8[0:32]
> > flag int8[0:8]
> > }
> >
> > The items in the structer seems missmatch. Would you help explain how
> > syzkaller fuzz the structer?
>
> TCA_RED_PARMS union option is defined as:
>
> q_red_options [
> TCA_RED_PARMS nlattr[TCA_RED_PARMS, tc_red_qopt]
> ...
> ] [varlen]
>
> and nlattr is defined as:
>
> type nlattr[TYPE, PAYLOAD] nlattr_t[const[TYPE, int16], PAYLOAD]
>
> type nlattr_t[TYPE, PAYLOAD] {
> nla_len len[parent, int16]
> nla_type TYPE
> payload PAYLOAD
> } [packed, align_4]
>
> So here:
>
> @TCA_RED_PARMS={0x14, 0x1, {0x0, 0x0, 0x0, 0x1f}}
>
> first 2 numbers are nlattr len and type, and then the inner struct is
> tc_red_qopt with truncated trailing zero values.
Ah, got it. Thanks for the explanation.
Regards
Hangbin
^ permalink raw reply
* [PATCH v2] wcn36xx: Add support for Factory Test Mode (FTM)
From: Ramon Fried @ 2018-05-18 10:31 UTC (permalink / raw)
To: kvalo, jjohnson
Cc: linux-kernel, wcn36xx, linux-wireless, netdev, Eyal Ilsar,
Ramon Fried
From: Eyal Ilsar <eilsar@codeaurora.org>
Introduce infrastructure for supporting Factory Test Mode (FTM) of the
wireless LAN subsystem. In order for the user space to access the
firmware in test mode the relevant netlink channel needs to be exposed
from the kernel driver.
The above is achieved as follows:
1) Register wcn36xx driver to testmode callback from netlink
2) Add testmode callback implementation to handle incoming FTM commands
3) Add FTM command packet structure
4) Add handling for GET_BUILD_RELEASE_NUMBER (msgid=0x32A2)
5) Add generic handling for all PTT_MSG packets
Signed-off-by: Eyal Ilsar <eilsar@codeaurora.org>
Signed-off-by: Ramon Fried <ramon.fried@linaro.org>
---
v2:
* check for NULL after kmalloc
* don't assign value to ret.
drivers/net/wireless/ath/wcn36xx/Makefile | 2 +
drivers/net/wireless/ath/wcn36xx/hal.h | 16 ++
drivers/net/wireless/ath/wcn36xx/main.c | 3 +
drivers/net/wireless/ath/wcn36xx/smd.c | 81 ++++++++++
drivers/net/wireless/ath/wcn36xx/smd.h | 4 +
drivers/net/wireless/ath/wcn36xx/testmode.c | 151 ++++++++++++++++++
drivers/net/wireless/ath/wcn36xx/testmode.h | 46 ++++++
drivers/net/wireless/ath/wcn36xx/testmode_i.h | 29 ++++
drivers/net/wireless/ath/wcn36xx/wcn36xx.h | 2 +
9 files changed, 334 insertions(+)
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.c
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode.h
create mode 100644 drivers/net/wireless/ath/wcn36xx/testmode_i.h
diff --git a/drivers/net/wireless/ath/wcn36xx/Makefile b/drivers/net/wireless/ath/wcn36xx/Makefile
index 3b09435104eb..582049f65735 100644
--- a/drivers/net/wireless/ath/wcn36xx/Makefile
+++ b/drivers/net/wireless/ath/wcn36xx/Makefile
@@ -6,3 +6,5 @@ wcn36xx-y += main.o \
smd.o \
pmc.o \
debug.o
+
+wcn36xx-$(CONFIG_NL80211_TESTMODE) += testmode.o
diff --git a/drivers/net/wireless/ath/wcn36xx/hal.h b/drivers/net/wireless/ath/wcn36xx/hal.h
index 182963522941..8491b3cb3206 100644
--- a/drivers/net/wireless/ath/wcn36xx/hal.h
+++ b/drivers/net/wireless/ath/wcn36xx/hal.h
@@ -2230,6 +2230,22 @@ struct wcn36xx_hal_switch_channel_rsp_msg {
} __packed;
+struct wcn36xx_hal_process_ptt_msg_req_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
+struct wcn36xx_hal_process_ptt_msg_rsp_msg {
+ struct wcn36xx_hal_msg_header header;
+
+ /* FTM Command response status */
+ u32 ptt_msg_resp_status;
+ /* Actual FTM Command body */
+ u8 ptt_msg[0];
+} __packed;
+
struct update_edca_params_req_msg {
struct wcn36xx_hal_msg_header header;
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c b/drivers/net/wireless/ath/wcn36xx/main.c
index 69d6be59d97f..ea14f87d11ff 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -26,6 +26,7 @@
#include <linux/soc/qcom/smem_state.h>
#include <linux/soc/qcom/wcnss_ctrl.h>
#include "wcn36xx.h"
+#include "testmode.h"
unsigned int wcn36xx_dbg_mask;
module_param_named(debug_mask, wcn36xx_dbg_mask, uint, 0644);
@@ -1116,6 +1117,8 @@ static const struct ieee80211_ops wcn36xx_ops = {
.sta_add = wcn36xx_sta_add,
.sta_remove = wcn36xx_sta_remove,
.ampdu_action = wcn36xx_ampdu_action,
+
+ CFG80211_TESTMODE_CMD(wcn36xx_tm_cmd)
};
static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c b/drivers/net/wireless/ath/wcn36xx/smd.c
index 8932af5e4d8d..fb0192b7ee99 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -292,12 +292,26 @@ static void init_hal_msg(struct wcn36xx_hal_msg_header *hdr,
msg_body.header.len = sizeof(msg_body); \
} while (0) \
+#define INIT_HAL_PTT_MSG(p_msg_body, ppt_msg_len) \
+ do { \
+ memset(p_msg_body, 0, sizeof(*p_msg_body) + ppt_msg_len); \
+ p_msg_body->header.msg_type = WCN36XX_HAL_PROCESS_PTT_REQ; \
+ p_msg_body->header.msg_version = WCN36XX_HAL_MSG_VERSION0; \
+ p_msg_body->header.len = sizeof(*p_msg_body) + ppt_msg_len; \
+ } while (0)
+
#define PREPARE_HAL_BUF(send_buf, msg_body) \
do { \
memset(send_buf, 0, msg_body.header.len); \
memcpy(send_buf, &msg_body, sizeof(msg_body)); \
} while (0) \
+#define PREPARE_HAL_PTT_MSG_BUF(send_buf, p_msg_body) \
+ do { \
+ memset(send_buf, 0, p_msg_body->header.len); \
+ memcpy(send_buf, p_msg_body, p_msg_body->header.len); \
+ } while (0)
+
static int wcn36xx_smd_rsp_status_check(void *buf, size_t len)
{
struct wcn36xx_fw_msg_status_rsp *rsp;
@@ -741,6 +755,71 @@ int wcn36xx_smd_switch_channel(struct wcn36xx *wcn,
return ret;
}
+static int wcn36xx_smd_process_ptt_msg_rsp(void *buf, size_t len,
+ void **p_ptt_rsp_msg)
+{
+ struct wcn36xx_hal_process_ptt_msg_rsp_msg *rsp;
+ int ret;
+
+ ret = wcn36xx_smd_rsp_status_check(buf, len);
+ if (ret)
+ return ret;
+
+ rsp = (struct wcn36xx_hal_process_ptt_msg_rsp_msg *)buf;
+
+ wcn36xx_dbg(WCN36XX_DBG_HAL, "process ptt msg responded with length %d\n",
+ rsp->header.len);
+ wcn36xx_dbg_dump(WCN36XX_DBG_HAL_DUMP, "HAL_PTT_MSG_RSP:", rsp->ptt_msg,
+ rsp->header.len - sizeof(rsp->ptt_msg_resp_status));
+
+ if (rsp->header.len > 0) {
+ *p_ptt_rsp_msg = kmalloc(rsp->header.len, GFP_ATOMIC);
+ if (!*p_ptt_rsp_msg)
+ return -ENOMEM;
+ memcpy(*p_ptt_rsp_msg, rsp->ptt_msg, rsp->header.len);
+ }
+ return ret;
+}
+
+int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
+ struct ieee80211_vif *vif, void *ptt_msg, size_t len,
+ void **ptt_rsp_msg)
+{
+ struct wcn36xx_hal_process_ptt_msg_req_msg *p_msg_body;
+ int ret;
+
+ mutex_lock(&wcn->hal_mutex);
+ p_msg_body = kmalloc(
+ sizeof(struct wcn36xx_hal_process_ptt_msg_req_msg) + len,
+ GFP_ATOMIC);
+ if (!p_msg_body) {
+ ret = -ENOMEM;
+ goto out_nomem;
+ }
+ INIT_HAL_PTT_MSG(p_msg_body, len);
+
+ memcpy(&p_msg_body->ptt_msg, ptt_msg, len);
+
+ PREPARE_HAL_PTT_MSG_BUF(wcn->hal_buf, p_msg_body);
+
+ ret = wcn36xx_smd_send_and_wait(wcn, p_msg_body->header.len);
+ if (ret) {
+ wcn36xx_err("Sending hal_process_ptt_msg failed\n");
+ goto out;
+ }
+ ret = wcn36xx_smd_process_ptt_msg_rsp(wcn->hal_buf, wcn->hal_rsp_len,
+ ptt_rsp_msg);
+ if (ret) {
+ wcn36xx_err("process_ptt_msg response failed err=%d\n", ret);
+ goto out;
+ }
+out:
+ kfree(p_msg_body);
+out_nomem:
+ mutex_unlock(&wcn->hal_mutex);
+ return ret;
+}
+
static int wcn36xx_smd_update_scan_params_rsp(void *buf, size_t len)
{
struct wcn36xx_hal_update_scan_params_resp *rsp;
@@ -2367,6 +2446,7 @@ int wcn36xx_smd_rsp_process(struct rpmsg_device *rpdev,
case WCN36XX_HAL_JOIN_RSP:
case WCN36XX_HAL_UPDATE_SCAN_PARAM_RSP:
case WCN36XX_HAL_CH_SWITCH_RSP:
+ case WCN36XX_HAL_PROCESS_PTT_RSP:
case WCN36XX_HAL_FEATURE_CAPS_EXCHANGE_RSP:
case WCN36XX_HAL_8023_MULTICAST_LIST_RSP:
case WCN36XX_HAL_START_SCAN_OFFLOAD_RSP:
@@ -2407,6 +2487,7 @@ int wcn36xx_smd_rsp_process(struct rpmsg_device *rpdev,
return 0;
}
+
static void wcn36xx_ind_smd_work(struct work_struct *work)
{
struct wcn36xx *wcn =
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h b/drivers/net/wireless/ath/wcn36xx/smd.h
index 8076edf40ac8..945407b8764b 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -86,6 +86,10 @@ int wcn36xx_smd_send_beacon(struct wcn36xx *wcn, struct ieee80211_vif *vif,
u16 p2p_off);
int wcn36xx_smd_switch_channel(struct wcn36xx *wcn,
struct ieee80211_vif *vif, int ch);
+int wcn36xx_smd_process_ptt_msg(struct wcn36xx *wcn,
+ struct ieee80211_vif *vif,
+ void *ptt_msg, size_t len,
+ void **ptt_rsp_msg);
int wcn36xx_smd_update_proberesp_tmpl(struct wcn36xx *wcn,
struct ieee80211_vif *vif,
struct sk_buff *skb);
diff --git a/drivers/net/wireless/ath/wcn36xx/testmode.c b/drivers/net/wireless/ath/wcn36xx/testmode.c
new file mode 100644
index 000000000000..74c5bd51b173
--- /dev/null
+++ b/drivers/net/wireless/ath/wcn36xx/testmode.c
@@ -0,0 +1,151 @@
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include <net/netlink.h>
+#include <linux/firmware.h>
+#include <net/cfg80211.h>
+#include "wcn36xx.h"
+
+#include "testmode.h"
+#include "testmode_i.h"
+#include "hal.h"
+#include "smd.h"
+
+static const struct nla_policy wcn36xx_tm_policy[WCN36XX_TM_ATTR_MAX + 1] = {
+ [WCN36XX_TM_ATTR_CMD] = { .type = NLA_U16 },
+ [WCN36XX_TM_ATTR_DATA] = { .type = NLA_BINARY,
+ .len = WCN36XX_TM_DATA_MAX_LEN },
+};
+
+struct build_release_number {
+ u16 drv_major;
+ u16 drv_minor;
+ u16 drv_patch;
+ u16 drv_build;
+ u16 ptt_max;
+ u16 ptt_min;
+ u16 fw_ver;
+} __packed;
+
+static int wcn36xx_tm_cmd_ptt(struct wcn36xx *wcn, struct ieee80211_vif *vif,
+ struct nlattr *tb[])
+{
+ int ret = 0, buf_len;
+ void *buf;
+ struct ftm_rsp_msg *msg, *rsp = NULL;
+ struct sk_buff *skb;
+
+ if (!tb[WCN36XX_TM_ATTR_DATA]) {
+ ret = -EINVAL;
+ goto out;
+ }
+
+ buf = nla_data(tb[WCN36XX_TM_ATTR_DATA]);
+ buf_len = nla_len(tb[WCN36XX_TM_ATTR_DATA]);
+ msg = (struct ftm_rsp_msg *)buf;
+
+ wcn36xx_dbg(WCN36XX_DBG_TESTMODE,
+ "testmode cmd wmi msg_id 0x%04X msg_len %d buf %pK buf_len %d\n",
+ msg->msg_id, msg->msg_body_length,
+ buf, buf_len);
+
+ wcn36xx_dbg_dump(WCN36XX_DBG_TESTMODE_DUMP, "REQ ", buf, buf_len);
+
+ if (msg->msg_id == MSG_GET_BUILD_RELEASE_NUMBER) {
+ struct build_release_number *body =
+ (struct build_release_number *)
+ msg->msg_response;
+
+ body->drv_major = wcn->fw_major;
+ body->drv_minor = wcn->fw_minor;
+ body->drv_patch = wcn->fw_version;
+ body->drv_build = wcn->fw_revision;
+ body->ptt_max = 10;
+ body->ptt_min = 0;
+
+ rsp = msg;
+ rsp->resp_status = 0;
+ } else {
+ wcn36xx_dbg(WCN36XX_DBG_TESTMODE,
+ "PPT Request >> HAL size %d\n",
+ msg->msg_body_length);
+
+ msg->resp_status = wcn36xx_smd_process_ptt_msg(wcn, vif, msg,
+ msg->msg_body_length, (void *)(&rsp));
+
+ wcn36xx_dbg(WCN36XX_DBG_TESTMODE,
+ "Response status = %d\n",
+ msg->resp_status);
+ if (rsp)
+ wcn36xx_dbg(WCN36XX_DBG_TESTMODE,
+ "PPT Response << HAL size %d\n",
+ rsp->msg_body_length);
+ }
+
+ if (!rsp) {
+ rsp = msg;
+ wcn36xx_warn("No response! Echoing request with response status %d\n",
+ rsp->resp_status);
+ }
+ wcn36xx_dbg_dump(WCN36XX_DBG_TESTMODE_DUMP, "RSP ",
+ rsp, rsp->msg_body_length);
+
+ skb = cfg80211_testmode_alloc_reply_skb(wcn->hw->wiphy,
+ nla_total_size(msg->msg_body_length));
+ if (!skb) {
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ ret = nla_put(skb, WCN36XX_TM_ATTR_DATA, rsp->msg_body_length, rsp);
+ if (ret) {
+ kfree_skb(skb);
+ goto out;
+ }
+
+ ret = cfg80211_testmode_reply(skb);
+
+out:
+ if (rsp != msg)
+ kfree(rsp);
+
+ return ret;
+}
+
+int wcn36xx_tm_cmd(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ void *data, int len)
+{
+ struct wcn36xx *wcn = hw->priv;
+ struct nlattr *tb[WCN36XX_TM_ATTR_MAX + 1];
+ int ret = 0;
+ unsigned short attr;
+
+ wcn36xx_dbg_dump(WCN36XX_DBG_TESTMODE_DUMP, "Data:", data, len);
+ ret = nla_parse(tb, WCN36XX_TM_ATTR_MAX, data, len,
+ wcn36xx_tm_policy, NULL);
+ if (ret)
+ return ret;
+
+ if (!tb[WCN36XX_TM_ATTR_CMD])
+ return -EINVAL;
+
+ attr = nla_get_u16(tb[WCN36XX_TM_ATTR_CMD]);
+
+ if (attr != WCN36XX_TM_CMD_PTT)
+ return -EOPNOTSUPP;
+
+ return wcn36xx_tm_cmd_ptt(wcn, vif, tb);
+}
diff --git a/drivers/net/wireless/ath/wcn36xx/testmode.h b/drivers/net/wireless/ath/wcn36xx/testmode.h
new file mode 100644
index 000000000000..4c6cfdb46580
--- /dev/null
+++ b/drivers/net/wireless/ath/wcn36xx/testmode.h
@@ -0,0 +1,46 @@
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "wcn36xx.h"
+
+struct ftm_rsp_msg {
+ u16 msg_id;
+ u16 msg_body_length;
+ u32 resp_status;
+ u8 msg_response[0];
+} __packed;
+
+/* The request buffer of FTM which contains a byte of command and the request */
+struct ftm_payload {
+ u16 ftm_cmd_type;
+ struct ftm_rsp_msg ftm_cmd_msg;
+} __packed;
+
+#define MSG_GET_BUILD_RELEASE_NUMBER 0x32A2
+
+#ifdef CONFIG_NL80211_TESTMODE
+int wcn36xx_tm_cmd(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
+ void *data, int len);
+
+#else
+static inline int wcn36xx_tm_cmd(struct ieee80211_hw *hw,
+ struct ieee80211_vif *vif,
+ void *data, int len)
+{
+ return 0;
+}
+
+#endif
diff --git a/drivers/net/wireless/ath/wcn36xx/testmode_i.h b/drivers/net/wireless/ath/wcn36xx/testmode_i.h
new file mode 100644
index 000000000000..8a1477ffd5a0
--- /dev/null
+++ b/drivers/net/wireless/ath/wcn36xx/testmode_i.h
@@ -0,0 +1,29 @@
+/*
+ * Copyright (c) 2018, The Linux Foundation. All rights reserved.
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
+ * SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
+ * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
+ * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#define WCN36XX_TM_DATA_MAX_LEN 5000
+
+enum wcn36xx_tm_attr {
+ __WCN36XX_TM_ATTR_INVALID = 0,
+ WCN36XX_TM_ATTR_CMD = 1,
+ WCN36XX_TM_ATTR_DATA = 2,
+
+ /* keep last */
+ __WCN36XX_TM_ATTR_AFTER_LAST,
+ WCN36XX_TM_ATTR_MAX = __WCN36XX_TM_ATTR_AFTER_LAST - 1,
+};
+
+#define WCN36XX_TM_CMD_PTT 3
diff --git a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
index 5854adf43f3a..547e9a9eb28f 100644
--- a/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
+++ b/drivers/net/wireless/ath/wcn36xx/wcn36xx.h
@@ -56,6 +56,8 @@ enum wcn36xx_debug_mask {
WCN36XX_DBG_BEACON_DUMP = 0x00001000,
WCN36XX_DBG_PMC = 0x00002000,
WCN36XX_DBG_PMC_DUMP = 0x00004000,
+ WCN36XX_DBG_TESTMODE = 0x00008000,
+ WCN36XX_DBG_TESTMODE_DUMP = 0x00010000,
WCN36XX_DBG_ANY = 0xffffffff,
};
--
2.17.0
^ permalink raw reply related
* [PATCH v2] sh_eth: Change platform check to CONFIG_ARCH_RENESAS
From: Geert Uytterhoeven @ 2018-05-18 10:52 UTC (permalink / raw)
To: David S . Miller, Sergei Shtylyov
Cc: netdev, linux-renesas-soc, Geert Uytterhoeven
Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
CONFIG_ARCH_SHMOBILE, hence use the former.
Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
check.
This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
future.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
---
v2:
- Add Acked-by, Reviewed-by.
---
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/renesas/sh_eth.h b/drivers/net/ethernet/renesas/sh_eth.h
index a5b792ce2ae7d046..1bf930d4a1e52c18 100644
--- a/drivers/net/ethernet/renesas/sh_eth.h
+++ b/drivers/net/ethernet/renesas/sh_eth.h
@@ -163,7 +163,7 @@ enum {
};
/* Driver's parameters */
-#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_SHMOBILE)
+#if defined(CONFIG_CPU_SH4) || defined(CONFIG_ARCH_RENESAS)
#define SH_ETH_RX_ALIGN 32
#else
#define SH_ETH_RX_ALIGN 2
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v2] sh_eth: Change platform check to CONFIG_ARCH_RENESAS
From: Sergei Shtylyov @ 2018-05-18 10:56 UTC (permalink / raw)
To: Geert Uytterhoeven, David S . Miller; +Cc: netdev, linux-renesas-soc
In-Reply-To: <1526640771-473-1-git-send-email-geert+renesas@glider.be>
On 05/18/2018 01:52 PM, Geert Uytterhoeven wrote:
> Since commit 9b5ba0df4ea4f940 ("ARM: shmobile: Introduce ARCH_RENESAS")
> is CONFIG_ARCH_RENESAS a more appropriate platform check than the legacy
"If" should follow, not precede the option as this is not a question. :-)
> CONFIG_ARCH_SHMOBILE, hence use the former.
>
> Renesas SuperH SH-Mobile SoCs are still covered by the CONFIG_CPU_SH4
> check.
>
> This will allow to drop ARCH_SHMOBILE on ARM and ARM64 in the near
> future.
>
> Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
> Acked-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH 0/3] Add R8A77980 GEther support
From: Sergei Shtylyov @ 2018-05-18 11:00 UTC (permalink / raw)
To: David Miller; +Cc: netdev, devicetree, robh+dt, mark.rutland, linux-renesas-soc
In-Reply-To: <20180517.145357.2037804925428844092.davem@davemloft.net>
On 05/17/2018 09:53 PM, David Miller wrote:
>> Here's a set of 3 patches against DaveM's 'net-next.git' repo. They (gradually)
>> add R8A77980 GEther support to the 'sh_eth' driver, starting with couple new
>> register bits/values introduced with this chip, and ending with adding a new
>> 'struct sh_eth_cpu_data' instance connected to the new DT "compatible" prop
>> value...
>>
>> [1/1] sh_eth: add RGMII support
>> [2/3] sh_eth: add EDMR.NBST support
>> [3/3] sh_eth: add R8A77980 support
>
> Waiting for a respin of this, correcting the RGMII check in patch #1.
Respun yesterday, will repost RSN. :-)
MBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] netfilter: properly initialize xt_table_info structure
From: Greg Kroah-Hartman @ 2018-05-18 11:04 UTC (permalink / raw)
To: Florian Westphal
Cc: Jan Engelhardt, Eric Dumazet, Greg Hackmann, Pablo Neira Ayuso,
Jozsef Kadlecsik, Michal Kubecek, netfilter-devel, coreteam,
netdev
In-Reply-To: <20180518092756.odlyvxcpgbuistqq@breakpoint.cc>
On Fri, May 18, 2018 at 11:27:56AM +0200, Florian Westphal wrote:
> Greg Kroah-Hartman <gregkh@linuxfoundation.org> wrote:
> > On Thu, May 17, 2018 at 12:42:00PM +0200, Jan Engelhardt wrote:
> > >
> > > On Thursday 2018-05-17 12:09, Greg Kroah-Hartman wrote:
> > > >> > --- a/net/netfilter/x_tables.c
> > > >> > +++ b/net/netfilter/x_tables.c
> > > >> > @@ -1183,11 +1183,10 @@ struct xt_table_info *xt_alloc_table_info(unsigned int size)
> > > >> > * than shoot all processes down before realizing there is nothing
> > > >> > * more to reclaim.
> > > >> > */
> > > >> > - info = kvmalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> > + info = kvzalloc(sz, GFP_KERNEL | __GFP_NORETRY);
> > > >> > if (!info)
> > > >> > return NULL;
> > > >>
> > > >> I am curious, what particular path does not later overwrite the whole zone ?
> > > >
> > > >In do_ipt_get_ctl, the IPT_SO_GET_ENTRIES: option uses a len value that
> > > >can be larger than the size of the structure itself.
> > > >
> > > >Then the data is copied to userspace in copy_entries_to_user() for ipv4
> > > >and v6, and that's where the "bad data"
> > >
> > > If the kernel incorrectly copies more bytes than it should, isn't that
> > > a sign that may be going going past the end of the info buffer?
> > > (And thus, zeroing won't truly fix the issue)
> >
> > No, the buffer size is correct, we just aren't filling up the whole
> > buffer as the data requested is smaller than the buffer size.
>
> I have no objections to the patch but I'd like to understand what
> problem its fixing.
>
> Normal pattern is:
> newinfo = xt_alloc_table_info(tmp.size);
> copy_from_user(newinfo->entries, user + sizeof(tmp), tmp.size);
>
> So inital value of the rule blob area should not matter.
>
> Furthermore, when copying the rule blob back to userspace,
> the kernel is not supposed to copy any padding back to userspace either,
> since commit f32815d21d4d8287336fb9cef4d2d9e0866214c2 only the
> user-relevant parts should be copied (some matches and targets allocate
> kernel-private data such as pointers, and we did use to leak such pointer
> values back to userspace).
Ah, fun, commit f32815d21d4d ("xtables: add xt_match, xt_target and data
copy_to_user functions") showed up in 4.11 and this was reported in 4.4 :(
However, the "bad" code path seems to be from the IPT_SO_GET_ENTRIES
request, which does not look to use the new functions provided in
f32815d21d4d, or am I mistaken?
Let me go work on a reproducer for this to make it a lot more obvious
what is happening, and if it is still even an issue after f32815d21d4d
is applied to a kernel. Sorry for not providing that in the first
place...
thanks,
greg k-h
^ permalink raw reply
* Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter
From: Kevin Darbyshire-Bryant @ 2018-05-18 11:18 UTC (permalink / raw)
To: Cong Wang
Cc: Toke Høiland-Jørgensen, Cake List,
Linux Kernel Network Developers, Eric Dumazet
In-Reply-To: <CAM_iQpUA1cEx5X3mD9Zhs4YqON5Q_SL1T=EjOd2k6Zbj6vzVyA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]
> On 18 May 2018, at 05:27, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>
> On Thu, May 17, 2018 at 4:23 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>> Eric Dumazet <eric.dumazet@gmail.com> writes:
>>
>>> On 05/16/2018 01:29 PM, Toke Høiland-Jørgensen wrote:
>>>> The ACK filter is an optional feature of CAKE which is designed to improve
>>>> performance on links with very asymmetrical rate limits. On such links
>>>> (which are unfortunately quite prevalent, especially for DSL and cable
>>>> subscribers), the downstream throughput can be limited by the number of
>>>> ACKs capable of being transmitted in the *upstream* direction.
>>>>
>>>
>>> ...
>>>
>>>>
>>>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>>>> ---
>>>> net/sched/sch_cake.c | 260 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>>> 1 file changed, 258 insertions(+), 2 deletions(-)
>>>>
>>>>
>>>
>>> I have decided to implement ACK compression in TCP stack itself.
>>
>> Awesome! Will look forward to seeing that!
>
> +1
>
> It is really odd to put into a TC qdisc, TCP stack is a much better
> place.
Speaking as a user of cake’s ack filtering, although it may be an odd place, it is incredibly useful in my linux based home router middle box that usefully extracts extra usable bandwidth from my asymmetric link. And whilst ack compression/reduction/filtering call it what you will, will come to the linux TCP stack, as yet other OS stacks are less enlightened and benefit from the router’s tweaking/meddling/interference.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [Cake] [PATCH net-next v12 3/7] sch_cake: Add optional ACK filter
From: Sebastian Moeller @ 2018-05-18 11:23 UTC (permalink / raw)
To: Kevin Darbyshire-Bryant
Cc: Cong Wang, Cake List, Linux Kernel Network Developers,
Eric Dumazet
In-Reply-To: <05E1D675-B73B-4409-8991-EB89D5538EAB@darbyshire-bryant.me.uk>
Hi Kevin,
> On May 18, 2018, at 13:18, Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:
>
>
>
>> On 18 May 2018, at 05:27, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>
>> On Thu, May 17, 2018 at 4:23 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
>>> Eric Dumazet <eric.dumazet@gmail.com> writes:
>>>
>>>> On 05/16/2018 01:29 PM, Toke Høiland-Jørgensen wrote:
>>>>> The ACK filter is an optional feature of CAKE which is designed to improve
>>>>> performance on links with very asymmetrical rate limits. On such links
>>>>> (which are unfortunately quite prevalent, especially for DSL and cable
>>>>> subscribers), the downstream throughput can be limited by the number of
>>>>> ACKs capable of being transmitted in the *upstream* direction.
>>>>>
>>>>
>>>> ...
>>>>
>>>>>
>>>>> Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk>
>>>>> ---
>>>>> net/sched/sch_cake.c | 260 ++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>> 1 file changed, 258 insertions(+), 2 deletions(-)
>>>>>
>>>>>
>>>>
>>>> I have decided to implement ACK compression in TCP stack itself.
>>>
>>> Awesome! Will look forward to seeing that!
>>
>> +1
>>
>> It is really odd to put into a TC qdisc, TCP stack is a much better
>> place.
>
> Speaking as a user of cake’s ack filtering, although it may be an odd place, it is incredibly useful in my linux based home router middle box that usefully extracts extra usable bandwidth from my asymmetric link. And whilst ack compression/reduction/filtering call it what you will, will come to the linux TCP stack, as yet other OS stacks are less enlightened and benefit from the router’s tweaking/meddling/interference.
I believe this is a good point, it is really the asymmetry of the link that makes ACK suppression more or less desirable, and it is quite helpful if the adaptation to that link only needs to be configured on one device. I think this is similar to applying MSS clamping on a router to account for say PPPoE overhead as compared to relaying on path MTU discovery or having to configure the MTU on all end-points.
Best Regards
>
>
> _______________________________________________
> Cake mailing list
> Cake@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake
^ permalink raw reply
* Re: [RFC v4 3/5] virtio_ring: add packed ring support
From: Tiwei Bie @ 2018-05-18 11:29 UTC (permalink / raw)
To: Jason Wang; +Cc: mst, virtualization, linux-kernel, netdev, wexu, jfreimann
In-Reply-To: <bc38e5a1-e920-7055-dc22-49ac98455257@redhat.com>
On Thu, May 17, 2018 at 08:01:52PM +0800, Jason Wang wrote:
> On 2018年05月16日 22:33, Tiwei Bie wrote:
> > On Wed, May 16, 2018 at 10:05:44PM +0800, Jason Wang wrote:
> > > On 2018年05月16日 21:45, Tiwei Bie wrote:
> > > > On Wed, May 16, 2018 at 08:51:43PM +0800, Jason Wang wrote:
> > > > > On 2018年05月16日 20:39, Tiwei Bie wrote:
> > > > > > On Wed, May 16, 2018 at 07:50:16PM +0800, Jason Wang wrote:
> > > > > > > On 2018年05月16日 16:37, Tiwei Bie wrote:
> > [...]
> > > > > > > > +static void detach_buf_packed(struct vring_virtqueue *vq, unsigned int head,
> > > > > > > > + unsigned int id, void **ctx)
> > > > > > > > +{
> > > > > > > > + struct vring_packed_desc *desc;
> > > > > > > > + unsigned int i, j;
> > > > > > > > +
> > > > > > > > + /* Clear data ptr. */
> > > > > > > > + vq->desc_state[id].data = NULL;
> > > > > > > > +
> > > > > > > > + i = head;
> > > > > > > > +
> > > > > > > > + for (j = 0; j < vq->desc_state[id].num; j++) {
> > > > > > > > + desc = &vq->vring_packed.desc[i];
> > > > > > > > + vring_unmap_one_packed(vq, desc);
> > > > > > > As mentioned in previous discussion, this probably won't work for the case
> > > > > > > of out of order completion since it depends on the information in the
> > > > > > > descriptor ring. We probably need to extend ctx to record such information.
> > > > > > Above code doesn't depend on the information in the descriptor
> > > > > > ring. The vq->desc_state[] is the extended ctx.
> > > > > >
> > > > > > Best regards,
> > > > > > Tiwei Bie
> > > > > Yes, but desc is a pointer to descriptor ring I think so
> > > > > vring_unmap_one_packed() still depends on the content of descriptor ring?
> > > > >
> > > > I got your point now. I think it makes sense to reserve
> > > > the bits of the addr field. Driver shouldn't try to get
> > > > addrs from the descriptors when cleanup the descriptors
> > > > no matter whether we support out-of-order or not.
> > > Maybe I was wrong, but I remember spec mentioned something like this.
> > You're right. Spec mentioned this. I was just repeating
> > the spec to emphasize that it does make sense. :)
> >
> > > > But combining it with the out-of-order support, it will
> > > > mean that the driver still needs to maintain a desc/ctx
> > > > list that is very similar to the desc ring in the split
> > > > ring. I'm not quite sure whether it's something we want.
> > > > If it is true, I'll do it. So do you think we also want
> > > > to maintain such a desc/ctx list for packed ring?
> > > To make it work for OOO backends I think we need something like this
> > > (hardware NIC drivers are usually have something like this).
> > Which hardware NIC drivers have this?
>
> It's quite common I think, e.g driver track e.g dma addr and page frag
> somewhere. e.g the ring->rx_info in mlx4 driver.
It seems that I had a misunderstanding on your
previous comments. I know it's quite common for
drivers to track e.g. DMA addrs somewhere (and
I think one reason behind this is that they want
to reuse the bits of addr field). But tracking
addrs somewhere doesn't means supporting OOO.
I thought you were saying it's quite common for
hardware NIC drivers to support OOO (i.e. NICs
will return the descriptors OOO):
I'm not familiar with mlx4, maybe I'm wrong.
I just had a quick glance. And I found below
comments in mlx4_en_process_rx_cq():
```
/* We assume a 1:1 mapping between CQEs and Rx descriptors, so Rx
* descriptor offset can be deduced from the CQE index instead of
* reading 'cqe->index' */
index = cq->mcq.cons_index & ring->size_mask;
cqe = mlx4_en_get_cqe(cq->buf, index, priv->cqe_size) + factor;
```
It seems that although they have a completion
queue, they are still using the ring in order.
I guess maybe storage device may want OOO.
Best regards,
Tiwei Bie
>
> Thanks
>
> >
> > > Not for the patch, but it looks like having a OUT_OF_ORDER feature bit is
> > > much more simpler to be started with.
> > +1
> >
> > Best regards,
> > Tiwei Bie
>
^ permalink raw reply
* Re: [net-next 3/6] ixgbe: release lock for the duration of ixgbe_suspend_close()
From: Pavel Tatashin @ 2018-05-18 11:37 UTC (permalink / raw)
To: Sergei Shtylyov, Jeff Kirsher, davem; +Cc: netdev, nhorman, sassmann, jogreene
In-Reply-To: <c9fbb37d-9213-ff72-aa8c-b998f0b19490@cogentembedded.com>
* parallelized this function, so drop lock for the
>
> Parallelizing? Else the sentence doesn't parse for me. :-)
Hi Sergei,
In a separate series I parallelized device_shutdown(), see:
http://lkml.kernel.org/r/20180516024004.28977-1-pasha.tatashin@oracle.com
But, this particular patch should be dropped, as discussed in this thread:
http://lkml.kernel.org/r/20180503035931.22439-2-pasha.tatashin@oracle.com
Alexander Duyck, made a point that a generic RTNL scalability fix should be done. This particular patch might introduce a race, since it relies on assumption that RTNL is not needed in this place because ixgbe_close() does not have it, but Alexander Duyck, says that the callers of ixgbe_close() are assumed to own this lock.
Thank you,
Pavel
^ permalink raw reply
* [PATCH net] sock_diag: fix use-after-free read in __sk_free
From: Eric Dumazet @ 2018-05-18 11:47 UTC (permalink / raw)
To: David S . Miller; +Cc: netdev, Eric Dumazet, Eric Dumazet, Craig Gallek
We must not call sock_diag_has_destroy_listeners(sk) on a socket
that has no reference on net structure.
BUG: KASAN: use-after-free in sock_diag_has_destroy_listeners include/linux/sock_diag.h:75 [inline]
BUG: KASAN: use-after-free in __sk_free+0x329/0x340 net/core/sock.c:1609
Read of size 8 at addr ffff88018a02e3a0 by task swapper/1/0
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.17.0-rc5+ #54
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1b9/0x294 lib/dump_stack.c:113
print_address_description+0x6c/0x20b mm/kasan/report.c:256
kasan_report_error mm/kasan/report.c:354 [inline]
kasan_report.cold.7+0x242/0x2fe mm/kasan/report.c:412
__asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:433
sock_diag_has_destroy_listeners include/linux/sock_diag.h:75 [inline]
__sk_free+0x329/0x340 net/core/sock.c:1609
sk_free+0x42/0x50 net/core/sock.c:1623
sock_put include/net/sock.h:1664 [inline]
reqsk_free include/net/request_sock.h:116 [inline]
reqsk_put include/net/request_sock.h:124 [inline]
inet_csk_reqsk_queue_drop_and_put net/ipv4/inet_connection_sock.c:672 [inline]
reqsk_timer_handler+0xe27/0x10e0 net/ipv4/inet_connection_sock.c:739
call_timer_fn+0x230/0x940 kernel/time/timer.c:1326
expire_timers kernel/time/timer.c:1363 [inline]
__run_timers+0x79e/0xc50 kernel/time/timer.c:1666
run_timer_softirq+0x4c/0x70 kernel/time/timer.c:1692
__do_softirq+0x2e0/0xaf5 kernel/softirq.c:285
invoke_softirq kernel/softirq.c:365 [inline]
irq_exit+0x1d1/0x200 kernel/softirq.c:405
exiting_irq arch/x86/include/asm/apic.h:525 [inline]
smp_apic_timer_interrupt+0x17e/0x710 arch/x86/kernel/apic/apic.c:1052
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
</IRQ>
RIP: 0010:native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
RSP: 0018:ffff8801d9ae7c38 EFLAGS: 00000282 ORIG_RAX: ffffffffffffff13
RAX: dffffc0000000000 RBX: 1ffff1003b35cf8a RCX: 0000000000000000
RDX: 1ffffffff11a30d0 RSI: 0000000000000001 RDI: ffffffff88d18680
RBP: ffff8801d9ae7c38 R08: ffffed003b5e46c3 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001
R13: ffff8801d9ae7cf0 R14: ffffffff897bef20 R15: 0000000000000000
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0xc2/0x440 arch/x86/kernel/process.c:354
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:345
default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x395/0x560 kernel/sched/idle.c:262
cpu_startup_entry+0x104/0x120 kernel/sched/idle.c:368
start_secondary+0x426/0x5b0 arch/x86/kernel/smpboot.c:269
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
Allocated by task 4557:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
kasan_kmalloc+0xc4/0xe0 mm/kasan/kasan.c:553
kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:490
kmem_cache_alloc+0x12e/0x760 mm/slab.c:3554
kmem_cache_zalloc include/linux/slab.h:691 [inline]
net_alloc net/core/net_namespace.c:383 [inline]
copy_net_ns+0x159/0x4c0 net/core/net_namespace.c:423
create_new_namespaces+0x69d/0x8f0 kernel/nsproxy.c:107
unshare_nsproxy_namespaces+0xc3/0x1f0 kernel/nsproxy.c:206
ksys_unshare+0x708/0xf90 kernel/fork.c:2408
__do_sys_unshare kernel/fork.c:2476 [inline]
__se_sys_unshare kernel/fork.c:2474 [inline]
__x64_sys_unshare+0x31/0x40 kernel/fork.c:2474
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
Freed by task 69:
save_stack+0x43/0xd0 mm/kasan/kasan.c:448
set_track mm/kasan/kasan.c:460 [inline]
__kasan_slab_free+0x11a/0x170 mm/kasan/kasan.c:521
kasan_slab_free+0xe/0x10 mm/kasan/kasan.c:528
__cache_free mm/slab.c:3498 [inline]
kmem_cache_free+0x86/0x2d0 mm/slab.c:3756
net_free net/core/net_namespace.c:399 [inline]
net_drop_ns.part.14+0x11a/0x130 net/core/net_namespace.c:406
net_drop_ns net/core/net_namespace.c:405 [inline]
cleanup_net+0x6a1/0xb20 net/core/net_namespace.c:541
process_one_work+0xc1e/0x1b50 kernel/workqueue.c:2145
worker_thread+0x1cc/0x1440 kernel/workqueue.c:2279
kthread+0x345/0x410 kernel/kthread.c:240
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
The buggy address belongs to the object at ffff88018a02c140
which belongs to the cache net_namespace of size 8832
The buggy address is located 8800 bytes inside of
8832-byte region [ffff88018a02c140, ffff88018a02e3c0)
The buggy address belongs to the page:
page:ffffea0006280b00 count:1 mapcount:0 mapping:ffff88018a02c140 index:0x0 compound_mapcount: 0
flags: 0x2fffc0000008100(slab|head)
raw: 02fffc0000008100 ffff88018a02c140 0000000000000000 0000000100000001
raw: ffffea00062a1320 ffffea0006268020 ffff8801d9bdde40 0000000000000000
page dumped because: kasan: bad access detected
Fixes: b922622ec6ef ("sock_diag: don't broadcast kernel sockets")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Craig Gallek <kraig@google.com>
Reported-by: syzbot <syzkaller@googlegroups.com>
---
net/core/sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/sock.c b/net/core/sock.c
index 6444525f610cf8039516744ad26aec58485b9b8a..3b6d02854e57736254975963c45369515f369ddc 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -1606,7 +1606,7 @@ static void __sk_free(struct sock *sk)
if (likely(sk->sk_net_refcnt))
sock_inuse_add(sock_net(sk), -1);
- if (unlikely(sock_diag_has_destroy_listeners(sk) && sk->sk_net_refcnt))
+ if (unlikely(sk->sk_net_refcnt && sock_diag_has_destroy_listeners(sk)))
sock_diag_broadcast_destroy(sk);
else
sk_destruct(sk);
--
2.17.0.441.gb46fe60e1d-goog
^ permalink raw reply related
* [PATCH net-next] tipc: eliminate complaint of KMSAN uninit-value in tipc_conn_rcv_sub
From: Ying Xue @ 2018-05-18 11:50 UTC (permalink / raw)
To: netdev; +Cc: tipc-discussion, syzkaller-bugs, davem
As variable s of struct tipc_subscr type is not initialized
in tipc_conn_rcv_from_sock() before it is used in tipc_conn_rcv_sub(),
KMSAN reported the following uninit-value type complaint:
==================================================================
BUG: KMSAN: uninit-value in tipc_conn_rcv_sub+0x184/0x950
net/tipc/topsrv.c:373
CPU: 0 PID: 66 Comm: kworker/u4:4 Not tainted 4.17.0-rc3+ #88
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: tipc_rcv tipc_conn_recv_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
kmsan_report+0x142/0x240 mm/kmsan/kmsan.c:1067
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
tipc_conn_rcv_sub+0x184/0x950 net/tipc/topsrv.c:373
tipc_conn_rcv_from_sock net/tipc/topsrv.c:409 [inline]
tipc_conn_recv_work+0x3cd/0x560 net/tipc/topsrv.c:424
process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
kthread+0x539/0x720 kernel/kthread.c:239
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
Local variable description: ----s.i@tipc_conn_recv_work
Variable was created at:
tipc_conn_recv_work+0x65/0x560 net/tipc/topsrv.c:419
process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
==================================================================
Kernel panic - not syncing: panic_on_warn set ...
CPU: 0 PID: 66 Comm: kworker/u4:4 Tainted: G B 4.17.0-rc3+
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: tipc_rcv tipc_conn_recv_work
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x185/0x1d0 lib/dump_stack.c:113
panic+0x39d/0x940 kernel/panic.c:184
kmsan_report+0x238/0x240 mm/kmsan/kmsan.c:1083
__msan_warning_32+0x6c/0xb0 mm/kmsan/kmsan_instr.c:683
tipc_conn_rcv_sub+0x184/0x950 net/tipc/topsrv.c:373
tipc_conn_rcv_from_sock net/tipc/topsrv.c:409 [inline]
tipc_conn_recv_work+0x3cd/0x560 net/tipc/topsrv.c:424
process_one_work+0x12c6/0x1f60 kernel/workqueue.c:2145
worker_thread+0x113c/0x24f0 kernel/workqueue.c:2279
kthread+0x539/0x720 kernel/kthread.c:239
ret_from_fork+0x35/0x40 arch/x86/entry/entry_64.S:412
Dumping ftrace buffer:
(ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
Reported-by: syzbot+8951a3065ee7fd6d6e23@syzkaller.appspotmail.com
Signed-off-by: Ying Xue <ying.xue@windriver.com>
---
net/tipc/topsrv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/tipc/topsrv.c b/net/tipc/topsrv.c
index c8e34ef..fe47a62 100644
--- a/net/tipc/topsrv.c
+++ b/net/tipc/topsrv.c
@@ -397,6 +397,7 @@ static int tipc_conn_rcv_from_sock(struct tipc_conn *con)
struct kvec iov;
int ret;
+ memset(&s, 0, sizeof(s));
iov.iov_base = &s;
iov.iov_len = sizeof(s);
msg.msg_name = NULL;
--
2.7.4
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
^ permalink raw reply related
* [PATCH bpf-next 0/4] AF_XDP follow-up patches, cosmetics
From: Björn Töpel @ 2018-05-18 12:00 UTC (permalink / raw)
To: magnus.karlsson, magnus.karlsson, ast, daniel, netdev
Cc: Björn Töpel
From: Björn Töpel <bjorn.topel@intel.com>
This series contain "cosmetics only" follow-up patches for AF_XDP.
Thanks to Daniel for suggesting them!
Björn Töpel (4):
xsk: clean up SPDX headers
xsk: remove newline at end of file
xsk: fixed some cases of unnecessary parentheses
xsk: proper '=' alignment
include/net/xdp_sock.h | 13 ++-----------
include/uapi/linux/if_xdp.h | 13 ++-----------
kernel/bpf/xskmap.c | 9 ---------
net/xdp/Makefile | 1 -
net/xdp/xdp_umem.c | 13 ++-----------
net/xdp/xdp_umem.h | 13 ++-----------
net/xdp/xdp_umem_props.h | 13 ++-----------
net/xdp/xsk.c | 45 ++++++++++++++++++---------------------------
net/xdp/xsk_queue.c | 12 +-----------
net/xdp/xsk_queue.h | 17 ++++-------------
samples/bpf/xdpsock_user.c | 12 +-----------
11 files changed, 34 insertions(+), 127 deletions(-)
--
2.14.1
^ 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