Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752696AbdHXKDr (ORCPT ); Thu, 24 Aug 2017 06:03:47 -0400 Received: from wdc011.relay.arandomserver.com ([208.43.115.130]:37108 "EHLO wdc011.relay.arandomserver.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752195AbdHXKDo (ORCPT ); Thu, 24 Aug 2017 06:03:44 -0400 Subject: Re: Kernels v4.9+ cause short reads of block devices To: Linus Torvalds Cc: Al Viro , Linux Kernel Mailing List , Wei Fang , linux-fsdevel References: <1ae53e17-e455-4f17-0280-b0dae183a449@nazar.ca> From: Doug Nazar Message-ID: <706d597b-37bd-7725-a164-9e2b19255fac@nazar.ca> Date: Thu, 24 Aug 2017 06:03:33 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Thunderbird/54.0a2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 173.192.232.254 X-SpamExperts-Domain: wdc006.hawkhost.com X-SpamExperts-Username: relay Authentication-Results: arandomserver.com; auth=pass (login) smtp.auth=relay@wdc006.hawkhost.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.02) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZiXrQymdGY8qNmNJwTfl2xJ192kNgbkumUo HMCUQ8HXGkAwPN4M+BNtq20Hh3O6Az8x54JCQSpSh9ixc9o3H3wVCZryIsNFvaBrlzs70sT7iKmx j3Zz/WM/IwRyPjIHIwCEs+b/XGgTDsO+ElLJwRPLy5Q27uXcUQdWzBZJ7D6gWR5e973vehgRRMJd d1x498TLmX09LD4nM83KPO9ZiOIMK7n9JUG0tkF/jEO0NY30aYoNYUbVrTtEe3GW4LV9k5TlgTl6 fJxyntEfhZCKje4ZEejqcvF9whXmqNO3rZfNMqIdXj9EdeaBLWNm5S1nFwnQ08vWrPDgMXSp0PD/ +0YjMeeCQkEqUofYsXPaNx98FfQeXbCuryvNiGYRcw2pVekSMBaNT3w80AsNCBGDGO978pmhpoO7 78fYDO6sWKqYqy8V7Ry9BNz+WPPsYEAz+enW5j/4CzrmNymzPa3B4u6viTf5rRxafI3VERBHrL3V 0w7knaJOHXyb74CkvMRWnDsj+EHzOAOcJGTZeiAp3tyaP9NmbLEzYUBlJj1Mw1Gk9U21bJJYEvQ+ mjkfiZQwN2Ycnj95DBfxzNqou21wZgZ/vfLvzYWTBDhTssaXQYgNf1fgqDNXxZTBdyz2DdhKjV2t I4g+l6rCWbY0MZcgnbHsF7a8xU3eZ693aRr6FKdtTEat6v5OMq1/dYjI7gDgNzQxbdah5FQqUpBQ /ZOBeCO/QnTIgDfxZ2/WGqYvyOVteVOdo6Dvr8fbMJVJ9/erL6/4IvMfhB2h/z0m0D607pH+bbcn JMMuYxnpWh/BX5m30581doKaMMHQ+5JvvyEOHexzhSsXFiSDkTVkCkszBB9G8qN+F4qdUnhmNihU ZaffS6G6WGNm9YD6a31App4D4Z5xJ4RGzhM5OcgfWRzUhZzlEpwHJhzhpRFuH/T1TpBaybd01LvX ffaG7BTa9OIWwPNmWhbtwk4CVUxZImV0v1p74oj0h+DxjN4rdwq9UTvXru+r48YuTBQcIPAkZZI6 4CI= X-Report-Abuse-To: spam@se001.arandomserver.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1165 Lines: 32 On 8/23/17 4:13 PM, Linus Torvalds wrote: > Oh, right you are - I'm much too used to 64-bit, where > MAX_LFS_FILESIZE is basically infinite, and was jusr assuming that it > was something like the UFS bug we had not that long ago that was due > to the 32-bit limit. > > But yes, on 32-bit, we are limited by the 32-bit index into the page > cache, and we limit the index to 31 bits too, so we have (PAGE_SIZE << > 31) -1, which is that 7ffffffffff. Yeah, it's an old organically grown storage server (install images, old vms, etc.) that I can't convince myself it's worth upgrading. > The *right* patch is likely to just this instead: > > -#define MAX_LFS_FILESIZE (((loff_t)PAGE_SIZE << (BITS_PER_LONG-1))-1) > +#define MAX_LFS_FILESIZE (((loff_t)PAGE_SIZE << > BITS_PER_LONG)-PAGE_SIZE) > > which should make MAX_LFS_FILESIZE be 0xffffffff000 and you disk size > should be ok. That solves my issue. I'm curious if that check should also be in the write path. If the check had been there too I wouldn't have ended up with any corruption. I'm not sure if anything over 16TB will create/assemble (or if anybody else is crazy like me). Doug