* Re: [PATCH]: tipc: Fix oops on send prior to entering networked mode
From: Neil Horman @ 2010-02-23 1:11 UTC (permalink / raw)
To: Stephens, Allan; +Cc: netdev, per.liden, jon.maloy, tipc-discussion, davem
In-Reply-To: <29C1DC0826876849BDD9F1C67ABA29430705EF62@ala-mail09.corp.ad.wrs.com>
On Mon, Feb 22, 2010 at 02:44:48PM -0800, Stephens, Allan wrote:
> Hi Neil:
>
> Good work on spotting this bug, and in tracking down the cause. I took
> a look at your patch, but there are a couple of problems I can see with
> the approach you've taken to fix things:
>
Thanks. Like I mentioned in my initial post, my approach only had minimal
testing, and I'm not supprised that my approach had some rough edges.
> 1) The check you've added to send_msg() in net/tipc/socket.c will help
> prevent things from blowing up if the message sender is using an AF_MIPC
> socket from user space, but it won't help prevent a similar oops if an
> "application" uses TIPC's native API to send a message directly from
> kernel space.
>
> 2) The other change you made to defer setting tipc_mode to TIPC_NET_MODE
> will cause problems if TIPC has to bail out during tipc_net_start()
> because of problems. Specifically, the ensuing call to tipc_net_stop()
> won't get a chance to clean up any partial initialization that got done
> prior to the initialization problem, which could result in memory leaks.
>
> Fortunately, I think there's a relatively easy solution. Since TIPC
> always needs to call tipc_node_select() in order to send an off-node
> message, you should be able to add the necessary error checking there.
> I'm thinking of something along the lines of:
>
That seems like it might be a problem in and of itself. If the startup/shutdown
code relies on the state of the implementation, perhaps that worth cleaning up
so as to avoid a race condition.
> static inline struct tipc_node *tipc_node_select(u32 addr, u32 selector)
> {
> if (likely(in_own_cluster(addr)))
> return tipc_local_nodes ?
> tipc_local_nodes[tipc_node(addr)] : NULL;
> return tipc_net->zones ? tipc_node_select_next_hop(addr,
> selector) : NULL;
> }
>
> Please give this a try and let us know how things go.
>
I'm happy to give this a try, but I'm a bit concerned by this approach. It
certainly seems like it will solve the problem at hand, but it doesn't seem to
address the underlying cause, which is that you can execute code paths which the
state of the implementation doesn't/shouldn't allow. In other words, this solve
the immediate problem, but it still allows someone to try send data via tipc
before tipc is ready to send data. It would be nice if we could deal with the
larger problem.
I'll let you know how the above patch goes.
Regards
Neil
> Regards,
> Al
>
> > -----Original Message-----
> > From: Neil Horman [mailto:nhorman@tuxdriver.com]
> > Sent: Friday, February 19, 2010 2:41 PM
> > To: netdev@vger.kernel.org
> > Cc: per.liden@ericsson.com; jon.maloy@ericsson.com; Stephens,
> > Allan; tipc-discussion@lists.sourceforge.net;
> > davem@davemloft.net; nhorman@tuxdriver.com
> > Subject: [PATCH]: tipc: Fix oops on send prior to entering
> > networked mode
> >
> > Fix TIPC to disallow sending to remote addresses prior to
> > entering NET_MODE
> >
> > user programs can oops the kernel by sending datagrams via
> > AF_TIPC prior to entering networked mode. The following
> > backtrace has been observed:
> >
> > ID: 13459 TASK: ffff810014640040 CPU: 0 COMMAND: "tipc-client"
> > #0 [ffff81002d9a5810] crash_kexec at ffffffff800ac5b9
> > #1 [ffff81002d9a58d0] __die at ffffffff80065127
> > #2 [ffff81002d9a5910] do_page_fault at ffffffff80066da7
> > #3 [ffff81002d9a5a00] error_exit at ffffffff8005dde9
> > [exception RIP: tipc_node_select_next_hop+90]
> > RIP: ffffffff8869d3c3 RSP: ffff81002d9a5ab8 RFLAGS: 00010202
> > RAX: 0000000000000001 RBX: 0000000000000001 RCX: 0000000000000001
> > RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000001001001
> > RBP: 0000000001001001 R8: 0074736575716552 R9: 0000000000000000
> > R10: ffff81003fbd0680 R11: 00000000000000c8 R12: 0000000000000008
> > R13: 0000000000000001 R14: 0000000000000001 R15: ffff810015c6ca00
> > ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
> > #4 [ffff81002d9a5ab0] tipc_node_select_next_hop at ffffffff8869d3b1
> > #5 [ffff81002d9a5ae0] tipc_link_send_sections_fast at ffffffff88698558
> > #6 [ffff81002d9a5be0] tipc_forward2port at ffffffff8869eb1d
> > #7 [ffff81002d9a5c10] tipc_send2port at ffffffff8869eb79
> > #8 [ffff81002d9a5c30] send_msg at ffffffff886a1d0b
> > #9 [ffff81002d9a5cb0] sock_sendmsg at ffffffff80055261
> > RIP: 0000003cbd8d49a3 RSP: 00007fffc84e0be8 RFLAGS: 00010206
> > RAX: 000000000000002c RBX: ffffffff8005d116 RCX: 0000000000000000
> > RDX: 0000000000000008 RSI: 00007fffc84e0c00 RDI: 0000000000000003
> > RBP: 0000000000000000 R8: 00007fffc84e0c10 R9: 0000000000000010
> > R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
> > R13: 00007fffc84e0d10 R14: 0000000000000000 R15: 00007fffc84e0c30
> > ORIG_RAX: 000000000000002c CS: 0033 SS: 002b
> >
> > What happens is that, when the tipc module in inserted it
> > enters a standalone node mode in which communication to its
> > own address is allowed <0.0.0> but not to other addresses,
> > since the appropriate data structures have not been allocated
> > yet (specifically the tipc_net pointer). There is nothing
> > stopping a client from trying to send such a message however,
> > and if that happens, we attempt to dereference tipc_net.zones
> > while the pointer is still NULL, and explode. The fix is to
> > add a check at the start of the send_msg path to ensure that
> > we've allocated the tipc_net pointers and entered networked
> > mode prior to allowing a send to any destination other than
> > our loopback address.
> >
> > This patch has received minimal testing, but fixes the issue.
> > Through reviews are appreciated.
> >
> > Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> >
> > CC: Per Liden <per.liden@ericsson.com>
> > CC: Jon Maloy <jon.maloy@ericsson.com>
> > CC: Allan Stephens <allan.stephens@windriver.com>
> > CC: David S. Miller <davem@davemloft.net>
> > CC: Neil Horman <nhorman@tuxdriver.com>
> > CC: tipc-discussion@lists.sourceforge.net
> >
> >
> > net.c | 2 +-
> > socket.c | 4 ++++
> > 2 files changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/tipc/net.c b/net/tipc/net.c index
> > 7906608..512b33c 100644
> > --- a/net/tipc/net.c
> > +++ b/net/tipc/net.c
> > @@ -278,7 +278,6 @@ int tipc_net_start(u32 addr)
> > tipc_cfg_stop();
> >
> > tipc_own_addr = addr;
> > - tipc_mode = TIPC_NET_MODE;
> > tipc_named_reinit();
> > tipc_port_reinit();
> >
> > @@ -289,6 +288,7 @@ int tipc_net_start(u32 addr)
> > return res;
> > }
> >
> > + tipc_mode = TIPC_NET_MODE;
> > tipc_k_signal((Handler)tipc_subscr_start, 0);
> > tipc_k_signal((Handler)tipc_cfg_init, 0);
> >
> > diff --git a/net/tipc/socket.c b/net/tipc/socket.c index
> > 1ea64f0..45229fd 100644
> > --- a/net/tipc/socket.c
> > +++ b/net/tipc/socket.c
> > @@ -526,6 +526,10 @@ static int send_msg(struct kiocb *iocb,
> > struct socket *sock,
> > if (iocb)
> > lock_sock(sk);
> >
> > + if ((tipc_mode != TIPC_NET_MODE) &&
> > + (dest->addr.name.domain != tipc_own_addr))
> > + return -EHOSTUNREACH;
> > +
> > needs_conn = (sock->state != SS_READY);
> > if (unlikely(needs_conn)) {
> > if (sock->state == SS_LISTENING) {
> >
>
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000: convert to use netdev_for_each_mc_addr
From: Jesse Brandeburg @ 2010-02-23 0:54 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem
In-Reply-To: <20100222191044.GC4141@psychotron.redhat.com>
On Mon, Feb 22, 2010 at 11:10 AM, Jiri Pirko <jpirko@redhat.com> wrote:
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
> ---
> drivers/net/e1000/e1000_main.c | 37 +++++++++++++++++--------------------
> 1 files changed, 17 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c
> index 3b14dd7..c99f95c 100644
> --- a/drivers/net/e1000/e1000_main.c
> +++ b/drivers/net/e1000/e1000_main.c
> @@ -2161,29 +2161,26 @@ static void e1000_set_rx_mode(struct net_device *netdev)
>
> WARN_ON(i == rar_entries);
>
> - mc_ptr = netdev->mc_list;
> -
> - for (; i < rar_entries; i++) {
> - if (mc_ptr) {
> - e1000_rar_set(hw, mc_ptr->da_addr, i);
> - mc_ptr = mc_ptr->next;
> - } else {
> - E1000_WRITE_REG_ARRAY(hw, RA, i << 1, 0);
> - E1000_WRITE_FLUSH();
> - E1000_WRITE_REG_ARRAY(hw, RA, (i << 1) + 1, 0);
> - E1000_WRITE_FLUSH();
> + netdev_for_each_mc_addr(mc_ptr, netdev) {
> + if (i == rar_entries) {
> + /* load any remaining addresses into the hash table */
> + u32 hash_reg, hash_bit, mta;
> + hash_value = e1000_hash_mc_addr(hw, mc_ptr->da_addr);
> + hash_reg = (hash_value >> 5) & 0x7F;
> + hash_bit = hash_value & 0x1F;
> + mta = (1 << hash_bit);
> + mcarray[hash_reg] |= mta;
> + }
> + else {
nit - else should be in the same line like "} else {"
> + e1000_rar_set(hw, mc_ptr->da_addr, i++);
> }
> }
>
> - /* load any remaining addresses into the hash table */
> -
> - for (; mc_ptr; mc_ptr = mc_ptr->next) {
> - u32 hash_reg, hash_bit, mta;
> - hash_value = e1000_hash_mc_addr(hw, mc_ptr->da_addr);
> - hash_reg = (hash_value >> 5) & 0x7F;
> - hash_bit = hash_value & 0x1F;
> - mta = (1 << hash_bit);
> - mcarray[hash_reg] |= mta;
> + for (; i < rar_entries; i++) {
> + E1000_WRITE_REG_ARRAY(hw, RA, i << 1, 0);
> + E1000_WRITE_FLUSH();
> + E1000_WRITE_REG_ARRAY(hw, RA, (i << 1) + 1, 0);
> + E1000_WRITE_FLUSH();
> }
>
> /* write the hash table completely, write from bottom to avoid
otherwise seems okay. Thanks for your work on cleaning this stuff,
we'll be testing it as part of the net next testing already going on.
^ permalink raw reply
* Re: [PATCH V2 net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Miller @ 2010-02-23 0:45 UTC (permalink / raw)
To: dave; +Cc: joe, netdev
In-Reply-To: <1266884549.2930.57.camel@obelisk.thedillows.org>
From: David Dillow <dave@thedillows.org>
Date: Mon, 22 Feb 2010 19:22:29 -0500
> On Mon, 2010-02-22 at 15:43 -0800, David Miller wrote:
>> Man you are picky :-/ Are you a control freak?
>
> Sometimes, yes. Aren't you? ;)
Yes, I certainly can be :-)
> It doesn't matter for this driver, with its minimal user base. And it
> may not be worth the effort for the transformation series. But I think
> he's going to move into much larger projects and I believe it would be a
> good habit to develop.
Agreed.
^ permalink raw reply
* Re: NETIF_F_HIGHDMA misuse in networking drivers?
From: Robert Hancock @ 2010-02-23 0:28 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20100222.155357.235673585.davem@davemloft.net>
On Mon, Feb 22, 2010 at 5:53 PM, David Miller <davem@davemloft.net> wrote:
> From: Robert Hancock <hancockrwd@gmail.com>
> Date: Sat, 20 Feb 2010 12:29:14 -0600
>
>> Was just part of a discussion in another thread talking about 64-bit
>> DMA support issues where NETIF_F_HIGHDMA came up. I was originally
>> under the impression that this flag indicated the device supported
>> 64-bit DMA addressing. However, from looking at the code that checks
>> for it (and, well, the actual comment for the flag) it really means
>> "can access highmem" which has nothing to do with 64-bit at all. And
>> if there's no highmem (like on x86_64) it has no effect at all.
>
> I think it's trying to do two things, and doing only one of them
> well :-)
>
> It's trying to keep drivers from receiving highmem pages if they are
> not able to access them properly. F.e. imagine a driver that copies
> data out of the packet assuming that page_address() is always valid on
> the SKB pages.
Yeah, it appears this is the only reason not to set the HIGHDMA flag.
Of course, given that relatively few drivers should need to do this (I
would think only emulated/virtual adapters, or really old/crappy
hardware with no bus-master support) ideally it would be better if
only those drivers needed to do something special (i.e. a NOHIGHDMA
flag or something) rather than making all the normal ones do it..
>
> It's also trying to use this to prevent physical addresses beyond 4GB
> from reaching the driver, which as you note is not implemented
> precisely here.
If by "precisely" you mean "at all, on many architectures".. on a
non-highmem arch, setting or not setting HIGHDMA has no effect on
anything, including whether >4GB addresses will be received by the
driver or not. Only the device DMA mask (presumably) does. Therefore,
conditionally setting HIGHDMA based on what DMA mask the driver has
been able to set is almost certainly a bug.
>
> Without knowing something about how the driver "DMAs" packet data we
> can't really do an accurate test here. Maybe the driver directly DMAs
> using physical addressing (an ASIC inside of a CPU, for example,
> drivers/net/niu.c has a case of this).
>
> Maybe the platform uses an IOMMU with 32-bit virtual addressing, so
> any physical address is fine even if the card only supports 32-bit
> addressing (basically any PCI coard on sparc64 is an example of this).
>
> And finally maybe the card supports 64-bit DMA addressing so anything
> works on any platform.
The DMA mask facility already should address all of these cases
AFAICS, so there should be no need for any extra handling here..
>
> How to test all of these possible cases precisely that at this spot in
> the transmit path is the question at hand. To be honest I consider
> the current hack "good enough" :-)
Well, as I see it there are two big problems with the current state:
-As there are a lot of bad examples in the tree of this flag being set
based on irrelevant criteria, such mistakes will propagate to new
drivers in cargo-cult fashion. (Looking at some of the existing
examples, it seems like has already occurred for a lot of them.)
-Failing to set the HIGHDMA flag when it should be is likely to impact
performance on highmem architectures by causing unnecessary packet
copying, and potentially using up more precious low memory.
^ permalink raw reply
* Re: [PATCH V2 net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Dillow @ 2010-02-23 0:22 UTC (permalink / raw)
To: David Miller; +Cc: joe, netdev
In-Reply-To: <20100222.154306.114398657.davem@davemloft.net>
On Mon, 2010-02-22 at 15:43 -0800, David Miller wrote:
> Man you are picky :-/ Are you a control freak?
Sometimes, yes. Aren't you? ;)
> You can't even let Joe write his commit comments consistently with the
> ones he is using for all the other similar network driver transmations?
That's fine, I was offering a suggestion on improving the comments that
I felt were in line with messages in the past from you, Ingo, Linus, and
others regarding the quality of commit messages.
> What makes doing the same exact transformations to your favorite
> driver so special that it deserves a specially constructed commit
> message?
I expect Joe to continue to submit high quality patches, and to grow
into larger roles than the already important one he is doing now. He's
doing good work, and he's been easy to work with. I'd just like to see
the commit messages improve beyond giving a bullet list of changes one
could get from a quick scan of the patch -- adding the context and why
of the changes rather than a mechanical listing.
It doesn't matter for this driver, with its minimal user base. And it
may not be worth the effort for the transformation series. But I think
he's going to move into much larger projects and I believe it would be a
good habit to develop.
^ permalink raw reply
* Re: [net-next-2.6 PATCH 0/7] xfrm by MARK
From: David Miller @ 2010-02-23 0:21 UTC (permalink / raw)
To: hadi; +Cc: timo.teras, kaber, herbert, netdev
In-Reply-To: <1266874380-29593-1-git-send-email-hadi@cyberus.ca>
From: jamal <hadi@cyberus.ca>
Date: Mon, 22 Feb 2010 16:32:53 -0500
> This patchset implements manipulation of ipsec tables with the
> "mark" tag. You can config the SAD and SPD from user space
> with a specified mark.
Looks good, all applied to net-next-2.6, thanks!
^ permalink raw reply
* Re: NETIF_F_HIGHDMA misuse in networking drivers?
From: David Miller @ 2010-02-22 23:53 UTC (permalink / raw)
To: hancockrwd; +Cc: linux-kernel, netdev
In-Reply-To: <4B8029FA.2000404@gmail.com>
From: Robert Hancock <hancockrwd@gmail.com>
Date: Sat, 20 Feb 2010 12:29:14 -0600
> Was just part of a discussion in another thread talking about 64-bit
> DMA support issues where NETIF_F_HIGHDMA came up. I was originally
> under the impression that this flag indicated the device supported
> 64-bit DMA addressing. However, from looking at the code that checks
> for it (and, well, the actual comment for the flag) it really means
> "can access highmem" which has nothing to do with 64-bit at all. And
> if there's no highmem (like on x86_64) it has no effect at all.
I think it's trying to do two things, and doing only one of them
well :-)
It's trying to keep drivers from receiving highmem pages if they are
not able to access them properly. F.e. imagine a driver that copies
data out of the packet assuming that page_address() is always valid on
the SKB pages.
It's also trying to use this to prevent physical addresses beyond 4GB
from reaching the driver, which as you note is not implemented
precisely here.
Without knowing something about how the driver "DMAs" packet data we
can't really do an accurate test here. Maybe the driver directly DMAs
using physical addressing (an ASIC inside of a CPU, for example,
drivers/net/niu.c has a case of this).
Maybe the platform uses an IOMMU with 32-bit virtual addressing, so
any physical address is fine even if the card only supports 32-bit
addressing (basically any PCI coard on sparc64 is an example of this).
And finally maybe the card supports 64-bit DMA addressing so anything
works on any platform.
How to test all of these possible cases precisely that at this spot in
the transmit path is the question at hand. To be honest I consider
the current hack "good enough" :-)
^ permalink raw reply
* Re: [net-next-2.6 PATCH] pci: add support for 82576NS serdes to existing SR-IOV quirk
From: David Miller @ 2010-02-22 23:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: jbarnes, netdev, linux-pci, gospo, alexander.h.duyck
In-Reply-To: <20100220035744.31323.86894.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 19 Feb 2010 19:57:46 -0800
> From: Alexander Duyck <alexander.h.duyck@intel.com>
>
> This patch adds support for the 82576NS Serdes adapter to the existing pci
> quirk for 82576 parts.
>
> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] ixgbe: prevent speculative processing of descriptors before ready
From: David Miller @ 2010-02-22 23:49 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, miltonm, anton, donald.c.skidmore
In-Reply-To: <20100220034419.31030.5083.stgit@localhost.localdomain>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 19 Feb 2010 19:44:42 -0800
> From: Milton Miller <miltonm@bga.com>
>
> The PowerPC architecture does not require loads to independent bytes to be
> ordered without adding an explicit barrier.
>
> In ixgbe_clean_rx_irq we load the status bit then load the packet data.
> With packet split disabled if these loads go out of order we get a
> stale packet, but we will notice the bad sequence numbers and drop it.
>
> The problem occurs with packet split enabled where the TCP/IP header and data
> are in different descriptors. If the reads go out of order we may have data
> that doesn't match the TCP/IP header. Since we use hardware checksumming this
> bad data is never verified and it makes it all the way to the application.
>
> This bug was found during stress testing and adding this barrier has been shown
> to fix it.
>
> Signed-off-by: Milton Miller <miltonm@bga.com>
> Signed-off-by: Anton Blanchard <anton@samba.org>
> Acked-by: Don Skidmore <donald.c.skidmore@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: convert multiple drivers to use netdev_for_each_mc_addr, part3
From: David Miller @ 2010-02-22 23:48 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100220101356.GA10116@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Sat, 20 Feb 2010 11:13:58 +0100
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH] isdn: fix a few Kconfig imperfections
From: David Miller @ 2010-02-22 23:48 UTC (permalink / raw)
To: tilman; +Cc: isdn, keil, isdn4linux, i4ldeveloper, netdev, linux-kernel
In-Reply-To: <20100222210938.75A3B4011D@xenon.ts.pxnet.com>
From: Tilman Schmidt <tilman@imap.cc>
Date: Mon, 22 Feb 2010 22:09:38 +0100 (CET)
> 1. Rewrite the outdated help texts for config options ISDN and ISDN_CAPI.
> 2. The MISDN config option appeared between ISDN_I4L and the I4L hardware
> driver options; move it to a less irritating place.
> 3. HYSDN is not in fact an I4L driver, and needn't depend on ISDN_I4L, so
> move it from the I4L section to the general section.
> 4. ISDN_HDLC is now also used by drivers outside I4L. Move it from the
> I4L section to the general section, too.
>
> Signed-off-by: Tilman Schmidt <tilman@imap.cc>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net/arm: convert to use netdev_for_each_mc_addr
From: David Miller @ 2010-02-22 23:48 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100220090626.GA2607@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Sat, 20 Feb 2010 10:06:27 +0100
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] net: convert multiple drivers to use netdev_for_each_mc_addr, part4
From: David Miller @ 2010-02-22 23:48 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100222192225.GD4141@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Mon, 22 Feb 2010 20:22:26 +0100
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [net-next-2.6 PATCH] e1000: convert to use netdev_for_each_mc_addr
From: David Miller @ 2010-02-22 23:47 UTC (permalink / raw)
To: jpirko; +Cc: netdev
In-Reply-To: <20100222191044.GC4141@psychotron.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Mon, 22 Feb 2010 20:10:44 +0100
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] can:ti_hecc: Add pm hook-up
From: David Miller @ 2010-02-22 23:47 UTC (permalink / raw)
To: srk-l0cyMroinI0
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, krbaalaaji-l0cyMroinI0
In-Reply-To: <1266845736-7161-1-git-send-email-srk-l0cyMroinI0@public.gmane.org>
From: Sriramakrishnan <srk-l0cyMroinI0@public.gmane.org>
Date: Mon, 22 Feb 2010 19:05:36 +0530
> Added the suspend and resume implementation in the HECC (CAN)
> driver.
>
> Signed-off-by: K R Baalaaji <krbaalaaji-l0cyMroinI0@public.gmane.org>
> Signed-off-by: Sriramakrishnan <srk-l0cyMroinI0@public.gmane.org>
> Acked-by: Anant Gole <anantgole-l0cyMroinI0@public.gmane.org>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] can: ti hecc module : add platform specific initialization callback.
From: David Miller @ 2010-02-22 23:47 UTC (permalink / raw)
To: srk; +Cc: socketcan-core, netdev, anantgole
In-Reply-To: <1266845762-7809-1-git-send-email-srk@ti.com>
From: Sriramakrishnan <srk@ti.com>
Date: Mon, 22 Feb 2010 19:06:02 +0530
> CAN module on AM3517 requires programming of IO expander as part
> of init sequence - to enable CAN PHY. Added platform specific
> init callback to handle this.
>
> Signed-off-by: Sriramakrishnan <srk@ti.com>
> Acked-by: Anant Gole <anantgole@ti.com>
Please address Wolfgang's feedback comments.
Thanks.
^ permalink raw reply
* Re: [PATCH V2 net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Miller @ 2010-02-22 23:47 UTC (permalink / raw)
To: joe; +Cc: netdev, dave
In-Reply-To: <1266808127.10646.77.camel@Joe-Laptop.home>
From: Joe Perches <joe@perches.com>
Date: Sun, 21 Feb 2010 19:08:47 -0800
> David Dillow took my suggestions and improved on them.
> Here is this latest version.
>
> Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> Remove #define PFX
> Remove #define ERR_PFX
> Remove now unused member name from struct typhoon
> Use pr_<level>
> Use netdev_<level>
> Coalesce long formats
> Remove version information
>
> Signed-off-by: Joe Perches <joe@perches.com>
> Signed-off-by: David Dillow <dave@thedillows.org>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] ibmveth: Add suspend/resume support
From: David Miller @ 2010-02-22 23:46 UTC (permalink / raw)
To: brking; +Cc: netdev
In-Reply-To: <201002211647.o1LGlqh3023138@d01av01.pok.ibm.com>
From: Brian King <brking@linux.vnet.ibm.com>
Date: Sun, 21 Feb 2010 10:48:01 -0600
>
> Adds support for resuming from suspend for IBM virtual ethernet devices.
> We may have lost an interrupt over the suspend, so we just kick the
> interrupt handler to process anything that is outstanding.
>
> Signed-off-by: Brian King <brking@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] b44: use netdev_alloc_skb instead of dev_alloc_skb
From: David Miller @ 2010-02-22 23:46 UTC (permalink / raw)
To: hauke; +Cc: zambrano, netdev
In-Reply-To: <1266699326-1541-2-git-send-email-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sat, 20 Feb 2010 21:55:26 +0100
> The conversion in bf0dcbd929faf036f1a4f2918090344d0e249cf5 missed the
> new allocation in b44_rx.
> This patch was used in OpenWRT for a long time.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] b44: Set PHY address to NO_PHY if reset fails.
From: David Miller @ 2010-02-22 23:46 UTC (permalink / raw)
To: hauke; +Cc: zambrano, netdev
In-Reply-To: <1266699326-1541-1-git-send-email-hauke@hauke-m.de>
From: Hauke Mehrtens <hauke@hauke-m.de>
Date: Sat, 20 Feb 2010 21:55:25 +0100
> Do a PHY reset to test if there is an active phy and set the PHY address
> to B44_PHY_ADDR_NO_PHY in case of an not active phy. This is needed for
> the Linksys WRTSL54GS and Asus WL-500W.
> This patch was used in OpenWRT for a long time.
>
> Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] af_key: locking change
From: David Miller @ 2010-02-22 23:46 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100222175742.761539214@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 22 Feb 2010 09:57:19 -0800
> Get rid of custom locking that was using wait queue, lock, and atomic
> to basically build a queued mutex. Use RCU for read side.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] packet: convert socket list to RCU (v3)
From: David Miller @ 2010-02-22 23:46 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100222175742.681962290@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 22 Feb 2010 09:57:18 -0800
> Convert AF_PACKET to use RCU, eliminating one more reader/writer lock.
>
> There is no need for a real sk_del_node_init_rcu(), because sk_del_node_init
> is doing the equivalent thing to hlst_del_init_rcu already; but added
> some comments to try and make that obvious.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/3] seq_file: add RCU versions of new hlist/list iterators (v3)
From: David Miller @ 2010-02-22 23:46 UTC (permalink / raw)
To: shemminger; +Cc: netdev
In-Reply-To: <20100222175742.601785018@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Mon, 22 Feb 2010 09:57:17 -0800
> Many usages of seq_file use RCU protected lists, so non RCU
> iterators will not work safely.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] add net fec phy lan8700
From: David Miller @ 2010-02-22 23:45 UTC (permalink / raw)
To: carsten.behling; +Cc: netdev, kernel, dmalek
In-Reply-To: <D99582E5322435468A77E74BB0039E7B176E1F3BC4@SRV02.hamburg.garz-fricke.de>
From: Carsten Behling <carsten.behling@garz-fricke.com>
Date: Fri, 19 Feb 2010 15:21:35 +0100
> Signed-off-by: Carsten Behling <carsten.behling@garz-fricke.com>
Patch does not apply to net-next-2.6
^ permalink raw reply
* Re: [PATCH V2 net-next 14/15] drivers/net/typhoon.c: Use (pr|netdev)_<level> macro helpers
From: David Miller @ 2010-02-22 23:43 UTC (permalink / raw)
To: dave; +Cc: joe, netdev
In-Reply-To: <1266808995.2930.24.camel@obelisk.thedillows.org>
From: David Dillow <dave@thedillows.org>
Date: Sun, 21 Feb 2010 22:23:15 -0500
> On Sun, 2010-02-21 at 19:08 -0800, Joe Perches wrote:
>> David Dillow took my suggestions and improved on them.
>> Here is this latest version.
>>
>> Add #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
>> Remove #define PFX
>> Remove #define ERR_PFX
>> Remove now unused member name from struct typhoon
>> Use pr_<level>
>> Use netdev_<level>
>> Coalesce long formats
>> Remove version information
>>
>> Signed-off-by: Joe Perches <joe@perches.com>
>> Signed-off-by: David Dillow <dave@thedillows.org>
>
> Perhaps commit text as follows?
Man you are picky :-/ Are you a control freak?
You can't even let Joe write his commit comments consistently with the
ones he is using for all the other similar network driver transmations?
What makes doing the same exact transformations to your favorite
driver so special that it deserves a specially constructed commit
message?
Tell me.
Stuff like this drives me crazy.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox