linux-kernel - Re: partition sysfs OOPS in current GIT

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: <20080206155749.ce1fcd25.akpm@linux-foundation.org>
Date:	Wed, 6 Feb 2008 15:57:49 -0800
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Greg KH <gregkh@...e.de>
Cc:	davem@...emloft.net, linux-kernel@...r.kernel.org,
	kay.sievers@...y.org
Subject: Re: partition sysfs OOPS in current GIT

On Wed, 6 Feb 2008 15:31:17 -0800
Greg KH <gregkh@...e.de> wrote:

> On Wed, Feb 06, 2008 at 03:26:39PM -0800, David Miller wrote:
> > 
> > I get the following OOPS from udevd during bootup on
> > sparc64:
> > 
> > [    0.982046]               \|/ ____ \|/
> > [    0.982054]               "@'/ .. \`@"
> > [    0.982058]               /_| \__/ |_\
> > [    0.982063]                  \__U_/
> > [    0.982482] udevd(1305): Kernel illegal instruction [#1]
> > [    0.982550] TSTATE: 0000004411001602 TPC: 00000000007ddb80 TNPC: 00000000007ddb84 Y: 00000000    Not tainted
> > [    0.982647] TPC: <0x7ddb88>
> > [    0.982684] g0: 0000000000000000 g1: 00000000007ddb80 g2: 0000000000000000 g3: 0000000000000000
> > [    0.982760] g4: fffff803fb332a00 g5: fffff8000f8a6000 g6: fffff803fb3a8000 g7: fffff803fc893724
> > [    0.982831] o0: fffff803fc8bc010 o1: 00000000007ddb58 o2: fffff803fbba0000 o3: fffff803fb3abd48
> > [    0.982907] o4: 0000000000040001 o5: 0000000000000000 sp: fffff803fb3ab391 ret_pc: 00000000005b7524
> > [    0.982984] RPC: <dev_attr_show+0x24/0x30>
> > [    0.983016] l0: 0000000000000000 l1: 0000000000000000 l2: fffff803fc9a5308 l3: 000000000005a000
> > [    0.983074] l4: 0000000000000004 l5: fffff803fb340b00 l6: 0000000000000168 l7: fffff803fbd32700
> > [    0.983133] i0: fffffffffffffffb i1: 00000000007ddb58 i2: fffff803fbba0000 i3: 0000000000000000
> > [    0.983197] i4: 00000000005002a4 i5: 0000000000000008 i6: fffff803fb3ab451 i7: 0000000000500620
> > [    0.983269] I7: <sysfs_read_file+0x80/0x104>
> > [    0.983299] Caller[0000000000500620]: sysfs_read_file+0x80/0x104
> > [    0.983368] Caller[00000000004bedc0]: vfs_read+0x78/0x10c
> > [    0.983556] Caller[00000000004bf114]: sys_read+0x34/0x60
> > [    0.983622] Caller[0000000000406294]: linux_sparc_syscall32+0x3c/0x40
> > [    0.983707] Caller[0000000000016d90]: 0x16d98
> > [    0.983873] Instruction DUMP: 007ddb80  00000000  00000000 <00000000> 00000000  00000000  00000000  00000000  007ddb98 
> > 
> > This is dev_attr_show() calling attr->show() which points to
> > 'part_attr_group' struct instead of a function. :-)
> 
> Ick, that's not good :)

gregkh-driver-block-device.patch strikes again.

> How is it working for anyone else then?  sparc64 isn't doing anything
> "odd" with it's block devices, is it?
> 
> > I'm pretty sure the following changeset is to blame:
> > 
> > commit edfaa7c36574f1bf09c65ad602412db9da5f96bf
> > Author: Kay Sievers <kay.sievers@...y.org>
> > Date:   Mon May 21 22:08:01 2007 +0200
> > 
> >     Driver core: convert block from raw kobjects to core devices
> >     
> >     This moves the block devices to /sys/class/block. It will create a
> >     flat list of all block devices, with the disks and partitions in one
> >     directory. For compatibility /sys/block is created and contains symlinks
> >     to the disks.
> 
> So I'm guessing if you revert this it works?

Going offtopic here...

The patch was committed to mainline last week and it has a git timestamp
from eight months ago.  When you received the original email from Kay.

But the patch changed in that time period.  This doesn't seem right?
--
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/