* Re: [Patch net v2] rds: fix two RCU related problems
From: Santosh Shilimkar @ 2018-09-11 1:33 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: Sowmini Varadhan, rds-devel
In-Reply-To: <20180911012726.5353-1-xiyou.wangcong@gmail.com>
On 9/10/2018 6:27 PM, Cong Wang wrote:
> When a rds sock is bound, it is inserted into the bind_hash_table
> which is protected by RCU. But when releasing rds sock, after it
> is removed from this hash table, it is freed immediately without
> respecting RCU grace period. This could cause some use-after-free
> as reported by syzbot.
>
> Mark the rds sock with SOCK_RCU_FREE before inserting it into the
> bind_hash_table, so that it would be always freed after a RCU grace
> period.
>
> The other problem is in rds_find_bound(), the rds sock could be
> freed in between rhashtable_lookup_fast() and rds_sock_addref(),
> so we need to extend RCU read lock protection in rds_find_bound()
> to close this race condition.
>
> Reported-and-tested-by: syzbot+8967084bcac563795dc6@syzkaller.appspotmail.com
> Reported-by: syzbot+93a5839deb355537440f@syzkaller.appspotmail.com
> Cc: Sowmini Varadhan <sowmini.varadhan@oracle.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@oracle.com>
> Cc: rds-devel@oss.oracle.com
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
Thank you !!
Acked-by: Santosh Shilimkar <santosh.shilimkar@oarcle.com>
^ permalink raw reply
* Re: [PATCH] ip6_gre: simplify gre header parsing in ip6gre_err
From: Jiri Benc @ 2018-09-11 6:47 UTC (permalink / raw)
To: Haishuang Yan; +Cc: David S. Miller, Alexey Kuznetsov, netdev, linux-kernel
In-Reply-To: <F6F07B41-345D-4416-B9C7-D5509715D33F@cmss.chinamobile.com>
On Tue, 11 Sep 2018 10:19:31 +0800, Haishuang Yan wrote:
> Since csum_err may not be used outside, how about refactoring gre_parse_header function like this:
>
> --- a/net/ipv4/gre_demux.c
> +++ b/net/ipv4/gre_demux.c
> @@ -86,7 +86,7 @@ int gre_parse_header(struct sk_buff *skb, struct tnl_ptk_info *tpi,
>
> options = (__be32 *)(greh + 1);
> if (greh->flags & GRE_CSUM) {
> - if (skb_checksum_simple_validate(skb)) {
> + if (csum_err && skb_checksum_simple_validate(skb)) {
Something like this, yes.
Thanks!
Jiri
^ permalink raw reply
* [PATCH] xen/netfront: don't bug in case of too many frags
From: Juergen Gross @ 2018-09-11 7:04 UTC (permalink / raw)
To: linux-kernel, netdev, xen-devel
Cc: davem, boris.ostrovsky, Juergen Gross, stable
Commit 57f230ab04d291 ("xen/netfront: raise max number of slots in
xennet_get_responses()") raised the max number of allowed slots by one.
This seems to be problematic in some configurations with netback using
a larger MAX_SKB_FRAGS value (e.g. old Linux kernel with MAX_SKB_FRAGS
defined as 18 instead of nowadays 17).
Instead of BUG_ON() in this case just fall back to retransmission.
Fixes: 57f230ab04d291 ("xen/netfront: raise max number of slots in xennet_get_responses()")
Cc: stable@vger.kernel.org
Signed-off-by: Juergen Gross <jgross@suse.com>
---
drivers/net/xen-netfront.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index 9407acbd19a9..f17f602e6171 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -908,7 +908,11 @@ static RING_IDX xennet_fill_frags(struct netfront_queue *queue,
BUG_ON(pull_to <= skb_headlen(skb));
__pskb_pull_tail(skb, pull_to - skb_headlen(skb));
}
- BUG_ON(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS);
+ if (unlikely(skb_shinfo(skb)->nr_frags >= MAX_SKB_FRAGS)) {
+ queue->rx.rsp_cons = ++cons;
+ kfree_skb(nskb);
+ return ~0U;
+ }
skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags,
skb_frag_page(nfrag),
@@ -1045,6 +1049,8 @@ static int xennet_poll(struct napi_struct *napi, int budget)
skb->len += rx->status;
i = xennet_fill_frags(queue, skb, &tmpq);
+ if (unlikely(i == ~0U))
+ goto err;
if (rx->flags & XEN_NETRXF_csum_blank)
skb->ip_summed = CHECKSUM_PARTIAL;
--
2.16.4
^ permalink raw reply related
* [PATCH RESEND net-next] docs: net: Convert tcp.txt to RST format
From: Tobin C. Harding @ 2018-09-11 7:13 UTC (permalink / raw)
To: David S. Miller
Cc: Tobin C. Harding, Eric Dumazet, netdev, linux-doc, linux-kernel
Restructured text is the kernel documentation format of choice now.
Some text from tcp.txt is out of date, specifically the function
tcp_write() does not appear to be in the tree anymore. Also the
following data members have been removed
sk->tcp_pend_event
sk->transmit_queue
sk->transmit_new
sk->transmit_end
sk->tcp_last_tx_ack
sk->tcp_dup_ack
Remove section 'How the new TCP output machine [nyi] works'. This
leaves only a single section so we can name the document with that
section heading now.
Convert tcp.txt to RST format. Add GPLv2 SPDX tag.
Signed-off-by: Tobin C. Harding <me@tobin.cc>
---
This is v1 re-sending since I sent the original during the merge window :(
CC'd Eric as maintainer of TCP (according to MAINTAINERS)
I was going to ask a question on netdev list as to whether this file was
out of date. I just removed the suspect section and did the patch
instead. I am not sure if it is correct to remove it or if the
structure documented has just been changed. Please see bottom section
of removed text ('How the new TCP output machine [nyi] works').
Also please note this file is not covered by MAINTAINERS, should it be?
thanks,
Tobin.
Documentation/networking/00-INDEX | 2 -
Documentation/networking/index.rst | 1 +
Documentation/networking/tcp.rst | 71 ++++++++++++++++++++
Documentation/networking/tcp.txt | 101 -----------------------------
4 files changed, 72 insertions(+), 103 deletions(-)
create mode 100644 Documentation/networking/tcp.rst
delete mode 100644 Documentation/networking/tcp.txt
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 02a323c43261..dcbccae4043e 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -198,8 +198,6 @@ tc-actions-env-rules.txt
- rules for traffic control (tc) actions.
timestamping.txt
- overview of network packet timestamping variants.
-tcp.txt
- - short blurb on how TCP output takes place.
tcp-thin.txt
- kernel tuning options for low rate 'thin' TCP streams.
team.txt
diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst
index fcd710f2cc7a..1cb9bcc36dd7 100644
--- a/Documentation/networking/index.rst
+++ b/Documentation/networking/index.rst
@@ -21,6 +21,7 @@ Contents:
net_failover
alias
bridge
+ tcp
.. only:: subproject
diff --git a/Documentation/networking/tcp.rst b/Documentation/networking/tcp.rst
new file mode 100644
index 000000000000..ae2094fc5de3
--- /dev/null
+++ b/Documentation/networking/tcp.rst
@@ -0,0 +1,71 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+======================
+TCP Congestion Control
+======================
+
+The following variables are used in the tcp_sock for congestion control
+
+.. flat-table:: Congestion Control
+ :widths: 1 2
+
+ * - tcp_sock struct member
+ - Usage
+
+ * - snd_cwnd
+ - The size of the congestion window
+
+ * - snd_ssthresh
+ - Slow start threshold. We are in slow start if snd_cwnd is less
+ than this.
+
+ * - snd_cwnd_cnt
+ - A counter used to slow down the rate of increase once we exceed
+ slow start threshold.
+
+ * - snd_cwnd_clamp
+ - This is the maximum size that snd_cwnd can grow to.
+
+ * - snd_cwnd_stamp
+ - Timestamp for when congestion window last validated.
+
+ * - snd_cwnd_used
+ - Used as a highwater mark for how much of the congestion window
+ is in use. It is used to adjust snd_cwnd down when the link is
+ limited by the application rather than the network.
+
+As of 2.6.13, Linux supports pluggable congestion control algorithms. A
+congestion control mechanism can be registered through functions in
+tcp_cong.c. The functions used by the congestion control mechanism are
+registered via passing a tcp_congestion_ops struct to
+tcp_register_congestion_control. As a minimum, the congestion control
+mechanism must provide a valid name and must implement either ssthresh,
+cong_avoid and undo_cwnd hooks or the "omnipotent" cong_control hook.
+
+Private data for a congestion control mechanism is stored in
+tp->ca_priv. tcp_ca(tp) returns a pointer to this space. This is
+preallocated space - it is important to check the size of your private
+data will fit this space, or alternatively, space could be allocated
+elsewhere and a pointer to it could be stored here.
+
+There are three kinds of congestion control algorithms currently: The
+simplest ones are derived from TCP reno (highspeed, scalable) and just
+provide an alternative congestion window calculation. More complex ones
+like BIC try to look at other events to provide better heuristics.
+There are also round trip time based algorithms like Vegas and
+Westwood+.
+
+Good TCP congestion control is a complex problem because the algorithm
+needs to maintain fairness and performance. Please review current
+research and RFC's before developing new modules.
+
+The default congestion control mechanism is chosen based on the
+DEFAULT_TCP_CONG Kconfig parameter. If you really want a particular
+default value then you can set it using sysctl
+net.ipv4.tcp_congestion_control. The module will be autoloaded if
+needed and you will get the expected protocol. If you ask for an
+unknown congestion method, then the sysctl attempt will fail.
+
+If you remove a TCP congestion control module, then you will get the
+next available one. Since reno cannot be built as a module, and cannot
+be removed, it will always be available.
diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt
deleted file mode 100644
index 9c7139d57e57..000000000000
--- a/Documentation/networking/tcp.txt
+++ /dev/null
@@ -1,101 +0,0 @@
-TCP protocol
-============
-
-Last updated: 3 June 2017
-
-Contents
-========
-
-- Congestion control
-- How the new TCP output machine [nyi] works
-
-Congestion control
-==================
-
-The following variables are used in the tcp_sock for congestion control:
-snd_cwnd The size of the congestion window
-snd_ssthresh Slow start threshold. We are in slow start if
- snd_cwnd is less than this.
-snd_cwnd_cnt A counter used to slow down the rate of increase
- once we exceed slow start threshold.
-snd_cwnd_clamp This is the maximum size that snd_cwnd can grow to.
-snd_cwnd_stamp Timestamp for when congestion window last validated.
-snd_cwnd_used Used as a highwater mark for how much of the
- congestion window is in use. It is used to adjust
- snd_cwnd down when the link is limited by the
- application rather than the network.
-
-As of 2.6.13, Linux supports pluggable congestion control algorithms.
-A congestion control mechanism can be registered through functions in
-tcp_cong.c. The functions used by the congestion control mechanism are
-registered via passing a tcp_congestion_ops struct to
-tcp_register_congestion_control. As a minimum, the congestion control
-mechanism must provide a valid name and must implement either ssthresh,
-cong_avoid and undo_cwnd hooks or the "omnipotent" cong_control hook.
-
-Private data for a congestion control mechanism is stored in tp->ca_priv.
-tcp_ca(tp) returns a pointer to this space. This is preallocated space - it
-is important to check the size of your private data will fit this space, or
-alternatively, space could be allocated elsewhere and a pointer to it could
-be stored here.
-
-There are three kinds of congestion control algorithms currently: The
-simplest ones are derived from TCP reno (highspeed, scalable) and just
-provide an alternative congestion window calculation. More complex
-ones like BIC try to look at other events to provide better
-heuristics. There are also round trip time based algorithms like
-Vegas and Westwood+.
-
-Good TCP congestion control is a complex problem because the algorithm
-needs to maintain fairness and performance. Please review current
-research and RFC's before developing new modules.
-
-The default congestion control mechanism is chosen based on the
-DEFAULT_TCP_CONG Kconfig parameter. If you really want a particular default
-value then you can set it using sysctl net.ipv4.tcp_congestion_control. The
-module will be autoloaded if needed and you will get the expected protocol. If
-you ask for an unknown congestion method, then the sysctl attempt will fail.
-
-If you remove a TCP congestion control module, then you will get the next
-available one. Since reno cannot be built as a module, and cannot be
-removed, it will always be available.
-
-How the new TCP output machine [nyi] works.
-===========================================
-
-Data is kept on a single queue. The skb->users flag tells us if the frame is
-one that has been queued already. To add a frame we throw it on the end. Ack
-walks down the list from the start.
-
-We keep a set of control flags
-
-
- sk->tcp_pend_event
-
- TCP_PEND_ACK Ack needed
- TCP_ACK_NOW Needed now
- TCP_WINDOW Window update check
- TCP_WINZERO Zero probing
-
-
- sk->transmit_queue The transmission frame begin
- sk->transmit_new First new frame pointer
- sk->transmit_end Where to add frames
-
- sk->tcp_last_tx_ack Last ack seen
- sk->tcp_dup_ack Dup ack count for fast retransmit
-
-
-Frames are queued for output by tcp_write. We do our best to send the frames
-off immediately if possible, but otherwise queue and compute the body
-checksum in the copy.
-
-When a write is done we try to clear any pending events and piggy back them.
-If the window is full we queue full sized frames. On the first timeout in
-zero window we split this.
-
-On a timer we walk the retransmit list to send any retransmits, update the
-backoff timers etc. A change of route table stamp causes a change of header
-and recompute. We add any new tcp level headers and refinish the checksum
-before sending.
-
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net] ipv6: use rt6_info members when dst is set in rt6_fill_node
From: David Ahern @ 2018-09-11 2:39 UTC (permalink / raw)
To: Hangbin Liu; +Cc: Xin Long, network dev, davem, Roopa Prabhu
In-Reply-To: <20180911010449.GA24677@leo.usersys.redhat.com>
On 9/10/18 7:04 PM, Hangbin Liu wrote:
> diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> index 18e00ce..62621b4 100644
> --- a/net/ipv6/route.c
> +++ b/net/ipv6/route.c
> @@ -998,6 +998,21 @@ static void ip6_rt_copy_init(struct rt6_info *rt, struct fib6_info *ort)
> rt->rt6i_prefsrc = ort->fib6_prefsrc;
> }
>
> +static void rt6_update_info(struct rt6_info *rt)
> +{
> + struct fib6_info *from;
> +
> + rcu_read_lock();
> + from = rcu_dereference(rt->from);
> + fib6_info_hold(from);
> + rcu_read_unlock();
> +
> + from->fib6_flags = rt->rt6i_flags;
> + from->fib6_nh.nh_gw = rt->rt6i_gateway;
As I mentioned on your last patch, redirects do *not* update fib
entries. Exceptions, yes, but not core data of a fib entry.
^ permalink raw reply
* RE: [PATCH] xen-netback: remove unecessary condition check before debugfs_remove_recursive
From: Paul Durrant @ 2018-09-11 8:00 UTC (permalink / raw)
To: 'zhong jiang', davem@davemloft.net, Wei Liu
Cc: xen-devel@lists.xenproject.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1536414822-32911-1-git-send-email-zhongjiang@huawei.com>
> -----Original Message-----
> From: zhong jiang [mailto:zhongjiang@huawei.com]
> Sent: 08 September 2018 14:54
> To: davem@davemloft.net; Paul Durrant <Paul.Durrant@citrix.com>; Wei Liu
> <wei.liu2@citrix.com>
> Cc: xen-devel@lists.xenproject.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [PATCH] xen-netback: remove unecessary condition check before
> debugfs_remove_recursive
>
> debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just
> remove the condition check before debugfs_remove_recursive.
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
> ---
> drivers/net/xen-netback/netback.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/net/xen-netback/netback.c b/drivers/net/xen-
> netback/netback.c
> index 3621e05..80aae3a 100644
> --- a/drivers/net/xen-netback/netback.c
> +++ b/drivers/net/xen-netback/netback.c
> @@ -1660,8 +1660,7 @@ static int __init netback_init(void)
> static void __exit netback_fini(void)
> {
> #ifdef CONFIG_DEBUG_FS
> - if (!IS_ERR_OR_NULL(xen_netback_dbg_root))
> - debugfs_remove_recursive(xen_netback_dbg_root);
> + debugfs_remove_recursive(xen_netback_dbg_root);
> #endif /* CONFIG_DEBUG_FS */
> xenvif_xenbus_fini();
> }
> --
> 1.7.12.4
^ permalink raw reply
* Re: [Intel-wired-lan] e1000e driver stuck at 10Mbps after reconnection
From: Benjamin Poirier @ 2018-09-11 8:31 UTC (permalink / raw)
To: Camille Bordignon
Cc: Neftin, Sasha, Alexander Duyck, Netdev, intel-wired-lan,
David S. Miller, linux-kernel
In-Reply-To: <20180907062851.GA7336@super_plancton>
On 2018/09/07 08:28, Camille Bordignon wrote:
> Le mercredi 08 août 2018 à 18:00:28 (+0300), Neftin, Sasha a écrit :
> > On 8/8/2018 17:24, Neftin, Sasha wrote:
> > > On 8/7/2018 09:42, Camille Bordignon wrote:
> > > > Le lundi 06 août 2018 à 15:45:29 (-0700), Alexander Duyck a écrit :
> > > > > On Mon, Aug 6, 2018 at 4:59 AM, Camille Bordignon
> > > > > <camille.bordignon@easymile.com> wrote:
> > > > > > Hello,
> > > > > >
> > > > > > Recently we experienced some issues with intel NIC (I219-LM
> > > > > > and I219-V).
> > > > > > It seems that after a wire reconnection, auto-negotation "fails" and
> > > > > > link speed drips to 10 Mbps.
> > > > > >
[...]
>
> I recently figured out that neither the previous patch nor commit
> 0b76aae741abb9d16d2c0e67f8b1e766576f897d fix this issue.
>
> In these cases, after reproducing the issue, when ethernet wire is connected
> kernel logs mention full speed (1000 Mbps) but actually it seems it is not.
> The problem persists.
>
Hmm, so the newer (post 4110e02eb45e) kernels are actually "better", in
that they accurately report that link speed is 10Mb/s.
In the end, do you know of a kernel version that doesn't exhibit the
problem of slower actual link speed?
I had a look at the code and I tried to reproduce the problem on the
hardware that I have (I217) but could not.
Also, out of curiosity, have you tried playing with the speed, autoneg
and advertise settings via ethtool -s to force the link to 1000Mb/s?
^ permalink raw reply
* Re: [PATCH net] ipv6: use rt6_info members when dst is set in rt6_fill_node
From: Hangbin Liu @ 2018-09-11 3:41 UTC (permalink / raw)
To: David Ahern; +Cc: Xin Long, network dev, davem, Roopa Prabhu
In-Reply-To: <879245ec-fd99-3b7f-6fc2-2d8d25cf2c57@cumulusnetworks.com>
Hi David,
On Mon, Sep 10, 2018 at 08:39:34PM -0600, David Ahern wrote:
> On 9/10/18 7:04 PM, Hangbin Liu wrote:
>
> > diff --git a/net/ipv6/route.c b/net/ipv6/route.c
> > index 18e00ce..62621b4 100644
> > --- a/net/ipv6/route.c
> > +++ b/net/ipv6/route.c
> > @@ -998,6 +998,21 @@ static void ip6_rt_copy_init(struct rt6_info *rt, struct fib6_info *ort)
> > rt->rt6i_prefsrc = ort->fib6_prefsrc;
> > }
> >
> > +static void rt6_update_info(struct rt6_info *rt)
> > +{
> > + struct fib6_info *from;
> > +
> > + rcu_read_lock();
> > + from = rcu_dereference(rt->from);
> > + fib6_info_hold(from);
> > + rcu_read_unlock();
> > +
> > + from->fib6_flags = rt->rt6i_flags;
> > + from->fib6_nh.nh_gw = rt->rt6i_gateway;
>
> As I mentioned on your last patch, redirects do *not* update fib
> entries. Exceptions, yes, but not core data of a fib entry.
Thanks for the comments, I understand that we should not update original route.
And here I know the redirect (should?) do not update fib entries.
So Xin Long's patch looks more reasonable.
Thanks
Hangbin
^ permalink raw reply
* Re: [PATCH] net: ipv4: Use BUG_ON directly instead of a if condition followed by BUG
From: Sergei Shtylyov @ 2018-09-11 8:51 UTC (permalink / raw)
To: zhong jiang, davem, edumazet; +Cc: kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <1536590282-23899-1-git-send-email-zhongjiang@huawei.com>
On 9/10/2018 5:38 PM, zhong jiang wrote:
> The if condition can be removed if we use BUG_ON directly.
> The issule is detected with the help of Coccinelle.
Issue?
>
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> net/ipv4/tcp_input.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 62508a2..893bde3 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
> @@ -4934,8 +4934,8 @@ void tcp_rbtree_insert(struct rb_root *root, struct sk_buff *skb)
> BUG_ON(offset < 0);
> if (size > 0) {
> size = min(copy, size);
> - if (skb_copy_bits(skb, offset, skb_put(nskb, size), size))
> - BUG();
> + BUG(skb_copy_bits(skb, offset,
You said BUG_ON()?
> + skb_put(nskb, size), size));
> TCP_SKB_CB(nskb)->end_seq += size;
> copy -= size;
> start += size;
> @@ -5327,8 +5327,8 @@ static void tcp_urg(struct sock *sk, struct sk_buff *skb, const struct tcphdr *t
> /* Is the urgent pointer pointing into this packet? */
> if (ptr < skb->len) {
> u8 tmp;
> - if (skb_copy_bits(skb, ptr, &tmp, 1))
> - BUG();
> +
> + BUG(skb_copy_bits(skb, ptr, &tmp, 1));
Likewise.
[...]
MBR, Sergei
^ permalink raw reply
* Re: [PATCH] net: ipv4: Use BUG_ON directly instead of a if condition followed by BUG
From: zhong jiang @ 2018-09-11 8:59 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: davem, edumazet, kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <a000b5a4-2907-70f9-70ed-7e1c6a797876@cogentembedded.com>
On 2018/9/11 16:51, Sergei Shtylyov wrote:
> On 9/10/2018 5:38 PM, zhong jiang wrote:
>
>> The if condition can be removed if we use BUG_ON directly.
>> The issule is detected with the help of Coccinelle.
>
> Issue?
>
>>
>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>> ---
>> net/ipv4/tcp_input.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index 62508a2..893bde3 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -4934,8 +4934,8 @@ void tcp_rbtree_insert(struct rb_root *root, struct sk_buff *skb)
>> BUG_ON(offset < 0);
>> if (size > 0) {
>> size = min(copy, size);
>> - if (skb_copy_bits(skb, offset, skb_put(nskb, size), size))
>> - BUG();
>> + BUG(skb_copy_bits(skb, offset,
>
> You said BUG_ON()?
Yep. Do you think that it is worthing to do
Thanks,
zhong jiang
>
>> + skb_put(nskb, size), size));
>> TCP_SKB_CB(nskb)->end_seq += size;
>> copy -= size;
>> start += size;
>> @@ -5327,8 +5327,8 @@ static void tcp_urg(struct sock *sk, struct sk_buff *skb, const struct tcphdr *t
>> /* Is the urgent pointer pointing into this packet? */
>> if (ptr < skb->len) {
>> u8 tmp;
>> - if (skb_copy_bits(skb, ptr, &tmp, 1))
>> - BUG();
>> +
>> + BUG(skb_copy_bits(skb, ptr, &tmp, 1));
>
> Likewise.
>
> [...]
>
> MBR, Sergei
>
> .
>
^ permalink raw reply
* Re: [PATCH net-next v3 05/17] zinc: ChaCha20 x86_64 implementation
From: Samuel Neves @ 2018-09-11 9:00 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Jason A. Donenfeld, linux-kernel, netdev, davem,
Greg Kroah-Hartman, Andy Lutomirski, Jean-Philippe Aumasson,
Andy Polyakov, Ingo Molnar, the arch/x86 maintainers,
Linux Crypto Mailing List
In-Reply-To: <alpine.DEB.2.21.1809111021250.5110@nanos.tec.linutronix.de>
On Tue, Sep 11, 2018 at 9:22 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> On Mon, 10 Sep 2018, Jason A. Donenfeld wrote:
>> lib/zinc/Makefile | 4 +
>> lib/zinc/chacha20/chacha20-x86_64-glue.h | 102 +
>> lib/zinc/chacha20/chacha20-x86_64.S | 2632 ++++++++++++++++++++++
>
> Just a stupid question. What's the rationale of putting that into lib/zinc
> instead of having it in arch/x86/crypto?
>
This is covered on the 02/17 commit message, whose relevant paragraph follows:
> It also organizes the implementations in a simple, straight-forward,
> and direct manner, making it enjoyable and intuitive to work on.
> Rather than moving optimized assembly implementations into arch/, it
> keeps them all together in lib/zinc/, making it simple and obvious to
> compare and contrast what's happening. This is, notably, exactly what
> the lib/raid6/ tree does, and that seems to work out rather well. It's
> also the pattern of most successful crypto libraries. The architecture-
> specific glue-code is made a part of each translation unit, rather than
> being in a separate one, so that generic and architecture-optimized code
> are combined at compile-time, and incompatibility branches compiled out by
> the optimizer.
^ permalink raw reply
* Re: [PATCH] PCI: Reprogram bridge prefetch registers on resume
From: Rafael J. Wysocki @ 2018-09-11 9:08 UTC (permalink / raw)
To: Daniel Drake, Bjorn Helgaas
Cc: Peter Wu, linux-pci, Linux Upstreaming Team, nouveau, Linux PM,
kherbst, Andy Shevchenko, Wysocki, Rafael J, Keith Busch,
Mika Westerberg, Jon Derrick, Thomas Martitz, davem, hkallweit1,
netdev, nic_swsd, Linux Kernel
In-Reply-To: <CAD8Lp46eDaSF3fNQgYL=3vCXJ5VpV-JkYEu-YTtuh+w4rMU-5w@mail.gmail.com>
On Tuesday, September 11, 2018 5:35:13 AM CEST Daniel Drake wrote:
> I have created https://bugzilla.kernel.org/show_bug.cgi?id=201069 to
> archive the research done so far.
>
> On Fri, Sep 7, 2018 at 11:05 PM, Peter Wu <peter@lekensteyn.nl> wrote:
> > Windows 10 unconditionally rewrites these registers (BAR, I/O Base +
> > Limit, Memory Base + Limit, etc. from top to bottom), see annotations:
> > https://www.spinics.net/lists/linux-pci/msg75856.html
> >
> > Linux has a generic "restore" operation that works backwards from the
> > end of the PCI config space to the beginning, see
> > pci_restore_config_space. Do you have a dmesg where you see the
> > "restoring config space at offset" messages?
>
> Interesting, I had not spotted this code. The logs for the affected
> bridge on Asus X542UQ:
>
> 0000:00:1c.0: restoring config space at offset 0x3c (was 0x100,
> writing 0x1001ff)
> 0000:00:1c.0: restoring config space at offset 0x24 (was 0x10001,
> writing 0xe1f1d001)
> 0000:00:1c.0: restoring config space at offset 0x20 (was 0x0, writing
> 0xef00ee00)
> 0000:00:1c.0: restoring config space at offset 0xc (was 0x810000,
> writing 0x810010)
> 0000:00:1c.0: restoring config space at offset 0x4 (was 0x100007,
> writing 0x100407)
>
> So it didn't restore 0x28 (the magic register) and also register 0x2c
> (prefetch limit upper 32 bits) because their values were already 0 on
> resume.
>
> https://bugzilla.kernel.org/show_bug.cgi?id=116851#c23 has an
> assertion that Intel recognises this issue and calls for all those
> registers to be restored on resume.
>
> I propose for Linux 4.19 we apply a minimally intrusive change that
> "forcibly" restores dword registers 0x24, 0x28 and 0x2c for PCI
> bridges (regardless of their current value), while retaining the
> existing restore order (high to low) over all registers and doing the
> read-then-maybe-write thing for all of the other regs (per current
> behaviour).
I agree here. It would be good to cover this gap and possibly backport
the fix to "stable".
> Then we also consider swiftly applying a followup patch implementing a
> more thorough approach and we give it some time in linux-next before
> releasing in Linux 4.20 which does something more thorough. I think
> perhaps more discussion is needed there, or at least some more input
> from Bjorn. Seems like we have 3 approaches to consider:
>
> 1. Peter Wu suggests following what windows does. Windows appears to
> start with low registers and works its way upwards, which means it
> writes BAR addresses, I/O base, etc, before writing prefetch
> registers. It skips over read-only and write-to-clear registers and
> also only writes some of the registers at the very end - like the
> command register.
>
> To be thorough here we would probably also have to study and copy what
> Windows does for non-bridge devices (not sure how many device classes
> we would want to study here?). Also it is a bit risky in that Bjorn
> has pointed out that Linux's earlier approach with a high level of
> similarity here (restore registers in ascending order, regardless of
> their current value) caused a laptop to hang on resume.
>
>
> 2. Bjorn suggested tweaking the existing code to always write the
> saved value even when the hardware has that same value. The
> read-maybe-write logic was introduced to avoid a laptop hang, but at
> that time we were restoring registers in ascending order, now we are
> descending it might be worth giving this another try.
I agree with Bjorn here.
> 3. Do nothing else beyond the minimal change that I propose for v4.19?
> Looking a bit more into git history this seems to be a sensitive and
> problematic area, more changes might mean more trouble. For example
> right now pci_restore_config_space() does:
> pci_restore_config_space_range(pdev, 10, 15, 0, 0);
> /* Restore BARs before the command register. */
> pci_restore_config_space_range(pdev, 4, 9, 10, 0);
> pci_restore_config_space_range(pdev, 0, 3, 0, 0);
> but pci_restore_config_space_range() already goes in descending order,
> so the above is already equivalent to the code in the "else" path that
> follows:
> pci_restore_config_space_range(pdev, 0, 15, 0, 0);
>
> and if you look at the history behind this "mixup" there's stuff that
> goes back to 2012 like commit a6cb9ee7cabe ("PCI: Retry BARs
> restoration for Type 0 headers only") which was fixing up another
> problematic commit in this area, etc.
So let's first fix what's known broken and see how this goes IMO.
On top of that and later, try to make the changes suggested by Bjorn and see
how far we can get with that.
Having done that, revisit and see if there still are any problems to address
in this area.
Thanks,
Rafael
^ permalink raw reply
* Re: [PATCH net-next v3 05/17] zinc: ChaCha20 x86_64 implementation
From: Thomas Gleixner @ 2018-09-11 9:09 UTC (permalink / raw)
To: Samuel Neves
Cc: Jason A. Donenfeld, linux-kernel, netdev, davem,
Greg Kroah-Hartman, Andy Lutomirski, Jean-Philippe Aumasson,
Andy Polyakov, Ingo Molnar, the arch/x86 maintainers,
Linux Crypto Mailing List
In-Reply-To: <CAEX_ruFFWsW897DuFEbz9+6av02bMwDgiA9GxV+=SBtyKG7LJw@mail.gmail.com>
On Tue, 11 Sep 2018, Samuel Neves wrote:
> On Tue, Sep 11, 2018 at 9:22 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Mon, 10 Sep 2018, Jason A. Donenfeld wrote:
> >> lib/zinc/Makefile | 4 +
> >> lib/zinc/chacha20/chacha20-x86_64-glue.h | 102 +
> >> lib/zinc/chacha20/chacha20-x86_64.S | 2632 ++++++++++++++++++++++
> >
> > Just a stupid question. What's the rationale of putting that into lib/zinc
> > instead of having it in arch/x86/crypto?
> >
>
> This is covered on the 02/17 commit message, whose relevant paragraph follows:
Well, being only cc'ed on only half of the patches does not really help.
> > It also organizes the implementations in a simple, straight-forward,
> > and direct manner, making it enjoyable and intuitive to work on.
> > Rather than moving optimized assembly implementations into arch/, it
> > keeps them all together in lib/zinc/, making it simple and obvious to
> > compare and contrast what's happening. This is, notably, exactly what
> > the lib/raid6/ tree does, and that seems to work out rather well. It's
> > also the pattern of most successful crypto libraries. The architecture-
> > specific glue-code is made a part of each translation unit, rather than
> > being in a separate one, so that generic and architecture-optimized code
> > are combined at compile-time, and incompatibility branches compiled out by
> > the optimizer.
Fair enough.
^ permalink raw reply
* Re: [PATCH] net: ipv4: Use BUG_ON directly instead of a if condition followed by BUG
From: zhong jiang @ 2018-09-11 9:19 UTC (permalink / raw)
To: Sergei Shtylyov; +Cc: davem, edumazet, kuznet, yoshfuji, netdev, linux-kernel
In-Reply-To: <e1b9c36c-5459-a68e-e6fd-cca038e31d5f@cogentembedded.com>
On 2018/9/11 17:11, Sergei Shtylyov wrote:
> On 9/11/2018 11:59 AM, zhong jiang wrote:
>
>>>> The if condition can be removed if we use BUG_ON directly.
>>>> The issule is detected with the help of Coccinelle.
>>>
>>> Issue?
>>>
>>>>
>>>> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
>>>> ---
>>>> net/ipv4/tcp_input.c | 8 ++++----
>>>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>>>> index 62508a2..893bde3 100644
>>>> --- a/net/ipv4/tcp_input.c
>>>> +++ b/net/ipv4/tcp_input.c
>>>> @@ -4934,8 +4934,8 @@ void tcp_rbtree_insert(struct rb_root *root, struct sk_buff *skb)
>>>> BUG_ON(offset < 0);
>>>> if (size > 0) {
>>>> size = min(copy, size);
>>>> - if (skb_copy_bits(skb, offset, skb_put(nskb, size), size))
>>>> - BUG();
>>>> + BUG(skb_copy_bits(skb, offset,
>>>
>>> You said BUG_ON()?
>> Yep. Do you think that it is worthing to do
>
> I think BUG() doesn't take parameters, BUG_ON() does. Have you tried to build the kernel with your patch at all?
>
I know that the patch should be BUG_ON instead of BUG. This is my mistake. I just want to know that it is worthing to do so.
Thanks,
zhong jiang
>> Thanks,
>> zhong jiang
> [...]
>
> MBR, Sergei
>
>
>
^ permalink raw reply
* [PATCH v2] kcm: remove any offset before parsing messages
From: Dominique Martinet @ 2018-09-11 9:21 UTC (permalink / raw)
To: Doron Roberts-Kedes, Tom Herbert, Dave Watson
Cc: Dominique Martinet, David S. Miller, netdev, linux-kernel
The current code assumes kcm users know they need to look for the
strparser offset within their bpf program, which is not documented
anywhere and examples laying around do not do.
The actual recv function does handle the offset well, so we can create a
temporary clone of the skb and pull that one up as required for parsing.
The pull itself has a cost if we are pulling beyond the head data,
measured to 2-3% latency in a noisy VM with a local client stressing
that path. The clone's impact seemed too small to measure.
This bug can be exhibited easily by implementing a "trivial" kcm parser
taking the first bytes as size, and on the client sending at least two
such packets in a single write().
Note that bpf sockmap has the same problem, both for parse and for recv,
so it would pulling twice or a real pull within the strparser logic if
anyone cares about that.
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
---
Hmm, while trying to benchmark this, I sometimes got hangs in
kcm_wait_data() for the last packet somehow?
The sender program was done (exited (zombie) so I assumed the sender
socket flushed), but the receiver was in kcm_wait_data in kcm_recvmsg
indicating it parsed a header but there was no skb to peek at?
But the sock is locked so this shouldn't be racy...
I can get it fairly often with this patch and small messages with an
offset, but I think it's just because the pull changes some timing - I
can't hit it with just the clone, and I can hit it with a pull without
clone as well.... And I don't see how pulling a cloned skb can impact
the original socket, but I'm a bit fuzzy on this.
(it's interesting that I didn't seem to hit this race when pulling in
strparser, that shouldn't be any different)
I'll look at that a bit more, but there have been no activity here for
a while and I don't have the energy to keep pushing in the strparser
direction, so take this patch more as a change of direction and a bit
as a 'bump' on the subject - I think it's important but I have too much
on my plate right now to keep pushing if there is no interest from the
authors.
net/kcm/kcmsock.c | 26 +++++++++++++++++++++++++-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/net/kcm/kcmsock.c b/net/kcm/kcmsock.c
index 571d824e4e24..36c438b95955 100644
--- a/net/kcm/kcmsock.c
+++ b/net/kcm/kcmsock.c
@@ -381,8 +381,32 @@ static int kcm_parse_func_strparser(struct strparser *strp, struct sk_buff *skb)
{
struct kcm_psock *psock = container_of(strp, struct kcm_psock, strp);
struct bpf_prog *prog = psock->bpf_prog;
+ struct sk_buff *clone_skb = NULL;
+ struct strp_msg *stm;
+ int rc;
+
+ stm = strp_msg(skb);
+ if (stm->offset) {
+ skb = clone_skb = skb_clone(skb, GFP_ATOMIC);
+ if (!clone_skb)
+ return -ENOMEM;
+
+ if (!pskb_pull(clone_skb, stm->offset)) {
+ rc = -ENOMEM;
+ goto out;
+ }
+
+ /* reset cloned skb's offset for bpf programs using it */
+ stm = strp_msg(clone_skb);
+ stm->offset = 0;
+ }
+
+ rc = (*prog->bpf_func)(skb, prog->insnsi);
+out:
+ if (clone_skb)
+ kfree_skb(clone_skb);
- return (*prog->bpf_func)(skb, prog->insnsi);
+ return rc;
}
static int kcm_read_sock_done(struct strparser *strp, int err)
--
2.17.1
^ permalink raw reply related
* Re: libbpf build broken on musl libc (Alpine Linux)
From: Jakub Kicinski @ 2018-09-11 10:22 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: Daniel Borkmann, Thomas Richter, Hendrik Brueckner,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180910172903.GB15516@kernel.org>
On Mon, 10 Sep 2018 14:29:03 -0300, Arnaldo Carvalho de Melo wrote:
> After lunch I'll work on a patch to fix this,
Hi Arnaldo!
Any luck?
^ permalink raw reply
* Re: [PATCH RESEND net-next] docs: net: Convert tcp.txt to RST format
From: Eric Dumazet @ 2018-09-11 10:30 UTC (permalink / raw)
To: Tobin C. Harding, David S. Miller
Cc: Eric Dumazet, netdev, linux-doc, linux-kernel
In-Reply-To: <20180911071324.11199-1-me@tobin.cc>
On 09/11/2018 12:13 AM, Tobin C. Harding wrote:
> Restructured text is the kernel documentation format of choice now.
> Some text from tcp.txt is out of date, specifically the function
> tcp_write() does not appear to be in the tree anymore. Also the
> following data members have been removed
>
> sk->tcp_pend_event
> sk->transmit_queue
> sk->transmit_new
> sk->transmit_end
> sk->tcp_last_tx_ack
> sk->tcp_dup_ack
>
> Remove section 'How the new TCP output machine [nyi] works'. This
> leaves only a single section so we can name the document with that
> section heading now.
>
> Convert tcp.txt to RST format. Add GPLv2 SPDX tag.
>
> Signed-off-by: Tobin C. Harding <me@tobin.cc>
>
I dunno, this 'doc' is probably useless and should be deleted.
^ permalink raw reply
* Re: general protection fault in rhashtable_walk_exit
From: syzbot @ 2018-09-11 6:05 UTC (permalink / raw)
To: davem, jon.maloy, linux-kernel, netdev, syzkaller-bugs,
tipc-discussion, ying.xue
In-Reply-To: <0000000000005c23ca0575803f6d@google.com>
syzbot has found a reproducer for the following crash on:
HEAD commit: 7c5cca358854 qmi_wwan: Support dynamic config on Quectel E..
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=10ea5bb6400000
kernel config: https://syzkaller.appspot.com/x/.config?x=8f59875069d721b6
dashboard link: https://syzkaller.appspot.com/bug?extid=3f8324abccfbf8c74a9f
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=1029be66400000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11f7cd49400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+3f8324abccfbf8c74a9f@syzkaller.appspotmail.com
RBP: 0000000000000004 R08: 0000000000000001 R09: 0000000000000100
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 6713 Comm: syz-executor470 Not tainted 4.19.0-rc2+ #94
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:rhashtable_walk_exit+0x74/0x360 lib/rhashtable.c:689
Code: 8e 83 c7 00 f1 f1 f1 f1 c7 40 04 00 f2 f2 f2 65 48 8b 04 25 28 00 00
00 48 89 45 d0 31 c0 e8 13 28 f0 fd 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00
0f 85 e5 01 00 00 48 8b 03 48 8d b8 00 01 00 00 e8
RSP: 0018:ffff8801b77d70e8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff838ea71d RDI: 0000000000000000
RBP: ffff8801b77d7188 R08: ffff8801d3334680 R09: ffffed003a877e54
R10: ffffed003a877e54 R11: ffff8801d43bf2a3 R12: 1ffff10036efae20
R13: dffffc0000000000 R14: ffff8801b77d7160 R15: dffffc0000000000
FS: 0000000002080880(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004b5abc CR3: 00000001ce4b7000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
tipc_dump_done+0x34/0x50 net/tipc/socket.c:3295
__tipc_nl_compat_dumpit.isra.11+0x670/0xb30 net/tipc/netlink_compat.c:220
tipc_nl_compat_dumpit+0x1f4/0x440 net/tipc/netlink_compat.c:267
tipc_nl_compat_handle net/tipc/netlink_compat.c:1169 [inline]
tipc_nl_compat_recv+0x14a0/0x19a0 net/tipc/netlink_compat.c:1207
genl_family_rcv_msg+0x8a9/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+0x5a5/0x760 net/netlink/af_netlink.c:1343
netlink_sendmsg+0xa18/0xfc0 net/netlink/af_netlink.c:1908
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xd5/0x120 net/socket.c:631
___sys_sendmsg+0x7fd/0x930 net/socket.c:2114
__sys_sendmsg+0x11d/0x280 net/socket.c:2152
__do_sys_sendmsg net/socket.c:2161 [inline]
__se_sys_sendmsg net/socket.c:2159 [inline]
__x64_sys_sendmsg+0x78/0xb0 net/socket.c:2159
do_syscall_64+0x1b9/0x820 arch/x86/entry/common.c:290
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x441d39
Code: e8 4c e8 ff ff 48 83 c4 18 c3 0f 1f 80 00 00 00 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 4b 04 fc ff c3 66 2e 0f 1f 84 00 00 00 00
RSP: 002b:00007fffc3125798 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fffc31257b0 RCX: 0000000000441d39
RDX: 0000000000000000 RSI: 0000000020000100 RDI: 0000000000000003
RBP: 0000000000000004 R08: 0000000000000001 R09: 0000000000000100
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: ffffffffffffffff R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 037223c8463c1458 ]---
RIP: 0010:rhashtable_walk_exit+0x74/0x360 lib/rhashtable.c:689
Code: 8e 83 c7 00 f1 f1 f1 f1 c7 40 04 00 f2 f2 f2 65 48 8b 04 25 28 00 00
00 48 89 45 d0 31 c0 e8 13 28 f0 fd 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00
0f 85 e5 01 00 00 48 8b 03 48 8d b8 00 01 00 00 e8
RSP: 0018:ffff8801b77d70e8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff838ea71d RDI: 0000000000000000
RBP: ffff8801b77d7188 R08: ffff8801d3334680 R09: ffffed003a877e54
R10: ffffed003a877e54 R11: ffff8801d43bf2a3 R12: 1ffff10036efae20
R13: dffffc0000000000 R14: ffff8801b77d7160 R15: dffffc0000000000
FS: 0000000002080880(0000) GS:ffff8801daf00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000004b5abc CR3: 00000001ce4b7000 CR4: 00000000001406e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
^ permalink raw reply
* Re: [PATCH net-next] net: bridge: add support for sticky fdb entries
From: Nikolay Aleksandrov @ 2018-09-11 6:23 UTC (permalink / raw)
To: Grygorii Strashko, Stephen Hemminger; +Cc: netdev, roopa, davem, bridge
In-Reply-To: <38bfcada-abea-be8d-c794-154113ca17f8@cumulusnetworks.com>
On 11/09/18 02:55, Nikolay Aleksandrov wrote:
> On 11/09/18 02:22, Grygorii Strashko wrote:
>>
>>
>> On 09/10/2018 04:18 PM, Stephen Hemminger wrote:
>>> On Mon, 10 Sep 2018 13:16:01 +0300
>>> Nikolay Aleksandrov <nikolay@cumulusnetworks.com> wrote:
>>>
>>>> Add support for entries which are "sticky", i.e. will not change their port
>>>> if they show up from a different one. A new ndm flag is introduced for that
>>>> purpose - NTF_STICKY. We allow to set it only to non-local entries.
>>>
>>> Is there a name for this in other network switch API's?
>>
>> In TI CPSW hardware we have following definition for similar FDB/ALE entries
>> (AM437x TRM - 15.3.2.7.1.4 Unicast Address Table Entry):
>>
>> Block (BLOCK) – The block bit indicates that a packet with a matching source or
>> destination address should be dropped (block the address).
>> 0 – Address is not blocked.
>> 1 – Drop a packet with a matching source or destination address (secure must be zero)
>> If block and secure are both set, then they no longer mean block and secure.
>> When both are set, the block and secure bits indicate that the packet is
>> a unicast supervisory (super) packet and they determine the unicast forward state test criteria.
>> If both bits are set then the packet is forwarded if the receive port is in
>> the Forwarding/Blocking/Learning state.
>> If both bits are not set then the packet is forwarded if the receive port is in
>> the Forwarding state.
>>
>> Secure (SECURE) - This bit indicates that a packet with a matching source address
>> should be dropped if the received port number is not equal to the table entry port_number.
>> 0 – Received port number is a don’t care.
>> 1 – Drop the packet if the received port is not the secure port for the source
>> address and do not update the address (block must be zero)
>>
>> Updating Process:
>> if ((source address found) and (receive port number != port_number) and (secure or block))
>> then do not update address
>>
>> "sticky" would mean SECURE+BLOCK = supervisory (super) packet
>>
>
> That could work. but we haven't really made any arrangements w.r.t. to current implementations.
> So if IUC secure+block should be:
> - block:
> 1 – Drop a packet with a matching source or destination address (secure must be zero)
> If block and secure are both set, then they no longer mean block and secure.>
> - secure:
> 1 – Drop the packet if the received port is not the secure port for the source
> address and do not update the address (block must be zero)
>
> These could mean a very different config based on their description. Feel free to add.
>
Nevermind my comment, got it. To support them fully though we will need to have more options.
They should be achievable through firewall as well.
>>>
>>>>
>>>> Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
>>>> ---
>>>> I'll send the selftest for sticky with the iproute2 patch if this one is
>>>> accepted. We've had multiple requests to support such flag and now it's
>>>> also needed for some eVPN and clag setups.
>>>>
>>>> include/uapi/linux/neighbour.h | 1 +
>>>> net/bridge/br_fdb.c | 19 ++++++++++++++++---
>>>> net/bridge/br_private.h | 1 +
>>>> 3 files changed, 18 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/include/uapi/linux/neighbour.h b/include/uapi/linux/neighbour.h
>>>> index 904db6148476..998155444e0d 100644
>>>> --- a/include/uapi/linux/neighbour.h
>>>> +++ b/include/uapi/linux/neighbour.h
>>>> @@ -43,6 +43,7 @@ enum {
>>>> #define NTF_PROXY 0x08 /* == ATF_PUBL */
>>>> #define NTF_EXT_LEARNED 0x10
>>>> #define NTF_OFFLOADED 0x20
>>>> +#define NTF_STICKY 0x40
>>>> #define NTF_ROUTER 0x80
>>>>
>>>> /*
>>>> diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
>>>> index 502f66349530..26569ed06a4d 100644
>>>> --- a/net/bridge/br_fdb.c
>>>> +++ b/net/bridge/br_fdb.c
>>>> @@ -584,7 +584,7 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source,
>>>> unsigned long now = jiffies;
>>>>
>>>> /* fastpath: update of existing entry */
>>>> - if (unlikely(source != fdb->dst)) {
>>>> + if (unlikely(source != fdb->dst && !fdb->is_sticky)) {
>>>> fdb->dst = source;
>>>> fdb_modified = true;
>>>> /* Take over HW learned entry */
>>>> @@ -656,6 +656,8 @@ static int fdb_fill_info(struct sk_buff *skb, const struct net_bridge *br,
>>>> ndm->ndm_flags |= NTF_OFFLOADED;
>>>> if (fdb->added_by_external_learn)
>>>> ndm->ndm_flags |= NTF_EXT_LEARNED;
>>>> + if (fdb->is_sticky)
>>>> + ndm->ndm_flags |= NTF_STICKY;
>>>>
>>>> if (nla_put(skb, NDA_LLADDR, ETH_ALEN, &fdb->key.addr))
>>>> goto nla_put_failure;
>>>> @@ -772,7 +774,8 @@ int br_fdb_dump(struct sk_buff *skb,
>>>>
>>>> /* Update (create or replace) forwarding database entry */
>>>> static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
>>>> - const __u8 *addr, __u16 state, __u16 flags, __u16 vid)
>>>> + const u8 *addr, u16 state, u16 flags, u16 vid,
>>>> + u8 is_sticky)
>>>
>>> Why not change the API to take a full ndm flags, someone is sure to add more later.
>
> Sure, I've added a similar "fix" on my bridge todo list which is getting very long by the way,
>
> but it is not the point of this patch.
>
I'll send v2 with your proposed change, indeed more people will probably make use of it in the
future. Thanks for the feedback.
Cheers,
Nik
^ permalink raw reply
* [PATCHv2 net] ipv6: use rt6_info members when dst is set in rt6_fill_node
From: Xin Long @ 2018-09-11 6:33 UTC (permalink / raw)
To: network dev; +Cc: davem, David Ahern, Roopa Prabhu
In inet6_rtm_getroute, since Commit 93531c674315 ("net/ipv6: separate
handling of FIB entries from dst based routes"), it has used rt->from
to dump route info instead of rt.
However for some route like cache, some of its information like flags
or gateway is not the same as that of the 'from' one. It caused 'ip
route get' to dump the wrong route information.
In Jianlin's testing, the output information even lost the expiration
time for a pmtu route cache due to the wrong fib6_flags.
So change to use rt6_info members for dst addr, src addr, flags and
gateway when it tries to dump a route entry without fibmatch set.
v1->v2:
- not use rt6i_prefsrc.
- also fix the gw dump issue.
Fixes: 93531c674315 ("net/ipv6: separate handling of FIB entries from dst based routes")
Reported-by: Jianlin Shi <jishi@redhat.com>
Signed-off-by: Xin Long <lucien.xin@gmail.com>
---
net/ipv6/route.c | 42 ++++++++++++++++++++++++++++++------------
1 file changed, 30 insertions(+), 12 deletions(-)
diff --git a/net/ipv6/route.c b/net/ipv6/route.c
index 18e00ce..3eed045 100644
--- a/net/ipv6/route.c
+++ b/net/ipv6/route.c
@@ -4670,20 +4670,31 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
int iif, int type, u32 portid, u32 seq,
unsigned int flags)
{
- struct rtmsg *rtm;
+ struct rt6_info *rt6 = (struct rt6_info *)dst;
+ struct rt6key *rt6_dst, *rt6_src;
+ u32 *pmetrics, table, rt6_flags;
struct nlmsghdr *nlh;
+ struct rtmsg *rtm;
long expires = 0;
- u32 *pmetrics;
- u32 table;
nlh = nlmsg_put(skb, portid, seq, type, sizeof(*rtm), flags);
if (!nlh)
return -EMSGSIZE;
+ if (rt6) {
+ rt6_dst = &rt6->rt6i_dst;
+ rt6_src = &rt6->rt6i_src;
+ rt6_flags = rt6->rt6i_flags;
+ } else {
+ rt6_dst = &rt->fib6_dst;
+ rt6_src = &rt->fib6_src;
+ rt6_flags = rt->fib6_flags;
+ }
+
rtm = nlmsg_data(nlh);
rtm->rtm_family = AF_INET6;
- rtm->rtm_dst_len = rt->fib6_dst.plen;
- rtm->rtm_src_len = rt->fib6_src.plen;
+ rtm->rtm_dst_len = rt6_dst->plen;
+ rtm->rtm_src_len = rt6_src->plen;
rtm->rtm_tos = 0;
if (rt->fib6_table)
table = rt->fib6_table->tb6_id;
@@ -4698,7 +4709,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
rtm->rtm_scope = RT_SCOPE_UNIVERSE;
rtm->rtm_protocol = rt->fib6_protocol;
- if (rt->fib6_flags & RTF_CACHE)
+ if (rt6_flags & RTF_CACHE)
rtm->rtm_flags |= RTM_F_CLONED;
if (dest) {
@@ -4706,7 +4717,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
rtm->rtm_dst_len = 128;
} else if (rtm->rtm_dst_len)
- if (nla_put_in6_addr(skb, RTA_DST, &rt->fib6_dst.addr))
+ if (nla_put_in6_addr(skb, RTA_DST, &rt6_dst->addr))
goto nla_put_failure;
#ifdef CONFIG_IPV6_SUBTREES
if (src) {
@@ -4714,12 +4725,12 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
rtm->rtm_src_len = 128;
} else if (rtm->rtm_src_len &&
- nla_put_in6_addr(skb, RTA_SRC, &rt->fib6_src.addr))
+ nla_put_in6_addr(skb, RTA_SRC, &rt6_src->addr))
goto nla_put_failure;
#endif
if (iif) {
#ifdef CONFIG_IPV6_MROUTE
- if (ipv6_addr_is_multicast(&rt->fib6_dst.addr)) {
+ if (ipv6_addr_is_multicast(&rt6_dst->addr)) {
int err = ip6mr_get_route(net, skb, rtm, portid);
if (err == 0)
@@ -4754,7 +4765,14 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
/* For multipath routes, walk the siblings list and add
* each as a nexthop within RTA_MULTIPATH.
*/
- if (rt->fib6_nsiblings) {
+ if (rt6) {
+ if (rt6_flags & RTF_GATEWAY &&
+ nla_put_in6_addr(skb, RTA_GATEWAY, &rt6->rt6i_gateway))
+ goto nla_put_failure;
+
+ if (dst->dev && nla_put_u32(skb, RTA_OIF, dst->dev->ifindex))
+ goto nla_put_failure;
+ } else if (rt->fib6_nsiblings) {
struct fib6_info *sibling, *next_sibling;
struct nlattr *mp;
@@ -4777,7 +4795,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
goto nla_put_failure;
}
- if (rt->fib6_flags & RTF_EXPIRES) {
+ if (rt6_flags & RTF_EXPIRES) {
expires = dst ? dst->expires : rt->expires;
expires -= jiffies;
}
@@ -4785,7 +4803,7 @@ static int rt6_fill_node(struct net *net, struct sk_buff *skb,
if (rtnl_put_cacheinfo(skb, dst, 0, expires, dst ? dst->error : 0) < 0)
goto nla_put_failure;
- if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(rt->fib6_flags)))
+ if (nla_put_u8(skb, RTA_PREF, IPV6_EXTRACT_PREF(rt6_flags)))
goto nla_put_failure;
--
2.1.0
^ permalink raw reply related
* [PATCH net-next v2] net: bridge: add support for sticky fdb entries
From: Nikolay Aleksandrov @ 2018-09-11 6:39 UTC (permalink / raw)
To: netdev; +Cc: roopa, davem, bridge, stephen, Nikolay Aleksandrov
In-Reply-To: <20180910141802.268e85c5@shemminger-XPS-13-9360>
Add support for entries which are "sticky", i.e. will not change their port
if they show up from a different one. A new ndm flag is introduced for that
purpose - NTF_STICKY. We allow to set it only to non-local entries.
Signed-off-by: Nikolay Aleksandrov <nikolay@cumulusnetworks.com>
---
v2: As Stephen suggested pass the whole ndm_flags because it will probably
be used by someone else soon.
I'll send the selftest for sticky with the iproute2 patch if this one is
accepted. We've had multiple requests to support such flag and now it's
also needed for some eVPN and clag setups.
include/uapi/linux/neighbour.h | 1 +
net/bridge/br_fdb.c | 19 ++++++++++++++++---
net/bridge/br_private.h | 1 +
3 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/neighbour.h b/include/uapi/linux/neighbour.h
index 904db6148476..998155444e0d 100644
--- a/include/uapi/linux/neighbour.h
+++ b/include/uapi/linux/neighbour.h
@@ -43,6 +43,7 @@ enum {
#define NTF_PROXY 0x08 /* == ATF_PUBL */
#define NTF_EXT_LEARNED 0x10
#define NTF_OFFLOADED 0x20
+#define NTF_STICKY 0x40
#define NTF_ROUTER 0x80
/*
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 502f66349530..a56ed7f2a3a3 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -584,7 +584,7 @@ void br_fdb_update(struct net_bridge *br, struct net_bridge_port *source,
unsigned long now = jiffies;
/* fastpath: update of existing entry */
- if (unlikely(source != fdb->dst)) {
+ if (unlikely(source != fdb->dst && !fdb->is_sticky)) {
fdb->dst = source;
fdb_modified = true;
/* Take over HW learned entry */
@@ -656,6 +656,8 @@ static int fdb_fill_info(struct sk_buff *skb, const struct net_bridge *br,
ndm->ndm_flags |= NTF_OFFLOADED;
if (fdb->added_by_external_learn)
ndm->ndm_flags |= NTF_EXT_LEARNED;
+ if (fdb->is_sticky)
+ ndm->ndm_flags |= NTF_STICKY;
if (nla_put(skb, NDA_LLADDR, ETH_ALEN, &fdb->key.addr))
goto nla_put_failure;
@@ -772,8 +774,10 @@ int br_fdb_dump(struct sk_buff *skb,
/* Update (create or replace) forwarding database entry */
static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
- const __u8 *addr, __u16 state, __u16 flags, __u16 vid)
+ const u8 *addr, u16 state, u16 flags, u16 vid,
+ u8 ndm_flags)
{
+ u8 is_sticky = !!(ndm_flags & NTF_STICKY);
struct net_bridge_fdb_entry *fdb;
bool modified = false;
@@ -789,6 +793,9 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
return -EINVAL;
}
+ if (is_sticky && (state & NUD_PERMANENT))
+ return -EINVAL;
+
fdb = br_fdb_find(br, addr, vid);
if (fdb == NULL) {
if (!(flags & NLM_F_CREATE))
@@ -832,6 +839,12 @@ static int fdb_add_entry(struct net_bridge *br, struct net_bridge_port *source,
modified = true;
}
+
+ if (is_sticky != fdb->is_sticky) {
+ fdb->is_sticky = is_sticky;
+ modified = true;
+ }
+
fdb->added_by_user = 1;
fdb->used = jiffies;
@@ -865,7 +878,7 @@ static int __br_fdb_add(struct ndmsg *ndm, struct net_bridge *br,
} else {
spin_lock_bh(&br->hash_lock);
err = fdb_add_entry(br, p, addr, ndm->ndm_state,
- nlh_flags, vid);
+ nlh_flags, vid, ndm->ndm_flags);
spin_unlock_bh(&br->hash_lock);
}
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 11ed2029985f..d21035a17f4c 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -181,6 +181,7 @@ struct net_bridge_fdb_entry {
struct hlist_node fdb_node;
unsigned char is_local:1,
is_static:1,
+ is_sticky:1,
added_by_user:1,
added_by_external_learn:1,
offloaded:1;
--
2.11.0
^ permalink raw reply related
* Re: unexpected GRO/veth behavior
From: Paolo Abeni @ 2018-09-11 6:54 UTC (permalink / raw)
To: netdev; +Cc: eric.dumazet, Toshiaki Makita
In-Reply-To: <4106d3f7eee7f0186fcfdd0331cdafeecd3240c0.camel@redhat.com>
Hi,
On Mon, 2018-09-10 at 16:44 +0200, Paolo Abeni wrote:
> while testing some local patches I observed that the TCP tput in the
> following scenario:
>
> # the following enable napi on veth0, so that we can trigger the
> # GRO path with namespaces
> ip netns add test
> ip link add type veth
> ip link set dev veth0 netns test
> ip -n test link set lo up
> ip -n test link set veth0 up
> ip -n test addr add dev veth0 172.16.1.2/24
> ip link set dev veth1 up
> ip addr add dev veth1 172.16.1.1/24
> IDX=`ip netns exec test cat /sys/class/net/veth0/ifindex`
>
> # 'xdp_pass' is a NO-OP XDP program that simply return XDP_PASS
> ip netns exec test ./xdp_pass $IDX &
> taskset 0x2 ip netns exec test iperf3 -s -i 60 &
> taskset 0x1 iperf3 -c 172.16.1.2 -t 60 -i 60
In the same scenario, using instead:
iperf3 -c 172.16.1.2 -t 600 -i 60 -N -l 10K
I hit the following splat, on a recent, unpatched net-next:
[ 362.098904] refcount_t overflow at skb_set_owner_w+0x5e/0xa0 in iperf3[1644], uid/euid: 0/0
[ 362.108239] WARNING: CPU: 0 PID: 1644 at kernel/panic.c:648 refcount_error_report+0xa0/0xa4
[ 362.117547] Modules linked in: tcp_diag inet_diag veth intel_rapl sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel intel_cstate intel_uncore intel_rapl_perf ipmi_ssif iTCO_wdt sg ipmi_si iTCO_vendor_support ipmi_devintf mxm_wmi ipmi_msghandler pcspkr dcdbas mei_me wmi mei lpc_ich acpi_power_meter pcc_cpufreq xfs libcrc32c sd_mod mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ixgbe igb ttm ahci mdio libahci ptp crc32c_intel drm pps_core libata i2c_algo_bit dca dm_mirror dm_region_hash dm_log dm_mod
[ 362.176622] CPU: 0 PID: 1644 Comm: iperf3 Not tainted 4.19.0-rc2.vanilla+ #2025
[ 362.184777] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.1.7 06/16/2016
[ 362.193124] RIP: 0010:refcount_error_report+0xa0/0xa4
[ 362.198758] Code: 08 00 00 48 8b 95 80 00 00 00 49 8d 8c 24 80 0a 00 00 41 89 c1 44 89 2c 24 48 89 de 48 c7 c7 18 4d e7 9d 31 c0 e8 30 fa ff ff <0f> 0b eb 88 0f 1f 44 00 00 55 48 89 e5 41 56 41 55 41 54 49 89 fc
[ 362.219711] RSP: 0018:ffff9ee6ff603c20 EFLAGS: 00010282
[ 362.225538] RAX: 0000000000000000 RBX: ffffffff9de83e10 RCX: 0000000000000000
[ 362.233497] RDX: 0000000000000001 RSI: ffff9ee6ff6167d8 RDI: ffff9ee6ff6167d8
[ 362.241457] RBP: ffff9ee6ff603d78 R08: 0000000000000490 R09: 0000000000000004
[ 362.249416] R10: 0000000000000000 R11: ffff9ee6ff603990 R12: ffff9ee664b94500
[ 362.257377] R13: 0000000000000000 R14: 0000000000000004 R15: ffffffff9de615f9
[ 362.265337] FS: 00007f1d22d28740(0000) GS:ffff9ee6ff600000(0000) knlGS:0000000000000000
[ 362.274363] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 362.280773] CR2: 00007f1d222f35d0 CR3: 0000001fddfec003 CR4: 00000000001606f0
[ 362.288733] Call Trace:
[ 362.291459] <IRQ>
[ 362.293702] ex_handler_refcount+0x4e/0x80
[ 362.298269] fixup_exception+0x35/0x40
[ 362.302451] do_trap+0x109/0x150
[ 362.306048] do_error_trap+0xd5/0x130
[ 362.315766] invalid_op+0x14/0x20
[ 362.319460] RIP: 0010:skb_set_owner_w+0x5e/0xa0
[ 362.324512] Code: ef ff ff 74 49 48 c7 43 60 20 7b 4a 9d 8b 85 f4 01 00 00 85 c0 75 16 8b 83 e0 00 00 00 f0 01 85 44 01 00 00 0f 88 d8 23 16 00 <5b> 5d c3 80 8b 91 00 00 00 01 8b 85 f4 01 00 00 89 83 a4 00 00 00
[ 362.345465] RSP: 0018:ffff9ee6ff603e20 EFLAGS: 00010a86
[ 362.351291] RAX: 0000000000001100 RBX: ffff9ee65deec700 RCX: ffff9ee65e829244
[ 362.359250] RDX: 0000000000000100 RSI: ffff9ee65e829100 RDI: ffff9ee65deec700
[ 362.367210] RBP: ffff9ee65e829100 R08: 000000000002a380 R09: 0000000000000000
[ 362.375169] R10: 0000000000000002 R11: fffff1a4bf77bb00 R12: ffffc0754661d000
[ 362.383130] R13: ffff9ee65deec200 R14: ffff9ee65f597000 R15: 00000000000000aa
[ 362.391092] veth_xdp_rcv+0x4e4/0x890 [veth]
[ 362.399357] veth_poll+0x4d/0x17a [veth]
[ 362.403731] net_rx_action+0x2af/0x3f0
[ 362.407912] __do_softirq+0xdd/0x29e
[ 362.411897] do_softirq_own_stack+0x2a/0x40
[ 362.416561] </IRQ>
[ 362.418899] do_softirq+0x4b/0x70
[ 362.422594] __local_bh_enable_ip+0x50/0x60
[ 362.427258] ip_finish_output2+0x16a/0x390
[ 362.431824] ip_output+0x71/0xe0
[ 362.440670] __tcp_transmit_skb+0x583/0xab0
[ 362.445333] tcp_write_xmit+0x247/0xfb0
[ 362.449609] __tcp_push_pending_frames+0x2d/0xd0
[ 362.454760] tcp_sendmsg_locked+0x857/0xd30
[ 362.459424] tcp_sendmsg+0x27/0x40
[ 362.463216] sock_sendmsg+0x36/0x50
[ 362.467104] sock_write_iter+0x87/0x100
[ 362.471382] __vfs_write+0x112/0x1a0
[ 362.475369] vfs_write+0xad/0x1a0
[ 362.479062] ksys_write+0x52/0xc0
[ 362.482759] do_syscall_64+0x5b/0x180
[ 362.486841] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 362.492473] RIP: 0033:0x7f1d22293238
[ 362.496458] Code: 89 02 48 c7 c0 ff ff ff ff eb b3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8d 05 c5 54 2d 00 8b 00 85 c0 75 17 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 58 c3 0f 1f 80 00 00 00 00 41 54 49 89 d4 55
[ 362.517409] RSP: 002b:00007ffebaef8008 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 362.525855] RAX: ffffffffffffffda RBX: 0000000000002800 RCX: 00007f1d22293238
[ 362.533816] RDX: 0000000000002800 RSI: 00007f1d22d36000 RDI: 0000000000000005
[ 362.541775] RBP: 00007f1d22d36000 R08: 00000002db777a30 R09: 0000562b70712b20
[ 362.549734] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000005
[ 362.557693] R13: 0000000000002800 R14: 00007ffebaef8060 R15: 0000562b70712260
The problem, AFAICS, is that the GRO path changes the cumulative
truesize of the skbs entering such code path without updating
sk_wmem_alloc. The posted code tries to keep unchanged such cumulative
truesize.
I *think* we can hit a similar condition with a tun device in IFF_NAPI
mode.
Cheers,
Paolo
^ permalink raw reply
* Re: libbpf build broken on musl libc (Alpine Linux)
From: Arnaldo Carvalho de Melo @ 2018-09-11 12:15 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Daniel Borkmann, Thomas Richter, Hendrik Brueckner,
Linux Kernel Mailing List,
Linux Networking Development Mailing List
In-Reply-To: <20180911122218.0d2eb3f9@cakuba>
Em Tue, Sep 11, 2018 at 12:22:18PM +0200, Jakub Kicinski escreveu:
> On Mon, 10 Sep 2018 14:29:03 -0300, Arnaldo Carvalho de Melo wrote:
> > After lunch I'll work on a patch to fix this,
> Hi Arnaldo!
> Any luck?
Well, we need to apply the patch below and make tools/lib/str_error_r.c
live in a library that libbpf and perf is linked to.
We have tools/lib/api/ that I think we should make libbpf link against
it, so perf would as well, and even when perf is not linked with libbpf,
those symbols would be available.
The patch below, as-is, is enough for tools/perf/, as it already
statically links with libapi, but we need to do it properly as a library
as stated above.
I'm a bit busy right now, so may take me a bit more time, help in having
libapi used by libbpf would be welcome.
While looking at this I noticed that we should get
tools/perf/check_headers.sh and move it outside perf so that libbpf can
use that mechanism instead of the old ad-hoc series of diffs in its
Makefile, that Jiri forgot to convert to check_headers.
For reference, this is how it looks like now, the builds that take more
time (second column, in seconds, i5 + NVMe) is because it builds with
both gcc and clang, with and without libelf. ClearLinux is failing for
an unrelated problem, its a recent container, also the
ubuntu:18.04-x-i686 cross build is another unrelated problem, something
related to atomics.
Only the alpine (musl libc) are regressions due to the strerror_r
oddity.
- Arnaldo
# dm
1 5.15 alpine:3.4 : FAIL gcc (Alpine 5.3.0) 5.3.0
2 5.08 alpine:3.5 : FAIL gcc (Alpine 6.2.1) 6.2.1 20160822
3 6.40 alpine:3.6 : FAIL gcc (Alpine 6.3.0) 6.3.0
4 5.38 alpine:3.7 : FAIL gcc (Alpine 6.4.0) 6.4.0
5 5.44 alpine:3.8 : FAIL gcc (Alpine 6.4.0) 6.4.0
6 5.69 alpine:edge : FAIL gcc (Alpine 6.4.0) 6.4.0
7 37.14 amazonlinux:1 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
8 43.81 amazonlinux:2 : Ok gcc (GCC) 7.3.1 20180303 (Red Hat 7.3.1-5)
9 28.93 android-ndk:r12b-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
10 29.89 android-ndk:r15c-arm : Ok arm-linux-androideabi-gcc (GCC) 4.9.x 20150123 (prerelease)
11 22.19 centos:5 : Ok gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-55)
12 35.31 centos:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23)
13 40.22 centos:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28)
14 23.39 clearlinux:latest : FAIL gcc (Clear Linux OS for Intel Architecture) 8.2.0
15 36.10 debian:7 : Ok gcc (Debian 4.7.2-5) 4.7.2
16 41.81 debian:8 : Ok gcc (Debian 4.9.2-10+deb8u1) 4.9.2
17 97.56 debian:9 : Ok gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516
18 108.83 debian:experimental : Ok gcc (Debian 8.2.0-4) 8.2.0
19 40.88 debian:experimental-x-arm64 : Ok aarch64-linux-gnu-gcc (Debian 8.1.0-12) 8.1.0
20 41.05 debian:experimental-x-mips : Ok mips-linux-gnu-gcc (Debian 8.1.0-12) 8.1.0
21 36.59 debian:experimental-x-mips64 : Ok mips64-linux-gnuabi64-gcc (Debian 8.1.0-12) 8.1.0
22 41.20 debian:experimental-x-mipsel : Ok mipsel-linux-gnu-gcc (Debian 8.1.0-12) 8.1.0
23 39.76 fedora:20 : Ok gcc (GCC) 4.8.3 20140911 (Red Hat 4.8.3-7)
24 41.85 fedora:21 : Ok gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)
25 42.56 fedora:22 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
26 41.62 fedora:23 : Ok gcc (GCC) 5.3.1 20160406 (Red Hat 5.3.1-6)
27 43.09 fedora:24 : Ok gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
28 36.13 fedora:24-x-ARC-uClibc : Ok arc-linux-gcc (ARCompact ISA Linux uClibc toolchain 2017.09-rc2) 7.1.1 20170710
29 119.56 fedora:25 : Ok gcc (GCC) 6.4.1 20170727 (Red Hat 6.4.1-1)
30 136.89 fedora:26 : Ok gcc (GCC) 7.3.1 20180130 (Red Hat 7.3.1-2)
31 136.21 fedora:27 : Ok gcc (GCC) 7.3.1 20180712 (Red Hat 7.3.1-6)
32 155.74 fedora:28 : Ok gcc (GCC) 8.1.1 20180712 (Red Hat 8.1.1-5)
33 163.56 fedora:rawhide : Ok gcc (GCC) 8.2.1 20180801 (Red Hat 8.2.1-2)
34 40.91 gentoo-stage3-amd64:latest : Ok gcc (Gentoo 7.3.0-r3 p1.4) 7.3.0
35 43.49 mageia:5 : Ok gcc (GCC) 4.9.2
36 43.53 mageia:6 : Ok gcc (Mageia 5.5.0-1.mga6) 5.5.0
37 41.78 opensuse:13.2 : Ok gcc (SUSE Linux) 4.8.3 20140627 [gcc-4_8-branch revision 212064]
38 40.90 opensuse:42.1 : Ok gcc (SUSE Linux) 4.8.5
39 41.82 opensuse:42.2 : Ok gcc (SUSE Linux) 4.8.5
40 42.54 opensuse:42.3 : Ok gcc (SUSE Linux) 4.8.5
41 137.82 opensuse:tumbleweed : Ok gcc (SUSE Linux) 7.3.1 20180323 [gcc-7-branch revision 258812]
42 33.51 oraclelinux:6 : Ok gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-23.0.1)
43 39.50 oraclelinux:7 : Ok gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-28.0.1)
44 32.46 ubuntu:12.04.5 : Ok gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
45 37.82 ubuntu:14.04.4 : Ok gcc (Ubuntu 4.8.4-2ubuntu1~14.04.3) 4.8.4
46 34.76 ubuntu:14.04.4-x-linaro-arm64 : Ok aarch64-linux-gnu-gcc (Linaro GCC 5.5-2017.10) 5.5.0
47 93.53 ubuntu:16.04 : Ok gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0 20160609
48 34.76 ubuntu:16.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
49 33.89 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
50 34.44 ubuntu:16.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
51 33.90 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
52 34.16 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
53 32.89 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609
54 100.14 ubuntu:16.10 : Ok gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
55 107.62 ubuntu:17.10 : Ok gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
56 111.93 ubuntu:18.04 : Ok gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
57 36.09 ubuntu:18.04-x-arm : Ok arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.3.0-16ubuntu3) 7.3.0
58 36.57 ubuntu:18.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.3.0-16ubuntu3) 7.3.0
59 4.90 ubuntu:18.04-x-i686 : FAIL i686-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
60 27.67 ubuntu:18.04-x-m68k : Ok m68k-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
61 36.20 ubuntu:18.04-x-powerpc : Ok powerpc-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
62 39.75 ubuntu:18.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
63 40.01 ubuntu:18.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
64 68.19 ubuntu:18.04-x-riscv64 : Ok riscv64-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
65 34.25 ubuntu:18.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
66 36.44 ubuntu:18.04-x-sh4 : Ok sh4-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
67 31.68 ubuntu:18.04-x-sparc64 : Ok sparc64-linux-gnu-gcc (Ubuntu 7.3.0-16ubuntu3) 7.3.0
68 104.31 ubuntu:18.10 : Ok gcc (Ubuntu 8.2.0-4ubuntu1) 8.2.0
#
^ permalink raw reply
* Re: [PATCH v3 00/15] soc: octeontx2: Add RVU admin function driver
From: Sunil Kovvuri @ 2018-09-11 12:37 UTC (permalink / raw)
To: LKML, Arnd Bergmann, olof
Cc: LAKML, linux-soc, Andrew Lunn, David S. Miller, Linux Netdev List,
Sunil Goutham
In-Reply-To: <1536078525-31534-1-git-send-email-sunil.kovvuri@gmail.com>
On Tue, Sep 4, 2018 at 9:58 PM <sunil.kovvuri@gmail.com> wrote:
>
> From: Sunil Goutham <sgoutham@marvell.com>
>
> Resource virtualization unit (RVU) on Marvell's OcteonTX2 SOC supports
> multiple PCIe SRIOV physical functions (PFs) and virtual functions (VFs).
> PF0 is called administrative / admin function (AF) and has privilege access
> to registers to provision different RVU functional blocks to each of
> PF/VF.
>
> This admin function (AF) driver acts as a configuration / administrative
> software which provisions functional blocks to a PF/VF on demand for them
> to work as one of the following
> - A basic network controller (i.e NIC).
> - NIC with packet filtering, shaping and scheduling capabilities.
> - A crypto device.
> - A combination of above etc.
>
> PF/VFs communicate with admin function via a shared memory region.
> This patch series adds logic for the following
> - RVU AF driver with functional blocks provisioning support
> - Mailbox infrastructure for communication between AF and PFs.
> - CGX driver which provides information about physcial network
> interfaces which AF processes and forwards required info to
> PF/VF drivers.
>
> This is the first set of patches out of 70 odd patches.
>
> Note: This driver neither receives any data nor processes it i.e no I/O,
> just does the hardware configuration.
>
> Changes from v2:
> No changes, submitted again with netdev mailing list in loop.
> - Suggested by Arnd Bergmann and Andrew Lunn
>
> Changes from v1:
> 1 Merged RVU admin function and CGX drivers into a single module
> - Suggested by Arnd Bergmann
> 2 Pulled mbox communication APIs into a separate module to remove
> admin function driver dependency in a VM where AF is not attached.
> - Suggested by Arnd Bergmann
>
Hi Arnd,
Didn't receive any feedback for the v3 patch series over a week's time.
Can you please pick up these patches to merge into arm-soc ?
Thanks,
Sunil.
^ permalink raw reply
* Re: [PATCH net-next v3 17/17] net: WireGuard secure network tunnel
From: kbuild test robot @ 2018-09-11 12:59 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: kbuild-all, linux-kernel, netdev, davem, gregkh,
Jason A. Donenfeld
In-Reply-To: <20180911010838.8818-19-Jason@zx2c4.com>
[-- Attachment #1: Type: text/plain, Size: 45354 bytes --]
Hi Jason,
I love your patch! Yet something to improve:
[auto build test ERROR on net-next/master]
url: https://github.com/0day-ci/linux/commits/Jason-A-Donenfeld/WireGuard-Secure-Network-Tunnel/20180911-185037
config: um-i386_defconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=um SUBARCH=i386
All error/warnings (new ones prefixed by >>):
In file included from lib/zinc/chacha20/chacha20-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from lib/zinc/chacha20/chacha20-x86_64-glue.h:8:0,
from <command-line>:0:
lib/zinc/chacha20/chacha20-x86_64-glue.h: In function 'chacha20_fpu_init':
>> arch/x86/include/asm/cpufeature.h:65:28: error: 'REQUIRED_MASK0' undeclared (first use in this function); did you mean 'DISABLED_MASK0'?
( CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 0, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/chacha20/chacha20-x86_64-glue.h:36:23: note: in expansion of macro 'boot_cpu_has'
chacha20_use_ssse3 = boot_cpu_has(X86_FEATURE_SSSE3);
^~~~~~~~~~~~
arch/x86/include/asm/cpufeature.h:65:28: note: each undeclared identifier is reported only once for each function it appears in
( CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 0, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/chacha20/chacha20-x86_64-glue.h:36:23: note: in expansion of macro 'boot_cpu_has'
chacha20_use_ssse3 = boot_cpu_has(X86_FEATURE_SSSE3);
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:66:28: error: 'REQUIRED_MASK1' undeclared (first use in this function); did you mean 'REQUIRED_MASK0'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 1, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/chacha20/chacha20-x86_64-glue.h:36:23: note: in expansion of macro 'boot_cpu_has'
chacha20_use_ssse3 = boot_cpu_has(X86_FEATURE_SSSE3);
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:67:28: error: 'REQUIRED_MASK2' undeclared (first use in this function); did you mean 'REQUIRED_MASK1'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 2, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/chacha20/chacha20-x86_64-glue.h:36:23: note: in expansion of macro 'boot_cpu_has'
chacha20_use_ssse3 = boot_cpu_has(X86_FEATURE_SSSE3);
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:68:28: error: 'REQUIRED_MASK3' undeclared (first use in this function); did you mean 'REQUIRED_MASK2'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 3, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
--
In file included from lib/zinc/poly1305/poly1305-x86_64-glue.h:7:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from lib/zinc/poly1305/poly1305-x86_64-glue.h:7:0,
from <command-line>:0:
lib/zinc/poly1305/poly1305-x86_64-glue.h: In function 'poly1305_fpu_init':
>> arch/x86/include/asm/cpufeature.h:65:28: error: 'REQUIRED_MASK0' undeclared (first use in this function); did you mean 'DISABLED_MASK0'?
( CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 0, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/poly1305/poly1305-x86_64-glue.h:39:3: note: in expansion of macro 'boot_cpu_has'
boot_cpu_has(X86_FEATURE_AVX) &&
^~~~~~~~~~~~
arch/x86/include/asm/cpufeature.h:65:28: note: each undeclared identifier is reported only once for each function it appears in
( CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 0, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/poly1305/poly1305-x86_64-glue.h:39:3: note: in expansion of macro 'boot_cpu_has'
boot_cpu_has(X86_FEATURE_AVX) &&
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:66:28: error: 'REQUIRED_MASK1' undeclared (first use in this function); did you mean 'REQUIRED_MASK0'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 1, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/poly1305/poly1305-x86_64-glue.h:39:3: note: in expansion of macro 'boot_cpu_has'
boot_cpu_has(X86_FEATURE_AVX) &&
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:67:28: error: 'REQUIRED_MASK2' undeclared (first use in this function); did you mean 'REQUIRED_MASK1'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 2, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/poly1305/poly1305-x86_64-glue.h:39:3: note: in expansion of macro 'boot_cpu_has'
boot_cpu_has(X86_FEATURE_AVX) &&
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:68:28: error: 'REQUIRED_MASK3' undeclared (first use in this function); did you mean 'REQUIRED_MASK2'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 3, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
--
lib/zinc/poly1305/poly1305-x86_64.S: Assembler messages:
>> lib/zinc/poly1305/poly1305-x86_64.S:25: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:26: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:27: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:28: Error: bad register name `%rax'
>> lib/zinc/poly1305/poly1305-x86_64.S:30: Error: bad register name `%rsi'
lib/zinc/poly1305/poly1305-x86_64.S:33: Error: bad register name `%rax'
>> lib/zinc/poly1305/poly1305-x86_64.S:34: Error: bad register name `%rcx'
>> lib/zinc/poly1305/poly1305-x86_64.S:35: Error: bad register name `%rsi)'
lib/zinc/poly1305/poly1305-x86_64.S:36: Error: bad register name `%rsi)'
lib/zinc/poly1305/poly1305-x86_64.S:37: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:38: Error: bad register name `%rcx'
>> lib/zinc/poly1305/poly1305-x86_64.S:47: Error: bad register name `%rdx'
>> lib/zinc/poly1305/poly1305-x86_64.S:50: Error: bad register name `%rbx'
>> lib/zinc/poly1305/poly1305-x86_64.S:51: Error: bad register name `%r12'
>> lib/zinc/poly1305/poly1305-x86_64.S:52: Error: bad register name `%r13'
>> lib/zinc/poly1305/poly1305-x86_64.S:53: Error: bad register name `%r14'
>> lib/zinc/poly1305/poly1305-x86_64.S:54: Error: bad register name `%r15'
>> lib/zinc/poly1305/poly1305-x86_64.S:55: Error: bad register name `%rdi'
lib/zinc/poly1305/poly1305-x86_64.S:59: Error: bad register name `%rdx'
>> lib/zinc/poly1305/poly1305-x86_64.S:61: Error: bad register name `%rdi)'
lib/zinc/poly1305/poly1305-x86_64.S:62: Error: bad register name `%rdi)'
lib/zinc/poly1305/poly1305-x86_64.S:64: Error: bad register name `%rdi)'
lib/zinc/poly1305/poly1305-x86_64.S:65: Error: bad register name `%rdi)'
lib/zinc/poly1305/poly1305-x86_64.S:66: Error: bad register name `%rdi)'
lib/zinc/poly1305/poly1305-x86_64.S:68: Error: bad register name `%r13'
lib/zinc/poly1305/poly1305-x86_64.S:69: Error: bad register name `%r13'
lib/zinc/poly1305/poly1305-x86_64.S:70: Error: bad register name `%r12'
lib/zinc/poly1305/poly1305-x86_64.S:71: Error: bad register name `%r12'
lib/zinc/poly1305/poly1305-x86_64.S:77: Error: bad register name `%rsi)'
lib/zinc/poly1305/poly1305-x86_64.S:78: Error: bad register name `%rsi)'
lib/zinc/poly1305/poly1305-x86_64.S:79: Error: bad register name `%rsi)'
lib/zinc/poly1305/poly1305-x86_64.S:80: Error: bad register name `%rcx'
lib/zinc/poly1305/poly1305-x86_64.S:81: Error: bad register name `%r14'
lib/zinc/poly1305/poly1305-x86_64.S:82: Error: bad register name `%rax'
>> lib/zinc/poly1305/poly1305-x86_64.S:83: Error: bad register name `%r11'
lib/zinc/poly1305/poly1305-x86_64.S:84: Error: bad register name `%rdx'
lib/zinc/poly1305/poly1305-x86_64.S:86: Error: bad register name `%r14'
lib/zinc/poly1305/poly1305-x86_64.S:87: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:88: Error: bad register name `%r11'
lib/zinc/poly1305/poly1305-x86_64.S:89: Error: bad register name `%rdx'
lib/zinc/poly1305/poly1305-x86_64.S:91: Error: bad register name `%rbx'
lib/zinc/poly1305/poly1305-x86_64.S:92: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:93: Error: bad register name `%r13'
lib/zinc/poly1305/poly1305-x86_64.S:94: Error: bad register name `%rdx'
lib/zinc/poly1305/poly1305-x86_64.S:96: Error: bad register name `%rbx'
>> lib/zinc/poly1305/poly1305-x86_64.S:97: Error: bad register name `%r10'
lib/zinc/poly1305/poly1305-x86_64.S:98: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:99: Error: bad register name `%rdx'
lib/zinc/poly1305/poly1305-x86_64.S:101: Error: bad register name `%r13'
lib/zinc/poly1305/poly1305-x86_64.S:102: Error: bad register name `%rbx'
>> lib/zinc/poly1305/poly1305-x86_64.S:103: Error: bad register name `%r8'
lib/zinc/poly1305/poly1305-x86_64.S:104: Error: bad register name `%rdi'
lib/zinc/poly1305/poly1305-x86_64.S:106: Error: bad register name `%r11'
>> lib/zinc/poly1305/poly1305-x86_64.S:107: Error: bad register name `%r9'
lib/zinc/poly1305/poly1305-x86_64.S:108: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:109: Error: bad register name `%r10'
lib/zinc/poly1305/poly1305-x86_64.S:111: Error: bad register name `%rdi'
lib/zinc/poly1305/poly1305-x86_64.S:112: Error: bad register name `%rdi'
lib/zinc/poly1305/poly1305-x86_64.S:113: Error: bad register name `%rdi'
lib/zinc/poly1305/poly1305-x86_64.S:114: Error: bad register name `%r10'
lib/zinc/poly1305/poly1305-x86_64.S:115: Error: bad register name `%rdi'
lib/zinc/poly1305/poly1305-x86_64.S:116: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:117: Error: bad register name `%rbx'
lib/zinc/poly1305/poly1305-x86_64.S:118: Error: bad register name `%r10'
lib/zinc/poly1305/poly1305-x86_64.S:120: Error: bad register name `%r12'
lib/zinc/poly1305/poly1305-x86_64.S:121: Error: bad register name `%r15'
>> lib/zinc/poly1305/poly1305-x86_64.S:124: Error: bad register name `%rsp)'
lib/zinc/poly1305/poly1305-x86_64.S:126: Error: bad register name `%r14'
lib/zinc/poly1305/poly1305-x86_64.S:127: Error: bad register name `%rbx'
lib/zinc/poly1305/poly1305-x86_64.S:128: Error: bad register name `%r10'
lib/zinc/poly1305/poly1305-x86_64.S:130: Error: bad register name `%rsp)'
lib/zinc/poly1305/poly1305-x86_64.S:131: Error: bad register name `%rsp)'
lib/zinc/poly1305/poly1305-x86_64.S:132: Error: bad register name `%rsp)'
lib/zinc/poly1305/poly1305-x86_64.S:133: Error: bad register name `%rsp)'
lib/zinc/poly1305/poly1305-x86_64.S:134: Error: bad register name `%rsp)'
lib/zinc/poly1305/poly1305-x86_64.S:135: Error: bad register name `%rsp)'
lib/zinc/poly1305/poly1305-x86_64.S:144: Error: bad register name `%rdi)'
lib/zinc/poly1305/poly1305-x86_64.S:145: Error: bad register name `%rdi)'
lib/zinc/poly1305/poly1305-x86_64.S:146: Error: bad register name `%rdi)'
lib/zinc/poly1305/poly1305-x86_64.S:148: Error: bad register name `%r8'
lib/zinc/poly1305/poly1305-x86_64.S:149: Error: bad register name `%r8'
lib/zinc/poly1305/poly1305-x86_64.S:150: Error: bad register name `%r9'
lib/zinc/poly1305/poly1305-x86_64.S:151: Error: bad register name `%r9'
lib/zinc/poly1305/poly1305-x86_64.S:152: Error: bad register name `%r10'
lib/zinc/poly1305/poly1305-x86_64.S:153: Error: bad register name `%r10'
lib/zinc/poly1305/poly1305-x86_64.S:154: Error: bad register name `%r8'
lib/zinc/poly1305/poly1305-x86_64.S:155: Error: bad register name `%r9'
>> lib/zinc/poly1305/poly1305-x86_64.S:157: Error: bad register name `%rdx)'
lib/zinc/poly1305/poly1305-x86_64.S:158: Error: bad register name `%rdx)'
lib/zinc/poly1305/poly1305-x86_64.S:159: Error: bad register name `%rax'
lib/zinc/poly1305/poly1305-x86_64.S:160: Error: bad register name `%rcx'
--
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:8:0,
from <command-line>:0:
>> arch/x86/include/asm/cpufeature.h:134:34: warning: 'struct cpuinfo_x86' declared inside parameter list will not be visible outside of this definition or declaration
extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
^~~~~~~~~~~
In file included from include/linux/compiler_types.h:64:0,
from <command-line>:0:
arch/x86/include/asm/cpufeature.h: In function '_static_cpu_has':
>> arch/x86/include/asm/cpufeature.h:198:52: error: 'struct cpuinfo_um' has no member named 'x86_capability'
[cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
^
include/linux/compiler-gcc.h:182:47: note: in definition of macro 'asm_volatile_goto'
#define asm_volatile_goto(x...) do { asm goto(x); asm (""); } while (0)
^
In file included from lib/zinc/curve25519/curve25519-x86_64-glue.h:8:0,
from <command-line>:0:
lib/zinc/curve25519/curve25519-x86_64-glue.h: In function 'curve25519_fpu_init':
>> arch/x86/include/asm/cpufeature.h:65:28: error: 'REQUIRED_MASK0' undeclared (first use in this function); did you mean 'DISABLED_MASK0'?
( CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 0, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:18:24: note: in expansion of macro 'boot_cpu_has'
curve25519_use_bmi2 = boot_cpu_has(X86_FEATURE_BMI2);
^~~~~~~~~~~~
arch/x86/include/asm/cpufeature.h:65:28: note: each undeclared identifier is reported only once for each function it appears in
( CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 0, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:18:24: note: in expansion of macro 'boot_cpu_has'
curve25519_use_bmi2 = boot_cpu_has(X86_FEATURE_BMI2);
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:66:28: error: 'REQUIRED_MASK1' undeclared (first use in this function); did you mean 'REQUIRED_MASK0'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 1, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:18:24: note: in expansion of macro 'boot_cpu_has'
curve25519_use_bmi2 = boot_cpu_has(X86_FEATURE_BMI2);
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:67:28: error: 'REQUIRED_MASK2' undeclared (first use in this function); did you mean 'REQUIRED_MASK1'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 2, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
>> lib/zinc/curve25519/curve25519-x86_64-glue.h:18:24: note: in expansion of macro 'boot_cpu_has'
curve25519_use_bmi2 = boot_cpu_has(X86_FEATURE_BMI2);
^~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:68:28: error: 'REQUIRED_MASK3' undeclared (first use in this function); did you mean 'REQUIRED_MASK2'?
CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 3, feature_bit) || \
^
arch/x86/include/asm/cpufeature.h:62:44: note: in definition of macro 'CHECK_BIT_IN_MASK_WORD'
(((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
^~~~~~~~
>> arch/x86/include/asm/cpufeature.h:111:32: note: in expansion of macro 'REQUIRED_MASK_BIT_SET'
(__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
^~~~~~~~~~~~~~~~~~~~~
>> arch/x86/include/asm/cpufeature.h:129:27: note: in expansion of macro 'cpu_has'
#define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
^~~~~~~
..
vim +198 arch/x86/include/asm/cpufeature.h
80a208bd arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-06-24 50
0f8d2b92 include/asm-x86/cpufeature.h Ingo Molnar 2008-02-26 51 #define test_cpu_cap(c, bit) \
0f8d2b92 include/asm-x86/cpufeature.h Ingo Molnar 2008-02-26 @52 test_bit(bit, (unsigned long *)((c)->x86_capability))
0f8d2b92 include/asm-x86/cpufeature.h Ingo Molnar 2008-02-26 53
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 54 /*
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 55 * There are 32 bits/features in each mask word. The high bits
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 56 * (selected with (bit>>5) give us the word number and the low 5
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 57 * bits give us the bit/feature number inside the word.
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 58 * (1UL<<((bit)&31) gives us a mask for the feature_bit so we can
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 59 * see if it is set in the mask word.
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 60 */
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 61 #define CHECK_BIT_IN_MASK_WORD(maskname, word, bit) \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 62 (((bit)>>5)==(word) && (1UL<<((bit)&31) & maskname##word ))
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 63
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 64 #define REQUIRED_MASK_BIT_SET(feature_bit) \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @65 ( CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 0, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @66 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 1, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @67 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 2, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @68 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 3, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @69 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 4, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @70 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 5, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @71 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 6, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @72 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 7, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @73 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 8, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @74 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 9, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @75 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 10, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @76 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 11, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @77 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 12, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @78 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 13, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @79 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 14, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @80 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 15, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @81 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 16, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @82 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 17, feature_bit) || \
95ca0ee8 arch/x86/include/asm/cpufeature.h David Woodhouse 2018-01-25 @83 CHECK_BIT_IN_MASK_WORD(REQUIRED_MASK, 18, feature_bit) || \
1e61f78b arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 @84 REQUIRED_MASK_CHECK || \
95ca0ee8 arch/x86/include/asm/cpufeature.h David Woodhouse 2018-01-25 85 BUILD_BUG_ON_ZERO(NCAPINTS != 19))
349c004e arch/x86/include/asm/cpufeature.h Christoph Lameter 2011-03-12 86
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 87 #define DISABLED_MASK_BIT_SET(feature_bit) \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 88 ( CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 0, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 89 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 1, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 90 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 2, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 91 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 3, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 92 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 4, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 93 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 5, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 94 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 6, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 95 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 7, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 96 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 8, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 97 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 9, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 98 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 10, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 99 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 11, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 100 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 12, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 101 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 13, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 102 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 14, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 103 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 15, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 104 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 16, feature_bit) || \
8eda072e arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 105 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 17, feature_bit) || \
95ca0ee8 arch/x86/include/asm/cpufeature.h David Woodhouse 2018-01-25 106 CHECK_BIT_IN_MASK_WORD(DISABLED_MASK, 18, feature_bit) || \
1e61f78b arch/x86/include/asm/cpufeature.h Dave Hansen 2016-06-29 107 DISABLED_MASK_CHECK || \
95ca0ee8 arch/x86/include/asm/cpufeature.h David Woodhouse 2018-01-25 108 BUILD_BUG_ON_ZERO(NCAPINTS != 19))
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 109
349c004e arch/x86/include/asm/cpufeature.h Christoph Lameter 2011-03-12 110 #define cpu_has(c, bit) \
349c004e arch/x86/include/asm/cpufeature.h Christoph Lameter 2011-03-12 @111 (__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
0f8d2b92 include/asm-x86/cpufeature.h Ingo Molnar 2008-02-26 @112 test_cpu_cap(c, bit))
0f8d2b92 include/asm-x86/cpufeature.h Ingo Molnar 2008-02-26 113
349c004e arch/x86/include/asm/cpufeature.h Christoph Lameter 2011-03-12 114 #define this_cpu_has(bit) \
349c004e arch/x86/include/asm/cpufeature.h Christoph Lameter 2011-03-12 115 (__builtin_constant_p(bit) && REQUIRED_MASK_BIT_SET(bit) ? 1 : \
349c004e arch/x86/include/asm/cpufeature.h Christoph Lameter 2011-03-12 116 x86_this_cpu_test_bit(bit, (unsigned long *)&cpu_info.x86_capability))
349c004e arch/x86/include/asm/cpufeature.h Christoph Lameter 2011-03-12 117
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 118 /*
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 119 * This macro is for detection of features which need kernel
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 120 * infrastructure to be used. It may *not* directly test the CPU
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 121 * itself. Use the cpu_has() family if you want true runtime
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 122 * testing of CPU features, like in hypervisor code where you are
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 123 * supporting a possible guest feature where host support for it
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 124 * is not relevant.
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 125 */
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 126 #define cpu_feature_enabled(bit) \
f2cc8e07 arch/x86/include/asm/cpufeature.h Borislav Petkov 2016-02-16 127 (__builtin_constant_p(bit) && DISABLED_MASK_BIT_SET(bit) ? 0 : static_cpu_has(bit))
381aa07a arch/x86/include/asm/cpufeature.h Dave Hansen 2014-09-11 128
7b11fb51 include/asm-x86/cpufeature.h H. Peter Anvin 2008-01-30 @129 #define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit)
7b11fb51 include/asm-x86/cpufeature.h H. Peter Anvin 2008-01-30 130
53756d37 include/asm-x86/cpufeature.h Jeremy Fitzhardinge 2008-01-30 131 #define set_cpu_cap(c, bit) set_bit(bit, (unsigned long *)((c)->x86_capability))
0b00de85 arch/x86/include/asm/cpufeature.h Andi Kleen 2017-10-13 132
0b00de85 arch/x86/include/asm/cpufeature.h Andi Kleen 2017-10-13 133 extern void setup_clear_cpu_cap(unsigned int bit);
0b00de85 arch/x86/include/asm/cpufeature.h Andi Kleen 2017-10-13 @134 extern void clear_cpu_cap(struct cpuinfo_x86 *c, unsigned int bit);
0b00de85 arch/x86/include/asm/cpufeature.h Andi Kleen 2017-10-13 135
404ee5b1 include/asm-x86/cpufeature.h Andi Kleen 2008-01-30 136 #define setup_force_cpu_cap(bit) do { \
404ee5b1 include/asm-x86/cpufeature.h Andi Kleen 2008-01-30 137 set_cpu_cap(&boot_cpu_data, bit); \
3e0c3737 arch/x86/include/asm/cpufeature.h Yinghai Lu 2009-05-09 138 set_bit(bit, (unsigned long *)cpu_caps_set); \
404ee5b1 include/asm-x86/cpufeature.h Andi Kleen 2008-01-30 139 } while (0)
53756d37 include/asm-x86/cpufeature.h Jeremy Fitzhardinge 2008-01-30 140
6cbd2171 arch/x86/include/asm/cpufeature.h Thomas Gleixner 2017-12-04 141 #define setup_force_cpu_bug(bit) setup_force_cpu_cap(bit)
6cbd2171 arch/x86/include/asm/cpufeature.h Thomas Gleixner 2017-12-04 142
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 143 #if defined(__clang__) && !defined(CC_HAVE_ASM_GOTO)
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 144
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 145 /*
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 146 * Workaround for the sake of BPF compilation which utilizes kernel
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 147 * headers, but clang does not support ASM GOTO and fails the build.
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 148 */
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 149 #ifndef __BPF_TRACING__
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 150 #warning "Compiler lacks ASM_GOTO support. Add -D __BPF_TRACING__ to your compiler arguments"
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 151 #endif
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 152
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 153 #define static_cpu_has(bit) boot_cpu_has(bit)
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 154
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 155 #else
b1ae32db arch/x86/include/asm/cpufeature.h Alexei Starovoitov 2018-05-13 156
a3c8acd0 arch/x86/include/asm/cpufeature.h H. Peter Anvin 2010-05-11 157 /*
a3c8acd0 arch/x86/include/asm/cpufeature.h H. Peter Anvin 2010-05-11 158 * Static testing of CPU features. Used the same as boot_cpu_has().
a362bf9f arch/x86/include/asm/cpufeature.h Borislav Petkov 2016-01-27 159 * These will statically patch the target code for additional
a362bf9f arch/x86/include/asm/cpufeature.h Borislav Petkov 2016-01-27 160 * performance.
a3c8acd0 arch/x86/include/asm/cpufeature.h H. Peter Anvin 2010-05-11 161 */
bc696ca0 arch/x86/include/asm/cpufeature.h Borislav Petkov 2016-01-26 162 static __always_inline __pure bool _static_cpu_has(u16 bit)
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 163 {
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 164 asm_volatile_goto("1: jmp 6f\n"
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 165 "2:\n"
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 166 ".skip -(((5f-4f) - (2b-1b)) > 0) * "
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 167 "((5f-4f) - (2b-1b)),0x90\n"
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 168 "3:\n"
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 169 ".section .altinstructions,\"a\"\n"
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 170 " .long 1b - .\n" /* src offset */
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 171 " .long 4f - .\n" /* repl offset */
3197b04b arch/x86/include/asm/cpufeature.h Peter Zijlstra 2018-01-16 172 " .word %P[always]\n" /* always replace */
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 173 " .byte 3b - 1b\n" /* src len */
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 174 " .byte 5f - 4f\n" /* repl len */
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 175 " .byte 3b - 2b\n" /* pad len */
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 176 ".previous\n"
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 177 ".section .altinstr_replacement,\"ax\"\n"
48c7a250 arch/x86/include/asm/cpufeature.h Borislav Petkov 2015-01-05 178 "4: jmp %l[t_no]\n"
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 179 "5:\n"
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 180 ".previous\n"
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 181 ".section .altinstructions,\"a\"\n"
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 182 " .long 1b - .\n" /* src offset */
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 183 " .long 0\n" /* no replacement */
3197b04b arch/x86/include/asm/cpufeature.h Peter Zijlstra 2018-01-16 184 " .word %P[feature]\n" /* feature bit */
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 185 " .byte 3b - 1b\n" /* src len */
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 186 " .byte 0\n" /* repl len */
4332195c arch/x86/include/asm/cpufeature.h Borislav Petkov 2014-12-27 187 " .byte 0\n" /* pad len */
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 188 ".previous\n"
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 189 ".section .altinstr_aux,\"ax\"\n"
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 190 "6:\n"
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 191 " testb %[bitnum],%[cap_byte]\n"
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 192 " jnz %l[t_yes]\n"
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 193 " jmp %l[t_no]\n"
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 194 ".previous\n"
3197b04b arch/x86/include/asm/cpufeature.h Peter Zijlstra 2018-01-16 195 : : [feature] "i" (bit),
3197b04b arch/x86/include/asm/cpufeature.h Peter Zijlstra 2018-01-16 196 [always] "i" (X86_FEATURE_ALWAYS),
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 197 [bitnum] "i" (1 << (bit & 7)),
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 @198 [cap_byte] "m" (((const char *)boot_cpu_data.x86_capability)[bit >> 3])
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 199 : : t_yes, t_no);
2476f2fa arch/x86/include/asm/cpufeature.h Brian Gerst 2016-01-27 200 t_yes:
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 201 return true;
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 202 t_no:
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 203 return false;
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 204 }
4a90a99c arch/x86/include/asm/cpufeature.h Borislav Petkov 2013-06-09 205
:::::: The code at line 198 was first introduced by commit
:::::: 2476f2fa20568bd5d9e09cd35bcd73e99a6f4cc6 x86/alternatives: Discard dynamic check after init
:::::: TO: Brian Gerst <brgerst@gmail.com>
:::::: CC: Ingo Molnar <mingo@kernel.org>
---
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: 7940 bytes --]
^ 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