On Sat, Feb 15, 2014 at 03:50:29PM -0800, Linus Torvalds wrote:
> [ Added linux-mm to the participants list ]
>
> On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner wrote:
> >
> > Dave, the patch below should chop off the stack usage from
> > xfs_log_force_lsn() issuing IO by deferring it to the CIL w
On Mon, Feb 17, 2014 at 06:46:48PM +0100, Oleg Nesterov wrote:
> > pulling the logics *out* of kernel/signal.c and into arch/*.
>
> Not really, I think.
How so? You propose to make all architectures call do_coredump()
themselves, instead of having it done centrally. It's more boilerplate
for al
On 02/17, Al Viro wrote:
>
> On Mon, Feb 17, 2014 at 05:57:35PM +0100, Oleg Nesterov wrote:
>
> > Looks like, this is all is really nasty. Actually, I think siginfo on
> > stack is not that bad if we are going to do handle_signal() or restart,
> > perhaps we can do the extra kmalloc/memcpy/kfree fo
On Mon, Feb 17, 2014 at 05:57:35PM +0100, Oleg Nesterov wrote:
> Looks like, this is all is really nasty. Actually, I think siginfo on
> stack is not that bad if we are going to do handle_signal() or restart,
> perhaps we can do the extra kmalloc/memcpy/kfree for do_coredump().
> Something like be
On 02/15, Oleg Nesterov wrote:
>
> On 02/15, Al Viro wrote:
> >
> > On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > > > So basically we want a different condition for "can we just go ahead and
> > > > free that sucker", right? Instead of "it's on the list, shan't free it"
> > >
[ Added linux-mm to the participants list ]
On Thu, Feb 13, 2014 at 4:24 PM, Dave Chinner wrote:
>
> Dave, the patch below should chop off the stack usage from
> xfs_log_force_lsn() issuing IO by deferring it to the CIL workqueue.
> Can you given this a run?
Ok, so DaveJ confirmed that DaveC's p
On Sat, Feb 15, 2014 at 2:28 PM, Dave Jones wrote:
>
> I've got a shitload of debug options enabled, which may explain it.
> Or perhaps that new STACK_PROTECTOR_STRONG stuff ?
Well, a lot of it is just the callee-saved registers. The compiler
will tend to preferentially allocate registers in the
On Sun, Feb 16, 2014 at 09:23:56AM +1100, Dave Chinner wrote:
> There's a pretty massive difference between the actual stack usage
> of the local variables and the amount of stack being used by the
> compiled code.
>
> What it appears to be is that the compiler is pushing 6-10 registers
>
On Fri, Feb 14, 2014 at 11:01:23AM -0500, Dave Jones wrote:
> On Fri, Feb 14, 2014 at 11:24:27AM +1100, Dave Chinner wrote:
>
> > > I can fix this one easily - we already have a workqueue for doing
> > > async log pushes (will split the stack between xlog_cil_force_lsn
> > > and xlog_cil_push)
On 02/15, Al Viro wrote:
>
> On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > > So basically we want a different condition for "can we just go ahead and
> > > free that sucker", right? Instead of "it's on the list, shan't free it"
> > > it ought to be something like "it's on the
On Sat, Feb 15, 2014 at 06:43:45PM +0100, Oleg Nesterov wrote:
> > So basically we want a different condition for "can we just go ahead and
> > free that sucker", right? Instead of "it's on the list, shan't free it"
> > it ought to be something like "it's on the list or it is referenced by
> > ksi
On 02/15, Al Viro wrote:
>
> > Ouch... I think I see what you mean. Let me see if I got it right:
> > timer->sigq is *not* freed by collect_signal(); it's done by
> > release_posix_timer() instead, under siglock. Frankly, this
> > /*
> > * If it is queued it will be freed when d
On Sat, Feb 15, 2014 at 03:58:38PM +, Al Viro wrote:
> BTW, I really wonder how does that stuff interact with PTRACE_SETSIGINFO.
> What happens if tracer does PTRACE_GETSIGINFO, changes ->si_signo to
> something blocked, shoves it back with PTRACE_SETSIGINFO and does
> PTRACE_CONT with that ne
On Sat, Feb 15, 2014 at 03:36:31PM +, Al Viro wrote:
> On Sat, Feb 15, 2014 at 03:22:51PM +, Al Viro wrote:
> > On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
> >
> > > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> > >
> > >Once get_signal_to_deliver() or any
On Sat, Feb 15, 2014 at 03:22:51PM +, Al Viro wrote:
> On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
>
> > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> >
> >Once get_signal_to_deliver() or any other caller drops ->siglock
> >another thread can do sys_timer_
On 02/15, Al Viro wrote:
>
> On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
>
> > 1. info->q can be already freed if SIGQUEUE_PREALLOC.
> >
> >Once get_signal_to_deliver() or any other caller drops ->siglock
> >another thread can do sys_timer_delete()->sigqueue_free().
>
> H
On Sat, Feb 15, 2014 at 03:27:00PM +0100, Oleg Nesterov wrote:
> 1. info->q can be already freed if SIGQUEUE_PREALLOC.
>
>Once get_signal_to_deliver() or any other caller drops ->siglock
>another thread can do sys_timer_delete()->sigqueue_free().
How the devil would it find the sucker?
On 02/14, Christoph Hellwig wrote:
>
> Might aswell stick the discmiss into what was dequeue_signal_lock().
> Which at that point should get a saner name (maybe thread_dequeue_signal ?)
> and lose all argument except maybe task_struct
No, task_struct argument should die, I think. It is misleading.
On 02/15, Al Viro wrote:
>
> OK, _very_ preliminary patch follows. It's uglier than it has to
And I'm afraid it needs more uglifications...
> +void dismiss_siginfo(ksiginfo_t *info)
> +{
> + if (info->q)
> + __sigqueue_free(info->q);
> + info->q = NULL;
> +}
1. info->q can b
On Thu, Feb 13, 2014 at 09:58:47AM -0800, Linus Torvalds wrote:
> On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov wrote:
> >
> > And we should be careful with SIGQUEUE_PREALLOC, at least
> > collect_signal() should not do list_del_init()... Plus we need to
> > handle the SEND_SIG_FORCED-like case.
On Fri, Feb 14, 2014 at 04:16:24PM +, Al Viro wrote:
> > All of these have in common that they try to handle signals in a kernel
> > thread (which we don't even allow by default), and that they ignore the
> > siginfo. I think they could mostly be replaced by an addition to the
> > kthread API
On Fri, Feb 14, 2014 at 04:16:24PM +, Al Viro wrote:
> FWIW, there's a funny situation - all users of dequeue_signal_lock()
> actually ignore info completely. I'm not saying that we ought to
> stop returning it, but e.g. jbd part of that patch is simply
s/jbd/jffs2/, obviously. Sorry... And
On Fri, Feb 14, 2014 at 08:13:02AM -0800, Christoph Hellwig wrote:
> On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> > We'd have to teach each user of "dequeue_signal()" to free the siginfo
> > thing. Which shouldn't be too bad - I think we've collected all of
> > that into generi
On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> We'd have to teach each user of "dequeue_signal()" to free the siginfo
> thing. Which shouldn't be too bad - I think we've collected all of
> that into generic code, and there isn't the mass or architecture code
> that knows about th
On 02/14, Al Viro wrote:
>
> BTW, Oleg, could you explain why does PTRACE_PEEK_SIGINFO copy ->si_code
> separately? IOW, why do we want the upper 16 bits of ->si_code exposed?
> It used to be a strictly internal thing IIRC (it's been what, 2.3.late?)
Yes, but checkpoint/restart tools want to dump
On Fri, Feb 14, 2014 at 11:24:27AM +1100, Dave Chinner wrote:
> > I can fix this one easily - we already have a workqueue for doing
> > async log pushes (will split the stack between xlog_cil_force_lsn
> > and xlog_cil_push), but the reason we haven't used it for synchronous
> > log forces is
On Fri, Feb 14, 2014 at 02:29:30PM +0100, Richard Weinberger wrote:
> Am 14.02.2014 14:25, schrieb Christoph Hellwig:
> > On Thu, Feb 13, 2014 at 08:51:46PM +, Al Viro wrote:
> >> On Wed, Feb 12, 2014 at 09:44:11PM +, Al Viro wrote:
> >>
> >>> I'll try to put something along those lines tog
Am 14.02.2014 14:25, schrieb Christoph Hellwig:
> On Thu, Feb 13, 2014 at 08:51:46PM +, Al Viro wrote:
>> On Wed, Feb 12, 2014 at 09:44:11PM +, Al Viro wrote:
>>
>>> I'll try to put something along those lines together, if you or Oleg don't
>>> do it first.
>>
>> OK, having looked at that s
On Thu, Feb 13, 2014 at 08:51:46PM +, Al Viro wrote:
> On Wed, Feb 12, 2014 at 09:44:11PM +, Al Viro wrote:
>
> > I'll try to put something along those lines together, if you or Oleg don't
> > do it first.
>
> OK, having looked at that stuff...
>
> 1) things become much more compact if w
On Wed, Feb 12, 2014 at 06:18:29PM +1100, Dave Chinner wrote:
> > It looks like just "do_signal()" has a stack frame that is about 230
> > bytes even under normal circumstancs (largely due to "struct ksignal"
> > - which in turn is largely due to the insane 128-byte padding in
> > siginfo_t). Add a
On Thu, Feb 13, 2014 at 08:51:46PM +, Al Viro wrote:
> On Wed, Feb 12, 2014 at 09:44:11PM +, Al Viro wrote:
>
> > I'll try to put something along those lines together, if you or Oleg don't
> > do it first.
>
> OK, having looked at that stuff...
>
> 1) things become much more compact if w
On Wed, Feb 12, 2014 at 09:44:11PM +, Al Viro wrote:
> I'll try to put something along those lines together, if you or Oleg don't
> do it first.
OK, having looked at that stuff...
1) things become much more compact if we finish conversion to get_signal()
first. Callers of get_signal_to_deli
On 02/13, Oleg Nesterov wrote:
>
> On 02/13, Linus Torvalds wrote:
> >
> > On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov wrote:
> > >
> > > And we should be careful with SIGQUEUE_PREALLOC, at least
> > > collect_signal() should not do list_del_init()... Plus we need to
> > > handle the SEND_SIG_F
On 02/13, Linus Torvalds wrote:
>
> On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov wrote:
> >
> > And we should be careful with SIGQUEUE_PREALLOC, at least
> > collect_signal() should not do list_del_init()... Plus we need to
> > handle the SEND_SIG_FORCED-like case.
>
> I don't think the users ne
On Thu, Feb 13, 2014 at 9:40 AM, Oleg Nesterov wrote:
>
> And we should be careful with SIGQUEUE_PREALLOC, at least
> collect_signal() should not do list_del_init()... Plus we need to
> handle the SEND_SIG_FORCED-like case.
I don't think the users need to care. They'd just call
"sigqueue_free()"
On 02/12, Linus Torvalds wrote:
>
> On Wed, Feb 12, 2014 at 1:14 PM, Al Viro wrote:
> >
> > Umm... What if we delay __sigqueue_free()? After all, that's where the
> > fat sucker normally comes from. That way we might get away with much
> > smaller structure on stack...
>
> Sounds like the Right
On Wed, Feb 12, 2014 at 01:32:55PM -0800, Linus Torvalds wrote:
> On Wed, Feb 12, 2014 at 1:14 PM, Al Viro wrote:
> >
> > Umm... What if we delay __sigqueue_free()? After all, that's where the
> > fat sucker normally comes from. That way we might get away with much
> > smaller structure on stac
On Wed, Feb 12, 2014 at 1:14 PM, Al Viro wrote:
>
> Umm... What if we delay __sigqueue_free()? After all, that's where the
> fat sucker normally comes from. That way we might get away with much
> smaller structure on stack...
Sounds like the RightThing(tm) to do to me, and I don't see why it
w
On Wed, Feb 12, 2014 at 12:13:19PM -0800, Linus Torvalds wrote:
> On Wed, Feb 12, 2014 at 3:39 AM, Al Viro wrote:
> > On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> >
> >> It looks like just "do_signal()" has a stack frame that is about 230
> >> bytes even under normal circumsta
On Wed, Feb 12, 2014 at 09:25:38AM -0500, Dave Jones wrote:
> On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> > On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> > >
> > > > None of the XFS code di
On Wed, Feb 12, 2014 at 3:39 AM, Al Viro wrote:
> On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
>
>> It looks like just "do_signal()" has a stack frame that is about 230
>> bytes even under normal circumstancs (largely due to "struct ksignal"
>> - which in turn is largely due to
On 2/12/14, 12:10 AM, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
>> On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
>>
>> > None of the XFS code disables interrupts in that path, not does is
>> > call outside XFS except to dispatch IO. The stac
On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> >
> > > None of the XFS code disables interrupts in that path, not does is
> > > call outside XFS e
On Wed, Feb 12, 2014 at 07:40:36AM -0500, Steven Rostedt wrote:
> The pt_regs structure.
>
> That's what? 21 unsigned longs? 21 * 8 = 168. I think that's the
> culprit here.
>
> Peter and Frederic, is there a way not to store that on the stack?
Something like so?
---
include/trace/ftrace.h
On Wed, 12 Feb 2014 19:35:13 +1100
Dave Chinner wrote:
> And it's leaf functions that the CONFIG_STACK_TRACER doesn't catch
> on x86-64 (at least, according to the documentation).
> CONFIG_DEBUG_STACK_USAGE output is showing up to 800 bytes more
> stack usage than the tracer. As such, I also thi
On Wed, 12 Feb 2014 03:13:33 -0500
Tejun Heo wrote:
> On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> > There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> > all seem to be of the type perf_trace_block_buffer() - things created
> > with DECLARE_EVENT_CLASS(),
[ Added the perf tracepoint maintainers ]
On Tue, 11 Feb 2014 22:59:58 -0800
Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner wrote:
> >
> > FYI, just creating lots of files with open(O_CREAT):
> >
> > [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes lef
On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> It looks like just "do_signal()" has a stack frame that is about 230
> bytes even under normal circumstancs (largely due to "struct ksignal"
> - which in turn is largely due to the insane 128-byte padding in
> siginfo_t). Add a few
On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner wrote:
> >
> > FYI, just creating lots of files with open(O_CREAT):
> >
> > [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
> > [ 348.769846] fs_mark (4814) us
On Tue, Feb 11, 2014 at 10:59:58PM -0800, Linus Torvalds wrote:
> There's a lot of 200+ byte stack frames in block/blk-core.s, and they
> all seem to be of the type perf_trace_block_buffer() - things created
> with DECLARE_EVENT_CLASS(), afaik. Why they all have 200+ bytes of
> frame, I have no ide
On Tue, Feb 11, 2014 at 10:28:12PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner wrote:
> >
> > None of the XFS code disables interrupts in that path, not does is
> > call outside XFS except to dispatch IO. The stack is pretty deep at
> > this point and I know that t
On Tue, Feb 11, 2014 at 10:31 PM, Dave Chinner wrote:
>
> FYI, just creating lots of files with open(O_CREAT):
>
> [ 348.718357] fs_mark (4828) used greatest stack depth: 2968 bytes left
> [ 348.769846] fs_mark (4814) used greatest stack depth: 2312 bytes left
> [ 349.17] fs_mark (4826) use
On Wed, Feb 12, 2014 at 05:10:38PM +1100, Dave Chinner wrote:
> On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> > On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> >
> > > None of the XFS code disables interrupts in that path, not does is
> > > call outside XFS except
On Tue, Feb 11, 2014 at 9:40 PM, Dave Chinner wrote:
>
> None of the XFS code disables interrupts in that path, not does is
> call outside XFS except to dispatch IO. The stack is pretty deep at
> this point and I know that the standard (non stacked) IO stack can
> consume >3kb of stack space when
On Wed, Feb 12, 2014 at 12:50:27AM -0500, Dave Jones wrote:
> On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
>
> > None of the XFS code disables interrupts in that path, not does is
> > call outside XFS except to dispatch IO. The stack is pretty deep at
> > this point and I know
On Wed, Feb 12, 2014 at 04:40:43PM +1100, Dave Chinner wrote:
> None of the XFS code disables interrupts in that path, not does is
> call outside XFS except to dispatch IO. The stack is pretty deep at
> this point and I know that the standard (non stacked) IO stack can
> consume >3kb of stack
On Wed, Feb 12, 2014 at 04:22:15AM +, Al Viro wrote:
> On Tue, Feb 11, 2014 at 11:03:58PM -0500, Dave Jones wrote:
> > [ 3111.414202] [] bio_alloc_bioset+0x156/0x210
> > [ 3111.414855] [] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> > [ 3111.415517] [] ? xlog_bdstrat+0x22/0x60 [xfs]
> > [ 3111.41617
On Tue, Feb 11, 2014 at 11:03:58PM -0500, Dave Jones wrote:
> [ 3111.414202] [] bio_alloc_bioset+0x156/0x210
> [ 3111.414855] [] _xfs_buf_ioapply+0x1c1/0x3c0 [xfs]
> [ 3111.415517] [] ? xlog_bdstrat+0x22/0x60 [xfs]
> [ 3111.416175] [] xfs_buf_iorequest+0x6b/0xf0 [xfs]
> [ 3111.416843] [] xlog_
On Tue, Feb 11, 2014 at 06:52:19PM -0800, Linus Torvalds wrote:
> On Tue, Feb 11, 2014 at 5:09 PM, Al Viro wrote:
> >
> > Slap the check in vfs_create(), see if interrupts had been disabled by it
> > or
> > by something in ->create(). Since it's reproducible...
>
> path_openat() starts o
On Tue, Feb 11, 2014 at 5:09 PM, Al Viro wrote:
>
> Slap the check in vfs_create(), see if interrupts had been disabled by it or
> by something in ->create(). Since it's reproducible...
path_openat() starts off with a get_empty_filp(), which allocates a
file pointer with GFP_KERNEL. So that shou
On Tue, Feb 11, 2014 at 07:44:03PM -0500, Dave Jones wrote:
> The 'good' news is I seem to be able to reproduce it fairly quickly.
> I've seen it 3-4 times this afternoon. (Always from the coredump path)
>
> I was on vacation last week, but I wasn't hitting this before then, so it's a
> fairly re
On Tue, Feb 11, 2014 at 03:49:14PM -0600, Eric Sandeen wrote:
> On 2/11/14, 3:08 PM, Dave Chinner wrote:
> > On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
> >> BUG: sleeping function called from invalid context at mm/mempool.c:203
> >> in_atomic(): 0, irqs_disabled(): 1, pid: 2751
On 2/11/14, 3:08 PM, Dave Chinner wrote:
> On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
>> BUG: sleeping function called from invalid context at mm/mempool.c:203
>> in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
>> 5 locks held by trinity-c3/27511:
>> #0: (sb_writ
On Tue, Feb 11, 2014 at 12:27:07PM -0500, Dave Jones wrote:
> BUG: sleeping function called from invalid context at mm/mempool.c:203
> in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
> 5 locks held by trinity-c3/27511:
> #0: (sb_writers#9){..}, at: []
> mnt_want_write+0x24/0
BUG: sleeping function called from invalid context at mm/mempool.c:203
in_atomic(): 0, irqs_disabled(): 1, pid: 27511, name: trinity-c3
5 locks held by trinity-c3/27511:
#0: (sb_writers#9){..}, at: [] mnt_want_write+0x24/0x50
#1: (&type->i_mutex_dir_key#3){..}, at: []
do_last.isra.51+0
65 matches
Mail list logo
