On Fri, May 14, 2021 at 07:29:48AM +0200, Matthias Pressfreund wrote:
> Interesting. How do I figure the correct order of keywords? So far I thought
> it
> didn't matter.
for the kernel, the order doesn't matter.
for people reviewing code, it matters.
> On 2021-05-13 18:40, Theo de Raadt wrote
Interesting. How do I figure the correct order of keywords? So far I thought it
didn't matter.
On 2021-05-13 18:40, Theo de Raadt wrote:
> + if (pledge("stdio rpath inet recvfd sendfd "
> + "wpath cpath proc tty getpw", NULL) == -1)
On 2021-04-03, Michael Forney wrote:
> On 2020-01-28, Michael Forney wrote:
>> On 2019-05-28, Michael Forney wrote:
>>> I noticed that OpenBSD's fscanf doesn't yet support hex float strings,
>>> which are standardized in C99. I am using them in my application (which
>>> I would like to support O
On Thu, May 13, 2021 at 10:40:40AM -0600, Theo de Raadt wrote:
> + if (pledge("stdio rpath inet recvfd sendfd "
> + "wpath cpath proc tty getpw", NULL) == -1)
>
> Please change the order:
>
> stdio rpath wpath cpath inet recvfd sendf
Hi,
Here a diff for www page: FAQ > PF:perf
Just a typo.
Right?
Index: faq/pf/perf.html
===
RCS file: /cvs/www/faq/pf/perf.html,v
retrieving revision 1.45
diff -u -r1.45 perf.html
--- faq/pf/perf.html5 May 2021 21:49:29 -0
ping?
On Tue, May 04, 2021 at 10:50:50AM +0200, Jan Klemkow wrote:
> Hi,
>
> The following diff adds some missing consts for char * to the internal
> program functions.
>
> OK?
>
> bye,
> Jan
>
> Index: extern.h
> ===
> RCS file:
ping?
On Sat, May 01, 2021 at 11:19:56AM +0200, Jan Klemkow wrote:
> Hi,
>
> This cleanup diff, removes a useless if islower(3) from the loop. It is
> guarantee by toupper(3) that no character will be changed if its not a
> lower one.
>
> man toupper(3):
> The toupper() and toupper_l() fun
ping?
On Wed, May 05, 2021 at 04:42:49PM +0200, Jan Klemkow wrote:
> Hi,
>
> The function lreply() already calls fflush(3) on stdout. So, this calls
> are useless.
>
> OK?
>
> bye,
> Jan
>
> Index: ftpd.c
> ===
> RCS file: /cvs/s
Hi,
This is the first attempt to bring pledge into ftpd. The Main ftpd
process can't use pledge for now because of possible chroot(2) calls.
But, the two forks after user login are pledged with this diff.
I tested it manually and with the ftpd's regression tests.
OK?
bye,
Jan
Index: monitor.c
On Thu, May 13, 2021 at 11:08:25AM -0500, Scott Cheloha wrote:
> > On May 13, 2021, at 10:57 AM, Visa Hankala wrote:
> >
> > On Thu, May 13, 2021 at 12:04:57AM -0500, Scott Cheloha wrote:
> >> The funky locking dance in softclock() and softclock_thread() is
> >> needed to keep from violating the
+ if (pledge("stdio rpath inet recvfd sendfd "
+ "wpath cpath proc tty getpw", NULL) == -1)
Please change the order:
stdio rpath wpath cpath inet recvfd sendfd proc tty getpw
(It remains extremely permissive).
> On May 13, 2021, at 10:57 AM, Visa Hankala wrote:
>
> On Thu, May 13, 2021 at 12:04:57AM -0500, Scott Cheloha wrote:
>> The funky locking dance in softclock() and softclock_thread() is
>> needed to keep from violating the locking hierarchy. The
>> timeout_mutex is above the kernel lock, so we
On Thu, May 13, 2021 at 12:04:57AM -0500, Scott Cheloha wrote:
> The funky locking dance in softclock() and softclock_thread() is
> needed to keep from violating the locking hierarchy. The
> timeout_mutex is above the kernel lock, so we need to leave the
> timeout_mutex, then drop the kernel lock,
I guess this diff would skip sending the early events. You don't show how
it is used, in which drivers it is used, nor how they are modified to send
replacements for the skipped messages.
And then you would modify specific drivers to not send the early events,
and instead use an additional API fo
It looks that re_rxeof() might leak mbufs in two cases. The first case
happens if the controller returns an incomplete frame when frames are
expected to be non-fragmented. Note that in this instance the fragment
list sc->rl_head should be empty and does not need clearing.
The second leak happens i
On Thu, May 13, 2021 at 01:15:05PM +0200, Hrvoje Popovski wrote:
> On 13.5.2021. 1:25, Vitaliy Makkoveev wrote:
> > It seems this lock order issue is not parallel diff specific.
>
>
>
> Yes, you are right ... it seemed familiar but i couldn't reproduce it
> on lapc trunk or without this diff so
On 13.5.2021. 1:25, Vitaliy Makkoveev wrote:
> It seems this lock order issue is not parallel diff specific.
Yes, you are right ... it seemed familiar but i couldn't reproduce it
on lapc trunk or without this diff so i thought that parallel diff is
one to blame ..
sorry for noise ..
On Thu, May 13 2021, Jeremie Courreges-Anglas wrote:
> On Wed, May 12 2021, Scott Cheloha wrote:
>> Hi,
>>
>> In a separate mail thread, bluhm@ mentioned that panic(9) does not
>> cleanly handle multiple CPUs entering it simultaneously:
>>
>> https://marc.info/?l=openbsd-tech&m=161908805925325&w=
On Wed, May 12 2021, Scott Cheloha wrote:
> Hi,
>
> In a separate mail thread, bluhm@ mentioned that panic(9) does not
> cleanly handle multiple CPUs entering it simultaneously:
>
> https://marc.info/?l=openbsd-tech&m=161908805925325&w=2
>
> I'm unsure which part of panic(9) is causing the problem
On Wed, May 12, 2021 at 07:08:39PM -0500, Scott Cheloha wrote:
> I'm unsure which part of panic(9) is causing the problem he mentions,
I was talking about this:
r620-1# papnpaiancini:cc :p :op
opooolo_llc_ac_caccahhceh_ei_eti_tieetmme_mm__amgamigacigci__cc_hccehhcekcekc::
k :m bmubmfubfuppflp ll
On Thu, May 13, 2021 at 09:20:22AM +0900, YASUOKA Masahiko wrote:
> On Wed, 12 May 2021 19:11:09 +0900 (JST)
> YASUOKA Masahiko wrote:
> > Radek reported a problem to misc@ that multiple Windows clients behind
> > a NAT cannot use a L2TP/IPsec server simultaneously.
> >
> > https://marc.info/?t=1
Last year Andrew Forgue pointed out that rad(8) does not respond to
Router Solicitations from
::. ( https://marc.info/?l=openbsd-bugs&m=157820352329054&w=2 )
They also pointed out that RFC 4861 4.1 allows solicitations from the
unspecified address:
Source Address
An IP ad
22 matches
Mail list logo
