On Tue, May 27, 2014 at 01:07:20PM +0800, Li Zefan wrote:
> On 2014/5/27 12:50, Yong Zhang wrote:
> > BTW, I realy don't care who credits the patch and Ralf said that
> > he will applied the one which moves the place of udelay_val.
> >
> > Anyway, if your co
>
> Li Bin never reported this bug, but he fixed it. It's a shame that
> you took the credit from us.
>
> On 2014/5/21 13:36, Yong Zhang wrote:
> > asid_cache must be unsigned long otherwise on 64bit system
> > it will become 0 if the value in get_new_mmu_con
the credit from us.
I just saw a bug report and ananysis. And I agreed and confirmed it's
a bug.
Thanks,
Yong
>
> On 2014/5/21 13:36, Yong Zhang wrote:
> > asid_cache must be unsigned long otherwise on 64bit system
> > it will become 0 if the value in get_new_
asid_cache must be unsigned long otherwise on 64bit system
it will become 0 if the value in get_new_mmu_context()
reaches 0x and in the end the assumption of
ASID_FIRST_VERSION is not true anymore thus leads to
more dangerous things.
Reported-by: libin
Signed-off-by: Yong Zhang
---
V2
From: Yong Zhang
The code fails to update tg->rt_bandwidth.[rt_period | rt_runtime]
if we have RT_GROUP_SCHED enabled. And if we lower the value of
sched_rt_runtime_us, we get error as "write error: Invalid argument".
Fix it by calling tg_set_rt_bandwidth() instead when setting
sch
If we happen to pull a running task on other cpu, a WARNING
will happen. But the very task will be pulled to this cpu
finally. This pulling is dangerous since the task's private
data could be broken. Fix it by skipping this kind of task.
Signed-off-by: Yong Zhang
Cc: Ingo Molnar
Cc:
On Fri, Apr 05, 2013 at 06:36:40PM +0200, Peter Zijlstra wrote:
> Thomas spotted a nasty 32bit race in sched_clock_remote() after way too
> many hours of debugging weirdness.
>
> What happens is that sched_clock_remote() does regular machine word
> reads of sched_clock_data::clock; this appears sa
On Fri, Mar 01, 2013 at 11:17:42AM +0100, Thomas Gleixner wrote:
> On Fri, 1 Mar 2013, Yong Zhang wrote:
>
> > From: Yong Zhang
> >
> > Otherwise, below warning is shown somtimes when running some test:
> >
> > WARNING: at kernel/sched/core.c:3423 migrate_d
From: Yong Zhang
Otherwise, below warning is shown somtimes when running some test:
WARNING: at kernel/sched/core.c:3423 migrate_disable+0xbf/0xd0()
Hardware name: OptiPlex 755
Modules linked in: floppy parport parport_pc minix
Pid: 1800, comm: tst-robustpi8 Tainted: GW3.4.28-rt40
On Fri, Mar 1, 2013 at 9:36 AM, Yong Zhang wrote:
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -562,16 +562,17 @@ void exit_pi_state_list(struct task_struct *curr)
>
> spin_lock(&hb->lock);
>
> - raw_
From: Yong Zhang
Otherwise, below warning is shown somtimes when running some test:
WARNING: at kernel/sched/core.c:3423 migrate_disable+0xbf/0xd0()
Hardware name: OptiPlex 755
Modules linked in: floppy parport parport_pc minix
Pid: 1800, comm: tst-robustpi8 Tainted: GW3.4.28-rt40
Commit-ID: 9fb1b90ce0a847a8cc9492a6c1f347b5be1f33ff
Gitweb: http://git.kernel.org/tip/9fb1b90ce0a847a8cc9492a6c1f347b5be1f33ff
Author: Yong Zhang
AuthorDate: Mon, 16 Apr 2012 15:01:55 +0800
Committer: Ingo Molnar
CommitDate: Tue, 19 Feb 2013 08:43:35 +0100
lockdep: Selftest: convert
From: Yong Zhang
Current access_ok() will fail even if the address range is
valid when it reaches to the end of TASK_SIZE.
For exampe: addr = 0xf0; size = 16;
the real address range it want to access is 0xf0~0xf;
but addr + size = 0x100 which we will not and can&#
13 matches
Mail list logo
