• Mike Marshall's avatar
    orangefs: get rid of knob code... · ec95f1de
    Mike Marshall authored
    Christoph Hellwig sent in a reversion of "orangefs: remember count
    when reading." because:
    
      ->read_iter calls can race with each other and one or
      more ->flush calls. Remove the the scheme to store the read
      count in the file private data as is is completely racy and
      can cause use after free or double free conditions
    
    Christoph's reversion caused Orangefs not to work or to compile. I
    added a patch that fixed that, but intel's kbuild test robot pointed
    out that sending Christoph's patch followed by my patch upstream, it
    would break bisection because of the failure to compile. So I have
    combined the reversion plus my patch... here's the commit message
    that was in my patch:
    
      Logically, optimal Orangefs "pages" are 4 megabytes. Reading
      large Orangefs files 4096 bytes at a time is like trying to
      kick a dead whale down the beach. Before Christoph's "Revert
      orangefs: remember count when reading." I tried to give users
      a knob whereby they could, for example, use "count" in
      read(2) or bs with dd(1) to get whatever they considered an
      appropriate amount of bytes at a time from Orangefs and fill
      as many page cache pages as they could at once.
    
      Without the racy code that Christoph reverted Orangefs won't
      even compile, much less work. So this replaces the logic that
      used the private file data that Christoph reverted with
      a static number of bytes to read from Orangefs.
    
      I ran tests like the following to determine what a
      reasonable static number of bytes might be:
    
      dd if=/pvfsmnt/asdf of=/dev/null count=128 bs=4194304
      dd if=/pvfsmnt/asdf of=/dev/null count=256 bs=2097152
      dd if=/pvfsmnt/asdf of=/dev/null count=512 bs=1048576
                                .
                                .
                                .
      dd if=/pvfsmnt/asdf of=/dev/null count=4194304 bs=128
    
      Reads seem faster using the static number, so my "knob code"
      wasn't just racy, it wasn't even a good idea...
    Signed-off-by: default avatarMike Marshall <hubcap@omnibond.com>
    Reported-by: default avatarkbuild test robot <lkp@intel.com>
    ec95f1de
inode.c 28.4 KB