Date: Mon, 22 Jul 2019 15:24:18 +0200 (CEST) From: Ronald Klop <ronald-lists@klop.ws> To: Laurie Jennings <laurie_jennings_1977@yahoo.com> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: mmap port from 9 not working Message-ID: <1779550698.53.1563801858348@localhost> In-Reply-To: <1436787942.4783433.1563800208736@mail.yahoo.com> References: <446145008.4396329.1563680883838.ref@mail.yahoo.com> <446145008.4396329.1563680883838@mail.yahoo.com> <20190721144404.GJ47193@kib.kiev.ua> <550659871.4389820.1563721133104@mail.yahoo.com> <1027101659.12.1563797006919@localhost> <1436787942.4783433.1563800208736@mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Van: Laurie Jennings <laurie_jennings_1977@yahoo.com>
Datum: maandag, 22 juli 2019 14:56
Aan: Ronald Klop <ronald-lists@klop.ws>
Onderwerp: Re: mmap port from 9 not working
>
>
>
>
>
>
>
>
> Van: Laurie Jennings <laurie_jennings_1977@yahoo.com>
> Datum: zondag, 21 juli 2019 16:58
> Aan: Konstantin Belousov <kostikbel@gmail.com>
> CC: FreeBSD Current <freebsd-current@freebsd.org>
> Onderwerp: Re: mmap port from 9 not working
>>
>> On Sunday, July 21, 2019, 10:44:14 AM EDT, Konstantin Belousov <kostikbel@gmail.com> wrote:
>>
>> On Sun, Jul 21, 2019 at 03:48:03AM +0000, Laurie Jennings wrote:
>> > I have some custom stuff I'm porting from Freebsd 9.x using mmap. I get a pointer from the kernel via an ioctl and I map it into a shared buffer.
>> > char *kptr; // mem ptr from kernel
>> > fd=open("/dev/kmem",O_RDWR);memp=mmap(0,size,PROT_READ|PROT_WRITE,MAP_SHARED,fd,(off_t) ptr);
>> >
>> > This worked perfectly in 9; memp I had a shared block of memory between the kernel and user space.
>> > In 11.3 this returns an errno 22, which is pretty murky. I did notice that off_t doesnt yield an actual offset; I've tried putting in the correct value manuallybut it just fails and fails.I've tried read only also.
>> > Please Help!
>>
>> | Start with providing (and looking yourself) at the output of kdump/ktrace
>> | around the failing mmap. The checks for correctness of the mmap(2) arguments
>> | were greatly improved during years after FreeBSD 9.
>> Since posting this I found a thread that said something about mmap no longer supporting /dev/kmem. If that's that case I need to find another method. No sense spending a day debugging something thatisn't supposed to work.
>> SHOULD this still work? This always worked fine with non-wired memory but maybe things have changed since 9.
>>
>>
>>
>
>
> On Monday, July 22, 2019, 8:03:33 AM EDT, Ronald Klop <ronald-lists@klop.ws> wrote: "
>
> It looks like this is not possible anymore. Here is the code change with some explanation.
> https://svnweb.freebsd.org/base?view=revision&revision=307332
> https://reviews.freebsd.org/D8248
>
> Just a question of my site out of interest to people who know more about this than I do. Does Page Table Isolation (PTI) also prevent mapping /dev/kmem in user space?
> https://wiki.freebsd.org/SpeculativeExecutionVulnerabilities#Meltdown_.28CVE-2017-5754.29
>
> Regards,
> Ronald.
>
> "
>
> Just FYI, I got this to work using '/dev/mem' by passing up the physical address of the block. Probably more intuitive.
>
> Just a question; the docs say contigmalloc() returns wired memory; is this guaranteed to be the case or do I need to run vm_map_wire() on it to be sure? vm_map_lookup() doesnt return "wired" as true after a contigmalloc(); but maybe all kernel_map memory is wired?
>
> LJ
>
Laurie,
I have no idea. I'll cc the mailinglist back into the conversation.
Ronald.
From owner-freebsd-current@freebsd.org Mon Jul 22 14:24:59 2019
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.nyi.freebsd.org (Postfix) with ESMTP id CBBF4B2DB2
for <freebsd-current@mailman.nyi.freebsd.org>;
Mon, 22 Jul 2019 14:24:59 +0000 (UTC)
(envelope-from cy.schubert@cschubert.com)
Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.13])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "Client", Issuer "CA" (not verified))
by mx1.freebsd.org (Postfix) with ESMTPS id C07047158B;
Mon, 22 Jul 2019 14:24:58 +0000 (UTC)
(envelope-from cy.schubert@cschubert.com)
Received: from spqr.komquats.com ([70.67.125.17]) by shaw.ca with ESMTPA
id pZFGh3NqKsAGkpZFHh0ZT1; Mon, 22 Jul 2019 08:24:56 -0600
X-Authority-Analysis: v=2.3 cv=WeVylHpX c=1 sm=1 tr=0
a=VFtTW3WuZNDh6VkGe7fA3g==:117 a=VFtTW3WuZNDh6VkGe7fA3g==:17
a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=IkcTkHD0fZMA:10 a=0o9FgrsRnhwA:10
a=6I5d2MoRAAAA:8 a=YxBL1-UpAAAA:8 a=MvG_LwwQwwA86umcuccA:9 a=QEXdDO2ut3YA:10
a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22
Received: from android-9f533bc8675af991.esitwifi.local
(S0106788a207e2972.gv.shawcable.net [70.66.154.233])
by spqr.komquats.com (Postfix) with ESMTPSA id 63995897;
Mon, 22 Jul 2019 07:24:53 -0700 (PDT)
Date: Mon, 22 Jul 2019 07:23:29 -0700
User-Agent: K-9 Mail for Android
In-Reply-To: <e0a438981f44c52e2b81a95d1cd302cb52cdbf86.camel@freebsd.org>
References: <alpine.BSF.2.21.9999.1907211459520.89843@mail.neu.net>
<e0a438981f44c52e2b81a95d1cd302cb52cdbf86.camel@freebsd.org>
MIME-Version: 1.0
Content-Type: text/plain;
charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: filesystem mount problem
To: freebsd-current@freebsd.org, Ian Lepore <ian@freebsd.org>,
AN <andy@neu.net>
From: Cy Schubert <Cy.Schubert@cschubert.com>
Message-ID: <4B9E3F6E-A324-4C7D-B1B1-E1D009C43A7E@cschubert.com>
X-CMAE-Envelope: MS4wfNsmhIJds/44wkpd5+lkMDDYPrEj/44af2Vn0W0GMLVcLtlrt1+KkroLqlvRqHRp5j2bOuizqXT4UAFNlN8qgl7cuPiXxGRo1/XX9RF8JScb+ti9FY13
6+71OEHQ4xYQnMuYcLjr2V+PHxrHJHZf1ZwIBWW9vFB0zpT984qo9fNOCdKJQShObWrWj1Iq8vVjU3z+JitNdSPjJNXUtF+oBADe/nB77SxqlxX/ERCnAdmr
X-Rspamd-Queue-Id: C07047158B
X-Spamd-Bar: -----
Authentication-Results: mx1.freebsd.org
X-Spamd-Result: default: False [-5.47 / 15.00]; ARC_NA(0.00)[];
RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0];
FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3];
TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0];
MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[];
RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[];
MX_GOOD(-0.01)[cached: spqr.komquats.com];
NEURAL_HAM_SHORT(-0.83)[-0.831,0];
RCVD_IN_DNSWL_NONE(0.00)[13.134.59.64.list.dnswl.org : 127.0.5.0];
R_SPF_NA(0.00)[];
RECEIVED_SPAMHAUS_PBL(0.00)[233.154.66.70.zen.spamhaus.org :
127.0.0.11,17.125.67.70.zen.spamhaus.org : 127.0.0.11];
R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+];
ASN(0.00)[asn:6327, ipnet:64.59.128.0/20, country:CA];
MID_RHS_MATCH_FROM(0.00)[];
IP_SCORE(-2.53)[ip: (-6.81), ipnet: 64.59.128.0/20(-3.23), asn: 6327(-2.51),
country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[]
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>;
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 14:24:59 -0000
On July 21, 2019 1:44:13 PM PDT, Ian Lepore <ian@freebsd=2Eorg> wrote:
>On Sun, 2019-07-21 at 15:07 -0400, AN wrote:
>> Hi:
>>=20
>> FreeBSD FreeBSD_13 13=2E0-CURRENT FreeBSD 13=2E0-CURRENT #102 r350187:
>> Sat Jul=20
>> 20 19:04:30 EDT 2019=20
>> root@FreeBSD_13:/usr/obj/usr/src/amd64=2Eamd64/sys/MYKERNEL amd64
>> 1300036
>>=20
>> I would appreciate some help with the following problem=2E
>>=20
>> /etc/fstab:
>> # Device Mountpoint FStype Options Dump Pass#
>> /dev/ada0p2 none swap sw 0 0
>> /dev/ada0p3 / ufs rw 1 1
>> linprocfs /compat/linux/proc linprocfs rw 0 0
>> tmpfs /compat/linux/dev/shm tmpfs rw,mode=3D1777 0=09
>> 0
>>=20
>>=20
>> # df -h
>> Filesystem Size Used Avail Capacity Mounted on
>> /dev/ada0p3 428G 245G 149G 62% /
>> devfs 1=2E0K 1=2E0K 0B 100% /dev
>> linprocfs 4=2E0K 4=2E0K 0B 100% /compat/linux/proc
>> tmpfs 47G 4=2E0K 47G 0% /compat/linux/dev/shm
>> tmpfs 20M 604K 19M 3% /tmp
>>=20
>> I don't understand why the /tmp is being mounted=2E It is causing
>> problems=20
>> because when I try to run portupgrade it fails for lack of space=2E If
>> I=20
>> forcibly unmount it everything breaks=2E
>>=20
>> # umount -v /tmp
>> umount: unmount of /tmp failed: Device busy
>> [root@FreeBSD_13 ~]# umount -vf /tmp
>> tmpfs: unmount from /tmp
>> [root@FreeBSD_13 ~]# df -h
>> Filesystem Size Used Avail Capacity Mounted on
>> /dev/ada0p3 428G 245G 149G 62% /
>> devfs 1=2E0K 1=2E0K 0B 100% /dev
>> linprocfs 4=2E0K 4=2E0K 0B 100% /compat/linux/proc
>> tmpfs 47G 4=2E0K 47G 0% /compat/linux/dev/shm
>> [root@FreeBSD_13 ~]# vinagre
>> Unable to init server: Could not connect to 127=2E0=2E0=2E1: Connection
>> refused
>>=20
>> (vinagre:27111): Gtk-WARNING **: 15:04:21=2E599: cannot open display:
>> :0
>>=20
>> Any help would be appreciated, thanks in advance=2E
>>=20
>
>The problem isn't that /tmp is tmpfs, the problem is that it's being
>mounted by /etc/rc=2Ed/tmp as a 20MB filesystem because tmpsize=3D"20m" i=
s
>the default=2E You could set tmpsize to some bigger value in rc=2Econf, =
or
>you can add an explicit mount for /tmp in fstab so that you get the
>full (47G on your system) capacity that's available:
>
> tmpfs /tmp tmpfs rw 0 0
>
>-- Ian
>
>
>_______________________________________________
>freebsd-current@freebsd=2Eorg mailing list
>https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current
>To unsubscribe, send any mail to
>"freebsd-current-unsubscribe@freebsd=2Eorg"
I've seen clients inadvertently DoS themselves when I was a Solaris admin=
=2E Solaris never used limits for tmpfs=2E=20
As to how we arrived at 20m, I recall an OSF/1 course where the instructor=
intimated that 20m was industry best practice at the time and OSF/1 being =
BSD=2E That was a lifetime ago=2E Maybe it's time to consider a higher defa=
ult for 2019=2E
Anticipating a memory constrained embedded argument, people designing prod=
ucts would customize it anyway=2E=20
--=20
Pardon the typos and autocorrect, small keyboard in use=2E
Cheers,
Cy Schubert <Cy=2ESchubert@cschubert=2Ecom>
FreeBSD UNIX: <cy@FreeBSD=2Eorg> Web: http://www=2EFreeBSD=2Eorg
The need of the many outweighs the greed of the few=2E
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1779550698.53.1563801858348>