bpf only reads packets, so we can claim theyre const.
now that we have the caller mark the packet as dropped based on the
return from the tap functions, it simplifies some of the internals
of the bpf code too.
ok?
Index: bpf.c
===
R
Yeah you are. In the context you sent it it sounds mean spirited, not
funny. I know you may not appreciate that not knowing the behind the
scenes issues, but thats how it comes off, and it crossed a bit of a line
with me.
On Monday, 9 May 2016, patrick keshishian wrote:
> I must be missing some
I must be missing something. I thought that was a funny comment from Theo.
--patrick
On 5/9/16, Bob Beck wrote:
> I am gonna say no. i am the bigger holdout for this particular issue than
> theo. he has been working on me quietly behind the scenes to soften me up
> about it while maintaing a
and in case you are wondering, im the one who needs to be convinced to do
all the work for this dangerous little farce.
On Monday, 9 May 2016, Bob Beck wrote:
> I am gonna say no. i am the bigger holdout for this particular issue than
> theo. he has been working on me quietly behind the scenes
I am gonna say no. i am the bigger holdout for this particular issue than
theo. he has been working on me quietly behind the scenes to soften me up
about it while maintaing a stern face publicly to protect his people. you
know what, ill happily pick on theo for eccenticities, and when he is a
di
if I didn't, someone else would.
Index: theo.c
===
RCS file: /cvs/src/usr.bin/mg/theo.c,v
retrieving revision 1.150
diff -u -p -u -p -r1.150 theo.c
--- theo.c 23 Dec 2015 19:37:34 - 1.150
+++ theo.c 10 May 2016 03:0
Hi Mark,
Mark Kettenis wrote on Tue, May 10, 2016 at 12:31:05AM +0200:
> Philip Guenther wrote:
>> On Mon, 9 May 2016, Ingo Schwarze wrote:
>>> The libedit build system is unusual in so far as it compiles almost all
>>> C files (but not all of them) as a single compilation unit, editline.c,
>>>
> Date: Tue, 10 May 2016 00:48:12 +0200
> From: Ingo Schwarze
>
> Hi Mark,
>
> Mark Kettenis wrote on Tue, May 10, 2016 at 12:31:05AM +0200:
> > Philip Guenther wrote:
> >> On Mon, 9 May 2016, Ingo Schwarze wrote:
>
> >>> The libedit build system is unusual in so far as it compiles almost all
> Date: Mon, 9 May 2016 14:47:39 -0700
> From: Philip Guenther
>
> On Mon, 9 May 2016, Ingo Schwarze wrote:
> > The libedit build system is unusual in so far as it compiles almost all
> > C files (but not all of them) as a single compilation unit, editline.c,
> > that #includes most of the othe
On Mon, 9 May 2016, Ingo Schwarze wrote:
> The libedit build system is unusual in so far as it compiles almost all
> C files (but not all of them) as a single compilation unit, editline.c,
> that #includes most of the other *.c files.
...
> I'd prefer compiling all modules seperately, like we do
Hi,
The libedit build system is unusual in so far as it compiles almost
all C files (but not all of them) as a single compilation unit,
editline.c, that #includes most of the other *.c files.
The main motivation for this quirk was to make sure that symbols
of the internal interfaces between the v
> > From: Miod Vallat
> > Date: Mon, 9 May 2016 18:08:03 + (UTC)
> >
> > > This is just a draft.
> > >
> > > Index: arch/hppa/hppa/machdep.c
> >
> > > @@ -1329,11 +1330,31 @@ sys_sigreturn(struct proc *p, void *v, r
> > > struct trapframe *tf = p->p_md.md_regs;
> > > int error;
> > >
>
> From: Miod Vallat
> Date: Mon, 9 May 2016 18:08:03 + (UTC)
>
> > This is just a draft.
> >
> > Index: arch/hppa/hppa/machdep.c
>
> > @@ -1329,11 +1330,31 @@ sys_sigreturn(struct proc *p, void *v, r
> > struct trapframe *tf = p->p_md.md_regs;
> > int error;
> >
> > + if (PROC_PC
Hello,
The function ber_free_elements() sets the variable ber to NULL in most
error cases and calls ber_free_elements(ber). This causes a NULL
dereference in ber_free_elements. This patch fix that problem.
bye,
Jan
Index: ber.c
==
I've been routinely building ports with it over the last week.
It's not bump-free *yet* but it works, and it's going to get better.
One good reason it's useful is because it allows people to use the same
platform to build ports that they're running stuff on. Keeping the ports
isolated in a corner
> This is just a draft.
>
> Index: arch/hppa/hppa/machdep.c
> @@ -1329,11 +1330,31 @@ sys_sigreturn(struct proc *p, void *v, r
> struct trapframe *tf = p->p_md.md_regs;
> int error;
>
> + if (PROC_PC(p) != (u_int64_t)p->p_p->ps_sigcode +
Why uint64_t here? This is a 32-bit plat
> This is the first demonstration of a mitigation against SROP.
>
> This is SROP: http://www.cs.vu.nl/~herbertb/papers/srop_sp14.pdf
Here is a better diff, which reduces change of the amd64 ABI.
Index: arch/alpha/alpha/locore.s
===
This is the first demonstration of a mitigation against SROP.
This is SROP: http://www.cs.vu.nl/~herbertb/papers/srop_sp14.pdf
A solution for Linux was attempted (https://lwn.net/Articles/674861),
but that proposal appears to have run lightly into the ABI wall, and
seems to not be integrated.
A
Hi Marc,
Marc Espie wrote on Mon, May 09, 2016 at 06:23:16PM +0200:
> On Mon, May 09, 2016 at 06:11:08PM +0200, Ingo Schwarze wrote:
>> So, bzip2(1) is actually an excellent example.
>>
>> These lines are required:
>>
>> @man man/man1/bzcat.1
>> @man man/man1/bzcmp.1
>> @man man/man1/bzdi
On Mon, May 09, 2016 at 06:11:08PM +0200, Ingo Schwarze wrote:
> So, bzip2(1) is actually an excellent example.
>
> These lines are required:
>
> @man man/man1/bzcat.1
> @man man/man1/bzcmp.1
> @man man/man1/bzdiff.1
> @man man/man1/bzegrep.1
> @man man/man1/bzfgrep.1
> @man man/man1/
Hi Marc,
Marc Espie wrote on Mon, May 09, 2016 at 04:06:06PM +0200:
> Source has been wiped out of extraneous links... looks like some ports
> could be too (just took a random sample: bzip2)
>
> No idea whether we need some automated tool, or just @commenting out
> the extra entry in PLIST would
Source has been wiped out of extraneous links... looks like some ports could
be too (just took a random sample: bzip2)
No idea whether we need some automated tool, or just @commenting out the
extra entry in PLIST would be enough.
If anything, we can probably write something that looks at packages
On Fri, May 06, 2016 at 02:27:46PM +0200, Martin Pieuchot wrote:
> Now that ip_forward() is reusing the route fetched by in_ouraddr() we
> want to make sure we're fetching a possible RTF_MPATH route and not
> simply picking the first one every time.
>
> This restore the behavior of r1.274 when usi
On Sun, May 08, 2016 at 07:27:13PM +, Fabien Siron wrote:
> Hi everyone,
>
> The following patch moves all the validations of the start command in
> start_vm() as suggested in the comment.
>
> Index: vmctl.c
> ===
> RCS file: /cv
24 matches
Mail list logo
