malloc_conf J j

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

malloc_conf J j

Jan Stary
Does 'J' simply make the junk level two and
does 'j' simply make the junk level zero?

The current "increase/decrease" wording in malloc(3)
can suggest it has a memory. For example, setting

        vm.malloc_conf=J

"increases" junk level to two;
does setting

        vm.malloc_conf=C

later retain a junk level of two,
as there is no 'j' to "decrease" it,
or is the junk level the defult of one now?

        Jan

Reply | Threaded
Open this post in threaded view
|

Re: malloc_conf J j

Otto Moerbeek
On Sun, May 19, 2019 at 08:50:20AM +0200, Jan Stary wrote:

> Does 'J' simply make the junk level two and
> does 'j' simply make the junk level zero?
>
> The current "increase/decrease" wording in malloc(3)
> can suggest it has a memory. For example, setting
>
> vm.malloc_conf=J
>
> "increases" junk level to two;
> does setting
>
> vm.malloc_conf=C
>
> later retain a junk level of two,
> as there is no 'j' to "decrease" it,
> or is the junk level the defult of one now?
>
> Jan
>

C is a combined flag, containing J amongst others.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: malloc_conf J j

Ingo Schwarze
Hi,

Otto Moerbeek wrote on Sun, May 19, 2019 at 02:55:09PM +0200:
> On Sun, May 19, 2019 at 08:50:20AM +0200, Jan Stary wrote:

>> Does 'J' simply make the junk level two and
>> does 'j' simply make the junk level zero?

No, it does not.

For example, if sysctl vm.malloc_conf contains j and MALLOC_OPTIONS
contains J, or if any one source contains "jJ" or "jjJ", you end
up with level 1: During the first malloc call in the program, the
j first lowers the level from 1 to 0, then the J raises the level
back to 1, but not to 2.

>> The current "increase/decrease" wording in malloc(3)
>> can suggest it has a memory. For example, setting
>>
>> vm.malloc_conf=J
>>
>> "increases" junk level to two;
>> does setting
>>
>> vm.malloc_conf=C
>>
>> later retain a junk level of two,
>> as there is no 'j' to "decrease" it,
>> or is the junk level the defult of one now?

Your question makes no sense whatsoever.

First, the word "later" makes no sense.  Malloc initialization is
only done once during a run of any given program.  So if the sysctl
contains J during startup, that is what governs program behaviour.
Changing the sysctl later no longer has any effect on the running
program.

Besides, while J and j manipulate mopts.def_malloc_junk, C sets
mopts.chunk_canaries.  One doesn't have anything to do with the
other.

> C is a combined flag, containing J amongst others.

Neither the code nor the manual page appears to agree with that
statement.  Are you maybe thinking of S?

To provide another example, MALLOC_OPTIONS=jS results in junk level
1 because j lowers it from 1 to 0, then S raises it from 0 to 1.
MALLOC_OPTIONS=jSS results in junk level 2, whereas MALLOC_OPTIONS=SSj
results in junk level 1.


The manual page already seems quite clear.  Well, maybe we could
add one sentence for even more clarity.  Right now, some might think
that earlier flags win.

OK?
  Ingo


Index: malloc.3
===================================================================
RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
retrieving revision 1.124
diff -u -r1.124 malloc.3
--- malloc.3 13 May 2019 06:04:55 -0000 1.124
+++ malloc.3 19 May 2019 14:39:30 -0000
@@ -270,6 +270,8 @@
 in the program.
 Each is scanned for the flags documented below.
 Unless otherwise noted uppercase means on, lowercase means off.
+During initialization, flags occurring later modify the behaviour
+that was requested by flags processed earlier.
 .Bl -tag -width indent
 .It Cm C
 .Dq Canaries .

Reply | Threaded
Open this post in threaded view
|

Re: malloc_conf J j

Otto Moerbeek
On Sun, May 19, 2019 at 04:46:44PM +0200, Ingo Schwarze wrote:

> Hi,
>
> Otto Moerbeek wrote on Sun, May 19, 2019 at 02:55:09PM +0200:
> > On Sun, May 19, 2019 at 08:50:20AM +0200, Jan Stary wrote:
>
> >> Does 'J' simply make the junk level two and
> >> does 'j' simply make the junk level zero?
>
> No, it does not.
>
> For example, if sysctl vm.malloc_conf contains j and MALLOC_OPTIONS
> contains J, or if any one source contains "jJ" or "jjJ", you end
> up with level 1: During the first malloc call in the program, the
> j first lowers the level from 1 to 0, then the J raises the level
> back to 1, but not to 2.
>
> >> The current "increase/decrease" wording in malloc(3)
> >> can suggest it has a memory. For example, setting
> >>
> >> vm.malloc_conf=J
> >>
> >> "increases" junk level to two;
> >> does setting
> >>
> >> vm.malloc_conf=C
> >>
> >> later retain a junk level of two,
> >> as there is no 'j' to "decrease" it,
> >> or is the junk level the defult of one now?
>
> Your question makes no sense whatsoever.
>
> First, the word "later" makes no sense.  Malloc initialization is
> only done once during a run of any given program.  So if the sysctl
> contains J during startup, that is what governs program behaviour.
> Changing the sysctl later no longer has any effect on the running
> program.
>
> Besides, while J and j manipulate mopts.def_malloc_junk, C sets
> mopts.chunk_canaries.  One doesn't have anything to do with the
> other.
>
> > C is a combined flag, containing J amongst others.
>
> Neither the code nor the manual page appears to agree with that
> statement.  Are you maybe thinking of S?

yes, I was thinking of S indeed.

>
> To provide another example, MALLOC_OPTIONS=jS results in junk level
> 1 because j lowers it from 1 to 0, then S raises it from 0 to 1.
> MALLOC_OPTIONS=jSS results in junk level 2, whereas MALLOC_OPTIONS=SSj
> results in junk level 1.
>
>
> The manual page already seems quite clear.  Well, maybe we could
> add one sentence for even more clarity.  Right now, some might think
> that earlier flags win.
>
> OK?
>   Ingo

yes,

        -Otto

>
>
> Index: malloc.3
> ===================================================================
> RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
> retrieving revision 1.124
> diff -u -r1.124 malloc.3
> --- malloc.3 13 May 2019 06:04:55 -0000 1.124
> +++ malloc.3 19 May 2019 14:39:30 -0000
> @@ -270,6 +270,8 @@
>  in the program.
>  Each is scanned for the flags documented below.
>  Unless otherwise noted uppercase means on, lowercase means off.
> +During initialization, flags occurring later modify the behaviour
> +that was requested by flags processed earlier.
>  .Bl -tag -width indent
>  .It Cm C
>  .Dq Canaries .

Reply | Threaded
Open this post in threaded view
|

Re: malloc_conf J j

Jan Stary
In reply to this post by Ingo Schwarze
On May 19 16:46:44, [hidden email] wrote:

> >> The current "increase/decrease" wording in malloc(3)
> >> can suggest it has a memory. For example, setting
> >>
> >> vm.malloc_conf=J
> >>
> >> "increases" junk level to two;
> >> does setting
> >>
> >> vm.malloc_conf=C
> >>
> >> later retain a junk level of two,
> >> as there is no 'j' to "decrease" it,
> >> or is the junk level the defult of one now?
>
> Your question makes no sense whatsoever.
>
> First, the word "later" makes no sense.

I should have worded more clearly. I meant programs that start later,
after vm.malloc_conf is set to something else.

It makes perfect sense now, thanks.

        Jan

> Malloc initialization is
> only done once during a run of any given program.


> contains J during startup, that is what governs program behaviour.
> Changing the sysctl later no longer has any effect on the running
> program.

> Index: malloc.3
> ===================================================================
> RCS file: /cvs/src/lib/libc/stdlib/malloc.3,v
> retrieving revision 1.124
> diff -u -r1.124 malloc.3
> --- malloc.3 13 May 2019 06:04:55 -0000 1.124
> +++ malloc.3 19 May 2019 14:39:30 -0000
> @@ -270,6 +270,8 @@
>  in the program.
>  Each is scanned for the flags documented below.
>  Unless otherwise noted uppercase means on, lowercase means off.
> +During initialization, flags occurring later modify the behaviour
> +that was requested by flags processed earlier.
>  .Bl -tag -width indent
>  .It Cm C
>  .Dq Canaries .
>

Reply | Threaded
Open this post in threaded view
|

Re: malloc_conf J j

Ingo Schwarze
Hi Jan,

Jan Stary wrote on Sun, May 19, 2019 at 05:46:08PM +0200:
> On May 19 16:46:44, [hidden email] wrote:
>> Jan Stary wrote:

>>> The current "increase/decrease" wording in malloc(3)
>>> can suggest it has a memory. For example, setting
>>>
>>> vm.malloc_conf=J
>>>
>>> "increases" junk level to two;
>>> does setting
>>>
>>> vm.malloc_conf=C
>>>
>>> later retain a junk level of two,
>>> as there is no 'j' to "decrease" it,
>>> or is the junk level the defult of one now?

>> Your question makes no sense whatsoever.
>> First, the word "later" makes no sense.

> I should have worded more clearly. I meant programs that start later,

Oh.  It didn't even occur to me that somebody could possibly fall
prey to the misconception that anything related to a library function
that is not a system call could possibly propagate from one process
to another process that isn't even a child of the first one.
I think the fact that we are in section 3 here and not in section 2
already makes it clear enough that whatever is described here starts
from scratch for every new process and cannot depend on whatever
other processes may have done before.

> after vm.malloc_conf is set to something else.

Well, sysctl(2) tells you that vm.malloc_conf is a *string*, so it
is already clear enough that the kernel does *not* store junk levels
as numbers but simply stores a string of letters.  So it should be
clear that first setting one string, then another one overrides the
first string and can in no way be cumulative.

> It makes perfect sense now, thanks.

I agree nothing more seems to be missing from the documentation;
at least, i don't see what might still be missing.

Yours,
  Ingo