From owner-freebsd-fs@freebsd.org Sun Jan 3 04:35:00 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AC3E7A53625 for ; Sun, 3 Jan 2016 04:35:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 90C9710D9 for ; Sun, 3 Jan 2016 04:35:00 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id u034Z0ur009289 for ; Sun, 3 Jan 2016 04:35:00 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-fs@FreeBSD.org Subject: [Bug 205816] [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Date: Sun, 03 Jan 2016 04:35:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-CURRENT X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: damjan.jov@gmail.com X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-bugs@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status keywords bug_severity priority component assigned_to reporter cc attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Jan 2016 04:35:00 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D205816 Bug ID: 205816 Summary: [ext2fs] [patch] EXT4 sparse blocks unsupported, contain garbage when read Product: Base System Version: 11.0-CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: damjan.jov@gmail.com CC: freebsd-fs@FreeBSD.org Created attachment 164979 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D164979&action= =3Dedit preliminary patch to implement support for EXT4 sparse files The ext2fs module does not support sparse files on EXT4 filesystems, yet doesn't fail. When attempting to read the sparse blocks from a sparse file, instead of zeroes, they contain garbage data read from the wrong disk block= s. Here's an example sparse file in debugfs: debugfs: dump_extents /home/user/Documents/file.iso Level Entries Logical Physical Length Flags 0/ 1 1/ 1 0 - 1122599 1082775 1122600 1/ 1 1/ 53 0 - 5 1372160 - 1372165 6 1/ 1 2/ 53 8 - 11 1372168 - 1372171 4 1/ 1 3/ 53 16 - 19 1372176 - 1372179 4 1/ 1 4/ 53 24 - 27 1372184 - 1372187 4 1/ 1 5/ 53 32 - 33 1372192 - 1372193 2 ... Note how block ranges 0-5, 8-11, 16-19 are allocated, but the in between bl= ocks are sparse. The problem starts in the ext4_ext_binsearch() function in ext2_extents.c w= hich expects the block ranges in the extents to be continuous, and doesn't check whether the lbn parameter even lies inside the found extent's block range. = It blindly sets: path->ep_ext =3D l - 1; which will set the pointer to invalid memory (a part of struct ext2_extent_header) when lbn=3D0 and the first block of a file is sparse. A= lso in the above example, lbn=3D6 will use the 0-5 extent, reading block 0 instead. My preliminary patch improves ext4_ext_binsearch() to check for out of range blocks, marks the path as being sparse, and stores the range of extents starting at the lbn that is sparse. Sparse extents are cached in ext4_ext_read() for future reuse. Actual reading of sparse blocks is implemented by copying from a static array of zeroes (is there a better way= of doing it?) and read() definitely works, but mmap() doesn't seem to (system instantly reboots when reading even 1 byte from mapped region, but this also happens for some dense files, so it's not (just?) my patch). If testing against other EXT4 implementations, note that ext4fuse also has = this bug. --=20 You are receiving this mail because: You are on the CC list for the bug.=