* Re: [RFC PATCH net-next V2 6/6] virtio-net: support XDP rx handler
From: Jesper Dangaard Brouer @ 2018-08-14 9:22 UTC (permalink / raw)
To: Jason Wang; +Cc: netdev, linux-kernel, ast, daniel, mst
In-Reply-To: <1534130250-5302-7-git-send-email-jasowang@redhat.com>
On Mon, 13 Aug 2018 11:17:30 +0800
Jason Wang <jasowang@redhat.com> wrote:
> This patch tries to add the support of XDP rx handler to
> virtio-net. This is straight-forward, just call xdp_do_pass() and
> behave depends on its return value.
>
> Test was done by using XDP_DROP (xdp1) for macvlan on top of
> virtio-net. PPS of SKB mode was ~1.2Mpps while PPS of native XDP mode
> was ~2.2Mpps. About 83% improvement was measured.
I'm not convinced...
Why are you not using XDP_REDIRECT, which is already implemented in
receive_mergeable (which you modify below).
The macvlan driver just need to implement ndo_xdp_xmit(), and then you
can redirect (with XDP prog from physical driver into the guest). It
should be much faster...
> Notes: for RFC, only mergeable buffer case was implemented.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/virtio_net.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 62311dd..1e22ad9 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -777,6 +777,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> rcu_read_lock();
> xdp_prog = rcu_dereference(rq->xdp_prog);
> if (xdp_prog) {
> + rx_xdp_handler_result_t ret;
> struct xdp_frame *xdpf;
> struct page *xdp_page;
> struct xdp_buff xdp;
> @@ -825,6 +826,15 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
>
> switch (act) {
> case XDP_PASS:
> + ret = xdp_do_pass(&xdp);
> + if (ret == RX_XDP_HANDLER_DROP)
> + goto drop;
> + if (ret != RX_XDP_HANDLER_FALLBACK) {
> + if (unlikely(xdp_page != page))
> + put_page(page);
> + rcu_read_unlock();
> + goto xdp_xmit;
> + }
> /* recalculate offset to account for any header
> * adjustments. Note other cases do not build an
> * skb and avoid using offset
> @@ -881,6 +891,7 @@ static struct sk_buff *receive_mergeable(struct net_device *dev,
> case XDP_ABORTED:
> trace_xdp_exception(vi->dev, xdp_prog, act);
> /* fall through */
> +drop:
> case XDP_DROP:
> if (unlikely(xdp_page != page))
> __free_pages(xdp_page, 0);
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [PATCH 1/1] NFC: Fix possible memory corruption when handling SHDLC I-Frame commands
From: Greg KH @ 2018-08-14 9:21 UTC (permalink / raw)
To: Suren Baghdasaryan
Cc: security, kdeus, Samuel Ortiz, David S. Miller, Allen Pais,
Kees Cook, linux-wireless, netdev, linux-kernel
In-Reply-To: <20180813223910.26276-1-surenb@google.com>
On Mon, Aug 13, 2018 at 03:39:08PM -0700, Suren Baghdasaryan wrote:
> When handling SHDLC I-Frame commands "pipe" field used for indexing
> into an array should be checked before usage. If left unchecked it
> might access memory outside of the array of size NFC_HCI_MAX_PIPES(127).
>
> Malformed NFC HCI frames could be injected by a malicious NFC device
> communicating with the device being attacked (remote attack vector),
> or even by an attacker with physical access to the I2C bus such that
> they could influence the data transfers on that bus (local attack vector).
> skb->data is controlled by the attacker and has only been sanitized in
> the most trivial ways (CRC check), therefore we can consider the
> create_info struct and all of its members to tainted. 'create_info->pipe'
> with max value of 255 (uint8) is used to take an offset of the
> hdev->pipes array of 127 elements which can lead to OOB write.
>
> Suggested-by: Kevin Deus <kdeus@google.com>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* [PATCH] rds: fix building with IPV6=m
From: Arnd Bergmann @ 2018-08-14 9:07 UTC (permalink / raw)
To: Santosh Shilimkar, David S. Miller
Cc: Arnd Bergmann, Anders Roxell, Greg Thelen, Ka-Cheong Poon,
Stephen Hemminger, netdev, linux-rdma, rds-devel, linux-kernel
When CONFIG_RDS_TCP is built-in and CONFIG_IPV6 is a loadable
module, we get a link error agains the modular ipv6_chk_addr()
function:
net/rds/tcp.o: In function `rds_tcp_laddr_check':
tcp.c:(.text+0x3b2): undefined reference to `ipv6_chk_addr'
This adds back a dependency that forces RDS_TCP to also be
a loadable module when IPV6 is one.
Fixes: e65d4d96334e ("rds: Remove IPv6 dependency")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
net/rds/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/rds/Kconfig b/net/rds/Kconfig
index 41f75563b54b..01b3bd6a3708 100644
--- a/net/rds/Kconfig
+++ b/net/rds/Kconfig
@@ -16,6 +16,7 @@ config RDS_RDMA
config RDS_TCP
tristate "RDS over TCP"
depends on RDS
+ depends on IPV6 || !IPV6
---help---
Allow RDS to use TCP as a transport.
This transport does not support RDMA operations.
--
2.18.0
^ permalink raw reply related
* Re: [PATCH next-queue 3/8] ixgbe: add VF ipsec management
From: kbuild test robot @ 2018-08-14 5:31 UTC (permalink / raw)
To: Shannon Nelson
Cc: kbuild-all, intel-wired-lan, jeffrey.t.kirsher, steffen.klassert,
netdev
In-Reply-To: <1534185825-12451-4-git-send-email-shannon.nelson@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 4616 bytes --]
Hi Shannon,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on jkirsher-next-queue/dev-queue]
[also build test ERROR on v4.18 next-20180813]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Shannon-Nelson/ixgbe-ixgbevf-IPsec-offload-support-for-VFs/20180814-074800
base: https://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/next-queue.git dev-queue
config: x86_64-randconfig-v0-08131550 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.o: In function `ixgbe_ipsec_vf_add_sa':
>> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c:917: undefined reference to `xfrm_aead_get_byname'
make[1]: *** [vmlinux] Error 1
make[1]: Target '_all' not remade because of errors.
vim +917 drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
862
863 /**
864 * ixgbe_ipsec_vf_add_sa - translate VF request to SA add
865 * @adapter: board private structure
866 * @msgbuf: The message buffer
867 * @vf: the VF index
868 *
869 * Make up a new xs and algorithm info from the data sent by the VF.
870 * We only need to sketch in just enough to set up the HW offload.
871 * Put the resulting offload_handle into the return message to the VF.
872 *
873 * Returns 0 or error value
874 **/
875 int ixgbe_ipsec_vf_add_sa(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
876 {
877 struct ixgbe_ipsec *ipsec = adapter->ipsec;
878 struct xfrm_algo_desc *algo;
879 struct sa_mbx_msg *sam;
880 struct xfrm_state *xs;
881 size_t aead_len;
882 u16 sa_idx;
883 u32 pfsa;
884 int err;
885
886 sam = (struct sa_mbx_msg *)(&msgbuf[1]);
887 if (!adapter->vfinfo[vf].trusted) {
888 e_warn(drv, "VF %d attempted to add an IPsec SA\n", vf);
889 err = -EACCES;
890 goto err_out;
891 }
892
893 /* Tx IPsec offload doesn't seem to work on this
894 * device, so block these requests for now.
895 */
896 if (!(sam->flags & XFRM_OFFLOAD_INBOUND)) {
897 err = -ENXIO;
898 goto err_out;
899 }
900
901 xs = kzalloc(sizeof(*xs), GFP_KERNEL);
902 if (unlikely(!xs)) {
903 err = -ENOMEM;
904 goto err_out;
905 }
906
907 xs->xso.flags = sam->flags;
908 xs->id.spi = sam->spi;
909 xs->id.proto = sam->proto;
910 xs->props.family = sam->family;
911 if (xs->props.family == AF_INET6)
912 memcpy(&xs->id.daddr.a6, sam->addr, sizeof(xs->id.daddr.a6));
913 else
914 memcpy(&xs->id.daddr.a4, sam->addr, sizeof(xs->id.daddr.a4));
915 xs->xso.dev = adapter->netdev;
916
> 917 algo = xfrm_aead_get_byname(aes_gcm_name, IXGBE_IPSEC_AUTH_BITS, 1);
918 if (unlikely(!algo)) {
919 err = -ENOENT;
920 goto err_xs;
921 }
922
923 aead_len = sizeof(*xs->aead) + IXGBE_IPSEC_KEY_BITS / 8;
924 xs->aead = kzalloc(aead_len, GFP_KERNEL);
925 if (unlikely(!xs->aead)) {
926 err = -ENOMEM;
927 goto err_xs;
928 }
929
930 xs->props.ealgo = algo->desc.sadb_alg_id;
931 xs->geniv = algo->uinfo.aead.geniv;
932 xs->aead->alg_icv_len = IXGBE_IPSEC_AUTH_BITS;
933 xs->aead->alg_key_len = IXGBE_IPSEC_KEY_BITS;
934 memcpy(xs->aead->alg_key, sam->key, sizeof(sam->key));
935 memcpy(xs->aead->alg_name, aes_gcm_name, sizeof(aes_gcm_name));
936
937 /* set up the HW offload */
938 err = ixgbe_ipsec_add_sa(xs);
939 if (err)
940 goto err_aead;
941
942 pfsa = xs->xso.offload_handle;
943 if (pfsa < IXGBE_IPSEC_BASE_TX_INDEX) {
944 sa_idx = pfsa - IXGBE_IPSEC_BASE_RX_INDEX;
945 ipsec->rx_tbl[sa_idx].vf = vf;
946 ipsec->rx_tbl[sa_idx].mode |= IXGBE_RXTXMOD_VF;
947 } else {
948 sa_idx = pfsa - IXGBE_IPSEC_BASE_TX_INDEX;
949 ipsec->tx_tbl[sa_idx].vf = vf;
950 ipsec->tx_tbl[sa_idx].mode |= IXGBE_RXTXMOD_VF;
951 }
952
953 msgbuf[1] = xs->xso.offload_handle;
954
955 return 0;
956
957 err_aead:
958 memset(xs->aead, 0, sizeof(*xs->aead));
959 kfree(xs->aead);
960 err_xs:
961 memset(xs, 0, sizeof(*xs));
962 kfree(xs);
963 err_out:
964 msgbuf[1] = err;
965 return err;
966 }
967
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 32985 bytes --]
^ permalink raw reply
* Re: [RFC PATCH net-next V2 0/6] XDP rx handler
From: Jason Wang @ 2018-08-14 7:59 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: netdev, linux-kernel, ast, daniel, jbrouer, mst
In-Reply-To: <20180814003253.fkgl6lyklc7fclvq@ast-mbp>
On 2018年08月14日 08:32, Alexei Starovoitov wrote:
> On Mon, Aug 13, 2018 at 11:17:24AM +0800, Jason Wang wrote:
>> Hi:
>>
>> This series tries to implement XDP support for rx hanlder. This would
>> be useful for doing native XDP on stacked device like macvlan, bridge
>> or even bond.
>>
>> The idea is simple, let stacked device register a XDP rx handler. And
>> when driver return XDP_PASS, it will call a new helper xdp_do_pass()
>> which will try to pass XDP buff to XDP rx handler directly. XDP rx
>> handler may then decide how to proceed, it could consume the buff, ask
>> driver to drop the packet or ask the driver to fallback to normal skb
>> path.
>>
>> A sample XDP rx handler was implemented for macvlan. And virtio-net
>> (mergeable buffer case) was converted to call xdp_do_pass() as an
>> example. For ease comparision, generic XDP support for rx handler was
>> also implemented.
>>
>> Compared to skb mode XDP on macvlan, native XDP on macvlan (XDP_DROP)
>> shows about 83% improvement.
> I'm missing the motiviation for this.
> It seems performance of such solution is ~1M packet per second.
Notice it was measured by virtio-net which is kind of slow.
> What would be a real life use case for such feature ?
I had another run on top of 10G mlx4 and macvlan:
XDP_DROP on mlx4: 14.0Mpps
XDP_DROP on macvlan: 10.05Mpps
Perf shows macvlan_hash_lookup() and indirect call to
macvlan_handle_xdp() are the reasons for the number drop. I think the
numbers are acceptable. And we could try more optimizations on top.
So here's real life use case is trying to have an fast XDP path for rx
handler based device:
- For containers, we can run XDP for macvlan (~70% of wire speed). This
allows a container specific policy.
- For VM, we can implement macvtap XDP rx handler on top. This allow us
to forward packet to VM without building skb in the setup of macvtap.
- The idea could be used by other rx handler based device like bridge,
we may have a XDP fast forwarding path for bridge.
>
> Another concern is that XDP users expect to get line rate performance
> and native XDP delivers it. 'generic XDP' is a fallback only
> mechanism to operate on NICs that don't have native XDP yet.
So I can replace generic XDP TX routine with a native one for macvlan.
> Toshiaki's veth XDP work fits XDP philosophy and allows
> high speed networking to be done inside containers after veth.
> It's trying to get to line rate inside container.
This is one of the goal of this series as well. I agree veth XDP work
looks pretty fine, but it only work for a specific setup I believe since
it depends on XDP_REDIRECT which is supported by few drivers (and
there's no VF driver support). And in order to make it work for a end
user, the XDP program still need logic like hash(map) lookup to
determine the destination veth.
> This XDP rx handler stuff is destined to stay at 1Mpps speeds forever
> and the users will get confused with forever slow modes of XDP.
>
> Please explain the problem you're trying to solve.
> "look, here I can to XDP on top of macvlan" is not an explanation of the problem.
>
Thanks
^ permalink raw reply
* Re: lock recursion - was: Re: [4.18 rc7] BUG: sleeping function called from invalid context at mm/slab.h:421
From: Mikhail Gavrilov @ 2018-08-14 5:10 UTC (permalink / raw)
To: pmladek
Cc: vbabka, davem, marcel, johan.hedberg, linux-bluetooth, netdev,
linux-mm, rostedt, sergey.senozhatsky, peterz
In-Reply-To: <20180808113615.qzdzifpkmt5yktbx@pathway.suse.cz>
That's all?
Issue happens everytime when I paired computer with bluetooth peripherals.
And this is not dependent on the bluetooth adapter used. I see this on
three different systems.
--
Best Regards,
Mike Gavrilov.
On Wed, 8 Aug 2018 at 16:36, Petr Mladek <pmladek@suse.com> wrote:
>
> On Wed 2018-08-08 11:05:00, Vlastimil Babka wrote:
> > On 08/08/2018 11:01 AM, Vlastimil Babka wrote:
> > > fbcon_startup() calls kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL) so
> > > it tells slab it can sleep. The problem must be higher in the stack,
> > > CCing printk people.
> >
> > Uh just noticed there was also attached dmesg which my reply converted
> > to inline. The first problem there is a lockdep splat.
>
> The lockdep splat might eventually be a valid issue (recursive lock) in the
> networking code. But it seems to be unrelated to the later problems
> with sleeping in fbcon_startup().
>
> Adding networking people into CC. Please, find below the relevant part
> from the dmesg. The full log can be found in the original message at
> https://marc.info/?l=linux-mm&m=153370024009996&w=2
>
> Lock recursion in bluetooth code:
>
> [ 32.050660] Bluetooth: RFCOMM TTY layer initialized
> [ 32.050675] Bluetooth: RFCOMM socket layer initialized
> [ 32.050719] Bluetooth: RFCOMM ver 1.11
> [ 34.413359] fuse init (API version 7.27)
> [ 40.562871] rfkill: input handler disabled
> [ 42.272301] pool (2344) used greatest stack depth: 11320 bytes left
> [ 42.701283] ISO 9660 Extensions: Microsoft Joliet Level 3
> [ 42.704062] ISO 9660 Extensions: Microsoft Joliet Level 3
> [ 42.710375] ISO 9660 Extensions: RRIP_1991A
> [ 64.930766] tracker-extract (2229) used greatest stack depth: 11176 bytes left
> [ 465.911281] TaskSchedulerFo (3362) used greatest stack depth: 11112 bytes left
> [ 491.743600] TaskSchedulerFo (3364) used greatest stack depth: 11032 bytes left
> [ 507.733884] nf_conntrack: default automatic helper assignment has been turned off \
> for security reasons and CT-based firewall rule not found. Use the iptables CT \
> target to attach helpers instead. [ 660.384586] kworker/dying (155) used greatest \
> stack depth: 10888 bytes left [ 699.910094] device enp2s0 entered promiscuous mode
> [ 1098.658964] kworker/dying (7) used greatest stack depth: 10712 bytes left
> [ 1843.488301] perf: interrupt took too long (2510 > 2500), lowering \
> kernel.perf_event_max_sample_rate to 79000 [ 2819.896469] perf: interrupt took too \
> long (3138 > 3137), lowering kernel.perf_event_max_sample_rate to 63000 [ \
> 6120.247124] perf: interrupt took too long (3923 > 3922), lowering \
> kernel.perf_event_max_sample_rate to 50000
>
> [ 6829.212232] ============================================
> [ 6829.212234] WARNING: possible recursive locking detected
> [ 6829.212236] 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 Not tainted
> [ 6829.212237] --------------------------------------------
> [ 6829.212239] kworker/u17:2/28441 is trying to acquire lock:
> [ 6829.212242] 000000004025b723 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: \
> bt_accept_enqueue+0x3c/0xb0 [bluetooth] [ 6829.212260]
> but task is already holding lock:
> [ 6829.212262] 000000004cb71eef (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: \
> l2cap_sock_new_connection_cb+0x18/0xa0 [bluetooth] [ 6829.212278]
> other info that might help us debug this:
> [ 6829.212279] Possible unsafe locking scenario:
>
> [ 6829.212281] CPU0
> [ 6829.212282] ----
> [ 6829.212284] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
> [ 6829.212286] lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP);
> [ 6829.212288]
> *** DEADLOCK ***
>
> [ 6829.212290] May be due to missing lock nesting notation
>
> [ 6829.212293] 5 locks held by kworker/u17:2/28441:
> [ 6829.212294] #0: 000000009af6a4dc ((wq_completion)"%s"hdev->name#2){+.+.}, at: \
> process_one_work+0x1f3/0x650 [ 6829.212301] #1: 000000006f7488f4 \
> ((work_completion)(&hdev->rx_work)){+.+.}, at: process_one_work+0x1f3/0x650 [ \
> 6829.212306] #2: 000000003dba8333 (&conn->chan_lock){+.+.}, at: \
> l2cap_connect+0x8f/0x5a0 [bluetooth] [ 6829.212321] #3: 00000000aaa813b9 \
> (&chan->lock/2){+.+.}, at: l2cap_connect+0xa9/0x5a0 [bluetooth] [ 6829.212335] #4: \
> 000000004cb71eef (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}, at: \
> l2cap_sock_new_connection_cb+0x18/0xa0 [bluetooth] [ 6829.212350]
> stack backtrace:
> [ 6829.212354] CPU: 6 PID: 28441 Comm: kworker/u17:2 Not tainted \
> 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 [ 6829.212355] Hardware name: Gigabyte Technology \
> Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [ 6829.212365] Workqueue: hci0 \
> hci_rx_work [bluetooth] [ 6829.212367] Call Trace:
> [ 6829.212373] dump_stack+0x85/0xc0
> [ 6829.212377] __lock_acquire.cold.64+0x158/0x227
> [ 6829.212381] ? mark_held_locks+0x57/0x80
> [ 6829.212384] lock_acquire+0x9e/0x1b0
> [ 6829.212394] ? bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 6829.212398] lock_sock_nested+0x72/0xa0
> [ 6829.212407] ? bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 6829.212417] bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 6829.212429] l2cap_sock_new_connection_cb+0x5d/0xa0 [bluetooth]
> [ 6829.212441] l2cap_connect+0x110/0x5a0 [bluetooth]
> [ 6829.212454] ? l2cap_recv_frame+0x6d0/0x2cb0 [bluetooth]
> [ 6829.212458] ? __mutex_unlock_slowpath+0x4b/0x2b0
> [ 6829.212470] l2cap_recv_frame+0x6e8/0x2cb0 [bluetooth]
> [ 6829.212474] ? __mutex_unlock_slowpath+0x4b/0x2b0
> [ 6829.212484] hci_rx_work+0x1c6/0x5d0 [bluetooth]
> [ 6829.212488] process_one_work+0x27d/0x650
> [ 6829.212492] worker_thread+0x3c/0x390
> [ 6829.212494] ? process_one_work+0x650/0x650
> [ 6829.212498] kthread+0x120/0x140
> [ 6829.212501] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 6829.212504] ret_from_fork+0x3a/0x50
> [ 6829.285343] BUG: sleeping function called from invalid context at \
> net/core/sock.c:2833 [ 6829.285349] in_atomic(): 1, irqs_disabled(): 0, pid: 1743, \
> name: krfcommd [ 6829.285351] INFO: lockdep is turned off.
> [ 6829.285355] CPU: 6 PID: 1743 Comm: krfcommd Not tainted \
> 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 [ 6829.285358] Hardware name: Gigabyte Technology \
> Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [ 6829.285360] Call Trace:
> [ 6829.285368] dump_stack+0x85/0xc0
> [ 6829.285373] ___might_sleep.cold.72+0xac/0xbc
> [ 6829.285378] lock_sock_nested+0x29/0xa0
> [ 6829.285394] bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 6829.285401] rfcomm_connect_ind+0x21b/0x260 [rfcomm]
> [ 6829.285406] rfcomm_run+0x1611/0x1820 [rfcomm]
> [ 6829.285411] ? do_wait_intr_irq+0xb0/0xb0
> [ 6829.285416] ? rfcomm_check_accept+0x90/0x90 [rfcomm]
> [ 6829.285419] kthread+0x120/0x140
> [ 6829.285422] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 6829.285426] ret_from_fork+0x3a/0x50
> [ 6829.476282] input: 04:5D:4B:5F:34:57 as /devices/virtual/input/input35
> [ 7273.090391] show_signal_msg: 23 callbacks suppressed
> [ 7273.090393] CFileWriterThre[29422]: segfault at 7f078bfe7240 ip 00007f079137843c \
> sp 00007f078bb8dcf0 error 4 in steamclient.so[7f0790880000+14d2000] [ 7273.090404] \
> Code: 89 df ff d2 8b 45 00 83 f8 02 0f 84 9e 00 00 00 83 f8 03 0f 84 55 05 00 00 83 \
> f8 01 74 48 31 ed 4d 85 e4 74 11 48 85 db 74 0c <48> 8b 03 4c 89 e6 48 89 df ff 50 10 \
> 48 8b b4 24 e8 00 00 00 64 48 [ 7755.656023] rfkill: input handler enabled
> [ 7773.439895] rfkill: input handler disabled
> [ 8075.232946] BUG: sleeping function called from invalid context at \
> net/core/sock.c:2833 [ 8075.232951] in_atomic(): 1, irqs_disabled(): 0, pid: 1743, \
> name: krfcommd [ 8075.232952] INFO: lockdep is turned off.
> [ 8075.232956] CPU: 5 PID: 1743 Comm: krfcommd Tainted: G W \
> 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 [ 8075.232957] Hardware name: Gigabyte Technology \
> Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [ 8075.232959] Call Trace:
> [ 8075.232965] dump_stack+0x85/0xc0
> [ 8075.232969] ___might_sleep.cold.72+0xac/0xbc
> [ 8075.232973] lock_sock_nested+0x29/0xa0
> [ 8075.232987] bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [ 8075.232992] rfcomm_connect_ind+0x21b/0x260 [rfcomm]
> [ 8075.232997] rfcomm_run+0x1611/0x1820 [rfcomm]
> [ 8075.233001] ? do_wait_intr_irq+0xb0/0xb0
> [ 8075.233005] ? rfcomm_check_accept+0x90/0x90 [rfcomm]
> [ 8075.233008] kthread+0x120/0x140
> [ 8075.233011] ? kthread_create_worker_on_cpu+0x70/0x70
> [ 8075.233014] ret_from_fork+0x3a/0x50
> [ 8075.413187] input: 04:5D:4B:5F:34:57 as /devices/virtual/input/input36
> [13538.300352] steam[4385]: segfault at 0 ip 00000000eabc32d9 sp 00000000ffdca1b0 \
> error 4 in vgui2_s.so[eab26000+292000] [13538.300365] Code: 74 03 00 00 00 00 00 00 \
> c7 44 24 08 02 00 00 00 c7 44 24 04 10 00 00 00 c7 04 24 44 ac 00 00 e8 1d 40 fb ff \
> 89 86 74 03 00 00 <8b> 00 8b 78 10 e8 3d 1a fb ff 8b 86 74 03 00 00 dd 5c 24 04 89 04 \
> [14324.004275] pool[443]: segfault at 0 ip 00007f53e2399556 sp 00007f53ceffcc40 \
> error 4 in libnssutil3.so[7f53e2395000+12000] [14324.004286] Code: d8 5b 5d 41 5c c3 \
> 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 f3 0f 1e fa 41 54 41 bc ff ff ff ff 55 53 \
> 48 89 fb e8 7a bc ff ff <48> 8b 3b 48 89 c5 e8 9f c1 ff ff 48 8b 43 38 48 39 c5 75 23 \
> eb 2d [14324.007764] rfkill: input handler enabled
> [14348.933385] rfkill: input handler disabled
> [15930.680376] DMA-API: debugging out of memory - disabling
> [16087.451698] vaapi-queue:src (10166) used greatest stack depth: 10616 bytes left
> [19689.192082] BUG: sleeping function called from invalid context at \
> net/core/sock.c:2833 [19689.192087] in_atomic(): 1, irqs_disabled(): 0, pid: 1743, \
> name: krfcommd [19689.192089] INFO: lockdep is turned off.
> [19689.192093] CPU: 6 PID: 1743 Comm: krfcommd Tainted: G W \
> 4.18.0-0.rc7.git1.1.fc29.x86_64 #1 [19689.192096] Hardware name: Gigabyte Technology \
> Co., Ltd. Z87M-D3H/Z87M-D3H, BIOS F11 08/12/2014 [19689.192098] Call Trace:
> [19689.192106] dump_stack+0x85/0xc0
> [19689.192112] ___might_sleep.cold.72+0xac/0xbc
> [19689.192117] lock_sock_nested+0x29/0xa0
> [19689.192142] bt_accept_enqueue+0x3c/0xb0 [bluetooth]
> [19689.192150] rfcomm_connect_ind+0x21b/0x260 [rfcomm]
> [19689.192157] rfcomm_run+0x1611/0x1820 [rfcomm]
> [19689.192163] ? do_wait_intr_irq+0xb0/0xb0
> [19689.192179] ? rfcomm_check_accept+0x90/0x90 [rfcomm]
> [19689.192183] kthread+0x120/0x140
> [19689.192186] ? kthread_create_worker_on_cpu+0x70/0x70
> [19689.192190] ret_from_fork+0x3a/0x50
> [19689.377451] input: 04:5D:4B:5F:34:57 as /devices/virtual/input/input37
>
>
> Best Regards,
> Petr
^ permalink raw reply
* inconsistent lock state in ila_xlat_nl_cmd_del_mapping
From: syzbot @ 2018-08-14 4:40 UTC (permalink / raw)
To: davem, gregkh, keescook, ktkhai, kuznet, linux-kernel, netdev,
pombredanne, stephen, syzkaller-bugs, tom, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 36d2f761b5aa cxgb4: update 1.20.8.0 as the latest firmware..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17f429c8400000
kernel config: https://syzkaller.appspot.com/x/.config?x=dbf55ebfa6bfd517
dashboard link: https://syzkaller.appspot.com/bug?extid=3db64bd48b29a825d2db
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=14ed8a3c400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=17a4c622400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3db64bd48b29a825d2db@syzkaller.appspotmail.com
IPv6: ADDRCONF(NETDEV_CHANGE): veth0: link becomes ready
IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready
8021q: adding VLAN 0 to HW filter on device team0
================================
WARNING: inconsistent lock state
4.18.0-rc8+ #179 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
syz-executor551/4387 [HC0[0]:SC0[0]:HE1:SE1] takes:
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at: spin_lock
include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at: ila_del_mapping
net/ipv6/ila/ila_xlat.c:290 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at:
ila_xlat_nl_cmd_del_mapping+0x46b/0xb00 net/ipv6/ila/ila_xlat.c:368
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
__rhashtable_insert_fast include/linux/rhashtable.h:596 [inline]
rhashtable_lookup_insert_fast include/linux/rhashtable.h:784 [inline]
fdb_create+0x5cc/0x1710 net/bridge/br_fdb.c:508
br_fdb_update+0x4e7/0xd40 net/bridge/br_fdb.c:605
br_handle_frame_finish+0xa23/0x1960 net/bridge/br_input.c:97
br_nf_hook_thresh+0x48d/0x5f0 net/bridge/br_netfilter_hooks.c:1011
br_nf_pre_routing_finish_ipv6+0x7bc/0xef0
net/bridge/br_netfilter_ipv6.c:209
NF_HOOK include/linux/netfilter.h:287 [inline]
br_nf_pre_routing_ipv6+0x4af/0xac0 net/bridge/br_netfilter_ipv6.c:237
br_nf_pre_routing+0xb33/0x17d0 net/bridge/br_netfilter_hooks.c:494
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0xc2/0x1c0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
NF_HOOK include/linux/netfilter.h:285 [inline]
br_handle_frame+0xc0d/0x1a20 net/bridge/br_input.c:303
__netif_receive_skb_core+0x1455/0x3af0 net/core/dev.c:4821
__netif_receive_skb_one_core+0xd0/0x200 net/core/dev.c:4890
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
process_backlog+0x219/0x760 net/core/dev.c:5808
napi_poll net/core/dev.c:6228 [inline]
net_rx_action+0x7a5/0x1920 net/core/dev.c:6294
__do_softirq+0x2e8/0xb17 kernel/softirq.c:292
invoke_softirq kernel/softirq.c:372 [inline]
irq_exit+0x1d4/0x210 kernel/softirq.c:412
exiting_irq arch/x86/include/asm/apic.h:527 [inline]
smp_apic_timer_interrupt+0x186/0x730 arch/x86/kernel/apic/apic.c:1055
apic_timer_interrupt+0xf/0x20 arch/x86/entry/entry_64.S:863
native_safe_halt+0x6/0x10 arch/x86/include/asm/irqflags.h:54
arch_safe_halt arch/x86/include/asm/paravirt.h:94 [inline]
default_idle+0xc7/0x450 arch/x86/kernel/process.c:500
arch_cpu_idle+0x10/0x20 arch/x86/kernel/process.c:491
default_idle_call+0x6d/0x90 kernel/sched/idle.c:93
cpuidle_idle_call kernel/sched/idle.c:153 [inline]
do_idle+0x3aa/0x570 kernel/sched/idle.c:262
cpu_startup_entry+0x10c/0x120 kernel/sched/idle.c:368
start_secondary+0x433/0x5d0 arch/x86/kernel/smpboot.c:270
secondary_startup_64+0xa5/0xb0 arch/x86/kernel/head_64.S:242
irq event stamp: 51111
hardirqs last enabled at (51111): [<ffffffff814fca78>]
queue_work_on+0xe8/0x1e0 kernel/workqueue.c:1490
hardirqs last disabled at (51110): [<ffffffff814fca2f>]
queue_work_on+0x9f/0x1e0 kernel/workqueue.c:1483
softirqs last enabled at (51088): [<ffffffff85079b7c>] spin_unlock_bh
include/linux/spinlock.h:355 [inline]
softirqs last enabled at (51088): [<ffffffff85079b7c>]
release_sock+0x1ec/0x2c0 net/core/sock.c:2860
softirqs last disabled at (51086): [<ffffffff85079a0d>] spin_lock_bh
include/linux/spinlock.h:315 [inline]
softirqs last disabled at (51086): [<ffffffff85079a0d>]
release_sock+0x7d/0x2c0 net/core/sock.c:2847
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&tlocks[i])->rlock);
<Interrupt>
lock(&(&tlocks[i])->rlock);
*** DEADLOCK ***
1 lock held by syz-executor551/4387:
#0: (____ptrval____) (cb_lock){++++}, at: genl_rcv+0x19/0x40
net/netlink/genetlink.c:636
stack backtrace:
CPU: 0 PID: 4387 Comm: syz-executor551 Not tainted 4.18.0-rc8+ #179
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+0x1c9/0x2b4 lib/dump_stack.c:113
print_usage_bug.cold.63+0x320/0x41a kernel/locking/lockdep.c:2546
valid_state kernel/locking/lockdep.c:2559 [inline]
mark_lock_irq kernel/locking/lockdep.c:2753 [inline]
mark_lock+0x1048/0x19f0 kernel/locking/lockdep.c:3151
mark_irqflags kernel/locking/lockdep.c:3047 [inline]
__lock_acquire+0x7ca/0x5020 kernel/locking/lockdep.c:3392
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:310 [inline]
ila_del_mapping net/ipv6/ila/ila_xlat.c:290 [inline]
ila_xlat_nl_cmd_del_mapping+0x46b/0xb00 net/ipv6/ila/ila_xlat.c:368
genl_family_rcv_msg+0x8a3/0x1140 net/netlink/genetlink.c:601
genl_rcv_msg+0xc6/0x168 net/netlink/genetlink.c:626
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
genl_rcv+0x28/0x40 net/netlink/genetlink.c:637
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:640 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:650
___sys_sendmsg+0x7fd/0x930 net/socket.c:2133
__sys_sendmsg+0x11d/0x290 net/socket.c:2171
__do_sys_sendmsg net/socket.c:2180 [inline]
__se_sys_sendmsg net/socket.c:2178 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2178
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441109
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 db 0a fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd2c44eb68 EFLAGS: 00000213 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00000000004002c8 RCX: 0000000000441109
RDX: 0000000000000000 RSI: 0000000020000040 RDI: 0000000000000003
RBP: 00000000006cc018 R08: 00000000000001
---
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#bug-status-tracking 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
* Re: linux-next: build warning after merge of the net-next tree
From: Masahiro Yamada @ 2018-08-14 7:05 UTC (permalink / raw)
To: Guenter Roeck
Cc: Stephen Rothwell, David Miller, Networking,
Linux-Next Mailing List, Linux Kernel Mailing List, Andrew Lunn
In-Reply-To: <CAK7LNARfZH=ZEdFuRq_g1HsJ+Pv1m=v343JLyE-6+uM_d+3eWA@mail.gmail.com>
2018-07-20 8:19 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> 2018-07-20 7:35 GMT+09:00 Guenter Roeck <linux@roeck-us.net>:
>> On Fri, Jul 20, 2018 at 08:09:06AM +1000, Stephen Rothwell wrote:
>>> Hi Guenter,
>>>
>>> On Thu, 19 Jul 2018 06:49:01 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>> >
>>> > On 07/18/2018 10:29 PM, Stephen Rothwell wrote:
>>> > >
>>> > > On Wed, 18 Jul 2018 20:52:56 -0700 Guenter Roeck <linux@roeck-us.net> wrote:
>>> > >>
>>> > >> On 07/18/2018 07:04 PM, Stephen Rothwell wrote:
>>> > >>>
>>> > >>> After merging the net-next tree, today's linux-next build (x86_64
>>> > >>> allmodconfig) produced this warning:
>>> > >>>
>>> > >>> *
>>> > >>> * Restart config...
>>> > >>> *
>>> > >>> ....
>>> > >>>
>>> > >>> This is output by my "make allmodconfig" and only started after merging
>>> > >>> the net-next tree today. It has continued for further merges/builds.
>>> > >>>
>>> > >>> I suspect commit
>>> > >>>
>>> > >>> 1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
>>> > >>>
>>> > >>> which added an "imply" clause.
>>> > >>>
>>> > >> I thought "imply" was better than "depends on HWMON || HWMON=n", but maybe
>>> > >> not. Is that a caveat when using "imply", and does it mean that "imply"
>>> > >> should better not be used ?
>>> > >
>>> > > I don't know, sorry. It was just my best guess from what I could see
>>> > > had changed.
>>> > >
>>> > > I wonder if it makes a difference that I am doing my "make
>>> > > allmodconfig" on top of a previous "make allmodconfig" and some symbols
>>> > > are marked as "NEW" (though they are not symbols related to the changes
>>> > > that happened during the net-next tree merge)?
>>> > >
>>> >
>>> > I tried to reproduce the problem, but I don't see the message.
>>> >
>>> > What I do see, though, is that "make allmodconfig" on a clean tree,
>>> > followed by "make menuconfig", results in configuration changes.
>>> > Specifically,
>>> >
>>> > > CONFIG_ARC_EMAC_CORE=m
>>> > > CONFIG_ARC_EMAC=m
>>> > > CONFIG_EMAC_ROCKCHIP=m
>>> >
>>> > is removed by menuconfig, and a large number of "# ... is not set"
>>> > configuration lines are added. Weird and bad, since several of the
>>> > disabled configurations _should_ be enabled by "make allmodconfig",
>>> > and a large number of hwmon drivers are affected. Bisect does point
>>> > to "net: phy: sfp: Add HWMON support for module sensors", meaning
>>> > "imply hwmon" does have severe side effects and can not be used.
>>> >
>>> > I'll try to find a fix.
>>>
>>> OK, my mistake, the "make allmodconfig" works, the following "make"
>>> causes the config restart. (I am actually doing cross builds and using
>>> an external object directory, in case that matters.)
>>>
>>> I removed the "imply HWMON" line added by the above commit and the
>>> problem went away. Also, using "depends on HWMON || HWMON=n" instead
>>> of the imply fixes it.
>>
>> Yes, replacing imply with the dependency is what I did in the fixup patch.
>> Sorry, I should have copied you: https://patchwork.kernel.org/patch/10534925/
>>
>> It is a bit different - imply was supposed to enforce HWMON={y,n} if SFP=y,
>> and the depends line enforces SFP={n,m} if HWMON=m. I have no idea why
>> imply doesn't work, but I think I'll stay away from it in the future.
>>
>> Guenter
>
>
> Hmm, this could be a Kconfig bug.
>
> I will take a look.
Today, I took a look at it.
The cause of the problem was the circular dependency.
Somehow, 'imply' is not checked in the circular dependency.
So, I wrote patches to report this.
https://patchwork.kernel.org/patch/10565061/
https://patchwork.kernel.org/patch/10565063/
If you apply those two patches on top of commit
1323061a018a ("net: phy: sfp: Add HWMON support for module sensors")
It is reported in allmodconfig stage, like this:
masahiro@grover:~/ref/linux-next$ make allmodconfig
HOSTCC scripts/kconfig/conf.o
YACC scripts/kconfig/zconf.tab.c
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --allmodconfig Kconfig
drivers/of/Kconfig:68:error: recursive dependency detected!
drivers/of/Kconfig:68: symbol OF_IRQ depends on IRQ_DOMAIN
kernel/irq/Kconfig:63: symbol IRQ_DOMAIN is selected by REGMAP
drivers/base/regmap/Kconfig:6: symbol REGMAP is selected by SENSORS_ASPEED
drivers/hwmon/Kconfig:352: symbol SENSORS_ASPEED depends on HWMON
drivers/hwmon/Kconfig:5: symbol HWMON is implied by SFP
drivers/net/phy/Kconfig:214: symbol SFP depends on PHYLIB
drivers/net/phy/Kconfig:181: symbol PHYLIB is selected by ARC_EMAC_CORE
drivers/net/ethernet/arc/Kconfig:18: symbol ARC_EMAC_CORE is selected
by ARC_EMAC
drivers/net/ethernet/arc/Kconfig:24: symbol ARC_EMAC depends on OF_IRQ
For a resolution refer to Documentation/kbuild/kconfig-language.txt
subsection "Kconfig recursive dependency limitations"
#
# configuration written to .config
#
>
>
> BTW,
> 'depends on HWMON || HWMON=n' is pointless
> because it is always true.
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* Re: [PATCH net-next 02/10] dt-bindings: net: ocelot: remove hsio from the list of register address spaces
From: Quentin Schulz @ 2018-08-14 6:49 UTC (permalink / raw)
To: Rob Herring
Cc: alexandre.belloni, ralf, paul.burton, jhogan, mark.rutland, davem,
kishon, andrew, f.fainelli, linux-mips, devicetree, linux-kernel,
netdev, allan.nielsen, thomas.petazzoni
In-Reply-To: <20180813223103.GA16669@rob-hp-laptop>
[-- Attachment #1: Type: text/plain, Size: 3549 bytes --]
Hi Rob,
On Mon, Aug 13, 2018 at 04:31:03PM -0600, Rob Herring wrote:
> On Mon, Jul 30, 2018 at 02:43:47PM +0200, Quentin Schulz wrote:
> > HSIO register address space should be handled outside of the MAC
> > controller as there are some registers for PLL5 configuring,
> > SerDes/switch port muxing and a thermal sensor IP, so let's remove it.
> >
> > Signed-off-by: Quentin Schulz <quentin.schulz@bootlin.com>
> > ---
> > Documentation/devicetree/bindings/mips/mscc.txt | 16 ++++++++++++-
> > Documentation/devicetree/bindings/net/mscc-ocelot.txt | 9 ++-----
> > 2 files changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/mips/mscc.txt b/Documentation/devicetree/bindings/mips/mscc.txt
> > index ae15ec3..bc817e9 100644
> > --- a/Documentation/devicetree/bindings/mips/mscc.txt
> > +++ b/Documentation/devicetree/bindings/mips/mscc.txt
> > @@ -41,3 +41,19 @@ Example:
> > compatible = "mscc,ocelot-cpu-syscon", "syscon";
> > reg = <0x70000000 0x2c>;
> > };
> > +
> > +o HSIO regs:
> > +
> > +The SoC has a few registers (HSIO) handling miscellaneous functionalities:
> > +configuration and status of PLL5, RCOMP, SyncE, SerDes configurations and
> > +status, SerDes muxing and a thermal sensor.
> > +
> > +Required properties:
> > +- compatible: Should be "mscc,ocelot-hsio", "syscon", "simple-mfd"
> > +- reg : Should contain registers location and length
> > +
> > +Example:
> > + syscon@10d0000 {
> > + compatible = "mscc,ocelot-hsio", "syscon", "simple-mfd";
>
> simple-mfd is not appropriate without child nodes, so drop it.
>
Understood but it's an intermediate patch. Later (patch 8), the SerDes
muxing "controller" is added as a child to this node. There most likely
will be some others in the future (temperature sensor for example).
Furthermore, there's already a simple-mfd without children in this file:
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bindings/mips/mscc.txt#L19
How should we handle this case?
Thanks,
Quentin
> > + reg = <0x10d0000 0x10000>;
> > + };
> > diff --git a/Documentation/devicetree/bindings/net/mscc-ocelot.txt b/Documentation/devicetree/bindings/net/mscc-ocelot.txt
> > index 0a84711..9e5c17d 100644
> > --- a/Documentation/devicetree/bindings/net/mscc-ocelot.txt
> > +++ b/Documentation/devicetree/bindings/net/mscc-ocelot.txt
> > @@ -12,7 +12,6 @@ Required properties:
> > - "sys"
> > - "rew"
> > - "qs"
> > - - "hsio"
> > - "qsys"
> > - "ana"
> > - "portX" with X from 0 to the number of last port index available on that
> > @@ -45,7 +44,6 @@ Example:
> > reg = <0x1010000 0x10000>,
> > <0x1030000 0x10000>,
> > <0x1080000 0x100>,
> > - <0x10d0000 0x10000>,
> > <0x11e0000 0x100>,
> > <0x11f0000 0x100>,
> > <0x1200000 0x100>,
> > @@ -59,10 +57,9 @@ Example:
> > <0x1280000 0x100>,
> > <0x1800000 0x80000>,
> > <0x1880000 0x10000>;
> > - reg-names = "sys", "rew", "qs", "hsio", "port0",
> > - "port1", "port2", "port3", "port4", "port5",
> > - "port6", "port7", "port8", "port9", "port10",
> > - "qsys", "ana";
> > + reg-names = "sys", "rew", "qs", "port0", "port1", "port2",
> > + "port3", "port4", "port5", "port6", "port7",
> > + "port8", "port9", "port10", "qsys", "ana";
> > interrupts = <21 22>;
> > interrupt-names = "xtr", "inj";
> >
> > --
> > git-series 0.9.1
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] net: systemport: fix unused function warning
From: David Miller @ 2018-08-14 3:46 UTC (permalink / raw)
To: arnd
Cc: f.fainelli, talgi, alexander.h.duyck, jeffrey.t.kirsher, netdev,
linux-kernel
In-Reply-To: <20180813221041.219857-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 14 Aug 2018 00:10:34 +0200
> The only remaining caller of this function is inside of an #ifdef
> after another caller got removed. This causes a harmless warning
> in some configurations:
>
> drivers/net/ethernet/broadcom/bcmsysport.c:1068:13: error: 'bcm_sysport_resume_from_wol' defined but not used [-Werror=unused-function]
>
> Removing the #ifdef around the PM functions simplifies the code
> and avoids the problem but letting the compiler drop the unused
> functions silently.
>
> Fixes: 9e85e22713d6 ("net: systemport: Do not re-configure upon WoL interrupt")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH] net: stmmac: mark PM functions as __maybe_unused
From: David Miller @ 2018-08-14 3:46 UTC (permalink / raw)
To: arnd; +Cc: peppe.cavallaro, alexandre.torgue, joabreu, netdev, linux-kernel
In-Reply-To: <20180813215046.3663828-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 13 Aug 2018 23:50:41 +0200
> The newly added suspend/resume functions cause a build warning
> when CONFIG_PM is disabled:
>
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:324:12: error: 'stmmac_pci_resume' defined but not used [-Werror=unused-function]
> drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c:306:12: error: 'stmmac_pci_suspend' defined but not used [-Werror=unused-function]
>
> Mark them as __maybe_unused so gcc can drop them silently.
>
> Fixes: b7d0f08e9129 ("net: stmmac: Fix WoL for PCI-based setups")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: lan743x: select CRC16
From: David Miller @ 2018-08-14 3:44 UTC (permalink / raw)
To: arnd; +Cc: Bryan.Whitehead, andrew, netdev, linux-kernel
In-Reply-To: <20180813211938.2375199-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 13 Aug 2018 23:19:21 +0200
> lan743x now fails to build when CONFIG_CRC16 is disabled:
>
> drivers/net/ethernet/microchip/lan743x_main.o: In function crc16'
>
> Force it on like all other users do.
>
> Fixes: 4d94282afd95 ("lan743x: Add power management support")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* possible deadlock in rhashtable_lookup_insert_fast
From: syzbot @ 2018-08-14 6:20 UTC (permalink / raw)
To: davem, gregkh, keescook, ktkhai, kuznet, linux-kernel, netdev,
pombredanne, stephen, syzkaller-bugs, tom, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 36d2f761b5aa cxgb4: update 1.20.8.0 as the latest firmware..
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=134b323c400000
kernel config: https://syzkaller.appspot.com/x/.config?x=dbf55ebfa6bfd517
dashboard link: https://syzkaller.appspot.com/bug?extid=b66a5a554991a8ed027c
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=103285f0400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=12859d72400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+b66a5a554991a8ed027c@syzkaller.appspotmail.com
random: sshd: uninitialized urandom read (32 bytes read)
random: sshd: uninitialized urandom read (32 bytes read)
netlink: 'syz-executor077': attribute type 8 has an invalid length.
============================================
WARNING: possible recursive locking detected
4.18.0-rc8+ #179 Not tainted
--------------------------------------------
syz-executor077/4391 is trying to acquire lock:
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: spin_lock_bh
include/linux/spinlock.h:315 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: __rhashtable_insert_fast
include/linux/rhashtable.h:596 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at:
rhashtable_lookup_insert_fast.constprop.26+0x436/0x13a0
include/linux/rhashtable.h:784
but task is already holding lock:
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: spin_lock
include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: ila_add_mapping
net/ipv6/ila/ila_xlat.c:233 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at:
ila_xlat_nl_cmd_add_mapping+0x6bb/0x17e0 net/ipv6/ila/ila_xlat.c:355
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&tlocks[i])->rlock);
lock(&(&tlocks[i])->rlock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by syz-executor077/4391:
#0: (____ptrval____) (cb_lock){++++}, at: genl_rcv+0x19/0x40
net/netlink/genetlink.c:636
#1: (____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: spin_lock
include/linux/spinlock.h:310 [inline]
#1: (____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at: ila_add_mapping
net/ipv6/ila/ila_xlat.c:233 [inline]
#1: (____ptrval____) (&(&tlocks[i])->rlock){+.+.}, at:
ila_xlat_nl_cmd_add_mapping+0x6bb/0x17e0 net/ipv6/ila/ila_xlat.c:355
#2: (____ptrval____) (rcu_read_lock){....}, at: __rhashtable_insert_fast
include/linux/rhashtable.h:579 [inline]
#2: (____ptrval____) (rcu_read_lock){....}, at:
rhashtable_lookup_insert_fast.constprop.26+0x1d7/0x13a0
include/linux/rhashtable.h:784
stack backtrace:
CPU: 1 PID: 4391 Comm: syz-executor077 Not tainted 4.18.0-rc8+ #179
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+0x1c9/0x2b4 lib/dump_stack.c:113
print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
check_deadlock kernel/locking/lockdep.c:1809 [inline]
validate_chain kernel/locking/lockdep.c:2405 [inline]
__lock_acquire.cold.65+0x1fb/0x486 kernel/locking/lockdep.c:3435
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
__rhashtable_insert_fast include/linux/rhashtable.h:596 [inline]
rhashtable_lookup_insert_fast.constprop.26+0x436/0x13a0
include/linux/rhashtable.h:784
ila_add_mapping net/ipv6/ila/ila_xlat.c:240 [inline]
ila_xlat_nl_cmd_add_mapping+0xafe/0x17e0 net/ipv6/ila/ila_xlat.c:355
genl_family_rcv_msg+0x8a3/0x1140 net/netlink/genetlink.c:601
genl_rcv_msg+0xc6/0x168 net/netlink/genetlink.c:626
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
genl_rcv+0x28/0x40 net/netlink/genetlink.c:637
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:640 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:650
___sys_sendmsg+0x7fd/0x930 net/socket.c:2133
__sys_sendmsg+0x11d/0x290 net/socket.c:2171
__do_sys_sendmsg net/socket.c:2180 [inline]
__se_sys_sendmsg net/socket.c:2178 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2178
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x4400e9
Code: 18 89 d0 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 fb 13 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007ffd14495758 EFLAG
---
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#bug-status-tracking 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
* [PATCH v2 iproute2-next] Add SKB Priority qdisc support in tc(8)
From: Nishanth Devarajan @ 2018-08-14 2:57 UTC (permalink / raw)
To: dsahern; +Cc: netdev, doucette, michel
sch_skbprio is a qdisc that prioritizes packets according to their skb->priority
field. Under congestion, it drops already-enqueued lower priority packets to
make space available for higher priority packets. Skbprio was conceived as a
solution for denial-of-service defenses that need to route packets with
different priorities as a means to overcome DoS attacks.
Signed-off-by: Nishanth Devarajan <ndev2021@gmail.com>
Reviewed-by: Michel Machado <michel@digirati.com.br>
---
v2
*Patch applies cleanly, fixes for proper code indentation.
---
man/man8/tc-skbprio.8 | 70 ++++++++++++++++++++++++++++++++++++++++++
tc/Makefile | 1 +
tc/q_skbprio.c | 84 +++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 155 insertions(+)
create mode 100644 man/man8/tc-skbprio.8
create mode 100644 tc/q_skbprio.c
diff --git a/man/man8/tc-skbprio.8 b/man/man8/tc-skbprio.8
new file mode 100644
index 0000000..844bbf4
--- /dev/null
+++ b/man/man8/tc-skbprio.8
@@ -0,0 +1,70 @@
+.TH SKBPRIO 8 "13 August 2018" "iproute2" "Linux"
+.SH NAME
+skbprio \- SKB Priority Queue
+
+.SH SYNOPSIS
+.B tc qdisc ... add skbprio
+.B [ limit
+packets
+.B ]
+
+.SH DESCRIPTION
+SKB Priority Queue is a queueing discipline intended to prioritize
+the most important packets during a denial-of-service (
+.B DoS
+) attack. The priority of a packet is given by
+.B skb->priority
+, where a higher value places the packet closer to the exit of the queue. When
+the queue is full, the lowest priority packet in the queue is dropped to make
+room for the packet to be added if it has higher priority. If the packet to be
+added has lower priority than all packets in the queue, it is dropped.
+
+Without SKB priority queue, queue length limits must be imposed
+on individual sub-queues, and there is no straightforward way to enforce
+a global queue length limit across all priorities. SKBprio queue enforces
+a global queue length limit while not restricting the lengths of
+individual sub-queues.
+
+While SKB Priority Queue is agnostic to how
+.B skb->priority
+is assigned. A typical use case is to copy
+the 6-bit DS field of IPv4 and IPv6 packets using
+.BR tc-skbedit (8)
+. If
+.B skb->priority
+is greater or equal to 64, the priority is assumed to be 63.
+Priorities less than 64 are taken at face value.
+
+SKB Priority Queue enables routers to locally decide which
+packets to drop under a DoS attack.
+Priorities should be assigned to packets such that the higher the priority,
+the more expected behavior a source shows.
+So sources have an incentive to play by the rules.
+
+.SH ALGORITHM
+
+Skbprio maintains 64 lists (priorities go from 0 to 63).
+When a packet is enqueued, it gets inserted at the
+.B tail
+of its priority list. When a packet needs to be sent out to the network, it is
+taken from the head of the highest priority list. When the queue is full,
+the packet at the tail of the lowest priority list is dropped to serve the
+ingress packet - if it is of higher priority, otherwise the ingress packet is
+dropped. This algorithm allocates as much bandwidth as possible to high
+priority packets, while only servicing low priority packets when
+there is enough bandwidth.
+
+.SH PARAMETERS
+.TP
+limit
+Maximum queue size specified in packets. It defaults to 64.
+The range for this parameter is [0, UINT32_MAX].
+
+.SH SEE ALSO
+.BR tc-prio (8),
+.BR tc-skbedit (8)
+
+.SH AUTHORS
+Nishanth Devarajan <devarajn@uci.edu>, Michel Machado <michel@digirati.com.br>
+
+This manpage maintained by Bert Hubert <ahu@ds9a.nl>
diff --git a/tc/Makefile b/tc/Makefile
index 36cde2f..5a1a7ff 100644
--- a/tc/Makefile
+++ b/tc/Makefile
@@ -12,6 +12,7 @@ TCMODULES += q_fifo.o
TCMODULES += q_sfq.o
TCMODULES += q_red.o
TCMODULES += q_prio.o
+TCMODULES += q_skbprio.o
TCMODULES += q_tbf.o
TCMODULES += q_cbq.o
TCMODULES += q_rr.o
diff --git a/tc/q_skbprio.c b/tc/q_skbprio.c
new file mode 100644
index 0000000..2b6d78f
--- /dev/null
+++ b/tc/q_skbprio.c
@@ -0,0 +1,84 @@
+/*
+ * q_skbprio.c SKB PRIORITY QUEUE.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ *
+ * Authors: Nishanth Devarajan, <ndev2021@gmail.com>
+ *
+ */
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <unistd.h>
+#include <syslog.h>
+#include <fcntl.h>
+#include <sys/socket.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <string.h>
+
+#include "utils.h"
+#include "tc_util.h"
+
+static void explain(void)
+{
+ fprintf(stderr, "Usage: ... <skbprio> [ limit NUMBER ]\n");
+}
+
+static int skbprio_parse_opt(struct qdisc_util *qu, int argc, char **argv,
+ struct nlmsghdr *n, const char *dev)
+{
+ int ok = 0;
+ struct tc_skbprio_qopt opt = {};
+
+ while (argc > 0) {
+ if (strcmp(*argv, "limit") == 0) {
+ NEXT_ARG();
+ if (get_size(&opt.limit, *argv)) {
+ fprintf(stderr,
+ "%s: Illegal \"limit\" value:\"%s\"\n",
+ qu->id, *argv);
+ return -1;
+ }
+ ok++;
+ }
+ else if (strcmp(*argv, "help") == 0) {
+ explain();
+ return -1;
+ } else {
+ fprintf(stderr,
+ "%s: unknown parameter \"%s\"\n",
+ qu->id, *argv);
+ explain();
+ return -1;
+ }
+ argc--; argv++;
+ }
+
+ if (ok)
+ addattr_l(n, 1024, TCA_OPTIONS, &opt, sizeof(opt));
+ return 0;
+}
+
+static int skbprio_print_opt(struct qdisc_util *qu, FILE *f, struct rtattr *opt)
+{
+ struct tc_skbprio_qopt *qopt;
+
+ if (opt == NULL)
+ return 0;
+
+ if (RTA_PAYLOAD(opt) < sizeof(*qopt))
+ return -1;
+ qopt = RTA_DATA(opt);
+ fprintf(f, "limit %u ", qopt->limit);
+ return 0;
+}
+
+struct qdisc_util skbprio_qdisc_util = {
+ .id = "skbprio",
+ .parse_qopt = skbprio_parse_opt,
+ .print_qopt = skbprio_print_opt,
+};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH net 0/2] net_sched: Fix two tc_index filter init issues
From: David Miller @ 2018-08-14 2:40 UTC (permalink / raw)
To: liuhangbin; +Cc: netdev, xiyou.wangcong
In-Reply-To: <1534157044-19753-1-git-send-email-liuhangbin@gmail.com>
From: Hangbin Liu <liuhangbin@gmail.com>
Date: Mon, 13 Aug 2018 18:44:02 +0800
> These two patches fix two tc_index filter init issues. The first one fixes
> missing exts info in new filter, which will cause NULL pointer dereference
> when delete tcindex filter. The second one fixes missing res info when create
> new filter, which will make filter unbind failed.
Series applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net] nfp: clean up return types in kdoc comments
From: David Miller @ 2018-08-14 2:36 UTC (permalink / raw)
To: jakub.kicinski; +Cc: netdev
In-Reply-To: <20180814013105.19180-1-jakub.kicinski@netronome.com>
From: Jakub Kicinski <jakub.kicinski@netronome.com>
Date: Mon, 13 Aug 2018 18:31:05 -0700
> Remove 'Return:' information from functions which no longer
> return a value. Also update name and return types of nfp_nffw_info
> access functions.
>
> Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
> Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
Applied, thanks Jakub.
^ permalink raw reply
* serdev: How to attach serdev devices to USB based tty devices?
From: Andreas Färber @ 2018-08-14 2:28 UTC (permalink / raw)
To: Rob Herring, linux-serial@vger.kernel.org, linux-usb
Cc: linux-arm-kernel@lists.infradead.org, Linux-MIPS, Stefan Rehm,
Xue Liu, LoRa_Community_Support@semtech.com, Oliver Neukum,
Alexander Graf, Ben Whitten, devicetree, Jian-Hong Pan,
netdev@vger.kernel.org
Hi Rob et al.,
For my LoRa network driver project [1] I have found your serdev
framework to be a valuable help for dealing with hardware modules
exposing some textual or binary UART interface.
In particular on arm(64) and mips this allows to define an unlimited
number of serdev drivers [2] that are associated via their Device Tree
compatible string and can optionally be configured via DT properties.
And in theory it seems serdev has also grown support for ACPI.
Now, a growing number of vendors are placing such modules on a USB stick
for easy evaluation on x86_64 PC hardware, or are designing mPCIe or M.2
cards using their USB pins. While I do not yet have access to such a
device myself, it is my understanding that devices with USB-UART bridge
chipsets (e.g., FTDI) will show up as /dev/ttyUSBx and devices with an
MCU implementing the CDC USB protocol (e.g., Pico-cell gateway = picoGW)
will show up as /dev/ttyACMx.
On the Raspberry Pi I've seen that Device Tree nodes can be used to pass
information to on-board devices such as MAC address to Ethernet chipset,
but that does not seem all that useful for passing a serdev child node
to hot-plugged devices at unpredictable hub/port location (where it
should not interfere with regular USB-UART cables for debugging), nor
would it help ACPI based platforms such as x86_64.
My idea then was that if we had some unique criteria like vendor and
product IDs (or whatever is supported in usb_device_id), we could write
a usb_driver with suitable USB_DEVICE*() macro. In its probe function we
could call into the existing tty driver's probe function and afterwards
try creating and attaching the appropriate serdev device, i.e. a fixed
USB-to-serdev driver mapping. Problem is that most devices don't seem to
implement any unique identifier I could make this depend on - either by
using a standard FT232/FT2232/CH340G chip or by using STMicroelectronics
virtual com port identifiers in CDC firmware and only differing in the
textual description [3] the usb_device_id does not seem to match on.
The obvious solution would of course be if hardware vendors could revise
their designs to configure FTDI/etc. chips uniquely. I hear that that
may involve exchanging the chipset, increasing costs, and may impact
existing drivers. Wouldn't help for devices out there today either.
For the picoGW CDC firmware, Semtech does appear to own a USB vendor ID,
so it would seem possible to allocate their own product IDs for SX1301
and SX1308 respectively to replace the generic STMicroelectronics IDs,
which the various vendors could offer as firmware updates.
All outside my control though.
Oliver therefore suggested to not mess with USB drivers and instead use
a line discipline (ldisc). It seems that for example the userspace tool
slattach takes a tty device and performs an ioctl to switch the generic
tty device into a special N_SLIP protocol mode, implemented in [4].
However, the existing number of such ldisc modes appears to be below 30,
with hardly any vendor-specific implementation, so polluting its number
space seems undesirable? And in some cases I would like to use the same
protocol implementation over direct UART and over USB, so would like to
avoid duplicate serdev_device_driver and tty_ldisc_ops implementations.
Long story short, has there been any thinking about a userspace
interface to attach a given serdev driver to a tty device?
Or is there, on OF_DYNAMIC platforms, a way from userspace to associate
a DT fragment (!= DT Overlay) with a given USB device dynamically, to
attach a serdev node with sub-nodes?
Any other ideas how to cleanly solve this?
In some cases we're talking about a "simple" AT-like command interface;
the picoGW implements a semi-generic USB-SPI bridge that may host a
choice of 2+ chipsets, which in turn has two further sub-devices with 3+
chipset choices (theoretically clk output and rx/tx options etc.) each.
(For the latter I'm thinking we'll need a serdev driver exposing a
regmap_bus and then implement regmap_bus based versions of the SPI
drivers like Ben and I refactored SX1257 in [2] last weekend.)
Thanks,
Andreas
[1] https://patchwork.ozlabs.org/cover/937545/
[2]
https://git.kernel.org/pub/scm/linux/kernel/git/afaerber/linux-lora.git/tree/drivers/net/lora?h=lora-next
[3]
https://github.com/Lora-net/picoGW_mcu/blob/master/src/usb_cdc/Src/usbd_desc.cpp#L59
[4]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/slip/slip.c#n1281
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
^ permalink raw reply
* inconsistent lock state in ila_xlat_nl_cmd_add_mapping
From: syzbot @ 2018-08-14 4:40 UTC (permalink / raw)
To: davem, gregkh, keescook, ktkhai, kuznet, linux-kernel, netdev,
pombredanne, stephen, syzkaller-bugs, tom, yoshfuji
Hello,
syzbot found the following crash on:
HEAD commit: 78cbac647e61 Merge branch 'ip-faster-in-order-IP-fragments'
git tree: net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14df4828400000
kernel config: https://syzkaller.appspot.com/x/.config?x=9100338df26ab75
dashboard link: https://syzkaller.appspot.com/bug?extid=eaaf6c4a6a8cb1869d86
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syzkaller repro:https://syzkaller.appspot.com/x/repro.syz?x=13069ad2400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+eaaf6c4a6a8cb1869d86@syzkaller.appspotmail.com
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
8021q: adding VLAN 0 to HW filter on device team0
================================
WARNING: inconsistent lock state
4.18.0-rc8+ #183 Not tainted
--------------------------------
inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.
syz-executor2/6403 [HC0[0]:SC0[0]:HE1:SE1] takes:
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at: spin_lock
include/linux/spinlock.h:310 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at: ila_add_mapping
net/ipv6/ila/ila_xlat.c:233 [inline]
(____ptrval____) (&(&tlocks[i])->rlock){+.?.}, at:
ila_xlat_nl_cmd_add_mapping+0x6bb/0x17e0 net/ipv6/ila/ila_xlat.c:355
{IN-SOFTIRQ-W} state was registered at:
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline]
_raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168
spin_lock_bh include/linux/spinlock.h:315 [inline]
__rhashtable_insert_fast include/linux/rhashtable.h:596 [inline]
rhashtable_lookup_insert_fast include/linux/rhashtable.h:784 [inline]
fdb_create+0x5cc/0x1710 net/bridge/br_fdb.c:508
br_fdb_update+0x4e7/0xd40 net/bridge/br_fdb.c:605
br_handle_frame_finish+0xa23/0x1960 net/bridge/br_input.c:97
br_nf_hook_thresh+0x48d/0x5f0 net/bridge/br_netfilter_hooks.c:1011
br_nf_pre_routing_finish_ipv6+0x7bc/0xef0
net/bridge/br_netfilter_ipv6.c:209
NF_HOOK include/linux/netfilter.h:287 [inline]
br_nf_pre_routing_ipv6+0x4af/0xac0 net/bridge/br_netfilter_ipv6.c:237
br_nf_pre_routing+0xb33/0x17d0 net/bridge/br_netfilter_hooks.c:494
nf_hook_entry_hookfn include/linux/netfilter.h:119 [inline]
nf_hook_slow+0xc2/0x1c0 net/netfilter/core.c:511
nf_hook include/linux/netfilter.h:242 [inline]
NF_HOOK include/linux/netfilter.h:285 [inline]
br_handle_frame+0xc0d/0x1a20 net/bridge/br_input.c:303
__netif_receive_skb_core+0x1455/0x3af0 net/core/dev.c:4821
__netif_receive_skb_one_core+0xd0/0x200 net/core/dev.c:4890
__netif_receive_skb+0x2c/0x1e0 net/core/dev.c:5002
process_backlog+0x219/0x760 net/core/dev.c:5808
napi_poll net/core/dev.c:6228 [inline]
net_rx_action+0x7a5/0x1920 net/core/dev.c:6294
__do_softirq+0x2e8/0xb17 kernel/softirq.c:292
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1046
do_softirq.part.18+0x155/0x1a0 kernel/softirq.c:336
do_softirq arch/x86/include/asm/preempt.h:23 [inline]
__local_bh_enable_ip+0x1ec/0x230 kernel/softirq.c:189
local_bh_enable include/linux/bottom_half.h:32 [inline]
rcu_read_unlock_bh include/linux/rcupdate.h:725 [inline]
ip6_finish_output2+0xce8/0x2820 net/ipv6/ip6_output.c:121
ip6_finish_output+0x5fe/0xbc0 net/ipv6/ip6_output.c:154
NF_HOOK_COND include/linux/netfilter.h:276 [inline]
ip6_output+0x234/0x9d0 net/ipv6/ip6_output.c:171
dst_output include/net/dst.h:444 [inline]
NF_HOOK include/linux/netfilter.h:287 [inline]
ndisc_send_skb+0x100d/0x1570 net/ipv6/ndisc.c:491
ndisc_send_ns+0x3c1/0x8d0 net/ipv6/ndisc.c:633
addrconf_dad_work+0xbf2/0x1310 net/ipv6/addrconf.c:4060
process_one_work+0xc73/0x1ba0 kernel/workqueue.c:2153
worker_thread+0x189/0x13c0 kernel/workqueue.c:2296
kthread+0x345/0x410 kernel/kthread.c:246
ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:412
irq event stamp: 113
hardirqs last enabled at (113): [<ffffffff86b11fe4>]
__raw_spin_unlock_irqrestore include/linux/spinlock_api_smp.h:160 [inline]
hardirqs last enabled at (113): [<ffffffff86b11fe4>]
_raw_spin_unlock_irqrestore+0x74/0xc0 kernel/locking/spinlock.c:184
hardirqs last disabled at (112): [<ffffffff86b120a4>]
__raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:108 [inline]
hardirqs last disabled at (112): [<ffffffff86b120a4>]
_raw_spin_lock_irqsave+0x74/0xc0 kernel/locking/spinlock.c:152
softirqs last enabled at (64): [<ffffffff85079b7c>] spin_unlock_bh
include/linux/spinlock.h:355 [inline]
softirqs last enabled at (64): [<ffffffff85079b7c>]
release_sock+0x1ec/0x2c0 net/core/sock.c:2860
softirqs last disabled at (62): [<ffffffff85079a0d>] spin_lock_bh
include/linux/spinlock.h:315 [inline]
softirqs last disabled at (62): [<ffffffff85079a0d>]
release_sock+0x7d/0x2c0 net/core/sock.c:2847
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&(&tlocks[i])->rlock);
<Interrupt>
lock(&(&tlocks[i])->rlock);
*** DEADLOCK ***
1 lock held by syz-executor2/6403:
#0: (____ptrval____) (cb_lock){++++}, at: genl_rcv+0x19/0x40
net/netlink/genetlink.c:636
stack backtrace:
CPU: 0 PID: 6403 Comm: syz-executor2 Not tainted 4.18.0-rc8+ #183
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+0x1c9/0x2b4 lib/dump_stack.c:113
print_usage_bug.cold.63+0x320/0x41a kernel/locking/lockdep.c:2546
valid_state kernel/locking/lockdep.c:2559 [inline]
mark_lock_irq kernel/locking/lockdep.c:2753 [inline]
mark_lock+0x1048/0x19f0 kernel/locking/lockdep.c:3151
mark_irqflags kernel/locking/lockdep.c:3047 [inline]
__lock_acquire+0x7ca/0x5020 kernel/locking/lockdep.c:3392
lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
__raw_spin_lock include/linux/spinlock_api_smp.h:142 [inline]
_raw_spin_lock+0x2a/0x40 kernel/locking/spinlock.c:144
spin_lock include/linux/spinlock.h:310 [inline]
ila_add_mapping net/ipv6/ila/ila_xlat.c:233 [inline]
ila_xlat_nl_cmd_add_mapping+0x6bb/0x17e0 net/ipv6/ila/ila_xlat.c:355
genl_family_rcv_msg+0x8a3/0x1140 net/netlink/genetlink.c:601
genl_rcv_msg+0xc6/0x168 net/netlink/genetlink.c:626
netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2454
genl_rcv+0x28/0x40 net/netlink/genetlink.c:637
netlink_unicast_kernel net/netlink/af_netlink.c:1317 [inline]
netlink_unicast+0x5a0/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:640 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:650
___sys_sendmsg+0x7fd/0x930 net/socket.c:2133
__sys_sendmsg+0x11d/0x290 net/socket.c:2171
__do_sys_sendmsg net/socket.c:2180 [inline]
__se_sys_sendmsg net/socket.c:2178 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2178
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x457089
Code: fd b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 89 f8 48 89 f7
48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff
ff 0f 83 cb b4 fb ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fcc9357bc78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fcc9357c6d4 RCX: 0000000000457089
RDX: 0000000000000000 RSI: 0000000020000080 RDI: 0000000000000003
RBP: 00000000009300a0 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00000000ffffffff
R13: 00000000004d3c18 R14: 00000000004c88f5 R15: 0000000000000000
---
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#bug-status-tracking 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
* Re: [PATCH net 2/2] net_sched: Fix missing res info when create new tc_index filter
From: Cong Wang @ 2018-08-14 1:46 UTC (permalink / raw)
To: Hangbin Liu; +Cc: Linux Kernel Network Developers, David Miller
In-Reply-To: <1534157044-19753-3-git-send-email-liuhangbin@gmail.com>
On Mon, Aug 13, 2018 at 3:44 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
> This is because we didn't update f->result.res when create new filter. Then in
> tcindex_delete() -> tcf_unbind_filter(), we will failed to find out the res
> and unbind filter, which will trigger the WARN_ON() in cbq_destroy_class().
>
> Fix it by updating f->result.res when create new filter.
>
> Fixes: 6e0565697a106 ("net_sched: fix another crash in cls_tcindex")
> Reported-by: Li Shuang <shuali@redhat.com>
> Signed-off-by: Hangbin Liu <liuhangbin@gmail.com>
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [PATCH net 1/2] net_sched: fix NULL pointer dereference when delete tcindex filter
From: Cong Wang @ 2018-08-14 1:46 UTC (permalink / raw)
To: Hangbin Liu; +Cc: Linux Kernel Network Developers, David Miller
In-Reply-To: <1534157044-19753-2-git-send-email-liuhangbin@gmail.com>
On Mon, Aug 13, 2018 at 3:44 AM Hangbin Liu <liuhangbin@gmail.com> wrote:
>
> This is because in tcindex_set_parms, when there is no old_r, we set new
> exts to cr.exts. And we didn't set it to filter when r == &new_filter_result.
>
> Then in tcindex_delete() -> tcf_exts_get_net(), we will get NULL pointer
> dereference as we didn't init exts.
>
> Fix it by moving tcf_exts_change() after "if (old_r && old_r != r)" check.
> Then we don't need "cr" as there is no errout after that.
Acked-by: Cong Wang <xiyou.wangcong@gmail.com>
^ permalink raw reply
* Re: [Question] bluetooth/{bnep,cmtp,hidp}: memory barriers
From: JeffyChen @ 2018-08-14 4:26 UTC (permalink / raw)
To: Brian Norris, Andrea Parri
Cc: Marcel Holtmann, Johan Hedberg, David S. Miller, linux-bluetooth,
netdev, linux-kernel, Brian Norris, AL Yu-Chen Cho
In-Reply-To: <20180813231854.GA173912@ban.mtv.corp.google.com>
Hi guys,
Thanks for your mails, and sorry for the late response..
On 08/14/2018 07:18 AM, Brian Norris wrote:
>
> commit 5da8e47d849d3d37b14129f038782a095b9ad049
> Author: Jeffy Chen<jeffy.chen@rock-chips.com>
> Date: Tue Jun 27 17:34:44 2017 +0800
>
> Bluetooth: hidp: fix possible might sleep error in hidp_session_thread
>
> that*some* kind of barrier was stuck in there simply as a response to
> comments like this, that were going away:
>
> - *
> - * Note: set_current_state() performs any necessary
> - * memory-barriers for us.
> */
> - set_current_state(TASK_INTERRUPTIBLE);
>
> + /* Ensure session->terminate is updated */
> + smp_mb__before_atomic();
>
>
> It was probably an attempt to fill in the gap for the
> set_current_state() (and comment) which was being removed. I believe
> Jeffy originally added more barriers in other places, but I convinced
> him not to.
right, i was trying to avoid losing memory-barriers when removing
set_current_state and changing wake_up_process to wake_up_interruptible.
and checking these code again, it's true the smp_mb__before_atomic
before atomic_read is not needed, the smp_mb after
atomic_inc(&session->terminate) should be enough.
and as Brian point out, there's already an smp_store_mb at the end of
wait_woken, i agree we can remove all the
smp_mb__{before,after}_atomic() i wrongly added :)
>
> I have to say, I'm not really up-to-speed on the use of manual barriers
> in Linux (it's much preferable when they're wrapped into higher-level
> data structures already), but I believe the main intention here is to
> ensure that any change to 'terminate' that happened during the previous
> "wait_woken()" would be visible to our atomic_read().
>
> Looking into wait_woken(), I'm feeling like none of these additional
> barriers are necessary at all. I believe wait_woken() handles the
> visibility issues we care about (that if we were woken for termination,
> we'll see the terminating condition).
^ permalink raw reply
* [PATCH net] nfp: clean up return types in kdoc comments
From: Jakub Kicinski @ 2018-08-14 1:31 UTC (permalink / raw)
To: davem; +Cc: netdev, Jakub Kicinski
Remove 'Return:' information from functions which no longer
return a value. Also update name and return types of nfp_nffw_info
access functions.
Signed-off-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Reviewed-by: Dirk van der Merwe <dirk.vandermerwe@netronome.com>
---
drivers/net/ethernet/netronome/nfp/nfp_net_common.c | 2 --
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c | 6 ++----
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
index 0817c69fc568..a8b9fbab5f73 100644
--- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
+++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c
@@ -949,8 +949,6 @@ static int nfp_net_tx(struct sk_buff *skb, struct net_device *netdev)
* nfp_net_tx_complete() - Handled completed TX packets
* @tx_ring: TX ring structure
* @budget: NAPI budget (only used as bool to determine if in NAPI context)
- *
- * Return: Number of completed TX descriptors
*/
static void nfp_net_tx_complete(struct nfp_net_tx_ring *tx_ring, int budget)
{
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c
index 37a6d7822a38..40510860341b 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_nffw.c
@@ -207,7 +207,7 @@ nffw_res_fwinfos(struct nfp_nffw_info_data *fwinf, struct nffw_fwinfo **arr)
* nfp_nffw_info_open() - Acquire the lock on the NFFW table
* @cpp: NFP CPP handle
*
- * Return: 0, or -ERRNO
+ * Return: pointer to nfp_nffw_info object or ERR_PTR()
*/
struct nfp_nffw_info *nfp_nffw_info_open(struct nfp_cpp *cpp)
{
@@ -253,10 +253,8 @@ struct nfp_nffw_info *nfp_nffw_info_open(struct nfp_cpp *cpp)
}
/**
- * nfp_nffw_info_release() - Release the lock on the NFFW table
+ * nfp_nffw_info_close() - Release the lock on the NFFW table and free state
* @state: NFP FW info state
- *
- * Return: 0, or -ERRNO
*/
void nfp_nffw_info_close(struct nfp_nffw_info *state)
{
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] bnxt_en: take coredump_record structure off stack
From: David Miller @ 2018-08-14 3:46 UTC (permalink / raw)
To: arnd
Cc: michael.chan, vasundhara-v.volam, gospo, scott.branden, netdev,
linux-kernel
In-Reply-To: <20180813221256.299221-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 14 Aug 2018 00:12:45 +0200
> The bnxt_coredump_record structure is very long, causing a warning
> about possible stack overflow on 32-bit architectures:
>
> drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c: In function 'bnxt_get_coredump':
> drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:2989:1: error: the frame size of 1188 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
>
> I could not see any reason to operate on an on-stack copy of the
> structure before copying it back into the caller-provided buffer, which
> also simplifies the code here.
>
> Fixes: 6c5657d085ae ("bnxt_en: Add support for ethtool get dump.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH] l2tp: fix unused function warning
From: David Miller @ 2018-08-14 3:46 UTC (permalink / raw)
To: arnd; +Cc: jchapman, g.nault, lorenzo.bianconi, netdev, linux-kernel
In-Reply-To: <20180813214341.3333789-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 13 Aug 2018 23:43:05 +0200
> Removing one of the callers of pppol2tp_session_get_sock caused a harmless
> warning in some configurations:
>
> net/l2tp/l2tp_ppp.c:142:21: 'pppol2tp_session_get_sock' defined but not used [-Wunused-function]
>
> Rather than adding another #ifdef here, using a proper IS_ENABLED()
> check makes the code more readable and avoids those warnings while
> letting the compiler figure out for itself which code is needed.
>
> This adds one pointer for the unused show() callback in struct
> l2tp_session, but that seems harmless.
>
> Fixes: b0e29063dcb3 ("l2tp: remove pppol2tp_session_ioctl()")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ permalink raw reply
* Re: [PATCH] bnxt_en: avoid string overflow for record->system_name
From: David Miller @ 2018-08-14 3:46 UTC (permalink / raw)
To: arnd
Cc: michael.chan, vasundhara-v.volam, scott.branden, gospo, netdev,
linux-kernel
In-Reply-To: <20180813212700.2681499-1-arnd@arndb.de>
From: Arnd Bergmann <arnd@arndb.de>
Date: Mon, 13 Aug 2018 23:26:54 +0200
> The utsname()->nodename string may be 64 bytes long, and it gets
> copied without the trailing nul byte into the shorter record->system_name,
> as gcc now warns:
>
> In file included from include/linux/bitmap.h:9,
> from include/linux/ethtool.h:16,
> from drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:13:
> In function 'strncpy',
> inlined from 'bnxt_fill_coredump_record' at drivers/net/ethernet/broadcom/bnxt/bnxt_ethtool.c:2863:2:
> include/linux/string.h:254:9: error: '__builtin_strncpy' output truncated before terminating nul copying as many bytes from a string as its length [-Werror=stringop-truncation]
>
> Using strlcpy() at least avoids overflowing the destination buffer
> and adds proper nul-termination. It may still truncate long names
> though, which probably can't be solved here.
>
> Fixes: 6c5657d085ae ("bnxt_en: Add support for ethtool get dump.")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied.
^ 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