* [PATCH net-next] sch_htb: do not report fake rate estimators
From: Eric Dumazet @ 2016-10-21 16:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Jiri Kosina, Jamal Hadi Salim
From: Eric Dumazet <edumazet@google.com>
When I prepared commit d250a5f90e53 ("pkt_sched: gen_estimator: Dont
report fake rate estimators"), htb still had an implicit rate estimator
for all its classes.
Then later, I made this rate estimator optional in commit 64153ce0a7b6
("net_sched: htb: do not setup default rate estimators"), but I forgot
to update htb use of gnet_stats_copy_rate_est()
After this patch, "tc -s qdisc ..." no longer report fake rate
estimators for HTB classes.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/sched/sch_htb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/sched/sch_htb.c b/net/sched/sch_htb.c
index c798d0de8a9daf067cae2485ad6bfeeac039efb0..9926fe4f3b6f7db9aeba22fbbfae3d47c4e2af60 100644
--- a/net/sched/sch_htb.c
+++ b/net/sched/sch_htb.c
@@ -1145,7 +1145,7 @@ htb_dump_class_stats(struct Qdisc *sch, unsigned long arg, struct gnet_dump *d)
if (gnet_stats_copy_basic(qdisc_root_sleeping_running(sch),
d, NULL, &cl->bstats) < 0 ||
- gnet_stats_copy_rate_est(d, NULL, &cl->rate_est) < 0 ||
+ gnet_stats_copy_rate_est(d, &cl->bstats, &cl->rate_est) < 0 ||
gnet_stats_copy_queue(d, NULL, &qs, qlen) < 0)
return -1;
^ permalink raw reply related
* Re: [RFC PATCH 08/13] dwmac-meson8b: add support for phy selection
From: Andrew Lunn @ 2016-10-21 16:08 UTC (permalink / raw)
To: Neil Armstrong
Cc: khilman, carlo, linus.walleij, linux-gpio, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel, netdev
In-Reply-To: <dc810494-6ece-c4ae-d412-ed9af3fac9c2@baylibre.com>
Hi Neil
> Yes this would be a good idea if we were able to scan the internal
> and external PHYs at the same time, but with our limited knowledge
> the values we write in the register seems to switch a mux for the
> whole RMII and MDIO signals to either interface.
Ah, O.K. So you need something like:
drivers/net/phy/mdio-mux-mmioreg.c
This seems to be limited to a single byte for the mux register, so you
might need to make some extensions.
Andrew
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Paul Moore @ 2016-10-21 16:19 UTC (permalink / raw)
To: Cong Wang
Cc: Stephen Smalley, Linux Kernel Network Developers, Elad Raz,
Richard Guy Briggs
In-Reply-To: <CAM_iQpVFWzUm2BJZUs+-LWpKA8kubuKhzyE01_V69TEsrFnm-Q@mail.gmail.com>
On Thu, Oct 20, 2016 at 7:35 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Thu, Oct 20, 2016 at 12:07 PM, Paul Moore <paul@paul-moore.com> wrote:
>> On Thu, Oct 20, 2016 at 2:29 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> On Thu, Oct 20, 2016 at 7:58 AM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>> On 10/20/2016 02:52 AM, Cong Wang wrote:
>>>>> A kernel warning inside __local_bh_enable_ip() was reported by people
>>>>> running SELinux, this is caused due to some SELinux functions
>>>>> (indirectly) call peernet2id() with IRQ disabled in process context,
>>>>> when we re-enable BH with IRQ disabled kernel complains. Shut up this
>>>>> warning by saving IRQ context in peernet2id(), BH is still implicitly
>>>>> disabled.
>>>>
>>>> Not sure this suffices; kill_fasync() -> send_sigio() ->
>>>> send_sigio_to_task() -> sigio_perm() -> security_file_send_sigiotask()
>>>> -> selinux_file_send_sigiotask() -> ... -> audit_log() -> ... ->
>>>> peernet2id()
>>>
>>> Oh, this is a new one. kill_fasync() is called in IRQ handler, so we actually
>>> do multicast in IRQ context.... It makes no sense, netlink multicast could
>>> be very expensive if we have many listeners.
>>
>> I'm sure there are a few others I don't know about, but I believe the
>> only commonly used audit multicast listener is systemd.
>
> But user-space is free to listen to this group, right? If so this is just open
> for a potential DDOS attack.
Listeners are required to have CAP_AUDIT_READ.
>>> I am Cc'ing Richard who added that multicast in audit_log_end(). It seems
>>> not easy to just move the multicast to a workqueue, since the skb is copied
>>> from audit_buffer which is freed immediately after that, probably need another
>>> queue like audit_skb_queue.
>>
>> This approach would double the queue size which is something I want to
>> avoid. I would suggest sticking with a single queue and dealing with
>> the netlink message link fixup and multicast send in the existing
>> netlink unicast thread; basically we would just be moving the
>> multicast code from audit_log_end() into kauditd_thread(). This is
>> the same approach I mentioned earlier off-list.
>
> This is what I did in the follow up patch. I attach the updated version
> in this email for you to review ...
I think there is still some confusion. The second patch you posted
still has two queues with potentially duplicated (minus the length
tweaks) skbs.
What I am talking about is queuing the skb in audit_log_end(), without
any modification, waking up the kauditd_thread, and then letting the
kauditd_thread() function do both the netlink multicast and unicast
sends, complete with the skb_copy() and length tweaks. This way we
only queue one copy of the skb. To help make this more clear, I'll
work up a patch and CC you.
However, let me say this one more time: this is *NOT* a change I want
to make during the -rcX cycle, this is a change that we should do for
-next and submit during the next merge window after is has been tested
and soaked in linux-next. Given where we are at right now - it's
Friday and I expect -rc2 on Sunday - I think the best course of action
is to revert the original patch and move on. I'm going to do that now
and I'll submit it to netdev as soon as I've done some basic sanity
checks.
> ... I still can't make selinux-testsuites working
> on my Fedora even though I have SELinux=enforcing, anyhow I don't
> see any kernel warning in my dmesg at least.
Stephen already responded and I agree with him, it looks like
something might be off with your kernel config. Everything works
correctly for me with upstream and Fedora Rawhide kernels.
>> However, that isn't something I want to mess with as a regression fix,
>> mostly because I really want to see this regression gone by -rc2 as it
>> is making SELinux testing a real pain. If the patch posted at the top
>> of this thread isn't a suitable fix, we really should revert the
>> original patch.
>
> Since you want to test SELinux anyway, please test the attached one.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [PATCH net-next v2 7/9] net: use core MTU range checking in misc drivers
From: Sebastian Reichel @ 2016-10-21 16:22 UTC (permalink / raw)
To: Jarod Wilson
Cc: linux-kernel, netdev, linux-rdma, Stefan Richter, Faisal Latif,
Cliff Whickman, Robin Holt, Jes Sorensen, Marek Lindner,
Simon Wunderlich, Antonio Quartulli, Sathya Prakash, Chaitra P B,
Suganath Prabu Subramani, MPT-FusionLinux.pdl, Felipe Balbi,
Arvid Brodin, Remi Denis-Courmont
In-Reply-To: <20161020175524.6184-8-jarod@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 228 bytes --]
Hi,
On Thu, Oct 20, 2016 at 01:55:22PM -0400, Jarod Wilson wrote:
> hsi/clients/ssi_protocol:
> - use core MTU range checking
> - remove now redundant ssip_pn_set_mtu
Acked-By: Sebastian Reichel <sre@kernel.org>
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] flow_dissector: avoid uninitialized variable access
From: Jiri Pirko @ 2016-10-21 16:31 UTC (permalink / raw)
To: Arnd Bergmann
Cc: David S. Miller, Alexander Duyck, Tom Herbert, Jiri Pirko,
Hadar Hen Zion, Gao Feng, Eric Garver, Amir Vadai, netdev,
linux-kernel
In-Reply-To: <20161021155626.4020344-1-arnd@arndb.de>
Fri, Oct 21, 2016 at 05:55:53PM CEST, arnd@arndb.de wrote:
>gcc warns about an uninitialized pointer dereference in the vlan
>priority handling:
>
>net/core/flow_dissector.c: In function '__skb_flow_dissect':
>net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
>
>From all I can tell, this warning is about a real bug, and we
>should not attempt look up the vlan header if there was
>no vlan tag.
I don't see how vlan could be used uninitialized. But I understand that
this is impossible for gcc to track it. Please just use uninitialized_var()
>
>Fixes: f6a66927692e ("flow_dissector: Get vlan priority in addition to vlan id")
>Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>---
>I'm not sure about this one, please have a closer look at what
>the original code does before applying.
>---
> net/core/flow_dissector.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
>diff --git a/net/core/flow_dissector.c b/net/core/flow_dissector.c
>index 44e6ba9d3a6b..dd6003bf27e1 100644
>--- a/net/core/flow_dissector.c
>+++ b/net/core/flow_dissector.c
>@@ -245,7 +245,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> }
> case htons(ETH_P_8021AD):
> case htons(ETH_P_8021Q): {
>- const struct vlan_hdr *vlan;
>+ const struct vlan_hdr *vlan = NULL;
>
> if (skb && skb_vlan_tag_present(skb))
> proto = skb->protocol;
>@@ -264,7 +264,7 @@ bool __skb_flow_dissect(const struct sk_buff *skb,
> }
>
> skip_vlan = true;
>- if (dissector_uses_key(flow_dissector,
>+ if (vlan && dissector_uses_key(flow_dissector,
> FLOW_DISSECTOR_KEY_VLAN)) {
> key_vlan = skb_flow_dissector_target(flow_dissector,
> FLOW_DISSECTOR_KEY_VLAN,
>--
>2.9.0
>
^ permalink raw reply
* [PATCH 2/2] net: phy: broadcom: Add support for BCM54612E
From: Xo Wang @ 2016-10-21 17:20 UTC (permalink / raw)
To: f.fainelli
Cc: davem, jaedon.shin, netdev, linux-kernel, openbmc, joel, Xo Wang
In-Reply-To: <1477070413-92621-1-git-send-email-xow@google.com>
This PHY has internal delays enabled after reset. This clears the
internal delay enables unless the interface specifically requests them.
Signed-off-by: Xo Wang <xow@google.com>
---
drivers/net/phy/broadcom.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++
include/linux/brcmphy.h | 1 +
2 files changed, 49 insertions(+)
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 870327e..583ef8a 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -337,6 +337,41 @@ static int bcm5481_config_aneg(struct phy_device *phydev)
return ret;
}
+static int bcm54612e_config_aneg(struct phy_device *phydev)
+{
+ int ret;
+
+ /* First, auto-negotiate. */
+ ret = genphy_config_aneg(phydev);
+
+ /* Clear TX internal delay unless requested. */
+ if ((phydev->interface != PHY_INTERFACE_MODE_RGMII_ID) &&
+ (phydev->interface != PHY_INTERFACE_MODE_RGMII_TXID)) {
+ /* Disable TXD to GTXCLK clock delay (default set) */
+ /* Bit 9 is the only field in shadow register 00011 */
+ bcm_phy_write_shadow(phydev, 0x03, 0);
+ }
+
+ /* Clear RX internal delay unless requested. */
+ if ((phydev->interface != PHY_INTERFACE_MODE_RGMII_ID) &&
+ (phydev->interface != PHY_INTERFACE_MODE_RGMII_RXID)) {
+ u16 reg;
+
+ /* Errata: reads require filling in the write selector field */
+ bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ MII_BCM54XX_AUXCTL_MISC_RDSEL_MISC);
+ reg = phy_read(phydev, MII_BCM54XX_AUX_CTL);
+ /* Disable RXD to RXC delay (default set) */
+ reg &= ~MII_BCM54XX_AUXCTL_MISC_RXD_RXC_SKEW;
+ /* Clear shadow selector field */
+ reg &= ~MII_BCM54XX_AUXCTL_SHDWSEL_MASK;
+ bcm54xx_auxctl_write(phydev, MII_BCM54XX_AUXCTL_SHDWSEL_MISC,
+ MII_BCM54XX_AUXCTL_MISC_WREN | reg);
+ }
+
+ return ret;
+}
+
static int brcm_phy_setbits(struct phy_device *phydev, int reg, int set)
{
int val;
@@ -485,6 +520,18 @@ static struct phy_driver broadcom_drivers[] = {
.ack_interrupt = bcm_phy_ack_intr,
.config_intr = bcm_phy_config_intr,
}, {
+ .phy_id = PHY_ID_BCM54612E,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM54612E",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = bcm54612e_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm_phy_ack_intr,
+ .config_intr = bcm_phy_config_intr,
+}, {
.phy_id = PHY_ID_BCM54616S,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM54616S",
@@ -600,6 +647,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
{ PHY_ID_BCM5411, 0xfffffff0 },
{ PHY_ID_BCM5421, 0xfffffff0 },
{ PHY_ID_BCM5461, 0xfffffff0 },
+ { PHY_ID_BCM54612E, 0xfffffff0 },
{ PHY_ID_BCM54616S, 0xfffffff0 },
{ PHY_ID_BCM5464, 0xfffffff0 },
{ PHY_ID_BCM5481, 0xfffffff0 },
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 22c4421..60def78 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -18,6 +18,7 @@
#define PHY_ID_BCM5421 0x002060e0
#define PHY_ID_BCM5464 0x002060b0
#define PHY_ID_BCM5461 0x002060c0
+#define PHY_ID_BCM54612E 0x03625e60
#define PHY_ID_BCM54616S 0x03625d10
#define PHY_ID_BCM57780 0x03625d90
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [PATCH 0/2] Broadcom BCM54612E support
From: Xo Wang @ 2016-10-21 17:20 UTC (permalink / raw)
To: f.fainelli; +Cc: davem, jaedon.shin, netdev, linux-kernel, openbmc, joel
This series is based on tip of torvalds/master.
The first patch adds register definitions from Broadcom docs.
The second patch adds the BCM54612E PHY ID, flags, and device-specific
RGMII internal delay initialization.
I tested on a custom board with an Aspeed AST2500 SOC with its second
MAC connected to this PHY.
Xo Wang (2):
net: phy: broadcom: Update Auxiliary Control Register
net: phy: broadcom: Add support for BCM54612E
^ permalink raw reply
* [PATCH 1/2] net: phy: broadcom: Update Auxiliary Control Register macros
From: Xo Wang @ 2016-10-21 17:20 UTC (permalink / raw)
To: f.fainelli
Cc: davem, jaedon.shin, netdev, linux-kernel, openbmc, joel, Xo Wang
In-Reply-To: <1477070413-92621-1-git-send-email-xow@google.com>
Add the RXD-to-RXC skew (delay) time bit in the Miscellaneous Control
shadow register and a mask for the shadow selector field.
Remove a re-definition of MII_BCM54XX_AUXCTL_SHDWSEL_AUXCTL.
Signed-off-by: Xo Wang <xow@google.com>
---
include/linux/brcmphy.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index e3354b7..22c4421 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -105,11 +105,12 @@
#define MII_BCM54XX_AUXCTL_ACTL_SMDSP_ENA 0x0800
#define MII_BCM54XX_AUXCTL_MISC_WREN 0x8000
+#define MII_BCM54XX_AUXCTL_MISC_RXD_RXC_SKEW 0x0100
#define MII_BCM54XX_AUXCTL_MISC_FORCE_AMDIX 0x0200
#define MII_BCM54XX_AUXCTL_MISC_RDSEL_MISC 0x7000
#define MII_BCM54XX_AUXCTL_SHDWSEL_MISC 0x0007
-#define MII_BCM54XX_AUXCTL_SHDWSEL_AUXCTL 0x0000
+#define MII_BCM54XX_AUXCTL_SHDWSEL_MASK 0x0007
/*
* Broadcom LED source encodings. These are used in BCM5461, BCM5481,
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* Re: network packet kernel rate limit
From: Cong Wang @ 2016-10-21 17:41 UTC (permalink / raw)
To: YUAN Linyu; +Cc: netdev@vger.kernel.org
In-Reply-To: <8729016553E3654398EA69218DA29EEF5CB42C@cnshjmbx02>
On Thu, Oct 20, 2016 at 11:17 PM, YUAN Linyu
<Linyu.Yuan@alcatel-sbell.com.cn> wrote:
> User space application require linux kernel to do rate limit to some type of Ethernet packet(ARP, ICMP, TCP, for example 1000 packet/s) when system run under Ethernet packet flooding test.
> Do you know if kernel already exist a feature to implement this requirement?
There are multiple Qdisc's for rate limiting, e.g.:
http://lartc.org/manpages/tc-htb.html
^ permalink raw reply
* Re: [PATCH net] net: remove MTU limits on a few ether_setup callers
From: David Miller @ 2016-10-21 17:58 UTC (permalink / raw)
To: jarod; +Cc: linux-kernel, netdev, asbjorn, parameswaran.r7
In-Reply-To: <20161021032527.12954-1-jarod@redhat.com>
From: Jarod Wilson <jarod@redhat.com>
Date: Thu, 20 Oct 2016 23:25:27 -0400
> These few drivers call ether_setup(), but have no ndo_change_mtu, and thus
> were overlooked for changes to MTU range checking behavior. They
> previously had no range checks, so for feature-parity, set their min_mtu
> to 0 and max_mtu to ETH_MAX_MTU (65535), instead of the 68 and 1500
> inherited from the ether_setup() changes. Fine-tuning can come after we get
> back to full feature-parity here.
>
> CC: netdev@vger.kernel.org
> Reported-by: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
> CC: Asbjoern Sloth Toennesen <asbjorn@asbjorn.st>
> CC: R Parameswaran <parameswaran.r7@gmail.com>
> Signed-off-by: Jarod Wilson <jarod@redhat.com>
Applied.
Please use "[PATCH net-next]" in your subject line when a patch
targets net-next.
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Cong Wang @ 2016-10-21 18:02 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Smalley, Linux Kernel Network Developers, Elad Raz,
Richard Guy Briggs
In-Reply-To: <CAHC9VhQWWDHnQGv+feXZ_CDrkftuRkKLtKvXkpN0pqh6e6hMPQ@mail.gmail.com>
On Fri, Oct 21, 2016 at 9:19 AM, Paul Moore <paul@paul-moore.com> wrote:
> On Thu, Oct 20, 2016 at 7:35 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> This is what I did in the follow up patch. I attach the updated version
>> in this email for you to review ...
>
> I think there is still some confusion. The second patch you posted
> still has two queues with potentially duplicated (minus the length
> tweaks) skbs.
The current code without my patch is already this, the only difference
is there is no queue for multicast case, duplication is already there.
So, why do you expect me to fix two problems in one patch? This
is totally unfair, it is probably based on your eager to revert...
>
> What I am talking about is queuing the skb in audit_log_end(), without
> any modification, waking up the kauditd_thread, and then letting the
> kauditd_thread() function do both the netlink multicast and unicast
> sends, complete with the skb_copy() and length tweaks. This way we
> only queue one copy of the skb. To help make this more clear, I'll
> work up a patch and CC you.
Sure, I hate the skb_copy() too since it could be in a IRQ handler,
I didn't remove it because that would make the patch more complicated
than the current one. We can always improve this later for the next merge
window, can't we? Why are you pushing something irrelevant to my
patch to make it unnecessarily complicated?
> However, let me say this one more time: this is *NOT* a change I want
> to make during the -rcX cycle, this is a change that we should do for
> -next and submit during the next merge window after is has been tested
> and soaked in linux-next. Given where we are at right now - it's
> Friday and I expect -rc2 on Sunday - I think the best course of action
> is to revert the original patch and move on. I'm going to do that now
> and I'll submit it to netdev as soon as I've done some basic sanity
> checks.
The problem with this is: I would have to revert this revert for the next
merge window, in the end you would have the following in git log:
1) original one
2) revert
3) audit fix
4) revert the above revert
comparing with:
1) original one
2) audit fix
You just want to make things unnecessarily complicated.
You need to really CALM DOWN, -rc2 is NOT late, assuming -rc7 is the final
release candidate, we still have 5 weeks to fix it, why are you so scared?
We have dealt much more complicated patch/backport for networking
for -stable. Please don't panic.
^ permalink raw reply
* Pure polling mode for netdevices
From: Zach Brown @ 2016-10-21 18:03 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel
Is there a way to get NAPI to poll all the time?
Or just any way to get netdevices to use only polling and no interrupts?
We have some rt targets where the jitter can be improved by disabling
interrupts and using just polling. In these cases we're okay with the
performance downsides that come with polling.
In particular we already have an implementation for the cadence macb driver
that does only polling mode and have verified that it improves the
jitter.
We're hoping for a more general existing solution or at the very least a
solution that would be accepted upstream. Any thoughts?
^ permalink raw reply
* Re: [PATCH] kexec: Export kexec_in_progress to modules
From: Eric W. Biederman @ 2016-10-21 18:37 UTC (permalink / raw)
To: David Miller; +Cc: f.fainelli, netdev, kexec, linux-kernel, sfr
In-Reply-To: <20161021.101343.1389577512803674816.davem@davemloft.net>
David Miller <davem@davemloft.net> writes:
> From: ebiederm@xmission.com (Eric W. Biederman)
> Date: Fri, 21 Oct 2016 00:26:55 -0500
>
>> So as far as I can tell you are advocating for a change to support a
>> driver doing something that is completely pointless. So no let's not
>> export this symbol. Please fix the driver to do something less
>> pointless instead.
>
> FLorian explained his reasoning for doing what he is doing in this
> specific driver and it made sense to me.
What doesn't make sense to me is not doing that for any other kind of
reboot.
Of the 3 uses of kexec_in_progres in the kernel (not counting this one)
I think there is only one of them that is really valid. And that one
is only valid because it is the least horrible thing the pci layer can
do. (AKA it is a hack even there).
It really is nonsense having methods do different things depending on
context and that is why kexec_in_progress is not exeported.
As far as I can tell the use of kexec_in_progress winds up being
a fragile hack that will just cause more problems later on.
Florian is there a good readon why you don't just do?
static void bcm_sf2_sw_shutdown(struct platform_device *pdev)
{
struct bcm_sf2_priv *priv = platform_get_drvdata(pdev);
/* For a kernel about to be kexec'd we want to keep the GPHY on for a
* successful MDIO bus scan to occur. If we did turn off the GPHY
* before (e.g: port_disable), this will also power it back on.
*/
if (priv->hw_params.num_gphy == 1)
bcm_sf2_gphy_enable_set(priv->dev->ds, true);
}
I certainly don't see anything in the changelog to explain why that
isn't done.
Eric
^ permalink raw reply
* Re: Pure polling mode for netdevices
From: Eric Dumazet @ 2016-10-21 18:41 UTC (permalink / raw)
To: Zach Brown; +Cc: netdev, linux-kernel
In-Reply-To: <20161021180316.GA305@zach-desktop>
On Fri, 2016-10-21 at 13:03 -0500, Zach Brown wrote:
> Is there a way to get NAPI to poll all the time?
> Or just any way to get netdevices to use only polling and no interrupts?
>
> We have some rt targets where the jitter can be improved by disabling
> interrupts and using just polling. In these cases we're okay with the
> performance downsides that come with polling.
>
> In particular we already have an implementation for the cadence macb driver
> that does only polling mode and have verified that it improves the
> jitter.
>
> We're hoping for a more general existing solution or at the very least a
> solution that would be accepted upstream. Any thoughts?
This is not yet done, although you could use busy poll infrastructure to
get this without a kernel change.
Open as many TCP flows are necessary to traverse all the queues you care
about, then loop on recvmsg() to trigger NAPI polling.
^ permalink raw reply
* Re: [PATCH] kexec: Export kexec_in_progress to modules
From: Florian Fainelli @ 2016-10-21 18:48 UTC (permalink / raw)
To: Eric W. Biederman, David Miller; +Cc: netdev, kexec, linux-kernel, sfr
In-Reply-To: <87wph1eeft.fsf@xmission.com>
On 10/21/2016 11:37 AM, Eric W. Biederman wrote:
> David Miller <davem@davemloft.net> writes:
>
>> From: ebiederm@xmission.com (Eric W. Biederman)
>> Date: Fri, 21 Oct 2016 00:26:55 -0500
>>
>>> So as far as I can tell you are advocating for a change to support a
>>> driver doing something that is completely pointless. So no let's not
>>> export this symbol. Please fix the driver to do something less
>>> pointless instead.
>>
>> FLorian explained his reasoning for doing what he is doing in this
>> specific driver and it made sense to me.
>
> What doesn't make sense to me is not doing that for any other kind of
> reboot.
>
> Of the 3 uses of kexec_in_progres in the kernel (not counting this one)
> I think there is only one of them that is really valid. And that one
> is only valid because it is the least horrible thing the pci layer can
> do. (AKA it is a hack even there).
>
> It really is nonsense having methods do different things depending on
> context and that is why kexec_in_progress is not exeported.
>
> As far as I can tell the use of kexec_in_progress winds up being
> a fragile hack that will just cause more problems later on.
>
> Florian is there a good readon why you don't just do?
Checking kexec_in_progress allowed not to turn the PHY on for a normal
reboot case, since we don't necessarily know when it will be
re-initialized next, so in that sense it's a power optimization that is
nice to have.
>
> static void bcm_sf2_sw_shutdown(struct platform_device *pdev)
> {
> struct bcm_sf2_priv *priv = platform_get_drvdata(pdev);
>
> /* For a kernel about to be kexec'd we want to keep the GPHY on for a
> * successful MDIO bus scan to occur. If we did turn off the GPHY
> * before (e.g: port_disable), this will also power it back on.
> */
> if (priv->hw_params.num_gphy == 1)
> bcm_sf2_gphy_enable_set(priv->dev->ds, true);
> }
>
> I certainly don't see anything in the changelog to explain why that
> isn't done.
That would result in an identical behavior for what I am after, David,
shall I send a revert plus this?
--
Florian
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Richard Guy Briggs @ 2016-10-21 19:39 UTC (permalink / raw)
To: Cong Wang
Cc: Paul Moore, Stephen Smalley, Linux Kernel Network Developers,
Elad Raz
In-Reply-To: <CAM_iQpV0vfwsToR=maxhGM+fvQLX9zqcpp14A-C9JNzLfKJy9g@mail.gmail.com>
On 2016-10-21 11:02, Cong Wang wrote:
> On Fri, Oct 21, 2016 at 9:19 AM, Paul Moore <paul@paul-moore.com> wrote:
> > On Thu, Oct 20, 2016 at 7:35 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> >> This is what I did in the follow up patch. I attach the updated version
> >> in this email for you to review ...
> >
> > I think there is still some confusion. The second patch you posted
> > still has two queues with potentially duplicated (minus the length
> > tweaks) skbs.
>
> The current code without my patch is already this, the only difference
> is there is no queue for multicast case, duplication is already there.
> So, why do you expect me to fix two problems in one patch? This
> is totally unfair, it is probably based on your eager to revert...
>
> >
> > What I am talking about is queuing the skb in audit_log_end(), without
> > any modification, waking up the kauditd_thread, and then letting the
> > kauditd_thread() function do both the netlink multicast and unicast
> > sends, complete with the skb_copy() and length tweaks. This way we
> > only queue one copy of the skb. To help make this more clear, I'll
> > work up a patch and CC you.
>
> Sure, I hate the skb_copy() too since it could be in a IRQ handler,
> I didn't remove it because that would make the patch more complicated
> than the current one. We can always improve this later for the next merge
> window, can't we? Why are you pushing something irrelevant to my
> patch to make it unnecessarily complicated?
>
>
> > However, let me say this one more time: this is *NOT* a change I want
> > to make during the -rcX cycle, this is a change that we should do for
> > -next and submit during the next merge window after is has been tested
> > and soaked in linux-next. Given where we are at right now - it's
> > Friday and I expect -rc2 on Sunday - I think the best course of action
> > is to revert the original patch and move on. I'm going to do that now
> > and I'll submit it to netdev as soon as I've done some basic sanity
> > checks.
>
> The problem with this is: I would have to revert this revert for the next
> merge window, in the end you would have the following in git log:
>
> 1) original one
> 2) revert
> 3) audit fix
> 4) revert the above revert
>
> comparing with:
>
> 1) original one
> 2) audit fix
>
> You just want to make things unnecessarily complicated.
I agree here. I've been following this, thinking about it, but don't
yet have a solid recommendation about the way to proceed yet, but
reverting it does not seem like the right solution.
> You need to really CALM DOWN, -rc2 is NOT late, assuming -rc7 is the final
> release candidate, we still have 5 weeks to fix it, why are you so scared?
A revert seems pretty impulsive to me now.
> We have dealt much more complicated patch/backport for networking
> for -stable. Please don't panic.
- RGB
^ permalink raw reply
* [PATCH iproute2 net-next] tc: m_mirred: Fix parsing of 'index' optional argument
From: Shmulik Ladkani @ 2016-10-21 20:01 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jamal Hadi Salim, netdev, Shmulik Ladkani
Code in parse_mirred() suggests "index" argument can be placed either
after the "egress" clause, or as the first argument (after "action mirred").
However, parse_egress() fails to correctly parse "index" if it's the
first argument.
For example:
# tc filter add ... action mirred index 5
RTNETLINK answers: Invalid argument
(unnecessary RTNETLINK issued, should have been parse error)
# tc filter add ... action mirred index 5 egress redirect dev eth0
bad action type egress
(should have been parsed successfully)
Fix parse_egress as follows:
- continue parsing after valid "index" is seen
- don't issue the RTNETLINK unless valid "egress" is seen
Signed-off-by: Shmulik Ladkani <shmulik.ladkani@gmail.com>
---
Well, both man and usage suggest "index" comes after the egress clause:
tc ... action mirred DIRECTION ACTION [ index INDEX ] dev DEVICENAME
So an alternative would be banning "index" as 1st argument in parse_mirred.
tc/m_mirred.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/tc/m_mirred.c b/tc/m_mirred.c
index 11f4c9b46f..d3e750b89b 100644
--- a/tc/m_mirred.c
+++ b/tc/m_mirred.c
@@ -91,9 +91,8 @@ parse_egress(struct action_util *a, int *argc_p, char ***argv_p,
}
iok++;
if (!ok) {
- argc--;
- argv++;
- break;
+ NEXT_ARG();
+ continue;
}
} else if (!ok) {
fprintf(stderr, "was expecting egress (%s)\n", *argv);
@@ -134,7 +133,7 @@ parse_egress(struct action_util *a, int *argc_p, char ***argv_p,
NEXT_ARG();
}
- if (!ok && !iok) {
+ if (!ok) {
return -1;
}
--
2.7.4
^ permalink raw reply related
* Re: [Patch net] net: saving irq context for peernet2id()
From: Paul Moore @ 2016-10-21 20:03 UTC (permalink / raw)
To: Cong Wang
Cc: Stephen Smalley, Linux Kernel Network Developers, Elad Raz,
Richard Guy Briggs
In-Reply-To: <CAM_iQpV0vfwsToR=maxhGM+fvQLX9zqcpp14A-C9JNzLfKJy9g@mail.gmail.com>
On Fri, Oct 21, 2016 at 2:02 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Fri, Oct 21, 2016 at 9:19 AM, Paul Moore <paul@paul-moore.com> wrote:
>> On Thu, Oct 20, 2016 at 7:35 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>>> This is what I did in the follow up patch. I attach the updated version
>>> in this email for you to review ...
>>
>> I think there is still some confusion. The second patch you posted
>> still has two queues with potentially duplicated (minus the length
>> tweaks) skbs.
>
> The current code without my patch is already this, the only difference
> is there is no queue for multicast case, duplication is already there.
The difference is the period of time where the skbs are duplicated.
You patch duplicates the skb and then queues them, I'm suggesting
putting a single skb in the queue and then only duplicating it once it
has been pulled off the queue.
> So, why do you expect me to fix two problems in one patch? This
> is totally unfair, it is probably based on your eager to revert...
All I've been asking for this week is a fix before -rc2 is released; I
think I've been pretty clear and consistent about that. At the start
of the week I didn't care if it was a revert or some other fix, so
long as the fix was relatively small and easily verified/tested. I
did say that if we got to the end of the week and we didn't have a
solution in place I would advocate for a revert. It's Friday
afternoon as I type this.
I've also been pretty clear from the very beginning that I don't
consider a rework of the audit multicast code to be a candidate for
4.9-rcX, that is -next material as far as I'm concerned. I'll readily
admit that perhaps I'm more conservative than most maintainers, but I
take that approach to try to keep from breaking other subsystems (and
avoid situations like these, because this thread is so much fun after
all).
>> What I am talking about is queuing the skb in audit_log_end(), without
>> any modification, waking up the kauditd_thread, and then letting the
>> kauditd_thread() function do both the netlink multicast and unicast
>> sends, complete with the skb_copy() and length tweaks. This way we
>> only queue one copy of the skb. To help make this more clear, I'll
>> work up a patch and CC you.
>
> Sure, I hate the skb_copy() too since it could be in a IRQ handler,
> I didn't remove it because that would make the patch more complicated
> than the current one. We can always improve this later for the next merge
> window, can't we? Why are you pushing something irrelevant to my
> patch to make it unnecessarily complicated?
I don't even know where to begin ... please just re-read what I've
said above as well as previously this week. I just want a simple fix
for 4.9-rc. I'm not going to sign-off/ack a rework of the audit
multicast code for 4.9-rc.
>> However, let me say this one more time: this is *NOT* a change I want
>> to make during the -rcX cycle, this is a change that we should do for
>> -next and submit during the next merge window after is has been tested
>> and soaked in linux-next. Given where we are at right now - it's
>> Friday and I expect -rc2 on Sunday - I think the best course of action
>> is to revert the original patch and move on. I'm going to do that now
>> and I'll submit it to netdev as soon as I've done some basic sanity
>> checks.
>
> The problem with this is: I would have to revert this revert for the next
> merge window, in the end you would have the following in git log:
>
> 1) original one
> 2) revert
> 3) audit fix
> 4) revert the above revert
>
> comparing with:
>
> 1) original one
> 2) audit fix
>
> You just want to make things unnecessarily complicated.
No. What I want, (one more time) is a fix in -rc2.
> You need to really CALM DOWN, -rc2 is NOT late, assuming -rc7 is the final
> release candidate, we still have 5 weeks to fix it, why are you so scared?
We don't know each other, in fact before this week I'm not sure we've
even emailed each other (my apologies if we have), so I'm just
ignoring statements like the above, but just some advice (feel free to
ignore): I don't think anyone ever responds well to demands to "CALM
DOWN", especially when I feel my side of the conversation has been
quite civil.
> We have dealt much more complicated patch/backport for networking
> for -stable. Please don't panic.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Paul Moore @ 2016-10-21 20:15 UTC (permalink / raw)
To: Richard Guy Briggs
Cc: Cong Wang, Stephen Smalley, Linux Kernel Network Developers,
Elad Raz
In-Reply-To: <20161021193951.GS23701@madcap2.tricolour.ca>
On Fri, Oct 21, 2016 at 3:39 PM, Richard Guy Briggs <rgb@redhat.com> wrote:
> On 2016-10-21 11:02, Cong Wang wrote:
>> On Fri, Oct 21, 2016 at 9:19 AM, Paul Moore <paul@paul-moore.com> wrote:
>> > On Thu, Oct 20, 2016 at 7:35 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> >> This is what I did in the follow up patch. I attach the updated version
>> >> in this email for you to review ...
>> >
>> > I think there is still some confusion. The second patch you posted
>> > still has two queues with potentially duplicated (minus the length
>> > tweaks) skbs.
>>
>> The current code without my patch is already this, the only difference
>> is there is no queue for multicast case, duplication is already there.
>> So, why do you expect me to fix two problems in one patch? This
>> is totally unfair, it is probably based on your eager to revert...
>>
>> >
>> > What I am talking about is queuing the skb in audit_log_end(), without
>> > any modification, waking up the kauditd_thread, and then letting the
>> > kauditd_thread() function do both the netlink multicast and unicast
>> > sends, complete with the skb_copy() and length tweaks. This way we
>> > only queue one copy of the skb. To help make this more clear, I'll
>> > work up a patch and CC you.
>>
>> Sure, I hate the skb_copy() too since it could be in a IRQ handler,
>> I didn't remove it because that would make the patch more complicated
>> than the current one. We can always improve this later for the next merge
>> window, can't we? Why are you pushing something irrelevant to my
>> patch to make it unnecessarily complicated?
>>
>>
>> > However, let me say this one more time: this is *NOT* a change I want
>> > to make during the -rcX cycle, this is a change that we should do for
>> > -next and submit during the next merge window after is has been tested
>> > and soaked in linux-next. Given where we are at right now - it's
>> > Friday and I expect -rc2 on Sunday - I think the best course of action
>> > is to revert the original patch and move on. I'm going to do that now
>> > and I'll submit it to netdev as soon as I've done some basic sanity
>> > checks.
>>
>> The problem with this is: I would have to revert this revert for the next
>> merge window, in the end you would have the following in git log:
>>
>> 1) original one
>> 2) revert
>> 3) audit fix
>> 4) revert the above revert
>>
>> comparing with:
>>
>> 1) original one
>> 2) audit fix
>>
>> You just want to make things unnecessarily complicated.
>
> I agree here. I've been following this, thinking about it, but don't
> yet have a solid recommendation about the way to proceed yet, but
> reverting it does not seem like the right solution.
>
>> You need to really CALM DOWN, -rc2 is NOT late, assuming -rc7 is the final
>> release candidate, we still have 5 weeks to fix it, why are you so scared?
>
> A revert seems pretty impulsive to me now.
I agree that if this issue had been identified today, it would be
impulsive to do a revert for -rc2; Stephen reported this problem
Wednesday morning. I would also be okay waiting on a fix past -rc2 if
the solution was still under development and we all agreed on the
solution.
However, that's not the case is it? Unless I missed something, the
fix that Cong Wang is advocating (rework the audit multicast code), is
a change that I have said I'm not going to accept during the -rc
phase. It has been a few days now and no alternate fix has been
proposed, I'll give it a few more hours ...
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: David Miller @ 2016-10-21 20:33 UTC (permalink / raw)
To: paul; +Cc: rgb, xiyou.wangcong, sds, netdev, e
In-Reply-To: <CAHC9VhSm21f-HurdGi7+D0LmHNkkKRyAsT-OHJEyOZgoJVYUNg@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Fri, 21 Oct 2016 16:15:00 -0400
> However, that's not the case is it? Unless I missed something, the
> fix that Cong Wang is advocating (rework the audit multicast code), is
> a change that I have said I'm not going to accept during the -rc
> phase. It has been a few days now and no alternate fix has been
> proposed, I'll give it a few more hours ...
It really is the right way to fix this though.
Nothing should be emitting netlink messages, potentially en-masse
to a multicast group or broadcast, in hardware interrupt context.
I know it's been said that only systemd receives these things, so
that point doesn't need to be remade again.
We have many weeks until -final is released so I really don't
understand the reluctance at a slightly more involved fix in -rc2. In
fact this is the most optimal time to try it this way, as we'll have
the maximum amount of time for it to have exposure for testing before
-final.
Thanks.
^ permalink raw reply
* Re: [Patch net] net: saving irq context for peernet2id()
From: Paul Moore @ 2016-10-21 20:53 UTC (permalink / raw)
To: David Miller; +Cc: rgb, xiyou.wangcong, Stephen Smalley, netdev, e
In-Reply-To: <20161021.163342.2187677530255875866.davem@davemloft.net>
On Fri, Oct 21, 2016 at 4:33 PM, David Miller <davem@davemloft.net> wrote:
> From: Paul Moore <paul@paul-moore.com>
> Date: Fri, 21 Oct 2016 16:15:00 -0400
>
>> However, that's not the case is it? Unless I missed something, the
>> fix that Cong Wang is advocating (rework the audit multicast code), is
>> a change that I have said I'm not going to accept during the -rc
>> phase. It has been a few days now and no alternate fix has been
>> proposed, I'll give it a few more hours ...
>
> It really is the right way to fix this though.
>
> Nothing should be emitting netlink messages, potentially en-masse
> to a multicast group or broadcast, in hardware interrupt context.
>
> I know it's been said that only systemd receives these things, so
> that point doesn't need to be remade again.
I think it is also worth noting that this code has been doing it this
way for some time now. I say this not to advocate that it is correct,
only that there hasn't been a demonstrated problem until Cong Wang's
patch.
> We have many weeks until -final is released so I really don't
> understand the reluctance at a slightly more involved fix in -rc2. In
> fact this is the most optimal time to try it this way, as we'll have
> the maximum amount of time for it to have exposure for testing before
> -final.
Well, I understand what you are trying to say, but the maximum amount
of time for exposure/testing would be to put it in -next. The audit
netlink code needs a rework, but introducing such a change in the -rc
kernels is not something I'm going to do, especially when the change
which triggered the regression is an optimization that can be easily
reverted ... or fixed, but the only two options I've heard mentioned
are the audit multicast rework and the revert; if someone has a third
option I'm listening ...
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: [RFC PATCH 09/13] net: phy: Add Meson GXL Internal PHY driver
From: Florian Fainelli @ 2016-10-21 20:56 UTC (permalink / raw)
To: Neil Armstrong, khilman-rdvid1DuHRBWk0Htik3J/w,
carlo-KA+7E9HrN00dnm+yROfE0A,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1477060838-14164-10-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
On 10/21/2016 07:40 AM, Neil Armstrong wrote:
> Add driver for the Internal RMII PHY found in the Amlogic Meson GXL SoCs.
>
> This PHY seems to only implement some standard registers and need some
> workarounds to provide autoneg values from vendor registers.
>
> Some magic values are currently used to configure the PHY, and this a
> temporary setup until clarification about these registers names and
> registers fields are provided by Amlogic.
>
> Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
> ---
> +
> +static int meson_gxl_config_init(struct phy_device *phydev)
> +{
> + int val;
> + u32 features;
> +
> + meson_gxl_phy_config(phydev);
> +
> + features = SUPPORTED_MII;
This does not really belong in the PHY driver, and this is statically
assigned, I would just drop this.
> +
> + /* Do we support autonegotiation? */
> + val = phy_read(phydev, MII_BMSR);
> + if (val < 0)
> + return val;
> +
> + if (val & BMSR_ANEGCAPABLE)
> + features |= SUPPORTED_Autoneg;
> + if (val & BMSR_100FULL)
> + features |= SUPPORTED_100baseT_Full;
> + if (val & BMSR_100HALF)
> + features |= SUPPORTED_100baseT_Half;
> + if (val & BMSR_10FULL)
> + features |= SUPPORTED_10baseT_Full;
> + if (val & BMSR_10HALF)
> + features |= SUPPORTED_10baseT_Half;
> +
> + phydev->supported = features;
> + phydev->advertising = features;
This is redundant with what PHYLIB will determine for the PHY.
> +
> + return 0;
> +}
> +
> +static int meson_gxl_phy_read_status(struct phy_device *phydev)
> +{
> + int err;
> +
> + /* Update the link, but return if there was an error */
> + err = genphy_update_link(phydev);
> + if (err)
> + return err;
> +
> + phydev->lp_advertising = 0;
> + phydev->pause = 0;
> + phydev->asym_pause = 0;
> +
> + if (phydev->autoneg == AUTONEG_ENABLE) {
> + unsigned int speed;
> + int reg = phy_read(phydev, GXL_REG_ANEG);
Is all of this really necessary? This should all be reflected in the
standard BMSR register, is not this the case here that we have to read
this non-standard register?
You use genphy_config_aneg(), so surely, the standard auto-negotiation
part works somehow?
> +
> + if (reg < 0)
> + return reg;
> +
> + speed = reg & REG_ANEG_SPEED_MASK;
> +
> + if (reg & REG_ANEG_FDUPLEX)
> + phydev->duplex = DUPLEX_FULL;
> + else
> + phydev->duplex = DUPLEX_HALF;
> +
> + if ((reg & REG_ANEG_SPEED_MASK) == REG_ANEG_SPEED10)
> + phydev->speed = SPEED_10;
> + else if ((reg & REG_ANEG_SPEED_MASK) == REG_ANEG_SPEED100)
> + phydev->speed = SPEED_100;
> + } else {
> + int bmcr = phy_read(phydev, MII_BMCR);
> +
> + if (bmcr < 0)
> + return bmcr;
> +
> + if (bmcr & BMCR_FULLDPLX)
> + phydev->duplex = DUPLEX_FULL;
> + else
> + phydev->duplex = DUPLEX_HALF;
> +
> + if (bmcr & BMCR_SPEED1000)
> + phydev->speed = SPEED_1000;
> + else if (bmcr & BMCR_SPEED100)
> + phydev->speed = SPEED_100;
> + else
> + phydev->speed = SPEED_10;
> + }
> +
> + return 0;
> +}
> +
> +static struct phy_driver meson_gxl_phy = {
> + .phy_id = 0x01814400,
> + .name = "Meson GXL Internal PHY",
> + .phy_id_mask = 0x0fffffff,
Usually the last 4 bits are 0, since that's where the revision part is
located.
> + .features = 0,
You should set PHY_GBIT_FEATURES and set .flags to PHY_IS_INTERNAL since
this is an internal PHY?
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] flow_dissector: avoid uninitialized variable access
From: Arnd Bergmann @ 2016-10-21 21:05 UTC (permalink / raw)
To: Jiri Pirko
Cc: David S. Miller, Alexander Duyck, Tom Herbert, Jiri Pirko,
Hadar Hen Zion, Gao Feng, Eric Garver, Amir Vadai, netdev,
linux-kernel
In-Reply-To: <20161021163118.GA2155@nanopsycho.orion>
On Friday, October 21, 2016 6:31:18 PM CEST Jiri Pirko wrote:
> Fri, Oct 21, 2016 at 05:55:53PM CEST, arnd@arndb.de wrote:
> >gcc warns about an uninitialized pointer dereference in the vlan
> >priority handling:
> >
> >net/core/flow_dissector.c: In function '__skb_flow_dissect':
> >net/core/flow_dissector.c:281:61: error: 'vlan' may be used uninitialized in this function [-Werror=maybe-uninitialized]
> >
> >From all I can tell, this warning is about a real bug, and we
> >should not attempt look up the vlan header if there was
> >no vlan tag.
>
> I don't see how vlan could be used uninitialized. But I understand that
> this is impossible for gcc to track it. Please just use uninitialized_var()
>
I usually try to avoid uninitialized_var(), as making it obvious to
the compiler why something is known tends to result in more readable
source code and better object code.
Can you explain why "dissector_uses_key(flow_dissector,
FLOW_DISSECTOR_KEY_VLAN) && skb_vlan_tag_present(skb)" implies
"eth_type_vlan(proto))"?
If I add uninitialized_var() here, I would at least put that in
a comment here.
On a related note, I also don't see how
"dissector_uses_key(flow_dissector, FLOW_DISSECTOR_KEY_VLAN)"
implies that skb is non-NULL. I guess this is related to the
first one.
Arnd
^ permalink raw reply
* Re: [PATCH net-next v6 1/3] net/socket: factor out helpers for memory and queue manipulation
From: Eric Dumazet @ 2016-10-21 21:13 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller, James Morris,
Trond Myklebust, Alexander Duyck, Daniel Borkmann, Eric Dumazet,
Tom Herbert, Hannes Frederic Sowa, Edward Cree,
linux-nfs-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <14784e6382342c2184929ef2959e7c11faf8ff8e.1477043395.git.pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Fri, 2016-10-21 at 13:55 +0200, Paolo Abeni wrote:
> Basic sock operations that udp code can use with its own
> memory accounting schema. No functional change is introduced
> in the existing APIs.
>
> v4 -> v5:
> - avoid whitespace changes
>
> v2 -> v4:
> - avoid exporting __sock_enqueue_skb
>
> v1 -> v2:
> - avoid export sock_rmem_free
>
> Acked-by: Hannes Frederic Sowa <hannes-tFNcAqjVMyqKXQKiL6tip0B+6BGkLq7r@public.gmane.org>
> Signed-off-by: Paolo Abeni <pabeni-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> ---
Acked-by: Eric Dumazet <edumazet-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next v6 2/3] udp: implement memory accounting helpers
From: Eric Dumazet @ 2016-10-21 21:13 UTC (permalink / raw)
To: Paolo Abeni
Cc: netdev, David S. Miller, James Morris, Trond Myklebust,
Alexander Duyck, Daniel Borkmann, Eric Dumazet, Tom Herbert,
Hannes Frederic Sowa, Edward Cree, linux-nfs
In-Reply-To: <4d2e0fc8f5c3d1309b0fb71bc65a2719a8e82825.1477043395.git.pabeni@redhat.com>
On Fri, 2016-10-21 at 13:55 +0200, Paolo Abeni wrote:
> Avoid using the generic helpers.
> Use the receive queue spin lock to protect the memory
> accounting operation, both on enqueue and on dequeue.
>
> On dequeue perform partial memory reclaiming, trying to
> leave a quantum of forward allocated memory.
>
> On enqueue use a custom helper, to allow some optimizations:
> - use a plain spin_lock() variant instead of the slightly
> costly spin_lock_irqsave(),
> - avoid dst_force check, since the calling code has already
> dropped the skb dst
> - avoid orphaning the skb, since skb_steal_sock() already did
> the work for us
>
> The above needs custom memory reclaiming on shutdown, provided
> by the udp_destruct_sock().
Acked-by: Eric Dumazet <edumazet@google.com>
^ 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