gmx.com> writes:
> ...
> It appears that it's not possible to make a proper API with
> malloc_usable_size() included, at least when
> multi-threading is involved (ie., in the modern world).
>
> However, it is still useful to create an API that supports the following
cases:
> ...
Well, this i
On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote:
> On Wed, Nov 27, 2013 at 01:11:35PM -0800, Don Lewis wrote:
> > On 27 Nov, Konstantin Belousov wrote:
> > > On Wed, Nov 27, 2013 at 11:35:19AM -0800, Don Lewis wrote:
> > >> On 27 Nov, Konstantin Belousov wrote:
> > >> > On Wed,
On Sat, Nov 30, 2013 at 01:02:16PM +0100, Peter Holm wrote:
> On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote:
> > Peter, could you, please, try to reproduce the issue ? It does not look
> > like a random hardware failure, since in all cases, it is curthread access
> > which is
I propose to unconditionally add the switch -fno-strict-overflow to the
kernel compilation. See the patch at the end of message for exact change
proposed.
What does it do. It disallows useless and counter-intuitive behaviour of
the compiler(s) for the signed overflow. Basically, the issue is tha
On Fri, Nov 29, 2013 at 08:37:28PM -0800, Tim Kientzle wrote:
>
> On Nov 29, 2013, at 3:44 PM, jb wrote:
>
> > Luigi Rizzo iet.unipi.it> writes:
> >
> >> ...
> >> There is a difference between applications peeking into
> >> implementation details that should be hidden, and providing
> >> inst
On 30 Nov, Konstantin Belousov wrote:
> On Sat, Nov 30, 2013 at 01:02:16PM +0100, Peter Holm wrote:
>> On Thu, Nov 28, 2013 at 09:56:10AM +0200, Konstantin Belousov wrote:
>> > Peter, could you, please, try to reproduce the issue ? It does not look
>> > like a random hardware failure, since in all
+1, this caught us out with sendfile testing very recently :(
-a
On 30 November 2013 05:56, Konstantin Belousov wrote:
> I propose to unconditionally add the switch -fno-strict-overflow to the
> kernel compilation. See the patch at the end of message for exact change
> proposed.
>
> What does
Venkata Duvvuru wrote this message on Mon, Nov 25, 2013 at 14:58 +:
> The problem with using int or u_int for 1 or 2 byte values is that while
> printing these 1 or 2 byte values I observed that sysctl module is
> considering 4 bytes. Hence I see an undesired output. It is actually
> conside
gmx.com> writes:
> ...
> So new flags could be [1]:
> - realloc_flags(p, s, REALLOCF_NO_MOVE): Resize object p, without moving
> it, to size s. With this restriction, when requesting more memory, and
> the specified amount isn't available, don't do anything (when requesting
> less memory, alwa
In message
, Adrian Chadd writes:
>> The compiler authors take the undefined part there as a blanket to perform
>> optimizations which are assuming that signed overflow cannot happen.
That's sufficient explanation for me to support your proposal.
--
Poul-Henning Kamp | UNIX since Zilog Z
On 11/11/13 14:57, Teske, Devin wrote:
> On Nov 11, 2013, at 12:54 PM, Nathan Whitehorn wrote:
>
>> On 11/11/13 14:30, Nathan Whitehorn wrote:
>>> On 11/11/13 14:18, Teske, Devin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Nov 11, 2013, at 11:46 AM, Michael De
On 30 Nov 2013, at 14:56, Konstantin Belousov wrote:
> I propose to unconditionally add the switch -fno-strict-overflow to the
> kernel compilation. See the patch at the end of message for exact change
> proposed.
>
> What does it do. It disallows useless and counter-intuitive behaviour of
> th
On 30 November 2013 15:25, Dimitry Andric wrote:
> On 30 Nov 2013, at 14:56, Konstantin Belousov wrote:
>> I propose to unconditionally add the switch -fno-strict-overflow to the
>> kernel compilation. See the patch at the end of message for exact change
>> proposed.
>>
>> What does it do. It d
Luigi Rizzo wrote this message on Fri, Nov 29, 2013 at 17:11 -0800:
> On Fri, Nov 29, 2013 at 4:49 PM, Adrian Chadd wrote:
>
> > The reason I wouldn't implement this is to avoid having code that
> > _relies_ on this behaviour in order to function or perform well.
>
>
> nobody ever said (or coul
Adrian Chadd wrote, On 12/01/2013 01:33:
Are you able to have clang/llvm/gcc tell us where/when code is relying
on undefined behaviour? So we can, like, fix them?
Well, there's -ftrapv.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd
John-Mark Gurney wrote, On 12/01/2013 03:20:
Either it happens rarely, and always doing a realloc won't hurt
performance, or it happens often, and then you should be using a larger
buffer in the first place..
What if a size-elastic implementation of a dynamic data structure would be able
to ad
Just came across this error...
zfs -mm master errors with
Assertion failed: (tq->tq_freelist != NULL), file
/master/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c,
line 289.
Abort (core dumped)
___
freebsd-curren
On Sat, Nov 30, 2013 at 10:51:56PM -0500, Outback Dingo wrote:
> Just came across this error...
>
> zfs -mm master errors with
>
> Assertion failed: (tq->tq_freelist != NULL), file
> /master/src/cddl/lib/libzpool/../../../cddl/contrib/opensolaris/lib/libzpool/common/taskq.c,
> line 289.
> Abo
you have to upgrade your pool to enable histogram i believe
zdb -mm master
Metaslabs:
vdev 0
metaslabs 103 offsetspacemap free
--- --- ---
-
metaslab 0 offset
On Sat, Nov 30, 2013 at 11:09:26PM -0500, Outback Dingo wrote:
> you have to upgrade your pool to enable histogram i believe
>
> zdb -mm master
>
So, is the problem with zfs(8), or zdb(8) ?
>
> On Sat, Nov 30, 2013 at 11:04 PM, Glen Barber wrote:
>
> > On Sat, Nov 30, 2013 at 10:51:56PM -050
On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote:
[..]
> Are you able to have clang/llvm/gcc tell us where/when code is relying
> on undefined behaviour? So we can, like, fix them?
It wasn't all that long ago that we had this wonderful thing called
-Werror and had a clean kernel build.
The pr
On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm wrote:
> On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote:
> [..]
>> Are you able to have clang/llvm/gcc tell us where/when code is relying
>> on undefined behaviour? So we can, like, fix them?
>
> It wasn't all that long ago that we had this wonder
On Sat, Nov 30, 2013 at 8:38 PM, Eitan Adler wrote:
> On Sat, Nov 30, 2013 at 11:26 PM, Peter Wemm wrote:
>> On Sat, Nov 30, 2013 at 4:33 PM, Adrian Chadd wrote:
>> [..]
>>> Are you able to have clang/llvm/gcc tell us where/when code is relying
>>> on undefined behaviour? So we can, like, fix th
On Sat, Nov 30, 2013 at 04:33:17PM -0800, Adrian Chadd wrote:
> On 30 November 2013 15:25, Dimitry Andric wrote:
> > On 30 Nov 2013, at 14:56, Konstantin Belousov wrote:
> >> I propose to unconditionally add the switch -fno-strict-overflow to the
> >> kernel compilation. See the patch at the en
24 matches
Mail list logo
