linux-kernel - Re: [Regression, bisected 9e30cc] "sysfs, kernfs: no need to kern_mount() sysfs from sysfs_init()" prevents system from booting correctly

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140314140804.GG12613@htj.dyndns.org>
Date:	Fri, 14 Mar 2014 10:08:04 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Alexandre Demers <alexandre.f.demers@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [Regression, bisected 9e30cc] "sysfs, kernfs: no need to
 kern_mount() sysfs from sysfs_init()" prevents system from booting correctly

Hello, Alexandre.

On Fri, Mar 14, 2014 at 09:27:35AM -0400, Alexandre Demers wrote:
> I was told to send this bug
> (https://bugzilla.kernel.org/show_bug.cgi?id=72061) directly by email.
> 
> So, I've been struggling with something that looks like a bug, but I
> may be wrong. Since 3.14-rc1 up until yesterday's latest commit, I
> can't boot my system correctly. The kernel will boot, but when it
> comes to mounting the disk's partitions, the computer seem to hit
> something while mounting the root partition: the light associated to
> the disk's activity stays on; if I hit ctrl+alt+del in the first 10 to
> 15 seconds, the computer will restart; beyond that point, the system
> just continues to work on the disk for a long period (I was painting a
> door the other day and it continued reading or writing the whole time)
> until it begins outputting errors. I'll have to add it in another
> comment later. It is about not being able to copy because disk is full
> (my partitions have plenty of free space). So I've been bisecting
> until I found out when the problem had begun.
> 
> ------
> Bisecting points to the following first bad commit:
> 9e30cc9595303b27b48be49b7bcd4d0679e34253 is the first bad commit
> commit 9e30cc9595303b27b48be49b7bcd4d0679e34253
> Author: Tejun Heo <tj@...nel.org>
> Date:   Thu Nov 28 14:54:38 2013 -0500
> 
>     sysfs, kernfs: no need to kern_mount() sysfs from sysfs_init()
> 
>     It has been very long since sysfs depended on vfs to keep track of
>     internal states and whether sysfs is mounted or not doesn't make any
>     difference to sysfs's internal operation.
> 
>     In addition to init and filesystem type registration, sysfs_init()
>     invokes kern_mount() to create in-kernel mount of sysfs.  This
>     internal mounting doesn't server any purpose anymore.  Remove it.
> 
>     Signed-off-by: Tejun Heo <tj@...nel.org>
>     Signed-off-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> 
> :040000 040000 d85991e8a4e333ad651dc593cacff5e6b8d4f916
> d3bd9c50967807c9145a7bd9d3ec7978101c93f3 M fs
> ------
> 
> Using any kernel compiled before that commit boots fine. Am I missing something?

Hah, that's interesting and completely unexpected.  What userland are
you using?  Also, after such failure fills up the filesystem, can you
determine which files are filling it up?  We'll need to restore the
original behavior but need to first find out how userland depends on
it at all.

Thanks.

-- 
tejun
--
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/