From owner-freebsd-current@freebsd.org Sun Aug 12 12:26:00 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 A11FC106EFC6 for ; Sun, 12 Aug 2018 12:26:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660082.outbound.protection.outlook.com [40.107.66.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 2F44585B9C for ; Sun, 12 Aug 2018 12:25:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM (52.132.44.160) by YTOPR0101MB1210.CANPRD01.PROD.OUTLOOK.COM (52.132.43.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.15; Sun, 12 Aug 2018 12:25:58 +0000 Received: from YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM ([fe80::f171:1f28:a0a2:f127]) by YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM ([fe80::f171:1f28:a0a2:f127%2]) with mapi id 15.20.1017.022; Sun, 12 Aug 2018 12:25:58 +0000 From: Rick Macklem To: Konstantin Belousov CC: "freebsd-current@FreeBSD.org" , "peter@holm.cc" Subject: Re: ffs_truncate3 panics Thread-Topic: ffs_truncate3 panics Thread-Index: AQHULkj8zfSrFB+Dkkqu0NmeGvZbQKS0RKaAgAGEoXWAAKUlgIAANVYCgACitwCAAJvZIoABYIyAgAEw+G+AAA/YgIABir2A Date: Sun, 12 Aug 2018 12:25:58 +0000 Message-ID: References: <20180807131445.GC1884@kib.kiev.ua> <20180808221647.GH1884@kib.kiev.ua> <20180809111004.GK1884@kib.kiev.ua> <20180810172941.GA2113@kib.kiev.ua> , <20180811123755.GD2113@kib.kiev.ua> In-Reply-To: <20180811123755.GD2113@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rmacklem@uoguelph.ca; x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YTOPR0101MB1210; 6:haUFWb3mmgDGH2mSr9HpzCVgsYcqYyYKDVNR4mOMgpXg5rvtb9DOc2eAq5OqkwTowG6okrGVrQsYVau8aB4vILA4hA9tg1TYIVI4wQJ7J/FuW4CcWPzU701jZ2sKEIOOHgjg+fb2knPf9K+qefVSRXKyq2MhFruMPUGBLOXqNvWHKFX9550KYHlyMTW74xhyPRqJVvZWZFke1oJVnlfl9Z22fpd8UJ6VL+eZwe3dkARkycy7o7NShJZYQZDpFk41f/obnJSnLnipTKze/bFlpC0K97ETuISDg1MXwixu1VCxpgK+oryRL4m+2ZEDabzSjh2Ivj7/INO32dr7wUHrjjxi5l/PKIgh8cVggcuzYdo1g97QB8uW80dcaeMQmDnZzBIHMW0Hc0S0JvcLHx/PWo/dyXDJVDRsN6AUf+JUc8NxRQEjPSNiyeOZKzVaBx/kZmAnOwVPjwC2SQ212q41SA==; 5:MhBf7zv369QxmSYMok/b92zVustg3qiQFk/n/FuwkFE5UtIxByRSBHadKistc5+00DVP25a8rDnywTawsAGS/Jro8ySsBInPCeSbexFtbA2hgIGZvum/dqhKh21doSGYWq5jxmgHK9h8YfiSNeuOZqK/8tK9iylRqo7qtbKtVms=; 7:n1AzGoOiugJL2xnWoRm5DBPYsD2SvXGUoNe2olJ/fTE7N5rfne3bj8mbqw+ATuqJAuTbKKgAiTCX+QHpFQjWAsz7yocqNyNCipfgq+eQdm/ahfaAxsMw39GyQVQZj1dwt3E/lals6sYYlPDA6wHBzvqGrLTOBhgIalY/vURm97EImJqieSm/3HCH693MQuNeWAjkiBx5NLYscICY5va7ZFC5EGDBQl34fD8NYwDARvUuG2Q2dTgmozHHDbAYe9cq x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7e8e4980-0d24-42eb-576d-08d6004ec241 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:YTOPR0101MB1210; x-ms-traffictypediagnostic: YTOPR0101MB1210: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:YTOPR0101MB1210; BCL:0; PCL:0; RULEID:; SRVR:YTOPR0101MB1210; x-forefront-prvs: 0762FFD075 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(136003)(39860400002)(396003)(189003)(199004)(106356001)(105586002)(478600001)(25786009)(6506007)(486006)(316002)(786003)(476003)(74316002)(305945005)(33656002)(5250100002)(11346002)(446003)(14454004)(26005)(99286004)(7116003)(5660300001)(74482002)(2900100001)(53936002)(54906003)(186003)(229853002)(8936002)(9686003)(55016002)(76176011)(6436002)(1411001)(93886005)(6916009)(102836004)(7696005)(6246003)(86362001)(4326008)(39060400002)(14444005)(68736007)(97736004)(8676002)(81166006)(256004)(81156014)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTOPR0101MB1210; H:YTOPR0101MB1820.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-microsoft-antispam-message-info: cfJHVCbSktdHZiBGTskQcK/HaqNodMsPmafnNJlecmJPTdgOUfNLgTHwBcWcuA2daTm4yg0728J1DyQuhoE/SSvqIZUN9lfpp/aoxmu859R6R7gNnRWkwI4BH86OVEMt8ZcozFKQ7ky9UkjpD4FRa5sK2Z4hBKoaXs7vEmg4TnbbDRHEN1rJaxl6NlPaYoxDnH4WbKdOmZylCDnycp0r6V4YSpwMz/bh8KFQHK18+NCiVj32PJ7opaJv9KSdlmiseqTIF8m+AgTqz6WiBlnbXcKAiqusrvltfl+cnJLbwBpATAlbAeVRHCjNbIc0CA1h2EiYQGmvIfV6AdS9PFRrmXbLpQoCZY7k6mZ7EolxaCY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 7e8e4980-0d24-42eb-576d-08d6004ec241 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Aug 2018 12:25:58.5077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTOPR0101MB1210 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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: Sun, 12 Aug 2018 12:26:00 -0000 Konstantin Belousov wrote: [stuff snipped] >Problem with this buffer is that BX_ALTDATA bit is not set. >This is the reason why vinvalbuf(V_ALT) skips it. [more stuff snipped] >The vnode is exclusively locked. Other thread must not be able to >instantiate a buffer under us. That's what I thought, but I wasn't sure that UFS never did anything to the= buffers without the vnode lock. [more stuff snipped] >This is the patch that I posted long time ago. It is obviously related >to missed BX_ALTDATA. Can you add this patch to your kernel ? > >diff --git a/sys/ufs/ffs/ffs_balloc.c b/sys/ufs/ffs/ffs_balloc.c >index 552c295753d..6d89a229ea7 100644 >--- a/sys/ufs/ffs/ffs_balloc.c >+++ b/sys/ufs/ffs/ffs_balloc.c >@@ -682,8 +682,16 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, = int size, > ffs_blkpref_ufs2(ip, lbn, (int)lbn, > &dp->di_extb[0]), osize, nsize, flags, > cred, &bp); >- if (error) >+ if (error !=3D 0) { >+ /* getblk does truncation, if need= ed */ >+ bp =3D getblk(vp, -1 - lbn, osize,= 0, 0, >+ GB_NOCREAT); >+ if (bp !=3D NULL) { >+ bp->b_xflags |=3D BX_ALTDA= TA; >+ brelse(bp); >+ } > return (error); >+ } > bp->b_xflags |=3D BX_ALTDATA; > if (DOINGSOFTDEP(vp)) > softdep_setup_allocext(ip, lbn, >@@ -699,8 +707,17 @@ ffs_balloc_ufs2(struct vnode *vp, off_t startoffset, = int size, > error =3D ffs_alloc(ip, lbn, > ffs_blkpref_ufs2(ip, lbn, (int)lbn, &dp->di_ext= b[0]), > nsize, flags, cred, &newb); >- if (error) >+ if (error !=3D 0) { >+ bp =3D getblk(vp, -1 - lbn, nsize, 0, 0, >+ GB_NOCREAT); >+ if (bp !=3D NULL) { >+ bp->b_xflags |=3D BX_ALTDATA; >+ bp->b_flags |=3D B_RELBUF | B_INVA= L; >+ bp->b_flags &=3D ~B_ASYNC; >+ brelse(bp); >+ } > return (error); >+ } > bp =3D getblk(vp, -1 - lbn, nsize, 0, 0, gbflags); > bp->b_blkno =3D fsbtodb(fs, newb); > bp->b_xflags |=3D BX_ALTDATA; I don't think this patch helped. I still get printf()s with b_xflags =3D=3D= clear with it applied. I haven't gotten one that would cause the panic yet, but it didn't make the BX_ALTDATA flag get set. However, I have narrowed down how the ones that cause a panic() occur. Turns out I was wrong when I said di_size =3D=3D 0 for all these files. They don't store any data, but if an application does a truncate(2) with le= ngth > 0, the di_size does get set non-zero. It is when one of these files hits the ffs_truncate() with the extended att= ribute buffer on it, that the panic() happens. (Most of them have di_size =3D=3D 0 and return from the function in the cod= e block that starts with "if (ip->I_size =3D=3D length)" at around line#299, befor= e the panic() check.) rick