Add Aspire 5741G KEY_TOUCHPAD_TOGGLE to wmi keymap, preventing
"acer_wmi: Unknown key number - 0x85" error.
Signed-off-by: Sergey Senozhatsky
---
drivers/platform/x86/acer-wmi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platfor
On (11/27/12 14:31), joeyli wrote:
> 於 一，2012-11-26 於 21:35 +0300，Sergey Senozhatsky 提到：
> > Add Aspire 5741G KEY_TOUCHPAD_TOGGLE to wmi keymap, preventing
> > "acer_wmi: Unknown key number - 0x85" error.
> >
> >
> > Signed-off-by: Sergey Se
On (02/07/13 22:53), Andreas Bombe wrote:
> On Sun, Jan 13, 2013 at 02:38:20PM +0300, Sergey Senozhatsky wrote:
> > On (01/12/13 20:27), Dave Jones wrote:
> > > BUG: sleeping function called from invalid context at mm/slub.c:925
> > > in_atomic(): 1, irqs_disabled
ned-off-by: Sergey Senozhatsky
---
arch/x86/kernel/traps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index ab82cbd..dff3e72 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -654,7 +654,9 @@ do_device_not_available
On (08/29/12 00:11), Borislav Petkov wrote:
> Date: Wed, 29 Aug 2012 00:11:13 +0200
> From: Borislav Petkov
> To: Sergey Senozhatsky
> Cc: Thomas Gleixner , Ingo Molnar ,
> "H. Peter Anvin" , x...@kernel.org, Steven Rostedt
> , Srikar Dronamraju ,
> Pet
Signed-off-by: Sergey Senozhatsky
---
arch/x86/kernel/traps.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index ab82cbd..fa226ef 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -654,7 +654,9 @@ do_device_not_av
On (10/16/12 23:49), Dave Jones wrote:
> I just triggered this while fuzz testing. All traces happened
> in quick succession.
>
I can easily reproduce this one
[ 5714.696329] ===
[ 5714.696332] [ INFO: suspicious RCU usage. ]
[ 5714.696336] 3.7.0-rc2-dbg-01220-g698b6f
On (10/24/12 20:06), Oleg Nesterov wrote:
> On 10/24, Sergey Senozhatsky wrote:
> >
> > small question,
> >
> > ptrace_notify() and forward calls are able to both indirectly and directly
> > call schedule(),
> > /* direct call from ptrace_stop()*/,
> &
On (10/24/12 20:52), Oleg Nesterov wrote:
> On 10/24, Sergey Senozhatsky wrote:
> >
> > On (10/24/12 20:06), Oleg Nesterov wrote:
> > > On 10/24, Sergey Senozhatsky wrote:
> > > >
> > > > small question,
> > > >
> > >
On (10/24/12 12:41), Paul E. McKenney wrote:
> On Wed, Oct 24, 2012 at 12:17:16PM -0700, Sergey Senozhatsky wrote:
> > On (10/24/12 20:52), Oleg Nesterov wrote:
> > > On 10/24, Sergey Senozhatsky wrote:
> > > >
> > > > On (10/24/12 20:06), Oleg
On (10/24/12 13:11), Paul E. McKenney wrote:
> > > >
> > > > sorry, I meant idle from RCU point of view:
> > > >
> > > > int rcu_is_cpu_idle(void)
> > > > {
> > > > return !rcu_dynticks_nesting;
> > > > }
> > >
> > > Hmmm... This reproduces on UP builds, then?
> >
> > I'll compile UP
On (10/25/12 00:32), Frederic Weisbecker wrote:
> First of all, thanks a lot for your report.
>
> 2012/10/24 Sergey Senozhatsky :
> > On (10/24/12 20:06), Oleg Nesterov wrote:
> >> On 10/24, Sergey Senozhatsky wrote:
> >> >
> >> > small question,
On (10/25/12 00:32), Frederic Weisbecker wrote:
> > My understanding is (I may be wrong) that we can schedule() from ptrace
> > chain to
> > some arbitrary task, which will continue its execution from the point where
> > RCU assumes
> > CPU as not idle, while CPU in fact still in idle state -- no
On (10/26/12 11:44), Frederic Weisbecker wrote:
> Thanks.
>
> Sergey, Dave,
>
> Does the patch I just sent you fix the issue?
>
> Patch is "[PATCH] rcu: Fix unrecovered RCU user mode in syscall_trace_leave()"
>
good job, works fine for me.
Tested-by:
: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 115 +---
1 file changed, 50 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 6edefde..7585467 100644
--- a/drivers/staging/zram
ed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_sysfs.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/zram/zram_sysfs.c
b/drivers/staging/zram/zram_sysfs.c
index edb0ed4..6be318e 100644
--- a/drivers/staging/zram/zram_sysfs.c
+++ b/driver
On (10/29/12 10:21), Nitin Gupta wrote:
> >+#include
> >
> > #include "zram_drv.h"
> >
> >@@ -54,13 +55,12 @@ static ssize_t disksize_show(struct device *dev,
> > static ssize_t disksize_store(struct device *dev,
> > struct device_attribute *attr, const char *buf, size_t len)
> > {
On (10/29/12 10:14), Nitin Gupta wrote:
>
> "Read before write" message is not valid in case ZRAM_ZERO flag is
> set. Its true only in !handle case.
>
do we actually need this message?
> Otherwise, the patch looks good to me.
>
> On a side note, zram still contains a known use-after-free bug
zram: handle mem suffixes in disk size zram_sysfs parameter
Use memparse() to allow mem suffixes in disksize sysfs number.
Examples:
echo 256K > /sys/block/zram0/disksize
echo 512M > /sys/block/zram0/disksize
echo 1G > /sys/block/zram0/disksize
Signed-off-b
message for handle_zero_page() case to a more general one
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 115 +---
1 file changed, 50 insertions(+), 65 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram
On (10/29/12 11:32), Nitin Gupta wrote:
>
> Nothing should be printed (even a debug only message) for
> the ZRAM_ZERO case. This case can be quite common for certain
> kinds of data and would cause a huge log spew. Also (!handle) case
> is not the same as zero-filled page case, so this message wo
message for handle_zero_page() case
v2: changed debug message for handle_zero_page() case to a more general one
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 113 +---
1 file changed, 48 insertions(+), 65 deletions(-)
diff --git a
_init_kthread_worker+0x70/0x70
[] ret_from_fork+0x7c/0xb0
[] ? __init_kthread_worker+0x70/0x70
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers
ite_range+0x59/0x60
[] filemap_write_and_wait_range+0x50/0x70
[] blkdev_fsync+0x24/0x50
[] do_fsync+0x5d/0x90
[] sys_fsync+0x10/0x20
[] tracesys+0xd4/0xd9
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 2 +-
1 file changed, 1 i
please ignore this patch. on a second thought -- I'm sure it will not fix
anything.
will rework and resend.
-ss
On (10/30/12 12:01), Sergey Senozhatsky wrote:
> zram: forbid IO operations from within zram_init_device()
>
> Allocation operations in zra
-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 18 --
drivers/staging/zram/zram_sysfs.c | 4
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 47f2e3a..a40ecc1 100644
On (10/30/12 11:04), Greg Kroah-Hartman wrote:
> On Tue, Oct 30, 2012 at 12:03:19PM +0300, Sergey Senozhatsky wrote:
> > zram: permit sleeping while in pool zs_malloc()
>
> 2/2? Huh? Where is 1/2?
>
> I have a raft of patches from you, all out of order, and full of
&
Hello Greg,
I'm gonna send you 2 zram patches shortly, reviewed by Nitin.
[PATCH 1/2] zram: factor-out zram_decompress_page() function
[PATCH 2/2] zram: handle mem suffixes in disk size zram_sysfs parameter
Thanks,
-ss
--
To unsubscribe from this list: send the line "unsu
zram: factor-out zram_decompress_page() function
zram_bvec_read() shared decompress functionality with
zram_read_before_write() function.
Factor-out and make commonly used zram_decompress_page() function, which also
simplified
error handling in zram_bvec_read().
Signed-off-by: Sergey
zram: handle mem suffixes in disk size zram_sysfs parameter
Use memparse() to allow mem suffixes in disksize sysfs number.
Examples:
echo 256K > /sys/block/zram0/disksize
echo 512M > /sys/block/zram0/disksize
echo 1G > /sys/block/zram0/disksize
Signed-off-b
On (10/30/12 12:18), Greg Kroah-Hartman wrote:
> > the first one:
> >
> > [PATCH 1/2] zram: factor-out zram_decompress_page() function
> > [PATCH 2/2] zram: handle mem suffixes in disk size zram_sysfs parameter
> >
> > ACKed by Nitin.
> >
> > the second one
> >
> > [PATCH 2/2] zram: permit sle
zram_bvec_read() shared decompress functionality with zram_read_before_write()
function.
Factor-out and make commonly used zram_decompress_page() function, which also
simplified
error handling in zram_bvec_read().
Signed-off-by: Sergey Senozhatsky
Reviewed-by: Nitin Gupta
---
drivers
Use memparse() to allow mem suffixes in disksize sysfs number.
Examples:
echo 256K > /sys/block/zram0/disksize
echo 512M > /sys/block/zram0/disksize
echo 1G > /sys/block/zram0/disksize
Signed-off-by: Sergey Senozhatsky
Reviewed-by: Nitin Gupta
---
drivers/sta
so errors are easier to care in
zram_bvec_write(). now we handle both use after-kfree (as you did in your
patch),
and use after-kunmap.
please review.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 91 +
1 file changed, 46 insertions(+
I've renamed the topic.
On (10/30/12 20:55), Nitin Gupta wrote:
> >>==
> >>zram: Fix use-after-free in partial I/O case
> >>
> >>When the compressed size of a page exceeds a threshold, the page is
> >>stored as-is i.e. in uncompressed form. In the partial I/O i.e.
> >>non-PAGE_SIZE'ed I/O cas
/0x20
[] ? set_page_attributes+0x11/0x12
[] ? load_module+0x12fa/0x17e8
[] ? map_vm_area+0x22/0x31
[] ? SyS_init_module+0x67/0x7d
[] ? sysenter_do_call+0x12/0x26
Reported-by: Meelis Roos
Signed-off-by: Sergey Senozhatsky
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 ++
1 file chang
On (07/01/13 12:42), Michael Wang wrote:
> On 06/26/2013 05:15 AM, Sergey Senozhatsky wrote:
> [snip]
> >
> > [ 60.277848] Chain exists of:
> > (&(&j_cdbs->work)->work) --> &j_cdbs->timer_mutex --> cpu_hotplug.lock
> &
On (07/11/13 10:43), Michael Wang wrote:
> Hi, Sergey
>
> On 07/11/2013 07:13 AM, Sergey Senozhatsky wrote:
> [snip]
> >
> >
> > Please kindly review the following patch.
> >
> >
> >
> > Remove cpu device only upon succesful c
On (07/11/13 16:47), Michael Wang wrote:
> On 07/11/2013 04:22 PM, Sergey Senozhatsky wrote:
> [snip]
> >>
> >
> > Hello Michael,
> > nice job! works fine for me.
> >
> > Reported-and-Tested-by: Sergey Senozhatsky
>
> Thanks for the test :)
&g
LZ4 compression and decompression functions require different
in signedness input/output parameters: unsigned char for
compression and signed char for decompression.
Change decompression API to require unsigned char.
Signed-off-by: Sergey Senozhatsky
---
include/linux/lz4.h | 8
ss = lzo1x_decompress_safe;
to
->compress = lz4_compress;
->decompress = lz4_decompress_unknownoutputsize;
the last one produces unneccessary compilation warning.
-ss
>2013/7/12 Sergey Senozhatsky <[2]sergey.senozhat...@gmail.com>
>
> LZ4 compr
On (07/03/13 11:37), Jerome Marchand wrote:
> Subject: Re: [PATCH staging-next] zram: protect zram_reset_device() call
> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130110
> Thunderbird/17.0.2
>
> On 06/26/2013 02:28 PM, Sergey Senozhatsky wr
yway I will put my opinion.
>
> On Wed, Sep 11, 2013 at 02:12:50AM +0300, Sergey Senozhatsky wrote:
> > Dan Carpenter noted that handle_pending_slot_free() is racy with
> > zram_reset_device(). Take write init_lock in zram_slot_free(), thus
>
> Right but "init_lock&quo
Calling handle_pending_slot_free() for every RW operation may
cause unneccessary slot_free_lock locking, because most likely
process will see NULL slot_free_rq. handle_pending_slot_free()
only when current detects that slot_free_rq is not NULL.
Signed-off-by: Sergey Senozhatsky
---
drivers
`zram->init_done != 0' equals to `zram->meta != NULL', so init_done
can be removed.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 18 +++---
drivers/staging/zram/zram_drv.h | 1 -
2 files changed, 7 insertions(+), 12 deletions(-)
diff
On (09/06/13 16:42), Jerome Marchand wrote:
> On 09/06/2013 03:47 PM, Sergey Senozhatsky wrote:
> > Calling handle_pending_slot_free() for every RW operation may
> > cause unneccessary slot_free_lock locking, because most likely
> > process will see NULL slot_free_rq. han
rw_lock.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 91d94b5..5bfbe0e 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b
`zram->init_done' in fact mimics `zram->meta != NULL' value. Introduce
init_done() function that checks zram->meta (iow, checks if initialisation
was performed), so `zram->init_done' can be removed.
v2: introduce init_done()
Signed-off-by: Sergey Senozhatsky
On (09/06/13 16:50), Jerome Marchand wrote:
> On 09/06/2013 03:52 PM, Sergey Senozhatsky wrote:
> > `zram->init_done != 0' equals to `zram->meta != NULL', so init_done
> > can be removed.
>
> The name init_done is self explanatory, meta isn't. You cou
: protect handle_pending_slot_free() with zram rw_lock.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 91d94b5..a8261b4
On (09/09/13 11:33), Dan Carpenter wrote:
> On Fri, Sep 06, 2013 at 05:55:45PM +0300, Sergey Senozhatsky wrote:
> > On (09/06/13 16:42), Jerome Marchand wrote:
> > > On 09/06/2013 03:47 PM, Sergey Senozhatsky wrote:
> > > > Calling handle_pending_slot_fre
> > Calling handle_pending_slot_free() for every RW operation may
> > cause unneccessary slot_free_lock locking, because most likely
> > process will see NULL slot_free_rq. handle_pending_slot_free()
> > only when current detects that slot_free_rq is not NULL.
> >
> > v2: protect handle_pending_sl
On (09/09/13 16:21), Dan Carpenter wrote:
> On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote:
> > > > Calling handle_pending_slot_free() for every RW operation may
> > > > cause unneccessary slot_free_lock locking, because most likely
> > >
On (09/09/13 17:52), Dan Carpenter wrote:
> On Mon, Sep 09, 2013 at 05:42:59PM +0300, Sergey Senozhatsky wrote:
> > > 3) Explain why it is safe to test zram->slot_free_rq when we are not
> > >holding the lock. I think it is unsafe. I don't want to even think
On (09/09/13 18:10), Jerome Marchand wrote:
> On 09/09/2013 03:46 PM, Jerome Marchand wrote:
> > On 09/09/2013 03:21 PM, Dan Carpenter wrote:
> >> On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote:
> >>>>> Calling handle_pending_slot_free() for
ned-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 91d94b5..7a2d4de 100644
--- a/drivers/staging/zram/zram_drv.c
+++ b/driv
`zram->init_done' in fact mimics `zram->meta != NULL' value.
Introduce init_done() function that checks zram->meta (iow,
checks if initialisation was performed), so `zram->init_done'
can be removed.
v3: init_done() in handle_pending_slot_free()
v2: introduce init_do
On (09/10/13 17:34), Sergey Senozhatsky wrote:
[..]
> >
> > Now I think we can drop the call to handle_pending_slot_free() in
> > zram_bvec_rw() altogether. As long as the write lock is held when
> > handle_pending_slot_free() is called, there is no race. It's no
10a
I'll prepare a proper patch for stable.
-ss
> --
>
> From: Sergey Senozhatsky
>
> [ Upstream commit a01c34f72e7cd2624570818f579b5ab464f93de2 ]
>
> Fix a warning from lockdep caused by calling flush_work() for
> uninitialized hotplug wor
93de2 [both backported] with
moved flush_work_sync() in radeon_irq_kms_fini() to rdev->irq.installed == true
case (am I right?). if so, then looks good to me!
-ss
> -- Steve
>
> From 39a678bf28d5c3e8266bd88ba1e831818102787e Mon Sep 17 00:00:00 2001
> From: Sergey Senozhatsky
Roos
Tested-by: Meelis Roos
Signed-off-by: Sergey Senozhatsky
---
drivers/gpu/drm/radeon/radeon_irq_kms.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_irq_kms.c
b/drivers/gpu/drm/radeon/radeon_irq_kms.c
index 443bd49..6be5d6b 1
On (09/11/13 12:13), Steven Rostedt wrote:
> On Wed, 11 Sep 2013 09:00:16 -0700
> Greg KH wrote:
>
> > On Wed, Sep 11, 2013 at 05:36:29PM +0300, Sergey Senozhatsky wrote:
> > > This one on top of stable 3.6.11 git.
> >
> > What do you mean by this?
> >
On (09/11/13 14:54), Steven Rostedt wrote:
> > On (09/11/13 12:13), Steven Rostedt wrote:
> > > On Wed, 11 Sep 2013 09:00:16 -0700
> > > Greg KH wrote:
> > >
> > > > On Wed, Sep 11, 2013 at 05:36:29PM +0300, Sergey Senozhatsky wrote:
&
On (09/12/13 15:12), Greg KH wrote:
> On Wed, Sep 11, 2013 at 02:12:50AM +0300, Sergey Senozhatsky wrote:
> > Dan Carpenter noted that handle_pending_slot_free() is racy with
> > zram_reset_device(). Take write init_lock in zram_slot_free(), thus
> > preventing any conc
’
was
here
void net_secret_init(void);
Signed-off-by: Sergey Senozhatsky
---
include/net/secure_seq.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/net/secure_seq.h b/include/net/secure_seq.h
index 52c1a90..f257486 100644
--- a/include/net/secure_seq.h
+++ b/include/net
On (08/29/13 16:06), Alex Deucher wrote:
> On Thu, Aug 29, 2013 at 4:07 PM, Greg Kroah-Hartman
> wrote:
> > On Thu, Aug 29, 2013 at 02:27:52PM -0400, Alex Deucher wrote:
> >> On Thu, Aug 29, 2013 at 6:55 AM, Meelis Roos wrote:
> >> >> Reported-by: Meelis
On (08/31/13 01:04), Frederic Weisbecker wrote:
> But stime should always be below rtime due to the calculation done by
> scale_stime()
> which roughly sums up to:
>
> stime = (stime / stime + utime) * rtime
>
> So this shouldn't happen.
>
> I couldn't manage to reproduce it though. Can y
On (08/31/13 01:04), Frederic Weisbecker wrote:
> > in cputime_adjust() `stime' is greater than `rtime', so `utime = rtime -
> > stime'
> > sets wrong value.
>
> But stime should always be below rtime due to the calculation done by
> scale_stime()
> which roughly sums up to:
>
> stime = (
On (09/02/13 15:07), Frederic Weisbecker wrote:
> > $ dmesg | grep Ooops
> > [ 1295.311056] Ooops: stime:4622750929 rtime:4622750928
> > [ 1301.384396] Ooops: stime:4654072951 rtime:4654072950
> > [ 1307.438935] Ooops: stime:4687858107 rtime:4687858106
> > [ 1313.493462] Ooops: stime:4724166945 rti
On (09/02/13 15:50), Stanislaw Gruszka wrote:
> Date: Mon, 2 Sep 2013 15:50:34 +0200
> From: Stanislaw Gruszka
> To: Frederic Weisbecker
> Cc: Sergey Senozhatsky , Ingo Molnar
> , Peter Zijlstra , "Paul E.
> McKenney" , Borislav Petkov ,
> linux-kernel@vger.k
On (09/02/13 16:13), Frederic Weisbecker wrote:
> > On Mon, Sep 02, 2013 at 03:07:45PM +0200, Frederic Weisbecker wrote:
> > > > Hope this may help.
> > > > I've added a silly check to make sure that `stime < rtime'
> > > >
> > > > @@ -579,6 +582,10 @@ static void cputime_adjust(struct task_cputim
On (09/03/13 10:43), Stanislaw Gruszka wrote:
> >
> > usually stime < rtime.
> > this is what scale_stime() gets as input:
> >
> > [ 1291.409566] stime:3790580815 rtime:4344293130 total:3790580815
>
> Ok, I see now, utime is 0 . This seems to be problem with dynamic ticks
> as you told that your
On (09/03/13 10:43), Stanislaw Gruszka wrote:
> > > > Thanks a lot Sergey for testing this further!
> > > >
> > > > Interesting results, so rtime is always one or two units off stime
> > > > after scaling.
> > > > Stanislaw made the scaling code with Linus and he has a better idea on
> > > > the
od job.
here are my:
Reported-by: Sergey Senozhatsky
Tested-by: Sergey Senozhatsky
-ss
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index a7959e0..25cc35d 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -557,7 +557,7 @@ stat
> > I read your threads roughly so I may miss something. If so, sorry
> > > for that. Anyway I will put my opinion.
> > >
> > > On Wed, Sep 11, 2013 at 02:12:50AM +0300, Sergey Senozhatsky wrote:
> > > > Dan Carpenter noted that handle_pending_slot_free(
ate.isra.2+0x1b5/0x1b5
[0.948724] [] kthread+0xd5/0xdd
[0.948814] [] kernel_thread_helper+0x4/0x10
[0.948900] [] ? retint_restore_args+0x13/0x13
[0.948985] [] ? __init_kthread_worker+0x5a/0x5a
[0.949069] [] ? gs_change+0x13/0x13
devcgroup_inode_mknod() part submitted by Paul E. McKen
On (10/10/12 14:06), Stephen Rothwell wrote:
> Hi Catalin,
>
> Today's linux-next merge of the kmemleak tree got a conflict in
> mm/kmemleak.c between commit 85d3a316c714 ("kmemleak: use rbtree instead
> of prio tree") from Linus' tree and commit 48786770bf3b ("kmemleak: do
> not leak object after
On (10/10/12 14:06), Stephen Rothwell wrote:
> Hi Catalin,
>
> Today's linux-next merge of the kmemleak tree got a conflict in
> mm/kmemleak.c between commit 85d3a316c714 ("kmemleak: use rbtree instead
> of prio tree") from Linus' tree and commit 48786770bf3b ("kmemleak: do
> not leak object after
; [0.948469] [] ? handle_create.isra.2+0x1b5/0x1b5
> > [0.948554] [] devtmpfsd+0xe4/0x138
> > [0.948638] [] ? handle_create.isra.2+0x1b5/0x1b5
> > [0.948724] [] kthread+0xd5/0xdd
> > [0.948814] [] kernel_thread_helper+0x4/0x10
> > [0.948900] [] ? retint_
0.948985] [] ? __init_kthread_worker+0x5a/0x5a
[0.949069] [] ? gs_change+0x13/0x13
devcgroup_inode_mknod() part submitted by Paul E. McKenney.
Signed-off-by: Sergey Senozhatsky
---
security/device_cgroup.c | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
.
zram_reset_device()/__zram_reset_device() pair.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/Makefile | 2 +-
drivers/staging/zram/zram_drv.c | 454 +++---
drivers/staging/zram/zram_drv.h | 12 -
drivers/staging/zram/zram_sysfs.c | 227
. zram_reset_device()/__zram_reset_device() pair.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/Makefile | 2 +-
drivers/staging/zram/zram_drv.c | 524 +-
drivers/staging/zram/zram_drv.h | 10 -
drivers/staging/zram/zram_sysfs.c | 209
We also can drop several zram_drv wrapper
> > functions, used from zram sysfs:
> > e.g. zram_reset_device()/__zram_reset_device() pair.
> >
> > Signed-off-by: Sergey Senozhatsky
> >
> > ---
> > drivers/staging/zram/
. zram_reset_device()/__zram_reset_device() pair.
v2: as suggested by Greg K-H, move MODULE description to the
bottom of the file.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/Makefile | 2 +-
drivers/staging/zram/zram_drv.c | 516 ++
drivers/staging/zram
[ 2164.633265] lost page write due to I/O error on zram0
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_drv.c
index 7538774..82c7202 100644
[ 60.277396] ==
[ 60.277400] [ INFO: possible circular locking dependency detected ]
[ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted
[ 60.277411] ---
[ 60.277417] ba
Commit 9b3bb7abcdf2df0f1b2657e6cbc9d06bc2b3b36f (remove
zram_sysfs file (v2)) accidentally made zram_reset_device()
racy. Protect zram_reset_device() call with zram->lock.
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 6 +-
1 file changed, 5 insertions(+)
On (06/28/13 10:13), Viresh Kumar wrote:
> On 26 June 2013 02:45, Sergey Senozhatsky
> wrote:
> >
> > [ 60.277396] ==
> > [ 60.277400] [ INFO: possible circular locking dependency detected ]
> > [ 60.277407]
On (06/28/13 15:01), Srivatsa S. Bhat wrote:
> On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
> > On (06/28/13 10:13), Viresh Kumar wrote:
> >> On 26 June 2013 02:45, Sergey Senozhatsky
> >> wrote
On (06/28/13 19:43), Srivatsa S. Bhat wrote:
> On 06/28/2013 01:14 PM, Sergey Senozhatsky wrote:
> > Hello,
> > Yes, this helps, of course, but at the same time it returns the previous
> > problem -- preventing cpu_hotplug in some places.
> >
> >
> > I h
Hello,
got this with today's linux-next
[3.163894] ===
[3.163895] [ INFO: suspicious RCU usage. ]
[3.163897] 3.9.0-rc3-next-20130322-dbg-dirty #1 Not tainted
[3.163898] ---
[3.163900] fs/eventpoll.c:545 suspicious rcu_der
On (03/23/13 17:34), Eric Wong wrote:
> Sergey Senozhatsky wrote:
> > [3.163894] ===
> > [3.163895] [ INFO: suspicious RCU usage. ]
> > [3.163897] 3.9.0-rc3-next-20130322-dbg-dirty #1 Not tain
s+0x120/0x330
[4.800909] [] kernel_init_freeable+0x111/0x191
[4.801052] [] ? do_early_param+0x88/0x88
[4.801233] [] ? rest_init+0x140/0x140
[4.801393] [] kernel_init+0xe/0x180
[4.801556] [] ret_from_fork+0x7c/0xb0
[4.801718] [] ? rest_init+0x140/0x140
Signed-off-by: Serge
--- a/drivers/cpufreq/cpufreq_governor.h
> +++ b/drivers/cpufreq/cpufreq_governor.h
> @@ -213,6 +213,7 @@ struct dbs_data {
> unsigned int min_sampling_rate;
> int usage_count;
> void *tuners;
> + int queue_stop;
>
> /* dbs_mutex pro
On (07/14/13 14:47), Sergey Senozhatsky wrote:
>
> Now, as I fixed radeon kms, I can see:
>
> [ 806.660530] [ cut here ]
> [ 806.660539] WARNING: CPU: 0 PID: 2389 at arch/x86/kernel/smp.c:124
> native_smp_send_reschedule+0x57/0x60()
Well, this one
;>> +redo:
> >>>> +round--;
> >>>> for_each_cpu(i, policy->cpus) {
> >>>> cdbs = dbs_data->cdata->get_cpu_cdbs(i);
> >>>> cancel_delayed_work_sync(&cdbs->work);
> >>>
> halt command and nobody had brought in suspend/resume to the equation.
>
> The reason for _that_ in turn, it turns out is that, earlier halt/shutdown
> was being done by disabling non-boot CPUs while tasks were frozen, just like
> suspend/resume but commit cf7df378a (r
On (07/16/13 14:03), Srivatsa S. Bhat wrote:
> >> So here is the solution:
> >>
> >> On 3.11-rc1, apply these patches in the order mentioned below, and check
> >> whether it fixes _all_ problems (both the warnings about IPI as well as the
> >> lockdep splat).
> >>
> >> 1. Patch given in: https://l
Hello,
extracted as a new thread from https://lkml.org/lkml/2013/7/16/344
cpufreq midifications are:
> Srivatsa S. Bhat wrote:
>
> 1. Patch given in: https://lkml.org/lkml/2013/7/11/661
>(Just apply patch 1, not the entire patchset).
>
> 2. Apply the patch shown below, on top of the above pat
= 384181.66 KB/sec
w/ patch (LZO)
Children see throughput for 8 mixed workload= 2957859.84 KB/sec
Parent sees throughput for 8 mixed workload = 1859763.07 KB/sec
Signed-off-by: Sergey Senozhatsky
---
drivers/staging/zram/zram_drv.c | 604 +++
1 - 100 of 3780 matches
Mail list logo
