Re: svn commit: r303019 - head/sys/geom

[Bryan Drewery]

On 8/13/16 5:45 AM, Warner Losh wrote:
> On Fri, Aug 12, 2016 at 3:06 PM, Ngie Cooper  wrote:
>> On Fri, Aug 12, 2016 at 8:23 AM, Bryan Drewery  wrote:
>>
>> ...
>>
>>> No, I was missing r303637.  Hard to say if it is related... Andrey says
>>> it's not.  I haven't dived into it yet and it's so far only happened
>>> once (out of a few tests).  We do have various customizations but I'm
>>> inclined to think it's the stock code having problems.
>>
>> I hit it again on our internal vendor tree (what bdrewery was noting
>> previously). I can provide some details about the panic if need be.
> 
> Ideally, you'd reproduce it on an unmodified -current. In a vendor tree 
> there's
> many chances that something else is odd or off that would make it hard for
> the community to help.
> 
> Warner
> 

#4  0x80477b82 in g_resize_provider_event
(arg=0xf80007f8d3a0, flag=) at
/b/mnt/src/sys/geom/geom_subr.c:668
668 KASSERT(!(pp->flags & G_PF_WITHER),
(gdb) p pp->mediasize
$2 = 0

It seems that r303637 really does cover the panic we're hitting since
the g_resize_provider_event was posted with mediasize==0 which r303637
avoids.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r303019 - head/sys/geom

[Warner Losh]

On Fri, Aug 12, 2016 at 3:06 PM, Ngie Cooper  wrote:
> On Fri, Aug 12, 2016 at 8:23 AM, Bryan Drewery  wrote:
>
> ...
>
>> No, I was missing r303637.  Hard to say if it is related... Andrey says
>> it's not.  I haven't dived into it yet and it's so far only happened
>> once (out of a few tests).  We do have various customizations but I'm
>> inclined to think it's the stock code having problems.
>
> I hit it again on our internal vendor tree (what bdrewery was noting
> previously). I can provide some details about the panic if need be.

Ideally, you'd reproduce it on an unmodified -current. In a vendor tree there's
many chances that something else is odd or off that would make it hard for
the community to help.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303019 - head/sys/geom

[Ngie Cooper]

On Fri, Aug 12, 2016 at 8:23 AM, Bryan Drewery  wrote:

...

> No, I was missing r303637.  Hard to say if it is related... Andrey says
> it's not.  I haven't dived into it yet and it's so far only happened
> once (out of a few tests).  We do have various customizations but I'm
> inclined to think it's the stock code having problems.

I hit it again on our internal vendor tree (what bdrewery was noting
previously). I can provide some details about the panic if need be.
Thanks,
-Ngie
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303019 - head/sys/geom

[Bryan Drewery]

On 8/12/16 8:21 AM, Warner Losh wrote:
> On Fri, Aug 12, 2016 at 9:17 AM, Kenneth D. Merry  wrote:
>> On Fri, Aug 12, 2016 at 09:13:58 -0600, Warner Losh wrote:
>>> On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry  wrote:
 On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote:
> On 12.08.16 03:26, Bryan Drewery wrote:
>> On r303467 I ran into this:
>>
>> panic @ time 1470916206.652, thread 0xf8000412f000:
>> g_resize_provider_event but withered
>> cpuid = 0
>> Panic occurred in module kernel loaded at 0x8020:
>>
>> Stack: --
>> kernel:kassert_panic+0x166
>> kernel:g_resize_provider_event+0x181
>> kernel:g_run_events+0x186^M^M
>> kernel:fork_exit+0x83^M^M
>> --
>>
>> No further information available unfortunately.
>
> This one is related to r302087 :)

 It looks like there is a race.  I think we need to replace the KASSERT
 in g_resize_provider_event() with a return in case the provider is
 withered.

 I won't be able to work on or test this until sometime next week.  So if
 you guys want to go ahead and make the change, please do.
>>>
>>> But why are we calling g_resize_provider on a withered object? That's
>>> the part I don't understand in this thread.
>>
>> It isn't withered when the event is queued, but it is withered by the time
>> the event is executed.
>>
>> There is a check in g_resize_provider() to make sure it isn't withered.  If
>> not, the event is queued.  But once g_resize_provider_event() runs, it is
>> withered and we run into the KASSERT.
>>
>> There isn't adequate locking and ordering in there to prevent the race
>> from happening, so the assert should be replaced with an "if (withered)
>> return" statement.
> 
> I'll grant that we may wither with outstanding events, but why is it
> withering? That seems odd. Either we're bogusly posting this event
> just before it will wither, or something else is bogusly withering it.
> Just removing the assert isn't going to fix the underlying issue.
> 
> Back to Bryan: just to be clear, this is with the latest version of
> the code, and not the intermediate version that was fixed after
> numerous problems surfaced, right?
> 

No, I was missing r303637.  Hard to say if it is related... Andrey says
it's not.  I haven't dived into it yet and it's so far only happened
once (out of a few tests).  We do have various customizations but I'm
inclined to think it's the stock code having problems.


-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r303019 - head/sys/geom

[Warner Losh]

On Fri, Aug 12, 2016 at 9:17 AM, Kenneth D. Merry  wrote:
> On Fri, Aug 12, 2016 at 09:13:58 -0600, Warner Losh wrote:
>> On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry  wrote:
>> > On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote:
>> >> On 12.08.16 03:26, Bryan Drewery wrote:
>> >> > On r303467 I ran into this:
>> >> >
>> >> > panic @ time 1470916206.652, thread 0xf8000412f000:
>> >> > g_resize_provider_event but withered
>> >> > cpuid = 0
>> >> > Panic occurred in module kernel loaded at 0x8020:
>> >> >
>> >> > Stack: --
>> >> > kernel:kassert_panic+0x166
>> >> > kernel:g_resize_provider_event+0x181
>> >> > kernel:g_run_events+0x186^M^M
>> >> > kernel:fork_exit+0x83^M^M
>> >> > --
>> >> >
>> >> > No further information available unfortunately.
>> >>
>> >> This one is related to r302087 :)
>> >
>> > It looks like there is a race.  I think we need to replace the KASSERT
>> > in g_resize_provider_event() with a return in case the provider is
>> > withered.
>> >
>> > I won't be able to work on or test this until sometime next week.  So if
>> > you guys want to go ahead and make the change, please do.
>>
>> But why are we calling g_resize_provider on a withered object? That's
>> the part I don't understand in this thread.
>
> It isn't withered when the event is queued, but it is withered by the time
> the event is executed.
>
> There is a check in g_resize_provider() to make sure it isn't withered.  If
> not, the event is queued.  But once g_resize_provider_event() runs, it is
> withered and we run into the KASSERT.
>
> There isn't adequate locking and ordering in there to prevent the race
> from happening, so the assert should be replaced with an "if (withered)
> return" statement.

I'll grant that we may wither with outstanding events, but why is it
withering? That seems odd. Either we're bogusly posting this event
just before it will wither, or something else is bogusly withering it.
Just removing the assert isn't going to fix the underlying issue.

Back to Bryan: just to be clear, this is with the latest version of
the code, and not the intermediate version that was fixed after
numerous problems surfaced, right?

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303019 - head/sys/geom

[Kenneth D. Merry]

On Fri, Aug 12, 2016 at 09:13:58 -0600, Warner Losh wrote:
> On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry  wrote:
> > On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote:
> >> On 12.08.16 03:26, Bryan Drewery wrote:
> >> > On r303467 I ran into this:
> >> >
> >> > panic @ time 1470916206.652, thread 0xf8000412f000:
> >> > g_resize_provider_event but withered
> >> > cpuid = 0
> >> > Panic occurred in module kernel loaded at 0x8020:
> >> >
> >> > Stack: --
> >> > kernel:kassert_panic+0x166
> >> > kernel:g_resize_provider_event+0x181
> >> > kernel:g_run_events+0x186^M^M
> >> > kernel:fork_exit+0x83^M^M
> >> > --
> >> >
> >> > No further information available unfortunately.
> >>
> >> This one is related to r302087 :)
> >
> > It looks like there is a race.  I think we need to replace the KASSERT
> > in g_resize_provider_event() with a return in case the provider is
> > withered.
> >
> > I won't be able to work on or test this until sometime next week.  So if
> > you guys want to go ahead and make the change, please do.
> 
> But why are we calling g_resize_provider on a withered object? That's
> the part I don't understand in this thread.

It isn't withered when the event is queued, but it is withered by the time
the event is executed.

There is a check in g_resize_provider() to make sure it isn't withered.  If
not, the event is queued.  But once g_resize_provider_event() runs, it is
withered and we run into the KASSERT.

There isn't adequate locking and ordering in there to prevent the race
from happening, so the assert should be replaced with an "if (withered)
return" statement.

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303019 - head/sys/geom

[Warner Losh]

On Fri, Aug 12, 2016 at 9:11 AM, Kenneth D. Merry  wrote:
> On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote:
>> On 12.08.16 03:26, Bryan Drewery wrote:
>> > On r303467 I ran into this:
>> >
>> > panic @ time 1470916206.652, thread 0xf8000412f000:
>> > g_resize_provider_event but withered
>> > cpuid = 0
>> > Panic occurred in module kernel loaded at 0x8020:
>> >
>> > Stack: --
>> > kernel:kassert_panic+0x166
>> > kernel:g_resize_provider_event+0x181
>> > kernel:g_run_events+0x186^M^M
>> > kernel:fork_exit+0x83^M^M
>> > --
>> >
>> > No further information available unfortunately.
>>
>> This one is related to r302087 :)
>
> It looks like there is a race.  I think we need to replace the KASSERT
> in g_resize_provider_event() with a return in case the provider is
> withered.
>
> I won't be able to work on or test this until sometime next week.  So if
> you guys want to go ahead and make the change, please do.

But why are we calling g_resize_provider on a withered object? That's
the part I don't understand in this thread.

Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303019 - head/sys/geom

[Kenneth D. Merry]

On Fri, Aug 12, 2016 at 13:38:21 +0300, Andrey V. Elsukov wrote:
> On 12.08.16 03:26, Bryan Drewery wrote:
> > On r303467 I ran into this:
> > 
> > panic @ time 1470916206.652, thread 0xf8000412f000:
> > g_resize_provider_event but withered
> > cpuid = 0
> > Panic occurred in module kernel loaded at 0x8020:
> > 
> > Stack: --
> > kernel:kassert_panic+0x166
> > kernel:g_resize_provider_event+0x181
> > kernel:g_run_events+0x186^M^M
> > kernel:fork_exit+0x83^M^M
> > --
> > 
> > No further information available unfortunately.
> 
> This one is related to r302087 :)

It looks like there is a race.  I think we need to replace the KASSERT
in g_resize_provider_event() with a return in case the provider is
withered.

I won't be able to work on or test this until sometime next week.  So if
you guys want to go ahead and make the change, please do.

Ken
-- 
Kenneth Merry
k...@freebsd.org
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"

Re: svn commit: r303019 - head/sys/geom

[Andrey V. Elsukov]

On 12.08.16 03:26, Bryan Drewery wrote:
> On r303467 I ran into this:
> 
> panic @ time 1470916206.652, thread 0xf8000412f000:
> g_resize_provider_event but withered
> cpuid = 0
> Panic occurred in module kernel loaded at 0x8020:
> 
> Stack: --
> kernel:kassert_panic+0x166
> kernel:g_resize_provider_event+0x181
> kernel:g_run_events+0x186^M^M
> kernel:fork_exit+0x83^M^M
> --
> 
> No further information available unfortunately.

This one is related to r302087 :)

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r303019 - head/sys/geom

[Bryan Drewery]

On 8/11/2016 5:26 PM, Bryan Drewery wrote:
> On 7/23/2016 10:27 PM, Peter Wemm wrote:
>> On Saturday, July 23, 2016 09:39:00 PM Peter Wemm wrote:
>>> On Tuesday, July 19, 2016 05:36:21 AM Andrey V. Elsukov wrote:
 Author: ae
 Date: Tue Jul 19 05:36:21 2016
 New Revision: 303019
 URL: https://svnweb.freebsd.org/changeset/base/303019

 Log:
   Use g_resize_provider() to change the size of GEOM_DISK provider,
   when it is being opened. This should fix the possible loss of a resize
   event when disk capacity changed.
>>>
>>> Are you sure about this?  We have machines in the freebsd.org cluster that
>>> now panic on boot:
>>>
>>> Trying to mount root from zfs:zroot []...
>>> GEOM_PART: da0 was automatically resized.
>>>   Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
>>> GEOM_PART: integrity check failed (da0, GPT)
>>>
>>> Fatal trap 12: page fault while in kernel mode
>>> cpuid = 1; apic id = 01
>>> fault virtual address   = 0x48
>>> fault code  = supervisor read data, page not present
>>> instruction pointer = 0x20:0x80740005
>>> stack pointer   = 0x28:0xfe01f119db10
>>> frame pointer   = 0x28:0xfe01f119db30
>>> code segment= base 0x0, limit 0xf, type 0x1b
>>> = DPL 0, pres 1, long 1, def32 0, gran 1
>>> processor eflags= interrupt enabled, resume, IOPL = 0
>>> current process = 13 (g_event)
>>> [ thread pid 13 tid 100019 ]
>>> Stopped at  g_part_resize+0x35: testb   $0x8,0x48(%rbx)
>>>
>>>
>>>
>>> db> where
>>> Tracing pid 13 tid 100019 td 0xf8000426fa00
>>> g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30
>>> g_resize_provider_event() at g_resize_provider_event+0xb5/frame
>>> 0xfe01f119d0 g_run_events() at g_run_events+0x20e/frame
>>> 0xfe01f119dbb0
>>> ..
>>>
>>> It is exploding here:
>>> g_part_resize(struct g_consumer *cp)
>>> {
>>> struct g_part_table *table;
>>>
>>> G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__,
>>> cp->provider->name)); g_topology_assert();
>>>
>>> table = cp->geom->softc;
>>> if (table->gpt_opened == 0) {
>>> ^ (table is null)
>>>
>>> Are you creating events too soon now?
>>
>> Sometimes da0 fails, other times da1 fails.. and sometimes it is completely 
>> fine.  There is some sort of race going on with this change during the very 
>> first moments of bootup.
>>
> 
> On r303467 I ran into this:
> 
> panic @ time 1470916206.652, thread 0xf8000412f000:
> g_resize_provider_event but withered
> cpuid = 0
> Panic occurred in module kernel loaded at 0x8020:
> 
> Stack: --
> kernel:kassert_panic+0x166
> kernel:g_resize_provider_event+0x181
> kernel:g_run_events+0x186^M^M
> kernel:fork_exit+0x83^M^M
> --
> 
> No further information available unfortunately.
> 


da13 at mps0 bus 0 scbus0 target 14 lun 0^M^M
da13:  s/n JPW9K0N00LSZYL detached^M^M
(da24:mps0: mps0:0:Target 15 supports SSU^M^M
14:mps0: 0): Target 17 supports SSU^M^M
UNMAPPED^M^M
...
g_access(969): provider da13 has error^M^M
da24 at mps0 bus 0 scbus0 target 14 lun 0^M^M
g_access(969): provider da13 has error^M^M
da24: g_access(969): provider da13 has error^M^M
da24:  SCSI-6 device^M^M
da24: Serial Number JPW9K0N00LSZYL^M^M
da24: 300.000MB/s transfers^M^M
da24: Command Queueing enabled^M^M
da24: 476940MB (976773168 512 byte sectors)^M^M
da24: quirks=0x2^M^M
(da13:da18 at mps0 bus 0 scbus0 target 12 lun 0^M^M
mps0:0:da18: 14:0):  s/n
JPW9K0N00LT8ELremoving device entry^M^M
 detached^M^M
(da13:da16 at mps0 bus 0 scbus0 target 13 lun 0^M^M
mps0:0:da16: 14:0):  s/n JPW9K0N00LTB4LPeriph
destroyed^M^M
 detached^M^M
da17 at mps0 bus 0 scbus0 target 10 lun 0^M^M
da17:  s/n JPW9K0N00JZESL detached^M^M
da20 at mps0 bus 0 scbus0 target 16 lun 0^M^M
da20:  s/n JPW9K0N00K2PEL detached^M^M
panic @ time 1470916206.652, thread 0xf8000412f000:
g_resize_provider_event but withered^M^M

...

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r303019 - head/sys/geom

[Bryan Drewery]

On 7/23/2016 10:27 PM, Peter Wemm wrote:
> On Saturday, July 23, 2016 09:39:00 PM Peter Wemm wrote:
>> On Tuesday, July 19, 2016 05:36:21 AM Andrey V. Elsukov wrote:
>>> Author: ae
>>> Date: Tue Jul 19 05:36:21 2016
>>> New Revision: 303019
>>> URL: https://svnweb.freebsd.org/changeset/base/303019
>>>
>>> Log:
>>>   Use g_resize_provider() to change the size of GEOM_DISK provider,
>>>   when it is being opened. This should fix the possible loss of a resize
>>>   event when disk capacity changed.
>>
>> Are you sure about this?  We have machines in the freebsd.org cluster that
>> now panic on boot:
>>
>> Trying to mount root from zfs:zroot []...
>> GEOM_PART: da0 was automatically resized.
>>   Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
>> GEOM_PART: integrity check failed (da0, GPT)
>>
>> Fatal trap 12: page fault while in kernel mode
>> cpuid = 1; apic id = 01
>> fault virtual address= 0x48
>> fault code   = supervisor read data, page not present
>> instruction pointer  = 0x20:0x80740005
>> stack pointer= 0x28:0xfe01f119db10
>> frame pointer= 0x28:0xfe01f119db30
>> code segment = base 0x0, limit 0xf, type 0x1b
>>  = DPL 0, pres 1, long 1, def32 0, gran 1
>> processor eflags = interrupt enabled, resume, IOPL = 0
>> current process  = 13 (g_event)
>> [ thread pid 13 tid 100019 ]
>> Stopped at  g_part_resize+0x35: testb   $0x8,0x48(%rbx)
>>
>>
>>
>> db> where
>> Tracing pid 13 tid 100019 td 0xf8000426fa00
>> g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30
>> g_resize_provider_event() at g_resize_provider_event+0xb5/frame
>> 0xfe01f119d0 g_run_events() at g_run_events+0x20e/frame
>> 0xfe01f119dbb0
>> ..
>>
>> It is exploding here:
>> g_part_resize(struct g_consumer *cp)
>> {
>> struct g_part_table *table;
>>
>> G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__,
>> cp->provider->name)); g_topology_assert();
>>
>> table = cp->geom->softc;
>> if (table->gpt_opened == 0) {
>> ^ (table is null)
>>
>> Are you creating events too soon now?
> 
> Sometimes da0 fails, other times da1 fails.. and sometimes it is completely 
> fine.  There is some sort of race going on with this change during the very 
> first moments of bootup.
> 

On r303467 I ran into this:

panic @ time 1470916206.652, thread 0xf8000412f000:
g_resize_provider_event but withered
cpuid = 0
Panic occurred in module kernel loaded at 0x8020:

Stack: --
kernel:kassert_panic+0x166
kernel:g_resize_provider_event+0x181
kernel:g_run_events+0x186^M^M
kernel:fork_exit+0x83^M^M
--

No further information available unfortunately.

-- 
Regards,
Bryan Drewery



signature.asc
Description: OpenPGP digital signature

Re: svn commit: r303019 - head/sys/geom

[Peter Wemm]

On Saturday, July 23, 2016 09:39:00 PM Peter Wemm wrote:
> On Tuesday, July 19, 2016 05:36:21 AM Andrey V. Elsukov wrote:
> > Author: ae
> > Date: Tue Jul 19 05:36:21 2016
> > New Revision: 303019
> > URL: https://svnweb.freebsd.org/changeset/base/303019
> > 
> > Log:
> >   Use g_resize_provider() to change the size of GEOM_DISK provider,
> >   when it is being opened. This should fix the possible loss of a resize
> >   event when disk capacity changed.
> 
> Are you sure about this?  We have machines in the freebsd.org cluster that
> now panic on boot:
> 
> Trying to mount root from zfs:zroot []...
> GEOM_PART: da0 was automatically resized.
>   Use `gpart commit da0` to save changes or `gpart undo da0` to revert them.
> GEOM_PART: integrity check failed (da0, GPT)
> 
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0x48
> fault code= supervisor read data, page not present
> instruction pointer   = 0x20:0x80740005
> stack pointer = 0x28:0xfe01f119db10
> frame pointer = 0x28:0xfe01f119db30
> code segment  = base 0x0, limit 0xf, type 0x1b
>   = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags  = interrupt enabled, resume, IOPL = 0
> current process   = 13 (g_event)
> [ thread pid 13 tid 100019 ]
> Stopped at  g_part_resize+0x35: testb   $0x8,0x48(%rbx)
> 
> 
> 
> db> where
> Tracing pid 13 tid 100019 td 0xf8000426fa00
> g_part_resize() at g_part_resize+0x35/frame 0xfe01f119db30
> g_resize_provider_event() at g_resize_provider_event+0xb5/frame
> 0xfe01f119d0 g_run_events() at g_run_events+0x20e/frame
> 0xfe01f119dbb0
> ..
> 
> It is exploding here:
> g_part_resize(struct g_consumer *cp)
> {
> struct g_part_table *table;
> 
> G_PART_TRACE((G_T_TOPOLOGY, "%s(%s)", __func__,
> cp->provider->name)); g_topology_assert();
> 
> table = cp->geom->softc;
> if (table->gpt_opened == 0) {
> ^ (table is null)
> 
> Are you creating events too soon now?

Sometimes da0 fails, other times da1 fails.. and sometimes it is completely 
fine.  There is some sort of race going on with this change during the very 
first moments of bootup.

-- 
Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV
UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246

signature.asc
Description: This is a digitally signed message part.

Re: svn commit: r303019 - head/sys/geom

[Sepherosa Ziehau]

Thanks!

On Tue, Jul 19, 2016 at 1:36 PM, Andrey V. Elsukov  wrote:
> Author: ae
> Date: Tue Jul 19 05:36:21 2016
> New Revision: 303019
> URL: https://svnweb.freebsd.org/changeset/base/303019
>
> Log:
>   Use g_resize_provider() to change the size of GEOM_DISK provider,
>   when it is being opened. This should fix the possible loss of a resize
>   event when disk capacity changed.
>
>   PR:   211028
>   Reported by:  Dexuan Cui 
>   MFC after:3 weeks
>
> Modified:
>   head/sys/geom/geom_disk.c
>
> Modified: head/sys/geom/geom_disk.c
> ==
> --- head/sys/geom/geom_disk.c   Tue Jul 19 04:56:59 2016(r303018)
> +++ head/sys/geom/geom_disk.c   Tue Jul 19 05:36:21 2016(r303019)
> @@ -126,7 +126,6 @@ g_disk_access(struct g_provider *pp, int
> if (error != 0)
> return (error);
> }
> -   pp->mediasize = dp->d_mediasize;
> pp->sectorsize = dp->d_sectorsize;
> if (dp->d_maxsize == 0) {
> printf("WARNING: Disk drive %s%d has no d_maxsize\n",
> @@ -143,6 +142,7 @@ g_disk_access(struct g_provider *pp, int
> pp->stripeoffset = dp->d_stripeoffset;
> pp->stripesize = dp->d_stripesize;
> dp->d_flags |= DISKFLAG_OPEN;
> +   g_resize_provider(pp, dp->d_mediasize);
> } else if ((pp->acr + pp->acw + pp->ace) > 0 && (r + w + e) == 0) {
> if (dp->d_close != NULL) {
> error = dp->d_close(dp);
> ___
> svn-src-all@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/svn-src-all
> To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"



-- 
Tomorrow Will Never Die
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"