* Re: [PATCH][next] net: phy: meson-gxl: make function meson_gxl_read_status static
From: David Miller @ 2017-12-13 20:05 UTC (permalink / raw)
To: colin.king
Cc: andrew, f.fainelli, carlo, khilman, netdev, linux-arm-kernel,
linux-amlogic, kernel-janitors, linux-kernel
In-Reply-To: <20171212130311.17185-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Tue, 12 Dec 2017 13:03:11 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> The function meson_gxl_read_status is local to the source and does
> not need to be in global scope, so make it static.
>
> Cleans up sparse warning:
> symbol 'meson_gxl_read_status' was not declared. Should it be static?
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] net: phy: marvell10g: remove XGMII as an option for 88x3310
From: David Miller @ 2017-12-13 20:05 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1eOk3i-00010j-0V@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 12:53:18 +0000
> Remove XGMII as an option for the 88x3310 PHY driver, as the PHY doesn't
> support XGMII's 32-bit data lanes. It supports USXGMII, which is not
> XGMII, but a single-lane serdes interface - see
> https://developer.cisco.com/site/usgmii-usxgmii/
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH] of_mdio / mdiobus: ensure mdio devices have fwnode correctly populated
From: David Miller @ 2017-12-13 20:02 UTC (permalink / raw)
To: rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
frowand.list-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <E1eOi7f-0002Rs-K7-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
From: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Date: Tue, 12 Dec 2017 10:49:15 +0000
> Ensure that all mdio devices populate the struct device fwnode pointer
> as well as the of_node pointer to allow drivers that wish to use
> fwnode APIs to work.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Applied.
--
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 net] net: phy: fix resume handling
From: David Miller @ 2017-12-13 20:00 UTC (permalink / raw)
To: rmk+kernel; +Cc: andrew, f.fainelli, netdev
In-Reply-To: <E1eOi48-0002N2-QC@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 10:45:36 +0000
> When a PHY has the BMCR_PDOWN bit set, it may decide to ignore writes
> to other registers, or reset the registers to power-on defaults.
> Micrel PHYs do this for their interrupt registers.
>
> The current structure of phylib tries to enable interrupts before
> resuming (and releasing) the BMCR_PDOWN bit. This fails, causing
> Micrel PHYs to stop working after a suspend/resume sequence if they
> are using interrupts.
>
> Fix this by ensuring that the PHY driver resume methods do not take
> the phydev->lock mutex themselves, but the callers of phy_resume()
> take that lock. This then allows us to move the call to phy_resume()
> before we enable interrupts in phy_start().
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] ARM: dts: vf610-zii-dev: use XAUI for DSA link ports
From: David Miller @ 2017-12-13 19:59 UTC (permalink / raw)
To: rmk+kernel
Cc: andrew, f.fainelli, devicetree, linux-arm-kernel, mark.rutland,
netdev, robh+dt, kernel, shawnguo, stefan, vivien.didelot
In-Reply-To: <E1eOgsp-0001Ab-9x@rmk-PC.armlinux.org.uk>
From: Russell King <rmk+kernel@armlinux.org.uk>
Date: Tue, 12 Dec 2017 09:29:51 +0000
> Use XAUI rather than XGMII for DSA link ports, as this is the interface
> mode that the switches actually use. XAUI is the 4 lane bus with clock
> per direction, whereas XGMII is a 32 bit bus with clock.
>
> Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
> ---
> This must be applied along with patch 1 to avoid breakage.
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] net: dsa: allow XAUI phy interface mode
From: David Miller @ 2017-12-13 19:59 UTC (permalink / raw)
To: rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw
Cc: andrew-g2DYL2Zd6BY, f.fainelli-Re5JQEeQqe8AvxtiuMwx3w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
mark.rutland-5wv7dgnIgG8, netdev-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, kernel-bIcnvbaLZ9MEGnE8C9+IrQ,
shawnguo-DgEjT+Ai2ygdnm+yROfE0A, stefan-XLVq0VzYD2Y,
vivien.didelot-4ysUXcep3aM1wj+D4I0NRVaTQe2KTcn/
In-Reply-To: <E1eOgsk-0001AU-5z-eh5Bv4kxaXIk46pC+1QYvQNdhmdF6hFW@public.gmane.org>
From: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Date: Tue, 12 Dec 2017 09:29:46 +0000
> XGMII is a 32-bit bus plus two clock signals per direction. XAUI is
> four serial lanes per direction. The 88e6190 supports XAUI but not
> XGMII as it doesn't have enough pins. The same is true of 88e6176.
>
> Match on PHY_INTERFACE_MODE_XAUI for the XAUI port type, but keep
> accepting XGMII for backwards compatibility.
>
> Signed-off-by: Russell King <rmk+kernel-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org>
Applied.
--
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: x86 boot broken on -rc1?
From: Jakub Kicinski @ 2017-12-13 19:58 UTC (permalink / raw)
To: Björn Töpel; +Cc: LKML, netdev@vger.kernel.org
In-Reply-To: <CAJ+HfNicp5rKpUmx9_Y8FZDd73Ob9uquG0P7sY1nGDCY8p0NNw@mail.gmail.com>
On Wed, 13 Dec 2017 20:37:02 +0100, Björn Töpel wrote:
> 2017-12-02 1:39 GMT+01:00 Jakub Kicinski:
> > [ 5.777076] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
>
> Yes, I'm getting that as well (v4.15-rc2-772-gcdc0974f10cf).
>
> Did you bisect it? I haven't got around yet.
Yup, it's fixed but I'm not sure who far it trickled down the various
trees:
947134d9b00f ("x86/smpboot: Do not use smp_num_siblings in __max_logical_packages calculation")
^ permalink raw reply
* [patch iproute2] tc: fix json array closing
From: Jiri Pirko @ 2017-12-13 19:56 UTC (permalink / raw)
To: netdev; +Cc: stephen
From: Jiri Pirko <jiri@mellanox.com>
Fixes: 2704bd625583 ("tc: jsonify actions core")
Signed-off-by: Jiri Pirko <jiri@mellanox.com>
---
tc/m_action.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tc/m_action.c b/tc/m_action.c
index 13f942b..8185819 100644
--- a/tc/m_action.c
+++ b/tc/m_action.c
@@ -378,7 +378,7 @@ tc_print_action(FILE *f, const struct rtattr *arg, unsigned short tot_acts)
}
}
- close_json_object();
+ close_json_array(PRINT_JSON, NULL);
return 0;
}
--
2.9.5
^ permalink raw reply related
* Re: [PATCH] hippi: Fix a Fix a possible sleep-in-atomic bug in rr_close
From: David Miller @ 2017-12-13 19:53 UTC (permalink / raw)
To: baijiaju1990; +Cc: jes, jes, netdev, linux-kernel
In-Reply-To: <1513068592-23632-1-git-send-email-baijiaju1990@163.com>
From: Jia-Ju Bai <baijiaju1990@163.com>
Date: Tue, 12 Dec 2017 16:49:52 +0800
> The driver may sleep under a spinlock.
> The function call path is:
> rr_close (acquire the spinlock)
> free_irq --> may sleep
>
> To fix it, free_irq is moved to the place without holding the spinlock.
>
> This bug is found by my static analysis tool(DSAC) and checked by my code review.
>
> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
Applied.
^ permalink raw reply
* Re: [PATCH v2 0/3] r8169: extend PCI core and switch to device-managed functions in probe
From: David Miller @ 2017-12-13 19:52 UTC (permalink / raw)
To: hkallweit1; +Cc: nic_swsd, bhelgaas, netdev, linux-pci
In-Reply-To: <36fa928b-e974-c023-de3e-c2bd05f53df2@gmail.com>
From: Heiner Kallweit <hkallweit1@gmail.com>
Date: Tue, 12 Dec 2017 07:34:26 +0100
> Probe error path and remove callback can be significantly simplified
> by using device-managed functions. To be able to do this in the r8169
> driver we need a device-managed version of pci_set_mwi first.
>
> v2:
> Change patch 1 based on Björn's review comments and add his Acked-by.
Series applied, thanks.
^ permalink raw reply
* Re: thunderx sgmii interface hang
From: Andrew Lunn @ 2017-12-13 19:43 UTC (permalink / raw)
To: Tim Harvey; +Cc: netdev, Sunil Goutham
In-Reply-To: <CAJ+vNU3UwuTrDqoDZNavEqSG_gs3=bpWRzmsp-ao3fsYvMoY2g@mail.gmail.com>
> The nic appears to work fine (pings, TCP etc) up until a performance
> test is attempted.
> When an iperf bandwidth test is attempted the nic ends up in a state
> where truncated-ip packets are being sent out (per a tcpdump from
> another board):
Hi Tim
Are pause frames supported? Have you tried turning them off?
Can you reproduce the issue with UDP? Or is it TCP only?
Andrew
^ permalink raw reply
* [PATCH net] sock: free skb in skb_complete_tx_timestamp on error
From: Willem de Bruijn @ 2017-12-13 19:41 UTC (permalink / raw)
To: netdev; +Cc: richardcochran, davem, Willem de Bruijn
From: Willem de Bruijn <willemb@google.com>
skb_complete_tx_timestamp must ingest the skb it is passed. Call
kfree_skb if the skb cannot be enqueued.
Fixes: b245be1f4db1 ("net-timestamp: no-payload only sysctl")
Fixes: 9ac25fc06375 ("net: fix socket refcounting in skb_complete_tx_timestamp()")
Reported-by: Richard Cochran <richardcochran@gmail.com>
Signed-off-by: Willem de Bruijn <willemb@google.com>
---
net/core/skbuff.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6b0ff396fa9d..a592ca025fc4 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4293,7 +4293,7 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
struct sock *sk = skb->sk;
if (!skb_may_tx_timestamp(sk, false))
- return;
+ goto err;
/* Take a reference to prevent skb_orphan() from freeing the socket,
* but only if the socket refcount is not zero.
@@ -4302,7 +4302,11 @@ void skb_complete_tx_timestamp(struct sk_buff *skb,
*skb_hwtstamps(skb) = *hwtstamps;
__skb_complete_tx_timestamp(skb, sk, SCM_TSTAMP_SND, false);
sock_put(sk);
+ return;
}
+
+err:
+ kfree_skb(skb);
}
EXPORT_SYMBOL_GPL(skb_complete_tx_timestamp);
--
2.15.1.504.g5279b80103-goog
^ permalink raw reply related
* Re: x86 boot broken on -rc1?
From: Björn Töpel @ 2017-12-13 19:37 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: LKML, netdev@vger.kernel.org
In-Reply-To: <20171201163954.2e356787@cakuba.netronome.com>
2017-12-02 1:39 GMT+01:00 Jakub Kicinski <jakub.kicinski@netronome.com>:
> Hi!
>
> I'm hitting these after DaveM pulled rc1 into net-next on my Xeon
> E5-2630 v4 box. It also happens on linux-next. Did anyone else
> experience it? (.config attached)
>
> [ 5.003771] WARNING: CPU: 14 PID: 1 at ../arch/x86/events/intel/uncore.c:936 uncore_pci_probe+0x285/0x2b0
> [ 5.007544] Modules linked in:
> [ 5.007544] CPU: 14 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.007544] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.007544] task: 000000009e842725 task.stack: 000000008a63fd2d
> [ 5.007544] RIP: 0010:uncore_pci_probe+0x285/0x2b0
> [ 5.007544] RSP: 0000:ffffad8580163d10 EFLAGS: 00010286
> [ 5.007544] RAX: ffff98576cc3df30 RBX: ffffffffb08037e0 RCX: ffffffffb0c1a120
> [ 5.007544] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffb0c1a960
> [ 5.007544] RBP: ffff985b6c00ac00 R08: fffffffffffffffe R09: 00000000000fffff
> [ 5.007544] R10: ffff98576f1b6018 R11: 0000000000000022 R12: ffff985b6c641000
> [ 5.007544] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000001
> [ 5.007544] FS: 0000000000000000(0000) GS:ffff98576fb80000(0000) knlGS:0000000000000000
> [ 5.007544] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.007544] CR2: 0000000000000000 CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.007544] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.007544] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.007544] Call Trace:
> [ 5.007544] local_pci_probe+0x3d/0x90
> [ 5.007544] ? pci_match_device+0xd9/0x100
> [ 5.007544] pci_device_probe+0x122/0x180
> [ 5.007544] driver_probe_device+0x246/0x330
> [ 5.007544] ? set_debug_rodata+0x11/0x11
> [ 5.007544] __driver_attach+0x8a/0x90
> [ 5.007544] ? driver_probe_device+0x330/0x330
> [ 5.007544] bus_for_each_dev+0x5c/0x90
> [ 5.007544] bus_add_driver+0x196/0x220
> [ 5.007544] driver_register+0x57/0xc0
> [ 5.007544] intel_uncore_init+0x1e3/0x249
> [ 5.007544] ? uncore_type_init+0x193/0x193
> [ 5.007544] ? set_debug_rodata+0x11/0x11
> [ 5.007544] do_one_initcall+0x4b/0x190
> [ 5.007544] kernel_init_freeable+0x16e/0x1f5
> [ 5.007544] ? rest_init+0xd0/0xd0
> [ 5.007544] kernel_init+0xa/0x100
> [ 5.007544] ret_from_fork+0x1f/0x30
> [ 5.007544] Code: 48 8b 52 08 48 85 d2 74 0d 89 44 24 04 48 89 df ff d2 8b 44 24 04 48 89 df 89 44 24 04 e8 54 0a 1c 00 8b 44 24 0
> [ 5.007544] ---[ end trace 4dc4c3d5f5afcd2f ]---
> [ 5.244504] bdx_uncore: probe of 0000:ff:08.2 failed with error -22
> [ 5.251604] bdx_uncore: probe of 0000:ff:0b.1 failed with error -22
> [ 5.258711] bdx_uncore: probe of 0000:ff:10.1 failed with error -22
> [ 5.265819] bdx_uncore: probe of 0000:ff:14.0 failed with error -22
> [ 5.272919] bdx_uncore: probe of 0000:ff:14.1 failed with error -22
> [ 5.280019] bdx_uncore: probe of 0000:ff:15.0 failed with error -22
> [ 5.287112] bdx_uncore: probe of 0000:ff:15.1 failed with error -22
> [ 5.294376] WARNING: CPU: 1 PID: 15 at ../arch/x86/events/intel/uncore.c:1065 uncore_change_type_ctx.isra.5+0xe6/0xf0
> [ 5.298362] Modules linked in:
> [ 5.298362] CPU: 1 PID: 15 Comm: cpuhp/1 Tainted: G W 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.298362] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.298362] task: 00000000ae78bc8f task.stack: 00000000f79660c1
> [ 5.298362] RIP: 0010:uncore_change_type_ctx.isra.5+0xe6/0xf0
> [ 5.298362] RSP: 0000:ffffad85833b3db8 EFLAGS: 00010213
> [ 5.298362] RAX: 0000000000000000 RBX: ffff9857669b0200 RCX: 0000000000000001
> [ 5.298362] RDX: ffff985b6f000000 RSI: ffff985b66580400 RDI: ffffffffb0c1ae8c
> [ 5.298362] RBP: ffff985b66580400 R08: ffffffffb0c1ae8c R09: 0000000000000001
> [ 5.298362] R10: 0000000000000000 R11: 00000000003d0900 R12: 0000000000000000
> [ 5.298362] R13: ffffffffffffffff R14: 0000000000000001 R15: 0000000000000008
> [ 5.298362] FS: 0000000000000000(0000) GS:ffff985b6f000000(0000) knlGS:0000000000000000
> [ 5.298362] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.298362] CR2: 0000000000000000 CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.298362] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.298362] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.298362] Call Trace:
> [ 5.298362] uncore_event_cpu_online+0x283/0x340
> [ 5.298362] ? uncore_event_cpu_offline+0x180/0x180
> [ 5.298362] cpuhp_invoke_callback+0x8c/0x620
> [ 5.298362] ? __schedule+0x1ad/0x6c0
> [ 5.298362] ? sort_range+0x20/0x20
> [ 5.298362] cpuhp_thread_fun+0xbc/0x140
> [ 5.298362] smpboot_thread_fn+0x114/0x1d0
> [ 5.298362] kthread+0x111/0x130
> [ 5.298362] ? kthread_create_on_node+0x40/0x40
> [ 5.298362] ret_from_fork+0x1f/0x30
> [ 5.298362] Code: 2a 44 89 73 10 41 83 c4 01 48 81 c5 40 01 00 00 45 3b 20 7c cf 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 0f f
> [ 5.298362] ---[ end trace 4dc4c3d5f5afcd30 ]---
> [ 5.504808] Scanning for low memory corruption every 60 seconds
> [ 5.512347] Initialise system trusted keyrings
> [ 5.517470] workingset: timestamp_bits=40 max_order=23 bucket_order=0
> [ 5.524840] BUG: unable to handle kernel paging request at 0000000023314bf4
> [ 5.528761] IP: __kmalloc_track_caller+0xa8/0x210
> [ 5.528761] PGD 185c0a067 P4D 185c0a067 PUD 185c0c067 PMD 0
> [ 5.528761] Oops: 0000 [#1] PREEMPT SMP
> [ 5.528761] Modules linked in:
> [ 5.528761] CPU: 14 PID: 1 Comm: swapper/0 Tainted: G W 4.15.0-rc1-perf-00225-gb2a4e0a76b1d #782
> [ 5.528761] Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.3.4 11/08/2016
> [ 5.528761] task: 000000009e842725 task.stack: 000000008a63fd2d
> [ 5.528761] RIP: 0010:__kmalloc_track_caller+0xa8/0x210
> [ 5.528761] RSP: 0000:ffffad8580163d58 EFLAGS: 00010286
> [ 5.528761] RAX: 0000000000000000 RBX: ffffffffffffffff RCX: 000000000012ce0e
> [ 5.528761] RDX: 000000000012cd0e RSI: 000000000012cd0e RDI: 000000000001dde0
> [ 5.528761] RBP: ffff985700000001 R08: ffff98576f407c00 R09: ffffffffb071edbf
> [ 5.528761] R10: ffffd54de1995600 R11: ffff985b6655915f R12: 0000000000000004
> [ 5.528761] R13: 00000000014000c0 R14: ffffffffb026c239 R15: ffff98576f407c00
> [ 5.528761] FS: 0000000000000000(0000) GS:ffff98576fb80000(0000) knlGS:0000000000000000
> [ 5.528761] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 5.528761] CR2: ffffffffffffffff CR3: 0000000185c09001 CR4: 00000000003606e0
> [ 5.528761] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 5.528761] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [ 5.528761] Call Trace:
> [ 5.528761] kstrdup+0x2d/0x60
> [ 5.528761] __kernfs_new_node+0x29/0x130
> [ 5.528761] kernfs_new_node+0x24/0x50
> [ 5.528761] kernfs_create_link+0x29/0x90
> [ 5.528761] sysfs_do_create_link_sd.isra.0+0x5d/0xc0
> [ 5.528761] sysfs_slab_add+0x1f5/0x270
> [ 5.528761] ? set_debug_rodata+0x11/0x11
> [ 5.528761] slab_sysfs_init+0x8b/0xfa
> [ 5.528761] ? kmem_cache_init+0xf9/0xf9
> [ 5.528761] do_one_initcall+0x4b/0x190
> [ 5.528761] kernel_init_freeable+0x16e/0x1f5
> [ 5.528761] ? rest_init+0xd0/0xd0
> [ 5.528761] kernel_init+0xa/0x100
> [ 5.528761] ret_from_fork+0x1f/0x30
> [ 5.528761] Code: 49 63 47 20 49 8b 3f 48 8d 8a 00 01 00 00 48 8b 5c 05 00 48 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 ab 48 85 db 7
> [ 5.528761] RIP: __kmalloc_track_caller+0xa8/0x210 RSP: ffffad8580163d58
> [ 5.528761] CR2: ffffffffffffffff
> [ 5.528761] ---[ end trace 4dc4c3d5f5afcd31 ]---
> [ 5.773089] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
> [ 5.773089]
> [ 5.777076] Kernel Offset: 0x2f000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
> [ 5.777076] ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009
Yes, I'm getting that as well (v4.15-rc2-772-gcdc0974f10cf).
Did you bisect it? I haven't got around yet.
Björn
^ permalink raw reply
* [PATCH iproute2 3/3] ip: gre: fix IFLA_GRE_LINK attribute sizing
From: Serhey Popovych @ 2017-12-13 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513193762-1580-1-git-send-email-serhe.popovych@gmail.com>
Attribute IFLA_GRE_LINK is 32 bit long, not 8 bit.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/link_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 6f82fb4..09f1e44 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -155,7 +155,7 @@ get_failed:
tos = rta_getattr_u8(greinfo[IFLA_GRE_TOS]);
if (greinfo[IFLA_GRE_LINK])
- link = rta_getattr_u8(greinfo[IFLA_GRE_LINK]);
+ link = rta_getattr_u32(greinfo[IFLA_GRE_LINK]);
if (greinfo[IFLA_GRE_ENCAP_TYPE])
encaptype = rta_getattr_u16(greinfo[IFLA_GRE_ENCAP_TYPE]);
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 2/3] ip/tunnel: Use get_addr() instead of get_prefix() for local/remote endpoints
From: Serhey Popovych @ 2017-12-13 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513193762-1580-1-git-send-email-serhe.popovych@gmail.com>
Manual page ip-link(8) states that both local and remote accept
IPADDR not PREFIX. Use get_addr() instead of get_prefix() to
parse local/remote endpoint address correctly.
Force corresponding address family instead of using preferred_family
to catch weired cases as shown below.
Before this patch it is possible to create tunnel with commands:
ip li add dev ip6gre2 type ip6gre local fe80::1/64 remote fe80::2/64
ip -4 li add dev ip6gre2 type ip6gre local 10.0.0.1/24 remote 10.0.0.2/24
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/ip6tunnel.c | 8 ++------
ip/link_gre6.c | 8 ++------
ip/link_ip6tnl.c | 12 ++++--------
ip/link_vti6.c | 8 ++++----
4 files changed, 12 insertions(+), 24 deletions(-)
diff --git a/ip/ip6tunnel.c b/ip/ip6tunnel.c
index 4563e1e..b8db49c 100644
--- a/ip/ip6tunnel.c
+++ b/ip/ip6tunnel.c
@@ -170,17 +170,13 @@ static int parse_args(int argc, char **argv, int cmd, struct ip6_tnl_parm2 *p)
inet_prefix raddr;
NEXT_ARG();
- get_prefix(&raddr, *argv, preferred_family);
- if (raddr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
+ get_addr(&raddr, *argv, AF_INET6);
memcpy(&p->raddr, &raddr.data, sizeof(p->raddr));
} else if (strcmp(*argv, "local") == 0) {
inet_prefix laddr;
NEXT_ARG();
- get_prefix(&laddr, *argv, preferred_family);
- if (laddr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
+ get_addr(&laddr, *argv, AF_INET6);
memcpy(&p->laddr, &laddr.data, sizeof(p->laddr));
} else if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
diff --git a/ip/link_gre6.c b/ip/link_gre6.c
index 0a82eae..c22fded 100644
--- a/ip/link_gre6.c
+++ b/ip/link_gre6.c
@@ -257,17 +257,13 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
+ get_addr(&addr, *argv, AF_INET6);
memcpy(&raddr, &addr.data, sizeof(raddr));
} else if (!matches(*argv, "local")) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
+ get_addr(&addr, *argv, AF_INET6);
memcpy(&laddr, &addr.data, sizeof(laddr));
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
diff --git a/ip/link_ip6tnl.c b/ip/link_ip6tnl.c
index 43287ab..4ab337f 100644
--- a/ip/link_ip6tnl.c
+++ b/ip/link_ip6tnl.c
@@ -184,18 +184,14 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"remote\" address family is AF_UNSPEC", *argv);
- memcpy(&raddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&raddr, addr.data, sizeof(raddr));
} else if (strcmp(*argv, "local") == 0) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, preferred_family);
- if (addr.family == AF_UNSPEC)
- invarg("\"local\" address family is AF_UNSPEC", *argv);
- memcpy(&laddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&laddr, addr.data, sizeof(laddr));
} else if (matches(*argv, "dev") == 0) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_vti6.c b/ip/link_vti6.c
index f665520..84824a5 100644
--- a/ip/link_vti6.c
+++ b/ip/link_vti6.c
@@ -164,14 +164,14 @@ get_failed:
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&daddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&daddr, addr.data, sizeof(daddr));
} else if (!matches(*argv, "local")) {
inet_prefix addr;
NEXT_ARG();
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&saddr, addr.data, addr.bytelen);
+ get_addr(&addr, *argv, AF_INET6);
+ memcpy(&saddr, addr.data, sizeof(saddr));
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 1/3] ip/tunnel: Unify setup and accept zero address for local/remote endpoints
From: Serhey Popovych @ 2017-12-13 19:36 UTC (permalink / raw)
To: netdev
In-Reply-To: <1513193762-1580-1-git-send-email-serhe.popovych@gmail.com>
It is fully legal to submit zero (INADDR_ANY/IN6ADDR_ANY_INIT)
value for local and/or remote endpoints for all tunnel drivers:
no need additionally check this in userspace.
Note that all tunnel specific code already can pass zero address
to the kernel.
Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com>
---
ip/iptunnel.c | 10 ++--------
ip/link_gre.c | 6 ++----
ip/link_iptnl.c | 10 ++--------
ip/link_vti.c | 14 ++------------
ip/link_vti6.c | 26 ++++++++------------------
5 files changed, 16 insertions(+), 50 deletions(-)
diff --git a/ip/iptunnel.c b/ip/iptunnel.c
index 208a1f0..ce610f8 100644
--- a/ip/iptunnel.c
+++ b/ip/iptunnel.c
@@ -127,16 +127,10 @@ static int parse_args(int argc, char **argv, int cmd, struct ip_tunnel_parm *p)
p->iph.frag_off = htons(IP_DF);
} else if (strcmp(*argv, "remote") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- p->iph.daddr = get_addr32(*argv);
- else
- p->iph.daddr = htonl(INADDR_ANY);
+ p->iph.daddr = get_addr32(*argv);
} else if (strcmp(*argv, "local") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- p->iph.saddr = get_addr32(*argv);
- else
- p->iph.saddr = htonl(INADDR_ANY);
+ p->iph.saddr = get_addr32(*argv);
} else if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
medium = *argv;
diff --git a/ip/link_gre.c b/ip/link_gre.c
index 43cb1af..6f82fb4 100644
--- a/ip/link_gre.c
+++ b/ip/link_gre.c
@@ -251,12 +251,10 @@ get_failed:
pmtudisc = 1;
} else if (!matches(*argv, "remote")) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- daddr = get_addr32(*argv);
+ daddr = get_addr32(*argv);
} else if (!matches(*argv, "local")) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- saddr = get_addr32(*argv);
+ saddr = get_addr32(*argv);
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_iptnl.c b/ip/link_iptnl.c
index 4940b8b..521d6ba 100644
--- a/ip/link_iptnl.c
+++ b/ip/link_iptnl.c
@@ -195,16 +195,10 @@ get_failed:
while (argc > 0) {
if (strcmp(*argv, "remote") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- raddr = get_addr32(*argv);
- else
- raddr = 0;
+ raddr = get_addr32(*argv);
} else if (strcmp(*argv, "local") == 0) {
NEXT_ARG();
- if (strcmp(*argv, "any"))
- laddr = get_addr32(*argv);
- else
- laddr = 0;
+ laddr = get_addr32(*argv);
} else if (matches(*argv, "dev") == 0) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_vti.c b/ip/link_vti.c
index 07ac94e..05aefa3 100644
--- a/ip/link_vti.c
+++ b/ip/link_vti.c
@@ -167,20 +167,10 @@ get_failed:
okey = uval;
} else if (!matches(*argv, "remote")) {
NEXT_ARG();
- if (!strcmp(*argv, "any")) {
- fprintf(stderr, "invalid value for \"remote\": \"%s\"\n", *argv);
- exit(-1);
- } else {
- daddr = get_addr32(*argv);
- }
+ daddr = get_addr32(*argv);
} else if (!matches(*argv, "local")) {
NEXT_ARG();
- if (!strcmp(*argv, "any")) {
- fprintf(stderr, "invalid value for \"local\": \"%s\"\n", *argv);
- exit(-1);
- } else {
- saddr = get_addr32(*argv);
- }
+ saddr = get_addr32(*argv);
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
diff --git a/ip/link_vti6.c b/ip/link_vti6.c
index 6d08bfe..f665520 100644
--- a/ip/link_vti6.c
+++ b/ip/link_vti6.c
@@ -161,27 +161,17 @@ get_failed:
}
okey = uval;
} else if (!matches(*argv, "remote")) {
- NEXT_ARG();
- if (!strcmp(*argv, "any")) {
- fprintf(stderr, "invalid value for \"remote\": \"%s\"\n", *argv);
- exit(-1);
- } else {
- inet_prefix addr;
+ inet_prefix addr;
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&daddr, addr.data, addr.bytelen);
- }
- } else if (!matches(*argv, "local")) {
NEXT_ARG();
- if (!strcmp(*argv, "any")) {
- fprintf(stderr, "invalid value for \"local\": \"%s\"\n", *argv);
- exit(-1);
- } else {
- inet_prefix addr;
+ get_prefix(&addr, *argv, AF_INET6);
+ memcpy(&daddr, addr.data, addr.bytelen);
+ } else if (!matches(*argv, "local")) {
+ inet_prefix addr;
- get_prefix(&addr, *argv, AF_INET6);
- memcpy(&saddr, addr.data, addr.bytelen);
- }
+ NEXT_ARG();
+ get_prefix(&addr, *argv, AF_INET6);
+ memcpy(&saddr, addr.data, addr.bytelen);
} else if (!matches(*argv, "dev")) {
NEXT_ARG();
link = if_nametoindex(*argv);
--
1.7.10.4
^ permalink raw reply related
* [PATCH iproute2 0/3] Improve tunnel local/remote endpoint params and gre link attribute handling
From: Serhey Popovych @ 2017-12-13 19:35 UTC (permalink / raw)
To: netdev
In this series following problems addressed:
1) Size of IFLA_GRE_LINK attribute is 32 bits long in , not 8 bit.
2) Use get_addr() instead of get_prefix() to parse local/remote
tunnel endpoints as IPADDR, not PREFIX as per ip-link(8).
3) No need to check if local/remote endpoints are zero (e.g. INADDR_ANY):
it is fully legal value, accepted by the kernel.
See individual patch description message for details.
Thanks,
Serhii
Serhey Popovych (3):
ip/tunnel: Unify setup and accept zero address for local/remote
endpoints
ip/tunnel: Use get_addr() instead of get_prefix() for local/remote
endpoints
ip: gre: fix IFLA_GRE_LINK attribute sizing
ip/ip6tunnel.c | 8 ++------
ip/iptunnel.c | 10 ++--------
ip/link_gre.c | 8 +++-----
ip/link_gre6.c | 8 ++------
ip/link_ip6tnl.c | 12 ++++--------
ip/link_iptnl.c | 10 ++--------
ip/link_vti.c | 14 ++------------
ip/link_vti6.c | 26 ++++++++------------------
8 files changed, 25 insertions(+), 71 deletions(-)
--
1.7.10.4
^ permalink raw reply
* Re: [PATCH net-next] tcp/dccp: avoid one atomic operation for timewait hashdance
From: David Miller @ 2017-12-13 19:33 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1513056312.25033.49.camel@gmail.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 11 Dec 2017 21:25:12 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> First, rename __inet_twsk_hashdance() to inet_twsk_hashdance()
>
> Then, remove one inet_twsk_put() by setting tw_refcnt to 3 instead
> of 4, but adding a fat warning that we do not have the right to access
> tw anymore after inet_twsk_hashdance()
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v1] Bluetooth: introduce DEFINE_SHOW_ATTRIBUTE() macro
From: Marcel Holtmann @ 2017-12-13 19:21 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Johan Hedberg, linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
David S. Miller, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20171122211546.5682-1-andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Hi Andy,
> This macro deduplicates a lot of similar code across the hci_debugfs.c
> module. Targeting to be moved to seq_file.h eventually.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> ---
> net/bluetooth/hci_debugfs.c | 184 +++++---------------------------------------
> 1 file changed, 18 insertions(+), 166 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 00/12] Netfilter fixes for net
From: David Miller @ 2017-12-13 19:13 UTC (permalink / raw)
To: pablo; +Cc: netfilter-devel, netdev
In-Reply-To: <20171213184520.8193-1-pablo@netfilter.org>
From: Pablo Neira Ayuso <pablo@netfilter.org>
Date: Wed, 13 Dec 2017 19:45:08 +0100
> The follow patchset contains Netfilter fixes for your net tree,
> they are:
...
> You can pull these changes from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf.git
Pulled, but the attention to detail in these patches could be improved.
There were several obvious typos in the commit messages in this series.
^ permalink raw reply
* Re: [PATCH net-next] net: llc: remove init_net check
From: Alexander Aring @ 2017-12-13 19:09 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Jamal Hadi Salim, netdev
In-Reply-To: <1512072766.19682.27.camel@gmail.com>
Hi,
On Thu, Nov 30, 2017 at 3:12 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
...
>
>
> Well, we use different netns for isolation.
>
> You need more changes than simply removing this check, I guess.
>
> __llc_sap_find() would need a per netns list, or proper netns checks.
>
I looked deeper into this and try to move the list from global
resource to net struct and use per netns init... it's just a very big
task and I try to do my best there...
Also I figured out that the bridge code use a lot of global resources
which should also be per netns as well and I am worried that you can
actually move bridges to different namespaces. :-/
Just a status update - when I have time I try to do that... just need
time and it's not simple to do this change in llc.
- Alex
^ permalink raw reply
* Re: BUG REPORT: iproute2 seems to have bug with dsfield/tos in ip-rule and ip-route
From: Daniel Lakeland @ 2017-12-13 19:05 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20171213101259.65652da6@xeon-e3>
Following up my previous email with output from the machine:
Note that like some of those other people I was able to get ip rule to
accept tos values with just low order bits set
Here is example of how ip rule accepts low order dsfield bits but not modern DSCP type bits, also including some version info
dlakelan@pingpong:~$ sudo ip rule add dsfield 0x0c table 100
dlakelan@pingpong:~$ ip rule show
0: from all lookup local
32765: from all tos 0x0c lookup 100
32766: from all lookup main
32767: from all lookup default
dlakelan@pingpong:~$ sudo ip rule add dsfield 0xc0 table 100
RTNETLINK answers: Invalid argument
dlakelan@pingpong:~$ cat /proc/version
Linux version 4.12.0-1-amd64 (debian-kernel@lists.debian.org) (gcc version 6.4.0 20170805 (Debian 6.4.0-3) ) #1 SMP Debian 4.12.6-1 (2017-08-12)
dlakelan@pingpong:~$ ip -V
ip utility, iproute2-ss160518
^ permalink raw reply
* Re: [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()
From: Jakub Kicinski @ 2017-12-13 19:04 UTC (permalink / raw)
To: Al Viro; +Cc: Linus Torvalds, netdev, linux-kernel
In-Reply-To: <20171213142212.GD21978@ZenIV.linux.org.uk>
On Wed, 13 Dec 2017 14:22:12 +0000, Al Viro wrote:
> IMO it's not worth the trouble; let's go with the check inside of
> static inline and accept that on clang builds it'll do nothing.
Ack, thanks for investigating!
^ permalink raw reply
* Re: [PATCH] ipv6: ip6mr: Recalc UDP checksum before forwarding
From: Brendan McGrath @ 2017-12-13 19:02 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller, netdev, linux-kernel
In-Reply-To: <1513187564.25033.65.camel@gmail.com>
I should clarify that the packet being forwarded originated on the
Virtual Interface (i.e. it wasn't received on it). When data is received
on the Virtual Interface (i.e. sent by a virtual host) then ip_summed is
CHECKSUM_PARTIAL and the checksum is calculated before transmission on
the wire.
The scenario I was testing (which caused the csum error) was to:
a) send multicast data to virtual devices over the Virtual Interface;
and then
b) add an MFC to forward traffic from the Virtual Interface to a
Physical Interface (so one of the machines on the physical network could
receive it).
The packet was accepted by the Virtual devices (even though tcpdump
shows an invalid CRC) but rejected by the Physical devices. My
assumption here was there is some kind of optimisation (for a
virtualised Linux kernel on the same host) but I didn't find the code to
verify that assumption.
My tests and findings were:
MR = Multicast Router
VM = Virtual Machine (connected to the MR via a virtual switch [virbr0])
PH = Physical Machine (connected via a physical switch [br0])
The asterisk indicates where packet originated.
The value of ip_summed is being checked by a netfilter hook registered
to NF_INET_FORWARD.
The CRC value was checked by tcpdump on the receiving interface.
"Packet accepted" indicates that the application received the packet.
Scenario 1:
VM <------* MR --------> PH
VM CRC: Incorrect (packet accepted)
PH CRC: Incorrect (packet rejected)
ip_summed = 1 (CHECKSUM_UNNECESSARY)
Scenario 2:
VM *------> MR --------> PH
MR(br0) CRC: Incorrect (packet accepted)
PH CRC: Correct (packet accepted)
ip_summed = 3 (CHECKSUM_PARTIAL)
Scenario 3:
VM <------- MR *-------> PH
VM CRC: Correct (packet accepted)
PH CRC: Correct (packet accepted)
ip_summed = 1 (CHECKSUM_UNNECESSARY)
On 14/12/17 04:52, Eric Dumazet wrote:
> On Wed, 2017-12-13 at 22:20 +1100, Brendan McGrath wrote:
>> Currently, when forwarding from a Virtual Interface to a Physical
>> Interface, ip_summed is set to a value of CHECKSUM_UNNECESSARY and
>> the UDP checksum has not been calculated.
>>
> This seems a bug then ?
> CHECKSUM_UNNECESSARY means checksum has been validated.
> Not that we want it being computed later in the stack.
>
> If we force a checksum here, what guarantee do we have packet was not
> corrupted before we do this ?
>
^ permalink raw reply
* Re: [PATCH net-next v3 0/6] net: qualcomm: rmnet: Configuration options
From: David Miller @ 2017-12-13 19:01 UTC (permalink / raw)
To: subashab; +Cc: netdev
In-Reply-To: <1513038615-16407-1-git-send-email-subashab@codeaurora.org>
From: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Date: Mon, 11 Dec 2017 17:30:09 -0700
> This series adds support for configuring features on rmnet devices.
> The rmnet specific features to be configured here are aggregation and
> control commands.
>
> Patch 1 is a cleanup of return codes in the transmit path.
> Patch 2 removes some redundant ingress and egress macros.
> Patch 3 restricts the creation of rmnet dev to one dev per mux id for a
> given real dev.
> Patch 4 adds ethernet data path support.
> Patches 5-6 add support for configuring features on new and existing
> rmnet devices.
>
> v1->v2:
> The memory leak fixed as part of patch 1 is merged seperately as
> a896d94abd2c ("net: qualcomm: rmnet: Fix leak on transmit failure").
> Fix a use after free in patch 4 if a packet with headroom lesser than ethernet
> header length is received.
>
> v2->v3:
> Fix formatting problem in patch 5 in the return statement.
Series applied, thanks.
^ 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