DragonFlyBSD bugtracker: Issueshttps://bugs.dragonflybsd.org/https://bugs.dragonflybsd.org/favicon.ico?16293952082018-04-11T17:20:15ZDragonFlyBSD bugtracker
Redmine DragonFlyBSD - Bug #3129 (New): Kernel panic with 5.2.0 on A2SDi-4C-HLN4Fhttps://bugs.dragonflybsd.org/issues/31292018-04-11T17:20:15Zstateless
<p>I tried to boot 5.2.0 on A2SDi-4C-HLN4F from Supermicro<br />and I got the following kernel panic:</p>
<p><a class="external" href="https://u.2f30.org/sin/2018-04-11-175500_1366x768_scrot.png">https://u.2f30.org/sin/2018-04-11-175500_1366x768_scrot.png</a></p>
<p>See: <a class="external" href="http://bxr.su/DragonFly/sys/kern/subr_cpu_topology.c#125">http://bxr.su/DragonFly/sys/kern/subr_cpu_topology.c#125</a></p> DragonFlyBSD - Bug #2959 (Closed): Duplicate packets on network interface running v4.6.1.1.g6e9a0...https://bugs.dragonflybsd.org/issues/29592016-10-19T20:00:43Zstateless
<p>Hi,</p>
<p>I have an OpenBSD router and a DragonFly BSD machine.</p>
<p>The router configuration is as follows:</p>
<p>em1 is the first LAN interface.<br />em2 is the second LAN interface.<br />em7 is the span port.<br />bridge0 contains em1 and em7.</p>
<p>The DragonFly BSD machine is configured as follows:</p>
<p>bnx0 connects to em2 directly and uses DHCP to get an address. This is how I communicate with the machine.<br />bnx1 connects to em7, the span port, and it is configured as -arp promisc up (no ip address on the interface).</p>
<p>Now I connect my laptop to em1 on my router. I ping the DragonFly BSD box on the address that is assigned on bnx0.<br />Two ICMP echo requests arrive on the DragonFly BSD box, one on bnx0 and one on bnx1. This is expected.<br />However, I also get <em>two</em> ICMP echo replies back from bnx0. This doesn't seem correct.</p>
<p>I tried Linux and OpenBSD in place of the DragonFly BSD box and they do not behave like this. They send only one<br />ICMP echo reply.</p>
<p>Is anything I am missing?</p> DragonFlyBSD - Submit #2818 (Closed): Add utimensat() supporthttps://bugs.dragonflybsd.org/issues/28182015-05-21T15:07:39Zstateless
<p>There is more work to be done in this area. The next step is to<br />convert kern_utimes() to work on a timespec structure and update callers<br />to use timespec.</p>
<p>The last step is to add support for futimens(2) on top of the refactored<br />kern_utimes().</p>
<p>I've tried to test all corner-cases in this patch. It seems to work but more<br />eyes would be helpful.</p> DragonFlyBSD - Bug #2817 (Resolved): Permission checking for utimes(2) and friends are not proper...https://bugs.dragonflybsd.org/issues/28172015-05-21T14:59:18Zstateless
<p>Changing the access and modification times of a file to anything other than<br />the current time can only be done by the owner of the file or the super-user as per<br />POSIX.</p>
<p>At present it is possible to do so just by having write access to the file.</p>
<p>A simple example follows:</p>
<p>touch foo; chown root:user foo; chmod 664 foo; touch -t 200805101024 foo</p>
<p>The last operation should normally fail.</p>
<p>I noticed this as part of my work on adding support for utimensat(). I believe<br />the fix can be consolidated outside of the implementation of the utimes/utimensat<br />system calls.</p>