* Re: Introduce FCLONE_SCRATCH skbs to reduce stack memory useage and napi jitter
From: Eric Dumazet @ 2011-10-28 2:37 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller
In-Reply-To: <20111028013729.GA6524@neilslaptop.think-freely.org>
Le jeudi 27 octobre 2011 à 21:37 -0400, Neil Horman a écrit :
> >
> Yes, I'd experimented with some of this, and had mixed results. Specifically I
> came up with a way to use the additional space as an array of list heads, with
> backpointers to the socket_queue each list_head was owned by and the skb that
> owned the entry. It was nice because it let me enqueue the same skb to hundreds
> of sockets at the same time, which was really nice. It was bad however, because
> it completely broke socket accounting (any likely anything else that required on
> any part of the socket state). Any thoughts on ways I might improve on that.
> If I could make some sort of reduced sk_buff so that I didn't have to allocate
> all 256 bytes of a full sk_buff, that would be great!
It seems your objectives are contradictory (memory saving and cpu
saving). Most of the time we have to fight false sharing first.
I dont want to try to use the available space from skb, since its cache
unfriendly, in case you have one CPU 100% in softirq handling,
dispatching messages to XX other application cpus.
You dont want each application cpu slowing down other cpus by
manipulating a list anchor, contained in a shared cache line, highly
contended. We already have one high contention point (skb refcount or
data refcount).
Another point of interest is that modern NIC tend to use paged frag
skbs, with very litle space available in skb head. frag part is
readonly, and sometime with no available space neither.
So your idea only works on some (old gen) nics and some narrow
conditions.
I believe it adds too much complex code for this.
I understand you are disappointed, but maybe you should have shared your
ideas before coding them !
^ permalink raw reply
* Re: [PATCH net -v2] [BUGFIX] bonding: use flush_delayed_work_sync in bond_close
From: HAYASAKA Mitsuo @ 2011-10-28 1:52 UTC (permalink / raw)
To: Jay Vosburgh
Cc: netdev, Américo Wang, Stephen Hemminger, Andy Gospodarek,
linux-kernel, yrl.pp-manager.tt
In-Reply-To: <2216.1319650260@death>
Hi Joy,
I checked your patch, and any problems have not been observed for
almost one day although I could reproduce the BUG in the latest net-next
without it.
I think this patch works well.
Tested-by: Mitsuo Hayasaka <mitsuo.hayasaka.hu@hitachi.com>
(2011/10/27 2:31), Jay Vosburgh wrote:
> HAYASAKA Mitsuo <mitsuo.hayasaka.hu@hitachi.com> wrote:
> [...]
>> The interval of mii_mon was set to 1 to reproduce this bug easily and
>> the 802.3ad mode was used. Then, I executed the following command.
>>
>> # while true; do ifconfig bond0 down; done &
>> # while true; do ifconfig bond0 up; done &
>>
>> This bug rarely occurs since it is the severe timing problem.
>> I found that it is more easily to reproduce this bug when using guest OS.
>>
>> For example, it took one to three days for me to reproduce it on host OS,
>> but some hours on guest OS.
>
> Could you test this patch and see if it resolves the problem?
>
> This patch does a few things:
>
> All of the monitor functions that run on work queues are
> modified to never unconditionally acquire RTNL; all will reschedule the
> work and return if rtnl_trylock fails. This covers bond_mii_monitor,
> bond_activebackup_arp_mon, and bond_alb_monitor.
>
> The "clear out the work queues" calls in bond_close and
> bond_uninit now call cancel_delayed_work_sync, which should either
> delete a pending work item, or wait for an executing item to complete.
> I chose cancel_ over the original patch's flush_ because we just want
> the work queue stopped. We don't need to have any pending items execute
> if they're not already running.
>
> Also in reference to the previous, I'm not sure if we still need
> to check for delayed_work_pending, but I've left those checks in place.
>
> Remove the "kill_timers" field and all references to it. If
> cancel_delayed_work_sync is safe to use, we do not need an extra
> sentinel.
>
> Lastly, for testing purposes only, the bond_alb_monitor in this
> patch includes an unconditional call to rtnl_trylock(); this is an
> artifical way to make the race in that function easier to test for,
> because the real race is very difficult to hit.
>
> This patch is against net-next as of yesterday.
>
> Comments?
>
> -J
>
>
> diff --git a/drivers/net/bonding/bond_3ad.c b/drivers/net/bonding/bond_3ad.c
> index b33c099..0ae0d7c 100644
> --- a/drivers/net/bonding/bond_3ad.c
> +++ b/drivers/net/bonding/bond_3ad.c
> @@ -2110,9 +2110,6 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
>
> read_lock(&bond->lock);
>
> - if (bond->kill_timers)
> - goto out;
> -
> //check if there are any slaves
> if (bond->slave_cnt == 0)
> goto re_arm;
> @@ -2161,9 +2158,8 @@ void bond_3ad_state_machine_handler(struct work_struct *work)
> }
>
> re_arm:
> - if (!bond->kill_timers)
> - queue_delayed_work(bond->wq, &bond->ad_work, ad_delta_in_ticks);
> -out:
> + queue_delayed_work(bond->wq, &bond->ad_work, ad_delta_in_ticks);
> +
> read_unlock(&bond->lock);
> }
>
> diff --git a/drivers/net/bonding/bond_alb.c b/drivers/net/bonding/bond_alb.c
> index d4fbd2e..13d1bf9 100644
> --- a/drivers/net/bonding/bond_alb.c
> +++ b/drivers/net/bonding/bond_alb.c
> @@ -1343,10 +1343,6 @@ void bond_alb_monitor(struct work_struct *work)
>
> read_lock(&bond->lock);
>
> - if (bond->kill_timers) {
> - goto out;
> - }
> -
> if (bond->slave_cnt == 0) {
> bond_info->tx_rebalance_counter = 0;
> bond_info->lp_counter = 0;
> @@ -1394,6 +1390,14 @@ void bond_alb_monitor(struct work_struct *work)
> bond_info->tx_rebalance_counter = 0;
> }
>
> + /* XXX - unconditional attempt at RTNL for testing purposes, as
> + * normal case, below, is difficult to induce.
> + */
> + read_unlock(&bond->lock);
> + if (rtnl_trylock())
> + rtnl_unlock();
> + read_lock(&bond->lock);
> +
> /* handle rlb stuff */
> if (bond_info->rlb_enabled) {
> if (bond_info->primary_is_promisc &&
> @@ -1404,7 +1408,10 @@ void bond_alb_monitor(struct work_struct *work)
> * nothing else.
> */
> read_unlock(&bond->lock);
> - rtnl_lock();
> + if (!rtnl_trylock()) {
> + read_lock(&bond->lock);
> + goto re_arm;
> + }
>
> bond_info->rlb_promisc_timeout_counter = 0;
>
> @@ -1440,9 +1447,8 @@ void bond_alb_monitor(struct work_struct *work)
> }
>
> re_arm:
> - if (!bond->kill_timers)
> - queue_delayed_work(bond->wq, &bond->alb_work, alb_delta_in_ticks);
> -out:
> + queue_delayed_work(bond->wq, &bond->alb_work, alb_delta_in_ticks);
> +
> read_unlock(&bond->lock);
> }
>
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 71efff3..e6fefff 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -774,9 +774,6 @@ static void bond_resend_igmp_join_requests(struct bonding *bond)
>
> read_lock(&bond->lock);
>
> - if (bond->kill_timers)
> - goto out;
> -
> /* rejoin all groups on bond device */
> __bond_resend_igmp_join_requests(bond->dev);
>
> @@ -790,9 +787,9 @@ static void bond_resend_igmp_join_requests(struct bonding *bond)
> __bond_resend_igmp_join_requests(vlan_dev);
> }
>
> - if ((--bond->igmp_retrans > 0) && !bond->kill_timers)
> + if (--bond->igmp_retrans > 0)
> queue_delayed_work(bond->wq, &bond->mcast_work, HZ/5);
> -out:
> +
> read_unlock(&bond->lock);
> }
>
> @@ -2518,19 +2515,26 @@ void bond_mii_monitor(struct work_struct *work)
> struct bonding *bond = container_of(work, struct bonding,
> mii_work.work);
> bool should_notify_peers = false;
> + unsigned long delay;
>
> read_lock(&bond->lock);
> - if (bond->kill_timers)
> - goto out;
> +
> + delay = msecs_to_jiffies(bond->params.miimon);
>
> if (bond->slave_cnt == 0)
> goto re_arm;
>
> - should_notify_peers = bond_should_notify_peers(bond);
> -
> if (bond_miimon_inspect(bond)) {
> read_unlock(&bond->lock);
> - rtnl_lock();
> +
> + /* Race avoidance with bond_close flush of workqueue */
> + if (!rtnl_trylock()) {
> + read_lock(&bond->lock);
> + delay = 1;
> + should_notify_peers = false;
> + goto re_arm;
> + }
> +
> read_lock(&bond->lock);
>
> bond_miimon_commit(bond);
> @@ -2540,15 +2544,21 @@ void bond_mii_monitor(struct work_struct *work)
> read_lock(&bond->lock);
> }
>
> + should_notify_peers = bond_should_notify_peers(bond);
> +
> re_arm:
> - if (bond->params.miimon && !bond->kill_timers)
> - queue_delayed_work(bond->wq, &bond->mii_work,
> - msecs_to_jiffies(bond->params.miimon));
> -out:
> + if (bond->params.miimon)
> + queue_delayed_work(bond->wq, &bond->mii_work, delay);
> +
> read_unlock(&bond->lock);
>
> if (should_notify_peers) {
> - rtnl_lock();
> + if (!rtnl_trylock()) {
> + read_lock(&bond->lock);
> + bond->send_peer_notif++;
> + read_unlock(&bond->lock);
> + return;
> + }
> netdev_bonding_change(bond->dev, NETDEV_NOTIFY_PEERS);
> rtnl_unlock();
> }
> @@ -2790,9 +2800,6 @@ void bond_loadbalance_arp_mon(struct work_struct *work)
>
> delta_in_ticks = msecs_to_jiffies(bond->params.arp_interval);
>
> - if (bond->kill_timers)
> - goto out;
> -
> if (bond->slave_cnt == 0)
> goto re_arm;
>
> @@ -2889,9 +2896,9 @@ void bond_loadbalance_arp_mon(struct work_struct *work)
> }
>
> re_arm:
> - if (bond->params.arp_interval && !bond->kill_timers)
> + if (bond->params.arp_interval)
> queue_delayed_work(bond->wq, &bond->arp_work, delta_in_ticks);
> -out:
> +
> read_unlock(&bond->lock);
> }
>
> @@ -3132,9 +3139,6 @@ void bond_activebackup_arp_mon(struct work_struct *work)
>
> read_lock(&bond->lock);
>
> - if (bond->kill_timers)
> - goto out;
> -
> delta_in_ticks = msecs_to_jiffies(bond->params.arp_interval);
>
> if (bond->slave_cnt == 0)
> @@ -3144,7 +3148,15 @@ void bond_activebackup_arp_mon(struct work_struct *work)
>
> if (bond_ab_arp_inspect(bond, delta_in_ticks)) {
> read_unlock(&bond->lock);
> - rtnl_lock();
> +
> + /* Race avoidance with bond_close flush of workqueue */
> + if (!rtnl_trylock()) {
> + read_lock(&bond->lock);
> + delta_in_ticks = 1;
> + should_notify_peers = false;
> + goto re_arm;
> + }
> +
> read_lock(&bond->lock);
>
> bond_ab_arp_commit(bond, delta_in_ticks);
> @@ -3157,13 +3169,18 @@ void bond_activebackup_arp_mon(struct work_struct *work)
> bond_ab_arp_probe(bond);
>
> re_arm:
> - if (bond->params.arp_interval && !bond->kill_timers)
> + if (bond->params.arp_interval)
> queue_delayed_work(bond->wq, &bond->arp_work, delta_in_ticks);
> -out:
> +
> read_unlock(&bond->lock);
>
> if (should_notify_peers) {
> - rtnl_lock();
> + if (!rtnl_trylock()) {
> + read_lock(&bond->lock);
> + bond->send_peer_notif++;
> + read_unlock(&bond->lock);
> + return;
> + }
> netdev_bonding_change(bond->dev, NETDEV_NOTIFY_PEERS);
> rtnl_unlock();
> }
> @@ -3425,8 +3442,6 @@ static int bond_open(struct net_device *bond_dev)
> struct slave *slave;
> int i;
>
> - bond->kill_timers = 0;
> -
> /* reset slave->backup and slave->inactive */
> read_lock(&bond->lock);
> if (bond->slave_cnt > 0) {
> @@ -3495,33 +3510,30 @@ static int bond_close(struct net_device *bond_dev)
>
> bond->send_peer_notif = 0;
>
> - /* signal timers not to re-arm */
> - bond->kill_timers = 1;
> -
> write_unlock_bh(&bond->lock);
>
> if (bond->params.miimon) { /* link check interval, in milliseconds. */
> - cancel_delayed_work(&bond->mii_work);
> + cancel_delayed_work_sync(&bond->mii_work);
> }
>
> if (bond->params.arp_interval) { /* arp interval, in milliseconds. */
> - cancel_delayed_work(&bond->arp_work);
> + cancel_delayed_work_sync(&bond->arp_work);
> }
>
> switch (bond->params.mode) {
> case BOND_MODE_8023AD:
> - cancel_delayed_work(&bond->ad_work);
> + cancel_delayed_work_sync(&bond->ad_work);
> break;
> case BOND_MODE_TLB:
> case BOND_MODE_ALB:
> - cancel_delayed_work(&bond->alb_work);
> + cancel_delayed_work_sync(&bond->alb_work);
> break;
> default:
> break;
> }
>
> if (delayed_work_pending(&bond->mcast_work))
> - cancel_delayed_work(&bond->mcast_work);
> + cancel_delayed_work_sync(&bond->mcast_work);
>
> if (bond_is_lb(bond)) {
> /* Must be called only after all
> @@ -4368,26 +4380,22 @@ static void bond_setup(struct net_device *bond_dev)
>
> static void bond_work_cancel_all(struct bonding *bond)
> {
> - write_lock_bh(&bond->lock);
> - bond->kill_timers = 1;
> - write_unlock_bh(&bond->lock);
> -
> if (bond->params.miimon && delayed_work_pending(&bond->mii_work))
> - cancel_delayed_work(&bond->mii_work);
> + cancel_delayed_work_sync(&bond->mii_work);
>
> if (bond->params.arp_interval && delayed_work_pending(&bond->arp_work))
> - cancel_delayed_work(&bond->arp_work);
> + cancel_delayed_work_sync(&bond->arp_work);
>
> if (bond->params.mode == BOND_MODE_ALB &&
> delayed_work_pending(&bond->alb_work))
> - cancel_delayed_work(&bond->alb_work);
> + cancel_delayed_work_sync(&bond->alb_work);
>
> if (bond->params.mode == BOND_MODE_8023AD &&
> delayed_work_pending(&bond->ad_work))
> - cancel_delayed_work(&bond->ad_work);
> + cancel_delayed_work_sync(&bond->ad_work);
>
> if (delayed_work_pending(&bond->mcast_work))
> - cancel_delayed_work(&bond->mcast_work);
> + cancel_delayed_work_sync(&bond->mcast_work);
> }
>
> /*
> diff --git a/drivers/net/bonding/bonding.h b/drivers/net/bonding/bonding.h
> index 82fec5f..1aecc37 100644
> --- a/drivers/net/bonding/bonding.h
> +++ b/drivers/net/bonding/bonding.h
> @@ -222,7 +222,6 @@ struct bonding {
> struct slave *);
> rwlock_t lock;
> rwlock_t curr_slave_lock;
> - s8 kill_timers;
> u8 send_peer_notif;
> s8 setup_by_slave;
> s8 igmp_retrans;
>
>
> ---
> -Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
>
^ permalink raw reply
* Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Ben Hutchings @ 2011-10-28 1:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Andi Kleen, Eric Dumazet, linux-kernel, netdev, Andrew Morton
In-Reply-To: <CA+55aFy9oJSK99K=brRzSfSnLocO=PuS7yuKkAcw3t5hATJrfw@mail.gmail.com>
On Thu, 2011-10-27 at 18:34 -0700, Linus Torvalds wrote:
> On Thu, Oct 27, 2011 at 6:25 PM, Andi Kleen <andi@firstfloor.org> wrote:
> >
> > Seems reasonable too. In fact we usually should have memory barriers
> > for this anyways which obsolete the volatile.
>
> No we shouldn't. Memory barriers are insanely expensive, and pointless
> for atomics - that aren't ordered anyway.
>
> You may mean compiler barriers.
>
> That said, removing the volatile entirely might be a good idea, and
> never mind any barriers at all. The ordering for atomics really isn't
> well enough specified that we should care. So I wouldn't object to a
> patch that just removes the volatile entirely, but it would have to be
> accompanied with quite a bit of testing, in case some odd case ends up
> depending on it. But nothing *should* be looping on those things
> anyway.
Whether or not it needs to provide any ordering guarantee, atomic_read()
must never read more than once, and I think that requires the volatile
qualification. It might be clearer to use the ACCESS_ONCE macro,
however.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: Introduce FCLONE_SCRATCH skbs to reduce stack memory useage and napi jitter
From: Neil Horman @ 2011-10-28 1:37 UTC (permalink / raw)
To: Eric Dumazet; +Cc: netdev, David S. Miller
In-Reply-To: <1319756146.19125.42.camel@edumazet-laptop>
On Fri, Oct 28, 2011 at 12:55:46AM +0200, Eric Dumazet wrote:
> Le jeudi 27 octobre 2011 à 15:53 -0400, Neil Horman a écrit :
> > I had this idea awhile ago while I was looking at the receive path for multicast
> > frames. The top of the mcast recieve path (in __udp4_lib_mcast_deliver, has a
> > loop in which we traverse a hash list linearly, looking for sockets that are
> > listening to a given multicast group. For each matching socket we clone the skb
> > to enqueue it to the corresponding socket. This creates two problems:
> >
> > 1) Application driven jitter in the receive path
> > As you add processes that listen to the same multcast group, you increase the
> > number of iterations you have to preform in this loop, which can lead to
> > increases in the amount of time you spend processing each frame in softirq
> > context, expecially if you are memory constrained, and the skb_clone operation
> > has to call all the way back into the buddy allocator for more ram. This can
> > lead to needlessly dropped frames as rx latency increases in the stack.
> >
>
> Hmm... time to perform this loop not depends on memory constraints,
> since GFP_ATOMIC allocations are done. It succeed or not, immediately.
>
Thats not entirely correct. The time it takes to allocate a new object from the
slab can be very much affected by memory contraints. Systems under memory
pressue may need to shrink slab caches, allocate from remote nodes, etc, all of
which contributes to additional allocation time. This time is multiplied by the
number of sockets listening to a particular group. I'm not saying its a huge
change, but its a change that I saw the ability to address. This change (I
hope) tries, when able, to eliminate the jitter from that path.
> Time is consumed on the copy of the skb head, and refcnt
> increases/decreases on datarefcnt. Your patch doesnt avoid this.
>
No it doesn't, you're correct. I was really looking at lower hanging fruit with
this change.
> When application calls recvmsg() we then perform the two atomics on skb
> refcnt and data refcnt and free them, with cache line false sharing...
>
> > 2) Increased memory usage
> > As you increase the number of listeners to a multicast group, you directly
> > increase the number of times you clone and skb, putting increased memory
> > pressure on the system.
> >
>
> One skb_head is about 256 bytes (232 bytes on 64bit arches)
>
Yes, thats right. Depending on the size of the received frame I can allocate
anywhere from 1 to 4 additional skbs using otherwise unused memory at the tail
of the data segment with this patch.
> > while neither of these problems is a huge concern, I thought it would be nice if
> > we could mitigate the effects of increased application instances on performance
> > in this area. As such I came up with this patch set. I created a new skb
> > fclone type called FCLONE_SCRATCH. When available, it commandeers the
> > internally fragmented space of an skb data buffer and uses that to allocate
> > additional skbs during the clone operation. Since the skb->data area is
> > allocated with a kmalloc operation (and is therefore nominally a power of 2 in
> > size), and nominally network interfaces tend to have an mtu of around 1500
> > bytes, we typically can reclaim several hundred bytes of space at the end of an
> > skb (more if the incomming packet is not a full MTU in size). This space, being
> > exclusively accessible to the softirq doing the reclaim, can be quickly accesed
> > without the need for additional locking, potntially providing lower jitter in
> > napi context per frame during a receive operation, as well as some memory
> > savings.
> >
> > I'm still collecting stats on its performance, but I thought I would post now to
> > get some early reviews and feedback on it.
> >
>
> I really doubt you'll find a significative performance increase.
>
With the perf script I included in this set, I'm currently reducing the napi rx
path runtime by about 2 microsecond per iteration when multiple processes are
listening to the same group, and we can allocate skbs from the data area of the
received skb. I'm not sure how accurate (or valuable) that is, but thats what
I'm getting. While I've not measured, theres also the fact that kfree_skb doesn't
have any work to do with FCLONE_SCRATCH skbs, since they all get returned when
the data area gets kfreed. Lastly, theres the savings of 256 bytes per
listening app that uses an FCLONE_SCRATCH skb, since that memory is already
reserved, and effectively free. I can't really put a number on how significant
that is, but I think its valuable.
> I do believe its a too complex : skb code is already a nightmare if you
> ask me.
>
I'm not sure I agree with that. Its certainly complex in the sense that it adds
additional state to be checked in the skb_clone and kfree_skb paths, but beyond
that, it doesn't require any semantic changes to any of the other parts of the
skb api(s). Is there something specific about this change that you find
unacceptibly complex, or something I can do to make it simpler?
> And your hack/idea wont work quite well if you have 8 receivers for each
> frame.
>
It will work fine, to whatever degree its able, and this it will fall back on
the standard skb_clone behavior. The performance gains will be reduced, of
course, which I think is what you are referring to, but the memory advantages
still exit. If you have 8 receivers, but a given skb has only enough free space
at the end of the data segment to allocate 4 additional skbs, we'll allocate
those 4, and do a real kmem_cache_alloc of 4 more in skb_clone. The last 4 have
to use the slab_allocation path as we otherwise would, so we're no worse off
than before, but we still get the memory savings (which would be about 1k per
received frame for this mcast group, which I think is significant).
> What about finding another way to queue one skb to N receive queue(s),
> so that several multicast sockets can share same skb head ?
>
Yes, I'd experimented with some of this, and had mixed results. Specifically I
came up with a way to use the additional space as an array of list heads, with
backpointers to the socket_queue each list_head was owned by and the skb that
owned the entry. It was nice because it let me enqueue the same skb to hundreds
of sockets at the same time, which was really nice. It was bad however, because
it completely broke socket accounting (any likely anything else that required on
any part of the socket state). Any thoughts on ways I might improve on that.
If I could make some sort of reduced sk_buff so that I didn't have to allocate
all 256 bytes of a full sk_buff, that would be great!
> I always found sk_receive queue being very inefficient, since a queue or
> dequeue must dirty a lot of cache lines.
>
> This forces us to use a spinlock to protect queue/enqueue operations,
> but also the socket lock (because of the MSG_PEEK stuff and
> sk_rmem_alloc / sk_forward_alloc)
>
> sk_receive_queue.lock is the real jitter source.
>
> Ideally, we could have a fast path using a small circular array per
> socket, of say 8 or 16 pointers to skbs, or allow application or
> sysadmin to size this array.
>
> A circular buffer can be handled without any lock, using atomic
> operations (cmpxchg()) on load/unload indexes. The array of pointers is
> written only by the softirq handler cpu, read by consumers.
>
> Since this array is small [and finite size], and skb shared, we dont
> call skb_set_owner_r() anymore, avoiding expensive atomic ops on
> sk->sk_rmem_alloc.
>
> UDP receive path could become lockless, allowing the softirq handler to
> run without being slowed down by concurrent recvmsg()
>
> At recvmsg() time, N-1 threads would only perform the skb->refcnt
> decrement, and the last one would free the skb and data as well.
>
This seems like a reasonable idea, and I'm happy to experiment with it, but I
still like the idea of using that often available space at the end of an skb,
just because I think the memory savings is attractive. Shall I roll them into
the same patch series, or do them separately?
Neil
>
>
>
^ permalink raw reply
* Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Linus Torvalds @ 2011-10-28 1:34 UTC (permalink / raw)
To: Andi Kleen; +Cc: Eric Dumazet, linux-kernel, netdev, Andrew Morton
In-Reply-To: <20111028012521.GF25795@one.firstfloor.org>
On Thu, Oct 27, 2011 at 6:25 PM, Andi Kleen <andi@firstfloor.org> wrote:
>
> Seems reasonable too. In fact we usually should have memory barriers
> for this anyways which obsolete the volatile.
No we shouldn't. Memory barriers are insanely expensive, and pointless
for atomics - that aren't ordered anyway.
You may mean compiler barriers.
That said, removing the volatile entirely might be a good idea, and
never mind any barriers at all. The ordering for atomics really isn't
well enough specified that we should care. So I wouldn't object to a
patch that just removes the volatile entirely, but it would have to be
accompanied with quite a bit of testing, in case some odd case ends up
depending on it. But nothing *should* be looping on those things
anyway.
Linus
^ permalink raw reply
* Re: [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Andi Kleen @ 2011-10-28 1:25 UTC (permalink / raw)
To: Eric Dumazet
Cc: Linus Torvalds, linux-kernel, Andi Kleen, netdev, Andrew Morton
In-Reply-To: <1319764761.23112.14.camel@edumazet-laptop>
On Fri, Oct 28, 2011 at 03:19:21AM +0200, Eric Dumazet wrote:
> In commit 4e60c86bd9e (gcc-4.6: mm: fix unused but set warnings)
> Andi forced VM_BUG_ON(cond) to evaluate cond, even if CONFIG_DEBUG_VM is
> not set :
>
> #ifdef CONFIG_DEBUG_VM
> #define VM_BUG_ON(cond) BUG_ON(cond)
> #else
> #define VM_BUG_ON(cond) do { (void)(cond); } while (0)
> #endif
Eventually the warnings were disabled in the Makefile.
So it would be reasonable to just revert that patch now, at least
for VM_BUG_ON, if it costs performance.
>
> So maybe a fix would be to introduce an atomic_read_stable() variant ?
>
> static inline int atomic_read_stable(const atomic_t *v)
> {
> return v->counter;
> }
Seems reasonable too. In fact we usually should have memory barriers
for this anyways which obsolete the volatile.
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* [RFC] should VM_BUG_ON(cond) really evaluate cond
From: Eric Dumazet @ 2011-10-28 1:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, Andi Kleen, netdev, Andrew Morton
In commit 4e60c86bd9e (gcc-4.6: mm: fix unused but set warnings)
Andi forced VM_BUG_ON(cond) to evaluate cond, even if CONFIG_DEBUG_VM is
not set :
#ifdef CONFIG_DEBUG_VM
#define VM_BUG_ON(cond) BUG_ON(cond)
#else
#define VM_BUG_ON(cond) do { (void)(cond); } while (0)
#endif
As a side effect, get_page()/put_page_testzero() are performing more bus
transactions on contended cache line on some workloads (tcp on loopback
for example, where a page is acting as a shared buffer)
0,05 : ffffffff815e4775: je ffffffff815e4970 <tcp_sendmsg+0xc80>
0,05 : ffffffff815e477b: mov 0x1c(%r9),%eax // useless
3,32 : ffffffff815e477f: mov (%r9),%rax // useless
0,51 : ffffffff815e4782: lock incl 0x1c(%r9)
3,87 : ffffffff815e4787: mov (%r9),%rax
0,00 : ffffffff815e478a: test $0x80,%ah
0,00 : ffffffff815e478d: jne ffffffff815e49f2 <tcp_sendmsg+0xd02>
Of course, we have to understand why
(void) (atomic_read(&some_atomic) == 1);
generates asm code...
mov some_atomic,%eax
Ah yes, this is because of the volatile...
static inline int atomic_read(const atomic_t *v)
{
return (*(volatile int *)&(v)->counter);
}
So maybe a fix would be to introduce an atomic_read_stable() variant ?
static inline int atomic_read_stable(const atomic_t *v)
{
return v->counter;
}
Thanks !
^ permalink raw reply
* Re: [PATCH] xfrm: fix error checking in xfrm_output_gso
From: Yan, Zheng @ 2011-10-28 0:47 UTC (permalink / raw)
To: netdev@vger.kernel.org; +Cc: Herbert Xu, davem@davemloft.net
In-Reply-To: <4EA8ED1E.6080808@intel.com>
On 10/27/2011 01:33 PM, Yan, Zheng wrote:
> xfrm_output2() returns 1 on success. This bug makes xfrm_output_gso()
> drop all segments except the first one.
>
> Signed-off-by: Zheng Yan <zheng.z.yan@intel.com>
> ---
> diff --git a/net/xfrm/xfrm_output.c b/net/xfrm/xfrm_output.c
> index 47bacd8..04e963a 100644
> --- a/net/xfrm/xfrm_output.c
> +++ b/net/xfrm/xfrm_output.c
> @@ -159,7 +159,7 @@ static int xfrm_output_gso(struct sk_buff *skb)
> segs->next = NULL;
> err = xfrm_output2(segs);
>
> - if (unlikely(err)) {
> + if (unlikely(err < 0)) {
> while ((segs = nskb)) {
> nskb = segs->next;
> segs->next = NULL;
Return 1 means collision, please ignore this patch. Thanks
^ permalink raw reply
* Re: [RFC] tcp: Export TCP Delayed ACK parameters to user
From: Eric Dumazet @ 2011-10-28 0:01 UTC (permalink / raw)
To: Daniel Baluta; +Cc: davem, kuznet, jmorris, yoshfuji, kaber, netdev
In-Reply-To: <1319756841-2051-1-git-send-email-dbaluta@ixiacom.com>
Le vendredi 28 octobre 2011 à 02:07 +0300, Daniel Baluta a écrit :
> RFC2581 ($4.2) specifies when an ACK should be generated as follows:
>
> " .. an ACK SHOULD be generated for at least every second
> full-sized segment, and MUST be generated within 500 ms
> of the arrival of the first unacknowledged packet.
> "
>
> We export the number of segments and the timeout limits
> specified above, so that a user can tune them according
> to its needs.
>
Well, this requires user has a machine exclusive use :)
> Specifically:
> * /proc/sys/net/ipv4/tcp_delack_segs, represents
> the threshold for the number of segments.
> * /proc/sys/net/ipv4/tcp_delack_min, specifies
> the minimum timeout value
> * /proc/sys/net/ipv4/tcp_delack_max, specifies
> the maximum timeout value.
>
> Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
> ---
> include/net/tcp.h | 20 +++++++++++++++++---
> net/ipv4/sysctl_net_ipv4.c | 21 +++++++++++++++++++++
> net/ipv4/tcp.c | 5 +++--
> net/ipv4/tcp_input.c | 7 +++++--
> net/ipv4/tcp_output.c | 4 +++-
> 5 files changed, 49 insertions(+), 8 deletions(-)
>
Missing Documentation changes
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index e147f42..f3b0c17 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -111,14 +111,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
> * TIME-WAIT timer.
> */
>
> -#define TCP_DELACK_MAX ((unsigned)(HZ/5)) /* maximal time to delay before sending an ACK */
> +/* default maximum time to delay before sending an ACK */
> +#define TCP_DELACK_MAX_DEFAULT ((unsigned)(HZ/5))
> +
> #if HZ >= 100
> -#define TCP_DELACK_MIN ((unsigned)(HZ/25)) /* minimal time to delay before sending an ACK */
> +/* default minimum time to delay before sending an ACK */
> +#define TCP_DELACK_MIN_DEFAULT ((unsigned)(HZ/25))
> #define TCP_ATO_MIN ((unsigned)(HZ/25))
> #else
> -#define TCP_DELACK_MIN 4U
> +#define TCP_DELACK_MIN_DEFAULT 4U
> #define TCP_ATO_MIN 4U
> #endif
> +
> +#define TCP_DELACK_MIN sysctl_tcp_delack_min
> +#define TCP_DELACK_MAX sysctl_tcp_delack_max
Hmm, please try to compile dccp as a module :)
You need some EXPORT_SYMBOL() definitions.
Frankly, I suggest removing TCP_DELACK_{MIN|MAX} to avoid unecessary
layer, and use sysctl_tcp_delack_{min|max} instead
> +
> #define TCP_RTO_MAX ((unsigned)(120*HZ))
> #define TCP_RTO_MIN ((unsigned)(HZ/5))
> #define TCP_TIMEOUT_INIT ((unsigned)(1*HZ)) /* RFC2988bis initial RTO value */
> @@ -251,6 +258,9 @@ extern int sysctl_tcp_max_ssthresh;
> extern int sysctl_tcp_cookie_size;
> extern int sysctl_tcp_thin_linear_timeouts;
> extern int sysctl_tcp_thin_dupack;
> +extern int sysctl_tcp_delack_segs;
> +extern int sysctl_tcp_delack_min;
> +extern int sysctl_tcp_delack_max;
>
> extern atomic_long_t tcp_memory_allocated;
> extern struct percpu_counter tcp_sockets_allocated;
> @@ -1557,6 +1567,10 @@ static inline struct tcp_extend_values *tcp_xv(struct request_values *rvp)
> {
> return (struct tcp_extend_values *)rvp;
> }
> +static inline int tcp_snd_thresh(struct sock *sk)
I am not sure name is properly chosen, its about delack or not ?
const struct *sk
> +{
> + return inet_csk(sk)->icsk_ack.rcv_mss * sysctl_tcp_delack_segs;
> +}
>
Thanks !
^ permalink raw reply
* Re: [PATCH net-next] bnx2x: Disable LRO on FCoE or iSCSI boot device
From: Michael Chan @ 2011-10-27 23:30 UTC (permalink / raw)
To: John Fastabend
Cc: David Miller, netdev@vger.kernel.org, Dmitry Kravkov,
Eilon Greenstein
In-Reply-To: <4E9F38D6.6030700@intel.com>
On Wed, 2011-10-19 at 13:53 -0700, John Fastabend wrote:
> As a reference point this works fine in both FCoE and iSCSI stacks
> today. The device is reset or link is lost for whatever reason
> when the link comes back up the stack logs back in, enumerates
> the luns and the scsi stack recovers as expected.
>
> Firmware should do the equivalent login, lun enumeration, etc as
> needed.
Just a quick follow-up on this issue. Our firmware actually performs
the same logout before the reset and login after the reset. For iSCSI,
the problem on our device was actually caused by our userspace daemon
logging events to a log file in the root fs. The file I/O was blocked
and the daemon could not proceed to do the important operations during
the reset, and this caused filesystem I/O errors. We have now fixed the
problem in the userspace daemon.
For FCoE, there is no logging issue and the root fs failure seems to
happen only in a multipath configuration with all paths going down for a
short time (caused by reset in this case). We believe this also affects
other devices and not just ours. We are now working with the multipath
maintainer to understand this issue.
So this confirms that the original patch for bnx2x is not needed.
Thanks.
^ permalink raw reply
* [RFC] tcp: Export TCP Delayed ACK parameters to user
From: Daniel Baluta @ 2011-10-27 23:07 UTC (permalink / raw)
To: davem; +Cc: kuznet, jmorris, yoshfuji, kaber, netdev, eric.dumazet,
Daniel Baluta
RFC2581 ($4.2) specifies when an ACK should be generated as follows:
" .. an ACK SHOULD be generated for at least every second
full-sized segment, and MUST be generated within 500 ms
of the arrival of the first unacknowledged packet.
"
We export the number of segments and the timeout limits
specified above, so that a user can tune them according
to its needs.
Specifically:
* /proc/sys/net/ipv4/tcp_delack_segs, represents
the threshold for the number of segments.
* /proc/sys/net/ipv4/tcp_delack_min, specifies
the minimum timeout value
* /proc/sys/net/ipv4/tcp_delack_max, specifies
the maximum timeout value.
Signed-off-by: Daniel Baluta <dbaluta@ixiacom.com>
---
include/net/tcp.h | 20 +++++++++++++++++---
net/ipv4/sysctl_net_ipv4.c | 21 +++++++++++++++++++++
net/ipv4/tcp.c | 5 +++--
net/ipv4/tcp_input.c | 7 +++++--
net/ipv4/tcp_output.c | 4 +++-
5 files changed, 49 insertions(+), 8 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index e147f42..f3b0c17 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -111,14 +111,21 @@ extern void tcp_time_wait(struct sock *sk, int state, int timeo);
* TIME-WAIT timer.
*/
-#define TCP_DELACK_MAX ((unsigned)(HZ/5)) /* maximal time to delay before sending an ACK */
+/* default maximum time to delay before sending an ACK */
+#define TCP_DELACK_MAX_DEFAULT ((unsigned)(HZ/5))
+
#if HZ >= 100
-#define TCP_DELACK_MIN ((unsigned)(HZ/25)) /* minimal time to delay before sending an ACK */
+/* default minimum time to delay before sending an ACK */
+#define TCP_DELACK_MIN_DEFAULT ((unsigned)(HZ/25))
#define TCP_ATO_MIN ((unsigned)(HZ/25))
#else
-#define TCP_DELACK_MIN 4U
+#define TCP_DELACK_MIN_DEFAULT 4U
#define TCP_ATO_MIN 4U
#endif
+
+#define TCP_DELACK_MIN sysctl_tcp_delack_min
+#define TCP_DELACK_MAX sysctl_tcp_delack_max
+
#define TCP_RTO_MAX ((unsigned)(120*HZ))
#define TCP_RTO_MIN ((unsigned)(HZ/5))
#define TCP_TIMEOUT_INIT ((unsigned)(1*HZ)) /* RFC2988bis initial RTO value */
@@ -251,6 +258,9 @@ extern int sysctl_tcp_max_ssthresh;
extern int sysctl_tcp_cookie_size;
extern int sysctl_tcp_thin_linear_timeouts;
extern int sysctl_tcp_thin_dupack;
+extern int sysctl_tcp_delack_segs;
+extern int sysctl_tcp_delack_min;
+extern int sysctl_tcp_delack_max;
extern atomic_long_t tcp_memory_allocated;
extern struct percpu_counter tcp_sockets_allocated;
@@ -1557,6 +1567,10 @@ static inline struct tcp_extend_values *tcp_xv(struct request_values *rvp)
{
return (struct tcp_extend_values *)rvp;
}
+static inline int tcp_snd_thresh(struct sock *sk)
+{
+ return inet_csk(sk)->icsk_ack.rcv_mss * sysctl_tcp_delack_segs;
+}
extern void tcp_v4_init(void);
extern void tcp_init(void);
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 69fd720..c22c4c5 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -639,6 +639,27 @@ static struct ctl_table ipv4_table[] = {
.proc_handler = proc_dointvec
},
{
+ .procname = "tcp_delack_segs",
+ .data = &sysctl_tcp_delack_segs,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec
+ },
+ {
+ .procname = "tcp_delack_min",
+ .data = &sysctl_tcp_delack_min,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_ms_jiffies
+ },
+ {
+ .procname = "tcp_delack_max",
+ .data = &sysctl_tcp_delack_max,
+ .maxlen = sizeof(int),
+ .mode = 0644,
+ .proc_handler = proc_dointvec_ms_jiffies
+ },
+ {
.procname = "udp_mem",
.data = &sysctl_udp_mem,
.maxlen = sizeof(sysctl_udp_mem),
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 34f5db1..0aad29b 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1204,8 +1204,9 @@ void tcp_cleanup_rbuf(struct sock *sk, int copied)
/* Delayed ACKs frequently hit locked sockets during bulk
* receive. */
if (icsk->icsk_ack.blocked ||
- /* Once-per-two-segments ACK was not sent by tcp_input.c */
- tp->rcv_nxt - tp->rcv_wup > icsk->icsk_ack.rcv_mss ||
+ /* More than once-per-tcp_delack_segs-segments ACK
+ * was not sent by tcp_input.c */
+ tp->rcv_nxt - tp->rcv_wup > tcp_snd_thresh(sk) ||
/*
* If this read emptied read buffer, we send ACK, if
* connection is not bidirectional, user drained
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 52b5c2d..1e02a80 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -98,6 +98,9 @@ int sysctl_tcp_thin_dupack __read_mostly;
int sysctl_tcp_moderate_rcvbuf __read_mostly = 1;
int sysctl_tcp_abc __read_mostly;
+int sysctl_tcp_delack_segs __read_mostly = 1;
+
+
#define FLAG_DATA 0x01 /* Incoming frame contained data. */
#define FLAG_WIN_UPDATE 0x02 /* Incoming ACK was a window update. */
#define FLAG_DATA_ACKED 0x04 /* This ACK acknowledged new data. */
@@ -4993,8 +4996,8 @@ static void __tcp_ack_snd_check(struct sock *sk, int ofo_possible)
{
struct tcp_sock *tp = tcp_sk(sk);
- /* More than one full frame received... */
- if (((tp->rcv_nxt - tp->rcv_wup) > inet_csk(sk)->icsk_ack.rcv_mss &&
+ /* More than tcp_delack_segs full frame(s) received... */
+ if (((tp->rcv_nxt - tp->rcv_wup) > tcp_snd_thresh(sk) &&
/* ... and right edge of window advances far enough.
* (tcp_recvmsg() will send ACK otherwise). Or...
*/
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 980b98f..0ec31af 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -63,6 +63,8 @@ int sysctl_tcp_slow_start_after_idle __read_mostly = 1;
int sysctl_tcp_cookie_size __read_mostly = 0; /* TCP_COOKIE_MAX */
EXPORT_SYMBOL_GPL(sysctl_tcp_cookie_size);
+int sysctl_tcp_delack_min __read_mostly = TCP_DELACK_MIN_DEFAULT;
+int sysctl_tcp_delack_max __read_mostly = TCP_DELACK_MAX_DEFAULT;
/* Account for new data that has been sent to the network. */
static void tcp_event_new_data_sent(struct sock *sk, const struct sk_buff *skb)
@@ -2685,7 +2687,7 @@ void tcp_send_delayed_ack(struct sock *sk)
* directly.
*/
if (tp->srtt) {
- int rtt = max(tp->srtt >> 3, TCP_DELACK_MIN);
+ int rtt = max_t(unsigned, tp->srtt >> 3, TCP_DELACK_MIN);
if (rtt < max_ato)
max_ato = rtt;
--
1.7.2.5
^ permalink raw reply related
* Re: Introduce FCLONE_SCRATCH skbs to reduce stack memory useage and napi jitter
From: Eric Dumazet @ 2011-10-27 22:55 UTC (permalink / raw)
To: Neil Horman; +Cc: netdev, David S. Miller
In-Reply-To: <1319745221-30880-1-git-send-email-nhorman@tuxdriver.com>
Le jeudi 27 octobre 2011 à 15:53 -0400, Neil Horman a écrit :
> I had this idea awhile ago while I was looking at the receive path for multicast
> frames. The top of the mcast recieve path (in __udp4_lib_mcast_deliver, has a
> loop in which we traverse a hash list linearly, looking for sockets that are
> listening to a given multicast group. For each matching socket we clone the skb
> to enqueue it to the corresponding socket. This creates two problems:
>
> 1) Application driven jitter in the receive path
> As you add processes that listen to the same multcast group, you increase the
> number of iterations you have to preform in this loop, which can lead to
> increases in the amount of time you spend processing each frame in softirq
> context, expecially if you are memory constrained, and the skb_clone operation
> has to call all the way back into the buddy allocator for more ram. This can
> lead to needlessly dropped frames as rx latency increases in the stack.
>
Hmm... time to perform this loop not depends on memory constraints,
since GFP_ATOMIC allocations are done. It succeed or not, immediately.
Time is consumed on the copy of the skb head, and refcnt
increases/decreases on datarefcnt. Your patch doesnt avoid this.
When application calls recvmsg() we then perform the two atomics on skb
refcnt and data refcnt and free them, with cache line false sharing...
> 2) Increased memory usage
> As you increase the number of listeners to a multicast group, you directly
> increase the number of times you clone and skb, putting increased memory
> pressure on the system.
>
One skb_head is about 256 bytes (232 bytes on 64bit arches)
> while neither of these problems is a huge concern, I thought it would be nice if
> we could mitigate the effects of increased application instances on performance
> in this area. As such I came up with this patch set. I created a new skb
> fclone type called FCLONE_SCRATCH. When available, it commandeers the
> internally fragmented space of an skb data buffer and uses that to allocate
> additional skbs during the clone operation. Since the skb->data area is
> allocated with a kmalloc operation (and is therefore nominally a power of 2 in
> size), and nominally network interfaces tend to have an mtu of around 1500
> bytes, we typically can reclaim several hundred bytes of space at the end of an
> skb (more if the incomming packet is not a full MTU in size). This space, being
> exclusively accessible to the softirq doing the reclaim, can be quickly accesed
> without the need for additional locking, potntially providing lower jitter in
> napi context per frame during a receive operation, as well as some memory
> savings.
>
> I'm still collecting stats on its performance, but I thought I would post now to
> get some early reviews and feedback on it.
>
I really doubt you'll find a significative performance increase.
I do believe its a too complex : skb code is already a nightmare if you
ask me.
And your hack/idea wont work quite well if you have 8 receivers for each
frame.
What about finding another way to queue one skb to N receive queue(s),
so that several multicast sockets can share same skb head ?
I always found sk_receive queue being very inefficient, since a queue or
dequeue must dirty a lot of cache lines.
This forces us to use a spinlock to protect queue/enqueue operations,
but also the socket lock (because of the MSG_PEEK stuff and
sk_rmem_alloc / sk_forward_alloc)
sk_receive_queue.lock is the real jitter source.
Ideally, we could have a fast path using a small circular array per
socket, of say 8 or 16 pointers to skbs, or allow application or
sysadmin to size this array.
A circular buffer can be handled without any lock, using atomic
operations (cmpxchg()) on load/unload indexes. The array of pointers is
written only by the softirq handler cpu, read by consumers.
Since this array is small [and finite size], and skb shared, we dont
call skb_set_owner_r() anymore, avoiding expensive atomic ops on
sk->sk_rmem_alloc.
UDP receive path could become lockless, allowing the softirq handler to
run without being slowed down by concurrent recvmsg()
At recvmsg() time, N-1 threads would only perform the skb->refcnt
decrement, and the last one would free the skb and data as well.
^ permalink raw reply
* Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
From: Mike Frysinger @ 2011-10-27 22:43 UTC (permalink / raw)
To: Mark Brown
Cc: Linus Walleij, netdev, Steve Glendinning, Mathieu Poirer,
Robert Marklund, Paul Mundt, linux-sh, Sascha Hauer,
Tony Lindgren, linux-omap, uclinux-dist-devel, Linus Walleij
In-Reply-To: <20111027214241.GA11534@opensource.wolfsonmicro.com>
On Thu, Oct 27, 2011 at 23:42, Mark Brown wrote:
> On Thu, Oct 27, 2011 at 10:59:14PM +0200, Mike Frysinger wrote:
>> i saw that !CONFIG_REGULATOR works great. my concern is that these
>> boards don't define any regulators for smsc resources, so if
>> CONFIG_REGULATOR is enabled to test out unrelated daughter cards, i
>> don't want the network driver suddenly failing. Linus' comments
>> suggest that this is what would happen unless each board file has its
>> smsc platform resources extended. maybe i misunderstood what he was saying ?
>
> That's the case that's handled by CONFIG_REGULATOR_DUMMY - if the lookup
> fails the core will provide a virtual regulator to the consumer. If
> you're running a setup like that you probably want to enable dummy
> regulators anyway.
ok, if people configuring need only select that Kconfig symbol to make
it work, i'm fine with things. thanks for the explanation.
-mike
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove quotes of maintaners's names
From: Jeff Kirsher @ 2011-10-27 22:26 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: akpm@linux-foundation.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <alpine.LNX.2.00.1110271845200.8311@darkstar.example.net>
[-- Attachment #1: Type: text/plain, Size: 24218 bytes --]
On Thu, 2011-10-27 at 11:48 -0700, Marcos Paulo de Souza wrote:
>
> On Thu, 27 Oct 2011, Kirsher, Jeffrey T wrote:
>
> > On Oct 27, 2011, at 14:14, "Marcos Paulo de Souza" <marcos.mage@gmail.com> wrote:
> >
> >> Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
> >> ---
> >> MAINTAINERS | 128 +++++++++++++++++++++++++++++-----------------------------
> >> 1 files changed, 64 insertions(+), 64 deletions(-)
> >>
> >> diff --git a/MAINTAINERS b/MAINTAINERS
> >> index 27af9c9..0bea8d7 100644
> >> --- a/MAINTAINERS
> >> +++ b/MAINTAINERS
> >> @@ -140,7 +140,7 @@ S: Supported
> >> F: drivers/scsi/3w-*
> >>
> >> 53C700 AND 53C700-66 SCSI DRIVER
> >> -M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> >> +M: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
> >> L: linux-scsi@vger.kernel.org
> >> S: Maintained
> >> F: drivers/scsi/53c700*
> >> @@ -422,7 +422,7 @@ F: drivers/char/agp/
> >> F: include/linux/agp*
> >>
> >> AHA152X SCSI DRIVER
> >> -M: "Juergen E. Fischer" <fischer@norbit.de>
> >> +M: Juergen E. Fischer <fischer@norbit.de>
> >> L: linux-scsi@vger.kernel.org
> >> S: Maintained
> >> F: drivers/scsi/aha152x*
> >> @@ -1096,7 +1096,7 @@ F: arch/arm/mach-shmobile/
> >> F: drivers/sh/
> >>
> >> ARM/TELECHIPS ARM ARCHITECTURE
> >> -M: "Hans J. Koch" <hjk@hansjkoch.de>
> >> +M: Hans J. Koch <hjk@hansjkoch.de>
> >> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> >> S: Maintained
> >> F: arch/arm/plat-tcc/
> >> @@ -1108,7 +1108,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> >> S: Maintained
> >>
> >> ARM/TETON BGA MACHINE SUPPORT
> >> -M: "Mark F. Brown" <mark.brown314@gmail.com>
> >> +M: Mark F. Brown <mark.brown314@gmail.com>
> >> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> >> S: Maintained
> >>
> >> @@ -1200,7 +1200,7 @@ F: drivers/platform/x86/asus*.c
> >> F: drivers/platform/x86/eeepc*.c
> >>
> >> ASUS ASB100 HARDWARE MONITOR DRIVER
> >> -M: "Mark M. Hoffman" <mhoffman@lightlink.com>
> >> +M: Mark M. Hoffman <mhoffman@lightlink.com>
> >> L: lm-sensors@lm-sensors.org
> >> S: Maintained
> >> F: drivers/hwmon/asb100.c
> >> @@ -1223,14 +1223,14 @@ F: drivers/misc/eeprom/at24.c
> >> F: include/linux/i2c/at24.h
> >>
> >> ATA OVER ETHERNET (AOE) DRIVER
> >> -M: "Ed L. Cashin" <ecashin@coraid.com>
> >> +M: Ed L. Cashin <ecashin@coraid.com>
> >> W: http://www.coraid.com/support/linux
> >> S: Supported
> >> F: Documentation/aoe/
> >> F: drivers/block/aoe/
> >>
> >> ATHEROS ATH GENERIC UTILITIES
> >> -M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
> >> +M: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
> >> L: linux-wireless@vger.kernel.org
> >> S: Supported
> >> F: drivers/net/wireless/ath/*
> >> @@ -1238,7 +1238,7 @@ F: drivers/net/wireless/ath/*
> >> ATHEROS ATH5K WIRELESS DRIVER
> >> M: Jiri Slaby <jirislaby@gmail.com>
> >> M: Nick Kossifidis <mickflemm@gmail.com>
> >> -M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
> >> +M: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
> >> M: Bob Copeland <me@bobcopeland.com>
> >> L: linux-wireless@vger.kernel.org
> >> L: ath5k-devel@lists.ath5k.org
> >> @@ -1255,7 +1255,7 @@ S: Supported
> >> F: drivers/net/wireless/ath/ath6kl/
> >>
> >> ATHEROS ATH9K WIRELESS DRIVER
> >> -M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
> >> +M: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
> >> M: Jouni Malinen <jouni@qca.qualcomm.com>
> >> M: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
> >> M: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
> >> @@ -1436,7 +1436,7 @@ F: Documentation/filesystems/befs.txt
> >> F: fs/befs/
> >>
> >> BFS FILE SYSTEM
> >> -M: "Tigran A. Aivazian" <tigran@aivazian.fsnet.co.uk>
> >> +M: Tigran A. Aivazian <tigran@aivazian.fsnet.co.uk>
> >> S: Maintained
> >> F: Documentation/filesystems/bfs.txt
> >> F: fs/bfs/
> >> @@ -1504,7 +1504,7 @@ F: drivers/mtd/devices/block2mtd.c
> >>
> >> BLUETOOTH DRIVERS
> >> M: Marcel Holtmann <marcel@holtmann.org>
> >> -M: "Gustavo F. Padovan" <padovan@profusion.mobi>
> >> +M: Gustavo F. Padovan <padovan@profusion.mobi>
> >> L: linux-bluetooth@vger.kernel.org
> >> W: http://www.bluez.org/
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
> >> @@ -1513,7 +1513,7 @@ F: drivers/bluetooth/
> >>
> >> BLUETOOTH SUBSYSTEM
> >> M: Marcel Holtmann <marcel@holtmann.org>
> >> -M: "Gustavo F. Padovan" <padovan@profusion.mobi>
> >> +M: Gustavo F. Padovan <padovan@profusion.mobi>
> >> L: linux-bluetooth@vger.kernel.org
> >> W: http://www.bluez.org/
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
> >> @@ -1659,7 +1659,7 @@ F: net/caif/
> >>
> >> CALGARY x86-64 IOMMU
> >> M: Muli Ben-Yehuda <muli@il.ibm.com>
> >> -M: "Jon D. Mason" <jdmason@kudzu.us>
> >> +M: Jon D. Mason <jdmason@kudzu.us>
> >> L: discuss@x86-64.org
> >> S: Maintained
> >> F: arch/x86/kernel/pci-calgary_64.c
> >> @@ -1925,7 +1925,7 @@ F: drivers/cpufreq/
> >> F: include/linux/cpufreq.h
> >>
> >> CPUID/MSR DRIVER
> >> -M: "H. Peter Anvin" <hpa@zytor.com>
> >> +M: H. Peter Anvin <hpa@zytor.com>
> >> S: Maintained
> >> F: arch/x86/kernel/cpuid.c
> >> F: arch/x86/kernel/msr.c
> >> @@ -1962,7 +1962,7 @@ F: drivers/tty/serial/crisv10.*
> >>
> >> CRYPTO API
> >> M: Herbert Xu <herbert@gondor.apana.org.au>
> >> -M: "David S. Miller" <davem@davemloft.net>
> >> +M: David S. Miller <davem@davemloft.net>
> >> L: linux-crypto@vger.kernel.org
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
> >> S: Maintained
> >> @@ -2116,7 +2116,7 @@ F: Documentation/networking/decnet.txt
> >> F: net/decnet/
> >>
> >> DEFXX FDDI NETWORK DRIVER
> >> -M: "Maciej W. Rozycki" <macro@linux-mips.org>
> >> +M: Maciej W. Rozycki <macro@linux-mips.org>
> >> S: Maintained
> >> F: drivers/net/fddi/defxx.*
> >>
> >> @@ -2169,7 +2169,7 @@ F: include/linux/device-mapper.h
> >> F: include/linux/dm-*.h
> >>
> >> DIGI INTL. EPCA DRIVER
> >> -M: "Digi International, Inc" <Eng.Linux@digi.com>
> >> +M: Digi International, Inc <Eng.Linux@digi.com>
> >> L: Eng.Linux@digi.com
> >> W: http://www.digi.com
> >> S: Orphan
> >> @@ -2248,7 +2248,7 @@ S: Maintained
> >> F: Documentation/
> >>
> >> DOUBLETALK DRIVER
> >> -M: "James R. Van Zandt" <jrv@vanzandt.mv.com>
> >> +M: James R. Van Zandt <jrv@vanzandt.mv.com>
> >> L: blinux-list@redhat.com
> >> S: Maintained
> >> F: drivers/char/dtlk.c
> >> @@ -2317,7 +2317,7 @@ F: lib/dynamic_debug.c
> >> F: include/linux/dynamic_debug.h
> >>
> >> DZ DECSTATION DZ11 SERIAL DRIVER
> >> -M: "Maciej W. Rozycki" <macro@linux-mips.org>
> >> +M: Maciej W. Rozycki <macro@linux-mips.org>
> >> S: Maintained
> >> F: drivers/tty/serial/dz.*
> >>
> >> @@ -2436,7 +2436,7 @@ F: include/linux/edac_mce.h
> >>
> >> EDAC-I82975X
> >> M: Ranganathan Desikan <ravi@jetztechnologies.com>
> >> -M: "Arvind R." <arvino55@gmail.com>
> >> +M: Arvind R. <arvino55@gmail.com>
> >> L: bluesmoke-devel@lists.sourceforge.net (moderated for non-subscribers)
> >> W: bluesmoke.sourceforge.net
> >> S: Maintained
> >> @@ -2565,7 +2565,7 @@ F: fs/ext3/
> >> F: include/linux/ext3*
> >>
> >> EXT4 FILE SYSTEM
> >> -M: "Theodore Ts'o" <tytso@mit.edu>
> >> +M: Theodore Ts'o <tytso@mit.edu>
> >> M: Andreas Dilger <adilger.kernel@dilger.ca>
> >> L: linux-ext4@vger.kernel.org
> >> W: http://ext4.wiki.kernel.org
> >> @@ -2759,7 +2759,7 @@ F: fs/freevxfs/
> >>
> >> FREEZER
> >> M: Pavel Machek <pavel@ucw.cz>
> >> -M: "Rafael J. Wysocki" <rjw@sisk.pl>
> >> +M: Rafael J. Wysocki <rjw@sisk.pl>
> >> L: linux-pm@vger.kernel.org
> >> S: Supported
> >> F: Documentation/power/freezing-of-tasks.txt
> >> @@ -2840,7 +2840,7 @@ S: Maintained
> >> F: include/asm-generic
> >>
> >> GENERIC UIO DRIVER FOR PCI DEVICES
> >> -M: "Michael S. Tsirkin" <mst@redhat.com>
> >> +M: Michael S. Tsirkin <mst@redhat.com>
> >> L: kvm@vger.kernel.org
> >> S: Supported
> >> F: drivers/uio/uio_pci_generic.c
> >> @@ -2991,7 +2991,7 @@ F: Documentation/blockdev/cpqarray.txt
> >> F: drivers/block/cpqarray.*
> >>
> >> HEWLETT-PACKARD SMART ARRAY RAID DRIVER (hpsa)
> >> -M: "Stephen M. Cameron" <scameron@beardog.cce.hp.com>
> >> +M: Stephen M. Cameron <scameron@beardog.cce.hp.com>
> >> L: iss_storagedev@hp.com
> >> S: Supported
> >> F: Documentation/scsi/hpsa.txt
> >> @@ -3021,7 +3021,7 @@ F: drivers/video/hgafb.c
> >>
> >> HIBERNATION (aka Software Suspend, aka swsusp)
> >> M: Pavel Machek <pavel@ucw.cz>
> >> -M: "Rafael J. Wysocki" <rjw@sisk.pl>
> >> +M: Rafael J. Wysocki <rjw@sisk.pl>
> >> L: linux-pm@vger.kernel.org
> >> S: Supported
> >> F: arch/x86/power/
> >> @@ -3101,7 +3101,7 @@ F: drivers/char/hpet.c
> >> F: include/linux/hpet.h
> >>
> >> HPET: x86
> >> -M: "Venkatesh Pallipadi (Venki)" <venki@google.com>
> >> +M: Venkatesh Pallipadi (Venki) <venki@google.com>
> >> S: Maintained
> >> F: arch/x86/kernel/hpet.c
> >> F: arch/x86/include/asm/hpet.h
> >> @@ -3130,14 +3130,14 @@ S: Maintained
> >> F: fs/hugetlbfs/
> >>
> >> I2C/SMBUS STUB DRIVER
> >> -M: "Mark M. Hoffman" <mhoffman@lightlink.com>
> >> +M: Mark M. Hoffman <mhoffman@lightlink.com>
> >> L: linux-i2c@vger.kernel.org
> >> S: Maintained
> >> F: drivers/i2c/busses/i2c-stub.c
> >>
> >> I2C SUBSYSTEM
> >> -M: "Jean Delvare (PC drivers, core)" <khali@linux-fr.org>
> >> -M: "Ben Dooks (embedded platforms)" <ben-linux@fluff.org>
> >> +M: Jean Delvare (PC drivers, core) <khali@linux-fr.org>
> >> +M: Ben Dooks (embedded platforms) <ben-linux@fluff.org>
> >> L: linux-i2c@vger.kernel.org
> >> W: http://i2c.wiki.kernel.org/
> >> T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
> >> @@ -3156,12 +3156,12 @@ S: Maintained
> >> F: drivers/i2c/busses/i2c-tiny-usb.c
> >>
> >> i386 BOOT CODE
> >> -M: "H. Peter Anvin" <hpa@zytor.com>
> >> +M: H. Peter Anvin <hpa@zytor.com>
> >> S: Maintained
> >> F: arch/x86/boot/
> >>
> >> i386 SETUP CODE / CPU ERRATA WORKAROUNDS
> >> -M: "H. Peter Anvin" <hpa@zytor.com>
> >> +M: H. Peter Anvin <hpa@zytor.com>
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
> >> S: Maintained
> >>
> >> @@ -3199,7 +3199,7 @@ S: Supported
> >> F: drivers/scsi/ips.*
> >>
> >> IDE SUBSYSTEM
> >> -M: "David S. Miller" <davem@davemloft.net>
> >> +M: David S. Miller <davem@davemloft.net>
> >> L: linux-ide@vger.kernel.org
> >> Q: http://patchwork.ozlabs.org/project/linux-ide/list/
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6.git
> >> @@ -3647,7 +3647,7 @@ F: include/linux/ext3_jbd.h
> >> F: include/linux/jbd.h
> >>
> >> JOURNALLING LAYER FOR BLOCK DEVICES (JBD2)
> >> -M: "Theodore Ts'o" <tytso@mit.edu>
> >> +M: Theodore Ts'o <tytso@mit.edu>
> >> L: linux-ext4@vger.kernel.org
> >> S: Maintained
> >> F: fs/jbd2/
> >> @@ -3713,7 +3713,7 @@ W: http://kernelnewbies.org/KernelJanitors
> >> S: Odd Fixes
> >>
> >> KERNEL NFSD, SUNRPC, AND LOCKD SERVERS
> >> -M: "J. Bruce Fields" <bfields@fieldses.org>
> >> +M: J. Bruce Fields <bfields@fieldses.org>
> >> M: Neil Brown <neilb@suse.de>
> >> L: linux-nfs@vger.kernel.org
> >> W: http://nfs.sourceforge.net/
> >> @@ -3848,7 +3848,7 @@ F: mm/kmemleak-test.c
> >> KPROBES
> >> M: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> >> M: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
> >> -M: "David S. Miller" <davem@davemloft.net>
> >> +M: David S. Miller <davem@davemloft.net>
> >> M: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> >> S: Maintained
> >> F: Documentation/kprobes.txt
> >> @@ -3872,7 +3872,7 @@ F: include/*/lapb.h
> >> F: net/lapb/
> >>
> >> LASI 53c700 driver for PARISC
> >> -M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> >> +M: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
> >> L: linux-scsi@vger.kernel.org
> >> S: Maintained
> >> F: Documentation/scsi/53c700.txt
> >> @@ -4040,7 +4040,7 @@ F: include/linux/lockdep.h
> >> F: kernel/lockdep*
> >>
> >> LOGICAL DISK MANAGER SUPPORT (LDM, Windows 2000/XP/Vista Dynamic Disks)
> >> -M: "Richard Russon (FlatCap)" <ldm@flatcap.org>
> >> +M: Richard Russon (FlatCap) <ldm@flatcap.org>
> >> L: linux-ntfs-dev@lists.sourceforge.net
> >> W: http://www.linux-ntfs.org/content/view/19/37/
> >> S: Maintained
> >> @@ -4191,14 +4191,14 @@ F: drivers/video/matrox/matroxfb_*
> >> F: include/linux/matroxfb.h
> >>
> >> MAX1668 TEMPERATURE SENSOR DRIVER
> >> -M: "David George" <david.george@ska.ac.za>
> >> +M: David George <david.george@ska.ac.za>
> >> L: lm-sensors@lm-sensors.org
> >> S: Maintained
> >> F: Documentation/hwmon/max1668
> >> F: drivers/hwmon/max1668.c
> >>
> >> MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER
> >> -M: "Hans J. Koch" <hjk@hansjkoch.de>
> >> +M: Hans J. Koch <hjk@hansjkoch.de>
> >> L: lm-sensors@lm-sensors.org
> >> S: Maintained
> >> F: Documentation/hwmon/max6650
> >> @@ -4318,7 +4318,7 @@ F: Documentation/serial/moxa-smartio
> >> F: drivers/tty/mxser.*
> >>
> >> MSI LAPTOP SUPPORT
> >> -M: "Lee, Chun-Yi" <jlee@novell.com>
> >> +M: Lee, Chun-Yi <jlee@novell.com>
> >> L: platform-driver-x86@vger.kernel.org
> >> S: Maintained
> >> F: drivers/platform/x86/msi-laptop.c
> >> @@ -4392,7 +4392,7 @@ S: Odd Fixes
> >> F: fs/ncpfs/
> >>
> >> NCR DUAL 700 SCSI DRIVER (MICROCHANNEL)
> >> -M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> >> +M: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
> >> L: linux-scsi@vger.kernel.org
> >> S: Maintained
> >> F: drivers/scsi/NCR_D700.*
> >> @@ -4475,7 +4475,7 @@ W: https://fedorahosted.org/dropwatch/
> >> F: net/core/drop_monitor.c
> >>
> >> NETWORKING [GENERAL]
> >> -M: "David S. Miller" <davem@davemloft.net>
> >> +M: David S. Miller <davem@davemloft.net>
> >> L: netdev@vger.kernel.org
> >> W: http://www.linuxfoundation.org/en/Net
> >> W: http://patchwork.ozlabs.org/project/netdev/list/
> >> @@ -4489,7 +4489,7 @@ F: include/linux/net.h
> >> F: include/linux/netdevice.h
> >>
> >> NETWORKING [IPv4/IPv6]
> >> -M: "David S. Miller" <davem@davemloft.net>
> >> +M: David S. Miller <davem@davemloft.net>
> >> M: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> >> M: James Morris <jmorris@namei.org>
> >> M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> >> @@ -4508,7 +4508,7 @@ L: netdev@vger.kernel.org
> >> S: Maintained
> >>
> >> NETWORKING [WIRELESS]
> >> -M: "John W. Linville" <linville@tuxdriver.com>
> >> +M: John W. Linville <linville@tuxdriver.com>
> >> L: linux-wireless@vger.kernel.org
> >> Q: http://patchwork.kernel.org/project/linux-wireless/list/
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> >> @@ -4896,7 +4896,7 @@ F: drivers/block/paride/
> >> PARISC ARCHITECTURE
> >> M: Kyle McMartin <kyle@mcmartin.ca>
> >> M: Helge Deller <deller@gmx.de>
> >> -M: "James E.J. Bottomley" <jejb@parisc-linux.org>
> >> +M: James E.J. Bottomley <jejb@parisc-linux.org>
> >> L: linux-parisc@vger.kernel.org
> >> W: http://www.parisc-linux.org/
> >> Q: http://patchwork.kernel.org/project/linux-parisc/list/
> >> @@ -5164,7 +5164,7 @@ F: Documentation/preempt-locking.txt
> >> F: include/linux/preempt.h
> >>
> >> PRISM54 WIRELESS DRIVER
> >> -M: "Luis R. Rodriguez" <mcgrof@gmail.com>
> >> +M: Luis R. Rodriguez <mcgrof@gmail.com>
> >> L: linux-wireless@vger.kernel.org
> >> W: http://wireless.kernel.org/en/users/Drivers/p54
> >> S: Obsolete
> >> @@ -5384,7 +5384,7 @@ F: drivers/net/wireless/ray*
> >>
> >> RCUTORTURE MODULE
> >> M: Josh Triplett <josh@freedesktop.org>
> >> -M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> >> +M: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> S: Supported
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
> >> F: Documentation/RCU/torture.txt
> >> @@ -5408,7 +5408,7 @@ F: net/rds/
> >>
> >> READ-COPY UPDATE (RCU)
> >> M: Dipankar Sarma <dipankar@in.ibm.com>
> >> -M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> >> +M: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >> W: http://www.rdrop.com/users/paulmck/rclock/
> >> S: Supported
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
> >> @@ -5480,7 +5480,7 @@ F: include/net/rose.h
> >> F: net/rose/
> >>
> >> RTL8180 WIRELESS DRIVER
> >> -M: "John W. Linville" <linville@tuxdriver.com>
> >> +M: John W. Linville <linville@tuxdriver.com>
> >> L: linux-wireless@vger.kernel.org
> >> W: http://linuxwireless.org/
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> >> @@ -5661,7 +5661,7 @@ F: drivers/scsi/sg.c
> >> F: include/scsi/sg.h
> >>
> >> SCSI SUBSYSTEM
> >> -M: "James E.J. Bottomley" <JBottomley@parallels.com>
> >> +M: James E.J. Bottomley <JBottomley@parallels.com>
> >> L: linux-scsi@vger.kernel.org
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
> >> @@ -5886,7 +5886,7 @@ S: Maintained
> >> F: drivers/net/ethernet/sis/sis900.*
> >>
> >> SIS 96X I2C/SMBUS DRIVER
> >> -M: "Mark M. Hoffman" <mhoffman@lightlink.com>
> >> +M: Mark M. Hoffman <mhoffman@lightlink.com>
> >> L: linux-i2c@vger.kernel.org
> >> S: Maintained
> >> F: Documentation/i2c/busses/i2c-sis96x
> >> @@ -5948,7 +5948,7 @@ F: Documentation/hwmon/sch5627
> >> F: drivers/hwmon/sch5627.c
> >>
> >> SMSC47B397 HARDWARE MONITOR DRIVER
> >> -M: "Mark M. Hoffman" <mhoffman@lightlink.com>
> >> +M: Mark M. Hoffman <mhoffman@lightlink.com>
> >> L: lm-sensors@lm-sensors.org
> >> S: Maintained
> >> F: Documentation/hwmon/smsc47b397
> >> @@ -6054,7 +6054,7 @@ F: sound/soc/
> >> F: include/sound/soc*
> >>
> >> SPARC + UltraSPARC (sparc/sparc64)
> >> -M: "David S. Miller" <davem@davemloft.net>
> >> +M: David S. Miller <davem@davemloft.net>
> >> L: sparclinux@vger.kernel.org
> >> Q: http://patchwork.ozlabs.org/project/sparclinux/list/
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6.git
> >> @@ -6064,7 +6064,7 @@ F: arch/sparc/
> >> F: drivers/sbus/
> >>
> >> SPARC SERIAL DRIVERS
> >> -M: "David S. Miller" <davem@davemloft.net>
> >> +M: David S. Miller <davem@davemloft.net>
> >> L: sparclinux@vger.kernel.org
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6.git
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next-2.6.git
> >> @@ -6349,7 +6349,7 @@ F: drivers/sh/
> >> SUSPEND TO RAM
> >> M: Len Brown <len.brown@intel.com>
> >> M: Pavel Machek <pavel@ucw.cz>
> >> -M: "Rafael J. Wysocki" <rjw@sisk.pl>
> >> +M: Rafael J. Wysocki <rjw@sisk.pl>
> >> L: linux-pm@vger.kernel.org
> >> S: Supported
> >> F: Documentation/power/
> >> @@ -6402,8 +6402,8 @@ F: include/net/pkt_cls.h
> >> F: net/sched/
> >>
> >> TCP LOW PRIORITY MODULE
> >> -M: "Wong Hoi Sing, Edison" <hswong3i@gmail.com>
> >> -M: "Hung Hing Lun, Mike" <hlhung3i@gmail.com>
> >> +M: Wong Hoi Sing, Edison <hswong3i@gmail.com>
> >> +M: Hung Hing Lun, Mike <hlhung3i@gmail.com>
> >> W: http://tcp-lp-mod.sourceforge.net/
> >> S: Maintained
> >> F: net/ipv4/tcp_lp.c
> >> @@ -6586,7 +6586,7 @@ F: Documentation/networking/tuntap.txt
> >> F: arch/um/os-Linux/drivers/
> >>
> >> TURBOCHANNEL SUBSYSTEM
> >> -M: "Maciej W. Rozycki" <macro@linux-mips.org>
> >> +M: Maciej W. Rozycki <macro@linux-mips.org>
> >> S: Maintained
> >> F: drivers/tc/
> >> F: include/linux/tc.h
> >> @@ -6983,7 +6983,7 @@ F: fs/hostfs/
> >> F: fs/hppfs/
> >>
> >> USERSPACE I/O (UIO)
> >> -M: "Hans J. Koch" <hjk@hansjkoch.de>
> >> +M: Hans J. Koch <hjk@hansjkoch.de>
> >> M: Greg Kroah-Hartman <gregkh@suse.de>
> >> S: Maintained
> >> F: Documentation/DocBook/uio-howto.tmpl
> >> @@ -7029,7 +7029,7 @@ F: include/linux/virtio_console.h
> >>
> >> VIRTIO CORE, NET AND BLOCK DRIVERS
> >> M: Rusty Russell <rusty@rustcorp.com.au>
> >> -M: "Michael S. Tsirkin" <mst@redhat.com>
> >> +M: Michael S. Tsirkin <mst@redhat.com>
> >> L: virtualization@lists.linux-foundation.org
> >> S: Maintained
> >> F: drivers/virtio/
> >> @@ -7038,7 +7038,7 @@ F: drivers/block/virtio_blk.c
> >> F: include/linux/virtio_*.h
> >>
> >> VIRTIO HOST (VHOST)
> >> -M: "Michael S. Tsirkin" <mst@redhat.com>
> >> +M: Michael S. Tsirkin <mst@redhat.com>
> >> L: kvm@vger.kernel.org
> >> L: virtualization@lists.linux-foundation.org
> >> L: netdev@vger.kernel.org
> >> @@ -7096,7 +7096,7 @@ F: include/linux/vlynq.h
> >>
> >> VMWARE VMXNET3 ETHERNET DRIVER
> >> M: Shreyas Bhatewara <sbhatewara@vmware.com>
> >> -M: "VMware, Inc." <pv-drivers@vmware.com>
> >> +M: VMware, Inc. <pv-drivers@vmware.com>
> >> L: netdev@vger.kernel.org
> >> S: Maintained
> >> F: drivers/net/vmxnet3/
> >> @@ -7293,7 +7293,7 @@ F: net/x25/
> >> X86 ARCHITECTURE (32-BIT AND 64-BIT)
> >> M: Thomas Gleixner <tglx@linutronix.de>
> >> M: Ingo Molnar <mingo@redhat.com>
> >> -M: "H. Peter Anvin" <hpa@zytor.com>
> >> +M: H. Peter Anvin <hpa@zytor.com>
> >> M: x86@kernel.org
> >> T: git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
> >> S: Maintained
> >> @@ -7412,7 +7412,7 @@ S: Odd Fixes
> >> F: drivers/media/video/zoran/
> >>
> >> ZS DECSTATION Z85C30 SERIAL DRIVER
> >> -M: "Maciej W. Rozycki" <macro@linux-mips.org>
> >> +M: Maciej W. Rozycki <macro@linux-mips.org>
> >> S: Maintained
> >> F: drivers/tty/serial/zs.*
> >>
> >> --
> >> 1.7.4.4
> >>
> >
> > Adding lkml and netdev mailing lists...
> >
> > The reason these names are in quotes is because they need to be wrapped in quotes when used in a git patch (I.e. CC: "David S. Miller" <davem@davemloft.net>) because of the . in the friendly name.
> >
> Sorry, I thought that is a so trivial patch that doesn't need to copy lkml
> and netdev...
>
> So, if the quotes aren't necessary, this patch will be discarded?
>
I think you meant to say "if the quotes ARE necessary, this patch will
be discarded?"
Yes, if a patch needs changes or has issues, the patch would be
discarded (not applied).
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove quotes of maintaners's names
From: Sam Ravnborg @ 2011-10-27 21:53 UTC (permalink / raw)
To: Kirsher, Jeffrey T
Cc: Marcos Paulo de Souza, akpm@linux-foundation.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <610B86C6-622E-4EFE-89DF-BF09BDB4D765@intel.com>
On Thu, Oct 27, 2011 at 02:35:54PM -0700, Kirsher, Jeffrey T wrote:
> On Oct 27, 2011, at 14:14, "Marcos Paulo de Souza" <marcos.mage@gmail.com> wrote:
>
> > Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
> > ---
> > MAINTAINERS | 128 +++++++++++++++++++++++++++++-----------------------------
> > 1 files changed, 64 insertions(+), 64 deletions(-)
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 27af9c9..0bea8d7 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -140,7 +140,7 @@ S: Supported
> > F: drivers/scsi/3w-*
> >
> > 53C700 AND 53C700-66 SCSI DRIVER
> > -M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> > +M: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
> > L: linux-scsi@vger.kernel.org
> > S: Maintained
> > F: drivers/scsi/53c700*
> > @@ -422,7 +422,7 @@ F: drivers/char/agp/
> > F: include/linux/agp*
> >
>
> Adding lkml and netdev mailing lists...
>
> The reason these names are in quotes is because they need to be wrapped in quotes when used in a git patch (I.e. CC: "David S. Miller" <davem@davemloft.net>) because of the . in the friendly name.
And anyone that copy'n'paste the name to their mail client would also by screwed if
the quotes are missing.
Sam
^ permalink raw reply
* Re: [PATCH 2/2 v3] net/smsc911x: Add regulator support
From: Mark Brown @ 2011-10-27 21:42 UTC (permalink / raw)
To: Mike Frysinger
Cc: Linus Walleij, netdev, Steve Glendinning, Mathieu Poirer,
Robert Marklund, Paul Mundt, linux-sh, Sascha Hauer,
Tony Lindgren, linux-omap, uclinux-dist-devel, Linus Walleij
In-Reply-To: <CAJaTeTpzFOdgqGH3vDWY8Mdx7zra8R9nUQYHgsEBfy_yGkEWOw@mail.gmail.com>
On Thu, Oct 27, 2011 at 10:59:14PM +0200, Mike Frysinger wrote:
> i saw that !CONFIG_REGULATOR works great. my concern is that these
> boards don't define any regulators for smsc resources, so if
> CONFIG_REGULATOR is enabled to test out unrelated daughter cards, i
> don't want the network driver suddenly failing. Linus' comments
> suggest that this is what would happen unless each board file has its
> smsc platform resources extended. maybe i misunderstood what he was saying ?
That's the case that's handled by CONFIG_REGULATOR_DUMMY - if the lookup
fails the core will provide a virtual regulator to the consumer. If
you're running a setup like that you probably want to enable dummy
regulators anyway.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Remove quotes of maintaners's names
From: Kirsher, Jeffrey T @ 2011-10-27 21:35 UTC (permalink / raw)
To: Marcos Paulo de Souza
Cc: akpm@linux-foundation.org, Marcos Paulo de Souza,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1319739381-5244-1-git-send-email-marcos.mage@gmail.com>
On Oct 27, 2011, at 14:14, "Marcos Paulo de Souza" <marcos.mage@gmail.com> wrote:
> Signed-off-by: Marcos Paulo de Souza <marcos.mage@gmail.com>
> ---
> MAINTAINERS | 128 +++++++++++++++++++++++++++++-----------------------------
> 1 files changed, 64 insertions(+), 64 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 27af9c9..0bea8d7 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -140,7 +140,7 @@ S: Supported
> F: drivers/scsi/3w-*
>
> 53C700 AND 53C700-66 SCSI DRIVER
> -M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> +M: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
> L: linux-scsi@vger.kernel.org
> S: Maintained
> F: drivers/scsi/53c700*
> @@ -422,7 +422,7 @@ F: drivers/char/agp/
> F: include/linux/agp*
>
> AHA152X SCSI DRIVER
> -M: "Juergen E. Fischer" <fischer@norbit.de>
> +M: Juergen E. Fischer <fischer@norbit.de>
> L: linux-scsi@vger.kernel.org
> S: Maintained
> F: drivers/scsi/aha152x*
> @@ -1096,7 +1096,7 @@ F: arch/arm/mach-shmobile/
> F: drivers/sh/
>
> ARM/TELECHIPS ARM ARCHITECTURE
> -M: "Hans J. Koch" <hjk@hansjkoch.de>
> +M: Hans J. Koch <hjk@hansjkoch.de>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
> F: arch/arm/plat-tcc/
> @@ -1108,7 +1108,7 @@ L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
>
> ARM/TETON BGA MACHINE SUPPORT
> -M: "Mark F. Brown" <mark.brown314@gmail.com>
> +M: Mark F. Brown <mark.brown314@gmail.com>
> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
> S: Maintained
>
> @@ -1200,7 +1200,7 @@ F: drivers/platform/x86/asus*.c
> F: drivers/platform/x86/eeepc*.c
>
> ASUS ASB100 HARDWARE MONITOR DRIVER
> -M: "Mark M. Hoffman" <mhoffman@lightlink.com>
> +M: Mark M. Hoffman <mhoffman@lightlink.com>
> L: lm-sensors@lm-sensors.org
> S: Maintained
> F: drivers/hwmon/asb100.c
> @@ -1223,14 +1223,14 @@ F: drivers/misc/eeprom/at24.c
> F: include/linux/i2c/at24.h
>
> ATA OVER ETHERNET (AOE) DRIVER
> -M: "Ed L. Cashin" <ecashin@coraid.com>
> +M: Ed L. Cashin <ecashin@coraid.com>
> W: http://www.coraid.com/support/linux
> S: Supported
> F: Documentation/aoe/
> F: drivers/block/aoe/
>
> ATHEROS ATH GENERIC UTILITIES
> -M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
> +M: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
> L: linux-wireless@vger.kernel.org
> S: Supported
> F: drivers/net/wireless/ath/*
> @@ -1238,7 +1238,7 @@ F: drivers/net/wireless/ath/*
> ATHEROS ATH5K WIRELESS DRIVER
> M: Jiri Slaby <jirislaby@gmail.com>
> M: Nick Kossifidis <mickflemm@gmail.com>
> -M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
> +M: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
> M: Bob Copeland <me@bobcopeland.com>
> L: linux-wireless@vger.kernel.org
> L: ath5k-devel@lists.ath5k.org
> @@ -1255,7 +1255,7 @@ S: Supported
> F: drivers/net/wireless/ath/ath6kl/
>
> ATHEROS ATH9K WIRELESS DRIVER
> -M: "Luis R. Rodriguez" <mcgrof@qca.qualcomm.com>
> +M: Luis R. Rodriguez <mcgrof@qca.qualcomm.com>
> M: Jouni Malinen <jouni@qca.qualcomm.com>
> M: Vasanthakumar Thiagarajan <vthiagar@qca.qualcomm.com>
> M: Senthil Balasubramanian <senthilb@qca.qualcomm.com>
> @@ -1436,7 +1436,7 @@ F: Documentation/filesystems/befs.txt
> F: fs/befs/
>
> BFS FILE SYSTEM
> -M: "Tigran A. Aivazian" <tigran@aivazian.fsnet.co.uk>
> +M: Tigran A. Aivazian <tigran@aivazian.fsnet.co.uk>
> S: Maintained
> F: Documentation/filesystems/bfs.txt
> F: fs/bfs/
> @@ -1504,7 +1504,7 @@ F: drivers/mtd/devices/block2mtd.c
>
> BLUETOOTH DRIVERS
> M: Marcel Holtmann <marcel@holtmann.org>
> -M: "Gustavo F. Padovan" <padovan@profusion.mobi>
> +M: Gustavo F. Padovan <padovan@profusion.mobi>
> L: linux-bluetooth@vger.kernel.org
> W: http://www.bluez.org/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
> @@ -1513,7 +1513,7 @@ F: drivers/bluetooth/
>
> BLUETOOTH SUBSYSTEM
> M: Marcel Holtmann <marcel@holtmann.org>
> -M: "Gustavo F. Padovan" <padovan@profusion.mobi>
> +M: Gustavo F. Padovan <padovan@profusion.mobi>
> L: linux-bluetooth@vger.kernel.org
> W: http://www.bluez.org/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-2.6.git
> @@ -1659,7 +1659,7 @@ F: net/caif/
>
> CALGARY x86-64 IOMMU
> M: Muli Ben-Yehuda <muli@il.ibm.com>
> -M: "Jon D. Mason" <jdmason@kudzu.us>
> +M: Jon D. Mason <jdmason@kudzu.us>
> L: discuss@x86-64.org
> S: Maintained
> F: arch/x86/kernel/pci-calgary_64.c
> @@ -1925,7 +1925,7 @@ F: drivers/cpufreq/
> F: include/linux/cpufreq.h
>
> CPUID/MSR DRIVER
> -M: "H. Peter Anvin" <hpa@zytor.com>
> +M: H. Peter Anvin <hpa@zytor.com>
> S: Maintained
> F: arch/x86/kernel/cpuid.c
> F: arch/x86/kernel/msr.c
> @@ -1962,7 +1962,7 @@ F: drivers/tty/serial/crisv10.*
>
> CRYPTO API
> M: Herbert Xu <herbert@gondor.apana.org.au>
> -M: "David S. Miller" <davem@davemloft.net>
> +M: David S. Miller <davem@davemloft.net>
> L: linux-crypto@vger.kernel.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
> S: Maintained
> @@ -2116,7 +2116,7 @@ F: Documentation/networking/decnet.txt
> F: net/decnet/
>
> DEFXX FDDI NETWORK DRIVER
> -M: "Maciej W. Rozycki" <macro@linux-mips.org>
> +M: Maciej W. Rozycki <macro@linux-mips.org>
> S: Maintained
> F: drivers/net/fddi/defxx.*
>
> @@ -2169,7 +2169,7 @@ F: include/linux/device-mapper.h
> F: include/linux/dm-*.h
>
> DIGI INTL. EPCA DRIVER
> -M: "Digi International, Inc" <Eng.Linux@digi.com>
> +M: Digi International, Inc <Eng.Linux@digi.com>
> L: Eng.Linux@digi.com
> W: http://www.digi.com
> S: Orphan
> @@ -2248,7 +2248,7 @@ S: Maintained
> F: Documentation/
>
> DOUBLETALK DRIVER
> -M: "James R. Van Zandt" <jrv@vanzandt.mv.com>
> +M: James R. Van Zandt <jrv@vanzandt.mv.com>
> L: blinux-list@redhat.com
> S: Maintained
> F: drivers/char/dtlk.c
> @@ -2317,7 +2317,7 @@ F: lib/dynamic_debug.c
> F: include/linux/dynamic_debug.h
>
> DZ DECSTATION DZ11 SERIAL DRIVER
> -M: "Maciej W. Rozycki" <macro@linux-mips.org>
> +M: Maciej W. Rozycki <macro@linux-mips.org>
> S: Maintained
> F: drivers/tty/serial/dz.*
>
> @@ -2436,7 +2436,7 @@ F: include/linux/edac_mce.h
>
> EDAC-I82975X
> M: Ranganathan Desikan <ravi@jetztechnologies.com>
> -M: "Arvind R." <arvino55@gmail.com>
> +M: Arvind R. <arvino55@gmail.com>
> L: bluesmoke-devel@lists.sourceforge.net (moderated for non-subscribers)
> W: bluesmoke.sourceforge.net
> S: Maintained
> @@ -2565,7 +2565,7 @@ F: fs/ext3/
> F: include/linux/ext3*
>
> EXT4 FILE SYSTEM
> -M: "Theodore Ts'o" <tytso@mit.edu>
> +M: Theodore Ts'o <tytso@mit.edu>
> M: Andreas Dilger <adilger.kernel@dilger.ca>
> L: linux-ext4@vger.kernel.org
> W: http://ext4.wiki.kernel.org
> @@ -2759,7 +2759,7 @@ F: fs/freevxfs/
>
> FREEZER
> M: Pavel Machek <pavel@ucw.cz>
> -M: "Rafael J. Wysocki" <rjw@sisk.pl>
> +M: Rafael J. Wysocki <rjw@sisk.pl>
> L: linux-pm@vger.kernel.org
> S: Supported
> F: Documentation/power/freezing-of-tasks.txt
> @@ -2840,7 +2840,7 @@ S: Maintained
> F: include/asm-generic
>
> GENERIC UIO DRIVER FOR PCI DEVICES
> -M: "Michael S. Tsirkin" <mst@redhat.com>
> +M: Michael S. Tsirkin <mst@redhat.com>
> L: kvm@vger.kernel.org
> S: Supported
> F: drivers/uio/uio_pci_generic.c
> @@ -2991,7 +2991,7 @@ F: Documentation/blockdev/cpqarray.txt
> F: drivers/block/cpqarray.*
>
> HEWLETT-PACKARD SMART ARRAY RAID DRIVER (hpsa)
> -M: "Stephen M. Cameron" <scameron@beardog.cce.hp.com>
> +M: Stephen M. Cameron <scameron@beardog.cce.hp.com>
> L: iss_storagedev@hp.com
> S: Supported
> F: Documentation/scsi/hpsa.txt
> @@ -3021,7 +3021,7 @@ F: drivers/video/hgafb.c
>
> HIBERNATION (aka Software Suspend, aka swsusp)
> M: Pavel Machek <pavel@ucw.cz>
> -M: "Rafael J. Wysocki" <rjw@sisk.pl>
> +M: Rafael J. Wysocki <rjw@sisk.pl>
> L: linux-pm@vger.kernel.org
> S: Supported
> F: arch/x86/power/
> @@ -3101,7 +3101,7 @@ F: drivers/char/hpet.c
> F: include/linux/hpet.h
>
> HPET: x86
> -M: "Venkatesh Pallipadi (Venki)" <venki@google.com>
> +M: Venkatesh Pallipadi (Venki) <venki@google.com>
> S: Maintained
> F: arch/x86/kernel/hpet.c
> F: arch/x86/include/asm/hpet.h
> @@ -3130,14 +3130,14 @@ S: Maintained
> F: fs/hugetlbfs/
>
> I2C/SMBUS STUB DRIVER
> -M: "Mark M. Hoffman" <mhoffman@lightlink.com>
> +M: Mark M. Hoffman <mhoffman@lightlink.com>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> F: drivers/i2c/busses/i2c-stub.c
>
> I2C SUBSYSTEM
> -M: "Jean Delvare (PC drivers, core)" <khali@linux-fr.org>
> -M: "Ben Dooks (embedded platforms)" <ben-linux@fluff.org>
> +M: Jean Delvare (PC drivers, core) <khali@linux-fr.org>
> +M: Ben Dooks (embedded platforms) <ben-linux@fluff.org>
> L: linux-i2c@vger.kernel.org
> W: http://i2c.wiki.kernel.org/
> T: quilt kernel.org/pub/linux/kernel/people/jdelvare/linux-2.6/jdelvare-i2c/
> @@ -3156,12 +3156,12 @@ S: Maintained
> F: drivers/i2c/busses/i2c-tiny-usb.c
>
> i386 BOOT CODE
> -M: "H. Peter Anvin" <hpa@zytor.com>
> +M: H. Peter Anvin <hpa@zytor.com>
> S: Maintained
> F: arch/x86/boot/
>
> i386 SETUP CODE / CPU ERRATA WORKAROUNDS
> -M: "H. Peter Anvin" <hpa@zytor.com>
> +M: H. Peter Anvin <hpa@zytor.com>
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-x86setup.git
> S: Maintained
>
> @@ -3199,7 +3199,7 @@ S: Supported
> F: drivers/scsi/ips.*
>
> IDE SUBSYSTEM
> -M: "David S. Miller" <davem@davemloft.net>
> +M: David S. Miller <davem@davemloft.net>
> L: linux-ide@vger.kernel.org
> Q: http://patchwork.ozlabs.org/project/linux-ide/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6.git
> @@ -3647,7 +3647,7 @@ F: include/linux/ext3_jbd.h
> F: include/linux/jbd.h
>
> JOURNALLING LAYER FOR BLOCK DEVICES (JBD2)
> -M: "Theodore Ts'o" <tytso@mit.edu>
> +M: Theodore Ts'o <tytso@mit.edu>
> L: linux-ext4@vger.kernel.org
> S: Maintained
> F: fs/jbd2/
> @@ -3713,7 +3713,7 @@ W: http://kernelnewbies.org/KernelJanitors
> S: Odd Fixes
>
> KERNEL NFSD, SUNRPC, AND LOCKD SERVERS
> -M: "J. Bruce Fields" <bfields@fieldses.org>
> +M: J. Bruce Fields <bfields@fieldses.org>
> M: Neil Brown <neilb@suse.de>
> L: linux-nfs@vger.kernel.org
> W: http://nfs.sourceforge.net/
> @@ -3848,7 +3848,7 @@ F: mm/kmemleak-test.c
> KPROBES
> M: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> M: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
> -M: "David S. Miller" <davem@davemloft.net>
> +M: David S. Miller <davem@davemloft.net>
> M: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
> S: Maintained
> F: Documentation/kprobes.txt
> @@ -3872,7 +3872,7 @@ F: include/*/lapb.h
> F: net/lapb/
>
> LASI 53c700 driver for PARISC
> -M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> +M: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
> L: linux-scsi@vger.kernel.org
> S: Maintained
> F: Documentation/scsi/53c700.txt
> @@ -4040,7 +4040,7 @@ F: include/linux/lockdep.h
> F: kernel/lockdep*
>
> LOGICAL DISK MANAGER SUPPORT (LDM, Windows 2000/XP/Vista Dynamic Disks)
> -M: "Richard Russon (FlatCap)" <ldm@flatcap.org>
> +M: Richard Russon (FlatCap) <ldm@flatcap.org>
> L: linux-ntfs-dev@lists.sourceforge.net
> W: http://www.linux-ntfs.org/content/view/19/37/
> S: Maintained
> @@ -4191,14 +4191,14 @@ F: drivers/video/matrox/matroxfb_*
> F: include/linux/matroxfb.h
>
> MAX1668 TEMPERATURE SENSOR DRIVER
> -M: "David George" <david.george@ska.ac.za>
> +M: David George <david.george@ska.ac.za>
> L: lm-sensors@lm-sensors.org
> S: Maintained
> F: Documentation/hwmon/max1668
> F: drivers/hwmon/max1668.c
>
> MAX6650 HARDWARE MONITOR AND FAN CONTROLLER DRIVER
> -M: "Hans J. Koch" <hjk@hansjkoch.de>
> +M: Hans J. Koch <hjk@hansjkoch.de>
> L: lm-sensors@lm-sensors.org
> S: Maintained
> F: Documentation/hwmon/max6650
> @@ -4318,7 +4318,7 @@ F: Documentation/serial/moxa-smartio
> F: drivers/tty/mxser.*
>
> MSI LAPTOP SUPPORT
> -M: "Lee, Chun-Yi" <jlee@novell.com>
> +M: Lee, Chun-Yi <jlee@novell.com>
> L: platform-driver-x86@vger.kernel.org
> S: Maintained
> F: drivers/platform/x86/msi-laptop.c
> @@ -4392,7 +4392,7 @@ S: Odd Fixes
> F: fs/ncpfs/
>
> NCR DUAL 700 SCSI DRIVER (MICROCHANNEL)
> -M: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
> +M: James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
> L: linux-scsi@vger.kernel.org
> S: Maintained
> F: drivers/scsi/NCR_D700.*
> @@ -4475,7 +4475,7 @@ W: https://fedorahosted.org/dropwatch/
> F: net/core/drop_monitor.c
>
> NETWORKING [GENERAL]
> -M: "David S. Miller" <davem@davemloft.net>
> +M: David S. Miller <davem@davemloft.net>
> L: netdev@vger.kernel.org
> W: http://www.linuxfoundation.org/en/Net
> W: http://patchwork.ozlabs.org/project/netdev/list/
> @@ -4489,7 +4489,7 @@ F: include/linux/net.h
> F: include/linux/netdevice.h
>
> NETWORKING [IPv4/IPv6]
> -M: "David S. Miller" <davem@davemloft.net>
> +M: David S. Miller <davem@davemloft.net>
> M: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> M: James Morris <jmorris@namei.org>
> M: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
> @@ -4508,7 +4508,7 @@ L: netdev@vger.kernel.org
> S: Maintained
>
> NETWORKING [WIRELESS]
> -M: "John W. Linville" <linville@tuxdriver.com>
> +M: John W. Linville <linville@tuxdriver.com>
> L: linux-wireless@vger.kernel.org
> Q: http://patchwork.kernel.org/project/linux-wireless/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-2.6.git
> @@ -4896,7 +4896,7 @@ F: drivers/block/paride/
> PARISC ARCHITECTURE
> M: Kyle McMartin <kyle@mcmartin.ca>
> M: Helge Deller <deller@gmx.de>
> -M: "James E.J. Bottomley" <jejb@parisc-linux.org>
> +M: James E.J. Bottomley <jejb@parisc-linux.org>
> L: linux-parisc@vger.kernel.org
> W: http://www.parisc-linux.org/
> Q: http://patchwork.kernel.org/project/linux-parisc/list/
> @@ -5164,7 +5164,7 @@ F: Documentation/preempt-locking.txt
> F: include/linux/preempt.h
>
> PRISM54 WIRELESS DRIVER
> -M: "Luis R. Rodriguez" <mcgrof@gmail.com>
> +M: Luis R. Rodriguez <mcgrof@gmail.com>
> L: linux-wireless@vger.kernel.org
> W: http://wireless.kernel.org/en/users/Drivers/p54
> S: Obsolete
> @@ -5384,7 +5384,7 @@ F: drivers/net/wireless/ray*
>
> RCUTORTURE MODULE
> M: Josh Triplett <josh@freedesktop.org>
> -M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> +M: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> S: Supported
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
> F: Documentation/RCU/torture.txt
> @@ -5408,7 +5408,7 @@ F: net/rds/
>
> READ-COPY UPDATE (RCU)
> M: Dipankar Sarma <dipankar@in.ibm.com>
> -M: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> +M: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> W: http://www.rdrop.com/users/paulmck/rclock/
> S: Supported
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
> @@ -5480,7 +5480,7 @@ F: include/net/rose.h
> F: net/rose/
>
> RTL8180 WIRELESS DRIVER
> -M: "John W. Linville" <linville@tuxdriver.com>
> +M: John W. Linville <linville@tuxdriver.com>
> L: linux-wireless@vger.kernel.org
> W: http://linuxwireless.org/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-testing.git
> @@ -5661,7 +5661,7 @@ F: drivers/scsi/sg.c
> F: include/scsi/sg.h
>
> SCSI SUBSYSTEM
> -M: "James E.J. Bottomley" <JBottomley@parallels.com>
> +M: James E.J. Bottomley <JBottomley@parallels.com>
> L: linux-scsi@vger.kernel.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
> @@ -5886,7 +5886,7 @@ S: Maintained
> F: drivers/net/ethernet/sis/sis900.*
>
> SIS 96X I2C/SMBUS DRIVER
> -M: "Mark M. Hoffman" <mhoffman@lightlink.com>
> +M: Mark M. Hoffman <mhoffman@lightlink.com>
> L: linux-i2c@vger.kernel.org
> S: Maintained
> F: Documentation/i2c/busses/i2c-sis96x
> @@ -5948,7 +5948,7 @@ F: Documentation/hwmon/sch5627
> F: drivers/hwmon/sch5627.c
>
> SMSC47B397 HARDWARE MONITOR DRIVER
> -M: "Mark M. Hoffman" <mhoffman@lightlink.com>
> +M: Mark M. Hoffman <mhoffman@lightlink.com>
> L: lm-sensors@lm-sensors.org
> S: Maintained
> F: Documentation/hwmon/smsc47b397
> @@ -6054,7 +6054,7 @@ F: sound/soc/
> F: include/sound/soc*
>
> SPARC + UltraSPARC (sparc/sparc64)
> -M: "David S. Miller" <davem@davemloft.net>
> +M: David S. Miller <davem@davemloft.net>
> L: sparclinux@vger.kernel.org
> Q: http://patchwork.ozlabs.org/project/sparclinux/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6.git
> @@ -6064,7 +6064,7 @@ F: arch/sparc/
> F: drivers/sbus/
>
> SPARC SERIAL DRIVERS
> -M: "David S. Miller" <davem@davemloft.net>
> +M: David S. Miller <davem@davemloft.net>
> L: sparclinux@vger.kernel.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-2.6.git
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc-next-2.6.git
> @@ -6349,7 +6349,7 @@ F: drivers/sh/
> SUSPEND TO RAM
> M: Len Brown <len.brown@intel.com>
> M: Pavel Machek <pavel@ucw.cz>
> -M: "Rafael J. Wysocki" <rjw@sisk.pl>
> +M: Rafael J. Wysocki <rjw@sisk.pl>
> L: linux-pm@vger.kernel.org
> S: Supported
> F: Documentation/power/
> @@ -6402,8 +6402,8 @@ F: include/net/pkt_cls.h
> F: net/sched/
>
> TCP LOW PRIORITY MODULE
> -M: "Wong Hoi Sing, Edison" <hswong3i@gmail.com>
> -M: "Hung Hing Lun, Mike" <hlhung3i@gmail.com>
> +M: Wong Hoi Sing, Edison <hswong3i@gmail.com>
> +M: Hung Hing Lun, Mike <hlhung3i@gmail.com>
> W: http://tcp-lp-mod.sourceforge.net/
> S: Maintained
> F: net/ipv4/tcp_lp.c
> @@ -6586,7 +6586,7 @@ F: Documentation/networking/tuntap.txt
> F: arch/um/os-Linux/drivers/
>
> TURBOCHANNEL SUBSYSTEM
> -M: "Maciej W. Rozycki" <macro@linux-mips.org>
> +M: Maciej W. Rozycki <macro@linux-mips.org>
> S: Maintained
> F: drivers/tc/
> F: include/linux/tc.h
> @@ -6983,7 +6983,7 @@ F: fs/hostfs/
> F: fs/hppfs/
>
> USERSPACE I/O (UIO)
> -M: "Hans J. Koch" <hjk@hansjkoch.de>
> +M: Hans J. Koch <hjk@hansjkoch.de>
> M: Greg Kroah-Hartman <gregkh@suse.de>
> S: Maintained
> F: Documentation/DocBook/uio-howto.tmpl
> @@ -7029,7 +7029,7 @@ F: include/linux/virtio_console.h
>
> VIRTIO CORE, NET AND BLOCK DRIVERS
> M: Rusty Russell <rusty@rustcorp.com.au>
> -M: "Michael S. Tsirkin" <mst@redhat.com>
> +M: Michael S. Tsirkin <mst@redhat.com>
> L: virtualization@lists.linux-foundation.org
> S: Maintained
> F: drivers/virtio/
> @@ -7038,7 +7038,7 @@ F: drivers/block/virtio_blk.c
> F: include/linux/virtio_*.h
>
> VIRTIO HOST (VHOST)
> -M: "Michael S. Tsirkin" <mst@redhat.com>
> +M: Michael S. Tsirkin <mst@redhat.com>
> L: kvm@vger.kernel.org
> L: virtualization@lists.linux-foundation.org
> L: netdev@vger.kernel.org
> @@ -7096,7 +7096,7 @@ F: include/linux/vlynq.h
>
> VMWARE VMXNET3 ETHERNET DRIVER
> M: Shreyas Bhatewara <sbhatewara@vmware.com>
> -M: "VMware, Inc." <pv-drivers@vmware.com>
> +M: VMware, Inc. <pv-drivers@vmware.com>
> L: netdev@vger.kernel.org
> S: Maintained
> F: drivers/net/vmxnet3/
> @@ -7293,7 +7293,7 @@ F: net/x25/
> X86 ARCHITECTURE (32-BIT AND 64-BIT)
> M: Thomas Gleixner <tglx@linutronix.de>
> M: Ingo Molnar <mingo@redhat.com>
> -M: "H. Peter Anvin" <hpa@zytor.com>
> +M: H. Peter Anvin <hpa@zytor.com>
> M: x86@kernel.org
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
> S: Maintained
> @@ -7412,7 +7412,7 @@ S: Odd Fixes
> F: drivers/media/video/zoran/
>
> ZS DECSTATION Z85C30 SERIAL DRIVER
> -M: "Maciej W. Rozycki" <macro@linux-mips.org>
> +M: Maciej W. Rozycki <macro@linux-mips.org>
> S: Maintained
> F: drivers/tty/serial/zs.*
>
> --
> 1.7.4.4
>
Adding lkml and netdev mailing lists...
The reason these names are in quotes is because they need to be wrapped in quotes when used in a git patch (I.e. CC: "David S. Miller" <davem@davemloft.net>) because of the . in the friendly name.
^ permalink raw reply
* Re: [PATCH v6 5/8] SUNRPC: cleanup service destruction
From: J. Bruce Fields @ 2011-10-27 21:30 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust, linux-nfs, xemul, neilb, netdev, linux-kernel,
davem, devel
In-Reply-To: <20111025101716.12689.81697.stgit@localhost6.localdomain6>
On Tue, Oct 25, 2011 at 02:17:18PM +0300, Stanislav Kinsbursky wrote:
> svc_unregister() call have to be removed from svc_destroy() since it will be
> called in sv_shutdown callback.
It would be clearer that you're *moving* this if this were merged with
the following patch. And without doing that the series isn't quite
bisectable, unless I'm missing something.
--b.
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky@parallels.com>
>
> ---
> net/sunrpc/svc.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index 918edc3..407462f 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -530,7 +530,6 @@ svc_destroy(struct svc_serv *serv)
> if (svc_serv_is_pooled(serv))
> svc_pool_map_put();
>
> - svc_unregister(serv);
> kfree(serv->sv_pools);
> kfree(serv);
> }
>
^ permalink raw reply
* Re: [PATCH v6 4/8] SUNRPC: setup rpcbind clients if service requires it
From: J. Bruce Fields @ 2011-10-27 21:27 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust-HgOvQuBEEgTQT0dZR+AlfA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA, xemul-bzQdu9zFT3WakBO8gow8eQ,
neilb-l3A5Bk7waGM, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
devel-GEFAQzZX7r8dnm+yROfE0A
In-Reply-To: <20111025101705.12689.68022.stgit-bi+AKbBUZKagILUCTcTcHdKyNwTtLsGr@public.gmane.org>
On Tue, Oct 25, 2011 at 02:17:08PM +0300, Stanislav Kinsbursky wrote:
> New function ("svc_uses_rpcbind") will be used to detect, that new service will
> send portmapper register calls. For such services we will create rpcbind
> clients and remove all stale portmap registrations.
> Also, svc_rpcb_cleanup() will be set as sv_shutdown callback for such services
> in case of this field wasn't initialized earlier. This will allow to destroy
> rpcbind clients when no other users of them left.
>
> Note: Currently, any creating service will be detected as portmap user.
> Probably, this is wrong. But now it depends on program versions "vs_hidden"
> flag.
>
> Signed-off-by: Stanislav Kinsbursky <skinsbursky-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
>
> ---
> net/sunrpc/svc.c | 11 +++++++++--
> 1 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/net/sunrpc/svc.c b/net/sunrpc/svc.c
> index d2d61bf..918edc3 100644
> --- a/net/sunrpc/svc.c
> +++ b/net/sunrpc/svc.c
> @@ -454,8 +454,15 @@ __svc_create(struct svc_program *prog, unsigned int bufsize, int npools,
> spin_lock_init(&pool->sp_lock);
> }
>
> - /* Remove any stale portmap registrations */
> - svc_unregister(serv);
> + if (svc_uses_rpcbind(serv)) {
> + if (svc_rpcb_setup(serv) < 0) {
> + kfree(serv->sv_pools);
> + kfree(serv);
> + return NULL;
Nit: could we convert this (and the previous failure to allocate
sv_pools) to the usual pattern of collecting the cleanup at the end and
jumping to it with a goto?
Looks fine otherwise.
--b.
> + }
> + if (!serv->sv_shutdown)
> + serv->sv_shutdown = svc_rpcb_cleanup;
> + }
>
> return serv;
> }
>
--
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 2/2 v3] net/smsc911x: Add regulator support
From: Mike Frysinger @ 2011-10-27 20:59 UTC (permalink / raw)
To: Mark Brown
Cc: Linus Walleij, netdev, Steve Glendinning, Mathieu Poirer,
Robert Marklund, Paul Mundt, linux-sh, Sascha Hauer,
Tony Lindgren, linux-omap, uclinux-dist-devel, Linus Walleij
In-Reply-To: <20111027154638.GA16946@sirena.org.uk>
On Thu, Oct 27, 2011 at 17:46, Mark Brown wrote:
> On Thu, Oct 27, 2011 at 03:21:47PM +0200, Mike Frysinger wrote:
>> my gut reaction: smsc911x is working just fine without regulator
>> support for many people, so why do we suddenly need to make it a
>> requirement ? this is a fairly small amount of code, so adding a
>> smsc911x Kconfig symbol to control the regulator support seems like
>> overkill. only other option would be to change the patch to not make
>> missing regulators non-fatal. so i'd probably lean towards the latter
>> (and it sounds like you changed this with earlier versions).
>
> The regulator API contains a series of generic facilities for stubbing
> itself out when not in use - there's no need for individual drivers to
> worry about this stuff, they should just rely on the framework. The
> main one at the minute is REGULATOR_DUMMY which does what you suggest
> and makes regulator_get() never fail.
i saw that !CONFIG_REGULATOR works great. my concern is that these
boards don't define any regulators for smsc resources, so if
CONFIG_REGULATOR is enabled to test out unrelated daughter cards, i
don't want the network driver suddenly failing. Linus' comments
suggest that this is what would happen unless each board file has its
smsc platform resources extended. maybe i misunderstood what he was saying ?
-mike
^ permalink raw reply
* Re: [PATCH v3 0/3] SUNRPC: rcbind clients virtualization
From: J. Bruce Fields @ 2011-10-27 20:25 UTC (permalink / raw)
To: Stanislav Kinsbursky
Cc: Trond.Myklebust, linux-nfs, xemul, neilb, netdev, linux-kernel,
davem, devel
In-Reply-To: <20111027180824.20459.23219.stgit@localhost6.localdomain6>
On Thu, Oct 27, 2011 at 10:10:43PM +0300, Stanislav Kinsbursky wrote:
> v3:
> 1) First two patches from previous version were squashed.
>
> This patch-set was created in context of clone of git branch:
> git://git.linux-nfs.org/projects/trondmy/nfs-2.6.git
> and rebased on tag "v3.1".
>
> This patch-set virtualizes rpcbind clients per network namespace context. IOW,
> each network namespace will have its own pair of rpcbind clients (if they would
> be created by request).
>
> Note:
> 1) this patch-set depends on "SUNRPC: make rpcbind clients allocated and
> destroyed dynamically" patch-set which has been send earlier.
> 2) init_net pointer is still used instead of current->nsproxy->net_ns,
> because I'm not sure yet about how to virtualize services. I.e. NFS callback
> services will be per netns. NFSd service will be per netns too from my pow. But
> Lockd can be per netns or one for all.
I'm not sure what you mean by that; could you explain?
--b.
> And also we have NFSd file system, which
> is not virtualized yet.
>
> The following series consists of:
>
> ---
>
> Stanislav Kinsbursky (3):
> SUNRPC: move rpcbind internals to sunrpc part of network namespace context
> SUNRPC: optimize net_ns dereferencing in rpcbind creation calls
> SUNRPC: optimize net_ns dereferencing in rpcbind registering calls
>
>
> net/sunrpc/netns.h | 5 ++
> net/sunrpc/rpcb_clnt.c | 103 ++++++++++++++++++++++++++----------------------
> 2 files changed, 61 insertions(+), 47 deletions(-)
>
> --
> Signature
^ permalink raw reply
* Re: [net 0/7] bnx2x: driver and firmware fixes
From: David Miller @ 2011-10-27 20:20 UTC (permalink / raw)
To: yanivr; +Cc: netdev
In-Reply-To: <1319728191-24938-1-git-send-email-yanivr@broadcom.com>
From: "Yaniv Rosner" <yanivr@broadcom.com>
Date: Thu, 27 Oct 2011 17:09:44 +0200
> The following patch series describe few link fixes and firmware update.
>
> Please consider applying it to net.
All applied, thank you.
^ permalink raw reply
* [RFC PATCH 5/5] net: add FCLONE_SCRATCH use to ipv6 udp path
From: Neil Horman @ 2011-10-27 19:53 UTC (permalink / raw)
To: netdev; +Cc: root, Neil Horman, David S. Miller
In-Reply-To: <1319745221-30880-1-git-send-email-nhorman@tuxdriver.com>
From: root <root@amd-dinar-01.lab.bos.redhat.com>
Like the ipv4 path, the ipv6 path can benefit from this change by taking
advantage of the unused space at the tail of an skbuffs data area. Mark ipv6
udp multicast frames as being elligible for scratch fcloning.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
---
net/ipv6/udp.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index f4ca0a5..dda6661 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -645,6 +645,8 @@ static int __udp6_lib_mcast_deliver(struct net *net, struct sk_buff *skb,
int dif;
unsigned int i, count = 0;
+ skb_make_fclone_scratch(skb);
+
spin_lock(&hslot->lock);
sk = sk_nulls_head(&hslot->head);
dif = inet6_iif(skb);
--
1.7.6.4
^ permalink raw reply related
* [RFC PATCH 4/5] perf: add perf script to monitor efficiency increase in FCLONE_SCRATCH api
From: Neil Horman @ 2011-10-27 19:53 UTC (permalink / raw)
To: netdev; +Cc: root, Neil Horman, David S. Miller
In-Reply-To: <1319745221-30880-1-git-send-email-nhorman@tuxdriver.com>
From: root <root@updev.think-freely.org>
Since the FCLONE_SCRATCH mehanism is opportunistic, gathering internally
fragmented memory when available, its beneficial to know how efficiently its
working, so that tuning can be implemented to optimize it. This patch adds a
perf script to export data collected via the previously added tracepoints.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
---
.../scripts/python/bin/net-fscratch-stats-record | 4 +
.../scripts/python/bin/net-fscratch-stats-report | 4 +
tools/perf/scripts/python/net-fscratch.py | 198 ++++++++++++++++++++
3 files changed, 206 insertions(+), 0 deletions(-)
create mode 100644 tools/perf/scripts/python/bin/net-fscratch-stats-record
create mode 100644 tools/perf/scripts/python/bin/net-fscratch-stats-report
create mode 100644 tools/perf/scripts/python/net-fscratch.py
diff --git a/tools/perf/scripts/python/bin/net-fscratch-stats-record b/tools/perf/scripts/python/bin/net-fscratch-stats-record
new file mode 100644
index 0000000..7aae593
--- /dev/null
+++ b/tools/perf/scripts/python/bin/net-fscratch-stats-record
@@ -0,0 +1,4 @@
+#!/bin/bash
+perf record -e skb:skb_make_fclone_scratch -e skb:alloc_fscratch_skb \
+ -e napi:napi_schedule -e napi:napi_complete \
+ -e napi:napi_poll -e net:netif_receive_skb $@
diff --git a/tools/perf/scripts/python/bin/net-fscratch-stats-report b/tools/perf/scripts/python/bin/net-fscratch-stats-report
new file mode 100644
index 0000000..85bb867
--- /dev/null
+++ b/tools/perf/scripts/python/bin/net-fscratch-stats-report
@@ -0,0 +1,4 @@
+#!/bin/bash
+# description: display a process of packet and processing time
+
+perf script -s "$PERF_EXEC_PATH"/scripts/python/net-fscratch.py $@
diff --git a/tools/perf/scripts/python/net-fscratch.py b/tools/perf/scripts/python/net-fscratch.py
new file mode 100644
index 0000000..f9ae5c9
--- /dev/null
+++ b/tools/perf/scripts/python/net-fscratch.py
@@ -0,0 +1,198 @@
+# Display a process of packets and processed time.
+# It helps us to investigate networking or network device.
+#
+# options
+# tx: show only tx chart
+# rx: show only rx chart
+# dev=: show only thing related to specified device
+# debug: work with debug mode. It shows buffer status.
+
+import os
+import sys
+
+sys.path.append(os.environ['PERF_EXEC_PATH'] + \
+ '/scripts/python/Perf-Trace-Util/lib/Perf/Trace')
+
+from perf_trace_context import *
+from Core import *
+from Util import *
+
+parent_skbs = {}
+
+total_parents=0
+total_children_avail=0
+total_children_used=0
+total_orphans=0
+
+IDX_FC_COUNT=0
+IDX_FC_KIDS=1
+
+STATE_START_TIMING=0
+STATE_TIMING=1
+STATE_COLLECT_TIMING=2
+STATE_RESET=3
+
+cpu_cycle_stats = {}
+cpu_total_stats = {}
+
+class cpuCycleStats():
+ def __init__(self):
+ self.start_rx_time = 0
+ self.end_rx_time = 0
+ self.state = STATE_RESET
+ self.total_rx_frames = 0
+
+class cpuTotalStats():
+ def __init__(self):
+ self.total_frames = 0
+ self.total_napi_time = 0
+ self.napi_sc_cycles = 0
+
+def gather_fclone_use_stats(stat):
+ global total_parents
+ global total_children_avail
+ global total_children_used
+
+ total_parents = total_parents+1
+ total_children_avail = total_children_avail + stat[IDX_FC_COUNT]
+ total_children_used = total_children_used + stat[IDX_FC_KIDS]
+
+# called from perf, when it finds a correspoinding event
+def skb__skb_make_fclone_scratch(event_name, context, common_cpu,
+ common_secs, common_nsecs, common_pid, common_comm,
+ skb, name, fccount):
+ global parent_skbs
+
+ if (skb in parent_skbs.keys()):
+ gather_fclone_use_stats(parent_skbs[skb])
+ parent_skbs[skb] = None
+
+ parent_skbs[skb] = [fccount, 0]
+
+def skb__alloc_fscratch_skb(event_name, context, common_cpu,
+ common_secs, common_nsecs, common_pid, common_comm,
+ parent, child):
+ global parent_skbs
+ global total_orphans
+
+ if (child == 0):
+ #We didn't have an fscratch_child to allocate
+ return
+
+ try:
+ parent_skbs[parent][IDX_FC_KIDS] += 1
+ except:
+ total_orphans += 1
+
+def napi__napi_schedule(event_name, context, common_cpu,
+ common_secs, common_nsecs, common_pid, common_comm,
+ napi, dev_name):
+ global cpu_cycle_stats
+
+ if (common_cpu in cpu_cycle_stats.keys()):
+ return;
+
+ cpu_cycle_stats[common_cpu] = cpuCycleStats()
+ cpu_cycle_stats[common_cpu].state = STATE_START_TIMING
+ return
+
+def napi__napi_complete(event_name, context, common_cpu,
+ common_secs, common_nsecs, common_pid, common_comm,
+ napi, dev_name):
+ global cpu_cycle_stats
+ global cpu_total_stats
+
+
+ if (common_cpu not in cpu_cycle_stats.keys()):
+ return
+
+ if (cpu_cycle_stats[common_cpu].state == STATE_TIMING):
+ cpu_cycle_stats[common_cpu].state = STATE_COLLECT_TIMING
+
+
+def napi__napi_poll(event_name, context, common_cpu,
+ common_secs, common_nsecs, common_pid, common_comm,
+ napi, dev_name):
+ global cpu_cycle_stats
+ global cpu_total_stats
+
+ if (common_cpu not in cpu_cycle_stats.keys()):
+ return
+
+
+ if (common_cpu not in cpu_total_stats.keys()):
+ cpu_total_stats[common_cpu] = cpuTotalStats()
+
+ state = cpu_cycle_stats[common_cpu].state
+
+ if (state == STATE_COLLECT_TIMING):
+ cpu_total_stats[common_cpu].napi_sc_cycles += 1
+
+ if (cpu_cycle_stats[common_cpu].end_rx_time == cpu_cycle_stats[common_cpu].start_rx_time):
+ cpu_cycle_stats[common_cpu].end_rx_time = common_nsecs
+
+ if ((state == STATE_COLLECT_TIMING) or (state == STATE_TIMING)):
+ if (cpu_cycle_stats[common_cpu].end_rx_time > cpu_cycle_stats[common_cpu].start_rx_time):
+ napi_time = cpu_cycle_stats[common_cpu].end_rx_time - cpu_cycle_stats[common_cpu].start_rx_time
+ else:
+ napi_time = cpu_cycle_stats[common_cpu].start_rx_time - cpu_cycle_stats[common_cpu].end_rx_time
+
+ if (napi_time == 0):
+ cpu_cycle_stats[common_cpu].total_rx_frames = 0
+
+ cpu_total_stats[common_cpu].total_frames += cpu_cycle_stats[common_cpu].total_rx_frames
+ cpu_total_stats[common_cpu].total_napi_time += napi_time
+ cpu_cycle_stats[common_cpu] = cpuCycleStats()
+ cpu_cycle_stats[common_cpu].state = STATE_START_TIMING
+
+
+def net__netif_receive_skb(event_name, context, common_cpu,
+ common_secs, common_nsecs, common_pid, common_comm,
+ skbaddr, len, name):
+ global cpu_cycle_stats
+
+ if (common_cpu not in cpu_cycle_stats.keys()):
+ return
+
+ if (cpu_cycle_stats[common_cpu].state == STATE_START_TIMING):
+ cpu_cycle_stats[common_cpu].state = STATE_TIMING
+ cpu_cycle_stats[common_cpu].start_rx_time = common_nsecs
+
+
+ if (cpu_cycle_stats[common_cpu].state == STATE_TIMING):
+ cpu_cycle_stats[common_cpu].total_rx_frames += 1
+ cpu_cycle_stats[common_cpu].end_rx_time = common_nsecs
+
+
+def trace_end():
+ global parent_skbs
+ global total_parents
+ global total_children_avail
+ global total_children_used
+ global total_orphans
+ global cpu_total_stats
+
+ for i in parent_skbs.keys():
+ gather_fclone_use_stats(parent_skbs[i])
+ try:
+ avg_offer_skb = str(total_children_avail / total_parents)
+ avg_used_skb = str(total_children_used / total_parents)
+ except:
+ avg_offer_skb = str(0)
+ avg_used_skb = str(0)
+
+ print "Performance report:"
+ print "Skbs marked as having scratch space available: " + str(total_parents)
+ print "Total fclone_scratch skb children available: " + str(total_children_avail)
+ print "Total fclone_scratch skb children used: " + str(total_children_used)
+ print "Total orphans: " + str(total_orphans)
+ print "Average number of scratch skbs available: " + avg_offer_skb
+ print "Average number of scratch skbs used: " + avg_used_skb
+ for i in cpu_total_stats.keys():
+ tframe = cpu_total_stats[i].total_frames
+ ttime = cpu_total_stats[i].total_napi_time
+ try:
+ print "CPU " + str(i) + " avg napi latency " + str(ttime/tframe) + " nsec/frame (" + str(ttime) + " " + str(tframe) + ")"
+ except:
+ print "CPU " + str(i) + " avg napi latency 0 usec/frame (" + str(ttime) + " " + str(tframe) + ")"
+ print "CPU " + str(i) + " napi sched/complete cycles: " + str(cpu_total_stats[i].napi_sc_cycles)
--
1.7.6.4
^ permalink raw reply related
* [RFC PATCH 3/5] net: Add & modify tracepoints to skb FCLONE_SCRATCH paths
From: Neil Horman @ 2011-10-27 19:53 UTC (permalink / raw)
To: netdev; +Cc: Neil Horman, Neil Horman, David S. Miller
In-Reply-To: <1319745221-30880-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@updev.think-freely.org>
Since skbs that are fcloned via the FCLONE_SCRATCH method are opportunistic, it
would be nice to have some feedback on how efficiently the path is acting.
These tracepoints provide the infrastructure needed to create perf scripts that
let us measure things like the number of skbs that are converted for
FCLONE_SCRATCH use, the number of scratch skbs that actually get
allocated, and the average per-packet time spent in the napi softirq context.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: "David S. Miller" <davem@davemloft.net>
---
include/linux/skbuff.h | 21 +--------------------
include/trace/events/napi.h | 41 +++++++++++++++++++++++++++++++++++++++++
include/trace/events/skb.h | 41 +++++++++++++++++++++++++++++++++++++++++
net/core/dev.c | 2 ++
net/core/skbuff.c | 37 +++++++++++++++++++++++++++++++++----
5 files changed, 118 insertions(+), 24 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index e04fa48..77e3605 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -2540,26 +2540,7 @@ extern unsigned int skb_make_fclone_scratch(struct sk_buff *skb);
/*
* Allocates an skb out of our scratch space
*/
-static inline struct sk_buff *alloc_fscratch_skb(struct sk_buff *skb)
-{
- struct skb_scr_control *sctl = skb_get_scratch_control(skb);
- struct sk_buff *sskb;
-
- BUG_ON(skb->fclone != SKB_FCLONE_SCRATCH);
- BUG_ON(!sctl);
- BUG_ON(sctl->owner != skb);
- if (skb_queue_empty(&sctl->scr_skbs))
- return NULL;
-
- sskb = __skb_dequeue(&sctl->scr_skbs);
-
- /*
- * Mark us as a scratch skb, so we get properly kfree-ed
- */
- sskb->fclone = SKB_FCLONE_SCRATCH;
-
- return sskb;
-}
+extern struct sk_buff *alloc_fscratch_skb(struct sk_buff *skb);
#endif /* __KERNEL__ */
#endif /* _LINUX_SKBUFF_H */
diff --git a/include/trace/events/napi.h b/include/trace/events/napi.h
index 8fe1e93..5af5675 100644
--- a/include/trace/events/napi.h
+++ b/include/trace/events/napi.h
@@ -7,6 +7,7 @@
#include <linux/netdevice.h>
#include <linux/tracepoint.h>
#include <linux/ftrace.h>
+#include <linux/kernel_stat.h>
#define NO_DEV "(no_device)"
@@ -30,6 +31,46 @@ TRACE_EVENT(napi_poll,
__entry->napi, __get_str(dev_name))
);
+TRACE_EVENT(napi_schedule,
+
+ TP_PROTO(struct napi_struct *napi),
+
+ TP_ARGS(napi),
+
+ TP_STRUCT__entry(
+ __field( struct napi_struct *, napi)
+ __string( dev_name, napi->dev ? napi->dev->name : NO_DEV)
+ ),
+
+ TP_fast_assign(
+ __entry->napi = napi;
+ __assign_str(dev_name, napi->dev ? napi->dev->name : NO_DEV);
+ ),
+
+ TP_printk("napi schedule on napi struct %p for device %s",
+ __entry->napi, __get_str(dev_name))
+);
+
+TRACE_EVENT(napi_complete,
+
+ TP_PROTO(struct napi_struct *napi),
+
+ TP_ARGS(napi),
+
+ TP_STRUCT__entry(
+ __field( struct napi_struct *, napi)
+ __string( dev_name, napi->dev ? napi->dev->name : NO_DEV)
+ ),
+
+ TP_fast_assign(
+ __entry->napi = napi;
+ __assign_str(dev_name, napi->dev ? napi->dev->name : NO_DEV);
+ ),
+
+ TP_printk("napi complete on napi struct %p for device %s",
+ __entry->napi, __get_str(dev_name))
+);
+
#undef NO_DEV
#endif /* _TRACE_NAPI_H_ */
diff --git a/include/trace/events/skb.h b/include/trace/events/skb.h
index 0c68ae22..3b83438 100644
--- a/include/trace/events/skb.h
+++ b/include/trace/events/skb.h
@@ -69,6 +69,47 @@ TRACE_EVENT(skb_copy_datagram_iovec,
TP_printk("skbaddr=%p len=%d", __entry->skbaddr, __entry->len)
);
+TRACE_EVENT(skb_make_fclone_scratch,
+
+ TP_PROTO(struct sk_buff *skb, int count),
+
+ TP_ARGS(skb, count),
+
+ TP_STRUCT__entry(
+ __field( const struct sk_buff *, skb)
+ __string( name, skb->dev ? skb->dev->name : "unknown")
+ __field( int, fccount)
+ ),
+
+ TP_fast_assign(
+ __entry->skb = skb;
+ __assign_str(name, skb->dev ? skb->dev->name : "unknown");
+ __entry->fccount = count;
+ ),
+
+ TP_printk("skb= %p, dev=%s, count=%d", __entry->skb,
+ __get_str(name), __entry->fccount)
+);
+
+TRACE_EVENT(alloc_fscratch_skb,
+
+ TP_PROTO(const struct sk_buff *parent, const struct sk_buff *child),
+
+ TP_ARGS(parent, child),
+
+ TP_STRUCT__entry(
+ __field( const struct sk_buff *, parent)
+ __field( const struct sk_buff *, child)
+ ),
+
+ TP_fast_assign(
+ __entry->parent = parent;
+ __entry->child = child;
+ ),
+
+ TP_printk("parent=%p, child=%p", __entry->parent, __entry->child)
+);
+
#endif /* _TRACE_SKB_H */
/* This part must be outside protection */
diff --git a/net/core/dev.c b/net/core/dev.c
index b7ba81a..1af4c02 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2579,6 +2579,7 @@ int weight_p __read_mostly = 64; /* old backlog weight */
static inline void ____napi_schedule(struct softnet_data *sd,
struct napi_struct *napi)
{
+ trace_napi_schedule(napi);
list_add_tail(&napi->poll_list, &sd->poll_list);
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
}
@@ -3829,6 +3830,7 @@ void __napi_complete(struct napi_struct *n)
BUG_ON(!test_bit(NAPI_STATE_SCHED, &n->state));
BUG_ON(n->gro_list);
+ trace_napi_complete(n);
list_del(&n->poll_list);
smp_mb__before_clear_bit();
clear_bit(NAPI_STATE_SCHED, &n->state);
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 6fdf1a7..0347446 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -3221,6 +3221,30 @@ void __skb_warn_lro_forwarding(const struct sk_buff *skb)
}
EXPORT_SYMBOL(__skb_warn_lro_forwarding);
+/*
+ * Allocates an skb out of our scratch space
+ */
+struct sk_buff *alloc_fscratch_skb(struct sk_buff *skb)
+{
+ struct skb_scr_control *sctl = skb_get_scratch_control(skb);
+ struct sk_buff *sskb = NULL;
+
+ BUG_ON(skb->fclone != SKB_FCLONE_SCRATCH);
+ BUG_ON(!sctl);
+ BUG_ON(sctl->owner != skb);
+
+ sskb = __skb_dequeue(&sctl->scr_skbs);
+
+ /*
+ * Mark us as a scratch skb, so we get properly kfree-ed
+ */
+ sskb->fclone = SKB_FCLONE_SCRATCH;
+
+ trace_alloc_fscratch_skb(skb, sskb);
+ return sskb;
+}
+EXPORT_SYMBOL(alloc_fscratch_skb);
+
unsigned int skb_make_fclone_scratch(struct sk_buff *skb)
{
size_t bufsz, totsz, scrsz, tmpsz;
@@ -3228,15 +3252,16 @@ unsigned int skb_make_fclone_scratch(struct sk_buff *skb)
struct sk_buff *scr_skb;
struct skb_shared_info *old_info;
bool format_tail = false;
+ int fclone_count = 0;
if (skb_shared(skb))
- return 0;
+ goto out;
/*
* Cant do scratch space on fcloned skbs
*/
if (skb->fclone)
- return 0;
+ goto out;
if ((skb->end - skb->tail) > sizeof(struct skb_shared_info)) {
old_info = skb_shinfo(skb);
@@ -3257,7 +3282,7 @@ unsigned int skb_make_fclone_scratch(struct sk_buff *skb)
sizeof(struct skb_shared_info);
if ((bufsz + sizeof(struct skb_scr_control)) >= totsz)
- return 0;
+ goto out;
/*
* And this is the leftover area, minus sizeof(int) to store the number
@@ -3278,6 +3303,10 @@ unsigned int skb_make_fclone_scratch(struct sk_buff *skb)
skb->fclone = SKB_FCLONE_SCRATCH;
- return skb_queue_len(&sctl->scr_skbs);
+ fclone_count = skb_queue_len(&sctl->scr_skbs);
+out:
+ trace_skb_make_fclone_scratch(skb, fclone_count);
+ return fclone_count;
}
+EXPORT_SYMBOL(skb_make_fclone_scratch);
--
1.7.6.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox