svn commit: r244144 - in head/sys/amd64: amd64 include
Author: grehan Date: Wed Dec 12 08:35:32 2012 New Revision: 244144 URL: http://svnweb.freebsd.org/changeset/base/244144 Log: Implement an API to allow a hypervisor to save/restore guest floating point state without having to know the size of floating-point state. Unstaticize fpurestore to allow the hypervisor to save/restore guest state using fpusave/fpurestore on the allocated FPU state area. Reviewed by: kib Obtained from:NetApp/bhyve MFC after:1 week Modified: head/sys/amd64/amd64/fpu.c head/sys/amd64/include/fpu.h Modified: head/sys/amd64/amd64/fpu.c == --- head/sys/amd64/amd64/fpu.c Wed Dec 12 07:29:38 2012(r244143) +++ head/sys/amd64/amd64/fpu.c Wed Dec 12 08:35:32 2012(r244144) @@ -47,6 +47,7 @@ __FBSDID("$FreeBSD$"); #include #include #include +#include #include #include @@ -134,6 +135,7 @@ SYSCTL_INT(_hw, HW_FLOATINGPT, floatingp static int use_xsaveopt; int use_xsave; /* non-static for cpu_switch.S */ uint64_t xsave_mask; /* the same */ +static uma_zone_t fpu_save_area_zone; static struct savefpu *fpu_initialstate; struct xsave_area_elm_descr { @@ -151,7 +153,7 @@ fpusave(void *addr) fxsave((char *)addr); } -static void +void fpurestore(void *addr) { @@ -312,6 +314,10 @@ fpuinitstate(void *arg __unused) } } + fpu_save_area_zone = uma_zcreate("FPU_save_area", + cpu_max_ext_state_size, NULL, NULL, NULL, NULL, + XSAVE_AREA_ALIGN - 1, 0); + start_emulating(); intr_restore(saveintr); } @@ -980,3 +986,27 @@ is_fpu_kern_thread(u_int flags) return (0); return ((curpcb->pcb_flags & PCB_KERNFPU) != 0); } + +/* + * FPU save area alloc/free/init utility routines + */ +struct savefpu * +fpu_save_area_alloc(void) +{ + + return (uma_zalloc(fpu_save_area_zone, 0)); +} + +void +fpu_save_area_free(struct savefpu *fsa) +{ + + uma_zfree(fpu_save_area_zone, fsa); +} + +void +fpu_save_area_reset(struct savefpu *fsa) +{ + + bcopy(fpu_initialstate, fsa, cpu_max_ext_state_size); +} Modified: head/sys/amd64/include/fpu.h == --- head/sys/amd64/include/fpu.hWed Dec 12 07:29:38 2012 (r244143) +++ head/sys/amd64/include/fpu.hWed Dec 12 08:35:32 2012 (r244144) @@ -57,6 +57,7 @@ void fpuexit(struct thread *td); intfpuformat(void); intfpugetregs(struct thread *td); void fpuinit(void); +void fpurestore(void *addr); void fpusave(void *addr); intfpusetregs(struct thread *td, struct savefpu *addr, char *xfpustate, size_t xfpustate_size); @@ -73,6 +74,10 @@ int fpu_kern_leave(struct thread *td, st intfpu_kern_thread(u_int flags); intis_fpu_kern_thread(u_int flags); +struct savefpu *fpu_save_area_alloc(void); +void fpu_save_area_free(struct savefpu *fsa); +void fpu_save_area_reset(struct savefpu *fsa); + /* * Flags for fpu_kern_alloc_ctx(), fpu_kern_enter() and fpu_kern_thread(). */ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244145 - head/sys/dev/sound/pci/hda
Author: mav Date: Wed Dec 12 11:44:20 2012 New Revision: 244145 URL: http://svnweb.freebsd.org/changeset/base/244145 Log: Add quirks for AD1984A codec and Lenovo X300 laptop. PR: kern/148741 MFC after:2 weeks Modified: head/sys/dev/sound/pci/hda/hdaa_patches.c head/sys/dev/sound/pci/hda/hdac.h Modified: head/sys/dev/sound/pci/hda/hdaa_patches.c == --- head/sys/dev/sound/pci/hda/hdaa_patches.c Wed Dec 12 08:35:32 2012 (r244144) +++ head/sys/dev/sound/pci/hda/hdaa_patches.c Wed Dec 12 11:44:20 2012 (r244145) @@ -271,7 +271,17 @@ hdac_pin_patch(struct hdaa_widget *w) } /* New patches */ - if (id == HDA_CODEC_AD1986A && + if (id == HDA_CODEC_AD1984A && + subid == LENOVO_X300_SUBVENDOR) { + switch (nid) { + case 17: /* Headphones with redirection */ + patch = "as=1 seq=15"; + break; + case 20: /* Two mics together */ + patch = "as=2 seq=15"; + break; + } + } else if (id == HDA_CODEC_AD1986A && (subid == ASUS_M2NPVMX_SUBVENDOR || subid == ASUS_A8NVMCSM_SUBVENDOR || subid == ASUS_P5PL2_SUBVENDOR)) { @@ -372,6 +382,13 @@ hdaa_widget_patch(struct hdaa_widget *w) HDA_PARAM_AUDIO_WIDGET_CAP_TYPE_SHIFT; w->waspin = 1; } + /* +* Clear "digital" flag from digital mic input, as its signal then goes +* to "analog" mixer and this separation just limits functionaity. +*/ + if (hdaa_codec_id(devinfo) == HDA_CODEC_AD1984A && + w->nid == 23) + w->param.widget_cap &= ~HDA_PARAM_AUDIO_WIDGET_CAP_DIGITAL_MASK; HDA_BOOTVERBOSE( if (w->param.widget_cap != orig) { device_printf(w->devinfo->dev, Modified: head/sys/dev/sound/pci/hda/hdac.h == --- head/sys/dev/sound/pci/hda/hdac.h Wed Dec 12 08:35:32 2012 (r244144) +++ head/sys/dev/sound/pci/hda/hdac.h Wed Dec 12 11:44:20 2012 (r244145) @@ -218,6 +218,7 @@ #define LENOVO_3KN200_SUBVENDORHDA_MODEL_CONSTRUCT(LENOVO, 0x384e) #define LENOVO_B450_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x3a0d) #define LENOVO_TCA55_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x1015) +#define LENOVO_X300_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x20ac) #define LENOVO_ALL_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x) /* Samsung */ ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244146 - in head/sys/dev: ahci ata ata/chipsets
Author: mav Date: Wed Dec 12 11:53:15 2012 New Revision: 244146 URL: http://svnweb.freebsd.org/changeset/base/244146 Log: Add IDs for SATA controllers on AMD Hudson-2 series chipsets. I am not exactly sure about the naming due to lack of specs on AMD site, but it is better to have some identification then none at all. MFC after:1 month Modified: head/sys/dev/ahci/ahci.c head/sys/dev/ata/ata-pci.h head/sys/dev/ata/chipsets/ata-ati.c Modified: head/sys/dev/ahci/ahci.c == --- head/sys/dev/ahci/ahci.cWed Dec 12 11:44:20 2012(r244145) +++ head/sys/dev/ahci/ahci.cWed Dec 12 11:53:15 2012(r244146) @@ -122,6 +122,11 @@ static struct { {0x43931002, 0x00, "ATI IXP700",0}, {0x43941002, 0x00, "ATI IXP800",0}, {0x43951002, 0x00, "ATI IXP800",0}, + {0x78001022, 0x00, "AMD Hudson-2", 0}, + {0x78011022, 0x00, "AMD Hudson-2", 0}, + {0x78021022, 0x00, "AMD Hudson-2", 0}, + {0x78031022, 0x00, "AMD Hudson-2", 0}, + {0x78041022, 0x00, "AMD Hudson-2", 0}, {0x06121b21, 0x00, "ASMedia ASM1061", 0}, {0x26528086, 0x00, "Intel ICH6",AHCI_Q_NOFORCE}, {0x26538086, 0x00, "Intel ICH6M", AHCI_Q_NOFORCE}, Modified: head/sys/dev/ata/ata-pci.h == --- head/sys/dev/ata/ata-pci.h Wed Dec 12 11:44:20 2012(r244145) +++ head/sys/dev/ata/ata-pci.h Wed Dec 12 11:53:15 2012(r244146) @@ -101,6 +101,12 @@ struct ata_pci_controller { #define ATA_AMD768 0x74411022 #define ATA_AMD8111 0x74691022 #define ATA_AMD5536 0x209a1022 +#define ATA_AMD_HUDSON2_S1 0x78001022 +#define ATA_AMD_HUDSON2_S2 0x78011022 +#define ATA_AMD_HUDSON2_S3 0x78021022 +#define ATA_AMD_HUDSON2_S4 0x78031022 +#define ATA_AMD_HUDSON2_S5 0x78041022 +#define ATA_AMD_HUDSON20x780c1022 #define ATA_ADAPTEC_ID 0x9005 #define ATA_ADAPTEC_14200x02419005 Modified: head/sys/dev/ata/chipsets/ata-ati.c == --- head/sys/dev/ata/chipsets/ata-ati.c Wed Dec 12 11:44:20 2012 (r244145) +++ head/sys/dev/ata/chipsets/ata-ati.c Wed Dec 12 11:53:15 2012 (r244146) @@ -91,6 +91,12 @@ ata_ati_probe(device_t dev) { ATA_ATI_IXP700_S4, 0x00, ATI_AHCI, 0, ATA_SA300, "IXP700/800" }, { ATA_ATI_IXP800_S1, 0x00, ATI_AHCI, 0, ATA_SA300, "IXP800" }, { ATA_ATI_IXP800_S2, 0x00, ATI_AHCI, 0, ATA_SA300, "IXP800" }, + { ATA_AMD_HUDSON2, 0x00, ATI_PATA, 0, ATA_UDMA6, "Hudson-2" }, + { ATA_AMD_HUDSON2_S1, 0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" }, + { ATA_AMD_HUDSON2_S2, 0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" }, + { ATA_AMD_HUDSON2_S3, 0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" }, + { ATA_AMD_HUDSON2_S4, 0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" }, + { ATA_AMD_HUDSON2_S5, 0x00, ATI_AHCI, 0, ATA_SA300, "Hudson-2" }, { 0, 0, 0, 0, 0, 0}}; if (pci_get_vendor(dev) != ATA_ATI_ID) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244153 - head/lib/libc/gen
Author: pjd Date: Wed Dec 12 15:27:33 2012 New Revision: 244153 URL: http://svnweb.freebsd.org/changeset/base/244153 Log: Eliminate redundant variable. Modified: head/lib/libc/gen/sysctlbyname.c Modified: head/lib/libc/gen/sysctlbyname.c == --- head/lib/libc/gen/sysctlbyname.cWed Dec 12 13:33:11 2012 (r244152) +++ head/lib/libc/gen/sysctlbyname.cWed Dec 12 15:27:33 2012 (r244153) @@ -19,13 +19,10 @@ sysctlbyname(const char *name, void *old const void *newp, size_t newlen) { int real_oid[CTL_MAXNAME+2]; - int error; size_t oidlen; oidlen = sizeof(real_oid) / sizeof(int); - error = sysctlnametomib(name, real_oid, &oidlen); - if (error < 0) - return (error); - error = sysctl(real_oid, oidlen, oldp, oldlenp, newp, newlen); - return (error); + if (sysctlnametomib(name, real_oid, &oidlen) < 0) + return (-1); + return (sysctl(real_oid, oidlen, oldp, oldlenp, newp, newlen)); } ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244154 - head/bin/ps
Author: pjd Date: Wed Dec 12 15:45:03 2012 New Revision: 244154 URL: http://svnweb.freebsd.org/changeset/base/244154 Log: Use kern.max_pid sysctl to obtain maximum PID number instead of using local define. Reviewed by: jhb Modified: head/bin/ps/ps.c Modified: head/bin/ps/ps.c == --- head/bin/ps/ps.cWed Dec 12 15:27:33 2012(r244153) +++ head/bin/ps/ps.cWed Dec 12 15:45:03 2012(r244154) @@ -109,6 +109,7 @@ static int needcomm; /* -o "command" */ static int needenv; /* -e */ static int needuser; /* -o "user" */ static int optfatal; /* Fatal error parsing some list-option. */ +static int pid_max; /* kern.max_pid */ static enum sort { DEFAULT, SORTMEM, SORTCPU } sortby = DEFAULT; @@ -148,6 +149,7 @@ static int pscomp(const void *, const v static void saveuser(KINFO *); static void scanvars(void); static void sizevars(void); +static void pidmax_init(void); static void usage(void); static char dfmt[] = "pid,tt,state,time,command"; @@ -200,6 +202,8 @@ main(int argc, char *argv[]) if (argc > 1) argv[1] = kludge_oldps_options(PS_ARGS, argv[1], argv[2]); + pidmax_init(); + all = descendancy = _fmt = nselectors = optfatal = 0; prtheader = showthreads = wflag = xkeep_implied = 0; xkeep = -1; /* Neither -x nor -X. */ @@ -722,7 +726,6 @@ addelem_gid(struct listinfo *inf, const return (1); } -#defineBSD_PID_MAX 9 /* Copy of PID_MAX from sys/proc.h. */ static int addelem_pid(struct listinfo *inf, const char *elem) { @@ -740,7 +743,7 @@ addelem_pid(struct listinfo *inf, const if (*endp != '\0' || tempid < 0 || elem == endp) { warnx("Invalid %s: %s", inf->lname, elem); errno = ERANGE; - } else if (errno != 0 || tempid > BSD_PID_MAX) { + } else if (errno != 0 || tempid > pid_max) { warnx("%s too large: %s", inf->lname, elem); errno = ERANGE; } @@ -753,7 +756,6 @@ addelem_pid(struct listinfo *inf, const inf->l.pids[(inf->count)++] = tempid; return (1); } -#undef BSD_PID_MAX /*- * The user can specify a device via one of three formats: @@ -1352,6 +1354,18 @@ kludge_oldps_options(const char *optlist } static void +pidmax_init(void) +{ + size_t intsize; + + intsize = sizeof(pid_max); + if (sysctlbyname("kern.pid_max", &pid_max, &intsize, NULL, 0) < 0) { + warn("unable to read kern.pid_max"); + pid_max = 9; + } +} + +static void usage(void) { #defineSINGLE_OPTS "[-aCcde" OPT_LAZY_f "HhjlmrSTuvwXxZ]" ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244105 - in head/sys: kern sys
On Monday, December 10, 2012 8:23:51 pm Alfred Perlstein wrote: > Author: alfred > Date: Tue Dec 11 01:23:50 2012 > New Revision: 244105 > URL: http://svnweb.freebsd.org/changeset/base/244105 > > Log: > Switch the hardwired WITNESS panics to kassert_panic. > > This is an ongoing effort to provide runtime debug information > useful in the field that does not panic existing installations. > > This gives us the flexibility needed when shipping images to a > potentially large audience with WITNESS enabled without worrying > about formerly non-fatal LORs hurting a release. > > Sponsored by: iXsystems Witness doesn't panic on LORs. These are all bigger violations for things like doing sx_sunlock() on a exclusively locked sx lock. That is not safe and is merely going to result in data corruption and other unpleasantness. This sounds like a very bad idea. Did you talk about this anywhere (I have not caught up on various lists yet, so apologies if this has been discussed.) -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote: > Author: alfred > Date: Tue Dec 11 07:08:14 2012 > New Revision: 244112 > URL: http://svnweb.freebsd.org/changeset/base/244112 > > Log: > Cleanup more of the kassert_panic. > > fix compile warnings on !amd64 and NULL derefs that would happen > if kassert_panic() would return. This is one reason why having kassert not panic is such a bad idea. There are tons of places where the compiler knows that panic() is __dead2, and there is no cleanup code to handle what happens when an invariant is violated. This is not safe to run in the field unless your customers do not care about their data. If you are interested in doing regression tests, I am using a very different approach for some locking regression tests I am working on in p4 that allow you to use a wrapper around setjmp/longjmp to "catch" panics somewhat like exception handling in C++/Java (though much cruder). However, evne that is only intended for testing, not for production cases where production data is at stake. -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244155 - in head/sys/cddl: compat/opensolaris/kern compat/opensolaris/sys contrib/opensolaris/uts/common/fs/zfs contrib/opensolaris/uts/common/fs/zfs/sys
Author: smh Date: Wed Dec 12 16:14:14 2012 New Revision: 244155 URL: http://svnweb.freebsd.org/changeset/base/244155 Log: Renamed zfs trim stats removing duplicate zio_trim identifier from the name Added description option to kstats. Added descriptions for zio_trim kstats PR: kern/173113 Submitted by: Steven Hartland Reviewed by: pjd Approved by: pjd MFC after:2 weeks Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_kstat.c head/sys/cddl/compat/opensolaris/sys/kstat.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c Modified: head/sys/cddl/compat/opensolaris/kern/opensolaris_kstat.c == --- head/sys/cddl/compat/opensolaris/kern/opensolaris_kstat.c Wed Dec 12 15:45:03 2012(r244154) +++ head/sys/cddl/compat/opensolaris/kern/opensolaris_kstat.c Wed Dec 12 16:14:14 2012(r244155) @@ -118,7 +118,7 @@ kstat_install(kstat_t *ksp) SYSCTL_ADD_PROC(&ksp->ks_sysctl_ctx, SYSCTL_CHILDREN(ksp->ks_sysctl_root), OID_AUTO, ksent->name, CTLTYPE_U64 | CTLFLAG_RD, ksent, sizeof(*ksent), - kstat_sysctl, "QU", ""); + kstat_sysctl, "QU", ksent->desc); } } Modified: head/sys/cddl/compat/opensolaris/sys/kstat.h == --- head/sys/cddl/compat/opensolaris/sys/kstat.hWed Dec 12 15:45:03 2012(r244154) +++ head/sys/cddl/compat/opensolaris/sys/kstat.hWed Dec 12 16:14:14 2012(r244155) @@ -53,6 +53,8 @@ typedef struct kstat_named { #defineKSTAT_DATA_INT643 #defineKSTAT_DATA_UINT64 4 uchar_t data_type; +#defineKSTAT_DESCLEN 128 + chardesc[KSTAT_DESCLEN]; union { uint64_tui64; } value; Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h == --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h Wed Dec 12 15:45:03 2012(r244154) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/sys/zio.h Wed Dec 12 16:14:14 2012(r244155) @@ -372,23 +372,23 @@ typedef struct zio_trim_stats { /* * Number of bytes successfully TRIMmed. */ - kstat_named_t zio_trim_bytes; + kstat_named_t bytes; /* * Number of successful TRIM requests. */ - kstat_named_t zio_trim_success; + kstat_named_t success; /* * Number of TRIM requests that failed because TRIM is not * supported. */ - kstat_named_t zio_trim_unsupported; + kstat_named_t unsupported; /* * Number of TRIM requests that failed for other reasons. */ - kstat_named_t zio_trim_failed; + kstat_named_t failed; } zio_trim_stats_t; extern zio_trim_stats_t zio_trim_stats; Modified: head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c == --- head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c Wed Dec 12 15:45:03 2012(r244154) +++ head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zio.c Wed Dec 12 16:14:14 2012(r244155) @@ -48,14 +48,15 @@ TUNABLE_INT("vfs.zfs.zio.exclude_metadat SYSCTL_INT(_vfs_zfs_zio, OID_AUTO, exclude_metadata, CTLFLAG_RDTUN, &zio_exclude_metadata, 0, "Exclude metadata buffers from dumps as well"); -/* - * See zio.h for more information about these fields. - */ zio_trim_stats_t zio_trim_stats = { - { "zio_trim_bytes", KSTAT_DATA_UINT64 }, - { "zio_trim_success", KSTAT_DATA_UINT64 }, - { "zio_trim_unsupported", KSTAT_DATA_UINT64 }, - { "zio_trim_failed",KSTAT_DATA_UINT64 }, + { "bytes", KSTAT_DATA_UINT64, + "Number of bytes successfully TRIMmed" }, + { "success",KSTAT_DATA_UINT64, + "Number of successful TRIM requests" }, + { "unsupported",KSTAT_DATA_UINT64, + "Number of TRIM requests that failed because TRIM is not supported" }, + { "failed", KSTAT_DATA_UINT64, + "Number of TRIM requests that failed for reasons other than not supported" }, }; static kstat_t *zio_trim_ksp; @@ -2660,14 +2661,14 @@ zio_vdev_io_assess(zio_t *zio) if (zio->io_type == ZIO_TYPE_IOCTL && zio->io_cmd == DKIOCTRIM) switch (zio->io_error) { case 0: - ZIO_TRIM_STAT_INCR(zio_trim_bytes, zio->io_size); - ZIO_TRIM_STAT_BUMP(zio_trim_success); + ZIO_TRIM_STAT_INCR(bytes, zio->io_size); +
Re: svn commit: r244154 - head/bin/ps
On 12 December 2012 10:45, Pawel Jakub Dawidek wrote: > + if (sysctlbyname("kern.pid_max", &pid_max, &intsize, NULL, 0) < 0) { > + warn("unable to read kern.pid_max"); Silly question, when could this fail and not be fatal? > + pid_max = 9; Why not use PID_MAX from sys/proc.h? -- Eitan Adler Source, Ports, Doc committer Bugmeister, Ports Security teams ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244154 - head/bin/ps
On Wed, Dec 12, 2012 at 11:37:00AM -0500, Eitan Adler wrote: > On 12 December 2012 10:45, Pawel Jakub Dawidek wrote: > > > + if (sysctlbyname("kern.pid_max", &pid_max, &intsize, NULL, 0) < 0) { > > + warn("unable to read kern.pid_max"); > > Silly question, when could this fail and not be fatal? It isn't fatal, we can easly make some assumptions instead of turning ps(1) unusable. Currently it will be hard to make it fail, which doesn't mean we shouldn't handle this case. Some day it might fail for some reason (someone changed sysctl name?). > > + pid_max = 9; > > Why not use PID_MAX from sys/proc.h? Because we are in userland and PID_MAX is only defined for the kernel. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgppOFYrdKMf4.pgp Description: PGP signature
svn commit: r244156 - head/share/misc
Author: smh Date: Wed Dec 12 16:59:07 2012 New Revision: 244156 URL: http://svnweb.freebsd.org/changeset/base/244156 Log: Add myself as a new src committer Approved by: pjd (mentor) Modified: head/share/misc/committers-src.dot Modified: head/share/misc/committers-src.dot == --- head/share/misc/committers-src.dot Wed Dec 12 16:14:14 2012 (r244155) +++ head/share/misc/committers-src.dot Wed Dec 12 16:59:07 2012 (r244156) @@ -249,6 +249,7 @@ sephe [label="Sepherosa Ziehau\nsephe@Fr sepotvin [label="Stephane E. Potvin\nsepot...@freebsd.org\n2007/02/15"] simon [label="Simon L. Nielsen\nsi...@freebsd.org\n2006/03/07"] sjg [label="Simon J. Gerraty\n...@freebsd.org\n2012/10/23"] +smh [label="Steven Hartland\s...@freebsd.org\n2012/11/12"] sobomax [label="Maxim Sobolev\nsobo...@freebsd.org\n2001/07/25"] sos [label="Soren Schmidt\n...@freebsd.org\n/??/??"] sson [label="Stacey Son\ns...@freebsd.org\n2008/07/08"] @@ -307,6 +308,7 @@ anholt -> jkim avg -> art avg -> pluknet +avg -> smh benno -> grehan @@ -555,6 +557,7 @@ philip -> uqs pjd -> kib pjd -> lulf +pjd -> smh pjd -> trociny rgrimes -> markm ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
kassert()s are already optional. Ie, you can choose to not compile them in. So the __dead2() code path bit for doing KASSERT() -> kassert_panic() at compile time isn't a problem. The problem is where you do panic() -> kassert_panic() (eg in the Witness code) which is what Alfred discovered shortly after doing up his initial patch. Anything which is a KASSERT() can and should be treated as a run-time warning just as much as a run-time "crash here so I can figure out what broke." Having the warning in a production box is going to be helpful for developers. Adrian On 12 December 2012 07:46, John Baldwin wrote: > On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote: >> Author: alfred >> Date: Tue Dec 11 07:08:14 2012 >> New Revision: 244112 >> URL: http://svnweb.freebsd.org/changeset/base/244112 >> >> Log: >> Cleanup more of the kassert_panic. >> >> fix compile warnings on !amd64 and NULL derefs that would happen >> if kassert_panic() would return. > > This is one reason why having kassert not panic is such a bad idea. There are > tons of places where the compiler knows that panic() is __dead2, and there is > no cleanup code to handle what happens when an invariant is violated. This is > not safe to run in the field unless your customers do not care about their > data. If you are interested in doing regression tests, I am using a very > different approach for some locking regression tests I am working on in p4 > that allow you to use a wrapper around setjmp/longjmp to "catch" panics > somewhat like exception handling in C++/Java (though much cruder). However, > evne that is only intended for testing, not for production cases where > production data is at stake. > > -- > John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244157 - head/sys/netinet
Author: glebius Date: Wed Dec 12 17:41:21 2012 New Revision: 244157 URL: http://svnweb.freebsd.org/changeset/base/244157 Log: Fix a crash in tcp_input(), that happens when mbuf has a fwd_tag on it, but later after processing and freeing the tag, we need to jump back again to the findpcb label. Since the fwd_tag pointer wasn't NULL we tried to process and free the tag for second time. Reported & tested by: Pawel Tyll MFC after:3 days Modified: head/sys/netinet/tcp_input.c Modified: head/sys/netinet/tcp_input.c == --- head/sys/netinet/tcp_input.cWed Dec 12 16:59:07 2012 (r244156) +++ head/sys/netinet/tcp_input.cWed Dec 12 17:41:21 2012 (r244157) @@ -810,6 +810,7 @@ findpcb: /* Remove the tag from the packet. We don't need it anymore. */ m_tag_delete(m, fwd_tag); m->m_flags &= ~M_IP_NEXTHOP; + fwd_tag = NULL; } else if (isipv6) { inp = in6_pcblookup_mbuf(&V_tcbinfo, &ip6->ip6_src, th->th_sport, &ip6->ip6_dst, th->th_dport, @@ -847,6 +848,7 @@ findpcb: /* Remove the tag from the packet. We don't need it anymore. */ m_tag_delete(m, fwd_tag); m->m_flags &= ~M_IP_NEXTHOP; + fwd_tag = NULL; } else inp = in_pcblookup_mbuf(&V_tcbinfo, ip->ip_src, th->th_sport, ip->ip_dst, th->th_dport, ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244158 - head/sys/boot/forth
Author: dteske Date: Wed Dec 12 17:49:01 2012 New Revision: 244158 URL: http://svnweb.freebsd.org/changeset/base/244158 Log: Fix a regression caused by SVN r222417. Prior to r222417, setting `password' in loader.conf(5) did not prevent boot but instead only prevented changes to boot options by prompting for password if autoboot failed or the user interrupted the countdown sequence. After r222417 the same machine with `password' set in loader.conf(5) would no longer boot without _always_ entering the password. This patch restores the old (8.x and older) functionality for password in loader.conf(5) while adding a new bootlock_password feature to replace the edge-case should anybody desire the regressed functionality (HINT: great for PXE servers and/or private distributions). loader.conf(5) was updated to be more clear with-respect to password setting (previous text was misleading). Documentation (loader.conf(5) and check-password.4th(8)) has been updated to include notes on the new bootlock_password setting. Special thanks to Alex Verbod for bringing this to my attention and helping to refine the loader.conf(5) text. PR: conf/170110 Submitted by: Vitaly Zakharov Reviewed by: Alexander Verbod Modified: head/sys/boot/forth/beastie.4th.8 head/sys/boot/forth/check-password.4th head/sys/boot/forth/check-password.4th.8 head/sys/boot/forth/loader.4th.8 head/sys/boot/forth/loader.conf.5 head/sys/boot/forth/menu.4th.8 Modified: head/sys/boot/forth/beastie.4th.8 == --- head/sys/boot/forth/beastie.4th.8 Wed Dec 12 17:41:21 2012 (r244157) +++ head/sys/boot/forth/beastie.4th.8 Wed Dec 12 17:49:01 2012 (r244158) @@ -1,4 +1,4 @@ -.\" Copyright (c) 2011 Devin Teske +.\" Copyright (c) 2011-2012 Devin Teske .\" All rights reserved. .\" .\" Redistribution and use in source and binary forms, with or without @@ -94,8 +94,9 @@ The variable can be configured in .Xr loader.conf 5 to the number of seconds you would like to delay loading the boot menu. -During the delay the user can press Ctrl-C to fall back to autoboot or ENTER -to proceed. +During the delay the user can press Ctrl-C to fall back to +.Ic autoboot +or ENTER to proceed. The default behavior is to not delay. .El .Pp Modified: head/sys/boot/forth/check-password.4th == --- head/sys/boot/forth/check-password.4th Wed Dec 12 17:41:21 2012 (r244157) +++ head/sys/boot/forth/check-password.4th Wed Dec 12 17:49:01 2012 (r244158) @@ -1,4 +1,4 @@ -\ Copyright (c) 2006-2011 Devin Teske +\ Copyright (c) 2006-2012 Devin Teske \ All rights reserved. \ \ Redistribution and use in source and binary forms, with or without @@ -74,7 +74,7 @@ variable readlen\ input length again ; -: read ( -- String prompt ) +: read ( String prompt -- ) 0 25 at-xy \ Move the cursor to the bottom-left dup 1+ read-start ! \ Store X offset after the prompt @@ -134,23 +134,37 @@ variable readlen\ input length : check-password ( -- ) - \ Exit if a password was not set - s" password" getenv dup -1 = if - drop exit + \ Do not allow the user to proceed beyond this point if a boot-lock + \ password has been set (preventing even boot from proceeding) + s" bootlock_password" getenv dup -1 <> if + begin + s" Boot Password: " read ( prompt -- ) + 2dup readval readlen @ compare 0<> + while + 3000 ms ." loader: incorrect password" 10 emit + repeat + 2drop ( c-addr/u ) + else + drop ( -1 ) \ getenv cruft then - begin \ Loop as long as it takes to get the right password + \ Exit if a password was not set + s" password" getenv -1 = if exit else drop then + + \ We should prevent the user from visiting the menu or dropping to the + \ interactive loader(8) prompt, but still allow the machine to boot... - s" Password: " \ Output a prompt for a password - read \ Read the user's input until Enter + 0 autoboot + \ Only reached if autoboot fails for any reason (including if/when + \ the user aborts/escapes the countdown sequence leading to boot). + + s" password" getenv + begin + s" Password: " read ( prompt -- ) 2dup readval readlen @ compare 0= if 2drop exit \ Correct password then - - \ Bad Password - 3000 ms - ." loader: incorrect password" 10 emit - - again \ Not the right password; repeat + 3000 ms ." loader: incorrect password" 10 emit + again ;
Re: svn commit: r244112 - head/sys/kern
to all: I am trying to take this offline with John so that we can discuss the reasoning behind the change and come to an agreement on how it is implemented, or if not to remove it. -Alfred On 12/12/12 7:46 AM, John Baldwin wrote: On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote: Author: alfred Date: Tue Dec 11 07:08:14 2012 New Revision: 244112 URL: http://svnweb.freebsd.org/changeset/base/244112 Log: Cleanup more of the kassert_panic. fix compile warnings on !amd64 and NULL derefs that would happen if kassert_panic() would return. This is one reason why having kassert not panic is such a bad idea. There are tons of places where the compiler knows that panic() is __dead2, and there is no cleanup code to handle what happens when an invariant is violated. This is not safe to run in the field unless your customers do not care about their data. If you are interested in doing regression tests, I am using a very different approach for some locking regression tests I am working on in p4 that allow you to use a wrapper around setjmp/longjmp to "catch" panics somewhat like exception handling in C++/Java (though much cruder). However, evne that is only intended for testing, not for production cases where production data is at stake. ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244154 - head/bin/ps
On Wed, Dec 12, 2012 at 03:45:04PM +, Pawel Jakub Dawidek wrote: > Author: pjd > Date: Wed Dec 12 15:45:03 2012 > New Revision: 244154 > URL: http://svnweb.freebsd.org/changeset/base/244154 > > Log: > Use kern.max_pid sysctl to obtain maximum PID number instead of using local > define. It is pid_max, not max_pid. But the change is wrong. The kern.pid_max only limits newly allocated pids, it does not magically moves existing pids, which are out of range, to the limited region. See the corresponding commit log for the description. It was added to make it easier to run FreeBSD 1.x binaries on the modern kernels. pgpG4ptvoWqmK.pgp Description: PGP signature
svn commit: r244162 - in head: bin/sh tools/regression/bin/sh/errors
Author: jilles Date: Wed Dec 12 22:01:10 2012 New Revision: 244162 URL: http://svnweb.freebsd.org/changeset/base/244162 Log: sh: Detect and flag write errors on stdout in builtins. If there is a write error on stdout, a message will be printed (to stderr) and the exit status will be changed to 2 if it would have been 0 or 1. PR: bin/158206 Added: head/tools/regression/bin/sh/errors/write-error1.0 (contents, props changed) Modified: head/bin/sh/eval.c head/bin/sh/output.c head/bin/sh/output.h Modified: head/bin/sh/eval.c == --- head/bin/sh/eval.c Wed Dec 12 20:55:30 2012(r244161) +++ head/bin/sh/eval.c Wed Dec 12 22:01:10 2012(r244162) @@ -1070,6 +1070,7 @@ evalcommand(union node *cmd, int flags, } handler = &jmploc; redirect(cmd->ncmd.redirect, mode); + outclearerror(out1); /* * If there is no command word, redirection errors should * not be fatal but assignment errors should. @@ -1085,6 +1086,11 @@ evalcommand(union node *cmd, int flags, builtin_flags = flags; exitstatus = (*builtinfunc[cmdentry.u.index])(argc, argv); flushall(); + if (outiserror(out1)) { + warning("write error on stdout"); + if (exitstatus == 0 || exitstatus == 1) + exitstatus = 2; + } cmddone: if (argc > 0) bltinunsetlocale(); Modified: head/bin/sh/output.c == --- head/bin/sh/output.cWed Dec 12 20:55:30 2012(r244161) +++ head/bin/sh/output.cWed Dec 12 22:01:10 2012(r244162) @@ -239,6 +239,20 @@ freestdout(void) } +int +outiserror(struct output *file) +{ + return (file->flags & OUTPUT_ERR); +} + + +void +outclearerror(struct output *file) +{ + file->flags &= ~OUTPUT_ERR; +} + + void outfmt(struct output *file, const char *fmt, ...) { Modified: head/bin/sh/output.h == --- head/bin/sh/output.hWed Dec 12 20:55:30 2012(r244161) +++ head/bin/sh/output.hWed Dec 12 22:01:10 2012(r244162) @@ -66,6 +66,8 @@ void emptyoutbuf(struct output *); void flushall(void); void flushout(struct output *); void freestdout(void); +int outiserror(struct output *); +void outclearerror(struct output *); void outfmt(struct output *, const char *, ...) __printflike(2, 3); void out1fmt(const char *, ...) __printflike(1, 2); void out2fmt_flush(const char *, ...) __printflike(1, 2); Added: head/tools/regression/bin/sh/errors/write-error1.0 == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/tools/regression/bin/sh/errors/write-error1.0 Wed Dec 12 22:01:10 2012(r244162) @@ -0,0 +1,3 @@ +# $FreeBSD$ + +! echo >&- 2>/dev/null ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On Wednesday, December 12, 2012 12:06:22 pm Adrian Chadd wrote: > kassert()s are already optional. Ie, you can choose to not compile them in. > > So the __dead2() code path bit for doing KASSERT() -> kassert_panic() > at compile time isn't a problem. > > The problem is where you do panic() -> kassert_panic() (eg in the > Witness code) which is what Alfred discovered shortly after doing up > his initial patch. > > Anything which is a KASSERT() can and should be treated as a run-time > warning just as much as a run-time "crash here so I can figure out > what broke." Having the warning in a production box is going to be > helpful for developers. Hmmm, I'll have to chew on this. Adding lots of returns because panic's are now no longer dead2 was why I ended up backing the removal of the RESTARTABLE_PANICS option. I'm inclined to say that it's really bad to let a kernel known to be in a bad state continue, and that if someone has asked for the slowdown of all the extra checks INVARIANTS adds, they might as well minimize the chance for data corruption by having the kernel stop as soon as a problem is detected. (Note that the primary reason I know for people not running with INVARIANTS enabled is not that they don't want panics, but that they don't want the performance hit.) -- John Baldwin ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12 December 2012 13:58, John Baldwin wrote: >> Anything which is a KASSERT() can and should be treated as a run-time >> warning just as much as a run-time "crash here so I can figure out >> what broke." Having the warning in a production box is going to be >> helpful for developers. > > Hmmm, I'll have to chew on this. Adding lots of returns because panic's are > now no longer dead2 was why I ended up backing the removal of the > RESTARTABLE_PANICS option. Yes, for panic() as it stands it should just do that - panic. We should likely go over the panic()s and replace them with kassert+handle gracefully wherever its appropriate (there are a few places in net80211 for example that I'd like to do this.) But you're right. For panic(), the rest of the code likely doesn't handle or continue gracefully, so we shouldn't automatically disable them. But this is about KASSERT(). Alfred mixed this in with witness "non panic" mode, which I think is what's confusing people. > I'm inclined to say that it's really bad to let a kernel known to be in a > bad state continue, and that if someone has asked for the slowdown of all > the extra checks INVARIANTS adds, they might as well minimize the chance for > data corruption by having the kernel stop as soon as a problem is detected. Right, but that should be an option. It'd be nice if we were able to dump out some system state when an invariant condition or witness issue was hit (like a mini scripted ddb dump - say, log things like the current lock state) but then continue. > (Note that the primary reason I know for people not running with INVARIANTS > enabled is not that they don't want panics, but that they don't want the > performance hit.) Well, it would be nice to be able to enable invariants on some shipping "debug" versions of images in order to gather more data without crashing the kernel. Adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244163 - head/share/misc
Author: jimharris Date: Wed Dec 12 22:25:31 2012 New Revision: 244163 URL: http://svnweb.freebsd.org/changeset/base/244163 Log: Add my ex-mentors. Modified: head/share/misc/committers-src.dot Modified: head/share/misc/committers-src.dot == --- head/share/misc/committers-src.dot Wed Dec 12 22:01:10 2012 (r244162) +++ head/share/misc/committers-src.dot Wed Dec 12 22:25:31 2012 (r244163) @@ -241,6 +241,7 @@ rstone [label="Ryan Stone\nrstone@FreeBS ru [label="Ruslan Ermilov\n...@freebsd.org\n1999/05/27"] rwatson [label="Robert N. M. Watson\nrwat...@freebsd.org\n1999/12/16"] sam [label="Sam Leffler\n...@freebsd.org\n2002/07/02"] +sbruno [label="Sean Bruno\nsbr...@freebsd.org\n/??/??"] sanpei [label="MIHIRA Sanpei Yoshiro\nsan...@freebsd.org\n2000/06/19"] scf [label="Sean C. Farley\n...@freebsd.org\n2007/06/24"] schweikh [label="Jens Schweikhardt\nschwe...@freebsd.org\n2001/04/06"] @@ -602,8 +603,11 @@ sam -> andre sam -> benjsc sam -> sephe +sbruno -> jimharris + schweikh -> dds +scottl -> jimharris scottl -> pjd scottl -> sah scottl -> yongari ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12/12/12 2:15 PM, Adrian Chadd wrote: On 12 December 2012 13:58, John Baldwin wrote: (Note that the primary reason I know for people not running with INVARIANTS enabled is not that they don't want panics, but that they don't want the performance hit.) Well, it would be nice to be able to enable invariants on some shipping "debug" versions of images in order to gather more data without crashing the kernel. Yes, two of my employers were more of "we want to get more debug metrics, we have the spare cycles, but we can't deal with superfluous panics". It also allows us "non-architects" to slip in a debug image when we have spare cpu without getting yelled at for "crashing the $foo". -Alfred ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
on 12/12/2012 23:58 John Baldwin said the following: > Hmmm, I'll have to chew on this. Adding lots of returns because panic's are > now no longer dead2 was why I ended up backing the removal of the > RESTARTABLE_PANICS option. > > I'm inclined to say that it's really bad to let a kernel known to be in a > bad state continue, and that if someone has asked for the slowdown of all > the extra checks INVARIANTS adds, they might as well minimize the chance for > data corruption by having the kernel stop as soon as a problem is detected. > > (Note that the primary reason I know for people not running with INVARIANTS > enabled is not that they don't want panics, but that they don't want the > performance hit.) Previously we had two alternatives: - use INVARIANTS and be sure that the kernel is in sane state, that any bugs are caught early, no corruptions / insanity is propagated to the point where valuable data can be hurt; the price is lower (possibly much lower) performance because of all other checks; - do not use INVARIANTS and risk that some error would not be caught early and would cause greater harm; the upside is better performance; So people used (use) INVARIANTS to extensively test any new code/environments, but then prefer to run production systems without INVARIANTS. Now we get a new middle-ground: get both worse performance (because KASSERTs are compiled in) and a risk of harming your data (because KASSERTs no longer panic). The upside: there is no panic! There's just a log message (or etc). and chance to get more log messages because the insanity propagates. And a chance to lose your data (your customer's) - but I've already mentioned this. I am not sure that I like this kind of middle-ground. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
on 13/12/2012 00:27 Alfred Perlstein said the following: > On 12/12/12 2:15 PM, Adrian Chadd wrote: >> On 12 December 2012 13:58, John Baldwin wrote: >> >> >>> (Note that the primary reason I know for people not running with INVARIANTS >>> enabled is not that they don't want panics, but that they don't want the >>> performance hit.) >> Well, it would be nice to be able to enable invariants on some >> shipping "debug" versions of images in order to gather more data >> without crashing the kernel. > Yes, two of my employers were more of "we want to get more debug metrics, we > have the spare cycles, but we can't deal with superfluous panics". > > It also allows us "non-architects" to slip in a debug image when we have spare > cpu without getting yelled at for "crashing the $foo". There is clearly something wrong with this sort of mentality. If you find instances where a developer put panic(9) (or KASSERT or etc) to mean "maybe here is a bug, let's just panic", then let's get those things fixed. But most of assertions in our code that are know to me really mean that a real bug has already occurred, that portions of kernel state are corrupted and there is no going back to a sane state, only going forward to corrupting more and more. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
on 12/12/2012 19:06 Adrian Chadd said the following: > kassert()s are already optional. Ie, you can choose to not compile them in. > > So the __dead2() code path bit for doing KASSERT() -> kassert_panic() > at compile time isn't a problem. > > The problem is where you do panic() -> kassert_panic() (eg in the > Witness code) which is what Alfred discovered shortly after doing up > his initial patch. > > Anything which is a KASSERT() can and should be treated as a run-time > warning just as much as a run-time "crash here so I can figure out > what broke." Having the warning in a production box is going to be > helpful for developers. I have a quite different view on purpose and costs of KASSERTs. Specifically referring to r243980 I do not think that "non-fatal asserts" should really exist (or do exist). I wish all this muddying of KASSERT meaning would get reverted. These quite sensitive changes were rushed in, IMO. > On 12 December 2012 07:46, John Baldwin wrote: >> On Tuesday, December 11, 2012 2:08:14 am Alfred Perlstein wrote: >>> Author: alfred >>> Date: Tue Dec 11 07:08:14 2012 >>> New Revision: 244112 >>> URL: http://svnweb.freebsd.org/changeset/base/244112 >>> >>> Log: >>> Cleanup more of the kassert_panic. >>> >>> fix compile warnings on !amd64 and NULL derefs that would happen >>> if kassert_panic() would return. >> >> This is one reason why having kassert not panic is such a bad idea. There >> are >> tons of places where the compiler knows that panic() is __dead2, and there is >> no cleanup code to handle what happens when an invariant is violated. This >> is >> not safe to run in the field unless your customers do not care about their >> data. If you are interested in doing regression tests, I am using a very >> different approach for some locking regression tests I am working on in p4 >> that allow you to use a wrapper around setjmp/longjmp to "catch" panics >> somewhat like exception handling in C++/Java (though much cruder). However, >> evne that is only intended for testing, not for production cases where >> production data is at stake. >> >> -- >> John Baldwin -- Andriy Gapon -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
There are two parts to this; * don't compile in invariants. Panics panic. Invariant conditions aren't checked. You end up with data corruption still if there are bugs. * compile in invariants. Panics panic. Invariant conditions are checked and immediately panic. You can't run this in production to get debugging info because our debugging info is "create a crash dump and reboot." Now, the crash dump is great for us developers. But crap for say, a file server. If it's some very subtle issue that only occasionally pops up once a week and doesn't obviously screw with your data: * you can enable invariants and get a crash dump each time - then us developers get lots of information, but the user experiences outages once a week; * they just give the hell up, disable invariants in production and occasionally hit odd issues they can't explain. So now there's a third option: * enable invariants, get told when you hit that condition, and continue running. Now, we ship _right now_ generic with INVARIANTS disabled, because in theory the releases are supposed to be stable enough for us not to need the extra debugging information. That means that for those very occasional, very subtle bugs that invariants may catch, we don't have any way of getting told about them. Now, enabling some alternative to panic() is a different story and not what's being addressed here. HTH, Adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12 December 2012 14:33, Andriy Gapon wrote: >> Yes, two of my employers were more of "we want to get more debug metrics, we >> have the spare cycles, but we can't deal with superfluous panics". >> >> It also allows us "non-architects" to slip in a debug image when we have >> spare >> cpu without getting yelled at for "crashing the $foo". > > There is clearly something wrong with this sort of mentality. > > If you find instances where a developer put panic(9) (or KASSERT or etc) to > mean > "maybe here is a bug, let's just panic", then let's get those things fixed. > > But most of assertions in our code that are know to me really mean that a real > bug has already occurred, that portions of kernel state are corrupted and > there > is no going back to a sane state, only going forward to corrupting more and > more. Dude, if you're running -STABLE right now, you don't have invariants enabled and you aren't checking for them. So right now, as it stands, large swaths of our kernel code are falling afoul of what you're calling Alfred out on. Before you all reply, please review and understand the difference between "panic()" and "KASSERT()". panic() is not being changed here. KASSERT() is what's being changed here. panic() is not optional. KASSERT() is. With a non-INVARIANTS kernel, we _are not checking invariants_ and we are continuing to run _after_ said non-compiled-in invariants. With this in mind, please re-review this. :-) Adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12/12/12 2:29 PM, Andriy Gapon wrote: Now we get a new middle-ground: get both worse performance (because KASSERTs are compiled in) and a risk of harming your data (because KASSERTs no longer panic). The upside: there is no panic! There's just a log message (or etc). and chance to get more log messages because the insanity propagates. And a chance to lose your data (your customer's) - but I've already mentioned this. I am not sure that I like this kind of middle-ground. I have a number of points here: The most important one being: 1) without kassert you would still have the bug, just that it would be unreported. The upside: there is no panic! There's **NO** log message (or etc). and chance to get more log messages because the insanity propagates. Terrible! Let me explain that again: If you don't compile in KASSERT, then it's not like the condition is never going to happen. Instead it will just be unreported. So to put it in your own words, *without* KASSERT you get: The upside: there is no panic! There's **NO** log message (or etc). and chance to get more log messages because the insanity propagates. Now let's get to the other points: 2) Since this is not the default, then I do not understand why you are so concerned. 3) Can you explain to me why it is so upsetting to you that someone might be able to use this functionality? 4) *puts on flame retardant suit* ... Linux has had this for over a decade and it's allowed them to find bugs in different ways. Mind you, in Linux it was the default. 5) Adrian and I have both stated that we need this sort of functionality to avoid superfluous panics in our work environments while still getting bug feedback. Can we now please stop arguing over a non-default option that will help some vendors report bugs to the project? Thank you, -Alfred ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12/12/12 2:38 PM, Adrian Chadd wrote: There are two parts to this; * don't compile in invariants. Panics panic. Invariant conditions aren't checked. You end up with data corruption still if there are bugs. * compile in invariants. Panics panic. Invariant conditions are checked and immediately panic. You can't run this in production to get debugging info because our debugging info is "create a crash dump and reboot." Now, the crash dump is great for us developers. But crap for say, a file server. If it's some very subtle issue that only occasionally pops up once a week and doesn't obviously screw with your data: * you can enable invariants and get a crash dump each time - then us developers get lots of information, but the user experiences outages once a week; * they just give the hell up, disable invariants in production and occasionally hit odd issues they can't explain. So now there's a third option: * enable invariants, get told when you hit that condition, and continue running. Now, we ship _right now_ generic with INVARIANTS disabled, because in theory the releases are supposed to be stable enough for us not to need the extra debugging information. That means that for those very occasional, very subtle bugs that invariants may catch, we don't have any way of getting told about them. Now, enabling some alternative to panic() is a different story and not what's being addressed here. HTH, Yes. -Alfred ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12/12/12 14:48, Alfred Perlstein wrote: > On 12/12/12 2:29 PM, Andriy Gapon wrote: >> Now we get a new middle-ground: get both worse performance (because >> KASSERTs are compiled in) and a risk of harming your data (because >> KASSERTs no longer panic). The upside: there is no panic! There's just >> a log message (or etc). and chance to get more log messages because >> the insanity propagates. And a chance to lose your data (your >> customer's) - but I've already mentioned this. I am not sure that I >> like this kind of middle-ground. > I have a number of points here: > > The most important one being: > 1) without kassert you would still have the bug, just that it would be > unreported. > The upside: there is no panic! There's **NO** log message (or etc). > and chance to get more log messages because the insanity propagates. > > Terrible! > > Let me explain that again: > If you don't compile in KASSERT, then it's not like the condition is > never going to happen. Instead it will just be unreported. A KASSERT() really is for a condition that should never happen. It is primarily useful during development and testing (and when the code is reworked or redesigned). I agree with Andriy here -- a non-fatal assert shouldn't really exist. Why not add a new facility (a "if (!foo) kdb_backtrace()" or similar), call it what you want to, enable it (or not) even in release builds if you want to, use it wherever you want to, but let KASSERT be just the way it is? Adding a global knob that changes the way KASSERT behaves risks tripping others up. Personally, in a debug kernel I _really_ want the kernel to stop right away if any KASSERT in my code goes off so that its state is as close as possible to what it was at the time the problem occurred. In a release kernel I _really_ do not want the overhead of the KASSERT at all. If it was a check for a condition I wasn't sure about then I wouldn't have written it as a KASSERT. That's my 2 cents in case you plan to revisit your changes and were looking around for inputs... ;-) Regards, Navdeep > > So to put it in your own words, *without* KASSERT you get: > > The upside: there is no panic! There's **NO** log message (or etc). > and chance to get more log messages because the insanity propagates. > > > > Now let's get to the other points: > > 2) Since this is not the default, then I do not understand why you are > so concerned. > > 3) Can you explain to me why it is so upsetting to you that someone > might be able to use this functionality? > > 4) *puts on flame retardant suit* ... Linux has had this for over a > decade and it's allowed them to find bugs in different ways. Mind you, > in Linux it was the default. > > 5) Adrian and I have both stated that we need this sort of functionality > to avoid superfluous panics in our work environments while still getting > bug feedback. > > Can we now please stop arguing over a non-default option that will help > some vendors report bugs to the project? > > Thank you, > -Alfred > ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12/12/12 4:02 PM, Navdeep Parhar wrote: On 12/12/12 14:48, Alfred Perlstein wrote: On 12/12/12 2:29 PM, Andriy Gapon wrote: Now we get a new middle-ground: get both worse performance (because KASSERTs are compiled in) and a risk of harming your data (because KASSERTs no longer panic). The upside: there is no panic! There's just a log message (or etc). and chance to get more log messages because the insanity propagates. And a chance to lose your data (your customer's) - but I've already mentioned this. I am not sure that I like this kind of middle-ground. I have a number of points here: The most important one being: 1) without kassert you would still have the bug, just that it would be unreported. The upside: there is no panic! There's **NO** log message (or etc). and chance to get more log messages because the insanity propagates. Terrible! Let me explain that again: If you don't compile in KASSERT, then it's not like the condition is never going to happen. Instead it will just be unreported. A KASSERT() really is for a condition that should never happen. It is primarily useful during development and testing (and when the code is reworked or redesigned). I agree with Andriy here -- a non-fatal assert shouldn't really exist. What do you think happens to a FreeBSD kernel when INVARIANTS is compiled in and it trips an assertion after my change? -Alfred ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12/12/12 16:09, Alfred Perlstein wrote: > On 12/12/12 4:02 PM, Navdeep Parhar wrote: >> On 12/12/12 14:48, Alfred Perlstein wrote: >>> On 12/12/12 2:29 PM, Andriy Gapon wrote: Now we get a new middle-ground: get both worse performance (because KASSERTs are compiled in) and a risk of harming your data (because KASSERTs no longer panic). The upside: there is no panic! There's just a log message (or etc). and chance to get more log messages because the insanity propagates. And a chance to lose your data (your customer's) - but I've already mentioned this. I am not sure that I like this kind of middle-ground. >>> I have a number of points here: >>> >>> The most important one being: >>> 1) without kassert you would still have the bug, just that it would be >>> unreported. >>>The upside: there is no panic! There's **NO** log message (or etc). >>> and chance to get more log messages because the insanity propagates. >>> >>> Terrible! >>> >>> Let me explain that again: >>> If you don't compile in KASSERT, then it's not like the condition is >>> never going to happen. Instead it will just be unreported. >> A KASSERT() really is for a condition that should never happen. It is >> primarily useful during development and testing (and when the code is >> reworked or redesigned). I agree with Andriy here -- a non-fatal assert >> shouldn't really exist. > > > What do you think happens to a FreeBSD kernel when INVARIANTS is > compiled in and it trips an assertion after my change? I know the new knob has sane defaults. My point was that invariants should be considered inviolable. A knob that allows for it's-really-not-supposed-to-fail-but-in-case-it-does... dilutes their meaning, so it may have been better to introduce a new macro for the kind of tests you had in mind. I would use it too instead of the if (!foo) kdb_backtrace() that I often resort to for conditions that I'm not sure about. Regards, Navdeep ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
If a kassert is inviolable, then make it a panic() and include in the default kernel. Right now there's no distinction between "kassert for a condition that shouldn't happen, but we fail gracefully" and "kassert for a condition that shouldn't happen, and we don't handle at all." Ideally we'd create two separate macros to express that, t.hen we should make all kassert's that don't fail gracefully to fail gracefully. Anything left over should've been a panic() in the first place. Right now, with no INVARIANTS compiled in, we don't check KASSERT(). Again, the difference between panic and KASSERT. TL;DR - we're doing panic/assert sub-optimally; we don't have a consistent definition of what an invariant check is; Alfred's work doesn't change that. Adrian On 12 December 2012 16:25, Navdeep Parhar wrote: > On 12/12/12 16:09, Alfred Perlstein wrote: >> On 12/12/12 4:02 PM, Navdeep Parhar wrote: >>> On 12/12/12 14:48, Alfred Perlstein wrote: On 12/12/12 2:29 PM, Andriy Gapon wrote: > Now we get a new middle-ground: get both worse performance (because > KASSERTs are compiled in) and a risk of harming your data (because > KASSERTs no longer panic). The upside: there is no panic! There's just > a log message (or etc). and chance to get more log messages because > the insanity propagates. And a chance to lose your data (your > customer's) - but I've already mentioned this. I am not sure that I > like this kind of middle-ground. I have a number of points here: The most important one being: 1) without kassert you would still have the bug, just that it would be unreported. The upside: there is no panic! There's **NO** log message (or etc). and chance to get more log messages because the insanity propagates. Terrible! Let me explain that again: If you don't compile in KASSERT, then it's not like the condition is never going to happen. Instead it will just be unreported. >>> A KASSERT() really is for a condition that should never happen. It is >>> primarily useful during development and testing (and when the code is >>> reworked or redesigned). I agree with Andriy here -- a non-fatal assert >>> shouldn't really exist. >> >> >> What do you think happens to a FreeBSD kernel when INVARIANTS is >> compiled in and it trips an assertion after my change? > > I know the new knob has sane defaults. My point was that invariants > should be considered inviolable. A knob that allows for > it's-really-not-supposed-to-fail-but-in-case-it-does... dilutes their > meaning, so it may have been better to introduce a new macro for the > kind of tests you had in mind. I would use it too instead of the if > (!foo) kdb_backtrace() that I often resort to for conditions that I'm > not sure about. > > Regards, > Navdeep ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244164 - head/share/syscons/keymaps
Author: eadler Date: Thu Dec 13 00:44:23 2012 New Revision: 244164 URL: http://svnweb.freebsd.org/changeset/base/244164 Log: Give credit where credit is due. Requested by: Álvaro Castillo Approved by: cperciva (implicit) Modified: head/share/syscons/keymaps/spanish.dvorak.kbd Modified: head/share/syscons/keymaps/spanish.dvorak.kbd == --- head/share/syscons/keymaps/spanish.dvorak.kbd Wed Dec 12 22:25:31 2012(r244163) +++ head/share/syscons/keymaps/spanish.dvorak.kbd Thu Dec 13 00:44:23 2012(r244164) @@ -1,4 +1,6 @@ # $FreeBSD$ +# +# Submitted by:�lvaro Castillo # alt # scan cntrl altalt cntrl lock # code base shift cntrl shift altshift cntrl shift state ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12/12/12 4:25 PM, Navdeep Parhar wrote: On 12/12/12 16:09, Alfred Perlstein wrote: What do you think happens to a FreeBSD kernel when INVARIANTS is compiled in and it trips an assertion after my change? I know the new knob has sane defaults. My point was that invariants should be considered inviolable. A knob that allows for it's-really-not-supposed-to-fail-but-in-case-it-does... dilutes their meaning, so it may have been better to introduce a new macro for the kind of tests you had in mind. I would use it too instead of the if (!foo) kdb_backtrace() that I often resort to for conditions that I'm not sure about. The problem again is that not all the KASSERTS are inviolable, if you want to do a project to split them, then please do, it would really be helpful, as for now, they are a mis-mash of death/warnings and there are at least three vendors who approve of this as well as 3 long term committers that approved my change (not including Adrian). I'll be completely honest, I struggled very much with this KASSERT problem at a previous employer, and the second that Adrian brought up the idea of "optional panic" I was kicking myself so hard because the solution to so many problems suddenly jumped out at me. I will assure you that taking a stand on this one issue has the following problems: 1) Makes it harder for at LEAST three vendors to shake out and report bugs back to the project. 2) Makes it more likely that someone who has useful (to some, but not all) patches to keep them private to avoid such arguments. Anyhow after all this back and forth on changes that really do not effect anyone, ie defaults stay the same, it really has me questioning the sanity of contributing and/or taking the time to give this sort of thing to the project. It really seems like people are getting very bent out of shape over minor enhancements that offer flexibility. Like what if I do gzipp'd kernel dumps next? (on my todo list) How many people will complain that "gzip is too dangerous in kernel context foo foo" Not sure, I guess I'll find out? -Alfred ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
.. just make sure you've preallocated all the space needed by the gzip code when writing those dumps. :-) Adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244165 - head/usr.sbin/portsnap/portsnap
Author: alfred Date: Thu Dec 13 01:39:49 2012 New Revision: 244165 URL: http://svnweb.freebsd.org/changeset/base/244165 Log: Change progress indicator for downloading patches. Use a percent style indicator instead of emitting one long line of patch numbers. Modified: head/usr.sbin/portsnap/portsnap/portsnap.sh Modified: head/usr.sbin/portsnap/portsnap/portsnap.sh == --- head/usr.sbin/portsnap/portsnap/portsnap.sh Thu Dec 13 00:44:23 2012 (r244164) +++ head/usr.sbin/portsnap/portsnap/portsnap.sh Thu Dec 13 01:39:49 2012 (r244165) @@ -612,6 +612,28 @@ fetch_progress() { echo -n " " } +pct_fmt() +{ + printf " \r" + printf "($1/$2) %02.2f%% " `echo "scale=4;$LNC / $TOTAL * 100"|bc` +} + +fetch_progress_percent() { + TOTAL=$1 + LNC=0 + pct_fmt $LNC $TOTAL + while read x; do + LNC=$(($LNC + 1)) + if [ $(($LNC % 100)) = 0 ]; then + pct_fmt $LNC $TOTAL + elif [ $(($LNC % 10)) = 0 ]; then + echo -n . + fi + done + pct_fmt $LNC $TOTAL + echo " done. " +} + # Sanity-check an index file fetch_index_sanity() { if grep -qvE "^[-_+./@0-9A-Za-z]+\|[0-9a-f]{64}$" INDEX.new || @@ -781,11 +803,13 @@ fetch_update() { echo " done." 1>${QUIETREDIR} # Attempt to fetch ports patches - echo -n "Fetching `wc -l < patchlist | tr -d ' '` " + patchcnt=`wc -l < patchlist | tr -d ' '` + echo -n "Fetching $patchcnt " echo ${NDEBUG} "patches.${DDSTATS}" + echo " " tr '|' '-' < patchlist | lam -s "bp/" - | xargs ${XARGST} ${PHTTPGET} ${SERVERNAME} \ - 2>${STATSREDIR} | fetch_progress + 2>${STATSREDIR} | fetch_progress_percent $patchcnt echo "done." # Attempt to apply ports patches ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244165 - head/usr.sbin/portsnap/portsnap
Reviewed by: eadler On 12/12/12 5:39 PM, Alfred Perlstein wrote: Author: alfred Date: Thu Dec 13 01:39:49 2012 New Revision: 244165 URL: http://svnweb.freebsd.org/changeset/base/244165 Log: Change progress indicator for downloading patches. Use a percent style indicator instead of emitting one long line of patch numbers. Modified: head/usr.sbin/portsnap/portsnap/portsnap.sh Modified: head/usr.sbin/portsnap/portsnap/portsnap.sh == --- head/usr.sbin/portsnap/portsnap/portsnap.sh Thu Dec 13 00:44:23 2012 (r244164) +++ head/usr.sbin/portsnap/portsnap/portsnap.sh Thu Dec 13 01:39:49 2012 (r244165) @@ -612,6 +612,28 @@ fetch_progress() { echo -n " " } +pct_fmt() +{ + printf " \r" + printf "($1/$2) %02.2f%% " `echo "scale=4;$LNC / $TOTAL * 100"|bc` +} + +fetch_progress_percent() { + TOTAL=$1 + LNC=0 + pct_fmt $LNC $TOTAL + while read x; do + LNC=$(($LNC + 1)) + if [ $(($LNC % 100)) = 0 ]; then + pct_fmt $LNC $TOTAL + elif [ $(($LNC % 10)) = 0 ]; then + echo -n . + fi + done + pct_fmt $LNC $TOTAL + echo " done. " +} + # Sanity-check an index file fetch_index_sanity() { if grep -qvE "^[-_+./@0-9A-Za-z]+\|[0-9a-f]{64}$" INDEX.new || @@ -781,11 +803,13 @@ fetch_update() { echo " done." 1>${QUIETREDIR} # Attempt to fetch ports patches - echo -n "Fetching `wc -l < patchlist | tr -d ' '` " + patchcnt=`wc -l < patchlist | tr -d ' '` + echo -n "Fetching $patchcnt " echo ${NDEBUG} "patches.${DDSTATS}" + echo " " tr '|' '-' < patchlist | lam -s "bp/" - | xargs ${XARGST} ${PHTTPGET} ${SERVERNAME} \ - 2>${STATSREDIR} | fetch_progress + 2>${STATSREDIR} | fetch_progress_percent $patchcnt echo "done." # Attempt to apply ports patches ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244166 - head/usr.bin/calendar
Author: grog Date: Thu Dec 13 01:44:58 2012 New Revision: 244166 URL: http://svnweb.freebsd.org/changeset/base/244166 Log: Reluctantly remove one of the most extraordinary numeric conversion routines I have ever seen and replace with something far more boring. Modified: head/usr.bin/calendar/parsedata.c Modified: head/usr.bin/calendar/parsedata.c == --- head/usr.bin/calendar/parsedata.c Thu Dec 13 01:39:49 2012 (r244165) +++ head/usr.bin/calendar/parsedata.c Thu Dec 13 01:44:58 2012 (r244166) @@ -940,15 +940,13 @@ indextooffset(char *s) { int i; struct fixs *n; + char *es; if (s[0] == '+' || s[0] == '-') { - char ss[9]; - for (i = -100; i < 100; i++) { - sprintf(ss, "%s%d", (i > 0) ? "+" : "", i); - if (strcmp(ss, s) == 0) - return (i); - } - return (0); + i = strtod (s, &es); + if (*es != '\0') /* trailing junk */ + errx (1, "Invalid specifier format: %s\n", s); + return (i); } for (i = 0; i < 6; i++) { ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244168 - head/usr.bin/calendar
Author: grog Date: Thu Dec 13 02:21:05 2012 New Revision: 244168 URL: http://svnweb.freebsd.org/changeset/base/244168 Log: Use even more conventional conversion routines. Reported by: peterj@ Modified: head/usr.bin/calendar/parsedata.c Modified: head/usr.bin/calendar/parsedata.c == --- head/usr.bin/calendar/parsedata.c Thu Dec 13 01:58:11 2012 (r244167) +++ head/usr.bin/calendar/parsedata.c Thu Dec 13 02:21:05 2012 (r244168) @@ -943,7 +943,7 @@ indextooffset(char *s) char *es; if (s[0] == '+' || s[0] == '-') { - i = strtod (s, &es); + i = strtol (s, &es, 10); if (*es != '\0') /* trailing junk */ errx (1, "Invalid specifier format: %s\n", s); return (i); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244169 - head/sys/dev/smc
Author: gonzo Date: Thu Dec 13 03:33:01 2012 New Revision: 244169 URL: http://svnweb.freebsd.org/changeset/base/244169 Log: Disable interrupts in filter in order to avoid interrupt storm and CPU starvation Modified: head/sys/dev/smc/if_smc.c Modified: head/sys/dev/smc/if_smc.c == --- head/sys/dev/smc/if_smc.c Thu Dec 13 02:21:05 2012(r244168) +++ head/sys/dev/smc/if_smc.c Thu Dec 13 03:33:01 2012(r244169) @@ -807,6 +807,10 @@ smc_intr(void *context) struct smc_softc*sc; sc = (struct smc_softc *)context; + /* +* Block interrupts in order to let smc_task_intr to kick in +*/ + smc_write_1(sc, MSK, 0); taskqueue_enqueue_fast(sc->smc_tq, &sc->smc_intr); return (FILTER_HANDLED); } @@ -827,13 +831,6 @@ smc_task_intr(void *context, int pending smc_select_bank(sc, 2); /* -* Get the current mask, and then block all interrupts while we're -* working. -*/ - if ((ifp->if_capenable & IFCAP_POLLING) == 0) - smc_write_1(sc, MSK, 0); - - /* * Find out what interrupts are flagged. */ status = smc_read_1(sc, IST) & sc->smc_mask; ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244170 - head/sys/dev/sym
Author: gonzo Date: Thu Dec 13 03:34:24 2012 New Revision: 244170 URL: http://svnweb.freebsd.org/changeset/base/244170 Log: Add memory barrier macros for ARM Modified: head/sys/dev/sym/sym_hipd.c Modified: head/sys/dev/sym/sym_hipd.c == --- head/sys/dev/sym/sym_hipd.c Thu Dec 13 03:33:01 2012(r244169) +++ head/sys/dev/sym/sym_hipd.c Thu Dec 13 03:34:24 2012(r244170) @@ -135,6 +135,8 @@ typedef u_int32_t u32; #define MEMORY_BARRIER() __asm__ volatile("mf.a; mf" : : : "memory") #elif defined __sparc64__ #define MEMORY_BARRIER() __asm__ volatile("membar #Sync" : : : "memory") +#elif defined __arm__ +#define MEMORY_BARRIER() __do_dmb() #else #error "Not supported platform" #endif ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244171 - head/sys/dev/uart
Author: gonzo Date: Thu Dec 13 03:35:47 2012 New Revision: 244171 URL: http://svnweb.freebsd.org/changeset/base/244171 Log: Prevent possible usage of uninitialized pbase variable by checking return value of fdt_get_range Modified: head/sys/dev/uart/uart_bus_fdt.c Modified: head/sys/dev/uart/uart_bus_fdt.c == --- head/sys/dev/uart/uart_bus_fdt.cThu Dec 13 03:34:24 2012 (r244170) +++ head/sys/dev/uart/uart_bus_fdt.cThu Dec 13 03:35:47 2012 (r244171) @@ -206,8 +206,10 @@ uart_cpu_getdev(int devtype, struct uart err = fdt_regsize(node, &start, &size); if (err) return (ENXIO); + err = fdt_get_range(OF_parent(node), 0, &pbase, &psize); + if (err) + pbase = 0; - fdt_get_range(OF_parent(node), 0, &pbase, &psize); start += pbase; return (bus_space_map(di->bas.bst, start, size, 0, &di->bas.bsh)); ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244179 - head/sys/powerpc/wii
Author: rpaulo Date: Thu Dec 13 06:42:44 2012 New Revision: 244179 URL: http://svnweb.freebsd.org/changeset/base/244179 Log: Add the common FreeBSD SVN properties. Modified: Directory Properties: head/sys/powerpc/wii/locore.S (props changed) ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r244180 - head/contrib/top
Author: rpaulo Date: Thu Dec 13 06:45:45 2012 New Revision: 244180 URL: http://svnweb.freebsd.org/changeset/base/244180 Log: Bump MAX_COLS to 512 to take advantage of wider terminals. Modified: head/contrib/top/top.h Modified: head/contrib/top/top.h == --- head/contrib/top/top.h Thu Dec 13 06:42:44 2012(r244179) +++ head/contrib/top/top.h Thu Dec 13 06:45:45 2012(r244180) @@ -14,7 +14,7 @@ extern int Header_lines; /* 7 */ /* Maximum number of columns allowed for display */ -#define MAX_COLS 128 +#define MAX_COLS 512 /* Log base 2 of 1024 is 10 (2^10 == 1024) */ #define LOG102410 ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
on 13/12/2012 00:38 Adrian Chadd said the following: > There are two parts to this; > > * don't compile in invariants. Panics panic. Invariant conditions > aren't checked. You end up with data corruption still if there are > bugs. > * compile in invariants. Panics panic. Invariant conditions are > checked and immediately panic. You can't run this in production to get > debugging info because our debugging info is "create a crash dump and > reboot." > > Now, the crash dump is great for us developers. But crap for say, a > file server. If it's some very subtle issue that only occasionally > pops up once a week and doesn't obviously screw with your data: > > * you can enable invariants and get a crash dump each time - then us > developers get lots of information, but the user experiences outages > once a week; > * they just give the hell up, disable invariants in production and > occasionally hit odd issues they can't explain. > > So now there's a third option: > > * enable invariants, get told when you hit that condition, and continue > running. > > Now, we ship _right now_ generic with INVARIANTS disabled, because in > theory the releases are supposed to be stable enough for us not to > need the extra debugging information. That means that for those very > occasional, very subtle bugs that invariants may catch, we don't have > any way of getting told about them. > > Now, enabling some alternative to panic() is a different story and not > what's being addressed here. > > HTH, Let me see if it does... So basically a violated assertion means that something has already gone wrong. With assertions you catch that sooner and get full debug information and can fix it. Without assertions you crash anyway (in 99% cases), but later and get much less useful information. Now you have an option to crash later while having the worse performance and the only benefit is a log message which may or may not be useful for debugging. No, this doesn't help. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
Let me restate it again. We can ship a STABLE kernel with INVARIANTS enabled, and it not be any less stable than the STABLE kernel is today. Adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
on 13/12/2012 00:43 Adrian Chadd said the following: > On 12 December 2012 14:33, Andriy Gapon wrote: > >>> Yes, two of my employers were more of "we want to get more debug metrics, we >>> have the spare cycles, but we can't deal with superfluous panics". >>> >>> It also allows us "non-architects" to slip in a debug image when we have >>> spare >>> cpu without getting yelled at for "crashing the $foo". >> >> There is clearly something wrong with this sort of mentality. >> >> If you find instances where a developer put panic(9) (or KASSERT or etc) to >> mean >> "maybe here is a bug, let's just panic", then let's get those things fixed. >> >> But most of assertions in our code that are know to me really mean that a >> real >> bug has already occurred, that portions of kernel state are corrupted and >> there >> is no going back to a sane state, only going forward to corrupting more and >> more. > > Dude, if you're running -STABLE right now, you don't have invariants > enabled and you aren't checking for them. > So right now, as it stands, large swaths of our kernel code are > falling afoul of what you're calling Alfred out on. Pal, it's because there are people who thoroughly and regularly test code with INVARIANTS that the code with or without INVARIANTS does not crash as often as it could. When I tested the code with INVARIANTS I trust it to run without those and if a user get a mystery panic one of the first things to advise is to enable various debugging options. > Before you all reply, please review and understand the difference > between "panic()" and "KASSERT()". panic() is not being changed here. > KASSERT() is what's being changed here. panic() is not optional. > KASSERT() is. With a non-INVARIANTS kernel, we _are not checking > invariants_ and we are continuing to run _after_ said non-compiled-in > invariants. With this in mind, please re-review this. :-) KASSERT is not optional contrary to your opinion. We elect to not compile it in for performance reasons, but it is not optional when it is compiled in. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
on 13/12/2012 00:48 Alfred Perlstein said the following: > On 12/12/12 2:29 PM, Andriy Gapon wrote: >> Now we get a new middle-ground: get both worse performance (because KASSERTs >> are compiled in) and a risk of harming your data (because KASSERTs no longer >> panic). The upside: there is no panic! There's just a log message (or etc). >> and chance to get more log messages because the insanity propagates. And a >> chance to lose your data (your customer's) - but I've already mentioned this. >> I am not sure that I like this kind of middle-ground. > I have a number of points here: > > The most important one being: > 1) without kassert you would still have the bug, just that it would be > unreported. > The upside: there is no panic! There's **NO** log message (or etc). and > chance > to get more log messages because the insanity propagates. > > Terrible! > > Let me explain that again: > If you don't compile in KASSERT, then it's not like the condition is never > going > to happen. Instead it will just be unreported. > > So to put it in your own words, *without* KASSERT you get: > > The upside: there is no panic! There's **NO** log message (or etc). and > chance > to get more log messages because the insanity propagates. I disagree with your base premise. I think that the issue will get reported anyway. If the code has gone insane you will get a crash, it just would be much harder to debug. > Now let's get to the other points: > > 2) Since this is not the default, then I do not understand why you are so > concerned. I am concerned about the code becoming less clear and thus harder to maintain. I am also concerned about code with INVARIANTS becoming even more slow. > 3) Can you explain to me why it is so upsetting to you that someone might be > able to use this functionality? That is not upsetting to me at all. 'Someone' could develop the code in his branch / repo. Someone can provide the code for testing and review to his customers and other interested users. Someone may evaluate practical usefulness of the code and only then commit it to the tree. As far as I can see, no one had a chance yet to see how this code is really useful in practice. Yet the code is already in the tree. > 4) *puts on flame retardant suit* ... Linux has had this for over a decade and > it's allowed them to find bugs in different ways. Mind you, in Linux it was > the > default. Can't comment. But if you wanted to add some equivalent of WARN_ON, then I would have zero objection to that. I want to have a clear distinction between "this can't happen" and "it's weird that this happened". KASSERT is not for error checking or for spotting funny situations. It's for asserting sanity in the code as its name implies. > 5) Adrian and I have both stated that we need this sort of functionality to > avoid superfluous panics in our work environments while still getting bug > feedback. Good. Please use this code. > Can we now please stop arguing over a non-default option that will help some > vendors report bugs to the project? Please do use this code, please do report the bugs. Please postpone putting this code into the tree until its benefits are seen. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
Andriy, If you are willing to enable INVARIANTS by default in GENERIC, right now, then I think we should remove Alfred's work. Adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
on 13/12/2012 08:49 Adrian Chadd said the following: > Let me restate it again. > > We can ship a STABLE kernel with INVARIANTS enabled, and it not be any > less stable than the STABLE kernel is today. STABLE != stable, of course. And it will be much much slower, so no one (of the regular users) would use it. It seems like you are missing a point of KASSERT a little bit, the part why it is a compile-time option and not a run-time thing. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
on 13/12/2012 09:07 Adrian Chadd said the following: > Andriy, > > If you are willing to enable INVARIANTS by default in GENERIC, right > now, then I think we should remove Alfred's work. I do not see any connection. INVARIANTS in !CURRENT will not be enabled in GENERIC regardless of Alfred'd work. INVARIANTS in CURRENT are and will be enabled in GENERIC regardless of Alfred'd work. -- Andriy Gapon ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
Hi, I think the fundamental problem here is we have some pretty different ideas of what KASSERT should be, versus what it actually is in various parts of the code. Since we're lost in semantics, we're not going to get any further on this discussion just for now, so let's take a break and think about other things for now. adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On Wed, Dec 12, 2012 at 11:07:58PM -0800, Adrian Chadd wrote: > Andriy, > > If you are willing to enable INVARIANTS by default in GENERIC, right > now, then I think we should remove Alfred's work. It's already enabled by default in GENERIC in the development branch (aka head), which is exactly the right thing to do. Surely, you're not advocating we enable it by default in any release branch? Regards, Navdeep ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r244112 - head/sys/kern
On 12 December 2012 23:19, Navdeep Parhar wrote: > On Wed, Dec 12, 2012 at 11:07:58PM -0800, Adrian Chadd wrote: >> Andriy, >> >> If you are willing to enable INVARIANTS by default in GENERIC, right >> now, then I think we should remove Alfred's work. > > It's already enabled by default in GENERIC in the development branch > (aka head), which is exactly the right thing to do. Surely, you're not > advocating we enable it by default in any release branch? I'm sure at least one vendor out there would love to ship GENERIC + INVARIANTS minus the panic bit, so they get all of the invariants reporting and checking, but none of the panicing (which wouldn't occur if INVARIANTS wasn't compiled in.) WITNESS is still slow, but after I fixed a rather hilarious strlen() abuse in it, it actually started to be more useful to enable at runtime on my test equipment by default. Before I fixed that strlen() issue, I couldn't get anywhere near line rate ethernet/wifi throughput, so I didn't want to leave it on. Adrian ___ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"