Hi,
On 27.05.2014 13:24, Maurizio Lombardi wrote:
On Tue, May 27, 2014 at 10:43:59AM +0200, Maurizio Lombardi wrote:
But now I'm suspicious of this part of commit 3979ef4dcf:
failed:
bvec-bv_page = NULL;
bvec-bv_len = 0;
bvec-bv_offset = 0;
From: Dongsu Park dongsu.p...@profitbricks.com
Commit 3979ef4dcf3d1de55a560a3a4016c30a835df44d (bio-modify-
__bio_add_page-to-accept-pages-that-dont-start-a-new-segment-v3)
introduced a regression as reported by Jet Chen.
That results in a kernel BUG at drivers/block/virtio_blk.c:166.
To fix
Hi,
On 19.05.2014 17:55, Daniel Phillips wrote:
> On 05/18/2014 04:55 PM, Dave Chinner wrote:
> >On Fri, May 16, 2014 at 05:50:59PM -0700, Daniel Phillips wrote:
> >>We would like to offer Tux3 for review for mainline merge. We have
> >>prepared a new repository suitable for pulling:
> >>
>
Hi,
On 19.05.2014 17:55, Daniel Phillips wrote:
On 05/18/2014 04:55 PM, Dave Chinner wrote:
On Fri, May 16, 2014 at 05:50:59PM -0700, Daniel Phillips wrote:
We would like to offer Tux3 for review for mainline merge. We have
prepared a new repository suitable for pulling:
> + return -EINVAL;
> +
> + /* Its safe to start updating extents */
..
Apart from that, the whole patchset seems to work without error,
both on xfs and on ext4.
Of course I had to remove Lukas' patches before testing collapse-range.
So it would be excellent if t
...
Apart from that, the whole patchset seems to work without error,
both on xfs and on ext4.
Of course I had to remove Lukas' patches before testing collapse-range.
So it would be excellent if two patch series could get somehow merged.
Tested-by: Dongsu Park dongsu.p...@profitbricks.com
Regards,
Dongsu
in-sched.o: In function `liblockdep_pthread_mutex_unlock':
/linux/tools/perf/../lib/lockdep/include/liblockdep/mutex.h:48:
undefined reference to `lock_release'
Signed-off-by: Dongsu Park
Cc: Sasha Levin
---
tools/perf/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/per
`liblockdep_pthread_mutex_unlock':
/linux/tools/perf/../lib/lockdep/include/liblockdep/mutex.h:48:
undefined reference to `lock_release'
Signed-off-by: Dongsu Park dongsu.p...@profitbricks.com
Cc: Sasha Levin sasha.le...@oracle.com
---
tools/perf/Makefile | 3 ++-
1 file changed, 2 insertions
From: Dongsu Park
As a potential fix for a race condition in srp_free_iu(),
hold a mutex in srp_free_target_ib() before calling srp_free_iu().
In addition, also clear rx/tx ring after freeing memory.
Both rx_ring[] and tx_ring[] should be reinitialized to NULL,
to prevent other tasks from
From: Dongsu Park
Signed-off-By: Sebastian Riemer
---
drivers/infiniband/ulp/srp/ib_srp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index a0d0ca2..1b274484 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b
From: Bart Van Assche
In rport_dev_loss_timedout(), rport must be obtained by accessing
the member entry dev_loss_work, not fast_io_fail_work.
Signed-off-By: Bart Van Assche
---
drivers/scsi/scsi_transport_srp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Dongsu Park
After removing rport_delete(), rport->lld_data has to be set to NULL.
In addition to that, both srp_rport_delete() and
rport_dev_loss_timedout() must check if rport->lld_data is NULL,
before accessing to rport->lld_data or any rport's target area.
Without t
From: Dongsu Park
Unter circumstances, srp_rport_add() can make conflicts with
srp_rport_delete(), dumping the call trace written below.
That does not always occur. But its possible reason is adding
sysfs entries for the SRP target too fast, even before the
deletion hasn't finished yet
From: Dongsu Park
Hi Bart,
This patchset aims at fixing bugs that have been discovered in our own
SRP test environment so far. These patches are based on your patchset v4,
"Make ib_srp better suited for H.A. purposes",(09 Aug 2012).
The 5th patch, "fix an error accessing
From: Dongsu Park dongsu.p...@profitbricks.com
Hi Bart,
This patchset aims at fixing bugs that have been discovered in our own
SRP test environment so far. These patches are based on your patchset v4,
Make ib_srp better suited for H.A. purposes,(09 Aug 2012).
The 5th patch, fix an error
From: Dongsu Park dongsu.p...@profitbricks.com
Unter circumstances, srp_rport_add() can make conflicts with
srp_rport_delete(), dumping the call trace written below.
That does not always occur. But its possible reason is adding
sysfs entries for the SRP target too fast, even before the
deletion
From: Dongsu Park dongsu.p...@profitbricks.com
After removing rport_delete(), rport-lld_data has to be set to NULL.
In addition to that, both srp_rport_delete() and
rport_dev_loss_timedout() must check if rport-lld_data is NULL,
before accessing to rport-lld_data or any rport's target area
From: Bart Van Assche bvanass...@acm.org
In rport_dev_loss_timedout(), rport must be obtained by accessing
the member entry dev_loss_work, not fast_io_fail_work.
Signed-off-By: Bart Van Assche bvanass...@acm.org
---
drivers/scsi/scsi_transport_srp.c | 2 +-
1 file changed, 1 insertion(+), 1
From: Dongsu Park dongsu.p...@profitbricks.com
Signed-off-By: Sebastian Riemer sebastian.rie...@profitbricks.com
---
drivers/infiniband/ulp/srp/ib_srp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index a0d0ca2
From: Dongsu Park dongsu.p...@profitbricks.com
As a potential fix for a race condition in srp_free_iu(),
hold a mutex in srp_free_target_ib() before calling srp_free_iu().
In addition, also clear rx/tx ring after freeing memory.
Both rx_ring[] and tx_ring[] should be reinitialized to NULL
201 - 220 of 220 matches
Mail list logo
