- Original Message -
>
>
> On 12/6/19 6:09 PM, dftxbs3e wrote:
> > Hello!
> >
> > I am very happy that someone has found this issue.
> >
> > I have been suffering from rather random SIGBUS errors in similar
> > conditions described by the author.
> >
> > I don't have much
On 12/6/19 6:09 PM, dftxbs3e wrote:
> Hello!
>
> I am very happy that someone has found this issue.
>
> I have been suffering from rather random SIGBUS errors in similar
> conditions described by the author.
>
> I don't have much troubleshooting information to provide, however, I hit
> the
- Original Message -
> Please try the patch below:
I ran reproducer for 18 hours on 2 systems were it previously reproduced,
there were no crashes / SIGBUS.
Please try the patch below:
diff --git a/fs/iomap/buffered-io.c b/fs/iomap/buffered-io.c
index 512856a88106..340c15400423 100644
--- a/fs/iomap/buffered-io.c
+++ b/fs/iomap/buffered-io.c
@@ -28,6 +28,7 @@
struct iomap_page {
atomic_tread_count;
atomic_t
On Tue, Dec 03, 2019 at 09:35:28AM -0500, Jan Stancek wrote:
>
> - Original Message -
> > On Tue, Dec 03, 2019 at 07:50:39AM -0500, Jan Stancek wrote:
> > > My theory is that there's a race in iomap. There appear to be
> > > interleaved calls to iomap_set_range_uptodate() for same page
>
- Original Message -
> On Tue, Dec 03, 2019 at 07:50:39AM -0500, Jan Stancek wrote:
> > My theory is that there's a race in iomap. There appear to be
> > interleaved calls to iomap_set_range_uptodate() for same page
> > with varying offset and length. Each call sees bitmap as _not_
> >
On Tue, Dec 03, 2019 at 07:50:39AM -0500, Jan Stancek wrote:
> My theory is that there's a race in iomap. There appear to be
> interleaved calls to iomap_set_range_uptodate() for same page
> with varying offset and length. Each call sees bitmap as _not_
> entirely "uptodate" and hence doesn't call
