* Re: [patch 0/1][RFC] add a private field to the sock structure
From: Arnaldo Carvalho de Melo @ 2007-08-31 11:26 UTC (permalink / raw)
To: David Miller; +Cc: dlezcano, netdev, ralf
In-Reply-To: <20070830.224049.35665219.davem@davemloft.net>
Em Thu, Aug 30, 2007 at 10:40:49PM -0700, David Miller escreveu:
> From: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> Date: Wed, 29 Aug 2007 16:18:31 -0300
>
> > Nah, it still there, sk_protinfo, its just ax25 that uses it
> > (nudge(Ralf)). How do we state that a struct field is deprecated and
> > will be removed soon(tm)?
>
> You get rid of all the in-tree users and then just kill it :)
>
> More seriously, I don't think we need a deprecation schedule
> for a struct member, either it's not used in-tree anymore or
> it isn't. We'll go crazy with any other policy and it's
> difficult enough shrinking these things :-)
OK, I think its enough to say to dlezcano that he should avoid using
sk_protinfo, as soon as we do the work on AX.25 sk_protinfo will be
removed.
- Arnaldo
^ permalink raw reply
* Re: [Bugme-new] [Bug 8961] New: BUG triggered by oidentd in netlink code
From: Patrick McHardy @ 2007-08-31 11:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: netdev, bugme-daemon, link
In-Reply-To: <20070830180842.7c8414fe.akpm@linux-foundation.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1506 bytes --]
On Thu, 30 Aug 2007, Andrew Morton wrote:
> On Thu, 30 Aug 2007 07:41:31 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=8961
>
> This looks serious.
>
>> Summary: BUG triggered by oidentd in netlink code
>>
>> Aug 29 23:28:44 bowl kernel: [349587.500440] BUG: unable to handle kernel NULL
>> pointer dereference<1>BUG: unable to handle kernel NULL pointer dereference at
>> virtual address 00000054
>> Aug 29 23:28:44 bowl kernel: [349587.500454] printing eip:
>> Aug 29 23:28:45 bowl kernel: [349587.500457] c03318ae
>> Aug 29 23:28:45 bowl kernel: [349587.500459] *pde = 00000000
>> Aug 29 23:28:45 bowl kernel: [349587.500464] Oops: 0000 [#1]
>> Aug 29 23:28:45 bowl kernel: [349587.500466] PREEMPT SMP
>> Aug 29 23:28:46 bowl kernel: [349587.500474] Modules linked in: w83627hf
>> hwmon_vid i2c_isa
>> Aug 29 23:28:46 bowl kernel: [349587.500483] CPU: 0
>> Aug 29 23:28:47 bowl kernel: [349587.500485] EIP: 0060:[<c03318ae>] Not
>> tainted VLI
>> Aug 29 23:28:47 bowl kernel: [349587.500487] EFLAGS: 00010246 (2.6.22.3 #1)
>> Aug 29 23:28:47 bowl kernel: [349587.500499] EIP is at netlink_rcv_skb+0xa/0x7e
>> Aug 29 23:28:48 bowl kernel: [349587.500506] eax: 00000000 ebx: 00000000
Seems to be a bug introduced by the netlink_run_queue conversion,
since there is no locking and netlink_run_queue doesn't check
for NULL results from skb_dequeue, it might pass NULL to
netlink_rcv_skb, which crashes.
Does this patch help?
[-- Attachment #2: Type: TEXT/PLAIN, Size: 597 bytes --]
diff --git a/net/ipv4/inet_diag.c b/net/ipv4/inet_diag.c
index dbeacd8..8e1078d 100644
--- a/net/ipv4/inet_diag.c
+++ b/net/ipv4/inet_diag.c
@@ -836,12 +836,17 @@ static int inet_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh)
return inet_diag_get_exact(skb, nlh);
}
+static DEFINE_MUTEX(inet_diag_mutex);
+
static void inet_diag_rcv(struct sock *sk, int len)
{
unsigned int qlen = 0;
do {
+ if (!mutex_trylock(&inet_diag_mutex))
+ return;
netlink_run_queue(sk, &qlen, &inet_diag_rcv_msg);
+ mutex_unlock(&inet_diag_mutex);
} while (qlen);
}
^ permalink raw reply related
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-08-31 10:59 UTC (permalink / raw)
To: Jarek Poplawski, netdev
In-Reply-To: <46D7F273.5010401@bigtelecom.ru>
May be this bug eq "[PATCH] [NET_SCHED] sch_prio.c: remove duplicate
call of tc_classify()"?
> I get kernel panic on 2.6.23-rc4-git2
> This is netconsole log!
...
^ permalink raw reply
* Re: [PATCH 1/2] PS3: improve tx throughput for gelic driver
From: Jeff Garzik @ 2007-08-31 10:57 UTC (permalink / raw)
To: Masakazu Mokuno
Cc: Linas Vepstas, netdev, cbe-oss-dev, geoffrey.levand,
Geert Uytterhoeven
In-Reply-To: <20070829143537.C2D2.MOKUNO@sm.sony.co.jp>
Masakazu Mokuno wrote:
> Improve tx throughputs.
> netperf score gained approximately 20%
This is a useless patch description. It does not adequately summarize
the changes contained within the patch.
Please resubmit patch with a useful patch description
^ permalink raw reply
* Re: [patch 1/7] s390: ungrouping a device must not be interruptible
From: Jeff Garzik @ 2007-08-31 10:55 UTC (permalink / raw)
To: Ursula Braun; +Cc: netdev, linux-s390, frank.blaschka
In-Reply-To: <20070829101843.286542000@linux.vnet.ibm.com>
Applied patches 1-7, after changing the prefix back to "qeth: "
"s390: " prefix should be applied to changes that affect S/390
architecture platform in general.
This was a patchset specific to a single driver, thus the "qeth: "
prefix is more informative when looking at a long list of one-line
change summaries.
^ permalink raw reply
* Re: [PATCH 1/3] netxen: Avoid firmware load in PCI probe
From: Jeff Garzik @ 2007-08-31 10:53 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, rob
In-Reply-To: <20070828115603.166212155@netxen.com>
applied patches 1-2
^ permalink raw reply
* Re: [PATCH] PS3: fix the bug that 'ifconfig down' would hang
From: Jeff Garzik @ 2007-08-31 10:53 UTC (permalink / raw)
To: Masakazu Mokuno
Cc: netdev, Michael Lothian, Stefan Assmann, geoffrey.levand,
Geert Uytterhoeven, cbe-oss-dev, ppc, Linas Vepstas
In-Reply-To: <20070828125924.C2B1.MOKUNO@sm.sony.co.jp>
Masakazu Mokuno wrote:
> Fix the bug that 'ifconfig eth0 down' would hang up, reported by Stefan
> Assmann <sassmann@suse.de>.
> As we removed netif_poll_enable() from dev->open(), we should not use
> netif_poll_disable() in dev->stop().
>
> Signed-off-by: Masakazu Mokuno <mokuno@sm.sony.co.jp>
> CC: Geoff Levand <geoffrey.levand@am.sony.com>
> ---
> drivers/net/ps3_gelic_net.c | 1 -
> 1 file changed, 1 deletion(-)
applied
^ permalink raw reply
* Re: [PATCH 3/3] netxen: ethtool fixes
From: Jeff Garzik @ 2007-08-31 10:51 UTC (permalink / raw)
To: dhananjay; +Cc: netdev, rob
In-Reply-To: <20070828115603.981381010@netxen.com>
dhananjay@netxen.com wrote:
> +static int netxen_nic_set_rx_csum(struct net_device *dev, u32 data)
> +{
> + struct netxen_adapter *adapter = netdev_priv(dev);
> + adapter->rx_csum = 0;
> + return 0;
> +}
Bug: 'data' ignored
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-08-31 10:50 UTC (permalink / raw)
To: Jarek Poplawski, netdev
In-Reply-To: <20070831101733.GA3108@ff.dom.local>
I get kernel panic on 2.6.23-rc4-git2
This is netconsole log!
[ 3931.002707] BUG: unable to handle kernel NULL pointer dereference at
virtual address 00000008
[ 3931.002846] printing eip:
[ 3931.002906] c01c8973
[ 3931.002967] *pde = 00000000
[ 3931.003031] Oops: 0000 [#1]
[ 3931.003093] SMP
[ 3931.003160] Modules linked in: cls_u32 sch_sfq sch_htb netconsole
xt_tcpudp iptable_filter ip_tables x_tables i2c_i801 i2c_core
[ 3931.003327] CPU: 2
[ 3931.003327] EIP: 0060:[<c01c8973>] Not tainted VLI
[ 3931.003328] EFLAGS: 00010246 (2.6.23-rc4-testing #1)
[ 3931.003526] EIP is at rb_insert_color+0x13/0xad
[ 3931.003594] eax: 00000000 ebx: e9570324 ecx: e9570324 edx: f6deac48
[ 3931.003663] esi: 00000000 edi: ef5c4124 ebp: f6dea8a0 esp: e25f5d6c
[ 3931.003731] ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
[ 3931.003796] Process sh (pid: 6146, ti=e25f4000 task=c268b290
task.ti=e25f4000)
[ 3931.003866] Stack: f6deac48 00000569 00000000 ef5c4000 f6dea8a0
f8862a9d f881c5db e1fda780
[ 3931.004016] 00000003 f6db6dc0 f6deac48 f6dea800 00000000
00000000 dfc3e9b2 00000000
[ 3931.004161] e25f5dd8 00000000 c02a774b 00000002 e25f5e70
f6dea930 f6dea930 00000000
[ 3931.004307] Call Trace:
[ 3931.004434] [<f8862a9d>] htb_dequeue+0x195/0x6d2 [sch_htb]
[ 3931.004510] [<f881c5db>] ipt_do_table+0x41f/0x47c [ip_tables]
[ 3931.004584] [<c02a774b>] tc_classify+0x17/0x7c
[ 3931.004658] [<f8861925>] htb_activate_prios+0x9b/0xa5 [sch_htb]
[ 3931.004730] [<c02a71af>] __qdisc_run+0x2a/0x16b
[ 3931.004798] [<c029cfc1>] dev_queue_xmit+0x18b/0x2a6
[ 3931.004874] [<c02b94e3>] ip_output+0x281/0x2ba
[ 3931.004947] [<c02b571c>] ip_forward_finish+0x0/0x2e
[ 3931.005012] [<c02b59b5>] ip_forward+0x26b/0x2c6
[ 3931.005081] [<c02b571c>] ip_forward_finish+0x0/0x2e
[ 3931.005150] [<c02b4729>] ip_rcv+0x484/0x4bd
[ 3931.005216] [<c013dcc5>] file_read_actor+0x0/0xdb
[ 3931.005293] [<c029ab9c>] netif_receive_skb+0x2cd/0x340
[ 3931.005362] [<c0234ef1>] e1000_clean_rx_irq+0x379/0x448
[ 3931.005437] [<c0234b78>] e1000_clean_rx_irq+0x0/0x448
[ 3931.005506] [<c0233f8f>] e1000_clean+0x7a/0x249
[ 3931.005574] [<c029ccad>] net_rx_action+0x91/0x17f
[ 3931.005642] [<c01225e2>] __do_softirq+0x5d/0xc1
[ 3931.005714] [<c0122678>] do_softirq+0x32/0x36
[ 3931.005779] [<c010488a>] do_IRQ+0x7e/0x90
[ 3931.005849] [<c01032eb>] common_interrupt+0x23/0x28
[ 3931.005923] =======================
[ 3931.005986] Code: 56 04 eb 07 89 56 08 eb 02 89 17 8b 03 83 e0 03 09
d0 89 03 5b 5e 5f c3 55 57 89 c7 56 53 83 ec 04 89 14 24 eb 7e 89 c6 83
e6 fc <8b> 56 08 39 d3 75 34 8b 56 04 85 d2 74 06 8b 02 a8 01 74 31 8b
[ 3931.006386] EIP: [<c01c8973>] rb_insert_color+0x13/0xad SS:ESP
0068:e25f5d6c
[ 3931.006757] Kernel panic - not syncing: Fatal exception in interrupt
[ 3931.006863] Rebooting in 3 seconds..
> BTW, -git versions are usually more risky than -rc. And, maybe, let
> this 2.6.18 better stay away from this testing...
>
> Thanks,
> Jarek P.
>
>
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-08-31 10:48 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20070831101733.GA3108@ff.dom.local>
> But sometime a new kernel can break binary compatibility with previous
> one (e.g. after data structures change) and e.g. iptables or iproute
> tools stop working or work in an unpredictable way. There were a few
> such changes before 2.6.20 - I don't track current changes too much.
> And I'm sure your system uses much more than iptables or TC, even
> without your knowledge.
>
I can rollback =) Backup system get all functions. I can risk for one
system of two for get and fix all bugs.
Dynamic routing work fine and automatic switch between systems = 1-4
seconds.
>> I send to you all info that catch NETCONSOLE. i don't cut any info...
>>
>
> So, it seems something was broken. But, I meant, there can be sometimes
> interesting things a few lines before or after the infos too.
>
I can only see that say netconsole. If i look to monitor i look last
lines. last line is "====...". Scrolling not work
netconsole run as module and start after system do full load. Then
netconsole is up - i run generator of tc scripts.
> BTW, -git versions are usually more risky than -rc. And, maybe, let
> this 2.6.18 better stay away from this testing...
>
I look changes between 2.6.23-rc4 and 2.6.23-rc4-git2 and think that
paches look good and no do any critical things =)
Now i do many script runs to simulate bug. if i get it on 2.6.23-rc4 - i
post it here. 2.6.23-rc4 not have htb_timer function.
Badalian Vyacheslav
^ permalink raw reply
* Re: [PATCH] spidernet: fix interrupt reason recognition
From: Jeff Garzik @ 2007-08-31 10:46 UTC (permalink / raw)
To: Ishizaki Kou; +Cc: linas, netdev, cbe-oss-dev
In-Reply-To: <20070820.221327.-1300518791.kouish@swc.toshiba.co.jp>
Ishizaki Kou wrote:
> This patch solves a problem that the spidernet driver sometimes fails
> to handle IRQ.
>
> The problem happens because,
> - In Cell architecture, interrupts may arrive at an interrupt
> controller, even if they are masked by the setting on registers of
> devices. It happens when interrupt packets are sent just before
> the interrupts are masked.
> - spidernet interrupt handler compares interrupt reasons with
> interrupt masks, so when such interrupts occurs, spidernet interrupt
> handler returns IRQ_NONE.
> - When all of interrupt handler return IRQ_NONE, linux kernel disables
> the IRQ and it no longer delivers interrupts to the interrupt handlers.
>
> spidernet doesn't work after above sequence, because it can't receive
> interrupts.
>
> This patch changes spidernet interrupt handler that it compares
> interrupt reason with SPIDER_NET_INTX_MASK_VALUE.
>
> Signed-off-by: Kou Ishizaki <kou.ishizaki@toshiba.co.jp>
> ---
>
> Linas-san,
>
> Please apply this to 2.6.23. Because this problem is sometimes happens
> and we cannot use the ethernet port any more.
>
> And also, please apply the following Arnd-san's patch to fix a problem
> that spidernet driver sometimes causes a BUG_ON at open.
Linas? ACK? Alive? :)
Jeff
^ permalink raw reply
* Re: [Lksctp-developers] SCTP: Fix dead loop while received unexpected chunk with length set to zero
From: Wei Yongjun @ 2007-08-31 10:21 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: lksctp-developers, netdev
In-Reply-To: <46D6C9F2.5020702@hp.com>
Vlad Yasevich wrote:
> Wei Yongjun wrote:
>
>> Vlad Yasevich wrote:
>>
>>> Wei Yongjun wrote:
>>>
>>>
>>>> Vlad Yasevich wrote:
>>>>
>>>>
>>>>> NACK
>>>>>
>>>>> Section 8.4:
>>>>>
>>>>> An SCTP packet is called an "out of the blue" (OOTB) packet if it is
>>>>> correctly formed (i.e., passed the receiver's CRC32c check; see
>>>>> Section 6.8), but the receiver is not able to identify the
>>>>> association to which this packet belongs.
>>>>>
>>>>>
>>>>> I would argue that the packet is not correctly formed in this case
>>>>> and deserves a protocol violation ABORT in return.
>>>>>
>>>>> -vlad
>>>>>
>>>>>
>>>> As your comment, patch has been changed.
>>>> Patch has been split to two, one is resolve this dead loop problem in
>>>> this mail.
>>>> And the other is come in another mail to discard partial chunk which
>>>> chunk length is set to zero.
>>>>
>>>>
>>> I am starting to question the entire OOTB packet handling. There are way
>>> too many function that do almost the same thing and all handle OOTB a
>>> little
>>> different.
>>>
>>> sctp_sf_do_9_2_reshutack() is also called during sctp_sf_do_dupcook_a()
>>> processing, so checking for INIT chunk is wrong. Checking for just the
>>> chunkhdr_t should be enough.
>>>
>>>
>> This has been changed.
>>
>>> sctp_sf_tabort_8_4_8 is used directly as well (not just through the state
>>> machine). Not sure if the header verification is appropriate.
>>>
>>>
>> It is needed. Because sctp_sf_tabort_8_4_8() is called to handle OOTB
>> packet before check the header length.
>>
>
> But now we are doing the same thing twice (and this is not the only place).
> I know I am being really picky here, but I am starting to thing the ootb handling\
> is a mess and I really don't want to add to the mess.
>
> Until I (or someone else) prove that it's not a mess or fix it, I am going
> to hold off on these patches.
>
> Feel free to go through the spec and fix all the OOTB handling.
>
> Thanks
> -vlad
>
Packet changed:
1. Used sctp_sf_ootb() to handle OOTB packet
2. Remove length check from sctp_sf_tabort_8_4_8() in last patch
3. Add length check to sctp_sf_ootb()
4. Changed validity check order in sctp_sf_do_5_1B_init() and other functions to fix possible attack.
This patch may be correct.
Signed-off-by: Wei Yongjun <yjwei@cn.fujitsu.com>
diff -Nurp a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
--- a/net/sctp/sm_statefuns.c 2007-08-17 06:17:14.000000000 -0400
+++ b/net/sctp/sm_statefuns.c 2007-08-19 07:52:17.000000000 -0400
@@ -98,6 +98,7 @@ static sctp_disposition_t sctp_stop_t1_a
struct sctp_transport *transport);
static sctp_disposition_t sctp_sf_abort_violation(
+ const struct sctp_endpoint *ep,
const struct sctp_association *asoc,
void *arg,
sctp_cmd_seq_t *commands,
@@ -181,6 +182,14 @@ sctp_disposition_t sctp_sf_do_4_C(const
struct sctp_chunk *chunk = arg;
struct sctp_ulpevent *ev;
+ if (!sctp_vtag_verify_either(chunk, asoc))
+ return sctp_sf_pdiscard(ep, asoc, type, arg, commands);
+
+ /* Make sure that the SHUTDOWN_COMPLETE chunk has a valid length. */
+ if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
+ return sctp_sf_violation_chunklen(ep, asoc, type, arg,
+ commands);
+
/* RFC 2960 6.10 Bundling
*
* An endpoint MUST NOT bundle INIT, INIT ACK or
@@ -189,9 +198,6 @@ sctp_disposition_t sctp_sf_do_4_C(const
if (!chunk->singleton)
return SCTP_DISPOSITION_VIOLATION;
- if (!sctp_vtag_verify_either(chunk, asoc))
- return sctp_sf_pdiscard(ep, asoc, type, arg, commands);
-
/* RFC 2960 10.2 SCTP-to-ULP
*
* H) SHUTDOWN COMPLETE notification
@@ -267,6 +273,20 @@ sctp_disposition_t sctp_sf_do_5_1B_init(
struct sock *sk;
int len;
+ /* Make sure that the INIT chunk has a valid length.
+ * Normally, this would cause an ABORT with a Protocol Violation
+ * error, but since we don't have an association, we'll
+ * just discard the packet.
+ */
+ if (!sctp_chunk_length_valid(chunk, sizeof(sctp_init_chunk_t)))
+ return sctp_sf_pdiscard(ep, asoc, type, arg, commands);
+
+ /* 3.1 A packet containing an INIT chunk MUST have a zero Verification
+ * Tag.
+ */
+ if (chunk->sctp_hdr->vtag != 0)
+ return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands);
+
/* 6.10 Bundling
* An endpoint MUST NOT bundle INIT, INIT ACK or
* SHUTDOWN COMPLETE with any other chunks.
@@ -295,20 +315,6 @@ sctp_disposition_t sctp_sf_do_5_1B_init(
sk_acceptq_is_full(sk)))
return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands);
- /* 3.1 A packet containing an INIT chunk MUST have a zero Verification
- * Tag.
- */
- if (chunk->sctp_hdr->vtag != 0)
- return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands);
-
- /* Make sure that the INIT chunk has a valid length.
- * Normally, this would cause an ABORT with a Protocol Violation
- * error, but since we don't have an association, we'll
- * just discard the packet.
- */
- if (!sctp_chunk_length_valid(chunk, sizeof(sctp_init_chunk_t)))
- return sctp_sf_pdiscard(ep, asoc, type, arg, commands);
-
/* Verify the INIT chunk before processing it. */
err_chunk = NULL;
if (!sctp_verify_init(asoc, chunk->chunk_hdr->type,
@@ -591,12 +597,6 @@ sctp_disposition_t sctp_sf_do_5_1D_ce(co
int error = 0;
struct sctp_chunk *err_chk_p;
- /* If the packet is an OOTB packet which is temporarily on the
- * control endpoint, respond with an ABORT.
- */
- if (ep == sctp_sk((sctp_get_ctl_sock()))->ep)
- return sctp_sf_ootb(ep, asoc, type, arg, commands);
-
/* Make sure that the COOKIE_ECHO chunk has a valid length.
* In this case, we check that we have enough for at least a
* chunk header. More detailed verification is done
@@ -605,6 +605,12 @@ sctp_disposition_t sctp_sf_do_5_1D_ce(co
if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
return sctp_sf_pdiscard(ep, asoc, type, arg, commands);
+ /* If the packet is an OOTB packet which is temporarily on the
+ * control endpoint, respond with an ABORT.
+ */
+ if (ep == sctp_sk((sctp_get_ctl_sock()))->ep)
+ return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands);
+
/* "Decode" the chunk. We have no optional parameters so we
* are in good shape.
*/
@@ -1281,6 +1287,20 @@ static sctp_disposition_t sctp_sf_do_une
sctp_unrecognized_param_t *unk_param;
int len;
+ /* Make sure that the INIT chunk has a valid length.
+ * In this case, we generate a protocol violation since we have
+ * an association established.
+ */
+ if (!sctp_chunk_length_valid(chunk, sizeof(sctp_init_chunk_t)))
+ return sctp_sf_violation_chunklen(ep, asoc, type, arg,
+ commands);
+
+ /* 3.1 A packet containing an INIT chunk MUST have a zero Verification
+ * Tag.
+ */
+ if (chunk->sctp_hdr->vtag != 0)
+ return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands);
+
/* 6.10 Bundling
* An endpoint MUST NOT bundle INIT, INIT ACK or
* SHUTDOWN COMPLETE with any other chunks.
@@ -1293,19 +1313,6 @@ static sctp_disposition_t sctp_sf_do_une
if (!chunk->singleton)
return sctp_sf_pdiscard(ep, asoc, type, arg, commands);
- /* 3.1 A packet containing an INIT chunk MUST have a zero Verification
- * Tag.
- */
- if (chunk->sctp_hdr->vtag != 0)
- return sctp_sf_tabort_8_4_8(ep, asoc, type, arg, commands);
-
- /* Make sure that the INIT chunk has a valid length.
- * In this case, we generate a protocol violation since we have
- * an association established.
- */
- if (!sctp_chunk_length_valid(chunk, sizeof(sctp_init_chunk_t)))
- return sctp_sf_violation_chunklen(ep, asoc, type, arg,
- commands);
/* Grab the INIT header. */
chunk->subh.init_hdr = (sctp_inithdr_t *) chunk->skb->data;
@@ -2495,6 +2502,11 @@ sctp_disposition_t sctp_sf_do_9_2_reshut
struct sctp_chunk *chunk = (struct sctp_chunk *) arg;
struct sctp_chunk *reply;
+ /* Make sure that the chunk has a valid length */
+ if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
+ return sctp_sf_violation_chunklen(ep, asoc, type, arg,
+ commands);
+
/* Since we are not going to really process this INIT, there
* is no point in verifying chunk boundries. Just generate
* the SHUTDOWN ACK.
@@ -3146,6 +3158,11 @@ sctp_disposition_t sctp_sf_ootb(const st
ch = (sctp_chunkhdr_t *) ch_end;
} while (ch_end < skb_tail_pointer(skb));
+ /* Make sure that the chunk has a valid length. */
+ if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
+ return sctp_sf_violation_chunklen(ep, asoc, type, arg,
+ commands);
+
if (ootb_shut_ack)
sctp_sf_shut_8_4_5(ep, asoc, type, arg, commands);
else
@@ -3240,6 +3257,13 @@ sctp_disposition_t sctp_sf_do_8_5_1_E_sa
void *arg,
sctp_cmd_seq_t *commands)
{
+ struct sctp_chunk *chunk = arg;
+
+ /* Make sure that the SHUTDOWN_ACK chunk has a valid length. */
+ if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
+ return sctp_sf_violation_chunklen(ep, asoc, type, arg,
+ commands);
+
/* Although we do have an association in this case, it corresponds
* to a restarted association. So the packet is treated as an OOTB
* packet and the state function that handles OOTB SHUTDOWN_ACK is
@@ -3654,6 +3678,16 @@ sctp_disposition_t sctp_sf_discard_chunk
void *arg,
sctp_cmd_seq_t *commands)
{
+ struct sctp_chunk *chunk = arg;
+
+ /* Make sure that the chunk has a valid length.
+ * Since we don't know the chunk type, we use a general
+ * chunkhdr structure to make a comparison.
+ */
+ if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
+ return sctp_sf_violation_chunklen(ep, asoc, type, arg,
+ commands);
+
SCTP_DEBUG_PRINTK("Chunk %d is discarded\n", type.chunk);
return SCTP_DISPOSITION_DISCARD;
}
@@ -3709,6 +3743,13 @@ sctp_disposition_t sctp_sf_violation(con
void *arg,
sctp_cmd_seq_t *commands)
{
+ struct sctp_chunk *chunk = arg;
+
+ /* Make sure that the chunk has a valid length. */
+ if (!sctp_chunk_length_valid(chunk, sizeof(sctp_chunkhdr_t)))
+ return sctp_sf_violation_chunklen(ep, asoc, type, arg,
+ commands);
+
return SCTP_DISPOSITION_VIOLATION;
}
@@ -3716,12 +3757,14 @@ sctp_disposition_t sctp_sf_violation(con
* Common function to handle a protocol violation.
*/
static sctp_disposition_t sctp_sf_abort_violation(
+ const struct sctp_endpoint *ep,
const struct sctp_association *asoc,
void *arg,
sctp_cmd_seq_t *commands,
const __u8 *payload,
const size_t paylen)
{
+ struct sctp_packet *packet = NULL;
struct sctp_chunk *chunk = arg;
struct sctp_chunk *abort = NULL;
@@ -3730,22 +3773,41 @@ static sctp_disposition_t sctp_sf_abort_
if (!abort)
goto nomem;
- sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
- SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
+ if (asoc) {
+ sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(abort));
+ SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
- if (asoc->state <= SCTP_STATE_COOKIE_ECHOED) {
- sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP,
- SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT));
- sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
- SCTP_ERROR(ECONNREFUSED));
- sctp_add_cmd_sf(commands, SCTP_CMD_INIT_FAILED,
- SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
+ if (asoc->state <= SCTP_STATE_COOKIE_ECHOED) {
+ sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_STOP,
+ SCTP_TO(SCTP_EVENT_TIMEOUT_T1_INIT));
+ sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
+ SCTP_ERROR(ECONNREFUSED));
+ sctp_add_cmd_sf(commands, SCTP_CMD_INIT_FAILED,
+ SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
+ } else {
+ sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
+ SCTP_ERROR(ECONNABORTED));
+ sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
+ SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
+ SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
+ }
} else {
- sctp_add_cmd_sf(commands, SCTP_CMD_SET_SK_ERR,
- SCTP_ERROR(ECONNABORTED));
- sctp_add_cmd_sf(commands, SCTP_CMD_ASSOC_FAILED,
- SCTP_PERR(SCTP_ERROR_PROTO_VIOLATION));
- SCTP_DEC_STATS(SCTP_MIB_CURRESTAB);
+ packet = sctp_ootb_pkt_new(asoc, chunk);
+
+ if (!packet)
+ goto nomem;
+
+ if (sctp_test_T_bit(abort))
+ packet->vtag = ntohl(chunk->sctp_hdr->vtag);
+
+ abort->skb->sk = ep->base.sk;
+
+ sctp_packet_append_chunk(packet, abort);
+
+ sctp_add_cmd_sf(commands, SCTP_CMD_SEND_PKT,
+ SCTP_PACKET(packet));
+
+ SCTP_INC_STATS(SCTP_MIB_OUTCTRLCHUNKS);
}
sctp_add_cmd_sf(commands, SCTP_CMD_DISCARD_PACKET, SCTP_NULL());
@@ -3786,7 +3848,7 @@ static sctp_disposition_t sctp_sf_violat
{
char err_str[]="The following chunk had invalid length:";
- return sctp_sf_abort_violation(asoc, arg, commands, err_str,
+ return sctp_sf_abort_violation(ep, asoc, arg, commands, err_str,
sizeof(err_str));
}
@@ -3805,7 +3867,7 @@ static sctp_disposition_t sctp_sf_violat
{
char err_str[]="The cumulative tsn ack beyond the max tsn currently sent:";
- return sctp_sf_abort_violation(asoc, arg, commands, err_str,
+ return sctp_sf_abort_violation(ep, asoc, arg, commands, err_str,
sizeof(err_str));
}
diff -Nurp a/net/sctp/sm_statetable.c b/net/sctp/sm_statetable.c
--- a/net/sctp/sm_statetable.c 2007-08-09 11:58:11.000000000 -0400
+++ b/net/sctp/sm_statetable.c 2007-08-19 05:44:29.000000000 -0400
@@ -110,7 +110,7 @@ const sctp_sm_table_entry_t *sctp_sm_loo
/* SCTP_STATE_EMPTY */ \
TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_CLOSED */ \
- TYPE_SCTP_FUNC(sctp_sf_tabort_8_4_8), \
+ TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_COOKIE_WAIT */ \
TYPE_SCTP_FUNC(sctp_sf_discard_chunk), \
/* SCTP_STATE_COOKIE_ECHOED */ \
@@ -173,7 +173,7 @@ const sctp_sm_table_entry_t *sctp_sm_loo
/* SCTP_STATE_EMPTY */ \
TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_CLOSED */ \
- TYPE_SCTP_FUNC(sctp_sf_tabort_8_4_8), \
+ TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_COOKIE_WAIT */ \
TYPE_SCTP_FUNC(sctp_sf_discard_chunk), \
/* SCTP_STATE_COOKIE_ECHOED */ \
@@ -194,7 +194,7 @@ const sctp_sm_table_entry_t *sctp_sm_loo
/* SCTP_STATE_EMPTY */ \
TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_CLOSED */ \
- TYPE_SCTP_FUNC(sctp_sf_tabort_8_4_8), \
+ TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_COOKIE_WAIT */ \
TYPE_SCTP_FUNC(sctp_sf_discard_chunk), \
/* SCTP_STATE_COOKIE_ECHOED */ \
@@ -216,7 +216,7 @@ const sctp_sm_table_entry_t *sctp_sm_loo
/* SCTP_STATE_EMPTY */ \
TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_CLOSED */ \
- TYPE_SCTP_FUNC(sctp_sf_tabort_8_4_8), \
+ TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_COOKIE_WAIT */ \
TYPE_SCTP_FUNC(sctp_sf_violation), \
/* SCTP_STATE_COOKIE_ECHOED */ \
@@ -258,7 +258,7 @@ const sctp_sm_table_entry_t *sctp_sm_loo
/* SCTP_STATE_EMPTY */ \
TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_CLOSED */ \
- TYPE_SCTP_FUNC(sctp_sf_tabort_8_4_8), \
+ TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_COOKIE_WAIT */ \
TYPE_SCTP_FUNC(sctp_sf_discard_chunk), \
/* SCTP_STATE_COOKIE_ECHOED */ \
@@ -300,7 +300,7 @@ const sctp_sm_table_entry_t *sctp_sm_loo
/* SCTP_STATE_EMPTY */ \
TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_CLOSED */ \
- TYPE_SCTP_FUNC(sctp_sf_tabort_8_4_8), \
+ TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_COOKIE_WAIT */ \
TYPE_SCTP_FUNC(sctp_sf_discard_chunk), \
/* SCTP_STATE_COOKIE_ECHOED */ \
@@ -499,7 +499,7 @@ static const sctp_sm_table_entry_t addip
/* SCTP_STATE_EMPTY */ \
TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_CLOSED */ \
- TYPE_SCTP_FUNC(sctp_sf_tabort_8_4_8), \
+ TYPE_SCTP_FUNC(sctp_sf_ootb), \
/* SCTP_STATE_COOKIE_WAIT */ \
TYPE_SCTP_FUNC(sctp_sf_discard_chunk), \
/* SCTP_STATE_COOKIE_ECHOED */ \
@@ -528,7 +528,7 @@ chunk_event_table_unknown[SCTP_STATE_NUM
/* SCTP_STATE_EMPTY */
TYPE_SCTP_FUNC(sctp_sf_ootb),
/* SCTP_STATE_CLOSED */
- TYPE_SCTP_FUNC(sctp_sf_tabort_8_4_8),
+ TYPE_SCTP_FUNC(sctp_sf_ootb),
/* SCTP_STATE_COOKIE_WAIT */
TYPE_SCTP_FUNC(sctp_sf_unk_chunk),
/* SCTP_STATE_COOKIE_ECHOED */
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-08-31 10:17 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <46D7E050.1030303@bigtelecom.ru>
On Fri, Aug 31, 2007 at 01:33:04PM +0400, Badalian Vyacheslav wrote:
>
> >>i not have testing mashine.
> >>we have 2 mashine and dynamic routing. if 1 mashine down - all traffic
> >>go to second mashine.
> >>I can test is on this mashines but i need that testing mashine will
> >>reboot on kernel panic (sysctl message). No freezes =)
> >>
> >>Ok. i try 2.6.23-rc4.
> >>
> >
> >...but without testing machine it can be too much risk! New versions
> >of kernel can break your applications (sometimes they should be at
> >least rebuilded).
> >
> >So, maybe you would better try this, 'less testing', version of my patch:
> >
> >
> I risk only if RC kernel broke hardware. Mashines use only iptables and
> TC. All Scrips backuped.
But sometime a new kernel can break binary compatibility with previous
one (e.g. after data structures change) and e.g. iptables or iproute
tools stop working or work in an unpredictable way. There were a few
such changes before 2.6.20 - I don't track current changes too much.
And I'm sure your system uses much more than iptables or TC, even
without your knowledge.
> But if i need to reboot PC by hand (if it freeze) i need drive to
> servers-room =)
Of course, if previous kernel always boots by default, or even there
is a possibility to use for testing different partition with a copy
of main system this risk should be much smaller.
>
> > BTW, I think after this BUG could be something more about other CPUs.
> > Could you check this?
>
> I send to you all info that catch NETCONSOLE. i don't cut any info...
So, it seems something was broken. But, I meant, there can be sometimes
interesting things a few lines before or after the infos too.
>
> Now 1 mashine work at *"2.6.23-rc4-git2
> <http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.23-rc4-git2.bz2>"
> Backup mashine use 2.6.18*
>
BTW, -git versions are usually more risky than -rc. And, maybe, let
this 2.6.18 better stay away from this testing...
Thanks,
Jarek P.
^ permalink raw reply
* Re: [ANNOUNCE] iproute2-2.6.23-rc3
From: Patrick McHardy @ 2007-08-31 9:45 UTC (permalink / raw)
To: Pavel Emelyanov; +Cc: Stephen Hemminger, netdev
In-Reply-To: <46D7E0A4.2010404@openvz.org>
On Fri, 31 Aug 2007, Pavel Emelyanov wrote:
> Patrick McHardy wrote:
>> On Wed, 22 Aug 2007, Stephen Hemminger wrote:
>>
>>> There have been a lot of changes for 2.6.23, so here is a test release
>>> of iproute2 that should capture all the submitted patches
>>>
>>> Pavel Emelianov (1):
>>> Make ip utility veth driver aware
>>
>>
>> Why does this add a new ip subcommand instead and uses genetlink
>> instead of the rtnl_link API, which was introduced exactly for
>> this stuff?
>>
>
> Hm... It does not, it just adds a parser for veth commands that
> generic layer isn't aware of.
It does, you have "ip veth add", "ip veth del", ...
Didn't you already sent a patch that used "ip link add ..."?
In any case this should be replaced by proper use of the rtnl_link
stuff.
^ permalink raw reply
* Re: [ANNOUNCE] iproute2-2.6.23-rc3
From: Pavel Emelyanov @ 2007-08-31 9:34 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Stephen Hemminger, netdev
In-Reply-To: <Pine.LNX.4.64.0708311112001.5681@x2>
Patrick McHardy wrote:
> On Wed, 22 Aug 2007, Stephen Hemminger wrote:
>
>> There have been a lot of changes for 2.6.23, so here is a test release
>> of iproute2 that should capture all the submitted patches
>>
>> Pavel Emelianov (1):
>> Make ip utility veth driver aware
>
>
> Why does this add a new ip subcommand instead and uses genetlink
> instead of the rtnl_link API, which was introduced exactly for
> this stuff?
>
Hm... It does not, it just adds a parser for veth commands that
generic layer isn't aware of.
^ permalink raw reply
* Re: [PATCH] [NET_SCHED] sch_prio.c: remove duplicate call of tc_classify()
From: Patrick McHardy @ 2007-08-31 9:35 UTC (permalink / raw)
To: Lucas Nussbaum; +Cc: netdev
In-Reply-To: <20070830072817.GA9617@xanadu.blop.info>
On Thu, 30 Aug 2007, Lucas Nussbaum wrote:
> When CONFIG_NET_CLS_ACT is enabled, tc_classify() is called twice in
> prio_classify(). This causes "interesting" behaviour: with the setup
> below, packets are duplicated, sent twice to ifb0, and then loop in and
> out of ifb0.
>
> The patch uses the previously calculated return value in the switch,
> which is probably what Patrick had in mind in commit
> bdba91ec70fb5ccbdeb1c7068319adc6ea9e1a7d -- maybe Patrick can
> double-check this?
Thanks for catching this, this is indeed what I had in mind.
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Badalian Vyacheslav @ 2007-08-31 9:33 UTC (permalink / raw)
To: Jarek Poplawski; +Cc: netdev
In-Reply-To: <20070831090509.GC1772@ff.dom.local>
>> i not have testing mashine.
>> we have 2 mashine and dynamic routing. if 1 mashine down - all traffic
>> go to second mashine.
>> I can test is on this mashines but i need that testing mashine will
>> reboot on kernel panic (sysctl message). No freezes =)
>>
>> Ok. i try 2.6.23-rc4.
>>
>
> ...but without testing machine it can be too much risk! New versions
> of kernel can break your applications (sometimes they should be at
> least rebuilded).
>
> So, maybe you would better try this, 'less testing', version of my patch:
>
>
I risk only if RC kernel broke hardware. Mashines use only iptables and
TC. All Scrips backuped.
But if i need to reboot PC by hand (if it freeze) i need drive to
servers-room =)
> BTW, I think after this BUG could be something more about other CPUs.
> Could you check this?
I send to you all info that catch NETCONSOLE. i don't cut any info...
Now 1 mashine work at *"2.6.23-rc4-git2
<http://kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.23-rc4-git2.bz2>"
Backup mashine use 2.6.18*
^ permalink raw reply
* Re: [PATCH 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver
From: Herbert Xu @ 2007-08-31 9:30 UTC (permalink / raw)
To: Jesper Juhl, Al Viro
Cc: dsd-aBrp7R+bbdUdnm+yROfE0A, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, davem-fT/PcQaiUtIeIZ0/mPfg9Q,
kune-hUSrv6EASfkEnNRfnnE9gw,
linux-wireless-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <9a8748490708301320o49d8e794vc5c37ffc938006f1-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Jesper Juhl <jesper.juhl-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On 30/08/2007, Daniel Drake <dsd-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org> wrote:
>> Jesper Juhl wrote:
>> > Since kmalloc() returns a void pointer there is no reason to cast
>> > its return value.
>> > This patch also removes a pointless initialization of a variable.
>>
>> NAK: adds a sparse warning
>> zd_chip.c:116:15: warning: implicit cast to nocast type
>>
> Ok, I must admit I didn't check with sparse since it seemed pointless
> - we usually never cast void pointers to other pointer types,
> specifically because the C language nicely guarantees that the right
> thing will happen without the cast. Sometimes we have to cast them to
> integer types, su sure we need the cast there. But what on earth
> makes a "zd_addr_t *" so special that we have to explicitly cast a
> "void *" to that type?
>
> I see it's defined as
> typedef u32 __nocast zd_addr_t;
> in drivers/net/wireless/zd1211rw/zd_types.h , but why the __nocast ?
Nevermind the __nocast, this looks like a bug in sparse. Just
because a base type is __nocast, sparse shouldn't infer that a
pointer to it should also be __nocast.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [ANNOUNCE] iproute2-2.6.23-rc3
From: Patrick McHardy @ 2007-08-31 9:15 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, xemul
In-Reply-To: <20070822110804.30c2e803@freepuppy.rosehill.hemminger.net>
On Wed, 22 Aug 2007, Stephen Hemminger wrote:
> There have been a lot of changes for 2.6.23, so here is a test release
> of iproute2 that should capture all the submitted patches
>
> Pavel Emelianov (1):
> Make ip utility veth driver aware
Why does this add a new ip subcommand instead and uses genetlink
instead of the rtnl_link API, which was introduced exactly for
this stuff?
^ permalink raw reply
* Re: Tc bug (kernel crash) more info
From: Jarek Poplawski @ 2007-08-31 9:16 UTC (permalink / raw)
To: Badalian Vyacheslav; +Cc: netdev
In-Reply-To: <20070831090509.GC1772@ff.dom.local>
On Fri, Aug 31, 2007 at 11:05:09AM +0200, Jarek Poplawski wrote:
...
> So, maybe you would better try this, 'less testing', version of my patch:
Of course, the previous patch should be reverted (patch -p1 -R) or
clean 2.6.22.5 used for this.
Jarek P.
^ permalink raw reply
* [PATCH 7/7] [PPP] generic: Fix receive path data clobbering & non-linear handling
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[PPP] generic: Fix receive path data clobbering & non-linear handling
This patch adds missing pskb_may_pull calls to deal with non-linear
packets that may arrive from pppoe or pppol2tp.
It also copies cloned packets before writing over them.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/net/ppp_generic.c | 44 +++++++++++++++++++++++++-------------------
1 files changed, 25 insertions(+), 19 deletions(-)
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index 7e21342..4b49d0e 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -1525,7 +1525,7 @@ ppp_input_error(struct ppp_channel *chan, int code)
static void
ppp_receive_frame(struct ppp *ppp, struct sk_buff *skb, struct channel *pch)
{
- if (skb->len >= 2) {
+ if (pskb_may_pull(skb, 2)) {
#ifdef CONFIG_PPP_MULTILINK
/* XXX do channel-level decompression here */
if (PPP_PROTO(skb) == PPP_MP)
@@ -1577,7 +1577,7 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
if (ppp->vj == 0 || (ppp->flags & SC_REJ_COMP_TCP))
goto err;
- if (skb_tailroom(skb) < 124) {
+ if (skb_tailroom(skb) < 124 || skb_cloned(skb)) {
/* copy to a new sk_buff with more tailroom */
ns = dev_alloc_skb(skb->len + 128);
if (ns == 0) {
@@ -1648,23 +1648,29 @@ ppp_receive_nonmp_frame(struct ppp *ppp, struct sk_buff *skb)
/* check if the packet passes the pass and active filters */
/* the filter instructions are constructed assuming
a four-byte PPP header on each packet */
- *skb_push(skb, 2) = 0;
- if (ppp->pass_filter
- && sk_run_filter(skb, ppp->pass_filter,
- ppp->pass_len) == 0) {
- if (ppp->debug & 1)
- printk(KERN_DEBUG "PPP: inbound frame not passed\n");
- kfree_skb(skb);
- return;
- }
- if (!(ppp->active_filter
- && sk_run_filter(skb, ppp->active_filter,
- ppp->active_len) == 0))
- ppp->last_recv = jiffies;
- skb_pull(skb, 2);
-#else
- ppp->last_recv = jiffies;
+ if (ppp->pass_filter || ppp->active_filter) {
+ if (skb_cloned(skb) &&
+ pskb_expand_head(skb, 0, 0, GFP_ATOMIC))
+ goto err;
+
+ *skb_push(skb, 2) = 0;
+ if (ppp->pass_filter
+ && sk_run_filter(skb, ppp->pass_filter,
+ ppp->pass_len) == 0) {
+ if (ppp->debug & 1)
+ printk(KERN_DEBUG "PPP: inbound frame "
+ "not passed\n");
+ kfree_skb(skb);
+ return;
+ }
+ if (!(ppp->active_filter
+ && sk_run_filter(skb, ppp->active_filter,
+ ppp->active_len) == 0))
+ ppp->last_recv = jiffies;
+ __skb_pull(skb, 2);
+ } else
#endif /* CONFIG_PPP_FILTER */
+ ppp->last_recv = jiffies;
if ((ppp->dev->flags & IFF_UP) == 0
|| ppp->npmode[npi] != NPMODE_PASS) {
@@ -1762,7 +1768,7 @@ ppp_receive_mp_frame(struct ppp *ppp, struct sk_buff *skb, struct channel *pch)
struct channel *ch;
int mphdrlen = (ppp->flags & SC_MP_SHORTSEQ)? MPHDRLEN_SSN: MPHDRLEN;
- if (!pskb_may_pull(skb, mphdrlen) || ppp->mrru == 0)
+ if (!pskb_may_pull(skb, mphdrlen + 1) || ppp->mrru == 0)
goto err; /* no good, throw it away */
/* Decode sequence number and begin/end bits */
^ permalink raw reply related
* [PATCH 6/7] [PPP] generic: Call skb_cow_head before scribbling over skb
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[PPP] generic: Call skb_cow_head before scribbling over skb
It's rude to write over data that other people are still using. So call
skb_cow_head before PPP proceeds to modify the skb data.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/net/ppp_generic.c | 14 +++-----------
1 files changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ppp_generic.c b/drivers/net/ppp_generic.c
index 9293c82..7e21342 100644
--- a/drivers/net/ppp_generic.c
+++ b/drivers/net/ppp_generic.c
@@ -899,17 +899,9 @@ ppp_start_xmit(struct sk_buff *skb, struct net_device *dev)
/* Put the 2-byte PPP protocol number on the front,
making sure there is room for the address and control fields. */
- if (skb_headroom(skb) < PPP_HDRLEN) {
- struct sk_buff *ns;
-
- ns = alloc_skb(skb->len + dev->hard_header_len, GFP_ATOMIC);
- if (ns == 0)
- goto outf;
- skb_reserve(ns, dev->hard_header_len);
- skb_copy_bits(skb, 0, skb_put(ns, skb->len), skb->len);
- kfree_skb(skb);
- skb = ns;
- }
+ if (skb_cow_head(skb, PPP_HDRLEN))
+ goto outf;
+
pp = skb_push(skb, 2);
proto = npindex_to_proto[npi];
pp[0] = proto >> 8;
^ permalink raw reply related
* [PATCH 5/7] [NET] skbuff: Add skb_cow_head
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[NET] skbuff: Add skb_cow_head
This patch adds an optimised version of skb_cow that avoids the copy if
the header can be modified even if the rest of the payload is cloned.
This can be used in encapsulating paths where we only need to modify the
header. As it is, this can be used in PPPOE and bridging.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/net/pppoe.c | 2 +-
include/linux/skbuff.h | 40 +++++++++++++++++++++++++++++++---------
net/bridge/br_netfilter.c | 2 +-
3 files changed, 33 insertions(+), 11 deletions(-)
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index bac3654..0d7f570 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -860,7 +860,7 @@ static int __pppoe_xmit(struct sock *sk, struct sk_buff *skb)
/* Copy the data if there is no space for the header or if it's
* read-only.
*/
- if (skb_cow(skb, sizeof(*ph) + dev->hard_header_len))
+ if (skb_cow_head(skb, sizeof(*ph) + dev->hard_header_len))
goto abort;
__skb_push(skb, sizeof(*ph));
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 93c27f7..a656cec 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -1352,6 +1352,22 @@ static inline int skb_clone_writable(struct sk_buff *skb, int len)
skb_headroom(skb) + len <= skb->hdr_len;
}
+static inline int __skb_cow(struct sk_buff *skb, unsigned int headroom,
+ int cloned)
+{
+ int delta = 0;
+
+ if (headroom < NET_SKB_PAD)
+ headroom = NET_SKB_PAD;
+ if (headroom > skb_headroom(skb))
+ delta = headroom - skb_headroom(skb);
+
+ if (delta || cloned)
+ return pskb_expand_head(skb, ALIGN(delta, NET_SKB_PAD), 0,
+ GFP_ATOMIC);
+ return 0;
+}
+
/**
* skb_cow - copy header of skb when it is required
* @skb: buffer to cow
@@ -1366,16 +1382,22 @@ static inline int skb_clone_writable(struct sk_buff *skb, int len)
*/
static inline int skb_cow(struct sk_buff *skb, unsigned int headroom)
{
- int delta = (headroom > NET_SKB_PAD ? headroom : NET_SKB_PAD) -
- skb_headroom(skb);
-
- if (delta < 0)
- delta = 0;
+ return __skb_cow(skb, headroom, skb_cloned(skb));
+}
- if (delta || skb_cloned(skb))
- return pskb_expand_head(skb, (delta + (NET_SKB_PAD-1)) &
- ~(NET_SKB_PAD-1), 0, GFP_ATOMIC);
- return 0;
+/**
+ * skb_cow_head - skb_cow but only making the head writable
+ * @skb: buffer to cow
+ * @headroom: needed headroom
+ *
+ * This function is identical to skb_cow except that we replace the
+ * skb_cloned check by skb_header_cloned. It should be used when
+ * you only need to push on some header and do not need to modify
+ * the data.
+ */
+static inline int skb_cow_head(struct sk_buff *skb, unsigned int headroom)
+{
+ return __skb_cow(skb, headroom, skb_header_cloned(skb));
}
/**
diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
index 3ee2022..fc13130 100644
--- a/net/bridge/br_netfilter.c
+++ b/net/bridge/br_netfilter.c
@@ -183,7 +183,7 @@ int nf_bridge_copy_header(struct sk_buff *skb)
int err;
int header_size = ETH_HLEN + nf_bridge_encap_header_len(skb);
- err = skb_cow(skb, header_size);
+ err = skb_cow_head(skb, header_size);
if (err)
return err;
^ permalink raw reply related
* [PATCH 1/7] [PPP] pppoe: Fix skb_unshare_check call position
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[PPP] pppoe: Fix skb_unshare_check call position
The skb_unshare_check call needs to be made before pskb_may_pull,
not after.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
drivers/net/pppoe.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/pppoe.c b/drivers/net/pppoe.c
index 68631a5..5ac3eff 100644
--- a/drivers/net/pppoe.c
+++ b/drivers/net/pppoe.c
@@ -385,12 +385,12 @@ static int pppoe_rcv(struct sk_buff *skb,
struct pppoe_hdr *ph;
struct pppox_sock *po;
- if (!pskb_may_pull(skb, sizeof(struct pppoe_hdr)))
- goto drop;
-
if (!(skb = skb_share_check(skb, GFP_ATOMIC)))
goto out;
+ if (!pskb_may_pull(skb, sizeof(struct pppoe_hdr)))
+ goto drop;
+
ph = pppoe_hdr(skb);
po = get_item((unsigned long) ph->sid, eth_hdr(skb)->h_source, dev->ifindex);
^ permalink raw reply related
* [PATCH 4/7] [BRIDGE]: Kill clone argument to br_flood_*
From: Herbert Xu @ 2007-08-31 9:11 UTC (permalink / raw)
To: James Chapman, David S. Miller, Michal Ostrowski, Paul Mackerras,
Herbert Xu
In-Reply-To: <20070831090625.GA28175@gondor.apana.org.au>
[BRIDGE]: Kill clone argument to br_flood_*
The clone argument is only used by one caller and that caller can clone
the packet itself. This patch moves the clone call into the caller and
kills the clone argument.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
---
net/bridge/br_device.c | 4 ++--
net/bridge/br_forward.c | 21 +++++----------------
net/bridge/br_input.c | 48 ++++++++++++++++++++++--------------------------
net/bridge/br_private.h | 8 ++------
4 files changed, 31 insertions(+), 50 deletions(-)
diff --git a/net/bridge/br_device.c b/net/bridge/br_device.c
index 0eded17..99292e8 100644
--- a/net/bridge/br_device.c
+++ b/net/bridge/br_device.c
@@ -41,11 +41,11 @@ int br_dev_xmit(struct sk_buff *skb, struct net_device *dev)
skb_pull(skb, ETH_HLEN);
if (dest[0] & 1)
- br_flood_deliver(br, skb, 0);
+ br_flood_deliver(br, skb);
else if ((dst = __br_fdb_get(br, dest)) != NULL)
br_deliver(dst->dst, skb);
else
- br_flood_deliver(br, skb, 0);
+ br_flood_deliver(br, skb);
return 0;
}
diff --git a/net/bridge/br_forward.c b/net/bridge/br_forward.c
index ada7f49..bdd7c35 100644
--- a/net/bridge/br_forward.c
+++ b/net/bridge/br_forward.c
@@ -100,24 +100,13 @@ void br_forward(const struct net_bridge_port *to, struct sk_buff *skb)
}
/* called under bridge lock */
-static void br_flood(struct net_bridge *br, struct sk_buff *skb, int clone,
+static void br_flood(struct net_bridge *br, struct sk_buff *skb,
void (*__packet_hook)(const struct net_bridge_port *p,
struct sk_buff *skb))
{
struct net_bridge_port *p;
struct net_bridge_port *prev;
- if (clone) {
- struct sk_buff *skb2;
-
- if ((skb2 = skb_clone(skb, GFP_ATOMIC)) == NULL) {
- br->statistics.tx_dropped++;
- return;
- }
-
- skb = skb2;
- }
-
prev = NULL;
list_for_each_entry_rcu(p, &br->port_list, list) {
@@ -148,13 +137,13 @@ static void br_flood(struct net_bridge *br, struct sk_buff *skb, int clone,
/* called with rcu_read_lock */
-void br_flood_deliver(struct net_bridge *br, struct sk_buff *skb, int clone)
+void br_flood_deliver(struct net_bridge *br, struct sk_buff *skb)
{
- br_flood(br, skb, clone, __br_deliver);
+ br_flood(br, skb, __br_deliver);
}
/* called under bridge lock */
-void br_flood_forward(struct net_bridge *br, struct sk_buff *skb, int clone)
+void br_flood_forward(struct net_bridge *br, struct sk_buff *skb)
{
- br_flood(br, skb, clone, __br_forward);
+ br_flood(br, skb, __br_forward);
}
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 5c18595..069a4e1 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -43,7 +43,7 @@ int br_handle_frame_finish(struct sk_buff *skb)
struct net_bridge_port *p = rcu_dereference(skb->dev->br_port);
struct net_bridge *br;
struct net_bridge_fdb_entry *dst;
- int passedup = 0;
+ struct sk_buff *skb2;
if (!p || p->state == BR_STATE_DISABLED)
goto drop;
@@ -55,39 +55,35 @@ int br_handle_frame_finish(struct sk_buff *skb)
if (p->state == BR_STATE_LEARNING)
goto drop;
- if (br->dev->flags & IFF_PROMISC) {
- struct sk_buff *skb2;
+ /* The packet skb2 goes to the local host (NULL to skip). */
+ skb2 = NULL;
- skb2 = skb_clone(skb, GFP_ATOMIC);
- if (skb2 != NULL) {
- passedup = 1;
- br_pass_frame_up(br, skb2);
- }
- }
+ if (br->dev->flags & IFF_PROMISC)
+ skb2 = skb;
+
+ dst = NULL;
if (is_multicast_ether_addr(dest)) {
br->statistics.multicast++;
- br_flood_forward(br, skb, !passedup);
- if (!passedup)
- br_pass_frame_up(br, skb);
- goto out;
+ skb2 = skb;
+ } else if ((dst = __br_fdb_get(br, dest)) && dst->is_local) {
+ skb2 = skb;
+ /* Do not forward the packet since it's local. */
+ skb = NULL;
}
- dst = __br_fdb_get(br, dest);
- if (dst != NULL && dst->is_local) {
- if (!passedup)
- br_pass_frame_up(br, skb);
- else
- kfree_skb(skb);
- goto out;
- }
+ if (skb2 == skb)
+ skb2 = skb_clone(skb, GFP_ATOMIC);
- if (dst != NULL) {
- br_forward(dst->dst, skb);
- goto out;
- }
+ if (skb2)
+ br_pass_frame_up(br, skb2);
- br_flood_forward(br, skb, 0);
+ if (skb) {
+ if (dst)
+ br_forward(dst->dst, skb);
+ else
+ br_flood_forward(br, skb);
+ }
out:
return 0;
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index 21bf3a9..e6dc6f5 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -170,12 +170,8 @@ extern int br_dev_queue_push_xmit(struct sk_buff *skb);
extern void br_forward(const struct net_bridge_port *to,
struct sk_buff *skb);
extern int br_forward_finish(struct sk_buff *skb);
-extern void br_flood_deliver(struct net_bridge *br,
- struct sk_buff *skb,
- int clone);
-extern void br_flood_forward(struct net_bridge *br,
- struct sk_buff *skb,
- int clone);
+extern void br_flood_deliver(struct net_bridge *br, struct sk_buff *skb);
+extern void br_flood_forward(struct net_bridge *br, struct sk_buff *skb);
/* br_if.c */
extern void br_port_carrier_check(struct net_bridge_port *p);
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox