From owner-freebsd-hackers@freebsd.org Sat Feb 17 15:23:42 2018 Return-Path: Delivered-To: freebsd-hackers@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 14E87F1844D for ; Sat, 17 Feb 2018 15:23:42 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-qk0-x242.google.com (mail-qk0-x242.google.com [IPv6:2607:f8b0:400d:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AD57C84F14; Sat, 17 Feb 2018 15:23:41 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-qk0-x242.google.com with SMTP id z197so7388671qkb.6; Sat, 17 Feb 2018 07:23:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PvyAoorYC6eh7RgX5lFicBHTckBDijLGRqtbiaHg6Ws=; b=HeV+N+SKVq5VC4/4b8Rmt3scRbmSKWYEiCybiWCreD/CHGym1WdihToEuBtTJ7N4Tp tZym8d9aB4sAy1nQx9om9J8rpTHx+4meqZmmUqUjafsfw4WF7lMTIDaXvF4Tv9rvUKZ1 Rqn6w3vM45A02tO56jUXLAtYnAyy2WcC4/t0SgnuUDxaMe6EZJGZ04ubazCjOJuV7rN5 LyoH2vU9Yd3XfIClQBWJyoroZtlTDta/RW45ixlAknF9x8Mtqo1oRPM9nR8VHEe+vkbT UVabgIXN4z5WiY5d31R2J3cZM0OJyGCAkjtANlMHQw2OmqCClQbvHMGQtKv2vg4UgCXz YLwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PvyAoorYC6eh7RgX5lFicBHTckBDijLGRqtbiaHg6Ws=; b=Gt/kYDmiAirxvJs9cXF6W6BLMEEfH2QCZu7jZdwxTIy2Op/Z+NraC4vsKgTbaTCrh3 +ESoM+nAZY/zcUoxunWjKWCI8lw5P8PRk3aSwK/optVCCxmKacJN5vGBZFy7eLOhU7FM Ajb2bq6hB2LDNgu8PXzRuv6CPnB27rYvK4hHuLlKVxBZjCBF4ogbqKRTwWxceLVrJg6I zPoHj2UKHlzjxYMQpvc4Vfkoaju3vd5jwmRk/ubK0aD3BAk6d8pS/5u8JiCqEaVowBgt 6uLkEvFYvrXc50ZxOE9BxPUdR3RbQV4w2FOJzvtRcE6Ppf9aQgGcDKwS4xDBXe9vHDFU 7qlw== X-Gm-Message-State: APf1xPD7X+LbVJY+MCT/9laSnnZk5ypDxCAfFkFzgIN4k0o9kti/kYFo uQyqxgbZYdv8ttx3/qrpL7WS6ItoALlSzPll2SPXYA== X-Google-Smtp-Source: AH8x226h89pYrkPaGXVlPwvsp9owIiQYzuJp5wW7S2K20wGstPlyPQqR7n7nOAXd21u3nlwu/rlU04f2mRmod/fX6Ko= X-Received: by 10.55.222.9 with SMTP id h9mr15650942qkj.58.1518881021190; Sat, 17 Feb 2018 07:23:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.58.99 with HTTP; Sat, 17 Feb 2018 07:23:40 -0800 (PST) In-Reply-To: <20180217150224.GA61118@x-wing> References: <20180217150224.GA61118@x-wing> From: Mateusz Guzik Date: Sat, 17 Feb 2018 16:23:40 +0100 Message-ID: Subject: Re: Where KASASERT fd < fdp->fd_nfiles should be? To: Mariusz Zaborski Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Feb 2018 15:23:42 -0000 On Sat, Feb 17, 2018 at 04:02:24PM +0100, Mariusz Zaborski wrote: > > KASSERT(fd >= 0 && fd < fdp->fd_nfiles, > ("%s: invalid fd=%d", __func__, fd)); > > > My question and problem is do we need this KASSERT? > The fdget_locked checks if the fd is not larger then fd_lastfile. > But the code from fdinit suggest that fd_lastfile can be larger then fd_nfiles. > pjd@ suggested that it can go over size of the table fd_ofiles array: > while (fdp->fd_lastfile >= newfdp->fd_nfiles) { > FILEDESC_SUNLOCK(fdp); > fdgrowtable(newfdp, fdp->fd_lastfile + 1); > FILEDESC_SLOCK(fdp); > } > > So the question is do we need this assertion here or maybe should we move it to > the fget_locked()/fdget_locked() functions? > While the assertion arguably can be removed, it is most definitely valid. fd_nfiles signifies the size of the table, while fd_lastfile the highest used slot. By definition it must fit the table. The code sample is used on fork where the existing table is duplicated. Allocation of the new table is performed with locks dropped, which means the old one can grow in the meantime. The while loop ensures the new table will have the right size no matter what. -- Mateusz Guzik