* Re: [RFC v2] fq_codel : interval servo on hosts
From: Eric Dumazet @ 2012-09-04 15:34 UTC (permalink / raw)
To: Nandita Dukkipati; +Cc: Tomas Hruby, netdev, codel
In-Reply-To: <CAB_+Fg5xPRqEZNdH0mYogmm4LitMvycSLB-X1_7ryn4RY9FvSA@mail.gmail.com>
On Tue, 2012-09-04 at 08:10 -0700, Nandita Dukkipati wrote:
> The idea of using srtt as interval makes sense to me if alongside we
> also hash flows with similar RTTs into same bucket. But with just the
> change in interval, I am not sure how codel is expected to behave.
>
> My understanding is: the interval (usually set to worst case expected
> RTT) is used to measure the standing queue or the "bad" queue. Suppose
> 1ms and 100ms RTT flows get hashed to same bucket, then the interval
> with this patch will flip flop between 1ms and 100ms. How is this
> expected to measure a standing queue? In fact I think the 1ms flow may
> land up measuring the burstiness or the "good" queue created by the
> long RTT flows, and this isn't desirable.
>
Well, how things settle with a pure codel, mixing flows of very
different RTT then ?
It seems there is a high resistance on SFQ/fq_codel model because of the
probabilities of flows sharing a bucket.
So what about removing the stochastic thing and switch to a hash with
collision resolution ?
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Steven Rostedt @ 2012-09-04 15:35 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, lw-BthXqXjhjHXQFUHtdCDX3A,
teigland-H+wXaHxf7aLQT0dZR+AlfA, Sasha Levin,
axboe-tSWWG44O7X1aa/9Udqfwiw, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <20120828230050.GA3337@Krystal>
On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
> Looking again at:
>
> +#define hash_for_each_size(name, bits, bkt, node, obj, member) \
> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++) \
> + hlist_for_each_entry(obj, node, &name[bkt], member)
>
> you will notice that a "break" or "continue" in the inner loop will not
> affect the outer loop, which is certainly not what the programmer would
> expect!
>
> I advise strongly against creating such error-prone construct.
>
A few existing loop macros do this. But they require a do { } while ()
approach, and all have a comment.
It's used by do_each_thread() in sched.h and ftrace does this as well.
Look at kernel/trace/ftrace.c at do_for_each_ftrace_rec().
Yes it breaks 'break' but it does not break 'continue' as it would just
go to the next item that would have been found (like a normal for
would).
-- Steve
^ permalink raw reply
* Re: [RFC v2] fq_codel : interval servo on hosts
From: Eric Dumazet @ 2012-09-04 15:39 UTC (permalink / raw)
To: Jonathan Morton
Cc: Nandita Dukkipati, netdev, codel@lists.bufferbloat.net,
Tomas Hruby
In-Reply-To: <1C18E243-42BC-46F0-A336-EAD9BC881C45@gmail.com>
On Tue, 2012-09-04 at 18:25 +0300, Jonathan Morton wrote:
> I think that in most cases, a long RTT flow and a short RTT flow on
> the same interface means that the long RTT flow isn't bottlenecked
> here, and therefore won't ever build up a significant queue - and that
> means you would want to track over the shorter interval. Is that a
> reasonable assumption?
>
This would be reasonable, but if we have a shorter interval, this means
we could drop packets of the long RTT flow sooner than expected.
Thats because the drop_next value is setup on the previous packet, and
not based on the 'next packet'
Re-evaluating drop_next at the right time would need more cpu cycles.
^ permalink raw reply
* Re: [iproute2][PATCH v2] tc: mirred target: do not report non-existing devices
From: Stephen Hemminger @ 2012-09-04 15:40 UTC (permalink / raw)
To: y; +Cc: netdev, Eric Dumazet, Dan Kenigsberg
In-Reply-To: <1346582882-14568-1-git-send-email-y>
On Sun, 2 Sep 2012 13:48:02 +0300
y@redhat.com wrote:
> From: Dan Kenigsberg <danken@redhat.com>
>
> Currently, if a mirred target device is removed, `tc filter show`
> does not reveal the fact. Instead, it replaces the original name of the
> device with the default output of ll_map:ll_idx_n2a().
>
> This is unfortunate, since one cannot differ between this case and a valid
> mirroring target device named 'if17'.
>
> It seems that the original code meant to report an error message in this
> case, but it does not, since ll_index_to_name() never returns 0. I would
> not like to bail out in case of an error, since the user would still be
> interested to know what are the other details of the action.
>
> v2: properly declare the new function ll_index_exsits()
I am okay with the concept but "missing-if1" is still a possible
but unlikely name for a device. Maybe better to use something more
obvious like [unknown-1] or UNKNOWN?
^ permalink raw reply
* Re: [PATCH] usbnet: drop unneeded check for NULL
From: Richard Cochran @ 2012-09-04 15:53 UTC (permalink / raw)
To: Oliver Neukum; +Cc: davem, netdev, Oliver Neukum
In-Reply-To: <1346768514-19823-1-git-send-email-oliver@neukum.org>
On Tue, Sep 04, 2012 at 04:21:54PM +0200, Oliver Neukum wrote:
> usbnet_start_xmit() is always called with a valid skb
So, has the problem that this test worked around been fixed?
Thanks,
Richard
> Signed-off-by: Oliver Neukum <oneukum@suse.de>
> ---
> drivers/net/usb/usbnet.c | 3 +--
> 1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/usbnet.c b/drivers/net/usb/usbnet.c
> index 8531c1c..5234d20 100644
> --- a/drivers/net/usb/usbnet.c
> +++ b/drivers/net/usb/usbnet.c
> @@ -1092,8 +1092,7 @@ netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
> unsigned long flags;
> int retval;
>
> - if (skb)
> - skb_tx_timestamp(skb);
> + skb_tx_timestamp(skb);
>
> // some devices want funky USB-level framing, for
> // win32 driver (usually) and/or hardware quirks
> --
> 1.7.7
>
> --
> 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: [PATCH 1/4] net: mvneta: driver for Marvell Armada 370/XP network unit
From: Thomas Petazzoni @ 2012-09-04 15:56 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Lior Amsalem, Andrew Lunn, Ike Pan, Nadav Haklai, Ian Molton,
Lennert Buytenhek, David Marlin, Rami Rosen, Yehuda Yitschak,
Jani Monoses, Tawfik Bayouk, Dan Frazier, Eran Ben-Avi, Li Li,
Leif Lindholm, Sebastian Hesselbarth, Jason Cooper, Jon Masters,
Ben Dooks, Gregory Clement, linux-arm-kernel, Chris Van Hoof,
Nicolas Pitre, netdev
In-Reply-To: <201209041436.36430.arnd@arndb.de>
Arnd,
Thanks for looking so quickly into this driver!
Le Tue, 4 Sep 2012 14:36:36 +0000,
Arnd Bergmann <arnd@arndb.de> a écrit :
> On Tuesday 04 September 2012, Thomas Petazzoni wrote:
> > .../devicetree/bindings/net/marvell-neta.txt | 24 +
> > drivers/net/ethernet/marvell/Kconfig | 11 +
> > drivers/net/ethernet/marvell/Makefile | 1 +
> > drivers/net/ethernet/marvell/mvneta.c | 2732 ++++++++++++++++++++
> > drivers/net/ethernet/marvell/mvneta.h | 496 ++++
> > 5 files changed, 3264 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/net/marvell-neta.txt
> > create mode 100644 drivers/net/ethernet/marvell/mvneta.c
> > create mode 100644 drivers/net/ethernet/marvell/mvneta.h
>
> I usually prefer putting the definitions into the .c file rather
> than a separate header if there is only only file including it
> anyway.
Fine. I hesitated on this one, but since the driver was already quite
long, I thought a separate header would be nicer, but I don't have a
strong opinion, so I'll resubmit with this change.
> > +eth@d0070000 {
> > + compatible = "marvell,neta";
> > + reg = <0xd0070000 0x2500>;
> > + interrupts = <8>;
> > + device_type = "network";
> > + clock-frequency = <250000000>;
> > + status = "okay";
> > + phy-mode = "sgmii";
> > + phy-addr = <25>;
>
> I think we normally put the phy into a separate device node on an
> mdio bus and then use the of_phy_* functions to connect it to
> the ethernet device.
Even though it may not be a convincing argument, none of the existing DT
files in arch/arm/boot/dts seem to instantiate a separate PHY device
and a proper MDIO bus. However, the PowerPC platforms indeed make this
distinction a lot clearer.
However, this network unit has a clever MAC that autonomously queries
the PHY for the link status, and reports changes (link, duplex, speed)
in the form of MAC interrupts and MAC registers. Therefore, for basic
operation, there is no need for a separate PHY driver nor to expose the
MDIO bus in any way. The only thing needed is the PHY address, which is
filled into a register of the MAC so that it can start its automatic
query of the PHY.
Knowing this, would it be acceptable to have this driver without an
explicit MDIO bus in the DT?
Thanks,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH] nl80211: [PATCH] nl80211: fix possible memory leak nl80211_connect()
From: Johannes Berg @ 2012-09-04 16:07 UTC (permalink / raw)
To: Wei Yongjun; +Cc: linville, davem, yongjun_wei, linux-wireless, netdev
In-Reply-To: <CAPgLHd_ykxWnV82swesivdEkyqP+a+hBgTTT8SXwn9RYWR1HFA@mail.gmail.com>
On Sun, 2012-09-02 at 21:41 +0800, Wei Yongjun wrote:
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> connkeys is malloced in nl80211_parse_connkeys() and should
> be freed in the error handling case, otherwise it will cause
> memory leak.
>
> spatch with a semantic match is used to found this problem.
> (http://coccinelle.lip6.fr/)
Applied, thanks. I fixed the subject for you :)
johannes
^ permalink raw reply
* Fw: [Bug 47021] New: kernel panic with l2tpv3 & mtu > 1500
From: Stephen Hemminger @ 2012-09-04 16:07 UTC (permalink / raw)
To: netdev
Begin forwarded message:
Date: Tue, 4 Sep 2012 16:06:06 +0000 (UTC)
From: bugzilla-daemon@bugzilla.kernel.org
To: shemminger@linux-foundation.org
Subject: [Bug 47021] New: kernel panic with l2tpv3 & mtu > 1500
https://bugzilla.kernel.org/show_bug.cgi?id=47021
Summary: kernel panic with l2tpv3 & mtu > 1500
Product: Networking
Version: 2.5
Kernel Version: 3.2.28
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
AssignedTo: shemminger@linux-foundation.org
ReportedBy: a1bert@atlas.cz
Regression: No
first l2tpv3 packet that enters physical device with MTU > 1500 causes kernel
panic
tunel created using:
l2tpv3tun add tunnel tunnel_id 1 peer_tunnel_id 1 encap udp udp_sport 5001
udp_dport 5001 local 192.168.1.1 remote 192.168.1.2
l2tpv3tun add session tunnel_id 1 session_id 1 peer_session_id 1 dev l2tpeth1
reproducible: always
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Protected Project
From: Kim @ 2012-09-04 15:59 UTC (permalink / raw)
--
Dear Friend
I want to discuss an important issue with you .
I write to know if this is your valid email.
Please, let me know if your email is still valid.
KimJr
^ permalink raw reply
* Re: [PATCH] usbnet: drop unneeded check for NULL
From: Oliver Neukum @ 2012-09-04 16:13 UTC (permalink / raw)
To: Richard Cochran; +Cc: davem, netdev
In-Reply-To: <20120904155343.GA2170@netboy.at.omicron.at>
On Tuesday 04 September 2012 17:53:43 Richard Cochran wrote:
> On Tue, Sep 04, 2012 at 04:21:54PM +0200, Oliver Neukum wrote:
> > usbnet_start_xmit() is always called with a valid skb
>
> So, has the problem that this test worked around been fixed?
netdev_tx_t usbnet_start_xmit (struct sk_buff *skb,
struct net_device *net)
{
struct usbnet *dev = netdev_priv(net);
int length;
struct urb *urb = NULL;
struct skb_data *entry;
struct driver_info *info = dev->driver_info;
unsigned long flags;
int retval;
if (skb)
skb_tx_timestamp(skb);
// some devices want funky USB-level framing, for
// win32 driver (usually) and/or hardware quirks
if (info->tx_fixup) {
skb = info->tx_fixup (dev, skb, GFP_ATOMIC);
if (!skb) {
if (netif_msg_tx_err(dev)) {
netif_dbg(dev, tx_err, dev->net, "can't tx_fixup skb\n");
goto drop;
} else {
/* cdc_ncm collected packet; waits for more */
goto not_drop;
}
}
}
length = skb->len;
If that check is ever needed and tx_fixup not needed, the driver will oops here.
The check is wrong in any case.
Regards
Oliver
^ permalink raw reply
* Re: [PATCH v2] netfilter: take care of timewait sockets
From: David Miller @ 2012-09-04 16:16 UTC (permalink / raw)
To: eric.dumazet; +Cc: fw, hvtaifwkbgefbaei, netdev
In-Reply-To: <1346745325.13121.4.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 04 Sep 2012 09:55:25 +0200
> This patch was marked "Not applicable" in Patchwork
> ( http://patchwork.ozlabs.org/patch/181275/ )
>
> It seems a mistake, since it should be applied ?
Not applicable can mean "doesn't go through my tree"
This is netfilter stuff, so please submit it via the
netfilter folks :-)
^ permalink raw reply
* Re: Commit "ipconfig wait for carrier" makes boot hang for 2 mins if no carrier
From: Micha Nelissen @ 2012-09-04 16:09 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF61EF9E6E.9EF08C21-ONC1257A6F.004FE9B4-C1257A6F.0050A9B2@transmode.se>
Op 2012-09-04 16:41, Joakim Tjernlund schreef:
> Above mentioned commit(3fb72f1e6e6165c5f495e8dc11c5bbd14c73385c) changes
> a ~1 sec delay to ~120 sec boot delay if no carrier. This is a really
> long time to wait if you just want to set an IP address but doesn't
> care about NFS root, holds up the boot with 2 minutes.
Why not set the IP address then in your rootfs yourself?
Micha
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Pedro Alves @ 2012-09-04 16:30 UTC (permalink / raw)
To: Steven Rostedt
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, lw-BthXqXjhjHXQFUHtdCDX3A,
Mathieu Desnoyers, Sasha Levin, axboe-tSWWG44O7X1aa/9Udqfwiw,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <1346772948.27919.9.camel-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
On 09/04/2012 04:35 PM, Steven Rostedt wrote:
> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
>
>> Looking again at:
>>
>> +#define hash_for_each_size(name, bits, bkt, node, obj, member) \
>> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++) \
>> + hlist_for_each_entry(obj, node, &name[bkt], member)
>>
>> you will notice that a "break" or "continue" in the inner loop will not
>> affect the outer loop, which is certainly not what the programmer would
>> expect!
>>
>> I advise strongly against creating such error-prone construct.
>>
>
> A few existing loop macros do this. But they require a do { } while ()
> approach, and all have a comment.
>
> It's used by do_each_thread() in sched.h and ftrace does this as well.
> Look at kernel/trace/ftrace.c at do_for_each_ftrace_rec().
>
> Yes it breaks 'break' but it does not break 'continue' as it would just
> go to the next item that would have been found (like a normal for
> would).
/*
* This is a double for. Do not use 'break' to break out of the loop,
* you must use a goto.
*/
#define do_for_each_ftrace_rec(pg, rec) \
for (pg = ftrace_pages_start; pg; pg = pg->next) { \
int _____i; \
for (_____i = 0; _____i < pg->index; _____i++) { \
rec = &pg->records[_____i];
You can make 'break' also work as expected if you can embed a little knowledge
of the inner loop's condition in the outer loop's condition. Sometimes it's
trivial, most often when the inner loop's iterator is a pointer that goes
NULL at the end, but other times not so much. Something like (completely untested):
#define do_for_each_ftrace_rec(pg, rec) \
for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
pg && rec == &pg->records[pg->index]; \
pg = pg->next) { \
int _____i; \
for (_____i = 0; _____i < pg->index; _____i++) { \
rec = &pg->records[_____i];
(other variants possible)
IOW, the outer loop only iterates if the inner loop completes. If there's
a break in the inner loop, then the outer loop breaks too. Of course, it
all depends on whether the generated code looks sane or hideous, if
the uses of the macro care for it over bug avoidance.
--
Pedro Alves
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Mathieu Desnoyers @ 2012-09-04 16:32 UTC (permalink / raw)
To: Steven Rostedt
Cc: Sasha Levin, Tejun Heo, torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
davem-fT/PcQaiUtIeIZ0/mPfg9Q, mingo-X9Un+BFzKDI,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, aarcange-H+wXaHxf7aLQT0dZR+AlfA,
ericvh-Re5JQEeQqe8AvxtiuMwx3w, netdev-u79uwXL29TY76Z2rM5mHXA,
josh-iaAMLnmF4UmaiuxdJuQwMA, eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
axboe-tSWWG44O7X1aa/9Udqfwiw, agk-H+wXaHxf7aLQT0dZR+AlfA,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw, fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
jesse-l0M0P4e3n4LQT0dZR+AlfA,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ejt-H+wXaHxf7aLQT0dZR+AlfA, snitzer-H+wXaHxf7aLQT0dZR+AlfA,
edumazet-hpIqsD4AKlfQT0dZR+AlfA, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
dev-yBygre7rU0TnMu66kgdUjQ, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
lw-BthXqXjhjHXQFUHtdCDX3A
In-Reply-To: <1346772948.27919.9.camel-f9ZlEuEWxVcJvu8Pb33WZ0EMvNT87kid@public.gmane.org>
* Steven Rostedt (rostedt-nx8X9YLhiw1AfugRpC6u6w@public.gmane.org) wrote:
> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
>
> > Looking again at:
> >
> > +#define hash_for_each_size(name, bits, bkt, node, obj, member) \
> > + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++) \
> > + hlist_for_each_entry(obj, node, &name[bkt], member)
> >
> > you will notice that a "break" or "continue" in the inner loop will not
> > affect the outer loop, which is certainly not what the programmer would
> > expect!
> >
> > I advise strongly against creating such error-prone construct.
> >
>
> A few existing loop macros do this. But they require a do { } while ()
> approach, and all have a comment.
>
> It's used by do_each_thread() in sched.h
Yes. It's worth noting that it is a do_each_thread() /
while_each_thread() pair.
> and ftrace does this as well.
> Look at kernel/trace/ftrace.c at do_for_each_ftrace_rec().
Same here.
>
> Yes it breaks 'break' but it does not break 'continue' as it would just
> go to the next item that would have been found (like a normal for
> would).
Good point.
So would changing hash_for_each_size() to a
do_each_hash_size()/while_each_hash_size() make it clearer that this
contains a double-loop ? (along with an appropriate comment about
break).
Thanks,
Mathieu
>
> -- Steve
>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
--
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] usbnet: drop unneeded check for NULL
From: David Miller @ 2012-09-04 16:37 UTC (permalink / raw)
To: oliver; +Cc: richardcochran, netdev
In-Reply-To: <20747715.9FmHp7X6VE@linux-lqwf.site>
From: Oliver Neukum <oliver@neukum.org>
Date: Tue, 04 Sep 2012 18:13:18 +0200
> If that check is ever needed and tx_fixup not needed, the driver will oops here.
> The check is wrong in any case.
Right, we are dealing with two different things here.
Tree-wide there was a blind set of changes to protect skb_tx_timestamp()
calls with a NULL skb check.
But in this specific case, it's completely unnecessary.
So Oliver's change is definitely correct and I will add it to net-next
Thanks.
^ permalink raw reply
* Re: [RFC] packet: change call of synchronize_net to call_rcu
From: David Miller @ 2012-09-04 16:38 UTC (permalink / raw)
To: danborkmann
Cc: iulius.curt, edumazet, xemul, netdev, linux-kernel, dbaluta,
icurt, sdumitru
In-Reply-To: <CAD6jFUSa7gD45m7WdtDymJq-WkGq+kbofkws5n3dGMtuDE6d3A@mail.gmail.com>
From: Daniel Borkmann <danborkmann@iogearbox.net>
Date: Tue, 4 Sep 2012 16:53:06 +0200
> On Tue, Sep 4, 2012 at 4:16 PM, Iulius Curt <iulius.curt@gmail.com> wrote:
>> synchronize_net is called every time we close a PF_PACKET socket which is
>> causing performance loss when doing this on many sockets.
>
> Do you have any particular use case in mind?
I'm curious about this too, it seems rediculous to optimize for this
and that only seriously mis-designed userspace would do something like
this.
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Pedro Alves @ 2012-09-04 16:40 UTC (permalink / raw)
Cc: Steven Rostedt, Mathieu Desnoyers, Sasha Levin, Tejun Heo,
torvalds, akpm, linux-kernel, linux-mm, paul.gortmaker, davem,
mingo, ebiederm, aarcange, ericvh, netdev, josh, eric.dumazet,
axboe, agk, dm-devel, neilb, ccaulfie, teigland, Trond.Myklebust,
bfields, fweisbec, jesse, venkat.x.venkatsubra, ejt, snitzer,
edumazet, linux-nfs, dev
In-Reply-To: <50462C99.5000007@redhat.com>
On 09/04/2012 05:30 PM, Pedro Alves wrote:
> On 09/04/2012 04:35 PM, Steven Rostedt wrote:
>> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
>>
>>> Looking again at:
>>>
>>> +#define hash_for_each_size(name, bits, bkt, node, obj, member) \
>>> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++) \
>>> + hlist_for_each_entry(obj, node, &name[bkt], member)
>>>
>>> you will notice that a "break" or "continue" in the inner loop will not
>>> affect the outer loop, which is certainly not what the programmer would
>>> expect!
>>>
>>> I advise strongly against creating such error-prone construct.
>>>
>>
>> A few existing loop macros do this. But they require a do { } while ()
>> approach, and all have a comment.
>>
>> It's used by do_each_thread() in sched.h and ftrace does this as well.
>> Look at kernel/trace/ftrace.c at do_for_each_ftrace_rec().
>>
>> Yes it breaks 'break' but it does not break 'continue' as it would just
>> go to the next item that would have been found (like a normal for
>> would).
>
> /*
> * This is a double for. Do not use 'break' to break out of the loop,
> * you must use a goto.
> */
> #define do_for_each_ftrace_rec(pg, rec) \
> for (pg = ftrace_pages_start; pg; pg = pg->next) { \
> int _____i; \
> for (_____i = 0; _____i < pg->index; _____i++) { \
> rec = &pg->records[_____i];
>
>
>
> You can make 'break' also work as expected if you can embed a little knowledge
> of the inner loop's condition in the outer loop's condition. Sometimes it's
> trivial, most often when the inner loop's iterator is a pointer that goes
> NULL at the end, but other times not so much. Something like (completely untested):
>
> #define do_for_each_ftrace_rec(pg, rec) \
> for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
> pg && rec == &pg->records[pg->index]; \
> pg = pg->next) { \
> int _____i; \
> for (_____i = 0; _____i < pg->index; _____i++) { \
> rec = &pg->records[_____i];
>
>
> (other variants possible)
>
> IOW, the outer loop only iterates if the inner loop completes. If there's
> a break in the inner loop, then the outer loop breaks too. Of course, it
> all depends on whether the generated code looks sane or hideous, if
> the uses of the macro care for it over bug avoidance.
>
BTW, you can also go a step further and remove the need to close with double }},
with something like:
#define do_for_each_ftrace_rec(pg, rec) \
for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
pg && rec == &pg->records[pg->index]; \
pg = pg->next) \
for (rec = pg->records; rec < &pg->records[pg->index]; rec++)
--
Pedro Alves
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [RFC v2] fq_codel : interval servo on hosts
From: Dave Taht @ 2012-09-04 16:40 UTC (permalink / raw)
To: Eric Dumazet
Cc: Nandita Dukkipati, Yuchung Cheng, codel, Kathleen Nichols, netdev,
Tomas Hruby
In-Reply-To: <1346772855.13121.40.camel@edumazet-glaptop>
On Tue, Sep 4, 2012 at 8:34 AM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2012-09-04 at 08:10 -0700, Nandita Dukkipati wrote:
>> The idea of using srtt as interval makes sense to me if alongside we
>> also hash flows with similar RTTs into same bucket. But with just the
>> change in interval, I am not sure how codel is expected to behave.
>>
>> My understanding is: the interval (usually set to worst case expected
>> RTT) is used to measure the standing queue or the "bad" queue. Suppose
>> 1ms and 100ms RTT flows get hashed to same bucket, then the interval
>> with this patch will flip flop between 1ms and 100ms. How is this
>> expected to measure a standing queue? In fact I think the 1ms flow may
>> land up measuring the burstiness or the "good" queue created by the
>> long RTT flows, and this isn't desirable.
Experiments would be good.
>
> Well, how things settle with a pure codel, mixing flows of very
> different RTT then ?
Elephants are shot statistically more often than mice.
> It seems there is a high resistance on SFQ/fq_codel model because of the
> probabilities of flows sharing a bucket.
I was going to do this in a separate email, because it is a little off-topic.
fq_codel has a standing queue problem, based on the fact that when a
queue empties, codel.h resets. This made sense for the single FIFO
codel but not multi-queued fq_codel. So after we hit X high rate
flows, target can never be achieved, even straining mightily, and we
end up with a standing queue again.
Easily seen with like 150 bidirectional flows at 10 or 100Mbit.
(as queues go, it's still pretty good queue. And: I've fiddled with
various means of draining multi-queue behavior thus far, and they
ended up unstable/unfair)
> So what about removing the stochastic thing and switch to a hash with
> collision resolution ?
Was considered and discarded in the original SFQ paper as being too
computationally intensive
(in 1993). Worth revisiting.
http://www2.rdrop.com/~paulmck/scalability/paper/sfq.2002.06.04.pdf
>
>
--
Dave Täht
http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out
with fq_codel!"
^ permalink raw reply
* Re: [RFC v2] fq_codel : interval servo on hosts
From: Eric Dumazet @ 2012-09-04 16:54 UTC (permalink / raw)
To: Dave Taht; +Cc: Tomas Hruby, Nandita Dukkipati, netdev, codel
In-Reply-To: <CAA93jw6k4pgwanTa81oHb8jV6WGMfoo6KuOBSjbrfU3eRMbt5A@mail.gmail.com>
On Tue, 2012-09-04 at 09:40 -0700, Dave Taht wrote:
> >
> > Well, how things settle with a pure codel, mixing flows of very
> > different RTT then ?
>
> Elephants are shot statistically more often than mice.
This doesnt answer the question.
long/short RTT have nothing to do with elephant and mice.
^ permalink raw reply
* Re: [RFC v2] fq_codel : interval servo on hosts
From: Eric Dumazet @ 2012-09-04 16:57 UTC (permalink / raw)
To: Dave Taht; +Cc: Tomas Hruby, Nandita Dukkipati, netdev, codel
In-Reply-To: <CAA93jw6k4pgwanTa81oHb8jV6WGMfoo6KuOBSjbrfU3eRMbt5A@mail.gmail.com>
On Tue, 2012-09-04 at 09:40 -0700, Dave Taht wrote:
> fq_codel has a standing queue problem, based on the fact that when a
> queue empties, codel.h resets. This made sense for the single FIFO
> codel but not multi-queued fq_codel. So after we hit X high rate
> flows, target can never be achieved, even straining mightily, and we
> end up with a standing queue again.
>
> Easily seen with like 150 bidirectional flows at 10 or 100Mbit.
>
> (as queues go, it's still pretty good queue. And: I've fiddled with
> various means of draining multi-queue behavior thus far, and they
> ended up unstable/unfair)
No idea of what you mean by "codel.h resets".
Please use small mails, one idea by mail.
^ permalink raw reply
* Re: [PATCH] netrom: copy_datagram_iovec can fail
From: David Miller @ 2012-09-04 16:58 UTC (permalink / raw)
To: alan; +Cc: netdev
In-Reply-To: <20120904141315.26374.38822.stgit@localhost.localdomain>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Tue, 04 Sep 2012 15:13:18 +0100
> From: Alan Cox <alan@linux.intel.com>
>
> Check for an error from this and if so bail properly.
>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Applied and queued up for -stable, thanks Alan.
^ permalink raw reply
* Re: v3 for tcp friends?
From: David Miller @ 2012-09-04 16:58 UTC (permalink / raw)
To: brutus; +Cc: netdev
In-Reply-To: <CAEkNxbGJ6OGy3HDSeToXO_cDt7azpRZvy_CbQH0_UJ_mCS2s3w@mail.gmail.com>
From: Bruce Curtis <brutus@google.com>
Date: Tue, 4 Sep 2012 08:10:23 -0700
> Will do, issues addressed, I'll get the patch out later today or
> tomorrow at the latest.
Thanks a lot Bruce.
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Mathieu Desnoyers @ 2012-09-04 17:01 UTC (permalink / raw)
To: Pedro Alves
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, Steven Rostedt,
lw-BthXqXjhjHXQFUHtdCDX3A, teigland-H+wXaHxf7aLQT0dZR+AlfA,
Sasha Levin, axboe-tSWWG44O7X1aa/9Udqfwiw,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <50462EE8.1090903-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
* Pedro Alves (palves-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org) wrote:
> On 09/04/2012 05:30 PM, Pedro Alves wrote:
> > On 09/04/2012 04:35 PM, Steven Rostedt wrote:
> >> On Tue, 2012-08-28 at 19:00 -0400, Mathieu Desnoyers wrote:
> >>
> >>> Looking again at:
> >>>
> >>> +#define hash_for_each_size(name, bits, bkt, node, obj, member) \
> >>> + for (bkt = 0; bkt < HASH_SIZE(bits); bkt++) \
> >>> + hlist_for_each_entry(obj, node, &name[bkt], member)
> >>>
> >>> you will notice that a "break" or "continue" in the inner loop will not
> >>> affect the outer loop, which is certainly not what the programmer would
> >>> expect!
> >>>
> >>> I advise strongly against creating such error-prone construct.
> >>>
> >>
> >> A few existing loop macros do this. But they require a do { } while ()
> >> approach, and all have a comment.
> >>
> >> It's used by do_each_thread() in sched.h and ftrace does this as well.
> >> Look at kernel/trace/ftrace.c at do_for_each_ftrace_rec().
> >>
> >> Yes it breaks 'break' but it does not break 'continue' as it would just
> >> go to the next item that would have been found (like a normal for
> >> would).
> >
> > /*
> > * This is a double for. Do not use 'break' to break out of the loop,
> > * you must use a goto.
> > */
> > #define do_for_each_ftrace_rec(pg, rec) \
> > for (pg = ftrace_pages_start; pg; pg = pg->next) { \
> > int _____i; \
> > for (_____i = 0; _____i < pg->index; _____i++) { \
> > rec = &pg->records[_____i];
> >
> >
> >
> > You can make 'break' also work as expected if you can embed a little knowledge
> > of the inner loop's condition in the outer loop's condition. Sometimes it's
> > trivial, most often when the inner loop's iterator is a pointer that goes
> > NULL at the end, but other times not so much. Something like (completely untested):
> >
> > #define do_for_each_ftrace_rec(pg, rec) \
> > for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
> > pg && rec == &pg->records[pg->index]; \
> > pg = pg->next) { \
> > int _____i; \
> > for (_____i = 0; _____i < pg->index; _____i++) { \
> > rec = &pg->records[_____i];
> >
> >
> > (other variants possible)
> >
> > IOW, the outer loop only iterates if the inner loop completes. If there's
> > a break in the inner loop, then the outer loop breaks too. Of course, it
> > all depends on whether the generated code looks sane or hideous, if
> > the uses of the macro care for it over bug avoidance.
> >
>
> BTW, you can also go a step further and remove the need to close with double }},
> with something like:
>
> #define do_for_each_ftrace_rec(pg, rec) \
> for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
> pg && rec == &pg->records[pg->index]; \
> pg = pg->next) \
> for (rec = pg->records; rec < &pg->records[pg->index]; rec++)
Maybe in some cases there might be ways to combine the two loops into
one ? I'm not seeing exactly how to do it for this one, but it should
not be impossible. If the inner loop condition can be moved to the outer
loop, and if we use (blah ? loop1_conf : loop2_cond) to test for
different conditions depending on the context, and do the same for the
3rd argument of the for() loop. The details elude me for now though, so
maybe it's complete non-sense ;)
It might not be that useful for do_for_each_ftrace_rec, but if we can do
it for the hash table iterator, it might be worth it.
Thanks,
Mathieu
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: sctp_close/sk_free: kernel BUG at arch/x86/mm/physaddr.c:18!
From: Marc Kleine-Budde @ 2012-09-04 17:10 UTC (permalink / raw)
To: Fengguang Wu; +Cc: networking, linux-can, ebiederm
In-Reply-To: <20120904140411.GB15068@localhost>
[-- Attachment #1: Type: text/plain, Size: 4078 bytes --]
On 09/04/2012 04:04 PM, Fengguang Wu wrote:
> FYI, another kconfig triggering a slightly different oops on tree
>
> git://gitorious.org/linux-can/linux-can-next led-trigger
This in turn means the problem doesn't come from the CAN patches, as
both trees have different CAN patches. I'm adding Eric W. Biederman on
Cc as he contributed some sctp patches between v3.6 and net-next/master.
Marc
>
> [ 96.267311] ------------[ cut here ]------------
> [ 96.268294] kernel BUG at /c/kernel-tests/src/stable/arch/x86/mm/physaddr.c:18!
> [ 96.269988] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
> [ 96.270636] Modules linked in:
> [ 96.270636] CPU 0
> [ 96.270636] Pid: 2116, comm: trinity Not tainted 3.6.0-rc3+ #2679 Bochs Bochs
> [ 96.270636] RIP: 0010:[<ffffffff8102b22b>] [<ffffffff8102b22b>] __phys_addr+0x46/0x6b
> [ 96.270636] RSP: 0018:ffff880019585c98 EFLAGS: 00010213
> [ 96.270636] RAX: ffff87ffffffffff RBX: 0000ea6000000bb8 RCX: 0000000000000000
> [ 96.270636] RDX: 0000000000000000 RSI: 0000000000000296 RDI: 0000ea6000000bb8
> [ 96.270636] RBP: ffff880019585c98 R08: 0000000000000058 R09: 0000000000000008
> [ 96.270636] R10: 000000000000000a R11: 0000000000000058 R12: ffff8800195f7718
> [ 96.270636] R13: ffffffff816521cf R14: ffffea0000000000 R15: 0000000000000000
> [ 96.270636] FS: 00007fa19b534700(0000) GS:ffff88001f200000(0000) knlGS:0000000000000000
> [ 96.270636] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 96.270636] CR2: 00007fa19b03eba0 CR3: 000000001957b000 CR4: 00000000000006f0
> [ 96.270636] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [ 96.270636] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> [ 96.270636] Process trinity (pid: 2116, threadinfo ffff880019584000, task ffff88001af2c680)
> [ 96.270636] Stack:
> [ 96.270636] ffff880019585cd8 ffffffff811091d7 0000000000000000 ffff88001b1ef200
> [ 96.270636] ffff88001b1ef4d0 0000000000000000 ffff88001b1617b0 0000000000000000
> [ 96.270636] ffff880019585cf8 ffffffff816521cf ffff88001b1ef200 ffff88001b1ef248
> [ 96.270636] Call Trace:
> [ 96.270636] [<ffffffff811091d7>] kfree+0x63/0x162
> [ 96.270636] [<ffffffff816521cf>] inet_sock_destruct+0x112/0x1ca
> [ 96.270636] [<ffffffff815f6fa4>] __sk_free+0x1d/0x114
> [ 96.270636] [<ffffffff815f710b>] sk_free+0x1c/0x1e
> [ 96.270636] [<ffffffff816d59d5>] sctp_close+0x21a/0x229
> [ 96.270636] [<ffffffff810810f6>] ? lock_release_holdtime.part.6+0xb2/0xb7
> [ 96.270636] [<ffffffff81651b3e>] ? inet_release+0x65/0xc3
> [ 96.270636] [<ffffffff81651b93>] inet_release+0xba/0xc3
> [ 96.270636] [<ffffffff81651af9>] ? inet_release+0x20/0xc3
> [ 96.270636] [<ffffffff81674134>] inet6_release+0x30/0x3c
> [ 96.270636] [<ffffffff815f2317>] sock_release+0x1f/0x77
> [ 96.270636] [<ffffffff815f2396>] sock_close+0x27/0x2b
> [ 96.270636] [<ffffffff8110ec22>] __fput+0xf0/0x24b
> [ 96.270636] [<ffffffff8110ed8b>] ____fput+0xe/0x10
> [ 96.270636] [<ffffffff8104f370>] task_work_run+0x5d/0x75
> [ 96.270636] [<ffffffff81038a66>] do_exit+0x26b/0x7d7
> [ 96.270636] [<ffffffff81725a95>] ? retint_swapgs+0x13/0x1b
> [ 96.270636] [<ffffffff8103925b>] do_group_exit+0x7b/0xba
> [ 96.270636] [<ffffffff810392b1>] sys_exit_group+0x17/0x17
> [ 96.270636] [<ffffffff8172c78e>] tracesys+0xd0/0xd5
> [ 96.270636] Code: 00 80 48 01 c7 48 81 ff ff ff ff 1f 76 02 0f 0b 48 89 f8 48 03 05 f6 bd ae 00 eb 32 48 b8 ff ff ff ff ff 87 ff ff 48 39 c7 77 02 <0f> 0b 0f b6 0d 55 57 ba 00 48 b8 00 00 00 00 00 78 00 00 48 01
> [ 96.270636] RIP [<ffffffff8102b22b>] __phys_addr+0x46/0x6b
> [ 96.270636] RSP <ffff880019585c98>
>
> Thanks,
> Fengguang
>
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH v3 01/17] hashtable: introduce a small and naive hashtable
From: Steven Rostedt @ 2012-09-04 17:17 UTC (permalink / raw)
To: Pedro Alves
Cc: snitzer-H+wXaHxf7aLQT0dZR+AlfA, neilb-l3A5Bk7waGM,
fweisbec-Re5JQEeQqe8AvxtiuMwx3w,
Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
bfields-uC3wQj2KruNg9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA, agk-H+wXaHxf7aLQT0dZR+AlfA,
aarcange-H+wXaHxf7aLQT0dZR+AlfA, rds-devel-N0ozoZBvEnrZJqsBc5GL+g,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w,
venkat.x.venkatsubra-QHcLZuEGTsvQT0dZR+AlfA,
ccaulfie-H+wXaHxf7aLQT0dZR+AlfA, mingo-X9Un+BFzKDI,
dev-yBygre7rU0TnMu66kgdUjQ, ericvh-Re5JQEeQqe8AvxtiuMwx3w,
josh-iaAMLnmF4UmaiuxdJuQwMA, lw-BthXqXjhjHXQFUHtdCDX3A,
Mathieu Desnoyers, Sasha Levin, axboe-tSWWG44O7X1aa/9Udqfwiw,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, edumazet-hpIqsD4AKlfQT0dZR+AlfA,
linux-mm-Bw31MaZKKs3YtjvyW6yDsg, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, ejt-H+wXaHxf7aLQT0dZR+AlfA,
ebiederm-aS9lmoZGLiVWk0Htik3J/w, Tejun Heo,
teigland-H+wXaHxf7aLQT0dZR+AlfA,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
davem-fT/PcQaiUtIeIZ0/mPfg9Q
In-Reply-To: <50462EE8.1090903-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Tue, 2012-09-04 at 17:40 +0100, Pedro Alves wrote:
> BTW, you can also go a step further and remove the need to close with double }},
> with something like:
>
> #define do_for_each_ftrace_rec(pg, rec) \
> for (pg = ftrace_pages_start, rec = &pg->records[pg->index]; \
> pg && rec == &pg->records[pg->index]; \
> pg = pg->next) \
> for (rec = pg->records; rec < &pg->records[pg->index]; rec++)
>
Yeah, but why bother? It's hidden in a macro, and the extra '{ }' shows
that this is something "special".
-- Steve
^ 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