* RE: [PATCH 2/2] lan78xx: add ndo_get_stats64
From: Woojung.Huh @ 2016-03-16 16:11 UTC (permalink / raw)
To: sergei.shtylyov, davem, netdev; +Cc: UNGLinuxDriver
In-Reply-To: <56E96ABE.1010206@cogentembedded.com>
> > + storage->rx_length_errors = (stats.rx_undersize_frame_errors +
> > + stats.rx_oversize_frame_errors);
>
> Parens not needed.
>
> > + storage->rx_errors = (stats.rx_fcs_errors +
> > + stats.rx_alignment_errors +
> > + stats.rx_fragment_errors +
> > + stats.rx_jabber_errors +
> > + stats.rx_undersize_frame_errors +
> > + stats.rx_oversize_frame_errors +
> > + stats.rx_dropped_frames);
>
> Neither here.
>
> > + storage->tx_errors = (stats.tx_fcs_errors +
> > + stats.tx_excess_deferral_errors +
> > + stats.tx_carrier_errors);
>
> And here.
>
Thanks. Will resubmit.
Woojung
^ permalink raw reply
* Re: Regression: netlink fail (triggered by iw) removes extra wlan (phy) interface
From: Cong Wang @ 2016-03-16 16:00 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Network Development, Herbert Xu, Tejun Heo, Cong Wang,
David Miller, Tom Herbert, Martin KaFai Lau, kernel-team,
Linux Kernel Mailing List, Linus Torvalds, Jiri Pirko,
Nicolas Dichtel, Thomas Graf, Scott Feldman
In-Reply-To: <CACna6rzz4f-urvD7uvVKuvYMOWhW+JYWkVW8MK9mJTPw0OiWxA@mail.gmail.com>
On Thu, Feb 25, 2016 at 5:22 AM, Rafał Miłecki <zajec5@gmail.com> wrote:
> Hi,
>
> After updating kernel in OpenWrt from 4.1.6 to 4.1.10 I noticed that
> if "iw" command fails (which happens very rarely) my wlan0-1 interface
> disappears. To trigger this problem easily I'm using this trivial
> script:
> while [ 1 ]
> do
> iw phy phy0 interface add mon0 type monitor
> ifconfig mon0 up
> iw dev mon0 del
> done
>
> Whenever it goes wrong I see:
> Failed to connect to generic netlink.
> kern.info kernel: [ 1933.114338] br-lan: port 3(wlan0-1) entered disabled state
> kern.info kernel: [ 1933.335568] device wlan0-1 left promiscuous mode
> kern.info kernel: [ 1933.340385] br-lan: port 3(wlan0-1) entered disabled state
> daemon.notice netifd: Network device 'wlan0-1' link is down
> command failed: Too many open files in system (-23)
>
Note, for 4.1, the backport is known to be incorrect, and it is
fixed later by:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/net/netlink/af_netlink.c?h=linux-4.1.y&id=a52ec6de6d1638e8c203d7188c55627f75371612
> This regression is caused by commit:
> 4e27762 netlink: Fix autobind race condition that leads to zero port ID
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=4e27762417669cb459971635be550eb7b5598286
> that is a backport of upstream:
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=1f770c0a09da855a2b51af6d19de97fb955eca85
>
> This still happens with kernel 4.4.
Looks like the goto is missing in 4.4 branch too. ;) Mind to send a patch
to GregKH?
>
> My hardware is Linksys WRT160NL (Atheros AR9130 SoC) and I'm using two
> __ap interfaces on phy0 (wlan0 and wlan0-1).
>
> Could you take a look at this?
> Is there some additional info I could provide to help fixing this?
>
> --
> Rafał
^ permalink raw reply
* [PATCH] xfrm: don't segment UFO packets
From: Jiri Bohac @ 2016-03-16 16:00 UTC (permalink / raw)
To: Herbert Xu; +Cc: Steffen Klassert, David S. Miller, netdev
In-Reply-To: <20160130042102.GA22809@gondor.apana.org.au>
xfrm_output() will segment GSO packets, including UDP (UFO) packets.
this is wrong per RFC4303, section 3.3.4. Fragmentation:
If necessary, fragmentation is performed after ESP
processing within an IPsec implementation. Thus,
transport mode ESP is applied only to whole IP
datagrams (not to IP fragments).
Prevent xfrm_output() from segmenting UFO packets so that they will be
fragmented after the xfrm transforms.
Signed-off-by: Jiri Bohac <jbohac@suse.cz>
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 4355129..6f3e814 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -3501,6 +3501,12 @@ static inline bool skb_is_gso_v6(const struct sk_buff *skb)
return skb_shinfo(skb)->gso_type & SKB_GSO_TCPV6;
}
+/* Note: Should be called only if skb_is_gso(skb) is true */
+static inline bool skb_is_ufo(const struct sk_buff *skb)
+{
+ return skb_shinfo(skb)->gso_type & SKB_GSO_UDP;
+}
+
void __skb_warn_lro_forwarding(const struct sk_buff *skb);
static inline bool skb_warn_if_lro(const struct sk_buff *skb)
diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
index cc3676e..c52cc8b 100644
--- a/net/xfrm/xfrm_output.c
+++ b/net/xfrm/xfrm_output.c
@@ -197,8 +197,12 @@ int xfrm_output(struct sock *sk, struct sk_buff *skb)
struct net *net = dev_net(skb_dst(skb)->dev);
int err;
- if (skb_is_gso(skb))
- return xfrm_output_gso(net, sk, skb);
+ if (skb_is_gso(skb)) {
+ if (skb_is_ufo(skb))
+ return xfrm_output2(net, sk, skb);
+ else
+ return xfrm_output_gso(net, sk, skb);
+ }
if (skb->ip_summed == CHECKSUM_PARTIAL) {
err = skb_checksum_help(skb);
--
Jiri Bohac <jbohac@suse.cz>
SUSE Labs, SUSE CZ
^ permalink raw reply related
* Re: [PATCH] net: phy: fix PHY_RUNNING in phy_state_machine
From: Yegor Yefremov @ 2016-03-16 15:59 UTC (permalink / raw)
To: shh.xie
Cc: netdev, David Miller, Shaohui Xie, Florian Fainelli,
N, Mugunthan V, drivshin
In-Reply-To: <1439526220-31458-1-git-send-email-shh.xie@gmail.com>
On Fri, Aug 14, 2015 at 6:23 AM, <shh.xie@gmail.com> wrote:
> From: Shaohui Xie <Shaohui.Xie@freescale.com>
>
> Currently, if phy state is PHY_RUNNING, we always register a CHANGE
> when phy works in polling or interrupt ignored, this will make the
> adjust_link being called even the phy link did Not changed.
>
> checking the phy link to make sure the link did changed before we
> register a CHANGE, if link did not changed, we do nothing.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@freescale.com>
> ---
> drivers/net/phy/phy.c | 16 ++++++++++++----
> 1 file changed, 12 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 84b1fba..d972851 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
> @@ -814,6 +814,7 @@ void phy_state_machine(struct work_struct *work)
> bool needs_aneg = false, do_suspend = false;
> enum phy_state old_state;
> int err = 0;
> + int old_link;
>
> mutex_lock(&phydev->lock);
>
> @@ -899,11 +900,18 @@ void phy_state_machine(struct work_struct *work)
> phydev->adjust_link(phydev->attached_dev);
> break;
> case PHY_RUNNING:
> - /* Only register a CHANGE if we are
> - * polling or ignoring interrupts
> + /* Only register a CHANGE if we are polling or ignoring
> + * interrupts and link changed since latest checking.
> */
> - if (!phy_interrupt_is_valid(phydev))
> - phydev->state = PHY_CHANGELINK;
> + if (!phy_interrupt_is_valid(phydev)) {
> + old_link = phydev->link;
> + err = phy_read_status(phydev);
> + if (err)
> + break;
> +
> + if (old_link != phydev->link)
> + phydev->state = PHY_CHANGELINK;
> + }
> break;
> case PHY_CHANGELINK:
> err = phy_read_status(phydev);
This patch breaks my am335x based board, where one of the CPSW slaves
is connected to IP175D switch chip via RMII interface. Since this
patch packet reception is not working.
Yegor
^ permalink raw reply
* Re: [RFCv2 0/3] mac80211: implement fq codel
From: Dave Taht @ 2016-03-16 15:37 UTC (permalink / raw)
To: Michal Kazior
Cc: Felix Fietkau, Emmanuel Grumbach, Network Development,
linux-wireless, ath10k@lists.infradead.org,
codel@lists.bufferbloat.net, make-wifi-fast, Johannes Berg,
Tim Shepard
In-Reply-To: <CA+BoTQ=65mHN5iLnZjTE+tyEG7nfmCx4NZNbGRF6+VpRaNmOYw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1695 bytes --]
it is helpful to name the test files coherently in the flent tests, in
addition to using a directory structure and timestamp. It makes doing
comparison plots in data->add-other-open-data-files simpler. "-t
patched-mac-300mbps", for example.
Also netperf from svn (maybe 2.7, don't remember) will restart udp_rr
after a packet loss in 250ms. Seeing a loss on UDP_RR and it stop for
a while is "ok".
Dave Täht
Let's go make home routers and wifi faster! With better software!
https://www.gofundme.com/savewifi
On Wed, Mar 16, 2016 at 3:26 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
> On 16 March 2016 at 11:17, Michal Kazior <michal.kazior@tieto.com> wrote:
>> Hi,
>>
>> Most notable changes:
> [...]
>> * ath10k proof-of-concept that uses the new tx
>> scheduling (will post results in separate
>> email)
>
> I'm attaching a bunch of tests I've done using flent. They are all
> "burst" tests with burst-ports=1 and burst-length=2. The testing
> topology is:
>
> AP ----> STA
> AP )) (( STA
> [veth]--[br]--[wlan] )) (( [wlan]
>
> You can notice that in some tests plot data gets cut-off. There are 2
> problems I've identified:
> - excess drops (not a problem with the patchset and can be seen when
> there's no codel-in-mac or scheduling isn't used)
> - UDP_RR hangs (apparently QCA99X0 I have hangs for a few hundred ms
> sometimes at times and doesn't Rx frames causing UDP_RR to stop
> mid-way; confirmed with logs and sniffer; I haven't figured out *why*
> exactly, could be some hw/fw quirk)
>
> Let me know if you have questions or comments regarding my testing/results.
>
>
> Michał
[-- Attachment #2: cdf_comparison.png --]
[-- Type: image/png, Size: 87203 bytes --]
[-- Attachment #3: Type: text/plain, Size: 140 bytes --]
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/codel
^ permalink raw reply
* ipv6 not bringing up due to qdisc_tx_is_noop failing
From: Nikolay Borisov @ 2016-03-16 15:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, SiteGround Operations
Hello Dave,
I've been chasing a rather strange problem and I saw you were the person
that authored most of the code involved so I'm addresing you, but will
be happy to receive assistance from any one feeling knowledgeable enough
on the issue.
Basically I have an infiniband card on which I want to run ipv6 to this
effect I load modules ib_qib (the infiniband card is qlogic QLE7342) and
then I load module ib_ipoib and I get :
IPv6: ADDRCONF(NETDEV_UP): ib0: link is not ready
even though for example ibping and all that works. This happens because
the check if (!addrconf_qdisc_ok(dev)) in addrconf_notify fails, since
the dev's txq ->qdisc points to noop_qdisc.
Now, here is what happens :
1. When the ib_ipoib module is loaded
register_netdevice->dev_init_scheduler is called which sets the device's
qdisc to noop_qdisc
2. Then via a netlink message the device is being activate, which calls
into dev_activate->attach_one_default_qdisc which attaches the newly
created default qdisc to the dev->sleeping_qdisc member
3. The addrconf_notify is invoked which fails the check since the
netdev_queue's qdisk member was never updated (just the sleeping_qdisc)
to anything different than the initial state (which is noop_qdisc).
I have stack traces which do show this sequence of events, so my
questions now are:
1. What's the difference between netdev_queue->qdisc and
netdev_queue->qdisc_sleeping. Git blaming indicates those member haves
existed even before the git history was started.
2. Shouldn't the netdev_queue->qdisc also be updated during
attach_one_default_qdisc?
Regards,
Nikolay
^ permalink raw reply
* Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
From: Murali Karicheri @ 2016-03-16 15:16 UTC (permalink / raw)
To: Florian Fainelli, johan, open list:TI NETCP ETHERNET DRIVER,
Kwok, WingMan, Andrew Lunn, opendmb
In-Reply-To: <56E976DE.9040000@ti.com>
On 03/16/2016 11:08 AM, Murali Karicheri wrote:
> On 03/11/2016 02:51 PM, Florian Fainelli wrote:
>> On 11/03/16 10:31, Murali Karicheri wrote:
>>> On 03/10/2016 02:38 PM, Murali Karicheri wrote:
>>>> On 03/10/2016 01:05 PM, Florian Fainelli wrote:
>>>>> On 10/03/16 08:48, Murali Karicheri wrote:
>>>>>> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
>>>>>>> On 03/03/16 14:18, Murali Karicheri wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> We are using Micrel Phy in one of our board and wondering if we can force the
>>>>>>>> Phy to disable flow control at start. I have a 1G ethernet switch connected
>>>>>>>> to Phy and the phy always enable flow control. I would like to configure the
>>>>>>>> phy not to flow control. Is that possible and if yes, what should I do in the
>>>>>>>> my Ethernet driver to tell the Phy not to enable flow control?
>>>>>>>
>>>>>>> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
>>>>>>> the switch is doing, along with the link partner advertising support for
>>>>>>> it. You would want to make sure that your PHY device interface (provided
>>>>>>> that you are using the PHY library) is not starting with Pause
>>>>>>> advertised, but it could be supported.
>>>>>>
>>>>>> Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise
>>>>>> by default FC supported. After negotiation, I see that Phylib provide the
>>>>>> link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy not
>>>>>> to advertise?
>>>>>>
>>>>>> I call following sequence in the Ethernet driver.
>>>>>>
>>>>>> of_phy_connect(x,y,hndlr,a,z);
>>>>>
>>>>> Here you should be able to change phydev->advertising and
>>>>> phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
>>>>> bits and have phy_start() restart with that which should disable pause
>>>>> and asym_pause as seen by your adjust_link handler.
>>>>>
>>>> Ok. Good point. I will try this. Thanks for your suggestion.
>>>>
>>> I had to make following changes to the phy_device.c to allow the phy device
>>> report maximum common flow control capability to Ethernet driver through
>>> handler. My driver code looks like this.
>>>
>>> slave->phy = of_phy_connect(gbe_intf->ndev,
>>> slave->phy_node,
>>> hndlr, 0,
>>> phy_mode);
>>> if (!slave->phy) {
>>> dev_err(priv->dev, "phy not found on slave %d\n",
>>> slave->slave_num);
>>> return -ENODEV;
>>> }
>>> dev_dbg(priv->dev, "phy found: id is: 0x%s\n",
>>> dev_name(&slave->phy->dev));
>>>
>>> slave->phy->supported &=
>>> ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
>>> slave->phy->advertising = slave->phy->supported;
>>> phy_start(slave->phy);
>>> phy_read_status(slave->phy);
>>>
>>> And then in the phy_device.c, I did to get flow control off reported in
>>> handler for link status update.
>>
>>
>>
>>>
>>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>>> index d551df6..55412ad 100644
>>> --- a/drivers/net/phy/phy_device.c
>>> +++ b/drivers/net/phy/phy_device.c
>>> @@ -1021,8 +1021,8 @@ int genphy_read_status(struct phy_device *phydev)
>>> phydev->duplex = DUPLEX_FULL;
>>>
>>> if (phydev->duplex == DUPLEX_FULL) {
>>> - phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
>>> - phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
>>> + phydev->pause = adv & lpa & LPA_PAUSE_CAP ? 1 : 0;
>>> + phydev->asym_pause = adv & lpa & LPA_PAUSE_ASYM ? 1 : 0;
>>
>> What it means before your patch is that flow control is reported to the
>> PHY device if the link partner advertises that, with your patch applied,
>> it is reported only if the link partner and yourself advertise flow control.
>>
>> You seem to be willing to have phydev->pause and phydev->asym_pause
>> reflect the resolved pause capability, as opposed to the link partner's
>> pause capability, which I am not convinced is correct here, because we
>> need to take into account the user-configured pause configuration as
>> well. Your adjust_link function should be the one deciding whether pause
>> frame advertising and enabling is appropriate based on: locally
>> configured pause settings (enabled, disabled, autoneg) and the link
>> partner's pause capability.
>>
>> I do agree that the two fields are confusing and poorly documented, and
>> we should probably be consolidating the pause frame behavior in PHYLIB
>> as opposed to letting drivers deal with like e.g: gianfar, bcm63xx_enet,
>> tg3 etc.
>>
>>>
>>> Could you explain, why the common maximum capability is not reported to the
>>> driver as per standard?? Or Am I understood it wrong?
>>
>> I do not understand the question, what is "maximum capability" in that
>> context and what standard are you refering to?
>>
> I assume the Phylib is responsible for deciding what is the flow
> control pause and asym pause status to the driver through adjust_link.
> When driver starts the phy, it also tells its capabilities (for example
> it can reset some of the capabilities available in the Phy driver. In this
> particular case, Pause is a feature supported by Micrel phy. I have reset
> this feature in my driver by resetting this feature bit in the phy_device
> as suggested earlier in this discussion). So phylib has all knowledge
> available to disable flow control in this scenario even if LP is capable
> of flow control. Wondering why every driver has to take this decision
> again to enable or disable flow control instead of telling the driver
> what to do.
What I meant is if driver tells phy not advertise, then adjust_link should
reflect the same. i.e both pause and asym_pause should be off.
Murali
>
> Looks like Marvel driver (reproduced below) does this logic. I think the
> 802.3x flow control states, but I don't have access to the standard documentation.
> However I find the documentation at
> http://www.studioreti.it/slide/08_SwFlowContr_E_A.pdf.
>
> Page 17 states the behavior based on Local device & Link partner's
> capabilities. Probably adjust_link() should tell the outcome in pause
> and asym_pause so that driver can enable/disable fc. Also user's action
> to be taken into account as well so that fc can be disabled if desired.
>
> Code from drivers/net/phy/marvel.c
>
> static int marvell_read_status(struct phy_device *phydev)
> {
>
> int adv;
> int err;
> int lpa;
> int lpagb;
> int status = 0;
>
> /* Update the link, but return if there
> * was an error */
> err = genphy_update_link(phydev);
> if (err)
> return err;
>
> if (AUTONEG_ENABLE == phydev->autoneg) {
> status = phy_read(phydev, MII_M1011_PHY_STATUS);
> if (status < 0)
> return status;
>
> lpa = phy_read(phydev, MII_LPA);
> if (lpa < 0)
> return lpa;
>
> lpagb = phy_read(phydev, MII_STAT1000);
> if (lpagb < 0)
> return lpagb;
>
> adv = phy_read(phydev, MII_ADVERTISE);
> if (adv < 0)
> return adv;
>
> phydev->lp_advertising = mii_stat1000_to_ethtool_lpa_t(lpagb) |
> mii_lpa_to_ethtool_lpa_t(lpa);
>
> lpa &= adv;
>
> if (status & MII_M1011_PHY_STATUS_FULLDUPLEX int adv;
> int err;
> int lpa;
> int lpagb;
> int status = 0;
>
> /* Update the link, but return if there
> * was an error */
> err = genphy_update_link(phydev);
> if (err)
> return err;
> )
> phydev->duplex = DUPLEX_FULL;
> else
> phydev->duplex = DUPLEX_HALF;
>
> status = status & MII_M1011_PHY_STATUS_SPD_MASK;
> phydev->pause = phydev->asym_pause = 0;
>
> switch (status) {
> case MII_M1011_PHY_STATUS_1000:
> phydev->speed = SPEED_1000;
> break;
>
> case MII_M1011_PHY_STATUS_100:
> phydev->speed = SPEED_100;
> break;
>
> default:
> phydev->speed = SPEED_10;
>
> break;
> }
>
> if (phydev->duplex == DUPLEX_FULL) {
> phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
> phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
> }
> } 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;
>
> phydev->pause = phydev->asym_pause = 0;
> phydev->lp_advertising = 0;
> }
>
> return 0;
> }
>
>
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* net/ppp: use-after-free in ppp_unregister_channel
From: Baozeng Ding @ 2016-03-16 15:14 UTC (permalink / raw)
To: linux-kernel; +Cc: paulus, linux-ppp, netdev
Dear all,
I've got the following use-after-free report while running syzkaller
fuzzer. Unfortunately no reproducer. It was found in the Linux kernel
version(4.4, on commit 9638685e32af961943b679fcb72d4ddd458eb18f).
==================================================================
BUG: KASAN: use-after-free in ppp_unregister_channel+0x372/0x3a0 at
addr ffff880064e217e0
Read of size 8 by task syz-executor/11581
=============================================================================
BUG net_namespace (Not tainted): kasan: bad access detected
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: Allocated in copy_net_ns+0x6b/0x1a0 age=92569 cpu=3 pid=6906
[< none >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
[< none >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
[< inline >] slab_alloc_node kernel/mm/slub.c:2532
[< inline >] slab_alloc kernel/mm/slub.c:2574
[< none >] kmem_cache_alloc+0x23a/0x2b0 kernel/mm/slub.c:2579
[< inline >] kmem_cache_zalloc kernel/include/linux/slab.h:597
[< inline >] net_alloc kernel/net/core/net_namespace.c:325
[< none >] copy_net_ns+0x6b/0x1a0 kernel/net/core/net_namespace.c:360
[< none >] create_new_namespaces+0x2f6/0x610 kernel/kernel/nsproxy.c:95
[< none >] copy_namespaces+0x297/0x320 kernel/kernel/nsproxy.c:150
[< none >] copy_process.part.35+0x1bf4/0x5760 kernel/kernel/fork.c:1451
[< inline >] copy_process kernel/kernel/fork.c:1274
[< none >] _do_fork+0x1bc/0xcb0 kernel/kernel/fork.c:1723
[< inline >] SYSC_clone kernel/kernel/fork.c:1832
[< none >] SyS_clone+0x37/0x50 kernel/kernel/fork.c:1826
[< none >] entry_SYSCALL_64_fastpath+0x16/0x7a kernel/arch/x86/entry/entry_64.S:185
INFO: Freed in net_drop_ns+0x67/0x80 age=575 cpu=2 pid=2631
[< none >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
[< inline >] slab_free kernel/mm/slub.c:2805
[< none >] kmem_cache_free+0x2a0/0x330 kernel/mm/slub.c:2814
[< inline >] net_free kernel/net/core/net_namespace.c:341
[< none >] net_drop_ns+0x67/0x80 kernel/net/core/net_namespace.c:348
[< none >] cleanup_net+0x4e5/0x600 kernel/net/core/net_namespace.c:448
[< none >] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
[< none >] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
[< none >] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
[< none >] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
INFO: Slab 0xffffea0001938800 objects=3 used=0 fp=0xffff880064e20000
flags=0x5fffc0000004080
INFO: Object 0xffff880064e20000 @offset=0 fp=0xffff880064e24200
CPU: 1 PID: 11581 Comm: syz-executor Tainted: G B 4.4.0+
#5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
00000000ffffffff ffff8800662c7790 ffffffff8292049d ffff88003e36a300
ffff880064e20000 ffff880064e20000 ffff8800662c77c0 ffffffff816f2054
ffff88003e36a300 ffffea0001938800 ffff880064e20000 0000000000000000
Call Trace:
[< inline >] __dump_stack kernel/lib/dump_stack.c:15
[<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
[<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
[<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
[< inline >] print_address_description kernel/mm/kasan/report.c:138
[<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
[< inline >] kasan_report kernel/mm/kasan/report.c:259
[<ffffffff816fb4de>] __asan_report_load8_noabort+0x3e/0x40 kernel/mm/kasan/report.c:280
[< inline >] ? ppp_pernet kernel/include/linux/compiler.h:218
[<ffffffff83ad71b2>] ? ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
[< inline >] ppp_pernet kernel/include/linux/compiler.h:218
[<ffffffff83ad71b2>] ppp_unregister_channel+0x372/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
[< inline >] ? ppp_pernet kernel/drivers/net/ppp/ppp_generic.c:293
[<ffffffff83ad6f26>] ? ppp_unregister_channel+0xe6/0x3a0 kernel/drivers/net/ppp/ppp_generic.c:2392
[<ffffffff83ae18f3>] ppp_asynctty_close+0xa3/0x130 kernel/drivers/net/ppp/ppp_async.c:241
[<ffffffff83ae1850>] ? async_lcp_peek+0x5b0/0x5b0 kernel/drivers/net/ppp/ppp_async.c:1000
[<ffffffff82c33239>] tty_ldisc_close.isra.1+0x99/0xe0 kernel/drivers/tty/tty_ldisc.c:478
[<ffffffff82c332c0>] tty_ldisc_kill+0x40/0x170 kernel/drivers/tty/tty_ldisc.c:744
[<ffffffff82c34943>] tty_ldisc_release+0x1b3/0x260 kernel/drivers/tty/tty_ldisc.c:772
[<ffffffff82c1ef21>] tty_release+0xac1/0x13e0 kernel/drivers/tty/tty_io.c:1901
[<ffffffff82c1e460>] ? release_tty+0x320/0x320 kernel/drivers/tty/tty_io.c:1688
[<ffffffff8174de36>] __fput+0x236/0x780 kernel/fs/file_table.c:208
[<ffffffff8174e405>] ____fput+0x15/0x20 kernel/fs/file_table.c:244
[<ffffffff813595ab>] task_work_run+0x16b/0x200 kernel/kernel/task_work.c:115
[< inline >] exit_task_work kernel/include/linux/task_work.h:21
[<ffffffff81307105>] do_exit+0x8b5/0x2c60 kernel/kernel/exit.c:750
[<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
[<ffffffff81306850>] ? mm_update_next_owner+0x6f0/0x6f0 kernel/kernel/exit.c:357
[<ffffffff813215e6>] ? __dequeue_signal+0x136/0x470 kernel/kernel/signal.c:550
[<ffffffff8132067b>] ? recalc_sigpending_tsk+0x13b/0x180 kernel/kernel/signal.c:145
[<ffffffff81309628>] do_group_exit+0x108/0x330 kernel/kernel/exit.c:880
[<ffffffff8132b9d4>] get_signal+0x5e4/0x14f0 kernel/kernel/signal.c:2307
[< inline >] ? kretprobe_table_lock kernel/kernel/kprobes.c:1113
[<ffffffff8151d355>] ? kprobe_flush_task+0xb5/0x450 kernel/kernel/kprobes.c:1158
[<ffffffff8115f7d3>] do_signal+0x83/0x1c90 kernel/arch/x86/kernel/signal.c:712
[<ffffffff8151d2a0>] ? recycle_rp_inst+0x310/0x310 kernel/include/linux/list.h:655
[<ffffffff8115f750>] ? setup_sigcontext+0x780/0x780 kernel/arch/x86/kernel/signal.c:165
[<ffffffff81380864>] ? finish_task_switch+0x424/0x5f0 kernel/kernel/sched/core.c:2692
[< inline >] ? finish_lock_switch kernel/kernel/sched/sched.h:1099
[<ffffffff81380560>] ? finish_task_switch+0x120/0x5f0 kernel/kernel/sched/core.c:2678
[< inline >] ? context_switch kernel/kernel/sched/core.c:2807
[<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
[<ffffffff81003901>] exit_to_usermode_loop+0xf1/0x1a0 kernel/arch/x86/entry/common.c:247
[< inline >] prepare_exit_to_usermode kernel/arch/x86/entry/common.c:282
[<ffffffff810062ef>] syscall_return_slowpath+0x19f/0x210 kernel/arch/x86/entry/common.c:344
[<ffffffff85d88022>] int_ret_from_sys_call+0x25/0x9f kernel/arch/x86/entry/entry_64.S:281
Memory state around the buggy address:
ffff880064e21680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880064e21700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>ffff880064e21780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff880064e21800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff880064e21880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==================================================================
Best Regards,
Baozeng Ding
^ permalink raw reply
* Re: 4.5.0 on sun7i-a20-olinuxino-lime2: libphy: PHY stmmac-0:ffffffff not found (regression from rc7)
From: Bert Lindner @ 2016-03-16 15:10 UTC (permalink / raw)
To: Andreas Färber, Robin Murphy
Cc: Marc Zyngier, Maxime Ripard, linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, Giuseppe Cavallaro
In-Reply-To: <56E95B57.1090100-l3A5Bk7waGM@public.gmane.org>
On 2016-03-16 14:10, Andreas Färber wrote:
> Am 16.03.2016 um 13:09 schrieb Robin Murphy:
>> On 16/03/16 11:39, Marc Zyngier wrote:
>>> On 16/03/16 11:19, Bert Lindner wrote:
>>>> Hopefully this is the correct place and way to report this.
>
> The main discussion is on netdev list actually, CC'ed.
>
>>>> For the board sun7i-a20-olinuxino-lime2, there seems to be a problem
>>>> with the eth0 PHY in mainline kernel 4.5.0 that developed since
>>>> 4.5.0-rc7. Ethernet does not work, although eth0 is reported:
>>>>
>>>> root@lime2-079f:~# ip a l eth0
>>>> 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
>>>> default qlen 1000
>>>> link/ether 02:c9:05:02:07:9f brd ff:ff:ff:ff:ff:ff
>>>>
>>>> Difference reported in dmesg:
>>>>
>>>> 4.5.0-rc7:
>>>> [ 9.379279] NET: Registered protocol family 10
>>>> [ 10.217148] RX IPC Checksum Offload disabled
>>>> [ 10.217195] No MAC Management Counters available
>>>> [ 10.217627] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
>>>> [ 15.206250] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
>>>> 1Gbps/Full - flow control off
>>>> [ 15.206360] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
>>>>
>>>> 4.5.0:
>>>> [ 9.767125] NET: Registered protocol family 10
>>>> [ 10.357405] libphy: PHY stmmac-0:ffffffff not found
>>>> [ 10.362382] eth0: Could not attach to PHY
>>>> [ 10.366557] stmmac_open: Cannot attach to PHY (error: -19)
>>>>
>>>> .config is identical for both, also after make oldconfig, apart from
>>>> comment with version number. DTB file is also identical between the two
>>>> versions.
>>>>
>>>> Kernels are compiled on the board itself. /proc/version string:
>>>> Linux version 4.5.0-rc7 (root@lime2-079f) (gcc version 4.9.1
>>>> (Ubuntu/Linaro 4.9.1-16ubuntu6) ) #1 SMP Mon Mar 7 11:57:25 UTC 2016
>>>> Linux version 4.5.0 (root@lime2-079f) (gcc version 4.9.1 (Ubuntu/Linaro
>>>> 4.9.1-16ubuntu6) ) #1 SMP Tue Mar 15 11:39:01 UTC 2016
>>>>
>>>> Please let me know if more info is needed, if I should post complete
>>>> .config, test compile with a particular config or patch, etc. Part of
>>>> .config below.
>>>
>>> Can you please try reverting 88f8b1b ("stmmac: Fix 'eth0: No PHY found'
>>> regression") and report whether or not this changes anything? This seems
>>> to be the only stmac patch between -rc7 and release...
>>
>> Sounds like the same thing as the giant ongoing discussion thread here:
>>
>> http://thread.gmane.org/gmane.linux.drivers.devicetree/159007/focus=402830
>
> v4 fixes for 4.5 are here:
>
> https://patchwork.ozlabs.org/patch/598195/ (revert)
> https://patchwork.ozlabs.org/patch/598196/
>
> v2 fixes for linux-next here:
>
> https://patchwork.ozlabs.org/patch/598331/ (revert)
> https://patchwork.ozlabs.org/patch/598332/
>
> Please let Peppe know whether they work for you guys.
Hi guys - I can confirm 4.5.0 minus 88f8b1b works for me:
root@lime2-079f:~# cat /proc/version
Linux version 4.5.0-minus-88f8b1b (root@lime2-079f) (gcc version 4.9.1
(Ubuntu/Linaro 4.9.1-16ubuntu6) ) #2 SMP Wed Mar 16 12:50:03 UTC 2016
From dmesg output:
[ 9.731730] NET: Registered protocol family 10
[ 10.516893] RX IPC Checksum Offload disabled
[ 10.516948] No MAC Management Counters available
[ 10.517374] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 15.505548] sun7i-dwmac 1c50000.ethernet eth0: Link is Up -
1Gbps/Full - flow control off
[ 15.505660] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
.. and connected over ethernet.
Thanks, best,
-bert
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* [PATCH net-next 2/2] ovs: support to refresh a flow via netlink
From: Samuel Gauthier @ 2016-03-16 15:07 UTC (permalink / raw)
To: Pravin Shelar, David S. Miller; +Cc: netdev, dev, Samuel Gauthier
In-Reply-To: <1458140872-22438-1-git-send-email-samuel.gauthier@6wind.com>
The used parameter of a flow tells us when it was used for the last
time. It is possible to set this parameter to 0 using the
OVS_FLOW_ATTR_CLEAR attribute, which means 'never used'. But it is not
possible to set this parameter to 'now'.
With this commit, adding OVS_FLOW_ATTR_USED to a 'set flow' netlink
message refreshes the flow used time to the current time. The value in
OVS_FLOW_ATTR_USED attribute is not used in this case.
Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
---
net/openvswitch/datapath.c | 2 ++
net/openvswitch/flow.c | 6 ++++++
net/openvswitch/flow.h | 1 +
3 files changed, 9 insertions(+)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 8c6dcffe9b62..f2050af3965a 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -1183,6 +1183,8 @@ static int ovs_flow_cmd_set(struct sk_buff *skb, struct genl_info *info)
/* Clear stats. */
if (a[OVS_FLOW_ATTR_CLEAR])
ovs_flow_stats_clear(flow);
+ if (a[OVS_FLOW_ATTR_USED])
+ ovs_flow_refresh(flow);
ovs_unlock();
if (reply)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 831db351fef9..602795dd3656 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -167,6 +167,12 @@ void ovs_flow_stats_get(const struct sw_flow *flow,
}
}
+/* Must be called with rcu_read_lock or ovs_mutex. */
+void ovs_flow_refresh(struct sw_flow *flow)
+{
+ ovs_flow_stats_update(flow, 0, 0, 0);
+}
+
/* Called with ovs_mutex. */
void ovs_flow_stats_clear(struct sw_flow *flow)
{
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index 51e10c4b1ce6..4b6b64c999ed 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -214,6 +214,7 @@ void ovs_flow_stats_update_skb(struct sw_flow *, __be16 tcp_flags,
const struct sk_buff *);
void ovs_flow_stats_get(const struct sw_flow *, struct ovs_flow_stats *,
unsigned long *used, __be16 *tcp_flags);
+void ovs_flow_refresh(struct sw_flow *);
void ovs_flow_stats_clear(struct sw_flow *);
u64 ovs_flow_used_time(unsigned long flow_jiffies);
--
2.2.1.62.g3f15098
^ permalink raw reply related
* [PATCH net-next 1/2] ovs: split ovs_flow_stats_update into skb and stats
From: Samuel Gauthier @ 2016-03-16 15:07 UTC (permalink / raw)
To: Pravin Shelar, David S. Miller; +Cc: netdev, dev, Samuel Gauthier
In-Reply-To: <1458140872-22438-1-git-send-email-samuel.gauthier@6wind.com>
The function to update statistics takes a skbuff as parameter. It
would be handy to have the statistics update part in one function, and
the skbuff part in another one.
The next commit will make use of the new ovs_flow_stats_update
function.
Signed-off-by: Samuel Gauthier <samuel.gauthier@6wind.com>
---
net/openvswitch/datapath.c | 2 +-
net/openvswitch/flow.c | 17 ++++++++++++-----
net/openvswitch/flow.h | 4 ++--
3 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index 0cc66a4e492d..8c6dcffe9b62 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -284,7 +284,7 @@ void ovs_dp_process_packet(struct sk_buff *skb, struct sw_flow_key *key)
goto out;
}
- ovs_flow_stats_update(flow, key->tp.flags, skb);
+ ovs_flow_stats_update_skb(flow, key->tp.flags, skb);
sf_acts = rcu_dereference(flow->sf_acts);
ovs_execute_actions(dp, skb, sf_acts, key);
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 0ea128eeeab2..831db351fef9 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -67,12 +67,11 @@ u64 ovs_flow_used_time(unsigned long flow_jiffies)
#define TCP_FLAGS_BE16(tp) (*(__be16 *)&tcp_flag_word(tp) & htons(0x0FFF))
-void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
- const struct sk_buff *skb)
+static void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
+ unsigned int count, unsigned int len)
{
struct flow_stats *stats;
int node = numa_node_id();
- int len = skb->len + (skb_vlan_tag_present(skb) ? VLAN_HLEN : 0);
stats = rcu_dereference(flow->stats[node]);
@@ -109,7 +108,7 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
node);
if (likely(new_stats)) {
new_stats->used = jiffies;
- new_stats->packet_count = 1;
+ new_stats->packet_count = count;
new_stats->byte_count = len;
new_stats->tcp_flags = tcp_flags;
spin_lock_init(&new_stats->lock);
@@ -124,13 +123,21 @@ void ovs_flow_stats_update(struct sw_flow *flow, __be16 tcp_flags,
}
stats->used = jiffies;
- stats->packet_count++;
+ stats->packet_count += count;
stats->byte_count += len;
stats->tcp_flags |= tcp_flags;
unlock:
spin_unlock(&stats->lock);
}
+void ovs_flow_stats_update_skb(struct sw_flow *flow, __be16 tcp_flags,
+ const struct sk_buff *skb)
+{
+ int len = skb->len + (skb_vlan_tag_present(skb) ? VLAN_HLEN : 0);
+
+ ovs_flow_stats_update(flow, tcp_flags, 1, len);
+}
+
/* Must be called with rcu_read_lock or ovs_mutex. */
void ovs_flow_stats_get(const struct sw_flow *flow,
struct ovs_flow_stats *ovs_stats,
diff --git a/net/openvswitch/flow.h b/net/openvswitch/flow.h
index 1d055c559eaf..51e10c4b1ce6 100644
--- a/net/openvswitch/flow.h
+++ b/net/openvswitch/flow.h
@@ -210,8 +210,8 @@ static inline bool ovs_identifier_is_key(const struct sw_flow_id *sfid)
return !ovs_identifier_is_ufid(sfid);
}
-void ovs_flow_stats_update(struct sw_flow *, __be16 tcp_flags,
- const struct sk_buff *);
+void ovs_flow_stats_update_skb(struct sw_flow *, __be16 tcp_flags,
+ const struct sk_buff *);
void ovs_flow_stats_get(const struct sw_flow *, struct ovs_flow_stats *,
unsigned long *used, __be16 *tcp_flags);
void ovs_flow_stats_clear(struct sw_flow *);
--
2.2.1.62.g3f15098
^ permalink raw reply related
* [PATCH net-next 0/2] ovs: refresh a flow via netlink
From: Samuel Gauthier @ 2016-03-16 15:07 UTC (permalink / raw)
To: Pravin Shelar, David S. Miller; +Cc: netdev, dev, Samuel Gauthier
This patchset adds a netlink api to refresh an existing flow in
openvswitch.
When a packet is sent in the openvswitch kernel datapath and no
flow is found, the packet is sent to the ovs-vswitchd daemon,
which will process the packet, and ask the kernel to create a new
flow. The next packets for this flow will be processed by the
kernel datapath. If a flow is not used for a (configurable)
period of time, ovs-vswitchd removes the flow from the kernel.
As a result, it can be tricky to test the kernel datapath against
packets, as the first packets of each flow will have to go
through the ovs-vswitchd daemon. For instance, to do a zeroloss
performance test, you establish the flows, and then you have to
perform your zeroloss test before the flow is removed by
ovs-vswitchd.
It is possible to configure a flow timeout in ovs-vswitchd (using
other_config:max-idle option), but it changes the behavior for
all the flows, which is not always what you want.
I tested this with a patch for the openvswitch tree of the
ovs-dpctl mod-flow command, which adds a --refresh flag. I will
submit the patch if this patchset is accepted.
Samuel Gauthier (2):
ovs: split ovs_flow_stats_update into skb and stats
ovs: support to refresh a flow via netlink
net/openvswitch/datapath.c | 4 +++-
net/openvswitch/flow.c | 23 ++++++++++++++++++-----
net/openvswitch/flow.h | 5 +++--
3 files changed, 24 insertions(+), 8 deletions(-)
--
2.2.1.62.g3f15098
^ permalink raw reply
* Re: Micrel Phy - Is there a way to configure the Phy not to do 802.3x flow control?
From: Murali Karicheri @ 2016-03-16 15:08 UTC (permalink / raw)
To: Florian Fainelli, johan, open list:TI NETCP ETHERNET DRIVER,
Kwok, WingMan, Andrew Lunn, opendmb
In-Reply-To: <56E321DE.9030408@gmail.com>
On 03/11/2016 02:51 PM, Florian Fainelli wrote:
> On 11/03/16 10:31, Murali Karicheri wrote:
>> On 03/10/2016 02:38 PM, Murali Karicheri wrote:
>>> On 03/10/2016 01:05 PM, Florian Fainelli wrote:
>>>> On 10/03/16 08:48, Murali Karicheri wrote:
>>>>> On 03/03/2016 07:16 PM, Florian Fainelli wrote:
>>>>>> On 03/03/16 14:18, Murali Karicheri wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> We are using Micrel Phy in one of our board and wondering if we can force the
>>>>>>> Phy to disable flow control at start. I have a 1G ethernet switch connected
>>>>>>> to Phy and the phy always enable flow control. I would like to configure the
>>>>>>> phy not to flow control. Is that possible and if yes, what should I do in the
>>>>>>> my Ethernet driver to tell the Phy not to enable flow control?
>>>>>>
>>>>>> The PHY is not doing flow control per-se, your pseudo Ethernet MAC in
>>>>>> the switch is doing, along with the link partner advertising support for
>>>>>> it. You would want to make sure that your PHY device interface (provided
>>>>>> that you are using the PHY library) is not starting with Pause
>>>>>> advertised, but it could be supported.
>>>>>
>>>>> Understood that Phy is just advertise FC. The Micrel phy for 9031 advertise
>>>>> by default FC supported. After negotiation, I see that Phylib provide the
>>>>> link status with parameter pause = 1, asym_pause = 1. How do I tell the Phy not
>>>>> to advertise?
>>>>>
>>>>> I call following sequence in the Ethernet driver.
>>>>>
>>>>> of_phy_connect(x,y,hndlr,a,z);
>>>>
>>>> Here you should be able to change phydev->advertising and
>>>> phydev->supported to mask the ADVERTISED_Pause | ADVERTISED_AsymPause
>>>> bits and have phy_start() restart with that which should disable pause
>>>> and asym_pause as seen by your adjust_link handler.
>>>>
>>> Ok. Good point. I will try this. Thanks for your suggestion.
>>>
>> I had to make following changes to the phy_device.c to allow the phy device
>> report maximum common flow control capability to Ethernet driver through
>> handler. My driver code looks like this.
>>
>> slave->phy = of_phy_connect(gbe_intf->ndev,
>> slave->phy_node,
>> hndlr, 0,
>> phy_mode);
>> if (!slave->phy) {
>> dev_err(priv->dev, "phy not found on slave %d\n",
>> slave->slave_num);
>> return -ENODEV;
>> }
>> dev_dbg(priv->dev, "phy found: id is: 0x%s\n",
>> dev_name(&slave->phy->dev));
>>
>> slave->phy->supported &=
>> ~(SUPPORTED_Pause | SUPPORTED_Asym_Pause);
>> slave->phy->advertising = slave->phy->supported;
>> phy_start(slave->phy);
>> phy_read_status(slave->phy);
>>
>> And then in the phy_device.c, I did to get flow control off reported in
>> handler for link status update.
>
>
>
>>
>> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
>> index d551df6..55412ad 100644
>> --- a/drivers/net/phy/phy_device.c
>> +++ b/drivers/net/phy/phy_device.c
>> @@ -1021,8 +1021,8 @@ int genphy_read_status(struct phy_device *phydev)
>> phydev->duplex = DUPLEX_FULL;
>>
>> if (phydev->duplex == DUPLEX_FULL) {
>> - phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
>> - phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
>> + phydev->pause = adv & lpa & LPA_PAUSE_CAP ? 1 : 0;
>> + phydev->asym_pause = adv & lpa & LPA_PAUSE_ASYM ? 1 : 0;
>
> What it means before your patch is that flow control is reported to the
> PHY device if the link partner advertises that, with your patch applied,
> it is reported only if the link partner and yourself advertise flow control.
>
> You seem to be willing to have phydev->pause and phydev->asym_pause
> reflect the resolved pause capability, as opposed to the link partner's
> pause capability, which I am not convinced is correct here, because we
> need to take into account the user-configured pause configuration as
> well. Your adjust_link function should be the one deciding whether pause
> frame advertising and enabling is appropriate based on: locally
> configured pause settings (enabled, disabled, autoneg) and the link
> partner's pause capability.
>
> I do agree that the two fields are confusing and poorly documented, and
> we should probably be consolidating the pause frame behavior in PHYLIB
> as opposed to letting drivers deal with like e.g: gianfar, bcm63xx_enet,
> tg3 etc.
>
>>
>> Could you explain, why the common maximum capability is not reported to the
>> driver as per standard?? Or Am I understood it wrong?
>
> I do not understand the question, what is "maximum capability" in that
> context and what standard are you refering to?
>
I assume the Phylib is responsible for deciding what is the flow
control pause and asym pause status to the driver through adjust_link.
When driver starts the phy, it also tells its capabilities (for example
it can reset some of the capabilities available in the Phy driver. In this
particular case, Pause is a feature supported by Micrel phy. I have reset
this feature in my driver by resetting this feature bit in the phy_device
as suggested earlier in this discussion). So phylib has all knowledge
available to disable flow control in this scenario even if LP is capable
of flow control. Wondering why every driver has to take this decision
again to enable or disable flow control instead of telling the driver
what to do.
Looks like Marvel driver (reproduced below) does this logic. I think the
802.3x flow control states, but I don't have access to the standard documentation.
However I find the documentation at
http://www.studioreti.it/slide/08_SwFlowContr_E_A.pdf.
Page 17 states the behavior based on Local device & Link partner's
capabilities. Probably adjust_link() should tell the outcome in pause
and asym_pause so that driver can enable/disable fc. Also user's action
to be taken into account as well so that fc can be disabled if desired.
Code from drivers/net/phy/marvel.c
static int marvell_read_status(struct phy_device *phydev)
{
int adv;
int err;
int lpa;
int lpagb;
int status = 0;
/* Update the link, but return if there
* was an error */
err = genphy_update_link(phydev);
if (err)
return err;
if (AUTONEG_ENABLE == phydev->autoneg) {
status = phy_read(phydev, MII_M1011_PHY_STATUS);
if (status < 0)
return status;
lpa = phy_read(phydev, MII_LPA);
if (lpa < 0)
return lpa;
lpagb = phy_read(phydev, MII_STAT1000);
if (lpagb < 0)
return lpagb;
adv = phy_read(phydev, MII_ADVERTISE);
if (adv < 0)
return adv;
phydev->lp_advertising = mii_stat1000_to_ethtool_lpa_t(lpagb) |
mii_lpa_to_ethtool_lpa_t(lpa);
lpa &= adv;
if (status & MII_M1011_PHY_STATUS_FULLDUPLEX int adv;
int err;
int lpa;
int lpagb;
int status = 0;
/* Update the link, but return if there
* was an error */
err = genphy_update_link(phydev);
if (err)
return err;
)
phydev->duplex = DUPLEX_FULL;
else
phydev->duplex = DUPLEX_HALF;
status = status & MII_M1011_PHY_STATUS_SPD_MASK;
phydev->pause = phydev->asym_pause = 0;
switch (status) {
case MII_M1011_PHY_STATUS_1000:
phydev->speed = SPEED_1000;
break;
case MII_M1011_PHY_STATUS_100:
phydev->speed = SPEED_100;
break;
default:
phydev->speed = SPEED_10;
break;
}
if (phydev->duplex == DUPLEX_FULL) {
phydev->pause = lpa & LPA_PAUSE_CAP ? 1 : 0;
phydev->asym_pause = lpa & LPA_PAUSE_ASYM ? 1 : 0;
}
} 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;
phydev->pause = phydev->asym_pause = 0;
phydev->lp_advertising = 0;
}
return 0;
}
--
Murali Karicheri
Linux Kernel, Keystone
^ permalink raw reply
* am335x: no multicast reception over VLAN
From: Yegor Yefremov @ 2016-03-16 15:05 UTC (permalink / raw)
To: netdev
Cc: linux-omap@vger.kernel.org, N, Mugunthan V, drivshin,
grygorii.strashko
I have an am335x based board using CPSW in Dual EMAC mode. Without
VLAN IDs I can receive and send multicast packets [1]. When I create
VLAN ID:
ip link add link eth1 name eth1.100 type vlan id 100
ip addr add 192.168.100.2/24 brd 192.168.100.255 dev eth1.100
route add -net 224.0.0.0 netmask 224.0.0.0 eth1.100
I can successfully send multicast packets, but not receive them. On
the other side of the Ethernet cable I've used Pandaboard. Pandaboard
could both receive and send multicast packets via VLAN.
This setup was tested with both 3.18.21 and 4.5 kernels.
Any idea?
[1] https://pymotw.com/2/socket/multicast.html
Regards,
Yegor
^ permalink raw reply
* Re: [PATCH ethtool 3/3] Documentation for IPv6 NFC
From: Edward Cree @ 2016-03-16 14:54 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1457887638.3331.33.camel@decadent.org.uk>
On 13/03/16 16:47, Ben Hutchings wrote:
> Why is ip6 added in the middle of the IPv4 flow-types here...
> ...and here...
> ...but not here?
Good catch; I will make them all like the last one.
> Missing nexthdr?
On the contrary, it needed to be removed from all the other places - there
is no nexthdr input, only l4proto.
-Ed
^ permalink raw reply
* Re: [PATCH ethtool 2/3] Add IPv6 support to NFC
From: Edward Cree @ 2016-03-16 14:53 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1457887406.3331.31.camel@decadent.org.uk>
On 13/03/16 16:43, Ben Hutchings wrote:
> On Mon, 2016-02-15 at 14:59 +0000, Edward Cree wrote:
>> Signed-off-by: Edward Cree <ecree@solarflare.com>
> [...]
>> @@ -950,6 +1154,19 @@ static int rxclass_get_mask(char *str, unsigned char *p,
>> *(__be32 *)&p[opt->moffset] = ~val;
>> break;
>> }
>> + case OPT_IP6: {
>> + __be32 val[4];
>> + int i;
>> + err = rxclass_get_ipv6(str, val);
>> + if (err)
>> + return -1;
>> + for (i = 0; i < 4; i++) {
>> + ((__be32 *)&p[opt->offset])[i] = val[i];
>> + if (opt->moffset >= 0)
>> + ((__be32 *)&p[opt->moffset])[i] = ~val[i];
> This pointer arithmetic looks terrible. I think memcpy() would be much
> clearer here.
I've changed the version in rxclass_get_val to use memcpy() (and memset() the
mask). Unfortunately, we can't do that here, because we need to complement
the mask valueas we go, and afaik there's no library function to copy-and-
complement a byte array.
Glibc does, however, have a function memfrob(), which XORs every byte of an
arraywiththe constant 42. Useful feature, that.
On the other hand, the quoted code is still wrong because it's also writing
throughopt->offset and checking for opt->moffset>= 0, both daft copy-and-
paste errors onmypart. Will fix in next version.
> I won't apply patches labelled as "confidential". You need to stop
> including this nonsense in your public messages (I thought you fixed
> this once before).
In theory it's been fixed harder now - please let me know if not.
-Ed
^ permalink raw reply
* Re: [PATCH net-next 0/6] bridge: support sending rntl info when we set attributes through sysfs/ioctl
From: Xin Long @ 2016-03-16 14:59 UTC (permalink / raw)
To: Nikolay Aleksandrov
Cc: network dev, davem, Hannes Frederic Sowa, Stephen Hemminger,
bridge@lists.linux-foundation.org
In-Reply-To: <56E96DFC.7090608@cumulusnetworks.com>
On Wed, Mar 16, 2016 at 10:30 PM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> On 03/16/2016 02:34 PM, Xin Long wrote:
>> This patchset is used to support sending rntl info to user in some places,
>> and ensure that whenever those attributes change internally or from sysfs,
>> that a netlink notification is sent out to listeners.
>>
>> It also make some adjustment in bridge sysfs so that we can implement this
>> easily.
>>
>> I've done some tests on this patchset, like:
>> [br_sysfs]
>> 1. change all the attribute values of br or brif:
>> $ echo $value > /sys/class/net/br0/bridge/{*}
>> $ echo $value > /sys/class/net/br0/brif/eth1/{*}
>>
>> 2. meanwhile, on another terminal to observe the msg:
>> $ bridge monitor
>>
>> [br_ioctl]
>> 1. in bridge-utils package, do some changes in br_set, let brctl command
>> use ioctl to set attribute:
>> if ((ret = set_sysfs(path, value)) < 0) { -->
>> if (1) {
>>
>> $ brctl set*
>>
>> 2. meanwhile, on another terminal to observe the msg:
>> $ bridge monitor
>>
>> This test covers all the attributes that brctl and sysfs support to set.
>>
>
> Please also include the bridge maintainers (CCed).
>
okay, I will post v2 with CC maintainers.
thanks
^ permalink raw reply
* Re: [PATCH net-next 5/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_if
From: Xin Long @ 2016-03-16 14:58 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: network dev, davem, Hannes Frederic Sowa
In-Reply-To: <56E97267.2010800@cumulusnetworks.com>
On Wed, Mar 16, 2016 at 10:49 PM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> On 03/16/2016 03:45 PM, Xin Long wrote:
>> do you think it''s redundant if we add a notification in bridge
>> fdb_flush to keep
>> consistence with port fdb_flush?
>>
> Hmm, technically we're doing this via a sysfs option and the netlink fdb flush
> one will generate a notification, so I'd say let's make them all consistent and
> make them all generate a notification, and also making the bridge fdb_flush use
> the bridge_store_parm should be trivial.
>
okay, I will also make this one use bridge_store_parm.
Thanks
^ permalink raw reply
* Re: [PATCH net-next 5/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_if
From: Nikolay Aleksandrov @ 2016-03-16 14:49 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Hannes Frederic Sowa
In-Reply-To: <CADvbK_eZUKV21x241heK45D9j62Fg7fZqd5rgG-S_LPed2WGjw@mail.gmail.com>
On 03/16/2016 03:45 PM, Xin Long wrote:
> On Wed, Mar 16, 2016 at 10:23 PM, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>> On 03/16/2016 02:34 PM, Xin Long wrote:
>>> Now when we change the attributes of bridge or br_port by netlink,
>>> a relevant netlink notification will be sent, but if we change them
>>> by ioctl or sysfs, no notification will be sent.
>>>
>>> We should ensure that whenever those attributes change internally or from
>>> sysfs/ioctl, that a netlink notification is sent out to listeners.
>>>
>>> Also, NetworkManager will use this in the future to listen for out-of-band
>>> bridge master attribute updates and incorporate them into the runtime
>>> configuration.
>>>
>>> This patch is used for br_sysfs_if, and we also move br_ifinfo_notify out
>>> of store_flag.
>>>
>>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>>> ---
>>> net/bridge/br_sysfs_if.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>
>> Generally looks good, but it creates an inconsistency between bridge fdb_flush
>> and port fdb_flush since the latter will generate a notification while the
>> bridge flush will not.
>>
> yeah, because port fdb_flush is called by brport_store(), in the
> common function.
Right.
> do you think it''s redundant if we add a notification in bridge
> fdb_flush to keep
> consistence with port fdb_flush?
>
Hmm, technically we're doing this via a sysfs option and the netlink fdb flush
one will generate a notification, so I'd say let's make them all consistent and
make them all generate a notification, and also making the bridge fdb_flush use
the bridge_store_parm should be trivial.
Thanks,
Nik
^ permalink raw reply
* Re: [PATCH net-next 5/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_if
From: Xin Long @ 2016-03-16 14:49 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: network dev, davem, Hannes Frederic Sowa
In-Reply-To: <CADvbK_eZUKV21x241heK45D9j62Fg7fZqd5rgG-S_LPed2WGjw@mail.gmail.com>
On Wed, Mar 16, 2016 at 10:45 PM, Xin Long <lucien.xin@gmail.com> wrote:
> yeah, because port fdb_flush is called by brport_store(), in the
> common function.
> do you think it''s redundant if we add a notification in bridge
> fdb_flush to keep
> consistence with port fdb_flush?
just change it on patch 1/6.
^ permalink raw reply
* Re: [PATCH net-next 5/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_if
From: Xin Long @ 2016-03-16 14:45 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: network dev, davem, Hannes Frederic Sowa
In-Reply-To: <56E96C4C.8060407@cumulusnetworks.com>
On Wed, Mar 16, 2016 at 10:23 PM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> On 03/16/2016 02:34 PM, Xin Long wrote:
>> Now when we change the attributes of bridge or br_port by netlink,
>> a relevant netlink notification will be sent, but if we change them
>> by ioctl or sysfs, no notification will be sent.
>>
>> We should ensure that whenever those attributes change internally or from
>> sysfs/ioctl, that a netlink notification is sent out to listeners.
>>
>> Also, NetworkManager will use this in the future to listen for out-of-band
>> bridge master attribute updates and incorporate them into the runtime
>> configuration.
>>
>> This patch is used for br_sysfs_if, and we also move br_ifinfo_notify out
>> of store_flag.
>>
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>> ---
>> net/bridge/br_sysfs_if.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>
> Generally looks good, but it creates an inconsistency between bridge fdb_flush
> and port fdb_flush since the latter will generate a notification while the
> bridge flush will not.
>
yeah, because port fdb_flush is called by brport_store(), in the
common function.
do you think it''s redundant if we add a notification in bridge
fdb_flush to keep
consistence with port fdb_flush?
^ permalink raw reply
* net/bluetooth: use-after-free in hci_event_packet
From: Baozeng Ding @ 2016-03-16 14:44 UTC (permalink / raw)
To: linux-kernel
Cc: linux-bluetooth, netdev, marcel, gustavo, johan.hedberg, davem
Dear all,
I've hit the following use-after-free in hci_event_packet while
fuzzying kernel(4.4, on commit
9638685e32af961943b679fcb72d4ddd458eb18f) using syzkaller. I
cannot reproduce it with a standalone C program. But it reproduces
easily by replaying the fuzzer log using Go toolchain:
$ go get github.com/google/syzkaller
$ cd $GOPATH/src/github.com/google/syzkaller
$ make executor execprog
$ scp bin/syz-executor bin/syz-execprog (your@testmachine)
$ scp poc_file your@testmachine
on your test machine:
$ ./bin/syz-execprog -executor ./bin/syz-executor -cover=0 -repeat=0
-procs=16 poc_file
The content of the poc_file is as the following:
mmap(&(0x7f0000000000)=nil, (0xd77000), 0x3, 0x32, 0xffffffffffffffff,
0x0)
r0 = syz_open_dev$vhci(&(0x7f000078a000-0x2)="2f6465762f7668636900",
0x0, 0x2081)
writev(r0, &(0x7f0000d72000+0xce4)=[{&(0x7f0000d6d000)="ff00", 0x2}],
0x1)
write(r0,
&(0x7f0000d77000-0x56)="0422e1e37a57f86c13ecf1267dbc33d62693e36b1518dee20b325c6c99f61c416e7dc6dd0452224180f8197ba570311b02cf04e1875f9a9a70c9393c9d42175b341af060368bafea5e028b50be8afea2f53a9564d00b",
0x56)
After running about a few seconds, we will get the following reports:
(in /var/log/kern.log)
BUG: KASAN: use-after-free in hci_event_packet+0x8d45/0x9f90 at addr
ffff88043ef6e310
Read of size 1 by task kworker/u17:11/9348
=============================================================================
BUG kmalloc-512 (Tainted: G B ): kasan: bad access
detected
-----------------------------------------------------------------------------
INFO: Allocated in __alloc_workqueue_key+0xf7/0xe50 age=2844 cpu=2
pid=9403
[< none >] ___slab_alloc+0x4c7/0x500 kernel/mm/slub.c:2440
[< none >] __slab_alloc+0x4c/0x90 kernel/mm/slub.c:2469
[< inline >] slab_alloc_node kernel/mm/slub.c:2532
[< inline >] slab_alloc kernel/mm/slub.c:2574
[< none >] __kmalloc+0x28f/0x320 kernel/mm/slub.c:3534
[< inline >] kmalloc kernel/include/linux/slab.h:468
[< inline >] kzalloc kernel/include/linux/slab.h:607
[< none >] __alloc_workqueue_key+0xf7/0xe50 kernel/kernel/workqueue.c:3853
[< none >] hci_register_dev+0x21b/0x870 kernel/net/bluetooth/hci_core.c:3053
[< none >] vhci_create_device+0x275/0x520 kernel/drivers/bluetooth/hci_vhci.c:135
[< inline >] vhci_get_user kernel/drivers/bluetooth/hci_vhci.c:209
[< none >] vhci_write+0x2ad/0x430 kernel/drivers/bluetooth/hci_vhci.c:289
[< none >] do_iter_readv_writev+0x18b/0x250 kernel/fs/read_write.c:703
[< none >] do_readv_writev+0x3b9/0x6e0 kernel/fs/read_write.c:847
[< none >] vfs_writev+0x86/0xc0 kernel/fs/read_write.c:886
[< inline >] SYSC_writev kernel/fs/read_write.c:919
[< none >] SyS_writev+0x111/0x2b0 kernel/fs/read_write.c:911
[< none >] entry_SYSCALL_64_fastpath+0x16/0x7a
kernel/arch/x86/entry/entry_64.S:185
INFO: Freed in rcu_free_wq+0xb6/0x110 age=353 cpu=5 pid=4134
[< none >] __slab_free+0x1fc/0x320 kernel/mm/slub.c:2650
[< inline >] slab_free kernel/mm/slub.c:2805
[< none >] kfree+0x279/0x2a0 kernel/mm/slub.c:3634
[< none >] rcu_free_wq+0xb6/0x110 kernel/kernel/workqueue.c:3159
[< inline >] __rcu_reclaim kernel/kernel/rcu/rcu.h:118
[< inline >] rcu_do_batch kernel/kernel/rcu/tree.c:2704
[< inline >] invoke_rcu_callbacks kernel/kernel/rcu/tree.c:2970
[< inline >] __rcu_process_callbacks kernel/kernel/rcu/tree.c:2937
[< none >] rcu_process_callbacks+0xb08/0x1230 kernel/kernel/rcu/tree.c:2954
[< none >] __do_softirq+0x23b/0x8a0 kernel/kernel/softirq.c:273
[< inline >] invoke_softirq kernel/kernel/softirq.c:350
[< none >] irq_exit+0x15d/0x190 kernel/kernel/softirq.c:391
[< inline >] exiting_irq kernel/./arch/x86/include/asm/apic.h:659
[< none >] smp_apic_timer_interrupt+0x7b/0xa0 kernel/arch/x86/kernel/apic/apic.c:932
[< none >] apic_timer_interrupt+0x8c/0xa0 kernel/arch/x86/entry/entry_64.S:520
[< inline >] zero_user_segments kernel/include/linux/highmem.h:202
[< none >] ext4_block_write_begin+0xb2e/0xd20 kernel/fs/ext4/inode.c:938
[< none >] ext4_da_write_begin+0x3ec/0xa30 kernel/fs/ext4/inode.c:2724
[< none >] generic_perform_write+0x297/0x540 kernel/mm/filemap.c:2537
[< none >] __generic_file_write_iter+0x351/0x5a0 kernel/mm/filemap.c:2662
[< none >] ext4_file_write_iter+0x2e7/0xc80 kernel/fs/ext4/file.c:171
[< inline >] new_sync_write kernel/fs/read_write.c:517
[< none >] __vfs_write+0x300/0x470 kernel/fs/read_write.c:530
[< none >] vfs_write+0x167/0x4a0 kernel/fs/read_write.c:577
[< inline >] SYSC_write kernel/fs/read_write.c:624
[< none >] SyS_write+0x111/0x220 kernel/fs/read_write.c:616
INFO: Slab 0xffffea0010fbdb00 objects=20 used=19 fp=0xffff88043ef6e310
flags=0x2fffc0000004080
INFO: Object 0xffff88043ef6e310 @offset=8976 fp=0x (null)
CPU: 1 PID: 9348 Comm: kworker/u17:11 Tainted: G B 4.4.0+
#5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Workqueue: hci4 hci_rx_work
00000000ffffffff ffff880433b8f6b0 ffffffff8292049d ffff88048a004b40
ffff88043ef6e310 ffff88043ef6c000 ffff880433b8f6e0 ffffffff816f2054
ffff88048a004b40 ffffea0010fbdb00 ffff88043ef6e310 ffff88043ef6e318
Call Trace:
[< inline >] __dump_stack kernel/lib/dump_stack.c:15
[<ffffffff8292049d>] dump_stack+0x6f/0xa2 kernel/lib/dump_stack.c:50
[<ffffffff816f2054>] print_trailer+0xf4/0x150 kernel/mm/slub.c:654
[<ffffffff816f875f>] object_err+0x2f/0x40 kernel/mm/slub.c:661
[< inline >] print_address_description kernel/mm/kasan/report.c:138
[<ffffffff816fb0c5>] kasan_report_error+0x215/0x530 kernel/mm/kasan/report.c:236
[< inline >] kasan_report kernel/mm/kasan/report.c:259
[<ffffffff816fb41e>] __asan_report_load1_noabort+0x3e/0x40 kernel/mm/kasan/report.c:277
[< inline >] ? hci_inquiry_result_with_rssi_evt kernel/net/bluetooth/hci_event.c:3616
[<ffffffff854db5f5>] ? hci_event_packet+0x8d45/0x9f90 kernel/net/bluetooth/hci_event.c:5323
[< inline >] hci_inquiry_result_with_rssi_evt kernel/net/bluetooth/hci_event.c:3616
[<ffffffff854db5f5>] hci_event_packet+0x8d45/0x9f90 kernel/net/bluetooth/hci_event.c:5323
[< inline >] ? spin_lock kernel/include/linux/spinlock.h:302
[<ffffffff816f3d32>] ? deactivate_slab+0x212/0x710 kernel/mm/slub.c:1949
[< inline >] ? hci_cc_read_local_amp_info kernel/net/bluetooth/hci_event.c:833
[<ffffffff854d28b0>] ? hci_cmd_complete_evt+0xcfb0/0xcfb0 kernel/net/bluetooth/hci_event.c:2905
[< inline >] ? spin_unlock kernel/include/linux/spinlock.h:347
[<ffffffff816f3f28>] ? deactivate_slab+0x408/0x710 kernel/mm/slub.c:1995
[<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
[<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
[< inline >] ? rcu_read_unlock kernel/include/linux/rcupdate.h:926
[<ffffffff813f1df7>] ? cpuacct_charge+0x1a7/0x380 kernel/kernel/sched/cpuacct.c:255
[< inline >] ? rcu_lock_release kernel/include/linux/rcupdate.h:495
[< inline >] ? rcu_read_unlock kernel/include/linux/rcupdate.h:930
[<ffffffff813f1e16>] ? cpuacct_charge+0x1c6/0x380 kernel/kernel/sched/cpuacct.c:255
[< inline >] ? task_cpu kernel/include/linux/sched.h:3111
[<ffffffff813f1cb0>] ? cpuacct_charge+0x60/0x380 kernel/kernel/sched/cpuacct.c:240
[<ffffffff8139e056>] ? rcu_read_unlock+0x16/0x70 kernel/include/linux/rcupdate.h:926
[<ffffffff813fdd20>] ? debug_check_no_locks_freed+0x290/0x290 kernel/kernel/locking/lockdep.c:4123
[<ffffffff813a0124>] ? __compute_runnable_contrib+0x54/0x70 kernel/kernel/sched/fair.c:2549
[< inline >] ? __update_load_avg kernel/kernel/sched/fair.c:2668
[<ffffffff813a0653>] ? update_cfs_rq_load_avg+0x513/0x1160 kernel/kernel/sched/fair.c:2795
[<ffffffff84c34792>] ? skb_dequeue+0x22/0x180 kernel/net/core/skbuff.c:2333
[<ffffffff813fd7ad>] ? trace_hardirqs_on+0xd/0x10 kernel/kernel/locking/lockdep.c:2619
[<ffffffff85509956>] ? hci_send_to_monitor+0x296/0x3e0 kernel/net/bluetooth/hci_sock.c:305
[<ffffffff8549ad12>] hci_rx_work+0x6f2/0xc00 kernel/net/bluetooth/hci_core.c:4157
[<ffffffff8134acaa>] ? process_one_work+0x6ca/0x1440 kernel/kernel/workqueue.c:2033
[<ffffffff8134ad74>] process_one_work+0x794/0x1440 kernel/kernel/workqueue.c:2036
[<ffffffff8134acaa>] ? process_one_work+0x6ca/0x1440 kernel/kernel/workqueue.c:2033
[<ffffffff8134a5e0>] ? pwq_dec_nr_in_flight+0x2e0/0x2e0 kernel/include/linux/compiler.h:218
[<ffffffff8134bafb>] worker_thread+0xdb/0xfc0 kernel/kernel/workqueue.c:2170
[< inline >] ? context_switch kernel/kernel/sched/core.c:2807
[<ffffffff85d794e9>] ? __schedule+0x919/0x1bd0 kernel/kernel/sched/core.c:3283
[<ffffffff8135e4ff>] kthread+0x23f/0x2d0 kernel/drivers/block/aoe/aoecmd.c:1303
[<ffffffff8134ba20>] ? process_one_work+0x1440/0x1440 kernel/include/linux/list.h:655
[<ffffffff8135e2c0>] ? kthread_create_on_node+0x3b0/0x3b0 kernel/kernel/kthread.c:285
[<ffffffff8135e2c0>] ? kthread_create_on_node+0x3b0/0x3b0 kernel/kernel/kthread.c:285
[<ffffffff85d8826f>] ret_from_fork+0x3f/0x70 kernel/arch/x86/entry/entry_64.S:468
[<ffffffff8135e2c0>] ? kthread_create_on_node+0x3b0/0x3b0 kernel/kernel/kthread.c:285
Memory state around the buggy address:
ffff88043ef6e200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff88043ef6e280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff88043ef6e300: fc fc fb fb fb fb fb fb fb fb fb fb fb fb fb fb
^
ffff88043ef6e380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff88043ef6e400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
============================================================
Best Regards,
Baozeng Ding
^ permalink raw reply
* Re: [PATCH net-next 4/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_br
From: Nikolay Aleksandrov @ 2016-03-16 14:33 UTC (permalink / raw)
To: Xin Long; +Cc: network dev, davem, Hannes Frederic Sowa
In-Reply-To: <CADvbK_fApZ76HLaVKHKukkfNMvg3b_Htz+n-vzni6H3eJPEf2Q@mail.gmail.com>
On 03/16/2016 03:29 PM, Xin Long wrote:
> On Wed, Mar 16, 2016 at 10:14 PM, Nikolay Aleksandrov
> <nikolay@cumulusnetworks.com> wrote:
>> On 03/16/2016 02:34 PM, Xin Long wrote:
>>> Now when we change the attributes of bridge or br_port by netlink,
>>> a relevant netlink notification will be sent, but if we change them
>>> by ioctl or sysfs, no notification will be sent.
>>>
>>> We should ensure that whenever those attributes change internally or from
>>> sysfs/ioctl, that a netlink notification is sent out to listeners.
>>>
>>> Also, NetworkManager will use this in the future to listen for out-of-band
>>> bridge master attribute updates and incorporate them into the runtime
>>> configuration.
>>>
>>> This patch is used for br_sysfs_br. and we also need to remove some
>>> rtnl_trylock in old functions so that we can call it in a common one.
>>>
>>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>>> ---
>>> net/bridge/br_sysfs_br.c | 17 ++++++++---------
>>> net/bridge/br_vlan.c | 30 +++++-------------------------
>>> 2 files changed, 13 insertions(+), 34 deletions(-)
>>>
>>
>> What about the group_addr option ? Changing it will not generate a notification.
>>
>>
>
> group_addr is not a string-to-long convert in sysfs. so it's hard to use
> store_bridge_parm, that's why I didn't modify it.
>
> in group_addr_store():
> it also tries to hold rtnl_lock. maybe we can send rtnl msg there.
> what do you think?
Sounds good.
>
> when I cooked this patch, I was wondering why br_recalculate_fwd_mask
> "Must be protected by RTNL."
>
vlan_enabled and vlan_proto are changed under rtnl, also this can race with
changing via netlink
^ permalink raw reply
* Re: [PATCH net-next 0/6] bridge: support sending rntl info when we set attributes through sysfs/ioctl
From: Nikolay Aleksandrov @ 2016-03-16 14:30 UTC (permalink / raw)
To: Xin Long, network dev
Cc: davem, Hannes Frederic Sowa, Stephen Hemminger,
bridge@lists.linux-foundation.org
In-Reply-To: <cover.1458134414.git.lucien.xin@gmail.com>
On 03/16/2016 02:34 PM, Xin Long wrote:
> This patchset is used to support sending rntl info to user in some places,
> and ensure that whenever those attributes change internally or from sysfs,
> that a netlink notification is sent out to listeners.
>
> It also make some adjustment in bridge sysfs so that we can implement this
> easily.
>
> I've done some tests on this patchset, like:
> [br_sysfs]
> 1. change all the attribute values of br or brif:
> $ echo $value > /sys/class/net/br0/bridge/{*}
> $ echo $value > /sys/class/net/br0/brif/eth1/{*}
>
> 2. meanwhile, on another terminal to observe the msg:
> $ bridge monitor
>
> [br_ioctl]
> 1. in bridge-utils package, do some changes in br_set, let brctl command
> use ioctl to set attribute:
> if ((ret = set_sysfs(path, value)) < 0) { -->
> if (1) {
>
> $ brctl set*
>
> 2. meanwhile, on another terminal to observe the msg:
> $ bridge monitor
>
> This test covers all the attributes that brctl and sysfs support to set.
>
Please also include the bridge maintainers (CCed).
^ permalink raw reply
* Re: [PATCH net-next 4/6] bridge: a netlink notification should be sent when those attributes are changed by br_sysfs_br
From: Xin Long @ 2016-03-16 14:29 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: network dev, davem, Hannes Frederic Sowa
In-Reply-To: <56E96A3B.1030907@cumulusnetworks.com>
On Wed, Mar 16, 2016 at 10:14 PM, Nikolay Aleksandrov
<nikolay@cumulusnetworks.com> wrote:
> On 03/16/2016 02:34 PM, Xin Long wrote:
>> Now when we change the attributes of bridge or br_port by netlink,
>> a relevant netlink notification will be sent, but if we change them
>> by ioctl or sysfs, no notification will be sent.
>>
>> We should ensure that whenever those attributes change internally or from
>> sysfs/ioctl, that a netlink notification is sent out to listeners.
>>
>> Also, NetworkManager will use this in the future to listen for out-of-band
>> bridge master attribute updates and incorporate them into the runtime
>> configuration.
>>
>> This patch is used for br_sysfs_br. and we also need to remove some
>> rtnl_trylock in old functions so that we can call it in a common one.
>>
>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>> ---
>> net/bridge/br_sysfs_br.c | 17 ++++++++---------
>> net/bridge/br_vlan.c | 30 +++++-------------------------
>> 2 files changed, 13 insertions(+), 34 deletions(-)
>>
>
> What about the group_addr option ? Changing it will not generate a notification.
>
>
group_addr is not a string-to-long convert in sysfs. so it's hard to use
store_bridge_parm, that's why I didn't modify it.
in group_addr_store():
it also tries to hold rtnl_lock. maybe we can send rtnl msg there.
what do you think?
when I cooked this patch, I was wondering why br_recalculate_fwd_mask
"Must be protected by RTNL."
^ 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