* Re: [PATCH] drivers/base: export gpl (un)register_memory_notifier
From: Dave Hansen @ 2008-02-12 18:04 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Themann, Jan-Bernd, netdev, linux-kernel, Thomas Klein, linux-ppc,
Christoph Raisch, Greg KH
In-Reply-To: <200802111724.12416.ossthema@de.ibm.com>
On Mon, 2008-02-11 at 17:24 +0100, Jan-Bernd Themann wrote:
> Drivers like eHEA need memory notifiers in order to
> update their internal DMA memory map when memory is added
> to or removed from the system.
>
> Patch for eHEA memory hotplug support that uses these functions:
> http://www.spinics.net/lists/netdev/msg54484.html
This driver is broken pretty horribly. It won't even compile for a
plain ppc64 kernel:
http://sr71.net/~dave/linux/ehea-is-broken.config
I know it's used for very specific hardware, but this is the symptom of
it not using the proper abstracted interfaces to the VM.
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_main.c:42:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
CC drivers/net/mii.o
make[4]: *** [drivers/net/ehea/ehea_main.o] Error 1
make[4]: *** Waiting for unfinished jobs....
CC drivers/net/ixgb/ixgb_param.o
In file included from /home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:32:
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:44:14: warning: "SECTION_SIZE_BITS" is not defined
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.h:45:2: error: #error eHEA module cannot work if kernel sectionsize < ehea sectionsize
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_create_busmap':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: 'NR_MEM_SECTIONS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: (Each undeclared identifier is reported only once
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:574: error: for each function it appears in.)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:575: error: implicit declaration of function 'valid_section_nr'
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_map_vaddr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:606: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c: In function 'ehea_reg_kernel_mr':
/home/dave/work/linux/2.6/23/linux-2.6.git/drivers/net/ehea/ehea_qmr.c:655: error: 'SECTION_SIZE_BITS' undeclared (first use in this function)
-- Dave
^ permalink raw reply
* Re: Open bugs
From: Natalie Protasevich @ 2008-02-12 18:55 UTC (permalink / raw)
To: James Bottomley
Cc: linux-kernel, akpm, netdev, alsa-devel, linux-ide, bugme-daemon,
linux-scsi
In-Reply-To: <1202839022.3137.63.camel@localhost.localdomain>
On Feb 12, 2008 9:57 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> Added linux-scsi for the SCSI ones
>
> On Tue, 2008-02-12 at 00:18 -0800, Natalie Protasevich wrote:
> > Hello,
> >
> > The bugs listed are over a month old, and haven't been addressed yet.
> > It would be appreciated if corresponding maintainers identify whether
> > the bugs have been fixed, or need to be worked on, and take
> > appropriate action.
> >
> > In most cases, reporters are standing by and ready to provide
> > information and necessary testing.
> > Thanks!
> >
> > SCSI======================================================
> >
> > Problems on booting
> > http://bugzilla.kernel.org/show_bug.cgi?id=9621
> > Date: 12/22/2007
> > Regression
> > Summary: The boot stops / hangs on hardware detection of SCSI. I have
> > an InitioINI-9X00U/UW
> > When I have an usb key sticked in /dev/sba, and run lilo then, then it
> > dont boot but give L99 99 99 99 ... error
>
> I think this was fixed by commit
> e2d435ea4084022ab88efa74214accb45b1f9e92
>
> Apparently bugzilla email is on the fritz again because this bug report
> didn't come across linux-scsi.
I just fixed that, thanks. It was incorrect "assign-to" party.
>
> > Resetting RAID attached to a FC Switch causes kernel panic and crash
> > http://bugzilla.kernel.org/show_bug.cgi?id=9598
> > 12/18/2007
> > Hardware Environment:SunFire X4200 - 2 x dual core AMD Opteron CPUs,
> > 8GB Ram, Qlogic FC adapter.
> > Summary: Resetting the RAID box causes the X4200 to crash.
>
> This one looks like the usual problem of remove re-add with the SCSI
> device model.
>
> > 3ware 9650SE -8LPML not recognized by 3w-9xxx driver
> > http://bugzilla.kernel.org/show_bug.cgi?id=8908
> > 08/19/2007
> > Problem Description: The 3w-9xxx kernel driver for 3ware 9xxx SATA
> > RAID Controller series did not recognize the 3ware 9650SE-8LPML SATA
> > RAID Controller.
>
> Since this one never apparently worked it's not a regression but an
> enhancement request, isn't it?
No this is not a regression. The bug list that I post is just any bugs
(mostly unattended or stalled). Sometimes those are regressions off of
the Raphael's list, when they don't get resolved for a while, or just
random regressions that haven't showed up on the "hot list" by
Raphael.
>
> However, adding this PCI ID to the driver should be fairly
> straightforward. Does anyone know what the actual PCI IDs are?
I just asked the reporter to provide this information, thanks.
>
> James
>
>
^ permalink raw reply
* Re: [PATCH] fib_trie: rcu_assign_pointer warning fix
From: Jarek Poplawski @ 2008-02-12 19:32 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: David Miller, shemminger, netdev, linux-kernel
In-Reply-To: <20080212160729.GA9157@linux.vnet.ibm.com>
On Tue, Feb 12, 2008 at 08:07:29AM -0800, Paul E. McKenney wrote:
...
> "All programmers are blind, especially me."
Hmm... I got it my way: you - superheroes - sometimes seem to be just
like us - common people... (Probably early in the morning, before
dressing your funny costumes?)
> You are right, Jarek. I ran this through gcc, and the following
> comes close:
>
> #define rcu_assign_pointer(p, v) \
> ({ \
> if (!__builtin_constant_p(v) || (v)) \
> smp_wmb(); \
> (p) = (v); \
> })
>
> But I am concerned about the following case:
>
> rcu_assign_pointer(global_index, 0);
>
> . . .
>
> x = global_array[rcu_dereference(global_index)];
>
> Since arrays have a zero-th element, we would really want a memory
> barrier in this case.
It seems the above version of this macro uses the barrier for 0, but
if I miss something, or for these other: documenting reasons, then of
course you are right.
>
> So how about leaving the index-unfriendly version of rcu_assign_pointer()
> and adding an rcu_assign_index() as follows?
>
> Thanx, Paul
>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> ---
>
> rcupdate.h | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff -urpNa -X dontdiff linux-2.6.24/include/linux/rcupdate.h linux-2.6.24-rai/include/linux/rcupdate.h
> --- linux-2.6.24/include/linux/rcupdate.h 2008-01-24 14:58:37.000000000 -0800
> +++ linux-2.6.24-rai/include/linux/rcupdate.h 2008-02-12 08:04:59.000000000 -0800
> @@ -278,6 +278,24 @@ extern struct lockdep_map rcu_lock_map;
> })
>
> /**
> + * rcu_assign_index - assign (publicize) a index of a newly
> + * initialized array elementg that will be dereferenced by RCU
---------------------------^
+ * initialized array element that will be dereferenced by RCU
Regards,
Jarek P.
^ permalink raw reply
* Re: [PATCH] [RFC] Smack: unlabeled outgoing ambient packets - v2
From: Paul Moore @ 2008-02-12 19:42 UTC (permalink / raw)
To: casey; +Cc: netdev, linux-kernel
In-Reply-To: <47B0E1A1.7090902@schaufler-ca.com>
On Monday 11 February 2008 7:00:33 pm Casey Schaufler wrote:
> This patch differs significantly from the previous version.
> I think that I am using the netlbl interfaces more appropriately,
> Paul, please let me know if there's a better approach.
Nope, this approach is what I was talking about. There are some minor
issues discussed below but they should be easy/quick to fix.
> It's inconvenient that netlbl_sock_setattr frees the domain passed.
> I see that it makes sense for SELinux with the way SELinux treats
> secctx's, but Smack is more careful about memory usage and I have
> to do what I consider a gratuitous kalloc because of this behavior.
> Would you be open to a patch to change this if it included the
> SELinux changes?
I've looked at this before from a SELinux point of view to see if I
could get rid of this extra memory allocation/copy and there just isn't
a clean way to do it ("clean" being very subjective). The problem is
you either have to hold the policy lock while you make the NetLabel
call (not a good idea), move the selinux_netlbl_sock_setsid()
functionality back into security/selinux/ss/services.c (not desired by
the SELinux folks who like to keep the selinux/ss/ directory minimal),
or do the allocatin in security_netlbl_sid_to_secattr() and free it in
selinux_netlbl_sock_setsid(). Of those options, only the last is
really possible and it's so prone to memory leakage that I'm hesitant
to say it's better than what we currently have. Right now you do a
call to netlbl_secattr_init() to start, do what you want with the
secattr, and then you call netlbl_secattr_destroy() which will clean up
_everything_ so nothing is leaked. It works out really well because
all of the _secattr_init() calls are matched by _secattr_destroy()
calls within the same function; very easy to quickly scan and ensure
there are no problems (the memory leak for a few weeks ago was quickly
caught by looking at the code). I'm in no hurry to loose this handy
little property of the secattr, although I do agree that it isn't
optimal for SMACK at present. On the plus side this only happens once
per-socket and not per-packet so I don't expect the malloc/copy to be
fatal at this point.
You've got my mind revisiting this idea so give me a while and let me
see if I can think of something that should be palatable to everyone
involved. In the meantime, I think you should fixup the few little
nits in this patch and get it merged as it is a nice improvement and
something that I believe most SMACK users will want.
> security/smack/smack_lsm.c | 20 ++++++------
> security/smack/smackfs.c | 54
> +++++++++++++++++++++++++---------- 2 files changed, 49
> insertions(+), 25 deletions(-)
>
> diff -uprN -X linux-2.6.25-g0210-base//Documentation/dontdiff
> linux-2.6.25-g0210-base/security/smack/smackfs.c
> linux-2.6.25-g0210/security/smack/smackfs.c ---
> linux-2.6.25-g0210-base/security/smack/smackfs.c 2008-02-10
> 19:30:47.000000000 -0800 +++
> linux-2.6.25-g0210/security/smack/smackfs.c 2008-02-11
> 07:14:54.000000000 -0800 @@ -45,6 +45,7 @@ enum smk_inos {
> */
> static DEFINE_MUTEX(smack_list_lock);
> static DEFINE_MUTEX(smack_cipso_lock);
> +static DEFINE_MUTEX(smack_ambient_lock);
>
> /*
> * This is the "ambient" label for network traffic.
> @@ -363,6 +364,27 @@ void smk_cipso_doi(void)
> __func__, __LINE__, rc);
> }
>
> +/**
> + * smk_unlbl_ambient - initialize the unlabeled domain
> + */
> +void smk_unlbl_ambient(char *oldambient)
> +{
> + int rc;
> + struct netlbl_audit audit_info;
You should try and populate the 'audit_info' struct with actual info so
the generated audit record is more useful for people who care about
those things. It's only two fields, 'secid' and 'loginuid', which are
pretty self-explanatory.
> + if (oldambient != NULL) {
> + rc = netlbl_cfg_map_del(oldambient, &audit_info);
> + if (rc != 0)
> + printk(KERN_WARNING "%s:%d remove rc = %d\n",
> + __func__, __LINE__, rc);
> + }
> +
> + rc = netlbl_cfg_unlbl_add_map(smack_net_ambient, &audit_info);
> + if (rc != 0)
> + printk(KERN_WARNING "%s:%d add rc = %d\n",
> + __func__, __LINE__, rc);
> +}
> +
> /*
> * Seq_file read operations for /smack/cipso
> */
> @@ -709,7 +731,6 @@ static ssize_t smk_read_ambient(struct f
> size_t cn, loff_t *ppos)
> {
> ssize_t rc;
> - char out[SMK_LABELLEN];
> int asize;
>
> if (*ppos != 0)
> @@ -717,23 +738,18 @@ static ssize_t smk_read_ambient(struct f
> /*
> * Being careful to avoid a problem in the case where
> * smack_net_ambient gets changed in midstream.
> - * Since smack_net_ambient is always set with a value
> - * from the label list, including initially, and those
> - * never get freed, the worst case is that the pointer
> - * gets changed just after this strncpy, in which case
> - * the value passed up is incorrect. Locking around
> - * smack_net_ambient wouldn't be any better than this
> - * copy scheme as by the time the caller got to look
> - * at the ambient value it would have cleared the lock
> - * and been changed.
> */
> - strncpy(out, smack_net_ambient, SMK_LABELLEN);
> - asize = strlen(out) + 1;
> + mutex_lock(&smack_ambient_lock);
>
> - if (cn < asize)
> - return -EINVAL;
> + asize = strlen(smack_net_ambient) + 1;
>
> - rc = simple_read_from_buffer(buf, cn, ppos, out, asize);
> + if (cn >= asize)
> + rc = simple_read_from_buffer(buf, cn, ppos,
> + smack_net_ambient, asize);
> + else
> + rc = -EINVAL;
> +
> + mutex_unlock(&smack_ambient_lock);
>
> return rc;
> }
> @@ -751,6 +767,7 @@ static ssize_t smk_write_ambient(struct
> size_t count, loff_t *ppos)
> {
> char in[SMK_LABELLEN];
> + char *oldambient;
> char *smack;
>
> if (!capable(CAP_MAC_ADMIN))
> @@ -766,7 +783,13 @@ static ssize_t smk_write_ambient(struct
> if (smack == NULL)
> return -EINVAL;
>
> + mutex_lock(&smack_ambient_lock);
> +
> + oldambient = smack_net_ambient;
> smack_net_ambient = smack;
> + smk_unlbl_ambient(oldambient);
> +
> + mutex_unlock(&smack_ambient_lock);
There is still the potential for a race here between when you change
the 'smack_net_ambient' value and when you actually change the NetLabel
configuration as you still allow new sockets to be created/labeled
regardless of the 'smack_ambient_lock'. That said, considering that
this is a privileged operation and one that I don't expect to be very
frequent it's probably not a big deal, I just wanted to make sure you
were aware of that.
> return count;
> }
> @@ -974,6 +997,7 @@ static int __init init_smk_fs(void)
>
> sema_init(&smack_write_sem, 1);
> smk_cipso_doi();
> + smk_unlbl_ambient(NULL);
>
> return err;
> }
> diff -uprN -X linux-2.6.25-g0210-base//Documentation/dontdiff
> linux-2.6.25-g0210-base/security/smack/smack_lsm.c
> linux-2.6.25-g0210/security/smack/smack_lsm.c ---
> linux-2.6.25-g0210-base/security/smack/smack_lsm.c 2008-02-10
> 19:30:47.000000000 -0800 +++
> linux-2.6.25-g0210/security/smack/smack_lsm.c 2008-02-10
> 20:10:47.000000000 -0800 @@ -1251,7 +1251,7 @@ static void
> smack_to_secattr(char *smack
>
> switch (smack_net_nltype) {
> case NETLBL_NLTYPE_CIPSOV4:
> - nlsp->domain = NULL;
> + nlsp->domain = kstrdup(smack, GFP_ATOMIC);
> nlsp->flags = NETLBL_SECATTR_DOMAIN;
> nlsp->flags |= NETLBL_SECATTR_MLS_LVL;
Should have noticed this sooner, how about replacing the above two lines
with the following?
nlsp->flags = NETLBL_SECATTR_DOMAIN | NETLBL_SECATTR_MLS_LVL;
> @@ -1276,21 +1276,21 @@ static void smack_to_secattr(char *smack
> * Convert the outbound smack value (smk_out) to a
> * secattr and attach it to the socket.
> *
> - * Returns 0 on success or an error code
> + * The return from netlbl_sock_setattr is ignored because
> + * the defaulting label behavior provided by netlbl takes
> + * care of the error cases.
Not quite ... NetLabel will take care of making sure things are labeled
correctly (default vs. ambient) but it can still fail for a variety of
reasons: memory pressure, labeling protocol cannot represent the
security attributes you passed, etc. Moral of the story, you still
need to check the return value of netlbl_sock_setattr() and deal with
failures in a sane manner.
> */
> -static int smack_netlabel(struct sock *sk)
> +static void smack_netlabel(struct sock *sk)
> {
> struct socket_smack *ssp = sk->sk_security;
> struct netlbl_lsm_secattr secattr;
> - int rc = 0;
> + int rc;
>
> netlbl_secattr_init(&secattr);
> smack_to_secattr(ssp->smk_out, &secattr);
> if (secattr.flags != NETLBL_SECATTR_NONE)
You can keep the above if-statement if you like, but NetLabel handles
this case gracefully (if it doesn't let me know, it's a bug) so it
isn't necessary.
> rc = netlbl_sock_setattr(sk, &secattr);
> -
> netlbl_secattr_destroy(&secattr);
> - return rc;
> }
>
> /**
> @@ -1340,7 +1340,7 @@ static int smack_inode_setsecurity(struc
> ssp->smk_in = sp;
> else if (strcmp(name, XATTR_SMACK_IPOUT) == 0) {
> ssp->smk_out = sp;
> - return smack_netlabel(sock->sk);
> + smack_netlabel(sock->sk);
See above comments regarding return values.
> } else
> return -EOPNOTSUPP;
>
> @@ -1367,7 +1367,8 @@ static int smack_socket_post_create(stru
> /*
> * Set the outbound netlbl.
> */
> - return smack_netlabel(sock->sk);
> + smack_netlabel(sock->sk);
> + return 0;
Same thing.
> }
>
> /**
> @@ -2199,7 +2200,6 @@ static int smack_socket_getpeersec_dgram
> static void smack_sock_graft(struct sock *sk, struct socket *parent)
> {
> struct socket_smack *ssp;
> - int rc;
>
> if (sk == NULL)
> return;
> @@ -2212,7 +2212,7 @@ static void smack_sock_graft(struct sock
> ssp->smk_out = current->security;
> ssp->smk_packet[0] = '\0';
>
> - rc = smack_netlabel(sk);
> + smack_netlabel(sk);
Once more, but with feeling.
> }
>
> /**
--
paul moore
linux security @ hp
^ permalink raw reply
* Re: [PATCH] fib_trie: rcu_assign_pointer warning fix
From: Jarek Poplawski @ 2008-02-12 19:46 UTC (permalink / raw)
To: Paul E. McKenney; +Cc: David Miller, shemminger, netdev, linux-kernel
In-Reply-To: <20080212193218.GA2803@ami.dom.local>
On Tue, Feb 12, 2008 at 08:32:18PM +0100, Jarek Poplawski wrote:
...
> It seems the above version of this macro uses the barrier for 0, but
> if I miss something, or for these other: documenting reasons,
...or __builtin_constants could be used for indexing (?!),
> then of
> course you are right.
Jarek P.
^ permalink raw reply
* Re: e1000e hardware CRC stripping breaks bridging
From: Johan Andersson @ 2008-02-12 20:20 UTC (permalink / raw)
To: Kok, Auke; +Cc: Daniel Drake, netdev, jesse.brandeburg
In-Reply-To: <47B1D697.8030503@intel.com>
Kok, Auke wrote:
> Jesse figured it out. I just send you a patch to test, can you guys give that a
> try and see if it fixes the situation? Johan?
>
> thanks,
>
> Auke
>
Yes, I will test this patch right away.
/Johan
^ permalink raw reply
* Re: [PATCH] Add IPv6 support to TCP SYN cookies
From: Ross Vandegrift @ 2008-02-12 20:38 UTC (permalink / raw)
To: Andi Kleen; +Cc: Glenn Griffin, netdev, linux-kernel
In-Reply-To: <20080208120746.GE4745@one.firstfloor.org>
On Fri, Feb 08, 2008 at 01:07:46PM +0100, Andi Kleen wrote:
> On Thu, Feb 07, 2008 at 02:44:46PM -0500, Ross Vandegrift wrote:
> > On Wed, Feb 06, 2008 at 09:53:57AM +0100, Andi Kleen wrote:
> > My initial test is end-to-end 1000Mbps, but I've got a few different
> > packet rates.
> >
> > > If the young/old heuristics do not work well enough anymore most
> > > likely we should try readding RED to the syn queue again. That used
> > > to be pretty effective in the early days. I don't quite remember why
> > > Linux didn't end up using it in fact.
> >
> > I'm running juno-z with 2, 4, & 8 threads of syn flood to port 80.
> > wireshark measures 2 threads at 350pps, 4 threads at 750pps, and 8
>
> What's the total bandwidth of the attack?
Sorry for the delay in getting back to you on this Andi.
Here's a breakdown for each attack of the pps and bandwidth:
packets/s Mb/s
380 0.182
715 0.343
1193 0.572
16460 7.896
The first three tests were done with some fixed delay inbetween syn
floods. The last is done with all delays as small as possible.
> > threads at 1200pps. Under no SYN flood, the server handles 750 HTTP
> > requests per second, measured via httping in flood mode.
>
> Thanks for the tests. Could you please do an additional experiment?
> Use sch_em or similar to add a jittering longer latency in the connection
> (as would be realistic in a real distributed DOS). Does it make a
> difference?
Jitter on both ends makes it worse. Jitter only on the syn flooder
end behaves approximately the same.
If I add jitter to both the flooder and the target with:
tc qdisc add dev eth0 root netem delay 50ms 100ms distribution normal
I can kill off the host with even a single thread of syn flooding,
even with a backlog queue size of 32768.
> > With a default tcp_max_syn_backlog of 1024, I can trivially prevent
> > any inbound client connections with 2 threads of syn flood.
> > Enabling tcp_syncookies brings the connection handling back up to 725
> > fetches per second.
>
> Yes the defaults are probably too low. That's something that should
> be fixed.
Yea, with a longer queue, the server is somewhat more resiliant. But
it's still pretty easy to overwhelm it. syncookies is a night and day
difference.
> > At these levels the CPU impact of tcp_syncookies is nothing. I can't
>
> CPU impact of syncookies was never a concern. The problems are rather
> missing flow control and disabling of valuable TCP features.
Oh definitely - Willy raised the CPU issue in another mail, I was just
including my findings with a bigger CPU.
In general I agree with you for the TCP features, but in the cases where
we're enabling syncookies, it's the difference between bad connectivity and
no connectivity.
--
Ross Vandegrift
ross@kallisti.us
"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37
^ permalink raw reply
* E1000 (PCI-E) doesn't work on nforce430, MSI issue.
From: Krzysztof Halasa @ 2008-02-12 21:25 UTC (permalink / raw)
To: linux-kernel, netdev
Hi,
Is it a known problem?
Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
e1000e).
Don't work by default. "pci=nomsi" fixes the problem.
82572EI Gigabit Ethernet Controller (Copper) (rev 06)
Subsystem: PRO/1000 PT Desktop Adapter
(8086:10b9 subsystem 8086:1083)
grep eth0 /proc/interrupts
20: 1945 1 IO-APIC-fasteoi eth0
(without "pci=nomsi":
221: 0 0 PCI-MSI-edge eth0)
other devices of possible interest:
00:00.0 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.1 RAM memory: nVidia Corporation C51 Memory Controller 0 (rev a2)
00:00.2 RAM memory: nVidia Corporation C51 Memory Controller 1 (rev a2)
00:00.3 RAM memory: nVidia Corporation C51 Memory Controller 5 (rev a2)
00:00.4 RAM memory: nVidia Corporation C51 Memory Controller 4 (rev a2)
00:00.5 RAM memory: nVidia Corporation C51 Host Bridge (rev a2)
00:00.6 RAM memory: nVidia Corporation C51 Memory Controller 3 (rev a2)
00:00.7 RAM memory: nVidia Corporation C51 Memory Controller 2 (rev a2)
00:03.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:04.0 PCI bridge: nVidia Corporation C51 PCI Express Bridge (rev a1)
00:09.0 RAM memory: nVidia Corporation MCP51 Host Bridge (rev a2)
00:0a.0 ISA bridge: nVidia Corporation MCP51 LPC Bridge (rev a3)
00:0a.1 SMBus: nVidia Corporation MCP51 SMBus (rev a3)
00:0a.2 RAM memory: nVidia Corporation MCP51 Memory Controller 0 (rev a3)
00:10.0 PCI bridge: nVidia Corporation MCP51 PCI Bridge (rev a2)
Additional details on request.
--
Krzysztof Halasa
^ permalink raw reply
* Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.
From: Prakash Punnoor @ 2008-02-12 21:34 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: linux-kernel, netdev
In-Reply-To: <m37ih9ooim.fsf@maximus.localdomain>
[-- Attachment #1: Type: text/plain, Size: 555 bytes --]
On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
> Hi,
>
> Is it a known problem?
> Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
> E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
> e1000e).
>
> Don't work by default. "pci=nomsi" fixes the problem.
Probably the patch to enable msi bit on the host bridge(?) is still missing in
mainline. I needed that patch to make msi work on my MCP51 system.
--
(°= =°)
//\ Prakash Punnoor /\\
V_/ \_V
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* permisions for Ethetool vs rtnetlink
From: Rick Jones @ 2008-02-12 22:08 UTC (permalink / raw)
To: Linux Network Development list
I've been further enhancing the netperf omni tests to enable reporting
stuff like uname for local/remote, the name of the probable egress
interface (rtnetlink), and then driver information for that interface.
I figure that such information being spat-out by netperf might be useful
to have if one were setting-up a database of results and/or making
regression checks and the like.
It struck me as a little odd that I can retrieve routing information for
a destination as a mere mortal, but to retreive driver information for
an interface I have to be priviledged. At first glance I would think
the sensitivity of both sets of information would be about the same?
Is the difference simply an artifact of history?
sincerely,
rick jones
^ permalink raw reply
* [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.
From: Steve Wise @ 2008-02-12 22:09 UTC (permalink / raw)
To: rdreier; +Cc: netdev, linux-kernel, general
RDMA/cxgb3: Fail loopback connections.
The cxgb3 HW and driver don't support loopback RDMA connections. So fail
any connection attempt where the destination address is local.
Signed-off-by: Steve Wise <swise@opengridcomputing.com>
---
drivers/infiniband/hw/cxgb3/iwch_cm.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/drivers/infiniband/hw/cxgb3/iwch_cm.c b/drivers/infiniband/hw/cxgb3/iwch_cm.c
index e9a08fa..5d82723 100644
--- a/drivers/infiniband/hw/cxgb3/iwch_cm.c
+++ b/drivers/infiniband/hw/cxgb3/iwch_cm.c
@@ -1784,6 +1784,17 @@ err:
return err;
}
+static void is_loopback_dst(struct iw_cm_id *cm_id)
+{
+ struct net_device *dev;
+
+ dev = ip_dev_find(&init_net, cm_id->remote_addr.sin_addr.s_addr);
+ if (!dev)
+ return 0;
+ dev_put(dev);
+ return 1;
+}
+
int iwch_connect(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
{
int err = 0;
@@ -1791,6 +1802,11 @@ int iwch_connect(struct iw_cm_id *cm_id, struct iw_cm_conn_param *conn_param)
struct iwch_ep *ep;
struct rtable *rt;
+ if (is_loopback_dst(cm_id)) {
+ err = -ENOSYS;
+ goto out;
+ }
+
ep = alloc_ep(sizeof(*ep), GFP_KERNEL);
if (!ep) {
printk(KERN_ERR MOD "%s - cannot alloc ep.\n", __FUNCTION__);
^ permalink raw reply related
* Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.
From: Kok, Auke @ 2008-02-12 22:24 UTC (permalink / raw)
To: Prakash Punnoor; +Cc: Krzysztof Halasa, linux-kernel, netdev
In-Reply-To: <200802122234.47164.prakash@punnoor.de>
Prakash Punnoor wrote:
> On the day of Tuesday 12 February 2008 Krzysztof Halasa hast written:
>> Hi,
>>
>> Is it a known problem?
>> Linux 2.6.24.2, ASUS M2NPV-MX mobo, nforce 430 based, two PCI-E x1
>> E1000 cards, 32-bit kernel, default e1000 driver (PCI IDs disabled in
>> e1000e).
your card will work with e1000e from 2.6.25 onwards.
>> Don't work by default. "pci=nomsi" fixes the problem.
actually does not fix anything - it just works around it by falling back to legacy
interrupts.
> Probably the patch to enable msi bit on the host bridge(?) is still missing in
> mainline. I needed that patch to make msi work on my MCP51 system.
and there have been many more reports. unfortunately e1000 cards are one of the
few things that actually uses MSI. It works great except for a few problematic
motherboards, and the ones mentioned in this thread fall amongst them.
Auke
^ permalink raw reply
* Re: r8169 auto-negotiation problem
From: Francois Romieu @ 2008-02-12 22:20 UTC (permalink / raw)
To: fgnijuhhu guduggurehug; +Cc: netdev
In-Reply-To: <BAY107-W2892B3D06485CBB5AEDCC2D52B0@phx.gbl>
fgnijuhhu guduggurehug <jsmiths1234@live.com> :
> > fgnijuhhu guduggurehug :
> > [...]
> >> I already posted my problem and what I did to solve it on
> >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461429.
> >
> > Have you tried anything more recent than a 2.6.18 based kernel ?
>
> No, but if changes were made to the iniatialization of the chipset
> in the current driver (mine was 2.2LK), this might do the trick.
Please try a recent kernel. Your r8169 driver is badly outdated.
[...]
> Anyway, how to best upgrade the kernel in debian (without problems,
> of course) ? The problem right now is that every apt-get upgrade
> reverts the r8169 driver to the old one...
I do not use debian but you can read:
http://www.google.com/search?q=debian+kernel+upgrade
--
Ueimor
^ permalink raw reply
* [PATCH] libertas: Remove unused exports
From: Roland Dreier @ 2008-02-12 23:08 UTC (permalink / raw)
To: John W. Linville; +Cc: netdev, Dan Williams
In-Reply-To: <adatzkj0z7l.fsf@cisco.com>
The libertas driver exports a number of symbols with no in-tree
users; remove these unused exports. lbs_reset_device() is completely
unused, with no callers at all, so remove the function completely.
A couple of these unused exported symbols are static, which causes the
following build error on ia64 with gcc 4.2.3:
drivers/net/wireless/libertas/main.c:1375: error: __ksymtab_lbs_remove_mesh causes a section type conflict
drivers/net/wireless/libertas/main.c:1354: error: __ksymtab_lbs_add_mesh causes a section type conflict
This patch fixes this problem. I don't have hardware, so this is not
run-tested, but I tested the build with
CONFIG_LIBERTAS=y
CONFIG_LIBERTAS_USB=m
CONFIG_LIBERTAS_CS=m
CONFIG_LIBERTAS_SDIO=m
and there were no problems with undefined symbols.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
---
Here's the patch that removes the unused exports (and a few more that
I found).
diff --git a/drivers/net/wireless/libertas/cmd.c b/drivers/net/wireless/libertas/cmd.c
index eab0203..b3c1acb 100644
--- a/drivers/net/wireless/libertas/cmd.c
+++ b/drivers/net/wireless/libertas/cmd.c
@@ -1040,7 +1040,6 @@ int lbs_mesh_access(struct lbs_private *priv, uint16_t cmd_action,
lbs_deb_leave(LBS_DEB_CMD);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_mesh_access);
int lbs_mesh_config(struct lbs_private *priv, uint16_t enable, uint16_t chan)
{
@@ -1576,7 +1575,6 @@ done:
lbs_deb_leave_args(LBS_DEB_HOST, "ret %d", ret);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_prepare_and_send_command);
/**
* @brief This function allocates the command buffer and link
diff --git a/drivers/net/wireless/libertas/decl.h b/drivers/net/wireless/libertas/decl.h
index aaacd9b..4e22341 100644
--- a/drivers/net/wireless/libertas/decl.h
+++ b/drivers/net/wireless/libertas/decl.h
@@ -69,7 +69,6 @@ struct lbs_private *lbs_add_card(void *card, struct device *dmdev);
int lbs_remove_card(struct lbs_private *priv);
int lbs_start_card(struct lbs_private *priv);
int lbs_stop_card(struct lbs_private *priv);
-int lbs_reset_device(struct lbs_private *priv);
void lbs_host_to_card_done(struct lbs_private *priv);
int lbs_update_channel(struct lbs_private *priv);
diff --git a/drivers/net/wireless/libertas/main.c b/drivers/net/wireless/libertas/main.c
index 84fb49c..1eaf6af 100644
--- a/drivers/net/wireless/libertas/main.c
+++ b/drivers/net/wireless/libertas/main.c
@@ -1351,8 +1350,6 @@ done:
lbs_deb_leave_args(LBS_DEB_MESH, "ret %d", ret);
return ret;
}
-EXPORT_SYMBOL_GPL(lbs_add_mesh);
-
static void lbs_remove_mesh(struct lbs_private *priv)
{
@@ -1372,7 +1369,6 @@ static void lbs_remove_mesh(struct lbs_private *priv)
free_netdev(mesh_dev);
lbs_deb_leave(LBS_DEB_MESH);
}
-EXPORT_SYMBOL_GPL(lbs_remove_mesh);
/**
* @brief This function finds the CFP in
@@ -1458,20 +1454,6 @@ void lbs_interrupt(struct lbs_private *priv)
}
EXPORT_SYMBOL_GPL(lbs_interrupt);
-int lbs_reset_device(struct lbs_private *priv)
-{
- int ret;
-
- lbs_deb_enter(LBS_DEB_MAIN);
- ret = lbs_prepare_and_send_command(priv, CMD_802_11_RESET,
- CMD_ACT_HALT, 0, 0, NULL);
- msleep_interruptible(10);
-
- lbs_deb_leave_args(LBS_DEB_MAIN, "ret %d", ret);
- return ret;
-}
-EXPORT_SYMBOL_GPL(lbs_reset_device);
-
static int __init lbs_init_module(void)
{
lbs_deb_enter(LBS_DEB_MAIN);
^ permalink raw reply related
* [PATCH] e1000e: Fix CRC stripping in hardware context bug
From: Auke Kok @ 2008-02-12 23:20 UTC (permalink / raw)
To: jeff; +Cc: e1000-devel, netdev, andy, johan.andersson
CRC stripping was only correctly enabled for packet split recieves
which is used when receiving jumbo frames. Correctly enable SECRC
also for normal buffer packet receives.
Tested by Andy Gospodarek and Johan Andersson, see bugzilla #9940.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/e1000e/netdev.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
index b9b0d32..ea4ecc3 100644
--- a/drivers/net/e1000e/netdev.c
+++ b/drivers/net/e1000e/netdev.c
@@ -1690,6 +1690,9 @@ static void e1000_setup_rctl(struct e1000_adapter *adapter)
else
rctl |= E1000_RCTL_LPE;
+ /* Enable hardware CRC frame stripping */
+ rctl |= E1000_RCTL_SECRC;
+
/* Setup buffer sizes */
rctl &= ~E1000_RCTL_SZ_4096;
rctl |= E1000_RCTL_BSEX;
@@ -1755,9 +1758,6 @@ static void e1000_setup_rctl(struct e1000_adapter *adapter)
/* Enable Packet split descriptors */
rctl |= E1000_RCTL_DTYP_PS;
-
- /* Enable hardware CRC frame stripping */
- rctl |= E1000_RCTL_SECRC;
psrctl |= adapter->rx_ps_bsize0 >>
E1000_PSRCTL_BSIZE0_SHIFT;
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
^ permalink raw reply related
* [PATCH] ixgbe: Correctly obtain protocol information on transmit
From: Auke Kok @ 2008-02-12 23:20 UTC (permalink / raw)
To: jeff; +Cc: netdev, andy, e1000-devel
In reply to "RE: [Fwd: [PATCH 2.6.25] ixgbe/igb: correctly obtain protocol
information on transmit]" from Andy Gospodarek:
The driver was incorrectly looking at socket headers for
protocol information, needed for checksumming offload. Fix
this by not looking at the socket but frame headers instead.
This disregards extension headers but it's unclear that linux
generates those anyway.
Tested by Andy Gospodarek.
Signed-off-by: Auke Kok <auke-jan.h.kok@intel.com>
---
drivers/net/ixgbe/ixgbe_main.c | 24 +++++++++++++++++++++---
1 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ixgbe/ixgbe_main.c b/drivers/net/ixgbe/ixgbe_main.c
index 540b647..23d0a4a 100644
--- a/drivers/net/ixgbe/ixgbe_main.c
+++ b/drivers/net/ixgbe/ixgbe_main.c
@@ -2277,11 +2277,29 @@ static bool ixgbe_tx_csum(struct ixgbe_adapter *adapter,
IXGBE_ADVTXD_DTYP_CTXT);
if (skb->ip_summed == CHECKSUM_PARTIAL) {
- if (skb->protocol == htons(ETH_P_IP))
+ switch (skb->protocol) {
+ case __constant_htons(ETH_P_IP):
type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_IPV4;
+ if (ip_hdr(skb)->protocol == IPPROTO_TCP)
+ type_tucmd_mlhl |=
+ IXGBE_ADVTXD_TUCMD_L4T_TCP;
+ break;
+
+ case __constant_htons(ETH_P_IPV6):
+ /* XXX what about other V6 headers?? */
+ if (ipv6_hdr(skb)->nexthdr == IPPROTO_TCP)
+ type_tucmd_mlhl |=
+ IXGBE_ADVTXD_TUCMD_L4T_TCP;
+ break;
- if (skb->sk->sk_protocol == IPPROTO_TCP)
- type_tucmd_mlhl |= IXGBE_ADVTXD_TUCMD_L4T_TCP;
+ default:
+ if (unlikely(net_ratelimit())) {
+ DPRINTK(PROBE, WARNING,
+ "partial checksum but proto=%x!\n",
+ skb->protocol);
+ }
+ break;
+ }
}
context_desc->type_tucmd_mlhl = cpu_to_le32(type_tucmd_mlhl);
^ permalink raw reply related
* RE: [PATCH resend] qla3xxx: convert byte order of constant instead ofvariable
From: Ron Mercer @ 2008-02-12 23:36 UTC (permalink / raw)
To: Marcin Slusarz, netdev, Linux Driver; +Cc: LKML
In-Reply-To: <20080210100546.GA6737@joi>
> -----Original Message-----
> From: Marcin Slusarz [mailto:marcin.slusarz@gmail.com]
> Sent: Sunday, February 10, 2008 2:06 AM
> To: netdev@vger.kernel.org; Linux Driver
> Cc: LKML
> Subject: [PATCH resend] qla3xxx: convert byte order of
> constant instead ofvariable
>
> convert byte order of constant instead of variable
> which can be done at compile time (vs run time)
>
> Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
> ---
> drivers/net/qla3xxx.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/qla3xxx.c b/drivers/net/qla3xxx.c
> index a6aeb9d..b7f7b22 100644
> --- a/drivers/net/qla3xxx.c
> +++ b/drivers/net/qla3xxx.c
> @@ -2472,8 +2472,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
>
> if (seg_cnt == 1) {
> /* Terminate the last segment. */
> - oal_entry->len =
> - cpu_to_le32(le32_to_cpu(oal_entry->len) |
> OAL_LAST_ENTRY);
> + oal_entry->len |= cpu_to_le32(OAL_LAST_ENTRY);
> } else {
> oal = tx_cb->oal;
> for (completed_segs=0; completed_segs<frag_cnt;
> completed_segs++,seg++) {
> @@ -2530,8 +2529,7 @@ static int ql_send_map(struct ql3_adapter *qdev,
> frag->size);
> }
> /* Terminate the last segment. */
> - oal_entry->len =
> - cpu_to_le32(le32_to_cpu(oal_entry->len) |
> OAL_LAST_ENTRY);
> + oal_entry->len |= cpu_to_le32(OAL_LAST_ENTRY);
> }
>
> return NETDEV_TX_OK;
> --
> 1.5.3.7
>
>
Thanks
Acked-by: Ron Mercer <ron.mercer@qlogic.com>
^ permalink raw reply
* [IPV6]: Fix IPsec datagram fragmentation
From: Herbert Xu @ 2008-02-13 0:04 UTC (permalink / raw)
To: David S. Miller, YOSHIFUJI Hideaki, netdev; +Cc: dlstevens, Kazunori Miyazawa
Hi Dave:
[IPV6]: Fix IPsec datagram fragmentation
This is a long-standing bug in the IPsec IPv6 code that breaks
when we emit a IPsec tunnel-mode datagram packet. The problem
is that the code the emits the packet assumes the IPv6 stack
will fragment it later, but the IPv6 stack assumes that whoever
is emitting the packet is going to pre-fragment the packet.
In the long term we need to fix both sides, e.g., to get the
datagram code to pre-fragment as well as to get the IPv6 stack
to fragment locally generated tunnel-mode packet.
For now this patch does the second part which should make it
work for the IPsec host case.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 9ac6ca2..4e9a2fe 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -621,7 +621,7 @@ static int ip6_fragment(struct sk_buff *skb, int (*output)(struct sk_buff *))
* or if the skb it not generated by a local socket. (This last
* check should be redundant, but it's free.)
*/
- if (!np || np->pmtudisc >= IPV6_PMTUDISC_DO) {
+ if (skb->local_df) {
skb->dev = skb->dst->dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev);
IP6_INC_STATS(ip6_dst_idev(skb->dst), IPSTATS_MIB_FRAGFAILS);
@@ -1420,6 +1420,10 @@ int ip6_push_pending_frames(struct sock *sk)
tmp_skb->sk = NULL;
}
+ /* Allow local fragmentation. */
+ if (np->pmtudisc >= IPV6_PMTUDISC_DO)
+ skb->local_df = 1;
+
ipv6_addr_copy(final_dst, &fl->fl6_dst);
__skb_pull(skb, skb_network_header_len(skb));
if (opt && opt->opt_flen)
diff --git a/net/ipv6/xfrm6_output.c b/net/ipv6/xfrm6_output.c
index b34c58c..79ccfb0 100644
--- a/net/ipv6/xfrm6_output.c
+++ b/net/ipv6/xfrm6_output.c
@@ -36,7 +36,7 @@ static int xfrm6_tunnel_check_size(struct sk_buff *skb)
if (mtu < IPV6_MIN_MTU)
mtu = IPV6_MIN_MTU;
- if (skb->len > mtu) {
+ if (!skb->local_df && skb->len > mtu) {
skb->dev = dst->dev;
icmpv6_send(skb, ICMPV6_PKT_TOOBIG, 0, mtu, skb->dev);
ret = -EMSGSIZE;
^ permalink raw reply related
* Re: E1000 (PCI-E) doesn't work on nforce430, MSI issue.
From: Krzysztof Halasa @ 2008-02-13 0:05 UTC (permalink / raw)
To: Kok, Auke; +Cc: Prakash Punnoor, linux-kernel, netdev
In-Reply-To: <47B21C95.4050705@intel.com>
"Kok, Auke" <auke-jan.h.kok@intel.com> writes:
>>> Don't work by default. "pci=nomsi" fixes the problem.
>
> actually does not fix anything - it just works around it by falling
> back to legacy interrupts.
Actually it does, fixes the problem by working around a bug :-)
Thanks for info.
--
Krzysztof Halasa
^ permalink raw reply
* Re: [ofa-general] [PATCH 2.6.25] RDMA/cxgb3: Fail loopback connections.
From: Roland Dreier @ 2008-02-13 0:26 UTC (permalink / raw)
To: Steve Wise; +Cc: netdev, linux-kernel, general
In-Reply-To: <20080212220929.24442.76874.stgit@dell3.ogc.int>
applied, although:
> +static void is_loopback_dst(struct iw_cm_id *cm_id)
> +{
> + struct net_device *dev;
> +
> + dev = ip_dev_find(&init_net, cm_id->remote_addr.sin_addr.s_addr);
> + if (!dev)
> + return 0;
> + dev_put(dev);
> + return 1;
> +}
is there any way this could trigger when it should, like if I'm trying
to make a connection from one local device to a different local device
(which should work fine)?
- R.
^ permalink raw reply
* [PATCH 1/4] rcu_assign_pointer: null check fix
From: Stephen Hemminger @ 2008-02-13 0:50 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev
In-Reply-To: <20080213005042.150212716@vyatta.com>
[-- Attachment #1: rcu-assign-warn.patch --]
[-- Type: text/plain, Size: 637 bytes --]
Goofed on last change, should avoid barrier only on rcu_assign_pointer(p, NULL)
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
include/linux/rcupdate.h | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
--- a/include/linux/rcupdate.h 2008-02-12 14:46:49.000000000 -0800
+++ b/include/linux/rcupdate.h 2008-02-12 14:56:17.000000000 -0800
@@ -178,7 +178,7 @@ struct rcu_head {
#define rcu_assign_pointer(p, v) \
({ \
- if (!(__builtin_constant_p(v) && v)) \
+ if (!__builtin_constant_p(v) || v) \
smp_wmb(); \
(p) = (v); \
})
--
Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* [PATCH 2/4] fib_trie: improve output format for /proc/net/fib_trie
From: Stephen Hemminger @ 2008-02-13 0:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20080213005042.150212716@vyatta.com>
[-- Attachment #1: fib-trie-format.patch --]
[-- Type: text/plain, Size: 5136 bytes --]
Make output format prettier (more tree like).
<local>:
--- 0.0.0.0/0
|--- 10.111.111.0/24
| +-- 10.111.111.0/32 link broadcast
| |--- 10.111.111.254/31
| | +-- 10.111.111.254/32 host local
| | +-- 10.111.111.255/32 link broadcast
|--- 127.0.0.0/8
| |--- 127.0.0.0/31
| | +-- 127.0.0.0/32 link broadcast
| | +-- 127.0.0.0/8 host local
| | +-- 127.0.0.1/32 host local
| +-- 127.255.255.255/32 link broadcast
|--- 192.168.1.0/24
| |--- 192.168.1.0/28
| | +-- 192.168.1.0/32 link broadcast
| | +-- 192.168.1.9/32 host local
| +-- 192.168.1.255/32 link broadcast
<main>:
--- 0.0.0.0/0
|--- 0.0.0.0/4
| +-- 0.0.0.0/0 universe unicast
| +-- 10.111.111.0/24 link unicast
+-- 169.254.0.0/16 link unicast
+-- 192.168.1.0/24 link unicast
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
net/ipv4/fib_trie.c | 106 ++++++++++++++++++++++++++------------------------
1 files changed, 55 insertions(+), 51 deletions(-)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index 1ff446d..72338cd 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -2340,46 +2340,57 @@ static void fib_trie_seq_stop(struct seq_file *seq, void *v)
rcu_read_unlock();
}
+/* print left side of tree */
static void seq_indent(struct seq_file *seq, int n)
{
- while (n-- > 0) seq_puts(seq, " ");
-}
-
-static inline const char *rtn_scope(char *buf, size_t len, enum rt_scope_t s)
-{
- switch (s) {
- case RT_SCOPE_UNIVERSE: return "universe";
- case RT_SCOPE_SITE: return "site";
- case RT_SCOPE_LINK: return "link";
- case RT_SCOPE_HOST: return "host";
- case RT_SCOPE_NOWHERE: return "nowhere";
- default:
- snprintf(buf, len, "scope=%d", s);
- return buf;
- }
+ while (n-- > 0)
+ seq_puts(seq, " |");
}
static const char *rtn_type_names[__RTN_MAX] = {
- [RTN_UNSPEC] = "UNSPEC",
- [RTN_UNICAST] = "UNICAST",
- [RTN_LOCAL] = "LOCAL",
- [RTN_BROADCAST] = "BROADCAST",
- [RTN_ANYCAST] = "ANYCAST",
- [RTN_MULTICAST] = "MULTICAST",
- [RTN_BLACKHOLE] = "BLACKHOLE",
- [RTN_UNREACHABLE] = "UNREACHABLE",
- [RTN_PROHIBIT] = "PROHIBIT",
- [RTN_THROW] = "THROW",
- [RTN_NAT] = "NAT",
- [RTN_XRESOLVE] = "XRESOLVE",
+ [RTN_UNSPEC] = "unspec",
+ [RTN_UNICAST] = "unicast",
+ [RTN_LOCAL] = "local",
+ [RTN_BROADCAST] = "broadcast",
+ [RTN_ANYCAST] = "anycast",
+ [RTN_MULTICAST] = "multicast",
+ [RTN_BLACKHOLE] = "blackhole",
+ [RTN_UNREACHABLE] = "unreachable",
+ [RTN_PROHIBIT] = "prohibit",
+ [RTN_THROW] = "throw",
+ [RTN_NAT] = "nat",
+ [RTN_XRESOLVE] = "xresolve",
};
-static inline const char *rtn_type(char *buf, size_t len, unsigned t)
-{
- if (t < __RTN_MAX && rtn_type_names[t])
- return rtn_type_names[t];
- snprintf(buf, len, "type %u", t);
- return buf;
+static void fib_trie_show_alias(struct seq_file *seq, const struct fib_alias *fa)
+{
+ switch (fa->fa_scope) {
+ case RT_SCOPE_UNIVERSE:
+ seq_puts(seq, "universe");
+ break;
+ case RT_SCOPE_SITE:
+ seq_puts(seq, "site");
+ break;
+ case RT_SCOPE_LINK:
+ seq_puts(seq, "link");
+ break;
+ case RT_SCOPE_HOST:
+ seq_puts(seq, "host");
+ break;
+ case RT_SCOPE_NOWHERE:
+ seq_puts(seq, "nowhere");
+ break;
+ default:
+ seq_printf(seq, "scope:%d", fa->fa_scope);
+ }
+
+ if (fa->fa_type < __RTN_MAX && rtn_type_names[fa->fa_type])
+ seq_printf(seq, " %s", rtn_type_names[fa->fa_type]);
+ else
+ seq_printf(seq, " type:%u", fa->fa_type);
+
+ if (fa->fa_tos)
+ seq_printf(seq, " tos:%#x", fa->fa_tos);
}
/* Pretty print the trie */
@@ -2402,10 +2413,8 @@ static int fib_trie_seq_show(struct seq_file *seq, void *v)
struct tnode *tn = (struct tnode *) n;
__be32 prf = htonl(mask_pfx(tn->key, tn->pos));
- seq_indent(seq, iter->depth-1);
- seq_printf(seq, " +-- %d.%d.%d.%d/%d %d %d %d\n",
- NIPQUAD(prf), tn->pos, tn->bits, tn->full_children,
- tn->empty_children);
+ seq_indent(seq, iter->depth - 1);
+ seq_printf(seq, "--- %d.%d.%d.%d/%d\n", NIPQUAD(prf), tn->pos);
} else {
struct leaf *l = (struct leaf *) n;
@@ -2413,24 +2422,19 @@ static int fib_trie_seq_show(struct seq_file *seq, void *v)
struct hlist_node *node;
__be32 val = htonl(l->key);
- seq_indent(seq, iter->depth);
- seq_printf(seq, " |-- %d.%d.%d.%d\n", NIPQUAD(val));
-
hlist_for_each_entry_rcu(li, node, &l->list, hlist) {
struct fib_alias *fa;
+
+ seq_indent(seq, iter->depth - 1);
+ seq_printf(seq, " +-- %d.%d.%d.%d/%d ",
+ NIPQUAD(val), li->plen);
list_for_each_entry_rcu(fa, &li->falh, fa_list) {
- char buf1[32], buf2[32];
-
- seq_indent(seq, iter->depth+1);
- seq_printf(seq, " /%d %s %s", li->plen,
- rtn_scope(buf1, sizeof(buf1),
- fa->fa_scope),
- rtn_type(buf2, sizeof(buf2),
- fa->fa_type));
- if (fa->fa_tos)
- seq_printf(seq, " tos=%d", fa->fa_tos);
- seq_putc(seq, '\n');
+ fib_trie_show_alias(seq, fa);
+ if (list_is_last(&fa->fa_list, &li->falh))
+ seq_putc(seq, '\n');
+ else
+ seq_puts(seq, ", ");
}
}
}
--
1.5.3.8
--
Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply related
* Re: [PATCH 4/4] hlist_for_each_entry_continue simplification
From: David Miller @ 2008-02-13 1:26 UTC (permalink / raw)
To: shemminger; +Cc: paulmck, netdev, linux-kernel
In-Reply-To: <20080213005122.879352336@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 12 Feb 2008 16:50:46 -0800
> All the users of hlist_for_each_entry_continue had to intialize pos
> before use; change API so pos is a pure temporary variable which matches
> the usage of other xxxx_for_each_entry routines.
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
linux/list.h changes need to be reviewed on linux-kernel and
merged into Linus's tree via some means other than the
networking tree.
I just got chewed out for a similar issue wrt. the rcupdate.h
changes of yesterday and thus have to remove them from my
tree.
^ permalink raw reply
* Re: [PATCH 1/4] rcu_assign_pointer: null check fix
From: David Miller @ 2008-02-13 1:27 UTC (permalink / raw)
To: shemminger; +Cc: linux-kernel, netdev
In-Reply-To: <20080213005122.653836965@vyatta.com>
From: Stephen Hemminger <shemminger@vyatta.com>
Date: Tue, 12 Feb 2008 16:50:43 -0800
> Goofed on last change, should avoid barrier only on rcu_assign_pointer(p, NULL)
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Like the original change this needs to be merged upstream outside of
the networking tree, sorry.
^ permalink raw reply
* [PATCH BUGFIX 25-rc1] Smack: Don't fail against Nulled sk sockets
From: Ahmed S. Darwish @ 2008-02-13 1:25 UTC (permalink / raw)
To: Andrew Morton, Linus Torvalds; +Cc: Casey Schaufler, Joerg Platte, LKML, Netdev
Hi!,
Appropriately handle sockets with sk = NULL. This is usually the socket
case when starting kernel nfsd.
Signed-off-by: Ahmed S. Darwish <darwish.07@gmail.com>
Acked-by: Casey Schaufler <casey@schuafler-ca.com>
Tested-by: Joerg Platte <jplatte@naasa.net>
--
diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
index 1c11e42..eb04278 100644
--- a/security/smack/smack_lsm.c
+++ b/security/smack/smack_lsm.c
@@ -701,7 +701,7 @@ static int smack_inode_getsecurity(const struct inode *inode,
return -EOPNOTSUPP;
sock = SOCKET_I(ip);
- if (sock == NULL)
+ if (sock == NULL || sock->sk == NULL)
return -EOPNOTSUPP;
ssp = sock->sk->sk_security;
@@ -1280,10 +1280,12 @@ static void smack_to_secattr(char *smack, struct netlbl_lsm_secattr *nlsp)
*/
static int smack_netlabel(struct sock *sk)
{
- struct socket_smack *ssp = sk->sk_security;
+ struct socket_smack *ssp;
struct netlbl_lsm_secattr secattr;
int rc = 0;
+ BUG_ON(sk == NULL);
+ ssp = sk->sk_security;
netlbl_secattr_init(&secattr);
smack_to_secattr(ssp->smk_out, &secattr);
if (secattr.flags != NETLBL_SECATTR_NONE)
@@ -1331,7 +1333,7 @@ static int smack_inode_setsecurity(struct inode *inode, const char *name,
return -EOPNOTSUPP;
sock = SOCKET_I(inode);
- if (sock == NULL)
+ if (sock == NULL || sock->sk == NULL)
return -EOPNOTSUPP;
ssp = sock->sk->sk_security;
@@ -1362,7 +1364,7 @@ static int smack_inode_setsecurity(struct inode *inode, const char *name,
static int smack_socket_post_create(struct socket *sock, int family,
int type, int protocol, int kern)
{
- if (family != PF_INET)
+ if (family != PF_INET || sock->sk == NULL)
return 0;
/*
* Set the outbound netlbl.
Warm regards
--
Ahmed S. Darwish
Homepage: http://darwish.07.googlepages.com
Blog: http://darwish-07.blogspot.com
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox