Re: [PATCHv2 2.6.24] fib: fix route replacement, fib_info is shared
On 28-01-2008 00:20, Jarek Poplawski wrote:
Hi, I have a few questions below:
Julian Anastasov wrote, On 01/26/2008 01:41 PM:
...
--- linux-2.6.24/net/ipv4/fib_hash.c_orig2008-01-25 10:45:06.0
+0200
+++ linux-2.6.24/net/ipv4/fib_hash.c 2008-01-26 14:11:34.0 +0200
@@ -434,19 +434,43 @@ static int fn_hash_insert(struct fib_tab
if (fa fa-fa_tos == tos
fa-fa_info-fib_priority == fi-fib_priority) {
...One more doubt here. Your FIB description doesn't say about this,
and a code at the end of this function, where a new alias is inserted,
doesn't seem to show this too. Are these aliases in the node sorted by
fib_priority too? I mean, isn't it possible here, that we got fa
from fib_node_alias() with right tos but greater fib_priority, but
there is a better match (with right priority) later on the list yet?
(The comment above this reads something else, but I'd be glad if you
could confirm this.)
Regards,
Jarek P.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2.6.24] fib: fix route replacement, fib_info is shared
On Mon, Jan 28, 2008 at 09:33:02AM +0100, Jarek Poplawski wrote: ... from fib_node_alias() with right tos but greater fib_priority, but from fib_find_alias() of course... arek P. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24 regression: Wake On Lan in sky2 broken on Mac mini
On Mon, Jan 28, 2008 at 09:21:30 +0100, Mikael Pettersson wrote: Tino Keitel writes: Hi folks, with 2.6.24-rc8, Wake On LAN doesn't work anymore as it used to with 2.6.23 on my Mac mini Core Duo. I saw that this was reported in http://bugzilla.kernel.org/show_bug.cgi?id=9721 and on netdev a patch for the sky2 driver was sent by Stephen Hemminger. This patch fixed WOL for me after applying it to 2.6.24-rc8. However, it seems as the patch never made it into the kernel. Instead, the commit that was suspected to break WOL (84cd2dfb04d23a961c5f537baa243fa54d0987ac) was reverted (be63a21c9573fbf88106ff0f030da5974551257b). Now I tried the 2.6.24 release and noticed that WOL is still broken. I'll be happy to test any patches that can make it into 2.6.24.1. 1. Wrong mailing list; use netdev (@vger) instead. Done. 2. The reverted commit had much much more serious consequences than wol doesn't work, it actually caused BIOS hangs and failed reboots. Yes, but even with the reverted commit, WOL still doesn't work. I just tried the patch from the netdev mailing list with the 2.6.24 release version and now WOL works for me. Regards, Tino -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2.6.24] fib: fix route replacement, fib_info is shared
On Mon, Jan 28, 2008 at 09:33:02AM +0100, Jarek Poplawski wrote: ... [...] Are these aliases in the node sorted by fib_priority too? [...] OK, I see they are! Sorry for bothering, Jarek P. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
2.6.24 regression: Wake On Lan in sky2 broken on Mac mini
Hi folks, with 2.6.24-rc8, Wake On LAN doesn't work anymore as it used to with 2.6.23 on my Mac mini Core Duo. I saw that this was reported in http://bugzilla.kernel.org/show_bug.cgi?id=9721 and on netdev a patch for the sky2 driver was sent by Stephen Hemminger. This patch fixed WOL for me after applying it to 2.6.24-rc8. However, it seems as the patch never made it into the kernel. Instead, the commit that was suspected to break WOL (84cd2dfb04d23a961c5f537baa243fa54d0987ac) was reverted (be63a21c9573fbf88106ff0f030da5974551257b). Now I tried the 2.6.24 release and noticed that WOL is still broken. I'll be happy to test any patches that can make it into 2.6.24.1. Regards, Tino -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6] [DCCP]: Fix the adjustments to AWL and SWL
This fixes a problem and a potential loophole with regard to seqno/ackno
validity: the problem is that the initial adjustments to AWL/SWL were
only performed at the begin of the connection, during the handshake.
Since the Sequence Window feature is always greater than Wmin=32 (7.5.2),
it is however necessary to perform these adjustments at least for the first
W/W' (variables as per 7.5.1) packets in the lifetime of a connection.
This requirement is complicated by the fact that W/W' can change at any time
during the lifetime of a connection.
Therefore the consequence is to perform this safety check each time SWL/AWL
are updated.
A second problem solved by this patch is that the remote/local Sequence Window
feature values (which set the bounds for AWL/SWL/SWH) are undefined until the
feature negotiation has completed.
During the initial handshake we have more stringent sequence number protection,
the changes added by this patch effect that {A,S}W{L,H} are within the correct
bounds at the instant that feature negotiation completes (since the SeqWin
feature activation handlers call dccp_update_gsr/gss()).
A detailed rationale is below -- can be removed from the commit message.
1. Server sequence number checks during initial handshake
-
The server can not use the fields of the listening socket for seqno/ackno checks
and thus needs to store all relevant information on a per-connection basis on
the dccp_request socket. This is a size-constrained structure and has currently
only ISS (dreq_iss) and ISR (dreq_isr) defined.
Adding further fields (SW{L,H}, AW{L,H}) would increase the size of the struct
and it is questionable whether this will have any practical gain. The currently
implemented solution is as follows.
* receiving first Request: dccp_v{4,6}_conn_request sets
ISR := P.seqno, ISS := dccp_v{4,6}_init_sequence()
* sending first Response: dccp_v{4,6}_send_response via dccp_make_response()
sets P.seqno := ISS, sets P.ackno := ISR
* receiving retransmitted Request: dccp_check_req() overrides ISR := P.seqno
* answering retransmitted Request: dccp_make_response() sets ISS += 1,
otherwise as per first Response
* completing the handshake: succeeds in dccp_check_req() for the first Ack
where P.ackno == ISS (P.seqno is not tested)
* creating child socket: ISS, ISR are copied from the request_sock
This solution will succeed whenever the server can receive the Request and the
subsequent Ack in succession, without retransmissions. If there is packet loss,
the client needs to retransmit until this condition succeeds; it will otherwise
eventually give up. Adding further fields to the request_sock could increase
the robustness a bit, in that it would make possible to let a reordered Ack
(from a retransmitted Response) pass. The argument against such a solution is
that if the packet loss is not persistent and an Ack gets through, why not
wait for the one answering the original response: if the loss is persistent, it
is probably better to not start the connection in the first place.
Long story short: the present design (by Arnaldo) is simple and will likely work
just as well as a more complicated solution. As a consequence, {A,S}W{L,H} are
not needed until the moment the request_sock is cloned into the accept queue.
At that stage feature negotiation has completed, so that the values for the
local
and remote Sequence Window feature (7.5.2) are known, i.e. we are now in a
better
position to compute {A,S}W{L,H}.
2. Client sequence number checks during initial handshake
-
Until entering PARTOPEN the client does not need the adjustments, since it
constrains the Ack window to the packet it sent.
* sending first Request: dccp_v{4,6}_connect() choose ISS,
dccp_connect() then sets GAR := ISS (as per 8.5),
dccp_transmit_skb() (with the previous bug fix) sets
GSS := ISS, AWL := ISS, AWH := GSS
* n-th retransmitted Request (with previous patch):
dccp_retransmit_skb() via timer calls
dccp_transmit_skb(), which sets GSS := ISS+n
and then AWL := ISS, AWH := ISS+n
* receiving any Response: dccp_rcv_request_sent_state_process()
-- accepts packet if AWL = P.ackno = AWH;
-- sets GSR = ISR = P.seqno
* sending the Ack completing the handshake: dccp_send_ack() calls
dccp_transmit_skb(), which sets GSS += 1
and AWL := ISS, AWH := GSS
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/dccp.h | 20
net/dccp/input.c | 18 ++
net/dccp/minisocks.c | 30
[PATCH 5/6] [DCCP]: Merge now-reduced connect_init() function
After moving the assignment of GAR/ISS from dccp_connect_init() to
dccp_transmit_skb(), the former function becomes very small, so that
a merger with dccp_connect() suggested itself.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/output.c | 18 +-
1 files changed, 5 insertions(+), 13 deletions(-)
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -444,8 +444,9 @@ int dccp_send_reset(struct sock *sk, enum dccp_reset_codes
code)
/*
* Do all connect socket setups that can be done AF independent.
*/
-static inline void dccp_connect_init(struct sock *sk)
+int dccp_connect(struct sock *sk)
{
+ struct sk_buff *skb;
struct dccp_sock *dp = dccp_sk(sk);
struct dst_entry *dst = __sk_dst_get(sk);
struct inet_connection_sock *icsk = inet_csk(sk);
@@ -455,22 +456,12 @@ static inline void dccp_connect_init(struct sock *sk)
dccp_sync_mss(sk, dst_mtu(dst));
- /* Initialise GAR as per 8.5; AWL/AWH are set in dccp_transmit_skb() */
- dp-dccps_gar = dp-dccps_iss;
-
- icsk-icsk_retransmits = 0;
-}
-
-int dccp_connect(struct sock *sk)
-{
- struct sk_buff *skb;
- struct inet_connection_sock *icsk = inet_csk(sk);
-
/* do not connect if feature negotiation setup fails */
if (dccp_feat_finalise_settings(dccp_sk(sk)))
return -EPROTO;
- dccp_connect_init(sk);
+ /* Initialise GAR as per 8.5; AWL/AWH are set in dccp_transmit_skb() */
+ dp-dccps_gar = dp-dccps_iss;
skb = alloc_skb(sk-sk_prot-max_header, sk-sk_allocation);
if (unlikely(skb == NULL))
@@ -486,6 +477,7 @@ int dccp_connect(struct sock *sk)
DCCP_INC_STATS(DCCP_MIB_ACTIVEOPENS);
/* Timer for repeating the REQUEST until an answer. */
+ icsk-icsk_retransmits = 0;
inet_csk_reset_xmit_timer(sk, ICSK_TIME_RETRANS,
icsk-icsk_rto, DCCP_RTO_MAX);
return 0;
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/6] [DCCP]: Bug in initial acknowledgment number assignment
Step 8.5 in RFC 4340 says for the newly cloned socket Initialize S.GAR := S.ISS, but what in fact the code (minisocks.c) does is Initialize S.GAR := S.ISR, which is wrong (typo?) -- fixed by the patch. Signed-off-by: Gerrit Renker [EMAIL PROTECTED] --- net/dccp/minisocks.c |7 +++ 1 files changed, 3 insertions(+), 4 deletions(-) --- a/net/dccp/minisocks.c +++ b/net/dccp/minisocks.c @@ -122,13 +122,12 @@ struct sock *dccp_create_openreq_child(struct sock *sk, *Initialize S.GAR := S.ISS *Set S.ISR, S.GSR, S.SWL, S.SWH from packet or Init Cookies */ + newdp-dccps_gar = newdp-dccps_iss = dreq-dreq_iss; + dccp_update_gss(newsk, dreq-dreq_iss); - newdp-dccps_gar = newdp-dccps_isr = dreq-dreq_isr; + newdp-dccps_isr = dreq-dreq_isr; dccp_update_gsr(newsk, dreq-dreq_isr); - newdp-dccps_iss = dreq-dreq_iss; - dccp_update_gss(newsk, dreq-dreq_iss); - /* * SWL and AWL are initially adjusted so that they are not less than * the initial Sequence Numbers received and sent, respectively: -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[DCCP] [Patch 0/6] [BUG-Fix]: Fixes for CCID3, seqnos, and dccp_probe
This is a set of bug fixes for CCID3 and general DCCP.
Please consider patches #1, #2, #3. The remainder are for the test tree
(but are fixes nonetheless) and may not apply directly onto mainline; with
regard to patch #6, please see note at end of message.
Patch #1: Fixes a CCID3 bug: when loss was encountered, the value returned at
minimum resolution was wrong and over 80 times too high.
Patch #2: Fixes a bug in the assignment of GAR (used ISR instead of ISS).
Patch #3: Another bug fix: AWL was only ever set after the Response.
Patch #4: Fixes adjustments to AWL and SWL. These were only updated at the
begin of the connection (where the statements reduced to much
simpler assignments), but need to be adjusted for the reception
of subsequent packets also.
(Note: This patch is best used after going through the feature
negotiation patches, since the feature handlers for Sequence
Window ensure that these values are up to date.)
Patch #5: As a consequence of the preceding patches, the dccp_connect_init
function may be merged into dccp_connect. Is a suggestion (which
would make sense), not a bug fix.
Patch #6: A fix for dccp_probe - this used to be noisy and created huge
files. By attaching the dccp_probe onto a different function, this
was fixed, the output file size shrank by a factor of over 100,
with qualitatively the same or better output.
I have put these after the feature-negotiation patches onto
git://eden-feed.erg.abdn.ac.uk/dccp_exp {dccp,ccid4}
and updated the CCID4 tree to take advantage of the dccp_probe update.
If people would like to use the dccp_probe update for a mainline kernel,
I have uploaded a similar patch to patch #6 onto
http://www.erg.abdn.ac.uk/users/gerrit/dccp/dccp_probe_for_mainline.diff
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/6] [CCID3]: Function returned wrong value
This fixes a bug in the reverse lookup of p, given a value f(p) (used in the
reverse-lookup of the first/synthetic loss interval in RFC 3448, 6.3.1):
instead of p, the function returned the smallest table value f(p).
The smallest tabulated value of
10^6 * f(p) = sqrt(2*p/3) + 12 * sqrt(3*p/8) * (32 * p^3 + p)
for p=0.0001 is 8172.
Since this value is scaled by 10^6, the impact of this bug is that a loss
of 8172/10^6 = 0.8172% was reported whenever the input was below the table
resolution of 0.01%.
This means that the value was over 80 times too high, resulting in large spikes
of the initial loss interval, and thus unnecessarily reducing the throughput.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/ccids/lib/tfrc_equation.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- a/net/dccp/ccids/lib/tfrc_equation.c
+++ b/net/dccp/ccids/lib/tfrc_equation.c
@@ -677,11 +677,11 @@ u32 tfrc_calc_x_reverse_lookup(u32 fvalue)
/* Error cases. */
if (fvalue tfrc_calc_x_lookup[0][1]) {
DCCP_WARN(fvalue %d smaller than resolution\n, fvalue);
- return tfrc_calc_x_lookup[0][1];
+ return TFRC_SMALLEST_P;
}
if (fvalue tfrc_calc_x_lookup[TFRC_CALC_X_ARRSIZE - 1][0]) {
DCCP_WARN(fvalue %d exceeds bounds!\n, fvalue);
- return 100;
+ return 100; /* The maximum: 100% scaled by 10^6 */
}
if (fvalue = tfrc_calc_x_lookup[TFRC_CALC_X_ARRSIZE - 1][1]) {
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6] [DCCP]: Bug-Fix - AWL was never updated
This patch was triggered by finding the following message in the syslog:
kernel: dccp_check_seqno: DCCP: Step 6 failed for DATAACK packet, [...]
P.ackno exists or LAWL(82947089) = P.ackno(82948208)
= S.AWH(82948728), sending SYNC...
Note the difference between AWH and AWL: it is 1639 packets (while Sequence
Window was actually at 100). A closer look at the trace showed that
LAWL = AWL = 82947089 equalled the ISS on the Response.
The cause of the bug was that AWL was only ever set on the first packet - the
DCCP-Request sent by dccp_v{4,6}_connect().
The fix is to continually update AWL/AWH with each new packet (as GSS=AWH).
In addition, AWL/AWH are now updated to enforce more stringent checks on the
initial sequence numbers when connecting:
* AWL is initialised to ISS and remains at this value;
* AWH is always set to GSS (via dccp_update_gss());
* so on the first Request: AWL = AWH = ISS,
and on the n-th Request: AWL = ISS, AWH = ISS+n.
As a consequence, only Response packets that refer to Requests sent by this
host will pass, all others are discarded. This is the intention and in effect
implements the initial adjustments for AWL as specified in RFC 4340, 7.5.1.
Note: A problem that remains is that ISS can potentially be under-run even after
the initial handshake; this is addressed a subsequent patch.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/output.c | 34 +++---
1 files changed, 15 insertions(+), 19 deletions(-)
--- a/net/dccp/output.c
+++ b/net/dccp/output.c
@@ -53,8 +53,11 @@ static int dccp_transmit_skb(struct sock *sk, struct sk_buff
*skb)
dccp_packet_hdr_len(dcb-dccpd_type);
int err, set_ack = 1;
u64 ackno = dp-dccps_gsr;
-
- dccp_inc_seqno(dp-dccps_gss);
+ /*
+* Increment GSS here already in case the option code needs it.
+* Update GSS for real only if option processing below succeeds.
+*/
+ dcb-dccpd_seq = ADD48(dp-dccps_gss, 1);
switch (dcb-dccpd_type) {
case DCCP_PKT_DATA:
@@ -66,6 +69,9 @@ static int dccp_transmit_skb(struct sock *sk, struct sk_buff
*skb)
case DCCP_PKT_REQUEST:
set_ack = 0;
+ /* Use ISS on the first (non-retransmitted) Request. */
+ if (icsk-icsk_retransmits == 0)
+ dcb-dccpd_seq = dp-dccps_iss;
/* fall through */
case DCCP_PKT_SYNC:
@@ -84,14 +90,11 @@ static int dccp_transmit_skb(struct sock *sk, struct
sk_buff *skb)
break;
}
- dcb-dccpd_seq = dp-dccps_gss;
-
if (dccp_insert_options(sk, skb)) {
kfree_skb(skb);
return -EPROTO;
}
-
/* Build DCCP header and checksum it. */
dh = dccp_zeroed_hdr(skb, dccp_header_size);
dh-dccph_type = dcb-dccpd_type;
@@ -103,7 +106,7 @@ static int dccp_transmit_skb(struct sock *sk, struct
sk_buff *skb)
/* XXX For now we're using only 48 bits sequence numbers */
dh-dccph_x = 1;
- dp-dccps_awh = dp-dccps_gss;
+ dccp_update_gss(sk, dcb-dccpd_seq);
dccp_hdr_set_seq(dh, dp-dccps_gss);
if (set_ack)
dccp_hdr_set_ack(dccp_hdr_ack_bits(skb), ackno);
@@ -112,6 +115,11 @@ static int dccp_transmit_skb(struct sock *sk, struct
sk_buff *skb)
case DCCP_PKT_REQUEST:
dccp_hdr_request(skb)-dccph_req_service =
dp-dccps_service;
+ /*
+* Limit Ack window to ISS = P.ackno = GSS, so that
+* only Responses to Requests we sent are considered.
+*/
+ dp-dccps_awl = dp-dccps_iss;
break;
case DCCP_PKT_RESET:
dccp_hdr_reset(skb)-dccph_reset_code =
@@ -447,19 +455,7 @@ static inline void dccp_connect_init(struct sock *sk)
dccp_sync_mss(sk, dst_mtu(dst));
- /*
-* SWL and AWL are initially adjusted so that they are not less than
-* the initial Sequence Numbers received and sent, respectively:
-* SWL := max(GSR + 1 - floor(W/4), ISR),
-* AWL := max(GSS - W' + 1, ISS).
-* These adjustments MUST be applied only at the beginning of the
-* connection.
-*/
- dccp_update_gss(sk, dp-dccps_iss);
- dccp_set_seqno(dp-dccps_awl, max48(dp-dccps_awl, dp-dccps_iss));
-
- /* S.GAR - greatest valid acknowledgement number received on a non-Sync;
-*
[PATCH 6/6] [DCCP-PROBE]: Reduce noise in output and convert to ktime_t
This fixes the problem that dccp_probe output can grow quite large without
apparent benefit (many identical data points), creating huge files (up to
over one Gigabyte for a few minutes' test run) which are very hard to
post-process (in one instance it got so bad that gnuplot ate up all memory
plus swap).
The cause for the problem is that the kprobe is inserted into dccp_sendmsg,
which can be called in a polling-mode (whenever the TX queue is full due to
congestion-control issues, EAGAIN is returned). This creates many very
similar data points, i.e. the increase of processing time does not increase
the quality/information of the probe output.
The fix is to attach the probe to a different function -- write_xmit was
chosen since it gets called continually (both via userspace and timer);
an input-path function would stop sampling as soon as the other end stops
sending feedback.
For comparison the output file sizes for the same 20 second test
run over a lossy link:
* before / without patch: 118 Megabytes
* after / with patch: 1.2 Megabytes
and there was much less noise in the output.
To allow backward compatibility with scripts that people use, the now-unused
`size' field in the output has been replaced with the CCID identifier. This
also serves for future compatibility - support for CCID2 is work in progress
(depends on the still unfinished SRTT/RTTVAR updates).
While at it, the update to ktime_t was also performed.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
---
net/dccp/probe.c | 68 ++---
1 files changed, 23 insertions(+), 45 deletions(-)
--- a/net/dccp/probe.c
+++ b/net/dccp/probe.c
@@ -46,77 +46,55 @@ struct {
struct kfifo *fifo;
spinlock_tlock;
wait_queue_head_t wait;
- struct timevaltstart;
+ ktime_t start;
} dccpw;
-static void printl(const char *fmt, ...)
-{
- va_list args;
- int len;
- struct timeval now;
- char tbuf[256];
-
- va_start(args, fmt);
- do_gettimeofday(now);
-
- now.tv_sec -= dccpw.tstart.tv_sec;
- now.tv_usec -= dccpw.tstart.tv_usec;
- if (now.tv_usec 0) {
- --now.tv_sec;
- now.tv_usec += 100;
- }
-
- len = sprintf(tbuf, %lu.%06lu ,
- (unsigned long) now.tv_sec,
- (unsigned long) now.tv_usec);
- len += vscnprintf(tbuf+len, sizeof(tbuf)-len, fmt, args);
- va_end(args);
-
- kfifo_put(dccpw.fifo, tbuf, len);
- wake_up(dccpw.wait);
-}
-
-static int jdccp_sendmsg(struct kiocb *iocb, struct sock *sk,
-struct msghdr *msg, size_t size)
+static void jdccp_write_xmit(struct sock *sk)
{
const struct inet_sock *inet = inet_sk(sk);
struct ccid3_hc_tx_sock *hctx = NULL;
+ struct timespec tv;
+ char tbuf[256];
+ int len, ccid = ccid_get_current_id(dccp_sk(sk), false);
- if (ccid_get_current_id(dccp_sk(sk), false) == DCCPC_CCID3)
+ if (ccid == DCCPC_CCID3)
hctx = ccid3_hc_tx_sk(sk);
- if (port == 0 || ntohs(inet-dport) == port ||
- ntohs(inet-sport) == port) {
- if (hctx)
- printl(%d.%d.%d.%d:%u %d.%d.%d.%d:%u %d %d %d %d %u
- %llu %llu %d\n,
+ if (!port || ntohs(inet-dport) == port || ntohs(inet-sport) == port) {
+
+ tv = ktime_to_timespec(ktime_sub(ktime_get(), dccpw.start));
+ len = sprintf(tbuf, %lu.%09lu %d.%d.%d.%d:%u %d.%d.%d.%d:%u
%d,
+ (unsigned long) tv.tv_sec,
+ (unsigned long) tv.tv_nsec,
NIPQUAD(inet-saddr), ntohs(inet-sport),
- NIPQUAD(inet-daddr), ntohs(inet-dport), size,
+ NIPQUAD(inet-daddr), ntohs(inet-dport), ccid);
+
+ if (hctx)
+ len += sprintf(tbuf + len, %d %d %d %u %llu %llu %d,
hctx-ccid3hctx_s, hctx-ccid3hctx_rtt,
hctx-ccid3hctx_p, hctx-ccid3hctx_x_calc,
hctx-ccid3hctx_x_recv 6,
hctx-ccid3hctx_x 6, hctx-ccid3hctx_t_ipi);
- else
- printl(%d.%d.%d.%d:%u %d.%d.%d.%d:%u %d\n,
- NIPQUAD(inet-saddr), ntohs(inet-sport),
- NIPQUAD(inet-daddr), ntohs(inet-dport), size);
+
+ len += sprintf(tbuf + len, \n);
+ kfifo_put(dccpw.fifo, tbuf, len);
+ wake_up(dccpw.wait);
}
jprobe_return();
- return 0;
}
static struct jprobe dccp_send_probe = {
.kp = {
- .symbol_name = dccp_sendmsg,
+ .symbol_name = dccp_write_xmit,
},
- .entry = jdccp_sendmsg,
+
[PATCH 1/1] replace logical- by bit-or in smctr_make_tx_status_code(), drivers/net/tokenring/smctr.c
drivers/net/tokenring/smctr.h:50:#define IBM_PASS_SOURCE_ADDR0x01 -- replace logical- by bit-or for IBM_PASS_SOURCE_ADDR Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/drivers/net/tokenring/smctr.c b/drivers/net/tokenring/smctr.c index 93da3a3..ec29766 100644 --- a/drivers/net/tokenring/smctr.c +++ b/drivers/net/tokenring/smctr.c @@ -3413,7 +3413,7 @@ static int smctr_make_tx_status_code(struct net_device *dev, tsv-svi = TRANSMIT_STATUS_CODE; tsv-svl = S_TRANSMIT_STATUS_CODE; -tsv-svv[0] = ((tx_fstatus 0x0100 6) || IBM_PASS_SOURCE_ADDR); +tsv-svv[0] = ((tx_fstatus 0x0100 6) | IBM_PASS_SOURCE_ADDR); /* Stripped frame status of Transmitted Frame */ tsv-svv[1] = tx_fstatus 0xff; -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][INET_DIAG]: Fix inet_diag_lock_handler error path
On Mon, Jan 28, 2008 at 12:20:50AM -0200, Arnaldo Carvalho de Melo wrote:
Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=9825
The inet_diag_lock_handler function uses ERR_PTR to encode errors but
its callers were testing against NULL.
Thanks for catching this Arnaldo!
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[INET]: Prevent out-of-sync truesize on ip_fragment slow path
Hi:
[INET]: Prevent out-of-sync truesize on ip_fragment slow path
When ip_fragment has to hit the slow path the value of skb-truesize
may go out of sync because we would have updated it without changing
the packet length. This violates the constraints on truesize.
This patch postpones the update of skb-truesize to prevent this.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/ipv4/ip_output.c b/net/ipv4/ip_output.c
index fd99fbd..76ec973 100644
--- a/net/ipv4/ip_output.c
+++ b/net/ipv4/ip_output.c
@@ -462,6 +462,7 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct
sk_buff*))
if (skb_shinfo(skb)-frag_list) {
struct sk_buff *frag;
int first_len = skb_pagelen(skb);
+ int truesizes = 0;
if (first_len - hlen mtu ||
((first_len - hlen) 7) ||
@@ -485,7 +486,7 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct
sk_buff*))
sock_hold(skb-sk);
frag-sk = skb-sk;
frag-destructor = sock_wfree;
- skb-truesize -= frag-truesize;
+ truesizes += frag-truesize;
}
}
@@ -496,6 +497,7 @@ int ip_fragment(struct sk_buff *skb, int (*output)(struct
sk_buff*))
frag = skb_shinfo(skb)-frag_list;
skb_shinfo(skb)-frag_list = NULL;
skb-data_len = first_len - skb_headlen(skb);
+ skb-truesize -= truesizes;
skb-len = first_len;
iph-tot_len = htons(first_len);
iph-frag_off = htons(IP_MF);
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 6338a9c..bb9b183 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -609,6 +609,7 @@ static int ip6_fragment(struct sk_buff *skb, int
(*output)(struct sk_buff *))
if (skb_shinfo(skb)-frag_list) {
int first_len = skb_pagelen(skb);
+ int truesizes = 0;
if (first_len - hlen mtu ||
((first_len - hlen) 7) ||
@@ -631,7 +632,7 @@ static int ip6_fragment(struct sk_buff *skb, int
(*output)(struct sk_buff *))
sock_hold(skb-sk);
frag-sk = skb-sk;
frag-destructor = sock_wfree;
- skb-truesize -= frag-truesize;
+ truesizes += frag-truesize;
}
}
@@ -662,6 +663,7 @@ static int ip6_fragment(struct sk_buff *skb, int
(*output)(struct sk_buff *))
first_len = skb_pagelen(skb);
skb-data_len = first_len - skb_headlen(skb);
+ skb-truesize -= truesizes;
skb-len = first_len;
ipv6_hdr(skb)-payload_len = htons(first_len -
sizeof(struct ipv6hdr));
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH net-2.6.25] [IPV6] ADDRLABEL: Fix double free on label deletion.
If an entry is being deleted because it has only one reference,
we immediately delete it and blindly register the rcu handler for it,
This results in oops by double freeing that object.
This patch fixes it by consolidating the code paths for the deletion;
let its rcu handler delete the object if it has no more reference.
Bug was found by Mitsuru Chinen [EMAIL PROTECTED]
Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED]
---
diff --git a/net/ipv6/addrlabel.c b/net/ipv6/addrlabel.c
index 6f1ca60..7a706c4 100644
--- a/net/ipv6/addrlabel.c
+++ b/net/ipv6/addrlabel.c
@@ -106,6 +106,11 @@ static inline void ip6addrlbl_free(struct ip6addrlbl_entry
*p)
kfree(p);
}
+static void ip6addrlbl_free_rcu(struct rcu_head *h)
+{
+ ip6addrlbl_free(container_of(h, struct ip6addrlbl_entry, rcu));
+}
+
static inline int ip6addrlbl_hold(struct ip6addrlbl_entry *p)
{
return atomic_inc_not_zero(p-refcnt);
@@ -114,12 +119,7 @@ static inline int ip6addrlbl_hold(struct ip6addrlbl_entry
*p)
static inline void ip6addrlbl_put(struct ip6addrlbl_entry *p)
{
if (atomic_dec_and_test(p-refcnt))
- ip6addrlbl_free(p);
-}
-
-static void ip6addrlbl_free_rcu(struct rcu_head *h)
-{
- ip6addrlbl_free(container_of(h, struct ip6addrlbl_entry, rcu));
+ call_rcu(p-rcu, ip6addrlbl_free_rcu);
}
/* Find label */
@@ -240,7 +240,6 @@ int __ip6addrlbl_add(struct ip6addrlbl_entry *newp, int
replace)
}
hlist_replace_rcu(p-list, newp-list);
ip6addrlbl_put(p);
- call_rcu(p-rcu, ip6addrlbl_free_rcu);
goto out;
} else if ((p-prefixlen == newp-prefixlen
!p-ifindex) ||
(p-prefixlen newp-prefixlen)) {
@@ -300,7 +299,6 @@ int __ip6addrlbl_del(const struct in6_addr *prefix, int
prefixlen,
ipv6_addr_equal(p-prefix, prefix)) {
hlist_del_rcu(p-list);
ip6addrlbl_put(p);
- call_rcu(p-rcu, ip6addrlbl_free_rcu);
ret = 0;
break;
}
--
YOSHIFUJI Hideaki @ USAGI Project [EMAIL PROTECTED]
GPG-FP : 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PACTH 1/1] drivers/net/usb: AX88178 100Mbps problem
Asix 88178 does not work under 100Mbps connection. This patch correct the problem. kernel version: 2.6.24 asix_driver_patch.gz Description: application/gzip
Re: [Cbe-oss-dev] [PATCH 1/5] spidernet: add missing initialization
Jeff, this series of 5 patches by Ishizaki-san runs fine on the blade, I tested it for a few days. Besides it fixes a nasty bug in spidernet RX descriptor handling. Can you please consider it for 2.6.25 ? Thanks ! Jens On Wednesday 23 January 2008, Jens Osterkamp wrote: On Friday 11 January 2008, Ishizaki Kou wrote: This patch fixes initialization of aneg_count and medium fields in spider_net_card to make spidernet driver correctly sets link status. Signed-off-by: Kou Ishizaki [EMAIL PROTECTED] Acked-by: Jens Osterkamp [EMAIL PROTECTED] --- Index: linux-powerpc-git/drivers/net/spider_net.c === --- linux-powerpc-git.orig/drivers/net/spider_net.c +++ linux-powerpc-git/drivers/net/spider_net.c @@ -1399,6 +1399,8 @@ spider_net_link_reset(struct net_device spider_net_write_reg(card, SPIDER_NET_GMACINTEN, 0); /* reset phy and setup aneg */ + card-aneg_count = 0; + card-medium = BCM54XX_COPPER; spider_net_setup_aneg(card); mod_timer(card-aneg_timer, jiffies + SPIDER_NET_ANEG_TIMER); @@ -1982,6 +1984,8 @@ spider_net_open(struct net_device *netde goto init_firmware_failed; /* start probing with copper */ + card-aneg_count = 0; + card-medium = BCM54XX_COPPER; spider_net_setup_aneg(card); if (card-phy.def-phy_id) mod_timer(card-aneg_timer, jiffies + SPIDER_NET_ANEG_TIMER); ___ cbe-oss-dev mailing list [EMAIL PROTECTED] https://ozlabs.org/mailman/listinfo/cbe-oss-dev -- Gruß, Jens IBM Deutschland Entwicklung GmbH Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Herbert Kircher Sitz der Gesellschaft: Böblingen Registergericht: Amtsgericht Stuttgart, HRB 243294 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
appearing again: kernel: eth0: too many iterations (6) in nv_nic_irq
It seems that this problem with NVidia's nic comes up more and more... From time to time we get this in the log: Jan 27 14:43:12 duvel kernel: eth0: too many iterations (6) in nv_nic_irq. We algo get Jan 27 11:32:43 duvel kernel: KERNEL: assertion ((int)tcp_packets_in_flight(tp) = 0) failed at net/ipv4/tcp_input.c (1274) But at different moments, as shown above. Are they related? What's the meaning of the assertion failed one? The messages are more likely to appear when traffic is high (500Mb/s). This is with 2.6.22.16. Any suggestions? -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: appearing again: kernel: eth0: too many iterations (6) in nv_nic_irq
On Mon, 28 Jan 2008 11:32:55 -0200 [EMAIL PROTECTED] (Carlos Carvalho) wrote: It seems that this problem with NVidia's nic comes up more and more... From time to time we get this in the log: Jan 27 14:43:12 duvel kernel: eth0: too many iterations (6) in nv_nic_irq. We algo get Jan 27 11:32:43 duvel kernel: KERNEL: assertion ((int)tcp_packets_in_flight(tp) = 0) failed at net/ipv4/tcp_input.c (1274) But at different moments, as shown above. Are they related? What's the meaning of the assertion failed one? The messages are more likely to appear when traffic is high (500Mb/s). This is with 2.6.22.16. Any suggestions? -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Use NAPI which is available as configuration option in this driver. Increase the max_interrupt_work from the ridiculously low value of 5 to something more larger like 15, with module parameter in /etc/modprobe.d/options: options forcedeth max_interrupt_work=15 Also, see if you motherboard supports MSI, if so add msi=1 module parameter -- Stephen Hemminger [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] ethtool: fix typo on setting speed 10000
Jeff Garzik wrote: Auke Kok wrote: From: Jesse Brandeburg [EMAIL PROTECTED] fix the typo in speed 1 setting. Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- ethtool.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) patches 1 and 2 failed to apply. applied #3 can you refresh the tree on http://git.kernel.org/?p=network/ethtool/ethtool.git ? I did indeed send the first two patches out earlier but they did not show up on git.kernel.org, hence I posted them again. Thanks, Auke -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
ipcomp regression in 2.6.24
Has someone an idea which patch could have damaged ipcomp? Daniel With 2.6.24 IPSEC/ESP tunnels to older kernels establish fine, data flows in both directions, but no data comes out of the tunnel. Needed to disable ipcomp. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/6] [DCCP]: Bug-Fix - AWL was never updated
On Jan 28, 2008 11:16 PM, Gerrit Renker [EMAIL PROTECTED] wrote:
This patch was triggered by finding the following message in the syslog:
kernel: dccp_check_seqno: DCCP: Step 6 failed for DATAACK packet, [...]
P.ackno exists or LAWL(82947089) = P.ackno(82948208)
= S.AWH(82948728), sending SYNC...
Note the difference between AWH and AWL: it is 1639 packets (while Sequence
Window was actually at 100). A closer look at the trace showed that
LAWL = AWL = 82947089 equalled the ISS on the Response.
The cause of the bug was that AWL was only ever set on the first packet - the
DCCP-Request sent by dccp_v{4,6}_connect().
The fix is to continually update AWL/AWH with each new packet (as GSS=AWH).
In addition, AWL/AWH are now updated to enforce more stringent checks on the
initial sequence numbers when connecting:
* AWL is initialised to ISS and remains at this value;
* AWH is always set to GSS (via dccp_update_gss());
* so on the first Request: AWL = AWH = ISS,
and on the n-th Request: AWL = ISS, AWH = ISS+n.
As a consequence, only Response packets that refer to Requests sent by this
host will pass, all others are discarded. This is the intention and in effect
implements the initial adjustments for AWL as specified in RFC 4340, 7.5.1.
Note: A problem that remains is that ISS can potentially be under-run even
after
the initial handshake; this is addressed a subsequent patch.
Signed-off-by: Gerrit Renker [EMAIL PROTECTED]
Yes I had seen this and had worked out that variables weren't being
updated as they should be but hadn't got as far as a fix before I
stopped my coding days so much :-(
Acked-by: Ian McDonald [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [AX25]: Kill ax25_bind() user triggable printk.
on the last run overlooked that sfuzz triggable message.
move the message to the corresponding comment.
Signed-off-by: maximilian attems [EMAIL PROTECTED]
---
net/ax25/af_ax25.c | 13 +
1 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index b4725ff..a2cc7c1 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -1038,16 +1038,13 @@ static int ax25_bind(struct socket *sock, struct
sockaddr *uaddr, int addr_len)
int err = 0;
if (addr_len != sizeof(struct sockaddr_ax25)
- addr_len != sizeof(struct full_sockaddr_ax25)) {
- /* support for old structure may go away some time */
+ addr_len != sizeof(struct full_sockaddr_ax25))
+ /* support for old structure may go away some time
+* ax25_bind(): uses old (6 digipeater) socket structure.
+*/
if ((addr_len sizeof(struct sockaddr_ax25) +
sizeof(ax25_address) * 6) ||
- (addr_len sizeof(struct full_sockaddr_ax25))) {
+ (addr_len sizeof(struct full_sockaddr_ax25)))
return -EINVAL;
- }
-
- printk(KERN_WARNING ax25_bind(): %s uses old (6 digipeater)
socket structure.\n,
- current-comm);
- }
if (addr-fsa_ax25.sax25_family != AF_AX25)
return -EINVAL;
--
1.5.4.rc4
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [AX25]: Beautify x25_init() version printk.
kill ref to old version and dup Linux. Signed-off-by: maximilian attems [EMAIL PROTECTED] --- net/x25/af_x25.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/x25/af_x25.c b/net/x25/af_x25.c index 92cfe8e..d0dbce0 100644 --- a/net/x25/af_x25.c +++ b/net/x25/af_x25.c @@ -1652,7 +1652,7 @@ static int __init x25_init(void) register_netdevice_notifier(x25_dev_notifier); - printk(KERN_INFO X.25 for Linux. Version 0.2 for Linux 2.1.15\n); + printk(KERN_INFO X.25 for Linux Version 0.2\n); #ifdef CONFIG_SYSCTL x25_register_sysctl(); -- 1.5.4.rc4 -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: sky2: tx hang on dual-port Yukon XL when rx csum disabled
Tony Battersby wrote: I am experiencing network tx hangs on a dual-port SK-9E22 with sky2 in 2.6.24. The problem is triggered by both ports transmitting at high speed simultaneously. This problem is 100% quickly reproducible. Here is the setup: PC #1 with Intel PRO/1000 NIC: e1000 IP address 192.168.1.1 running iperf -s PC #2 with Intel PRO/1000 NIC: e1000 IP address 192.168.2.1 running iperf -s PC #3 with SysKonnect SK-9E22 (dual-port copper PCI-express) sky2 IP address 192.168.1.2 sky2 IP address 192.168.2.2 So basically, I have two PCs with Intel PRO/1000 NICs running iperf -s. Each of these Intel NICs is directly cabled to one of the two ports of the SysKonnect NIC. make sure to disable the default Linux arp behavior for this kind of test on PC3 by* [EMAIL PROTECTED] echo 1 /proc/sys/net/ipv4/conf/all/arp_filter [EMAIL PROTECTED] echo 1 /proc/sys/net/ipv4/conf/eth0/arp_filter [EMAIL PROTECTED] echo 1 /proc/sys/net/ipv4/conf/eth1/arp_filter *see http://linux-ip.net/html/ether-arp.html -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: tx hang on dual-port Yukon XL when rx csum disabled
On Mon, 28 Jan 2008 13:43:19 -0500 Tony Battersby [EMAIL PROTECTED] wrote: I am experiencing network tx hangs on a dual-port SK-9E22 with sky2 in 2.6.24. The problem is triggered by both ports transmitting at high speed simultaneously. This problem is 100% quickly reproducible. Here is the setup: PC #1 with Intel PRO/1000 NIC: e1000 IP address 192.168.1.1 running iperf -s PC #2 with Intel PRO/1000 NIC: e1000 IP address 192.168.2.1 running iperf -s PC #3 with SysKonnect SK-9E22 (dual-port copper PCI-express) sky2 IP address 192.168.1.2 sky2 IP address 192.168.2.2 So basically, I have two PCs with Intel PRO/1000 NICs running iperf -s. Each of these Intel NICs is directly cabled to one of the two ports of the SysKonnect NIC. When I run: (PC #3 tty1) iperf -c 192.168.1.1 -t 30 (wait for a second or two) (PC #3 tty2) iperf -c 192.168.2.1 -t 30 iperf -c 192.168.1.1 never finishes, but iperf -c 192.168.2.1 does finish. Press Ctrl-C to abort the hung iperf. Ping 192.168.1.1 does not respond. Ping 192.168.2.1 does respond, but each ping has almost exactly 1 second latency (the latency should be 1 ms). When I switch the order of the tests, whichever iperf -c was started _first_ is the one that locks up with no ping afterward, and whichever was started _second_ is the one that finishes, but with a 1-second ping latency afterward. So the problem follows the ordering of the tests rather than a specific port. Also, the trigger seems to be transmitting, not receiving. If I run iperf -s on the SysKonnect PC and iperf -c on the two Intel PRO/1000 PCs, then the tests pass. When I do ethtool -K eth0 rx on; ethtool -K eth1 rx on to turn on rx checksumming on both ports of the SysKonnect NIC, both tests pass successfully. Commit 8b31cfbcd1b54362ef06c85beb40e65a349169a2 sky2: disable rx checksum on Yukon XL disabled rx checksumming by default on this NIC to get rid of some hw csum failure messages (http://marc.info/?l=linux-netdevm=119497815523843w=4). However, this seems to have exposed a different (and arguably worse) bug. I also tried booting with maxcpus=1 pci=nomsi, but that didn't affect the problem. As a temporary workaround, I will use ethtool to turn on rx checksumming and live with the hw csum failure messages, since they are better than network lockups. Let me know if I can be of any further assistance in tracking down this problem. Tony Battersby Cybernetics What bus and chipset is in use on the systems with sky2? I have seen problems when using PCI-X on AMD systems (documented in AMD errata) due to multiple outstanding transactions. -- Stephen Hemminger [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET]: Remove PowerPC code from fec.c
On Friday 25 January 2008, Jochen Friedrich wrote: Maybe the wording should be changed to: This driver is now only used on ColdFire (m68knommu) processors. Conditional PowerPC code has been removed. How about adding a pointer to the driver that is now used on powerpc, for the people that are looking in here? Arnd -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: tx hang on dual-port Yukon XL when rx csum disabled
What bus and chipset is in use on the systems with sky2? I have seen problems when using PCI-X on AMD systems (documented in AMD errata) due to multiple outstanding transactions. Motherboard: SuperMicro PDSME Chipset: Intel E7230 Processor: Intel Pentium D 3.4 GHz (note: tried both SMP and booting with maxcpus=1) lspci: 00:00.0 Host bridge: Intel Corporation E7230/3000/3010 Memory Controller Hub (rev 81) 00:01.0 PCI bridge: Intel Corporation E7230/3000/3010 PCI Express Root Port (rev 81) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 01) 00:1c.4 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 5 (rev 01) 00:1c.5 PCI bridge: Intel Corporation 82801GR/GH/GHM (ICH7 Family) PCI Express Port 6 (rev 01) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 01) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev e1) 00:1f.0 ISA bridge: Intel Corporation 82801GB/GR (ICH7 Family) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 01) 01:00.0 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge A (rev 09) 01:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09) 01:00.2 PCI bridge: Intel Corporation 6700PXH PCI Express-to-PCI Bridge B (rev 09) 01:00.3 PIC: Intel Corporation 6700PXH I/OxAPIC Interrupt Controller B (rev 09) 04:00.0 Ethernet controller: SysKonnect SK-9E21D 10/100/1000Base-T Adapter, Copper RJ-45 (rev 14) 05:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 06:00.0 Ethernet controller: Intel Corporation 82573E Gigabit Ethernet Controller (Copper) (rev 03) 0a:04.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) cat /proc/cpuinfo: processor: 0 vendor_id: GenuineIntel cpu family: 15 model: 6 model name: Intel(R) Pentium(R) D CPU 3.40GHz stepping: 4 cpu MHz: 3391.734 cache size: 2048 KB physical id: 0 siblings: 2 core id: 0 cpu cores: 2 fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 6 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips: 6789.26 clflush size: 64 processor: 1 vendor_id: GenuineIntel cpu family: 15 model: 6 model name: Intel(R) Pentium(R) D CPU 3.40GHz stepping: 4 cpu MHz: 3391.734 cache size: 2048 KB physical id: 0 siblings: 2 core id: 1 cpu cores: 2 fdiv_bug: no hlt_bug: no f00f_bug: no coma_bug: no fpu: yes fpu_exception: yes cpuid level: 6 wp: yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pebs bts sync_rdtsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm bogomips: 6783.57 clflush size: 64 cat /proc/interrupts CPU0 CPU1 0: 86 0 IO-APIC-edge timer 1: 81 0 IO-APIC-edge i8042 7: 0 0 IO-APIC-edge parport0 8: 1 0 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 5 0 IO-APIC-edge i8042 14: 412 0 IO-APIC-edge ide0 16: 0 0 IO-APIC-fasteoi uhci_hcd:usb5 18: 0 0 IO-APIC-fasteoi uhci_hcd:usb4 19: 31 0 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2 20: 0 0 IO-APIC-fasteoi uhci_hcd:usb3 219: 1 0 PCI-MSI-edge eth0 NMI: 0 0 Non-maskable interrupts LOC: 1924 514 Local timer interrupts RES: 16 20 Rescheduling interrupts CAL: 19 56 function call interrupts TLB: 21 41 TLB shootdowns TRM: 0 0 Thermal event interrupts SPU: 0 0 Spurious interrupts ERR: 0 MIS: 0 (note: tried booting with pci=nomsi also) Tony -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Udev coldplugging loads 8139too driver instead of 8139cp
Linux 2.6.24 kernel gives the following messages when udev coldplugging loads the driver for my NIC: 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip 8139too :00:0b.0: Use the 8139cp driver for improved performance and stability. ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 10 ACPI: PCI Interrupt :00:0b.0[A] - Link [LNK1] - GSI 10 (level, low) - IRQ 10 8139too :00:0b.0: unknown chip version, assuming RTL-8139 8139too :00:0b.0: TxConfig = 0x7480 eth1: RealTek RTL8139 at 0xcee8e800, 00:08:02:d8:d5:b9, IRQ 10 eth1: Identified 8139 chip type 'RTL-8139' ACPI: PCI Interrupt Link [LNK3] enabled at IRQ 11 PCI: setting IRQ 11 as level-triggered ACPI: PCI Interrupt :00:13.2[C] - Link [LNK3] - GSI 11 (level, low) - IRQ 11 Output of lspci -vvvn: 00:0b.0 0200: 10ec:8139 (rev 20) Subsystem: 0e11:0056 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 64 (8000ns min, 16000ns max), Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 10 Region 0: I/O ports at 9000 [size=256] Region 1: Memory at f0018800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Kernel driver in use: 8139too Kernel modules: 8139cp, 8139too Why does not udev coldpluggin first try to load 8139cp instead of 8139too? -- Frederik Himpe [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Null pointer dereference when bringing up bonding device on kernel-2.6.24-2.fc9.i686
Benny Amorsen [EMAIL PROTECTED] wrote: https://bugzilla.redhat.com/show_bug.cgi?id=430391 I know what this is, I'll fix it. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Null pointer dereference when bringing up bonding device on kernel-2.6.24-2.fc9.i686
https://bugzilla.redhat.com/show_bug.cgi?id=430391 Bringing up interface bond0: BUG: unable to handle kernel NULL pointer dereference at virtual address printing eip: c0506fd8 *pde = 7f5f8067 Oops: [#1] SMP Modules linked in: bonding ipv6 xt_pkttype ipt_LOG ipt_iprange ipt_REJECT xt_tcpudp nf_conntrack_ipv4 xt_state nf_conntrack_tftp nf_conntrack_ftp nf_conntrack iptable_filter ip_tables x_tables dm_mirror dm_mod rtc_cmos iTCO_wdt pcspkr iTCO_vendor_support e1000 i2c_i801 i2c_core button tg3 e752x_edac edac_core sr_mod sg cdrom ata_generic ata_piix pata_acpi libata sd_mod scsi_mod raid456 async_xor async_memcpy async_tx xor raid1 ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd Pid: 1620, comm: modprobe Not tainted (2.6.24-2.fc9 #1) EIP: 0060:[c0506fd8] EFLAGS: 00210202 CPU: 3 EIP is at strnicmp+0x25/0x7c EAX: f6d64062 EBX: ECX: 0010 EDX: ESI: 0010 EDI: EBP: f6f2ae64 ESP: f6f2ae50 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 Process modprobe (pid: 1620, ti=f6f2a000 task=f6fc8000 task.ti=f6f2a000) Stack: f6d64000 f8cf7a14 f780f630 f6f2ae88 f8ce6fb6 f8cf09b4 f8cf8f80 0001 f780f630 f6f2aeb0 f89a0778 f8cf1568 0064 f6f40540 f8cf7e00 f6f2aeb0 f6f40568 f8cf7e00 f8cf7e00 Call Trace: [c04064b6] show_trace_log_lvl+0x1a/0x2f [c0406566] show_stack_log_lvl+0x9b/0xa3 [c0406615] show_registers+0xa7/0x178 [c040681b] die+0x135/0x220 [c0640bd3] do_page_fault+0x553/0x631 [c063f25a] error_code+0x72/0x78 [f8ce6fb6] bond_create+0x40/0x2da [bonding] [f89a0778] bonding_init+0x778/0x802 [bonding] [c045482d] sys_init_module+0x1430/0x155c [c040526e] syscall_call+0x7/0xb === Code: 89 d0 5e 5f 5d c3 55 89 e5 57 31 ff 56 89 ce 53 31 db 83 ec 08 85 c9 89 45 f0 89 55 ec eb 50 31 ff eb 4e 8b 55 f0 8a 02 8b 55 ec 8a 1a 42 ff 45 f0 84 c0 89 55 ec 74 e7 84 db 89 c7 74 33 38 d8 EIP: [c0506fd8] strnicmp+0x25/0x7c SS:ESP 0068:f6f2ae50 ---[ end trace b1f7597239228b36 ]--- ./network-functions: line 216: 1620 Segmentation fault modprobe $1 /dev/null 21 Sorry if bugs in distribution kernels are less interesting. /Benny -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] 9p: kill dead static inline buf_put_string
On Jan 25, 2008 4:46 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote: From: =?ISO-8859-1?q?Ilpo=20J=E4rvinen?= [EMAIL PROTECTED] Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] Acked-by: Eric Van Hensbergen [EMAIL PROTECTED] -eric -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
sky2: tx hang on dual-port Yukon XL when rx csum disabled
I am experiencing network tx hangs on a dual-port SK-9E22 with sky2 in 2.6.24. The problem is triggered by both ports transmitting at high speed simultaneously. This problem is 100% quickly reproducible. Here is the setup: PC #1 with Intel PRO/1000 NIC: e1000 IP address 192.168.1.1 running iperf -s PC #2 with Intel PRO/1000 NIC: e1000 IP address 192.168.2.1 running iperf -s PC #3 with SysKonnect SK-9E22 (dual-port copper PCI-express) sky2 IP address 192.168.1.2 sky2 IP address 192.168.2.2 So basically, I have two PCs with Intel PRO/1000 NICs running iperf -s. Each of these Intel NICs is directly cabled to one of the two ports of the SysKonnect NIC. When I run: (PC #3 tty1) iperf -c 192.168.1.1 -t 30 (wait for a second or two) (PC #3 tty2) iperf -c 192.168.2.1 -t 30 iperf -c 192.168.1.1 never finishes, but iperf -c 192.168.2.1 does finish. Press Ctrl-C to abort the hung iperf. Ping 192.168.1.1 does not respond. Ping 192.168.2.1 does respond, but each ping has almost exactly 1 second latency (the latency should be 1 ms). When I switch the order of the tests, whichever iperf -c was started _first_ is the one that locks up with no ping afterward, and whichever was started _second_ is the one that finishes, but with a 1-second ping latency afterward. So the problem follows the ordering of the tests rather than a specific port. Also, the trigger seems to be transmitting, not receiving. If I run iperf -s on the SysKonnect PC and iperf -c on the two Intel PRO/1000 PCs, then the tests pass. When I do ethtool -K eth0 rx on; ethtool -K eth1 rx on to turn on rx checksumming on both ports of the SysKonnect NIC, both tests pass successfully. Commit 8b31cfbcd1b54362ef06c85beb40e65a349169a2 sky2: disable rx checksum on Yukon XL disabled rx checksumming by default on this NIC to get rid of some hw csum failure messages (http://marc.info/?l=linux-netdevm=119497815523843w=4). However, this seems to have exposed a different (and arguably worse) bug. I also tried booting with maxcpus=1 pci=nomsi, but that didn't affect the problem. As a temporary workaround, I will use ethtool to turn on rx checksumming and live with the hw csum failure messages, since they are better than network lockups. Let me know if I can be of any further assistance in tracking down this problem. Tony Battersby Cybernetics -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24 regression: Wake On Lan in sky2 broken on Mac mini
On Mon, 28 Jan 2008 09:48:55 +0100 Tino Keitel [EMAIL PROTECTED] wrote: On Mon, Jan 28, 2008 at 09:21:30 +0100, Mikael Pettersson wrote: Tino Keitel writes: Hi folks, with 2.6.24-rc8, Wake On LAN doesn't work anymore as it used to with 2.6.23 on my Mac mini Core Duo. I saw that this was reported in http://bugzilla.kernel.org/show_bug.cgi?id=9721 and on netdev a patch for the sky2 driver was sent by Stephen Hemminger. This patch fixed WOL for me after applying it to 2.6.24-rc8. However, it seems as the patch never made it into the kernel. Instead, the commit that was suspected to break WOL (84cd2dfb04d23a961c5f537baa243fa54d0987ac) was reverted (be63a21c9573fbf88106ff0f030da5974551257b). Now I tried the 2.6.24 release and noticed that WOL is still broken. I'll be happy to test any patches that can make it into 2.6.24.1. 1. Wrong mailing list; use netdev (@vger) instead. Done. 2. The reverted commit had much much more serious consequences than wol doesn't work, it actually caused BIOS hangs and failed reboots. Yes, but even with the reverted commit, WOL still doesn't work. I just tried the patch from the netdev mailing list with the 2.6.24 release version and now WOL works for me. Patch went to Jeff, but never made it into 2.6.24. The timing was just wrong. -- Stephen Hemminger [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sky2: tx hang on dual-port Yukon XL when rx csum disabled
Brandeburg, Jesse wrote: make sure to disable the default Linux arp behavior for this kind of test on PC3 by* [EMAIL PROTECTED] echo 1 /proc/sys/net/ipv4/conf/all/arp_filter [EMAIL PROTECTED] echo 1 /proc/sys/net/ipv4/conf/eth0/arp_filter [EMAIL PROTECTED] echo 1 /proc/sys/net/ipv4/conf/eth1/arp_filter *see http://linux-ip.net/html/ether-arp.html Yeah, that bit me a few years ago, and I now have it in one of my boot startup scripts... But thanks anyway. Tony -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] security/selinux/netlabel.c: fix double free
This patch fixes a double free (security_netlbl_sid_to_secattr() already
calls netlbl_secattr_destroy() when it returns !0) introduced by
commit 45c950e0f839fded922ebc0bfd59b1081cc71b70 and spotted by the
Coverity checker.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6/security/selinux/netlabel.c.old 2008-01-23 00:38:19.0
+0200
+++ linux-2.6/security/selinux/netlabel.c 2008-01-23 00:39:09.0
+0200
@@ -58,22 +58,22 @@ static int selinux_netlbl_sock_setsid(st
rc = security_netlbl_sid_to_secattr(sid, secattr);
if (rc != 0)
goto sock_setsid_return;
rc = netlbl_sock_setattr(sk, secattr);
if (rc == 0) {
spin_lock_bh(sksec-nlbl_lock);
sksec-nlbl_state = NLBL_LABELED;
spin_unlock_bh(sksec-nlbl_lock);
}
-sock_setsid_return:
netlbl_secattr_destroy(secattr);
+sock_setsid_return:
return rc;
}
/**
* selinux_netlbl_cache_invalidate - Invalidate the NetLabel cache
*
* Description:
* Invalidate the NetLabel security attribute mapping cache.
*
*/
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bugme-new] [Bug 9836] New: e1000 network driver doesn't recognize (and load on) its hardware
On Mon, 28 Jan 2008 05:32:00 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9836 Summary: e1000 network driver doesn't recognize (and load on) its hardware Product: Drivers Version: 2.5 KernelVersion: 2.6.24 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: blocking Priority: P1 Component: Network AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Latest working kernel version: not known Earliest failing kernel version: every Distribution: Fedora Core 7 Hardware Environment: lspci output and dmesg information are attached Software Environment: doesn't matter Problem Description: recently e1000 network drivers stopped working when right after switching on or rebooting our Intel server. While trying to 'modprobe e1000; ifconfig eth0 IP_address' I've got a failure and e1000 says hardware is not detected. After about a *hundred* attempts to modprobe and rmmod it, the e1000 network driver finally loads and allows to set up networking. Steps to reproduce: reboot or power on your server. Try to up the network which is attached to your Intel PCI-X Pro 1000 NIC. Odd. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Bugme-new] [Bug 9836] New: e1000 network driver doesn't recognize (and load on) its hardware
Andrew Morton wrote: On Mon, 28 Jan 2008 05:32:00 -0800 (PST) [EMAIL PROTECTED] wrote: http://bugzilla.kernel.org/show_bug.cgi?id=9836 Problem Description: recently e1000 network drivers stopped working when right after switching on or rebooting our Intel server. While trying to 'modprobe e1000; ifconfig eth0 IP_address' I've got a failure and e1000 says hardware is not detected. After about a *hundred* attempts to modprobe and rmmod it, the e1000 network driver finally loads and allows to set up networking. I'm not sure how you figured out rmmod/insmoding the driver gets you working, but I don't see any failure messages in the dmesg log you sent, I just see: Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :07:04.0[A] - GSI 16 (level, low) - IRQ 16 e1000: :07:04.0: e1000_probe: (PCI:33MHz:32-bit) 00:04:23:cc:82:5e e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection ACPI: PCI interrupt for device :07:04.0 disabled Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :07:04.0[A] - GSI 16 (level, low) - IRQ 16 e1000: :07:04.0: e1000_probe: (PCI:33MHz:32-bit) 00:04:23:cc:82:5e e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection ACPI: PCI interrupt for device :07:04.0 disabled Intel(R) PRO/1000 Network Driver - version 7.3.20-k2-NAPI Copyright (c) 1999-2006 Intel Corporation. ACPI: PCI Interrupt :07:04.0[A] - GSI 16 (level, low) - IRQ 16 e1000: :07:04.0: e1000_probe: (PCI:33MHz:32-bit) 00:04:23:cc:82:5e e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection e1000: eth0: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex, Flow Control: RX/TX I believe the PCI interrupt for device 7:4.0 disabled is you unloading the driver again each time, and I don't see any messages at all that indicate the driver knows anything is wrong. can you run 'ethtool -t eth0 offline' after rebooting, loading the module, ifconfig eth0 up, and waiting 4 seconds? what does ethtool eth0 say after loading the driver (before you ifconfig up it?) are you sure you're not having some udev problem? Can you send the console output or attach it to the bug? Steps to reproduce: reboot or power on your server. Try to up the network which is attached to your Intel PCI-X Pro 1000 NIC. This is a PCI only adapter, FYI. Odd. agreed, something doesn't add up here, yet. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[2.6 patch] remove the obsolete xircom_tulip_cb driver
The xircom_tulip_cb driver has been replaced the xircom_cb driver, and since it depended on BROKEN_ON_SMP it e.g. was no longer present in many distribution kernels. This patch therefore removes it. Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- drivers/net/tulip/Kconfig | 15 drivers/net/tulip/Makefile |1 drivers/net/tulip/xircom_tulip_cb.c | 1726 3 files changed, 1 insertion(+), 1741 deletions(-) fe38501034c6105dbb1ad770dafda42548357ea9 diff --git a/drivers/net/tulip/Kconfig b/drivers/net/tulip/Kconfig index 20ac150..d913405 100644 --- a/drivers/net/tulip/Kconfig +++ b/drivers/net/tulip/Kconfig @@ -141,7 +141,7 @@ config ULI526X be called uli526x. config PCMCIA_XIRCOM - tristate Xircom CardBus support (new driver) + tristate Xircom CardBus support depends on CARDBUS ---help--- This driver is for the Digital Tulip Ethernet CardBus adapters. @@ -152,17 +152,4 @@ config PCMCIA_XIRCOM To compile this driver as a module, choose M here. The module will be called xircom_cb. If unsure, say N. -config PCMCIA_XIRTULIP - tristate Xircom Tulip-like CardBus support (old driver) - depends on CARDBUS BROKEN_ON_SMP - select CRC32 - ---help--- - This driver is for the Digital Tulip Ethernet CardBus adapters. - It should work with most DEC 21*4*-based chips/ethercards, as well - as with work-alike chips from Lite-On (PNIC) and Macronix (MXIC) and - ASIX. - - To compile this driver as a module, choose M here. The module will - be called xircom_tulip_cb. If unsure, say N. - endif # NET_TULIP diff --git a/drivers/net/tulip/Makefile b/drivers/net/tulip/Makefile index 451090d..200cbf7 100644 --- a/drivers/net/tulip/Makefile +++ b/drivers/net/tulip/Makefile @@ -2,7 +2,6 @@ # Makefile for the Linux Tulip family network device drivers. # -obj-$(CONFIG_PCMCIA_XIRTULIP) += xircom_tulip_cb.o obj-$(CONFIG_PCMCIA_XIRCOM)+= xircom_cb.o obj-$(CONFIG_DM9102) += dmfe.o obj-$(CONFIG_WINBOND_840) += winbond-840.o diff --git a/drivers/net/tulip/xircom_tulip_cb.c b/drivers/net/tulip/xircom_tulip_cb.c deleted file mode 100644 index c3f8e30..000 --- a/drivers/net/tulip/xircom_tulip_cb.c +++ /dev/null @@ -1,1726 +0,0 @@ -/* xircom_tulip_cb.c: A Xircom CBE-100 ethernet driver for Linux. */ -/* - Written/copyright 1994-1999 by Donald Becker. - - This software may be used and distributed according to the terms - of the GNU General Public License, incorporated herein by reference. - - The author may be reached as [EMAIL PROTECTED], or C/O - Scyld Computing Corporation - 410 Severn Ave., Suite 210 - Annapolis MD 21403 - -*/ - -#define DRV_NAME xircom_tulip_cb -#define DRV_VERSION0.92 -#define DRV_RELDATEJune 27, 2006 - -/* A few user-configurable values. */ - -#define xircom_debug debug -#ifdef XIRCOM_DEBUG -static int xircom_debug = XIRCOM_DEBUG; -#else -static int xircom_debug = 1; -#endif - -/* Maximum events (Rx packets, etc.) to handle at each interrupt. */ -static int max_interrupt_work = 25; - -#define MAX_UNITS 4 -/* Used to pass the full-duplex flag, etc. */ -static int full_duplex[MAX_UNITS]; -static int options[MAX_UNITS]; -static int mtu[MAX_UNITS]; /* Jumbo MTU for interfaces. */ - -/* Keep the ring sizes a power of two for efficiency. - Making the Tx ring too large decreases the effectiveness of channel - bonding and packet priority. - There are no ill effects from too-large receive rings. */ -#define TX_RING_SIZE 16 -#define RX_RING_SIZE 32 - -/* Set the copy breakpoint for the copy-only-tiny-buffer Rx structure. */ -#ifdef __alpha__ -static int rx_copybreak = 1518; -#else -static int rx_copybreak = 100; -#endif - -/* - Set the bus performance register. - Typical: Set 16 longword cache alignment, no burst limit. - Cache alignment bits 15:14 Burst length 13:8 - No alignment 0x unlimited 0800 8 longwords - 40008 longwords0100 1 longword 1000 16 longwords - 800016 longwords0200 2 longwords2000 32 longwords - C00032 longwords 0400 4 longwords - Warning: many older 486 systems are broken and require setting 0x00A04800 - 8 longword cache alignment, 8 longword burst. - ToDo: Non-Intel setting could be better. -*/ - -#if defined(__alpha__) || defined(__ia64__) || defined(__x86_64__) -static int csr0 = 0x01A0 | 0xE000; -#elif defined(__powerpc__) -static int csr0 = 0x01B0 | 0x8000; -#elif defined(CONFIG_SPARC) -static int csr0 = 0x01B00080 | 0x8000; -#elif defined(__i386__) -static int csr0 = 0x01A0 | 0x8000; -#else -#warning Processor architecture undefined! -static int csr0 = 0x00A0 | 0x4800;
Re: [2.6 patch] security/selinux/netlabel.c: fix double free
On Monday 28 January 2008 5:35:40 pm Adrian Bunk wrote: On Mon, Jan 28, 2008 at 05:23:46PM -0500, Paul Moore wrote: Thanks for finding this mistake, however, I'd rather see it fixed by removing the netlbl_secattr_destroy() call in security_netlbl_sid_to_secattr() as it really shouldn't be there anymore. We moved the matching _init() call into selinux_netlbl_sock_setsid() and I'd like to see the _init() and _destroy() calls done in the same function. I can push a revised patch for this if you would prefer, otherwise I'll be happy to ack an updated version ... doing the patch is trivial but you are able to write a better changelog for it - just push a revised patch. Will do, thanks. -- paul moore linux security @ hp -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ixgb: enable sun hardware support for broadcom phy
Matheos Worku wrote: Jeff Garzik wrote: Auke Kok wrote: From: Matheos Worku [EMAIL PROTECTED] Implement support for a SUN-specific PHY. SUN provides a modified 82597-based board with their own PHY that works with very little modification to the code. This patch implements this new PHY which is identified by the subvendor device ID. The device ID of the adapter remains the same. Signed-off-by: Matheos Worku [EMAIL PROTECTED] Signed-off-by: Jesse Brandeburg [EMAIL PROTECTED] Signed-off-by: Auke Kok [EMAIL PROTECTED] --- drivers/net/ixgb/ixgb_hw.c | 82 +- drivers/net/ixgb/ixgb_hw.h |3 +- drivers/net/ixgb/ixgb_ids.h |4 ++ drivers/net/ixgb/ixgb_main.c | 10 +++-- 4 files changed, 91 insertions(+), 8 deletions(-) applied #upstream Jeff, Bleated Happy New Year. I was wondering when this patch will make it to Linus' and other trees. I just checked Linus's and other net trees, including git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git and I see only the other patch's commit: 3fd7131feacc01c1e23e46c416228f36ebdcc0d4, and not this patch. It's in the upstream branch of that tree: http://git.kernel.org/?p=linux/kernel/git/jgarzik/netdev-2.6.git;a=history;f=drivers/net/ixgb;hb=upstream this should be merged in the currently open merge window, so you'll find it eventually in the 2.6.25 kernel release. Cheers, Auke -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] security/selinux/netlabel.c: fix double free
On Mon, Jan 28, 2008 at 05:23:46PM -0500, Paul Moore wrote: On Monday 28 January 2008 5:09:38 pm Adrian Bunk wrote: This patch fixes a double free (security_netlbl_sid_to_secattr() already calls netlbl_secattr_destroy() when it returns !0) introduced by commit 45c950e0f839fded922ebc0bfd59b1081cc71b70 and spotted by the Coverity checker. Hi Adrian, Hi Paul, Thanks for finding this mistake, however, I'd rather see it fixed by removing the netlbl_secattr_destroy() call in security_netlbl_sid_to_secattr() as it really shouldn't be there anymore. We moved the matching _init() call into selinux_netlbl_sock_setsid() and I'd like to see the _init() and _destroy() calls done in the same function. I can push a revised patch for this if you would prefer, otherwise I'll be happy to ack an updated version ... doing the patch is trivial but you are able to write a better changelog for it - just push a revised patch. paul moore cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [2.6 patch] security/selinux/netlabel.c: fix double free
On Monday 28 January 2008 5:09:38 pm Adrian Bunk wrote:
This patch fixes a double free (security_netlbl_sid_to_secattr()
already calls netlbl_secattr_destroy() when it returns !0) introduced
by commit 45c950e0f839fded922ebc0bfd59b1081cc71b70 and spotted by the
Coverity checker.
Hi Adrian,
Thanks for finding this mistake, however, I'd rather see it fixed by
removing the netlbl_secattr_destroy() call in
security_netlbl_sid_to_secattr() as it really shouldn't be there
anymore. We moved the matching _init() call into
selinux_netlbl_sock_setsid() and I'd like to see the _init() and
_destroy() calls done in the same function. I can push a revised patch
for this if you would prefer, otherwise I'll be happy to ack an updated
version ...
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
---
--- linux-2.6/security/selinux/netlabel.c.old 2008-01-23
00:38:19.0 +0200 +++
linux-2.6/security/selinux/netlabel.c 2008-01-23 00:39:09.0
+0200 @@ -58,22 +58,22 @@ static int selinux_netlbl_sock_setsid(st rc
= security_netlbl_sid_to_secattr(sid, secattr);
if (rc != 0)
goto sock_setsid_return;
rc = netlbl_sock_setattr(sk, secattr);
if (rc == 0) {
spin_lock_bh(sksec-nlbl_lock);
sksec-nlbl_state = NLBL_LABELED;
spin_unlock_bh(sksec-nlbl_lock);
}
-sock_setsid_return:
netlbl_secattr_destroy(secattr);
+sock_setsid_return:
return rc;
}
/**
* selinux_netlbl_cache_invalidate - Invalidate the NetLabel cache
*
* Description:
* Invalidate the NetLabel security attribute mapping cache.
*
*/
--
paul moore
linux security @ hp
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] bonding: fix race that causes invalid statistics
I've seen reports of invalid stats in /proc/net/dev for bonding
interfaces, and found it's a pretty easy problem to reproduce. Since
the current code zeros the bonding stats when a read is requested and a
pointer to that data is returned to the caller we cannot guarantee that
the caller has completely accessed the data before a successive call to
request the stats zeroes the stats again.
This patch creates a new stack variable to keep track of the updated
stats and copies the data from that variable into the bonding stats
structure. This ensures that the value for any of the bonding stats
should not incorrectly return zero for any of the bonding statistics.
This does use more stack space and require an extra memcpy, but it seems
like a fair trade-off for consistently correct bonding statistics.
Signed-off-by: Andy Gospodarek [EMAIL PROTECTED]
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
bond_main.c | 57 ++---
1 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 49a1982..901de6d 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3769,41 +3769,44 @@ static struct net_device_stats *bond_get_stats(struct
net_device *bond_dev)
{
struct bonding *bond = bond_dev-priv;
struct net_device_stats *stats = (bond-stats), *sstats;
+ struct net_device_stats local_stats;
struct slave *slave;
int i;
- memset(stats, 0, sizeof(struct net_device_stats));
+ memset(local_stats, 0, sizeof(struct net_device_stats));
read_lock_bh(bond-lock);
bond_for_each_slave(bond, slave, i) {
sstats = slave-dev-get_stats(slave-dev);
- stats-rx_packets += sstats-rx_packets;
- stats-rx_bytes += sstats-rx_bytes;
- stats-rx_errors += sstats-rx_errors;
- stats-rx_dropped += sstats-rx_dropped;
-
- stats-tx_packets += sstats-tx_packets;
- stats-tx_bytes += sstats-tx_bytes;
- stats-tx_errors += sstats-tx_errors;
- stats-tx_dropped += sstats-tx_dropped;
-
- stats-multicast += sstats-multicast;
- stats-collisions += sstats-collisions;
-
- stats-rx_length_errors += sstats-rx_length_errors;
- stats-rx_over_errors += sstats-rx_over_errors;
- stats-rx_crc_errors += sstats-rx_crc_errors;
- stats-rx_frame_errors += sstats-rx_frame_errors;
- stats-rx_fifo_errors += sstats-rx_fifo_errors;
- stats-rx_missed_errors += sstats-rx_missed_errors;
-
- stats-tx_aborted_errors += sstats-tx_aborted_errors;
- stats-tx_carrier_errors += sstats-tx_carrier_errors;
- stats-tx_fifo_errors += sstats-tx_fifo_errors;
- stats-tx_heartbeat_errors += sstats-tx_heartbeat_errors;
- stats-tx_window_errors += sstats-tx_window_errors;
- }
+ local_stats.rx_packets += sstats-rx_packets;
+ local_stats.rx_bytes += sstats-rx_bytes;
+ local_stats.rx_errors += sstats-rx_errors;
+ local_stats.rx_dropped += sstats-rx_dropped;
+
+ local_stats.tx_packets += sstats-tx_packets;
+ local_stats.tx_bytes += sstats-tx_bytes;
+ local_stats.tx_errors += sstats-tx_errors;
+ local_stats.tx_dropped += sstats-tx_dropped;
+
+ local_stats.multicast += sstats-multicast;
+ local_stats.collisions += sstats-collisions;
+
+ local_stats.rx_length_errors += sstats-rx_length_errors;
+ local_stats.rx_over_errors += sstats-rx_over_errors;
+ local_stats.rx_crc_errors += sstats-rx_crc_errors;
+ local_stats.rx_frame_errors += sstats-rx_frame_errors;
+ local_stats.rx_fifo_errors += sstats-rx_fifo_errors;
+ local_stats.rx_missed_errors += sstats-rx_missed_errors;
+
+ local_stats.tx_aborted_errors += sstats-tx_aborted_errors;
+ local_stats.tx_carrier_errors += sstats-tx_carrier_errors;
+ local_stats.tx_fifo_errors += sstats-tx_fifo_errors;
+ local_stats.tx_heartbeat_errors += sstats-tx_heartbeat_errors;
+ local_stats.tx_window_errors += sstats-tx_window_errors;
+ }
+
+ memcpy(stats,local_stats,sizeof(net_device_stats));
read_unlock_bh(bond-lock);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
net-2.6.25 status...
I've been busy here at LCA08 rebasing the net-2.6.25
tree getting it ready for pushing to Linus.
Most of the conflicts were to the usual places, such
as the feature removal schedule text file, things
like drivers/net/{Kconfig,Makefile} etc.
I just send Linus a pull request so if he takes it
then it will show up soon in his tree.
I've powered-on my Niagara boxes back home so I can do
lots of regression builds.
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: fix race that causes invalid statistics
Jay Vosburgh wrote: Andy Gospodarek [EMAIL PROTECTED] wrote: + memcpy(stats,local_stats,sizeof(net_device_stats)); FYI, this generates a compiler error (missing the word struct in here). Other than not compiling, the patch seems reasonable. I'll fix it up and include it in the series I'll post tomorrow or so. -J Looks like Andy sent the draft version by mistake. We did in fact test an otherwise identical patch, which did fix the bug. -- Chris -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: fix race that causes invalid statistics
Andy Gospodarek [EMAIL PROTECTED] wrote: + memcpy(stats,local_stats,sizeof(net_device_stats)); FYI, this generates a compiler error (missing the word struct in here). Other than not compiling, the patch seems reasonable. I'll fix it up and include it in the series I'll post tomorrow or so. -J --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25] [IPV6] ADDRLABEL: Fix double free on label deletion.
From: YOSHIFUJI Hideaki / 吉藤英明 [EMAIL PROTECTED] Date: Mon, 28 Jan 2008 21:02:22 +0900 (JST) If an entry is being deleted because it has only one reference, we immediately delete it and blindly register the rcu handler for it, This results in oops by double freeing that object. This patch fixes it by consolidating the code paths for the deletion; let its rcu handler delete the object if it has no more reference. Bug was found by Mitsuru Chinen [EMAIL PROTECTED] Signed-off-by: YOSHIFUJI Hideaki [EMAIL PROTECTED] Applied, thank you. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PHYLIB: Locking fixes for PHY I/O potentially sleeping
From: Andy Fleming [EMAIL PROTECTED] Date: Mon, 28 Jan 2008 18:29:39 -0600 Jeff, Dave, any chance we can get this one in for 2.6.25? It will allow a number of other drivers to start using PHY Lib. I'm sure Nate can resend if needed. This shouldn't be a problem. I just did my initial merge with Linus, so after he pulls that in Jeff can merge stuff like this to me so that it can go into my second pass. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] bonding: fix race that causes invalid statistics
On Mon, Jan 28, 2008 at 03:59:03PM -0800, Jay Osbourn wrote:
Andy Gospodarek [EMAIL PROTECTED] wrote:
+memcpy(stats,local_stats,sizeof(net_device_stats));
FYI, this generates a compiler error (missing the word struct
in here). Other than not compiling, the patch seems reasonable. I'll
fix it up and include it in the series I'll post tomorrow or so.
-J
Crap. Here's the one I intended to send.
Signed-off-by: Andy Gospodarek [EMAIL PROTECTED]
Signed-off-by: Chris Snook [EMAIL PROTECTED]
---
bond_main.c | 57 ++---
1 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index 49a1982..901de6d 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3769,41 +3769,44 @@ static struct net_device_stats *bond_get_stats(struct
net_device *bond_dev)
{
struct bonding *bond = bond_dev-priv;
struct net_device_stats *stats = (bond-stats), *sstats;
+ struct net_device_stats local_stats;
struct slave *slave;
int i;
- memset(stats, 0, sizeof(struct net_device_stats));
+ memset(local_stats, 0, sizeof(struct net_device_stats));
read_lock_bh(bond-lock);
bond_for_each_slave(bond, slave, i) {
sstats = slave-dev-get_stats(slave-dev);
- stats-rx_packets += sstats-rx_packets;
- stats-rx_bytes += sstats-rx_bytes;
- stats-rx_errors += sstats-rx_errors;
- stats-rx_dropped += sstats-rx_dropped;
-
- stats-tx_packets += sstats-tx_packets;
- stats-tx_bytes += sstats-tx_bytes;
- stats-tx_errors += sstats-tx_errors;
- stats-tx_dropped += sstats-tx_dropped;
-
- stats-multicast += sstats-multicast;
- stats-collisions += sstats-collisions;
-
- stats-rx_length_errors += sstats-rx_length_errors;
- stats-rx_over_errors += sstats-rx_over_errors;
- stats-rx_crc_errors += sstats-rx_crc_errors;
- stats-rx_frame_errors += sstats-rx_frame_errors;
- stats-rx_fifo_errors += sstats-rx_fifo_errors;
- stats-rx_missed_errors += sstats-rx_missed_errors;
-
- stats-tx_aborted_errors += sstats-tx_aborted_errors;
- stats-tx_carrier_errors += sstats-tx_carrier_errors;
- stats-tx_fifo_errors += sstats-tx_fifo_errors;
- stats-tx_heartbeat_errors += sstats-tx_heartbeat_errors;
- stats-tx_window_errors += sstats-tx_window_errors;
- }
+ local_stats.rx_packets += sstats-rx_packets;
+ local_stats.rx_bytes += sstats-rx_bytes;
+ local_stats.rx_errors += sstats-rx_errors;
+ local_stats.rx_dropped += sstats-rx_dropped;
+
+ local_stats.tx_packets += sstats-tx_packets;
+ local_stats.tx_bytes += sstats-tx_bytes;
+ local_stats.tx_errors += sstats-tx_errors;
+ local_stats.tx_dropped += sstats-tx_dropped;
+
+ local_stats.multicast += sstats-multicast;
+ local_stats.collisions += sstats-collisions;
+
+ local_stats.rx_length_errors += sstats-rx_length_errors;
+ local_stats.rx_over_errors += sstats-rx_over_errors;
+ local_stats.rx_crc_errors += sstats-rx_crc_errors;
+ local_stats.rx_frame_errors += sstats-rx_frame_errors;
+ local_stats.rx_fifo_errors += sstats-rx_fifo_errors;
+ local_stats.rx_missed_errors += sstats-rx_missed_errors;
+
+ local_stats.tx_aborted_errors += sstats-tx_aborted_errors;
+ local_stats.tx_carrier_errors += sstats-tx_carrier_errors;
+ local_stats.tx_fifo_errors += sstats-tx_fifo_errors;
+ local_stats.tx_heartbeat_errors += sstats-tx_heartbeat_errors;
+ local_stats.tx_window_errors += sstats-tx_window_errors;
+ }
+
+ memcpy(stats,local_stats,sizeof(struct net_device_stats));
read_unlock_bh(bond-lock);
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET]: Remove PowerPC code from fec.c
-- Forwarded message --
Date: Fri, 25 Jan 2008 15:33:45 +0100
From: Jochen Friedrich [EMAIL PROTECTED]
To: Garzik, Jeff [EMAIL PROTECTED]
Cc: Vitaly Bordug [EMAIL PROTECTED],
Scott Wood [EMAIL PROTECTED],
Kumar Gala [EMAIL PROTECTED],
Geert Uytterhoeven [EMAIL PROTECTED],
Kernel, Linux [EMAIL PROTECTED],
netdev@vger.kernel.org netdev@vger.kernel.org,
linuxppc-dev list [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: [PATCH] [NET]: Remove PowerPC code from fec.c
fec.c is only used on M68k Coldfire CPUs. Remove leftover
PowerPC code from this driver.
I was always hoping that this driver would be supported on both
architectures. After all the underlying eth device is essentially
the same on both.
Anyway... I don't have a problem with this patch, looks ok
the me.
Acked-by: Greg Ungerer [EMAIL PROTECTED]
Regards
Greg
Signed-off-by: Jochen Friedrich [EMAIL PROTECTED]
---
drivers/net/fec.c | 136
+---
1 files changed, 3 insertions(+), 133 deletions(-)
diff --git a/drivers/net/fec.c b/drivers/net/fec.c
index 0fbf1bb..0499cbb 100644
--- a/drivers/net/fec.c
+++ b/drivers/net/fec.c
@@ -23,6 +23,9 @@
*
* Bug fixes and cleanup by Philippe De Muyter ([EMAIL PROTECTED])
* Copyright (c) 2004-2006 Macq Electronique SA.
+ *
+ * This driver is now only used on ColdFire processors. Remove
conditional
+ * Powerpc code.
*/
#include linux/module.h
@@ -49,17 +52,9 @@
#include asm/pgtable.h
#include asm/cacheflush.h
-#if defined(CONFIG_M523x) || defined(CONFIG_M527x) || \
-defined(CONFIG_M5272) || defined(CONFIG_M528x) || \
-defined(CONFIG_M520x) || defined(CONFIG_M532x)
#include asm/coldfire.h
#include asm/mcfsim.h
#include fec.h
-#else
-#include asm/8xx_immap.h
-#include asm/mpc8xx.h
-#include commproc.h
-#endif
#if defined(CONFIG_FEC2)
#define FEC_MAX_PORTS 2
@@ -1223,14 +1218,9 @@ static phy_info_t const * const phy_info[] = {
/*
- */
#if !defined(CONFIG_M532x)
-#ifdef CONFIG_RPXCLASSIC
-static void
-mii_link_interrupt(void *dev_id);
-#else
static irqreturn_t
mii_link_interrupt(int irq, void * dev_id);
#endif
-#endif
#if defined(CONFIG_M5272)
/*
@@ -1800,121 +1790,6 @@ static void __inline__ fec_uncache(unsigned
long addr)
/*
- */
-#else
-
-/*
- *Code specific to the MPC860T setup.
- */
-static void __inline__ fec_request_intrs(struct net_device *dev)
-{
- volatile immap_t *immap;
-
- immap = (immap_t *)IMAP_ADDR; /* pointer to internal registers */
-
- if (request_8xxirq(FEC_INTERRUPT, fec_enet_interrupt, 0, fec,
dev) != 0)
- panic(Could not allocate FEC IRQ!);
-
-#ifdef CONFIG_RPXCLASSIC
- /* Make Port C, bit 15 an input that causes interrupts.
- */
- immap-im_ioport.iop_pcpar = ~0x0001;
- immap-im_ioport.iop_pcdir = ~0x0001;
- immap-im_ioport.iop_pcso = ~0x0001;
- immap-im_ioport.iop_pcint |= 0x0001;
- cpm_install_handler(CPMVEC_PIO_PC15, mii_link_interrupt, dev);
-
- /* Make LEDS reflect Link status.
- */
- *((uint *) RPX_CSR_ADDR) = ~BCSR2_FETHLEDMODE;
-#endif
-#ifdef CONFIG_FADS
- if (request_8xxirq(SIU_IRQ2, mii_link_interrupt, 0, mii, dev) != 0)
- panic(Could not allocate MII IRQ!);
-#endif
-}
-
-static void __inline__ fec_get_mac(struct net_device *dev)
-{
- bd_t *bd;
-
- bd = (bd_t *)__res;
- memcpy(dev-dev_addr, bd-bi_enetaddr, ETH_ALEN);
-
-#ifdef CONFIG_RPXCLASSIC
- /* The Embedded Planet boards have only one MAC address in
- * the EEPROM, but can have two Ethernet ports. For the
- * FEC port, we create another address by setting one of
- * the address bits above something that would have (up to
- * now) been allocated.
- */
- dev-dev_adrd[3] |= 0x80;
-#endif
-}
-
-static void __inline__ fec_set_mii(struct net_device *dev, struct
fec_enet_private *fep)
-{
- extern uint _get_IMMR(void);
- volatile immap_t *immap;
- volatile fec_t *fecp;
-
- fecp = fep-hwp;
- immap = (immap_t *)IMAP_ADDR; /* pointer to internal registers */
-
- /* Configure all of port D for MII.
- */
- immap-im_ioport.iop_pdpar = 0x1fff;
-
- /* Bits moved from Rev. D onward.
- */
- if ((_get_IMMR() 0x) 0x0501)
- immap-im_ioport.iop_pddir = 0x1c58; /* Pre rev. D */
- else
- immap-im_ioport.iop_pddir = 0x1fff; /* Rev. D and later */
-
- /* Set MII speed to 2.5 MHz
- */
- fecp-fec_mii_speed = fep-phy_speed =
- ((bd-bi_busfreq * 100) / 250) 0x7e;
-}
-
-static void __inline__ fec_enable_phy_intr(void)
-{
- volatile fec_t *fecp;
-
- fecp = fep-hwp;
-
- /* Enable MII command finished interrupt
- */
- fecp-fec_ivec = (FEC_INTERRUPT/2) 29;
-}
-
-static void __inline__
Re: [PATCH] PHYLIB: Locking fixes for PHY I/O potentially sleeping
Andy Fleming wrote: Jeff, Dave, any chance we can get this one in for 2.6.25? It will allow a number of other drivers to start using PHY Lib. I'm sure Nate can resend if needed. On Jan 3, 2008, at 17:36, Nate Case wrote: PHY read/write functions can potentially sleep (e.g., a PHY accessed via I2C). The following changes were made to account for this: * Change spin locks to mutex locks * Add a BUG_ON() to phy_read() phy_write() to warn against calling them from an interrupt context. * Use work queue for PHY state machine handling since it can potentially sleep * Change phydev lock from spinlock to mutex Signed-off-by: Nate Case [EMAIL PROTECTED] don't see it in my queue, so please resend. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Udev coldplugging loads 8139too driver instead of 8139cp
Frederik Himpe wrote: Linux 2.6.24 kernel gives the following messages when udev coldplugging loads the driver for my NIC: 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip 8139too :00:0b.0: Use the 8139cp driver for improved performance and stability. There are 2 drivers for 8139-based NICs. For really different two kinds of hardware, which both uses the same PCI identifiers. Both drivers claims to work with all NICs with those PCI ids, because externally (by means of udev for example) it's impossible to distinguish the two kinds of hardware, it becomes clean only when the driver (either of the two) loads and actually checks which hardware we have here. Udev in fact loads both - 8139cp and 8139too. The difference is the ORDER in which it loads them - if for cp-handled hardware it first loads too, too will complain as above and will NOT claim the device. The same is true for the opposite. So - in short - things has always been this way (thanks to realtec). I've seen similar (but opposite) effects on my systems, which are all should be serviced by 8139too driver but 8139cp loaded first - up till i gave up and just disabled 8139cp... I don't know what happened in 2.6.24, but my guess is that since 8139too-based hw is now alot more common, the two drivers are listed in the opposite order. In short: NotABug, or ComplainToRealtec (but that's wy too late and will not help anyway) ;) /mjt -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2.6.24] fib: fix route replacement, fib_info is shared
Hello,
On Mon, 28 Jan 2008, Jarek Poplawski wrote:
BTW, the way add works wasn't questioned now, but it seems could be,
or man ip should call it e.g. ip route add - add new destination,
and append ip route append (unless I have old man).
add is similar to prepend, only that checks NLM_F_EXCL
to avoid many alternative routes, only one route for tos+priority is
allowed for add. As for the sorting by tos/priority and the
insertion position I remember for thread on this issue:
http://marc.info/?t=10961429062r=1w=2
+ fa = list_entry(fa-fa_list.prev, struct fib_alias, fa_list);
+ list_for_each_entry_continue(fa, f-fn_alias, fa_list) {
+ if (fa-fa_tos != tos)
+ break;
+ if (fa-fa_info-fib_priority != fi-fib_priority)
+ break;
+ if (fa-fa_type == cfg-fc_type
+ fa-fa_scope == cfg-fc_scope
+ fa-fa_info == fi) {
+ fa_match = fa;
+ break;
Why can't we try goto out from here? (less reading...)
The case with NLM_F_REPLACE needs to check more things, one
day one can combine NLM_F_APPEND+NLM_F_REPLACE to replace last
alternative route, not only the first one as currently implemented.
+ fa = fa_first;
+ if (fa_match) {
+ if (fa == fa_match)
+ err = 0;
Could you comment more why returning an error seems to depend on the
order of aliases here? But, IMHO there is no reason to change the old
behavior WRT this error, so probably this err = 0 should be always if
NLM_F_REPLACE is set.
fa_match is some existing alias that matches all new parameters.
As NLM_F_REPLACE changes the first alternative route for
tos+priority if fa_match == fa_first (we are replacing alias that
matches all parameters) we return 0, only that routing cache is not
flushed - nothing is replaced/changed. So, fa == fa_match means
replace will not change existing parameters, return 0 as this is
not an error.
PS: I think, this FIB info you sent earlier is just fine for
Documentation/networking without any changes! (Maybe one more patch?)
This is so small part of the picture, such 15-minute listing
is not enough to explain everything. May be such and other information
can be added as part of some known documentation.
Regards
--
Julian Anastasov [EMAIL PROTECTED]
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] PHYLIB: Locking fixes for PHY I/O potentially sleeping
Jeff, Dave, any chance we can get this one in for 2.6.25? It will allow a number of other drivers to start using PHY Lib. I'm sure Nate can resend if needed. On Jan 3, 2008, at 17:36, Nate Case wrote: PHY read/write functions can potentially sleep (e.g., a PHY accessed via I2C). The following changes were made to account for this: * Change spin locks to mutex locks * Add a BUG_ON() to phy_read() phy_write() to warn against calling them from an interrupt context. * Use work queue for PHY state machine handling since it can potentially sleep * Change phydev lock from spinlock to mutex Signed-off-by: Nate Case [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: appearing again: kernel: eth0: too many iterations (6) in nv_nic_irq
On Mon, Jan 28, 2008 at 11:32:55AM -0200, Carlos Carvalho wrote: It seems that this problem with NVidia's nic comes up more and more... From time to time we get this in the log: Jan 27 14:43:12 duvel kernel: eth0: too many iterations (6) in nv_nic_irq. We algo get Jan 27 11:32:43 duvel kernel: KERNEL: assertion ((int)tcp_packets_in_flight(tp) = 0) failed at net/ipv4/tcp_input.c (1274) But at different moments, as shown above. Are they related? What's the meaning of the assertion failed one? The messages are more likely to appear when traffic is high (500Mb/s). This is with 2.6.22.16. Any suggestions? I've noticed that when running the latest forcedeth on an older base kernel (2.6.18 in my case) that enable_irq and disable_irq don't quite behave the same way with using MSI as they do with INTx. 2.6.24 works great on the same hardware so something has changed between at leat 2.6.18 and now to make life better. I've been meaning to look at those calls and figure out if we can replace them with simple calls to disable the hardware IRQs only, but haven't had a chance yet. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Udev coldplugging loads 8139too driver instead of 8139cp
On Tue, 29 Jan 2008 03:46:08 +0300 Michael Tokarev [EMAIL PROTECTED] wrote: Frederik Himpe wrote: Linux 2.6.24 kernel gives the following messages when udev coldplugging loads the driver for my NIC: 8139too :00:0b.0: This (id 10ec:8139 rev 20) is an enhanced 8139C+ chip 8139too :00:0b.0: Use the 8139cp driver for improved performance and stability. There are 2 drivers for 8139-based NICs. For really different two kinds of hardware, which both uses the same PCI identifiers. Both drivers claims to work with all NICs with those PCI ids, because externally (by means of udev for example) it's impossible to distinguish the two kinds of hardware, it becomes clean only when the driver (either of the two) loads and actually checks which hardware we have here. Is there any chance of using subdevice or subversion to tell them apart? That worked for other vendors like DLINK who slapped same ID on different cards. Udev in fact loads both - 8139cp and 8139too. The difference is the ORDER in which it loads them - if for cp-handled hardware it first loads too, too will complain as above and will NOT claim the device. The same is true for the opposite. So - in short - things has always been this way (thanks to realtec). I've seen similar (but opposite) effects on my systems, which are all should be serviced by 8139too driver but 8139cp loaded first - up till i gave up and just disabled 8139cp... I don't know what happened in 2.6.24, but my guess is that since 8139too-based hw is now alot more common, the two drivers are listed in the opposite order. In short: NotABug, or ComplainToRealtec (but that's wy too late and will not help anyway) ;) /mjt -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html -- Stephen Hemminger [EMAIL PROTECTED] -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: appearing again: kernel: eth0: too many iterations (6) in nv_nic_irq
Stephen Hemminger ([EMAIL PROTECTED]) wrote on 28 January 2008 08:06: On Mon, 28 Jan 2008 11:32:55 -0200 [EMAIL PROTECTED] (Carlos Carvalho) wrote: It seems that this problem with NVidia's nic comes up more and more... From time to time we get this in the log: Jan 27 14:43:12 duvel kernel: eth0: too many iterations (6) in nv_nic_irq. We algo get Jan 27 11:32:43 duvel kernel: KERNEL: assertion ((int)tcp_packets_in_flight(tp) = 0) failed at net/ipv4/tcp_input.c (1274) But at different moments, as shown above. Are they related? What's the meaning of the assertion failed one? The messages are more likely to appear when traffic is high (500Mb/s). This is with 2.6.22.16. Any suggestions? Use NAPI which is available as configuration option in this driver. Already in use. Increase the max_interrupt_work from the ridiculously low value of 5 to something more larger like 15, with module parameter in /etc/modprobe.d/options: options forcedeth max_interrupt_work=15 Will try. Also, see if you motherboard supports MSI, if so add msi=1 module parameter It does, I have this in the config: CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y How can I set these options with the driver compiled in the kernel and not as a module? I can change the max_interrupt_work in the source but what about msi? Any ideas about the assertion ((int)tcp_packets_in_flight...? -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] SELinux: Fix double free in selinux_netlbl_sock_setsid()
As pointed out by Adrian Bunk, commit 45c950e0f839fded922ebc0bfd59b1081cc71b70 caused a double-free when security_netlbl_sid_to_secattr() fails. This patch fixes this by removing the netlbl_secattr_destroy() call from that function since we are already releasing the secattr memory in selinux_netlbl_sock_setsid(). Signed-off-by: Paul Moore [EMAIL PROTECTED] --- security/selinux/ss/services.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/security/selinux/ss/services.c b/security/selinux/ss/services.c index 4bf715d..3a16aba 100644 --- a/security/selinux/ss/services.c +++ b/security/selinux/ss/services.c @@ -2629,7 +2629,6 @@ int security_netlbl_sid_to_secattr(u32 sid, struct netlbl_lsm_secattr *secattr) netlbl_sid_to_secattr_failure: POLICY_RDUNLOCK; - netlbl_secattr_destroy(secattr); return rc; } #endif /* CONFIG_NETLABEL */ -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[0/3] [IPSEC]: Add async/aead support
Hi Dave:
I've rebased the IPsec AEAD/async patches for the current net-2.6.25
tree.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/3] [IPSEC]: Allow async algorithms
[IPSEC]: Allow async algorithms
Now that ESP uses authenc we can turn on the support for async algorithms
in IPsec.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
---
net/xfrm/xfrm_algo.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/xfrm/xfrm_algo.c b/net/xfrm/xfrm_algo.c
--- a/net/xfrm/xfrm_algo.c
+++ b/net/xfrm/xfrm_algo.c
@@ -358,21 +358,21 @@ static const struct xfrm_algo_list xfrm_
.algs = aalg_list,
.entries = ARRAY_SIZE(aalg_list),
.type = CRYPTO_ALG_TYPE_HASH,
- .mask = CRYPTO_ALG_TYPE_HASH_MASK | CRYPTO_ALG_ASYNC,
+ .mask = CRYPTO_ALG_TYPE_HASH_MASK,
};
static const struct xfrm_algo_list xfrm_ealg_list = {
.algs = ealg_list,
.entries = ARRAY_SIZE(ealg_list),
.type = CRYPTO_ALG_TYPE_BLKCIPHER,
- .mask = CRYPTO_ALG_TYPE_MASK | CRYPTO_ALG_ASYNC,
+ .mask = CRYPTO_ALG_TYPE_BLKCIPHER_MASK,
};
static const struct xfrm_algo_list xfrm_calg_list = {
.algs = calg_list,
.entries = ARRAY_SIZE(calg_list),
.type = CRYPTO_ALG_TYPE_COMPRESS,
- .mask = CRYPTO_ALG_TYPE_MASK | CRYPTO_ALG_ASYNC,
+ .mask = CRYPTO_ALG_TYPE_MASK,
};
static struct xfrm_algo_desc *xfrm_find_algo(
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [IPSEC]: Add support for combined mode algorithms
[IPSEC]: Add support for combined mode algorithms
This patch adds support for combined mode algorithms with GCM being the
first algorithm supported.
Combined mode algorithms can be added through the xfrm_user interface
using the new algorithm payload type XFRMA_ALG_AEAD. Each algorithms
is identified by its name and the ICV length.
For the purposes of matching algorithms in xfrm_tmpl structures, combined
mode algorithms are occupy the same name space as encryption algorithms.
This is in line with how they are negotiated using IKE.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
---
include/linux/pfkeyv2.h |6 ++
include/linux/xfrm.h|8 ++
include/net/xfrm.h |8 ++
net/ipv4/esp4.c | 71
net/ipv6/esp6.c | 77 +-
net/xfrm/xfrm_algo.c| 138
net/xfrm/xfrm_user.c| 71 +++-
7 files changed, 347 insertions(+), 32 deletions(-)
diff --git a/include/linux/pfkeyv2.h b/include/linux/pfkeyv2.h
--- a/include/linux/pfkeyv2.h
+++ b/include/linux/pfkeyv2.h
@@ -298,6 +298,12 @@ struct sadb_x_sec_ctx {
#define SADB_X_EALG_BLOWFISHCBC7
#define SADB_EALG_NULL 11
#define SADB_X_EALG_AESCBC 12
+#define SADB_X_EALG_AES_CCM_ICV8 14
+#define SADB_X_EALG_AES_CCM_ICV12 15
+#define SADB_X_EALG_AES_CCM_ICV16 16
+#define SADB_X_EALG_AES_GCM_ICV8 18
+#define SADB_X_EALG_AES_GCM_ICV12 19
+#define SADB_X_EALG_AES_GCM_ICV16 20
#define SADB_X_EALG_CAMELLIACBC22
#define SADB_EALG_MAX 253 /* last EALG */
/* private allocations should use 249-255 (RFC2407) */
diff --git a/include/linux/xfrm.h b/include/linux/xfrm.h
--- a/include/linux/xfrm.h
+++ b/include/linux/xfrm.h
@@ -96,6 +96,13 @@ struct xfrm_algo {
charalg_key[0];
};
+struct xfrm_algo_aead {
+ charalg_name[64];
+ int alg_key_len;/* in bits */
+ int alg_icv_len;/* in bits */
+ charalg_key[0];
+};
+
struct xfrm_stats {
__u32 replay_window;
__u32 replay;
@@ -270,6 +277,7 @@ enum xfrm_attr_type_t {
XFRMA_LASTUSED,
XFRMA_POLICY_TYPE, /* struct xfrm_userpolicy_type */
XFRMA_MIGRATE,
+ XFRMA_ALG_AEAD, /* struct xfrm_algo_aead */
__XFRMA_MAX
#define XFRMA_MAX (__XFRMA_MAX - 1)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -159,6 +159,7 @@ struct xfrm_state
struct xfrm_algo*aalg;
struct xfrm_algo*ealg;
struct xfrm_algo*calg;
+ struct xfrm_algo_aead *aead;
/* Data for encapsulator */
struct xfrm_encap_tmpl *encap;
@@ -1108,6 +1109,10 @@ static inline int xfrm_id_proto_match(u8
/*
* xfrm algorithm information
*/
+struct xfrm_algo_aead_info {
+ u16 icv_truncbits;
+};
+
struct xfrm_algo_auth_info {
u16 icv_truncbits;
u16 icv_fullbits;
@@ -1127,6 +1132,7 @@ struct xfrm_algo_desc {
char *compat;
u8 available:1;
union {
+ struct xfrm_algo_aead_info aead;
struct xfrm_algo_auth_info auth;
struct xfrm_algo_encr_info encr;
struct xfrm_algo_comp_info comp;
@@ -1343,6 +1349,8 @@ extern struct xfrm_algo_desc *xfrm_calg_
extern struct xfrm_algo_desc *xfrm_aalg_get_byname(char *name, int probe);
extern struct xfrm_algo_desc *xfrm_ealg_get_byname(char *name, int probe);
extern struct xfrm_algo_desc *xfrm_calg_get_byname(char *name, int probe);
+extern struct xfrm_algo_desc *xfrm_aead_get_byname(char *name, int icv_len,
+ int probe);
struct hash_desc;
struct scatterlist;
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -439,32 +439,53 @@ static void esp_destroy(struct xfrm_stat
kfree(esp);
}
-static int esp_init_state(struct xfrm_state *x)
+static int esp_init_aead(struct xfrm_state *x)
+{
+ struct esp_data *esp = x-data;
+ struct crypto_aead *aead;
+ int err;
+
+ aead = crypto_alloc_aead(x-aead-alg_name, 0, 0);
+ err = PTR_ERR(aead);
+ if (IS_ERR(aead))
+ goto error;
+
+ esp-aead = aead;
+
+ err = crypto_aead_setkey(aead, x-aead-alg_key,
+(x-aead-alg_key_len + 7) / 8);
+ if (err)
+ goto error;
+
+ err = crypto_aead_setauthsize(aead, x-aead-alg_icv_len / 8);
+ if (err)
+ goto error;
+
+error:
+ return err;
+}
+
+static int esp_init_authenc(struct xfrm_state *x)
{
- struct esp_data *esp = NULL;
+ struct esp_data *esp = x-data;
struct crypto_aead *aead;
struct crypto_authenc_key_param *param;
struct rtattr *rta;
char *key;
char *p;
[PATCH 1/3] [IPSEC]: Use crypto_aead and authenc in ESP
[IPSEC]: Use crypto_aead and authenc in ESP
This patch converts ESP to use the crypto_aead interface and in particular
the authenc algorithm. This lays the foundations for future support of
combined mode algorithms.
Signed-off-by: Herbert Xu [EMAIL PROTECTED]
---
include/net/esp.h | 52 -
net/ipv4/Kconfig |1
net/ipv4/esp4.c | 497 --
net/ipv6/Kconfig |1
net/ipv6/esp6.c | 460 ++---
5 files changed, 590 insertions(+), 421 deletions(-)
diff --git a/include/net/esp.h b/include/net/esp.h
--- a/include/net/esp.h
+++ b/include/net/esp.h
@@ -1,58 +1,20 @@
#ifndef _NET_ESP_H
#define _NET_ESP_H
-#include linux/crypto.h
-#include net/xfrm.h
-#include linux/scatterlist.h
+#include linux/skbuff.h
-#define ESP_NUM_FAST_SG4
+struct crypto_aead;
-struct esp_data
-{
- struct scatterlist sgbuf[ESP_NUM_FAST_SG];
+struct esp_data {
+ /* 0..255 */
+ int padlen;
- /* Confidentiality */
- struct {
- int padlen; /* 0..255 */
- /* ivlen is offset from enc_data, where encrypted data start.
-* It is logically different of crypto_tfm_alg_ivsize(tfm).
-* We assume that it is either zero (no ivec), or
-* = crypto_tfm_alg_ivsize(tfm). */
- int ivlen;
- int ivinitted;
- u8 *ivec; /* ivec buffer */
- struct crypto_blkcipher *tfm; /* crypto handle */
- } conf;
-
- /* Integrity. It is active when icv_full_len != 0 */
- struct {
- u8 *work_icv;
- int icv_full_len;
- int icv_trunc_len;
- struct crypto_hash *tfm;
- } auth;
+ /* Confidentiality Integrity */
+ struct crypto_aead *aead;
};
extern void *pskb_put(struct sk_buff *skb, struct sk_buff *tail, int len);
-static inline int esp_mac_digest(struct esp_data *esp, struct sk_buff *skb,
-int offset, int len)
-{
- struct hash_desc desc;
- int err;
-
- desc.tfm = esp-auth.tfm;
- desc.flags = 0;
-
- err = crypto_hash_init(desc);
- if (unlikely(err))
- return err;
- err = skb_icv_walk(skb, desc, offset, len, crypto_hash_update);
- if (unlikely(err))
- return err;
- return crypto_hash_final(desc, esp-auth.work_icv);
-}
-
struct ip_esp_hdr;
static inline struct ip_esp_hdr *ip_esp_hdr(const struct sk_buff *skb)
diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
--- a/net/ipv4/Kconfig
+++ b/net/ipv4/Kconfig
@@ -343,6 +343,7 @@ config INET_ESP
tristate IP: ESP transformation
select XFRM
select CRYPTO
+ select CRYPTO_AEAD
select CRYPTO_HMAC
select CRYPTO_MD5
select CRYPTO_CBC
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -1,27 +1,118 @@
+#include crypto/aead.h
+#include crypto/authenc.h
#include linux/err.h
#include linux/module.h
#include net/ip.h
#include net/xfrm.h
#include net/esp.h
#include linux/scatterlist.h
-#include linux/crypto.h
#include linux/kernel.h
#include linux/pfkeyv2.h
-#include linux/random.h
+#include linux/rtnetlink.h
+#include linux/slab.h
#include linux/spinlock.h
#include linux/in6.h
#include net/icmp.h
#include net/protocol.h
#include net/udp.h
+struct esp_skb_cb {
+ struct xfrm_skb_cb xfrm;
+ void *tmp;
+};
+
+#define ESP_SKB_CB(__skb) ((struct esp_skb_cb *)((__skb)-cb[0]))
+
+/*
+ * Allocate an AEAD request structure with extra space for SG and IV.
+ *
+ * For alignment considerations the IV is placed at the front, followed
+ * by the request and finally the SG list.
+ *
+ * TODO: Use spare space in skb for this where possible.
+ */
+static void *esp_alloc_tmp(struct crypto_aead *aead, int nfrags)
+{
+ unsigned int len;
+
+ len = crypto_aead_ivsize(aead);
+ if (len) {
+ len += crypto_aead_alignmask(aead)
+ ~(crypto_tfm_ctx_alignment() - 1);
+ len = ALIGN(len, crypto_tfm_ctx_alignment());
+ }
+
+ len += sizeof(struct aead_givcrypt_request) + crypto_aead_reqsize(aead);
+ len = ALIGN(len, __alignof__(struct scatterlist));
+
+ len += sizeof(struct scatterlist) * nfrags;
+
+ return kmalloc(len, GFP_ATOMIC);
+}
+
+static inline u8 *esp_tmp_iv(struct crypto_aead *aead, void *tmp)
+{
+ return crypto_aead_ivsize(aead) ?
+ PTR_ALIGN((u8 *)tmp, crypto_aead_alignmask(aead) + 1) : tmp;
+}
+
+static inline struct aead_givcrypt_request *esp_tmp_givreq(
+ struct crypto_aead *aead, u8 *iv)
+{
+ struct aead_givcrypt_request *req;
+
+
Re: [0/3] [IPSEC]: Add async/aead support
From: Herbert Xu [EMAIL PROTECTED] Date: Tue, 29 Jan 2008 14:10:47 +1100 Hi Dave: I've rebased the IPsec AEAD/async patches for the current net-2.6.25 tree. I've queued this up into a local tree, thanks Herbert. I'm going to keep the real net-2.6.25.git tree untouched until Linus pulls since the last thing I want to do is screw up that merge :-) -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SELinux: Fix double free in selinux_netlbl_sock_setsid()
From: Paul Moore [EMAIL PROTECTED] Date: Mon, 28 Jan 2008 21:20:26 -0500 As pointed out by Adrian Bunk, commit 45c950e0f839fded922ebc0bfd59b1081cc71b70 caused a double-free when security_netlbl_sid_to_secattr() fails. This patch fixes this by removing the netlbl_secattr_destroy() call from that function since we are already releasing the secattr memory in selinux_netlbl_sock_setsid(). Signed-off-by: Paul Moore [EMAIL PROTECTED] Applied, and I'll queue this up for -stable too. Please, when mentioning specific commits please also provide the changelog headline along with the SHA1 hash. The reason is that when this fix is moved over to another tree where the SHA1 of the causing change is different people studying your fix won't be able to find it without more stable contextual information. Thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [NET] 9p: kill dead static inline buf_put_string
From: Eric Van Hensbergen [EMAIL PROTECTED] Date: Mon, 28 Jan 2008 15:42:44 -0600 On Jan 25, 2008 4:46 PM, Ilpo Järvinen [EMAIL PROTECTED] wrote: From: =?ISO-8859-1?q?Ilpo=20J=E4rvinen?= [EMAIL PROTECTED] Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] Acked-by: Eric Van Hensbergen [EMAIL PROTECTED] Applied, thanks. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [AX25]: Beautify x25_init() version printk.
From: maximilian attems [EMAIL PROTECTED] Date: Mon, 28 Jan 2008 18:31:10 +0100 kill ref to old version and dup Linux. Signed-off-by: maximilian attems [EMAIL PROTECTED] Applied -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [AX25]: Kill ax25_bind() user triggable printk.
From: maximilian attems [EMAIL PROTECTED] Date: Mon, 28 Jan 2008 18:31:09 +0100 on the last run overlooked that sfuzz triggable message. move the message to the corresponding comment. Signed-off-by: maximilian attems [EMAIL PROTECTED] Applied. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [INET]: Prevent out-of-sync truesize on ip_fragment slow path
From: Herbert Xu [EMAIL PROTECTED] Date: Mon, 28 Jan 2008 22:12:59 +1100 Hi: [INET]: Prevent out-of-sync truesize on ip_fragment slow path When ip_fragment has to hit the slow path the value of skb-truesize may go out of sync because we would have updated it without changing the packet length. This violates the constraints on truesize. This patch postpones the update of skb-truesize to prevent this. Signed-off-by: Herbert Xu [EMAIL PROTECTED] Applied, I'll queue this up for 2.6.24-stable too. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][INET_DIAG]: Fix inet_diag_lock_handler error path
From: Herbert Xu [EMAIL PROTECTED] Date: Mon, 28 Jan 2008 22:03:10 +1100 On Mon, Jan 28, 2008 at 12:20:50AM -0200, Arnaldo Carvalho de Melo wrote: Fixes: http://bugzilla.kernel.org/show_bug.cgi?id=9825 The inet_diag_lock_handler function uses ERR_PTR to encode errors but its callers were testing against NULL. Thanks for catching this Arnaldo! Applied and queued up for 2.6.24-stable, thanks! -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2.6.24] fib: fix route replacement, fib_info is shared
From: Julian Anastasov [EMAIL PROTECTED] Date: Sat, 26 Jan 2008 14:41:32 +0200 (EET) fib_info can be shared by many route prefixes but we don't want duplicate alternative routes for a prefix+tos+priority. Last change was not correct to check fib_treeref because it accounts usage from other prefixes. Additionally, avoid replacement without error if new route is same, as Joonwoo Park suggests. Signed-off-by: Julian Anastasov [EMAIL PROTECTED] Applied, thank you. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Feel more pleasure in love!
Join the world of boundless enjoyments! http://uiwm.measureremember.com -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 2.6.24] fib_trie: apply fixes from fib_hash
From: Julian Anastasov [EMAIL PROTECTED] Date: Sat, 26 Jan 2008 14:44:36 +0200 (EET) Update fib_trie with some fib_hash fixes: - check for duplicate alternative routes for prefix+tos+priority when replacing route - properly insert by matching tos together with priority - fix alias walking to use list_for_each_entry_continue for insertion and deletion when fa_head is not NULL - copy state from fa to new_fa on replace (not a problem for now) - additionally, avoid replacement without error if new route is same, as Joonwoo Park suggests. Signed-off-by: Julian Anastasov [EMAIL PROTECTED] Also applied, thanks a lot. -- To unsubscribe from this list: send the line unsubscribe netdev in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH net-2.6.25 4/7][ATM]: [br2864] routed support
On Jan 26, 2008 8:20 PM, chas williams - CONTRACTOR
[EMAIL PROTECTED] wrote:
In message [EMAIL PROTECTED],Chung-
Chi Lo writes:
By the way, this routed mode patch doesn't include encaps=VCMUX and
RFC2684 routed
protocol decapsulation?
yep. eric believes the following should fix both problems:
commit 43e4b025ffe130cd6a292fa9ff909e39a88f849c
Author: Chas Williams - CONTRACTOR [EMAIL PROTECTED]
Date: Sat Jan 26 07:18:26 2008 -0500
[ATM]: [br2864] fix vcmux support
From: Eric Kinzie [EMAIL PROTECTED]
Signed-off-by: Chas Williams [EMAIL PROTECTED]
diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 31347cb..97b422c 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -400,15 +400,20 @@ static void br2684_push(struct atm_vcc *atmvcc, struct
sk_buff *skb)
return;
}
- } else {
- /* first 2 chars should be 0 */
- if (*((u16 *) (skb-data)) != 0) {
- brdev-stats.rx_errors++;
- dev_kfree_skb(skb);
- return;
+ } else { /* vc-mux */
+ if (brdev-payload == p_routed) {
add line
skb-protocol = __constant_htons(ETH_P_IP);
here just like LLC did?
+ skb_reset_network_header(skb);
+ skb-pkt_type = PACKET_HOST;
+ } else { /* p_bridged */
+ /* first 2 chars should be 0 */
+ if (*((u16 *) (skb-data)) != 0) {
+ brdev-stats.rx_errors++;
+ dev_kfree_skb(skb);
+ return;
+ }
+ skb_pull(skb, BR2684_PAD_LEN);
+ skb-protocol = eth_type_trans(skb, net_dev);
}
- skb_pull(skb, BR2684_PAD_LEN + ETH_HLEN); /* pad,
dstmac, srcmac, ethtype */
- skb-protocol = eth_type_trans(skb, net_dev);
}
Also have a problem when encapsulation is VCMUX and routed mode, in
/*
@@ -136,6 +156,7 @@ static int br2684_xmit_vcc(struct sk_buff *skb,
struct br2684_dev *brdev,
{
..
..
+ if (brvcc-encaps == e_llc) {
..
+ } else {
+ skb_push(skb, 2);
+ if (brdev-payload == p_bridged)
+ memset(skb-data, 0, 2);
+ }
Here should be
} else {
if (brdev-payload == p_bridged) {
skb_push(skb, 2);
memset(skb-data, 0, 2);
}
}
Because VCMUX and routed mode doesn't need two bytes in header.
--
Lino, Chung-Chi Lo
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
