From owner-freebsd-current@freebsd.org Fri Dec 7 09:59:43 2018 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 606ED133244F for ; Fri, 7 Dec 2018 09:59:43 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B28EA8287C; Fri, 7 Dec 2018 09:59:42 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qt1-x82a.google.com with SMTP id t13so3824006qtn.3; Fri, 07 Dec 2018 01:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Jc8xGuoqY5f2KgZLw2+h1RbKyzBgmbZ4ClArPTzxDGM=; b=M24NEnREuQJjCQ1f/+zDC1Hry8JjjdVb5loKrAr1UUF9fePzXA4Vnt4hwfi8sCFKFY T0DLvp6dYNPsKm84ESZYOR5ZFw/Z5D3CZE5Fn3unly6fHUdUH+Z1H7VmEIFq/BY5pqfl P/IgfsUMU8EYkp7/Ym5lMMqS3m37eHK8pkL+1mMx53sBEoOgg5CGKa5Ss98mjcObvcjQ JD4njy7kFYQ6wUYUXDrFMxiGvRO3+hQ1ndLpdwWnDWKB1d/H2WxeI090SVhsAGyZa7qw Fo/OCQtooaDJn1jzTa7TA7kybw9OQgHgbWTaJdkuitBUn2XO0bWcWyhZJORtGD8B8mEc 22JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Jc8xGuoqY5f2KgZLw2+h1RbKyzBgmbZ4ClArPTzxDGM=; b=UYrA7dKDL8CsufhIp6dYgQMtoGC0p0q+xFJ1HfCTaPKpcy5GuvSH14whowgbr4cYgp +txLqb588ChRC7PRDBp38HtpA31RENv5D0J8HSFZ4VjVQtYjQMwDM17qQwiae1l7r/fu /Pqe2ss9eJgYpaIo3S2IR7ZsRE7m5R9kk1o2f0CNs/KKsEADTSrF7tKCdTcMCuIkU2h2 RV9aBBGHTZVvviHO5JHwzgkwF3kaT9dIZwfTP6dR/Daw9JriQPMUYKkSeJUPXcvgjJCH Q5pdDTGYKchlfRa9wYp+w/4EKUW5Mrgtnpfvg3XOm5lws5VSPD9cMHJ8QSs9LL3cCOzR lIqA== X-Gm-Message-State: AA+aEWaMj7VUjflT5ksDo7IIC0MzhjUadT/mAg/kgwQ/LfHlJXYU4lSV V2vtZBwSGxpl6Lwvi6GDAWfvieQfSlGlqCwuzt+PDA== X-Google-Smtp-Source: AFSGD/WuZ1f5zBS49vFgAofOMf/WhVC+qMGV4EY2Gl4psV03gMnH0lK8jNpqIiQ+gXI0lvk7q9QUCVDNh91L5MJpE3U= X-Received: by 2002:ac8:5053:: with SMTP id h19mr1290140qtm.280.1544176782093; Fri, 07 Dec 2018 01:59:42 -0800 (PST) MIME-Version: 1.0 Received: by 2002:ac8:784:0:0:0:0:0 with HTTP; Fri, 7 Dec 2018 01:59:41 -0800 (PST) In-Reply-To: <16c12239-031e-14fd-e82a-450b242338c5@freebsd.org> References: <16c12239-031e-14fd-e82a-450b242338c5@freebsd.org> From: Mateusz Guzik Date: Fri, 7 Dec 2018 10:59:41 +0100 Message-ID: Subject: Re: rm cannot recursively delete directory on tmpfs on RPi2 To: mmel@freebsd.org Cc: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: B28EA8287C X-Spamd-Result: default: False [-5.72 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; RCVD_IN_DNSWL_NONE(0.00)[a.2.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; NEURAL_HAM_SHORT(-0.84)[-0.844,0]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; IP_SCORE(-1.87)[ip: (-6.44), ipnet: 2607:f8b0::/32(-1.51), asn: 15169(-1.30), country: US(-0.09)] X-Rspamd-Server: mx1.freebsd.org 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: Fri, 07 Dec 2018 09:59:43 -0000 On 12/7/18, Michal Meloun wrote: > > > On 07.12.2018 7:25, Mateusz Guzik wrote: >> On 12/7/18, Jia-Shiun Li wrote: >>> On Fri, Dec 7, 2018 at 12:36 AM Alan Somers wrote: >>> >>>> On Wed, Dec 5, 2018 at 10:18 PM Jia-Shiun Li >>>> wrote: >>>>> >>>>> amd64 and RPi3 do not have this issue. >>>>> >>>>> jsli@rpi2:/home/jsli 13:04 # uname -a >>>>> FreeBSD rpi2 13.0-CURRENT FreeBSD 13.0-CURRENT r341419 GENERIC-NODEBUG >>>> arm >>>>> jsli@rpi2:/home/jsli 13:05 # mount -t tmpfs tmpfs /mnt >>>>> jsli@rpi2:/home/jsli 13:05 # cd /mnt >>>>> jsli@rpi2:/mnt 13:05 # tar xf >>>>> /usr/ports/distfiles/sqlite-autoconf-3260000.tar.gz >>>>> jsli@rpi2:/mnt 13:05 # rm -rf sqlite-autoconf-3260000/ >>>>> rm: sqlite-autoconf-3260000/tea: Operation not permitted >>>>> rm: sqlite-autoconf-3260000/: Directory not empty >>>>> jsli@rpi2:/mnt 13:05 # >>>>> >>>>> -Jia-Shiun >>>> >>>> Did you check for file flags? Do "ls -lod >>>> sqlite-autoconf-3260000/tea". >>>> >>>> >>> Unlikely caused by flags I think. >>> >>> jsli@rpi2:/home/jsli # mount -t tmpfs tmpfs /mnt >>> jsli@rpi2:/home/jsli # cd /mnt >>> jsli@rpi2:/mnt # ls -R >>> jsli@rpi2:/mnt # mkdir dir >>> jsli@rpi2:/mnt # ls -R >>> dir/ >>> ls: dir: directory causes a cycle >>> jsli@rpi2:/mnt # >>> >>> >>> looks inode no for directories are wrong >>> >>> jsli@rpi2:/mnt # ll -ia >>> total 4 >>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ./ >>> 2 drwxr-xr-x 23 root wheel 512 Dec 3 17:04 ../ >>> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 dir/ >>> jsli@rpi2:/mnt # ll -ia dir >>> total 0 >>> 2 drwxr-xr-x 2 root wheel 0 Dec 7 09:55 ./ >>> 2 drwxr-xr-x 3 root wheel 36 Dec 7 09:55 ../ >>> jsli@rpi2:/mnt # >>> >> >> Ouch. >> >> Looks like 64-bit atomic on 32-bit arm don't work as advertised. >> >> While they should be fixed, I have been meaning to commit the following >> which will have a side effect of taking care of the bug you ran into: >> > > Mateusz, > where you see problem with 64-bit atomic on arm? I'm not aware of any > problem in this area. inode allocation for tmpfs (and other places) was recently changed to use 64-bit atomics (excluding mips and powerpc). So far atomic_fetchadd_64 failing to bump the number on 32-bit arm (at least for the variant used by whatever is put on rpi2) looks like a decent explanation. The code definitely works on amd64. -- Mateusz Guzik