On Wed, 24 Jan 2018, Conrad Meyer wrote:
On Wed, Jan 24, 2018 at 10:05 AM, Warner Losh wrote:
...
Let's start with his point about u_long vs size_t causing problems:
void*malloc(unsigned long size, struct malloc_type *type, int flags)
vs
void*mallocarray(size_t nmemb, size_t size, str
On Wed, Jan 24, 2018 at 2:40 PM, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 1:13 PM, Warner Losh wrote:
> > mallocarray should be the last line of defense, not the only line of
> > defense.
>
> Agreed.
>
> > most of the time, it's more correct to say
> >
> > if (WOULD_OVERFLOW(a,b))
> > r
On Wed, Jan 24, 2018 at 1:13 PM, Warner Losh wrote:
> mallocarray should be the last line of defense, not the only line of
> defense.
Agreed.
> most of the time, it's more correct to say
>
> if (WOULD_OVERFLOW(a,b))
> return EINVAL;
> ptr = mallocarray(a,b...);
Disagree -- the right check t
On Wed, Jan 24, 2018 at 12:40 PM, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 11:27 AM, Warner Losh wrote:
> >
> > Which is why we should add check overflows for most of the no wait cases.
> > They should be checked, but not primarily with mallocarray...
>
> I don't understand what the distinc
On Wed, Jan 24, 2018 at 11:27 AM, Warner Losh wrote:
>
> Which is why we should add check overflows for most of the no wait cases.
> They should be checked, but not primarily with mallocarray...
I don't understand what the distinction is here. Can you help me
understand why the overflow check sh
On Jan 24, 2018 12:24 PM, "Conrad Meyer" wrote:
On Wed, Jan 24, 2018 at 10:51 AM, Pedro Giffuni wrote:
> FWIW, I suggested a panic for M_WAITOK and returning NULL for M_NOWAIT,
but
> cem didn't like it because it was inconsistent.
>
> I think the current argument is more about the size/trigger t
On Wed, Jan 24, 2018 at 10:44 AM, Pedro Giffuni wrote:
> ...
> On 24/01/2018 13:30, Conrad Meyer wrote:
>>
>> ...
>> size_t can handle 10GB, but u_long can't.
>> This whole argument hinges upon incorrect assumption that size_t is
>> larger than u_long.
>
>
> Hmm...
>
> Lets just make it "unsigned
On Wed, Jan 24, 2018 at 10:51 AM, Pedro Giffuni wrote:
> FWIW, I suggested a panic for M_WAITOK and returning NULL for M_NOWAIT, but
> cem didn't like it because it was inconsistent.
>
> I think the current argument is more about the size/trigger than the
> behavior though.
Yeah. If an overflow
On 24/01/2018 13:40, Hans Petter Selasky wrote:
On 01/24/18 19:28, Warner Losh wrote:
Does mallocarray(10 ,1Gb) panic on i386? It does not. It should.
Hi,
If M_WAITOK is specified, then sleep forever and print a message.
Else return NULL ?
FWIW, I suggested a panic for M_WAITOK and return
...
On 24/01/2018 13:30, Conrad Meyer wrote:
...
size_t can handle 10GB, but u_long can't.
This whole argument hinges upon incorrect assumption that size_t is
larger than u_long.
Hmm...
Lets just make it "unsigned long" to be consistent with malloc(9) and
avoid confusion?
Pedro.
___
On Wed, Jan 24, 2018 at 10:40 AM, Hans Petter Selasky wrote:
> On 01/24/18 19:28, Warner Losh wrote:
>>
>> Does mallocarray(10 ,1Gb) panic on i386? It does not. It should.
>
>
> Hi,
>
> If M_WAITOK is specified, then sleep forever and print a message.
> Else return NULL ?
Depends on the machine.
On Jan 24, 2018 11:33 AM, "Conrad Meyer" wrote:
Bruce didn't get this wrong, you've just misread his (style / opinion)
complaint as an actual bug (which is kind of the whole reason why it's
hard to treat his complaints seriously):
> size_t happens to have the same representation as u_long on all
On 01/24/18 19:28, Warner Losh wrote:
Does mallocarray(10 ,1Gb) panic on i386? It does not. It should.
Hi,
If M_WAITOK is specified, then sleep forever and print a message.
Else return NULL ?
--HPS
___
svn-src-all@freebsd.org mailing list
https://li
Bruce didn't get this wrong, you've just misread his (style / opinion)
complaint as an actual bug (which is kind of the whole reason why it's
hard to treat his complaints seriously):
> size_t happens to have the same representation as u_long on all supported
> arches
So yes, the check works on i
On Wed, Jan 24, 2018 at 10:05 AM, Warner Losh wrote:
> It changes the fundamental 'can't fail' allocations into 'maybe panic'
> allocations, which was my big objection.
No, it doesn't make any such change. The only calls that will panic
now would have "succeeded" before but returned a smaller si
On Wed, Jan 24, 2018 at 11:05:24AM -0700, Warner Losh wrote:
> Let's start with his point about u_long vs size_t causing problems:
>
> void*malloc(unsigned long size, struct malloc_type *type, int flags)
> vs
> void*mallocarray(size_t nmemb, size_t size, struct malloc_type *type,
>
> Sinc
Does mallocarray(10 ,1Gb) panic on i386? It does not. It should.
Warner
On Jan 24, 2018 11:20 AM, "Conrad Meyer" wrote:
> Please point out what in Bruce's rant is actually relevant. Again, I
> usually start reading them and get sidetracked in things that are
> opinions stated as fact, or outri
Please point out what in Bruce's rant is actually relevant. Again, I
usually start reading them and get sidetracked in things that are
opinions stated as fact, or outright incorrect. At which point, I
give up on them.
___
svn-src-all@freebsd.org mailing
On 01/24/18 12:37, Conrad Meyer wrote:
On Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni wrote:
On 23/01/2018 14:08, Conrad Meyer wrote:
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
I'm confused about this change.
On Wed, Jan 24, 2018 at 10:34 AM, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote:
> > I agree completely. It doesn't do what you think it is doing, for all the
> > reasons that Bruce outlines. We thought it was a bad idea when it came
> up 2
> > years ago and nothing ha
On Wed, 2018-01-24 at 09:34 -0800, Conrad Meyer wrote:
> On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote:
> >
> > I agree completely. It doesn't do what you think it is doing, for all the
> > reasons that Bruce outlines. We thought it was a bad idea when it came up 2
> > years ago and nothing
On 01/24/18 03:50, Bruce Evans wrote:
On Tue, 23 Jan 2018, Pedro Giffuni wrote:
On 23/01/2018 14:08, Conrad Meyer wrote:
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni
wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL: https://svnweb.freebsd.org/chan
On Tue, Jan 23, 2018 at 11:40 AM, Pedro Giffuni wrote:
> On 23/01/2018 14:08, Conrad Meyer wrote:
>> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
>>>
>>> Author: pfg
>>> Date: Sun Jan 21 15:42:36 2018
>>> New Revision: 328218
>>
>> I'm confused about this change. Wouldn't it be bette
On Wed, Jan 24, 2018 at 7:44 AM, Warner Losh wrote:
> I agree completely. It doesn't do what you think it is doing, for all the
> reasons that Bruce outlines. We thought it was a bad idea when it came up 2
> years ago and nothing has really changed.
I disagree. I'm not sure what you mean by "it
On Wed, Jan 24, 2018 at 1:50 AM, Bruce Evans wrote:
> On Tue, 23 Jan 2018, Pedro Giffuni wrote:
>
> On 23/01/2018 14:08, Conrad Meyer wrote:
>>
>>> Hi Pedro,
>>>
>>> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni
>>> wrote:
>>>
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Rev
On Tue, 23 Jan 2018, Pedro Giffuni wrote:
On 23/01/2018 14:08, Conrad Meyer wrote:
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL: https://svnweb.freebsd.org/changeset/base/328218
Log:
Revert r327828,
Hi;
On 23/01/2018 17:13, Bryan Drewery wrote:
On 1/23/2018 11:40 AM, Pedro Giffuni wrote:
Hi;
On 23/01/2018 14:08, Conrad Meyer wrote:
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni
wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL: https://svnweb.fre
On 1/23/2018 11:40 AM, Pedro Giffuni wrote:
> Hi;
>
>
> On 23/01/2018 14:08, Conrad Meyer wrote:
>> Hi Pedro,
>>
>> On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni
>> wrote:
>>> Author: pfg
>>> Date: Sun Jan 21 15:42:36 2018
>>> New Revision: 328218
>>> URL: https://svnweb.freebsd.org/changese
Hi;
On 23/01/2018 14:08, Conrad Meyer wrote:
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL: https://svnweb.freebsd.org/changeset/base/328218
Log:
Revert r327828, r327949, r327953, r328016-r328026, r3
Hi Pedro,
On Sun, Jan 21, 2018 at 7:42 AM, Pedro F. Giffuni wrote:
> Author: pfg
> Date: Sun Jan 21 15:42:36 2018
> New Revision: 328218
> URL: https://svnweb.freebsd.org/changeset/base/328218
>
> Log:
> Revert r327828, r327949, r327953, r328016-r328026, r328041:
> Uses of mallocarray(9).
>
>
Author: pfg
Date: Sun Jan 21 15:42:36 2018
New Revision: 328218
URL: https://svnweb.freebsd.org/changeset/base/328218
Log:
Revert r327828, r327949, r327953, r328016-r328026, r328041:
Uses of mallocarray(9).
The use of mallocarray(9) has rocketed the required swap to build FreeBSD.
This
31 matches
Mail list logo