[OpenAFS-devel] Solaris 10 - 1.4.3rc3 kernel modules build issues

[Douglas E. Engert]

Jeffrey Hutzelman wrote:
> 
> 
> On Friday, March 09, 2007 03:51:32 PM -0600 "Douglas E. Engert" 
> <deengert@anl.gov> wrote:
> 
>>
>>
>> Derrick J Brashear wrote:
>>> On Fri, 9 Mar 2007, Douglas E. Engert wrote:
>>>
>>>> It was not clear if this was a name made up by AFS, or a
>>>> name that is defined on some OS. If its an AFS made up name than
>>>> I agree.
>>>
>>> The idea was to use the OS' definition, if they defined it. However, the
>>> question then is whether OFFSET_MAX(fd) is portable, or whether this is
>>> just inherently a non-portable macro and we have to do something ugly.
>>>
>>
>> If I understand the comments in the code in that area, you are trying
>> to detect if the af->l_len is the max value for an offset,  or if Java
>> may have passed in a 32 bit 0x7ffffffe, as this is what Java thinks is
>> the max. And why would java use the -1?
> 
> The comment is mostly useless.  Please see the earlier mailing list 
> thread in which the author of that patch points out that his original 
> reference to 0x7ffffffe is in error, and the correct value is in fact 
> 0x7ffffffffffffffe.  The comments about -1 and 32 bits are merely an 
> attempt at explaining why some java implementations erroneously request 
> whole-file locks using that offset, but the explanation is irrelevant - 
> the important thing is that the bug exists, and this works around it.
> 
>> If so, the use of 0x7fffffff in line 547 for non UNIX machines
>> is not right as it assumes a 32 bit offset. It really needs to look
>> at the max for an offset. The code after the comment about Java and 32
>> bit offset -1 does not make sense when using a OFFSET_MAX which is 64
>> bits.
> 
> Only the code after the comment is new.  The code before it is correct - 

I don't believe it is. It may be on Linux,

Here is the Solars 10  cc -E output of MODLOAD64/afs_vnop_flock*

  27252  # 539
  27253
  27254  # 547
  27255      if (af->l_len == 0x7fffffff)
  27256      af->l_len = 0;
  27257  # 554
  27258
  27259  # 559
  27260      if (af->l_len ==  OFFSET_MAX -1)
  27261  # 561
  27262      af->l_len = 0;
  27263


> on AFS_LINUX24_ENV, we use OFFSET_MAX; on other platforms we use 
> 0x7fffffff always, and, on 64-bit-kernel platforms, _also_ LONG_MAX 
> (0x7fffffffffffffff). 

lines:
    549  #ifdef AFS_LINUX_64BIT_KERNEL
    550      if (af->l_len == LONG_MAX)
    551      af->l_len = 0;      /* since some systems indicate it as EOF */
    552  #endif

Are not processed, as Solaris is not a "LINUX" system.
But LONG_MAX is defined in ./sys/types.h as

#if defined(_LP64)
#define LONG_MAX        9223372036854775807L
...
#else /* _ILP32 */
#define LONG_MAX        2147483647L
...



> This has nothing whatsoever to do with the Java 
> issue; it is simply detecting cases where user-land or the OS depicts a 
> whole-file lock using the maximum possible offset instead of 0.  It's 
> also not new.
> 
> -- Jeff
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444