linux-kernel - Re: module: fix module_refcount() return when running in a module exit routine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 29 Jan 2015 13:16:37 +0100
From:	Bart Van Assche <bart.vanassche@...disk.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
CC:	Christoph Hellwig <hch@...radead.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-scsi <linux-scsi@...r.kernel.org>
Subject: Re: module: fix module_refcount() return when running in a module
 exit routine

On 01/28/15 22:45, James Bottomley wrote:
> On Wed, 2015-01-28 at 10:23 +0100, Bart Van Assche wrote:
>> Is this the latest version of this patch that is available ? I have
>> tried to test the above patch. However, I couldn't test the impact of
>> this patch on the SRP initiator driver since my test system didn't boot
>> anymore with the above patch applied. That test system boots from an ATA
>> disk managed by the SCSI subsystem:
>> $ lsscsi | head -n1
>> [0:0:0:0]    disk    ATA      KINGSTON SH103S3 BBF0  /dev/sda
> 
> Not yet, since I knew it would need a bit of testing to identify all the
> potential in_exit acquisitions.  However, you could help me by
> diagnosing the current failure.

Hello James,

I have done the following:
- Read over your patch but didn't spot anything obvious.
- Added printk() statements in the modified functions in an attempt to
  determine where in the boot process the hang occurs. Apparently none
  of the functions touched by this patch got called before the hang
  occurred.
- Uploaded a screenshot of the boot messages
(https://drive.google.com/file/d/0B1YQOreL3_FxN1pPMnZrSDdLYTQ/view?usp=sharing).
The most remarkable message is "SATA link down". This message does not
appear when booting e.g. kernel version v3.16.
- Left the system alone for a few minutes after the boot process
  stopped making progress. The message "boot drive not found" appeared.

So this is probably an issue in another component than the SCSI
subsystem. What's not clear to me is why every time I tried to boot
without this patch that booting succeeded and every time I tried to boot
with this patch applied that booting did not succeed ... I have not yet
had the time to run a bisect.

Note: the tests I ran today were performed with kernel v3.19-rc6 with
patch https://lkml.org/lkml/2015/1/28/334 applied. However, that last
patch shouldn't have any impact on the boot process since
CONFIG_SCSI_MQ_DEFAULT was not set.

Bart.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/