From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756874AbdKNVWn (ORCPT ); Tue, 14 Nov 2017 16:22:43 -0500 Received: from mail.etersoft.ru ([91.232.225.46]:37110 "EHLO mail.etersoft.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754444AbdKNVWd (ORCPT ); Tue, 14 Nov 2017 16:22:33 -0500 DKIM-Filter: OpenDKIM Filter v2.10.3 mail.etersoft.ru 79CA96D7B83 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Date: Wed, 15 Nov 2017 00:22:31 +0300 From: Vitaly Lipatov To: Jeff Layton Cc: wine-patches , "J. Bruce Fields" , Alexander Viro , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Christoph Hellwig Subject: Re: [PATCH v3] fs/fcntl: restore checking against COMPAT_LOFF_T_MAX for F_GETLK64 Organization: Etersoft In-Reply-To: <1510690743.4757.16.camel@kernel.org> References: <20171114134715.21649-1-lav@etersoft.ru> <20171114164818.6783-1-lav@etersoft.ru> <1510686778.4757.11.camel@kernel.org> <1510690743.4757.16.camel@kernel.org> Message-ID: User-Agent: Roundcube Webmail/1.3.3 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by nfs id vAELMlul021557 Jeff Layton писал 14.11.17 23:19: > On Tue, 2017-11-14 at 22:25 +0300, Vitaly Lipatov wrote: >> Jeff Layton писал 14.11.17 22:12: >> ... >> > Wait... >> > >> > Does this do anything at all in the case where you pass in >> > COMPAT_LOFF_T_MAX? l_start and l_len are either off_t or loff_t >> > (depending on arch). >> > >> > Either one will fit in the F_GETLK64/F_OFD_GETLK struct, so I don't see >> > a need to check here. >> >> I am not sure, can off_t be bigger than loff_t ? > > I don't think so, at least not in any possible situation we care about > here. We have this checking for ages: if (f.l_start > COMPAT_LOFF_T_MAX) ret = -EOVERFLOW; http://debian.securedservers.com/kernel/pub/linux/kernel/people/akpm/patches/2.6/2.6.15-rc5/2.6.15-rc5-mm1/broken-out/fix-overflow-tests-for-compat_sys_fcntl64-locking.patch > >> If not, we have just skip checking against COMPAT_LOFF_T_MAX. >> >> ... >> > > @@ -644,7 +644,7 @@ COMPAT_SYSCALL_DEFINE3(fcntl64, unsigned int, fd, >> > > unsigned int, cmd, >> > > err = fcntl_getlk(f.file, convert_fcntl_cmd(cmd), &flock); >> > > if (err) >> > > break; >> > > - err = fixup_compat_flock(&flock); >> > > + err = fixup_compat_flock(&flock, COMPAT_LOFF_T_MAX); >> > > if (err) >> > > return err; >> > > err = put_compat_flock64(&flock, compat_ptr(arg)); >> > >> > Maybe a simpler fix would be to just remove the fixup_compat_flock call >> > above? >> > > > Ok. If you have a test for this, mind testing and sending a patch? I think if COMPAT_LOFF_T_MAX is exists, that value can be smaller than can fit in off_t. Checking against COMPAT_LOFF_T_MAX keep old logic works for me last 10 years. I have some tests around wine project I worked on. May be later I will do additional tests. -- С уважением, Виталий Липатов, Etersoft