On 5 December 2016 at 22:33, Vegard Nossum wrote:
> On 5 December 2016 at 21:35, Linus Torvalds
> wrote:
>> Note for Ingo and Peter: this patch has not been tested at all. But
>> Vegard did test an earlier patch of mine that just verified that yes,
>> the issue really was
On 5 December 2016 at 21:35, Linus Torvalds
wrote:
> Note for Ingo and Peter: this patch has not been tested at all. But
> Vegard did test an earlier patch of mine that just verified that yes,
> the issue really was that wait queue entries remained on the wait
> queue head just as we were about to
On 5 December 2016 at 20:11, Vegard Nossum wrote:
> On 5 December 2016 at 18:55, Linus Torvalds
> wrote:
>> On Mon, Dec 5, 2016 at 9:09 AM, Vegard Nossum
>> wrote:
>> Since you apparently can recreate this fairly easily, how about trying
>> this stupid patch
On 5 December 2016 at 18:55, Linus Torvalds
wrote:
> On Mon, Dec 5, 2016 at 9:09 AM, Vegard Nossum wrote:
>>
>> The warning shows that it made it past the list_empty_careful() check
>> in finish_wait() but then bugs out on the &wait->task_list
>> dereference.
&g
On 5 December 2016 at 19:11, Andy Lutomirski wrote:
> On Sun, Dec 4, 2016 at 3:04 PM, Vegard Nossum wrote:
>> On 23 November 2016 at 20:58, Dave Jones wrote:
>>> On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote:
>>>
>>> > [ 317.689216] BUG:
On 5 December 2016 at 12:10, Vegard Nossum wrote:
> On 5 December 2016 at 00:04, Vegard Nossum wrote:
>> FWIW I hit this as well:
>>
>> BUG: unable to handle kernel paging request at 81ff08b7
>> IP: [] __lock_acquire.isra.32+0xda/0x1a30
>> CPU: 0 PID: 2
On 5 December 2016 at 00:04, Vegard Nossum wrote:
> FWIW I hit this as well:
>
> BUG: unable to handle kernel paging request at 81ff08b7
> IP: [] __lock_acquire.isra.32+0xda/0x1a30
> CPU: 0 PID: 21744 Comm: trinity-c56 Tainted: GB 4.9.0-rc7+ #217
[...]
&g
On 23 November 2016 at 20:58, Dave Jones wrote:
> On Wed, Nov 23, 2016 at 02:34:19PM -0500, Dave Jones wrote:
>
> > [ 317.689216] BUG: Bad page state in process kworker/u8:8 pfn:4d8fd4
> > trace from just before this happened. Does this shed any light ?
> >
> > https://codemonkey.org.uk/junk
Hi,
With the attached (fuzzed) disk image I get this crash on latest
linus/master when mounting:
BTRFS: device fsid de80ced1-18ac-490c-9afb-cf0a7d66cc7e devid 1 transid
7 /dev/loop0
BTRFS info (device loop0): disk space caching is enabled
divide error: [#1] SMP KASAN
CPU: 0 PID: 955 Com
On 11/30/2015 05:34 PM, David Sterba wrote:
On Mon, Nov 30, 2015 at 02:48:51PM +0100, David Sterba wrote:
On Sun, Nov 15, 2015 at 07:21:17PM +0100, Vegard Nossum wrote:
With the attached btrfs image, I get the following splat when mounting:
"""
# mount -o loop -t btrfs ./btrfs.
Hi,
With the attached btrfs image, I get the following splat when mounting:
"""
# mount -o loop -t btrfs ./btrfs.0 /mnt/0/
BTRFS: device fsid 9006933e-2a9a-44f0-917f-514252aeec2c devid 1 transid
7 /dev/loop0
BTRFS info (device loop0): disk space caching is enabled
BUG: failure at fs/btrfs/ctre
11 matches
Mail list logo