* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: David Miller @ 2009-09-05 7:27 UTC (permalink / raw)
To: kaber; +Cc: netdev
In-Reply-To: <20090904164111.27300.29929.sendpatchset@x2.localnet>
From: Patrick McHardy <kaber@trash.net>
Date: Fri, 4 Sep 2009 18:41:12 +0200 (MEST)
> Any comments and test results welcome :)
This looks really nice. I have them already checked into my
local net-next-2.6 tree and will push them out after I do
some multiqueue testing with NIU.
Thanks!
^ permalink raw reply
* Re: [PATCH] WAN: remove deprecated PCI_DEVICE_ID from PCI200SYN driver.
From: David Miller @ 2009-09-05 6:07 UTC (permalink / raw)
To: khc; +Cc: netdev
In-Reply-To: <m363byk3af.fsf@intrepid.localdomain>
From: Krzysztof Halasa <khc@pm.waw.pl>
Date: Fri, 04 Sep 2009 19:50:16 +0200
> PCI200SYN has its own PCI subsystem device ID for 3+ years, now it's
> time to remove the generic PLX905[02] ID from the driver. Anyone with
> old EEPROM data will have to run the upgrade.
>
> Having the generic PLX905[02] (PCI-local bus bridge) ID is harmful
> as the driver tries to handle other devices based on these bridges.
Please provide a proper signoff with all patches.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: Marcel Holtmann @ 2009-09-05 5:55 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, davem, johannes
In-Reply-To: <20090904214903.49e5a361@nehalam>
Hi Stephen,
> > The Ethernet framing is used for a lot of devices these days. Most
> > prominent are WiFi and WiMAX based devices. However for userspace
> > application it is important to classify these devices correctly and
> > not only see them as Ethernet devices. The daemons like HAL, DeviceKit
> > or even NetworkManager with udev support tries to do the classification
> > in userspace with a lot trickery and extra system calls. This is not
> > good and actually reaches its limitations. Especially since the kernel
> > does know the type of the Ethernet device it is pretty stupid.
> >
> > To solve this problem the underlying device type needs to be set and
> > then the value will be exported as DEVTYPE via uevents and available
> > within udev.
> >
> > # cat /sys/class/net/wlan0/uevent
> > DEVTYPE=wlan
> > INTERFACE=wlan0
> > IFINDEX=5
> >
>
> The problem with your idea is that there is only a nebulous definition of
> what is a Wifi device, and what is a WiMAX device etc. What userspace should be looking
> for is "does device XXX support API yyy?" and if it supports API
> yyy then I it can be configured that way.
We don't need that. We just need to know what technology is behind that
Ethernet device. Otherwise we have no real starting point.
> There already is some information in sysfs like /sys/class/net/XXX/type
> which gives the hardware type (ARPHRD_ETHER, etc). Why not a better version
> of something like this that provides "can do FOO" interface?
that was my initial idea, but I couldn't come up with something good.
And the DEVTYPE from struct device is a standard way of exposing such
information. Actually subsystem like SCSI, USB, Bluetooth etc. use that
already. So why not do the same for Ethernet based devices.
> Doing a several system calls (open/read/close) per device is not a big
> issue. Even an android phone can do open/read/close in less than a millisecond
> I bet.
It is not only the system calls that userspace has to do. There is no
central place for this stuff and why should be do it all if the kernel
already has all the details.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: David Miller @ 2009-09-05 5:55 UTC (permalink / raw)
To: marcel; +Cc: netdev, shemminger, johannes
In-Reply-To: <1252129940.27694.9.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 05 Sep 2009 07:52:20 +0200
>> > What is ugly about it. Do you have any other recommendation on how let
>> > userspace know what type of Ethernet device it is?
>>
>> Well, for one thing, you're wasting 48 bytes on 64-bit when all you're
>> really intrested in is one string.
>
> the integration with struct device has plenty of other advantages
Ok, this I agree with.
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: Marcel Holtmann @ 2009-09-05 5:52 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, johannes
In-Reply-To: <20090904.214615.198838334.davem@davemloft.net>
Hi David,
> > What is ugly about it. Do you have any other recommendation on how let
> > userspace know what type of Ethernet device it is?
>
> Well, for one thing, you're wasting 48 bytes on 64-bit when all you're
> really intrested in is one string.
the integration with struct device has plenty of other advantages. You
could use all the sysfs magic from it. For example in the next step the
hacking of some sysfs directories can be moved into the subsystem itself
and could be moved out of the core. Wireless would be one of them were
we would benefit here.
> Also, you didn't setup an assignment for plain ethernet devices,
> you just handle the non-traditional devices that do ethernet
> framing. Is this intentional?
For now it is. Mainly since some non plain Ethernet devices are using
alloc_etherdev instead of just alloc_netdev. So I would have to do some
extra work. I have planned it, but not gotten around it yet.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: Stephen Hemminger @ 2009-09-05 4:49 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: netdev, davem, johannes
In-Reply-To: <1251788899-30156-1-git-send-email-marcel@holtmann.org>
On Tue, 1 Sep 2009 00:08:19 -0700
Marcel Holtmann <marcel@holtmann.org> wrote:
> The Ethernet framing is used for a lot of devices these days. Most
> prominent are WiFi and WiMAX based devices. However for userspace
> application it is important to classify these devices correctly and
> not only see them as Ethernet devices. The daemons like HAL, DeviceKit
> or even NetworkManager with udev support tries to do the classification
> in userspace with a lot trickery and extra system calls. This is not
> good and actually reaches its limitations. Especially since the kernel
> does know the type of the Ethernet device it is pretty stupid.
>
> To solve this problem the underlying device type needs to be set and
> then the value will be exported as DEVTYPE via uevents and available
> within udev.
>
> # cat /sys/class/net/wlan0/uevent
> DEVTYPE=wlan
> INTERFACE=wlan0
> IFINDEX=5
>
The problem with your idea is that there is only a nebulous definition of
what is a Wifi device, and what is a WiMAX device etc. What userspace should be looking
for is "does device XXX support API yyy?" and if it supports API
yyy then I it can be configured that way.
There already is some information in sysfs like /sys/class/net/XXX/type
which gives the hardware type (ARPHRD_ETHER, etc). Why not a better version
of something like this that provides "can do FOO" interface?
Doing a several system calls (open/read/close) per device is not a big
issue. Even an android phone can do open/read/close in less than a millisecond
I bet.
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: David Miller @ 2009-09-05 4:46 UTC (permalink / raw)
To: marcel; +Cc: netdev, shemminger, johannes
In-Reply-To: <1252125240.27694.5.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 05 Sep 2009 06:34:00 +0200
> What is ugly about it. Do you have any other recommendation on how let
> userspace know what type of Ethernet device it is?
Well, for one thing, you're wasting 48 bytes on 64-bit when all you're
really intrested in is one string.
Also, you didn't setup an assignment for plain ethernet devices,
you just handle the non-traditional devices that do ethernet
framing. Is this intentional?
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: Marcel Holtmann @ 2009-09-05 4:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shemminger, johannes
In-Reply-To: <20090904.202750.249172306.davem@davemloft.net>
Hi Dave,
> > can you please give me some feedback on this patch.
>
> Johannes recommended using a NETDEV_REGISTER hook, I'm
> waiting for you to try and use that instead of this
> patch.
that was for the Wireless drivers part. Total different from what this
patch trying to achieve.
> Your patch is ugly, so I'd like to avoid it if possible.
What is ugly about it. Do you have any other recommendation on how let
userspace know what type of Ethernet device it is?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] netlink: silence compiler warning
From: David Miller @ 2009-09-05 3:33 UTC (permalink / raw)
To: brian.haley; +Cc: marcel, netdev
In-Reply-To: <4AA1C086.5000607@hp.com>
From: Brian Haley <brian.haley@hp.com>
Date: Fri, 04 Sep 2009 21:36:06 -0400
> Hi Marcel,
>
> Marcel Holtmann wrote:
>> can we please add the err = -E... where it actually is needed and not
>> stupidly go ahead and silence compiler warnings with err = 0. This has
>> been posted before.
>
> Sorry, I don't remember it being posted before. If you look at the code
> though, err is correctly initialized, gcc just can't figure it out. The
> choices I see are either what I originally posted, using uninitialized_var(err),
> or the patch below. It doesn't matter to me.
uninitialized_var() would be absolutely wrong here, as then we'd
return garbage if such a path were actually possible.
Your original patch was fine and I'm going to apply it, thanks.
^ permalink raw reply
* Re: [PATCH] netlink: silence compiler warning
From: David Miller @ 2009-09-05 3:32 UTC (permalink / raw)
To: marcel; +Cc: brian.haley, netdev
In-Reply-To: <1252112881.27694.3.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 05 Sep 2009 03:08:01 +0200
> can we please add the err = -E... where it actually is needed and not
> stupidly go ahead and silence compiler warnings with err = 0. This has
> been posted before.
Ummm, no. Actually Brian's patch is correct.
I can't even prove that there are no paths where err won't
be initialized properly to something.
And if such an occurance happens, returning "0" is absolutely
the right thing to do.
And that's what Brian's patch does.
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: David Miller @ 2009-09-05 3:27 UTC (permalink / raw)
To: marcel; +Cc: netdev, shemminger, johannes
In-Reply-To: <1252109846.27694.1.camel@violet>
From: Marcel Holtmann <marcel@holtmann.org>
Date: Sat, 05 Sep 2009 02:17:26 +0200
> can you please give me some feedback on this patch.
Johannes recommended using a NETDEV_REGISTER hook, I'm
waiting for you to try and use that instead of this
patch.
Your patch is ugly, so I'd like to avoid it if possible.
^ permalink raw reply
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: Stephen Hemminger @ 2009-09-05 2:38 UTC (permalink / raw)
To: Krzysztof Halasa; +Cc: David Miller, sfr, linux-next, netdev
In-Reply-To: <m31vmmk0kt.fsf@intrepid.localdomain>
On Fri, 04 Sep 2009 20:48:50 +0200
Krzysztof Halasa <khc@pm.waw.pl> wrote:
> Stephen Hemminger <shemminger@vyatta.com> writes:
>
> > This is a brute force removal of the wierd slave interface done for
> > DLCI -> SDLA transmit. Before it was using non-standard return values
> > and freeing skb in caller. This changes it to using normal return
> > values, and freeing in the callee. Luckly only one driver pair was
> > doing this. Not tested on real hardware, in fact I wonder if this
> > driver pair is even being used by any users.
>
> The only hardware which seems to be driven by dlci.c is sdla.c =
> old Sangoma ISA cards.
>
> Sangoma seems to maintain their own drivers for their hw (including
> these ISA cards).
>
> Are the in-kernel drivers functional after all those years? I don't
> know.
In the Vyatta product we use the Sangoma drivers, so we actually have
to make and not configure in the existing WAN drivers.
--
^ permalink raw reply
* [PATCH] ipv6: Add IFA_F_DADFAILED flag
From: Brian Haley @ 2009-09-05 1:38 UTC (permalink / raw)
To: david Miller; +Cc: netdev@vger.kernel.org, YOSHIFUJI Hideaki
[Note: if this is accepted I'll send out a patch for iproute,
if you'd prefer to not use the last ifa_flag I'll send a
much larger patch that does this differently :) ]
Add IFA_F_DADFAILED flag to denote an IPv6 address that has
failed Duplicate Address Detection, that way tools like
/sbin/ip can be more informative.
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
inet6 2001:db8::1/64 scope global tentative dadfailed
valid_lft forever preferred_lft forever
Signed-off-by: Brian Haley <brian.haley@hp.com>
---
diff --git a/include/linux/if_addr.h b/include/linux/if_addr.h
index a60c821..fd97404 100644
--- a/include/linux/if_addr.h
+++ b/include/linux/if_addr.h
@@ -41,6 +41,7 @@ enum
#define IFA_F_NODAD 0x02
#define IFA_F_OPTIMISTIC 0x04
+#define IFA_F_DADFAILED 0x08
#define IFA_F_HOMEADDRESS 0x10
#define IFA_F_DEPRECATED 0x20
#define IFA_F_TENTATIVE 0x40
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index 43b3c9f..6532966 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -1376,7 +1376,7 @@ static void addrconf_dad_stop(struct inet6_ifaddr *ifp)
if (ifp->flags&IFA_F_PERMANENT) {
spin_lock_bh(&ifp->lock);
addrconf_del_timer(ifp);
- ifp->flags |= IFA_F_TENTATIVE;
+ ifp->flags |= IFA_F_DADFAILED;
spin_unlock_bh(&ifp->lock);
in6_ifa_put(ifp);
#ifdef CONFIG_IPV6_PRIVACY
^ permalink raw reply related
* Re: [PATCH] netlink: silence compiler warning
From: Brian Haley @ 2009-09-05 1:36 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <1252112881.27694.3.camel@violet>
Hi Marcel,
Marcel Holtmann wrote:
> can we please add the err = -E... where it actually is needed and not
> stupidly go ahead and silence compiler warnings with err = 0. This has
> been posted before.
Sorry, I don't remember it being posted before. If you look at the code
though, err is correctly initialized, gcc just can't figure it out. The
choices I see are either what I originally posted, using uninitialized_var(err),
or the patch below. It doesn't matter to me.
-Brian
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 66f6ba0..8741036 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -177,6 +177,7 @@ int genl_register_mc_group(struct genl_family *family,
struct net *net;
rcu_read_lock();
+ err = 0;
for_each_net_rcu(net) {
err = netlink_change_ngroups(net->genl_sock,
mc_groups_longs * BITS_PER_LONG);
^ permalink raw reply related
* Re: [PATCH] netlink: silence compiler warning
From: Marcel Holtmann @ 2009-09-05 1:08 UTC (permalink / raw)
To: Brian Haley; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <4AA1B712.6060900@hp.com>
Hi Brian,
> CC net/netlink/genetlink.o
> net/netlink/genetlink.c: In function ‘genl_register_mc_group’:
> net/netlink/genetlink.c:139: warning: ‘err’ may be used uninitialized in this function
>
> From following the code 'err' is initialized, but set it to zero to
> silence the warning.
>
> Signed-off-by: Brian Haley <brian.haley@hp.com>
> ---
>
> diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
> index 575c643..66f6ba0 100644
> --- a/net/netlink/genetlink.c
> +++ b/net/netlink/genetlink.c
> @@ -136,7 +136,7 @@ int genl_register_mc_group(struct genl_family *family,
> {
> int id;
> unsigned long *new_groups;
> - int err;
> + int err = 0;
>
> BUG_ON(grp->name[0] == '\0');
can we please add the err = -E... where it actually is needed and not
stupidly go ahead and silence compiler warnings with err = 0. This has
been posted before.
Regards
Marcel
^ permalink raw reply
* [PATCH] netlink: silence compiler warning
From: Brian Haley @ 2009-09-05 0:55 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org
CC net/netlink/genetlink.o
net/netlink/genetlink.c: In function ‘genl_register_mc_group’:
net/netlink/genetlink.c:139: warning: ‘err’ may be used uninitialized in this function
From following the code 'err' is initialized, but set it to zero to
silence the warning.
Signed-off-by: Brian Haley <brian.haley@hp.com>
---
diff --git a/net/netlink/genetlink.c b/net/netlink/genetlink.c
index 575c643..66f6ba0 100644
--- a/net/netlink/genetlink.c
+++ b/net/netlink/genetlink.c
@@ -136,7 +136,7 @@ int genl_register_mc_group(struct genl_family *family,
{
int id;
unsigned long *new_groups;
- int err;
+ int err = 0;
BUG_ON(grp->name[0] == '\0');
^ permalink raw reply related
* [PATCH] net: fix hydra printk format warning
From: Randy Dunlap @ 2009-09-05 0:20 UTC (permalink / raw)
To: linux-m68k, netdev; +Cc: Geert Uytterhoeven, Roman Zippel, davem
From: Randy Dunlap <randy.dunlap@oracle.com>
m68k:
drivers/net/hydra.c:178: warning: format '%08lx' expects type 'long unsigned int', but argument 3 has type 'resource_size_t'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
---
drivers/net/hydra.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-2.6.31-rc8-git1.orig/drivers/net/hydra.c
+++ linux-2.6.31-rc8-git1/drivers/net/hydra.c
@@ -173,9 +173,9 @@ static int __devinit hydra_init(struct z
zorro_set_drvdata(z, dev);
- printk(KERN_INFO "%s: Hydra at 0x%08lx, address "
+ printk(KERN_INFO "%s: Hydra at 0x%08llx, address "
"%pM (hydra.c " HYDRA_VERSION ")\n",
- dev->name, z->resource.start, dev->dev_addr);
+ dev->name, (unsigned long long)z->resource.start, dev->dev_addr);
return 0;
}
---
~Randy
LPC 2009, Sept. 23-25, Portland, Oregon
http://linuxplumbersconf.org/2009/
^ permalink raw reply
* Re: [PATCH] net: Add DEVTYPE support for Ethernet based devices
From: Marcel Holtmann @ 2009-09-05 0:17 UTC (permalink / raw)
To: netdev; +Cc: davem, shemminger, johannes
In-Reply-To: <1251788899-30156-1-git-send-email-marcel@holtmann.org>
Hi Dave,
> The Ethernet framing is used for a lot of devices these days. Most
> prominent are WiFi and WiMAX based devices. However for userspace
> application it is important to classify these devices correctly and
> not only see them as Ethernet devices. The daemons like HAL, DeviceKit
> or even NetworkManager with udev support tries to do the classification
> in userspace with a lot trickery and extra system calls. This is not
> good and actually reaches its limitations. Especially since the kernel
> does know the type of the Ethernet device it is pretty stupid.
>
> To solve this problem the underlying device type needs to be set and
> then the value will be exported as DEVTYPE via uevents and available
> within udev.
>
> # cat /sys/class/net/wlan0/uevent
> DEVTYPE=wlan
> INTERFACE=wlan0
> IFINDEX=5
>
> This is similar to subsystems like USB and SCSI that distinguish
> between hosts, devices, disks, partitions etc.
>
> The new SET_NETDEV_DEVTYPE() is a convenience helper to set the actual
> device type. All device types are free form, but for convenience the
> same strings as used with RFKILL are choosen.
can you please give me some feedback on this patch.
Regards
Marcel
^ permalink raw reply
* Re: pull request: SCTP updates for net-next-2.6
From: David Miller @ 2009-09-04 22:58 UTC (permalink / raw)
To: vladislav.yasevich; +Cc: netdev, linux-sctp, lksctp-developers
In-Reply-To: <4AA1959A.30400@hp.com>
From: Vlad Yasevich <vladislav.yasevich@hp.com>
Date: Fri, 04 Sep 2009 18:32:58 -0400
> Here is an accumulated set of SCTP patches for net-next. It's a collection
> of bug fixes and some new features.
>
> Please let me know if there any problems.
Pulled, thanks a lot Vlad!
^ permalink raw reply
* Re: [PATCH] forcedeth: updated phy errata
From: David Miller @ 2009-09-04 22:54 UTC (permalink / raw)
To: aabdulla; +Cc: manfred, akpm, netdev
In-Reply-To: <4AA14CBE.8000402@nvidia.com>
From: Ayaz Abdulla <aabdulla@nvidia.com>
Date: Fri, 04 Sep 2009 13:22:06 -0400
> Phy vendors have said "No" in the past. I can request for 'opening up'
> the bits again, but not all vendors will comply - resulting in no
> support for forcedeth. This is currently the only way to provide a
> good experience for the end user.
If I make it more difficult for you to get you're patch into the tree
than to get permission from the vendor, I'm sure you'll find a way to
make it happen.
^ permalink raw reply
* Re: [PATCH] forcedeth: updated phy errata
From: Ayaz Abdulla @ 2009-09-04 17:22 UTC (permalink / raw)
To: David Miller
Cc: manfred@colorfullife.com, akpm@osdl.org, netdev@vger.kernel.org
In-Reply-To: <20090904.150015.247320928.davem@davemloft.net>
David Miller wrote:
> From: Ayaz Abdulla <aabdulla@nvidia.com>
> Date: Fri, 04 Sep 2009 09:57:59 -0400
>
>
>>Unfortunately, the phy vendors don't want us exposing the meaning of
>>their non-standard bits.
>
>
> So when you go away and some other developer tries to debug a problem
> in this area, then what happens? Do they just guess what those bits
> mean?
I understand your concern. However, NVIDIA will always be the maintainer
for these phy erratas and work with users to solve any issues. We have
access to the confidential documents provided by the vendors.
Phy vendors have said "No" in the past. I can request for 'opening up'
the bits again, but not all vendors will comply - resulting in no
support for forcedeth. This is currently the only way to provide a good
experience for the end user.
>
> Sorry, this sort of situation is unacceptable in this modern day and
> age. You'll need to work this out before I'm willing to take the
> patch.
^ permalink raw reply
* pull request: SCTP updates for net-next-2.6
From: Vlad Yasevich @ 2009-09-04 22:32 UTC (permalink / raw)
To: David Miller
Cc: netdev, Linux SCTP Dev Mailing list,
lksctp-developers@lists.sourceforge.net
Hi David
Here is an accumulated set of SCTP patches for net-next. It's a collection
of bug fixes and some new features.
Please let me know if there any problems.
Thanks
-vlad
--
The following changes since commit 8a34e2f8ba7d4302977c90e357921994a6c39af9:
Sachin Sant (1):
net: Fix a build break because of a typo in drivers/net/3c503.c
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/vxy/lksctp-dev.git net-next
Alexey Dobriyan (1):
sctp: use proc_create()
Bhaskar Dutta (1):
sctp: Sysctl configuration for IPv4 Address Scoping
Doug Graham (1):
sctp: Fix piggybacked ACKs
Rami Rosen (1):
sctp: remove unused union (sctp_cmsg_data_t) definition
Vlad Yasevich (18):
sctp: release cached route when the transport goes down.
sctp: Disallow new connection on a closing socket
sctp: Fix data segmentation with small frag_size
sctp: Generate SACKs when actually sending outbound DATA
sctp: Try to encourage SACK bundling with DATA.
sctp: Send user messages to the lower layer as one
sctp: Fix error count increments that were results of HEARTBEATS
sctp: Clear fast_recovery on the transport when T3 timer expires.
sctp: drop a_rwnd to 0 when receive buffer overflows.
sctp: Try not to change a_rwnd when faking a SACK from SHUTDOWN.
sctp: Nagle delay should be based on path mtu
sctp: Don't do NAGLE delay on large writes that were fragmented small
sctp: Fix SCTP_MAXSEG socket option to comply to spec.
sctp: Failover transmitted list on transport delete
sctp: Correctly track if AUTH has been bundled.
sctp: Turn flags in 'sctp_packet' into bit fields
sctp: Get rid of an extra routing lookup when adding a transport.
sctp: Catch bogus stream sequence numbers
Wei Yongjun (8):
sctp: avoid overwrite the return value of sctp_process_asconf_ack()
sctp: check the unrecognized ASCONF parameter before access it
sctp: update the route for non-active transports after addresses are added
sctp: drop SHUTDOWN chunk if the TSN is less than the CTSN
sctp: fix check the chunk length of received HEARTBEAT-ACK chunk
sctp: fix to reset packet information after packet transmit
sctp: turn flags in 'struct sctp_association' into bit fields
sctp: remove dup code in net/sctp/output.c
Documentation/networking/ip-sysctl.txt | 10 ++
include/net/sctp/command.h | 3 +
include/net/sctp/constants.h | 9 ++-
include/net/sctp/sctp.h | 7 +-
include/net/sctp/structs.h | 63 ++++++-----
include/net/sctp/user.h | 6 -
net/sctp/associola.c | 93 ++++++++++++++--
net/sctp/bind_addr.c | 21 ++++-
net/sctp/chunk.c | 62 +++++++++--
net/sctp/output.c | 188 +++++++++++++++++++-------------
net/sctp/outqueue.c | 47 ++++++--
net/sctp/proc.c | 4 +-
net/sctp/protocol.c | 11 +-
net/sctp/sm_make_chunk.c | 25 +++--
net/sctp/sm_sideeffect.c | 56 ++++++++--
net/sctp/sm_statefuns.c | 68 ++++++++++-
net/sctp/socket.c | 38 +++----
net/sctp/sysctl.c | 12 ++
net/sctp/transport.c | 3 +
19 files changed, 519 insertions(+), 207 deletions(-)
^ permalink raw reply
* Re: [PATCH] forcedeth: updated phy errata
From: David Miller @ 2009-09-04 22:00 UTC (permalink / raw)
To: aabdulla; +Cc: manfred, akpm, netdev
In-Reply-To: <4AA11CE7.7050400@nvidia.com>
From: Ayaz Abdulla <aabdulla@nvidia.com>
Date: Fri, 04 Sep 2009 09:57:59 -0400
> Unfortunately, the phy vendors don't want us exposing the meaning of
> their non-standard bits.
So when you go away and some other developer tries to debug a problem
in this area, then what happens? Do they just guess what those bits
mean?
Sorry, this sort of situation is unacceptable in this modern day and
age. You'll need to work this out before I'm willing to take the
patch.
^ permalink raw reply
* Contact the national sec oxfam with Name,Age,Occuptaion,Nationality ,Country,Gender,Tel Number to redeem your donations sum of £250,000GBPounds from oxfam grant donation center
From: OXFAM GB @ 2009-09-04 20:31 UTC (permalink / raw)
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Paul E. McKenney @ 2009-09-04 20:43 UTC (permalink / raw)
To: Christoph Lameter
Cc: Eric Dumazet, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <alpine.DEB.1.10.0909041140040.9781@V090114053VZO-1>
On Fri, Sep 04, 2009 at 11:42:17AM -0400, Christoph Lameter wrote:
> On Thu, 3 Sep 2009, Paul E. McKenney wrote:
>
> > If it were the user of the slab who was invoking some variant of
> > call_rcu(), then I would agree with you.
>
> The user already has to deal with it as explained by Eric.
I didn't read his email that way. Perhaps I misinterpreted it.
> > However, call_rcu() is instead being invoked by the slab itself in the
> > case of SLAB_DESTROY_BY_RCU, so that there is no variation in usage.
> > Requiring that the user call rcu_barrier() is asking for subtle bugs.
> > Therefore, the best approach is to have kmem_cache_destroy() handle
> > the RCU cleanup, given that this cleanup is for actions taken by
> > kmem_cache_free(), not by the user.
>
> The user already has to properly handle barriers and rcu logic in order to
> use objects handled with RCU properly. Moreover the user even has to check
> that the object is not suddenly checked under it. Its already complex.
mm/slab.c has had RCU calls since 2.6.9, so this is not new.
> Guess we are doing this ... Sigh. Are you going to add support other rcu
> versions to slab as well as time permits and as the need arises? Should
> we add you as a maintainer? ;-)
I don't see any point in adding anything resembling SLAB_DESTROY_BY_RCU_BH,
SLAB_DESTROY_BY_RCU_SCHED, or SLAB_DESTROY_BY_SRCU unless and until
someone needs it. And I most especially don't see the point of adding
(say) SLAB_DESTROY_BY_RCU_BH_SCHED until someone convinces me of the
need for it. I would prefer to put the energy into further streamlining
the underlying RCU implementation, maybe someday collapsing RCU-BH back
into RCU. ;-)
We have gotten along fine with only SLAB_DESTROY_BY_RCU for almost
five years, so I think we are plenty fine with what we have. So, as
you say, "as the need arises".
I don't see any more need to add me as maintainer of slab and friends
than of btrfs, netfilter, selinux, decnet, afs, wireless, or any of a
number of other subsystems that use RCU.
Thanx, Paul
^ 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