WireGuard implementation for the OpenBSD kernel https://git.zx2c4.com/wireguard-openbsd/atom/sys/msdosfs/denode.h?h=jd%2Fsimplify-queueing 2019-01-21T18:09:21Z 2019-01-21T18:09:21Z anton anton@openbsd.org 2019-01-21T18:09:21Z urn:sha1:6bd4f7ca0ef936d4e355b60a534d1efc45dff893 structure allows for better tracking of pending lock operations which is essential in order to prevent a use-after-free once the underlying vnode is gone. Inspired by the lockf implementation in FreeBSD. ok visa@ Reported-by: syzbot+d5540a236382f50f1dac@syzkaller.appspotmail.com 2018-05-07T14:43:01Z mpi mpi@openbsd.org 2018-05-07T14:43:01Z urn:sha1:90aa86e4e33ee7a01b3cb9193956fe8779092447 With sf@, inputs from krw@, tested by many, ok visa@ 2017-06-13T18:13:18Z sf sf@openbsd.org 2017-06-13T18:13:18Z urn:sha1:659e968ee685873d1ba8a955d021c90d4cfc0156 This has again caused regressions, this time when reading from msdosfs. This reverts denode.h 1.31 msdosfs_vnops.c 1.114 Requested by deraadt@ 2017-05-29T13:48:12Z sf sf@openbsd.org 2017-05-29T13:48:12Z urn:sha1:f4aaab5fd4219e21322d2fe25905a711d91e97da This is the reverted commit by mpi@ from msdosfs_vnops.c 1.105 plus some additional tweaks to fix some cluster/block number confusion that lead to regressions when seeking past the end of a file. The original commit message was: The logic used in msdosfs_bmap() to loop calling pcbmap() comes from FreeBSD and is not really efficient but it is good enough since it is only called when generating I/O. With this diff I get a 100% improvement when reading big files from a crappy USB stick. With this and bread_cluster(9) modified to not re-fetch B_CACHED buffers, reading large contiguous files with chunk sizes of MAXPHYS is almost as fast as physio(9) on the same device. For a 'real world' example, when copying music files from a USB stick I see a speed jump from 15MB/s on -current to 24Mb/s with this diff. While here rename some 'lbn' variables into 'cn' to better reflect what we're dealing with. Tested by Mathieu, with support from deraadt@ ok mpi@ 2016-08-30T19:47:23Z sf sf@openbsd.org 2016-08-30T19:47:23Z urn:sha1:a7510cbce6cfc4f5599c2fe7d80eec19277ff1a2 This caused garbage to be written instead of blocks of 0-bytes if a file is extended by seeking past the end. This happens for example when extracting files containing lots of 0-bytes with tar. ok mpi@ Details of original commit: msdosfs_vnops.c revision 1.105 denode.h revision 1.28 date: 2016/01/13 10:00:55; author: mpi; commitid: ru9jHQwQX09BC5Bw; Implement VFS read clustering for MSDOSFS. The logic used in msdosfs_bmap() to loop calling pcbmap() comes from FreeBSD and is not really efficient but it is good enough since it is only called when generating I/O. With this diff I get a 100% improvement when reading big files from a crappy USB stick. With this and bread_cluster(9) modified to not re-fetch B_CACHED buffers, reading large contiguous files with chunk sizes of MAXPHYS is almost as fast as physio(9) on the same device. For a 'real world' example, when copying music files from a USB stick I see a speed jump from 15MB/s on -current to 24Mb/s with this diff. While here rename some 'lbn' variables into 'cn' to better reflect what we're dealing with. Tested by Mathieu, with support from deraadt@ 2016-06-19T11:54:33Z natano natano@openbsd.org 2016-06-19T11:54:33Z urn:sha1:26b8ec940ab2fa67fbd6a540475975a33d306550 trivial change to use rrw locks instead. All it needs is LK_* defines for the RW_* flags. tested by naddy and sthen on package building infrastructure input and ok jmc mpi tedu 2016-01-13T10:00:55Z mpi mpi@openbsd.org 2016-01-13T10:00:55Z urn:sha1:69dc856612686806a22aac0c5ec30d0789582c0d The logic used in msdosfs_bmap() to loop calling pcbmap() comes from FreeBSD and is not really efficient but it is good enough since it is only called when generating I/O. With this diff I get a 100% improvement when reading big files from a crappy USB stick. With this and bread_cluster(9) modified to not re-fetch B_CACHED buffers, reading large contiguous files with chunk sizes of MAXPHYS is almost as fast as physio(9) on the same device. For a 'real world' example, when copying music files from a USB stick I see a speed jump from 15MB/s on -current to 24Mb/s with this diff. While here rename some 'lbn' variables into 'cn' to better reflect what we're dealing with. Tested by Mathieu, with support from deraadt@ 2015-10-23T10:45:31Z krw krw@openbsd.org 2015-10-23T10:45:31Z urn:sha1:9eacea01e9ed3f9c68be5d20950269d8caea87c9 read without generating spurious headaches. 2013-06-11T16:42:02Z deraadt deraadt@openbsd.org 2013-06-11T16:42:02Z urn:sha1:1abdbfde5173507cdbd2578554582107ac062818 test period; i think 3 years ago the last bugs fell out. ok otto beck others 2012-09-06T19:06:04Z krw krw@openbsd.org 2012-09-06T19:06:04Z urn:sha1:e6f855f7a7cafb73415a238ce5cc66cfb52b38bc using "%.11s" to print them out. Make all dos file names 11 byte arrays and nuke the attempt to put '\0' at the 12th position of such an array. Fixes 'panic: smashed stack in msdosfs_rename.c' reported by MERHIGI Marcus via tech@. Tested by MERHIGI Marcus. Suggestions and ok tedu@.