Re: readdir loses renamed files

From: Matthias Andree (matthias.andree_at_gmx.de)
Date: 10/28/04

  • Next message: Pavel Machek: "Re: Fixing MTRR smp breakage and suspending sysdevs." 
    Date:	Thu, 28 Oct 2004 11:34:26 +0200
To: Theodore Ts'o <tytso@mit.edu>, Timo Sirainen <tss@iki.fi>, linux-kernel@vger.kernel.org

    On Mon, 25 Oct 2004, Theodore Ts'o wrote:

    > And that's because there's no good way to do this without trashing the
    > performance of the system, especially when most applications don't
    > care. (Do you really want your entire system running significantly
    > slower, penalizing all other applications on your system, just because
    > of one stupid/badly-written application?)

    Please - is it really necessary that application writers are offended in
    this way? Timo is investing enormous time and effort in writing a *good*
    application, and he's effectively seeking a way to *robustly* deal with
    Maildir format mail storage. Please leave it at "readdir/getdents don't
    work the way you expect and cannot for this and that reason."

    Timo tries to implement a *robust* Maildir reader and has just bumped
    into the flaws of DJB's "no-locking" store.

    Yes, it's a mail server again that poses file system questions on this
    list; only it's IMAP this time rather than SMTP and directory
    synchronous I/O...

    > In order to do this, the
    > kernel would have to atomically snapshot the directory --- even one
    > which might be several megabytes in length, and store a copy of it in
    > memory, while the application calls readdir(). Several processes
    > could perform a denial-of-service attack by starting to call
    > readdir(), and then stopping. This would end up locking up huge
    > amounts of non-pageable system memory, and cause the system to come
    > down in a hurry.

    I'd like to question that.

    Just some rough thoughts:

    1. the number of open file handles (including directories seen as files
       for a moment at least) is limited per process, and I'd think the
       number of directories open can be lower

    2. versioned information might provide what the application wants
       without locking up the system

    3. the application could be offered an interface for atomic directory
       reads that requires the application to provide sufficient memory in a
       single contiguous buffer (making it thread-safe in the same go). 

    -- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
  • Next message: Pavel Machek: "Re: Fixing MTRR smp breakage and suspending sysdevs."

    Relevant Pages

    • Re: large files unnecessary trashing filesystem cache?
      ... > list about very large files trashing the filesystems memory cache leading to ... > My guess was, it has something to do with mm/readahead.c, a test limiting the ... Is there a reason why those applications couldn't use O_DIRECT? ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • large files unnecessary trashing filesystem cache?
      ... list about very large files trashing the filesystems memory cache leading to ... Of course one could always implement f_advise-calls in all applications, ... My guess was, it has something to do with mm/readahead.c, a test limiting the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Zeroed pages returned for heap
      ... >>also an application) to assume that the pages returned by the OS for heap ... > memory would seem to be making very dangerous assumptions. ... > pieces of memory to applications without erasing the old contents of the ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Testing optimize-for-size suitability?
      ... >> Is there a benchmark or set of benchmarks that would allow me to test ... I haven't noticed any other improvement, but I guess that more memory ... I will also try to compile other applications, ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: xmalloc string functions
      ... require memory allocations depending on the way the system works. ... If the toolkit being used is not one of those, then it is irrelevant that some provide a means to do so, particularly if the "some" are not available for the platform being targeted. ... Not enough context for most real-world applications to recover at this point. ... At this point g_malloccalling abortbecomes a moot point, particularly if your auto-save code is robust against memory allocation errors. ...
      (comp.lang.c)