* Re: [PATCH v0 3/4] cgroup: net_cls: Pass in task to sock_update_classid()
From: Eric Dumazet @ 2012-10-17 13:37 UTC (permalink / raw)
To: Daniel Wagner
Cc: netdev, cgroups, Daniel Wagner, David S. Miller,
Michael S. Tsirkin, Eric Dumazet, Glauber Costa, Joe Perches,
Neil Horman, Stanislav Kinsbursky, Tejun Heo
In-Reply-To: <1350479078-29361-4-git-send-email-wagi@monom.org>
On Wed, 2012-10-17 at 15:04 +0200, Daniel Wagner wrote:
> From: Daniel Wagner <daniel.wagner@bmw-carit.de>
>
> sock_update_classid() assumes that the update operation always are
> applied on the current task. sock_update_classid() needs to know on
> which tasks to work on in order to be able to migrate task between
> cgroups using the struct cgroup_subsys attach() callback.
>
...
>
> -extern void sock_update_classid(struct sock *sk);
> +extern void sock_update_classid(struct sock *sk, struct task_struct *task);
>
> #if IS_BUILTIN(CONFIG_NET_CLS_CGROUP)
> static inline u32 task_cls_classid(struct task_struct *p)
> diff --git a/net/core/sock.c b/net/core/sock.c
> index 8a146cf..68c2f3b 100644
> --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1214,12 +1214,12 @@ static void sk_prot_free(struct proto *prot, struct sock *sk)
>
> #ifdef CONFIG_CGROUPS
> #if IS_ENABLED(CONFIG_NET_CLS_CGROUP)
> -void sock_update_classid(struct sock *sk)
> +void sock_update_classid(struct sock *sk, struct task_struct *task)
> {
> u32 classid;
>
> rcu_read_lock(); /* doing current task, which cannot vanish. */
> - classid = task_cls_classid(current);
> + classid = task_cls_classid(task);
> rcu_read_unlock();
Comment is now misleading (since task might not be current) and
rcu_read_lock()/rcu_read_unlock() protects nothing here, but avoid a
lockdep splat...
Hey task_cls_classid() has its own rcu protection since commit
3fb5a991916091a908d (cls_cgroup: Fix rcu lockdep warning)
So we can safely revert Paul commit (1144182a8757f2a1)
(We no longer need rcu_read_lock/unlock here)
(BTW net-next is not opened yet, its content outdated, although I like
your patch series !)
^ permalink raw reply
* RE: [PATCH 4/6] ptp: add api to get ptp seq id and event type from skb
From: N, Mugunthan V @ 2012-10-17 13:48 UTC (permalink / raw)
To: Ben Hutchings
Cc: netdev@vger.kernel.org, davem@davemloft.net, Richard Cochran
In-Reply-To: <1350429030.2649.49.camel@bwh-desktop.uk.solarflarecom.com>
> -----Original Message-----
> From: Ben Hutchings [mailto:bhutchings@solarflare.com]
> Sent: Wednesday, October 17, 2012 4:41 AM
> To: N, Mugunthan V
> Cc: netdev@vger.kernel.org; davem@davemloft.net; Richard Cochran
> Subject: Re: [PATCH 4/6] ptp: add api to get ptp seq id and event type
> from skb
>
> On Wed, 2012-10-17 at 04:15 +0530, Mugunthan V N wrote:
> > Cc: Richard Cochran <richardcochran@gmail.com>
> > Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
> > ---
> > include/linux/ptp_classify.h | 42
> ++++++++++++++++++++++++++++++++++++++++++
> > 1 files changed, 42 insertions(+), 0 deletions(-)
> >
> > diff --git a/include/linux/ptp_classify.h
> b/include/linux/ptp_classify.h
> > index 1dc420b..9b3b55b 100644
> > --- a/include/linux/ptp_classify.h
> > +++ b/include/linux/ptp_classify.h
> > @@ -137,4 +137,46 @@ static inline int ptp_filter_init(struct
> sock_filter *f, int len)
> > {OP_RETA, 0, 0, 0 }, /* */ \
> > /*L6x*/ {OP_RETK, 0, 0, PTP_CLASS_NONE },
> >
> > +static inline int ptp_get_skb_event(struct sk_buff *skb, u32
> ptp_class,
> > + u16 *evt_seqid, u8 *evt_msgtype)
> > +{
> > + u16 *seqid;
> > + unsigned int offset;
> > + u8 *msgtype, *data = skb->data;
> > +
> > + switch (ptp_class) {
> > + case PTP_CLASS_V1_IPV4:
> > + case PTP_CLASS_V2_IPV4:
> > + offset = ETH_HLEN + IPV4_HLEN(data) + UDP_HLEN;
> > + break;
> > + case PTP_CLASS_V1_IPV6:
> > + case PTP_CLASS_V2_IPV6:
> > + offset = OFF_PTP6;
> > + break;
> > + case PTP_CLASS_V2_L2:
> > + offset = ETH_HLEN;
> > + break;
> > + case PTP_CLASS_V2_VLAN:
> > + offset = ETH_HLEN + VLAN_HLEN;
> > + break;
> > + default:
> > + return 0;
> > + }
> > +
> > + if (skb->len + ETH_HLEN < offset + OFF_PTP_SEQUENCE_ID +
> sizeof(*seqid))
> > + return 0;
> > +
> > + if (unlikely(ptp_class & PTP_CLASS_V1))
> > + msgtype = data + offset + OFF_PTP_CONTROL;
> > + else
> > + msgtype = data + offset;
> > +
> > + seqid = (u16 *)(data + offset + OFF_PTP_SEQUENCE_ID);
>
> This assumes the skb is linear. Use skb_header_pointer() to allow for
> fragmented skbs.
Will fix this in next version patch series
Regards
Mugunthan V N
^ permalink raw reply
* Re: [PATCH v0 4/4] cgroup: net_cls: Rework update socket logic
From: John Fastabend @ 2012-10-17 14:02 UTC (permalink / raw)
To: Daniel Wagner
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, Li Zefan, David S. Miller, Michael S. Tsirkin,
Jamal Hadi Salim, Joe Perches, Neil Horman, Stanislav Kinsbursky,
Tejun Heo
In-Reply-To: <1350479078-29361-5-git-send-email-wagi-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
On 10/17/2012 6:04 AM, Daniel Wagner wrote:
> From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
>
> The cgroup logic part of net_cls is very similar as the one in
> net_prio. Let's stream line the net_cls logic with the net_prio one.
>
[...]
>
> +static void cgrp_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
> +{
> + struct task_struct *p;
> +
> + cgroup_taskset_for_each(p, cgrp, tset) {
> + unsigned int fd;
> + struct fdtable *fdt;
> + struct files_struct *files;
> +
> + task_lock(p);
> + files = p->files;
> + if (!files) {
> + task_unlock(p);
> + continue;
> + }
> +
> + spin_lock(&files->file_lock);
> + fdt = files_fdtable(files);
> + for (fd = 0; fd < fdt->max_fds; fd++) {
> + struct file *file;
> + struct socket *sock;
> + int err;
> +
> + file = fcheck_files(files, fd);
> + if (!file)
> + continue;
> +
> + sock = sock_from_file(file, &err);
> + if (sock)
> + sock_update_classid(sock->sk, p);
> + }
> + spin_unlock(&files->file_lock);
This block should probably use iterate_fd() instead of open coding
this. See the latest net_prio_attach().
.John
> + task_unlock(p);
> + }
> +}
> +
^ permalink raw reply
* Re: [RFC PATCH] net/core: support runtime PM on net_device
From: Ming Lei @ 2012-10-17 14:17 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: David S. Miller, Oliver Neukum, Alan Stern, netdev, linux-pm
In-Reply-To: <6849166.biYgaI8vyA@vostro.rjw.lan>
On Wed, Oct 17, 2012 at 1:07 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
> On Wednesday 10 of October 2012 20:58:33 Ming Lei wrote:
>> In ioctl path on net_device, the physical deivce is often
>> touched, but the physical device may have been put into runtime
>> suspend state already, so cause some utilitis(ifconfig, ethtool,
>> ...) to return failure in this situation.
>>
>> This patch enables runtime PM on net_device and mark it as
>> no_callbacks, and resumes the net_device if physical device
>> is to be accessed, then suspends it after completion of the
>> access.
>>
>> This patch fixes the problem above.
>>
>> Signed-off-by: Ming Lei <ming.lei@canonical.com>
>
> Well, it looks good in principle.
>
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
OK, I will prepare -v1 for merge later if no one has objection on
the patch, which has a compile error.('ret' is not defined in
dev_ethtool)
Thanks,
--
Ming Lei
^ permalink raw reply
* igb mtu change
From: ratheesh kannoth @ 2012-10-17 14:41 UTC (permalink / raw)
To: e1000-devel, linux-net, netdev
igb_change_mtu change is only changing adapter->rx_ring[0]->rx_buffer_len.
1) we dont have to change adapter->tx_ring[0]->rx_buffer_len ?
2) Is there any way to set different values to
adapter->tx_ring[0]->rx_buffer_len and
adapter->rx_ring[0]->rx_buffer_len ?
I am facing a problem because i have a strange requirement....i have
2KB bufffer pools ( GFP_DMA ) in kernel.
When i receive a jumbo pkt of size 9126, five rx_desc should be
used to recieve paket. So the first rx_desc will have a status error
bit indicating that it is not
EOP ( eop ) ....I could easily keep track of my 2KB buffer pools.
But when sending ...i wll collect all 2KB buffers of same jumbo frame
and dma to tx_ring....
So i need 1500 on rx_ring[0]->rx_buffer_len and 9126 on
adapter->tx_ring[0]->rx_buffer_len. .Is there any way ?
Thanks,
Ratheesh
^ permalink raw reply
* Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Jon Hunter @ 2012-10-17 14:41 UTC (permalink / raw)
To: Tony Lindgren
Cc: Richard Cochran, Afzal Mohammed, Russell King, Arnd Bergmann,
netdev, hvaibhav@ti.com, David Miller, linux-arm-kernel,
linux-omap@vger.kernel.org
In-Reply-To: <20121016212647.GM15569@atomide.com>
On 10/16/2012 04:26 PM, Tony Lindgren wrote:
> * Jon Hunter <jon-hunter@ti.com> [121016 14:00]:
>> Hi Tony,
>>
>> On 10/16/2012 12:48 PM, Tony Lindgren wrote:
>>> * Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
>>>> From: hvaibhav@ti.com <hvaibhav@ti.com>
>>>>
>>>> With recent changes in omap gpmc driver code, in case of DT
>>>> boot mode, where bootloader does not configure gpmc cs space
>>>> will result into kernel BUG() inside gpmc_mem_init() function,
>>>> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
>>>> gpmc_config7[0].baseaddress is set to '0' on reset.
>>>>
>>>> This use-case is applicable for any board/EVM which doesn't have
>>>> any peripheral connected to gpmc cs0, for example BeagleXM and
>>>> BeagleBone, so DT boot mode fails.
>>>>
>>>> This patch adds of_have_populated_dt() check before creating
>>>> device, so that for DT boot mode, gpmc probe will not be called
>>>> which is expected behavior, as gpmc is not supported yet from DT.
>>>
>>> I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
>>>
>>> Next time, please also cc linux-omap@vger.kernel.org for series
>>> like this. I'm sure the people reading the omap list are interested
>>> in these.
>>
>> This patch appears to be masking an underlying issue. How about
>> something like the following ...
>
> OK that looks good to me. I'll drop the earlier fix and use
> yours instead.
Hi Tony, sorry but I realised now that in my patch that I need to
take care of releasing and memory and clocks that were acquired
during the probe. Here is a V2. If you prefer I can create a delta
patch also with the previous.
Cheers
Jon
>From 91f5234d567c07ce1579b50e52de1a1e06ce5c68 Mon Sep 17 00:00:00 2001
From: Jon Hunter <jon-hunter@ti.com>
Date: Tue, 16 Oct 2012 15:22:58 -0500
Subject: [PATCH V2] ARM: OMAP2+: Allow kernel to boot even if GPMC fails to
reserve memory
Currently, if the GPMC driver fails to reserve memory when probed we will
call BUG() and the kernel will not boot. Instead of calling BUG(), return
an error from probe and allow kernel to boot.
Boot tested on AM335x beagle bone board and OMAP4430 Panda board.
V2 changes:
- Ensure that clock and memory resources are released on error.
Signed-off-by: Jon Hunter <jon-hunter@ti.com>
---
arch/arm/mach-omap2/gpmc.c | 24 +++++++++++++++++++-----
1 file changed, 19 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 5ac5cf3..92b5718 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -868,9 +868,9 @@ static void __devexit gpmc_mem_exit(void)
}
-static void __devinit gpmc_mem_init(void)
+static int __devinit gpmc_mem_init(void)
{
- int cs;
+ int cs, rc;
unsigned long boot_rom_space = 0;
/* never allocate the first page, to facilitate bug detection;
@@ -890,13 +890,21 @@ static void __devinit gpmc_mem_init(void)
if (!gpmc_cs_mem_enabled(cs))
continue;
gpmc_cs_get_memconf(cs, &base, &size);
- if (gpmc_cs_insert_mem(cs, base, size) < 0)
- BUG();
+ rc = gpmc_cs_insert_mem(cs, base, size);
+ if (IS_ERR_VALUE(rc)) {
+ while (--cs >= 0)
+ if (gpmc_cs_mem_enabled(cs))
+ gpmc_cs_delete_mem(cs);
+ return rc;
+ }
}
+
+ return 0;
}
static __devinit int gpmc_probe(struct platform_device *pdev)
{
+ int rc;
u32 l;
struct resource *res;
@@ -936,7 +944,13 @@ static __devinit int gpmc_probe(struct platform_device *pdev)
dev_info(gpmc_dev, "GPMC revision %d.%d\n", GPMC_REVISION_MAJOR(l),
GPMC_REVISION_MINOR(l));
- gpmc_mem_init();
+ rc = gpmc_mem_init();
+ if (IS_ERR_VALUE(rc)) {
+ clk_disable_unprepare(gpmc_l3_clk);
+ clk_put(gpmc_l3_clk);
+ dev_err(gpmc_dev, "failed to reserve memory\n");
+ return rc;
+ }
if (IS_ERR_VALUE(gpmc_setup_irq()))
dev_warn(gpmc_dev, "gpmc_setup_irq failed\n");
--
1.7.9.5
^ permalink raw reply related
* Re:
From: Shravan Mishra @ 2012-10-17 15:18 UTC (permalink / raw)
To: netdev
In-Reply-To: <CABNhDQxBMr37chpY_+y_KUh3P1ELDtOERpcn4s=Gy1OMJ2ZHVQ@mail.gmail.com>
On Wed, Oct 17, 2012 at 11:16 AM, Shravan Mishra
<shravan.mishra@gmail.com> wrote:
>
> Hi,
>
> Is there a way to simulate delayed acknowlegement such that in my packet
> trace I see it getting triggered.
>
> I'm using 3.2.31 linux kernel.
>
> I don't see any sysctl parameter for doing this.
>
> I checked HZ on my box using sysconf(_SC_CLK_TICK) it shows 100.
>
> Under tcp.h
>
> TCP_DELACK_MIN - HZ/25
>
> which means that my delayed ack timeout will be 40ms.
>
> How can I see this ?
>
> Currently I see tcp acks well within the above bounds.
>
>
> Sincerely
> Shravan
^ permalink raw reply
* [PATCHv3] ipv6: Enable enough of the code to handle GSO when disabled.
From: Vlad Yasevich @ 2012-10-17 15:46 UTC (permalink / raw)
To: netdev; +Cc: davem, Vlad Yasevich
Changes:
- Fix spelling in description
- Removed obsolete stub definition from ipv.h
When a guest using virtio is attempting to use IPv6 on a host where
the IPv6 module is administratively disabled, the tcp bulk transfer
rate drops down to 10kbps. The problem is that when IPv6 is disabled,
none of the protocol handlers are registered. When a guest attempts
to send an IPv6 packet with GSO (which is the default), this packet
is dropped by the host stack because there are no gso handlers
registered. A retransmit is triggered for every GSO packet thus
reducing the transfer rate.
This patch attempts to solve this by enabling just enough code so GSO
is correctly processed. However, I should point out that if IPv6 is
simply blacklisted or not built for the kernel, this problem will
still persist.
This problem also exists for AF_PACKET sockets, so it is not limited
to guests using virtio.
Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
---
include/linux/ipv6.h | 1 +
net/ipv6/af_inet6.c | 69 +++++++++++++++++++++++++++++++++++++++++++++---
net/ipv6/ip6_input.c | 5 +++
net/ipv6/reassembly.c | 11 +++++--
net/ipv6/tcp_ipv6.c | 9 +++++-
net/ipv6/udp.c | 6 +++-
6 files changed, 90 insertions(+), 11 deletions(-)
diff --git a/include/linux/ipv6.h b/include/linux/ipv6.h
index 0b94e91..1d5e061 100644
--- a/include/linux/ipv6.h
+++ b/include/linux/ipv6.h
@@ -176,6 +176,7 @@ struct ipv6_devconf {
};
struct ipv6_params {
+ __s32 disable_ipv6_mod;
__s32 disable_ipv6;
__s32 autoconf;
};
diff --git a/net/ipv6/af_inet6.c b/net/ipv6/af_inet6.c
index a974247..1fd0d73 100644
--- a/net/ipv6/af_inet6.c
+++ b/net/ipv6/af_inet6.c
@@ -74,13 +74,13 @@ static struct list_head inetsw6[SOCK_MAX];
static DEFINE_SPINLOCK(inetsw6_lock);
struct ipv6_params ipv6_defaults = {
+ .disable_ipv6_mod = 0,
.disable_ipv6 = 0,
.autoconf = 1,
};
-static int disable_ipv6_mod;
-module_param_named(disable, disable_ipv6_mod, int, 0444);
+module_param_named(disable, ipv6_defaults.disable_ipv6_mod, int, 0444);
MODULE_PARM_DESC(disable, "Disable IPv6 module such that it is non-functional");
module_param_named(disable_ipv6, ipv6_defaults.disable_ipv6, int, 0444);
@@ -1048,6 +1048,53 @@ static struct pernet_operations inet6_net_ops = {
.exit = inet6_net_exit,
};
+/* This function is called when IPv6 is administratively disabled.
+ * Its sole purpose is to set up enough of IPv6 that GSO/TSO will work
+ * for any outgoing IPv6 packets that may have been generated by
+ * guest or AF_PACKET sockets.
+ */
+static int inet6_init_disabled(void)
+{
+ int err = 0;
+
+ /* Init v6 extension headers. */
+ err = ipv6_exthdrs_init();
+ if (err)
+ goto out;
+
+ err = ipv6_frag_init();
+ if (err)
+ goto ipv6_frag_fail;
+
+ /* Init v6 transport protocols. UDP-light doesn't support GSO so
+ * it is omitted
+ */
+ err = udpv6_init();
+ if (err)
+ goto udpv6_fail;
+
+ err = tcpv6_init();
+ if (err)
+ goto tcpv6_fail;
+
+ err = ipv6_packet_init();
+ if (err)
+ goto ipv6_packet_fail;
+
+ return 0;
+
+ipv6_packet_fail:
+ tcpv6_exit();
+tcpv6_fail:
+ udpv6_exit();
+udpv6_fail:
+ ipv6_frag_exit();
+ipv6_frag_fail:
+ ipv6_exthdrs_exit();
+out:
+ return err;
+}
+
static int __init inet6_init(void)
{
struct sk_buff *dummy_skb;
@@ -1060,8 +1107,9 @@ static int __init inet6_init(void)
for (r = &inetsw6[0]; r < &inetsw6[SOCK_MAX]; ++r)
INIT_LIST_HEAD(r);
- if (disable_ipv6_mod) {
+ if (ipv6_defaults.disable_ipv6_mod) {
pr_info("Loaded, but administratively disabled, reboot required to enable\n");
+ err = inet6_init_disabled();
goto out;
}
@@ -1238,11 +1286,22 @@ out_unregister_tcp_proto:
}
module_init(inet6_init);
+static void __exit inet6_exit_disabled(void)
+{
+ ipv6_packet_cleanup();
+ ipv6_frag_exit();
+ ipv6_exthdrs_exit();
+ udpv6_exit();
+ tcpv6_exit();
+}
+
static void __exit inet6_exit(void)
{
- if (disable_ipv6_mod)
+ if (ipv6_defaults.disable_ipv6_mod) {
+ inet6_exit_disabled();
return;
-
+ }
+
/* First of all disallow new sockets creation. */
sock_unregister(PF_INET6);
/* Disallow any further netlink messages */
diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c
index a52d864..3e86ec3 100644
--- a/net/ipv6/ip6_input.c
+++ b/net/ipv6/ip6_input.c
@@ -74,6 +74,11 @@ int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt
return NET_RX_DROP;
}
+ if (ipv6_defaults.disable_ipv6_mod) {
+ kfree_skb(skb);
+ return NET_RX_DROP;
+ }
+
rcu_read_lock();
idev = __in6_dev_get(skb->dev);
diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index da8a4e3..71a0e61 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -705,6 +705,9 @@ int __init ipv6_frag_init(void)
if (ret)
goto out;
+ if (ipv6_defaults.disable_ipv6_mod)
+ goto out;
+
ret = ip6_frags_sysctl_register();
if (ret)
goto err_sysctl;
@@ -734,8 +737,10 @@ err_sysctl:
void ipv6_frag_exit(void)
{
- inet_frags_fini(&ip6_frags);
- ip6_frags_sysctl_unregister();
- unregister_pernet_subsys(&ip6_frags_ops);
+ if (!ipv6_defaults.disable_ipv6_mod) {
+ inet_frags_fini(&ip6_frags);
+ ip6_frags_sysctl_unregister();
+ unregister_pernet_subsys(&ip6_frags_ops);
+ }
inet6_del_protocol(&frag_protocol, IPPROTO_FRAGMENT);
}
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 49c8903..ebb297c 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -2109,6 +2109,9 @@ int __init tcpv6_init(void)
if (ret)
goto out;
+ if (ipv6_defaults.disable_ipv6_mod)
+ goto out;
+
/* register inet6 protocol */
ret = inet6_register_protosw(&tcpv6_protosw);
if (ret)
@@ -2129,7 +2132,9 @@ out_tcpv6_protosw:
void tcpv6_exit(void)
{
- unregister_pernet_subsys(&tcpv6_net_ops);
- inet6_unregister_protosw(&tcpv6_protosw);
+ if (!ipv6_defaults.disable_ipv6_mod) {
+ unregister_pernet_subsys(&tcpv6_net_ops);
+ inet6_unregister_protosw(&tcpv6_protosw);
+ }
inet6_del_protocol(&tcpv6_protocol, IPPROTO_TCP);
}
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index fc99972..2e8dddb 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1569,6 +1569,9 @@ int __init udpv6_init(void)
if (ret)
goto out;
+ if (ipv6_defaults.disable_ipv6_mod)
+ goto out;
+
ret = inet6_register_protosw(&udpv6_protosw);
if (ret)
goto out_udpv6_protocol;
@@ -1582,6 +1585,7 @@ out_udpv6_protocol:
void udpv6_exit(void)
{
- inet6_unregister_protosw(&udpv6_protosw);
+ if (!ipv6_defaults.disable_ipv6_mod)
+ inet6_unregister_protosw(&udpv6_protosw);
inet6_del_protocol(&udpv6_protocol, IPPROTO_UDP);
}
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH v0 3/4] cgroup: net_cls: Pass in task to sock_update_classid()
From: Daniel Wagner @ 2012-10-17 15:54 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Michael S. Tsirkin, Eric Dumazet,
Glauber Costa, Joe Perches, Neil Horman, Stanislav Kinsbursky,
Tejun Heo
In-Reply-To: <1350481041.26103.454.camel@edumazet-glaptop>
On 17.10.2012 15:37, Eric Dumazet wrote:
> On Wed, 2012-10-17 at 15:04 +0200, Daniel Wagner wrote:
>> From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
>>
>> sock_update_classid() assumes that the update operation always are
>> applied on the current task. sock_update_classid() needs to know on
>> which tasks to work on in order to be able to migrate task between
>> cgroups using the struct cgroup_subsys attach() callback.
>>
> ...
>
>>
>> -extern void sock_update_classid(struct sock *sk);
>> +extern void sock_update_classid(struct sock *sk, struct task_struct *task);
>>
>> #if IS_BUILTIN(CONFIG_NET_CLS_CGROUP)
>> static inline u32 task_cls_classid(struct task_struct *p)
>> diff --git a/net/core/sock.c b/net/core/sock.c
>> index 8a146cf..68c2f3b 100644
>> --- a/net/core/sock.c
>> +++ b/net/core/sock.c
>> @@ -1214,12 +1214,12 @@ static void sk_prot_free(struct proto *prot, struct sock *sk)
>>
>> #ifdef CONFIG_CGROUPS
>> #if IS_ENABLED(CONFIG_NET_CLS_CGROUP)
>> -void sock_update_classid(struct sock *sk)
>> +void sock_update_classid(struct sock *sk, struct task_struct *task)
>> {
>> u32 classid;
>>
>> rcu_read_lock(); /* doing current task, which cannot vanish. */
>> - classid = task_cls_classid(current);
>> + classid = task_cls_classid(task);
>> rcu_read_unlock();
>
>
> Comment is now misleading (since task might not be current) and
> rcu_read_lock()/rcu_read_unlock() protects nothing here, but avoid a
> lockdep splat...
>
> Hey task_cls_classid() has its own rcu protection since commit
> 3fb5a991916091a908d (cls_cgroup: Fix rcu lockdep warning)
>
> So we can safely revert Paul commit (1144182a8757f2a1)
> (We no longer need rcu_read_lock/unlock here)
Good point. Will update the series accordingly.
> (BTW net-next is not opened yet, its content outdated, although I like
> your patch series !)
I still have not figured all details on the patch submission procedure.
Sorry about that. The time to send patches for net-next will be annonced
by David, is this correct?
^ permalink raw reply
* Re: [PATCH v0 4/4] cgroup: net_cls: Rework update socket logic
From: Daniel Wagner @ 2012-10-17 15:56 UTC (permalink / raw)
To: John Fastabend
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, Li Zefan, David S. Miller, Michael S. Tsirkin,
Jamal Hadi Salim, Joe Perches, Neil Horman, Stanislav Kinsbursky,
Tejun Heo
In-Reply-To: <507EBA59.9080307-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
On 17.10.2012 16:02, John Fastabend wrote:
> On 10/17/2012 6:04 AM, Daniel Wagner wrote:
>> From: Daniel Wagner <daniel.wagner-98C5kh4wR6ohFhg+JK9F0w@public.gmane.org>
>>
>> The cgroup logic part of net_cls is very similar as the one in
>> net_prio. Let's stream line the net_cls logic with the net_prio one.
[...]
> This block should probably use iterate_fd() instead of open coding
> this. See the latest net_prio_attach().
Thanks for the heads up. Will update the patch accordingly.
^ permalink raw reply
* Re: [patch net] vlan: allow to change type when no vlan device is hooked on netdev
From: Jon Stanley @ 2012-10-17 16:06 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, fubar, andy, kaber
In-Reply-To: <1350473856-29380-1-git-send-email-jiri@resnulli.us>
On Wed, Oct 17, 2012 at 7:37 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> vlan_info might be present but still no vlan devices might be there.
> That is in case of vlan0 automatically added.
>
> So in that case, allow to change netdev type.
Confirmed to work, thanks!
^ permalink raw reply
* Re: [PATCHv3] ipv6: Enable enough of the code to handle GSO when disabled.
From: Eric Dumazet @ 2012-10-17 16:13 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, davem
In-Reply-To: <1350488802-24071-1-git-send-email-vyasevic@redhat.com>
On Wed, 2012-10-17 at 11:46 -0400, Vlad Yasevich wrote:
> This patch attempts to solve this by enabling just enough code so GSO
> is correctly processed. However, I should point out that if IPv6 is
> simply blacklisted or not built for the kernel, this problem will
> still persist.
So I guess this should be done in a different way ?
We currently use a single structure (struct packet_type) to hold
pointers to different methods. (The .func() field, and the gso/gro
stuff)
We probably need to split it in two parts, and make one part linked into
kernel, even if CONFIG_IPV6=n, so that GRO/GSO is fully IPv4/IPv6
functional.
By the way, do we really need a hash table for this ?
It seems we only have IPv4 (ETH_P_IP) and IPv6 (ETH_P_IPV6) to take care
of ?
This would remove some tests we currently have in GRO stack, and some
RCU stuff as well.
(GRO is slower if we have many af_packet sockets)
list_for_each_entry_rcu(ptype, head, list) {
if (ptype->type != type || ptype->dev || !ptype->gro_receive)
continue;
...
Adding a hook/test in ipv6_rcv() is ugly.
^ permalink raw reply
* Re: [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Tony Lindgren @ 2012-10-17 16:13 UTC (permalink / raw)
To: Jon Hunter
Cc: Richard Cochran, Afzal Mohammed, Russell King, Arnd Bergmann,
netdev, hvaibhav@ti.com, David Miller, linux-arm-kernel,
linux-omap@vger.kernel.org
In-Reply-To: <507EC395.7060409@ti.com>
* Jon Hunter <jon-hunter@ti.com> [121017 07:43]:
>
> On 10/16/2012 04:26 PM, Tony Lindgren wrote:
> > * Jon Hunter <jon-hunter@ti.com> [121016 14:00]:
> >> Hi Tony,
> >>
> >> On 10/16/2012 12:48 PM, Tony Lindgren wrote:
> >>> * Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
> >>>> From: hvaibhav@ti.com <hvaibhav@ti.com>
> >>>>
> >>>> With recent changes in omap gpmc driver code, in case of DT
> >>>> boot mode, where bootloader does not configure gpmc cs space
> >>>> will result into kernel BUG() inside gpmc_mem_init() function,
> >>>> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> >>>> gpmc_config7[0].baseaddress is set to '0' on reset.
> >>>>
> >>>> This use-case is applicable for any board/EVM which doesn't have
> >>>> any peripheral connected to gpmc cs0, for example BeagleXM and
> >>>> BeagleBone, so DT boot mode fails.
> >>>>
> >>>> This patch adds of_have_populated_dt() check before creating
> >>>> device, so that for DT boot mode, gpmc probe will not be called
> >>>> which is expected behavior, as gpmc is not supported yet from DT.
> >>>
> >>> I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
> >>>
> >>> Next time, please also cc linux-omap@vger.kernel.org for series
> >>> like this. I'm sure the people reading the omap list are interested
> >>> in these.
> >>
> >> This patch appears to be masking an underlying issue. How about
> >> something like the following ...
> >
> > OK that looks good to me. I'll drop the earlier fix and use
> > yours instead.
>
> Hi Tony, sorry but I realised now that in my patch that I need to
> take care of releasing and memory and clocks that were acquired
> during the probe. Here is a V2. If you prefer I can create a delta
> patch also with the previous.
OK thanks I'll update it.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH v0 3/4] cgroup: net_cls: Pass in task to sock_update_classid()
From: Eric Dumazet @ 2012-10-17 16:15 UTC (permalink / raw)
To: Daniel Wagner
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, cgroups-u79uwXL29TY76Z2rM5mHXA,
Daniel Wagner, David S. Miller, Michael S. Tsirkin, Eric Dumazet,
Glauber Costa, Joe Perches, Neil Horman, Stanislav Kinsbursky,
Tejun Heo
In-Reply-To: <507ED4C0.7070408-kQCPcA+X3s7YtjvyW6yDsg@public.gmane.org>
On Wed, 2012-10-17 at 17:54 +0200, Daniel Wagner wrote:
> I still have not figured all details on the patch submission procedure.
> Sorry about that. The time to send patches for net-next will be annonced
> by David, is this correct?
>
Exactly. David sent a mail yesterday :
On Mon, 2012-10-15 at 23:19 -0400, David Miller wrote:
> Please stop sending feature patches and cleanups.
>
> I'll be sure to let the list know when net-next is
> ready for submissions again, thanks.
>
> Thank you.
> --
^ permalink raw reply
* Question about Mellanox FW reporting (incorrect) port types
From: Marcelo Ricardo Leitner @ 2012-10-17 16:27 UTC (permalink / raw)
To: netdev; +Cc: Or Gerlitz, Doug Ledford
Hi there,
We have a customer that is having issues bringing the 1st port up after
upgrading RHEL. You may somewhat ignore the 6.2/6.3, just consider it as
"old" and "new" please. The thing is:
- RHEL 6.2 works with warnings, it brings both ports up as ETH, as
expected, just dmesg that gives repeated:
mlx4_core 0000:05:00.0: Requested port type for port 1 is not supported
on this HCA
- RHEL 6.3 doesn't, it brings only the 2nd port up
The 1st one is tagged as IB, checked via /sys/.../mxl4_port1
NIC:
05:00.0 Network controller: Mellanox Technologies MT26438 [ConnectX VPI
PCIe 2.0 5GT/s - IB QDR / 10GigE Virtualization+] (rev b0)
05:00.0 0280: 15b3:6746 (rev b0)
Issue seen at 14 servers, different firmware revisions, including at
least 2.8.0 and 2.7.9294. We couldn't reproduce it, while using 2.7.9100.
To narrow down, I placed a debug msg at mlx4_QUERY_DEV_CAP() at 6.3 kernel:
for (i = 1; i <= dev_cap->num_ports; ++i) {
err = mlx4_cmd_box(dev, 0, mailbox->dma, i, 0,
MLX4_CMD_QUERY_PORT,
MLX4_CMD_TIME_CLASS_B,
!mlx4_is_slave(dev));
if (err)
goto out;
MLX4_GET(field, outbox, QUERY_PORT_SUPPORTED_TYPE_OFFSET);
dev_cap->supported_port_types[i] = field & 3;
dev_cap->suggested_type[i] = (field >> 3) & 1;
dev_cap->default_sense[i] = (field >> 4) & 1;
...
mlx4_dbg(dev, "Port %d type flags: %x %x %x\n", i,
dev_cap->supported_port_types[i],
dev_cap->suggested_type[i],
dev_cap->default_sense[i]);
}
This gave us:
[ 12.368187] mlx4_core 0000:05:00.0: Port 1 type flags: 1 0 0
[ 12.378232] mlx4_core 0000:05:00.0: Port 2 type flags: 2 0 0
And that's mapped to:
enum mlx4_port_type {
MLX4_PORT_TYPE_NONE = 0,
MLX4_PORT_TYPE_IB = 1,
MLX4_PORT_TYPE_ETH = 2,
MLX4_PORT_TYPE_AUTO = 3
};
So actually seems that the new driver is doing just as expected. It is
honoring what firmware is saying.
Then I checked why previous driver worked. It seems to me (now based
only on code review) that it was because of this forced sense, which was
removed in 6.3, which integrated this commit:
commit 8d0fc7b61191c9433a4f738987b89e1d962eb637
Author: Yevgeny Petrilin <yevgenyp@mellanox.co.il>
Date: Mon Dec 19 04:00:34 2011 +0000
mlx4_core: Changing link sensing logic
has the chunk:
@@ -1329,12 +1353,6 @@ static int mlx4_setup_hca(struct mlx4_dev *dev)
if (!mlx4_is_slave(dev)) {
for (port = 1; port <= dev->caps.num_ports; port++) {
- if (!mlx4_is_mfunc(dev)) {
- enum mlx4_port_type port_type = 0;
- mlx4_SENSE_PORT(dev, port, &port_type);
- if (port_type)
- dev->caps.port_type[port] =
port_type;
- }
ib_port_default_caps = 0;
err = mlx4_get_port_ib_caps(dev, port,
This code would allow changing the port type to ETH, as it was executed
after the query cap and it didn't check for supported_types before setting.
So my questions are: is it possible to the firmware report a wrong port
type like that? Is it somehow configurable by sysadmin (via fw update,
..), can we flip that byte or is it a manufacturing issue?
Any other info needed? I can't try upstream driver, but I can
cherry-pick some changes if needed/recommended.
dmesg snippet for 6.3 with debugs:
[ 10.573469] mlx4_core 0000:05:00.0: PCI INT A -> GSI 26 (level, low)
-> IRQ 26
[ 10.573509] mlx4_core 0000:05:00.0: setting latency timer to 64
[ 11.593401] mlx4_core 0000:05:00.0: FW version 2.8.000 (cmd intf rev
3), max commands 16
[ 11.606423] mlx4_core 0000:05:00.0: Catastrophic error buffer at
0x1f020, size 0x10, BAR 0
[ 11.619459] mlx4_core 0000:05:00.0: Communication vector bar:2
offset:0x800
[ 11.631071] mlx4_core 0000:05:00.0: FW size 385 KB
[ 11.640232] mlx4_core 0000:05:00.0: Clear int @ 1000, BAR 2
[ 11.651984] mlx4_core 0000:05:00.0: Mapped 26 chunks/6168 KB for FW.
[ 12.355826] mlx4_core 0000:05:00.0: BlueFlame available (reg size
512, regs/page 8)
[ 12.368187] mlx4_core 0000:05:00.0: Port 1 type flags: 1 0 0
[ 12.378232] mlx4_core 0000:05:00.0: Port 2 type flags: 2 0 0
[ 12.388158] mlx4_core 0000:05:00.0: Base MM extensions: flags
00000cc0, rsvd L_Key 00000500
[ 12.401071] mlx4_core 0000:05:00.0: Max ICM size 4294967296 MB
[ 12.411183] mlx4_core 0000:05:00.0: Max QPs: 16777216, reserved QPs:
64, entry size: 256
[ 12.423786] mlx4_core 0000:05:00.0: Max SRQs: 16777216, reserved
SRQs: 64, entry size: 128
[ 12.436568] mlx4_core 0000:05:00.0: Max CQs: 16777216, reserved CQs:
128, entry size: 128
[ 12.449241] mlx4_core 0000:05:00.0: Max EQs: 512, reserved EQs: 8,
entry size: 128
[ 12.461221] mlx4_core 0000:05:00.0: reserved MPTs: 16, reserved MTTs: 16
[ 12.472270] mlx4_core 0000:05:00.0: Max PDs: 8388608, reserved PDs:
4, reserved UARs: 2
[ 12.484711] mlx4_core 0000:05:00.0: Max QP/MCG: 8388608, reserved MGMs: 0
[ 12.495786] mlx4_core 0000:05:00.0: Max CQEs: 4194304, max WQEs:
16384, max SRQ WQEs: 16384
[ 12.508587] mlx4_core 0000:05:00.0: Local CA ACK delay: 15, max MTU:
4096, port width cap: 3
[ 12.521485] mlx4_core 0000:05:00.0: Max SQ desc size: 1008, max SQ
S/G: 62
[ 12.532639] mlx4_core 0000:05:00.0: Max RQ desc size: 512, max RQ S/G: 32
[ 12.543651] mlx4_core 0000:05:00.0: Max GSO size: 131072
[ 12.552996] mlx4_core 0000:05:00.0: Max counters: 256
[ 12.561998] mlx4_core 0000:05:00.0: DEV_CAP flags:
[ 12.570660] mlx4_core 0000:05:00.0: RC transport
[ 12.570661] mlx4_core 0000:05:00.0: UC transport
[ 12.570662] mlx4_core 0000:05:00.0: UD transport
[ 12.570662] mlx4_core 0000:05:00.0: XRC transport
[ 12.570663] mlx4_core 0000:05:00.0: FCoIB support
[ 12.570664] mlx4_core 0000:05:00.0: SRQ support
[ 12.570665] mlx4_core 0000:05:00.0: IPoIB checksum offload
[ 12.570666] mlx4_core 0000:05:00.0: P_Key violation counter
[ 12.570667] mlx4_core 0000:05:00.0: Q_Key violation counter
[ 12.570667] mlx4_core 0000:05:00.0: DPDP
[ 12.570668] mlx4_core 0000:05:00.0: Big LSO headers
[ 12.570669] mlx4_core 0000:05:00.0: APM support
[ 12.570670] mlx4_core 0000:05:00.0: Atomic ops support
[ 12.570671] mlx4_core 0000:05:00.0: Address vector port checking
support
[ 12.570672] mlx4_core 0000:05:00.0: UD multicast support
[ 12.570672] mlx4_core 0000:05:00.0: Router support
[ 12.570673] mlx4_core 0000:05:00.0: IBoE support
[ 12.570674] mlx4_core 0000:05:00.0: Unicast loopback support
[ 12.570675] mlx4_core 0000:05:00.0: Wake On LAN support
[ 12.570676] mlx4_core 0000:05:00.0: UDP RSS support
[ 12.570676] mlx4_core 0000:05:00.0: Unicast VEP steering support
[ 12.570677] mlx4_core 0000:05:00.0: Multicast VEP steering support
[ 12.570678] mlx4_core 0000:05:00.0: Counters support
[ 12.570680] mlx4_core 0000:05:00.0: Initial port 1 type: 1,
port_type_array[0]=0 <-- (this is log of mine too)
[ 12.570681] mlx4_core 0000:05:00.0: Sense allowed for port 1: 0
[ 12.570682] mlx4_core 0000:05:00.0: Initial port 2 type: 2,
port_type_array[1]=0
[ 12.570683] mlx4_core 0000:05:00.0: Sense allowed for port 2: 0
[ 12.570686] mlx4_core 0000:05:00.0: profile[ 0] ( CMPT): 2^26
entries @ 0x 0, size 0x 100000000
[ 12.570687] mlx4_core 0000:05:00.0: profile[ 1] (RDMARC): 2^22
entries @ 0x 100000000, size 0x 8000000
[ 12.570689] mlx4_core 0000:05:00.0: profile[ 2] ( QP): 2^18
entries @ 0x 108000000, size 0x 4000000
[ 12.570690] mlx4_core 0000:05:00.0: profile[ 3] ( MTT): 2^23
entries @ 0x 10c000000, size 0x 4000000
[ 12.570691] mlx4_core 0000:05:00.0: profile[ 4] ( DMPT): 2^19
entries @ 0x 110000000, size 0x 2000000
[ 12.570693] mlx4_core 0000:05:00.0: profile[ 5] ( ALTC): 2^18
entries @ 0x 112000000, size 0x 1000000
[ 12.570694] mlx4_core 0000:05:00.0: profile[ 6] ( SRQ): 2^16
entries @ 0x 113000000, size 0x 800000
[ 12.570696] mlx4_core 0000:05:00.0: profile[ 7] ( CQ): 2^16
entries @ 0x 113800000, size 0x 800000
[ 12.570697] mlx4_core 0000:05:00.0: profile[ 8] ( MCG): 2^13
entries @ 0x 114000000, size 0x 800000
[ 12.570699] mlx4_core 0000:05:00.0: profile[ 9] ( AUXC): 2^18
entries @ 0x 114800000, size 0x 40000
[ 12.570701] mlx4_core 0000:05:00.0: profile[10] ( EQ): 2^06
entries @ 0x 114840000, size 0x 2000
[ 12.570702] mlx4_core 0000:05:00.0: HCA context memory: reserving
4530440 KB
[ 12.570722] mlx4_core 0000:05:00.0: 4530440 KB of HCA context
requires 8936 KB aux memory.
[ 12.599185] mlx4_core 0000:05:00.0: Mapped 38 chunks/8936 KB for ICM aux.
[ 12.600516] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at 0 for ICM.
[ 12.601811] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
40000000 for ICM.
[ 12.603105] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
80000000 for ICM.
[ 12.603139] mlx4_core 0000:05:00.0: Mapped 1 chunks/4 KB at c0000000
for ICM.
[ 12.603192] mlx4_core 0000:05:00.0: Mapped 1 chunks/8 KB at 114840000
for ICM.
[ 12.604464] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
10c000000 for ICM.
[ 12.605772] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
110000000 for ICM.
[ 12.607047] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
108000000 for ICM.
[ 12.608324] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114800000 for ICM.
[ 12.609600] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
112000000 for ICM.
[ 12.610875] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
100000000 for ICM.
[ 12.612146] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
113800000 for ICM.
[ 12.613419] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
113000000 for ICM.
[ 12.614693] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114000000 for ICM.
[ 12.615966] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114040000 for ICM.
[ 12.617240] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114080000 for ICM.
[ 12.618512] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
1140c0000 for ICM.
[ 12.619787] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114100000 for ICM.
[ 12.621061] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114140000 for ICM.
[ 12.622334] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114180000 for ICM.
[ 12.623603] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
1141c0000 for ICM.
[ 12.624880] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114200000 for ICM.
[ 12.626154] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114240000 for ICM.
[ 12.627426] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114280000 for ICM.
[ 12.628699] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
1142c0000 for ICM.
[ 12.629974] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114300000 for ICM.
[ 12.631247] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114340000 for ICM.
[ 12.632521] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114380000 for ICM.
[ 12.633793] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
1143c0000 for ICM.
[ 12.635069] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114400000 for ICM.
[ 12.636342] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114440000 for ICM.
[ 12.637616] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114480000 for ICM.
[ 12.638890] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
1144c0000 for ICM.
[ 12.640162] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114500000 for ICM.
[ 12.641435] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114540000 for ICM.
[ 12.642714] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114580000 for ICM.
[ 12.643989] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
1145c0000 for ICM.
[ 12.645265] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114600000 for ICM.
[ 12.646536] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114640000 for ICM.
[ 12.647807] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114680000 for ICM.
[ 12.649082] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
1146c0000 for ICM.
[ 12.650354] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114700000 for ICM.
[ 12.651628] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114740000 for ICM.
[ 12.652902] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
114780000 for ICM.
[ 12.654177] mlx4_core 0000:05:00.0: Mapped 1 chunks/256 KB at
1147c0000 for ICM.
... irq allocs ...
[ 13.222583] mlx4_core 0000:05:00.0: irq 128 for MSI/MSI-X
[ 13.602288] mlx4_core 0000:05:00.0: NOP command IRQ test passed
[ 13.653457] mlx4_en: Mellanox ConnectX HCA Ethernet driver v2.0 (Dec
2011)
[ 13.662601] mlx4_en 0000:05:00.0: Activating port:2
[ 13.669411] mlx4_en: 0000:05:00.0: Port 2: Using 8 TX rings
[ 13.676497] mlx4_en: 0000:05:00.0: Port 2: Using 8 RX rings
[ 13.683772] mlx4_en: 0000:05:00.0: Port 2: Initializing port
[ 13.731168] mlx4_ib: Mellanox ConnectX InfiniBand driver v1.0 (April
4, 2008)
Previous kernel (I don't have it with debugs):
mlx4_core 0000:05:00.0: irq 105 for MSI/MSI-X
mlx4_en: Mellanox ConnectX HCA Ethernet driver v1.5.4.1 (March 2011)
mlx4_en 0000:05:00.0: Activating port:1
mlx4_en: 0000:05:00.0: Port 1: Using 8 TX rings
mlx4_en: 0000:05:00.0: Port 1: Using 8 RX rings
mlx4_en: 0000:05:00.0: Port 1: Initializing port
mlx4_en 0000:05:00.0: Activating port:2
mlx4_en: 0000:05:00.0: Port 2: Using 8 TX rings
mlx4_en: 0000:05:00.0: Port 2: Using 8 RX rings
mlx4_en: 0000:05:00.0: Port 2: Initializing port
Same host, same nic, just rebooted.
Thanks,
Marcelo.
^ permalink raw reply
* Re: [PATCHv3] ipv6: Enable enough of the code to handle GSO when disabled.
From: Ben Hutchings @ 2012-10-17 16:50 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Vlad Yasevich, netdev, davem
In-Reply-To: <1350490397.26103.647.camel@edumazet-glaptop>
On Wed, 2012-10-17 at 18:13 +0200, Eric Dumazet wrote:
> On Wed, 2012-10-17 at 11:46 -0400, Vlad Yasevich wrote:
>
> > This patch attempts to solve this by enabling just enough code so GSO
> > is correctly processed. However, I should point out that if IPv6 is
> > simply blacklisted or not built for the kernel, this problem will
> > still persist.
>
> So I guess this should be done in a different way ?
>
> We currently use a single structure (struct packet_type) to hold
> pointers to different methods. (The .func() field, and the gso/gro
> stuff)
>
> We probably need to split it in two parts, and make one part linked into
> kernel, even if CONFIG_IPV6=n, so that GRO/GSO is fully IPv4/IPv6
> functional.
[...]
Either that or make sure that we don't advertise IPv6 GSO when IPv6 is
disabled.
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] qla3xxx: Ensure req_q_phy_addr writes to the register
From: Jitendra Kalsaria @ 2012-10-17 17:45 UTC (permalink / raw)
To: Joe Jin, Ron Mercer, Dept-Eng Linux Driver
Cc: netdev, linux-kernel, Greg Marsden
In-Reply-To: <507E50E5.5040201@oracle.com>
>-----Original Message-----
>From: Joe Jin [mailto:joe.jin@oracle.com]
>Sent: Tuesday, October 16, 2012 11:32 PM
>To: Ron Mercer; Jitendra Kalsaria; Dept-Eng Linux Driver
>Cc: netdev; linux-kernel; Greg Marsden
>Subject: [PATCH] qla3xxx: Ensure req_q_phy_addr writes to the register
>
>Make sure req_q_phy_addr write to the register.
>
>Signed-off-by: Joe Jin <joe.jin@oracle.com>
>Cc: Ron Mercer <ron.mercer@qlogic.com>
>Cc: Jitendra Kalsaria <jitendra.kalsaria@qlogic.com>
>---
> drivers/net/ethernet/qlogic/qla3xxx.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
>diff --git a/drivers/net/ethernet/qlogic/qla3xxx.c b/drivers/net/ethernet/qlogic/qla3xxx.c
>index df09b1c..78b4cba 100644
>--- a/drivers/net/ethernet/qlogic/qla3xxx.c
>+++ b/drivers/net/ethernet/qlogic/qla3xxx.c
>@@ -2525,6 +2525,12 @@ static int ql_alloc_net_req_rsp_queues(struct ql3_adapter *qdev)
> qdev->req_q_size =
> (u32) (NUM_REQ_Q_ENTRIES * sizeof(struct ob_mac_iocb_req));
>
>+ /*
>+ * The barrier is required to ensure that req_q_phy_addr writes to
>+ * the memory.
>+ */
>+ wmb();
>+
> qdev->req_q_virt_addr =
> pci_alloc_consistent(qdev->pdev,
> (size_t) qdev->req_q_size,
Your changes only take care of request queue but not response queue which also need barrier.
qdev->req_q_size =
(u32) (NUM_REQ_Q_ENTRIES * sizeof(struct ob_mac_iocb_req));
qdev->rsp_q_size = NUM_RSP_Q_ENTRIES * sizeof(struct net_rsp_iocb);
wmb();
thanks,
Jiten
--
1.7.11.7
^ permalink raw reply
* Re: [PATCH] SUNRPC: Prevent kernel stack corruption on long values of flush
From: Sasha Levin @ 2012-10-17 17:59 UTC (permalink / raw)
To: J. Bruce Fields
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, davej-H+wXaHxf7aLQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120718173913.GA1298-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>
On Wed, Jul 18, 2012 at 1:39 PM, J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:
> On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
>> The buffer size in read_flush() is too small for the longest possible values
>> for it. This can lead to a kernel stack corruption:
>
> Thanks!
I've just stumbled on this crash again, and noticed that this patch
never made it in.
Was it just a mixup, or is something still missing?
Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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 V2 0/7] support the cpts found on am335x devices
From: Richard Cochran @ 2012-10-17 18:27 UTC (permalink / raw)
To: N, Mugunthan V
Cc: netdev@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
David Miller, Chemparathy, Cyril, Govindarajan, Sriramakrishnan
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9F86E9@DBDE01.ent.ti.com>
On Tue, Oct 16, 2012 at 11:11:29PM +0000, N, Mugunthan V wrote:
>
> Yes, I do agree that driver handles it. As Half roll over and Full roll
> over events are not handled in the driver, I am just curious how will
> the misaligned TS would be handled and also in cpts set time, the Lower
> 32 bit time is written to CPTS counter
#include <linux/clocksource.h>
> Since we poll for the 32bit over flow for every HZ * 8 cycle, won't
> there be a system overhead. If the CPTS ref clock is changed according
> to the ptp freq adjust api, how will the timecounter take care of change
> in frequency
There is nothing to do here. What are you asking?
> The current driver which is in vanilla kernel doesn't use extended slave
> address which are conflict between TI814x CPSW IP version and AM335x CPSW
> IP version. I have just posted my version of CPTS implementation. May be
> we can work together make the driver compatible with both CPSW versions
Okay.
> Since CPSW is a 3port Switch we should not fix time stamping will be enabled
> only for slave 0 or passing slave number through DT. Its better if we
> can configure both the slaves. This can be tested with EVM-sk which has
> both the slave ports pinned out.
I hope that you meant, "better if we can configure _either_ slave."
Considering how SO_TIMESTAMPING works, you can't use both at once.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] SUNRPC: Prevent kernel stack corruption on long values of flush
From: Boaz Harrosh @ 2012-10-17 18:29 UTC (permalink / raw)
To: Jim Rees
Cc: Dave Jones, J. Bruce Fields, Sasha Levin,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120718205510.GA18374-63aXycvo3TyHXe+LvDLADg@public.gmane.org>
On 07/18/2012 01:55 PM, Jim Rees wrote:
> Dave Jones wrote:
>
>
> Unsigned long isn't necessarily 32 bits.
> On 64-bit systems %lu can be up to 18446744073709551615
>
> Thanks. You caught me thinking "Intel." How embarrassing.
What? why even on Intel-64 long is 64bit. long is always the
same or bigger then a pointer (A pointer must always fit
in a long)
On the other hand int is 32bit in Intel-64 unlike some
other CPUs where int(s) may get to be 64bit as well.
Cheers
Boaz
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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] SUNRPC: Prevent kernel stack corruption on long values of flush
From: J. Bruce Fields @ 2012-10-17 19:02 UTC (permalink / raw)
To: Sasha Levin
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, davej-H+wXaHxf7aLQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CA+1xoqcgWTP8pAY3Ok2R0JM-ZXSkGroEvAFcqP0KaK=dABiTXA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Wed, Oct 17, 2012 at 01:59:39PM -0400, Sasha Levin wrote:
> On Wed, Jul 18, 2012 at 1:39 PM, J. Bruce Fields <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org> wrote:
> > On Tue, Jul 17, 2012 at 12:01:26AM +0200, Sasha Levin wrote:
> >> The buffer size in read_flush() is too small for the longest possible values
> >> for it. This can lead to a kernel stack corruption:
> >
> > Thanks!
>
> I've just stumbled on this crash again, and noticed that this patch
> never made it in.
>
> Was it just a mixup, or is something still missing?
Oh, man, I guess I got distracted by the subsequent base10len()
discussion.
Added to my for-3.7 branch, I'll push that out after some tests and
hopefully send in a pull request tomorrow.
Thanks for noticing the ommission.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" 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: [PATCHv3] ipv6: Enable enough of the code to handle GSO when disabled.
From: Vlad Yasevich @ 2012-10-17 19:03 UTC (permalink / raw)
To: Ben Hutchings; +Cc: Eric Dumazet, netdev, davem
In-Reply-To: <1350492636.2884.5.camel@bwh-desktop.uk.solarflarecom.com>
On 10/17/2012 12:50 PM, Ben Hutchings wrote:
> On Wed, 2012-10-17 at 18:13 +0200, Eric Dumazet wrote:
>> On Wed, 2012-10-17 at 11:46 -0400, Vlad Yasevich wrote:
>>
>>> This patch attempts to solve this by enabling just enough code so GSO
>>> is correctly processed. However, I should point out that if IPv6 is
>>> simply blacklisted or not built for the kernel, this problem will
>>> still persist.
>>
>> So I guess this should be done in a different way ?
>>
>> We currently use a single structure (struct packet_type) to hold
>> pointers to different methods. (The .func() field, and the gso/gro
>> stuff)
>>
>> We probably need to split it in two parts, and make one part linked into
>> kernel, even if CONFIG_IPV6=n, so that GRO/GSO is fully IPv4/IPv6
>> functional.
> [...]
>
> Either that or make sure that we don't advertise IPv6 GSO when IPv6 is
> disabled.
>
> Ben.
>
this becomes a problem when migration or save/restore is used. since
offload features may be different between systesm, we may not be able to
migrate.
-vlad
^ permalink raw reply
* Re: [PATCHv3] ipv6: Enable enough of the code to handle GSO when disabled.
From: Vlad Yasevich @ 2012-10-17 19:11 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, davem
In-Reply-To: <1350490397.26103.647.camel@edumazet-glaptop>
On 10/17/2012 12:13 PM, Eric Dumazet wrote:
> On Wed, 2012-10-17 at 11:46 -0400, Vlad Yasevich wrote:
>
>> This patch attempts to solve this by enabling just enough code so GSO
>> is correctly processed. However, I should point out that if IPv6 is
>> simply blacklisted or not built for the kernel, this problem will
>> still persist.
>
> So I guess this should be done in a different way ?
>
> We currently use a single structure (struct packet_type) to hold
> pointers to different methods. (The .func() field, and the gso/gro
> stuff)
>
> We probably need to split it in two parts, and make one part linked into
> kernel, even if CONFIG_IPV6=n, so that GRO/GSO is fully IPv4/IPv6
> functional.
The thing about this approach is that if there are any other protocols
that could have to provide their own segmentation functionality, such
functionality would always have to be part of the kernel. I wasn't sure
how much I liked that.
>
> By the way, do we really need a hash table for this ?
> It seems we only have IPv4 (ETH_P_IP) and IPv6 (ETH_P_IPV6) to take care
> of ?
Which hash are you talking about? I didn't add any hashes.
>
> This would remove some tests we currently have in GRO stack, and some
> RCU stuff as well.
> (GRO is slower if we have many af_packet sockets)
>
> list_for_each_entry_rcu(ptype, head, list) {
> if (ptype->type != type || ptype->dev || !ptype->gro_receive)
> continue;
> ...
>
> Adding a hook/test in ipv6_rcv() is ugly.
>
There already is one for device. I original had a stub ipv6_rcv that
just dropped the packet. I could resurrect that if that's better...
-vlad
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv5 1/4] modem_shm: Add Modem Access Framework
From: Greg KH @ 2012-10-17 19:15 UTC (permalink / raw)
To: Arun MURTHY
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
linux-doc@vger.kernel.org, alan@lxorguk.ukuu.org.uk
In-Reply-To: <F45880696056844FA6A73F415B568C695B9C5CECE3@EXDCVYMBSTM006.EQ1STM.local>
On Wed, Oct 17, 2012 at 10:00:10AM +0200, Arun MURTHY wrote:
> > On Mon, Oct 15, 2012 at 10:58:37AM +0530, Arun Murthy wrote:
> >
> > I'm going to ignore your .c logic, as there are things in it that I don't think is
> > correct. But it all comes down to your data structures, if you fix them, then
> > the .c logic will become correct:
You still aren't understanding what I am trying to say here.
So, one final try...
> > > +
> > > +#include <linux/device.h>
> > > +
> > > +struct clients {
> > > + struct device *dev;
> >
> > Why is this a pointer? It should be embedded in the structure.
>
> This is the pointer to the clients's device structure. There will be a
> single entity for a modem but multiple clients. Hence this struct is
> specific for each client.
But each "client" should be a device, so embed it in the structure.
> > > + atomic_t cnt;
> >
> > Why is this needed at all? And if it's needed, why is it an atomic?
> > (hint, your use of atomic_t really isn't correct at all in this patch, it's not doing
> > what you think it is doing...)
>
> Basically the operation done by this, i.e modem access/release has a lot of
> affect on the clients. Since we are accesing some modem registers without
> this modem request it might lead to system freeze. Hence such cross over
> scenarios are considered and the counter is increased/decreased after the
> operation(modem access/release). And reading of these variable are done
> especially during system suspend, where decision is taken based on the value
> of the counter read, hence any modification done should preside over read.
> Moreover since there are multiple clients, using atomic for a simple locking
> mechanism.
Hint, if you _ever_ say, "I'll use an atomic_t as a simple lock", you
are usually wrong. But sometimes it can be done right. So I went and
re-read your implementation.
You got it wrong.
So don't do this.
Seriously, an atomic value is not a lock, and, as you used it, it
doesn't even work properly. So don't try to roll your own lock, either
use a lock, or use the built-in-reference-counting of the driver core,
which is what I keep saying here.
I'll say it again, don't do this. Use the build-in reference count of
the struct device, that the kernel can manage for you, to handle this.
It will do it correctly, simply, and make your life a whole lot easier,
and better yet, will allow me to accept this code.
As it is, it is broken and wrong and quite buggy.
Please use the driver core properly. I know it can be difficult, and
isn't the best documented body of code. But it works, and works well,
and when people try to work around it thinking they don't need it, or
will just roll their own logic instead, they get it wrong and it causes
problems. Just like this implementation shows.
So please, go back, consult with others on your team about how to do
this right.
If you have specific questions about the driver core that I can answer,
after you have read a few users of it (look at the bus code from
something "simple" for how to do this, don't look at USB) I will be glad
to help out. But I feel that the previous review comments I have made
in this area, have been totally ignored, so I'm loath to try to do the
design work for you here. You need to work it out so you feel
comfortable with it, not me.
good luck,
greg k-h
p.s. I'm sure your company/team/coworkers can help review your patches,
right? Please run them by someone else first, that would have caught
the locking/atomic_t issue immediately.
^ permalink raw reply
* Re: Question about Mellanox FW reporting (incorrect) port types
From: Or Gerlitz @ 2012-10-17 19:22 UTC (permalink / raw)
To: Marcelo Ricardo Leitner, Yevgeny Petrilin
Cc: netdev, Or Gerlitz, Doug Ledford, Yishai Hadas
In-Reply-To: <507EDC5D.4070602@redhat.com>
Marcelo Ricardo Leitner <mleitner@redhat.com> wrote:
>
> [...] So my questions are: is it possible to the firmware report a wrong port type like
> that? Is it somehow configurable by sysadmin (via fw update, ..), can we flip that byte
> or is it a manufacturing issue?
I'm not sure, Yevgeny/Yishai do you have any insights here?
> I can't try upstream driver
why?! netdev is dealing with upstream, isn't it?
Or.
^ 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