From owner-freebsd-current@freebsd.org Wed May 22 18:08:43 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2C97515B3C88 for ; Wed, 22 May 2019 18:08:43 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-lj1-f173.google.com (mail-lj1-f173.google.com [209.85.208.173]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) 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 2D09E91E10; Wed, 22 May 2019 18:08:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-lj1-f173.google.com with SMTP id q16so2968604ljj.8; Wed, 22 May 2019 11:08:42 -0700 (PDT) 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=fYioiwOxYv6huFRllAbp39RFVM8ZV9iVVuDKOZ0++MA=; b=Ib+et1FZl8kR8wWnPqePrN2ZX5hZ96IdGkdx2AiE/CTbtTEAu9s+WEjz+rlw8m+2qF T2d5i+Z6unTeVQgEKdASZkqeo348ppSb2NrEQyGAfb1K4HoP9D/YNbE9BE3OSg8xdjFA 2Biwog7GZXSjUaxVQE8rszhBkeMzgUJOCb+Ter6VKMT4jOB2co6ve0LniVs4ppyh5ckF lt4xZ/EEf+P0GPp4WY01lDNZOuDYdz09xKNy7qDWXXFWaStl3kf21Vb8Y57DCd7HGMEv mUSOTE8dRE9XzTg7viko+qzBrmhOdZtiSIikFTPggPg+klQiVXNA2w9/9ecx/4Wl4iDS oRmQ== X-Gm-Message-State: APjAAAU/wxJLAD0Qg8YzLy3lUd+4I60LEhTbFQDdpHZsJFmw72CGUHQT ZiAT34oVAqGyafoMbhH2OD2P4fs+JGx0CPg2RZCx6g== X-Google-Smtp-Source: APXvYqxfD8JCXO/ym/I/MvBe6AWtFiQY3/RpwPPvVtGvd98SptM+GY705n8FREWupnume+d6GTFcwiYbZX1x9boMB2w= X-Received: by 2002:a2e:1f02:: with SMTP id f2mr45076558ljf.86.1558548192394; Wed, 22 May 2019 11:03:12 -0700 (PDT) MIME-Version: 1.0 References: <6ec62e4d-9f93-ffe1-646c-3846c9308334@FreeBSD.org> <20190522175133.GC2748@kib.kiev.ua> <84e3001b-646d-b1d9-f206-577d63f79bf1@FreeBSD.org> In-Reply-To: <84e3001b-646d-b1d9-f206-577d63f79bf1@FreeBSD.org> From: Alan Somers Date: Wed, 22 May 2019 12:03:00 -0600 Message-ID: Subject: Re: Weirdness when writing to pseudofs file To: Johannes Lundberg Cc: Konstantin Belousov , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 2D09E91E10 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.208.173 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-4.13 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.85)[-0.853,0]; RCVD_IN_DNSWL_NONE(0.00)[173.208.85.209.list.dnswl.org : 127.0.5.0]; RCVD_TLS_LAST(0.00)[]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; IP_SCORE(-1.27)[ip: (-0.56), ipnet: 209.85.128.0/17(-3.46), asn: 15169(-2.27), country: US(-0.06)]; FREEMAIL_CC(0.00)[gmail.com] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2019 18:08:43 -0000 On Wed, May 22, 2019 at 11:59 AM Johannes Lundberg wrote: > > > On 5/22/19 10:51 AM, Konstantin Belousov wrote: > > On Wed, May 22, 2019 at 10:36:34AM -0700, Johannes Lundberg wrote: > >> Hi > >> > >> I'm fiddling with lindebugfs, which is based on pseudofs. When writing > >> to a file, > >> > >> this works: # echo 1 >> /path/to/file > >> > >> but this does not: # echo 1 > /path/to/file > >> > >> "Operation not supported." is returned before the pseudofs code is even > >> entered. > >> > >> Is this expected behavior? (if so, why?) > > Does the file exist ? > > > > Pseudofs does not implement VOP_CREATE(), which is reasonable. > > Yes, it exists and my custom write function is receiving the call for > ">>". (which is for example used by drm driver debugfs to do certain > things on demand by accepting write to a debugfs file) First, you need to try ktrace to see exactly which system call is not supported. If the problem still isn't obvious, then you can try dtrace to see exactly which VOP isn't suppoted. Do it like this: sudo ktrace /bin/sh -c "echo 1 > /path/to/file" sudo kdump sudo dtrace -i 'fbt:::return /arg1 == 45/ {trace(".")}' -c "/bin/sh -c 'echo 1 > /path/to/file/'" The dtrace command will show you which function returned EOPNOTSUPP. However, it will also show a lot of functions that coincidentally return 45 even though it's not an errno, and even functions that return void. -Alan