* RE: [PATCH] r8169: remember WOL preferences on driver load
From: hayeswang @ 2013-08-15 6:09 UTC (permalink / raw)
To: 'Peter Wu', 'Francois Romieu'; +Cc: netdev, 'nic_swsd'
In-Reply-To: <5823402.G5n4G2k0Uv@al>
Peter Wu [mailto:lekensteyn@gmail.com]
> Sent: Wednesday, August 14, 2013 8:57 PM
> To: Francois Romieu
> Cc: netdev@vger.kernel.org; nic_swsd; Hayeswang
> Subject: Re: [PATCH] r8169: remember WOL preferences on driver load
>
> On Tuesday 13 August 2013 23:28:43 Francois Romieu wrote:
> > > The r8168 vendor driver used to write to both Config1 and
> Config5, but
> > > in recent versions, this is commented out. Here we keep
> writing PMEnable
> > > to Config1 because there may be older chips where
> PMEnable is not sticky.
> >
> > <sneak regression paranoia>
> > Please include the bits you want to keep in the "&" mask.
> > </sneak regression paranoia>
>
> I previously tried:
>
> RTL_W8(Config5, RTL_R8(Config5) & (BWF | MWF | UWF |
> LanWake | PMEStatus));
I think this way is better and safe.
> but then I realized that the Realtek r8168 vendor driver does
> not touch this
> register on load. The bits not included in the above mask are
> 2, 3 and 7. On
> most datasheets for recent hardware, these are marked reserved.
Some settings would be in rtl8168_hw_start() for different chips.
We sure only correct bit would be enabled.
The simple way is to clear bit 2, 3 and 7 for all chips. Or set desired
bit which you want.
Best Regards,
Hayes
^ permalink raw reply
* Re: [patch 1/2] libceph: fix error handling in handle_reply()
From: Sage Weil @ 2013-08-15 6:05 UTC (permalink / raw)
To: Dan Carpenter; +Cc: David S. Miller, ceph-devel, netdev, kernel-janitors
In-Reply-To: <20130815055158.GA23580@elgon.mountain>
Applied all 3 of these.
Thanks, Dan!
sage
On Thu, 15 Aug 2013, Dan Carpenter wrote:
> We've tried to fix the error paths in this function before, but there
> is still a hidden goto in the ceph_decode_need() macro which goes to the
> wrong place. We need to release the "req" and unlock a mutex before
> returning.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
> diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
> index dbc0a73..559a832 100644
> --- a/net/ceph/osd_client.c
> +++ b/net/ceph/osd_client.c
> @@ -1488,14 +1488,14 @@ static void handle_reply(struct ceph_osd_client *osdc, struct ceph_msg *msg,
> dout("handle_reply %p tid %llu req %p result %d\n", msg, tid,
> req, result);
>
> - ceph_decode_need(&p, end, 4, bad);
> + ceph_decode_need(&p, end, 4, bad_put);
> numops = ceph_decode_32(&p);
> if (numops > CEPH_OSD_MAX_OP)
> goto bad_put;
> if (numops != req->r_num_ops)
> goto bad_put;
> payload_len = 0;
> - ceph_decode_need(&p, end, numops * sizeof(struct ceph_osd_op), bad);
> + ceph_decode_need(&p, end, numops * sizeof(struct ceph_osd_op), bad_put);
> for (i = 0; i < numops; i++) {
> struct ceph_osd_op *op = p;
> int len;
> @@ -1513,7 +1513,7 @@ static void handle_reply(struct ceph_osd_client *osdc, struct ceph_msg *msg,
> goto bad_put;
> }
>
> - ceph_decode_need(&p, end, 4 + numops * 4, bad);
> + ceph_decode_need(&p, end, 4 + numops * 4, bad_put);
> retry_attempt = ceph_decode_32(&p);
> for (i = 0; i < numops; i++)
> req->r_reply_op_result[i] = ceph_decode_32(&p);
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* [PATCH v4 5/5] ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
From: Lad, Prabhakar @ 2013-08-15 6:01 UTC (permalink / raw)
To: Sekhar Nori
Cc: DLOS, LKML, devicetree-discuss, linux-arm-kernel, netdev,
Lad, Prabhakar
In-Reply-To: <1376546497-26931-1-git-send-email-prabhakar.csengg@gmail.com>
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Add OF_DEV_AUXDATA for eth0 driver in da850 board dt
file to use emac clock.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Changes for V2: none
Changes for V3: none
Changes for v4: none
arch/arm/mach-davinci/da8xx-dt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index d172563..caa9202 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -44,6 +44,9 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ns16550a", 0x01d0c000, "serial8250.1", NULL),
OF_DEV_AUXDATA("ns16550a", 0x01d0d000, "serial8250.2", NULL),
OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0", NULL),
+ OF_DEV_AUXDATA("ti,davinci-dm6467-emac", 0x01e20000, "davinci_emac.1",
+ NULL),
+
{}
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 4/5] ARM: davinci: da850: add DT node for eth0.
From: Lad, Prabhakar @ 2013-08-15 6:01 UTC (permalink / raw)
To: Sekhar Nori
Cc: DLOS, LKML, devicetree-discuss, linux-arm-kernel, netdev,
Lad, Prabhakar
In-Reply-To: <1376546497-26931-1-git-send-email-prabhakar.csengg@gmail.com>
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Add eth0 device tree node information and pinmux for mii to da850 by
providing interrupt details and local mac address of eth0.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Changes for v2: None
Changes for v3:
a> Split the pinmux for mdio and mii.
Changes for v4: none
arch/arm/boot/dts/da850-evm.dts | 5 +++++
arch/arm/boot/dts/da850.dtsi | 30 ++++++++++++++++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 1f8cfdd..65bc080 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -96,6 +96,11 @@
pinctrl-0 = <&mdio_pins>;
bus_freq = <2200000>;
};
+ eth0: emac@1e20000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mii_pins>;
+ };
};
nand_cs3@62000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index d5138b4..911f647 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -131,6 +131,22 @@
0x10 0x00000088 0x000000ff
>;
};
+ mii_pins: pinmux_mii_pins {
+ pinctrl-single,bits = <
+ /*
+ * MII_TXEN, MII_TXCLK, MII_COL
+ * MII_TXD_3, MII_TXD_2, MII_TXD_1
+ * MII_TXD_0
+ */
+ 0x8 0x88888880 0xfffffff0
+ /*
+ * MII_RXER, MII_CRS, MII_RXCLK
+ * MII_RXDV, MII_RXD_3, MII_RXD_2
+ * MII_RXD_1, MII_RXD_0
+ */
+ 0xc 0x88888888 0xffffffff
+ >;
+ };
};
serial0: serial@1c42000 {
@@ -226,6 +242,20 @@
#size-cells = <0>;
reg = <0x224000 0x1000>;
};
+ eth0: emac@1e20000 {
+ compatible = "ti,davinci-dm6467-emac";
+ reg = <0x220000 0x4000>;
+ ti,davinci-ctrl-reg-offset = <0x3000>;
+ ti,davinci-ctrl-mod-reg-offset = <0x2000>;
+ ti,davinci-ctrl-ram-offset = <0>;
+ ti,davinci-ctrl-ram-size = <0x2000>;
+ local-mac-address = [ 00 00 00 00 00 00 ];
+ interrupts = <33
+ 34
+ 35
+ 36
+ >;
+ };
};
nand_cs3@62000000 {
compatible = "ti,davinci-nand";
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 3/5] ARM: davinci: da850: add OF_DEV_AUXDATA entry for mdio.
From: Lad, Prabhakar @ 2013-08-15 6:01 UTC (permalink / raw)
To: Sekhar Nori
Cc: DLOS, LKML, devicetree-discuss, linux-arm-kernel, netdev,
Lad, Prabhakar
In-Reply-To: <1376546497-26931-1-git-send-email-prabhakar.csengg@gmail.com>
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Add OF_DEV_AUXDATA for mdio driver in da850 board dt
file to use mdio clock.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Changes for v2: none
Changes for v3: none
Changes for v4: none
arch/arm/mach-davinci/da8xx-dt.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/da8xx-dt.c b/arch/arm/mach-davinci/da8xx-dt.c
index 9683cbd..d172563 100644
--- a/arch/arm/mach-davinci/da8xx-dt.c
+++ b/arch/arm/mach-davinci/da8xx-dt.c
@@ -43,6 +43,7 @@ static struct of_dev_auxdata da850_auxdata_lookup[] __initdata = {
OF_DEV_AUXDATA("ns16550a", 0x01c42000, "serial8250.0", NULL),
OF_DEV_AUXDATA("ns16550a", 0x01d0c000, "serial8250.1", NULL),
OF_DEV_AUXDATA("ns16550a", 0x01d0d000, "serial8250.2", NULL),
+ OF_DEV_AUXDATA("ti,davinci_mdio", 0x01e24000, "davinci_mdio.0", NULL),
{}
};
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 2/5] ARM: davinci: da850: add DT node for mdio device
From: Lad, Prabhakar @ 2013-08-15 6:01 UTC (permalink / raw)
To: Sekhar Nori
Cc: DLOS, LKML, devicetree-discuss, linux-arm-kernel, netdev,
Lad, Prabhakar
In-Reply-To: <1376546497-26931-1-git-send-email-prabhakar.csengg@gmail.com>
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
Add mdio device tree node information to da850 by
providing register details and bus frequency of mdio.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
Changes for v2: none
Changes for v3:
a> Added pin entries for mdio.
Changes for v4: none
arch/arm/boot/dts/da850-evm.dts | 6 ++++++
arch/arm/boot/dts/da850.dtsi | 13 +++++++++++++
2 files changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 5bce7cc..1f8cfdd 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -90,6 +90,12 @@
};
};
};
+ mdio: mdio@1e24000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&mdio_pins>;
+ bus_freq = <2200000>;
+ };
};
nand_cs3@62000000 {
status = "okay";
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index 5f7e79a..d5138b4 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -125,6 +125,13 @@
0x14 0x00000010 0x000000f0
>;
};
+ mdio_pins: pinmux_mdio_pins {
+ pinctrl-single,bits = <
+ /* MDIO_CLK, MDIO_D */
+ 0x10 0x00000088 0x000000ff
+ >;
+ };
+
};
serial0: serial@1c42000 {
compatible = "ns16550a";
@@ -213,6 +220,12 @@
interrupts = <56>;
status = "disabled";
};
+ mdio: mdio@1e24000 {
+ compatible = "ti,davinci_mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0x224000 0x1000>;
+ };
};
nand_cs3@62000000 {
compatible = "ti,davinci-nand";
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 1/5] ARM: davinci: fix clock lookup for mdio device
From: Lad, Prabhakar @ 2013-08-15 6:01 UTC (permalink / raw)
To: Sekhar Nori
Cc: DLOS, LKML, devicetree-discuss, linux-arm-kernel, netdev,
Lad, Prabhakar
In-Reply-To: <1376546497-26931-1-git-send-email-prabhakar.csengg@gmail.com>
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
This patch removes the clock alias for mdio device and adds a entry
in clock lookup table, this entry can now be used by both DT and NON
DT case.
Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com>
---
changes for v2: None
Changes for v3:
a> added clock lookup entry for davinci_mdio in da830 file.
Changes for v4:
a> added clock lookup entry for all davinci devices.
arch/arm/mach-davinci/da830.c | 1 +
arch/arm/mach-davinci/da850.c | 1 +
arch/arm/mach-davinci/devices-da8xx.c | 8 ++------
arch/arm/mach-davinci/dm365.c | 3 +--
arch/arm/mach-davinci/dm644x.c | 3 +--
arch/arm/mach-davinci/dm646x.c | 3 +--
6 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/da830.c b/arch/arm/mach-davinci/da830.c
index 111613b..d6c746e 100644
--- a/arch/arm/mach-davinci/da830.c
+++ b/arch/arm/mach-davinci/da830.c
@@ -417,6 +417,7 @@ static struct clk_lookup da830_clks[] = {
CLK(NULL, "aintc", &aintc_clk),
CLK(NULL, "secu_mgr", &secu_mgr_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
+ CLK("davinci_mdio.0", "fck", &emac_clk),
CLK(NULL, "gpio", &gpio_clk),
CLK("i2c_davinci.2", NULL, &i2c1_clk),
CLK(NULL, "usb11", &usb11_clk),
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 5ef37f9..f56e5fb 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -461,6 +461,7 @@ static struct clk_lookup da850_clks[] = {
CLK(NULL, "arm", &arm_clk),
CLK(NULL, "rmii", &rmii_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
+ CLK("davinci_mdio.0", "fck", &emac_clk),
CLK("davinci-mcasp.0", NULL, &mcasp_clk),
CLK("da8xx_lcdc.0", "fck", &lcdc_clk),
CLK("da830-mmc.0", NULL, &mmcsd0_clk),
diff --git a/arch/arm/mach-davinci/devices-da8xx.c b/arch/arm/mach-davinci/devices-da8xx.c
index 280f67d..a408b30 100644
--- a/arch/arm/mach-davinci/devices-da8xx.c
+++ b/arch/arm/mach-davinci/devices-da8xx.c
@@ -481,12 +481,8 @@ int __init da8xx_register_emac(void)
ret = platform_device_register(&da8xx_mdio_device);
if (ret < 0)
return ret;
- ret = platform_device_register(&da8xx_emac_device);
- if (ret < 0)
- return ret;
- ret = clk_add_alias(NULL, dev_name(&da8xx_mdio_device.dev),
- NULL, &da8xx_emac_device.dev);
- return ret;
+
+ return platform_device_register(&da8xx_emac_device);
}
static struct resource da830_mcasp1_resources[] = {
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 3a039bc..278080d 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -477,6 +477,7 @@ static struct clk_lookup dm365_clks[] = {
CLK(NULL, "timer3", &timer3_clk),
CLK(NULL, "usb", &usb_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
+ CLK("davinci_mdio.0", "fck", &emac_clk),
CLK("davinci_voicecodec", NULL, &voicecodec_clk),
CLK("davinci-mcbsp", NULL, &asp0_clk),
CLK(NULL, "rto", &rto_clk),
@@ -1422,8 +1423,6 @@ static int __init dm365_init_devices(void)
platform_device_register(&dm365_mdio_device);
platform_device_register(&dm365_emac_device);
- clk_add_alias(NULL, dev_name(&dm365_mdio_device.dev),
- NULL, &dm365_emac_device.dev);
return 0;
}
diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-davinci/dm644x.c
index 23de0de..4f74682 100644
--- a/arch/arm/mach-davinci/dm644x.c
+++ b/arch/arm/mach-davinci/dm644x.c
@@ -307,6 +307,7 @@ static struct clk_lookup dm644x_clks[] = {
CLK("serial8250.1", NULL, &uart1_clk),
CLK("serial8250.2", NULL, &uart2_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
+ CLK("davinci_mdio.0", "fck", &emac_clk),
CLK("i2c_davinci.1", NULL, &i2c_clk),
CLK("palm_bk3710", NULL, &ide_clk),
CLK("davinci-mcbsp", NULL, &asp_clk),
@@ -950,8 +951,6 @@ static int __init dm644x_init_devices(void)
platform_device_register(&dm644x_mdio_device);
platform_device_register(&dm644x_emac_device);
- clk_add_alias(NULL, dev_name(&dm644x_mdio_device.dev),
- NULL, &dm644x_emac_device.dev);
return 0;
}
diff --git a/arch/arm/mach-davinci/dm646x.c b/arch/arm/mach-davinci/dm646x.c
index 4b25804..68f8d1f 100644
--- a/arch/arm/mach-davinci/dm646x.c
+++ b/arch/arm/mach-davinci/dm646x.c
@@ -351,6 +351,7 @@ static struct clk_lookup dm646x_clks[] = {
CLK("davinci-mcasp.1", NULL, &mcasp1_clk),
CLK(NULL, "aemif", &aemif_clk),
CLK("davinci_emac.1", NULL, &emac_clk),
+ CLK("davinci_mdio.0", "fck", &emac_clk),
CLK(NULL, "pwm0", &pwm0_clk),
CLK(NULL, "pwm1", &pwm1_clk),
CLK(NULL, "timer0", &timer0_clk),
@@ -940,8 +941,6 @@ static int __init dm646x_init_devices(void)
platform_device_register(&dm646x_mdio_device);
platform_device_register(&dm646x_emac_device);
- clk_add_alias(NULL, dev_name(&dm646x_mdio_device.dev),
- NULL, &dm646x_emac_device.dev);
return 0;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH v4 0/5] ARM: davinci: da850: add ethernet driver DT support
From: Lad, Prabhakar @ 2013-08-15 6:01 UTC (permalink / raw)
To: Sekhar Nori
Cc: DLOS, LKML, devicetree-discuss, linux-arm-kernel, netdev,
Lad, Prabhakar
From: "Lad, Prabhakar" <prabhakar.csengg@gmail.com>
This patch set enables Ethernet support through device tree model.
This patch set enables mii interface only and is being tested to boot via
rootfs. The rmii phy is present on the i2c gpio expander chip (UI board)
for which yet support needs to be added, once the DT support for the chip
is enabled, enabling rmii will be subsequnet patch.
Changes for v2:
1: Enabled mdio device.
2: Fixed clock lookup.
Changes for v3:
1: Fixed review comments pointed out by Sekhar.
Changes for v4:
1: Fixed review comments pointed out by Sekhar.
2: Dropped patch v3 6/6 (https://patchwork.kernel.org/patch/2768361/)
Which depends on adding GPIO DT node, will address it once GPIO support is added.
3: Rebased the patches on [1]
[1] https://git.kernel.org/cgit/linux/kernel/git/nsekhar/linux-davinci.git/log/?h=v3.12/soc
Lad, Prabhakar (5):
ARM: davinci: fix clock lookup for mdio device
ARM: davinci: da850: add DT node for mdio device
ARM: davinci: da850: add OF_DEV_AUXDATA entry for mdio.
ARM: davinci: da850: add DT node for eth0.
ARM: davinci: da850: add OF_DEV_AUXDATA entry for eth0.
arch/arm/boot/dts/da850-evm.dts | 11 +++++++++
arch/arm/boot/dts/da850.dtsi | 43 +++++++++++++++++++++++++++++++++
arch/arm/mach-davinci/da830.c | 1 +
arch/arm/mach-davinci/da850.c | 1 +
arch/arm/mach-davinci/da8xx-dt.c | 4 +++
arch/arm/mach-davinci/devices-da8xx.c | 8 ++----
arch/arm/mach-davinci/dm365.c | 3 +--
arch/arm/mach-davinci/dm644x.c | 3 +--
arch/arm/mach-davinci/dm646x.c | 3 +--
9 files changed, 65 insertions(+), 12 deletions(-)
--
1.7.9.5
^ permalink raw reply
* [patch 3/2] libceph: create_singlethread_workqueue() doesn't return ERR_PTRs
From: Dan Carpenter @ 2013-08-15 5:58 UTC (permalink / raw)
To: Sage Weil; +Cc: David S. Miller, ceph-devel, netdev, kernel-janitors
create_singlethread_workqueue() returns NULL on error, and it doesn't
return ERR_PTRs.
I tweaked the error handling a little to be consistent with earlier in
the function.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
index dbc0a73..02c5246 100644
--- a/net/ceph/osd_client.c
+++ b/net/ceph/osd_client.c
@@ -2257,12 +2257,10 @@ int ceph_osdc_init(struct ceph_osd_client *osdc, struct ceph_client *client)
if (err < 0)
goto out_msgpool;
+ err = -ENOMEM;
osdc->notify_wq = create_singlethread_workqueue("ceph-watch-notify");
- if (IS_ERR(osdc->notify_wq)) {
- err = PTR_ERR(osdc->notify_wq);
- osdc->notify_wq = NULL;
+ if (!osdc->notify_wq)
goto out_msgpool;
- }
return 0;
out_msgpool:
^ permalink raw reply related
* [patch 2/2] libceph: potential NULL dereference in ceph_osdc_handle_map()
From: Dan Carpenter @ 2013-08-15 5:52 UTC (permalink / raw)
To: Sage Weil; +Cc: David S. Miller, ceph-devel, netdev, kernel-janitors
There are two places where we read "nr_maps" if both of them are set to
zero then we would hit a NULL dereference here.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
---
I think this is a real bug, but please review my fix for it because I'm
not very familiar with this code.
diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
index 559a832..56f1fe5 100644
--- a/net/ceph/osd_client.c
+++ b/net/ceph/osd_client.c
@@ -1786,6 +1786,8 @@ void ceph_osdc_handle_map(struct ceph_osd_client *osdc, struct ceph_msg *msg)
nr_maps--;
}
+ if (!osdc->osdmap)
+ goto bad;
done:
downgrade_write(&osdc->map_sem);
ceph_monc_got_osdmap(&osdc->client->monc, osdc->osdmap->epoch);
^ permalink raw reply related
* [patch 1/2] libceph: fix error handling in handle_reply()
From: Dan Carpenter @ 2013-08-15 5:51 UTC (permalink / raw)
To: Sage Weil; +Cc: David S. Miller, ceph-devel, netdev, kernel-janitors
We've tried to fix the error paths in this function before, but there
is still a hidden goto in the ceph_decode_need() macro which goes to the
wrong place. We need to release the "req" and unlock a mutex before
returning.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/net/ceph/osd_client.c b/net/ceph/osd_client.c
index dbc0a73..559a832 100644
--- a/net/ceph/osd_client.c
+++ b/net/ceph/osd_client.c
@@ -1488,14 +1488,14 @@ static void handle_reply(struct ceph_osd_client *osdc, struct ceph_msg *msg,
dout("handle_reply %p tid %llu req %p result %d\n", msg, tid,
req, result);
- ceph_decode_need(&p, end, 4, bad);
+ ceph_decode_need(&p, end, 4, bad_put);
numops = ceph_decode_32(&p);
if (numops > CEPH_OSD_MAX_OP)
goto bad_put;
if (numops != req->r_num_ops)
goto bad_put;
payload_len = 0;
- ceph_decode_need(&p, end, numops * sizeof(struct ceph_osd_op), bad);
+ ceph_decode_need(&p, end, numops * sizeof(struct ceph_osd_op), bad_put);
for (i = 0; i < numops; i++) {
struct ceph_osd_op *op = p;
int len;
@@ -1513,7 +1513,7 @@ static void handle_reply(struct ceph_osd_client *osdc, struct ceph_msg *msg,
goto bad_put;
}
- ceph_decode_need(&p, end, 4 + numops * 4, bad);
+ ceph_decode_need(&p, end, 4 + numops * 4, bad_put);
retry_attempt = ceph_decode_32(&p);
for (i = 0; i < numops; i++)
req->r_reply_op_result[i] = ceph_decode_32(&p);
^ permalink raw reply related
* Re: TCP Connection teardown seems to violate TCP specification
From: Damian Lukowski @ 2013-08-15 5:32 UTC (permalink / raw)
To: Rick Jones; +Cc: Yuchung Cheng, netdev
In-Reply-To: <520BF8EB.4060800@hp.com>
Hi,
thanks for the elaborate answer. I put too much focus on the TCP state
diagram. Now I also found the passages in the RFCs.
RFC-793 states that "users must keep reading connections they close for
sending until the TCP says no more data", and RFC-1122 says
"If such a host issues a CLOSE call while received data is still
pending in TCP, or if new data is received after CLOSE is called,
its TCP SHOULD send a RST to show that data was lost".
So those RSTs are valid, and wget/curl don't read outstanding data
where they should.
Best regards
Damian
Am Mittwoch, den 14.08.2013, 14:38 -0700 schrieb Rick Jones:
> On 08/14/2013 02:18 PM, Damian Lukowski wrote:
> > At least in curl, the close() seems to be implicit as it occurs
> > at the very end of the trace:
> >
> > close(3) = 0
> > exit_group(0) = ?
> > +++ exited with 0 +++
> >
> > Nevertheless, shouldn't the stack keep on reading the input
> > even if the local application is not interested in it?
> > The other side might rely on it, and I've seen webserver logs
> > which indicate SSL read errors likely because of this.
>
> Ignoring for a moment the SSL matter, if you get a tutorial on (BSD)
> sockets or a copy of the works of the likes of the late W. Richard
> Stevens you will find that the semantics of close() are such that there
> is no way for the received data to be consumed by an application - it no
> longer has a reference to the socket, so to where can the data go?
>
> If then data arrives, what is TCP to do? Clearly, from the standpoint
> of TCP, something is amiss. The local application has indicated it is
> not expecting any more data (by calling close()) and more data has
> arrived. TCP could discard the data and not ACK it, which would simply
> leave the remote TCP retransmitting until a limit was reached at the
> remote. TCP could bit-bucket the data and send-back ACKs, but that is
> giving a false sense of "success" to the remote application. So, TCP
> does the only thing it can do - it sends a Reset (RST) segment back to
> the sender. This then is an indication that something went wrong - in
> this case there was an application-layer error. Sadly, TCP has no way
> to say that rather than some other TCP-level error - it has just the one
> RST bit.
>
> If the other side relies on the data it is sending being consumed, and
> the local side close()es, that is an indication of an application-layer
> failure - they did not "handshake" their goodbye correctly.
>
> Also, close() is not the half-close of which you read in the TCP RFC.
> In the BSD Sockets interface (not to be confused with the "sockets"
> mentioned in the RFC) the call one makes to effect a half-close of a
> connection is shutdown(SHUT_WR). In that case, the application retains
> a reference to the socket, and so can consume data until the remote end
> itself then calls either SHUTDOWN(SHUT_WR) or close() (close() being OK
> here at the remote because the connection is already half-closed so the
> remote isn't going to be receiving any data in the first place).
>
> So, at the client side or more accurately the side initiating TCP
> connection shutdown the sequence should be something like:
>
> 1) shutdown(SHUT_WR) - this will cause TCP to send a FINished segment to
> the remote TCP, and the remote TCP will indicate this to the remote
> application via a read return of zero.
> 2) wait for a read return of zero, perhaps bit bucketing data - this
> read return of zero will indicate that the remote application has gotten
> the notification and has itself closed
> 3) close()
>
> Now, step two can be ever so slightly problematic - how long to wait?
>
> As for SSL... I cannot begin to pretend to be an SSL protocol expert,
> but in looking at some traces recently, and at one of the more recent
> RFCs, I think they have a slight hole in their specification. The
> (current?) spec says that an SSL Close Notify alert message is to be
> sent (exchanged?) when terminating the SSL session. The specs also say
> that a client can just send the Close Notify and go away. (eg a close -
> implicit or explicit)
>
> Trouble is, the remote side will want to send a Close Notify of its own.
> If the client has Close Notified and scooted, or even just close()ed
> without a Close Notify sent, the remote/server's Close Notify will hit
> the client's TCP stack and elicit a RST segment. Even better is when
> there is a statefull firewall between client and server, which then
> closes-off the four-tuple. If that RST is lost on the way back to the
> server, the server TCP will continue retransmitting the Close Notify
> message, which will hit the firewall and be dropped. The firewall may
> then log "Hey, I dropped this packet trying to get in" entries for each
> of those retransmissions, which then may cause people looking at said
> logs to become "concerned..."
>
> rick jones
>
^ permalink raw reply
* Re: [PATCHv2 net-next] 6lowpan: handle only real link-local addresses
From: Alexander Aring @ 2013-08-15 4:57 UTC (permalink / raw)
To: David Miller
Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev
In-Reply-To: <20130814.171825.944941726261089646.davem@davemloft.net>
Hi David,
On Wed, Aug 14, 2013 at 05:18:25PM -0700, David Miller wrote:
> From: Alexander Aring <alex.aring@gmail.com>
> Date: Wed, 14 Aug 2013 23:17:01 +0200
>
> > Ok, please let me know what should I do to submit it properly.
>
> What you don't understand is that just because patches aren't
> related doesn't mean that their order of application doesn't
> matter.
>
Ok. I got the information on an other mailinglist that I should
not mix "features" and "fixes" in a single series. Then I just
try to seperate...
My first patch-serie included all patches in a single series.
> So you put all the patches into a full series so that there is no
> ambiguity as to what order the patches are to be applied.
>
Ok.
> Do not ever seperate patches when you are submitting changes to the
> same exact files at one time.
Ok, I will remember it.
Thanks and apologize for the inconvenience
Regards
Alex
^ permalink raw reply
* Re: [PATCH net-next] ipv4,ipv6: send arp/ndisc packets with TC_PRIO_CONTROL
From: Hannes Frederic Sowa @ 2013-08-15 3:56 UTC (permalink / raw)
To: netdev, bcrl; +Cc: dave.taht
In-Reply-To: <20130814233412.GC13066@order.stressinduktion.org>
On Thu, Aug 15, 2013 at 01:34:12AM +0200, Hannes Frederic Sowa wrote:
> We already did this change for igmp/mld packets in commit
> 9d4a0314642918cbda9ed4012df51e8df608fce6 ("ipv4, ipv6: send igmpv3/mld
> packets with TC_PRIO_CONTROL").
>
> arp and ndisc are as important as mld/igmp for a working network, so
> make the appropriate change here, too.
>
> Cc: Benjamin LaHaise <bcrl@kvack.org>
> Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
I would like to downgrade this patch from tag net-next to RFC.
After Dave Taht talked to me, I realized that this change could have drastic
impact on how packets could starve in various qdiscs if a router is last hop
for a ping scan.
Please postpone this patch until I did more research. Comments are welcome,
too.
Thanks,
Hannes
^ permalink raw reply
* [PATCH] vhost: Drop linux/socket.h
From: Asias He @ 2013-08-15 3:20 UTC (permalink / raw)
To: netdev; +Cc: virtualization, kvm, Michael S. Tsirkin
memcpy_fromiovec is moved to lib/iovec.c. No need to include
linux/socket.h for it.
Signed-off-by: Asias He <asias@redhat.com>
---
drivers/vhost/vhost.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index e58cf00..038c242 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -13,7 +13,6 @@
#include <linux/eventfd.h>
#include <linux/vhost.h>
-#include <linux/socket.h> /* memcpy_fromiovec */
#include <linux/mm.h>
#include <linux/mmu_context.h>
#include <linux/miscdevice.h>
--
1.8.3.1
^ permalink raw reply related
* Re: [Patch net-next] net: sync some IP headers with glibc
From: Cong Wang @ 2013-08-15 2:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, tmb, libc-alpha, yoshfuji, carlos
In-Reply-To: <20130814.134246.1152657041177088716.davem@davemloft.net>
On Wed, 2013-08-14 at 13:42 -0700, David Miller wrote:
> From: Cong Wang <amwang@redhat.com>
> Date: Tue, 13 Aug 2013 16:37:33 +0800
>
> > @@ -23,31 +23,54 @@
> >
> > /* Standard well-defined IP protocols. */
> > enum {
> > - IPPROTO_IP = 0, /* Dummy protocol for TCP */
> > - IPPROTO_ICMP = 1, /* Internet Control Message Protocol */
>
> > + IPPROTO_IP = 0, /* Dummy protocol for TCP. */
>
> Please don't do unrelated things like reformat comments, it makes the
> path much harder to audit.
OK.
>
> > -
> > +#if __UAPI_DEF_IN6_ADDR
> > struct in6_addr {
> > union {
> > __u8 u6_addr8[16];
> > +#if __UAPI_DEF_IN6_ADDR
> > __be16 u6_addr16[8];
>
> The same CPP test twice inside of itself, the second test seems
> superfluous. I bet this second one was supposed to be
> __UAPI_DEF_IN6_ADDR_ALT instead of __UAPI_DEF_IN6_ADDR.
Indeed.
>
> > -#define IPPROTO_HOPOPTS 0 /* IPv6 hop-by-hop options */
> > -#define IPPROTO_ROUTING 43 /* IPv6 routing header */
> > -#define IPPROTO_FRAGMENT 44 /* IPv6 fragmentation header */
> > -#define IPPROTO_ICMPV6 58 /* ICMPv6 */
> > -#define IPPROTO_NONE 59 /* IPv6 no next header */
> > -#define IPPROTO_DSTOPTS 60 /* IPv6 destination options */
> > -#define IPPROTO_MH 135 /* IPv6 mobility header */
> > +#if __UAPI_DEF_IPPROTO_V6
> > +enum {
> > + IPPROTO_HOPOPTS = 0, /* IPv6 hop-by-hop options */
>
> Again, do not reformat things, it's an unrelated change and makes
> this patch harder to review.
Ok.
I will update the patch.
Thanks!
^ permalink raw reply
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
From: Ding Tianhong @ 2013-08-15 2:16 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev, kargig, ppandit
In-Reply-To: <20130815012457.GD13066@order.stressinduktion.org>
On 2013/8/15 9:24, Hannes Frederic Sowa wrote:
> On Thu, Aug 15, 2013 at 08:43:06AM +0800, Ding Tianhong wrote:
>> On 2013/8/14 18:15, Hannes Frederic Sowa wrote:
>>> On Wed, Aug 14, 2013 at 05:06:54PM +0800, Ding Tianhong wrote:
>>>> A LAN user can remotely disable temporary address which may lead
>>>> to privacy violatins and information disclosure.
>>>>
>>>> The reason is that the linux kernel uses the 'ipv6.max_addresses'
>>>> option to specify how many ipv6 addresses and interface may have.
>>>> The 'ipv6.regen_max_retry' (default value 3) option specifies
>>>> how many times the kernel will try to create a new address.
>>>>
>>>> But the kernel is not distinguish between the event of reaching
>>>> max_addresses for an interface and failing to generate a new address.
>>>> the kernel disable the temporary address after regenerate a new
>>>> address 'regen_max_retry' times.
>>>>
>>>> According RFC4941 3.3.7:
>>>>
>>>> ---------------------------------------
>>>>
>>>> If DAD indicates the address is already in use,
>>>> the node must generate a new randomized interface
>>>> identifier as described in section 3.2 above, and
>>>> repeat the previous steps as appropriate up to
>>>> TEMP_IDGEN_RETRIES times.
>>>>
>>>> If after TEMP_IDGEN_RETRIES consecutive attempts no
>>>> non-unique address was generated, the node must log
>>>> a system error and must not attempt to generate
>>>> temporary address for that interface.
>>>>
>>>> ------------------------------------------
>>>>
>>>> RFC4941 3.3.7 specifies that disabling the temp_address must happen
>>>> upon the address is already in use, not reach the max_address,
>>>> So we have to check the return err and distinguish the correct retry path.
>>>>
>>>> This fixes CVE-2013-0343
>>>
>>> I don't think this patch fixes CVE-2013-0343.
>>>
>>>>
>>>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>>>> Tested-by: Wang Weidong <wangweidong1@huawei.com>
>>>> Cc: David S. Miller <davem@davemloft.net>
>>>> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>>>> Cc: Eric Dumazet <edumazet@google.com>
>>>> ---
>>>> net/ipv6/addrconf.c | 26 ++++++++++++++++++++++----
>>>> 1 file changed, 22 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>>>> index da4241c..7b55464 100644
>>>> --- a/net/ipv6/addrconf.c
>>>> +++ b/net/ipv6/addrconf.c
>>>> @@ -1134,10 +1134,28 @@ retry:
>>>> if (IS_ERR_OR_NULL(ift)) {
>>>> in6_ifa_put(ifp);
>>>> in6_dev_put(idev);
>>>> - pr_info("%s: retry temporary address regeneration\n", __func__);
>>>> - tmpaddr = &addr;
>>>> - write_lock(&idev->lock);
>>>> - goto retry;
>>>> +
>>>> + /* According RFC4941 3.3.7:
>>>> + * If DAD indicates the address is already in use,
>>>> + * the node must generate a new randomized interface
>>>> + * identifier as described in section 3.2 above, and
>>>> + * repeat the previous steps as appropriate up to
>>>> + * TEMP_IDGEN_RETRIES times.
>>>> + * If after TEMP_IDGEN_RETRIES consecutive attempts no
>>>> + * non-unique address was generated, the node must log
>>>> + * a system error and must not attempt to generate
>>>> + * temporary address for that interface.
>>>> + * So we have to check the return err and distinguish
>>>> + * the correct retry path.
>>>> + */
>>>> + if (PTR_ERR(ift) == -EEXIST) {
>>>
>>> -EEXIST is not the same as "ipv6 address is is already used on the
>>> subnet". I really don't see the point here. IMHO this breaks the intended
>>> regeneration logic.
>>>
>>> I fear a fix of CVE-2013-0343 will be a bit more complicated. ;) I give it a
>>> thought.
>>>
>>> Greetings,
>>>
>>> Hannes
>>>
>>>
>> ok, thanks for your feedback, I'll waiting you for more information to fix the problem.:)
>
> [added George Kargiotakis and P J P to Cc and full quote]
>
> I wonder if the easiest solution would be to just drop the max_addresses
> limit from ipv6_create_tempaddr. max_addresses protects the kernel from
> installing an unlimited amount of addresses on an interface which gets flooded
> by RAs. Because we have a direct relation between interface address to temp
> address, I don't see that we would create the possiblity of DoS.
>
> Sure, an audit and testing is needed.
>
> Greetings,
>
> Hannes
>
I am afraid that if remove the max limit from the ipv6_create_tempaddr, the tool flood_route26 attack will create huge address to the temp_list, it will be a huge list,
may it destroy something or not?
Best regards
Ding Tianhong
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> .
>
^ permalink raw reply
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
From: Hannes Frederic Sowa @ 2013-08-15 1:24 UTC (permalink / raw)
To: Ding Tianhong
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev, kargig, ppandit
In-Reply-To: <520C241A.2030708@huawei.com>
On Thu, Aug 15, 2013 at 08:43:06AM +0800, Ding Tianhong wrote:
> On 2013/8/14 18:15, Hannes Frederic Sowa wrote:
> > On Wed, Aug 14, 2013 at 05:06:54PM +0800, Ding Tianhong wrote:
> >> A LAN user can remotely disable temporary address which may lead
> >> to privacy violatins and information disclosure.
> >>
> >> The reason is that the linux kernel uses the 'ipv6.max_addresses'
> >> option to specify how many ipv6 addresses and interface may have.
> >> The 'ipv6.regen_max_retry' (default value 3) option specifies
> >> how many times the kernel will try to create a new address.
> >>
> >> But the kernel is not distinguish between the event of reaching
> >> max_addresses for an interface and failing to generate a new address.
> >> the kernel disable the temporary address after regenerate a new
> >> address 'regen_max_retry' times.
> >>
> >> According RFC4941 3.3.7:
> >>
> >> ---------------------------------------
> >>
> >> If DAD indicates the address is already in use,
> >> the node must generate a new randomized interface
> >> identifier as described in section 3.2 above, and
> >> repeat the previous steps as appropriate up to
> >> TEMP_IDGEN_RETRIES times.
> >>
> >> If after TEMP_IDGEN_RETRIES consecutive attempts no
> >> non-unique address was generated, the node must log
> >> a system error and must not attempt to generate
> >> temporary address for that interface.
> >>
> >> ------------------------------------------
> >>
> >> RFC4941 3.3.7 specifies that disabling the temp_address must happen
> >> upon the address is already in use, not reach the max_address,
> >> So we have to check the return err and distinguish the correct retry path.
> >>
> >> This fixes CVE-2013-0343
> >
> > I don't think this patch fixes CVE-2013-0343.
> >
> >>
> >> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
> >> Tested-by: Wang Weidong <wangweidong1@huawei.com>
> >> Cc: David S. Miller <davem@davemloft.net>
> >> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
> >> Cc: Eric Dumazet <edumazet@google.com>
> >> ---
> >> net/ipv6/addrconf.c | 26 ++++++++++++++++++++++----
> >> 1 file changed, 22 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> >> index da4241c..7b55464 100644
> >> --- a/net/ipv6/addrconf.c
> >> +++ b/net/ipv6/addrconf.c
> >> @@ -1134,10 +1134,28 @@ retry:
> >> if (IS_ERR_OR_NULL(ift)) {
> >> in6_ifa_put(ifp);
> >> in6_dev_put(idev);
> >> - pr_info("%s: retry temporary address regeneration\n", __func__);
> >> - tmpaddr = &addr;
> >> - write_lock(&idev->lock);
> >> - goto retry;
> >> +
> >> + /* According RFC4941 3.3.7:
> >> + * If DAD indicates the address is already in use,
> >> + * the node must generate a new randomized interface
> >> + * identifier as described in section 3.2 above, and
> >> + * repeat the previous steps as appropriate up to
> >> + * TEMP_IDGEN_RETRIES times.
> >> + * If after TEMP_IDGEN_RETRIES consecutive attempts no
> >> + * non-unique address was generated, the node must log
> >> + * a system error and must not attempt to generate
> >> + * temporary address for that interface.
> >> + * So we have to check the return err and distinguish
> >> + * the correct retry path.
> >> + */
> >> + if (PTR_ERR(ift) == -EEXIST) {
> >
> > -EEXIST is not the same as "ipv6 address is is already used on the
> > subnet". I really don't see the point here. IMHO this breaks the intended
> > regeneration logic.
> >
> > I fear a fix of CVE-2013-0343 will be a bit more complicated. ;) I give it a
> > thought.
> >
> > Greetings,
> >
> > Hannes
> >
> >
> ok, thanks for your feedback, I'll waiting you for more information to fix the problem.:)
[added George Kargiotakis and P J P to Cc and full quote]
I wonder if the easiest solution would be to just drop the max_addresses
limit from ipv6_create_tempaddr. max_addresses protects the kernel from
installing an unlimited amount of addresses on an interface which gets flooded
by RAs. Because we have a direct relation between interface address to temp
address, I don't see that we would create the possiblity of DoS.
Sure, an audit and testing is needed.
Greetings,
Hannes
^ permalink raw reply
* Re: [PATCH 1/3 v4] ipv6: do not disable temp_address when reaching max_address
From: Ding Tianhong @ 2013-08-15 0:43 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Jon Maloy, Eric Dumazet,
Netdev
In-Reply-To: <20130814101511.GC16264@order.stressinduktion.org>
On 2013/8/14 18:15, Hannes Frederic Sowa wrote:
> On Wed, Aug 14, 2013 at 05:06:54PM +0800, Ding Tianhong wrote:
>> A LAN user can remotely disable temporary address which may lead
>> to privacy violatins and information disclosure.
>>
>> The reason is that the linux kernel uses the 'ipv6.max_addresses'
>> option to specify how many ipv6 addresses and interface may have.
>> The 'ipv6.regen_max_retry' (default value 3) option specifies
>> how many times the kernel will try to create a new address.
>>
>> But the kernel is not distinguish between the event of reaching
>> max_addresses for an interface and failing to generate a new address.
>> the kernel disable the temporary address after regenerate a new
>> address 'regen_max_retry' times.
>>
>> According RFC4941 3.3.7:
>>
>> ---------------------------------------
>>
>> If DAD indicates the address is already in use,
>> the node must generate a new randomized interface
>> identifier as described in section 3.2 above, and
>> repeat the previous steps as appropriate up to
>> TEMP_IDGEN_RETRIES times.
>>
>> If after TEMP_IDGEN_RETRIES consecutive attempts no
>> non-unique address was generated, the node must log
>> a system error and must not attempt to generate
>> temporary address for that interface.
>>
>> ------------------------------------------
>>
>> RFC4941 3.3.7 specifies that disabling the temp_address must happen
>> upon the address is already in use, not reach the max_address,
>> So we have to check the return err and distinguish the correct retry path.
>>
>> This fixes CVE-2013-0343
>
> I don't think this patch fixes CVE-2013-0343.
>
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> Tested-by: Wang Weidong <wangweidong1@huawei.com>
>> Cc: David S. Miller <davem@davemloft.net>
>> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
>> Cc: Eric Dumazet <edumazet@google.com>
>> ---
>> net/ipv6/addrconf.c | 26 ++++++++++++++++++++++----
>> 1 file changed, 22 insertions(+), 4 deletions(-)
>>
>> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
>> index da4241c..7b55464 100644
>> --- a/net/ipv6/addrconf.c
>> +++ b/net/ipv6/addrconf.c
>> @@ -1134,10 +1134,28 @@ retry:
>> if (IS_ERR_OR_NULL(ift)) {
>> in6_ifa_put(ifp);
>> in6_dev_put(idev);
>> - pr_info("%s: retry temporary address regeneration\n", __func__);
>> - tmpaddr = &addr;
>> - write_lock(&idev->lock);
>> - goto retry;
>> +
>> + /* According RFC4941 3.3.7:
>> + * If DAD indicates the address is already in use,
>> + * the node must generate a new randomized interface
>> + * identifier as described in section 3.2 above, and
>> + * repeat the previous steps as appropriate up to
>> + * TEMP_IDGEN_RETRIES times.
>> + * If after TEMP_IDGEN_RETRIES consecutive attempts no
>> + * non-unique address was generated, the node must log
>> + * a system error and must not attempt to generate
>> + * temporary address for that interface.
>> + * So we have to check the return err and distinguish
>> + * the correct retry path.
>> + */
>> + if (PTR_ERR(ift) == -EEXIST) {
>
> -EEXIST is not the same as "ipv6 address is is already used on the
> subnet". I really don't see the point here. IMHO this breaks the intended
> regeneration logic.
>
> I fear a fix of CVE-2013-0343 will be a bit more complicated. ;) I give it a
> thought.
>
> Greetings,
>
> Hannes
>
>
ok, thanks for your feedback, I'll waiting you for more information to fix the problem.:)
> .
>
^ permalink raw reply
* Re: TCP Connection teardown seems to violate TCP specification
From: David Miller @ 2013-08-15 0:19 UTC (permalink / raw)
To: damian; +Cc: rick.jones2, ycheng, netdev
In-Reply-To: <1376515097.9293.6.camel@nexus>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Wed, 14 Aug 2013 23:18:17 +0200
> Nevertheless, shouldn't the stack keep on reading the input
> even if the local application is not interested in it?
Absolutely, positively, not.
It is a loss of data, and therefore TCP responds with a reset when
pending read data is not consumed by the application.
^ permalink raw reply
* Re: [PATCHv2 net-next] 6lowpan: handle only real link-local addresses
From: David Miller @ 2013-08-15 0:18 UTC (permalink / raw)
To: alex.aring; +Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev
In-Reply-To: <20130814211658.GA2075@x61s.8.8.8.8>
From: Alexander Aring <alex.aring@gmail.com>
Date: Wed, 14 Aug 2013 23:17:01 +0200
> Ok, please let me know what should I do to submit it properly.
What you don't understand is that just because patches aren't
related doesn't mean that their order of application doesn't
matter.
So you put all the patches into a full series so that there is no
ambiguity as to what order the patches are to be applied.
Do not ever seperate patches when you are submitting changes to the
same exact files at one time.
^ permalink raw reply
* [PATCH net-next] ipv4,ipv6: send arp/ndisc packets with TC_PRIO_CONTROL
From: Hannes Frederic Sowa @ 2013-08-14 23:34 UTC (permalink / raw)
To: netdev; +Cc: bcrl
We already did this change for igmp/mld packets in commit
9d4a0314642918cbda9ed4012df51e8df608fce6 ("ipv4, ipv6: send igmpv3/mld
packets with TC_PRIO_CONTROL").
arp and ndisc are as important as mld/igmp for a working network, so
make the appropriate change here, too.
Cc: Benjamin LaHaise <bcrl@kvack.org>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
---
net/ipv4/arp.c | 2 ++
net/ipv6/ndisc.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 4429b01..4ed18371 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c
@@ -92,6 +92,7 @@
#include <linux/fddidevice.h>
#include <linux/if_arp.h>
#include <linux/skbuff.h>
+#include <linux/pkt_sched.h>
#include <linux/proc_fs.h>
#include <linux/seq_file.h>
#include <linux/stat.h>
@@ -594,6 +595,7 @@ struct sk_buff *arp_create(int type, int ptype, __be32 dest_ip,
skb_reset_network_header(skb);
arp = (struct arphdr *) skb_put(skb, arp_hdr_len(dev));
skb->dev = dev;
+ skb->priority = TC_PRIO_CONTROL;
skb->protocol = htons(ETH_P_ARP);
if (src_hw == NULL)
src_hw = dev->dev_addr;
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index 79aa965..007f868 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -50,6 +50,7 @@
#include <linux/ipv6.h>
#include <linux/icmpv6.h>
#include <linux/jhash.h>
+#include <linux/pkt_sched.h>
#include <net/sock.h>
#include <net/snmp.h>
@@ -382,7 +383,7 @@ static struct sk_buff *ndisc_alloc_skb(struct net_device *dev,
__func__, err);
return NULL;
}
-
+ skb->priority = TC_PRIO_CONTROL;
skb->protocol = htons(ETH_P_IPV6);
skb->dev = dev;
--
1.8.3.1
^ permalink raw reply related
* [PATCH net 2/3] openvswitch: Use correct type while allocating flex array.
From: Jesse Gross @ 2013-08-14 23:19 UTC (permalink / raw)
To: David Miller; +Cc: netdev, dev, Pravin B Shelar, Jesse Gross
In-Reply-To: <1376522347-39531-1-git-send-email-jesse@nicira.com>
From: Pravin B Shelar <pshelar@nicira.com>
Flex array is used to allocate hash buckets which is type struct
hlist_head, but we use `struct hlist_head *` to calculate
array size. Since hlist_head is of size pointer it works fine.
Following patch use correct type.
Signed-off-by: Pravin B Shelar <pshelar@nicira.com>
Signed-off-by: Jesse Gross <jesse@nicira.com>
---
net/openvswitch/flow.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/openvswitch/flow.c b/net/openvswitch/flow.c
index 5c519b1..1aa84dc 100644
--- a/net/openvswitch/flow.c
+++ b/net/openvswitch/flow.c
@@ -240,7 +240,7 @@ static struct flex_array *alloc_buckets(unsigned int n_buckets)
struct flex_array *buckets;
int i, err;
- buckets = flex_array_alloc(sizeof(struct hlist_head *),
+ buckets = flex_array_alloc(sizeof(struct hlist_head),
n_buckets, GFP_KERNEL);
if (!buckets)
return NULL;
--
1.8.1.2
^ permalink raw reply related
* [PATCH net 3/3] openvswitch: Reset tunnel key between input and output.
From: Jesse Gross @ 2013-08-14 23:19 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1376522347-39531-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
It doesn't make sense to output a tunnel packet using the same
parameters that it was received with since that will generally
just result in the packet going back to us. As a result, userspace
assumes that the tunnel key is cleared when transitioning through
the switch. In the majority of cases this doesn't matter since a
packet is either going to a tunnel port (in which the key is
overwritten with new values) or to a non-tunnel port (in which
case the key is ignored). However, it's theoreticaly possible that
userspace could rely on the documented behavior, so this corrects
it.
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/actions.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/openvswitch/actions.c b/net/openvswitch/actions.c
index 22c5f39..ab101f7 100644
--- a/net/openvswitch/actions.c
+++ b/net/openvswitch/actions.c
@@ -535,6 +535,7 @@ int ovs_execute_actions(struct datapath *dp, struct sk_buff *skb)
{
struct sw_flow_actions *acts = rcu_dereference(OVS_CB(skb)->flow->sf_acts);
+ OVS_CB(skb)->tun_key = NULL;
return do_execute_actions(dp, skb, acts->actions,
acts->actions_len, false);
}
--
1.8.1.2
^ permalink raw reply related
* [PATCH net 1/3] openvswitch: Fix bad merge resolution.
From: Jesse Gross @ 2013-08-14 23:19 UTC (permalink / raw)
To: David Miller; +Cc: dev-yBygre7rU0TnMu66kgdUjQ, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1376522347-39531-1-git-send-email-jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
git silently included an extra hunk in vport_cmd_set() during
automatic merging. This code is unreachable so it does not actually
introduce a problem but it is clearly incorrect.
Signed-off-by: Jesse Gross <jesse-l0M0P4e3n4LQT0dZR+AlfA@public.gmane.org>
---
net/openvswitch/datapath.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/net/openvswitch/datapath.c b/net/openvswitch/datapath.c
index f7e3a0d..f2ed760 100644
--- a/net/openvswitch/datapath.c
+++ b/net/openvswitch/datapath.c
@@ -2076,9 +2076,6 @@ static int ovs_vport_cmd_set(struct sk_buff *skb, struct genl_info *info)
ovs_notify(reply, info, &ovs_dp_vport_multicast_group);
return 0;
- rtnl_unlock();
- return 0;
-
exit_free:
kfree_skb(reply);
exit_unlock:
--
1.8.1.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox