From owner-svn-src-all@freebsd.org Tue Nov 6 16:59:48 2018 Return-Path: Delivered-To: svn-src-all@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 BED1C1129FDA for ; Tue, 6 Nov 2018 16:59:48 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A2747803A9 for ; Tue, 6 Nov 2018 16:59:47 +0000 (UTC) (envelope-from sobomax@sippysoft.com) Received: by mail-oi1-f176.google.com with SMTP id j202-v6so11305607oih.10 for ; Tue, 06 Nov 2018 08:59:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XbfT05yRSiGrJrEEyBFNhjVksStwYPKVz3k/xf/Hd78=; b=pHrF30pAtEVqQyPzbe921b277rRU1b1ffz1ytNxAHXENV68tXYF5MABm1bt7Aj3VBM 5Fz7EdPnDZHYb20STHEXg9648v8jNms12OKBAYxoKvfJpV/LDk/h6K+R+47zaC6JVXNR GRewmSX3p8Ry08lztLN6Xekb7TUbf/G+sEC6UiQI8ORth4XV+pVITF6nN0Smt6pUVsT/ m17ZyxEcyM4PvsW/BDTu6ImmWtQSEOQMuN2FmCMCCIs55DkzT1vLbbeQ5OS8LLyJcnC9 YPK2NfKYVHD1BQrdvNAGzO/QXyNfHr84SYpTnczzlqG40Neo7Xrxgn5u5n+uU7v9svYD h6cg== X-Gm-Message-State: AGRZ1gLJJsOZafD/D5f90Mwx+hcDjL0dMSXycq7nULCqgYKI7QxxOMUP cglTp2/gquztew6dOQKn+wWiJDhyKhaWdrf9SSlktQ== X-Google-Smtp-Source: AJdET5d1bYYSNPRCO6da6/2ADvCk35qonfzHZVP34rahU7YQ/Cmqrb3GJKprilyc5vQSQnTxTU5Ku/o7VR6MuNkvgWc= X-Received: by 2002:aca:5c5:: with SMTP id 188-v6mr16720249oif.185.1541523261700; Tue, 06 Nov 2018 08:54:21 -0800 (PST) MIME-Version: 1.0 References: <201811061555.wA6FtfiT017783@repo.freebsd.org> <201811061630.wA6GUwaK096771@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201811061630.wA6GUwaK096771@pdx.rh.CN85.dnsmgr.net> From: Maxim Sobolev Date: Tue, 6 Nov 2018 08:54:10 -0800 Message-ID: Subject: Re: svn commit: r340187 - head/sys/geom To: rgrimes@freebsd.org Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org X-Rspamd-Queue-Id: A2747803A9 X-Spamd-Result: default: False [-3.98 / 200.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-0.998,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[alt1.aspmx.l.google.com,aspmx.l.google.com,alt3.aspmx.l.google.com,alt2.aspmx.l.google.com,alt4.aspmx.l.google.com]; NEURAL_HAM_SHORT(-0.95)[-0.946,0]; RCVD_IN_DNSWL_NONE(0.00)[176.167.85.209.list.dnswl.org : 127.0.5.0]; IP_SCORE(-1.03)[ipnet: 209.85.128.0/17(-3.68), asn: 15169(-1.39), country: US(-0.08)]; FORGED_SENDER(0.30)[sobomax@freebsd.org,sobomax@sippysoft.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[176.167.85.209.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[sobomax@freebsd.org,sobomax@sippysoft.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2018 16:59:49 -0000 Rodney, this was actually my original intention, however then I noticed in the GEOM code there is at least one case when BIO_FLUSH request is being generated internally with bio_offset == mediasize and bio_lenth == 0, so I thought there might be some need to allow such requests through. But I'd happily go with the stricter rule if it does no harm. I simply don't know enough about the intended use and the logic behind zero-length transfers to make that call. -Max int g_io_flush(struct g_consumer *cp) { ... bp = g_alloc_bio(); bp->bio_cmd = BIO_FLUSH; ... bp->bio_offset = cp->provider->mediasize; bp->bio_length = 0; bp->bio_data = NULL; g_io_request(bp, cp); ... } On Tue, Nov 6, 2018 at 8:31 AM Rodney W. Grimes < freebsd@pdx.rh.cn85.dnsmgr.net> wrote: > > > Author: sobomax > > Date: Tue Nov 6 15:55:41 2018 > > New Revision: 340187 > > URL: https://svnweb.freebsd.org/changeset/base/340187 > > > > Log: > > Don't allow BIO_READ, BIO_WRITE or BIO_DELETE requests that are > > fully beyond the end of providers media. The only exception is made > > for the zero length transfers which are allowed to be just on the > > boundary. Previously, any requests starting on the boundary (i.e. next > > byte after the last one) have been allowed to go through. > > > > No response from: freebsd-geom@, phk > > MFC after: 1 month > > > > Modified: > > head/sys/geom/geom_io.c > > > > Modified: head/sys/geom/geom_io.c > > ============================================================================== > > --- head/sys/geom/geom_io.c Tue Nov 6 15:52:49 2018 (r340186) > > +++ head/sys/geom/geom_io.c Tue Nov 6 15:55:41 2018 (r340187) > > @@ -420,6 +420,8 @@ g_io_check(struct bio *bp) > > return (EIO); > > if (bp->bio_offset > pp->mediasize) > > return (EIO); > > + if (bp->bio_offset == pp->mediasize && bp->bio_length > 0) > > + return (EIO); > > Isnt mediasize 0 based, such that any operation at pp->mediasize is > technically past the end of the media and should get an EIO no > matter how big it is? > > Who is doing 0 byte operations at pp->mediasize? > That code should probably be fixed rather than allowing > this special case here. > > > /* Truncate requests to the end of providers media. */ > > excess = bp->bio_offset + bp->bio_length; > > > > > > -- > Rod Grimes rgrimes@freebsd.org