On Tue, Jul 08, 2014 at 09:41:08PM -0500, Adam Thompson wrote:
> On 5.4-RELEASE, I'm trying to use growfs to expand a root filesystem. I've
> grown the disk from 2GB to 10GB, I've used disklabel(8) to adjust the
> OpenBSD area and the size of partition 'a'. All those numbers line up.
> Rebooting
The current divert(4) implementation allocates an mbuf tag in pf_test()
to store the divert port specified by a divert-packet PF rule.
The divert_packet() function then looks up that mbuf tag to retrieve the
divert port number before sending the packet to userspace.
As far as I can tell, this app
On 5.4-RELEASE, I'm trying to use growfs to expand a root filesystem.
I've grown the disk from 2GB to 10GB, I've used disklabel(8) to adjust
the OpenBSD area and the size of partition 'a'. All those numbers line up.
Rebooting into bsd.rd, copying /sbin/growfs to the ramdisk, and then
using it (
On Tue, Jul 8, 2014 at 9:59 PM, Brian Callahan wrote:
> Hi everyone --
>
> port-modules.5 is missing an "If" to make a complete sentence.
> OK?
ok daniel@
>
> ~Brian
>
> Index: port-modules.5
> ===
> RCS file: /cvs/src/share/man/man
Hi everyone --
port-modules.5 is missing an "If" to make a complete sentence.
OK?
~Brian
Index: port-modules.5
===
RCS file: /cvs/src/share/man/man5/port-modules.5,v
retrieving revision 1.172
diff -u -p -r1.172 port-modules.5
--- p
On Tue, Jul 8, 2014 at 3:51 PM, Philip Guenther wrote:
> * using atomics when we don't even have correct process-pending signals
> risks a solution that
>doesn't work when more than one pending set has to be examined.
I'll hold off on this until we have process-pending signals then.
On Mon, Jul 7, 2014 at 1:46 PM, Matthew Dempsky wrote:
> p_sigmask is only modified by the owning thread from process context
> (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
> but it can be accessed anywhere (e.g., interrupts or threads on other
> CPUs). Currently sys_sigp
> Date: Tue, 8 Jul 2014 09:22:41 +0200 (CEST)
> From: Stefan Fritsch
>
> Hi,
>
> I have been trying to increase fork performance of openbsd/amd64 on KVM.
> It turns out that when I increase the number of CPUs of a VM from 1 to 3,
> a fork+exit micro benchmark is slowed down by a factor of 7.
>
This makes ifconfig scan indicate the type of encryption used on a network.
To make this work, the kernel must fill in RSN info every time it runs
a scan, not just if wpa was already enabled (i.e. the IEEE80211_F_RSNON
flag is already set).
While here, add missing definition for IEEE80211_WPA_CIP
Updated diff below with the following changes:
- p_sigmask is now volatile, per kettenis's request
- kern_fork.c's memcpy() for p_startcopy needs to cast away the
volatile now
- kettenis pointed out atomic_swap_uint() isn't safe to use in MI code
yet, so for now proc_sigsetmask() just relies o
Hi!
This diff adds a "-U" flag to dump that allows using disklabel
UIDs in /etc/dumpdates. That makes incremental dumps possible when a
disk is roaming between device files.
I'd be happy to receive comments.
Also, sorry for the noise in misc, and thanks to everyone pointing me
in the right direc
> how would you like your deadbeef? well done?
>
> since we support variable poison values, we should invert the patterns
> sometimes to find bugs where the deadbeef values hide the bugs. (we
> can of course do even more with extra tricksy bit patterns, but start
> with this.)
I have been worried
how would you like your deadbeef? well done?
since we support variable poison values, we should invert the patterns
sometimes to find bugs where the deadbeef values hide the bugs. (we
can of course do even more with extra tricksy bit patterns, but start
with this.)
Index: subr_poison.c
==
On Tue, Jul 8, 2014 at 12:28 PM, Mark Kettenis wrote:
> With that explanation, this sounds a lot more reasonable.
Ah, good. :) Sorry, I should have mentioned up front the followup
steps I had planned and the rationale for taking this path.
On Tue, Jul 08, 2014 at 03:01:58PM -0400, Ted Unangst wrote:
> I think it's safe to just have one goto label? free(NULL) is fine.
That's true. If we go into that direction, we can also use the cleanup
function that would be done at the end of directory processing.
Also put two variables static t
>
> On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis
> wrote:
> > I disagree with this diff. We should discourage the use of GNU
> > extensions in our kernel. Therefore I think std=gnu99 would give the
> > wrong signal.
>
> Can you clarify your concern? Currently we're (implicitly) compiling
>
On Tue, Jul 8, 2014 at 12:03 PM, Mark Kettenis wrote:
> I disagree with this diff. We should discourage the use of GNU
> extensions in our kernel. Therefore I think std=gnu99 would give the
> wrong signal.
Can you clarify your concern? Currently we're (implicitly) compiling
with -std=gnu89, wh
> Date: Tue, 8 Jul 2014 09:05:38 -0700
> From: Matthew Dempsky
>
> On Tue, Jul 8, 2014 at 1:29 AM, Mark Kettenis wrote:
> >> Date: Mon, 7 Jul 2014 13:46:03 -0700
> >> From: Matthew Dempsky
> >>
> >> p_sigmask is only modified by the owning thread from process context
> >> (e.g., sys_sigprocmask
> Date: Tue, 8 Jul 2014 11:17:35 -0700
> From: Matthew Dempsky
>
> Diff below converts the kernel to build with -std=gnu99. (For
> simplicity, I've only included amd64 for now, but I'll make the same
> change to all kernel Makefiles if this is ok.)
>
> The only incompatibility (that I'm aware o
On Mon, Jun 30, 2014 at 21:26, Tobias Stoeckmann wrote:
> Hi,
>
> this diff merges NetBSD's revision 1.20 into our tree: There are
> some memory leaks in resetDosDirSection.
>
> This is not a simple merge, I have added some things:
>
> - rootDir was not properly freed in NetBSD's commit
> (actu
On Thu, Jun 26, 2014 at 13:43, Arne Becker wrote:
> Hi.
>
>> Now soliciting diffs to change readwrite to a loop with two buffers
>> that poll()s in all four directions. :)
>
> Good thing you made me remember I wrote just this a while ago.
> This is my first OpenBSD diff, so tell me if I missed a
Diff below converts the kernel to build with -std=gnu99. (For
simplicity, I've only included amd64 for now, but I'll make the same
change to all kernel Makefiles if this is ok.)
The only incompatibility (that I'm aware of) is that ISO C99's inline
semantics differ slightly from GNU C89's historic
It's rare, but there *are* cases where a thread wants to sleep and
doesn't expect any wakeup() calls at all; e.g., nanosleep() and
sigsuspend(). In these cases, there's no point in requiring a valid
wait channel identifier or adding the thread to the sleep queue.
Diff below explicitly allows tsle
On Tue, Jul 8, 2014 at 1:29 AM, Mark Kettenis wrote:
>> Date: Mon, 7 Jul 2014 13:46:03 -0700
>> From: Matthew Dempsky
>>
>> p_sigmask is only modified by the owning thread from process context
>> (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
>> but it can be accessed anywhe
On Tue, Jul 8, 2014 at 1:21 AM, Martin Pieuchot wrote:
> There was a previous attempt to mark sigpromask(2) as nolock but if I
> recall properly setting p_sigmask atomically is not enough and there's
> still a possible race in ptsignal().
>
> Have you looked into this function, is it safe now?
I
I'll need this for some upcoming changes, at least to do it WITHOUT
adding the 3rd or 4th or 5th copy of the bpf_mtap loop. most of these
bpf_mtap_* are almost identical, minor differences in what to prepend,
and foremost: passing custom copy functions. since bpf_mtap is all
over the place I made b
> Date: Mon, 7 Jul 2014 13:46:03 -0700
> From: Matthew Dempsky
>
> p_sigmask is only modified by the owning thread from process context
> (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
> but it can be accessed anywhere (e.g., interrupts or threads on other
> CPUs). Currentl
On 07/07/14(Mon) 13:46, Matthew Dempsky wrote:
> p_sigmask is only modified by the owning thread from process context
> (e.g., sys_sigprocmask(), sys_sigreturn(), userret(), or postsig()),
> but it can be accessed anywhere (e.g., interrupts or threads on other
> CPUs). Currently sys_sigprocmask()
Hi,
I have been trying to increase fork performance of openbsd/amd64 on KVM.
It turns out that when I increase the number of CPUs of a VM from 1 to 3,
a fork+exit micro benchmark is slowed down by a factor of 7.
The main reason for this seems to be a very large number of cross-CPU TLB
flushes
29 matches
Mail list logo
