linux-ext4 - Is warn_on() right reply for i/o error?

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

Message-ID: <20140724152721.GA4771@amd.pavel.ucw.cz>
Date:	Thu, 24 Jul 2014 17:27:22 +0200
From:	Pavel Machek <pavel@....cz>
To:	tytso@....edu, linux-kernel@...r.kernel.org,
	adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org, jack@...e.cz
Subject: Is warn_on() right reply for i/o error?

Hi!

Just... I know, I should not be unscrewing hard drive cover while
operating.

But on the other hand... WARN_ON() does not sound like right reply for
a disk failure... right?

And on related note... automounting is evil. Oh well.

								Pavel

sd 6:0:0:0: [sdf] Unhandled error code
sd 6:0:0:0: [sdf]  
Result: hostbyte=0x01 driverbyte=0x00
sd 6:0:0:0: [sdf] CDB: 
cdb[0]=0x28: 28 00 00 05 4a 00 00 00 40 00
end_request: I/O error, dev sdf, sector 346624
Buffer I/O error on device sdf, logical block 43328
Buffer I/O error on device sdf, logical block 43329
------------[ cut here ]------------
WARNING: CPU: 0 PID: 4710 at fs/fs-writeback.c:1199
__mark_inode_dirty+0x1be/0x1d0()
bdi-block not registered
Modules linked in:
CPU: 0 PID: 4710 Comm: umount Not tainted 3.16.0-rc5+ #381
Hardware name:                  /DG41MJ, BIOS
MJG4110H.86A.0006.2009.1223.1155 12/23/2009
 000004af df661e18 c480956d c4a2bae0 df661e48 c403914a c4a2baf7
 df661e74
 00001266 c4a2bae0 000004af c41154fe c41154fe d21ffa74 c6263dec
 d21ffc60
 df661e60 c40391ee 00000009 df661e58 c4a2baf7 df661e74 df661e88
 c41154fe
Call Trace:
 [<c480956d>] dump_stack+0x41/0x52
 [<c403914a>] warn_slowpath_common+0x7a/0xa0
 [<c41154fe>] ? __mark_inode_dirty+0x1be/0x1d0
 [<c41154fe>] ? __mark_inode_dirty+0x1be/0x1d0
 [<c40391ee>] warn_slowpath_fmt+0x2e/0x30
 [<c41154fe>] __mark_inode_dirty+0x1be/0x1d0
 [<c411b806>] __set_page_dirty+0x66/0xb0
 [<c411b8a6>] mark_buffer_dirty+0x56/0x80
 [<c415bc1d>] ext3_put_super+0x20d/0x250
 [<c410a042>] ? evict_inodes+0xb2/0x110
 [<c40f4888>] generic_shutdown_super+0x68/0xe0
 [<c40f4925>] kill_block_super+0x25/0x70
 [<c40f4b88>] deactivate_locked_super+0x48/0x70
 [<c40f5161>] deactivate_super+0x51/0x70
 [<c410da6f>] mntput_no_expire+0x12f/0x1f0
 [<c410f1e7>] ? SyS_umount+0xa7/0x430
 [<c410f1e7>] SyS_umount+0xa7/0x430
 [<c480e41e>] ? syscall_call+0x7/0xb
 [<c40df3e1>] ? vm_munmap+0x41/0x50
 [<c480e41e>] syscall_call+0x7/0xb
---[ end trace 6642457659b6f1ae ]---
EXT3-fs (sdf1): I/O error while writing superblock
usb 1-1: new high-speed USB device number 8 using ehci-pci

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html