Francois Romieu wrote:
Bruce Cole <[EMAIL PROTECTED]> :
[...]
What's the status of this fix? It (or something more refined) seems
necessary to correct the current performance problems with this driver.
An explanation or something more refined would be welcome.
Are you indicating t
On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote:
> Chris Snook <[EMAIL PROTECTED]> wrote:
> >
> > Because atomic operations are generally used for synchronization, which
> > requires
> > volatile behavior. Most such codepaths currently use an inefficient
> > barrier().
> > Some fo
On Wed, 15 Aug 2007 10:10:38 +0200
Stefan Richter <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >> > Actually I think the entire thing is a
> >> > bad idea but thats another matter.
>
> > Working off the git tree as it shows who actually is making
> > changes/updating stuff recently and why whic
Alan Cox wrote:
>> > Actually I think the entire thing is a
>> > bad idea but thats another matter.
> Working off the git tree as it shows who actually is making
> changes/updating stuff recently and why which is a major clue when
> tracing bugs
Adrian Bunk wrote in http://lkml.org/lkml/2007/6/30
oleg 123 <[EMAIL PROTECTED]> wrote:
>
> There is a bug in __sock_create() function (net/socket.c).
> If an error occur in LSM hook security_socket_post_create, then unneeded
> rcu_read_unlock() is made in __sock_create.
Well spotted! Please cc netdev@vger.kernel.org for networking
issues.
[NET]:
Satyam Sharma wrote:
> [ BTW, why do we want the compiler to not optimize atomic_read()'s in
> the first place? Atomic ops guarantee atomicity, which has nothing
> to do with "volatility" -- users that expect "volatility" from
> atomic ops are the ones who must be fixed instead, IMHO. ]
LDD3
There is no point in trying to handle source MAC address based VLANs in
the wireless stack, something like "smacvlan" modeled after macvlan
should be sufficient.
Signed-off-by: Johannes Berg <[EMAIL PROTECTED]>
---
We could just not keep the hole as well since people can't really be
using that he
On Tue, 14 Aug 2007, Adrian Bunk wrote:
> According to git, the only one who touched this file during the last
> 5 years was me when removing drivers...
>
> modinfo offers less ancient information.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
For the m68k net drivers:
Acked-by: Geert Uytt
IP32 doesn't even have a ZONE_DMA so no point in using GFP_DMA in any
IP32-specific device driver.
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
diff --git a/drivers/net/meth.c b/drivers/net/meth.c
index 92b403b..32bed6b 100644
--- a/drivers/net/meth.c
+++ b/drivers/net/meth.c
@@ -405,7 +405,7
On Wed, Aug 15, 2007 at 12:35:31PM +0200, Stefan Richter wrote:
>
> LDD3 says on page 125: "The following operations are defined for the
> type [atomic_t] and are guaranteed to be atomic with respect to all
> processors of an SMP computer."
>
> Doesn't "atomic WRT all processors" require volatil
On Wed, 15 Aug 2007, Stefan Richter wrote:
> Satyam Sharma wrote:
> > [ BTW, why do we want the compiler to not optimize atomic_read()'s in
> > the first place? Atomic ops guarantee atomicity, which has nothing
> > to do with "volatility" -- users that expect "volatility" from
> > atomic o
Hey,
Is it intentional that in the case where set_rx_mode is assigned, you
still need to assign set_multicast_list even if it won't ever be called
as a flag for SIOCADDMULTI?
I was thinking of converting the wireless code to use set_rx_mode and
assign set_multicast_list only if the underlying har
Johannes Berg wrote:
> Is it intentional that in the case where set_rx_mode is assigned, you
> still need to assign set_multicast_list even if it won't ever be called
> as a flag for SIOCADDMULTI?
>
> I was thinking of converting the wireless code to use set_rx_mode and
> assign set_multicast_list
On Wed, 2007-08-15 at 14:33 +0200, Patrick McHardy wrote:
> Johannes Berg wrote:
> > Is it intentional that in the case where set_rx_mode is assigned, you
> > still need to assign set_multicast_list even if it won't ever be called
> > as a flag for SIOCADDMULTI?
> >
> > I was thinking of convertin
On Wednesday 15 August 2007 02:40:35 John W. Linville wrote:
> On Mon, Aug 13, 2007 at 12:44:02AM +0200, Adrian Bunk wrote:
> > On Sun, Aug 12, 2007 at 02:00:26PM +0200, Michael Buesch wrote:
> > > Ok, I'll give it a try, with small modifications.
> >
> > Thanks.
> >
> > > On Sunday 12 August 200
On Wed, 2007-08-15 at 14:33 +0200, Patrick McHardy wrote:
> Johannes Berg wrote:
> > Is it intentional that in the case where set_rx_mode is assigned, you
> > still need to assign set_multicast_list even if it won't ever be called
> > as a flag for SIOCADDMULTI?
> >
> > I was thinking of convertin
Satyam Sharma wrote:
> On Wed, 15 Aug 2007, Stefan Richter wrote:
>> Doesn't "atomic WRT all processors" require volatility?
>
> No, it definitely doesn't. Why should it?
>
> "Atomic w.r.t. all processors" is just your normal, simple "atomicity"
> for SMP systems (ensure that that object is modif
I wrote:
> static inline void A(atomic_t *a)
> {
> int b = atomic_read(a);
> if (b)
> do_something_time_consuming();
> }
>
> static inline void B(atomic_t *a)
> {
> int b = atomic_read(a);
> if (b)
> do_something_more();
> }
>
> static void C(at
Paul E. McKenney wrote:
On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
Maybe it is the safe way to go, but it does obscure cases where there
is a real need for barriers.
I prefer burying barriers into other primitives.
When they should naturally be there, eg. locking or the
From: Aurelien Jarno <[EMAIL PROTECTED]>
The conversion of the B44 driver to SSB bus added the functions
__b44_{read,write}phy functions that have an argument phy_id. This gives
a way to fix the b44_mii_{read,write} functions used for MII interfaces.
The patch below does that. It allows B44 devic
Signed-off-by: Michael Buesch <[EMAIL PROTECTED]>
Index: wireless-dev-new/drivers/net/Kconfig
===
--- wireless-dev-new.orig/drivers/net/Kconfig 2007-08-11 00:49:28.0
+0200
+++ wireless-dev-new/drivers/net/Kconfig200
On 8/15/2007 10:18 AM, Heiko Carstens wrote:
> On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote:
>> Chris Snook <[EMAIL PROTECTED]> wrote:
>> >
>> > Because atomic operations are generally used for synchronization, which
>> > requires
>> > volatile behavior. Most such codepaths curren
On Wed, 15 Aug 2007, Stefan Richter wrote:
> Satyam Sharma wrote:
> > On Wed, 15 Aug 2007, Stefan Richter wrote:
> >> Doesn't "atomic WRT all processors" require volatility?
> >
> > No, it definitely doesn't. Why should it?
> >
> > "Atomic w.r.t. all processors" is just your normal, simple "at
Hi Stefan,
On Wed, 15 Aug 2007, Stefan Richter wrote:
> On 8/15/2007 10:18 AM, Heiko Carstens wrote:
> > On Wed, Aug 15, 2007 at 02:49:03PM +0800, Herbert Xu wrote:
> >> Chris Snook <[EMAIL PROTECTED]> wrote:
> >> >
> >> > Because atomic operations are generally used for synchronization, which
On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
> On Wed, 15 Aug 2007, Stefan Richter wrote:
> > Satyam Sharma wrote:
> > > On Wed, 15 Aug 2007, Stefan Richter wrote:
> > >> Doesn't "atomic WRT all processors" require volatility?
> > >
> > > No, it definitely doesn't. Why should it?
David Miller wrote:
From: Sean Hefty <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 14:40:16 -0700
Steve Wise wrote:
Any more comments?
Does anyone have ideas on how to reserve the port space without using a
struct socket?
How about we just remove the RDMA stack altogether? I am not at all
k
On Wednesday 15 August 2007, Paul E. McKenney wrote:
> ACCESS_ONCE() is indeed intended to be used when actually loading or
> storing the variable. That said, I must admit that it is not clear to me
> why you would want to add an extra order() rather than ACCESS_ONCE()ing
> one or both of the adj
On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
>
> > I don't know if this here is affected:
>
> Yes, I think it is. You're clearly expecting the read to actually happen
> when you call get_hpsb_generation(). It's clearly not a busy-loop, so
> cpu_relax() sounds pointless / wrong so
ipv6 sends a RTM_DELLINK netlink message on both events: NETDEV_DOWN,
NETDEV_UNREGISTER. Corrected by sending RTM_NEWLINK on NETDEV_DOWN event
and RTM_DELLINK on NETDEV_UNREGISTER event.
---
btw. I don't know why protocol sends a NL messages about iface state
changes. It comes from other sources.
We have been shipping Linux based servers to customers for several
years now, with few problems. Recently, however, a single customer has
been seeing kernel panics. Unfortunately, the customer is about 200
miles away, so physical access is limited. There are two ethernet
interfaces, one should be
On Wednesday 15 August 2007 15:29:43 Arnd Bergmann wrote:
> On Wednesday 15 August 2007, Paul E. McKenney wrote:
>
> > ACCESS_ONCE() is indeed intended to be used when actually loading or
> > storing the variable. That said, I must admit that it is not clear to me
> > why you would want to add an
On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
>
> Do we really need another set of APIs? Can you give even one example
> where the pre-existing volatile semantics are causing enough of a problem
> to justify adding yet more atomic_*() APIs?
Let's turn this around. Can you gi
Hi Alan.
On Wed, Aug 15, 2007 at 04:07:23PM +0100, Alan J. Wylie ([EMAIL PROTECTED])
wrote:
> EIP: [] skb_pull_rcsum+0x6d/0x71 SS:ESP 09068:c03e1ea4
> Kernel panic - not syncing: Fatal exception in interrupt
At least with this patch it should not panic.
More correct solution might be to use pskb
On Wed, Aug 15, 2007 at 11:33:36PM +0800, Herbert Xu wrote:
> On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
> >
> > Do we really need another set of APIs? Can you give even one example
> > where the pre-existing volatile semantics are causing enough of a problem
> > to justify
Herbert Xu wrote:
> On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
>>> I don't know if this here is affected:
[...something like]
b = atomic_read(a);
for (i = 0; i < 4; i++) {
msleep_interruptible(63);
c = atomic_read(a);
Herbert Xu wrote:
Chris Snook <[EMAIL PROTECTED]> wrote:
Because atomic operations are generally used for synchronization, which requires
volatile behavior. Most such codepaths currently use an inefficient barrier().
Some forget to and we get bugs, because people assume that atomic_read()
ac
On Tue, 2007-08-07 at 18:32 -0700, David Miller wrote:
>From: Joy Latten <[EMAIL PROTECTED]>
>Date: Thu, 2 Aug 2007 15:56:47 -0500
>
>> @@ -426,10 +426,15 @@ struct xfrm_audit
>> };
>>
>> #ifdef CONFIG_AUDITSYSCALL
>> -extern void xfrm_audit_log(uid_t auid, u32 secid, int type, int result,
>> -
On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:
> Herbert Xu wrote:
> > On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
> >>> I don't know if this here is affected:
>
> [...something like]
> b = atomic_read(a);
> for (i = 0; i < 4; i++) {
>
On Tue, Aug 14, 2007 at 10:54:32AM +0100, Mark Hindley wrote:
> On Tue, Aug 14, 2007 at 01:33:26AM -0400, Jeff Garzik wrote:
> > I would strongly prefer that vortex_up return a value, since all the
> > important callers of this function can themselves return an error back
> > to the system.
> >
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 06:09:35PM +0200, Stefan Richter wrote:
> > Herbert Xu wrote:
> > > On Wed, Aug 15, 2007 at 08:05:38PM +0530, Satyam Sharma wrote:
> > >>> I don't know if this here is affected:
> >
> > [...something like]
> > b = atomic
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 11:33:36PM +0800, Herbert Xu wrote:
> > On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
> > >
> > > Do we really need another set of APIs? Can you give even one example
> > > where the pre-existing volatil
From: Nicholas Nunley <[EMAIL PROTECTED]>
Signed-off-by: Nicholas Nunley <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
Makefile.am|2
ethtool-util.h |2
ethtool.c |1
ixgbe.c| 1017
4 f
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 10:48:28PM +0530, Satyam Sharma wrote:
> > [...]
> > Not for i386 and x86_64 -- those have atomic ops without any "volatile"
> > semantics (currently as per existing definitions).
>
> I claim unit volumes with arm, and the m
* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-08-09 18:07
> My big question is: Has anyone recently used the 802_3 protocol in tc
> with u32 and actually gotten it to work? I can't see how the
> u32_classify() code can look at the mac header, since it is using the
> network header accessor to
Hi Paul,
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
> > [...]
> > No, I'd actually prefer something like what Christoph Lameter suggested,
> > i.e. users (such as above) who want "volatile"-like behaviour from atomic
> > ops can
On Wed, Aug 15, 2007 at 10:48:28PM +0530, Satyam Sharma wrote:
> On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> > On Wed, Aug 15, 2007 at 11:33:36PM +0800, Herbert Xu wrote:
> > > On Wed, Aug 15, 2007 at 07:25:16AM -0700, Paul E. McKenney wrote:
> > > >
> > > > Do we really need another set of API
From: Nicholas Nunley <[EMAIL PROTECTED]>
Signed-off-by: Nicholas Nunley <[EMAIL PROTECTED]>
Signed-off-by: Auke Kok <[EMAIL PROTECTED]>
---
Makefile.am|2
ethtool-util.h |2
ethtool.c |1
igb.c | 864
4 f
* Richard MUSIL <[EMAIL PROTECTED]> 2007-08-10 10:45
> I have noticed that although ops for each family are the same (each
> device is functionally same) I cannot use same genl_ops struct for
> registration, because it uses internal member to link in list. Therefore
> it is necessary to allocate ne
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Let's turn this around. Can you give a single example where
> the volatile semantics is needed in a legitimate way?
Accessing H/W registers? But apart from that...
David
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]>
> 2007-08-15 11:02
> > > There is this very horrible way of using the u32
> classifier with a
> > > negative offset to look into the ethernet header.
> >
> > Based on this, it sounds like u32 using protocol 802_3 is broken?
>
> You might be expect
> * Waskiewicz Jr, Peter P <[EMAIL PROTECTED]>
> 2007-08-09 18:07
> > My big question is: Has anyone recently used the 802_3
> protocol in tc
> > with u32 and actually gotten it to work? I can't see how the
> > u32_classify() code can look at the mac header, since it is
> using the
> > networ
* Waskiewicz Jr, Peter P <[EMAIL PROTECTED]> 2007-08-15 11:02
> > There is this very horrible way of using the u32 classifier
> > with a negative offset to look into the ethernet header.
>
> Based on this, it sounds like u32 using protocol 802_3 is broken?
You might be expecting too much from u3
On Wed, Aug 15, 2007 at 07:19:57PM +0100, David Howells wrote:
> Herbert Xu <[EMAIL PROTECTED]> wrote:
>
> > Let's turn this around. Can you give a single example where
> > the volatile semantics is needed in a legitimate way?
>
> Accessing H/W registers? But apart from that...
Communicating b
I'd very much like to help out. The "rtnl assertion spew" isn't
instilling confidence in customers I've been working with. If you'd
like to send me patches in private I'd help test them ASAP.
Could you elaborate on the associated risk of _not_ fixing these
issues? balance-alb _seems_ to be work
"Volatile behaviour" itself isn't consistently defined (at least
definitely not consistently implemented in various gcc versions across
platforms),
It should be consistent across platforms; if not, file a bug please.
but it is /expected/ to mean something like: "ensure that
every such access a
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use it.
rmb() orders *any* two reads; that includes two reads from the same
location.
Consider that smp_rmb basically will do anything from flushing the
pip
On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> >>How does the compiler know that msleep() has got barrier()s?
> >
> >Because msleep_interruptible() is in a separate compilation unit,
> >the compiler has to assume that it might modify any arbitrary global.
>
> No; compilation
These patches update the network driver core, e100 and e1000 driver to use
devres. Devres is a simple resource manager for device drivers, see
Documentation/driver-model/devres.txt for more information.
The use of devres will continue to be optional with this patch set and can be
applied to drive
* netdev_pci_remove_one() can replace simple pci device remove
functions
* devm_alloc_netdev() is like alloc_netdev but allocates memory using devres.
Signed-off-by: Brandon Philips <[EMAIL PROTECTED]>
---
include/linux/etherdevice.h |5 ++
include/linux/netdevice.h |7 ++
net/core/
devres manages device resources and is currently used by all libata low level
drivers. When devres is used in a driver the complexity of error handling in
the device probe and remove functions can be reduced.
In this case e100_free(), e100_remove() and all of the gotos in e100_probe have
been re
devm_kcalloc is a simple wrapper around devm_kzalloc for arrays. This is
needed because kcalloc is often used in network devices.
Signed-off-by: Brandon Philips <[EMAIL PROTECTED]>
---
drivers/base/devres.c | 16
include/linux/device.h |2 ++
2 files changed, 18 inserti
Conversion of e1000 probe() and remove() to devres.
Signed-off-by: Brandon Philips <[EMAIL PROTECTED]>
---
drivers/net/e1000/e1000.h |1
drivers/net/e1000/e1000_main.c | 92 -
2 files changed, 28 insertions(+), 65 deletions(-)
Index: linux-2.6/
On Wed, Aug 15, 2007 at 11:25:05PM +0530, Satyam Sharma wrote:
> Hi Paul,
> On Wed, 15 Aug 2007, Paul E. McKenney wrote:
>
> > On Wed, Aug 15, 2007 at 07:17:29PM +0530, Satyam Sharma wrote:
> > > [...]
> > > No, I'd actually prefer something like what Christoph Lameter suggested,
> > > i.e. users
Mike Snitzer <[EMAIL PROTECTED]> wrote:
>I'd very much like to help out. The "rtnl assertion spew" isn't
>instilling confidence in customers I've been working with. If you'd
>like to send me patches in private I'd help test them ASAP.
I'll send you some stuff off-list in a bit.
>Could
On Wed, Aug 15, 2007 at 08:51:58PM +0200, Segher Boessenkool wrote:
> >Well if there is only one memory location involved, then smp_rmb()
> >isn't
> >going to really do anything anyway, so it would be incorrect to use it.
>
> rmb() orders *any* two reads; that includes two reads from the same
> l
On Wed, 15 Aug 2007, Segher Boessenkool wrote:
> > "Volatile behaviour" itself isn't consistently defined (at least
> > definitely not consistently implemented in various gcc versions across
> > platforms),
>
> It should be consistent across platforms; if not, file a bug please.
>
> > but it i
On Wed, 15 Aug 2007 12:22:51 -0700 (PDT)
[EMAIL PROTECTED] wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=8891
>
>Summary: in-kernel rpc generates broken RPCBPROC_GETVERSADDR v4
> requests
>Product: Networking
>Version: 2.5
> Kerne
[ The Cc: list scares me. Should probably trim it. ]
On Wed, 15 Aug 2007, Paul E. McKenney wrote:
> On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> > >>How does the compiler know that msleep() has got barrier()s?
> > >
> > >Because msleep_interruptible() is in a separate co
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
location.
If the two reads are to the same location, all CPUs I am aware of
will
Well if there is only one memory location involved, then smp_rmb()
isn't
going to really do anything anyway, so it would be incorrect to use
it.
rmb() orders *any* two reads; that includes two reads from the same
location.
If the two reads are to the same location, all CPUs I am aware of
will
On Thu, Aug 16, 2007 at 01:24:42AM +0530, Satyam Sharma wrote:
> [ The Cc: list scares me. Should probably trim it. ]
Trim away! ;-)
> On Wed, 15 Aug 2007, Paul E. McKenney wrote:
>
> > On Wed, Aug 15, 2007 at 08:31:25PM +0200, Segher Boessenkool wrote:
> > > >>How does the compiler know that m
On Wed, Aug 15, 2007 at 11:30:05PM +1000, Nick Piggin wrote:
> Paul E. McKenney wrote:
> >On Tue, Aug 14, 2007 at 03:34:25PM +1000, Nick Piggin wrote:
>
> >>Maybe it is the safe way to go, but it does obscure cases where there
> >>is a real need for barriers.
> >
> >
> >I prefer burying barriers i
On Wed, Aug 15, 2007 at 09:46:55PM +0200, Segher Boessenkool wrote:
> >>>Well if there is only one memory location involved, then smp_rmb()
> >>>isn't
> >>>going to really do anything anyway, so it would be incorrect to use
> >>>it.
> >>
> >>rmb() orders *any* two reads; that includes two reads fr
On Wed, 15 Aug 2007, Stefan Richter wrote:
> LDD3 says on page 125: "The following operations are defined for the
> type [atomic_t] and are guaranteed to be atomic with respect to all
> processors of an SMP computer."
>
> Doesn't "atomic WRT all processors" require volatility?
Atomic operations
Andrew Morton wrote:
On Wed, 15 Aug 2007 12:22:51 -0700 (PDT)
[EMAIL PROTECTED] wrote:
http://bugzilla.kernel.org/show_bug.cgi?id=8891
Summary: in-kernel rpc generates broken RPCBPROC_GETVERSADDR v4
requests
Product: Networking
Version: 2.5
How does the compiler know that msleep() has got barrier()s?
Because msleep_interruptible() is in a separate compilation unit,
the compiler has to assume that it might modify any arbitrary global.
No; compilation units have nothing to do with it, GCC can optimise
across compilation unit bounda
I think this was just terminology confusion here again. Isn't "any
code
that it cannot currently see" the same as "another compilation unit",
and wouldn't the "compilation unit" itself expand if we ask gcc to
compile more than one unit at once? Or is there some more specific
"definition" for "com
What volatile does are a) never optimise away a read (or write)
to the object, since the data can change in ways the compiler
cannot see; and b) never move stores to the object across a
sequence point. This does not mean other accesses cannot be
reordered wrt the volatile access.
If the abstract
What you probably mean is that the compiler has to assume any code
it cannot currently see can do anything (insofar as allowed by the
relevant standards etc.)
I think this was just terminology confusion here again. Isn't "any code
that it cannot currently see" the same as "another compilation un
On Wed, Aug 15, 2007 at 10:13:49PM +0200, Segher Boessenkool wrote:
> >Well if there is only one memory location involved, then smp_rmb()
> >isn't
> >going to really do anything anyway, so it would be incorrect to use
> >it.
>
> rmb() orders *any* two reads; that includes t
On Wed, Aug 15, 2007 at 06:30:00PM +0200, Steffen Klassert wrote:
> On Tue, Aug 14, 2007 at 10:54:32AM +0100, Mark Hindley wrote:
> > On Tue, Aug 14, 2007 at 01:33:26AM -0400, Jeff Garzik wrote:
> > > I would strongly prefer that vortex_up return a value, since all the
> > > important callers of t
Of course, if we find there are more callers in the kernel who want
the
volatility behaviour than those who don't care, we can re-define the
existing ops to such variants, and re-name the existing definitions
to
somethine else, say "atomic_read_nonvolatile" for all I care.
Do we really need a
No; compilation units have nothing to do with it, GCC can optimise
across compilation unit boundaries just fine, if you tell it to
compile more than one compilation unit at once.
Last I checked, the Linux kernel build system did compile each .c file
as a separate compilation unit.
I have some
Hello,
I can see some very strange problem with sky2 and skge interfaces with 2.6.22,
and also 2.6.23-rc2/3.
After 8-9 minutes, the interfaces stop working. ethtool reports that the link is
down and the only way to make the interfaces usable again is
removing/reinserting the module or running ethto
Possibly these were too trivial to expose any potential problems that
you
may have been referring to, so would be helpful if you could write a
more
concrete example / sample code.
The trick is to have a sufficiently complicated expression to force
the compiler to run out of registers.
You ca
Please check the definition of "cache coherence".
Which of the twelve thousand such definitions? :-)
Summary: the CPU is indeed within its rights to execute loads and
stores
to a single variable out of order, -but- only if it gets the same
result
that it would have obtained by executing them
From: Herbert Xu <[EMAIL PROTECTED]>
Date: Wed, 15 Aug 2007 16:33:35 +0800
> [NET]: Fix unbalanced rcu_read_unlock in __sock_create
>
> The recent RCU work created an unbalanced rcu_read_unlock
> in __sock_create. This patch fixes that. Reported by
> oleg 123.
>
> Signed-off-by: Herbert Xu <[E
A similar fix to netfilter from Eric Dumazet inspired me to
look around a bit by using some grep/sed stuff as looking for
this kind of bugs seemed easy to automate. This is one of them
I found where it looks like this semicolon is not valid.
Signed-off-by: Ilpo Järvinen <[EMAIL PROTECTED]>
---
n
From: "Ilpo_Järvinen" <[EMAIL PROTECTED]>
Date: Thu, 16 Aug 2007 00:57:00 +0300 (EEST)
> A similar fix to netfilter from Eric Dumazet inspired me to
> look around a bit by using some grep/sed stuff as looking for
> this kind of bugs seemed easy to automate. This is one of them
> I found where it l
- Added support to unmask entire set of device errors and alarms.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -Nurp orig/drivers/net/s2io.c patch1/drivers/net/s2io.c
--- orig/
- Added support to poll entire set of device errors and alarams.
- Replaced alarm_intr_handler() with s2io_handle_errors().
- Added statistic counters to monitor the alarms.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
Signed-off-by: Ra
- Removed the unused variable, intr_type, in device private structure.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -Nurp patch2/drivers/net/s2io.c patch3/drivers/net/s2io.c
--
- Added check to return from the traffic handling function, if the card status
is DOWN.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -Nurp patch3/drivers/net/s2io.c patch4/d
- Optimized interrupt routine fast path.
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Santosh Rastapur <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -Nurp patch4/drivers/net/s2io.c patch5/drivers/net/s2io.c
--- patch4/drivers/net/s2io.c
- Changed kmalloc+memset to k[zc]alloc as per Mariusz's patch
<[EMAIL PROTECTED]>
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -urpN org/drivers/net/s2io.c patch1/drivers/net/s2io.c
--- org/drivers/net/s2io.c 2007-08-09 1
- Removed bimodal interrupt support - unused feature
Signed-off-by: Sivakumar Subramani <[EMAIL PROTECTED]>
Signed-off-by: Ramkrishna Vepa <[EMAIL PROTECTED]>
---
diff -urpN patch1/drivers/net/s2io.c patch2/drivers/net/s2io.c
--- patch1/drivers/net/s2io.c 2007-08-10 11:53:46.0 +0530
+++
On Wed, Aug 15, 2007 at 10:52:53PM +0200, Segher Boessenkool wrote:
> >>I think this was just terminology confusion here again. Isn't "any
> >>code
> >>that it cannot currently see" the same as "another compilation unit",
> >>and wouldn't the "compilation unit" itself expand if we ask gcc to
> >>c
On Wed, Aug 15, 2007 at 11:05:35PM +0200, Segher Boessenkool wrote:
> >>No; compilation units have nothing to do with it, GCC can optimise
> >>across compilation unit boundaries just fine, if you tell it to
> >>compile more than one compilation unit at once.
> >
> >Last I checked, the Linux kernel
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Fri, 10 Aug 2007 16:56:17 -0400
> All this is currently checked into the 'eflags' branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
>
> But when everybody is happy with it, IMO we should get it into
> net-2.6.24.git, as i
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Mon, 13 Aug 2007 09:24:00 -0400
> Sorry about that. Not sure what happened to that patch. Here is
> the good patch with witespace cleanups.
Applied to net-2.6.24, thanks for fixing this patch up.
-
To unsubscribe from this list: send the line "unsub
1 - 100 of 179 matches
Mail list logo
