[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [LTP] 2.4.test11 and LTP




ulimit() as a library call is depricated as Nate said.  We should
consider removing it.

The open01 failure appears to be a functionality change between 2.2 and
2.4.  On my workstation, 2.2.16, it passes.  On one of our test systems,
2.4.0, it fails.

When I first looked at this, I thought it might be an "acceptable"
change in functionality.  Now I'm not so sure because the original
reason I thought it might be acceptable was because the failure report
indicated a "No such file or directory."  I've seen errnos change on
Linux for whatever reason, so I thought ENOENT for ELOOP might be okay. 
Regardless, the failure message is misleading because the open() call
does not fail.  It succeeds.  The test case in question creates a
symbolic link in a directory that points to itself, and then tries to
open it.  Our failure comes from the open() succeeding.  It should fail
with an ELOOP as it does in 2.2.

Here is what a trace looks like:

symlink("symbolic", "symbolic")         = 0
lstat("symbolic", {st_mode=S_IFLNK|0777, st_size=8, ...}) = 0
open("symbolic", O_RDONLY|O_CREAT, 01001177600) = 3

I put a pause in the code to look at what /proc/<pid>/fd looked like:

$ ls -l /proc/4804/fd/
total 0
lrwx------    1 alaffin  uftest         64 Jan 22 18:16 0 -> /dev/pts/1
lrwx------    1 alaffin  uftest         64 Jan 22 18:16 1 -> /dev/pts/1
lrwx------    1 alaffin  uftest         64 Jan 22 18:16 2 -> /dev/pts/1
lr-x------    1 alaffin  uftest         64 Jan 22 18:16 3 ->
/tmp/opeFc67Bq/

$ ls -l /tmp/opeFc67Bq/
total 0
lrwxrwxrwx    1 alaffin  uftest          8 Jan 22 18:13 symbolic ->
symbolic

So, the proc filesystem indicates that it successfully opened the
directory rather than failing to open the looping symlink.

Even better, when no O_CREAT is not used, ELOOP is returned:

symlink("symbolic", "symbolic")         = 0
lstat("symbolic", {st_mode=S_IFLNK|0777, st_size=8, ...}) = 0
open("symbolic", O_RDONLY)              = -1 ELOOP (Too many levels of
symbolic links)

I don't know why the writer of this test choose to throw an O_CREAT in
the open().  It appears that this is the key.  I've written a simple
program to illustrate the issue, here's a run:

$ ./eloop
open(O_RDONLY) of looping symlink readonly failed: 40: Too many levels
of symbolic links
open(O_WRONLY) of looping symlink readonly failed: 40: Too many levels
of symbolic links
open(O_RDWR) of looping symlink readonly failed: 40: Too many levels of
symbolic links
hmm, open(O_RDONLY|O_CREAT) should have failed
open(O_WRONLY|O_CREAT) of looping symlink readonly failed: 21: Is a
directory
open(O_RDWR|O_CREAT) of looping symlink readonly failed: 21: Is a
directory

O_CREAT in combination with a symlink seems to cause havoc.  My test
program is attached.

--aaron

Robert Williamson wrote:
> 
> We've seen the same errors with the 2.4 and 2.4.1 kernel.  Does anyone know
> if  these are just a result from changes in functionality or actual
> failures?
> 

-- 
Aaron Laffin
Silicon Graphics, Inc. OS Test Development
Email: alaffin@sgi.com Voice: 651-683-5756
USA/MN/EA/F6625/SSBU
#include <unistd.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <string.h>
#include <errno.h>

void call_open(int mode, char *strmode)
{
  int fd;

  fd = open("testlink",mode);
  
  if (fd<0)
  {
    printf("open(%s) of looping symlink readonly failed: %d: %s\n",strmode,errno,strerror(errno));
  }
  else
  {
    printf("hmm, open(%s) should have failed\n",strmode);
    close(fd);
  }
}

int main()
{
  int fd;

  symlink("testlink","testlink");

  call_open(O_RDONLY,"O_RDONLY");
  call_open(O_WRONLY,"O_WRONLY");
  call_open(O_RDWR,"O_RDWR");
  call_open(O_RDONLY|O_CREAT,"O_RDONLY|O_CREAT");
  call_open(O_WRONLY|O_CREAT,"O_WRONLY|O_CREAT");
  call_open(O_RDWR|O_CREAT,"O_RDWR|O_CREAT");

  unlink("testlink");
}