public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* stack overflow on Sparc64
@ 2008-06-18  0:47 Mikulas Patocka
  2008-06-18  4:01 ` David Miller
  0 siblings, 1 reply; 43+ messages in thread
From: Mikulas Patocka @ 2008-06-18  0:47 UTC (permalink / raw)
  To: sparclinux, linux-kernel; +Cc: Alasdair G Kergon

Hi

I am getting stack overflows on my Sparc64 station. They happen when I 
copy to device-mapper snapshot origin device using small IO size (512 
bytes) and simultaneously execute "lvs" command. The kernel is compiled 
with most debugging functions enabled. The stack trace is this:

__ide_end_request
__blk_end_request
__end_that_request_first
req_bio_endio
bio_endio
clone_endio
dec_pending
bio_endio
clone_endio
dec_pending
bio_endio
clone_endio
dec_pending
bio_endio
end_bio_bh_io_sync
end_buffer_read_sync
__end_buffer_read_notouch
unlock_buffer
wake_up_bit
__wake_up_bit
__wake_up
__wake_up_common
wake_bit_function
autoremove_wake_function
default_wake_function
try_to_wake_up
task_rq_lock
__spin_lock
lock_acquire
__lock_acquire
*** crash, stack overflow

--- observations:

That loop bio_endio->clone_endio->dec_pending is repeating for each level 
of nested devices --- so for any architecture there exists a level at 
which it causes trouble. We need something to prevent recursion, maybe the 
similar trick that was done with avoing bio request function recursion 
(i.e. if bio_endio is called recursively, it just adds the bio to queue 
and lets the top level to call endio method).

Wait queue waking looks like being written by a high-level maniac --- it 
contains 8 levels of calls (none of them inlined). 7 of these calls (until 
try_to_wake_up) do nothing but pass arguments to lower level call. And 
each of these calls allocate at least 192 bytes of stack space. All these 
7 useless calls consume 1360 bytes of stack (and cause windows traps that 
needlessly damage performance). Would you agree to inline most of the 
calls to save stack? Or do you see another solution?

Long-term consideration: Is it possible to implement interrupt stacks on 
sparc64? Functions on sparc eat stack much more aggressively than on other 
architectures (minimum stack size for a function is 192 bytes).

Mikulas

^ permalink raw reply	[flat|nested] 43+ messages in thread

end of thread, other threads:[~2008-08-15 21:13 UTC | newest]

Thread overview: 43+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-18  0:47 stack overflow on Sparc64 Mikulas Patocka
2008-06-18  4:01 ` David Miller
2008-06-19  3:24   ` Mikulas Patocka
2008-06-19  3:59     ` David Miller
2008-06-19  5:17       ` Mikulas Patocka
2008-06-19  6:37         ` David Miller
2008-06-19 13:01           ` Mikulas Patocka
2008-06-20 15:47   ` Mikulas Patocka
2008-06-20 17:26     ` David Miller
2008-06-20 20:34       ` Mikulas Patocka
2008-06-20 20:37         ` David Miller
2008-06-20 21:26           ` Mikulas Patocka
2008-06-20 21:41             ` David Miller
2008-06-21  4:51               ` David Miller
2008-06-21 19:42                 ` Mikulas Patocka
2008-06-22  7:03                   ` David Miller
2008-06-22 13:48                     ` Mikulas Patocka
2008-08-12  6:30                   ` David Miller
2008-08-12  8:22                     ` David Miller
2008-08-13  0:53                       ` Mikulas Patocka
2008-08-13  0:59                         ` David Miller
2008-08-13  1:11                     ` console handover badness [was: stack overflow on Sparc64] Mikulas Patocka
2008-08-13  1:22                       ` console handover badness David Miller
2008-08-13  1:40                       ` David Miller
2008-08-13  8:50                         ` David Miller
2008-08-13 12:46                         ` Mikulas Patocka
2008-08-14  3:25                           ` David Miller
2008-08-14 23:11                             ` Bootmem allocator broken [was: console handover badness] Mikulas Patocka
2008-08-14 23:25                               ` Bootmem allocator broken David Miller
2008-08-15 11:09                                 ` Alexander Beregalov
2008-08-15 21:13                                   ` David Miller
2008-08-14 23:40                               ` Johannes Weiner
2008-06-20 21:14       ` stack overflow on Sparc64 Mikulas Patocka
2008-06-20 21:20         ` David Miller
2008-06-20 21:25           ` Mikulas Patocka
2008-06-20 21:44             ` David Miller
2008-06-20 21:47               ` David Miller
2008-06-20 22:22                 ` Mikulas Patocka
2008-06-20 22:28                   ` David Miller
2008-06-20 22:36                     ` Mikulas Patocka
2008-06-20 22:47                       ` David Miller
2008-06-21  0:37                         ` Mikulas Patocka
2008-06-20 22:33               ` Mikulas Patocka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox