* Re: fanotify as syscalls
From: Jamie Lokier @ 2009-09-21 23:12 UTC (permalink / raw)
To: Davide Libenzi
Cc: Andreas Gruenbacher, Eric Paris, Linus Torvalds, Evgeniy Polyakov,
David Miller, Linux Kernel Mailing List, linux-fsdevel, netdev,
viro, alan, hch
In-Reply-To: <alpine.DEB.2.00.0909211456180.1116@makko.or.mcafeemobile.com>
Davide Libenzi wrote:
> On Mon, 21 Sep 2009, Jamie Lokier wrote:
>
> > I think so to, and that'd be a great all round solution.
>
> If this is for anti-malware vendors
Personally I'm not interested in anti-malware, and am simply
interested in leveraging fsnotify improvements to accelerate userspace
caches of information which depends on files (indexes, templates,
compiler caches, stat caches etc.). Basically make inotify better,
and sufficiently correct for that purpose.
My sticking my oar in lately is to ensure the fsnotify improvements
are going in the (imho) right direction. There's a lot of interesting
apps waiting in the wings on this. It doesn't have to be complicated,
just... sensible.
> to intercept userspace accesses
> they're currently doing it by hacking the syscall table, why don't we
> offer a way to monitor syscalls (kernel side) in a non racy way?
> Modules can [un]register themselves for syscall intercaption, and receive
> the syscall number and parameters. They'd be able to change paramters,
> return error codes, and so on.
> The cost of the check in the syscall path could even be under an
> alternative-like patching, if really neeeded.
> The Pros of this would be:
>
> - The kernel code to implement this would be trivially small, with no
> I-need-this-feature-too growth potential
(Fwiw, the {fa,fs,i}notify thing looks to me like it's getting simpler
as we go. Good design = decrease complexity + increase versatility.
E.g. see epoll.)
> - There won't be any externally visible API to maintain (and its kernel
> counter part) and expand
>
> - Any system call can be intercepted, allowing it to be flexible while
> leaving the burden of the interception handling, and communication with
> userspace policy enforcers, to the anti-malware (or whoever really)
> companies modules
>
> The anti-malware are already doing this (intercepting syscall), they
> already have code for it, and they always did (writing kernel
> modules/drivers, that is) for Windows.
I don't mind at all if fanotify is replaced by a general purpose "take
over the system call table" solution for anti-malware, and I still get
to keep the fsnotify improvements :-)
But I can't help noticing that we _already_ have quite well placed
hooks for intercepting system calls, called security_this and
security_that (SELinux etc), albeit they can't redirect things so much.
However, being a little kinder, I suspect even the anti-malware
vendors would rather not slow down everything with race-prone
complicated tracking of everything every process does... which is why
fanotify allows it's "interest set" to be reduced from everything to a
subset of files, and it's results to be cached, and let the races be
handled in the normal way by VFS.
Once you have an "interest set" and focus on files, it looks somewhat
reasonable to use the fsnotify hooks.
...That is, if you believe monitoring files is the best approach to
anti-malware. I can't help noticing that on (ahem) Windows, running
just a "virus checker" which generically scans every file independent
of it's location looking for signatures and keeping up with patches is
no longer considered good enough.
-- Jamie
^ permalink raw reply
* Re: fanotify as syscalls
From: Andreas Gruenbacher @ 2009-09-21 23:09 UTC (permalink / raw)
To: Jamie Lokier
Cc: Eric Paris, Linus Torvalds, Evgeniy Polyakov, David Miller,
linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <20090921220002.GE14700@shareable.org>
On Tuesday, 22 September 2009 0:00:02 Jamie Lokier wrote:
> Andreas Gruenbacher wrote:
> > On Monday, 21 September 2009 22:28:23 Jamie Lokier wrote:
> > > It would be logical if fanotify could block and ack those [mount &
> > > umount events] in the same way as it can block and ack other accesses
> > > (with the usual filtering rules on which inodes trigger events, and
> > > which don't or are cached).
> >
> > Hmm. To me, fanotify is about file contents first of all: this is what
> > fanotify wants to be able to veto.
>
> Surely you don't assume that what constitutes malicious content is
> independent of it's location and/or name?
If the antimalware vendors want to base their decisions on pathnames then
that's their decision, and they can check /proc/self/fd/N. We should be able
to treat directory events the same.
> (See also "echo 'run_virus&' >>.bash_login).
>
> Wait a minute. You don't assume that, otherwise why the interest in
> subtrees? :-)
>
> > Directory events seem reasonable to add for inotify compatibility,
>
> Did you see may point about userspace caches and how directory events
> are fundamental to that - there's no way to build a cache without them?
Yes, there were some doubts about this appoach. Waiting for your code to
demonstrate; an object based cache (e.g., st_dev + st_ino) rather than a
pathname based cache would seem more reasonable.
> > but I see no need for access decisions on them.
>
> Please excuse me; I'm a bit confused. Is fanotify intended just for
> use by access decision programs, or is the plan now for it to also be
> a replacement for inotify? I'm getting conflicting signals about
> that.
Inotify doesn't support access decisions. So where's the problem with
having "notify only" events for directory / mount / unmount events?
> If it's just for access decision programs, and if those aren't going
> to care about location, then there's no need to add directory events
> to fanotify at all. But then I'll be demanding subtree support in
> inotify, please :-)
>
> > Even less so for mounts and unmounts.
>
> (as root) mkdir foo; mount dodgy foo -oloop; mount --bind foo/cat
> /bin/cat
... and then someone accesses /bin/cat, which triggers a fanotify access
decision.
Thanks,
Andreas
^ permalink raw reply
* [PATCH 2/2] ibm_newemac: MAL Coalescing in Canyonlands/Kilauea/Glacier dts
From: Prodyut Hazarika @ 2009-09-21 22:47 UTC (permalink / raw)
To: netdev
Cc: Victor Gallardo, Feng Kan, lada.podivin, Loc Ho, Prodyut Hazarika,
bhutchings, linuxppc-dev, davem
Support for MAL interrupt coalescing in Canyonlands, Kilauea & Glacier
dts.
MAL driver falls back to EOB IRQ if Coalescing IRQ mapping missing in dts
Signed-off-by: Prodyut Hazarika <phazarika@amcc.com>
Acked-by: Victor Gallardo <vgallardo@amcc.com>
Acked-by: Feng Kan <fkan@amcc.com>
---
arch/powerpc/boot/dts/canyonlands.dts | 6 +++++-
arch/powerpc/boot/dts/glacier.dts | 10 +++++++++-
arch/powerpc/boot/dts/kilauea.dts | 8 ++++++--
3 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/boot/dts/canyonlands.dts
b/arch/powerpc/boot/dts/canyonlands.dts
index c920170..5803a5b 100644
--- a/arch/powerpc/boot/dts/canyonlands.dts
+++ b/arch/powerpc/boot/dts/canyonlands.dts
@@ -146,7 +146,11 @@
/*RXEOB*/ 0x7 0x4
/*SERR*/ 0x3 0x4
/*TXDE*/ 0x4 0x4
- /*RXDE*/ 0x5 0x4>;
+ /*RXDE*/ 0x5 0x4
+ /*TX0 COAL*/ 0x8 0x2
+ /*TX1 COAL*/ 0x9 0x2
+ /*RX0 COAL*/ 0xc 0x2
+ /*RX1 COAL*/ 0xd 0x2 >;
};
USB0: ehci@bffd0400 {
diff --git a/arch/powerpc/boot/dts/glacier.dts
b/arch/powerpc/boot/dts/glacier.dts
index f3787a2..9af473f 100644
--- a/arch/powerpc/boot/dts/glacier.dts
+++ b/arch/powerpc/boot/dts/glacier.dts
@@ -130,7 +130,15 @@
/*RXEOB*/ 0x7 0x4
/*SERR*/ 0x3 0x4
/*TXDE*/ 0x4 0x4
- /*RXDE*/ 0x5 0x4>;
+ /*RXDE*/ 0x5 0x4
+ /*TX0 COAL*/ 0x8 0x2
+ /*TX1 COAL*/ 0x9 0x2
+ /*TX2 COAL*/ 0xa 0x2
+ /*TX3 COAL*/ 0xb 0x2
+ /*RX0 COAL*/ 0xc 0x2
+ /*RX1 COAL*/ 0xd 0x2
+ /*RX2 COAL*/ 0xe 0x2
+ /*RX3 COAL*/ 0xf 0x2 >;
desc-base-addr-high = <0x8>;
};
diff --git a/arch/powerpc/boot/dts/kilauea.dts
b/arch/powerpc/boot/dts/kilauea.dts
index c465614..14057a2 100644
--- a/arch/powerpc/boot/dts/kilauea.dts
+++ b/arch/powerpc/boot/dts/kilauea.dts
@@ -110,7 +110,7 @@
num-tx-chans = <2>;
num-rx-chans = <2>;
interrupt-parent = <&MAL0>;
- interrupts = <0x0 0x1 0x2 0x3 0x4>;
+ interrupts = <0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7 0x8>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
@@ -118,7 +118,11 @@
/*RXEOB*/ 0x1 &UIC0 0xb 0x4
/*SERR*/ 0x2 &UIC1 0x0 0x4
/*TXDE*/ 0x3 &UIC1 0x1 0x4
- /*RXDE*/ 0x4 &UIC1 0x2 0x4>;
+ /*RXDE*/ 0x4 &UIC1 0x2 0x4
+ /*TX0 COAL*/ 0x5 &UIC2 0x7 0x2
+ /*TX1 COAL*/ 0x6 &UIC2 0x8 0x2
+ /*RX0 COAL*/ 0x7 &UIC2 0x9 0x2
+ /*RX1 COAL*/ 0x8 &UIC2 0xa 0x2 >;
interrupt-map-mask = <0xffffffff>;
};
--
1.5.6
--------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its
subsidiaries. It is to be used solely for the purpose of furthering the
parties' business relationship. All unauthorized review, use, disclosure
or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the
original message.
^ permalink raw reply related
* [PATCH 1/2] ibm_newemac: Add Support for MAL Interrupt Coalescing
From: Prodyut Hazarika @ 2009-09-21 22:47 UTC (permalink / raw)
To: netdev
Cc: Victor Gallardo, Feng Kan, lada.podivin, Loc Ho, Prodyut Hazarika,
bhutchings, linuxppc-dev, davem
Support for Hardware Interrupt coalescing in MAL.
Coalescing is supported on the newer revs of 460EX/GT and 405EX.
The MAL driver falls back to EOB IRQ if coalescing not supported
Signed-off-by: Prodyut Hazarika <phazarika@amcc.com>
Acked-by: Victor Gallardo <vgallardo@amcc.com>
Acked-by: Feng Kan <fkan@amcc.com>
---
drivers/net/ibm_newemac/Kconfig | 27 ++++
drivers/net/ibm_newemac/mal.c | 295
+++++++++++++++++++++++++++++++++++----
drivers/net/ibm_newemac/mal.h | 55 +++++++
3 files changed, 350 insertions(+), 27 deletions(-)
diff --git a/drivers/net/ibm_newemac/Kconfig
b/drivers/net/ibm_newemac/Kconfig
index 78a1628..8a88173 100644
--- a/drivers/net/ibm_newemac/Kconfig
+++ b/drivers/net/ibm_newemac/Kconfig
@@ -63,6 +63,33 @@ config IBM_NEW_EMAC_EMAC4
bool
default n
+config IBM_NEW_EMAC_INTR_COALESCE
+ bool "Hardware Interrupt coalescing"
+ depends on IBM_NEW_EMAC && (460EX || 460GT || 405EX)
+ default y
+ help
+ When selected the Ethernet interrupt coalescing is selected.
+
+config IBM_NEW_EMAC_TX_COAL_COUNT
+ int "TX Coalescence frame count (packets)"
+ depends on IBM_NEW_EMAC_INTR_COALESCE
+ default "16"
+
+config IBM_NEW_EMAC_TX_COAL_TIMER
+ int "TX Coalescence timer (clock ticks)"
+ depends on IBM_NEW_EMAC_INTR_COALESCE
+ default "1000000"
+
+config IBM_NEW_EMAC_RX_COAL_COUNT
+ int "RX Coalescence frame count (packets)"
+ depends on IBM_NEW_EMAC_INTR_COALESCE
+ default "1"
+
+config IBM_NEW_EMAC_RX_COAL_TIMER
+ int "RX Coalescence timer (clock ticks)"
+ depends on IBM_NEW_EMAC_INTR_COALESCE
+ default "1000000"
+
config IBM_NEW_EMAC_NO_FLOW_CTRL
bool
default n
diff --git a/drivers/net/ibm_newemac/mal.c b/drivers/net/ibm_newemac/mal.c
index 2a2fc17..7dc06ad 100644
--- a/drivers/net/ibm_newemac/mal.c
+++ b/drivers/net/ibm_newemac/mal.c
@@ -31,6 +31,20 @@
#include <asm/dcr-regs.h>
static int mal_count;
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+static char *tx_coal_irqname[] = {
+ "TX0 COAL",
+ "TX1 COAL",
+ "TX2 COAL",
+ "TX3 COAL",
+};
+static char *rx_coal_irqname[] = {
+ "RX0 COAL",
+ "RX1 COAL",
+ "RX2 COAL",
+ "RX3 COAL",
+};
+#endif
int __devinit mal_register_commac(struct mal_instance *mal,
struct mal_commac *commac)
@@ -217,6 +231,86 @@ static inline void mal_disable_eob_irq(struct
mal_instance *mal)
MAL_DBG2(mal, "disable_irq" NL);
}
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+static inline void mal_enable_coal(struct mal_instance *mal)
+{
+ unsigned int val;
+#if defined(CONFIG_405EX)
+ /* Clear the counters */
+ val = SDR0_ICC_FLUSH0 | SDR0_ICC_FLUSH1;
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX, val);
+
+ /* Set Tx/Rx Timer values */
+ mtdcri(SDR0, DCRN_SDR0_ICCTRTX0, CONFIG_IBM_NEW_EMAC_TX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRTX1, CONFIG_IBM_NEW_EMAC_TX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRRX0, CONFIG_IBM_NEW_EMAC_RX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRRX1, CONFIG_IBM_NEW_EMAC_RX_COAL_TIMER);
+
+ /* Enable the Tx/Rx Coalescing interrupt */
+ val = ((CONFIG_IBM_NEW_EMAC_TX_COAL_COUNT & COAL_FRAME_MASK)
+ << SDR0_ICC_FTHR0_SHIFT) |
+ ((CONFIG_IBM_NEW_EMAC_TX_COAL_COUNT & COAL_FRAME_MASK)
+ << SDR0_ICC_FTHR1_SHIFT);
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX, val);
+
+ val = ((CONFIG_IBM_NEW_EMAC_RX_COAL_COUNT & COAL_FRAME_MASK)
+ << SDR0_ICC_FTHR0_SHIFT) |
+ ((CONFIG_IBM_NEW_EMAC_RX_COAL_COUNT & COAL_FRAME_MASK)
+ << SDR0_ICC_FTHR1_SHIFT);
+
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX, val);
+#elif defined(CONFIG_460EX) || defined(CONFIG_460GT)
+ /* Clear the counters */
+ val = SDR0_ICC_FLUSH;
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX0, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX1, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX0, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX1, val);
+#if defined(CONFIG_460GT)
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX2, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX3, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX2, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX3, val);
+#endif
+
+ /* Set Tx/Rx Timer values */
+ mtdcri(SDR0, DCRN_SDR0_ICCTRTX0, CONFIG_IBM_NEW_EMAC_TX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRTX1, CONFIG_IBM_NEW_EMAC_TX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRRX0, CONFIG_IBM_NEW_EMAC_RX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRRX1, CONFIG_IBM_NEW_EMAC_RX_COAL_TIMER);
+#if defined(CONFIG_460GT)
+ mtdcri(SDR0, DCRN_SDR0_ICCTRTX2, CONFIG_IBM_NEW_EMAC_TX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRTX3, CONFIG_IBM_NEW_EMAC_TX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRRX2, CONFIG_IBM_NEW_EMAC_RX_COAL_TIMER);
+ mtdcri(SDR0, DCRN_SDR0_ICCTRRX3, CONFIG_IBM_NEW_EMAC_RX_COAL_TIMER);
+#endif
+
+ /* Enable the Tx/Rx Coalescing interrupt */
+ val = (CONFIG_IBM_NEW_EMAC_TX_COAL_COUNT & COAL_FRAME_MASK)
+ << SDR0_ICC_FTHR_SHIFT;
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX0, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX1, val);
+#if defined(CONFIG_460GT)
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX2, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRTX3, val);
+#endif
+
+ val = (CONFIG_IBM_NEW_EMAC_RX_COAL_COUNT & COAL_FRAME_MASK)
+ << SDR0_ICC_FTHR_SHIFT;
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX0, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX1, val);
+#if defined(CONFIG_460GT)
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX2, val);
+ mtdcri(SDR0, DCRN_SDR0_ICCRRX3, val);
+#endif
+#endif
+ printk(KERN_INFO "MAL: Enabled Intr Coal TxCnt: %d RxCnt: %d\n",
+ CONFIG_IBM_NEW_EMAC_TX_COAL_COUNT,
+ CONFIG_IBM_NEW_EMAC_RX_COAL_COUNT);
+}
+#endif
+
static irqreturn_t mal_serr(int irq, void *dev_instance)
{
struct mal_instance *mal = dev_instance;
@@ -309,6 +403,15 @@ static irqreturn_t mal_rxeob(int irq, void
*dev_instance)
return IRQ_HANDLED;
}
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+static irqreturn_t mal_coal(int irq, void *dev_instance)
+{
+ struct mal_instance *mal = dev_instance;
+ mal_schedule_poll(mal);
+ return IRQ_HANDLED;
+}
+#endif
+
static irqreturn_t mal_txde(int irq, void *dev_instance)
{
struct mal_instance *mal = dev_instance;
@@ -527,6 +630,10 @@ static int __devinit mal_probe(struct of_device
*ofdev,
u32 cfg;
unsigned long irqflags;
irq_handler_t hdlr_serr, hdlr_txde, hdlr_rxde;
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ int num_phys_chans;
+ int coal_intr_index;
+#endif
mal = kzalloc(sizeof(struct mal_instance), GFP_KERNEL);
if (!mal) {
@@ -609,6 +716,50 @@ static int __devinit mal_probe(struct of_device
*ofdev,
goto fail_unmap;
}
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ /* Number of Tx channels is equal to Physical channels */
+ /* Rx channels include Virtual channels so use Tx channels */
+ BUG_ON(mal->num_tx_chans > MAL_MAX_PHYS_CHANNELS);
+ num_phys_chans = mal->num_tx_chans;
+ /* Older revs in 460EX and 460GT have coalesce bug in h/w */
+#if defined(CONFIG_460EX) || defined(CONFIG_460GT)
+ {
+ unsigned int pvr;
+ unsigned short min;
+ pvr = mfspr(SPRN_PVR);
+ min = PVR_MIN(pvr);
+ if (min < 4) {
+ printk(KERN_INFO "PVR %x Intr Coal disabled: H/W bug\n",
+ pvr);
+ mal->coalesce_disabled = 1;
+ }
+ }
+#else
+ mal->coalesce_disabled = 0;
+#endif
+ coal_intr_index = 5;
+
+ /* If device tree doesn't Interrupt coal IRQ, fall back to EOB IRQ */
+ for (i = 0; (i < num_phys_chans) && !mal->coalesce_disabled; i++) {
+ mal->txcoal_irq[i] =
+ irq_of_parse_and_map(ofdev->node, coal_intr_index++);
+ if (mal->txcoal_irq[i] == NO_IRQ) {
+ printk(KERN_INFO "MAL: No device tree IRQ "
+ "for TxCoal%d - disabling coalescing\n", i);
+ mal->coalesce_disabled = 1;
+ }
+ }
+ for (i = 0; (i < num_phys_chans) && !mal->coalesce_disabled ; i++) {
+ mal->rxcoal_irq[i] =
+ irq_of_parse_and_map(ofdev->node, coal_intr_index++);
+ if (mal->rxcoal_irq[i] == NO_IRQ) {
+ printk(KERN_INFO "MAL: No device tree IRQ "
+ "for RxCoal%d - disabling coalescing\n", i);
+ mal->coalesce_disabled = 1;
+ }
+ }
+#endif
+
INIT_LIST_HEAD(&mal->poll_list);
INIT_LIST_HEAD(&mal->list);
spin_lock_init(&mal->lock);
@@ -674,20 +825,69 @@ static int __devinit mal_probe(struct of_device
*ofdev,
}
err = request_irq(mal->serr_irq, hdlr_serr, irqflags, "MAL SERR", mal);
- if (err)
- goto fail2;
+ if (err) {
+ mal->serr_irq = NO_IRQ;
+ goto failirq;
+ }
err = request_irq(mal->txde_irq, hdlr_txde, irqflags, "MAL TX DE", mal);
- if (err)
- goto fail3;
- err = request_irq(mal->txeob_irq, mal_txeob, 0, "MAL TX EOB", mal);
- if (err)
- goto fail4;
+ if (err) {
+ mal->txde_irq = NO_IRQ;
+ goto failirq;
+ }
err = request_irq(mal->rxde_irq, hdlr_rxde, irqflags, "MAL RX DE", mal);
- if (err)
- goto fail5;
- err = request_irq(mal->rxeob_irq, mal_rxeob, 0, "MAL RX EOB", mal);
- if (err)
- goto fail6;
+ if (err) {
+ mal->rxde_irq = NO_IRQ;
+ goto failirq;
+ }
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ for (i = 0; (i < num_phys_chans) && !mal->coalesce_disabled; i++) {
+ err = request_irq(mal->txcoal_irq[i],
+ mal_coal, 0, tx_coal_irqname[i], mal);
+ if (err) {
+ printk(KERN_INFO "MAL: TxCoal%d ReqIRQ failed "
+ " - disabling coalescing\n", i);
+ mal->txcoal_irq[i] = NO_IRQ;
+ mal->coalesce_disabled = 1;
+ break;
+ }
+ }
+ for (i = 0; (i < num_phys_chans) && !mal->coalesce_disabled; i++) {
+ err = request_irq(mal->rxcoal_irq[i],
+ mal_coal, 0, rx_coal_irqname[i], mal);
+ if (err) {
+ printk(KERN_INFO "MAL: RxCoal%d ReqIRQ failed - "
+ "disabling coalescing\n", i);
+ mal->rxcoal_irq[i] = NO_IRQ;
+ mal->coalesce_disabled = 1;
+ break;
+ }
+ }
+
+ /* Fall back to EOB IRQ if coalesce not supported */
+ if (mal->coalesce_disabled) {
+ /* Clean up any IRQs allocated for Coalescing */
+ for (i = 0; i < num_phys_chans; i++) {
+ if (mal->txcoal_irq[i] != NO_IRQ)
+ free_irq(mal->txcoal_irq[i], mal);
+ if (mal->rxcoal_irq[i] != NO_IRQ)
+ free_irq(mal->rxcoal_irq[i], mal);
+ }
+#endif
+ err = request_irq(mal->txeob_irq, mal_txeob, 0,
+ "MAL TX EOB", mal);
+ if (err) {
+ mal->txeob_irq = NO_IRQ;
+ goto failirq;
+ }
+ err = request_irq(mal->rxeob_irq, mal_rxeob, 0,
+ "MAL RX EOB", mal);
+ if (err) {
+ mal->rxeob_irq = NO_IRQ;
+ goto failirq;
+ }
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ }
+#endif
/* Enable all MAL SERR interrupt sources */
if (mal->version == 2)
@@ -695,6 +895,10 @@ static int __devinit mal_probe(struct of_device
*ofdev,
else
set_mal_dcrn(mal, MAL_IER, MAL1_IER_EVENTS);
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ if (mal->coalesce_disabled == 0)
+ mal_enable_coal(mal);
+#endif
/* Enable EOB interrupt */
mal_enable_eob_irq(mal);
@@ -711,15 +915,30 @@ static int __devinit mal_probe(struct of_device
*ofdev,
return 0;
- fail6:
- free_irq(mal->rxde_irq, mal);
- fail5:
- free_irq(mal->txeob_irq, mal);
- fail4:
- free_irq(mal->txde_irq, mal);
- fail3:
- free_irq(mal->serr_irq, mal);
- fail2:
+ failirq:
+ if (mal->serr_irq != NO_IRQ)
+ free_irq(mal->serr_irq, mal);
+ if (mal->txde_irq != NO_IRQ)
+ free_irq(mal->txde_irq, mal);
+ if (mal->rxde_irq != NO_IRQ)
+ free_irq(mal->rxde_irq, mal);
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ if (mal->coalesce_disabled == 0) {
+ for (i = 0; i < num_phys_chans; i++) {
+ if (mal->txcoal_irq[i] != NO_IRQ)
+ free_irq(mal->txcoal_irq[i], mal);
+ if (mal->rxcoal_irq[i] != NO_IRQ)
+ free_irq(mal->rxcoal_irq[i], mal);
+ }
+ } else {
+#endif
+ if (mal->txeob_irq != NO_IRQ)
+ free_irq(mal->txeob_irq, mal);
+ if (mal->rxeob_irq != NO_IRQ)
+ free_irq(mal->rxeob_irq, mal);
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ }
+#endif
dma_free_coherent(&ofdev->dev, bd_size, mal->bd_virt, mal->bd_dma);
fail_unmap:
dcr_unmap(mal->dcr_host, 0x100);
@@ -732,6 +951,10 @@ static int __devinit mal_probe(struct of_device
*ofdev,
static int __devexit mal_remove(struct of_device *ofdev)
{
struct mal_instance *mal = dev_get_drvdata(&ofdev->dev);
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ int i;
+ int num_phys_chans;
+#endif
MAL_DBG(mal, "remove" NL);
@@ -748,12 +971,30 @@ static int __devexit mal_remove(struct of_device
*ofdev)
dev_set_drvdata(&ofdev->dev, NULL);
- free_irq(mal->serr_irq, mal);
- free_irq(mal->txde_irq, mal);
- free_irq(mal->txeob_irq, mal);
- free_irq(mal->rxde_irq, mal);
- free_irq(mal->rxeob_irq, mal);
-
+ if (mal->serr_irq != NO_IRQ)
+ free_irq(mal->serr_irq, mal);
+ if (mal->txde_irq != NO_IRQ)
+ free_irq(mal->txde_irq, mal);
+ if (mal->rxde_irq != NO_IRQ)
+ free_irq(mal->rxde_irq, mal);
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ num_phys_chans = mal->num_tx_chans;
+ if (mal->coalesce_disabled == 0) {
+ for (i = 0; i < num_phys_chans; i++) {
+ if (mal->txcoal_irq[i] != NO_IRQ)
+ free_irq(mal->txcoal_irq[i], mal);
+ if (mal->rxcoal_irq[i] != NO_IRQ)
+ free_irq(mal->rxcoal_irq[i], mal);
+ }
+ } else {
+#endif
+ if (mal->txeob_irq != NO_IRQ)
+ free_irq(mal->txeob_irq, mal);
+ if (mal->rxeob_irq != NO_IRQ)
+ free_irq(mal->rxeob_irq, mal);
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ }
+#endif
mal_reset(mal);
mal_dbg_unregister(mal);
diff --git a/drivers/net/ibm_newemac/mal.h b/drivers/net/ibm_newemac/mal.h
index 9ededfb..a93c352 100644
--- a/drivers/net/ibm_newemac/mal.h
+++ b/drivers/net/ibm_newemac/mal.h
@@ -169,6 +169,56 @@ struct mal_descriptor {
#define MAL_TX_CTRL_LAST 0x1000
#define MAL_TX_CTRL_INTR 0x0400
+#if defined(CONFIG_405EX)
+#define DCRN_SDR0_ICCRTX 0x430B /* Int coal Tx control register */
+#define DCRN_SDR0_ICCRRX 0x430C /* Int coal Rx control register */
+#define SDR0_ICC_FTHR0_SHIFT 23
+#define SDR0_ICC_FLUSH0 22
+#define SDR0_ICC_FLUWI0 21
+#define SDR0_ICC_FTHR1_SHIFT 12
+#define SDR0_ICC_FLUSH1 11
+#define SDR0_ICC_FLUWI1 10
+#define DCRN_SDR0_ICCTRTX0 0x430D /* Int coal Tx0 count threshold */
+#define DCRN_SDR0_ICCTRTX1 0x430E /* Int coal Tx1 count threshold */
+#define DCRN_SDR0_ICCTRRX0 0x430F /* Int coal Rx0 count threshold */
+#define DCRN_SDR0_ICCTRRX1 0x4310 /* Int coal Rx1 count threshold */
+#define DCRN_SDR0_ICTSRTX0 0x4307 /* Int coal Tx0 timer status*/
+#define DCRN_SDR0_ICTSRTX1 0x4308 /* Int coal Tx1 timer status*/
+#define DCRN_SDR0_ICTSRRX0 0x4309 /* Int coal Rx0 timer status*/
+#define DCRN_SDR0_ICTSRRX1 0x430A /* Int coal Rx1 timer status*/
+#elif defined(CONFIG_460EX) || defined(CONFIG_460GT)
+#define DCRN_SDR0_ICCRTX0 0x4410 /* Int coal Tx0 control register */
+#define DCRN_SDR0_ICCRTX1 0x4411 /* Int coal Tx1 control register */
+#define DCRN_SDR0_ICCRTX2 0x4412 /* Int coal Tx2 control register */
+#define DCRN_SDR0_ICCRTX3 0x4413 /* Int coal Tx3 control register */
+#define DCRN_SDR0_ICCRRX0 0x4414 /* Int coal Rx0 control register */
+#define DCRN_SDR0_ICCRRX1 0x4415 /* Int coal Rx1 control register */
+#define DCRN_SDR0_ICCRRX2 0x4416 /* Int coal Rx2 control register */
+#define DCRN_SDR0_ICCRRX3 0x4417 /* Int coal Rx3 control register */
+#define SDR0_ICC_FTHR_SHIFT 23
+#define SDR0_ICC_FLUSH 22
+#define SDR0_ICC_FLUWI 21
+#define DCRN_SDR0_ICCTRTX0 0x4418 /* Int coal Tx0 count threshold */
+#define DCRN_SDR0_ICCTRTX1 0x4419 /* Int coal Tx1 count threshold */
+#define DCRN_SDR0_ICCTRTX2 0x441A /* Int coal Tx2 count threshold */
+#define DCRN_SDR0_ICCTRTX3 0x441B /* Int coal Tx3 count threshold */
+#define DCRN_SDR0_ICCTRRX0 0x441C /* Int coal Rx0 count threshold */
+#define DCRN_SDR0_ICCTRRX1 0x441D /* Int coal Rx1 count threshold */
+#define DCRN_SDR0_ICCTRRX2 0x441E /* Int coal Rx2 count threshold */
+#define DCRN_SDR0_ICCTRRX3 0x441F /* Int coal Rx3 count threshold */
+#define DCRN_SDR0_ICTSRTX0 0x4420 /* Int coal Tx0 timer status*/
+#define DCRN_SDR0_ICTSRTX1 0x4421 /* Int coal Tx1 timer status*/
+#define DCRN_SDR0_ICTSRTX2 0x4422 /* Int coal Tx2 timer status*/
+#define DCRN_SDR0_ICTSRTX3 0x4423 /* Int coal Tx3 timer status*/
+#define DCRN_SDR0_ICTSRRX0 0x4424 /* Int coal Rx0 timer status*/
+#define DCRN_SDR0_ICTSRRX1 0x4425 /* Int coal Rx1 timer status*/
+#define DCRN_SDR0_ICTSRRX2 0x4426 /* Int coal Rx2 timer status*/
+#define DCRN_SDR0_ICTSRRX3 0x4427 /* Int coal Rx3 timer status*/
+#endif
+
+#define COAL_FRAME_MASK 0x1FF
+#define MAL_MAX_PHYS_CHANNELS 4
+
struct mal_commac_ops {
void (*poll_tx) (void *dev);
int (*poll_rx) (void *dev, int budget);
@@ -217,6 +267,11 @@ struct mal_instance {
struct net_device dummy_dev;
unsigned int features;
+#ifdef CONFIG_IBM_NEW_EMAC_INTR_COALESCE
+ int txcoal_irq[MAL_MAX_PHYS_CHANNELS];
+ int rxcoal_irq[MAL_MAX_PHYS_CHANNELS];
+ int coalesce_disabled;
+#endif
};
static inline u32 get_mal_dcrn(struct mal_instance *mal, int reg)
--
1.5.6
--------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is
for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its
subsidiaries. It is to be used solely for the purpose of furthering the
parties' business relationship. All unauthorized review, use, disclosure
or distribution is prohibited. If you are not the intended recipient,
please contact the sender by reply e-mail and destroy all copies of the
original message.
^ permalink raw reply related
* Re: fanotify as syscalls
From: Davide Libenzi @ 2009-09-21 22:18 UTC (permalink / raw)
To: Jamie Lokier
Cc: Andreas Gruenbacher, Eric Paris, Linus Torvalds, Evgeniy Polyakov,
David Miller, Linux Kernel Mailing List, linux-fsdevel, netdev,
viro, alan, hch
In-Reply-To: <20090921202823.GB14700@shareable.org>
On Mon, 21 Sep 2009, Jamie Lokier wrote:
> I think so to, and that'd be a great all round solution.
If this is for anti-malware vendors to intercept userspace accesses
they're currently doing it by hacking the syscall table, why don't we
offer a way to monitor syscalls (kernel side) in a non racy way?
Modules can [un]register themselves for syscall intercaption, and receive
the syscall number and parameters. They'd be able to change paramters,
return error codes, and so on.
The cost of the check in the syscall path could even be under an
alternative-like patching, if really neeeded.
The Pros of this would be:
- The kernel code to implement this would be trivially small, with no
I-need-this-feature-too growth potential
- There won't be any externally visible API to maintain (and its kernel
counter part) and expand
- Any system call can be intercepted, allowing it to be flexible while
leaving the burden of the interception handling, and communication with
userspace policy enforcers, to the anti-malware (or whoever really)
companies modules
The anti-malware are already doing this (intercepting syscall), they
already have code for it, and they always did (writing kernel
modules/drivers, that is) for Windows.
- Davide
^ permalink raw reply
* Re: fanotify as syscalls
From: Jamie Lokier @ 2009-09-21 22:00 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: Eric Paris, Linus Torvalds, Evgeniy Polyakov, David Miller,
linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <200909212327.20978.agruen@suse.de>
Andreas Gruenbacher wrote:
> On Monday, 21 September 2009 22:28:23 Jamie Lokier wrote:
> > It would be logical if fanotify could block and ack those [mount & umount
> > events] in the same way as it can block and ack other accesses (with the
> > usual filtering rules on which inodes trigger events, and which don't or are
> > cached).
>
> Hmm. To me, fanotify is about file contents first of all: this is what
> fanotify wants to be able to veto.
Surely you don't assume that what constitutes malicious content is
independent of it's location and/or name?
(See also "echo 'run_virus&' >>.bash_login).
Wait a minute. You don't assume that, otherwise why the interest in
subtrees? :-)
> Directory events seem reasonable to add for inotify compatibility,
Did you see may point about userspace caches and how directory events
are fundamental to that - there's no way to build a cache without them?
> but I see no need for access decisions on them.
Please excuse me; I'm a bit confused. Is fanotify intended just for
use by access decision programs, or is the plan now for it to also be
a replacement for inotify? I'm getting conflicting signals about
that.
If it's just for access decision programs, and if those aren't going
to care about location, then there's no need to add directory events
to fanotify at all. But then I'll be demanding subtree support in
inotify, please :-)
> Even less so for mounts and unmounts.
(as root) mkdir foo; mount dodgy foo -oloop; mount --bind foo/cat /bin/cat
If fanotify doesn't react to that, which is just a fancy way of saying
"zcat virus.gz >/bin/cat" in a way which doesn't cause any writes or
opens, what's the point in it? Is fanotify only for checking files
written by non-root users?
> (Besides, we can't hold any vfs locks
> while asking fanotify so those operations wouldn't be atomic, anyway.)
Indeed, good point.
-- Jamie
^ permalink raw reply
* Re: [PATCH 3/3] at91_can: add driver for Atmel's CAN controller on AT91SAM9263
From: Andrew Victor @ 2009-09-21 21:44 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev, linux-arm-kernel, Socketcan-core, Andrew Victor, wg
In-Reply-To: <1253180254-11910-4-git-send-email-mkl@pengutronix.de>
hi Marc,
> +static inline u32 at91_read(const struct at91_priv *priv, enum at91_reg reg)
> +{
> + return readl(priv->reg_base + reg);
> +}
> +
> +static inline void at91_write(const struct at91_priv *priv, enum at91_reg reg,
> + u32 value)
> +{
> + writel(value, priv->reg_base + reg);
> +}
Rather use __raw_readl() and __raw_writel().
Regards,
Andrew Victor
^ permalink raw reply
* Re: [PATCHv5 3/3] vhost_net: a kernel-level virtio server
From: Ira W. Snyder @ 2009-09-21 21:43 UTC (permalink / raw)
To: Gregory Haskins
Cc: Avi Kivity, Michael S. Tsirkin, netdev, virtualization, kvm,
linux-kernel, mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze,
alacrityvm-devel
In-Reply-To: <4AB1A8FD.2010805@gmail.com>
On Wed, Sep 16, 2009 at 11:11:57PM -0400, Gregory Haskins wrote:
> Avi Kivity wrote:
> > On 09/16/2009 10:22 PM, Gregory Haskins wrote:
> >> Avi Kivity wrote:
> >>
> >>> On 09/16/2009 05:10 PM, Gregory Haskins wrote:
> >>>
> >>>>> If kvm can do it, others can.
> >>>>>
> >>>>>
> >>>> The problem is that you seem to either hand-wave over details like
> >>>> this,
> >>>> or you give details that are pretty much exactly what vbus does
> >>>> already.
> >>>> My point is that I've already sat down and thought about these
> >>>> issues
> >>>> and solved them in a freely available GPL'ed software package.
> >>>>
> >>>>
> >>> In the kernel. IMO that's the wrong place for it.
> >>>
> >> 3) "in-kernel": You can do something like virtio-net to vhost to
> >> potentially meet some of the requirements, but not all.
> >>
> >> In order to fully meet (3), you would need to do some of that stuff you
> >> mentioned in the last reply with muxing device-nr/reg-nr. In addition,
> >> we need to have a facility for mapping eventfds and establishing a
> >> signaling mechanism (like PIO+qid), etc. KVM does this with
> >> IRQFD/IOEVENTFD, but we dont have KVM in this case so it needs to be
> >> invented.
> >>
> >
> > irqfd/eventfd is the abstraction layer, it doesn't need to be reabstracted.
>
> Not per se, but it needs to be interfaced. How do I register that
> eventfd with the fastpath in Ira's rig? How do I signal the eventfd
> (x86->ppc, and ppc->x86)?
>
Sorry to reply so late to this thread, I've been on vacation for the
past week. If you'd like to continue in another thread, please start it
and CC me.
On the PPC, I've got a hardware "doorbell" register which generates 30
distiguishable interrupts over the PCI bus. I have outbound and inbound
registers, which can be used to signal the "other side".
I assume it isn't too much code to signal an eventfd in an interrupt
handler. I haven't gotten to this point in the code yet.
> To take it to the next level, how do I organize that mechanism so that
> it works for more than one IO-stream (e.g. address the various queues
> within ethernet or a different device like the console)? KVM has
> IOEVENTFD and IRQFD managed with MSI and PIO. This new rig does not
> have the luxury of an established IO paradigm.
>
> Is vbus the only way to implement a solution? No. But it is _a_ way,
> and its one that was specifically designed to solve this very problem
> (as well as others).
>
> (As an aside, note that you generally will want an abstraction on top of
> irqfd/eventfd like shm-signal or virtqueues to do shared-memory based
> event mitigation, but I digress. That is a separate topic).
>
> >
> >> To meet performance, this stuff has to be in kernel and there has to be
> >> a way to manage it.
> >
> > and management belongs in userspace.
>
> vbus does not dictate where the management must be. Its an extensible
> framework, governed by what you plug into it (ala connectors and devices).
>
> For instance, the vbus-kvm connector in alacrityvm chooses to put DEVADD
> and DEVDROP hotswap events into the interrupt stream, because they are
> simple and we already needed the interrupt stream anyway for fast-path.
>
> As another example: venet chose to put ->call(MACQUERY) "config-space"
> into its call namespace because its simple, and we already need
> ->calls() for fastpath. It therefore exports an attribute to sysfs that
> allows the management app to set it.
>
> I could likewise have designed the connector or device-model differently
> as to keep the mac-address and hotswap-events somewhere else (QEMU/PCI
> userspace) but this seems silly to me when they are so trivial, so I didn't.
>
> >
> >> Since vbus was designed to do exactly that, this is
> >> what I would advocate. You could also reinvent these concepts and put
> >> your own mux and mapping code in place, in addition to all the other
> >> stuff that vbus does. But I am not clear why anyone would want to.
> >>
> >
> > Maybe they like their backward compatibility and Windows support.
>
> This is really not relevant to this thread, since we are talking about
> Ira's hardware. But if you must bring this up, then I will reiterate
> that you just design the connector to interface with QEMU+PCI and you
> have that too if that was important to you.
>
> But on that topic: Since you could consider KVM a "motherboard
> manufacturer" of sorts (it just happens to be virtual hardware), I don't
> know why KVM seems to consider itself the only motherboard manufacturer
> in the world that has to make everything look legacy. If a company like
> ASUS wants to add some cutting edge IO controller/bus, they simply do
> it. Pretty much every product release may contain a different array of
> devices, many of which are not backwards compatible with any prior
> silicon. The guy/gal installing Windows on that system may see a "?" in
> device-manager until they load a driver that supports the new chip, and
> subsequently it works. It is certainly not a requirement to make said
> chip somehow work with existing drivers/facilities on bare metal, per
> se. Why should virtual systems be different?
>
> So, yeah, the current design of the vbus-kvm connector means I have to
> provide a driver. This is understood, and I have no problem with that.
>
> The only thing that I would agree has to be backwards compatible is the
> BIOS/boot function. If you can't support running an image like the
> Windows installer, you are hosed. If you can't use your ethernet until
> you get a chance to install a driver after the install completes, its
> just like most other systems in existence. IOW: It's not a big deal.
>
> For cases where the IO system is needed as part of the boot/install, you
> provide BIOS and/or an install-disk support for it.
>
> >
> >> So no, the kernel is not the wrong place for it. Its the _only_ place
> >> for it. Otherwise, just use (1) and be done with it.
> >>
> >>
> >
> > I'm talking about the config stuff, not the data path.
>
> As stated above, where config stuff lives is a function of what you
> interface to vbus. Data-path stuff must be in the kernel for
> performance reasons, and this is what I was referring to. I think we
> are generally both in agreement, here.
>
> What I was getting at is that you can't just hand-wave the datapath
> stuff. We do fast path in KVM with IRQFD/IOEVENTFD+PIO, and we do
> device discovery/addressing with PCI. Neither of those are available
> here in Ira's case yet the general concepts are needed. Therefore, we
> have to come up with something else.
>
> >
> >>> Further, if we adopt
> >>> vbus, if drop compatibility with existing guests or have to support both
> >>> vbus and virtio-pci.
> >>>
> >> We already need to support both (at least to support Ira). virtio-pci
> >> doesn't work here. Something else (vbus, or vbus-like) is needed.
> >>
> >
> > virtio-ira.
>
> Sure, virtio-ira and he is on his own to make a bus-model under that, or
> virtio-vbus + vbus-ira-connector to use the vbus framework. Either
> model can work, I agree.
>
Yes, I'm having to create my own bus model, a-la lguest, virtio-pci, and
virtio-s390. It isn't especially easy. I can steal lots of code from the
lguest bus model, but sometimes it is good to generalize, especially
after the fourth implemention or so. I think this is what GHaskins tried
to do.
Here is what I've implemented so far:
* a generic virtio-phys-guest layer (my bus model, like lguest)
- this runs on the crate server (x86) in my system
* a generic virtio-phys-host layer (my /dev/lguest implementation)
- this runs on the ppc boards in my system
- this assumes that the kernel will allocate some memory and
expose it over PCI in a device-specific way, so the guest can
see it as a PCI BAR
* a virtio-phys-mpc83xx driver
- this runs on the crate server (x86) in my system
- this interfaces virtio-phys-guest to my mpc83xx board
- it is a Linux PCI driver, which detects mpc83xx boards, runs
ioremap_pci_bar() on the correct PCI BAR, and then gives that
to the virtio-phys-guest layer
I think that the idea of device/driver (instead of host/guest) is a good
one. It makes my problem easier to think about.
I've given it some thought, and I think that running vhost-net (or
similar) on the ppc boards, with virtio-net on the x86 crate server will
work. The virtio-ring abstraction is almost good enough to work for this
situation, but I had to re-invent it to work with my boards.
I've exposed a 16K region of memory as PCI BAR1 from my ppc board.
Remember that this is the "host" system. I used each 4K block as a
"device descriptor" which contains:
1) the type of device, config space, etc. for virtio
2) the "desc" table (virtio memory descriptors, see virtio-ring)
3) the "avail" table (available entries in the desc table)
Parts 2 and 3 are repeated three times, to allow for a maximum of three
virtqueues per device. This is good enough for all current drivers.
The guest side (x86 in my system) allocates some device-accessible
memory, and writes the PCI address to the device descriptor. This memory
contains:
1) the "used" table (consumed entries in the desc/avail tables)
This exists three times as well, once for each virtqueue.
The rest is basically a copy of virtio-ring, with a few changes to allow
for cacheing, etc. It may not even be worth doing this from a
performance standpoint, I haven't benchmarked it yet.
For now, I'd be happy with a non-DMA memcpy only solution. I can add DMA
once things are working.
I've got the current code (subject to change at any time) available at
the address listed below. If you think another format would be better
for you, please ask, and I'll provide it.
http://www.mmarray.org/~iws/virtio-phys/
I've gotten plenty of email about this from lots of interested
developers. There are people who would like this kind of system to just
work, while having to write just some glue for their device, just like a
network driver. I hunch most people have created some proprietary mess
that basically works, and left it at that.
So, here is a desperate cry for help. I'd like to make this work, and
I'd really like to see it in mainline. I'm trying to give back to the
community from which I've taken plenty.
Ira
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH V2 0/3] at91_can: add support for Atmel's CAN controller on AT91SAM9263
From: Russell King - ARM Linux @ 2009-09-21 21:40 UTC (permalink / raw)
To: Andrew Victor
Cc: Marc Kleine-Budde, Socketcan-core, netdev, Andrew Victor,
Wolfgang Grandegger, linux-arm-kernel
In-Reply-To: <cd73a99e0909211431k37429a70o4efaac7104f7d526@mail.gmail.com>
On Mon, Sep 21, 2009 at 11:31:19PM +0200, Andrew Victor wrote:
> hi Marc,
>
> >>> Marc Kleine-Budde (3):
> >>> at91sam9263: add at91_can device to generic device definition
> >>> at91sam9263ek: activate at91 CAN controller
> >>> at91_can: add driver for Atmel's CAN controller on AT91SAM9263
> >>
> >> I have just added my "signed-off-by" for the Socket-CAN patch #3. Don't
> >> known who will take care of the other patches.
> >
> > Thanks Wolfgang.
> >
> > Andrew, are the first two going throught the arm tree?
>
> That would be best.
> Please submit them to Russell King's patch system.
While we're at at91 stuff, please can someone see about fixing the
AC97 breakage with at91cap9adk_defconfig please, or confirming that
patches I already have fix this?
^ permalink raw reply
* Re: [PATCH V2 0/3] at91_can: add support for Atmel's CAN controller on AT91SAM9263
From: Andrew Victor @ 2009-09-21 21:31 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Wolfgang Grandegger, netdev, Socketcan-core, Andrew Victor,
linux-arm-kernel
In-Reply-To: <4AB209CB.10707@pengutronix.de>
hi Marc,
>>> Marc Kleine-Budde (3):
>>> at91sam9263: add at91_can device to generic device definition
>>> at91sam9263ek: activate at91 CAN controller
>>> at91_can: add driver for Atmel's CAN controller on AT91SAM9263
>>
>> I have just added my "signed-off-by" for the Socket-CAN patch #3. Don't
>> known who will take care of the other patches.
>
> Thanks Wolfgang.
>
> Andrew, are the first two going throught the arm tree?
That would be best.
Please submit them to Russell King's patch system.
Regards,
Andrew Victor
^ permalink raw reply
* Re: [PATCH 1/3] at91sam9263: add at91_can device to generic device definition
From: Marc Kleine-Budde @ 2009-09-21 21:30 UTC (permalink / raw)
To: Andrew Victor
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <cd73a99e0909211423v11db220fy1a669d389646f249-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey Andrew,
Andrew Victor wrote:
>> This patch adds the device definition for the at91_can device to
>> the generic device definiton file for the at91sam9263.
>>
>> Signed-off-by: Hans J. Koch <hjk-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
>> Signed-off-by: Marc Kleine-Budde <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Acked-by: Andrew Victor <linux-PelNFVqkFnVyf+4FbqDuWQ@public.gmane.org>
Thanks for you Ack, how do the first two patches now get into mainline?
The third one goes over David's net-next-2.6.
cheers, Marc
- --
Pengutronix e.K. | Marc Kleine-Budde |
Linux Solutions for Science and Industry | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkq38HsACgkQjTAFq1RaXHMhNgCfRIe+YdnwKsO7C1HwT6azHSH4
Oh4An3DBidtNAbRWsVyFco/mPcJHhA4z
=hbZm
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: fanotify as syscalls
From: Andreas Gruenbacher @ 2009-09-21 21:27 UTC (permalink / raw)
To: Jamie Lokier
Cc: Eric Paris, Linus Torvalds, Evgeniy Polyakov, David Miller,
linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <20090921202823.GB14700@shareable.org>
On Monday, 21 September 2009 22:28:23 Jamie Lokier wrote:
> It would be logical if fanotify could block and ack those [mount & umount
> events] in the same way as it can block and ack other accesses (with the
> usual filtering rules on which inodes trigger events, and which don't or are
> cached).
Hmm. To me, fanotify is about file contents first of all: this is what
fanotify wants to be able to veto. Directory events seem reasonable to add
for inotify compatibility, but I see no need for access decisions on them.
Even less so for mounts and unmounts. (Besides, we can't hold any vfs locks
while asking fanotify so those operations wouldn't be atomic, anyway.)
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCH 2/3] at91sam9263ek: activate at91 CAN controller
From: Andrew Victor @ 2009-09-21 21:27 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: netdev, linux-arm-kernel, Socketcan-core, Andrew Victor, wg,
Hans J. Koch
In-Reply-To: <1253180254-11910-3-git-send-email-mkl@pengutronix.de>
hi Marc,
> This patch activates the at91 CAN controller for the at91sam9263ek
> development board.
>
> Signed-off-by: Hans J. Koch <hjk@linutronix.de>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Andrew Victor <linux@maxim.org.za>
^ permalink raw reply
* Re: [PATCH 1/3] at91sam9263: add at91_can device to generic device definition
From: Andrew Victor @ 2009-09-21 21:23 UTC (permalink / raw)
To: Marc Kleine-Budde; +Cc: netdev, Socketcan-core, Hans J. Koch, linux-arm-kernel
In-Reply-To: <1253094405-3216-2-git-send-email-mkl@pengutronix.de>
hi Marc,
> This patch adds the device definition for the at91_can device to
> the generic device definiton file for the at91sam9263.
>
> Signed-off-by: Hans J. Koch <hjk@linutronix.de>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Andrew Victor <linux@maxim.org.za>
^ permalink raw reply
* Re: [PATCH 02/13] TProxy: add lookup type checks for UDP in nf_tproxy_get_sock_v4()
From: Jan Engelhardt @ 2009-09-21 21:20 UTC (permalink / raw)
To: Balazs Scheidler; +Cc: netfilter-devel, netdev
In-Reply-To: <1253548005.12519.2.camel@bzorp.balabit>
On Saturday 2009-08-15 14:01, Balazs Scheidler wrote:
>+ case IPPROTO_UDP:
>+ sk = udp4_lib_lookup(net, saddr, sport, daddr, dport,
>+ in->ifindex);
You might want to add IPPROTO_UDPLITE in all places.
^ permalink raw reply
* Re: [net-2.6 PATCH 2/6] net: remove kfree_skb on a NULL pointer in af_netlink.c
From: David Miller @ 2009-09-21 20:54 UTC (permalink / raw)
To: john.r.fastabend; +Cc: jeffrey.t.kirsher, netdev, gospo, linux-scsi
In-Reply-To: <4AB76BD3.80802@intel.com>
From: John Fastabend <john.r.fastabend@intel.com>
Date: Mon, 21 Sep 2009 12:04:35 +0000
>>
> OK, but this depends on the unlikely() macro in kfree_skb() to catch a
> case that is the expected non-error case. Would it be better to wrap
> the kfree_skb() in an if statement to avoid hitting the unlikely()
> macro? Or is the performance hit from the unlikely() macro so small
> this is not an issue? Thanks for looking at these.
>
Expands too much code inline, that's why we don't do it that
way.
^ permalink raw reply
* Re: fanotify as syscalls
From: Jamie Lokier @ 2009-09-21 20:28 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: Eric Paris, Linus Torvalds, Evgeniy Polyakov, David Miller,
linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <200909212204.51077.agruen@suse.de>
Andreas Gruenbacher wrote:
> On Saturday, 19 September 2009 5:04:31 Eric Paris wrote:
> > Let me start by saying I am agreeing I should pursue subtree
> > notification. It's what I think everyone really wants. It's a great
> > idea, and I think you might have a simple way to get close. Clearly
> > these are avenues I'm willing and hoping to pursue. Also I say it
> > again, I believe the interface as proposed (except maybe some of my
> > exclusion stuff) is flexible enough to implement any of these ideas.
> > Does anyone disagree?
>
> It does seem flexible enough. However, the current interface assumes "global"
> listeners (the mask argument of fanotify_init):
>
> int fanotify_init(int flags, int f_flags, __u64 mask,
> unsigned int priority);
>
> Once subtree support is added, this parameter becomes obsolete. That's pretty
> broken for a syscall yet to be introduced.
>
> > BUT to solve one of the main problems fanotify is intending to solve it
> > needs a way to be the 'fscking all notifier.' It needs to be the whole
> > damn system.
>
> Think of a system after boot, with a single global namespace. Whatever you
> access by filename is reachable from the namespace root. At this point,
> nothing more global exists. A listener can watch the mount points of
> interest, and everything's fine.
>
> What's a bit more tricky is to ensure that this listener will continue to
> receive all events from whatever else is mounted anywhere, irrespective of
> namespaces. I think we can get there.
I think so to, and that'd be a great all round solution.
We _have_ to receive mount & umount events to do this. But even
inotify-style tracking needs those if it's to be accurate, so it's not
an additional burden.
It would be logical if fanotify could block and ack those in the same
way as it can block and ack other accesses (with the usual filtering
rules on which inodes trigger events, and which don't or are cached).
As in to prevent: mount --bind innocent .bash_login, but also to
ensure it always knows what's mounted when another event occurs.
> By the way, Documentation/filesystems/sharedsubtree.txt describes how
> filesystem namespaces work.
Fortunately, after making a new namespace you can read the mounts in
the new namespace from /proc/self/mount* (I think) without having to
know anything about the shared subtree rules.
So to follow monitoring/checking across all namespaces, it would (I
think) be enough to receive a fanotify "new namespace" event, and Ack
that event to allow the CLONE_NS to proceed. It's still tricky stuff
though.
-- Jamie
^ permalink raw reply
* Re: [AX25] kernel panic
From: Jarek Poplawski @ 2009-09-21 20:11 UTC (permalink / raw)
To: Bernard Pidoux; +Cc: Ralf Baechle DL5RB, Linux Netdev List, linux-hams
<20090910142436.GB10547@linux-mips.org> <4AA9288B.2070205@upmc.fr>
<20090911120557.GA12175@linux-mips.org> <4AB5EAE5.6070605@upmc.fr>
<20090920210242.GA9804@del.dom.local> <4AB73CDE.4030709@upmc.fr>
In-Reply-To: <4AB73CDE.4030709@upmc.fr>
Bernard Pidoux wrote, On 09/21/2009 10:44 AM:
> Hi Jarek,
>
> Good fishing !
>
> During the night I catched the following two identical AX25_DBG
> messages with netconsole
> sending already reported message: kernel BUG at kernel/timer.c:913!
> and followed by kernel
> panics and the machine rebooting.
>
>
> Sep 21 03:24:06 f6bvp-11 klogd: ------------[ cut here ]------------
> Sep 21 03:24:06 f6bvp-11 klogd: WARNING: at include/net/ax25.h:260
> ax25_kiss_rcv+0x650/0xab0 [ax25]()
Thanks for testing. Alas I don't get how it's possible at this place
(unless I miss the place), especially with a nosmp kernel. So here is
take 2 (to apply after reverting the previous one).
Regards,
Jarek P.
--- (debugging patch, take 2)
include/net/ax25.h | 36 ++++++++++++++++++++++++++++++++++++
net/ax25/af_ax25.c | 12 ++++++++++++
2 files changed, 48 insertions(+), 0 deletions(-)
diff --git a/include/net/ax25.h b/include/net/ax25.h
index 717e219..7fefbb0 100644
--- a/include/net/ax25.h
+++ b/include/net/ax25.h
@@ -252,9 +252,45 @@ typedef struct ax25_cb {
#define ax25_cb_hold(__ax25) \
atomic_inc(&((__ax25)->refcount))
+static __inline__ int ax25_timers_warn(ax25_cb *ax25)
+{
+ int err = 0;
+
+ if (del_timer(&ax25->timer)) {
+ WARN_ON_ONCE(1);
+ err = 1;
+ }
+ if (del_timer(&ax25->t1timer)) {
+ WARN_ON_ONCE(1);
+ err += 2;
+ }
+ if (del_timer(&ax25->t2timer)) {
+ WARN_ON_ONCE(1);
+ err += 4;
+ }
+ if (del_timer(&ax25->t3timer)) {
+ WARN_ON_ONCE(1);
+ err += 8;
+ }
+ if (del_timer(&ax25->idletimer)) {
+ WARN_ON_ONCE(1);
+ err += 16;
+ }
+ if (del_timer(&ax25->dtimer)) {
+ WARN_ON_ONCE(1);
+ err += 32;
+ }
+ if (err)
+ printk(KERN_WARNING "AX25_DBG: %d %p %u %s %d\n", err, ax25,
+ ax25->state, __func__, __LINE__);
+
+ return err;
+}
+
static __inline__ void ax25_cb_put(ax25_cb *ax25)
{
if (atomic_dec_and_test(&ax25->refcount)) {
+ ax25_timers_warn(ax25);
kfree(ax25->digipeat);
kfree(ax25);
}
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index da0f64f..f1f515c 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -58,6 +58,9 @@ static const struct proto_ops ax25_proto_ops;
static void ax25_free_sock(struct sock *sk)
{
+ if (ax25_timers_warn(ax25_sk(sk)))
+ printk(KERN_WARNING "AX25_DBG: %p %u %u %u\n", sk,
+ sk->sk_family, sk->sk_type, sk->sk_protocol);
ax25_cb_put(ax25_sk(sk));
}
@@ -222,6 +225,8 @@ ax25_cb *ax25_find_cb(ax25_address *src_addr, ax25_address *dest_addr,
if (s->ax25_dev == NULL)
continue;
if (ax25cmp(&s->source_addr, src_addr) == 0 && ax25cmp(&s->dest_addr, dest_addr) == 0 && s->ax25_dev->dev == dev) {
+ int ref;
+
if (digi != NULL && digi->ndigi != 0) {
if (s->digipeat == NULL)
continue;
@@ -231,6 +236,13 @@ ax25_cb *ax25_find_cb(ax25_address *src_addr, ax25_address *dest_addr,
if (s->digipeat != NULL && s->digipeat->ndigi != 0)
continue;
}
+ ref = atomic_read(&s->refcount);
+ if (ref < 2) {
+ WARN_ON_ONCE(1);
+ printk(KERN_WARNING "AX25_DBG: %d %p %d %s\n",
+ ref, s, s->state, __func__);
+ }
+
ax25_cb_hold(s);
spin_unlock_bh(&ax25_list_lock);
^ permalink raw reply related
* Re: fanotify as syscalls
From: Andreas Gruenbacher @ 2009-09-21 20:04 UTC (permalink / raw)
To: Eric Paris
Cc: Jamie Lokier, Linus Torvalds, Evgeniy Polyakov, David Miller,
linux-kernel, linux-fsdevel, netdev, viro, alan, hch
In-Reply-To: <1253329471.2630.30.camel@dhcp231-106.rdu.redhat.com>
On Saturday, 19 September 2009 5:04:31 Eric Paris wrote:
> Let me start by saying I am agreeing I should pursue subtree
> notification. It's what I think everyone really wants. It's a great
> idea, and I think you might have a simple way to get close. Clearly
> these are avenues I'm willing and hoping to pursue. Also I say it
> again, I believe the interface as proposed (except maybe some of my
> exclusion stuff) is flexible enough to implement any of these ideas.
> Does anyone disagree?
It does seem flexible enough. However, the current interface assumes "global"
listeners (the mask argument of fanotify_init):
int fanotify_init(int flags, int f_flags, __u64 mask,
unsigned int priority);
Once subtree support is added, this parameter becomes obsolete. That's pretty
broken for a syscall yet to be introduced.
> BUT to solve one of the main problems fanotify is intending to solve it
> needs a way to be the 'fscking all notifier.' It needs to be the whole
> damn system.
Think of a system after boot, with a single global namespace. Whatever you
access by filename is reachable from the namespace root. At this point,
nothing more global exists. A listener can watch the mount points of
interest, and everything's fine.
What's a bit more tricky is to ensure that this listener will continue to
receive all events from whatever else is mounted anywhere, irrespective of
namespaces. I think we can get there.
By the way, Documentation/filesystems/sharedsubtree.txt describes how
filesystem namespaces work.
Thanks,
Andreas
^ permalink raw reply
* [PATCH] bcm63xx_enet: timeout off by one in do_mdio_op()
From: Roel Kluin @ 2009-09-21 20:08 UTC (permalink / raw)
To: mbizon, netdev, Andrew Morton
`while (limit-- >= 0)' reaches -2 after the loop upon timeout.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
---
Small chance to occur, probably.
diff --git a/drivers/net/bcm63xx_enet.c b/drivers/net/bcm63xx_enet.c
index 09d2709..ba29dc3 100644
--- a/drivers/net/bcm63xx_enet.c
+++ b/drivers/net/bcm63xx_enet.c
@@ -90,7 +90,7 @@ static int do_mdio_op(struct bcm_enet_priv *priv, unsigned int data)
if (enet_readl(priv, ENET_IR_REG) & ENET_IR_MII)
break;
udelay(1);
- } while (limit-- >= 0);
+ } while (limit-- > 0);
return (limit < 0) ? 1 : 0;
}
^ permalink raw reply related
* Re: [net-2.6 PATCH 2/6] net: remove kfree_skb on a NULL pointer in af_netlink.c
From: John Fastabend @ 2009-09-21 12:04 UTC (permalink / raw)
To: David Miller
Cc: Kirsher, Jeffrey T, netdev@vger.kernel.org, gospo@redhat.com,
linux-scsi@vger.kernel.org
In-Reply-To: <20090917.182445.240085155.davem@davemloft.net>
David Miller wrote:
> From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> Date: Thu, 17 Sep 2009 17:57:29 -0700
>
>
>> From: John Fastabend <john.r.fastabend@intel.com>
>>
>> This removes a kfree_skb that is being called on a NULL pointer when
>> do_one_broadcast() is sucessful. And moves the kfree_skb into
>> do_one_broadcast() for the error case.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
>>
>
> kfree_skb() on a NULL pointer is completely legal.
>
OK, but this depends on the unlikely() macro in kfree_skb() to catch a
case that is the expected non-error case. Would it be better to wrap the
kfree_skb() in an if statement to avoid hitting the unlikely() macro?
Or is the performance hit from the unlikely() macro so small this is not
an issue? Thanks for looking at these.
john.
^ permalink raw reply
* Re: "cfg80211: fix SME connect" breaks iwl3945
From: Christian Lamparter @ 2009-09-21 19:14 UTC (permalink / raw)
To: Jens Axboe; +Cc: Linux Kernel, johannes, netdev
In-Reply-To: <20090921190150.GC23126@kernel.dk>
On Monday 21 September 2009 21:01:50 Jens Axboe wrote:
> Since the latest net pull that contains our above commit
> (bbac31f4c0339f6c51afbd0edfb4959df9b53fa9 in tree), my iwl3945 based x60
> laptop doesn't want to connect to my access point at all. Reverting this
> commit makes it work.
>
> Let me know if you need more info.
Can you try "[PATCH] cfg80211: don't overwrite privacy setting"
from [1]?
[1] http://marc.info/?l=linux-wireless&m=125323296617306&w=2
Regards,
Chr
^ permalink raw reply
* Re: "cfg80211: fix SME connect" breaks iwl3945
From: Jens Axboe @ 2009-09-21 19:20 UTC (permalink / raw)
To: Christian Lamparter; +Cc: Linux Kernel, johannes, netdev
In-Reply-To: <200909212114.06642.chunkeey@googlemail.com>
On Mon, Sep 21 2009, Christian Lamparter wrote:
> On Monday 21 September 2009 21:01:50 Jens Axboe wrote:
> > Since the latest net pull that contains our above commit
> > (bbac31f4c0339f6c51afbd0edfb4959df9b53fa9 in tree), my iwl3945 based x60
> > laptop doesn't want to connect to my access point at all. Reverting this
> > commit makes it work.
> >
> > Let me know if you need more info.
>
> Can you try "[PATCH] cfg80211: don't overwrite privacy setting"
> from [1]?
>
> [1] http://marc.info/?l=linux-wireless&m=125323296617306&w=2
Seems to bring the network back as well, it associates fine and gets a
dhcp address.
--
Jens Axboe
^ permalink raw reply
* "cfg80211: fix SME connect" breaks iwl3945
From: Jens Axboe @ 2009-09-21 19:01 UTC (permalink / raw)
To: Linux Kernel; +Cc: johannes, netdev
Hi Johannes,
Since the latest net pull that contains our above commit
(bbac31f4c0339f6c51afbd0edfb4959df9b53fa9 in tree), my iwl3945 based x60
laptop doesn't want to connect to my access point at all. Reverting this
commit makes it work.
Let me know if you need more info.
--
Jens Axboe
^ permalink raw reply
* Re: [PANIC] pktgen panic on load
From: Simon Holm Thøgersen @ 2009-09-21 18:49 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Jesse Brandeburg, netdev
In-Reply-To: <20090921095451.5ce95767@s6510>
> > > > just got this today after cloning Linus' tree, please let me know if you
> > > > want .config or full dmesg
> > >
> > > config would help (hrt, nohz, preempt, ...), and was it just on module load?
> > > or had you started it sending?
> >
> > I have the similar trace below on a simple 'modprobe pktgen'. I've
> > attached my config for v2.6.31-6456-g78f28b7.
>
> Could you do a git bisect, although pktgen changed recently, the changes were
> not related to the thread initialization, so I suspect something outside
> the scope of networking (ie scheduler, vm, etc)
Seems like this was fixed by commit 3f04e8c ("sched: Re-add lost
cpu_allowed check to sched_fair.c::select_task_rq_fair()") according to
Ingo [1]. Indeed, using Linus' current tree works for me.
[1] http://marc.info/?l=linux-netdev&m=125355156524237&w=2
Simon Holm Thøgersen
^ 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