* Re: [PATCH v3 net-next 1/2] net: dsa: lan9303: Add port_fast_age and port_fdb_dump methods
From: Vivien Didelot @ 2017-10-20 13:57 UTC (permalink / raw)
To: Egil Hjelmeland, andrew, f.fainelli, netdev, linux-kernel; +Cc: Egil Hjelmeland
In-Reply-To: <20171020101910.2245-2-privat@egil-hjelmeland.no>
Hi Egil,
Egil Hjelmeland <privat@egil-hjelmeland.no> writes:
> Add DSA method port_fast_age as a step to STP support.
>
> Add low level functions for accessing the lan9303 ALR (Address Logic
> Resolution).
>
> Added DSA method port_fdb_dump
>
> Signed-off-by: Egil Hjelmeland <privat@egil-hjelmeland.no>
Reviewed-by: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
^ permalink raw reply
* [PATCH net-next 3/3] net: stmmac: Prevent infinite loop in get_rx_timestamp_status()
From: Jose Abreu @ 2017-10-20 13:37 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Jose Abreu, David S. Miller, Joao Pinto, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <cover.1508506265.git.joabreu@synopsys.com>
Prevent infinite loop by correctly setting the loop condition to
break when i == 10.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
index e0ef02f..4b286e2 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c
@@ -275,7 +275,7 @@ static int dwmac4_wrback_get_rx_timestamp_status(void *desc, u32 ats)
goto exit;
i++;
- } while ((ret == 1) || (i < 10));
+ } while ((ret == 1) && (i < 10));
if (i == 10)
ret = -EBUSY;
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 2/3] net: stmmac: Fix stmmac_get_rx_hwtstamp()
From: Jose Abreu @ 2017-10-20 13:37 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Jose Abreu, David S. Miller, Joao Pinto, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <cover.1508506265.git.joabreu@synopsys.com>
When using GMAC4 the valid timestamp is from CTX next desc but
we are passing the previous desc to get_rx_timestamp_status()
callback.
Fix this and while at it rework a little bit the function logic.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 13 ++++++-------
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index f7b7906..0d3fd3b 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -473,19 +473,18 @@ static void stmmac_get_rx_hwtstamp(struct stmmac_priv *priv, struct dma_desc *p,
struct dma_desc *np, struct sk_buff *skb)
{
struct skb_shared_hwtstamps *shhwtstamp = NULL;
+ struct dma_desc *desc = p;
u64 ns;
if (!priv->hwts_rx_en)
return;
+ /* For GMAC4, the valid timestamp is from CTX next desc. */
+ if (priv->plat->has_gmac4)
+ desc = np;
/* Check if timestamp is available */
- if (priv->hw->desc->get_rx_timestamp_status(p, priv->adv_ts)) {
- /* For GMAC4, the valid timestamp is from CTX next desc. */
- if (priv->plat->has_gmac4)
- ns = priv->hw->desc->get_timestamp(np, priv->adv_ts);
- else
- ns = priv->hw->desc->get_timestamp(p, priv->adv_ts);
-
+ if (priv->hw->desc->get_rx_timestamp_status(desc, priv->adv_ts)) {
+ ns = priv->hw->desc->get_timestamp(desc, priv->adv_ts);
netdev_dbg(priv->dev, "get valid RX hw timestamp %llu\n", ns);
shhwtstamp = skb_hwtstamps(skb);
memset(shhwtstamp, 0, sizeof(struct skb_shared_hwtstamps));
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 1/3] net: stmmac: Add missing call to dev_kfree_skb()
From: Jose Abreu @ 2017-10-20 13:37 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Jose Abreu, David S. Miller, Joao Pinto, Giuseppe Cavallaro,
Alexandre Torgue
In-Reply-To: <cover.1508506265.git.joabreu@synopsys.com>
When RX HW timestamp is enabled and a frame is discarded we are
not freeing the skb but instead only setting to NULL the entry.
Add a call to dev_kfree_skb_any() so that skb entry is correctly
freed.
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 0e1b0a3..f7b7906 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3358,6 +3358,7 @@ static int stmmac_rx(struct stmmac_priv *priv, int limit, u32 queue)
* them in stmmac_rx_refill() function so that
* device can reuse it.
*/
+ dev_kfree_skb_any(rx_q->rx_skbuff[entry]);
rx_q->rx_skbuff[entry] = NULL;
dma_unmap_single(priv->device,
rx_q->rx_skbuff_dma[entry],
--
1.9.1
^ permalink raw reply related
* [PATCH net-next 0/3] net: stmmac: Fix HW timestamping
From: Jose Abreu @ 2017-10-20 13:37 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: Jose Abreu, David S. Miller, Joao Pinto, Giuseppe Cavallaro,
Alexandre Torgue
Hi,
Three fixes for HW timestamping feature, all of them for RX side.
Best regards,
Jose Miguel Abreu
David,
I'm targeting this for -next but teel free to apply this in
your -fixes tree if you think its needed. Though, I don't
think anyone is using HW timestamping because these bugs would
appear immediatly.
Cc: David S. Miller <davem@davemloft.net>
Cc: Joao Pinto <jpinto@synopsys.com>
Cc: Giuseppe Cavallaro <peppe.cavallaro@st.com>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Jose Abreu (3):
net: stmmac: Add missing call to dev_kfree_skb()
net: stmmac: Fix stmmac_get_rx_hwtstamp()
net: stmmac: Prevent infinite loop in get_rx_timestamp_status()
drivers/net/ethernet/stmicro/stmmac/dwmac4_descs.c | 2 +-
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 14 +++++++-------
2 files changed, 8 insertions(+), 8 deletions(-)
--
1.9.1
^ permalink raw reply
* Re: [RFC PATCH 3/5] sctp: Add LSM hooks
From: Xin Long @ 2017-10-20 13:14 UTC (permalink / raw)
To: Richard Haines
Cc: Neil Horman, selinux, network dev, linux-sctp,
linux-security-module
In-Reply-To: <1508501095.8370.7.camel@btinternet.com>
On Fri, Oct 20, 2017 at 8:04 PM, Richard Haines
<richard_c_haines@btinternet.com> wrote:
> On Fri, 2017-10-20 at 07:16 -0400, Neil Horman wrote:
>> On Wed, Oct 18, 2017 at 11:05:09PM +0800, Xin Long wrote:
>> > On Tue, Oct 17, 2017 at 9:58 PM, Richard Haines
>> > <richard_c_haines@btinternet.com> wrote:
>> > > Add security hooks to allow security modules to exercise access
>> > > control
>> > > over SCTP.
>> > >
>> > > Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
>> > > ---
>> > > include/net/sctp/structs.h | 10 ++++++++
>> > > include/uapi/linux/sctp.h | 1 +
>> > > net/sctp/sm_make_chunk.c | 12 +++++++++
>> > > net/sctp/sm_statefuns.c | 14 ++++++++++-
>> > > net/sctp/socket.c | 61
>> > > +++++++++++++++++++++++++++++++++++++++++++++-
>> > > 5 files changed, 96 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/include/net/sctp/structs.h
>> > > b/include/net/sctp/structs.h
>> > > index 7767577..6e72e3e 100644
>> > > --- a/include/net/sctp/structs.h
>> > > +++ b/include/net/sctp/structs.h
>> > > @@ -1270,6 +1270,16 @@ struct sctp_endpoint {
>> > > reconf_enable:1;
>> > >
>> > > __u8 strreset_enable;
>> > > +
>> > > + /* Security identifiers from incoming (INIT). These are
>> > > set by
>> > > + * security_sctp_assoc_request(). These will only be used
>> > > by
>> > > + * SCTP TCP type sockets and peeled off connections as
>> > > they
>> > > + * cause a new socket to be generated.
>> > > security_sctp_sk_clone()
>> > > + * will then plug these into the new socket.
>> > > + */
>> > > +
>> > > + u32 secid;
>> > > + u32 peer_secid;
>> > > };
>> > >
>> > > /* Recover the outter endpoint structure. */
>> > > diff --git a/include/uapi/linux/sctp.h
>> > > b/include/uapi/linux/sctp.h
>> > > index 6217ff8..c04812f 100644
>> > > --- a/include/uapi/linux/sctp.h
>> > > +++ b/include/uapi/linux/sctp.h
>> > > @@ -122,6 +122,7 @@ typedef __s32 sctp_assoc_t;
>> > > #define SCTP_RESET_ASSOC 120
>> > > #define SCTP_ADD_STREAMS 121
>> > > #define SCTP_SOCKOPT_PEELOFF_FLAGS 122
>> > > +#define SCTP_SENDMSG_CONNECT 123
>> > >
>> > > /* PR-SCTP policies */
>> > > #define SCTP_PR_SCTP_NONE 0x0000
>> > > diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
>> > > index 6110447..ca4705b 100644
>> > > --- a/net/sctp/sm_make_chunk.c
>> > > +++ b/net/sctp/sm_make_chunk.c
>> > > @@ -3059,6 +3059,12 @@ static __be16
>> > > sctp_process_asconf_param(struct sctp_association *asoc,
>> > > if (af->is_any(&addr))
>> > > memcpy(&addr, &asconf->source,
>> > > sizeof(addr));
>> > >
>> > > + if (security_sctp_bind_connect(asoc->ep->base.sk,
>> > > + SCTP_PARAM_ADD_IP,
>> > > + (struct sockaddr
>> > > *)&addr,
>> > > + af->sockaddr_len))
>> > > + return SCTP_ERROR_REQ_REFUSED;
>> > > +
>> > > /* ADDIP 4.3 D9) If an endpoint receives an ADD
>> > > IP address
>> > > * request and does not have the local resources
>> > > to add this
>> > > * new address to the association, it MUST return
>> > > an Error
>> > > @@ -3125,6 +3131,12 @@ static __be16
>> > > sctp_process_asconf_param(struct sctp_association *asoc,
>> > > if (af->is_any(&addr))
>> > > memcpy(&addr.v4, sctp_source(asconf),
>> > > sizeof(addr));
>> > >
>> > > + if (security_sctp_bind_connect(asoc->ep->base.sk,
>> > > + SCTP_PARAM_SET_PRI
>> > > MARY,
>> > > + (struct sockaddr
>> > > *)&addr,
>> > > + af->sockaddr_len))
>> > > + return SCTP_ERROR_REQ_REFUSED;
>> > > +
>> > > peer = sctp_assoc_lookup_paddr(asoc, &addr);
>> > > if (!peer)
>> > > return SCTP_ERROR_DNS_FAILED;
>> > > diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>> > > index b2a74c3..4ba5805 100644
>> > > --- a/net/sctp/sm_statefuns.c
>> > > +++ b/net/sctp/sm_statefuns.c
>> > > @@ -314,6 +314,11 @@ sctp_disposition_t
>> > > sctp_sf_do_5_1B_init(struct net *net,
>> > > sctp_unrecognized_param_t *unk_param;
>> > > int len;
>> > >
>> > > + /* Update socket peer label if first association. */
>> > > + if (security_sctp_assoc_request((struct sctp_endpoint
>> > > *)ep,
>> > > + chunk->skb,
>> > > SCTP_CID_INIT))
>> > > + return sctp_sf_pdiscard(net, ep, asoc, type, arg,
>> > > commands);
>> > > +
>> > > /* 6.10 Bundling
>> > > * An endpoint MUST NOT bundle INIT, INIT ACK or
>> > > * SHUTDOWN COMPLETE with any other chunks.
>> > > @@ -446,7 +451,6 @@ sctp_disposition_t
>> > > sctp_sf_do_5_1B_init(struct net *net,
>> > > }
>> > >
>> > > sctp_add_cmd_sf(commands, SCTP_CMD_NEW_ASOC,
>> > > SCTP_ASOC(new_asoc));
>> > > -
>> > > sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
>> > > SCTP_CHUNK(repl));
>> > >
>> > > /*
>> > > @@ -507,6 +511,11 @@ sctp_disposition_t
>> > > sctp_sf_do_5_1C_ack(struct net *net,
>> > > struct sctp_chunk *err_chunk;
>> > > struct sctp_packet *packet;
>> > >
>> > > + /* Update socket peer label if first association. */
>> > > + if (security_sctp_assoc_request((struct sctp_endpoint
>> > > *)ep,
>> > > + chunk->skb,
>> > > SCTP_CID_INIT_ACK))
>> > > + return sctp_sf_pdiscard(net, ep, asoc, type, arg,
>> > > commands);
>> > > +
>> >
>> > Just thinking security_sctp_assoc_request hook should also be in
>> > sctp_sf_do_unexpected_init() and sctp_sf_do_5_2_4_dupcook() ?
>>
>> I agree, i think if this hook is gating on the creation of a new
>> association,
>> they should be in all the locations where that happens
>> Neil
>
> Thanks for the comments. I've just added the hook as requested for my
> next update, however I have not managed to trigger these areas using
> the lksctp-tools tests. Can you suggest any suitable tools for testing
> these scenarios.
It's all a matter of timing:
sctp_sf_do_5_2_2_dupinit():
Case A:
Endpoint A Endpoint B ULP
(CLOSED) (CLOSED)
INIT ----------------->
<----------------- INIT-ACK
COOKIE-ECHO ----------------->
<----------------- COOKIE-ACK
Communication Up ---------->
INIT ----------------->
(Different INIT-TAG)
<----------------- INIT-ACK
COOKIE-ECHO ----------------->
<----------------- COOKIE-ACK
DATA ----------------->
<----------------- SACK
sctp_sf_do_5_2_1_siminit():
Case B:
Endpoint A Endpoint B ULP
(CLOSED) (CLOSED)
<----- Associate
<----------------- INIT
INIT ----------------->
<----------------- INIT-ACK
COOKIE-ECHO ----------------->
<----------------- COOKIE-ACK
Communication Up ---------->
sctp_sf_do_5_2_4_dupcook():
Case D:
Endpoint A Endpoint B ULP
(CLOSED) (CLOSED)
<----- Associate
INIT ----------------->
<----------------- INIT-ACK
COOKIE-ECHO ----------------->
<----------------- COOKIE-ACK
Communication Up ---------->
COOKIE-ECHO ----------------->
<----------------- COOKIE-ACK
I think scapy could help with 4-shake stuff:
# iptables -A OUTPUT -p sctp -d 192.0.0.2 --chunk-type only abort -o
eth1 -j DROP
and
something like:
def start_assoc(self, target, local):
target_host, target_port = target
local_host, local_port = local
# init snd
self._tsn = 2017
self._cnt = 15
SCTP_HEADER = (IP(dst=target_host, flags="DF") /
SCTP(sport=local_port, dport=target_port, tag=0))
INIT = (SCTP_HEADER / SCTPChunkInit(init_tag=1,
a_rwnd=106496, n_out_streams=self._cnt, n_in_streams=self._cnt,
init_tsn=self._tsn,
params=[SCTPParamSupport(types=[64])]))
INIT_ACK = sr1(INIT, timeout=3, verbose=0)
if INIT_ACK == None or not INIT_ACK.haslayer(SCTPChunkInitAck):
return False
# cookie echo snd
SCTP_HEADER[SCTP].tag = INIT_ACK[SCTPChunkInitAck].init_tag
COOKIE_ECHO = (SCTP_HEADER /
SCTPChunkCookieEcho(cookie=INIT_ACK[SCTPChunkParamStateCookie].cookie))
COOKIE_ACK = sr1(COOKIE_ECHO, timeout=3, verbose=0)
if COOKIE_ACK == None or not
COOKIE_ACK.haslayer(SCTPChunkCookieAck):
return False
^ permalink raw reply
* Re: [PATCH net-next v2 1/6] devlink: Add permanent config parameter get/set operations
From: Steve Lin @ 2017-10-20 13:11 UTC (permalink / raw)
To: Yuval Mintz
Cc: netdev@vger.kernel.org, Jiri Pirko, davem@davemloft.net,
michael.chan@broadcom.com, linville@tuxdriver.com,
gospo@broadcom.com
In-Reply-To: <AM0PR0502MB3683FB1536D1A204E5D1369EBF420@AM0PR0502MB3683.eurprd05.prod.outlook.com>
On Thu, Oct 19, 2017 at 4:21 PM, Yuval Mintz <yuvalm@mellanox.com> wrote:
>> Subject: [PATCH net-next v2 1/6] devlink: Add permanent config parameter
>> get/set operations
>>
>> Add support for permanent config parameter get/set commands. Used
>> for parameters held in NVRAM, persistent device configuration.
>
> Given some of the attributes aren't Boolean, what about an API that
> allows the user to learn of supported values per option?
> Otherwise only way for configuring some of them would be trial & error.
Interesting suggestion. There's a couple of places where this could
be a factor. (1) When a user wants to know what values are
defined/available in the API, and (2) When the user wants to know what
values are supported by a specific driver/device.
The intention for (1) is to push that into userspace. The userspace
devlink tool patches I am working on (not yet submitted) essentially
mirror the config parameters and their options, with string "keywords"
associated with each parameter and option, since it's the userspace
app that will be parsing the command line strings and converting to
API enums. So the userspace app can provide the list of
parameters/options it supports, which could be a subset of what's
available in the API.
For (2), currently there is no mechanism other than trial/error as you
suggest (up to driver to either return an error or else make use of
the value specified by the user). We could contemplate adding such a
mechanism, but it's a little complicated as some options take a range
(i.e. # of VFs per PF for example), and others may take one of a set
of enumerated values (pre-boot link speed for example).
To clarify, are you suggesting some mechanism to allow a driver to
report which parameters and options it supports (case (2))? Or are
you suggesting something in the kernel API to handle case (1) above?
>
>>
>> Signed-off-by: Steve Lin <steven.lin1@broadcom.com>
>> Acked-by: Andy Gospodarek <gospo@broadcom.com>
>> ---
>> include/net/devlink.h | 3 +
>> include/uapi/linux/devlink.h | 11 ++
>> net/core/devlink.c | 234
>> +++++++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 248 insertions(+)
>>
>> diff --git a/include/net/devlink.h b/include/net/devlink.h
>> index b9654e1..bd64623 100644
>> --- a/include/net/devlink.h
>> +++ b/include/net/devlink.h
>> @@ -270,6 +270,9 @@ struct devlink_ops {
>> int (*eswitch_inline_mode_set)(struct devlink *devlink, u8
>> inline_mode);
>> int (*eswitch_encap_mode_get)(struct devlink *devlink, u8
>> *p_encap_mode);
>> int (*eswitch_encap_mode_set)(struct devlink *devlink, u8
>> encap_mode);
>> + int (*perm_config_get)(struct devlink *devlink, u32 param, u32
>> *value);
>> + int (*perm_config_set)(struct devlink *devlink, u32 param, u32
>> value,
>> + u8 *restart_reqd);
>> };
>>
>> static inline void *devlink_priv(struct devlink *devlink)
>> diff --git a/include/uapi/linux/devlink.h b/include/uapi/linux/devlink.h
>> index 0cbca96..47cc584 100644
>> --- a/include/uapi/linux/devlink.h
>> +++ b/include/uapi/linux/devlink.h
>> @@ -70,6 +70,10 @@ enum devlink_command {
>> DEVLINK_CMD_DPIPE_HEADERS_GET,
>> DEVLINK_CMD_DPIPE_TABLE_COUNTERS_SET,
>>
>> + /* Permanent (NVRAM) device config get/set */
>> + DEVLINK_CMD_PERM_CONFIG_GET,
>> + DEVLINK_CMD_PERM_CONFIG_SET,
>> +
>> /* add new commands above here */
>> __DEVLINK_CMD_MAX,
>> DEVLINK_CMD_MAX = __DEVLINK_CMD_MAX - 1
>> @@ -202,6 +206,13 @@ enum devlink_attr {
>>
>> DEVLINK_ATTR_ESWITCH_ENCAP_MODE, /* u8 */
>>
>> + /* Permanent Configuration Parameters */
>> + DEVLINK_ATTR_PERM_CONFIGS, /* nested */
>> + DEVLINK_ATTR_PERM_CONFIG, /* nested */
>> + DEVLINK_ATTR_PERM_CONFIG_PARAMETER, /* u32 */
>> + DEVLINK_ATTR_PERM_CONFIG_VALUE, /*
>> u32 */
>> + DEVLINK_ATTR_PERM_CONFIG_RESTART_REQUIRED, /* u8 */
>> +
>> /* add new attributes above here, update the policy in devlink.c */
>>
>> __DEVLINK_ATTR_MAX,
>> diff --git a/net/core/devlink.c b/net/core/devlink.c
>> index 7d430c1..c2cc7c6 100644
>> --- a/net/core/devlink.c
>> +++ b/net/core/devlink.c
>> @@ -1566,6 +1566,224 @@ static int
>> devlink_nl_cmd_eswitch_set_doit(struct sk_buff *skb,
>> return 0;
>> }
>>
>> +static const struct nla_policy devlink_nl_policy[DEVLINK_ATTR_MAX + 1];
>> +
>> +static int devlink_nl_single_param_get(struct sk_buff *msg,
>> + struct devlink *devlink,
>> + uint32_t param)
>> +{
>> + u32 value;
>> + int err;
>> + const struct devlink_ops *ops = devlink->ops;
>> + struct nlattr *param_attr;
>> +
>> + err = ops->perm_config_get(devlink, param, &value);
>> + if (err)
>> + return err;
>> +
>> + param_attr = nla_nest_start(msg, DEVLINK_ATTR_PERM_CONFIG);
>> + nla_put_u32(msg, DEVLINK_ATTR_PERM_CONFIG_PARAMETER,
>> param);
>> + nla_put_u32(msg, DEVLINK_ATTR_PERM_CONFIG_VALUE, value);
>> + nla_nest_end(msg, param_attr);
>> +
>> + return 0;
>> +}
>> +
>> +static int devlink_nl_config_get_fill(struct sk_buff *msg,
>> + struct devlink *devlink,
>> + enum devlink_command cmd,
>> + struct genl_info *info)
>> +{
>> + void *hdr;
>> + int err;
>> + struct nlattr *attr;
>> + int param_count = 0;
>> + struct nlattr *cfgparam_attr;
>> + int rem;
>> + struct nlattr *tb[DEVLINK_ATTR_MAX + 1];
>> + u32 param;
>> +
>> + hdr = genlmsg_put(msg, info->snd_portid, info->snd_seq,
>> + &devlink_nl_family, 0, cmd);
>> + if (!hdr) {
>> + err = -EMSGSIZE;
>> + goto nla_msg_failure;
>> + }
>> +
>> + err = devlink_nl_put_handle(msg, devlink);
>> + if (err)
>> + goto nla_put_failure;
>> +
>> + if (!info->attrs[DEVLINK_ATTR_PERM_CONFIGS]) {
>> + /* No configuration parameters */
>> + goto nla_put_failure;
>> + }
>> +
>> + cfgparam_attr = nla_nest_start(msg,
>> DEVLINK_ATTR_PERM_CONFIGS);
>> +
>> + nla_for_each_nested(attr, info-
>> >attrs[DEVLINK_ATTR_PERM_CONFIGS],
>> + rem) {
> Isn't it possible that a response for a single request for multiple ATTRs
> wouldn't fit in a single message?
>
Hmm... Given the small size and relatively small total number of these
attributes, even when additional drivers add their own, I think it's
unlikely that a single request would require a multipart message, even
in the event it's requesting all of the parameters for a given device.
I guess we could support NLM_F_MULTI type messages, but it didn't seem
necessary to me for this application? Thoughts?
>> + if (err)
>> + goto nla_nest_failure;
>> + param_count++;
>
> Looks like an unused parameter
>> +
>> + if (restart_reqd) {
>
> Doesn't seem like you're ever setting it.
> A leftover from when this was an attribute of the configs instead
> of per-config perhaps?
Thanks for catching these two issues - you're right, they are leftover
from the v1 implementation; apologies for not catching them in v2.
Will fix in v3.
^ permalink raw reply
* Re: [PATCH] net: ethtool: remove error check for legacy setting transceiver type
From: Niklas Söderlund @ 2017-10-20 13:03 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: David S. Miller, Florian Fainelli, netdev@vger.kernel.org,
Linux-Renesas, Renjith R V
In-Reply-To: <CAMuHMdUFHP-nmft72q7_ZGqqUzuOoj0q+6+fyfQF-XkfnFpLvA@mail.gmail.com>
Hi Geert,
On 2017-10-20 09:15:50 +0200, Geert Uytterhoeven wrote:
> Hi Niklas,
>
> On Fri, Oct 20, 2017 at 1:32 AM, Niklas Söderlund
> <niklas.soderlund+renesas@ragnatech.se> wrote:
> > Commit 9cab88726929605 ("net: ethtool: Add back transceiver type")
> > restores the transceiver type to struct ethtool_link_settings and
> > convert_link_ksettings_to_legacy_settings() but forgets to remove the
> > error check for the same in convert_legacy_settings_to_link_ksettings().
> > This prevents older versions of ethtool to change link settings.
> >
> > # ethtool --version
> > ethtool version 3.16
> >
> > # ethtool -s eth0 autoneg on speed 100 duplex full
> > Cannot set new settings: Invalid argument
> > not setting speed
> > not setting duplex
> > not setting autoneg
> >
> > While newer versions of ethtool works.
> >
> > # ethtool --version
> > ethtool version 4.10
> >
> > # ethtool -s eth0 autoneg on speed 100 duplex full
> > [ 57.703268] sh-eth ee700000.ethernet eth0: Link is Down
> > [ 59.618227] sh-eth ee700000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
> >
> > Fixes: 19cab88726929605 ("net: ethtool: Add back transceiver type")
>
> Thanks for your patch!
>
> Reported-by: Renjith R V <renjith.rv@quest-global.com>
>
> > Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
>
> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be>
>
> While this fixed ethtool, unfortunately this revealed another issue: several
> drivers call phy_ethtool_ksettings_set() while holding a driver-specific
> spinlock, which leads to phy_start_aneg_priv() calling mutex_lock() with
> interrupts disabled.
This seems to be a old issue, I can reproduce it on v4.2, releases
earlier than that is problematic for me to compile using gcc7 so I gave
up. I don't know if this ever worked without triggering the BUG but it
is present at least from v4.2.
>
> Backtrace for sh_eth:
>
> BUG: sleeping function called from invalid context at kernel/locking/mutex.c:238
> [ 161.636382] in_atomic(): 1, irqs_disabled(): 128, pid: 1684, name: ethtool
> [ 161.643260] CPU: 1 PID: 1684 Comm: ethtool Not tainted
> 4.14.0-rc5-koelsch-00441-g8545ae86337930b0 #3649
> [ 161.652653] Hardware name: Generic R-Car Gen2 (Flattened Device Tree)
> [ 161.659109] [<c020efe4>] (unwind_backtrace) from [<c020aa5c>]
> (show_stack+0x10/0x14)
> [ 161.666859] [<c020aa5c>] (show_stack) from [<c0723444>]
> (dump_stack+0x7c/0x9c)
> [ 161.674090] [<c0723444>] (dump_stack) from [<c023f760>]
> (___might_sleep+0x128/0x164)
> [ 161.681841] [<c023f760>] (___might_sleep) from [<c073894c>]
> (mutex_lock+0x18/0x60)
> [ 161.689418] [<c073894c>] (mutex_lock) from [<c0537c60>]
> (phy_start_aneg_priv+0x28/0x120)
> [ 161.697513] [<c0537c60>] (phy_start_aneg_priv) from [<c0537ee4>]
> (phy_ethtool_ksettings_set+0xc0/0xcc)
> [ 161.706824] [<c0537ee4>] (phy_ethtool_ksettings_set) from
> [<c053fe58>] (sh_eth_set_link_ksettings+0x3c/0xa8)
> [ 161.716657] [<c053fe58>] (sh_eth_set_link_ksettings) from
> [<c0676f88>] (ethtool_set_settings+0x100/0x114)
> [ 161.726229] [<c0676f88>] (ethtool_set_settings) from [<c0679ea0>]
> (dev_ethtool+0x400/0x2248)
> [ 161.734672] [<c0679ea0>] (dev_ethtool) from [<c068f850>]
> (dev_ioctl+0x424/0x774)
> [ 161.742074] [<c068f850>] (dev_ioctl) from [<c02f9a24>] (vfs_ioctl+0x20/0x34)
> [ 161.749128] [<c02f9a24>] (vfs_ioctl) from [<c02fa1f0>]
> (do_vfs_ioctl+0x6b4/0x7b8)
> [ 161.756616] [<c02fa1f0>] (do_vfs_ioctl) from [<c02fa328>]
> (SyS_ioctl+0x34/0x5c)
> [ 161.763930] [<c02fa328>] (SyS_ioctl) from [<c0206e60>]
> (ret_fast_syscall+0x0/0x40)
>
> There's a similar dump for ravb.
>
> I quick grep shows that at least the Broadcom B44 driver is also affected.
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
--
Regards,
Niklas Söderlund
^ permalink raw reply
* [net-next:master 299/330] include/net/sock.h:348:36: error: 'struct sock_common' has no member named 'skc_v6_rcv_saddr'; did you mean 'skc_rcv_saddr'?
From: kbuild test robot @ 2017-10-20 12:40 UTC (permalink / raw)
To: David Ahern; +Cc: kbuild-all, netdev
[-- Attachment #1: Type: text/plain, Size: 13609 bytes --]
Hi David,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git master
head: aec72f3392b1d598a979e89c4fdb131965ae0ab3
commit: 386fd5da401dc6c4b0ab6a54d333609876b699fe [299/330] tcp: Check daddr_cache before use in tracepoint
config: x86_64-kexec (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 386fd5da401dc6c4b0ab6a54d333609876b699fe
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
In file included from include/trace/define_trace.h:95:0,
from include/trace/events/tcp.h:68,
from net/core/net-traces.c:34:
include/trace/events/tcp.h: In function 'trace_event_raw_event_tcp_retransmit_skb':
>> include/net/sock.h:348:36: error: 'struct sock_common' has no member named 'skc_v6_rcv_saddr'; did you mean 'skc_rcv_saddr'?
#define sk_v6_rcv_saddr __sk_common.skc_v6_rcv_saddr
^
include/trace/trace_events.h:718:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~~~~~
include/trace/trace_events.h:77:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~~~~~
include/trace/events/tcp.h:12:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(tcp_retransmit_skb,
^~~~~~~~~~~
include/trace/events/tcp.h:29:2: note: in expansion of macro 'TP_fast_assign'
TP_fast_assign(
^~~~~~~~~~~~~~
include/trace/events/tcp.h:49:16: note: in expansion of macro 'sk_v6_rcv_saddr'
*pin6 = sk->sk_v6_rcv_saddr;
^~~~~~~~~~~~~~~
>> include/net/sock.h:347:33: error: 'struct sock_common' has no member named 'skc_v6_daddr'; did you mean 'skc_daddr'?
#define sk_v6_daddr __sk_common.skc_v6_daddr
^
include/trace/trace_events.h:718:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~~~~~
include/trace/trace_events.h:77:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~~~~~
include/trace/events/tcp.h:12:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(tcp_retransmit_skb,
^~~~~~~~~~~
include/trace/events/tcp.h:29:2: note: in expansion of macro 'TP_fast_assign'
TP_fast_assign(
^~~~~~~~~~~~~~
include/trace/events/tcp.h:51:16: note: in expansion of macro 'sk_v6_daddr'
*pin6 = sk->sk_v6_daddr;
^~~~~~~~~~~
In file included from include/trace/define_trace.h:96:0,
from include/trace/events/tcp.h:68,
from net/core/net-traces.c:34:
include/trace/events/tcp.h: In function 'perf_trace_tcp_retransmit_skb':
>> include/net/sock.h:348:36: error: 'struct sock_common' has no member named 'skc_v6_rcv_saddr'; did you mean 'skc_rcv_saddr'?
#define sk_v6_rcv_saddr __sk_common.skc_v6_rcv_saddr
^
include/trace/perf.h:65:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~~~~~
include/trace/trace_events.h:77:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~~~~~
include/trace/events/tcp.h:12:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(tcp_retransmit_skb,
^~~~~~~~~~~
include/trace/events/tcp.h:29:2: note: in expansion of macro 'TP_fast_assign'
TP_fast_assign(
^~~~~~~~~~~~~~
include/trace/events/tcp.h:49:16: note: in expansion of macro 'sk_v6_rcv_saddr'
*pin6 = sk->sk_v6_rcv_saddr;
^~~~~~~~~~~~~~~
>> include/net/sock.h:347:33: error: 'struct sock_common' has no member named 'skc_v6_daddr'; did you mean 'skc_daddr'?
#define sk_v6_daddr __sk_common.skc_v6_daddr
^
include/trace/perf.h:65:4: note: in definition of macro 'DECLARE_EVENT_CLASS'
{ assign; } \
^~~~~~
include/trace/trace_events.h:77:9: note: in expansion of macro 'PARAMS'
PARAMS(assign), \
^~~~~~
include/trace/events/tcp.h:12:1: note: in expansion of macro 'TRACE_EVENT'
TRACE_EVENT(tcp_retransmit_skb,
^~~~~~~~~~~
include/trace/events/tcp.h:29:2: note: in expansion of macro 'TP_fast_assign'
TP_fast_assign(
^~~~~~~~~~~~~~
include/trace/events/tcp.h:51:16: note: in expansion of macro 'sk_v6_daddr'
*pin6 = sk->sk_v6_daddr;
^~~~~~~~~~~
vim +348 include/net/sock.h
4dc6dc716 Eric Dumazet 2009-07-15 327
68835aba4 Eric Dumazet 2010-11-30 328 #define sk_dontcopy_begin __sk_common.skc_dontcopy_begin
68835aba4 Eric Dumazet 2010-11-30 329 #define sk_dontcopy_end __sk_common.skc_dontcopy_end
4dc6dc716 Eric Dumazet 2009-07-15 330 #define sk_hash __sk_common.skc_hash
508054668 Eric Dumazet 2013-10-02 331 #define sk_portpair __sk_common.skc_portpair
05dbc7b59 Eric Dumazet 2013-10-03 332 #define sk_num __sk_common.skc_num
05dbc7b59 Eric Dumazet 2013-10-03 333 #define sk_dport __sk_common.skc_dport
508054668 Eric Dumazet 2013-10-02 334 #define sk_addrpair __sk_common.skc_addrpair
508054668 Eric Dumazet 2013-10-02 335 #define sk_daddr __sk_common.skc_daddr
508054668 Eric Dumazet 2013-10-02 336 #define sk_rcv_saddr __sk_common.skc_rcv_saddr
^1da177e4 Linus Torvalds 2005-04-16 337 #define sk_family __sk_common.skc_family
^1da177e4 Linus Torvalds 2005-04-16 338 #define sk_state __sk_common.skc_state
^1da177e4 Linus Torvalds 2005-04-16 339 #define sk_reuse __sk_common.skc_reuse
055dc21a1 Tom Herbert 2013-01-22 340 #define sk_reuseport __sk_common.skc_reuseport
9fe516ba3 Eric Dumazet 2014-06-27 341 #define sk_ipv6only __sk_common.skc_ipv6only
26abe1437 Eric W. Biederman 2015-05-08 342 #define sk_net_refcnt __sk_common.skc_net_refcnt
^1da177e4 Linus Torvalds 2005-04-16 343 #define sk_bound_dev_if __sk_common.skc_bound_dev_if
^1da177e4 Linus Torvalds 2005-04-16 344 #define sk_bind_node __sk_common.skc_bind_node
8feaf0c0a Arnaldo Carvalho de Melo 2005-08-09 345 #define sk_prot __sk_common.skc_prot
07feaebfc Eric W. Biederman 2007-09-12 346 #define sk_net __sk_common.skc_net
efe4208f4 Eric Dumazet 2013-10-03 @347 #define sk_v6_daddr __sk_common.skc_v6_daddr
efe4208f4 Eric Dumazet 2013-10-03 @348 #define sk_v6_rcv_saddr __sk_common.skc_v6_rcv_saddr
33cf7c90f Eric Dumazet 2015-03-11 349 #define sk_cookie __sk_common.skc_cookie
70da268b5 Eric Dumazet 2015-10-08 350 #define sk_incoming_cpu __sk_common.skc_incoming_cpu
8e5eb54d3 Eric Dumazet 2015-10-08 351 #define sk_flags __sk_common.skc_flags
ed53d0ab7 Eric Dumazet 2015-10-08 352 #define sk_rxhash __sk_common.skc_rxhash
efe4208f4 Eric Dumazet 2013-10-03 353
^1da177e4 Linus Torvalds 2005-04-16 354 socket_lock_t sk_lock;
9115e8cd2 Eric Dumazet 2016-12-03 355 atomic_t sk_drops;
9115e8cd2 Eric Dumazet 2016-12-03 356 int sk_rcvlowat;
9115e8cd2 Eric Dumazet 2016-12-03 357 struct sk_buff_head sk_error_queue;
b178bb3df Eric Dumazet 2010-11-16 358 struct sk_buff_head sk_receive_queue;
fa438ccfd Eric Dumazet 2007-03-04 359 /*
fa438ccfd Eric Dumazet 2007-03-04 360 * The backlog queue is special, it is always used with
fa438ccfd Eric Dumazet 2007-03-04 361 * the per-socket spinlock held and requires low latency
fa438ccfd Eric Dumazet 2007-03-04 362 * access. Therefore we special case it's implementation.
b178bb3df Eric Dumazet 2010-11-16 363 * Note : rmem_alloc is in this structure to fill a hole
b178bb3df Eric Dumazet 2010-11-16 364 * on 64bit arches, not because its logically part of
b178bb3df Eric Dumazet 2010-11-16 365 * backlog.
fa438ccfd Eric Dumazet 2007-03-04 366 */
fa438ccfd Eric Dumazet 2007-03-04 367 struct {
b178bb3df Eric Dumazet 2010-11-16 368 atomic_t rmem_alloc;
b178bb3df Eric Dumazet 2010-11-16 369 int len;
fa438ccfd Eric Dumazet 2007-03-04 370 struct sk_buff *head;
fa438ccfd Eric Dumazet 2007-03-04 371 struct sk_buff *tail;
fa438ccfd Eric Dumazet 2007-03-04 372 } sk_backlog;
b178bb3df Eric Dumazet 2010-11-16 373 #define sk_rmem_alloc sk_backlog.rmem_alloc
2c8c56e15 Eric Dumazet 2014-11-11 374
9115e8cd2 Eric Dumazet 2016-12-03 375 int sk_forward_alloc;
e0d1095ae Cong Wang 2013-08-01 376 #ifdef CONFIG_NET_RX_BUSY_POLL
dafcc4380 Eliezer Tamir 2013-06-14 377 unsigned int sk_ll_usec;
9115e8cd2 Eric Dumazet 2016-12-03 378 /* ===== mostly read cache line ===== */
9115e8cd2 Eric Dumazet 2016-12-03 379 unsigned int sk_napi_id;
060212928 Eliezer Tamir 2013-06-10 380 #endif
b178bb3df Eric Dumazet 2010-11-16 381 int sk_rcvbuf;
b178bb3df Eric Dumazet 2010-11-16 382
b178bb3df Eric Dumazet 2010-11-16 383 struct sk_filter __rcu *sk_filter;
ceb5d58b2 Eric Dumazet 2015-11-29 384 union {
eaefd1105 Eric Dumazet 2011-02-18 385 struct socket_wq __rcu *sk_wq;
ceb5d58b2 Eric Dumazet 2015-11-29 386 struct socket_wq *sk_wq_raw;
ceb5d58b2 Eric Dumazet 2015-11-29 387 };
def8b4faf Alexey Dobriyan 2008-10-28 388 #ifdef CONFIG_XFRM
d188ba86d Eric Dumazet 2015-12-08 389 struct xfrm_policy __rcu *sk_policy[2];
def8b4faf Alexey Dobriyan 2008-10-28 390 #endif
deaa58542 Eric Dumazet 2012-06-24 391 struct dst_entry *sk_rx_dst;
0e36cbb34 Cong Wang 2013-01-22 392 struct dst_entry __rcu *sk_dst_cache;
^1da177e4 Linus Torvalds 2005-04-16 393 atomic_t sk_omem_alloc;
4e07a91c3 Arnaldo Carvalho de Melo 2007-05-29 394 int sk_sndbuf;
9115e8cd2 Eric Dumazet 2016-12-03 395
9115e8cd2 Eric Dumazet 2016-12-03 396 /* ===== cache line for TX ===== */
9115e8cd2 Eric Dumazet 2016-12-03 397 int sk_wmem_queued;
14afee4b6 Reshetova, Elena 2017-06-30 398 refcount_t sk_wmem_alloc;
9115e8cd2 Eric Dumazet 2016-12-03 399 unsigned long sk_tsq_flags;
75c119afe Eric Dumazet 2017-10-05 400 union {
9115e8cd2 Eric Dumazet 2016-12-03 401 struct sk_buff *sk_send_head;
75c119afe Eric Dumazet 2017-10-05 402 struct rb_root tcp_rtx_queue;
75c119afe Eric Dumazet 2017-10-05 403 };
^1da177e4 Linus Torvalds 2005-04-16 404 struct sk_buff_head sk_write_queue;
9115e8cd2 Eric Dumazet 2016-12-03 405 __s32 sk_peek_off;
9115e8cd2 Eric Dumazet 2016-12-03 406 int sk_write_pending;
9b8805a32 Julian Anastasov 2017-02-06 407 __u32 sk_dst_pending_confirm;
218af599f Eric Dumazet 2017-05-16 408 u32 sk_pacing_status; /* see enum sk_pacing */
9115e8cd2 Eric Dumazet 2016-12-03 409 long sk_sndtimeo;
9115e8cd2 Eric Dumazet 2016-12-03 410 struct timer_list sk_timer;
9115e8cd2 Eric Dumazet 2016-12-03 411 __u32 sk_priority;
9115e8cd2 Eric Dumazet 2016-12-03 412 __u32 sk_mark;
9115e8cd2 Eric Dumazet 2016-12-03 413 u32 sk_pacing_rate; /* bytes per second */
9115e8cd2 Eric Dumazet 2016-12-03 414 u32 sk_max_pacing_rate;
9115e8cd2 Eric Dumazet 2016-12-03 415 struct page_frag sk_frag;
9115e8cd2 Eric Dumazet 2016-12-03 416 netdev_features_t sk_route_caps;
9115e8cd2 Eric Dumazet 2016-12-03 417 netdev_features_t sk_route_nocaps;
9115e8cd2 Eric Dumazet 2016-12-03 418 int sk_gso_type;
9115e8cd2 Eric Dumazet 2016-12-03 419 unsigned int sk_gso_max_size;
9115e8cd2 Eric Dumazet 2016-12-03 420 gfp_t sk_allocation;
9115e8cd2 Eric Dumazet 2016-12-03 421 __u32 sk_txhash;
fc64869c4 Andrey Ryabinin 2016-05-18 422
fc64869c4 Andrey Ryabinin 2016-05-18 423 /*
fc64869c4 Andrey Ryabinin 2016-05-18 424 * Because of non atomicity rules, all
fc64869c4 Andrey Ryabinin 2016-05-18 425 * changes are protected by socket lock.
fc64869c4 Andrey Ryabinin 2016-05-18 426 */
aa4c1037a David Ahern 2016-12-01 427 unsigned int __sk_flags_offset[0];
aa4c1037a David Ahern 2016-12-01 428 #ifdef __BIG_ENDIAN_BITFIELD
aa4c1037a David Ahern 2016-12-01 429 #define SK_FL_PROTO_SHIFT 16
aa4c1037a David Ahern 2016-12-01 430 #define SK_FL_PROTO_MASK 0x00ff0000
aa4c1037a David Ahern 2016-12-01 431
:::::: The code at line 348 was first introduced by commit
:::::: efe4208f47f907b86f528788da711e8ab9dea44d ipv6: make lookups simpler and faster
:::::: TO: Eric Dumazet <edumazet@google.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 26265 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v7 0/5] bpf: security: New file mode and LSM hooks for eBPF object permission control
From: David Miller @ 2017-10-20 12:40 UTC (permalink / raw)
To: chenbofeng.kernel
Cc: netdev, Selinux, linux-security-module, jeffv, alexei.starovoitov,
lorenzo, daniel, sds, james.l.morris, paul, fengc
In-Reply-To: <20171018200026.146093-1-chenbofeng.kernel@gmail.com>
Series applied.
^ permalink raw reply
* Re: [PATCH 0/2] 9p: Fixes for hard-to-hit bugs
From: Tuomas Tynkkynen @ 2017-10-20 12:34 UTC (permalink / raw)
To: Al Viro, Linus Torvalds
Cc: v9fs-developer, Eric Van Hensbergen, Ron Minnich,
Latchesar Ionkov, David S. Miller, linux-kernel, netdev,
linux-fsdevel
In-Reply-To: <20170906145908.8082-1-tuomas@tuxera.com>
Al, Linus
Can one of you please pick these patches? They've been on the list for
a month now, with an ack from Latchesar Ionkov.
Thanks!
Tuomas
On Wed, 2017-09-06 at 17:59 +0300, Tuomas Tynkkynen wrote:
> These two patches fix two hard-to-hit (but really annoying) bugs in
> 9p.
> The first one was posted earlier in February (with one R-b), the
> second
> is a new one.
>
> Both of these have had soaking in NixOS distribution kernels for
> a couple of months with no ill effects.
>
> Tuomas Tynkkynen (2):
> fs/9p: Compare qid.path in v9fs_test_inode
> net/9p: Switch to wait_event_killable()
>
> fs/9p/vfs_inode.c | 3 +++
> fs/9p/vfs_inode_dotl.c | 3 +++
> net/9p/client.c | 3 +--
> net/9p/trans_virtio.c | 13 ++++++-------
> net/9p/trans_xen.c | 4 ++--
> 5 files changed, 15 insertions(+), 11 deletions(-)
>
^ permalink raw reply
* Re: [PATCH net-next] net-tun: fix panics at dismantle time
From: David Miller @ 2017-10-20 12:31 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, peterpenkov96, maheshb
In-Reply-To: <1508353929.31614.136.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 18 Oct 2017 12:12:09 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> syzkaller got crashes at dismantle time [1]
>
> It is not correct to test (tun->flags & IFF_NAPI) in tun_napi_disable()
> and tun_napi_del() : Each tun_file can have different mode, depending
> on how they were created.
>
> Similarly I have changed tun_get_user() and tun_poll_controller()
> to use the new tfile->napi_enabled boolean.
...
> Fixes: 943170998b20 ("net-tun: enable NAPI for TUN/TAP driver")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] net: ipv4: Change fib notifiers to take a fib_alias
From: David Miller @ 2017-10-20 12:29 UTC (permalink / raw)
To: dsahern; +Cc: netdev, jiri, idosch
In-Reply-To: <1508351953-26442-1-git-send-email-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Wed, 18 Oct 2017 11:39:13 -0700
> All of the notifier data (fib_info, tos, type and table id) are
> contained in the fib_alias. Pass it to the notifier instead of
> each data separately shortening the argument list by 3.
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] tcp: socket option to set TCP fast open key
From: David Miller @ 2017-10-20 12:29 UTC (permalink / raw)
To: ycheng; +Cc: netdev, cpaasch, edumazet, ncardwell, maheshb
In-Reply-To: <20171018182251.5486-1-ycheng@google.com>
From: Yuchung Cheng <ycheng@google.com>
Date: Wed, 18 Oct 2017 11:22:51 -0700
> New socket option TCP_FASTOPEN_KEY to allow different keys per
> listener. The listener by default uses the global key until the
> socket option is set. The key is a 16 bytes long binary data. This
> option has no effect on regular non-listener TCP sockets.
>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
> Reviewed-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] liquidio: xmit_more support
From: David Miller @ 2017-10-20 12:18 UTC (permalink / raw)
To: felix.manlunas; +Cc: netdev, raghu.vatsavayi, derek.chickles, satananda.burla
In-Reply-To: <20171018173602.GA14082@felix-thinkpad.cavium.com>
From: Felix Manlunas <felix.manlunas@cavium.com>
Date: Wed, 18 Oct 2017 10:36:02 -0700
> From: Intiyaz Basha <intiyaz.basha@cavium.com>
>
> Do not write the Tx doorbell if skb->xmit_more is set unless the Tx
> queue is full or stopped.
>
> Signed-off-by: Intiyaz Basha <intiyaz.basha@cavium.com>
> Signed-off-by: Derek Chickles <derek.chickles@cavium.com>
> Signed-off-by: Felix Manlunas <felix.manlunas@cavium.com>
You're going to need some kind of added heuristic for this.
If the TX queue is idle, and then you get a full TX queue's
worth of xmit_more frames, you do not want to defer the doorbell
until the entire queue has been filled.
But that is what you are doing.
You have to experment with different deferral limit values to
see where latency starts to be negatively impacted.
^ permalink raw reply
* Re: [PATCH v3 net-next 0/5] mlxsw: spectrum_router: Add extack messages for RIF and VRF overflow
From: David Miller @ 2017-10-20 12:15 UTC (permalink / raw)
To: dsahern; +Cc: netdev, jiri, idosch, kjlx, yoshfuji
In-Reply-To: <1508345816-25678-1-git-send-email-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Wed, 18 Oct 2017 09:56:51 -0700
> Currently, exceeding the number of VRF instances or the number of router
> interfaces either fails with a non-intuitive EBUSY:
> $ ip li set swp1s1.6 vrf vrf-1s1-6 up
> RTNETLINK answers: Device or resource busy
>
> or fails silently (IPv6) since the checks are done in a work queue. This
> set adds support for the address validator notifier to spectrum which
> allows ext-ack based messages to be returned on failure.
>
> To make that happen the IPv6 version needs to be converted from atomic
> to blocking (patch 2), and then support for extack needs to be added
> to the notifier (patch 3). Patch 1 reworks the locking in ipv6_add_addr
> to work better in the atomic and non-atomic code paths. Patches 4 and 5
> add the validator notifier to spectrum and then plumb the extack argument
> through spectrum_router.
>
> With this set, VRF overflows fail with:
> $ ip li set swp1s1.6 vrf vrf-1s1-6 up
> Error: spectrum: Exceeded number of supported VRF.
>
> and RIF overflows fail with:
> $ ip addr add dev swp1s2.191 10.12.191.1/24
> Error: spectrum: Exceeded number of supported router interfaces.
Series applied.
^ permalink raw reply
* Re: [RFC PATCH] can: m_can: Support higher speed CAN-FD bitrates
From: Sekhar Nori @ 2017-10-20 12:14 UTC (permalink / raw)
To: Marc Kleine-Budde, Franklin S Cooper Jr, Mario Hüttel,
Yang, Wenyou, wg, socketcan, quentin.schulz, edumazet, linux-can,
netdev, linux-kernel
Cc: Wenyou Yang, Dong Aisheng, Quadros, Roger, Oliver Hartkopp
In-Reply-To: <48317843-b488-8ccb-c6c5-e8cbb90ff5e3@pengutronix.de>
On Thursday 19 October 2017 08:25 PM, Marc Kleine-Budde wrote:
> On 10/19/2017 03:54 PM, Franklin S Cooper Jr wrote:
>> On 10/19/2017 06:32 AM, Marc Kleine-Budde wrote:
>>> On 10/19/2017 01:09 PM, Sekhar Nori wrote:
>>>> On Thursday 19 October 2017 02:43 PM, Marc Kleine-Budde wrote:
>>>>> On 10/19/2017 07:07 AM, Sekhar Nori wrote:
>>>>>>>>> Sounds reasonable. What's the status of this series?
>>>>>>>>
>>>>>>>> I have had some offline discussions with Franklin on this, and I am not
>>>>>>>> fully convinced that DT is the way to go here (although I don't have the
>>>>>>>> agreement with Franklin there).
>>>>>>>
>>>>>>> Probably the fundamental area where we disagree is what "default" SSP
>>>>>>> value should be used. Based on a short (< 1 ft) point to point test
>>>>>>> using a SSP of 50% worked fine. However, I'm not convinced that this
>>>>>>> default value of 50% will work in a more "traditional" CAN bus at higher
>>>>>>> speeds. Nor am I convinced that a SSP of 50% will work on every MCAN
>>>>>>> board in even the simplest test cases.
>>>>>>>
>>>>>>> I believe that this default SSP should be a DT property that allows any
>>>>>>> board to determine what default value works best in general.
>>>>>>
>>>>>> With that, I think, we are taking DT from describing board/hardware
>>>>>> characteristics to providing default values that software should use.
>>>>>
>>>>> If the default value is board specific and cannot be calculated in
>>>>> general or from other values present in the DT, then it's from my point
>>>>> of view describing the hardware.
>>>>>
>>>>>> In any case, if Marc and/or Wolfgang are okay with it, binding
>>>>>> documentation for such a property should be sent to DT maintainers for
>>>>>> review.
>>>>>>
>>>>>>>>
>>>>>>>> There are two components in configuring the secondary sample point. It
>>>>>>>> is the transceiver loopback delay and an offset (example half of the bit
>>>>>>>> time in data phase).
>>>>>>>>
>>>>>>>> While the transceiver loopback delay is pretty board dependent (and thus
>>>>>>>> amenable to DT encoding), I am not quite sure the offset can be
>>>>>>>> configured in DT because its not really board dependent.
>>>>>>>>
>>>>>>>> Unfortunately, offset calculation does not seem to be an exact science.
>>>>>>>> There are recommendations ranging from using 50% of bit time to making
>>>>>>>> it same as the sample point configured. This means users who need to
>>>>>>>> change the SSP due to offset variations need to change their DT even
>>>>>>>> without anything changing on their board.
>>>>>>>>
>>>>>>>> Since we have a netlink socket interface to configure sample point, I
>>>>>>>> wonder if that should be extended to configure SSP too (or at least the
>>>>>>>> offset part of SSP)?
>>>>>>>
>>>>>>> Sekhar is right that ideally the user should be able to set the SSP at
>>>>>>> runtime. However, my issue is that based on my experience CAN users
>>>>>>> expect the driver to just work the majority of times. For unique use
>>>>>>> cases where the driver calculated values don't work then the user should
>>>>>>> be able to override it. This should only be done for a very small
>>>>>>> percentage of CAN users. Unless you allow DT to provide a default SSP
>>>>>>> many users of MCAN may find that the default SSP doesn't work and must
>>>>>>> always use runtime overrides to get anything to work. I don't think that
>>>>>>> is a good user experience which is why I don't like the idea.
>>>>>>
>>>>>> Fair enough. But not quite sure if CAN users expect CAN-FD to "just
>>>>>> work" without doing any bittiming related setup.
>>>>>
>>>>> From my point of view I'd rather buy a board from a HW vendor where
>>>>> CAN-FD works, rather than a board where I have to tweak the bit-timing
>>>>> for a simple CAN-FD test setup.
>>>>>
>>>>> As far as I see for the m_can driver it's a single tuple: "bitrate > 2.5
>>>>> MBit/s -> 50%". Do we need an array of tuples in general?
>>
>> Internally what I proposed was a binding that allowed you to pass in an
>> array of a range of baud rates and then a SSP for that baud rate range.
>> Therefore, if the baud rate being used impacted what SSP worked then it
>> allows someone to provide a range of defaults. Of course a person also
>> has the ability to use a single large range thus implementing a single
>> default SSP value.
>
> A single tuple is just a special case of a list of tuples :)
>
> I was thinking of something like this:
>
> First we need a struct defining the bitrate spp relationship.
I dont know if there is such a relation between bitrate and SSP. We do
know that some papers[1] suggest that below 2.5MBits/sec TDC (and hence
SSP) feature is not required. And we also know that hardly anyone has
tested CAN-FD above 5MBits/sec.
Between these two values, we do not have enough data today to suggest
that SSP (as a percentage of bittiming) needs to move as bitrate varies.
> The driver provides default values by a sorted array of these structs
> together with array length.
>
> During device registration we assign these default values to the actual
> driver instance.
>
> The netlink code can read and overwrite the current values. Maybe it can
> read the default values.
>
> The bitrate calculation code calculates the to be used spp value.
>
> The driver sets the value during the open callback.
>
>>> Do we need more than one tuple here?
>>>
>>>>> If good default values are transceiver and board specific, they can go
>>>>> into the DT. We need a generic (this means driver agnostic) binding for
>>>>> this. If this table needs to be tweaked for special purpose, then we can
>>>>> add a netlink interface for this as well.
>>>>>
>>>>> Comments?
>>>>
>>>> I dont know how a good default (other than 50% as the starting point)
>>>> can be arrived at without doing any actual measurements on the actual
>>>> network. Since we do know that the value has to be tweaked, agree that
>>>> netlink interface has to be provided.
>>
>> Now I have seen in non public documentations that setting SP to SSP also
>> works.
>
> This can already by done now, without the need for new interfaces.
If I read correctly, this is what Oliver Hartkopp is saying too.
>> This makes a bit more sense to me and I'm alot more comfortable going
>> with this. However, since its based on non public information I can't
>> justify it beyond that "it works for me". But I'm alot more
>> comfortable going with then saying "hey this default value works for
>> TI's dra76 evm. Therefore, every MCAN board will be stuck by default
>> for a value that works for us". So if there is no push back with
>> going with SSP = db SP with no documentation to back up why that is
>> being used then I will try that out and send patches.
>
> This means we postpone the whole add-new-interface-dance until the
> SPP=SP approach doesn't work for some usecase?
I think thats prudent as any new interface (DT or userspace) needs to be
maintained forever. Over time we should have more data from actual
deployments to see if a new interface is really necessary.
Thanks,
Sekhar
[1]
http://www.bosch-semiconductors.de/media/automotive_electronics/pdf_2/ipmodules_3/can_fd_1/icc14_2013_paper_Hartwich.pdf
(last page)
^ permalink raw reply
* Re: [PATCH net-next 00/13] s390/net: updates 2017-10-18
From: David Miller @ 2017-10-20 12:12 UTC (permalink / raw)
To: jwi; +Cc: netdev, linux-s390, schwidefsky, heiko.carstens, raspl, ubraun
In-Reply-To: <20171018154025.73630-1-jwi@linux.vnet.ibm.com>
From: Julian Wiedmann <jwi@linux.vnet.ibm.com>
Date: Wed, 18 Oct 2017 17:40:12 +0200
> please apply some additional robustness fixes and cleanups for 4.15.
Series applied.
^ permalink raw reply
* Re: [PATCH net-next] net/sched: Set the net-device for egress device instance
From: David Miller @ 2017-10-20 12:09 UTC (permalink / raw)
To: ogerlitz; +Cc: netdev, mlxsw
In-Reply-To: <1508341088-20043-1-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Wed, 18 Oct 2017 18:38:08 +0300
> Currently the netdevice field is not set and the egdev instance
> is not functional, fix that.
>
> Fixes: 3f55bdda8df ('net: sched: introduce per-egress action device callbacks')
> Signed-off-by: Or Gerlitz <ogerlitz@mellanox.com>
> Acked-by: Jiri Pirko <jiri@mellanox.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 0/8] cxgb4: enable more tc flower offload matches and actions
From: David Miller @ 2017-10-20 12:07 UTC (permalink / raw)
To: rahul.lakkireddy; +Cc: netdev, kumaras, ganeshgr, nirranjan, indranil
In-Reply-To: <cover.1508312071.git.rahul.lakkireddy@chelsio.com>
From: Rahul Lakkireddy <rahul.lakkireddy@chelsio.com>
Date: Wed, 18 Oct 2017 20:49:06 +0530
> This patch series enable more matches and actions for TC Flower
> Offload support on Chelsio adapters.
Series applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] tcp: Remove use of inet6_sk and add IPv6 checks to tracepoint
From: David Miller @ 2017-10-20 12:05 UTC (permalink / raw)
To: dsahern; +Cc: netdev, xiyou.wangcong, eric.dumazet, songliubraving
In-Reply-To: <1508339849-19527-1-git-send-email-dsahern@gmail.com>
From: David Ahern <dsahern@gmail.com>
Date: Wed, 18 Oct 2017 08:17:29 -0700
> 386fd5da401d ("tcp: Check daddr_cache before use in tracepoint") was the
> second version of the tracepoint fixup patch. This patch is the delta
> between v2 and v3. Specifically, remove the use of inet6_sk and check
> sk_family as requested by Eric and add IS_ENABLED(CONFIG_IPV6) around
> the use of sk_v6_rcv_saddr and sk_v6_daddr as done in sock_common (noted
> by Cong).
>
> Signed-off-by: David Ahern <dsahern@gmail.com>
Applied, sorry for the mixup :)
^ permalink raw reply
* Re: [RFC PATCH 3/5] sctp: Add LSM hooks
From: Richard Haines @ 2017-10-20 12:04 UTC (permalink / raw)
To: Neil Horman, Xin Long
Cc: selinux, network dev, linux-sctp, linux-security-module
In-Reply-To: <20171020111637.GA14713@neilslaptop.think-freely.org>
On Fri, 2017-10-20 at 07:16 -0400, Neil Horman wrote:
> On Wed, Oct 18, 2017 at 11:05:09PM +0800, Xin Long wrote:
> > On Tue, Oct 17, 2017 at 9:58 PM, Richard Haines
> > <richard_c_haines@btinternet.com> wrote:
> > > Add security hooks to allow security modules to exercise access
> > > control
> > > over SCTP.
> > >
> > > Signed-off-by: Richard Haines <richard_c_haines@btinternet.com>
> > > ---
> > > include/net/sctp/structs.h | 10 ++++++++
> > > include/uapi/linux/sctp.h | 1 +
> > > net/sctp/sm_make_chunk.c | 12 +++++++++
> > > net/sctp/sm_statefuns.c | 14 ++++++++++-
> > > net/sctp/socket.c | 61
> > > +++++++++++++++++++++++++++++++++++++++++++++-
> > > 5 files changed, 96 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/include/net/sctp/structs.h
> > > b/include/net/sctp/structs.h
> > > index 7767577..6e72e3e 100644
> > > --- a/include/net/sctp/structs.h
> > > +++ b/include/net/sctp/structs.h
> > > @@ -1270,6 +1270,16 @@ struct sctp_endpoint {
> > > reconf_enable:1;
> > >
> > > __u8 strreset_enable;
> > > +
> > > + /* Security identifiers from incoming (INIT). These are
> > > set by
> > > + * security_sctp_assoc_request(). These will only be used
> > > by
> > > + * SCTP TCP type sockets and peeled off connections as
> > > they
> > > + * cause a new socket to be generated.
> > > security_sctp_sk_clone()
> > > + * will then plug these into the new socket.
> > > + */
> > > +
> > > + u32 secid;
> > > + u32 peer_secid;
> > > };
> > >
> > > /* Recover the outter endpoint structure. */
> > > diff --git a/include/uapi/linux/sctp.h
> > > b/include/uapi/linux/sctp.h
> > > index 6217ff8..c04812f 100644
> > > --- a/include/uapi/linux/sctp.h
> > > +++ b/include/uapi/linux/sctp.h
> > > @@ -122,6 +122,7 @@ typedef __s32 sctp_assoc_t;
> > > #define SCTP_RESET_ASSOC 120
> > > #define SCTP_ADD_STREAMS 121
> > > #define SCTP_SOCKOPT_PEELOFF_FLAGS 122
> > > +#define SCTP_SENDMSG_CONNECT 123
> > >
> > > /* PR-SCTP policies */
> > > #define SCTP_PR_SCTP_NONE 0x0000
> > > diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
> > > index 6110447..ca4705b 100644
> > > --- a/net/sctp/sm_make_chunk.c
> > > +++ b/net/sctp/sm_make_chunk.c
> > > @@ -3059,6 +3059,12 @@ static __be16
> > > sctp_process_asconf_param(struct sctp_association *asoc,
> > > if (af->is_any(&addr))
> > > memcpy(&addr, &asconf->source,
> > > sizeof(addr));
> > >
> > > + if (security_sctp_bind_connect(asoc->ep->base.sk,
> > > + SCTP_PARAM_ADD_IP,
> > > + (struct sockaddr
> > > *)&addr,
> > > + af->sockaddr_len))
> > > + return SCTP_ERROR_REQ_REFUSED;
> > > +
> > > /* ADDIP 4.3 D9) If an endpoint receives an ADD
> > > IP address
> > > * request and does not have the local resources
> > > to add this
> > > * new address to the association, it MUST return
> > > an Error
> > > @@ -3125,6 +3131,12 @@ static __be16
> > > sctp_process_asconf_param(struct sctp_association *asoc,
> > > if (af->is_any(&addr))
> > > memcpy(&addr.v4, sctp_source(asconf),
> > > sizeof(addr));
> > >
> > > + if (security_sctp_bind_connect(asoc->ep->base.sk,
> > > + SCTP_PARAM_SET_PRI
> > > MARY,
> > > + (struct sockaddr
> > > *)&addr,
> > > + af->sockaddr_len))
> > > + return SCTP_ERROR_REQ_REFUSED;
> > > +
> > > peer = sctp_assoc_lookup_paddr(asoc, &addr);
> > > if (!peer)
> > > return SCTP_ERROR_DNS_FAILED;
> > > diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> > > index b2a74c3..4ba5805 100644
> > > --- a/net/sctp/sm_statefuns.c
> > > +++ b/net/sctp/sm_statefuns.c
> > > @@ -314,6 +314,11 @@ sctp_disposition_t
> > > sctp_sf_do_5_1B_init(struct net *net,
> > > sctp_unrecognized_param_t *unk_param;
> > > int len;
> > >
> > > + /* Update socket peer label if first association. */
> > > + if (security_sctp_assoc_request((struct sctp_endpoint
> > > *)ep,
> > > + chunk->skb,
> > > SCTP_CID_INIT))
> > > + return sctp_sf_pdiscard(net, ep, asoc, type, arg,
> > > commands);
> > > +
> > > /* 6.10 Bundling
> > > * An endpoint MUST NOT bundle INIT, INIT ACK or
> > > * SHUTDOWN COMPLETE with any other chunks.
> > > @@ -446,7 +451,6 @@ sctp_disposition_t
> > > sctp_sf_do_5_1B_init(struct net *net,
> > > }
> > >
> > > sctp_add_cmd_sf(commands, SCTP_CMD_NEW_ASOC,
> > > SCTP_ASOC(new_asoc));
> > > -
> > > sctp_add_cmd_sf(commands, SCTP_CMD_REPLY,
> > > SCTP_CHUNK(repl));
> > >
> > > /*
> > > @@ -507,6 +511,11 @@ sctp_disposition_t
> > > sctp_sf_do_5_1C_ack(struct net *net,
> > > struct sctp_chunk *err_chunk;
> > > struct sctp_packet *packet;
> > >
> > > + /* Update socket peer label if first association. */
> > > + if (security_sctp_assoc_request((struct sctp_endpoint
> > > *)ep,
> > > + chunk->skb,
> > > SCTP_CID_INIT_ACK))
> > > + return sctp_sf_pdiscard(net, ep, asoc, type, arg,
> > > commands);
> > > +
> >
> > Just thinking security_sctp_assoc_request hook should also be in
> > sctp_sf_do_unexpected_init() and sctp_sf_do_5_2_4_dupcook() ?
>
> I agree, i think if this hook is gating on the creation of a new
> association,
> they should be in all the locations where that happens
> Neil
Thanks for the comments. I've just added the hook as requested for my
next update, however I have not managed to trigger these areas using
the lksctp-tools tests. Can you suggest any suitable tools for testing
these scenarios.
Thanks
Richard
>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-
> > sctp" in
> > the body of a message to majordomo@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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] doc: Update VRF documentation metric
From: David Miller @ 2017-10-20 12:03 UTC (permalink / raw)
To: sharpd; +Cc: netdev, dsa
In-Reply-To: <20171018142428.26398-1-sharpd@cumulusnetworks.com>
From: Donald Sharp <sharpd@cumulusnetworks.com>
Date: Wed, 18 Oct 2017 10:24:28 -0400
> Two things:
>
> 1) Update examples to show usage of metric
> 2) Discuss reasoning for using such a high metric.
>
> Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
Applied to net-next.
^ permalink raw reply
* Re: [net PATCH 0/5] sockmap fixes for net
From: David Miller @ 2017-10-20 12:01 UTC (permalink / raw)
To: john.r.fastabend; +Cc: alexei.starovoitov, netdev, borkmann
In-Reply-To: <150833522977.3588.14633565129152334098.stgit@john-XPS-13-9360>
From: John Fastabend <john.r.fastabend@gmail.com>
Date: Wed, 18 Oct 2017 07:09:48 -0700
> The following implements a set of fixes for sockmap and changes the
> API slightly in a few places to reduce preempt_disable/enable scope.
> We do this here in net because it requires an API change and this
> avoids getting stuck with legacy API going forward.
>
> The short description:
>
> Access to skb mark is removed, it is problematic when we add
> features in the future because mark is a union and used by the
> TCP/socket code internally. We don't want to expose this to the
> BPF programs or let programs change the values.
>
> The other change is caching metadata in the skb itself between
> when the BPF program returns a redirect code and the core code
> implements the redirect. This avoids having per cpu metadata.
>
> Finally, tighten restriction on using sockmap to CAP_NET_ADMIN and
> only SOCK_STREAM sockets.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net] sctp: add the missing sock_owned_by_user check in sctp_icmp_redirect
From: David Miller @ 2017-10-20 11:54 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, edumazet, marcelo.leitner, nhorman
In-Reply-To: <7f2a5122d93d4b72115027690e89c0a164097452.1508333869.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Wed, 18 Oct 2017 21:37:49 +0800
> Now sctp processes icmp redirect packet in sctp_icmp_redirect where
> it calls sctp_transport_dst_check in which tp->dst can be released.
>
> The problem is before calling sctp_transport_dst_check, it doesn't
> check sock_owned_by_user, which means tp->dst could be freed while
> a process is accessing it with owning the socket.
>
> An use-after-free issue could be triggered by this.
>
> This patch is to fix it by checking sock_owned_by_user before calling
> sctp_transport_dst_check in sctp_icmp_redirect, so that it would not
> release tp->dst if users still hold sock lock.
>
> Besides, the same issue fixed in commit 45caeaa5ac0b ("dccp/tcp: fix
> routing redirect race") on sctp also needs this check.
>
> Fixes: 55be7a9c6074 ("ipv4: Add redirect support to all protocol icmp error handlers")
> Reported-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied and queued up for -stable.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox