On Wed, 10 May 2023, Olaf Hering wrote:
> Wed, 10 May 2023 00:58:27 +0200 Olaf Hering :
>
> > In my debugging (with v8.0.0) it turned out the three pci_set_word
> > causes the domU to hang. In fact, it is just the last one:
> >
> >pci_set_byte(pci_conf + 0x20, 0x01); /* BMIBA: 20-23h */
> >
On Fri, May 12, 2023 at 11:16:03AM -0500, Eric Blake wrote:
>
>
> On Wed, May 10, 2023 at 10:35:55PM +0200, Kevin Wolf wrote:
> >
> > There are some error paths in blk_exp_add() that jump to 'fail:' before
> > 'exp' is even created. So we can't just unconditionally access exp->blk.
> >
> >
On Wed, May 10, 2023 at 10:36:01PM +0200, Kevin Wolf wrote:
>
> There are some conditions under which we don't actually need to do
> anything for taking a reader lock: Writing the graph is only possible
> from the main context while holding the BQL. So if a reader is running
> in the main
On Wed, May 10, 2023 at 10:36:00PM +0200, Kevin Wolf wrote:
>
> When jobs are sleeping, for example to enforce a given rate limit, they
> can be reentered early, in particular in order to get paused, to update
> the rate limit or to get cancelled.
>
> Before this patch, they behave in this
On Wed, May 10, 2023 at 10:35:59PM +0200, Kevin Wolf wrote:
>
> bdrv_unref() is a no_coroutine_fn, so calling it from coroutine context
> is invalid. Use bdrv_co_unref() instead.
>
> Signed-off-by: Kevin Wolf
> ---
> tests/unit/test-bdrv-drain.c | 2 +-
> 1 file changed, 1 insertion(+), 1
On Wed, May 10, 2023 at 10:35:58PM +0200, Kevin Wolf wrote:
>
> If we take a reader lock, we can't call any functions that take a writer
> lock internally without causing deadlocks once the reader lock is
> actually enforced in the main thread, too. Take the reader lock only
> where it is
On Thu, May 11, 2023 at 09:10:21PM -0500, Eric Blake wrote:
>
> It's already confusing that we have two very similar functions for
> wrapping the parse of a 64-bit unsigned value, differing mainly on
> whether they permit leading '-'. Adjust the signature of parse_uint()
> and
On Wed, May 10, 2023 at 10:35:57PM +0200, Kevin Wolf wrote:
>
> If we take a reader lock, we can't call any functions that take a writer
> lock internally without causing deadlocks once the reader lock is
> actually enforced in the main thread, too. Take the reader lock only
> where it is
On Wed, May 10, 2023 at 10:35:56PM +0200, Kevin Wolf wrote:
>
> qcow2_do_open() calls a few no_co_wrappers that wrap functions taking
> the graph lock internally as a writer. Therefore, it can't hold the
> reader lock across these calls, it causes deadlocks. Drop the lock
> temporarily around
On Wed, May 10, 2023 at 10:35:55PM +0200, Kevin Wolf wrote:
>
> There are some error paths in blk_exp_add() that jump to 'fail:' before
> 'exp' is even created. So we can't just unconditionally access exp->blk.
>
> Add a NULL check, and switch from exp->blk to blk, which is available
>
On Wed, May 10, 2023 at 10:35:54PM +0200, Kevin Wolf wrote:
>
> These are functions that modify the graph, so they must be able to take
> a writer lock. This is impossible if they already hold the reader lock.
> If they need a reader lock for some of their operations, they should
> take it
Le 12/05/2023 à 14:08, John Paul Adrian Glaubitz a écrit :
Hello Laurent!
On Fri, 2023-05-12 at 13:13 +0200, Laurent Vivier wrote:
This patch breaks something with LTP (20230127) test fchown05_16 on sid/sparc64:
tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s
fchown05.c:44: TPASS:
On Wed, 10 May 2023 at 21:38, Kevin Wolf wrote:
>
> There are some error paths in blk_exp_add() that jump to 'fail:' before
> 'exp' is even created. So we can't just unconditionally access exp->blk.
>
> Add a NULL check, and switch from exp->blk to blk, which is available
> earlier, just to be
Hello Laurent!
On Fri, 2023-05-12 at 13:13 +0200, Laurent Vivier wrote:
> This patch breaks something with LTP (20230127) test fchown05_16 on
> sid/sparc64:
>
> tst_test.c:1558: TINFO: Timeout per run is 0h 00m 30s
> fchown05.c:44: TPASS: fchown(3, 700, 701), change owner/group ids passed
>
On 3/30/23 15:18, Philippe Mathieu-Daudé wrote:
The 64-bit SPARC V9 syscall ABI uses 32-bit UIDs. Only enable
the 16-bit UID wrappers for 32-bit SPARC (V7 and V8).
Possibly missed in commit 992f48a036 ("Support for 32 bit
ABI on 64 bit targets (only enabled Sparc64)").
Reported-by: Gregor
Hello,
On 5/12/23 06:00, Philippe Mathieu-Daudé wrote:
Hi Cédric,
On 25/10/22 17:20, Cédric Le Goater wrote:
Store a reference on the AspeedSMC class under the flash object and
use it when accessing the flash contents. Avoiding the class cast
checkers in these hot paths improves performance
16 matches
Mail list logo
