On (03/22/16 15:57), Byungchul Park wrote:
> On Tue, Mar 22, 2016 at 02:52:43PM +0900, Sergey Senozhatsky wrote:
> > On (03/22/16 11:13), Byungchul Park wrote:
> > [..]
> >
> > what about a "normal" case, when things are not going to explode printk(),
> > but we have several lockups on the same lo
On Tue, Mar 22, 2016 at 02:52:43PM +0900, Sergey Senozhatsky wrote:
> On (03/22/16 11:13), Byungchul Park wrote:
> [..]
>
> what about a "normal" case, when things are not going to explode printk(),
> but we have several lockups on the same lock (which is probably more
> likely than printk recursi
On (03/22/16 11:13), Byungchul Park wrote:
[..]
what about a "normal" case, when things are not going to explode printk(),
but we have several lockups on the same lock (which is probably more
likely than printk recursion)?
suppose:
- there are 8 CPUs on the system
- 1 cpus owns the spin_lock for
On Tue, Mar 22, 2016 at 02:11:05AM +0900, Sergey Senozhatsky wrote:
> On (03/21/16 16:33), Jan Kara wrote:
> [..]
> > > > And by calling wake_up_process() under logbuf_lock, you actually
> > > > introduce
> > > > recursion issues for printk_deferred() messages which are supposed to be
> > > > work
On Mon, Mar 21, 2016 at 06:28:48PM +0900, Sergey Senozhatsky wrote:
> > Just to be sure, whether you take my suggestion or not is not important.
> > I just suggested it in this thread since it can solve what you worried
> > about. That's all. I can post it in another thread though. Why don't you
>
On (03/21/16 16:33), Jan Kara wrote:
[..]
> > > And by calling wake_up_process() under logbuf_lock, you actually introduce
> > > recursion issues for printk_deferred() messages which are supposed to be
> > > working from under rq->lock and similar. So I think you have to keep this
> > > section out
On Mon 21-03-16 23:58:32, Sergey Senozhatsky wrote:
> Hello Jan,
>
> On (03/21/16 15:32), Jan Kara wrote:
> [..]
> > > we have 2 spin locks in vprintk_emit() -- logbuf_lock and sem->lock. and N
> > > CPUs can concurrently lockup on those two locks, which already makes a
> > > single static pointer
Hello Jan,
On (03/21/16 15:32), Jan Kara wrote:
[..]
> > we have 2 spin locks in vprintk_emit() -- logbuf_lock and sem->lock. and N
> > CPUs can concurrently lockup on those two locks, which already makes a
> > single static pointer in spiun_dump() questionable.
> >
> > logbug_lock *theoretically
On Mon 21-03-16 18:28:48, Sergey Senozhatsky wrote:
> On (03/21/16 17:47), Byungchul Park wrote:
> [..]
> > > Is there any reason why you don't put the wake_up_process() out of the
> > > critical section with my suggestion, even though it can solve the infinite
> > > recuresion you worried about?
>
On (03/21/16 17:47), Byungchul Park wrote:
[..]
> > Is there any reason why you don't put the wake_up_process() out of the
> > critical section with my suggestion, even though it can solve the infinite
> > recuresion you worried about?
>
> Just to be sure, whether you take my suggestion or not is
On (03/21/16 17:07), Byungchul Park wrote:
[..]
> > > > > It will not print the "lockup suspected" message at all, for e.g.
> > > > > rq->lock,
> > > > > p->pi_lock and any locks which are used within wake_up_process().
> > > >
> > > > this will switch to old SYNC printk() mode should such a lock
On Mon, Mar 21, 2016 at 05:07:51PM +0900, Byungchul Park wrote:
> On Mon, Mar 21, 2016 at 04:35:07PM +0900, Sergey Senozhatsky wrote:
> > On (03/21/16 09:56), Byungchul Park wrote:
> > > > > > + if (!sync_print) {
> > > > > > + if (in_sched) {
> > > > > > + /*
> > > >
On Mon, Mar 21, 2016 at 04:35:07PM +0900, Sergey Senozhatsky wrote:
> On (03/21/16 09:56), Byungchul Park wrote:
> > > > > + if (!sync_print) {
> > > > > + if (in_sched) {
> > > > > + /*
> > > > > + * @in_sched messages may come too early, wh
On (03/21/16 09:56), Byungchul Park wrote:
> > > > + if (!sync_print) {
> > > > + if (in_sched) {
> > > > + /*
> > > > +* @in_sched messages may come too early, when
> > > > we don't
> > > > +* yet have @prin
On Mon, Mar 21, 2016 at 09:43:47AM +0900, Sergey Senozhatsky wrote:
> On (03/21/16 09:06), Byungchul Park wrote:
> > On Sun, Mar 20, 2016 at 11:13:10PM +0900, Sergey Senozhatsky wrote:
> [..]
> > > + if (!sync_print) {
> > > + if (in_sched) {
> > > + /*
> > > +
On (03/21/16 09:06), Byungchul Park wrote:
> On Sun, Mar 20, 2016 at 11:13:10PM +0900, Sergey Senozhatsky wrote:
[..]
> > + if (!sync_print) {
> > + if (in_sched) {
> > + /*
> > +* @in_sched messages may come too early, when we don't
> > +
On Sun, Mar 20, 2016 at 11:13:10PM +0900, Sergey Senozhatsky wrote:
> @@ -1748,13 +1872,42 @@ asmlinkage int vprintk_emit(int facility, int level,
>dict, dictlen, text, text_len);
> }
>
> + /*
> + * By default we print message to cons
From: Jan Kara
Currently, printk() sometimes waits for message to be printed to console
and sometimes it does not (when console_sem is held by some other
process). In case printk() grabs console_sem and starts printing to
console, it prints messages from kernel printk buffer until the buffer
is e
18 matches
Mail list logo
