Re: [PATCH] net: ethernet: aquantia: fix alloc_cast.cocci warnings
On Thu, 2017-01-19 at 17:09 +0800, kbuild test robot wrote:
> drivers/net/ethernet/aquantia/atlantic/aq_ring.c:24:20-41: WARNING: casting
> value returned by memory allocation function to (struct aq_ring_buff_s *) is
> useless.
>
> Remove casting the values returned by memory allocation functions
> like kmalloc, kzalloc, kmem_cache_alloc, kmem_cache_zalloc etc.
[]
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_ring.c
> @@ -21,7 +21,7 @@ static struct aq_ring_s *aq_ring_alloc(s
> {
> int err = 0;
>
> - self->buff_ring = (struct aq_ring_buff_s *)
> + self->buff_ring =
> kzalloc(sizeof(struct aq_ring_buff_s) * self->size, GFP_KERNEL);
This should likely be kcalloc
Re: [PATCHv3 net-next 2/4] sctp: implement sender-side procedures for SSN/TSN Reset Request Parameter
On Fri, Jan 20, 2017 at 6:02 AM, Marcelo Ricardo Leitner
wrote:
> On Fri, Jan 20, 2017 at 01:19:12AM +0800, Xin Long wrote:
>> This patch is to implement Sender-Side Procedures for the SSN/TSN
>> Reset Request Parameter descibed in rfc6525 section 5.1.4.
>>
>> It is also to add sockopt SCTP_RESET_ASSOC in rfc6525 section 6.3.3
>> for users.
>>
>> Signed-off-by: Xin Long
>> ---
>> include/net/sctp/sctp.h | 1 +
>> include/uapi/linux/sctp.h | 1 +
>> net/sctp/socket.c | 29 +
>> net/sctp/stream.c | 33 +
>> 4 files changed, 64 insertions(+)
>>
>> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
>> index 3cfd365b..b93820f 100644
>> --- a/include/net/sctp/sctp.h
>> +++ b/include/net/sctp/sctp.h
>> @@ -198,6 +198,7 @@ int sctp_offload_init(void);
>> */
>> int sctp_send_reset_streams(struct sctp_association *asoc,
>> struct sctp_reset_streams *params);
>> +int sctp_send_reset_assoc(struct sctp_association *asoc);
>>
>> /*
>> * Module global variables
>> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
>> index 03c27ce..c0bd8c3 100644
>> --- a/include/uapi/linux/sctp.h
>> +++ b/include/uapi/linux/sctp.h
>> @@ -117,6 +117,7 @@ typedef __s32 sctp_assoc_t;
>> #define SCTP_PR_ASSOC_STATUS 115
>> #define SCTP_ENABLE_STREAM_RESET 118
>> #define SCTP_RESET_STREAMS 119
>> +#define SCTP_RESET_ASSOC 120
>>
>> /* PR-SCTP policies */
>> #define SCTP_PR_SCTP_NONE0x
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index bee4dd3..2c5c9ca 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -3812,6 +3812,32 @@ static int sctp_setsockopt_reset_streams(struct sock
>> *sk,
>> return retval;
>> }
>>
>> +static int sctp_setsockopt_reset_assoc(struct sock *sk,
>> +char __user *optval,
>> +unsigned int optlen)
>> +{
>> + struct sctp_association *asoc;
>> + sctp_assoc_t associd;
>> + int retval = -EINVAL;
>> +
>> + if (optlen != sizeof(associd))
>> + goto out;
>> +
>> + if (copy_from_user(&associd, optval, optlen)) {
>> + retval = -EFAULT;
>> + goto out;
>> + }
>> +
>> + asoc = sctp_id2assoc(sk, associd);
>> + if (!asoc)
>> + goto out;
>> +
>> + retval = sctp_send_reset_assoc(asoc);
>> +
>> +out:
>> + return retval;
>> +}
>> +
>> /* API 6.2 setsockopt(), getsockopt()
>> *
>> * Applications use setsockopt() and getsockopt() to set or retrieve
>> @@ -3984,6 +4010,9 @@ static int sctp_setsockopt(struct sock *sk, int level,
>> int optname,
>> case SCTP_RESET_STREAMS:
>> retval = sctp_setsockopt_reset_streams(sk, optval, optlen);
>> break;
>> + case SCTP_RESET_ASSOC:
>> + retval = sctp_setsockopt_reset_assoc(sk, optval, optlen);
>> + break;
>> default:
>> retval = -ENOPROTOOPT;
>> break;
>> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
>> index 13d5e07..b368191 100644
>> --- a/net/sctp/stream.c
>> +++ b/net/sctp/stream.c
>> @@ -162,3 +162,36 @@ int sctp_send_reset_streams(struct sctp_association
>> *asoc,
>> out:
>> return retval;
>> }
>> +
>> +int sctp_send_reset_assoc(struct sctp_association *asoc)
>> +{
>> + struct sctp_chunk *chunk = NULL;
>> + int retval;
>> + __u16 i;
>> +
>> + if (!asoc->peer.reconf_capable ||
>> + !(asoc->strreset_enable & SCTP_ENABLE_RESET_ASSOC_REQ))
>> + return -ENOPROTOOPT;
>> +
>> + if (asoc->strreset_outstanding)
>> + return -EINPROGRESS;
>> +
>> + chunk = sctp_make_strreset_tsnreq(asoc);
>> + if (!chunk)
>> + return -ENOMEM;
>> +
>
> Please add a comment here explaining that the for below is to block
> further xmit of data until this request is completed.
sure.
>
>> + for (i = 0; i < asoc->stream->outcnt; i++)
>> + asoc->stream->out[i].state = SCTP_STREAM_CLOSED;
>> +
>> + asoc->strreset_outstanding = 1;
>> + asoc->strreset_chunk = chunk;
>> + sctp_chunk_hold(asoc->strreset_chunk);
>> +
>> + retval = sctp_send_reconf(asoc, chunk);
>> + if (retval) {
>> + sctp_chunk_put(asoc->strreset_chunk);
>> + asoc->strreset_chunk = NULL;
>
> If this happens, the asoc will get stuck, as strreset_outstanding is
> marked as 1, all streams are closed and no packet was even queued
> (I'm assuming so as you're dropping the reference on it).
you're right, I'm planning to move:
>> + for (i = 0; i < asoc->stream->outcnt; i++)
>> + asoc->stream->out[i].state = SCTP_STREAM_CLOSED;
>> +
>> + asoc->strreset_outstanding = 1;
right after this check. so that it will do it only when
the reconf chunk is sent out.
>
>
>> + }
>> +
>> + return retval;
>> +}
>> --
>> 2.1.0
>>
>> --
>> To unsubscribe from this list: se
Re: [PATCHv3 net-next 4/4] sctp: implement sender-side procedures for Add Incoming/Outgoing Streams Request Parameter
On Fri, Jan 20, 2017 at 6:15 AM, Marcelo Ricardo Leitner
wrote:
> On Fri, Jan 20, 2017 at 01:19:14AM +0800, Xin Long wrote:
>> This patch is to implement Sender-Side Procedures for the Add
>> Outgoing and Incoming Streams Request Parameter described in
>> rfc6525 section 5.1.5-5.1.6.
>>
>> It is also to add sockopt SCTP_ADD_STREAMS in rfc6525 section
>> 6.3.4 for users.
>>
>> Signed-off-by: Xin Long
>> ---
>> include/net/sctp/sctp.h | 2 +
>> include/uapi/linux/sctp.h | 7
>> net/sctp/socket.c | 29 ++
>> net/sctp/stream.c | 99
>> +++
>> 4 files changed, 137 insertions(+)
>>
>> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
>> index b93820f..68ee1a6 100644
>> --- a/include/net/sctp/sctp.h
>> +++ b/include/net/sctp/sctp.h
>> @@ -199,6 +199,8 @@ int sctp_offload_init(void);
>> int sctp_send_reset_streams(struct sctp_association *asoc,
>> struct sctp_reset_streams *params);
>> int sctp_send_reset_assoc(struct sctp_association *asoc);
>> +int sctp_send_add_streams(struct sctp_association *asoc,
>> + struct sctp_add_streams *params);
>>
>> /*
>> * Module global variables
>> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
>> index c0bd8c3..a91a9cc 100644
>> --- a/include/uapi/linux/sctp.h
>> +++ b/include/uapi/linux/sctp.h
>> @@ -118,6 +118,7 @@ typedef __s32 sctp_assoc_t;
>> #define SCTP_ENABLE_STREAM_RESET 118
>> #define SCTP_RESET_STREAMS 119
>> #define SCTP_RESET_ASSOC 120
>> +#define SCTP_ADD_STREAMS 121
>>
>> /* PR-SCTP policies */
>> #define SCTP_PR_SCTP_NONE0x
>> @@ -1027,4 +1028,10 @@ struct sctp_reset_streams {
>> uint16_t srs_stream_list[]; /* list if srs_num_streams is not 0 */
>> };
>>
>> +struct sctp_add_streams {
>> + sctp_assoc_t sas_assoc_id;
>> + uint16_t sas_instrms;
>> + uint16_t sas_outstrms;
>> +};
>> +
>> #endif /* _UAPI_SCTP_H */
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index 2c5c9ca..ae0a99e 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -3838,6 +3838,32 @@ static int sctp_setsockopt_reset_assoc(struct sock
>> *sk,
>> return retval;
>> }
>>
>> +static int sctp_setsockopt_add_streams(struct sock *sk,
>> +char __user *optval,
>> +unsigned int optlen)
>> +{
>> + struct sctp_association *asoc;
>> + struct sctp_add_streams params;
>> + int retval = -EINVAL;
>> +
>> + if (optlen != sizeof(params))
>> + goto out;
>> +
>> + if (copy_from_user(¶ms, optval, optlen)) {
>> + retval = -EFAULT;
>> + goto out;
>> + }
>> +
>> + asoc = sctp_id2assoc(sk, params.sas_assoc_id);
>> + if (!asoc)
>> + goto out;
>> +
>> + retval = sctp_send_add_streams(asoc, ¶ms);
>> +
>> +out:
>> + return retval;
>> +}
>> +
>> /* API 6.2 setsockopt(), getsockopt()
>> *
>> * Applications use setsockopt() and getsockopt() to set or retrieve
>> @@ -4013,6 +4039,9 @@ static int sctp_setsockopt(struct sock *sk, int level,
>> int optname,
>> case SCTP_RESET_ASSOC:
>> retval = sctp_setsockopt_reset_assoc(sk, optval, optlen);
>> break;
>> + case SCTP_ADD_STREAMS:
>> + retval = sctp_setsockopt_add_streams(sk, optval, optlen);
>> + break;
>> default:
>> retval = -ENOPROTOOPT;
>> break;
>> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
>> index b368191..ba41837 100644
>> --- a/net/sctp/stream.c
>> +++ b/net/sctp/stream.c
>> @@ -195,3 +195,102 @@ int sctp_send_reset_assoc(struct sctp_association
>> *asoc)
>>
>> return retval;
>> }
>> +
>> +int sctp_send_add_streams(struct sctp_association *asoc,
>> + struct sctp_add_streams *params)
>> +{
>> + struct sctp_stream *stream = asoc->stream;
>> + struct sctp_chunk *chunk = NULL;
>> + int retval = -EINVAL;
>> + __u16 out, in;
>> +
>> + if (!asoc->peer.reconf_capable ||
>> + !(asoc->strreset_enable & SCTP_ENABLE_CHANGE_ASSOC_REQ)) {
>> + retval = -ENOPROTOOPT;
>> + goto out;
>> + }
>> +
>> + if (asoc->strreset_outstanding) {
>> + retval = -EINPROGRESS;
>> + goto out;
>> + }
>> +
>> + out = params->sas_outstrms;
>> + in = params->sas_instrms;
>> +
>> + if (!out && !in)
>> + goto out;
>> +
>> + if (out) {
>> + __u16 nums = stream->outcnt + out;
>> +
>> + /* Check for overflow, can't use nums here */
>> + if (stream->outcnt + out > SCTP_MAX_STREAM)
>> + goto out;
>> +
>> + /* Use ksize to check if stream array really needs to realloc
>> */
>> + if (ksize(stream->out) / sizeof(*stream->out) < nums) {
>> + struct sctp_stream_out *str
Re: [PATCHv3 net-next 4/4] sctp: implement sender-side procedures for Add Incoming/Outgoing Streams Request Parameter
On Fri, Jan 20, 2017 at 5:47 AM, Marcelo Ricardo Leitner
wrote:
> On Fri, Jan 20, 2017 at 01:19:14AM +0800, Xin Long wrote:
>> This patch is to implement Sender-Side Procedures for the Add
>> Outgoing and Incoming Streams Request Parameter described in
>> rfc6525 section 5.1.5-5.1.6.
>>
>> It is also to add sockopt SCTP_ADD_STREAMS in rfc6525 section
>> 6.3.4 for users.
>>
>> Signed-off-by: Xin Long
>> ---
>> include/net/sctp/sctp.h | 2 +
>> include/uapi/linux/sctp.h | 7
>> net/sctp/socket.c | 29 ++
>> net/sctp/stream.c | 99
>> +++
>> 4 files changed, 137 insertions(+)
>>
>> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
>> index b93820f..68ee1a6 100644
>> --- a/include/net/sctp/sctp.h
>> +++ b/include/net/sctp/sctp.h
>> @@ -199,6 +199,8 @@ int sctp_offload_init(void);
>> int sctp_send_reset_streams(struct sctp_association *asoc,
>> struct sctp_reset_streams *params);
>> int sctp_send_reset_assoc(struct sctp_association *asoc);
>> +int sctp_send_add_streams(struct sctp_association *asoc,
>> + struct sctp_add_streams *params);
>>
>> /*
>> * Module global variables
>> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
>> index c0bd8c3..a91a9cc 100644
>> --- a/include/uapi/linux/sctp.h
>> +++ b/include/uapi/linux/sctp.h
>> @@ -118,6 +118,7 @@ typedef __s32 sctp_assoc_t;
>> #define SCTP_ENABLE_STREAM_RESET 118
>> #define SCTP_RESET_STREAMS 119
>> #define SCTP_RESET_ASSOC 120
>> +#define SCTP_ADD_STREAMS 121
>>
>> /* PR-SCTP policies */
>> #define SCTP_PR_SCTP_NONE0x
>> @@ -1027,4 +1028,10 @@ struct sctp_reset_streams {
>> uint16_t srs_stream_list[]; /* list if srs_num_streams is not 0 */
>> };
>>
>> +struct sctp_add_streams {
>> + sctp_assoc_t sas_assoc_id;
>> + uint16_t sas_instrms;
>> + uint16_t sas_outstrms;
>> +};
>> +
>> #endif /* _UAPI_SCTP_H */
>> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
>> index 2c5c9ca..ae0a99e 100644
>> --- a/net/sctp/socket.c
>> +++ b/net/sctp/socket.c
>> @@ -3838,6 +3838,32 @@ static int sctp_setsockopt_reset_assoc(struct sock
>> *sk,
>> return retval;
>> }
>>
>> +static int sctp_setsockopt_add_streams(struct sock *sk,
>> +char __user *optval,
>> +unsigned int optlen)
>> +{
>> + struct sctp_association *asoc;
>> + struct sctp_add_streams params;
>> + int retval = -EINVAL;
>> +
>> + if (optlen != sizeof(params))
>> + goto out;
>> +
>> + if (copy_from_user(¶ms, optval, optlen)) {
>> + retval = -EFAULT;
>> + goto out;
>> + }
>> +
>> + asoc = sctp_id2assoc(sk, params.sas_assoc_id);
>> + if (!asoc)
>> + goto out;
>> +
>> + retval = sctp_send_add_streams(asoc, ¶ms);
>> +
>> +out:
>> + return retval;
>> +}
>> +
>> /* API 6.2 setsockopt(), getsockopt()
>> *
>> * Applications use setsockopt() and getsockopt() to set or retrieve
>> @@ -4013,6 +4039,9 @@ static int sctp_setsockopt(struct sock *sk, int level,
>> int optname,
>> case SCTP_RESET_ASSOC:
>> retval = sctp_setsockopt_reset_assoc(sk, optval, optlen);
>> break;
>> + case SCTP_ADD_STREAMS:
>> + retval = sctp_setsockopt_add_streams(sk, optval, optlen);
>> + break;
>> default:
>> retval = -ENOPROTOOPT;
>> break;
>> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
>> index b368191..ba41837 100644
>> --- a/net/sctp/stream.c
>> +++ b/net/sctp/stream.c
>> @@ -195,3 +195,102 @@ int sctp_send_reset_assoc(struct sctp_association
>> *asoc)
>>
>> return retval;
>> }
>> +
>> +int sctp_send_add_streams(struct sctp_association *asoc,
>> + struct sctp_add_streams *params)
>> +{
>> + struct sctp_stream *stream = asoc->stream;
>> + struct sctp_chunk *chunk = NULL;
>> + int retval = -EINVAL;
>> + __u16 out, in;
>> +
>> + if (!asoc->peer.reconf_capable ||
>> + !(asoc->strreset_enable & SCTP_ENABLE_CHANGE_ASSOC_REQ)) {
>> + retval = -ENOPROTOOPT;
>> + goto out;
>> + }
>> +
>> + if (asoc->strreset_outstanding) {
>> + retval = -EINPROGRESS;
>> + goto out;
>> + }
>> +
>> + out = params->sas_outstrms;
>> + in = params->sas_instrms;
>> +
>> + if (!out && !in)
>
> [@]
>
>> + goto out;
>> +
>> + if (out) {
>> + __u16 nums = stream->outcnt + out;
>> +
>> + /* Check for overflow, can't use nums here */
>> + if (stream->outcnt + out > SCTP_MAX_STREAM)
>> + goto out;
>
> You should do these overflow checks before doing actual work,
> preferreably at [@] mark above.
> Here it's fine, but when [*] below run, it may be too late.
>
>> +
>> + /* Use ksize to chec
ipv6_get_ifaddr() not exported
Hi all, I'm working on a custom Netfilter module which could seemingly use ipv6_get_ifaddr() function to find a netdev which has a destination IPv6 assigned (if any). The function is public, but not exported, so I can't use it in my module. Am I doing anything wrong, or I'm just a first type to use ipv6_get_ifaddr() outside net/ipv6 code, and it's okay to export it now? Thanks, Valentine
[PATCH net-next] cxgb4: Fix unused variable warning
Fix unused variable warning when CONFIG_PCI_IOV is not defined. Signed-off-by: Ganesh Goudar --- drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c index 4da6f90..49e000e 100644 --- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c +++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c @@ -4643,7 +4643,9 @@ static int init_one(struct pci_dev *pdev, const struct pci_device_id *ent) u32 whoami, pl_rev; enum chip_type chip; static int adap_idx = 1; +#ifdef CONFIG_PCI_IOV u32 v, port_vec; +#endif printk_once(KERN_INFO "%s - version %s\n", DRV_DESC, DRV_VERSION); -- 2.1.0
[PATCH iproute2 net-next v2] tc: m_csum: add support for SCTP checksum
'sctp' parameter can now be used as 'csum' target to enable CRC32c
computation on SCTP packets.
Signed-off-by: Davide Caratti
---
Notes:
V2
- update man/man8/tc-csum.8 to include 'sctp' target
man/man8/tc-csum.8 | 7 +--
tc/m_csum.c| 11 ---
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/man/man8/tc-csum.8 b/man/man8/tc-csum.8
index 3a64c82..f4392a4 100644
--- a/man/man8/tc-csum.8
+++ b/man/man8/tc-csum.8
@@ -19,6 +19,7 @@ csum - checksum update action
.BR tcp " |"
.BR udp " |"
.BR udplite " |"
+.BR sctp " |"
.IR SWEETS " }"
.ti -8
@@ -43,9 +44,11 @@ IGMP header
TCP header
.RB ( tcp ),
UDP header
-.RB ( udp ") or"
+.RB ( udp ),
UDPLite header
-.RB ( udplite ).
+.RB ( udplite ") or"
+SCTP header
+.RB ( sctp ).
.TP
.B SWEETS
These are merely syntactic sugar and ignored internally.
diff --git a/tc/m_csum.c b/tc/m_csum.c
index d5b1af6..0ee8cad 100644
--- a/tc/m_csum.c
+++ b/tc/m_csum.c
@@ -24,7 +24,7 @@ explain(void)
{
fprintf(stderr, "Usage: ... csum \n"
"Where: UPDATE := []\n"
- " TARGET := { ip4h | icmp | igmp | tcp | udp |
udplite | }\n"
+ " TARGET := { ip4h | icmp | igmp | tcp | udp |
udplite | sctp | }\n"
" SWEETS := { and | or | \'+\' }\n");
}
@@ -65,6 +65,9 @@ parse_csum_args(int *argc_p, char ***argv_p, struct tc_csum
*sel)
else if (matches(*argv, "udplite") == 0)
sel->update_flags |= TCA_CSUM_UPDATE_FLAG_UDPLITE;
+ else if (matches(*argv, "sctp") == 0)
+ sel->update_flags |= TCA_CSUM_UPDATE_FLAG_SCTP;
+
else if ((matches(*argv, "and") == 0) ||
(matches(*argv, "or") == 0) ||
(matches(*argv, "+") == 0))
@@ -160,6 +163,7 @@ print_csum(struct action_util *au, FILE *f, struct rtattr
*arg)
char *uflag_4 = "";
char *uflag_5 = "";
char *uflag_6 = "";
+ char *uflag_7 = "";
int uflag_count = 0;
@@ -191,13 +195,14 @@ print_csum(struct action_util *au, FILE *f, struct rtattr
*arg)
CSUM_UFLAG_BUFFER(uflag_4, TCA_CSUM_UPDATE_FLAG_TCP, "tcp");
CSUM_UFLAG_BUFFER(uflag_5, TCA_CSUM_UPDATE_FLAG_UDP, "udp");
CSUM_UFLAG_BUFFER(uflag_6, TCA_CSUM_UPDATE_FLAG_UDPLITE, "udplite");
+ CSUM_UFLAG_BUFFER(uflag_7, TCA_CSUM_UPDATE_FLAG_SCTP, "sctp");
if (!uflag_count) {
uflag_1 = "?empty";
}
- fprintf(f, "csum (%s%s%s%s%s%s) action %s\n",
+ fprintf(f, "csum (%s%s%s%s%s%s%s) action %s\n",
uflag_1, uflag_2, uflag_3,
- uflag_4, uflag_5, uflag_6,
+ uflag_4, uflag_5, uflag_6, uflag_7,
action_n2a(sel->action));
fprintf(f, "\tindex %u ref %d bind %d", sel->index, sel->refcnt,
sel->bindcnt);
--
2.7.4
Re: [PATCH net] net/mlx5e: Do not recycle pages from emergency reserve
On Thu, Jan 19, 2017 at 9:03 AM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> A driver using dev_alloc_page() must not reuse a page allocated from
> emergency memory reserve.
>
> Otherwise all packets using this page will be immediately dropped,
> unless for very specific sockets having SOCK_MEMALLOC bit set.
>
> This issue might be hard to debug, because only a fraction of received
> packets would be dropped.
>
> Fixes: 4415a0319f92 ("net/mlx5e: Implement RX mapped page cache for page
> recycle")
> Signed-off-by: Eric Dumazet
> Cc: Tariq Toukan
> Cc: Saeed Mahameed
Acked-by: Saeed Mahameed
Please read and get back to me its urgent. Thank you!
Good day, I have an important message for you concerning the death of my deceased client . I am aware you are not related to this by blood, nationality or family, therefore I ask that you consider the factors in my email and keep it strictly confidential. However, if you are unable to meet my demand, kindly discard of it. This is regards the fund 15.5 million us dollars and 5 Kilos of GOLD BAR he left behind here in this country (Togo),Contact me with your full names, occupation, country of residence and direct telephone number only at (bikkobikko...@consultant.com) for full details regards this claim.I await your urgent response today. Regards, Benjamin Bikko .
Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving
On Fri, Jan 20, 2017 at 6:32 AM, Jason Wang wrote:
> Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
> xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
> fixing this by adding a hint (has_data_valid) and set it only on the
> receiving path.
>
> Cc: Rolf Neugebauer
> Signed-off-by: Jason Wang
Acked-by: Rolf Neugebauer
Ah, I missed this use of the function. Looks like this patch does not
regress the issue I was seeing with virtio_net.
Rolf
> ---
> drivers/net/macvtap.c | 2 +-
> drivers/net/tun.c | 2 +-
> drivers/net/virtio_net.c | 2 +-
> include/linux/virtio_net.h | 6 +-
> net/packet/af_packet.c | 4 ++--
> 5 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 5c26653..4026185 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
> return -EINVAL;
>
> if (virtio_net_hdr_from_skb(skb, &vnet_hdr,
> - macvtap_is_little_endian(q)))
> + macvtap_is_little_endian(q),
> true))
> BUG();
>
> if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index cd8e02c..2cd10b2 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> return -EINVAL;
>
> if (virtio_net_hdr_from_skb(skb, &gso,
> - tun_is_little_endian(tun))) {
> + tun_is_little_endian(tun), true))
> {
> struct skb_shared_info *sinfo = skb_shinfo(skb);
> pr_err("unexpected GSO type: "
>"0x%x, gso_size %d, hdr_len %d\n",
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4a10500..3474243 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct
> sk_buff *skb)
> hdr = skb_vnet_hdr(skb);
>
> if (virtio_net_hdr_from_skb(skb, &hdr->hdr,
> - virtio_is_little_endian(vi->vdev)))
> + virtio_is_little_endian(vi->vdev), false))
> BUG();
>
> if (vi->mergeable_rx_bufs)
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index 5643647..5209b5e 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
>
> static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> struct virtio_net_hdr *hdr,
> - bool little_endian)
> + bool little_endian,
> + bool has_data_valid)
> {
> memset(hdr, 0, sizeof(*hdr)); /* no info leak */
>
> @@ -91,6 +92,9 @@ static inline int virtio_net_hdr_from_skb(const struct
> sk_buff *skb,
> skb_checksum_start_offset(skb));
> hdr->csum_offset = __cpu_to_virtio16(little_endian,
> skb->csum_offset);
> + } else if (has_data_valid &&
> + skb->ip_summed == CHECKSUM_UNNECESSARY) {
> + hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
>
> return 0;
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index b9e1a13..3d555c7 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1976,7 +1976,7 @@ static int packet_rcv_vnet(struct msghdr *msg, const
> struct sk_buff *skb,
> return -EINVAL;
> *len -= sizeof(vnet_hdr);
>
> - if (virtio_net_hdr_from_skb(skb, &vnet_hdr, vio_le()))
> + if (virtio_net_hdr_from_skb(skb, &vnet_hdr, vio_le(), true))
> return -EINVAL;
>
> return memcpy_to_msg(msg, (void *)&vnet_hdr, sizeof(vnet_hdr));
> @@ -2237,7 +2237,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct
> net_device *dev,
> if (po->has_vnet_hdr) {
> if (virtio_net_hdr_from_skb(skb, h.raw + macoff -
> sizeof(struct virtio_net_hdr),
> - vio_le())) {
> + vio_le(), true)) {
> spin_lock(&sk->sk_receive_queue.lock);
> goto drop_n_account;
> }
> --
> 2.7.4
>
Re: Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
Hi,
>
>
> This patch should be enhanced with the smb_xx() calls as suggested by by Lino.
>
If you do this, please place the smp_rmb() before the if condition in the irq
handler like
smp_rmb();
if (rtlpci->irq_enabled == 0) {
return ret;
as I think that the suggestion I made before was not correct (sorry for the
confusion).
Regards,
Lino
Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341 (fwd)
mv88e6xxx_6341_family is checked twice, on line 2606 and 2607.
julia
-- Forwarded message --
Date: Fri, 20 Jan 2017 19:38:12 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch
88E6341
In-Reply-To: <20170119214934.27442-3-gregory.clem...@free-electrons.com>
Hi Gregory,
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20170120]
[cannot apply to v4.10-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Gregory-CLEMENT/Add-support-for-the-ethernet-switch-on-the-ESPRESSObin/20170120-180348
:: branch date: 2 hours ago
:: commit date: 2 hours ago
>> drivers/net/dsa/mv88e6xxx/chip.c:2606:36-63: duplicated argument to && or ||
git remote add linux-review https://github.com/0day-ci/linux
git remote update linux-review
git checkout c618c22093235e96adf0c6f39497eeed083a60cf
vim +2606 drivers/net/dsa/mv88e6xxx/chip.c
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2590
if (err)
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2591
return err;
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2592
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2593
/* Egress rate control 2: disable egress rate control. */
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2594
err = mv88e6xxx_port_write(chip, port, PORT_RATE_CONTROL_2, 0x);
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2595
if (err)
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2596
return err;
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2597
b35d322a1 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-12-03 2598
if (chip->info->ops->port_pause_config) {
b35d322a1 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-12-03 2599
err = chip->info->ops->port_pause_config(chip, port);
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2600
if (err)
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2601
return err;
b35d322a1 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-12-03 2602
}
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2603
b35d322a1 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-12-03 2604
if (mv88e6xxx_6352_family(chip) || mv88e6xxx_6351_family(chip) ||
b35d322a1 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-12-03 2605
mv88e6xxx_6165_family(chip) || mv88e6xxx_6097_family(chip) ||
c618c2209 drivers/net/dsa/mv88e6xxx/chip.c Gregory CLEMENT 2017-01-19 @2606
mv88e6xxx_6320_family(chip) || mv88e6xxx_6341_family(chip) ||
c618c2209 drivers/net/dsa/mv88e6xxx/chip.c Gregory CLEMENT 2017-01-19 2607
mv88e6xxx_6341_family(chip)) {
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2608
/* Port ATU control: disable limiting the number of
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2609
* address database entries that this port is allowed
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2610
* to use.
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2611
*/
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2612
err = mv88e6xxx_port_write(chip, port, PORT_ATU_CONTROL,
0e7b99257 drivers/net/dsa/mv88e6xxx/chip.c Andrew Lunn 2016-09-21 2613
0x);
54d792f25 drivers/net/dsa/mv88e6xxx.c Andrew Lunn 2015-05-06 2614
/* Priority Override: disable DA, SA and VTU priority
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
Re: [PATCHv3 net-next 4/4] sctp: implement sender-side procedures for Add Incoming/Outgoing Streams Request Parameter
On Fri, Jan 20, 2017 at 04:56:30PM +0800, Xin Long wrote:
> On Fri, Jan 20, 2017 at 5:47 AM, Marcelo Ricardo Leitner
> wrote:
> > On Fri, Jan 20, 2017 at 01:19:14AM +0800, Xin Long wrote:
> >> This patch is to implement Sender-Side Procedures for the Add
> >> Outgoing and Incoming Streams Request Parameter described in
> >> rfc6525 section 5.1.5-5.1.6.
> >>
> >> It is also to add sockopt SCTP_ADD_STREAMS in rfc6525 section
> >> 6.3.4 for users.
> >>
> >> Signed-off-by: Xin Long
> >> ---
> >> include/net/sctp/sctp.h | 2 +
> >> include/uapi/linux/sctp.h | 7
> >> net/sctp/socket.c | 29 ++
> >> net/sctp/stream.c | 99
> >> +++
> >> 4 files changed, 137 insertions(+)
> >>
> >> diff --git a/include/net/sctp/sctp.h b/include/net/sctp/sctp.h
> >> index b93820f..68ee1a6 100644
> >> --- a/include/net/sctp/sctp.h
> >> +++ b/include/net/sctp/sctp.h
> >> @@ -199,6 +199,8 @@ int sctp_offload_init(void);
> >> int sctp_send_reset_streams(struct sctp_association *asoc,
> >> struct sctp_reset_streams *params);
> >> int sctp_send_reset_assoc(struct sctp_association *asoc);
> >> +int sctp_send_add_streams(struct sctp_association *asoc,
> >> + struct sctp_add_streams *params);
> >>
> >> /*
> >> * Module global variables
> >> diff --git a/include/uapi/linux/sctp.h b/include/uapi/linux/sctp.h
> >> index c0bd8c3..a91a9cc 100644
> >> --- a/include/uapi/linux/sctp.h
> >> +++ b/include/uapi/linux/sctp.h
> >> @@ -118,6 +118,7 @@ typedef __s32 sctp_assoc_t;
> >> #define SCTP_ENABLE_STREAM_RESET 118
> >> #define SCTP_RESET_STREAMS 119
> >> #define SCTP_RESET_ASSOC 120
> >> +#define SCTP_ADD_STREAMS 121
> >>
> >> /* PR-SCTP policies */
> >> #define SCTP_PR_SCTP_NONE0x
> >> @@ -1027,4 +1028,10 @@ struct sctp_reset_streams {
> >> uint16_t srs_stream_list[]; /* list if srs_num_streams is not 0
> >> */
> >> };
> >>
> >> +struct sctp_add_streams {
> >> + sctp_assoc_t sas_assoc_id;
> >> + uint16_t sas_instrms;
> >> + uint16_t sas_outstrms;
> >> +};
> >> +
> >> #endif /* _UAPI_SCTP_H */
> >> diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> >> index 2c5c9ca..ae0a99e 100644
> >> --- a/net/sctp/socket.c
> >> +++ b/net/sctp/socket.c
> >> @@ -3838,6 +3838,32 @@ static int sctp_setsockopt_reset_assoc(struct sock
> >> *sk,
> >> return retval;
> >> }
> >>
> >> +static int sctp_setsockopt_add_streams(struct sock *sk,
> >> +char __user *optval,
> >> +unsigned int optlen)
> >> +{
> >> + struct sctp_association *asoc;
> >> + struct sctp_add_streams params;
> >> + int retval = -EINVAL;
> >> +
> >> + if (optlen != sizeof(params))
> >> + goto out;
> >> +
> >> + if (copy_from_user(¶ms, optval, optlen)) {
> >> + retval = -EFAULT;
> >> + goto out;
> >> + }
> >> +
> >> + asoc = sctp_id2assoc(sk, params.sas_assoc_id);
> >> + if (!asoc)
> >> + goto out;
> >> +
> >> + retval = sctp_send_add_streams(asoc, ¶ms);
> >> +
> >> +out:
> >> + return retval;
> >> +}
> >> +
> >> /* API 6.2 setsockopt(), getsockopt()
> >> *
> >> * Applications use setsockopt() and getsockopt() to set or retrieve
> >> @@ -4013,6 +4039,9 @@ static int sctp_setsockopt(struct sock *sk, int
> >> level, int optname,
> >> case SCTP_RESET_ASSOC:
> >> retval = sctp_setsockopt_reset_assoc(sk, optval, optlen);
> >> break;
> >> + case SCTP_ADD_STREAMS:
> >> + retval = sctp_setsockopt_add_streams(sk, optval, optlen);
> >> + break;
> >> default:
> >> retval = -ENOPROTOOPT;
> >> break;
> >> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> >> index b368191..ba41837 100644
> >> --- a/net/sctp/stream.c
> >> +++ b/net/sctp/stream.c
> >> @@ -195,3 +195,102 @@ int sctp_send_reset_assoc(struct sctp_association
> >> *asoc)
> >>
> >> return retval;
> >> }
> >> +
> >> +int sctp_send_add_streams(struct sctp_association *asoc,
> >> + struct sctp_add_streams *params)
> >> +{
> >> + struct sctp_stream *stream = asoc->stream;
> >> + struct sctp_chunk *chunk = NULL;
> >> + int retval = -EINVAL;
> >> + __u16 out, in;
> >> +
> >> + if (!asoc->peer.reconf_capable ||
> >> + !(asoc->strreset_enable & SCTP_ENABLE_CHANGE_ASSOC_REQ)) {
> >> + retval = -ENOPROTOOPT;
> >> + goto out;
> >> + }
> >> +
> >> + if (asoc->strreset_outstanding) {
> >> + retval = -EINPROGRESS;
> >> + goto out;
> >> + }
> >> +
> >> + out = params->sas_outstrms;
> >> + in = params->sas_instrms;
> >> +
> >> + if (!out && !in)
> >
> > [@]
> >
> >> + goto out;
> >> +
> >> + if (out) {
> >> + __u16 nums = stream->outcnt + out;
> >> +
> >> +
Re: [PATCH] net: ethtool: avoid allocation failure for dump_regs
David Miller writes:
> From: Kalle Valo
> Date: Thu, 19 Jan 2017 20:08:30 +0200
>
>> "John W. Linville" writes:
>>
>>> I forgot to Cc Johannes and Kalle...
>>
>> Also adding linux-wireless.
>>
>>> On Thu, Jan 19, 2017 at 09:15:09AM -0500, John W. Linville wrote:
>>>
I'm responsible for this mess. The original idea was for various
mac80211-based drivers to override the ethtool operation and provide
their own dump operation, but the mac80211 crowd never embraced
the idea.
In the meantime, I added the default implementation which just
passed-up wdev->wiphy->hw_version as the version info for a 0-length
register dump. I then implemented a driver-specific regiser dump
handler for userland ethtool that would interpret the hardware version
information for the at76c50x-usb driver.
So the net of it is, if we treat a return of 0 from get_regs_len()
as "not supported", we break this one driver-specific feature for
userland ethtool. Realistically, there are probably very few users
to care. But I can't guarantee that the number is zero.
>>
>> I know the number is not zero, because I remember using it years back
>> with something else than at76c50x-usb. But is the number more than one,
>> I don't know :)
>
> I'm trying to dig down and figure out why this problem is showing up now.
> ethtool_get_regs() has been using vzalloc() since 2011, and before that it
> used plain vmalloc().
>
> This code has therefore been using v{m,z}alloc() forever. What changed?
>
> The zero size check has been in the vmalloc implementation since at least
> 2009.
>
> I don't understand why this is all triggering and being noticed now. The
> whole ieee80211 "return zero length regs and return hw version in get_regs"
> thing should have been failing for at least 7 years now.
Maybe just nobody hasn't used it since? If my memory serves me right
(too often it does not) It's 6-7 years since I used this, and if the
kernel I worked on at the time was a year or two old, I might have used
a version without the zero size check.
But I'm just hand-waving here, I cannot be sure what's the last kernel I
used.
--
Kalle Valo
RE: [PATCH net-next V4] tc: flower: Refactor matching flags to be more user friendly
From: Of Jiri Benc
> Sent: 19 January 2017 14:22
> On Thu, 19 Jan 2017 16:17:48 +0200, Paul Blakey wrote:
> > + while (token) {
> > + if (!strncmp(token, "no", 2)) {
> > + no = true;
> > + token = strchr(token, '_') + 1;
>
> This seems to still assume that "no" is followed by an underscore.
> What about a simple token += 2?
Actually it was rather worse than that and probably shows a
distinct lack of testing.
Consider what happened with "no", "nofubar" and "nofubar_baz",
all ought to be rejected.
Actually using strncmp() is also overkill.
Nothing wrong with:
if (token[0] == 'n' && token[1] == 'o' && token[2]) {
no = true;
token += 2;
if (token[0] == '_' && token[1])
token++;
...
or replace the last 3 lines with:
token += 2 + (token[2] == '_' & token[3]);
David
[RFC PATCH] net: stmicro: eQOS IP Core
For historical reasons the Designware eQOS IP Core started in version 4.x,
instead of starting in 1.x. This caused some misunderstanding, which resulted
in calling this IP as GMAC4. If you go to Synopsys website and check the
Ethernet portfolio there is no GMAC4 IP:
https://www.synopsys.com/designware-ip/interface-ip/ethernet.html
There is a new version of eQOS comming out (5.x) that will have the same
mac, dma registers and flow, with an extra set of registers to enable
features like TSN. The creation of a dwmac5 or gmac5 would be wrong, and
including those new features related to eQOS 5.x in dwmac4 would also not
be very correct.
This patch suggests to rename dwmac4_* driver to eqos_*, turning it the
official driver for eQOS IP. The registers definitions are also now
called QOS_ instead of GMAC4_.
For more information about eQOS IP please check:
https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_qos
Signed-off-by: Joao Pinto
---
drivers/net/ethernet/stmicro/stmmac/Makefile | 4 +-
drivers/net/ethernet/stmicro/stmmac/common.h | 16 +--
.../ethernet/stmicro/stmmac/dwmac-dwc-qos-eth.c| 4 +-
.../ethernet/stmicro/stmmac/{dwmac4.h => eqos.h} | 28 ++---
.../stmicro/stmmac/{dwmac4_core.c => eqos_core.c} | 125 ++---
.../stmmac/{dwmac4_descs.c => eqos_descs.c}| 92 +++
.../stmmac/{dwmac4_descs.h => eqos_descs.h}| 8 +-
.../stmicro/stmmac/{dwmac4_dma.c => eqos_dma.c}| 125 ++---
.../stmicro/stmmac/{dwmac4_dma.h => eqos_dma.h}| 38 +++
.../stmicro/stmmac/{dwmac4_lib.c => eqos_lib.c}| 36 +++---
drivers/net/ethernet/stmicro/stmmac/mmc.h | 2 +-
.../net/ethernet/stmicro/stmmac/stmmac_ethtool.c | 4 +-
.../net/ethernet/stmicro/stmmac/stmmac_hwtstamp.c | 10 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 42 +++
drivers/net/ethernet/stmicro/stmmac/stmmac_mdio.c | 20 ++--
drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c | 30 +++--
.../net/ethernet/stmicro/stmmac/stmmac_platform.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_ptp.h | 4 +-
include/linux/stmmac.h | 2 +-
20 files changed, 300 insertions(+), 294 deletions(-)
rename drivers/net/ethernet/stmicro/stmmac/{dwmac4.h => eqos.h} (93%)
rename drivers/net/ethernet/stmicro/stmmac/{dwmac4_core.c => eqos_core.c} (77%)
rename drivers/net/ethernet/stmicro/stmmac/{dwmac4_descs.c => eqos_descs.c}
(78%)
rename drivers/net/ethernet/stmicro/stmmac/{dwmac4_descs.h => eqos_descs.h}
(97%)
rename drivers/net/ethernet/stmicro/stmmac/{dwmac4_dma.c => eqos_dma.c} (77%)
rename drivers/net/ethernet/stmicro/stmmac/{dwmac4_dma.h => eqos_dma.h} (86%)
rename drivers/net/ethernet/stmicro/stmmac/{dwmac4_lib.c => eqos_lib.c} (83%)
diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile
b/drivers/net/ethernet/stmicro/stmmac/Makefile
index 700c603..6b7df7f 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -2,8 +2,8 @@ obj-$(CONFIG_STMMAC_ETH) += stmmac.o
stmmac-objs:= stmmac_main.o stmmac_ethtool.o stmmac_mdio.o ring_mode.o \
chain_mode.o dwmac_lib.o dwmac1000_core.o dwmac1000_dma.o \
dwmac100_core.o dwmac100_dma.o enh_desc.o norm_desc.o \
- mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o dwmac4_descs.o \
- dwmac4_dma.o dwmac4_lib.o dwmac4_core.o $(stmmac-y)
+ mmc_core.o stmmac_hwtstamp.o stmmac_ptp.o eqos_descs.o\
+ eqos_dma.o eqos_lib.o eqos_core.o $(stmmac-y)
# Ordering matters. Generic driver must be last.
obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/common.h
b/drivers/net/ethernet/stmicro/stmmac/common.h
index 75e2666..2645a09 100644
--- a/drivers/net/ethernet/stmicro/stmmac/common.h
+++ b/drivers/net/ethernet/stmicro/stmmac/common.h
@@ -493,16 +493,16 @@ struct stmmac_ops {
struct stmmac_hwtimestamp {
void (*config_hw_tstamping) (void __iomem *ioaddr, u32 data);
u32 (*config_sub_second_increment)(void __iomem *ioaddr, u32 ptp_clock,
- int gmac4);
+ int qos);
int (*init_systime) (void __iomem *ioaddr, u32 sec, u32 nsec);
int (*config_addend) (void __iomem *ioaddr, u32 addend);
int (*adjust_systime) (void __iomem *ioaddr, u32 sec, u32 nsec,
- int add_sub, int gmac4);
+ int add_sub, int qos);
u64(*get_systime) (void __iomem *ioaddr);
};
extern const struct stmmac_hwtimestamp stmmac_ptp;
-extern const struct stmmac_mode_ops dwmac4_ring_mode_ops;
+extern const struct stmmac_mode_ops eqos_ring_mode_ops;
struct mac_link {
int port;
@@ -555,7 +555,7 @@ struct mac_device_info *dwmac1000_setup(void __iomem
*ioaddr, int mcbins,
[PATCH] net: sctp: fix array overrun read on sctp_timer_tbl
From: Colin Ian King
The comparison on the timeout can lead to an array overrun
read on sctp_timer_tbl because of an off-by-one error. Fix
this by using < instead of <= and also compare to the array
size rather than SCTP_EVENT_TIMEOUT_MAX.
Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
Signed-off-by: Colin Ian King
---
net/sctp/debug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sctp/debug.c b/net/sctp/debug.c
index 95d7b15..e371a0d 100644
--- a/net/sctp/debug.c
+++ b/net/sctp/debug.c
@@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[] = {
/* Lookup timer debug name. */
const char *sctp_tname(const sctp_subtype_t id)
{
- if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
+ if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
return sctp_timer_tbl[id.timeout];
return "unknown_timer";
}
--
2.10.2
[PATCH net-next] net: remove bh disabling around percpu_counter accesses
From: Eric Dumazet
Shaohua Li made percpu_counter irq safe in commit 098faf5805c8
("percpu_counter: make APIs irq safe")
We can safely remove BH disable/enable sections around various
percpu_counter manipulations.
Signed-off-by: Eric Dumazet
---
include/net/dst_ops.h |9 +
include/net/inet_frag.h |8 +---
net/ipv4/inet_connection_sock.c |3 +--
net/ipv4/proc.c |2 --
net/ipv4/tcp.c |2 --
net/ipv4/tcp_ipv4.c |2 --
6 files changed, 3 insertions(+), 23 deletions(-)
diff --git a/include/net/dst_ops.h b/include/net/dst_ops.h
index
a0d443ca16fcca26b4925d477265935f5bdaf5bc..8a2b66d8d78de33f18f1343f97fd7d29e935fbfa
100644
--- a/include/net/dst_ops.h
+++ b/include/net/dst_ops.h
@@ -46,19 +46,12 @@ static inline int dst_entries_get_fast(struct dst_ops *dst)
static inline int dst_entries_get_slow(struct dst_ops *dst)
{
- int res;
-
- local_bh_disable();
- res = percpu_counter_sum_positive(&dst->pcpuc_entries);
- local_bh_enable();
- return res;
+ return percpu_counter_sum_positive(&dst->pcpuc_entries);
}
static inline void dst_entries_add(struct dst_ops *dst, int val)
{
- local_bh_disable();
percpu_counter_add(&dst->pcpuc_entries, val);
- local_bh_enable();
}
static inline int dst_entries_init(struct dst_ops *dst)
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index
909972aa3acd7e4e3d865800f45056235efc7bef..5894730ec82a9fba3b9bca160de6e0db3a73024e
100644
--- a/include/net/inet_frag.h
+++ b/include/net/inet_frag.h
@@ -164,13 +164,7 @@ static inline void add_frag_mem_limit(struct netns_frags
*nf, int i)
static inline unsigned int sum_frag_mem_limit(struct netns_frags *nf)
{
- unsigned int res;
-
- local_bh_disable();
- res = percpu_counter_sum_positive(&nf->mem);
- local_bh_enable();
-
- return res;
+ return percpu_counter_sum_positive(&nf->mem);
}
/* RFC 3168 support :
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index
096a085611ab8dc2b0666ed9859bf792f396dc43..c7f7c53353691070813eeb7ece86d1826f408fd5
100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -836,9 +836,8 @@ void inet_csk_destroy_sock(struct sock *sk)
sk_refcnt_debug_release(sk);
- local_bh_disable();
percpu_counter_dec(sk->sk_prot->orphan_count);
- local_bh_enable();
+
sock_put(sk);
}
EXPORT_SYMBOL(inet_csk_destroy_sock);
diff --git a/net/ipv4/proc.c b/net/ipv4/proc.c
index
0247ca0322327bc42273b675b769c1f176ba33f4..a9deeb90dd36e0a8f94596b4f563ad63925344cf
100644
--- a/net/ipv4/proc.c
+++ b/net/ipv4/proc.c
@@ -57,10 +57,8 @@ static int sockstat_seq_show(struct seq_file *seq, void *v)
unsigned int frag_mem;
int orphans, sockets;
- local_bh_disable();
orphans = percpu_counter_sum_positive(&tcp_orphan_count);
sockets = proto_sockets_allocated_sum_positive(&tcp_prot);
- local_bh_enable();
socket_seq_show(seq);
seq_printf(seq, "TCP: inuse %d orphan %d tw %d alloc %d mem %ld\n",
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index
aba6ea76338e35e36124580dcab3c80e3c638659..c43eb1a831d7a0a36b447421908a149b1808590b
100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -420,9 +420,7 @@ void tcp_init_sock(struct sock *sk)
sk->sk_sndbuf = sysctl_tcp_wmem[1];
sk->sk_rcvbuf = sysctl_tcp_rmem[1];
- local_bh_disable();
sk_sockets_allocated_inc(sk);
- local_bh_enable();
}
EXPORT_SYMBOL(tcp_init_sock);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index
3644fc1176918d81c645e0e79c4ec3aec4216474..f7325b25b06e65581ecc496f95e819aa738c0987
100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1887,9 +1887,7 @@ void tcp_v4_destroy_sock(struct sock *sk)
tcp_free_fastopen_req(tp);
tcp_saved_syn_free(tp);
- local_bh_disable();
sk_sockets_allocated_dec(sk);
- local_bh_enable();
}
EXPORT_SYMBOL(tcp_v4_destroy_sock);
[PATCH] net: phy: micrel: add KSZ8795 ethernet switch
This ethernet switch have unfortunately the same phy id as KSZ8051.
Signed-off-by: Sean Nyekjaer
---
drivers/net/phy/micrel.c | 14 ++
include/linux/micrel_phy.h | 2 ++
2 files changed, 16 insertions(+)
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index ea92d524d5a8..d47026c18974 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -1014,6 +1014,20 @@ static struct phy_driver ksphy_driver[] = {
.get_stats = kszphy_get_stats,
.suspend= genphy_suspend,
.resume = genphy_resume,
+}, {
+ .phy_id = PHY_ID_KSZ8795,
+ .phy_id_mask= MICREL_PHY_ID_MASK,
+ .name = "Micrel KSZ8795 Switch",
+ .features = (PHY_BASIC_FEATURES | SUPPORTED_Pause),
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init= kszphy_config_init,
+ .config_aneg= genphy_config_aneg,
+ .read_status= genphy_read_status,
+ .get_sset_count = kszphy_get_sset_count,
+ .get_strings= kszphy_get_strings,
+ .get_stats = kszphy_get_stats,
+ .suspend= genphy_suspend,
+ .resume = genphy_resume,
} };
module_phy_driver(ksphy_driver);
diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
index 257173e0095e..f541da68d1e7 100644
--- a/include/linux/micrel_phy.h
+++ b/include/linux/micrel_phy.h
@@ -35,6 +35,8 @@
#define PHY_ID_KSZ886X 0x00221430
#define PHY_ID_KSZ8863 0x00221435
+#define PHY_ID_KSZ8795 0x00221550
+
/* struct phy_device dev_flags definitions */
#define MICREL_PHY_50MHZ_CLK 0x0001
#define MICREL_PHY_FXEN0x0002
--
2.11.0
Re: [PATCH] net: sctp: fix array overrun read on sctp_timer_tbl
On Fri, Jan 20, 2017 at 01:01:57PM +, Colin King wrote:
> From: Colin Ian King
>
> The comparison on the timeout can lead to an array overrun
> read on sctp_timer_tbl because of an off-by-one error. Fix
> this by using < instead of <= and also compare to the array
> size rather than SCTP_EVENT_TIMEOUT_MAX.
>
> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> Signed-off-by: Colin Ian King
> ---
> net/sctp/debug.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> index 95d7b15..e371a0d 100644
> --- a/net/sctp/debug.c
> +++ b/net/sctp/debug.c
> @@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[] = {
> /* Lookup timer debug name. */
> const char *sctp_tname(const sctp_subtype_t id)
> {
> - if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
> + if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
> return sctp_timer_tbl[id.timeout];
The issue exists but this is not the right fix.
Issue was introduced by 7b9438de0cd4 ("sctp: add stream reconf timer")
as it introduced a new timer but didn't add the timer name here, so the
fix should (also) include:
diff --git a/net/sctp/debug.c b/net/sctp/debug.c
index 95d7b15dad21..c5f4ed5242ac 100644
--- a/net/sctp/debug.c
+++ b/net/sctp/debug.c
@@ -159,6 +159,7 @@ static const char *const sctp_timer_tbl[] = {
"TIMEOUT_T4_RTO",
"TIMEOUT_T5_SHUTDOWN_GUARD",
"TIMEOUT_HEARTBEAT",
+ "TIMEOUT_RECONF",
"TIMEOUT_SACK",
"TIMEOUT_AUTOCLOSE",
};
Thanks,
Marcelo
> return "unknown_timer";
> }
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH] net: sctp: fix array overrun read on sctp_timer_tbl
On 20/01/17 13:10, Marcelo Ricardo Leitner wrote:
> On Fri, Jan 20, 2017 at 01:01:57PM +, Colin King wrote:
>> From: Colin Ian King
>>
>> The comparison on the timeout can lead to an array overrun
>> read on sctp_timer_tbl because of an off-by-one error. Fix
>> this by using < instead of <= and also compare to the array
>> size rather than SCTP_EVENT_TIMEOUT_MAX.
>>
>> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>>
>> Signed-off-by: Colin Ian King
>> ---
>> net/sctp/debug.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
>> index 95d7b15..e371a0d 100644
>> --- a/net/sctp/debug.c
>> +++ b/net/sctp/debug.c
>> @@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[] = {
>> /* Lookup timer debug name. */
>> const char *sctp_tname(const sctp_subtype_t id)
>> {
>> -if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
>> +if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
>> return sctp_timer_tbl[id.timeout];
>
> The issue exists but this is not the right fix.
> Issue was introduced by 7b9438de0cd4 ("sctp: add stream reconf timer")
> as it introduced a new timer but didn't add the timer name here, so the
> fix should (also) include:
>
> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> index 95d7b15dad21..c5f4ed5242ac 100644
> --- a/net/sctp/debug.c
> +++ b/net/sctp/debug.c
> @@ -159,6 +159,7 @@ static const char *const sctp_timer_tbl[] = {
> "TIMEOUT_T4_RTO",
> "TIMEOUT_T5_SHUTDOWN_GUARD",
> "TIMEOUT_HEARTBEAT",
> + "TIMEOUT_RECONF",
> "TIMEOUT_SACK",
> "TIMEOUT_AUTOCLOSE",
> };
Ah, OK, I can add that timeout into the the table, but perhaps it's
still prudent to check the index against the table size as well.
>
> Thanks,
> Marcelo
>
>> return "unknown_timer";
>> }
>> --
>> 2.10.2
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
[PATCH net-next] uapi: fix signess in ethtool_validate_speed()
From: Jonas Johansson
There is a comparison of speed variable which
is unsigned, and SPEED_UNKNOWN which is signed.
Signed-off-by: Jonas Johansson
Signed-off-by: Volodymyr Bendiuga
---
include/uapi/linux/ethtool.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
index f0db778..1ca4a77 100644
--- a/include/uapi/linux/ethtool.h
+++ b/include/uapi/linux/ethtool.h
@@ -1500,7 +1500,7 @@ enum ethtool_link_mode_bit_indices {
#define SPEED_UNKNOWN -1
-static inline int ethtool_validate_speed(__u32 speed)
+static inline int ethtool_validate_speed(__s32 speed)
{
return speed <= INT_MAX || speed == SPEED_UNKNOWN;
}
--
2.7.4
Re: [PATCH] net: sctp: fix array overrun read on sctp_timer_tbl
On Fri, Jan 20, 2017 at 01:15:18PM +, Colin Ian King wrote:
> On 20/01/17 13:10, Marcelo Ricardo Leitner wrote:
> > On Fri, Jan 20, 2017 at 01:01:57PM +, Colin King wrote:
> >> From: Colin Ian King
> >>
> >> The comparison on the timeout can lead to an array overrun
> >> read on sctp_timer_tbl because of an off-by-one error. Fix
> >> this by using < instead of <= and also compare to the array
> >> size rather than SCTP_EVENT_TIMEOUT_MAX.
> >>
> >> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
> >>
> >> Signed-off-by: Colin Ian King
> >> ---
> >> net/sctp/debug.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> >> index 95d7b15..e371a0d 100644
> >> --- a/net/sctp/debug.c
> >> +++ b/net/sctp/debug.c
> >> @@ -166,7 +166,7 @@ static const char *const sctp_timer_tbl[] = {
> >> /* Lookup timer debug name. */
> >> const char *sctp_tname(const sctp_subtype_t id)
> >> {
> >> - if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
> >> + if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
> >>return sctp_timer_tbl[id.timeout];
> >
> > The issue exists but this is not the right fix.
> > Issue was introduced by 7b9438de0cd4 ("sctp: add stream reconf timer")
> > as it introduced a new timer but didn't add the timer name here, so the
> > fix should (also) include:
> >
> > diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> > index 95d7b15dad21..c5f4ed5242ac 100644
> > --- a/net/sctp/debug.c
> > +++ b/net/sctp/debug.c
> > @@ -159,6 +159,7 @@ static const char *const sctp_timer_tbl[] = {
> > "TIMEOUT_T4_RTO",
> > "TIMEOUT_T5_SHUTDOWN_GUARD",
> > "TIMEOUT_HEARTBEAT",
> > + "TIMEOUT_RECONF",
> > "TIMEOUT_SACK",
> > "TIMEOUT_AUTOCLOSE",
> > };
>
> Ah, OK, I can add that timeout into the the table, but perhaps it's
> still prudent to check the index against the table size as well.
>
Yes, and/or a:
BUILD_BUG_ON(SCTP_EVENT_TIMEOUT_MAX + 1 != ARRAY_SIZE(sctp_timer_tbl))
As then we would be sure to have the list right :-)
Otherwise we may not do wrong reads but may report the wrong timer name.
> >
> > Thanks,
> > Marcelo
> >
> >>return "unknown_timer";
> >> }
> >> --
> >> 2.10.2
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
From: Colin Ian King
Table sctp_timer_tbl is missing a TIMEOUT_RECONF string so
add this in. Also compare timeout with the size of the array
sctp_timer_tbl rather than SCTP_EVENT_TIMEOUT_MAX. Also add
a build time check that SCTP_EVENT_TIMEOUT_MAX is correct
so we don't ever get this kind of mismatch between the table
and SCTP_EVENT_TIMEOUT_MAX in the future.
Kudos to Marcel Ricardo Leitner for spotting the missing string
and suggesting the build time sanity check.
Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
Signed-off-by: Colin Ian King
---
net/sctp/debug.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/sctp/debug.c b/net/sctp/debug.c
index 95d7b15..2e47eb2 100644
--- a/net/sctp/debug.c
+++ b/net/sctp/debug.c
@@ -159,6 +159,7 @@ static const char *const sctp_timer_tbl[] = {
"TIMEOUT_T4_RTO",
"TIMEOUT_T5_SHUTDOWN_GUARD",
"TIMEOUT_HEARTBEAT",
+ "TIMEOUT_RECONF",
"TIMEOUT_SACK",
"TIMEOUT_AUTOCLOSE",
};
@@ -166,7 +167,9 @@ static const char *const sctp_timer_tbl[] = {
/* Lookup timer debug name. */
const char *sctp_tname(const sctp_subtype_t id)
{
- if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
+ BUILD_BUG_ON(SCTP_EVENT_TIMEOUT_MAX + 1 != ARRAY_SIZE(sctp_timer_tbl));
+
+ if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
return sctp_timer_tbl[id.timeout];
return "unknown_timer";
}
--
2.10.2
Re: [PATCH v6 13/13] net: ethernet: aquantia: Integrate AQtion 2.5/5 GB NIC driver
Hi David, [auto build test ERROR on net-next/master] [also build test ERROR on v4.10-rc4 next-20170120] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Alexander-Loktionov/net-ethernet-aquantia-Make-and-configuration-files/20170119-19 config: arm-allmodconfig (attached as .config) compiler: arm-linux-gnueabi-gcc (Debian 6.1.1-9) 6.1.1 20160705 reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): >> ERROR: "__bad_udelay" [drivers/net/ethernet/aquantia/atlantic/atlantic.ko] >> undefined! --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
[PATCH] Bluetooth: hidp: might sleep error in hidp_session_thread
[ 39.044329] do not call blocking ops when !TASK_RUNNING; state=1 set
at [] hidp_session_thread+0x110/0x568 [hidp]
...
[ 40.159664] Call trace:
[ 40.162122] [] __might_sleep+0x64/0x90
[ 40.167443] [] lock_sock_nested+0x30/0x78
[ 40.173047] [] l2cap_sock_sendmsg+0x90/0xf0
[bluetooth]
[ 40.179842] [] sock_sendmsg+0x4c/0x68
[ 40.185072] [] kernel_sendmsg+0x54/0x68
[ 40.190477] [] hidp_send_frame+0x78/0xa0 [hidp]
[ 40.196574] [] hidp_process_transmit+0x44/0x98
[hidp]
[ 40.203191] [] hidp_session_thread+0x364/0x568
[hidp]
Following (https://lwn.net/Articles/628628/).
Signed-off-by: Jeffy Chen
---
net/bluetooth/hidp/core.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/net/bluetooth/hidp/core.c b/net/bluetooth/hidp/core.c
index 0bec458..bfd3fb8 100644
--- a/net/bluetooth/hidp/core.c
+++ b/net/bluetooth/hidp/core.c
@@ -1180,7 +1180,9 @@ static void hidp_session_run(struct hidp_session *session)
struct sock *ctrl_sk = session->ctrl_sock->sk;
struct sock *intr_sk = session->intr_sock->sk;
struct sk_buff *skb;
+ DEFINE_WAIT_FUNC(wait, woken_wake_function);
+ add_wait_queue(sk_sleep(intr_sk), &wait);
for (;;) {
/*
* This thread can be woken up two ways:
@@ -1188,12 +1190,10 @@ static void hidp_session_run(struct hidp_session
*session)
*session->terminate flag and wakes this thread up.
* - Via modifying the socket state of ctrl/intr_sock. This
*thread is woken up by ->sk_state_changed().
-*
-* Note: set_current_state() performs any necessary
-* memory-barriers for us.
*/
- set_current_state(TASK_INTERRUPTIBLE);
+ /* Ensure session->terminate is updated */
+ smp_mb__before_atomic();
if (atomic_read(&session->terminate))
break;
@@ -1227,11 +1227,14 @@ static void hidp_session_run(struct hidp_session
*session)
hidp_process_transmit(session, &session->ctrl_transmit,
session->ctrl_sock);
- schedule();
+ wait_woken(&wait, TASK_INTERRUPTIBLE, MAX_SCHEDULE_TIMEOUT);
}
+ remove_wait_queue(sk_sleep(intr_sk), &wait);
atomic_inc(&session->terminate);
- set_current_state(TASK_RUNNING);
+
+ /* Ensure session->terminate is updated */
+ smp_mb__after_atomic();
}
/*
--
2.1.4
[PATCH net-next] gre6: Clean up unused struct ipv6_tel_txoption definition
Commit b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE
functions") removed the ip6gre specific transmit function, but left the
struct ipv6_tel_txoption definition. Clean it up.
Signed-off-by: Jakub Sitnicki
---
net/ipv6/ip6_gre.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 75b6108..65bdfd1 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -484,11 +484,6 @@ static int gre_rcv(struct sk_buff *skb)
return 0;
}
-struct ipv6_tel_txoption {
- struct ipv6_txoptions ops;
- __u8 dst_opt[8];
-};
-
static int gre_handle_offloads(struct sk_buff *skb, bool csum)
{
return iptunnel_handle_offloads(skb,
--
2.7.4
Re: [PATCH 5/6] treewide: use kv[mz]alloc* rather than opencoded variants
On 01/12/2017 06:37 PM, Michal Hocko wrote: > On Thu 12-01-17 09:26:09, Kees Cook wrote: >> On Thu, Jan 12, 2017 at 7:37 AM, Michal Hocko wrote: > [...] >>> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c >>> index 4f74511015b8..e6bbb33d2956 100644 >>> --- a/arch/s390/kvm/kvm-s390.c >>> +++ b/arch/s390/kvm/kvm-s390.c >>> @@ -1126,10 +1126,7 @@ static long kvm_s390_get_skeys(struct kvm *kvm, >>> struct kvm_s390_skeys *args) >>> if (args->count < 1 || args->count > KVM_S390_SKEYS_MAX) >>> return -EINVAL; >>> >>> - keys = kmalloc_array(args->count, sizeof(uint8_t), >>> -GFP_KERNEL | __GFP_NOWARN); >>> - if (!keys) >>> - keys = vmalloc(sizeof(uint8_t) * args->count); >>> + keys = kvmalloc(args->count * sizeof(uint8_t), GFP_KERNEL); >> >> Before doing this conversion, can we add a kvmalloc_array() API? This >> conversion could allow for the reintroduction of integer overflow >> flaws. (This particular situation isn't at risk since ->count is >> checked, but I'd prefer we not create a risky set of examples for >> using kvmalloc.) > > Well, I am not opposed to kvmalloc_array but I would argue that this > conversion cannot introduce new overflow issues. The code would have > to be broken already because even though kmalloc_array checks for the > overflow but vmalloc fallback doesn't... Yeah I agree, but if some of the places were really wrong, after the conversion we won't see them anymore. > If there is a general interest for this API I can add it. I think it would be better, yes.
Re: [PATCH net-next v4 2/2] net: stmmac: dwmac-meson8b: make the RGMII TX delay configurable
Hi David, On Sun, Dec 18, 2016 at 5:13 PM, Martin Blumenstingl wrote: > On Sun, Dec 18, 2016 at 4:49 PM, David Miller wrote: >> From: Martin Blumenstingl >> Date: Sat, 17 Dec 2016 19:21:19 +0100 >> >>> Prior to this patch we were using a hardcoded RGMII TX clock delay of >>> 2ns (= 1/4 cycle of the 125MHz RGMII TX clock). This value works for >>> many boards, but unfortunately not for all (due to the way the actual >>> circuit is designed, sometimes because the TX delay is enabled in the >>> PHY, etc.). Making the TX delay on the MAC side configurable allows us >>> to support all possible hardware combinations. >>> >>> This allows fixing a compatibility issue on some boards, where the >>> RTL8211F PHY is configured to generate the TX delay. We can now turn >>> off the TX delay in the MAC, because otherwise we would be applying the >>> delay twice (which results in non-working TX traffic). >>> >>> Signed-off-by: Martin Blumenstingl >>> Tested-by: Neil Armstrong >> >> Is this really the safest thing to do? >> >> If you say the existing hard-coded setting of 1/4 cycle works on most >> boards, and what you're trying to do is override it with an OF >> property value for boards where the existing setting does not work, >> then you _must_ use a default value that corresponds to what the >> existing code does not when you don't see this new OF property. > it's a bit more complicated in reality: 1/4 cycle works when the TX > delay of the RTL8211F PHY is turned off (until recently it was always > enabled for phy-mode RGMII). > >> So please retain the current behavior of the 1/4 cycle TX delay >> setting when you don't see the amlogic,tx-delay-ns property. >> >> I really think you risk breaking existing boards by not doing so, >> unless you can have this patch tested on every such board that exists >> and I don't think you really can feasibly and rigorously do that. > there's a patch in my follow-up series which adds the 2ns to the .dts > for all RGMII based boards: [0] (and I would keep these even if we had > a default value, just to make it explicit and thus easier to > understand for other people). > however, we can add the 2ns default back (I can do this if you want - > Rob Herring was unhappy with the missing documentation of this default > value [1] - so note to myself: take care of that as well). but then we > have to decide when to apply this default value: only when we're in > RGMII mode or also in any of the RGMII_*ID modes? could you please let me know if I should add a a fallback (2ns which was the old hardcoded value) to the driver or if I should simply leave it out (that's the way it is right now). I'm fine with either way, I would just like to avoid duplicate work. So please let me know how you prefer it. Regards, Martin
Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
On Fri, Jan 20, 2017 at 01:45:42PM +, Colin King wrote:
> From: Colin Ian King
>
> Table sctp_timer_tbl is missing a TIMEOUT_RECONF string so
> add this in. Also compare timeout with the size of the array
> sctp_timer_tbl rather than SCTP_EVENT_TIMEOUT_MAX. Also add
> a build time check that SCTP_EVENT_TIMEOUT_MAX is correct
> so we don't ever get this kind of mismatch between the table
> and SCTP_EVENT_TIMEOUT_MAX in the future.
>
> Kudos to Marcel Ricardo Leitner for spotting the missing string
> and suggesting the build time sanity check.
>
> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> Signed-off-by: Colin Ian King
Not sure I can add the Fixes tag for you here, but:
Fixes: 7b9438de0cd4 ("sctp: add stream reconf timer")
Acked-by: Marcelo Ricardo Leitner
Thanks
> ---
> net/sctp/debug.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/net/sctp/debug.c b/net/sctp/debug.c
> index 95d7b15..2e47eb2 100644
> --- a/net/sctp/debug.c
> +++ b/net/sctp/debug.c
> @@ -159,6 +159,7 @@ static const char *const sctp_timer_tbl[] = {
> "TIMEOUT_T4_RTO",
> "TIMEOUT_T5_SHUTDOWN_GUARD",
> "TIMEOUT_HEARTBEAT",
> + "TIMEOUT_RECONF",
> "TIMEOUT_SACK",
> "TIMEOUT_AUTOCLOSE",
> };
> @@ -166,7 +167,9 @@ static const char *const sctp_timer_tbl[] = {
> /* Lookup timer debug name. */
> const char *sctp_tname(const sctp_subtype_t id)
> {
> - if (id.timeout <= SCTP_EVENT_TIMEOUT_MAX)
> + BUILD_BUG_ON(SCTP_EVENT_TIMEOUT_MAX + 1 != ARRAY_SIZE(sctp_timer_tbl));
> +
> + if (id.timeout < ARRAY_SIZE(sctp_timer_tbl))
> return sctp_timer_tbl[id.timeout];
> return "unknown_timer";
> }
> --
> 2.10.2
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Re: [PATCH iproute2 net-next] ipmroute: add support for RTNH_F_UNRESOLVED
On 20/01/17 15:04, Nikolay Aleksandrov wrote: > This patch adds a new field that is printed in the end of the line which > denotes the real entry state. Before this patch an entry's IIF could > disappear and it would look like an unresolved one (iif = unresolved): > (3.0.16.1, 225.11.16.1) Iif: unresolved > with no way to really distinguish it from an unresolved entry. > After the patch if the dumped entry has RTNH_F_UNRESOLVED set we get: > (3.0.16.1, 225.11.16.1) Iif: unresolved State: unresolved > for unresolved entries and: > (0.0.0.0, 225.11.11.11) Iif: eth4 Oifs: eth3 State: resolved > for resolved entries after the OIF list. Note that "State:" has ':' in > it so it cannot be mistaken for an interface name. > And for the example above, we'd get: > (0.0.0.0, 225.11.11.11) Iif: unresolved State: resolved > > Also when dumping all routes via ip route show table all, it will show > up as: > multicast 225.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved > > Signed-off-by: Nikolay Aleksandrov > --- > ip/ipmroute.c | 6 ++ > ip/iproute.c | 2 ++ > 2 files changed, 8 insertions(+) > Oops, sent the wrong version. v2 coming up, sorry for the noise
Re: [PATCH net] net: mpls: Fix multipath selection for LSR use case
On 20/01/17 00:51, David Ahern wrote:
MPLS multipath for LSR is broken -- always selecting the first nexthop
in the one label case. For example:
$ ip netns exec ns1 ip -f mpls ro ls
100
nexthop as to 200 via inet 172.16.2.2 dev virt12
nexthop as to 300 via inet 172.16.3.2 dev virt13
101
nexthop as to 201 via inet6 2000:2::2 dev virt12
nexthop as to 301 via inet6 2000:3::2 dev virt13
In this example incoming packets have a single MPLS labels which means
BOS bit is set. The BOS bit is passed from mpls_forward down to
mpls_multipath_hash which never processes the hash loop because BOS is 1.
Removing the bos arg from mpls_multipath_hash uncovers a number of other
problems with the hash loop that processes the MPLS label stack -- from
incorrect assumptions on the skb (skb has already pulled the first mpls
label in mpls_forward yet loop assumes it is there)
This was intentional because it doesn't really add anything to include
the top-most label in the entropy since all traffic for the mpls_route
will have the same top-most label, until support for sharing of
mpls_routes is added.
Having said that, it costs very little to do this, makes the code
simpler and avoids the need to remember to change this if sharing is
added, so it's fine with me.
to incorrect
pskb_may_pull checks (label_index starts at 0 and pskb_may_pull checks
all use sizeof() * label_index).
This patch addresses all problems by moving the skb_pull in mpls_forward
after mpls_select_multipath. This allows mpls_multipath_hash to see the
skb with the entire label stack as it arrived.
From there mpls_multipath_hash is modified to additively compute the
total mpls header length on each pass (on pass N mpls_hdr_len is
N * sizeof(mpls_shim_hdr)). When the label is found with the BOS set it
verifies the skb has sufficient header for ipv4 or ipv6, and find the
IPv4 and IPv6 header by using the last mpls_hdr pointer and adding 1 to
advance past it.
With these changes I have verified the code correctly sees the label,
BOS, IPv4 and IPv6 addresses in the network header and icmp/tcp/udp
traffic for ipv4 and ipv6 are distributed across the nexthops.
Fixes: 1c78efa8319ca ("mpls: flow-based multipath selection")
Signed-off-by: David Ahern
Acked-by: Robert Shearman
Good catch, thanks for fixing.
[PATCH iproute2 net-next] ipmroute: add support for RTNH_F_UNRESOLVED
This patch adds a new field that is printed in the end of the line which
denotes the real entry state. Before this patch an entry's IIF could
disappear and it would look like an unresolved one (iif = unresolved):
(3.0.16.1, 225.11.16.1) Iif: unresolved
with no way to really distinguish it from an unresolved entry.
After the patch if the dumped entry has RTNH_F_UNRESOLVED set we get:
(3.0.16.1, 225.11.16.1) Iif: unresolved State: unresolved
for unresolved entries and:
(0.0.0.0, 225.11.11.11) Iif: eth4 Oifs: eth3 State: resolved
for resolved entries after the OIF list. Note that "State:" has ':' in
it so it cannot be mistaken for an interface name.
And for the example above, we'd get:
(0.0.0.0, 225.11.11.11) Iif: unresolved State: resolved
Also when dumping all routes via ip route show table all, it will show
up as:
multicast 225.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved
Signed-off-by: Nikolay Aleksandrov
---
ip/ipmroute.c | 6 ++
ip/iproute.c | 2 ++
2 files changed, 8 insertions(+)
diff --git a/ip/ipmroute.c b/ip/ipmroute.c
index 512afcd2086e..913f3fd28e14 100644
--- a/ip/ipmroute.c
+++ b/ip/ipmroute.c
@@ -159,6 +159,12 @@ int print_mroute(const struct sockaddr_nl *who, struct
nlmsghdr *n, void *arg)
nh = RTNH_NEXT(nh);
}
}
+ fprintf(fp, " State: ");
+ if (r->rtm_flags & RTNH_F_UNRESOLVED)
+ fprintf(fp, "unresolved");
+ else
+ fprintf(fp, "resolved");
+
if (show_stats && tb[RTA_MFC_STATS]) {
struct rta_mfc_stats *mfcs = RTA_DATA(tb[RTA_MFC_STATS]);
diff --git a/ip/iproute.c b/ip/iproute.c
index e433de8be189..c19578337f71 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -448,6 +448,8 @@ int print_route(const struct sockaddr_nl *who, struct
nlmsghdr *n, void *arg)
fprintf(fp, "notify ");
if (r->rtm_flags & RTNH_F_LINKDOWN)
fprintf(fp, "linkdown ");
+ if (r->rtm_flags & RTNH_F_UNRESOLVED)
+ fprintf(fp, "unresolved ");
if (tb[RTA_MARK]) {
unsigned int mark = *(unsigned int *)RTA_DATA(tb[RTA_MARK]);
--
2.1.4
RE: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
> On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote: > > -Realtek 8192CE chipset maintains local irq flags after enabling/disabling > > hardware interrupts. > > -Hardware interrupts are enabled before enabling the local irq > > flags(these flags are being checked in interrupt handler), > > leading to race condition on some RP, where the irq line between > > bridge and GIC goes high at ASSERT_INTx and goes low only > > at DEASSERT_INTx. In this kind of RP by the time ASSERT_INTx is seen > > irq_enable flag is still set to false, resulting in continuous > > interrupts seen by CPU as DEASSERT_INTx cannot be sent since > > flag is still false and making CPU stall. > > -Changing the sequence of setting these irq flags. > > > > Signed-off-by: Bharat Kumar Gogada > > --- > > This patch should be enhanced with the smb_xx() calls as suggested by by Lino. > > The subject should be changed. I would suggest something like "rtlwifi: > rtl8192ce: Prevent race condition when enabling interrupts", as it explains > the > condition you are preventing. > > The other PCI drivers also have the same problem. Do you want to prepare the > patches, or should I do it? > Thanks Larry. Please send out the patches adding the above enhancements suggested by Lino. Bharat
Re: [PATCH] net: phy: micrel: add KSZ8795 ethernet switch
On Fri, Jan 20, 2017 at 01:50:49PM +0100, Sean Nyekjaer wrote: > This ethernet switch have unfortunately the same phy id as KSZ8051. Hi Sean Please could you explain some more. You are adding PHY support here, not switch support. So is this to enable the PHY driver for the PHYs embedded in the switch? Andrew
[PATCH iproute2 net-next v2] ipmroute: add support for RTNH_F_UNRESOLVED
This patch adds a new field that is printed in the end of the line which
denotes the real entry state. Before this patch an entry's IIF could
disappear and it would look like an unresolved one (iif = unresolved):
(3.0.16.1, 225.11.16.1) Iif: unresolved
with no way to really distinguish it from an unresolved entry.
After the patch if the dumped entry has RTNH_F_UNRESOLVED set we get:
(3.0.16.1, 225.11.16.1) Iif: unresolved State: unresolved
for unresolved entries and:
(0.0.0.0, 225.11.11.11) Iif: eth4 Oifs: eth3 State: resolved
for resolved entries after the OIF list. Note that "State:" has ':' in
it so it cannot be mistaken for an interface name.
And for the example above, we'd get:
(0.0.0.0, 225.11.11.11) Iif: unresolved State: resolved
Also when dumping all routes via ip route show table all, it will show
up as:
multicast 225.11.16.1/32 from 3.0.16.1/32 table default proto 17 unresolved
Signed-off-by: Nikolay Aleksandrov
---
v2: sent latest version, with dumping the state in one line
ip/ipmroute.c | 2 ++
ip/iproute.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/ip/ipmroute.c b/ip/ipmroute.c
index 512afcd2086e..593ce3a1bd95 100644
--- a/ip/ipmroute.c
+++ b/ip/ipmroute.c
@@ -159,6 +159,8 @@ int print_mroute(const struct sockaddr_nl *who, struct
nlmsghdr *n, void *arg)
nh = RTNH_NEXT(nh);
}
}
+ fprintf(fp, " State: %s",
+ r->rtm_flags & RTNH_F_UNRESOLVED ? "unresolved" : "resolved");
if (show_stats && tb[RTA_MFC_STATS]) {
struct rta_mfc_stats *mfcs = RTA_DATA(tb[RTA_MFC_STATS]);
diff --git a/ip/iproute.c b/ip/iproute.c
index e433de8be189..c19578337f71 100644
--- a/ip/iproute.c
+++ b/ip/iproute.c
@@ -448,6 +448,8 @@ int print_route(const struct sockaddr_nl *who, struct
nlmsghdr *n, void *arg)
fprintf(fp, "notify ");
if (r->rtm_flags & RTNH_F_LINKDOWN)
fprintf(fp, "linkdown ");
+ if (r->rtm_flags & RTNH_F_UNRESOLVED)
+ fprintf(fp, "unresolved ");
if (tb[RTA_MARK]) {
unsigned int mark = *(unsigned int *)RTA_DATA(tb[RTA_MARK]);
--
2.1.4
[PATCH] sock: use hlist_entry_safe
Use hlist_entry_safe() instead of open-coding it.
Signed-off-by: Geliang Tang
---
include/net/sock.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/net/sock.h b/include/net/sock.h
index 4077ec4..c4e1caf1 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -544,8 +544,7 @@ static inline struct sock *sk_nulls_head(const struct
hlist_nulls_head *head)
static inline struct sock *sk_next(const struct sock *sk)
{
- return sk->sk_node.next ?
- hlist_entry(sk->sk_node.next, struct sock, sk_node) : NULL;
+ return hlist_entry_safe(sk->sk_node.next, struct sock, sk_node);
}
static inline struct sock *sk_nulls_next(const struct sock *sk)
--
2.9.3
Re: [PATCH v7 11/13] net: ethernet: aquantia: Ethtool support
+1 Many times this information is needed, and "ethtool -i" is a convenient way to get it. Rami Rosen
[PATCH] 6lowpan: use rb_entry()
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
net/6lowpan/nhc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/6lowpan/nhc.c b/net/6lowpan/nhc.c
index 7008d53..4fa2fdd 100644
--- a/net/6lowpan/nhc.c
+++ b/net/6lowpan/nhc.c
@@ -27,8 +27,8 @@ static int lowpan_nhc_insert(struct lowpan_nhc *nhc)
/* Figure out where to put new node */
while (*new) {
- struct lowpan_nhc *this = container_of(*new, struct lowpan_nhc,
- node);
+ struct lowpan_nhc *this = rb_entry(*new, struct lowpan_nhc,
+ node);
int result, len_dif, len;
len_dif = nhc->idlen - this->idlen;
@@ -69,8 +69,8 @@ static struct lowpan_nhc *lowpan_nhc_by_nhcid(const struct
sk_buff *skb)
const u8 *nhcid_skb_ptr = skb->data;
while (node) {
- struct lowpan_nhc *nhc = container_of(node, struct lowpan_nhc,
- node);
+ struct lowpan_nhc *nhc = rb_entry(node, struct lowpan_nhc,
+ node);
u8 nhcid_skb_ptr_masked[LOWPAN_NHC_MAX_ID_LEN];
int result, i;
--
2.9.3
[PATCH] net/mlx4: use rb_entry()
To make the code clearer, use rb_entry() instead of container_of() to
deal with rbtree.
Signed-off-by: Geliang Tang
---
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
index 1822382..6da6e01 100644
--- a/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
+++ b/drivers/net/ethernet/mellanox/mlx4/resource_tracker.c
@@ -236,8 +236,8 @@ static void *res_tracker_lookup(struct rb_root *root, u64
res_id)
struct rb_node *node = root->rb_node;
while (node) {
- struct res_common *res = container_of(node, struct res_common,
- node);
+ struct res_common *res = rb_entry(node, struct res_common,
+ node);
if (res_id < res->res_id)
node = node->rb_left;
@@ -255,8 +255,8 @@ static int res_tracker_insert(struct rb_root *root, struct
res_common *res)
/* Figure out where to put new node */
while (*new) {
- struct res_common *this = container_of(*new, struct res_common,
- node);
+ struct res_common *this = rb_entry(*new, struct res_common,
+ node);
parent = *new;
if (res->res_id < this->res_id)
--
2.9.3
RE: [PATCHv3 net-next 3/4] sctp: add support for generating stream reconf add incoming/outgoing streams request chunk
From: Xin Long
> Sent: 19 January 2017 17:19
> This patch is to define Add Incoming/Outgoing Streams Request
> Parameter described in rfc6525 section 4.5 and 4.6. They can
> be in one same chunk trunk as rfc6525 section 3.1-7 describes,
> so make them in one function.
...
> +struct sctp_strreset_addstrm {
> + sctp_paramhdr_t param_hdr;
> + __u32 request_seq;
> + __u16 number_of_streams;
> + __u16 reserved;
> +} __packed;
...
> + addstrm.param_hdr.type = SCTP_PARAM_RESET_ADD_OUT_STREAMS;
> + addstrm.param_hdr.length = htons(size);
> + addstrm.number_of_streams = htons(out);
> + addstrm.request_seq = htonl(asoc->strreset_outseq);
> + addstrm.reserved = 0;
> +
> + sctp_addto_chunk(retval, size, &addstrm);
Since you allocate the sctp_strreset_addstrm structure on stack
there is no requirement for it to be packed.
David
Re: [PATCH] inet: don't use sk_v6_rcv_saddr directly
On Thu, Jan 19, 2017 at 5:47 PM, Josef Bacik wrote:
When comparing two sockets we need to use inet6_rcv_saddr so we get a
NULL
sk_v6_rcv_saddr if the socket isn't AF_INET6, otherwise our
comparison function
can be wrong.
Fixes: 637bc8b ("inet: reset tb->fastreuseport when adding a
reuseport sk")
Signed-off-by: Josef Bacik
---
net/ipv4/inet_connection_sock.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/inet_connection_sock.c
b/net/ipv4/inet_connection_sock.c
index 096a085..a336c42 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -99,7 +99,7 @@ int inet_rcv_saddr_equal(const struct sock *sk,
const struct sock *sk2,
#if IS_ENABLED(CONFIG_IPV6)
if (sk->sk_family == AF_INET6)
return ipv6_rcv_saddr_equal(&sk->sk_v6_rcv_saddr,
- &sk2->sk_v6_rcv_saddr,
+ inet6_rcv_saddr(sk2),
sk->sk_rcv_saddr,
sk2->sk_rcv_saddr,
ipv6_only_sock(sk),
--
2.5.5
Sorry I forgot to tag this, it's for net-next. Thanks,
Josef
Re: [PATCH 2/2] at803x: double check SGMII side autoneg
On 01/20/2017 03:38 AM, Timur Tabi wrote:
> Zefir Kurtisi wrote:
>> It always operates at 675MHz, which with two lines gives 1.25Gbps,
>> which at 10/8 coding gives exactly 1Gbps net data rate. If the
>> at803x's copper side autonegotiates to 1Gbps, the bits traversing
>> over the SGMII match the copper side 1:1. In case the copper side
>> autonegotiates to e.g. 100Mbps, each bit at the copper side on the
>> SGMII bus is replicated and sent 10x times - or 100x times in case of
>> 10Mbps. The MAC side of the ETH needs to be aware of how the SGMII
>> data has to be interpreted, and this is why you have to set the bits
>> you are referring to.
>
> So does this mean that the SGMII link should not be autonegotiated? I
> currently
> have this code:
>
> if (phydev->autoneg == AUTONEG_ENABLE) {
> val &= ~(FORCE_AN_RX_CFG | FORCE_AN_TX_CFG);
> val |= AN_ENABLE;
> writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
> } else {
> ...
>
> So if the external PHY is set to autonegotiate, then the SGMII block is set to
> also negotiate. Now that I think about it, this seems wrong. And in fact,
> I'm not
> sure how it works. It seems that the this only makes sense if the SGMII
> block is
> configured to act as the only PHY. This is an option that the hardware
> supports
> but my driver does not. So perhaps I should remove this part, and just do
> the rest:
>
>
> u32 speed_cfg;
>
> switch (phydev->speed) {
> case SPEED_10:
> speed_cfg = SPDMODE_10;
> break;
> case SPEED_100:
> speed_cfg = SPDMODE_100;
> break;
> case SPEED_1000:
> speed_cfg = SPDMODE_1000;
> break;
> default:
> return -EINVAL;
> }
>
> if (phydev->duplex == DUPLEX_FULL)
> speed_cfg |= DUPLEX_MODE;
>
> val &= ~AN_ENABLE;
> writel(speed_cfg, phy->base + EMAC_SGMII_PHY_SPEED_CFG1);
> writel(val, phy->base + EMAC_SGMII_PHY_AUTONEG_CFG2);
>
> Should I be doing this all the time?
>
Hm, that might be product dependent. From my experience with the gianfar/at8031
this is what I can share: there is a known flaw in some revisions of the eTSEC
that causes random failures in SGMII autonegotiation. As a workaround FSL
proposes
to use fixed speed. I spent lots of time getting this working, but in the end it
turned out it does not. Setting fixed Gbps speed on both ends of the link is
reported to be ok (link failure bits clean, page transmitted ok), but no data
goes
through the link.
>From a source I can't remember atm I was told that autonegotiation is mandatory
for SGMII, therefore I believe there is no need to change the autoneg bits for
SGMII in your case. I'd assume that resetting the link before setting the speed
value should be enough, i.e. the second write to EMAC_SGMII_PHY_AUTONEG_CFG2
might
be useless. YMMV
>> To track down who is causing the additional message, I would proceed
>> with following technique that helped me dig down a similar problem:
>> since you control the events in question and there is no risk of
>> flooding the kernel log, in the top of phy.c::phy_print_status() add
>> a dump_stack() call. In the debug log ensure that all of the traces
>> end up in the same phydev->adjust_link() callback handler (in your
>> case emac_adjust_link()).
>
> That's a good idea, thanks.
>
As Florian responded, it seems you need to double check for real changes before
printing the link status to get rid of the double printed notifications.
Good Luck.
Re: [PATCH] stmmac: adding EEE to GMAC4
Hi Rayagond,
Às 6:01 AM de 1/19/2017, Rayagond Kokatanur escreveu:
> On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto wrote:
>> This patch adds Energy Efficiency Ethernet to GMAC4.
>>
>> Signed-off-by: Joao Pinto
>> ---
>> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 12 +
>> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59
>> +++
>> 2 files changed, 71 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> index b524598..73d1dab 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> @@ -90,6 +90,18 @@ enum power_event {
>> power_down = 0x0001,
>> };
>>
>> +/* Energy Efficient Ethernet (EEE) for GMAC4
>> + *
>> + * LPI status, timer and control register offset
>> + */
>> +#define GMAC4_LPI_CTRL_STATUS 0xd0
>> +#define GMAC4_LPI_TIMER_CTRL 0xd4
>> +
>> +/* LPI control and status defines */
>> +#define GMAC4_LPI_CTRL_STATUS_LPITXA BIT(19) /* Enable LPI TX Automate */
>> +#define GMAC4_LPI_CTRL_STATUS_PLS BIT(17) /* PHY Link Status */
>> +#define GMAC4_LPI_CTRL_STATUS_LPIENBIT(16) /* LPI Enable */
>> +
>> /* MAC Debug bitmap */
>> #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>> #define GMAC_DEBUG_TFCSTS_SHIFT17
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> index ecfbf57..02eab79 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info
>> *hw,
>>GMAC_ADDR_LOW(reg_n));
>> }
>>
>> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + /* Enable the link status receive on RGMII, SGMII ore SMII
>> +* receive path and instruct the transmit to enter in LPI
>> +* state.
>> +*/
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN |
>> GMAC4_LPI_CTRL_STATUS_LPITXA);
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +
>> + if (link)
>> + value |= GMAC4_LPI_CTRL_STATUS_PLS;
>> + else
>> + value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + int value = ((tw & 0x)) | ((ls & 0x7ff) << 16);
>
> If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
> should AND 0x3ff.
>
> int value = ((tw & 0x)) | ((ls & 0x3ff) << 16);
You are absolutely right. LS is related to 25:16 (10 bits).
Thank you for checking it!
Joao
>
>> +
>> + /* Program the timers in the LPI timer control register:
>> +* LS: minimum time (ms) for which the link
>> +* status from PHY should be ok before transmitting
>> +* the LPI pattern.
>> +* TW: minimum time (us) for which the core waits
>> +* after it has stopped transmitting the LPI pattern.
>> +*/
>> + writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
>> +}
>> +
>> static void dwmac4_set_filter(struct mac_device_info *hw,
>> struct net_device *dev)
>> {
>> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
>> .pmt = dwmac4_pmt,
>> .set_umac_addr = dwmac4_set_umac_addr,
>> .get_umac_addr = dwmac4_get_umac_addr,
>> + .set_eee_mode = dwmac4_set_eee_mode,
>> + .reset_eee_mode = dwmac4_reset_eee_mode,
>> + .set_eee_timer = dwmac4_set_eee_timer,
>> + .set_eee_pls = dwmac4_set_eee_pls,
>> .pcs_ctrl_ane = dwmac4_ctrl_ane,
>> .pcs_rane = dwmac4_rane,
>> .pcs_get_adv_lp = dwmac4_get_adv_lp,
>> --
>> 2.9.3
>>
>
>
>
[PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
From: Eric Dumazet
seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
possibly NULL, so we must check kmemdup() return value and abort if
it is NULL
Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of
SR-IPv6")
Signed-off-by: Eric Dumazet
Cc: David Lebrun
---
net/ipv6/seg6.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
index
b172d85c650a376f541ea05d72046c76b8404303..a855eb325b030a666fe92c56a2d432c77d9dfe7a
100644
--- a/net/ipv6/seg6.c
+++ b/net/ipv6/seg6.c
@@ -176,6 +176,8 @@ static int seg6_genl_set_tunsrc(struct sk_buff *skb, struct
genl_info *info)
val = nla_data(info->attrs[SEG6_ATTR_DST]);
t_new = kmemdup(val, sizeof(*val), GFP_KERNEL);
+ if (!t_new)
+ return -ENOMEM;
mutex_lock(&sdata->lock);
Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving
From: Jason Wang
Date: Fri, 20 Jan 2017 14:32:42 +0800
> Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
> xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
> fixing this by adding a hint (has_data_valid) and set it only on the
> receiving path.
>
> Cc: Rolf Neugebauer
> Signed-off-by: Jason Wang
Applied, thanks Jason.
Re: [PATCH] stmmac: adding EEE to GMAC4
Sorry, please ignore, wrong patch file.
Joao Pinto
Às 6:01 AM de 1/19/2017, Rayagond Kokatanur escreveu:
> On Thu, Dec 29, 2016 at 10:40 PM, Joao Pinto wrote:
>> This patch adds Energy Efficiency Ethernet to GMAC4.
>>
>> Signed-off-by: Joao Pinto
>> ---
>> drivers/net/ethernet/stmicro/stmmac/dwmac4.h | 12 +
>> drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 59
>> +++
>> 2 files changed, 71 insertions(+)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> index b524598..73d1dab 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
>> @@ -90,6 +90,18 @@ enum power_event {
>> power_down = 0x0001,
>> };
>>
>> +/* Energy Efficient Ethernet (EEE) for GMAC4
>> + *
>> + * LPI status, timer and control register offset
>> + */
>> +#define GMAC4_LPI_CTRL_STATUS 0xd0
>> +#define GMAC4_LPI_TIMER_CTRL 0xd4
>> +
>> +/* LPI control and status defines */
>> +#define GMAC4_LPI_CTRL_STATUS_LPITXA BIT(19) /* Enable LPI TX Automate */
>> +#define GMAC4_LPI_CTRL_STATUS_PLS BIT(17) /* PHY Link Status */
>> +#define GMAC4_LPI_CTRL_STATUS_LPIENBIT(16) /* LPI Enable */
>> +
>> /* MAC Debug bitmap */
>> #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
>> #define GMAC_DEBUG_TFCSTS_SHIFT17
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> index ecfbf57..02eab79 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
>> @@ -137,6 +137,61 @@ static void dwmac4_get_umac_addr(struct mac_device_info
>> *hw,
>>GMAC_ADDR_LOW(reg_n));
>> }
>>
>> +static void dwmac4_set_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + /* Enable the link status receive on RGMII, SGMII ore SMII
>> +* receive path and instruct the transmit to enter in LPI
>> +* state.
>> +*/
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value |= GMAC4_LPI_CTRL_STATUS_LPIEN | GMAC4_LPI_CTRL_STATUS_LPITXA;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_reset_eee_mode(struct mac_device_info *hw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> + value &= ~(GMAC4_LPI_CTRL_STATUS_LPIEN |
>> GMAC4_LPI_CTRL_STATUS_LPITXA);
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_pls(struct mac_device_info *hw, int link)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + u32 value;
>> +
>> + value = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +
>> + if (link)
>> + value |= GMAC4_LPI_CTRL_STATUS_PLS;
>> + else
>> + value &= ~GMAC4_LPI_CTRL_STATUS_PLS;
>> +
>> + writel(value, ioaddr + GMAC4_LPI_CTRL_STATUS);
>> +}
>> +
>> +static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
>> +{
>> + void __iomem *ioaddr = hw->pcsr;
>> + int value = ((tw & 0x)) | ((ls & 0x7ff) << 16);
>
> If I am not wrong, LS field is 10 bits wide not 11 bits, hence we
> should AND 0x3ff.
>
> int value = ((tw & 0x)) | ((ls & 0x3ff) << 16);
>
>> +
>> + /* Program the timers in the LPI timer control register:
>> +* LS: minimum time (ms) for which the link
>> +* status from PHY should be ok before transmitting
>> +* the LPI pattern.
>> +* TW: minimum time (us) for which the core waits
>> +* after it has stopped transmitting the LPI pattern.
>> +*/
>> + writel(value, ioaddr + GMAC4_LPI_TIMER_CTRL);
>> +}
>> +
>> static void dwmac4_set_filter(struct mac_device_info *hw,
>> struct net_device *dev)
>> {
>> @@ -410,6 +465,10 @@ static const struct stmmac_ops dwmac4_ops = {
>> .pmt = dwmac4_pmt,
>> .set_umac_addr = dwmac4_set_umac_addr,
>> .get_umac_addr = dwmac4_get_umac_addr,
>> + .set_eee_mode = dwmac4_set_eee_mode,
>> + .reset_eee_mode = dwmac4_reset_eee_mode,
>> + .set_eee_timer = dwmac4_set_eee_timer,
>> + .set_eee_pls = dwmac4_set_eee_pls,
>> .pcs_ctrl_ane = dwmac4_ctrl_ane,
>> .pcs_rane = dwmac4_rane,
>> .pcs_get_adv_lp = dwmac4_get_adv_lp,
>> --
>> 2.9.3
>>
>
>
>
Re: [PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
On 01/20/2017 04:57 PM, Eric Dumazet wrote:
> From: Eric Dumazet
>
> seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
> possibly NULL, so we must check kmemdup() return value and abort if
> it is NULL
>
> Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of
> SR-IPv6")
> Signed-off-by: Eric Dumazet
> Cc: David Lebrun
> ---
> net/ipv6/seg6.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
> index
> b172d85c650a376f541ea05d72046c76b8404303..a855eb325b030a666fe92c56a2d432c77d9dfe7a
> 100644
> --- a/net/ipv6/seg6.c
> +++ b/net/ipv6/seg6.c
> @@ -176,6 +176,8 @@ static int seg6_genl_set_tunsrc(struct sk_buff *skb,
> struct genl_info *info)
>
> val = nla_data(info->attrs[SEG6_ATTR_DST]);
> t_new = kmemdup(val, sizeof(*val), GFP_KERNEL);
> + if (!t_new)
> + return -ENOMEM;
>
> mutex_lock(&sdata->lock);
>
>
>
Thanks :)
Acked-by: David Lebrun
signature.asc
Description: OpenPGP digital signature
Re: [PATCH net] r8152: fix rtl8152_post_reset function
From: Hayes Wang Date: Fri, 20 Jan 2017 14:33:55 +0800 > The rtl8152_post_reset() should sumbit rx urb and interrupt transfer, > otherwise the rx wouldn't work and the linking change couldn't be > detected. > > Signed-off-by: Hayes Wang Applied, thank you.
[PATCH net-next] ipv6: add NUMA awareness to seg6_hmac_init_algo()
From: Eric Dumazet
Since we allocate per cpu storage, let's also use NUMA hints.
Signed-off-by: Eric Dumazet
---
net/ipv6/seg6_hmac.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/seg6_hmac.c b/net/ipv6/seg6_hmac.c
index
5215e1eba01030dc9345b847eee5ac5ef3bed1b9..b274f1d95e037c93e8e0e6531cfc51709f71297c
100644
--- a/net/ipv6/seg6_hmac.c
+++ b/net/ipv6/seg6_hmac.c
@@ -389,7 +389,8 @@ static int seg6_hmac_init_algo(void)
return -ENOMEM;
for_each_possible_cpu(cpu) {
- shash = kzalloc(shsize, GFP_KERNEL);
+ shash = kzalloc_node(shsize, GFP_KERNEL,
+cpu_to_node(cpu));
if (!shash)
return -ENOMEM;
*per_cpu_ptr(algo->shashs, cpu) = shash;
[PATCH] net: stmicro: fix LS field mask in EEE configuration
This patch fixes the LS mask when setting EEE timer.
LS field is 10 bits long and not 11 as currently.
Signed-off-by: Joao Pinto
Reported-By: Rayagond Kokatanur
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 834f40f..202216c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -184,7 +184,7 @@ static void dwmac4_set_eee_pls(struct mac_device_info *hw,
int link)
static void dwmac4_set_eee_timer(struct mac_device_info *hw, int ls, int tw)
{
void __iomem *ioaddr = hw->pcsr;
- int value = ((tw & 0x)) | ((ls & 0x7ff) << 16);
+ int value = ((tw & 0x)) | ((ls & 0x3ff) << 16);
/* Program the timers in the LPI timer control register:
* LS: minimum time (ms) for which the link
--
2.9.3
Re: [PATCH net] ipv6: seg6_genl_set_tunsrc() must check kmemdup() return value
From: Eric Dumazet
Date: Fri, 20 Jan 2017 07:57:42 -0800
> From: Eric Dumazet
>
> seg6_genl_get_tunsrc() and set_tun_src() do not handle tun_src being
> possibly NULL, so we must check kmemdup() return value and abort if
> it is NULL
>
> Fixes: 915d7e5e5930 ("ipv6: sr: add code base for control plane support of
> SR-IPv6")
> Signed-off-by: Eric Dumazet
Applied, thanks Eric.
Re: [PATCH] stmicro: add more information to Kconfig
My e-mail client went bogus, please ignore 2 past e-mails. Very sorry. Best Regards, Joao Pinto Às 3:57 PM de 1/20/2017, Joao Pinto escreveu: > This patch adds more info to stmicro' Kconfig files in order to be clearer > that the driver can be used by ethernet cards based on 10/100/1000/EQOS > Synopsys IP Cores. > > EQOS was also added stmmac/Kconfig Kconfig, since dwmac4 is in fact EQoS, > one of Synopsys Ethernet IPs. More info at: > https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_qos > > Signed-off-by: Joao Pinto > --- > drivers/net/ethernet/stmicro/Kconfig| 3 ++- > drivers/net/ethernet/stmicro/stmmac/Kconfig | 15 +++ > 2 files changed, 9 insertions(+), 9 deletions(-) > > diff --git a/drivers/net/ethernet/stmicro/Kconfig > b/drivers/net/ethernet/stmicro/Kconfig > index 1c1157d..ecd7a5e 100644 > --- a/drivers/net/ethernet/stmicro/Kconfig > +++ b/drivers/net/ethernet/stmicro/Kconfig > @@ -7,7 +7,8 @@ config NET_VENDOR_STMICRO > default y > depends on HAS_IOMEM > ---help--- > - If you have a network (Ethernet) card belonging to this class, say Y. > + If you have a network (Ethernet) card based on Synopsys Ethernet IP > + Cores, say Y. > > Note that the answer to this question doesn't directly affect the > kernel: saying N will just cause the configurator to skip all > diff --git a/drivers/net/ethernet/stmicro/stmmac/Kconfig > b/drivers/net/ethernet/stmicro/stmmac/Kconfig > index 99594e3..cfbe363 100644 > --- a/drivers/net/ethernet/stmicro/stmmac/Kconfig > +++ b/drivers/net/ethernet/stmicro/stmmac/Kconfig > @@ -1,5 +1,5 @@ > config STMMAC_ETH > - tristate "STMicroelectronics 10/100/1000 Ethernet driver" > + tristate "STMicroelectronics 10/100/1000/EQOS Ethernet driver" > depends on HAS_IOMEM && HAS_DMA > select MII > select PHYLIB > @@ -7,9 +7,8 @@ config STMMAC_ETH > imply PTP_1588_CLOCK > select RESET_CONTROLLER > ---help--- > - This is the driver for the Ethernet IPs are built around a > - Synopsys IP Core and only tested on the STMicroelectronics > - platforms. > + This is the driver for the Ethernet IPs built around a > + Synopsys IP Core. > > if STMMAC_ETH > > @@ -152,11 +151,11 @@ config STMMAC_PCI > tristate "STMMAC PCI bus support" > depends on STMMAC_ETH && PCI > ---help--- > - This is to select the Synopsys DWMAC available on PCI devices, > - if you have a controller with this interface, say Y or M here. > + This selects the platform specific bus support for the stmmac driver. > + This driver was tested on XLINX XC2V3000 FF1152AMT0221 > + D1215994A VIRTEX FPGA board and SNPS QoS IPK Prototyping Kit. > > - This PCI support is tested on XLINX XC2V3000 FF1152AMT0221 > - D1215994A VIRTEX FPGA board. > + If you have a controller with this interface, say Y or M here. > > If unsure, say N. > endif >
Re: [PATCH 1/3] cxgb4: hide unused warnings
From: Arnd Bergmann
Date: Wed, 18 Jan 2017 15:52:51 +0100
> The two new variables are only used inside of an #ifdef and cause
> harmless warnings when that is disabled:
>
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c: In function 'init_one':
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4646:9: error: unused
> variable 'port_vec' [-Werror=unused-variable]
> drivers/net/ethernet/chelsio/cxgb4/cxgb4_main.c:4646:6: error: unused
> variable 'v' [-Werror=unused-variable]
>
> This adds another #ifdef around the declarations.
>
> Fixes: 96fe11f27b70 ("cxgb4: Implement ndo_get_phys_port_id for mgmt dev")
> Signed-off-by: Arnd Bergmann
Applied.
Re: [RFC PATCH] net: stmicro: eQOS IP Core
From: Joao Pinto Date: Fri, 20 Jan 2017 12:27:33 + > For historical reasons the Designware eQOS IP Core started in version 4.x, > instead of starting in 1.x. This caused some misunderstanding, which resulted > in calling this IP as GMAC4. If you go to Synopsys website and check the > Ethernet portfolio there is no GMAC4 IP: > https://www.synopsys.com/designware-ip/interface-ip/ethernet.html > > There is a new version of eQOS comming out (5.x) that will have the same > mac, dma registers and flow, with an extra set of registers to enable > features like TSN. The creation of a dwmac5 or gmac5 would be wrong, and > including those new features related to eQOS 5.x in dwmac4 would also not > be very correct. > > This patch suggests to rename dwmac4_* driver to eqos_*, turning it the > official driver for eQOS IP. The registers definitions are also now > called QOS_ instead of GMAC4_. > > For more information about eQOS IP please check: > https://www.synopsys.com/dw/ipdir.php?ds=dwc_ether_qos > > Signed-off-by: Joao Pinto Sorry, you're not renaming every function in the driver that meets this qualification. I understand you want to work hard on the driver, but part of that is _accepting_ things how they have been for years and making code improvements and additions rather than messing around playing rename-this/rename-that games until it looks how you want it to. Please stop this charade of renaming, I'm getting really tired of it and I think you really have no concept what kind of effect it has on people who have to review, apply, and backport this code. Kconfig text changes and clarifications, that's fine. But all of these function and variable name changes to the driver, and comment sweeps, no it is not acceptable to me.
[PATCH net-next] bnx2x: avoid two atomic ops per page on x86
From: Eric Dumazet
Commit 4cace675d687 ("bnx2x: Alloc 4k fragment for each rx ring buffer
element") added extra put_page() and get_page() calls on arches where
PAGE_SIZE=4K like x86
Reorder things to avoid this overhead.
Signed-off-by: Eric Dumazet
Cc: Gabriel Krisman Bertazi
Cc: Yuval Mintz
Cc: Ariel Elior
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 15 --
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
index
3e199d3e461ef5dd237e3176bcb666f878ac..c0dac0e5696d7d01457a42c2c13f1640c2e2
100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c
@@ -549,14 +549,7 @@ static int bnx2x_alloc_rx_sge(struct bnx2x *bp, struct
bnx2x_fastpath *fp,
struct bnx2x_alloc_pool *pool = &fp->page_pool;
dma_addr_t mapping;
- if (!pool->page || (PAGE_SIZE - pool->offset) < SGE_PAGE_SIZE) {
-
- /* put page reference used by the memory pool, since we
-* won't be using this page as the mempool anymore.
-*/
- if (pool->page)
- put_page(pool->page);
-
+ if (!pool->page) {
pool->page = alloc_pages(gfp_mask, PAGES_PER_SGE_SHIFT);
if (unlikely(!pool->page))
return -ENOMEM;
@@ -571,7 +564,6 @@ static int bnx2x_alloc_rx_sge(struct bnx2x *bp, struct
bnx2x_fastpath *fp,
return -ENOMEM;
}
- get_page(pool->page);
sw_buf->page = pool->page;
sw_buf->offset = pool->offset;
@@ -581,7 +573,10 @@ static int bnx2x_alloc_rx_sge(struct bnx2x *bp, struct
bnx2x_fastpath *fp,
sge->addr_lo = cpu_to_le32(U64_LO(mapping));
pool->offset += SGE_PAGE_SIZE;
-
+ if (PAGE_SIZE - pool->offset >= SGE_PAGE_SIZE)
+ get_page(pool->page);
+ else
+ pool->page = NULL;
return 0;
}
Re: [PATCH net-next] cxgb4: Fix unused variable warning
From: Ganesh Goudar Date: Fri, 20 Jan 2017 14:47:19 +0530 > Fix unused variable warning when CONFIG_PCI_IOV is not > defined. > > Signed-off-by: Ganesh Goudar Arnd already submitted a fix for this, and unlike your's his provided a proper Fixes-by: tag. Thanks.
Re: [PATCH net-next] net: remove bh disabling around percpu_counter accesses
From: Eric Dumazet
Date: Fri, 20 Jan 2017 05:06:08 -0800
> From: Eric Dumazet
>
> Shaohua Li made percpu_counter irq safe in commit 098faf5805c8
> ("percpu_counter: make APIs irq safe")
>
> We can safely remove BH disable/enable sections around various
> percpu_counter manipulations.
>
> Signed-off-by: Eric Dumazet
Looks great, applied, thanks Eric.
Re: [PATCH] net: sctp: fix array overrun read on sctp_timer_tbl
From: Colin King
Date: Fri, 20 Jan 2017 13:01:57 +
> From: Colin Ian King
>
> The comparison on the timeout can lead to an array overrun
> read on sctp_timer_tbl because of an off-by-one error. Fix
> this by using < instead of <= and also compare to the array
> size rather than SCTP_EVENT_TIMEOUT_MAX.
>
> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> Signed-off-by: Colin Ian King
Applied.
Re: [PATCH] rtlwifi: rtl8192x: Enabling and disabling hardware interrupts after enabling local irq flags
On 01/20/2017 08:14 AM, Bharat Kumar Gogada wrote: > On 01/19/2017 04:14 AM, Bharat Kumar Gogada wrote: -Realtek 8192CE chipset maintains local irq flags after enabling/disabling hardware interrupts. -Hardware interrupts are enabled before enabling the local irq flags(these flags are being checked in interrupt handler), leading to race condition on some RP, where the irq line between bridge and GIC goes high at ASSERT_INTx and goes low only at DEASSERT_INTx. In this kind of RP by the time ASSERT_INTx is seen irq_enable flag is still set to false, resulting in continuous interrupts seen by CPU as DEASSERT_INTx cannot be sent since flag is still false and making CPU stall. -Changing the sequence of setting these irq flags. Signed-off-by: Bharat Kumar Gogada --- This patch should be enhanced with the smb_xx() calls as suggested by by Lino. The subject should be changed. I would suggest something like "rtlwifi: rtl8192ce: Prevent race condition when enabling interrupts", as it explains the condition you are preventing. The other PCI drivers also have the same problem. Do you want to prepare the patches, or should I do it? Thanks Larry. Please send out the patches adding the above enhancements suggested by Lino. I have prepared a patch fixing all the drivers. By the way, what CPU hardware showed this problem? Larry
Re: [PATCH net-next] gre6: Clean up unused struct ipv6_tel_txoption definition
From: Jakub Sitnicki
Date: Fri, 20 Jan 2017 14:53:06 +0100
> Commit b05229f44228 ("gre6: Cleanup GREv6 transmit path, call common GRE
> functions") removed the ip6gre specific transmit function, but left the
> struct ipv6_tel_txoption definition. Clean it up.
>
> Signed-off-by: Jakub Sitnicki
Applied, thank you.
Re: [PATCH net-next] uapi: fix signess in ethtool_validate_speed()
On Fri, Jan 20, 2017 at 02:20:53PM +0100, Volodymyr Bendiuga wrote:
> From: Jonas Johansson
>
> There is a comparison of speed variable which
> is unsigned, and SPEED_UNKNOWN which is signed.
So?
>
> Signed-off-by: Jonas Johansson
> Signed-off-by: Volodymyr Bendiuga
> ---
> include/uapi/linux/ethtool.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
> index f0db778..1ca4a77 100644
> --- a/include/uapi/linux/ethtool.h
> +++ b/include/uapi/linux/ethtool.h
> @@ -1500,7 +1500,7 @@ enum ethtool_link_mode_bit_indices {
>
> #define SPEED_UNKNOWN-1
>
> -static inline int ethtool_validate_speed(__u32 speed)
> +static inline int ethtool_validate_speed(__s32 speed)
> {
> return speed <= INT_MAX || speed == SPEED_UNKNOWN;
> }
Then comparison to INT_MAX does not make sense.
> --
> 2.7.4
Re: [PATCH] sock: use hlist_entry_safe
From: Geliang Tang Date: Fri, 20 Jan 2017 22:27:04 +0800 > Use hlist_entry_safe() instead of open-coding it. > > Signed-off-by: Geliang Tang Applied.
Re: [PATCHv3 net-next 3/4] sctp: add support for generating stream reconf add incoming/outgoing streams request chunk
On Fri, Jan 20, 2017 at 02:50:01PM +, David Laight wrote:
> From: Xin Long
> > Sent: 19 January 2017 17:19
> > This patch is to define Add Incoming/Outgoing Streams Request
> > Parameter described in rfc6525 section 4.5 and 4.6. They can
> > be in one same chunk trunk as rfc6525 section 3.1-7 describes,
> > so make them in one function.
> ...
> > +struct sctp_strreset_addstrm {
> > + sctp_paramhdr_t param_hdr;
> > + __u32 request_seq;
> > + __u16 number_of_streams;
> > + __u16 reserved;
> > +} __packed;
> ...
> > + addstrm.param_hdr.type = SCTP_PARAM_RESET_ADD_OUT_STREAMS;
> > + addstrm.param_hdr.length = htons(size);
> > + addstrm.number_of_streams = htons(out);
> > + addstrm.request_seq = htonl(asoc->strreset_outseq);
> > + addstrm.reserved = 0;
> > +
> > + sctp_addto_chunk(retval, size, &addstrm);
>
> Since you allocate the sctp_strreset_addstrm structure on stack
> there is no requirement for it to be packed.
It shouldn't matter that it's allocated on stack. Why should it?
We need it to be packed as this is a header that will be sent out to
another peer, so there can't be any padding on it.
Marcelo
Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
From: Colin King
Date: Fri, 20 Jan 2017 13:45:42 +
> From: Colin Ian King
>
> Table sctp_timer_tbl is missing a TIMEOUT_RECONF string so
> add this in. Also compare timeout with the size of the array
> sctp_timer_tbl rather than SCTP_EVENT_TIMEOUT_MAX. Also add
> a build time check that SCTP_EVENT_TIMEOUT_MAX is correct
> so we don't ever get this kind of mismatch between the table
> and SCTP_EVENT_TIMEOUT_MAX in the future.
>
> Kudos to Marcel Ricardo Leitner for spotting the missing string
> and suggesting the build time sanity check.
>
> Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
>
> Signed-off-by: Colin Ian King
Well, my bad... I reverted V1, that's fine.
But this patch doesn't even compile.
In file included from ./include/uapi/linux/stddef.h:1:0,
from ./include/linux/stddef.h:4,
from ./include/uapi/linux/posix_types.h:4,
from ./include/uapi/linux/types.h:13,
from ./include/linux/types.h:5,
from ./include/net/sctp/sctp.h:58,
from net/sctp/debug.c:41:
net/sctp/debug.c: In function ‘sctp_tname’:
./include/linux/compiler.h:518:38: error: call to ‘__compiletime_assert_170’
declared with attribute error: BUILD_BUG_ON failed: SCTP_EVENT_TIMEOUT_MAX + 1
!= ARRAY_SIZE(sctp_timer_tbl)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
Re: Getting a handle on all these new NIC features
Hi Tom, On 17/01/17 22:05, Tom Herbert wrote: > There was some discussion about the problems of dealing with the > explosion of NIC features in the mlx directory restructuring proposal, > but I think the is a deeper issue here that should be discussed. > > It's hard not to notice that there has been quite a proliferation of > NIC features in several drivers. This trend had resulted in very > complex driver code that may or may not segment individual features. > One visible manifestation of this is number of ndo functions which is > somewhere around seventy-five now. > > I suspect the vast majority of these advances NIC features (e.g. > bridging, UDP offloads, tc offload, etc.) are only relevant to some of > the people some of the time. The problem we have, in this case those > of us that are attempting to deploy and maintain NICs at scale, is > when we have to deal with the ramifications of these features being > intertwined with core driver functionality that is relevant to > everyone. This becomes very obvious when we need to backport drivers > from later versions of kernel. > > I realize that backports of a driver is not a specific concern of the > Linux kernel, but nevertheless this is a real problem and a fact of > life for many users. Rebasing the full kernel is still a major effort > and it seems the best we could ever do is one rebase per year. In the > interim we need to occasionally backport drivers. Backporting drivers > is difficult precisely because of new features or API changes to > existing ones. These sort of changes tend to have a spiderweb of > dependencies in other parts of the stack so that the number of patches > we need to cherry-pick goes way beyond those that touch the driver we > are interested in. For the sfc driver (Solarflare Adapters) we currently do backports internally for: - RedHat Enterprise Linux5.10, 5.11 - RedHat Enterprise Linux6.5, 6.6, 6.7, 6.8 - Redhat Messaging Realtime and Grid 2.5 - RedHat Enterprise Linux7.0, 7.1, 7.2 - RedHat Enterprise Linux for Realtime 7.1, 7.2 - SuSE Linux Enterprise Server 11sp3, sp4 - SuSE Linux Enterprise RealTime Extension 11 - SuSE Linux Enterprise Server 12base release, sp1 - Canonical Ubuntu Server LTS14.04, 16.04 - Canonical Ubuntu Server- - Debian 7 "Wheezy" 7.X - Debian 8 "Jessie" 8.X - Linux 2.6.18 to 4.9-rc1 We update this list as needed, and always try to support the latest kernel. I do not know if that would cover the kernel version you are using. Best regards, Martin > Currently we (FB) need to backport two NIC drivers. I've already gave > details of backporting mlx5 on the thread to restructure the driver > directories. The other driver being backporting seems to suffer from > the same type of feature complexity. > > In short, I would like to ask if driver maintainers to start to > modularize driver features. If something being added is obviously a > narrow feature that only a subset of users will need can we allow > config options to #ifdef those out somehow? Furthermore can the file > and directory structure of drivers reflect that; our lives would be > _so_ much simpler to maintain drivers in production if we have such > modularity and the ability to build drivers with the features of our > choosing. > > Thanks, > Tom
Re: [net-next PATCH 0/3] Retrieve number of VFs in a bus-agnostic way
From: Phil Sutter Date: Wed, 18 Jan 2017 14:04:36 +0100 > Previously, it was assumed that only PCI NICs would be capable of having > virtual functions - with my proposed enhancement of dummy NIC driver > implementing (fake) ones for testing purposes, this is no longer true. > > Discussion of said patch has led to the suggestion of implementing a > bus-agnostic method for VF count retrieval so rtnetlink could work with > both real VF-capable PCI NICs as well as my dummy modifications without > introducing ugly hacks. > > The following series tries to achieve just that by introducing a bus > type callback to retrieve a device's number of VFs, implementing this > callback for PCI bus and finally adjusting rtnetlink to make use of the > generalized infrastructure. This is really nice and clean, compare it to your original approach :-) Series applied, thanks!
Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
From: Marcelo Ricardo Leitner
Date: Fri, 20 Jan 2017 11:58:45 -0200
> Not sure I can add the Fixes tag for you here, but:
> Fixes: 7b9438de0cd4 ("sctp: add stream reconf timer")
> Acked-by: Marcelo Ricardo Leitner
FWIW, patchwork doesn't notice updated Fixes: tags like this but I
try to do so myself and the effort is definitely appreciated.
We need a V3 of this change anyways, see the build failure I reported
for V2, so Colin can add the Fixes: tag there explicitly.
Re: [PATCH net-next V4] tc: flower: Refactor matching flags to be more user friendly
On Fri, 20 Jan 2017 12:27:42 +, David Laight wrote:
> Consider what happened with "no", "nofubar" and "nofubar_baz",
> all ought to be rejected.
Why? "no" translates to "", "nofubar" to "fubar", etc. And those will
be evaluated the same way as if they were supplied without the "no".
I don't see a problem with this.
> Actually using strncmp() is also overkill.
Why? It compares two bytes. There's an extra null at the end of the
"no" string but I wouldn't call that "overkill".
> Nothing wrong with:
> if (token[0] == 'n' && token[1] == 'o' && token[2]) {
Except that strncmp is easier to understand and cleaner.
> no = true;
> token += 2;
> if (token[0] == '_' && token[1])
> token++;
This doesn't make sense. The intent was not to allow both "nofrag" and
"no_frag". The code in the patch treats "no_frag" as invalid and that's
okay.
> ...
>
> or replace the last 3 lines with:
> token += 2 + (token[2] == '_' & token[3]);
That's horribly ugly. Anyone looking at this will spent 2 minutes
trying to untangle the code instead of the 2 seconds with the current
code. We're not trying to win the Obfuscated C Contest here.
Jiri
Re: [PATCH 2/3] qed: avoid possible stack overflow in qed_ll2_acquire_connection
From: Arnd Bergmann Date: Wed, 18 Jan 2017 15:52:52 +0100 > struct qed_ll2_info is rather large, so putting it on the stack > can cause an overflow, as this warning tries to tell us: > > drivers/net/ethernet/qlogic/qed/qed_ll2.c: In function 'qed_ll2_start': > drivers/net/ethernet/qlogic/qed/qed_ll2.c:2159:1: error: the frame size of > 1056 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] > > qed_ll2_start_ooo() already uses a dynamic allocation for the structure > to work around that problem, and we could do the same in qed_ll2_start() > as well as qed_roce_ll2_start(), but since the structure is only > used to pass a couple of initialization values here, it seems nicer > to replace it with a different structure. > > Lacking any idea for better naming, I'm adding 'struct qed_ll2_conn', > which now contains all the initialization data, and this now simply > gets copied into struct qed_ll2_info rather than assigning all members > one by one. > > Signed-off-by: Arnd Bergmann Applied.
Re: [PATCH net] virtio-net: restore VIRTIO_HDR_F_DATA_VALID on receiving
On Fri, Jan 20, 2017 at 02:32:42PM +0800, Jason Wang wrote:
> Commit 501db511397f ("virtio: don't set VIRTIO_NET_HDR_F_DATA_VALID on
> xmit") in fact disables VIRTIO_HDR_F_DATA_VALID on receiving path too,
> fixing this by adding a hint (has_data_valid) and set it only on the
> receiving path.
>
> Cc: Rolf Neugebauer
> Signed-off-by: Jason Wang
> ---
> drivers/net/macvtap.c | 2 +-
> drivers/net/tun.c | 2 +-
> drivers/net/virtio_net.c | 2 +-
> include/linux/virtio_net.h | 6 +-
> net/packet/af_packet.c | 4 ++--
> 5 files changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 5c26653..4026185 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -825,7 +825,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
> return -EINVAL;
>
> if (virtio_net_hdr_from_skb(skb, &vnet_hdr,
> - macvtap_is_little_endian(q)))
> + macvtap_is_little_endian(q), true))
> BUG();
>
> if (copy_to_iter(&vnet_hdr, sizeof(vnet_hdr), iter) !=
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index cd8e02c..2cd10b2 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1360,7 +1360,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
> return -EINVAL;
>
> if (virtio_net_hdr_from_skb(skb, &gso,
> - tun_is_little_endian(tun))) {
> + tun_is_little_endian(tun), true)) {
> struct skb_shared_info *sinfo = skb_shinfo(skb);
> pr_err("unexpected GSO type: "
> "0x%x, gso_size %d, hdr_len %d\n",
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 4a10500..3474243 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -1104,7 +1104,7 @@ static int xmit_skb(struct send_queue *sq, struct
> sk_buff *skb)
> hdr = skb_vnet_hdr(skb);
>
> if (virtio_net_hdr_from_skb(skb, &hdr->hdr,
> - virtio_is_little_endian(vi->vdev)))
> + virtio_is_little_endian(vi->vdev), false))
> BUG();
>
> if (vi->mergeable_rx_bufs)
> diff --git a/include/linux/virtio_net.h b/include/linux/virtio_net.h
> index 5643647..5209b5e 100644
> --- a/include/linux/virtio_net.h
> +++ b/include/linux/virtio_net.h
> @@ -56,7 +56,8 @@ static inline int virtio_net_hdr_to_skb(struct sk_buff *skb,
>
> static inline int virtio_net_hdr_from_skb(const struct sk_buff *skb,
> struct virtio_net_hdr *hdr,
> - bool little_endian)
> + bool little_endian,
> + bool has_data_valid)
> {
> memset(hdr, 0, sizeof(*hdr)); /* no info leak */
>
I would prefer naming it is_rx. Callers should not know about
internal details like data valid, the issue we are trying to fix
here is that tx and tx headers are slightly different.
> @@ -91,6 +92,9 @@ static inline int virtio_net_hdr_from_skb(const struct
> sk_buff *skb,
> skb_checksum_start_offset(skb));
> hdr->csum_offset = __cpu_to_virtio16(little_endian,
> skb->csum_offset);
> + } else if (has_data_valid &&
> +skb->ip_summed == CHECKSUM_UNNECESSARY) {
> + hdr->flags = VIRTIO_NET_HDR_F_DATA_VALID;
> } /* else everything is zero */
>
> return 0;
> diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
> index b9e1a13..3d555c7 100644
> --- a/net/packet/af_packet.c
> +++ b/net/packet/af_packet.c
> @@ -1976,7 +1976,7 @@ static int packet_rcv_vnet(struct msghdr *msg, const
> struct sk_buff *skb,
> return -EINVAL;
> *len -= sizeof(vnet_hdr);
>
> - if (virtio_net_hdr_from_skb(skb, &vnet_hdr, vio_le()))
> + if (virtio_net_hdr_from_skb(skb, &vnet_hdr, vio_le(), true))
> return -EINVAL;
>
> return memcpy_to_msg(msg, (void *)&vnet_hdr, sizeof(vnet_hdr));
> @@ -2237,7 +2237,7 @@ static int tpacket_rcv(struct sk_buff *skb, struct
> net_device *dev,
> if (po->has_vnet_hdr) {
> if (virtio_net_hdr_from_skb(skb, h.raw + macoff -
> sizeof(struct virtio_net_hdr),
> - vio_le())) {
> + vio_le(), true)) {
> spin_lock(&sk->sk_receive_queue.lock);
> goto drop_n_account;
> }
> --
> 2.7.4
[PATCH net] bridge: netlink: call br_changelink() during br_dev_newlink()
Any bridge options specified during link creation (e.g. ip link add)
are ignored as br_dev_newlink() does not process them.
Use br_changelink() to do it.
Signed-off-by: Ivan Vecera
---
net/bridge/br_netlink.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 71c7453..7109b38 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -781,20 +781,6 @@ static int br_validate(struct nlattr *tb[], struct nlattr
*data[])
return 0;
}
-static int br_dev_newlink(struct net *src_net, struct net_device *dev,
- struct nlattr *tb[], struct nlattr *data[])
-{
- struct net_bridge *br = netdev_priv(dev);
-
- if (tb[IFLA_ADDRESS]) {
- spin_lock_bh(&br->lock);
- br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
- spin_unlock_bh(&br->lock);
- }
-
- return register_netdevice(dev);
-}
-
static int br_port_slave_changelink(struct net_device *brdev,
struct net_device *dev,
struct nlattr *tb[],
@@ -1115,6 +1101,25 @@ static int br_changelink(struct net_device *brdev,
struct nlattr *tb[],
return 0;
}
+static int br_dev_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct net_bridge *br = netdev_priv(dev);
+ int err;
+
+ if (tb[IFLA_ADDRESS]) {
+ spin_lock_bh(&br->lock);
+ br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
+ spin_unlock_bh(&br->lock);
+ }
+
+ err = br_changelink(dev, tb, data);
+ if (err)
+ return err;
+
+ return register_netdevice(dev);
+}
+
static size_t br_get_size(const struct net_device *brdev)
{
return nla_total_size(sizeof(u32)) +/* IFLA_BR_FORWARD_DELAY */
--
2.10.2
Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
From: Marcelo Ricardo Leitner Date: Fri, 20 Jan 2017 14:48:20 -0200 > Seems you applied it on net tree, but commit that introduced the issue > (7b9438de0cd4) is still only on net-next. That explains everything. > I build-tested it here before acking, it worked, on top of > 4567d686f5c6d955e57a3afa1741944c1e7f4033. > > Colin, please respin the patch.. add the Fixes tag, fix the missing 'o' > in my name on the changelog :-) and tag the patch as net-next tree too. Indeed, thanks.
Re: [PATCH 3/3] bcm63xx_enet: avoid uninitialized variable warning
From: Arnd Bergmann Date: Wed, 18 Jan 2017 15:52:53 +0100 > gcc-7 and probably earlier versions get confused by this function > and print a harmless warning: > > drivers/net/ethernet/broadcom/bcm63xx_enet.c: In function 'bcm_enet_open': > drivers/net/ethernet/broadcom/bcm63xx_enet.c:1130:3: error: 'phydev' may be > used uninitialized in this function [-Werror=maybe-uninitialized] > > This adds an initialization for the 'phydev' variable when it is unused > and changes the check to test for that NULL pointer to make it clear > that we always pass a valid pointer here. > > Signed-off-by: Arnd Bergmann Also applied, thanks.
Re: [RFC] net: ipv6: return the first matched rt6_info for multicast packets in find_rr_leaf()
From: Rajasekar Kumar Date: Wed, 18 Jan 2017 20:43:37 +0530 > There is a performance issue when large number of interfaces are > enabled with VRRP protocol in 2 router nodes which are connected > to each other. When VRRP hello is received (which is multicast > packet with DIP: ff02::18), a rt6_info node is added to fib6_node > of address ff02::18. This happens for each interface on which > VRRP is enabled. For 2000 interfaces with VRRP enabled, 2000 > rt6_info nodes are added to the same fib6_node. As of today, > find_rr_leaf() goes further to find better match, even after first > successful match based on interface key. In this case, it walks > 2000 nodes for every incoming packet/outgoing packet, which is > expensive and not needed. rt6_info match based on supplied > interface match should be sufficient. The first match occurs > when there is interface match, and after that there can not be > another match for multicast packets. So, first match should be > returned for multicast packets. > > find_rr_leaf() tries to find best available gateway, mainly based on > interface match and gateway's reachablity info.When this is required > for unicast packets, multicast packets do not need either gateway's > reachability status or gateway's Layer2 address as it is derived > from Destination IP (group address). rt6_info match based on supplied > interface match should be sufficient. > > This fix helps in scenario wherein multicast packets arrive in some > interfaces frequently than other interfaces. rt6_info is added to > beginning of list for former cases. Verified this case. > > Signed-off-by: Rajasekar Kumar So the only thing different in each rt6_info in the list is the interface, right? Well, that's a part of the lookup key, multicast or not. If the user binds a socket to a specific interface, they want the route lookup to return the rt6_info node with that device. So I think your change introduces a regression, therefore another solution will need to be found for your performance problem.
Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
On Fri, Jan 20, 2017 at 11:31:17AM -0500, David Miller wrote:
> From: Colin King
> Date: Fri, 20 Jan 2017 13:45:42 +
>
> > From: Colin Ian King
> >
> > Table sctp_timer_tbl is missing a TIMEOUT_RECONF string so
> > add this in. Also compare timeout with the size of the array
> > sctp_timer_tbl rather than SCTP_EVENT_TIMEOUT_MAX. Also add
> > a build time check that SCTP_EVENT_TIMEOUT_MAX is correct
> > so we don't ever get this kind of mismatch between the table
> > and SCTP_EVENT_TIMEOUT_MAX in the future.
> >
> > Kudos to Marcel Ricardo Leitner for spotting the missing string
> > and suggesting the build time sanity check.
> >
> > Fixes CoverityScan CID#1397639 ("Out-of-bounds read")
> >
> > Signed-off-by: Colin Ian King
>
> Well, my bad... I reverted V1, that's fine.
>
> But this patch doesn't even compile.
>
> In file included from ./include/uapi/linux/stddef.h:1:0,
> from ./include/linux/stddef.h:4,
> from ./include/uapi/linux/posix_types.h:4,
> from ./include/uapi/linux/types.h:13,
> from ./include/linux/types.h:5,
> from ./include/net/sctp/sctp.h:58,
> from net/sctp/debug.c:41:
> net/sctp/debug.c: In function ‘sctp_tname’:
> ./include/linux/compiler.h:518:38: error: call to ‘__compiletime_assert_170’
> declared with attribute error: BUILD_BUG_ON failed: SCTP_EVENT_TIMEOUT_MAX +
> 1 != ARRAY_SIZE(sctp_timer_tbl)
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
Seems you applied it on net tree, but commit that introduced the issue
(7b9438de0cd4) is still only on net-next.
I build-tested it here before acking, it worked, on top of
4567d686f5c6d955e57a3afa1741944c1e7f4033.
Colin, please respin the patch.. add the Fixes tag, fix the missing 'o'
in my name on the changelog :-) and tag the patch as net-next tree too.
Thanks,
Marcelo
Re: [net-next PATCH 0/3] Retrieve number of VFs in a bus-agnostic way
On Fri, Jan 20, 2017 at 11:43:46AM -0500, David Miller wrote: > From: Phil Sutter > Date: Wed, 18 Jan 2017 14:04:36 +0100 > > > Previously, it was assumed that only PCI NICs would be capable of having > > virtual functions - with my proposed enhancement of dummy NIC driver > > implementing (fake) ones for testing purposes, this is no longer true. > > > > Discussion of said patch has led to the suggestion of implementing a > > bus-agnostic method for VF count retrieval so rtnetlink could work with > > both real VF-capable PCI NICs as well as my dummy modifications without > > introducing ugly hacks. > > > > The following series tries to achieve just that by introducing a bus > > type callback to retrieve a device's number of VFs, implementing this > > callback for PCI bus and finally adjusting rtnetlink to make use of the > > generalized infrastructure. > > This is really nice and clean, compare it to your original approach :-) Yes, indeed! Thanks a lot for pointing me into the right direction. :) Cheers, Phil
[PATCH net v2] bridge: netlink: call br_changelink() during br_dev_newlink()
Any bridge options specified during link creation (e.g. ip link add)
are ignored as br_dev_newlink() does not process them.
Use br_changelink() to do it.
Fixes: 1332351 bridge: implement rtnl_link_ops->changelink
Signed-off-by: Ivan Vecera
---
net/bridge/br_netlink.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 71c7453..7109b38 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -781,20 +781,6 @@ static int br_validate(struct nlattr *tb[], struct nlattr
*data[])
return 0;
}
-static int br_dev_newlink(struct net *src_net, struct net_device *dev,
- struct nlattr *tb[], struct nlattr *data[])
-{
- struct net_bridge *br = netdev_priv(dev);
-
- if (tb[IFLA_ADDRESS]) {
- spin_lock_bh(&br->lock);
- br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
- spin_unlock_bh(&br->lock);
- }
-
- return register_netdevice(dev);
-}
-
static int br_port_slave_changelink(struct net_device *brdev,
struct net_device *dev,
struct nlattr *tb[],
@@ -1115,6 +1101,25 @@ static int br_changelink(struct net_device *brdev,
struct nlattr *tb[],
return 0;
}
+static int br_dev_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct net_bridge *br = netdev_priv(dev);
+ int err;
+
+ if (tb[IFLA_ADDRESS]) {
+ spin_lock_bh(&br->lock);
+ br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
+ spin_unlock_bh(&br->lock);
+ }
+
+ err = br_changelink(dev, tb, data);
+ if (err)
+ return err;
+
+ return register_netdevice(dev);
+}
+
static size_t br_get_size(const struct net_device *brdev)
{
return nla_total_size(sizeof(u32)) +/* IFLA_BR_FORWARD_DELAY */
--
2.10.2
RE: [net PATCH v5 6/6] virtio_net: XDP support for adjust_head
From: Michael S. Tsirkin > Sent: 19 January 2017 21:12 > > On 2017?01?18? 23:15, Michael S. Tsirkin wrote: > > > On Tue, Jan 17, 2017 at 02:22:59PM -0800, John Fastabend wrote: > > > > Add support for XDP adjust head by allocating a 256B header region > > > > that XDP programs can grow into. This is only enabled when a XDP > > > > program is loaded. > > > > > > > > In order to ensure that we do not have to unwind queue headroom push > > > > queue setup below bpf_prog_add. It reads better to do a prog ref > > > > unwind vs another queue setup call. > > > > > > > > At the moment this code must do a full reset to ensure old buffers > > > > without headroom on program add or with headroom on program removal > > > > are not used incorrectly in the datapath. Ideally we would only > > > > have to disable/enable the RX queues being updated but there is no > > > > API to do this at the moment in virtio so use the big hammer. In > > > > practice it is likely not that big of a problem as this will only > > > > happen when XDP is enabled/disabled changing programs does not > > > > require the reset. There is some risk that the driver may either > > > > have an allocation failure or for some reason fail to correctly > > > > negotiate with the underlying backend in this case the driver will > > > > be left uninitialized. I have not seen this ever happen on my test > > > > systems and for what its worth this same failure case can occur > > > > from probe and other contexts in virtio framework. > > > > > > > > Signed-off-by: John Fastabend > > > I've been thinking about it - can't we drop > > > old buffers without the head room which were posted before > > > xdp attached? > > > > > > Avoiding the reset would be much nicer. > > > > > > Thoughts? > > > > > > > As been discussed before, device may use them in the same time so it's not > > safe. Or do you mean detect them after xdp were set and drop the buffer > > without head room, this looks sub-optimal. > > > > Thanks > > Yes, this is what I mean. Why is this suboptimal? It's a single branch > in code. Yes we might lose some packets but the big hammer of device > reset will likely lose more. Why not leave let the hardware receive into the 'small' buffer (without headroom) and do a copy when a frame is received. Replace the buffers with 'big' ones for the next receive. A data copy on a ring full of buffers won't really be noticed. David
Re: [PATCH][V2] net: sctp: fix array overrun read on sctp_timer_tbl
On Fri, Jan 20, 2017 at 11:32:09AM -0500, David Miller wrote:
> From: Marcelo Ricardo Leitner
> Date: Fri, 20 Jan 2017 11:58:45 -0200
>
> > Not sure I can add the Fixes tag for you here, but:
> > Fixes: 7b9438de0cd4 ("sctp: add stream reconf timer")
> > Acked-by: Marcelo Ricardo Leitner
>
> FWIW, patchwork doesn't notice updated Fixes: tags like this but I
> try to do so myself and the effort is definitely appreciated.
Ok, good to know, thanks.
>
> We need a V3 of this change anyways, see the build failure I reported
> for V2, so Colin can add the Fixes: tag there explicitly.
>
Replied this one in there.
Marcelo
Re: [PATCH net 0/2] net: Fix oops on state free after lwt module unload
From: Robert Shearman Date: Wed, 18 Jan 2017 15:32:01 + > This patchset fixes an oops in lwtstate_free and a memory leak that > would otherwise be exposed by ensuring that references are taken on > modules that need to stay around to clean up lwt state. To faciliate > this all ops that implement destroy_state and that can be configured > to build as a module are changed specify the owner module in the > ops. The intersection of those two sets is just ila at the moment. Two things: 1) Under no circumstances should we allow a lwtunnel ops implementing module to unload while there is a rule using those ops which is alive. Therefore, we should not special case the destroy op. We should unconditionally grab the module reference. 2) Please add the new 'owner' field and add an appropriate assignment for ops->owner to _every_ lwtunnel implementation, and do so in your first patch. Please do not only do this for ILA. Thanks.
Re: [PATCH v5 0/2] Add support for the ethernet switch on the ESPRESSObin
Hi Andrew, On jeu., janv. 19 2017, Andrew Lunn wrote: >> While comparing the datasheet and the ops functions used, some >> question came to me. They should not prevent applying this series, >> but their answer would help me to have a better understanding of the >> dsa subsystem. >> >> - Are the temperature related operation still useful with dsa2 ? > > No. I'm in the process of moving the code into the Marvell PHY driver, > since the sensor is in the embedded PHYs. > > What ID does the embedded PHY use? The 6390 has a blank ID, where as > older device have a real ID. Actually I didn't find anything related to the temperature measurement in the datasheet I have. For the 6390 there is a dedicated datsheet for the PHY part for the 6352 it is part of the same datasheet. After a second look I think I don't have anything related to the PHY part in the datasheets. What I wanted to do was to test 6390 and 6352 temperature related functions and to see if one of them worked. That's how I realized it was not possible to do it with dsa2. > >> - Why the setup is done differently between the 6390 and the 6352 >> families when the have exactly the same register? > > EDSA on 6390 works differently to 6352, meaning it breaks. So we need > to run the 6390 with DSA tagging, not EDSA. Maybe this is the source > of the differences? > > It should also be noted that the 6390 support is not yet complete. I > have a few more patches in my tree to post. > >> - On the Port Controller 2, the bit PORT_CONTROL_2_MAP_DA is set for >> 6352 and not for 6390 whereas the same bit exists in 6360 and the >> description for this bit is the same for both datasheet. > > Humm, it does look like it is missing mv88e6xxx_6390_family(chip). > >> >> - Register PORT_ATU_CONTROL and PORT_PRI_OVERRIDE are reset on 6352 >> and not on 6390. While here again the registers description are >> the same. > > And the same here. I've mostly been working on where the 6390 is > different. Where it is the same i've mostly ignored it so far :-) > > There is also an ongoing effort to remove all these big if statements > with a list of families. Thanks for this answers I understand it a little better now. Gregory > > Andrew -- Gregory Clement, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com
Re: [PATCH net v2] bridge: netlink: call br_changelink() during br_dev_newlink()
Fri, Jan 20, 2017 at 05:59:33PM CET, c...@cera.cz wrote: >Any bridge options specified during link creation (e.g. ip link add) >are ignored as br_dev_newlink() does not process them. >Use br_changelink() to do it. > >Fixes: 1332351 bridge: implement rtnl_link_ops->changelink This is not the correct "Fixes" format.
Re: [PATCH net-next] bpf: add bpf_probe_read_str helper
From: Gianluca Borello Date: Wed, 18 Jan 2017 17:55:49 + > Provide a simple helper with the same semantics of strncpy_from_unsafe(): > > int bpf_probe_read_str(void *dst, int size, const void *unsafe_addr) > > This gives more flexibility to a bpf program. ... > Signed-off-by: Gianluca Borello > Acked-by: Alexei Starovoitov > Acked-by: Daniel Borkmann Applied, thank you.
[PATCH net v3] bridge: netlink: call br_changelink() during br_dev_newlink()
Any bridge options specified during link creation (e.g. ip link add)
are ignored as br_dev_newlink() does not process them.
Use br_changelink() to do it.
Fixes: 1332351 ("bridge: implement rtnl_link_ops->changelink")
Signed-off-by: Ivan Vecera
---
net/bridge/br_netlink.c | 33 +++--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
index 71c7453..7109b38 100644
--- a/net/bridge/br_netlink.c
+++ b/net/bridge/br_netlink.c
@@ -781,20 +781,6 @@ static int br_validate(struct nlattr *tb[], struct nlattr
*data[])
return 0;
}
-static int br_dev_newlink(struct net *src_net, struct net_device *dev,
- struct nlattr *tb[], struct nlattr *data[])
-{
- struct net_bridge *br = netdev_priv(dev);
-
- if (tb[IFLA_ADDRESS]) {
- spin_lock_bh(&br->lock);
- br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
- spin_unlock_bh(&br->lock);
- }
-
- return register_netdevice(dev);
-}
-
static int br_port_slave_changelink(struct net_device *brdev,
struct net_device *dev,
struct nlattr *tb[],
@@ -1115,6 +1101,25 @@ static int br_changelink(struct net_device *brdev,
struct nlattr *tb[],
return 0;
}
+static int br_dev_newlink(struct net *src_net, struct net_device *dev,
+ struct nlattr *tb[], struct nlattr *data[])
+{
+ struct net_bridge *br = netdev_priv(dev);
+ int err;
+
+ if (tb[IFLA_ADDRESS]) {
+ spin_lock_bh(&br->lock);
+ br_stp_change_bridge_id(br, nla_data(tb[IFLA_ADDRESS]));
+ spin_unlock_bh(&br->lock);
+ }
+
+ err = br_changelink(dev, tb, data);
+ if (err)
+ return err;
+
+ return register_netdevice(dev);
+}
+
static size_t br_get_size(const struct net_device *brdev)
{
return nla_total_size(sizeof(u32)) +/* IFLA_BR_FORWARD_DELAY */
--
2.10.2
Re: [PATCH net-next] vxlan: preserve type of dst_port parm for encap_bypass_if_local()
From: Lance Richardson Date: Wed, 18 Jan 2017 15:24:57 -0500 > Eliminate sparse warning by maintaining type of dst_port > as __be16. > > Signed-off-by: Lance Richardson Applied.
Re: [PATCH net-next] csum: eliminate sparse warning in remcsum_unadjust()
From: Lance Richardson Date: Wed, 18 Jan 2017 15:14:56 -0500 > Cast second parameter of csum_sub() from __sum16 to __wsum. > > Signed-off-by: Lance Richardson Applied.
Re: Getting a handle on all these new NIC features
On Fri, Jan 20, 2017 at 8:36 AM, Martin Habets wrote: > Hi Tom, > > On 17/01/17 22:05, Tom Herbert wrote: >> There was some discussion about the problems of dealing with the >> explosion of NIC features in the mlx directory restructuring proposal, >> but I think the is a deeper issue here that should be discussed. >> >> It's hard not to notice that there has been quite a proliferation of >> NIC features in several drivers. This trend had resulted in very >> complex driver code that may or may not segment individual features. >> One visible manifestation of this is number of ndo functions which is >> somewhere around seventy-five now. >> >> I suspect the vast majority of these advances NIC features (e.g. >> bridging, UDP offloads, tc offload, etc.) are only relevant to some of >> the people some of the time. The problem we have, in this case those >> of us that are attempting to deploy and maintain NICs at scale, is >> when we have to deal with the ramifications of these features being >> intertwined with core driver functionality that is relevant to >> everyone. This becomes very obvious when we need to backport drivers >> from later versions of kernel. >> >> I realize that backports of a driver is not a specific concern of the >> Linux kernel, but nevertheless this is a real problem and a fact of >> life for many users. Rebasing the full kernel is still a major effort >> and it seems the best we could ever do is one rebase per year. In the >> interim we need to occasionally backport drivers. Backporting drivers >> is difficult precisely because of new features or API changes to >> existing ones. These sort of changes tend to have a spiderweb of >> dependencies in other parts of the stack so that the number of patches >> we need to cherry-pick goes way beyond those that touch the driver we >> are interested in. > > For the sfc driver (Solarflare Adapters) we currently do backports internally > for: > - RedHat Enterprise Linux5.10, 5.11 > - RedHat Enterprise Linux6.5, 6.6, 6.7, 6.8 >- Redhat Messaging Realtime and Grid 2.5 > - RedHat Enterprise Linux7.0, 7.1, 7.2 >- RedHat Enterprise Linux for Realtime 7.1, 7.2 > - SuSE Linux Enterprise Server 11sp3, sp4 >- SuSE Linux Enterprise RealTime Extension 11 > - SuSE Linux Enterprise Server 12base release, sp1 > - Canonical Ubuntu Server LTS14.04, 16.04 > - Canonical Ubuntu Server- > - Debian 7 "Wheezy" 7.X > - Debian 8 "Jessie" 8.X > - Linux 2.6.18 to 4.9-rc1 > > We update this list as needed, and always try to support the latest kernel. > I do not know if that would cover the kernel version you are using. > That really doesn't help us. We don't base which kernels we run in datacenters on what distros are doing-- they don't seem to move as fast in rebsing. Our general request is that vendors always do their development upstream, if we need to do a backport in our kernel then we take responsibility for that. As I mentioned, the churn and lack of modularization seem to be making this process more and more difficult. Tom > Best regards, > Martin > >> Currently we (FB) need to backport two NIC drivers. I've already gave >> details of backporting mlx5 on the thread to restructure the driver >> directories. The other driver being backporting seems to suffer from >> the same type of feature complexity. >> >> In short, I would like to ask if driver maintainers to start to >> modularize driver features. If something being added is obviously a >> narrow feature that only a subset of users will need can we allow >> config options to #ifdef those out somehow? Furthermore can the file >> and directory structure of drivers reflect that; our lives would be >> _so_ much simpler to maintain drivers in production if we have such >> modularity and the ability to build drivers with the features of our >> choosing. >> >> Thanks, >> Tom
Re: [PATCH net-next] fq_codel: Avoid regenerating skb flow hash unless necessary
From: Andrew Collins Date: Wed, 18 Jan 2017 14:04:28 -0700 > The fq_codel qdisc currently always regenerates the skb flow hash. > This wastes some cycles and prevents flow seperation in cases where > the traffic has been encrypted and can no longer be understood by the > flow dissector. > > Change it to use the prexisting flow hash if one exists, and only > regenerate if necessary. > > Signed-off-by: Andrew Collins Applied, thanks.
Re: [net PATCH] bpf: fix samples xdp_tx_iptunnel and tc_l2_redirect with fake KBUILD_MODNAME
From: Jesper Dangaard Brouer
Date: Wed, 18 Jan 2017 17:19:00 +0100
> Fix build errors for samples/bpf xdp_tx_iptunnel and tc_l2_redirect,
> when dynamic debugging is enabled (CONFIG_DYNAMIC_DEBUG) by defining a
> fake KBUILD_MODNAME.
>
> Just like Daniel Borkmann fixed other samples/bpf in commit
> 96a8eb1eeed2 ("bpf: fix samples to add fake KBUILD_MODNAME").
>
> Fixes: 12d8bb64e3f6 ("bpf: xdp: Add XDP example for head adjustment")
> Fixes: 90e02896f1a4 ("bpf: Add test for bpf_redirect to ipip/ip6tnl")
> Signed-off-by: Jesper Dangaard Brouer
Applied, thanks Jesper.
Re: [PATCH] net: qcom/emac: claim the irq only when the device is opened
From: Timur Tabi Date: Wed, 18 Jan 2017 15:42:25 -0600 > During reset, functions emac_mac_down() and emac_mac_up() are called, > so we don't want to free and claim the IRQ unnecessarily. Move those > operations to open/close. > > Signed-off-by: Timur Tabi If you don't tell me what tree this is against in your Subject line, I have to guess. I don't like guessing.
Re: [net-next 0/4] tipc: emulate multicast through replication
From: Jon Maloy
Date: Wed, 18 Jan 2017 13:50:49 -0500
> TIPC multicast messages are currently distributed via L2 broadcast
> or IP multicast to all nodes in the cluster, irrespective of the
> number of real destinations of the message.
>
> In this series we introduce an option to transport messages via
> replication ("replicast") across a selected number of unicast links,
> instead of relying on the underlying media. This option is used when
> true broadcast/multicast is not supported by the media, or when the
> number of true destinations is much smaller than the cluster size.
Series applied, thanks Jon.
Re: [PATCH] net: qcom/emac: claim the irq only when the device is opened
On 01/20/2017 11:19 AM, David Miller wrote: If you don't tell me what tree this is against in your Subject line, I have to guess. I don't like guessing. Sorry, this is for net-next. I will specify the target tree in all future patches. -- Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
Re: [PATCH next 0/3] use netdev_is_rx_handler_busy() in few known cases
From: Mahesh Bandewar Date: Wed, 18 Jan 2017 15:02:45 -0800 > netdev_rx_handler_register() was recently split into two parts - (a) check > if the handler is used, (b) register the new handler, parts. This is > helpful in scenarios like bonding where at the time of registration there > is too much state to unwind and it should check if the device is free > before building that state. IPvlan and macvlan drivers don't have this > issue however it can make use of the same check instead of using a device > specific check. Looks good, series applied, thanks.
Re: [PATCH iproute2 0/2] two small fixes in flower option parser error flow
On Thu, 19 Jan 2017 14:31:18 +0200 Roi Dayan wrote: > Hi, > > the first adds a missing return check and the second removes > an incorrect error msg. > > Thanks, > Roi > > > Roi Dayan (2): > tc: flower: Add missing err check when parsing flower options > tc: flower: Fix incorrect error msg about eth type > > tc/f_flower.c | 11 +-- > 1 files changed, 5 insertions(+), 6 deletions(-) > Both applied
Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
Hi Vvien and Andrew,
On ven., janv. 20 2017, Andrew Lunn wrote:
> On Thu, Jan 19, 2017 at 05:26:03PM -0500, Vivien Didelot wrote:
>> Gregory CLEMENT writes:
>>
>> > +static bool mv88e6xxx_6341_family(struct mv88e6xxx_chip *chip)
>> > +{
>> > + return chip->info->family == MV88E6XXX_FAMILY_6341;
>> > +}
>>
>> I don't want to see these erronous family checks anymore, but I cannot
>> blame you for adding it since not all the code is moved to ops yet ;)
If there a series about to be merged I can rebase my series on it. Else
I propose to keep it and convert the family check to ops when you will
send the series for it.
>>
>> >MV88E6XXX_FAMILY_6165, /* 6123 6161 6165 */
>> >MV88E6XXX_FAMILY_6185, /* 6108 6121 6122 6131 6152 6155 6182 6185 */
>> >MV88E6XXX_FAMILY_6320, /* 6320 6321 */
>> > + MV88E6XXX_FAMILY_6341, /* 6141 6341 */
>>
>> Maybe I missed it, Andrew, can you confirm that 6341 is a proper Marvell
>> family of switch chips?
>
> My understand is that it is. Marvell have not added it to DSDT. There
> is a new SDK called UMSD, also GPLv2 and BSD. They call this family
> Topaz, and the 6390 is Peridot.
I confirm that 6141 and 6341 are called Topaz. Actually I can add the
support for the 6141 too, it is just a matter of adding an ID and maybe
removing some ops as 6141 is a subset of 6341.
Gregory
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
Re: [PATCH iproute2 net-next v2] tc: m_csum: add support for SCTP checksum
On Fri, 20 Jan 2017 11:10:10 +0100 Davide Caratti wrote: > 'sctp' parameter can now be used as 'csum' target to enable CRC32c > computation on SCTP packets. > > Signed-off-by: Davide Caratti Applied to net-next
Re: [PATCH net-next] fq_codel: Avoid regenerating skb flow hash unless necessary
On Fri, 2017-01-20 at 09:23 -0800, Tom Herbert wrote: > So the perturbing of the hash is no longer needed for fq_codel? Right, we never implemented a timer to change the perturbation anyway. Note that local TCP flows now implement their own hash change when needed.
Re: [PATCH v5 2/2] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
Hi Gregory, Gregory CLEMENT writes: > If there a series about to be merged I can rebase my series on it. Else > I propose to keep it and convert the family check to ops when you will > send the series for it. I am reworking the VTU operations, but not these port operations yet. I will take care of converting the family checks once I'm done, don't worry ;) > I confirm that 6141 and 6341 are called Topaz. Actually I can add the > support for the 6141 too, it is just a matter of adding an ID and maybe > removing some ops as 6141 is a subset of 6341. I don't mind having a patch adding support for only one chip at a time, that is up to you. Thanks, Vivien
Re: [PATCH] ip/xfrm: Fix deleteall when having many policies installed
On Thu, 19 Jan 2017 08:57:56 +0100 Alexander Heinlein wrote: > From 192cf19b3a97871a508ad57ba5893d1719877f13 Mon Sep 17 00:00:00 2001 > From: Alexander Heinlein > Date: Mon, 16 Jan 2017 14:48:25 +0100 > Subject: [PATCH] ip/xfrm: Fix deleteall when having many policies installed > > Fix "Policy buffer overflow" when trying to use deleteall with many > policies installed. > > Signed-off-by: Alexander Heinlein Applied thanks.
