Netdev List
 help / color / mirror / Atom feed
* Re: [PATCH v2 1/2] net: phy: at803x: dont inline helpers
From: David Miller @ 2019-02-19  0:28 UTC (permalink / raw)
  To: vkoul
  Cc: linux-arm-msm, bjorn.andersson, netdev, niklas.cassel, andrew,
	f.fainelli, nsekhar, peter.ujfalusi, marc.w.gonzalez
In-Reply-To: <20190218101853.4290-1-vkoul@kernel.org>

From: Vinod Koul <vkoul@kernel.org>
Date: Mon, 18 Feb 2019 15:48:52 +0530

> Some helpers were inlined, but makes more sense to allow compiler
> to do the right optiomazations instead, so remove inline for
> at803x_disable_rx_delay() and at803x_disable_tx_delay()
> 
> Signed-off-by: Vinod Koul <vkoul@kernel.org>

Two problem with this patch series.

1) It fixes a bug in 'net' but the patches only apply cleanly to
   'net-next'.  Please respin this against 'net'.

2) This series lacks a header posting "[PATCH vX 0/N] " which
   explains at a high level what the series is doing, how it is
   doing it, and why it is doing it that way.

Thanks.

^ permalink raw reply

* Re: [PATCH net] mac80211: mesh: fix missing unlock on error in table_path_del()
From: David Miller @ 2019-02-19  0:30 UTC (permalink / raw)
  To: johannes; +Cc: linux-wireless, netdev, herbert, weiyongjun1
In-Reply-To: <20190218102929.22276-1-johannes@sipsolutions.net>

From: Johannes Berg <johannes@sipsolutions.net>
Date: Mon, 18 Feb 2019 11:29:29 +0100

> From: Wei Yongjun <weiyongjun1@huawei.com>
> 
> spin_lock_bh() is used in table_path_del() but rcu_read_unlock()
> is used for unlocking. Fix it by using spin_unlock_bh() instead
> of rcu_read_unlock() in the error handling case.
> 
> Fixes: b4c3fbe63601 ("mac80211: Use linked list instead of rhashtable walk for mesh tables")
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> Dave, can you take this directly? I see little value in sending a
> pull request for this one patch (but if you prefer can do so.)

Applied, thanks Johannes.

^ permalink raw reply

* linux-next: manual merge of the net-next tree with the net tree
From: Stephen Rothwell @ 2019-02-19  0:30 UTC (permalink / raw)
  To: David Miller, Networking
  Cc: Linux Next Mailing List, Linux Kernel Mailing List, Eric Dumazet

[-- Attachment #1: Type: text/plain, Size: 1305 bytes --]

Hi all,

Today's linux-next merge of the net-next tree got a conflict in:

  net/ipv4/tcp.c

between commit:

  04c03114be82 ("tcp: clear icsk_backoff in tcp_write_queue_purge()")

from the net tree and commit:

  3a9a57f63794 ("tcp: move snd_cwnd & snd_cwnd_cnt init to tcp_disconnect()")

from the net-next tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc net/ipv4/tcp.c
index cf3c5095c10e,cab6b2f2f61d..000000000000
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@@ -2577,9 -2595,11 +2596,10 @@@ int tcp_disconnect(struct sock *sk, in
  	tp->write_seq += tp->max_window + 2;
  	if (tp->write_seq == 0)
  		tp->write_seq = 1;
- 	tp->snd_cwnd = 2;
 -	icsk->icsk_backoff = 0;
  	icsk->icsk_probes_out = 0;
+ 	icsk->icsk_rto = TCP_TIMEOUT_INIT;
  	tp->snd_ssthresh = TCP_INFINITE_SSTHRESH;
+ 	tp->snd_cwnd = TCP_INIT_CWND;
  	tp->snd_cwnd_cnt = 0;
  	tp->window_clamp = 0;
  	tp->delivered_ce = 0;

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply

* Re: [PATCH v2 net-next] mdio_bus: Fix PTR_ERR() usage after initialization to constant
From: David Miller @ 2019-02-19  0:36 UTC (permalink / raw)
  To: yuehaibing; +Cc: andrew, f.fainelli, hkallweit1, linux-kernel, netdev
In-Reply-To: <20190216025935.22888-1-yuehaibing@huawei.com>

From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 16 Feb 2019 10:59:35 +0800

> Fix coccinelle warning:
> 
> ./drivers/net/phy/mdio_bus.c:51:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
> ./drivers/net/phy/mdio_bus.c:52:5-12: ERROR: PTR_ERR applied after initialization to constant on line 44
> 
> fix this by using IS_ERR before PTR_ERR
> 
> Fixes: bafbdd527d56 ("phylib: Add device reset GPIO support")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> v2: remove variable 'ret'

Applied.

^ permalink raw reply

* Re: [PATCH] net: sched: using kfree_rcu() to simplify the code
From: David Miller @ 2019-02-19  0:36 UTC (permalink / raw)
  To: weiyongjun1; +Cc: jhs, xiyou.wangcong, jiri, netdev, kernel-janitors
In-Reply-To: <20190216081955.93243-1-weiyongjun1@huawei.com>

From: Wei Yongjun <weiyongjun1@huawei.com>
Date: Sat, 16 Feb 2019 08:19:55 +0000

> The callback function of call_rcu() just calls a kfree(), so we
> can use kfree_rcu() instead of call_rcu() + callback function.
> 
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>

Applied.

^ permalink raw reply

* Re: [PATCH v2] net: dsa: Implement flow_dissect callback for tag_dsa.
From: David Miller @ 2019-02-19  0:36 UTC (permalink / raw)
  To: rdong.ge; +Cc: andrew, vivien.didelot, f.fainelli, netdev, linux-kernel
In-Reply-To: <20190216083524.860-1-rdong.ge@gmail.com>

From: Rundong Ge <rdong.ge@gmail.com>
Date: Sat, 16 Feb 2019 08:35:24 +0000

> RPS not work for DSA devices since the 'skb_get_hash'
> will always get the invalid hash for dsa tagged packets.
> 
> "[PATCH] tag_mtk: add flow_dissect callback to the ops struct"
> introduced the flow_dissect callback to get the right hash for
> MTK tagged packet. Tag_dsa and tag_edsa  also need to implement
> the callback.
> 
> Signed-off-by: Rundong Ge <rdong.ge@gmail.com>

Applied to net-next.

^ permalink raw reply

* Re: [PATCH] r8152: Add support for MAC address pass through on RTL8153-BD
From: David Miller @ 2019-02-19  0:38 UTC (permalink / raw)
  To: david0813
  Cc: linux-usb, netdev, linux-kernel, hayeswang, mario.limonciello,
	bigeasy, edumazet, jslaby, f.fainelli, david.chen7, kai.heng.feng,
	zhongjiang
In-Reply-To: <20190216091642.21388-1-david0813@gmail.com>

From: David Chen <david0813@gmail.com>
Date: Sat, 16 Feb 2019 17:16:42 +0800

> From: David Chen <david.chen7@dell.com>
> 
> RTL8153-BD is used in Dell DA300 type-C dongle.
> It should be added to the whitelist of devices to activate MAC address
> pass through.
> 
> Per confirming with Realtek all devices containing RTL8153-BD should
> activate MAC pass through and there won't use pass through bit on efuse
> like in RTL8153-AD.
> 
> Signed-off-by: David Chen <david.chen7@dell.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net-next] r8169: remove unneeded mmiowb barriers
From: David Miller @ 2019-02-19  0:39 UTC (permalink / raw)
  To: hkallweit1; +Cc: nic_swsd, netdev
In-Reply-To: <10883db9-493c-7434-2379-de79712cee85@gmail.com>

From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 16 Feb 2019 10:20:15 +0100

> writex() has implicit barriers, that's what makes it different from
> writex_relaxed(). Therefore these calls to mmiowb() can be removed.
> 
> This patch was recently reverted due to a dependency with another
> problematic patch. But because it didn't contribute to the problem
> it was rebased and can be resubmitted.
> 
> Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next] liquidio: using NULL instead of plain integer
From: David Miller @ 2019-02-19  0:42 UTC (permalink / raw)
  To: yuehaibing; +Cc: dchickles, sburla, fmanlunas, linux-kernel, netdev
In-Reply-To: <20190216095310.22544-1-yuehaibing@huawei.com>

From: YueHaibing <yuehaibing@huawei.com>
Date: Sat, 16 Feb 2019 17:53:10 +0800

> Fix following warning:
> 
> drivers/net/ethernet/cavium/liquidio/cn23xx_pf_device.c:1453:35: warning: Using plain integer as NULL pointer
> drivers/net/ethernet/cavium/liquidio/lio_main.c:2910:23: warning: Using plain integer as NULL pointer
> 
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Applied.

^ permalink raw reply

* Re: [PATCH net-next v2 0/2] net: phy: add helpers for handling C45 10GBT AN register values
From: David Miller @ 2019-02-19  0:44 UTC (permalink / raw)
  To: hkallweit1; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <c6be00e5-d4e5-69a1-cb9c-31cd446556be@gmail.com>

From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Sat, 16 Feb 2019 17:24:58 +0100

> Similar to the existing helpers for the Clause 22 registers add helpers
> to deal with converting Clause 45 advertisement registers to / from
> link mode bitmaps.
> 
> Note that these helpers are defined in linux/mdio.h, not like the
> Clause 22 helpers in linux/mii.h. Reason is that the Clause 45 register
> constants are defined in uapi/linux/mdio.h. And uapi/linux/mdio.h
> includes linux/mii.h before defining the C45 register constants.
> 
> v2:
> - Remove few helpers which aren't used by this series. They will
>   follow together with the users.

Series applied with fuzz on patch #1 :-)))))

^ permalink raw reply

* Re: [PATCH net-next] bnx2x: Remove set but not used variable 'mfw_vn'
From: David Miller @ 2019-02-19  0:48 UTC (permalink / raw)
  To: yuehaibing; +Cc: aelior, skalluru, GR-everest-linux-l2, netdev, kernel-janitors
In-Reply-To: <20190218121954.78928-1-yuehaibing@huawei.com>

From: YueHaibing <yuehaibing@huawei.com>
Date: Mon, 18 Feb 2019 12:19:54 +0000

> Fixes gcc '-Wunused-but-set-variable' warning:
> 
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function 'bnx2x_get_hwinfo':
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:11940:10: warning:
>  variable 'mfw_vn' set but not used [-Wunused-but-set-variable]
> 
> It's never used since introduction.
> 
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>

Applied, thanks.

^ permalink raw reply

* Re: [PATCH net 0/2] qed: iWARP - fix some syn related issues.
From: David Miller @ 2019-02-19  0:52 UTC (permalink / raw)
  To: michal.kalderon; +Cc: ariel.elior, netdev, linux-rdma
In-Reply-To: <20190218132403.12487-1-michal.kalderon@marvell.com>

From: Michal Kalderon <michal.kalderon@marvell.com>
Date: Mon, 18 Feb 2019 15:24:01 +0200

> This series fixes two bugs related to iWARP syn processing flow. 

Series applied, thanks.

^ permalink raw reply

* Re: [PATCH 1/2] wireless: mt76: call hweight8() instead of __sw_hweight8()
From: Masahiro Yamada @ 2019-02-19  1:13 UTC (permalink / raw)
  To: Kalle Valo
  Cc: Ingo Molnar, Thomas Gleixner, Borislav Petkov, H . Peter Anvin,
	X86 ML, linux-wireless, Christoph Hellwig, David S. Miller,
	Networking, Linux Kernel Mailing List, Lorenzo Bianconi,
	moderated list:ARM/Mediatek SoC support, linux-arm-kernel,
	Felix Fietkau, Matthias Brugger
In-Reply-To: <87pnrosy29.fsf@kamboji.qca.qualcomm.com>

On Tue, Feb 19, 2019 at 4:38 AM Kalle Valo <kvalo@codeaurora.org> wrote:
>
> Kalle Valo <kvalo@codeaurora.org> writes:
>
> > Kalle Valo <kvalo@codeaurora.org> writes:
> >
> >> Masahiro Yamada <yamada.masahiro@socionext.com> writes:
> >>
> >>> __sw_hweight8() is just internal implementation.
> >>>
> >>> Drivers should use the common API, hweight8().
> >>>
> >>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> >>
> >> Acked-by: Kalle Valo <kvalo@codeaurora.org>
> >>
> >>> This patch should go to x86 tree along with 2/2.
> >>>
> >>> Otherwise, all{yes,mod}config of x86 would be broken.
> >>>
> >>> This patch is trivial enough.
> >>> I want ACK from the net/wireless maintainer
> >>> so that this can go in via x86 tree.
> >>
> >> Sounds good to me, feel free to push via the x86 tree.
> >
> > Actually, can you wait a bit? Felix just reminded me that we have a
> > similar patch pending from Ben Hutchings:
> >
> > https://patchwork.kernel.org/patch/10808203/
> >
> > And it seems there are two instances of __sw_hweight8, at least in my
> > wireless-drivers-next tree:
> >
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int i, nstream =
> > __sw_hweight8(dev->antenna_mask);
> > drivers/net/wireless/mediatek/mt76/mac80211.c: int n_chains =
> > __sw_hweight8(dev->antenna_mask);
> >
> > So we need to think what to do.
>
> I think the best would be that Felix applies Ben's patch to the wireless
> tree and I'll push it to Linus during the next merge window (via
> net-next). Simpler and less conflicts that way.
>
> So Masahiro, could you hold your x86 patch for a while until the mt76
> patch will be in Linus' tree? That should not take more than two weeks,
> I think.

Sure.
I will resend 2/2 later.




-- 
Best Regards
Masahiro Yamada

^ permalink raw reply

* Re: [PATCH] NETWORKING: avoid use IPCB in cipso_v4_error
From: David Miller @ 2019-02-19  1:25 UTC (permalink / raw)
  To: s-nazarov; +Cc: paul, netdev, linux-security-module, kuznet, yoshfuji
In-Reply-To: <1122331550497151@iva7-d29a8296bc3c.qloud-c.yandex.net>

From: Nazarov Sergey <s-nazarov@yandex.ru>
Date: Mon, 18 Feb 2019 16:39:11 +0300

> I think, it would not be a good solution, if I will analyze all
> subsystems using icmp_send, because I do not have enough knowledge
> for this.  I propose to add a new function, for example,
> ismp_send_safe, something like that:

Please don't do this.

Solve the problem properly by auditing each case, there aren't a lot and
it is not too difficult to see the upcall sites.

^ permalink raw reply

* Re: [PATCH][unix] missing barriers in some of unix_sock ->addr and ->path accesses
From: Sasha Levin @ 2019-02-19  1:30 UTC (permalink / raw)
  To: Al Viro; +Cc: netdev, David Miller, stable, stable
In-Reply-To: <20190218213246.GV2217@ZenIV.linux.org.uk>

On Mon, Feb 18, 2019 at 09:32:46PM +0000, Al Viro wrote:
>On Mon, Feb 18, 2019 at 09:14:33PM +0000, Sasha Levin wrote:
>> Hi,
>>
>> [This is an automated email]
>>
>> This commit has been processed because it contains a -stable tag.
>
>Ugh...  Should've removed Cc; stable from netdev posting; my apologies.
>
>> How should we proceed with this patch?
>
>Wait for it to get into davem's tree, for starters?

It won't go in stable until it's upstream, the only reason for this
early mail is that it's easier to get responses from people while the
patch is still fresh in their brains (as you might have noticed ;) )
rather than in a few weeks.

--
Thanks,
Sasha

^ permalink raw reply

* Re: [PATCH net] net: stmmac: Fix a race in EEE enable callback
From: David Miller @ 2019-02-19  1:40 UTC (permalink / raw)
  To: jose.abreu
  Cc: netdev, linux-kernel, joao.pinto, peppe.cavallaro,
	alexandre.torgue
In-Reply-To: <fb866bb5dd8a11326fab8e6d393f2a37eed5073f.1550496861.git.joabreu@synopsys.com>

From: Jose Abreu <jose.abreu@synopsys.com>
Date: Mon, 18 Feb 2019 14:35:03 +0100

> We are saving the status of EEE even before we try to enable it. This
> leads to a race with XMIT function that tries to arm EEE timer before we
> set it up.
> 
> Fix this by only saving the EEE parameters after all operations are
> performed with success.
> 
> Signed-off-by: Jose Abreu <joabreu@synopsys.com>
> Fixes: d765955d2ae0 ("stmmac: add the Energy Efficient Ethernet support")

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: pull-request: wireless-drivers 2019-02-18
From: David Miller @ 2019-02-19  1:41 UTC (permalink / raw)
  To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87zhqtt98h.fsf@kamboji.qca.qualcomm.com>

From: Kalle Valo <kvalo@codeaurora.org>
Date: Mon, 18 Feb 2019 17:19:26 +0200

> here's one more pull request to net tree for 5.0. Please let me know if
> you have any problems.

Pulled, thanks Kalle.

^ permalink raw reply

* Re: [PATCH net] net: hns: Fixes the missing put_device in positive leg for roce reset
From: David Miller @ 2019-02-19  1:45 UTC (permalink / raw)
  To: salil.mehta
  Cc: yisen.zhuang, lipeng321, mehta.salil, netdev, linux-kernel,
	linux-rdma, linuxarm
In-Reply-To: <20190218174032.22972-1-salil.mehta@huawei.com>

From: Salil Mehta <salil.mehta@huawei.com>
Date: Mon, 18 Feb 2019 17:40:32 +0000

> This patch fixes the missing device reference release-after-use in
> the positive leg of the roce reset API of the HNS DSAF.
> 
> Fixes: c969c6e7ab8c ("net: hns: Fix object reference leaks in hns_dsaf_roce_reset()")
> Reported-by: John Garry <john.garry@huawei.com>
> Signed-off-by: Salil Mehta <salil.mehta@huawei.com>

Applied, thanks Salil.

^ permalink raw reply

* Re: [PATCH] net: netcp: Fix ethss driver probe issue
From: David Miller @ 2019-02-19  1:50 UTC (permalink / raw)
  To: m-karicheri2; +Cc: w-kwok2, netdev, linux-kernel
In-Reply-To: <20190218201051.19623-1-m-karicheri2@ti.com>

From: Murali Karicheri <m-karicheri2@ti.com>
Date: Mon, 18 Feb 2019 15:10:51 -0500

> Recent commit below has introduced a bug in netcp driver that causes
> the ethss driver probe failure and thus break the networking function
> on K2 SoCs such as K2HK, K2L, K2E etc. This patch fixes the issue to
> restore networking on the above SoCs.
> 
> Fixes: 21c328dcecfc ("net: ethernet: Convert to using %pOFn instead of device_node.name")
> Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>

Applied and queued up for -stable, thanks.

^ permalink raw reply

* Re: [PATCH v2] bonding: fix PACKET_ORIGDEV regression
From: David Ahern @ 2019-02-19  1:51 UTC (permalink / raw)
  To: Michal Soltys, David Miller
  Cc: Maciej Żenczykowski, Jay Vosburgh, Vincent Bernat,
	Mahesh Bandewar, Chonggang Li, Linux NetDev
In-Reply-To: <20190218165528.15575-1-soltys@ziu.info>

On 2/18/19 9:55 AM, Michal Soltys wrote:
> This patch fixes a subtle PACKET_ORIGDEV regression which was a side
> effect of fixes introduced by:
> 
> 6a9e461f6fe4 bonding: pass link-local packets to bonding master also.
> 
> ... to:
> 
> b89f04c61efe bonding: deliver link-local packets with skb->dev set to link that packets arrived on
> 
> While 6a9e461f6fe4 restored pre-b89f04c61efe presence of link-local
> packets on bonding masters (which is required e.g. by linux bridges
> participating in spanning tree or needed for lab-like setups created
> with group_fwd_mask) it also caused the originating device
> information to be lost due to cloning.
> 
> Maciej Żenczykowski proposed another solution that doesn't require
> packet cloning and retains original device information - instead of
> returning RX_HANDLER_PASS for all link-local packets it's now limited
> only to packets from inactive slaves.
> 
> At the same time, packets passed to bonding masters retain correct
> information about the originating device and PACKET_ORIGDEV can be used
> to determine it.
> 
> This elegantly solves all issues so far:
> 
> - link-local packets that were removed from bonding masters
> - LLDP daemons being forced to explicitly bind to slave interfaces
> - PACKET_ORIGDEV having no effect on bond interfaces
> 
> Fixes: 6a9e461f6fe4 (bonding: pass link-local packets to bonding master also.)
> Reported-by: Vincent Bernat <vincent@bernat.ch>
> Signed-off-by: Michal Soltys <soltys@ziu.info>
> ---
>  drivers/net/bonding/bond_main.c | 35 +++++++++++++--------------------
>  1 file changed, 14 insertions(+), 21 deletions(-)
> 

Hi Michal:

Can you add test cases that shows the expectations of this API? Given
the back and forth on the last set of patches -- and the impacts to
lldpd users for example -- we really need test cases added to selftests.

^ permalink raw reply

* Re: [PATCH net v4.15..v4.19] net: dsa: Fix NPD checking for br_vlan_enabled()
From: David Miller @ 2019-02-19  1:54 UTC (permalink / raw)
  To: f.fainelli; +Cc: netdev, frank-w, andrew, vivien.didelot, linux-kernel
In-Reply-To: <20190218223011.4824-1-f.fainelli@gmail.com>

From: Florian Fainelli <f.fainelli@gmail.com>
Date: Mon, 18 Feb 2019 14:30:11 -0800

> It is possible for the DSA slave network device not to be part of a
> bridge, yet have an upper device like a VLAN device be part of a bridge.
> When that VLAN device is enslaved, since it does not define any
> switchdev_ops, we will recurse down to the lower/physical port device,
> call switchdev_port_obj_add() with a VLAN, and here we will check
> br_vlan_enabled() on a NULL dp->bridge_dev, thus causing a NULL pointer
> de-reference.
> 
> This is no longer a problem upstream after commit d17d9f5e5143
> ("switchdev: Replace port obj add/del SDO with a notification").
> 
> Fixes: 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
> Reported-by: Frank Wunderlich <frank-w@public-files.de>
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> David,
> 
> This affects v4.15..v4.19, but not v5.0-rc1 can you still queue this up
> for -stable? Thanks!

Queued up.

^ permalink raw reply

* Re: [PATCH 0/2] Netfilter/IPVS fixes for net
From: David Miller @ 2019-02-19  1:56 UTC (permalink / raw)
  To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20190218230823.8114-1-pablo@netfilter.org>

From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Tue, 19 Feb 2019 00:08:21 +0100

> The following patchset contains Netfilter/IPVS fixes for net:
> 
> 1) Follow up patch to fix a compilation warning in a recent IPVS fix:
>    098e13f5b21d ("ipvs: fix dependency on nf_defrag_ipv6").
> 
> 2) Bogus ENOENT error on flush after rule deletion in the same batch,
>    reported by Phil Sutter.
> 
> You can pull these changes from:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git

Series applied, thanks.

^ permalink raw reply

* [PATCH] net: remove unneeded switch fall-through
From: Li RongQing @ 2019-02-19  2:15 UTC (permalink / raw)
  To: netdev

This case block has been terminated by a return, so not need
a switch fall-through

Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 net/ipv4/igmp.c        | 1 -
 net/ipv6/mcast_snoop.c | 1 -
 2 files changed, 2 deletions(-)

diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index b448cf32296c..6c2febc39dca 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -1541,7 +1541,6 @@ static int ip_mc_check_igmp_msg(struct sk_buff *skb)
 	case IGMP_HOST_LEAVE_MESSAGE:
 	case IGMP_HOST_MEMBERSHIP_REPORT:
 	case IGMPV2_HOST_MEMBERSHIP_REPORT:
-		/* fall through */
 		return 0;
 	case IGMPV3_HOST_MEMBERSHIP_REPORT:
 		return ip_mc_check_igmp_reportv3(skb);
diff --git a/net/ipv6/mcast_snoop.c b/net/ipv6/mcast_snoop.c
index 55e2ac179f28..dddd75d1be0e 100644
--- a/net/ipv6/mcast_snoop.c
+++ b/net/ipv6/mcast_snoop.c
@@ -128,7 +128,6 @@ static int ipv6_mc_check_mld_msg(struct sk_buff *skb)
 	switch (mld->mld_type) {
 	case ICMPV6_MGM_REDUCTION:
 	case ICMPV6_MGM_REPORT:
-		/* fall through */
 		return 0;
 	case ICMPV6_MLD2_REPORT:
 		return ipv6_mc_check_mld_reportv2(skb);
-- 
2.16.2


^ permalink raw reply related

* [PATCH][net-next] bridge: remove redundant check on err in br_multicast_ipv4_rcv
From: Li RongQing @ 2019-02-19  2:17 UTC (permalink / raw)
  To: netdev

br_ip4_multicast_mrd_rcv only return 0 and -ENOMSG,
no other negative value

Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
 net/bridge/br_multicast.c | 7 +------
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 4a048fd1cbea..fe9f2d8ca2c1 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1615,12 +1615,7 @@ static int br_multicast_ipv4_rcv(struct net_bridge *br,
 			if (ip_hdr(skb)->protocol == IPPROTO_PIM)
 				br_multicast_pim(br, port, skb);
 		} else if (ipv4_is_all_snoopers(ip_hdr(skb)->daddr)) {
-			err = br_ip4_multicast_mrd_rcv(br, port, skb);
-
-			if (err < 0 && err != -ENOMSG) {
-				br_multicast_err_count(br, port, skb->protocol);
-				return err;
-			}
+			br_ip4_multicast_mrd_rcv(br, port, skb);
 		}
 
 		return 0;
-- 
2.16.2


^ permalink raw reply related

* Re: [PATCH net-next] yellowfin: fix remove set but not used variable warning
From: YueHaibing @ 2019-02-19  2:34 UTC (permalink / raw)
  To: David Miller; +Cc: yang.wei9, netdev, kernel-janitors
In-Reply-To: <20190218.121337.147896114474592034.davem@davemloft.net>

On 2019/2/19 4:13, David Miller wrote:
> From: YueHaibing <yuehaibing@huawei.com>
> Date: Mon, 18 Feb 2019 08:15:46 +0000
> 
>> @@ -1050,8 +1050,11 @@ static int yellowfin_rx(struct net_device *dev)
>>  		struct sk_buff *rx_skb = yp->rx_skbuff[entry];
>>  		s16 frame_status;
>>  		u16 desc_status;
>> -		int data_size, yf_size;
>> +		int data_size;
>>  		u8 *buf_addr;
>> +#ifdef YF_PROTOTYPE
>> +		int yf_size = sizeof(struct yellowfin_desc);
>> +#endif
> 
> This is just silly.
> 
> Please move this variable declaration and initialization into the
> YF_PROTOTYPE basic block in the code below it, like this:
> 
> #ifdef YF_PROTOTYPE		/* Support for prototype hardware errata. */
> 		} else if ((yp->flags & HasMACAddrBug)  &&
> 			int yf_size = sizeof(struct yellowfin_desc);

There's just in if condition, define the 'yf_size' seems incorrect

maybe we can remove 'yf_size' and use sizeof directly?

> 
> 			!ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
> 						      entry * yf_size),
> 					  dev->dev_addr) &&
> 			!ether_addr_equal(le32_to_cpu(yp->rx_ring_dma +
> 						      entry * yf_size),
> 					  "\377\377\377\377\377\377")) {
> 			if (bogus_rx++ == 0)
> 				netdev_warn(dev, "Bad frame to %pM\n",
> 					    buf_addr);
> #endif
> 
> Thanks.
> 
> .
> 


^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox