workqueue: fix how cpu number is stored in work->data
in [Kernel]
|
Prev: Version 2: Provide /sys/../ec with read/write access and some cleanups
Next: x86: ioremap: fix wrong physical address handling in PAT code
From: Martin Schwidefsky on 22 Jul 2010 11:20 On Thu, 22 Jul 2010 14:25:28 +0200 Tejun Heo <tj(a)kernel.org> wrote: > Once a work starts execution, its data contains the cpu number it was > on instead of pointing to cwq. This is added by commit 7a22ad75 > (workqueue: carry cpu number in work data once execution starts) to > reliably determine the work was last on even if the workqueue itself > was destroyed inbetween. > > Whether data points to a cwq or contains a cpu number was > distinguished by comparing the value against PAGE_OFFSET. The > assumption was that a cpu number should be below PAGE_OFFSET while a > pointer to cwq should be above it. However, on architectures which > use separate address spaces for user and kernel spaces, this doesn't > hold as PAGE_OFFSET is zero. > > Fix it by using an explicit flag, WORK_STRUCT_CWQ, to mark what the > data field contains. If the flag is set, it's pointing to a cwq; > otherwise, it contains a cpu number. > > Reported on s390 and microblaze during linux-next testing. > > Signed-off-by: Tejun Heo <tj(a)kernel.org> > Reported-by: Sachin Sant <sachinp(a)in.ibm.com> > Reported-by: Michal Simek <michal.simek(a)petalogix.com> > Reported-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> > --- > Yeah, that was a stupid assumption by me. Can you guys please test > whether this fixes the problem? Compiles and boots for s390. Thanks. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Michal Simek on 22 Jul 2010 16:20 Tejun Heo wrote: > Once a work starts execution, its data contains the cpu number it was > on instead of pointing to cwq. This is added by commit 7a22ad75 > (workqueue: carry cpu number in work data once execution starts) to > reliably determine the work was last on even if the workqueue itself > was destroyed inbetween. > > Whether data points to a cwq or contains a cpu number was > distinguished by comparing the value against PAGE_OFFSET. The > assumption was that a cpu number should be below PAGE_OFFSET while a > pointer to cwq should be above it. However, on architectures which > use separate address spaces for user and kernel spaces, this doesn't > hold as PAGE_OFFSET is zero. > > Fix it by using an explicit flag, WORK_STRUCT_CWQ, to mark what the > data field contains. If the flag is set, it's pointing to a cwq; > otherwise, it contains a cpu number. > > Reported on s390 and microblaze during linux-next testing. > > Signed-off-by: Tejun Heo <tj(a)kernel.org> > Reported-by: Sachin Sant <sachinp(a)in.ibm.com> > Reported-by: Michal Simek <michal.simek(a)petalogix.com> > Reported-by: Martin Schwidefsky <schwidefsky(a)de.ibm.com> > --- > Yeah, that was a stupid assumption by me. Can you guys please test > whether this fixes the problem? > > Thanks. Microblaze is OK. Tested-by: Michal Simek <monstr(a)monstr.eu> Thanks, Michal -- Michal Simek, Ing. (M.Eng) PetaLogix - Linux Solutions for a Reconfigurable World w: www.petalogix.com p: +61-7-30090663,+42-0-721842854 f: +61-7-30090663 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Tejun Heo on 22 Jul 2010 16:50
On 07/22/2010 05:10 PM, Martin Schwidefsky wrote: > Compiles and boots for s390. Thanks. Added Tested-by's and applied to wq#for-next. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |