* [PATCH net-next 01/21] tipc: Drop __TIME__ usage
From: Paul Gortmaker @ 2011-05-10 20:44 UTC (permalink / raw)
To: davem; +Cc: netdev, Allan.Stephens, Michal Marek, Allan Stephens,
Paul Gortmaker
In-Reply-To: <1305060277-15600-1-git-send-email-paul.gortmaker@windriver.com>
From: Michal Marek <mmarek@suse.cz>
The kernel already prints its build timestamp during boot, no need to
repeat it in random drivers and produce different object files each
time.
Signed-off-by: Michal Marek <mmarek@suse.cz>
Cc: Jon Maloy <jon.maloy@ericsson.com>
Cc: netdev@vger.kernel.org
Cc: tipc-discussion@lists.sourceforge.net
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/core.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/net/tipc/core.c b/net/tipc/core.c
index c9a73e7..943b6af 100644
--- a/net/tipc/core.c
+++ b/net/tipc/core.c
@@ -179,8 +179,7 @@ static int __init tipc_init(void)
if (tipc_log_resize(CONFIG_TIPC_LOG) != 0)
warn("Unable to create log buffer\n");
- info("Activated (version " TIPC_MOD_VER
- " compiled " __DATE__ " " __TIME__ ")\n");
+ info("Activated (version " TIPC_MOD_VER ")\n");
tipc_own_addr = 0;
tipc_remote_management = 1;
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 05/21] tipc: Remove code to emulate loss of broadcast messages
From: Paul Gortmaker @ 2011-05-10 20:44 UTC (permalink / raw)
To: davem; +Cc: netdev, Allan.Stephens, Allan Stephens, Paul Gortmaker
In-Reply-To: <1305060277-15600-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Eliminates optional code used to test TIPC's ability to recover
from lost broadcast messages. This code duplicates functionality
already provided by the network stack's QoS option "network emulator".
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/bcast.c | 18 ------------------
1 files changed, 0 insertions(+), 18 deletions(-)
diff --git a/net/tipc/bcast.c b/net/tipc/bcast.c
index 7dc1dc7..08e3216 100644
--- a/net/tipc/bcast.c
+++ b/net/tipc/bcast.c
@@ -44,13 +44,6 @@
#define BCLINK_WIN_DEFAULT 20 /* bcast link window size (default) */
-/*
- * Loss rate for incoming broadcast frames; used to test retransmission code.
- * Set to N to cause every N'th frame to be discarded; 0 => don't discard any.
- */
-
-#define TIPC_BCAST_LOSS_RATE 0
-
/**
* struct bcbearer_pair - a pair of bearers used by broadcast link
* @primary: pointer to primary bearer
@@ -434,9 +427,6 @@ int tipc_bclink_send_msg(struct sk_buff *buf)
void tipc_bclink_recv_pkt(struct sk_buff *buf)
{
-#if (TIPC_BCAST_LOSS_RATE)
- static int rx_count;
-#endif
struct tipc_msg *msg = buf_msg(buf);
struct tipc_node *node = tipc_node_find(msg_prevnode(msg));
u32 next_in;
@@ -470,14 +460,6 @@ void tipc_bclink_recv_pkt(struct sk_buff *buf)
return;
}
-#if (TIPC_BCAST_LOSS_RATE)
- if (++rx_count == TIPC_BCAST_LOSS_RATE) {
- rx_count = 0;
- buf_discard(buf);
- return;
- }
-#endif
-
tipc_node_lock(node);
receive:
deferred = node->bclink.deferred_head;
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 04/21] tipc: Cosmetic consolidation of internal message type definitions
From: Paul Gortmaker @ 2011-05-10 20:44 UTC (permalink / raw)
To: davem; +Cc: netdev, Allan.Stephens, Allan Stephens, Paul Gortmaker
In-Reply-To: <1305060277-15600-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Half of the #define entries in msg.h were down at the bottom
of the header, instead of up at the top before any of the static
inlines etc. Relocate them up to the top, to be consistent with
the other normal linux header file layout conventions.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/msg.h | 58 ++++++++++++++++++++++++++++----------------------------
1 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index c5593ac..005b318 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -491,6 +491,35 @@ static inline struct tipc_msg *msg_get_wrapped(struct tipc_msg *m)
#define PUBLICATION 0
#define WITHDRAWAL 1
+/*
+ * Segmentation message types
+ */
+
+#define FIRST_FRAGMENT 0
+#define FRAGMENT 1
+#define LAST_FRAGMENT 2
+
+/*
+ * Link management protocol message types
+ */
+
+#define STATE_MSG 0
+#define RESET_MSG 1
+#define ACTIVATE_MSG 2
+
+/*
+ * Changeover tunnel message types
+ */
+#define DUPLICATE_MSG 0
+#define ORIGINAL_MSG 1
+
+/*
+ * Config protocol message types
+ */
+
+#define DSC_REQ_MSG 0
+#define DSC_RESP_MSG 1
+
/*
* Word 1
@@ -718,35 +747,6 @@ static inline void msg_set_link_tolerance(struct tipc_msg *m, u32 n)
msg_set_bits(m, 9, 0, 0xffff, n);
}
-/*
- * Segmentation message types
- */
-
-#define FIRST_FRAGMENT 0
-#define FRAGMENT 1
-#define LAST_FRAGMENT 2
-
-/*
- * Link management protocol message types
- */
-
-#define STATE_MSG 0
-#define RESET_MSG 1
-#define ACTIVATE_MSG 2
-
-/*
- * Changeover tunnel message types
- */
-#define DUPLICATE_MSG 0
-#define ORIGINAL_MSG 1
-
-/*
- * Config protocol message types
- */
-
-#define DSC_REQ_MSG 0
-#define DSC_RESP_MSG 1
-
u32 tipc_msg_tot_importance(struct tipc_msg *m);
void tipc_msg_init(struct tipc_msg *m, u32 user, u32 type,
u32 hsize, u32 destnode);
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 03/21] tipc: Eliminate unused routing message definitions
From: Paul Gortmaker @ 2011-05-10 20:44 UTC (permalink / raw)
To: davem; +Cc: netdev, Allan.Stephens, Allan Stephens, Paul Gortmaker
In-Reply-To: <1305060277-15600-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Gets rid of unused constants defining the types used in routing
messages. These messages no longer exist in TIPC now that multicluster
and multizone support has been eliminated.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/msg.h | 9 ---------
1 files changed, 0 insertions(+), 9 deletions(-)
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index d098317..c5593ac 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -741,15 +741,6 @@ static inline void msg_set_link_tolerance(struct tipc_msg *m, u32 n)
#define ORIGINAL_MSG 1
/*
- * Routing table message types
- */
-#define EXT_ROUTING_TABLE 0
-#define LOCAL_ROUTING_TABLE 1 /* obsoleted */
-#define SLAVE_ROUTING_TABLE 2
-#define ROUTE_ADDITION 3
-#define ROUTE_REMOVAL 4
-
-/*
* Config protocol message types
*/
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 02/21] tipc: Update comments in message header include file
From: Paul Gortmaker @ 2011-05-10 20:44 UTC (permalink / raw)
To: davem; +Cc: netdev, Allan.Stephens, Allan Stephens, Paul Gortmaker
In-Reply-To: <1305060277-15600-1-git-send-email-paul.gortmaker@windriver.com>
From: Allan Stephens <allan.stephens@windriver.com>
Removes comments in TIPC's message header include file that are
outdated and/or unnecessary. Also introduces short comments (or
supplements existing ones) to better describe several set of existing
symbolic constants.
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
net/tipc/msg.h | 89 ++++++++++++++-----------------------------------------
1 files changed, 23 insertions(+), 66 deletions(-)
diff --git a/net/tipc/msg.h b/net/tipc/msg.h
index de02339..d098317 100644
--- a/net/tipc/msg.h
+++ b/net/tipc/msg.h
@@ -39,41 +39,24 @@
#include "bearer.h"
+/*
+ * Constants and routines used to read and write TIPC payload message headers
+ *
+ * Note: Some items are also used with TIPC internal message headers
+ */
+
#define TIPC_VERSION 2
/*
- * TIPC user data message header format, version 2:
- *
- *
- * 1 0 9 8 7 6 5 4|3 2 1 0 9 8 7 6|5 4 3 2 1 0 9 8|7 6 5 4 3 2 1 0
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w0:|vers | user |hdr sz |n|d|s|-| message size |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w1:|mstyp| error |rer cnt|lsc|opt p| broadcast ack no |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w2:| link level ack no | broadcast/link level seq no |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w3:| previous node |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w4:| originating port |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w5:| destination port |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w6:| originating node |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w7:| destination node |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w8:| name type / transport sequence number |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * w9:| name instance/multicast lower bound |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * wA:| multicast upper bound |
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- * / /
- * \ options \
- * / /
- * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- *
+ * Payload message users are defined in TIPC's public API:
+ * - TIPC_LOW_IMPORTANCE
+ * - TIPC_MEDIUM_IMPORTANCE
+ * - TIPC_HIGH_IMPORTANCE
+ * - TIPC_CRITICAL_IMPORTANCE
+ */
+
+/*
+ * Payload message types
*/
#define TIPC_CONN_MSG 0
@@ -81,6 +64,9 @@
#define TIPC_NAMED_MSG 2
#define TIPC_DIRECT_MSG 3
+/*
+ * Message header sizes
+ */
#define SHORT_H_SIZE 24 /* Connected, in-cluster messages */
#define DIR_MSG_H_SIZE 32 /* Directly addressed messages */
@@ -473,40 +459,11 @@ static inline struct tipc_msg *msg_get_wrapped(struct tipc_msg *m)
/*
- TIPC internal message header format, version 2
-
- 1 0 9 8 7 6 5 4|3 2 1 0 9 8 7 6|5 4 3 2 1 0 9 8|7 6 5 4 3 2 1 0
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w0:|vers |msg usr|hdr sz |n|resrv| packet size |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w1:|m typ| sequence gap | broadcast ack no |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w2:| link level ack no/bc_gap_from | seq no / bcast_gap_to |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w3:| previous node |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w4:| next sent broadcast/fragm no | next sent pkt/ fragm msg no |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w5:| session no |rsv=0|r|berid|link prio|netpl|p|
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w6:| originating node |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w7:| destination node |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w8:| transport sequence number |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- w9:| msg count / bcast tag | link tolerance |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- \ \
- / User Specific Data /
- \ \
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- NB: CONN_MANAGER use data message format. LINK_CONFIG has own format.
-*/
+ * Constants and routines used to read and write TIPC internal message headers
+ */
/*
- * Internal users
+ * Internal message users
*/
#define BCAST_PROTOCOL 5
@@ -520,7 +477,7 @@ static inline struct tipc_msg *msg_get_wrapped(struct tipc_msg *m)
#define LINK_CONFIG 13
/*
- * Connection management protocol messages
+ * Connection management protocol message types
*/
#define CONN_PROBE 0
@@ -528,7 +485,7 @@ static inline struct tipc_msg *msg_get_wrapped(struct tipc_msg *m)
#define CONN_ACK 2
/*
- * Name distributor messages
+ * Name distributor message types
*/
#define PUBLICATION 0
--
1.7.4.4
^ permalink raw reply related
* [PATCH net-next 00/21] tipc updates for the next round
From: Paul Gortmaker @ 2011-05-10 20:44 UTC (permalink / raw)
To: davem; +Cc: netdev, Allan.Stephens, Paul Gortmaker
Another mixed bag of tipc commits. It leads off with some largely
cosmetic stuff, but then gets into what should be some more of the
useful/functional fixes with a bit more complexity. There really
isn't any new functionality here -- just fixes or robustness type
improvements.
Paul.
---
The following changes since commit 7ef73bca731fea9d4b706db2acb96b6488aa1b0e:
sctp: Fix debug message args. (2011-05-08 21:24:07 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/paulg/net-next-2.6.git tipc-May10-2011
Allan Stephens (19):
tipc: Update comments in message header include file
tipc: Eliminate unused routing message definitions
tipc: Cosmetic consolidation of internal message type definitions
tipc: Remove code to emulate loss of broadcast messages
tipc: Don't initialize link selector field in fragmented messages
tipc: Avoid pointless masking of fragmented message identifier
tipc: Fix issues with fragmentation of an existing message buffer
tipc: Set name lookup scope field properly in all data messages
tipc: Fix problem with bundled multicast message
tipc: Update destination node field on incoming multicast messages
tipc: Fix sk_buff leaks when link congestion is detected
tipc: Strengthen checks for neighboring node discovery
tipc: Abort excessive send requests as early as possible
tipc: Avoid recomputation of outgoing message length
tipc: Introduce routine to enqueue a chain of messages on link tx queue
tipc: Enhance handling of discovery object creation failures
tipc: Enhance sending of discovery object link request messages
tipc: Add monitoring of number of nodes discovered by bearer
tipc: Revise timings used when sending link request messages
Michal Marek (1):
tipc: Drop __TIME__ usage
Paul Gortmaker (1):
tipc: make zone/cluster mask constants a define
include/linux/tipc.h | 2 +-
net/tipc/addr.h | 7 ++-
net/tipc/bcast.c | 22 +-------
net/tipc/bearer.c | 45 +++++++++-----
net/tipc/core.c | 3 +-
net/tipc/discover.c | 150 +++++++++++++++++++++++++++++-----------------
net/tipc/discover.h | 11 ++--
net/tipc/link.c | 104 +++++++++++++++++++--------------
net/tipc/link.h | 1 +
net/tipc/msg.c | 25 +-------
net/tipc/msg.h | 161 +++++++++++++++++---------------------------------
net/tipc/port.c | 55 ++++++++++-------
net/tipc/port.h | 14 +++--
net/tipc/socket.c | 27 +++++++--
net/tipc/subscr.c | 4 +-
15 files changed, 321 insertions(+), 310 deletions(-)
--
1.7.4.4
^ permalink raw reply
* Re: [Bugme-new] [Bug 33502] New: Caught 64-bit read from uninitialized memory in __alloc_skb
From: Christoph Lameter @ 2011-05-10 20:33 UTC (permalink / raw)
To: Eric Dumazet
Cc: Vegard Nossum, Pekka Enberg, casteyde.christian, Andrew Morton,
netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1305057989.2437.18.camel@edumazet-laptop>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 943 bytes --]
On Tue, 10 May 2011, Eric Dumazet wrote:
> Le mardi 10 mai 2011 à 14:38 -0500, Christoph Lameter a écrit :
>
> > Optimizing? You think about this as concurrency issue between multiple
> > cpus. That is fundamentally wrong. This is dealing with access to per cpu
> > data and the concurrency issues are only with code running on the *same*
> > cpu.
> >
>
> If you enable irqs, then this object can be allocated by _this_ cpu and
> given to another one.
That will cause an incrementing of the tid.
> Another cpu can free the page, forcing you to call a very expensive
> function, that might give obsolete result as soon it returns.
No the other cpu cannot free the page since the page is pinned by
the current cpu (see PageFrozen()).
> Maybe I am just tired tonight, this seems very obvious, I must miss
> something.
Yeah you are way off thinking about cpu to cpu concurrency issues that do
not apply here.
^ permalink raw reply
* Re: [PATCHv2 net-next-2.6] ethtool: Added support for FW dump
From: Anirban Chakraborty @ 2011-05-10 20:22 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, David Miller
In-Reply-To: <1305052186.2859.47.camel@bwh-desktop>
On May 10, 2011, at 11:29 AM, Ben Hutchings wrote:
> On Mon, 2011-05-09 at 18:02 -0700, Anirban Chakraborty wrote:
>> Added code to take FW dump via ethtool. A pair of set and get functions are
>> added to configure dump level and fetch dump data from the driver respectively.
>
> I don't understand why you are combining get-flags and get-data in the
> driver interface. I suggested that you could use a single option for
> these in the ethtool *utility*, but combining them in the driver
> interface just seems to complicate the implementation of the ethtool
> core code and the driver.
I was under the impression that you wanted to collapse get data and flag into one operation,
both in ethtool and in the driver. Will change it in next version.
>
>> Signed-off-by: Anirban Chakraborty <anirban.chakraborty@qlogic.com>
>> ---
>> include/linux/ethtool.h | 31 +++++++++++++++++++++++
>> net/core/ethtool.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 93 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/linux/ethtool.h b/include/linux/ethtool.h
>> index bd0b50b..f2cd7e1 100644
>> --- a/include/linux/ethtool.h
>> +++ b/include/linux/ethtool.h
>> @@ -601,6 +601,31 @@ struct ethtool_flash {
>> char data[ETHTOOL_FLASH_MAX_FILENAME];
>> };
>>
>> +/**
>> + * struct ethtool_dump - used for retrieving, setting device dump
>
> Missing description of @cmd.
>
>> + * @type: type of operation, get dump settings or data
>> + * @version: FW version of the dump
>> + * @flag: flag for dump setting
>> + * @len: length of dump data
>> + * @data: data collected for this command
>
> The kernel-doc needs to describe when the fields are valid - i.e. which
> commands use them as input and/or output.
Will fix.
> <snip>
>>
>> +
>> + data = vzalloc(dump.len);
>> + if (!data)
>> + return -ENOMEM;
>> + ret = ops->get_dump(dev, &dump, data);
>> + if (ret) {
>> + ret = -EFAULT;
>
> There is no reason to change ret here. Didn't I already raise this in
> version 1?
Yes you did. Although I fixed others, but some how I missed this one.
>
>> + goto out;
>> + }
>> + useraddr += offsetof(struct ethtool_dump, data);
>> + if (copy_to_user(useraddr, data, dump.len))
>
> The copied length should be the *minimum* of the user's buffer length
> and the actual dump length.
Will fix it.
^ permalink raw reply
* Re: [PATCH] net/usb: mark LG VL600 LTE modem ethernet interface as WWAN
From: David Miller @ 2011-05-10 20:14 UTC (permalink / raw)
To: dcbw; +Cc: netdev, andrew.zaborowski, oneukum
In-Reply-To: <1304963011.5005.5.camel@dcbw.foobar.com>
From: Dan Williams <dcbw@redhat.com>
Date: Mon, 09 May 2011 12:43:20 -0500
> Like other mobile broadband device ethernet interfaces, mark the LG
> VL600 with the 'wwan' devtype so userspace knows it needs additional
> configuration via the AT port before the interface can be used.
>
> Signed-off-by: Dan Williams <dcbw@redhat.com>
Applied, thanks.
^ permalink raw reply
* Re: slcan: fix ldisc->open retval
From: David Miller @ 2011-05-10 20:12 UTC (permalink / raw)
To: socketcan; +Cc: netdev, matvejchikov
In-Reply-To: <4DC8D681.8000602@hartkopp.net>
From: Oliver Hartkopp <socketcan@hartkopp.net>
Date: Tue, 10 May 2011 08:09:05 +0200
> TTY layer expects 0 if the ldisc->open operation succeeded.
>
> Reported-by: Matvejchikov Ilya <matvejchikov@gmail.com>
> Signed-off-by: Oliver Hartkopp <socketcan@hartkopp.net>
Applied, thanks.
^ permalink raw reply
* [ANNOUNCE] IPTV-Analyzer project released v0.9.0
From: Jesper Dangaard Brouer @ 2011-05-10 20:03 UTC (permalink / raw)
To: hawk
I'm happy to announce the first official release of the IPTV-Analyzer
project, as an Open Source project.
Homepage:
http://www.iptv-analyzer.org
Git tree:
https://github.com/netoptimizer/IPTV-Analyzer
The IPTV-Analyzer is a continuous/real-time tool for analyzing the
contents of MPEG2 Transport Stream (TS) packets, which is commonly
used for IPTV multicast signals. The main purpose is continuous
quality measurement, with a focus on detecting MPEG2 TS/CC packet
drops.
The core component is an iptables (Linux) kernel module, named
"mpeg2ts". This kernel module performs the real-time Deep Packet
Inspection of the MPEG2-TS packets. Its highly performance optimized,
written for parallel processing across CPU cores (via RCU locking) and
hash tables are used for handling large number of streams. Statistics
are exported via the proc filesystem (scalability is achieved via use
of the seq_file proc API). It scales to hundreds of IPTV channels,
even on small ATOM based CPUs.
Please send bugreports, patches, improvement, comments or insults to:
hawk@comx.dk
--
Best regards,
Jesper Dangaard Brouer
ComX Networks A/S
Linux Network Kernel Developer
Cand. Scient Datalog / MSc.CS
Author of http://adsl-optimizer.dk
LinkedIn: http://www.linkedin.com/in/brouer
^ permalink raw reply
* Re: [Bugme-new] [Bug 33502] New: Caught 64-bit read from uninitialized memory in __alloc_skb
From: Eric Dumazet @ 2011-05-10 20:06 UTC (permalink / raw)
To: Christoph Lameter
Cc: Vegard Nossum, Pekka Enberg, casteyde.christian, Andrew Morton,
netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <alpine.DEB.2.00.1105101435480.4023@router.home>
Le mardi 10 mai 2011 à 14:38 -0500, Christoph Lameter a écrit :
> Optimizing? You think about this as concurrency issue between multiple
> cpus. That is fundamentally wrong. This is dealing with access to per cpu
> data and the concurrency issues are only with code running on the *same*
> cpu.
>
If you enable irqs, then this object can be allocated by _this_ cpu and
given to another one.
Another cpu can free the page, forcing you to call a very expensive
function, that might give obsolete result as soon it returns.
Maybe I am just tired tonight, this seems very obvious, I must miss
something.
^ permalink raw reply
* Re: [PATCH v2] net: ipv4: add IPPROTO_ICMP socket kind
From: Vasiliy Kulikov @ 2011-05-10 19:45 UTC (permalink / raw)
To: David Miller
Cc: solar, linux-kernel, netdev, peak, kees.cook, dan.j.rosenberg,
eugene, nelhage, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20110510.121550.112583080.davem@davemloft.net>
On Tue, May 10, 2011 at 12:15 -0700, David Miller wrote:
> A lot has changed in this area, your code won't even compile, so
> please adjust your patch to fit net-next-2.6 as needed, perhaps
> using net/ipv4/raw.c and net/ipv4/udp.c as a guide.
Sure, will do it.
Thanks!
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [Bugme-new] [Bug 33502] New: Caught 64-bit read from uninitialized memory in __alloc_skb
From: Christoph Lameter @ 2011-05-10 19:38 UTC (permalink / raw)
To: Eric Dumazet
Cc: Vegard Nossum, Pekka Enberg, casteyde.christian, Andrew Morton,
netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <1305055948.2437.13.camel@edumazet-laptop>
On Tue, 10 May 2011, Eric Dumazet wrote:
> > > You have to disable IRQ _before_ even fetching 'object'
> >
> > The object pointer is being obtained from a per cpu structure and
> > not from the page. What is the problem with fetching the object pointer?
> >
> > > Or else, you can have an IRQ, allocate this object, pass to another cpu.
> >
> > If that occurs then TID is being incremented and we will restart the loop
> > getting the new object pointer from the per cpu structure. The object
> > pointer that we were considering is irrelevant.
> >
>
> Problem is not restart the loop, but avoiding accessing a non valid
> memory area.
Yes and could you please explain clearly what the problem is?
>
> > > This other cpu can free the object and unmap page right after you did
> > > the probe_kernel_address(object) (successfully), and before your cpu :
> > >
> > > p = get_freepointer(s, object); << BUG >>
> >
> > If the other cpu frees the object and unmaps the page then
> > get_freepointer_safe() can obtain an arbitrary value since the TID was
> > incremented. We will restart the loop and discard the value retrieved.
> >
>
>
>
> In current code I see :
>
> tid = c->tid;
> barrier();
> object = c->freelist;
>
> There is no guarantee c->tid is fetched before c->freelist by cpu.
>
> You need rmb() here.
Nope. This is not processor to processor concurrency. this_cpu operations
only deal with concurrency issues on the same processor. I.e. interrupts
and preemption.
> I claim all this would be far more simple disabling IRQ before fetching
> c->tid and c->freelist, in DEBUG_PAGE_ALLOC case.
>
> You would not even need to use magic probe_kernel_read()
>
>
> Why do you try so _hard_ trying to optimize this, I really wonder.
> Nobody is able to read this code anymore and prove its correct.
Optimizing? You think about this as concurrency issue between multiple
cpus. That is fundamentally wrong. This is dealing with access to per cpu
data and the concurrency issues are only with code running on the *same*
cpu.
^ permalink raw reply
* Re: [PATCH 3/3] RFC gianfar: add rx_ntuple feature
From: Ben Hutchings @ 2011-05-10 19:38 UTC (permalink / raw)
To: Sebastian.Poehn; +Cc: netdev
In-Reply-To: <OF56049997.B9542799-ON8525788C.00470640-8525788C.00470642@BeldenCDT.com>
As a general warning, you may find that the RX NFC interface makes more
sense. So far only ixgbe and sfc implement the RX n-tuple interface and
ixgbe will be moving to RX NFC.
I don't know quite what the capabilities of this hardware are, so it may
be that RX NFC doesn't make much sense.
On Tue, 2011-05-10 at 08:55 -0400, Sebastian.Poehn@Belden.com wrote:
> This is the main part. Functionality to add and remove ntuples,
> conversion from ntuple to hardware binary rx filer format,
> optimization of hardware filer table entries and extended hardware
> capability check.
>
> --- gianfar_ethtool.c.orig 2011-05-10 11:45:33.301745000 +0200
> +++ gianfar_ethtool.c 2011-05-10 13:27:23.041744819 +0200
Diffs should be made from above the linux-2.6 directory (or using 'git
diff' or similar).
> @@ -42,6 +42,8 @@
>
> extern void gfar_start(struct net_device *dev);
> extern int gfar_clean_rx_ring(struct gfar_priv_rx_q *rx_queue, int rx_work_limit);
> +extern void sort(void *, size_t, size_t, int(*cmp_func)(const void *,
> + const void *), void(*swap_func)(void *, void *, int size));
Why are you declaring this here rather than including <linux/sort.h>?
> #define GFAR_MAX_COAL_USECS 0xffff
> #define GFAR_MAX_COAL_FRAMES 0xff
> @@ -787,6 +789,1011 @@ static int gfar_set_nfc(struct net_devic
> return ret;
> }
>
> +/*Global pointer on table*/
> +struct filer_table *ref;
> +u32 filer_index;
> +struct interf *queue;
> +
> +enum nop {
> + ASC = 0, DESC = 1
> +} row;
Is this global state really necessary? I think not.
> +static inline void toggle_order(void)
> +{
> + row ^= 1;
> +}
> +
> +static int my_comp(const void *a, const void *b)
> +{
> +
> + signed int temp;
> + if (*(u32 *) a > *(u32 *) b)
> + temp = -1;
> + else if (*(u32 *) a == *(u32 *) b)
> + temp = 0;
> + else
> + temp = 1;
> +
> + if (row == DESC)
> + return temp;
> + else
> + return -temp;
> +}
Use a second comparison function to reverse the order.
> +static void my_swap(void *a, void *b, int size)
> +{
> + u32 t1 = *(u32 *) a;
> + u32 t2 = *(u32 *) (a + 4);
> + u32 t3 = *(u32 *) (a + 8);
> + u32 t4 = *(u32 *) (a + 12);
> + *(u32 *) a = *(u32 *) b;
> + *(u32 *) (a + 4) = *(u32 *) (b + 4);
> + *(u32 *) (a + 8) = *(u32 *) (b + 8);
> + *(u32 *) (a + 12) = *(u32 *) (b + 12);
> + *(u32 *) b = t1;
> + *(u32 *) (b + 4) = t2;
> + *(u32 *) (b + 8) = t3;
> + *(u32 *) (b + 12) = t4;
> +}
> +
> +/*Write a mask to hardware*/
> +static inline void set_mask(u32 mask)
> +{
> + ref->fe[filer_index].ctrl = RQFCR_AND | RQFCR_PID_MASK
> + | RQFCR_CMP_EXACT;
> + ref->fe[filer_index].prop = mask;
> + filer_index++;
> +}
> +
> +/*Sets parse bits (e.g. IP or TCP)*/
> +static void set_parse_bits(u32 host, u32 mask)
> +{
> + set_mask(mask);
> + ref->fe[filer_index].ctrl = RQFCR_CMP_EXACT | RQFCR_PID_PARSE
> + | RQFCR_AND;
> + ref->fe[filer_index].prop = host;
> + filer_index++;
> +}
> +
> +/*For setting a tuple of host,mask of type flag
> + *Example:
> + *IP-Src = 10.0.0.0/255.0.0.0
> + *host: 0x0A000000 mask: FF000000 flag: RQFPR_IPV4
> + *Note:
> + *For better usage of hardware 16 and 8 bit masks should be filled up
> + *with ones*/
> +static void set_attribute(unsigned int host, unsigned int mask,
> + unsigned int flag)
It would be clearer to rename 'host' as 'value'.
> +{
> + if (host || ~mask) {
If all bits are masked then the 'host' value must be ignored. So just
check ~mask.
> + /*This is to deal with masks smaller than 32bit
> + * and for special processing of MAC-filtering and
> + * VLAN-filtering*/
> + switch (flag) {
> + /*3bit*/
> + case RQFCR_PID_PRI:
> + if (((host & 0x7) == 0) && ((mask & 0x7) == 0))
> + return;
Doesn't this mean that an n-tuple filter that should match priority 0
will actually match all priority values?
> + host &= 0x7;
> + break;
> + /*8bit*/
> + case RQFCR_PID_L4P:
> + case RQFCR_PID_TOS:
> + if (!(mask & 0xFF))
> + mask = 0xFFFFFFFF;
I don't understand this special case. Are you sure you shouldn't be
using something like:
mask ^= 0xff;
> + break;
> + /*12bit*/
> + case RQFCR_PID_VID:
> + if (((host & 0xFFF) == 0) && ((mask & 0xFFF) == 0))
> + return;
Again, this seems to mean that a filter that should match VID 0 (i.e.
untagged) will match both tagged and untagged frames.
> + host &= 0xFFF;
> + break;
> + /*16bit*/
> + case RQFCR_PID_DPT:
> + case RQFCR_PID_SPT:
> + case RQFCR_PID_ETY:
> + if (!(mask & 0xFFFF))
> + mask = 0xFFFFFFFF;
Again, I don't understand this special case.
> + break;
> + /*24bit*/
> + case RQFCR_PID_DAH:
> + case RQFCR_PID_DAL:
> + case RQFCR_PID_SAH:
> + case RQFCR_PID_SAL:
> + host &= 0x00FFFFFF;
> + break;
> + /*for all real 32bit masks*/
> + default:
> + if (!mask)
> + mask = 0xFFFFFFFF;
> + break;
> + }
> +
> + set_mask(mask);
> + ref->fe[filer_index].ctrl = RQFCR_CMP_EXACT | RQFCR_AND | flag;
> + ref->fe[filer_index].prop = host;
> + filer_index++;
> + }
> +}
> +
> +/*Translates host and mask for UDP,TCP or SCTP*/
> +static void set_basic_ip(struct ethtool_tcpip4_spec *host,
> + struct ethtool_tcpip4_spec *mask)
> +{
> + set_attribute(host->ip4src, mask->ip4src, RQFCR_PID_SIA);
> + set_attribute(host->ip4dst, mask->ip4dst, RQFCR_PID_DIA);
> + set_attribute(host->pdst, mask->pdst | 0xFFFF0000, RQFCR_PID_DPT);
> + set_attribute(host->psrc, mask->psrc | 0xFFFF0000, RQFCR_PID_SPT);
> + set_attribute(host->tos, mask->tos | 0xFFFFFF00, RQFCR_PID_TOS);
> +}
> +
> +/*Translates host and mask for USER-IP4*/
> +static inline void set_user_ip(struct ethtool_usrip4_spec *host,
> + struct ethtool_usrip4_spec *mask)
> +{
> +
> + set_attribute(host->ip4src, mask->ip4src, RQFCR_PID_SIA);
> + set_attribute(host->ip4dst, mask->ip4dst, RQFCR_PID_DIA);
> + set_attribute(host->tos, mask->tos | 0xFFFFFF00, RQFCR_PID_TOS);
> + set_attribute(host->proto, mask->proto | 0xFFFFFF00, RQFCR_PID_L4P);
> + set_attribute(host->l4_4_bytes, mask->l4_4_bytes, RQFCR_PID_ARB);
> +
> +}
> +
> +/*Translates host and mask for ETHER spec*/
> +static inline void set_ether(struct ethhdr *host, struct ethhdr *mask)
> +{
> + u32 upper_temp_mask = 0;
> + u32 lower_temp_mask = 0;
> + /*Source address*/
> + if (!(is_zero_ether_addr(host->h_source) && is_broadcast_ether_addr(
> + mask->h_source))) {
Just check !is_broadcast_ether_addr(mask->h_source).
> + if (is_zero_ether_addr(mask->h_source)) {
> + upper_temp_mask = 0xFFFFFFFF;
> + lower_temp_mask = 0xFFFFFFFF;
> + } else {
> + upper_temp_mask = mask->h_source[0] << 16
> + | mask->h_source[1] << 8
> + | mask->h_source[2] | 0xFF000000;
> + lower_temp_mask = mask->h_source[3] << 16
> + | mask->h_source[4] << 8
> + | mask->h_source[5] | 0xFF000000;
> + }
> + /*Upper 24bit*/
> + set_attribute(0x80000000 | host->h_source[0] << 16
> + | host->h_source[1] << 8 | host->h_source[2],
> + upper_temp_mask, RQFCR_PID_SAH);
> + /*And the same for the lower part*/
> + set_attribute(0x80000000 | host->h_source[3] << 16
> + | host->h_source[4] << 8 | host->h_source[5],
> + lower_temp_mask, RQFCR_PID_SAL);
> + }
> + /*Destination address*/
> + if (!(is_zero_ether_addr(host->h_dest) && is_broadcast_ether_addr(
> + mask->h_dest))) {
Similarly here, just test the mask.
> + /*Special for destination is limited broadcast*/
> + if ((is_broadcast_ether_addr(host->h_dest)
> + && is_zero_ether_addr(mask->h_dest))) {
> + set_parse_bits(RQFPR_EBC, RQFPR_EBC);
> + } else {
> +
> + if (is_zero_ether_addr(mask->h_dest)) {
> + upper_temp_mask = 0xFFFFFFFF;
> + lower_temp_mask = 0xFFFFFFFF;
> + } else {
> + upper_temp_mask = mask->h_dest[0] << 16
> + | mask->h_dest[1] << 8
> + | mask->h_dest[2] | 0xFF000000;
> + lower_temp_mask = mask->h_dest[3] << 16
> + | mask->h_dest[4] << 8
> + | mask->h_dest[5] | 0xFF000000;
> + }
> +
> + /*Upper 24bit*/
> + set_attribute(0x80000000 | host->h_dest[0] << 16
> + | host->h_dest[1] << 8
> + | host->h_dest[2], upper_temp_mask,
> + RQFCR_PID_DAH);
> + /*And the same for the lower part*/
> + set_attribute(0x80000000 | host->h_dest[3] << 16
> + | host->h_dest[4] << 8
> + | host->h_dest[5], lower_temp_mask,
> + RQFCR_PID_DAL);
> + }
> + }
> +
> + /*Set Ethertype*/
> + if ((host->h_proto || ~(mask->h_proto | 0xFFFF0000))) {
Similarly here, just test the mask.
> + set_attribute(host->h_proto, mask->h_proto | 0xFFFF0000,
> + RQFCR_PID_ETY);
> + }
> +
> + /*
> + * Question: What the hell does the 0x80000000 do?
> + * Answer: It is just a dirty hack to prevent the setAtribute()
> + * to ignore a half MAC address which is like 0x000000/0xFFFFFF
> + */
Why would it do that?
Is a filter that matches only upper or only lower 24 bits of a MAC
address invalid?
[Skipped more stuff; I haven't got time to review all of this.]
[...]
> +static int gfar_set_rx_ntuple(struct net_device *dev,
> + struct ethtool_rx_ntuple *cmd)
> +{ struct gfar __iomem *regs = NULL;
> + struct gfar_private *priv = netdev_priv(dev);
> + int i = 0;
> + static struct interf *store[10];
> +
> + regs = priv->gfargrp[0].regs;
> +
> + /*Only values between -2 and num_rx_queues -1 allowed*/
> + if ((cmd->fs.action >= (signed int)priv->num_rx_queues) ||
> + (cmd->fs.action < ETHTOOL_RXNTUPLE_ACTION_CLEAR))
> + return -EINVAL;
> +
> + for (i = 0; i < 10; i++) {
> + if (store[i] == 0) {
> + store[i] = init_table(priv);
> + if (store[i] == (struct interf *)-1) {
> + store[i] = 0;
> + return -1;
> + }
> + strcpy(store[i]->name, dev->name);
> + break;
> + } else if (!strcmp(store[i]->name, dev->name)) {
> + queue = store[i];
> + break;
> + }
> +
> + }
Why aren't you putting this state in struct gfar_private?
You can't use name as a key anyway; interfaces can be renamed.
> + do_action(&cmd->fs, priv);
> +
> + return 0;
> +}
> +
> +
> const struct ethtool_ops gfar_ethtool_ops = {
> .get_settings = gfar_gsettings,
> .set_settings = gfar_ssettings,
> @@ -808,4 +1815,6 @@ const struct ethtool_ops gfar_ethtool_op
> .set_wol = gfar_set_wol,
> #endif
> .set_rxnfc = gfar_set_nfc,
> + /*function for accessing rx queue filer*/
> + .set_rx_ntuple = gfar_set_rx_ntuple
> };
>
> Signed-off-by: Sebastian Poehn <sebastian.poehn@belden.com>
This belongs at the top, but is not important for an RFC anyway.
> DISCLAIMER:
>
> Privileged and/or Confidential information may be contained in this
> message. If you are not the addressee of this message, you may not
> copy, use or deliver this message to anyone. In such event, you
> should destroy the message and kindly notify the sender by reply
> e-mail. It is understood that opinions or conclusions that do not
> relate to the official business of the company are neither given
> nor endorsed by the company.
Well this wasn't sent specifically to me, so am I in trouble now?
Please get rid of this nonsense.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [Bugme-new] [Bug 33502] New: Caught 64-bit read from uninitialized memory in __alloc_skb
From: Eric Dumazet @ 2011-05-10 19:32 UTC (permalink / raw)
To: Christoph Lameter
Cc: Vegard Nossum, Pekka Enberg, casteyde.christian, Andrew Morton,
netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <alpine.DEB.2.00.1105101323290.4023@router.home>
Le mardi 10 mai 2011 à 13:28 -0500, Christoph Lameter a écrit :
> On Tue, 10 May 2011, Eric Dumazet wrote:
>
> > > + else
> > > + p = get_freepointer(s, object);
> > > +
> > > + local_irq_restore(flags);
> > > +#else
> > > + p = get_freepointer(s, object);
> > > +#endif
> > > + return p;
> > > +}
> > > +
> > > static inline void set_freepointer(struct kmem_cache *s, void *object, void *fp)
> > > {
> > > *(void **)(object + s->offset) = fp;
> > > @@ -1933,7 +1954,7 @@ redo:
> > > if (unlikely(!irqsafe_cpu_cmpxchg_double(
> > > s->cpu_slab->freelist, s->cpu_slab->tid,
> > > object, tid,
> > > - get_freepointer(s, object), next_tid(tid)))) {
> > > + get_freepointer_safe(s, object), next_tid(tid)))) {
> > >
> > > note_cmpxchg_failure("slab_alloc", s, tid);
> > > goto redo;
> >
> >
> > Really this wont work Stephen
>
> I am not Stephen.
>
Yes, sorry Christoph.
> > You have to disable IRQ _before_ even fetching 'object'
>
> The object pointer is being obtained from a per cpu structure and
> not from the page. What is the problem with fetching the object pointer?
>
> > Or else, you can have an IRQ, allocate this object, pass to another cpu.
>
> If that occurs then TID is being incremented and we will restart the loop
> getting the new object pointer from the per cpu structure. The object
> pointer that we were considering is irrelevant.
>
Problem is not restart the loop, but avoiding accessing a non valid
memory area.
> > This other cpu can free the object and unmap page right after you did
> > the probe_kernel_address(object) (successfully), and before your cpu :
> >
> > p = get_freepointer(s, object); << BUG >>
>
> If the other cpu frees the object and unmaps the page then
> get_freepointer_safe() can obtain an arbitrary value since the TID was
> incremented. We will restart the loop and discard the value retrieved.
>
In current code I see :
tid = c->tid;
barrier();
object = c->freelist;
There is no guarantee c->tid is fetched before c->freelist by cpu.
You need rmb() here.
I claim all this would be far more simple disabling IRQ before fetching
c->tid and c->freelist, in DEBUG_PAGE_ALLOC case.
You would not even need to use magic probe_kernel_read()
Why do you try so _hard_ trying to optimize this, I really wonder.
Nobody is able to read this code anymore and prove its correct.
^ permalink raw reply
* Re: [PATCH] xfrm: Don't allow esn with disabled anti replay detection
From: David Miller @ 2011-05-10 19:28 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20110510054305.GC8013@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 10 May 2011 07:43:05 +0200
> Unlike the standard case, disabled anti replay detection needs some
> nontrivial extra treatment on ESN. RFC 4303 states:
>
> Note: If a receiver chooses to not enable anti-replay for an SA, then
> the receiver SHOULD NOT negotiate ESN in an SA management protocol.
> Use of ESN creates a need for the receiver to manage the anti-replay
> window (in order to determine the correct value for the high-order
> bits of the ESN, which are employed in the ICV computation), which is
> generally contrary to the notion of disabling anti-replay for an SA.
>
> So return an error if an ESN state with disabled anti replay detection
> is inserted for now and add the extra treatment later if we need it.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Also applied, thanks for fixing these bugs!
^ permalink raw reply
* Re: [PATCH] xfrm: Assign the inner mode output function to the dst entry
From: David Miller @ 2011-05-10 19:28 UTC (permalink / raw)
To: steffen.klassert; +Cc: herbert, netdev
In-Reply-To: <20110510053638.GB8013@secunet.com>
From: Steffen Klassert <steffen.klassert@secunet.com>
Date: Tue, 10 May 2011 07:36:38 +0200
> As it is, we assign the outer modes output function to the dst entry
> when we create the xfrm bundle. This leads to two problems on interfamily
> scenarios. We might insert ipv4 packets into ip6_fragment when called
> from xfrm6_output. The system crashes if we try to fragment an ipv4
> packet with ip6_fragment. This issue was introduced with git commit
> ad0081e4 (ipv6: Fragment locally generated tunnel-mode IPSec6 packets
> as needed). The second issue is, that we might insert ipv4 packets in
> netfilter6 and vice versa on interfamily scenarios.
>
> With this patch we assign the inner mode output function to the dst entry
> when we create the xfrm bundle. So xfrm4_output/xfrm6_output from the inner
> mode is used and the right fragmentation and netfilter functions are called.
> We switch then to outer mode with the output_finish functions.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Applied.
^ permalink raw reply
* Re: oops during unregister_netdevice interface enslaved to bond - regression
From: David Miller @ 2011-05-10 19:26 UTC (permalink / raw)
To: eric.dumazet; +Cc: blaschka, netdev, ELELUECK, opurdila
In-Reply-To: <1305034619.2614.37.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 May 2011 15:36:59 +0200
> [PATCH net-2.6] net: dev_close() should check IFF_UP
Applied, thanks Eric.
^ permalink raw reply
* Re: oops during unregister_netdevice interface enslaved to bond - regression
From: David Miller @ 2011-05-10 19:25 UTC (permalink / raw)
To: ELELUECK; +Cc: netdev, Frank.Blaschka
In-Reply-To: <OF0F4919C3.B9CFCAE8-ONC125788C.002D5EB1-C125788C.002D83B7@de.ibm.com>
From: Einar EL Lueck <ELELUECK@de.ibm.com>
Date: Tue, 10 May 2011 10:17:09 +0200
> Calls to the *_many functions introduced by Octavian may never interleave
> because
> the traversed lists modify each other. This was the root cause for the
> symptom that Frank discovered. Octavian is not a valid mail recipient
> anymore and did not react from any new mail address. I suggest to revert
> the commit.
I don't think a pure-revert is appropriate in this case, the regression
that will introduce is almost as serious as the OOPS here.
Someone just needs to work on a fix.
^ permalink raw reply
* Re: [PATCH net-2.6] vlan: fix GVRP at dismantle time
From: David Miller @ 2011-05-10 19:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: mirqus, alex, netdev, jesse, greearb, kaber
In-Reply-To: <1305009636.3050.60.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 10 May 2011 08:40:36 +0200
> [PATCH net-2.6] vlan: fix GVRP at dismantle time
Applied and queued up for -stable, thanks!
^ permalink raw reply
* Re: [PATCH v2] net: ipv4: add IPPROTO_ICMP socket kind
From: David Miller @ 2011-05-10 19:15 UTC (permalink / raw)
To: segoon
Cc: solar, linux-kernel, netdev, peak, kees.cook, dan.j.rosenberg,
eugene, nelhage, kuznet, pekkas, jmorris, yoshfuji, kaber
In-Reply-To: <20110510180957.GA3262@albatros>
From: Vasiliy Kulikov <segoon@openwall.com>
Date: Tue, 10 May 2011 22:09:59 +0400
In net-next-2.6 we're trying to get rid of uses of route identity
information, and also the types used for flow lookup keys are
completely different. This code won't compile as-is.
> + {
> + struct flowi fl = { .oif = ipc.oif,
This should be "struct flowi4 fl4", declare it at the top
level of the function so you can get at the fully resolved
key values later in this function.
Then use "flowi4_init_output(...) to initialize the flow instead of
this explicit assignment.
> + if (!ipc.addr)
> + ipc.addr = rt->rt_dst;
Replase rt->rt_dst with fl4.daddr
> + err = ip_append_data(sk, ping_getfrag, &pfh, len,
> + 0, &ipc, &rt,
> + msg->msg_flags);
ip_append_data() now takes a flowi4 key pointer as an argument, so
you'll need to pass "&fl4" in.
A lot has changed in this area, your code won't even compile, so
please adjust your patch to fit net-next-2.6 as needed, perhaps
using net/ipv4/raw.c and net/ipv4/udp.c as a guide.
Thanks.
^ permalink raw reply
* RE: Kernel 2.6.38.6 page allocation failure (ixgbe)
From: Brandeburg, Jesse @ 2011-05-10 19:06 UTC (permalink / raw)
To: Stefan Majer; +Cc: e1000-devel@lists.sourceforge.net, netdev@vger.kernel.org
In-Reply-To: <BANLkTik=FM5LJs8JUKHR2S+r41vi94Z7pw@mail.gmail.com>
Adding e1000-devel, our list for the out-of-tree ixgbe driver (the issue is reported below to be in both upstream and out-of-tree)
do you have jumbo frames enabled?
-----Original Message-----
From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On Behalf Of Stefan Majer
Sent: Tuesday, May 10, 2011 9:03 AM
To: netdev@vger.kernel.org
Subject: Kernel 2.6.38.6 page allocation failure (ixgbe)
Hi,
im running 4 nodes with ceph on top of btrfs with a dualport Intel
X520 10Gb Ethernet Card with the latest 3.3.9 ixgbe driver.
during benchmarks i get the following stack.
I can easily reproduce this by simply running rados bench from a fast
machine using this 4 nodes as ceph cluster.
We saw this with stock ixgbe driver from 2.6.38.6 and with the latest
3.3.9 ixgbe.
This kernel is tainted because we use fusion-io iodrives as journal
devices for btrfs.
Any hints to nail this down are welcome.
Greetings Stefan Majer
May 10 15:26:40 os02 kernel: [ 3652.485219] cosd: page allocation
failure. order:2, mode:0x4020
May 10 15:26:40 os02 kernel: [ 3652.485223] kswapd0: page allocation
failure. order:2, mode:0x4020
May 10 15:26:40 os02 kernel: [ 3652.485228] Pid: 57, comm: kswapd0
Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
May 10 15:26:40 os02 kernel: [ 3652.485230] Call Trace:
May 10 15:26:40 os02 kernel: [ 3652.485232] <IRQ>
[<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
May 10 15:26:40 os02 kernel: [ 3652.485247] [<ffffffff814b0ad0>] ?
ip_local_deliver+0x80/0x90
May 10 15:26:40 os02 kernel: [ 3652.485250] cosd: page allocation
failure. order:2, mode:0x4020
May 10 15:26:40 os02 kernel: [ 3652.485256] [<ffffffff81146cd2>] ?
kmalloc_large_node+0x62/0xb0
May 10 15:26:40 os02 kernel: [ 3652.485259] Pid: 1849, comm: cosd
Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
May 10 15:26:40 os02 kernel: [ 3652.485261] Call Trace:
May 10 15:26:40 os02 kernel: [ 3652.485264] [<ffffffff8114becb>] ?
__kmalloc_node_track_caller+0x15b/0x1d0
May 10 15:26:40 os02 kernel: [ 3652.485266] <IRQ>
[<ffffffff81466f74>] ? __netdev_alloc_skb+0x24/0x50
May 10 15:26:40 os02 kernel: [ 3652.485274] [<ffffffff81108ce7>] ?
__alloc_pages_nodemask+0x6f7/0x8a0
May 10 15:26:40 os02 kernel: [ 3652.485277] [<ffffffff81466713>] ?
__alloc_skb+0x83/0x170
May 10 15:26:40 os02 kernel: [ 3652.485281] [<ffffffff814b0ad0>] ?
ip_local_deliver+0x80/0x90
May 10 15:26:40 os02 kernel: [ 3652.485283] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 10 15:26:40 os02 kernel: [ 3652.485287] [<ffffffff81146cd2>] ?
kmalloc_large_node+0x62/0xb0
May 10 15:26:40 os02 kernel: [ 3652.485297] [<ffffffffa005d9aa>] ?
ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
May 10 15:26:40 os02 kernel: [ 3652.485300] [<ffffffff8114becb>] ?
__kmalloc_node_track_caller+0x15b/0x1d0
May 10 15:26:40 os02 kernel: [ 3652.485305] [<ffffffff812b79e0>] ?
swiotlb_map_page+0x0/0x110
May 10 15:26:40 os02 kernel: [ 3652.485308] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 10 15:26:40 os02 kernel: [ 3652.485315] [<ffffffffa0060930>] ?
ixgbe_poll+0x1140/0x1670 [ixgbe]
May 10 15:26:40 os02 kernel: [ 3652.485318] [<ffffffff81466713>] ?
__alloc_skb+0x83/0x170
May 10 15:26:40 os02 kernel: [ 3652.485323] [<ffffffff810f33eb>] ?
perf_pmu_enable+0x2b/0x40
May 10 15:26:40 os02 kernel: [ 3652.485326] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 10 15:26:40 os02 kernel: [ 3652.485330] [<ffffffff81474eb2>] ?
net_rx_action+0x102/0x2a0
May 10 15:26:40 os02 kernel: [ 3652.485336] [<ffffffffa005d9aa>] ?
ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
May 10 15:26:40 os02 kernel: [ 3652.485341] [<ffffffff8106b745>] ?
__do_softirq+0xb5/0x210
May 10 15:26:40 os02 kernel: [ 3652.485344] [<ffffffff81474840>] ?
napi_skb_finish+0x50/0x70
May 10 15:26:40 os02 kernel: [ 3652.485348] [<ffffffff810c7ca4>] ?
handle_IRQ_event+0x54/0x180
May 10 15:26:40 os02 kernel: [ 3652.485354] [<ffffffffa0060930>] ?
ixgbe_poll+0x1140/0x1670 [ixgbe]
May 10 15:26:40 os02 kernel: [ 3652.485357] [<ffffffff8106b7bd>] ?
__do_softirq+0x12d/0x210
May 10 15:26:40 os02 kernel: [ 3652.485360] [<ffffffff810f33eb>] ?
perf_pmu_enable+0x2b/0x40
May 10 15:26:40 os02 kernel: [ 3652.485364] [<ffffffff8100cf3c>] ?
call_softirq+0x1c/0x30
May 10 15:26:40 os02 kernel: [ 3652.485367] [<ffffffff81474eb2>] ?
net_rx_action+0x102/0x2a0
May 10 15:26:40 os02 kernel: [ 3652.485369] [<ffffffff8100e975>] ?
do_softirq+0x65/0xa0
May 10 15:26:40 os02 kernel: [ 3652.485372] [<ffffffff8106b745>] ?
__do_softirq+0xb5/0x210
May 10 15:26:40 os02 kernel: [ 3652.485375] [<ffffffff8106b605>] ?
irq_exit+0x95/0xa0
May 10 15:26:40 os02 kernel: [ 3652.485379] [<ffffffff810c7ca4>] ?
handle_IRQ_event+0x54/0x180
May 10 15:26:40 os02 kernel: [ 3652.485383] [<ffffffff8154a276>] ?
do_IRQ+0x66/0xe0
May 10 15:26:40 os02 kernel: [ 3652.485386] [<ffffffff8106b7bd>] ?
__do_softirq+0x12d/0x210
May 10 15:26:40 os02 kernel: [ 3652.485389] [<ffffffff81542a53>] ?
ret_from_intr+0x0/0x15
May 10 15:26:40 os02 kernel: [ 3652.485391] <EOI>
[<ffffffff8100cf3c>] ? call_softirq+0x1c/0x30
May 10 15:26:40 os02 kernel: [ 3652.485397] [<ffffffff81110a54>] ?
shrink_inactive_list+0x164/0x460
May 10 15:26:40 os02 kernel: [ 3652.485400] [<ffffffff8100e975>] ?
do_softirq+0x65/0xa0
May 10 15:26:40 os02 kernel: [ 3652.485404] [<ffffffff8153facc>] ?
schedule+0x44c/0xa10
May 10 15:26:40 os02 kernel: [ 3652.485407] [<ffffffff8106b605>] ?
irq_exit+0x95/0xa0
May 10 15:26:40 os02 kernel: [ 3652.485412] [<ffffffff81109b1a>] ?
determine_dirtyable_memory+0x1a/0x30
May 10 15:26:40 os02 kernel: [ 3652.485416] [<ffffffff8154a276>] ?
do_IRQ+0x66/0xe0
May 10 15:26:40 os02 kernel: [ 3652.485419] [<ffffffff81111453>] ?
shrink_zone+0x3d3/0x530
May 10 15:26:40 os02 kernel: [ 3652.485422] [<ffffffff81542a53>] ?
ret_from_intr+0x0/0x15
May 10 15:26:40 os02 kernel: [ 3652.485423] <EOI>
[<ffffffff81074a4a>] ? del_timer_sync+0x3a/0x60
May 10 15:26:40 os02 kernel: [ 3652.485430] [<ffffffff812a774d>] ?
copy_user_generic_string+0x2d/0x40
May 10 15:26:40 os02 kernel: [ 3652.485435] [<ffffffff811054a5>] ?
zone_watermark_ok_safe+0xb5/0xd0
May 10 15:26:40 os02 kernel: [ 3652.485439] [<ffffffff810ff351>] ?
iov_iter_copy_from_user_atomic+0x101/0x170
May 10 15:26:40 os02 kernel: [ 3652.485442] [<ffffffff81112a69>] ?
kswapd+0x889/0xb20
May 10 15:26:40 os02 kernel: [ 3652.485457] [<ffffffffa026c91d>] ?
btrfs_copy_from_user+0xcd/0x130 [btrfs]
May 10 15:26:40 os02 kernel: [ 3652.485460] [<ffffffff811121e0>] ?
kswapd+0x0/0xb20
May 10 15:26:40 os02 kernel: [ 3652.485472] [<ffffffffa026d844>] ?
__btrfs_buffered_write+0x1a4/0x330 [btrfs]
May 10 15:26:40 os02 kernel: [ 3652.485476] [<ffffffff810862b6>] ?
kthread+0x96/0xa0
May 10 15:26:40 os02 kernel: [ 3652.485479] [<ffffffff8117151f>] ?
file_update_time+0x5f/0x170
May 10 15:26:40 os02 kernel: [ 3652.485482] [<ffffffff8100ce44>] ?
kernel_thread_helper+0x4/0x10
May 10 15:26:40 os02 kernel: [ 3652.485493] [<ffffffffa026dc08>] ?
btrfs_file_aio_write+0x238/0x4e0 [btrfs]
May 10 15:26:40 os02 kernel: [ 3652.485496] [<ffffffff81086220>] ?
kthread+0x0/0xa0
May 10 15:26:40 os02 kernel: [ 3652.485507] [<ffffffffa026d9d0>] ?
btrfs_file_aio_write+0x0/0x4e0 [btrfs]
May 10 15:26:40 os02 kernel: [ 3652.485511] [<ffffffff8100ce40>] ?
kernel_thread_helper+0x0/0x10
May 10 15:26:40 os02 kernel: [ 3652.485515] [<ffffffff81158ff3>] ?
do_sync_readv_writev+0xd3/0x110
May 10 15:26:40 os02 kernel: [ 3652.485516] Mem-Info:
May 10 15:26:40 os02 kernel: [ 3652.485519] [<ffffffff81163d42>] ?
path_put+0x22/0x30
May 10 15:26:40 os02 kernel: [ 3652.485521] Node 0 DMA per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.485525] [<ffffffff812584a3>] ?
selinux_file_permission+0xf3/0x150
May 10 15:26:40 os02 kernel: [ 3652.485528] CPU 0: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485530] CPU 1: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485534] [<ffffffff81251583>] ?
security_file_permission+0x23/0x90
May 10 15:26:40 os02 kernel: [ 3652.485535] CPU 2: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485538] CPU 3: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485542] [<ffffffff81159f14>] ?
do_readv_writev+0xd4/0x1e0
May 10 15:26:40 os02 kernel: [ 3652.485544] CPU 4: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485547] CPU 5: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485550] [<ffffffff81540d91>] ?
mutex_lock+0x31/0x60
May 10 15:26:40 os02 kernel: [ 3652.485552] CPU 6: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485554] CPU 7: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485557] [<ffffffff8115a066>] ?
vfs_writev+0x46/0x60
May 10 15:26:40 os02 kernel: [ 3652.485558] Node 0 DMA32 per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.485562] [<ffffffff8115a1a1>] ?
sys_writev+0x51/0xc0
May 10 15:26:40 os02 kernel: [ 3652.485564] CPU 0: hi: 186, btch:
31 usd: 144
May 10 15:26:40 os02 kernel: [ 3652.485567] CPU 1: hi: 186, btch:
31 usd: 198
May 10 15:26:40 os02 kernel: [ 3652.485571] [<ffffffff8100c002>] ?
system_call_fastpath+0x16/0x1b
May 10 15:26:40 os02 kernel: [ 3652.485573] CPU 2: hi: 186, btch:
31 usd: 180
May 10 15:26:40 os02 kernel: [ 3652.485574] Mem-Info:
May 10 15:26:40 os02 kernel: [ 3652.485576] CPU 3: hi: 186, btch:
31 usd: 171
May 10 15:26:40 os02 kernel: [ 3652.485578] Node 0 CPU 4: hi: 186,
btch: 31 usd: 159
May 10 15:26:40 os02 kernel: [ 3652.485581] DMA per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.485582] CPU 5: hi: 186, btch:
31 usd: 69
May 10 15:26:40 os02 kernel: [ 3652.485585] CPU 0: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485587] CPU 6: hi: 186, btch:
31 usd: 180
May 10 15:26:40 os02 kernel: [ 3652.485589] CPU 1: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485591] CPU 7: hi: 186, btch:
31 usd: 184
May 10 15:26:40 os02 kernel: [ 3652.485593] CPU 2: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485594] Node 0 CPU 3: hi: 0,
btch: 1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485597] Normal per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.485598] CPU 4: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485600] CPU 0: hi: 186, btch:
31 usd: 100
May 10 15:26:40 os02 kernel: [ 3652.485602] CPU 5: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485604] CPU 1: hi: 186, btch:
31 usd: 47
May 10 15:26:40 os02 kernel: [ 3652.485606] CPU 6: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485608] CPU 2: hi: 186, btch:
31 usd: 168
May 10 15:26:40 os02 kernel: [ 3652.485610] CPU 7: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.485612] CPU 3: hi: 186, btch:
31 usd: 140
May 10 15:26:40 os02 kernel: [ 3652.485614] Node 0 CPU 4: hi: 186,
btch: 31 usd: 177
May 10 15:26:40 os02 kernel: [ 3652.485617] DMA32 per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.485618] CPU 5: hi: 186, btch:
31 usd: 77
May 10 15:26:40 os02 kernel: [ 3652.485621] CPU 0: hi: 186, btch:
31 usd: 144
May 10 15:26:40 os02 kernel: [ 3652.485623] CPU 6: hi: 186, btch:
31 usd: 168
May 10 15:26:40 os02 kernel: [ 3652.485625] CPU 1: hi: 186, btch:
31 usd: 198
May 10 15:26:40 os02 kernel: [ 3652.485627] CPU 7: hi: 186, btch:
31 usd: 68
May 10 15:26:40 os02 kernel: [ 3652.485629] CPU 2: hi: 186, btch:
31 usd: 180
May 10 15:26:40 os02 kernel: [ 3652.485634] active_anon:255806
inactive_anon:19454 isolated_anon:0
May 10 15:26:40 os02 kernel: [ 3652.485636] active_file:420093
inactive_file:5180559 isolated_file:0
May 10 15:26:40 os02 kernel: [ 3652.485637] unevictable:50582
dirty:314034 writeback:8484 unstable:0
May 10 15:26:40 os02 kernel: [ 3652.485639] free:30074
slab_reclaimable:35739 slab_unreclaimable:13526
May 10 15:26:40 os02 kernel: [ 3652.485641] mapped:3440 shmem:51
pagetables:1342 bounce:0
May 10 15:26:40 os02 kernel: [ 3652.485643] CPU 3: hi: 186, btch:
31 usd: 171
May 10 15:26:40 os02 kernel: [ 3652.485644] Node 0 CPU 4: hi: 186,
btch: 31 usd: 159
May 10 15:26:40 os02 kernel: [ 3652.485652] DMA free:15852kB min:12kB
low:12kB high:16kB active_anon:0kB inactive_anon:0kB active_file:0kB
inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:15660kB mlocked:0kB dirty:0kB writeback:0kB
mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
May 10 15:26:40 os02 kernel: [ 3652.485659] CPU 5: hi: 186, btch:
31 usd: 69
May 10 15:26:40 os02 kernel: [ 3652.485661] lowmem_reserve[]:CPU 6:
hi: 186, btch: 31 usd: 180
May 10 15:26:40 os02 kernel: [ 3652.485663] 0CPU 7: hi: 186,
btch: 31 usd: 184
May 10 15:26:40 os02 kernel: [ 3652.485665] 2991Node 0 24201Normal per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.485668] 24201CPU 0: hi: 186,
btch: 31 usd: 100
May 10 15:26:40 os02 kernel: [ 3652.485671]
May 10 15:26:40 os02 kernel: [ 3652.485672] CPU 1: hi: 186, btch:
31 usd: 47
May 10 15:26:40 os02 kernel: [ 3652.485674] Node 0 CPU 2: hi: 186,
btch: 31 usd: 168
May 10 15:26:40 os02 kernel: [ 3652.485682] DMA32 free:85748kB
min:2460kB low:3072kB high:3688kB active_anon:20480kB
inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
unevictable:72kB isolated(anon):0kB isolated(file):0kB
present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
mapped:648kB shmem:0kB slab_reclaimable:28400kB
slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
May 10 15:26:40 os02 kernel: [ 3652.485690] CPU 3: hi: 186, btch:
31 usd: 140
May 10 15:26:40 os02 kernel: [ 3652.485691] lowmem_reserve[]:CPU 4:
hi: 186, btch: 31 usd: 177
May 10 15:26:40 os02 kernel: [ 3652.485693] 0CPU 5: hi: 186,
btch: 31 usd: 77
May 10 15:26:40 os02 kernel: [ 3652.485696] 0CPU 6: hi: 186,
btch: 31 usd: 168
May 10 15:26:40 os02 kernel: [ 3652.485698] 21210CPU 7: hi: 186,
btch: 31 usd: 68
May 10 15:26:40 os02 kernel: [ 3652.485701] 21210active_anon:255806
inactive_anon:19454 isolated_anon:0
May 10 15:26:40 os02 kernel: [ 3652.485705] active_file:420093
inactive_file:5180559 isolated_file:0
May 10 15:26:40 os02 kernel: [ 3652.485706] unevictable:50582
dirty:314034 writeback:8484 unstable:0
May 10 15:26:40 os02 kernel: [ 3652.485707] free:30074
slab_reclaimable:35739 slab_unreclaimable:13526
May 10 15:26:40 os02 kernel: [ 3652.485708] mapped:3440 shmem:51
pagetables:1342 bounce:0
May 10 15:26:40 os02 kernel: [ 3652.485709]
May 10 15:26:40 os02 kernel: [ 3652.485710] Node 0 Node 0 DMA
free:15852kB min:12kB low:12kB high:16kB active_anon:0kB
inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB
isolated(anon):0kB isolated(file):0kB present:15660kB mlocked:0kB
dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB
slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB
bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
May 10 15:26:40 os02 kernel: [ 3652.485724] Normal free:18696kB
min:17440kB low:21800kB high:26160kB active_anon:1002744kB
inactive_anon:72548kB active_file:1528784kB inactive_file:18077048kB
unevictable:202256kB isolated(anon):0kB isolated(file):0kB
present:21719040kB mlocked:0kB dirty:1045316kB writeback:33936kB
mapped:13112kB shmem:204kB slab_reclaimable:114556kB
slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32
all_unreclaimable? no
May 10 15:26:40 os02 kernel: [ 3652.485731]
lowmem_reserve[]:lowmem_reserve[]: 0 0 2991 0 24201 0 24201 0
May 10 15:26:40 os02 kernel: [ 3652.485737]
May 10 15:26:40 os02 kernel: [ 3652.485738] Node 0 Node 0 DMA32
free:85748kB min:2460kB low:3072kB high:3688kB active_anon:20480kB
inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
unevictable:72kB isolated(anon):0kB isolated(file):0kB
present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
mapped:648kB shmem:0kB slab_reclaimable:28400kB
slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
May 10 15:26:40 os02 kernel: [ 3652.485747] DMA:
lowmem_reserve[]:1*4kB 01*8kB 00*16kB 212101*32kB 212101*64kB
May 10 15:26:40 os02 kernel: [ 3652.485754] 1*128kB Node 0 1*256kB
Normal free:18696kB min:17440kB low:21800kB high:26160kB
active_anon:1002744kB inactive_anon:72548kB active_file:1528784kB
inactive_file:18077048kB unevictable:202256kB isolated(anon):0kB
isolated(file):0kB present:21719040kB mlocked:0kB dirty:1045316kB
writeback:33936kB mapped:13112kB shmem:204kB slab_reclaimable:114556kB
slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:32
all_unreclaimable? no
May 10 15:26:40 os02 kernel: [ 3652.485764] 0*512kB
lowmem_reserve[]:1*1024kB 01*2048kB 03*4096kB 0= 15852kB
May 10 15:26:40 os02 kernel: [ 3652.485771] 0Node 0
May 10 15:26:40 os02 kernel: [ 3652.485773] DMA32: Node 0 59*4kB DMA:
125*8kB 1*4kB 66*16kB 1*8kB 80*32kB 0*16kB 188*64kB 1*32kB 51*128kB
1*64kB 15*256kB 1*128kB 40*512kB 1*256kB 31*1024kB 0*512kB 1*2048kB
1*1024kB 1*4096kB 1*2048kB = 85620kB
May 10 15:26:40 os02 kernel: [ 3652.485789] 3*4096kB Node 0 = 15852kB
May 10 15:26:40 os02 kernel: [ 3652.485791] Normal: Node 0 3930*4kB
DMA32: 0*8kB 59*4kB 1*16kB 125*8kB 0*32kB 66*16kB 0*64kB 80*32kB
0*128kB 188*64kB 1*256kB 51*128kB 1*512kB 15*256kB 0*1024kB 40*512kB
1*2048kB 31*1024kB 0*4096kB 1*2048kB = 18552kB
May 10 15:26:40 os02 kernel: [ 3652.485807] 1*4096kB 5651289 total
pagecache pages
May 10 15:26:40 os02 kernel: [ 3652.485809] = 85620kB
May 10 15:26:40 os02 kernel: [ 3652.485810] 0 pages in swap cache
May 10 15:26:40 os02 kernel: [ 3652.485811] Node 0 Swap cache stats:
add 0, delete 0, find 0/0
May 10 15:26:40 os02 kernel: [ 3652.485814] Normal: Free swap = 1048572kB
May 10 15:26:40 os02 kernel: [ 3652.485815] 3930*4kB Total swap = 1048572kB
May 10 15:26:40 os02 kernel: [ 3652.485817] 0*8kB 1*16kB 0*32kB 0*64kB
0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 18552kB
May 10 15:26:40 os02 kernel: [ 3652.485822] 5651289 total pagecache pages
May 10 15:26:40 os02 kernel: [ 3652.485823] 0 pages in swap cache
May 10 15:26:40 os02 kernel: [ 3652.485824] Swap cache stats: add 0,
delete 0, find 0/0
May 10 15:26:40 os02 kernel: [ 3652.485825] Free swap = 1048572kB
May 10 15:26:40 os02 kernel: [ 3652.485826] Total swap = 1048572kB
May 10 15:26:40 os02 kernel: [ 3652.486439] kworker/0:1: page
allocation failure. order:2, mode:0x4020
May 10 15:26:40 os02 kernel: [ 3652.486443] Pid: 0, comm: kworker/0:1
Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
May 10 15:26:40 os02 kernel: [ 3652.486446] Call Trace:
May 10 15:26:40 os02 kernel: [ 3652.486448] <IRQ>
[<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
May 10 15:26:40 os02 kernel: [ 3652.486459] [<ffffffff814b0ad0>] ?
ip_local_deliver+0x80/0x90
May 10 15:26:40 os02 kernel: [ 3652.486464] [<ffffffff81146cd2>] ?
kmalloc_large_node+0x62/0xb0
May 10 15:26:40 os02 kernel: [ 3652.486468] [<ffffffff8114becb>] ?
__kmalloc_node_track_caller+0x15b/0x1d0
May 10 15:26:40 os02 kernel: [ 3652.486473] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 10 15:26:40 os02 kernel: [ 3652.486476] [<ffffffff81466713>] ?
__alloc_skb+0x83/0x170
May 10 15:26:40 os02 kernel: [ 3652.486479] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 10 15:26:40 os02 kernel: [ 3652.486489] [<ffffffffa005d9aa>] ?
ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
May 10 15:26:40 os02 kernel: [ 3652.486494] [<ffffffff81474840>] ?
napi_skb_finish+0x50/0x70
May 10 15:26:40 os02 kernel: [ 3652.486501] [<ffffffffa0060930>] ?
ixgbe_poll+0x1140/0x1670 [ixgbe]
May 10 15:26:40 os02 kernel: [ 3652.486506] [<ffffffff81013379>] ?
sched_clock+0x9/0x10
May 10 15:26:40 os02 kernel: [ 3652.486510] [<ffffffff81474eb2>] ?
net_rx_action+0x102/0x2a0
May 10 15:26:40 os02 kernel: [ 3652.486514] [<ffffffff8106b745>] ?
__do_softirq+0xb5/0x210
May 10 15:26:40 os02 kernel: [ 3652.486520] [<ffffffff8108aec4>] ?
hrtimer_interrupt+0x134/0x240
May 10 15:26:40 os02 kernel: [ 3652.486523] [<ffffffff8100cf3c>] ?
call_softirq+0x1c/0x30
May 10 15:26:40 os02 kernel: [ 3652.486526] [<ffffffff8100e975>] ?
do_softirq+0x65/0xa0
May 10 15:26:40 os02 kernel: [ 3652.486529] [<ffffffff8106b605>] ?
irq_exit+0x95/0xa0
May 10 15:26:40 os02 kernel: [ 3652.486533] [<ffffffff8154a360>] ?
smp_apic_timer_interrupt+0x70/0x9b
May 10 15:26:40 os02 kernel: [ 3652.486536] [<ffffffff8100c9f3>] ?
apic_timer_interrupt+0x13/0x20
May 10 15:26:40 os02 kernel: [ 3652.486538] <EOI>
[<ffffffff812db311>] ? intel_idle+0xc1/0x120
May 10 15:26:40 os02 kernel: [ 3652.486544] [<ffffffff812db2f4>] ?
intel_idle+0xa4/0x120
May 10 15:26:40 os02 kernel: [ 3652.486549] [<ffffffff8143bca5>] ?
cpuidle_idle_call+0xb5/0x240
May 10 15:26:40 os02 kernel: [ 3652.486554] [<ffffffff8100aa87>] ?
cpu_idle+0xb7/0x110
May 10 15:26:40 os02 kernel: [ 3652.486558] [<ffffffff81538ffe>] ?
start_secondary+0x21f/0x221
May 10 15:26:40 os02 kernel: [ 3652.486561] Mem-Info:
May 10 15:26:40 os02 kernel: [ 3652.486562] Node 0 DMA per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.486564] CPU 0: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.486567] CPU 1: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.486569] CPU 2: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.486571] CPU 3: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.486573] CPU 4: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.486575] CPU 5: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.486578] CPU 6: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.486580] CPU 7: hi: 0, btch:
1 usd: 0
May 10 15:26:40 os02 kernel: [ 3652.486581] Node 0 DMA32 per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.486584] CPU 0: hi: 186, btch:
31 usd: 144
May 10 15:26:40 os02 kernel: [ 3652.486586] CPU 1: hi: 186, btch:
31 usd: 198
May 10 15:26:40 os02 kernel: [ 3652.486588] CPU 2: hi: 186, btch:
31 usd: 180
May 10 15:26:40 os02 kernel: [ 3652.486590] CPU 3: hi: 186, btch:
31 usd: 172
May 10 15:26:40 os02 kernel: [ 3652.486593] CPU 4: hi: 186, btch:
31 usd: 159
May 10 15:26:40 os02 kernel: [ 3652.486595] CPU 5: hi: 186, btch:
31 usd: 69
May 10 15:26:40 os02 kernel: [ 3652.486597] CPU 6: hi: 186, btch:
31 usd: 180
May 10 15:26:40 os02 kernel: [ 3652.486599] CPU 7: hi: 186, btch:
31 usd: 184
May 10 15:26:40 os02 kernel: [ 3652.486601] Node 0 Normal per-cpu:
May 10 15:26:40 os02 kernel: [ 3652.486603] CPU 0: hi: 186, btch:
31 usd: 162
May 10 15:26:40 os02 kernel: [ 3652.486605] CPU 1: hi: 186, btch:
31 usd: 47
May 10 15:26:40 os02 kernel: [ 3652.486608] CPU 2: hi: 186, btch:
31 usd: 168
May 10 15:26:40 os02 kernel: [ 3652.486610] CPU 3: hi: 186, btch:
31 usd: 141
May 10 15:26:40 os02 kernel: [ 3652.486612] CPU 4: hi: 186, btch:
31 usd: 177
May 10 15:26:40 os02 kernel: [ 3652.486614] CPU 5: hi: 186, btch:
31 usd: 77
May 10 15:26:40 os02 kernel: [ 3652.486616] CPU 6: hi: 186, btch:
31 usd: 168
May 10 15:26:40 os02 kernel: [ 3652.486618] CPU 7: hi: 186, btch:
31 usd: 174
May 10 15:26:40 os02 kernel: [ 3652.486624] active_anon:255806
inactive_anon:19454 isolated_anon:0
May 10 15:26:40 os02 kernel: [ 3652.486625] active_file:420093
inactive_file:5180745 isolated_file:0
May 10 15:26:40 os02 kernel: [ 3652.486627] unevictable:50582
dirty:314470 writeback:8484 unstable:0
May 10 15:26:40 os02 kernel: [ 3652.486628] free:29795
slab_reclaimable:35739 slab_unreclaimable:13526
May 10 15:26:40 os02 kernel: [ 3652.486629] mapped:3440 shmem:51
pagetables:1342 bounce:0
May 10 15:26:40 os02 kernel: [ 3652.486631] Node 0 DMA free:15852kB
min:12kB low:12kB high:16kB active_anon:0kB inactive_anon:0kB
active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB
isolated(file):0kB present:15660kB mlocked:0kB dirty:0kB writeback:0kB
mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB
kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB
writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
May 10 15:26:40 os02 kernel: [ 3652.486642] lowmem_reserve[]: 0 2991 24201 24201
May 10 15:26:40 os02 kernel: [ 3652.486645] Node 0 DMA32 free:85748kB
min:2460kB low:3072kB high:3688kB active_anon:20480kB
inactive_anon:5268kB active_file:151588kB inactive_file:2645188kB
unevictable:72kB isolated(anon):0kB isolated(file):0kB
present:3063392kB mlocked:0kB dirty:210820kB writeback:0kB
mapped:648kB shmem:0kB slab_reclaimable:28400kB
slab_unreclaimable:2152kB kernel_stack:520kB pagetables:100kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0
all_unreclaimable? no
May 10 15:26:40 os02 kernel: [ 3652.486657] lowmem_reserve[]: 0 0 21210 21210
May 10 15:26:40 os02 kernel: [ 3652.486660] Node 0 Normal free:17580kB
min:17440kB low:21800kB high:26160kB active_anon:1002744kB
inactive_anon:72548kB active_file:1528784kB inactive_file:18077792kB
unevictable:202256kB isolated(anon):0kB isolated(file):0kB
present:21719040kB mlocked:0kB dirty:1047060kB writeback:33936kB
mapped:13112kB shmem:204kB slab_reclaimable:114556kB
slab_unreclaimable:51952kB kernel_stack:3768kB pagetables:5268kB
unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:64
all_unreclaimable? no
May 10 15:26:40 os02 kernel: [ 3652.486673] lowmem_reserve[]: 0 0 0 0
May 10 15:26:40 os02 kernel: [ 3652.486675] Node 0 DMA: 1*4kB 1*8kB
0*16kB 1*32kB 1*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 1*2048kB
3*4096kB = 15852kB
May 10 15:26:40 os02 kernel: [ 3652.486684] Node 0 DMA32: 59*4kB
125*8kB 66*16kB 80*32kB 188*64kB 51*128kB 15*256kB 40*512kB 31*1024kB
1*2048kB 1*4096kB = 85620kB
May 10 15:26:40 os02 kernel: [ 3652.486692] Node 0 Normal: 3705*4kB
12*8kB 16*16kB 4*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB
0*4096kB = 18180kB
May 10 15:26:40 os02 kernel: [ 3652.486700] 5651289 total pagecache pages
May 10 15:26:40 os02 kernel: [ 3652.486702] 0 pages in swap cache
May 10 15:26:40 os02 kernel: [ 3652.486704] Swap cache stats: add 0,
delete 0, find 0/0
May 10 15:26:40 os02 kernel: [ 3652.486705] Free swap = 1048572kB
May 10 15:26:40 os02 kernel: [ 3652.486707] Total swap = 1048572kB
May 10 15:26:40 os02 kernel: [ 3652.562795] 6291440 pages RAM
May 10 15:26:40 os02 kernel: [ 3652.562798] 108688 pages reserved
May 10 15:26:40 os02 kernel: [ 3652.562799] 5429575 pages shared
May 10 15:26:40 os02 kernel: [ 3652.562801] 783596 pages non-shared
May 10 15:26:40 os02 kernel: [ 3652.651570] 6291440 pages RAM
May 10 15:26:40 os02 kernel: [ 3652.651572] 108688 pages reserved
May 10 15:26:40 os02 kernel: [ 3652.651573] 5430055 pages shared
May 10 15:26:40 os02 kernel: [ 3652.651575] 782974 pages non-shared
May 10 15:26:40 os02 kernel: [ 3652.721553] 6291440 pages RAM
May 10 15:26:40 os02 kernel: [ 3652.721555] 108688 pages reserved
May 10 15:26:40 os02 kernel: [ 3652.721556] 5430961 pages shared
May 10 15:26:40 os02 kernel: [ 3652.721557] 781496 pages non-shared
May 10 15:26:40 os02 kernel: [ 3654.349865] Pid: 1846, comm: cosd
Tainted: P W 2.6.38.6-1.fits.1.el6.x86_64 #1
May 10 15:26:40 os02 kernel: [ 3654.358792] Call Trace:
May 10 15:26:40 os02 kernel: [ 3654.361519] <IRQ>
[<ffffffff81108ce7>] ? __alloc_pages_nodemask+0x6f7/0x8a0
May 10 15:26:40 os02 kernel: [ 3654.369495] [<ffffffff814b0ad0>] ?
ip_local_deliver+0x80/0x90
May 10 15:26:40 os02 kernel: [ 3654.376005] [<ffffffff81146cd2>] ?
kmalloc_large_node+0x62/0xb0
May 10 15:26:40 os02 kernel: [ 3654.382703] [<ffffffff8114becb>] ?
__kmalloc_node_track_caller+0x15b/0x1d0
May 10 15:26:40 os02 kernel: [ 3654.390464] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 10 15:26:40 os02 kernel: [ 3654.397163] [<ffffffff81466713>] ?
__alloc_skb+0x83/0x170
May 10 15:26:40 os02 kernel: [ 3654.403277] [<ffffffff81466f74>] ?
__netdev_alloc_skb+0x24/0x50
May 10 15:26:40 os02 kernel: [ 3654.409970] [<ffffffffa005d9aa>] ?
ixgbe_alloc_rx_buffers+0x9a/0x450 [ixgbe]
May 10 15:26:40 os02 kernel: [ 3654.417926] [<ffffffff812b79e0>] ?
swiotlb_map_page+0x0/0x110
May 10 15:26:40 os02 kernel: [ 3654.424432] [<ffffffffa0060930>] ?
ixgbe_poll+0x1140/0x1670 [ixgbe]
May 10 15:26:40 os02 kernel: [ 3654.431518] [<ffffffff810f33eb>] ?
perf_pmu_enable+0x2b/0x40
May 10 15:26:40 os02 kernel: [ 3654.437924] [<ffffffff81474eb2>] ?
net_rx_action+0x102/0x2a0
May 10 15:26:40 os02 kernel: [ 3654.444329] [<ffffffff8106b745>] ?
__do_softirq+0xb5/0x210
May 10 15:26:40 os02 kernel: [ 3654.450541] [<ffffffff810c7ca4>] ?
handle_IRQ_event+0x54/0x180
May 10 15:26:40 os02 kernel: [ 3654.457138] [<ffffffff8106b7bd>] ?
__do_softirq+0x12d/0x210
May 10 15:26:40 os02 kernel: [ 3654.463446] [<ffffffff8100cf3c>] ?
call_softirq+0x1c/0x30
May 10 15:26:40 os02 kernel: [ 3654.469562] [<ffffffff8100e975>] ?
do_softirq+0x65/0xa0
May 10 15:26:40 os02 kernel: [ 3654.475484] [<ffffffff8106b605>] ?
irq_exit+0x95/0xa0
May 10 15:26:40 os02 kernel: [ 3654.481218] [<ffffffff8154a276>] ?
do_IRQ+0x66/0xe0
May 10 15:26:40 os02 kernel: [ 3654.486754] [<ffffffff81542a53>] ?
ret_from_intr+0x0/0x15
May 10 15:26:40 os02 kernel: [ 3654.492867] <EOI>
[<ffffffff81286919>] ? __make_request+0x149/0x4c0
May 10 15:26:40 os02 kernel: [ 3654.500061] [<ffffffff812868e4>] ?
__make_request+0x114/0x4c0
May 10 15:26:41 os02 kernel: [ 3654.506565] [<ffffffff812841bd>] ?
generic_make_request+0x2fd/0x5e0
May 10 15:26:41 os02 kernel: [ 3654.513649] [<ffffffff8142742b>] ?
dm_get_live_table+0x4b/0x60
May 10 15:26:41 os02 kernel: [ 3654.520248] [<ffffffff81427bc1>] ?
dm_merge_bvec+0xc1/0x140
May 10 15:26:41 os02 kernel: [ 3654.526555] [<ffffffff81284526>] ?
submit_bio+0x86/0x110
May 10 15:26:41 os02 kernel: [ 3654.532574] [<ffffffff8118deac>] ?
dio_bio_submit+0xbc/0xc0
May 10 15:26:41 os02 kernel: [ 3654.538881] [<ffffffff8118df40>] ?
dio_send_cur_page+0x90/0xc0
May 10 15:26:41 os02 kernel: [ 3654.545478] [<ffffffff8118dfd5>] ?
submit_page_section+0x65/0x180
May 10 15:26:41 os02 kernel: [ 3654.552370] [<ffffffff8118e918>] ?
__blockdev_direct_IO+0x678/0xb30
May 10 15:26:41 os02 kernel: [ 3654.559454] [<ffffffff81250eaf>] ?
security_inode_getsecurity+0x1f/0x30
May 10 15:26:41 os02 kernel: [ 3654.566924] [<ffffffff8118c627>] ?
blkdev_direct_IO+0x57/0x60
May 10 15:26:41 os02 kernel: [ 3654.573414] [<ffffffff8118b760>] ?
blkdev_get_blocks+0x0/0xc0
May 10 15:26:41 os02 kernel: [ 3654.579954] [<ffffffff811008f2>] ?
generic_file_direct_write+0xc2/0x190
May 10 15:26:41 os02 kernel: [ 3654.587424] [<ffffffff811715b6>] ?
file_update_time+0xf6/0x170
May 10 15:26:41 os02 kernel: [ 3654.594025] [<ffffffff811023eb>] ?
__generic_file_aio_write+0x32b/0x460
May 10 15:26:41 os02 kernel: [ 3654.601494] [<ffffffff8105c9e0>] ?
wake_up_state+0x10/0x20
and so on.
--
Stefan Majer
--
Stefan Majer
--
To unsubscribe from this list: send the line "unsubscribe netdev" 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: [Bugme-new] [Bug 33502] New: Caught 64-bit read from uninitialized memory in __alloc_skb
From: Christoph Lameter @ 2011-05-10 19:05 UTC (permalink / raw)
To: Eric Dumazet
Cc: Vegard Nossum, Pekka Enberg, casteyde.christian, Andrew Morton,
netdev, bugzilla-daemon, bugme-daemon
In-Reply-To: <alpine.DEB.2.00.1105101323290.4023@router.home>
On Tue, 10 May 2011, Christoph Lameter wrote:
> > This other cpu can free the object and unmap page right after you did
> > the probe_kernel_address(object) (successfully), and before your cpu :
> >
> > p = get_freepointer(s, object); << BUG >>
>
> If the other cpu frees the object and unmaps the page then
> get_freepointer_safe() can obtain an arbitrary value since the TID was
> incremented. We will restart the loop and discard the value retrieved.
Ok. Forgot the element there of a different cpu. A different cpu cannot
unmap the page or free the page since the page is in a frozen state while
we allocate from it.
The page is only handled by the cpu it was assigned to until the cpu which
froze it releases it.
The only case that we need to protect against here is the case when an
interrupt or reschedule causes the *same* cpu to release the page. In that
case the TID must have been incremented.
^ permalink raw reply
* Re: [PATCH 2/2] net/dl2k: Don't reconfigure link @100Mbps when disabling autoneg @1Gbps
From: Ben Hutchings @ 2011-05-10 18:55 UTC (permalink / raw)
To: David Decotigny
Cc: Giuseppe Cavallaro, David S. Miller, Joe Perches,
Stanislaw Gruszka, netdev, linux-kernel
In-Reply-To: <1304986748-15809-3-git-send-email-decot@google.com>
On Mon, 2011-05-09 at 17:19 -0700, David Decotigny wrote:
> The initial version of the driver used to force the link to 100Mbps
> when auto-negociation was disabled on a 1Gbps link, ignoring the
> requested link speed. Instead, this change refuses to change anything
> when it is asked to configure the link speed at 1Gbps without
> auto-negociation, but acts as requested in all the other cases.
>
> IMPORTANT: Previously, the return value from mii_set_media() was
> ignored. This patch uses it for its own return value.
>
> Tested: module compiling, NOT tested on real hardware.
> Signed-off-by: David Decotigny <decot@google.com>
[...]
The changes to validation look fine. However, I noticed that there's a
call to netif_carrier_off() at the top of this function. This means
that in the error and shortcut cases, the interface will be left
disabled! It's an existing bug but might be made slightly worse by this
change.
Please also move the call to netif_carrier_off() down to the end, just
before the call to mii_set_media() which actually alters the link.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ 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