* Re: failure to find rate WARN_ON on iwlagn
From: Dave Jones @ 2011-08-02 2:31 UTC (permalink / raw)
To: netdev; +Cc: ilw
In-Reply-To: <20110706151128.GB1425@redhat.com>
On Wed, Jul 06, 2011 at 11:11:28AM -0400, Dave Jones wrote:
> I just hit this trace 3 times on this hardware..
> 04:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
I'm still seeing this every couple days, even on current trees.
Dave
> wlan0: authenticate with b8:c7:5d:0c:39:88 (try 1)
> wlan0: authenticate with b8:c7:5d:0c:39:88 (try 2)
> wlan0: authenticate with b8:c7:5d:0c:39:88 (try 3)
> wlan0: authentication with b8:c7:5d:0c:39:88 timed out
> ------------[ cut here ]------------
> WARNING: at include/net/mac80211.h:3081 rate_control_send_low+0x8b/0x10f [mac80211]()
> Hardware name: Adamo 13
> Modules linked in: sctp libcrc32c ip_queue can_raw cmtp kernelcapi rfcomm can_bcm hidp caif_socket caif af_802154 phonet af_rxrpc can pppoe pppox ppp_generic slhc irda crc_ccitt rds af_key decnet rose ax25 x25 atm appletalk ipx p8022 psnap llc p8023 tcp_lp nfs fscache fuse nfsd lockd nfs_acl auth_rpcgss sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables btusb bluetooth arc4 dell_wmi sparse_keymap snd_usb_audio snd_usbmidi_lib snd_rawmidi snd_hda_codec_hdmi snd_hda_codec_idt cdc_ether usbnet cdc_wdm mii snd_hda_intel snd_hda_codec snd_hwdep cdc_acm uvcvideo dell_laptop snd_seq microcode videodev v4l2_compat_ioctl32 dcdbas snd_seq_device snd_pcm iwlagn mac80211 iTCO_wdt tg3 cfg80211 pcspkr joydev i2c_i801 iTCO_vend
or_support rfkill snd_timer snd soundcore snd_page_alloc wmi virtio_net kvm_intel kvm ipv6 xts gf128mul dm_crypt i915 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_s!
> can]
> Pid: 0, comm: swapper Not tainted 3.0.0-rc5+ #89
> Call Trace:
> <IRQ> [<ffffffff8105acfc>] warn_slowpath_common+0x83/0x9b
> [<ffffffff8105ad2e>] warn_slowpath_null+0x1a/0x1c
> [<ffffffffa0252b17>] rate_control_send_low+0x8b/0x10f [mac80211]
> [<ffffffffa0291c59>] rs_get_rate+0x138/0x215 [iwlagn]
> [<ffffffffa0252fcf>] rate_control_get_rate+0x86/0x14c [mac80211]
> [<ffffffff814cf60e>] ? _raw_spin_unlock_irqrestore+0x6c/0x7a
> [<ffffffffa025bde1>] invoke_tx_handlers+0x8f3/0xf47 [mac80211]
> [<ffffffffa025a4f0>] ? compare_ether_addr+0x2c/0x2c [mac80211]
> [<ffffffff814c818e>] ? __slab_alloc+0x399/0x3b4
> [<ffffffffa025c4b4>] ieee80211_tx+0x7f/0xaf [mac80211]
> [<ffffffffa025c66a>] ieee80211_xmit+0x186/0x19a [mac80211]
> [<ffffffff81060d3f>] ? __local_bh_disable+0x8c/0xbe
> [<ffffffffa025d5dc>] ieee80211_tx_skb+0x56/0x5e [mac80211]
> [<ffffffffa02493c3>] ieee80211_send_bar+0xda/0xe9 [mac80211]
> [<ffffffffa0243928>] ieee80211_tx_status+0x25c/0x808 [mac80211]
> [<ffffffff814cf600>] ? _raw_spin_unlock_irqrestore+0x5e/0x7a
> [<ffffffffa0242d12>] ieee80211_tasklet_handler+0x5b/0xa8 [mac80211]
> [<ffffffff81061311>] tasklet_action+0x93/0xf3
> [<ffffffff810614ba>] __do_softirq+0x10f/0x257
> [<ffffffff814d6bdc>] call_softirq+0x1c/0x30
> [<ffffffff8100bcaa>] do_softirq+0x4b/0xa1
> [<ffffffff8106189d>] irq_exit+0x5d/0xb5
> [<ffffffff814d747d>] do_IRQ+0x8d/0xa4
> [<ffffffff814cfc13>] common_interrupt+0x13/0x13
> <EOI> [<ffffffff814d29f7>] ? notifier_call_chain+0xbb/0xbb
> [<ffffffff812e11c3>] ? arch_local_irq_enable+0x8/0xd
> [<ffffffff8108e2a8>] ? trace_hardirqs_on+0xd/0xf
> [<ffffffff812e1d80>] acpi_idle_enter_c1+0xa0/0xbe
> [<ffffffff813e0acb>] cpuidle_idle_call+0x10c/0x1eb
> [<ffffffff81009323>] cpu_idle+0xe3/0x143
> [<ffffffff81d3dbc2>] ? start_kernel+0x401/0x40c
> [<ffffffff814abc71>] rest_init+0xd5/0xdc
> [<ffffffff814abb9c>] ? csum_partial_copy_generic+0x16c/0x16c
> [<ffffffff81d3dbc2>] start_kernel+0x401/0x40c
> [<ffffffff81d3d2c4>] x86_64_start_reservations+0xaf/0xb3
> [<ffffffff81d3d140>] ? early_idt_handlers+0x140/0x140
> [<ffffffff81d3d3ca>] x86_64_start_kernel+0x102/0x111
> ---[ end trace ab18f52dc63f6394 ]---
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
---end quoted text---
^ permalink raw reply
* Re: [net-next v2 28/71] 8139*/atp/r8169/sc92031: Move the Realtek drivers
From: Jeff Garzik @ 2011-08-02 3:21 UTC (permalink / raw)
To: Ben Hutchings
Cc: Jeff Kirsher, davem, netdev, gospo, sassmann,
Realtek linux nic maintainers, Francois Romieu, Donald Becker
In-Reply-To: <1312244694.2591.42.camel@deadeye>
On 08/01/2011 08:24 PM, Ben Hutchings wrote:
> On Sat, 2011-07-30 at 20:26 -0700, Jeff Kirsher wrote:
>> Move the Realtek drivers into drivers/net/ethernet/realtek/ and make
>> the necessary Kconfig and Makefile changes.
> [...]
>
> Does it really make sense to move the pci-skeleton driver? Although it
> includes hardware access specific to RTL8139 chips, that's not really
> the point of it.
Indeed. pci-skeleton was simply intended to illustrate a clean driver
for a simple DMA-driven NIC.
Honestly, it's so outdated now that deletion would be a better course.
Jeff
^ permalink raw reply
* Re: [net-next v2 28/71] 8139*/atp/r8169/sc92031: Move the Realtek drivers
From: Jeff Kirsher @ 2011-08-02 3:41 UTC (permalink / raw)
To: Jeff Garzik
Cc: Ben Hutchings, davem@davemloft.net, netdev@vger.kernel.org,
gospo@redhat.com, sassmann@redhat.com,
Realtek linux nic maintainers, Francois Romieu, Donald Becker
In-Reply-To: <4E376D30.6050406@pobox.com>
[-- Attachment #1: Type: text/plain, Size: 834 bytes --]
On Mon, 2011-08-01 at 20:21 -0700, Jeff Garzik wrote:
> On 08/01/2011 08:24 PM, Ben Hutchings wrote:
> > On Sat, 2011-07-30 at 20:26 -0700, Jeff Kirsher wrote:
> >> Move the Realtek drivers into drivers/net/ethernet/realtek/ and make
> >> the necessary Kconfig and Makefile changes.
> > [...]
> >
> > Does it really make sense to move the pci-skeleton driver? Although it
> > includes hardware access specific to RTL8139 chips, that's not really
> > the point of it.
>
> Indeed. pci-skeleton was simply intended to illustrate a clean driver
> for a simple DMA-driven NIC.
>
> Honestly, it's so outdated now that deletion would be a better course.
If it would be useful, should we take the time to update pci-skeleton
driver? Or will this be a maintenance issue going forward and deletion
is the best answer?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [Bug?] Machine hangs, rtl8192se possible cause
From: Larry Finger @ 2011-08-02 3:45 UTC (permalink / raw)
To: Jaroslaw Fedewicz
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <CAFdoEiRBPMx0C+YXwd4-Q=_nHpOb+r2+GspwujZrPh6S4tDwEQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On 08/01/2011 06:10 PM, Jaroslaw Fedewicz wrote:
>
> I'm using a fairly recent version of kernel from git (I think from
> before yesterday). The mysterious hangs were there from the beginning,
> but it also might be partly because ATI driver was messed up too at
> these times. Later, ati appeared fixed but the hangs wouldn't go away.
If that git tree is linux-2.6, or its new name, from Linus, then you have the
latest source.
> I don't think it's a panic proper, though. Nothing ever gets logged
> along the lines of "panic". Even if I happen to have a text mode
> console, it just freezes. If I have a panic or an oops proper, I'm
> also kicked out of X11 to see it by the KMS. But not in this case.
>
> (Also, the laptop has neither Caps Lock nor Num Lock nor Scroll Lock
> LEDs, so I can't see if they blink.)
A kernel panic never logs anything to the disk. The only place you will see it
is on the logging console, or in netconsole output.
> What raised my suspicions is that I've never seen this happen when
> rtl8192se wasn't compiled at all or was not loaded.
>
> The most problematic thing is that it does not hang right away. Most
> of the time, I see the machine go into the catatonia after quite a
> while, and as it is not the laptop I do most of my work on, I usually
> see it hanged when screen PM has already kicked in. So I cannot really
> read what the log might say on the matter.
>
> I cannot also trigger the freeze reliably. Most of the time it happens
> "when you are not looking at it", and it usually happens either during
> or just after high load averages and low to none network activity (a
> typical scenario: build a firefox from sources, go outside, come home
> 4 hours later, the laptop is turned on but dead by hanging; no
> messages as the screen is obviously off; a less typical scenario is to
> freeze during startup).
>
> I'm the last person ever to suggest anything on the subject, but could
> it be a problem in the card's power management?
Not likely. I have three different cards with differing configurations that I
have run for extended periods without seeing your problem. One of them is the
same as yours.
Until you get some kind of dump from the system, I'm not sure what can be done.
Larry
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [net-next v2 28/71] 8139*/atp/r8169/sc92031: Move the Realtek drivers
From: David Miller @ 2011-08-02 3:48 UTC (permalink / raw)
To: jgarzik
Cc: bhutchings, jeffrey.t.kirsher, netdev, gospo, sassmann, nic_swsd,
romieu, becker
In-Reply-To: <4E376D30.6050406@pobox.com>
From: Jeff Garzik <jgarzik@pobox.com>
Date: Mon, 01 Aug 2011 23:21:20 -0400
> On 08/01/2011 08:24 PM, Ben Hutchings wrote:
>> On Sat, 2011-07-30 at 20:26 -0700, Jeff Kirsher wrote:
>>> Move the Realtek drivers into drivers/net/ethernet/realtek/ and make
>>> the necessary Kconfig and Makefile changes.
>> [...]
>>
>> Does it really make sense to move the pci-skeleton driver? Although
>> it
>> includes hardware access specific to RTL8139 chips, that's not really
>> the point of it.
>
> Indeed. pci-skeleton was simply intended to illustrate a clean driver
> for a simple DMA-driven NIC.
>
> Honestly, it's so outdated now that deletion would be a better course.
Yeah, this is probably true.
^ permalink raw reply
* Re: [net-next v2 70/71] tile: Move the Tilera driver
From: Jeff Kirsher @ 2011-08-02 3:53 UTC (permalink / raw)
To: Chris Metcalf, H Hartley Sweeten, Geert Uytterhoeven
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
In-Reply-To: <4E36E0B2.60900@tilera.com>
[-- Attachment #1: Type: text/plain, Size: 3479 bytes --]
On Mon, 2011-08-01 at 10:21 -0700, Chris Metcalf wrote:
> On 7/30/2011 11:27 PM, Jeff Kirsher wrote:
> > Move the Tilera driver into drivers/net/ethernet/tile and
> > make the necessary Kconfig and Makefile changes.
> >
> > CC: Chris Metcalf <cmetcalf@tilera.com>
> > Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> > [...]
> > +++ b/drivers/net/ethernet/tile/Kconfig
> > @@ -0,0 +1,28 @@
> > +#
> > +# Tilera network device configuration
> > +#
> > +
> > +config NET_VENDOR_TILERA
> > + bool "Tilera devices"
> > + depends on TILE
> > + ---help---
> > + If you have a network (Ethernet) card belonging to this class, say Y
> > + and read the Ethernet-HOWTO, available from
> > + <http://www.tldp.org/docs.html#howto>.
> > +
> > + Note that the answer to this question doesn't directly affect the
> > + kernel: saying N will just cause the configurator to skip all
> > + the questions about Tilera cards. If you say Y, you will be asked for
> > + your specific card in the following questions.
> > +
> > +config TILE_NET
> > + tristate "Tilera GBE/XGBE network driver support"
> > + depends on NET_VENDOR_TILERA && TILE
> > + default y
> > + select CRC32
> > + ---help---
> > + This is a standard Linux network device driver for the
> > + on-chip Tilera Gigabit Ethernet and XAUI interfaces.
> > +
> > + To compile this driver as a module, choose M here: the module
> > + will be called tile_net.
>
> Overall, this seems fine, since the Tilera drivers get grouped more
> appropriately as a result. However, the drivers in question are not
> Ethernet cards (and Tilera is not an Ethernet card vendor and has no plans
> to become one). Instead, this is the driver support for the built-in
> networking hardware on the Tilera multicore CPU chip. I'm happy to group
> this support under drivers/net/ethernet/tile/, but I think it's appropriate
> to default it to "Y" if you are building a TILE kernel (since you are
> guaranteed to have the networking hardware available).
>
> I suspect for now the cleanest thing to do is to fold the two config
> options together, using NET_VENDOR_TILERA for consistency with other
> NET_VENDOR_xxx symbols, and defaulting it to "Y" via "depends on TILE". I
> don't think the Ethernet-HOWO reference is particularly helpful since it
> mostly tackles all the various card issues, kernel boot param issues, etc.,
> none of which are relevant to this driver. Something like:
>
> +config NET_VENDOR_TILERA
> + bool "Tilera devices"
> + depends on TILE
> + default y
> + select CRC32
> + ---help---
> + This is a standard Linux network device driver for the arch/tile
> + on-chip Gigabit Ethernet and XAUI interfaces.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called tile_net.
>
>
> Obviously you'd also need to tweak the TILE_NET symbol in the Makefile to
> be VENDOR_TILERA. If this makes sense to you, go ahead and make the
> change, and feel free to use my
>
> Acked-by: Chris Metcalf <cmetcalf@tilera.com>
>
Sounds fine, I will make the necessary changes.
Also based on feedback from Hartley Sweeten and Geert Uytterhoeven, I
will make a change to the Kconifg's to make it less a maintenance issue
going forward by wrapping the drivers in the Kconfig with "if
NET_VENDOR_<blah> ... endif. This way new drivers will not have to add
the dependency of NET_VENDOR_<blah>.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [net-next v2 28/71] 8139*/atp/r8169/sc92031: Move the Realtek drivers
From: Jeff Kirsher @ 2011-08-02 3:58 UTC (permalink / raw)
To: David Miller
Cc: jgarzik@pobox.com, bhutchings@solarflare.com,
netdev@vger.kernel.org, gospo@redhat.com, sassmann@redhat.com,
nic_swsd@realtek.com, romieu@fr.zoreil.com, becker@scyld.com
In-Reply-To: <20110801.204840.1467588276691539635.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 883 bytes --]
On Mon, 2011-08-01 at 20:48 -0700, David Miller wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> Date: Mon, 01 Aug 2011 23:21:20 -0400
>
> > On 08/01/2011 08:24 PM, Ben Hutchings wrote:
> >> On Sat, 2011-07-30 at 20:26 -0700, Jeff Kirsher wrote:
> >>> Move the Realtek drivers into drivers/net/ethernet/realtek/ and make
> >>> the necessary Kconfig and Makefile changes.
> >> [...]
> >>
> >> Does it really make sense to move the pci-skeleton driver? Although
> >> it
> >> includes hardware access specific to RTL8139 chips, that's not really
> >> the point of it.
> >
> > Indeed. pci-skeleton was simply intended to illustrate a clean driver
> > for a simple DMA-driven NIC.
> >
> > Honestly, it's so outdated now that deletion would be a better course.
>
> Yeah, this is probably true.
Ok, I will remove it.
I will put together a v3 of the series.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: David Miller @ 2011-08-02 6:07 UTC (permalink / raw)
To: penguin-kernel; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <201107280336.p6S3aUY7004372@www262.sakura.ne.jp>
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: Thu, 28 Jul 2011 12:36:30 +0900
> Here is an optimized version. Only compile tested.
Anton, please test this or I'm just going to apply it before it
gets any testing :-)
^ permalink raw reply
* [PATCH net] bnx2x: Prevent restarting Tx during bnx2x_nic_unload
From: Vlad Zolotarov @ 2011-08-02 7:52 UTC (permalink / raw)
To: Dave Miller; +Cc: netdev@vger.kernel.org, Eilon Greenstein
Tx queues were stopped before bp->state was changed to a value different
from BNX2X_STATE_OPEN, which allowed the bnx2x_tx_int() called from the
NAPI context to re-enable it. This then allowed the netdev->ndo_start_xmit()
to be called in the middle of the function reset and rings freeing.
This patch changes bp->state to a value different
from BNX2X_STATE_OPEN BEFORE disabling the Tx queues in order to restore the
broken protection against the above race in the bnx2x_tx_int().
Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
---
drivers/net/bnx2x/bnx2x_cmn.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2x/bnx2x_cmn.c b/drivers/net/bnx2x/bnx2x_cmn.c
index 5b0dba6..d724a18 100644
--- a/drivers/net/bnx2x/bnx2x_cmn.c
+++ b/drivers/net/bnx2x/bnx2x_cmn.c
@@ -1989,14 +1989,20 @@ int bnx2x_nic_unload(struct bnx2x *bp, int unload_mode)
return -EINVAL;
}
+ /*
+ * It's important to set the bp->state to the value different from
+ * BNX2X_STATE_OPEN and only then stop the Tx. Otherwise bnx2x_tx_int()
+ * may restart the Tx from the NAPI context (see bnx2x_tx_int()).
+ */
+ bp->state = BNX2X_STATE_CLOSING_WAIT4_HALT;
+ smp_mb();
+
/* Stop Tx */
bnx2x_tx_disable(bp);
#ifdef BCM_CNIC
bnx2x_cnic_notify(bp, CNIC_CTL_STOP_CMD);
#endif
- bp->state = BNX2X_STATE_CLOSING_WAIT4_HALT;
- smp_mb();
bp->rx_mode = BNX2X_RX_MODE_NONE;
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH net] bnx2x: Prevent restarting Tx during bnx2x_nic_unload
From: David Miller @ 2011-08-02 8:35 UTC (permalink / raw)
To: vladz; +Cc: netdev, eilong
In-Reply-To: <201108021052.37368.vladz@broadcom.com>
From: "Vlad Zolotarov" <vladz@broadcom.com>
Date: Tue, 2 Aug 2011 10:52:37 +0300
> Tx queues were stopped before bp->state was changed to a value different
> from BNX2X_STATE_OPEN, which allowed the bnx2x_tx_int() called from the
> NAPI context to re-enable it. This then allowed the netdev->ndo_start_xmit()
> to be called in the middle of the function reset and rings freeing.
>
> This patch changes bp->state to a value different
> from BNX2X_STATE_OPEN BEFORE disabling the Tx queues in order to restore the
> broken protection against the above race in the bnx2x_tx_int().
>
> Signed-off-by: Vladislav Zolotarov <vladz@broadcom.com>
> Signed-off-by: Eilon Greenstein <eilong@broadcom.com>
Applied, thansk Vlad.
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Tetsuo Handa @ 2011-08-02 9:28 UTC (permalink / raw)
To: davem; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <20110801.230731.1942061135621106602.davem@davemloft.net>
David Miller wrote:
> From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Date: Thu, 28 Jul 2011 12:36:30 +0900
>
> > Here is an optimized version. Only compile tested.
>
> Anton, please test this or I'm just going to apply it before it
> gets any testing :-)
Just a moment please. I found a problem (described below).
I tested on TOMOYO using below program
--- Start of test program ---
#include <string.h>
#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <signal.h>
#include <netdb.h>
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <net/if.h>
#include <net/ethernet.h>
#include <linux/if_packet.h>
#include <asm/unistd.h>
#include <errno.h>
#ifndef __NR_sendmmsg
#if defined( __PPC__)
#define __NR_sendmmsg 349
#elif defined(__x86_64__)
#define __NR_sendmmsg 307
#elif defined(__i386__)
#define __NR_sendmmsg 345
#else
#error __NR_sendmmsg not defined
#endif
#endif
struct mmsghdr {
struct msghdr msg_hdr;
unsigned int msg_len;
};
static inline int sendmmsg(int fd, struct mmsghdr *mmsg, unsigned vlen,
unsigned flags)
{
return syscall(__NR_sendmmsg, fd, mmsg, vlen, flags, NULL);
}
static unsigned long packets;
static unsigned long packets_prev;
static void sigalrm_handler(int junk)
{
unsigned long p = packets;
printf("%ld\n", p - packets_prev);
packets_prev = p;
alarm(1);
}
#define NUMDESTS 20
#define NUMBATCH 100
int main(int argc, char *argv[])
{
const int fd = socket(AF_INET, SOCK_DGRAM, 0);
unsigned int i;
char b[10];
static char buf[NUMBATCH][10];
static struct iovec iovec[NUMBATCH][1];
static struct mmsghdr datagrams[NUMBATCH];
struct sockaddr_in addr[NUMDESTS];
signal(SIGALRM, sigalrm_handler);
alarm(1);
memset(buf, 0, sizeof(buf));
memset(iovec, 0, sizeof(iovec));
memset(datagrams, 0, sizeof(datagrams));
memset(&addr, 0, sizeof(addr));
for (i = 0; i < sizeof(b); i++)
b[i]= i;
for (i = 0; i < NUMDESTS; i++) {
addr[i].sin_family = AF_INET;
addr[i].sin_addr.s_addr = htonl(INADDR_LOOPBACK);
addr[i].sin_port = htons(10000 + (argc == 1 ? i : 0) * 10);
}
for (i = 0; i < NUMBATCH; ++i) {
memcpy(&buf[i], b, sizeof(buf[i]));
iovec[i][0].iov_base = buf[i];
iovec[i][0].iov_len = sizeof(buf[i]);
datagrams[i].msg_hdr.msg_iov = iovec[i];
datagrams[i].msg_hdr.msg_iovlen = 1;
datagrams[i].msg_hdr.msg_name = &addr[i % NUMDESTS];
datagrams[i].msg_hdr.msg_namelen = sizeof(addr[0]);
}
while (1) {
int ret;
errno = 0;
ret = sendmmsg(fd, datagrams, NUMBATCH, 0);
if (ret < 0) {
perror("sendmmsg");
exit(1);
}
if (ret != NUMBATCH) {
fprintf(stderr,
"sendmmsg returned sent less than batch %d\n", ret);
}
packets += ret;
}
return 0;
}
--- End of test program ---
and realized that remembering the fact that LSM module has returned an error
code other than -EAGAIN causes subsequent sendmmsg() request to fail with that
error code.
fput_light(sock->file, fput_needed);
if (err == 0)
return datagrams;
if (datagrams != 0) {
/*
* We may send less entries than requested (vlen) if the
* sock is non blocking...
*/
if (err != -EAGAIN) {
/*
* ... or if sendmsg returns an error after we
* send some datagrams, where we record the
* error to return on the next call or if the
* app asks about it using getsockopt(SO_ERROR).
*/
sock->sk->sk_err = -err;
}
return datagrams;
}
return err;
For example, if TOMOYO returned -EPERM on the 14th datagram,
subsequent sendmmsg() fails with EPERM and the program will exit().
sendmmsg returned sent less than batch 14
sendmmsg: Operation not permitted
I think this behavior is not preferable.
In this case, should security_socket_sendmsg() return -EAGAIN rather than
-EPERM?
Or, should sendmmsg() not record errors after some of datagrams were sent?
^ permalink raw reply
* PHY down?
From: Joakim Tjernlund @ 2011-08-02 9:24 UTC (permalink / raw)
To: netdev
I must be missing something obvious but I cannot find how
to bring eth0's PHY down (link down) from user space.
Tried various settings with ethtool and ifconfig eth0 down but it didn't help.
Jocke
^ permalink raw reply
* Re: PHY down?
From: Ben Hutchings @ 2011-08-02 11:01 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OF6D5A2ABF.61D9AA63-ONC12578E0.00335EE4-C12578E0.0033AE22@transmode.se>
On Tue, 2011-08-02 at 11:24 +0200, Joakim Tjernlund wrote:
> I must be missing something obvious but I cannot find how
> to bring eth0's PHY down (link down) from user space.
> Tried various settings with ethtool and ifconfig eth0 down but it didn't help.
If you configure an interface down, and if the interface is not used for
remote management, then some drivers will turn the PHY off. But there
is no general way to control this explicitly.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
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: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: David Miller @ 2011-08-02 11:18 UTC (permalink / raw)
To: penguin-kernel; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <201108020928.p729Sekl091800@www262.sakura.ne.jp>
From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Date: Tue, 02 Aug 2011 18:28:40 +0900
> I think this behavior is not preferable. In this case, should
> security_socket_sendmsg() return -EAGAIN rather than -EPERM? Or,
> should sendmmsg() not record errors after some of datagrams were
> sent?
I think you must return -EAGAIN so that the user can see how many
of the datagrams were sent successfully.
In fact, it is a requirement. What if the sent datagrams have
side effects (f.e. money moves from one bank account to another)?
How else can the application find this out?
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: David Miller @ 2011-08-02 11:26 UTC (permalink / raw)
To: penguin-kernel; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <20110802.041857.1325765319466840715.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 02 Aug 2011 04:18:57 -0700 (PDT)
> From: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
> Date: Tue, 02 Aug 2011 18:28:40 +0900
>
>> I think this behavior is not preferable. In this case, should
>> security_socket_sendmsg() return -EAGAIN rather than -EPERM? Or,
>> should sendmmsg() not record errors after some of datagrams were
>> sent?
>
> I think you must return -EAGAIN so that the user can see how many
> of the datagrams were sent successfully.
>
> In fact, it is a requirement. What if the sent datagrams have
> side effects (f.e. money moves from one bank account to another)?
>
> How else can the application find this out?
Actually, I change my mind. :-)
I think sendmmsg() needs to unconditionally not report an error if any
datagrams were sent successfully.
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Tetsuo Handa @ 2011-08-02 11:52 UTC (permalink / raw)
To: davem; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <20110802.042641.2122529993066553943.davem@davemloft.net>
David Miller wrote:
> Actually, I change my mind. :-)
>
> I think sendmmsg() needs to unconditionally not report an error if any
> datagrams were sent successfully.
What about adding
#ifdef CONFIG_SECURITY_NETWORK
static inline bool security_socket_may_send_multiple_address(void)
{
return security_ops->socket_may_send_multiple_address;
}
#else
static inline bool security_socket_may_send_multiple_address(void)
{
return true;
}
#endif
and letting SMACK and TOMOYO return false and others return true?
The check will look like
if (sendmmsg) {
Record destination address of first datagram if first datagram,
compare with recorded address and subsequent datagram otherwise.
If same address, continue. Otherwise, call
security_socket_may_send_multiple_address() and break if it returns false.
}
. The side effect is that sendmmsg() will be allowed to send to single
destination if underlying LSM module does not permit sending to multiple
address, to multiple destination otherwise. As long as sendmmsg() is used for
sending to single destination, there will be no performance loss.
It will be kmalloc()-free, fast and simple. Also, makes LSM stacking easier.
^ permalink raw reply
* Re: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: David Miller @ 2011-08-02 12:01 UTC (permalink / raw)
To: penguin-kernel; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <201108022052.FBE56208.FLQHFtMOVOSOJF@I-love.SAKURA.ne.jp>
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: Tue, 2 Aug 2011 20:52:05 +0900
> David Miller wrote:
>> Actually, I change my mind. :-)
>>
>> I think sendmmsg() needs to unconditionally not report an error if any
>> datagrams were sent successfully.
>
> What about adding
I much prefer to make the error handling more correct, rather than
making sendmmsg() have fundamentally different semantics depending
upon the underlying LSM.
^ permalink raw reply
* Re: PHY down?
From: Joakim Tjernlund @ 2011-08-02 12:24 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev
In-Reply-To: <1312282868.2591.68.camel@deadeye>
Ben Hutchings <bhutchings@solarflare.com> wrote on 2011/08/02 13:01:08:
>
> On Tue, 2011-08-02 at 11:24 +0200, Joakim Tjernlund wrote:
> > I must be missing something obvious but I cannot find how
> > to bring eth0's PHY down (link down) from user space.
> > Tried various settings with ethtool and ifconfig eth0 down but it didn't help.
>
> If you configure an interface down, and if the interface is not used for
> remote management, then some drivers will turn the PHY off. But there
> is no general way to control this explicitly.
OK, when to stop the PHY doesn't seem standardized. Seem logical to me
to also turn off the PHY when interface is configured down. Perhaps this could
be agreed upon?
What does remote management mean? How do I identify if the I/F is used for remote management?
Jocke
>
> Ben.
^ permalink raw reply
* Re: PHY down?
From: Ben Hutchings @ 2011-08-02 12:38 UTC (permalink / raw)
To: Joakim Tjernlund; +Cc: netdev
In-Reply-To: <OFEC77B7FA.1BCB17E8-ONC12578E0.0043754B-C12578E0.00441F36@transmode.se>
On Tue, 2011-08-02 at 14:24 +0200, Joakim Tjernlund wrote:
> Ben Hutchings <bhutchings@solarflare.com> wrote on 2011/08/02 13:01:08:
> >
> > On Tue, 2011-08-02 at 11:24 +0200, Joakim Tjernlund wrote:
> > > I must be missing something obvious but I cannot find how
> > > to bring eth0's PHY down (link down) from user space.
> > > Tried various settings with ethtool and ifconfig eth0 down but it didn't help.
> >
> > If you configure an interface down, and if the interface is not used for
> > remote management, then some drivers will turn the PHY off. But there
> > is no general way to control this explicitly.
>
> OK, when to stop the PHY doesn't seem standardized. Seem logical to me
> to also turn off the PHY when interface is configured down. Perhaps this could
> be agreed upon?
> What does remote management mean? How do I identify if the I/F is used for remote management?
Most server motherboards have some sort of lights-out management (LOM)
faclity. This is usually accessible when the server is switched on, as
well. It may share a network port or ports with the host OS.
There is no general way to tell whether this is supported or enabled on
an interface, but it should be described in motherboard documentation or
the firmware configuration program (BIOS setup).
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: [PATCH] net: Fix security_socket_sendmsg() bypass problem.
From: Tetsuo Handa @ 2011-08-02 13:11 UTC (permalink / raw)
To: davem; +Cc: eparis, anton, casey, mjt, netdev, linux-security-module
In-Reply-To: <20110802.050115.1714327089688495866.davem@davemloft.net>
David Miller wrote:
> From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
> Date: Tue, 2 Aug 2011 20:52:05 +0900
>
> > David Miller wrote:
> >> Actually, I change my mind. :-)
> >>
> >> I think sendmmsg() needs to unconditionally not report an error if any
> >> datagrams were sent successfully.
> >
> > What about adding
>
> I much prefer to make the error handling more correct, rather than
> making sendmmsg() have fundamentally different semantics depending
> upon the underlying LSM.
>
I see. Here is an updated version.
Changes since V1:
In __sys_sendmmsg(), ignore errors if one or more datagrams were
sent successfully.
But regarding
| I think sendmmsg() needs to unconditionally not report an error if any
| datagrams were sent successfully.
what should I do if put_user() returned error?
A datagram was sent successfully but will return -EFAULT (although I doubt
when such thing can happen).
while (datagrams < vlen) {
/*
* If datagrams == 0, LSM module will check. Otherwise, it will
* check depending on its implementation.
*/
if (MSG_CMSG_COMPAT & flags) {
err = __sys_sendmsg(sock, (struct msghdr __user *)compat_entry,
&msg_sys, flags, datagrams, &list);
if (err < 0)
break;
err = __put_user(err, &compat_entry->msg_len);
++compat_entry;
} else {
err = __sys_sendmsg(sock, (struct msghdr __user *)entry,
&msg_sys, flags, datagrams, &list);
if (err < 0)
break;
err = put_user(err, &entry->msg_len);
++entry;
}
if (err)
break;
++datagrams;
}
----------------------------------------
[PATCH v2] net: Fix security_socket_sendmsg() bypass problem.
The sendmmsg() introduced by commit 228e548e "net: Add sendmmsg socket system
call" is capable of sending to multiple different destinations. However,
security_socket_sendmsg() is called for only once even if multiple different
destination's addresses are passed to sendmmsg().
SMACK is using destination's address for checking sendmsg() permission.
Therefore, we need to call security_socket_sendmsg() for each destination
address rather than only the first destination address.
Fix this regression by
(1) passing "int datagrams" argument to security_socket_sendmsg() so that
SELinux can omit sock_has_perm() checks on the 2nd or later.
(2) passing "struct list_head *list" argument to security_socket_sendmsg() so
that SMACK can omit smack_netlabel_send() checks for duplicated destination
address.
(3) letting __sys_sendmmsg() provide "struct list_head list" for
security_socket_sendmsg() and clean it up before return.
Also, it is not preferable to let next sendmmsg() return previous sendmmsg()'s
error code when some of requested entries were not sent, for the caller will
get confused by next sendmmsg(). Thus, ignore errors if one or more entries
were sent successfully.
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: stable <stable@kernel.org> [3.0+]
---
include/linux/security.h | 16 ++++++++--
include/linux/socket.h | 8 +++++
net/socket.c | 67 +++++++++++++++++++++++----------------------
security/capability.c | 3 +-
security/security.c | 52 +++++++++++++++++++++++++++++++++-
security/selinux/hooks.c | 5 ++-
security/smack/smack_lsm.c | 5 ++-
7 files changed, 114 insertions(+), 42 deletions(-)
--- linux-3.0.orig/include/linux/security.h
+++ linux-3.0/include/linux/security.h
@@ -93,6 +93,7 @@ struct xfrm_policy;
struct xfrm_state;
struct xfrm_user_sec_ctx;
struct seq_file;
+struct list_head;
extern int cap_netlink_send(struct sock *sk, struct sk_buff *skb);
extern int cap_netlink_recv(struct sk_buff *skb, int cap);
@@ -880,6 +881,10 @@ static inline void security_free_mnt_opt
* @sock contains the socket structure.
* @msg contains the message to be transmitted.
* @size contains the size of message.
+ * @datagrams contains the index of messages in sendmmsg(). This is 0 if
+ * not sendmmsg().
+ * @list contains the list head which can be used for holding
+ * already-checked destination address. This is NULL if not sendmmsg().
* Return 0 if permission is granted.
* @socket_recvmsg:
* Check permission before receiving a message from a socket.
@@ -1584,8 +1589,8 @@ struct security_operations {
struct sockaddr *address, int addrlen);
int (*socket_listen) (struct socket *sock, int backlog);
int (*socket_accept) (struct socket *sock, struct socket *newsock);
- int (*socket_sendmsg) (struct socket *sock,
- struct msghdr *msg, int size);
+ int (*socket_sendmsg) (struct socket *sock, struct msghdr *msg,
+ int size, int datagrams, struct list_head *list);
int (*socket_recvmsg) (struct socket *sock,
struct msghdr *msg, int size, int flags);
int (*socket_getsockname) (struct socket *sock);
@@ -2551,7 +2556,9 @@ int security_socket_bind(struct socket *
int security_socket_connect(struct socket *sock, struct sockaddr *address, int addrlen);
int security_socket_listen(struct socket *sock, int backlog);
int security_socket_accept(struct socket *sock, struct socket *newsock);
-int security_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size);
+bool security_sendmsg_uniq_address(struct msghdr *msg, struct list_head *list);
+int security_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size,
+ int datagrams, struct list_head *list);
int security_socket_recvmsg(struct socket *sock, struct msghdr *msg,
int size, int flags);
int security_socket_getsockname(struct socket *sock);
@@ -2636,7 +2643,8 @@ static inline int security_socket_accept
}
static inline int security_socket_sendmsg(struct socket *sock,
- struct msghdr *msg, int size)
+ struct msghdr *msg, int size,
+ int datagrams, struct list_head *list)
{
return 0;
}
--- linux-3.0.orig/include/linux/socket.h
+++ linux-3.0/include/linux/socket.h
@@ -23,6 +23,7 @@ struct __kernel_sockaddr_storage {
#include <linux/uio.h> /* iovec support */
#include <linux/types.h> /* pid_t */
#include <linux/compiler.h> /* __user */
+#include <linux/list.h> /* struct list_head */
struct pid;
struct cred;
@@ -75,6 +76,13 @@ struct mmsghdr {
unsigned msg_len;
};
+/* For remembering destination's address passed to sendmmsg(). */
+struct sendmmsg_dest_info {
+ struct list_head list;
+ unsigned int address_len;
+ struct sockaddr_storage address;
+};
+
/*
* POSIX 1003.1g - ancillary data object information
* Ancillary data consits of a sequence of pairs of
--- linux-3.0.orig/net/socket.c
+++ linux-3.0/net/socket.c
@@ -558,9 +558,10 @@ static inline int __sock_sendmsg_nosec(s
}
static inline int __sock_sendmsg(struct kiocb *iocb, struct socket *sock,
- struct msghdr *msg, size_t size)
+ struct msghdr *msg, size_t size,
+ int datagrams, struct list_head *list)
{
- int err = security_socket_sendmsg(sock, msg, size);
+ int err = security_socket_sendmsg(sock, msg, size, datagrams, list);
return err ?: __sock_sendmsg_nosec(iocb, sock, msg, size);
}
@@ -573,14 +574,16 @@ int sock_sendmsg(struct socket *sock, st
init_sync_kiocb(&iocb, NULL);
iocb.private = &siocb;
- ret = __sock_sendmsg(&iocb, sock, msg, size);
+ ret = __sock_sendmsg(&iocb, sock, msg, size, 0, NULL);
if (-EIOCBQUEUED == ret)
ret = wait_on_sync_kiocb(&iocb);
return ret;
}
EXPORT_SYMBOL(sock_sendmsg);
-int sock_sendmsg_nosec(struct socket *sock, struct msghdr *msg, size_t size)
+static int sock_send_datagrams(struct socket *sock, struct msghdr *msg,
+ size_t size, int datagrams,
+ struct list_head *list)
{
struct kiocb iocb;
struct sock_iocb siocb;
@@ -588,7 +591,7 @@ int sock_sendmsg_nosec(struct socket *so
init_sync_kiocb(&iocb, NULL);
iocb.private = &siocb;
- ret = __sock_sendmsg_nosec(&iocb, sock, msg, size);
+ ret = __sock_sendmsg(&iocb, sock, msg, size, datagrams, list);
if (-EIOCBQUEUED == ret)
ret = wait_on_sync_kiocb(&iocb);
return ret;
@@ -888,7 +891,7 @@ static ssize_t do_sock_write(struct msgh
if (sock->type == SOCK_SEQPACKET)
msg->msg_flags |= MSG_EOR;
- return __sock_sendmsg(iocb, sock, msg, size);
+ return __sock_sendmsg(iocb, sock, msg, size, 0, NULL);
}
static ssize_t sock_aio_write(struct kiocb *iocb, const struct iovec *iov,
@@ -1872,7 +1875,8 @@ SYSCALL_DEFINE2(shutdown, int, fd, int,
#define COMPAT_FLAGS(msg) COMPAT_MSG(msg, msg_flags)
static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
- struct msghdr *msg_sys, unsigned flags, int nosec)
+ struct msghdr *msg_sys, unsigned flags, int datagrams,
+ struct list_head *list)
{
struct compat_msghdr __user *msg_compat =
(struct compat_msghdr __user *)msg;
@@ -1953,8 +1957,7 @@ static int __sys_sendmsg(struct socket *
if (sock->file->f_flags & O_NONBLOCK)
msg_sys->msg_flags |= MSG_DONTWAIT;
- err = (nosec ? sock_sendmsg_nosec : sock_sendmsg)(sock, msg_sys,
- total_len);
+ err = sock_send_datagrams(sock, msg_sys, total_len, datagrams, list);
out_freectl:
if (ctl_buf != ctl)
@@ -1979,7 +1982,7 @@ SYSCALL_DEFINE3(sendmsg, int, fd, struct
if (!sock)
goto out;
- err = __sys_sendmsg(sock, msg, &msg_sys, flags, 0);
+ err = __sys_sendmsg(sock, msg, &msg_sys, flags, 0, NULL);
fput_light(sock->file, fput_needed);
out:
@@ -1998,6 +2001,7 @@ int __sys_sendmmsg(int fd, struct mmsghd
struct mmsghdr __user *entry;
struct compat_mmsghdr __user *compat_entry;
struct msghdr msg_sys;
+ LIST_HEAD(list); /* List for finding duplicated destination address. */
datagrams = 0;
@@ -2014,18 +2018,19 @@ int __sys_sendmmsg(int fd, struct mmsghd
while (datagrams < vlen) {
/*
- * No need to ask LSM for more than the first datagram.
+ * If datagrams == 0, LSM module will check. Otherwise, it will
+ * check depending on its implementation.
*/
if (MSG_CMSG_COMPAT & flags) {
err = __sys_sendmsg(sock, (struct msghdr __user *)compat_entry,
- &msg_sys, flags, datagrams);
+ &msg_sys, flags, datagrams, &list);
if (err < 0)
break;
err = __put_user(err, &compat_entry->msg_len);
++compat_entry;
} else {
err = __sys_sendmsg(sock, (struct msghdr __user *)entry,
- &msg_sys, flags, datagrams);
+ &msg_sys, flags, datagrams, &list);
if (err < 0)
break;
err = put_user(err, &entry->msg_len);
@@ -2038,29 +2043,27 @@ int __sys_sendmmsg(int fd, struct mmsghd
}
out_put:
- fput_light(sock->file, fput_needed);
-
- if (err == 0)
- return datagrams;
-
- if (datagrams != 0) {
- /*
- * We may send less entries than requested (vlen) if the
- * sock is non blocking...
- */
- if (err != -EAGAIN) {
- /*
- * ... or if sendmsg returns an error after we
- * send some datagrams, where we record the
- * error to return on the next call or if the
- * app asks about it using getsockopt(SO_ERROR).
- */
- sock->sk->sk_err = -err;
+#ifdef CONFIG_SECURITY_NETWORK
+ { /* Clean up destination addresses. */
+ struct sendmmsg_dest_info *ptr;
+ struct sendmmsg_dest_info *tmp;
+
+ list_for_each_entry_safe(ptr, tmp, &list, list) {
+ list_del(&ptr->list);
+ kfree(ptr);
}
+ }
+#endif
+ fput_light(sock->file, fput_needed);
+ /*
+ * We may send less entries than requested (vlen), but we ignore errors
+ * if one or more entries were sent successfully.
+ */
+ if (datagrams)
return datagrams;
- }
+ /* Report errors only if no entry was sent. */
return err;
}
--- linux-3.0.orig/security/capability.c
+++ linux-3.0/security/capability.c
@@ -593,7 +593,8 @@ static int cap_socket_accept(struct sock
return 0;
}
-static int cap_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size)
+static int cap_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size,
+ int datagrams, struct list_head *list)
{
return 0;
}
--- linux-3.0.orig/security/security.c
+++ linux-3.0/security/security.c
@@ -17,6 +17,7 @@
#include <linux/kernel.h>
#include <linux/security.h>
#include <linux/ima.h>
+#include <linux/socket.h>
/* Boot-time LSM user choice */
static __initdata char chosen_lsm[SECURITY_NAME_MAX + 1] =
@@ -1036,9 +1037,56 @@ int security_socket_accept(struct socket
return security_ops->socket_accept(sock, newsock);
}
-int security_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size)
+int security_socket_sendmsg(struct socket *sock, struct msghdr *msg, int size,
+ int datagrams, struct list_head *list)
{
- return security_ops->socket_sendmsg(sock, msg, size);
+ return security_ops->socket_sendmsg(sock, msg, size, datagrams, list);
+}
+
+/**
+ * security_sendmsg_uniq_address - Check for duplicated address.
+ *
+ * @msg: Pointer to "struct msg".
+ * @list: Pointer to "struct list_head".
+ *
+ * Returns true if @msg->msg_name is already in @list, false otherwise.
+ * @msg->msg_name will be duplicated and added to @list (unless out-of-memory
+ * occurs) if this function returns true. __sys_sendmmsg() provides @list and
+ * will clean up allocated memory before return.
+ *
+ * Some LSM modules check permission based on destination address at
+ * security_socket_sendmsg(). But checking for duplicated destination
+ * address at common code path is waste of time unless such LSM module is
+ * selected. Therefore, let such LSM modules call this function if they want to
+ * check permission only once for each uniq destination address.
+ */
+bool security_sendmsg_uniq_address(struct msghdr *msg, struct list_head *list)
+{
+ struct sendmmsg_dest_info *ptr;
+
+ /* If not sendmmsg(), this address is uniq. */
+ if (!list)
+ return true;
+ /* If sendmmsg(), check if this address was already used. */
+ list_for_each_entry(ptr, list, list) {
+ if (ptr->address_len != msg->msg_namelen ||
+ memcmp(&ptr->address, msg->msg_name, ptr->address_len))
+ continue;
+ return false;
+ }
+ /*
+ * Remember this address so that subsequent call will return false.
+ *
+ * Out of memory error is not fatal here because checking more than
+ * once should be harmless other than the performance loss.
+ */
+ ptr = kmalloc(sizeof(*ptr), GFP_KERNEL);
+ if (ptr) {
+ ptr->address_len = msg->msg_namelen;
+ memcpy(&ptr->address, msg->msg_name, ptr->address_len);
+ list_add(&ptr->list, list);
+ }
+ return true;
}
int security_socket_recvmsg(struct socket *sock, struct msghdr *msg,
--- linux-3.0.orig/security/selinux/hooks.c
+++ linux-3.0/security/selinux/hooks.c
@@ -3967,9 +3967,10 @@ static int selinux_socket_accept(struct
}
static int selinux_socket_sendmsg(struct socket *sock, struct msghdr *msg,
- int size)
+ int size, int datagrams,
+ struct list_head *list)
{
- return sock_has_perm(current, sock->sk, SOCKET__WRITE);
+ return datagrams ? 0 : sock_has_perm(current, sock->sk, SOCKET__WRITE);
}
static int selinux_socket_recvmsg(struct socket *sock, struct msghdr *msg,
--- linux-3.0.orig/security/smack/smack_lsm.c
+++ linux-3.0/security/smack/smack_lsm.c
@@ -2799,7 +2799,7 @@ static int smack_unix_may_send(struct so
* label host.
*/
static int smack_socket_sendmsg(struct socket *sock, struct msghdr *msg,
- int size)
+ int size, int datagrams, struct list_head *list)
{
struct sockaddr_in *sip = (struct sockaddr_in *) msg->msg_name;
@@ -2809,6 +2809,9 @@ static int smack_socket_sendmsg(struct s
if (sip == NULL || sip->sin_family != AF_INET)
return 0;
+ if (!security_sendmsg_uniq_address(msg, list))
+ return 0;
+
return smack_netlabel_send(sock->sk, sip);
}
^ permalink raw reply
* Re: [PATCH 02/14] allow root in container to copy namespaces (v3)
From: Serge E. Hallyn @ 2011-08-02 14:08 UTC (permalink / raw)
To: Eric W. Biederman
Cc: dhowells-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <m1ei146a6t.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org):
> The dangers of changing the namespace of a process remain the same,
> confused suid programs. I don't believe there are any unique new
> dangers.
>
> Not allowing joining namespaces you already have a copy of is just
> a matter of making it hard to get things wrong.
>
> I would feel more a bit more comfortable if the way we did this was
> to move all of the capable calls into the per namespace methods
> and then changed them one namespace at a time. I don't think
The patch belows moves them into the per namespace methods, for
what it's worth. If you like I can change them, for now, to
'capable(CAP_SYS_ADMIN)' targeted at init_user_ns, but if we're
targetting at the userns owning the destination namespace, it
seems this must be sufficient...
> there are any fundmanetal dangers of allowing unshare without
> the global CAP_SYS_ADMIN, but it would be good to be able to audit
If you have suspicions that there may in fact be dangers, then
perhaps this whole patch should be delayed, and copy_namespaces()
and unshare_nsproxy_namespaces() should continue to check global
CAP_SYS_ADMIN? The only part which would remain would be the
moving of the setns capable check into the per-ns ->install
method, but it would check the global CAP_SYS_ADMIN?
> and make or revoke the decision one namespace at a time.
>
> Eric
>
>
> > Changelog:
> > Jul 29: setns: target capability check for setns
> > When changing to another namespace, make sure that we have
> > the CAP_SYS_ADMIN capability targeted at the user namespace
> > owning the new ns.
> >
> > Signed-off-by: Serge E. Hallyn <serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
> > Cc: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> > ---
> > ipc/namespace.c | 3 +++
> > kernel/fork.c | 4 ++--
> > kernel/nsproxy.c | 7 ++-----
> > kernel/utsname.c | 3 +++
> > net/core/net_namespace.c | 3 +++
> > 5 files changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/ipc/namespace.c b/ipc/namespace.c
> > index ce0a647..f527e49 100644
> > --- a/ipc/namespace.c
> > +++ b/ipc/namespace.c
> > @@ -163,6 +163,9 @@ static void ipcns_put(void *ns)
> >
> > static int ipcns_install(struct nsproxy *nsproxy, void *ns)
> > {
> > + struct ipc_namespace *newns = ns;
> > + if (!ns_capable(newns->user_ns, CAP_SYS_ADMIN))
> > + return -1;
> > /* Ditch state from the old ipc namespace */
> > exit_sem(current);
> > put_ipc_ns(nsproxy->ipc_ns);
> > diff --git a/kernel/fork.c b/kernel/fork.c
> > index e7ceaca..f9fac70 100644
> > --- a/kernel/fork.c
> > +++ b/kernel/fork.c
> > @@ -1488,8 +1488,8 @@ long do_fork(unsigned long clone_flags,
> > /* hopefully this check will go away when userns support is
> > * complete
> > */
> > - if (!capable(CAP_SYS_ADMIN) || !capable(CAP_SETUID) ||
> > - !capable(CAP_SETGID))
> > + if (!nsown_capable(CAP_SYS_ADMIN) || !nsown_capable(CAP_SETUID) ||
> > + !nsown_capable(CAP_SETGID))
> > return -EPERM;
> > }
> >
> > diff --git a/kernel/nsproxy.c b/kernel/nsproxy.c
> > index 9aeab4b..cadcee0 100644
> > --- a/kernel/nsproxy.c
> > +++ b/kernel/nsproxy.c
> > @@ -134,7 +134,7 @@ int copy_namespaces(unsigned long flags, struct task_struct *tsk)
> > CLONE_NEWPID | CLONE_NEWNET)))
> > return 0;
> >
> > - if (!capable(CAP_SYS_ADMIN)) {
> > + if (!nsown_capable(CAP_SYS_ADMIN)) {
> > err = -EPERM;
> > goto out;
> > }
> > @@ -191,7 +191,7 @@ int unshare_nsproxy_namespaces(unsigned long unshare_flags,
> > CLONE_NEWNET)))
> > return 0;
> >
> > - if (!capable(CAP_SYS_ADMIN))
> > + if (!nsown_capable(CAP_SYS_ADMIN))
> > return -EPERM;
> >
> > *new_nsp = create_new_namespaces(unshare_flags, current,
> > @@ -241,9 +241,6 @@ SYSCALL_DEFINE2(setns, int, fd, int, nstype)
> > struct file *file;
> > int err;
> >
> > - if (!capable(CAP_SYS_ADMIN))
> > - return -EPERM;
> > -
> > file = proc_ns_fget(fd);
> > if (IS_ERR(file))
> > return PTR_ERR(file);
> > diff --git a/kernel/utsname.c b/kernel/utsname.c
> > index bff131b..8f648cc 100644
> > --- a/kernel/utsname.c
> > +++ b/kernel/utsname.c
> > @@ -104,6 +104,9 @@ static void utsns_put(void *ns)
> >
> > static int utsns_install(struct nsproxy *nsproxy, void *ns)
> > {
> > + struct uts_namespace *newns = ns;
> > + if (!ns_capable(newns->user_ns, CAP_SYS_ADMIN))
> > + return -1;
> > get_uts_ns(ns);
> > put_uts_ns(nsproxy->uts_ns);
> > nsproxy->uts_ns = ns;
> > diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> > index 5bbdbf0..90c97f6 100644
> > --- a/net/core/net_namespace.c
> > +++ b/net/core/net_namespace.c
> > @@ -620,6 +620,9 @@ static void netns_put(void *ns)
> >
> > static int netns_install(struct nsproxy *nsproxy, void *ns)
> > {
> > + struct net *net = ns;
> > + if (!ns_capable(net->user_ns, CAP_SYS_ADMIN))
> > + return -1;
> > put_net(nsproxy->net_ns);
> > nsproxy->net_ns = get_net(ns);
> > return 0;
^ permalink raw reply
* [PATCH] r8169 : MAC address change fix for the 8168e-vl.
From: Francois Romieu @ 2011-08-02 13:53 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Hayes Wang
Addresses https://bugzilla.kernel.org/show_bug.cgi?id=39252
Hayes suggested that the usual MAC{0, 4} register writes be completed
with writes to extended GigaMAC registers :
- 0xe0 .. 0xe5
- 0xf2 .. 0xf7
Registers 0xf0 and 0xf1 should be set to 0.
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Cc: Hayes Wang <hayeswang@realtek.com>
---
drivers/net/r8169.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/net/r8169.c b/drivers/net/r8169.c
index 7d9c650..851a488 100644
--- a/drivers/net/r8169.c
+++ b/drivers/net/r8169.c
@@ -1091,6 +1091,21 @@ rtl_w1w0_eri(void __iomem *ioaddr, int addr, u32 mask, u32 p, u32 m, int type)
rtl_eri_write(ioaddr, addr, mask, (val & ~m) | p, type);
}
+struct exgmac_reg {
+ u16 addr;
+ u16 mask;
+ u32 val;
+};
+
+static void rtl_write_exgmac_batch(void __iomem *ioaddr,
+ const struct exgmac_reg *r, int len)
+{
+ while (len-- > 0) {
+ rtl_eri_write(ioaddr, r->addr, r->mask, r->val, ERIAR_EXGMAC);
+ r++;
+ }
+}
+
static u8 rtl8168d_efuse_read(void __iomem *ioaddr, int reg_addr)
{
u8 value = 0xff;
@@ -3116,6 +3131,18 @@ static void rtl_rar_set(struct rtl8169_private *tp, u8 *addr)
RTL_W32(MAC0, low);
RTL_R32(MAC0);
+ if (tp->mac_version == RTL_GIGA_MAC_VER_34) {
+ const struct exgmac_reg e[] = {
+ { .addr = 0xe0, ERIAR_MASK_1111, .val = low },
+ { .addr = 0xe4, ERIAR_MASK_1111, .val = high },
+ { .addr = 0xf0, ERIAR_MASK_1111, .val = low << 16 },
+ { .addr = 0xf4, ERIAR_MASK_1111, .val = high << 16 |
+ low >> 16 },
+ };
+
+ rtl_write_exgmac_batch(ioaddr, e, ARRAY_SIZE(e));
+ }
+
RTL_W8(Cfg9346, Cfg9346_Lock);
spin_unlock_irq(&tp->lock);
--
1.7.6
^ permalink raw reply related
* [PATCH ] cdc_ncm: fixes for big-endian architecture / MIPS
From: Alexey Orishko @ 2011-08-02 16:20 UTC (permalink / raw)
To: netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
oliver-GvhC2dPhHPQdnm+yROfE0A
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, gregkh-l3A5Bk7waGM,
Alexey Orishko
Changes:
- removed redandunt conversion for usb control requests
- added missing conversion for nth16.wNdpIndex
Thanks to Giuseppe Scrivano for providing fixes
This patch shall be applied on top of today's Josh Boyle patch
[PATCH v3] usbnet/cdc_ncm: Don't use stack variables for DMA
Signed-off-by: Alexey Orishko <alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw@public.gmane.org>
---
drivers/net/usb/cdc_ncm.c | 33 ++++++++++++++++-----------------
1 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
index bbcb133..4b2a317 100644
--- a/drivers/net/usb/cdc_ncm.c
+++ b/drivers/net/usb/cdc_ncm.c
@@ -53,7 +53,7 @@
#include <linux/usb/usbnet.h>
#include <linux/usb/cdc.h>
-#define DRIVER_VERSION "01-June-2011"
+#define DRIVER_VERSION "02-Aug-2011"
/* CDC NCM subclass 3.2.1 */
#define USB_CDC_NCM_NDP16_LENGTH_MIN 0x10
@@ -203,8 +203,8 @@ static u8 cdc_ncm_setup(struct cdc_ncm_ctx *ctx)
req.bmRequestType = USB_TYPE_CLASS | USB_DIR_IN | USB_RECIP_INTERFACE;
req.bNotificationType = USB_CDC_GET_NTB_PARAMETERS;
req.wValue = 0;
- req.wIndex = cpu_to_le16(iface_no);
- req.wLength = cpu_to_le16(sizeof(ctx->ncm_parm));
+ req.wIndex = iface_no;
+ req.wLength = sizeof(ctx->ncm_parm);
err = cdc_ncm_do_request(ctx, &req, &ctx->ncm_parm, 0, NULL, 1000);
if (err) {
@@ -257,7 +257,7 @@ static u8 cdc_ncm_setup(struct cdc_ncm_ctx *ctx)
USB_RECIP_INTERFACE;
req.bNotificationType = USB_CDC_SET_NTB_INPUT_SIZE;
req.wValue = 0;
- req.wIndex = cpu_to_le16(iface_no);
+ req.wIndex = iface_no;
if (flags & USB_CDC_NCM_NCAP_NTB_INPUT_SIZE) {
struct usb_cdc_ncm_ndp_input_size *ndp_in_sz;
@@ -351,8 +351,8 @@ size_err:
req.bmRequestType = USB_TYPE_CLASS | USB_DIR_OUT |
USB_RECIP_INTERFACE;
req.bNotificationType = USB_CDC_SET_CRC_MODE;
- req.wValue = cpu_to_le16(USB_CDC_NCM_CRC_NOT_APPENDED);
- req.wIndex = cpu_to_le16(iface_no);
+ req.wValue = USB_CDC_NCM_CRC_NOT_APPENDED;
+ req.wIndex = iface_no;
req.wLength = 0;
err = cdc_ncm_do_request(ctx, &req, NULL, 0, NULL, 1000);
@@ -365,8 +365,8 @@ size_err:
req.bmRequestType = USB_TYPE_CLASS | USB_DIR_OUT |
USB_RECIP_INTERFACE;
req.bNotificationType = USB_CDC_SET_NTB_FORMAT;
- req.wValue = cpu_to_le16(USB_CDC_NCM_NTB16_FORMAT);
- req.wIndex = cpu_to_le16(iface_no);
+ req.wValue = USB_CDC_NCM_NTB16_FORMAT;
+ req.wIndex = iface_no;
req.wLength = 0;
err = cdc_ncm_do_request(ctx, &req, NULL, 0, NULL, 1000);
@@ -392,8 +392,8 @@ size_err:
USB_RECIP_INTERFACE;
req.bNotificationType = USB_CDC_GET_MAX_DATAGRAM_SIZE;
req.wValue = 0;
- req.wIndex = cpu_to_le16(iface_no);
- req.wLength = cpu_to_le16(2);
+ req.wIndex = iface_no;
+ req.wLength = 2;
err = cdc_ncm_do_request(ctx, &req, max_datagram_size, 0, NULL,
1000);
@@ -426,7 +426,7 @@ size_err:
USB_RECIP_INTERFACE;
req.bNotificationType = USB_CDC_SET_MAX_DATAGRAM_SIZE;
req.wValue = 0;
- req.wIndex = cpu_to_le16(iface_no);
+ req.wIndex = iface_no;
req.wLength = 2;
*max_datagram_size =
cpu_to_le16(ctx->max_datagram_size);
@@ -702,6 +702,7 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
u32 offset;
u32 last_offset;
u16 n = 0;
+ u16 ndpIndex = 0;
u8 ready2send = 0;
/* if there is a remaining skb, it gets priority */
@@ -889,8 +890,8 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
cpu_to_le16(sizeof(ctx->tx_ncm.nth16));
ctx->tx_ncm.nth16.wSequence = cpu_to_le16(ctx->tx_seq);
ctx->tx_ncm.nth16.wBlockLength = cpu_to_le16(last_offset);
- ctx->tx_ncm.nth16.wNdpIndex = ALIGN(sizeof(struct usb_cdc_ncm_nth16),
- ctx->tx_ndp_modulus);
+ ndpIndex = ALIGN(sizeof(struct usb_cdc_ncm_nth16), ctx->tx_ndp_modulus);
+ ctx->tx_ncm.nth16.wNdpIndex = cpu_to_le16(ndpIndex);
memcpy(skb_out->data, &(ctx->tx_ncm.nth16), sizeof(ctx->tx_ncm.nth16));
ctx->tx_seq++;
@@ -903,12 +904,10 @@ cdc_ncm_fill_tx_frame(struct cdc_ncm_ctx *ctx, struct sk_buff *skb)
ctx->tx_ncm.ndp16.wLength = cpu_to_le16(rem);
ctx->tx_ncm.ndp16.wNextNdpIndex = 0; /* reserved */
- memcpy(((u8 *)skb_out->data) + ctx->tx_ncm.nth16.wNdpIndex,
- &(ctx->tx_ncm.ndp16),
+ memcpy(((u8 *)skb_out->data) + ndpIndex, &(ctx->tx_ncm.ndp16),
sizeof(ctx->tx_ncm.ndp16));
- memcpy(((u8 *)skb_out->data) + ctx->tx_ncm.nth16.wNdpIndex +
- sizeof(ctx->tx_ncm.ndp16),
+ memcpy(((u8 *)skb_out->data) + ndpIndex + sizeof(ctx->tx_ncm.ndp16),
&(ctx->tx_ncm.dpe16),
(ctx->tx_curr_frame_num + 1) *
sizeof(struct usb_cdc_ncm_dpe16));
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* return of ip_rt_bug()
From: Dave Jones @ 2011-08-02 17:09 UTC (permalink / raw)
To: netdev; +Cc: Tom London
Tom (CC'd) has been hitting that ip_rt_bug() WARN_ON() since 3.0rc
Here's the latest report.
------------[ cut here]------------
WARNING: atnet/ipv4/route.c:1714 ip_rt_bug+0x5c/0x62()
Hardware name: 74585FU
Modules linked in: fuse
ip6table_filter ip6_tables ebtable_nat ebtables ppdev parport_pc lp parport
ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state
nf_conntrack xt_CHECKSUM iptable_mangle tun bridge stp llc sunrpc rfcomm bnep
usblp arc4 uvcvideo videodev media snd_usb_audio snd_usbmidi_lib snd_rawmidi
v4l2_compat_ioctl32 iwlagn microcode i2c_i801 btusb iTCO_wdt
iTCO_vendor_support mac80211 bluetooth snd_hda_codec_conexant cfg80211
thinkpad_acpi snd_hda_intel snd_hda_codec rfkill snd_hwdep snd_seq
snd_seq_device snd_pcm snd_timer snd soundcore snd_page_alloc e1000e virtio_net
kvm_intel kvm uinput wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video[last unloaded: scsi_wait_scan]
Pid: 5492, comm: xsane Not tainted 3.1.0-0.rc0.git12.1.fc17.x86_64 #1
Call Trace:
[<ffffffff8105c5ec>] warn_slowpath_common+0x83/0x9b
[<ffffffff8105c61e>] warn_slowpath_null+0x1a/0x1c
[<ffffffff8142f485>] ip_rt_bug+0x5c/0x62
[<ffffffff81437091>] dst_output+0x19/0x1d
[<ffffffff814387c0>] ip_local_out+0x20/0x25
[<ffffffff81439695>] ip_send_skb+0x19/0x3e
[<ffffffff81455ea2>] udp_send_skb+0x239/0x29b
[<ffffffff8145763f>] udp_sendmsg+0x5a1/0x7d4
[<ffffffff813f67d5>] ? release_sock+0x35/0x155
[<ffffffff8143718c>] ? ip_select_ident+0x3d/0x3d
[<ffffffff81062703>] ? local_bh_enable_ip+0xe/0x10
[<ffffffff814f1231>] ? _raw_spin_unlock_bh+0x40/0x44
[<ffffffff813f68ec>] ? release_sock+0x14c/0x155
[<ffffffff8145eb58>] inet_sendmsg+0x66/0x6f
[<ffffffff813f1d92>] sock_sendmsg+0xe6/0x109
[<ffffffff8108f1c8>] ? lock_acquire+0x10f/0x13e
[<ffffffff8110dd34>] ? might_fault+0x5c/0xac
[<ffffffff8108f08c>] ? lock_release+0x1a4/0x1d1
[<ffffffff8110dd7d>] ? might_fault+0xa5/0xac
[<ffffffff813f2ad7>] ? copy_from_user+0x2f/0x31
[<ffffffff813f496d>] sys_sendto+0x132/0x174
[<ffffffff8124ef6e>] ? trace_hardirqs_on_thunk+0x3a/0x3f
[<ffffffff814f80c2>] system_call_fastpath+0x16/0x1b
---[ end trace 0e82aef47f8d8552 ]---
------------[ cut here ]------------
all the traces he's hit so far seem to be caused by udp, and they all seem to be
going from 192.168.2.5 -> 255.255.255.255
https://bugzilla.redhat.com/show_bug.cgi?id=712632 is his full report with similar traces.
Dave
^ permalink raw reply
* RE: [PATCH 6/6] bna: Tx and Rx Redesign
From: Rasesh Mody @ 2011-08-02 18:05 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team
In-Reply-To: <20110801.180959.434819216427342007.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Monday, August 01, 2011 6:10 PM
>
>This just adds a lot of new code, but there are no users of this
>new code.
>
>Resubmit this when you have the actual users of the code ready.
We took this approach to avoid sending large amount of patches at once while keeping the patches bisectable.
We can resubmit the first 3 patches as enhancements and submit new code in a separate patch set with actual user of the code, but the patch count may be little high for this new code enablement, is this ok?
Thanks,
Rasesh
^ 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