From: Vlad Yasevich <vladislav.yasevich@hp.com>
To: linux-sctp@vger.kernel.org
Subject: Re: BUG in sctp crashes the system
Date: Tue, 18 Nov 2008 15:46:44 +0000 [thread overview]
Message-ID: <4922E364.6020002@hp.com> (raw)
In-Reply-To: <200811061205.57403.mhocko@suse.cz>
Michal Hocko wrote:
> On Tue 18-11-08 09:04:58, Vlad Yasevich wrote:
>> Michal Hocko wrote:
>>> On Thu 06-11-08 08:48:45, Vlad Yasevich wrote:
>>>> Michal Hocko wrote:
>>>>> Hi,
> [...]
>>> Do you have any ETA?
>>> Is there some way how to help here?
>>>
>> which version in particular is most critical?
>>
>> Just remember then 2.6.16 is very old and there have been a lot of fixes that
>> address critical issues.
>>
>> For 2.6.28, can you apply the attached patch and post dmesg output. Also, if
>> it's possible to capture a kdump, that would make things much easier.
>
> Does it make sense to enable CONFIG_SCTP_DBG_MSG and CONFIG_SCTP_DBG_OBJCNT?
> We don't set them in our enterprise kernels and I as this seems to be
> race condition I would like to prevent some timing issues. But if it is
> worth trying I can try to turn them on.
>
DBG_MSG will slow everything down too much and will alter any races significantly.
I don't think this is as much a race as potentially corruption. From the
skb_over_panic() you reported, the allocated skb looks very strange.
The skb size is 1280 bytes and the reserved header area is on 116 bytes.
That doesn't appear to correspond to what should be in the packet.
So, either sctp_packet or skb somehow got corrupted. The debug code I
added will show the values from the sctp_packet if such corruption occurs.
We'll still BUG out since I want to see the values from the skb as well.
Getting a kdump will allow to examine other areas as well, but I wanted
to start small.
-vlad
next prev parent reply other threads:[~2008-11-18 15:46 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-06 11:05 BUG in sctp crashes the system Michal Hocko
2008-11-06 13:48 ` Vlad Yasevich
2008-11-13 12:19 ` Michal Hocko
2008-11-18 9:03 ` Michal Hocko
2008-11-18 14:04 ` Vlad Yasevich
2008-11-18 14:10 ` Michal Hocko
2008-11-18 14:22 ` Michal Hocko
2008-11-18 15:46 ` Vlad Yasevich [this message]
2008-11-18 16:12 ` Michal Hocko
2008-11-19 10:54 ` Michal Hocko
2008-11-21 14:28 ` Vlad Yasevich
2008-11-21 14:48 ` Michal Hocko
2008-11-21 15:05 ` Michal Hocko
2008-11-21 15:35 ` Vlad Yasevich
2008-11-21 15:42 ` Vlad Yasevich
2008-11-21 15:50 ` Michal Hocko
2008-11-24 13:35 ` Michal Hocko
2008-11-24 15:00 ` Vlad Yasevich
2008-11-24 15:25 ` Michal Hocko
2008-11-24 15:31 ` Vlad Yasevich
2008-12-08 18:53 ` Vlad Yasevich
2008-12-09 15:38 ` Michal Hocko
2008-12-09 17:06 ` Vlad Yasevich
2008-12-11 9:27 ` Michal Hocko
2008-12-11 13:47 ` Vlad Yasevich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4922E364.6020002@hp.com \
--to=vladislav.yasevich@hp.com \
--cc=linux-sctp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.