* Re: [PATCH net] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
From: Hannes Frederic Sowa @ 2015-01-09 11:34 UTC (permalink / raw)
To: Rahul Sharma, Pablo Neira Ayuso; +Cc: netdev, linux-kernel, netfilter-devel
In-Reply-To: <CAFB3abwrjp61LLOk3RWwXYEq1g4QZUC8OTKuO2cAr+GbV3n4rw@mail.gmail.com>
On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
> Hi Pablo,
>
> On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso <pablo@netfilter.org>
> wrote:
> > On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> >> Hi Pablo,
> >>
> >> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> >> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> >> > ipv6_find_hdr() function is designed to return the transport protocol.
> >> > After the proposed change, it will return extension header numbers.
> >> > This will break existing ip6tables rulesets since the `-p' option
> >> > relies on this function to match the transport protocol.
> >> >
> >> > Note that the AH header is skipped (see code a bit below this
> >> > problematic fragmentation handling) so the follow up header after the
> >> > AH header is returned as the transport header.
> >> >
> >> > We can probably return the AH protocol number for non-1st fragments.
> >> > However, that would be something new to ip6tables since nobody has
> >> > ever seen packet matching `-p ah' rules. Thus, we restore control to
> >> > the user to allow this, but we would accept all kind of fragmented AH
> >> > traffic through the firewall since we cannot know what transport
> >> > protocol contains from non-1st fragments (unless I'm missing anything,
> >> > I need to have a closer look at this again tomorrow with fresher
> >> > mind).
> >>
> >> The code in question is guarded by (_frag_off != 0), so we are
> >> definitely processing a non-1st fragment currently. The -p match would
> >> happen at the time when the packet is reassembled and thus ipv6_find_hdr
> >> will find the real transport (final) header at this point (I hope I
> >> followed the code correctly here).
> >
> > Then, Rahul should get things working by modprobing nf_defrag_ipv6.
>
> I already had nf_defrag_ipv6 installed when the issue occured. But I
> see ip6table_raw_hook returning NF_DROP for the second fragment.
That's what I expected. I think the change only affects hooks before
reassembly.
Pablo, do we care about that, otherwise we should start audit the
callers?
Bye,
Hannes
^ permalink raw reply
* Re: [PATCH net] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
From: Pablo Neira Ayuso @ 2015-01-09 11:36 UTC (permalink / raw)
To: Rahul Sharma; +Cc: Hannes Frederic Sowa, netdev, linux-kernel, netfilter-devel
In-Reply-To: <CAFB3abwrjp61LLOk3RWwXYEq1g4QZUC8OTKuO2cAr+GbV3n4rw@mail.gmail.com>
On Fri, Jan 09, 2015 at 12:48:24PM +0530, Rahul Sharma wrote:
> Hi Pablo,
>
> On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso <pablo@netfilter.org> wrote:
> > On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> >> Hi Pablo,
> >>
> >> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> >> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> >> > ipv6_find_hdr() function is designed to return the transport protocol.
> >> > After the proposed change, it will return extension header numbers.
> >> > This will break existing ip6tables rulesets since the `-p' option
> >> > relies on this function to match the transport protocol.
> >> >
> >> > Note that the AH header is skipped (see code a bit below this
> >> > problematic fragmentation handling) so the follow up header after the
> >> > AH header is returned as the transport header.
> >> >
> >> > We can probably return the AH protocol number for non-1st fragments.
> >> > However, that would be something new to ip6tables since nobody has
> >> > ever seen packet matching `-p ah' rules. Thus, we restore control to
> >> > the user to allow this, but we would accept all kind of fragmented AH
> >> > traffic through the firewall since we cannot know what transport
> >> > protocol contains from non-1st fragments (unless I'm missing anything,
> >> > I need to have a closer look at this again tomorrow with fresher
> >> > mind).
> >>
> >> The code in question is guarded by (_frag_off != 0), so we are
> >> definitely processing a non-1st fragment currently. The -p match would
> >> happen at the time when the packet is reassembled and thus ipv6_find_hdr
> >> will find the real transport (final) header at this point (I hope I
> >> followed the code correctly here).
> >
> > Then, Rahul should get things working by modprobing nf_defrag_ipv6.
>
> I already had nf_defrag_ipv6 installed when the issue occured. But I
> see ip6table_raw_hook returning NF_DROP for the second fragment.
That's strange, this doesn't make sense to me. Could you enable
pr_debug() debugging in nf_ct_frag6_gather() to check why this packet
was not defragmented?
^ permalink raw reply
* Re: [PATCH net] ipv6: Prevent ipv6_find_hdr() from returning ENOENT for valid non-first fragments
From: Pablo Neira Ayuso @ 2015-01-09 11:45 UTC (permalink / raw)
To: Hannes Frederic Sowa; +Cc: Rahul Sharma, netdev, linux-kernel, netfilter-devel
In-Reply-To: <1420803255.1978819.211762005.707EFFB9@webmail.messagingengine.com>
Hi Hannes,
On Fri, Jan 09, 2015 at 12:34:15PM +0100, Hannes Frederic Sowa wrote:
> On Fri, Jan 9, 2015, at 08:18, Rahul Sharma wrote:
> > Hi Pablo,
> >
> > On Fri, Jan 9, 2015 at 5:35 AM, Pablo Neira Ayuso <pablo@netfilter.org>
> > wrote:
> > > On Thu, Jan 08, 2015 at 11:39:16PM +0100, Hannes Frederic Sowa wrote:
> > >> Hi Pablo,
> > >>
> > >> On Thu, Jan 8, 2015, at 21:53, Pablo Neira Ayuso wrote:
> > >> > I'm afraid we cannot just get rid of that !ipv6_ext_hdr() check. The
> > >> > ipv6_find_hdr() function is designed to return the transport protocol.
> > >> > After the proposed change, it will return extension header numbers.
> > >> > This will break existing ip6tables rulesets since the `-p' option
> > >> > relies on this function to match the transport protocol.
> > >> >
> > >> > Note that the AH header is skipped (see code a bit below this
> > >> > problematic fragmentation handling) so the follow up header after the
> > >> > AH header is returned as the transport header.
> > >> >
> > >> > We can probably return the AH protocol number for non-1st fragments.
> > >> > However, that would be something new to ip6tables since nobody has
> > >> > ever seen packet matching `-p ah' rules. Thus, we restore control to
> > >> > the user to allow this, but we would accept all kind of fragmented AH
> > >> > traffic through the firewall since we cannot know what transport
> > >> > protocol contains from non-1st fragments (unless I'm missing anything,
> > >> > I need to have a closer look at this again tomorrow with fresher
> > >> > mind).
> > >>
> > >> The code in question is guarded by (_frag_off != 0), so we are
> > >> definitely processing a non-1st fragment currently. The -p match would
> > >> happen at the time when the packet is reassembled and thus ipv6_find_hdr
> > >> will find the real transport (final) header at this point (I hope I
> > >> followed the code correctly here).
> > >
> > > Then, Rahul should get things working by modprobing nf_defrag_ipv6.
> >
> > I already had nf_defrag_ipv6 installed when the issue occured. But I
> > see ip6table_raw_hook returning NF_DROP for the second fragment.
>
> That's what I expected. I think the change only affects hooks before
> reassembly.
reassembly happens at NF_IP6_PRI_CONNTRACK_DEFRAG (-400), so that
happens before NF_IP6_PRI_RAW (-300) in IPv6 which is where the raw
table is placed.
^ permalink raw reply
* Re: Fw: iproute2: segfault with ip link show dev
From: Vadim Kochan @ 2015-01-09 11:43 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev@vger.kernel.org
In-Reply-To: <20150107114217.42bf2392@urahara>
Hi,
I really don't know about VF thing but I did a diff of 3.15.0 and
3.16.0 in ip/ipaddress.c
and seems in print_vfinfo:
vf_rate = RTA_DATA(vf[IFLA_VF_RATE]);
might be a NULL ?
Regards,
On Wed, Jan 7, 2015 at 9:42 PM, Stephen Hemminger
<stephen@networkplumber.org> wrote:
> Looks like one VF info changes broke old code
>
> Begin forwarded message:
>
> Date: Wed, 7 Jan 2015 04:06:53 -0800
> From: William Dauchy <william@gandi.net>
> To: "stephen@networkplumber.org" <stephen@networkplumber.org>
> Subject: iproute2: segfault with ip link show dev
>
>
> Hi,
>
> I was using iproute2 3.15.
> My network card in using igb driver with VF enable, e.g igb.max_vfs=2
> After upgrading to 3.16, I have now a segfault while doing a
> usual `ip link show dev eth1`.
> Disabling VFS make the segafult disappear.
>
> Here is the gdb trace even if it does not contain much info.
> The segfault occurs when at the VF step.
>
> (gdb) break print_linkinfo
> Breakpoint 1 at 0x40782d
> (gdb) set args link show dev eth1
> (gdb) r
> Starting program: /sbin/ip link show dev eth1
>
> Breakpoint 1, 0x000000000040782d in print_linkinfo ()
> (gdb) n
> Single stepping until exit from function print_linkinfo,
> which has no line number information.
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP
> mode DEFAULT group default qlen 10000
> link/ether 00:26:6c:ff:b5:c1 brd ff:ff:ff:ff:ff:ff
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00000000004070eb in print_vfinfo ()
> (gdb) bt
> #0 0x00000000004070eb in print_vfinfo ()
> #1 0x0000000000407f9f in print_linkinfo ()
> #2 0x000000000041f266 in iplink_get ()
> #3 0x0000000000409c69 in ipaddr_list_flush_or_save ()
> #4 0x000000000040a113 in ipaddr_list_link ()
> #5 0x00000000004203f6 in do_iplink ()
> #6 0x0000000000405a07 in do_cmd ()
> #7 0x000000000040621e in main ()
>
> The expected output is for example:
>
> # ip link show dev eth1
> 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP mode DEFAULT group default qlen 10000
> link/ether 00:26:6c:ff:b3:8d brd ff:ff:ff:ff:ff:ff
> vf 0 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
> vf 1 MAC 00:00:00:00:00:00, spoof checking on, link-state auto
>
>
> I'm using my own kernel build, a stable v3.14.x
>
> Regards,
> --
> William
^ permalink raw reply
* Query regarding sk_filter
From: Kumar Sanghvi @ 2015-01-09 11:23 UTC (permalink / raw)
To: netdev
Hi netdev team,
I have a query regarding sk_filter call in tcp receive path:
In 'tcp_v4_rcv' function, if sk is found by __inet_lookup_skb then,
down the line, there is a call to sk_filter to ensure if the incoming packet
is allowed to be processed for that sk.
However, in 'tcp_v4_hnd_req' function, if nsk is found by inet_lookup_established
then, later, there does not seem to be a sk_filter call for that nsk in the receive
path processing.
I am wondering shouldn't there be a sk_filter call on nsk found in 'tcp_v4_hnd_req'
function ? Or, probably I am missing something.
I am running some high rate syn-flood tests and trying to understand the sk_filter
behaviour in this case.
Thanks,
Kumar.
^ permalink raw reply
* [PATCH 1/2] NFC: pn544: GPIO access that may sleep
From: Robert Dolca @ 2015-01-09 12:02 UTC (permalink / raw)
To: linux-nfc
Cc: linux-kernel, linux-wireless, netdev, Lauro Ramos Venancio,
Aloisio Almeida Jr, Samuel Ortiz, David S. Miller, Johannes Berg,
Clement Perrochaud, Robert Dolca
gpio_set_value was replaced with gpio_set_value_cansleep in order
to allow GPIO access that may sleep. This is particularelly useful
when GPIO is accessed using busses like I2C, SPI, USB
Signed-off-by: Robert Dolca <robert.dolca@intel.com>
---
drivers/nfc/pn544/i2c.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index fc02e8d..5f4b9c1 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -195,18 +195,18 @@ static void pn544_hci_i2c_platform_init(struct pn544_i2c_phy *phy)
nfc_info(&phy->i2c_dev->dev, "Detecting nfc_en polarity\n");
/* Disable fw download */
- gpio_set_value(phy->gpio_fw, 0);
+ gpio_set_value_cansleep(phy->gpio_fw, 0);
for (polarity = 0; polarity < 2; polarity++) {
phy->en_polarity = polarity;
retry = 3;
while (retry--) {
/* power off */
- gpio_set_value(phy->gpio_en, !phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
usleep_range(10000, 15000);
/* power on */
- gpio_set_value(phy->gpio_en, phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
usleep_range(10000, 15000);
/* send reset */
@@ -225,13 +225,13 @@ static void pn544_hci_i2c_platform_init(struct pn544_i2c_phy *phy)
"Could not detect nfc_en polarity, fallback to active high\n");
out:
- gpio_set_value(phy->gpio_en, !phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
}
static void pn544_hci_i2c_enable_mode(struct pn544_i2c_phy *phy, int run_mode)
{
- gpio_set_value(phy->gpio_fw, run_mode == PN544_FW_MODE ? 1 : 0);
- gpio_set_value(phy->gpio_en, phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_fw, run_mode == PN544_FW_MODE ? 1 : 0);
+ gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
usleep_range(10000, 15000);
phy->run_mode = run_mode;
@@ -254,14 +254,14 @@ static void pn544_hci_i2c_disable(void *phy_id)
{
struct pn544_i2c_phy *phy = phy_id;
- gpio_set_value(phy->gpio_fw, 0);
- gpio_set_value(phy->gpio_en, !phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_fw, 0);
+ gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
usleep_range(10000, 15000);
- gpio_set_value(phy->gpio_en, phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, phy->en_polarity);
usleep_range(10000, 15000);
- gpio_set_value(phy->gpio_en, !phy->en_polarity);
+ gpio_set_value_cansleep(phy->gpio_en, !phy->en_polarity);
usleep_range(10000, 15000);
phy->powered = 0;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/2] nfc: NXP PN544 ACPI support
From: Robert Dolca @ 2015-01-09 12:02 UTC (permalink / raw)
To: linux-nfc-hn68Rpc1hR1g9hUCZPvPmw
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Lauro Ramos Venancio,
Aloisio Almeida Jr, Samuel Ortiz, David S. Miller, Johannes Berg,
Clement Perrochaud, Robert Dolca
In-Reply-To: <1420804937-10787-1-git-send-email-robert.dolca-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Device id: NXP5440
Pin mapping:
- 0 IRQ pin
- 1 enable pin
- 2 firmware pin
Signed-off-by: Robert Dolca <robert.dolca-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
drivers/nfc/Kconfig | 1 +
drivers/nfc/pn544/i2c.c | 115 ++++++++++++++++++++++++++++++++++++++++++++++--
net/nfc/core.c | 1 +
3 files changed, 114 insertions(+), 3 deletions(-)
diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
index 7929fac..a25e712 100644
--- a/drivers/nfc/Kconfig
+++ b/drivers/nfc/Kconfig
@@ -68,6 +68,7 @@ config NFC_PORT100
If unsure, say N.
+source "drivers/nfc/pn547/Kconfig"
source "drivers/nfc/pn544/Kconfig"
source "drivers/nfc/microread/Kconfig"
source "drivers/nfc/nfcmrvl/Kconfig"
diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
index 5f4b9c1..58b9029 100644
--- a/drivers/nfc/pn544/i2c.c
+++ b/drivers/nfc/pn544/i2c.c
@@ -24,6 +24,7 @@
#include <linux/gpio.h>
#include <linux/of_gpio.h>
#include <linux/of_irq.h>
+#include <linux/acpi.h>
#include <linux/miscdevice.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
@@ -41,6 +42,11 @@
#define PN544_I2C_FRAME_HEADROOM 1
#define PN544_I2C_FRAME_TAILROOM 2
+/* GPIO names */
+#define PN544_GPIO_NAME_IRQ "pn544_irq"
+#define PN544_GPIO_NAME_FW "pn544_fw"
+#define PN544_GPIO_NAME_EN "pn544_en"
+
/* framing in HCI mode */
#define PN544_HCI_I2C_LLC_LEN 1
#define PN544_HCI_I2C_LLC_CRC 2
@@ -58,6 +64,13 @@ static struct i2c_device_id pn544_hci_i2c_id_table[] = {
MODULE_DEVICE_TABLE(i2c, pn544_hci_i2c_id_table);
+static const struct acpi_device_id pn544_hci_i2c_acpi_match[] = {
+ {"NXP5440", 0},
+ {}
+};
+
+MODULE_DEVICE_TABLE(acpi, pn544_hci_i2c_acpi_match);
+
#define PN544_HCI_I2C_DRIVER_NAME "pn544_hci_i2c"
/*
@@ -859,6 +872,90 @@ exit_state_wait_secure_write_answer:
}
}
+static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
+{
+ struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
+ const struct acpi_device_id *id;
+ struct gpio_desc *gpiod_en, *gpiod_irq, *gpiod_fw;
+ struct device *dev;
+ int ret;
+
+ if (!client)
+ return -EINVAL;
+
+ dev = &client->dev;
+
+ /* Match the struct device against a given list of ACPI IDs */
+ id = acpi_match_device(dev->driver->acpi_match_table, dev);
+
+ if (!id)
+ return -ENODEV;
+
+ /* Get EN GPIO from ACPI */
+ gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
+ if (IS_ERR(gpiod_en)) {
+ nfc_err(dev,
+ "Unable to get EN GPIO\n");
+ return -ENODEV;
+ }
+
+ phy->gpio_en = desc_to_gpio(gpiod_en);
+
+ /* Configuration EN GPIO */
+ ret = gpiod_direction_output(gpiod_en, 0);
+ if (ret) {
+ nfc_err(dev, "Fail EN pin direction\n");
+ return ret;
+ }
+
+ /* Get FW GPIO from ACPI */
+ gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
+ if (IS_ERR(gpiod_fw)) {
+ nfc_err(dev,
+ "Unable to get FW GPIO\n");
+ return -ENODEV;
+ }
+
+ phy->gpio_fw = desc_to_gpio(gpiod_fw);
+
+ /* Configuration FW GPIO */
+ ret = gpiod_direction_output(gpiod_fw, 0);
+ if (ret) {
+ nfc_err(dev, "Fail FW pin direction\n");
+ return ret;
+ }
+
+ /* Get IRQ GPIO */
+ gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
+ if (IS_ERR(gpiod_irq)) {
+ nfc_err(dev,
+ "Unable to get IRQ GPIO\n");
+ return -ENODEV;
+ }
+
+ phy->gpio_irq = desc_to_gpio(gpiod_irq);
+
+ /* Configure IRQ GPIO */
+ ret = gpiod_direction_input(gpiod_irq);
+ if (ret) {
+ nfc_err(dev, "Fail IRQ pin direction\n");
+ return ret;
+ }
+
+ /* Map the pin to an IRQ */
+ ret = gpiod_to_irq(gpiod_irq);
+ if (ret < 0) {
+ nfc_err(dev, "Fail pin IRQ mapping\n");
+ return ret;
+ }
+
+ nfc_info(dev, "GPIO resource, no:%d irq:%d\n",
+ desc_to_gpio(gpiod_irq), ret);
+ client->irq = ret;
+
+ return 0;
+}
+
#ifdef CONFIG_OF
static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
@@ -884,7 +981,7 @@ static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
phy->gpio_en = ret;
/* Configuration of EN GPIO */
- ret = gpio_request(phy->gpio_en, "pn544_en");
+ ret = gpio_request(phy->gpio_en, PN544_GPIO_NAME_EN);
if (ret) {
nfc_err(&client->dev, "Fail EN pin\n");
goto err_dt;
@@ -906,7 +1003,7 @@ static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
phy->gpio_fw = ret;
/* Configuration of FW GPIO */
- ret = gpio_request(phy->gpio_fw, "pn544_fw");
+ ret = gpio_request(phy->gpio_fw, PN544_GPIO_NAME_FW);
if (ret) {
nfc_err(&client->dev, "Fail FW pin\n");
goto err_gpio_en;
@@ -1001,6 +1098,14 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
phy->gpio_en = pdata->get_gpio(NFC_GPIO_ENABLE);
phy->gpio_fw = pdata->get_gpio(NFC_GPIO_FW_RESET);
phy->gpio_irq = pdata->get_gpio(NFC_GPIO_IRQ);
+ /* Using ACPI */
+ } else if (ACPI_HANDLE(&client->dev)) {
+ r = pn544_hci_i2c_acpi_request_resources(client);
+ if (r) {
+ nfc_err(&client->dev,
+ "Cannot get ACPI data\n");
+ return r;
+ }
} else {
nfc_err(&client->dev, "No platform data\n");
return -EINVAL;
@@ -1020,9 +1125,12 @@ static int pn544_hci_i2c_probe(struct i2c_client *client,
PN544_I2C_FRAME_HEADROOM, PN544_I2C_FRAME_TAILROOM,
PN544_HCI_I2C_LLC_MAX_PAYLOAD,
pn544_hci_i2c_fw_download, &phy->hdev);
- if (r < 0)
+ if (r < 0) {
+ nfc_err(&client->dev, "HCI Probing error\n");
goto err_hci;
+ }
+ nfc_info(&client->dev, "NFC I2C driver loaded\n");
return 0;
err_hci:
@@ -1080,6 +1188,7 @@ static struct i2c_driver pn544_hci_i2c_driver = {
.name = PN544_HCI_I2C_DRIVER_NAME,
.owner = THIS_MODULE,
.of_match_table = of_match_ptr(of_pn544_i2c_match),
+ .acpi_match_table = ACPI_PTR(pn544_hci_i2c_acpi_match),
},
.probe = pn544_hci_i2c_probe,
.id_table = pn544_hci_i2c_id_table,
diff --git a/net/nfc/core.c b/net/nfc/core.c
index 819b877..a53c2cc 100644
--- a/net/nfc/core.c
+++ b/net/nfc/core.c
@@ -32,6 +32,7 @@
#include "nfc.h"
+#define DEBUG
#define VERSION "0.1"
#define NFC_CHECK_PRES_FREQ_MS 2000
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH] net/9p: Initialize opts->privport as it should be.
From: Dominique Martinet @ 2015-01-09 12:05 UTC (permalink / raw)
To: Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov
Cc: v9fs-developer, David S. Miller, netdev, linux-kernel,
Dominique Martinet
We're currently using an uninitialized value if option privport is not set,
thus (almost) always using a privileged port.
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
---
net/9p/trans_fd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/9p/trans_fd.c b/net/9p/trans_fd.c
index 80d08f6..748703e 100644
--- a/net/9p/trans_fd.c
+++ b/net/9p/trans_fd.c
@@ -734,6 +734,7 @@ static int parse_opts(char *params, struct p9_fd_opts *opts)
opts->port = P9_PORT;
opts->rfd = ~0;
opts->wfd = ~0;
+ opts->privport = 0;
if (!params)
return 0;
--
1.9.3
^ permalink raw reply related
* [PATCH] net/9p: add a privport option for RDMA transport.
From: Dominique Martinet @ 2015-01-09 12:07 UTC (permalink / raw)
To: Eric Van Hensbergen, Ron Minnich, Latchesar Ionkov
Cc: v9fs-developer, David S. Miller, netdev, linux-kernel, linux-rdma,
Dominique Martinet
RDMA can use the same kind of weak security as TCP by checking the
client can bind to a privileged port, which is better than nothing
if TAUTH isn't implemented.
Signed-off-by: Dominique Martinet <dominique.martinet@cea.fr>
---
Please note that this does NOT checkpatch because option tokens
"Opt_foo" are considered CamelCase.
To make this pass one would need to submit a first patch that'd "fix"
token names all around 9p code (net and fs), I'd rather stay coherent
and keep it as is for now.
I tried to stick to keep code similar to the tcp equivalent, but happy
to make any change deemed useful.
net/9p/trans_rdma.c | 52 ++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 44 insertions(+), 8 deletions(-)
diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
index 14ad43b..3533d2a 100644
--- a/net/9p/trans_rdma.c
+++ b/net/9p/trans_rdma.c
@@ -139,6 +139,7 @@ struct p9_rdma_opts {
int sq_depth;
int rq_depth;
long timeout;
+ int privport;
};
/*
@@ -146,7 +147,10 @@ struct p9_rdma_opts {
*/
enum {
/* Options that take integer arguments */
- Opt_port, Opt_rq_depth, Opt_sq_depth, Opt_timeout, Opt_err,
+ Opt_port, Opt_rq_depth, Opt_sq_depth, Opt_timeout,
+ /* Options that take no argument */
+ Opt_privport,
+ Opt_err,
};
static match_table_t tokens = {
@@ -154,6 +158,7 @@ static match_table_t tokens = {
{Opt_sq_depth, "sq=%u"},
{Opt_rq_depth, "rq=%u"},
{Opt_timeout, "timeout=%u"},
+ {Opt_privport, "privport"},
{Opt_err, NULL},
};
@@ -175,6 +180,7 @@ static int parse_opts(char *params, struct p9_rdma_opts *opts)
opts->sq_depth = P9_RDMA_SQ_DEPTH;
opts->rq_depth = P9_RDMA_RQ_DEPTH;
opts->timeout = P9_RDMA_TIMEOUT;
+ opts->privport = 0;
if (!params)
return 0;
@@ -193,13 +199,13 @@ static int parse_opts(char *params, struct p9_rdma_opts *opts)
if (!*p)
continue;
token = match_token(p, tokens, args);
- if (token == Opt_err)
- continue;
- r = match_int(&args[0], &option);
- if (r < 0) {
- p9_debug(P9_DEBUG_ERROR,
- "integer field, but no integer?\n");
- continue;
+ if ((token != Opt_err) && (token != Opt_privport)) {
+ r = match_int(&args[0], &option);
+ if (r < 0) {
+ p9_debug(P9_DEBUG_ERROR,
+ "integer field, but no integer?\n");
+ continue;
+ }
}
switch (token) {
case Opt_port:
@@ -214,6 +220,9 @@ static int parse_opts(char *params, struct p9_rdma_opts *opts)
case Opt_timeout:
opts->timeout = option;
break;
+ case Opt_privport:
+ opts->privport = 1;
+ break;
default:
continue;
}
@@ -607,6 +616,23 @@ static int rdma_cancelled(struct p9_client *client, struct p9_req_t *req)
return 0;
}
+static int p9_rdma_bind_privport(struct p9_trans_rdma *rdma)
+{
+ struct sockaddr_in cl = {
+ .sin_family = AF_INET,
+ .sin_addr.s_addr = htonl(INADDR_ANY),
+ };
+ int port, err = -EINVAL;
+
+ for (port = P9_DEF_MAX_RESVPORT; port >= P9_DEF_MIN_RESVPORT; port--) {
+ cl.sin_port = htons((ushort)port);
+ err = rdma_bind_addr(rdma->cm_id, (struct sockaddr *)&cl);
+ if (err != -EADDRINUSE)
+ break;
+ }
+ return err;
+}
+
/**
* trans_create_rdma - Transport method for creating atransport instance
* @client: client instance
@@ -642,6 +668,16 @@ rdma_create_trans(struct p9_client *client, const char *addr, char *args)
/* Associate the client with the transport */
client->trans = rdma;
+ /* Bind to a privileged port if we need to */
+ if (opts.privport) {
+ err = p9_rdma_bind_privport(rdma);
+ if (err < 0) {
+ pr_err("%s (%d): problem binding to privport: %d\n",
+ __func__, task_pid_nr(current), -err);
+ goto error;
+ }
+ }
+
/* Resolve the server's address */
rdma->addr.sin_family = AF_INET;
rdma->addr.sin_addr.s_addr = in_aton(addr);
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v2 0/7] Fix sti drivers whcih mix reg address spaces
From: Maxime Coquelin @ 2015-01-09 12:45 UTC (permalink / raw)
To: Peter Griffin, linux-arm-kernel, linux-kernel,
srinivas.kandagatla, patrice.chotard, peppe.cavallaro, kishon,
arnd
Cc: lee.jones, devicetree, netdev
In-Reply-To: <1420643052-4506-1-git-send-email-peter.griffin@linaro.org>
Hi Peter,
On 01/07/2015 04:04 PM, Peter Griffin wrote:
> Hi folks,
>
> A V2 of this old series incorporating Arnd and Lees Feedback form v1.
>
> Following on from Arnds comments about the picophy driver here
> https://lkml.org/lkml/2014/11/13/161, this series fixes the
> remaining upstreamed drivers for STI, which are mixing address spaces
> in the reg property. We do this in a way similar to the keystone
> and bcm7445 platforms, by having sysconfig phandle/ offset pair
> (where only one register is required). Or phandle / integer array
> where multiple offsets in the same bank are needed).
>
> This series breaks DT compatability! But the platform support
> is WIP and only being used by the few developers who are upstreaming
> support for it. I've made each change to the driver / dt doc / dt
> file as a single atomic commit so the kernel will remain bisectable.
>
> This series then also enables the picophy driver, and adds back in
> the ehci/ohci dt nodes for stih410 which make use of the picophy.
>
> regards,
>
> Peter.
>
> Changes since v1:
> - Add missing space after */ (Lee)
> - Change comment to "indexed from" rather than "not indexed from" (Lee)
> - Change naming to phy1, phy2 rather than phy@1 phy@2 if there is no reg property (Arnd / Grant)
> - Rebased on v3.19-rc3 (me)
> - Checkpatch "no space before tabs" warning in stih41*.dtsi (me)
>
> Peter Griffin (7):
> phy: phy-stih407-usb: Pass sysconfig register offsets via syscfg
> property.
> phy: miphy365x: Pass sysconfig register offsets via syscfg dt
> property.
> ARM: STi: DT: STiH407: Add usb2 picophy dt nodes
> ARM: STi: DT: STiH410: Add usb2 picophy dt nodes
> ARM: STi: DT: STiH410: Add DT nodes for the ehci and ohci usb
> controllers.
> ARM: multi_v7_defconfig: Enable stih407 usb picophy
> stmmac: dwmac-sti: Pass sysconfig register offset via syscon dt
> property.
>
> .../devicetree/bindings/net/sti-dwmac.txt | 14 ++---
> .../devicetree/bindings/phy/phy-miphy365x.txt | 15 ++---
> .../devicetree/bindings/phy/phy-stih407-usb.txt | 10 +---
> arch/arm/boot/dts/stih407-family.dtsi | 9 +++
> arch/arm/boot/dts/stih410.dtsi | 70 ++++++++++++++++++++++
> arch/arm/boot/dts/stih415.dtsi | 12 ++--
> arch/arm/boot/dts/stih416.dtsi | 22 +++----
> arch/arm/configs/multi_v7_defconfig | 1 +
> drivers/net/ethernet/stmicro/stmmac/dwmac-sti.c | 13 ++--
> drivers/phy/phy-miphy365x.c | 29 ++++-----
> drivers/phy/phy-stih407-usb.c | 25 ++++----
> 11 files changed, 143 insertions(+), 77 deletions(-)
>
Thanks! The series looks good to me.
DT patches applied to sti-dt-for-v3.20 branch,
and defconfig patch applied to sti-defconfig-for-v3.20.
Regards,
Maxime
^ permalink raw reply
* Re: [bisected] no traffic on ssl vpn with 3.19rc1 - 3.19rc3
From: Billy Shuman @ 2015-01-09 13:13 UTC (permalink / raw)
To: Herbert Xu; +Cc: netdev
In-Reply-To: <20150108205745.GA13460@gondor.apana.org.au>
Changeset 8c847d254146d32c86574a1b16923ff91bb784dd did not resolve the
issue for me.
Should I target any other specific changesets?
Thanks,
Billy
William Shuman
Tel: 260-316-9300
Email: wshuman3@gmail.com
On Thu, Jan 8, 2015 at 3:57 PM, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> Billy Shuman <wshuman3@gmail.com> wrote:
>>
>> Since 3.19rc1 I get 100% packet loss through SSL vpn. I bisected with
>> the following result:
>>
>> 0b46d0ee9c240c7430a47e9b0365674d4a04522 is the first bad commit
>> commit e0b46d0ee9c240c7430a47e9b0365674d4a04522
>> Author: Herbert Xu <herbert@gondor.apana.org.au>
>> Date: Fri Nov 7 21:22:23 2014 +0800
>>
>> tun: Use iovec iterators
>>
>> This patch removes the use of skb_copy_datagram_const_iovec in
>> favour of the iovec iterator-based skb_copy_datagram_iter.
>>
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=90901
>
> This changeset is known to be buggy. However it was fixed ages
> ago by changeset 8c847d254146d32c86574a1b16923ff91bb784dd.
>
> So please test that changeset to see if it works for you. If it
> does, then please do your bisection between that and the current
> top of tree.
>
> Thanks,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: NULL pointer dereference at skb_queue_tail()
From: Tetsuo Handa @ 2015-01-09 13:20 UTC (permalink / raw)
To: cwang; +Cc: netdev
In-Reply-To: <CAHA+R7Mq=vhSCqJsE5dn7PGg39R8Nh+m1RT0F-KcoBU99GdpWA@mail.gmail.com>
Cong Wang wrote:
> On Mon, Jan 5, 2015 at 4:50 AM, Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
> > Tetsuo Handa wrote:
> >> I can reproduce below oops when testing Linux 3.18 with memory allocation
> >> failure injection module at https://lkml.org/lkml/2014/12/25/64 .
> >
> > I can reliably reproduce this oops with current linux.git using memory
> > allocation failure injection module. There is a possibility of memory
> > corruption since this oops always occurs immediately after memory
> > allocation failure within GPU/DRM code. I want to check whether
> > fields of structures have expected values or not.
>
> Looks like the skb->prev and/or skb->next in the skb queue is corrupted,
> but I don't see why. We do play some magic on these pointers recently,
> but it should not be related with unix socket at all.
Yes, I saw skb->prev == NULL while skb->next != NULL. And I saw various
different oops shown below depending on timing.
Is there code which set skb->prev or skb->next to NULL after it was
initialized with non-NULL? If there is no such code, this could be
memory corruption.
>
> Is it possible for you to check if this is a regression of recent kernel?
> We only have few changes in unix socket recently, and I don't see they
> could cause this bug.
Would you tell me which versions to test?
I confirmed that this problem exists at least since 3.14.
I haven't hit this problem with 3.12 because I hit different problem
before hitting this problem. So far I didn't hit this problem with 3.10.
[ 244.389630] BUG: unable to handle kernel paging request at 00000000bf38b1f5
[ 244.391428] IP: [<ffffffff81646a51>] unix_detach_fds.isra.25+0x21/0x50
[ 244.393050] PGD 7aabf067 PUD 0
[ 244.393865] Oops: 0000 [#1] SMP
[ 244.394694] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_9804(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel dm_mirror aesni_intel dm_region_hash dm_log glue_helper dm_mod lrw gf128mul ablk_helper cryptd ppdev vmw_balloon parport_pc microcode pcspkr serio_raw vmw_vmci parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi e1000 ata_piix mptspi libata scsi_transport_spi m
ptscsih mptbase floppy
[ 244.413886] CPU: 2 PID: 9936 Comm: Xorg Tainted: G W OE 3.19.0-rc3+ #9
[ 244.415807] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 244.418438] task: ffff88007a7d3d40 ti: ffff88007ab88000 task.ti: ffff88007ab88000
[ 244.420269] RIP: 0010:[<ffffffff81646a51>] [<ffffffff81646a51>] unix_detach_fds.isra.25+0x21/0x50
[ 244.422517] RSP: 0018:ffff88007ab8bb48 EFLAGS: 00010206
[ 244.423823] RAX: 00000000bf38b1f5 RBX: 0000000000000000 RCX: 0000000000000014
[ 244.425580] RDX: 0000000000000004 RSI: ffff88007b4b4800 RDI: ffff88007ab8bbf8
[ 244.427312] RBP: ffff88007ab8bb58 R08: 0000000000000014 R09: ffff88007ae54000
[ 244.429070] R10: ffff88007ae54000 R11: ffff88007a7d3d40 R12: ffff88007ab8bbf8
[ 244.430816] R13: ffff88007b4b4800 R14: ffff88003a806990 R15: ffff88003a806900
[ 244.432555] FS: 00007fe2e1976980(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
[ 244.434477] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 244.435859] CR2: 00000000bf38b1f5 CR3: 000000007aa31000 CR4: 00000000000407e0
[ 244.437626] Stack:
[ 244.438124] 0000000000000000 0000000000000000 ffff88007ab8bc68 ffffffff816486cb
[ 244.439987] dead000000200200 ffff88001db00700 ffff88007a7d3d40 ffff88007ab8bc28
[ 244.441889] ffff88007a7d3d40 ffff88003a806bb0 0000000000000001 ffff88007ae54000
[ 244.443778] Call Trace:
[ 244.444376] [<ffffffff816486cb>] unix_stream_recvmsg+0x57b/0x840
[ 244.445850] [<ffffffff811c7530>] ? poll_select_copy_remaining+0x130/0x130
[ 244.447504] [<ffffffff81589c96>] sock_recvmsg+0x76/0x90
[ 244.448777] [<ffffffff8158b8fe>] ? copy_msghdr_from_user+0x15e/0x1f0
[ 244.450331] [<ffffffff8158bd84>] ___sys_recvmsg+0xe4/0x200
[ 244.451660] [<ffffffff81337180>] ? timerqueue_add+0x60/0xb0
[ 244.453018] [<ffffffff810ce4c9>] ? enqueue_hrtimer+0x29/0x90
[ 244.454390] [<ffffffff810cea70>] ? __hrtimer_start_range_ns+0x260/0x360
[ 244.455995] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 244.457313] [<ffffffff8158c762>] __sys_recvmsg+0x42/0x80
[ 244.458625] [<ffffffff8158c7b2>] SyS_recvmsg+0x12/0x20
[ 244.459871] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 244.461334] Code: 66 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 55 48 8b 46 38 48 89 e5 41 54 49 89 fc 53 48 89 07 48 c7 46 38 00 00 00 00 48 8b 07 <0f> bf 18 83 eb 01 79 0b eb 1e 0f 1f 44 00 00 49 8b 04 24 48 63
[ 244.467598] RIP [<ffffffff81646a51>] unix_detach_fds.isra.25+0x21/0x50
[ 244.469201] RSP <ffff88007ab8bb48>
[ 244.470055] CR2: 00000000bf38b1f5
[ 1511.728498] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 1511.730551] IP: [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 1511.731987] PGD 0
[ 1511.732523] Oops: 0002 [#1] SMP
[ 1511.733406] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_2788(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel dm_mirror ghash_clmulni_intel dm_region_hash dm_log aesni_intel dm_mod glue_helper lrw gf128mul ablk_helper cryptd vmw_balloon ppdev microcode serio_raw pcspkr parport_pc vmw_vmci parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi mptspi ata_piix e1000 scsi_transport_spi libata m
ptscsih mptbase floppy
[ 1511.752609] CPU: 2 PID: 2972 Comm: pool Tainted: G W OE 3.19.0-rc3+ #9
[ 1511.754400] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 1511.757001] task: ffff880036d29180 ti: ffff8800791bc000 task.ti: ffff8800791bc000
[ 1511.758830] RIP: 0010:[<ffffffff8159342b>] [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 1511.760787] RSP: 0018:ffff8800791bfb78 EFLAGS: 00010082
[ 1511.762047] RAX: 0000000000000296 RBX: ffff88007a8d7380 RCX: 0000000000000000
[ 1511.763765] RDX: 0000000000000000 RSI: 0000000000000296 RDI: ffff88007a8d77a4
[ 1511.765583] RBP: ffff8800791bfb98 R08: 0000000000000296 R09: 0000000000000000
[ 1511.767359] R10: ffff8800799cb4b0 R11: ffff88007a22b410 R12: ffff88007a8d7790
[ 1511.769116] R13: ffff88007a8d77a4 R14: ffff88007a8d7790 R15: 0000000000000001
[ 1511.770866] FS: 0000000000000000(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
[ 1511.772854] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1511.774239] CR2: 0000000000000008 CR3: 0000000001c14000 CR4: 00000000000407e0
[ 1511.776042] Stack:
[ 1511.776558] ffff88007a8d776c ffff88007a8d7700 ffff88007a8d776c ffff88007a8d7a80
[ 1511.778449] ffff8800791bfbf8 ffffffff81648030 0000000100c2e630 ffff880000000000
[ 1511.780372] 0000000000000000 0000000000000000 0000000000000000 ffff8800799cb480
[ 1511.782290] Call Trace:
[ 1511.782921] [<ffffffff81648030>] unix_release_sock+0x1d0/0x2b0
[ 1511.784410] [<ffffffff81648131>] unix_release+0x21/0x40
[ 1511.785721] [<ffffffff8158ab8f>] sock_release+0x1f/0x90
[ 1511.787029] [<ffffffff8158ac12>] sock_close+0x12/0x20
[ 1511.788323] [<ffffffff811b531f>] __fput+0xdf/0x1e0
[ 1511.789514] [<ffffffff811b546e>] ____fput+0xe/0x10
[ 1511.790720] [<ffffffff81087dac>] task_work_run+0xcc/0xf0
[ 1511.792072] [<ffffffff8106eae8>] do_exit+0x2d8/0xb40
[ 1511.793290] [<ffffffff810779af>] ? recalc_sigpending+0x1f/0x60
[ 1511.794718] [<ffffffff8106f3df>] do_group_exit+0x3f/0xa0
[ 1511.796074] [<ffffffff8107a6f2>] get_signal+0x1d2/0x6f0
[ 1511.797396] [<ffffffff810134e8>] do_signal+0x28/0x720
[ 1511.798653] [<ffffffff81013c2c>] do_notify_resume+0x4c/0x90
[ 1511.800057] [<ffffffff816a5587>] int_signal+0x12/0x17
[ 1511.801334] Code: 00 49 8b 1c 24 4c 39 e3 74 46 48 85 db 74 23 41 83 6c 24 10 01 48 8b 0b 48 8b 53 08 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 <48> 89 51 08 48 89 0a 48 89 c6 4c 89 ef e8 53 17 11 00 48 83 c4
[ 1511.807711] RIP [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 1511.809118] RSP <ffff8800791bfb78>
[ 1511.809995] CR2: 0000000000000008
[ 149.357455] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
[ 149.359965] IP: [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 149.361412] PGD 0
[ 149.361931] Oops: 0002 [#1] SMP
[ 149.362787] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_2459(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel dm_mirror ghash_clmulni_intel dm_region_hash dm_log aesni_intel dm_mod glue_helper lrw gf128mul ablk_helper cryptd ppdev vmw_balloon microcode parport_pc pcspkr serio_raw parport vmw_vmci shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput ata_generic pata_acpi sd_mod ata_piix mptspi e1000 scsi_transport_spi mptscsih
libata mptbase floppy
[ 149.382152] CPU: 0 PID: 2608 Comm: gnome-shell Tainted: G W OE 3.19.0-rc3+ #9
[ 149.384226] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 149.386705] task: ffff88007ad5d780 ti: ffff88007a630000 task.ti: ffff88007a630000
[ 149.388606] RIP: 0010:[<ffffffff8159342b>] [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 149.390496] RSP: 0018:ffff88007a633b78 EFLAGS: 00010097
[ 149.391740] RAX: 0000000000000296 RBX: ffff88007ad6ad80 RCX: 0000000000000000
[ 149.393627] RDX: ffff88003a87fae8 RSI: 0000000000000292 RDI: ffff88007ad6e624
[ 149.395312] RBP: ffff88007a633b98 R08: 0000000000000296 R09: 0000000000000000
[ 149.397071] R10: ffff88003eeb4030 R11: ffff88007a2dfc10 R12: ffff88007ad6e610
[ 149.398745] R13: ffff88007ad6e624 R14: ffff88007ad6e610 R15: 0000000000000001
[ 149.400434] FS: 0000000000000000(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 149.402266] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 149.403924] CR2: 0000000000000008 CR3: 0000000001c14000 CR4: 00000000000407f0
[ 149.405701] Stack:
[ 149.406206] ffff88007ad6e5ec ffff88007ad6e580 ffff88007ad6e5ec ffff88007ad6b480
[ 149.408086] ffff88007a633bf8 ffffffff81647fc4 000000013eeb2dc8 ffff880000000000
[ 149.409863] 0000000000000000 0000000000000000 0000000000000000 ffff88003eeb4000
[ 149.411670] Call Trace:
[ 149.412242] [<ffffffff81647fc4>] unix_release_sock+0x164/0x2b0
[ 149.413838] [<ffffffff81648131>] unix_release+0x21/0x40
[ 149.415089] [<ffffffff8158ab8f>] sock_release+0x1f/0x90
[ 149.416382] [<ffffffff8158ac12>] sock_close+0x12/0x20
[ 149.417581] [<ffffffff811b531f>] __fput+0xdf/0x1e0
[ 149.418869] [<ffffffff811b546e>] ____fput+0xe/0x10
[ 149.420026] [<ffffffff81087dac>] task_work_run+0xcc/0xf0
[ 149.421313] [<ffffffff8106eae8>] do_exit+0x2d8/0xb40
[ 149.422495] [<ffffffff810779af>] ? recalc_sigpending+0x1f/0x60
[ 149.423925] [<ffffffff8106f3df>] do_group_exit+0x3f/0xa0
[ 149.425173] [<ffffffff8107a6f2>] get_signal+0x1d2/0x6f0
[ 149.426408] [<ffffffff810134e8>] do_signal+0x28/0x720
[ 149.427573] [<ffffffff8101fe4b>] ? __restore_xstate_sig+0x8b/0x680
[ 149.429030] [<ffffffff81013c2c>] do_notify_resume+0x4c/0x90
[ 149.430351] [<ffffffff816a5587>] int_signal+0x12/0x17
[ 149.431511] Code: 00 49 8b 1c 24 4c 39 e3 74 46 48 85 db 74 23 41 83 6c 24 10 01 48 8b 0b 48 8b 53 08 48 c7 03 00 00 00 00 48 c7 43 08 00 00 00 00 <48> 89 51 08 48 89 0a 48 89 c6 4c 89 ef e8 53 17 11 00 48 83 c4
[ 149.437473] RIP [<ffffffff8159342b>] skb_dequeue+0x4b/0x80
[ 149.438803] RSP <ffff88007a633b78>
[ 149.439599] CR2: 0000000000000008
[ 144.274609] BUG: unable to handle kernel NULL pointer dereference at 0000000000000002
[ 144.276557] IP: [<ffffffff81599f40>] skb_copy_datagram_iter+0xe0/0x260
[ 144.278178] PGD 7a26e067 PUD 7a26b067 PMD 0
[ 144.279300] Oops: 0000 [#1] SMP
[ 144.280129] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_2457(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel dm_mirror aesni_intel dm_region_hash glue_helper dm_log lrw gf128mul dm_mod ablk_helper cryptd ppdev vmw_balloon microcode parport_pc serio_raw pcspkr vmw_vmci parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi mptspi scsi_transport_spi e1000 mptscsih ata_piix
mptbase libata floppy
[ 144.299002] CPU: 2 PID: 2348 Comm: gnome-shell Tainted: G W OE 3.19.0-rc3+ #9
[ 144.300902] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 144.303443] task: ffff880078008000 ti: ffff88007a298000 task.ti: ffff88007a298000
[ 144.305231] RIP: 0010:[<ffffffff81599f40>] [<ffffffff81599f40>] skb_copy_datagram_iter+0xe0/0x260
[ 144.307397] RSP: 0018:ffff88007a29bbc8 EFLAGS: 00010202
[ 144.308726] RAX: 0000000000000002 RBX: 0000000000001000 RCX: 00000000c698e000
[ 144.310443] RDX: ffff88007a29be78 RSI: 0000000039672000 RDI: ffff88007a139180
[ 144.312144] RBP: ffff88007a29bc18 R08: 0000000000001000 R09: ffff88007b1e0c80
[ 144.313834] R10: 0000000000000000 R11: ffff880078008000 R12: 0000000000000000
[ 144.315559] R13: ffff88007a139180 R14: 0000000039672000 R15: ffff88007a138a80
[ 144.317261] FS: 00007fc870c36a00(0000) GS:ffff88007fc80000(0000) knlGS:0000000000000000
[ 144.319169] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 144.320562] CR2: 0000000000000002 CR3: 000000007b5f5000 CR4: 00000000000407e0
[ 144.322289] Stack:
[ 144.322784] 0000000000000008 ffff88007a151000 00000000c698e000 ffff88007a29be78
[ 144.324668] ffff88007a29bca8 0000000000000000 0000000000000000 ffff88007a139180
[ 144.326564] ffff88007a138b10 ffff88007a138a80 ffff88007a29bd28 ffffffff8164865b
[ 144.328422] Call Trace:
[ 144.329021] [<ffffffff8164865b>] unix_stream_recvmsg+0x50b/0x840
[ 144.330484] [<ffffffff811c7530>] ? poll_select_copy_remaining+0x130/0x130
[ 144.332121] [<ffffffff81589c96>] sock_recvmsg+0x76/0x90
[ 144.333389] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 144.334714] [<ffffffff811d07a3>] ? __fdget+0x13/0x20
[ 144.335934] [<ffffffff8158a1c7>] ? sockfd_lookup_light+0x17/0x70
[ 144.337383] [<ffffffff8158a860>] SYSC_recvfrom+0xe0/0x160
[ 144.338693] [<ffffffff81103264>] ? __audit_syscall_entry+0xb4/0x110
[ 144.340222] [<ffffffff8102140c>] ? do_audit_syscall_entry+0x6c/0x70
[ 144.341753] [<ffffffff810227b3>] ? syscall_trace_enter_phase1+0x123/0x180
[ 144.343385] [<ffffffff8158c2ee>] SyS_recvfrom+0xe/0x10
[ 144.344651] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 144.346100] Code: 83 c7 10 89 da 4c 89 ee ff d1 49 8b 0f 48 85 c9 75 e9 8b 4d c0 85 c9 0f 8f 76 ff ff ff 41 8b 85 cc 00 00 00 49 03 85 d0 00 00 00 <80> 38 00 0f 84 98 00 00 00 45 31 ff 0f 1f 40 00 49 63 d7 48 83
[ 144.352303] RIP [<ffffffff81599f40>] skb_copy_datagram_iter+0xe0/0x260
[ 144.353900] RSP <ffff88007a29bbc8>
[ 144.354829] CR2: 0000000000000002
[ 141.981007] BUG: unable to handle kernel paging request at ffff88013b831cc0
[ 141.982931] IP: [<ffffffff81594dd5>] __alloc_skb+0x165/0x2b0
[ 141.984465] PGD 1f2b067 PUD 0
[ 141.985334] Oops: 0002 [#1] SMP
[ 141.986357] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_4681(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel dm_mirror glue_helper dm_region_hash dm_log lrw dm_mod gf128mul ablk_helper cryptd ppdev vmw_balloon parport_pc microcode serio_raw vmw_vmci pcspkr parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput ata_generic sd_mod pata_acpi ata_piix libata mptspi e1000 scsi_transport_spi m
ptscsih mptbase floppy
[ 142.006491] CPU: 3 PID: 610 Comm: Xorg Tainted: G W OE 3.19.0-rc3+ #9
[ 142.008230] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 142.010776] task: ffff880078898000 ti: ffff88007be24000 task.ti: ffff88007be24000
[ 142.012551] RIP: 0010:[<ffffffff81594dd5>] [<ffffffff81594dd5>] __alloc_skb+0x165/0x2b0
[ 142.014522] RSP: 0018:ffff88007be27aa8 EFLAGS: 00010246
[ 142.015810] RAX: 00000000ffffffff RBX: ffff88003b831c00 RCX: 00000000ffffffff
[ 142.017512] RDX: ffff88013b831cc0 RSI: 0000000000000000 RDI: ffff88003b831cc8
[ 142.019255] RBP: ffff88007be27af8 R08: 00000000ffffffc0 R09: 0000000000000200
[ 142.020966] R10: ffffffff81594cbe R11: ffff88007f803700 R12: ffff88003b831d00
[ 142.022673] R13: 00000000ffffffff R14: ffff88007f803700 R15: 0000000000000100
[ 142.024378] FS: 00007fae44c35980(0000) GS:ffff88007fcc0000(0000) knlGS:0000000000000000
[ 142.026300] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 142.027657] CR2: ffff88013b831cc0 CR3: 00000000780ea000 CR4: 00000000000407e0
[ 142.029383] Stack:
[ 142.029865] ffff880000000000 0000000000000001 ffff88007b232ec0 0000000000000000
[ 142.031710] ffff8800780483c8 0000000000000003 0000000000000000 ffff88007be27ba8
[ 142.033531] ffff880078f06200 0000000000000000 ffff88007be27b58 ffffffff8159567c
[ 142.035344] Call Trace:
[ 142.035950] [<ffffffff8159567c>] alloc_skb_with_frags+0x5c/0x1e0
[ 142.037356] [<ffffffff81096440>] ? wake_up_state+0x20/0x20
[ 142.038865] [<ffffffff8158f9d6>] sock_alloc_send_pskb+0x196/0x250
[ 142.040323] [<ffffffff810aaeb4>] ? __wake_up_sync_key+0x54/0x70
[ 142.041769] [<ffffffff8164a237>] ? wait_for_unix_gc+0x27/0xa0
[ 142.043181] [<ffffffff81647aba>] unix_stream_sendmsg+0x2aa/0x430
[ 142.044582] [<ffffffff8158a9e3>] sock_aio_write+0x103/0x140
[ 142.045979] [<ffffffff811b2fbc>] do_sync_readv_writev+0x4c/0x80
[ 142.047370] [<ffffffff811b4965>] do_readv_writev+0x1e5/0x280
[ 142.048756] [<ffffffff810ce4c9>] ? enqueue_hrtimer+0x29/0x90
[ 142.050119] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 142.051432] [<ffffffff81103264>] ? __audit_syscall_entry+0xb4/0x110
[ 142.052891] [<ffffffff811b4a89>] vfs_writev+0x39/0x50
[ 142.054119] [<ffffffff811b4bba>] SyS_writev+0x4a/0xd0
[ 142.055307] [<ffffffff811034f6>] ? __audit_syscall_exit+0x236/0x2e0
[ 142.056821] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 142.058259] Code: b6 83 90 00 00 00 83 e0 f7 09 c8 b9 ff ff ff ff 85 f6 88 83 90 00 00 00 b8 ff ff ff ff 66 89 8b c2 00 00 00 66 89 83 c6 00 00 00 <48> c7 02 00 00 00 00 48 c7 42 08 00 00 00 00 48 c7 42 10 00 00
[ 142.064326] RIP [<ffffffff81594dd5>] __alloc_skb+0x165/0x2b0
[ 142.065719] RSP <ffff88007be27aa8>
[ 142.066536] CR2: ffff88013b831cc0
[ 202.125577] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 202.127781] IP: [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 202.129471] PGD 7909a067 PUD 7c0ab067 PMD 0
[ 202.130709] Oops: 0002 [#1] SMP
[ 202.131655] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_4681(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul dm_mirror crc32_pclmul crc32c_intel dm_region_hash dm_log ghash_clmulni_intel aesni_intel dm_mod glue_helper lrw gf128mul ablk_helper cryptd ppdev vmw_balloon parport_pc microcode pcspkr vmw_vmci serio_raw parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi mptspi scsi_transport_spi e1000 mptscsih ata_piix
mptbase libata floppy [last unloaded: stap_1d434baec036a3abf082a3f3fc53e337_4681]
[ 202.154006] CPU: 0 PID: 2884 Comm: Xorg Tainted: G W OE 3.19.0-rc3+ #9
[ 202.155953] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 202.158788] task: ffff88004b048000 ti: ffff88007b590000 task.ti: ffff88007b590000
[ 202.160770] RIP: 0010:[<ffffffff81593577>] [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 202.162999] RSP: 0018:ffff88007b593bc8 EFLAGS: 00010046
[ 202.164409] RAX: 0000000000000292 RBX: ffff88007a426990 RCX: 0000000000000000
[ 202.166246] RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffff88007a4269a4
[ 202.168089] RBP: ffff88007b593be8 R08: 0000000000000292 R09: 0000000000000300
[ 202.169992] R10: ffffffff81594cbe R11: ffff88007f803600 R12: ffff88007a426990
[ 202.171916] R13: ffff88007a4269a4 R14: 0000000000000000 R15: ffff88007a426900
[ 202.173815] FS: 00007f8233198980(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 202.175936] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 202.177467] CR2: 0000000000000000 CR3: 000000004eb73000 CR4: 00000000000407f0
[ 202.179411] Stack:
[ 202.179967] 0000000000000020 ffff88007a426990 0000000000000020 0000000000000000
[ 202.182006] ffff88007b593ca8 ffffffff816479ed ffff88007a426990 ffff88007b593d10
[ 202.184061] 0000002000000000 ffff88007b593cc8 0000000000000020 ffff88007a426bf8
[ 202.186124] Call Trace:
[ 202.186817] [<ffffffff816479ed>] unix_stream_sendmsg+0x1dd/0x430
[ 202.188440] [<ffffffff8158a9e3>] sock_aio_write+0x103/0x140
[ 202.189938] [<ffffffff811b2fbc>] do_sync_readv_writev+0x4c/0x80
[ 202.191531] [<ffffffff811b4965>] do_readv_writev+0x1e5/0x280
[ 202.193053] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 202.194496] [<ffffffff81103264>] ? __audit_syscall_entry+0xb4/0x110
[ 202.196181] [<ffffffff811b4a89>] vfs_writev+0x39/0x50
[ 202.197506] [<ffffffff811b4bba>] SyS_writev+0x4a/0xd0
[ 202.198855] [<ffffffff811034f6>] ? __audit_syscall_exit+0x236/0x2e0
[ 202.200550] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 202.202137] Code: 8d 6f 14 41 54 49 89 f4 53 48 89 fb 4c 89 ef 48 83 ec 08 e8 dc 19 11 00 48 8b 53 08 49 89 1c 24 4c 89 ef 48 89 c6 49 89 54 24 08 <4c> 89 22 83 43 10 01 4c 89 63 08 e8 09 16 11 00 48 83 c4 08 5b
[ 202.208943] RIP [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 202.210471] RSP <ffff88007b593bc8>
[ 202.211382] CR2: 0000000000000000
[ 313.016314] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 313.018432] IP: [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 313.019982] PGD 79fe4067 PUD 7879b067 PMD 0
[ 313.021183] Oops: 0002 [#1] SMP
[ 313.022081] Modules linked in: stap_1d434baec036a3abf082a3f3fc53e337_4681(OE) ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul dm_mirror crc32_pclmul dm_region_hash crc32c_intel dm_log ghash_clmulni_intel aesni_intel dm_mod glue_helper lrw gf128mul ablk_helper cryptd ppdev vmw_balloon microcode serio_raw parport_pc pcspkr vmw_vmci shpchp parport i2c_piix4 nfsd auth_rpcgss nfs_acl lockd grace sunrpc uinput sd_mod ata_generic pata_acpi ata_piix libata mptspi scsi_transport_spi mptscsi
h e1000 mptbase floppy
[ 313.041970] CPU: 0 PID: 2928 Comm: Xorg Tainted: G W OE 3.19.0-rc3+ #9
[ 313.043692] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 313.046200] task: ffff88007a3fa300 ti: ffff880079f08000 task.ti: ffff880079f08000
[ 313.047972] RIP: 0010:[<ffffffff81593577>] [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 313.049940] RSP: 0018:ffff880079f0bbc8 EFLAGS: 00010046
[ 313.051209] RAX: 0000000000000292 RBX: ffff88007a0c3510 RCX: 0000000000000000
[ 313.052892] RDX: 0000000000000000 RSI: 0000000000000292 RDI: ffff88007a0c3524
[ 313.054572] RBP: ffff880079f0bbe8 R08: 0000000000000292 R09: 0000000000000300
[ 313.056254] R10: ffffffff81594cbe R11: ffff88007f803600 R12: ffff88007a0c3510
[ 313.057957] R13: ffff88007a0c3524 R14: 0000000000000000 R15: ffff88007a0c3480
[ 313.059642] FS: 00007fa68e9b5980(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
[ 313.061536] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 313.062881] CR2: 0000000000000000 CR3: 000000007c026000 CR4: 00000000000407f0
[ 313.064617] Stack:
[ 313.065110] 0000000000000020 ffff88007a0c3510 0000000000000020 0000000000000000
[ 313.066962] ffff880079f0bca8 ffffffff816479ed ffff88007a0c3510 ffff880079f0bd10
[ 313.068809] 0000002000000000 ffff880079f0bcc8 0000000000000020 ffff88007a0c3778
[ 313.070667] Call Trace:
[ 313.071263] [<ffffffff816479ed>] unix_stream_sendmsg+0x1dd/0x430
[ 313.072710] [<ffffffff8158a9e3>] sock_aio_write+0x103/0x140
[ 313.074281] [<ffffffff811b2fbc>] do_sync_readv_writev+0x4c/0x80
[ 313.075706] [<ffffffff811b4965>] do_readv_writev+0x1e5/0x280
[ 313.077070] [<ffffffff810ce4c9>] ? enqueue_hrtimer+0x29/0x90
[ 313.078437] [<ffffffff811d0745>] ? __fget_light+0x25/0x70
[ 313.079731] [<ffffffff81103264>] ? __audit_syscall_entry+0xb4/0x110
[ 313.081225] [<ffffffff811b4a89>] vfs_writev+0x39/0x50
[ 313.082450] [<ffffffff811b4bba>] SyS_writev+0x4a/0xd0
[ 313.083680] [<ffffffff811034f6>] ? __audit_syscall_exit+0x236/0x2e0
[ 313.085186] [<ffffffff816a52e9>] system_call_fastpath+0x12/0x17
[ 313.086609] Code: 8d 6f 14 41 54 49 89 f4 53 48 89 fb 4c 89 ef 48 83 ec 08 e8 dc 19 11 00 48 8b 53 08 49 89 1c 24 4c 89 ef 48 89 c6 49 89 54 24 08 <4c> 89 22 83 43 10 01 4c 89 63 08 e8 09 16 11 00 48 83 c4 08 5b
[ 313.093012] RIP [<ffffffff81593577>] skb_queue_tail+0x37/0x60
[ 313.094408] RSP <ffff880079f0bbc8>
[ 313.095233] CR2: 0000000000000000
[ 207.542992] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 207.545125] IP: [<ffffffff81536cc3>] skb_queue_tail+0x33/0x50
[ 207.546719] PGD 49067 PUD 1a3067 PMD 0
[ 207.547815] Oops: 0002 [#1] SMP
[ 207.548725] Modules linked in: stap_a22ae6d0c4bc77fa650b27434e28e712_2992(OF) ip6t_rpfilter ip6t_REJECT ipt_REJECT xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_raw iptable_filter ip_tables coretemp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel dm_mirror glue_helper dm_region_hash lrw gf128mul dm_log ablk_helper dm_mod cryptd microcode vmw_balloon ppdev parport_pc serio_raw pcspkr vmw_vmci parport shpchp i2c_piix4 nfsd auth_rpcgss nfs_acl lockd sunrpc uinput sd_mod ata_generic pata_acpi mptspi scsi_transport_spi mpt
scsih mptbase ata_piix libata e1000 floppy
[ 207.568456] CPU: 3 PID: 3016 Comm: Xorg Tainted: GF W O 3.14.0+ #12
[ 207.570127] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 07/31/2013
[ 207.572653] task: ffff88007bf4baa0 ti: ffff88007a230000 task.ti: ffff88007a230000
[ 207.574431] RIP: 0010:[<ffffffff81536cc3>] [<ffffffff81536cc3>] skb_queue_tail+0x33/0x50
[ 207.576378] RSP: 0018:ffff88007a231c70 EFLAGS: 00010046
[ 207.577655] RAX: 0000000000000246 RBX: ffff8800221c4190 RCX: 0000000000000000
[ 207.579361] RDX: 0000000000000000 RSI: 0000000000000246 RDI: ffff8800221c41a4
[ 207.581034] RBP: ffff88007a231c88 R08: 0000000000000246 R09: 0000000000000300
[ 207.582752] R10: ffff88003c3cc900 R11: 0000000000000020 R12: ffff8800221c4190
[ 207.584445] R13: ffff8800221c41a4 R14: ffff8800221c4100 R15: 0000000000000000
[ 207.586114] FS: 00007f91fc263980(0000) GS:ffff88007fcc0000(0000) knlGS:0000000000000000
[ 207.588011] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 207.589752] CR2: 0000000000000000 CR3: 0000000000139000 CR4: 00000000000407e0
[ 207.591514] Stack:
[ 207.592046] ffff8800221c4190 0000000000000020 0000000000000000 ffff88007a231d30
[ 207.594108] ffffffff815e2018 ffff8800221c4190 0000002000000059 ffff88007a231d40
[ 207.596194] 0000000000000020 ffff8800221c43e8 ffff88007a231d78 ffff88007b22ef80
[ 207.598156] Call Trace:
[ 207.598774] [<ffffffff815e2018>] unix_stream_sendmsg+0x1b8/0x3f0
[ 207.600297] [<ffffffff8152dde7>] sock_aio_write+0xd7/0xf0
[ 207.601750] [<ffffffff811d1eb8>] ? fsnotify+0x228/0x2f0
[ 207.603077] [<ffffffff81190e9c>] do_sync_readv_writev+0x4c/0x80
[ 207.604638] [<ffffffff81192300>] do_readv_writev+0xb0/0x220
[ 207.606030] [<ffffffff8108c91a>] ? __hrtimer_start_range_ns+0x1aa/0x380
[ 207.607678] [<ffffffff8142154e>] ? vmw_unlocked_ioctl+0x4e/0x70
[ 207.609322] [<ffffffff811a3e60>] ? do_vfs_ioctl+0x2e0/0x4c0
[ 207.610728] [<ffffffff811924f0>] vfs_writev+0x30/0x60
[ 207.612081] [<ffffffff8119263a>] SyS_writev+0x4a/0xd0
[ 207.613369] [<ffffffff81645da9>] system_call_fastpath+0x16/0x1b
[ 207.614896] Code: e5 41 55 4c 8d 6f 14 41 54 49 89 f4 53 48 89 fb 4c 89 ef e8 00 7c 10 00 48 8b 53 08 49 89 1c 24 4c 89 ef 48 89 c6 49 89 54 24 08 <4c> 89 22 83 43 10 01 4c 89 63 08 e8 dd 79 10 00 5b 41 5c 41 5d
[ 207.621107] RIP [<ffffffff81536cc3>] skb_queue_tail+0x33/0x50
[ 207.622519] RSP <ffff88007a231c70>
[ 207.623354] CR2: 0000000000000000
^ permalink raw reply
* Re: [PATCH net-next 16/16] tipc: make netlink support net namespace
From: Sergei Shtylyov @ 2015-01-09 13:42 UTC (permalink / raw)
To: Ying Xue, davem
Cc: jon.maloy, Tero.Aho, Paul.Gortmaker, erik.hugne, richard.alpe,
netdev, tipc-discussion
In-Reply-To: <1420788433-17960-17-git-send-email-ying.xue@windriver.com>
Hello.
On 1/9/2015 10:27 AM, Ying Xue wrote:
> Currently tipc module only allows users sitting on "init_net" namespace
> to configure it through netlink interface. But now almost each tipc
> component is able to be aware of net namespace, so it's time to open
> the permission for users residing in other namespaces, allowing them
> to configure their own tipc stack instance through netlink interface.
> Signed-off-by: Ying Xue <ying.xue@windriver.com>
> Tested-by: Tero Aho <Tero.Aho@coriant.com>
> Reviewed-by: Jon Maloy <jon.maloy@ericsson.com>
> ---
> net/tipc/netlink.c | 7 +++++--
> 1 file changed, 5 insertions(+), 2 deletions(-)
> diff --git a/net/tipc/netlink.c b/net/tipc/netlink.c
> index 282b596..fe0f513 100644
> --- a/net/tipc/netlink.c
> +++ b/net/tipc/netlink.c
> @@ -54,7 +54,8 @@ static int handle_cmd(struct sk_buff *skb, struct genl_info *info)
> int hdr_space = nlmsg_total_size(GENL_HDRLEN + TIPC_GENL_HDRLEN);
> u16 cmd;
>
> - if ((req_userhdr->cmd & 0xC000) && (!netlink_capable(skb, CAP_NET_ADMIN)))
> + if ((req_userhdr->cmd & 0xC000) &&
> + (!netlink_net_capable(skb, CAP_NET_ADMIN)))
Why? Also, it seems like unrelated change...
[...]
WBR, Sergei
^ permalink raw reply
* Re: Winning Notification !!!
From: UK FREE LOTTO @ 2015-01-09 13:27 UTC (permalink / raw)
Your email ID has made you a bonafide winner of the sum of $2,000,000.00 USD, Provide your Name,Country,Occupation and Tel. So that your winning will be activate and open to your name.
^ permalink raw reply
* Re: [PATCH] ethernet: atheros: Add nss-gmac driver
From: Mark Rutland @ 2015-01-09 13:50 UTC (permalink / raw)
To: Stephen Wang
Cc: jcliburn-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1420754626-30121-1-git-send-email-wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Thu, Jan 08, 2015 at 10:03:46PM +0000, Stephen Wang wrote:
> This driver adds support for the internal GMACs on IPQ806x SoCs.
> It supports the device-tree and will register up to 4 ethernet
> interfaces.
>
> Signed-off-by: Stephen Wang <wstephen-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
> ---
> drivers/net/ethernet/atheros/Kconfig | 10 +
> drivers/net/ethernet/atheros/Makefile | 1 +
> drivers/net/ethernet/atheros/nss-gmac/LICENSE.txt | 14 +
> drivers/net/ethernet/atheros/nss-gmac/Makefile | 19 +
> .../atheros/nss-gmac/exports/nss_gmac_api_if.h | 126 ++
> .../atheros/nss-gmac/include/msm_nss_gmac.h | 338 ++++
> .../atheros/nss-gmac/include/msm_nss_macsec.h | 73 +
> .../atheros/nss-gmac/include/nss_gmac_clocks.h | 100 +
> .../atheros/nss-gmac/include/nss_gmac_dev.h | 2136 ++++++++++++++++++++
> .../nss-gmac/include/nss_gmac_network_interface.h | 63 +
> .../net/ethernet/atheros/nss-gmac/nss_gmac_ctrl.c | 1210 +++++++++++
> .../net/ethernet/atheros/nss-gmac/nss_gmac_dev.c | 1963 ++++++++++++++++++
> .../ethernet/atheros/nss-gmac/nss_gmac_ethtool.c | 526 +++++
> .../net/ethernet/atheros/nss-gmac/nss_gmac_init.c | 1131 +++++++++++
> .../ethernet/atheros/nss-gmac/nss_gmac_mdiobus.c | 187 ++
> .../atheros/nss-gmac/nss_gmac_tx_rx_offload.c | 1175 +++++++++++
Device tree bindings _must_ be documented, yet this standalone patch
adds nothing to Documentation/devicetree/bindings per the diffstat
above. So trivial NAK until there's a patch documenting that.
See Documentation/devicetree/bindings/submitting-patches.txt
Thanks,
Mark.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v3 4/4] can: kvaser_usb: Add support for the Usbcan-II family
From: Marc Kleine-Budde @ 2015-01-09 14:05 UTC (permalink / raw)
To: Ahmed S. Darwish
Cc: Olivier Sobrie, Oliver Hartkopp, Wolfgang Grandegger,
David S. Miller, Paul Gortmaker, Linux-CAN, netdev, LKML
In-Reply-To: <20150109030657.GA1791@vivalin-002>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
On 01/09/2015 04:06 AM, Ahmed S. Darwish wrote:
>>>
>>> cf->can_id |= CAN_ERR_CRTL;
>>> cf->data[1] = CAN_ERR_CRTL_RX_OVERFLOW;
>>>
>>> stats->rx_over_errors++;
>>> stats->rx_errors++;
>>>
>>> netif_rx(skb);
>>>
>>> stats->rx_packets++;
>>> stats->rx_bytes += cf->can_dlc;
>>
>> Another patch would be not to touch cf after netif_rx(), please
>> move the stats handling before calling netif_rx(). Same applies to
>> the kvaser_usb_rx_can_msg() function.
> BTW, is it guaranteed from the SocketCAN stack that netif_rx()
netif_rx() is the generic networking stack already.
> will never return NET_RX_DROPPED? Because if no guarantee
> exists, I guess below fragment cannot be completely correct?
No, it's not guaranteed...
>
> stats->rx_packets++;
> stats->rx_bytes += cf->can_dlc;
> netif_rx(skb);
>
> On the other hand, I don't see evan a single CAN driver checking
> netif_rx() return value, so maybe such a check is an overkill...
A quick look shows that almost no ethernet or wireless drivers take care
about the return value. In case of a RX_DROPPED some increase a drop
counter, though.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH iproute2 3/3] ip netns: Delete all netns
From: Nicolas Dichtel @ 2015-01-09 14:24 UTC (permalink / raw)
To: Vadim Kochan, Jiri Benc; +Cc: Brian Haley, netdev@vger.kernel.org
In-Reply-To: <CAMw6YJLx0O6dVnD2XcmF+qz+=m51TyZOqJWSYGKQ-XrMHP8z3w@mail.gmail.com>
Le 09/01/2015 10:54, Vadim Kochan a écrit :
> Ok,
>
> If I will re-work to use new option, would it be useful ? So it will look:
>
> $ ip -all netns del
> $ ip -all netns exec ip link
> $ ip -all netns exec ip route add ...
>
> Seems not so weird to me ?
What about making this new option only for the 'netns' subsystem?
Something like: 'ip netns -all exec'?
Regards,
Nicolas
^ permalink raw reply
* [PATCH 1/1] openvswitch: Remove unnecessary version.h inclusion
From: Syam Sidhardhan @ 2015-01-09 14:56 UTC (permalink / raw)
To: netdev, syamsidhardh, pshelar, davem, dev; +Cc: Syam Sidhardhan
version.h inclusion is not necessary as detected by versioncheck.
Signed-off-by: Syam Sidhardhan <s.syam@samsung.com>
---
net/openvswitch/vport-geneve.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/openvswitch/vport-geneve.c b/net/openvswitch/vport-geneve.c
index 347fa23..70e2aae 100644
--- a/net/openvswitch/vport-geneve.c
+++ b/net/openvswitch/vport-geneve.c
@@ -9,8 +9,6 @@
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-#include <linux/version.h>
-
#include <linux/in.h>
#include <linux/ip.h>
#include <linux/net.h>
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] mdio-mux-gpio: use new gpiod_get_array and gpiod_put_array functions
From: Rojhalat Ibrahim @ 2015-01-09 15:19 UTC (permalink / raw)
To: linux-gpio@vger.kernel.org
Cc: Alexandre Courbot, Linus Walleij, David Miller, netdev
Use the new gpiod_get_array and gpiod_put_array functions for obtaining and
disposing of GPIO descriptors.
Signed-off-by: Rojhalat Ibrahim <imr@rtschenk.de>
---
This patch depends on my previous patch "gpiolib: add gpiod_get_array and
gpiod_put_array functions".
drivers/net/phy/mdio-mux-gpio.c | 28 ++++++++--------------------
1 file changed, 8 insertions(+), 20 deletions(-)
diff --git a/drivers/net/phy/mdio-mux-gpio.c b/drivers/net/phy/mdio-mux-gpio.c
index 1eaf81e..35c37da 100644
--- a/drivers/net/phy/mdio-mux-gpio.c
+++ b/drivers/net/phy/mdio-mux-gpio.c
@@ -47,7 +47,6 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
{
struct mdio_mux_gpio_state *s;
int num_gpios;
- unsigned int n;
int r;
if (!pdev->dev.of_node)
@@ -63,16 +62,10 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
s->num_gpios = num_gpios;
- for (n = 0; n < num_gpios; ) {
- struct gpio_desc *gpio = gpiod_get_index(&pdev->dev, NULL, n,
- GPIOD_OUT_LOW);
- if (IS_ERR(gpio)) {
- r = PTR_ERR(gpio);
- goto err;
- }
- s->gpio[n] = gpio;
- n++;
- }
+ r = gpiod_get_array(&pdev->dev, NULL, s->gpio, num_gpios,
+ GPIOD_OUT_LOW);
+ if (r != num_gpios)
+ return r;
r = mdio_mux_init(&pdev->dev,
mdio_mux_gpio_switch_fn, &s->mux_handle, s);
@@ -80,22 +73,17 @@ static int mdio_mux_gpio_probe(struct platform_device *pdev)
if (r == 0) {
pdev->dev.platform_data = s;
return 0;
+ } else {
+ gpiod_put_array(s->gpio, num_gpios);
+ return r;
}
-err:
- while (n) {
- n--;
- gpiod_put(s->gpio[n]);
- }
- return r;
}
static int mdio_mux_gpio_remove(struct platform_device *pdev)
{
- unsigned int n;
struct mdio_mux_gpio_state *s = dev_get_platdata(&pdev->dev);
mdio_mux_uninit(s->mux_handle);
- for (n = 0; n < s->num_gpios; n++)
- gpiod_put(s->gpio[n]);
+ gpiod_put_array(s->gpio, s->num_gpios);
return 0;
}
--
2.0.5
^ permalink raw reply related
* [PATCH net-next v2 0/8]r8169:update hardware parameter
From: Chunhao Lin @ 2015-01-09 15:25 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
These series of patch include the pcie ephy parameter update of
following adapters.
rtl8411
rtl8168f
rtl8168evl
rtl8168dp
rtl8105
rtl8402
And include jumbo frame patch update of following adapters.
rtl8168dp
rtl8168e
rtl8168evl
Also remove unnecessary function rtl_hw_start_8168dp and add function
rtl_hw_start_8168f_2 to set rtl8168f rev.b pcie ephy parameters.
In v2 patch, give more explanation about pcie ephy parameter update.
Chunhao Lin (8):
r8169:change rtl8168dp jumbo frame patch
r8169:update rtl8168e and rtl8168evl jumbo frame patch
r8169:correct the way of setting rtl8168dp pcie ephy parameters
r8169:rtl8168dp rev.c pcie ephy setting is the same as rtl8168dp rev.b
r8169:update rtl8168dp pcie ephy parameters to improve power
consumption
r8169:update pcie ephy parameters to decrease the resume time from L0s
to L0
r8169:update rtl8402 pcie ephy parameter
r8169:update rtl8168f rev.b pcie ephy parameter
drivers/net/ethernet/realtek/r8169.c | 112 +++++++++++++++--------------------
1 file changed, 49 insertions(+), 63 deletions(-)
--
1.9.1
^ permalink raw reply
* [PATCH net-next v2 1/8] r8169:change rtl8168dp jumbo frame patch
From: Chunhao Lin @ 2015-01-09 15:25 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168DP jumbo frame patch is the same as RTL8168C. So, for RTL8168DP,
change to use RTL8168C jumbo frame patch. Also reomve uncessary function
"r8168dp_hw_jumbo_enable" and "r8168dp_hw_jumbo_disable".
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 28 ++++++----------------------
1 file changed, 6 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 3a28059..72d15b8 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4927,20 +4927,6 @@ static void r8168c_hw_jumbo_disable(struct rtl8169_private *tp)
rtl_tx_performance_tweak(tp->pci_dev, 0x5 << MAX_READ_REQUEST_SHIFT);
}
-static void r8168dp_hw_jumbo_enable(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
-
- RTL_W8(Config3, RTL_R8(Config3) | Jumbo_En0);
-}
-
-static void r8168dp_hw_jumbo_disable(struct rtl8169_private *tp)
-{
- void __iomem *ioaddr = tp->mmio_addr;
-
- RTL_W8(Config3, RTL_R8(Config3) & ~Jumbo_En0);
-}
-
static void r8168e_hw_jumbo_enable(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
@@ -5014,16 +5000,13 @@ static void rtl_init_jumbo_ops(struct rtl8169_private *tp)
case RTL_GIGA_MAC_VER_24:
case RTL_GIGA_MAC_VER_25:
case RTL_GIGA_MAC_VER_26:
- ops->disable = r8168c_hw_jumbo_disable;
- ops->enable = r8168c_hw_jumbo_enable;
- break;
case RTL_GIGA_MAC_VER_27:
case RTL_GIGA_MAC_VER_28:
- ops->disable = r8168dp_hw_jumbo_disable;
- ops->enable = r8168dp_hw_jumbo_enable;
+ case RTL_GIGA_MAC_VER_31:
+ ops->disable = r8168c_hw_jumbo_disable;
+ ops->enable = r8168c_hw_jumbo_enable;
break;
- case RTL_GIGA_MAC_VER_31: /* Wild guess. Needs info from Realtek. */
- case RTL_GIGA_MAC_VER_32:
+ case RTL_GIGA_MAC_VER_32: /* Wild guess. Needs info from Realtek. */
case RTL_GIGA_MAC_VER_33:
case RTL_GIGA_MAC_VER_34:
ops->disable = r8168e_hw_jumbo_disable;
@@ -5758,7 +5741,8 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
rtl_csi_access_enable_1(tp);
- rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
+ if (tp->dev->mtu <= ETH_DATA_LEN)
+ rtl_tx_performance_tweak(pdev, 0x5 << MAX_READ_REQUEST_SHIFT);
RTL_W8(MaxTxPacketSize, TxPacketMax);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 2/8] r8169:update rtl8168e and rtl8168evl jumbo frame patch
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
RTL8168E and RTL8168EVL do not need to change pcie max read request size
when jumbo frame is enabled. So remove setting pcie max read request
size from their jumbo frame patch.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 72d15b8..991bda5 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -4934,7 +4934,6 @@ static void r8168e_hw_jumbo_enable(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, 0x3f);
RTL_W8(Config3, RTL_R8(Config3) | Jumbo_En0);
RTL_W8(Config4, RTL_R8(Config4) | 0x01);
- rtl_tx_performance_tweak(tp->pci_dev, 0x2 << MAX_READ_REQUEST_SHIFT);
}
static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
@@ -4944,7 +4943,6 @@ static void r8168e_hw_jumbo_disable(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, 0x0c);
RTL_W8(Config3, RTL_R8(Config3) & ~Jumbo_En0);
RTL_W8(Config4, RTL_R8(Config4) & ~0x01);
- rtl_tx_performance_tweak(tp->pci_dev, 0x5 << MAX_READ_REQUEST_SHIFT);
}
static void r8168b_0_hw_jumbo_enable(struct rtl8169_private *tp)
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 3/8] r8169:correct the way of setting rtl8168dp pcie ephy parameters
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
The original way is wrong, it always sets the ephy reg 0x03. Correct it
in this patch.
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 15 ++++-----------
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 991bda5..540a6b8 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5731,11 +5731,10 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
void __iomem *ioaddr = tp->mmio_addr;
struct pci_dev *pdev = tp->pci_dev;
static const struct ephy_info e_info_8168d_4[] = {
- { 0x0b, ~0, 0x48 },
- { 0x19, 0x20, 0x50 },
- { 0x0c, ~0, 0x20 }
+ { 0x0b, 0x0000, 0x0048 },
+ { 0x19, 0x0020, 0x0050 },
+ { 0x0c, 0x0100, 0x0020 }
};
- int i;
rtl_csi_access_enable_1(tp);
@@ -5744,13 +5743,7 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
RTL_W8(MaxTxPacketSize, TxPacketMax);
- for (i = 0; i < ARRAY_SIZE(e_info_8168d_4); i++) {
- const struct ephy_info *e = e_info_8168d_4 + i;
- u16 w;
-
- w = rtl_ephy_read(tp, e->offset);
- rtl_ephy_write(tp, 0x03, (w & e->mask) | e->bits);
- }
+ rtl_ephy_init(tp, e_info_8168d_4, ARRAY_SIZE(e_info_8168d_4));
rtl_enable_clock_request(pdev);
}
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 5/8] r8169:update rtl8168dp pcie ephy parameters to improve power consumption
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
The following parameter will disable more pcie ephy block (like pcie ephy
read/write clock.....etc ) to save more power when in aspm+clkreq mode.
{ 0x10, 0x0004, 0x0000 }
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 928e35a..ade7144 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -5718,7 +5718,8 @@ static void rtl_hw_start_8168d_4(struct rtl8169_private *tp)
static const struct ephy_info e_info_8168d_4[] = {
{ 0x0b, 0x0000, 0x0048 },
{ 0x19, 0x0020, 0x0050 },
- { 0x0c, 0x0100, 0x0020 }
+ { 0x0c, 0x0100, 0x0020 },
+ { 0x10, 0x0004, 0x0000 }
};
rtl_csi_access_enable_1(tp);
--
1.9.1
^ permalink raw reply related
* [PATCH net-next v2 7/8] r8169:update rtl8402 pcie ephy parameter
From: Chunhao Lin @ 2015-01-09 15:26 UTC (permalink / raw)
To: netdev; +Cc: nic_swsd, linux-kernel, Chunhao Lin
In-Reply-To: <1420817166-9868-1-git-send-email-hau@realtek.com>
Remove following unnecessary ephy parameter.
{ 0x1e, 0, 0x4000 }
Signed-off-by: Chunhao Lin <hau@realtek.com>
---
drivers/net/ethernet/realtek/r8169.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/realtek/r8169.c b/drivers/net/ethernet/realtek/r8169.c
index 483fa40..aa12833 100644
--- a/drivers/net/ethernet/realtek/r8169.c
+++ b/drivers/net/ethernet/realtek/r8169.c
@@ -6431,8 +6431,7 @@ static void rtl_hw_start_8402(struct rtl8169_private *tp)
{
void __iomem *ioaddr = tp->mmio_addr;
static const struct ephy_info e_info_8402[] = {
- { 0x19, 0xffff, 0xff64 },
- { 0x1e, 0, 0x4000 }
+ { 0x19, 0xffff, 0xff64 }
};
rtl_csi_access_enable_2(tp);
--
1.9.1
^ 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