From: Dan Malek <dan@embeddededge.com>
To: "Christian Gan" <christian.gan@librestream.com>
Cc: <linux-mips@linux-mips.org>,
"Herbert Valerio Riedel" <hvr@hvrlab.org>,
"Josh Green" <jgreen@users.sourceforge.net>,
"Pete Popov" <ppopov@embeddedalley.com>
Subject: Re: iptables/vmalloc issues on alchemy
Date: Thu, 28 Apr 2005 16:56:39 -0400 [thread overview]
Message-ID: <ca9dea6d5cc67afd6a42f06de4286bf9@embeddededge.com> (raw)
In-Reply-To: <8230E1CC35AF9F43839F3049E930169A137217@yang.LibreStream.local>
On Apr 28, 2005, at 4:11 PM, Christian Gan wrote:
> Could this also related to this problem I posted a long time ago? I
> haven't had a chance to revisit things for a while...
I've just been talking about 2.6, so "long time ago" can't be
that long :-) I have the updates to the exception handler so
the PTEs get loaded correctly, that's on the way. I think 2.4
should be OK if anyone is using that.
The one that bothers me is this patch I've been sitting on for
quite some time. It's not specific to Alchemy, it's a generic
MIPS page table issue. The problem started when someone
loaded very large modules which caused a new kernel page
table to be allocated. For some reason I don't remember,
the vmalloc_fault fixup didn't handle this, and the applications
would crash the system because their pgd page didn't
get updated to reflect this. The address must have been in
the vmalloc space, but I no longer have the system for testing
(but the code is running in a several thousand real products).
The only way I could make this work is to test the fault address,
the most significant bit anyway, in the TLB miss handler to
see if it was a user or kernel address. If it was a kernel address,
I loaded the init_mm pgd instead of the thread pgd. Just one
test and a couple of instructions, but it was necessary. I'm
still puzzling, but will remember :-)
Thanks.
-- Dan
WARNING: multiple messages have this Message-ID (diff)
From: Dan Malek <dan@embeddededge.com>
To: Christian Gan <christian.gan@librestream.com>
Cc: linux-mips@linux-mips.org,
Herbert Valerio Riedel <hvr@hvrlab.org>,
Josh Green <jgreen@users.sourceforge.net>,
Pete Popov <ppopov@embeddedalley.com>
Subject: Re: iptables/vmalloc issues on alchemy
Date: Thu, 28 Apr 2005 16:56:39 -0400 [thread overview]
Message-ID: <ca9dea6d5cc67afd6a42f06de4286bf9@embeddededge.com> (raw)
Message-ID: <20050428205639._pXxC1I42Eatk4SlGvzq57eoKogvHvycjQPiKpNZosE@z> (raw)
In-Reply-To: <8230E1CC35AF9F43839F3049E930169A137217@yang.LibreStream.local>
On Apr 28, 2005, at 4:11 PM, Christian Gan wrote:
> Could this also related to this problem I posted a long time ago? I
> haven't had a chance to revisit things for a while...
I've just been talking about 2.6, so "long time ago" can't be
that long :-) I have the updates to the exception handler so
the PTEs get loaded correctly, that's on the way. I think 2.4
should be OK if anyone is using that.
The one that bothers me is this patch I've been sitting on for
quite some time. It's not specific to Alchemy, it's a generic
MIPS page table issue. The problem started when someone
loaded very large modules which caused a new kernel page
table to be allocated. For some reason I don't remember,
the vmalloc_fault fixup didn't handle this, and the applications
would crash the system because their pgd page didn't
get updated to reflect this. The address must have been in
the vmalloc space, but I no longer have the system for testing
(but the code is running in a several thousand real products).
The only way I could make this work is to test the fault address,
the most significant bit anyway, in the TLB miss handler to
see if it was a user or kernel address. If it was a kernel address,
I loaded the init_mm pgd instead of the thread pgd. Just one
test and a couple of instructions, but it was necessary. I'm
still puzzling, but will remember :-)
Thanks.
-- Dan
next prev parent reply other threads:[~2005-04-28 20:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-04-28 20:11 iptables/vmalloc issues on alchemy Christian Gan
2005-04-28 20:11 ` Christian Gan
2005-04-28 20:56 ` Dan Malek [this message]
2005-04-28 20:56 ` Dan Malek
-- strict thread matches above, loose matches on Subject: below --
2005-04-28 23:16 Christian Gan
2005-04-28 23:16 ` Christian Gan
2005-04-28 21:22 Christian Gan
2005-04-28 21:22 ` Christian Gan
2005-04-28 22:16 ` Dan Malek
2005-04-28 22:16 ` Dan Malek
2005-04-28 23:52 ` Thiemo Seufer
2005-04-26 8:43 Herbert Valerio Riedel
2005-04-27 18:49 ` Josh Green
2005-04-27 19:06 ` Dan Malek
2005-04-28 5:06 ` Herbert Valerio Riedel
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=ca9dea6d5cc67afd6a42f06de4286bf9@embeddededge.com \
--to=dan@embeddededge.com \
--cc=christian.gan@librestream.com \
--cc=hvr@hvrlab.org \
--cc=jgreen@users.sourceforge.net \
--cc=linux-mips@linux-mips.org \
--cc=ppopov@embeddedalley.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox