* [PATCH] net: WIZnet drivers: fix possible NULL dereference
From: Mike Sinkovsky @ 2012-04-11 5:53 UTC (permalink / raw)
To: netdev, dan.carpenter, davem; +Cc: Mike Sinkovsky
In-Reply-To: <20120410084006.GA27006@elgon.mountain>
This fixes possible null dereference in probe() function: when both
.mac_addr and .link_gpio are unknown, dev.platform_data may be NULL
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Mike Sinkovsky <msink@permonline.ru>
---
drivers/net/ethernet/wiznet/w5100.c | 2 +-
drivers/net/ethernet/wiznet/w5300.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/wiznet/w5100.c b/drivers/net/ethernet/wiznet/w5100.c
index c28e1d5..157d2f0 100644
--- a/drivers/net/ethernet/wiznet/w5100.c
+++ b/drivers/net/ethernet/wiznet/w5100.c
@@ -682,7 +682,7 @@ static int __devinit w5100_hw_probe(struct platform_device *pdev)
return ret;
priv->irq = irq;
- priv->link_gpio = data->link_gpio;
+ priv->link_gpio = data ? data->link_gpio : -EINVAL;
if (gpio_is_valid(priv->link_gpio)) {
char *link_name = devm_kzalloc(&pdev->dev, 16, GFP_KERNEL);
if (!link_name)
diff --git a/drivers/net/ethernet/wiznet/w5300.c b/drivers/net/ethernet/wiznet/w5300.c
index 88afde9..86d07bb 100644
--- a/drivers/net/ethernet/wiznet/w5300.c
+++ b/drivers/net/ethernet/wiznet/w5300.c
@@ -596,7 +596,7 @@ static int __devinit w5300_hw_probe(struct platform_device *pdev)
return ret;
priv->irq = irq;
- priv->link_gpio = data->link_gpio;
+ priv->link_gpio = data ? data->link_gpio : -EINVAL;
if (gpio_is_valid(priv->link_gpio)) {
char *link_name = devm_kzalloc(&pdev->dev, 16, GFP_KERNEL);
if (!link_name)
--
1.6.3.3
^ permalink raw reply related
* Re: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: Eric Dumazet @ 2012-04-11 5:43 UTC (permalink / raw)
To: Marc MERLIN
Cc: David Miller, Larry.Finger-tQ5ms3gMjBLk1uMJSBkQmQ,
bhutchings-s/n/eUQHGBpZroRs9YW3xA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120411052733.GA17352-xnduUnryOU1AfugRpC6u6w@public.gmane.org>
On Tue, 2012-04-10 at 22:27 -0700, Marc MERLIN wrote:
> On Tue, Apr 10, 2012 at 08:11:03AM +0200, Eric Dumazet wrote:
> > Please try following patch, as it solved the problem for me (no more
> > order-1 allocations in tx path)
>
> I applied our patch to 3.3.1 and cannot reproduce the problem anymore.
>
> I'll leave a big wireless copy running overnight just in case, but I think
> you fixed it.
>
> Thanks much,
> Marc
Thanks Marc for bringing this issue.
I have a lenovo T420s laptop and could debug the thing pretty fast.
I'll send two official patches.
--
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: 3.2.8/amd64 full interrupt hangs and deadlocks under big network copies (page allocation failure)
From: Marc MERLIN @ 2012-04-11 5:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Larry.Finger, bhutchings, linux-wireless, netdev
In-Reply-To: <1334038263.2907.1.camel@edumazet-glaptop>
On Tue, Apr 10, 2012 at 08:11:03AM +0200, Eric Dumazet wrote:
> Please try following patch, as it solved the problem for me (no more
> order-1 allocations in tx path)
I applied our patch to 3.3.1 and cannot reproduce the problem anymore.
I'll leave a big wireless copy running overnight just in case, but I think
you fixed it.
Thanks much,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
^ permalink raw reply
* [PATCH net-next] rtnetlink & bonding: change args got get_tx_queues
From: Stephen Hemminger @ 2012-04-11 4:34 UTC (permalink / raw)
To: Ben Hutchings, Jay Vosburgh, Andy Gospodarek; +Cc: David Miller, netdev
In-Reply-To: <1334009344.7150.268.camel@deadeye>
Change get_tx_queues, drop unsused arg/return value real_tx_queues,
and use return by value (with error) rather than call by reference.
Probably bonding should just change to LLTX and the whole get_tx_queues
API could disappear!
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/bonding/bond_main.c | 7 ++-----
include/net/rtnetlink.h | 5 ++---
net/core/rtnetlink.c | 8 ++++----
3 files changed, 8 insertions(+), 12 deletions(-)
--- a/drivers/net/bonding/bond_main.c 2012-04-09 11:18:09.109148332 -0700
+++ b/drivers/net/bonding/bond_main.c 2012-04-10 21:23:07.380267810 -0700
@@ -4779,12 +4779,9 @@ static int bond_validate(struct nlattr *
return 0;
}
-static int bond_get_tx_queues(struct net *net, struct nlattr *tb[],
- unsigned int *num_queues,
- unsigned int *real_num_queues)
+static int bond_get_tx_queues(struct net *net, const struct nlattr *tb[])
{
- *num_queues = tx_queues;
- return 0;
+ return tx_queues;
}
static struct rtnl_link_ops bond_link_ops __read_mostly = {
--- a/include/net/rtnetlink.h 2012-04-10 21:19:01.369508395 -0700
+++ b/include/net/rtnetlink.h 2012-04-10 21:24:57.897506149 -0700
@@ -77,9 +77,8 @@ struct rtnl_link_ops {
size_t (*get_xstats_size)(const struct net_device *dev);
int (*fill_xstats)(struct sk_buff *skb,
const struct net_device *dev);
- int (*get_tx_queues)(struct net *net, struct nlattr *tb[],
- unsigned int *tx_queues,
- unsigned int *real_tx_queues);
+ int (*get_tx_queues)(struct net *net,
+ const struct nlattr *tb[]);
};
extern int __rtnl_link_register(struct rtnl_link_ops *ops);
--- a/net/core/rtnetlink.c 2012-04-09 11:18:09.673154299 -0700
+++ b/net/core/rtnetlink.c 2012-04-10 21:20:42.002637653 -0700
@@ -1641,14 +1641,14 @@ struct net_device *rtnl_create_link(stru
int err;
struct net_device *dev;
unsigned int num_queues = 1;
- unsigned int real_num_queues = 1;
if (ops->get_tx_queues) {
- err = ops->get_tx_queues(src_net, tb, &num_queues,
- &real_num_queues);
- if (err)
+ err = ops->get_tx_queues(src_net, tb);
+ if (err < 0)
goto err;
+ num_queues = err;
}
+
err = -ENOMEM;
dev = alloc_netdev_mq(ops->priv_size, ifname, ops->setup, num_queues);
if (!dev)
^ permalink raw reply
* [PATCH] rtnetlink: fix comments
From: Stephen Hemminger @ 2012-04-11 4:32 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev
In-Reply-To: <1334009344.7150.268.camel@deadeye>
Fix spelling and references in rtnetlink.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
v2 - fix bogus comment on get_link_af_size and add get_tx_queues
--- a/include/net/rtnetlink.h 2012-02-27 08:43:02.400935781 -0800
+++ b/include/net/rtnetlink.h 2012-04-10 21:19:01.369508395 -0700
@@ -41,9 +41,11 @@ static inline int rtnl_msg_family(const
* @get_size: Function to calculate required room for dumping device
* specific netlink attributes
* @fill_info: Function to dump device specific netlink attributes
- * @get_xstats_size: Function to calculate required room for dumping devic
+ * @get_xstats_size: Function to calculate required room for dumping device
* specific statistics
* @fill_xstats: Function to dump device specific statistics
+ * @get_tx_queues: Function to determine number of transmit queues to create when
+ * creating a new device.
*/
struct rtnl_link_ops {
struct list_head list;
@@ -94,7 +96,7 @@ extern void rtnl_link_unregister(struct
* @fill_link_af: Function to fill IFLA_AF_SPEC with address family
* specific netlink attributes.
* @get_link_af_size: Function to calculate size of address family specific
- * netlink attributes exlusive the container attribute.
+ * netlink attributes.
* @validate_link_af: Validate a IFLA_AF_SPEC attribute, must check attr
* for invalid configuration settings.
* @set_link_af: Function to parse a IFLA_AF_SPEC attribute and modify
^ permalink raw reply
* Re: [net-next PATCH v1 3/7] net: add fdb generic dump routine
From: Ben Hutchings @ 2012-04-11 3:45 UTC (permalink / raw)
To: John Fastabend
Cc: roprabhu, mst, stephen.hemminger, davem, hadi, jeffrey.t.kirsher,
netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <20120409220030.3288.31389.stgit@jf-dev1-dcblab>
On Mon, 2012-04-09 at 15:00 -0700, John Fastabend wrote:
> This adds a generic dump routine drivers can call. It
> should be sufficient to handle any bridging model that
> uses the unicast address list. This should be most SR-IOV
> enabled NICs.
[...]
> +static int nlmsg_populate_fdb(struct sk_buff *skb,
> + struct netlink_callback *cb,
> + struct net_device *dev,
> + int *idx,
> + struct netdev_hw_addr_list *list)
> +{
> + struct netdev_hw_addr *ha;
> + struct ndmsg *ndm;
> + struct nlmsghdr *nlh;
> + u32 pid, seq;
> +
> + pid = NETLINK_CB(cb->skb).pid;
> + seq = cb->nlh->nlmsg_seq;
> +
> + list_for_each_entry(ha, &list->list, list) {
> + if (*idx < cb->args[0])
> + goto skip;
> +
> + nlh = nlmsg_put(skb, pid, seq,
> + RTM_NEWNEIGH, sizeof(*ndm), NLM_F_MULTI);
> + if (!nlh)
> + break;
This break is effectively return 0, but shouldn't we return an error?
In practice this does no harm because any subsequent invocation of
nlmsg_populate_fdb() for the same skb is also going to fail here with no
change to *idx. But it would be more obviously correct to return an
error.
[...]
> + }
> + return 0;
> +nla_put_failure:
> + nlmsg_cancel(skb, nlh);
> + return -ENOMEM;
> +}
[...]
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [net-next PATCH v1 2/7] net: addr_list: add exclusive dev_uc_add and dev_mc_add
From: Ben Hutchings @ 2012-04-11 3:33 UTC (permalink / raw)
To: John Fastabend
Cc: roprabhu, mst, stephen.hemminger, davem, hadi, jeffrey.t.kirsher,
netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <20120409220023.3288.59939.stgit@jf-dev1-dcblab>
On Mon, 2012-04-09 at 15:00 -0700, John Fastabend wrote:
> This adds a dev_uc_add_excl() and dev_mc_add_excl() calls
> similar to the original dev_{uc|mc}_add() except it sets
> the global bit and returns -EEXIST for duplicat entires.
>
> This is useful for drivers that support SR-IOV, macvlan
> devices and any other devices that need to manage the
> unicast and multicast lists.
[...]
> +/**
> + * dev_mc_add_excl - Add a global secondary multicast address
> + * @dev: device
> + * @addr: address to add
> + */
> +int dev_mc_add_excl(struct net_device *dev, unsigned char *addr)
> +{
> + struct netdev_hw_addr *ha;
> + int err;
> +
> + netif_addr_lock_bh(dev);
> + list_for_each_entry(ha, &dev->mc.list, list) {
> + if (!memcmp(ha->addr, addr, dev->addr_len) &&
> + ha->type == NETDEV_HW_ADDR_T_UNICAST) {
> + err = -EEXIST;
> + goto out;
> + }
> + }
> + err = __hw_addr_create_ex(&dev->mc, addr, dev->addr_len,
> + NETDEV_HW_ADDR_T_UNICAST, true);
[...]
The address types are wrong. But do we even need this function yet?
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [net-next PATCH v1 1/7] net: add generic PF_BRIDGE:RTM_ FDB hooks
From: Ben Hutchings @ 2012-04-11 3:23 UTC (permalink / raw)
To: John Fastabend
Cc: roprabhu, mst, stephen.hemminger, davem, hadi, jeffrey.t.kirsher,
netdev, gregory.v.rose, krkumar2, sri
In-Reply-To: <20120409220017.3288.13746.stgit@jf-dev1-dcblab>
On Mon, 2012-04-09 at 15:00 -0700, John Fastabend wrote:
[...]
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 1f77540..05822e5 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
[...]
> @@ -905,6 +906,19 @@ struct netdev_fcoe_hbainfo {
> * feature set might be less than what was returned by ndo_fix_features()).
> * Must return >0 or -errno if it changed dev->features itself.
> *
> + * int (*ndo_fdb_add)(struct ndmsg *ndm, struct net_device *dev,
> + * unsigned char *addr, u16 flags)
> + * Adds an FDB entry to dev for addr. The ndmsg contains flags to indicate
> + * if the dev->master FDB should be updated or the devices internal FDB.
I don't think the second sentence is helpful, as rtnl_fdb_add() will
take care of those flags.
> + * int (*ndo_fdb_del)(struct ndmsg *ndm, struct net_device *dev,
> + * unsigned char *addr)
> + * Deletes the FDB entry from dev coresponding to addr. The ndmsg
> + * contains flags to indicate if the dev->master FDB should be
> + * updated or the devices internal FDB.
Similarly here.
> + * int (*ndo_fdb_dump)(struct sk_buff *skb, struct netlink_callback *cb,
> + * struct net_device *dev, int idx)
> + * Used to add FDB entries to dump requests. Implementers should add
> + * entries to skb and update idx with the number of entries.
> */
[...
> --- a/net/core/rtnetlink.c
> +++ b/net/core/rtnetlink.c
[...]
> +static int rtnl_fdb_add(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
> +{
[...]
> + err = -EOPNOTSUPP;
So if NTF_MASTER and NTF_SELF are both set, we can quietly fall back to
just setting one FDB? Not sure that's really desirable though
> + /* Support fdb on master device the net/bridge default case */
> + if ((!ndm->ndm_flags || ndm->ndm_flags & NTF_MASTER) &&
> + (dev->priv_flags & IFF_BRIDGE_PORT)) {
> + struct net_device *master = dev->master;
> +
> + if (master->netdev_ops->ndo_fdb_add)
This operation is surely going to be mandatory for bridge devices, so
this check should be omitted or changed to a BUG_ON().
> + err = master->netdev_ops->ndo_fdb_add(ndm, dev, addr,
> + nlh->nlmsg_flags);
Shoudn't we return early on error?
> + }
> +
> + /* Embedded bridge, macvlan, and any other device support */
> + if ((ndm->ndm_flags & NTF_SELF) &&
> + dev->netdev_ops->ndo_fdb_add)
Error if !dev->netdev_ops->ndo_fdb_add.
> + err = dev->netdev_ops->ndo_fdb_add(ndm, dev, addr,
> + nlh->nlmsg_flags);
Wonder what we should do on error here if we've already successfully
called ndo_fdb_add on the master? Should we try to roll back the first
addition?
> + return err;
> +}
> +
> +static int rtnl_fdb_del(struct sk_buff *skb, struct nlmsghdr *nlh, void *arg)
> +{
[...]
> + err = -EOPNOTSUPP;
> +
> + /* Support fdb on master device the net/bridge default case */
> + if ((!ndm->ndm_flags || ndm->ndm_flags & NTF_MASTER) &&
> + (dev->priv_flags & IFF_BRIDGE_PORT)) {
> + struct net_device *master = dev->master;
> +
> + if (master->netdev_ops->ndo_fdb_del)
> + err = master->netdev_ops->ndo_fdb_del(ndm, dev, addr);
> + }
> +
> + /* Embedded bridge, macvlan, and any other device support */
> + if ((ndm->ndm_flags & NTF_SELF) &&
> + dev->netdev_ops->ndo_fdb_del)
> + err = dev->netdev_ops->ndo_fdb_del(ndm, dev, addr);
> + return err;
> +}
[...]
This has the same issues.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h
From: H. Peter Anvin @ 2012-04-11 3:20 UTC (permalink / raw)
To: Will Drewry
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore, akpm,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <CABqD9hZgnrKFY_Wei-ysU=Dy7Og2iEemnqPvcQ14M0+vL65gHQ@mail.gmail.com>
On 04/10/2012 08:13 PM, Will Drewry wrote:
> On Sun, Mar 25, 2012 at 2:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
>> On 03/14/2012 08:11 PM, Will Drewry wrote:
>>>
>>> +static inline int syscall_get_arch(struct task_struct *task,
>>> + struct pt_regs *regs)
>>> +{
>>> +#ifdef CONFIG_IA32_EMULATION
>>> + /*
>>> + * TS_COMPAT is set for 32-bit syscall entries and then
>>> + * remains set until we return to user mode.
>>> + *
>>> + * TIF_IA32 tasks should always have TS_COMPAT set at
>>> + * system call time.
>>> + */
>>> + if (task_thread_info(task)->status & TS_COMPAT)
>>> + return AUDIT_ARCH_I386;
>>> +#endif
>>> + return AUDIT_ARCH_X86_64;
>>> +}
>>> #endif /* CONFIG_X86_32 */
>>>
>>> #endif /* _ASM_X86_SYSCALL_H */
>>
>> Just one FYI on this: after the x32 changes are upstream this can be
>> implemented in terms of is_ia32_task().
>
> Now that I've seen is_ia32_task(), it appears to be exactly the same as above:
> (1) If we're x86_32, it's ia32
> (2) If we're x86_64, ia32 == !!(status & TS_COMPAT)
> (3) Otherwise, it's x86_64, including x32
>
> Am I missing something? Should is_ia32_task(void) take a task_struct?
> Right now, I don't see any reason to change the code, as posted, but
> maybe I am mis-reading?
>
Sorry, answered the wrong question. Yes, it is the same as above...
just wandered if we could centralize this test. It might indeed make
sense to provide general predicates which take a task pointer.
-hpa
^ permalink raw reply
* Re: [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h
From: H. Peter Anvin @ 2012-04-11 3:16 UTC (permalink / raw)
To: Will Drewry
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore, akpm,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <CABqD9hZgnrKFY_Wei-ysU=Dy7Og2iEemnqPvcQ14M0+vL65gHQ@mail.gmail.com>
On 04/10/2012 08:13 PM, Will Drewry wrote:
>
> Now that I've seen is_ia32_task(), it appears to be exactly the same as above:
> (1) If we're x86_32, it's ia32
> (2) If we're x86_64, ia32 == !!(status & TS_COMPAT)
> (3) Otherwise, it's x86_64, including x32
>
> Am I missing something? Should is_ia32_task(void) take a task_struct?
> Right now, I don't see any reason to change the code, as posted, but
> maybe I am mis-reading?
>
is_compat_task() is true for x32, is_ia32_task() is false.
-hpa
^ permalink raw reply
* Re: [PATCH v15 04/13] arch/x86: add syscall_get_arch to syscall.h
From: Will Drewry @ 2012-04-11 3:13 UTC (permalink / raw)
To: H. Peter Anvin
Cc: linux-kernel, linux-arch, linux-doc, kernel-hardening, netdev,
x86, arnd, davem, mingo, oleg, peterz, rdunlap, mcgrathr, tglx,
luto, eparis, serge.hallyn, djm, scarybeasts, indan, pmoore, akpm,
corbet, eric.dumazet, markus, coreyb, keescook
In-Reply-To: <4F6F7362.6030402@zytor.com>
On Sun, Mar 25, 2012 at 2:34 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 03/14/2012 08:11 PM, Will Drewry wrote:
>>
>> +static inline int syscall_get_arch(struct task_struct *task,
>> + struct pt_regs *regs)
>> +{
>> +#ifdef CONFIG_IA32_EMULATION
>> + /*
>> + * TS_COMPAT is set for 32-bit syscall entries and then
>> + * remains set until we return to user mode.
>> + *
>> + * TIF_IA32 tasks should always have TS_COMPAT set at
>> + * system call time.
>> + */
>> + if (task_thread_info(task)->status & TS_COMPAT)
>> + return AUDIT_ARCH_I386;
>> +#endif
>> + return AUDIT_ARCH_X86_64;
>> +}
>> #endif /* CONFIG_X86_32 */
>>
>> #endif /* _ASM_X86_SYSCALL_H */
>
> Just one FYI on this: after the x32 changes are upstream this can be
> implemented in terms of is_ia32_task().
Now that I've seen is_ia32_task(), it appears to be exactly the same as above:
(1) If we're x86_32, it's ia32
(2) If we're x86_64, ia32 == !!(status & TS_COMPAT)
(3) Otherwise, it's x86_64, including x32
Am I missing something? Should is_ia32_task(void) take a task_struct?
Right now, I don't see any reason to change the code, as posted, but
maybe I am mis-reading?
thanks!
will
^ permalink raw reply
* RE: Expose ltr/obff interface by sysfs
From: Hao, Xudong @ 2012-04-11 3:02 UTC (permalink / raw)
To: Konrad Rzeszutek Wilk
Cc: linux-pci@vger.kernel.org, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net, Jesse Barnes
In-Reply-To: <20120406183932.GB13473@phenom.dumpdata.com>
> But a better question is - why should this be done - especially from the guest
> which has a limited view of the machine? The machine might be running a lot of
> other requests so the OBFF inside the guest could be invalid.
>
Maybe I did not describe it clearly, the original idea is host admin can control the inode interface but not guest.
> -----Original Message-----
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk@oracle.com]
> Sent: Saturday, April 07, 2012 2:40 AM
> To: Hao, Xudong
> Cc: linux-pci@vger.kernel.org; netdev@vger.kernel.org;
> e1000-devel@lists.sourceforge.net; Jesse Barnes
> Subject: Re: Expose ltr/obff interface by sysfs
>
> On Fri, Apr 06, 2012 at 02:43:59AM +0000, Hao, Xudong wrote:
> > Hi,
> >
> > I'm working on virtualization Xen/KVM. I saw there are ltr/obff
> enabling/disabling function in pci.c, but no called till now. I want to know if
> anybody(driver developer) are working for using it? Can driver change the LTR
> latency value dynamically?
> >
> > /*
> > LTR(Latency tolerance reporting) allows devices to send messages to the root
> complex indicating their latency tolerance for snooped & unsnooped memory
> transactions.
> > OBFF (optimized buffer flush/fill), where supported, can help improve energy
> efficiency by giving devices information about when interrupts and other
> activity will have a reduced power impact.
> > */
> >
> > One way to control ltr/obff is used by driver, however, I'm considering that in
> virtualization, how guest OS driver control them. I have an idea that expose an
> inode interface by sysfs, like "reset" inode implemented in pci-sysfs.c, so that
> system user/administrator can enable/disable ltr/obff or set latency value on
> userspace, but not limited on driver. Comments?
>
> So right now the driver inside the guest can probably see it, but can't change
> them.
> (As those requests end up being filtered).
>
> But there is nothing wrong with your changing those values from within the
> host.
>
> But a better question is - why should this be done - especially from the guest
> which has a limited view of the machine? The machine might be running a lot of
> other requests so the OBFF inside the guest could be invalid.
>
>
> >
> > < pls CC me when reply this mail, thanks >
> >
> > Best Regards,
> > Xudong Hao
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci"
> > 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
* linux-next: manual merge of the wireless-next tree with the net-next tree
From: Stephen Rothwell @ 2012-04-11 2:56 UTC (permalink / raw)
To: John W. Linville
Cc: linux-next, linux-kernel, David Miller, netdev, Javier Cardona,
Marco Porsch, Pavel Zubarev
[-- Attachment #1: Type: text/plain, Size: 6481 bytes --]
Hi John,
Today's linux-next merge of the wireless-next tree got a conflict in
net/wireless/nl80211.c between commit 9360ffd18597 ("wireless: Stop using
NLA_PUT*()") from the net-next tree and commit d299a1f21ea7 ("{nl,cfg}
80211: Support for mesh synchronization") from the wireless-next tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc net/wireless/nl80211.c
index 65622e9,b12a052..0000000
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@@ -2540,17 -2486,18 +2543,20 @@@ static int nl80211_send_station(struct
nla_nest_end(msg, bss_param);
}
- if (sinfo->filled & STATION_INFO_STA_FLAGS)
- NLA_PUT(msg, NL80211_STA_INFO_STA_FLAGS,
- sizeof(struct nl80211_sta_flag_update),
- &sinfo->sta_flags);
- if (sinfo->filled & STATION_INFO_T_OFFSET)
- NLA_PUT_U64(msg, NL80211_STA_INFO_T_OFFSET,
- sinfo->t_offset);
+ if ((sinfo->filled & STATION_INFO_STA_FLAGS) &&
+ nla_put(msg, NL80211_STA_INFO_STA_FLAGS,
+ sizeof(struct nl80211_sta_flag_update),
+ &sinfo->sta_flags))
+ goto nla_put_failure;
++ if ((sinfo->filled & STATION_INFO_T_OFFSET) &&
++ nla_put_u64(msg, NL80211_STA_INFO_T_OFFSET, sinfo->t_offset))
++ goto nla_put_failure;
nla_nest_end(msg, sinfoattr);
- if (sinfo->filled & STATION_INFO_ASSOC_REQ_IES)
- NLA_PUT(msg, NL80211_ATTR_IE, sinfo->assoc_req_ies_len,
- sinfo->assoc_req_ies);
+ if ((sinfo->filled & STATION_INFO_ASSOC_REQ_IES) &&
+ nla_put(msg, NL80211_ATTR_IE, sinfo->assoc_req_ies_len,
+ sinfo->assoc_req_ies))
+ goto nla_put_failure;
return genlmsg_end(msg, hdr);
@@@ -3328,48 -3274,49 +3334,50 @@@ static int nl80211_get_mesh_config(stru
pinfoattr = nla_nest_start(msg, NL80211_ATTR_MESH_CONFIG);
if (!pinfoattr)
goto nla_put_failure;
- NLA_PUT_U32(msg, NL80211_ATTR_IFINDEX, dev->ifindex);
- NLA_PUT_U16(msg, NL80211_MESHCONF_RETRY_TIMEOUT,
- cur_params.dot11MeshRetryTimeout);
- NLA_PUT_U16(msg, NL80211_MESHCONF_CONFIRM_TIMEOUT,
- cur_params.dot11MeshConfirmTimeout);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HOLDING_TIMEOUT,
- cur_params.dot11MeshHoldingTimeout);
- NLA_PUT_U16(msg, NL80211_MESHCONF_MAX_PEER_LINKS,
- cur_params.dot11MeshMaxPeerLinks);
- NLA_PUT_U8(msg, NL80211_MESHCONF_MAX_RETRIES,
- cur_params.dot11MeshMaxRetries);
- NLA_PUT_U8(msg, NL80211_MESHCONF_TTL,
- cur_params.dot11MeshTTL);
- NLA_PUT_U8(msg, NL80211_MESHCONF_ELEMENT_TTL,
- cur_params.element_ttl);
- NLA_PUT_U8(msg, NL80211_MESHCONF_AUTO_OPEN_PLINKS,
- cur_params.auto_open_plinks);
- NLA_PUT_U32(msg, NL80211_MESHCONF_SYNC_OFFSET_MAX_NEIGHBOR,
- cur_params.dot11MeshNbrOffsetMaxNeighbor);
- NLA_PUT_U8(msg, NL80211_MESHCONF_HWMP_MAX_PREQ_RETRIES,
- cur_params.dot11MeshHWMPmaxPREQretries);
- NLA_PUT_U32(msg, NL80211_MESHCONF_PATH_REFRESH_TIME,
- cur_params.path_refresh_time);
- NLA_PUT_U16(msg, NL80211_MESHCONF_MIN_DISCOVERY_TIMEOUT,
- cur_params.min_discovery_timeout);
- NLA_PUT_U32(msg, NL80211_MESHCONF_HWMP_ACTIVE_PATH_TIMEOUT,
- cur_params.dot11MeshHWMPactivePathTimeout);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HWMP_PREQ_MIN_INTERVAL,
- cur_params.dot11MeshHWMPpreqMinInterval);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HWMP_PERR_MIN_INTERVAL,
- cur_params.dot11MeshHWMPperrMinInterval);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HWMP_NET_DIAM_TRVS_TIME,
- cur_params.dot11MeshHWMPnetDiameterTraversalTime);
- NLA_PUT_U8(msg, NL80211_MESHCONF_HWMP_ROOTMODE,
- cur_params.dot11MeshHWMPRootMode);
- NLA_PUT_U16(msg, NL80211_MESHCONF_HWMP_RANN_INTERVAL,
- cur_params.dot11MeshHWMPRannInterval);
- NLA_PUT_U8(msg, NL80211_MESHCONF_GATE_ANNOUNCEMENTS,
- cur_params.dot11MeshGateAnnouncementProtocol);
- NLA_PUT_U8(msg, NL80211_MESHCONF_FORWARDING,
- cur_params.dot11MeshForwarding);
- NLA_PUT_U32(msg, NL80211_MESHCONF_RSSI_THRESHOLD,
- cur_params.rssi_threshold);
+ if (nla_put_u32(msg, NL80211_ATTR_IFINDEX, dev->ifindex) ||
+ nla_put_u16(msg, NL80211_MESHCONF_RETRY_TIMEOUT,
+ cur_params.dot11MeshRetryTimeout) ||
+ nla_put_u16(msg, NL80211_MESHCONF_CONFIRM_TIMEOUT,
+ cur_params.dot11MeshConfirmTimeout) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HOLDING_TIMEOUT,
+ cur_params.dot11MeshHoldingTimeout) ||
+ nla_put_u16(msg, NL80211_MESHCONF_MAX_PEER_LINKS,
+ cur_params.dot11MeshMaxPeerLinks) ||
+ nla_put_u8(msg, NL80211_MESHCONF_MAX_RETRIES,
+ cur_params.dot11MeshMaxRetries) ||
+ nla_put_u8(msg, NL80211_MESHCONF_TTL,
+ cur_params.dot11MeshTTL) ||
+ nla_put_u8(msg, NL80211_MESHCONF_ELEMENT_TTL,
+ cur_params.element_ttl) ||
+ nla_put_u8(msg, NL80211_MESHCONF_AUTO_OPEN_PLINKS,
+ cur_params.auto_open_plinks) ||
++ nla_put_u32(msg, NL80211_MESHCONF_SYNC_OFFSET_MAX_NEIGHBOR,
++ cur_params.dot11MeshNbrOffsetMaxNeighbor) ||
+ nla_put_u8(msg, NL80211_MESHCONF_HWMP_MAX_PREQ_RETRIES,
+ cur_params.dot11MeshHWMPmaxPREQretries) ||
+ nla_put_u32(msg, NL80211_MESHCONF_PATH_REFRESH_TIME,
+ cur_params.path_refresh_time) ||
+ nla_put_u16(msg, NL80211_MESHCONF_MIN_DISCOVERY_TIMEOUT,
+ cur_params.min_discovery_timeout) ||
+ nla_put_u32(msg, NL80211_MESHCONF_HWMP_ACTIVE_PATH_TIMEOUT,
+ cur_params.dot11MeshHWMPactivePathTimeout) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HWMP_PREQ_MIN_INTERVAL,
+ cur_params.dot11MeshHWMPpreqMinInterval) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HWMP_PERR_MIN_INTERVAL,
+ cur_params.dot11MeshHWMPperrMinInterval) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HWMP_NET_DIAM_TRVS_TIME,
+ cur_params.dot11MeshHWMPnetDiameterTraversalTime) ||
+ nla_put_u8(msg, NL80211_MESHCONF_HWMP_ROOTMODE,
+ cur_params.dot11MeshHWMPRootMode) ||
+ nla_put_u16(msg, NL80211_MESHCONF_HWMP_RANN_INTERVAL,
+ cur_params.dot11MeshHWMPRannInterval) ||
+ nla_put_u8(msg, NL80211_MESHCONF_GATE_ANNOUNCEMENTS,
+ cur_params.dot11MeshGateAnnouncementProtocol) ||
+ nla_put_u8(msg, NL80211_MESHCONF_FORWARDING,
+ cur_params.dot11MeshForwarding) ||
+ nla_put_u32(msg, NL80211_MESHCONF_RSSI_THRESHOLD,
+ cur_params.rssi_threshold))
+ goto nla_put_failure;
nla_nest_end(msg, pinfoattr);
genlmsg_end(msg, hdr);
return genlmsg_reply(msg, info);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] memcg/tcp: fix warning caused b res->usage go to negative.
From: Glauber Costa @ 2012-04-11 2:22 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki; +Cc: netdev, David Miller, Andrew Morton
In-Reply-To: <4F83B3FD.4010107@jp.fujitsu.com>
>
> The problem is that jump_label updating is not atomic_ops.
That's indeed really bad.
You seem to be right about that... I wonder, however, if we should
prevent anything to run in any cpu during the jump_label update?
The update can be slow, sure, but it is not expected to be frequent...
> I'm _not_ sure the update order of the jump_label in sock_update_memcg()
> and other jump instructions inserted at accounting.
Any ordering assumptions here would be extremely fragile, even if we
could make one.
> For example, if the jump instruction in sock_update_memcg() is updated 1st
> and others are updated later, it's unclear whether sockets which has _valid_
> sock->sk_cgrp will be accounted or not because accounting jump instruction
> may not be updated yet.
>
> Hopefully, label in sock_update_memcg should be updated last...
>
> Hm. If I do, I'll add one more key as:
>
> atomic_t sock_should_memcg_aware;
>
> And update 2 keys in following order.
>
> At enable
> static_key_slow_inc(&memcg_socket_limit_enabled)
> atomic_inc(&sock_should_memcg_aware);
>
> At disable
> atomic_dec(&sock_should_memcg_aware);
> static_key_slow_dec(&memcg_socket_limit_enabled)
>
> And
> ==
> void sock_update_memcg(struct sock *sk)
> {
> if (atomic_read(&sock_should_memcg_aware)) {
>
> ==
Problem here is that having an atomic variable here defeats a bit the
purpose of the jump labels.
If it is just in the update path, it is not *that* bad.
But unless we go fix the jump labels to prevent such thing from
happening, maybe it would be better to have two jump labels here?
One for the writer, that is updated last, and one from the readers.
This way we can force the ordering the way we want.
^ permalink raw reply
* [net-next PATCH 2/2] net/l2tp: add support for L2TP over IPv6 UDP
From: Benjamin LaHaise @ 2012-04-11 2:21 UTC (permalink / raw)
To: David S. Miller, James Chapman; +Cc: netdev
This patch adds support for carrying L2TP frames over UDP on top of IPv6 in
addition to the existing UDP on IPv4. Support has been tested with both hw
accelerated ethernet drivers, as well as dumb interfaces.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
---
include/linux/if_pppol2tp.h | 28 ++++++++++++++-
include/linux/if_pppox.h | 12 ++++++
net/l2tp/l2tp_core.c | 84 ++++++++++++++++++++++++++++++++++++------
net/l2tp/l2tp_ppp.c | 42 +++++++++++++++++++++-
4 files changed, 152 insertions(+), 14 deletions(-)
diff --git a/include/linux/if_pppol2tp.h b/include/linux/if_pppol2tp.h
index 23cefa1..b477541 100644
--- a/include/linux/if_pppol2tp.h
+++ b/include/linux/if_pppol2tp.h
@@ -19,10 +19,11 @@
#ifdef __KERNEL__
#include <linux/in.h>
+#include <linux/in6.h>
#endif
/* Structure used to connect() the socket to a particular tunnel UDP
- * socket.
+ * socket over IPv4.
*/
struct pppol2tp_addr {
__kernel_pid_t pid; /* pid that owns the fd.
@@ -35,6 +36,20 @@ struct pppol2tp_addr {
__u16 d_tunnel, d_session; /* For sending outgoing packets */
};
+/* Structure used to connect() the socket to a particular tunnel UDP
+ * socket over IPv6.
+ */
+struct pppol2tpin6_addr {
+ __kernel_pid_t pid; /* pid that owns the fd.
+ * 0 => current */
+ int fd; /* FD of UDP socket to use */
+
+ __u16 s_tunnel, s_session; /* For matching incoming packets */
+ __u16 d_tunnel, d_session; /* For sending outgoing packets */
+
+ struct sockaddr_in6 addr; /* IP address and port to send to */
+};
+
/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
* bits. So we need a different sockaddr structure.
*/
@@ -49,6 +64,17 @@ struct pppol2tpv3_addr {
__u32 d_tunnel, d_session; /* For sending outgoing packets */
};
+struct pppol2tpv3in6_addr {
+ __kernel_pid_t pid; /* pid that owns the fd.
+ * 0 => current */
+ int fd; /* FD of UDP or IP socket to use */
+
+ __u32 s_tunnel, s_session; /* For matching incoming packets */
+ __u32 d_tunnel, d_session; /* For sending outgoing packets */
+
+ struct sockaddr_in6 addr; /* IP address and port to send to */
+};
+
/* Socket options:
* DEBUG - bitmask of debug message categories
* SENDSEQ - 0 => don't send packets with sequence numbers
diff --git a/include/linux/if_pppox.h b/include/linux/if_pppox.h
index b5f927f..6720d57 100644
--- a/include/linux/if_pppox.h
+++ b/include/linux/if_pppox.h
@@ -83,6 +83,12 @@ struct sockaddr_pppol2tp {
struct pppol2tp_addr pppol2tp;
} __attribute__((packed));
+struct sockaddr_pppol2tpin6 {
+ __kernel_sa_family_t sa_family; /* address family, AF_PPPOX */
+ unsigned int sa_protocol; /* protocol identifier */
+ struct pppol2tpin6_addr pppol2tp;
+} __attribute__((packed));
+
/* The L2TPv3 protocol changes tunnel and session ids from 16 to 32
* bits. So we need a different sockaddr structure.
*/
@@ -92,6 +98,12 @@ struct sockaddr_pppol2tpv3 {
struct pppol2tpv3_addr pppol2tp;
} __attribute__((packed));
+struct sockaddr_pppol2tpv3in6 {
+ __kernel_sa_family_t sa_family; /* address family, AF_PPPOX */
+ unsigned int sa_protocol; /* protocol identifier */
+ struct pppol2tpv3in6_addr pppol2tp;
+} __attribute__((packed));
+
/*********************************************************************
*
* ioctl interface for defining forwarding of connections
diff --git a/net/l2tp/l2tp_core.c b/net/l2tp/l2tp_core.c
index 89ff8c6..ef024a4 100644
--- a/net/l2tp/l2tp_core.c
+++ b/net/l2tp/l2tp_core.c
@@ -53,6 +53,9 @@
#include <net/inet_common.h>
#include <net/xfrm.h>
#include <net/protocol.h>
+#include <net/inet6_connection_sock.h>
+#include <net/inet_ecn.h>
+#include <net/ip6_route.h>
#include <asm/byteorder.h>
#include <linux/atomic.h>
@@ -446,21 +449,43 @@ static inline int l2tp_verify_udp_checksum(struct sock *sk,
{
struct udphdr *uh = udp_hdr(skb);
u16 ulen = ntohs(uh->len);
- struct inet_sock *inet;
__wsum psum;
- if (sk->sk_no_check || skb_csum_unnecessary(skb) || !uh->check)
- return 0;
-
- inet = inet_sk(sk);
- psum = csum_tcpudp_nofold(inet->inet_saddr, inet->inet_daddr, ulen,
- IPPROTO_UDP, 0);
-
- if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
- !csum_fold(csum_add(psum, skb->csum)))
+ if (sk->sk_no_check || skb_csum_unnecessary(skb))
return 0;
- skb->csum = psum;
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6) {
+ if (!uh->check) {
+ LIMIT_NETDEBUG(KERN_INFO "L2TP: IPv6: checksum is 0\n");
+ return 1;
+ }
+ if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
+ !csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
+ &ipv6_hdr(skb)->daddr, ulen,
+ IPPROTO_UDP, skb->csum)) {
+ skb->ip_summed = CHECKSUM_UNNECESSARY;
+ return 0;
+ }
+ skb->csum = ~csum_unfold(csum_ipv6_magic(&ipv6_hdr(skb)->saddr,
+ &ipv6_hdr(skb)->daddr,
+ skb->len, IPPROTO_UDP,
+ 0));
+ } else
+#endif
+ {
+ struct inet_sock *inet;
+ if (!uh->check)
+ return 0;
+ inet = inet_sk(sk);
+ psum = csum_tcpudp_nofold(inet->inet_saddr, inet->inet_daddr,
+ ulen, IPPROTO_UDP, 0);
+
+ if ((skb->ip_summed == CHECKSUM_COMPLETE) &&
+ !csum_fold(csum_add(psum, skb->csum)))
+ return 0;
+ skb->csum = psum;
+ }
return __skb_checksum_complete(skb);
}
@@ -988,7 +1013,12 @@ static int l2tp_xmit_core(struct l2tp_session *session, struct sk_buff *skb,
/* Queue the packet to IP for output */
skb->local_df = 1;
- error = ip_queue_xmit(skb, fl);
+#if IS_ENABLED(CONFIG_IPV6)
+ if (skb->sk->sk_family == PF_INET6)
+ error = inet6_csk_xmit(skb, NULL);
+ else
+#endif
+ error = ip_queue_xmit(skb, fl);
/* Update stats */
if (error >= 0) {
@@ -1021,6 +1051,31 @@ static inline void l2tp_skb_set_owner_w(struct sk_buff *skb, struct sock *sk)
skb->destructor = l2tp_sock_wfree;
}
+#if IS_ENABLED(CONFIG_IPV6)
+static void l2tp_xmit_ipv6_csum(struct sock *sk, struct sk_buff *skb,
+ int udp_len)
+{
+ struct ipv6_pinfo *np = inet6_sk(sk);
+ struct udphdr *uh = udp_hdr(skb);
+
+ if (!skb_dst(skb) || !skb_dst(skb)->dev ||
+ !(skb_dst(skb)->dev->features & NETIF_F_IPV6_CSUM)) {
+ skb->ip_summed = CHECKSUM_COMPLETE;
+ skb->csum = skb_checksum(skb, 0, udp_len, 0);
+ uh->check = csum_ipv6_magic(&np->saddr, &np->daddr, udp_len,
+ IPPROTO_UDP, skb->csum);
+ if (uh->check == 0)
+ uh->check = CSUM_MANGLED_0;
+ } else {
+ skb->ip_summed = CHECKSUM_PARTIAL;
+ skb->csum_start = skb_transport_header(skb) - skb->head;
+ skb->csum_offset = offsetof(struct udphdr, check);
+ uh->check = ~csum_ipv6_magic(&np->saddr, &np->daddr,
+ udp_len, IPPROTO_UDP, 0);
+ }
+}
+#endif
+
/* If caller requires the skb to have a ppp header, the header must be
* inserted in the skb data before calling this function.
*/
@@ -1089,6 +1144,11 @@ int l2tp_xmit_skb(struct l2tp_session *session, struct sk_buff *skb, int hdr_len
uh->check = 0;
/* Calculate UDP checksum if configured to do so */
+#if IS_ENABLED(CONFIG_IPV6)
+ if (sk->sk_family == PF_INET6)
+ l2tp_xmit_ipv6_csum(sk, skb, udp_len);
+ else
+#endif
if (sk->sk_no_check == UDP_CSUM_NOXMIT)
skb->ip_summed = CHECKSUM_NONE;
else if ((skb_dst(skb) && skb_dst(skb)->dev) &&
diff --git a/net/l2tp/l2tp_ppp.c b/net/l2tp/l2tp_ppp.c
index 1addd9f..27b9dec 100644
--- a/net/l2tp/l2tp_ppp.c
+++ b/net/l2tp/l2tp_ppp.c
@@ -916,7 +916,7 @@ static int pppol2tp_getname(struct socket *sock, struct sockaddr *uaddr,
}
inet = inet_sk(tunnel->sock);
- if (tunnel->version == 2) {
+ if ((tunnel->version == 2) && (tunnel->sock->sk_family == AF_INET)) {
struct sockaddr_pppol2tp sp;
len = sizeof(sp);
memset(&sp, 0, len);
@@ -932,6 +932,46 @@ static int pppol2tp_getname(struct socket *sock, struct sockaddr *uaddr,
sp.pppol2tp.addr.sin_port = inet->inet_dport;
sp.pppol2tp.addr.sin_addr.s_addr = inet->inet_daddr;
memcpy(uaddr, &sp, len);
+#if IS_ENABLED(CONFIG_IPV6)
+ } else if ((tunnel->version == 2) &&
+ (tunnel->sock->sk_family == AF_INET6)) {
+ struct ipv6_pinfo *np = inet6_sk(tunnel->sock);
+ struct sockaddr_pppol2tpin6 sp;
+ len = sizeof(sp);
+ memset(&sp, 0, len);
+ sp.sa_family = AF_PPPOX;
+ sp.sa_protocol = PX_PROTO_OL2TP;
+ sp.pppol2tp.fd = tunnel->fd;
+ sp.pppol2tp.pid = pls->owner;
+ sp.pppol2tp.s_tunnel = tunnel->tunnel_id;
+ sp.pppol2tp.d_tunnel = tunnel->peer_tunnel_id;
+ sp.pppol2tp.s_session = session->session_id;
+ sp.pppol2tp.d_session = session->peer_session_id;
+ sp.pppol2tp.addr.sin6_family = AF_INET6;
+ sp.pppol2tp.addr.sin6_port = inet->inet_dport;
+ memcpy(&sp.pppol2tp.addr.sin6_addr, &np->daddr,
+ sizeof(np->daddr));
+ memcpy(uaddr, &sp, len);
+ } else if ((tunnel->version == 3) &&
+ (tunnel->sock->sk_family == AF_INET6)) {
+ struct ipv6_pinfo *np = inet6_sk(tunnel->sock);
+ struct sockaddr_pppol2tpv3in6 sp;
+ len = sizeof(sp);
+ memset(&sp, 0, len);
+ sp.sa_family = AF_PPPOX;
+ sp.sa_protocol = PX_PROTO_OL2TP;
+ sp.pppol2tp.fd = tunnel->fd;
+ sp.pppol2tp.pid = pls->owner;
+ sp.pppol2tp.s_tunnel = tunnel->tunnel_id;
+ sp.pppol2tp.d_tunnel = tunnel->peer_tunnel_id;
+ sp.pppol2tp.s_session = session->session_id;
+ sp.pppol2tp.d_session = session->peer_session_id;
+ sp.pppol2tp.addr.sin6_family = AF_INET6;
+ sp.pppol2tp.addr.sin6_port = inet->inet_dport;
+ memcpy(&sp.pppol2tp.addr.sin6_addr, &np->daddr,
+ sizeof(np->daddr));
+ memcpy(uaddr, &sp, len);
+#endif
} else if (tunnel->version == 3) {
struct sockaddr_pppol2tpv3 sp;
len = sizeof(sp);
--
1.7.4.1
--
"Thought is the essence of where you are now."
^ permalink raw reply related
* [PATCH net-next 1/2] net/ipv6/udp: Add encap_rcv support to IPv6 UDP
From: Benjamin LaHaise @ 2012-04-11 2:20 UTC (permalink / raw)
To: David S. Miller, James Chapman; +Cc: netdev
At present, UDP encapsulated protocols (like L2TP) are only able to use the
encap_rcv hook with UDP over IPv4. This patch adds the same support for use
with UDP over IPv6.
Signed-off-by: Benjamin LaHaise <bcrl@kvack.org>
---
net/ipv6/udp.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 37b0699..4d7cd72 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -515,6 +515,37 @@ int udpv6_queue_rcv_skb(struct sock * sk, struct sk_buff *skb)
if (!xfrm6_policy_check(sk, XFRM_POLICY_IN, skb))
goto drop;
+ if (up->encap_type) {
+ int (*encap_rcv)(struct sock *sk, struct sk_buff *skb);
+
+ /*
+ * This is an encapsulation socket so pass the skb to
+ * the socket's udp_encap_rcv() hook. Otherwise, just
+ * fall through and pass this up the UDP socket.
+ * up->encap_rcv() returns the following value:
+ * =0 if skb was successfully passed to the encap
+ * handler or was discarded by it.
+ * >0 if skb should be passed on to UDP.
+ * <0 if skb should be resubmitted as proto -N
+ */
+
+ /* if we're overly short, let UDP handle it */
+ encap_rcv = ACCESS_ONCE(up->encap_rcv);
+ if (skb->len > sizeof(struct udphdr) && encap_rcv != NULL) {
+ int ret;
+
+ ret = encap_rcv(sk, skb);
+ if (ret <= 0) {
+ UDP6_INC_STATS_BH(sock_net(sk),
+ UDP_MIB_INDATAGRAMS,
+ is_udplite);
+ return -ret;
+ }
+ }
+
+ /* FALLTHROUGH -- it's a UDP Packet */
+ }
+
/*
* UDP-Lite specific tests, ignored on UDP sockets (see net/ipv4/udp.c).
*/
--
1.7.4.1
--
"Thought is the essence of where you are now."
^ permalink raw reply related
* rcu_sched_state detected stall, no stack trace
From: Prashant Batra (prbatra) @ 2012-04-11 2:20 UTC (permalink / raw)
To: netdev
Hi,
I am running vanilla kernel 3.0.23 . I am trying to add some 6K and more
IPv6 IPSec tunnels.
I am getting these warnings in dmesg close to 6k tunnels, after which
the kernel hangs and have to reboot the kernel.
[ 1511.045261] INFO: rcu_sched_state detected stall on CPU 4 (t=300000
jiffies) [ 1534.736899] INFO: rcu_bh_state detected stalls on
CPUs/tasks: { 4} (detected by 13, t=300002 jiffies)
I am not getting any back-trace also, to figure out what is actually
causing the stall to happen.
Could someone help to figure out the issue.
Regards,
Prashant
^ permalink raw reply
* Re: [net-next PATCH v1 7/7] macvlan: add FDB bridge ops and new macvlan mode
From: John Fastabend @ 2012-04-11 1:42 UTC (permalink / raw)
To: Sridhar Samudrala, Michael S. Tsirkin
Cc: roprabhu, stephen.hemminger, davem, hadi, bhutchings,
jeffrey.t.kirsher, netdev, gregory.v.rose, krkumar2
In-Reply-To: <4F84D472.8090602@us.ibm.com>
On 4/10/2012 5:46 PM, Sridhar Samudrala wrote:
> On 4/10/2012 8:35 AM, John Fastabend wrote:
>> On 4/10/2012 8:30 AM, Michael S. Tsirkin wrote:
>>> On Tue, Apr 10, 2012 at 08:26:21AM -0700, John Fastabend wrote:
>>>> On 4/10/2012 7:35 AM, Michael S. Tsirkin wrote:
>>>>> On Tue, Apr 10, 2012 at 07:25:58AM -0700, John Fastabend wrote:
>>>>>>> Hmm okay, but this would mean we should convert
>>>>>>> MACVLAN_MODE_PASSTHRU_NOPROMISC to something
>>>>>>> that can combined with all modes. E.g.
>>>>>>> MACVLAN_MODE_BRIDGE | MACVLAN_MODE_FLAG_XXXXX
>>>>>>>
>>>>>>> and document that it does not promise to flood
>>>>>>> multicast.
>>>>>>>
>>>>>> How about changing MACVLAN_MODE_PASSTHRU_NOPROMISC -> MACVLAN_MODE_NOPORMISC
>>>>>> for this patch. Then a follow on series can rework bridge
>>>>>> and VEPA to use it as well.
>>>>> Right. We probably need a better name if it's going to
>>>>> affect other things besides promisc though.
>>>>>
>>>> how about MACVLAN_MODE_FDBFLAG?
>>> The idea being that no one figures out what this means so
>>> no one will make any wrong assumptions? ;)
>>>
>> Well its a flag to enable the FDB (forwarding database) ops
>> and skip dev_set_promisc() on passthru mode. Any better ideas?
>> Maybe MACVLAN_MODE_FDBENABLE or MACVLAN_MODE_MANAGE_FDB?
> Do we need to introduce another mode? I think this patch is enabling passthru mode without the need
> to put the underlying device in promiscuous mode. So basically we can consider this patch as
> an optimization.
>
> Thanks
> Sridhar
>
Sridhar, Michael,
After thinking about this a bit I would propose keeping this
patch as is. Or if we prefer I can make this a flag but I don't
think that helps much. passthru mode is the only macvlan mode
that calls dev_set_promiscuity(). Either way I think this mode
or flag should _only_ toggle the call to dev_set_promiscuity().
Setting multicast dev->flag IFF_ALLMULTI seems to be a completely
separate optimization that we can work with a follow up patch.
Any thoughts?
Thanks for the feedback,
John
^ permalink raw reply
* Re: [RFC] net/hsr: Add support for IEC 62439-3 High-availability Seamless Redundancy
From: Stephen Hemminger @ 2012-04-11 1:28 UTC (permalink / raw)
To: Arvid Brodin
Cc: Ben Hutchings, David Miller, netdev@vger.kernel.org,
balferreira@googlemail.com
In-Reply-To: <4F84CA36.7020209@xdin.com>
> 3) My feeble suggestion to cast icmp_hdr() to (char *) is of course even worse (it doesn't
> even avoid the erroneous cast in the first place).
>
> So what do we do?
>
Reading Documentation/unalgined-memory-access.txt suggests that you
probably should copy the skb before passing up the stack (if necessary).
That is safe (but slightly slower).
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-11 1:16 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.211114.643908401942868800.davem@davemloft.net>
On Tue, Apr 10, 2012 at 6:11 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 17:59:40 -0700
>
>> On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
>>> From: Tim Hockin <thockin@hockin.org>
>>> Date: Tue, 10 Apr 2012 17:19:42 -0700
>>>
>>>> I agree. The patches to this driver have been very few and far
>>>> between, but even those I am largely unable to review any more.
>>>>
>>>> I'm more than willing to hand it off to someone who can do a better job of it
>>>
>>> My inclination was the mark the driver Orphan'd, which represents
>>> the current state of affairs quite accurately.
>>
>> I'm OK with that. As much as I don't like being a deadbeat, it's a
>> more accurate snapshot of this driver today.
>
> Ok, I'll push that MAINTAINERS change, thanks Tim.
I wish there were a way to say "I know a fair amount about this
device" without claiming an "M" line (send patches here).
Tim
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: David Miller @ 2012-04-11 1:11 UTC (permalink / raw)
To: thockin; +Cc: romieu, netdev
In-Reply-To: <CAAAKZwsVA7XxbbUfYRdC20Z0gjTG-3vAmQibA1Z5yaFdpa9jgA@mail.gmail.com>
From: Tim Hockin <thockin@hockin.org>
Date: Tue, 10 Apr 2012 17:59:40 -0700
> On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
>> From: Tim Hockin <thockin@hockin.org>
>> Date: Tue, 10 Apr 2012 17:19:42 -0700
>>
>>> I agree. The patches to this driver have been very few and far
>>> between, but even those I am largely unable to review any more.
>>>
>>> I'm more than willing to hand it off to someone who can do a better job of it
>>
>> My inclination was the mark the driver Orphan'd, which represents
>> the current state of affairs quite accurately.
>
> I'm OK with that. As much as I don't like being a deadbeat, it's a
> more accurate snapshot of this driver today.
Ok, I'll push that MAINTAINERS change, thanks Tim.
^ permalink raw reply
* Re: [PATCH net-next #2 28/39] natsemi: stop using net_device.{base_addr, irq}.
From: Tim Hockin @ 2012-04-11 0:59 UTC (permalink / raw)
To: David Miller; +Cc: romieu, netdev
In-Reply-To: <20120410.204202.923592889066244236.davem@davemloft.net>
On Tue, Apr 10, 2012 at 5:42 PM, David Miller <davem@davemloft.net> wrote:
> From: Tim Hockin <thockin@hockin.org>
> Date: Tue, 10 Apr 2012 17:19:42 -0700
>
>> I agree. The patches to this driver have been very few and far
>> between, but even those I am largely unable to review any more.
>>
>> I'm more than willing to hand it off to someone who can do a better job of it
>
> My inclination was the mark the driver Orphan'd, which represents
> the current state of affairs quite accurately.
I'm OK with that. As much as I don't like being a deadbeat, it's a
more accurate snapshot of this driver today.
Tim
^ permalink raw reply
* [PATCH 07/11] ethernet: replace open-coded ARRAY_SIZE with macro
From: Jim Cromie @ 2012-04-11 0:56 UTC (permalink / raw)
To: netdev, davem, jeffrey.t.kirsher, joe, florian, netdev
Cc: trivial, Jim Cromie
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
drivers/net/ethernet/s6gmac.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/s6gmac.c b/drivers/net/ethernet/s6gmac.c
index 1895605..8e9fda0 100644
--- a/drivers/net/ethernet/s6gmac.c
+++ b/drivers/net/ethernet/s6gmac.c
@@ -937,7 +937,7 @@ static struct net_device_stats *s6gmac_stats(struct net_device *dev)
do {
unsigned long flags;
spin_lock_irqsave(&pd->lock, flags);
- for (i = 0; i < sizeof(pd->stats) / sizeof(unsigned long); i++)
+ for (i = 0; i < ARRAY_SIZE(pd->stats); i++)
pd->stats[i] =
pd->carry[i] << (S6_GMAC_STAT_SIZE_MIN - 1);
s6gmac_stats_collect(pd, &statinf[0][0]);
--
1.7.8.1
^ permalink raw reply related
* [PATCH 06/11] enic: replace open-coded ARRAY_SIZE with macro
From: Jim Cromie @ 2012-04-11 0:56 UTC (permalink / raw)
To: netdev; +Cc: trivial, Jim Cromie
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
drivers/net/ethernet/cisco/enic/enic_pp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_pp.c b/drivers/net/ethernet/cisco/enic/enic_pp.c
index dafea1e..43464f0 100644
--- a/drivers/net/ethernet/cisco/enic/enic_pp.c
+++ b/drivers/net/ethernet/cisco/enic/enic_pp.c
@@ -184,7 +184,7 @@ static int (*enic_pp_handlers[])(struct enic *enic, int vf,
};
static const int enic_pp_handlers_count =
- sizeof(enic_pp_handlers)/sizeof(*enic_pp_handlers);
+ ARRAY_SIZE(enic_pp_handlers);
static int enic_pp_preassociate(struct enic *enic, int vf,
struct enic_port_profile *prev_pp, int *restore_pp)
--
1.7.8.1
^ permalink raw reply related
* [PATCH 05/11] broadcom: replace open-coded ARRAY_SIZE with macro
From: Jim Cromie @ 2012-04-11 0:56 UTC (permalink / raw)
To: netdev; +Cc: trivial, Jim Cromie
Signed-off-by: Jim Cromie <jim.cromie@gmail.com>
---
drivers/net/ethernet/broadcom/bnx2.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2.c b/drivers/net/ethernet/broadcom/bnx2.c
index 8297e28..0552168 100644
--- a/drivers/net/ethernet/broadcom/bnx2.c
+++ b/drivers/net/ethernet/broadcom/bnx2.c
@@ -7343,8 +7343,7 @@ static struct {
{ "rx_fw_discards" },
};
-#define BNX2_NUM_STATS (sizeof(bnx2_stats_str_arr)/\
- sizeof(bnx2_stats_str_arr[0]))
+#define BNX2_NUM_STATS ARRAY_SIZE(bnx2_stats_str_arr)
#define STATS_OFFSET32(offset_name) (offsetof(struct statistics_block, offset_name) / 4)
--
1.7.8.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox