linux-toradex.git/fs/minix/minix.h, branch v4.4.15

fs: cleanup slight list_entry abuse

2015-06-23T22:01:59+00:00

list_entry is just a wrapper for container_of, but it is arguably
wrong (and slightly confusing) to use it when the pointed-to struct
member is not a struct list_head. Use container_of directly instead.

Signed-off-by: Rasmus Villemoes 
Signed-off-by: Al Viro

vfs: check i_nlink limits in vfs_{mkdir,rename_dir,link}

2012-03-21T01:29:32+00:00

New field of struct super_block - ->s_max_links.  Maximal allowed
value of ->i_nlink or 0; in the latter case all checks still need
to be done in ->link/->mkdir/->rename instances.  Note that this
limit applies both to directoris and to non-directories.

Signed-off-by: Al Viro

minix: propagate umode_t

2012-01-04T03:54:59+00:00

Signed-off-by: Al Viro

minixfs: kill manual hweight(), simplify

2011-11-19T16:13:28+00:00

Signed-off-by: Al Viro

fs/minix: Verify bitmap block counts before mounting

2011-11-19T16:13:26+00:00

Newer versions of MINIX can create filesystems that allocate an extra
bitmap block.  Mounting of this succeeds, but doing a statfs call will
result in an oops in count_free because of a negative number being used
for the bh index.

Avoid this by verifying the number of allocated blocks at mount time,
erroring out if there are not enough and make statfs ignore the extras
if there are too many.

This fixes https://bugzilla.kernel.org/show_bug.cgi?id=18792

Signed-off-by: Josh Boyer 
Signed-off-by: Al Viro

bitops: remove minix bitops from asm/bitops.h

2011-03-24T02:46:22+00:00

minix bit operations are only used by minix filesystem and useless by
other modules.  Because byte order of inode and block bitmaps is different
on each architecture like below:

m68k:
	big-endian 16bit indexed bitmaps

h8300, microblaze, s390, sparc, m68knommu:
	big-endian 32 or 64bit indexed bitmaps

m32r, mips, sh, xtensa:
	big-endian 32 or 64bit indexed bitmaps for big-endian mode
	little-endian bitmaps for little-endian mode

Others:
	little-endian bitmaps

In order to move minix bit operations from asm/bitops.h to architecture
independent code in minix filesystem, this provides two config options.

CONFIG_MINIX_FS_BIG_ENDIAN_16BIT_INDEXED is only selected by m68k.
CONFIG_MINIX_FS_NATIVE_ENDIAN is selected by the architectures which use
native byte order bitmaps (h8300, microblaze, s390, sparc, m68knommu,
m32r, mips, sh, xtensa).  The architectures which always use little-endian
bitmaps do not select these options.

Finally, we can remove minix bit operations from asm/bitops.h for all
architectures.

Signed-off-by: Akinobu Mita 
Acked-by: Arnd Bergmann 
Acked-by: Greg Ungerer 
Cc: Geert Uytterhoeven 
Cc: Roman Zippel 
Cc: Andreas Schwab 
Cc: Martin Schwidefsky 
Cc: Heiko Carstens 
Cc: Yoshinori Sato 
Cc: Michal Simek 
Cc: "David S. Miller" 
Cc: Hirokazu Takata 
Acked-by: Ralf Baechle 
Acked-by: Paul Mundt 
Cc: Chris Zankel 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

clean up write_begin usage for directories in pagecache

2010-08-09T20:47:31+00:00

For filesystem that implement directories in pagecache we call
block_write_begin with an already allocated page for this code, while the
normal regular file write path uses the default block_write_begin behaviour.

Get rid of the __foofs_write_begin helper and opencode the normal write_begin
call in foofs_write_begin, while adding a new foofs_prepare_chunk helper for
the directory code.  The added benefit is that foofs_prepare_chunk has
a much saner calling convention.

Note that the interruptible flag passed into block_write_begin is always
ignored if we already pass in a page (see next patch for details), and
we never were doing truncations of exessive blocks for this case either so we
can switch directly to block_write_begin_newtrunc.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

minix: replace inode uid,gid,mode init with helper

2010-05-21T22:31:24+00:00

- also redesign minix_new_inode interface

Signed-off-by: Dmitry Monakhov 
Signed-off-by: Al Viro

Making fs/minix/minix.h double including safe

2009-06-22T18:34:42+00:00

I happened to find that fs/minix/minix.h doesn't guard double include.

Yes, I know this never cause something destructive because this is
self-evidence that no source file includes minix.h twice, but I think
fixing this is better than disregarding it.

Signed-off-by: Hitoshi Mitake 
Signed-off-by: Linus Torvalds

switch minix to simple_fsync()

2009-06-12T01:36:12+00:00

* get minix_write_inode() to honour the second argument
* now we can use simple_fsync() for minixfs

Signed-off-by: Al Viro