CC [M] net/ipv4/netfilter/ip_conntrack_core.o
net/ipv4/netfilter/ip_conntrack_core.c: In function
`ip_conntrack_event_cache_init':
include/linux/netfilter_ipv4/ip_conntrack.h:296: sorry, unimplemented:
inlining failed in call to 'ip_conntrack_put': function body not
available
net/ipv4/netfilter/
Andrew Morton wrote:
Begin forwarded message:
Date: Thu, 21 Jul 2005 11:39:44 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 4922] New: Bug in netfilter.c when drivers do
hardware checksum generation.
http://bugzilla.kernel.org/show_bug.cgi?id=4922
S
David S. Miller wrote:
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Wed, 13 Jul 2005 01:38:37 +0200
If its about outgoing traffic, shouldn't a prio-qdisc as root qdisc do
just fine? skb->priority can be used to select a queue. Incoming traffic
with pre-classification by the NIC would require
Begin forwarded message:
Date: Thu, 21 Jul 2005 11:39:44 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [Bugme-new] [Bug 4922] New: Bug in netfilter.c when drivers do
hardware checksum generation.
http://bugzilla.kernel.org/show_bug.cgi?id=4922
Summary: Bug in netfil
Dave,
The second one again, also at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git
- Arnaldo
sk_refcnt_debug.patch
Description: Binary data
Hi David,
Fixed those tabs, etc, both changesets available at:
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/acme/net-2.6.14.git
This time done over latest net-2.6.14 from you.
Regards,
- Arnaldo
PS.: lets see if gmail works this time...
reqsk_queue_destroy.patch
Description: Bin
Ben Greear wrote:
Ben Greear wrote:
Er, now I feel like an idiot. I am using the real_dev that
is saved in the vlan device logic, not the thing in the
skb.
Please ignore my previous ravings.
Ben
--
Ben Greear <[EMAIL PROTECTED]>
Candela Technologies Inc http://www.candelatech.com
-
To un
Ben Greear wrote:
David S. Miller wrote:
I studied this and it's merely a matter of parameter passing.
Specifically, at ptype->func() time, it is plainly the skb->dev
before skb_bond() is applied.
So I added a "real_dev" arg to ptype->func() and converted
the tree over to that.
Thomas, this k
David S. Miller <[EMAIL PROTECTED]> wrote:
[...]
>Comments?
FWIW, there have been a couple of proposals floating around
bonding-devel for a while from people looking to get the skb->real_dev
in user space (for network manager applications and user-level link
state monitor type things). T
David S. Miller wrote:
I studied this and it's merely a matter of parameter passing.
Specifically, at ptype->func() time, it is plainly the skb->dev
before skb_bond() is applied.
So I added a "real_dev" arg to ptype->func() and converted
the tree over to that.
Thomas, this kills the TCF_META_ID
Hi Dave,
> > The pkt_type zero is not a valid one. We only use 1-4 and 0xff. So this
> > can't be the problem. I assume that the cb is not copied from the driver
> > into the core at some point.
>
> All clones and copies of SKBs copy of the ->cb[] for you.
> So perhaps something is spamming the -
I studied this and it's merely a matter of parameter passing.
Specifically, at ptype->func() time, it is plainly the skb->dev
before skb_bond() is applied.
So I added a "real_dev" arg to ptype->func() and converted
the tree over to that.
Thomas, this kills the TCF_META_ID_REALDEV stuff, so we sh
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Fri, 22 Jul 2005 01:49:51 +0200
> The pkt_type zero is not a valid one. We only use 1-4 and 0xff. So this
> can't be the problem. I assume that the cb is not copied from the driver
> into the core at some point.
All clones and copies of SKBs copy of
Hi Dave,
> > unfortunatly it is not that straight forward as I thought. The attached
> > patch which modifies the Bluetooth core and the hci_usb driver is not
> > working on my machine.
>
> This probably has nothing to do with why the patch doesn't
> work for you, but the transformation of "incom
From: Patrick McHardy <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 02:36:13 +0200
> ctnetlink needs large socket buffer sizes. To avoid increasing
> the system wide limit we would like to have something that allows
> CAP_NET_ADMIN to override these limits. The first idea was to
> change the SO_{SND,
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 23:42:11 +0200
> unfortunatly it is not that straight forward as I thought. The attached
> patch which modifies the Bluetooth core and the hci_usb driver is not
> working on my machine.
This probably has nothing to do with why the p
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 23:42:11 +0200
> unfortunatly it is not that straight forward as I thought. The attached
> patch which modifies the Bluetooth core and the hci_usb driver is not
> working on my machine.
Hmmm... I'll see if I can spot anything obviou
From: [EMAIL PROTECTED] (Arnaldo Carvalho de Melo)
Date: Wed, 20 Jul 2005 20:22:28 -0300
> + if (lopt->qlen != 0) {
> + struct request_sock *req;
> + int i;
> +
> + for (i = 0; i < lopt->nr_table_entries; i++)
> + while ((req = lopt->syn_
Hi Dave,
> > However after a look trough the Bluetooth core it should be quite
> > easy too move the pkt_type into the control buffer. We already use
> > it for a direction bit. The nasty thing is that I have to modify all
> > the drivers. So when you finally decided to shrink the pkt_type, I
> >
Hi,
I've noticed a difference between the IPv4 and IPv6 router alert
handling, which I think constitutes a bug.
For IPv4, you can bind a socket to an interface. If you use the
IP_ROUTER_ALERT sockopt then packets with router alert options are only
delivered to raw sockets bound to the incoming in
From: Marcel Holtmann <[EMAIL PROTECTED]>
Date: Thu, 21 Jul 2005 20:20:35 +0200
> However after a look trough the Bluetooth core it should be quite
> easy too move the pkt_type into the control buffer. We already use
> it for a direction bit. The nasty thing is that I have to modify all
> the driv
Jay Vosburgh wrote:
Jeff Garzik <[EMAIL PROTECTED]> wrote:
Jay Vosburgh wrote:
Reposting again; I'd like to see this in 2.6.13 as it contains
documentation for new features added for 2.6.13. If it's been applied
somewhere, I must not be looking in the right place.
It's queued in m
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>Jay Vosburgh wrote:
>> Reposting again; I'd like to see this in 2.6.13 as it contains
>> documentation for new features added for 2.6.13. If it's been applied
>> somewhere, I must not be looking in the right place.
>
>It's queued in my 'Pending for -rc
Jay Vosburgh wrote:
Reposting again; I'd like to see this in 2.6.13 as it contains
documentation for new features added for 2.6.13. If it's been applied
somewhere, I must not be looking in the right place.
It's queued in my 'Pending for -rc' folder, so all good.
Things will be quiet t
Hi Harald,
> I just ran into Marcel Holtmann earlier today. He thinks moving that
> data into the cb is fine, though he has to double-check that.
>
> He also said that he really only needs 5 bits, so even if the current
> pkt_type overloading would persist, we could probably shrink it to make
>
Arnaldo Carvalho de Melo wrote:
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -486,6 +486,8 @@ extern int sk_wait_data(struct sock *sk,
struct request_sock_ops;
+#undef SOCK_REFCNT_DEBUG
+
Why are you doing this here? Leftover from debugging?
-Brian
-
To unsubscribe from this li
Jesse Brandeburg wrote:
dropped: rnbc does not mean dropped, see above. mpc means dropped.
fifo: mpc means the fifo overflowed, and the packet was dropped (the
only time we drop).
missed: this should also be mpc because it shows we missed the packet.
Wow, thanks! So there we were reportin
27 matches
Mail list logo
