From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C0657C02183 for ; Thu, 16 Jan 2025 16:07:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D5B76B0082; Thu, 16 Jan 2025 11:07:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 385006B0083; Thu, 16 Jan 2025 11:07:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2259C6B0085; Thu, 16 Jan 2025 11:07:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 02F886B0082 for ; Thu, 16 Jan 2025 11:07:09 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B7B7F140FAC for ; Thu, 16 Jan 2025 16:06:06 +0000 (UTC) X-FDA: 83013791532.05.07154DB Received: from mail-pl1-f173.google.com (mail-pl1-f173.google.com [209.85.214.173]) by imf07.hostedemail.com (Postfix) with ESMTP id A271440014 for ; Thu, 16 Jan 2025 16:06:04 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="XL/bIRsE"; spf=pass (imf07.hostedemail.com: domain of groeck7@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=groeck7@gmail.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737043564; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=m+WqPhV7Nyyh9gf5ceF9ds73DoDeZ3VqzjEcPveU+tA=; b=StEu6D1AwlsM6VfmGdZ1/pdxftxFJcarRw4e/Bq8HhRCjEe5g3CPOzhA7l6FdYNy8B6L7W w/hEnn6ZQI7QMvBlzx+SycYoWFDUXM3M7xuW5drSEnVFY8s9M1fpa5Pbht9bUIG/i/syba Qs8aAHY7YvozgVY+5zgHui4+ra1LU0Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737043564; a=rsa-sha256; cv=none; b=JHIITgmXlBpjP2fHnKK+rKAURaQ22x9YUoFQBhI2uXyFoUTZnZ/vxSilZjPX9FCwtt7yW4 SBr8M/6i2Ju5WjZWaG74V7Ce3kDboXaogP6cuWn6iOk0o66lK/5w67jBFKXFYvQRSF/hSy 2bStn9WEKeO8nvEyiPPHLSqV0Vs2Uog= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="XL/bIRsE"; spf=pass (imf07.hostedemail.com: domain of groeck7@gmail.com designates 209.85.214.173 as permitted sender) smtp.mailfrom=groeck7@gmail.com; dmarc=none Received: by mail-pl1-f173.google.com with SMTP id d9443c01a7336-21619108a6bso18379505ad.3 for ; Thu, 16 Jan 2025 08:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1737043563; x=1737648363; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date:message-id :reply-to; bh=m+WqPhV7Nyyh9gf5ceF9ds73DoDeZ3VqzjEcPveU+tA=; b=XL/bIRsEhq5qpSkq2t4N4Ke8Ikawf/6pEtni4q1UE74AO76wpuukOKzDRdm9mQzB+b R3gJu5Jns+Qo9CdM61O7MzZnkw/o5Z2J+Yb8YKwjcP9O74Iz++4LdOgKAk8jfbAFUNO6 us9aan9fLvvw+w07x1e8LXNtq47WhPxkJHjTmQoPf15XcOOF70UU5t8rKvOF6RF+yJNp B6XuxqLdMDBb7BbJhi+KYPgeUVoI3GuKSBUTCw4T0GkUe6oxr58qxGe3PrUe7k+w7ZlM m31koqHwLjWkBLjaHQIgdhM6HEXJSP5mexcE6Ek9sgmELRn4AdR89XRzUB+ml9K273d9 rRRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1737043563; x=1737648363; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=m+WqPhV7Nyyh9gf5ceF9ds73DoDeZ3VqzjEcPveU+tA=; b=BZmwODO6Fx7lfv2m/c+WXdz6YeeuD2wgeJbe92m1LdtoBfUhF4WENfr+fFM+Kcx9Ft Oyki1LdCGKXuNCOublg7yZCtBZszXRrPqL+/rNOoYwHhv8vvGdVnhEFGLogtli0CinTf c6vVgGh8Qf+fkHRRtkEcSBB+iI6VQOHP0DpKAit0J7zVnNGuHUa8GySF8pqVPfAqnYMV dg7DqfZDi7v2n4iKDvTLhIjGEu4XjBatHQCW1kTM+tjtkUMO1aNHE27+WwNH/BXTZLpD e97hw1gKlImnojBrVZKHqoo8jM3zoPB9j73N0en9eUYiK4PXyvJYWYytHKoP4Gamw1RH YvUw== X-Forwarded-Encrypted: i=1; AJvYcCXLMO9R2Ei1/uZbiLcc6tXp5rhEacQvCnO8jJ+T8iUMHYY1bI/MAxZcXw6CUTaXcnOhieEuV9gKQA==@kvack.org X-Gm-Message-State: AOJu0YwfqaO+aCw4gyAMAwc3cotCZXNVMVGRT8kOTuGhG1H9dqCdoRjK UC3B7OCIn7BDkT2Eml7kCLA9aIx8U42S3pHsA4mN8mf801AwdHl6 X-Gm-Gg: ASbGncs+V7ES6Xs2fkwt3klLwK8weDmPucrbzS5VkRvgH9wFS9+A/XM67kTZl3PTmNd KDMDnmg1lE0suv/+T/qCqPtlHz2/IZCX+pOuPf5tgwNlBnVsiaRvKa/KvWRay0TkeEj9KSltEu1 lRLbYjxZxRFmMaf80hLAzEyHUt3eP3taim/NaeF+SZmk4GZDndrisaX9pGJIGlWy7EJpbD8m4jU BONgyOhsEaP6ilK1BleSdYhsrA06YLajSG2jmC7NJagYQIlFm8r78yqJHpyaaEyIc9LEg== X-Google-Smtp-Source: AGHT+IG6G4/bgTk6C4+QqxKFuhA2iSXSQbqDIexA+rufjN251HRup57Q4JZZFN/a5CUl0x91k4a3zg== X-Received: by 2002:aa7:88cd:0:b0:725:f097:ed21 with SMTP id d2e1a72fcca58-72d21f471d6mr43213862b3a.15.1737043562960; Thu, 16 Jan 2025 08:06:02 -0800 (PST) Received: from server.roeck-us.net ([2600:1700:e321:62f0:da43:aeff:fecc:bfd5]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-a9bcc3234c4sm243113a12.19.2025.01.16.08.06.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jan 2025 08:06:01 -0800 (PST) Date: Thu, 16 Jan 2025 08:05:59 -0800 From: Guenter Roeck To: Jan Kara Cc: Jim Zhao , akpm@linux-foundation.org, willy@infradead.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] mm/page-writeback: Consolidate wb_thresh bumping logic into __wb_calc_thresh Message-ID: <897b426d-7ca7-4bfe-8342-d2af910f8202@roeck-us.net> References: <20241121100539.605818-1-jimzhao.ai@gmail.com> <64a44636-16ec-4a10-aeb6-e327b7f989c2@roeck-us.net> <0e5dc5f1-c2c2-4893-902b-4677c21a38c0@roeck-us.net> <2xndprbkr5k5qer4zb6ov35fa5ym7c36q6mcyapdh22ypqxivh@ahuvuqs47yd4> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2xndprbkr5k5qer4zb6ov35fa5ym7c36q6mcyapdh22ypqxivh@ahuvuqs47yd4> X-Stat-Signature: obgqrhq37t5upt9med7773ea5ac3p8z4 X-Rspamd-Queue-Id: A271440014 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1737043564-14545 X-HE-Meta: U2FsdGVkX1/da/QPdFQtTnfyu09DTFdfBDkEHFTQPPTWY+JnWCLv67Prhp0NxQIREz4uaE6a7g3dxm+9T21jrrvd6soWBOrKc+ynFKhJ9NwREwd3T/bKsq3Kt5woZLZa/cK/ZEljqsz8CqqJFiWeKQtorKg2MklZlOKUTYdhL7cqpNmg+kM92GptI3INU1Z+mPyGDalPkU1IKpen2gHmEZUn4yU4oFyhjqisIrXwTjiGPZC/qChZei+y/18Qfx+OxdoRqd8xmVeiOqnOOjHKeChWAqSQW5eyP6X0Xnf8EEnx0J+0QjOQCPoggTvVZm3lKwb7+DHOzDikvc+qXWzc8MOO0KMfoDfYhDzojbkJecHwklv2+C5GYb5G/3+CfuDtP9UzdMp4i44HRBBwiuVbYb39GVKsZl9iitK/p386+UTrRKl45PW+eC6fvsMfv1h/GU208arJAi5+nY1Mb/WKroqn3NWSWT5Z2ly6QgN7DyOMYsNXAiGLpcdzbYUydIJtjKDUX/NnEKAecYr3wNBJSkDLN+S4w++Y2/otZ/4ZQVB9CI9CchWdJhwkQ6B482unvC1ff7k5jNoz09PAs1GCk7BhjayxQIMPP3idxA4QfQWhhtFdEm+hTKnK9qy5Z/NIsjR7tVz29q1+93wCN172yIJ4Q/A44PXYOk3X9PA+FmjK/oEFN/7kTGx8PyJRejFJKXlsk1INQMp76fS+R7QKJye9AOlgrKuOS43FaPukrFvXXIpia7eMstpO6yAzjHq1DSmzw7taac31KmHdXDxtFLJmhGl4tLtg7S0P8CGWM+RF8YkzKvEkU/XQcSislTamocPb+R7gOH15LQHSzNMrri3sJZ3fowJtHBxq6UDkOKoaEoi7jyvKoSAIY1A7dJ5BO4KXk26uvpOIP431mrjkjRxQ0/nJxyFAn3xKsYSG3nMWzrBukUiKz07k7LJk7/ydqrQsLR0kOaKSjCzrKZ1 Fs+7pn0R fN4kb+XKGipx4Il7q+Fm3ksvzWuY3Fwf1lGkAAztJgBwRjTVhXYcnjS7mb7tOXGbwsQPnYLTHG9/z2g3WBrWYTvNyuAHfP2PoL8eMnkLuzy1NTSo0fm1YtHp3hvGv2hUpUn9kDbGfING1oM2dyAg/6O3wco4JBc5WrJeAlEnPov7Lq8u70Iyhg0djCMcuEahRmAc6d2FczCcgpnG1773nA1/zTnWWWPX/lNvnLtOv+N2amWPANGU/Y1iBcRIr/OMgY+gD7D6bJCvnZEGUxwlvdqV5L3Rv4FxAw34xsAp1Fx4OlfiVpBL0z1O2x1UxGfPoBlJwaIYVBwUnckc5Z/5ajP6txSmirBZaMBgtBb9ZvcZRLylX8DbsM9qrfZxGZT7F5GUKA3Yu0tOegSwGshNK+SSt3lbO5tf4AHgERktusHhO07zJd+Xwn4PaDksq6U5LG/7kf+maEgGofoxKiaFl5nvJIbbElRm6RNNm5aAa7rjhHdZ5atgk0qWag39b2yUEFyandD4STDVRmDNAVzz7DxvuRQHd5o5sJ5tFEQFvJutmxtAGhKsNf52tYn1EzEZqdsthTKuN85aJUMtpKOvs0PY8YtH7qwfam7+QKBJFUy62Tr0d5mipJE3xqg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Jan 16, 2025 at 03:56:57PM +0100, Jan Kara wrote: ... > > > > Interesting. Is there some endianness issue, by any chance ? I only see the problem > > with sheb (big endian), not with sh (little endian). I'd suspect that it is an > > emulation bug, but it is odd that the problem did not show up before. > > So far I don't have a good explanation. Let me write down here the facts, > maybe it will trigger the aha effect. > > 1) Ext2 stores the metadata in little endian ordering. We observe the > problem with the first directory entry in the folio. Both entry->rec_len > (16-bit) and entry->inode (32-bit) appear to be seen in wrong endianity > > 2) The function that fails is ext2_check_folio(). We kmap_local() the folio > in ext2_get_folio(), then in ext2_check_folio() we do: > > ext2_dirent *p; > > p = (ext2_dirent *)(kaddr + 0); > rec_len = ext2_rec_len_from_disk(p->rec_len); > ^^^ value 3072 == 0x0c00 seen here instead of correct 0x000c > this value is invalid so we go to: > ext2_error(sb, __func__, "bad entry in directory #%lu: : %s - " > "offset=%llu, inode=%lu, rec_len=%d, name_len=%d", > dir->i_ino, error, folio_pos(folio) + offs, > (unsigned long) le32_to_cpu(p->inode), > rec_len, p->name_len); > > Here rec_len is printed so we see the wrong value. Also > le32_to_cpu(p->inode) is printed which also shows number with swapped byte > ordering (the message contains inode number 27393 == 0x00006b01 but the > proper inode number is 363 == 0x0000016b). This actually releals more about > the problem because only the two bytes were swapped in the inode number > although we always treat it as 32-bit entity. So this would indeed point > more at some architectural issue rather than a problem in the filesystem / > MM. > > Note that to get at this point in the boot we must have correctly > byteswapped many other directory entries in the filesystem. So the problem > must be triggered by some parallel activity happening in the system or > something like that. > > 3) The problem appears only with MTD storage, not with IDE/SATA on the same > system + filesystem image. It it unclear how the storage influences the > reproduction, rather than that it influences timing of events in the > system. > > 4) The problem reliably happens with "mm/page-writeback: Consolidate wb_thresh > bumping logic into __wb_calc_thresh", not without it. All this patch does > is that it possibly changes a limit at which processes dirtying pages in > the page cache get throttled. Thus there are fairly limited opportunities > for how it can cause damage (I've checked for possible UAF issues or memory > corruption but I don't really see any such possibility there, it is just > crunching numbers from the mm counters and takes decision based on the > result). This change doesn't have direct on the directory ext2 code. The only > thing it does is that it possibly changes code alignment of ext2 code if it > gets linked afterwards into vmlinux image (provided ext2 is built in). Another > possibility is again that it changes timing of events in the system due to > differences in throttling of processes dirtying page cache. > > So at this point I don't have a better explanation than blame the HW. What > really tipped my conviction in this direction is the 16-bit byteswap in a > 32-bit entity. Hence I guess I'll ask Andrew to put Jim's patch back into > tree if you don't object. I agree that this is most likely an emulation problem (it would not be the first one), so please go ahead. Thanks, Guenter