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
| ||
|
Date: Mon, 2 Nov 2015 18:13:34 -0800 From: Joshua Hudson <joshudson@...il.com> To: linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: [PATCH] add support for larger files in minix filesystem No response. I suppose I must be doing something wrong ... On 11/1/15, Joshua Hudson <joshudson@...il.com> wrote: > From: Joshua Hudson <joshudson@...il.com> > > The Minix v3 filesystem and kernel driver have no actual dependency on > files > being less than 2GB in size; however the kernel does not allow creating a > file of 2GB or larger on a Minix v3 filesystem. I was able to remove the > pseudo- > dependency easily by changing one line of code (filesystems need to tell > VFS > how big of files they allow). > > This code won't do anything useful unless the filesystem superblock is > patched at offset 1040 to a larger value. The largest safe value is > 0,252,255,255. > > Signed-off-by Joshua Hudson <joshudson@...il.com> > --- > I'm not on the list anymore so if you don't CC me I won't see it. > > Background: I've been playing around with work on a new embedded device. > where the hardware simply isn't powerful enough to sustain ext2 filesystem. > This resulted in me choosing the Minix filesystem as the operational > filesystem > for reasons including find-next-free-block is sixteen times faster than > FAT. > I discovered the need to collect about 3gb of sensor data in one tape-like > run. > Naturally, this leads to creating a 3gb file; but Linux Kernel can't > handle that. > > Please note I'm pretty far down branches and I don't think a stock kernel > will run on my system (non-free hardware drivers). Thankfully the Minix fs > code changes so slowly this should apply all the same. I have tested that > the patch applies and builds a kernel that fixes the problem. > > The fact that the superblock has to be edited for the patch to do anything > interesting (else it replaces s_maxbytes with the same value) makes this > quite safe to apply even in the presence of a bug I don't know about. > > --- linux-4.2.3/fs/minix/inode.c.orig 2015-11-01 17:13:57.227148723 -0800 > +++ linux-4.2.3/fs/minix/inode.c 2015-11-01 17:21:49.785390753 -0800 > @@ -232,6 +232,7 @@ > s->s_max_links = MINIX2_LINK_MAX; > } else > goto out_no_fs; > + s->s_maxbytes = (unsigned)sbi->s_max_size; /* s_max_size > cannot be >=4GB and MAX_LFS_SIZE must be >= 4GB */ > > /* > * Allocate the buffer map to keep the superblock small. > -- 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/
Powered by blists - more mailing lists