[Bug 237463] aacraid(4) doesn't work on powerpc64

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237463

--- Comment #14 from commit-h...@freebsd.org ---
A commit references this bug:

Author: luporl
Date: Wed Mar  4 12:21:38 UTC 2020
New revision: 358613
URL: https://svnweb.freebsd.org/changeset/base/358613

Log:
  [aacraid] Add missing unmap call for SYNC mode

  This issue was observed on a PowerPC64 machine with an Adaptec RAID
Controller
  with PCI device ID 0x028d. After several read/write operations, the kernel
was
  panic'ing in bus_dmamap_sync(). This was due to a missing aac_unmap_command()
  in the SYNC path.

  PR:   237463
  Reviewed by:  jhibbits
  Differential Revision:https://reviews.freebsd.org/D23668

Changes:
  head/sys/dev/aacraid/aacraid.c

-- 
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 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514

ctmin...@yahoo.com changed:

   What|Removed |Added

 Status|Closed  |New
 Resolution|Works As Intended   |---

--- Comment #4 from ctmin...@yahoo.com ---
(In reply to Kristof Provost from comment #2)
I am re-opening this for a couple of reasons:
1. I don't think my previous reply was seen by Kristof (who closed this).
2. It was closed so fast it left NO room for others in the community to comment
3. One person should not be able to dictate weather something gets looked at.

I ask that this be left open for at least a week for commenters. While, the
feature may currently work as intended and documented, this could still be an
improvement on the reply-to feature. And it is my personal opinion (and backed
by RFC) the the behavior I outlined is wrong.

If others think this should be addressed, great. Then it should stay open. If
others think nothing needs/should be done. I will accept the "closed - works as
intended".

-- 
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 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514

--- Comment #5 from Kristof Provost  ---
I have indeed seen your response. There was no need to reopen the issue for
that.
As I'm currently the only maintainer of pf in FreeBSD I don't expect much
follow-up, but I'm happy to leave this open for another week. I will not work
on it.

-- 
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 244596] pkgbase: duplicate files and directories in `make packages`

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244596

Bug ID: 244596
   Summary: pkgbase: duplicate files and directories in `make
packages`
   Product: Base System
   Version: CURRENT
  Hardware: Any
OS: Any
Status: New
  Severity: Affects Only Me
  Priority: ---
 Component: misc
  Assignee: b...@freebsd.org
  Reporter: ema...@freebsd.org

pkgbase `make packages` emits many duplicate file/directory warnings of the
form

pkg: duplicate directory listing: /boot/defaults, ignoring
pkg: duplicate file listing: /etc/libmap.conf, ignoring

In total,
485 duplicate directory
172 duplicate file

in some cases there are multiple lines in METALOG for a file or directory with
different attributes - e.g., ./etc has 80 copies of

./etc type=dir uname=root gname=wheel mode=0755 tags=package=utilities

and one

./etc type=dir uname=root gname=wheel mode=0755

-- 
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 234886] shutdown not installed with setuid bit in pkgbase

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234886

Ed Maste  changed:

   What|Removed |Added

   See Also||https://bugs.freebsd.org/bu
   ||gzilla/show_bug.cgi?id=2445
   ||96

-- 
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 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514

--- Comment #6 from ctmin...@yahoo.com ---
(In reply to Kristof Provost from comment #5)
I did not know there was only 1 maintainer of pf. So, thank you for
entertaining my impertinence. Would you mind pointing out where the reply-to
feature is in the source code? I am not a developer, but just in case someone
else feels inclined to take a look.

-- 
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 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514

--- Comment #7 from Kristof Provost  ---
(In reply to ctminime from comment #6)
There is no one place to look for this. Rules are parsed (at configuration
time) by the code in sbin/pfctl, then passed to the kernel. The code in
sys/netpfil/pf parses packets and decides what actions to take based on those
rules.

Relevant functions are pf_test() and pf_route(), PF_REPLYTO is a useful
constant to look at. This is nontrivial code with subtle edge cases.

-- 
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 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514

p...@itassistans.se changed:

   What|Removed |Added

 CC||p...@itassistans.se

--- Comment #8 from p...@itassistans.se ---
I agree with the earlier comment by Kristof Provost. This is not a FreeBSD bug.

pf is being told to route all reply packets back through a certain gateway, and
that is in fact what it's doing. If the way the administrator configures
FreeBSD violates an RFC, that's on the administrator. There are many ways to
configure firewall rules that go counter to what's written in an RFC, if that's
what you want to do.

It is also conversely possible to configure PF rules that do not cause this
behaviour, if that's what you want to do. If a project or system administrator
that uses pf generates pf rules that end up violating an RFC, it's on whoever's
or whatever writing the rules to write them differently.

In this case the firewall rule is working exactly as intended.

You might be able to argue that it would be useful for pf to have a feature
that would route packets down a certain interface, as opposed to specifically
through a specific gateway, but that would mean talking about introducing a new
feature, rather than changing behaviour of an old one. I think it might be a
good idea, but if you really want pf to do that, you can already do that by
writing rules that handle same-subnet traffic differently to cross-subnet
traffic, although it'd end up a bit messy.

Incidentally, I agree with ctminime's core problem description. The way
OPNsense and pfSense use this feature is bogus. But it has nothing to do with
FreeBSD or pf. It's doing what it's being told, and pf should not second guess
what the administrator is telling it to do. There may be good reasons to
configure your firewall in that way.

-- 
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 244068] Boot environment doesn't work without vfs.root.mountfrom

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244068

greencopperm...@yandex.com changed:

   What|Removed |Added

   Severity|Affects Only Me |Affects Some People

-- 
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 244533] [patch] diff(1) --label not honoured for "print_status"

2020-03-04 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244533

Mark Linimon  changed:

   What|Removed |Added

   Keywords||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"