On Wed, Jan 24, 2001 at 01:21:44PM +0100, Andrea Arcangeli wrote:
> For example you don't know if there's another object that will cast
> the int pointer back to char pointer before dereferencing. That would
> get a defined runtime behaviour on all archs.
No. The representation of "int*" and "ch
Andrea Arcangeli <[EMAIL PROTECTED]>:
> On Tue, Jan 23, 2001 at 11:51:15PM -0800, Richard Henderson wrote:
> > On Thu, Jan 11, 2001 at 12:59:24AM +0100, Andrea Arcangeli wrote:
> > > What I said is that I can write this C code:
> > >
> > > int x[2], * p = (int *) (((char *) &x)+1);
> > > main
On Wed, Jan 24, 2001 at 01:51:49AM -0800, Richard Henderson wrote:
> On Wed, Jan 24, 2001 at 10:02:40AM +0100, Andrea Arcangeli wrote:
> > I'd love if you could forbid it to compile.
>
> Problem is that there's stuff like this all over the place. Plus,
That's why I thought you were required to
In article <[EMAIL PROTECTED]> you write:
> I know this code has undefined behaviour at _runtime_. But I thought
> you were obliged to allow it to compile. That was my only point.
There is no distinction between compilation and runtime in the standard.
Actually, C could be interpreted, or a very
On Wed, Jan 24, 2001 at 10:02:40AM +0100, Andrea Arcangeli wrote:
> I'd love if you could forbid it to compile.
Problem is that there's stuff like this all over the place. Plus,
just because something is undefined by the standard doesn't mean
it's not useful -- it's not possible to write either
On Tue, Jan 23, 2001 at 11:51:15PM -0800, Richard Henderson wrote:
> On Thu, Jan 11, 2001 at 12:59:24AM +0100, Andrea Arcangeli wrote:
> > What I said is that I can write this C code:
> >
> > int x[2], * p = (int *) (((char *) &x)+1);
> > main()
> > {
> > *p = 0;
> > }
On Thu, Jan 11, 2001 at 12:59:24AM +0100, Andrea Arcangeli wrote:
> What I said is that I can write this C code:
>
> int x[2], * p = (int *) (((char *) &x)+1);
> main()
> {
> *p = 0;
> }
>
> This is legal C code.
Err, no. This is not "legal" by any stretch
Manfred writes:
> 2.2.18 struct nfs_fh is a new structure for nfsV3, it doesn't exist in 2.2.17.
> That structure is unusable on ARM.
Correct.
> Russel want's to change the new "struct nfs_fh" (from 2.2.18), and that
> change is included in 2.2.19pre7. But that change breaks i386 nfs mount.
Unf
Andi Kleen writes:
> The change is rather useless anyways, because even in NFSv3 file handles
> cannot be >64bytes. Would even fit in a char, doesn't need a short nor an
> int.
Indeed, but whether it be a char or a short, it'll still break on ARM. My
original set of 3 solutions still stand ther
Andrea Arcangeli writes:
> This patch looks fine w.r.t. alignment but given the below seems called
> at runtime (not just at mount time) for performance and to save a dozen of bytes
> of kernel stack it would probably better to use the nfs_fh structure in
> 2.2.19pre7 for the in-kernel representat
> " " == Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Thu, Jan 11, 2001 at 07:30:49PM +0100, Trond Myklebust
> wrote:
>> OK. In that case my patch, would just be amended to eliminate
>> the redundant comparison as is the case below.
> This patch looks fine w.r.t.
On Thu, Jan 11, 2001 at 07:30:49PM +0100, Trond Myklebust wrote:
> OK. In that case my patch, would just be amended to eliminate the
> redundant comparison as is the case below.
This patch looks fine w.r.t. alignment but given the below seems called
at runtime (not just at mount time) for perform
On Thu, Jan 11, 2001 at 07:22:03PM +0100, Trond Myklebust wrote:
> [..] Are there any
> alignment requirements on them?
On some arch int can be read only at a sizeof(int) byte aligned address
(details in my example in reply to Russell).
Andrea
-
To unsubscribe from this list: send the line "unsu
> " " == Trond Myklebust <[EMAIL PROTECTED]> writes:
> - if (file->f_handle.fh_dcookie == fh->fh_dcookie &&
> - !memcmp(&file->f_handle, fh, sizeof(*fh)))
> + if (file->f_handle.fh_dcookie == fh.fh_dcookie &&
> + !memcmp(&file->f_handle, &fh, sizeof(fh)))
>
Mark Hahn wrote:
>
> hi. I've received 8 copiies of this message (via linux-kernel) so far.
> headers indicate that the following hop is being repeated:
>
8. That's weird - according to my maillogs colorfullife.com (my own
server) only sent 6 copies to everyone.
The attached one is the 5. messa
> " " == Manfred Spraul <[EMAIL PROTECTED]> writes:
> Trond Myklebust wrote:
>>
>>
>> As for the issue of casting 'fh->data' as a 'struct knfsd' then
>> that is a perfectly valid operation.
>>
> No it isn't.
> fh-> data is an array of characters, thus witho
Trond Myklebust wrote:
>
>
> As for the issue of casting 'fh->data' as a 'struct knfsd' then that
> is a perfectly valid operation.
>
No it isn't.
fh->data is an array of characters, thus without any alignment
restrictions.
'struct knfsd' begins with a pointer, thus it must be 4 or 8 byte
align
> " " == Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> As far I can see the only reason size makes sense to be 32bit
> is to get some more strict behaviour in the below code (to
> avoid discarding the most significant 16bits in sanity checks
> like this):
> nlm4_dec
Zitiere Andi Kleen <[EMAIL PROTECTED]>:
> On Thu, Jan 11, 2001 at 07:10:27AM -0500, Manfred wrote:
> > Zitiere Russell King <[EMAIL PROTECTED]>:
> > > The API changed:
> > > struct nfs_mount_data {
> > > int version;/* 1 */
> > > int fd;
On Thu, Jan 11, 2001 at 07:10:27AM -0500, Manfred wrote:
> Zitiere Russell King <[EMAIL PROTECTED]>:
> > The API changed:
> > struct nfs_mount_data {
> > int version;/* 1 */
> > int fd; /* 1 */
> > - struct nfs_fh
Zitiere Russell King <[EMAIL PROTECTED]>:
> The API changed:
> struct nfs_mount_data {
> int version;/* 1 */
> int fd; /* 1 */
> - struct nfs_fh root; /* 1 */
> + struct nfs2_fh old_root;
> " " == Russell King <[EMAIL PROTECTED]> writes:
> Hubert Mantel writes:
>> is this part of 2.2.19pre7 really a good idea? Even in 2.4.0
>> the size field is still a short.
>> #define NFS_MAXFHSIZE 64
>> struct nfs_fh {
>> - unsigned short size;
>> + unsigned int
On Thu, Jan 11, 2001 at 07:34:01AM +, Russell King wrote:
> 1. Yucky code in the NFS layers to copy a nfs_fh from userspace to kernel
>space, translating it into something sane.
> 2. Yucky code in the NFS layers to manually handle the nfs_fh to knfs_fh
>translation.
> 3. Accept the bre
Andrea Arcangeli writes:
> However I'd _love_ to see the EIP where you get the fault, I currently don't
> see the line of code that is crashing your ARM and I know this code doesn't
> segfault on ARM.
Examine nlm_lookup_file() and the usage of fh->fh_dev and fh->fh_ino.
What happens is that in th
On Wed, Jan 10, 2001 at 10:09:22PM +, Russell King wrote:
> Andrea Arcangeli writes:
> > Furthmore
> > the cast of data to a struct should work on all architectures as far as C is
> > concerned (if you then run al
Andrea Arcangeli writes:
> (spotted by Andi) util-linux-2.10o/mount/nfs_mount4.h:
>
> struct nfs3_fh {
> unsigned short size;
> unsigned char data[64];
> };
>
> (see also nfs_mount_data structure in both kernel and mount)
Well, let me put it this way:
1. NFS
On Wed, Jan 10, 2001 at 06:54:45AM +, Russell King wrote:
> This is an internal kernel data structure. Do you know of some program
No, it isn't, that's the whole point.
> that breaks as a result of this?
(spotted by Andi) util-linux-2.10o/mount/nfs_mount4.h:
struct nfs3_fh {
unsig
Hubert Mantel writes:
> is this part of 2.2.19pre7 really a good idea? Even in 2.4.0 the size
> field is still a short.
> #define NFS_MAXFHSIZE64
> struct nfs_fh {
> - unsigned short size;
> + unsigned intsize;
> unsigned char data[NFS
> is this part of 2.2.19pre7 really a good idea? Even in 2.4.0 the size
> field is still a short.
It needs to change in 2.4 as well. The cast of data to a struct isnt portable
to all architectures.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
29 matches
Mail list logo
