Re: some [big] changes to ZPL (ZFS<->VFS )
On 03/08/2016 17:25, Andriy Gapon wrote: > Another change that was not strictly required and which is probably too > intrusive is killing the support for case insensitive operations. My > thinking was that FreeBSD VFS does not provide support for those anyway. > But I'll probably restore the code, at least in the bottom half of the > ZPL, before committing the change. It turned out that most of the removed code was dead anyway and it took just a few lines of code to restore support for case-insensitive filesystems. Filesystems with mixed case sensitivity behave exactly the same as case-sensitive filesystem as it has always been the case on FreeBSD. Anyway the big change has just been committed: https://svnweb.freebsd.org/changeset/base/303763 Please test away. Another note is that the filesystem name cache is now disabled for case insensitive filesystems and filesystems with normalization other than none. That may hurt the lookup performance, but should ensure correctness of operations. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: date(1) default format changed between 10.3 and 11.0-BETA3
On 5/08/2016 5:44 AM, Mark Martinec wrote: Should I open a bug report, or has the problem been noted? it's not clear without reading the standard whether the bug is in the old or new version. have you tried other systems? In particular I'd check OSX sh-3.2$ export LC_CTYPE="en_US.UTF-8" sh-3.2$ export LC_TIME="en_US.UTF-8" sh-3.2$ export LC_ALL="en_US.UTF-8" sh-3.2$ export LC_NUMERIC="en_US.UTF-8" sh-3.2$ date Fri Aug 5 12:57:47 AWST 2016 if it IS a bug then yes, file a report with full reproduction steps. Mark On 2016-08-04 04:32, Julian Elischer wrote: On 4/08/2016 7:24 AM, Mark Martinec wrote: Is it normal/expected/documented that the date(1) command in 11.0 now produces a timestamp in substantially different format in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour time): Thursday, August 4, 2016 at 12:50:43 AM CEST vs: Thu Aug 4 00:52:29 CEST 2016 one of those is a bug. the formats are defined in posix I believe. Setting LC_TIME does not help: $LC_TIME="C" date Thursday, August 4, 2016 at 01:13:37 AM CEST although LC_ALL="C" _does_ help. This is funny too, especially regarding commas: $ LC_ALL="en_GB.UTF-8" date Thursday 4 August 2016 at 01:16:45 CEST $ LC_ALL="en_US.UTF-8" date Thursday, August 4, 2016 at 01:16:54 AM CEST The date(1) man page states: The date utility is expected to be compatible with IEEE Std 1003.2 (“POSIX.2”). What does POSIX.2 say about date(1) following a locale? == 11.0-BETA3: $ date Thursday, August 4, 2016 at 12:50:43 AM CEST $ uname -a FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul 29 02:27:28 UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 $ locale LANG= LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 == 10.3-RELEASE-p6 : $ date Thu Aug 4 00:52:29 CEST 2016 $ freebsd-version 10.3-RELEASE-p6 $ uname -a FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 $ locale LANG= LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 Mark ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0
On Fri, Aug 05, 2016 at 01:59:18AM +, Glen Barber wrote: > This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, > and will be deprecated effective 11.0-RELEASE (and preceeding RCs). > Stupid editor mistake. OpenSSH DSA keys are deprecated upstream. Sorry for any confusion. > Please see r303716 for details on the relevant commit, but upstream no > longer considers them secure. Please replace DSA keys with ECDSA or RSA > keys as soon as possible, otherwise there will be issues when upgrading > from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the > 11.0-RELEASE build. > Glen On behalf of: re@ and secteam@ signature.asc Description: PGP signature
HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, and will be deprecated effective 11.0-RELEASE (and preceeding RCs). Please see r303716 for details on the relevant commit, but upstream no longer considers them secure. Please replace DSA keys with ECDSA or RSA keys as soon as possible, otherwise there will be issues when upgrading from 11.0-BETA4 to the subsequent 11.0 build, but most definitely the 11.0-RELEASE build. Glen On behalf of: re@ and secteam@ -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJXo/L2AAoJEAMUWKVHj+KTG3sP/3j5PBVMBlYVVR+M4PUoRJjb kShIRFHzHUV9YzTIljtqOVf/f/mw3kRHA4fUonID5AJlo23ht9cwGOvGUi5H3lBK rnL9vsU9lvZoGyaHLpR/nikMOaRTa8bl1cdpULlEGH94HEzDuLT92AtAZ5HtdDEl GcXRfTe3eGOaxcqNSF8NKSMQQ8rzbKmsgsa5Cbf0PYToemn3xyPAr+9Nz8tbSrlR TrrFhzOR6+Ix0NcYJAKs6RUZ2kgbAheYF6nQmAHlJzyBihlfdfieJdysqNwSOQ8u c7CyBLNFrGKqYTDVQI36MUwoyVtEqbOjt3cPitsMsD3fVAf05H7dHp/0iqrUghUs 60HYOjfmvZxH5wvhEPdv/wPLAZeosdQgW8np3Y5cztw7cxZXF+PxoMjRcnXVpQ2c QIZg3RsiQmJtAT4Z2OuvYikqGzrpsVido0um/KMM9b82XilJExxPPzgEpXCK3CE8 7TchzrRA/W27eST4VXoNYrrMlmpavur1IxvMS54fBOu98efTIoER6uJc1t7qcL6r mEVmBoMqecg+auuWqz50Bh8K329dlYuGLMbk/Ktc3agXtpkw88ylDmC6l5N7qrnL kSb4i3DboU7R1cltiin3c/P+ahwfKQdNH18QbN3utJuzSSRVvXq4laUGFlRhWEEx bLbbH2fh5bxDmDXDMdCF =LLtP -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
kernel panic caused by virtualbox(?)
Reposted to -current to get some more eyes on this ... I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. The host is: FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 The virtualbox version is: virtualbox-ose-5.0.26 virtualbox-ose-kmod-5.0.26_1 The panic message is: panic: Unregistered use of FPU in kernel cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe085a55d030 vpanic() at vpanic+0x182/frame 0xfe085a55d0b0 kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120 trap() at trap+0x7ae/frame 0xfe085a55d330 calltrap() at calltrap+0x8/frame 0xfe085a55d330 --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, rbp = 0xfe085a55d430 --- g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430 g_pLogger() at 0x8274e5c7/frame 0x3 KDB: enter: panic Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is the trigger. There are no symbols for the virtualbox kmods, possibly because I installed them as an upgrade using packages (built with the same source tree version) instead of by using PORTS_MODULES in make.conf, so ports kgdb didn't have anything useful to say about what happened before the trap. This panic is very repeatable. I just got another one when starting the same VM., but this time the two calls before the trap were null_bug_bypass(). Hmn, that symbol is in nullfs ... I don't see this with a Windows 7 VM. All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse -msoft-float -mno-aes -mno-avx ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: date(1) default format changed between 10.3 and 11.0-BETA3
Should I open a bug report, or has the problem been noted? Mark On 2016-08-04 04:32, Julian Elischer wrote: On 4/08/2016 7:24 AM, Mark Martinec wrote: Is it normal/expected/documented that the date(1) command in 11.0 now produces a timestamp in substantially different format in an "en_US.UTF-8" locale (long names, commas, 12 vs. 24h hour time): Thursday, August 4, 2016 at 12:50:43 AM CEST vs: Thu Aug 4 00:52:29 CEST 2016 one of those is a bug. the formats are defined in posix I believe. Setting LC_TIME does not help: $ LC_TIME="C" date Thursday, August 4, 2016 at 01:13:37 AM CEST although LC_ALL="C" _does_ help. This is funny too, especially regarding commas: $ LC_ALL="en_GB.UTF-8" date Thursday 4 August 2016 at 01:16:45 CEST $ LC_ALL="en_US.UTF-8" date Thursday, August 4, 2016 at 01:16:54 AM CEST The date(1) man page states: The date utility is expected to be compatible with IEEE Std 1003.2 (“POSIX.2”). What does POSIX.2 say about date(1) following a locale? == 11.0-BETA3: $ date Thursday, August 4, 2016 at 12:50:43 AM CEST $ uname -a FreeBSD xxx.ijs.si 11.0-BETA3 FreeBSD 11.0-BETA3 #0 r303469: Fri Jul 29 02:27:28 UTC 2016 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 $ locale LANG= LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 == 10.3-RELEASE-p6 : $ date Thu Aug 4 00:52:29 CEST 2016 $ freebsd-version 10.3-RELEASE-p6 $ uname -a FreeBSD yyy.ijs.si 10.3-RELEASE-p4 FreeBSD 10.3-RELEASE-p4 #0: Sat May 28 12:23:44 UTC 2016 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 $ locale LANG= LC_CTYPE="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_ALL=en_US.UTF-8 Mark ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwm load panic
On Thursday, August 4, 2016, Christian Schwarz wrote: > Any idea which revision/commit introduced this regression? > > (I want to test iwm + freebsd-base-graphics on my laptop tonight and > hence avoid crashers like this one in advance.) > > @mmacy: is the revision in the current drm-next-4.6 branch of > https://github.com/FreeBSDDesktop/freebsd-base-graphics.git > > Yes. That is what I run on my Skylake based gen4 carbon x1. 8260 support was just added, so I don't know if it's possible to use new hardware without exposing one's self to this bug. In fairness, 80-85% of the time it loads just fine, and this bug looks much easier to fix than the various issues I am looking at right now. Once loaded the driver has worked quite satisfactorily. -M > Thanks, > > -- > Christian Schwarz > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org > " > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
11.0-RELEASE schedule update
As those of you tracking our PR system are probably aware, re@ is aware of an issue related to ZFS and VFS that we feel is urgent enough to have fixed for 11.0-RELEASE. https://lists.freebsd.org/pipermail/freebsd-current/2016-August/062829.html As such, instead of branching releng/11.0 today and starting 11.0-RC1 builds, BETA4 will be added to the 11.0 release schedule, since the level of possible intrusiveness would be extremely difficult to fix with an Errata Notice after 11.0-RELEASE. The 11.0-RELEASE schedule has been updated on the website to account for the BETA4 addition: https://www.freebsd.org/releases/11.0R/schedule.html Thank you for your patience. Glen On behalf of: re@ signature.asc Description: PGP signature
Re: EARLY_AP_STARTUP hangs during boot
On Thursday, August 04, 2016 08:59:06 AM Gary Jennejohn wrote:
> On Tue, 02 Aug 2016 10:41:23 -0700
> John Baldwin wrote:
>
> > On Tuesday, August 02, 2016 09:03:10 AM Gary Jennejohn wrote:
> > > On Mon, 01 Aug 2016 13:19:16 -0700
> > > John Baldwin wrote:
> > >
> > > > On Monday, August 01, 2016 03:31:11 PM Gary Jennejohn wrote:
> > > > > On Mon, 1 Aug 2016 09:34:34 +0200
> > > > > Gary Jennejohn wrote:
> > > > >
> > > > > > On Sun, 31 Jul 2016 14:22:35 -0700
> > > > > > John Baldwin wrote:
> > > > > >
> > > > > > > On Sunday, July 31, 2016 11:29:14 AM Gary Jennejohn wrote:
> > > > > > > > On Sat, 30 Jul 2016 12:03:59 -0700
> > > > > > > > John Baldwin wrote:
> > > > > > > >
> > > > > > > > > On Saturday, July 30, 2016 09:44:22 AM Gary Jennejohn wrote:
> > > > > > > > >
> > > > > > > > > > On Fri, 29 Jul 2016 13:17:42 -0700
> > > > > > > > > > John Baldwin wrote:
> > > > > > > > > >
> > > > > > > > > > > On Thursday, July 28, 2016 12:31:31 AM Gary Jennejohn
> > > > > > > > > > > wrote:
> > > > > > > > > > > > Well, now I know that ULE is a prerequiste for
> > > > > > > > > > > > EARLY_AP_STARTUP! I
> > > > > > > > > > > > wasn't aware of that. I prefer BSD and that's the
> > > > > > > > > > > > scheduler I did
> > > > > > > > > > > > the first tests with.
> > > > > > > > > > > >
> > > > > > > > > > > > But with the ULE scheduler the system comes up all the
> > > > > > > > > > > > way.
> > > > > > > > > > > >
> > > > > > > > > > > > It would be nice if the BSD scheduler could also be
> > > > > > > > > > > > modified to
> > > > > > > > > > > > work with EARLY_AP_STARTUP.
> > > > > > > > > > >
> > > > > > > > > > > I wasn't able to reproduce your hang with 4BSD, but I
> > > > > > > > > > > think I see a
> > > > > > > > > > > possible problem. Try this:
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> > > > > > > > > > > index 7de56b6..d53331a 100644
> > > > > > > > > > > --- a/sys/kern/sched_4bsd.c
> > > > > > > > > > > +++ b/sys/kern/sched_4bsd.c
> > > > > > > > > > > @@ -327,7 +327,6 @@ maybe_preempt(struct thread *td)
> > > > > > > > > > >* - The current thread has a higher (numerically
> > > > > > > > > > > lower) or
> > > > > > > > > > >*equivalent priority. Note that this prevents
> > > > > > > > > > > curthread from
> > > > > > > > > > >*trying to preempt to itself.
> > > > > > > > > > > - * - It is too early in the boot for context switches
> > > > > > > > > > > (cold is set).
> > > > > > > > > > >* - The current thread has an inhibitor set or is in
> > > > > > > > > > > the process of
> > > > > > > > > > >*exiting. In this case, the current thread is
> > > > > > > > > > > about to switch
> > > > > > > > > > >*out anyways, so there's no point in preempting.
> > > > > > > > > > > If we did,
> > > > > > > > > > > @@ -348,7 +347,7 @@ maybe_preempt(struct thread *td)
> > > > > > > > > > > ("maybe_preempt: trying to run
> > > > > > > > > > > inhibited thread"));
> > > > > > > > > > > pri = td->td_priority;
> > > > > > > > > > > cpri = ctd->td_priority;
> > > > > > > > > > > - if (panicstr != NULL || pri >= cpri || cold /* ||
> > > > > > > > > > > dumping */ ||
> > > > > > > > > > > + if (panicstr != NULL || pri >= cpri /* || dumping */ ||
> > > > > > > > > > > TD_IS_INHIBITED(ctd))
> > > > > > > > > > > return (0);
> > > > > > > > > > > #ifndef FULL_PREEMPTION
> > > > > > > > > > > @@ -1127,7 +1126,7 @@ forward_wakeup(int cpunum)
> > > > > > > > > > > if ((!forward_wakeup_enabled) ||
> > > > > > > > > > >(forward_wakeup_use_mask == 0 &&
> > > > > > > > > > > forward_wakeup_use_loop == 0))
> > > > > > > > > > > return (0);
> > > > > > > > > > > - if (!smp_started || cold || panicstr)
> > > > > > > > > > > + if (!smp_started || panicstr)
> > > > > > > > > > > return (0);
> > > > > > > > > > >
> > > > > > > > > > > forward_wakeups_requested++;
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Thanks, but with this patch the kernel hangs in exactly the
> > > > > > > > > > same
> > > > > > > > > > place as before - after the HPET output.
> > > > > > > > > >
> > > > > > > > > > Maybe I'm missing some kernel option which ULE works
> > > > > > > > > > around, or
> > > > > > > > > > something like that.
> > > > > > > > >
> > > > > > > > > Hmm, ok. Please add KTR_RUNQ and KTR_SMP to the KTR masks,
> > > > > > > > > that is
> > > > > > > > > 'options KTR_COMPILE=(KTR_PROC|KTR_RUNQ|KTR_SMP)' and
> > > > > > > > > 'options KTR_MASK=(KTR_PROC|KTR_RUNQ|KTR_SMP)'
> > > > > > > > >
> > > > > > > > > Please also add this patch (on top of the previous patch):
> > > > > > > > >
> > > > > > > > > diff --git a/sys/kern/sched_4bsd.c b/sys/kern/sched_4bsd.c
> > > > > > > > > index 2973a23..bab2278 100644
> > > > > >
Re: iwm load panic
Any idea which revision/commit introduced this regression? (I want to test iwm + freebsd-base-graphics on my laptop tonight and hence avoid crashers like this one in advance.) @mmacy: is the revision in the current drm-next-4.6 branch of https://github.com/FreeBSDDesktop/freebsd-base-graphics.git Thanks, -- Christian Schwarz ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwm load panic
Uhm, yes. I can read that too. I'm suggesting that someone working on the iwm driver can fix it. On the boot immediately prior to this my system panicked with an assert in idr - which is much more my bailiwick. -M On Thu, Aug 4, 2016 at 1:04 AM, Hans Petter Selasky wrote: > On 08/04/16 09:56, K. Macy wrote: >> >> #12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at > > > Hi, > > Looks like a NULL pointer, queue=NULL > > --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: iwm load panic
On 08/04/16 09:56, K. Macy wrote: #12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at Hi, Looks like a NULL pointer, queue=NULL --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
iwm load panic
I get this panic periodically at iwm load time: (kgdb) p ic->ic_tq value has been optimized out (kgdb) down #12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_taskqueue.c:554 554 TQ_LOCK(queue); (kgdb) bt #0 __curthread () at ./machine/pcpu.h:221 #1 doadump (textdump=0) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:298 #2 0x82703ac9 in vt_kms_postswitch (arg=) at /usr/home/mmacy/drm-next-4.6/sys/modules/drm2/drm2/../../../dev/drm2/linux_fb.c:82 #3 0x8093fb55 in vt_window_switch (vw=0x817e87d0 ) at /usr/home/mmacy/drm-next-4.6/sys/dev/vt/vt_core.c:540 #4 0x8093c9b0 in vtterm_cngrab (tm=) at /usr/home/mmacy/drm-next-4.6/sys/dev/vt/vt_core.c:1465 #5 0x80a78f12 in cngrab () at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_cons.c:368 #6 0x80ae88c6 in vpanic (fmt=0x810f771b "%s", ap=0xfe0461098e70) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:745 #7 0x80ae87b3 in panic (fmt=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_shutdown.c:690 #8 0x80fc0361 in trap_fatal (frame=0xfe0461099170, eva=100) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:841 #9 0x80fc0553 in trap_pfault (frame=0xfe0461099170, usermode=0) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:691 #10 0x80fbfafc in trap (frame=0xfe0461099170) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:442 #11 #12 taskqueue_drain (queue=0x0, task=0xfe004fc17150) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_taskqueue.c:554 #13 0x827823bb in ieee80211_draintask (ic=, task=0xfe004fc17150) at /usr/home/mmacy/drm-next-4.6/sys/net80211/ieee80211_var.h:796 #14 iwm_detach_local (sc=, do_net80211=) at /usr/home/mmacy/drm-next-4.6/sys/modules/iwm/../../dev/iwm/if_iwm.c:6121 #15 0x80b21e8c in run_interrupt_driven_config_hooks () at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_autoconf.c:118 #16 0x80b21ccb in config_intrhook_establish (hook=) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_autoconf.c:182 #17 0x82781d03 in iwm_attach (dev=) at /usr/home/mmacy/drm-next-4.6/sys/modules/iwm/../../dev/iwm/if_iwm.c:5825 #18 0x80b26340 in DEVICE_ATTACH (dev=0xf8000744f700) at ./device_if.h:180 #19 device_attach (dev=0xf8000744f700) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:2900 #20 0x8071730d in pci_driver_added (dev=, driver=) at /usr/home/mmacy/drm-next-4.6/sys/dev/pci/pci.c:4330 #21 0x80b23e9d in BUS_DRIVER_ADDED (_dev=0xf8000744f800, _driver=0x82790c08 ) at ./bus_if.h:204 #22 devclass_driver_added (dc=, driver=) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:1099 #23 0x80b23e02 in devclass_add_driver (dc=, driver=, pass=, dcp=) at /usr/home/mmacy/drm-next-4.6/sys/kern/subr_bus.c:1172 #24 0x80ac2300 in module_register_init (arg=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_module.c:123 #25 0x80ab3f14 in linker_file_sysinit (lf=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:234 #26 linker_load_file (filename=, result=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:434 #27 linker_load_module (kldname=, modname=0xf8000f0a8000 "if_iwm", parent=, verinfo=, lfpp=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:2024 #28 0x80ab5d48 in kern_kldload (td=, file=, fileid=0xfe0461099874) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:1041 #29 0x80ab5eab in sys_kldload (td=0xf800966f1500, uap=) at /usr/home/mmacy/drm-next-4.6/sys/kern/kern_linker.c:1067 #30 0x80fc0cc8 in syscallenter (td=, sa=) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/../../kern/subr_syscall.c:135 #31 amd64_syscall (td=, traced=0) at /usr/home/mmacy/drm-next-4.6/sys/amd64/amd64/trap.c:942 #32 #33 0x00080086d38a in ?? () ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Socket sendmsg() porting question
2016-08-03 19:18 GMT+02:00 Lundberg, Johannes :
> Even if I set cmsg_level and cmsg_type it won't let me send it. The problem
> is having a zero length attachment on freebsd
> I can't send -1 as fd because that errors to invalid file descriptor.
Well, it makes sense. If you're attaching a message to a sendmsg()
call, it should have contents that make sense. Also, msg_controllen
should correspond with the actual space consumed by the message. Not a
single byte more. Change the logic to one of the following two.
Solution 1: Simply set msg_controllen to zero entirely, so there is no
message attached when sending.
struct cmsghdr *cmsg = CMSG_FIRSTHDR(&message);
if (fd >= 0) {
message.msg_controllen = CMSG_SPACE(sizeof(fd));
cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
memcpy(CMSG_DATA(cmsg), &fd, sizeof(fd));
} else {
message.msg_controllen = 0;
}
Solution 2: Send a SCM_RIGHTS message that contains no file descriptors.
struct cmsghdr *cmsg = CMSG_FIRSTHDR(&message);
cmsg->cmsg_level = SOL_SOCKET;
cmsg->cmsg_type = SCM_RIGHTS;
if (fd >= 0) {
message.msg_controllen = CMSG_SPACE(sizeof(fd));
cmsg->cmsg_len = CMSG_LEN(sizeof(fd));
memcpy(CMSG_DATA(cmsg), &fd, sizeof(fd));
} else {
message.msg_controllen = CMSG_SPACE(0);
cmsg->cmsg_len = CMSG_LEN(0);
}
Also worth mentioning:
char control[CMSG_SPACE(sizeof(int))];
That line is incorrect. The reason for this is that it may not be
sufficiently aligned. You have to make sure that the control message
buffer is aligned to at least 'struct cmsghdr', as CMSG_FIRSTHDR()
will do nothing more than return the buffer directly. Change that line
to one of the following two:
#include
alignas(struct cmsghdr) char control[CMSG_SPACE(sizeof(int))];
Or:
union {
struct cmsghdr a;
char b[CMSG_SPACE(sizeof(int))];
} control;
Best regards,
--
Ed Schouten
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Socket sendmsg() porting question
On 4/08/2016 1:18 AM, Lundberg, Johannes wrote: Hi Alan Thanks for the reply. Can I still use the same receiving function for sendmsg/send and tell what kind of message is coming? How would I tell if there is an fd attached or not? Even if I set cmsg_level and cmsg_type it won't let me send it. The problem is having a zero length attachment on freebsd I can't send -1 as fd because that errors to invalid file descriptor. On Wed, Aug 3, 2016 at 10:12 AM, Alan Somers wrote: On Wed, Aug 3, 2016 at 10:54 AM, Lundberg, Johannes wrote: Hi I'm porting a project to fbsd and I have problem with this part that works in linux but not fbsd when fd = -1. https://github.com/Cloudef/wlc/blob/master/src/session/fd.c#L80-L108 I get "invalid argument" from sendmsg() when setting CMSG_LEN(0). Anyone have a clue how to correctly do this on fbsd? Thanks! Johannes It sounds like you're trying to send an empty cmsg. The error may happen because your msg_controllen field is inconsistent with your cmsg_len field. You're setting msg_controllen as if there were a full cmsg, but then cmsg_len says that there is no cmsg. Or maybe the error is because (just guessing) FreeBSD doesn't allow sending empty or undefined cmsgs. Notice that cmsg_level and cmsg_type are undefined in the case where fd == -1. POSIX doesn't say whether sendmsg supports empty cmsgs, but why bother? You could just use send instead of sendmsg if you're not sending a file descriptor. -Alan I think it's a standards interpretation thing. what data do you send WITH the message? I assume you have some in-band data as well. if you have no FD, just use "sendto()." the other end will still be able to do a recvmesg() but will discover no added info. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
