From owner-freebsd-hackers@freebsd.org Sat Oct 17 04:21:30 2020 Return-Path: Delivered-To: freebsd-hackers@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 AB87C428565 for ; Sat, 17 Oct 2020 04:21:30 +0000 (UTC) (envelope-from karnajitw@gmail.com) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CCqbF0gnNz4b8c for ; Sat, 17 Oct 2020 04:21:28 +0000 (UTC) (envelope-from karnajitw@gmail.com) Received: by mail-yb1-xb2a.google.com with SMTP id c3so3665432ybl.0 for ; Fri, 16 Oct 2020 21:21:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tgOG5xBGL8J15wvzv885QScj6uvT+3fBkuefv/q2t5s=; b=TrnItSPHge/bMmOluWyxgzDu6ribowpuQIgTbVBWd88sQB1fnvG8HCSXRlhxYwpbgi sUCCHAO130jf9wQB/t2U0dSMkvoIEsCcviakGzGU7aAOeLW6Rpi1eNADwkMsp3uT2EZu 6g+uc4Uja0N4wBfCNAX2DzqwbwxGiDofspy8sOyyua2nhd0/pGlydEKkX1OUGYi0ImTS wRAoT0inH1Uib65zJ1DudQWrGss+2kp1LoC6t9tzcgQV2LUHAvRRGSBdTQzcF1D+15Jz OFtN1p4iw/Ziw7pMGKN70wm3g1OO8Aauq4hHBsdRxCuJbhSFqUuT0dNVycodIEwgYYuF uLow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tgOG5xBGL8J15wvzv885QScj6uvT+3fBkuefv/q2t5s=; b=hDgHHc9or7isxhmBZv/XO3PTbbs69sU3R4xzvm+gaQcSpakEpLYK3K4gG04+6yQmIw wrZYJbkSNiT2EhMOOR6KVZhbbyc2QZnY1K/VIGlhiRTXX7oJ8Zl/8iaiB5K0zJGAkR/n RwJlEpwNOSBgfweIf1peiBV7muKHh1HTqoNbgkmEtFGpRmF56Fi/hoZgwYF/9kv/8qXE jPx0Sa0mcFG1xcEvuebpDctceqW/k4BtmN7mYTFsV4x3N4F1FsqIGLFci8qlP3Rlxj7C PF4WRvr+lR212lXfjNpHYrByYIYB5svc8U+miOKPjKEJTAcAqXzhQqT6/G03w/hqWnoM RraA== X-Gm-Message-State: AOAM530moqtTb85lstxBE/UmJXbJhpvfpGeNrZzXqcB+o2uqbXzuq13R jGqIjIJxzvy+/brlSJR2B/tEvKAhr/t5JsD2CrM= X-Google-Smtp-Source: ABdhPJxnicGI6e7r7ddcagp9pEXM8XO10jCIsTzXZ9qZhS0dJm98DhNwkVuYuRk7ihT5MmdQjuDmWIwbz1fA2qQmpUU= X-Received: by 2002:a25:3f45:: with SMTP id m66mr9219535yba.317.1602908487817; Fri, 16 Oct 2020 21:21:27 -0700 (PDT) MIME-Version: 1.0 References: <9CCF59F6-06F2-4352-94E5-C508E165D0C2@wanadoo.fr> <20201016101144.GS2643@kib.kiev.ua> In-Reply-To: <20201016101144.GS2643@kib.kiev.ua> From: karnajit wangkhem Date: Sat, 17 Oct 2020 09:51:16 +0530 Message-ID: Subject: Re: Extra memory mapping seen on freebsd-12 which was not seen in freebsd-11 To: Konstantin Belousov Cc: Paul Floyd , FreeBSD Hackers X-Rspamd-Queue-Id: 4CCqbF0gnNz4b8c X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=TrnItSPH; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of karnajitw@gmail.com designates 2607:f8b0:4864:20::b2a as permitted sender) smtp.mailfrom=karnajitw@gmail.com X-Spamd-Result: default: False [-3.05 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.09)[-0.094]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.961]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-0.996]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-hackers@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b2a:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-hackers]; FREEMAIL_CC(0.00)[wanadoo.fr,freebsd.org] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Oct 2020 04:21:30 -0000 Thanks for the info. This was exactly my worry. On one side valgrind should have allowed this mapping and at the same time the application would be doing wrong. I will keep this in mind. On Fri, Oct 16, 2020 at 3:41 PM Konstantin Belousov wrote: > On Fri, Oct 16, 2020 at 10:43:32AM +0530, karnajit wangkhem wrote: > > Thanks for the reply. It helped in my understanding. > > > > Below is a sample code > > > > #include > > #include > > #include > > #include > > > > int main() > > { > > char *str = NULL; > > str = (char *)mmap((void *)0x7fffdfffe000UL, 0x2000, PROT_READ | > > PROT_WRITE, MAP_FIXED | MAP_ANON, -1, 0); > > if ((void *)str == (void *)MAP_FAILED) { > > int err = errno; > > printf("mmap failed. err (%s)\n", strerror(err)); > > } else { > > memcpy(str, "Hello World", 12); > > printf("str = %s\n", str); > > } > > > > return 0; > > } > > > > Now, the below code under valgrind will give > > - mmap failed. err (Invalid argument) > > > > But, if we give control of this segment to the client program > > with VG_(am_change_ownership_v_to_c), then valgrind allows the client to > do > > the following mmap. > > - str = Hello World > > > > And, the resultant procstat result looks like this: > > 2382 0x7fbfff000 0x7fc001000 rwx 2 2 1 0 ----- > df > > 2382 0x7fffdfffe000 0x7fffe0000000 rw- 0 0 0 0 ----- > -- > > <<< Client mmap call > > 2382 0x7fffe0000000 0x7ffffffdf000 --- 0 0 0 0 ----- > -- > > <<< 0x1000 bytes is taken away from the MAP_GUARD area > > 2382 0x7ffffffdf000 0x7ffffffff000 rw- 1 1 1 0 ---D- > df > > 2382 0x7ffffffff000 0x800000000000 r-x 1 1 104 0 ----- > ph > > > > So, is it right for the application with or without valgrind to cross the > > above boundary, If that memory which the application reserved is just for > > normal application specific use? > > You called mmap(2) with MAP_FIXED flag, which means that mmap must destroy > any mapping existing at the specified address, and create the requested > mapping instead. This should work as far as the requested range fits into > the userspace virtual address space, and mapping object provides requested > permissions. > > If valgrind does not emulate that behavior of MAP_FIXED correctly, it is > valgrind bug. > > That said, application trying to mmap something at the guard holding the > stack grow area is most likely buggy. Old libthr intentionally split main > thread' stack into stacks of the new threads, but this was changed. >