* Re: [PATCH 06/10] af_ieee802154: provide dummy get/setsockopt
From: David Miller @ 2009-08-13 3:52 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-7-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:41 +0400
> Provide dummt get/setsockopt implementations to stop these
> syscalls from oopsing on our sockets.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
No need for me to apply this, already in the tree.
^ permalink raw reply
* Re: [PATCH 05/10] nl802154: add support for dumping WPAN interface information
From: David Miller @ 2009-08-13 3:52 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-6-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:40 +0400
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 04/10] documentation: fix wrt. headers rename
From: David Miller @ 2009-08-13 3:52 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-5-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:39 +0400
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 03/10] nl802154: make ieee802154_policy constant
From: David Miller @ 2009-08-13 3:52 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-4-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:38 +0400
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH 02/10] af_ieee802154: fix ioctl processing
From: David Miller @ 2009-08-13 3:51 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-3-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:37 +0400
> fix two errors in ioctl processing:
> 1) if the ioctl isn't supported one should return -ENOIOCTLCMD
> 2) don't call ndo_do_ioctl if the device doesn't provide it
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
This change is already in net-2.6, so submitting it for net-next-2.6
is superfluous. It shows up when I merge net-2.6 into net-next-2.6,
which I keep doing periodically.
If you have dependencies with net-2.6 changes, simply tell me that
I need to merge net-2.6 into net-next-2.6 before applying your
net-next-2.6 patches
^ permalink raw reply
* Re: [PATCH 01/10] af_ieee802154: drop IEEE802154_SIOC_ADD_SLAVE declaration
From: David Miller @ 2009-08-13 3:50 UTC (permalink / raw)
To: dbaryshkov; +Cc: netdev, slapin, linux-zigbee-devel
In-Reply-To: <1249649925-11996-2-git-send-email-dbaryshkov@gmail.com>
From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Date: Fri, 7 Aug 2009 16:58:36 +0400
> IEEE802154_SIOC_ADD_SLAVE was used to allocate 802.15.4 interfaces
> on the top of radio. It's not used anymore, drop it.
>
> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Applied to net-next-2.6
^ permalink raw reply
* Re: [PATCH] libertas: name the network device wlan%d
From: Daniel Drake @ 2009-08-13 3:48 UTC (permalink / raw)
To: Dan Williams
Cc: John W. Linville, Daniel Mack, libertas-dev, Roel Kluin, netdev
In-Reply-To: <1250094662.31650.24.camel@localhost.localdomain>
2009/8/12 Dan Williams <dcbw@redhat.com>:
> Daniel, is it a problem for you guys if the libertas wifi interface name
> went from 'eth' -> 'wlan' ? Mesh name would be unchanged.
I can't think of any problems.
Daniel
^ permalink raw reply
* Re: [PATCH] e1000e: fix use of pci_enable_pcie_error_reporting
From: David Miller @ 2009-08-13 3:46 UTC (permalink / raw)
To: dfeng
Cc: john.ronciak, peter.p.waskiewicz.jr, bruce.w.allan,
jesse.brandeburg, jeffrey.t.kirsher, e1000-devel, netdev,
linux-kernel
In-Reply-To: <1249637774-32419-1-git-send-email-dfeng@redhat.com>
From: Xiaotian Feng <dfeng@redhat.com>
Date: Fri, 7 Aug 2009 17:36:14 +0800
> 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>
In moving this block of code, you've corrupted the indentation,
making it more indented than it should be.
In any event, I expect the Intel folks to pick this up.
> 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
>
^ permalink raw reply
* Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: David Miller @ 2009-08-13 3:42 UTC (permalink / raw)
To: herbert; +Cc: joamaki, netdev
In-Reply-To: <20090813020606.GA18205@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 13 Aug 2009 12:06:06 +1000
> Jussi Maki <joamaki@gmail.com> wrote:
>>
>> diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
>> index d401dc8..e5195c9 100644
>> --- a/net/xfrm/xfrm_hash.h
>> +++ b/net/xfrm/xfrm_hash.h
>> @@ -16,7 +16,7 @@ static inline unsigned int __xfrm6_addr_hash(xfrm_address_t *addr)
>>
>> static inline unsigned int __xfrm4_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
>> {
>> - return ntohl(daddr->a4 ^ saddr->a4);
>> + return ntohl(daddr->a4 + saddr->a4);
>> }
>
> What if the other side intentionally picks a destination addresses
> to create collisions? Actually it's even easier than that. We
> don't include the SPI in the hash so regardless of how we hash
> it, our peer can simply continue to create SAs with the same
> descriptors and they'll all hash to the same bucket.
Isn't it fruitless to talk about exploiting SA IDs when such things
are setup using an encrypted negotiation sequence and some level of
trust?
Just wondering :-)
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: Bill Fink @ 2009-08-13 2:35 UTC (permalink / raw)
To: David Miller; +Cc: netdev, brice, gallatin
In-Reply-To: <20090812.162921.244358554.davem@davemloft.net>
On Wed, 12 Aug 2009, David Miller wrote:
> From: Bill Fink <billfink@mindspring.com>
> Date: Fri, 7 Aug 2009 17:06:00 -0400
>
> > To kludge around this, I made a different patch to the myri10ge driver.
> > This time I hardcoded the NUMA node in the call to alloc_pages_node()
> > to 2 for devices with an IRQ between 113 and 118 (eth2 through eth7)
> > and to 0 for devices with an IRQ between 119 and 124 (eth8 through eth13).
> > This is of course very specific to our specific system (NUMA node ids
> > and Myricom 10-GigE device IRQs), and is not something that would be
> > generically applicable. But it was useful as a test, and it did
> > improve the receive side performance substantially!
>
> This, unfortunately, won't be comprehensive. You'd also need to
> kludge the NUMA node used for allocation of the skb->data buffer via
> the netdev_alloc_skb() calls in myri10ge_rx_done() and friends.
>
> This could possibly account for why, with your kludge, you still
> were only getting 56.4703 Gbps
I actually did try this. I changed the netdev_alloc_skb() call in
the myri10ge driver to an __alloc_skb() call and explicitly specified
the correct NUMA node (plus all the necessary extra code that gets
done under the covers by netdev_alloc_skb()). It didn't help.
Not being a kernel developer, one thing I didn't know though was if
the skb was initially allocated on NUMA node A, as the skb got expanded
during its processing, would it always stay on NUMA node A, or could
it possibly be migrated subsequently to a different NUMA node B.
-Thanks
-Bill
^ permalink raw reply
* Re: [PATCH] Fix xfrm hash collisions by changing __xfrm4_daddr_saddr_hash to hash addresses with addition
From: Herbert Xu @ 2009-08-13 2:06 UTC (permalink / raw)
To: Jussi Maki; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.1.10.0908071032171.3426@sisapiiri.net.net>
Jussi Maki <joamaki@gmail.com> wrote:
>
> diff --git a/net/xfrm/xfrm_hash.h b/net/xfrm/xfrm_hash.h
> index d401dc8..e5195c9 100644
> --- a/net/xfrm/xfrm_hash.h
> +++ b/net/xfrm/xfrm_hash.h
> @@ -16,7 +16,7 @@ static inline unsigned int __xfrm6_addr_hash(xfrm_address_t *addr)
>
> static inline unsigned int __xfrm4_daddr_saddr_hash(xfrm_address_t *daddr, xfrm_address_t *saddr)
> {
> - return ntohl(daddr->a4 ^ saddr->a4);
> + return ntohl(daddr->a4 + saddr->a4);
> }
What if the other side intentionally picks a destination addresses
to create collisions? Actually it's even easier than that. We
don't include the SPI in the hash so regardless of how we hash
it, our peer can simply continue to create SAs with the same
descriptors and they'll all hash to the same bucket.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] ipv6: Log the explicit address that triggered DAD failure
From: Brian Haley @ 2009-08-13 1:33 UTC (permalink / raw)
To: Jens Rosenboom; +Cc: Linux Network Developers, David Miller
In-Reply-To: <1250089107.6641.36.camel@fnki-nb00130>
Jens Rosenboom wrote:
> If an interface has multiple addresses, the current message for DAD
> failure isn't really helpful, so this patch adds the address itself to
> the printk.
>
> Signed-off-by: Jens Rosenboom <jens@mcbone.net>
>
> ---
>
> diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
> index 43b3c9f..01a4b25 100644
> --- a/net/ipv6/addrconf.c
> +++ b/net/ipv6/addrconf.c
> @@ -1403,8 +1403,8 @@ void addrconf_dad_failure(struct inet6_ifaddr
> *ifp)
> struct inet6_dev *idev = ifp->idev;
>
> if (net_ratelimit())
> - printk(KERN_INFO "%s: IPv6 duplicate address detected!\n",
> - ifp->idev->dev->name);
> + printk(KERN_INFO "%s: IPv6 duplicate address %pI6 detected!\n",
> + ifp->idev->dev->name, &ifp->addr);
>
> if (idev->cnf.accept_dad > 1 && !idev->cnf.disable_ipv6) {
> struct in6_addr addr;
I have no problem with this patch, I should have done this when I
last changed this code.
The other thing I've come across that is similar to this is the
issue that when DAD fails, /sbin/ip doesn't show that it did,
the address just stays in a tentative state forever:
inet6 dead:beef::1/64 scope global tentative
valid_lft forever preferred_lft forever
Does anyone have an issue of adding a "dadfailed" flag to make
this more obvious:
inet6 dead:beef::1/64 scope global tentative dadfailed
valid_lft forever preferred_lft forever
-Brian
^ permalink raw reply
* Re: [RFC] ipv6: Change %pI6 format to output compacted addresses?
From: Brian Haley @ 2009-08-13 1:33 UTC (permalink / raw)
To: Jens Rosenboom; +Cc: Linux Network Developers
In-Reply-To: <1250091560.6641.48.camel@fnki-nb00130>
Jens Rosenboom wrote:
> Currently the output looks like 2001:0db8:0000:0000:0000:0000:0000:0001
> which might be compacted to 2001:db8::1. The code to do this could be
> adapted from inet_ntop in glibc, which would add about 80 lines to
> lib/vsprintf.c. How do you guys value the tradeoff between more readable
> logging and increased kernel size?
>
> This was already mentioned in
> http://kerneltrap.org/mailarchive/linux-netdev/2008/11/25/4231684 but
> noone seems to have taken up on it.
I think if any changes are made they should try and follow:
http://www.ietf.org/id/draft-kawamura-ipv6-text-representation-03.txt
For one thing, the code today doesn't print things like the v4-mapped
address correctly.
Anyways, can you try this patch, it's less than 40 new lines :)
It might be good enough, but could probably use some help.
-Brian
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 756ccaf..58602ba 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -652,13 +652,46 @@ static char *ip6_addr_string(char *buf, char *end, u8 *addr,
{
char ip6_addr[8 * 5]; /* (8 * 4 hex digits), 7 colons and trailing zero */
char *p = ip6_addr;
- int i;
+ int i, needcolon = 0, printhi;
+ u16 *addr16 = (u16 *)addr;
+ enum { DC_START, DC_MIDDLE, DC_DONE } dcolon = DC_START;
+
+ /* omit leading zeros and shorten using "::" */
for (i = 0; i < 8; i++) {
- p = pack_hex_byte(p, addr[2 * i]);
- p = pack_hex_byte(p, addr[2 * i + 1]);
- if (!(spec.flags & SPECIAL) && i != 7)
- *p++ = ':';
+ if (!(spec.flags & SPECIAL)) {
+ if (addr16[i] == 0 && colon < DC_DONE) {
+ colon = DC_MIDDLE;
+ continue;
+ }
+ if (colon == DC_MIDDLE) {
+ colon = DC_DONE;
+ *p++ = ':';
+ *p++ = ':';
+ } else if (needcolon)
+ *p++ = ':';
+ }
+ printhi = 0;
+ if (addr[2 * i]) {
+ if (addr[2 * i] > 0x0f)
+ p = pack_hex_byte(p, addr[2 * i]);
+ else
+ *p++ = hex_asc_lo(addr[2 * i]);
+ printhi++;
+ }
+ /*
+ * If we printed the high-order bits we must print the
+ * low-order ones, even if they're all zeros.
+ */
+ if (printhi || addr[2 * i + 1] > 0x0f)
+ p = pack_hex_byte(p, addr[2 * i + 1]);
+ else if (addr[2 * i + 1])
+ *p++ = hex_asc_lo(addr[2 * i + 1]);
+ needcolon++;
+ }
+ if (colon == DC_MIDDLE) {
+ *p++ = ':';
+ *p++ = ':';
}
*p = '\0';
spec.flags &= ~SPECIAL;
^ permalink raw reply related
* Re: [patch 1/1] proc connector: add event for process becoming session leader
From: Andrew Morton @ 2009-08-13 1:02 UTC (permalink / raw)
To: David Miller; +Cc: netdev, scott, johnpol, matthltc, oleg
In-Reply-To: <20090812.173203.35197832.davem@davemloft.net>
On Wed, 12 Aug 2009 17:32:03 -0700 (PDT) David Miller <davem@davemloft.net> wrote:
> From: akpm@linux-foundation.org
> Date: Thu, 06 Aug 2009 16:05:47 -0700
>
> > From: Scott James Remnant <scott@ubuntu.com>
> >
> > The act of a process becoming a session leader is a useful signal to a
> > supervising init daemon such as Upstart.
> >
> > While a daemon will normally do this as part of the process of becoming a
> > daemon, it is rare for its children to do so. When the children do, it is
> > nearly always a sign that the child should be considered detached from the
> > parent and not supervised along with it.
> >
> > The poster-child example is OpenSSH; the per-login children call setsid()
> > so that they may control the pty connected to them. If the primary daemon
> > dies or is restarted, we do not want to consider the per-login children
> > and want to respawn the primary daemon without killing the children.
> >
> > This patch adds a new PROC_SID_EVENT and associated structure to the
> > proc_event event_data union, it arranges for this to be emitted when the
> > special PIDTYPE_SID pid is set.
> >
> > [akpm@linux-foundation.org: coding-style fixes]
> > Signed-off-by: Scott James Remnant <scott@ubuntu.com>
> > Acked-by: Matt Helsley <matthltc@us.ibm.com>
> > Cc: Oleg Nesterov <oleg@tv-sign.ru>
> > Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> > Cc: "David S. Miller" <davem@davemloft.net>
> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
>
> Acked-by: David S. Miller <davem@davemloft.net>
Ta.
> This is more process handling level stuff than actual networking
> or connector bits, so it should probably be merged via akpm's
> usual patch bombs or some other relevant tree.
>
> Andrew, if you really want, I can take this into net-next-2.6
No probs, I'll send it for 2.6.32-rc1.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-08-11
From: David Miller @ 2009-08-13 0:38 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090812182403.GF2657@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Wed, 12 Aug 2009 14:24:03 -0400
> When you pull this, could you also revert 57921c31 ("libertas: Read
> buffer overflow"). It has been shown to create a new problem. There
> is work towards a solution to that one, but it isn't a simple clean-up.
Done.
^ permalink raw reply
* Re: pull request: wireless-2.6 2009-08-11
From: David Miller @ 2009-08-13 0:37 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20090811183605.GG2634@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 11 Aug 2009 14:36:06 -0400
> Here are a couple more minor fixes intended for 2.6.31. Hopefully we
> are winding-down!
Pulled, thanks John.
^ permalink raw reply
* Re: [patch 1/1] proc connector: add event for process becoming session leader
From: David Miller @ 2009-08-13 0:32 UTC (permalink / raw)
To: akpm; +Cc: netdev, scott, johnpol, matthltc, oleg
In-Reply-To: <200908062305.n76N5lZj005259@imap1.linux-foundation.org>
From: akpm@linux-foundation.org
Date: Thu, 06 Aug 2009 16:05:47 -0700
> From: Scott James Remnant <scott@ubuntu.com>
>
> The act of a process becoming a session leader is a useful signal to a
> supervising init daemon such as Upstart.
>
> While a daemon will normally do this as part of the process of becoming a
> daemon, it is rare for its children to do so. When the children do, it is
> nearly always a sign that the child should be considered detached from the
> parent and not supervised along with it.
>
> The poster-child example is OpenSSH; the per-login children call setsid()
> so that they may control the pty connected to them. If the primary daemon
> dies or is restarted, we do not want to consider the per-login children
> and want to respawn the primary daemon without killing the children.
>
> This patch adds a new PROC_SID_EVENT and associated structure to the
> proc_event event_data union, it arranges for this to be emitted when the
> special PIDTYPE_SID pid is set.
>
> [akpm@linux-foundation.org: coding-style fixes]
> Signed-off-by: Scott James Remnant <scott@ubuntu.com>
> Acked-by: Matt Helsley <matthltc@us.ibm.com>
> Cc: Oleg Nesterov <oleg@tv-sign.ru>
> Cc: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
> Cc: "David S. Miller" <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Acked-by: David S. Miller <davem@davemloft.net>
This is more process handling level stuff than actual networking
or connector bits, so it should probably be merged via akpm's
usual patch bombs or some other relevant tree.
Andrew, if you really want, I can take this into net-next-2.6
^ permalink raw reply
* Re: 3x59x-fix-pci-resource-management.patch
From: David Miller @ 2009-08-13 0:26 UTC (permalink / raw)
To: akpm; +Cc: sshtylyov, klassert, netdev
In-Reply-To: <20090807091415.6a78af4d.akpm@linux-foundation.org>
From: Andrew Morton <akpm@linux-foundation.org>
Date: Fri, 7 Aug 2009 09:14:15 -0700
> On Fri, 07 Aug 2009 14:53:17 +0400 Sergei Shtylyov <sshtylyov@ru.mvista.com> wrote:
>
>> There was several more comments from you but they all got resolved
>> between you and Jeff at the time...
>>
>
> Doh, OK, thanks. My fault.
>
> I have a cardbus card somewhere..
Please repost this when we have at least some cardbus
testing of some sort, because if we can get rid of all
of that resource special casing that would be nice.
^ permalink raw reply
* Re: module loading permissions and request_module permission inconsistencies
From: Serge E. Hallyn @ 2009-08-12 23:48 UTC (permalink / raw)
To: Eric Paris
Cc: linux-kernel, netdev, linux-security-module, sds, davem,
shemminger, kees, morgan, casey, dwlash
In-Reply-To: <1249933513.2501.58.camel@dhcp231-106.rdu.redhat.com>
Quoting Eric Paris (eparis@redhat.com):
> I'd like to hear thoughts on how we currently do permissions handling on
> request_module() and if it really makes sense? request_module() is the
> function which will do an upcall to try to get modprobe to load a
> specified module into the kernel. It is called in a lot of places
> around the kernel (~128). Of those places only three check to see if
> the REQUESTING process has some sort of module loading permissions
> (CAP_SYS_RAWIO.) Those three are in net/core/dev.c::dev_load() and in
> the IPv4 tcp congestion code in tcp_set_default_congestion_control() and
> tcp_set_congestion_control(). All 125 other calls to request_module()
> appear to be done without any permissions check against the triggering
> process. The actual loading of a module is done in another thread which
> always has permissions, so that side of things appears to not be an
> issue.
>
> First question, why does networking do it's own CAP_SYS_MODULE checks?
> (this is VERY old code, pre-git days) And, does it make sense? In the
> past this has come up in [1] when /sbin/ip triggered the loading of a
> module to get IPv6 tunnel support. It's perfectly reasonable
> for /sbin/ip to do this. But is it reasonable for /sbin/ip to need
> CAP_SYS_MODULE? CAP_SYS_MODULE says that /sbin/ip has permissions to
> load any arbitrary binary it feels like as a kernel module directly. Is
> this really what we want? Should SELinux have to give a hacked /sbin/ip
> permissions to load any arbitrary module? Recently in [2] we find that
> now bluetoothd needs to be granted permissions to directly load any
> kernel module it pleases, just so it can request the upcall loads bnep.
> The same holds basically true for congestion control hooks. Note that
> I'm saying we are giving permission for these to load kernel modules
> directly, not just through the upcall.
Right, so taking a more extreme example, the request_module() in
search_binary_handler... requiring CAP_SYS_MODULE there would mean
you'd have to be privileged to be the first to execute say a
binfmt_misc.
The actual modules are to be protected by protecting /lib/modules
and /sbin/modprobe themselves. So long as those are properly
protected, the ability to cause a call to __request_module() at most
takes up more memory.
So what you say seems to make sense.
-serge
^ permalink raw reply
* Re: [PATCH] net: Fix spinlock use in alloc_netdev_mq()
From: David Miller @ 2009-08-12 23:44 UTC (permalink / raw)
To: jpirko
Cc: akpm, mingo, a.p.zijlstra, torvalds, netdev, linux-kernel,
eric.dumazet
In-Reply-To: <20090806083102.GA3737@psychotron.englab.brq.redhat.com>
From: Jiri Pirko <jpirko@redhat.com>
Date: Thu, 6 Aug 2009 10:31:02 +0200
> Hmm, I see your point here. Eric previously posted patch which moved spin lock
> init into alloc_netdev_mq(). But he was worried about having it here and
> netdev_set_addr_lockdep_class() in register_netdevice() (because before
> dev_unicast_init() dev->type is not set). So how about the following patch?
Well, because of those potential late dev->type settings we
can't do things this way. And I believe those in fact do happen.
So I'm tossing this patch, I wouldn't have applied it to net-2.6
anyways, as it's net-next-2.6 material :-)
^ permalink raw reply
* Re: [PATCH] pppoe: fix race at init time
From: David Miller @ 2009-08-12 23:40 UTC (permalink / raw)
To: gorcunov; +Cc: for.poige+bugzilla.kernel.org, eric.dumazet, xemul, akpm, netdev
In-Reply-To: <20090729144642.GA5094@lenovo>
From: Cyrill Gorcunov <gorcunov@gmail.com>
Date: Wed, 29 Jul 2009 18:46:42 +0400
> net,pppoe: fixup module init/exit subsequent calls
>
> pernet data should allocated first and freed last
> on module init/exit routines otherwise it's possible
> to have unserialized calls to packet handling routines.
>
> Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Still no feedback on this one, but it looks totally correct to me.
So I've applied it to net-next-2.6 so that it doesn't get lost and if
it turns out we need it to actually fix a user reported bug we can
toss it into net-2.6 too.
^ permalink raw reply
* Re: Receive side performance issue with multi-10-GigE and NUMA
From: David Miller @ 2009-08-12 23:29 UTC (permalink / raw)
To: billfink; +Cc: netdev, brice, gallatin
In-Reply-To: <20090807170600.9a2eff2e.billfink@mindspring.com>
From: Bill Fink <billfink@mindspring.com>
Date: Fri, 7 Aug 2009 17:06:00 -0400
> To kludge around this, I made a different patch to the myri10ge driver.
> This time I hardcoded the NUMA node in the call to alloc_pages_node()
> to 2 for devices with an IRQ between 113 and 118 (eth2 through eth7)
> and to 0 for devices with an IRQ between 119 and 124 (eth8 through eth13).
> This is of course very specific to our specific system (NUMA node ids
> and Myricom 10-GigE device IRQs), and is not something that would be
> generically applicable. But it was useful as a test, and it did
> improve the receive side performance substantially!
This, unfortunately, won't be comprehensive. You'd also need to
kludge the NUMA node used for allocation of the skb->data buffer via
the netdev_alloc_skb() calls in myri10ge_rx_done() and friends.
This could possibly account for why, with your kludge, you still
were only getting 56.4703 Gbps
^ permalink raw reply
* Re: AlacrityVM numbers updated for 31-rc4
From: Gregory Haskins @ 2009-08-12 23:21 UTC (permalink / raw)
To: Anthony Liguori
Cc: alacrityvm-devel, alacrityvm-users, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Michael S. Tsirkin, netdev
In-Reply-To: <4A834ABB.4010801@codemonkey.ws>
[-- Attachment #1: Type: text/plain, Size: 1254 bytes --]
Anthony Liguori wrote:
> Gregory Haskins wrote:
>> I re-ran the numbers on 10GE against the actual alacrityvm v0.1 release
>> available in git on kernel.org.
>>
>> I tried to include the newly announced "vhost" driver (Michael Tsirkin)
>> for virtio acceleration, but ran into issues getting the patches to
>> apply.
>>
>> For now, this includes native, virtio-u (virtio-userspace), and venet
>> all running on 31-rc4. If I can resolve the issue with Michaels
>> patches, I will add "virtio-k" (virtio-kernel) to the mix as well. For
>> now, here are the results for 1500mtu:
>>
>> native: 7388Mb/s, 29.8us rtt (33505 tps udp-rr)
>> venet: 3654Mb/s, 56.8us rtt (17600 tps udp-rr)
>> virtio-u: 1955Mb/s, 4016.0us rtt ( 249 tps udp-rr)
>>
>
> Just FYI, the numbers quoted are wrong for virtio-u. Greg's machine
> didn't have high res timers enabled in the kernel. He'll post newer
> numbers later but they're much better than these (venet is still ahead
> though).
>
> Regards,
>
> Anthony Liguori
Anthony is correct. The new numbers after fixing the HRT clock issue are:
virtio-u: 2670Mb/s, 266us rtt (3764 tps udp-rr)
I will update the charts later tonight.
Sorry for the confusion.
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 2/2] selinux: Support for the new TUN LSM hooks
From: Serge E. Hallyn @ 2009-08-12 23:07 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-security-module, netdev, selinux
In-Reply-To: <200908121855.24061.paul.moore@hp.com>
Quoting Paul Moore (paul.moore@hp.com):
> On Wednesday 12 August 2009 06:14:40 pm Serge E. Hallyn wrote:
> > Quoting Paul Moore (paul.moore@hp.com):
> > > +static int selinux_tun_dev_attach(struct sock *sk)
> > > +{
> > > + struct sk_security_struct *sksec = sk->sk_security;
> > > + u32 sid = current_sid();
> > > + int err;
> > > +
> > > + err = avc_has_perm(sid, sksec->sid, SECCLASS_TUN_SOCKET,
> > > + TUN_SOCKET__RELABELFROM, NULL);
> > > + if (err)
> > > + return err;
> > > + err = avc_has_perm(sid, sid, SECCLASS_RAWIP_SOCKET,
> >
> > Was RAWIP on purpose here?
>
> Nope, a mistake on my part that I hadn't caught yet. Thanks.
>
> > > + TUN_SOCKET__RELABELTO, NULL);
> > > + if (err)
> > > + return err;
> > > +
> > > + sksec->sid = sid;
> > > +
> > > + return 0;
> > > +}
> >
> > IIUC it is possible for multiple processes to attach to the same
> > tun device. Will it get confusing/incorrect to have each attach
> > potentially (if tasks have different sids) relabel?
>
> I may be reading the code wrong, but in drivers/net/tun.c:tun_attach() the
> code checks to see if the TUN device is already in use and if it is then the
> attach fails with -EBUSY (check where the tun_device->tfile is examined). I
Ah yes, you're right - I saw the check for (ifr->ifr_flags & IFF_TUN_EXCL) in
the attach path in tun_set_iff, and missed this one.
> believe this should ensure that only one process at a time has access to the
> TUN device so we shouldn't have to worry about a TUN socket getting relabeled
> while it is currently in use. As far as persistent TUN devices getting
> relabeled when a new process attaches to them, that is what we are trying to
> accomplish here so that the network traffic being sent via the TUN device is
> labeled according to the currently attached process; this is consistent with
> how SELinux currently labels locally generated outbound traffic - outbound
> packets inherit their security label from the sending process via the
> originating socket/sock.
Ok, thanks. To my untrained eye the class addition looks right too, so
with the trivial change:
Acked-by: Serge Hallyn <serue@us.ibm.com>
thanks,
-serge
^ permalink raw reply
* Re: AlacrityVM numbers updated for 31-rc4
From: Anthony Liguori @ 2009-08-12 23:05 UTC (permalink / raw)
To: Gregory Haskins
Cc: alacrityvm-devel, alacrityvm-users, linux-kernel@vger.kernel.org,
kvm@vger.kernel.org, Michael S. Tsirkin, netdev
In-Reply-To: <4A83296B.3080606@gmail.com>
Gregory Haskins wrote:
> I re-ran the numbers on 10GE against the actual alacrityvm v0.1 release
> available in git on kernel.org.
>
> I tried to include the newly announced "vhost" driver (Michael Tsirkin)
> for virtio acceleration, but ran into issues getting the patches to apply.
>
> For now, this includes native, virtio-u (virtio-userspace), and venet
> all running on 31-rc4. If I can resolve the issue with Michaels
> patches, I will add "virtio-k" (virtio-kernel) to the mix as well. For
> now, here are the results for 1500mtu:
>
> native: 7388Mb/s, 29.8us rtt (33505 tps udp-rr)
> venet: 3654Mb/s, 56.8us rtt (17600 tps udp-rr)
> virtio-u: 1955Mb/s, 4016.0us rtt ( 249 tps udp-rr)
>
Just FYI, the numbers quoted are wrong for virtio-u. Greg's machine
didn't have high res timers enabled in the kernel. He'll post newer
numbers later but they're much better than these (venet is still ahead
though).
Regards,
Anthony Liguori
^ 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