* Re: [PATCH 2/7] ns: Introduce the setns syscall
From: Eric W. Biederman @ 2011-05-11 20:33 UTC (permalink / raw)
To: Nathan Lynch
Cc: linux-arch, netdev, linux-kernel, Linux Containers, linux-fsdevel
In-Reply-To: <1305141681.1236.48.camel@orca.stoopid.dyndns.org>
Nathan Lynch <ntl@pobox.com> writes:
> Hi Eric,
>
> On Fri, 2011-05-06 at 19:24 -0700, Eric W. Biederman wrote:
>> With the networking stack today there is demand to handle
>> multiple network stacks at a time. Not in the context
>> of containers but in the context of people doing interesting
>> things with routing.
>>
>> There is also demand in the context of containers to have
>> an efficient way to execute some code in the container itself.
>> If nothing else it is very useful ad a debugging technique.
>>
>> Both problems can be solved by starting some form of login
>> daemon in the namespaces people want access to, or you
>> can play games by ptracing a process and getting the
>> traced process to do things you want it to do. However
>> it turns out that a login daemon or a ptrace puppet
>> controller are more code, they are more prone to
>> failure, and generally they are less efficient than
>> simply changing the namespace of a process to a
>> specified one.
>>
>> Pieces of this puzzle can also be solved by instead of
>> coming up with a general purpose system call coming up
>> with targed system calls perhaps socketat that solve
>> a subset of the larger problem. Overall that appears
>> to be more work for less reward.
>>
>> int setns(int fd, int nstype);
>>
>> The fd argument is a file descriptor referring to a proc
>> file of the namespace you want to switch the process to.
>>
>> In the setns system call the nstype is 0 or specifies
>> an clone flag of the namespace you intend to change
>> to prevent changing a namespace unintentionally.
>
> I don't understand exactly what the nstype argument buys us - why would
> correct code ever need to specify a value other than 0? And reusing the
> CLONE_NEW* values in this interface is kind of ugly when setns is
> precisely _not_ creating new namespaces.
No but it is setting a new namespace. I do agree it is a bit ugly. But
the worst case at this point is I introduce a new set of beautiful
defines with the same values.
> Is there some fundamental reason it couldn't be
>
> int setns(int fd);
>
> or is there a use case I'm missing?
When someone else opens the file descriptor and passes it to us
and we don't completely trust them. Or equally when someone
else does the bind mount into the filesystem namespace and we
don't completely trust them.
Plus having a flags field is useful in general.
>> +SYSCALL_DEFINE2(setns, int, fd, int, nstype)
>> +{
>> + const struct proc_ns_operations *ops;
>> + struct task_struct *tsk = current;
>> + struct nsproxy *new_nsproxy;
>> + struct proc_inode *ei;
>> + struct file *file;
>> + int err;
>> +
>> + if (!capable(CAP_SYS_ADMIN))
>> + return -EPERM;
>> +
>> + file = proc_ns_fget(fd);
>> + if (IS_ERR(file))
>> + return PTR_ERR(file);
>> +
>> + err = -EINVAL;
>> + ei = PROC_I(file->f_dentry->d_inode);
>> + ops = ei->ns_ops;
>> + if (nstype && (ops->type != nstype))
>> + goto out;
>> +
>> + new_nsproxy = create_new_namespaces(0, tsk, tsk->fs);
>
> create_new_namespaces() can fail; shouldn't this be checked?
Yes. This was pointed out a little earlier and has been fixed
in my tree.
>> + err = ops->install(new_nsproxy, ei->ns);
>> + if (err) {
>> + free_nsproxy(new_nsproxy);
>> + goto out;
>> + }
>> + switch_task_namespaces(tsk, new_nsproxy);
>> +out:
>> + fput(file);
>> + return err;
>> +}
>> +
Eric
^ permalink raw reply
* Re: [PATCH] pci, e1000e: Add and use __pci_disable_link_state
From: Yinghai Lu @ 2011-05-11 20:23 UTC (permalink / raw)
To: Jesse Barnes
Cc: Andrew Morton, Naga Chumbalkar, e1000-devel, Bruce Allan,
Jesse Brandeburg, linux-pci, linux-kernel, Rafael J. Wysocki,
John Ronciak, Kenji Kaneshige, netdev, Matthew Garrett
In-Reply-To: <20110509143536.08bd0297@jbarnes-desktop>
On 05/09/2011 02:35 PM, Jesse Barnes wrote:
> On Sun, 08 May 2011 11:54:32 -0700
> Yinghai Lu <yinghai@kernel.org> wrote:
>
>>
>> Need to use it in _e1000e_disable_aspm.
>> when aer happens,
>> pci_walk_bus already have down_read(&pci_bus_sem)...
>> then report_slot_reset
>> ==> e1000_io_slot_reset
>> ==> e1000e_disable_aspm
>> ==> pci_disable_link_state...
>>
>> We can not use pci_disable_link_state, and it will try to hold pci_bus_sem again.
>>
>> Try to have __pci_disable_link_state that will not need to hold pci_bus_sem.
>
> What about the other callers of e1000e_disable_aspm? Do they already
> have the lock held or is it just reset that needs the already locked
> version?
yes.
there is another version when aspm is not defined. and it does not use any lock.
#ifdef CONFIG_PCIEASPM
static void __e1000e_disable_aspm(struct pci_dev *pdev, u16 state)
{
pci_disable_link_state(pdev, state);
}
#else
static void __e1000e_disable_aspm(struct pci_dev *pdev, u16 state)
{
int pos;
u16 reg16;
/*
* Both device and parent should have the same ASPM setting.
* Disable ASPM in downstream component first and then upstream.
*/
pos = pci_pcie_cap(pdev);
pci_read_config_word(pdev, pos + PCI_EXP_LNKCTL, ®16);
reg16 &= ~state;
pci_write_config_word(pdev, pos + PCI_EXP_LNKCTL, reg16);
if (!pdev->bus->self)
return;
pos = pci_pcie_cap(pdev->bus->self);
pci_read_config_word(pdev->bus->self, pos + PCI_EXP_LNKCTL, ®16);
reg16 &= ~state;
pci_write_config_word(pdev->bus->self, pos + PCI_EXP_LNKCTL, reg16);
}
#endif
>
>> +extern void __pci_disable_link_state(struct pci_dev *pdev, int state);
>> extern void pcie_clear_aspm(void);
>> extern void pcie_no_aspm(void);
>> #else
>
> pci_disable_link_state_locked would be more descriptive and would match
> other usage in the kernel.
ok.
Thanks
Yinghai
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* pull request: wireless-2.6 2011-05-11
From: John W. Linville @ 2011-05-11 19:27 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
Dave,
Here are a few more late-breakers that I would like to see in 2.6.39.
The one from Luca fixes a problem that can cause devices to be unable
to (re-)associate after a disconnect. The ath9k fix from Mohammed
fixes a WARNING, the one from Paul fixes a locking issue that can
lead to data corruption, and the one from Stanislaw fixes a crash
documented in bug 34452. All are small and all but one are contained
within their respective drivers.
Please let me know if there are problems!
John
---
The following changes since commit 9bbc052d5e63512b0ce4e201ea97e12fba9fda82:
Merge branch 'pablo/nf-2.6-updates' of git://1984.lsi.us.es/net-2.6 (2011-05-10 15:04:35 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git master
Luciano Coelho (1):
mac80211: don't start the dynamic ps timer if not associated
Mohammed Shafi Shajakhan (1):
ath9k: Fix a warning due to a queued work during S3 state
Paul Fox (1):
libertas: fix cmdpendingq locking
Stanislaw Gruszka (1):
iwlegacy: fix IBSS mode crashes
drivers/net/wireless/ath/ath9k/main.c | 8 ++++++++
drivers/net/wireless/iwlegacy/iwl-core.c | 7 +++++++
drivers/net/wireless/iwlegacy/iwl-dev.h | 6 ++++++
drivers/net/wireless/libertas/cmd.c | 6 ++++--
net/mac80211/tx.c | 4 ++++
5 files changed, 29 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/main.c b/drivers/net/wireless/ath/ath9k/main.c
index 17d04ff..1482fa6 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -2141,6 +2141,8 @@ static void ath9k_set_coverage_class(struct ieee80211_hw *hw, u8 coverage_class)
static void ath9k_flush(struct ieee80211_hw *hw, bool drop)
{
struct ath_softc *sc = hw->priv;
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
int timeout = 200; /* ms */
int i, j;
@@ -2149,6 +2151,12 @@ static void ath9k_flush(struct ieee80211_hw *hw, bool drop)
cancel_delayed_work_sync(&sc->tx_complete_work);
+ if (sc->sc_flags & SC_OP_INVALID) {
+ ath_dbg(common, ATH_DBG_ANY, "Device not present\n");
+ mutex_unlock(&sc->mutex);
+ return;
+ }
+
if (drop)
timeout = 1;
diff --git a/drivers/net/wireless/iwlegacy/iwl-core.c b/drivers/net/wireless/iwlegacy/iwl-core.c
index 2b08efb..dcbb2ef 100644
--- a/drivers/net/wireless/iwlegacy/iwl-core.c
+++ b/drivers/net/wireless/iwlegacy/iwl-core.c
@@ -2155,6 +2155,13 @@ int iwl_legacy_mac_config(struct ieee80211_hw *hw, u32 changed)
goto set_ch_out;
}
+ if (priv->iw_mode == NL80211_IFTYPE_ADHOC &&
+ !iwl_legacy_is_channel_ibss(ch_info)) {
+ IWL_DEBUG_MAC80211(priv, "leave - not IBSS channel\n");
+ ret = -EINVAL;
+ goto set_ch_out;
+ }
+
spin_lock_irqsave(&priv->lock, flags);
for_each_context(priv, ctx) {
diff --git a/drivers/net/wireless/iwlegacy/iwl-dev.h b/drivers/net/wireless/iwlegacy/iwl-dev.h
index 9ee849d..f43ac1e 100644
--- a/drivers/net/wireless/iwlegacy/iwl-dev.h
+++ b/drivers/net/wireless/iwlegacy/iwl-dev.h
@@ -1411,6 +1411,12 @@ iwl_legacy_is_channel_passive(const struct iwl_channel_info *ch)
return (!(ch->flags & EEPROM_CHANNEL_ACTIVE)) ? 1 : 0;
}
+static inline int
+iwl_legacy_is_channel_ibss(const struct iwl_channel_info *ch)
+{
+ return (ch->flags & EEPROM_CHANNEL_IBSS) ? 1 : 0;
+}
+
static inline void
__iwl_legacy_free_pages(struct iwl_priv *priv, struct page *page)
{
diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c
index 7e8a658..f3ac624 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -1339,8 +1339,8 @@ int lbs_execute_next_command(struct lbs_private *priv)
cpu_to_le16(PS_MODE_ACTION_EXIT_PS)) {
lbs_deb_host(
"EXEC_NEXT_CMD: ignore ENTER_PS cmd\n");
- list_del(&cmdnode->list);
spin_lock_irqsave(&priv->driver_lock, flags);
+ list_del(&cmdnode->list);
lbs_complete_command(priv, cmdnode, 0);
spin_unlock_irqrestore(&priv->driver_lock, flags);
@@ -1352,8 +1352,8 @@ int lbs_execute_next_command(struct lbs_private *priv)
(priv->psstate == PS_STATE_PRE_SLEEP)) {
lbs_deb_host(
"EXEC_NEXT_CMD: ignore EXIT_PS cmd in sleep\n");
- list_del(&cmdnode->list);
spin_lock_irqsave(&priv->driver_lock, flags);
+ list_del(&cmdnode->list);
lbs_complete_command(priv, cmdnode, 0);
spin_unlock_irqrestore(&priv->driver_lock, flags);
priv->needtowakeup = 1;
@@ -1366,7 +1366,9 @@ int lbs_execute_next_command(struct lbs_private *priv)
"EXEC_NEXT_CMD: sending EXIT_PS\n");
}
}
+ spin_lock_irqsave(&priv->driver_lock, flags);
list_del(&cmdnode->list);
+ spin_unlock_irqrestore(&priv->driver_lock, flags);
lbs_deb_host("EXEC_NEXT_CMD: sending command 0x%04x\n",
le16_to_cpu(cmd->command));
lbs_submit_command(priv, cmdnode);
diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index ce4596e..bd1224f 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -237,6 +237,10 @@ ieee80211_tx_h_dynamic_ps(struct ieee80211_tx_data *tx)
&local->dynamic_ps_disable_work);
}
+ /* Don't restart the timer if we're not disassociated */
+ if (!ifmgd->associated)
+ return TX_CONTINUE;
+
mod_timer(&local->dynamic_ps_timer, jiffies +
msecs_to_jiffies(local->hw.conf.dynamic_ps_timeout));
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: [PATCH 3/7] ns proc: Add support for the network namespace.
From: Nathan Lynch @ 2011-05-11 19:21 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-arch, linux-kernel, netdev, linux-fsdevel, jamal,
Daniel Lezcano, Linux Containers, Renato Westphal
In-Reply-To: <1304735101-1824-3-git-send-email-ebiederm@xmission.com>
On Fri, 2011-05-06 at 19:24 -0700, Eric W. Biederman wrote:
> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 3f86026..bf7707e 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -573,3 +573,34 @@ void unregister_pernet_device(struct pernet_operations *ops)
> mutex_unlock(&net_mutex);
> }
> EXPORT_SYMBOL_GPL(unregister_pernet_device);
> +
> +#ifdef CONFIG_NET_NS
> +static void *netns_get(struct task_struct *task)
> +{
> + struct net *net;
> + rcu_read_lock();
> + net = get_net(task->nsproxy->net_ns);
This should use task_nsproxy() and check the result before grabbing the
net_ns, but I think you fix that in a later patch.
Regardless, it looks as if all the proc_ns_ops->get() implementations
really just want the nsproxy, so maybe the get() methods should take
that instead of the task_struct, and proc_ns_instantiate() should do
something like:
struct nsproxy *nsproxy;
...
ei->ns_ops = ns_ops;
error = -ESRCH;
rcu_read_lock();
nsproxy = task_nsproxy(task);
rcu_read_unlock();
if (!nsproxy)
got out;
ei->ns = ns_ops->get(nsproxy);
So then the zombie check is consolidated in one place instead of having
to do it in every get() method.
> + rcu_read_unlock();
> + return net;
> +}
> +
> +static void netns_put(void *ns)
> +{
> + put_net(ns);
> +}
> +
> +static int netns_install(struct nsproxy *nsproxy, void *ns)
> +{
> + put_net(nsproxy->net_ns);
> + nsproxy->net_ns = get_net(ns);
> + return 0;
> +}
This introduces a window where, potentially, nsproxy->net_ns is stale
before it is updated with the namespace which is being attached, no?
(Same concern applies to other install methods in the patch set). It
seems possible to oops the kernel in this window by looking up
/proc/$PID/ns/net while $PID is in the midst of setns().
^ permalink raw reply
* Re: [PATCH 2/7] ns: Introduce the setns syscall
From: Nathan Lynch @ 2011-05-11 19:21 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-arch, netdev, linux-kernel, Linux Containers, linux-fsdevel
In-Reply-To: <1304735101-1824-2-git-send-email-ebiederm@xmission.com>
Hi Eric,
On Fri, 2011-05-06 at 19:24 -0700, Eric W. Biederman wrote:
> With the networking stack today there is demand to handle
> multiple network stacks at a time. Not in the context
> of containers but in the context of people doing interesting
> things with routing.
>
> There is also demand in the context of containers to have
> an efficient way to execute some code in the container itself.
> If nothing else it is very useful ad a debugging technique.
>
> Both problems can be solved by starting some form of login
> daemon in the namespaces people want access to, or you
> can play games by ptracing a process and getting the
> traced process to do things you want it to do. However
> it turns out that a login daemon or a ptrace puppet
> controller are more code, they are more prone to
> failure, and generally they are less efficient than
> simply changing the namespace of a process to a
> specified one.
>
> Pieces of this puzzle can also be solved by instead of
> coming up with a general purpose system call coming up
> with targed system calls perhaps socketat that solve
> a subset of the larger problem. Overall that appears
> to be more work for less reward.
>
> int setns(int fd, int nstype);
>
> The fd argument is a file descriptor referring to a proc
> file of the namespace you want to switch the process to.
>
> In the setns system call the nstype is 0 or specifies
> an clone flag of the namespace you intend to change
> to prevent changing a namespace unintentionally.
I don't understand exactly what the nstype argument buys us - why would
correct code ever need to specify a value other than 0? And reusing the
CLONE_NEW* values in this interface is kind of ugly when setns is
precisely _not_ creating new namespaces.
Is there some fundamental reason it couldn't be
int setns(int fd);
or is there a use case I'm missing?
> +SYSCALL_DEFINE2(setns, int, fd, int, nstype)
> +{
> + const struct proc_ns_operations *ops;
> + struct task_struct *tsk = current;
> + struct nsproxy *new_nsproxy;
> + struct proc_inode *ei;
> + struct file *file;
> + int err;
> +
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> +
> + file = proc_ns_fget(fd);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + err = -EINVAL;
> + ei = PROC_I(file->f_dentry->d_inode);
> + ops = ei->ns_ops;
> + if (nstype && (ops->type != nstype))
> + goto out;
> +
> + new_nsproxy = create_new_namespaces(0, tsk, tsk->fs);
create_new_namespaces() can fail; shouldn't this be checked?
> + err = ops->install(new_nsproxy, ei->ns);
> + if (err) {
> + free_nsproxy(new_nsproxy);
> + goto out;
> + }
> + switch_task_namespaces(tsk, new_nsproxy);
> +out:
> + fput(file);
> + return err;
> +}
> +
^ permalink raw reply
* Re: [PATCH 1/7] ns: proc files for namespace naming policy.
From: Nathan Lynch @ 2011-05-11 19:20 UTC (permalink / raw)
To: Eric W. Biederman
Cc: linux-arch, linux-kernel, netdev, linux-fsdevel, jamal,
Daniel Lezcano, Linux Containers, Renato Westphal
In-Reply-To: <1304735101-1824-1-git-send-email-ebiederm@xmission.com>
Hi Eric,
A few comments on your patch set.
On Fri, 2011-05-06 at 19:24 -0700, Eric W. Biederman wrote:
> diff --git a/fs/proc/inode.c b/fs/proc/inode.c
> index d15aa1b..74b48cf 100644
> --- a/fs/proc/inode.c
> +++ b/fs/proc/inode.c
> @@ -28,6 +28,7 @@ static void proc_evict_inode(struct inode *inode)
> {
> struct proc_dir_entry *de;
> struct ctl_table_header *head;
> + const struct proc_ns_operations *ns_ops;
>
> truncate_inode_pages(&inode->i_data, 0);
> end_writeback(inode);
> @@ -44,6 +45,10 @@ static void proc_evict_inode(struct inode *inode)
> rcu_assign_pointer(PROC_I(inode)->sysctl, NULL);
> sysctl_head_put(head);
> }
> + /* Release any associated namespace */
> + ns_ops = PROC_I(inode)->ns_ops;
> + if (ns_ops && ns_ops->put)
> + ns_ops->put(PROC_I(inode)->ns);
Is it ever valid for ns_ops->put to be null? If not, I suggest removing
the check.
> diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c
> new file mode 100644
> index 0000000..6ae9f07
> --- /dev/null
> +++ b/fs/proc/namespaces.c
...
> +static struct dentry *proc_ns_dir_lookup(struct inode *dir,
> + struct dentry *dentry, struct nameidata *nd)
> +{
> + struct dentry *error;
> + struct task_struct *task = get_proc_task(dir);
> + const struct proc_ns_operations **entry, **last;
> + unsigned int len = dentry->d_name.len;
> +
> + error = ERR_PTR(-ENOENT);
> +
> + if (!task)
> + goto out_no_task;
> +
> + error = ERR_PTR(-EPERM);
> + if (!ptrace_may_access(task, PTRACE_MODE_READ))
> + goto out;
> +
> + last = &ns_entries[ARRAY_SIZE(ns_entries) - 1];
> + for (entry = ns_entries; entry <= last; entry++) {
> + if (strlen((*entry)->name) != len)
> + continue;
> + if (!memcmp(dentry->d_name.name, (*entry)->name, len))
> + break;
> + }
> + if (entry > last)
> + goto out;
This returns EPERM when it should return ENOENT?
> +
> + error = proc_ns_instantiate(dir, dentry, task, *entry);
> +out:
> + put_task_struct(task);
> +out_no_task:
> + return error;
> +}
...
> --- a/include/linux/proc_fs.h
> +++ b/include/linux/proc_fs.h
> @@ -250,6 +257,15 @@ kclist_add(struct kcore_list *new, void *addr, size_t size, int type)
> extern void kclist_add(struct kcore_list *, void *, size_t, int type);
> #endif
>
> +struct nsproxy;
> +struct proc_ns_operations {
> + const char *name;
> + int type;
> + void *(*get)(struct task_struct *task);
> + void (*put)(void *ns);
> + int (*install)(struct nsproxy *nsproxy, void *ns);
> +};
> +
> union proc_op {
> int (*proc_get_link)(struct inode *, struct path *);
> int (*proc_read)(struct task_struct *task, char *page);
> @@ -268,6 +284,8 @@ struct proc_inode {
> struct proc_dir_entry *pde;
> struct ctl_table_header *sysctl;
> struct ctl_table *sysctl_entry;
> + void *ns;
> + const struct proc_ns_operations *ns_ops;
> struct inode vfs_inode;
> };
Not that I have any better ideas, but it seems a bit undesirable to
increase the size of proc_inode for this one purpose.
^ permalink raw reply
* Re: [PATCHv1] e1000e: Allow ethtool to enable/disable loopback.
From: Michał Mirosław @ 2011-05-11 19:15 UTC (permalink / raw)
To: Mahesh Bandewar
Cc: Jeff Kirsher, e1000-devel, David Miller, netdev, Tom Herbert
In-Reply-To: <1305140625-25888-1-git-send-email-maheshb@google.com>
2011/5/11 Mahesh Bandewar <maheshb@google.com>:
> This patch adds e1000_set_features() to handle loopback mode. When loopback
> is enabled, it enables internal-MAC loopback.
Please wait for this driver's conversion to hw_features. One comment
below, though.
[...]
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
[...]
> +static int e1000_set_features(struct net_device *dev, u32 features)
> +{
> + u32 changed = dev->features ^ features;
> +
> + if ((changed & NETIF_F_LOOPBACK) && netif_running(dev))
> + e1000_set_loopback(dev, features);
> +
> + return 0;
> +}
[...]
If e1000_set_loopback() fails, this should set dev->features to passed
features (but keeping NETIF_F_LOOPBACK unchanged in dev->features) to
keep the state consistent.
Best Regards,
Michał Mirosław
^ permalink raw reply
* [PATCHv1] e1000e: Allow ethtool to enable/disable loopback.
From: Mahesh Bandewar @ 2011-05-11 19:03 UTC (permalink / raw)
To: Jeff Kirsher, e1000-devel, David Miller
Cc: netdev, Tom Herbert, Mahesh Bandewar
This patch adds e1000_set_features() to handle loopback mode. When loopback
is enabled, it enables internal-MAC loopback.
Signed-off-by: Mahesh Bandewar <maheshb@google.com>
---
drivers/net/e1000e/e1000.h | 1 +
drivers/net/e1000e/ethtool.c | 34 ++++++++++++++++++++++++++++++++++
drivers/net/e1000e/netdev.c | 21 +++++++++++++++++++++
drivers/net/e1000e/phy.c | 19 +++++++++++++++----
4 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/drivers/net/e1000e/e1000.h b/drivers/net/e1000e/e1000.h
index 9549879..9db3037 100644
--- a/drivers/net/e1000e/e1000.h
+++ b/drivers/net/e1000e/e1000.h
@@ -640,6 +640,7 @@ extern s32 e1000_check_polarity_ife(struct e1000_hw *hw);
extern s32 e1000_phy_force_speed_duplex_ife(struct e1000_hw *hw);
extern s32 e1000_check_polarity_igp(struct e1000_hw *hw);
extern bool e1000_check_phy_82574(struct e1000_hw *hw);
+extern int e1000_set_loopback(struct net_device *dev, u32 features);
static inline s32 e1000_phy_hw_reset(struct e1000_hw *hw)
{
diff --git a/drivers/net/e1000e/ethtool.c b/drivers/net/e1000e/ethtool.c
index 859d0d3..9c26b42 100644
--- a/drivers/net/e1000e/ethtool.c
+++ b/drivers/net/e1000e/ethtool.c
@@ -2027,6 +2027,40 @@ static int e1000e_set_flags(struct net_device *netdev, u32 data)
return 0;
}
+int e1000_set_loopback(struct net_device *netdev, u32 features)
+{
+ struct e1000_adapter *adapter = netdev_priv(netdev);
+ struct e1000_hw *hw = &adapter->hw;
+ uint16_t reg = 0;
+ int retval = 0;
+
+ if ((retval = e1e_rphy(hw, PHY_CONTROL, ®)) > 0)
+ return retval;
+
+ if (features & NETIF_F_LOOPBACK) {
+ if (reg & MII_CR_LOOPBACK)
+ return 0;
+
+ retval = e1000_setup_loopback_test(adapter);
+ if (retval)
+ return retval;
+
+ netdev_info(netdev,
+ "e1000e: Internal PHY loopback mode enabled.\n");
+ } else {
+ if (!(reg & MII_CR_LOOPBACK))
+ return 0;
+
+ e1000_loopback_cleanup(adapter);
+ e1000e_down(adapter);
+ e1000e_up(adapter);
+ netdev_info(netdev,
+ "e1000e: Internal PHY loopback mode disabled.\n");
+ }
+
+ return retval;
+}
+
static const struct ethtool_ops e1000_ethtool_ops = {
.get_settings = e1000_get_settings,
.set_settings = e1000_set_settings,
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index 0939040..6aee9b19 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -3688,6 +3688,13 @@ static int e1000_open(struct net_device *netdev)
else
ew32(ICS, E1000_ICS_LSC);
+ /*
+ * If loopback was enabled while the device was down,
+ * make sure it gets installed properly now.
+ */
+ if (netdev->features & NETIF_F_LOOPBACK)
+ e1000_set_loopback(netdev, netdev->features);
+
return 0;
err_req_irq:
@@ -5623,6 +5630,16 @@ static void e1000_netpoll(struct net_device *netdev)
}
#endif
+static int e1000_set_features(struct net_device *dev, u32 features)
+{
+ u32 changed = dev->features ^ features;
+
+ if ((changed & NETIF_F_LOOPBACK) && netif_running(dev))
+ e1000_set_loopback(dev, features);
+
+ return 0;
+}
+
/**
* e1000_io_error_detected - called when PCI error is detected
* @pdev: Pointer to PCI device
@@ -5789,6 +5806,7 @@ static const struct net_device_ops e1000e_netdev_ops = {
#ifdef CONFIG_NET_POLL_CONTROLLER
.ndo_poll_controller = e1000_netpoll,
#endif
+ .ndo_set_features = e1000_set_features,
};
/**
@@ -6093,6 +6111,9 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
e1000_print_device_info(adapter);
+ /* Add loopback capability to the device. */
+ netdev->hw_features |= NETIF_F_LOOPBACK;
+
if (pci_dev_run_wake(pdev))
pm_runtime_put_noidle(&pdev->dev);
diff --git a/drivers/net/e1000e/phy.c b/drivers/net/e1000e/phy.c
index 484774c..9bc5df3 100644
--- a/drivers/net/e1000e/phy.c
+++ b/drivers/net/e1000e/phy.c
@@ -1758,7 +1758,7 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32 iterations,
u32 usec_interval, bool *success)
{
s32 ret_val = 0;
- u16 i, phy_status;
+ u16 i, reg;
for (i = 0; i < iterations; i++) {
/*
@@ -1766,7 +1766,7 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32 iterations,
* twice due to the link bit being sticky. No harm doing
* it across the board.
*/
- ret_val = e1e_rphy(hw, PHY_STATUS, &phy_status);
+ ret_val = e1e_rphy(hw, PHY_STATUS, ®);
if (ret_val)
/*
* If the first read fails, another entity may have
@@ -1774,10 +1774,10 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32 iterations,
* see if they have relinquished the resources yet.
*/
udelay(usec_interval);
- ret_val = e1e_rphy(hw, PHY_STATUS, &phy_status);
+ ret_val = e1e_rphy(hw, PHY_STATUS, ®);
if (ret_val)
break;
- if (phy_status & MII_SR_LINK_STATUS)
+ if (reg & MII_SR_LINK_STATUS)
break;
if (usec_interval >= 1000)
mdelay(usec_interval/1000);
@@ -1787,6 +1787,17 @@ s32 e1000e_phy_has_link_generic(struct e1000_hw *hw, u32 iterations,
*success = (i < iterations);
+ /*
+ * If the device is in loopback mode, we have to fake
+ * link up. Try this only if link isn't present.
+ */
+ if (!(*success) && !e1e_rphy(hw, PHY_CONTROL, ®) &&
+ (reg & MII_CR_LOOPBACK)) {
+ /* Fake link up. */
+ *success = true;
+ ret_val = 0;
+ }
+
return ret_val;
}
--
1.7.3.1
^ permalink raw reply related
* What could be the cause of reboot hang on iptables script with niu driver interface up in RHL6.0 systems
From: Joyce Yu - System Software @ 2011-05-11 18:40 UTC (permalink / raw)
To: netdev
Hi,
Some of my Redhat 6.0 systems always have reboot hang problem on
iptables script with niu driver interface up. After adding some debug
stuff, I can see the system alway hang on " modprobe -r xt_state". What
could be the cause of it? Does niu driver need to handle some
calls/ioctls that currently not implemented in the niu driver?
Thanks,
Joyce
^ permalink raw reply
* Re: GIT net-2.6 rolled back 8 commits...
From: Eric Dumazet @ 2011-05-11 18:31 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless, netfilter-devel
In-Reply-To: <20110511.112909.226795883.davem@davemloft.net>
Le mercredi 11 mai 2011 à 11:29 -0700, David Miller a écrit :
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed, 11 May 2011 05:31:27 +0200
>
> > Would it be possible you sync net-next-2.6 and pull net-2.6 in it ?
>
> I'm taking care of this right now.
Wow excellent timing (for me at least), thanks !
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: GIT net-2.6 rolled back 8 commits...
From: David Miller @ 2011-05-11 18:29 UTC (permalink / raw)
To: eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1305084687.2437.44.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Wed, 11 May 2011 05:31:27 +0200
> Would it be possible you sync net-next-2.6 and pull net-2.6 in it ?
I'm taking care of this right now.
--
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
* Re: [PATCH 2/2] net/dl2k: Don't reconfigure link @100Mbps when disabling autoneg @1Gbps
From: Florian Weimer @ 2011-05-11 9:47 UTC (permalink / raw)
To: David Decotigny
Cc: Giuseppe Cavallaro, David S. Miller, Joe Perches,
Stanislaw Gruszka, netdev, linux-kernel
In-Reply-To: <1304986748-15809-3-git-send-email-decot@google.com>
* David Decotigny:
> Tested: module compiling, NOT tested on real hardware.
To my knowledge, dl2k is broken. Some sort of synchronization
primitives are missing. Under load, the NIC's notion of ring buffer
status diverges from the host's view. 8-(
--
Florian Weimer <fweimer@bfk.de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
^ permalink raw reply
* RE: [PATCH net-next 00/21] tipc updates for the next round
From: Stephens, Allan @ 2011-05-11 18:02 UTC (permalink / raw)
To: Gortmaker, Paul; +Cc: netdev@vger.kernel.org
In-Reply-To: <20110511.110111.193684522.davem@davemloft.net>
Excellent!
-- Al
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Wednesday, May 11, 2011 2:01 PM
> To: Gortmaker, Paul
> Cc: netdev@vger.kernel.org; Stephens, Allan
> Subject: Re: [PATCH net-next 00/21] tipc updates for the next round
>
> From: Paul Gortmaker <paul.gortmaker@windriver.com>
> Date: Tue, 10 May 2011 16:44:16 -0400
>
> > Another mixed bag of tipc commits. It leads off with some largely
> > cosmetic stuff, but then gets into what should be some more of the
> > useful/functional fixes with a bit more complexity. There really
> > isn't any new functionality here -- just fixes or robustness type
> > improvements.
> ...
> > git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-next-2.6.git
> > tipc-May10-2011
>
> Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next 00/21] tipc updates for the next round
From: David Miller @ 2011-05-11 18:01 UTC (permalink / raw)
To: paul.gortmaker; +Cc: netdev, Allan.Stephens
In-Reply-To: <1305060277-15600-1-git-send-email-paul.gortmaker@windriver.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Tue, 10 May 2011 16:44:16 -0400
> Another mixed bag of tipc commits. It leads off with some largely
> cosmetic stuff, but then gets into what should be some more of the
> useful/functional fixes with a bit more complexity. There really
> isn't any new functionality here -- just fixes or robustness type
> improvements.
...
> git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-next-2.6.git tipc-May10-2011
Pulled, thanks a lot.
^ permalink raw reply
* Re: future developments of usbnet
From: David Miller @ 2011-05-11 17:47 UTC (permalink / raw)
To: oliver-GvhC2dPhHPQdnm+yROfE0A
Cc: shemminger-ZtmgI6mnKB3QT0dZR+AlfA,
stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz,
tom.leiming-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201105111937.47448.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
From: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Date: Wed, 11 May 2011 19:37:47 +0200
> How is the frequency NAPI uses to poll determined? We could abuse
> this and resubmit the rx URBs only at poll time, but this feels dirty,
> because we would still leave interrupts enabled.
It's not a frequency determined internally by the networking.
It is purely event based (meaning triggered by the device's interrupt).
Control flow is:
IRQ --> irq_handler()
my_netdevice_disable_device_irq();
napi_schedule();
--> schedule POLL soft irq
SOFTIRQ --> net_rx_action()
budget = netdev_budget;
for_each_net_device_needing_polling() {
...
weight = napi_state->weight;
...
work = n->poll(n, weight);
...
budget -= work;
...
}
That's the general idea.
Basically once you take you interrupt, and disable device interrupts,
the generic net device layer calls your ->poll() routing with a "weight"
You should not process more RX packets than this value.
If you have less than "weight" work to do, you should do a napi_complete(),
which takes you out of the polling group, and re-enable device interrupts.
So the idea is that you keep getting ->poll()'d until there is no more
RX work to do.
The "weight" argument implements fairness amongst competing, actively
polling, devices on the same CPU.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: future developments of usbnet
From: Oliver Neukum @ 2011-05-11 17:37 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Alan Stern, Ming Lei, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110509084649.127ec0da@nehalam>
Am Montag, 9. Mai 2011, 17:46:49 schrieb Stephen Hemminger:
> On Mon, 9 May 2011 11:31:16 -0400 (EDT)
> Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org> wrote:
> > How do other network drivers handle this problem? Can the same
> > strategy be used?
> >
> > Alan Stern
>
> Most Ethernet drivers have a fixed size receive ring and pass preallocated
> memory (skb's or pages) for the hardware to fill in. When NAPI poll is run
> it refills the ring and passes the data up to netif_receive_skb. NAPI allows
> the poll routine to process a limited number of packets (weight) and after
> that the poll loop exits and gets rerun by soft interrupt. If data is
> arriving faster than the kernel can process, eventually the receive ring
> passed to hardware gets exhausted and the hardware drops packets.
How is the frequency NAPI uses to poll determined? We could abuse
this and resubmit the rx URBs only at poll time, but this feels dirty,
because we would still leave interrupts enabled.
Is there no other driver which faces this problem?
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 00/18] virtio and vhost-net performance enhancements
From: Krishna Kumar2 @ 2011-05-11 17:10 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Christian Borntraeger, Carsten Otte, habanero, Heiko Carstens,
kvm, lguest, linux-kernel, linux-s390, linux390, netdev,
Rusty Russell, Martin Schwidefsky, steved, Tom Lendacky,
virtualization, Shirley Ma
In-Reply-To: <cover.1304541918.git.mst@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> wrote on 05/05/2011 02:20:18 AM:
> [PATCH 00/18] virtio and vhost-net performance enhancements
>
> OK, here's a large patchset that implements the virtio spec update that I
> sent earlier. It supercedes the PUBLISH_USED_IDX patches
> I sent out earlier.
>
> I know it's a lot to ask but please test, and please consider for
2.6.40 :)
>
> I see nice performance improvements: one run showed going from 12
> to 18 Gbit/s host to guest with netperf, but I did not spend a lot
> of time testing performance, so no guarantees it's not a fluke,
> I hope others will try this out and report.
> Pls note I will be away from keyboard for the next week.
I tested with the git tree (which also contains the later
additional patch), and get this error on guest:
May 11 08:06:08 localhost kernel: net eth0: Unexpected TX queue failure:
-28
May 11 08:06:08 localhost kernel: net eth0: Unexpected TX queue failure:
-28
May 11 08:06:08 localhost kernel: net eth0: Unexpected TX queue failure:
-28
May 11 08:06:08 localhost kernel: net eth0: Unexpected TX queue failure:
-28
...
The network stops after that and requires a modprobe "restart" to
get it working again. This is with the new qemu/vhost/virtio-net.
Please let me know if I am missing something.
thanks,
- KK
^ permalink raw reply
* Re: [PATCH] Add libertas_disablemesh module parameter to disable mesh interface
From: Randy Dunlap @ 2011-05-11 17:00 UTC (permalink / raw)
To: Sascha Silbe
Cc: linux-wireless, devel, Dan Williams, John W. Linville,
libertas-dev, netdev, linux-kernel
In-Reply-To: <1305118354-17337-1-git-send-email-silbe@activitycentral.com>
On Wed, 11 May 2011 14:52:34 +0200 Sascha Silbe wrote:
> This allows individual users and deployments to disable mesh support at
> runtime, i.e. without having to build and maintain a custom kernel.
I guess a user could want to do this on a per-driver basis, but ISTM that
it would be better to be something like a sysctl that applies to all (wireless)
drivers.
Do other wireless drivers have something like this?
> Based on a patch by Paul Fox <pgf@laptop.org>.
> Signed-off-by: Sascha Silbe <silbe@activitycentral.com>
> ---
> drivers/net/wireless/libertas/main.c | 9 ++++++++-
> 1 files changed, 8 insertions(+), 1 deletions(-)
>
> The patch is based on the OLPC 2.6.35 kernel tree, but applies cleanly to
> wireless-next.
>
> diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
> index 8445473..62069e2 100644
> --- a/drivers/net/wireless/libertas/main.c
> +++ b/drivers/net/wireless/libertas/main.c
> @@ -41,6 +41,10 @@ unsigned int lbs_debug;
> EXPORT_SYMBOL_GPL(lbs_debug);
> module_param_named(libertas_debug, lbs_debug, int, 0644);
>
> +unsigned int lbs_disablemesh;
> +EXPORT_SYMBOL_GPL(lbs_disablemesh);
> +module_param_named(libertas_disablemesh, lbs_disablemesh, int, 0644);
> +
>
> /* This global structure is used to send the confirm_sleep command as
> * fast as possible down to the firmware. */
> @@ -1086,7 +1090,10 @@ int lbs_start_card(struct lbs_private *priv)
>
> lbs_update_channel(priv);
>
> - lbs_init_mesh(priv);
> + if (!lbs_disablemesh)
> + lbs_init_mesh(priv);
> + else
> + lbs_pr_info("%s: mesh disabled\n", dev->name);
>
> /*
> * While rtap isn't related to mesh, only mesh-enabled
> --
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
^ permalink raw reply
* Re: [PATCH 0/2] wireless: Make and use const struct ieee80211_channel
From: John W. Linville @ 2011-05-11 16:57 UTC (permalink / raw)
To: Joe Perches
Cc: libertas-dev, linux-wireless, orinoco-users, orinoco-devel,
netdev, LKML
In-Reply-To: <1304698221.11874.6.camel@Joe-Laptop>
On Fri, May 06, 2011 at 09:10:21AM -0700, Joe Perches wrote:
> On Fri, 2011-05-06 at 09:19 -0400, John W. Linville wrote:
> > On Thu, May 05, 2011 at 03:21:47PM -0700, Joe Perches wrote:
> > > On Thu, 2011-05-05 at 14:49 -0400, John W. Linville wrote:
> > > > These patches generated a lot of warnings in net/mac80211. Did you
> > > > actually build them?
> > > Yes.
> > > Did you apply patch 1/2 first?
> > > It's a dependent patch.
> > That's the one that cause most of the warnings...
>
> Consider the 2 patches as a single patch.
> Do you have new build warnings after applying both
> patches 1 and 2?
Yes, of course.
CC [M] net/mac80211/scan.o
net/mac80211/scan.c: In function ‘ieee80211_scan_state_decision’:
net/mac80211/scan.c:509:12: warning: assignment discards qualifiers from pointer target type
net/mac80211/scan.c: In function ‘ieee80211_scan_state_set_channel’:
net/mac80211/scan.c:610:7: warning: assignment discards qualifiers from pointer target type
CC [M] net/mac80211/offchannel.o
CC [M] net/mac80211/ht.o
CC [M] net/mac80211/agg-tx.o
CC [M] net/mac80211/agg-rx.o
CC [M] net/mac80211/ibss.o
net/mac80211/ibss.c: In function ‘ieee80211_sta_join_ibss’:
net/mac80211/ibss.c:250:7: warning: passing argument 4 of ‘__ieee80211_sta_join_ibss’ discards qualifiers from pointer target type
net/mac80211/ibss.c:64:13: note: expected ‘struct ieee80211_channel *’ but argument is of type ‘const struct ieee80211_channel *’
net/mac80211/ibss.c: In function ‘ieee80211_ibss_join’:
net/mac80211/ibss.c:918:24: warning: assignment discards qualifiers from pointer target type
net/mac80211/ibss.c:923:30: warning: assignment discards qualifiers from pointer target type
CC [M] net/mac80211/mlme.o
net/mac80211/mlme.c: In function ‘ieee80211_mgd_auth’:
net/mac80211/mlme.c:2350:11: warning: assignment discards qualifiers from pointer target type
net/mac80211/mlme.c: In function ‘ieee80211_mgd_assoc’:
net/mac80211/mlme.c:2500:11: warning: assignment discards qualifiers from pointer target type
CC [M] net/mac80211/work.o
CC [M] net/mac80211/iface.o
CC [M] net/mac80211/rate.o
CC [M] net/mac80211/tkip.o
CC [M] net/mac80211/aes_ccm.o
CC [M] net/mac80211/aes_cmac.o
CC [M] net/mac80211/cfg.o
net/mac80211/cfg.c:2083:2: warning: initialization from incompatible pointer type
net/mac80211/cfg.c:2101:2: warning: initialization from incompatible pointer type
net/mac80211/cfg.c:2103:2: warning: initialization from incompatible pointer type
CC [M] net/mac80211/rx.o
commit 07daa458f14226deff1e464f594a44111168e7ee
Author: Joe Perches <joe@perches.com>
Date: Thu Apr 28 22:25:08 2011 -0700
wireless: Use const struct ieee80211_channel where possible
Make some structure uses const.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
commit 5c9adfae8855fc744f77b24df322060a7117c521
Author: Joe Perches <joe@perches.com>
Date: Thu Apr 28 22:25:07 2011 -0700
wireless: Make struct ieee80211_channel const where possible
Useful for declarations of static const.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
<commits were temporary, not applied now>
I'm dropping these patches -- feel free to repost if/when the warnings
disappear.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: [PATCH net-next 2/2 V3] net: driver: use NETIF_F_GSO_SOFTWARE masks directly
From: Michał Mirosław @ 2011-05-11 10:07 UTC (permalink / raw)
To: Shan Wei
Cc: David Miller, netdev, rusty, Michael S. Tsirkin, Eric Dumazet,
krkumar2, Ben Hutchings
In-Reply-To: <4DCA2BEB.4000308@cn.fujitsu.com>
2011/5/11 Shan Wei <shanwei@cn.fujitsu.com>:
> For loopback device can support any offload, so directly using
> NETIF_F_GSO_SOFTWARE offload mask is enough safe.
> And as Michał Mirosław suggested, add NETIF_F_HIGHDMA to hw_features.
>
>
> For virtio_net driver, safely using NETIF_F_GSO_SOFTWARE offload mask for bit operation.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
> ---
> drivers/net/loopback.c | 16 +++++-----------
> drivers/net/virtio_net.c | 3 ++-
> 2 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/loopback.c b/drivers/net/loopback.c
> index 4ce9e5f..e6cccec 100644
> --- a/drivers/net/loopback.c
> +++ b/drivers/net/loopback.c
> @@ -165,17 +165,11 @@ static void loopback_setup(struct net_device *dev)
> dev->type = ARPHRD_LOOPBACK; /* 0x0001*/
> dev->flags = IFF_LOOPBACK;
> dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
> - dev->hw_features = NETIF_F_ALL_TSO | NETIF_F_UFO;
> - dev->features = NETIF_F_SG | NETIF_F_FRAGLIST
> - | NETIF_F_ALL_TSO
> - | NETIF_F_UFO
> - | NETIF_F_NO_CSUM
> - | NETIF_F_RXCSUM
> - | NETIF_F_HIGHDMA
> - | NETIF_F_LLTX
> - | NETIF_F_NETNS_LOCAL
> - | NETIF_F_VLAN_CHALLENGED
> - | NETIF_F_LOOPBACK;
> + dev->hw_features = NETIF_F_GSO_SOFTWARE | NETIF_F_HIGHDMA;
> + dev->features = dev->hw_features | NETIF_F_SG
> + | NETIF_F_FRAGLIST | NETIF_F_NO_CSUM | NETIF_F_RXCSUM
> + | NETIF_F_LLTX | NETIF_F_NETNS_LOCAL
> + | NETIF_F_VLAN_CHALLENGED | NETIF_F_LOOPBACK;
> dev->ethtool_ops = &loopback_ethtool_ops;
> dev->header_ops = ð_header_ops;
> dev->netdev_ops = &loopback_ops;
[...]
Looks ok. For loopback, more features are actually changeable - only
last 4 are really forced here.
Best Regards,
Michał Mirosław
^ permalink raw reply
* Re: [PATCH net-next 1/2 RESEND v3] net: use NETIF_F_ALL_TSO for vlan features
From: Dimitris Michailidis @ 2011-05-11 16:35 UTC (permalink / raw)
To: Shan Wei; +Cc: David Miller, netdev, eilong, leedom
In-Reply-To: <4DCA2B86.9030205@cn.fujitsu.com>
On 05/10/2011 11:24 PM, Shan Wei wrote:
> As Dimitris Michailidis suggested, use NETIF_F_ALL_TSO for vlan_features,
> which is a mask, but not hw_features.
>
> Signed-off-by: Shan Wei <shanwei@cn.fujitsu.com>
While these changes aren't wrong I don't see a good reason to make them. I am
also curious why you're changing only these three drivers.
> ---
> drivers/net/bnx2x/bnx2x_main.c | 2 +-
> drivers/net/cxgb4/cxgb4_main.c | 2 +-
> drivers/net/cxgb4vf/cxgb4vf_main.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/bnx2x/bnx2x_main.c b/drivers/net/bnx2x/bnx2x_main.c
> index 2762edf..172684b 100644
> --- a/drivers/net/bnx2x/bnx2x_main.c
> +++ b/drivers/net/bnx2x/bnx2x_main.c
> @@ -9267,7 +9267,7 @@ static int __devinit bnx2x_init_dev(struct pci_dev *pdev,
> NETIF_F_RXCSUM | NETIF_F_LRO | NETIF_F_HW_VLAN_TX;
>
> dev->vlan_features = NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> - NETIF_F_TSO | NETIF_F_TSO_ECN | NETIF_F_TSO6 | NETIF_F_HIGHDMA;
> + NETIF_F_ALL_TSO | NETIF_F_HIGHDMA;
>
> dev->features |= dev->hw_features | NETIF_F_HW_VLAN_RX;
> if (bp->flags & USING_DAC_FLAG)
> diff --git a/drivers/net/cxgb4/cxgb4_main.c b/drivers/net/cxgb4/cxgb4_main.c
> index 7e3cfbe..21a163c 100644
> --- a/drivers/net/cxgb4/cxgb4_main.c
> +++ b/drivers/net/cxgb4/cxgb4_main.c
> @@ -3528,7 +3528,7 @@ static void free_some_resources(struct adapter *adapter)
> }
>
> #define TSO_FLAGS (NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_TSO_ECN)
> -#define VLAN_FEAT (NETIF_F_SG | NETIF_F_IP_CSUM | TSO_FLAGS | \
> +#define VLAN_FEAT (NETIF_F_SG | NETIF_F_IP_CSUM | NETIF_F_ALL_TSO | \
> NETIF_F_IPV6_CSUM | NETIF_F_HIGHDMA)
>
> static int __devinit init_one(struct pci_dev *pdev,
> diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
> index e71c08e..b55c521 100644
> --- a/drivers/net/cxgb4vf/cxgb4vf_main.c
> +++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
> @@ -2604,7 +2604,7 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
> netdev->hw_features = NETIF_F_SG | TSO_FLAGS |
> NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> NETIF_F_HW_VLAN_TX | NETIF_F_RXCSUM;
> - netdev->vlan_features = NETIF_F_SG | TSO_FLAGS |
> + netdev->vlan_features = NETIF_F_SG | NETIF_F_ALL_TSO |
> NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> NETIF_F_HIGHDMA;
> netdev->features = netdev->hw_features |
^ permalink raw reply
* Re: [PATCH] ehea: Fix memory hotplug oops
From: Breno Leitao @ 2011-05-11 12:46 UTC (permalink / raw)
To: David Miller; +Cc: Anton Blanchard, netdev
In-Reply-To: <20110511121710.05ab8c2e@kryten>
On 05/10/2011 11:17 PM, Anton Blanchard wrote:
>
> The ehea driver oopses during memory hotplug if the ports are not
> up. A simple testcase:
>
> # ifconfig ethX down
> # echo offline > /sys/devices/system/memory/memory32/state
>
> Oops: Kernel access of bad area, sig: 11 [#1]
> last sysfs file: /sys/devices/system/memory/memory32/state
> REGS: c000000709393110 TRAP: 0300 Not tainted
(2.6.39-rc2-01385-g7ef73bc-dirty)
> DAR: 0000000000000000, DSISR: 40000000
> ...
> NIP [c000000000067c98] .__wake_up_common+0x48/0xf0
> LR [c00000000006d034] .__wake_up+0x54/0x90
> Call Trace:
> [c00000000006d034] .__wake_up+0x54/0x90
> [d000000006bb6270] .ehea_rereg_mrs+0x140/0x730 [ehea]
> [d000000006bb69c4] .ehea_mem_notifier+0x164/0x170 [ehea]
> [c0000000006fc8a8] .notifier_call_chain+0x78/0xf0
> [c0000000000b3d70] .__blocking_notifier_call_chain+0x70/0xb0
> [c000000000458d78] .memory_notify+0x28/0x40
> [c0000000001871d8] .remove_memory+0x208/0x6d0
> [c000000000458264] .memory_section_action+0x94/0x140
> [c0000000004583ec] .memory_block_change_state+0xdc/0x1d0
> [c0000000004585cc] .store_mem_state+0xec/0x160
> [c00000000044768c] .sysdev_store+0x3c/0x50
> [c00000000020b48c] .sysfs_write_file+0xec/0x1f0
> [c00000000018f86c] .vfs_write+0xec/0x1e0
> [c00000000018fa88] .SyS_write+0x58/0xd0
>
> To fix this, initialise the waitqueues during port probe instead
> of port open.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Breno Leitao <leitao@linux.vnet.ibm.com>
^ permalink raw reply
* Re: [PATCH] tcp_cubic: limit delayed_ack ratio to prevent divide error
From: TB @ 2011-05-11 15:35 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Brandeburg, Jesse, David Miller, Sangtae Ha, Injong Rhee,
Valdis.Kletnieks@vt.edu, rdunlap@xenotime.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20110511082238.1ef1c190@nehalam>
On 11-05-11 11:22 AM, Stephen Hemminger wrote:
> On Wed, 11 May 2011 10:49:01 -0400
> TB <lkml@techboom.com> wrote:
>
>> On 11-05-06 12:53 PM, Stephen Hemminger wrote:
>>> On Fri, 06 May 2011 12:15:46 -0400
>>> TB <lkml@techboom.com> wrote:
>>>
>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>> Hash: SHA1
>>>>
>>>> On 11-05-04 04:53 PM, Brandeburg, Jesse wrote:
>>>>>
>>>>>
>>>>> On Wed, 4 May 2011, Stephen Hemminger wrote:
>>>>>
>>>>>> TCP Cubic keeps a metric that estimates the amount of delayed
>>>>>> acknowledgements to use in adjusting the window. If an abnormally
>>>>>> large number of packets are acknowledged at once, then the update
>>>>>> could wrap and reach zero. This kind of ACK could only
>>>>>> happen when there was a large window and huge number of
>>>>>> ACK's were lost.
>>>>>>
>>>>>> This patch limits the value of delayed ack ratio. The choice of 32
>>>>>> is just a conservative value since normally it should be range of
>>>>>> 1 to 4 packets.
>>>>>>
>>>>>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
>>>>>
>>>>> patch seems fine, but please credit the reporter (lkml@techboom.com) with
>>>>> reporting the issue with logs, maybe even with Reported-by: and some kind
>>>>> of reference to the panic message or the email thread in the text or
>>>>> header?
>>>>
>>>> We're currently testing the patch on 6 production servers
>>>
>>> Thank you, is there some regularity to the failures previously?
>>
>> This is now being tested on about 50 servers and we just had another
>> panic, on a server with 2.6.38.5 and this patch.
>>
>> [405542.454073] ------------[ cut here ]------------
>> [405542.454109] kernel BUG at net/ipv4/tcp_output.c:1006!
>> [405542.454136] invalid opcode: 0000 [#1]
>>
>> [405542.454166] last sysfs file:
>> /sys/devices/pci0000:00/0000:00:1f.2/host6/scsi_host/host6/proc_name
>> [405542.454213] CPU 0
>>
>> [405542.454220] Modules linked in:
>> i2c_i801
>> evdev
>> i2c_core
>> button
>> [last unloaded: scsi_wait_scan]
>>
>> [405542.454300]
>> [405542.454320] Pid: 0, comm: swapper Not tainted 2.6.38.5 #8
>>
>> /
>>
>> [405542.454379] RIP: 0010:[<ffffffff814e7ed2>]
>> [<ffffffff814e7ed2>] tcp_fragment+0x22/0x29a
>> [405542.454433] RSP: 0018:ffff8800bf403a30 EFLAGS: 00010202
>> [405542.454460] RAX: ffff88000cd35000 RBX: ffff88006b84f480 RCX:
>> 0000000000000218
>> [405542.454504] RDX: 0000000000001708 RSI: ffff88006b84f480 RDI:
>> ffff880008d6b200
>> [405542.454548] RBP: 0000000000001540 R08: 0000000000000002 R09:
>> 000000001027984a
>> [405542.454592] R10: ffff8800b915f428 R11: ffff880008d6b200 R12:
>> ffff88006b84f4a8
>> [405542.454636] R13: 0000000000001708 R14: 0000000000000000 R15:
>> ffff880008d6b200
>> [405542.454680] FS: 0000000000000000(0000) GS:ffff8800bf400000(0000)
>> knlGS:0000000000000000
>> [405542.454726] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> [405542.454754] CR2: 00007f94055c7000 CR3: 000000083e0bd000 CR4:
>> 00000000000006f0
>> [405542.454798] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
>> 0000000000000000
>> [405542.454842] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
>> 0000000000000400
>> [405542.454886] Process swapper (pid: 0, threadinfo ffffffff8176c000,
>> task ffffffff81777020)
>> [405542.454931] Stack:
>> [405542.454951] 0000000000000000
>> 0000021808d6b798
>> 00000002000005b4
>> ffff88006b84f480
>>
>> [405542.455006] ffff880008d6b200
>> ffff88006b84f4a8
>> 0000000000000015
>> 0000000000000000
>>
>> [405542.455061] ffff880008d6b300
>> ffffffff814df7a4
>> ffff8802a3965140
>> 00000000000001a0
>>
>> [405542.455115] Call Trace:
>> [405542.455137] <IRQ>
>>
>> [405542.455162] [<ffffffff814df7a4>] ? tcp_mark_head_lost+0x13c/0x202
>> [405542.455192] [<ffffffff814e33a8>] ? tcp_ack+0xe98/0x1a89
>> [405542.455220] [<ffffffff814e42ca>] ? tcp_validate_incoming+0x69/0x290
>> [405542.455250] [<ffffffff814e4c9b>] ? tcp_rcv_established+0x7aa/0xa13
>> [405542.455281] [<ffffffff814ec60b>] ? tcp_v4_do_rcv+0x1b2/0x382
>> [405542.455310] [<ffffffff814c95d4>] ? nf_iterate+0x40/0x78
>> [405542.455338] [<ffffffff814ecc5f>] ? tcp_v4_rcv+0x484/0x797
>> [405542.455368] [<ffffffff814d11c7>] ? ip_local_deliver_finish+0xab/0x139
>> [405542.455398] [<ffffffff814ae2b3>] ? __netif_receive_skb+0x31c/0x349
>> [405542.455428] [<ffffffff814aec82>] ? netif_receive_skb+0x67/0x6d
>> [405542.455457] [<ffffffff814af1fb>] ? napi_gro_receive+0x9d/0xab
>> [405542.455485] [<ffffffff814aed57>] ? napi_skb_finish+0x1c/0x31
>> [405542.455516] [<ffffffff813e4248>] ? igb_poll+0x7d5/0xb2e
>> [405542.455544] [<ffffffff813e432f>] ? igb_poll+0x8bc/0xb2e
>> [405542.455572] [<ffffffff813e211a>] ? igb_msix_ring+0x6e/0x75
>> [405542.455602] [<ffffffff8106749c>] ? handle_IRQ_event+0x51/0x119
>> [405542.455631] [<ffffffff814af337>] ? net_rx_action+0xa7/0x212
>> [405542.455661] [<ffffffff8103b6c2>] ? __do_softirq+0xbe/0x184
>> [405542.455690] [<ffffffff8100364c>] ? call_softirq+0x1c/0x28
>> [405542.455719] [<ffffffff81005085>] ? do_softirq+0x31/0x63
>> [405542.455746] [<ffffffff8103b56c>] ? irq_exit+0x36/0x78
>> [405542.455773] [<ffffffff81004784>] ? do_IRQ+0x98/0xae
>> [405542.455802] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
>> [405542.455829] <EOI>
>>
>> [405542.455860] [<ffffffff81009a41>] ? mwait_idle+0xb9/0xf3
>> [405542.455888] [<ffffffff81001c6e>] ? cpu_idle+0x57/0x8d
>> [405542.455921] [<ffffffff81801c49>] ? start_kernel+0x34e/0x35a
>> [405542.455950] [<ffffffff81801398>] ? x86_64_start_kernel+0xf3/0xf9
>
> This panic is different than the last one.
> It is coming from TCP fragment code being
> called with an invalid skb. If I read the registers correctly,
> skb->len (R14) = 0 and len (EDX) = 1708; the check here is failing.
>
> int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
> unsigned int mss_now)
> {
>
> BUG_ON(len > skb->len);
>
>
> Are you running with large (or small) MTU? What netfilter rules, perhaps
> the firewall rule altered the packet.
MTU 1500, No firewall rules (empty rules for filter, no mangle, no nat
modules)
^ permalink raw reply
* Re: [PATCH] tcp_cubic: limit delayed_ack ratio to prevent divide error
From: Stephen Hemminger @ 2011-05-11 15:22 UTC (permalink / raw)
To: TB
Cc: Brandeburg, Jesse, David Miller, Sangtae Ha, Injong Rhee,
Valdis.Kletnieks@vt.edu, rdunlap@xenotime.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <4DCAA1DD.6010609@techboom.com>
On Wed, 11 May 2011 10:49:01 -0400
TB <lkml@techboom.com> wrote:
> On 11-05-06 12:53 PM, Stephen Hemminger wrote:
> > On Fri, 06 May 2011 12:15:46 -0400
> > TB <lkml@techboom.com> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE-----
> >> Hash: SHA1
> >>
> >> On 11-05-04 04:53 PM, Brandeburg, Jesse wrote:
> >>>
> >>>
> >>> On Wed, 4 May 2011, Stephen Hemminger wrote:
> >>>
> >>>> TCP Cubic keeps a metric that estimates the amount of delayed
> >>>> acknowledgements to use in adjusting the window. If an abnormally
> >>>> large number of packets are acknowledged at once, then the update
> >>>> could wrap and reach zero. This kind of ACK could only
> >>>> happen when there was a large window and huge number of
> >>>> ACK's were lost.
> >>>>
> >>>> This patch limits the value of delayed ack ratio. The choice of 32
> >>>> is just a conservative value since normally it should be range of
> >>>> 1 to 4 packets.
> >>>>
> >>>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
> >>>
> >>> patch seems fine, but please credit the reporter (lkml@techboom.com) with
> >>> reporting the issue with logs, maybe even with Reported-by: and some kind
> >>> of reference to the panic message or the email thread in the text or
> >>> header?
> >>
> >> We're currently testing the patch on 6 production servers
> >
> > Thank you, is there some regularity to the failures previously?
>
> This is now being tested on about 50 servers and we just had another
> panic, on a server with 2.6.38.5 and this patch.
>
> [405542.454073] ------------[ cut here ]------------
> [405542.454109] kernel BUG at net/ipv4/tcp_output.c:1006!
> [405542.454136] invalid opcode: 0000 [#1]
>
> [405542.454166] last sysfs file:
> /sys/devices/pci0000:00/0000:00:1f.2/host6/scsi_host/host6/proc_name
> [405542.454213] CPU 0
>
> [405542.454220] Modules linked in:
> i2c_i801
> evdev
> i2c_core
> button
> [last unloaded: scsi_wait_scan]
>
> [405542.454300]
> [405542.454320] Pid: 0, comm: swapper Not tainted 2.6.38.5 #8
>
> /
>
> [405542.454379] RIP: 0010:[<ffffffff814e7ed2>]
> [<ffffffff814e7ed2>] tcp_fragment+0x22/0x29a
> [405542.454433] RSP: 0018:ffff8800bf403a30 EFLAGS: 00010202
> [405542.454460] RAX: ffff88000cd35000 RBX: ffff88006b84f480 RCX:
> 0000000000000218
> [405542.454504] RDX: 0000000000001708 RSI: ffff88006b84f480 RDI:
> ffff880008d6b200
> [405542.454548] RBP: 0000000000001540 R08: 0000000000000002 R09:
> 000000001027984a
> [405542.454592] R10: ffff8800b915f428 R11: ffff880008d6b200 R12:
> ffff88006b84f4a8
> [405542.454636] R13: 0000000000001708 R14: 0000000000000000 R15:
> ffff880008d6b200
> [405542.454680] FS: 0000000000000000(0000) GS:ffff8800bf400000(0000)
> knlGS:0000000000000000
> [405542.454726] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> [405542.454754] CR2: 00007f94055c7000 CR3: 000000083e0bd000 CR4:
> 00000000000006f0
> [405542.454798] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [405542.454842] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
> 0000000000000400
> [405542.454886] Process swapper (pid: 0, threadinfo ffffffff8176c000,
> task ffffffff81777020)
> [405542.454931] Stack:
> [405542.454951] 0000000000000000
> 0000021808d6b798
> 00000002000005b4
> ffff88006b84f480
>
> [405542.455006] ffff880008d6b200
> ffff88006b84f4a8
> 0000000000000015
> 0000000000000000
>
> [405542.455061] ffff880008d6b300
> ffffffff814df7a4
> ffff8802a3965140
> 00000000000001a0
>
> [405542.455115] Call Trace:
> [405542.455137] <IRQ>
>
> [405542.455162] [<ffffffff814df7a4>] ? tcp_mark_head_lost+0x13c/0x202
> [405542.455192] [<ffffffff814e33a8>] ? tcp_ack+0xe98/0x1a89
> [405542.455220] [<ffffffff814e42ca>] ? tcp_validate_incoming+0x69/0x290
> [405542.455250] [<ffffffff814e4c9b>] ? tcp_rcv_established+0x7aa/0xa13
> [405542.455281] [<ffffffff814ec60b>] ? tcp_v4_do_rcv+0x1b2/0x382
> [405542.455310] [<ffffffff814c95d4>] ? nf_iterate+0x40/0x78
> [405542.455338] [<ffffffff814ecc5f>] ? tcp_v4_rcv+0x484/0x797
> [405542.455368] [<ffffffff814d11c7>] ? ip_local_deliver_finish+0xab/0x139
> [405542.455398] [<ffffffff814ae2b3>] ? __netif_receive_skb+0x31c/0x349
> [405542.455428] [<ffffffff814aec82>] ? netif_receive_skb+0x67/0x6d
> [405542.455457] [<ffffffff814af1fb>] ? napi_gro_receive+0x9d/0xab
> [405542.455485] [<ffffffff814aed57>] ? napi_skb_finish+0x1c/0x31
> [405542.455516] [<ffffffff813e4248>] ? igb_poll+0x7d5/0xb2e
> [405542.455544] [<ffffffff813e432f>] ? igb_poll+0x8bc/0xb2e
> [405542.455572] [<ffffffff813e211a>] ? igb_msix_ring+0x6e/0x75
> [405542.455602] [<ffffffff8106749c>] ? handle_IRQ_event+0x51/0x119
> [405542.455631] [<ffffffff814af337>] ? net_rx_action+0xa7/0x212
> [405542.455661] [<ffffffff8103b6c2>] ? __do_softirq+0xbe/0x184
> [405542.455690] [<ffffffff8100364c>] ? call_softirq+0x1c/0x28
> [405542.455719] [<ffffffff81005085>] ? do_softirq+0x31/0x63
> [405542.455746] [<ffffffff8103b56c>] ? irq_exit+0x36/0x78
> [405542.455773] [<ffffffff81004784>] ? do_IRQ+0x98/0xae
> [405542.455802] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
> [405542.455829] <EOI>
>
> [405542.455860] [<ffffffff81009a41>] ? mwait_idle+0xb9/0xf3
> [405542.455888] [<ffffffff81001c6e>] ? cpu_idle+0x57/0x8d
> [405542.455921] [<ffffffff81801c49>] ? start_kernel+0x34e/0x35a
> [405542.455950] [<ffffffff81801398>] ? x86_64_start_kernel+0xf3/0xf9
This panic is different than the last one.
It is coming from TCP fragment code being
called with an invalid skb. If I read the registers correctly,
skb->len (R14) = 0 and len (EDX) = 1708; the check here is failing.
int tcp_fragment(struct sock *sk, struct sk_buff *skb, u32 len,
unsigned int mss_now)
{
BUG_ON(len > skb->len);
Are you running with large (or small) MTU? What netfilter rules, perhaps
the firewall rule altered the packet.
--
^ permalink raw reply
* Re: [PATCH] tcp_cubic: limit delayed_ack ratio to prevent divide error
From: TB @ 2011-05-11 14:49 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Brandeburg, Jesse, David Miller, Sangtae Ha, Injong Rhee,
Valdis.Kletnieks@vt.edu, rdunlap@xenotime.net,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20110506095359.57c4fb38@nehalam>
On 11-05-06 12:53 PM, Stephen Hemminger wrote:
> On Fri, 06 May 2011 12:15:46 -0400
> TB <lkml@techboom.com> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 11-05-04 04:53 PM, Brandeburg, Jesse wrote:
>>>
>>>
>>> On Wed, 4 May 2011, Stephen Hemminger wrote:
>>>
>>>> TCP Cubic keeps a metric that estimates the amount of delayed
>>>> acknowledgements to use in adjusting the window. If an abnormally
>>>> large number of packets are acknowledged at once, then the update
>>>> could wrap and reach zero. This kind of ACK could only
>>>> happen when there was a large window and huge number of
>>>> ACK's were lost.
>>>>
>>>> This patch limits the value of delayed ack ratio. The choice of 32
>>>> is just a conservative value since normally it should be range of
>>>> 1 to 4 packets.
>>>>
>>>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>>
>>> patch seems fine, but please credit the reporter (lkml@techboom.com) with
>>> reporting the issue with logs, maybe even with Reported-by: and some kind
>>> of reference to the panic message or the email thread in the text or
>>> header?
>>
>> We're currently testing the patch on 6 production servers
>
> Thank you, is there some regularity to the failures previously?
This is now being tested on about 50 servers and we just had another
panic, on a server with 2.6.38.5 and this patch.
[405542.454073] ------------[ cut here ]------------
[405542.454109] kernel BUG at net/ipv4/tcp_output.c:1006!
[405542.454136] invalid opcode: 0000 [#1]
[405542.454166] last sysfs file:
/sys/devices/pci0000:00/0000:00:1f.2/host6/scsi_host/host6/proc_name
[405542.454213] CPU 0
[405542.454220] Modules linked in:
i2c_i801
evdev
i2c_core
button
[last unloaded: scsi_wait_scan]
[405542.454300]
[405542.454320] Pid: 0, comm: swapper Not tainted 2.6.38.5 #8
/
[405542.454379] RIP: 0010:[<ffffffff814e7ed2>]
[<ffffffff814e7ed2>] tcp_fragment+0x22/0x29a
[405542.454433] RSP: 0018:ffff8800bf403a30 EFLAGS: 00010202
[405542.454460] RAX: ffff88000cd35000 RBX: ffff88006b84f480 RCX:
0000000000000218
[405542.454504] RDX: 0000000000001708 RSI: ffff88006b84f480 RDI:
ffff880008d6b200
[405542.454548] RBP: 0000000000001540 R08: 0000000000000002 R09:
000000001027984a
[405542.454592] R10: ffff8800b915f428 R11: ffff880008d6b200 R12:
ffff88006b84f4a8
[405542.454636] R13: 0000000000001708 R14: 0000000000000000 R15:
ffff880008d6b200
[405542.454680] FS: 0000000000000000(0000) GS:ffff8800bf400000(0000)
knlGS:0000000000000000
[405542.454726] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[405542.454754] CR2: 00007f94055c7000 CR3: 000000083e0bd000 CR4:
00000000000006f0
[405542.454798] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[405542.454842] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[405542.454886] Process swapper (pid: 0, threadinfo ffffffff8176c000,
task ffffffff81777020)
[405542.454931] Stack:
[405542.454951] 0000000000000000
0000021808d6b798
00000002000005b4
ffff88006b84f480
[405542.455006] ffff880008d6b200
ffff88006b84f4a8
0000000000000015
0000000000000000
[405542.455061] ffff880008d6b300
ffffffff814df7a4
ffff8802a3965140
00000000000001a0
[405542.455115] Call Trace:
[405542.455137] <IRQ>
[405542.455162] [<ffffffff814df7a4>] ? tcp_mark_head_lost+0x13c/0x202
[405542.455192] [<ffffffff814e33a8>] ? tcp_ack+0xe98/0x1a89
[405542.455220] [<ffffffff814e42ca>] ? tcp_validate_incoming+0x69/0x290
[405542.455250] [<ffffffff814e4c9b>] ? tcp_rcv_established+0x7aa/0xa13
[405542.455281] [<ffffffff814ec60b>] ? tcp_v4_do_rcv+0x1b2/0x382
[405542.455310] [<ffffffff814c95d4>] ? nf_iterate+0x40/0x78
[405542.455338] [<ffffffff814ecc5f>] ? tcp_v4_rcv+0x484/0x797
[405542.455368] [<ffffffff814d11c7>] ? ip_local_deliver_finish+0xab/0x139
[405542.455398] [<ffffffff814ae2b3>] ? __netif_receive_skb+0x31c/0x349
[405542.455428] [<ffffffff814aec82>] ? netif_receive_skb+0x67/0x6d
[405542.455457] [<ffffffff814af1fb>] ? napi_gro_receive+0x9d/0xab
[405542.455485] [<ffffffff814aed57>] ? napi_skb_finish+0x1c/0x31
[405542.455516] [<ffffffff813e4248>] ? igb_poll+0x7d5/0xb2e
[405542.455544] [<ffffffff813e432f>] ? igb_poll+0x8bc/0xb2e
[405542.455572] [<ffffffff813e211a>] ? igb_msix_ring+0x6e/0x75
[405542.455602] [<ffffffff8106749c>] ? handle_IRQ_event+0x51/0x119
[405542.455631] [<ffffffff814af337>] ? net_rx_action+0xa7/0x212
[405542.455661] [<ffffffff8103b6c2>] ? __do_softirq+0xbe/0x184
[405542.455690] [<ffffffff8100364c>] ? call_softirq+0x1c/0x28
[405542.455719] [<ffffffff81005085>] ? do_softirq+0x31/0x63
[405542.455746] [<ffffffff8103b56c>] ? irq_exit+0x36/0x78
[405542.455773] [<ffffffff81004784>] ? do_IRQ+0x98/0xae
[405542.455802] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
[405542.455829] <EOI>
[405542.455860] [<ffffffff81009a41>] ? mwait_idle+0xb9/0xf3
[405542.455888] [<ffffffff81001c6e>] ? cpu_idle+0x57/0x8d
[405542.455921] [<ffffffff81801c49>] ? start_kernel+0x34e/0x35a
[405542.455950] [<ffffffff81801398>] ? x86_64_start_kernel+0xf3/0xf9
[405542.455977] Code:
f>
[405542.456239] RIP
[<ffffffff814e7ed2>] tcp_fragment+0x22/0x29a
[405542.456270] RSP <ffff8800bf403a30>
[405542.456543] ---[ end trace 231aaa222f893065 ]---
[405542.456600] Kernel panic - not syncing: Fatal exception in interrupt
[405542.456659] Pid: 0, comm: swapper Tainted: G D 2.6.38.5 #8
[405542.456719] Call Trace:
[405542.456770] <IRQ>
[<ffffffff81560960>] ? panic+0x9d/0x1a0
[405542.456863] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
[405542.456923] [<ffffffff810365bb>] ? kmsg_dump+0x46/0xec
[405542.456981] [<ffffffff81006176>] ? oops_end+0x9f/0xac
[405542.457039] [<ffffffff81003f83>] ? do_invalid_op+0x85/0x8f
[405542.457097] [<ffffffff814e7ed2>] ? tcp_fragment+0x22/0x29a
[405542.457156] [<ffffffff814e80a9>] ? tcp_fragment+0x1f9/0x29a
[405542.457216] [<ffffffff810033d5>] ? invalid_op+0x15/0x20
[405542.457276] [<ffffffff814e7ed2>] ? tcp_fragment+0x22/0x29a
[405542.457337] [<ffffffff814df7a4>] ? tcp_mark_head_lost+0x13c/0x202
[405542.457400] [<ffffffff814e33a8>] ? tcp_ack+0xe98/0x1a89
[405542.457461] [<ffffffff814e42ca>] ? tcp_validate_incoming+0x69/0x290
[405542.457524] [<ffffffff814e4c9b>] ? tcp_rcv_established+0x7aa/0xa13
[405542.457586] [<ffffffff814ec60b>] ? tcp_v4_do_rcv+0x1b2/0x382
[405542.457645] [<ffffffff814c95d4>] ? nf_iterate+0x40/0x78
[405542.457703] [<ffffffff814ecc5f>] ? tcp_v4_rcv+0x484/0x797
[405542.457761] [<ffffffff814d11c7>] ? ip_local_deliver_finish+0xab/0x139
[405542.457827] [<ffffffff814ae2b3>] ? __netif_receive_skb+0x31c/0x349
[405542.457894] [<ffffffff814aec82>] ? netif_receive_skb+0x67/0x6d
[405542.457953] [<ffffffff814af1fb>] ? napi_gro_receive+0x9d/0xab
[405542.458021] [<ffffffff814aed57>] ? napi_skb_finish+0x1c/0x31
[405542.458080] [<ffffffff813e4248>] ? igb_poll+0x7d5/0xb2e
[405542.458138] [<ffffffff813e432f>] ? igb_poll+0x8bc/0xb2e
[405542.458196] [<ffffffff813e211a>] ? igb_msix_ring+0x6e/0x75
[405542.458254] [<ffffffff8106749c>] ? handle_IRQ_event+0x51/0x119
[405542.458313] [<ffffffff814af337>] ? net_rx_action+0xa7/0x212
[405542.458371] [<ffffffff8103b6c2>] ? __do_softirq+0xbe/0x184
[405542.458430] [<ffffffff8100364c>] ? call_softirq+0x1c/0x28
[405542.458488] [<ffffffff81005085>] ? do_softirq+0x31/0x63
[405542.458545] [<ffffffff8103b56c>] ? irq_exit+0x36/0x78
[405542.458602] [<ffffffff81004784>] ? do_IRQ+0x98/0xae
[405542.458660] [<ffffffff81562ed3>] ? ret_from_intr+0x0/0xe
[405542.458717] <EOI>
[<ffffffff81009a41>] ? mwait_idle+0xb9/0xf3
[405542.458810] [<ffffffff81001c6e>] ? cpu_idle+0x57/0x8d
[405542.458867] [<ffffffff81801c49>] ? start_kernel+0x34e/0x35a
[405542.458926] [<ffffffff81801398>] ? x86_64_start_kernel+0xf3/0xf9
^ 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