On Mon, Jul 02, 2007 at 09:52:26AM +0200, Jarek Poplawski wrote:
From my recent patch:
#1
Until kernel ver. 2.6.21 (including) cancel_rearming_delayed_work()
required a work function should always (unconditionally) rearm with
delay 0 - otherwise it would endlessly
From: Jarek Poplawski [EMAIL PROTECTED]
Date: Wed, 4 Jul 2007 08:41:59 +0200
On Mon, Jul 02, 2007 at 09:52:26AM +0200, Jarek Poplawski wrote:
From my recent patch:
#1
Until kernel ver. 2.6.21 (including) cancel_rearming_delayed_work()
required a work function should
On Tue, Jul 03, 2007 at 11:47:18PM -0700, David Miller wrote:
...
I plan to apply this patch, don't worry about it :)
Now I'm really worried! Don't you evere sleep?
Good night,
Jarek P.
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL
On Wed, Jul 04, 2007 at 08:41:59AM +0200, Jarek Poplawski wrote:
...
They were done on your request but it looks like Andrew
is waiting on something...
Andrew,
This time I'm not sorry for my English because I've just
found I could speak Chiefly Midland and Southern U.S..
Jarek P.
-
To
If I am correct, a TCP server can make up to
64K accepts for a port at a single IP-address.
If one would like to have e.g. 1M TCP connections
to a single IP-address of a powerful server (without load balancer),
how to make such setup?
There is a workaround to arrange several secondary
Hi,
I am trying to understand whether I can setup a skb destructor in my
code (which is basically a protocol above dev_queue_xmit() and co). From
what I see in many parts in the current kernel code, the protocol (I
mean, the one who actually creates the skb) may setup a destructor.
However, I
* Robert Iakobashvili:
If I am correct, a TCP server can make up to
64K accepts for a port at a single IP-address.
I don't think such a limit exists. In typical configurations, a
single client IP address can only establish a few tens of thousands of
TCP connections to one server port. But as
On Tue, Jul 03, 2007 at 11:58:40AM -0700, Andrew Morton wrote:
while (np-put_rx.orig != less_rx) {
- struct sk_buff *skb = dev_alloc_skb(np-rx_buf_sz +
NV_RX_ALLOC_PAD);
+ struct sk_buff *skb = dev_alloc_skb_node(np-rx_buf_sz +
NV_RX_ALLOC_PAD,
On Tue, 2007-07-03 at 19:38 +0800, Li Yang-r58472 wrote:
-Original Message-
From: Joakim Tjernlund [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 03, 2007 7:20 PM
To: Li Yang-r58472
Cc: linuxppc-dev Development; Netdev; Fleming Andy-afleming
Subject: RE: [PATCH] ucc_geth.c, make
On Tue, Jul 03, 2007 at 05:30:51PM -0700, Yinghai Lu wrote:
[PATCH 2/4] net: use numa_node in net_devcice-dev instead of parent
Signed-off-by: Yinghai Lu [EMAIL PROTECTED]
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 27cfe5f..005cc1c 100644
--- a/net/core/skbuff.c
+++
On Wed, Jul 04, 2007 at 10:04:54AM +0200, Brice Goglin ([EMAIL PROTECTED])
wrote:
So, I'd like to have a clear statement about who's allowed to use a
destructor :)
That one who allocates skb - if it is socket layer, it sets own
socket destructor, netlink has own too and so on.
Thanks,
Brice
On 7/4/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Wed, Jul 04, 2007 at 09:50:31AM +0200, Robert Iakobashvili ([EMAIL
PROTECTED]) wrote:
If I am correct, a TCP server can make up to
64K accepts for a port at a single IP-address.
No, it is essentially unlimited - linux uses local/remote
From: Miklos Szeredi [EMAIL PROTECTED]
Throw out the old mark sweep garbage collector and put in a
refcounting cycle detecting one.
The old one had a race with recvmsg, that resulted in false positives
and hence data loss. The old algorithm operated on all unix sockets
in the system, so any
On Wed, 4 Jul 2007 11:40:48 +0200
Robert Iakobashvili [EMAIL PROTECTED] wrote:
On 7/4/07, Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Wed, Jul 04, 2007 at 09:50:31AM +0200, Robert Iakobashvili ([EMAIL
PROTECTED]) wrote:
If I am correct, a TCP server can make up to
64K accepts for a
This patch introduces a capability flag that is used by the DLPAR userspace
tool to check which DLPAR features are supported by the eHEA driver.
Signed-off-by: Jan-Bernd Themann [EMAIL PROTECTED]
---
drivers/net/ehea/ehea.h |8 +++-
drivers/net/ehea/ehea_main.c | 17
This patch enables the receive side processing to aggregate TCP packets within
the HEA device driver. It analyses the packets already received after an
interrupt arrived and forwards these as chains of SKBs for the same TCP
connection with modified header field. We have seen a lower CPU load and
From: Satyam Sharma [EMAIL PROTECTED]
[9/9] netconsole: Support dynamic reconfiguration using configfs
This patch introduces support for dynamic reconfiguration (adding, removing
and/or modifying parameters of netconsole targets at runtime) using a
userspace interface exported via configfs.
From: Satyam Sharma [EMAIL PROTECTED]
[0/9] netconsole: Multiple targets and dynamic reconfigurability
This patchset is a rework of the original idea and patches posted by
Keiichi Kii and Takayoshi Kochi at: http://lkml.org/lkml/2007/6/13/72
[ I had initially thought about only modifying
From: Satyam Sharma [EMAIL PROTECTED]
[7/9] netconsole: Support multiple logging targets
This patch introduces support for multiple targets:
Let's keep this out of CONFIG_NETCONSOLE_DYNAMIC as well -- this is useful
even in the default case and (including the infrastructure introduced in
From: Satyam Sharma [EMAIL PROTECTED]
[3/9] netconsole: Introduce netconsole_target
Introduce a wrapper structure over netpoll to represent targets
configured in netconsole. This will get extended with other members in
further patches.
Ok, so the original patchset did this along with (and
From: Satyam Sharma [EMAIL PROTECTED]
[1/1] netpoll: Fix a leak-n-bug in netpoll_cleanup()
93ec2c723e3f8a216dde2899aeb85c648672bc6b applied excessive duct tape to
the netpoll beast's netpoll_cleanup(), thus substituting one leak with
another, and opening up a little buglet :-)
net_device-npinfo
From: Satyam Sharma [EMAIL PROTECTED]
[8/9] netconsole: Update documentation for dynamic reconfigurability
Add myself to parties interested in receiving bug reports, and give lots
of examples. Also fix some whitespace inconsistencies I introduced earlier.
Signed-off-by: Satyam Sharma [EMAIL
David Miller wrote:
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Wed, 4 Jul 2007 09:51:20 +0100
On Tue, Jul 03, 2007 at 05:30:51PM -0700, Yinghai Lu wrote:
...
struct sk_buff *__netdev_alloc_skb(struct net_device *dev,
unsigned int length, gfp_t gfp_mask)
{
- int node
On Tue, 2007-06-19 at 11:40 +0800, Zhang Rui wrote:
+/* attributes of acpi_genl_family */
+enum {
+ ACPI_GENL_ATTR_UNSPEC,
+ ACPI_GENL_ATTR_EVENT, /* ACPI event info needed by user space */
+ __ACPI_GENL_ATTR_MAX,
+};
+#define ACPI_GENL_ATTR_MAX (__ACPI_GENL_ATTR_MAX - 1)
+
Hey,
Looking through the code that uses NL_NONROOT_SEND I just realised that
it's impossible to send multicast messages from userspace to multicast
groups with IDs higher than 31. That's not really good given that
everywhere else we handle multicast groups up to 2^32-1 :/
Unfortunately, I
Patrick McHardy [EMAIL PROTECTED] writes:
It should create as many devices as necessary to operate (similar
to the loopback device) by default. Optional interfaces that are
used for addressing reasons should be manually added by the user
as needed. And it should not use module parameters for
Allow changing the number of groups for a netlink family
after it has been created, use RCU to protect the listeners
bitmap keeping netlink_has_listeners() lock-free.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
include/linux/netlink.h |1
net/netlink/af_netlink.c | 86
Hi Satyam,
At first, thank you for your helping.
I'm going to try/review your patches.
[ I had initially thought about only modifying Keiichi's patches to
incorporate the suggested stuff, sysfs+ioctl-configfs conversion, etc,
but the changes became too much and I ultimately ended up rewriting
On 21-06-2007 12:58, Mark Hannessen wrote:
Hi list,
I have some trouble getting my network card to run.
when I run dmesg I can clearly see it being detected
eth0: VIA Rhine II at 0xee006000, 00:e0:c5:54:88:a8, IRQ 11.
eth0: MII PHY found at address 1, status 0x786d advertising 05e1 Link
Hi Keiichi,
On Wed, 4 Jul 2007, Keiichi KII wrote:
[...]
At first, thank you for your helping.
I'm going to try/review your patches.
[ I had initially thought about only modifying Keiichi's patches to
incorporate the suggested stuff, sysfs+ioctl-configfs conversion, etc,
but the changes
On Tue, Jul 03, 2007 at 09:51:25PM +0200, Johannes Berg ([EMAIL PROTECTED])
wrote:
Does anybody have any better ideas?
Hi Johannes.
Why don't you want to reserve a set of bits in group number, which means
'allow to work with unpriveledged users', that bits should not cross existing
users
[ Some more thoughts I had on this, for those interested. ]
+#ifdef CONFIG_NETCONSOLE_DYNAMIC
+
+/*
+ * Targets that were created by parsing the boot/module option string
+ * do not exist in the configfs hierarchy and will never go away (and
+ * have zeroed-out config_item members).
{snip}
OK, but then a new property in PHY node is needed which holds
the initial speed and duplex.
initial-phy-capacity = speed duplex ?
This should be useful for real PHYs too if, for instance, autoneg
isn't
working/supported/wanted.
Maybe it should be:
initial-phy-capacity = speed
On Wed, 2007-04-07 at 09:49 +0530, Krishna Kumar2 wrote:
Do you see any contention for tx_lock which can justify having a prep
handler? As I understood, no other CPU can be in the xmit code at the
same time since RUNNING bit is held. Hence getting this lock early or
late should not matter for
Hi,
good catch.
Thanks
On Wednesday 04 July 2007 14:53, Akinobu Mita wrote:
2007/7/4, Jan-Bernd Themann [EMAIL PROTECTED]:
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index bdb5241..f8c0908 100644
--- a/drivers/net/ehea/ehea_main.c
+++
Hello,
I tried source routing with netcat just for my interest but it did
not work. tcpdump output follows:
00:07:40:53:bd:55 00:01:8e:b3:82:1c, ethertype IPv4 (0x0800),
length 86: (tos 0x0, ttl 64, id 50437, offset 0, flags [DF],
proto: TCP (6), length: 72, options (LSRR 172.27.129.2
On Wed, 2007-07-04 at 16:04 +0400, Evgeniy Polyakov wrote:
On Tue, Jul 03, 2007 at 09:51:25PM +0200, Johannes Berg ([EMAIL PROTECTED])
wrote:
Does anybody have any better ideas?
Why don't you want to reserve a set of bits in group number, which means
'allow to work with unpriveledged
On Wed, Jul 04, 2007 at 04:38:04PM +0530, Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[5/9] netconsole: Introduce dev_status member
Introduce a new member in netconsole_target that tracks the status (up or
down) of the underlying interface network device that the specific
How about separate autoneg to a property dumb-phy, which
indicates the
PHY/switch doesn't provide MII register interface.
Something like that I suppose. But don't call it dumb phy,
nor fake phy, nor anything similar -- there simply is _no_
phy. If the Linux code wants to pretend there is
On Wed, Jul 04, 2007 at 04:37:59PM +0530, Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[4/9] netconsole: Introduce netconsole_netdev_notifier
To update fields of underlying netpoll structure at runtime on
corresponding NETDEV_CHANGEADDR or NETDEV_CHANGENAME notifications.
On Wed, Jul 04, 2007 at 04:38:09PM +0530, Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[6/9] netconsole: Update documentation for multiple target support
... and add a few useful general purpose tips as well while we're at it.
The tips are fine and should go in their own
Urs Thuermann wrote:
Patrick McHardy [EMAIL PROTECTED] writes:
It should create as many devices as necessary to operate (similar
to the loopback device) by default. Optional interfaces that are
used for addressing reasons should be manually added by the user
as needed. And it should not use
On Wed, 2007-07-04 at 16:12 +0200, Patrick McHardy wrote:
Johannes Berg wrote:
Hey,
Looking through the code that uses NL_NONROOT_SEND I just realised that
it's impossible to send multicast messages from userspace to multicast
groups with IDs higher than 31. That's not really good
Johannes Berg wrote:
Hey,
Looking through the code that uses NL_NONROOT_SEND I just realised that
it's impossible to send multicast messages from userspace to multicast
groups with IDs higher than 31. That's not really good given that
everywhere else we handle multicast groups up to 2^32-1
Johannes Berg wrote:
On Wed, 2007-07-04 at 16:12 +0200, Patrick McHardy wrote:
Johannes Berg wrote:
Hey,
Looking through the code that uses NL_NONROOT_SEND I just realised that
it's impossible to send multicast messages from userspace to multicast
groups with IDs higher than 31. That's not
On Wed, 2007-07-04 at 16:30 +0200, Patrick McHardy wrote:
[...]
The kernel doesn't have any multicast listeners (yet).
Right.
I wonder if thats really a good idea to use multicast for device
configuration. Unicast transmissions from userspace to kernel
are reliable when you don't use
Allow kicking listeners out of a multicast group when necessary
(for example if that group is going to be removed.)
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
include/linux/netlink.h |1 +
net/netlink/af_netlink.c | 47 ++-
2 files
This is just a repost of the patches that I posted previously
because they were buried deeply in the ACPI thread and I'm
hoping that now other people will also take a look.
johannes
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
Allow changing the number of groups for a netlink family
after it has been created, use RCU to protect the listeners
bitmap keeping netlink_has_listeners() lock-free.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
include/linux/netlink.h |1
net/netlink/af_netlink.c | 86
Introduce API to dynamically register and unregister multicast groups.
Signed-off-by: Johannes Berg [EMAIL PROTECTED]
---
include/linux/genetlink.h | 13 +++
include/net/genetlink.h | 22 +
net/netlink/genetlink.c | 190 --
3 files
Johannes Berg wrote:
On Wed, 2007-07-04 at 16:30 +0200, Patrick McHardy wrote:
I wonder if thats really a good idea to use multicast for device
configuration. Unicast transmissions from userspace to kernel
are reliable when you don't use MSG_DONTWAIT. For multicasts
doing the same would mean
On Wed, 2007-07-04 at 16:48 +0200, Patrick McHardy wrote:
Yes, although in both cases you have no guarantee how long its
going to take, someone else could be flooding the receive queue.
For userspace this is more likely to be a real problem though
since the kernel will keep processing the
Johannes Berg wrote:
On Wed, 2007-07-04 at 16:48 +0200, Patrick McHardy wrote:
Yes, although in both cases you have no guarantee how long its
going to take, someone else could be flooding the receive queue.
For userspace this is more likely to be a real problem though
since the kernel will
On Wed, 2007-07-04 at 17:00 +0200, Patrick McHardy wrote:
Not by itself probably but a user could DoS your wireless connectivity
this way.
Hmm, if anything then not the connectivity but rather the MLME i.e. it
won't do roaming properly maybe. Maybe we should then have a way to say
that
On Wed, 4 Jul 2007, Matt Mackall wrote:
On Wed, Jul 04, 2007 at 04:38:04PM +0530, Satyam Sharma wrote:
[...]
+/*
+ * Why no net_dev_is_up() in netdevice.h? The kernel could lose a lot of
+ * weight if only netdevice.h had the good sense to export such a function.
+ * Oh well ...
+ */
On 7/4/07, David Miller [EMAIL PROTECTED] wrote:
From: Christoph Hellwig [EMAIL PROTECTED]
Date: Wed, 4 Jul 2007 09:51:20 +0100
On Tue, Jul 03, 2007 at 05:30:51PM -0700, Yinghai Lu wrote:
[PATCH 2/4] net: use numa_node in net_devcice-dev instead of parent
Signed-off-by: Yinghai Lu [EMAIL
On Wed, 2007-07-04 at 15:32 +0200, Segher Boessenkool wrote:
How about separate autoneg to a property dumb-phy, which
indicates the
PHY/switch doesn't provide MII register interface.
Something like that I suppose. But don't call it dumb phy,
nor fake phy, nor anything similar -- there
On 7/4/07, Christoph Hellwig [EMAIL PROTECTED] wrote:
On Tue, Jul 03, 2007 at 11:58:40AM -0700, Andrew Morton wrote:
while (np-put_rx.orig != less_rx) {
- struct sk_buff *skb = dev_alloc_skb(np-rx_buf_sz +
NV_RX_ALLOC_PAD);
+ struct sk_buff *skb =
On Wed, 4 Jul 2007, Matt Mackall wrote:
On Wed, Jul 04, 2007 at 04:37:49PM +0530, Satyam Sharma wrote:
[...]
(2) With this change, option_setup() is not required for modular netconsole.
How is this a simplification? You've taken code with no #ifdefs and
added one! Please have both modular
On Wed, 4 Jul 2007, Matt Mackall wrote:
On Wed, Jul 04, 2007 at 04:37:59PM +0530, Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[4/9] netconsole: Introduce netconsole_netdev_notifier
To update fields of underlying netpoll structure at runtime on
corresponding
Hello,
I got Oops like below. I glanced xfrm_bundle_ok() in
xfrm_policy.c and __xfrm4.bundle_create() in xfrm4_policy.c.
In __xfrm4.bundle_create(), xfrm_dst-next may be null but
in xfrm_bundle_ok(), later loop does not check null, only break
`if (last == first)'.
I tried to solve with only
Hi Matt,
On Wed, 4 Jul 2007, Matt Mackall wrote:
On Wed, Jul 04, 2007 at 04:38:09PM +0530, Satyam Sharma wrote:
From: Satyam Sharma [EMAIL PROTECTED]
[6/9] netconsole: Update documentation for multiple target support
... and add a few useful general purpose tips as well while we're
On Wed, Jul 04, 2007 at 05:47:51PM +0200, Patrick McHardy wrote:
This is an updated version of the gen_estimator fix
that relies on all changes happening under the rtnl
and just fixes the race between timer rearming and
timer removal.
[NET]: Fix gen_estimator timer removal race
As
63 matches
Mail list logo
