Re: [PATCH] net, can, ti_hecc: add DT support for the ti,hecc controller
On 10/19/2015 08:39 AM, Heiko Schocher wrote:
> add DT support for the ti hecc controller, used on
> am3517 SoCs.
A similar patch was posted a few days ago, see
http://comments.gmane.org/gmane.linux.can/8616 and my comments.
Please coordinate with Anton Glukhov (Cc'ed) and/or pick up his patches
as they are in better shape.
Marc
>
> Signed-off-by: Heiko Schocher
> ---
>
> .../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
> arch/arm/boot/dts/am3517.dtsi | 13 +++
> drivers/net/can/ti_hecc.c | 45
> +-
> 3 files changed, 76 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
>
> diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
> b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
> new file mode 100644
> index 000..09fab59
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
> @@ -0,0 +1,20 @@
> +* TI HECC CAN *
> +
> +Required properties:
> + - compatible: Should be "ti,hecc"
We usually put the name of the first SoC this IP core appears in to the
compatible.
> + - reg: Should contain CAN controller registers location and length
> + - interrupts: Should contain IRQ line for the CAN controller
I'm missing the description of the ti,* properties. I think they are
required, too. Although the code doesn't enforce it.
> +
> +Example:
> +
> + can0: hecc@5c05 {
> + compatible = "ti,hecc";
> + reg = <0x5c05 0x4000>;
> + interrupts = <24>;
> + ti,hecc_scc_offset = <0>;
> + ti,hecc_scc_ram_offset = <0x3000>;
> + ti,hecc_ram_offset = <0x3000>;
> + ti,hecc_mbx_offset = <0x2000>;
> + ti,hecc_int_line = <0>;
> + ti,hecc_version = <1>;
Versioning in the OF world is done via the compatible. Are the offsets a
per SoC parameter? I'm not sure if it's better to put
the offsets into the driver.
> + };
> diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
> index 5e3f5e8..47bc429 100644
> --- a/arch/arm/boot/dts/am3517.dtsi
> +++ b/arch/arm/boot/dts/am3517.dtsi
> @@ -25,6 +25,19 @@
> interrupt-names = "mc";
> };
>
> + can0: hecc@5c05 {
> + compatible = "ti,hecc";
> + reg = <0x5c05 0x4000>;
> + interrupts = <24>;
> + ti,hecc_scc_offset = <0>;
> + ti,hecc_scc_ram_offset = <0x3000>;
> + ti,hecc_ram_offset = <0x3000>;
> + ti,hecc_mbx_offset = <0x2000>;
> + ti,hecc_int_line = <0>;
> + ti,hecc_version = <1>;
> + status = "disabled";
> + };
> +
> davinci_emac: ethernet@0x5c00 {
> compatible = "ti,am3517-emac";
> ti,hwmods = "davinci_emac";
> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
> index c08e8ea..f1705d5 100644
> --- a/drivers/net/can/ti_hecc.c
> +++ b/drivers/net/can/ti_hecc.c
> @@ -875,16 +875,56 @@ static const struct net_device_ops ti_hecc_netdev_ops =
> {
> .ndo_change_mtu = can_change_mtu,
> };
>
> +#if defined(CONFIG_OF)
> +static const struct of_device_id ti_hecc_can_dt_ids[] = {
> + {
> + .compatible = "ti,hecc",
> + }, {
> + /* sentinel */
> + }
> +};
> +MODULE_DEVICE_TABLE(of, ti_hecc_can_dt_ids);
> +#endif
Please remove the ifdef, use __maybe_unused instead.
> +
> +static const struct ti_hecc_platform_data
> +*ti_hecc_can_get_driver_data(struct platform_device *pdev)
> +{
> + if (pdev->dev.of_node) {
> + struct ti_hecc_platform_data *data;
> + struct device_node *np = pdev->dev.of_node;
> +
> + data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
> + if (!data)
> + return NULL;
> +
> + of_property_read_u32(np, "ti,hecc_scc_offset",
> + &data->scc_hecc_offset);
> + of_property_read_u32(np, "ti,hecc_scc_ram_offset",
> + &data->scc_ram_offset);
> + of_property_read_u32(np, "ti,hecc_ram_offset",
> + &data->hecc_ram_offset);
> + of_property_read_u32(np, "ti,hecc_mbx_offset",
> + &data->mbx_offset);
> + of_property_read_u32(np, "ti,hecc_int_line",
> + &data->int_line);
> + of_property_read_u32(np, "ti,hecc_version",
> + &data->version);
I'm missing error handling here.
> + return data;
> + }
> + return (const struct ti_hecc_platform_data *)
> + dev_get_platdata(&pdev->dev);
Is th
Re: [PATCH] net, can, ti_hecc: fix a run time warn_on.
Hello Marc,
Am 19.10.2015 um 08:34 schrieb Marc Kleine-Budde:
On 10/19/2015 08:22 AM, Heiko Schocher wrote:
This patch fixes a warning in clk_enable by calling
clk_prepare_enable instead.
What about the corresponding clk_disable_unprepare()?
Yes, that should be fixed too, do this in a v2, thanks!
bye,
Heiko
Marc
Signed-off-by: Heiko Schocher
---
drivers/net/can/ti_hecc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index cf345cb..c08e8ea 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -951,7 +951,7 @@ static int ti_hecc_probe(struct platform_device *pdev)
netif_napi_add(ndev, &priv->napi, ti_hecc_rx_poll,
HECC_DEF_NAPI_WEIGHT);
- clk_enable(priv->clk);
+ clk_prepare_enable(priv->clk);
err = register_candev(ndev);
if (err) {
dev_err(&pdev->dev, "register_candev() failed\n");
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[net-next:master 1236/1358] net/netfilter/nfnetlink_log.c:320:14: warning: 'flags' may be used uninitialized in this function
tree: https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git
master
head: 371f1c7e0d854796adc622cc3bacfcc5fc638db1
commit: 8cbc870829ecd8f1062f2a756683c80e2d1eae7f [1236/1358] netfilter:
nfnetlink_log: validate dependencies to avoid breaking atomicity
config: m68k-sun3_defconfig (attached as .config)
reproduce:
wget
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
-O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 8cbc870829ecd8f1062f2a756683c80e2d1eae7f
# save the attached .config to linux build tree
make.cross ARCH=m68k
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
net/netfilter/nfnetlink_log.c: In function 'nfulnl_recv_config':
>> net/netfilter/nfnetlink_log.c:320:14: warning: 'flags' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
inst->flags = flags;
^
net/netfilter/nfnetlink_log.c:828:6: note: 'flags' was declared here
u16 flags;
^
vim +/flags +320 net/netfilter/nfnetlink_log.c
0597f268 Harald Welte2005-08-09 304 }
0597f268 Harald Welte2005-08-09 305
0597f268 Harald Welte2005-08-09 306 static int
0597f268 Harald Welte2005-08-09 307 nfulnl_set_qthresh(struct
nfulnl_instance *inst, u_int32_t qthresh)
0597f268 Harald Welte2005-08-09 308 {
0597f268 Harald Welte2005-08-09 309spin_lock_bh(&inst->lock);
0597f268 Harald Welte2005-08-09 310inst->qthreshold = qthresh;
0597f268 Harald Welte2005-08-09 311spin_unlock_bh(&inst->lock);
0597f268 Harald Welte2005-08-09 312
0597f268 Harald Welte2005-08-09 313return 0;
0597f268 Harald Welte2005-08-09 314 }
0597f268 Harald Welte2005-08-09 315
0af5f6c1 Harald Welte2006-03-20 316 static int
0af5f6c1 Harald Welte2006-03-20 317 nfulnl_set_flags(struct
nfulnl_instance *inst, u_int16_t flags)
0af5f6c1 Harald Welte2006-03-20 318 {
0af5f6c1 Harald Welte2006-03-20 319spin_lock_bh(&inst->lock);
ee433530 Patrick McHardy 2006-05-19 @320inst->flags = flags;
0af5f6c1 Harald Welte2006-03-20 321spin_unlock_bh(&inst->lock);
0af5f6c1 Harald Welte2006-03-20 322
0af5f6c1 Harald Welte2006-03-20 323return 0;
0af5f6c1 Harald Welte2006-03-20 324 }
0af5f6c1 Harald Welte2006-03-20 325
c6a8f648 Michal Miroslaw 2007-09-28 326 static struct sk_buff *
afff14f6 Gao feng2013-09-23 327 nfulnl_alloc_skb(struct net *net, u32
peer_portid, unsigned int inst_size,
afff14f6 Gao feng2013-09-23 328 unsigned int pkt_size)
:: The code at line 320 was first introduced by commit
:: ee433530d96a7b0af24ab616e5b51f1d89f9ae38 [NETFILTER]: nfnetlink_log: fix
byteorder confusion
:: TO: Patrick McHardy
:: CC: David S. Miller
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[GIT] Networking
1) Account for extra headroom in ath9k driver, from Felix Fietkau. 2) Fix OOPS in pppoe driver due to incorrect socket state transition, from Guillaume Nault. 3) Kill memory leak in amd-xgbe debugfx, from Geliang Tang. 4) Power management fixes for iwlwifi, from Johannes Berg. 5) Fix races in reqsk_queue_unlink(), from Eric Dumazet. 6) Fix dst_entry usage in ARP replies, from Jiri Benc. 7) Cure OOPSes with SO_GET_FILTER, from Daniel Borkmann. 8) Missing allocation failure check in amd-xgbe, from Tom Lendacky. 9) Various resource allocation/freeing cures in DSA< from Neil Armstrong. 10) A series of bug fixes in the openvswitch conntrack support, from Joe Stringer. 11) Fix two cases (BPF and act_mirred) where we have to clean the sender cpu stored in the SKB before transmitting. From WANG Cong and Alexei Starovoitov. 12) Disable VLAN filtering in promiscuous mode in mlx5 driver, from Achiad Shochat. 13) Older bnx2x chips cannot do 4-tuple UDP hashing, so prevent this configuration via ethtool. From Yuval Mintz. 14) Don't call rt6_uncached_list_flush_dev() from rt6_ifdown() when 'dev' is NULL, from Eric Biederman. 15) Prevent stalled link synchronization in tipc, from Jon Paul Maloy. 16) kcalloc() gstrings ethtool buffer before having driver fill it in, in order to prevent kernel memory leaking. From Joe Perches. 17) Fix mixxing rt6_info initialization for blackhole routes, from Martin KaFai Lau. 18) Kill VLAN regression in via-rhine, from Andrej Ota. 19) Missing pfmemalloc check in sk_add_backlog(), from Eric Dumazet. 20) Fix spurious MSG_TRUNC signalling in netlink dumps, from Ronen Arad. 21) Scrube SKBs when pushing them between namespaces in openvswitch, from Joe Stringer. 22) bcmgenet enables link interrupts too early, fix from Florian Fainelli. Please pull, thanks a lot! The following changes since commit 36f8dafe52b0d0726edd5102900e37192f1d3c65: Merge tag 'mmc-v4.3-rc3' of git://git.linaro.org/people/ulf.hansson/mmc (2015-10-02 08:03:04 -0400) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master for you to fetch changes up to 37850e37fcfb4dd831bc9e33221e8c49a732956f: net: bcmgenet: Fix early link interrupt enabling (2015-10-18 23:07:12 -0700) Achiad Shochat (1): net/mlx5e: Disable VLAN filter in promiscuous mode Alexei Starovoitov (1): bpf: clear sender_cpu before xmit Andrei Otcheretianski (1): iwlwifi: mvm: flush fw_dump_wk when mvm fails to start Andrej Ota (1): via-rhine: fix VLAN receive handling regression. Andrey Vagin (1): net/unix: fix logic about sk_peek_offset Arad, Ronen (2): rtnetlink: fix gcc -Wconversion warning netlink: Trim skb to alloc size to avoid MSG_TRUNC Arik Nemtsov (1): iwlwifi: mvm: init card correctly on ctkill exit check Arnd Bergmann (1): mlxsw: fix warnings for big-endian 32-bit dma_addr_t Avraham Stern (1): iwlwifi: mvm: clear csa countdown when AP is stopped Carol L Soto (2): net/mlx4: Remove shared_ports variable at mlx4_enable_msi_x net/mlx4_core: Avoid failing the interrupts test Chia-Sheng Chang (1): net: asix: add support for the Billionton GUSB2AM-1G-B USB adapter Daniel Borkmann (1): bpf: fix panic in SO_GET_FILTER with native ebpf programs David Ahern (1): net: Fix vti use case with oif in dst lookups for IPv6 David B. Robins (1): net: usb: asix: Fix crash on skb alloc failure David S. Miller (11): Merge tag 'linux-can-fixes-for-4.3-20150930' of git://git.kernel.org/.../mkl/linux-can Merge tag 'wireless-drivers-for-davem-2015-10-01' of git://git.kernel.org/.../kvalo/wireless-drivers Merge branch 'dsa-unbind' Merge branch 'ovs-ct-fixes' Merge branch 'mlx' Merge branch 'mlxsw-fixes' Merge branch 'be2net-fixes' Merge tag 'mac80211-for-davem-2015-10-13' of git://git.kernel.org/.../jberg/mac80211 Merge branch 'ipv6-blackhole-route-fix' Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth Merge tag 'wireless-drivers-for-davem-2015-10-17' of git://git.kernel.org/.../kvalo/wireless-drivers Elad Raz (1): mlxsw: switchx2: changing order of exit fallbacks Eric Dumazet (2): inet: fix race in reqsk_queue_unlink() net: add pfmemalloc check in sk_add_backlog() Eric W. Biederman (1): ipv6: Don't call with rt6_uncached_list_flush_dev Felix Fietkau (3): mac80211: fix handling of PS filtering with fast-xmit ath9k: declare required extra tx headroom ath10k: fix DMA related firmware crashes on multiple devices Florian Fainelli (1): net: bcmgenet: Fix early link interrupt enabling Geliang Tang (1): amd-xgbe: fix potential memory leak in xgbe-debugfs Gerlando Falauto (2): net/fsl_pq_mdio: check TBI addr
[PATCH] net, can, ti_hecc: add DT support for the ti,hecc controller
add DT support for the ti hecc controller, used on
am3517 SoCs.
Signed-off-by: Heiko Schocher
---
.../devicetree/bindings/net/can/ti_hecc-can.txt| 20 ++
arch/arm/boot/dts/am3517.dtsi | 13 +++
drivers/net/can/ti_hecc.c | 45 +-
3 files changed, 76 insertions(+), 2 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
diff --git a/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
new file mode 100644
index 000..09fab59
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/ti_hecc-can.txt
@@ -0,0 +1,20 @@
+* TI HECC CAN *
+
+Required properties:
+ - compatible: Should be "ti,hecc"
+ - reg: Should contain CAN controller registers location and length
+ - interrupts: Should contain IRQ line for the CAN controller
+
+Example:
+
+ can0: hecc@5c05 {
+ compatible = "ti,hecc";
+ reg = <0x5c05 0x4000>;
+ interrupts = <24>;
+ ti,hecc_scc_offset = <0>;
+ ti,hecc_scc_ram_offset = <0x3000>;
+ ti,hecc_ram_offset = <0x3000>;
+ ti,hecc_mbx_offset = <0x2000>;
+ ti,hecc_int_line = <0>;
+ ti,hecc_version = <1>;
+ };
diff --git a/arch/arm/boot/dts/am3517.dtsi b/arch/arm/boot/dts/am3517.dtsi
index 5e3f5e8..47bc429 100644
--- a/arch/arm/boot/dts/am3517.dtsi
+++ b/arch/arm/boot/dts/am3517.dtsi
@@ -25,6 +25,19 @@
interrupt-names = "mc";
};
+ can0: hecc@5c05 {
+ compatible = "ti,hecc";
+ reg = <0x5c05 0x4000>;
+ interrupts = <24>;
+ ti,hecc_scc_offset = <0>;
+ ti,hecc_scc_ram_offset = <0x3000>;
+ ti,hecc_ram_offset = <0x3000>;
+ ti,hecc_mbx_offset = <0x2000>;
+ ti,hecc_int_line = <0>;
+ ti,hecc_version = <1>;
+ status = "disabled";
+ };
+
davinci_emac: ethernet@0x5c00 {
compatible = "ti,am3517-emac";
ti,hwmods = "davinci_emac";
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index c08e8ea..f1705d5 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -875,16 +875,56 @@ static const struct net_device_ops ti_hecc_netdev_ops = {
.ndo_change_mtu = can_change_mtu,
};
+#if defined(CONFIG_OF)
+static const struct of_device_id ti_hecc_can_dt_ids[] = {
+ {
+ .compatible = "ti,hecc",
+ }, {
+ /* sentinel */
+ }
+};
+MODULE_DEVICE_TABLE(of, ti_hecc_can_dt_ids);
+#endif
+
+static const struct ti_hecc_platform_data
+*ti_hecc_can_get_driver_data(struct platform_device *pdev)
+{
+ if (pdev->dev.of_node) {
+ struct ti_hecc_platform_data *data;
+ struct device_node *np = pdev->dev.of_node;
+
+ data = devm_kzalloc(&pdev->dev, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return NULL;
+
+ of_property_read_u32(np, "ti,hecc_scc_offset",
+&data->scc_hecc_offset);
+ of_property_read_u32(np, "ti,hecc_scc_ram_offset",
+&data->scc_ram_offset);
+ of_property_read_u32(np, "ti,hecc_ram_offset",
+&data->hecc_ram_offset);
+ of_property_read_u32(np, "ti,hecc_mbx_offset",
+&data->mbx_offset);
+ of_property_read_u32(np, "ti,hecc_int_line",
+&data->int_line);
+ of_property_read_u32(np, "ti,hecc_version",
+&data->version);
+ return data;
+ }
+ return (const struct ti_hecc_platform_data *)
+ dev_get_platdata(&pdev->dev);
+}
+
static int ti_hecc_probe(struct platform_device *pdev)
{
struct net_device *ndev = (struct net_device *)0;
struct ti_hecc_priv *priv;
- struct ti_hecc_platform_data *pdata;
+ const struct ti_hecc_platform_data *pdata;
struct resource *mem, *irq;
void __iomem *addr;
int err = -ENODEV;
- pdata = dev_get_platdata(&pdev->dev);
+ pdata = ti_hecc_can_get_driver_data(pdev);
if (!pdata) {
dev_err(&pdev->dev, "No platform data\n");
goto probe_exit;
@@ -1040,6 +1080,7 @@ static int ti_hecc_resume(struct platform_device *pdev)
static struct platform_driver ti_hecc_driver = {
.driver = {
.name= DRV_NAME,
+ .of_match_table = of_match_ptr(ti_hecc_can_dt_ids),
},
.probe = ti_h
Re: [PATCH] net, can, ti_hecc: fix a run time warn_on.
On 10/19/2015 08:22 AM, Heiko Schocher wrote:
> This patch fixes a warning in clk_enable by calling
> clk_prepare_enable instead.
What about the corresponding clk_disable_unprepare()?
Marc
>
> Signed-off-by: Heiko Schocher
> ---
>
> drivers/net/can/ti_hecc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
> index cf345cb..c08e8ea 100644
> --- a/drivers/net/can/ti_hecc.c
> +++ b/drivers/net/can/ti_hecc.c
> @@ -951,7 +951,7 @@ static int ti_hecc_probe(struct platform_device *pdev)
> netif_napi_add(ndev, &priv->napi, ti_hecc_rx_poll,
> HECC_DEF_NAPI_WEIGHT);
>
> - clk_enable(priv->clk);
> + clk_prepare_enable(priv->clk);
> err = register_candev(ndev);
> if (err) {
> dev_err(&pdev->dev, "register_candev() failed\n");
>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
[PATCH] net, can, ti_hecc: fix a run time warn_on.
This patch fixes a warning in clk_enable by calling
clk_prepare_enable instead.
Signed-off-by: Heiko Schocher
---
drivers/net/can/ti_hecc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/can/ti_hecc.c b/drivers/net/can/ti_hecc.c
index cf345cb..c08e8ea 100644
--- a/drivers/net/can/ti_hecc.c
+++ b/drivers/net/can/ti_hecc.c
@@ -951,7 +951,7 @@ static int ti_hecc_probe(struct platform_device *pdev)
netif_napi_add(ndev, &priv->napi, ti_hecc_rx_poll,
HECC_DEF_NAPI_WEIGHT);
- clk_enable(priv->clk);
+ clk_prepare_enable(priv->clk);
err = register_candev(ndev);
if (err) {
dev_err(&pdev->dev, "register_candev() failed\n");
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ipv6 route: Aggregate table getting code
From: Masashi Honma Date: Sun, 18 Oct 2015 09:51:39 +0900 > These lines could be aggregated to one line because fib6_new_table() calls > fib6_get_table() inside on both cases CONFIG_IPV6_MULTIPLE_TABLES is enabled > or > not. > > Signed-off-by: Masashi Honma This is not correct. The whole point of the test is so that the kernel log message warning for failing to provide NLM_F_CREATE can be printed in precisely the correct conditions. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] net: bcmgenet: Fix early link interrupt enabling
From: Florian Fainelli
Date: Sat, 17 Oct 2015 14:22:46 -0700
> From: Florian Fainelli
>
> Link interrupts are enabled in init_umac(), which is too early for us to
> process them since we do not yet have a valid PHY device pointer. On
> BCM7425 chips for instance, we will crash calling phy_mac_interrupt()
> because phydev is NULL.
>
> Fix this by moving the link interrupts enabling in
> bcmgenet_netif_start(), under a specific function:
> bcmgenet_link_intr_enable() and while at it, update the comments
> surrounding the code.
>
> Fixes: 6cc8e6d4dcb36 ("net: bcmgenet: Delay PHY initialization to
> bcmgenet_open()")
> Signed-off-by: Florian Fainelli
Applied, thanks Florian.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull-request: wireless-drivers 2015-10-17
From: Kalle Valo Date: Sat, 17 Oct 2015 08:26:19 +0300 > few small fixes I would like to get to 4.3 still. Please let me know if > there are any problems. Pulled, thanks Kalle. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/35] Netfilter/IPVS updates for net-next
From: Pablo Neira Ayuso Date: Sat, 17 Oct 2015 15:48:50 +0200 > This is exactly the same pull request, including the conflict > resolution for net/bridge/br_netfilter_hooks.c. Pulled, thanks Pablo. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] xen-netfront: update num_queues to real created
Sometimes xennet_create_queues() may failed to created all requested
queues, we need to update num_queues to real created to avoid NULL
pointer dereference.
Signed-off-by: Joe Jin
Cc: Boris Ostrovsky
Cc: Konrad Rzeszutek Wilk
Cc: Wei Liu
Cc: Ian Campbell
Cc: David S. Miller
---
drivers/net/xen-netfront.c | 14 +++---
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index f821a97..6febc05 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -1706,19 +1706,19 @@ static void xennet_destroy_queues(struct netfront_info
*info)
}
static int xennet_create_queues(struct netfront_info *info,
- unsigned int num_queues)
+ unsigned int *num_queues)
{
unsigned int i;
int ret;
- info->queues = kcalloc(num_queues, sizeof(struct netfront_queue),
+ info->queues = kcalloc(*num_queues, sizeof(struct netfront_queue),
GFP_KERNEL);
if (!info->queues)
return -ENOMEM;
rtnl_lock();
- for (i = 0; i < num_queues; i++) {
+ for (i = 0; i < *num_queues; i++) {
struct netfront_queue *queue = &info->queues[i];
queue->id = i;
@@ -1728,7 +1728,7 @@ static int xennet_create_queues(struct netfront_info
*info,
if (ret < 0) {
dev_warn(&info->netdev->dev,
"only created %d queues\n", i);
- num_queues = i;
+ *num_queues = i;
break;
}
@@ -1738,11 +1738,11 @@ static int xennet_create_queues(struct netfront_info
*info,
napi_enable(&queue->napi);
}
- netif_set_real_num_tx_queues(info->netdev, num_queues);
+ netif_set_real_num_tx_queues(info->netdev, *num_queues);
rtnl_unlock();
- if (num_queues == 0) {
+ if (*num_queues == 0) {
dev_err(&info->netdev->dev, "no queues\n");
return -EINVAL;
}
@@ -1788,7 +1788,7 @@ static int talk_to_netback(struct xenbus_device *dev,
if (info->queues)
xennet_destroy_queues(info);
- err = xennet_create_queues(info, num_queues);
+ err = xennet_create_queues(info, &num_queues);
if (err < 0)
goto destroy_ring;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 net-next] RDS: fix rds-ping deadlock over TCP transport
From: Santosh Shilimkar
Date: Fri, 16 Oct 2015 22:13:21 -0400
> Sowmini found hang with rds-ping while testing RDS over TCP. Its
> a corner case and doesn't happen always. The issue is not reproducible
> with IB transport. Its clear from below dump why we see it with RDS TCP.
...
> This happens because rds_send_xmit() chain wants to take
> sock_lock which is already taken by tcp_v4_rcv() on its
> way to rds_tcp_data_ready(). Commit db6526dcb51b ("RDS: use
> rds_send_xmit() state instead of RDS_LL_SEND_FULL") which
> was trying to opportunistically finish the send request
> in same thread context.
>
> But because of above recursive lock hang with RDS TCP,
> the send work from rds_send_pong() needs to deferred to
> worker to avoid lock up. Given RDS ping is more of connectivity
> test than performance critical path, its should be ok even
> for transport like IB.
>
> Reported-by: Sowmini Varadhan
> Acked-by: Sowmini Varadhan
> Signed-off-by: Santosh Shilimkar
> Signed-off-by: Santosh Shilimkar
> ---
> v2: Dropped the confusing SEND_LL_FULL check from v1
Applied, thank you.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net] tunnels: Don't require remote endpoint or ID during creation.
From: Jesse Gross Date: Fri, 16 Oct 2015 16:36:00 -0700 > Before lightweight tunnels existed, it really didn't make sense to > create a tunnel that was not fully specified, such as without a > destination IP address - the resulting packets would go nowhere. > However, with lightweight tunnels, the opposite is true - it doesn't > make sense to require this information when it will be provided later > on by the route. This loosens the requirements for this information. > > An alternative would be to allow the relaxed version only when > COLLECT_METADATA is enabled. However, since there are several > variations on this theme (such as NBMA tunnels in GRE), just dropping > the restrictions seems the most consistent across tunnels and with > the existing configuration. > > CC: John Linville > Signed-off-by: Jesse Gross Applied, thanks Jesse. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] uapi: add mpls_iptunnel.h
From: Stephen Hemminger Date: Fri, 16 Oct 2015 16:12:34 -0700 > Add missing rule to export mpls iptunnel header needed by iproute2 > > Signed-off-by: Stephen Hemminger Applied, thanks Stephen. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3] bnxt_en: New Broadcom ethernet driver.
On Sat, 17 Oct 2015 00:21:44 -0400
Michael Chan wrote:
> +static inline u32 bnxt_tx_avail(struct bnxt *bp, struct bnxt_tx_ring_info
> *txr)
> +{
> + /* Tell compiler to fetch tx indices from memory. */
> + barrier();
Actually, you are telling compiler not to reorder. Which may not
be sufficient on some platforms.
> + return bp->tx_ring_size -
> + ((txr->tx_prod - txr->tx_cons) & bp->tx_ring_mask);
> +}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3] bnxt_en: New Broadcom ethernet driver.
On Sat, 17 Oct 2015 00:21:44 -0400
Michael Chan wrote:
> +static bool bnxt_vf_pciid(int idx)
> +{
> + if (idx == BCM57304_VF || idx == BCM57404_VF)
> + return true;
> + return false;
> +}
> +
I prefer just returning result of logical operation
rather than adding unnecessary if statement.
And never use (signed) int when unsigned is the real
data type. Also avoid any unnecessary expansion of 16 bit
value.
static bool bnxt_vf_pciid(u16 idx)
{
return (idx == BCM57304_VF || idx == BCM57404_VF);
}
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3] bnxt_en: New Broadcom ethernet driver.
On Sat, 17 Oct 2015 00:21:44 -0400
Michael Chan wrote:
> +/* indexed by enum above */
> +static struct {
> + char *name;
> +} board_info[] = {
> + { "Broadcom BCM57302 NetXtreme-C Single-port 10Gb/25Gb/40Gb/50Gb
> Ethernet" },
> + { "Broadcom BCM57304 NetXtreme-C Dual-port 10Gb/25Gb/40Gb/50Gb
> Ethernet" },
> + { "Broadcom BCM57404 NetXtreme-E Dual-port 10Gb/25Gb Ethernet" },
> + { "Broadcom BCM57406 NetXtreme-E Dual-port 10Gb Ethernet" },
> + { "Broadcom BCM57304 NetXtreme-C Ethernet Virtual Function" },
> + { "Broadcom BCM57404 NetXtreme-E Ethernet Virtual Function" },
> +};
Tables like this should be declared const.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next] tcp: do not set queue_mapping on SYNACK
From: Eric Dumazet
Date: Fri, 16 Oct 2015 13:00:01 -0700
> From: Eric Dumazet
>
> At the time of commit fff326990789 ("tcp: reflect SYN queue_mapping into
> SYNACK packets") we had little ways to cope with SYN floods.
>
> We no longer need to reflect incoming skb queue mappings, and instead
> can pick a TX queue based on cpu cooking the SYNACK, with normal XPS
> affinities.
>
> Note that all SYNACK retransmits were picking TX queue 0, this no longer
> is a win given that SYNACK rtx are now distributed on all cpus.
>
> Signed-off-by: Eric Dumazet
Applied, thanks Eric.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 net] openvswitch: Scrub skb between namespaces
From: Joe Stringer Date: Fri, 16 Oct 2015 11:08:18 -0700 > If OVS receives a packet from another namespace, then the packet should > be scrubbed. However, people have already begun to rely on the behaviour > that skb->mark is preserved across namespaces, so retain this one field. > > This is mainly to address information leakage between namespaces when > using OVS internal ports, but by placing it in ovs_vport_receive() it is > more generally applicable, meaning it should not be overlooked if other > port types are allowed to be moved into namespaces in future. > > Signed-off-by: Joe Stringer Applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pull request: bluetooth 2015-10-16
From: Johan Hedberg Date: Fri, 16 Oct 2015 17:29:00 +0300 > First of all, sorry for the late set of patches for the 4.3 cycle. We > just finished an intensive week of testing at the Bluetooth UnPlugFest > and discovered (and fixed) issues there. Unfortunately a few issues > affect 4.3-rc5 in a way that they break existing Bluetooth LE mouse and > keyboard support. > > The regressions result from supporting LE privacy in conjunction with > scanning for Resolvable Private Addresses before connecting. A feature > that has been tested heavily (including automated unit tests), but sadly > some regressions slipped in. The UnPlugFest with its multitude of test > platforms is a good battle testing ground for uncovering every corner > case. > > The patches in this pull request focus only on fixing the regressions in > 4.3-rc5. The patches look a bit larger since we also added comments in > the critical sections of the fixes to improve clarity. > > I would appreciate if we can get these regression fixes to Linus > quickly. Please let me know if there are any issues pulling. Thanks. Ok, pulled, thanks Johan. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] allow dctcp alpha to drop to zero
If alpha is strictly reduced by alpha >> dctcp_shift_g and if alpha is less
than 1 << dctcp_shift_g, then alpha may never reach zero. For example,
given shift_g=4 and alpha=15, alpha >> dctcp_shift_g yields 0 and alpha
remains 15. The effect isn't noticeable in this case below cwnd=137, but
could gradually drive uncongested flows with leftover alpha down to
cwnd=137. A larger dctcp_shift_g would have a greater effect.
This change causes alpha=15 to drop to 0 instead of being decrementing by 1
as it would when alpha=16. However, it requires one less conditional to
implement since it doesn't have to guard against subtracting 1 from 0U. A
decay of 15 is not unreasonable since an equal or greater amount occurs at
alpha >= 240.
Signed-off-by: Andrew G. Shewmaker
---
net/ipv4/tcp_dctcp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/tcp_dctcp.c b/net/ipv4/tcp_dctcp.c
index 7092a61..7e538f7 100644
--- a/net/ipv4/tcp_dctcp.c
+++ b/net/ipv4/tcp_dctcp.c
@@ -209,7 +209,7 @@ static void dctcp_update_alpha(struct sock *sk, u32 flags)
/* alpha = (1 - g) * alpha + g * F */
- alpha -= alpha >> dctcp_shift_g;
+ alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);
if (bytes_ecn) {
/* If dctcp_shift_g == 1, a 32bit value would overflow
* after 8 Mbytes.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH iproute2] bridge: add calls to fflush in fdb and mdb print functions
On Thu, 15 Oct 2015 14:53:17 -0700 Roopa Prabhu wrote: > From: Wilson Kok > > This patch adds fflush in fdb and mdb print functions > > Signed-off-by: Wilson Kok > Signed-off-by: Roopa Prabhu Applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ip-rule: neither prohibit nor reject or unreachable flags exist
On Thu, 15 Oct 2015 20:32:17 + Phil Sutter wrote: > This has been inconsistent since the beginning of Git and seems to be > merely a documentation leftover, therefore just remove it from help > output and man page. > > Signed-off-by: Phil Sutter Applied. > -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH iproute2] ss: return -1 if an unrecognized option was given
On Thu, 15 Oct 2015 21:01:16 +0200 Phil Sutter wrote: > When getopt_long encounters an option which has not been registered, it > returns '?'. React upon that and call usage() instead of help() so ss > returns with a non-zero exit status. > > Signed-off-by: Phil Sutter Applied -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/7] tcp: track min RTT using windowed min-filter
On Wed, Oct 14, 2015 at 02:28:00AM -0700, Andrew Shewmaker wrote:
> On Fri, Oct 16, 2015 at 09:57:42PM -0700, Yuchung Cheng wrote:
> ...
> > diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> > index 86a7eda..90edef5 100644
> > --- a/include/linux/tcp.h
> > +++ b/include/linux/tcp.h
> > @@ -217,6 +217,9 @@ struct tcp_sock {
> > u32 mdev_max_us;/* maximal mdev for the last rtt period */
> > u32 rttvar_us; /* smoothed mdev_max*/
> > u32 rtt_seq;/* sequence number to update rttvar */
> > + struct rtt_meas {
> > + u32 rtt, ts;/* RTT in usec and sampling time in jiffies. */
> > + } rtt_min[3];
>
> First, thanks for all the work in this patch series. In particular,
> applying Kern's check to ca_seq_rtt_us should fix some bad behavior
> I've observed recently.
I'd have to run more tests to be sure, but net-next with this patch series
significantly improves upon the poor behavior I was seeing where randomly
dropped packets greatly limited the usefulness of RTTs as a signal of
congestion. I still see some measurements that exceed the amount of delay
possible from queue buildup, but fewer than before.
Thanks!
-Andrew
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: [Bug 106171] New: Regression causes "ip" command to crash, leaving the user without any networking
Freescale driver bug. Begin forwarded message: Date: Mon, 19 Oct 2015 02:14:45 + From: "bugzilla-dae...@bugzilla.kernel.org" To: "shemmin...@linux-foundation.org" Subject: [Bug 106171] New: Regression causes "ip" command to crash, leaving the user without any networking https://bugzilla.kernel.org/show_bug.cgi?id=106171 Bug ID: 106171 Summary: Regression causes "ip" command to crash, leaving the user without any networking Product: Networking Version: 2.5 Kernel Version: 4.2.0 Hardware: ARM OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: IPV4 Assignee: shemmin...@linux-foundation.org Reporter: justinc...@yopmail.com Regression: No Created attachment 190481 --> https://bugzilla.kernel.org/attachment.cgi?id=190481&action=edit Process ip (pid: 252, stack limit = 0xed7a4220) Stack: (0xed7a5a58 to 0xed7a6000) Between kernel version 4.1.7 and 4.2.0 something caused networking to be left non-functioning. I can confirm the bug is still in mainline 4.2.3. Attached is the stack trace showing up during boot of the device with 4.2.3 kernel. I have since regressed to 4.1.x and networking works fine again. I had one other user confirm this bug via Freenode IRC. -- You are receiving this mail because: You are the assignee for the bug. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] bpf: control the trace data output on current cpu when perf sampling
于 2015/10/17 6:06, Alexei Starovoitov 写道:
> On 10/16/15 12:42 AM, Kaixu Xia wrote:
>> This patch adds the flag dump_enable to control the trace data
>> output process when perf sampling. By setting this flag and
>> integrating with ebpf, we can control the data output process and
>> get the samples we are most interested in.
>>
>> The bpf helper bpf_perf_event_dump_control() can control the
>> perf_event on current cpu.
>>
>> Signed-off-by: Kaixu Xia
>> ---
>> include/linux/perf_event.h | 1 +
>> include/uapi/linux/bpf.h| 5 +
>> include/uapi/linux/perf_event.h | 3 ++-
>> kernel/bpf/verifier.c | 3 ++-
>> kernel/events/core.c| 13
>> kernel/trace/bpf_trace.c| 44
>> +
>> 6 files changed, 67 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 092a0e8..2af527e 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -472,6 +472,7 @@ struct perf_event {
>> struct irq_workpending;
>>
>> atomic_tevent_limit;
>> +atomic_tdump_enable;
>
> The naming is the hardest...
> How about calling it 'soft_enable' instead?
>
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -287,6 +287,11 @@ enum bpf_func_id {
>>* Return: realm if != 0
>>*/
>> BPF_FUNC_get_route_realm,
>> +
>> +/**
>> + * u64 bpf_perf_event_dump_control(&map, index, flag)
>> + */
>> +BPF_FUNC_perf_event_dump_control,
>
> and this one is too long.
> May be bpf_perf_event_control() ?
>
> Daniel, any thoughts on naming?
>
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -331,7 +331,8 @@ struct perf_event_attr {
>> comm_exec : 1, /* flag comm events that are due to
>> an exec */
>> use_clockid: 1, /* use @clockid for time fields */
>> context_switch : 1, /* context switch data */
>> -__reserved_1 : 37;
>> +dump_enable: 1, /* don't output data on samples */
>
> either comment or name is wrong.
> how about calling this one 'soft_disable',
> since you want zero to be default and the event should be on.
>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index b11756f..74a16af 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -6337,6 +6337,9 @@ static int __perf_event_overflow(struct perf_event
>> *event,
>> irq_work_queue(&event->pending);
>> }
>>
>> +if (!atomic_read(&event->dump_enable))
>> +return ret;
>
> I'm not an expert in this piece of perf, but should it be 'return 0'
> instead ?
> and may be moved to is_sampling_event() check?
> Also please add unlikely().
The is_sampling_event() is checked in many other kernel places, not only in
perf events interrupt overflow handle. I'm not sure it is fine if we move it
to there. In addition, I think hwc->interrupts++ should be done in
__perf_event_overflow() before event->soft_enable is checked.
>
>> +static void perf_event_check_dump_flag(struct perf_event *event)
>> +{
>> +if (event->attr.dump_enable == 1)
>> +atomic_set(&event->dump_enable, 1);
>> +else
>> +atomic_set(&event->dump_enable, 0);
>
> that looks like it breaks perf, since default for bits is zero
> and all events will be soft-disabled?
> How did you test it?
> Please add a test to samples/bpf/ for this feature.
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] staging: rtl8712: Add device ID for Sitecom WLA2100
This adds the USB ID for the Sitecom WLA2100. The Windows 10 inf file
was checked to verify that the addition is correct.
Reported-by: Frans van de Wiel
Signed-off-by: Larry Finger
Cc: Frans van de Wiel
Cc: Stable [All stable versions]
---
drivers/staging/rtl8712/usb_intf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/rtl8712/usb_intf.c
b/drivers/staging/rtl8712/usb_intf.c
index f8b5b33..943a0e2 100644
--- a/drivers/staging/rtl8712/usb_intf.c
+++ b/drivers/staging/rtl8712/usb_intf.c
@@ -144,6 +144,7 @@ static struct usb_device_id rtl871x_usb_id_tbl[] = {
{USB_DEVICE(0x0DF6, 0x0058)},
{USB_DEVICE(0x0DF6, 0x0049)},
{USB_DEVICE(0x0DF6, 0x004C)},
+ {USB_DEVICE(0x0DF6, 0x006C)},
{USB_DEVICE(0x0DF6, 0x0064)},
/* Skyworth */
{USB_DEVICE(0x14b2, 0x3300)},
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/7] tcp: track min RTT using windowed min-filter
On Sun, Oct 18, 2015 at 10:33:41AM -0400, Neal Cardwell wrote: > On Wed, Oct 14, 2015 at 5:28 AM, Andrew Shewmaker wrote: > >> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c > >> index 38743e5..e177386 100644 > >> --- a/net/ipv4/tcp_input.c > >> +++ b/net/ipv4/tcp_input.c > > ... > >> @@ -2961,7 +3028,7 @@ void tcp_synack_rtt_meas(struct sock *sk, struct > >> request_sock *req) > >> rtt_us = skb_mstamp_us_delta(&now, > >> &tcp_rsk(req)->snt_synack); > >> } > >> > >> - tcp_ack_update_rtt(sk, FLAG_SYN_ACKED, rtt_us, -1L); > >> + tcp_ack_update_rtt(sk, FLAG_SYN_ACKED, rtt_us, -1L, rtt_us); > >> } > > > > This didn't apply to net-next for me. I see seq_rtt_us instead of > > rtt_us and a check on the existence of tp->srtt_us. Maybe I've > > misapplied the patch? > > This patch series applies cleanly for me against David Miller's > net-next at SHA1 4be3158 (from Friday Oct 16). (Using "git am" on the > mbox patches from http://patchwork.ozlabs.org/project/netdev/list/ > ...) > > On top of what SHA1 are you applying the series? Doesn't matter which one ... it was the wrong one :) I'd executed a git pull before applying the patch set, but I ended up having to force it. Once I did, it applied cleanly. Apologies for the false alarm, Andrew -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] ARCNET: features and fixes
From: Michael Grzeschik Date: Fri, 16 Oct 2015 13:00:54 +0200 > This series includes some small fixes. The main changes are the correct > xceiver handling (enable/disable) of the com20020 cards. The driver now > handles > link status change detection. The EAE PCI-ARCNET cards now make use of the > rotary encoded subdevice indexing and got support for led triggers on transmit > and reconnection events. If you mix features and bug fixes, then it's ambiguous which tree these changes should go into. If it's just fixes, then it's clearly 'net', But once you add feature changes and cleanups, then 'net' is not appropriate. Please split this up properly and submit things targetting the correct GIT tree. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/2] bpf: control the trace data output on current cpu when perf sampling
于 2015/10/17 6:06, Alexei Starovoitov 写道:
> On 10/16/15 12:42 AM, Kaixu Xia wrote:
>> This patch adds the flag dump_enable to control the trace data
>> output process when perf sampling. By setting this flag and
>> integrating with ebpf, we can control the data output process and
>> get the samples we are most interested in.
>>
>> The bpf helper bpf_perf_event_dump_control() can control the
>> perf_event on current cpu.
>>
>> Signed-off-by: Kaixu Xia
>> ---
>> include/linux/perf_event.h | 1 +
>> include/uapi/linux/bpf.h| 5 +
>> include/uapi/linux/perf_event.h | 3 ++-
>> kernel/bpf/verifier.c | 3 ++-
>> kernel/events/core.c| 13
>> kernel/trace/bpf_trace.c| 44
>> +
>> 6 files changed, 67 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
>> index 092a0e8..2af527e 100644
>> --- a/include/linux/perf_event.h
>> +++ b/include/linux/perf_event.h
>> @@ -472,6 +472,7 @@ struct perf_event {
>> struct irq_workpending;
>>
>> atomic_tevent_limit;
>> +atomic_tdump_enable;
>
> The naming is the hardest...
> How about calling it 'soft_enable' instead?
>
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -287,6 +287,11 @@ enum bpf_func_id {
>>* Return: realm if != 0
>>*/
>> BPF_FUNC_get_route_realm,
>> +
>> +/**
>> + * u64 bpf_perf_event_dump_control(&map, index, flag)
>> + */
>> +BPF_FUNC_perf_event_dump_control,
>
> and this one is too long.
> May be bpf_perf_event_control() ?
>
> Daniel, any thoughts on naming?
>
>> --- a/include/uapi/linux/perf_event.h
>> +++ b/include/uapi/linux/perf_event.h
>> @@ -331,7 +331,8 @@ struct perf_event_attr {
>> comm_exec : 1, /* flag comm events that are due to
>> an exec */
>> use_clockid: 1, /* use @clockid for time fields */
>> context_switch : 1, /* context switch data */
>> -__reserved_1 : 37;
>> +dump_enable: 1, /* don't output data on samples */
>
> either comment or name is wrong.
> how about calling this one 'soft_disable',
> since you want zero to be default and the event should be on.
>
>> diff --git a/kernel/events/core.c b/kernel/events/core.c
>> index b11756f..74a16af 100644
>> --- a/kernel/events/core.c
>> +++ b/kernel/events/core.c
>> @@ -6337,6 +6337,9 @@ static int __perf_event_overflow(struct perf_event
>> *event,
>> irq_work_queue(&event->pending);
>> }
>>
>> +if (!atomic_read(&event->dump_enable))
>> +return ret;
>
> I'm not an expert in this piece of perf, but should it be 'return 0'
> instead ?
> and may be moved to is_sampling_event() check?
> Also please add unlikely().
>
>> +static void perf_event_check_dump_flag(struct perf_event *event)
>> +{
>> +if (event->attr.dump_enable == 1)it
>> +atomic_set(&event->dump_enable, 1);
>> +else
>> +atomic_set(&event->dump_enable, 0);
>
> that looks like it breaks perf, since default for bits is zero
> and all events will be soft-disabled?
> How did you test it?
> Please add a test to samples/bpf/ for this feature.
It is really hard that adding a test to samples/bpf/. We need to implement most
of
'perf record/report' commands from tools/perf/, like mmap(), dump trace, etc.
Only
the perf_event_open syscall is really not enough.
Actually, this patch set is only the kernel space side, and it still needs the
perf
user space side, you can find the necessary patches in Wang Nan's git tree[1].
Based on Wang Nan's git tree, we can config BPF maps through perf cmdline.
We also need to confing attr->soft_disable in perf user side based on tree[1].
so
it was not included in this patchset. I will send out the perf userspace part
after
this patch set is applied.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/pi3orama/linux.git perf/ebpf
>
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: hix5hd2_gmac: avoid integer overload warning
From: Arnd Bergmann Date: Fri, 16 Oct 2015 12:00:51 +0200 > BITS_RX_EN is an 'unsigned long' constant, so the ones complement of that > has bits set that do not fit into a 32-bit variable on 64-bit architectures, > which causes a harmless gcc warning: > > drivers/net/ethernet/hisilicon/hix5hd2_gmac.c: In function > 'hix5hd2_port_disable': > drivers/net/ethernet/hisilicon/hix5hd2_gmac.c:374:2: warning: large integer > implicitly truncated to unsigned type [-Woverflow] > writel_relaxed(~(BITS_RX_EN | BITS_TX_EN), priv->base + PORT_EN); > > This adds a cast to (u32) to tell gcc that the code is indeed fine. > > Signed-off-by: Arnd Bergmann Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: hisilicon: add OF dependency
From: Arnd Bergmann Date: Fri, 16 Oct 2015 11:33:49 +0200 > The HNS MDIO driver fails to build on older ARM machines that are not > yet converted to CONFIG_OF: > > drivers/net/ethernet/hisilicon/hns_mdio.c: In function 'hns_mdio_bus_name': > drivers/net/ethernet/hisilicon/hns_mdio.c:405:14: error: 'OF_BAD_ADDR' > undeclared (first use in this function) > u64 taddr = OF_BAD_ADDR; > ^ > drivers/net/ethernet/hisilicon/hns_mdio.c:405:14: note: each undeclared > identifier is reported only once for each function it appears in > drivers/net/ethernet/hisilicon/hns_mdio.c:409:11: error: implicit declaration > of function 'of_translate_address' [-Werror=implicit-function-declaration] >taddr = of_translate_address(np, addr); >^ > > This clarifies the dependency to ensure we don't attempt to build these > drivers without CONFIG_OF, but also adds a COMPILE_TEST alternative to > give us better build coverage testing. > > Build-tested on x86 as well to ensure this actually works. > > Signed-off-by: Arnd Bergmann Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: hisilicon: include linux/vmalloc.h in dsaf
From: Arnd Bergmann Date: Fri, 16 Oct 2015 11:30:56 +0200 > Some configurations fail to build the hns dsaf code because of > a missing header file: > > ethernet/hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_init': > ethernet/hisilicon/hns/hns_dsaf_main.c:1096:2: error: implicit declaration of > function 'vzalloc' [-Werror=implicit-function-declaration] > priv->soft_mac_tbl = vzalloc(sizeof(*priv->soft_mac_tbl) > > This adds the correct #include. > > Signed-off-by: Arnd Bergmann Applied, thank you. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 0/2] net: hns: fixes two bugs in hns driver
From: yankejian Date: Fri, 16 Oct 2015 17:03:18 +0800 > This patchset fixes two bugs in hns driver. > - fixes timeout when received pause frame from the connective ports > - should be set by using ethtool -s when the devices are link down Series applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3 0/2] net: hisilicon fix some bugs in HNS drivers
From: huangdaode Date: Fri, 16 Oct 2015 11:54:15 +0800 > This patchset fixes the two bugs in HNS driver, one is remove the hnae sysfs > interface > according to the review comments from Arnd Bergmann , another > is fixing the wrong mac_id judgement bug which is found during internal tests. Series applied, tanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 0/4] BPF updates
From: Daniel Borkmann Date: Fri, 16 Oct 2015 03:09:21 +0200 > This set adds support for persistent maps/progs. Please see > individual patches for further details. > > A man-page update to bpf(2) will be sent afterwards, also a > iproute2 patch for support in tc. > > Thanks! It seems like the design here is still a little bit in flux, so I'm marking this as "changes requested" in patchwork. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v3 0/2] net: hisilicon fix some bugs in HNS drivers
On 2015/10/16 17:30, Arnd Bergmann wrote: On Friday 16 October 2015 11:54:15 huangdaode wrote: This patchset fixes the two bugs in HNS driver, one is remove the hnae sysfs interface according to the review comments from Arnd Bergmann , another is fixing the wrong mac_id judgement bug which is found during internal tests. change log: v3: remove the hnae sysfs interface. v2: 1) remove first bug fix, which is fixed in another patch submitted by Arnd Bergmann 2) change the code sytyle according to Joe. v1: initial version. huangdaode (2): net: hisilicon rm hnae sysfs interface net: hisilicon fix a bug on Hisilicon Network Subsystem drivers/net/ethernet/hisilicon/hns/hnae.c | 47 --- drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 2 +- 2 files changed, 1 insertion(+), 48 deletions(-) I found two more bugs in build testing, will follow up with patches in this thread Arnd. . Hi Arnd, thanks for your comments. i see you adding three patches in this thread to fix related bugs. should I need to re-send a new version patch which contains your other three patches or just wait for David Miller to merge this thread? thanks Daode Huang . -- Best Regards Daode Huang -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] xen-netback: correctly check failed allocation
From: Insu Yun Date: Thu, 15 Oct 2015 18:02:28 + > Since vzalloc can be failed in memory pressure, > writes -ENOMEM to xenstore to indicate error. > > Signed-off-by: Insu Yun Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: asix: add support for the Billionton GUSB2AM-1G-B USB adapter
From: changch...@gmail.com Date: Fri, 16 Oct 2015 02:00:21 +0800 > From: Chia-Sheng Chang > > Just another AX88178-based 10/100/1000 USB-to-Ethernet dongle. This one > shows up in lsusb as: "ID 08dd:0114 Billionton Systems, Inc". > > Signed-off-by: Chia-Sheng Chang > Cc: "David S. Miller" Applied. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] net: phy: bcm-phy-lib: Fix module license issue
From: Arun Parameswaran
Date: Thu, 15 Oct 2015 10:37:13 -0700
> The 'bcm-phy-lib.c', added as a part of the commit
> "net: phy: Add Broadcom phy library for common interfaces"
> was missing the module license. This was causing an issue
> when the library is built as a module; "module license
> 'unspecified' taints kernel".
>
> This patch fixes the issue by adding the module license,
> author and description to the bcm-phy-lib.c file.
>
> Fixes: a1cba5613edf5 ("net: phy: Add Broadcom phy library for
> common interfaces")
> Signed-off-by: Arun Parameswaran
Applied.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2] netlink: Trim skb to alloc size to avoid MSG_TRUNC
From: Ronen Arad Date: Thu, 15 Oct 2015 01:55:17 -0700 > netlink_dump() allocates skb based on the calculated min_dump_alloc or > a per socket max_recvmsg_len. > min_alloc_size is maximum space required for any single netdev > attributes as calculated by rtnl_calcit(). > max_recvmsg_len tracks the user provided buffer to netlink_recvmsg. > It is capped at 16KiB. > The intention is to avoid small allocations and to minimize the number > of calls required to obtain dump information for all net devices. > > netlink_dump packs as many small messages as could fit within an skb > that was sized for the largest single netdev information. The actual > space available within an skb is larger than what is requested. It could > be much larger and up to near 2x with align to next power of 2 approach. > > Allowing netlink_dump to use all the space available within the > allocated skb increases the buffer size a user has to provide to avoid > truncaion (i.e. MSG_TRUNG flag set). > > It was observed that with many VLANs configured on at least one netdev, > a larger buffer of near 64KiB was necessary to avoid "Message truncated" > error in "ip link" or "bridge [-c[ompressvlans]] vlan show" when > min_alloc_size was only little over 32KiB. > > This patch trims skb to allocated size in order to allow the user to > avoid truncation with more reasonable buffer size. > > Signed-off-by: Ronen Arad Getting spurious MSG_TRUNC is surely a bug, so I am going to apply this to 'net' as it is a genuine bug fix. Thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH net-next 0/9] netlink: strict attribute checking option
From: David Ahern Date: Fri, 16 Oct 2015 09:57:33 -0600 > On 10/16/15 2:02 AM, Jiri Benc wrote: >> On Fri, 16 Oct 2015 01:06:44 -0700 (PDT), David Miller wrote: >>> No, it's definitely not OK, because lwtunnel support exists in >>> Linus's tree. >>> >>> And tools should be able to work on all kernels where lwtunnel support >>> is available. >> >> You can consider the lwtunnels feature as not finished in the current >> Linus's tree. It works, it won't change (thus anything using it in its >> current form will continue to work in all the future kernels), but >> mainstream tools won't make use of it until a kernel version later >> which will get some additional support. >> >> I don't think it's much of a problem and I don't think it is the first >> time this would happen. >> >> I'm afraid I don't have any solution that could do better. > > What about a flag that requests the version from the relevant kernel > subsystem? The whole point of having an easily extensible protocol like netlink with attributes and whatnot was to avoid messy schemes like versioning. The big mistake was ignoring unknown attributes. I mean seriously, think about it, what if the new attribute specified by the user was some security setting or something? I'm sure even more dangerous examples can be imagined. I'm beginning to wonder if we can just change this unilaterally to not ignore unrecognized attributes. I am increasingly certain that things that would "break" we wouldn't want to succeed anyways. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next v2] ipconfig: send Client-identifier in DHCP requests
From: roy.qing...@gmail.com Date: Thu, 15 Oct 2015 16:54:36 +0800 > From: Li RongQing > > A dhcp server may provide parameters to a client from a pool of IP > addresses and using a shared rootfs, or provide a specific set of > parameters for a specific client, usually using the MAC address to > identify each client individually. The dhcp protocol also specifies > a client-id field which can be used to determine the correct > parameters to supply when no MAC address is available. There is > currently no way to tell the kernel to supply a specific client-id, > only the userspace dhcp clients support this feature, but this can > not be used when the network is needed before userspace is available > such as when the root filesystem is on NFS. > > This patch is to be able to do something like "ip=dhcp,client_id_type, > client_id_value", as a kernel parameter to enable the kernel to > identify itself to the server. > > Signed-off-by: Li RongQing Looks good, applied, thanks. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] vsock: fix missing cleanup when misc_register failed
I'm sorry too, fell free to ignore my patch, Thanks. 2015-10-19 9:50 GMT+08:00 David Miller : > From: Gao feng > Date: Sun, 18 Oct 2015 23:35:56 +0800 > >> reset transport and unlock if misc_register failed. >> >> Signed-off-by: Gao feng > > It's extremely disappointing that it took you three revisions > just to put together a submission that actually compiles. > > That shows me that you put a very low amount of care into your > submission, and if you don't care about your change why should I? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] RDS: convert bind hash table to re-sizable hashtable
From: Santosh Shilimkar Date: Wed, 14 Oct 2015 14:15:31 -0700 > From: Santosh Shilimkar > > To further improve the RDS connection scalabilty on massive systems > where number of sockets grows into tens of thousands of sockets, there > is a need of larger bind hashtable. Pre-allocated 8K or 16K table is > not very flexible in terms of memory utilisation. The rhashtable > infrastructure gives us the flexibility to grow the hashtbable based > on use and also comes up with inbuilt efficient bucket(chain) handling. > > Cc: David Laight > Cc: David Miller > Signed-off-by: Santosh Shilimkar This looks fine as far as I can tell. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] vsock: fix missing cleanup when misc_register failed
From: Gao feng Date: Sun, 18 Oct 2015 23:35:56 +0800 > reset transport and unlock if misc_register failed. > > Signed-off-by: Gao feng It's extremely disappointing that it took you three revisions just to put together a submission that actually compiles. That shows me that you put a very low amount of care into your submission, and if you don't care about your change why should I? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v4 1/2] mpls: multipath route support
From: Roopa Prabhu
This patch adds support for MPLS multipath routes.
Includes following changes to support multipath:
- splits struct mpls_route into 'struct mpls_route + struct mpls_nh'
- 'struct mpls_nh' represents a mpls nexthop label forwarding entry
- moves mpls route and nexthop structures into internal.h
- A mpls_route can point to multiple mpls_nh structs
- the nexthops are maintained as a array (similar to ipv4 fib)
- In the process of restructuring, this patch also consistently changes
all labels to u8
- Adds support to parse/fill RTA_MULTIPATH netlink attribute for
multipath routes similar to ipv4/v6 fib
- In this patch, the multipath route nexthop selection algorithm
simply returns the first nexthop. It is replaced by a
hash based algorithm from Robert Shearman in the next patch
- mpls_route_update cleanup: remove 'dev' handling in mpls_route_update.
mpls_route_update though implemented to update based on dev, it was
never used that way. And the dev handling gets tricky with multiple nexthops.
Cannot match against any single nexthops dev. So, this patch removes the unused
'dev' handling in mpls_route_update.
Example:
$ip -f mpls route add 100 nexthop as 200 via inet 10.1.1.2 dev swp1 \
nexthop as 700 via inet 10.1.1.6 dev swp2 \
nexthop as 800 via inet 40.1.1.2 dev swp3
$ip -f mpls route show
100
nexthop as to 200 via inet 10.1.1.2 dev swp1
nexthop as to 700 via inet 10.1.1.6 dev swp2
nexthop as to 800 via inet 40.1.1.2 dev swp3
Signed-off-by: Roopa Prabhu
---
include/net/mpls_iptunnel.h | 2 +-
net/mpls/af_mpls.c | 498 +++-
net/mpls/internal.h | 52 -
3 files changed, 403 insertions(+), 149 deletions(-)
diff --git a/include/net/mpls_iptunnel.h b/include/net/mpls_iptunnel.h
index 4757997..179253f 100644
--- a/include/net/mpls_iptunnel.h
+++ b/include/net/mpls_iptunnel.h
@@ -18,7 +18,7 @@
struct mpls_iptunnel_encap {
u32 label[MAX_NEW_LABELS];
- u32 labels;
+ u8 labels;
};
static inline struct mpls_iptunnel_encap *mpls_lwtunnel_encap(struct
lwtunnel_state *lwtstate)
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index bb185a2..ebefdd4 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -19,37 +19,9 @@
#include
#include
#endif
+#include
#include "internal.h"
-#define LABEL_NOT_SPECIFIED (1<<20)
-#define MAX_NEW_LABELS 2
-
-/* This maximum ha length copied from the definition of struct neighbour */
-#define MAX_VIA_ALEN (ALIGN(MAX_ADDR_LEN, sizeof(unsigned long)))
-
-enum mpls_payload_type {
- MPT_UNSPEC, /* IPv4 or IPv6 */
- MPT_IPV4 = 4,
- MPT_IPV6 = 6,
-
- /* Other types not implemented:
-* - Pseudo-wire with or without control word (RFC4385)
-* - GAL (RFC5586)
-*/
-};
-
-struct mpls_route { /* next hop label forwarding entry */
- struct net_device __rcu *rt_dev;
- struct rcu_head rt_rcu;
- u32 rt_label[MAX_NEW_LABELS];
- u8 rt_protocol; /* routing protocol that set this
entry */
- u8 rt_payload_type;
- u8 rt_labels;
- u8 rt_via_alen;
- u8 rt_via_table;
- u8 rt_via[0];
-};
-
static int zero = 0;
static int label_limit = (1 << 20) - 1;
@@ -80,10 +52,10 @@ bool mpls_output_possible(const struct net_device *dev)
}
EXPORT_SYMBOL_GPL(mpls_output_possible);
-static unsigned int mpls_rt_header_size(const struct mpls_route *rt)
+static unsigned int mpls_nh_header_size(const struct mpls_nh *nh)
{
/* The size of the layer 2.5 labels to be added for this route */
- return rt->rt_labels * sizeof(struct mpls_shim_hdr);
+ return nh->nh_labels * sizeof(struct mpls_shim_hdr);
}
unsigned int mpls_dev_mtu(const struct net_device *dev)
@@ -105,6 +77,12 @@ bool mpls_pkt_too_big(const struct sk_buff *skb, unsigned
int mtu)
}
EXPORT_SYMBOL_GPL(mpls_pkt_too_big);
+static struct mpls_nh *mpls_select_multipath(struct mpls_route *rt)
+{
+ /* assume single nexthop for now */
+ return &rt->rt_nh[0];
+}
+
static bool mpls_egress(struct mpls_route *rt, struct sk_buff *skb,
struct mpls_entry_decoded dec)
{
@@ -159,6 +137,7 @@ static int mpls_forward(struct sk_buff *skb, struct
net_device *dev,
struct net *net = dev_net(dev);
struct mpls_shim_hdr *hdr;
struct mpls_route *rt;
+ struct mpls_nh *nh;
struct mpls_entry_decoded dec;
struct net_device *out_dev;
struct mpls_dev *mdev;
@@ -166,6 +145,7 @@ static int mpls_forward(struct sk_buff *skb, struct
net_device *dev,
unsigned int new_header_size;
unsigned int mtu;
int err;
+ int nhidx;
/* Careful this entire function runs inside of an rcu critical se
[PATCH net-next v4 0/2] mpls: multipath support
From: Roopa Prabhu This patch adds support for MPLS multipath routes. Includes following changes to support multipath: - splits struct mpls_route into 'struct mpls_route + struct mpls_nh'. - struct mpls_nh represents a mpls nexthop label forwarding entry - Adds support to parse/fill RTA_MULTIPATH netlink attribute for multipath routes similar to ipv4/v6 fib - In the process of restructuring, this patch also consistently changes all labels to u8 $ip -f mpls route add 100 nexthop as 200 via inet 10.1.1.2 dev swp1 \ nexthop as 700 via inet 10.1.1.6 dev swp2 \ nexthop as 800 via inet 40.1.1.2 dev swp3 $ip -f mpls route show 100 nexthop as to 200 via inet 10.1.1.2 dev swp1 nexthop as to 700 via inet 10.1.1.6 dev swp2 nexthop as to 800 via inet 40.1.1.2 dev swp3 Roopa Prabhu (1): mpls: multipath support Robert Shearman (1): mpls: flow-based multipath selection Signed-off-by: Roopa Prabhu v2: - Incorporate some feedback from Robert: use dynamic allocation (list) instead of static allocation for nexthops v3: - Move back to arrays (same as v1), also suggested by Eric Biederman v4: - address a few comments from Eric Biederman Plan to address the following pending comments in incremental patches after this infrastructure changes go in. - Move VIA size to 16 bytes - use ipv6 flow label in ecmp calculations - dead route handling during multipath route selection (I had planned this in an incremental patch initially). include/net/mpls_iptunnel.h | 2 +- net/mpls/af_mpls.c | 668 ++-- net/mpls/internal.h | 57 +++- 3 files changed, 572 insertions(+), 155 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-next v4 2/2] mpls: flow-based multipath selection
From: Robert Shearman
Change the selection of a multipath route to use a flow-based
hash. This more suitable for traffic sensitive to reordering within a
flow (e.g. TCP, L2VPN) and whilst still allowing a good distribution
of traffic given enough flows.
Selection of the path for a multipath route is done using a hash of:
1. Label stack up to MAX_MP_SELECT_LABELS labels or up to and
including entropy label, whichever is first.
2. 3-tuple of (L3 src, L3 dst, proto) from IPv4/IPv6 header in MPLS
payload, if present.
Naturally, a 5-tuple hash using L4 information in addition would be
possible and be better in some scenarios, but there is a tradeoff
between looking deeper into the packet to achieve good distribution,
and packet forwarding performance, and I have erred on the side of the
latter as the default.
Signed-off-by: Robert Shearman
---
net/mpls/af_mpls.c | 88 ++
1 file changed, 83 insertions(+), 5 deletions(-)
diff --git a/net/mpls/af_mpls.c b/net/mpls/af_mpls.c
index ebefdd4..79154f7 100644
--- a/net/mpls/af_mpls.c
+++ b/net/mpls/af_mpls.c
@@ -22,6 +22,11 @@
#include
#include "internal.h"
+/* Maximum number of labels to look ahead at when selecting a path of
+ * a multipath route
+ */
+#define MAX_MP_SELECT_LABELS 4
+
static int zero = 0;
static int label_limit = (1 << 20) - 1;
@@ -77,10 +82,78 @@ bool mpls_pkt_too_big(const struct sk_buff *skb, unsigned
int mtu)
}
EXPORT_SYMBOL_GPL(mpls_pkt_too_big);
-static struct mpls_nh *mpls_select_multipath(struct mpls_route *rt)
+static struct mpls_nh *mpls_select_multipath(struct mpls_route *rt,
+struct sk_buff *skb, bool bos)
{
- /* assume single nexthop for now */
- return &rt->rt_nh[0];
+ struct mpls_entry_decoded dec;
+ struct mpls_shim_hdr *hdr;
+ bool eli_seen = false;
+ int label_index;
+ int nh_index = 0;
+ u32 hash = 0;
+
+ /* No need to look further into packet if there's only
+* one path
+*/
+ if (rt->rt_nhn == 1)
+ goto out;
+
+ for (label_index = 0; label_index < MAX_MP_SELECT_LABELS && !bos;
+label_index++) {
+ if (!pskb_may_pull(skb, sizeof(*hdr) * label_index))
+ break;
+
+ /* Read and decode the current label */
+ hdr = mpls_hdr(skb) + label_index;
+ dec = mpls_entry_decode(hdr);
+
+ /* RFC6790 - reserved labels MUST NOT be used as keys
+* for the load-balancing function
+*/
+ if (likely(dec.label >= MPLS_LABEL_FIRST_UNRESERVED)) {
+ hash = jhash_1word(dec.label, hash);
+
+ /* The entropy label follows the entropy label
+* indicator, so this means that the entropy
+* label was just added to the hash - no need to
+* go any deeper either in the label stack or in the
+* payload
+*/
+ if (eli_seen)
+ break;
+ } else if (dec.label == MPLS_LABEL_ENTROPY) {
+ eli_seen = true;
+ }
+
+ bos = dec.bos;
+ if (bos && pskb_may_pull(skb, sizeof(*hdr) * label_index +
+sizeof(struct iphdr))) {
+ const struct iphdr *v4hdr;
+
+ v4hdr = (const struct iphdr *)(mpls_hdr(skb) +
+ label_index);
+ if (v4hdr->version == 4) {
+ hash = jhash_3words(ntohl(v4hdr->saddr),
+ ntohl(v4hdr->daddr),
+ v4hdr->protocol, hash);
+ } else if (v4hdr->version == 6 &&
+ pskb_may_pull(skb, sizeof(*hdr) * label_index +
+ sizeof(struct ipv6hdr))) {
+ const struct ipv6hdr *v6hdr;
+
+ v6hdr = (const struct ipv6hdr *)(mpls_hdr(skb) +
+ label_index);
+
+ hash = __ipv6_addr_jhash(&v6hdr->saddr, hash);
+ hash = __ipv6_addr_jhash(&v6hdr->daddr, hash);
+ hash = jhash_1word(v6hdr->nexthdr, hash);
+ }
+ }
+ }
+
+ nh_index = hash % rt->rt_nhn;
+out:
+ return &rt->rt_nh[nh_index];
}
static bool mpls_egress(struct mpls_route *rt, struct sk_buff *skb,
@@ -145,7 +218,6 @@ static int mpls_forward(struct sk_buff *skb, struct
net_device *dev,
unsigned int new_header_size;
unsigned int mtu;
Darlehen anbieten
Guten Tag, Wir MASTHAVEN Darlehensfinanzierung geben, Kredite per Post Anzeige. Wir bieten verschiedene Arten von Krediten (kurz- und langfristige Darlehen, persönliche Darlehen, Kredite an Unternehmen etc.) um 3% Zins. Wir geben Kredite an Menschen in Not nicht unabhängig von ihrem Standort, Geschlecht, Familienstand, Bildung, Job-Status, sondern muss eine rechtliche Mittel der Rückzahlung haben. Unsere Darlehen bewegen sich zwischen 5.000,00 zu 10.000.000,00 US-Dollar oder Euro oder Pfund mit einer Laufzeit von maximal 20 Jahren. Wenn Sie an weiteren Informationen interessiert sind, füllen Sie bitte das folgende Formular aus und senden es an unsere E-Mail-Adresse: masthavenloan_fina...@hotmail.com Mehr Informationen benötigt Ihre Namen: Adresse: ... Telefon: ... Benötigte Menge: ... Dauer: ... Beruf: ... Monatliches Einkommen Level: .. Geschlecht: .. Geburtsdatum: ... Status: ... Land: . Zweck: . "Wir zeigen Ihnen, einen besseren Weg, um Ihre finanzielle Freiheit" Mit freundlichen Grüßen, Mark Hedley -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm
Ani Sinha wrote: > Indeed. So it seems to me that we have run into one another such case. > In patch c6825c0976fa7893692, I see we have added an additional check (along > with comparing tuple and zone) to verify that if the conntrack is confirmed. > > + return nf_ct_tuple_equal(tuple, &h->tuple) && > + nf_ct_zone(ct) == zone && > + nf_ct_is_confirmed(ct); > > This is necessary since it's possible that a conntrack can be recreated with > the same zone. > Unfortunately, we leave a hole open in __nf_conntrack_confirm() because this > routine _is_ responsible > for confirming the conntrack. We cannot use the same logic here. Hmm, why? I don't understand why we need to change __nf_conntrack_confirm(), can you elaborate? At __nf_conntrack_confirm call time, only one cpu can see this nfct entry. Other cpus on read-side can see it due to object re-use but any of the following tests should fail: 1. different tuples 2. differnet zones 3. CONFIRMED not set So they would skip entry and restart lookup (NULs value mismatch). > Should I send a patch along the lines of : > > diff --git a/net/netfilter/nf_conntrack_core.c > b/net/netfilter/nf_conntrack_core.c > index 71935fc..6ff4088 100644 > --- a/net/netfilter/nf_conntrack_core.c > +++ b/net/netfilter/nf_conntrack_core.c > @@ -535,6 +535,12 @@ __nf_conntrack_confirm(struct sk_buff *skb) > zone == nf_ct_zone(nf_ct_tuplehash_to_ctrack(h))) > goto out; > > + /* we might be racing against a case where the conntrack was deleted > +and a new conntrack was initialized with the exact same zone. We > +need to make sure that the conntrack node is in the hashtable */ ? The conntrack is NOT in the hashtable at this point. Its not even on the unconfirmed list since we already removed it in preparation of hashtable insertion. > + if (hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode)) > + goto out; That would be a bug, how can ->nfct be confirmed twice? If you're talking about IPS_CONFIRMED getting set -- that should be harmless. In some theoretical condition we could indeed observe this nfct on another cpu, just before we actually insert this but this does not cause a problem on the read-side since the conntrack matches the tuple exactly and all extensions have been initialized. And if we create two conntracks with identical tuples on different CPUs which is possible regardless of RCU this will be detected during confirm step (we search ht for a colliding tuple). So, if there is a problem please describe in more detail, I don't see anything wrong so far. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm
> > On Sun, Oct 18, 2015 at 1:07 AM, Florian Westphal wrote: > > Ani Sinha wrote: > >> Coming back to this crash, I see something interesting in the > >> conntrack code in linux 3.4.109 (a supported kernel version). I see > >> that the hash table manipulations are protected by a spinlock. Also > >> lookups/reads are protected by RCU. However allocation and > >> deallocation of conntrack objects happen outside of both the locks. > >> It seems to me that a conntrack object can be deallocated and a new > >> object can be allocated and initialized within the same RCU grace > >> period, while the hash table is being read. > > > > Yes. We need to use SLAB_DESTROY_BY_RCU instead of kfree_rcu because > > there could be hundreds of thousands of alloc/free pairs within a short > > time period. > > > >> It looks like a bug to me. > > > > No, as long as readers detect object reuse. Right. > > > >> > Looking upstream, I see a couple of patches which fixes race condition > >> > around the use of the conntrack hash table with RCU (lock free read) > >> > primitives : > >> > > >> > commit c6825c0976fa7893692e0e43b09740b419b23c09 > >> > Author: Andrey Vagin > >> > Date: Wed Jan 29 19:34:14 2014 +0100 > >> > netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get > >> > > >> > and a followup patch : > >> > > >> > commit e53376bef2cd97d3e3f61fdc677fb8da7d03d0da > >> > Author: Pablo Neira Ayuso > >> > Date: Mon Feb 3 20:01:53 2014 +0100 > >> > netfilter: nf_conntrack: don't release a conntrack with non-zero > >> > refcnt > >> > > > > > These for instance fix such bugs. > Indeed. So it seems to me that we have run into one another such case. In patch c6825c0976fa7893692, I see we have added an additional check (along with comparing tuple and zone) to verify that if the conntrack is confirmed. + return nf_ct_tuple_equal(tuple, &h->tuple) && + nf_ct_zone(ct) == zone && + nf_ct_is_confirmed(ct); This is necessary since it's possible that a conntrack can be recreated with the same zone. Unfortunately, we leave a hole open in __nf_conntrack_confirm() because this routine _is_ responsible for confirming the conntrack. We cannot use the same logic here. Should I send a patch along the lines of : diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c index 71935fc..6ff4088 100644 --- a/net/netfilter/nf_conntrack_core.c +++ b/net/netfilter/nf_conntrack_core.c @@ -535,6 +535,12 @@ __nf_conntrack_confirm(struct sk_buff *skb) zone == nf_ct_zone(nf_ct_tuplehash_to_ctrack(h))) goto out; + /* we might be racing against a case where the conntrack was deleted + and a new conntrack was initialized with the exact same zone. We + need to make sure that the conntrack node is in the hashtable */ + if (hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode)) + goto out; + /* Remove from unconfirmed list */ hlist_nulls_del_rcu(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode); -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/3] unix: fix use-after-free in unix_dgram_poll()
Jason Baron writes:
>
>>
>> X-Signed-Off-By: Rainer Weikusat
>>
Sorry for the delayed reply but I had to do some catching up on what the
people who pay me consider 'useful work' :-).
> So the patches I've posted and yours both use the idea of a relaying
> the remote peer wakeup via callbacks that are internal to the net/unix,
> such that we avoid exposing the remote peer wakeup to the external
> poll()/select()/epoll(). They differ in when and how those callbacks
> are registered/unregistered.
Yes. In my opinion, that's the next best idea considering that the need
to handle this particular situation is presumably specfcific to the
af_unix.c code and thus, doesn't warrant changes to all I/O multiplexing
implementations.
> So I think your approach here will generally keep the peer wait wakeup
> queue to its absolute minimum, by removing from that queue when
> we set POLLOUT, however it requires taking the peer waitqueue lock on
> every poll() call.
>
> So I think there are tradeoffs here vs. what I've
> posted. So for example, if there are a lot of writers against one 'server'
> socket, there is going to be a lot of lock contention with your approach
> here. So I think the performance is going to depend on the workload that
> is tested.
This approach is really completely run-of-the-mill "possibly sleep until
some event occurs" code, eg, you'll find a description of this exact
procedure on p. 157 of chapter 6 of
https://lwn.net/Kernel/LDD3/
The idea behind 'the wait queue' (insofar I'm aware of it) is that it
will be used as list of threads who need to be notified when the
associated event occurs. Since you seem to argue that the run-of-the-mill
algorithm is too slow for this particular case, is there anything to
back this up?
This is also sort-of a zero-sum game as the idea to enqueue on a wait
queue because the event could possibly become interesting in future
really just shifts (for n:1 connected sockets) work from the (possibly
many) clients to the single server. And considering that 'the wait'
became necessary (if it became necessary) because flow-control kicked in
to stop clients from sending more data to the server until it had time
to catch up with the already sent data, this doesn't seem like a good
idea to me.
Using a flag to signal that at least some of the members of this queue
actually want to be woken up will also only save work if it is assumed
that most threads won't ever really be waiting for this, ie, won't
execute the corresponding unix_dgram_poll code. But if that code isn't
going to be executed most of the time, anyway, why optimize it?
It's also not really necessary to take the waitqueue lock on every poll,
eg, the code in unix_dgram_poll could be changed like this:
need_wakeup = 0;
unix_state_lock(sk);
other = unix_peer(sk);
if (other && unix_peer(other) != sk) {
if (unix_recvq_full(other)) {
need_wakeup = !unix_peer_wake_connect(sk,
other);
if (unix_recvq_full(other)) {
writable = 0;
need_wakeup = 0;
} else
unix_peer_wake_disconnect(sk, other);
} else
need_wakeup = unix_peer_wake_disconnect(sk,
other);
}
unix_state_unlock(sk);
if (need_wakeup)
wake_up_interruptible_poll(sk_sleep(sk), POLL_OUT_ALL);
I'm no big fan of adding complications like this based on the conjecture
that they might be useful, but this one seems justified to me. IMHO,
there are two interesting cases here:
1. The current thread won't have to wait. It should detect this quickly
so that it can get back to work, hence, check for this before
'preparing to wait'.
2. Nothing to be done here right now, hence, performing an additional
check for 'still not writeable' shouldn't matter much.
Yet another 3.2.54 patch with the change above
---
--- linux-2-6.b/net/unix/af_unix.c 2015-10-18 20:41:10.829404899 +0100
+++ linux-2-6/net/unix/af_unix.c2015-10-18 20:17:34.819134482 +0100
@@ -115,6 +115,8 @@
#include
#include
+#define POLL_OUT_ALL (POLLOUT | POLLWRNORM | POLLWRBAND)
+
static struct hlist_head unix_socket_table[UNIX_HASH_SIZE + 1];
static DEFINE_SPINLOCK(unix_table_lock);
static atomic_long_t unix_nr_socks;
@@ -303,6 +305,53 @@ found:
return s;
}
+static int unix_peer_wake_relay(wait_queue_t *q, unsigned mode, int flags,
+ void *key)
+{
+ struct unix_sock *u;
+ wait_queue_head_t *u_sleep;
+
+ u = container_of(q, struct unix_sock, peer_wake);
+
+ u_sleep = sk_sleep(&u->sk);
+ if (u_sleep)
+ wake_up_interruptible_poll(u_sleep, key);
+
+ retur
Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs
On 10/18/15 9:49 AM, Daniel Borkmann wrote: Okay, I have pushed some rough working proof of concept here: https://git.breakpoint.cc/cgit/dborkman/net-next.git/log/?h=ebpf-fds-final5 So the idea eventually had to be slightly modified after giving this further thoughts and is the following: We have 3 commands (BPF_DEV_CREATE, BPF_DEV_DESTROY, BPF_DEV_CONNECT), and related to that a bpf_attr extension with only a single __u32 fd member in it. ... The nice thing about it is that you can create/unlink as many as you want, but when you remove the real device from an application via bpf_dev_destroy(fd), then all links disappear with it. Just like in the case of a normal device driver. interesting idea! What happens if user app creates a dev via bpf_dev_create(), exits and then admin does rm of that dev ? Looks like map/prog will leak ? So the only proper way to delete such cdevs is via bpf_dev_destroy ? On device creation, the kernel will return the minor number via bpf(2), so you can access the file easily, f.e. /dev/bpf/bpf_map resp. /dev/bpf/bpf_prog, and then move on with mknod(2) or symlink(2) from there if wished. what if admin mknod in that dir with some arbitrary minor ? mknod will succeed, but it won't hold anything? looks like bpf_dev_connect will handle it gracefully. So these cdevs should only be created and destroyed via bpf syscall and only sensible operations on them is open() to get fd and pass to bpf_dev_connect and symlink. Anything else admin should be careful not to do. Right? -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Good Day
I need your assistance into this transaction. Regards, Mr. LEUNG Cheung -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cash Awaiting Pick-Up
This is to re-notify you of the £500,000.00(POUNDS) That was deposited at western union office in your name is available for pickup. Contact this email: accountoffic...@qq.com for your M.T.C.N Numbers. Contact Person: Mrs. Hillary Florence Email: accountoffic...@qq.com -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs
On 10/18/2015 05:03 PM, Daniel Borkmann wrote:
On 10/18/2015 04:20 AM, Alexei Starovoitov wrote:
...
that indeed sounds cleaner, less lines of code, no fs, etc, but
I don't see how it will work yet.
I'll have some code ready very soon to show the concept. Will post it here
tonight, stay tuned. ;)
Okay, I have pushed some rough working proof of concept here:
https://git.breakpoint.cc/cgit/dborkman/net-next.git/log/?h=ebpf-fds-final5
So the idea eventually had to be slightly modified after giving this further
thoughts and is the following:
We have 3 commands (BPF_DEV_CREATE, BPF_DEV_DESTROY, BPF_DEV_CONNECT), and
related to that a bpf_attr extension with only a single __u32 fd member in it.
Now, when we have an existing map/prog fd, we can do bpf_dev_create(fd) from
the application, and the kernel will create automatically a device, assigning
major/minor, etc.
You'll automatically have a sysfs entry under a new "bpf" class, for example:
# ls -la /sys/class/bpf/
lrwxrwxrwx. 1 root root 0 Oct 18 18:24 bpf_map0 ->
../../devices/virtual/bpf/bpf_map0
lrwxrwxrwx. 1 root root 0 Oct 18 18:24 bpf_prog0 ->
../../devices/virtual/bpf/bpf_prog0
# cat /sys/class/bpf/bpf_map0/dev
249:0
# cat /sys/class/bpf/bpf_prog0/dev
248:0
And they also appear automatically under:
# ls -la /dev/bpf/
crw---. 1 root root 249, 0 Oct 18 17:38 bpf_map0
crw---. 1 root root 248, 0 Oct 18 18:23 bpf_prog0
This means, you can create your own hierarchy somewhere and then symlink to it,
or add further mknod's, f.e.:
# mknod ./foomap c 249 0
# ./samples/bpf/devicex map-connect ./foomap
dev, fd:3 (Success)
map, fd:4 (Success)
map, fd:4 read pair:(123,0) (Success)
The nice thing about it is that you can create/unlink as many as you want, but
when you remove the real device from an application via bpf_dev_destroy(fd),
then all links disappear with it. Just like in the case of a normal device
driver.
On device creation, the kernel will return the minor number via bpf(2), so you
can access the file easily, f.e. /dev/bpf/bpf_map resp.
/dev/bpf/bpf_prog,
and then move on with mknod(2) or symlink(2) from there if wished.
Last but not least, we can open the device driver, and then bpf_dev_connect(fd)
will return a new fd you can operate with the bpf(2) syscall to access maps and
stuff. Same here, the remaining device driver ops, we can then still use in
future
for something useful.
The example code (top commit) does, to show the concept:
** Map:
* Create map and place map into special device:
# ./samples/bpf/devicex map-create /tmp/map-test
map, fd:3 (Success)
map, dev minor:2 (Success)
map, /dev/bpf/bpf_map2 linked to /tmp/map-test (Success)
map, fd:3 wrote pair:(123,456) (Success)
map, fd:3 read pair:(123,456) (Success)
* Retrieve map from special device:
# ./samples/bpf/devicex map-connect /tmp/map-test
dev, fd:3 (Success)
map, fd:4 (Success)
map, fd:4 read pair:(123,456) (Success)
* Destroy special device (map is still locally available):
# ./samples/bpf/devicex map-destroy /tmp/map-test2
dev, fd:3 (Success)
map, fd:4 (Success)
map, dev destroyed:2 (Success)
map, fd:4 read pair:(123,456) (Success)
** Prog:
* Create prog and place prog into special device:
# ./samples/bpf/devicex prog-create /tmp/prog-test
prog, fd:3 (Success)
prog, dev minor:0 (Success)
prog, /dev/bpf/bpf_prog0 linked to /tmp/prog-test (Success)
sock, fd:4 (Success)
sock, prog attached:0 (Success)
* Retrieve prog from special device, attach to sock:
# ./samples/bpf/devicex prog-connect /tmp/prog-test
dev, fd:3 (Success)
prog, fd:4 (Success)
sock, fd:3 (Success)
sock, prog attached:0 (Success)
* Destroy special device (prog is still locally available):
# ./samples/bpf/devicex prog-destroy /tmp/prog-test
dev, fd:3 (Success)
prog, fd:4 (Success)
prog, dev destroyed:0 (Success)
The actual code needed (2nd commit from above link), would be roughly along the
lines of what is shown below ... the code is overall a bit smaller than the fs.
This model seems much cleaner and more flexible to me than the file system. So,
I could polish this stuff further up a bit and do further tests/reviews on
Monday
for a real submission. Does that sound like a plan?
Thanks,
Daniel
Code:
include/linux/bpf.h | 20 +++
include/uapi/linux/bpf.h | 45 +-
kernel/bpf/Makefile | 4 +-
kernel/bpf/core.c| 2 +-
kernel/bpf/device.c | 407 +++
kernel/bpf/syscall.c | 52 --
6 files changed, 482 insertions(+), 48 deletions(-)
create mode 100644 kernel/bpf/device.c
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 0ae6f77..52d57ed 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -8,8 +8,12 @@
#define _LINUX_BPF_H 1
#include
+
#include
#include
+#include
+
+#define BPF_F_HAS_DEV (1 << 0)
struct bpf_map;
@@ -37,7 +41,11 @@ struct bpf_map {
u32 value_
[PATCH v3] vsock: fix missing cleanup when misc_register failed
reset transport and unlock if misc_register failed.
Signed-off-by: Gao feng
---
net/vmw_vsock/af_vsock.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index df5fc6b..00e8a34 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1948,13 +1948,13 @@ int __vsock_core_init(const struct vsock_transport *t,
struct module *owner)
err = misc_register(&vsock_device);
if (err) {
pr_err("Failed to register misc device\n");
- return -ENOENT;
+ goto err_reset_transport;
}
err = proto_register(&vsock_proto, 1); /* we want our slab */
if (err) {
pr_err("Cannot register vsock protocol\n");
- goto err_misc_deregister;
+ goto err_deregister_misc;
}
err = sock_register(&vsock_family_ops);
@@ -1969,8 +1969,9 @@ int __vsock_core_init(const struct vsock_transport *t,
struct module *owner)
err_unregister_proto:
proto_unregister(&vsock_proto);
-err_misc_deregister:
+err_deregister_misc:
misc_deregister(&vsock_device);
+err_reset_transport:
transport = NULL;
err_busy:
mutex_unlock(&vsock_register_mutex);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/9] net: fix trivial typos
s/regsiter/register/ Signed-off-by: Geliang Tang --- drivers/net/ethernet/amd/amd8111e.h | 2 +- drivers/net/ethernet/atheros/atl1c/atl1c_hw.c | 2 +- drivers/net/ethernet/intel/igb/e1000_phy.c| 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/ethernet/amd/amd8111e.h b/drivers/net/ethernet/amd/amd8111e.h index 7cdb185..d5e2b71 100644 --- a/drivers/net/ethernet/amd/amd8111e.h +++ b/drivers/net/ethernet/amd/amd8111e.h @@ -48,7 +48,7 @@ eg., if the value 10011010b is written into the least significant byte of a comm /* 32 bit registers */ #define ASF_STAT 0x00/* ASF status register */ -#define CHIPID 0x04/* Chip ID regsiter */ +#define CHIPID 0x04/* Chip ID register */ #defineMIB_DATA0x10/* MIB data register */ #define MIB_ADDR 0x14/* MIB address register */ #define STAT0 0x30/* Status0 register */ diff --git a/drivers/net/ethernet/atheros/atl1c/atl1c_hw.c b/drivers/net/ethernet/atheros/atl1c/atl1c_hw.c index a8b80c5..73efdb0 100644 --- a/drivers/net/ethernet/atheros/atl1c/atl1c_hw.c +++ b/drivers/net/ethernet/atheros/atl1c/atl1c_hw.c @@ -307,7 +307,7 @@ void atl1c_start_phy_polling(struct atl1c_hw *hw, u16 clk_sel) /* * atl1c_read_phy_core - * core function to read register in PHY via MDIO control regsiter. + * core function to read register in PHY via MDIO control register. * ext: extension register (see IEEE 802.3) * dev: device address (see IEEE 802.3 DEVAD, PRTAD is fixed to 0) * reg: reg to read diff --git a/drivers/net/ethernet/intel/igb/e1000_phy.c b/drivers/net/ethernet/intel/igb/e1000_phy.c index 23ec28f..ffc3a14 100644 --- a/drivers/net/ethernet/intel/igb/e1000_phy.c +++ b/drivers/net/ethernet/intel/igb/e1000_phy.c @@ -123,7 +123,7 @@ out: * @offset: register offset to be read * @data: pointer to the read data * - * Reads the MDI control regsiter in the PHY at offset and stores the + * Reads the MDI control register in the PHY at offset and stores the * information read to data. **/ s32 igb_read_phy_reg_mdic(struct e1000_hw *hw, u32 offset, u16 *data) -- 2.5.0 -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] vsock: fix missing cleanup when misc_register failed
Hi Gao,
[auto build test ERROR on net/master -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Gao-feng/vsock-fix-missing-cleanup-when-misc_register-failed/20151018-223056
config: x86_64-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
net/vmw_vsock/af_vsock.c:1957:17: sparse: label 'err_deregister_misc' was
not declared
net/vmw_vsock/af_vsock.c: In function '__vsock_core_init':
>> net/vmw_vsock/af_vsock.c:1972:1: warning: label 'err_undegister_misc'
>> defined but not used [-Wunused-label]
err_undegister_misc:
^
>> net/vmw_vsock/af_vsock.c:1957:3: error: label 'err_deregister_misc' used but
>> not defined
goto err_deregister_misc;
^
sparse warnings: (new ones prefixed by >>)
>> net/vmw_vsock/af_vsock.c:1957:17: sparse: label 'err_deregister_misc' was
>> not declared
net/vmw_vsock/af_vsock.c: In function '__vsock_core_init':
net/vmw_vsock/af_vsock.c:1972:1: warning: label 'err_undegister_misc'
defined but not used [-Wunused-label]
err_undegister_misc:
^
net/vmw_vsock/af_vsock.c:1957:3: error: label 'err_deregister_misc' used but
not defined
goto err_deregister_misc;
^
vim +/err_deregister_misc +1957 net/vmw_vsock/af_vsock.c
1951 goto err_reset_transport;
1952 }
1953
1954 err = proto_register(&vsock_proto, 1); /* we want our slab */
1955 if (err) {
1956 pr_err("Cannot register vsock protocol\n");
> 1957 goto err_deregister_misc;
1958 }
1959
1960 err = sock_register(&vsock_family_ops);
1961 if (err) {
1962 pr_err("could not register af_vsock (%d) address
family: %d\n",
1963 AF_VSOCK, err);
1964 goto err_unregister_proto;
1965 }
1966
1967 mutex_unlock(&vsock_register_mutex);
1968 return 0;
1969
1970 err_unregister_proto:
1971 proto_unregister(&vsock_proto);
> 1972 err_undegister_misc:
1973 misc_deregister(&vsock_device);
1974 err_reset_transport:
1975 transport = NULL;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH net] net: try harder to not reuse ifindex when moving interfaces
On Fri, Oct 16, 2015 at 01:07:59PM +0200, Jiri Benc wrote:
> When moving interfaces to a different netns, the ifindex of the interface is
> kept if possible. However, this is not kept in sync with allocation of new
> interfaces in the target netns. While the ifindex will be skipped when
> creating a new interface in the netns, it will be reused when the old
> interface disappeared since.
>
> This causes races for GUI tools in situations like this:
>
> 1. create netns 'new_netns'
> 2. in root netns, move the interface with ifindex 2 to new_netns
> 3. in new_netns, delete the interface with ifindex 2
> 4. in new_netns, create an interface - it will get ifindex 2
>
> Ensure that newly allocated interfaces in a netns get ifindex higher than
> any interface that has appeared in the netns. This of course does not fix
> the reuse problem for the applications; it just makes it less likely to be
> hit in common usage patterns.
>
> Reported-by: Thomas Haller
> Signed-off-by: Jiri Benc
> ---
> net/core/dev.c | 19 +++
> 1 file changed, 19 insertions(+)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 6bb6470f5b7b..e3d05c20f0ef 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -6137,6 +6137,23 @@ static int dev_new_index(struct net *net)
> }
> }
>
> +/**
> + * dev_update_index - update the ifindex used for allocation
> + * @net: the applicable net namespace
> + * @ifindex: the assigned ifindex
> + *
> + * Updates the notion of currently allocated maximal ifindex to
> + * decrease likelihood of ifindex reuse when the ifindex was assigned
> + * by other means than calling dev_new_index (e.g. when moving
> + * interface across net namespaces). The caller must hold the rtnl
> + * semaphore or the dev_base_lock.
> + */
> +static void dev_update_index(struct net *net, int ifindex)
> +{
> + if (ifindex > net->ifindex)
> + net->ifindex = ifindex;
> +}
> +
it looks dangerous.
Does it mean that 'for (4B) { create new dev; free old dev; }
will keep incrementing that max index and dos it eventually?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs
On 10/18/2015 04:20 AM, Alexei Starovoitov wrote: ... that indeed sounds cleaner, less lines of code, no fs, etc, but I don't see how it will work yet. I'll have some code ready very soon to show the concept. Will post it here tonight, stay tuned. ;) Cheers, Daniel -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-next 2/7] tcp: track min RTT using windowed min-filter
On Wed, Oct 14, 2015 at 5:28 AM, Andrew Shewmaker wrote: >> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c >> index 38743e5..e177386 100644 >> --- a/net/ipv4/tcp_input.c >> +++ b/net/ipv4/tcp_input.c > ... >> @@ -2961,7 +3028,7 @@ void tcp_synack_rtt_meas(struct sock *sk, struct >> request_sock *req) >> rtt_us = skb_mstamp_us_delta(&now, &tcp_rsk(req)->snt_synack); >> } >> >> - tcp_ack_update_rtt(sk, FLAG_SYN_ACKED, rtt_us, -1L); >> + tcp_ack_update_rtt(sk, FLAG_SYN_ACKED, rtt_us, -1L, rtt_us); >> } > > This didn't apply to net-next for me. I see seq_rtt_us instead of > rtt_us and a check on the existence of tp->srtt_us. Maybe I've > misapplied the patch? This patch series applies cleanly for me against David Miller's net-next at SHA1 4be3158 (from Friday Oct 16). (Using "git am" on the mbox patches from http://patchwork.ozlabs.org/project/netdev/list/ ...) On top of what SHA1 are you applying the series? neal -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] vsock: fix missing cleanup when misc_register failed
reset transport and unlock if misc_register failed.
Signed-off-by: Gao feng
---
net/vmw_vsock/af_vsock.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index df5fc6b..598e045 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1948,13 +1948,13 @@ int __vsock_core_init(const struct vsock_transport *t,
struct module *owner)
err = misc_register(&vsock_device);
if (err) {
pr_err("Failed to register misc device\n");
- return -ENOENT;
+ goto err_reset_transport;
}
err = proto_register(&vsock_proto, 1); /* we want our slab */
if (err) {
pr_err("Cannot register vsock protocol\n");
- goto err_misc_deregister;
+ goto err_deregister_misc;
}
err = sock_register(&vsock_family_ops);
@@ -1969,8 +1969,9 @@ int __vsock_core_init(const struct vsock_transport *t,
struct module *owner)
err_unregister_proto:
proto_unregister(&vsock_proto);
-err_misc_deregister:
+err_undegister_misc:
misc_deregister(&vsock_device);
+err_reset_transport:
transport = NULL;
err_busy:
mutex_unlock(&vsock_register_mutex);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vsock: fix missing cleanup when misc_register failed
Hi Gao,
[auto build test ERROR on net/master -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Gao-feng/vsock-fix-missing-cleanup-when-misc_register-failed/20151018-215542
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All error/warnings (new ones prefixed by >>):
net/vmw_vsock/af_vsock.c: In function '__vsock_core_init':
>> net/vmw_vsock/af_vsock.c:1972:1: warning: label 'err_unregister_misc'
>> defined but not used [-Wunused-label]
err_unregister_misc:
^
>> net/vmw_vsock/af_vsock.c:1957:3: error: label 'err_misc_deregister' used but
>> not defined
goto err_misc_deregister;
^
vim +/err_misc_deregister +1957 net/vmw_vsock/af_vsock.c
1ef231d1 Gao feng 2015-10-18 1951 goto err_reset_transport;
d021c344 Andy King 2013-02-06 1952 }
d021c344 Andy King 2013-02-06 1953
d021c344 Andy King 2013-02-06 1954 err = proto_register(&vsock_proto, 1);
/* we want our slab */
d021c344 Andy King 2013-02-06 1955 if (err) {
d021c344 Andy King 2013-02-06 1956 pr_err("Cannot register vsock
protocol\n");
d021c344 Andy King 2013-02-06 @1957 goto err_misc_deregister;
d021c344 Andy King 2013-02-06 1958 }
d021c344 Andy King 2013-02-06 1959
d021c344 Andy King 2013-02-06 1960 err = sock_register(&vsock_family_ops);
d021c344 Andy King 2013-02-06 1961 if (err) {
d021c344 Andy King 2013-02-06 1962 pr_err("could not register
af_vsock (%d) address family: %d\n",
d021c344 Andy King 2013-02-06 1963AF_VSOCK, err);
d021c344 Andy King 2013-02-06 1964 goto err_unregister_proto;
d021c344 Andy King 2013-02-06 1965 }
d021c344 Andy King 2013-02-06 1966
2c4a336e Andy King 2014-05-01 1967 mutex_unlock(&vsock_register_mutex);
d021c344 Andy King 2013-02-06 1968 return 0;
d021c344 Andy King 2013-02-06 1969
d021c344 Andy King 2013-02-06 1970 err_unregister_proto:
d021c344 Andy King 2013-02-06 1971 proto_unregister(&vsock_proto);
1ef231d1 Gao feng 2015-10-18 @1972 err_unregister_misc:
d021c344 Andy King 2013-02-06 1973 misc_deregister(&vsock_device);
1ef231d1 Gao feng 2015-10-18 1974 err_reset_transport:
d021c344 Andy King 2013-02-06 1975 transport = NULL;
:: The code at line 1957 was first introduced by commit
:: d021c344051af91f42c5ba9fdedc176740cbd238 VSOCK: Introduce VM Sockets
:: TO: Andy King
:: CC: David S. Miller
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: [PATCH net-next 2/7] tcp: track min RTT using windowed min-filter
On Fri, Oct 16, 2015 at 09:57:42PM -0700, Yuchung Cheng wrote:
...
> diff --git a/include/linux/tcp.h b/include/linux/tcp.h
> index 86a7eda..90edef5 100644
> --- a/include/linux/tcp.h
> +++ b/include/linux/tcp.h
> @@ -217,6 +217,9 @@ struct tcp_sock {
> u32 mdev_max_us;/* maximal mdev for the last rtt period */
> u32 rttvar_us; /* smoothed mdev_max*/
> u32 rtt_seq;/* sequence number to update rttvar */
> + struct rtt_meas {
> + u32 rtt, ts;/* RTT in usec and sampling time in jiffies. */
> + } rtt_min[3];
First, thanks for all the work in this patch series. In particular,
applying Kern's check to ca_seq_rtt_us should fix some bad behavior
I've observed recently.
I only have a couple comments, so I abbreviated most of your patch.
Should rtt_meas.rtt be rtt_meas.rtt_us in order to be more consistent
with the naming of related variables?
...
> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
> index 38743e5..e177386 100644
> --- a/net/ipv4/tcp_input.c
> +++ b/net/ipv4/tcp_input.c
...
> @@ -2961,7 +3028,7 @@ void tcp_synack_rtt_meas(struct sock *sk, struct
> request_sock *req)
> rtt_us = skb_mstamp_us_delta(&now, &tcp_rsk(req)->snt_synack);
> }
>
> - tcp_ack_update_rtt(sk, FLAG_SYN_ACKED, rtt_us, -1L);
> + tcp_ack_update_rtt(sk, FLAG_SYN_ACKED, rtt_us, -1L, rtt_us);
> }
This didn't apply to net-next for me. I see seq_rtt_us instead of
rtt_us and a check on the existence of tp->srtt_us. Maybe I've
misapplied the patch? I'll try again and test the patch series
against the bad behavior I mentioned above as soon as I can.
Hopefully today.
-Andrew Shewmaker
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 0/2] net: mv643xx_eth: TSO TX data corruption fixes
Hello, as previously discussed [1] the mv643xx_eth driver has some issues with data corruption when using TCP segmentation offload (TSO). The following patch set improves this situation by fixing two data corruption bugs in the TSO TX path. Before applying the patches repeatedly accessing large files located on a SMB share on my NSA325 NAS with TSO enabled resulted in different hash sums, which confirmed that data corruption is happening during file transfer. After applying the patches the hash sums were the same. As this is my first patch submission please feel free to point out any issues with the patch set. [1] http://thread.gmane.org/gmane.linux.network/336530 Best wishes, Philipp Philipp Kirchhofer (2): net: mv643xx_eth: Ensure proper data alignment in TSO TX path net: mv643xx_eth: Defer writing the first TX descriptor when using TSO drivers/net/ethernet/marvell/mv643xx_eth.c | 48 +- 1 file changed, 40 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 2/2] net: mv643xx_eth: Defer writing the first TX descriptor when using TSO
To prevent a race between the TX DMA engine and the CPU the writing of the
first transmit descriptor must be deferred until all following descriptors
have been updated. The network card may otherwise start transmitting before
all packet descriptors are set up correctly, which leads to data corruption
or an aborted transmit operation.
This deferral is already done in the non-TSO TX path, implement it also in
the TSO TX path.
Signed-off-by: Philipp Kirchhofer
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index 68073bc..5124535 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -791,7 +791,8 @@ txq_put_data_tso(struct net_device *dev, struct tx_queue
*txq,
}
static inline void
-txq_put_hdr_tso(struct sk_buff *skb, struct tx_queue *txq, int length)
+txq_put_hdr_tso(struct sk_buff *skb, struct tx_queue *txq, int length,
+ u32 *first_cmd_sts, bool first_desc)
{
struct mv643xx_eth_private *mp = txq_to_mp(txq);
int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
@@ -800,6 +801,7 @@ txq_put_hdr_tso(struct sk_buff *skb, struct tx_queue *txq,
int length)
int ret;
u32 cmd_csum = 0;
u16 l4i_chk = 0;
+ u32 cmd_sts;
tx_index = txq->tx_curr_desc;
desc = &txq->tx_desc_area[tx_index];
@@ -815,9 +817,17 @@ txq_put_hdr_tso(struct sk_buff *skb, struct tx_queue *txq,
int length)
desc->byte_cnt = hdr_len;
desc->buf_ptr = txq->tso_hdrs_dma +
txq->tx_curr_desc * TSO_HEADER_SIZE;
- desc->cmd_sts = cmd_csum | BUFFER_OWNED_BY_DMA | TX_FIRST_DESC |
+ cmd_sts = cmd_csum | BUFFER_OWNED_BY_DMA | TX_FIRST_DESC |
GEN_CRC;
+ /* Defer updating the first command descriptor until all
+* following descriptors have been written.
+*/
+ if (first_desc)
+ *first_cmd_sts = cmd_sts;
+ else
+ desc->cmd_sts = cmd_sts;
+
txq->tx_curr_desc++;
if (txq->tx_curr_desc == txq->tx_ring_size)
txq->tx_curr_desc = 0;
@@ -831,6 +841,8 @@ static int txq_submit_tso(struct tx_queue *txq, struct
sk_buff *skb,
int desc_count = 0;
struct tso_t tso;
int hdr_len = skb_transport_offset(skb) + tcp_hdrlen(skb);
+ struct tx_desc *first_tx_desc;
+ u32 first_cmd_sts = 0;
/* Count needed descriptors */
if ((txq->tx_desc_count + tso_count_descs(skb)) >= txq->tx_ring_size) {
@@ -838,11 +850,14 @@ static int txq_submit_tso(struct tx_queue *txq, struct
sk_buff *skb,
return -EBUSY;
}
+ first_tx_desc = &txq->tx_desc_area[txq->tx_curr_desc];
+
/* Initialize the TSO handler, and prepare the first payload */
tso_start(skb, &tso);
total_len = skb->len - hdr_len;
while (total_len > 0) {
+ bool first_desc = (desc_count == 0);
char *hdr;
data_left = min_t(int, skb_shinfo(skb)->gso_size, total_len);
@@ -852,7 +867,8 @@ static int txq_submit_tso(struct tx_queue *txq, struct
sk_buff *skb,
/* prepare packet headers: MAC + IP + TCP */
hdr = txq->tso_hdrs + txq->tx_curr_desc * TSO_HEADER_SIZE;
tso_build_hdr(skb, hdr, &tso, data_left, total_len == 0);
- txq_put_hdr_tso(skb, txq, data_left);
+ txq_put_hdr_tso(skb, txq, data_left, &first_cmd_sts,
+ first_desc);
while (data_left > 0) {
int size;
@@ -872,6 +888,10 @@ static int txq_submit_tso(struct tx_queue *txq, struct
sk_buff *skb,
__skb_queue_tail(&txq->tx_skb, skb);
skb_tx_timestamp(skb);
+ /* ensure all other descriptors are written before first cmd_sts */
+ wmb();
+ first_tx_desc->cmd_sts = first_cmd_sts;
+
/* clear TX_END status */
mp->work_tx_end &= ~(1 << txq->index);
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net 1/2] net: mv643xx_eth: Ensure proper data alignment in TSO TX path
The TX DMA engine requires that buffers with a size of 8 bytes or smaller
must be 64 bit aligned. This requirement may be violated when doing TSO,
as in this case larger skb frags can be broken up and transmitted in small
parts with then inappropriate alignment.
Fix this by checking for proper alignment before handing a buffer to the
DMA engine. If the data is misaligned realign it by copying it into the
TSO header data area.
Signed-off-by: Philipp Kirchhofer
---
drivers/net/ethernet/marvell/mv643xx_eth.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c
b/drivers/net/ethernet/marvell/mv643xx_eth.c
index d52639b..68073bc 100644
--- a/drivers/net/ethernet/marvell/mv643xx_eth.c
+++ b/drivers/net/ethernet/marvell/mv643xx_eth.c
@@ -759,11 +759,23 @@ txq_put_data_tso(struct net_device *dev, struct tx_queue
*txq,
desc->l4i_chk = 0;
desc->byte_cnt = length;
- desc->buf_ptr = dma_map_single(dev->dev.parent, data,
- length, DMA_TO_DEVICE);
- if (unlikely(dma_mapping_error(dev->dev.parent, desc->buf_ptr))) {
- WARN(1, "dma_map_single failed!\n");
- return -ENOMEM;
+
+ if (length <= 8 && (uintptr_t)data & 0x7) {
+ /* Copy unaligned small data fragment to TSO header data area */
+ memcpy(txq->tso_hdrs + txq->tx_curr_desc * TSO_HEADER_SIZE,
+ data, length);
+ desc->buf_ptr = txq->tso_hdrs_dma
+ + txq->tx_curr_desc * TSO_HEADER_SIZE;
+ } else {
+ /* Alignment is okay, map buffer and hand off to hardware */
+ txq->tx_desc_mapping[tx_index] = DESC_DMA_MAP_SINGLE;
+ desc->buf_ptr = dma_map_single(dev->dev.parent, data,
+ length, DMA_TO_DEVICE);
+ if (unlikely(dma_mapping_error(dev->dev.parent,
+ desc->buf_ptr))) {
+ WARN(1, "dma_map_single failed!\n");
+ return -ENOMEM;
+ }
}
cmd_sts = BUFFER_OWNED_BY_DMA;
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] vsock: fix missing cleanup when misc_register failed
reset transport and unlock if misc_register failed.
Signed-off-by: Gao feng
---
net/vmw_vsock/af_vsock.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c
index df5fc6b..5f5fbed 100644
--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -1948,7 +1948,7 @@ int __vsock_core_init(const struct vsock_transport *t,
struct module *owner)
err = misc_register(&vsock_device);
if (err) {
pr_err("Failed to register misc device\n");
- return -ENOENT;
+ goto err_reset_transport;
}
err = proto_register(&vsock_proto, 1); /* we want our slab */
@@ -1969,8 +1969,9 @@ int __vsock_core_init(const struct vsock_transport *t,
struct module *owner)
err_unregister_proto:
proto_unregister(&vsock_proto);
-err_misc_deregister:
+err_unregister_misc:
misc_deregister(&vsock_device);
+err_reset_transport:
transport = NULL;
err_busy:
mutex_unlock(&vsock_register_mutex);
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] net: wireless: rt2x00: statics code style
Hello. On 10/17/2015 11:25 PM, Paul McQuade wrote: Do not initialise statics to 0 or NULL Also use tabs where possible Signed-off-by: Paul McQuade --- drivers/net/wireless/rt2x00/rt61pci.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c index c0e730e..53bd23d 100644 --- a/drivers/net/wireless/rt2x00/rt61pci.c +++ b/drivers/net/wireless/rt2x00/rt61pci.c @@ -39,7 +39,7 @@ /* * Allow hardware encryption to be disabled. */ -static bool modparam_nohwcrypt = false; +static bool modparam_nohwcrypt; module_param_named(nohwcrypt, modparam_nohwcrypt, bool, S_IRUGO); MODULE_PARM_DESC(nohwcrypt, "Disable hardware encryption."); @@ -1388,7 +1388,7 @@ static bool rt61pci_get_entry_state(struct queue_entry *entry) rt2x00_desc_read(entry_priv->desc, 0, &word); return (rt2x00_get_field32(word, TXD_W0_OWNER_NIC) || - rt2x00_get_field32(word, TXD_W0_VALID)); + rt2x00_get_field32(word, TXD_W0_VALID)); This line should indented more, like it was before. And the outer parens aren't needed. MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] net: wireless: b43: Fixed Pointer issue
On Sun, 18 Oct 2015 00:01:37 +0100
Paul McQuade wrote:
> Moved around pointer to avoid ERROR
>
> Signed-off-by: Paul McQuade
> ---
> drivers/net/wireless/b43/dma.h | 14 +++---
> drivers/net/wireless/b43/main.c | 6 +++---
> drivers/net/wireless/b43/main.h | 2 +-
> drivers/net/wireless/b43/xmit.h | 2 +-
> 4 files changed, 12 insertions(+), 12 deletions(-)
>
> enum b43_dmatype {
> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> index 2849070..040caa4 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -364,7 +364,7 @@ static struct ieee80211_supported_band
> b43_band_2ghz_limited = {
>
> static void b43_wireless_core_exit(struct b43_wldev *dev);
> static int b43_wireless_core_init(struct b43_wldev *dev);
> -static struct b43_wldev * b43_wireless_core_stop(struct b43_wldev *dev);
> +static struct b43_wldev *b43_wireless_core_stop(struct b43_wldev *dev);
> static int b43_wireless_core_start(struct b43_wldev *dev);
> static void b43_op_bss_info_changed(struct ieee80211_hw *hw,
> struct ieee80211_vif *vif,
Can we have a sane commit message, please?
This is not an 'error' or an 'issue'. It's purely cosmetical and coding
style related.
--
Michael
pgpDahJqbAp9x.pgp
Description: OpenPGP digital signature
Re: [PATCH 3/3] net: wireless: b43: statics Don't init to 0
On 18 October 2015 at 01:01, Paul McQuade wrote: > Don't turn statics to 0 or NULL Same request as Michael's in 2/3. Your "statics Don't init to 0" message sounds strange, statics *are* initialized to 0 by default (as you probably know but described it in a unclear way). -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux 3.4.43 : kernel crash at __nf_conntrack_confirm
Ani Sinha wrote: > Coming back to this crash, I see something interesting in the > conntrack code in linux 3.4.109 (a supported kernel version). I see > that the hash table manipulations are protected by a spinlock. Also > lookups/reads are protected by RCU. However allocation and > deallocation of conntrack objects happen outside of both the locks. > It seems to me that a conntrack object can be deallocated and a new > object can be allocated and initialized within the same RCU grace > period, while the hash table is being read. Yes. We need to use SLAB_DESTROY_BY_RCU instead of kfree_rcu because there could be hundreds of thousands of alloc/free pairs within a short time period. > It looks like a bug to me. No, as long as readers detect object reuse. > > Looking upstream, I see a couple of patches which fixes race condition > > around the use of the conntrack hash table with RCU (lock free read) > > primitives : > > > > commit c6825c0976fa7893692e0e43b09740b419b23c09 > > Author: Andrey Vagin > > Date: Wed Jan 29 19:34:14 2014 +0100 > > netfilter: nf_conntrack: fix RCU race in nf_conntrack_find_get > > > > and a followup patch : > > > > commit e53376bef2cd97d3e3f61fdc677fb8da7d03d0da > > Author: Pablo Neira Ayuso > > Date: Mon Feb 3 20:01:53 2014 +0100 > > netfilter: nf_conntrack: don't release a conntrack with non-zero > > refcnt > > These for instance fix such bugs. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
