Re: [PATCH] drbd: fix discard_zeroes_if_aligned regression

On Tue, 28 May 2019, Lars Ellenberg wrote: > On Fri, May 10, 2019 at 05:36:32PM +0000, Eric Wheeler wrote: > > Hi Lars, > > > > We just tried 4.19.x and this bugs still exists. We applied the patch > > which was originally submitted to this thread and it still app

Re: [PATCH] drbd: fix discard_zeroes_if_aligned regression

h which was originally submitted to this thread and it still applies cleanly and seems to work for our use case. You mentioned that you had some older code which zeroed out unaligned discard requests (or perhaps it was for a different purpose) that you may be able to use to patch this. Could you dig those up and see if we can get this solved? It would be nice to be able to use drbd with thin backing volumes from the vanilla kernel. If this has already been fixed in something newer than 4.19, then please point me to the commit. Thank you for your help! -- Eric Wheeler

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

; i += 4096) > buf[i] = 0; > return 0; > } Hi Tetsuo, Thank you for looking into this! I tried running this C program in 4.14.15 but did not get a deadlock, just OOM kills. Is the patch required to induce the deadlock? Also, what are you doing to XFS to make it trigg

Re: [PATCH 1/2] mm,vmscan: Kill global shrinker lock.

; i += 4096) > buf[i] = 0; > return 0; > } Hi Tetsuo, Thank you for looking into this! I tried running this C program in 4.14.15 but did not get a deadlock, just OOM kills. Is the patch required to induce the deadlock? Also, what are you doing to XFS to make it trigg

Re: [PATCH] drbd: fix discard_zeroes_if_aligned regression

c. My appologies, I thought this was internal to DRBD. What is the general rule here? Should linux-block always be Cc'ed with a patch? -- Eric Wheeler

Re: [PATCH] drbd: fix discard_zeroes_if_aligned regression

c. My appologies, I thought this was internal to DRBD. What is the general rule here? Should linux-block always be Cc'ed with a patch? -- Eric Wheeler

Re: [PATCH 9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

.function == 0); It looks like I need to add something to reverse_cpuid[] but I'm not sure what. Do you know what needs to be added here? -Eric -- Eric Wheeler > > Suggested-by: Jim Mattson <jmatt...@google.com> > Signed-off-by: Paolo Bonzini <pbonz...@redhat.com> &

Re: [PATCH 9/8] KVM: x86: limit MSR_IA32_SPEC_CTRL access based on CPUID availability

.function == 0); It looks like I need to add something to reverse_cpuid[] but I'm not sure what. Do you know what needs to be added here? -Eric -- Eric Wheeler > > Suggested-by: Jim Mattson > Signed-off-by: Paolo Bonzini > --- > This is for after X86_FEATURE_SPE

Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists

On Sat, 13 Jan 2018, Paolo Bonzini wrote: > Just add the new MSR at the end of the array. I'm assuming you meant emulated_msrs[], correct? -- Eric Wheeler > > Paolo > > ----- Eric Wheeler <k...@lists.ewheeler.net> ha scritto: > > On Tue, 9 Ja

Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists

On Sat, 13 Jan 2018, Paolo Bonzini wrote: > Just add the new MSR at the end of the array. I'm assuming you meant emulated_msrs[], correct? -- Eric Wheeler > > Paolo > > ----- Eric Wheeler ha scritto: > > On Tue, 9 Jan 2018, Paolo Bonzini wrote: > > > >

[PATCH] drbd: standardize kthread/workqueue thread naming to include drbd minor number

From: Eric Wheeler <g...@linux.ewheeler.net> For DRBD resources with long names that start with the same prefix, it was difficult to find all process pids for that minor since names are truncated to the task_struct's comm field (16 bytes). This patch names all processes associated with

[PATCH] drbd: standardize kthread/workqueue thread naming to include drbd minor number

From: Eric Wheeler For DRBD resources with long names that start with the same prefix, it was difficult to find all process pids for that minor since names are truncated to the task_struct's comm field (16 bytes). This patch names all processes associated with a DRBD device as drbdN_* where N

[PATCH] drbd: fix discard_zeroes_if_aligned regression

From: Eric Wheeler <g...@linux.ewheeler.net> According to drbd.conf documentation, "To not break established and expected behaviour, and suddenly cause fstrim on thin-provisioned LVs to run out-of-space instead of freeing up space, the default value is yes." This be

[PATCH] drbd: fix discard_zeroes_if_aligned regression

From: Eric Wheeler According to drbd.conf documentation, "To not break established and expected behaviour, and suddenly cause fstrim on thin-provisioned LVs to run out-of-space instead of freeing up space, the default value is yes." This behavior regressed in the REQ_OP_WRITE_ZEROE

Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists

MSR_IA32_RTIT_ADDR2_A, MSR_IA32_RTIT_ADDR2_B, MSR_IA32_RTIT_ADDR3_A, MSR_IA32_RTIT_ADDR3_B, + MSR_IA32_SPEC_CTRL, }; static unsigned num_msrs_to_save; Thank you for your help! -- Eric Wheeler > > static unsigned num_msrs_to_save; > -- > 1.8.3.1 > > >

Re: [PATCH 8/8] KVM: x86: add SPEC_CTRL and IBPB_SUPPORT to MSR and CPUID lists

MSR_IA32_RTIT_ADDR2_A, MSR_IA32_RTIT_ADDR2_B, MSR_IA32_RTIT_ADDR3_A, MSR_IA32_RTIT_ADDR3_B, + MSR_IA32_SPEC_CTRL, }; static unsigned num_msrs_to_save; Thank you for your help! -- Eric Wheeler > > static unsigned num_msrs_to_save; > -- > 1.8.3.1 > > >

Re: [PATCH v2] bcache: explicitly destroy mutex while exiting

Thanks. > > > > Reviewed-by: Coly Li <col...@suse.de> > > Looks good to me too. > > Reviewed-by: Michael Lyle <ml...@lyle.org> Should this Cc: stable to avoid the register race (possible crash?) described by Liang in other stable kernels? Reviewed-by: Eric

Re: [PATCH v2] bcache: explicitly destroy mutex while exiting

t; Reviewed-by: Coly Li > > Looks good to me too. > > Reviewed-by: Michael Lyle Should this Cc: stable to avoid the register race (possible crash?) described by Liang in other stable kernels? Reviewed-by: Eric Wheeler > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >

Re: bcache with existing ext4 filesystem

On Wed, 26 Jul 2017, Austin S. Hemmelgarn wrote: > On 2017-07-26 13:41, Eric Wheeler wrote: > > On Wed, 26 Jul 2017, Pavel Machek wrote: > > > > > Hi! > > > > > > > > > > Unfortunately, that would mean shifting 400GB data 8KB forward, >

Re: bcache with existing ext4 filesystem

On Wed, 26 Jul 2017, Austin S. Hemmelgarn wrote: > On 2017-07-26 13:41, Eric Wheeler wrote: > > On Wed, 26 Jul 2017, Pavel Machek wrote: > > > > > Hi! > > > > > > > > > > Unfortunately, that would mean shifting 400GB data 8KB forward, >

Re: bcache with existing ext4 filesystem

6,253:*,... or blk.disallow_mount=8:32 (or probably both). Just ideas, but it would be great to allow mounting only those major/minors which are authorized, particularly with increasingly complex block-device stacks. -- Eric Wheeler > > Actually, this already would be usabl

Re: bcache with existing ext4 filesystem

6,253:*,... or blk.disallow_mount=8:32 (or probably both). Just ideas, but it would be great to allow mounting only those major/minors which are authorized, particularly with increasingly complex block-device stacks. -- Eric Wheeler > > Actually, this already would be usabl

Re: v4.12: register_dcache lockdep problem on boot

It could be benign, try this patch: -Eric From: Liang Chen <liangchen.li...@gmail.com> mutex_destroy does nothing most of time, but it's better to call it to make the code future proof and it also has some meaning for like mutex debug. Signed-off-by: Liang Chen <liangchen.li...@gma

Re: v4.12: register_dcache lockdep problem on boot

It could be benign, try this patch: -Eric From: Liang Chen mutex_destroy does nothing most of time, but it's better to call it to make the code future proof and it also has some meaning for like mutex debug. Signed-off-by: Liang Chen Reviewed-by: Eric Wheeler Cc: sta...@vger.kernel.org ---

Re: bcache with existing ext4 filesystem

a partition. > > Well... if I move the partition, grub2 (etc) will be unable to access > data on it. (Plus I do not have free space before some of the > partitions I'd like to be cached). Why not use dm-linear and prepend space for the bcache superblock? If this is your boot devic

Re: bcache with existing ext4 filesystem

a partition. > > Well... if I move the partition, grub2 (etc) will be unable to access > data on it. (Plus I do not have free space before some of the > partitions I'd like to be cached). Why not use dm-linear and prepend space for the bcache superblock? If this is your boot devic

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On Wed, 14 Dec 2016, Jens Axboe wrote: > On 12/14/2016 06:50 PM, Eric Wheeler wrote: > > Hi Jens, > > > > I know you're busy, so when you get a moment: > > > > I've not yet seen your ack/nack on this yet and I want to make sure it > > gets in before the me

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On Wed, 14 Dec 2016, Jens Axboe wrote: > On 12/14/2016 06:50 PM, Eric Wheeler wrote: > > Hi Jens, > > > > I know you're busy, so when you get a moment: > > > > I've not yet seen your ack/nack on this yet and I want to make sure it > > gets in before the me

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On Tue, 31 Jan 2017, Jens Axboe wrote: > On 01/31/2017 11:14 AM, Eric Wheeler wrote: > > On Wed, 14 Dec 2016, Jens Axboe wrote: > >> On 12/14/2016 06:50 PM, Eric Wheeler wrote: > >>> Hi Jens, > >>> > >>> I know you're busy, so when you get

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On Tue, 31 Jan 2017, Jens Axboe wrote: > On 01/31/2017 11:14 AM, Eric Wheeler wrote: > > On Wed, 14 Dec 2016, Jens Axboe wrote: > >> On 12/14/2016 06:50 PM, Eric Wheeler wrote: > >>> Hi Jens, > >>> > >>> I know you're busy, so when you get

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On Wed, 14 Dec 2016, Jens Axboe wrote: > On 12/14/2016 06:50 PM, Eric Wheeler wrote: > > Hi Jens, > > > > I know you're busy, so when you get a moment: > > > > I've not yet seen your ack/nack on this yet and I want to make sure it > > gets in before the me

Re: [PULL] bcache: based on for-4.10/block, multiple updates

On Wed, 14 Dec 2016, Jens Axboe wrote: > On 12/14/2016 06:50 PM, Eric Wheeler wrote: > > Hi Jens, > > > > I know you're busy, so when you get a moment: > > > > I've not yet seen your ack/nack on this yet and I want to make sure it > > gets in before the me

Re: [PULL] bcache: based on for-4.10/block, multiple updates

that I've missed. Thanks! -Eric -- Eric Wheeler On Tue, 6 Dec 2016, Eric Wheeler wrote: > Hello Jens, > > Please pull for 4.10: > > Thank you! > > This pull request is based on the git.kernel.dk for-4.10/block branch: > > The following changes since commit 333ba053d145d

Re: [PULL] bcache: based on for-4.10/block, multiple updates

that I've missed. Thanks! -Eric -- Eric Wheeler On Tue, 6 Dec 2016, Eric Wheeler wrote: > Hello Jens, > > Please pull for 4.10: > > Thank you! > > This pull request is based on the git.kernel.dk for-4.10/block branch: > > The following changes since commit 333ba053d145d

[PULL] bcache: based on for-4.10/block, multiple updates

) Eric Wheeler (4): bcache: introduce per-process ioprio-based bypass/writeback hints bcache: documentation for ioprio cache hinting bcache: update bio->bi_opf bypass/writeback REQ_ flag hints bcache: partition support: add 16 minors per bcacheN dev

[PULL] bcache: based on for-4.10/block, multiple updates

) Eric Wheeler (4): bcache: introduce per-process ioprio-based bypass/writeback hints bcache: documentation for ioprio cache hinting bcache: update bio->bi_opf bypass/writeback REQ_ flag hints bcache: partition support: add 16 minors per bcacheN dev

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

B/0KB /s] [0/45.4K/0 iops] > >> [eta 05h:33m:13s] > >> > >> Thanks! > >> Yijing. > > > > I want to make sure that the set_capacity call that happens on cache > > attachment is not necessary when a backing device is attached without > >

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

B/0KB /s] [0/45.4K/0 iops] > >> [eta 05h:33m:13s] > >> > >> Thanks! > >> Yijing. > > > > I want to make sure that the set_capacity call that happens on cache > > attachment is not necessary when a backing device is attached without > > Hi Eri

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

On Wed, 30 Nov 2016, wangyijing wrote: > > > 在 2016/11/30 4:49, Eric Wheeler 写道: > > On Fri, 25 Nov 2016, Yijing Wang wrote: > > > >> set_capacity() has been called in bcache_device_init(), > >> remove the redundant one. > >> > &

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

On Wed, 30 Nov 2016, wangyijing wrote: > > > 在 2016/11/30 4:49, Eric Wheeler 写道: > > On Fri, 25 Nov 2016, Yijing Wang wrote: > > > >> set_capacity() has been called in bcache_device_init(), > >> remove the redundant one. > >> > >> Sig

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

On Fri, 25 Nov 2016, Yijing Wang wrote: > set_capacity() has been called in bcache_device_init(), > remove the redundant one. > > Signed-off-by: Yijing Wang > --- > drivers/md/bcache/super.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git

Re: [PATCH 1/2] bcache: Remove redundant set_capacity

On Fri, 25 Nov 2016, Yijing Wang wrote: > set_capacity() has been called in bcache_device_init(), > remove the redundant one. > > Signed-off-by: Yijing Wang > --- > drivers/md/bcache/super.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/md/bcache/super.c

Re: [PULL] bcache: multiple updates

On Sun, 30 Oct 2016, Jens Axboe wrote: > On 10/30/2016 08:00 AM, Kent Overstreet wrote: > > On Sat, Oct 29, 2016 at 06:32:38PM -0700, Eric Wheeler wrote: > > > On Thu, 27 Oct 2016, Jens Axboe wrote: > > > > > > > On 10/27/2016 05:27 PM

Re: [PULL] bcache: multiple updates

On Sun, 30 Oct 2016, Jens Axboe wrote: > On 10/30/2016 08:00 AM, Kent Overstreet wrote: > > On Sat, Oct 29, 2016 at 06:32:38PM -0700, Eric Wheeler wrote: > > > On Thu, 27 Oct 2016, Jens Axboe wrote: > > > > > > > On 10/27/2016 05:27 PM

Re: [PULL] bcache: multiple updates

On Thu, 27 Oct 2016, Jens Axboe wrote: > On 10/27/2016 05:27 PM, Eric Wheeler wrote: > > Hi Jens, > > > > Please pull this v4.9-rc2 based series of bcache updates for v4.9-rc3: > > (You may disregard the previous -rc1-based request.) > > > > git pull http

Re: [PULL] bcache: multiple updates

On Thu, 27 Oct 2016, Jens Axboe wrote: > On 10/27/2016 05:27 PM, Eric Wheeler wrote: > > Hi Jens, > > > > Please pull this v4.9-rc2 based series of bcache updates for v4.9-rc3: > > (You may disregard the previous -rc1-based request.) > > > > git pull http

Re: ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop)

On Mon, 24 Oct 2016, Kent Overstreet wrote: > On Sun, Oct 23, 2016 at 06:57:26PM -0700, Davidlohr Bueso wrote: > > On Wed, 19 Oct 2016, Peter Zijlstra wrote: > > > > > Subject: sched: Better explain sleep/wakeup > > > From: Peter Zijlstra > > > Date: Wed Oct 19 15:45:27

Re: ciao set_task_state() (was Re: [PATCH -v4 6/8] locking/mutex: Restructure wait loop)

On Mon, 24 Oct 2016, Kent Overstreet wrote: > On Sun, Oct 23, 2016 at 06:57:26PM -0700, Davidlohr Bueso wrote: > > On Wed, 19 Oct 2016, Peter Zijlstra wrote: > > > > > Subject: sched: Better explain sleep/wakeup > > > From: Peter Zijlstra > > > Date: Wed Oct 19 15:45:27 CEST 2016 > > > > > >

Re: bcachefs: Encryption (Posting for review)

brary. HMAC construction is as follows (|| means append): HMAC_{HASH,key}(data) = HASH(HASH(key) || HASH(data)) Of course you are welcome to support all of the above and let the user decide on the MAC function (poly1305 vs HMAC_{HASH,key}) and crypto function (counter-mode+block-ci

Re: bcachefs: Encryption (Posting for review)

brary. HMAC construction is as follows (|| means append): HMAC_{HASH,key}(data) = HASH(HASH(key) || HASH(data)) Of course you are welcome to support all of the above and let the user decide on the MAC function (poly1305 vs HMAC_{HASH,key}) and crypto function (counter-mode+block-ci

Re: [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ

acing CFQ. Including BFQ would be a boon for Linux and the community at large. -- Eric Wheeler [1] Based on Linux v4.1-rc1, it cleanly merges forward into v4.7: https://bitbucket.org/ewheelerinc/linux/branch/v4.1-rc1-bfq-v8 git pull https://bitbucket.org/ewheelerinc/linux.git v4.1-rc1-bfq-v8

Re: [PATCH V2 00/22] Replace the CFQ I/O Scheduler with BFQ

acing CFQ. Including BFQ would be a boon for Linux and the community at large. -- Eric Wheeler [1] Based on Linux v4.1-rc1, it cleanly merges forward into v4.7: https://bitbucket.org/ewheelerinc/linux/branch/v4.1-rc1-bfq-v8 git pull https://bitbucket.org/ewheelerinc/linux.git v4.1-rc1-bfq-v8

Re: [PATCH v3] block: make sure big bio is splitted into at most 256 bvecs

ple if check here is simple enough that it's > > probably fine. But I see no need to uglify the whole code path > > with that no_merge flag. Please drop if for now, and if we start > > caring for this path in common code we should just move the > > REQ_NOMERGE setting into the actual blk_bio_*_split helpers. > > Agreed about the no_merge thing. By removing `no_merge` this patch should cherry-peck into stable v4.3+ without merge issues by avoiding bi_rw refactor interference, too. Ming, can you send out a V4 without `no_merge` ? -- Eric Wheeler

Re: [PATCH v3] block: make sure big bio is splitted into at most 256 bvecs

ple if check here is simple enough that it's > > probably fine. But I see no need to uglify the whole code path > > with that no_merge flag. Please drop if for now, and if we start > > caring for this path in common code we should just move the > > REQ_NOMERGE setting into the actual blk_bio_*_split helpers. > > Agreed about the no_merge thing. By removing `no_merge` this patch should cherry-peck into stable v4.3+ without merge issues by avoiding bi_rw refactor interference, too. Ming, can you send out a V4 without `no_merge` ? -- Eric Wheeler

Re: [PATCH v2] block: make sure big bio is splitted into at most 256 bvecs

ES just push the problem further out into the future when bi_vcnt might again exceed BIO_MAX_PAGES? Perhaps you could elaborate if I have misunderstood. Are you suggesting that no driver should call generic_make_request when bi_vcnt > BIO_MAX_PAGES? -- Eric Wheeler [1] https://patchwork.kern

Re: [PATCH v2] block: make sure big bio is splitted into at most 256 bvecs

ES just push the problem further out into the future when bi_vcnt might again exceed BIO_MAX_PAGES? Perhaps you could elaborate if I have misunderstood. Are you suggesting that no driver should call generic_make_request when bi_vcnt > BIO_MAX_PAGES? -- Eric Wheeler [1] https://patchwork.kern

Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

On Tue, 19 Jul 2016, Lars Ellenberg wrote: > On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote: > > On Tue, Jul 12 2016 at 10:18pm -0400, > > Eric Wheeler <bca...@lists.ewheeler.net> wrote: > > > > > On Tue, 12 Jul 2016, NeilBrown wrote: >

Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

On Tue, 19 Jul 2016, Lars Ellenberg wrote: > On Tue, Jul 12, 2016 at 10:32:33PM -0400, Mike Snitzer wrote: > > On Tue, Jul 12 2016 at 10:18pm -0400, > > Eric Wheeler wrote: > > > > > On Tue, 12 Jul 2016, NeilBrown wrote: > > > > >

Re: To add, or not to add, a bio REQ_ROTATIONAL flag

[+cc from "Enable use of Solid State Hybrid Drives" https://lkml.org/lkml/2014/10/29/698 ] On Thu, 28 Jul 2016, Martin K. Petersen wrote: > >>>>> "Eric" == Eric Wheeler <bca...@lists.ewheeler.net> writes: > Eric> [...] This may imply t

Re: To add, or not to add, a bio REQ_ROTATIONAL flag

[+cc from "Enable use of Solid State Hybrid Drives" https://lkml.org/lkml/2014/10/29/698 ] On Thu, 28 Jul 2016, Martin K. Petersen wrote: > >>>>> "Eric" == Eric Wheeler writes: > Eric> [...] This may imply that > Eric> we need a new wa

To add, or not to add, a bio REQ_ROTATIONAL flag

/FADV_DONTNEED reasonable candidates? Perhaps ionice could be used used, but the concept of "priority" doesn't exactly encompass the concept of cache-bypass---so is something else needed? Other ideas? -- Eric Wheeler

To add, or not to add, a bio REQ_ROTATIONAL flag

/FADV_DONTNEED reasonable candidates? Perhaps ionice could be used used, but the concept of "priority" doesn't exactly encompass the concept of cache-bypass---so is something else needed? Other ideas? -- Eric Wheeler

Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

8pm -0400, > > Eric Wheeler <bca...@lists.ewheeler.net> wrote: > > > > > On Tue, 12 Jul 2016, NeilBrown wrote: > > > > > > > On Tue, Jul 12 2016, Lars Ellenberg wrote: > > > > > > > > > > > > > > Instead

Re: [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

8pm -0400, > > Eric Wheeler wrote: > > > > > On Tue, 12 Jul 2016, NeilBrown wrote: > > > > > > > On Tue, Jul 12 2016, Lars Ellenberg wrote: > > > > > > > > > > > > > > Instead, I suggest to distinguish bet

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

s overlap between both your patch and Mikulas's such that both #1,#2 are true and effort to solve this has been duplicated. If #3, then what might be done to resolve the overlap? What are the opinions of the authors and can a consensus be reached so we can see these pushed upstream with the appropriate stable Cc tags and ultimately fix 4.4.y? -- Eric Wheeler

Re: [dm-devel] [PATCH v2 1/1] block: fix blk_queue_split() resource exhaustion

rt to solve this has been duplicated. If #3, then what might be done to resolve the overlap? What are the opinions of the authors and can a consensus be reached so we can see these pushed upstream with the appropriate stable Cc tags and ultimately fix 4.4.y? -- Eric Wheeler

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

.cz> > > Let's send a friendly ping on these three patches after two weeks... Maciej, Were you able to get a backtrace? -- Eric Wheeler > > -- > Jiri Kosina > SUSE Labs > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache"

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

on these three patches after two weeks... Maciej, Were you able to get a backtrace? -- Eric Wheeler > > -- > Jiri Kosina > SUSE Labs > > -- > To unsubscribe from this list: send the line "unsubscribe linux-bcache" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

On Wed, 20 Apr 2016, Jiri Kosina wrote: > On Tue, 19 Apr 2016, Eric Wheeler wrote: > > > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > > expensive no-op given the fact that the thread is not marked freezable. > > > &

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

On Wed, 20 Apr 2016, Jiri Kosina wrote: > On Tue, 19 Apr 2016, Eric Wheeler wrote: > > > > bch_writeback_thread() is calling try_to_freeze(), but that's just an > > > expensive no-op given the fact that the thread is not marked freezable. > > > &

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

ing the try_to_freeze() calls are in the right place, should we simply set_freezable() on these kthreads? -- Eric Wheeler > > Signed-off-by: Jiri Kosina <jkos...@suse.cz> > --- > drivers/md/bcache/writeback.c | 3 --- > 1 file changed, 3 deletions(-) > > diff

Re: [PATCH] bcache: bch_writeback_thread() is not freezable

) calls are in the right place, should we simply set_freezable() on these kthreads? -- Eric Wheeler > > Signed-off-by: Jiri Kosina > --- > drivers/md/bcache/writeback.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/drivers/md/bcache/writeback.c b/drivers/m

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, 7 Apr 2016, Ming Lei wrote: > On Thu, Apr 7, 2016 at 9:56 AM, Eric Wheeler <bca...@lists.ewheeler.net> > wrote: > > On Thu, 7 Apr 2016, Ming Lei wrote: > > > >> On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler <bca...@lists.ewheeler.net> > >>

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, 7 Apr 2016, Ming Lei wrote: > On Thu, Apr 7, 2016 at 9:56 AM, Eric Wheeler > wrote: > > On Thu, 7 Apr 2016, Ming Lei wrote: > > > >> On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler > >> wrote: > >> > On Wed, 6 Apr 2016, Ming Lei wrote: >

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, 7 Apr 2016, Ming Lei wrote: > On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler <bca...@lists.ewheeler.net> > wrote: > > On Wed, 6 Apr 2016, Ming Lei wrote: > > > >> After arbitrary bio size is supported, the incoming bio may > >> be very big. W

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

On Thu, 7 Apr 2016, Ming Lei wrote: > On Thu, Apr 7, 2016 at 9:36 AM, Eric Wheeler > wrote: > > On Wed, 6 Apr 2016, Ming Lei wrote: > > > >> After arbitrary bio size is supported, the incoming bio may > >> be very big. We have to split the bio into small

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

> >> [bcache] > >> [ 172.665016] [] ? register_bcache+0x1006/0x1174 > >> [bcache] > > > > Fixes: 54efd50(block: make generic_make_request handle arbitrarily sized > > bios) > > Reported-by: Sebastian Roesner <sroesner-kernel...@roesner

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

che] > >> [ 172.665016] [] ? register_bcache+0x1006/0x1174 > >> [bcache] > > > > Fixes: 54efd50(block: make generic_make_request handle arbitrarily sized > > bios) > > Reported-by: Sebastian Roesner > > Reported-by: Eric Wheeler > > Cc: sta...@vger.k

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

make_request+0xb5/0x155 > > [ 172.664947] [] ? prio_io+0x85/0x95 [bcache] > > [ 172.664981] [] ? register_cache_set+0x355/0x8d0 > > [bcache] > > [ 172.665016] [] ? register_bcache+0x1006/0x1174 > > [bcache] > > Fixes: 54efd50(block: make generic_make_request handle

Re: [PATCH] block: make sure big bio is splitted into at most 256 bvecs

make_request+0xb5/0x155 > > [ 172.664947] [] ? prio_io+0x85/0x95 [bcache] > > [ 172.664981] [] ? register_cache_set+0x355/0x8d0 > > [bcache] > > [ 172.665016] [] ? register_bcache+0x1006/0x1174 > > [bcache] > > Fixes: 54efd50(block: make generic_make_request handle arb

[PATCH-RFC]: sysrq-a: graceful reboot via kernel_restart(), similar to sysrq-o

-ocalls kernel_power_off. Please comment on the patch and suggest any appropriate changes. Thank you! -- Eric Wheeler === diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 0e307c9..cf43fc8 100644 --- a/Documentation/sysrq.txt

[PATCH-RFC]: sysrq-a: graceful reboot via kernel_restart(), similar to sysrq-o

-ocalls kernel_power_off. Please comment on the patch and suggest any appropriate changes. Thank you! -- Eric Wheeler === diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt index 0e307c9..cf43fc8 100644 --- a/Documentation/sysrq.txt

Re: bcache_writeback: bch_writeback_thread...blk_queue_bio IO hang [was BUG: soft lockup]

[ changed subject, more below ] On Fri, 29 Jan 2016, Johannes Thumshirn wrote: > [ +cc Kent ] > > On Wed, Jan 27, 2016 at 02:57:25PM +, Yannis Aribaud wrote: > > Hi, > > > > After several weeks using the 4.2.6 kernel + patches from Ewheeler we just > > ran into a crash again. > > This

Re: bcache_writeback: bch_writeback_thread...blk_queue_bio IO hang [was BUG: soft lockup]

[ changed subject, more below ] On Fri, 29 Jan 2016, Johannes Thumshirn wrote: > [ +cc Kent ] > > On Wed, Jan 27, 2016 at 02:57:25PM +, Yannis Aribaud wrote: > > Hi, > > > > After several weeks using the 4.2.6 kernel + patches from Ewheeler we just > > ran into a crash again. > > This

[PULL] Re: bcache stability patches

.mail-archive.com/linux-bcache@vger.kernel.org/msg03159.html Quickly view commits here, too: https://github.com/ewheelerinc/linux/commits/bcache-patches-for-3.17 Cheers, -Eric -- Eric Wheeler, President eWheeler, Inc. dba Global Linux Security 888-LINUX26 (888-546-8926)

[PULL] Re: bcache stability patches

.mail-archive.com/linux-bcache@vger.kernel.org/msg03159.html Quickly view commits here, too: https://github.com/ewheelerinc/linux/commits/bcache-patches-for-3.17 Cheers, -Eric -- Eric Wheeler, President eWheeler, Inc. dba Global Linux Security 888-LINUX26 (888-546-8926)

Re: [PULL REQUEST]: bcache stability patches

On Wed, 2 Dec 2015, Johannes Thumshirn wrote: > On Sun, 2015-11-29 at 20:13 -0800, Eric Wheeler wrote: > > Hello all, > > > > Please pull this bcache branch with stability patches and see if it fixes > > any issue that you might have!  If you have stability patches

Re: [PULL REQUEST]: bcache stability patches

On Wed, 2 Dec 2015, Johannes Thumshirn wrote: > On Sun, 2015-11-29 at 20:13 -0800, Eric Wheeler wrote: > > Hello all, > > > > Please pull this bcache branch with stability patches and see if it fixes > > any issue that you might have!  If you have stability patches