* [PATCH] net : enable tx time stamping in the vde driver.
From: Paul Chavent @ 2012-12-06 15:25 UTC (permalink / raw)
To: jdike, richard, user-mode-linux-devel, netdev, richardcochran
Cc: Paul Chavent
This new version moves the skb_tx_timestamp in the main uml
driver. This should avoid the need to call this function in each
transport (vde, slirp, tuntap, ...). It also add support for ethtool
get_ts_info.
Signed-off-by: Paul Chavent <paul.chavent@onera.fr>
---
arch/um/drivers/net_kern.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/um/drivers/net_kern.c b/arch/um/drivers/net_kern.c
index b1314eb..5aa8696 100644
--- a/arch/um/drivers/net_kern.c
+++ b/arch/um/drivers/net_kern.c
@@ -218,6 +218,7 @@ static int uml_net_start_xmit(struct sk_buff *skb, struct net_device *dev)
spin_lock_irqsave(&lp->lock, flags);
len = (*lp->write)(lp->fd, skb, lp);
+ skb_tx_timestampns(skb);
if (len == skb->len) {
dev->stats.tx_packets++;
@@ -281,6 +282,7 @@ static void uml_net_get_drvinfo(struct net_device *dev,
static const struct ethtool_ops uml_net_ethtool_ops = {
.get_drvinfo = uml_net_get_drvinfo,
.get_link = ethtool_op_get_link,
+ .get_ts_info = ethtool_op_get_ts_info,
};
static void uml_net_user_timer_expire(unsigned long _conn)
--
1.7.12.1
^ permalink raw reply related
* Re: [Pv-drivers] [PATCH 0/6] VSOCK for Linux upstreaming
From: Andy King @ 2012-12-06 15:28 UTC (permalink / raw)
To: Anthony Liguori
Cc: Benjamin Herrenschmidt, pv-drivers, netdev, linux-kernel,
virtualization, gregkh, David Miller, georgezhang
In-Reply-To: <50A55F57.7080804@us.ibm.com>
Hi Anthony,
> This was already done in a hypervisor neutral way using virtio:
>
> http://lists.openwall.net/netdev/2008/12/14/8
>
> The concept was Nacked and that led to the abomination of
> virtio-serial. If an address family for virtualization is on the
> table, we should reconsider AF_VMCHANNEL.
I finally had a look at your patch. Please correct me if I'm wrong,
but it seems that the peer of an AF_VMCHANNEL connection is a virtio
channel inside the hypervisor, i.e., the other end is _not_ sockets,
right?
That's quite a bit different from vSockets, where both sides use the
socket interface, even within the VMX process in our hypervisor. We
also intend for arbitrary host processes -- those outside the
hypervisor -- to use it via the sockets interface. We have shipping
applications that do just that, where communication is between a guest
process and a host service, with both sides using the standard socket
API but with the vSockets address family. We also encourage people to
write such VM-to-host applications, and we've been shipping the
vSockets header in our host-side products to allow people to do just
that.
So I think in that sense vSockets is somewhat more general, and we'd
obviously prefer to go with our socket family and address structure
if LKML is open to something like this.
Thanks!
- Andy
PS I realize we still owe LKML a spec for the vSockets protocol.
^ permalink raw reply
* Re: [net-next PATCH V3-evictor] net: frag evictor, avoid killing warm frag queues
From: Jesper Dangaard Brouer @ 2012-12-06 15:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Florian Westphal, David S. Miller, netdev, Thomas Graf,
Paul E. McKenney, Cong Wang, Herbert Xu
In-Reply-To: <1354805276.31222.803.camel@edumazet-glaptop>
On Thu, 2012-12-06 at 06:47 -0800, Eric Dumazet wrote:
> On Thu, 2012-12-06 at 14:55 +0100, Jesper Dangaard Brouer wrote:
>
> > The LRU might be the correct solution after all. If I enable Ethernet
> > flow-control again, then I have a hard time "activating" the evictor
> > code (with thresh 4M/3M) . I'll need a separate DoS program, which can
> > send incomplete fragments (in back-to-back bursts) to provoke the
> > evictor and LRU.
> >
> > My cheap DoS reproducer-hack is to disable Ethernet flow-control on only
> > one interface (out of 3), to cause packet drops and the incomplete
> > fragments. The current preliminary results is that the two other
> > interfaces still gets packets through, we don't get the zero throughput
> > situation.
> > Two interfaces and no DoS: 15342 Mbit/s
> > Three interfaces and DoS: 7355 Mbit/s
> >
> > The reduction might look big, but you have to take into account, that
> > "activating" the evictor code, is also causing scalability issues of its
> > own (which could account for the performance drop it self).
>
> I would try removing the LRU, but keeping the age information (jiffie of
> last valid frag received on one inet_frag_queue)
I don't think its worth optimizing further, atm.
Because, the test above is without any of my SMP scalability fixes.
With my SMP fixes the result is, full scalability:
Three interfaces: (9601+6723+9432) = 25756 Mbit/s
And the 6723 Mbit/s number, is because the old 10G NIC cannot generate
anymore...
And I basically cannot use the cheap DoS reproducer-hack, as the
machine/code-path is now too fast...
Running with 4 interfaces, and starting 6 netperf's (to cause more
interleaving and higher mem usage):
4716+8042+8765+6204+2475+4568 = 34770 Mbit/s
I could just manage to get to do IpReasmFails = 14.
[jbrouer@dragon ~]$ nstat > /dev/null && sleep 1 && nstat
#kernel
IpInReceives 2980048 0.0
IpInDelivers 66217 0.0
IpReasmReqds 2980040 0.0
IpReasmOKs 66218 0.0
IpReasmFails 14 0.0
UdpInDatagrams 66218 0.0
IpExtInOctets 4397976885 0.0
So, after the SMP fixes, its very hard to "activate" the evictor. We
would need to find a slower e.g. embedded box and tune the evictor on
that, as a multi-CPU machine basically will scale "too-well" now ;-)
--Jesper
^ permalink raw reply
* [PULL net-next] vhost: changes for 3.8
From: Michael S. Tsirkin @ 2012-12-06 15:18 UTC (permalink / raw)
To: David Miller
Cc: kvm, virtualization, netdev, linux-kernel, dinggnu, mst,
yongjun_wei
The following changes since commit b93196dc5af7729ff7cc50d3d322ab1a364aa14f:
net: fix some compiler warning in net/core/neighbour.c (2012-12-05 21:50:37 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git vhost-net-next
for you to fetch changes up to 405d55c99da7a3045275fdb1a30614293a53c6e7:
tcm_vhost: remove unused variable in vhost_scsi_allocate_cmd() (2012-12-06 17:09:19 +0200)
----------------------------------------------------------------
Cong Ding (1):
tools:virtio: fix compilation warning
Michael S. Tsirkin (4):
vhost: avoid backend flush on vring ops
vhost-net: flush outstanding DMAs on memory change
vhost-net: skip head management if no outstanding
vhost-net: enable zerocopy tx by default
Wei Yongjun (1):
tcm_vhost: remove unused variable in vhost_scsi_allocate_cmd()
drivers/vhost/net.c | 51 ++++++++++++++++++++++++++++++----------------
drivers/vhost/tcm_vhost.c | 7 ++++---
drivers/vhost/vhost.c | 7 +++----
drivers/vhost/vhost.h | 3 ++-
tools/virtio/virtio_test.c | 2 +-
5 files changed, 44 insertions(+), 26 deletions(-)
^ permalink raw reply
* Re: at91sam9260 MACB problem with IP fragmentation
From: Erwin Rol @ 2012-12-06 15:15 UTC (permalink / raw)
To: Nicolas Ferre
Cc: linux-kernel, Havard Skinnemoen, linux-arm-kernel, matteo.fortini,
netdev
In-Reply-To: <50C09D2E.8050608@atmel.com>
Hey Nicolas,
On 6-12-2012 14:27, Nicolas Ferre wrote:
> Erwin,
>
> On 12/06/2012 12:32 PM, Erwin Rol :
>> Hello Nicolas, Havard, all,
>>
>> I have a very obscure problem with a at91sam9260 board (almost 1 to 1
>> copy of the Atmel EK).
>>
>> <snip>
>>
> [..]
>
> It seems that Matteo has the same behavior: check here:
> http://www.spinics.net/lists/netdev/msg218951.html
The difference seems to be that in Matteo's case the receiving stalls.
In my case it is the sending that stalls. I see the UDP datagram in
userspace and the sendto call also returns without error, but the data
does not end up on the network (until the next packet is send)
> I am working on the macb driver right now, so I will try to reproduce
> and track this issue on my side.
That would be really great, and thank you for the quick reply. If you
have anything that I should try or test on my hardware just let me know.
BTW: A quick check on a at91sam9263 board did not show the problem. I
will try to verify if it really does work on a 9263, cause maybe it just
more rare on a 9263.
- Erwin
^ permalink raw reply
* Re: [net-next PATCH V3-evictor] net: frag evictor, avoid killing warm frag queues
From: Eric Dumazet @ 2012-12-06 14:47 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Florian Westphal, David S. Miller, netdev, Thomas Graf,
Paul E. McKenney, Cong Wang, Herbert Xu
In-Reply-To: <1354802100.20888.242.camel@localhost>
On Thu, 2012-12-06 at 14:55 +0100, Jesper Dangaard Brouer wrote:
> Perhaps. But do note my bashing of the LRU list were wrong. I planned
> to explain that in a separate mail, but basically I were causing a DoS
> attack with incomplete fragments on my self, because I had disabled
> Ethernet flow-control. Which led me to some false assumptions on the
> LRU list behavior (sorry).
>
> The LRU might be the correct solution after all. If I enable Ethernet
> flow-control again, then I have a hard time "activating" the evictor
> code (with thresh 4M/3M) . I'll need a separate DoS program, which can
> send incomplete fragments (in back-to-back bursts) to provoke the
> evictor and LRU.
>
> My cheap DoS reproducer-hack is to disable Ethernet flow-control on only
> one interface (out of 3), to cause packet drops and the incomplete
> fragments. The current preliminary results is that the two other
> interfaces still gets packets through, we don't get the zero throughput
> situation.
> Two interfaces and no DoS: 15342 Mbit/s
> Three interfaces and DoS: 7355 Mbit/s
>
> The reduction might look big, but you have to take into account, that
> "activating" the evictor code, is also causing scalability issues of its
> own (which could account for the performance drop it self).
I would try removing the LRU, but keeping the age information (jiffie of
last valid frag received on one inet_frag_queue)
The eviction would be a function of the current memory used for the
frags (percpu_counter for good SMP scalability), divided by the max
allowed size, and ipfrag_time.
Under load, we would evict inet_frag_queue before the ipfrag_time timer,
without necessarily having to scan whole frags, only the ones we find in
the bucket we need to parse anyway (and lock)
The whole idea of a full garbage collect under softirq is not scalable,
as it locks a CPU in a non preemptible section for too long.
^ permalink raw reply
* Re: [PATCH] sctp: Fix compiler warning when CONFIG_DEBUG_SECTION_MISMATCH=y
From: Vlad Yasevich @ 2012-12-06 14:40 UTC (permalink / raw)
To: Christoph Paasch; +Cc: linux-sctp, davem, sri, nhorman, netdev
In-Reply-To: <1354798992-25622-1-git-send-email-christoph.paasch@uclouvain.be>
On 12/06/2012 08:03 AM, Christoph Paasch wrote:
> WARNING: net/sctp/sctp.o(.text+0x72f1): Section mismatch in reference
> from the function sctp_net_init() to the function
> .init.text:sctp_proc_init()
> The function sctp_net_init() references
> the function __init sctp_proc_init().
> This is often because sctp_net_init lacks a __init
> annotation or the annotation of sctp_proc_init is wrong.
>
> And put __net_init after 'int' for sctp_proc_init - as it is done
> everywhere else in the sctp-stack.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
-vlad
> ---
> net/sctp/protocol.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 456bc3d..2c7785b 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -86,7 +86,7 @@ int sysctl_sctp_rmem[3];
> int sysctl_sctp_wmem[3];
>
> /* Set up the proc fs entry for the SCTP protocol. */
> -static __net_init int sctp_proc_init(struct net *net)
> +static int __net_init sctp_proc_init(struct net *net)
> {
> #ifdef CONFIG_PROC_FS
> net->sctp.proc_net_sctp = proc_net_mkdir(net, "sctp", net->proc_net);
> @@ -1165,7 +1165,7 @@ static void sctp_v4_del_protocol(void)
> unregister_inetaddr_notifier(&sctp_inetaddr_notifier);
> }
>
> -static int sctp_net_init(struct net *net)
> +static int __net_init sctp_net_init(struct net *net)
> {
> int status;
>
> @@ -1290,7 +1290,7 @@ err_sysctl_register:
> return status;
> }
>
> -static void sctp_net_exit(struct net *net)
> +static void __net_exit sctp_net_exit(struct net *net)
> {
> /* Free the local address list */
> sctp_free_addr_wq(net);
>
^ permalink raw reply
* Re: [PATCH] tulip: Fix compiler warning when CONFIG_DEBUG_SECTION_MISMATCH=y
From: Ben Hutchings @ 2012-12-06 14:20 UTC (permalink / raw)
To: Christoph Paasch; +Cc: Grant Grundler, David Miller, netdev
In-Reply-To: <1354799067-25680-1-git-send-email-christoph.paasch@uclouvain.be>
On Thu, 2012-12-06 at 14:04 +0100, Christoph Paasch wrote:
> WARNING: drivers/net/ethernet/dec/tulip/tulip.o(.text+0x4057): Section
> mismatch in reference from the function tulip_init_one() to the variable
> .devinit.rodata:early_486_chipsets
> The function tulip_init_one() references
> the variable __devinitconst early_486_chipsets.
> This is often because tulip_init_one lacks a __devinitconst
> annotation or the annotation of early_486_chipsets is wrong.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
[...]
The section mismatch will be resolved shortly as hotplug is being made
non-optional and all the __devinit and similar section qualifiers will
go away. There's no need to make local fixes like this now.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC PATCH v2 3/3] tun: fix LSM/SELinux labeling of tun/tap devices
From: Michael S. Tsirkin @ 2012-12-06 14:12 UTC (permalink / raw)
To: Jason Wang; +Cc: Paul Moore, netdev, linux-security-module, selinux
In-Reply-To: <1505323.yRRvBmo94H@jason-thinkpad-t430s>
On Thu, Dec 06, 2012 at 09:51:13PM +0800, Jason Wang wrote:
> On Thursday, December 06, 2012 12:33:25 PM Michael S. Tsirkin wrote:
> > On Wed, Dec 05, 2012 at 03:26:19PM -0500, Paul Moore wrote:
> > > This patch corrects some problems with LSM/SELinux that were introduced
> > > with the multiqueue patchset. The problem stems from the fact that the
> > > multiqueue work changed the relationship between the tun device and its
> > > associated socket; before the socket persisted for the life of the
> > > device, however after the multiqueue changes the socket only persisted
> > > for the life of the userspace connection (fd open). For non-persistent
> > > devices this is not an issue, but for persistent devices this can cause
> > > the tun device to lose its SELinux label.
> > >
> > > We correct this problem by adding an opaque LSM security blob to the
> > > tun device struct which allows us to have the LSM security state, e.g.
> > > SELinux labeling information, persist for the lifetime of the tun
> > > device. In the process we tweak the LSM hooks to work with this new
> > > approach to TUN device/socket labeling and introduce a new LSM hook,
> > > security_tun_dev_create_queue(), to approve requests to create a new
> > > TUN queue via TUNSETQUEUE.
> > >
> > > The SELinux code has been adjusted to match the new LSM hooks, the
> > > other LSMs do not make use of the LSM TUN controls. This patch makes
> > > use of the recently added "tun_socket:create_queue" permission to
> > > restrict access to the TUNSETQUEUE operation. On older SELinux
> > > policies which do not define the "tun_socket:create_queue" permission
> > > the access control decision for TUNSETQUEUE will be handled according
> > > to the SELinux policy's unknown permission setting.
> > >
> > > Signed-off-by: Paul Moore <pmoore@redhat.com>
> >
> > OK so just to verify: this can be used to ensure that qemu
> > process that has the queue fd can only attach it to
> > a specific device, right?
>
> I think it can't.
> And I'm not sure whether we need selinux help to do this.
Well without selinux I doi not see a problem.
If you can do SETQUEUE you can do SETIFF too and then
you can attach to tap.
> Looks like we can do this without selinux through:
>
> 1. Don't assign a NULL pointer to tfile->tun during file detaching
So you detach from tun but keep a pointer to it? Not good.
> 2. Compare the ifr_name and the name of tfil->tun, if not equal, return -EINVAL
> 3. Set a special flag in tun_detach_all() to notify the fd is not usable, and
> can't be used for future attaching.
>
> Afther this, only the device that the fd is first attched through (TUNSETIFF or
> TUNSETQUEUE) is allowed to be attached again.
This looks like a hard-coded security policy.
The problem is not detach the problem is attach,
we should solve it there.
> >
> > > ---
> > >
> > > drivers/net/tun.c | 26 +++++++++++++---
> > > include/linux/security.h | 59
> > > +++++++++++++++++++++++++++++-------- security/capability.c
> > > | 24 +++++++++++++--
> > > security/security.c | 28 ++++++++++++++----
> > > security/selinux/hooks.c | 50 ++++++++++++++++++++++++-------
> > > security/selinux/include/objsec.h | 4 +++
> > > 6 files changed, 153 insertions(+), 38 deletions(-)
> > >
> > > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > > index 14a0454..fb8148b 100644
> > > --- a/drivers/net/tun.c
> > > +++ b/drivers/net/tun.c
> > > @@ -182,6 +182,7 @@ struct tun_struct {
> > >
> > > struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
> > > struct timer_list flow_gc_timer;
> > > unsigned long ageing_time;
> > >
> > > + void *security;
> > >
> > > };
> > >
> > > static inline u32 tun_hashfn(u32 rxhash)
> > >
> > > @@ -465,6 +466,10 @@ static int tun_attach(struct tun_struct *tun, struct
> > > file *file)>
> > > struct tun_file *tfile = file->private_data;
> > > int err;
> > >
> > > + err = security_tun_dev_attach(tfile->socket.sk, tun->security);
> > > + if (err < 0)
> > > + goto out;
> > > +
> > >
> > > err = -EINVAL;
> > > if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
> > >
> > > goto out;
> > >
> > > @@ -1348,6 +1353,7 @@ static void tun_free_netdev(struct net_device *dev)
> > >
> > > struct tun_struct *tun = netdev_priv(dev);
> > >
> > > tun_flow_uninit(tun);
> > >
> > > + security_tun_dev_free_security(tun->security);
> > >
> > > free_netdev(dev);
> > >
> > > }
> > >
> > > @@ -1534,7 +1540,7 @@ static int tun_set_iff(struct net *net, struct file
> > > *file, struct ifreq *ifr)>
> > > if (tun_not_capable(tun))
> > >
> > > return -EPERM;
> > >
> > > - err = security_tun_dev_attach(tfile->socket.sk);
> > > + err = security_tun_dev_open(tun->security);
> > >
> > > if (err < 0)
> > >
> > > return err;
> > >
> > > @@ -1587,7 +1593,9 @@ static int tun_set_iff(struct net *net, struct file
> > > *file, struct ifreq *ifr)>
> > > spin_lock_init(&tun->lock);
> > >
> > > - security_tun_dev_post_create(&tfile->sk);
> > > + err = security_tun_dev_alloc_security(&tun->security);
> > > + if (err < 0)
> > > + goto err_free_dev;
> > >
> > > tun_net_init(dev);
> > >
> > > @@ -1767,12 +1775,18 @@ static int tun_set_queue(struct file *file, struct
> > > ifreq *ifr)>
> > > tun = netdev_priv(dev);
> > > if (dev->netdev_ops != &tap_netdev_ops &&
> > >
> > > - dev->netdev_ops != &tun_netdev_ops)
> > > + dev->netdev_ops != &tun_netdev_ops) {
> > >
> > > ret = -EINVAL;
> > >
> > > - else if (tun_not_capable(tun))
> > > + goto unlock;
> > > + }
> > > + if (tun_not_capable(tun)) {
> > >
> > > ret = -EPERM;
> > >
> > > - else
> > > - ret = tun_attach(tun, file);
> > > + goto unlock;
> > > + }
> > > + ret = security_tun_dev_create_queue(tun->security);
> > > + if (ret < 0)
> > > + goto unlock;
> > > + ret = tun_attach(tun, file);
> > >
> > > } else if (ifr->ifr_flags & IFF_DETACH_QUEUE)
> > >
> > > __tun_detach(tfile, false);
> > >
> > > else
> > >
> > > diff --git a/include/linux/security.h b/include/linux/security.h
> > > index 05e88bd..8ea923b 100644
> > > --- a/include/linux/security.h
> > > +++ b/include/linux/security.h
> > > @@ -983,17 +983,29 @@ static inline void security_free_mnt_opts(struct
> > > security_mnt_opts *opts)>
> > > * tells the LSM to decrement the number of secmark labeling rules loaded
> > > * @req_classify_flow:
> > > * Sets the flow's sid to the openreq sid.
> > >
> > > + * @tun_dev_alloc_security:
> > > + * This hook allows a module to allocate a security structure for a TUN
> > > + * device.
> > > + * @security pointer to a security structure pointer.
> > > + * Returns a zero on success, negative values on failure.
> > > + * @tun_dev_free_security:
> > > + * This hook allows a module to free the security structure for a TUN
> > > + * device.
> > > + * @security pointer to the TUN device's security structure
> > >
> > > * @tun_dev_create:
> > > * Check permissions prior to creating a new TUN device.
> > >
> > > - * @tun_dev_post_create:
> > > - * This hook allows a module to update or allocate a per-socket security
> > > - * structure.
> > > - * @sk contains the newly created sock structure.
> > > + * @tun_dev_create_queue:
> > > + * Check permissions prior to creating a new TUN device queue.
> > > + * @security pointer to the TUN device's security structure.
> > >
> > > * @tun_dev_attach:
> > > - * Check permissions prior to attaching to a persistent TUN device. This
> > > - * hook can also be used by the module to update any security state
> > > + * This hook can be used by the module to update any security state
> > >
> > > * associated with the TUN device's sock structure.
> > > * @sk contains the existing sock structure.
> > >
> > > + * @security pointer to the TUN device's security structure.
> > > + * @tun_dev_open:
> > > + * This hook can be used by the module to update any security state
> > > + * associated with the TUN device's security structure.
> > > + * @security pointer to the TUN devices's security structure.
> > >
> > > *
> > > * Security hooks for XFRM operations.
> > > *
> > >
> > > @@ -1613,9 +1625,12 @@ struct security_operations {
> > >
> > > void (*secmark_refcount_inc) (void);
> > > void (*secmark_refcount_dec) (void);
> > > void (*req_classify_flow) (const struct request_sock *req, struct flowi
> > > *fl);>
> > > - int (*tun_dev_create)(void);
> > > - void (*tun_dev_post_create)(struct sock *sk);
> > > - int (*tun_dev_attach)(struct sock *sk);
> > > + int (*tun_dev_alloc_security) (void **security);
> > > + void (*tun_dev_free_security) (void *security);
> > > + int (*tun_dev_create) (void);
> > > + int (*tun_dev_create_queue) (void *security);
> > > + int (*tun_dev_attach) (struct sock *sk, void *security);
> > > + int (*tun_dev_open) (void *security);
> > >
> > > #endif /* CONFIG_SECURITY_NETWORK */
> > >
> > > #ifdef CONFIG_SECURITY_NETWORK_XFRM
> > >
> > > @@ -2553,9 +2568,12 @@ void security_inet_conn_established(struct sock
> > > *sk,
> > >
> > > int security_secmark_relabel_packet(u32 secid);
> > > void security_secmark_refcount_inc(void);
> > > void security_secmark_refcount_dec(void);
> > >
> > > +int security_tun_dev_alloc_security(void **security);
> > > +void security_tun_dev_free_security(void *security);
> > >
> > > int security_tun_dev_create(void);
> > >
> > > -void security_tun_dev_post_create(struct sock *sk);
> > > -int security_tun_dev_attach(struct sock *sk);
> > > +int security_tun_dev_create_queue(void *security);
> > > +int security_tun_dev_attach(struct sock *sk, void *security);
> > > +int security_tun_dev_open(void *security);
> > >
> > > #else /* CONFIG_SECURITY_NETWORK */
> > > static inline int security_unix_stream_connect(struct sock *sock,
> > >
> > > @@ -2720,16 +2738,31 @@ static inline void
> > > security_secmark_refcount_dec(void)>
> > > {
> > > }
> > >
> > > +static inline int security_tun_dev_alloc_security(void **security)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static inline void security_tun_dev_free_security(void *security)
> > > +{
> > > +}
> > > +
> > >
> > > static inline int security_tun_dev_create(void)
> > > {
> > >
> > > return 0;
> > >
> > > }
> > >
> > > -static inline void security_tun_dev_post_create(struct sock *sk)
> > > +static inline int security_tun_dev_create_queue(void *security)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static inline int security_tun_dev_attach(struct sock *sk, void
> > > *security)
> > >
> > > {
> > >
> > > + return 0;
> > >
> > > }
> > >
> > > -static inline int security_tun_dev_attach(struct sock *sk)
> > > +static inline int security_tun_dev_open(void *security)
> > >
> > > {
> > >
> > > return 0;
> > >
> > > }
> > >
> > > diff --git a/security/capability.c b/security/capability.c
> > > index b14a30c..bf4cbf2 100644
> > > --- a/security/capability.c
> > > +++ b/security/capability.c
> > > @@ -704,16 +704,31 @@ static void cap_req_classify_flow(const struct
> > > request_sock *req,>
> > > {
> > > }
> > >
> > > +static int cap_tun_dev_alloc_security(void **security)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static void cap_tun_dev_free_security(void *security)
> > > +{
> > > +}
> > > +
> > >
> > > static int cap_tun_dev_create(void)
> > > {
> > >
> > > return 0;
> > >
> > > }
> > >
> > > -static void cap_tun_dev_post_create(struct sock *sk)
> > > +static int cap_tun_dev_create_queue(void *security)
> > > +{
> > > + return 0;
> > > +}
> > > +
> > > +static int cap_tun_dev_attach(struct sock *sk, void *security)
> > >
> > > {
> > >
> > > + return 0;
> > >
> > > }
> > >
> > > -static int cap_tun_dev_attach(struct sock *sk)
> > > +static int cap_tun_dev_open(void *security)
> > >
> > > {
> > >
> > > return 0;
> > >
> > > }
> > >
> > > @@ -1044,8 +1059,11 @@ void __init security_fixup_ops(struct
> > > security_operations *ops)>
> > > set_to_cap_if_null(ops, secmark_refcount_inc);
> > > set_to_cap_if_null(ops, secmark_refcount_dec);
> > > set_to_cap_if_null(ops, req_classify_flow);
> > >
> > > + set_to_cap_if_null(ops, tun_dev_alloc_security);
> > > + set_to_cap_if_null(ops, tun_dev_free_security);
> > >
> > > set_to_cap_if_null(ops, tun_dev_create);
> > >
> > > - set_to_cap_if_null(ops, tun_dev_post_create);
> > > + set_to_cap_if_null(ops, tun_dev_create_queue);
> > > + set_to_cap_if_null(ops, tun_dev_open);
> > >
> > > set_to_cap_if_null(ops, tun_dev_attach);
> > >
> > > #endif /* CONFIG_SECURITY_NETWORK */
> > > #ifdef CONFIG_SECURITY_NETWORK_XFRM
> > >
> > > diff --git a/security/security.c b/security/security.c
> > > index 8dcd4ae..4d82654 100644
> > > --- a/security/security.c
> > > +++ b/security/security.c
> > > @@ -1244,24 +1244,42 @@ void security_secmark_refcount_dec(void)
> > >
> > > }
> > > EXPORT_SYMBOL(security_secmark_refcount_dec);
> > >
> > > +int security_tun_dev_alloc_security(void **security)
> > > +{
> > > + return security_ops->tun_dev_alloc_security(security);
> > > +}
> > > +EXPORT_SYMBOL(security_tun_dev_alloc_security);
> > > +
> > > +void security_tun_dev_free_security(void *security)
> > > +{
> > > + security_ops->tun_dev_free_security(security);
> > > +}
> > > +EXPORT_SYMBOL(security_tun_dev_free_security);
> > > +
> > >
> > > int security_tun_dev_create(void)
> > > {
> > >
> > > return security_ops->tun_dev_create();
> > >
> > > }
> > > EXPORT_SYMBOL(security_tun_dev_create);
> > >
> > > -void security_tun_dev_post_create(struct sock *sk)
> > > +int security_tun_dev_create_queue(void *security)
> > >
> > > {
> > >
> > > - return security_ops->tun_dev_post_create(sk);
> > > + return security_ops->tun_dev_create_queue(security);
> > >
> > > }
> > >
> > > -EXPORT_SYMBOL(security_tun_dev_post_create);
> > > +EXPORT_SYMBOL(security_tun_dev_create_queue);
> > >
> > > -int security_tun_dev_attach(struct sock *sk)
> > > +int security_tun_dev_attach(struct sock *sk, void *security)
> > >
> > > {
> > >
> > > - return security_ops->tun_dev_attach(sk);
> > > + return security_ops->tun_dev_attach(sk, security);
> > >
> > > }
> > > EXPORT_SYMBOL(security_tun_dev_attach);
> > >
> > > +int security_tun_dev_open(void *security)
> > > +{
> > > + return security_ops->tun_dev_open(security);
> > > +}
> > > +EXPORT_SYMBOL(security_tun_dev_open);
> > > +
> > >
> > > #endif /* CONFIG_SECURITY_NETWORK */
> > >
> > > #ifdef CONFIG_SECURITY_NETWORK_XFRM
> > >
> > > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > > index 61a5336..f1efb08 100644
> > > --- a/security/selinux/hooks.c
> > > +++ b/security/selinux/hooks.c
> > > @@ -4399,6 +4399,24 @@ static void selinux_req_classify_flow(const struct
> > > request_sock *req,>
> > > fl->flowi_secid = req->secid;
> > >
> > > }
> > >
> > > +static int selinux_tun_dev_alloc_security(void **security)
> > > +{
> > > + struct tun_security_struct *tunsec;
> > > +
> > > + tunsec = kzalloc(sizeof(*tunsec), GFP_KERNEL);
> > > + if (!tunsec)
> > > + return -ENOMEM;
> > > + tunsec->sid = current_sid();
> > > +
> > > + *security = tunsec;
> > > + return 0;
> > > +}
> > > +
> > > +static void selinux_tun_dev_free_security(void *security)
> > > +{
> > > + kfree(security);
> > > +}
> > > +
> > >
> > > static int selinux_tun_dev_create(void)
> > > {
> > >
> > > u32 sid = current_sid();
> > >
> > > @@ -4414,8 +4432,17 @@ static int selinux_tun_dev_create(void)
> > >
> > > NULL);
> > >
> > > }
> > >
> > > -static void selinux_tun_dev_post_create(struct sock *sk)
> > > +static int selinux_tun_dev_create_queue(void *security)
> > >
> > > {
> > >
> > > + struct tun_security_struct *tunsec = security;
> > > +
> > > + return avc_has_perm(current_sid(), tunsec->sid, SECCLASS_TUN_SOCKET,
> > > + TUN_SOCKET__CREATE_QUEUE, NULL);
> > > +}
> > > +
> > > +static int selinux_tun_dev_attach(struct sock *sk, void *security)
> > > +{
> > > + struct tun_security_struct *tunsec = security;
> > >
> > > struct sk_security_struct *sksec = sk->sk_security;
> > >
> > > /* we don't currently perform any NetLabel based labeling here and it
> > >
> > > @@ -4425,20 +4452,19 @@ static void selinux_tun_dev_post_create(struct
> > > sock *sk)>
> > > * cause confusion to the TUN user that had no idea network labeling
> > > * protocols were being used */
> > >
> > > - /* see the comments in selinux_tun_dev_create() about why we don't use
> > > - * the sockcreate SID here */
> > > -
> > > - sksec->sid = current_sid();
> > > + sksec->sid = tunsec->sid;
> > >
> > > sksec->sclass = SECCLASS_TUN_SOCKET;
> > >
> > > +
> > > + return 0;
> > >
> > > }
> > >
> > > -static int selinux_tun_dev_attach(struct sock *sk)
> > > +static int selinux_tun_dev_open(void *security)
> > >
> > > {
> > >
> > > - struct sk_security_struct *sksec = sk->sk_security;
> > > + struct tun_security_struct *tunsec = security;
> > >
> > > u32 sid = current_sid();
> > > int err;
> > >
> > > - err = avc_has_perm(sid, sksec->sid, SECCLASS_TUN_SOCKET,
> > > + err = avc_has_perm(sid, tunsec->sid, SECCLASS_TUN_SOCKET,
> > >
> > > TUN_SOCKET__RELABELFROM, NULL);
> > >
> > > if (err)
> > >
> > > return err;
> > >
> > > @@ -4446,8 +4472,7 @@ static int selinux_tun_dev_attach(struct sock *sk)
> > >
> > > TUN_SOCKET__RELABELTO, NULL);
> > >
> > > if (err)
> > >
> > > return err;
> > >
> > > -
> > > - sksec->sid = sid;
> > > + tunsec->sid = sid;
> > >
> > > return 0;
> > >
> > > }
> > >
> > > @@ -5642,9 +5667,12 @@ static struct security_operations selinux_ops = {
> > >
> > > .secmark_refcount_inc = selinux_secmark_refcount_inc,
> > > .secmark_refcount_dec = selinux_secmark_refcount_dec,
> > > .req_classify_flow = selinux_req_classify_flow,
> > >
> > > + .tun_dev_alloc_security = selinux_tun_dev_alloc_security,
> > > + .tun_dev_free_security = selinux_tun_dev_free_security,
> > >
> > > .tun_dev_create = selinux_tun_dev_create,
> > >
> > > - .tun_dev_post_create = selinux_tun_dev_post_create,
> > > + .tun_dev_create_queue = selinux_tun_dev_create_queue,
> > >
> > > .tun_dev_attach = selinux_tun_dev_attach,
> > >
> > > + .tun_dev_open = selinux_tun_dev_open,
> > >
> > > #ifdef CONFIG_SECURITY_NETWORK_XFRM
> > >
> > > .xfrm_policy_alloc_security = selinux_xfrm_policy_alloc,
> > >
> > > diff --git a/security/selinux/include/objsec.h
> > > b/security/selinux/include/objsec.h index 26c7eee..aa47bca 100644
> > > --- a/security/selinux/include/objsec.h
> > > +++ b/security/selinux/include/objsec.h
> > > @@ -110,6 +110,10 @@ struct sk_security_struct {
> > >
> > > u16 sclass; /* sock security class */
> > >
> > > };
> > >
> > > +struct tun_security_struct {
> > > + u32 sid; /* SID for the tun device sockets */
> > > +};
> > > +
> > >
> > > struct key_security_struct {
> > >
> > > u32 sid; /* SID of key */
> > >
> > > };
^ permalink raw reply
* Re: [PATCH] sctp: Fix compiler warning when CONFIG_DEBUG_SECTION_MISMATCH=y
From: Neil Horman @ 2012-12-06 14:11 UTC (permalink / raw)
To: Christoph Paasch; +Cc: vyasevich, linux-sctp, davem, sri, netdev
In-Reply-To: <1354798992-25622-1-git-send-email-christoph.paasch@uclouvain.be>
On Thu, Dec 06, 2012 at 02:03:12PM +0100, Christoph Paasch wrote:
> WARNING: net/sctp/sctp.o(.text+0x72f1): Section mismatch in reference
> from the function sctp_net_init() to the function
> .init.text:sctp_proc_init()
> The function sctp_net_init() references
> the function __init sctp_proc_init().
> This is often because sctp_net_init lacks a __init
> annotation or the annotation of sctp_proc_init is wrong.
>
> And put __net_init after 'int' for sctp_proc_init - as it is done
> everywhere else in the sctp-stack.
>
> Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
> ---
> net/sctp/protocol.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
> index 456bc3d..2c7785b 100644
> --- a/net/sctp/protocol.c
> +++ b/net/sctp/protocol.c
> @@ -86,7 +86,7 @@ int sysctl_sctp_rmem[3];
> int sysctl_sctp_wmem[3];
>
> /* Set up the proc fs entry for the SCTP protocol. */
> -static __net_init int sctp_proc_init(struct net *net)
> +static int __net_init sctp_proc_init(struct net *net)
> {
> #ifdef CONFIG_PROC_FS
> net->sctp.proc_net_sctp = proc_net_mkdir(net, "sctp", net->proc_net);
> @@ -1165,7 +1165,7 @@ static void sctp_v4_del_protocol(void)
> unregister_inetaddr_notifier(&sctp_inetaddr_notifier);
> }
>
> -static int sctp_net_init(struct net *net)
> +static int __net_init sctp_net_init(struct net *net)
> {
> int status;
>
> @@ -1290,7 +1290,7 @@ err_sysctl_register:
> return status;
> }
>
> -static void sctp_net_exit(struct net *net)
> +static void __net_exit sctp_net_exit(struct net *net)
> {
> /* Free the local address list */
> sctp_free_addr_wq(net);
> --
> 1.7.10.4
>
>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [Suggestion] net/atm : for sprintf, need check the total write length whether larger than a page.
From: chas williams - CONTRACTOR @ 2012-12-06 14:08 UTC (permalink / raw)
To: Chen Gang; +Cc: David Miller, netdev
In-Reply-To: <50BFF19E.1040405@asianux.com>
On Thu, 06 Dec 2012 09:15:10 +0800
Chen Gang <gang.chen@asianux.com> wrote:
> 于 2012年12月05日 22:55, chas williams - CONTRACTOR 写道:
> > did you mean '\0' instead of '\n'? scnprintf() considers the trailing
> > '\0' when formatting.
>
> no, originally, the end is "\n\0".
>
> I prefer we still compatible "\n" when the contents are very large.
> if count already == (PAGE_SIZE - 1), we have no chance to append "\n" to the end.
>
> - pos += sprintf(pos, "\n");
> + count += scnprintf(buf + count, PAGE_SIZE - count, "\n");
i would make the code a bit messy to do this for not much gain. again,
it isnt likely you would run into this in a normal situation.
^ permalink raw reply
* Re: [net-next PATCH V3-evictor] net: frag evictor, avoid killing warm frag queues
From: Jesper Dangaard Brouer @ 2012-12-06 13:55 UTC (permalink / raw)
To: Florian Westphal
Cc: Eric Dumazet, David S. Miller, netdev, Thomas Graf,
Paul E. McKenney, Cong Wang, Herbert Xu
In-Reply-To: <20121206123248.GA24493@breakpoint.cc>
On Thu, 2012-12-06 at 13:32 +0100, Florian Westphal wrote:
> Jesper Dangaard Brouer <jbrouer@redhat.com> wrote:
> > CPUs are fighting for the same LRU head (inet_frag_queue) element,
> > which is bad for scalability. We could fix this by unlinking the
> > element once a CPU graps it, but it would require us to change a
> > read_lock to a write_lock, thus we might not gain much performance.
> >
> > I already (implicit) fix this is a later patch, where I'm moving the
> > LRU lists to be per CPU. So, I don't know if it's worth fixing.
>
> Do you think its worth trying to remove the lru list altogether and
> just evict from the hash in a round-robin fashion instead?
Perhaps. But do note my bashing of the LRU list were wrong. I planned
to explain that in a separate mail, but basically I were causing a DoS
attack with incomplete fragments on my self, because I had disabled
Ethernet flow-control. Which led me to some false assumptions on the
LRU list behavior (sorry).
The LRU might be the correct solution after all. If I enable Ethernet
flow-control again, then I have a hard time "activating" the evictor
code (with thresh 4M/3M) . I'll need a separate DoS program, which can
send incomplete fragments (in back-to-back bursts) to provoke the
evictor and LRU.
My cheap DoS reproducer-hack is to disable Ethernet flow-control on only
one interface (out of 3), to cause packet drops and the incomplete
fragments. The current preliminary results is that the two other
interfaces still gets packets through, we don't get the zero throughput
situation.
Two interfaces and no DoS: 15342 Mbit/s
Three interfaces and DoS: 7355 Mbit/s
The reduction might look big, but you have to take into account, that
"activating" the evictor code, is also causing scalability issues of its
own (which could account for the performance drop it self).
--Jesper
^ permalink raw reply
* Re: [RFC PATCH v2 3/3] tun: fix LSM/SELinux labeling of tun/tap devices
From: Jason Wang @ 2012-12-06 13:51 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Paul Moore, netdev, linux-security-module, selinux
In-Reply-To: <20121206103325.GG10837@redhat.com>
On Thursday, December 06, 2012 12:33:25 PM Michael S. Tsirkin wrote:
> On Wed, Dec 05, 2012 at 03:26:19PM -0500, Paul Moore wrote:
> > This patch corrects some problems with LSM/SELinux that were introduced
> > with the multiqueue patchset. The problem stems from the fact that the
> > multiqueue work changed the relationship between the tun device and its
> > associated socket; before the socket persisted for the life of the
> > device, however after the multiqueue changes the socket only persisted
> > for the life of the userspace connection (fd open). For non-persistent
> > devices this is not an issue, but for persistent devices this can cause
> > the tun device to lose its SELinux label.
> >
> > We correct this problem by adding an opaque LSM security blob to the
> > tun device struct which allows us to have the LSM security state, e.g.
> > SELinux labeling information, persist for the lifetime of the tun
> > device. In the process we tweak the LSM hooks to work with this new
> > approach to TUN device/socket labeling and introduce a new LSM hook,
> > security_tun_dev_create_queue(), to approve requests to create a new
> > TUN queue via TUNSETQUEUE.
> >
> > The SELinux code has been adjusted to match the new LSM hooks, the
> > other LSMs do not make use of the LSM TUN controls. This patch makes
> > use of the recently added "tun_socket:create_queue" permission to
> > restrict access to the TUNSETQUEUE operation. On older SELinux
> > policies which do not define the "tun_socket:create_queue" permission
> > the access control decision for TUNSETQUEUE will be handled according
> > to the SELinux policy's unknown permission setting.
> >
> > Signed-off-by: Paul Moore <pmoore@redhat.com>
>
> OK so just to verify: this can be used to ensure that qemu
> process that has the queue fd can only attach it to
> a specific device, right?
I think it can't. And I'm not sure whether we need selinux help to do this.
Looks like we can do this without selinux through:
1. Don't assign a NULL pointer to tfile->tun during file detaching
2. Compare the ifr_name and the name of tfil->tun, if not equal, return -EINVAL
3. Set a special flag in tun_detach_all() to notify the fd is not usable, and
can't be used for future attaching.
Afther this, only the device that the fd is first attched through (TUNSETIFF or
TUNSETQUEUE) is allowed to be attached again.
>
> > ---
> >
> > drivers/net/tun.c | 26 +++++++++++++---
> > include/linux/security.h | 59
> > +++++++++++++++++++++++++++++-------- security/capability.c
> > | 24 +++++++++++++--
> > security/security.c | 28 ++++++++++++++----
> > security/selinux/hooks.c | 50 ++++++++++++++++++++++++-------
> > security/selinux/include/objsec.h | 4 +++
> > 6 files changed, 153 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> > index 14a0454..fb8148b 100644
> > --- a/drivers/net/tun.c
> > +++ b/drivers/net/tun.c
> > @@ -182,6 +182,7 @@ struct tun_struct {
> >
> > struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
> > struct timer_list flow_gc_timer;
> > unsigned long ageing_time;
> >
> > + void *security;
> >
> > };
> >
> > static inline u32 tun_hashfn(u32 rxhash)
> >
> > @@ -465,6 +466,10 @@ static int tun_attach(struct tun_struct *tun, struct
> > file *file)>
> > struct tun_file *tfile = file->private_data;
> > int err;
> >
> > + err = security_tun_dev_attach(tfile->socket.sk, tun->security);
> > + if (err < 0)
> > + goto out;
> > +
> >
> > err = -EINVAL;
> > if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
> >
> > goto out;
> >
> > @@ -1348,6 +1353,7 @@ static void tun_free_netdev(struct net_device *dev)
> >
> > struct tun_struct *tun = netdev_priv(dev);
> >
> > tun_flow_uninit(tun);
> >
> > + security_tun_dev_free_security(tun->security);
> >
> > free_netdev(dev);
> >
> > }
> >
> > @@ -1534,7 +1540,7 @@ static int tun_set_iff(struct net *net, struct file
> > *file, struct ifreq *ifr)>
> > if (tun_not_capable(tun))
> >
> > return -EPERM;
> >
> > - err = security_tun_dev_attach(tfile->socket.sk);
> > + err = security_tun_dev_open(tun->security);
> >
> > if (err < 0)
> >
> > return err;
> >
> > @@ -1587,7 +1593,9 @@ static int tun_set_iff(struct net *net, struct file
> > *file, struct ifreq *ifr)>
> > spin_lock_init(&tun->lock);
> >
> > - security_tun_dev_post_create(&tfile->sk);
> > + err = security_tun_dev_alloc_security(&tun->security);
> > + if (err < 0)
> > + goto err_free_dev;
> >
> > tun_net_init(dev);
> >
> > @@ -1767,12 +1775,18 @@ static int tun_set_queue(struct file *file, struct
> > ifreq *ifr)>
> > tun = netdev_priv(dev);
> > if (dev->netdev_ops != &tap_netdev_ops &&
> >
> > - dev->netdev_ops != &tun_netdev_ops)
> > + dev->netdev_ops != &tun_netdev_ops) {
> >
> > ret = -EINVAL;
> >
> > - else if (tun_not_capable(tun))
> > + goto unlock;
> > + }
> > + if (tun_not_capable(tun)) {
> >
> > ret = -EPERM;
> >
> > - else
> > - ret = tun_attach(tun, file);
> > + goto unlock;
> > + }
> > + ret = security_tun_dev_create_queue(tun->security);
> > + if (ret < 0)
> > + goto unlock;
> > + ret = tun_attach(tun, file);
> >
> > } else if (ifr->ifr_flags & IFF_DETACH_QUEUE)
> >
> > __tun_detach(tfile, false);
> >
> > else
> >
> > diff --git a/include/linux/security.h b/include/linux/security.h
> > index 05e88bd..8ea923b 100644
> > --- a/include/linux/security.h
> > +++ b/include/linux/security.h
> > @@ -983,17 +983,29 @@ static inline void security_free_mnt_opts(struct
> > security_mnt_opts *opts)>
> > * tells the LSM to decrement the number of secmark labeling rules loaded
> > * @req_classify_flow:
> > * Sets the flow's sid to the openreq sid.
> >
> > + * @tun_dev_alloc_security:
> > + * This hook allows a module to allocate a security structure for a TUN
> > + * device.
> > + * @security pointer to a security structure pointer.
> > + * Returns a zero on success, negative values on failure.
> > + * @tun_dev_free_security:
> > + * This hook allows a module to free the security structure for a TUN
> > + * device.
> > + * @security pointer to the TUN device's security structure
> >
> > * @tun_dev_create:
> > * Check permissions prior to creating a new TUN device.
> >
> > - * @tun_dev_post_create:
> > - * This hook allows a module to update or allocate a per-socket security
> > - * structure.
> > - * @sk contains the newly created sock structure.
> > + * @tun_dev_create_queue:
> > + * Check permissions prior to creating a new TUN device queue.
> > + * @security pointer to the TUN device's security structure.
> >
> > * @tun_dev_attach:
> > - * Check permissions prior to attaching to a persistent TUN device. This
> > - * hook can also be used by the module to update any security state
> > + * This hook can be used by the module to update any security state
> >
> > * associated with the TUN device's sock structure.
> > * @sk contains the existing sock structure.
> >
> > + * @security pointer to the TUN device's security structure.
> > + * @tun_dev_open:
> > + * This hook can be used by the module to update any security state
> > + * associated with the TUN device's security structure.
> > + * @security pointer to the TUN devices's security structure.
> >
> > *
> > * Security hooks for XFRM operations.
> > *
> >
> > @@ -1613,9 +1625,12 @@ struct security_operations {
> >
> > void (*secmark_refcount_inc) (void);
> > void (*secmark_refcount_dec) (void);
> > void (*req_classify_flow) (const struct request_sock *req, struct flowi
> > *fl);>
> > - int (*tun_dev_create)(void);
> > - void (*tun_dev_post_create)(struct sock *sk);
> > - int (*tun_dev_attach)(struct sock *sk);
> > + int (*tun_dev_alloc_security) (void **security);
> > + void (*tun_dev_free_security) (void *security);
> > + int (*tun_dev_create) (void);
> > + int (*tun_dev_create_queue) (void *security);
> > + int (*tun_dev_attach) (struct sock *sk, void *security);
> > + int (*tun_dev_open) (void *security);
> >
> > #endif /* CONFIG_SECURITY_NETWORK */
> >
> > #ifdef CONFIG_SECURITY_NETWORK_XFRM
> >
> > @@ -2553,9 +2568,12 @@ void security_inet_conn_established(struct sock
> > *sk,
> >
> > int security_secmark_relabel_packet(u32 secid);
> > void security_secmark_refcount_inc(void);
> > void security_secmark_refcount_dec(void);
> >
> > +int security_tun_dev_alloc_security(void **security);
> > +void security_tun_dev_free_security(void *security);
> >
> > int security_tun_dev_create(void);
> >
> > -void security_tun_dev_post_create(struct sock *sk);
> > -int security_tun_dev_attach(struct sock *sk);
> > +int security_tun_dev_create_queue(void *security);
> > +int security_tun_dev_attach(struct sock *sk, void *security);
> > +int security_tun_dev_open(void *security);
> >
> > #else /* CONFIG_SECURITY_NETWORK */
> > static inline int security_unix_stream_connect(struct sock *sock,
> >
> > @@ -2720,16 +2738,31 @@ static inline void
> > security_secmark_refcount_dec(void)>
> > {
> > }
> >
> > +static inline int security_tun_dev_alloc_security(void **security)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline void security_tun_dev_free_security(void *security)
> > +{
> > +}
> > +
> >
> > static inline int security_tun_dev_create(void)
> > {
> >
> > return 0;
> >
> > }
> >
> > -static inline void security_tun_dev_post_create(struct sock *sk)
> > +static inline int security_tun_dev_create_queue(void *security)
> > +{
> > + return 0;
> > +}
> > +
> > +static inline int security_tun_dev_attach(struct sock *sk, void
> > *security)
> >
> > {
> >
> > + return 0;
> >
> > }
> >
> > -static inline int security_tun_dev_attach(struct sock *sk)
> > +static inline int security_tun_dev_open(void *security)
> >
> > {
> >
> > return 0;
> >
> > }
> >
> > diff --git a/security/capability.c b/security/capability.c
> > index b14a30c..bf4cbf2 100644
> > --- a/security/capability.c
> > +++ b/security/capability.c
> > @@ -704,16 +704,31 @@ static void cap_req_classify_flow(const struct
> > request_sock *req,>
> > {
> > }
> >
> > +static int cap_tun_dev_alloc_security(void **security)
> > +{
> > + return 0;
> > +}
> > +
> > +static void cap_tun_dev_free_security(void *security)
> > +{
> > +}
> > +
> >
> > static int cap_tun_dev_create(void)
> > {
> >
> > return 0;
> >
> > }
> >
> > -static void cap_tun_dev_post_create(struct sock *sk)
> > +static int cap_tun_dev_create_queue(void *security)
> > +{
> > + return 0;
> > +}
> > +
> > +static int cap_tun_dev_attach(struct sock *sk, void *security)
> >
> > {
> >
> > + return 0;
> >
> > }
> >
> > -static int cap_tun_dev_attach(struct sock *sk)
> > +static int cap_tun_dev_open(void *security)
> >
> > {
> >
> > return 0;
> >
> > }
> >
> > @@ -1044,8 +1059,11 @@ void __init security_fixup_ops(struct
> > security_operations *ops)>
> > set_to_cap_if_null(ops, secmark_refcount_inc);
> > set_to_cap_if_null(ops, secmark_refcount_dec);
> > set_to_cap_if_null(ops, req_classify_flow);
> >
> > + set_to_cap_if_null(ops, tun_dev_alloc_security);
> > + set_to_cap_if_null(ops, tun_dev_free_security);
> >
> > set_to_cap_if_null(ops, tun_dev_create);
> >
> > - set_to_cap_if_null(ops, tun_dev_post_create);
> > + set_to_cap_if_null(ops, tun_dev_create_queue);
> > + set_to_cap_if_null(ops, tun_dev_open);
> >
> > set_to_cap_if_null(ops, tun_dev_attach);
> >
> > #endif /* CONFIG_SECURITY_NETWORK */
> > #ifdef CONFIG_SECURITY_NETWORK_XFRM
> >
> > diff --git a/security/security.c b/security/security.c
> > index 8dcd4ae..4d82654 100644
> > --- a/security/security.c
> > +++ b/security/security.c
> > @@ -1244,24 +1244,42 @@ void security_secmark_refcount_dec(void)
> >
> > }
> > EXPORT_SYMBOL(security_secmark_refcount_dec);
> >
> > +int security_tun_dev_alloc_security(void **security)
> > +{
> > + return security_ops->tun_dev_alloc_security(security);
> > +}
> > +EXPORT_SYMBOL(security_tun_dev_alloc_security);
> > +
> > +void security_tun_dev_free_security(void *security)
> > +{
> > + security_ops->tun_dev_free_security(security);
> > +}
> > +EXPORT_SYMBOL(security_tun_dev_free_security);
> > +
> >
> > int security_tun_dev_create(void)
> > {
> >
> > return security_ops->tun_dev_create();
> >
> > }
> > EXPORT_SYMBOL(security_tun_dev_create);
> >
> > -void security_tun_dev_post_create(struct sock *sk)
> > +int security_tun_dev_create_queue(void *security)
> >
> > {
> >
> > - return security_ops->tun_dev_post_create(sk);
> > + return security_ops->tun_dev_create_queue(security);
> >
> > }
> >
> > -EXPORT_SYMBOL(security_tun_dev_post_create);
> > +EXPORT_SYMBOL(security_tun_dev_create_queue);
> >
> > -int security_tun_dev_attach(struct sock *sk)
> > +int security_tun_dev_attach(struct sock *sk, void *security)
> >
> > {
> >
> > - return security_ops->tun_dev_attach(sk);
> > + return security_ops->tun_dev_attach(sk, security);
> >
> > }
> > EXPORT_SYMBOL(security_tun_dev_attach);
> >
> > +int security_tun_dev_open(void *security)
> > +{
> > + return security_ops->tun_dev_open(security);
> > +}
> > +EXPORT_SYMBOL(security_tun_dev_open);
> > +
> >
> > #endif /* CONFIG_SECURITY_NETWORK */
> >
> > #ifdef CONFIG_SECURITY_NETWORK_XFRM
> >
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index 61a5336..f1efb08 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -4399,6 +4399,24 @@ static void selinux_req_classify_flow(const struct
> > request_sock *req,>
> > fl->flowi_secid = req->secid;
> >
> > }
> >
> > +static int selinux_tun_dev_alloc_security(void **security)
> > +{
> > + struct tun_security_struct *tunsec;
> > +
> > + tunsec = kzalloc(sizeof(*tunsec), GFP_KERNEL);
> > + if (!tunsec)
> > + return -ENOMEM;
> > + tunsec->sid = current_sid();
> > +
> > + *security = tunsec;
> > + return 0;
> > +}
> > +
> > +static void selinux_tun_dev_free_security(void *security)
> > +{
> > + kfree(security);
> > +}
> > +
> >
> > static int selinux_tun_dev_create(void)
> > {
> >
> > u32 sid = current_sid();
> >
> > @@ -4414,8 +4432,17 @@ static int selinux_tun_dev_create(void)
> >
> > NULL);
> >
> > }
> >
> > -static void selinux_tun_dev_post_create(struct sock *sk)
> > +static int selinux_tun_dev_create_queue(void *security)
> >
> > {
> >
> > + struct tun_security_struct *tunsec = security;
> > +
> > + return avc_has_perm(current_sid(), tunsec->sid, SECCLASS_TUN_SOCKET,
> > + TUN_SOCKET__CREATE_QUEUE, NULL);
> > +}
> > +
> > +static int selinux_tun_dev_attach(struct sock *sk, void *security)
> > +{
> > + struct tun_security_struct *tunsec = security;
> >
> > struct sk_security_struct *sksec = sk->sk_security;
> >
> > /* we don't currently perform any NetLabel based labeling here and it
> >
> > @@ -4425,20 +4452,19 @@ static void selinux_tun_dev_post_create(struct
> > sock *sk)>
> > * cause confusion to the TUN user that had no idea network labeling
> > * protocols were being used */
> >
> > - /* see the comments in selinux_tun_dev_create() about why we don't use
> > - * the sockcreate SID here */
> > -
> > - sksec->sid = current_sid();
> > + sksec->sid = tunsec->sid;
> >
> > sksec->sclass = SECCLASS_TUN_SOCKET;
> >
> > +
> > + return 0;
> >
> > }
> >
> > -static int selinux_tun_dev_attach(struct sock *sk)
> > +static int selinux_tun_dev_open(void *security)
> >
> > {
> >
> > - struct sk_security_struct *sksec = sk->sk_security;
> > + struct tun_security_struct *tunsec = security;
> >
> > u32 sid = current_sid();
> > int err;
> >
> > - err = avc_has_perm(sid, sksec->sid, SECCLASS_TUN_SOCKET,
> > + err = avc_has_perm(sid, tunsec->sid, SECCLASS_TUN_SOCKET,
> >
> > TUN_SOCKET__RELABELFROM, NULL);
> >
> > if (err)
> >
> > return err;
> >
> > @@ -4446,8 +4472,7 @@ static int selinux_tun_dev_attach(struct sock *sk)
> >
> > TUN_SOCKET__RELABELTO, NULL);
> >
> > if (err)
> >
> > return err;
> >
> > -
> > - sksec->sid = sid;
> > + tunsec->sid = sid;
> >
> > return 0;
> >
> > }
> >
> > @@ -5642,9 +5667,12 @@ static struct security_operations selinux_ops = {
> >
> > .secmark_refcount_inc = selinux_secmark_refcount_inc,
> > .secmark_refcount_dec = selinux_secmark_refcount_dec,
> > .req_classify_flow = selinux_req_classify_flow,
> >
> > + .tun_dev_alloc_security = selinux_tun_dev_alloc_security,
> > + .tun_dev_free_security = selinux_tun_dev_free_security,
> >
> > .tun_dev_create = selinux_tun_dev_create,
> >
> > - .tun_dev_post_create = selinux_tun_dev_post_create,
> > + .tun_dev_create_queue = selinux_tun_dev_create_queue,
> >
> > .tun_dev_attach = selinux_tun_dev_attach,
> >
> > + .tun_dev_open = selinux_tun_dev_open,
> >
> > #ifdef CONFIG_SECURITY_NETWORK_XFRM
> >
> > .xfrm_policy_alloc_security = selinux_xfrm_policy_alloc,
> >
> > diff --git a/security/selinux/include/objsec.h
> > b/security/selinux/include/objsec.h index 26c7eee..aa47bca 100644
> > --- a/security/selinux/include/objsec.h
> > +++ b/security/selinux/include/objsec.h
> > @@ -110,6 +110,10 @@ struct sk_security_struct {
> >
> > u16 sclass; /* sock security class */
> >
> > };
> >
> > +struct tun_security_struct {
> > + u32 sid; /* SID for the tun device sockets */
> > +};
> > +
> >
> > struct key_security_struct {
> >
> > u32 sid; /* SID of key */
> >
> > };
^ permalink raw reply
* KINDLY READ THE ATTACHED FUND INVESTMENT PROPOSAL LETTER AND REPLY.
From: MR. ZUMA DECUBO @ 2012-12-06 13:32 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 2 bytes --]
[-- Attachment #2: FUND INVESTMENT PROPOSAL.docx --]
[-- Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document, Size: 12603 bytes --]
^ permalink raw reply
* RE: [net-next PATCH V3-evictor] net: frag evictor, avoid killing warm frag queues
From: David Laight @ 2012-12-06 13:29 UTC (permalink / raw)
To: Florian Westphal, Jesper Dangaard Brouer
Cc: Eric Dumazet, David S. Miller, netdev, Thomas Graf,
Paul E. McKenney, Cong Wang, Herbert Xu
In-Reply-To: <20121206123248.GA24493@breakpoint.cc>
> Jesper Dangaard Brouer <jbrouer@redhat.com> wrote:
> > CPUs are fighting for the same LRU head (inet_frag_queue) element,
> > which is bad for scalability. We could fix this by unlinking the
> > element once a CPU graps it, but it would require us to change a
> > read_lock to a write_lock, thus we might not gain much performance.
> >
> > I already (implicit) fix this is a later patch, where I'm moving the
> > LRU lists to be per CPU. So, I don't know if it's worth fixing.
>
> Do you think its worth trying to remove the lru list altogether and
> just evict from the hash in a round-robin fashion instead?
Round-robin will be the same as LRU under overload - so have the
same issues.
Random might be better - especially if IP datagrams for which
more than one in-sequence packet have been received are moved
to a second structure.
But you still need something to control the total memory use.
NFS/UDP is about the only thing that generates very large
IP datagrams - and no one in their right mind runs that
over non-local links.
For SMP you might hash to a small array of pointers (to fragments)
each having its own lock. Only evict items with the same hash.
Put the id in the array and you probably won't need to look at
the actual fragment (saving a cache miss) unless it is the one
you want.
David
^ permalink raw reply
* Re: at91sam9260 MACB problem with IP fragmentation
From: Nicolas Ferre @ 2012-12-06 13:27 UTC (permalink / raw)
To: Erwin Rol
Cc: linux-kernel, Havard Skinnemoen, linux-arm-kernel, matteo.fortini,
netdev
In-Reply-To: <50C08233.9030905@erwinrol.com>
Erwin,
On 12/06/2012 12:32 PM, Erwin Rol :
> Hello Nicolas, Havard, all,
>
> I have a very obscure problem with a at91sam9260 board (almost 1 to 1
> copy of the Atmel EK).
>
> The MACB seems to stall when I use large (>2 * MTU) UDP datagrams. The
> test case is that a udp echo client (PC) sends datagrams with increasing
> length to the AT91 until the max length of the UDP datagram is reached.
> When there is no IP fragmentation everything is fine, but when the
> datagrams are starting to get fragmented the AT91 will not reply
> anymore. But as soon as some network traffic happens it goes on again,
> and non of the data is lost.
>
> With wireshark the effect can be easily seen (192.168.1.4 is the PC echo
> client, and 192.168.1.133 is the at91 echo server) After the first
> request there comes no reply. After a 5 second timeout the second
> request is send. And then both replies are returned.
>
> When I enabled debugging output it all started to work. So I tried some
> udelays in the driver instead of printk and with a 1ms delay in the irq
> handler it started working. Of course that is an unacceptable fix, but
> it looks like that is some weird race condition that causes the sending
> to stall. The only difference with normal MTU sized datagrams I can
> think of is that the fragmented packets can be passed very quickly to
> the macb tx function, because the kernel has all 5 skb's ready.
>
> I would be very interested to hear if someone else could reproduce this
> problem. Or even better, has seen this problem and has a fix for it.
>
> I tried several kernels including the test version from Nicolas that he
> posted on LKML in October. They all show the same effect.
[..]
It seems that Matteo has the same behavior: check here:
http://www.spinics.net/lists/netdev/msg218951.html
I am working on the macb driver right now, so I will try to reproduce
and track this issue on my side.
Best regards,
--
Nicolas Ferre
^ permalink raw reply
* [PATCH] tulip: Fix compiler warning when CONFIG_DEBUG_SECTION_MISMATCH=y
From: Christoph Paasch @ 2012-12-06 13:04 UTC (permalink / raw)
To: Grant Grundler, David Miller; +Cc: netdev
WARNING: drivers/net/ethernet/dec/tulip/tulip.o(.text+0x4057): Section
mismatch in reference from the function tulip_init_one() to the variable
.devinit.rodata:early_486_chipsets
The function tulip_init_one() references
the variable __devinitconst early_486_chipsets.
This is often because tulip_init_one lacks a __devinitconst
annotation or the annotation of early_486_chipsets is wrong.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
drivers/net/ethernet/dec/tulip/tulip_core.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/dec/tulip/tulip_core.c b/drivers/net/ethernet/dec/tulip/tulip_core.c
index 157c8e6..6baec9c 100644
--- a/drivers/net/ethernet/dec/tulip/tulip_core.c
+++ b/drivers/net/ethernet/dec/tulip/tulip_core.c
@@ -1301,7 +1301,7 @@ DEFINE_PCI_DEVICE_TABLE(early_486_chipsets) = {
{ },
};
-static int tulip_init_one(struct pci_dev *pdev,
+static int __devinit tulip_init_one(struct pci_dev *pdev,
const struct pci_device_id *ent)
{
struct tulip_private *tp;
@@ -1970,7 +1970,7 @@ static void poll_tulip (struct net_device *dev)
}
#endif
-static struct pci_driver tulip_driver = {
+static struct __devinitdata pci_driver tulip_driver = {
.name = DRV_NAME,
.id_table = tulip_pci_tbl,
.probe = tulip_init_one,
--
1.7.10.4
^ permalink raw reply related
* [PATCH net next] team: remove team parameter from port_enter callback.
From: Rami Rosen @ 2012-12-06 13:09 UTC (permalink / raw)
To: davem; +Cc: jiri, netdev, Rami Rosen
This patch removes an unused parameter (team) from port_enter callback in
team_mode_ops and fixes accordingly its invocations in 3 modes and in team.c.
Signed-off-by: Rami Rosen <ramirose@gmail.com>
---
drivers/net/team/team.c | 2 +-
drivers/net/team/team_mode_broadcast.c | 2 +-
drivers/net/team/team_mode_loadbalance.c | 2 +-
drivers/net/team/team_mode_roundrobin.c | 2 +-
include/linux/if_team.h | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/team/team.c b/drivers/net/team/team.c
index ad86660..4203808 100644
--- a/drivers/net/team/team.c
+++ b/drivers/net/team/team.c
@@ -887,7 +887,7 @@ static int team_port_enter(struct team *team, struct team_port *port)
dev_hold(team->dev);
port->dev->priv_flags |= IFF_TEAM_PORT;
if (team->ops.port_enter) {
- err = team->ops.port_enter(team, port);
+ err = team->ops.port_enter(port);
if (err) {
netdev_err(team->dev, "Device %s failed to enter team mode\n",
port->dev->name);
diff --git a/drivers/net/team/team_mode_broadcast.c b/drivers/net/team/team_mode_broadcast.c
index c5db428..c3840bc 100644
--- a/drivers/net/team/team_mode_broadcast.c
+++ b/drivers/net/team/team_mode_broadcast.c
@@ -46,7 +46,7 @@ static bool bc_transmit(struct team *team, struct sk_buff *skb)
return sum_ret;
}
-static int bc_port_enter(struct team *team, struct team_port *port)
+static int bc_port_enter(struct team_port *port)
{
return team_port_set_team_dev_addr(port);
}
diff --git a/drivers/net/team/team_mode_loadbalance.c b/drivers/net/team/team_mode_loadbalance.c
index cdc31b5..1e84c77 100644
--- a/drivers/net/team/team_mode_loadbalance.c
+++ b/drivers/net/team/team_mode_loadbalance.c
@@ -614,7 +614,7 @@ static void lb_exit(struct team *team)
kfree(lb_priv->ex);
}
-static int lb_port_enter(struct team *team, struct team_port *port)
+static int lb_port_enter(struct team_port *port)
{
struct lb_port_priv *lb_port_priv = get_lb_port_priv(port);
diff --git a/drivers/net/team/team_mode_roundrobin.c b/drivers/net/team/team_mode_roundrobin.c
index 105135a..abe889e 100644
--- a/drivers/net/team/team_mode_roundrobin.c
+++ b/drivers/net/team/team_mode_roundrobin.c
@@ -64,7 +64,7 @@ drop:
return false;
}
-static int rr_port_enter(struct team *team, struct team_port *port)
+static int rr_port_enter(struct team_port *port)
{
return team_port_set_team_dev_addr(port);
}
diff --git a/include/linux/if_team.h b/include/linux/if_team.h
index 0245def..3366453 100644
--- a/include/linux/if_team.h
+++ b/include/linux/if_team.h
@@ -105,7 +105,7 @@ struct team_mode_ops {
struct team_port *port,
struct sk_buff *skb);
bool (*transmit)(struct team *team, struct sk_buff *skb);
- int (*port_enter)(struct team *team, struct team_port *port);
+ int (*port_enter)(struct team_port *port);
void (*port_leave)(struct team *team, struct team_port *port);
void (*port_change_dev_addr)(struct team *team, struct team_port *port);
void (*port_enabled)(struct team *team, struct team_port *port);
--
1.7.11.7
^ permalink raw reply related
* [PATCH] sctp: Fix compiler warning when CONFIG_DEBUG_SECTION_MISMATCH=y
From: Christoph Paasch @ 2012-12-06 13:03 UTC (permalink / raw)
To: vyasevich, linux-sctp, davem; +Cc: sri, nhorman, netdev
WARNING: net/sctp/sctp.o(.text+0x72f1): Section mismatch in reference
from the function sctp_net_init() to the function
.init.text:sctp_proc_init()
The function sctp_net_init() references
the function __init sctp_proc_init().
This is often because sctp_net_init lacks a __init
annotation or the annotation of sctp_proc_init is wrong.
And put __net_init after 'int' for sctp_proc_init - as it is done
everywhere else in the sctp-stack.
Signed-off-by: Christoph Paasch <christoph.paasch@uclouvain.be>
---
net/sctp/protocol.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sctp/protocol.c b/net/sctp/protocol.c
index 456bc3d..2c7785b 100644
--- a/net/sctp/protocol.c
+++ b/net/sctp/protocol.c
@@ -86,7 +86,7 @@ int sysctl_sctp_rmem[3];
int sysctl_sctp_wmem[3];
/* Set up the proc fs entry for the SCTP protocol. */
-static __net_init int sctp_proc_init(struct net *net)
+static int __net_init sctp_proc_init(struct net *net)
{
#ifdef CONFIG_PROC_FS
net->sctp.proc_net_sctp = proc_net_mkdir(net, "sctp", net->proc_net);
@@ -1165,7 +1165,7 @@ static void sctp_v4_del_protocol(void)
unregister_inetaddr_notifier(&sctp_inetaddr_notifier);
}
-static int sctp_net_init(struct net *net)
+static int __net_init sctp_net_init(struct net *net)
{
int status;
@@ -1290,7 +1290,7 @@ err_sysctl_register:
return status;
}
-static void sctp_net_exit(struct net *net)
+static void __net_exit sctp_net_exit(struct net *net)
{
/* Free the local address list */
sctp_free_addr_wq(net);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] vhost-blk: Add vhost-blk support v6
From: Michael S. Tsirkin @ 2012-12-06 13:00 UTC (permalink / raw)
To: Asias He
Cc: Jens Axboe, kvm, netdev, linux-kernel, virtualization,
Christoph Hellwig, David S. Miller
In-Reply-To: <1354412033-32372-1-git-send-email-asias@redhat.com>
On Sun, Dec 02, 2012 at 09:33:53AM +0800, Asias He wrote:
> diff --git a/drivers/vhost/Kconfig.blk b/drivers/vhost/Kconfig.blk
> new file mode 100644
> index 0000000..ff8ab76
> --- /dev/null
> +++ b/drivers/vhost/Kconfig.blk
> @@ -0,0 +1,10 @@
> +config VHOST_BLK
> + tristate "Host kernel accelerator for virtio blk (EXPERIMENTAL)"
> + depends on BLOCK && EXPERIMENTAL && m
should depend on eventfd as well.
^ permalink raw reply
* Re: [PATCH net 1/1] r8169: workaround for missing extended GigaMAC registers
From: Francois Romieu @ 2012-12-06 12:25 UTC (permalink / raw)
To: Wang YanQing; +Cc: netdev, David Miller, Lee Chun-Yi, Hayes Wang
In-Reply-To: <20121206073842.GA3847@udknight>
Wang YanQing:
[...]
> Are you sure we will lose GigaMAC registers's content
> after NIC into PCI_D3hot state ?
I have not made such a claim.
Only some bioses f*ck things up on resume, see:
http://marc.info/?l=linux-netdev&m=132195832624117&w=2
My test computer and its 8168evl (courtesy of Realtek) was not able to make
a difference w/o the patch: it always works.
--
Ueimor
^ permalink raw reply
* Re: [net-next PATCH V3-evictor] net: frag evictor, avoid killing warm frag queues
From: Florian Westphal @ 2012-12-06 12:32 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: Eric Dumazet, David S. Miller, Florian Westphal, netdev,
Thomas Graf, Paul E. McKenney, Cong Wang, Herbert Xu
In-Reply-To: <1354796760.20888.217.camel@localhost>
Jesper Dangaard Brouer <jbrouer@redhat.com> wrote:
> CPUs are fighting for the same LRU head (inet_frag_queue) element,
> which is bad for scalability. We could fix this by unlinking the
> element once a CPU graps it, but it would require us to change a
> read_lock to a write_lock, thus we might not gain much performance.
>
> I already (implicit) fix this is a later patch, where I'm moving the
> LRU lists to be per CPU. So, I don't know if it's worth fixing.
Do you think its worth trying to remove the lru list altogether and
just evict from the hash in a round-robin fashion instead?
^ permalink raw reply
* Re: [net-next PATCH V3-evictor] net: frag evictor, avoid killing warm frag queues
From: Jesper Dangaard Brouer @ 2012-12-06 12:26 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Florian Westphal, netdev, Thomas Graf,
Paul E. McKenney, Cong Wang, Herbert Xu
In-Reply-To: <1354699462.20888.207.camel@localhost>
On Wed, 2012-12-05 at 10:24 +0100, Jesper Dangaard Brouer wrote:
>
> The previous evictor patch of letting new fragments enter, worked
> amazingly well. But I suspect, this might also be related to a
> bug/problem in the evictor loop (which were being hidden by that
> patch).
The evictor loop does not contain a bug, just a SMP scalability issue
(which is fixed by later patches). The first evictor patch, which
does not let new fragments enter, only worked amazingly well because
its hiding this (and other) scalability issues, and implicit allowing
frags already "in" to exceed the mem usage for 1 jiffie. Thus,
invalidating the patch, as the improvement were only a side effect.
> My new *theory* is that the evictor loop, will be looping too much, if
> it finds a fragment which is INET_FRAG_COMPLETE ... in that case, we
> don't advance the LRU list, and thus will pickup the exact same
> inet_frag_queue again in the loop... to get out of the loop we need
> another CPU or packet to change the LRU list for us... I'll test that
> theory... (its could also be CPUs fighting over the same LRU head
> element that cause this) ... more to come...
The above theory does happen, but does not cause excessive looping.
The CPUs are just fighting about who gets to free the inet_frag_queue
and who gets to unlink it from its data structures (I guess, resulting
cache bouncing between CPUs).
CPUs are fighting for the same LRU head (inet_frag_queue) element,
which is bad for scalability. We could fix this by unlinking the
element once a CPU graps it, but it would require us to change a
read_lock to a write_lock, thus we might not gain much performance.
I already (implicit) fix this is a later patch, where I'm moving the
LRU lists to be per CPU. So, I don't know if it's worth fixing.
(And yes, I'm using thresh 4Mb/3Mb as my default setting now, but I'm
also experimenting with other thresh sizes)
p.s. Thank you Eric for being so persistent, so I realized this patch
were not good. We can hopefully now, move on to the other patches,
which fixes the real scalability issues.
--Jesper
^ permalink raw reply
* Re: [RFC PATCH v2 3/3] tun: fix LSM/SELinux labeling of tun/tap devices
From: Michael S. Tsirkin @ 2012-12-06 10:33 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, linux-security-module, selinux, jasowang
In-Reply-To: <20121205202619.18626.98778.stgit@localhost>
On Wed, Dec 05, 2012 at 03:26:19PM -0500, Paul Moore wrote:
> This patch corrects some problems with LSM/SELinux that were introduced
> with the multiqueue patchset. The problem stems from the fact that the
> multiqueue work changed the relationship between the tun device and its
> associated socket; before the socket persisted for the life of the
> device, however after the multiqueue changes the socket only persisted
> for the life of the userspace connection (fd open). For non-persistent
> devices this is not an issue, but for persistent devices this can cause
> the tun device to lose its SELinux label.
>
> We correct this problem by adding an opaque LSM security blob to the
> tun device struct which allows us to have the LSM security state, e.g.
> SELinux labeling information, persist for the lifetime of the tun
> device. In the process we tweak the LSM hooks to work with this new
> approach to TUN device/socket labeling and introduce a new LSM hook,
> security_tun_dev_create_queue(), to approve requests to create a new
> TUN queue via TUNSETQUEUE.
>
> The SELinux code has been adjusted to match the new LSM hooks, the
> other LSMs do not make use of the LSM TUN controls. This patch makes
> use of the recently added "tun_socket:create_queue" permission to
> restrict access to the TUNSETQUEUE operation. On older SELinux
> policies which do not define the "tun_socket:create_queue" permission
> the access control decision for TUNSETQUEUE will be handled according
> to the SELinux policy's unknown permission setting.
>
> Signed-off-by: Paul Moore <pmoore@redhat.com>
OK so just to verify: this can be used to ensure that qemu
process that has the queue fd can only attach it to
a specific device, right?
> ---
> drivers/net/tun.c | 26 +++++++++++++---
> include/linux/security.h | 59 +++++++++++++++++++++++++++++--------
> security/capability.c | 24 +++++++++++++--
> security/security.c | 28 ++++++++++++++----
> security/selinux/hooks.c | 50 ++++++++++++++++++++++++-------
> security/selinux/include/objsec.h | 4 +++
> 6 files changed, 153 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index 14a0454..fb8148b 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -182,6 +182,7 @@ struct tun_struct {
> struct hlist_head flows[TUN_NUM_FLOW_ENTRIES];
> struct timer_list flow_gc_timer;
> unsigned long ageing_time;
> + void *security;
> };
>
> static inline u32 tun_hashfn(u32 rxhash)
> @@ -465,6 +466,10 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
> struct tun_file *tfile = file->private_data;
> int err;
>
> + err = security_tun_dev_attach(tfile->socket.sk, tun->security);
> + if (err < 0)
> + goto out;
> +
> err = -EINVAL;
> if (rcu_dereference_protected(tfile->tun, lockdep_rtnl_is_held()))
> goto out;
> @@ -1348,6 +1353,7 @@ static void tun_free_netdev(struct net_device *dev)
> struct tun_struct *tun = netdev_priv(dev);
>
> tun_flow_uninit(tun);
> + security_tun_dev_free_security(tun->security);
> free_netdev(dev);
> }
>
> @@ -1534,7 +1540,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
>
> if (tun_not_capable(tun))
> return -EPERM;
> - err = security_tun_dev_attach(tfile->socket.sk);
> + err = security_tun_dev_open(tun->security);
> if (err < 0)
> return err;
>
> @@ -1587,7 +1593,9 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
>
> spin_lock_init(&tun->lock);
>
> - security_tun_dev_post_create(&tfile->sk);
> + err = security_tun_dev_alloc_security(&tun->security);
> + if (err < 0)
> + goto err_free_dev;
>
> tun_net_init(dev);
>
> @@ -1767,12 +1775,18 @@ static int tun_set_queue(struct file *file, struct ifreq *ifr)
>
> tun = netdev_priv(dev);
> if (dev->netdev_ops != &tap_netdev_ops &&
> - dev->netdev_ops != &tun_netdev_ops)
> + dev->netdev_ops != &tun_netdev_ops) {
> ret = -EINVAL;
> - else if (tun_not_capable(tun))
> + goto unlock;
> + }
> + if (tun_not_capable(tun)) {
> ret = -EPERM;
> - else
> - ret = tun_attach(tun, file);
> + goto unlock;
> + }
> + ret = security_tun_dev_create_queue(tun->security);
> + if (ret < 0)
> + goto unlock;
> + ret = tun_attach(tun, file);
> } else if (ifr->ifr_flags & IFF_DETACH_QUEUE)
> __tun_detach(tfile, false);
> else
> diff --git a/include/linux/security.h b/include/linux/security.h
> index 05e88bd..8ea923b 100644
> --- a/include/linux/security.h
> +++ b/include/linux/security.h
> @@ -983,17 +983,29 @@ static inline void security_free_mnt_opts(struct security_mnt_opts *opts)
> * tells the LSM to decrement the number of secmark labeling rules loaded
> * @req_classify_flow:
> * Sets the flow's sid to the openreq sid.
> + * @tun_dev_alloc_security:
> + * This hook allows a module to allocate a security structure for a TUN
> + * device.
> + * @security pointer to a security structure pointer.
> + * Returns a zero on success, negative values on failure.
> + * @tun_dev_free_security:
> + * This hook allows a module to free the security structure for a TUN
> + * device.
> + * @security pointer to the TUN device's security structure
> * @tun_dev_create:
> * Check permissions prior to creating a new TUN device.
> - * @tun_dev_post_create:
> - * This hook allows a module to update or allocate a per-socket security
> - * structure.
> - * @sk contains the newly created sock structure.
> + * @tun_dev_create_queue:
> + * Check permissions prior to creating a new TUN device queue.
> + * @security pointer to the TUN device's security structure.
> * @tun_dev_attach:
> - * Check permissions prior to attaching to a persistent TUN device. This
> - * hook can also be used by the module to update any security state
> + * This hook can be used by the module to update any security state
> * associated with the TUN device's sock structure.
> * @sk contains the existing sock structure.
> + * @security pointer to the TUN device's security structure.
> + * @tun_dev_open:
> + * This hook can be used by the module to update any security state
> + * associated with the TUN device's security structure.
> + * @security pointer to the TUN devices's security structure.
> *
> * Security hooks for XFRM operations.
> *
> @@ -1613,9 +1625,12 @@ struct security_operations {
> void (*secmark_refcount_inc) (void);
> void (*secmark_refcount_dec) (void);
> void (*req_classify_flow) (const struct request_sock *req, struct flowi *fl);
> - int (*tun_dev_create)(void);
> - void (*tun_dev_post_create)(struct sock *sk);
> - int (*tun_dev_attach)(struct sock *sk);
> + int (*tun_dev_alloc_security) (void **security);
> + void (*tun_dev_free_security) (void *security);
> + int (*tun_dev_create) (void);
> + int (*tun_dev_create_queue) (void *security);
> + int (*tun_dev_attach) (struct sock *sk, void *security);
> + int (*tun_dev_open) (void *security);
> #endif /* CONFIG_SECURITY_NETWORK */
>
> #ifdef CONFIG_SECURITY_NETWORK_XFRM
> @@ -2553,9 +2568,12 @@ void security_inet_conn_established(struct sock *sk,
> int security_secmark_relabel_packet(u32 secid);
> void security_secmark_refcount_inc(void);
> void security_secmark_refcount_dec(void);
> +int security_tun_dev_alloc_security(void **security);
> +void security_tun_dev_free_security(void *security);
> int security_tun_dev_create(void);
> -void security_tun_dev_post_create(struct sock *sk);
> -int security_tun_dev_attach(struct sock *sk);
> +int security_tun_dev_create_queue(void *security);
> +int security_tun_dev_attach(struct sock *sk, void *security);
> +int security_tun_dev_open(void *security);
>
> #else /* CONFIG_SECURITY_NETWORK */
> static inline int security_unix_stream_connect(struct sock *sock,
> @@ -2720,16 +2738,31 @@ static inline void security_secmark_refcount_dec(void)
> {
> }
>
> +static inline int security_tun_dev_alloc_security(void **security)
> +{
> + return 0;
> +}
> +
> +static inline void security_tun_dev_free_security(void *security)
> +{
> +}
> +
> static inline int security_tun_dev_create(void)
> {
> return 0;
> }
>
> -static inline void security_tun_dev_post_create(struct sock *sk)
> +static inline int security_tun_dev_create_queue(void *security)
> +{
> + return 0;
> +}
> +
> +static inline int security_tun_dev_attach(struct sock *sk, void *security)
> {
> + return 0;
> }
>
> -static inline int security_tun_dev_attach(struct sock *sk)
> +static inline int security_tun_dev_open(void *security)
> {
> return 0;
> }
> diff --git a/security/capability.c b/security/capability.c
> index b14a30c..bf4cbf2 100644
> --- a/security/capability.c
> +++ b/security/capability.c
> @@ -704,16 +704,31 @@ static void cap_req_classify_flow(const struct request_sock *req,
> {
> }
>
> +static int cap_tun_dev_alloc_security(void **security)
> +{
> + return 0;
> +}
> +
> +static void cap_tun_dev_free_security(void *security)
> +{
> +}
> +
> static int cap_tun_dev_create(void)
> {
> return 0;
> }
>
> -static void cap_tun_dev_post_create(struct sock *sk)
> +static int cap_tun_dev_create_queue(void *security)
> +{
> + return 0;
> +}
> +
> +static int cap_tun_dev_attach(struct sock *sk, void *security)
> {
> + return 0;
> }
>
> -static int cap_tun_dev_attach(struct sock *sk)
> +static int cap_tun_dev_open(void *security)
> {
> return 0;
> }
> @@ -1044,8 +1059,11 @@ void __init security_fixup_ops(struct security_operations *ops)
> set_to_cap_if_null(ops, secmark_refcount_inc);
> set_to_cap_if_null(ops, secmark_refcount_dec);
> set_to_cap_if_null(ops, req_classify_flow);
> + set_to_cap_if_null(ops, tun_dev_alloc_security);
> + set_to_cap_if_null(ops, tun_dev_free_security);
> set_to_cap_if_null(ops, tun_dev_create);
> - set_to_cap_if_null(ops, tun_dev_post_create);
> + set_to_cap_if_null(ops, tun_dev_create_queue);
> + set_to_cap_if_null(ops, tun_dev_open);
> set_to_cap_if_null(ops, tun_dev_attach);
> #endif /* CONFIG_SECURITY_NETWORK */
> #ifdef CONFIG_SECURITY_NETWORK_XFRM
> diff --git a/security/security.c b/security/security.c
> index 8dcd4ae..4d82654 100644
> --- a/security/security.c
> +++ b/security/security.c
> @@ -1244,24 +1244,42 @@ void security_secmark_refcount_dec(void)
> }
> EXPORT_SYMBOL(security_secmark_refcount_dec);
>
> +int security_tun_dev_alloc_security(void **security)
> +{
> + return security_ops->tun_dev_alloc_security(security);
> +}
> +EXPORT_SYMBOL(security_tun_dev_alloc_security);
> +
> +void security_tun_dev_free_security(void *security)
> +{
> + security_ops->tun_dev_free_security(security);
> +}
> +EXPORT_SYMBOL(security_tun_dev_free_security);
> +
> int security_tun_dev_create(void)
> {
> return security_ops->tun_dev_create();
> }
> EXPORT_SYMBOL(security_tun_dev_create);
>
> -void security_tun_dev_post_create(struct sock *sk)
> +int security_tun_dev_create_queue(void *security)
> {
> - return security_ops->tun_dev_post_create(sk);
> + return security_ops->tun_dev_create_queue(security);
> }
> -EXPORT_SYMBOL(security_tun_dev_post_create);
> +EXPORT_SYMBOL(security_tun_dev_create_queue);
>
> -int security_tun_dev_attach(struct sock *sk)
> +int security_tun_dev_attach(struct sock *sk, void *security)
> {
> - return security_ops->tun_dev_attach(sk);
> + return security_ops->tun_dev_attach(sk, security);
> }
> EXPORT_SYMBOL(security_tun_dev_attach);
>
> +int security_tun_dev_open(void *security)
> +{
> + return security_ops->tun_dev_open(security);
> +}
> +EXPORT_SYMBOL(security_tun_dev_open);
> +
> #endif /* CONFIG_SECURITY_NETWORK */
>
> #ifdef CONFIG_SECURITY_NETWORK_XFRM
> diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> index 61a5336..f1efb08 100644
> --- a/security/selinux/hooks.c
> +++ b/security/selinux/hooks.c
> @@ -4399,6 +4399,24 @@ static void selinux_req_classify_flow(const struct request_sock *req,
> fl->flowi_secid = req->secid;
> }
>
> +static int selinux_tun_dev_alloc_security(void **security)
> +{
> + struct tun_security_struct *tunsec;
> +
> + tunsec = kzalloc(sizeof(*tunsec), GFP_KERNEL);
> + if (!tunsec)
> + return -ENOMEM;
> + tunsec->sid = current_sid();
> +
> + *security = tunsec;
> + return 0;
> +}
> +
> +static void selinux_tun_dev_free_security(void *security)
> +{
> + kfree(security);
> +}
> +
> static int selinux_tun_dev_create(void)
> {
> u32 sid = current_sid();
> @@ -4414,8 +4432,17 @@ static int selinux_tun_dev_create(void)
> NULL);
> }
>
> -static void selinux_tun_dev_post_create(struct sock *sk)
> +static int selinux_tun_dev_create_queue(void *security)
> {
> + struct tun_security_struct *tunsec = security;
> +
> + return avc_has_perm(current_sid(), tunsec->sid, SECCLASS_TUN_SOCKET,
> + TUN_SOCKET__CREATE_QUEUE, NULL);
> +}
> +
> +static int selinux_tun_dev_attach(struct sock *sk, void *security)
> +{
> + struct tun_security_struct *tunsec = security;
> struct sk_security_struct *sksec = sk->sk_security;
>
> /* we don't currently perform any NetLabel based labeling here and it
> @@ -4425,20 +4452,19 @@ static void selinux_tun_dev_post_create(struct sock *sk)
> * cause confusion to the TUN user that had no idea network labeling
> * protocols were being used */
>
> - /* see the comments in selinux_tun_dev_create() about why we don't use
> - * the sockcreate SID here */
> -
> - sksec->sid = current_sid();
> + sksec->sid = tunsec->sid;
> sksec->sclass = SECCLASS_TUN_SOCKET;
> +
> + return 0;
> }
>
> -static int selinux_tun_dev_attach(struct sock *sk)
> +static int selinux_tun_dev_open(void *security)
> {
> - struct sk_security_struct *sksec = sk->sk_security;
> + struct tun_security_struct *tunsec = security;
> u32 sid = current_sid();
> int err;
>
> - err = avc_has_perm(sid, sksec->sid, SECCLASS_TUN_SOCKET,
> + err = avc_has_perm(sid, tunsec->sid, SECCLASS_TUN_SOCKET,
> TUN_SOCKET__RELABELFROM, NULL);
> if (err)
> return err;
> @@ -4446,8 +4472,7 @@ static int selinux_tun_dev_attach(struct sock *sk)
> TUN_SOCKET__RELABELTO, NULL);
> if (err)
> return err;
> -
> - sksec->sid = sid;
> + tunsec->sid = sid;
>
> return 0;
> }
> @@ -5642,9 +5667,12 @@ static struct security_operations selinux_ops = {
> .secmark_refcount_inc = selinux_secmark_refcount_inc,
> .secmark_refcount_dec = selinux_secmark_refcount_dec,
> .req_classify_flow = selinux_req_classify_flow,
> + .tun_dev_alloc_security = selinux_tun_dev_alloc_security,
> + .tun_dev_free_security = selinux_tun_dev_free_security,
> .tun_dev_create = selinux_tun_dev_create,
> - .tun_dev_post_create = selinux_tun_dev_post_create,
> + .tun_dev_create_queue = selinux_tun_dev_create_queue,
> .tun_dev_attach = selinux_tun_dev_attach,
> + .tun_dev_open = selinux_tun_dev_open,
>
> #ifdef CONFIG_SECURITY_NETWORK_XFRM
> .xfrm_policy_alloc_security = selinux_xfrm_policy_alloc,
> diff --git a/security/selinux/include/objsec.h b/security/selinux/include/objsec.h
> index 26c7eee..aa47bca 100644
> --- a/security/selinux/include/objsec.h
> +++ b/security/selinux/include/objsec.h
> @@ -110,6 +110,10 @@ struct sk_security_struct {
> u16 sclass; /* sock security class */
> };
>
> +struct tun_security_struct {
> + u32 sid; /* SID for the tun device sockets */
> +};
> +
> struct key_security_struct {
> u32 sid; /* SID of key */
> };
^ permalink raw reply
* Re: [RFC PATCH v2 1/3] tun: correctly report an error in tun_flow_init()
From: Jason Wang @ 2012-12-06 10:31 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, linux-security-module, selinux, mst
In-Reply-To: <20121205202604.18626.71229.stgit@localhost>
On Wednesday, December 05, 2012 03:26:04 PM Paul Moore wrote:
> On error, the error code from tun_flow_init() is lost inside
> tun_set_iff(), this patch fixes this by assigning the tun_flow_init()
> error code to the "err" variable which is returned by
> the tun_flow_init() function on error.
>
> Signed-off-by: Paul Moore <pmoore@redhat.com>
> ---
> drivers/net/tun.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index a1b2389..14a0454 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1591,7 +1591,8 @@ static int tun_set_iff(struct net *net, struct file
> *file, struct ifreq *ifr)
> tun_net_init(dev);
>
> - if (tun_flow_init(tun))
> + err = tun_flow_init(tun);
> + if (err < 0)
> goto err_free_dev;
>
> dev->hw_features = NETIF_F_SG | NETIF_F_FRAGLIST |
>
> --
Looks fine, we can separate this out of this series and replace the RFC with
net-next to let David apply it soon.
Thank Paul.
^ 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