svn commit: r340212 - head/sys/dev/usb/controller
Author: hselasky
Date: Wed Nov 7 08:25:44 2018
New Revision: 340212
URL: https://svnweb.freebsd.org/changeset/base/340212
Log:
Sometimes the complete split packet may be queued too early and the
transaction translator will return a NAK. Ignore this message and
retry the complete split instead.
MFC after:3 days
Sponsored by: Mellanox Technologies
Modified:
head/sys/dev/usb/controller/dwc_otg.c
Modified: head/sys/dev/usb/controller/dwc_otg.c
==
--- head/sys/dev/usb/controller/dwc_otg.c Wed Nov 7 06:29:01 2018
(r340211)
+++ head/sys/dev/usb/controller/dwc_otg.c Wed Nov 7 08:25:44 2018
(r340212)
@@ -1432,6 +1432,19 @@ dwc_otg_host_data_rx(struct dwc_otg_softc *sc, struct
goto receive_pkt;
}
} else if (td->ep_type == UE_ISOCHRONOUS) {
+ if (td->hcsplt != 0) {
+ /*
+* Sometimes the complete
+* split packet may be queued
+* too early and the
+* transaction translator will
+* return a NAK. Ignore
+* this message and retry the
+* complete split instead.
+*/
+ DPRINTF("Retrying complete split\n");
+ goto receive_pkt;
+ }
goto complete;
}
td->did_nak = 1;
___
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: r340213 - in head: lib/csu/mips lib/csu/sparc64 share/mk
Author: andrew
Date: Wed Nov 7 09:49:25 2018
New Revision: 340213
URL: https://svnweb.freebsd.org/changeset/base/340213
Log:
Add the (untested) mips and sparc64 .init call sequences.
The BSD crtbegin/crtend code now builds on all architectures, however
further work is needed to check if it works correctly.
MFC with: r339738
Sponsored by: DARPA, AFRL
Modified:
head/lib/csu/mips/crt.h
head/lib/csu/sparc64/crt.h
head/share/mk/src.opts.mk
Modified: head/lib/csu/mips/crt.h
==
--- head/lib/csu/mips/crt.h Wed Nov 7 08:25:44 2018(r340212)
+++ head/lib/csu/mips/crt.h Wed Nov 7 09:49:25 2018(r340213)
@@ -27,5 +27,25 @@
#define_CRT_H_
#defineHAVE_CTORS
+#defineCTORS_CONSTRUCTORS
+#ifdef __mips_o32
+#defineINIT_CALL_SEQ(func)
\
+".set noreorder\n" \
+"bal 1f \n" \
+"nop \n" \
+"1:\n"
\
+".cpload $ra \n" \
+".set reorder \n" \
+"jal " __STRING(func)
+#else
+#defineINIT_CALL_SEQ(func)
\
+".set noreorder\n" \
+"bal 1f \n" \
+"nop \n" \
+"1:\n"
\
+".set reorder \n" \
+".cpsetup $ra, $v0, 1b \n" \
+"jal " __STRING(func)
+#endif
#endif
Modified: head/lib/csu/sparc64/crt.h
==
--- head/lib/csu/sparc64/crt.h Wed Nov 7 08:25:44 2018(r340212)
+++ head/lib/csu/sparc64/crt.h Wed Nov 7 09:49:25 2018(r340213)
@@ -27,5 +27,7 @@
#define_CRT_H_
#defineHAVE_CTORS
+#defineCTORS_CONSTRUCTORS
+#defineINIT_CALL_SEQ(func) "call " __STRING(func) "; nop"
#endif
Modified: head/share/mk/src.opts.mk
==
--- head/share/mk/src.opts.mk Wed Nov 7 08:25:44 2018(r340212)
+++ head/share/mk/src.opts.mk Wed Nov 7 09:49:25 2018(r340213)
@@ -193,6 +193,7 @@ __DEFAULT_YES_OPTIONS = \
ZONEINFO
__DEFAULT_NO_OPTIONS = \
+BSD_CRTBEGIN \
BSD_GREP \
CLANG_EXTRAS \
DTRACE_TESTS \
@@ -383,13 +384,6 @@ BROKEN_OPTIONS+=HYPERV
# NVME is only x86 and powerpc64
.if ${__T} != "amd64" && ${__T} != "i386" && ${__T} != "powerpc64"
BROKEN_OPTIONS+=NVME
-.endif
-
-.if ${__T} == "aarch64" || ${__T} == "amd64" || ${__T} == "i386" || \
-${__T} == "powerpc64"
-__DEFAULT_NO_OPTIONS+=BSD_CRTBEGIN
-.else
-BROKEN_OPTIONS+=BSD_CRTBEGIN
.endif
.include
___
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: r340215 - in head/stand: common i386/libi386
Author: tsoome
Date: Wed Nov 7 11:14:22 2018
New Revision: 340215
URL: https://svnweb.freebsd.org/changeset/base/340215
Log:
loader: always set media size from partition.
The disk access is validated by using partition table definitions, therefore
we have no need for if statements, just set the disk size.
Of course the partition table itself may be incorrect/inconsistent, but if
so, we are in trouble anyhow.
Differential Revision:https://reviews.freebsd.org/D17822
Modified:
head/stand/common/disk.c
head/stand/common/part.c
head/stand/i386/libi386/biosdisk.c
Modified: head/stand/common/disk.c
==
--- head/stand/common/disk.cWed Nov 7 09:55:31 2018(r340214)
+++ head/stand/common/disk.cWed Nov 7 11:14:22 2018(r340215)
@@ -265,9 +265,7 @@ disk_open(struct disk_devdesc *dev, uint64_t mediasize
rc = ENXIO;
goto out;
}
- if (mediasize > od->mediasize) {
- od->mediasize = mediasize;
- }
+ od->mediasize = mediasize;
if (ptable_gettype(od->table) == PTABLE_BSD &&
partition >= 0) {
Modified: head/stand/common/part.c
==
--- head/stand/common/part.cWed Nov 7 09:55:31 2018(r340214)
+++ head/stand/common/part.cWed Nov 7 11:14:22 2018(r340215)
@@ -323,8 +323,7 @@ ptable_gptread(struct ptable *table, void *dev, diskre
* Note, this is still not a foolproof way to get disk's size. For
* example, an image file can be truncated when copied to smaller media.
*/
- if (hdr.hdr_lba_alt + 1 > table->sectors)
- table->sectors = hdr.hdr_lba_alt + 1;
+ table->sectors = hdr.hdr_lba_alt + 1;
for (i = 0; i < size / hdr.hdr_entsz; i++) {
ent = (struct gpt_ent *)(tbl + i * hdr.hdr_entsz);
Modified: head/stand/i386/libi386/biosdisk.c
==
--- head/stand/i386/libi386/biosdisk.c Wed Nov 7 09:55:31 2018
(r340214)
+++ head/stand/i386/libi386/biosdisk.c Wed Nov 7 11:14:22 2018
(r340215)
@@ -439,6 +439,33 @@ bd_print(int verbose)
}
/*
+ * Read disk size from partition.
+ * This is needed to work around buggy BIOS systems returning
+ * wrong (truncated) disk media size.
+ * During bd_probe() we tested if the multiplication of bd_sectors
+ * would overflow so it should be safe to perform here.
+ */
+static uint64_t
+bd_disk_get_sectors(struct disk_devdesc *dev)
+{
+ struct disk_devdesc disk;
+ uint64_t size;
+
+ disk.dd.d_dev = dev->dd.d_dev;
+ disk.dd.d_unit = dev->dd.d_unit;
+ disk.d_slice = -1;
+ disk.d_partition = -1;
+ disk.d_offset = 0;
+
+ size = BD(dev).bd_sectors * BD(dev).bd_sectorsize;
+ if (disk_open(&disk, size, BD(dev).bd_sectorsize) == 0) {
+ (void) disk_ioctl(&disk, DIOCGMEDIASIZE, &size);
+ disk_close(&disk);
+ }
+ return (size / BD(dev).bd_sectorsize);
+}
+
+/*
* Attempt to open the disk described by (dev) for use by (f).
*
* Note that the philosophy here is "give them exactly what
@@ -452,9 +479,7 @@ static int
bd_open(struct open_file *f, ...)
{
struct disk_devdesc *dev;
- struct disk_devdesc disk;
va_list ap;
- uint64_t size;
int rc;
va_start(ap, f);
@@ -470,33 +495,12 @@ bd_open(struct open_file *f, ...)
if ((BD(dev).bd_flags & BD_NO_MEDIA) == BD_NO_MEDIA)
return (EIO);
}
- BD(dev).bd_open++;
if (BD(dev).bd_bcache == NULL)
BD(dev).bd_bcache = bcache_allocate();
- /*
-* Read disk size from partition.
-* This is needed to work around buggy BIOS systems returning
-* wrong (truncated) disk media size.
-* During bd_probe() we tested if the mulitplication of bd_sectors
-* would overflow so it should be safe to perform here.
-*/
- disk.dd.d_dev = dev->dd.d_dev;
- disk.dd.d_unit = dev->dd.d_unit;
- disk.d_slice = -1;
- disk.d_partition = -1;
- disk.d_offset = 0;
-
- if (disk_open(&disk, BD(dev).bd_sectors * BD(dev).bd_sectorsize,
- BD(dev).bd_sectorsize) == 0) {
-
- if (disk_ioctl(&disk, DIOCGMEDIASIZE, &size) == 0) {
- size /= BD(dev).bd_sectorsize;
- if (size > BD(dev).bd_sectors)
- BD(dev).bd_sectors = size;
- }
- disk_close(&disk);
- }
+ if (BD(dev).bd_open == 0)
+ BD(dev).bd_sectors = bd_disk_get_sectors(dev);
+ BD(dev).bd_open++;
rc = disk_open(dev, BD(dev).bd_sectors * BD(dev).bd_sectorsize,
BD(dev).bd_sectorsize);
___
svn commit: r340216 - head/tools/tools/syscall_timing
Author: trasz
Date: Wed Nov 7 11:46:12 2018
New Revision: 340216
URL: https://svnweb.freebsd.org/changeset/base/340216
Log:
Add benchmarks for lstat(2) and readlink(2).
MFC after:2 weeks
Sponsored by: DARPA, AFRL
Modified:
head/tools/tools/syscall_timing/syscall_timing.c
Modified: head/tools/tools/syscall_timing/syscall_timing.c
==
--- head/tools/tools/syscall_timing/syscall_timing.cWed Nov 7 11:14:22
2018(r340215)
+++ head/tools/tools/syscall_timing/syscall_timing.cWed Nov 7 11:46:12
2018(r340216)
@@ -335,6 +335,23 @@ test_getuid(uintmax_t num, uintmax_t int_arg __unused,
}
static uintmax_t
+test_lstat(uintmax_t num, uintmax_t int_arg __unused, const char *path)
+{
+ struct stat sb;
+ uintmax_t i;
+ int error;
+
+ benchmark_start();
+ BENCHMARK_FOREACH(i, num) {
+ error = lstat(path, &sb);
+ if (error != 0)
+ err(-1, "lstat");
+ }
+ benchmark_stop();
+ return (i);
+}
+
+static uintmax_t
test_memcpy(uintmax_t num, uintmax_t int_arg, const char *path __unused)
{
char buf[int_arg], buf2[int_arg];
@@ -824,6 +841,23 @@ test_socketpair_dgram(uintmax_t num, uintmax_t int_arg
}
static uintmax_t
+test_readlink(uintmax_t num, uintmax_t int_arg __unused, const char *path)
+{
+ char buf[PATH_MAX];
+ ssize_t rv;
+ uintmax_t i;
+
+ benchmark_start();
+ BENCHMARK_FOREACH(i, num) {
+ rv = readlink(path, buf, sizeof(buf));
+ if (rv < 0 && errno != EINVAL)
+ err(-1, "readlink");
+ }
+ benchmark_stop();
+ return (i);
+}
+
+static uintmax_t
test_vfork(uintmax_t num, uintmax_t int_arg __unused, const char *path
__unused)
{
pid_t pid;
@@ -904,6 +938,7 @@ static const struct test tests[] = {
{ "getresuid", test_getresuid, .t_flags = 0 },
{ "gettimeofday", test_gettimeofday, .t_flags = 0 },
{ "getuid", test_getuid, .t_flags = 0 },
+ { "lstat", test_lstat, .t_flags = FLAG_PATH },
{ "memcpy_1", test_memcpy, .t_flags = 0, .t_int = 1 },
{ "memcpy_10", test_memcpy, .t_flags = 0, .t_int = 10 },
{ "memcpy_100", test_memcpy, .t_flags = 0, .t_int = 100 },
@@ -962,6 +997,7 @@ static const struct test tests[] = {
{ "socketpair_dgram", test_socketpair_dgram, .t_flags = 0 },
{ "socket_tcp", test_socket_stream, .t_int = PF_INET },
{ "socket_udp", test_socket_dgram, .t_int = PF_INET },
+ { "readlink", test_readlink, .t_flags = FLAG_PATH },
{ "vfork", test_vfork, .t_flags = 0 },
{ "vfork_exec", test_vfork_exec, .t_flags = 0 },
};
___
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: r340218 - in head: libexec/rtld-elf sys/sys
Author: arichardson
Date: Wed Nov 7 15:04:41 2018
New Revision: 340218
URL: https://svnweb.freebsd.org/changeset/base/340218
Log:
Handle the DT_MIPS_RLD_MAP_REL dynamic tag in RTLD
This dynamic tag contains the location of the .rld_map section relative to
the location of the dynamic tag. For PIE MIPS binaries DT_MIPS_RLD_MAP can
not be used since it contains an absolute address. Without this change
GDB can not find the function program counters in other libraries and once
I apply this change I can successfully run info sharedlibraries again.
Reviewed By: kib
Differential Revision: https://reviews.freebsd.org/D17867
Modified:
head/libexec/rtld-elf/rtld.c
head/sys/sys/elf_common.h
Modified: head/libexec/rtld-elf/rtld.c
==
--- head/libexec/rtld-elf/rtld.cWed Nov 7 12:08:26 2018
(r340217)
+++ head/libexec/rtld-elf/rtld.cWed Nov 7 15:04:41 2018
(r340218)
@@ -1264,6 +1264,13 @@ digest_dynamic1(Obj_Entry *obj, int early, const Elf_D
*((Elf_Addr *)(dynp->d_un.d_ptr)) = (Elf_Addr) &r_debug;
break;
+ case DT_MIPS_RLD_MAP_REL:
+ // The MIPS_RLD_MAP_REL tag stores the offset to the .rld_map
+ // section relative to the address of the tag itself.
+ *((Elf_Addr *)(__DECONST(char*, dynp) + dynp->d_un.d_val)) =
+ (Elf_Addr) &r_debug;
+ break;
+
case DT_MIPS_PLTGOT:
obj->mips_pltgot = (Elf_Addr *)(obj->relocbase +
dynp->d_un.d_ptr);
Modified: head/sys/sys/elf_common.h
==
--- head/sys/sys/elf_common.h Wed Nov 7 12:08:26 2018(r340217)
+++ head/sys/sys/elf_common.h Wed Nov 7 15:04:41 2018(r340218)
@@ -707,6 +707,7 @@ typedef struct {
#defineDT_MIPS_PLTGOT 0x7032
#defineDT_MIPS_RLD_OBJ_UPDATE 0x7033
#defineDT_MIPS_RWPLT 0x7034
+#defineDT_MIPS_RLD_MAP_REL 0x7035
#defineDT_PPC_GOT 0x7000
#defineDT_PPC_TLSOPT 0x7001
___
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: r340187 - head/sys/geom
On Tue, 2018-11-06 at 16:17 -0800, Rodney W. Grimes wrote:
> >
> > Rodney, this was actually my original intention, however then I noticed in
> > the GEOM code there is at least one case when BIO_FLUSH request is being
> > generated internally with bio_offset == mediasize and bio_lenth == 0, so I
> > thought there might be some need to allow such requests through. But I'd
> > happily go with the stricter rule if it does no harm. I simply don't know
> > enough about the intended use and the logic behind zero-length transfers to
> > make that call.
> I am not sure enough on if mediasize is 0 based or not,
> if it is then the error case should be fixed, and the
> code you show below should also be fixed as it is
> technically making a request beyond the end of device.
>
> I am also murky on why we are even doing a 0 size
> operation and end of device, is that to validate
> we can access all the media? If so then this wrong
> code and wrong error return should be fixed as it
> is off by 1.
>
> >
> >
> > -Max
> >
> > int
> > g_io_flush(struct g_consumer *cp)
> > {
> > ...
> > bp = g_alloc_bio();
> > bp->bio_cmd = BIO_FLUSH;
> > ...
> > bp->bio_offset = cp->provider->mediasize;
> The above should have a - 1 on it.
>
Unless offset > mediasize is specifically a signal to downstream code
in some way about how the flush is to be performed.
Nearly identical code to create a BIO_FLUSH bio appears in ufs softdeps
and in zfs. Before starting to arbitrarily change code that has worked
since 2006, it might be a good idea to track down why these values are
set the way they are. Unfortunately, there is no clue in the commit
logs, but maybe the author (pjd@, cc'd) can englighten us.
-- Ian
___
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: r340187 - head/sys/geom
Li-Wen, thanks for pointing out. I will investigate in the next few hours and follow-up then. Perhaps I need to treat out-of-the bounds BIO_DELETE differently, which was the original issue at hand. -Max On Tue, Nov 6, 2018 at 9:51 PM Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > > Hi Maxim, > > > > There are 5 regression tests failing since this change: > > > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test/9184/testReport/ > > > > sys.geom.class.* > > > > Can you help check them? > > Maybe this should be backed out and looked at more closely? > > > -- > Rod Grimes > rgri...@freebsd.org > > ___ 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: r340187 - head/sys/geom
> On Tue, 2018-11-06 at 16:17 -0800, Rodney W. Grimes wrote:
> > >
> > > Rodney, this was actually my original intention, however then I noticed in
> > > the GEOM code there is at least one case when BIO_FLUSH request is being
> > > generated internally with bio_offset == mediasize and bio_lenth == 0, so I
> > > thought there might be some need to allow such requests through. But I'd
> > > happily go with the stricter rule if it does no harm. I simply don't know
> > > enough about the intended use and the logic behind zero-length transfers
> > > to
> > > make that call.
> > I am not sure enough on if mediasize is 0 based or not,
> > if it is then the error case should be fixed, and the
> > code you show below should also be fixed as it is
> > technically making a request beyond the end of device.
> >
> > I am also murky on why we are even doing a 0 size
> > operation and end of device, is that to validate
> > we can access all the media???If so then this wrong
> > code and wrong error return should be fixed as it
> > is off by 1.
> >
> > >
> > >
> > > -Max
> > >
> > > int
> > > g_io_flush(struct g_consumer *cp)
> > > {
> > > ...
> > > bp = g_alloc_bio();
> > > bp->bio_cmd = BIO_FLUSH;
> > > ...
> > > bp->bio_offset = cp->provider->mediasize;
> > The above should have a - 1 on it.
> >
>
> Unless offset > mediasize is specifically a signal to downstream code
> in some way about how the flush is to be performed.
Could very well be, should be documented some place though.
> Nearly identical code to create a BIO_FLUSH bio appears in ufs softdeps
> and in zfs. Before starting to arbitrarily change code that has worked
> since 2006, it might be a good idea to track down why these values are
> set the way they are. Unfortunately, there is no clue in the commit
> logs, but maybe the author (pjd@, cc'd) can englighten us.
I agree with that take on the situation, and it is why I asked
for a revert and investigation, rather than trying to solve
why we suddenly fail some regression tests.
--
Rod Grimes rgri...@freebsd.org
___
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: r340220 - head/sys/geom
Author: sobomax Date: Wed Nov 7 16:28:09 2018 New Revision: 340220 URL: https://svnweb.freebsd.org/changeset/base/340220 Log: Revert r340187, it breaks EOD (end-of-device) detection logic. Turns out, i/o into last_sector+N is handled differently for N==1 and N>1 cases to accomodate that, so some other approach would be needed to fix DIOCGDELETE ioctl(2). Modified: head/sys/geom/geom_io.c Modified: head/sys/geom/geom_io.c == --- head/sys/geom/geom_io.c Wed Nov 7 16:22:18 2018(r340219) +++ head/sys/geom/geom_io.c Wed Nov 7 16:28:09 2018(r340220) @@ -420,8 +420,6 @@ g_io_check(struct bio *bp) return (EIO); if (bp->bio_offset > pp->mediasize) return (EIO); - if (bp->bio_offset == pp->mediasize && bp->bio_length > 0) - return (EIO); /* Truncate requests to the end of providers media. */ excess = bp->bio_offset + bp->bio_length; ___ 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: r340187 - head/sys/geom
Reverted, sorry. Turns out that i/o into last_sector+1 is handled
differently. I'll probably have to use different strategy to properly fail
out-of-bound ioctl(DIOCGDELETE) or otherwise indicate its result to the
userland app. To my defense, this patch has been out for 3 weeks on
freebsd-geom, and I got 0 responses.
-Max
On Wed, Nov 7, 2018 at 8:06 AM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Tue, 2018-11-06 at 16:17 -0800, Rodney W. Grimes wrote:
> > > >
> > > > Rodney, this was actually my original intention, however then I
> noticed in
> > > > the GEOM code there is at least one case when BIO_FLUSH request is
> being
> > > > generated internally with bio_offset == mediasize and bio_lenth ==
> 0, so I
> > > > thought there might be some need to allow such requests through. But
> I'd
> > > > happily go with the stricter rule if it does no harm. I simply don't
> know
> > > > enough about the intended use and the logic behind zero-length
> transfers to
> > > > make that call.
> > > I am not sure enough on if mediasize is 0 based or not,
> > > if it is then the error case should be fixed, and the
> > > code you show below should also be fixed as it is
> > > technically making a request beyond the end of device.
> > >
> > > I am also murky on why we are even doing a 0 size
> > > operation and end of device, is that to validate
> > > we can access all the media???If so then this wrong
> > > code and wrong error return should be fixed as it
> > > is off by 1.
> > >
> > > >
> > > >
> > > > -Max
> > > >
> > > > int
> > > > g_io_flush(struct g_consumer *cp)
> > > > {
> > > > ...
> > > > bp = g_alloc_bio();
> > > > bp->bio_cmd = BIO_FLUSH;
> > > > ...
> > > > bp->bio_offset = cp->provider->mediasize;
> > > The above should have a - 1 on it.
> > >
> >
> > Unless offset > mediasize is specifically a signal to downstream code
> > in some way about how the flush is to be performed.
>
> Could very well be, should be documented some place though.
>
> > Nearly identical code to create a BIO_FLUSH bio appears in ufs softdeps
> > and in zfs. Before starting to arbitrarily change code that has worked
> > since 2006, it might be a good idea to track down why these values are
> > set the way they are. Unfortunately, there is no clue in the commit
> > logs, but maybe the author (pjd@, cc'd) can englighten us.
>
> I agree with that take on the situation, and it is why I asked
> for a revert and investigation, rather than trying to solve
> why we suddenly fail some regression tests.
>
> --
> Rod Grimes
> rgri...@freebsd.org
>
>
___
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: r340220 - head/sys/geom
[ Charset UTF-8 unsupported, converting... ] > Author: sobomax > Date: Wed Nov 7 16:28:09 2018 > New Revision: 340220 > URL: https://svnweb.freebsd.org/changeset/base/340220 > > Log: > Revert r340187, it breaks EOD (end-of-device) detection logic. Turns out, > i/o into last_sector+N is handled differently for N==1 and N>1 cases to > accomodate that, so some other approach would be needed to fix DIOCGDELETE > ioctl(2). > > Modified: > head/sys/geom/geom_io.c > > Modified: head/sys/geom/geom_io.c > == > --- head/sys/geom/geom_io.c Wed Nov 7 16:22:18 2018(r340219) > +++ head/sys/geom/geom_io.c Wed Nov 7 16:28:09 2018(r340220) > @@ -420,8 +420,6 @@ g_io_check(struct bio *bp) > return (EIO); > if (bp->bio_offset > pp->mediasize) > return (EIO); > - if (bp->bio_offset == pp->mediasize && bp->bio_length > 0) > - return (EIO); > > /* Truncate requests to the end of providers media. */ > excess = bp->bio_offset + bp->bio_length; Thanks, I think this is the best thing to do while investigation goes on. -- Rod Grimes rgri...@freebsd.org ___ 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: r340221 - in head/sys: compat/freebsd32 kern
Author: brooks
Date: Wed Nov 7 16:55:04 2018
New Revision: 340221
URL: https://svnweb.freebsd.org/changeset/base/340221
Log:
makesyscalls.sh: allow pointer return types.
The previous code required that the return type be a single word. This
allows it to be a pointer without using a typedef.
Update the return types of break, mmap, and shmat to be void * as
declared. This only effects systrace output in-tree, but can aid in
generating system call wrappers from syscalls.master.
Reviewed by: kib
Obtained from:CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision:https://reviews.freebsd.org/D17873
Modified:
head/sys/compat/freebsd32/syscalls.master
head/sys/kern/makesyscalls.sh
head/sys/kern/syscalls.master
Modified: head/sys/compat/freebsd32/syscalls.master
==
--- head/sys/compat/freebsd32/syscalls.master Wed Nov 7 16:28:09 2018
(r340220)
+++ head/sys/compat/freebsd32/syscalls.master Wed Nov 7 16:55:04 2018
(r340221)
@@ -88,7 +88,7 @@
int mode, int dev); }
15 AUE_CHMOD NOPROTO { int chmod(const char *path, mode_t mode); }
16 AUE_CHOWN NOPROTO { int chown(const char *path, int uid, int
gid); }
-17 AUE_NULLNOPROTO { caddr_t break(char *nsize); }
+17 AUE_NULLNOPROTO { void *break(char *nsize); }
18 AUE_GETFSSTAT COMPAT4 { int freebsd32_getfsstat( \
struct statfs32 *buf, long bufsize, \
int mode); }
@@ -175,7 +175,7 @@
68 AUE_NULLOBSOL vwrite
69 AUE_SBRKNOPROTO { int sbrk(int incr); }
70 AUE_SSTKNOPROTO { int sstk(int incr); }
-71 AUE_MMAPCOMPAT|NOPROTO { int mmap(void *addr, int len, \
+71 AUE_MMAPCOMPAT|NOPROTO { void *mmap(void *addr, int len, \
int prot, int flags, int fd, int pos); }
72 AUE_O_VADVISE COMPAT11|NOPROTO{ int vadvise(int anom); }
73 AUE_MUNMAP NOPROTO { int munmap(void *addr, size_t len); }
@@ -373,7 +373,7 @@
__setrlimit_args int
196AUE_GETDIRENTRIES COMPAT11 { int freebsd32_getdirentries(int fd, \
char *buf, u_int count, int32_t *basep); }
-197AUE_MMAPCOMPAT6 { caddr_t freebsd32_mmap(void *addr, \
+197AUE_MMAPCOMPAT6 { void *freebsd32_mmap(void *addr, \
size_t len, int prot, int flags, int fd, \
int pad, uint32_t pos1, uint32_t pos2); }
198AUE_NULLNOPROTO { int nosys(void); } __syscall \
@@ -432,7 +432,7 @@
size_t msgsz, int msgflg); }
227AUE_MSGRCV NOSTD { int freebsd32_msgrcv(int msqid, void *msgp, \
size_t msgsz, long msgtyp, int msgflg); }
-228AUE_SHMAT NOSTD|NOPROTO { int shmat(int shmid, void *shmaddr, \
+228AUE_SHMAT NOSTD|NOPROTO { void *shmat(int shmid, void *shmaddr,
\
int shmflg); }
229AUE_SHMCTL COMPAT7|NOSTD { int freebsd32_shmctl( \
int shmid, int cmd, \
@@ -876,7 +876,7 @@
const void *buf, size_t nbyte, \
int pad, \
uint32_t offset1, uint32_t offset2); }
-477AUE_MMAPSTD { caddr_t freebsd32_mmap(void *addr, \
+477AUE_MMAPSTD { void *freebsd32_mmap(void *addr, \
size_t len, int prot, int flags, int fd, \
int pad, \
uint32_t pos1, uint32_t pos2); }
@@ -897,7 +897,7 @@
476AUE_PWRITE STD { ssize_t freebsd32_pwrite(int fd, \
const void *buf, size_t nbyte, \
uint32_t offset1, uint32_t offset2); }
-477AUE_MMAPSTD { caddr_t freebsd32_mmap(void *addr, \
+477AUE_MMAPSTD { void *freebsd32_mmap(void *addr, \
size_t len, int prot, int flags, int fd, \
uint32_t pos1, uint32_t pos2); }
478AUE_LSEEK STD { off_t freebsd32_lseek(int fd, \
Modified: head/sys/kern/makesyscalls.sh
==
--- head/sys/kern/makesyscalls.sh Wed Nov 7 16:28:09 2018
(r340220)
+++ head/sys/kern/makesyscalls.sh Wed Nov 7 16:55:04 2018
(r340221)
@@ -325,6 +325,7 @@ sed -e '
}
function parseline() {
f=4 # toss number, type, audit event
+ ret_inc = 0
argc= 0;
argssize =
svn commit: r340222 - in head/sys: compat/freebsd32 kern
Author: brooks Date: Wed Nov 7 16:56:07 2018 New Revision: 340222 URL: https://svnweb.freebsd.org/changeset/base/340222 Log: Regen after r340221: allow pointer return types. Sponsored by: DARPA, AFRL Differential Revision:https://reviews.freebsd.org/D17873 Modified: head/sys/compat/freebsd32/freebsd32_systrace_args.c head/sys/kern/systrace_args.c Modified: head/sys/compat/freebsd32/freebsd32_systrace_args.c == --- head/sys/compat/freebsd32/freebsd32_systrace_args.c Wed Nov 7 16:55:04 2018(r340221) +++ head/sys/compat/freebsd32/freebsd32_systrace_args.c Wed Nov 7 16:56:07 2018(r340222) @@ -8839,7 +8839,7 @@ systrace_return_setargdesc(int sysnum, int ndx, char * /* break */ case 17: if (ndx == 0 || ndx == 1) - p = "caddr_t"; + p = "void *"; break; /* getpid */ case 20: @@ -9388,7 +9388,7 @@ systrace_return_setargdesc(int sysnum, int ndx, char * /* shmat */ case 228: if (ndx == 0 || ndx == 1) - p = "int"; + p = "void *"; break; /* shmdt */ case 230: @@ -10139,7 +10139,7 @@ systrace_return_setargdesc(int sysnum, int ndx, char * /* freebsd32_mmap */ case 477: if (ndx == 0 || ndx == 1) - p = "caddr_t"; + p = "void *"; break; /* freebsd32_lseek */ case 478: @@ -10170,7 +10170,7 @@ systrace_return_setargdesc(int sysnum, int ndx, char * /* freebsd32_mmap */ case 477: if (ndx == 0 || ndx == 1) - p = "caddr_t"; + p = "void *"; break; /* freebsd32_lseek */ case 478: Modified: head/sys/kern/systrace_args.c == --- head/sys/kern/systrace_args.c Wed Nov 7 16:55:04 2018 (r340221) +++ head/sys/kern/systrace_args.c Wed Nov 7 16:56:07 2018 (r340222) @@ -8788,7 +8788,7 @@ systrace_return_setargdesc(int sysnum, int ndx, char * /* break */ case 17: if (ndx == 0 || ndx == 1) - p = "caddr_t"; + p = "void *"; break; /* getpid */ case 20: @@ -9357,7 +9357,7 @@ systrace_return_setargdesc(int sysnum, int ndx, char * /* shmat */ case 228: if (ndx == 0 || ndx == 1) - p = "int"; + p = "void *"; break; /* shmdt */ case 230: @@ -10187,7 +10187,7 @@ systrace_return_setargdesc(int sysnum, int ndx, char * /* mmap */ case 477: if (ndx == 0 || ndx == 1) - p = "caddr_t"; + p = "void *"; break; /* lseek */ case 478: ___ 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: r340223 - head/share/man/man8
Author: 0mp (ports committer)
Date: Wed Nov 7 16:56:32 2018
New Revision: 340223
URL: https://svnweb.freebsd.org/changeset/base/340223
Log:
rc.subr(8): Document when required_* variables are processed
At the moment rc.subr(8) supports the following required_* variables:
required_dirs, required_files, required_modules and required_vars.
This patch documents when every of those required_* variables is actually
processed (before or after running start_precmd).
Reviewed by: bcr
Approved by: krion (mentor, implicit), mat (mentor, implicit)
Sponsored by: Bally Wulff Games & Entertainment GmbH
Differential Revision:https://reviews.freebsd.org/D17895
Modified:
head/share/man/man8/rc.subr.8
Modified: head/share/man/man8/rc.subr.8
==
--- head/share/man/man8/rc.subr.8 Wed Nov 7 16:56:07 2018
(r340222)
+++ head/share/man/man8/rc.subr.8 Wed Nov 7 16:56:32 2018
(r340223)
@@ -29,7 +29,7 @@
.\"
.\" $FreeBSD$
.\"
-.Dd June 19, 2018
+.Dd November 7, 2018
.Dt RC.SUBR 8
.Os
.Sh NAME
@@ -491,16 +491,22 @@ Check for the existence of the listed directories
before running the
.Cm start
method.
+The list is checked before running
+.Va start_precmd .
.It Va required_files
Check for the readability of the listed files
before running the
.Cm start
method.
+The list is checked before running
+.Va start_precmd .
.It Va required_modules
Ensure that the listed kernel modules are loaded
before running the
.Cm start
method.
+The list is checked after running
+.Va start_precmd .
This is done after invoking the commands from
.Va start_precmd
so that the missing modules are not loaded in vain
@@ -531,6 +537,8 @@ on each of the list variables
before running the
.Cm start
method.
+The list is checked after running
+.Va start_precmd .
.It Va ${name}_chdir
Directory to
.Ic cd
___
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: r340187 - head/sys/geom
> Reverted, sorry. Turns out that i/o into last_sector+1 is handled
> differently. I'll probably have to use different strategy to properly fail
> out-of-bound ioctl(DIOCGDELETE) or otherwise indicate its result to the
> userland app. To my defense, this patch has been out for 3 weeks on
> freebsd-geom, and I got 0 responses.
Well you have some now, so lets try to sort this out and at least
document what the funny "access one byte past end with zero size
I/O" is about.
A good stratergy when you get no response on a phabricator review
is to poke about it on @current or @arch requesting feedback.
The phabricator notificaiton to potential reviewers is very low.
freebsd-geom is also probably a pretty short list.
> -Max
>
> On Wed, Nov 7, 2018 at 8:06 AM Rodney W. Grimes <
> free...@pdx.rh.cn85.dnsmgr.net> wrote:
>
> > > On Tue, 2018-11-06 at 16:17 -0800, Rodney W. Grimes wrote:
> > > > >
> > > > > Rodney, this was actually my original intention, however then I
> > noticed in
> > > > > the GEOM code there is at least one case when BIO_FLUSH request is
> > being
> > > > > generated internally with bio_offset == mediasize and bio_lenth ==
> > 0, so I
> > > > > thought there might be some need to allow such requests through. But
> > I'd
> > > > > happily go with the stricter rule if it does no harm. I simply don't
> > know
> > > > > enough about the intended use and the logic behind zero-length
> > transfers to
> > > > > make that call.
> > > > I am not sure enough on if mediasize is 0 based or not,
> > > > if it is then the error case should be fixed, and the
> > > > code you show below should also be fixed as it is
> > > > technically making a request beyond the end of device.
> > > >
> > > > I am also murky on why we are even doing a 0 size
> > > > operation and end of device, is that to validate
> > > > we can access all the media???If so then this wrong
> > > > code and wrong error return should be fixed as it
> > > > is off by 1.
> > > >
> > > > >
> > > > >
> > > > > -Max
> > > > >
> > > > > int
> > > > > g_io_flush(struct g_consumer *cp)
> > > > > {
> > > > > ...
> > > > > bp = g_alloc_bio();
> > > > > bp->bio_cmd = BIO_FLUSH;
> > > > > ...
> > > > > bp->bio_offset = cp->provider->mediasize;
> > > > The above should have a - 1 on it.
> > > >
> > >
> > > Unless offset > mediasize is specifically a signal to downstream code
> > > in some way about how the flush is to be performed.
> >
> > Could very well be, should be documented some place though.
> >
> > > Nearly identical code to create a BIO_FLUSH bio appears in ufs softdeps
> > > and in zfs. Before starting to arbitrarily change code that has worked
> > > since 2006, it might be a good idea to track down why these values are
> > > set the way they are. Unfortunately, there is no clue in the commit
> > > logs, but maybe the author (pjd@, cc'd) can englighten us.
> >
> > I agree with that take on the situation, and it is why I asked
> > for a revert and investigation, rather than trying to solve
> > why we suddenly fail some regression tests.
> >
> > --
> > Rod Grimes
> > rgri...@freebsd.org
> >
> >
--
Rod Grimes rgri...@freebsd.org
___
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: r340228 - head/sys/riscv/riscv
Author: jhb
Date: Wed Nov 7 18:27:43 2018
New Revision: 340228
URL: https://svnweb.freebsd.org/changeset/base/340228
Log:
Enable use of a global shared page for RISC-V.
machine/vmparam.h already defines the SHAREDPAGE constant. This
change just enables it for ELF executables. The only use of the
shared page currently is to hold the signal trampoline.
Reviewed by: markj, kib
Sponsored by: DARPA
Differential Revision:https://reviews.freebsd.org/D17875
Modified:
head/sys/riscv/riscv/elf_machdep.c
Modified: head/sys/riscv/riscv/elf_machdep.c
==
--- head/sys/riscv/riscv/elf_machdep.c Wed Nov 7 18:12:18 2018
(r340227)
+++ head/sys/riscv/riscv/elf_machdep.c Wed Nov 7 18:27:43 2018
(r340228)
@@ -83,10 +83,12 @@ struct sysentvec elf64_freebsd_sysvec = {
.sv_setregs = exec_setregs,
.sv_fixlimit= NULL,
.sv_maxssiz = NULL,
- .sv_flags = SV_ABI_FREEBSD | SV_LP64,
+ .sv_flags = SV_ABI_FREEBSD | SV_LP64 | SV_SHP,
.sv_set_syscall_retval = cpu_set_syscall_retval,
.sv_fetch_syscall_args = cpu_fetch_syscall_args,
.sv_syscallnames = syscallnames,
+ .sv_shared_page_base = SHAREDPAGE,
+ .sv_shared_page_len = PAGE_SIZE,
.sv_schedtail = NULL,
.sv_thread_detach = NULL,
.sv_trap= NULL,
___
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: r340229 - in head/sys: arm64/arm64 riscv/riscv
Author: jhb
Date: Wed Nov 7 18:28:55 2018
New Revision: 340229
URL: https://svnweb.freebsd.org/changeset/base/340229
Log:
Drop the legacy ELF brandinfo for the old rtld from arm64 and riscv.
These architectures never shipped binaries with an rtld path of
/usr/libexec/ld-elf.so.1.
Reviewed by: markj
Sponsored by: DARPA
Differential Revision:https://reviews.freebsd.org/D17876
Modified:
head/sys/arm64/arm64/elf_machdep.c
head/sys/riscv/riscv/elf_machdep.c
Modified: head/sys/arm64/arm64/elf_machdep.c
==
--- head/sys/arm64/arm64/elf_machdep.c Wed Nov 7 18:27:43 2018
(r340228)
+++ head/sys/arm64/arm64/elf_machdep.c Wed Nov 7 18:28:55 2018
(r340229)
@@ -107,21 +107,6 @@ static Elf64_Brandinfo freebsd_brand_info = {
SYSINIT(elf64, SI_SUB_EXEC, SI_ORDER_FIRST,
(sysinit_cfunc_t)elf64_insert_brand_entry, &freebsd_brand_info);
-static Elf64_Brandinfo freebsd_brand_oinfo = {
- .brand = ELFOSABI_FREEBSD,
- .machine= EM_AARCH64,
- .compat_3_brand = "FreeBSD",
- .emul_path = NULL,
- .interp_path= "/usr/libexec/ld-elf.so.1",
- .sysvec = &elf64_freebsd_sysvec,
- .interp_newpath = NULL,
- .brand_note = &elf64_freebsd_brandnote,
- .flags = BI_CAN_EXEC_DYN | BI_BRAND_NOTE
-};
-
-SYSINIT(oelf64, SI_SUB_EXEC, SI_ORDER_ANY,
-(sysinit_cfunc_t)elf64_insert_brand_entry, &freebsd_brand_oinfo);
-
void
elf64_dump_thread(struct thread *td __unused, void *dst __unused,
size_t *off __unused)
Modified: head/sys/riscv/riscv/elf_machdep.c
==
--- head/sys/riscv/riscv/elf_machdep.c Wed Nov 7 18:27:43 2018
(r340228)
+++ head/sys/riscv/riscv/elf_machdep.c Wed Nov 7 18:28:55 2018
(r340229)
@@ -111,22 +111,6 @@ SYSINIT(elf64, SI_SUB_EXEC, SI_ORDER_FIRST,
(sysinit_cfunc_t) elf64_insert_brand_entry,
&freebsd_brand_info);
-static Elf64_Brandinfo freebsd_brand_oinfo = {
- .brand = ELFOSABI_FREEBSD,
- .machine= EM_RISCV,
- .compat_3_brand = "FreeBSD",
- .emul_path = NULL,
- .interp_path= "/usr/libexec/ld-elf.so.1",
- .sysvec = &elf64_freebsd_sysvec,
- .interp_newpath = NULL,
- .brand_note = &elf64_freebsd_brandnote,
- .flags = BI_CAN_EXEC_DYN | BI_BRAND_NOTE
-};
-
-SYSINIT(oelf64, SI_SUB_EXEC, SI_ORDER_ANY,
- (sysinit_cfunc_t) elf64_insert_brand_entry,
- &freebsd_brand_oinfo);
-
static int debug_kld;
SYSCTL_INT(_kern, OID_AUTO, debug_kld,
CTLFLAG_RW, &debug_kld, 0,
___
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: r340231 - head/sys/kern
Author: jhb Date: Wed Nov 7 18:32:02 2018 New Revision: 340231 URL: https://svnweb.freebsd.org/changeset/base/340231 Log: Enable non-executable stacks by default on RISC-V. Reviewed by: markj Sponsored by: DARPA Differential Revision:https://reviews.freebsd.org/D17878 Modified: head/sys/kern/imgact_elf.c Modified: head/sys/kern/imgact_elf.c == --- head/sys/kern/imgact_elf.c Wed Nov 7 18:29:54 2018(r340230) +++ head/sys/kern/imgact_elf.c Wed Nov 7 18:32:02 2018(r340231) @@ -120,7 +120,8 @@ SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), int __elfN(nxstack) = #if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ || \ -(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) +(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) || \ +defined(__riscv) 1; #else 0; ___ 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: r340236 - head/sys/net
Author: shurd
Date: Wed Nov 7 19:31:48 2018
New Revision: 340236
URL: https://svnweb.freebsd.org/changeset/base/340236
Log:
Fix rxcsum issue introduced in r338838
r338838 attempted to fix issues with rxcsum and rxcsum6.
However, the rxcsum bits were set as though if_setcapenablebit() was
being called, not if_togglecapenable() which is in use. As a result,
it was not possible to disable rxcsum when rxcsum6 was supported.
PR: 233004
Reported by: lev
Reviewed by: lev
MFC after:3 days
Sponsored by: Limelight Networks
Differential Revision:https://reviews.freebsd.org/D17881
Modified:
head/sys/net/iflib.c
Modified: head/sys/net/iflib.c
==
--- head/sys/net/iflib.cWed Nov 7 18:54:24 2018(r340235)
+++ head/sys/net/iflib.cWed Nov 7 19:31:48 2018(r340236)
@@ -4256,18 +4256,13 @@ iflib_if_ioctl(if_t ifp, u_long command, caddr_t data)
setmask |= (mask & IFCAP_WOL);
/*
-* If we're disabling any RX csum, disable all the ones
-* the driver supports. This assumes all supported are
-* enabled.
-*
-* Otherwise, if they've changed, enable all of them.
+* If any RX csum has changed, change all the ones that
+* are supported by the driver.
*/
- if ((setmask & (IFCAP_RXCSUM | IFCAP_RXCSUM_IPV6)) <
- (oldmask & (IFCAP_RXCSUM | IFCAP_RXCSUM_IPV6)))
- setmask &= ~(IFCAP_RXCSUM | IFCAP_RXCSUM_IPV6);
- else if ((setmask & (IFCAP_RXCSUM | IFCAP_RXCSUM_IPV6)) !=
- (oldmask & (IFCAP_RXCSUM | IFCAP_RXCSUM_IPV6)))
- setmask |= (mask & (IFCAP_RXCSUM | IFCAP_RXCSUM_IPV6));
+ if (setmask & (IFCAP_RXCSUM | IFCAP_RXCSUM_IPV6)) {
+ setmask |= ctx->ifc_softc_ctx.isc_capabilities &
+ (IFCAP_RXCSUM | IFCAP_RXCSUM_IPV6);
+ }
/*
* want to ensure that traffic has stopped before we change any
of the flags
___
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: r340187 - head/sys/geom
On Wed, Nov 7, 2018 at 9:07 AM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Tue, 2018-11-06 at 16:17 -0800, Rodney W. Grimes wrote:
> > > >
> > > > Rodney, this was actually my original intention, however then I
> noticed in
> > > > the GEOM code there is at least one case when BIO_FLUSH request is
> being
> > > > generated internally with bio_offset == mediasize and bio_lenth ==
> 0, so I
> > > > thought there might be some need to allow such requests through. But
> I'd
> > > > happily go with the stricter rule if it does no harm. I simply don't
> know
> > > > enough about the intended use and the logic behind zero-length
> transfers to
> > > > make that call.
> > > I am not sure enough on if mediasize is 0 based or not,
> > > if it is then the error case should be fixed, and the
> > > code you show below should also be fixed as it is
> > > technically making a request beyond the end of device.
> > >
> > > I am also murky on why we are even doing a 0 size
> > > operation and end of device, is that to validate
> > > we can access all the media???If so then this wrong
> > > code and wrong error return should be fixed as it
> > > is off by 1.
> > >
> > > >
> > > >
> > > > -Max
> > > >
> > > > int
> > > > g_io_flush(struct g_consumer *cp)
> > > > {
> > > > ...
> > > > bp = g_alloc_bio();
> > > > bp->bio_cmd = BIO_FLUSH;
> > > > ...
> > > > bp->bio_offset = cp->provider->mediasize;
> > > The above should have a - 1 on it.
> > >
> >
> > Unless offset > mediasize is specifically a signal to downstream code
> > in some way about how the flush is to be performed.
>
> Could very well be, should be documented some place though.
>
> > Nearly identical code to create a BIO_FLUSH bio appears in ufs softdeps
> > and in zfs. Before starting to arbitrarily change code that has worked
> > since 2006, it might be a good idea to track down why these values are
> > set the way they are. Unfortunately, there is no clue in the commit
> > logs, but maybe the author (pjd@, cc'd) can englighten us.
>
> I agree with that take on the situation, and it is why I asked
> for a revert and investigation, rather than trying to solve
> why we suddenly fail some regression tests.
>
BIO_FLUSH is primarily done to force ordering points, since they are one of
the only users of BIO_ORDERED in the system (the other is one place in UFS
that shouldn't be doing BIO_ORDERED in theory, but in practice it's hard to
fix. The exact values of the request don't really matter for the most part,
though flushing past the end is seems ill defined. There's no way we'd
force out blocks past the end. NVME, SCSI and ATA all implement BIO_FLUSH
as either a NOP, or as simple command to flush all caches to stable media.
Other drivers that I looked at appear to do something similar, though I've
not looked at every single one of them in detail.
Warner
___
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
[I trace code associated with bl <1322.plt_call.getenv> in the two contexts and extend the range over which things appear to match: up to some point after the branch b <__glink_PLTresolve> .] On 2018-Nov-6, at 19:12, Mark Millard wrote: > [I've present a little information about the longer-existing > failure's odd backtrace for /libexec/ld-elf.so.1 /bin/ls > --but on powerpc64 FreeBSD instead of 32-bit powerpc FreeBSD.] > > On 2018-Nov-2, at 11:50, Konstantin Belousov wrote: > >> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote: >>> On 2018-Nov-2, at 8:52 AM, Konstantin Belousov >>> wrote: >>> . . . >>> >>> That seems better. But it crashes during /bin/ls execution >>> ( 0x0180 addresses ), apparently in a library routine >>> ( 0x41?? addresses ): >>> >>> Program received signal SIGSEGV, Segmentation fault. >>> 0x411220b4 in ?? () >>> (gdb) bt >>> #0 0x411220b4 in ?? () >>> #1 0x4112200c in ?? () >>> #2 0x01803c84 in ?? () >>> #3 0x018023b4 in ?? () >>> #4 0x010121a0 in .rtld_start () at >>> /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 >>> >>> Using a normal gdb run of /bin/ls suggests: >>> >>> #2 0x01803c84 in ?? () should be in main and seems to be: bl 0x1818914 >>> >>> #3 0x018023b4 in ?? () should be in _start >>> >>> Looking in the test context: >>> >>> 0x1803c80: bl 0x1818914 >>> 0x1803c84: cmpwi cr7,r3,-1 >>> >>> and: >>> >>> 0x1818914: li r11,59 >>> 0x1818918: b 0x18186f4 >>> >>> and: >>> >>> 0x18186f4: rlwinm r11,r11,2,0,29 >>> 0x18186f8: addis r11,r11,386 >>> 0x18186fc: lwz r11,-30316(r11) >>> 0x1818700: mtctr r11 >>> 0x1818704: bctr >>> >>> Breaking at the bctr and using info reg: >>> >>> r110x4125ffa0 1093009312 >>> >>> It looks like there is some amount of >>> activity before the traceback addresses >>> show up. >>> >>> I've not found a good way to fill in the "in ??()" >>> (or analogous) information. The addresses 0x411220?? >>> do not match up with a normal run of /bin/ls from >>> gdb: the addresses can not be accessed. >>> >>> >>> >>> It does appear that the code is in /lib/libc.so.7 in the >>> test context: >>> >>> Breakpoint 2, reloc_non_plt (obj=0x41041600, obj_rtld=0x41104b57, flags=4, >>> lockstate=0x0) at /usr/src/libexec/rtld-elf/powerpc/reloc.c:338 >>> . . . >>> >> 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. > > I've got a little more information about the odd backtrace > from the /libexec/ld-elf.so.1 /bin/ls failure that the > prior patch allowed getting to, although for a powerpc64 > example context. > > The information is only identifying where the code was > in /bin/ls and /lib/libc.so.1 in the backtrace. For > libc.so.1 I found the same code sequences in a gdb of > /bin/ls directly, matching one first, using the addresses > vs. in the /libexec/ld-elf.so.1 /bin/ls process to > find offsets for going back and forth, and then used > that two find the 2nd backtrace addresses material. > > Overall it suggests to me that (in somewhat > symbolic terms): > > bl <1322.plt_call.getenv> > > eventually lead to executing the wrong code. > > > The supporting detail is as follows. > > The /libexec/ld-elf.so.1 part of the backtrace was > easy to find where the code was: > > (gdb) run /bin/ls > Starting program: /libexec/ld-elf.so.1 /bin/ls > > Program received signal SIGSEGV, Segmentation fault. > 0x00080118d81c in ?? () > (gdb) bt > #0 0x00080118d81c in ?? () > #1 0x00080118d920 in ?? () > #2 0x10002558 in ?? () > #3 0x100037b0 in ?? () > #4 0x01018450 in ._rtld_start () at > /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 > Backtrace stopped: frame did not save the PC > > (gdb) > 101 ld %r7,128(%r1)/* exit proc */ > 102 ld %r8,136(%r1)/* ps_strings */ > 103 > 104 blrl/* _start(argc, argv, envp, obj, cleanup, ps_strings) */ > 105 > 106 li %r0,1 /* _exit() */ > 107 sc > > > The /bin/ls part of the backtrace was easy to find > were the code was: > > (gdb) symbol-file /bin/ls > Load new symbol table from "/bin/ls"? (y or n) y > Reading symbols from /bin/ls...Reading symbols from > /usr/lib/debug//bin/ls.debug...done. > done. > (gdb) bt > #0 0x00080118d81c in ?? () > #1 0x00080118d920 in ?? () > #2 0x10002558 in main (argc=, argv=0x80134bdb0) at > /usr/src/bin/ls/ls.c:268 > #3 0x100037b0 in _start (argc=, > argv=0x3fffdb70, env=0x3fffdb88, obj=, > cleanup=, ps_strings=) >at /usr/s
Re: svn commit: r340187 - head/sys/geom
In message , Warner Losh writes: >BIO_FLUSH is primarily done to force ordering points, Originally BIO_FLUSH was defined the way it is, to make it possible to flush an isolated specified range on providers which support that so that fsync(2) could be implemented that way. I can't remember the exact semantics of the two "magic" flush operations (off=0,len=0) and (off=end,len=0) but they were different from each other in some important aspect (Pawel?) -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: r340187 - head/sys/geom
On Wed, Nov 7, 2018 at 1:20 PM Poul-Henning Kamp wrote: > > In message < > canczdfrk-7vbetkhfq9kkm4usrvjvh8ws_ozjidmh5336dt...@mail.gmail.com> > , Warner Losh writes: > > >BIO_FLUSH is primarily done to force ordering points, > > Originally BIO_FLUSH was defined the way it is, to make it possible > to flush an isolated specified range on providers which support that > so that fsync(2) could be implemented that way. > > I can't remember the exact semantics of the two "magic" flush > operations (off=0,len=0) and (off=end,len=0) but they were different > from each other in some important aspect (Pawel?) > I couldn't find any place where the different types of flush are differentiated (nothing in CAM for sure), though I suppose I could have missed something. All the CAM drivers just use it to push data to the device and don't look at the flags. Warner ___ 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: r340238 - head/sys/conf
Author: emaste
Date: Wed Nov 7 20:36:57 2018
New Revision: 340238
URL: https://svnweb.freebsd.org/changeset/base/340238
Log:
newvers.sh: avoid regenerating vers.c if content unchanged
When reproducible build mode is enabled vers.c may be unchanged between
successive builds. In this case avoid changing the file's metadata so
that it does not cause dependent targets to be rebuilt.
Sponsored by: The FreeBSD Foundation
Reviewed by: imp
Differential Revision:https://reviews.freebsd.org/D17892
Modified:
head/sys/conf/newvers.sh
Modified: head/sys/conf/newvers.sh
==
--- head/sys/conf/newvers.shWed Nov 7 20:31:36 2018(r340237)
+++ head/sys/conf/newvers.shWed Nov 7 20:36:57 2018(r340238)
@@ -328,7 +328,7 @@ else
VERSTR="${VERINFO}\\n${u}@${h}:${d}\\n"
fi
-cat << EOF > vers.c
+vers_content_new=$(cat << EOF
$COPYRIGHT
#define SCCSSTR "@(#)${VERINFO}"
#define VERSTR "${VERSTR}"
@@ -342,5 +342,10 @@ char osrelease[sizeof(RELSTR) > 32 ? sizeof(RELSTR) :
int osreldate = ${RELDATE};
char kern_ident[] = "${i}";
EOF
+)
+vers_content_old=$(cat vers.c 2>/dev/null || true)
+if [ "$vers_content_new" != "$vers_content_old" ]; then
+ echo "$vers_content_new" > vers.c
+fi
echo $((v + 1)) > version
___
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: r340231 - head/sys/kern
Op wo 7 nov. 2018 om 19:32 schreef John Baldwin : > Modified: head/sys/kern/imgact_elf.c > == > --- head/sys/kern/imgact_elf.c Wed Nov 7 18:29:54 2018(r340230) > +++ head/sys/kern/imgact_elf.c Wed Nov 7 18:32:02 2018(r340231) > @@ -120,7 +120,8 @@ SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), > > int __elfN(nxstack) = > #if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ || > \ > -(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) > +(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) || \ > +defined(__riscv) > 1; > #else > 0; Are we getting to the point that it might make sense to invert this logic, i.e., just list the architectures that require executable stacks? -- Ed Schouten ___ 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: r340239 - head/usr.bin/bsdiff/bspatch
Author: oshogbo
Date: Wed Nov 7 21:01:14 2018
New Revision: 340239
URL: https://svnweb.freebsd.org/changeset/base/340239
Log:
bspatch: simplify capsicumization
Assume that user wants to run with capsicum support if he builds the software
with HAVE_CAPSICUM. Treat running application without capsicum in the kernel
as
an error.
MFC after:3 weeks
Modified:
head/usr.bin/bsdiff/bspatch/bspatch.c
Modified: head/usr.bin/bsdiff/bspatch/bspatch.c
==
--- head/usr.bin/bsdiff/bspatch/bspatch.c Wed Nov 7 20:36:57 2018
(r340238)
+++ head/usr.bin/bsdiff/bspatch/bspatch.c Wed Nov 7 21:01:14 2018
(r340239)
@@ -144,26 +144,22 @@ int main(int argc, char *argv[])
atexit(exit_cleanup);
#ifdef HAVE_CAPSICUM
- if (cap_enter() < 0) {
- /* Failed to sandbox, fatal if CAPABILITY_MODE enabled */
- if (errno != ENOSYS)
- err(1, "failed to enter security sandbox");
- } else {
- /* Capsicum Available */
- cap_rights_init(&rights_ro, CAP_READ, CAP_FSTAT, CAP_SEEK);
- cap_rights_init(&rights_wr, CAP_WRITE);
- cap_rights_init(&rights_dir, CAP_UNLINKAT);
+ if (cap_enter() < 0)
+ err(1, "failed to enter security sandbox");
- if (cap_rights_limit(fileno(f), &rights_ro) < 0 ||
- cap_rights_limit(fileno(cpf), &rights_ro) < 0 ||
- cap_rights_limit(fileno(dpf), &rights_ro) < 0 ||
- cap_rights_limit(fileno(epf), &rights_ro) < 0 ||
- cap_rights_limit(oldfd, &rights_ro) < 0 ||
- cap_rights_limit(newfd, &rights_wr) < 0 ||
- cap_rights_limit(dirfd, &rights_dir) < 0)
- err(1, "cap_rights_limit() failed, could not restrict"
- " capabilities");
- }
+ cap_rights_init(&rights_ro, CAP_READ, CAP_FSTAT, CAP_SEEK);
+ cap_rights_init(&rights_wr, CAP_WRITE);
+ cap_rights_init(&rights_dir, CAP_UNLINKAT);
+
+ if (cap_rights_limit(fileno(f), &rights_ro) < 0 ||
+ cap_rights_limit(fileno(cpf), &rights_ro) < 0 ||
+ cap_rights_limit(fileno(dpf), &rights_ro) < 0 ||
+ cap_rights_limit(fileno(epf), &rights_ro) < 0 ||
+ cap_rights_limit(oldfd, &rights_ro) < 0 ||
+ cap_rights_limit(newfd, &rights_wr) < 0 ||
+ cap_rights_limit(dirfd, &rights_dir) < 0)
+ err(1, "cap_rights_limit() failed, could not restrict"
+ " capabilities");
#endif
/*
___
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: r340231 - head/sys/kern
On 11/7/18 1:01 PM, Ed Schouten wrote: > Op wo 7 nov. 2018 om 19:32 schreef John Baldwin : >> Modified: head/sys/kern/imgact_elf.c >> == >> --- head/sys/kern/imgact_elf.c Wed Nov 7 18:29:54 2018(r340230) >> +++ head/sys/kern/imgact_elf.c Wed Nov 7 18:32:02 2018(r340231) >> @@ -120,7 +120,8 @@ SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), >> >> int __elfN(nxstack) = >> #if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ >> || \ >> -(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) >> +(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) || \ >> +defined(__riscv) >> 1; >> #else >> 0; > > Are we getting to the point that it might make sense to invert this > logic, i.e., just list the architectures that require executable > stacks? It's not clear. The remaining set is i386 (should be able to use nxstack when using PAE and PG_NX is supported), MIPS (no X permission in PTEs), 32-bit powerpc (no X permissions in PTEs AFAICT), and sparc64 (no X permissions in PTEs AFAICT). For architectures without X ptes, removing VM_PROT_EXECUTE from the stack permissions is a no-op and would be harmless, so we could perhaps just default this to always on at this point? -- John Baldwin ___ 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: r340240 - head/stand/common
Author: tsoome
Date: Wed Nov 7 21:36:52 2018
New Revision: 340240
URL: https://svnweb.freebsd.org/changeset/base/340240
Log:
loader: ptable_open() check for ptable_cd9660read result is wrong
The ptable_*read() functions return NULL on read errors (and partition table
closed as an side effect). The ptable_open must check the return value and
act properly.
PR: 232483
Reported by: lev
Reviewed by: lev,cem
Differential Revision:https://reviews.freebsd.org/D17890
Modified:
head/stand/common/part.c
Modified: head/stand/common/part.c
==
--- head/stand/common/part.cWed Nov 7 21:01:14 2018(r340239)
+++ head/stand/common/part.cWed Nov 7 21:36:52 2018(r340240)
@@ -675,10 +675,12 @@ ptable_open(void *dev, uint64_t sectors, uint16_t sect
table->type = PTABLE_NONE;
STAILQ_INIT(&table->entries);
- if (ptable_iso9660read(table, dev, dread) != NULL) {
- if (table->type == PTABLE_ISO9660)
- goto out;
- }
+ if (ptable_iso9660read(table, dev, dread) == NULL) {
+ /* Read error. */
+ table = NULL;
+ goto out;
+ } else if (table->type == PTABLE_ISO9660)
+ goto out;
#ifdef LOADER_VTOC8_SUPPORT
if (be16dec(buf + offsetof(struct vtoc8, magic)) == VTOC_MAGIC) {
___
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: r340231 - head/sys/kern
John Baldwin jhb at FreeBSD.org wrote on Wed Nov 7 21:36:02 UTC 2018 : > On 11/7/18 1:01 PM, Ed Schouten wrote: > > Op wo 7 nov. 2018 om 19:32 schreef John Baldwin : > >> Modified: head/sys/kern/imgact_elf.c > >> == > >> --- head/sys/kern/imgact_elf.c Wed Nov 7 18:29:54 2018(r340230) > >> +++ head/sys/kern/imgact_elf.c Wed Nov 7 18:32:02 2018(r340231) > >> @@ -120,7 +120,8 @@ SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), > >> > >> int __elfN(nxstack) = > >> #if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ > >> || \ > >> -(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) > >> +(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) || \ > >> +defined(__riscv) > >> 1; > >> #else > >> 0; > > > > Are we getting to the point that it might make sense to invert this > > logic, i.e., just list the architectures that require executable > > stacks? > > It's not clear. The remaining set is i386 (should be able to use nxstack > when using PAE and PG_NX is supported), MIPS (no X permission in PTEs), > 32-bit powerpc (no X permissions in PTEs AFAICT), and sparc64 (no X > permissions in PTEs AFAICT). For architectures without X ptes, removing > VM_PROT_EXECUTE from the stack permissions is a no-op and would be > harmless, so we could perhaps just default this to always on at this > point? FreeBSD for 32-bit powerpc can also run on powerpc64 hardware, something I commonly do with 32-bit powerpc FreeBSD. So I'm not sure if some of the powerpc64 context sometimes applies for such use or not. May be the mode of use is as-if it was limited like 32-bit powerpc hardware for what you propose? I do not now if i386 or mips have the same sort of question relative to use on 64-bit capable hardware. === 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: r339609 - in head/release: amd64 i386 powerpc sparc64
This fixes a build for us:
https://github.com/HardenedBSD/hardenedBSD/commit/c1a6f17c2a62ca9d1d0f4d788d8d832e9e909b6b
On Sunday, November 4, 2018, Oliver Pinter
wrote:
> On 10/22/18, Ed Maste wrote:
> > Author: emaste
> > Date: Mon Oct 22 19:39:20 2018
> > New Revision: 339609
> > URL: https://svnweb.freebsd.org/changeset/base/339609
> >
> > Log:
> > release: set -e to exit on error in iso image scripts
> >
> > Reviewed by:gjb
> > Differential Revision: https://reviews.freebsd.org/D17651
> >
> > Modified:
> > head/release/amd64/mkisoimages.sh
> > head/release/i386/mkisoimages.sh
> > head/release/powerpc/mkisoimages.sh
> > head/release/sparc64/mkisoimages.sh
> >
> > Modified: head/release/amd64/mkisoimages.sh
>
> This commit catches an warning / error in cd generation for amd64,
> with this error:
>
> >>> Installing everything completed on Mon Oct 22 18:07:00 UTC 2018
> --
> 1+0 records in
> 1+0 records out
> 4096 bytes transferred in 0.000197 secs (20757002 bytes/sec)
> 200+0 records in
> 200+0 records out
> 819200 bytes transferred in 0.020971 secs (39064121 bytes/sec)
> newfs_msdos: cannot get number of sectors per track: Operation not
> supported
> newfs_msdos: cannot get number of heads: Operation not supported
> newfs_msdos: trim 25 sectors to adjust to a multiple of 63
> /dev/md0: 1532 sectors in 1532 FAT12 clusters (512 bytes/cluster)
> BytesPerSec=512 SecPerClust=1 ResSectors=1 FATs=2 RootDirEnts=512
> Sectors=1575 Media=0xf8 FATsecs=5 SecPerTrack=63 Heads=1 HiddenSecs=0
> cp: chown: efi/efi/boot/bootx64.efi: Invalid argument
> 1+0 records in
> 1+0 records out
>
> The last working cd generation was before this commit:
> https://jenkins.hardenedbsd.org/jenkins/job/HardenedBSD-
> CURRENT-amd64/1361/console
>
> And after this commit it breaks on the above line:
> https://jenkins.hardenedbsd.org/jenkins/job/HardenedBSD-CURRENT-amd64/
>
> in ${SRCTOP}/release/amd64/mkisoimages.sh the -p option can't work
> when you copy to a FAT FS, so the easiest fix would be to remove the
> -p option from cp's line.
> Other problem with a script after the set -e changes, that if
> something fails, no one cleans up the created md devices.
>
>
> >
> ==
> > --- head/release/amd64/mkisoimages.sh Mon Oct 22 18:41:22 2018
> (r339608)
> > +++ head/release/amd64/mkisoimages.sh Mon Oct 22 19:39:20 2018
> (r339609)
> > @@ -23,6 +23,8 @@
> > # extra-bits-dir, if provided, contains additional files to be merged
> > # into base-bits-dir as part of making the image.
> >
> > +set -e
> > +
> > if [ -z $ETDUMP ]; then
> > ETDUMP=etdump
> > fi
> >
> > Modified: head/release/i386/mkisoimages.sh
> >
> ==
> > --- head/release/i386/mkisoimages.sh Mon Oct 22 18:41:22 2018
> (r339608)
> > +++ head/release/i386/mkisoimages.sh Mon Oct 22 19:39:20 2018
> (r339609)
> > @@ -23,6 +23,8 @@
> > # extra-bits-dir, if provided, contains additional files to be merged
> > # into base-bits-dir as part of making the image.
> >
> > +set -e
> > +
> > if [ "$1" = "-b" ]; then
> > # This is highly x86-centric and will be used directly below.
> > bootable="-o bootimage=i386;$4/boot/cdboot -o no-emul-boot"
> >
> > Modified: head/release/powerpc/mkisoimages.sh
> >
> ==
> > --- head/release/powerpc/mkisoimages.sh Mon Oct 22 18:41:22 2018
> (r339608)
> > +++ head/release/powerpc/mkisoimages.sh Mon Oct 22 19:39:20 2018
> (r339609)
> > @@ -23,6 +23,7 @@
> > # extra-bits-dir, if provided, contains additional files to be merged
> > # into base-bits-dir as part of making the image.
> >
> > +set -e
> >
> > if [ "$1" = "-b" ]; then
> > bootable=1
> >
> > Modified: head/release/sparc64/mkisoimages.sh
> >
> ==
> > --- head/release/sparc64/mkisoimages.sh Mon Oct 22 18:41:22 2018
> (r339608)
> > +++ head/release/sparc64/mkisoimages.sh Mon Oct 22 19:39:20 2018
> (r339609)
> > @@ -22,6 +22,8 @@
> > # resulting ISO image, base-bits-dir contains the image contents and
> > # extra-bits-dir, if provided, contains additional files to be merged
> > # into base-bits-dir as part of making the image.
> > +set -e
> > +
> > if [ $# -lt 3 ]; then
> > echo "Usage: $0 [-b] image-label image-name base-bits-dir
> > [extra-bits-dir]" > /dev/stderr
> > exit 1
> > ___
> > 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-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailm
Re: svn commit: r339876 - head/libexec/rtld-elf
[I note what I've failed to find a way to investigate.] On 2018-Nov-7, at 11:53, Mark Millard wrote: > [I trace code associated with bl <1322.plt_call.getenv> > in the two contexts and extend the range over which things > appear to match: up to some point after the branch > b <__glink_PLTresolve> .] > > On 2018-Nov-6, at 19:12, Mark Millard wrote: > >> [I've present a little information about the longer-existing >> failure's odd backtrace for /libexec/ld-elf.so.1 /bin/ls >> --but on powerpc64 FreeBSD instead of 32-bit powerpc FreeBSD.] >> >> On 2018-Nov-2, at 11:50, Konstantin Belousov wrote: >> >>> On Fri, Nov 02, 2018 at 10:38:08AM -0700, Mark Millard wrote: On 2018-Nov-2, at 8:52 AM, Konstantin Belousov wrote: > . . . That seems better. But it crashes during /bin/ls execution ( 0x0180 addresses ), apparently in a library routine ( 0x41?? addresses ): Program received signal SIGSEGV, Segmentation fault. 0x411220b4 in ?? () (gdb) bt #0 0x411220b4 in ?? () #1 0x4112200c in ?? () #2 0x01803c84 in ?? () #3 0x018023b4 in ?? () #4 0x010121a0 in .rtld_start () at /usr/src/libexec/rtld-elf/powerpc/rtld_start.S:112 Using a normal gdb run of /bin/ls suggests: #2 0x01803c84 in ?? () should be in main and seems to be: bl 0x1818914 #3 0x018023b4 in ?? () should be in _start Looking in the test context: 0x1803c80: bl 0x1818914 0x1803c84: cmpwi cr7,r3,-1 and: 0x1818914: li r11,59 0x1818918: b 0x18186f4 and: 0x18186f4: rlwinm r11,r11,2,0,29 0x18186f8: addis r11,r11,386 0x18186fc: lwz r11,-30316(r11) 0x1818700: mtctr r11 0x1818704: bctr Breaking at the bctr and using info reg: r110x4125ffa0 1093009312 It looks like there is some amount of activity before the traceback addresses show up. I've not found a good way to fill in the "in ??()" (or analogous) information. The addresses 0x411220?? do not match up with a normal run of /bin/ls from gdb: the addresses can not be accessed. It does appear that the code is in /lib/libc.so.7 in the test context: Breakpoint 2, reloc_non_plt (obj=0x41041600, obj_rtld=0x41104b57, flags=4, lockstate=0x0) at /usr/src/libexec/rtld-elf/powerpc/reloc.c:338 . . . >>> 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. >> >> I've got a little more information about the odd backtrace >> from the /libexec/ld-elf.so.1 /bin/ls failure that the >> prior patch allowed getting to, although for a powerpc64 >> example context. >> >> The information is only identifying where the code was >> in /bin/ls and /lib/libc.so.1 in the backtrace. For >> libc.so.1 I found the same code sequences in a gdb of >> /bin/ls directly, matching one first, using the addresses >> vs. in the /libexec/ld-elf.so.1 /bin/ls process to >> find offsets for going back and forth, and then used >> that two find the 2nd backtrace addresses material. >> >> Overall it suggests to me that (in somewhat >> symbolic terms): >> >> bl <1322.plt_call.getenv> >> >> eventually lead to executing the wrong code. >> >> >> The supporting detail is as follows. >> >> The /libexec/ld-elf.so.1 part of the backtrace was >> easy to find where the code was: >> >> (gdb) run /bin/ls >> Starting program: /libexec/ld-elf.so.1 /bin/ls >> >> Program received signal SIGSEGV, Segmentation fault. >> 0x00080118d81c in ?? () >> (gdb) bt >> #0 0x00080118d81c in ?? () >> #1 0x00080118d920 in ?? () >> #2 0x10002558 in ?? () >> #3 0x100037b0 in ?? () >> #4 0x01018450 in ._rtld_start () at >> /usr/src/libexec/rtld-elf/powerpc64/rtld_start.S:104 >> Backtrace stopped: frame did not save the PC >> >> (gdb) >> 101 ld %r7,128(%r1)/* exit proc */ >> 102 ld %r8,136(%r1)/* ps_strings */ >> 103 >> 104 blrl/* _start(argc, argv, envp, obj, cleanup, ps_strings) */ >> 105 >> 106 li %r0,1 /* _exit() */ >> 107 sc >> >> >> The /bin/ls part of the backtrace was easy to find >> were the code was: >> >> (gdb) symbol-file /bin/ls >> Load new symbol table from "/bin/ls"? (y or n) y >> Reading symbols from /bin/ls...Reading symbols from >> /usr/lib/debug//bin/ls.debug...done. >> done. >> (gdb) bt >> #0 0x00080118d81c in ?? () >> #1 0x00080118d9
Re: svn commit: r340231 - head/sys/kern
On Wed, Nov 07, 2018 at 01:35:57PM -0800, John Baldwin wrote: > On 11/7/18 1:01 PM, Ed Schouten wrote: > > Op wo 7 nov. 2018 om 19:32 schreef John Baldwin : > >> Modified: head/sys/kern/imgact_elf.c > >> == > >> --- head/sys/kern/imgact_elf.c Wed Nov 7 18:29:54 2018(r340230) > >> +++ head/sys/kern/imgact_elf.c Wed Nov 7 18:32:02 2018(r340231) > >> @@ -120,7 +120,8 @@ SYSCTL_INT(_debug, OID_AUTO, __elfN(legacy_coredump), > >> > >> int __elfN(nxstack) = > >> #if defined(__amd64__) || defined(__powerpc64__) /* both 64 and 32 bit */ > >> || \ > >> -(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) > >> +(defined(__arm__) && __ARM_ARCH >= 7) || defined(__aarch64__) || \ > >> +defined(__riscv) > >> 1; > >> #else > >> 0; > > > > Are we getting to the point that it might make sense to invert this > > logic, i.e., just list the architectures that require executable > > stacks? > > It's not clear. The remaining set is i386 (should be able to use nxstack > when using PAE and PG_NX is supported), MIPS (no X permission in PTEs), > 32-bit powerpc (no X permissions in PTEs AFAICT), and sparc64 (no X > permissions in PTEs AFAICT). For architectures without X ptes, removing > VM_PROT_EXECUTE from the stack permissions is a no-op and would be > harmless, so we could perhaps just default this to always on at this > point? AFAIR sparc64 ABI defines its stack as nx always (and PTEs do allow to control exec permission). ___ 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: r340241 - head/sys/vm
Author: markj
Date: Wed Nov 7 23:28:11 2018
New Revision: 340241
URL: https://svnweb.freebsd.org/changeset/base/340241
Log:
Fix a use-after-free in swp_pager_meta_free().
This was introduced in r326329 and explains the crashes mentioned in
the commit log message for r339934. In particular, on INVARIANTS
kernels, UMA trashing causes the loop to exit early, leaving swap
blocks behind when they should have been freed. After r336984 this
became more problematic since new anonymous mappings were more
likely to reuse swapped-out subranges of existing VM objects, so faults
would trigger pageins of freed memory rather than returning zeroed
pages.
Reviewed by: kib
MFC after:3 days
Sponsored by: The FreeBSD Foundation
Differential Revision:https://reviews.freebsd.org/D17897
Modified:
head/sys/vm/swap_pager.c
Modified: head/sys/vm/swap_pager.c
==
--- head/sys/vm/swap_pager.cWed Nov 7 21:36:52 2018(r340240)
+++ head/sys/vm/swap_pager.cWed Nov 7 23:28:11 2018(r340241)
@@ -1972,13 +1972,13 @@ swp_pager_meta_free(vm_object_t object, vm_pindex_t pi
swp_pager_update_freerange(&s_free, &n_free, sb->d[i]);
sb->d[i] = SWAPBLK_NONE;
}
+ pindex = sb->p + SWAP_META_PAGES;
if (swp_pager_swblk_empty(sb, 0, start) &&
swp_pager_swblk_empty(sb, limit, SWAP_META_PAGES)) {
SWAP_PCTRIE_REMOVE(&object->un_pager.swp.swp_blks,
sb->p);
uma_zfree(swblk_zone, sb);
}
- pindex = sb->p + SWAP_META_PAGES;
}
swp_pager_freeswapspace(s_free, n_free);
}
___
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: r340242 - head
Author: brooks
Date: Thu Nov 8 00:35:00 2018
New Revision: 340242
URL: https://svnweb.freebsd.org/changeset/base/340242
Log:
Add a top-level make target to rebuild all sysent files.
The sysent target is useful when changing makesyscalls.sh, when
making paired changes to syscalls.master files, or in a future where
freebsd32 sysent entries are built from the default syscalls.master.
Reviewed by: bdrewery
Obtained from:CheriBSD
Sponsored by: DARPA, AFRL
Differential Revision:https://reviews.freebsd.org/D17899
Modified:
head/Makefile
head/Makefile.inc1
Modified: head/Makefile
==
--- head/Makefile Wed Nov 7 23:28:11 2018(r340241)
+++ head/Makefile Thu Nov 8 00:35:00 2018(r340242)
@@ -33,6 +33,7 @@
# targets - Print a list of supported TARGET/TARGET_ARCH pairs
# for world and kernel targets.
# toolchains - Build a toolchain for all world and kernel targets.
+# sysent - (Re)build syscall entries from syscalls.master.
# xdev- xdev-build + xdev-install for the architecture
# specified with TARGET and TARGET_ARCH.
# xdev-build - Build cross-development tools.
@@ -135,6 +136,7 @@ TGTS= all all-man buildenv buildenvvars buildkernel bu
reinstallkernel reinstallkernel.debug \
installworld kernel-toolchain libraries maninstall \
obj objlink showconfig tags toolchain update \
+ sysent \
_worldtmp _legacy _bootstrap-tools _cleanobj _obj \
_build-tools _build-metadata _cross-tools _includes _libraries \
build32 distribute32 install32 buildsoft distributesoft installsoft \
Modified: head/Makefile.inc1
==
--- head/Makefile.inc1 Wed Nov 7 23:28:11 2018(r340241)
+++ head/Makefile.inc1 Thu Nov 8 00:35:00 2018(r340242)
@@ -1434,6 +1434,18 @@ packageworld: .PHONY
. endif
.endfor
+_sysent_dirs= sys/kern
+_sysent_dirs+= sys/compat/freebsd32
+_sysent_dirs+= sys/i386/ibcs2
+_sysent_dirs+= sys/amd64/linux \
+ sys/amd64/linux32 \
+ sys/arm64/linux \
+ sys/i386/linux
+sysent: .PHONY
+.for _dir in ${_sysent_dirs}
+ ${_+_}${MAKE} -C ${.CURDIR}/${_dir} sysent
+.endfor
+
#
# reinstall
#
___
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: r340242 - head
On 8 Nov 2018, at 0:35, Brooks Davis wrote: Author: brooks Date: Thu Nov 8 00:35:00 2018 New Revision: 340242 URL: https://svnweb.freebsd.org/changeset/base/340242 Log: Add a top-level make target to rebuild all sysent files. The sysent target is useful when changing makesyscalls.sh, when making paired changes to syscalls.master files, or in a future where freebsd32 sysent entries are built from the default syscalls.master. Reviewed by: bdrewery Obtained from:CheriBSD Sponsored by: DARPA, AFRL Differential Revision:https://reviews.freebsd.org/D17899 Modified: head/Makefile head/Makefile.inc1 I was wondering if the Makefile.inc1 parts shouldn’t mostly be in sys/Makefile or similar rather than at the top-level? /bz ___ 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"
