Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1461256imm; Mon, 3 Sep 2018 00:41:29 -0700 (PDT) X-Google-Smtp-Source: ANB0VdYAWpWpAqyIMVu4oOTzgYG/0Rtk9O1uv3c+21EmG5WZhYheK4EBmg1M+5A0kA1v/Gy7IMeZ X-Received: by 2002:a17:902:42c3:: with SMTP id h61-v6mr27319647pld.319.1535960489716; Mon, 03 Sep 2018 00:41:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535960489; cv=none; d=google.com; s=arc-20160816; b=CPtPXvdsAHAB97yutPpp2ITi7scYs2vv9A83pYjnTHwy9K/Nu0khMJKVKA9eatdnUr Oko5V9qQPuPiRSNH77qWCVeDCaAlI7+AOtT3aDXzSsgHsa/omkpw/NONpN8ojHf2aDLO 93gSjtlQXPIbVB10IZKt/JayYOtE513/v7+c3Hcb5ePXs/34s3UvOw1Q+58vIzK/Rf36 BVMKM1Kf00joj4X6lTvuJl5N7czVnlwTmezGf8kZe4PVNmHx6R4lJah1glx1gv+GJCsk aD395yMbGSnz8DfSA/A3Hnzdio9rw0w2KsD6Z6MqDBbHYs3QzJhNnlGOGiqR2AvjizLe pLgg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :arc-authentication-results; bh=+vdIIVFpRR/vxmZEgsmR75UU7/6Xtd6jr+Vl+5Op+To=; b=S77XU2CQ30ub+cql6unhQ8hFomRZYMbv4D1mmLKeUJcxxVMIiVek9rzs43oHbf/3/A 0aPQTH7vdgABcfrEBHZbuOi3WboS0BYoAma7xh6m5FFWMq0FKfEVoJnlID3Zv0qJEkbg 75O4s3b1epDccoACudtYfbusgL5RGvGBr1EbIsdhHlervFstWyWPmSVGrm9QNvQUTF6e nHwBJPo9khgUd01Bcq8oiftawY1zIl+bfIkmxmnJ2LTlarmIRFummS0GesCzCjGhr2gK JHURCSihFG5e+8N0zfArzfp5Z13xtNijfAcn3YNm3vALqnytR2AYLsI3eWP6rSpjdJhv s6lw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=K4A0lSt+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a8-v6si17916731plp.61.2018.09.03.00.41.14; Mon, 03 Sep 2018 00:41:29 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=K4A0lSt+; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726507AbeICL7D (ORCPT + 99 others); Mon, 3 Sep 2018 07:59:03 -0400 Received: from mail-wm0-f66.google.com ([74.125.82.66]:53426 "EHLO mail-wm0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725794AbeICL7D (ORCPT ); Mon, 3 Sep 2018 07:59:03 -0400 Received: by mail-wm0-f66.google.com with SMTP id b19-v6so72969wme.3; Mon, 03 Sep 2018 00:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=+vdIIVFpRR/vxmZEgsmR75UU7/6Xtd6jr+Vl+5Op+To=; b=K4A0lSt+lIgM+c1fAAhtCANLtEhVWfkJd39xXHxei9KXHgi6XaUuGVKtADJ1jfFhJi e9SbzuJ+o7yQY1gQW5yBIO3KuFwlOYp4oklDBmD9zsyZlcB/ruCG9yqlCVwpqfTnpjfL ETVGTya3rkM6bU8w/pDma2QRfGjr/TKp5EASXiI7jgPaohths0V7xAAud9xaFjjha/Hb K2i8RwiZV7z0+VBM5h/sD/W+RWniVSSn1WCCUoLD7KMPlqcePmOTTzpWxA72az/kx13y 5H7yLw/RfDiTuTI0Xvy+djV6x3gTVvxwm9MLejbE7OgFJeH/QH1LwsvkTPEaL+7/IcJF Xkjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=+vdIIVFpRR/vxmZEgsmR75UU7/6Xtd6jr+Vl+5Op+To=; b=qJh2RqnPNEW0gGa7BdxMUb634fCoYiWyIGA2giX55yTXNZFjof9I4uAZuj7VuokZRP I5wNh3GnC1HdR4zt5I++RxVtVSZT68JH/Hz010GYqhG5lPDN1TVKDwsqrOiHKDNULDgv ubQaEhodQqdsYOK3QtknvGAbwqe3ms3JSF3GrvgHXPNbtr6RhAWWq0OlViTeq0s8z2v1 o8W9NxoL3tEuQGJxPGnBlTWUPRHNXrosioj6vhfYsJSxgzcSdshs1xzWoEsBGmbBMD3T IAyNOPZxgHPZGW/0NGg/7YJG6G8fVbxfr1zO0xVF+AKI1YRfSUidvg96WWXdenFK0T22 2Mkw== X-Gm-Message-State: APzg51DO8yqntYbQ/VaWxAvESC2+YAEP/tf/U7FrWIemX1yOBa3AJVzY B0ILclajzb5e7d2PzUmo4L3g1V1c4Pk= X-Received: by 2002:a1c:1188:: with SMTP id 130-v6mr4280236wmr.138.1535960407148; Mon, 03 Sep 2018 00:40:07 -0700 (PDT) Received: from pali ([2a02:2b88:2:1::5cc6:2f]) by smtp.gmail.com with ESMTPSA id w4-v6sm18926550wro.24.2018.09.03.00.40.06 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 03 Sep 2018 00:40:06 -0700 (PDT) Date: Mon, 3 Sep 2018 09:40:05 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: OGAWA Hirofumi Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [PATCH] fat: Relax checks for sector size and media type Message-ID: <20180903074005.7e3guj24ksq2l44c@pali> References: <20180902131932.11558-1-pali.rohar@gmail.com> <87bm9ft5h5.fsf@mail.parknet.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <87bm9ft5h5.fsf@mail.parknet.co.jp> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 03 September 2018 16:17:26 OGAWA Hirofumi wrote: > Pali Rohár writes: > > > Windows fastfat.sys driver accepts also media types 0x00 and 0x01 and > > sector sizes 128 and 256 bytes. Linux mkfs.fat can format disk also to > > larger FAT sector sizes then 4096 bytes, therefore relax also upper limit > > restriction. > > > - if (!is_power_of_2(bpb->fat_sector_size) > > - || (bpb->fat_sector_size < 512) > > - || (bpb->fat_sector_size > 4096)) { > > + if (!is_power_of_2(bpb->fat_sector_size)) { > > Just relaxing validation doesn't work. The block layer doesn't support > smaller than 512, and lager than PAGE_SIZE. (And in specification, fat > doesn't support lager than 4096.) Hi! I just sent this patch for discussion, with links to (now open source) Windows implementation. I guess that Windows driver implementation is more "authoritative" then Microsoft's own specification. It is known that Windows implementation does not match Microsoft specification. I know at least 3 FAT specifications (MS EFI FAT, MS/SD card FAT, ECMA-107) and you are right that Microsoft's one does not allow sector sizes larger then 4096. If there is limitation by block layer, then: 1) Why we do not check for PAGE_SIZE? 2) Is check in fat driver really needed (if block layer checks it)? > > static inline int fat_valid_media(u8 media) > > { > > - return 0xf8 <= media || media == 0xf0; > > + return 0xf8 <= media || media == 0xf0 || media == 0x00 || media == 0x01; > > } > > #endif /* !_LINUX_MSDOS_FS_H */ > > This is ok though, this would be for ancient floppy media. Ok. -- Pali Rohár pali.rohar@gmail.com