daily CVS update output
Updating src tree: P src/external/bsd/jemalloc/dist/include/jemalloc/internal/arena_externs.h P src/external/bsd/jemalloc/dist/include/jemalloc/internal/arena_inlines_a.h P src/external/bsd/jemalloc/dist/include/jemalloc/internal/arena_inlines_b.h P src/external/bsd/jemalloc/dist/include/jemalloc/internal/atomic_gcc_atomic.h P src/external/bsd/jemalloc/dist/include/jemalloc/internal/prof_inlines_a.h P src/external/bsd/jemalloc/dist/include/jemalloc/internal/prof_inlines_b.h P src/external/bsd/jemalloc/dist/src/arena.c P src/external/bsd/jemalloc/dist/src/jemalloc.c P src/external/bsd/jemalloc/dist/src/prof.c P src/external/bsd/jemalloc/include/jemalloc/internal/jemalloc_preamble.h P src/sbin/gpt/header.c P src/sys/arch/cesfic/conf/GENERIC P src/sys/arch/evbarm/conf/mk.generic P src/sys/arch/hp300/conf/GENERIC P src/sys/arch/hp300/conf/INSTALL P src/sys/arch/hp300/hp300/machdep.c P src/sys/arch/m68k/conf/files.m68k P src/sys/arch/m68k/include/m68k.h P src/sys/arch/m68k/m68k/copy.s cvs update: `src/sys/arch/m68k/m68k/mappedcopy.c' is no longer in the repository P src/sys/arch/mvme68k/mvme68k/machdep.c P src/sys/arch/news68k/news68k/machdep.c P src/sys/arch/next68k/next68k/machdep.c P src/sys/arch/vax/uba/qv.c P src/sys/arch/vax/vsa/smg.c P src/sys/arch/x68k/conf/GENERIC P src/sys/arch/x68k/conf/INSTALL P src/sys/arch/x68k/x68k/machdep.c P src/sys/dev/nvmm/nvmm.c P src/sys/dev/nvmm/x86/nvmm_x86_svm.c P src/sys/dev/nvmm/x86/nvmm_x86_vmx.c P src/sys/dev/pci/ixgbe/ixgbe.c P src/sys/dev/pci/ixgbe/ixv.c P src/sys/kern/kern_scdebug.c P src/sys/net/if_ipsec.c P src/sys/netinet/ip_carp.c P src/sys/uvm/uvm_map.c P src/sys/uvm/uvm_mmap.c P src/sys/uvm/uvm_page.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 41064276 Mar 15 03:03 ls-lRA.gz
Re: ATF t_mlock() babylon5 kernel panics
Date:Thu, 14 Mar 2019 18:12:18 - (UTC) From:chris...@astron.com (Christos Zoulas) Message-ID: | Great debugging :-) The hard part was all Jason's work - he picked out just where things would be going wrong - after that it wasn't difficult. | LGTM, at this point I'd merge them: That's reasonable, but it isn't required for this bug fix, nor is correcting the error codes returned, so I think I'll leave those for a bit (or you can just make this change in a few minutes...) kre
Re: strange libc symbol renaming issue
On 14.03.2019 19:30, Manuel Bouyer wrote:
> On Thu, Mar 14, 2019 at 03:14:56PM +0100, Manuel Bouyer wrote:
>> Hello,
>> I've a very strange symbol renaming issue on NetBSD 8.0/amd64:
>> syslog-ng dies with a bad syscall signal, ktrace reveals that it
>> called compat_13_sigaction13, just after properly calling __sigprocmask14.
>
>> gdb on the core dump shows:
>> Core was generated by `syslog-ng'.
>> Program terminated with signal SIGSYS, Bad system call.
>> #0 0x7747ad46e74a in sigaction () from /usr/lib/libc.so.12
>> (gdb) up
>> #1 0x7747b0e38f38 in g_process_perform_supervise () at
>> lib/gprocess.c:1087
>> 1087 sigaction(SIGHUP, , NULL);
>> (gdb)
>>
>> but gprocess.c properly includes signal.h, there was no warning at link time,
>> and disasembling the function confirms it:
>>0x7747b0e38f08 <+143>: movq $0x0,0x58(%rsp)
>>0x7747b0e38f11 <+152>: movq $0x0,0x60(%rsp)
>>0x7747b0e38f1a <+161>: movq $0x0,0x68(%rsp)
>>0x7747b0e38f23 <+170>: movq $0x1,0x50(%rsp)
>>0x7747b0e38f2c <+179>: xor%edx,%edx
>>0x7747b0e38f2e <+181>: mov$0x1,%edi
>>0x7747b0e38f33 <+186>: callq 0x7747b0e2f700 <__sigaction14@plt>
>> => 0x7747b0e38f38 <+191>: mov$0x1,%ebp
>>0x7747b0e38f3d <+196>: lea0x4c(%rsp),%r15
>>0x7747b0e38f42 <+201>: lea0x41378(%rip),%r14#
>> 0x7747b0e7a2c1
>>
> Well, it turns out that sigaction is reimplemented by syslog-ng in
> lib/signal-handler.c. As it includes signal.h, its sigaction implementation
> is renamed to _sigaction14.
>
> This reimplementation of sigaction ends up calling the libc's one, using:
> static int (*real_sa)(int, const struct sigaction *, struct sigaction *);
>
> if (real_sa == NULL)
> {
> real_sa = dlsym(RTLD_NEXT, "sigaction");
> }
> return real_sa(signum, act, oldact);
>
>
> I could change sigaction to _sigaction14 in the dlsym here for NetBSD;
> is there a better way to do it ?
>
The proper way is to call (and detect for NetBSD): __sigaction14.
signature.asc
Description: OpenPGP digital signature
Re: strange libc symbol renaming issue
On Thu, Mar 14, 2019 at 03:14:56PM +0100, Manuel Bouyer wrote:
> Hello,
> I've a very strange symbol renaming issue on NetBSD 8.0/amd64:
> syslog-ng dies with a bad syscall signal, ktrace reveals that it
> called compat_13_sigaction13, just after properly calling __sigprocmask14.
> gdb on the core dump shows:
> Core was generated by `syslog-ng'.
> Program terminated with signal SIGSYS, Bad system call.
> #0 0x7747ad46e74a in sigaction () from /usr/lib/libc.so.12
> (gdb) up
> #1 0x7747b0e38f38 in g_process_perform_supervise () at
> lib/gprocess.c:1087
> 1087 sigaction(SIGHUP, , NULL);
> (gdb)
>
> but gprocess.c properly includes signal.h, there was no warning at link time,
> and disasembling the function confirms it:
>0x7747b0e38f08 <+143>: movq $0x0,0x58(%rsp)
>0x7747b0e38f11 <+152>: movq $0x0,0x60(%rsp)
>0x7747b0e38f1a <+161>: movq $0x0,0x68(%rsp)
>0x7747b0e38f23 <+170>: movq $0x1,0x50(%rsp)
>0x7747b0e38f2c <+179>: xor%edx,%edx
>0x7747b0e38f2e <+181>: mov$0x1,%edi
>0x7747b0e38f33 <+186>: callq 0x7747b0e2f700 <__sigaction14@plt>
> => 0x7747b0e38f38 <+191>: mov$0x1,%ebp
>0x7747b0e38f3d <+196>: lea0x4c(%rsp),%r15
>0x7747b0e38f42 <+201>: lea0x41378(%rip),%r14#
> 0x7747b0e7a2c1
>
Well, it turns out that sigaction is reimplemented by syslog-ng in
lib/signal-handler.c. As it includes signal.h, its sigaction implementation
is renamed to _sigaction14.
This reimplementation of sigaction ends up calling the libc's one, using:
static int (*real_sa)(int, const struct sigaction *, struct sigaction *);
if (real_sa == NULL)
{
real_sa = dlsym(RTLD_NEXT, "sigaction");
}
return real_sa(signum, act, oldact);
I could change sigaction to _sigaction14 in the dlsym here for NetBSD;
is there a better way to do it ?
--
Manuel Bouyer
NetBSD: 26 ans d'experience feront toujours la difference
--
Re: ATF t_mlock() babylon5 kernel panics
> On Mar 14, 2019, at 10:27 AM, Robert Elz wrote:
>
>Date:Thu, 14 Mar 2019 08:06:58 -0700
>From:Jason Thorpe
>Message-ID: <134778ad-a675-414a-bbb3-7eeeaf2c2...@me.com>
>
> | Great sleuthing, you pretty much nailed it.
>
> OK, great.This is the patch I plan to commit soon (rather than
> waiting on lots of review - so that the b5 tests can start working
> again ASAP).
>
> If anyone has any issues with this, please make them known soon
> (as in quite soon...)
Looks good to me. This is probably worth pulling up to netbsd-8 as well.
> Also, after this patch, I tested address wraparround (addr+llen < addr)
> and get the ENOMEM error that the patch returns (which seems to be the
> error that POSIX specifies for this kind of thing. Ans speaking of which
> we appear to differ with POSIX in several error codes, POSIX does not use
> EINVAL for mlock/munlock of a region which crosses a "hole" that would be
> ENOMEM (munlock converts the internal EINVAL into ENOMEM before returning,
> mlock() doesn't), and munlock() without a preceding mlock is not an error
> at all (POSIX says "regardless of how many times mlock( ) has been called by
> the process for any of the pages in the specified range." Zero is a
> number of times that mlock() might have been called. ALso, EAGAIN is
> correct for mlock() when the max number of pages the kernel will allow
> to be locked have been locked, but not for the case when a process exceeds
> its resource limit of locked pages ... that should be ENOMEM. There
> might be more like this. This patch doesn't do anything with those
> issues, they're not urgent, and we can fix them anytime (if we agree to
> do so.)
Yes, we should fix the error return cases as well.
>
> kre
>
> Index: uvm_map.c
> ===
> RCS file: /cvsroot/src/sys/uvm/uvm_map.c,v
> retrieving revision 1.358
> diff -u -r1.358 uvm_map.c
> --- uvm_map.c 3 Mar 2019 17:37:36 - 1.358
> +++ uvm_map.c 14 Mar 2019 16:29:57 -
> @@ -3359,6 +3359,14 @@
> }
> entry = start_entry;
>
> + if (start == end) { /* nothing required */
> + if ((lockflags & UVM_LK_EXIT) == 0)
> + vm_map_unlock(map);
> +
> + UVMHIST_LOG(maphist,"<- done (nothing)",0,0,0,0);
> + return 0;
> + }
> +
> /*
>* handle wiring and unwiring separately.
>*/
> Index: uvm_mmap.c
> ===
> RCS file: /cvsroot/src/sys/uvm/uvm_mmap.c,v
> retrieving revision 1.169
> diff -u -r1.169 uvm_mmap.c
> --- uvm_mmap.c19 Dec 2017 18:34:47 - 1.169
> +++ uvm_mmap.c14 Mar 2019 16:29:58 -
> @@ -759,8 +759,12 @@
>
> pageoff = (addr & PAGE_MASK);
> addr -= pageoff;
> - size += pageoff;
> - size = (vsize_t)round_page(size);
> + if (size != 0) {
> + size += pageoff;
> + size = (vsize_t)round_page(size);
> + }
> + if (addr + size < addr)
> + return ENOMEM;
>
> error = range_test(>p_vmspace->vm_map, addr, size, false);
> if (error)
> @@ -810,8 +814,12 @@
>
> pageoff = (addr & PAGE_MASK);
> addr -= pageoff;
> - size += pageoff;
> - size = (vsize_t)round_page(size);
> + if (size != 0) {
> + size += pageoff;
> + size = (vsize_t)round_page(size);
> + }
> + if (addr + size < addr)
> + return ENOMEM;
>
> error = range_test(>p_vmspace->vm_map, addr, size, false);
> if (error)
> Index: uvm_page.c
> ===
> RCS file: /cvsroot/src/sys/uvm/uvm_page.c,v
> retrieving revision 1.198
> diff -u -r1.198 uvm_page.c
> --- uvm_page.c19 May 2018 15:03:26 - 1.198
> +++ uvm_page.c14 Mar 2019 16:29:58 -
> @@ -1605,9 +1605,11 @@
> uvm_pageunwire(struct vm_page *pg)
> {
> KASSERT(mutex_owned(_pageqlock));
> + KASSERT(pg->wire_count != 0);
> pg->wire_count--;
> if (pg->wire_count == 0) {
> uvm_pageactivate(pg);
> + KASSERT(uvmexp.wired != 0);
> uvmexp.wired--;
> }
> }
>
>
-- thorpej
Re: ATF t_mlock() babylon5 kernel panics
In article <26375.1552584...@jinx.noi.kre.to>,
Robert Elz wrote:
>
Great debugging :-)
LGTM, at this point I'd merge them:
static int
round_and_check(const struct vm_map *map, vaddr_t *addr, vsize_t *size)
{
const vsize_t pageoff = (vsize_t)(*addr & PAGE_MASK);
*addr -= pageoff;
if (*size != 0) {
*size += pageoff;
*size = (vsize_t)round_page(*size);
}
if (*addr + *size < *addr)
return ENOMEM;
// Make range_test() take const map as it should have in the first place
return range_test(map, *addr, *size, false);
}
christos
Re: ATF t_mlock() babylon5 kernel panics
Date:Thu, 14 Mar 2019 08:06:58 -0700
From:Jason Thorpe
Message-ID: <134778ad-a675-414a-bbb3-7eeeaf2c2...@me.com>
| Great sleuthing, you pretty much nailed it.
OK, great.This is the patch I plan to commit soon (rather than
waiting on lots of review - so that the b5 tests can start working
again ASAP).
If anyone has any issues with this, please make them known soon
(as in quite soon...)
Of course, we can always revise, or revert, these changes later.
They do seem to work as intended however.
Before I added this to my test system, I (using the original kernel)
did a test of (several iterations of) munlock(buf, 0) (where buf is
page aligned) without any problems, as expected.
After applying this patch, the t_mlock test works with no failings
(as it exists in -current ... I will fix all its idiocy after it has
been used a few times in its current state - no matter how broken it
should not be able to crash the kernel).
Also, after this patch, I tested address wraparround (addr+llen < addr)
and get the ENOMEM error that the patch returns (which seems to be the
error that POSIX specifies for this kind of thing. Ans speaking of which
we appear to differ with POSIX in several error codes, POSIX does not use
EINVAL for mlock/munlock of a region which crosses a "hole" that would be
ENOMEM (munlock converts the internal EINVAL into ENOMEM before returning,
mlock() doesn't), and munlock() without a preceding mlock is not an error
at all (POSIX says "regardless of how many times mlock( ) has been called by
the process for any of the pages in the specified range." Zero is a
number of times that mlock() might have been called. ALso, EAGAIN is
correct for mlock() when the max number of pages the kernel will allow
to be locked have been locked, but not for the case when a process exceeds
its resource limit of locked pages ... that should be ENOMEM. There
might be more like this. This patch doesn't do anything with those
issues, they're not urgent, and we can fix them anytime (if we agree to
do so.)
kre
Index: uvm_map.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_map.c,v
retrieving revision 1.358
diff -u -r1.358 uvm_map.c
--- uvm_map.c 3 Mar 2019 17:37:36 - 1.358
+++ uvm_map.c 14 Mar 2019 16:29:57 -
@@ -3359,6 +3359,14 @@
}
entry = start_entry;
+ if (start == end) { /* nothing required */
+ if ((lockflags & UVM_LK_EXIT) == 0)
+ vm_map_unlock(map);
+
+ UVMHIST_LOG(maphist,"<- done (nothing)",0,0,0,0);
+ return 0;
+ }
+
/*
* handle wiring and unwiring separately.
*/
Index: uvm_mmap.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_mmap.c,v
retrieving revision 1.169
diff -u -r1.169 uvm_mmap.c
--- uvm_mmap.c 19 Dec 2017 18:34:47 - 1.169
+++ uvm_mmap.c 14 Mar 2019 16:29:58 -
@@ -759,8 +759,12 @@
pageoff = (addr & PAGE_MASK);
addr -= pageoff;
- size += pageoff;
- size = (vsize_t)round_page(size);
+ if (size != 0) {
+ size += pageoff;
+ size = (vsize_t)round_page(size);
+ }
+ if (addr + size < addr)
+ return ENOMEM;
error = range_test(>p_vmspace->vm_map, addr, size, false);
if (error)
@@ -810,8 +814,12 @@
pageoff = (addr & PAGE_MASK);
addr -= pageoff;
- size += pageoff;
- size = (vsize_t)round_page(size);
+ if (size != 0) {
+ size += pageoff;
+ size = (vsize_t)round_page(size);
+ }
+ if (addr + size < addr)
+ return ENOMEM;
error = range_test(>p_vmspace->vm_map, addr, size, false);
if (error)
Index: uvm_page.c
===
RCS file: /cvsroot/src/sys/uvm/uvm_page.c,v
retrieving revision 1.198
diff -u -r1.198 uvm_page.c
--- uvm_page.c 19 May 2018 15:03:26 - 1.198
+++ uvm_page.c 14 Mar 2019 16:29:58 -
@@ -1605,9 +1605,11 @@
uvm_pageunwire(struct vm_page *pg)
{
KASSERT(mutex_owned(_pageqlock));
+ KASSERT(pg->wire_count != 0);
pg->wire_count--;
if (pg->wire_count == 0) {
uvm_pageactivate(pg);
+ KASSERT(uvmexp.wired != 0);
uvmexp.wired--;
}
}
Re: ATF t_mlock() babylon5 kernel panics
On Mar 14, 2019, at 5:44 AM, Robert Elz wrote: > > am guessing at the UVMHIST_LOG() stuff (copy/paste/edit...) > > Does all of this sound plausible, and reasonable to do ? > Please do remember, that before this, I have never been > anywhere near uvm or anything pmap related, so have mercy! Great sleuthing, you pretty much nailed it. -- thorpej
strange libc symbol renaming issue
Hello, I've a very strange symbol renaming issue on NetBSD 8.0/amd64: syslog-ng dies with a bad syscall signal, ktrace reveals that it called compat_13_sigaction13, just after properly calling __sigprocmask14. gdb on the core dump shows: Core was generated by `syslog-ng'. Program terminated with signal SIGSYS, Bad system call. #0 0x7747ad46e74a in sigaction () from /usr/lib/libc.so.12 (gdb) up #1 0x7747b0e38f38 in g_process_perform_supervise () at lib/gprocess.c:1087 1087 sigaction(SIGHUP, , NULL); (gdb) but gprocess.c properly includes signal.h, there was no warning at link time, and disasembling the function confirms it: 0x7747b0e38f08 <+143>: movq $0x0,0x58(%rsp) 0x7747b0e38f11 <+152>: movq $0x0,0x60(%rsp) 0x7747b0e38f1a <+161>: movq $0x0,0x68(%rsp) 0x7747b0e38f23 <+170>: movq $0x1,0x50(%rsp) 0x7747b0e38f2c <+179>: xor%edx,%edx 0x7747b0e38f2e <+181>: mov$0x1,%edi 0x7747b0e38f33 <+186>: callq 0x7747b0e2f700 <__sigaction14@plt> => 0x7747b0e38f38 <+191>: mov$0x1,%ebp 0x7747b0e38f3d <+196>: lea0x4c(%rsp),%r15 0x7747b0e38f42 <+201>: lea0x41378(%rip),%r14# 0x7747b0e7a2c1 >From here gdb seems lost; I'm working on a core dump as this all happens after a fork so I can't work on it live: (gdb) disas 0x7747b0e2f700 Dump of assembler code for function __sigaction14@plt: 0x7747b0e2f700 <+0>: jmpq *0x2834a2(%rip)# 0x7747b10b2ba8 0x7747b0e2f706 <+6>: pushq $0x4e5 0x7747b0e2f70b <+11>:jmpq 0x7747b0e2a8a0 0x7747b10b2ba8 is in _GLOBAL_OFFSET_TABLE_ (gdb) x/lx 0x7747b10b2ba8 0x7747b10b2ba8: 0xb0e46527 (gdb) disas 0xb0e46527 No function contains specified address. (gdb) x/i 0xb0e46527 0xb0e46527: Cannot access memory at address 0xb0e46527 Any idea what could cause a program actually calling explicitely __sigaction14 to end up in the compat sigaction ? -- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Re: ATF t_mlock() babylon5 kernel panics
Date:Wed, 13 Mar 2019 11:44:51 -0700
From:Jason Thorpe
Message-ID: <9a2a4a34-35b0-490e-9a92-aab44174f...@me.com>
| I would suggest instrumenting-with-printf the "new_pageable"
| case of uvm_map_pageable()
That didn't show much we didn't already know.
Turns out the problem is in the other side, the mlock() case,
that's where things go bad, then the munlock() falls foul of
the corrupted setup. I haven't tested it yet, but I will,
but I am fairly sure that simply doing munlock(addr, 0) when
there has been no mlock() will cause no problems at all.
I am less sure about the case
mlock(addr, 100); munlock(addr+50, 0);
but I will investigate that one too.
What happens in the mlock(addr, 0) case is this:
uvm_map_pageable() starts by validating the start and end addresses
(ed6000 for both, since size == 0 ... that is the real address from
the test, but with all the upper bits dropped for the e-mail, they're
irrelevant).
uvm_map_lookup_entry() finds the entry for the start address, which
in this case is ecd000..eff000 (start..end) with wired_count == 0.
Since this is the !new_pageable case we drop to pass 1 of the "do wiring"
code. There entry != >header (the end ... that's impossible in
the first iteration I think) and entry->start (ecd000) < end (ed6000)
so we enter the loop.
The map isn't wired (wired_count == 0) so we do the test to see
if an amap_copy() is needed. It isn't, fortunately, or I'd have
to go learn that that's all about...
Then we get to the first interesting bit;
In general, if we have a map entry covering addresses a..b and
we want to lock a range x..y where a (ENTRY)->start && (VA) < (ENTRY)->end) { \
uvm_map_clip_end(MAP,ENTRY,VA); \
} \
(that's a macro definition, hence the \'s). Here ENTRY->start == x,
ENTRY->end == b, and VA == y. But x == y, so VA == x too.
Then since VA == ENTRY->start the condition fails, and no splitting
(clipping) is done.
So, now we have two entries [ecd000..ed6000] and [ed6000..eff000]
with "entry" (the one we're going to work on) being the second of
those (it is the one that contains the addresses we want to lock)
whereas the first is now irrelevant, untouched, and we can (and will)
simply forget about. The second one gets its wired_count incremented
(which in our case moves it from 0 to 1.)
That's where things really start to go wrong, as that's supposed to
mean that the addresses [ed6000..eff000] are wired. That might be
OK if we actually wired them (yet to come) but it is not what was
requested.
There is then a check for holes, not really sure what that's about,
but if it happens we get an error (I'm guessing it indicates that we
have the situation aFrom this we go onto the next map entry, which in our case isn't
interesting (cannot possibly be: either there are no more, or the
next has a value for its ->start which is >= eff000, which is > end
(ed6000) so one way or the other, the loop that is pass1 terminates.
On to pass 2.
The entry we start at remains the [ed6000..eff000] which now has
wired_count == 1.
The pass2 loop is controlled by
while (entry != >header && entry->start < end) {
The first part of that is not an issue, and like in pass1, cannot
ever happen the first time around. But: entry->start == ed6000,
and end == ed6000, entry->start is not < end, and so we never
enter the loop.
Oops.
That loop is what actually makes the pages wired, and we're doing
none of that.
Pass2 loop "done", rv remains 0 (it only gets set inside the loop,
where we never go) so we simply return.
mlock() "succeeded".
And now, for the lead in to the panic (new KASSERT failed) when
we come to munlock()... (but of course, it is not simple!)
We enter uvm_map_pageable() again, with start==end==ed6000 since
we are doing an munlock(same addr as locked, 0).
As nothing else has affected this process, uvm_map_lookup_entry() finds
the entry we were just working on [ed6000..eff000] - the entry that
contains the start addr (just the same as last time). But now that
entry has wired_count == 1 (which happened just a bit earlier in this
message.)
The new_pagable case starts with
UVM_MAP_CLIP_START(map, entry, start);
to strip off any leading section of the map entry, that we are
not unlocking, but here start == entry->start so the unwire begins
at the beginning of the map entry. That call changes nothing.
As with the wiring case, there are 2 loops, loop 1
while ((entry != >header) && (entry->start < end)) {
Just like before the first condition is impossible for the first
iteration, but for the second, entry->start == end.
Loop done before it started. Doesn't matter, all that loop does
is validity checking on the range of addresses to be unlocked (just
like the "hole" check above I think). Our address range is valid
(well, kind of).
On to the second loop.
while ((entry != >header) && (entry->start < end)) {
Well, that's boring.
Re: zsh crash in recent -current
That makes perfect sense. I'll rebuild it without this flag. On Thu, 14 Mar 2019 at 12:21, Geoff Wing wrote: > > On Thursday 2019-03-14 10:57 +, ci4...@gmail.com output: > :Well, after installing the unstripped zsh+modules and ncurses, I no > :longer get zsh any crashes. Plus, as I mentioned, there was some > :jemalloc updates a couple of days ago. Hence, no idea. > > Hi, > if you ended up configuring with --enable-zsh-mem (as you mentioned trying in > a previous message) then you should not be using jemalloc at all but zsh's > mem routines - in which case it may avoid any use-after-free issues or > otherwise which jemalloc may expose. > > Regards, > Geoff --
Re: zsh crash in recent -current
On Thursday 2019-03-14 10:57 +, ci4...@gmail.com output: :Well, after installing the unstripped zsh+modules and ncurses, I no :longer get zsh any crashes. Plus, as I mentioned, there was some :jemalloc updates a couple of days ago. Hence, no idea. Hi, if you ended up configuring with --enable-zsh-mem (as you mentioned trying in a previous message) then you should not be using jemalloc at all but zsh's mem routines - in which case it may avoid any use-after-free issues or otherwise which jemalloc may expose. Regards, Geoff
Re: zsh crash in recent -current
Well, after installing the unstripped zsh+modules and ncurses, I no longer get zsh any crashes. Plus, as I mentioned, there was some jemalloc updates a couple of days ago. Hence, no idea. On Thu, 14 Mar 2019 at 05:23, matthew green wrote: > > > (while none I have ever seen actually do, the > > malloc implementation is free to retrn the memory to the kernel, and > > remove it from the process's address space). > > FWIW, both old and new jemalloc are capable of doing this. :-) > > > .mrg. --
Re: UFS2 feature: inode space used for data
Date:Thu, 14 Mar 2019 09:11:50 +0100 From:Rhialto Message-ID: <20190314081150.gh...@falu.nl> | I thought that was what I wrote... because of the "unused". The distinction Michael was getting at, is that an inode block could be considered "unused" if it contains no inodes that are in use to refer to any files. A better way of saying what I think you meant is "never used" to indicate that the block in question has never held a valid inode. That said, I have no idea of the answer to your original question. kre
Re: UFS2 feature: inode space used for data
On Wed 13 Mar 2019 at 21:44:11 -, Michael van Elst wrote: > rhia...@falu.nl (Rhialto) writes: > > >in the set is allocated and initialized. The set of blocks that may > >be allocated to inodes is held as part of the free-space reserve > >until all other space in the filesystem is allocated. Only then can > >it be used for file data. > > >But the bit at the end: if you don't need so many inodes, but run out of > >data space, then unused inode blocks can be re-purposed as data blocks. > > I says that blocks that might be used for inodes later aren't allocated > for data unless there is no other free block. It doesn't talk about > re-purposing inode blocks once they are used as such. I thought that was what I wrote... because of the "unused". -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
