* Re: [GIT PULL v2] Open vSwitch
From: Jamal Hadi Salim @ 2011-11-23 13:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Herbert Xu, David Miller, jesse, netdev, dev
In-Reply-To: <1322052938.17693.9.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, 2011-11-23 at 13:55 +0100, Eric Dumazet wrote:
> Currently thinking about it. I was also waiting Tom Herbert BQL patches.
Excellent. I can test when you have something.
> Several people are interested, and John Fastabend told me he plans to :
>
> (1) rcu'ify classifiers/actions as needed
Makes sense in most cases. If you have a lot of flow setup/teardown
it may harm.
Another one - but dont see how much you can do about this; useful
when you want to share state (eg multiple flows being policed
by a single rate meter);
An action could be shared across multiple policies i.e you can
have:
match1, action foo instance 1, action bar instance 3
match2, action bar instance3
match3, ....
This could would mean a lock contended across cpus when different
flows hitting match1/2 show up on different cpus.
> (2) add flag to drop qdisc lock on simple or hw qdiscs
Where does config for the hardware happen from?
> (3) mq and mqprio call root qdisc and run a pass over classifiers
> actions possibly resetting queue_mapping.
It seems to make sense - but I will wait and see to have better
understanding.
cheers,
jamal
^ permalink raw reply
* AWARD NOTICE
From: VITTORIO FOUNDATION @ 2011-11-23 12:09 UTC (permalink / raw)
To: Recipients
You have been awarded $100,000,000.00 among the 5 beneficiaries from the Vittorio Foundation.Qualification numbers (P-333-7858,B-011-67)
Email:{vittoriofoundation1@hotmail.com}
Mr. Jennifer David
^ permalink raw reply
* Re: [PATCH 1/2] ax25: integer overflows in ax25_setsockopt()
From: Xi Wang @ 2011-11-23 14:04 UTC (permalink / raw)
To: Alan Cox
Cc: linux-kernel, Joerg Reuter, Ralf Baechle, David Miller,
linux-hams, netdev
In-Reply-To: <20111123104449.5e845a0f@lxorguk.ukuu.org.uk>
All these magic numbers come from net/ax25/sysctl_net_ax25.c, where
min/max values of each field are set for sysctl. Is it okay to use
them?
- xi
On Wed, Nov 23, 2011 at 5:44 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>> case AX25_T1:
>> - if (opt < 1) {
>> + if (opt < 1 || opt > 30) {
>
> Where do these values come from ? If they are from some 'standard' then
> really we should avoid restricting needlessly to it, particularly as
> AX.25 isn't well defined and is used for all sorts of crazy stuff where
> the usual range of settings isn't useful.
>
> Restricting to the point it would overflow makes sense however.
>
> Alan
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-hams" 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
* [PATCH] b44.c Use dev_kfree_skb_irq() in b44_tx()
From: Xander Hover @ 2011-11-23 13:56 UTC (permalink / raw)
To: peter.p.waskiewicz.jr; +Cc: zambrano, linux-kernel, netdev, Xander Hover
In-Reply-To: <Re: softirq oops from b44_poll>
Reported issues when using dev_kfree_skb() on UP systems and
systems with low numbers of cores. dev_kfree_skb_irq() will
properly save IRQ state before freeing the skb.
Tested on 3.1.1 and 3.2_rc2
Example of reproducible trace of kernel 3.1.1
------------[ cut here ]------------
WARNING: at kernel/softirq.c:159 local_bh_enable+0x32/0x79()
...
Pid: 0, comm: swapper Not tainted 3.1.1-gentoo #1
Call Trace:
[<c1022970>] warn_slowpath_common+0x65/0x7a
[<c102699e>] ? local_bh_enable+0x32/0x79
[<c1022994>] warn_slowpath_null+0xf/0x13
[<c102699e>] local_bh_enable+0x32/0x79
[<c134bfd8>] destroy_conntrack+0x7c/0x9b
[<c134890b>] nf_conntrack_destroy+0x1f/0x26
[<c132e3a6>] skb_release_head_state+0x74/0x83
[<c132e286>] __kfree_skb+0xb/0x6b
[<c132e30a>] consume_skb+0x24/0x26
[<c127c925>] b44_poll+0xaa/0x449
[<c1333ca1>] net_rx_action+0x3f/0xea
[<c1026a44>] __do_softirq+0x5f/0xd5
[<c10269e5>] ? local_bh_enable+0x79/0x79
<IRQ> [<c1026c32>] ? irq_exit+0x34/0x8d
[<c1003628>] ? do_IRQ+0x74/0x87
[<c13f5329>] ? common_interrupt+0x29/0x30
[<c1006e18>] ? default_idle+0x29/0x3e
[<c10015a7>] ? cpu_idle+0x2f/0x5d
[<c13e91c5>] ? rest_init+0x79/0x7b
[<c15c66a9>] ? start_kernel+0x297/0x29c
[<c15c60b0>] ? i386_start_kernel+0xb0/0xb7
---[ end trace 583f33bb1aa207a9 ]---
Signed-off-by: Xander Hover <LKML@hover.be>
---
drivers/net/ethernet/broadcom/b44.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/b44.c b/drivers/net/ethernet/broadcom/b44.c
index 4cf835d..3fb66d0 100644
--- a/drivers/net/ethernet/broadcom/b44.c
+++ b/drivers/net/ethernet/broadcom/b44.c
@@ -608,7 +608,7 @@ static void b44_tx(struct b44 *bp)
skb->len,
DMA_TO_DEVICE);
rp->skb = NULL;
- dev_kfree_skb(skb);
+ dev_kfree_skb_irq(skb);
}
bp->tx_cons = cons;
--
1.7.8.rc3
^ permalink raw reply related
* Re: [GIT PULL v2] Open vSwitch
From: Eric Dumazet @ 2011-11-23 14:15 UTC (permalink / raw)
To: jhs-jkUAjuhPggJWk0Htik3J/w
Cc: dev-yBygre7rU0TnMu66kgdUjQ, Herbert Xu,
netdev-u79uwXL29TY76Z2rM5mHXA, David Täht, David Miller
In-Reply-To: <1322055377.2039.179.camel@mojatatu>
Le mercredi 23 novembre 2011 à 08:36 -0500, jamal a écrit :
> If you wanna do this right - I suggest you get a different domain name.
> tc.org or something along those lines.
> Start aggregating documentation that is validated to be working. There's
> a lot of "opinions" out there instead of facts.
Or, we could stick documentation in kernel (Documentation/network/...),
so that we give credit to contributors to this essential part of the
network stack.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
^ permalink raw reply
* Re: [PATCH] netprio_cgroup: Fix build break
From: Neil Horman @ 2011-11-23 14:22 UTC (permalink / raw)
To: Kirill Smelkov
Cc: netdev, David S. Miller, john.r.fastabend, robert.w.love,
Stephen Rothwell, linux-next
In-Reply-To: <20111123131147.GA11508@tugrik.mns.mnsspb.ru>
On Wed, Nov 23, 2011 at 05:11:47PM +0400, Kirill Smelkov wrote:
> On Wed, Nov 23, 2011 at 07:32:33AM -0500, Neil Horman wrote:
> > I broke the build with the addition of netprio_cgroups if CONFIG_CGROUPS=n.
> > This patch corrects it by moving the offending struct into an ifdef
> > CONFIG_CGROUPS block. Also clean up a few needless defines and inline functions
> > that don't get called if CONFIG_CGROUPS isn't defined while Im at it.
>
> Thanks Neil, now it compiles ok.
>
Np, sorry for the trouble. I should have double checked that make oldconfig did
what I assumed it did
Neil
^ permalink raw reply
* Re: Missing TCP SYN on loopback, retransmits after 1s
From: Eric Dumazet @ 2011-11-23 14:38 UTC (permalink / raw)
To: Jesse Young; +Cc: David Miller, netdev
In-Reply-To: <20111122183727.01ab6f04@telperion.jlyo.org>
Le mardi 22 novembre 2011 à 18:37 -0600, Jesse Young a écrit :
> On Tue, 22 Nov 2011 19:23:38 -0500 (EST)
> David Miller <davem@davemloft.net> wrote:
>
> > From: Jesse Young <jlyo@jlyo.org>
> > Date: Tue, 22 Nov 2011 18:13:20 -0600
> >
> > > What's also puzzling, is that I see no packet drop reporting in
> > > $ ifconfig lo
> > > lo: flags=73<UP,LOOPBACK,RUNNING> mtu 16436 metric 1
> > > inet 127.0.0.1 netmask 255.0.0.0
> > > inet6 ::1 prefixlen 128 scopeid 0x10<host>
> > > loop txqueuelen 0 (Local Loopback)
> > > RX packets 276411482 bytes 15822880567 (14.7 GiB)
> > > RX errors 0 dropped 0 overruns 0 frame 0
> > > TX packets 276411482 bytes 15822880567 (14.7 GiB)
> > > TX errors 0 dropped 0 overruns 0 carrier 0 collisions
> >
> > The device driver therefore isn't even seeing the packets, they are
> > being dropped elsewhere.
> >
> > Why is this "puzzling"?
> >
> > There's layers upon layers and thousands of places where packets can
> > be dropped between the originating network stack and the actual device
> > driver.
>
> Maybe puzzling isn't the best word... just some more relevant
> information. Also, this is the loopback interface, there is no device
> driver, PHY or DLL layer in question here (just the loopback's mock
> driver/PHY/DLL).
>
> I presume that the drop is occuring in between the NET layer, and the sys
> call interface, do you agree? Where should I begin looking?
> --
Here is the patch to solve this IPv6 problem, thanks a lot for the
report !
[PATCH] ipv6: tcp: fix tcp_v6_conn_request()
Since linux 2.6.26 (commit c6aefafb7ec6 : Add IPv6 support to TCP SYN
cookies), we can drop a SYN packet reusing a TIME_WAIT socket.
(As a matter of fact we fail to send the SYNACK answer)
As the client resends its SYN packet after a one second timeout, we
accept it, because first packet removed the TIME_WAIT socket before
being dropped.
This probably explains why nobody ever noticed or complained.
Reported-by: Jesse Young <jlyo@jlyo.org>
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/ipv6/tcp_ipv6.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 36131d1..2dea4bb 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1255,6 +1255,13 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
if (!want_cookie || tmp_opt.tstamp_ok)
TCP_ECN_create_request(req, tcp_hdr(skb));
+ treq->iif = sk->sk_bound_dev_if;
+
+ /* So that link locals have meaning */
+ if (!sk->sk_bound_dev_if &&
+ ipv6_addr_type(&treq->rmt_addr) & IPV6_ADDR_LINKLOCAL)
+ treq->iif = inet6_iif(skb);
+
if (!isn) {
struct inet_peer *peer = NULL;
@@ -1264,12 +1271,6 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
atomic_inc(&skb->users);
treq->pktopts = skb;
}
- treq->iif = sk->sk_bound_dev_if;
-
- /* So that link locals have meaning */
- if (!sk->sk_bound_dev_if &&
- ipv6_addr_type(&treq->rmt_addr) & IPV6_ADDR_LINKLOCAL)
- treq->iif = inet6_iif(skb);
if (want_cookie) {
isn = cookie_v6_init_sequence(sk, skb, &req->mss);
^ permalink raw reply related
* Re: [PATCH 1/2] ax25: integer overflows in ax25_setsockopt()
From: Alan Cox @ 2011-11-23 14:39 UTC (permalink / raw)
To: Xi Wang
Cc: linux-kernel, Joerg Reuter, Ralf Baechle, David Miller,
linux-hams, netdev
In-Reply-To: <CAKU6vyY3WjVwTK5Tcp2W93DefjJMreZjhtudNHBALns=6bK9Jw@mail.gmail.com>
On Wed, 23 Nov 2011 09:04:11 -0500
Xi Wang <xi.wang@gmail.com> wrote:
> All these magic numbers come from net/ax25/sysctl_net_ax25.c, where
> min/max values of each field are set for sysctl. Is it okay to use
> them?
The sysctl range is the 'standard' range, but it's always historically
been possible to override them in apps for special cases. I'm wary of
changing that because people do insane things like AX.25 bounced off the
moon where you need very long timeouts.
Alan
^ permalink raw reply
* RE: [PATCH 1/2] ax25: integer overflows in ax25_setsockopt()
From: David Laight @ 2011-11-23 14:53 UTC (permalink / raw)
To: Alan Cox, Xi Wang
Cc: linux-kernel, Joerg Reuter, Ralf Baechle, David Miller,
linux-hams, netdev
In-Reply-To: <20111123143913.50fbcc8c@lxorguk.ukuu.org.uk>
> > All these magic numbers come from net/ax25/sysctl_net_ax25.c, where
> > min/max values of each field are set for sysctl. Is it okay to use
> > them?
>
> The sysctl range is the 'standard' range, but it's always historically
> been possible to override them in apps for special cases. I'm wary of
> changing that because people do insane things like AX.25
> bounced off the moon where you need very long timeouts.
It is a long time since I wrote any of the X.25 protocol
stack layers, but I would agree that limiting timers to the
values defined in the standard is probably not a good idea.
Even normal telco's may have decided to use values that
are outside the nominal range.
These timers are almost certainly either 'guard' timers
for missing responses or retransmit timers for 'keepalive'
messages - so allowing much larger values doesn't matter.
I'd only limit them in order to stop the code breaking.
The lower limit (1 second) will be below the limit for the
protocol - but exists to stop the code breaking.
David
^ permalink raw reply
* Re: [PATCH v3 01/10] dql: Dynamic queue limits
From: Eric Dumazet @ 2011-11-23 14:58 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1111222138280.13686@pokey.mtv.corp.google.com>
Le mardi 22 novembre 2011 à 21:52 -0800, Tom Herbert a écrit :
> Implementation of dynamic queue limits (dql). This is a libary which
> allows a queue limit to be dynamically managed. The goal of dql is
> to set the queue limit, number of objects to the queue, to be minimized
> without allowing the queue to be starved.
>
> dql would be used with a queue which has these properties:
>
> 1) Objects are queued up to some limit which can be expressed as a
> count of objects.
> 2) Periodically a completion process executes which retires consumed
> objects.
> 3) Starvation occurs when limit has been reached, all queued data has
> actually been consumed but completion processing has not yet run,
> so queuing new data is blocked.
> 4) Minimizing the amount of queued data is desirable.
>
> A canonical example of such a queue would be a NIC HW transmit queue.
>
> The queue limit is dynamic, it will increase or decrease over time
> depending on the workload. The queue limit is recalculated each time
> completion processing is done. Increases occur when the queue is
> starved and can exponentially increase over successive intervals.
> Decreases occur when more data is being maintained in the queue than
> needed to prevent starvation. The number of extra objects, or "slack",
> is measured over successive intervals, and to avoid hysteresis the
> limit is only reduced by the miminum slack seen over a configurable
> time period.
>
> dql API provides routines to manage the queue:
> - dql_init is called to intialize the dql structure
> - dql_reset is called to reset dynamic values
> - dql_queued called when objects are being enqueued
> - dql_avail returns availability in the queue
> - dql_completed is called when objects have be consumed in the queue
>
> Configuration consists of:
> - max_limit, maximum limit
> - min_limit, minimum limit
> - slack_hold_time, time to measure instances of slack before reducing
> queue limit
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/dynamic_queue_limits.h | 81 +++++++++++++++++++++
> lib/Kconfig | 3 +
> lib/Makefile | 2 +
> lib/dynamic_queue_limits.c | 132 ++++++++++++++++++++++++++++++++++
> 4 files changed, 218 insertions(+), 0 deletions(-)
> create mode 100644 include/linux/dynamic_queue_limits.h
> create mode 100644 lib/dynamic_queue_limits.c
>
> diff --git a/include/linux/dynamic_queue_limits.h b/include/linux/dynamic_queue_limits.h
> new file mode 100644
> index 0000000..8953187
> --- /dev/null
> +++ b/include/linux/dynamic_queue_limits.h
> @@ -0,0 +1,81 @@
> +/*
> + * Dynamic queue limits (dql) - Definitions
> + *
> + * Copyright (c) 2011, Tom Herbert <therbert@google.com>
> + *
> + * This header file contains the definitions for dynamic queue limits (dql).
> + * dql would be used in conjunction with a producer/consumer type queue
> + * (possibly a HW queue). Such a queue would have these general properties:
> + *
> + * 1) Objects are queued up to some limit specified as number of objects.
> + * 2) Periodically a completion process executes which retires consumed
> + * objects.
> + * 3) Starvation occurs when limit has been reached, all queued data has
> + * actually been consumed, but completion processing has not yet run
> + * so queuing new data is blocked.
> + * 4) Minimizing the amount of queued data is desirable.
> + *
> + * The goal of dql is to calculate the limit as the minimum number of objects
> + * needed to prevent starvation.
> + *
> + * The dql implementation does not implement any locking for the dql data
> + * structures, the higher layer should provide this.
> + */
Maybe give a hint on the fact that all dql_queued() must be serialized,
all dql_completed() must be serialized, but can use a different lock
(a dql_completed() can be run while a dql_queued() is run)
> +
> +#ifndef _LINUX_DQL_H
> +#define _LINUX_DQL_H
> +
> +#ifdef __KERNEL__
> +
> +struct dql {
> + unsigned long num_queued; /* Total ever queued */
> + unsigned long last_obj_cnt; /* Count at last queuing */
> +
> + unsigned long limit ____cacheline_aligned_in_smp; /* Current limit */
> + unsigned long prev_ovlimit; /* Previous over limit */
> +
> + unsigned long prev_num_queued; /* Previous queue total */
> + unsigned long num_completed; /* Total ever completed */
> +
> + unsigned long prev_last_obj_cnt; /* Previous queuing cnt */
> +
> + unsigned long lowest_slack; /* Lowest slack found */
> + unsigned long slack_start_time; /* Time slacks seen */
> +
> + unsigned long max_limit ____cacheline_aligned_in_smp; /* Max limit */
> + unsigned long min_limit; /* Minimum limit */
> + unsigned slack_hold_time; /* Time to measure slack */
> +};
> +
Hmm, please dont do that, it will add two cache lines in transmit path,
and a third one for very seldom used data.
What is needed tx fast path are : num_queued, last_obj_cnt, limit and
num_completed.
So I suggest :
struct dql {
/* part used in dql_queued() */
unsigned long num_queued; /* Total ever queued */
unsigned long last_obj_cnt; /* Count at last queuing */
unsigned long limit; /* Current limit */
unsigned long num_completed; /* Total ever completed */
/* part used in dql_completed() */
unsigned long prev_ovlimit; /* Previous over limit */
unsigned long prev_num_queued; /* Previous queue total */
unsigned long prev_last_obj_cnt; /* Previous queuing cnt */
unsigned long lowest_slack; /* Lowest slack found */
unsigned long slack_start_time; /* Time slacks seen */
unsigned long max_limit; /* Max limit */
unsigned long min_limit; /* Minimum limit */
unsigned int slack_hold_time; /* Time to measure slack */
};
Another question is : Is DQL planned to work on 32bit arch ?
A fast interface can probably send more than 2^32 bytes for large
slack_hold_time values, and wrap around.
If yes : We can use "unsigned int" instead of "unsigned long" to lower
memory need on 64bit arch.
If no, "unsigned long" type is not enough on 32bit, or we need to limit
slack_hold_time to small intervals...
^ permalink raw reply
* Re: [PATCH v3 01/10] dql: Dynamic queue limits
From: Eric Dumazet @ 2011-11-23 15:05 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1322060288.17693.37.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
Le mercredi 23 novembre 2011 à 15:58 +0100, Eric Dumazet a écrit :
> Another question is : Is DQL planned to work on 32bit arch ?
>
> A fast interface can probably send more than 2^32 bytes for large
> slack_hold_time values, and wrap around.
>
> If yes : We can use "unsigned int" instead of "unsigned long" to lower
> memory need on 64bit arch.
>
> If no, "unsigned long" type is not enough on 32bit, or we need to limit
> slack_hold_time to small intervals...
>
>
Hmm, reading again the code, 32bit counters should be more than enough,
instead of "unsigned long", on all arches.
unsigned long is only needed for slack_start_time (to store jiffies)
This would lower sizeof( struct dql) to 48 or 56 bytes.
^ permalink raw reply
* slub: use irqsafe_cpu_cmpxchg for put_cpu_partial
From: Christoph Lameter @ 2011-11-23 15:14 UTC (permalink / raw)
To: Pekka Enberg
Cc: Christian Kujau, Benjamin Herrenschmidt, Eric Dumazet,
Markus Trippelsdorf, Alex,Shi, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Matt Mackall, netdev@vger.kernel.org,
Tejun Heo, David Rientjes
In-Reply-To: <CAOJsxLGWTRuwQ04Mg26fNhZEmo7yVXG5vSZgF7Q5GESCk65odA@mail.gmail.com>
On Wed, 23 Nov 2011, Pekka Enberg wrote:
> 2011/11/23 Christian Kujau <lists@nerdbynature.de>:
> > OK, with Christoph's patch applied, 3.2.0-rc2-00274-g6fe4c6d-dirty survives
> > on this machine, with the disk & cpu workload that caused the machine to
> > panic w/o the patch. Load was at 4-5 this time, which is expected for this
> > box. I'll run a few more tests later on, but it seems ok for now.
> >
> > I couldn't resist and ran "slabinfo" anyway (after the workload!) - the
> > box survived, nothing was printed in syslog either. Output attached.
>
> Christoph, Eric, would you mind sending me the final patches that
> Christian tested? Maybe CC David too for extra pair of eyes.
I think he only tested the patch that he showed us. Here is the patch
cleaned up. Do you Want me to feed you the debug fixes patch by patch as
well?
Subject: slub: use irqsafe_cpu_cmpxchg for put_cpu_partial
The cmpxchg must be irq safe. The fallback for this_cpu_cmpxchg only
disables preemption which results in per cpu partial page operation
potentially failing on non x86 platforms.
Signed-off-by: Christoph Lameter <cl@linux.com>
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6/mm/slub.c
===================================================================
--- linux-2.6.orig/mm/slub.c 2011-11-23 09:10:48.000000000 -0600
+++ linux-2.6/mm/slub.c 2011-11-23 09:10:57.000000000 -0600
@@ -1969,7 +1969,7 @@ int put_cpu_partial(struct kmem_cache *s
page->pobjects = pobjects;
page->next = oldpage;
- } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
+ } while (irqsafe_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
stat(s, CPU_PARTIAL_FREE);
return pobjects;
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH] ipv4 : igmp : optimize timer modify logic in igmp_mod_timer()
From: Jun Zhao @ 2011-11-23 15:26 UTC (permalink / raw)
To: davem; +Cc: netdev, Jun Zhao
When timer is pending and expires less-than-or-equal-to new delay,
we need not used del_timer()/add_timer().
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
---
net/ipv4/igmp.c | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index c7472ef..50d06c5 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -215,14 +215,14 @@ static void igmp_mod_timer(struct ip_mc_list *im, int max_delay)
{
spin_lock_bh(&im->lock);
im->unsolicit_count = 0;
- if (del_timer(&im->timer)) {
- if ((long)(im->timer.expires-jiffies) < max_delay) {
- add_timer(&im->timer);
- im->tm_running = 1;
- spin_unlock_bh(&im->lock);
+ if (timer_pending(&im->timer)) {
+ if (time_before_eq(im->timer.expires, (jiffies + max_delay))) {
+ spin_lock_bh(&im->lock);
return;
+ } else {
+ del_timer(&im->timer);
+ atomic_dec(&im->refcnt);
}
- atomic_dec(&im->refcnt);
}
igmp_start_timer(im, max_delay);
spin_unlock_bh(&im->lock);
--
1.7.2.5
^ permalink raw reply related
* RE: [PATCH v3 01/10] dql: Dynamic queue limits
From: David Laight @ 2011-11-23 15:35 UTC (permalink / raw)
To: Eric Dumazet, Tom Herbert; +Cc: davem, netdev
In-Reply-To: <1322060288.17693.37.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
> Another question is : Is DQL planned to work on 32bit arch ?
>
> A fast interface can probably send more than 2^32 bytes for large
> slack_hold_time values, and wrap around.
>
> If yes : We can use "unsigned int" instead of "unsigned long" to lower
> memory need on 64bit arch.
>
> If no, "unsigned long" type is not enough on 32bit, or we
> need to limit slack_hold_time to small intervals...
Another option would be divide the byte counts by (say) 16.
This would be good enough for the purpose, and increase the
time-to-wrap by a factor of 16.
David
^ permalink raw reply
* Re: [PATCH] ipv4 : igmp : optimize timer modify logic in igmp_mod_timer()
From: Eric Dumazet @ 2011-11-23 15:42 UTC (permalink / raw)
To: Jun Zhao; +Cc: davem, netdev
In-Reply-To: <1322062004-9742-1-git-send-email-mypopydev@gmail.com>
Le mercredi 23 novembre 2011 à 23:26 +0800, Jun Zhao a écrit :
> When timer is pending and expires less-than-or-equal-to new delay,
> we need not used del_timer()/add_timer().
>
> Signed-off-by: Jun Zhao <mypopydev@gmail.com>
> ---
> net/ipv4/igmp.c | 12 ++++++------
> 1 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> index c7472ef..50d06c5 100644
> --- a/net/ipv4/igmp.c
> +++ b/net/ipv4/igmp.c
> @@ -215,14 +215,14 @@ static void igmp_mod_timer(struct ip_mc_list *im, int max_delay)
> {
> spin_lock_bh(&im->lock);
> im->unsolicit_count = 0;
> - if (del_timer(&im->timer)) {
> - if ((long)(im->timer.expires-jiffies) < max_delay) {
> - add_timer(&im->timer);
> - im->tm_running = 1;
> - spin_unlock_bh(&im->lock);
> + if (timer_pending(&im->timer)) {
> + if (time_before_eq(im->timer.expires, (jiffies + max_delay))) {
> + spin_lock_bh(&im->lock);
And you actually tested this patch ?
> return;
> + } else {
> + del_timer(&im->timer);
> + atomic_dec(&im->refcnt);
> }
> - atomic_dec(&im->refcnt);
> }
> igmp_start_timer(im, max_delay);
> spin_unlock_bh(&im->lock);
Not sure why you want to optimize this very rare function call, risking
adding bugs in it.
^ permalink raw reply
* Re: [PATCH] ipv4 : igmp : optimize timer modify logic in igmp_mod_timer()
From: Jun Zhao @ 2011-11-23 15:44 UTC (permalink / raw)
To: Eric Dumazet; +Cc: davem, netdev
In-Reply-To: <1322062966.17693.44.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Wed, 2011-11-23 at 16:42 +0100, Eric Dumazet wrote:
> Le mercredi 23 novembre 2011 à 23:26 +0800, Jun Zhao a écrit :
> > When timer is pending and expires less-than-or-equal-to new delay,
> > we need not used del_timer()/add_timer().
> >
> > Signed-off-by: Jun Zhao <mypopydev@gmail.com>
> > ---
> > net/ipv4/igmp.c | 12 ++++++------
> > 1 files changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
> > index c7472ef..50d06c5 100644
> > --- a/net/ipv4/igmp.c
> > +++ b/net/ipv4/igmp.c
> > @@ -215,14 +215,14 @@ static void igmp_mod_timer(struct ip_mc_list *im, int max_delay)
> > {
> > spin_lock_bh(&im->lock);
> > im->unsolicit_count = 0;
> > - if (del_timer(&im->timer)) {
> > - if ((long)(im->timer.expires-jiffies) < max_delay) {
> > - add_timer(&im->timer);
> > - im->tm_running = 1;
> > - spin_unlock_bh(&im->lock);
> > + if (timer_pending(&im->timer)) {
> > + if (time_before_eq(im->timer.expires, (jiffies + max_delay))) {
> > + spin_lock_bh(&im->lock);
>
> And you actually tested this patch ?
Sorry for this mistake. :(. spin_lock_bh -> spin_unlock_bh
>
> > return;
> > + } else {
> > + del_timer(&im->timer);
> > + atomic_dec(&im->refcnt);
> > }
> > - atomic_dec(&im->refcnt);
> > }
> > igmp_start_timer(im, max_delay);
> > spin_unlock_bh(&im->lock);
>
>
> Not sure why you want to optimize this very rare function call, risking
> adding bugs in it.
>
>
>
^ permalink raw reply
* Re: [PATCH 5/5] ipv4: Don't use the cached pmtu informations for input routes
From: Herbert Xu @ 2011-11-23 15:52 UTC (permalink / raw)
To: Steffen Klassert; +Cc: davem, netdev
In-Reply-To: <20111123121450.GE6348@secunet.com>
Steffen Klassert <steffen.klassert@secunet.com> wrote:
> The pmtu informations on the inetpeer are visible for output and
> input routes. On packet forwarding, we might propagate a learned
> pmtu to the sender. As we update the pmtu informations of the
> inetpeer on demand, the original sender of the forwarded packets
> might never notice when the pmtu to that inetpeer increases.
> So use the mtu of the outgoing device on packet forwarding instead
> of the pmtu to the final destination.
I disagree. MTU increases are detected by the source retrying,
so they most certainly should notice if our cached value expires.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v3 05/10] bql: Byte queue limits
From: Eric Dumazet @ 2011-11-23 16:00 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.00.1111222140410.15246@pokey.mtv.corp.google.com>
Le mardi 22 novembre 2011 à 21:52 -0800, Tom Herbert a écrit :
> Networking stack support for byte queue limits, uses dynamic queue
> limits library. Byte queue limits are maintained per transmit queue,
> and a dql structure has been added to netdev_queue structure for this
> purpose.
>
> Configuration of bql is in the tx-<n> sysfs directory for the queue
> under the byte_queue_limits directory. Configuration includes:
> limit_min, bql minimum limit
> limit_max, bql maximum limit
> hold_time, bql slack hold time
>
> Also under the directory are:
> limit, current byte limit
> inflight, current number of bytes on the queue
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> include/linux/netdevice.h | 28 ++++++++
> net/Kconfig | 13 ++++
> net/core/dev.c | 3 +
> net/core/net-sysfs.c | 150 ++++++++++++++++++++++++++++++++++++++++++---
> 4 files changed, 186 insertions(+), 8 deletions(-)
>
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 8b3eb8a..e17ece6 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -43,6 +43,7 @@
> #include <linux/rculist.h>
> #include <linux/dmaengine.h>
> #include <linux/workqueue.h>
> +#include <linux/dynamic_queue_limits.h>
>
> #include <linux/ethtool.h>
> #include <net/net_namespace.h>
> @@ -557,6 +558,9 @@ struct netdev_queue {
> * please use this field instead of dev->trans_start
> */
> unsigned long trans_start;
> +#ifdef CONFIG_BQL
> + struct dql dql;
> +#endif
> } ____cacheline_aligned_in_smp;
>
> static inline int netdev_queue_numa_node_read(const struct netdev_queue *q)
> @@ -1927,6 +1931,15 @@ static inline int netif_xmit_frozen_or_stopped(const struct netdev_queue *dev_qu
> static inline void netdev_tx_sent_queue(struct netdev_queue *dev_queue,
> unsigned int pkts, unsigned int bytes)
> {
> +#ifdef CONFIG_BQL
> + dql_queued(&dev_queue->dql, bytes);
> + if (unlikely(dql_avail(&dev_queue->dql) < 0)) {
> + set_bit(__QUEUE_STATE_STACK_XOFF, &dev_queue->state);
> + if (unlikely(dql_avail(&dev_queue->dql) >= 0))
> + clear_bit(__QUEUE_STATE_STACK_XOFF,
> + &dev_queue->state);
> + }
> +#endif
> }
>
> static inline void netdev_sent_queue(struct net_device *dev,
> @@ -1938,6 +1951,18 @@ static inline void netdev_sent_queue(struct net_device *dev,
> static inline void netdev_tx_completed_queue(struct netdev_queue *dev_queue,
> unsigned pkts, unsigned bytes)
> {
> +#ifdef CONFIG_BQL
> + if (likely(bytes)) {
> + dql_completed(&dev_queue->dql, bytes);
> + if (unlikely(test_bit(__QUEUE_STATE_STACK_XOFF,
> + &dev_queue->state) &&
> + dql_avail(&dev_queue->dql) >= 0)) {
Maybe we can use some trick to avoid many wakeups ?
I feel that an other cpu might discover queue state is now XON and can
start xmit, without the extra __netif_schedule_queue() cost for this cpu
(softirq...). In a stress situation, cpu handling NIC interrupts can be
hogged...
The idea would be to clear STACK_XOFF bit, and if bytes are still in
flight (anotehr completion should come later), not call
netif_schedule_queue()
> + if (test_and_clear_bit(__QUEUE_STATE_STACK_XOFF,
> + &dev_queue->state))
> + netif_schedule_queue(dev_queue);
> + }
> + }
> +#endif
> }
>
> static
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Markus Trippelsdorf @ 2011-11-23 16:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: Alex,Shi, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
Christoph Lameter, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj, dri-devel, Alex Deucher
In-Reply-To: <20111121153621.GA1678@x4.trippels.de>
On 2011.11.21 at 16:36 +0100, Markus Trippelsdorf wrote:
> On 2011.11.21 at 15:16 +0100, Eric Dumazet wrote:
> > Le lundi 21 novembre 2011 à 14:15 +0100, Markus Trippelsdorf a écrit :
> >
> > > I've enabled CONFIG_SLUB_DEBUG_ON and this is what happend:
> > >
> >
> > Thanks
> >
> > Please continue to provide more samples.
> >
> > There is something wrong somewhere, but where exactly, its hard to say.
>
> New sample. This one points to lib/idr.c:
>
> [drm] Initialized drm 1.1.0 20060810
> [drm] radeon defaulting to kernel modesetting.
> [drm] radeon kernel modesetting enabled.
> radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
> radeon 0000:01:05.0: setting latency timer to 64
> [drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
> [drm] register mmio base: 0xFBEE0000
> [drm] register mmio size: 65536
> ATOM BIOS: 113
> radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
> radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
> [drm] Detected VRAM RAM=128M, BAR=128M
> [drm] RAM width 32bits DDR
> [TTM] Zone kernel: Available graphics memory: 4083428 kiB.
> [TTM] Zone dma32: Available graphics memory: 2097152 kiB.
> [TTM] Initializing pool allocator.
> [drm] radeon: 128M of VRAM memory ready
> [drm] radeon: 512M of GTT memory ready.
> [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
> [drm] Driver supports precise vblank timestamp query.
> [drm] radeon: irq initialized.
> [drm] GART: num cpu pages 131072, num gpu pages 131072
> [drm] Loading RS780 Microcode
> [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
> radeon 0000:01:05.0: WB enabled
> [drm] ring test succeeded in 1 usecs
> [drm] radeon: ib pool ready.
> [drm] ib test succeeded in 0 usecs
> =============================================================================
> BUG idr_layer_cache: Poison overwritten
> -----------------------------------------------------------------------------
>
> INFO: 0xffff880215650800-0xffff880215650803. First byte 0x0 instead of 0x6b
> INFO: Slab 0xffffea0008559400 objects=18 used=18 fp=0x (null) flags=0x4000000000004080
> INFO: Object 0xffff8802156506d0 @offset=1744 fp=0xffff880215650a38
>
> Bytes b4 ffff8802156506c0: a4 6f fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a .o......ZZZZZZZZ
> Object ffff8802156506d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156506e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156506f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156507f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> Object ffff880215650810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215650890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156508e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
> Redzone ffff8802156508f0: bb bb bb bb bb bb bb bb ........
> Padding ffff880215650a30: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
> Pid: 1, comm: swapper Not tainted 3.2.0-rc2-00274-g6fe4c6d #71
> Call Trace:
> [<ffffffff81101cf8>] ? print_section+0x38/0x40
> [<ffffffff811021f3>] print_trailer+0xe3/0x150
> [<ffffffff811023f0>] check_bytes_and_report+0xe0/0x100
> [<ffffffff811031e6>] check_object+0x1c6/0x240
> [<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
> [<ffffffff814c5c43>] alloc_debug_processing+0x62/0xe4
> [<ffffffff814c64f1>] __slab_alloc.constprop.69+0x1a4/0x1e0
> [<ffffffff8129ae77>] ? drm_property_create+0x47/0x110
> [<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
> [<ffffffff81104db1>] kmem_cache_alloc+0x121/0x150
> [<ffffffff812031f0>] ? idr_pre_get+0x60/0x90
> [<ffffffff812031f0>] idr_pre_get+0x60/0x90
> [<ffffffff8129870a>] drm_mode_object_get+0x6a/0xc0
> [<ffffffff8129ae95>] drm_property_create+0x65/0x110
> [<ffffffff8129b15d>] drm_mode_config_init+0xfd/0x190
> [<ffffffff812e12ad>] radeon_modeset_init+0x1d/0x860
> [<ffffffff813211c7>] ? radeon_acpi_init+0x87/0xc0
> [<ffffffff812c37b8>] radeon_driver_load_kms+0xf8/0x150
> [<ffffffff81295a06>] drm_get_pci_dev+0x186/0x2d0
> [<ffffffff814bf1fd>] ? radeon_pci_probe+0x9e/0xb8
> [<ffffffff814bf20f>] radeon_pci_probe+0xb0/0xb8
> [<ffffffff8121be15>] pci_device_probe+0x75/0xa0
> [<ffffffff81324e1a>] ? driver_sysfs_add+0x7a/0xb0
> [<ffffffff81325021>] driver_probe_device+0x71/0x190
> [<ffffffff813251db>] __driver_attach+0x9b/0xa0
> [<ffffffff81325140>] ? driver_probe_device+0x190/0x190
> [<ffffffff81323e0d>] bus_for_each_dev+0x4d/0x90
> [<ffffffff813252f9>] driver_attach+0x19/0x20
> [<ffffffff81324598>] bus_add_driver+0x188/0x250
> [<ffffffff81325942>] driver_register+0x72/0x150
> [<ffffffff81321de5>] ? device_add+0x75/0x600
> [<ffffffff8121bb7d>] __pci_register_driver+0x5d/0xd0
> [<ffffffff81295c54>] drm_pci_init+0x104/0x120
> [<ffffffff818abefa>] ? ttm_init+0x62/0x62
> [<ffffffff818abfe1>] radeon_init+0xe7/0xe9
> [<ffffffff81890883>] do_one_initcall+0x7a/0x129
> [<ffffffff818909cc>] kernel_init+0x9a/0x114
> [<ffffffff814cddb4>] kernel_thread_helper+0x4/0x10
> [<ffffffff81890932>] ? do_one_initcall+0x129/0x129
> [<ffffffff814cddb0>] ? gs_change+0xb/0xb
> FIX idr_layer_cache: Restoring 0xffff880215650800-0xffff880215650803=0x6b
>
> FIX idr_layer_cache: Marking all objects used
Yesterday I couldn't reproduce the issue at all. But today I've hit
exactly the same spot again. (CCing the drm list)
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
radeon 0000:01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
radeon 0000:01:05.0: setting latency timer to 64
[drm] initializing kernel modesetting (RS780 0x1002:0x9614 0x1043:0x834D).
[drm] register mmio base: 0xFBEE0000
[drm] register mmio size: 65536
ATOM BIOS: 113
radeon 0000:01:05.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (128M used)
radeon 0000:01:05.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF
[drm] Detected VRAM RAM=128M, BAR=128M
[drm] RAM width 32bits DDR
[TTM] Zone kernel: Available graphics memory: 4083428 kiB.
[TTM] Zone dma32: Available graphics memory: 2097152 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 128M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] Loading RS780 Microcode
[drm] PCIE GART of 512M enabled (table at 0x00000000C0040000).
radeon 0000:01:05.0: WB enabled
[drm] ring test succeeded in 1 usecs
[drm] radeon: ib pool ready.
[drm] ib test succeeded in 0 usecs
=============================================================================
BUG idr_layer_cache: Poison overwritten
-----------------------------------------------------------------------------
INFO: 0xffff880215648800-0xffff880215648803. First byte 0x0 instead of 0x6b
INFO: Slab 0xffffea0008559200 objects=18 used=18 fp=0x (null) flags=0x4000000000004080
INFO: Object 0xffff8802156486d0 @offset=1744 fp=0xffff880215648a38
Bytes b4 ffff8802156486c0: 66 75 fb ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a fu......ZZZZZZZZ
Object ffff8802156486d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156486e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156486f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648700: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648710: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648720: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648730: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648740: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648750: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648760: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648770: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648780: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648790: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156487a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156487b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
Object ffff880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648820: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648830: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648840: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648850: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648860: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648870: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648880: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff880215648890: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156488a0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156488b0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156488c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156488d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
Object ffff8802156488e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 kkkkkkkkkkkkkkk.
Redzone ffff8802156488f0: bb bb bb bb bb bb bb bb ........
Padding ffff880215648a30: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ
Pid: 1, comm: swapper Not tainted 3.2.0-rc2-00438-g4d8c62a-dirty #105
Call Trace:
[<ffffffff81101fb8>] ? print_section+0x38/0x40
[<ffffffff811024b3>] print_trailer+0xe3/0x150
[<ffffffff811026b0>] check_bytes_and_report+0xe0/0x100
[<ffffffff811034a6>] check_object+0x1c6/0x240
[<ffffffff81203550>] ? idr_pre_get+0x60/0x90
[<ffffffff814c5fab>] alloc_debug_processing+0x62/0xe4
[<ffffffff814c6887>] __slab_alloc.constprop.69+0x1a4/0x1e0
[<ffffffff8129b287>] ? drm_property_create+0x47/0x110
[<ffffffff81203550>] ? idr_pre_get+0x60/0x90
[<ffffffff81105071>] kmem_cache_alloc+0x121/0x150
[<ffffffff81203550>] ? idr_pre_get+0x60/0x90
[<ffffffff81203550>] idr_pre_get+0x60/0x90
[<ffffffff81298b0a>] drm_mode_object_get+0x6a/0xc0
[<ffffffff8129b2a5>] drm_property_create+0x65/0x110
[<ffffffff8129b56d>] drm_mode_config_init+0xfd/0x190
[<ffffffff812e157d>] radeon_modeset_init+0x1d/0x860
[<ffffffff81321547>] ? radeon_acpi_init+0x87/0xc0
[<ffffffff812c3bc8>] radeon_driver_load_kms+0xf8/0x150
[<ffffffff81295e06>] drm_get_pci_dev+0x186/0x2d0
[<ffffffff814bf56d>] ? radeon_pci_probe+0x9e/0xb8
[<ffffffff814bf57f>] radeon_pci_probe+0xb0/0xb8
[<ffffffff8121c175>] pci_device_probe+0x75/0xa0
[<ffffffff8132519a>] ? driver_sysfs_add+0x7a/0xb0
[<ffffffff813253a1>] driver_probe_device+0x71/0x190
[<ffffffff8132555b>] __driver_attach+0x9b/0xa0
[<ffffffff813254c0>] ? driver_probe_device+0x190/0x190
[<ffffffff8132418d>] bus_for_each_dev+0x4d/0x90
[<ffffffff81325679>] driver_attach+0x19/0x20
[<ffffffff81324918>] bus_add_driver+0x188/0x250
[<ffffffff81325cc2>] driver_register+0x72/0x150
[<ffffffff81322165>] ? device_add+0x75/0x600
[<ffffffff8121bedd>] __pci_register_driver+0x5d/0xd0
[<ffffffff81296054>] drm_pci_init+0x104/0x120
[<ffffffff818abf51>] ? ttm_init+0x62/0x62
[<ffffffff818ac038>] radeon_init+0xe7/0xe9
[<ffffffff81890883>] do_one_initcall+0x7a/0x129
[<ffffffff818909cc>] kernel_init+0x9a/0x114
[<ffffffff814ce174>] kernel_thread_helper+0x4/0x10
[<ffffffff81890932>] ? do_one_initcall+0x129/0x129
[<ffffffff814ce170>] ? gs_change+0xb/0xb
FIX idr_layer_cache: Restoring 0xffff880215648800-0xffff880215648803=0x6b
FIX idr_layer_cache: Marking all objects used
[drm] Radeon Display Connectors
[drm] Connector 0:
[drm] VGA
[drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
[drm] Encoders:
[drm] CRT1: INTERNAL_KLDSCP_DAC1
[drm] Connector 1:
[drm] DVI-D
[drm] HPD3
[drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
[drm] Encoders:
[drm] DFP3: INTERNAL_KLDSCP_LVTMA
[drm] radeon: power management initialized
[drm] fb mappable at 0xF0142000
[drm] vram apper at 0xF0000000
[drm] size 7299072
[drm] fb depth is 24
[drm] pitch is 6912
fbcon: radeondrmfb (fb0) is primary device
Console: switching to colour frame buffer device 131x105
fb0: radeondrmfb frame buffer device
drm: registered panic notifier
[drm] Initialized radeon 2.12.0 20080528 for 0000:01:05.0 on minor 0
--
Markus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: slub: use irqsafe_cpu_cmpxchg for put_cpu_partial
From: Eric Dumazet @ 2011-11-23 16:04 UTC (permalink / raw)
To: Christoph Lameter
Cc: Pekka Enberg, Christian Kujau, Benjamin Herrenschmidt,
Markus Trippelsdorf, Alex,Shi, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Matt Mackall, netdev@vger.kernel.org,
Tejun Heo, David Rientjes
In-Reply-To: <alpine.DEB.2.00.1111230907330.16139@router.home>
Le mercredi 23 novembre 2011 à 09:14 -0600, Christoph Lameter a écrit :
> I think he only tested the patch that he showed us. Here is the patch
> cleaned up. Do you Want me to feed you the debug fixes patch by patch as
> well?
>
> Subject: slub: use irqsafe_cpu_cmpxchg for put_cpu_partial
>
> The cmpxchg must be irq safe. The fallback for this_cpu_cmpxchg only
> disables preemption which results in per cpu partial page operation
> potentially failing on non x86 platforms.
>
> Signed-off-by: Christoph Lameter <cl@linux.com>
>
> ---
> mm/slub.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Index: linux-2.6/mm/slub.c
> ===================================================================
> --- linux-2.6.orig/mm/slub.c 2011-11-23 09:10:48.000000000 -0600
> +++ linux-2.6/mm/slub.c 2011-11-23 09:10:57.000000000 -0600
> @@ -1969,7 +1969,7 @@ int put_cpu_partial(struct kmem_cache *s
> page->pobjects = pobjects;
> page->next = oldpage;
>
> - } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> + } while (irqsafe_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> stat(s, CPU_PARTIAL_FREE);
> return pobjects;
> }
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Thanks !
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [GIT PULL v2] Open vSwitch
From: John Fastabend @ 2011-11-23 16:05 UTC (permalink / raw)
To: Jamal Hadi Salim
Cc: dev-yBygre7rU0TnMu66kgdUjQ@public.gmane.org, Herbert Xu,
Eric Dumazet, netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
David Miller
In-Reply-To: <1322055858.2039.188.camel@mojatatu>
On 11/23/2011 5:44 AM, Jamal Hadi Salim wrote:
> On Wed, 2011-11-23 at 13:55 +0100, Eric Dumazet wrote:
>
>> Currently thinking about it. I was also waiting Tom Herbert BQL patches.
>
> Excellent. I can test when you have something.
>
>> Several people are interested, and John Fastabend told me he plans to :
>>
>> (1) rcu'ify classifiers/actions as needed
>
> Makes sense in most cases. If you have a lot of flow setup/teardown
> it may harm.
We could have a CONFIG option to always do locking in some
cases if thats not too ugly.
> Another one - but dont see how much you can do about this; useful
> when you want to share state (eg multiple flows being policed
> by a single rate meter);
> An action could be shared across multiple policies i.e you can
> have:
> match1, action foo instance 1, action bar instance 3
> match2, action bar instance3
> match3, ....
> This could would mean a lock contended across cpus when different
> flows hitting match1/2 show up on different cpus.
>
>> (2) add flag to drop qdisc lock on simple or hw qdiscs
>
> Where does config for the hardware happen from?
>
I assume you mean something like setup_tc() which we have
today to call into into the driver at qdisc create time. This
happens with the RTNL held. I don't see any reason not to also
call into the hardware on qdisc_change() I just haven't done
it yet.
Although I'm pretty sure we don't want to add a new ndo_ops
ever time we have some hardware feature we want to expose.
Assuming there are more than 1 or 2 hw features. So maybe
we could convert to something more generic. A setup_qos()
call that passes an skb with nl attributes.
Is that what you were asking?
>> (3) mq and mqprio call root qdisc and run a pass over classifiers
>> actions possibly resetting queue_mapping.
>
>
> It seems to make sense - but I will wait and see to have better
> understanding.
One of the problems this resolves is not being able to
call the classifier-actions until after the queue is
already selected. At this point you can't send it to
a higher/lower priority queue.
I'm traveling for a couple days, but I'll try to get
some actual patches out next week to illustrate this.
Thanks,
John
>
> cheers,
> jamal
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" 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: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Christoph Lameter @ 2011-11-23 16:06 UTC (permalink / raw)
To: Markus Trippelsdorf
Cc: Eric Dumazet, Alex,Shi, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Pekka Enberg, Matt Mackall,
netdev@vger.kernel.org, tj, dri-devel, Alex Deucher
In-Reply-To: <20111123160353.GA1673@x4.trippels.de>
On Wed, 23 Nov 2011, Markus Trippelsdorf wrote:
> > FIX idr_layer_cache: Marking all objects used
>
> Yesterday I couldn't reproduce the issue at all. But today I've hit
> exactly the same spot again. (CCing the drm list)
Well this is looks like write after free.
> =============================================================================
> BUG idr_layer_cache: Poison overwritten
> -----------------------------------------------------------------------------
> Object ffff8802156487c0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156487d0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156487e0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff8802156487f0: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
> Object ffff880215648800: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b ....kkkkkkkkkkkk
> Object ffff880215648810: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk
And its an integer sized write of 0. If you look at the struct definition
and lookup the offset you should be able to locate the field that
was modified.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [3.1-rc8 REGRESSION] sky2 hangs machine on turning off or suspending
From: Stephen Hemminger @ 2011-11-23 16:19 UTC (permalink / raw)
To: Rafał Miłecki
Cc: Network Development, David S. Miller, Rafael J. Wysocki
In-Reply-To: <CACna6rwDjqwypAr_03NEA=x8J_2DpL2LjgSMiQmLHHGv3AA7GA@mail.gmail.com>
On Wed, 23 Nov 2011 08:43:30 +0100
Rafał Miłecki <zajec5@gmail.com> wrote:
> W dniu 9 listopada 2011 12:46 użytkownik Rafał Miłecki
> <zajec5@gmail.com> napisał:
> > I've Sony VAIO FW11S with:
> >
> > 08:00.0 Ethernet controller [0200]: Marvell Technology Group Ltd.
> > 88E8055 PCI-E Gigabit Ethernet Controller [11ab:4363] (rev 13)
> > Subsystem: Sony Corporation Device [104d:9035]
> > Flags: bus master, fast devsel, latency 0, IRQ 47
> > Memory at d0120000 (64-bit, non-prefetchable) [size=16K]
> > I/O ports at 2000 [size=256]
> > Expansion ROM at d0100000 [disabled] [size=128K]
> > Capabilities: [48] Power Management version 3
> > Capabilities: [50] Vital Product Data
> > Capabilities: [5c] MSI: Enable+ Count=1/1 Maskable- 64bit+
> > Capabilities: [e0] Express Legacy Endpoint, MSI 00
> > Capabilities: [100] Advanced Error Reporting
> > Kernel driver in use: sky2
> >
> > Starting with:
> >
> > 0bdb0bd0139f3b6afa252de1487e3ce82a494db9
> > Author: stephen hemminger <shemminger@vyatta.com>
> > Date: Fri Sep 23 11:13:40 2011 +0000
> >
> > sky2: manage irq better on single port card
> >
> > I can not turn off my machine. I see "The system will be halted
> > immediately" on ALT+CTRL+F10 and that's all. Machine doesn't turn off,
> > I can no use SysRq, fan goes up. On CTRL+ATL+F1 I can see info about
> > sending KILL signal to all processes.
> >
> > Reverting this single patch fixes the problem.
> >
> > Some dmesg sky2 output:
> > [ 10.001833] sky2: driver version 1.29
> > [ 10.001873] sky2 0000:08:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
> > [ 10.001886] sky2 0000:08:00.0: setting latency timer to 64
> > [ 10.001916] sky2 0000:08:00.0: Yukon-2 EC Ultra chip revision 3
> > [ 10.002022] sky2 0000:08:00.0: irq 47 for MSI/MSI-X
> > [ 10.002515] sky2 0000:08:00.0: eth0: addr 00:1d:ba:19:9e:db
> > [ 58.764733] sky2 0000:08:00.0: eth0: enabling interface
> > [ 638.178629] sky2 0000:08:00.0: eth0: Link is up at 100 Mbps, full
> > duplex, flow control rx
>
> The bug was resolved by:
> sky2: fix hang in napi_disable
>
> Stephen, two comments to you:
>
> 1) I really hoped to get some info about resolving this issue. You
> could just ping me that something worth testing was posted.
It was a duplicate of other bug report. Sorry you didn't get cc'd
on the bug fixes.
> 2) Update your e-mail address in MAINTAINERS please.
That patch went in just recently.
^ permalink raw reply
* Re: [PATCH 0/6] SUNRPC: make RPC clients use network-namespace-aware PipeFS routines
From: J. Bruce Fields @ 2011-11-23 16:27 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111123104945.11077.10270.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Wed, Nov 23, 2011 at 02:51:10PM +0300, Stanislav Kinsbursky wrote:
> This patch set was created in context of clone of git
> branch: git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git.
> tag: v3.1
>
> This patch set depends on previous patch sets titled:
> 1) "SUNRPC: initial part of making pipefs work in net ns"
> 2) "SUNPRC: cleanup PipeFS for network-namespace-aware users"
Do you have a git tree set up with all of these applied?
(If I want to take a quick look it would personally be easier for me to
fetch your git tree than to get those patches out of old email.)
--b.
>
> This patch set is a first part of reworking SUNPRC PipeFS users.
> It makes SUNRPC clients using PipeFS nofitications for directory and GSS pipes
> dentries creation. With this patch set RPC clients and GSS auth creations
> routines doesn't force SUNRPC PipeFS mount point creation which actually means,
> that they now can work without PipeFS dentries.
>
> The following series consists of:
>
> ---
>
> Stanislav Kinsbursky (6):
> SUNRPC: handle RPC client pipefs dentries by network namespace aware routines
> SUNRPC: handle GSS AUTH pipes by network namespace aware routines
> SUNRPC: subscribe RPC clients to pipefs notifications
> SUNRPC: remove RPC client pipefs dentries after unregister
> SUNRPC: remove RPC pipefs mount point manipulations from RPC clients code
> SUNRPC: remove RPC PipeFS mount point reference from RPC client
>
>
> fs/nfs/idmap.c | 4 +
> fs/nfsd/nfs4callback.c | 2 -
> include/linux/nfs.h | 2 -
> include/linux/sunrpc/auth.h | 2 +
> include/linux/sunrpc/clnt.h | 2 -
> net/sunrpc/auth_gss/auth_gss.c | 101 +++++++++++++++++++++------
> net/sunrpc/clnt.c | 151 +++++++++++++++++++++++++++++++---------
> net/sunrpc/rpc_pipe.c | 19 +++--
> net/sunrpc/sunrpc.h | 2 +
> 9 files changed, 218 insertions(+), 67 deletions(-)
>
> --
> Signature
--
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 0/6] SUNRPC: make RPC clients use network-namespace-aware PipeFS routines
From: J. Bruce Fields @ 2011-11-23 16:36 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
jbottomley-bzQdu9zFT3WakBO8gow8eQ, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111123104945.11077.10270.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Wed, Nov 23, 2011 at 02:51:10PM +0300, Stanislav Kinsbursky wrote:
> This patch set was created in context of clone of git
> branch: git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git.
> tag: v3.1
>
> This patch set depends on previous patch sets titled:
> 1) "SUNRPC: initial part of making pipefs work in net ns"
> 2) "SUNPRC: cleanup PipeFS for network-namespace-aware users"
>
> This patch set is a first part of reworking SUNPRC PipeFS users.
> It makes SUNRPC clients using PipeFS nofitications for directory and GSS pipes
> dentries creation. With this patch set RPC clients and GSS auth creations
> routines doesn't force SUNRPC PipeFS mount point creation which actually means,
> that they now can work without PipeFS dentries.
I'm not following very well. (My fault, I haven't been paying
attention.) Could you summarize the itended behavior of pipefs after
all this is done?
So there's a separate superblock (and separate dentries) for each
namespace?
What decides which clients are visible in which network namespaces?
--b.
>
> The following series consists of:
>
> ---
>
> Stanislav Kinsbursky (6):
> SUNRPC: handle RPC client pipefs dentries by network namespace aware routines
> SUNRPC: handle GSS AUTH pipes by network namespace aware routines
> SUNRPC: subscribe RPC clients to pipefs notifications
> SUNRPC: remove RPC client pipefs dentries after unregister
> SUNRPC: remove RPC pipefs mount point manipulations from RPC clients code
> SUNRPC: remove RPC PipeFS mount point reference from RPC client
>
>
> fs/nfs/idmap.c | 4 +
> fs/nfsd/nfs4callback.c | 2 -
> include/linux/nfs.h | 2 -
> include/linux/sunrpc/auth.h | 2 +
> include/linux/sunrpc/clnt.h | 2 -
> net/sunrpc/auth_gss/auth_gss.c | 101 +++++++++++++++++++++------
> net/sunrpc/clnt.c | 151 +++++++++++++++++++++++++++++++---------
> net/sunrpc/rpc_pipe.c | 19 +++--
> net/sunrpc/sunrpc.h | 2 +
> 9 files changed, 218 insertions(+), 67 deletions(-)
>
> --
> Signature
--
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
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