[net-next PATCH] e1000: Fix for e1000 kills IPMI on a tagged vlan.

From: Graham, David <david.graham <at> intel.com>

Enabling VLAN filters (VFE) when the primary interface is brought up
(per commit 78ed11a) has caused problems for some users who manage
their systems using IPMI over a VLAN. This is because when the driver
enables the VLAN filter, this same filter table is enabled for the
management channel, and the table is initially empty, which means that
the IPMI/VLAN packets are filtered out and not received by the BMC.
This is a problem only on e1000 class adapters, as it is only
on e1000 that the filter table is common to the management and host
streams.

With this change, filtering is only enabled when one or more host VLANs
exist, and is disabled when the last host VLAN is removed. VLAN filtering
is always disabled when the primary interface is in promiscuous mode,
and will be (re)enabled if VLANs exist when the interface exits
promiscuous mode.

Note that this does not completely resolve the issue for those using VLAN
management, because if the host adds a VLAN, then the above problem
occurs when that VLAN is enabled. However, it does mean the there is no
problem for configurations where management is on a VLAN and the host is
not.

A complete solution to this issue would require further driver changes.
The driver would need to discover if (and which) management VLANs are
active before enabling VLAN filtering, so that it could ensure that the
managed VLANs are included in the VLAN filter table. This discovery
requires that the BMC identifies its VLAN in registers accessible
to the driver, and at least on Dell PE2850 systems the BMC does not

Re: TCP Congestion Control Algorithms

Thanks, Stephen!
Lisong

On Mon, Aug 31, 2009 at 5:07 PM, Stephen Hemminger<shemminger <at> vyatta.com> wrote:
> On Mon, 31 Aug 2009 16:10:59 -0500
> Lisong Xu <lisongxu2 <at> gmail.com> wrote:
>
>> Hello,
>>
>> Since there are multiple different TCP congestion control algorithms
>> available in Linux, a Linux server may use any of them.
>>
>> Is it possible for a regular user to find out the exact TCP congestion
>> control algorithm used by a Linux server? For example, if I am
>> downloading a file from a remote Linux server using a TCP flow, can I
>> find out whether this flow is a TCP/CUBIC flow, or TCP/Newreno, or
>> some other TCP protocol?
>>
>
> No. you might be able to some nmap style guessing, but no remote
> API. You can see locally on the server through /proc/sys/net
>
--
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

Re: [PATCH resend] tracing/events: convert NAPI's tracepoint via TRACE_EVENT

Steven Rostedt wrote:
> On Mon, 31 Aug 2009, Xiao Guangrong wrote:
> 
>> - Convert NAPI's tracepoint via TRACE_EVENT macro, the output information
>>   like below:
>>
>>    sshd-2503  [000]    71.920846: napi_poll: ifname=eth0 state=0 weigth=16 poll=pcnet32_poll
>>    sshd-2503  [000]    72.020291: napi_poll: ifname=eth0 state=0 weigth=16 poll=pcnet32_poll
>>    sshd-2503  [000]    72.020418: napi_poll: ifname=eth0 state=NAPI_STATE_SCHED weigth=16 poll=pcnet32_poll
>>
>> - Remove the "DECLARE_TRACE" definiens in include/trace/define_trace.h,
>>   because TRACE_EVENT not use it
> 
> The above really needs to be in a separate patch, since it is a tracing 
> infrastructure change.
> 

Hi Steven,

We can't break this patch into two patches, because it's has redefined 'DECLARE_TRACE'
in include/trace/define_trace.h, like below:

1: if we remove 'DECLARE_TRACE' first, then NAPI's tracepoint can't define tracepoint
   (it's a NAPI tracepoint's bug,
    see my previous patch: http://marc.info/?l=linux-kernel&m=125118032931716&w=2)

2: if we convert NAPI's tracepoint first, it can't include more TRACE_EVENT .h files in
   one .c file, the compiler will complain with variables redefined:

Re: [net-next PATCH] e1000: Fix for e1000 kills IPMI on a tagged vlan.

On Mon, 31 Aug 2009, Jeff Kirsher wrote:

> From: Graham, David <david.graham <at> intel.com>

<CUT>
> A complete solution to this issue would require further driver changes.
> The driver would need to discover if (and which) management VLANs are
> active before enabling VLAN filtering, so that it could ensure that the
> managed VLANs are included in the VLAN filter table. This discovery
> requires that the BMC identifies its VLAN in registers accessible
> to the driver, and at least on Dell PE2850 systems the BMC does not
> identify its VLAN to allow such discovery. Intel is pursuing this issue
> with the BMC vendor.
>
> Signed-off-by: Dave Graham <david.graham <at> intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher <at> intel.com>

Tested-by: Krzysztof Piotr Oledzki <ole <at> ans.pl>

Thank you for both pushing this fix into the mainline and trying to 
convince Dell to fix the BMC code.

BTW: this problem also exists on Dell 1425SC and probably on all 
e1000-based Dell servers.

Best regards,

 				Krzysztof Olędzki

Re: [PATCH 0/2] New LSM hooks for the TUN driver

On Fri, 28 Aug 2009, Paul Moore wrote:

> This is the third, and hopefully final, version of the new LSM TUN hooks.  This
> version incorporates all outstanding feedback as well as my sign-off and ACKs
> from both Eric and Serge (see patches).  However, the patches are still missing
> an ACK from netdev - I haven't heard any objections but I'm not certain anyone
> from netdev has really taken a look yet.

Applied to
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next

--

-- 
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

Re: [PATCH resend] tracing/events: convert NAPI's tracepoint via TRACE_EVENT

On Tue, 2009-09-01 at 09:06 +0800, Xiao Guangrong wrote:
> 
> Steven Rostedt wrote:
> > On Mon, 31 Aug 2009, Xiao Guangrong wrote:
> > 
> >> - Convert NAPI's tracepoint via TRACE_EVENT macro, the output information
> >>   like below:
> >>
> >>    sshd-2503  [000]    71.920846: napi_poll: ifname=eth0 state=0 weigth=16 poll=pcnet32_poll
> >>    sshd-2503  [000]    72.020291: napi_poll: ifname=eth0 state=0 weigth=16 poll=pcnet32_poll
> >>    sshd-2503  [000]    72.020418: napi_poll: ifname=eth0 state=NAPI_STATE_SCHED weigth=16 poll=pcnet32_poll
> >>
> >> - Remove the "DECLARE_TRACE" definiens in include/trace/define_trace.h,
> >>   because TRACE_EVENT not use it
> > 
> > The above really needs to be in a separate patch, since it is a tracing 
> > infrastructure change.
> > 
> 
> Hi Steven,
> 
> We can't break this patch into two patches, because it's has redefined 'DECLARE_TRACE'
> in include/trace/define_trace.h, like below:
> 
> 1: if we remove 'DECLARE_TRACE' first, then NAPI's tracepoint can't define tracepoint
>    (it's a NAPI tracepoint's bug,
>     see my previous patch: http://marc.info/?l=linux-kernel&m=125118032931716&w=2)
> 
> 2: if we convert NAPI's tracepoint first, it can't include more TRACE_EVENT .h files in
>    one .c file, the compiler will complain with variables redefined:

Re: [patch] ipvs: Use atomic operations atomicly

On Mon, Aug 31, 2009 at 02:22:26PM +0200, Patrick McHardy wrote:
> Simon Horman wrote:
> > A pointed out by Shin Hong, IPVS doesn't always use atomic operations
> > in an atomic manner. While this seems unlikely to be manifest in
> > strange behaviour, it seems appropriate to clean this up.
> > 
> > Cc: 홍신 shin hong <hongshin <at> gmail.com>
> > Signed-off-by: Simon Horman <horms <at> verge.net.au>
> 
> Applied, thanks.
> 
> >  	if (af == AF_INET &&
> >  	    (ip_vs_sync_state & IP_VS_STATE_MASTER) &&
> >  	    (((cp->protocol != IPPROTO_TCP ||
> >  	       cp->state == IP_VS_TCP_S_ESTABLISHED) &&
> > -	      (atomic_read(&cp->in_pkts) % sysctl_ip_vs_sync_threshold[1]
> > +	      (pkts % sysctl_ip_vs_sync_threshold[1]
> 
> It seems that proc_do_sync_threshold() should check whether this value
> is zero. The current checks also look racy since incorrect values are
> first updated, then overwritten again.

Hi,

I'm wondering if an approach along the lines of the following is valid.
The idea is that the value in the ctl_table is essentially a scratch
value that is used by the parser and then copied into ip_vs_sync_threshold
if it is valid. I'm concerned that there are atomicity issues
surrounding writing ip_vs_sync_threshold while there might be readers.

Re: [PATCH] r8169: Reduce looping in the interrupt handler.

On Sun, 2009-08-30 at 13:53 -0700, Eric W. Biederman wrote:
> Francois Romieu <romieu <at> fr.zoreil.com> writes:
> 
> > David Dillow <dave <at> thedillows.org> :
> > [...]
> >> It'll be this weekend, but I can see cases where it can lock my chip up
> >> -- they should be rare, but then I thought your case would be extremely
> >> rare...
> >
> > I don't get it.
> >
> > Can you elaborate the relevant cases or give some sample scenarios for
> > them ?
> 
> I think David is referring to the fact that in the NAPI loop there is
> nothing that acks everything.

That was my concern, yes.

I've not been able to reproduce my lockups under medium testing with
Francois's patch applied, so I'm a little more comfortable with it.

At the same time, I'm worried that the timing just changed enough to
make it harder to trigger, as was the case when I did the patch IIRC.
The kernel's interrupt handling changed in a manner that made it much
easier to hit about that time. The testing I did in May pointed strongly
at us failing to ACK an interrupt source, causing the MSI generation to
stop, so I need to think about things some more.

[PATCH] forcedeth: updated phy errata

This patch updates the special programming (and/or errata) needed in 
order to setup the phy for various vendor models.

The new models include:
Marvell E1116
Marvell E1111
Marvell E1011
Marvell E3016
Broadcom 9507
Broadcom AC131
Broadcom 50610

Signed-off-by: Ayaz Abdulla <aabdulla <at> nvidia.com>

--- old/drivers/net/forcedeth.c	2009-08-31 19:01:04.000000000 -0400
+++ new/drivers/net/forcedeth.c	2009-08-31 19:05:49.000000000 -0400
 <at>  <at>  -506,6 +506,7  <at>  <at> 
 #define PHY_OUI_VITESSE		0x01c1
 #define PHY_OUI_REALTEK		0x0732
 #define PHY_OUI_REALTEK2	0x0020
+#define PHY_OUI_BROADCOM	0x50ef
 #define PHYID1_OUI_MASK	0x03ff
 #define PHYID1_OUI_SHFT	6
 #define PHYID2_OUI_MASK	0xfc00
 <at>  <at>  -517,7 +518,18  <at>  <at> 
 #define PHY_REV_REALTEK_8211C		0x0001
 #define PHY_MODEL_REALTEK_8201		0x0200
 #define PHY_MODEL_MARVELL_E3016		0x0220

[iputils] - patch for ping to set un.echo.id to network byte order

I noticed in the ping source code that the identity flag on the icmp
echo packet is set to the pid of the ping command being run. I
immediatly fired up a packet sniffer to see it, but got endian
wierdness. Looking back at the code, and comparing with ping6 and
traceroute6, I noticed that when the identity is set, its fed the
value of getpid() without running it through htons(), as is done in
traceroute6.

So this patch for the ipv4 version of ping:

diff -pu iputils-s20071127/ping_common.c iputils-jamie/ping_common.c
--- iputils-s20071127/ping_common.c	2007-11-26 19:57:27.000000000 -0500
+++ iputils-jamie/ping_common.c	2009-09-01 00:10:58.000000000 -0400
 <at>  <at>  -473,7 +473,7  <at>  <at>  void setup(int icmp_sock)
 			*p++ = i;
 	}

-	ident = getpid() & 0xFFFF;
+	ident = htons(getpid() & 0xFFFF);

 	set_signal(SIGINT, sigexit);
 	set_signal(SIGALRM, sigexit);

seems obvious enough. I figured that htons was safe enough, since
pid_t is just an int.

Is there some reason to not send the identifier properly so it doesn't
end up bass-ackwards on the receiving end?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in