> [...] this opens a trivial DoS attack like
> for (;;) {
> ftruncate(fd);
> posix_fallocate(fd, (off_t)0, huge);
> }
How, exactly, is this any more of a DoS than doing the same thing but
using one or more write() calls instead of the posix_fallocate()
On Sun, Nov 17, 2013 at 3:30 AM, Terry Moore wrote:
>> From: Lourival Vieira Neto [mailto:lourival.n...@gmail.com]
>> > Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
> but
>> > you may find if not careful that the compiled binary is not loadable on
>> > machines with dif
Date:Sun, 17 Nov 2013 03:18:56 + (UTC)
From:chris...@astron.com (Christos Zoulas)
Message-ID:
| In article <1lcgiu4.18zr2h51aac07zm%m...@netbsd.org>,
| Emmanuel Dreyfus wrote:
| >NetBSD-current seems to lack posix_fallocate(2)
| FreeBSD has it as a syst
> From: Lourival Vieira Neto [mailto:lourival.n...@gmail.com]
> > Watch out, by the way, for compiled scripts; I have not checked Lua 5.x,
but
> > you may find if not careful that the compiled binary is not loadable on
> > machines with different choices for LP64, ILP32, etc. This is somewhat
> > i
I believe that if you want the Lua scripts to be portable across NetBSD
deployments, you should choose a well-known fixed width.
Watch out, by the way, for compiled scripts; I have not checked Lua 5.x, but
you may find if not careful that the compiled binary is not loadable on
machines with differ
On Sun, Nov 17, 2013 at 1:49 AM, Terry Moore wrote:
> I believe that if you want the Lua scripts to be portable across NetBSD
> deployments, you should choose a well-known fixed width.
Indeed.
> Watch out, by the way, for compiled scripts; I have not checked Lua 5.x, but
> you may find if not ca
On Sat, Nov 16, 2013 at 10:44 PM, Christos Zoulas wrote:
> On Nov 16, 9:30pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
> -- Subject: Re: [patch] changing lua_Number to int64_t
>
> | On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas
> wrote:
> | > In article <52872b0c.5080...@msys.ch
On Sat, Nov 16, 2013 at 9:47 PM, Alexander Nasonov wrote:
> Lourival Vieira Neto wrote:
>> On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas wrote:
>> > In article <52872b0c.5080...@msys.ch>, Marc Balmer wrote:
>> >>Changing the number type to int64_t is certainly a good idea. Two
>> >>question
In article <1lcgiu4.18zr2h51aac07zm%m...@netbsd.org>,
Emmanuel Dreyfus wrote:
>Hi
>
>NetBSD-current seems to lack posix_fallocate(2)
>http://pubs.opengroup.org/onlinepubs/009695299/functions/posix_fallocate
>.html
>
>Is someone already working on it, or has thoughs about how it should be
>implemen
>> It seems to me it would be more useful to do something like what
>> RLIMIT_CPU does, and generate SIGXFSZ for such operations, but fail
>> them only when the size exceeds the hard limit. [...]
>> Comments or other thoughts?
> I don't think it is used too much so the behavior change should not
Hi
NetBSD-current seems to lack posix_fallocate(2)
http://pubs.opengroup.org/onlinepubs/009695299/functions/posix_fallocate
.html
Is someone already working on it, or has thoughs about how it should be
implemented?
--
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
m...@netbsd.org
On Nov 16, 9:30pm, lourival.n...@gmail.com (Lourival Vieira Neto) wrote:
-- Subject: Re: [patch] changing lua_Number to int64_t
| On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas wrote:
| > In article <52872b0c.5080...@msys.ch>, Marc Balmer wrote:
| >>Changing the number type to int64_t is cer
Lourival Vieira Neto wrote:
> On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas wrote:
> > In article <52872b0c.5080...@msys.ch>, Marc Balmer wrote:
> >>Changing the number type to int64_t is certainly a good idea. Two
> >>questions, however:
> >
> > Why not intmax_t?
>
> My only argument is th
On Sat, Nov 16, 2013 at 8:52 PM, Christos Zoulas wrote:
> In article <52872b0c.5080...@msys.ch>, Marc Balmer wrote:
>>Changing the number type to int64_t is certainly a good idea. Two
>>questions, however:
>
> Why not intmax_t?
My only argument is that int64_t has a well-defined width and, AFA
On Sat, Nov 16, 2013 at 6:21 AM, Marc Balmer wrote:
> Changing the number type to int64_t is certainly a good idea. Two
> questions, however:
>
> 1) Why do you remove the sys/modules/lua/inttypes.g file?
Because this place holder is no long necessary. I have just replaced
that for sys/inttypes.h
In article <201311160540.aaa23...@chip.rodents-montreal.org>,
Mouse wrote:
>The documentation I have (which is consistent across 1.4T, 4.0.1, and
>5.2) says that "[a] file I/O operation that would create a file larger
>that the process' soft limit will cause the write to fail and a signal
>SIGXFS
In article <52872b0c.5080...@msys.ch>, Marc Balmer wrote:
>Changing the number type to int64_t is certainly a good idea. Two
>questions, however:
Why not intmax_t?
christos
Changing the number type to int64_t is certainly a good idea. Two
questions, however:
1) Why do you remove the sys/modules/lua/inttypes.g file?
2) In sys/modules/lua/luaconf.h, lua_str2number is still #defined as
stroll(), which assumes long long. Shouldn't that be changed as well to
a function
18 matches
Mail list logo
