* Re: [PATCH net-next-2.6] bonding: wipe out printk's
From: David Miller @ 2009-08-13 23:29 UTC (permalink / raw)
To: jpirko; +Cc: fubar, bonding-devel, netdev
In-Reply-To: <20090813141151.GA10449@psychotron.englab.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 13 Aug 2009 16:11:52 +0200
> I did not introduce new lines over 80 chars. I even eliminated some of them.
>
> Signed-off-by: Jiri Pirko <jpirko@redhat.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 0/2] inet6: resolve IPV6_TCLASS conversion problems
From: David Miller @ 2009-08-13 23:28 UTC (permalink / raw)
To: gerrit; +Cc: netdev
In-Reply-To: <1249841569-23706-1-git-send-email-gerrit@erg.abdn.ac.uk>
From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Date: Sun, 9 Aug 2009 20:12:47 +0200
> These are two patches dealing with the IPV6_TCLASS sticky socket option. They
> belong together, the second patch is a follow-up and fixes the remainder.
>
> Patch #1: Removes unnecessary conversions (tclass being u8)
> This is a resent, an OK was given in the reply of
> http://marc.info/?l=linux-netdev&m=124820628409987&w=2
> Patch #2: Solves the remaining problem of passing the socket option,
> fixing a bug (-1 became a non-default traffic class of 0xff).
Both applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 3/3] net: skb ftracer - Add actual ftrace code to kernel (v3)
From: David Miller @ 2009-08-13 23:28 UTC (permalink / raw)
To: nhorman; +Cc: netdev, rostedt
In-Reply-To: <20090813152356.GC16682@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 13 Aug 2009 11:23:56 -0400
> skb allocation / consumption correlator
>
> Add ftracer module to kernel to print out a list that correlates a process id,
> an skb it read, and the numa nodes on wich the process was running when it was
> read along with the numa node the skbuff was allocated on.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/3] net: skb ftracer - Add config option to enable new ftracer (v3)
From: David Miller @ 2009-08-13 23:28 UTC (permalink / raw)
To: nhorman; +Cc: netdev, rostedt
In-Reply-To: <20090813152045.GB16682@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 13 Aug 2009 11:20:45 -0400
> skb allocation / consumption corelator - Add config option
>
> This patch adds a Kconfig option to enable the addtition of the skb source
> tracer.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/3] net: skb ftracer - add tracepoint to skb_copy_datagram_iovec (v3)
From: David Miller @ 2009-08-13 23:28 UTC (permalink / raw)
To: nhorman; +Cc: netdev, rostedt
In-Reply-To: <20090813151944.GA16682@hmsreliant.think-freely.org>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Thu, 13 Aug 2009 11:19:44 -0400
> skb allocation / cosumption tracer - Add consumption tracepoint
>
> This patch adds a tracepoint to skb_copy_datagram_iovec, which is called each
> time a userspace process copies a frame from a socket receive queue to a user
> space buffer. It allows us to hook in and examine each sk_buff that the system
> receives on a per-socket bases, and can be use to compile a list of which skb's
> were received by which processes.
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH v3] Add support for w90p910 mac driver
From: David Miller @ 2009-08-13 23:27 UTC (permalink / raw)
To: mcuos.com; +Cc: linux, linux-arm-kernel, netdev
In-Reply-To: <4A7EC9CB.5060106@gmail.com>
From: Wan ZongShun <mcuos.com@gmail.com>
Date: Sun, 09 Aug 2009 21:06:19 +0800
> I fixed up my mac driver, which relatives to previous
> mac driver actually in the tree.
>
> Thanks a lot for your help!
>
> Signed-off-by: Wan ZongShun <mcuos.com@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 2/2] korina: add error-handling to korina_alloc_ring
From: David Miller @ 2009-08-13 23:27 UTC (permalink / raw)
To: n0-1; +Cc: netdev, akpm, florian, roel.kluin
In-Reply-To: <20090812225234.82E6E4CEAA@orbit.nwl.cc>
From: Phil Sutter <n0-1@freewrt.org>
Date: Thu, 13 Aug 2009 00:52:32 +0200
> This also avoids a potential buffer overflow in case the very first
> receive descriptor fails to allocate, as an index of -1 would be used
> afterwards. Kudos to Roel Kluin for pointing this out and providing an
> initial patch.
>
> Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/2] korina: fix printk formatting, add final info line
From: David Miller @ 2009-08-13 23:27 UTC (permalink / raw)
To: n0-1; +Cc: netdev, akpm, florian, roel.kluin
In-Reply-To: <20090812222249.39EAB4CEAA@orbit.nwl.cc>
From: Phil Sutter <n0-1@freewrt.org>
Date: Thu, 13 Aug 2009 00:22:46 +0200
> The macro DRV_NAME contains "korina", the field dev->name points to the
> actual interface name. So messages were formerly prefixed with
> 'korinaeth2:' (on my system).
>
> Signed-off-by: Phil Sutter <n0-1@freewrt.org>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] net/bridge: Add 'hairpin' port forwarding mode
From: David Miller @ 2009-08-13 23:27 UTC (permalink / raw)
To: anna.fischer
Cc: linux-kernel, netdev, shemminger, ptcongdon, evb, bridge,
virtualization, kaber, arnd, mike.dickson, adobriyan, bridge
In-Reply-To: <0199E0D51A61344794750DC57738F58E6D6B0C70D9@GVW1118EXC.americas.hpqcorp.net>
From: "Fischer, Anna" <anna.fischer@hp.com>
Date: Thu, 13 Aug 2009 16:55:16 +0000
> This patch adds a 'hairpin' (also called 'reflective relay') mode
> port configuration to the Linux Ethernet bridge kernel module.
> A bridge supporting hairpin forwarding mode can send frames back
> out through the port the frame was received on.
>
> Hairpin mode is required to support basic VEPA (Virtual
> Ethernet Port Aggregator) capabilities.
>
> You can find additional information on VEPA here:
> http://tech.groups.yahoo.com/group/evb/
> http://www.ieee802.org/1/files/public/docs2009/new-hudson-vepa_seminar-20090514d.pdf
> http://www.internet2.edu/presentations/jt2009jul/20090719-congdon.pdf
>
> An additional patch 'bridge-utils: Add 'hairpin' port forwarding mode'
> is provided to allow configuring hairpin mode from userspace tools.
>
> Signed-off-by: Paul Congdon <paul.congdon@hp.com>
> Signed-off-by: Anna Fischer <anna.fischer@hp.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] lmc: Read outside array bounds
From: David Miller @ 2009-08-13 23:27 UTC (permalink / raw)
To: roel.kluin; +Cc: khc, netdev, akpm
In-Reply-To: <4A8004B0.5000504@gmail.com>
From: Roel Kluin <roel.kluin@gmail.com>
Date: Mon, 10 Aug 2009 13:29:52 +0200
> If dev_alloc_skb() fails on the first iteration of the allocation loop,
> then we end up writing before the start of the array.
>
> Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [net-next-2.6 PATCH] be2net:Creating/destroying queues regardless of netif_running() in suspend/resume path
From: David Miller @ 2009-08-13 23:26 UTC (permalink / raw)
To: sarveshwarb; +Cc: netdev
In-Reply-To: <20090813070119.GA28043@serverengines.com>
From: Sarveshwar Bandi <sarveshwarb@serverengines.com>
Date: Thu, 13 Aug 2009 12:31:29 +0530
> Signed-off-by: sarveshwarb <sarveshwarb@serverengines.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 1/3] Networking: use CAP_NET_ADMIN when deciding to call request_module
From: David Miller @ 2009-08-13 23:14 UTC (permalink / raw)
To: paul.moore
Cc: eparis, linux-kernel, selinux, netdev, linux-security-module, sds,
shemminger, kees, morgan, casey, dwalsh
In-Reply-To: <200908131445.37263.paul.moore@hp.com>
From: Paul Moore <paul.moore@hp.com>
Date: Thu, 13 Aug 2009 14:45:37 -0400
> On Thursday 13 August 2009 09:44:51 am Eric Paris wrote:
>> The networking code checks CAP_SYS_MODULE before using request_module() to
>> try to load a kernel module. While this seems reasonable it's actually
>> weakening system security since we have to allow CAP_SYS_MODULE for things
>> like /sbin/ip and bluetoothd which need to be able to trigger module loads.
>> CAP_SYS_MODULE actually grants those binaries the ability to directly load
>> any code into the kernel. We should instead be protecting modprobe and the
>> modules on disk, rather than granting random programs the ability to load
>> code directly into the kernel. Instead we are going to gate those
>> networking checks on CAP_NET_ADMIN which still limits them to root but
>> which does not grant those processes the ability to load arbitrary code
>> into the kernel.
>>
>> Signed-off-by: Eric Paris <eparis@redhat.com>
>
> Sounds and looks reasonable to me.
>
> Acked-by: Paul Moore <paul.moore@hp.com>
Looks fine to me:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* Re: [PATCH] revert TCP retransmission backoff on ICMP destination unreachable
From: David Miller @ 2009-08-13 23:08 UTC (permalink / raw)
To: damian; +Cc: netdev
In-Reply-To: <4A8155AE.7000707@tvk.rwth-aachen.de>
From: Damian Lukowski <damian@tvk.rwth-aachen.de>
Date: Tue, 11 Aug 2009 13:27:42 +0200
> @@ -1220,6 +1220,8 @@
> #define tcp_for_write_queue_from_safe(skb, tmp, sk) \
> skb_queue_walk_from_safe(&(sk)->sk_write_queue, skb, tmp)
>
> +#define retrans_overstepped(sk, boundary) (inet_csk(sk)->icsk_retransmits && (tcp_time_stamp - tcp_sk(sk)->retrans_stamp) >= TCP_RTO_MIN*(2 << boundary))
> +
Longer than 80 columns, and use an inline function instead
of a macro in order to get proper type checking.
> @@ -332,11 +332,14 @@
> {
> struct iphdr *iph = (struct iphdr *)skb->data;
> struct tcphdr *th = (struct tcphdr *)(skb->data + (iph->ihl << 2));
> +
> + struct inet_connection_sock *icsk;
> struct tcp_sock *tp;
> struct inet_sock *inet;
Do not break up the function local variables with spurious new lines
like this, please.
> const int type = icmp_hdr(skb)->type;
> const int code = icmp_hdr(skb)->code;
> struct sock *sk;
> + struct sk_buff *skb_r;
> __u32 seq;
> int err;
> struct net *net = dev_net(skb->dev);
> @@ -367,6 +370,7 @@
> if (sk->sk_state == TCP_CLOSE)
> goto out;
>
> + icsk = inet_csk(sk);
> tp = tcp_sk(sk);
> seq = ntohl(th->seq);
> if (sk->sk_state != TCP_LISTEN &&
> @@ -393,6 +397,34 @@
> }
>
> err = icmp_err_convert[code].errno;
> +
> + /* check if ICMP unreachable messages allow revert of back-off */
> + if ((code != ICMP_NET_UNREACH && code != ICMP_HOST_UNREACH) || seq != tp->snd_una
> + || !icsk->icsk_retransmits || !icsk->icsk_backoff) break;
> +
> + icsk->icsk_backoff--;
> + icsk->icsk_rto >>= 1;
> +
> + skb_r = skb_peek(&sk->sk_write_queue);
> + BUG_ON(!skb_r);
> +
The indentation and tabbing is messed up in all of the code you are
adding, please fix it up to be consistent with the surrounding code
and the rest of the TCP stack.
Do not use C++ style // comments.
^ permalink raw reply
* Re: [PATCH] e1000e: fix use of pci_enable_pcie_error_reporting
From: Jeff Kirsher @ 2009-08-13 23:00 UTC (permalink / raw)
To: Xiaotian Feng
Cc: john.ronciak, peter.p.waskiewicz.jr, bruce.w.allan,
jesse.brandeburg, davem, e1000-devel, netdev, linux-kernel
In-Reply-To: <1249637774-32419-1-git-send-email-dfeng@redhat.com>
On Fri, Aug 7, 2009 at 02:36, Xiaotian Feng<dfeng@redhat.com> wrote:
> commit 111b9dc5 introduces pcie aer support for e1000e, but it is not
> reasonable to disable it in e1000_remove but enable it in e1000_resume.
> This patch enables aer support in e1000_probe.
>
> Signed-off-by: Xiaotian Feng <dfeng@redhat.com>
> ---
> drivers/net/e1000e/netdev.c | 16 ++++++++--------
> 1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/e1000e/netdev.c b/drivers/net/e1000e/netdev.c
> index 63415bb..e2f0304 100644
> --- a/drivers/net/e1000e/netdev.c
> +++ b/drivers/net/e1000e/netdev.c
> @@ -4670,14 +4670,6 @@ static int e1000_resume(struct pci_dev *pdev)
> return err;
> }
>
> - /* AER (Advanced Error Reporting) hooks */
> - err = pci_enable_pcie_error_reporting(pdev);
> - if (err) {
> - dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> - "0x%x\n", err);
> - /* non-fatal, continue */
> - }
> -
> pci_set_master(pdev);
>
> pci_enable_wake(pdev, PCI_D3hot, 0);
> @@ -4990,6 +4982,14 @@ static int __devinit e1000_probe(struct pci_dev *pdev,
> if (err)
> goto err_pci_reg;
>
> + /* AER (Advanced Error Reporting) hooks */
> + err = pci_enable_pcie_error_reporting(pdev);
> + if (err) {
> + dev_err(&pdev->dev, "pci_enable_pcie_error_reporting failed "
> + "0x%x\n", err);
> + /* non-fatal, continue */
> + }
> +
> pci_set_master(pdev);
> /* PCI config space info */
> err = pci_save_state(pdev);
> --
> 1.6.2.5
>
> --
This patch passed testing, I have added it to my queue of patches and
will push this out to Dave (with the whitespace corrected).
--
Cheers,
Jeff
^ permalink raw reply
* Re: [PATCH 1/3] Networking: use CAP_NET_ADMIN when deciding to call request_module
From: James Morris @ 2009-08-13 22:55 UTC (permalink / raw)
To: David S. Miller
Cc: Eric Paris, linux-kernel, selinux, netdev, linux-security-module,
Stephen Smalley, shemminger, kees, morgan, Casey Schaufler,
Daniel J Walsh, Herbert Xu
In-Reply-To: <200908131445.37263.paul.moore@hp.com>
Any nacks/acks from netdev folk?
It looks like the right thing to me.
On Thu, 13 Aug 2009, Paul Moore wrote:
> On Thursday 13 August 2009 09:44:51 am Eric Paris wrote:
> > The networking code checks CAP_SYS_MODULE before using request_module() to
> > try to load a kernel module. While this seems reasonable it's actually
> > weakening system security since we have to allow CAP_SYS_MODULE for things
> > like /sbin/ip and bluetoothd which need to be able to trigger module loads.
> > CAP_SYS_MODULE actually grants those binaries the ability to directly load
> > any code into the kernel. We should instead be protecting modprobe and the
> > modules on disk, rather than granting random programs the ability to load
> > code directly into the kernel. Instead we are going to gate those
> > networking checks on CAP_NET_ADMIN which still limits them to root but
> > which does not grant those processes the ability to load arbitrary code
> > into the kernel.
> >
> > Signed-off-by: Eric Paris <eparis@redhat.com>
>
> Sounds and looks reasonable to me.
>
> Acked-by: Paul Moore <paul.moore@hp.com>
>
> > ---
> >
> > drivers/staging/comedi/comedi_fops.c | 8 ++++----
> > net/core/dev.c | 2 +-
> > net/ipv4/tcp_cong.c | 4 ++--
> > 3 files changed, 7 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/staging/comedi/comedi_fops.c
> > b/drivers/staging/comedi/comedi_fops.c index 42e4bc4..f54bb9b 100644
> > --- a/drivers/staging/comedi/comedi_fops.c
> > +++ b/drivers/staging/comedi/comedi_fops.c
> > @@ -1772,12 +1772,12 @@ static int comedi_open(struct inode *inode, struct
> > file *file) mutex_lock(&dev->mutex);
> > if (dev->attached)
> > goto ok;
> > - if (!capable(CAP_SYS_MODULE) && dev->in_request_module) {
> > + if (!capable(CAP_NET_ADMIN) && dev->in_request_module) {
> > DPRINTK("in request module\n");
> > mutex_unlock(&dev->mutex);
> > return -ENODEV;
> > }
> > - if (capable(CAP_SYS_MODULE) && dev->in_request_module)
> > + if (capable(CAP_NET_ADMIN) && dev->in_request_module)
> > goto ok;
> >
> > dev->in_request_module = 1;
> > @@ -1790,8 +1790,8 @@ static int comedi_open(struct inode *inode, struct
> > file *file)
> >
> > dev->in_request_module = 0;
> >
> > - if (!dev->attached && !capable(CAP_SYS_MODULE)) {
> > - DPRINTK("not attached and not CAP_SYS_MODULE\n");
> > + if (!dev->attached && !capable(CAP_NET_ADMIN)) {
> > + DPRINTK("not attached and not CAP_NET_ADMIN\n");
> > mutex_unlock(&dev->mutex);
> > return -ENODEV;
> > }
> > diff --git a/net/core/dev.c b/net/core/dev.c
> > index 09fb03f..2604db9 100644
> > --- a/net/core/dev.c
> > +++ b/net/core/dev.c
> > @@ -1031,7 +1031,7 @@ void dev_load(struct net *net, const char *name)
> > dev = __dev_get_by_name(net, name);
> > read_unlock(&dev_base_lock);
> >
> > - if (!dev && capable(CAP_SYS_MODULE))
> > + if (!dev && capable(CAP_NET_ADMIN))
> > request_module("%s", name);
> > }
> >
> > diff --git a/net/ipv4/tcp_cong.c b/net/ipv4/tcp_cong.c
> > index e92beb9..6428b34 100644
> > --- a/net/ipv4/tcp_cong.c
> > +++ b/net/ipv4/tcp_cong.c
> > @@ -116,7 +116,7 @@ int tcp_set_default_congestion_control(const char
> > *name) spin_lock(&tcp_cong_list_lock);
> > ca = tcp_ca_find(name);
> > #ifdef CONFIG_MODULES
> > - if (!ca && capable(CAP_SYS_MODULE)) {
> > + if (!ca && capable(CAP_NET_ADMIN)) {
> > spin_unlock(&tcp_cong_list_lock);
> >
> > request_module("tcp_%s", name);
> > @@ -246,7 +246,7 @@ int tcp_set_congestion_control(struct sock *sk, const
> > char *name)
> >
> > #ifdef CONFIG_MODULES
> > /* not found attempt to autoload module */
> > - if (!ca && capable(CAP_SYS_MODULE)) {
> > + if (!ca && capable(CAP_NET_ADMIN)) {
> > rcu_read_unlock();
> > request_module("tcp_%s", name);
> > rcu_read_lock();
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe
> > linux-security-module" in the body of a message to
> > majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
> --
> paul moore
> linux @ hp
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* RE: [PATCH][RFC] net/bridge: add basic VEPA support
From: Fischer, Anna @ 2009-08-13 22:24 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Congdon (UC Davis), 'Stephen Hemminger',
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
evb@yahoogroups.com, davem@davemloft.net, kaber@trash.net,
adobriyan@gmail.com, 'Eric Biederman'
In-Reply-To: <200908121519.36808.arnd@arndb.de>
> Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
>
> On Tuesday 11 August 2009, Paul Congdon (UC Davis) wrote:
> > > >
> > > > The patch from Eric Biederman to allow macvlan to bridge between
> > > > its slave ports is at
> > > >
> > > > http://kerneltrap.org/mailarchive/linux-netdev/2009/3/9/5125774
> > >
> > > Looking through the discussions here, it does not seem as if a
> decision
> > > was made to integrate those patches, because they would make the
> > > macvlan interface behave too much like a bridge.
>
> Right, that question is still open, and dont't see it as very important
> right now, as long as we can still use it for VEPA.
>
> > > Also, it seems as if there was still a problem with doing
> > > multicast/broadcast delivery when enabling local VM-to-VM
> > > communication. Is that solved by now?
>
> Not yet, but I guess it comes as a natural extension when I fix
> multicast/broadcast delivery from the reflective relay for VEPA.
>
> The logic that I would use there is:
>
> broadcast from a dowstream port:
> if (bridge_mode(source_port)) {
> forward_to_upstream(frame);
> for_each_downstream(port) {
> /* deliver to all bridge ports except self, do
> not deliver to any VEPA port. */
> if (bridge_mode(port) && port != source_port) {
> forward_to_downstream(frame, port);
> }
> }
> } else {
> forward_to_upstream(frame);
> }
>
>
> broadcast from the upstream port
> if (bridge_mode(frame.source)) {
> /* comes from a port in bridge mode, so has already been
> delivered to all other bridge ports */
> for_each_downstream(port) {
> if (!bridge_mode(port)) {
> forward_to_downstream(frame, port);
> }
> }
> } else if (vepa_mode(frame.source)) {
> /* comes from VEPA port, so need to deliver to all
> bridge and all vepa ports except self */
> for_each_downstream(port) {
> if (port != frame.source)
> forward_to_downstream(frame, port);
> } else {
> /* external source, so flood to everyone */
> for_each_downstream(port) {
> forward_to_downstream(frame, port);
> }
>
> For multicast, we can do the same, or optionally add a per-port filter
> as you mentioned, if it becomes a bottleneck.
>
> Do you think this addresses the problem, or did I miss something
> important?
Yes, I think this addresses the problem. It would be very useful if
this functionality was in macvlan.
Thanks,
Anna
^ permalink raw reply
* RE: [PATCH][RFC] net/bridge: add basic VEPA support
From: Fischer, Anna @ 2009-08-13 22:11 UTC (permalink / raw)
To: Arnd Bergmann
Cc: Paul Congdon (UC Davis), 'Stephen Hemminger',
bridge@lists.linux-foundation.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, virtualization@lists.linux-foundation.org,
evb@yahoogroups.com, davem@davemloft.net, kaber@trash.net,
adobriyan@gmail.com, 'Eric Biederman'
In-Reply-To: <200908121827.28905.arnd@arndb.de>
> Subject: Re: [PATCH][RFC] net/bridge: add basic VEPA support
>
> On Wednesday 12 August 2009, Fischer, Anna wrote:
> > Yes, for the basic VEPA this is not important. For MultiChannel VEPA,
> it
> > would be nice if a macvlan device could operate as VEPA and as a
> typical
> > VEB (VEB = traditional bridge but no learning).
>
> Right, this would be a logical extension in that scenario. I would
> imagine
> that in many scenarios running a VEB also means that you want to use
> the advanced ebtables/iptables filtering of the bridge subsystem, but
> if all guests trust each other, using macvlan to bridge between them
> sounds useful as well, if only for simplicity.
>
> > Basically, what we would need to be able to support is running a VEB
> and
> > a VEPA simultaneously on the same uplink port (e.g. the physical
> device).
> > A new component (called the S-Component) would then multiplex frames
> > to the VEB or the VEPA based on a tagging scheme.
>
> You can of course do that by adding one port of the S-component to
> a port of a bridge, and using another port of the S-component to
> create macvlan devices, or you could have multiple ports of the
> S-component each with a macvlan multiplexor.
>
> Just to make sure I get the chain right, would it look like this?
> (adapted from Paul's PDF)
>
> eth0 (external) ---scomponent0 --- vlan2 --- macvlan0
> | | \- macvlan1
> | \-vlan3 --- macvlan2
> |-scomponent1 --- vlan2 --- br0 --- tap0
> | \ --- tap1
> |-scomponent2 --- vlan3 --- macvlan3
> \-scomponent3 --- --- --- macvlan4
>
> In this scenario, tap0 and tap1 could communicate over the bridge
> without
> tagging, while any data going out through the S-Component gets tagged
> with both a 802.1q Q-Tag and an S-Tag.
Yes, that looks right. If all the different interfaces, e.g. bridge ports,
macvlan devices, vlan tagging devices can be stacked that easily without
any known issues, that would be great.
> macvlan4 would be a guest that does its own tagging, and the external
> switch would need to check the VLAN IDs, but it could communicate with
> any other guest by tagging the frames as 2 or 3.
>
> macvlan2 and macvlan3 could communicate with each other and with
> external
> guests in vlan3.
>
> Guests on scomponent1 and scomponent3 could in theory have
> subdivisions of the network with macvlan running in the guest
> to run containers.
>
> > I think the question here was whether there is a way for a macvlan
> interface
> > to be set to promiscuous mode. At the moment, I believe a macvlan
> interface
> > only receives packets based on its destination address (this is for
> unicast
> > packets now). What if a macvlan interface wanted to get all packets
> that
> > are being received (either on the physical device, or on a particular
> > VLAN if using macvlan nested in vlan). Would this work easily?
> Imagine
> > you have a virtual machine attached to that macvlan / macvtap device
> and
> > this VM wants to do packet inspection or network traffic monitoring
> on
> > all packets flowing through the virtualized server.
>
> Ok, I see. As I said, the host could easily get access to all frames
> on macvlan downstream ports by opening a raw socket on the upstream
> port (with some extra work if we want to support this in bridge mode).
>
> If you want the inspection to be done in a guest rather than the host,
> the easiest way to achieve that would be to connect that raw socket
> to the guest using Or's raw frontend for qemu.
I am not too familiar with that raw frontend for qemu to be honest, but
if it can share the physical device with other macvlan interfaces
simultaneously, then I think that would indeed be sufficient to support
promiscuous mode ports. We would need to have a similar sort of driver
for Xen and other hypervisor solutions again as well though.
If it is possible to easily stack macvlan devices and bridges as you
describe above, then a promiscuous port should also be realized quite
easily as a typical bridge port, e.g. as shown above tap0 and tap1
would be typical, traditional bridge ports and though could send
and receive from/with any MAC addresses they like.
Anna
^ permalink raw reply
* Re: [Iproute2]: failed replacing internal netem qdisc with pfifo
From: Jarek Poplawski @ 2009-08-13 21:56 UTC (permalink / raw)
To: Marcela Maslanova; +Cc: netdev, shemminger, Patrick McHardy
In-Reply-To: <4A848663.4020304@gmail.com>
Jarek Poplawski wrote, On 08/13/2009 11:32 PM:
...
> The clasfullness isn't actually a big problem if we skip reordering
> (done by putting packets to the head of the queue) for such external
> qdiscs. Alternatively we could modify netem's tfifo behavior (to pfifo)
> with some option. Any suggestions?
...or something in between like classfulness limited to fifos only?
Jarek P.
^ permalink raw reply
* Re: [Iproute2]: failed replacing internal netem qdisc with pfifo
From: Jarek Poplawski @ 2009-08-13 21:32 UTC (permalink / raw)
To: Marcela Maslanova; +Cc: netdev, shemminger, Patrick McHardy
In-Reply-To: <20090813120330.GB7010@ff.dom.local>
Jarek Poplawski wrote, On 08/13/2009 02:03 PM:
> On 13-08-2009 12:26, Marcela Maslanova wrote:
>> Hello,
>> I've received bug report about not being replaced netem with pfifo
>> anymore: https://bugzilla.redhat.com/show_bug.cgi?id=515522
>> This should be possible according to documentation [1].
>> Is this intentional change or is it a bug?
>
> It's intentional:
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=02201464119334690fe209849843881b8e9cfa9f
>
>> It worked with kernel-2.6.27.5-117.fc10 and iproute-2.6.27. The problem
>> is still present with current iproute and kernel-2.6.29.6-217.2.3.fc11.
>
> Yes, netem is classless since 2.6.29, so this documentation needs
> updating.
Hmm... I see this is passed to the user as "notabug". On the other hand,
since this functionality looks like useful (and used), I wonder if "we"
weren't too strict, and maybe it should be at least partially restored.
The clasfullness isn't actually a big problem if we skip reordering
(done by putting packets to the head of the queue) for such external
qdiscs. Alternatively we could modify netem's tfifo behavior (to pfifo)
with some option. Any suggestions?
Jarek P.
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: Joe Perches @ 2009-08-13 21:13 UTC (permalink / raw)
To: Chuck Lever; +Cc: Brian Haley, Jens Rosenboom, Linux Network Developers
In-Reply-To: <457D0D34-041E-43AE-BE31-241A19AA08B4@oracle.com>
On Thu, 2009-08-13 at 17:02 -0400, Chuck Lever wrote:
> On Aug 13, 2009, at 4:34 PM, Joe Perches wrote:
> > net/sunrpc/svcauth_unix.c: seq_printf(m, "%s %pI6 %s\n", im-
> > >m_class, &addr, dom);
>
> This one might be a bad example.
There are 9 of them in net
$ grep -rP --include=*.[ch] "%pI6" net | grep seq_
net/sctp/ipv6.c: seq_printf(seq, "%pI6 ", &addr->v6.sin6_addr);
net/ipv6/netfilter/nf_conntrack_l3proto_ipv6.c: return seq_printf(s, "src=%pI6 dst=%pI6 ",
net/ipv6/ip6mr.c: seq_printf(seq, "%pI6 %pI6 %-3hd",
net/netfilter/xt_hashlimit.c: return seq_printf(s, "%ld %pI6:%u->%pI6:%u %u %u %u\n",
net/netfilter/xt_recent.c: seq_printf(seq, "src=%pI6 ttl: %u last_seen: %lu oldest_pkt: %u",
net/netfilter/ipvs/ip_vs_ctl.c: seq_printf(seq, "%s [%pI6]:%04X %s ",
net/netfilter/ipvs/ip_vs_conn.c: seq_printf(seq, "%-3s %pI6 %04X %pI6 %04X %pI6 %04X %-11s %7lu\n",
net/netfilter/ipvs/ip_vs_conn.c: seq_printf(seq, "%-3s %pI6 %04X %pI6 %04X %pI6 %04X %-11s %-6s %7lu\n",
net/sunrpc/svcauth_unix.c: seq_printf(m, "%s %pI6 %s\n", im->m_class, &addr, dom);
> [ I would think user space in general should be using inet_pton(3)
> everywhere for such interfaces, so the format of these addresses
> wouldn't matter so much. Probably impossible at this point. ]
David Miller is authoritative here.
> I'm not arguing one way or the other, but it would be useful if
> someone could check exactly what the dependencies are right now. It
> seems like we're speculating a bit.
cheers, Joe
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: Chuck Lever @ 2009-08-13 21:02 UTC (permalink / raw)
To: Joe Perches; +Cc: Brian Haley, Jens Rosenboom, Linux Network Developers
In-Reply-To: <1250195675.28285.128.camel@Joe-Laptop.home>
On Aug 13, 2009, at 4:34 PM, Joe Perches wrote:
> On Thu, 2009-08-13 at 16:24 -0400, Brian Haley wrote:
>> Is your arch "um"? Seems like those are only defined there, I'm
>> building
>> a straight x86 kernel.
>
> Nope.
>
> I did make allyesconfig ; make lib/vsprintf.o lib ctype.o
> allnoconfig works though.
>
>> This core dumps when running "test", I'm still trying to track down
>> why.
>
> missing return on ip_addr_string
>
>> I think we're thinking too hard about this, I would think we'd always
>> want to print the shortened IPv6 address in debugging messages with
>> %pI6.
>
> True, but you can't tell in sprintf as it's used in seq.
>
> for instance:
> net/sunrpc/svcauth_unix.c: seq_printf(m, "%s %pI6 %s\n", im-
> >m_class, &addr, dom);
This one might be a bad example. RPC IPv6 support, especially server
side, isn't written in stone yet. User space may not even be ready
for an IPv6 address here; I can check. If user space happens to be
flexible here, then it won't matter if this particular instance is
shorthanded or not.
[ I would think user space in general should be using inet_pton(3)
everywhere for such interfaces, so the format of these addresses
wouldn't matter so much. Probably impossible at this point. ]
>> The %pi6 places need to stay since they're an API to userspace. I
>> don't
>> think we need the extra "c" and "c4" support.
>
> I'm pretty sure it can't change and a new form is needed
> so %pi6c should be OK.
>
> I'd rather not use another %p<foo> letter.
I'm not arguing one way or the other, but it would be useful if
someone could check exactly what the dependencies are right now. It
seems like we're speculating a bit.
>> One comment on a quick scan of the code:
>> ip6_addr[8 * 5] is fine here, we won't ever have all eight plus an
>> IPv4 address.
>
> I'm fixing it up and will resubmit something working in a little
> while.
>
> cheers, Joe
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: [Bugme-new] [Bug 13975] New: BUG: unable to handle kernel paging request at 000d7a0b
From: Andrew Morton @ 2009-08-13 20:51 UTC (permalink / raw)
To: tonywhite100; +Cc: bugzilla-daemon, bugme-daemon, netdev, Rusty Russell
In-Reply-To: <bug-13975-10286@http.bugzilla.kernel.org/>
(switched to email. Please respond via emailed reply-to-all, not via the
bugzilla web interface).
On Thu, 13 Aug 2009 14:02:01 GMT
bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=13975
>
> Summary: BUG: unable to handle kernel paging request at
> 000d7a0b
> Product: Memory Management
> Version: 2.5
> Kernel Version: 2.6.30.4
> Platform: All
> OS/Version: Linux
> Tree: Mainline
> Status: NEW
> Severity: normal
> Priority: P1
> Component: Page Allocator
> AssignedTo: akpm@linux-foundation.org
> ReportedBy: tonywhite100@googlemail.com
> Regression: Yes
>
Interesting.
> Last kernel version tried was 2.6.30.1 and I did not experience this bug using
> that kernel.
>
> The crash happens randomly at boot and requires an fsck to fix. The kernel
> locks up.
>
> Here's the interesting part of the log :
>
> Aug 13 07:54:02 pentium-three kernel: BUG: unable to handle kernel paging
> request at 000d7a0b
> Aug 13 07:54:02 pentium-three kernel: IP: [<c01596d4>] m_show+0x94/0x190
> Aug 13 07:54:02 pentium-three kernel: *pde = 00000000
> Aug 13 07:54:02 pentium-three kernel: Oops: 0000 [#1] PREEMPT SMP
> Aug 13 07:54:02 pentium-three kernel: last sysfs file:
> /sys/module/nf_conntrack_ftp/initstate
> Aug 13 07:54:02 pentium-three kernel: Modules linked in: fuse af_packet
> xt_tcpudp xt_limit nf_conntrack_ipv4 nf_defrag_ipv4 xt_state ipt_LOG ipt_REJECT
> nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables dm_crypt
> rt2500usb arc4 snd_cmipci ecb gameport snd_pcm_oss snd_mixer_oss snd_pcm
> snd_page_alloc snd_opl3_lib rt73usb snd_hwdep crc_itu_t snd_mpu401_uart
> snd_seq_dummy snd_seq_oss rt2x00usb snd_seq_midi rt2x00lib snd_rawmidi
> led_class input_polldev snd_seq_midi_event snd_seq mac80211 snd_timer
> snd_seq_device cfg80211 snd evdev parport_pc rtc_cmos soundcore pcspkr rtc_core
> parport i2c_piix4 rtc_lib i2c_core shpchp pci_hotplug ext4 mbcache jbd2 crc16
> dm_mirror dm_region_hash dm_log dm_snapshot dm_mod usbhid hid sg sr_mod cdrom
> sd_mod pata_acpi ata_generic ata_piix uhci_hcd libata 8139too ehci_hcd floppy
> 8139cp scsi_mod usbcore mii intel_agp
> Aug 13 07:54:02 pentium-three kernel:
> Aug 13 07:54:02 pentium-three kernel: Pid: 2489, comm: lsmod Not tainted
> (2.6.30-4.slh.2-sidux-686 #1) To be Filled
> Aug 13 07:54:02 pentium-three kernel: EIP: 0060:[<c01596d4>] EFLAGS: 00010246
> CPU: 0
> Aug 13 07:54:02 pentium-three kernel: EIP is at m_show+0x94/0x190
> Aug 13 07:54:02 pentium-three kernel: EAX: 00000000 EBX: 000d7a0b ECX: de10fef4
> EDX: 00000000
> Aug 13 07:54:02 pentium-three kernel: ESI: e100fc98 EDI: df169660 EBP: e100fb60
> ESP: de10fee8
> Aug 13 07:54:02 pentium-three kernel: DS: 007b ES: 007b FS: 00d8 GS: 0033 SS:
> 0068
> Aug 13 07:54:02 pentium-three kernel: Process lsmod (pid: 2489, ti=de10e000
> task=ddd0c840 task.ti=de10e000)
> Aug 13 07:54:02 pentium-three kernel: Stack:
> Aug 13 07:54:02 pentium-three kernel: df169660 c041097e e11ebc4c 0000e764
> e100fb64 c102a2e0 00010246 00000000
> Aug 13 07:54:02 pentium-three kernel: df169660 e100fb64 00000035 c01d3d56
> 00000200 00000000 000003fa b7f95006
> Aug 13 07:54:02 pentium-three kernel: df1aca80 df169688 00000006 00000061
> 0000002b 00000000 0000002a 00000000
> Aug 13 07:54:02 pentium-three kernel: Call Trace:
> Aug 13 07:54:02 pentium-three kernel: [<c01d3d56>] ? seq_read+0x206/0x3d0
> Aug 13 07:54:02 pentium-three kernel: [<c01d3b50>] ? seq_read+0x0/0x3d0
> Aug 13 07:54:02 pentium-three kernel: [<c01f84e4>] ? proc_reg_read+0x64/0xa0
> Aug 13 07:54:02 pentium-three kernel: [<c01f8480>] ? proc_reg_read+0x0/0xa0
> Aug 13 07:54:02 pentium-three kernel: [<c01bb59d>] ? vfs_read+0x9d/0x160
> Aug 13 07:54:02 pentium-three kernel: [<c01bb731>] ? sys_read+0x41/0x80
> Aug 13 07:54:02 pentium-three kernel: [<c010394c>] ? sysenter_do_call+0x12/0x28
> Aug 13 07:54:02 pentium-three kernel: Code: c6 34 01 00 00 39 f3 74 31 8d b6 00
> 00 00 00 8b 43 08 89 3c 24 c7 44 24 04 7e 09 41 c0 83 c0 0c 89 44 24 08 e8 ce
> a2 07 00 8b 1b <8b> 03 0f 18 00 90 39 f3 75 da b8 01 00 00 00 8b 8d d4 00 00 00
> Aug 13 07:54:02 pentium-three kernel: EIP: [<c01596d4>] m_show+0x94/0x190
> SS:ESP 0068:de10fee8
> Aug 13 07:54:02 pentium-three kernel: CR2: 00000000000d7a0b
> Aug 13 07:54:02 pentium-three kernel: ---[ end trace 1e50990a393b4447 ]---
>
> I'll attach lspci and if there is any other information required please just
> ask and I'll post it.
>
We died running `lsmod'.
We died in kernel/module.c:m_show().
The last sysfs file which userspace accessed was
/sys/module/nf_conntrack_ftp/initstate.
>From which I surmise that nf_conntrack_ftp has somehow done something
bad to the module-related metadata which kernel/module.c presents to
userspace via /sys/module/nf_conntrack_ftp/initstate. Or something like that.
Tell me: had you done any `rmmod's on that machine? Perhaps of
netfilter modules? If so, perhaps netfilter didn't properly clean up
after itself or something.
Oh. "The crash happens randomly at boot". That makes it hard.
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: Joe Perches @ 2009-08-13 20:34 UTC (permalink / raw)
To: Brian Haley; +Cc: Jens Rosenboom, Linux Network Developers, Chuck Lever
In-Reply-To: <4A847669.7050508@hp.com>
On Thu, 2009-08-13 at 16:24 -0400, Brian Haley wrote:
> Is your arch "um"? Seems like those are only defined there, I'm building
> a straight x86 kernel.
Nope.
I did make allyesconfig ; make lib/vsprintf.o lib ctype.o
allnoconfig works though.
> This core dumps when running "test", I'm still trying to track down why.
missing return on ip_addr_string
> I think we're thinking too hard about this, I would think we'd always
> want to print the shortened IPv6 address in debugging messages with %pI6.
True, but you can't tell in sprintf as it's used in seq.
for instance:
net/sunrpc/svcauth_unix.c: seq_printf(m, "%s %pI6 %s\n", im->m_class, &addr, dom);
> The %pi6 places need to stay since they're an API to userspace. I don't
> think we need the extra "c" and "c4" support.
I'm pretty sure it can't change and a new form is needed
so %pi6c should be OK.
I'd rather not use another %p<foo> letter.
> One comment on a quick scan of the code:
> ip6_addr[8 * 5] is fine here, we won't ever have all eight plus an IPv4 address.
I'm fixing it up and will resubmit something working in a little while.
cheers, Joe
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: Brian Haley @ 2009-08-13 20:28 UTC (permalink / raw)
To: Chuck Lever; +Cc: Joe Perches, Jens Rosenboom, Linux Network Developers
In-Reply-To: <5D6A7C11-B300-4E39-BBDF-EF18C4BAE419@oracle.com>
Chuck Lever wrote:
> On Aug 13, 2009, at 2:21 PM, Joe Perches wrote:
>> On Thu, 2009-08-13 at 14:15 -0400, Chuck Lever wrote:
>>> On Aug 13, 2009, at 2:10 PM, Joe Perches wrote:
>>>> The patch allows "%p6ic" for compressed and "%p6ic4" for compressed
>>>> with ipv4 last u32.
>>>
>>> Why do these need to be separate?
>>
>> Just an option.
>> I think it possible somebody will want "1::" instead of "1::0.0.0.0"
>
> Hrm.
>
> Do you have a use case? Really, it's pretty easy to tell when the
> mapped v4 presentation format should be used. See
> ipv6_addr_v4mapped(). Otherwise the mapped v4 presentation format
> should never be used.
>
> A problem with the existing %p[iI] implementation is that each call site
> has to have logic that figures out the address family of the address
> before calling sprintf(). This makes it difficult to use this facility
> with, for example, debugging messages, since you have to add address
> family detection logic at every debugging message call site. Lots of
> clutter and duplicated code.
>
> With %p6ic4, each call site now has to see that it's an IPv6 address,
> and then decide if the address is a mapped v4 address or not. It's the
> same logic everywhere.
>
> It seems to me it would be a lot more useful if we had a new %p6
> formatter that handled all types of IPv6 addresses properly, the way
> inet_ntop(3) does in user space. (Or even a new formatter that could
> handle both address families).
I would agree that this could be better, maybe after playing with this
some more it will be obvious what that something is. I'd be willing
to review any thoughts you have :)
-Brian
^ permalink raw reply
* Re: Page allocation failures in guest
From: Pierre Ossman @ 2009-08-13 20:25 UTC (permalink / raw)
To: Rusty Russell
Cc: Avi Kivity, Minchan Kim, kvm, LKML, linux-mm, Wu Fengguang,
KOSAKI Motohiro, Rik van Riel, netdev
In-Reply-To: <200908121501.53167.rusty@rustcorp.com.au>
[-- Attachment #1: Type: text/plain, Size: 1044 bytes --]
On Wed, 12 Aug 2009 15:01:52 +0930
Rusty Russell <rusty@rustcorp.com.au> wrote:
> On Wed, 12 Aug 2009 12:49:51 pm Rusty Russell wrote:
> > On Tue, 11 Aug 2009 04:22:53 pm Avi Kivity wrote:
> > > On 08/11/2009 09:32 AM, Pierre Ossman wrote:
> > > > I doesn't get out of it though, or at least the virtio net driver
> > > > wedges itself.
> >
> > There's a fixme to retry when this happens, but this is the first report
> > I've received. I'll check it out.
>
> Subject: virtio: net refill on out-of-memory
>
> If we run out of memory, use keventd to fill the buffer. There's a
> report of this happening: "Page allocation failures in guest",
> Message-ID: <20090713115158.0a4892b0@mjolnir.ossman.eu>
>
> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
>
Patch applied. Now we wait. :)
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by the
Swedish government. Make sure your server uses encryption
for SMTP traffic and consider using PGP for end-to-end
encryption.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 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