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()
actually
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
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 forget to and we
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 which is a major
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/107 :
|
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]: Fix
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 says
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
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
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 volatility?
Not
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 ops are the
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
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 only
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 converting the
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 2007, Adrian Bunk
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 converting the
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 modified / set /
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(atomic_t *a)
{
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
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/Kconfig
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 currently use an
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 atomicity
for SMP
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
requires
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?
Atomic
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
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
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 solution
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.
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 extra
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 give
Hi Alan.
On Wed, Aug 15, 2007 at 04:07:23PM +0100, Alan J. Wylie ([EMAIL PROTECTED])
wrote:
EIP: [c02b6fb2] 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
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 adding
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()
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 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_read(a);
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 volatile semantics
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 files
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 majority of
* 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 start
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 use
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 APIs? Can you
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 files
* 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 new
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 expecting too much
* 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
* 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 u32. The
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 between
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
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
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
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 units
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
* 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 ++
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
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
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:
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 (such as
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 you
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
location.
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 is /expected/
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
[ 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 compilation
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
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 msleep()
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 into other
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 from the same
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 only
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
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 compilation
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
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
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 two reads from the same
location.
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 this
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
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
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
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 [EMAIL
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]
---
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 looks
- 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
---
- 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:
- 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
- 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
- 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
compile more than one
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 build system
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 it
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
From: John W. Linville [EMAIL PROTECTED]
Date: Tue, 14 Aug 2007 20:34:10 -0400
Individual patches available here:
http://www.kernel.org/pub/linux/kernel/people/linville/wireless-2.6/upstream-davem
John, what I'm going to do is wait for Linus to pull in the
2.6.23 mac80211 fixes you
1 - 100 of 174 matches
Mail list logo
