[Bug 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #34 from Andriy Gapon --- (In reply to stockhausen from comment #32) 1. Ah, you are right, I forgot that modern processors intercept C-state I/O accesses at a core level. Just to clarify, I assume that on your T620 cpucontrol -m 0xC0010073 /dev/cpuctl0 gives 0x414? 3.b(2) The root bridge has a range that covers 0x414, so that's okay. A. I do not think so. I think that the code currently expects BIOS to set up everything correctly. We could try to think about how FreeBSD ACPI code could work around not having Cx I/O ports in the system resources... By the way, I see why acpi cpu devices cannot share a resource if it's not an acpi system resource. If a resource is a system resource then it is allocated from the nexus (very early) and the acpi bus manages it on its own. That means that acpi_set_resource() -> resource_list_reserve(flags=0) -> resource_list_alloc() -> BUS_ALLOC_RESOURCE() -> nexus_alloc_resource() -> rman_reserve_resource(flags=0) would always fail. But that's okay, because acpi_alloc_resource() has a fallback to acpi_alloc_sysres(). And if the resource is consistently allocated with RF_SHARED, then all allocations of it succeed. If a resource is _not_ a system resource, then the resource is not allocated by the acpi bus in the nexus as the acpi bus is unaware of it. Then, when the first cpu calls acpi_PkgGas() -> acpi_bus_alloc_gas() -> bus_set_resource() -> acpi_set_resource() -> resource_list_reserve(flags=0) -> resource_list_alloc(flags=0) -> BUS_ALLOC_RESOURCE(flags=0) -> nexus_alloc_resource(flags=0) -> rman_reserve_resource(flags=0), the resource is allocated in the nexus and it is allocated without RF_SHARED flag. Because the allocation is successful, the resource is added to the device's resource list. After bus_set_resource(), acpi_bus_alloc_gas() calls bus_alloc_resource_any() -> acpi_alloc_resource(flags=RF_ACTIVE|RF_SHARED) -> resource_list_alloc(). Because the resource already exists in the device's resource list, resource_list_alloc() would simply activate it and return. So, for the first cpu acpi_bus_alloc_gas() is successful. For any subsequent cpu, this call chain acpi_PkgGas() -> acpi_bus_alloc_gas() -> bus_set_resource() -> acpi_set_resource() -> resource_list_reserve(flags=0) -> resource_list_alloc(flags=0) -> BUS_ALLOC_RESOURCE(flags=0) -> nexus_alloc_resource(flags=0) -> rman_reserve_resource(flags=0) would fail because the resource is already allocated in nexus and it is not shared. Thus, the resource would not be created in the device's resource list. Thus, the subsequent call to bus_alloc_resource_any() -> acpi_alloc_resource(flags=RF_ACTIVE|RF_SHARED) -> resource_list_alloc() would not find that resource and it would have to call BUS_ALLOC_RESOURCE() -> nexus_alloc_resource() -> rman_reserve_resource() and that would fail again for the same reason. And, in this case, acpi_alloc_resource()'s fallback to acpi_alloc_sysres() would also fail, because the resource is not a system resource. In the end, acpi_PkgGas() -> acpi_bus_alloc_gas() fails just as you have seen. B. I would add 0x414 to CRS of Device S900. E.g. using 0x040B as an example, I would add this just after it: IO (Decode16, 0x0414, // Range Minimum 0x0414, // Range Maximum 0x00, // Alignment 0x04, // Length ) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #35 from stockhau...@collogia.de --- Phew, I see you found the culprit. Although I do not know every single function I saw a lot of the names during my code analysis. Regarding HP T620 settings: cpucontrol -m 0xC0010073 /dev/cpuctl0 gives 0x413 (The CPU gets Port+1 from BIOS). So the ACPI tables need: For T620: IO (Decode16, 0x0413, // Range Minimum 0x0413, // Range Maximum 0x00, // Alignment 0x08, // Length ) For T730: IO (Decode16, 0x1770, // Range Minimum 0x1770, // Range Maximum 0x00, // Alignment 0x08, // Length ) With these settings C2 states come up fine on both machines. I will check if all of this hard work at least gives some power saving effects. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236853] panic: page fault on rtsock.c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236853 Bug ID: 236853 Summary: panic: page fault on rtsock.c Product: Base System Version: CURRENT Hardware: i386 OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: lenzi.ser...@gmail.com The system panics on /usr/src/sys/net/rtsock.c:839 and all references to ifp->if_addr->ifa_addr the pointer ifp->if_addr is invalid. some race condition occurs that releases the ifp->if_addr and when the code tries to read the next pointer a page fault occurs sometimes it happens in /usr/src/sys/net/rtsock.c:1581 too how to reproduce: setup (1) a freebsd 12 or 13 as a ppp-in server (man ppp) using the setup in the example at http://www.k1.com.br/crash/ppp, than go to another freebsd and using the ppptun.conf, connect to the (1) using the command ppp -ddial ppptun after several connects and disconnects, the (1) panics... sometimes the simple route get "any ppp address" is enough to panic the system. The resulting debug files of the panic is in the http://www.k1.com.br/crash -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236846] FreeBSD 12.0-STABLE-p3 r345567: panic: vm_fault_hold: fault on nofault entry
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846 --- Comment #1 from Viktor Dukhovni --- I switched to the 12.0-STABLE kernel, but still essentially the same panic: panic: vm_fault_hold: fault on nofault entry, addr: 0xfe0075df2000 cpuid = 6 time = 1553772208 KDB: stack backtrace: #0 0x80bf1907 at kdb_backtrace+0x67 #1 0x80ba58c3 at vpanic+0x1a3 #2 0x80ba5713 at panic+0x43 #3 0x80ee9ed1 at vm_fault_hold+0x2801 #4 0x80ee7680 at vm_fault+0x60 #5 0x81082a92 at trap_pfault+0x162 #6 0x81081f6e at trap+0x29e #7 0x8105c715 at calltrap+0x8 #8 0x80d32d73 at ip_input+0x463 #9 0x80cc70f6 at netisr_dispatch_src+0xd6 #10 0x80cab643 at ether_demux+0x163 #11 0x80cac7a6 at ether_nh_input+0x346 #12 0x80cc70f6 at netisr_dispatch_src+0xd6 #13 0x80caba44 at ether_input+0x54 #14 0x80cc3836 at iflib_rxeof+0xa66 #15 0x80cbdd06 at _task_fn_rx+0x76 #16 0x80bf0194 at gtaskqueue_run_locked+0x144 #17 0x80befdf8 at gtaskqueue_thread_loop+0x98 Uptime: 5h20m55s addr2line -afi -e /usr/lib/debug/boot/kernel/kernel.debug 0x80d32d73 0x80d32d73 ip_input /usr/src/sys/netinet/ip_input.c:606 The kgdb backtrace is: #0 __curthread () at ./machine/pcpu.h:230 #1 doadump (textdump=) at /usr/src/sys/kern/kern_shutdown.c:371 #2 0x80ba54ab in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:451 #3 0x80ba5923 in vpanic (fmt=, ap=0xfe45c130) at /usr/src/sys/kern/kern_shutdown.c:877 #4 0x80ba5713 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:804 #5 0x80ee9ed1 in vm_fault_hold (map=, vaddr=18446741876663853056, fault_type=, fault_flags=, m_hold=0x0) at /usr/src/sys/vm/vm_fault.c:598 #6 0x80ee7680 in vm_fault (map=0xf80003002000, vaddr=, fault_type=4 '\004', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:548 #7 0x81082a92 in trap_pfault (frame=0xfe45c460, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:844 #8 0x81081f6e in trap (frame=0xfe45c460) at /usr/src/sys/amd64/amd64/trap.c:441 #9 #10 0xfe0075df2450 in ?? () #11 0x8201a908 in __pcpu () #12 0x8201a908 in __pcpu () #13 0xfe640208 in ?? () #14 0xf8000377b000 in ?? () #15 0xf801 in ?? () #16 0x0034 in ?? () #17 0xf8000377b000 in ?? () #18 0xfe45c630 in ?? () #19 0xfe6489f8 in ?? () #20 0x0008 in ?? () #21 0xf804d4d6c100 in ?? () #22 0x65270264 in ?? () #23 0xf8000377b000 in ?? () #24 0x0014 in ?? () #25 0x82014880 in ?? () #26 0xf804d4d6c166 in ?? () #27 0xfe45c660 in ?? () #28 0x80d32d73 in ip_input (m=0xf804d4d6c100) at /usr/src/sys/netinet/ip_input.c:606 Backtrace stopped: frame did not save the PC -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236854] kernel exception at boot time
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236854 Bug ID: 236854 Summary: kernel exception at boot time Product: Base System Version: 11.2-RELEASE Hardware: arm64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ad...@canmos.net Hello! I have seen strange situation during of system boot when rootfs should be mounted on /dev/md0 (ramdisk): When system starts to boot into loaded kernel there is the following exception: FreeBSD/amd64 EFI loader, Revision 1.1 (Fri Jun 22 04:20:29 UTC 2018 r...@releng2.nyi.freebsd.org) Load Path: HD(2,GPT,56BFC0A5-33B0-11E9-9FAC-A4BF012E952E,0x64028,0x139BFF8) Load Device: PciRoot(0x9)/Pci(0x0,0x0)/Pci(0x0,0x0)/Ctrl(0x1)/Scsi(0x6,0x0)/H Btart @ 0x8031 ...s, 'help' for more detailed help.rompt.x16aee0+0x8 X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - RIP - 5B869C63, CS - 0038, RFLAGS - 00010206 ExceptionData - RAX - 0002, RCX - , RDX - 2E36E95DE5894855 RBX - , RSP - 6C0D2D58, RBP - 6C0D2E50 RSI - 5B899778, RDI - 5B88AC30 R8 - FFFB, R9 - 8080808080808080, R10 - FFF8 R11 - 6C0D2AE0, R12 - 5B88F210, R13 - 5B89D6D8 R14 - 5B88F200, R15 - 0002 DS - 0030, ES - 0030, FS - 0030 GS - 0030, SS - 0030 CR0 - 8013, CR2 - , CR3 - 6C033000 CR4 - 0668, CR8 - DR0 - , DR1 - , DR2 - DR3 - , DR6 - 0FF0, DR7 - 0400 GDTR - 6A510DE0 0047, LDTR - IDTR - 6A509018 0FFF, TR - FXSAVE_STATE - 6C0D29B0 Find PE image (No PDB) (ImageBase=5B843000, EntryPoint=5B849E50) [closing the connection] I catched it via SOL (Serial over LAN). Could you please help me to know - is this a bug or maybe i forget about some specific settings? My /boot/loader.conf looks like: # old style beastie_disable="YES" # system mrsas_load="YES" geom_mirror_load="YES" # rootfs on ramdisk initmd_load="YES" initmd_type="md_image" initmd_name="/boot/boot.md" #100MB file size rootdev="ufs:/dev/md0" I'm booting with UEFI support. My kernel is GENERIC but i recompiled it without mrsas driver. I load the driver via kernel module compiled from fresh sources downloaded from MegaRAID site manufacturer. The log of this driver looks like: AVAGO MegaRAID SAS FreeBSD mrsas driver version: 07.708.02.00 mrsas0: port 0xf000-0xf0ff mem 0x39f0-0x39ff,0x39e0-0x39ef,0xee80-0xee8f at device 0.0 numa-domain 1 on pci11 mrsas0: Using MSI-X with 40 number of vectors mrsas0: FW supports <128> MSIX vector,Online CPU 40 Current MSIX <40> mrsas0: NVME page size : (4096) mrsas0: FW supports SED mrsas0: FW supports JBOD Map mrsas0: FW supports JBOD Map Ext mrsas0: Jbod map is supported mrsas0: System PD created target ID: 0x6 mrsas0: System PD created target ID: 0x7 mrsas0: System PD created target ID: 0x8 mrsas0: System PD created target ID: 0x9 mrsas0: MSI-x interrupts setup success And i use GEOM mirror. When i remove the strings from /boot/loader.conf: # rootfs on ramdisk initmd_load="YES" initmd_type="md_image" initmd_name="/boot/boot.md" rootdev="ufs:/dev/md0" - then my system boots as usual. Thank you for helpl in advance! -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #36 from John Baldwin --- It may be that we need to fix the RF_SHAREABLE to propagate up when the resource is first allocated by resource_list_reserve, etc. That might fix this without requiring the BIOS to be patched. I haven't looked to see what that would involve though. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236513] HP Thin clients T620/T730 ACPI: Only CPU core 0 detects C2 state
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236513 --- Comment #37 from John Baldwin --- Created attachment 203218 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203218&action=edit shareable_acpi_set_resource.patch This is an untested hack that uses RF_SHAREABLE when reserving resources for CPUs. The other approach is we could just not reserve resources for CPU devices which might be safer as it would then always honor the flags passed to bus_alloc_resource(). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 211771] kernel panic when loading ix interface ( was kernel panic on boot PowerEdge R720xd )
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211771 Jeremy Shinall changed: What|Removed |Added CC||jeremyshin...@icloud.com --- Comment #22 from Jeremy Shinall --- (In reply to Kevin H. Patterson from comment #21) +1 for this. I'm having the exact same problem with an E10G42AFDA card in a Dell r515 on FreeNAS 11.2-U2. I bought this card explicitly because it's on the FreeBSD HCL. Would love to get some traction on this really old issue. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236846] FreeBSD 12.0-STABLE-p3 r345567: panic: vm_fault_hold: fault on nofault entry
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846 --- Comment #2 from Viktor Dukhovni --- With fantastic help from Mark Johnston, the issue has been plausibly narrowed down to the new epoch_tracker code in 12.0 not handling IPv6 via stf0 robustly. The crash dump with "option INVARIANTS" looks like: panic: Assertion etd->et_td == (struct thread *)td failed at /usr/src/sys/sys/epoch_private.h:178 cpuid = 7 time = 1553806077 KDB: stack backtrace: #0 0x80bbb047 at kdb_backtrace+0x67 #1 0x80b737c3 at vpanic+0x1a3 #2 0x80b735a3 at panic+0x43 #3 0x80c68357 at epoch_exit_preempt+0x1e7 #4 0x80c6b35d at if_addr_runlock+0x1d #5 0x82e33b67 at stf_getsrcifa6+0x1a7 #6 0x82e33488 at stf_output+0x48 #7 0x80dc356f at ip6_output+0x1daf #8 0x80d85d74 at tcp_output+0x1be4 #9 0x80d97739 at tcp_usr_disconnect+0x69 #10 0x80c07eec at soclose+0x9c #11 0x80b1d86a at _fdrop+0x1a #12 0x80b20abc at closef+0x1ec #13 0x80b1dea0 at closefp+0xa0 #14 0x8103ca58 at amd64_syscall+0x278 #15 0x8101589d at fast_syscall_common+0x101 I am now testing a work-around patch... -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236846] FreeBSD 12.0-STABLE-p3 r345567: stf_output panic in epoch_exit_preempt
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236846 Viktor Dukhovni changed: What|Removed |Added Summary|FreeBSD 12.0-STABLE-p3 |FreeBSD 12.0-STABLE-p3 |r345567: panic: |r345567: stf_output panic |vm_fault_hold: fault on |in epoch_exit_preempt |nofault entry | -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230876] save-entropy: Sync saved random data
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230876 Conrad Meyer changed: What|Removed |Added Assignee|b...@freebsd.org|c...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 230875] Revisit decision to not block read_random(9) on being seeded
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230875 Conrad Meyer changed: What|Removed |Added Assignee|b...@freebsd.org|c...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236864] sys/netpfil/pf/ioctl/validation:addtables triggered a GPF panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236864 Bug ID: 236864 Summary: sys/netpfil/pf/ioctl/validation:addtables triggered a GPF panic Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: n...@freebsd.org >From https://ci.freebsd.org/job/FreeBSD-head-amd64-test/10671/console : sys/netpfil/pf/ioctl/validation:addtables -> 16:58:03 16:58:03 Fatal trap 9: general protection fault while in kernel mode 16:58:03 cpuid = 0; apic id = 00 16:58:03 instruction pointer= 0x20:0x80cc8c75 16:58:03 stack pointer = 0x28:0xfe0030faf740 16:58:03 frame pointer = 0x28:0xfe0030faf740 16:58:03 code segment = base 0x0, limit 0xf, type 0x1b 16:58:03= DPL 0, pres 1, long 1, def32 0, gran 1 16:58:03 processor eflags = interrupt enabled, resume, IOPL = 0 16:58:03 current process= 23278 (ifconfig) 16:58:03 trap number= 9 16:58:03 panic: general protection fault 16:58:03 cpuid = 0 16:58:03 time = 1553817482 16:58:03 KDB: stack backtrace: 16:58:03 db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0030faf450 16:58:03 vpanic() at vpanic+0x19d/frame 0xfe0030faf4a0 16:58:03 panic() at panic+0x43/frame 0xfe0030faf500 16:58:03 trap_fatal() at trap_fatal+0x394/frame 0xfe0030faf560 16:58:03 trap() at trap+0x6c/frame 0xfe0030faf670 16:58:03 calltrap() at calltrap+0x8/frame 0xfe0030faf670 16:58:03 --- trap 0x9, rip = 0x80cc8c75, rsp = 0xfe0030faf740, rbp = 0xfe0030faf740 --- 16:58:03 strncmp() at strncmp+0x15/frame 0xfe0030faf740 16:58:03 ifunit_ref() at ifunit_ref+0x51/frame 0xfe0030faf780 16:58:03 ifioctl() at ifioctl+0x508/frame 0xfe0030faf850 16:58:03 kern_ioctl() at kern_ioctl+0x28a/frame 0xfe0030faf8c0 16:58:03 sys_ioctl() at sys_ioctl+0x15d/frame 0xfe0030faf990 16:58:03 amd64_syscall() at amd64_syscall+0x276/frame 0xfe0030fafab0 16:58:03 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe0030fafab0 16:58:03 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8004842ca, rsp = 0x7fffe448, rbp = 0x7fffe4b0 --- -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 194477] 10.1-RC1 tar(1) spurious directory permission error message
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477 and...@tao11.riddles.org.uk changed: What|Removed |Added CC||and...@tao11.riddles.org.uk --- Comment #6 from and...@tao11.riddles.org.uk --- This bug still exists in 12-stable. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236864] sys/netpfil/pf/ioctl/validation:addtables triggered a GPF panic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236864 --- Comment #1 from Li-Wen Hsu --- hmm, the commit r345660 doesn't seem to be related to this test, and the next run this case passed. We need to find a reliable way to reproduce this panic. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236870] libarchive directory traversal gives spurious permission errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236870 Bug ID: 236870 Summary: libarchive directory traversal gives spurious permission errors Product: Base System Version: 12.0-STABLE Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: bin Assignee: b...@freebsd.org Reporter: and...@tao11.riddles.org.uk Created attachment 203232 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203232&action=edit libarchive directory traversal patch libarchive-based utilities, notably including tar(1), fail if told to traverse "." if the parent directory is not readable. This is caused by libarchive trying to open ".." at the end of the traverse in order to exit the directory, which is an obviously wrong thing to do. Attached patch (against 12-stable) fixes this and includes a test case. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 236870] libarchive directory traversal gives spurious permission errors
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236870 --- Comment #1 from and...@tao11.riddles.org.uk --- Sorry, this fix isn't quite complete; there are still error cases with archiving "foo/bar/." where "foo" is not readable. Will post another fix shortly. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"