* 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
* Re: bugfix: wireless bug causing working setups to loose net connectivity
From: Oliver Hartkopp @ 2009-09-21 18:44 UTC (permalink / raw)
To: Arkadiusz Miskiewicz; +Cc: Johannes Berg, netdev
In-Reply-To: <200909212035.50592.a.miskiewicz@gmail.com>
Arkadiusz Miskiewicz wrote:
> Could
> http://marc.info/?l=linux-wireless&m=125323296617306&w=2
> be merged without waiting for separate wireless pull request?
>
> Currently previously working setups are no longer able to connect to AP (in my
> case WPA2PSK via wpasupplicant).
>
> AFAIK there was some kind of policy where bugfixes that break basic
> functionality are supposed to be merged fast to allow to actually use and test
> git kernel.
For me it was
http://git.kernel.org/?p=linux/kernel/git/davem/net-2.6.git;a=commitdiff;h=bbac31f4c0339f6c51afbd0edfb4959df9b53fa9
as written here:
http://marc.info/?l=linux-netdev&m=125352781320953&w=2
Maybe you can try to revert this patch in your setup too, to check whether it
also solves your issue.
Regards,
Oliver
^ permalink raw reply
* bugfix: wireless bug causing working setups to loose net connectivity
From: Arkadiusz Miskiewicz @ 2009-09-21 18:35 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev
Could
http://marc.info/?l=linux-wireless&m=125323296617306&w=2
be merged without waiting for separate wireless pull request?
Currently previously working setups are no longer able to connect to AP (in my
case WPA2PSK via wpasupplicant).
AFAIK there was some kind of policy where bugfixes that break basic
functionality are supposed to be merged fast to allow to actually use and test
git kernel.
Thanks,
--
Arkadiusz Miśkiewicz PLD/Linux Team
arekm / maven.pl http://ftp.pld-linux.org/
^ permalink raw reply
* Re: [PATCH 13/13] TProxy: use the interface primary IP address as a default value for --on-ip
From: Brian Haley @ 2009-09-21 18:00 UTC (permalink / raw)
To: Balazs Scheidler; +Cc: netfilter-devel, netdev
In-Reply-To: <1253548005.12519.13.camel@bzorp.balabit>
Balazs Scheidler wrote:
> #if defined(CONFIG_IPV6) || defined(CONFIG_IPV6_MODULE)
> +
> +static inline const struct in6_addr *
> +tproxy_laddr6(struct sk_buff *skb, const struct in6_addr *user_laddr, const struct in6_addr *daddr)
> +{
> + struct inet6_dev *indev;
> + struct inet6_ifaddr *ifa;
> + struct in6_addr *laddr;
> +
> + if (!ipv6_addr_any(user_laddr))
> + return user_laddr;
> +
> + laddr = NULL;
> + rcu_read_lock();
> + indev = __in6_dev_get(skb->dev);
> + if (indev && (ifa = indev->addr_list)) {
> + laddr = &ifa->addr;
> + }
> + rcu_read_unlock();
> +
> + return laddr ? laddr : daddr;
> +}
You should call ipv6_dev_get_saddr() to get a source address based on the target
destination address.
-Brian
^ permalink raw reply
* Re: [PATCH 12/13] TProxy: added IPv6 support to the socket match
From: Brian Haley @ 2009-09-21 17:59 UTC (permalink / raw)
To: Balazs Scheidler; +Cc: netfilter-devel, netdev
In-Reply-To: <1253548005.12519.12.camel@bzorp.balabit>
Balazs Scheidler wrote:
> +static bool
> +socket_mt6_v1(const struct sk_buff *skb, const struct xt_match_param *par)
> +{
> + struct ipv6hdr *iph = ipv6_hdr(skb);
> + struct udphdr _hdr, *hp = NULL;
> + struct sock *sk;
> + struct in6_addr *daddr, *saddr;
> + __be16 dport, sport;
> + int thoff;
> + u8 tproto;
> + const struct xt_socket_mtinfo1 *info = (struct xt_socket_mtinfo1 *) par->matchinfo;
> +
> + tproto = ipv6_find_hdr(skb, &thoff, -1, NULL);
> + if (tproto < 0) {
> + pr_debug("socket match: Unable to find transport header in IPv6 packet, dropping\n");
> + return NF_DROP;
> + }
> +
> + if (tproto == IPPROTO_UDP || tproto == IPPROTO_TCP) {
> + hp = skb_header_pointer(skb, thoff,
> + sizeof(_hdr), &_hdr);
> + if (hp == NULL)
> + return false;
> +
> + saddr = &iph->saddr;
> + sport = hp->source;
> + daddr = &iph->daddr;
> + dport = hp->dest;
> +
> + } else if (tproto == IPPROTO_ICMP) {
> + if (extract_icmp6_fields(skb, thoff, &tproto, &saddr, &daddr,
> + &sport, &dport))
> + return false;
> + } else {
> + return false;
> + }
Shouldn't this be IPPROTO_ICMPV6?
-Brian
^ permalink raw reply
* Re: SO_TIMESTAMPING fix and design decisions
From: John Ronciak @ 2009-09-21 17:59 UTC (permalink / raw)
To: Christopher Zimmermann; +Cc: netdev
In-Reply-To: <20090920205047.0f2df70c@pundit>
On Sun, Sep 20, 2009 at 11:50 AM, Christopher Zimmermann
<madroach@zakweb.de> wrote:
> It will need to be modified. If you want to avoid this, one could keep
> the HWTSTAMP_FILTER_PTP_.... defines and just redifine them to reflect
> the new interface.
> Where can I find this ptpd userspace daemon, which supports hardware
> timestamps using the ioctl interface? ptpd.sourceforge.net doesn't.
You can find a version of the modified ptpd on the e1000 Sourceforge
site http://e1000.sf.net. It has a version of the igb driver that
also supports this interface though it's a bit behind the regular igb
driver version.
I'm review your comments that start this thread and should have some
comments soon.
--
Cheers,
John
^ permalink raw reply
* Re: [PANIC] pktgen panic on load
From: Stephen Hemminger @ 2009-09-21 16:54 UTC (permalink / raw)
To: Simon Holm Thøgersen; +Cc: Jesse Brandeburg, netdev
In-Reply-To: <1253547857.2810.6.camel@odie>
On Mon, 21 Sep 2009 17:44:17 +0200
Simon Holm Thøgersen <odie@cs.aau.dk> wrote:
> søn, 20 09 2009 kl. 21:35 -0700, skrev Stephen Hemminger:
> > On Sun, 20 Sep 2009 15:45:47 -0700
> > Jesse Brandeburg <jesse.brandeburg@intel.com> wrote:
> >
> > > 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.
>
> > [ 2302.386665] pktgen 2.72: Packet Generator for packet performance testing.
> > [ 2302.386783] ------------[ cut here ]------------
> > [ 2302.386790] kernel BUG at net/core/pktgen.c:3503!
> > [ 2302.386796] invalid opcode: 0000 [#1] SMP
> > [ 2302.386803] last sysfs file: /sys/devices/pci0000:00/0000:00:1c.1/0000:02:00.0/ieee80211/phy0/rfkill1/state
> > [ 2302.386812] CPU 1
> > [ 2302.386817] Modules linked in: pktgen(+) i915 drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect binfmt_misc ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack bnep ipt_REJECT xt_tcpudp iptable_filter ip_tables x_tables bridge stp llc kvm_intel kvm tun snd_hda_codec_analog snd_hda_intel snd_hda_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_oss arc4 ecb snd_seq_midi_event snd_seq iwlagn snd_timer snd_seq_device iwlcore mac80211 uvcvideo snd video sdhci_pci soundcore snd_page_alloc cfg80211 ricoh_mmc videodev v4l1_compat v4l2_compat_ioctl32 intel_agp psmouse e1000e output sdhci led_class btusb
> > [ 2302.386920] Pid: 2897, comm: kpktgend_0 Not tainted 2.6.31-debug #8 HP EliteBook 6930p
> > [ 2302.386926] RIP: 0010:[<ffffffffa035483c>] [<ffffffffa035483c>] pktgen_thread_worker+0x19ac/0x1a40 [pktgen]
> > [ 2302.386945] RSP: 0018:ffff880050755d30 EFLAGS: 00010297
> > [ 2302.386950] RAX: 0000000000000001 RBX: ffff880057ae18c0 RCX: ffff880057ae18c0
> > [ 2302.386956] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff88006637d400
> > [ 2302.386961] RBP: ffff880050755ee0 R08: ffff880050754000 R09: 0000000000000000
> > [ 2302.386967] R10: 0000000000000001 R11: 0000000000000400 R12: ffff88005ae61db0
> > [ 2302.386973] R13: ffff88006637d400 R14: ffffffffa0352e90 R15: ffff88006637d400
> > [ 2302.386980] FS: 0000000000000000(0000) GS:ffff880006080000(0000) knlGS:0000000000000000
> > [ 2302.386986] CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
> > [ 2302.386991] CR2: 00007f861ee0e080 CR3: 0000000057a2a000 CR4: 00000000000026a0
> > [ 2302.386997] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> > [ 2302.387003] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> > [ 2302.387010] Process kpktgend_0 (pid: 2897, threadinfo ffff880050754000, task ffff880057ae18c0)
> > [ 2302.387014] Stack:
> > [ 2302.387018] 0000000000000000 ffff880057ae18f8 ffff88000609bc58 ffff880057ae18f8
> > [ 2302.387027] <0> ffff880050755d80 ffffffff81043726 ffff88000609bc30 ffff880057ae18f8
> > [ 2302.387037] <0> 0000000000000001 ffff88000609bc30 ffff880050755db0 ffff88005ae1ca78
> > [ 2302.387048] Call Trace:
> > [ 2302.387064] [<ffffffff81043726>] ? update_curr+0xe6/0x190
> > [ 2302.387073] [<ffffffff8103586e>] ? update_stats_wait_end+0xae/0xf0
> > [ 2302.387084] [<ffffffff81009e0d>] ? __switch_to+0xcd/0x320
> > [ 2302.387092] [<ffffffff81040a13>] ? finish_task_switch+0x43/0xd0
> > [ 2302.387103] [<ffffffff81444638>] ? thread_return+0x3e/0x6c6
> > [ 2302.387113] [<ffffffff81066ed0>] ? autoremove_wake_function+0x0/0x40
> > [ 2302.387125] [<ffffffffa0352e90>] ? pktgen_thread_worker+0x0/0x1a40 [pktgen]
> > [ 2302.387136] [<ffffffffa0352e90>] ? pktgen_thread_worker+0x0/0x1a40 [pktgen]
> > [ 2302.387143] [<ffffffff81066aa6>] kthread+0x96/0xb0
> > [ 2302.387151] [<ffffffff8100c68a>] child_rip+0xa/0x20
> > [ 2302.387158] [<ffffffff81066a10>] ? kthread+0x0/0xb0
> > [ 2302.387164] [<ffffffff8100c680>] ? child_rip+0x0/0x20
> > [ 2302.387168] Code: 89 df 31 db e8 36 2d 00 e1 e9 0d f0 ff ff 90 89 da 48 8b b5 b0 fe ff ff 48 c7 c7 ce 5e 35 a0 31 c0 e8 86 f6 0e e1 e9 fa f5 ff ff <0f> 0b eb fe 49 8b 85 48 02 00 00 48 89 de 4c 89 ef ff 50 30 89
> > [ 2302.387243] RIP [<ffffffffa035483c>] pktgen_thread_worker+0x19ac/0x1a40 [pktgen]
> > [ 2302.387256] RSP <ffff880050755d30>
> > [ 2302.387281] ---[ end trace 120a26c5c90348c4 ]---
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)
^ permalink raw reply
* Re: [crash] kernel BUG at net/core/pktgen.c:3503!
From: Ingo Molnar @ 2009-09-21 16:45 UTC (permalink / raw)
To: David Miller
Cc: gorcunov, torvalds, akpm, netdev, linux-kernel, Peter Zijlstra
In-Reply-To: <20090917174448.GA9548@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
>
> * David Miller <davem@davemloft.net> wrote:
>
> > From: Cyrill Gorcunov <gorcunov@gmail.com>
> > Date: Tue, 15 Sep 2009 22:51:12 +0400
> >
> > > [Ingo Molnar - Tue, Sep 15, 2009 at 08:36:47PM +0200]
> > > |
> > > | not sure which merge caused this, but i got this boot crash with latest
> > > | -git:
> > > |
> > > | calling flow_cache_init+0x0/0x1b9 @ 1
> > > | initcall flow_cache_init+0x0/0x1b9 returned 0 after 64 usecs
> > > | calling pg_init+0x0/0x37c @ 1
> > > | pktgen 2.72: Packet Generator for packet performance testing.
> > > | ------------[ cut here ]------------
> > > | kernel BUG at net/core/pktgen.c:3503!
> > > | invalid opcode: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> > > | last sysfs file:
> > > |
> > >
> > > Hi Ingo,
> > >
> > > just curious, will the following patch fix the problem?
> > > I've been fixing problem with familiar symthoms on
> > > system with custome virtual cpu implementation so
> > > it may not help in mainline but anyway :)
> >
> > Ingo, does Cyrill's patch help?
>
> For now i've turned pktgen off in my tests. Will check it again once
> things have calmed down somewhat.
>
> Also, i just tried to reproduce the pktgen crash with latest -git and
> the config i sent - no luck, so i cannot test Cyrill's patch either.
>
> Btw., we are seeing some other preempt count and task related
> weirdnesses as well in other code, maybe it's related. No good pattern
> yet to act upon.
>
> Anyway - please disregard this bugreport until i've investigated it
> closer.
Update: i've further investigated it and this bug was caused by a
scheduler bug introduced in this merge window, which got fixed in:
3f04e8c: sched: Re-add lost cpu_allowed check to sched_fair.c::select_task_rq_fair()
This bug caused CPU affinities to not work in essence - breaking kthread
per-cpu assumptions in net/core/pktgen.c.
I've confirmed this by re-enabling pktgen in my tests and the crash has
no reappeared.
Thanks,
Ingo
^ 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