* Re: [PATCH 2/3] arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes
From: Simon Horman @ 2019-01-23 9:51 UTC (permalink / raw)
To: Fabrizio Castro
Cc: Wolfgang Grandegger, Marc Kleine-Budde, Rob Herring, Mark Rutland,
Michael Turquette, Stephen Boyd, David S. Miller, Magnus Damm,
Geert Uytterhoeven, Chris Paterson, Biju Das, linux-can, netdev,
devicetree, linux-renesas-soc, linux-clk
In-Reply-To: <20190118121353.3mb44a7rmmp2ru5d@verge.net.au>
On Fri, Jan 18, 2019 at 01:13:53PM +0100, Simon Horman wrote:
> On Thu, Jan 17, 2019 at 02:54:15PM +0000, Fabrizio Castro wrote:
> > According to the latest information, clkp2 is available on RZ/G2.
> > Modify CAN0 and CAN1 nodes accordingly.
> >
> > Signed-off-by: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
> > Reviewed-by: Chris Paterson <Chris.Paterson2@renesas.com>
>
> Thanks,
>
> This looks fine to me but I will wait to see if there are other reviews
> before applying.
>
> Reviewed-by: Simon Horman <horms+renesas@verge.net.au>
Thanks again, applied for v5.1.
^ permalink raw reply
* Re: [PATCH net 5/5] net: aquantia: added err var into AQ_HW_WAIT_FOR construct
From: Igor Russkikh @ 2019-01-23 9:49 UTC (permalink / raw)
To: Andrew Lunn; +Cc: David S . Miller, netdev@vger.kernel.org, Nikita Danilov
In-Reply-To: <20190122133424.GB3634@lunn.ch>
>
> Hi Igor
>
> err = readx_poll_timeout(hw_atl_itr_res_irq_get, self, alt_itr_res,
> alt_itr_res == 0, 10, 1000);
>
> The advantage of using readx_poll_timeout is that it is used by lots
> of other drivers and works. It is much better to use core
> infrastructure, then build your own.
Hi Andrew, agreed, but driver have more incompatible places with constructs like
AQ_HW_WAIT_FOR(orig_stats_val !=
(aq_hw_read_reg(self, HW_ATL_FW2X_MPI_STATE2_ADDR) &
BIT(CAPS_HI_STATISTICS)),
1U, 10000U);
For this only the following hack comes to my mind:
err = readx_poll_timeout_atomic(, val, val, orig_stats_val !=
(aq_hw_read_reg(self, HW_ATL_FW2X_MPI_STATE2_ADDR) &
BIT(CAPS_HI_STATISTICS)), 1, 10000);
That way it may be better to do the following declaration then:
#define do_poll_timeout_atomic(cond, sleep_us, timeout_us) \
({ \
int _val; /* to make macro happy */
readx_poll_timeout_atomic(, _val, _val, cond, sleep_us, timeout_us);
})
Another way would be just to remove AQ_HW_WAIT_FOR macro for all the hard cases
and rewrite it with explicit `for` loop. But that'll reduce readability I guess.
PS
Found duplicating readl_poll_timeout declaration here:
https://elixir.bootlin.com/linux/latest/source/drivers/phy/qualcomm/phy-qcom-ufs-i.h#L27
Not sure what's the reason, but may worth cleaning it up.
Regards,
Igor
^ permalink raw reply
* [PATCH net-next] devlink: Use after free in devlink_health_reporter_destroy()
From: Dan Carpenter @ 2019-01-23 9:44 UTC (permalink / raw)
To: Jiri Pirko, Eran Ben Elisha; +Cc: David S. Miller, netdev, kernel-janitors
This calls kfree(reporter); before dereferencing reporter on the next
line when it does mutex_unlock(&reporter->devlink->lock);
Fixes: 880ee82f0313 ("devlink: Add health reporter create/destroy functionality")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
net/core/devlink.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/core/devlink.c b/net/core/devlink.c
index 60248a53c0ad..deccce13285a 100644
--- a/net/core/devlink.c
+++ b/net/core/devlink.c
@@ -4223,14 +4223,16 @@ EXPORT_SYMBOL_GPL(devlink_health_reporter_create);
void
devlink_health_reporter_destroy(struct devlink_health_reporter *reporter)
{
- mutex_lock(&reporter->devlink->lock);
+ struct devlink *devlink = reporter->devlink;
+
+ mutex_lock(&devlink->lock);
list_del(&reporter->list);
devlink_health_buffers_destroy(reporter->dump_buffers_array,
DEVLINK_HEALTH_SIZE_TO_BUFFERS(reporter->ops->dump_size));
devlink_health_buffers_destroy(reporter->diagnose_buffers_array,
DEVLINK_HEALTH_SIZE_TO_BUFFERS(reporter->ops->diagnose_size));
kfree(reporter);
- mutex_unlock(&reporter->devlink->lock);
+ mutex_unlock(&devlink->lock);
}
EXPORT_SYMBOL_GPL(devlink_health_reporter_destroy);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH net-next v7 1/8] devlink: Add devlink_param for port register and unregister
From: Vasundhara Volam @ 2019-01-23 9:13 UTC (permalink / raw)
To: Jiri Pirko
Cc: David Miller, michael.chan@broadcom.com, Jiri Pirko,
Jakub Kicinski, mkubecek, Netdev
In-Reply-To: <20190123082513.GA2191@nanopsycho>
On Wed, Jan 23, 2019 at 2:04 PM Jiri Pirko <jiri@resnulli.us> wrote:
>
> Fri, Jan 18, 2019 at 08:09:38AM CET, vasundhara-v.volam@broadcom.com wrote:
> >Add functions to register and unregister for the driver supported
> >configuration parameters table per port.
> >
> >v2->v3:
> >- Add a helper __devlink_params_register() with common code used by
> > both devlink_params_register() and devlink_port_params_register().
> >
>
> [...]
>
>
> >+
> >+static int __devlink_params_register(struct devlink *devlink,
> >+ struct list_head *param_list,
> >+ const struct devlink_param *params,
> >+ size_t params_count)
> > {
> > const struct devlink_param *param = params;
> > int i;
> >@@ -4490,20 +4493,11 @@ int devlink_params_register(struct devlink *devlink,
> >
> > mutex_lock(&devlink->lock);
> > for (i = 0; i < params_count; i++, param++) {
> >- if (!param || !param->name || !param->supported_cmodes) {
> >- err = -EINVAL;
> >+ err = devlink_param_verify(param);
> >+ if (err)
> > goto rollback;
> >- }
> >- if (param->generic) {
> >- err = devlink_param_generic_verify(param);
> >- if (err)
> >- goto rollback;
> >- } else {
> >- err = devlink_param_driver_verify(param);
> >- if (err)
> >- goto rollback;
> >- }
> >- err = devlink_param_register_one(devlink, param);
> >+
> >+ err = devlink_param_register_one(devlink, param_list, param);
> > if (err)
> > goto rollback;
> > }
> >@@ -4515,31 +4509,57 @@ int devlink_params_register(struct devlink *devlink,
> > if (!i)
> > goto unlock;
> > for (param--; i > 0; i--, param--)
> >- devlink_param_unregister_one(devlink, param);
> >+ devlink_param_unregister_one(devlink, param_list, param);
> > unlock:
> > mutex_unlock(&devlink->lock);
> > return err;
> > }
> >-EXPORT_SYMBOL_GPL(devlink_params_register);
> >
> > /**
> >- * devlink_params_unregister - unregister configuration parameters
> >+ * devlink_params_register - register configuration parameters
> >+ *
> > * @devlink: devlink
> >- * @params: configuration parameters to unregister
> >+ * @params: configuration parameters array
> > * @params_count: number of parameters provided
> >+ *
> >+ * Register the configuration parameters supported by the driver.
> > */
> >-void devlink_params_unregister(struct devlink *devlink,
> >- const struct devlink_param *params,
> >- size_t params_count)
> >+int devlink_params_register(struct devlink *devlink,
>
> The order of the functions should be:
> __devlink_params_register
> __devlink_params_unregister
> devlink_params_register
> devlink_params_unregister
> devlink_port_params_register
> devlink_port_params_unregister
>
> Your order is a bit confusing.
>
> Other than that:
> Acked-by: Jiri Pirko <jiri@mellanox.com>
Thank you Jiri. I will update the order in the next version.
>
>
> [...]
^ permalink raw reply
* Re: [PATCH net-next v7 2/8] devlink: Add port param get command
From: Jiri Pirko @ 2019-01-23 8:53 UTC (permalink / raw)
To: Vasundhara Volam
Cc: davem, michael.chan, jiri, jakub.kicinski, mkubecek, netdev
In-Reply-To: <1547795385-12354-3-git-send-email-vasundhara-v.volam@broadcom.com>
Fri, Jan 18, 2019 at 08:09:39AM CET, vasundhara-v.volam@broadcom.com wrote:
>Add port param get command which gets data per parameter.
>It also has option to dump the parameters data per port.
>
>Cc: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Vasundhara Volam <vasundhara-v.volam@broadcom.com>
Acked-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* Re: [PATCH bpf v3] bpftool: fix percpu maps updating
From: Daniel Borkmann @ 2019-01-23 8:59 UTC (permalink / raw)
To: Paolo Abeni, netdev; +Cc: Alexei Starovoitov, Quentin Monnet
In-Reply-To: <2aa43d94db61dc2644bc18a47fba2889ec93bf3e.1548069694.git.pabeni@redhat.com>
On 01/21/2019 12:36 PM, Paolo Abeni wrote:
> When updating a percpu map, bpftool currently copies the provided
> value only into the first per CPU copy of the specified value,
> all others instances are left zeroed.
>
> This change explicitly copies the user-provided bytes to all the
> per CPU instances, keeping the sub-command syntax unchanged.
>
> v2 -> v3:
> - drop unused argument, as per Quentin's suggestion
> v1 -> v2:
> - rename the helper as per Quentin's suggestion
>
> Fixes: 71bb428fe2c1 ("tools: bpf: add bpftool")
> Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Applied to bpf, thanks!
^ permalink raw reply
* Re: [PATCH] bpftool: Fix prog dump by tag
From: Daniel Borkmann @ 2019-01-23 8:58 UTC (permalink / raw)
To: Jiri Olsa, Alexei Starovoitov; +Cc: lkml, netdev, Lance Digby
In-Reply-To: <20190118125817.10763-1-jolsa@kernel.org>
On 01/18/2019 01:58 PM, Jiri Olsa wrote:
> Lance reported an issue with bpftool not being able to
> dump program if there are more programs loaded and you
> want to dump any but the first program, like:
>
> # bpftool prog
> 28: kprobe name trace_req_start tag 1dfc28ba8b3dd597 gpl
> loaded_at 2019-01-18T17:02:40+1100 uid 0
> xlated 112B jited 109B memlock 4096B map_ids 13
> 29: kprobe name trace_req_compl tag 5b6a5ecc6030a683 gpl
> loaded_at 2019-01-18T17:02:40+1100 uid 0
> xlated 928B jited 575B memlock 4096B map_ids 13,14
> # bpftool prog dum jited tag 1dfc28ba8b3dd597
> 0: push %rbp
> 1: mov %rsp,%rbp
> ...
>
> # bpftool prog dum jited tag 5b6a5ecc6030a683
> Error: can't get prog info (29): Bad address
>
> The problem is in the prog_fd_by_tag function not cleaning
> the struct bpf_prog_info before another request, so the
> previous program length is still in there and kernel assumes
> it needs to dump the program, which fails because there's no
> user pointer set.
>
> Moving the struct bpf_prog_info declaration into the loop,
> so it gets cleaned before each query.
>
> Reported-by: Lance Digby <ldigby@redhat.com>
> Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Applied to bpf and added Fixes tags, thanks!
^ permalink raw reply
* Re: [NETDEV]: getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP
From: Willy Tarreau @ 2019-01-23 8:54 UTC (permalink / raw)
To: Mohandass, Roobesh; +Cc: Lukas Tribus, Florian Westphal, netdev@vger.kernel.org
In-Reply-To: <MWHPR16MB150280EC34A9D4A8ECF809D4ED990@MWHPR16MB1502.namprd16.prod.outlook.com>
Hi Roobesh,
On Wed, Jan 23, 2019 at 08:07:48AM +0000, Mohandass, Roobesh wrote:
> Hi Willy/Florian/Lukas,
>
> disabling nf_conntrack_tcp_loose (solved the problem) and for last 24 hours,
> we are not evening seeing a single wrong connection data by send-proxy.
>
> Worth a note in your documentation related to this, as users might be aware
> off.
>
> Thanks very much for your help and support, I will report back if I see
> anything again related to this.
Thank you for your feedback on this issue, and kudos to Florian
for spotting the root cause!
Willy
^ permalink raw reply
* Re: [PATCH net-next v7 1/8] devlink: Add devlink_param for port register and unregister
From: Jiri Pirko @ 2019-01-23 8:25 UTC (permalink / raw)
To: Vasundhara Volam
Cc: davem, michael.chan, jiri, jakub.kicinski, mkubecek, netdev
In-Reply-To: <1547795385-12354-2-git-send-email-vasundhara-v.volam@broadcom.com>
Fri, Jan 18, 2019 at 08:09:38AM CET, vasundhara-v.volam@broadcom.com wrote:
>Add functions to register and unregister for the driver supported
>configuration parameters table per port.
>
>v2->v3:
>- Add a helper __devlink_params_register() with common code used by
> both devlink_params_register() and devlink_port_params_register().
>
[...]
>+
>+static int __devlink_params_register(struct devlink *devlink,
>+ struct list_head *param_list,
>+ const struct devlink_param *params,
>+ size_t params_count)
> {
> const struct devlink_param *param = params;
> int i;
>@@ -4490,20 +4493,11 @@ int devlink_params_register(struct devlink *devlink,
>
> mutex_lock(&devlink->lock);
> for (i = 0; i < params_count; i++, param++) {
>- if (!param || !param->name || !param->supported_cmodes) {
>- err = -EINVAL;
>+ err = devlink_param_verify(param);
>+ if (err)
> goto rollback;
>- }
>- if (param->generic) {
>- err = devlink_param_generic_verify(param);
>- if (err)
>- goto rollback;
>- } else {
>- err = devlink_param_driver_verify(param);
>- if (err)
>- goto rollback;
>- }
>- err = devlink_param_register_one(devlink, param);
>+
>+ err = devlink_param_register_one(devlink, param_list, param);
> if (err)
> goto rollback;
> }
>@@ -4515,31 +4509,57 @@ int devlink_params_register(struct devlink *devlink,
> if (!i)
> goto unlock;
> for (param--; i > 0; i--, param--)
>- devlink_param_unregister_one(devlink, param);
>+ devlink_param_unregister_one(devlink, param_list, param);
> unlock:
> mutex_unlock(&devlink->lock);
> return err;
> }
>-EXPORT_SYMBOL_GPL(devlink_params_register);
>
> /**
>- * devlink_params_unregister - unregister configuration parameters
>+ * devlink_params_register - register configuration parameters
>+ *
> * @devlink: devlink
>- * @params: configuration parameters to unregister
>+ * @params: configuration parameters array
> * @params_count: number of parameters provided
>+ *
>+ * Register the configuration parameters supported by the driver.
> */
>-void devlink_params_unregister(struct devlink *devlink,
>- const struct devlink_param *params,
>- size_t params_count)
>+int devlink_params_register(struct devlink *devlink,
The order of the functions should be:
__devlink_params_register
__devlink_params_unregister
devlink_params_register
devlink_params_unregister
devlink_port_params_register
devlink_port_params_unregister
Your order is a bit confusing.
Other than that:
Acked-by: Jiri Pirko <jiri@mellanox.com>
[...]
^ permalink raw reply
* Re: [PATCH net-next] net: stmmac: Fix return value check in qcom_ethqos_probe()
From: Vinod Koul @ 2019-01-23 8:30 UTC (permalink / raw)
To: Wei Yongjun, davem
Cc: Niklas Cassel, Giuseppe Cavallaro, Alexandre Torgue, Jose Abreu,
Maxime Coquelin, netdev, linux-stm32, linux-arm-kernel,
kernel-janitors
In-Reply-To: <1548224358-83281-1-git-send-email-weiyongjun1@huawei.com>
On 23-01-19, 06:19, Wei Yongjun wrote:
> In case of error, the function devm_clk_get() returns ERR_PTR() and
> never returns NULL. The NULL test in the return value check should be
> replaced with IS_ERR().
Acked-by: Vinod Koul <vkoul@kernel.org>
This is a networking subsystem patch and you missed Dave :(
> Fixes: a7c30e62d4b8 ("net: stmmac: Add driver for Qualcomm ethqos")
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index 30724bd..7ec8954 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -473,8 +473,8 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
> ethqos->por = of_device_get_match_data(&pdev->dev);
>
> ethqos->rgmii_clk = devm_clk_get(&pdev->dev, "rgmii");
> - if (!ethqos->rgmii_clk) {
> - ret = -ENOMEM;
> + if (IS_ERR(ethqos->rgmii_clk)) {
> + ret = PTR_ERR(ethqos->rgmii_clk);
> goto err_mem;
> }
>
>
--
~Vinod
^ permalink raw reply
* Want to edit your photos
From: Judy @ 2019-01-23 7:26 UTC (permalink / raw)
To: netdev
We want to work for you to edit your photos.
We can do your photos with white background, sharpen, retouching is
included for all your photos.
Waiting for the test photos to start with.
Thanks,
Judy
^ permalink raw reply
* Want to edit your photos
From: Judy @ 2019-01-23 6:40 UTC (permalink / raw)
To: netdev
We want to work for you to edit your photos.
We can do your photos with white background, sharpen, retouching is
included for all your photos.
Waiting for the test photos to start with.
Thanks,
Judy
^ permalink raw reply
* RE: [NETDEV]: getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP
From: Mohandass, Roobesh @ 2019-01-23 8:07 UTC (permalink / raw)
To: Willy Tarreau, Lukas Tribus; +Cc: Florian Westphal, netdev@vger.kernel.org
In-Reply-To: <MWHPR16MB1502F0C1FAD55777E7B228BFED830@MWHPR16MB1502.namprd16.prod.outlook.com>
Hi Willy/Florian/Lukas,
disabling nf_conntrack_tcp_loose (solved the problem) and for last 24 hours, we are not evening seeing a single wrong connection data by send-proxy.
Worth a note in your documentation related to this, as users might be aware off.
Thanks very much for your help and support, I will report back if I see anything again related to this.
-Roobesh G M
-----Original Message-----
From: Mohandass, Roobesh
Sent: Thursday, January 17, 2019 10:54 AM
To: Willy Tarreau <w@1wt.eu>; Lukas Tribus <lists@ltri.eu>
Cc: Florian Westphal <fw@strlen.de>; netdev@vger.kernel.org
Subject: RE: [NETDEV]: getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP
Hi Willy/Florian/Lukas,
Thanks for your help around this concern, sorry for the delayed response. I will test this out and get back to you.
-Roobesh G M
-----Original Message-----
From: Willy Tarreau <w@1wt.eu>
Sent: Sunday, January 13, 2019 12:04 AM
To: Lukas Tribus <lists@ltri.eu>
Cc: Mohandass, Roobesh <Roobesh_Mohandass@McAfee.com>; Florian Westphal <fw@strlen.de>; netdev@vger.kernel.org
Subject: Re: [NETDEV]: getsockopt(fd, SOL_IP, SO_ORIGINAL_DST, sa, &salen) is in fact sometimes returning the source IP instead the destination IP
This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Hi Lukas,
On Sat, Jan 12, 2019 at 07:01:34PM +0100, Lukas Tribus wrote:
> > Roobesh, do you use the destination address only for logging or
> > anywhere else in the request path ? And could you check if you have
> > nf_conntrack_tcp_loose set as Florian suggests ? I really think he
> > figured it right.
>
> It's about what we send with the PROXY protocol to the backend server,
> Roobesh reported things like that (src and dst is the same):
>
> PROXY TCP4 192.220.26.39 192.220.26.39 45066 45066 PROXY TCP4
> 192.220.26.39 192.220.26.39 45075 45075
>
> So the call would actually happen at the beginning of the TCP connection.
That sounds quite shocking to me then. Maybe we're facing such a sequence:
1) first session comes from this port, and client closes first (FIN)
2) haproxy then closes with (FIN)
3) client doesn't respond with the final ACK (e.g. blocked by another
firewall in between or the client's own conntrack)
4) the socket on the haproxy side remains in LAST_ACK state and ACKs
are periodically resent
5) local conntrack is in TIME_WAIT and expires faster than the largest
interval between two such ACKs
6) one of these retransmitted ACKs reopens the connection in reverse
direction due to nf_conntrack_tcp_loose. The connection is then
seen in ESTABLISHED state and might be kept a bit longer.
8) the connection finally expires in the local TCP stack but not yet
in conntrack.
7) later the client reuses the same source port while the connection
is still present in the conntrack table.
8) assuming tcp_be_liberal is also set, the packets can pass through
conntrack and establish a new connection to haproxy.
9) haproxy calls getsockopt(SO_ORIGINAL_DST) and gets the other end
point since the connection was created at step 6 above in the
other direction.
I could be wrong on certain specific points above but it looks plausible.
> Initial report is here:
> https://discourse.haproxy.org/t/send-proxy-not-modifying-some-traffic-
> with-proxy-ip-port-details/3336
Ah cool, I didn't have all this, thank you!
> Let's see if disabling nf_conntrack_tcp_loose changes things.
Yes this really is the only thing I can think of, and in this case noone is wrong in this chain (neither kernel nor haproxy). We'll need to document it in my opinion.
Thanks,
Willy
^ permalink raw reply
* [PATCH net-next] net/mlx4: Mark expected switch fall-through
From: Gustavo A. R. Silva @ 2019-01-23 8:05 UTC (permalink / raw)
To: Tariq Toukan, David S. Miller
Cc: netdev, linux-rdma, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warning:
drivers/net/ethernet/mellanox/mlx4/eq.c: In function ‘mlx4_eq_int’:
drivers/net/ethernet/mellanox/mlx4/mlx4.h:219:5: warning: this statement may fall through [-Wimplicit-fallthrough=]
if (mlx4_debug_level) \
^
drivers/net/ethernet/mellanox/mlx4/eq.c:558:4: note: in expansion of macro ‘mlx4_dbg’
mlx4_dbg(dev, "%s: MLX4_EVENT_TYPE_SRQ_LIMIT. srq_no=0x%x, eq 0x%x\n",
^~~~~~~~
drivers/net/ethernet/mellanox/mlx4/eq.c:561:3: note: here
case MLX4_EVENT_TYPE_SRQ_CATAS_ERROR:
^~~~
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/mellanox/mlx4/eq.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/mellanox/mlx4/eq.c b/drivers/net/ethernet/mellanox/mlx4/eq.c
index 4953c852c247..2f4201023836 100644
--- a/drivers/net/ethernet/mellanox/mlx4/eq.c
+++ b/drivers/net/ethernet/mellanox/mlx4/eq.c
@@ -558,6 +558,7 @@ static int mlx4_eq_int(struct mlx4_dev *dev, struct mlx4_eq *eq)
mlx4_dbg(dev, "%s: MLX4_EVENT_TYPE_SRQ_LIMIT. srq_no=0x%x, eq 0x%x\n",
__func__, be32_to_cpu(eqe->event.srq.srqn),
eq->eqn);
+ /* fall through */
case MLX4_EVENT_TYPE_SRQ_CATAS_ERROR:
if (mlx4_is_master(dev)) {
/* forward only to slave owning the SRQ */
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next] bna: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-01-23 8:06 UTC (permalink / raw)
To: Sudarsana Reddy Kalluru, Rasesh Mody, Sudarsana Kalluru,
Dept-GELinuxNICDev@cavium.com, David S. Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CY4PR18MB125398716A4A84409D301F7AD3990@CY4PR18MB1253.namprd18.prod.outlook.com>
On 1/23/19 2:03 AM, Sudarsana Reddy Kalluru wrote:
> -----Original Message-----
> From: Gustavo A. R. Silva [mailto:gustavo@embeddedor.com]
> Sent: 23 January 2019 13:23
> To: Rasesh Mody <rasesh.mody@cavium.com>; Sudarsana Kalluru <sudarsana.kalluru@cavium.com>; Dept-GELinuxNICDev@cavium.com; David S. Miller <davem@davemloft.net>
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R. Silva <gustavo@embeddedor.com>
> Subject: [PATCH net-next] bna: Mark expected switch fall-throughs
>
> External Email
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings:
>
> drivers/net/ethernet/brocade/bna/bfa_ioc.c:790:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
> drivers/net/ethernet/brocade/bna/bfa_ioc.c:860:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
>
> Warning level 3 was used: -Wimplicit-fallthrough=3
>
> This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough
>
> Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
> ---
> drivers/net/ethernet/brocade/bna/bfa_ioc.c | 9 +++------
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
> index a36e38676640..cbc9175d74c5 100644
> --- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
> +++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
> @@ -788,9 +788,8 @@ bfa_iocpf_sm_enabling(struct bfa_iocpf *iocpf, enum iocpf_event event)
>
> case IOCPF_E_INITFAIL:
> del_timer(&ioc->iocpf_timer);
> - /*
> - * !!! fall through !!!
> - */
> + /* fall through */
> +
> case IOCPF_E_TIMEOUT:
> bfa_nw_ioc_hw_sem_release(ioc);
> if (event == IOCPF_E_TIMEOUT) @@ -858,9 +857,7 @@ bfa_iocpf_sm_disabling(struct bfa_iocpf *iocpf, enum iocpf_event event)
>
> case IOCPF_E_FAIL:
> del_timer(&ioc->iocpf_timer);
> - /*
> - * !!! fall through !!!
> - */
> + /* fall through*/
>
> case IOCPF_E_TIMEOUT:
> bfa_ioc_set_cur_ioc_fwstate(ioc, BFI_IOC_FAIL);
> --
> 2.20.1
>
> Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
>
Thanks, Sudarsana.
--
Gustavo
^ permalink raw reply
* RE: [PATCH net-next] bna: Mark expected switch fall-throughs
From: Sudarsana Reddy Kalluru @ 2019-01-23 8:03 UTC (permalink / raw)
To: Gustavo A. R. Silva, Rasesh Mody, Sudarsana Kalluru,
Dept-GELinuxNICDev@cavium.com, David S. Miller
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190123075328.GA25319@embeddedor>
-----Original Message-----
From: Gustavo A. R. Silva [mailto:gustavo@embeddedor.com]
Sent: 23 January 2019 13:23
To: Rasesh Mody <rasesh.mody@cavium.com>; Sudarsana Kalluru <sudarsana.kalluru@cavium.com>; Dept-GELinuxNICDev@cavium.com; David S. Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R. Silva <gustavo@embeddedor.com>
Subject: [PATCH net-next] bna: Mark expected switch fall-throughs
External Email
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/ethernet/brocade/bna/bfa_ioc.c:790:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/brocade/bna/bfa_ioc.c:860:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/brocade/bna/bfa_ioc.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index a36e38676640..cbc9175d74c5 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -788,9 +788,8 @@ bfa_iocpf_sm_enabling(struct bfa_iocpf *iocpf, enum iocpf_event event)
case IOCPF_E_INITFAIL:
del_timer(&ioc->iocpf_timer);
- /*
- * !!! fall through !!!
- */
+ /* fall through */
+
case IOCPF_E_TIMEOUT:
bfa_nw_ioc_hw_sem_release(ioc);
if (event == IOCPF_E_TIMEOUT) @@ -858,9 +857,7 @@ bfa_iocpf_sm_disabling(struct bfa_iocpf *iocpf, enum iocpf_event event)
case IOCPF_E_FAIL:
del_timer(&ioc->iocpf_timer);
- /*
- * !!! fall through !!!
- */
+ /* fall through*/
case IOCPF_E_TIMEOUT:
bfa_ioc_set_cur_ioc_fwstate(ioc, BFI_IOC_FAIL);
--
2.20.1
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
^ permalink raw reply related
* [PATCH net-next] qed: Mark expected switch fall-through
From: Gustavo A. R. Silva @ 2019-01-23 7:59 UTC (permalink / raw)
To: Ariel Elior, everest-linux-l2, David S. Miller
Cc: netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warning:
drivers/net/ethernet/qlogic/qed/qed_cxt.c:2126:4: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/qlogic/qed/qed_cxt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_cxt.c b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
index c2ad405b2f50..35c9f484eb9f 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_cxt.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_cxt.c
@@ -2129,6 +2129,7 @@ int qed_cxt_set_pf_params(struct qed_hwfn *p_hwfn, u32 rdma_tasks)
rdma_tasks);
/* no need for break since RoCE coexist with Ethernet */
}
+ /* fall through */
case QED_PCI_ETH:
{
struct qed_eth_pf_params *p_params =
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] bna: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-01-23 7:53 UTC (permalink / raw)
To: Rasesh Mody, Sudarsana Kalluru, Dept-GELinuxNICDev,
David S. Miller
Cc: netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/ethernet/brocade/bna/bfa_ioc.c:790:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/brocade/bna/bfa_ioc.c:860:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/brocade/bna/bfa_ioc.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/net/ethernet/brocade/bna/bfa_ioc.c b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
index a36e38676640..cbc9175d74c5 100644
--- a/drivers/net/ethernet/brocade/bna/bfa_ioc.c
+++ b/drivers/net/ethernet/brocade/bna/bfa_ioc.c
@@ -788,9 +788,8 @@ bfa_iocpf_sm_enabling(struct bfa_iocpf *iocpf, enum iocpf_event event)
case IOCPF_E_INITFAIL:
del_timer(&ioc->iocpf_timer);
- /*
- * !!! fall through !!!
- */
+ /* fall through */
+
case IOCPF_E_TIMEOUT:
bfa_nw_ioc_hw_sem_release(ioc);
if (event == IOCPF_E_TIMEOUT)
@@ -858,9 +857,7 @@ bfa_iocpf_sm_disabling(struct bfa_iocpf *iocpf, enum iocpf_event event)
case IOCPF_E_FAIL:
del_timer(&ioc->iocpf_timer);
- /*
- * !!! fall through !!!
- */
+ /* fall through*/
case IOCPF_E_TIMEOUT:
bfa_ioc_set_cur_ioc_fwstate(ioc, BFI_IOC_FAIL);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH bpf-next v2] bpf: btf: add btf documentation
From: Alexei Starovoitov @ 2019-01-23 7:51 UTC (permalink / raw)
To: Yonghong Song
Cc: Alexei Starovoitov, Daniel Borkmann, Network Development,
Edward Cree, Kernel Team
In-Reply-To: <20190118215649.4029880-1-yhs@fb.com>
On Fri, Jan 18, 2019 at 2:00 PM Yonghong Song <yhs@fb.com> wrote:
>
> This patch added documentation for BTF (BPF Debug Format).
> The document is placed under linux:Documentation/bpf directory.
>
> Signed-off-by: Yonghong Song <yhs@fb.com>
> ---
> Documentation/bpf/btf.rst | 870 ++++++++++++++++++++++++++++++++++++
> Documentation/bpf/index.rst | 7 +
> 2 files changed, 877 insertions(+)
> create mode 100644 Documentation/bpf/btf.rst
>
> Changelogs:
> v1 -> v2:
> address comments from Edward, mainly including:
> . more detailed explanation of BTF_INT_OFFSET().
> . more explanation about array dimensions.
> . better wording refers to "type" field in btf_type
> for typedef/const/volatile/restrict.
> . better explanation for BTF_KIND_FUNC.
> . explanation of what is btf_id.
> . more cross references inside the document.
Looks great to me. Applied to bpf-next.
^ permalink raw reply
* [PATCH net-next] intel: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-01-23 7:48 UTC (permalink / raw)
To: Jeff Kirsher, David S. Miller
Cc: intel-wired-lan, netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/ethernet/intel/igb/e1000_82575.c:636:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/intel/igb/igb_main.c:6710:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/intel/i40e/i40e_xsk.c:237:3: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/intel/i40e/i40e_xsk.c | 3 ++-
drivers/net/ethernet/intel/igb/e1000_82575.c | 2 +-
drivers/net/ethernet/intel/igb/igb_main.c | 2 +-
3 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_xsk.c b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
index 96d849460d9b..774e31405ba0 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_xsk.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_xsk.c
@@ -235,9 +235,10 @@ static int i40e_run_xdp_zc(struct i40e_ring *rx_ring, struct xdp_buff *xdp)
break;
default:
bpf_warn_invalid_xdp_action(act);
+ /* fall through */
case XDP_ABORTED:
trace_xdp_exception(rx_ring->netdev, xdp_prog, act);
- /* fallthrough -- handle aborts by dropping packet */
+ /* fall through - handle aborts by dropping packet */
case XDP_DROP:
result = I40E_XDP_CONSUMED;
break;
diff --git a/drivers/net/ethernet/intel/igb/e1000_82575.c b/drivers/net/ethernet/intel/igb/e1000_82575.c
index bafdcf70a353..3ec2ce0725d5 100644
--- a/drivers/net/ethernet/intel/igb/e1000_82575.c
+++ b/drivers/net/ethernet/intel/igb/e1000_82575.c
@@ -638,7 +638,7 @@ static s32 igb_get_invariants_82575(struct e1000_hw *hw)
dev_spec->sgmii_active = true;
break;
}
- /* fall through for I2C based SGMII */
+ /* fall through - for I2C based SGMII */
case E1000_CTRL_EXT_LINK_MODE_PCIE_SERDES:
/* read media type from SFP EEPROM */
ret_val = igb_set_sfp_media_type_82575(hw);
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index dfa357b1a9d6..2c88e47574a7 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -6713,7 +6713,7 @@ static int __igb_notify_dca(struct device *dev, void *data)
igb_setup_dca(adapter);
break;
}
- /* Fall Through since DCA is disabled. */
+ /* Fall Through - since DCA is disabled. */
case DCA_PROVIDER_REMOVE:
if (adapter->flags & IGB_FLAG_DCA_ENABLED) {
/* without this a class_device is left
--
2.20.1
^ permalink raw reply related
* Re: [PATCH bpf-next v5 0/9] tools: bpftool: add probes for system and device
From: Alexei Starovoitov @ 2019-01-23 7:48 UTC (permalink / raw)
To: Quentin Monnet; +Cc: Alexei Starovoitov, Daniel Borkmann, Network Development
In-Reply-To: <CAADnVQJJvWEYjpzEvaXnO19KcxLJjdf+vEmtRqfW-9O42Nmmfw@mail.gmail.com>
On Tue, Jan 22, 2019 at 10:39 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Thu, Jan 17, 2019 at 7:28 AM Quentin Monnet
> <quentin.monnet@netronome.com> wrote:
> >
> >
> > If the user does not have root privileges (or more precisely, the
> > CAP_SYS_ADMIN capability) detection will be erroneous for most
> > parameters. Therefore, forbid non-root users to run the command.
> >
> > v5:
> > - Move exported symbols to a new LIBBPF_0.0.2 section in libbpf.map
> > (patches 4 to 6).
> > - Minor fixes on patches 3 and 4.
>
> I was about to apply the set,
> but while testing on older kernels bpftool crashed the box.
> It's a kernel bug, no doubt, but bpftool shouldn't be doing
> dangerous operations if it can potentially crash it.
> I'm debugging what went wrong.
> It crashed after this message:
> CONFIG_XFRM is set to y
> dmesg was:
> [1757577.380114] BUG: unable to handle kernel
> [1757577.388476] NULL pointer dereference
> [1757577.395957] at (null)
> [1757577.402752] IP: (null)
> [1757577.421265] Call Trace:
> [1757577.421269] ? SyS_bpf+0x18b/0x16b0
> [1757577.421272] ? __audit_syscall_entry+0xb5/0x100
> [1757577.421277] do_syscall_64+0x53/0x150
> Not sure how that was possible.
> I'm still debugging.
Changed my mind and applied to bpf-next.
Turned out that one of the map types was defined in ops,
but body was not backported due to large dependencies
not suitable for backport.
That caused map_create syscall to crash.
Will send a separate fix to improve backport resilience.
^ permalink raw reply
* RE: [PATCH net-next] broadcom: Mark expected switch fall-throughs
From: Sudarsana Reddy Kalluru @ 2019-01-23 7:47 UTC (permalink / raw)
To: Gustavo A. R. Silva, Ariel Elior, everest-linux-l2@cavium.com,
David S. Miller, Siva Reddy Kallam, Prashant Sreedharan,
Michael Chan
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20190123074119.GA18304@embeddedor>
-----Original Message-----
From: Gustavo A. R. Silva [mailto:gustavo@embeddedor.com]
Sent: 23 January 2019 13:11
To: Ariel Elior <ariel.elior@cavium.com>; Sudarsana Kalluru <sudarsana.kalluru@cavium.com>; everest-linux-l2@cavium.com; David S. Miller <davem@davemloft.net>; Siva Reddy Kallam <siva.kallam@broadcom.com>; Prashant Sreedharan <prashant@broadcom.com>; Michael Chan <mchan@broadcom.com>
Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Gustavo A. R. Silva <gustavo@embeddedor.com>
Subject: [PATCH net-next] broadcom: Mark expected switch fall-throughs
External Email
In preparation to enabling -Wimplicit-fallthrough, mark switch cases where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c:6336:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2231:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/broadcom/tg3.c:722:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/broadcom/tg3.c:783:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling -Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 2 +- drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index 29738dfa878c..d581d0ae6584 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -6335,7 +6335,7 @@ int bnx2x_set_led(struct link_params *params,
*/
if (!vars->link_up)
break;
- /* else: fall through */
+ /* fall through */
case LED_MODE_ON:
if (((params->phy[EXT_PHY1].type ==
PORT_HW_CFG_XGXS_EXT_PHY_TYPE_BCM8727) || diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index c835f6c7ecd0..c97b642e6537 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -2230,7 +2230,7 @@ int bnx2x_vf_free(struct bnx2x *bp, struct bnx2x_virtf *vf)
rc = bnx2x_vf_close(bp, vf);
if (rc)
goto op_err;
- /* Fallthrough to release resources */
+ /* Fall through - to release resources */
case VF_ACQUIRED:
DP(BNX2X_MSG_IOV, "about to free resources\n");
bnx2x_vf_free_resc(bp, vf); diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index b1627dd5f2fd..328373e0578f 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -721,7 +721,7 @@ static int tg3_ape_lock(struct tg3 *tp, int locknum)
case TG3_APE_LOCK_GPIO:
if (tg3_asic_rev(tp) == ASIC_REV_5761)
return 0;
- /* else: fall through */
+ /* fall through */
case TG3_APE_LOCK_GRC:
case TG3_APE_LOCK_MEM:
if (!tp->pci_fn)
@@ -782,7 +782,7 @@ static void tg3_ape_unlock(struct tg3 *tp, int locknum)
case TG3_APE_LOCK_GPIO:
if (tg3_asic_rev(tp) == ASIC_REV_5761)
return;
- /* else: fall through */
+ /* fall through */
case TG3_APE_LOCK_GRC:
case TG3_APE_LOCK_MEM:
if (!tp->pci_fn)
--
2.20.1
Acked-by: Sudarsana Kalluru <Sudarsana.Kalluru@cavium.com>
^ permalink raw reply related
* [PATCH net-next] broadcom: Mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-01-23 7:41 UTC (permalink / raw)
To: Ariel Elior, Sudarsana Kalluru, everest-linux-l2, David S. Miller,
Siva Reddy Kallam, Prashant Sreedharan, Michael Chan
Cc: netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c:6336:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c:2231:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/broadcom/tg3.c:722:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/broadcom/tg3.c:783:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 2 +-
drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c | 2 +-
drivers/net/ethernet/broadcom/tg3.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
index 29738dfa878c..d581d0ae6584 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c
@@ -6335,7 +6335,7 @@ int bnx2x_set_led(struct link_params *params,
*/
if (!vars->link_up)
break;
- /* else: fall through */
+ /* fall through */
case LED_MODE_ON:
if (((params->phy[EXT_PHY1].type ==
PORT_HW_CFG_XGXS_EXT_PHY_TYPE_BCM8727) ||
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
index c835f6c7ecd0..c97b642e6537 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.c
@@ -2230,7 +2230,7 @@ int bnx2x_vf_free(struct bnx2x *bp, struct bnx2x_virtf *vf)
rc = bnx2x_vf_close(bp, vf);
if (rc)
goto op_err;
- /* Fallthrough to release resources */
+ /* Fall through - to release resources */
case VF_ACQUIRED:
DP(BNX2X_MSG_IOV, "about to free resources\n");
bnx2x_vf_free_resc(bp, vf);
diff --git a/drivers/net/ethernet/broadcom/tg3.c b/drivers/net/ethernet/broadcom/tg3.c
index b1627dd5f2fd..328373e0578f 100644
--- a/drivers/net/ethernet/broadcom/tg3.c
+++ b/drivers/net/ethernet/broadcom/tg3.c
@@ -721,7 +721,7 @@ static int tg3_ape_lock(struct tg3 *tp, int locknum)
case TG3_APE_LOCK_GPIO:
if (tg3_asic_rev(tp) == ASIC_REV_5761)
return 0;
- /* else: fall through */
+ /* fall through */
case TG3_APE_LOCK_GRC:
case TG3_APE_LOCK_MEM:
if (!tp->pci_fn)
@@ -782,7 +782,7 @@ static void tg3_ape_unlock(struct tg3 *tp, int locknum)
case TG3_APE_LOCK_GPIO:
if (tg3_asic_rev(tp) == ASIC_REV_5761)
return;
- /* else: fall through */
+ /* fall through */
case TG3_APE_LOCK_GRC:
case TG3_APE_LOCK_MEM:
if (!tp->pci_fn)
--
2.20.1
^ permalink raw reply related
* [PATCH net-next] net: 3c509: mark expected switch fall-throughs
From: Gustavo A. R. Silva @ 2019-01-23 7:29 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, linux-kernel, Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
This patch fixes the following warnings:
drivers/net/ethernet/3com/3c509.c:1265:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
drivers/net/ethernet/3com/3c509.c:1271:8: warning: this statement may fall through [-Wimplicit-fallthrough=]
Warning level 3 was used: -Wimplicit-fallthrough=3
This patch is part of the ongoing efforts to enabling
-Wimplicit-fallthrough.
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
---
drivers/net/ethernet/3com/3c509.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/ethernet/3com/3c509.c b/drivers/net/ethernet/3com/3c509.c
index b223769d6a5e..3da97996bdf3 100644
--- a/drivers/net/ethernet/3com/3c509.c
+++ b/drivers/net/ethernet/3com/3c509.c
@@ -1266,12 +1266,14 @@ el3_up(struct net_device *dev)
pr_cont("Forcing 3c5x9b full-duplex mode");
break;
}
+ /* fall through */
case 8:
/* set full-duplex mode based on eeprom config setting */
if ((sw_info & 0x000f) && (sw_info & 0x8000)) {
pr_cont("Setting 3c5x9b full-duplex mode (from EEPROM configuration bit)");
break;
}
+ /* fall through */
default:
/* xcvr=(0 || 4) OR user has an old 3c5x9 non "B" model */
pr_cont("Setting 3c5x9/3c5x9B half-duplex mode");
--
2.20.1
^ permalink raw reply related
* general protection fault in rxrpc_connect_call
From: syzbot @ 2019-01-23 7:27 UTC (permalink / raw)
To: davem, dhowells, linux-afs, linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 787a3b432276 Merge branch 'for-linus' of git://git.kernel...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=104f80c0c00000
kernel config: https://syzkaller.appspot.com/x/.config?x=505743eba4e4f68
dashboard link: https://syzkaller.appspot.com/bug?extid=7966f2a0b2c7da8939b4
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
userspace arch: i386
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=15dc0930c00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=10f3766b400000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7966f2a0b2c7da8939b4@syzkaller.appspotmail.com
audit: type=1800 audit(1548224295.427:29): pid=7748 uid=0 auid=4294967295
ses=4294967295 subj==unconfined op=collect_data cause=failed(directio)
comm="startpar" name="rc.local" dev="sda1" ino=2432 res=0
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] PREEMPT SMP KASAN
CPU: 0 PID: 7899 Comm: syz-executor751 Not tainted 5.0.0-rc3+ #39
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
RIP: 0010:rxrpc_connect_call+0x1a3/0x5130 net/rxrpc/conn_client.c:690
Code: fa 4c 89 f0 48 c1 e8 03 80 3c 18 00 0f 85 01 46 00 00 48 b8 00 00 00
00 00 fc ff df 49 8b 1e 48 8d 7b 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 07 46 00 00 48 8b 5b 18 48 8d bb f0 01 00 00 48
RSP: 0018:ffff88808889ee90 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff88808ca0596c
RDX: 0000000000000003 RSI: ffffffff873650fa RDI: 0000000000000018
RBP: ffff88808889f3a8 R08: 00000000006000c0 R09: ffff8880a9620d20
R10: ffff8880a9620480 R11: 0000000000000000 R12: ffff8880a9177b40
R13: ffff88809a470160 R14: ffff88808889f6c8 R15: ffff8880a9177cc8
FS: 0000000000000000(0000) GS:ffff8880ae600000(0063) knlGS:0000000008b34840
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000020000040 CR3: 0000000090872000 CR4: 00000000001406f0
Call Trace:
rxrpc_new_client_call+0xb0b/0x1e50 net/rxrpc/call_object.c:291
rxrpc_new_client_call_for_sendmsg net/rxrpc/sendmsg.c:593 [inline]
rxrpc_do_sendmsg+0x16df/0x27ad net/rxrpc/sendmsg.c:649
rxrpc_sendmsg+0x4b8/0x5f0 net/rxrpc/af_rxrpc.c:556
sock_sendmsg_nosec net/socket.c:621 [inline]
sock_sendmsg+0xdd/0x130 net/socket.c:631
___sys_sendmsg+0x409/0x910 net/socket.c:2116
__sys_sendmmsg+0x3bc/0x730 net/socket.c:2204
__compat_sys_sendmmsg net/compat.c:771 [inline]
__do_compat_sys_sendmmsg net/compat.c:778 [inline]
__se_compat_sys_sendmmsg net/compat.c:775 [inline]
__ia32_compat_sys_sendmmsg+0x9f/0x100 net/compat.c:775
do_syscall_32_irqs_on arch/x86/entry/common.c:326 [inline]
do_fast_syscall_32+0x333/0xf98 arch/x86/entry/common.c:397
entry_SYSENTER_compat+0x70/0x7f arch/x86/entry/entry_64_compat.S:139
RIP: 0023:0xf7f17869
Code: 85 d2 74 02 89 0a 5b 5d c3 8b 04 24 c3 8b 14 24 c3 8b 3c 24 c3 90 90
90 90 90 90 90 90 90 90 90 90 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90
90 90 90 eb 0d 90 90 90 90 90 90 90 90 90 90 90 90
RSP: 002b:00000000ff96366c EFLAGS: 00000217 ORIG_RAX: 0000000000000159
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 0000000020005c00
RDX: 0000000000000001 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000020000040 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
Modules linked in:
---[ end trace 32887e7d2c420b9a ]---
RIP: 0010:rxrpc_connect_call+0x1a3/0x5130 net/rxrpc/conn_client.c:690
Code: fa 4c 89 f0 48 c1 e8 03 80 3c 18 00 0f 85 01 46 00 00 48 b8 00 00 00
00 00 fc ff df 49 8b 1e 48 8d 7b 18 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f
85 07 46 00 00 48 8b 5b 18 48 8d bb f0 01 00 00 48
RSP: 0018:ffff88808889ee90 EFLAGS: 00010206
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffff88808ca0596c
RDX: 0000000000000003 RSI: ffffffff873650fa RDI: 0000000000000018
RBP: ffff88808889f3a8 R08: 00000000006000c0 R09: ffff8880a9620d20
R10: ffff8880a9620480 R11: 0000000000000000 R12: ffff8880a9177b40
R13: ffff88809a470160 R14: ffff88808889f6c8 R15: ffff8880a9177cc8
FS: 0000000000000000(0000) GS:ffff8880ae600000(0063) knlGS:0000000008b34840
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 0000000020000040 CR3: 0000000090872000 CR4: 00000000001406f0
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#bug-status-tracking for how to communicate with
syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
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