All of lore.kernel.org
 help / color / mirror / Atom feed
From: Oleg Nesterov <oleg@redhat.com>
To: Joseph Salisbury <joseph.salisbury@canonical.com>
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>,
	JBottomley@parallels.com, Nagalakshmi.Nandigama@lsi.com,
	Sreekanth.Reddy@lsi.com, rientjes@google.com,
	akpm@linux-foundation.org, torvalds@linux-foundation.org,
	tj@kernel.org, tglx@linutronix.de, linux-kernel@vger.kernel.org,
	kernel-team@lists.ubuntu.com, linux-scsi@vger.kernel.org,
	Tomas Henzl <thenzl@redhat.com>
Subject: Re: please fix FUSION (Was: [v3.13][v3.14][Regression] kthread:makekthread_create()killable)
Date: Fri, 21 Mar 2014 19:34:43 +0100	[thread overview]
Message-ID: <20140321183443.GA3891@redhat.com> (raw)
In-Reply-To: <20140320192307.GA11883@redhat.com>

On 03/20, Oleg Nesterov wrote:
>
> On 03/20, Joseph Salisbury wrote:
> >
> > There was some testing done with your test kernel.  The data collected
> > while running your kernel is available in the bug report:
> > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705/comments/58
>
> Joseph, thanks a lot.
>
> I'll try to read the logs tomorrow, but at first glance Tetsuo was right,
> I do not see a "long" sleep in that log.

Yes, it seems that it actually needs > 30 secs. It spends most of the time
(30.13286 seconds) in

	msleep+0x20/0x30
	WaitForDoorbellInt+0x103/0x130 [mptbase]
	WaitForDoorbellReply+0x42/0x220 [mptbase]
	mpt_handshake_req_reply_wait+0x1dc/0x2c0 [mptbase]
	SendPortEnable.constprop.23+0x94/0xc0 [mptbase]

WaitForDoorbellInt() does msleep(1) in a loop. This trace starts at the line
6001, and it is repeated 3792 times, till the line 176686 which apparently
shows the trace of the 2nd WaitForDoorbellInt() in WaitForDoorbellReply().

SendPortEnable:

	if (ioc->ir_firmware || ioc->bus_type == SAS) {
		rc = mpt_handshake_req_reply_wait(ioc, req_sz,
		(u32*)&port_enable, reply_sz, (u16*)&reply_buf,
		300 /*seconds*/, sleepFlag);
	} else {
		rc = mpt_handshake_req_reply_wait(ioc, req_sz,
		(u32*)&port_enable, reply_sz, (u16*)&reply_buf,
		30 /*seconds*/, sleepFlag);
	}

I am wondering which branch calls mpt_handshake_req_reply_wait(), the
else's timeout=30 (passed to the 1st WaitForDoorbellInt) suspiciously
matches the time WaitForDoorbellInt() actually runs... But everything
works fine and at first glance the potential timeout error should be
propogated correctly. So "timeout" is probably 300. And probably this
all is fine.

All I can suggest is the dirty hack for now. User-space should be
changed too, I think, but this is another story.

Tetsuo, what do you think?

Oleg.
---


--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -5395,6 +5395,8 @@ static struct pci_driver mptsas_driver = {
 #endif
 };
 
+#include <linux/signal.h>
+
 static int __init
 mptsas_init(void)
 {
@@ -5424,7 +5426,31 @@ mptsas_init(void)
 	mpt_event_register(mptsasDoneCtx, mptsas_event_process);
 	mpt_reset_register(mptsasDoneCtx, mptsas_ioc_reset);
 
-	error = pci_register_driver(&mptsas_driver);
+	{
+		sigset_t full, save;
+		/*
+		 * KILL ME. THIS IS THE DIRTY AND WRONG HACK WAITING FOR THE
+		 * FIX FROM MAINTAINERS.
+		 *
+		 * - This driver needs a lot of time to complete SendPortEnable()
+		 *   but systemd-udevd sends SIGKILL after 30 seconds, see
+		 *   https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1276705
+		 *
+		 *   Probably user-space should be changed, but:
+		 *
+		 * - Since commit 786235eeba0e "kthread: make kthread_create()
+		 *   killable" scsi_host_alloc() becomes killable and this SIGKILL
+		 *   crashes the kernel.
+		 *
+		 *   If scsi_host_alloc() fails mptsas_probe() blindly calls
+		 *   mptscsih_remove() and scsi_remove_host() hits host == NULL.
+		 */
+		sigfillset(&full);
+		sigprocmask(SIG_SETMASK, &full, &save);
+		error = pci_register_driver(&mptsas_driver);
+		sigprocmask(SIG_SETMASK, &save, NULL);
+	}
+
 	if (error)
 		sas_release_transport(mptsas_transport_template);
 

  reply	other threads:[~2014-03-21 18:34 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-14 20:46 [v3.13][v3.14][Regression] kthread: make kthread_create() killable Joseph Salisbury
2014-03-15  0:43 ` Tetsuo Handa
2014-03-16 15:13   ` Tetsuo Handa
2014-03-16 16:25     ` Oleg Nesterov
2014-03-17 12:38       ` [v3.13][v3.14][Regression] kthread: make kthread_create()killable Tetsuo Handa
2014-03-17 14:22         ` Oleg Nesterov
2014-03-18 12:03           ` [v3.13][v3.14][Regression] kthread: makekthread_create()killable Tetsuo Handa
2014-03-18 17:16             ` Oleg Nesterov
2014-03-19 11:49               ` [v3.13][v3.14][Regression] kthread:makekthread_create()killable Tetsuo Handa
2014-03-19 16:13                 ` Joseph Salisbury
2014-03-19 17:52                   ` Oleg Nesterov
2014-03-19 18:29                     ` please fix FUSION (Was: [v3.13][v3.14][Regression] kthread:makekthread_create()killable) Oleg Nesterov
2014-03-19 19:42                       ` Oleg Nesterov
2014-03-19 21:04                         ` Joseph Salisbury
2014-03-20 16:46                         ` Joseph Salisbury
2014-03-20 19:23                           ` Oleg Nesterov
2014-03-21 18:34                             ` Oleg Nesterov [this message]
2014-03-21 19:32                               ` Linus Torvalds
2014-03-21 20:31                                 ` Oleg Nesterov
2014-03-21 22:56                                 ` James Bottomley
2014-03-22  6:25                               ` please fix FUSION (Was: [v3.13][v3.14][Regression]kthread:makekthread_create()killable) Tetsuo Handa
2014-03-22 19:25                                 ` Oleg Nesterov
2014-03-22 20:48                                   ` James Bottomley
2014-03-24 17:01                                     ` Oleg Nesterov
2014-03-22 21:25                                   ` Thomas Gleixner
2014-03-22 22:01                                     ` Thomas Gleixner
2014-03-22 23:57                                       ` please fix FUSION (Was:[v3.13][v3.14][Regression]kthread:makekthread_create()killable) Tetsuo Handa
2014-03-23  8:04                                         ` Thomas Gleixner
2014-03-23 14:19                                           ` James Bottomley
2014-03-23 14:28                                             ` Thomas Gleixner
2014-03-23 14:29                                               ` James Bottomley
2014-03-22 23:50                                   ` Tetsuo Handa
2014-03-17 20:02 ` [v3.13][v3.14][Regression] kthread: make kthread_create() killable Andrew Morton
2014-03-17 20:19   ` Oleg Nesterov
2014-03-17 20:39     ` Andrew Morton
2014-03-18 17:45       ` Oleg Nesterov
2014-06-03 13:03     ` [PATCH] kthread: Fix return value of kthread_create() upon SIGKILL Tetsuo Handa
2014-06-03 21:35       ` David Rientjes
2014-03-17 21:32   ` [v3.13][v3.14][Regression] kthread: make kthread_create()killable Tetsuo Handa
2014-03-17 23:18   ` [v3.13][v3.14][Regression] kthread: make kthread_create() killable One Thousand Gnomes
2014-03-18 17:50     ` Oleg Nesterov

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=20140321183443.GA3891@redhat.com \
    --to=oleg@redhat.com \
    --cc=JBottomley@parallels.com \
    --cc=Nagalakshmi.Nandigama@lsi.com \
    --cc=Sreekanth.Reddy@lsi.com \
    --cc=akpm@linux-foundation.org \
    --cc=joseph.salisbury@canonical.com \
    --cc=kernel-team@lists.ubuntu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=penguin-kernel@I-love.SAKURA.ne.jp \
    --cc=rientjes@google.com \
    --cc=tglx@linutronix.de \
    --cc=thenzl@redhat.com \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.