Implement a generic is_compat_task function. It should only be used
when absolutely necessary. For example, to clean up the per-architecture
tests in drivers/input/evdev.c.
Prototype is such that the existing asm-x86_64 helper needs no change.
Architecture maintainers must add an appropriate implementation to
asm/compat.h, if needed.
Signed-off-by: Kyle McMartin <[email protected]>
---
Yeah, this can be abused... but, blocks like:
#ifdef CONFIG_X86_64
# define COMPAT_TEST is_compat_task()
#elif defined(CONFIG_IA64)
# define COMPAT_TEST IS_IA32_PROCESS(task_pt_regs(current))
#elif defined(CONFIG_S390)
# define COMPAT_TEST test_thread_flag(TIF_31BIT)
#elif defined(CONFIG_MIPS)
# define COMPAT_TEST (current->thread.mflags & MF_32BIT_ADDR)
#else
# define COMPAT_TEST test_thread_flag(TIF_32BIT)
#endif
from drivers/input/evdev.c are worse. This style of block also appeared
in a patch on netdev recently...
I think everyone can agree centralizing this is probably better than
the current state of affairs.
diff --git a/include/asm-parisc/compat.h b/include/asm-parisc/compat.h
index 38b918f..a5eb7cd 100644
--- a/include/asm-parisc/compat.h
+++ b/include/asm-parisc/compat.h
@@ -5,6 +5,7 @@
*/
#include <linux/types.h>
#include <linux/sched.h>
+#include <linux/personality.h>
#define COMPAT_USER_HZ 100
@@ -144,4 +145,14 @@ static __inline__ void __user *compat_al
return (void __user *)regs->gr[30];
}
+static inline int __is_compat_task(struct task_struct *t)
+{
+ return (personality(t->personality) == PER_LINUX32);
+}
+
+static inline int is_compat_task(void)
+{
+ return __is_compat_task(current);
+}
+
#endif /* _ASM_PARISC_COMPAT_H */
diff --git a/include/linux/compat.h b/include/linux/compat.h
index c9ab2a2..d2e0ea9 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -181,5 +181,12 @@ static inline int compat_timespec_compar
return lhs->tv_nsec - rhs->tv_nsec;
}
+#else /* !CONFIG_COMPAT */
+
+static inline int is_compat_task(void)
+{
+ return 0;
+}
+
#endif /* CONFIG_COMPAT */
#endif /* _LINUX_COMPAT_H */
Kyle McMartin <[email protected]> wrote:
>
> Implement a generic is_compat_task function. It should only be used
> when absolutely necessary. For example, to clean up the per-architecture
> tests in drivers/input/evdev.c.
>
> Prototype is such that the existing asm-x86_64 helper needs no change.
>
> Architecture maintainers must add an appropriate implementation to
> asm/compat.h, if needed.
>
> ...
>
> +static inline int __is_compat_task(struct task_struct *t)
> +{
> + return (personality(t->personality) == PER_LINUX32);
> +}
> +
What continues to bug me about this (in a high-level hand-wavy sort of way)
is that this is an attribute of the mm_struct, not of the task_struct.
Andrew Morton writes:
> What continues to bug me about this (in a high-level hand-wavy sort of way)
> is that this is an attribute of the mm_struct, not of the task_struct.
It's not only an attribute of the mm_struct; compat-ness doesn't just
imply a restricted address space, it implies a different setting of
the processor when the task is running, a different set of system
calls, different interpretation of syscall arguments, etc.
Paul.
On Thu, 16 Feb 2006 21:49:39 -0800 Andrew Morton <[email protected]> wrote:
>
> What continues to bug me about this (in a high-level hand-wavy sort of way)
> is that this is an attribute of the mm_struct, not of the task_struct.
Aren't there really two things here:
in the syscall path you want to know that the kernel
was entered through a 32 bit (compat) syscall entry point so
you know what its arguments are and how to set up its return
values
in some places you need to know if the mm is a 32 bit mm
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
From: Andrew Morton <[email protected]>
Date: Thu, 16 Feb 2006 21:49:39 -0800
> Kyle McMartin <[email protected]> wrote:
> >
> > +static inline int __is_compat_task(struct task_struct *t)
> > +{
> > + return (personality(t->personality) == PER_LINUX32);
> > +}
> > +
>
> What continues to bug me about this (in a high-level hand-wavy sort of way)
> is that this is an attribute of the mm_struct, not of the task_struct.
It's an attribute of the "system call being invoked right now".
So you can emulate ia32 apps on ia64 or x86_64 by just trapping
to the 32-bit system calls directly, and stuff like that.
Hi All,
We have a Boot from SCSI setup and we are facing some problem. Problem
description is given below
System configuration: -
OS: AS4 UPDATE 1 [2.6.9-11.ELsmp]
Memory: 1 GB
QLA2310 Driver Info: Driver version 8.00.00b21-k, Firmware version 3.03.02
IPX
Setup: Boot From SCSI
Scenario 1:
Devices: 1024 SCSI devices
Utility gives the problem: /sbin/hotplug
Observation: udev process hangs and after some time kernel panic occurs.
Scenario 2:
Devices: 512
Utility:/sbin/hotplug
Observation: Boot from San success.
Scenario 3:
Devices: 1024
Utility: /sbin/udevsend
Observation: Boot from San success
Can any one answer the following queries: -
1. Are 512, the maximum number of devices that can be supported in Boot
from San in AS4 with hotplug agent?
2. If not what is the hardware requirement for more devices to be
supported or how it can be rectified?
3. Can we use utility /sbin/udevsend instead of /sbin/hotplug. Will it
impact any other process or devices?
4. Is /sbin/udevsend and /sbin/hotplug similar in functionality.
Thanks & Regards,
Srikanth Venkataraman.
http://www.patni.com
World-Wide Partnerships. World-Class Solutions.
_____________________________________________________________________
This e-mail message may contain proprietary, confidential or legally
privileged information for the sole use of the person or entity to
whom this message was originally addressed. Any review, e-transmission
dissemination or other use of or taking of any action in reliance upon
this information by persons or entities other than the intended
recipient is prohibited. If you have received this e-mail in error
kindly delete this e-mail from your records. If it appears that this
mail has been forwarded to you without proper authority, please notify
us immediately at [email protected] and delete this mail.
_____________________________________________________________________
On Thu, Feb 16, 2006 at 09:49:39PM -0800, Andrew Morton wrote:
> > +static inline int __is_compat_task(struct task_struct *t)
> > +{
> > + return (personality(t->personality) == PER_LINUX32);
> > +}
> > +
>
> What continues to bug me about this (in a high-level hand-wavy sort of way)
> is that this is an attribute of the mm_struct, not of the task_struct.
>
I'm not sure I agree, I can't find any real defined use for PER_LINUX32,
as opposed to PER_LINUX_32BIT, which is | ADDR_LIMIT_32BIT. That said,
I'm not opposed to moving parisc to use TIF_32BIT, in fact, I had this
in mind when I give the entrypoints a crapectomy.
Cheers,
Kyle