* Re: [PATCH] Fix RCU warning in rt_cache_seq_show
From: Eric Dumazet @ 2011-08-12 7:23 UTC (permalink / raw)
To: paulmck; +Cc: Mark Rutland, netdev, David S. Miller, Gergely Kalman
In-Reply-To: <20110812023237.GA2372@linux.vnet.ibm.com>
Le jeudi 11 août 2011 à 19:32 -0700, Paul E. McKenney a écrit :
> On Thu, Aug 11, 2011 at 06:58:21PM +0200, Eric Dumazet wrote:
> > Le mercredi 10 août 2011 à 10:28 +0100, Mark Rutland a écrit :
> > > > -----Original Message-----
> > > > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > > > Sent: 09 August 2011 18:19
> > > > To: Mark Rutland; Paul E. McKenney
> > > > Cc: netdev@vger.kernel.org; David S. Miller; Gergely Kalman
> > > > Subject: Re: [PATCH] Fix RCU warning in rt_cache_seq_show
> > > >
> > > > Le mardi 09 août 2011 à 18:02 +0100, Mark Rutland a écrit :
> > > > > Commit f2c31e32 ("net: fix NULL dereferences in check_peer_redir()")
> > > > > added rcu protection to dst neighbour, and updated callsites for
> > > > > dst_{get,set}_neighbour. Unfortunately, it missed rt_cache_seq_show.
> > > > >
> > > > > This produces a warning on v3.1-rc1 (on a preemptible kernel, on an
> > > > > ARM Vexpress A9x4):
> > > > >
> > > > > ===================================================
> > > > > [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > > ---------------------------------------------------
> > > > > include/net/dst.h:91 invoked rcu_dereference_check() without
> > > > protection!
> > > > >
> > > > > other info that might help us debug this:
> > > > >
> > > > > rcu_scheduler_active = 1, debug_locks = 0
> > > > > 2 locks held by proc01/32159:
> > > > >
> > > > > stack backtrace:
> > > > > [<80014880>] (unwind_backtrace+0x0/0xf8) from [<802e5c78>]
> > > > (rt_cache_seq_show+0x18c/0x1c4)
> > > > > [<802e5c78>] (rt_cache_seq_show+0x18c/0x1c4) from [<800e0c5c>]
> > > > (seq_read+0x324/0x4a4)
> > > > > [<800e0c5c>] (seq_read+0x324/0x4a4) from [<8010786c>]
> > > > (proc_reg_read+0x70/0x94)
> > > > > [<8010786c>] (proc_reg_read+0x70/0x94) from [<800c0ba8>]
> > > > (vfs_read+0xb0/0x144)
> > > > > [<800c0ba8>] (vfs_read+0xb0/0x144) from [<800c0ea8>]
> > > > (sys_read+0x40/0x70)
> > > > > [<800c0ea8>] (sys_read+0x40/0x70) from [<8000e0c0>]
> > > > (ret_fast_syscall+0x0/0x3c)
> > > > >
> > > > > This patch adds calls to rcu_read_{lock,unlock} in rt_cache_seq_show,
> > > > > protecting the dereferenced variable, and clearing the warning.
> > > > >
> > > > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > > > Cc: David S. Miller <davem@davemloft.net>
> > > > > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > > > > Cc: Gergely Kalman <synapse@hippy.csoma.elte.hu>
> > > > > ---
> > > > > net/ipv4/route.c | 2 ++
> > > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > > > > index e3dec1c..6699ef7 100644
> > > > > --- a/net/ipv4/route.c
> > > > > +++ b/net/ipv4/route.c
> > > > > @@ -419,6 +419,7 @@ static int rt_cache_seq_show(struct seq_file
> > > > *seq, void *v)
> > > > > struct neighbour *n;
> > > > > int len;
> > > > >
> > > > > + rcu_read_lock();
> > > > > n = dst_get_neighbour(&r->dst);
> > > > > seq_printf(seq, "%s\t%08X\t%08X\t%8X\t%d\t%u\t%d\t"
> > > > > "%08X\t%d\t%u\t%u\t%02X\t%d\t%1d\t%08X%n",
> > > > > @@ -435,6 +436,7 @@ static int rt_cache_seq_show(struct seq_file
> > > > *seq, void *v)
> > > > > -1,
> > > > > (n && (n->nud_state & NUD_CONNECTED)) ? 1 : 0,
> > > > > r->rt_spec_dst, &len);
> > > > > + rcu_read_unlock();
> > > > >
> > > > > seq_printf(seq, "%*s\n", 127 - len, "");
> > > > > }
> > > >
> > > >
> > > > Hmm, I though rcu_read_lock_bh() (done by caller of this function) was
> > > > protecting us here.
> > >
> > > Aha. Being a bit trigger-happy, I'd had a quick look at the functions
> > > mentioned in the backtrace, and not looked at any possible inlining.
> > >
> > > This being my first real exposure to RCU, I wasn't aware of the *_bh
> > > variants. Looking at the documentation (Documentation/RCU/checklist.txt),
> > > I think the real problem is that we should be using rcu_dereference_bh in
> > > this case:
> > >
> > > > read-side critical sections are delimited by rcu_read_lock()
> > > > and rcu_read_unlock(), or by similar primitives such as
> > > > rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case
> > > > the matching rcu_dereference() primitive must be used in order
> > > > to keep lockdep happy, in this case, rcu_dereference_bh().
> >
> > Hmm.
> >
> > I do think dst_get_neighbour() should use rcu_dereference(), because
> > dst->_neighbour are freed by call_rcu().
> >
> > The question is : Is following construct [A] safe or not ?
> >
> > {
> > rcu_read_lock_bh();
> > /* BH are now disabled, and we are not allowed to sleep */
> > ...
> >
> > ptr = rcu_dereference();
>
> This should be:
>
> ptr = rcu_dereference_bh();
>
> As you say below. Never mind! ;-)
>
> > ...
> > rcu_read_unlock_bh();
> > }
> >
> >
> > I dont really understand why lockdep wants [B] instead :
> >
> > {
> > rcu_read_lock_bh();
> > ...
> >
> > {
> > rcu_read_lock();
> > ptr = rcu_dereference();
>
> Here you are protected by both RCU and RCU-bh, so you should be able
> to use either rcu_dereference() or rcu_dereference_bh(). A bit
> strange to use rcu_dereference_bh(), though. Except perhaps if a
> pointer to a function was passed in from the outer RCU-bh read-side
> critical section or something.
>
> > rcu_read_unlock();
> > }
> > ...
> > rcu_read_unlock_bh();
> > }
> >
> >
> >
> > However, I can understand the other way [C], this is really needed :
> >
> > {
> > rcu_read_lock();
> > ...
> >
> > {
> > rcu_read_lock_bh();
> > ptr = rcu_dereference_bh();
> > rcu_read_unlock_bh();
> > }
> > ...
> > rcu_read_unlock();
> > }
> >
> > I believe [A] should be allowed by lockdep.
>
> OK, I'll bite. Why?
>
Oh well, I assumed local_bh_disable() disables preemption.
It does since day-0
add_preempt_count(SOFTIRQ_DISABLE_OFFSET);
So following should be safe :
local_bh_disable();
{
ptr = rcu_dereference(...);
use(ptr);
}
local_bh_enable();
Maybe they are longterm plans to break this assumption, I dont know.
^ permalink raw reply
* iproute2: make arpd daemon write pid file on fork
From: Alex Dubov @ 2011-08-12 6:23 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20110811110029.023a5955@nehalam.ftrdhcpuser.net>
Current version of arpd included with iproute2-2.6.37 will fork
unconditionally on start-up (using daemon() library call). This causes
problems with distro start-up scripts, as PID of the started daemon can not be
reliably obtained, hampering orderly daemon shutdown process.
The included patch makes arpd write it's own pid file after fork, in a common
LSB fashion, so as to better inter-operate with start up scripts. Removal of
stale pid files is handled elsewhere.
--- misc/arpd.c.orig 2011-01-08 04:54:30.000000000 +1100
+++ misc/arpd.c 2011-08-12 16:04:51.098754397 +1000
@@ -41,6 +41,7 @@
DB *dbase;
char *dbname = "/var/lib/arpd/arpd.db";
+char *pidfname = "/var/run/arpd.pid";
int ifnum;
int *ifvec;
@@ -780,6 +781,17 @@
goto do_abort;
}
+ do {
+ FILE *fp = fopen(pidfname, "w");
+ if (fp) {
+ fprintf(fp, "%ld\n", (long)getpid());
+ fclose(fp);
+ } else {
+ perror("arpd: pid fopen");
+ goto do_abort;
+ }
+ } while (0);
+
openlog("arpd", LOG_PID | LOG_CONS, LOG_DAEMON);
catch_signal(SIGINT, sig_exit);
catch_signal(SIGTERM, sig_exit);
^ permalink raw reply
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: David Miller @ 2011-08-12 6:17 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <1313129511.4588.8.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 11 Aug 2011 23:11:50 -0700
> On Thu, 2011-08-11 at 23:05 -0700, David Miller wrote:
>> From: David Miller <davem@davemloft.net>
>> Date: Thu, 11 Aug 2011 23:00:17 -0700 (PDT)
>>
>> > From: Stephen Rothwell <sfr@canb.auug.org.au>
>> > Date: Fri, 12 Aug 2011 15:00:03 +1000
>> >
>> >> However, Dave, I now get these (powerpc ppc64defconfig build of just the
>> >> net tree):
>> >
>> > This should fix the cxgbi scsi problems, I'll work on the mlx4 ones
>> > next.
>>
>> And this one will fix the mlx4 infiniband problems, thanks Stephen.
>
> Are you working on the cxgb3/4 infiniband errors as well? The fix is
> similar to the fix below.
Those do not need a fix, their Kconfig fragments don't select things
they "depend" upon them so they are fine.
^ permalink raw reply
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: Jeff Kirsher @ 2011-08-12 6:11 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb.auug.org.au, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20110811.230552.837691497153518712.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1631 bytes --]
On Thu, 2011-08-11 at 23:05 -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Thu, 11 Aug 2011 23:00:17 -0700 (PDT)
>
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Fri, 12 Aug 2011 15:00:03 +1000
> >
> >> However, Dave, I now get these (powerpc ppc64defconfig build of just the
> >> net tree):
> >
> > This should fix the cxgbi scsi problems, I'll work on the mlx4 ones
> > next.
>
> And this one will fix the mlx4 infiniband problems, thanks Stephen.
Are you working on the cxgb3/4 infiniband errors as well? The fix is
similar to the fix below.
>
> --------------------
> From af3dcd2f449b7243a4c7b987125ffc40fad262f0 Mon Sep 17 00:00:00 2001
> From: "David S. Miller" <davem@davemloft.net>
> Date: Thu, 11 Aug 2011 23:05:05 -0700
> Subject: [PATCH] mlx4: Fix infiniband Kconfig dependencies.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> drivers/infiniband/hw/mlx4/Kconfig | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/infiniband/hw/mlx4/Kconfig b/drivers/infiniband/hw/mlx4/Kconfig
> index bd995b2..24ab11a 100644
> --- a/drivers/infiniband/hw/mlx4/Kconfig
> +++ b/drivers/infiniband/hw/mlx4/Kconfig
> @@ -1,6 +1,7 @@
> config MLX4_INFINIBAND
> tristate "Mellanox ConnectX HCA support"
> - depends on NETDEVICES && NETDEV_10000 && PCI
> + depends on NETDEVICES && ETHERNET && PCI
> + select NET_VENDOR_MELLANOX
> select MLX4_CORE
> ---help---
> This driver provides low-level InfiniBand support for
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: pull request: wireless 2011-08-11
From: David Miller @ 2011-08-12 6:10 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20110811182018.GF2566-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Thu, 11 Aug 2011 14:20:19 -0400
> This is a little batch of patches intended for 3.1.
>
> Included is a fix for a typo that incorrectly calibrated an ath9k phy,
> a fix for an skb leak in ath5k, a fix for a bus error on some Broadcom
> SoC using b43, a fix for a memory leak in wl1251, and another pair
> of calibration fixes for ath9k. A handful of device ID updates are
> included as well.
>
> Please let me know if there are problems!
Pulled, thanks John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [net-next] spider_net: fix compile issue introduced by driver move
From: Jeff Kirsher @ 2011-08-12 6:08 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb.auug.org.au, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20110811.230017.1431877798231142541.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]
On Thu, 2011-08-11 at 23:00 -0700, David Miller wrote:
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 12 Aug 2011 15:00:03 +1000
>
> > However, Dave, I now get these (powerpc ppc64defconfig build of just the
> > net tree):
>
> This should fix the cxgbi scsi problems, I'll work on the mlx4 ones
> next.
>
> Thanks.
Dang you beat me to it. I have the inifiniband fix as well in my patch.
>
> From b6a0e86efb79b8ee71cb2129f3ad384d7efc22e3 Mon Sep 17 00:00:00 2001
> From: "David S. Miller" <davem@davemloft.net>
> Date: Thu, 11 Aug 2011 22:59:31 -0700
> Subject: [PATCH] cxgbi: Fix scsi Kconfig dependencies.
>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: David S. Miller <davem@davemloft.net>
> ---
> drivers/scsi/cxgbi/cxgb3i/Kconfig | 3 ++-
> drivers/scsi/cxgbi/cxgb4i/Kconfig | 3 ++-
> 2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/cxgbi/cxgb3i/Kconfig b/drivers/scsi/cxgbi/cxgb3i/Kconfig
> index 11dff23..6bbc36f 100644
> --- a/drivers/scsi/cxgbi/cxgb3i/Kconfig
> +++ b/drivers/scsi/cxgbi/cxgb3i/Kconfig
> @@ -2,7 +2,8 @@ config SCSI_CXGB3_ISCSI
> tristate "Chelsio T3 iSCSI support"
> depends on PCI && INET
> select NETDEVICES
> - select NETDEV_10000
> + select ETHERNET
> + select NET_VENDOR_CHELSIO
> select CHELSIO_T3
> select SCSI_ISCSI_ATTRS
> ---help---
> diff --git a/drivers/scsi/cxgbi/cxgb4i/Kconfig b/drivers/scsi/cxgbi/cxgb4i/Kconfig
> index d5302c2..16b2c7d 100644
> --- a/drivers/scsi/cxgbi/cxgb4i/Kconfig
> +++ b/drivers/scsi/cxgbi/cxgb4i/Kconfig
> @@ -2,7 +2,8 @@ config SCSI_CXGB4_ISCSI
> tristate "Chelsio T4 iSCSI support"
> depends on PCI && INET
> select NETDEVICES
> - select NETDEV_10000
> + select ETHERNET
> + select NET_VENDOR_CHELSIO
> select CHELSIO_T4
> select SCSI_ISCSI_ATTRS
> ---help---
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] tcp: Use LIMIT_NETDEBUG in syn_flood_warning()
From: Eric Dumazet @ 2011-08-12 6:08 UTC (permalink / raw)
To: David Miller; +Cc: therbert, netdev
In-Reply-To: <1313044387.3066.8.camel@edumazet-laptop>
Le jeudi 11 août 2011 à 08:33 +0200, Eric Dumazet a écrit :
> Le mercredi 10 août 2011 à 23:13 -0700, David Miller a écrit :
> > From: Tom Herbert <therbert@google.com>
> > Date: Wed, 10 Aug 2011 22:38:02 -0700 (PDT)
> >
> > > Rather than printing the message to the log, use a mib counter to keep
> > > track of the count of occurences of syn cookies being used or syn
> > > being dropped when request queue is full.
> > >
> > > Rationale is these messages can fill up /var/log/messages on server
> > > which is simply under heavy load... I'm not sure how much more useful
> > > they would be in identifying a server DOS attack (compared to
> > > counters).
> > >
> > > Signed-off-by: Tom Herbert <therbert@google.com>
> >
> > Print the message once, and also do the counters.
> >
> > Say something like "Possible SYN flooding, see SNMP counters." or
> > similar.
> >
> > Because if people are grepping for that message in their logs, they
> > will now have a false sense of confidence seeing it not being there
> > any more.
>
> An alternative would be to guard the message by net_msg_warn
> (/proc/sys/net/core/warnings)
>
> LIMIT_NETDEBUG(KERN_INFO "TCP: Possible SYN flooding on port %d. %s.\n"
> ...)
Here is a patch implementing this.
We could add mib counters later in a second patch, inside
tcp_syn_flood_warning()
Thanks
[PATCH] tcp: Use LIMIT_NETDEBUG in syn_flood_warning()
LIMIT_NETDEBUG allows the admin to disable some warning messages :
echo 0 > /proc/sys/net/core/warnings
Use it to avoid filling syslog on busy servers.
Based on a previous patch from Tom Herbert
Factorize syn_flood_warning() IPv4/IPv6 implementations
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
CC: Tom Herbert <therbert@google.com>
---
include/net/tcp.h | 1 +
net/ipv4/tcp_ipv4.c | 14 ++++++--------
net/ipv6/tcp_ipv6.c | 17 +----------------
3 files changed, 8 insertions(+), 24 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index 149a415..964341c 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -460,6 +460,7 @@ extern int tcp_write_wakeup(struct sock *);
extern void tcp_send_fin(struct sock *sk);
extern void tcp_send_active_reset(struct sock *sk, gfp_t priority);
extern int tcp_send_synack(struct sock *);
+extern void tcp_syn_flood_warning(const struct sk_buff *skb, const char *proto);
extern void tcp_push_one(struct sock *, unsigned int mss_now);
extern void tcp_send_ack(struct sock *sk);
extern void tcp_send_delayed_ack(struct sock *sk);
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 1c12b8e..9e622da 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -808,20 +808,19 @@ static void tcp_v4_reqsk_destructor(struct request_sock *req)
kfree(inet_rsk(req)->opt);
}
-static void syn_flood_warning(const struct sk_buff *skb)
+void tcp_syn_flood_warning(const struct sk_buff *skb, const char *proto)
{
- const char *msg;
+ const char *msg = "Dropping request";
#ifdef CONFIG_SYN_COOKIES
if (sysctl_tcp_syncookies)
msg = "Sending cookies";
- else
#endif
- msg = "Dropping request";
- pr_info("TCP: Possible SYN flooding on port %d. %s.\n",
- ntohs(tcp_hdr(skb)->dest), msg);
+ LIMIT_NETDEBUG(KERN_INFO "%s: Possible SYN flooding on port %d. %s.\n",
+ proto, ntohs(tcp_hdr(skb)->dest), msg);
}
+EXPORT_SYMBOL(tcp_syn_flood_warning);
/*
* Save and compile IPv4 options into the request_sock if needed.
@@ -1250,8 +1249,7 @@ int tcp_v4_conn_request(struct sock *sk, struct sk_buff *skb)
* evidently real one.
*/
if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
- if (net_ratelimit())
- syn_flood_warning(skb);
+ tcp_syn_flood_warning(skb, "TCP");
#ifdef CONFIG_SYN_COOKIES
if (sysctl_tcp_syncookies) {
want_cookie = 1;
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index d1fb63f..a043386 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -531,20 +531,6 @@ static int tcp_v6_rtx_synack(struct sock *sk, struct request_sock *req,
return tcp_v6_send_synack(sk, req, rvp);
}
-static inline void syn_flood_warning(struct sk_buff *skb)
-{
-#ifdef CONFIG_SYN_COOKIES
- if (sysctl_tcp_syncookies)
- printk(KERN_INFO
- "TCPv6: Possible SYN flooding on port %d. "
- "Sending cookies.\n", ntohs(tcp_hdr(skb)->dest));
- else
-#endif
- printk(KERN_INFO
- "TCPv6: Possible SYN flooding on port %d. "
- "Dropping request.\n", ntohs(tcp_hdr(skb)->dest));
-}
-
static void tcp_v6_reqsk_destructor(struct request_sock *req)
{
kfree_skb(inet6_rsk(req)->pktopts);
@@ -1192,8 +1178,7 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb)
goto drop;
if (inet_csk_reqsk_queue_is_full(sk) && !isn) {
- if (net_ratelimit())
- syn_flood_warning(skb);
+ tcp_syn_flood_warning(skb, "TCPv6");
#ifdef CONFIG_SYN_COOKIES
if (sysctl_tcp_syncookies)
want_cookie = 1;
^ permalink raw reply related
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: David Miller @ 2011-08-12 6:06 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, sfr, linux-next, linux-kernel
In-Reply-To: <1313120000-12085-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 11 Aug 2011 20:33:20 -0700
> Both Spider net driver and Sun GEM driver use the sungem_phy.o object.
> This fix creates a Kconfig object for sungem_phy (like MDIO) so that
> both drivers require the SUNGEM_PHY object.
>
> This has been compile tested for the Sun GEM driver.
>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks Jeff.
^ permalink raw reply
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: David Miller @ 2011-08-12 6:05 UTC (permalink / raw)
To: sfr; +Cc: jeffrey.t.kirsher, netdev, linux-next, linux-kernel
In-Reply-To: <20110811.230017.1431877798231142541.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Thu, 11 Aug 2011 23:00:17 -0700 (PDT)
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 12 Aug 2011 15:00:03 +1000
>
>> However, Dave, I now get these (powerpc ppc64defconfig build of just the
>> net tree):
>
> This should fix the cxgbi scsi problems, I'll work on the mlx4 ones
> next.
And this one will fix the mlx4 infiniband problems, thanks Stephen.
--------------------
>From af3dcd2f449b7243a4c7b987125ffc40fad262f0 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Thu, 11 Aug 2011 23:05:05 -0700
Subject: [PATCH] mlx4: Fix infiniband Kconfig dependencies.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/infiniband/hw/mlx4/Kconfig | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/infiniband/hw/mlx4/Kconfig b/drivers/infiniband/hw/mlx4/Kconfig
index bd995b2..24ab11a 100644
--- a/drivers/infiniband/hw/mlx4/Kconfig
+++ b/drivers/infiniband/hw/mlx4/Kconfig
@@ -1,6 +1,7 @@
config MLX4_INFINIBAND
tristate "Mellanox ConnectX HCA support"
- depends on NETDEVICES && NETDEV_10000 && PCI
+ depends on NETDEVICES && ETHERNET && PCI
+ select NET_VENDOR_MELLANOX
select MLX4_CORE
---help---
This driver provides low-level InfiniBand support for
--
1.7.6
^ permalink raw reply related
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: David Miller @ 2011-08-12 6:00 UTC (permalink / raw)
To: sfr; +Cc: jeffrey.t.kirsher, netdev, linux-next, linux-kernel
In-Reply-To: <20110812150003.1e2ba71018bea040fc7649d7@canb.auug.org.au>
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Aug 2011 15:00:03 +1000
> However, Dave, I now get these (powerpc ppc64defconfig build of just the
> net tree):
This should fix the cxgbi scsi problems, I'll work on the mlx4 ones
next.
Thanks.
>From b6a0e86efb79b8ee71cb2129f3ad384d7efc22e3 Mon Sep 17 00:00:00 2001
From: "David S. Miller" <davem@davemloft.net>
Date: Thu, 11 Aug 2011 22:59:31 -0700
Subject: [PATCH] cxgbi: Fix scsi Kconfig dependencies.
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/scsi/cxgbi/cxgb3i/Kconfig | 3 ++-
drivers/scsi/cxgbi/cxgb4i/Kconfig | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/cxgbi/cxgb3i/Kconfig b/drivers/scsi/cxgbi/cxgb3i/Kconfig
index 11dff23..6bbc36f 100644
--- a/drivers/scsi/cxgbi/cxgb3i/Kconfig
+++ b/drivers/scsi/cxgbi/cxgb3i/Kconfig
@@ -2,7 +2,8 @@ config SCSI_CXGB3_ISCSI
tristate "Chelsio T3 iSCSI support"
depends on PCI && INET
select NETDEVICES
- select NETDEV_10000
+ select ETHERNET
+ select NET_VENDOR_CHELSIO
select CHELSIO_T3
select SCSI_ISCSI_ATTRS
---help---
diff --git a/drivers/scsi/cxgbi/cxgb4i/Kconfig b/drivers/scsi/cxgbi/cxgb4i/Kconfig
index d5302c2..16b2c7d 100644
--- a/drivers/scsi/cxgbi/cxgb4i/Kconfig
+++ b/drivers/scsi/cxgbi/cxgb4i/Kconfig
@@ -2,7 +2,8 @@ config SCSI_CXGB4_ISCSI
tristate "Chelsio T4 iSCSI support"
depends on PCI && INET
select NETDEVICES
- select NETDEV_10000
+ select ETHERNET
+ select NET_VENDOR_CHELSIO
select CHELSIO_T4
select SCSI_ISCSI_ATTRS
---help---
--
1.7.6
^ permalink raw reply related
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: David Miller @ 2011-08-12 5:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: sfr, netdev, linux-next, linux-kernel
In-Reply-To: <1313128038.4588.5.camel@jtkirshe-mobl>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 11 Aug 2011 22:47:17 -0700
> This is just an example of the change that would be needed to resolve
> defconfig issues. The below patch should resolve the cxgb3/4 errors. I
> have not made the necessary changes to resolve the mlx4 issues in this
> patch. I can generate those as well, if need be.
The dependencies should be such that the Kconfig system will work
out whatever is needed.
If the build breaks, the dependencies are wrong and we need to fix
them. Updating defconfigs should not be necessary to get a clean
build, it should "just work"
^ permalink raw reply
* Re: [PATCH] Fix RCU warning in rt_cache_seq_show
From: Paul E. McKenney @ 2011-08-12 2:32 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Mark Rutland, netdev, David S. Miller, Gergely Kalman
In-Reply-To: <1313081901.3261.25.camel@edumazet-HP-Compaq-6005-Pro-SFF-PC>
On Thu, Aug 11, 2011 at 06:58:21PM +0200, Eric Dumazet wrote:
> Le mercredi 10 août 2011 à 10:28 +0100, Mark Rutland a écrit :
> > > -----Original Message-----
> > > From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> > > Sent: 09 August 2011 18:19
> > > To: Mark Rutland; Paul E. McKenney
> > > Cc: netdev@vger.kernel.org; David S. Miller; Gergely Kalman
> > > Subject: Re: [PATCH] Fix RCU warning in rt_cache_seq_show
> > >
> > > Le mardi 09 août 2011 à 18:02 +0100, Mark Rutland a écrit :
> > > > Commit f2c31e32 ("net: fix NULL dereferences in check_peer_redir()")
> > > > added rcu protection to dst neighbour, and updated callsites for
> > > > dst_{get,set}_neighbour. Unfortunately, it missed rt_cache_seq_show.
> > > >
> > > > This produces a warning on v3.1-rc1 (on a preemptible kernel, on an
> > > > ARM Vexpress A9x4):
> > > >
> > > > ===================================================
> > > > [ INFO: suspicious rcu_dereference_check() usage. ]
> > > > ---------------------------------------------------
> > > > include/net/dst.h:91 invoked rcu_dereference_check() without
> > > protection!
> > > >
> > > > other info that might help us debug this:
> > > >
> > > > rcu_scheduler_active = 1, debug_locks = 0
> > > > 2 locks held by proc01/32159:
> > > >
> > > > stack backtrace:
> > > > [<80014880>] (unwind_backtrace+0x0/0xf8) from [<802e5c78>]
> > > (rt_cache_seq_show+0x18c/0x1c4)
> > > > [<802e5c78>] (rt_cache_seq_show+0x18c/0x1c4) from [<800e0c5c>]
> > > (seq_read+0x324/0x4a4)
> > > > [<800e0c5c>] (seq_read+0x324/0x4a4) from [<8010786c>]
> > > (proc_reg_read+0x70/0x94)
> > > > [<8010786c>] (proc_reg_read+0x70/0x94) from [<800c0ba8>]
> > > (vfs_read+0xb0/0x144)
> > > > [<800c0ba8>] (vfs_read+0xb0/0x144) from [<800c0ea8>]
> > > (sys_read+0x40/0x70)
> > > > [<800c0ea8>] (sys_read+0x40/0x70) from [<8000e0c0>]
> > > (ret_fast_syscall+0x0/0x3c)
> > > >
> > > > This patch adds calls to rcu_read_{lock,unlock} in rt_cache_seq_show,
> > > > protecting the dereferenced variable, and clearing the warning.
> > > >
> > > > Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> > > > Cc: David S. Miller <davem@davemloft.net>
> > > > Cc: Eric Dumazet <eric.dumazet@gmail.com>
> > > > Cc: Gergely Kalman <synapse@hippy.csoma.elte.hu>
> > > > ---
> > > > net/ipv4/route.c | 2 ++
> > > > 1 files changed, 2 insertions(+), 0 deletions(-)
> > > >
> > > > diff --git a/net/ipv4/route.c b/net/ipv4/route.c
> > > > index e3dec1c..6699ef7 100644
> > > > --- a/net/ipv4/route.c
> > > > +++ b/net/ipv4/route.c
> > > > @@ -419,6 +419,7 @@ static int rt_cache_seq_show(struct seq_file
> > > *seq, void *v)
> > > > struct neighbour *n;
> > > > int len;
> > > >
> > > > + rcu_read_lock();
> > > > n = dst_get_neighbour(&r->dst);
> > > > seq_printf(seq, "%s\t%08X\t%08X\t%8X\t%d\t%u\t%d\t"
> > > > "%08X\t%d\t%u\t%u\t%02X\t%d\t%1d\t%08X%n",
> > > > @@ -435,6 +436,7 @@ static int rt_cache_seq_show(struct seq_file
> > > *seq, void *v)
> > > > -1,
> > > > (n && (n->nud_state & NUD_CONNECTED)) ? 1 : 0,
> > > > r->rt_spec_dst, &len);
> > > > + rcu_read_unlock();
> > > >
> > > > seq_printf(seq, "%*s\n", 127 - len, "");
> > > > }
> > >
> > >
> > > Hmm, I though rcu_read_lock_bh() (done by caller of this function) was
> > > protecting us here.
> >
> > Aha. Being a bit trigger-happy, I'd had a quick look at the functions
> > mentioned in the backtrace, and not looked at any possible inlining.
> >
> > This being my first real exposure to RCU, I wasn't aware of the *_bh
> > variants. Looking at the documentation (Documentation/RCU/checklist.txt),
> > I think the real problem is that we should be using rcu_dereference_bh in
> > this case:
> >
> > > read-side critical sections are delimited by rcu_read_lock()
> > > and rcu_read_unlock(), or by similar primitives such as
> > > rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case
> > > the matching rcu_dereference() primitive must be used in order
> > > to keep lockdep happy, in this case, rcu_dereference_bh().
>
> Hmm.
>
> I do think dst_get_neighbour() should use rcu_dereference(), because
> dst->_neighbour are freed by call_rcu().
>
> The question is : Is following construct [A] safe or not ?
>
> {
> rcu_read_lock_bh();
> /* BH are now disabled, and we are not allowed to sleep */
> ...
>
> ptr = rcu_dereference();
This should be:
ptr = rcu_dereference_bh();
As you say below. Never mind! ;-)
> ...
> rcu_read_unlock_bh();
> }
>
>
> I dont really understand why lockdep wants [B] instead :
>
> {
> rcu_read_lock_bh();
> ...
>
> {
> rcu_read_lock();
> ptr = rcu_dereference();
Here you are protected by both RCU and RCU-bh, so you should be able
to use either rcu_dereference() or rcu_dereference_bh(). A bit
strange to use rcu_dereference_bh(), though. Except perhaps if a
pointer to a function was passed in from the outer RCU-bh read-side
critical section or something.
> rcu_read_unlock();
> }
> ...
> rcu_read_unlock_bh();
> }
>
>
>
> However, I can understand the other way [C], this is really needed :
>
> {
> rcu_read_lock();
> ...
>
> {
> rcu_read_lock_bh();
> ptr = rcu_dereference_bh();
> rcu_read_unlock_bh();
> }
> ...
> rcu_read_unlock();
> }
>
> I believe [A] should be allowed by lockdep.
OK, I'll bite. Why?
Thanx, Paul
^ permalink raw reply
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: Jeff Kirsher @ 2011-08-12 5:47 UTC (permalink / raw)
To: Stephen Rothwell
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20110812150003.1e2ba71018bea040fc7649d7@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 11534 bytes --]
On Thu, 2011-08-11 at 22:00 -0700, Stephen Rothwell wrote:
> Hi Jeff,
>
> On Fri, 12 Aug 2011 14:41:31 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > On Thu, 11 Aug 2011 20:40:14 -0700 Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> > >
> > > On Thu, 2011-08-11 at 20:33 -0700, Kirsher, Jeffrey T wrote:
> > > > Both Spider net driver and Sun GEM driver use the sungem_phy.o object.
> > > > This fix creates a Kconfig object for sungem_phy (like MDIO) so that
> > > > both drivers require the SUNGEM_PHY object.
> > > >
> > > > This has been compile tested for the Sun GEM driver.
> > > >
> > > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > > ---
> > > > drivers/net/Kconfig | 4 ++++
> > > > drivers/net/Makefile | 2 +-
> > > > drivers/net/ethernet/sun/Kconfig | 1 +
> > > > drivers/net/ethernet/sun/Makefile | 3 ++-
> > > > 4 files changed, 8 insertions(+), 2 deletions(-)
> > >
> > > Stephen, is it possible for you to try this patch to ensure it resolves
> > > the compile issue you saw for the Spider Net driver when merging with
> > > David's net-next tree?
> >
> > That patch doesn't come close to applying to the copy of Dave's tree I
> > have from this morning (head e7c379d2a0dc). I'll see if I can figure it
> > out ...
>
> OK, I applied it by hand and it seems to fix that failure, thanks.
>
> However, Dave, I now get these (powerpc ppc64defconfig build of just the
> net tree):
>
> ERROR: ".cxgb4_unregister_uld" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_register_uld" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_iscsi_init" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_port_idx" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_port_viid" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_port_chan" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_best_mtu" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_l2t_get" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_alloc_atid" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_l2t_release" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_pktgl_to_skb" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_remove_tid" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_free_atid" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_ofld_send" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb4_l2t_send" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
> ERROR: ".cxgb3_unregister_client" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".cxgb3_register_client" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".t3_l2e_free" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".cxgb3_remove_tid" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".cxgb3_alloc_atid" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".t3_l2t_get" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".cxgb3_queue_tid_release" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".cxgb3_free_atid" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".cxgb3_insert_tid" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".t3_l2t_send_slow" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".cxgb3_ofld_send" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
> ERROR: ".cnic_unregister_driver" [drivers/scsi/bnx2i/bnx2i.ko] undefined!
> ERROR: ".cnic_register_driver" [drivers/scsi/bnx2i/bnx2i.ko] undefined!
> ERROR: ".mii_phy_probe" [drivers/net/spidernet.ko] undefined!
> ERROR: ".mlx4_cq_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_qp_release_range" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_counter_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_write_mtt" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_get_protocol_dev" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_srq_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_srq_query" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_fmr_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_multicast_detach" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_db_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_unregister_interface" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_buf_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_mr_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_mtt_init" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_fmr_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_cq_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_pd_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_SYNC_TPT" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_qp_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_buf_write_mtt" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_cq_resize" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_fmr_unmap" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_qp_modify" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_mtt_cleanup" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_counter_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_mr_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_qp_reserve_range" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_alloc_cmd_mailbox" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_fmr_enable" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_mr_enable" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_uar_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_db_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_pd_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_free_cmd_mailbox" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_srq_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_uar_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_CLOSE_PORT" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_qp_query" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_qp_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_map_phys_fmr" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_qp_remove" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_multicast_attach" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_INIT_PORT" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_cq_modify" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_srq_arm" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_find_cached_vlan" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_buf_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".__mlx4_cmd" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".mlx4_register_interface" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
> ERROR: ".cxgb4_free_atid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_ofld_send" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_alloc_stid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_get_tcp_stats" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_l2t_release" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_l2t_get" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_best_mtu" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_port_idx" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_unregister_uld" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_alloc_atid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_l2t_send" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_free_stid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_pktgl_to_skb" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_create_server" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_register_uld" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_port_chan" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_port_viid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".cxgb4_remove_tid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
> ERROR: ".dev2t3cdev" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_insert_tid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".t3_l2t_get" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_register_client" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".t3_l2t_send_slow" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_unregister_client" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_free_stid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_free_atid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_alloc_stid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_remove_tid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_ofld_send" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".cxgb3_alloc_atid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".t3_l2t_send_event" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".t3_l2e_free" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
> ERROR: ".t3_register_cpl_handler" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
>
> and I don't get this if I go back to your commit 19fd61785a58.
>
This is just an example of the change that would be needed to resolve
defconfig issues. The below patch should resolve the cxgb3/4 errors. I
have not made the necessary changes to resolve the mlx4 issues in this
patch. I can generate those as well, if need be.
diff --git a/arch/powerpc/configs/ppc64_defconfig
b/arch/powerpc/configs/ppc64_defconfig
index 84a685a5..4f099ba 100644
--- a/arch/powerpc/configs/ppc64_defconfig
+++ b/arch/powerpc/configs/ppc64_defconfig
@@ -229,6 +229,11 @@ CONFIG_BONDING=m
CONFIG_TUN=m
CONFIG_MARVELL_PHY=y
CONFIG_BROADCOM_PHY=m
+CONFIG_ETHERNET=y
+CONFIG_NET_VENDOR_CHELSIO=y
+CONFIG_CHELSIO_T1=m
+CONFIG_CHELSIO_T3=m
+CONFIG_CHELSIO_T4=m
CONFIG_NET_ETHERNET=y
CONFIG_SUNGEM=y
CONFIG_NET_VENDOR_3COM=y
@@ -246,9 +251,6 @@ CONFIG_BNX2=m
CONFIG_SPIDER_NET=m
CONFIG_GELIC_NET=m
CONFIG_GELIC_WIRELESS=y
-CONFIG_CHELSIO_T1=m
-CONFIG_CHELSIO_T3=m
-CONFIG_CHELSIO_T4=m
CONFIG_EHEA=m
CONFIG_IXGBE=m
CONFIG_IXGB=m
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply related
* [PATCH net-next] net: cleanup some rcu_dereference_raw
From: Eric Dumazet @ 2011-08-12 5:30 UTC (permalink / raw)
To: David Miller; +Cc: netdev
RCU api had been completed and rcu_access_pointer() or
rcu_dereference_protected() are better than generic
rcu_dereference_raw()
Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
---
net/core/dev.c | 10 +++++-----
net/core/fib_rules.c | 2 +-
net/core/net-sysfs.c | 4 ++--
net/ipv4/ipmr.c | 4 ++--
net/ipv4/route.c | 6 +++---
net/ipv4/udp.c | 7 +++----
net/ipv6/raw.c | 4 ++--
net/ipv6/udp.c | 2 +-
net/mac80211/mesh_pathtbl.c | 4 ++--
net/netlink/af_netlink.c | 2 +-
10 files changed, 22 insertions(+), 23 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 9428766..d22ffd7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -2673,13 +2673,13 @@ static int get_rps_cpu(struct net_device *dev, struct sk_buff *skb,
map = rcu_dereference(rxqueue->rps_map);
if (map) {
if (map->len == 1 &&
- !rcu_dereference_raw(rxqueue->rps_flow_table)) {
+ !rcu_access_pointer(rxqueue->rps_flow_table)) {
tcpu = map->cpus[0];
if (cpu_online(tcpu))
cpu = tcpu;
goto done;
}
- } else if (!rcu_dereference_raw(rxqueue->rps_flow_table)) {
+ } else if (!rcu_access_pointer(rxqueue->rps_flow_table)) {
goto done;
}
@@ -5727,8 +5727,8 @@ void netdev_run_todo(void)
/* paranoia */
BUG_ON(netdev_refcnt_read(dev));
- WARN_ON(rcu_dereference_raw(dev->ip_ptr));
- WARN_ON(rcu_dereference_raw(dev->ip6_ptr));
+ WARN_ON(rcu_access_pointer(dev->ip_ptr));
+ WARN_ON(rcu_access_pointer(dev->ip6_ptr));
WARN_ON(dev->dn_ptr);
if (dev->destructor)
@@ -5932,7 +5932,7 @@ void free_netdev(struct net_device *dev)
kfree(dev->_rx);
#endif
- kfree(rcu_dereference_raw(dev->ingress_queue));
+ kfree(rcu_dereference_protected(dev->ingress_queue, 1));
/* Flush device addresses */
dev_addr_flush(dev);
diff --git a/net/core/fib_rules.c b/net/core/fib_rules.c
index 0657b57..67c5c28 100644
--- a/net/core/fib_rules.c
+++ b/net/core/fib_rules.c
@@ -545,7 +545,7 @@ static int fib_nl_fill_rule(struct sk_buff *skb, struct fib_rule *rule,
frh->flags = rule->flags;
if (rule->action == FR_ACT_GOTO &&
- rcu_dereference_raw(rule->ctarget) == NULL)
+ rcu_access_pointer(rule->ctarget) == NULL)
frh->flags |= FIB_RULE_UNRESOLVED;
if (rule->iifname[0]) {
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index b1ab887..56e42ab 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -712,13 +712,13 @@ static void rx_queue_release(struct kobject *kobj)
struct rps_dev_flow_table *flow_table;
- map = rcu_dereference_raw(queue->rps_map);
+ map = rcu_dereference_protected(queue->rps_map, 1);
if (map) {
RCU_INIT_POINTER(queue->rps_map, NULL);
kfree_rcu(map, rcu);
}
- flow_table = rcu_dereference_raw(queue->rps_flow_table);
+ flow_table = rcu_dereference_protected(queue->rps_flow_table, 1);
if (flow_table) {
RCU_INIT_POINTER(queue->rps_flow_table, NULL);
call_rcu(&flow_table->rcu, rps_dev_flow_table_release);
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index f550285..6164e98 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1203,7 +1203,7 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
return -ENOENT;
if (optname != MRT_INIT) {
- if (sk != rcu_dereference_raw(mrt->mroute_sk) &&
+ if (sk != rcu_access_pointer(mrt->mroute_sk) &&
!capable(CAP_NET_ADMIN))
return -EACCES;
}
@@ -1230,7 +1230,7 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
rtnl_unlock();
return ret;
case MRT_DONE:
- if (sk != rcu_dereference_raw(mrt->mroute_sk))
+ if (sk != rcu_access_pointer(mrt->mroute_sk))
return -EACCES;
return ip_ra_control(sk, 0, NULL);
case MRT_ADD_VIF:
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index cb7efe0..d6e3213 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -324,7 +324,7 @@ static struct rtable *rt_cache_get_first(struct seq_file *seq)
struct rtable *r = NULL;
for (st->bucket = rt_hash_mask; st->bucket >= 0; --st->bucket) {
- if (!rcu_dereference_raw(rt_hash_table[st->bucket].chain))
+ if (!rcu_access_pointer(rt_hash_table[st->bucket].chain))
continue;
rcu_read_lock_bh();
r = rcu_dereference_bh(rt_hash_table[st->bucket].chain);
@@ -350,7 +350,7 @@ static struct rtable *__rt_cache_get_next(struct seq_file *seq,
do {
if (--st->bucket < 0)
return NULL;
- } while (!rcu_dereference_raw(rt_hash_table[st->bucket].chain));
+ } while (!rcu_access_pointer(rt_hash_table[st->bucket].chain));
rcu_read_lock_bh();
r = rcu_dereference_bh(rt_hash_table[st->bucket].chain);
}
@@ -762,7 +762,7 @@ static void rt_do_flush(struct net *net, int process_context)
if (process_context && need_resched())
cond_resched();
- rth = rcu_dereference_raw(rt_hash_table[i].chain);
+ rth = rcu_access_pointer(rt_hash_table[i].chain);
if (!rth)
continue;
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index 1b5a193..c1d5fac 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1461,10 +1461,9 @@ int udp_queue_rcv_skb(struct sock *sk, struct sk_buff *skb)
}
}
- if (rcu_dereference_raw(sk->sk_filter)) {
- if (udp_lib_checksum_complete(skb))
- goto drop;
- }
+ if (rcu_access_pointer(sk->sk_filter) &&
+ udp_lib_checksum_complete(skb))
+ goto drop;
if (sk_rcvqueues_full(sk, skb))
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index 4f45dc9..f34902f 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -372,9 +372,9 @@ void raw6_icmp_error(struct sk_buff *skb, int nexthdr,
read_unlock(&raw_v6_hashinfo.lock);
}
-static inline int rawv6_rcv_skb(struct sock * sk, struct sk_buff * skb)
+static inline int rawv6_rcv_skb(struct sock *sk, struct sk_buff *skb)
{
- if ((raw6_sk(sk)->checksum || rcu_dereference_raw(sk->sk_filter)) &&
+ if ((raw6_sk(sk)->checksum || rcu_access_pointer(sk->sk_filter)) &&
skb_checksum_complete(skb)) {
atomic_inc(&sk->sk_drops);
kfree_skb(skb);
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 29213b5..97e47f0 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -533,7 +533,7 @@ int udpv6_queue_rcv_skb(struct sock * sk, struct sk_buff *skb)
}
}
- if (rcu_dereference_raw(sk->sk_filter)) {
+ if (rcu_access_pointer(sk->sk_filter)) {
if (udp_lib_checksum_complete(skb))
goto drop;
}
diff --git a/net/mac80211/mesh_pathtbl.c b/net/mac80211/mesh_pathtbl.c
index 068ee65..dc7ae8d 100644
--- a/net/mac80211/mesh_pathtbl.c
+++ b/net/mac80211/mesh_pathtbl.c
@@ -843,6 +843,6 @@ void mesh_path_expire(struct ieee80211_sub_if_data *sdata)
void mesh_pathtbl_unregister(void)
{
/* no need for locking during exit path */
- mesh_table_free(rcu_dereference_raw(mesh_paths), true);
- mesh_table_free(rcu_dereference_raw(mpp_paths), true);
+ mesh_table_free(rcu_dereference_protected(mesh_paths, 1), true);
+ mesh_table_free(rcu_dereference_protected(mpp_paths, 1), true);
}
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 0a4db02..4330db9 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -1578,7 +1578,7 @@ int __netlink_change_ngroups(struct sock *sk, unsigned int groups)
new = kzalloc(sizeof(*new) + NLGRPSZ(groups), GFP_ATOMIC);
if (!new)
return -ENOMEM;
- old = rcu_dereference_raw(tbl->listeners);
+ old = rcu_dereference_protected(tbl->listeners, 1);
memcpy(new->masks, old->masks, NLGRPSZ(tbl->groups));
rcu_assign_pointer(tbl->listeners, new);
^ permalink raw reply related
* Re: linux-next: build failure after merge of the net tree
From: Jeff Kirsher @ 2011-08-12 5:22 UTC (permalink / raw)
To: Stephen Rothwell
Cc: David Miller, netdev@vger.kernel.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20110812143418.4fe084a6926f9f6258b596fd@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 520 bytes --]
On Thu, 2011-08-11 at 21:34 -0700, Stephen Rothwell wrote:
> Hi Jeff,
>
> On Thu, 11 Aug 2011 20:05:25 -0700 Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> >
> > I am working on a patch now to fix this.
> >
> > Stephen - if you could compile test it, I would greatly appreciate.
>
> Sure, send it over. With master.kernel.org down, its not like I can
> releease linux-next anyway :-)
>
That explains why I was having issues connecting to
master.kernel.org. :) Good to know it was not just me.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 2/9] drivers/net/wireless/wl12xx: add missing kfree
From: Luciano Coelho @ 2011-08-12 5:14 UTC (permalink / raw)
To: John W. Linville
Cc: kernel-janitors-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Julia Lawall
In-Reply-To: <1312802283-9107-2-git-send-email-julia-dAYI7NvHqcQ@public.gmane.org>
On Mon, 2011-08-08 at 13:17 +0200, Julia Lawall wrote:
> From: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> In each case, the freed data should be freed in the error handling code as
> well.
[...]
> Signed-off-by: Julia Lawall <julia-dAYI7NvHqcQ@public.gmane.org>
>
> ---
John, since you took Julia's patch for wl1251 into 3.1, could you also
take this patch into it, please?
Acked-by: Luciano Coelho <coelho-l0cyMroinI0@public.gmane.org>
--
Cheers,
Luca.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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: [net-next] spider_net: fix compile issue introduced by driver move
From: Stephen Rothwell @ 2011-08-12 5:00 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20110812144131.59de312ee6e1a9e8865c1a85@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 10297 bytes --]
Hi Jeff,
On Fri, 12 Aug 2011 14:41:31 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 11 Aug 2011 20:40:14 -0700 Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
> >
> > On Thu, 2011-08-11 at 20:33 -0700, Kirsher, Jeffrey T wrote:
> > > Both Spider net driver and Sun GEM driver use the sungem_phy.o object.
> > > This fix creates a Kconfig object for sungem_phy (like MDIO) so that
> > > both drivers require the SUNGEM_PHY object.
> > >
> > > This has been compile tested for the Sun GEM driver.
> > >
> > > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > > ---
> > > drivers/net/Kconfig | 4 ++++
> > > drivers/net/Makefile | 2 +-
> > > drivers/net/ethernet/sun/Kconfig | 1 +
> > > drivers/net/ethernet/sun/Makefile | 3 ++-
> > > 4 files changed, 8 insertions(+), 2 deletions(-)
> >
> > Stephen, is it possible for you to try this patch to ensure it resolves
> > the compile issue you saw for the Spider Net driver when merging with
> > David's net-next tree?
>
> That patch doesn't come close to applying to the copy of Dave's tree I
> have from this morning (head e7c379d2a0dc). I'll see if I can figure it
> out ...
OK, I applied it by hand and it seems to fix that failure, thanks.
However, Dave, I now get these (powerpc ppc64defconfig build of just the
net tree):
ERROR: ".cxgb4_unregister_uld" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_register_uld" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_iscsi_init" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_port_idx" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_port_viid" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_port_chan" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_best_mtu" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_l2t_get" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_alloc_atid" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_l2t_release" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_pktgl_to_skb" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_remove_tid" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_free_atid" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_ofld_send" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb4_l2t_send" [drivers/scsi/cxgbi/cxgb4i/cxgb4i.ko] undefined!
ERROR: ".cxgb3_unregister_client" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".cxgb3_register_client" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".t3_l2e_free" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".cxgb3_remove_tid" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".cxgb3_alloc_atid" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".t3_l2t_get" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".cxgb3_queue_tid_release" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".cxgb3_free_atid" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".cxgb3_insert_tid" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".t3_l2t_send_slow" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".cxgb3_ofld_send" [drivers/scsi/cxgbi/cxgb3i/cxgb3i.ko] undefined!
ERROR: ".cnic_unregister_driver" [drivers/scsi/bnx2i/bnx2i.ko] undefined!
ERROR: ".cnic_register_driver" [drivers/scsi/bnx2i/bnx2i.ko] undefined!
ERROR: ".mii_phy_probe" [drivers/net/spidernet.ko] undefined!
ERROR: ".mlx4_cq_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_qp_release_range" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_counter_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_write_mtt" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_get_protocol_dev" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_srq_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_srq_query" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_fmr_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_multicast_detach" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_db_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_unregister_interface" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_buf_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_mr_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_mtt_init" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_fmr_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_cq_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_pd_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_SYNC_TPT" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_qp_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_buf_write_mtt" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_cq_resize" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_fmr_unmap" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_qp_modify" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_mtt_cleanup" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_counter_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_mr_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_qp_reserve_range" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_alloc_cmd_mailbox" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_fmr_enable" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_mr_enable" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_uar_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_db_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_pd_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_free_cmd_mailbox" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_srq_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_uar_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_CLOSE_PORT" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_qp_query" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_qp_alloc" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_map_phys_fmr" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_qp_remove" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_multicast_attach" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_INIT_PORT" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_cq_modify" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_srq_arm" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_find_cached_vlan" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_buf_free" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".__mlx4_cmd" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".mlx4_register_interface" [drivers/infiniband/hw/mlx4/mlx4_ib.ko] undefined!
ERROR: ".cxgb4_free_atid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_ofld_send" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_alloc_stid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_get_tcp_stats" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_l2t_release" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_l2t_get" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_best_mtu" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_port_idx" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_unregister_uld" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_alloc_atid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_l2t_send" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_free_stid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_pktgl_to_skb" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_create_server" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_register_uld" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_port_chan" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_port_viid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".cxgb4_remove_tid" [drivers/infiniband/hw/cxgb4/iw_cxgb4.ko] undefined!
ERROR: ".dev2t3cdev" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_insert_tid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".t3_l2t_get" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_register_client" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".t3_l2t_send_slow" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_unregister_client" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_free_stid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_free_atid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_alloc_stid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_remove_tid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_ofld_send" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".cxgb3_alloc_atid" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".t3_l2t_send_event" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".t3_l2e_free" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
ERROR: ".t3_register_cpl_handler" [drivers/infiniband/hw/cxgb3/iw_cxgb3.ko] undefined!
and I don't get this if I go back to your commit 19fd61785a58.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Dear Internet User !!!
From: Microsoft Donation @ 2011-08-12 3:45 UTC (permalink / raw)
To: info
Dear Internet User! Microsoft Company have donated ?1,000,000 GBP to you and your family has a benefit for joining us in expanding the use of microsoft windows and internet in your country. For Claims Contact: Mrs.Hope Spencer. Email:mrs.hopespencer@admin.in.th
^ permalink raw reply
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: Stephen Rothwell @ 2011-08-12 4:41 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: davem@davemloft.net, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1313120415.2029.3.camel@jtkirshe-mobl>
[-- Attachment #1: Type: text/plain, Size: 1208 bytes --]
Hi Jeff,
On Thu, 11 Aug 2011 20:40:14 -0700 Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
>
> On Thu, 2011-08-11 at 20:33 -0700, Kirsher, Jeffrey T wrote:
> > Both Spider net driver and Sun GEM driver use the sungem_phy.o object.
> > This fix creates a Kconfig object for sungem_phy (like MDIO) so that
> > both drivers require the SUNGEM_PHY object.
> >
> > This has been compile tested for the Sun GEM driver.
> >
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > ---
> > drivers/net/Kconfig | 4 ++++
> > drivers/net/Makefile | 2 +-
> > drivers/net/ethernet/sun/Kconfig | 1 +
> > drivers/net/ethernet/sun/Makefile | 3 ++-
> > 4 files changed, 8 insertions(+), 2 deletions(-)
>
> Stephen, is it possible for you to try this patch to ensure it resolves
> the compile issue you saw for the Spider Net driver when merging with
> David's net-next tree?
That patch doesn't come close to applying to the copy of Dave's tree I
have from this morning (head e7c379d2a0dc). I'll see if I can figure it
out ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: linux-next: build failure after merge of the net tree
From: Stephen Rothwell @ 2011-08-12 4:34 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: David Miller, netdev@vger.kernel.org, linux-next@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1313118339.2029.1.camel@jtkirshe-mobl>
[-- Attachment #1: Type: text/plain, Size: 433 bytes --]
Hi Jeff,
On Thu, 11 Aug 2011 20:05:25 -0700 Jeff Kirsher <jeffrey.t.kirsher@intel.com> wrote:
>
> I am working on a patch now to fix this.
>
> Stephen - if you could compile test it, I would greatly appreciate.
Sure, send it over. With master.kernel.org down, its not like I can
releease linux-next anyway :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* HONDA PROMOTION 2011
From: HONDA COMPANY UK @ 2011-08-12 3:57 UTC (permalink / raw)
Your email has won £1,750,000.00 GBP Contact
richard_hcuk111@pkuit.com For More information.
Mr. Berenice Lopez (Program Co-ordinator.)
^ permalink raw reply
* Re: [net-next] spider_net: fix compile issue introduced by driver move
From: Jeff Kirsher @ 2011-08-12 3:40 UTC (permalink / raw)
To: davem@davemloft.net
Cc: netdev@vger.kernel.org, sfr@canb.auug.org.au,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1313120000-12085-1-git-send-email-jeffrey.t.kirsher@intel.com>
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
On Thu, 2011-08-11 at 20:33 -0700, Kirsher, Jeffrey T wrote:
> Both Spider net driver and Sun GEM driver use the sungem_phy.o object.
> This fix creates a Kconfig object for sungem_phy (like MDIO) so that
> both drivers require the SUNGEM_PHY object.
>
> This has been compile tested for the Sun GEM driver.
>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> ---
> drivers/net/Kconfig | 4 ++++
> drivers/net/Makefile | 2 +-
> drivers/net/ethernet/sun/Kconfig | 1 +
> drivers/net/ethernet/sun/Makefile | 3 ++-
> 4 files changed, 8 insertions(+), 2 deletions(-)
Stephen, is it possible for you to try this patch to ensure it resolves
the compile issue you saw for the Spider Net driver when merging with
David's net-next tree?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [net-next] spider_net: fix compile issue introduced by driver move
From: Jeff Kirsher @ 2011-08-12 3:33 UTC (permalink / raw)
To: davem; +Cc: Jeff Kirsher, netdev, sfr, linux-next, linux-kernel
Both Spider net driver and Sun GEM driver use the sungem_phy.o object.
This fix creates a Kconfig object for sungem_phy (like MDIO) so that
both drivers require the SUNGEM_PHY object.
This has been compile tested for the Sun GEM driver.
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
drivers/net/Kconfig | 4 ++++
drivers/net/Makefile | 2 +-
drivers/net/ethernet/sun/Kconfig | 1 +
drivers/net/ethernet/sun/Makefile | 3 ++-
4 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e6be7123..c8779c1 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -934,6 +934,7 @@ config SPIDER_NET
tristate "Spider Gigabit Ethernet driver"
depends on PCI && (PPC_IBM_CELL_BLADE || PPC_CELLEB)
select FW_LOADER
+ select SUNGEM_PHY
help
This driver supports the Gigabit Ethernet chips present on the
Cell Processor-Based Blades from IBM.
@@ -1083,6 +1084,9 @@ if NETDEV_10000
config MDIO
tristate
+config SUNGEM_PHY
+ tristate
+
endif # NETDEV_10000
source "drivers/net/tokenring/Kconfig"
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d151075..db888b0 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -41,7 +41,7 @@ obj-$(CONFIG_R6040) += r6040.o
obj-$(CONFIG_YELLOWFIN) += yellowfin.o
obj-$(CONFIG_FEALNX) += fealnx.o
spidernet-y += spider_net.o spider_net_ethtool.o
-obj-$(CONFIG_SPIDER_NET) += spidernet.o ethernet/sun/sungem_phy.o
+obj-$(CONFIG_SPIDER_NET) += spidernet.o
obj-$(CONFIG_GELIC_NET) += ps3_gelic.o
gelic_wireless-$(CONFIG_GELIC_WIRELESS) += ps3_gelic_wireless.o
ps3_gelic-objs += ps3_gelic_net.o $(gelic_wireless-y)
diff --git a/drivers/net/ethernet/sun/Kconfig b/drivers/net/ethernet/sun/Kconfig
index 87b17a7..5132fa6 100644
--- a/drivers/net/ethernet/sun/Kconfig
+++ b/drivers/net/ethernet/sun/Kconfig
@@ -57,6 +57,7 @@ config SUNGEM
tristate "Sun GEM support"
depends on PCI
select CRC32
+ select SUNGEM_PHY
---help---
Support for the Sun GEM chip, aka Sun GigabitEthernet/P 2.0. See also
<http://www.sun.com/products-n-solutions/hardware/docs/pdf/806-3985-10.pdf>.
diff --git a/drivers/net/ethernet/sun/Makefile b/drivers/net/ethernet/sun/Makefile
index 4f25217..6e25dad 100644
--- a/drivers/net/ethernet/sun/Makefile
+++ b/drivers/net/ethernet/sun/Makefile
@@ -5,7 +5,8 @@
obj-$(CONFIG_HAPPYMEAL) += sunhme.o
obj-$(CONFIG_SUNQE) += sunqe.o
obj-$(CONFIG_SUNBMAC) += sunbmac.o
-obj-$(CONFIG_SUNGEM) += sungem.o sungem_phy.o
+obj-$(CONFIG_SUNGEM) += sungem.o
+obj-$(CONFIG_SUNGEM_PHY) += sungem_phy.o
obj-$(CONFIG_CASSINI) += cassini.o
obj-$(CONFIG_SUNVNET) += sunvnet.o
obj-$(CONFIG_NIU) += niu.o
--
1.7.6
^ permalink raw reply related
* [PATCH RESEND] gianfar: reduce stack usage in gianfar_ethtool.c
From: stufever @ 2011-08-12 3:07 UTC (permalink / raw)
To: linux-kernel; +Cc: netdev, davem, sebastian.poehn, Wang Shaoyan
From: Wang Shaoyan <wangshaoyan.pt@taobao.com>
drivers/net/gianfar_ethtool.c:765: warning: the frame size of 2048 bytes is larger than 1024 bytes
Signed-off-by: Wang Shaoyan <wangshaoyan.pt@taobao.com>
Reviewed-and-tested-by: Sebastian Pöhn <sebastian.poehn@belden.com>
---
drivers/net/gianfar_ethtool.c | 26 +++++++++++++++++++++-----
1 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/drivers/net/gianfar_ethtool.c b/drivers/net/gianfar_ethtool.c
index 6e35069..25a8c2a 100644
--- a/drivers/net/gianfar_ethtool.c
+++ b/drivers/net/gianfar_ethtool.c
@@ -686,10 +686,21 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
{
unsigned int last_rule_idx = priv->cur_filer_idx;
unsigned int cmp_rqfpr;
- unsigned int local_rqfpr[MAX_FILER_IDX + 1];
- unsigned int local_rqfcr[MAX_FILER_IDX + 1];
+ unsigned int *local_rqfpr;
+ unsigned int *local_rqfcr;
int i = 0x0, k = 0x0;
int j = MAX_FILER_IDX, l = 0x0;
+ int ret = 1;
+
+ local_rqfpr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ local_rqfcr = kmalloc(sizeof(unsigned int) * (MAX_FILER_IDX + 1),
+ GFP_KERNEL);
+ if (!local_rqfpr || !local_rqfcr) {
+ pr_err("Out of memory\n");
+ ret = 0;
+ goto err;
+ }
switch (class) {
case TCP_V4_FLOW:
@@ -706,7 +717,8 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
break;
default:
pr_err("Right now this class is not supported\n");
- return 0;
+ ret = 0;
+ goto err;
}
for (i = 0; i < MAX_FILER_IDX + 1; i++) {
@@ -721,7 +733,8 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
if (i == MAX_FILER_IDX + 1) {
pr_err("No parse rule found, can't create hash rules\n");
- return 0;
+ ret = 0;
+ goto err;
}
/* If a match was found, then it begins the starting of a cluster rule
@@ -765,7 +778,10 @@ static int gfar_ethflow_to_filer_table(struct gfar_private *priv, u64 ethflow, u
priv->cur_filer_idx = priv->cur_filer_idx - 1;
}
- return 1;
+err:
+ kfree(local_rqfcr);
+ kfree(local_rqfpr);
+ return ret;
}
static int gfar_set_hash_opts(struct gfar_private *priv, struct ethtool_rxnfc *cmd)
--
1.7.4.1
^ permalink raw reply related
* Re: linux-next: build failure after merge of the net tree
From: Jeff Kirsher @ 2011-08-12 3:05 UTC (permalink / raw)
To: David Miller
Cc: sfr@canb.auug.org.au, netdev@vger.kernel.org,
linux-next@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20110811.195150.1070520107072994432.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 779 bytes --]
On Thu, 2011-08-11 at 19:51 -0700, David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Thu, 11 Aug 2011 19:31:35 -0700
>
> > I am curious, can you compile the Sun GEM support driver? and if so,
> > does the Spider Net driver compile?
>
> I'm pretty sure you cannot reference object targets outside of
> the current directory and expect it to work.
>
> You can only reference things in the current directory (objects,
> directories to traverse down into, etc.) as targets
>
> So when there is a common piece of infrastructure shared by
> two drivers, you're really going to have to cope with them
> at the same time.
I am working on a patch now to fix this.
Stephen - if you could compile test it, I would greatly appreciate.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ 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