On Mon, 2016-10-17 at 19:18 +0200, Mike Galbraith wrote:
> BTW, 4.8 either needs the btrfs deadlock fix (0ccd05285e7f) or the LTP
> testcase has to be hacked to not test btrfs. It also fails the first
> time it's run in 4.8/4.8-rt, doesn't do that in master/tip-rt.
Belay that, the first run fail
On Mon, 2016-10-17 at 18:29 +0200, Sebastian Andrzej Siewior wrote:
> On 2016-10-17 18:19:00 [+0200], Mike Galbraith wrote:
> > I used a local lock first, but lockdep was unhappy with it. Ok,
> > back
> > to the drawing board. Seems to work, but...
>
> locallock can be taken recursively so unles
On 2016-10-17 18:19:00 [+0200], Mike Galbraith wrote:
> I used a local lock first, but lockdep was unhappy with it. Ok, back
> to the drawing board. Seems to work, but...
locallock can be taken recursively so unless preemption was already
disabled, lockdep shouldn't complain. But then from the s
On Mon, 2016-10-17 at 16:24 +0200, Sebastian Andrzej Siewior wrote:
> On 2016-10-16 05:14:22 [+0200], Mike Galbraith wrote:
> >
> > In v4.7, the driver switched to percpu compression streams, disabling
> > preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead.
>
> I am not convinced th
On 2016-10-16 05:14:22 [+0200], Mike Galbraith wrote:
>
> In v4.7, the driver switched to percpu compression streams, disabling
> preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead.
I am not convinced that this will work. Nothing prevents
zram_bvec_write() to be reentrant on the sam
In v4.7, the driver switched to percpu compression streams, disabling
preemption (get/put_cpu_ptr()). Use get/put_cpu_light() instead.
Signed-off-by: Mike Galbraith
---
drivers/block/zram/zcomp.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/drivers/block/zram/zcomp.c
+++
6 matches
Mail list logo