msdosfs: fix directory corruption after rename operation

The is a bug in MSDOSFS that can be triggered when the target of a
rename operation exists. It is caused by the lack of inodes in the
FAT fil

msdosfs: fix directory corruption after rename operation

The is a bug in MSDOSFS that can be triggered when the target of a
rename operation exists. It is caused by the lack of inodes in the
FAT file system, which are substituted by the location of the DOS 8.3
directory entry in the file system. This causes the "inode" of a file
to change when its directory entry is moved to a different location.

The rename operation wants to re-use the existing directory entry
position of an existing target file name (POS1). But the code does
instead locate the first position in the directory that provides
sufficient free directory slots (POS2) to hold the target file name
and fills it with the directory data.

The rename operation continues and at the end writes directory data to
the initially retrieved location (POS1) of the old target directory.
This leads to 2 directory entries for the target file, but with
inconsistent data in the directory and in the cached file system
state.

The location that should have been re-used (POS1) is marked as deleted
in the directory, and new directory data has been written to a
different location (POS2). But the VFS cache has the newly written
data stored under the inode number that corresponds to the initially
planned position (POS1).

If then a new file is written, it can allocate the deleted directory
entries (POS1) and when it queries the cache, it retrieves data that
is valid for the target of the prior rename operation, leading to a
corrupt directory entry (at POS1) being written (DOS file name of the
earlier rename target combined with the Windows long file name of the
newly written file).

PR: 268005
Reported by: wbe@psr.com
Approved by: kib, mckusick
Fixes: 2c9cbc2d45b94
MFC after: 3 days
Differential Revision: https://reviews.freebsd.org/D43951

show more ...

msdosfs_rename(): implement several XXXs about downgrading to ro

Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D43482

msdosfs_rename(): handle errors from msdosfs_lookup_ino()

Properly working storage and correct filesystem structure indeed only
allow the EJUSTRETURN return code, but since the called function needs

msdosfs_rename(): handle errors from msdosfs_lookup_ino()

Properly working storage and correct filesystem structure indeed only
allow the EJUSTRETURN return code, but since the called function needs
to read directory blocks and (re)parse the content, the assert is not
neccessary hold.

PR: 276408
Reported by: John F. Carr
Reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D43482

show more ...

sys: Remove $FreeBSD$: one-line .c comment pattern

Remove /^/[*/]\s*\$FreeBSD\$.*\n/

fs/msdosfs: Fix potential panic and size calculations

Some combinations of FAT12 file system parameters could cause a kernel
panic due to an unmapped access if the size of the FAT was larger than
th

fs/msdosfs: Fix potential panic and size calculations

Some combinations of FAT12 file system parameters could cause a kernel
panic due to an unmapped access if the size of the FAT was larger than
the CPU page size. The reason is that FAT12 uses 3 bytes to store
2 FAT pointers, leading to partial FAT pointers at the end of buffers
of a size that is not a multiple of 3.

With a typical page size of 4 KB, this caused the FAT entry at byte
offsets 4095 and 4096 to cross the page boundary, with only the first
page mapped. This was fixed by adjusting the mapping to always cover
both bytes of each FAT entry.

Testing revealed 2 other inconsistencies that are fixed by this commit:

1) The calculation of the size of the data area did not take into
account the fact that the first two data block numbers are reserved
and that the data area starts with block 2. This could cause a
FAT12 file system created with the maximum supported number of
blocks to be incorrectly identified as FAT16.

2) The root directory does not take up space in the data area of a
FAT12 or FAT16 file system, since it is placed into a reserved
area outside of that data area. This commits makes stat() report
the logical size of the root directory, but with 0 blocks allocated
from the data area.

PR: 270587
Reviewed by: mckusick
Differential Revision: https://reviews.freebsd.org/D39386

show more ...

vfs: retire the now unused SAVESTART flag

Bump __FreeBSD_version to 1400075

Tested by: pho

vfs: stop using SAVESTART for rename

ni_startdir has never reached rename routines anyway

Reviewed by: mckusick
Tested by: pho
Differential Revision: https://reviews.freebsd.org/D34468

msdosfs: truncate write if it would exceed the fs max file size or RLIMIT_FSIZE

PR: 164793
Reviewed by: asomers, jah, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Dif

msdosfs: truncate write if it would exceed the fs max file size or RLIMIT_FSIZE

PR: 164793
Reviewed by: asomers, jah, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D36625

show more ...

msdosfs: disallow truncation to set file size past RLIMIT_FSIZE

PR: 164793
Reviewed by: asomers, jah, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revisi

msdosfs: disallow truncation to set file size past RLIMIT_FSIZE

PR: 164793
Reviewed by: asomers, jah, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D36625

show more ...

filesystems: return error from vn_rlimit_fsize() instead of EFBIG

Reviewed by: asomers, jah, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https

filesystems: return error from vn_rlimit_fsize() instead of EFBIG

Reviewed by: asomers, jah, markj
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
Differential revision: https://reviews.freebsd.org/D36625

show more ...

vfs: always retain path buffer after lookup

This removes some of the complexity needed to maintain HASBUF and
allows for removing injecting SAVENAME by filesystems.

Reviewed by: kib (previous versi

vfs: always retain path buffer after lookup

This removes some of the complexity needed to maintain HASBUF and
allows for removing injecting SAVENAME by filesystems.

Reviewed by: kib (previous version)
Differential Revision: https://reviews.freebsd.org/D36542

show more ...

msdosfs: clusterfree() is used only in error handling cases

Change its return type to void, because its result is ignored in both
call sites. Remove oldcnp argument as well, it is NULL always.

Sug

msdosfs: clusterfree() is used only in error handling cases

Change its return type to void, because its result is ignored in both
call sites. Remove oldcnp argument as well, it is NULL always.

Suggested and reviewed by: markj
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D33721

show more ...

Change VOP_READDIR's cookies argument to a **uint64_t

The cookies argument is only used by the NFS server. NFSv2 defines the
cookie as 32 bits on the wire, but NFSv3 increased it to 64 bits. Our
V

Change VOP_READDIR's cookies argument to a **uint64_t

The cookies argument is only used by the NFS server. NFSv2 defines the
cookie as 32 bits on the wire, but NFSv3 increased it to 64 bits. Our
VOP_READDIR, however, has always defined it as u_long, which is 32 bits
on some architectures. Change it to 64 bits on all architectures. This
doesn't matter for any in-tree file systems, but it matters for some
FUSE file systems that use 64-bit directory cookies.

PR: 260375
Reviewed by: rmacklem
Differential Revision: https://reviews.freebsd.org/D33404

show more ...

msdosfs_rename: remove write-only variables

Reviewed by: imp, mjg
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D32577

vfs: remove cn_thread

It is always curthread.

Reviewed by: kib
Differential Revision: https://reviews.freebsd.org/D32453

buffer pager: allow get_blksize method to return error

Reported and reviewed by: asomers
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31

buffer pager: allow get_blksize method to return error

Reported and reviewed by: asomers
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31998

show more ...

msdosfs: add doscheckpath lock

Similar to the UFS revision 8df4bc48c89a130207

Reviewed by: mckusick
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: http

msdosfs: add doscheckpath lock

Similar to the UFS revision 8df4bc48c89a130207

Reviewed by: mckusick
Tested by: pho
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31464

show more ...

msdosfs: fix rename

Use the same locking algorithm for msdosfs_rename() as used by ufs_rename().
Convert doscheckpath() to non-sleeping version.

Reported by: trasz
PR: 257522
In collaboration with:

msdosfs: fix rename

Use the same locking algorithm for msdosfs_rename() as used by ufs_rename().
Convert doscheckpath() to non-sleeping version.

Reported by: trasz
PR: 257522
In collaboration with: pho
Reviewed by: mckusick
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D31464

show more ...

vnode: move write cluster support data to inodes.

The data is only needed by filesystems that
1. use buffer cache
2. utilize clustering write support.

Requested by: mjg
Reviewed by: asomers (previo

vnode: move write cluster support data to inodes.

The data is only needed by filesystems that
1. use buffer cache
2. utilize clustering write support.

Requested by: mjg
Reviewed by: asomers (previous version), fsu (ext2 parts), mckusick
Tested by: pho
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D28679

show more ...

msdosfs: fix vnode leak with msdosfs_rename()

This could happen when failing due to disappearing source file.

Reviewed By: kib
Tested by: pho
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Di

msdosfs: fix vnode leak with msdosfs_rename()

This could happen when failing due to disappearing source file.

Reviewed By: kib
Tested by: pho
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D27338

show more ...

msdosfs: fix double unlock if the source file disappears

We would unlock fvp here, only to unlock it again below,
just before "bad".

Reviewed By: kib
Tested by: pho
Sponsored by: NetApp, Inc.
Spons

msdosfs: fix double unlock if the source file disappears

We would unlock fvp here, only to unlock it again below,
just before "bad".

Reviewed By: kib
Tested by: pho
Sponsored by: NetApp, Inc.
Sponsored by: Klara, Inc.
Differential Revision: https://reviews.freebsd.org/D27339

show more ...

msdosfs: Fix a leak of dirent padding bytes

This was missed in r340856 / commit
6d2e2df764199f0a15fd743e79599391959cc17d. Three bytes from the kernel
stack may be leaked when reading directory entr

msdosfs: Fix a leak of dirent padding bytes

This was missed in r340856 / commit
6d2e2df764199f0a15fd743e79599391959cc17d. Three bytes from the kernel
stack may be leaked when reading directory entries.

Reported by: Syed Faraz Abrar <faraz@elttam.com>
MFC after: 3 days
Sponsored by: The FreeBSD Foundation

show more ...

msdosfs: Add trivial support for suspension.

Tested by: pho (previous version)
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D27269

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Merge ^/head r363739 through r363986.