On Mon, Mar 13, 2023 at 5:32 PM Kevin Wolf wrote:
> > So I still think that this bug is a symptom of a problem in the design
> > of request queuing.
> >
> > In fact, shouldn't request queuing was enabled at the _end_ of
> > bdrv_drained_begin (once the BlockBackend has reached a quiescent
> >
Am 10.03.2023 um 16:13 hat Paolo Bonzini geschrieben:
> On Fri, Mar 10, 2023 at 3:25 PM Kevin Wolf wrote:
> > > 1. The TRIM operation should be completed on the IDE level before
> > > draining ends.
> > > 2. Block layer requests issued after draining has begun are queued.
> > >
> > > To me, the
On 3/13/23 13:29, Fiona Ebner wrote:
In fact, shouldn't request queuing was enabled at the _end_ of
bdrv_drained_begin (once the BlockBackend has reached a quiescent
state on its own terms), rather than at the beginning (which leads to
deadlocks like this one)?
Couldn't this lead to scenarios
Am 10.03.23 um 16:13 schrieb Paolo Bonzini:
> On Fri, Mar 10, 2023 at 3:25 PM Kevin Wolf wrote:
>>> 1. The TRIM operation should be completed on the IDE level before
>>> draining ends.
>>> 2. Block layer requests issued after draining has begun are queued.
>>>
>>> To me, the conclusion seems to
On Fri, Mar 10, 2023 at 3:25 PM Kevin Wolf wrote:
> > 1. The TRIM operation should be completed on the IDE level before
> > draining ends.
> > 2. Block layer requests issued after draining has begun are queued.
> >
> > To me, the conclusion seems to be:
> > Issue all block layer requests
Am 10.03.2023 um 14:05 hat Fiona Ebner geschrieben:
> Am 09.03.23 um 18:46 schrieb Kevin Wolf:
> > Am 09.03.2023 um 14:59 hat Paolo Bonzini geschrieben:
> >> On 3/9/23 13:31, Hanna Czenczek wrote:
> >>> On 09.03.23 13:08, Paolo Bonzini wrote:
> On Thu, Mar 9, 2023 at 1:05 PM Paolo Bonzini
Am 09.03.23 um 18:46 schrieb Kevin Wolf:
> Am 09.03.2023 um 14:59 hat Paolo Bonzini geschrieben:
>> On 3/9/23 13:31, Hanna Czenczek wrote:
>>> On 09.03.23 13:08, Paolo Bonzini wrote:
On Thu, Mar 9, 2023 at 1:05 PM Paolo Bonzini wrote:
> I think having to do this is problematic, because
Am 09.03.2023 um 14:59 hat Paolo Bonzini geschrieben:
> On 3/9/23 13:31, Hanna Czenczek wrote:
> > On 09.03.23 13:08, Paolo Bonzini wrote:
> > > On Thu, Mar 9, 2023 at 1:05 PM Paolo Bonzini wrote:
> > > > I think having to do this is problematic, because the blk_drain should
> > > > leave no
On 3/9/23 13:31, Hanna Czenczek wrote:
On 09.03.23 13:08, Paolo Bonzini wrote:
On Thu, Mar 9, 2023 at 1:05 PM Paolo Bonzini wrote:
I think having to do this is problematic, because the blk_drain should
leave no pending operation.
Here it seems okay because you do it in a controlled
On 09.03.23 13:08, Paolo Bonzini wrote:
On Thu, Mar 9, 2023 at 1:05 PM Paolo Bonzini wrote:
I think having to do this is problematic, because the blk_drain should
leave no pending operation.
Here it seems okay because you do it in a controlled situation, but the
main thread can also issue
On Thu, Mar 9, 2023 at 1:05 PM Paolo Bonzini wrote:
> I think having to do this is problematic, because the blk_drain should
> leave no pending operation.
>
> Here it seems okay because you do it in a controlled situation, but the
> main thread can also issue blk_drain(), or worse
On 3/9/23 12:44, Hanna Czenczek wrote:
+ *
+ * Note that TRIM operations call blk_aio_pdiscard() multiple
+ * times (and finally increment s->blk's in-flight counter while
+ * ide_trim_bh_cb() is scheduled), so we have to loop blk_drain()
+ * until the whole operation is
Commit 7e5cdb345f77d76cb4877fe6230c4e17a7d0d0ca ("ide: Increment BB
in-flight counter for TRIM BH") fixed a problem when cancelling trims:
ide_cancel_dma_sync() drains the BB to stop a potentially ongoing
request, and then asserts that no request is active anymore. When
trying to cancel a trim,
13 matches
Mail list logo
