| created | 2022-08-27T19:22:40Z |
|---|---|
| begin | 2022-08-23T00:00:00Z |
| end | 2022-08-24T00:00:00Z |
| path | src/sys |
| commits | 7 |
| date | 2022-08-23T08:10:35Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/usb/usbdevs | log | diff | annotate |
| message |
add SIMCom SIM5320 (same id used by Option iCON 210) from [email protected] |
|||
| date | 2022-08-23T08:11:01Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/usb/usbdevs.h | log | diff | annotate |
| src/sys/dev/usb/usbdevs_data.h | log | diff | annotate | |
| message | regen | |||
| date | 2022-08-23T08:12:30Z | |||
|---|---|---|---|---|
| author | jsg | |||
| files | src/sys/dev/usb/umsm.c | log | diff | annotate |
| message |
match on SIMCom SIM5320 (same id used by Option iCON 210) from and tested by [email protected] |
|||
| date | 2022-08-23T11:39:34Z | |||
|---|---|---|---|---|
| author | kettenis | |||
| files | src/sys/arch/arm64/arm64/cpu.c | log | diff | annotate |
| message |
Recognize the cores on Apple's M2 SoC. ok jsg@, tobhe@, deraadt@ |
|||
| date | 2022-08-23T13:18:59Z | |||
|---|---|---|---|---|
| author | aoyama | |||
| files | src/sys/arch/luna88k/conf/RAMDISK | log | diff | annotate |
| message |
Added NFS client support to RAMDISK kernel as the same as other platforms. Tested by me. |
|||
| date | 2022-08-23T15:58:57Z | |||
|---|---|---|---|---|
| author | anton | |||
| files | src/sys/dev/usb/umass.c | log | diff | annotate |
| message |
Remove assertions as they have been disabled since the code was imported from NetBSD back in 2000. ok krw@ |
|||
| date | 2022-08-23T20:37:16Z | |||
|---|---|---|---|---|
| author | cheloha | |||
| files | src/sys/msdosfs/msdosfs_denode.c | log | diff | annotate |
| src/sys/msdosfs/msdosfs_lookup.c | log | diff | annotate | |
| src/sys/msdosfs/msdosfs_vnops.c | log | diff | annotate | |
| message |
msdosfs: don't pass NULL proc pointer to detrunc() detrunc()'s proc pointer argument may be passed to vinvalbuf(9), which under certain conditions will pass the given proc pointer to VOP_FSYNC(9), which always asserts that the given proc pointer is equal to curproc. msdosfs_write(), msdosfs_inactive(), createde(), and deextend() all pass NULL for detrunc()'s proc pointer argument. I have no idea why. If these detrunc() calls ever reach VOP_FSYNC(9) the kernel will panic. So, for example, any user with write access to an msdosfs partition can panic the kernel by writing to the partition until they cause ENOSPC. That particular panic looks like this: panic: kernel diagnostic assertion "p == curproc" failed: file "/usr/src/sys/kern/vfs_vops.c", line 305 Stopped at db_enter+0xa: popq %rbp TID PID UID PRFLAGS PFLAGS CPU COMMAND *500294 8955 0 0x100003 0 1K ksh db_enter() at db_enter+0xa panic(ffffffff81f1b0cf) at panic+0xc4 __assert(ffffffff81fa361c,ffffffff81ee8329,131,ffffffff81f7229b) at assert+0x3b VOP_FSYNC(fffffd8449a78b30,ffffffffffffffff,1,0) at VOP_FSYNC+Oxd6 vinvalbuf(fffffd8449a78b30,3,ffffffffffffffff,0,0,ffffffffffffffff) at vinvalbuf+0xd5 detrunc(ffff80000186f900,1fe,0,ffffffffffffffff,0) at detrunc+0x239 msdosfs_write(ffff800055774b98) at msdosf_write+0x4a4 VOP_WRITE(fffffd8449a78b30,ffff800055774d10,3,fffffd8370e8d5d0) at VOP_WRITE+0x59 vn_write(fffffd83c723b860,ffff800055774d10,0) at vn_write+0xc0 dofilewritev(ffff8000556ecfc0,1,ffff800055774d10,0.ffff800055774dc0) at dofilewritev+0x14d sys_write(ffff8000556ecfc0,ffff800055774dd0,ffff800055774dc0) at sys_write+0x6a syscall(ffff800055774e70) at syscall+0x39b Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7ffffd8bf0, count: 2 This patch tweaks all the detrunc() calls in the aforementioned msdosfs functions to pass curproc instead of a NULL pointer to detrunc(). We don't appear to have curproc stashed anywhere in msdosfs_write() or deextend(), so for those calls we explicitly pass curproc. This might have unforseen consequences I can't anticipate. However, with this patch I can no longer panic the kernel by filling an msdosfs partition, which seems like an improvement. With advice from gnezdo@. ok gnezdo@ |
|||