* 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
* Re: [PATCH] slub: fix slab_pad_check()
From: Paul E. McKenney @ 2009-09-04 20:42 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Lameter, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <4AA0407E.8030505@gmail.com>
On Fri, Sep 04, 2009 at 12:17:34AM +0200, Eric Dumazet wrote:
> Eric Dumazet a écrit :
> >
> >
> >
> > Problem is not _objects_ Christoph, but _slabs_, and your patch is not working.
> >
> > Its true that when User calls kmem_cache_destroy(), all _objects_ were previously freed.
> > This is mandatory, with or withou SLAB_DESTROY_BY_RCU thing
> >
> > Problem is that slub has some internal state, including some to-be-freed _slabs_,
> > that User have no control at all on it.
> >
> > User cannot "know" slabs are freed, inuse, or whatever state in cache or call_rcu queues.
> >
> > Face it, SLAB_DESTROY_BY_RCU is internal affair (to slub/slab/... allocators)
> >
> > We absolutely need a rcu_barrier() somewhere, believe it or not. You can argue that it should
> > be done *before*, but it gives no speedup, only potential bugs.
> >
> > Only case User should do its rcu_barrier() itself is if it knows some call_rcu() are pending
> > and are delaying _objects_ freeing (typical !SLAB_DESTROY_RCU usage in RCU algos).
> >
> > I dont even understand why you care so much about kmem_cache_destroy(SLAB_DESTROY_BY_RCU),
> > given that almost nobody use it. We took almost one month to find out what the bug was in first
> > place...
>
>
> So maybe the safest thing would be to include the rcu_barrier() to
> insure all objects where freed
I argue that the above is the user's responsibility. That said, I don't
see why the user would pass a SLAB_DESTROY_BY_RCU object to call_rcu().
So I would want to see an example of this before inflicting a pair
of rcu_barrier() calls on kmem_cache_destroy().
> And another one for SLAB_DESTROY_BY_RCU to make sure slabs where freed
This last is I believe kmem_cache's responsibility.
Thanx, Paul
> void kmem_cache_destroy(struct kmem_cache *s)
> {
> /*
> * Make sure no objects are waiting in call_rcu queues to be freed
> */
> rcu_barrier();
>
> down_write(&slub_lock);
> s->refcount--;
> if (!s->refcount) {
> list_del(&s->list);
> up_write(&slub_lock);
> if (kmem_cache_close(s)) {
> printk(KERN_ERR "SLUB %s: %s called for cache that "
> "still has objects.\n", s->name, __func__);
> dump_stack();
> }
> /*
> * Make sure no slabs are waiting in call_rcu queues to be freed
> */
> if (s->flags & SLAB_DESTROY_BY_RCU)
> rcu_barrier();
> sysfs_slab_remove(s);
> } else
> up_write(&slub_lock);
> }
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 24/29] fsldma: implement a private tx_list
From: Dan Williams @ 2009-09-04 19:42 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-raid, netdev, Li Yang, maciej.sosnowski, Ira Snyder
In-Reply-To: <20090904023232.32667.58041.stgit@dwillia2-linux.ch.intel.com>
[-- Attachment #1: Type: text/plain, Size: 521 bytes --]
On Thu, Sep 3, 2009 at 7:32 PM, Dan Williams<dan.j.williams@intel.com> wrote:
> Drop fsldma's use of tx_list from struct dma_async_tx_descriptor in
> preparation for removal of this field.
>
> Cc: Li Yang <leoli@freescale.com>
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
As I merged the pending fsldma queue with this patch I noticed that
this missed a tx_list conversion in fsl_dma_tx_submit(). New patch
attached. I also fixed up the pending dma-slave support for fsldma
(attached).
Regards,
Dan
[-- Attachment #2: fsldma-local-tx-list.patch --]
[-- Type: text/x-diff, Size: 3396 bytes --]
fsldma: implement a private tx_list
From: Dan Williams <dan.j.williams@intel.com>
Drop fsldma's use of tx_list from struct dma_async_tx_descriptor in
preparation for removal of this field.
Cc: Li Yang <leoli@freescale.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/dma/fsldma.c | 16 +++++++++-------
drivers/dma/fsldma.h | 1 +
2 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index ef87a89..73dd748 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -326,7 +326,8 @@ static void fsl_chan_toggle_ext_start(struct fsl_dma_chan *fsl_chan, int enable)
static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
{
struct fsl_dma_chan *fsl_chan = to_fsl_chan(tx->chan);
- struct fsl_desc_sw *desc;
+ struct fsl_desc_sw *desc = tx_to_fsl_desc(tx);
+ struct fsl_desc_sw *child;
unsigned long flags;
dma_cookie_t cookie;
@@ -334,7 +335,7 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
spin_lock_irqsave(&fsl_chan->desc_lock, flags);
cookie = fsl_chan->common.cookie;
- list_for_each_entry(desc, &tx->tx_list, node) {
+ list_for_each_entry(child, &desc->tx_list, node) {
cookie++;
if (cookie < 0)
cookie = 1;
@@ -343,8 +344,8 @@ static dma_cookie_t fsl_dma_tx_submit(struct dma_async_tx_descriptor *tx)
}
fsl_chan->common.cookie = cookie;
- append_ld_queue(fsl_chan, tx_to_fsl_desc(tx));
- list_splice_init(&tx->tx_list, fsl_chan->ld_queue.prev);
+ append_ld_queue(fsl_chan, desc);
+ list_splice_init(&desc->tx_list, fsl_chan->ld_queue.prev);
spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
@@ -366,6 +367,7 @@ static struct fsl_desc_sw *fsl_dma_alloc_descriptor(
desc_sw = dma_pool_alloc(fsl_chan->desc_pool, GFP_ATOMIC, &pdesc);
if (desc_sw) {
memset(desc_sw, 0, sizeof(struct fsl_desc_sw));
+ INIT_LIST_HEAD(&desc_sw->tx_list);
dma_async_tx_descriptor_init(&desc_sw->async_tx,
&fsl_chan->common);
desc_sw->async_tx.tx_submit = fsl_dma_tx_submit;
@@ -455,7 +457,7 @@ fsl_dma_prep_interrupt(struct dma_chan *chan, unsigned long flags)
new->async_tx.flags = flags;
/* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &new->async_tx.tx_list);
+ list_add_tail(&new->node, &new->tx_list);
/* Set End-of-link to the last link descriptor of new list*/
set_ld_eol(fsl_chan, new);
@@ -513,7 +515,7 @@ static struct dma_async_tx_descriptor *fsl_dma_prep_memcpy(
dma_dest += copy;
/* Insert the link descriptor to the LD ring */
- list_add_tail(&new->node, &first->async_tx.tx_list);
+ list_add_tail(&new->node, &first->tx_list);
} while (len);
new->async_tx.flags = flags; /* client is in control of this ack */
@@ -528,7 +530,7 @@ fail:
if (!first)
return NULL;
- list = &first->async_tx.tx_list;
+ list = &first->tx_list;
list_for_each_entry_safe_reverse(new, prev, list, node) {
list_del(&new->node);
dma_pool_free(fsl_chan->desc_pool, new, new->async_tx.phys);
diff --git a/drivers/dma/fsldma.h b/drivers/dma/fsldma.h
index dc7f268..4493afe 100644
--- a/drivers/dma/fsldma.h
+++ b/drivers/dma/fsldma.h
@@ -90,6 +90,7 @@ struct fsl_dma_ld_hw {
struct fsl_desc_sw {
struct fsl_dma_ld_hw hw;
struct list_head node;
+ struct list_head tx_list;
struct dma_async_tx_descriptor async_tx;
struct list_head *ld;
void *priv;
[-- Attachment #3: fsldma-add-dma_slave-support.patch --]
[-- Type: text/x-diff, Size: 12785 bytes --]
fsldma: Add DMA_SLAVE support
From: Ira Snyder <iws@ovro.caltech.edu>
Use the DMA_SLAVE capability of the DMAEngine API to copy/from a
scatterlist into an arbitrary list of hardware address/length pairs.
This allows a single DMA transaction to copy data from several different
devices into a scatterlist at the same time.
This also adds support to enable some controller-specific features such as
external start and external pause for a DMA transaction.
[dan.j.williams@intel.com: rebased on tx_list movement]
Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
Acked-by: Li Yang <leoli@freescale.com>
Acked-by: Kumar Gala <galak@kernel.crashing.org>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
arch/powerpc/include/asm/fsldma.h | 136 ++++++++++++++++++++++
drivers/dma/fsldma.c | 227 +++++++++++++++++++++++++++++++++++++
2 files changed, 363 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/include/asm/fsldma.h
diff --git a/arch/powerpc/include/asm/fsldma.h b/arch/powerpc/include/asm/fsldma.h
new file mode 100644
index 0000000..a67aeed
--- /dev/null
+++ b/arch/powerpc/include/asm/fsldma.h
@@ -0,0 +1,136 @@
+/*
+ * Freescale MPC83XX / MPC85XX DMA Controller
+ *
+ * Copyright (c) 2009 Ira W. Snyder <iws@ovro.caltech.edu>
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#ifndef __ARCH_POWERPC_ASM_FSLDMA_H__
+#define __ARCH_POWERPC_ASM_FSLDMA_H__
+
+#include <linux/dmaengine.h>
+
+/*
+ * Definitions for the Freescale DMA controller's DMA_SLAVE implemention
+ *
+ * The Freescale DMA_SLAVE implementation was designed to handle many-to-many
+ * transfers. An example usage would be an accelerated copy between two
+ * scatterlists. Another example use would be an accelerated copy from
+ * multiple non-contiguous device buffers into a single scatterlist.
+ *
+ * A DMA_SLAVE transaction is defined by a struct fsl_dma_slave. This
+ * structure contains a list of hardware addresses that should be copied
+ * to/from the scatterlist passed into device_prep_slave_sg(). The structure
+ * also has some fields to enable hardware-specific features.
+ */
+
+/**
+ * struct fsl_dma_hw_addr
+ * @entry: linked list entry
+ * @address: the hardware address
+ * @length: length to transfer
+ *
+ * Holds a single physical hardware address / length pair for use
+ * with the DMAEngine DMA_SLAVE API.
+ */
+struct fsl_dma_hw_addr {
+ struct list_head entry;
+
+ dma_addr_t address;
+ size_t length;
+};
+
+/**
+ * struct fsl_dma_slave
+ * @addresses: a linked list of struct fsl_dma_hw_addr structures
+ * @request_count: value for DMA request count
+ * @src_loop_size: setup and enable constant source-address DMA transfers
+ * @dst_loop_size: setup and enable constant destination address DMA transfers
+ * @external_start: enable externally started DMA transfers
+ * @external_pause: enable externally paused DMA transfers
+ *
+ * Holds a list of address / length pairs for use with the DMAEngine
+ * DMA_SLAVE API implementation for the Freescale DMA controller.
+ */
+struct fsl_dma_slave {
+
+ /* List of hardware address/length pairs */
+ struct list_head addresses;
+
+ /* Support for extra controller features */
+ unsigned int request_count;
+ unsigned int src_loop_size;
+ unsigned int dst_loop_size;
+ bool external_start;
+ bool external_pause;
+};
+
+/**
+ * fsl_dma_slave_append - add an address/length pair to a struct fsl_dma_slave
+ * @slave: the &struct fsl_dma_slave to add to
+ * @address: the hardware address to add
+ * @length: the length of bytes to transfer from @address
+ *
+ * Add a hardware address/length pair to a struct fsl_dma_slave. Returns 0 on
+ * success, -ERRNO otherwise.
+ */
+static inline int fsl_dma_slave_append(struct fsl_dma_slave *slave,
+ dma_addr_t address, size_t length)
+{
+ struct fsl_dma_hw_addr *addr;
+
+ addr = kzalloc(sizeof(*addr), GFP_ATOMIC);
+ if (!addr)
+ return -ENOMEM;
+
+ INIT_LIST_HEAD(&addr->entry);
+ addr->address = address;
+ addr->length = length;
+
+ list_add_tail(&addr->entry, &slave->addresses);
+ return 0;
+}
+
+/**
+ * fsl_dma_slave_free - free a struct fsl_dma_slave
+ * @slave: the struct fsl_dma_slave to free
+ *
+ * Free a struct fsl_dma_slave and all associated address/length pairs
+ */
+static inline void fsl_dma_slave_free(struct fsl_dma_slave *slave)
+{
+ struct fsl_dma_hw_addr *addr, *tmp;
+
+ if (slave) {
+ list_for_each_entry_safe(addr, tmp, &slave->addresses, entry) {
+ list_del(&addr->entry);
+ kfree(addr);
+ }
+
+ kfree(slave);
+ }
+}
+
+/**
+ * fsl_dma_slave_alloc - allocate a struct fsl_dma_slave
+ * @gfp: the flags to pass to kmalloc when allocating this structure
+ *
+ * Allocate a struct fsl_dma_slave for use by the DMA_SLAVE API. Returns a new
+ * struct fsl_dma_slave on success, or NULL on failure.
+ */
+static inline struct fsl_dma_slave *fsl_dma_slave_alloc(gfp_t gfp)
+{
+ struct fsl_dma_slave *slave;
+
+ slave = kzalloc(sizeof(*slave), gfp);
+ if (!slave)
+ return NULL;
+
+ INIT_LIST_HEAD(&slave->addresses);
+ return slave;
+}
+
+#endif /* __ARCH_POWERPC_ASM_FSLDMA_H__ */
diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
index 7a0cb60..296f9e7 100644
--- a/drivers/dma/fsldma.c
+++ b/drivers/dma/fsldma.c
@@ -34,6 +34,7 @@
#include <linux/dmapool.h>
#include <linux/of_platform.h>
+#include <asm/fsldma.h>
#include "fsldma.h"
static void dma_init(struct fsl_dma_chan *fsl_chan)
@@ -552,6 +553,229 @@ fail:
}
/**
+ * fsl_dma_prep_slave_sg - prepare descriptors for a DMA_SLAVE transaction
+ * @chan: DMA channel
+ * @sgl: scatterlist to transfer to/from
+ * @sg_len: number of entries in @scatterlist
+ * @direction: DMA direction
+ * @flags: DMAEngine flags
+ *
+ * Prepare a set of descriptors for a DMA_SLAVE transaction. Following the
+ * DMA_SLAVE API, this gets the device-specific information from the
+ * chan->private variable.
+ */
+static struct dma_async_tx_descriptor *fsl_dma_prep_slave_sg(
+ struct dma_chan *chan, struct scatterlist *sgl, unsigned int sg_len,
+ enum dma_data_direction direction, unsigned long flags)
+{
+ struct fsl_dma_chan *fsl_chan;
+ struct fsl_desc_sw *first = NULL, *prev = NULL, *new = NULL;
+ struct fsl_dma_slave *slave;
+ struct list_head *tx_list;
+ size_t copy;
+
+ int i;
+ struct scatterlist *sg;
+ size_t sg_used;
+ size_t hw_used;
+ struct fsl_dma_hw_addr *hw;
+ dma_addr_t dma_dst, dma_src;
+
+ if (!chan)
+ return NULL;
+
+ if (!chan->private)
+ return NULL;
+
+ fsl_chan = to_fsl_chan(chan);
+ slave = chan->private;
+
+ if (list_empty(&slave->addresses))
+ return NULL;
+
+ hw = list_first_entry(&slave->addresses, struct fsl_dma_hw_addr, entry);
+ hw_used = 0;
+
+ /*
+ * Build the hardware transaction to copy from the scatterlist to
+ * the hardware, or from the hardware to the scatterlist
+ *
+ * If you are copying from the hardware to the scatterlist and it
+ * takes two hardware entries to fill an entire page, then both
+ * hardware entries will be coalesced into the same page
+ *
+ * If you are copying from the scatterlist to the hardware and a
+ * single page can fill two hardware entries, then the data will
+ * be read out of the page into the first hardware entry, and so on
+ */
+ for_each_sg(sgl, sg, sg_len, i) {
+ sg_used = 0;
+
+ /* Loop until the entire scatterlist entry is used */
+ while (sg_used < sg_dma_len(sg)) {
+
+ /*
+ * If we've used up the current hardware address/length
+ * pair, we need to load a new one
+ *
+ * This is done in a while loop so that descriptors with
+ * length == 0 will be skipped
+ */
+ while (hw_used >= hw->length) {
+
+ /*
+ * If the current hardware entry is the last
+ * entry in the list, we're finished
+ */
+ if (list_is_last(&hw->entry, &slave->addresses))
+ goto finished;
+
+ /* Get the next hardware address/length pair */
+ hw = list_entry(hw->entry.next,
+ struct fsl_dma_hw_addr, entry);
+ hw_used = 0;
+ }
+
+ /* Allocate the link descriptor from DMA pool */
+ new = fsl_dma_alloc_descriptor(fsl_chan);
+ if (!new) {
+ dev_err(fsl_chan->dev, "No free memory for "
+ "link descriptor\n");
+ goto fail;
+ }
+#ifdef FSL_DMA_LD_DEBUG
+ dev_dbg(fsl_chan->dev, "new link desc alloc %p\n", new);
+#endif
+
+ /*
+ * Calculate the maximum number of bytes to transfer,
+ * making sure it is less than the DMA controller limit
+ */
+ copy = min_t(size_t, sg_dma_len(sg) - sg_used,
+ hw->length - hw_used);
+ copy = min_t(size_t, copy, FSL_DMA_BCR_MAX_CNT);
+
+ /*
+ * DMA_FROM_DEVICE
+ * from the hardware to the scatterlist
+ *
+ * DMA_TO_DEVICE
+ * from the scatterlist to the hardware
+ */
+ if (direction == DMA_FROM_DEVICE) {
+ dma_src = hw->address + hw_used;
+ dma_dst = sg_dma_address(sg) + sg_used;
+ } else {
+ dma_src = sg_dma_address(sg) + sg_used;
+ dma_dst = hw->address + hw_used;
+ }
+
+ /* Fill in the descriptor */
+ set_desc_cnt(fsl_chan, &new->hw, copy);
+ set_desc_src(fsl_chan, &new->hw, dma_src);
+ set_desc_dest(fsl_chan, &new->hw, dma_dst);
+
+ /*
+ * If this is not the first descriptor, chain the
+ * current descriptor after the previous descriptor
+ */
+ if (!first) {
+ first = new;
+ } else {
+ set_desc_next(fsl_chan, &prev->hw,
+ new->async_tx.phys);
+ }
+
+ new->async_tx.cookie = 0;
+ async_tx_ack(&new->async_tx);
+
+ prev = new;
+ sg_used += copy;
+ hw_used += copy;
+
+ /* Insert the link descriptor into the LD ring */
+ list_add_tail(&new->node, &first->tx_list);
+ }
+ }
+
+finished:
+
+ /* All of the hardware address/length pairs had length == 0 */
+ if (!first || !new)
+ return NULL;
+
+ new->async_tx.flags = flags;
+ new->async_tx.cookie = -EBUSY;
+
+ /* Set End-of-link to the last link descriptor of new list */
+ set_ld_eol(fsl_chan, new);
+
+ /* Enable extra controller features */
+ if (fsl_chan->set_src_loop_size)
+ fsl_chan->set_src_loop_size(fsl_chan, slave->src_loop_size);
+
+ if (fsl_chan->set_dest_loop_size)
+ fsl_chan->set_dest_loop_size(fsl_chan, slave->dst_loop_size);
+
+ if (fsl_chan->toggle_ext_start)
+ fsl_chan->toggle_ext_start(fsl_chan, slave->external_start);
+
+ if (fsl_chan->toggle_ext_pause)
+ fsl_chan->toggle_ext_pause(fsl_chan, slave->external_pause);
+
+ if (fsl_chan->set_request_count)
+ fsl_chan->set_request_count(fsl_chan, slave->request_count);
+
+ return &first->async_tx;
+
+fail:
+ /* If first was not set, then we failed to allocate the very first
+ * descriptor, and we're done */
+ if (!first)
+ return NULL;
+
+ /*
+ * First is set, so all of the descriptors we allocated have been added
+ * to first->tx_list, INCLUDING "first" itself. Therefore we
+ * must traverse the list backwards freeing each descriptor in turn
+ *
+ * We're re-using variables for the loop, oh well
+ */
+ tx_list = &first->tx_list;
+ list_for_each_entry_safe_reverse(new, prev, tx_list, node) {
+ list_del_init(&new->node);
+ dma_pool_free(fsl_chan->desc_pool, new, new->async_tx.phys);
+ }
+
+ return NULL;
+}
+
+static void fsl_dma_device_terminate_all(struct dma_chan *chan)
+{
+ struct fsl_dma_chan *fsl_chan;
+ struct fsl_desc_sw *desc, *tmp;
+ unsigned long flags;
+
+ if (!chan)
+ return;
+
+ fsl_chan = to_fsl_chan(chan);
+
+ /* Halt the DMA engine */
+ dma_halt(fsl_chan);
+
+ spin_lock_irqsave(&fsl_chan->desc_lock, flags);
+
+ /* Remove and free all of the descriptors in the LD queue */
+ list_for_each_entry_safe(desc, tmp, &fsl_chan->ld_queue, node) {
+ list_del(&desc->node);
+ dma_pool_free(fsl_chan->desc_pool, desc, desc->async_tx.phys);
+ }
+
+ spin_unlock_irqrestore(&fsl_chan->desc_lock, flags);
+}
+
+/**
* fsl_dma_update_completed_cookie - Update the completed cookie.
* @fsl_chan : Freescale DMA channel
*/
@@ -977,12 +1201,15 @@ static int __devinit of_fsl_dma_probe(struct of_device *dev,
dma_cap_set(DMA_MEMCPY, fdev->common.cap_mask);
dma_cap_set(DMA_INTERRUPT, fdev->common.cap_mask);
+ dma_cap_set(DMA_SLAVE, fdev->common.cap_mask);
fdev->common.device_alloc_chan_resources = fsl_dma_alloc_chan_resources;
fdev->common.device_free_chan_resources = fsl_dma_free_chan_resources;
fdev->common.device_prep_dma_interrupt = fsl_dma_prep_interrupt;
fdev->common.device_prep_dma_memcpy = fsl_dma_prep_memcpy;
fdev->common.device_is_tx_complete = fsl_dma_is_complete;
fdev->common.device_issue_pending = fsl_dma_memcpy_issue_pending;
+ fdev->common.device_prep_slave_sg = fsl_dma_prep_slave_sg;
+ fdev->common.device_terminate_all = fsl_dma_device_terminate_all;
fdev->common.dev = &dev->dev;
fdev->irq = irq_of_parse_and_map(dev->node, 0);
^ permalink raw reply related
* Re: [PATCH] forcedeth: updated phy errata
From: Ayaz Abdulla @ 2009-09-04 13:57 UTC (permalink / raw)
To: David Miller
Cc: manfred@colorfullife.com, akpm@osdl.org, netdev@vger.kernel.org
In-Reply-To: <20090902.232201.248326790.davem@davemloft.net>
David Miller wrote:
> From: Ayaz Abdulla <aabdulla@nvidia.com>
> Date: Mon, 31 Aug 2009 19:08:37 -0400
>
>
>>This patch updates the special programming (and/or errata) needed in
>>order to setup the phy for various vendor models.
>>
>>The new models include:
>>Marvell E1116
>>Marvell E1111
>>Marvell E1011
>>Marvell E3016
>>Broadcom 9507
>>Broadcom AC131
>>Broadcom 50610
>>
>>Signed-off-by: Ayaz Abdulla <aabdulla@nvidia.com>
>
>
> Please document what these individual bits mean which you
> are clearing, by using an individual define for each register
> bit to describe it's purpose, and then define the mask as
> a concatenation of these bits.
>
> Having an opaque bitmask is not how to do this.
Unfortunately, the phy vendors don't want us exposing the meaning of
their non-standard bits.
>
> Thanks.
^ permalink raw reply
* Re: [PATCH] slub: fix slab_pad_check()
From: Christoph Lameter @ 2009-09-04 15:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Paul E. McKenney, Pekka Enberg, Zdenek Kabelac, Patrick McHardy,
Robin Holt, Linux Kernel Mailing List, Jesper Dangaard Brouer,
Linux Netdev List, Netfilter Developers
In-Reply-To: <4AA03E6A.7070800@gmail.com>
On Fri, 4 Sep 2009, Eric Dumazet wrote:
> Problem is not _objects_ Christoph, but _slabs_, and your patch is not working.
Why?
> Its true that when User calls kmem_cache_destroy(), all _objects_ were
> previously freed. This is mandatory, with or withou SLAB_DESTROY_BY_RCU
> thing
Right.
> Problem is that slub has some internal state, including some to-be-freed _slabs_,
> that User have no control at all on it.
Those are going to be freed without calls to rcu with my patch. The only
reason for earlier rcu frees are user calls to kfree.
> Face it, SLAB_DESTROY_BY_RCU is internal affair (to slub/slab/... allocators)
Nope the user must follow RCU guidelines when using objects.
> We absolutely need a rcu_barrier() somewhere, believe it or not. You can
> argue that it should be done *before*, but it gives no speedup, only
> potential bugs.
I never said that you do not need an rcu_barrier() for this particular
situation? Why suggest such a thing?
The insertion of rcu stuff in the slab code will lead to future bugs since
now the slab logic is tied to the semantics of a particular rcu
implementatin.
> Only case User should do its rcu_barrier() itself is if it knows some
> call_rcu() are pending and are delaying _objects_ freeing (typical
> !SLAB_DESTROY_RCU usage in RCU algos).
Ok then the user already has to deal with the barriers. The API is
inconsistent if you put this into kmem_cache_destroy.
> I dont even understand why you care so much about
> kmem_cache_destroy(SLAB_DESTROY_BY_RCU), given that almost nobody use
> it. We took almost one month to find out what the bug was in first
> place...
This is already the second bug on this issue. Given the complexity of rcu
it is to be experted that inserting more RCU semantics into the slab
allocators is likely to cause future chains of new features and
bugs in slab allocators.
^ permalink raw reply
* Re: [PATCH net-next] wan: dlci/sdla transmit return dehacking
From: Krzysztof Halasa @ 2009-09-04 18:48 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, sfr, linux-next, netdev
In-Reply-To: <20090904083346.43885303@nehalam>
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.
--
Krzysztof Halasa
^ permalink raw reply
* [PATCH] WAN: remove deprecated PCI_DEVICE_ID from PCI200SYN driver.
From: Krzysztof Halasa @ 2009-09-04 17:50 UTC (permalink / raw)
To: David Miller; +Cc: netdev
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.
--
Krzysztof Halasa
--- a/drivers/net/wan/pci200syn.c
+++ b/drivers/net/wan/pci200syn.c
@@ -360,15 +360,6 @@ static int __devinit pci200_pci_init_one(struct pci_dev *pdev,
" %u RX packets rings\n", ramsize / 1024, ramphys,
pdev->irq, card->tx_ring_buffers, card->rx_ring_buffers);
- if (pdev->subsystem_device == PCI_DEVICE_ID_PLX_9050) {
- printk(KERN_ERR "Detected PCI200SYN card with old "
- "configuration data.\n");
- printk(KERN_ERR "See <http://www.kernel.org/pub/"
- "linux/utils/net/hdlc/pci200syn/> for update.\n");
- printk(KERN_ERR "The card will stop working with"
- " future versions of Linux if not updated.\n");
- }
-
if (card->tx_ring_buffers < 1) {
printk(KERN_ERR "pci200syn: RAM test failed\n");
pci200_pci_remove_one(pdev);
@@ -427,8 +418,6 @@ static int __devinit pci200_pci_init_one(struct pci_dev *pdev,
static struct pci_device_id pci200_pci_tbl[] __devinitdata = {
{ PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050, PCI_VENDOR_ID_PLX,
- PCI_DEVICE_ID_PLX_9050, 0, 0, 0 },
- { PCI_VENDOR_ID_PLX, PCI_DEVICE_ID_PLX_9050, PCI_VENDOR_ID_PLX,
PCI_DEVICE_ID_PLX_PCI200SYN, 0, 0, 0 },
{ 0, }
};
^ permalink raw reply
* Re: net_sched 00/07: classful multiqueue dummy scheduler
From: Patrick McHardy @ 2009-09-04 16:42 UTC (permalink / raw)
To: netdev
In-Reply-To: <20090904164111.27300.29929.sendpatchset@x2.localnet>
[-- Attachment #1: Type: text/plain, Size: 1279 bytes --]
Patrick McHardy wrote:
> These patches contain a classful multiqueue ("mq") dummy scheduler to fix a
> couple of problems with the current multiqueue TC API integration. The
> changelogs of patch 05 and 07 contain more details.
>
> The mq scheduler does two things:
>
> - present device TX queues as classes, allowing to attach different qdiscs
> to them, which are grafted to the TX queues
>
> - present accumulated statistics of all device queue root qdiscs
>
> Its used by default for multiqueue devices instead of the regular pfifo_fast
> qdisc, but can also be attached manually to restore multiqueue behaviour
> after attaching a non-multiqueue (shared) qdisc.
>
> Patches 1-4 contain some preparatory cleanups because I was getting tired
> of copying unnecessary checks and dummy functions :)
>
> Patch 5 introduces a dev->qdisc pointer, which points to the root qdisc from
> userspace's point of view. This is later used for the mq qdisc, which isn't
> actually attached to any device queues. Patch 7 contains the mq scheduler.
>
> I've tested the scheduler with a hacked macvlan version which uses 4 queues,
> but since I don't own a multiqueue capable device I couldn't test this on
> real hardware.
And for reference, this is the script I used for testing:
[-- Attachment #2: test.sh --]
[-- Type: application/x-sh, Size: 928 bytes --]
^ 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