* [PATCH] boobytrap for 2.2.15pre5
@ 2000-01-28 2:28 Rik van Riel
2000-01-28 10:33 ` Tony Gale
2000-01-28 12:24 ` Tom Leete
0 siblings, 2 replies; 6+ messages in thread
From: Rik van Riel @ 2000-01-28 2:28 UTC (permalink / raw)
To: Linux Kernel; +Cc: Alan Cox, Linux MM
Hi,
the `boobytrap' code in __get_free_pages() that was
included in 2.2.15-pre5 has been quite succesful,
the kernel programmers have already managed to fix
a number of bugs found by people running this patch.
However, there are a number of places in the kernel
where the patch to __get_free_pages() is done in an
`indirect' way. This patch adds boobytrap code to
some (most?) of these indirect code paths as well,
allowing us to track down more errors and have a
BugFree(tm) 2.2 kernel sooner.
If you apply this patch your kernel will spit out
a one-line error message on every offence (and a
2-liner on a recursive offence). Each error message
will be of the form:
gfp called by non-running (1) task from c0121e23!
The first word, `gfp' is the function that raises the alarm.
The number between parentheses (1) is the tsk->state.
The last number is the memory address from where we were
called.
You can find this memory address in System.map or in
/proc/ksyms (useful if you have modules). When your
system spits out such a message, you can look up the
offending function in this way:
$ cat /proc/ksyms | sort | grep c0121
c0121474 vfree
c01214dc vmalloc
c01216a4 kmem_cache_create
c0121be0 kmem_cache_shrink
c0122114 kmem_cache_alloc (added for aestetic value)
Of course, you replace the number `c0121' with the
first few numbers of the error message you get...
As we can see, the address from the error message above
(c0121e23) lies between the beginnings of kmem_cache_shrink
and kmem_cache_alloc, that is, it is _in_ kmem_cache_shrink.
When you encounter these error messages, please send them
to linux-kernel, _with_ the names of the functions (because
they differ on every compilation) and, if possible, a short
explanation of what do did to provoke these errors.
kind regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
--- linux-2.2.15pre5/mm/vmscan.c.orig Fri Jan 28 00:13:18 2000
+++ linux-2.2.15pre5/mm/vmscan.c Fri Jan 28 01:46:02 2000
@@ -497,8 +497,11 @@
{
if (!do_try_to_free_pages(GFP_KSWAPD))
break;
- if (tsk->need_resched)
+ if (tsk->need_resched) {
+ if (nr_free_pages > freepages.low)
+ break;
schedule();
+ }
}
run_task_queue(&tq_disk);
interruptible_sleep_on_timeout(&kswapd_wait, HZ);
--- linux-2.2.15pre5/mm/memory.c.orig Fri Jan 28 00:16:30 2000
+++ linux-2.2.15pre5/mm/memory.c Fri Jan 28 01:45:40 2000
@@ -611,6 +611,12 @@
pte_t pte;
unsigned long old_page, new_page;
struct page * page_map;
+
+ /* booby trap */
+ if (current->state != TASK_RUNNING) {
+ printk("do_wp_page called by non-running (%d) task from %p!\n",
+ current->state, __builtin_return_address(0));
+ }
pte = *page_table;
new_page = __get_free_page(GFP_USER);
@@ -806,6 +812,13 @@
static int do_anonymous_page(struct task_struct * tsk, struct vm_area_struct * vma, pte_t *page_table, int write_access, unsigned long addr)
{
pte_t entry = pte_wrprotect(mk_pte(ZERO_PAGE(addr), vma->vm_page_prot));
+
+ /* booby trap */
+ if (current->state != TASK_RUNNING) {
+ printk("do_anonymous_page called by non-running (%d) task from %p!\n",
+ current->state, __builtin_return_address(0));
+ }
+
if (write_access) {
unsigned long page = __get_free_page(GFP_USER);
if (!page)
@@ -932,6 +945,12 @@
pte_t * pte;
int ret;
+ /* booby trap */
+ if (current->state != TASK_RUNNING) {
+ printk("handle_mm_fault called by non-running (%d) task from %p!\n",
+ current->state, __builtin_return_address(0));
+ }
+
pgd = pgd_offset(vma->vm_mm, address);
pmd = pmd_alloc(pgd, address);
if (!pmd)
--- linux-2.2.15pre5/mm/slab.c.orig Fri Jan 28 00:16:50 2000
+++ linux-2.2.15pre5/mm/slab.c Fri Jan 28 01:40:36 2000
@@ -687,6 +687,12 @@
size_t left_over;
size_t align;
+ /* booby trap */
+ if (current->state != TASK_RUNNING) {
+ printk("kmem_cache_create called by non-running (%d) task from %p!\n",
+ current->state, __builtin_return_address(0));
+ }
+
/* Sanity checks... */
#if SLAB_MGMT_CHECKS
if (!name) {
@@ -1589,6 +1595,12 @@
void *
kmem_cache_alloc(kmem_cache_t *cachep, int flags)
{
+ /* booby trap */
+ if (current->state != TASK_RUNNING) {
+ printk("kmem_cache_alloc called by non-running (%d) task from %p!\n",
+ current->state, __builtin_return_address(0));
+ }
+
return __kmem_cache_alloc(cachep, flags);
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH] boobytrap for 2.2.15pre5
2000-01-28 2:28 [PATCH] boobytrap for 2.2.15pre5 Rik van Riel
@ 2000-01-28 10:33 ` Tony Gale
2000-01-28 14:31 ` Alan Cox
2000-01-28 12:24 ` Tom Leete
1 sibling, 1 reply; 6+ messages in thread
From: Tony Gale @ 2000-01-28 10:33 UTC (permalink / raw)
To: Rik van Riel; +Cc: Linux MM, Alan Cox
Here's my list:
kmem_cache_alloc called by non-running (1) task from c011df72!
kmem_cache_alloc called by non-running (1) task from c011dfdd!
c011dcf0 T kmem_cache_shrink
c011dde4 t kmem_cache_grow
c011e158 t kmem_report_alloc_err
c011e184 t kmem_report_free_err
kmem_cache_alloc called by non-running (1) task from c014d31e!
kmem_cache_alloc called by non-running (2) task from c014d31e!
kmem_cache_alloc called by non-running (4) task from c014d31e!
c014d15c T sock_getsockopt
c014d30c T sk_alloc
c014d348 T sk_free
c014d384 T sock_wfree
kmem_cache_alloc called by non-running (1) task from c014db98!
kmem_cache_alloc called by non-running (2) task from c014db98!
kmem_cache_alloc called by non-running (4) task from c014db98!
c014dafc T show_net_buffers
c014db40 T alloc_skb
c014dc1c T kfree_skbmem
c014dc5c T __kfree_skb
kmem_cache_alloc called by non-running (1) task from c014dd1c!
kmem_cache_alloc called by non-running (2) task from c014dd1c!
kmem_cache_alloc called by non-running (4) task from c014dd1c!
c014dd04 T skb_clone
c014dd98 T skb_copy
c014dee4 T skb_realloc_headroom
kmem_cache_alloc called by non-running (1) task from c015c53d!
kmem_cache_alloc called by non-running (2) task from c015c53d!
kmem_cache_alloc called by non-running (4) task from c015c53d!
c015c438 T tcp_timewait_state_process
c015c528 T tcp_time_wait
c015c74c t tcp_fin
c015c800 t tcp_sack_maybe_coalesce
kmem_cache_alloc called by non-running (1) task from c01618eb!
kmem_cache_alloc called by non-running (2) task from c01618eb!
kmem_cache_alloc called by non-running (4) task from c01618eb!
c01617d0 t tcp_v4_or_free
c01617f4 T tcp_v4_conn_request
c0161b48 T tcp_create_openreq_child
c0161f30 T tcp_v4_syn_recv_sock
---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
We just joined the civil hair patrol!
The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] boobytrap for 2.2.15pre5
2000-01-28 2:28 [PATCH] boobytrap for 2.2.15pre5 Rik van Riel
2000-01-28 10:33 ` Tony Gale
@ 2000-01-28 12:24 ` Tom Leete
1 sibling, 0 replies; 6+ messages in thread
From: Tom Leete @ 2000-01-28 12:24 UTC (permalink / raw)
To: Rik van Riel; +Cc: Linux Kernel, Alan Cox, Linux MM
Rik van Riel wrote:
>
[...]
> If you apply this patch your kernel will spit out
> a one-line error message on every offence (and a
> 2-liner on a recursive offence). Each error message
> will be of the form:
>
[...]
> When you encounter these error messages, please send them
> to linux-kernel, _with_ the names of the functions (because
> they differ on every compilation) and, if possible, a short
> explanation of what do did to provoke these errors.
>
>
Hi,
Got lots of these:
kmem_cache_alloc called from non-running (1) task from
c014d5e8!
then one of these:
kmem_cache_alloc called from non-running (2) task from
c014d5e8!
c014d5e8 is in alloc_skb.
ppp generates a lot of them, but not all. With ppp they seem
to be arriving in bursts of five at intervals of maybe 1 to
5 min. Those intervals are likely to reflect my activity. I
also got a few during startup or login.
net/core/skbuff.c says __GFP_WAIT is clear if
in_interrupt(), but passes all other flags direct to
kmem_cache_alloc. I'm not seeing the printf(KERN_ERR ...)
for sleeping in interrupt from there.
Traces to follow, unless this rings a bell for someone.
Tom
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] boobytrap for 2.2.15pre5
2000-01-28 10:33 ` Tony Gale
@ 2000-01-28 14:31 ` Alan Cox
2000-01-28 14:40 ` Tony Gale
0 siblings, 1 reply; 6+ messages in thread
From: Alan Cox @ 2000-01-28 14:31 UTC (permalink / raw)
To: Tony Gale; +Cc: Rik van Riel, Linux MM, Alan Cox
> c014d30c T sk_alloc
> c014db40 T alloc_skb
> c014dd04 T skb_clone
That path is easy - tcp_connect(). Looks like NFS is being naughty
>
> c015c438 T tcp_timewait_state_process
> c015c528 T tcp_time_wait
This one makes no sense: its
tw = kmem_cache_alloc(tcp_timewait_cachep, SLAB_ATOMIC);
Looking harder I think Rik overdid the debugging checks.
Time for round two on these
Alan
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] boobytrap for 2.2.15pre5
2000-01-28 14:31 ` Alan Cox
@ 2000-01-28 14:40 ` Tony Gale
2000-01-28 14:54 ` Alan Cox
0 siblings, 1 reply; 6+ messages in thread
From: Tony Gale @ 2000-01-28 14:40 UTC (permalink / raw)
To: Alan Cox; +Cc: (Linux MM), (Rik van Riel)
On 28-Jan-2000 Alan Cox wrote:
>> c014d30c T sk_alloc
>> c014db40 T alloc_skb
>> c014dd04 T skb_clone
>
> That path is easy - tcp_connect(). Looks like NFS is being naughty
I don't have NFS compiled in. This is, afterall, part of
my firewall :-)
-tony
---
E-Mail: Tony Gale <gale@syntax.dera.gov.uk>
Reporter, n.:
A writer who guesses his way to the truth and dispels it with a
tempest of words.
-- Ambrose Bierce, "The Devil's Dictionary"
The views expressed above are entirely those of the writer
and do not represent the views, policy or understanding of
any other person or official body.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] boobytrap for 2.2.15pre5
2000-01-28 14:40 ` Tony Gale
@ 2000-01-28 14:54 ` Alan Cox
0 siblings, 0 replies; 6+ messages in thread
From: Alan Cox @ 2000-01-28 14:54 UTC (permalink / raw)
To: Tony Gale; +Cc: Alan Cox, Linux MM, Rik van Riel
> > That path is easy - tcp_connect(). Looks like NFS is being naughty
>
> I don't have NFS compiled in. This is, afterall, part of
> my firewall :-)
Ok that definitely convinces me Rik's booby trap is booby trapped 8). Ive just
let Rik know why on irc, expect rev 2
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2000-01-28 14:54 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2000-01-28 2:28 [PATCH] boobytrap for 2.2.15pre5 Rik van Riel
2000-01-28 10:33 ` Tony Gale
2000-01-28 14:31 ` Alan Cox
2000-01-28 14:40 ` Tony Gale
2000-01-28 14:54 ` Alan Cox
2000-01-28 12:24 ` Tom Leete
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox