Brandeburg, Jesse | 1 Oct 2008 01:08
Picon
Favicon

Re: Regression: ixgb warning on MTU change

On Wed, 24 Sep 2008, Breno Leitao wrote:
> I just found an issue related to ixgb that seems to be a regression.
> After the interface is up and running (packets already transmitted), if
> I try to change the MTU, running "ifconfig ethX mtu 70", for example,
> causes the following warning[1].
> 
> Bisecting I found that the commit that caused this warning is
> fc2d14e36c69a8d44a2f5230835b54e95025363e. Reverting it solves the
> problem, ie, no more warnings.
> 
> Digging further, I found that just removing the following line added
> by fc2d14e36c69a8d44a2f5230835b54e95025363e's patch
> "buffer_info->dma = 0;", also solves the problem.
> 

Thanks for the report, I think this patch should fix it.  Please test and 
let us know.  This was compile tested only.

----

From: Jesse Brandeburg <jesse.brandeburg <at> intel.com>

ixgb: fix bug when freeing resources

It was pointed out by Breno Leitao <leitao <at> linux.vnet.ibm.com> that
ixgb would crash on PPC when an IOMMU was in use, if change_mtu was
called.

It appears to be a pretty simple issue in the driver that wasn't discovered
because most systems don't run with an IOMMU.  The driver needs to only unmap
(Continue reading)

Bernhard Schmidt | 1 Oct 2008 01:30
Picon

Re: g3 + HP iLO2 -> IPv6 broken

On Tue, Sep 30, 2008 at 03:53:34PM -0700, Matt Carlson wrote:

> It sounds like the iLO2 firmware is messing around with the rx filter.
> I've heard of problems like this before with another management agent.
> 
> Can you give me the output to 'ethtool -i <device>' and the iLO2
> firmware version?

svr01:~# ethtool -i eth0
driver: tg3
version: 3.94
firmware-version: 5715-v3.28, UMP 1.15
bus-info: 0000:03:04.0

iLO 2 Standard 1.60 at 16:05:58 Jul 11 2008
Server Name: DL320G5P0200
Server Power: On

Regards,
Bernhard
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Arnaldo Carvalho de Melo | 1 Oct 2008 03:18
Picon
Favicon

Re: [PATCH net-next] ipv6: almost identical frag hashing funcs combined

Em Wed, Oct 01, 2008 at 01:57:47AM +0300, Ilpo Järvinen escreveu:
> 
> $ diff-funcs ip6qhashfn reassembly.c netfilter/nf_conntrack_reasm.c
>  --- reassembly.c:ip6qhashfn()
>  +++ netfilter/nf_conntrack_reasm.c:ip6qhashfn()
>  <at>  <at>  -1,5 +1,5  <at>  <at> 
> -static unsigned int ip6qhashfn(__be32 id, struct in6_addr *saddr,
> -			       struct in6_addr *daddr)
> +static unsigned int ip6qhashfn(__be32 id, const struct in6_addr *saddr,
> +			       const struct in6_addr *daddr)
>  {
>  	u32 a, b, c;
> 
>  <at>  <at>  -9,7 +9,7  <at>  <at> 
> 
>  	a += JHASH_GOLDEN_RATIO;
>  	b += JHASH_GOLDEN_RATIO;
> -	c += ip6_frags.rnd;
> +	c += nf_frags.rnd;
>  	__jhash_mix(a, b, c);
> 
>  	a += (__force u32)saddr->s6_addr32[3];
> 
> And codiff xx.o.old xx.o.new:
> 
> net/ipv6/netfilter/nf_conntrack_reasm.c:
>   ip6qhashfn         | -512
>   nf_hashfn          |   +6
>   nf_ct_frag6_gather |  +36
>  3 functions changed, 42 bytes added, 512 bytes removed, diff: -470
(Continue reading)

James Morris | 1 Oct 2008 03:34
Favicon

Re: [RFC PATCH v6 00/16] Labeled networking patches for 2.6.28

I found some sparse warnings -- the last couple at least may need 
attention:

$ make C=2 CF="-D__cold__=" SUBDIRS=net/netlabel

  CHECK   net/netlabel/netlabel_user.c
  CC      net/netlabel/netlabel_user.o
  CHECK   net/netlabel/netlabel_kapi.c
  CC      net/netlabel/netlabel_kapi.o
  CHECK   net/netlabel/netlabel_domainhash.c
net/netlabel/netlabel_domainhash.c:143:3: warning: symbol '_________p1' shadows an earlier one
net/netlabel/netlabel_domainhash.c:143:3: originally declared here
net/netlabel/netlabel_domainhash.c:143:3: warning: symbol '_________p1' shadows an earlier one
net/netlabel/netlabel_domainhash.c:143:3: originally declared here
net/netlabel/netlabel_domainhash.c:635:3: warning: symbol '_________p1' shadows an earlier one
net/netlabel/netlabel_domainhash.c:635:3: originally declared here
net/netlabel/netlabel_domainhash.c:635:3: warning: symbol '_________p1' shadows an earlier one
net/netlabel/netlabel_domainhash.c:635:3: originally declared here
  CC      net/netlabel/netlabel_domainhash.o
  CHECK   net/netlabel/netlabel_addrlist.c
  CC      net/netlabel/netlabel_addrlist.o
  CHECK   net/netlabel/netlabel_mgmt.c
  CC      net/netlabel/netlabel_mgmt.o
  CHECK   net/netlabel/netlabel_unlabeled.c
net/netlabel/netlabel_unlabeled.c:265:2: warning: symbol '_________p1' shadows an earlier one
net/netlabel/netlabel_unlabeled.c:265:2: originally declared here
net/netlabel/netlabel_unlabeled.c:265:2: warning: symbol '_________p1' shadows an earlier one
net/netlabel/netlabel_unlabeled.c:265:2: originally declared here
net/netlabel/netlabel_unlabeled.c:1282:3: warning: symbol '_________p1' shadows an earlier one
net/netlabel/netlabel_unlabeled.c:1282:3: originally declared here
(Continue reading)

James Morris | 1 Oct 2008 03:35
Favicon

Re: [RFC PATCH v6 01/16] selinux: Cleanup the NetLabel glue code

On Tue, 16 Sep 2008, Paul Moore wrote:

> We were doing a lot of extra work in selinux_netlbl_sock_graft() what wasn't
> necessary so this patch removes that code.  It also removes the redundant
> second argument to selinux_netlbl_sock_setsid() which allows us to simplify a
> few other functions.
> 
> Signed-off-by: Paul Moore <paul.moore <at> hp.com>

Nice cleanup :-)

Acked-by: James Morris <jmorris <at> namei.org>

--

-- 
James Morris
<jmorris <at> namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

James Morris | 1 Oct 2008 03:36
Favicon

Re: [RFC PATCH v6 02/16] selinux: Correctly handle IPv4 packets on IPv6 sockets in all cases

On Tue, 16 Sep 2008, Paul Moore wrote:

> We did the right thing in a few cases but there were several areas where we
> determined a packet's address family based on the socket's address family which
> is not the right thing to do since we can get IPv4 packets on IPv6 sockets.
> This patch fixes these problems by either taking the address family directly
> from the packet.
> 
> Signed-off-by: Paul Moore <paul.moore <at> hp.com>

Acked-by: James Morris <jmorris <at> namei.org>

--

-- 
James Morris
<jmorris <at> namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

James Morris | 1 Oct 2008 03:38
Favicon

Re: [RFC PATCH v6 03/16] netlabel: Remove unneeded in-kernel API functions

On Tue, 16 Sep 2008, Paul Moore wrote:

> After some discussions with the Smack folks, well just Casey, I now have a
> better idea of what Smack wants out of NetLabel in the future so I think it
> is now safe to do some API "pruning".  If another LSM comes along that
> needs this functionality we can always add it back in, but I don't see any
> LSMs on the horizon which might make use of these functions.
> 
> Thanks to Rami Rosen who suggested removing netlbl_cfg_cipsov4_del() back
> in February 2008.
> 
> Signed-off-by: Paul Moore <paul.moore <at> hp.com>

Reviewed-by: James Morris <jmorris <at> namei.org>

--

-- 
James Morris
<jmorris <at> namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

James Morris | 1 Oct 2008 03:43
Favicon

Re: [RFC PATCH v6 04/16] selinux: Better local/forward check in selinux_ip_postroute()

On Tue, 16 Sep 2008, Paul Moore wrote:

> It turns out that checking to see if skb->sk is NULL is not a very good
> indicator of a forwarded packet as some locally generated packets also have
> skb->sk set to NULL.  Fix this by not only checking the skb->sk field but also
> the IP[6]CB(skb)->flags field for the IP[6]SKB_FORWARDED flag.  While we are
> at it, we are calling selinux_parse_skb() much earlier than we really should
> resulting in potentially wasted cycles parsing packets for information we
> might no use; so shuffle the code around a bit to fix this.
> 
> Signed-off-by: Paul Moore <paul.moore <at> hp.com>

Acked-by: James Morris <jmorris <at> namei.org>

(Wow, this code is getting complex... :-)

--

-- 
James Morris
<jmorris <at> namei.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Simon Horman | 1 Oct 2008 07:53
Picon
Gravatar

Re: [RFC] bonding: add better ipv6 failover support

On Thu, Sep 25, 2008 at 11:42:57AM -0400, Brian Haley wrote:
> Jay Vosburgh wrote:
>> Brian Haley <brian.haley <at> hp.com> wrote:
>>
>>> This is an RFC patch to add better IPv6 failover support for bonding
>>> devices, especially when in active-backup mode, as reported by Alex
>>> Sidorenko.
>>>
>>> What this patch does:
>>>
>>> - Creates a new Kconfig option in the IPv6 Networking section to
>>>  compile-in the support in the bonding driver.  This also forces
>>>  IPV6=y since that's required to link everything.
>>
>> 	I think it's probably better to have the IPV6 dependent bits
>> somehow depend on CONFIG_IPV6 rather than having a Kconfig entry.  I
>> doubt that many real-world users will say yes to IPv6 and bonding, but
>> no to the bonding IPv6 support.  I also suspect that the IPV6=y
>> requirement won't fly with distros.
>
> I'm sure there's a way to do this better, for example, SCTP can be built  
> as a module with IPv6 support and have IPV6=m.  I'll try to make it work  
> without the option when IPV6=y or m.

Hi,

I took a bit of a stab at this, and here is what I cam up with.

It should enable IPV6_BONDING if one of the following is true
  * EXPERIMENTAL=y && IPV6=m && BONDING=m
(Continue reading)

Jarek Poplawski | 1 Oct 2008 07:58
Picon

Re: ax25 rose Re: kernel panic linux-2.6.27-rc7

On Wed, Oct 01, 2008 at 12:49:02AM +0200, Bernard Pidoux F6BVP wrote:
> Jarek,
>
> With the patch #2, there have been only one reboot after the machine was  
> frozen. I did not notice that was happening for there was no kernel  
> panic message but a frozen display only.
> Then I could only write down partially the values displayed after  
> AX25_DBG: c446c220, c..... 3, 5, 240
> Second number was not 000000 as it is most of the time.
> The machine rebooted after the usual 60 seconds delay and since then  
> there was no kernel panic.
> This is the first time kernel 2.6.27-rc7 does not panic within a minute.
> The system is up since about 20 minutes now with frequent AX25_DBG messages.

Hmm... Since this was intended mainly for debugging something went
wrong. (I expected to get at least one warning.)

>
> I am sorry that I must go to sleep now to be at work early in the morning.
> I will be away from my Linux box for a few days.
> Then we should probably interrupt this interesting bug hunting.
> I will send more results when I am back.

OK, I'll try to look at this in the meantime.

Cheers,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo <at> vger.kernel.org
(Continue reading)


Gmane