[PATCH] Allow softraid crypto to work with write-protected keys
Softraid currently opens the key disk as read + write. This isn't
necessary when just *reading* from the key disk.
This patch allows for softraid crypto to mount volumes with
write-protected keydisks (eg. Kanguru Flash Blu:
https://www.kanguru.com/storage-accessories/flash-blu30.shtml).
Also tested volume creation with the Flash Blu write-protect switch off;
still works as usual.
Index: sys/dev/softraid_crypto.c
===
RCS file: /cvs/src/sys/dev/softraid_crypto.c,v
retrieving revision 1.126
diff -u -p -r1.126 softraid_crypto.c
--- sys/dev/softraid_crypto.c 12 Apr 2016 16:26:54 -
1.126 +++ sys/dev/softraid_crypto.c 17 May 2016 04:18:52 -
@@ -797,7 +797,7 @@ sr_crypto_read_key_disk(struct sr_discip
sr_error(sc, "cannot open key disk %s", devname);
goto done;
}
- if (VOP_OPEN(vn, FREAD | FWRITE, NOCRED, curproc)) {
+ if (VOP_OPEN(vn, FREAD, NOCRED, curproc)) {
DNPRINTF(SR_D_META,"%s: sr_crypto_read_key_disk cannot
" "open %s\n", DEVNAME(sc), devname);
vput(vn);
@@ -811,7 +811,7 @@ sr_crypto_read_key_disk(struct sr_discip
NOCRED, curproc)) {
DNPRINTF(SR_D_META, "%s: sr_crypto_read_key_disk ioctl
" "failed\n", DEVNAME(sc));
- VOP_CLOSE(vn, FREAD | FWRITE, NOCRED, curproc);
+ VOP_CLOSE(vn, FREAD, NOCRED, curproc);
vput(vn);
goto done;
}
remove special vlan ioctls in ifconfig
the vlan ioctls have been superseded by the generic ifparent and
vnetid ioctls, and will eventually go away.
this removes the vlan ioctl handling from ifconfig. however, to
continue to support existing vlan interface configuration files
(/etc/hostname.vlan*), the command line options have been aliased
to the equiv handlers for the generic ioctls.
ok?
Index: ifconfig.c
===
RCS file: /cvs/src/sbin/ifconfig/ifconfig.c,v
retrieving revision 1.320
diff -u -p -r1.320 ifconfig.c
--- ifconfig.c 18 Apr 2016 06:20:23 - 1.320
+++ ifconfig.c 17 May 2016 00:48:43 -
@@ -90,8 +90,6 @@
#include
-#include
-
#include
#include
@@ -210,12 +208,8 @@ void setmpwencap(const char *, int);
void setmpwlabel(const char *, const char *);
void setmpwneighbor(const char *, int);
void setmpwcontrolword(const char *, int);
-void setvlantag(const char *, int);
-void setvlandev(const char *, int);
-void unsetvlandev(const char *, int);
void mpe_status(void);
void mpw_status(void);
-void vlan_status(void);
void setinstance(const char *, int);
intmain(int, char *[]);
intprefix(void *val, int);
@@ -351,9 +345,9 @@ const structcmd {
{ "scan", NEXTARG0, 0, setifscan },
{ "broadcast", NEXTARG,0, setifbroadaddr },
{ "prefixlen", NEXTARG,0, setifprefixlen},
- { "vlan", NEXTARG,0, setvlantag },
- { "vlandev",NEXTARG,0, setvlandev },
- { "-vlandev", 1, 0, unsetvlandev },
+ { "vlan", NEXTARG,0, setvnetid },
+ { "vlandev",NEXTARG,0, setifparent },
+ { "-vlandev", 1, 0, delifparent },
{ "group", NEXTARG,0, setifgroup },
{ "-group", NEXTARG,0, unsetifgroup },
{ "autoconf", 1, 0, setautoconf },
@@ -2947,7 +2941,6 @@ status(int link, struct sockaddr_dl *sdl
if_indextoname(ifrdesc.ifr_index, ifname) != NULL)
printf("\tpatch: %s\n", ifname);
#endif
- vlan_status();
getvnetid();
getifparent();
#ifndef SMALL
@@ -3652,100 +3645,6 @@ getifparent(void)
parent = ifp.ifp_parent;
printf("\tparent: %s\n", parent);
-}
-
-static int __tag = 0;
-static int __have_tag = 0;
-
-void
-vlan_status(void)
-{
- struct vlanreq vreq;
-
- bzero((char *)&vreq, sizeof(struct vlanreq));
- ifr.ifr_data = (caddr_t)&vreq;
-
- if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
- return;
-
- if (vreq.vlr_tag || (vreq.vlr_parent[0] != '\0'))
- printf("\tvlan: %d parent interface: %s\n",
- vreq.vlr_tag, vreq.vlr_parent[0] == '\0' ?
- "" : vreq.vlr_parent);
-}
-
-/* ARGSUSED */
-void
-setvlantag(const char *val, int d)
-{
- u_int16_t tag;
- struct vlanreq vreq;
- const char *errmsg = NULL;
-
- __tag = tag = strtonum(val, 0, 4095, &errmsg);
- if (errmsg)
- errx(1, "vlan tag %s: %s", val, errmsg);
- __have_tag = 1;
-
- bzero((char *)&vreq, sizeof(struct vlanreq));
- ifr.ifr_data = (caddr_t)&vreq;
-
- if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
- err(1, "SIOCGETVLAN");
-
- vreq.vlr_tag = tag;
-
- if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
- err(1, "SIOCSETVLAN");
-}
-
-/* ARGSUSED */
-void
-setvlandev(const char *val, int d)
-{
- struct vlanreq vreq;
- int tag;
- size_t skip;
- const char *estr;
-
- bzero((char *)&vreq, sizeof(struct vlanreq));
- ifr.ifr_data = (caddr_t)&vreq;
-
- if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
- err(1, "SIOCGETVLAN");
-
- (void) strlcpy(vreq.vlr_parent, val, sizeof(vreq.vlr_parent));
-
- if (!__have_tag && vreq.vlr_tag == 0) {
- skip = strcspn(ifr.ifr_name, "0123456789");
- tag = strtonum(ifr.ifr_name + skip, 0, 4095, &estr);
- if (estr != NULL)
- errx(1, "invalid vlan tag and device specification");
- vreq.vlr_tag = tag;
- } else if (__have_tag)
- vreq.vlr_tag = __tag;
-
- if (ioctl(s, SIOCSETVLAN, (caddr_t)&ifr) == -1)
- err(1, "SIOCSETVLAN");
-}
-
-/* ARGSUSED */
-void
-unsetvlandev(const char *val, int d)
-{
- struct vlanreq vreq;
-
- bzero((char *)&vreq, sizeof(struct vlanreq));
- ifr.ifr_data = (caddr_t)&vreq;
-
- if (ioctl(s, SIOCGETVLAN, (caddr_t)&ifr) == -1)
- err(1, "SIOCGETVLAN");
-
- bzero((char *)&vreq.vlr_parent, sizeof(vreq.vlr_parent));
- vreq.vlr_tag = 0;
-
- if (ioctl
Re: Accept cnmac as a valid rootdev from uboot on octeon
Visa Hankala wrote:
> On Mon, May 16, 2016 at 01:39:31AM +0200, Kim Lidström wrote:
> > I am nfs booting my edgerouter lite and didn't like to have to manually
> > enter 'cnmac0'
> > as my root device every boot.
> >
> > This is what I came up with. I stole the idea from macppc and modified
> > it a little.
> >
> > Am I way off here?
>
> The idea looks good. The patch format is somewhat broken though. See my
> comments inline.
I like comments! Thanks!
>
> The buffer allocation errors are not caused by this patch. Have you
> modified cnmac(4)? The driver allocates a fixed number of gather buffers
> and the system has run out of those. Are the cnmac(4) ports transmitting
> at all after the error?
>
I have not modified cnmac(4) and, from what I have seen during the day,
the ports seem to be transmitting without any hiccups.
I seem to consistently get around 95 megabits per second both up and
down.
The only thing I have noticed was that my phone all of a sudden couldn't
do some DNS lookups (imgur, for example) but that is most likely not
related.
I am in fact sending this email through said ports.
> > +
> > + if (dp->dev == NULL)
> > + printf("string [%s] not found\n", bootdev);
>
> The message is not very helpful.
I agree!
> > switch (bootdev_class) {
> > case DV_DISK:
> > - if ((strcmp(drvrname, "wd") == 0 ||
> > - strcmp(drvrname, "sd") == 0 ||
> > - strcmp(drvrname, "octcf") == 0 ||
> > - strcmp(drvrname, "amdcf") == 0) &&
> > - strcmp(name, bootdev) == 0)
> > - bootdv = dev;
> > - break;
> > case DV_IFNET:
> > /*
> > -* This relies on the onboard Ethernet interface being
> > -* attached before any other (usb) interface.
> > +* DV_IFNET relies on the onboard Ethernet interface
> > +* being attached before any other (usb) interface.
> > */
> > bootdv = dev;
>
> bootdv should be set only if the device name matches bootdev. Otherwise
> the system picks always the first device in the device class. With this
> tweak, the comment seems outdated.
>
I left that comment in there because I wasn't sure if it was still
relevant or not (Do the ethernet interface just happen to be attached
before any other interfaces on my device?) but if that is the case then
ofcourse it should be removed!
Is this patch better? I have tested it by trying both cnmac0, cnmac1 and
cnmac2 as rootdev and it seems to work properly.
I also removed the outdated comment, changed the pointless text (Maybe
it'd be more appropriate to remove it?) and changed a memcpy() to
strlcpy().
Oh, I added that strncmp too!
Index: sys/arch/octeon/octeon/autoconf.c
===
RCS file: /cvs/src/sys/arch/octeon/octeon/autoconf.c,v
retrieving revision 1.7
diff -u -p -r1.7 autoconf.c
--- sys/arch/octeon/octeon/autoconf.c 20 Jul 2015 19:44:32 -
1.7
+++ sys/arch/octeon/octeon/autoconf.c 16 May 2016 23:52:33 -
@@ -44,11 +44,45 @@ cpu_configure(void)
cold = 0;
}
+struct devmap {
+ char *dev;
+ enum devclass class;
+};
+
+struct devmap *
+findtype(void)
+{
+ static struct devmap devmap[] = {
+ { "wd", DV_DISK },
+ { "sd", DV_DISK },
+ { "octcf", DV_DISK },
+ { "amdcf", DV_DISK },
+ { "cnmac", DV_IFNET },
+ { NULL, DV_DULL }
+ };
+ struct devmap *dp = &devmap[0];
+
+ if (strlen(bootdev) < 2)
+ return(dp);
+
+ while (dp->dev) {
+ if (strncmp(bootdev, dp->dev, strlen(dp->dev)) == 0)
+ break;
+ dp++;
+ }
+
+ if (dp->dev == NULL)
+ printf("%s is not a valid rootdev\n", bootdev);
+
+ return(dp);
+}
+
void
parse_uboot_root(void)
{
char *p;
size_t len;
+ struct devmap *dp;
/*
* Turn the U-Boot root device (rootdev=/dev/octcf0) into a
boot device.
@@ -62,9 +96,10 @@ parse_uboot_root(void)
if (len <= 2 || len >= sizeof bootdev - 1)
return;
- memcpy(bootdev, p, len);
- bootdev[len] = '\0';
- bootdev_class = DV_DISK;
+ strlcpy(bootdev, p, sizeof bootdev);
+
+ dp = findtype();
+ bootdev_class = dp->class;
}
void
@@ -83,27 +118,14 @@ device_register(struct device *dev, void
if (bootdv != NULL)
return;
- const char *drvrname = dev->dv_cfdata->cf_driver->cd_name;
- const char *name = dev->dv_xname;
-
if (dev->dv_class != bootdev_class)
return;
switch (bootdev_class) {
case DV_DISK:
- if ((strcmp(drvrname, "wd") == 0 ||
- strcmp(drvrname, "sd") == 0 ||
-
Re: Accept cnmac as a valid rootdev from uboot on octeon
On Mon, May 16, 2016 at 01:39:31AM +0200, Kim Lidström wrote:
> I am nfs booting my edgerouter lite and didn't like to have to manually
> enter 'cnmac0'
> as my root device every boot.
>
> This is what I came up with. I stole the idea from macppc and modified
> it a little.
>
> Am I way off here?
The idea looks good. The patch format is somewhat broken though. See my
comments inline.
The buffer allocation errors are not caused by this patch. Have you
modified cnmac(4)? The driver allocates a fixed number of gather buffers
and the system has run out of those. Are the cnmac(4) ports transmitting
at all after the error?
> Index: sys/arch/octeon/octeon/autoconf.c
> ===
> RCS file: /cvs/src/sys/arch/octeon/octeon/autoconf.c,v
> retrieving revision 1.7
> diff -u -p -r1.7 autoconf.c
> --- sys/arch/octeon/octeon/autoconf.c 20 Jul 2015 19:44:32 -
> 1.7
> +++ sys/arch/octeon/octeon/autoconf.c 15 May 2016 23:28:33 -
> @@ -44,11 +44,45 @@ cpu_configure(void)
> cold = 0;
> }
>
> +struct devmap {
> + char *dev;
> + enum devclass class;
> +};
> +
> +struct devmap *
> +findtype(void)
> +{
> + static struct devmap devmap[] = {
> + { "wd", DV_DISK },
> + { "sd", DV_DISK },
> + { "octcf", DV_DISK },
> + { "amdcf", DV_DISK },
> + { "cnmac", DV_IFNET },
> + { NULL, DV_DULL }
> + };
> + struct devmap *dp = &devmap[0];
> +
> + if (strlen(bootdev) < 2)
> + return(dp);
> +
> + while (dp->dev) {
> + if (strncmp(bootdev, dp->dev, strlen(dp->dev)) == 0)
> + break;
> + dp++;
> + }
> +
> + if (dp->dev == NULL)
> + printf("string [%s] not found\n", bootdev);
The message is not very helpful.
> +
> + return(dp);
> +}
> +
> void
> parse_uboot_root(void)
> {
> char *p;
> size_t len;
> + struct devmap *dp;
>
> /*
> * Turn the U-Boot root device (rootdev=/dev/octcf0) into a
> boot device.
> @@ -64,7 +98,9 @@ parse_uboot_root(void)
>
> memcpy(bootdev, p, len);
> bootdev[len] = '\0';
> - bootdev_class = DV_DISK;
> +
> + dp = findtype();
> + bootdev_class = dp->class;
> }
>
> void
> @@ -82,26 +118,16 @@ device_register(struct device *dev, void
> {
> if (bootdv != NULL)
> return;
> -
> - const char *drvrname = dev->dv_cfdata->cf_driver->cd_name;
> - const char *name = dev->dv_xname;
> -
> +
> if (dev->dv_class != bootdev_class)
> return;
> -
> +
> switch (bootdev_class) {
> case DV_DISK:
> - if ((strcmp(drvrname, "wd") == 0 ||
> - strcmp(drvrname, "sd") == 0 ||
> - strcmp(drvrname, "octcf") == 0 ||
> - strcmp(drvrname, "amdcf") == 0) &&
> - strcmp(name, bootdev) == 0)
> - bootdv = dev;
> - break;
> case DV_IFNET:
> /*
> -* This relies on the onboard Ethernet interface being
> -* attached before any other (usb) interface.
> +* DV_IFNET relies on the onboard Ethernet interface
> +* being attached before any other (usb) interface.
> */
> bootdv = dev;
bootdv should be set only if the device name matches bootdev. Otherwise
the system picks always the first device in the device class. With this
tweak, the comment seems outdated.
switch (bootdev_class) {
case DV_DISK:
case DV_IFNET:
if (strcmp(name, bootdev) == 0)
bootdv = dev;
break;
default:
break;
}
> break;
> @@ -120,3 +146,4 @@ struct nam2blk nam2blk[] = {
> { "amdcf", 19 },
> { NULL, -1 }
> };
> +
>
Re: sendbug subject
Mon, 16 May 2016 00:01:59 +0200 Jeremie Courreges-Anglas
> "trondd" writes:
>
> > On Sun, May 15, 2016 1:22 pm, Juan Francisco Cantero Hurtado wrote:
> >> On Sun, May 15, 2016 at 06:43:16PM +0200, Jeremie Courreges-Anglas wrote:
> >>> "Ted Unangst" writes:
> >>>
> >>> > i'm tired of seeing bug reports with no subject. i also get a fair bit
> >>> of spam
> >>> > with no subject and i am easily confused. something is better than
> >>> nothing.
> >>>
> >>> I fear that after that change all bug reports will only have [bug
> >>> report] as Subject. Something that wouldn't catch the eye of people
> >>> that might be able to understand and fix the problem.
> >>
> >
> > Why not make Subject a required field? Might want to also add a comment
> > there like Category and Synopsis have.
>
> I like this idea, but those are not "required" fields. Also I don't
> find the warning message helpful.
>
> Here's a patch that builds up on Tim's diff. Tell the user which fields
> should be filled in, in the order where they are found in the bugreport.
An idea, how about form it Subject: [bugrep] subject, or whatever you
would prefer in the brackets, to discern the subjects when intermixed.
Apologies for not backing this humble useless suggestion with a patch.
> Index: sendbug.c
> ===
> RCS file: /cvs/src/usr.bin/sendbug/sendbug.c,v
> retrieving revision 1.74
> diff -u -p -p -u -r1.74 sendbug.c
> --- sendbug.c 17 Mar 2016 19:40:43 - 1.74
> +++ sendbug.c 15 May 2016 21:53:39 -
> @@ -30,7 +30,7 @@
> #define BEGIN64 "begin-base64 "
> #define END64 ""
>
> -int checkfile(const char *);
> +void checkfile(const char *);
> void debase(void);
> void dmesg(FILE *);
> int editit(const char *);
> @@ -164,8 +164,7 @@ main(int argc, char *argv[])
> errx(1, "report unchanged, nothing sent");
>
> prompt:
> - if (!checkfile(tmppath))
> - fprintf(stderr, "fields are blank, must be filled in\n");
> + checkfile(tmppath);
> c = prompt();
> switch (c) {
> case 'a':
> @@ -508,26 +507,37 @@ matchline(const char *s, const char *lin
> /*
> * Are all required fields filled out?
> */
> -int
> +void
> checkfile(const char *pathname)
> {
> FILE *fp;
> size_t len;
> - int category = 0, synopsis = 0;
> + int category = 0, synopsis = 0, subject = 0;
> char *buf;
>
> if ((fp = fopen(pathname, "r")) == NULL) {
> warn("%s", pathname);
> - return (0);
> + return;
> }
> while ((buf = fgetln(fp, &len))) {
> if (matchline(">Category:", buf, len))
> category = 1;
> else if (matchline(">Synopsis:", buf, len))
> synopsis = 1;
> + else if (matchline("Subject:", buf, len))
> + subject = 1;
> }
> fclose(fp);
> - return (category && synopsis);
> + if (!category || !synopsis || !subject) {
> + fprintf(stderr, "Some fields are blank, please fill them in: ");
> + if (!subject)
> + fprintf(stderr, "Subject ");
> + if (!synopsis)
> + fprintf(stderr, "Synopsis ");
> + if (!category)
> + fprintf(stderr, "Category ");
> + fputc('\n', stderr);
> + }
> }
>
> void
>
Re: Is loss of read-only /usr permanent?
On 2016/05/16 14:22, Craig Skinner wrote: > On 2016-05-14 Sat 12:25 PM |, RD Thrush wrote: > > > > Thanks, Craig. That is much better than what I proposed > > > > Another solution occured to me Bob;- > > ro /usr > rw /usr/lib (an additional mount point) > > If power was lost during boot, most of /usr would be unaffected. If /usr/lib is toast, /usr isn't going to do you much good.
Re: armv7 bus_dmamap_sync(9) fix
On Mon, May 16, 2016 at 12:53:54AM +0200, Mark Kettenis wrote: > So Theo's SROP mitigation diff made my armv7 machine completely > unstable. Filesystem-related panics, random core dumps, files with > blocks of zeroes on them, etc. > > Looking at the changes in question, there is no way they're > responsible for this behavior. This smells like cache-related bug > triggered by changes in the memory layout in the kernel. Since I'm > running with root on an SD card hanging off imxesdhc(4), I started > looking for missing bus_dmamap_sync() calls in that driver. Found > one, but notone that actually mattered. Then I turned to the actual > bus_dmamap_sync(9) implementation. It has a nice comment explaining > when cache maintenance is needed. It mentions that the D-Cache needs > to be invalidated for a POSTREAD operation. But it doesn't actually > do that. > > The NetBSD code (from which our code is derived) does implement this, > and has an additional comment: > > /* > * Cortex CPUs can do speculative loads so we need to clean the cache > * after a DMA read to deal with any speculatively loaded cache lines. > * Since these can't be dirty, we can just invalidate them and don't > * have to worry about having to write back their contents. > */ > > Adding the relevant bit of code seems to fix the issue. > > So here's the diff. It seems that this code isn't needed on the > pre-ARMv7 hardware. So I could sprinkle in an #ifdef CPU_ARMv7 if > people think that is worth it. But that might make us forget this > code for future ARM processor generations. > > ok? ok jsg@ > > > Index: arch/arm/arm/bus_dma.c > === > RCS file: /cvs/src/sys/arch/arm/arm/bus_dma.c,v > retrieving revision 1.29 > diff -u -p -r1.29 bus_dma.c > --- arch/arm/arm/bus_dma.c10 Mar 2016 10:22:43 - 1.29 > +++ arch/arm/arm/bus_dma.c15 May 2016 22:50:22 - > @@ -421,6 +421,19 @@ _bus_dmamap_sync_segment(vaddr_t va, pad > cpu_dcache_wb_range(va, len); > cpu_sdcache_wb_range(va, pa, len); > break; > + > + /* > + * Cortex CPUs can do speculative loads so we need to clean the cache > + * after a DMA read to deal with any speculatively loaded cache lines. > + * Since these can't be dirty, we can just invalidate them and don't > + * have to worry about having to write back their contents. > + */ > + case BUS_DMASYNC_POSTREAD: > + case BUS_DMASYNC_POSTREAD|BUS_DMASYNC_POSTWRITE: > + membar_sync(); > + cpu_dcache_inv_range(va, len); > + cpu_sdcache_inv_range(va, pa, len); > + break; > } > } > >
Re: Is loss of read-only /usr permanent?
On 2016-05-14 Sat 12:25 PM |, RD Thrush wrote: > > Thanks, Craig. That is much better than what I proposed > Another solution occured to me Bob;- ro /usr rw /usr/lib (an additional mount point) If power was lost during boot, most of /usr would be unaffected. The mods I mailed earlier could also be adapted for a ro /usr/lib too. Cheers! -- Q: What is the last thing a Kansas stripper takes off? A: Her bowling shoes.
Re: armv7 bus_dmamap_sync(9) fix
> Date: Mon, 16 May 2016 18:32:53 +1000
> From: Jonathan Gray
>
> After consulting an older version of the ARM ARM it seems the cp15
> barriers were introduced with armv6 so just do the compiler hint.
ok kettenis@
> Index: atomic.h
> ===
> RCS file: /cvs/src/sys/arch/arm/include/atomic.h,v
> retrieving revision 1.14
> diff -u -p -r1.14 atomic.h
> --- atomic.h 25 Apr 2016 08:00:43 - 1.14
> +++ atomic.h 16 May 2016 08:31:29 -
> @@ -465,6 +465,21 @@ atomic_clearbits_int(volatile unsigned i
> : "memory", "cc"
> );
> }
> +#endif /* CPU_ARMv7 */
> +
> +#if !defined(CPU_ARMv7)
> +
> +#define __membar() do { \
> + __asm __volatile("" ::: "memory"); \
> +} while (0)
> +
> +#define membar_enter() __membar()
> +#define membar_exit()__membar()
> +#define membar_producer()__membar()
> +#define membar_consumer()__membar()
> +#define membar_sync()__membar()
> +
> +#else /* !CPU_ARMv7 */
>
> #define __membar(_f) do { __asm __volatile(_f ::: "memory"); } while (0)
>
>
>
Re: cleanup pppd auth
On 2016/05/16 00:17, Jeremie Courreges-Anglas wrote: > "Ted Unangst" writes: > > > While making a small change to pppd, I noticed there is a lot of PAM and > > shadow code which is not relevant to us. The aspiring developer may then > > switch to bsd auth or even just crypt_checkpass, but first purge the tangly > > morass. > > ok jca@, but please also delete comments that are now meaningless: > > /* > - * This function is needed for PAM. > - */ > ... > -/* These functions are not enabled for PAM. The reason for this is that > */ > -/* there is not necessarily a "passwd" entry for this user. That is > */ > -/* real purpose of 'PAM' -- to virtualize the account data from the > */ > -/* application. If you want to do the same thing, write the entry in > */ > -/* the 'session' hook. > */ > > -- > jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE > Since upstream stopped supporting anything other than Linux/Solaris in 2000 (after the 2.3.11 release) this is unlikely to get in the way of updates, so ok with me too.
Re: Accept cnmac as a valid rootdev from uboot on octeon
Hmm, alright. This didn't turn out as good as I expected after some more testing. Right now I am getting loads and loads of cnmac0: cannot allocate gather buffer from free pool allocator cnmac0: failed to transmit packet in my dmesg. What am I missing here? Is there an init function (octeon_eth_buf_init?) that isn't being called because of this?
Re: armv7 bus_dmamap_sync(9) fix
On Mon, May 16, 2016 at 02:21:26PM +1000, Jonathan Gray wrote:
> On Mon, May 16, 2016 at 01:01:01PM +1000, Jonathan Gray wrote:
> > On Mon, May 16, 2016 at 12:53:54AM +0200, Mark Kettenis wrote:
> > > So Theo's SROP mitigation diff made my armv7 machine completely
> > > unstable. Filesystem-related panics, random core dumps, files with
> > > blocks of zeroes on them, etc.
> > >
> > > Looking at the changes in question, there is no way they're
> > > responsible for this behavior. This smells like cache-related bug
> > > triggered by changes in the memory layout in the kernel. Since I'm
> > > running with root on an SD card hanging off imxesdhc(4), I started
> > > looking for missing bus_dmamap_sync() calls in that driver. Found
> > > one, but notone that actually mattered. Then I turned to the actual
> > > bus_dmamap_sync(9) implementation. It has a nice comment explaining
> > > when cache maintenance is needed. It mentions that the D-Cache needs
> > > to be invalidated for a POSTREAD operation. But it doesn't actually
> > > do that.
> > >
> > > The NetBSD code (from which our code is derived) does implement this,
> > > and has an additional comment:
> > >
> > > /*
> > > * Cortex CPUs can do speculative loads so we need to clean the
> > > cache
> > > * after a DMA read to deal with any speculatively loaded cache
> > > lines.
> > > * Since these can't be dirty, we can just invalidate them and
> > > don't
> > > * have to worry about having to write back their contents.
> > > */
> > >
> > > Adding the relevant bit of code seems to fix the issue.
> > >
> > > So here's the diff. It seems that this code isn't needed on the
> > > pre-ARMv7 hardware. So I could sprinkle in an #ifdef CPU_ARMv7 if
> > > people think that is worth it. But that might make us forget this
> > > code for future ARM processor generations.
> > >
> > > ok?
> >
> > membar_sync() only exists for CPU_ARMv7 currently, I'm not sure
> > exactly when it was introduced (some v5 and all v6?) but we might be
> > able to use CP15DMB for armish/zaurus?
>
> and with the r0 use flagged in the extended asm syntax:
After consulting an older version of the ARM ARM it seems the cp15
barriers were introduced with armv6 so just do the compiler hint.
Index: atomic.h
===
RCS file: /cvs/src/sys/arch/arm/include/atomic.h,v
retrieving revision 1.14
diff -u -p -r1.14 atomic.h
--- atomic.h25 Apr 2016 08:00:43 - 1.14
+++ atomic.h16 May 2016 08:31:29 -
@@ -465,6 +465,21 @@ atomic_clearbits_int(volatile unsigned i
: "memory", "cc"
);
}
+#endif /* CPU_ARMv7 */
+
+#if !defined(CPU_ARMv7)
+
+#define __membar() do { \
+ __asm __volatile("" ::: "memory"); \
+} while (0)
+
+#define membar_enter() __membar()
+#define membar_exit() __membar()
+#define membar_producer() __membar()
+#define membar_consumer() __membar()
+#define membar_sync() __membar()
+
+#else /* !CPU_ARMv7 */
#define __membar(_f) do { __asm __volatile(_f ::: "memory"); } while (0)
new mainboard: hangs if left for a long time untouched, no xvideo support, no dri support.
Hi, Just in case somebody interested, the first problem (hangs) is most annoying: dmesg: OpenBSD 6.0-beta (GENERIC.MP) #2: Sun May 15 13:36:36 EEST 2016 r...@lbld12.duckdns.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 17037791232 (16248MB) avail mem = 16516952064 (15751MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xa7ed9000 (92 entries) bios0: vendor American Megatrends Inc. version "0237" date 08/07/2015 bios0: ASUSTeK COMPUTER INC. Q170M-C acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP APIC FPDT FIDT MCFG HPET SSDT LPIT SSDT SSDT SSDT DBGP DBG2 SSDT SSDT UEFI SSDT ASF! acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) UAR1(S4) UAR2(S4) PS2K(S3) PS2M(S3) PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) [...] acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz, 2694.24 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu0: 256KB 64b/line 8-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges cpu0: apic clock running at 23MHz cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz, 2693.32 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu1: 256KB 64b/line 8-way L2 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) cpu2: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz, 2693.32 MHz cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu2: 256KB 64b/line 8-way L2 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) cpu3: Intel(R) Core(TM) i5-6400 CPU @ 2.70GHz, 2693.32 MHz cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,SENSOR,ARAT cpu3: 256KB 64b/line 8-way L2 cache cpu3: smt 0, core 3, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins acpimcfg0 at acpi0 addr 0xe000, bus 0-255 acpihpet0 at acpi0: 2399 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (PEG0) acpiprt2 at acpi0: bus -1 (PEG1) acpiprt3 at acpi0: bus -1 (PEG2) acpiprt4 at acpi0: bus 4 (RP09) acpiprt5 at acpi0: bus -1 (RP10) acpiprt6 at acpi0: bus 5 (RP11) acpiprt7 at acpi0: bus -1 (RP12) acpiprt8 at acpi0: bus -1 (RP13) acpiprt9 at acpi0: bus 3 (RP01) acpiprt10 at acpi0: bus -1 (RP02) acpiprt11 at acpi0: bus -1 (RP03) acpiprt12 at acpi0: bus -1 (RP04) acpiprt13 at acpi0: bus -1 (RP05) acpiprt14 at acpi0: bus -1 (RP06) acpiprt15 at acpi0: bus -1 (RP07) acpiprt16 at acpi0: bus -1 (RP08) acpiprt17 at acpi0: bus 2 (RP17) acpiprt18 at acpi0: bus -1 (RP18) acpiprt19 at acpi0: bus -1 (RP19) acpiprt20 at acpi0: bus -1 (RP20) acpiprt21 at acpi0: bus -1 (RP14) acpiprt22 at acpi0: bus -1 (RP15) acpiprt23 at acpi0: bus -1 (RP16) acpiec0 at acpi0: not present acpicpu0 at acpi0: C3(200@256 mwait.1@0x40), C2(200@120 mwait.1@0x32), C1(1000@1 mwait.1), PSS acpicpu1 at acpi0: C3(200@256 mwait.1@0x40), C2(200@120 mwait.1@0x32), C1(1000@1 mwait.1), PSS acpicpu2 at acpi0: C3(200@256 mwait.1@0x40), C2(200@120 mwait.1@0x32), C1(1000@1 mwait.1), PSS acpicpu3 at acpi0: C3(200@256 mwait.1@0x40), C2(200@120 mwait.1@0x32), C1(1000@1 mwait.1), PSS acpipwrres0 at acpi0: PG00, resource for PEG0 acpipwrres1 at acpi0: PG01, resource for PEG1 acpipwrres2 at acpi0: PG02, resource for PEG2 acpipwrres3 at acpi0: WRST acpipwrres4 at acpi0: WRST acpipwrres5 at acpi0: WRST acpipwrres6 at
