svn commit: r340107 - head/libexec/rtld-elf
Author: kib
Date: Sun Nov 4 00:32:28 2018
New Revision: 340107
URL: https://svnweb.freebsd.org/changeset/base/340107
Log:
Remove Obj_Entry textsize member.
It is unused after r340102, and more important, I do not see how to
define textsize in both practically useful and correct way, for binaries
with more that one executable segments.
Sponsored by: The FreeBSD Foundation
Modified:
head/libexec/rtld-elf/map_object.c
head/libexec/rtld-elf/rtld.c
head/libexec/rtld-elf/rtld.h
Modified: head/libexec/rtld-elf/map_object.c
==
--- head/libexec/rtld-elf/map_object.c Sat Nov 3 23:37:13 2018
(r340106)
+++ head/libexec/rtld-elf/map_object.c Sun Nov 4 00:32:28 2018
(r340107)
@@ -287,7 +287,6 @@ map_object(int fd, const char *path, const struct stat
}
obj->mapbase = mapbase;
obj->mapsize = mapsize;
-obj->textsize = text_end - base_vaddr;
obj->vaddrbase = base_vaddr;
obj->relocbase = mapbase - base_vaddr;
obj->dynamic = (const Elf_Dyn *)(obj->relocbase + phdyn->p_vaddr);
Modified: head/libexec/rtld-elf/rtld.c
==
--- head/libexec/rtld-elf/rtld.cSat Nov 3 23:37:13 2018
(r340106)
+++ head/libexec/rtld-elf/rtld.cSun Nov 4 00:32:28 2018
(r340107)
@@ -1415,10 +1415,6 @@ digest_phdr(const Elf_Phdr *phdr, int phnum, caddr_t e
obj->vaddrbase;
}
nsegs++;
- if ((ph->p_flags & PF_X) == PF_X) {
- obj->textsize = MAX(obj->textsize,
- round_page(ph->p_vaddr + ph->p_memsz) - obj->vaddrbase);
- }
break;
case PT_DYNAMIC:
Modified: head/libexec/rtld-elf/rtld.h
==
--- head/libexec/rtld-elf/rtld.hSat Nov 3 23:37:13 2018
(r340106)
+++ head/libexec/rtld-elf/rtld.hSun Nov 4 00:32:28 2018
(r340107)
@@ -151,7 +151,6 @@ typedef struct Struct_Obj_Entry {
/* These items are computed by map_object() or by digest_phdr(). */
caddr_t mapbase; /* Base address of mapped region */
size_t mapsize;/* Size of mapped region in bytes */
-size_t textsize; /* Size of text segment in bytes */
Elf_Addr vaddrbase;/* Base address in shared object file */
caddr_t relocbase; /* Relocation constant = mapbase - vaddrbase */
const Elf_Dyn *dynamic;/* Dynamic section */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On Sat, Nov 03, 2018 at 06:59:02PM -0400, Charlie Li wrote: > On 03/11/2018 11:29, Konstantin Belousov wrote: > > Some minimal amount of facts instead of guesses would be much more useful. > > > Yeah, being sleep deprived and hurried (on my end) certainly doesn't help. > > What is the instruction which faulted ? Disassemble the text at 0x2f5664. > > Regardless of what is the instruction, show either the output from > > 'x86info -f' on the machine, or cpu identification lines from the > > _verbose_ boot dmesg. > > > It appears that 0x2f5664 does not exist: Or rather, it is a middle of the valid instruction. Next frame looks like it is process_irelocs(), if trusting the line numbers. So most likely it is something related to calling wrong relocator function, if anything. Perhaps you could try to trace the things manually, doing single-stepping of the startup code in debugger. There should be very modest amount of the irelocs, perhaps only one, and see where things go off the way. Might be try to vary the clang version, we know that this work with 6.0.1, and according to your report, breaks with 7.0. Try clang trunk ? > > Disassembly of section .init: > > 002f565c <_init>: > 2f565c: 48 83 ec 08 sub$0x8,%rsp > 2f5660: e8 fb 3c f3 ff callq 229360 > 2f5665: e8 b6 ff ff ff callq 2f5620 > <__do_global_ctors_aux> > 2f566a: 48 83 c4 08 add$0x8,%rsp > 2f566e: c3 retq > > CPU ident: > > CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x306d4 Family=0x6 Model=0x3d Stepping=4 > > Features=0xbfebfbff > > Features2=0x7ffafbbf > AMD Features=0x2c100800 > AMD Features2=0x121 > Structured Extended > Features=0x21c27ab > Structured Extended Features3=0x9c00 > XSAVE Features=0x1 > VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID > TSC: P-state invariant, performance statistics > > make is statically linked, do dynamically linked program fault ? > > > After some more checks, only the statically linked programs crash. > > -- > Charlie Li > Can't think of a witty .sigline today… > > (This email address is for mailing list use only; replace local-part > with vishwin for off-list communication) > ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r340106 - in head: contrib/netbsd-tests/lib/libc/time lib/libc/stdtime
Author: yuripv
Date: Sat Nov 3 23:37:13 2018
New Revision: 340106
URL: https://svnweb.freebsd.org/changeset/base/340106
Log:
strptime: make %k and %l specifiers match their description in
strftime(3), and allow them to process space-padded input.
PR: 230720
Submitted by: rlit...@inetco.com (original version)
Approved by: kib (mentor, implicit)
Differential Revision:https://reviews.freebsd.org/D17761
Modified:
head/contrib/netbsd-tests/lib/libc/time/t_strptime.c
head/lib/libc/stdtime/strptime.c
Modified: head/contrib/netbsd-tests/lib/libc/time/t_strptime.c
==
--- head/contrib/netbsd-tests/lib/libc/time/t_strptime.cSat Nov 3
22:12:21 2018(r340105)
+++ head/contrib/netbsd-tests/lib/libc/time/t_strptime.cSat Nov 3
23:37:13 2018(r340106)
@@ -331,8 +331,19 @@ ATF_TC_BODY(hour, tc)
h_fail("00", "%I");
h_fail("13", "%I");
+
#ifdef __FreeBSD__
- h_fail("00", "%l");
+ h_pass("0", "%k", 1, -1, -1, 0, -1, -1, -1, -1, -1);
+ h_pass("04", "%k", 2, -1, -1, 4, -1, -1, -1, -1, -1);
+ h_pass(" 8", "%k", 2, -1, -1, 8, -1, -1, -1, -1, -1);
+ h_pass("23", "%k", 2, -1, -1, 23, -1, -1, -1, -1, -1);
+ h_fail("24", "%k");
+
+ h_fail("0", "%l");
+ h_pass("1", "%l", 1, -1, -1, 1, -1, -1, -1, -1, -1);
+ h_pass("05", "%l", 2, -1, -1, 5, -1, -1, -1, -1, -1);
+ h_pass(" 9", "%l", 2, -1, -1, 9, -1, -1, -1, -1, -1);
+ h_pass("12", "%l", 2, -1, -1, 12, -1, -1, -1, -1, -1);
h_fail("13", "%l");
#endif
Modified: head/lib/libc/stdtime/strptime.c
==
--- head/lib/libc/stdtime/strptime.cSat Nov 3 22:12:21 2018
(r340105)
+++ head/lib/libc/stdtime/strptime.cSat Nov 3 23:37:13 2018
(r340106)
@@ -272,17 +272,24 @@ label:
case 'k':
case 'l':
/*
-* Of these, %l is the only specifier explicitly
-* documented as not being zero-padded. However,
-* there is no harm in allowing zero-padding.
+* %k and %l specifiers are documented as being
+* blank-padded. However, there is no harm in
+* allowing zero-padding.
*
-* XXX The %l specifier may gobble one too many
+* XXX %k and %l specifiers may gobble one too many
* digits if used incorrectly.
*/
+
+ len = 2;
+ if ((c == 'k' || c == 'l') &&
+ isblank_l((unsigned char)*buf, locale)) {
+ buf++;
+ len = 1;
+ }
+
if (!isdigit_l((unsigned char)*buf, locale))
return (NULL);
- len = 2;
for (i = 0; len && *buf != 0 &&
isdigit_l((unsigned char)*buf, locale); buf++) {
i *= 10;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 03/11/2018 11:29, Konstantin Belousov wrote: > Some minimal amount of facts instead of guesses would be much more useful. > Yeah, being sleep deprived and hurried (on my end) certainly doesn't help. > What is the instruction which faulted ? Disassemble the text at 0x2f5664. > Regardless of what is the instruction, show either the output from > 'x86info -f' on the machine, or cpu identification lines from the > _verbose_ boot dmesg. > It appears that 0x2f5664 does not exist: Disassembly of section .init: 002f565c <_init>: 2f565c: 48 83 ec 08 sub$0x8,%rsp 2f5660: e8 fb 3c f3 ff callq 229360 2f5665: e8 b6 ff ff ff callq 2f5620 <__do_global_ctors_aux> 2f566a: 48 83 c4 08 add$0x8,%rsp 2f566e: c3 retq CPU ident: CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306d4 Family=0x6 Model=0x3d Stepping=4 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21c27ab Structured Extended Features3=0x9c00 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics > make is statically linked, do dynamically linked program fault ? > After some more checks, only the statically linked programs crash. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
svn commit: r340104 - in head: share/colldef share/ctypedef share/monetdef share/numericdef tools/tools/locale tools/tools/locale/etc tools/tools/locale/etc/final-maps
Author: yuripv Date: Sat Nov 3 22:02:10 2018 New Revision: 340104 URL: https://svnweb.freebsd.org/changeset/base/340104 Log: Update to CLDR 34 and UNICODE 11. Discussed with: bapt Approved by: kib (mentor) MFC after:1 month Added: head/share/monetdef/fr_FR.UTF-8.src (contents, props changed) head/share/monetdef/it_IT.ISO8859-15.src - copied, changed from r340103, head/share/monetdef/de_AT.ISO8859-15.src head/share/monetdef/it_IT.UTF-8.src - copied, changed from r340103, head/share/monetdef/de_AT.UTF-8.src head/share/monetdef/nl_BE.ISO8859-1.src - copied unchanged from r340103, head/share/monetdef/de_AT.ISO8859-1.src head/share/numericdef/fr_FR.UTF-8.src (contents, props changed) Deleted: head/share/monetdef/de_AT.ISO8859-1.src head/share/monetdef/de_AT.ISO8859-15.src head/share/monetdef/de_AT.UTF-8.src Modified: head/share/colldef/af_ZA.UTF-8.src head/share/colldef/am_ET.UTF-8.src head/share/colldef/ar_SA.UTF-8.src head/share/colldef/be_BY.UTF-8.src head/share/colldef/ca_AD.UTF-8.src head/share/colldef/cs_CZ.ISO8859-2.src head/share/colldef/cs_CZ.UTF-8.src head/share/colldef/da_DK.ISO8859-1.src head/share/colldef/da_DK.ISO8859-15.src head/share/colldef/da_DK.UTF-8.src head/share/colldef/el_GR.UTF-8.src head/share/colldef/en_US.UTF-8.src head/share/colldef/es_MX.UTF-8.src head/share/colldef/et_EE.UTF-8.src head/share/colldef/fi_FI.UTF-8.src head/share/colldef/fr_CA.UTF-8.src head/share/colldef/he_IL.UTF-8.src head/share/colldef/hi_IN.UTF-8.src head/share/colldef/hr_HR.ISO8859-2.src head/share/colldef/hu_HU.ISO8859-2.src head/share/colldef/hu_HU.UTF-8.src head/share/colldef/hy_AM.UTF-8.src head/share/colldef/is_IS.UTF-8.src head/share/colldef/ja_JP.UTF-8.src head/share/colldef/ja_JP.eucJP.src head/share/colldef/kk_KZ.UTF-8.src head/share/colldef/ko_KR.UTF-8.src head/share/colldef/lt_LT.UTF-8.src head/share/colldef/lv_LV.UTF-8.src head/share/colldef/nb_NO.ISO8859-1.src head/share/colldef/nb_NO.ISO8859-15.src head/share/colldef/nn_NO.ISO8859-1.src head/share/colldef/nn_NO.ISO8859-15.src head/share/colldef/nn_NO.UTF-8.src head/share/colldef/pl_PL.UTF-8.src head/share/colldef/ro_RO.UTF-8.src head/share/colldef/ru_RU.UTF-8.src head/share/colldef/se_NO.UTF-8.src head/share/colldef/sk_SK.ISO8859-2.src head/share/colldef/sk_SK.UTF-8.src head/share/colldef/sl_SI.UTF-8.src head/share/colldef/sr_RS.ISO8859-2.src head/share/colldef/sr_RS.ISO8859-5.src head/share/colldef/sr_RS.UTF-8.src head/share/colldef/sr_rs.ut...@latin.src head/share/colldef/sv_SE.UTF-8.src head/share/colldef/tr_TR.UTF-8.src head/share/colldef/uk_UA.UTF-8.src head/share/colldef/zh_CN.GB18030.src head/share/colldef/zh_CN.GB2312.src head/share/colldef/zh_CN.GBK.src head/share/colldef/zh_CN.UTF-8.src head/share/colldef/zh_CN.eucCN.src head/share/colldef/zh_TW.Big5.src head/share/colldef/zh_TW.UTF-8.src head/share/ctypedef/Makefile head/share/ctypedef/ca_IT.ISO8859-1.src head/share/ctypedef/en_US.ISO8859-1.src head/share/ctypedef/hi_IN.ISCII-DEV.src head/share/ctypedef/hy_AM.ARMSCII-8.src head/share/ctypedef/ja_JP.eucJP.src head/share/ctypedef/zh_CN.eucCN.src head/share/monetdef/Makefile head/share/monetdef/fr_CH.UTF-8.src head/share/monetdef/hy_AM.ARMSCII-8.src head/share/monetdef/hy_AM.UTF-8.src head/share/monetdef/mn_MN.UTF-8.src head/share/monetdef/nl_BE.ISO8859-15.src head/share/monetdef/nl_BE.UTF-8.src head/share/numericdef/Makefile head/tools/tools/locale/Makefile head/tools/tools/locale/etc/charmaps.xml head/tools/tools/locale/etc/final-maps/map.UTF-8 Modified: head/share/colldef/af_ZA.UTF-8.src == --- head/share/colldef/af_ZA.UTF-8.src Sat Nov 3 21:59:52 2018 (r340103) +++ head/share/colldef/af_ZA.UTF-8.src Sat Nov 3 22:02:10 2018 (r340104) @@ -60,6 +60,7 @@ collating-symbol collating-symbol collating-symbol collating-symbol +collating-symbol collating-symbol collating-symbol collating-symbol @@ -70,431 +71,433 @@ collating-symbol collating-symbol collating-symbol collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol -collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol +collating-symbol collating-symbol
svn commit: r340102 - in head/libexec/rtld-elf: powerpc powerpc64
Author: kib
Date: Sat Nov 3 20:39:16 2018
New Revision: 340102
URL: https://svnweb.freebsd.org/changeset/base/340102
Log:
Flush data cache for executable loadable segments explicitly.
Do not use textsize and do not flush everything between map base and
base + textsize, because unmapped areas cannot be flushed.
This makes Obj_Entry textsize only use go away, and I will remove it
later.
Reported by: tuexen
Tested by:Mark Millard
Sponsored by: The FreeBSD Foundation
Modified:
head/libexec/rtld-elf/powerpc/reloc.c
head/libexec/rtld-elf/powerpc64/reloc.c
Modified: head/libexec/rtld-elf/powerpc/reloc.c
==
--- head/libexec/rtld-elf/powerpc/reloc.c Sat Nov 3 20:35:39 2018
(r340101)
+++ head/libexec/rtld-elf/powerpc/reloc.c Sat Nov 3 20:39:16 2018
(r340102)
@@ -294,6 +294,7 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld, int
{
const Elf_Rela *relalim;
const Elf_Rela *rela;
+ const Elf_Phdr *phdr;
SymCache *cache;
int r = -1;
@@ -327,8 +328,18 @@ done:
if (cache != NULL)
free(cache);
- /* Synchronize icache for text seg in case we made any changes */
- __syncicache(obj->mapbase, obj->textsize);
+ /*
+* Synchronize icache for executable segments in case we made
+* any changes.
+*/
+ for (phdr = obj->phdr;
+ (const char *)phdr < (const char *)obj->phdr + obj->phsize;
+ phdr++) {
+ if (phdr->p_type == PT_LOAD && (phdr->p_flags & PF_X) != 0) {
+ __syncicache(obj->relocbase + phdr->p_vaddr,
+ phdr->p_memsz);
+ }
+ }
return (r);
}
Modified: head/libexec/rtld-elf/powerpc64/reloc.c
==
--- head/libexec/rtld-elf/powerpc64/reloc.c Sat Nov 3 20:35:39 2018
(r340101)
+++ head/libexec/rtld-elf/powerpc64/reloc.c Sat Nov 3 20:39:16 2018
(r340102)
@@ -291,6 +291,7 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld, int
{
const Elf_Rela *relalim;
const Elf_Rela *rela;
+ const Elf_Phdr *phdr;
SymCache *cache;
int bytes = obj->dynsymcount * sizeof(SymCache);
int r = -1;
@@ -327,8 +328,18 @@ done:
if (cache)
munmap(cache, bytes);
- /* Synchronize icache for text seg in case we made any changes */
- __syncicache(obj->mapbase, obj->textsize);
+ /*
+* Synchronize icache for executable segments in case we made
+* any changes.
+*/
+ for (phdr = obj->phdr;
+ (const char *)phdr < (const char *)obj->phdr + obj->phsize;
+ phdr++) {
+ if (phdr->p_type == PT_LOAD && (phdr->p_flags & PF_X) != 0) {
+ __syncicache(obj->relocbase + phdr->p_vaddr,
+ phdr->p_memsz);
+ }
+ }
return (r);
}
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r340100 - head/sbin/ipfw
Author: ae
Date: Sat Nov 3 20:05:50 2018
New Revision: 340100
URL: https://svnweb.freebsd.org/changeset/base/340100
Log:
Do not use bzero() for the O_ICMP6TYPE opcode.
The buffer is already zeroed in compile_rule() function, and also it
may contain configured F_NOT flag in o.len field. This fixes the filling
for "not icmp6types" opcode.
PR: 232939
MFC after:3 days
Modified:
head/sbin/ipfw/ipv6.c
Modified: head/sbin/ipfw/ipv6.c
==
--- head/sbin/ipfw/ipv6.c Sat Nov 3 19:31:11 2018(r340099)
+++ head/sbin/ipfw/ipv6.c Sat Nov 3 20:05:50 2018(r340100)
@@ -143,8 +143,6 @@ fill_icmp6types(ipfw_insn_icmp6 *cmd, char *av, int cb
uint8_t type;
CHECK_LENGTH(cblen, F_INSN_SIZE(ipfw_insn_icmp6));
-
- bzero(cmd, sizeof(*cmd));
while (*av) {
if (*av == ',')
av++;
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339876 - head/libexec/rtld-elf
On 2018-Nov-3, at 12:04 PM, Mark Millard wrote: > On 2018-Nov-3, at 8:49 AM, Konstantin Belousov wrote: > >> On Fri, Nov 02, 2018 at 05:51:25PM -0700, Mark Millard wrote: >>> On 2018-Nov-2, at 11:50 AM, Konstantin Belousov >>> wrote: >>> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote: > . . . There seems to be an issue with the direct execution mode on ppc. Even otherwise working ld-elf.so.1 segfaults if I try to use it as standalone binary. But if I specify patched ld-elf.so.1 as the interpreter for some program, using 'cc -Wl,-I,/ld-elf.so.1' it works. So I see there two bugs, one is regression due to textsize calculation, which should be fixed by my patch. Another is the direct exec problem. >>> >>> My head -r339076 based powerpc64 and armv7 contexts also >>> fail for: >>> >>> # /libexec/ld-elf.so.1 /bin/ls >>> >>> The armv7 (a Cortext-A7 context) is interestingly different >>> in how it fails: >>> >>> # /libexec/ld-elf.so.1 /bin/ls >>> ld-elf.so.1: /bin/ls: mmap of entire address space failed: Cannot allocate >>> memory >> Can you show the ktrace/kdump for this ? > > Sure, in the Cortex-A7 context . . . > > . . . > > >>> My aarch64 context (a Cortext-A53 context) had no problem. >>> >>> (All 3 examples are without any of the the recent updates >>> or patches to ld-elf.so.1 source code.) >> >> And still, does the patch for isync range works ? You can test the new >> ld-elf.so.1 standalone by hard-coding its path into the binary. Build e.g. >> only ls(1) by using make in its directory, then re-issue the linking >> command with the additional flag '-Wl,-I, >> and try to run ls.full. > > Looks like the old PowerMac is available again for > such activity. So I'll see about testing. I tried installing a buildworld that has the patches via using the make arguments: installworld distrib-dirs distribution DB_FROM_SRC=1 DESTDIR=/usr/obj/DESTDIRs/gcc421-powerpc-installworld-poud (I normally have poudriere-devel use this gcc421-powerpc-installworld-poud in this environment.) Then: # chroot /usr/obj/DESTDIRs/gcc421-powerpc-installworld-poud # pwd / # ls .cshrc COPYRIGHT bootetc libexec mnt procroottmp var .profilebin dev lib media net rescue sbinusr # df -m Filesystem 1M-blocks Used Avail Capacity Mounted on /dev/ufs/FBSDG4Srootfs 95203 38217 4936944%/ devfs 0 0 0 100%/dev # ls -lTd /bin/ls -r-xr-xr-x 1 root wheel 36816 Nov 3 19:19:26 2018 /bin/ls # ls -lTd /libexec/ld-elf.so.1* -r-xr-xr-x 1 root wheel 136100 Nov 3 19:17:53 2018 /libexec/ld-elf.so.1 -r-xr-xr-x 1 root wheel 135932 Nov 2 02:10:34 2018 /libexec/ld-elf.so.1.old # /usr/libexec/gdb /libexec/ld-elf.so.1 . . . (gdb) disass reloc_non_plt Dump of assembler code for function reloc_non_plt: . . . 0x2b48 : bl 0xef78 0x2b4c : lwz r31,64(r29) 0x2b50 : lwz r9,68(r29) 0x2b54 : mr r11,r31 0x2b58 : add r0,r31,r9 0x2b5c : cmplw cr7,r31,r0 0x2b60 : blt+cr7,0x2b78 0x2b64 : b 0x2bbc 0x2b68 : addir31,r31,32 0x2b6c : add r0,r11,r9 0x2b70 : cmplw cr7,r0,r31 0x2b74 : ble-cr7,0x2bbc 0x2b78 : lwz r0,0(r31) 0x2b7c : cmpwi cr7,r0,1 0x2b80 : bne+cr7,0x2b68 0x2b84 : lwz r0,24(r31) 0x2b88 : andi. r10,r0,1 ---Type to continue, or q to quit--- 0x2b8c : beq+0x2b68 0x2b90 : lwz r0,52(r29) 0x2b94 : lwz r3,8(r31) 0x2b98 : lwz r4,20(r31) 0x2b9c : addir31,r31,32 0x2ba0 : add r3,r0,r3 0x2ba4 : bl 0x12858 <__syncicache> 0x2ba8 : lwz r11,64(r29) 0x2bac : lwz r9,68(r29) 0x2bb0 : add r0,r11,r9 0x2bb4 : cmplw cr7,r0,r31 0x2bb8 : bgt+cr7,0x2b78 . . . So, unless the chroot somehow bypasses use of that local /libexec/ld-elf.so.1 , the __synicache in a loop seems to be working under the chroot use. Let me know if this test is insufficient for some reason. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339876 - head/libexec/rtld-elf
On Sat, Nov 03, 2018 at 12:04:53PM -0700, Mark Millard wrote: > 80903 ld-elf.so.1 CALL > mmap(0x1,0xb000,0,0x6010,0x,0x1,0,0) > 80903 ld-elf.so.1 RET mmap -1 errno 12 Cannot allocate memory This is the allocation of VA for the whole binary. I guess that the normal non-PIE binary virtual base on arm is 0x1. I put the arm PIE base at 0x12000, which obviously causes the conflict between pre-loaded ld-elf.so.1 and later attempt to mmap the binary at the linked address. In fact I am happy that we added MAP_EXCL and it catched the situation. You can try to change ET_DYN_LOAD_ADDR on arm: diff --git a/sys/arm/include/elf.h b/sys/arm/include/elf.h index 7424b45e78f..28fc14e3dae 100644 --- a/sys/arm/include/elf.h +++ b/sys/arm/include/elf.h @@ -84,7 +84,7 @@ __ElfType(Auxinfo); */ #defineMAGIC_TRAMP_NUMBER 0x5c03 -#defineET_DYN_LOAD_ADDR0x12000 +#defineET_DYN_LOAD_ADDR0x50 /* Flags passed in AT_HWCAP. */ #defineHWCAP_SWP 0x0001 /* Unsupported, never set.*/ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r340099 - head
Author: emaste
Date: Sat Nov 3 19:31:11 2018
New Revision: 340099
URL: https://svnweb.freebsd.org/changeset/base/340099
Log:
libcompat: disable retpoline when building build tools
These are built with the host toolchain which may not support retpoline.
While here, move the MK_ overrides to a separate line and sort them
alphabetically to support future changes.
MFC with: r339511
Sponsored by: The FreeBSD Foundation
Modified:
head/Makefile.libcompat
Modified: head/Makefile.libcompat
==
--- head/Makefile.libcompat Sat Nov 3 18:03:24 2018(r340098)
+++ head/Makefile.libcompat Sat Nov 3 19:31:11 2018(r340099)
@@ -200,7 +200,8 @@ build${libcompat}: .PHONY
OBJTOP=${LIBCOMPAT_OBJTOP} \
OBJROOT='$${OBJTOP}/' \
MAKEOBJDIRPREFIX= \
- DIRPRFX=${_dir}/ -DNO_LINT -DNO_CPU_CFLAGS MK_WARNS=no MK_CTF=no \
+ DIRPRFX=${_dir}/ -DNO_LINT -DNO_CPU_CFLAGS \
+ MK_CTF=no MK_RETPOLINE=no MK_WARNS=no \
${_t}
.endfor
.endfor
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339876 - head/libexec/rtld-elf
On 2018-Nov-3, at 8:49 AM, Konstantin Belousov wrote:
> On Fri, Nov 02, 2018 at 05:51:25PM -0700, Mark Millard wrote:
>> On 2018-Nov-2, at 11:50 AM, Konstantin Belousov
>> wrote:
>>
>>> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote:
. . .
>>>
>>> There seems to be an issue with the direct execution mode on ppc.
>>> Even otherwise working ld-elf.so.1 segfaults if I try to use it as
>>> standalone binary.
>>>
>>> But if I specify patched ld-elf.so.1 as the interpreter for some program,
>>> using 'cc -Wl,-I,/ld-elf.so.1' it works. So I see there two bugs,
>>> one is regression due to textsize calculation, which should be fixed by
>>> my patch. Another is the direct exec problem.
>>
>> My head -r339076 based powerpc64 and armv7 contexts also
>> fail for:
>>
>> # /libexec/ld-elf.so.1 /bin/ls
>>
>> The armv7 (a Cortext-A7 context) is interestingly different
>> in how it fails:
>>
>> # /libexec/ld-elf.so.1 /bin/ls
>> ld-elf.so.1: /bin/ls: mmap of entire address space failed: Cannot allocate
>> memory
> Can you show the ktrace/kdump for this ?
Sure, in the Cortex-A7 context . . .
# ktrace -t+ /libexec/ld-elf.so.1 /bin/ls
ld-elf.so.1: /bin/ls: mmap of entire address space failed: Cannot allocate
memory
# kdump | less
80903 ktrace RET ktrace 0
80903 ktrace CALL execve(0xbfbfee23,0xbfbfecf0,0xbfbfecfc)
80903 ktrace NAMI "/libexec/ld-elf.so.1"
80903 ld-elf.so.1 RET execve JUSTRETURN
80903 ld-elf.so.1 CALL
mmap(0,0x2,0x3,0x1002,0x,0,0,0)
80903 ld-elf.so.1 RET mmap 537071616/0x20031000
80903 ld-elf.so.1 CALL issetugid
80903 ld-elf.so.1 RET issetugid 0
80903 ld-elf.so.1 CALL
openat(AT_FDCWD,0xbfbfee2d,0x30)
80903 ld-elf.so.1 NAMI "/bin/ls"
80903 ld-elf.so.1 RET openat 3
80903 ld-elf.so.1 CALL fstat(0x3,0xbfbfe638)
80903 ld-elf.so.1 STRU struct stat {dev=95, ino=2568217, mode=0100555,
nlink=1, uid=0, gid=0, rdev=5140776, atime=1538464078.957949000,
mtime=1538464078.958055000, ctime=1538464078.95881,
birthtime=1538464078.957947000, size=39440, blksize=32768, blocks=80, flags=0x0
}
80903 ld-elf.so.1 RET fstat 0
80903 ld-elf.so.1 CALL geteuid
80903 ld-elf.so.1 RET geteuid 0
80903 ld-elf.so.1 CALL
mmap(0,0x1000,0x1,0x40002,0x3,0,0,0)
80903 ld-elf.so.1 RET mmap 537202688/0x20051000
80903 ld-elf.so.1 CALL
mmap(0x1,0xb000,0,0x6010,0x,0x1,0,0)
80903 ld-elf.so.1 RET mmap -1 errno 12 Cannot allocate memory
80903 ld-elf.so.1 CALL munmap(0x20051000,0x1000)
80903 ld-elf.so.1 RET munmap 0
80903 ld-elf.so.1 CALL close(0x3)
80903 ld-elf.so.1 RET close 0
80903 ld-elf.so.1 CALL write(0x2,0x12e38,0xd)
80903 ld-elf.so.1 GIO fd 2 wrote 13 bytes
"ld-elf.so.1: "
80903 ld-elf.so.1 RET write 13/0xd
80903 ld-elf.so.1 CALL write(0x2,0x33238,0x44)
80903 ld-elf.so.1 GIO fd 2 wrote 68 bytes
"/bin/ls: mmap of entire address space failed: Cannot allocate memory"
80903 ld-elf.so.1 RET write 68/0x44
80903 ld-elf.so.1 CALL write(0x2,0xbfbfe1e7,0x1)
80903 ld-elf.so.1 GIO fd 2 wrote 1 byte
"
"
80903 ld-elf.so.1 RET write 1
80903 ld-elf.so.1 CALL exit(0x1)
>> My aarch64 context (a Cortext-A53 context) had no problem.
>>
>> (All 3 examples are without any of the the recent updates
>> or patches to ld-elf.so.1 source code.)
>
> And still, does the patch for isync range works ? You can test the new
> ld-elf.so.1 standalone by hard-coding its path into the binary. Build e.g.
> only ls(1) by using make in its directory, then re-issue the linking
> command with the additional flag '-Wl,-I,
> and try to run ls.full.
Looks like the old PowerMac is available again for
such activity. So I'll see about testing.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r340098 - in head/usr.sbin: ndp rtadvd
Author: bz
Date: Sat Nov 3 18:03:24 2018
New Revision: 340098
URL: https://svnweb.freebsd.org/changeset/base/340098
Log:
Update the "flag" for draft-ietf-6man-ipv6only-flag.
Having the flag named "6" can possibly be a problem for configurations
where parsing strings and numbers can produce ambivalent results.
Rename the "6" flag to the "S"ix (or Silence-IPv4) flag.
Modified:
head/usr.sbin/ndp/ndp.c
head/usr.sbin/rtadvd/config.c
head/usr.sbin/rtadvd/rtadvd.c
Modified: head/usr.sbin/ndp/ndp.c
==
--- head/usr.sbin/ndp/ndp.c Sat Nov 3 03:43:32 2018(r340097)
+++ head/usr.sbin/ndp/ndp.c Sat Nov 3 18:03:24 2018(r340098)
@@ -1097,7 +1097,7 @@ rtrlist()
p->flags & ND_RA_FLAG_MANAGED ? "M" : "",
p->flags & ND_RA_FLAG_OTHER ? "O" : "");
#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
- printf("%s", p->flags & ND_RA_FLAG_IPV6_ONLY ? "6" : "");
+ printf("%s", p->flags & ND_RA_FLAG_IPV6_ONLY ? "S" : "");
#endif
rtpref = ((p->flags & ND_RA_FLAG_RTPREF_MASK) >> 3) & 0xff;
printf(", pref=%s", rtpref_str[rtpref]);
Modified: head/usr.sbin/rtadvd/config.c
==
--- head/usr.sbin/rtadvd/config.c Sat Nov 3 03:43:32 2018
(r340097)
+++ head/usr.sbin/rtadvd/config.c Sat Nov 3 18:03:24 2018
(r340098)
@@ -438,7 +438,7 @@ getconfig(struct ifinfo *ifi)
val |= ND_RA_FLAG_RTPREF_LOW;
}
#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
- if (strchr(flagstr, '6'))
+ if (strchr(flagstr, 'S'))
val |= ND_RA_FLAG_IPV6_ONLY;
#endif
} else
Modified: head/usr.sbin/rtadvd/rtadvd.c
==
--- head/usr.sbin/rtadvd/rtadvd.c Sat Nov 3 03:43:32 2018
(r340097)
+++ head/usr.sbin/rtadvd/rtadvd.c Sat Nov 3 18:03:24 2018
(r340098)
@@ -1161,11 +1161,11 @@ ra_input(int len, struct nd_router_advert *nra,
inconsistent++;
}
#ifdef DRAFT_IETF_6MAN_IPV6ONLY_FLAG
- /* 6 flag */
+ /* S "IPv6-Only" (Six, Silence-IPv4) flag */
if ((nra->nd_ra_flags_reserved & ND_RA_FLAG_IPV6_ONLY) !=
rai->rai_ipv6onlyflg) {
syslog(LOG_NOTICE,
- "6 flag inconsistent on %s:"
+ "S flag inconsistent on %s:"
" %s from %s, %s from us",
ifi->ifi_ifname, on_off[!rai->rai_ipv6onlyflg],
inet_ntop(AF_INET6, >sin6_addr, ntopbuf,
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339388 - head/sys/dev/usb/controller
On 11/3/18 1:15 PM, Herbert J. Skuhra wrote: On Tue, 16 Oct 2018 20:47:13 +0200, Hans Petter Selasky wrote: Author: hselasky Date: Tue Oct 16 18:47:13 2018 New Revision: 339388 URL: https://svnweb.freebsd.org/changeset/base/339388 Log: Fix for reception of large full speed isochronous frames via the transaction translator, when using the DWC OTG USB controller driver. Make sure to re-try getting the complete split packets until a DATA0 packet is received. Larger isochronous frames may be split into multiple MDATA packets terminated by a single DATA0 packet. PR: 230434 MFC after: 3 days Approved by: re (gjb) Sponsored by:Mellanox Technologies Modified: head/sys/dev/usb/controller/dwc_otg.c Hei, I use a Sound Blaster Play 2 USB soundcard on a Raspberry Pi 2 and a Raspberry Pi 3 to listen to internet radio streams (e.g. NRK, SR, BBC, etc.). After this commit audio quality is deteriorated (strange noises). I've tried mpg123 and moc. -- Herbert Hi, How many channels does your audio device have? What sample rates are you using? What happens if you lower the vchanrate? dmesg ? What are the following sysctl values? dev.pcm.x.rec.vchanrate: 48000 dev.pcm.x.play.vchanrate: 48000 x is 0 or 1. --HPS ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339876 - head/libexec/rtld-elf
On Fri, Nov 02, 2018 at 05:51:25PM -0700, Mark Millard wrote: > On 2018-Nov-2, at 11:50 AM, Konstantin Belousov > wrote: > > > On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote: > >> . . . > > > > There seems to be an issue with the direct execution mode on ppc. > > Even otherwise working ld-elf.so.1 segfaults if I try to use it as > > standalone binary. > > > > But if I specify patched ld-elf.so.1 as the interpreter for some program, > > using 'cc -Wl,-I,/ld-elf.so.1' it works. So I see there two bugs, > > one is regression due to textsize calculation, which should be fixed by > > my patch. Another is the direct exec problem. > > My head -r339076 based powerpc64 and armv7 contexts also > fail for: > > # /libexec/ld-elf.so.1 /bin/ls > > The armv7 (a Cortext-A7 context) is interestingly different > in how it fails: > > # /libexec/ld-elf.so.1 /bin/ls > ld-elf.so.1: /bin/ls: mmap of entire address space failed: Cannot allocate > memory Can you show the ktrace/kdump for this ? > > My aarch64 context (a Cortext-A53 context) had no problem. > > (All 3 examples are without any of the the recent updates > or patches to ld-elf.so.1 source code.) And still, does the patch for isync range works ? You can test the new ld-elf.so.1 standalone by hard-coding its path into the binary. Build e.g. only ls(1) by using make in its directory, then re-issue the linking command with the additional flag '-Wl,-I, and try to run ls.full. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On Sat, Nov 03, 2018 at 08:52:16AM -0400, Charlie Li wrote: > On 01/11/2018 15:43, Charlie Li wrote: > > On 01/11/2018 12:04, Brooks Davis wrote: > >> Is this failure with devel/llvm70? It's currently missing the patch > >> required to make this work. https://reviews.freebsd.org/D17709 contains > >> this patch among others. I'll see about getting it applied. > >> > > Yes, devel/llvm70. Will build with your port commit at my next opportunity. > > > After building world and kernel r340097, kernel runs fine, but every > userspace program in world crashes with Illegal instruction. They all > crash in exactly the same way. Example backtrace from bmake, running > from objdir (first discovered after updating a poudriere jail and > attempting to even start it): > > Reading symbols from > /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from > /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done. > done. > [New LWP 100097] > Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make > --help'. > Program terminated with signal SIGILL, Illegal instruction. > #0 0x002f5664 in _init () > (gdb) bt > #0 0x002f5664 in _init () > #1 0x002290fe in _start (ap=, cleanup= out>) at /usr/src/lib/csu/amd64/crt1.c:66 > > Given the line number referenced in crt1.c, I'm guessing this condition > may have existed since at least r339351. Some minimal amount of facts instead of guesses would be much more useful. What is the instruction which faulted ? Disassemble the text at 0x2f5664. Regardless of what is the instruction, show either the output from 'x86info -f' on the machine, or cpu identification lines from the _verbose_ boot dmesg. make is statically linked, do dynamically linked program fault ? ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 01/11/2018 15:43, Charlie Li wrote: > On 01/11/2018 12:04, Brooks Davis wrote: >> Is this failure with devel/llvm70? It's currently missing the patch >> required to make this work. https://reviews.freebsd.org/D17709 contains >> this patch among others. I'll see about getting it applied. >> > Yes, devel/llvm70. Will build with your port commit at my next opportunity. > After building world and kernel r340097, kernel runs fine, but every userspace program in world crashes with Illegal instruction. They all crash in exactly the same way. Example backtrace from bmake, running from objdir (first discovered after updating a poudriere jail and attempting to even start it): Reading symbols from /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done. done. [New LWP 100097] Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make --help'. Program terminated with signal SIGILL, Illegal instruction. #0 0x002f5664 in _init () (gdb) bt #0 0x002f5664 in _init () #1 0x002290fe in _start (ap=, cleanup=) at /usr/src/lib/csu/amd64/crt1.c:66 Given the line number referenced in crt1.c, I'm guessing this condition may have existed since at least r339351. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339388 - head/sys/dev/usb/controller
On Tue, 16 Oct 2018 20:47:13 +0200, Hans Petter Selasky wrote: > > Author: hselasky > Date: Tue Oct 16 18:47:13 2018 > New Revision: 339388 > URL: https://svnweb.freebsd.org/changeset/base/339388 > > Log: > Fix for reception of large full speed isochronous frames via the transaction > translator, when using the DWC OTG USB controller driver. Make sure to > re-try > getting the complete split packets until a DATA0 packet is received. Larger > isochronous frames may be split into multiple MDATA packets terminated > by a single DATA0 packet. > > PR: 230434 > MFC after: 3 days > Approved by:re (gjb) > Sponsored by: Mellanox Technologies > > Modified: > head/sys/dev/usb/controller/dwc_otg.c Hei, I use a Sound Blaster Play 2 USB soundcard on a Raspberry Pi 2 and a Raspberry Pi 3 to listen to internet radio streams (e.g. NRK, SR, BBC, etc.). After this commit audio quality is deteriorated (strange noises). I've tried mpg123 and moc. -- Herbert ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r340097 - in head/sys: kern sys
Author: mmacy
Date: Sat Nov 3 03:43:32 2018
New Revision: 340097
URL: https://svnweb.freebsd.org/changeset/base/340097
Log:
Convert epoch to read / write records per cpu
In discussing D17503 "Run epoch calls sooner and more reliably" with
sbahra@ we came to the conclusion that epoch is currently misusing the
ck_epoch API. It isn't safe to do a "write side" operation (ck_epoch_call
or ck_epoch_poll) in the middle of a "read side" section. Since, by
definition,
it's possible to be preempted during the middle of an EPOCH_PREEMPT
epoch the GC task might call ck_epoch_poll or another thread might call
ck_epoch_call on the same section. The right solution is ultimately to change
the way that ck_epoch works for this use case. However, as a stopgap for
12 we agreed to simply have separate records for each use case.
Tested by: pho@
MFC after:3 days
Modified:
head/sys/kern/subr_epoch.c
head/sys/sys/epoch_private.h
Modified: head/sys/kern/subr_epoch.c
==
--- head/sys/kern/subr_epoch.c Sat Nov 3 03:10:06 2018(r340096)
+++ head/sys/kern/subr_epoch.c Sat Nov 3 03:43:32 2018(r340097)
@@ -150,7 +150,8 @@ epoch_ctor(epoch_t epoch)
CPU_FOREACH(cpu) {
er = zpcpu_get_cpu(epoch->e_pcpu_record, cpu);
bzero(er, sizeof(*er));
- ck_epoch_register(>e_epoch, >er_record, NULL);
+ ck_epoch_register(>e_epoch, >er_read_record, NULL);
+ ck_epoch_register(>e_epoch, >er_write_record, NULL);
TAILQ_INIT((struct threadlist *)(uintptr_t)>er_tdlist);
er->er_cpuid = cpu;
}
@@ -235,7 +236,7 @@ epoch_block_handler_preempt(struct ck_epoch *global __
int spincount, gen;
int locksheld __unused;
- record = __containerof(cr, struct epoch_record, er_record);
+ record = __containerof(cr, struct epoch_record, er_read_record);
td = curthread;
locksheld = td->td_locks;
spincount = 0;
@@ -461,7 +462,7 @@ epoch_call(epoch_t epoch, epoch_context_t ctx, void (*
critical_enter();
*DPCPU_PTR(epoch_cb_count) += 1;
er = epoch_currecord(epoch);
- ck_epoch_call(>er_record, cb, (ck_epoch_cb_t *)callback);
+ ck_epoch_call(>er_write_record, cb, (ck_epoch_cb_t *)callback);
critical_exit();
return;
boottime:
@@ -485,7 +486,7 @@ epoch_call_task(void *arg __unused)
if (__predict_false((epoch = allepochs[i]) == NULL))
continue;
er = epoch_currecord(epoch);
- record = >er_record;
+ record = >er_write_record;
if ((npending = record->n_pending) == 0)
continue;
ck_epoch_poll_deferred(record, _stack);
Modified: head/sys/sys/epoch_private.h
==
--- head/sys/sys/epoch_private.hSat Nov 3 03:10:06 2018
(r340096)
+++ head/sys/sys/epoch_private.hSat Nov 3 03:43:32 2018
(r340097)
@@ -89,7 +89,8 @@ typedef struct epoch_thread {
TAILQ_HEAD (epoch_tdlist, epoch_thread);
typedef struct epoch_record {
- ck_epoch_record_t er_record;
+ ck_epoch_record_t er_read_record;
+ ck_epoch_record_t er_write_record;
volatile struct epoch_tdlist er_tdlist;
volatile uint32_t er_gen;
uint32_t er_cpuid;
@@ -138,7 +139,7 @@ epoch_enter_preempt(epoch_t epoch, epoch_tracker_t et)
td->td_pre_epoch_prio = td->td_priority;
er = epoch_currecord(epoch);
TAILQ_INSERT_TAIL(>er_tdlist, etd, et_link);
- ck_epoch_begin(>er_record, (ck_epoch_section_t *)>et_section);
+ ck_epoch_begin(>er_read_record, (ck_epoch_section_t
*)>et_section);
critical_exit_sa(td);
}
@@ -155,7 +156,7 @@ epoch_enter(epoch_t epoch)
td->td_epochnest++;
critical_enter_sa(td);
er = epoch_currecord(epoch);
- ck_epoch_begin(>er_record, NULL);
+ ck_epoch_begin(>er_read_record, NULL);
}
static __inline void
@@ -183,7 +184,7 @@ epoch_exit_preempt(epoch_t epoch, epoch_tracker_t et)
etd->et_magic_post = 0;
#endif
etd->et_td = (void*)0xDEADBEEF;
- ck_epoch_end(>er_record,
+ ck_epoch_end(>er_read_record,
(ck_epoch_section_t *)>et_section);
TAILQ_REMOVE(>er_tdlist, etd, et_link);
er->er_gen++;
@@ -203,7 +204,7 @@ epoch_exit(epoch_t epoch)
MPASS(td->td_epochnest);
td->td_epochnest--;
er = epoch_currecord(epoch);
- ck_epoch_end(>er_record, NULL);
+ ck_epoch_end(>er_read_record, NULL);
critical_exit_sa(td);
}
#endif /* _KERNEL */
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to
