Just an INFSLP, easy.
ok?
Index: pci/pci.c
===
RCS file: /cvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.114
diff -u -p -r1.114 pci.c
--- pci/pci.c 25 Jun 2019 16:46:32 - 1.114
+++ pci/pci.c 15 Jan 2020 06:51:29
Given the SCSI_NOSLEEP split here I think the simplest thing we can do
is ask to sleep as much as we delay(9).
The question is: if you *could* poll in 10us intervals here with
tsleep_nsec(9), would you want to? If so, then this works. If
not, what is a more appropriate interval?
Index:
First, the tsleep(9) calls. These are easy. If cold != 0 we
delay(9), so just do the equivalent thing with tsleep_nsec(9).
Next, the msleep(9). If I understand correctly, in hvn_alloc_cmd()
we're waiting to pull something off a freelist. The freelist,
sc->sc_cntl_fq, is protexted by the mutex
On Tue Jan 14, 2020 at 12:40 PM, Theo de Raadt wrote:
> >
> > Channeling a conversation from 15 years ago: "How about wpakeyfile"
>
>
>
>
> Another consideration is... many of these passwords are locked to narrow
> usage cases, so does it really matter all that much?
>
>
Right, seems like I
Hi Stefan,
On Tue Jan 14, 2020 at 2:40 PM, Stefan Sperling wrote:
>
<... lots of useful stuff ...>
>
That was exactly the sort of thing I was looking for. Thanks!
It was seeing your device drivers presentation on Youtube a
week or so ago that originally inspired me to get stuck in, so
thanks
Here's another tsleep(9) -> tsleep_nsec(9) conversion.
The first chunk is easy: ticks to seconds.
The second chunk looks fishy, though.
aac_wait_command() calls tsleep(9) with a timeout in ticks, but the
only caller of aac_wait_command() uses a scsi_xfer.timeout as the
timeout, and if I'm
On Wed, Jan 15, 2020 at 01:26:53AM +0100, Klemens Nanni wrote:
> Replace the very same error message strlcpy() uses earlier. This makes
> it easier to distinguish and does not hide different errors behind the
> same generic one.
>
> For example, it turns
>
> # route -qn add -inet6 fec0::%
Ticks to milliseconds.
I've changed "tic" to "msecs" in the backoff loop to make the units
more obvious. I went with 10ms as the starting sleep. A perfect
conversion would start at something like (tick / 1000), but obviously
we're trying to move away from that sort of thing. Absent a better
Replace the very same error message strlcpy() uses earlier. This makes
it easier to distinguish and does not hide different errors behind the
same generic one.
For example, it turns
# route -qn add -inet6 fec0::% -prefixlen 10 ::1 -reject
route: fec0::%: bad value
into
On Tue, Jan 14, 2020 at 11:54:32PM +0100, Klemens Nanni wrote:
> Came here while testing an IPv6 related sys/net/rtsock.c diff: all
> invocations use `-q' and route(8) says
>
>-q Suppress all output.
>
> so the redirection is duplicate. If route still prints to standard
> output
On Tue, Jan 14, 2020 at 5:11 PM Stefan Sperling wrote:
> On Tue, Jan 14, 2020 at 12:34:29PM -0700, Theo de Raadt wrote:
> > Channeling a conversation from 15 years ago: "How about wpakeyfile"
>
> ifconfig wpakeyfile would be trivial to add if we really want it.
>
But how will hostname.if will
On Tue, Jan 14, 2020 at 12:34:29PM -0700, Theo de Raadt wrote:
> Channeling a conversation from 15 years ago: "How about wpakeyfile"
ifconfig wpakeyfile would be trivial to add if we really want it.
The downside is loss of unveil, here handled the same way as for the
bridge rulesfile. Looks like
Came here while testing an IPv6 related sys/net/rtsock.c diff: all
invocations use `-q' and route(8) says
-q Suppress all output.
so the redirection is duplicate. If route still prints to standard
output despite the quiet flag I want to see such a bug and fix it.
Note that
On Mon, Jan 13, 2020 at 06:32:00PM -0600, Scott Cheloha wrote:
> These sleeps don't have units, though in practice they are 1 second.
> Just prior in the code I see a delay(9) of 100 microseconds. Is the
> 100 ticks here a typo? What is a reasonable sleep duration for this
> hardware?
Both of
On 2020/01/14 21:48, Stuart Henderson wrote:
> On 2020/01/14 21:03, Tobias Heider wrote:
> > On Tue, Jan 14, 2020 at 09:17:11AM -0700, Theo de Raadt wrote:
> > > Stuart Henderson wrote:
> > >
> > > > On 2020/01/13 20:51, Klemens Nanni wrote:
> > > > > I'm in favour of removing the option and OK
On 2020/01/14 21:03, Tobias Heider wrote:
> On Tue, Jan 14, 2020 at 09:17:11AM -0700, Theo de Raadt wrote:
> > Stuart Henderson wrote:
> >
> > > On 2020/01/13 20:51, Klemens Nanni wrote:
> > > > I'm in favour of removing the option and OK with your diff, but simply
> > > > removing it is
On Tue, Jan 14, 2020 at 09:03:04PM +0100, Tobias Heider wrote:
> Makes sense. I added a warning and a notice in current.html.
OK kn
Thanks for the diff, commited.
Sebastian Benoit(be...@openbsd.org) on 2020.01.14 21:14:44 +0100:
> seems sensible.
>
> ok benno@
>
>
> Tracey Emery(tra...@traceyemery.net) on 2020.01.14 13:08:03 -0700:
> > Hello,
> >
> > In the server_response function of httpd, the if comparison to
> >
seems sensible.
ok benno@
Tracey Emery(tra...@traceyemery.net) on 2020.01.14 13:08:03 -0700:
> Hello,
>
> In the server_response function of httpd, the if comparison to
> srv_conf->maxrequests is using the wrong value. The value is derived from the
> first server configuration in httpd.conf,
Hello,
In the server_response function of httpd, the if comparison to
srv_conf->maxrequests is using the wrong value. The value is derived from the
first server configuration in httpd.conf, since we still don't know which server
name the client is requesting.
This small diff moves
On Tue, Jan 14, 2020 at 09:17:11AM -0700, Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2020/01/13 20:51, Klemens Nanni wrote:
> > > I'm in favour of removing the option and OK with your diff, but simply
> > > removing it is probably a bad idea given its nature.
> > >
> > > What about
Theo de Raadt wrote:
> Stuart Henderson wrote:
>
> > On 2020/01/14 10:27, Theo de Raadt wrote:
> > > Unfortunate part of this diff is that the password is (very
> > > momentarily) visible with ps(1) in the root-run ifconfig argv[] array.
> > > It's a tight race, but still it is visible.
> > >
On Mon, Jan 13, 2020 at 10:30:11AM -0700, Todd C. Miller wrote:
> On Mon, 13 Jan 2020 13:45:55 +0100, Jan Klemkow wrote:
>
> > This diff simplifies globbing for the ftpd(8) ls and stat command. And
> > it avoids to glob for the parameters "-lgA".
> >
> > Due, we just pass a single string to the
Stuart Henderson wrote:
> On 2020/01/14 10:27, Theo de Raadt wrote:
> > Unfortunate part of this diff is that the password is (very
> > momentarily) visible with ps(1) in the root-run ifconfig argv[] array.
> > It's a tight race, but still it is visible.
> >
> > People do run "sh /etc/netstart
On 2020/01/14 10:27, Theo de Raadt wrote:
> Unfortunate part of this diff is that the password is (very
> momentarily) visible with ps(1) in the root-run ifconfig argv[] array.
> It's a tight race, but still it is visible.
>
> People do run "sh /etc/netstart umb0" to activate the interface
>
On Tue, Jan 14, 2020 at 06:12:27PM +0100, Peter Hessler wrote:
> Updated diff
>
>
Look good. Thanks!
ok stsp@
> Index: net80211/ieee80211_ioctl.c
> ===
> RCS file: /home/cvs/openbsd/src/sys/net80211/ieee80211_ioctl.c,v
>
On Mon, Jan 13, 2020 at 12:20:10PM +0100, Patrick Wildt wrote:
> The problem is that the last two values are 67 and 100. If you go
> 5% down, it's 95. The nearest will still be 100. The code then
> realizes that it's the same level as before, and does nlevel--.
> But nlevel-- is 99, and not 67,
On Tue, Jan 14, 2020 at 01:32:50PM -0500, Ted Unangst wrote:
> Alexander Bluhm wrote:
> > loop:
> > - TAILQ_FOREACH_SAFE(vp, >mnt_vnodelist, v_mntvnodes, nvp) {
> > + TAILQ_FOREACH(vp, >mnt_vnodelist, v_mntvnodes) {
> > if (vp->v_mount != mp) /* Paranoia */
> >
Alexander Bluhm wrote:
> Hi,
>
> There is no remove and no sleep in this loop. So _SAFE is unnecessary.
>
> ok?
sure, with one bonus note.
>
> bluhm
>
> Index: nfs/nfs_subs.c
> ===
> RCS file:
On Tue, Jan 14, 2020 at 11:05:38AM -0700, Theo de Raadt wrote:
> Some of the pledges (such as "pf") exist to support a cluster of
> programs -- not just 1 program -- and improve their security by limiting
> what they can do. So that when the program gets subverted due something
> on it's input,
> I'm in the process of building a program that adds IP addresses to a table,
> from the network, It is HMAC'ed.
>
> I was stopped by a pledge, it seems it was not configured. Here is the
> ktrace snippet:
>
> 40051 table-server CALL open(0xbb705fb11f6,0x2)
> 40051 table-server NAMI
Hi,
I'm in the process of building a program that adds IP addresses to a table,
from the network, It is HMAC'ed.
I was stopped by a pledge, it seems it was not configured. Here is the
ktrace snippet:
40051 table-server CALL open(0xbb705fb11f6,0x2)
40051 table-server NAMI "/dev/pf"
40051
Unfortunate part of this diff is that the password is (very
momentarily) visible with ps(1) in the root-run ifconfig argv[] array.
It's a tight race, but still it is visible.
People do run "sh /etc/netstart umb0" to activate the interface
during multiuser.
If the password is truly sensitive, it
Mark Kettenis wrote:
> > Date: Tue, 14 Jan 2020 10:34:05 +1100
> > From: Jonathan Gray
> >
> > On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> > > I'm facing a lock ordering issue while profiling the scheduler which
> > > cannot be solved without using a different lock for
On 2020 Jan 14 (Tue) at 13:11:57 +0100 (+0100), Stefan Sperling wrote:
:On Mon, Jan 13, 2020 at 10:38:35PM +0100, Peter Hessler wrote:
:> On 2020 Jan 12 (Sun) at 21:39:19 +0100 (+0100), Peter Hessler wrote:
:> :When we change attributes for a join essid, we should apply the change
:> :immediately
On Tue, Jan 14, 2020 at 02:40:45PM +0100, Stefan Sperling wrote:
> On Tue, Jan 14, 2020 at 09:51:05PM +0900, leeb wrote:
> > Hello again tech@
> >
> > I've included diffs of what I've got so far at the bottom
> > of this mail, but first a couple of questions:
> >
> > - Using the full
> Date: Tue, 14 Jan 2020 10:34:05 +1100
> From: Jonathan Gray
>
> On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> > I'm facing a lock ordering issue while profiling the scheduler which
> > cannot be solved without using a different lock for the global sleepqueue
> > and the
On 14/01/20(Tue) 10:34, Jonathan Gray wrote:
> On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> > I'm facing a lock ordering issue while profiling the scheduler which
> > cannot be solved without using a different lock for the global sleepqueue
> > and the runqueues.
> >
> > The
On Jan 13, 2020, at 11:55 AM, Tobias Heider wrote:
>
> Hi,
>
> iked by default blocks all IPv6 traffic on a host unless any
> of the configured policies use v6. This was originally meant
> as a measure to prevent VPN leakage for people who did not
> think of IPv6 when configuring IPsec. With
On 13/01/20(Mon) 21:31, Martin Pieuchot wrote:
> I'd like hardclock() to be free of SCHED_LOCK(), the diff below brings
> us one step away from that goal. Please test with your favorite
> benchmark and report any regression :o)
>
> The reason for moving the SCHED_LOCK() away from hardclock() is
Stuart Henderson wrote:
> On 2020/01/13 20:51, Klemens Nanni wrote:
> > I'm in favour of removing the option and OK with your diff, but simply
> > removing it is probably a bad idea given its nature.
> >
> > What about printing a deprecation warning so that users can safely
> > adjust their
Thanks,
OK kn
Hello
> > >
> > > This reads simpler and clearer to me, what do you think?
> >
> > OK, I'll buy if (...) from you, but '+ 1' must stay there,
> > because it is for a '\0' terminator. So let's go for this:
> > len = strlen(pr->name) + 1;
> > if (pr->path[0])
> > len
On Tue, Jan 14, 2020 at 04:32:41PM +0100, Alexandr Nedvedicky wrote:
> Hello,
>
> On Tue, Jan 14, 2020 at 03:02:09PM +0100, Klemens Nanni wrote:
> > On Mon, Jan 13, 2020 at 10:47:27PM +0100, Alexandr Nedvedicky wrote:
> > > @@ -2182,7 +2182,7 @@ pfctl_walk_get(int opts, struct pfioc_ruleset *pr,
Hello,
On Tue, Jan 14, 2020 at 03:02:09PM +0100, Klemens Nanni wrote:
> On Mon, Jan 13, 2020 at 10:47:27PM +0100, Alexandr Nedvedicky wrote:
> > @@ -2182,7 +2182,7 @@ pfctl_walk_get(int opts, struct pfioc_ruleset *pr,
> > void *warg)
> > if (pfra == NULL)
> > err(1, "%s",
On Mon, Jan 13, 2020 at 05:02:12PM +0100, Martin Pieuchot wrote:
> I'm facing a lock ordering issue while profiling the scheduler which
> cannot be solved without using a different lock for the global sleepqueue
> and the runqueues.
>
> The SCHED_LOCK() currently protects both data structures as
Hi,
There is no remove and no sleep in this loop. So _SAFE is unnecessary.
ok?
bluhm
Index: nfs/nfs_subs.c
===
RCS file: /data/mirror/openbsd/cvs/src/sys/nfs/nfs_subs.c,v
retrieving revision 1.141
diff -u -p -r1.141 nfs_subs.c
On 2020/01/13 23:31, Sebastian Benoit wrote:
> Alexander Bluhm(alexander.bl...@gmx.net) on 2020.01.13 18:19:31 +0100:
> > On Mon, Jan 13, 2020 at 05:55:06PM +0100, Tobias Heider wrote:
> > > I think we should discuss whether we can remove the flow
> > > (and the -6 flag) as I constantly hear
Alexander Bluhm(alexander.bl...@gmx.net) on 2020.01.13 18:19:31 +0100:
> On Mon, Jan 13, 2020 at 05:55:06PM +0100, Tobias Heider wrote:
> > I think we should discuss whether we can remove the flow
> > (and the -6 flag) as I constantly hear people complaining
> > that it broke their setups and I
On Mon, Jan 13, 2020 at 12:20:10PM +0100, Patrick Wildt wrote:
> The problem is that the last two values are 67 and 100. If you go
> 5% down, it's 95. The nearest will still be 100. The code then
> realizes that it's the same level as before, and does nlevel--.
> But nlevel-- is 99, and not 67,
These sleeps don't have units, though in practice they are 1 second.
Just prior in the code I see a delay(9) of 100 microseconds. Is the
100 ticks here a typo? What is a reasonable sleep duration for this
hardware?
Index: pci/qle.c
On 2020/01/13 18:19, Alexander Bluhm wrote:
> On Mon, Jan 13, 2020 at 05:55:06PM +0100, Tobias Heider wrote:
> > I think we should discuss whether we can remove the flow
> > (and the -6 flag) as I constantly hear people complaining
> > that it broke their setups and I don't think anyone
> >
I like the idea. Unfortunately the diff does not apply.
On Thu, Jan 09, 2020 at 06:10:24AM +0100, Nazar Zhuk wrote:
> httpd(8) expects FastCGI processes to have the same chroot as httpd. I
> propose a feature that allows multiple FastCGI processes chrooted in
> separate directories under /var/www
On Mon, Jan 13, 2020 at 10:47:27PM +0100, Alexandr Nedvedicky wrote:
> @@ -2182,7 +2182,7 @@ pfctl_walk_get(int opts, struct pfioc_ruleset *pr, void
> *warg)
> if (pfra == NULL)
> err(1, "%s", __func__);
>
> - len = strlen(pr->path) + 1;
> + len = (pr->path[0] ==
| > >
| > > This email should be gold plated and moved to a permanent location in
| > > the FAQ on how to help OpenBSD and how to request new features.
| > >
| >
| > Please refrain from ridiculing people with good intentions.
| >
| I originally read Anders' mail as complimentary, but now
On 2020/01/14 00:54, leeb wrote:
> On Mon, Jan 13, 2020 at 04:42:22PM +0100, Martijn van Duren wrote:
> > On 1/13/20 4:30 PM, Anders Andersson wrote:
> > > On Mon, Jan 13, 2020 at 3:00 PM leeb wrote:
> > >>
> > >> Hello,
> > >>
>
> > >>
> > >> Thanks,
> > >>
> > >> Lee.
> > >
> > > This
Ticks to milliseconds. Original sleep is half a second, so 500ms.
ok?
Index: mii/mii_physubr.c
===
RCS file: /cvs/src/sys/dev/mii/mii_physubr.c,v
retrieving revision 1.45
diff -u -p -r1.45 mii_physubr.c
--- mii/mii_physubr.c 11
On Tue, Jan 14, 2020 at 09:51:05PM +0900, leeb wrote:
> Hello again tech@
>
> I've included diffs of what I've got so far at the bottom
> of this mail, but first a couple of questions:
>
> - Using the full 510-character limits for username and
> passphrase specified in the MBIM spec, kernel
I'd like hardclock() to be free of SCHED_LOCK(), the diff below brings
us one step away from that goal. Please test with your favorite
benchmark and report any regression :o)
The reason for moving the SCHED_LOCK() away from hardclock() is because
it will allow us to re-commit the diff moving
The convoluted logic that resets must_make does not make any sense to me.
It's just as simple to set built_status to ABORTED directly.
Note that in the compat make case, there are two instances of using
must_make left, one in arch.c, which I have yet to understand, and one
in
Hello,
> > + unsigned int len;
> strlen(3) returns size_t, malloc(3) takes it.
makes sense>
>
> > + struct pfr_anchors *anchors;
> > +
> > + anchors = (struct pfr_anchors *) warg;
> > +
> > + pfra = malloc(sizeof(*pfra));
> > + if (pfra == NULL)
> > + err(1, "%s",
Hello,
Some time ago I've tripped over ASSERT() in pf_state_key_link_reverse(), when
testing my changes to pfsync. I was using HP 710 systems with 8 cores I got
from Hrvoje. The panic happened rarely when running performance tesst over 10Gb
interfaces.
At time of panic the firewall was running
On Mon, Jan 13, 2020 at 10:38:35PM +0100, Peter Hessler wrote:
> On 2020 Jan 12 (Sun) at 21:39:19 +0100 (+0100), Peter Hessler wrote:
> :When we change attributes for a join essid, we should apply the change
> :immediately instead of waiting to (randomly) switch away and switch
> :back.
>
> And
On Mon, Nov 18, 2019 at 02:56:46PM +0900, SASANO Takayoshi wrote:
> At least OpenBSD-6.5 and 6.6's ftpd does not work NLIST command with
> any -option like this.
>
>
> ftp> nlist
> 150 Opening ASCII mode data connection for 'file list'.
> uaa
> _sysupgrade
> 226 Transfer complete.
> ftp>
On 2020 Jan 12 (Sun) at 21:39:19 +0100 (+0100), Peter Hessler wrote:
:When we change attributes for a join essid, we should apply the change
:immediately instead of waiting to (randomly) switch away and switch
:back.
And if we are connected to an AP, remove the node from the cache so we
can
Hello again tech@
I've included diffs of what I've got so far at the bottom
of this mail, but first a couple of questions:
- Using the full 510-character limits for username and
passphrase specified in the MBIM spec, kernel compilation
fails due to tripping the 2047-byte stack frame warning
66 matches
Mail list logo
