On Wed, Nov 07, 2018 at 08:59:24AM -0800, Rodney W. Grimes wrote:
> freebsd-geom is also probably a pretty short list.
IMHO it's one of our mailing lists that became obsolete once the initial
work was done. The bugbusters still assign to these lists, however.
ISTM that some of these assignee
On Wed, Nov 7, 2018 at 1:20 PM Poul-Henning Kamp wrote:
>
> In message <
> canczdfrk-7vbetkhfq9kkm4usrvjvh8ws_ozjidmh5336dt...@mail.gmail.com>
> , Warner Losh writes:
>
> >BIO_FLUSH is primarily done to force ordering points,
>
> Originally BIO_FLUSH was defined the way it is, to make
In message
, Warner Losh writes:
>BIO_FLUSH is primarily done to force ordering points,
Originally BIO_FLUSH was defined the way it is, to make it possible
to flush an isolated specified range on providers which support that
so that fsync(2) could be implemented that way.
I can't
On Wed, Nov 7, 2018 at 9:07 AM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Tue, 2018-11-06 at 16:17 -0800, Rodney W. Grimes wrote:
> > > >
> > > > Rodney, this was actually my original intention, however then I
> noticed in
> > > > the GEOM code there is at least one case
> Reverted, sorry. Turns out that i/o into last_sector+1 is handled
> differently. I'll probably have to use different strategy to properly fail
> out-of-bound ioctl(DIOCGDELETE) or otherwise indicate its result to the
> userland app. To my defense, this patch has been out for 3 weeks on
>
Reverted, sorry. Turns out that i/o into last_sector+1 is handled
differently. I'll probably have to use different strategy to properly fail
out-of-bound ioctl(DIOCGDELETE) or otherwise indicate its result to the
userland app. To my defense, this patch has been out for 3 weeks on
freebsd-geom, and
> On Tue, 2018-11-06 at 16:17 -0800, Rodney W. Grimes wrote:
> > >
> > > 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
Li-Wen, thanks for pointing out. I will investigate in the next few hours
and follow-up then. Perhaps I need to treat out-of-the bounds BIO_DELETE
differently, which was the original issue at hand.
-Max
On Tue, Nov 6, 2018 at 9:51 PM Rodney W. Grimes <
free...@pdx.rh.cn85.dnsmgr.net> wrote:
> >
On Tue, 2018-11-06 at 16:17 -0800, Rodney W. Grimes wrote:
> >
> > 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
Hi Maxim,
There are 5 regression tests failing since this change:
https://ci.freebsd.org/job/FreeBSD-head-amd64-test/9184/testReport/
sys.geom.class.*
Can you help check them?
Best,
Li-Wen
___
svn-src-head@freebsd.org mailing list
> 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.
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
> 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
13 matches
Mail list logo
