* [PATCH 2/3] ixgb: Add missing dma_mapping_error-call in ixgb_alloc_rx_buffers
From: Christoph Paasch @ 2013-03-16 10:32 UTC (permalink / raw)
To: Jeff Kirsher, Bruce Allan, Alex Duyck; +Cc: e1000-devel, netdev, David Miller
In-Reply-To: <1363429925-12724-1-git-send-email-christoph.paasch@uclouvain.be>
After dma_map_single, dma_mapping_error must be called. It seems safe to
not free the skb allocated in this function, as the skb can be reused
later.
Additionally this patch fixes one coding-style error.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/ethernet/intel/ixgb/ixgb_main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgb/ixgb_main.c b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
index e23f023..6662c7c 100644
--- a/drivers/net/ethernet/intel/ixgb/ixgb_main.c
+++ b/drivers/net/ethernet/intel/ixgb/ixgb_main.c
@@ -2155,6 +2155,10 @@ map_skb:
skb->data,
adapter->rx_buffer_len,
DMA_FROM_DEVICE);
+ if (dma_mapping_error(&pdev->dev, buffer_info->dma)) {
+ adapter->alloc_rx_buff_failed++;
+ break;
+ }
rx_desc = IXGB_RX_DESC(*rx_ring, i);
rx_desc->buff_addr = cpu_to_le64(buffer_info->dma);
@@ -2164,7 +2168,8 @@ map_skb:
rx_desc->status = 0;
- if (++i == rx_ring->count) i = 0;
+ if (++i == rx_ring->count)
+ i = 0;
buffer_info = &rx_ring->buffer_info[i];
}
--
1.8.1.227.g44fe835
^ permalink raw reply related
* [PATCH 1/1] connector: Added coredumping event to the process connector
From: Jesper Derehag @ 2013-03-16 10:50 UTC (permalink / raw)
To: Evgeniy Polyakov; +Cc: netdev, Jesper Derehag
Process connector can now also detect coredumping events. Could be used for instance by process-managers that want to get notified immediatly at process crash instead of waiting for exit.
Signed-off-by: Jesper Derehag <jderehag@hotmail.com>
---
drivers/connector/cn_proc.c | 27 +++++++++++++++++++++++++++
include/linux/cn_proc.h | 4 ++++
include/uapi/linux/cn_proc.h | 6 ++++--
kernel/signal.c | 2 ++
4 filer ändrade, 37 tillägg(+), 2 borttagningar(-)
diff --git a/drivers/connector/cn_proc.c b/drivers/connector/cn_proc.c
index 1110478..325f11c 100644
--- a/drivers/connector/cn_proc.c
+++ b/drivers/connector/cn_proc.c
@@ -232,6 +232,33 @@ void proc_comm_connector(struct task_struct *task)
cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
}
+void proc_coredump_connector(struct task_struct *task)
+{
+ struct cn_msg *msg;
+ struct proc_event *ev;
+ __u8 buffer[CN_PROC_MSG_SIZE];
+ struct timespec ts;
+
+ if (atomic_read(&proc_event_num_listeners) < 1)
+ return;
+
+ msg = (struct cn_msg *)buffer;
+ ev = (struct proc_event *)msg->data;
+ get_seq(&msg->seq, &ev->cpu);
+ ktime_get_ts(&ts); /* get high res monotonic timestamp */
+ put_unaligned(timespec_to_ns(&ts), (__u64 *)&ev->timestamp_ns);
+ ev->what = PROC_EVENT_COREDUMP;
+ ev->event_data.exit.process_pid = task->pid;
+ ev->event_data.exit.process_tgid = task->tgid;
+ ev->event_data.exit.exit_code = task->exit_code;
+ ev->event_data.exit.exit_signal = task->exit_signal;
+
+ memcpy(&msg->id, &cn_proc_event_id, sizeof(msg->id));
+ msg->ack = 0; /* not used */
+ msg->len = sizeof(*ev);
+ cn_netlink_send(msg, CN_IDX_PROC, GFP_KERNEL);
+}
+
void proc_exit_connector(struct task_struct *task)
{
struct cn_msg *msg;
diff --git a/include/linux/cn_proc.h b/include/linux/cn_proc.h
index 2c1bc1e..1d5b02a 100644
--- a/include/linux/cn_proc.h
+++ b/include/linux/cn_proc.h
@@ -26,6 +26,7 @@ void proc_id_connector(struct task_struct *task, int which_id);
void proc_sid_connector(struct task_struct *task);
void proc_ptrace_connector(struct task_struct *task, int which_id);
void proc_comm_connector(struct task_struct *task);
+void proc_coredump_connector(struct task_struct *task);
void proc_exit_connector(struct task_struct *task);
#else
static inline void proc_fork_connector(struct task_struct *task)
@@ -48,6 +49,9 @@ static inline void proc_ptrace_connector(struct task_struct *task,
int ptrace_id)
{}
+static inline void proc_coredump_connector(struct task_struct *task)
+{}
+
static inline void proc_exit_connector(struct task_struct *task)
{}
#endif /* CONFIG_PROC_EVENTS */
diff --git a/include/uapi/linux/cn_proc.h b/include/uapi/linux/cn_proc.h
index 0d7b499..a46caf1 100644
--- a/include/uapi/linux/cn_proc.h
+++ b/include/uapi/linux/cn_proc.h
@@ -55,8 +55,10 @@ struct proc_event {
PROC_EVENT_SID = 0x00000080,
PROC_EVENT_PTRACE = 0x00000100,
PROC_EVENT_COMM = 0x00000200,
- /* "next" should be 0x00000400 */
- /* "last" is the last process event: exit */
+ /* "next" should be 0x00000400 */
+ /* "last" is the last process event: exit,
+ * while "next to last" is coredumping event */
+ PROC_EVENT_COREDUMP = 0x40000000,
PROC_EVENT_EXIT = 0x80000000
} what;
__u32 cpu;
diff --git a/kernel/signal.c b/kernel/signal.c
index d63c79e..e591731 100644
--- a/kernel/signal.c
+++ b/kernel/signal.c
@@ -32,6 +32,7 @@
#include <linux/user_namespace.h>
#include <linux/uprobes.h>
#include <linux/compat.h>
+#include <linux/cn_proc.h>
#define CREATE_TRACE_POINTS
#include <trace/events/signal.h>
@@ -2347,6 +2348,7 @@ relock:
if (sig_kernel_coredump(signr)) {
if (print_fatal_signals)
print_fatal_signal(info->si_signo);
+ proc_coredump_connector(current);
/*
* If it was able to dump core, this kills all
* other threads in the group and synchronizes with
--
1.7.10.4
^ permalink raw reply related
* Re: igb_poll - device driver failed to check map error
From: Christoph Paasch @ 2013-03-16 11:07 UTC (permalink / raw)
To: Alexander Duyck
Cc: Alexander Duyck, Jeff Kirsher, Jesse Brandeburg, Bruce Allan,
Eric Dumazet, netdev
In-Reply-To: <5143A9EF.6030302@intel.com>
On Friday 15 March 2013 16:08:31 Alexander Duyck wrote:
> On 03/15/2013 12:52 AM, Christoph Paasch wrote:
> > On Thursday 14 March 2013 19:18:18 Alexander Duyck wrote:
> >> On 03/12/2013 02:31 AM, Christoph Paasch wrote:
> >>> Hello,
> >>>
> >>> I'm seeing a warning while booting my machine when DMA_API_DEBUG is set:
> >>>
> >>> [ 36.402824] ------------[ cut here ]------------
> >>> [ 36.458070] WARNING: at
> >>> /home/cpaasch/builder/net-next/lib/dma-debug.c:934
> >>> check_unmap+0x648/0x702()
> >>> [ 36.567377] Hardware name: ProLiant DL165 G7
> >>> [ 36.618452] igb 0000:04:00.0: DMA-API: device driver failed to check
> >>> map
> >>> error[device address=0x0000000233d9b232] [size=154 bytes] [mapped as
> >>> single] [ 36.776640] Modules linked in:
> >>> [ 36.815446] Pid: 0, comm: swapper/7 Not tainted 3.9.0-rc1-mptcp+ #101
> >>> [ 36.892515] Call Trace:
> >>> [ 36.921745] <IRQ> [<ffffffff8102ad7f>]
> >>> warn_slowpath_common+0x80/0x9a
> >>> [ 37.001023] [<ffffffff8102ae2d>] warn_slowpath_fmt+0x41/0x43
> >>> [ 37.069771] [<ffffffff811db17f>] check_unmap+0x648/0x702
> >>> [ 37.134363] [<ffffffff811db3e9>] debug_dma_unmap_page+0x50/0x52
> >>> [ 37.206234] [<ffffffff8136676a>] igb_poll+0x144/0xf7c
> >>> [ 37.267706] [<ffffffff8104dd19>] ? sched_clock_cpu+0x46/0xd1
> >>> [ 37.336456] [<ffffffff814458ce>] net_rx_action+0xa7/0x1d0
> >>> [ 37.402085] [<ffffffff81030b65>] __do_softirq+0xb4/0x16f
> >>> [ 37.466673] [<ffffffff81030c90>] irq_exit+0x40/0x87
> >>> [ 37.526067] [<ffffffff81002db1>] do_IRQ+0x98/0xaf
> >>> [ 37.583378] [<ffffffff815210aa>] common_interrupt+0x6a/0x6a
> >>> [ 37.651086] <EOI> [<ffffffff8105d4be>] ?
> >>> __tick_nohz_idle_enter+0x116/0x31f
> >>> [ 37.736595] [<ffffffff81008a04>] ? default_idle+0x24/0x39
> >>> [ 37.802224] [<ffffffff81008c62>] cpu_idle+0x68/0xa4
> >>> [ 37.861616] [<ffffffff81519f78>] start_secondary+0x1a9/0x1ad
> >>> [ 37.930364] ---[ end trace 01b5bb0fd75a464c ]---
> >>>
> >>>
> >>> It happens shortly after mounting the NFS-root filesystem.
> >>>
> >>> I tried to understand what is going on, but I am now at my wit's end.
> >>>
> >>> By adding some print-statements, here is what I found out (not sure if
> >>> this is anyhow helpful):
> >>>
> >>> The difference between tx_buffer->time_stamp and the current 'jiffies'
> >>> is
> >>> up to 2000 jiffies (HZ==1000) at the first time the above warning
> >>> happens
> >>> (this seems too much for me). From then on, I see my print 3-4 times
> >>> appear but without such a big difference between the timestamps
> >>> (difference around 1 and 2 jiffies).
> >>>
> >>> Some other stuff, I printed:
> >>> tx_buffer->skb: ffff880235054c80
> >>> tx_buffer->bytecount: 154
> >>> tx_buffer->gso_segs: 1
> >>> tx_buffer->protocol: 8
> >>> tx_buffer->tx_flags 0x20
> >>>
> >>>
> >>> One last thing:
> >>> Am I right that after each call to dma_map_single/page a call to
> >>> dma_mapping_error is needed? If that's the case, I have some patches
> >>> that
> >>> add this statement at missing places in the e1000, e1000e and ixgb
> >>> driver. But these patches do not fix my above problem.
> >>>
> >>>
> >>> Thanks for your help,
> >>> Christoph
> >>
> >> Christoph,
> >>
> >> One thing that might be useful would be to reproduce this with a
> >> standard 3.9-rc kernel instead of one using the multipath TCP patches.
> >> This will help us to verify that the issue is reproducible with a stock
> >> kernel and is not related to any ongoing work you may have only in your
> >> tree.
> >
> > Hello,
> >
> > this is on a clean net-next kernel without any MPTCP-code.
> >
> > I bisected it down to 787314c35fbb (Merge tag 'iommu-updates-v3.8' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu), which simply
> > introduces the debug_dma_mapping_error-checks.
> >
> > Am I right with the missing calls to dma_mapping_error in e1000, e1000e
> > and
> > ixgb?
> >
> > Cheers,
> > Christoph
>
> Christoph,
>
> The cause of this issues you are seeing may be due to the fact that the
> buffer triggering the error is being reused. I was able to reproduce
> this issue occasionally with pktgen if I cloned the skb. What may be
> happening is that the buffer is being mapped in the transmit path on one
> CPU while on another CPU the buffer is being cleaned. Since the output
> of each mapping is the physical address there is nothing to make each
> mapping unique and I suspect this is resulting in false hits.
>
> You should be able to verify this if you were to check the skb->users
> count as well as the dataref value in the skb_shared_info. I suspect
> either the users count of the dataref will be greater than 1.
Both, users and dataref, are equal to 1. Before the call to dev_kfree_skb_any
and after dma_unmap_single fails.
> You might also try testing the patch below to see if it has any effect.
> All it does is reorder the free and the unmap so that the buffer is not
> freed for reuse until after we have checked it in the unmap path.
I tested your patch, and it fixes my issue. Feel free to add a "Tested-by" to
the official patch.
Cheers,
Christoph
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index 4dbd629..0f9c324 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -5959,15 +5959,15 @@ static bool igb_clean_tx_irq(struct igb_q_vector
> *q_vector)
> total_bytes += tx_buffer->bytecount;
> total_packets += tx_buffer->gso_segs;
>
> - /* free the skb */
> - dev_kfree_skb_any(tx_buffer->skb);
> -
> /* unmap skb header data */
> dma_unmap_single(tx_ring->dev,
> dma_unmap_addr(tx_buffer, dma),
> dma_unmap_len(tx_buffer, len),
> DMA_TO_DEVICE);
>
> + /* free the skb */
> + dev_kfree_skb_any(tx_buffer->skb);
> +
> /* clear tx_buffer data */
> tx_buffer->skb = NULL;
> dma_unmap_len_set(tx_buffer, len, 0);
--
IP Networking Lab --- http://inl.info.ucl.ac.be
MultiPath TCP in the Linux Kernel --- http://multipath-tcp.org
UCLouvain
--
^ permalink raw reply
* Re: [PATCH 1/5] net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
From: Florian Fainelli @ 2013-03-16 14:41 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Maxime Ripard, linux-doc, netdev, devicetree-discuss,
linux-kernel, Rob Herring, Grant Likely, Rob Landley, sunny,
shuge, Stefan Roese, kevin
In-Reply-To: <1363380605-6577-2-git-send-email-maxime.ripard@free-electrons.com>
Hello Maxime, Stefan,
Please find below some comments regarding your PHY implementation in the driver
as well as the transmit and transmit completion routines.
Le vendredi 15 mars 2013 21:50:00, Maxime Ripard a écrit :
> From: Stefan Roese <sr@denx.de>
>
> The Allwinner A10 has an ethernet controller that is advertised as
> coming from Davicom.
>
> The exact feature set of this controller is unknown, since there is no
> public documentation for this IP, and this driver is mostly the one
> published by Allwinner that has been heavily cleaned up.
>
> Signed-off-by: Stefan Roese <sr@denx.de>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
[snip]
> +
> +wemac: ethernet@01c0b000 {
> + compatible = "davicom,wemac";
> + reg = <0x01c0b000 0x1000>;
> + interrupts = <55>;
> + allwinner,power-gpios = <&pio 7 19 0>;
> +};
You do not define any handle for the PHY chip, but I think you should make this
configurable and use the standard Device Tree helpers for finding and connecting
a PHY driver to your EMAC adapter driver.
[snip]
> +#define WEMAC_PHY 0x100 /* PHY address 0x01 */
This should be made configurable if possible.
[snip]
> + */
> +
> +struct wemac_board_info {
> + struct clk *clk;
> + struct device *dev;
> + spinlock_t lock;
> + void __iomem *membase;
> + struct mii_if_info mii;
> + u32 msg_enable;
> + struct net_device *ndev;
> + struct mutex phy_lock;
> + struct delayed_work phy_poll;
Consider using phylib which should allow you to remove struct mii_if_info and
the mutex and poll delayed workqueue.
> + unsigned power_gpio;
you could make this an int, so that you use gpio_is_valid() on this one.
> + struct sk_buff *skb_last;
> + u16 tx_fifo_stat;
> +};
> +
> +static inline struct wemac_board_info *to_wemac_board(struct net_device
> *dev) +{
> + return netdev_priv(dev);
> +}
> +
> +static int wemac_phy_read(struct net_device *dev, int phyaddr, int reg)
> +{
> + struct wemac_board_info *db = netdev_priv(dev);
> + unsigned long flags;
> + int ret;
> +
> + mutex_lock(&db->phy_lock);
> +
> + spin_lock_irqsave(&db->lock, flags);
> + /* issue the phy address and reg */
> + writel(phyaddr | reg, db->membase + EMAC_MAC_MADR_REG);
> + /* pull up the phy io line */
> + writel(0x1, db->membase + EMAC_MAC_MCMD_REG);
> + spin_unlock_irqrestore(&db->lock, flags);
> +
> + /* Wait read complete */
> + mdelay(1);
> +
> + /* push down the phy io line and read data */
> + spin_lock_irqsave(&db->lock, flags);
> + /* push down the phy io line */
> + writel(0x0, db->membase + EMAC_MAC_MCMD_REG);
> + /* and read data */
> + ret = readl(db->membase + EMAC_MAC_MRDD_REG);
> + spin_unlock_irqrestore(&db->lock, flags);
> +
> + mutex_unlock(&db->phy_lock);
This sounds pretty complicated as a locking scheme, using phylib should make
this simpler anyway.
> +
> + return ret;
> +}
> +
> +/* Write a word to phyxcer */
> +static void wemac_phy_write(struct net_device *dev,
> + int phyaddr, int reg, int value)
> +{
> + struct wemac_board_info *db = netdev_priv(dev);
> + unsigned long flags;
> +
> + mutex_lock(&db->phy_lock);
> +
> + spin_lock_irqsave(&db->lock, flags);
> + /* issue the phy address and reg */
> + writel(phyaddr | reg, db->membase + EMAC_MAC_MADR_REG);
> + /* pull up the phy io line */
> + writel(0x1, db->membase + EMAC_MAC_MCMD_REG);
> + spin_unlock_irqrestore(&db->lock, flags);
> +
> + /* Wait write complete */
> + mdelay(1);
> +
> + spin_lock_irqsave(&db->lock, flags);
> + /* push down the phy io line */
> + writel(0x0, db->membase + EMAC_MAC_MCMD_REG);
> + /* and write data */
> + writel(value, db->membase + EMAC_MAC_MWTD_REG);
> + spin_unlock_irqrestore(&db->lock, flags);
> +
> + mutex_unlock(&db->phy_lock);
Ditto
> +}
> +
> +static int emacrx_completed_flag = 1;
This should be moved to your interface specific private structure, as it won't
work when there are two instances of the same driver.
[snip]
> +
> +static void wemac_dumpblk_32bit(void __iomem *reg, int count)
> +{
> + int i;
> + int tmp;
> +
> + for (i = 0; i < (round_up(count, 4) / 4); i++)
> + tmp = readl(reg);
> +}
This could probably be removed, tmp is a write only location, did you remove
the variable printing that came along this?
> +
> +static void wemac_schedule_poll(struct wemac_board_info *db)
> +{
> + schedule_delayed_work(&db->phy_poll, HZ * 2);
> +}
phylib takes care of the polling for you.
> +
> +static int wemac_ioctl(struct net_device *dev, struct ifreq *req, int cmd)
> +{
> + struct wemac_board_info *dm = to_wemac_board(dev);
> +
> + if (!netif_running(dev))
> + return -EINVAL;
> +
> + return generic_mii_ioctl(&dm->mii, if_mii(req), cmd, NULL);
> +}
> +
> +/* ethtool ops */
> +static void wemac_get_drvinfo(struct net_device *dev,
> + struct ethtool_drvinfo *info)
> +{
> + strcpy(info->driver, DRV_NAME);
> + strcpy(info->version, DRV_VERSION);
You should use strlcpy() here to ensure null-termination, and you should also
fill in the bus_info member of struct ethtool_drvinfo.
> +}
> +
[snip]
> +unsigned int phy_link_check(struct net_device *dev)
> +{
> + unsigned int reg_val;
> +
> + reg_val = wemac_phy_read(dev, WEMAC_PHY, 1);
> +
> + if (reg_val & 0x4) {
> + netdev_info(dev, "EMAC PHY Linked...\n");
> + return 1;
> + } else {
> + netdev_info(dev, "EMAC PHY Link waiting......\n");
> + return 0;
> + }
> +}
Please remove this and migrate to phylib.
> +
> +unsigned int emac_setup(struct net_device *ndev)
> +{
> + unsigned int reg_val;
> + unsigned int phy_val;
> + unsigned int duplex_flag;
> + struct wemac_board_info *db = netdev_priv(ndev);
> +
> + /* set up TX */
> + reg_val = readl(db->membase + EMAC_TX_MODE_REG);
> +
> + writel(reg_val | EMAC_TX_MODE_ABORTED_FRAME_EN,
> + db->membase + EMAC_TX_MODE_REG);
> +
> + /* set up RX */
> + reg_val = readl(db->membase + EMAC_RX_CTL_REG);
> +
> + writel(reg_val | EMAC_RX_CTL_PASS_LEN_OOR_EN |
> + EMAC_RX_CTL_ACCEPT_UNICAST_EN | EMAC_RX_CTL_DA_FILTER_EN |
> + EMAC_RX_CTL_ACCEPT_MULTICAST_EN |
> + EMAC_RX_CTL_ACCEPT_BROADCAST_EN,
> + db->membase + EMAC_RX_CTL_REG);
> +
> + /* set MAC */
> + /* set MAC CTL0 */
> + reg_val = readl(db->membase + EMAC_MAC_CTL0_REG);
> + writel(reg_val | EMAC_MAC_CTL0_RX_FLOW_CTL_EN |
> + EMAC_MAC_CTL0_TX_FLOW_CTL_EN,
> + db->membase + EMAC_MAC_CTL0_REG);
> +
> + /* set MAC CTL1 */
> + reg_val = readl(db->membase + EMAC_MAC_CTL1_REG);
> + phy_val = wemac_phy_read(ndev, WEMAC_PHY, 0);
> + dev_dbg(db->dev, "PHY SETUP, reg 0 value: %x\n", phy_val);
> + duplex_flag = !!(phy_val & EMAC_PHY_DUPLEX);
> +
> + if (duplex_flag)
> + reg_val |= EMAC_MAC_CTL1_DUPLEX_EN;
> +
> + reg_val |= EMAC_MAC_CTL1_LEN_CHECK_EN;
> + reg_val |= EMAC_MAC_CTL1_CRC_EN;
> + reg_val |= EMAC_MAC_CTL1_PAD_EN;
> + writel(reg_val, db->membase + EMAC_MAC_CTL1_REG);
> +
> + /* set up IPGT */
> + writel(EMAC_MAC_IPGT_FULL_DUPLEX, db->membase + EMAC_MAC_IPGT_REG);
> +
> + /* set up IPGR */
> + writel((EMAC_MAC_IPGR_IPG1 << 8) | EMAC_MAC_IPGR_IPG2,
> + db->membase + EMAC_MAC_IPGR_REG);
> +
> + /* set up Collison window */
> + writel((EMAC_MAC_CLRT_COLLISION_WINDOW << 8) | EMAC_MAC_CLRT_RM,
> + db->membase + EMAC_MAC_CLRT_REG);
> +
> + /* set up Max Frame Length */
> + writel(WEMAC_MAX_FRAME_LEN,
> + db->membase + EMAC_MAC_MAXF_REG);
> +
> + return 0;
> +}
> +
> +unsigned int wemac_powerup(struct net_device *ndev)
> +{
> + struct wemac_board_info *db = netdev_priv(ndev);
> + unsigned int reg_val;
> +
> + /* initial EMAC */
> + /* flush RX FIFO */
> + reg_val = readl(db->membase + EMAC_RX_CTL_REG);
> + reg_val |= 0x8;
> + writel(reg_val, db->membase + EMAC_RX_CTL_REG);
> + udelay(1);
> +
> + /* initial MAC */
> + /* soft reset MAC */
> + reg_val = readl(db->membase + EMAC_MAC_CTL0_REG);
> + reg_val &= ~EMAC_MAC_CTL0_SOFT_RESET;
> + writel(reg_val, db->membase + EMAC_MAC_CTL0_REG);
> +
> + /* set MII clock */
> + reg_val = readl(db->membase + EMAC_MAC_MCFG_REG);
> + reg_val &= (~(0xf << 2));
> + reg_val |= (0xD << 2);
> + writel(reg_val, db->membase + EMAC_MAC_MCFG_REG);
> +
> + /* clear RX counter */
> + writel(0x0, db->membase + EMAC_RX_FBC_REG);
> +
> + /* disable all interrupt and clear interrupt status */
> + writel(0, db->membase + EMAC_INT_CTL_REG);
> + reg_val = readl(db->membase + EMAC_INT_STA_REG);
> + writel(reg_val, db->membase + EMAC_INT_STA_REG);
> +
> + udelay(1);
> +
> + /* set up EMAC */
> + emac_setup(ndev);
> +
> + /* set mac_address to chip */
> + writel(ndev->dev_addr[0] << 16 | ndev->dev_addr[1] << 8 | ndev->
> + dev_addr[2], db->membase + EMAC_MAC_A1_REG);
> + writel(ndev->dev_addr[3] << 16 | ndev->dev_addr[4] << 8 | ndev->
> + dev_addr[5], db->membase + EMAC_MAC_A0_REG);
> +
> + mdelay(1);
> +
> + return 1;
> +}
> +
> +static void wemac_poll_work(struct work_struct *w)
> +{
> + struct delayed_work *dw = container_of(w, struct delayed_work, work);
> + struct wemac_board_info *db = container_of(dw,
> + struct wemac_board_info,
> + phy_poll);
> + struct net_device *ndev = db->ndev;
> +
> + mii_check_media(&db->mii, netif_msg_link(db), 0);
> +
> + if (netif_running(ndev))
> + wemac_schedule_poll(db);
> +}
> +
> +static int wemac_set_mac_address(struct net_device *dev, void *p)
> +{
> + struct sockaddr *addr = p;
> + struct wemac_board_info *db = netdev_priv(dev);
> +
> + if (netif_running(dev))
> + return -EBUSY;
> +
> + memcpy(dev->dev_addr, addr->sa_data, ETH_ALEN);
> +
> + writel(dev->dev_addr[0] << 16 | dev->dev_addr[1] << 8 | dev->
> + dev_addr[2], db->membase + EMAC_MAC_A1_REG);
> + writel(dev->dev_addr[3] << 16 | dev->dev_addr[4] << 8 | dev->
> + dev_addr[5], db->membase + EMAC_MAC_A0_REG);
> +
> + return 0;
> +}
> +
> +/* Initialize wemac board */
> +static void wemac_init_wemac(struct net_device *dev)
> +{
> + struct wemac_board_info *db = netdev_priv(dev);
> + unsigned int phy_reg;
> + unsigned int reg_val;
> +
> + if (gpio_is_valid(db->power_gpio))
> + gpio_set_value(db->power_gpio, 1);
> +
> + /* PHY POWER UP */
> + phy_reg = wemac_phy_read(dev, WEMAC_PHY, 0);
> + wemac_phy_write(dev, WEMAC_PHY, 0, phy_reg & (~(1 << 11)));
> + mdelay(1);
> +
> + phy_reg = wemac_phy_read(dev, WEMAC_PHY, 0);
> +
> + /* set EMAC SPEED, depend on PHY */
> + reg_val = readl(db->membase + EMAC_MAC_SUPP_REG);
> + reg_val &= (~(0x1 << 8));
> + reg_val |= (((phy_reg & (1 << 13)) >> 13) << 8);
> + writel(reg_val, db->membase + EMAC_MAC_SUPP_REG);
> +
> + /* set duplex depend on phy */
> + reg_val = readl(db->membase + EMAC_MAC_CTL1_REG);
> + reg_val &= (~(0x1 << 0));
> + reg_val |= (((phy_reg & (1 << 8)) >> 8) << 0);
> + writel(reg_val, db->membase + EMAC_MAC_CTL1_REG);
> +
> + /* enable RX/TX */
> + reg_val = readl(db->membase + EMAC_CTL_REG);
> + writel(reg_val | EMAC_CTL_RESET | EMAC_CTL_TX_EN | EMAC_CTL_RX_EN,
> + db->membase + EMAC_CTL_REG);
> +
> + /* enable RX/TX0/RX Hlevel interrup */
> + reg_val = readl(db->membase + EMAC_INT_CTL_REG);
> + reg_val |= (0xf << 0) | (0x01 << 8);
> + writel(reg_val, db->membase + EMAC_INT_CTL_REG);
> +
> + /* Init Driver variable */
> + db->tx_fifo_stat = 0;
> + dev->trans_start = 0;
I do not think this is required you are supposed to update this field only in
the receive path.
> +}
> +
> +/* Our watchdog timed out. Called by the networking layer */
> +static void wemac_timeout(struct net_device *dev)
> +{
> + struct wemac_board_info *db = netdev_priv(dev);
> + unsigned long flags;
> +
> + if (netif_msg_timer(db))
> + dev_err(db->dev, "tx time out.\n");
> +
> + /* Save previous register address */
> + spin_lock_irqsave(&db->lock, flags);
> +
> + netif_stop_queue(dev);
> + wemac_reset(db);
> + wemac_init_wemac(dev);
> + /* We can accept TX packets again */
> + dev->trans_start = jiffies;
> + netif_wake_queue(dev);
> +
> + /* Restore previous register address */
> + spin_unlock_irqrestore(&db->lock, flags);
> +}
> +
> +/* Hardware start transmission.
> + * Send a packet to media from the upper layer.
> + */
> +static int wemac_start_xmit(struct sk_buff *skb, struct net_device *dev)
> +{
> + struct wemac_board_info *db = netdev_priv(dev);
> + unsigned long channel;
> + unsigned long flags;
> +
> + channel = db->tx_fifo_stat & 3;
> + if (channel == 3)
> + return 1;
start_xmit expects standardized return values such as NETDEV_TX_BUSY and
NETDEV_TX_COMPLETE, please use them.
> +
> + channel = (channel == 1 ? 1 : 0);
> +
> + spin_lock_irqsave(&db->lock, flags);
> +
> + writel(channel, db->membase + EMAC_TX_INS_REG);
> +
> + wemac_outblk_32bit(db->membase + EMAC_TX_IO_DATA_REG,
> + skb->data, skb->len);
> + dev->stats.tx_bytes += skb->len;
> +
> + db->tx_fifo_stat |= 1 << channel;
> + /* TX control: First packet immediately send, second packet queue */
> + if (channel == 0) {
> + /* set TX len */
> + writel(skb->len, db->membase + EMAC_TX_PL0_REG);
> + /* start translate from fifo to phy */
> + writel(readl(db->membase + EMAC_TX_CTL0_REG) | 1,
> + db->membase + EMAC_TX_CTL0_REG);
Do not you need some write barrier here to ensure your descriptor address and
control are properly written before the EMAC will see these?
> +
> + /* save the time stamp */
> + dev->trans_start = jiffies;
> + } else if (channel == 1) {
> + /* set TX len */
> + writel(skb->len, db->membase + EMAC_TX_PL1_REG);
> + /* start translate from fifo to phy */
> + writel(readl(db->membase + EMAC_TX_CTL1_REG) | 1,
> + db->membase + EMAC_TX_CTL1_REG);
> +
> + /* save the time stamp */
> + dev->trans_start = jiffies;
> + }
> +
> + if ((db->tx_fifo_stat & 3) == 3) {
> + /* Second packet */
> + netif_stop_queue(dev);
Why is that required? Does that mean that your EMAC can only transmit one
packet at a time?
> + }
> +
> + spin_unlock_irqrestore(&db->lock, flags);
> +
> + /* free this SKB */
> + dev_kfree_skb(skb);
> +
> + return 0;
> +}
> +
> +/* WEMAC interrupt handler
> + * receive the packet to upper layer, free the transmitted packet
> + */
> +static void wemac_tx_done(struct net_device *dev, struct wemac_board_info
> *db, + unsigned int tx_status)
> +{
> + /* One packet sent complete */
> + db->tx_fifo_stat &= ~(tx_status & 3);
> + if (3 == (tx_status & 3))
> + dev->stats.tx_packets += 2;
> + else
> + dev->stats.tx_packets++;
> +
> + if (netif_msg_tx_done(db))
> + dev_dbg(db->dev, "tx done, NSR %02x\n", tx_status);
> +
> + netif_wake_queue(dev);
Why is that also required? According to your start_xmit function you should do
this only when you have transmitted 2 packets no?
[snip]
> +
> + reg_val = readl(db->membase + EMAC_RX_IO_DATA_REG);
> + if (netif_msg_rx_status(db))
> + dev_dbg(db->dev, "receive header: %x\n", reg_val);
> + if (reg_val != 0x0143414d) {
Where is that magic value coming from?
--
Florian
^ permalink raw reply
* [Patch net-next] net: fix some typos in netif features
From: Cong Wang @ 2013-03-16 14:47 UTC (permalink / raw)
To: netdev; +Cc: Pravin B Shelar, David S. Miller, Cong Wang
From: Cong Wang <amwang@redhat.com>
Cc: Pravin B Shelar <pshelar@nicira.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: Cong Wang <amwang@redhat.com>
---
diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
index f5e797c..d6ee2d0 100644
--- a/include/linux/netdev_features.h
+++ b/include/linux/netdev_features.h
@@ -102,8 +102,8 @@ enum {
#define NETIF_F_VLAN_CHALLENGED __NETIF_F(VLAN_CHALLENGED)
#define NETIF_F_RXFCS __NETIF_F(RXFCS)
#define NETIF_F_RXALL __NETIF_F(RXALL)
-#define NETIF_F_GRE_GSO __NETIF_F(GSO_GRE)
-#define NETIF_F_UDP_TUNNEL __NETIF_F(UDP_TUNNEL)
+#define NETIF_F_GSO_GRE __NETIF_F(GSO_GRE)
+#define NETIF_F_GSO_UDP_TUNNEL __NETIF_F(GSO_UDP_TUNNEL)
/* Features valid for ethtool to change */
/* = all defined minus driver/device-class-related */
^ permalink raw reply related
* Re: connect(2) reassociation regression
From: Eric Dumazet @ 2013-03-16 14:51 UTC (permalink / raw)
To: William Ahern; +Cc: netdev
In-Reply-To: <20130316055632.GA21364@wilbur.25thandClement.com>
On Fri, 2013-03-15 at 22:56 -0700, William Ahern wrote:
> I've stumbled upon what may be a regression in connect(2) behavior.
>
> My DNS library uses connect(2) to reassociate UDP sockets. That way the
> kernel can filter my packets, and it makes for cleaner code overall. The
> Linux manual page makes it pretty clear that this is okay, and at least one
> interpretation of POSIX (certainly the one I had) does as well.
>
> At some point in the 3.x cycle (maybe after 3.2.0) something was changed.
> Whereas previously any reassociation worked, regardless of destination
> network, now if the _first_ association is to the loopback, any subsequent
> association to non-loopback fails with EINVAL. However, if the loopback is
> the second or later association then everything continues to work. In other
> words, the sequence
>
> connect(127.0.0.1), connect(8.8.8.8)
>
> fails with EINVAL, but
>
> connect(8.8.8.8), connect(127.0.0.1), connect(1.2.3.4)
>
> succeeds.
>
> I admit that originally I simply presumed that on each reassociation the
> kernel would handle reassociating the source address in addition to the
> destination address. The technique worked everywhere I tested, including
> Linux, Solaris, NetBSD, OpenBSD, FreeBSD. And I should note that it even
> worked when reassociating to different external networks (and still works on
> everything but Linux, AFAICT).
>
> I realize now that arguably POSIX only requires that a second connnect call
> change the destination address, and not the source address. But what would
> be the point of allowing a reassociation if the source address is never
> changed? Because any two addresses may route to entirely different networks
> or over different devices, the capability to reassociate would be pointless.
>
> OTOH, if you explicitly called bind before connect, most systems these days
> will unbind the source address when reassociating. That may be undesirable
> behavior, but it is long-standing behavior AFAICT, including on Linux. One
> way to bypass the new Linux behavior is to reset the socket with
> connect(AF_UNSPEC), but under the pedantic interpretation of POSIX that's
> not guaranteed to work.
There is an issue as the connect() call sets both local address:port and
remote address, in the case the local address was not already set by a
prior bind().
And once bound to a local address, its not really clear if we are
allowed to bind to a different one, and fall in the possible traps of
SO_REUSEADDR and find another socket bound to the same local addr:port.
So if the second connect() also change the source port, I am pretty sure
some applications will badly break.
I would just avoid the problem of handling this mess, and let the
application close the socket and allocate a new one.
Changing the kernel behavior on these kind of unspecified stuff might
break some other applications.
Clearly the BSD API was bad, as the connect() is a 'super operation',
not only setting the remote address:port, but also the local
address:port given the current routing table.
^ permalink raw reply
* Re: [PATCH 1/5] net: Add davicom wemac ethernet driver found on Allwinner A10 SoC's
From: Alexander Shiyan @ 2013-03-16 14:55 UTC (permalink / raw)
To: Maxime Ripard
Cc: linux-arm-kernel, linux-doc, netdev, devicetree-discuss,
linux-kernel, Rob Herring, Grant Likely, Rob Landley, sunny,
shuge, Stefan Roese, kevin
In-Reply-To: <1363380605-6577-2-git-send-email-maxime.ripard@free-electrons.com>
> From: Stefan Roese <sr@denx.de>
>
> The Allwinner A10 has an ethernet controller that is advertised as
> coming from Davicom.
>
> The exact feature set of this controller is unknown, since there is no
> public documentation for this IP, and this driver is mostly the one
> published by Allwinner that has been heavily cleaned up.
...
> +Example:
> +
> +wemac: ethernet@01c0b000 {
> + compatible = "davicom,wemac";
> + reg = <0x01c0b000 0x1000>;
> + interrupts = <55>;
> + allwinner,power-gpios = <&pio 7 19 0>;
I think regulator API is better for use for this.
And gpio-regulator for this case.
---
^ permalink raw reply
* [PATCH] ath9k : Fix ieee80211 work while going to suspend
From: Parag Warudkar @ 2013-03-16 16:38 UTC (permalink / raw)
To: Luis R. Rodriguez, Jouni Malinen, Vasanthakumar Thiagarajan,
John W. Linville, linux-wireless, ath9k-devel, netdev, LKML,
senthilb
[-- Attachment #1: Type: text/plain, Size: 6422 bytes --]
During suspend below warning is seen when ath9k is active. Attached
patch fixes the warning for me. Tested to work across few
suspend-resume cycles.
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642939] WARNING: at
net/mac80211/util.c:599 ieee80211_can_queue_work.isra.7+0x32/0x40
[mac80211]()
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642940] Hardware name: iMac12,1
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642941] queueing ieee80211
work while going to suspend
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642972] Modules linked in:
joydev hid_logitech_dj zfs(POF) bridge stp llc zunicode(POF) zavl(POF)
zcommon(POF) znvpair(POF) spl(OF) zlib_deflate be2iscsi
iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio
libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core
iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi rfcomm bnep
nls_utf8 hfsplus btusb uvcvideo videobuf2_vmalloc videobuf2_memops
videobuf2_core videodev bluetooth media coretemp snd_hda_codec_hdmi
snd_hda_codec_cirrus snd_hda_intel snd_hda_codec snd_hwdep snd_seq
snd_seq_device snd_pcm snd_page_alloc snd_timer snd soundcore arc4
ath9k ath9k_common microcode ath9k_hw ath mac80211 iTCO_wdt
iTCO_vendor_support cfg80211 lpc_ich mei mfd_core rfkill i2c_i801
applesmc apple_bl input_polldev vhost_net tun macvtap macvlan
kvm_intel kvm binfmt_misc uinput usb_storage crc32c_intel radeon ttm
i915 ghash_clmulni_intel firewire_ohci firewire_core i2c_algo_bit
drm_kms_helper crc_itu_t drm tg3 ptp pps_core i2c_core video sunrpc
[last unloaded: iptable_mangle]
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642985] Pid: 0, comm:
swapper/0 Tainted: PF O 3.8.2-206.fc18.x86_64 #1
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642986] Call Trace:
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.642992] <IRQ>
[<ffffffff8105e61f>] warn_slowpath_common+0x7f/0xc0
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643009]
[<ffffffffa0581420>] ? ath_start_rx_poll+0x70/0x70 [ath9k]
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643011]
[<ffffffff8105e716>] warn_slowpath_fmt+0x46/0x50
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643018]
[<ffffffffa045b542>] ieee80211_can_queue_work.isra.7+0x32/0x40
[mac80211]
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643024]
[<ffffffffa045b5de>] ieee80211_queue_work+0x2e/0x50 [mac80211]
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643027]
[<ffffffffa0581438>] ath_rx_poll+0x18/0x20 [ath9k]
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643029]
[<ffffffff8106d0aa>] call_timer_fn+0x3a/0x120
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643032]
[<ffffffffa0581420>] ? ath_start_rx_poll+0x70/0x70 [ath9k]
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643034]
[<ffffffff814fb240>] ? cpufreq_p4_target+0x120/0x120
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643035]
[<ffffffff8106ee3e>] run_timer_softirq+0x1fe/0x2b0
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643037]
[<ffffffff814fb240>] ? cpufreq_p4_target+0x120/0x120
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643038]
[<ffffffff81066cd0>] __do_softirq+0xd0/0x210
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643040]
[<ffffffff8101b913>] ? native_sched_clock+0x13/0x80
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643041]
[<ffffffff814fb240>] ? cpufreq_p4_target+0x120/0x120
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643043]
[<ffffffff8165985c>] call_softirq+0x1c/0x30
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643045]
[<ffffffff810162a5>] do_softirq+0x75/0xb0
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643046]
[<ffffffff81066fa5>] irq_exit+0xb5/0xc0
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643048]
[<ffffffff8165a1de>] smp_apic_timer_interrupt+0x6e/0x99
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643049]
[<ffffffff8165911d>] apic_timer_interrupt+0x6d/0x80
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643052] <EOI>
[<ffffffff810868ce>] ? __hrtimer_start_range_ns+0x1be/0x400
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643053]
[<ffffffff814fbc30>] ? cpuidle_wrap_enter+0x50/0xa0
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643054]
[<ffffffff814fbc29>] ? cpuidle_wrap_enter+0x49/0xa0
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643056]
[<ffffffff814fbc90>] cpuidle_enter_tk+0x10/0x20
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643057]
[<ffffffff814fb8c9>] cpuidle_idle_call+0xa9/0x260
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643058]
[<ffffffff8101d45f>] cpu_idle+0xaf/0x120
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643061]
[<ffffffff81634522>] rest_init+0x72/0x80
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643063]
[<ffffffff81d00c40>] start_kernel+0x3d1/0x3de
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643065]
[<ffffffff81d0066e>] ? repair_env_string+0x5e/0x5e
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643066]
[<ffffffff81d00356>] x86_64_start_reservations+0x131/0x135
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643068]
[<ffffffff81d0045a>] x86_64_start_kernel+0x100/0x10f
Mar 16 09:39:17 Parags-iMac kernel: [ 3993.643068] ---[ end trace
5595a7f5dd9a2949 ]---
Signed-off-by: Parag Warudkar <parag.lkml@gmail.com>
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h
b/drivers/net/wireless/ath/ath9k/ath9k.h
index a56b241..b3088a1 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -764,6 +764,7 @@ struct ath_softc {
atomic_t wow_got_bmiss_intr;
atomic_t wow_sleep_proc_intr; /* in the middle of WoW sleep ? */
u32 wow_intr_before_sleep;
+ bool suspending;
#endif
};
diff --git a/drivers/net/wireless/ath/ath9k/link.c
b/drivers/net/wireless/ath/ath9k/link.c
index ade3afb..fa77e19 100644
--- a/drivers/net/wireless/ath/ath9k/link.c
+++ b/drivers/net/wireless/ath/ath9k/link.c
@@ -158,7 +158,8 @@ void ath_start_rx_poll(struct ath_softc *sc, u8 nbeacon)
{
if (!AR_SREV_9300(sc->sc_ah))
return;
-
+ if (sc->suspending)
+ return;
if (!test_bit(SC_OP_PRIM_STA_VIF, &sc->sc_flags))
return;
diff --git a/drivers/net/wireless/ath/ath9k/main.c
b/drivers/net/wireless/ath/ath9k/main.c
index 6e66f9c..0cf88b7 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2150,7 +2150,7 @@ static int ath9k_suspend(struct ieee80211_hw *hw,
int ret = 0;
mutex_lock(&sc->mutex);
-
+ sc->suspending = 1;
ath_cancel_work(sc);
ath_stop_ani(sc);
del_timer_sync(&sc->rx_poll_timer);
@@ -2288,6 +2288,7 @@ static int ath9k_resume(struct ieee80211_hw *hw)
ath9k_start_btcoex(sc);
ath9k_ps_restore(sc);
+ sc->suspending = 0;
mutex_unlock(&sc->mutex);
return 0;
[-- Attachment #2: ath9k.patch --]
[-- Type: application/octet-stream, Size: 1514 bytes --]
Signed-off-by: Parag Warudkar <parag.lkml@gmail.com>
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index a56b241..b3088a1 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -764,6 +764,7 @@ struct ath_softc {
atomic_t wow_got_bmiss_intr;
atomic_t wow_sleep_proc_intr; /* in the middle of WoW sleep ? */
u32 wow_intr_before_sleep;
+ bool suspending;
#endif
};
diff --git a/drivers/net/wireless/ath/ath9k/link.c b/drivers/net/wireless/ath/ath9k/link.c
index ade3afb..fa77e19 100644
--- a/drivers/net/wireless/ath/ath9k/link.c
+++ b/drivers/net/wireless/ath/ath9k/link.c
@@ -158,7 +158,8 @@ void ath_start_rx_poll(struct ath_softc *sc, u8 nbeacon)
{
if (!AR_SREV_9300(sc->sc_ah))
return;
-
+ if (sc->suspending)
+ return;
if (!test_bit(SC_OP_PRIM_STA_VIF, &sc->sc_flags))
return;
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 6e66f9c..0cf88b7 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2150,7 +2150,7 @@ static int ath9k_suspend(struct ieee80211_hw *hw,
int ret = 0;
mutex_lock(&sc->mutex);
-
+ sc->suspending = 1;
ath_cancel_work(sc);
ath_stop_ani(sc);
del_timer_sync(&sc->rx_poll_timer);
@@ -2288,6 +2288,7 @@ static int ath9k_resume(struct ieee80211_hw *hw)
ath9k_start_btcoex(sc);
ath9k_ps_restore(sc);
+ sc->suspending = 0;
mutex_unlock(&sc->mutex);
return 0;
^ permalink raw reply related
* [PATCH] igb: make sensor info static
From: Stephen Hemminger @ 2013-03-16 16:56 UTC (permalink / raw)
To: Jeff Kirsher; +Cc: e1000-devel, netdev
Trivial sparse warning.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/drivers/net/ethernet/intel/igb/igb_hwmon.c 2013-03-14 14:22:58.135958283 -0700
+++ b/drivers/net/ethernet/intel/igb/igb_hwmon.c 2013-03-16 09:44:46.455461525 -0700
@@ -39,7 +39,7 @@
#include <linux/pci.h>
#ifdef CONFIG_IGB_HWMON
-struct i2c_board_info i350_sensor_info = {
+static struct i2c_board_info i350_sensor_info = {
I2C_BOARD_INFO("i350bb", (0Xf8 >> 1)),
};
^ permalink raw reply
* [PATCH] sfc: make local functions static
From: Stephen Hemminger @ 2013-03-16 16:57 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
Trivial sparse detected functions that should be static.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
--- a/drivers/net/ethernet/sfc/efx.c 2013-03-14 14:22:58.139958231 -0700
+++ b/drivers/net/ethernet/sfc/efx.c 2013-03-16 09:47:09.417612586 -0700
@@ -2950,8 +2950,8 @@ static const struct dev_pm_ops efx_pm_op
* At this point MMIO and DMA may be disabled.
* Stop the software path and request a slot reset.
*/
-pci_ers_result_t efx_io_error_detected(struct pci_dev *pdev,
- enum pci_channel_state state)
+static pci_ers_result_t efx_io_error_detected(struct pci_dev *pdev,
+ enum pci_channel_state state)
{
pci_ers_result_t status = PCI_ERS_RESULT_RECOVERED;
struct efx_nic *efx = pci_get_drvdata(pdev);
@@ -2986,7 +2986,7 @@ pci_ers_result_t efx_io_error_detected(s
}
/* Fake a successfull reset, which will be performed later in efx_io_resume. */
-pci_ers_result_t efx_io_slot_reset(struct pci_dev *pdev)
+static pci_ers_result_t efx_io_slot_reset(struct pci_dev *pdev)
{
struct efx_nic *efx = pci_get_drvdata(pdev);
pci_ers_result_t status = PCI_ERS_RESULT_RECOVERED;
--- a/drivers/net/ethernet/sfc/rx.c 2013-03-14 14:22:58.143958179 -0700
+++ b/drivers/net/ethernet/sfc/rx.c 2013-03-16 09:47:24.645415645 -0700
@@ -666,8 +666,8 @@ int efx_probe_rx_queue(struct efx_rx_que
return rc;
}
-void efx_init_rx_recycle_ring(struct efx_nic *efx,
- struct efx_rx_queue *rx_queue)
+static void efx_init_rx_recycle_ring(struct efx_nic *efx,
+ struct efx_rx_queue *rx_queue)
{
unsigned int bufs_in_recycle_ring, page_ring_size;
^ permalink raw reply
* Re: [PATCH 1/1] connector: Added coredumping event to the process connector
From: Hannes Frederic Sowa @ 2013-03-16 17:03 UTC (permalink / raw)
To: Jesper Derehag; +Cc: Evgeniy Polyakov, netdev
In-Reply-To: <1363431050-24135-1-git-send-email-jderehag@hotmail.com>
On Sat, Mar 16, 2013 at 11:50:50AM +0100, Jesper Derehag wrote:
> + ev->event_data.exit.exit_code = task->exit_code;
> + ev->event_data.exit.exit_signal = task->exit_signal;
Do these already contain meaningful values?
^ permalink raw reply
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: Eric Dumazet @ 2013-03-16 17:36 UTC (permalink / raw)
To: dormando; +Cc: Cong Wang, linux-kernel, netdev
In-Reply-To: <1363303174.29475.46.camel@edumazet-glaptop>
On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
> Thanks thats really useful, we might miss to increment socket refcount
> in a timer setup.
>
Hmm, please add following debugging patch as well
diff --git a/include/net/sock.h b/include/net/sock.h
index 14f6e9d..fe7c8a6 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -530,7 +530,9 @@ static inline void sock_hold(struct sock *sk)
*/
static inline void __sock_put(struct sock *sk)
{
- atomic_dec(&sk->sk_refcnt);
+ int newref = atomic_dec_return(&sk->sk_refcnt);
+
+ BUG_ON(newref <= 0);
}
static inline bool sk_del_node_init(struct sock *sk)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 786d97a..a445e15 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -739,7 +739,7 @@ void inet_csk_prepare_forced_close(struct sock *sk)
{
/* sk_clone_lock locked the socket and set refcnt to 2 */
bh_unlock_sock(sk);
- sock_put(sk);
+ __sock_put(sk);
/* The below has to be done to allow calling inet_csk_destroy_sock */
sock_set_flag(sk, SOCK_DEAD);
@@ -835,13 +835,13 @@ void inet_csk_listen_stop(struct sock *sk)
* tcp_v4_destroy_sock().
*/
tcp_sk(child)->fastopen_rsk = NULL;
- sock_put(sk);
+ __sock_put(sk);
}
inet_csk_destroy_sock(child);
bh_unlock_sock(child);
local_bh_enable();
- sock_put(child);
+ __sock_put(child);
sk_acceptq_removed(sk);
__reqsk_free(req);
^ permalink raw reply related
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: Eric Dumazet @ 2013-03-16 17:44 UTC (permalink / raw)
To: dormando; +Cc: Cong Wang, linux-kernel, netdev
In-Reply-To: <1363455366.29475.66.camel@edumazet-glaptop>
On Sat, 2013-03-16 at 10:36 -0700, Eric Dumazet wrote:
> On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
>
> > Thanks thats really useful, we might miss to increment socket refcount
> > in a timer setup.
> >
>
> Hmm, please add following debugging patch as well
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 14f6e9d..fe7c8a6 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -530,7 +530,9 @@ static inline void sock_hold(struct sock *sk)
> */
> static inline void __sock_put(struct sock *sk)
> {
> - atomic_dec(&sk->sk_refcnt);
> + int newref = atomic_dec_return(&sk->sk_refcnt);
> +
> + BUG_ON(newref <= 0);
> }
>
> static inline bool sk_del_node_init(struct sock *sk)
> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index 786d97a..a445e15 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c
> @@ -739,7 +739,7 @@ void inet_csk_prepare_forced_close(struct sock *sk)
> {
> /* sk_clone_lock locked the socket and set refcnt to 2 */
> bh_unlock_sock(sk);
> - sock_put(sk);
> + __sock_put(sk);
>
> /* The below has to be done to allow calling inet_csk_destroy_sock */
> sock_set_flag(sk, SOCK_DEAD);
> @@ -835,13 +835,13 @@ void inet_csk_listen_stop(struct sock *sk)
> * tcp_v4_destroy_sock().
> */
> tcp_sk(child)->fastopen_rsk = NULL;
> - sock_put(sk);
> + __sock_put(sk);
> }
> inet_csk_destroy_sock(child);
>
> bh_unlock_sock(child);
> local_bh_enable();
> - sock_put(child);
> + __sock_put(child);
>
Please don't include the last line : this should stay as
sock_put(child);
^ permalink raw reply
* Re: [PATCH net,stable-3.8] net: cdc_ncm, cdc_mbim: allow user to prefer NCM for backwards compatibility
From: Ben Hutchings @ 2013-03-16 17:51 UTC (permalink / raw)
To: Bjørn Mork; +Cc: netdev, linux-usb, Greg Suarez, Alexey Orishko
In-Reply-To: <87ppz14030.fsf@nemi.mork.no>
[-- Attachment #1: Type: text/plain, Size: 3649 bytes --]
On Fri, 2013-03-15 at 08:02 +0100, Bjørn Mork wrote:
> Ben Hutchings <ben@decadent.org.uk> writes:
>
> > On Thu, 2013-03-14 at 12:05 +0100, Bjørn Mork wrote:
> >> commit bd329e1 ("net: cdc_ncm: do not bind to NCM compatible MBIM devices")
> >> introduced a new policy, preferring MBIM for dual NCM/MBIM functions if
> >> the cdc_mbim driver was enabled. This caused a regression for users
> >> wanting to use NCM.
> >>
> >> Devices implementing NCM backwards compatibility according to section
> >> 3.2 of the MBIM v1.0 specification allow either NCM or MBIM on a single
> >> USB function, using different altsettings. The cdc_ncm and cdc_mbim
> >> drivers will both probe such functions, and must agree on a common
> >> policy for selecting either MBIM or NCM. Until now, this policy has
> >> been set at build time based on CONFIG_USB_NET_CDC_MBIM.
> >>
> >> Use a module parameter to set the system policy at runtime, allowing the
> >> user to prefer NCM on systems with the cdc_mbim driver.
> >>
> >> Cc: Greg Suarez <gsuarez@smithmicro.com>
> >> Cc: Alexey Orishko <alexey.orishko@stericsson.com>
> >> Reported-by: Geir Haatveit <nospam@haatveit.nu>
> >> Reported-by: Tommi Kyntola <kynde@ts.ray.fi>
> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=54791
> >> Signed-off-by: Bjørn Mork <bjorn@mork.no>
> >> ---
> >>
> >> We now have two users independently reporting this as a 3.8 regression,
> >> so something needs to be done. I am not sure if adding a new module
> >> parameter is acceptable for stable, but this problem is definitely a
> >> regression and no other solutions came up in response to my RFC.
> >>
> >> The only real alternative I see for stable, is disabling MBIM support
> >> on any dual NCM/MBIM function. Which of course will be a regression
> >> for any user wanting MBIM, making it unacceptable.
> > [...]
> >
> > It definitely makes sense for this to be a run-time parameter. And the
> > default seems correct for custom kernels.
> >
> > For a distribution kernel - at least for Debian, where we can't assume
> > kernel and userland are always updated together - I think the
> > compile-time default should be false, and the userland package
> > (presumably ModemManager?) can install a modprobe.conf file to override
> > that once it can handle MBIM. We handled KMS transitions in a similar
> > way. I don't know that it's worth having a Kconfig option for that,
> > though.
>
> We could consider always defaulting to NCM. That would remove the
> ugliest parts of the code as well. Should I send a new version with
> such a change?
We could, but I fear that would annoy people building custom kernels.
> Bundling a modprobe.conf file to enable MBIM with userland tools
> supporting it is a great idea, and sounds feasible for custom built
> systems as well.
Using unpatched Linux & ModemManager (or other userland) needs to just
work. So if Linux is going to have MBIM disabled by default then
upstream ModemManager needs to ship and install that modprobe.conf file.
> (BTW, if there is any doubt about it, I feel really bad about my recent
> request to enable MBIM in Debian, where I wrote "enabling the driver
> will not prevent any existing solution from working.". At the time, I
> had not seen any of these dual NCM/MBIM functions and I just didn't
> think about the problems such devices would run into. Sorry about
> that. I guess I owe you one more...)
It's called experimental for a reason. :-)
Ben.
--
Ben Hutchings
It is easier to change the specification to fit the program than vice versa.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH 1/1] connector: Added coredumping event to the process connector
From: Hannes Frederic Sowa @ 2013-03-16 18:40 UTC (permalink / raw)
To: Jesper Derehag; +Cc: Evgeniy Polyakov, netdev@vger.kernel.org
In-Reply-To: <DUB002-W54999962E08C0F2E11B4EEDDEE0@phx.gbl>
On Sat, Mar 16, 2013 at 05:57:20PM +0000, Jesper Derehag wrote:
>
>
> > Date: Sat, 16 Mar 2013 18:03:48 +0100
> > From: hannes@stressinduktion.org
> > To: jderehag@hotmail.com
> > CC: zbr@ioremap.net; netdev@vger.kernel.org
> > Subject: Re: [PATCH 1/1] connector: Added coredumping event to the process connector
> >
> > On Sat, Mar 16, 2013 at 11:50:50AM +0100, Jesper Derehag wrote:
> > > + ev->event_data.exit.exit_code = task->exit_code;
> > > + ev->event_data.exit.exit_signal = task->exit_signal;
> >
> > Do these already contain meaningful values?
> >
>
> I have to admit that they dont.And you are correct, I should add a new event struct specific for the coredump event instead of piggybacking on the exit struct.Will re-submit a patch..
Hm, I am still unsure if such a patch is needed. Couldn't you test for
coredump by inspecting exit_code on PROC_EVENT_EXIT?
^ permalink raw reply
* RE: [PATCH 1/1] connector: Added coredumping event to the process connector
From: Jesper Derehag @ 2013-03-16 19:08 UTC (permalink / raw)
To: netdev@vger.kernel.org
In-Reply-To: <20130316184036.GE24041@order.stressinduktion.org>
----------------------------------------
> Date: Sat, 16 Mar 2013 19:40:36 +0100
> From: hannes@stressinduktion.org
> To: jderehag@hotmail.com
> CC: zbr@ioremap.net; netdev@vger.kernel.org
> Subject: Re: [PATCH 1/1] connector: Added coredumping event to the process connector
>
> On Sat, Mar 16, 2013 at 05:57:20PM +0000, Jesper Derehag wrote:
> >
> >
> > > Date: Sat, 16 Mar 2013 18:03:48 +0100
> > > From: hannes@stressinduktion.org
> > > To: jderehag@hotmail.com
> > > CC: zbr@ioremap.net; netdev@vger.kernel.org
> > > Subject: Re: [PATCH 1/1] connector: Added coredumping event to the process connector
> > >
> > > On Sat, Mar 16, 2013 at 11:50:50AM +0100, Jesper Derehag wrote:
> > > > + ev->event_data.exit.exit_code = task->exit_code;
> > > > + ev->event_data.exit.exit_signal = task->exit_signal;
> > >
> > > Do these already contain meaningful values?
> > >
> >
> > I have to admit that they dont.And you are correct, I should add a new event struct specific for the coredump event instead of piggybacking on the exit struct.Will re-submit a patch..
>
> Hm, I am still unsure if such a patch is needed. Couldn't you test for
> coredump by inspecting exit_code on PROC_EVENT_EXIT?
*** resubmitted message due to it got dropped by vger.kernel.org ***
Well, what this patch adds I think is more a question of timing.
As an example, say you want to quickly detect process failures. In that case if we would only have the EXIT event, that would mean that we get notified after the dump is done, which could take minutes depending on how large the dump is.
If we instead watch for both EXIT & COREDUMP events, it would mean that we would quickly catch any failing process, regardless of if its actually starting to coredump or if its exited for some other reason.
^ permalink raw reply
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: dormando @ 2013-03-16 20:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Cong Wang, linux-kernel, netdev
In-Reply-To: <1363455885.29475.68.camel@edumazet-glaptop>
> On Sat, 2013-03-16 at 10:36 -0700, Eric Dumazet wrote:
> > On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
> >
> > > Thanks thats really useful, we might miss to increment socket refcount
> > > in a timer setup.
> > >
> >
> > Hmm, please add following debugging patch as well
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 14f6e9d..fe7c8a6 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -530,7 +530,9 @@ static inline void sock_hold(struct sock *sk)
> > */
> > static inline void __sock_put(struct sock *sk)
> > {
> > - atomic_dec(&sk->sk_refcnt);
> > + int newref = atomic_dec_return(&sk->sk_refcnt);
> > +
> > + BUG_ON(newref <= 0);
> > }
> >
> > static inline bool sk_del_node_init(struct sock *sk)
> > diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> > index 786d97a..a445e15 100644
> > --- a/net/ipv4/inet_connection_sock.c
> > +++ b/net/ipv4/inet_connection_sock.c
> > @@ -739,7 +739,7 @@ void inet_csk_prepare_forced_close(struct sock *sk)
> > {
> > /* sk_clone_lock locked the socket and set refcnt to 2 */
> > bh_unlock_sock(sk);
> > - sock_put(sk);
> > + __sock_put(sk);
> >
> > /* The below has to be done to allow calling inet_csk_destroy_sock */
> > sock_set_flag(sk, SOCK_DEAD);
> > @@ -835,13 +835,13 @@ void inet_csk_listen_stop(struct sock *sk)
> > * tcp_v4_destroy_sock().
> > */
> > tcp_sk(child)->fastopen_rsk = NULL;
> > - sock_put(sk);
> > + __sock_put(sk);
> > }
> > inet_csk_destroy_sock(child);
> >
> > bh_unlock_sock(child);
> > local_bh_enable();
> > - sock_put(child);
> > + __sock_put(child);
> >
>
> Please don't include the last line : this should stay as
>
> sock_put(child);
>
thanks! Will take at least 24 hours to get the trace.
^ permalink raw reply
* Re: connect(2) reassociation regression
From: William Ahern @ 2013-03-16 20:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev
In-Reply-To: <1363445467.29475.63.camel@edumazet-glaptop>
On Sat, Mar 16, 2013 at 07:51:07AM -0700, Eric Dumazet wrote:
> On Fri, 2013-03-15 at 22:56 -0700, William Ahern wrote:
> > I've stumbled upon what may be a regression in connect(2) behavior.
<snip>
> > At some point in the 3.x cycle (maybe after 3.2.0) something was changed.
> > Whereas previously any reassociation worked, regardless of destination
> > network, now if the _first_ association is to the loopback, any subsequent
> > association to non-loopback fails with EINVAL. However, if the loopback is
> > the second or later association then everything continues to work. In other
> > words, the sequence
> >
<snip>
>
> There is an issue as the connect() call sets both local address:port and
> remote address, in the case the local address was not already set by a
> prior bind().
>
> And once bound to a local address, its not really clear if we are
> allowed to bind to a different one, and fall in the possible traps of
> SO_REUSEADDR and find another socket bound to the same local addr:port.
>
> So if the second connect() also change the source port, I am pretty sure
> some applications will badly break.
>
> I would just avoid the problem of handling this mess, and let the
> application close the socket and allocate a new one.
This is for UDP, not TCP. The alternative is sendto/recvfrom. For a
non-blocking, recursive DNS library reopening sockets all of the time is
really messy.
> Changing the kernel behavior on these kind of unspecified stuff might
> break some other applications.
Indeed. The behavior _was_ changed, and my application broke, and
potentially many other applications.
> Clearly the BSD API was bad, as the connect() is a 'super operation',
> not only setting the remote address:port, but also the local
> address:port given the current routing table.
Well, AFAICT Linux implemented this behavior for years. FWIW, Solaris also
implements this behavior. It's been universal until recently.
^ permalink raw reply
* Re: [RFC PATCH net-next (V2, RESENT)] ipv6: Queue fragments per interface for multicast/link-local addresses.
From: YOSHIFUJI Hideaki @ 2013-03-17 0:50 UTC (permalink / raw)
To: netdev, netfilter-devel, Hannes Frederic Sowa; +Cc: YOSHIFUJI Hideaki
In-Reply-To: <20130316074745.GC24041@order.stressinduktion.org>
Hannes Frederic Sowa wrote:
> On Sun, Feb 17, 2013 at 01:44:38AM +0900, YOSHIFUJI Hideaki wrote:
>> We should queue fragments for the same link-local address on
>> different interfaces (e.g. fe80::1%eth0 and fe80::1%eth1) to the
>> different queue, because of nature of addressing architecture.
>>
>> Similarly, we should queue fragments for multicast on different
>> interface to the different queue. This is okay because
>> application joins group on speicific interface, and multicast
>> traffic is expected only on that interface.
>>
>> CC: Ben Greear <greearb@candelatech.com>
>> CC: Vlad Yasevich <vyasevic@redhat.com>
>> CC: Eric Dumazet <eric.dumazet@gmail.com>
>> Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
>
> I just found this patch while cleaning up my tree. I don't know its state
> (netdev patchworks says RFC and netfilter patchworks still lists it as
> new). However, I also do think that the per interface matching would be
> the right thing to do for multicast|linklocal fragments. Perhaps this patch
> should be resend?
Will do.
> Yoshifuji, do you think we should also implement RFC 3168 5.3 ECN
> fragmentation protection in reassembly.c? I think it should be
> straightforward because it is already implemented for ipv4 and the
> relevant bits just need to be moved to inet_fragment.c and become a bit
> more generalized.
OK.
--yoshfuji
^ permalink raw reply
* Re: [Patch net-next] net: fix some typos in netif features
From: Pravin Shelar @ 2013-03-17 2:45 UTC (permalink / raw)
To: Cong Wang; +Cc: netdev, David S. Miller
In-Reply-To: <1363445275-3917-1-git-send-email-amwang@redhat.com>
On Sat, Mar 16, 2013 at 7:47 AM, Cong Wang <amwang@redhat.com> wrote:
> From: Cong Wang <amwang@redhat.com>
>
> Cc: Pravin B Shelar <pshelar@nicira.com>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Cong Wang <amwang@redhat.com>
>
Looks good.
Acked-by: Pravin B Shelar <pshelar@nicira.com>
> ---
>
> diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
> index f5e797c..d6ee2d0 100644
> --- a/include/linux/netdev_features.h
> +++ b/include/linux/netdev_features.h
> @@ -102,8 +102,8 @@ enum {
> #define NETIF_F_VLAN_CHALLENGED __NETIF_F(VLAN_CHALLENGED)
> #define NETIF_F_RXFCS __NETIF_F(RXFCS)
> #define NETIF_F_RXALL __NETIF_F(RXALL)
> -#define NETIF_F_GRE_GSO __NETIF_F(GSO_GRE)
> -#define NETIF_F_UDP_TUNNEL __NETIF_F(UDP_TUNNEL)
> +#define NETIF_F_GSO_GRE __NETIF_F(GSO_GRE)
> +#define NETIF_F_GSO_UDP_TUNNEL __NETIF_F(GSO_UDP_TUNNEL)
>
> /* Features valid for ethtool to change */
> /* = all defined minus driver/device-class-related */
^ permalink raw reply
* Re: [PATCH] Revert "ip_gre: make ipgre_tunnel_xmit() not parse network header as IP unconditionally"
From: David Miller @ 2013-03-17 3:01 UTC (permalink / raw)
To: timo.teras; +Cc: netdev, yamahata, edumazet
In-Reply-To: <1363178269-27553-1-git-send-email-timo.teras@iki.fi>
From: Timo Teräs <timo.teras@iki.fi>
Date: Wed, 13 Mar 2013 14:37:49 +0200
> This reverts commit 412ed94744d16806fbec3bd250fd94e71cde5a1f.
>
> The commit is wrong as tiph points to the outer IPv4 header which is
> installed at ipgre_header() and not the inner one which is protocol dependant.
>
> This commit broke succesfully opennhrp which use PF_PACKET socket with
> ETH_P_NHRP protocol. Additionally ssl_addr is set to the link-layer
> IPv4 address. This address is written by ipgre_header() to the skb
> earlier, and this is the IPv4 header tiph should point to - regardless
> of the inner protocol payload.
>
> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Applied, and queued up for -stable, thanks.
^ permalink raw reply
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: Hannes Frederic Sowa @ 2013-03-17 6:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: dormando, Cong Wang, linux-kernel, netdev
In-Reply-To: <1363455366.29475.66.camel@edumazet-glaptop>
On Sat, Mar 16, 2013 at 10:36:06AM -0700, Eric Dumazet wrote:
> On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
>
> > Thanks thats really useful, we might miss to increment socket refcount
> > in a timer setup.
> >
>
> Hmm, please add following debugging patch as well
>
> diff --git a/include/net/sock.h b/include/net/sock.h
> index 14f6e9d..fe7c8a6 100644
> --- a/include/net/sock.h
> +++ b/include/net/sock.h
> @@ -530,7 +530,9 @@ static inline void sock_hold(struct sock *sk)
> */
> static inline void __sock_put(struct sock *sk)
> {
> - atomic_dec(&sk->sk_refcnt);
> + int newref = atomic_dec_return(&sk->sk_refcnt);
> +
> + BUG_ON(newref <= 0);
> }
Couldn't it also be a free from sock_wfree where the wmem accounting went
wrong? It does not care about reference counts there.
^ permalink raw reply
* [PATCH] drivers: net: irda: use resource_size() in au1k_ir.c
From: Silviu-Mihai Popescu @ 2013-03-17 7:03 UTC (permalink / raw)
To: netdev; +Cc: samuel, linux-kernel, Silviu-Mihai Popescu
This uses the resource_size() function instead of explicit computation.
Signed-off-by: Silviu-Mihai Popescu <silviupopescu1990@gmail.com>
---
drivers/net/irda/au1k_ir.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/irda/au1k_ir.c b/drivers/net/irda/au1k_ir.c
index b5151e4..56f1e6d 100644
--- a/drivers/net/irda/au1k_ir.c
+++ b/drivers/net/irda/au1k_ir.c
@@ -27,6 +27,7 @@
#include <linux/slab.h>
#include <linux/time.h>
#include <linux/types.h>
+#include <linux/ioport.h>
#include <net/irda/irda.h>
#include <net/irda/irmod.h>
@@ -882,12 +883,12 @@ static int au1k_irda_probe(struct platform_device *pdev)
goto out;
err = -EBUSY;
- aup->ioarea = request_mem_region(r->start, r->end - r->start + 1,
+ aup->ioarea = request_mem_region(r->start, resource_size(r),
pdev->name);
if (!aup->ioarea)
goto out;
- aup->iobase = ioremap_nocache(r->start, r->end - r->start + 1);
+ aup->iobase = ioremap_nocache(r->start, resource_size(r));
if (!aup->iobase)
goto out2;
--
1.7.9.5
^ permalink raw reply related
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: Hannes Frederic Sowa @ 2013-03-17 7:53 UTC (permalink / raw)
To: Eric Dumazet, dormando, Cong Wang, linux-kernel, netdev
In-Reply-To: <20130317063948.GF24041@order.stressinduktion.org>
On Sun, Mar 17, 2013 at 07:39:48AM +0100, Hannes Frederic Sowa wrote:
> On Sat, Mar 16, 2013 at 10:36:06AM -0700, Eric Dumazet wrote:
> > On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
> >
> > > Thanks thats really useful, we might miss to increment socket refcount
> > > in a timer setup.
> > >
> >
> > Hmm, please add following debugging patch as well
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 14f6e9d..fe7c8a6 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -530,7 +530,9 @@ static inline void sock_hold(struct sock *sk)
> > */
> > static inline void __sock_put(struct sock *sk)
> > {
> > - atomic_dec(&sk->sk_refcnt);
> > + int newref = atomic_dec_return(&sk->sk_refcnt);
> > +
> > + BUG_ON(newref <= 0);
> > }
>
> Couldn't it also be a free from sock_wfree where the wmem accounting went
> wrong? It does not care about reference counts there.
nvm, it had to be in the stacktrace then.
^ permalink raw reply
* Re: BUG: IPv4: Attempt to release TCP socket in state 1
From: dormando @ 2013-03-17 9:21 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Cong Wang, linux-kernel, netdev
In-Reply-To: <1363455885.29475.68.camel@edumazet-glaptop>
> On Sat, 2013-03-16 at 10:36 -0700, Eric Dumazet wrote:
> > On Fri, 2013-03-15 at 00:19 +0100, Eric Dumazet wrote:
> >
> > > Thanks thats really useful, we might miss to increment socket refcount
> > > in a timer setup.
> > >
> >
> > Hmm, please add following debugging patch as well
> >
> > diff --git a/include/net/sock.h b/include/net/sock.h
> > index 14f6e9d..fe7c8a6 100644
> > --- a/include/net/sock.h
> > +++ b/include/net/sock.h
> > @@ -530,7 +530,9 @@ static inline void sock_hold(struct sock *sk)
> > */
> > static inline void __sock_put(struct sock *sk)
> > {
> > - atomic_dec(&sk->sk_refcnt);
> > + int newref = atomic_dec_return(&sk->sk_refcnt);
> > +
> > + BUG_ON(newref <= 0);
> > }
> >
> > static inline bool sk_del_node_init(struct sock *sk)
> > diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> > index 786d97a..a445e15 100644
> > --- a/net/ipv4/inet_connection_sock.c
> > +++ b/net/ipv4/inet_connection_sock.c
> > @@ -739,7 +739,7 @@ void inet_csk_prepare_forced_close(struct sock *sk)
> > {
> > /* sk_clone_lock locked the socket and set refcnt to 2 */
> > bh_unlock_sock(sk);
> > - sock_put(sk);
> > + __sock_put(sk);
> >
> > /* The below has to be done to allow calling inet_csk_destroy_sock */
> > sock_set_flag(sk, SOCK_DEAD);
> > @@ -835,13 +835,13 @@ void inet_csk_listen_stop(struct sock *sk)
> > * tcp_v4_destroy_sock().
> > */
> > tcp_sk(child)->fastopen_rsk = NULL;
> > - sock_put(sk);
> > + __sock_put(sk);
> > }
> > inet_csk_destroy_sock(child);
> >
> > bh_unlock_sock(child);
> > local_bh_enable();
> > - sock_put(child);
> > + __sock_put(child);
> >
>
> Please don't include the last line : this should stay as
>
> sock_put(child);
Hope you don't mind a screenshot:
http://www.dormando.me/p/3.8.2-trace-crash.jpg
(I put the patches on 3.8.2). box is on another continent so screenshot
via IPMI is what I get. If this isn't enough or isn't right I'll try
harder to get the trace logged, I guess?
Thanks!
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox