1. 09 Jul, 2019 1 commit
    • Kirill Smelkov's avatar
      bigfile: Unstub ram_close · d91ef8fb
      Kirill Smelkov authored
      It should release resources associated with RAM. Make it call .ram_close
      from RAM ops. Add corresponding .ram_close to ram_shmfs. This fixes
      SHMFS_RAM->prefix leak.
      d91ef8fb
  2. 24 Oct, 2017 1 commit
    • Kirill Smelkov's avatar
      Relicense to GPLv3+ with wide exception for all Free Software / Open Source... · f11386a4
      Kirill Smelkov authored
      Relicense to GPLv3+ with wide exception for all Free Software / Open Source projects + Business options.
      
      Nexedi stack is licensed under Free Software licenses with various exceptions
      that cover three business cases:
      
      - Free Software
      - Proprietary Software
      - Rebranding
      
      As long as one intends to develop Free Software based on Nexedi stack, no
      license cost is involved. Developing proprietary software based on Nexedi stack
      may require a proprietary exception license. Rebranding Nexedi stack is
      prohibited unless rebranding license is acquired.
      
      Through this licensing approach, Nexedi expects to encourage Free Software
      development without restrictions and at the same time create a framework for
      proprietary software to contribute to the long term sustainability of the
      Nexedi stack.
      
      Please see https://www.nexedi.com/licensing for details, rationale and options.
      f11386a4
  3. 15 Dec, 2015 1 commit
    • Kirill Smelkov's avatar
      bigfile: Plug memory leak in ramh_close() · 997ebacd
      Kirill Smelkov authored
      No one was freeing RAMH structure itself, and thus ASAN reports e.g.:
      
      ==15935==ERROR: LeakSanitizer: detected memory leaks
      
      Direct leak of 32 byte(s) in 1 object(s) allocated from:
          #0 0x7f29c89f1001 in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x94001)
          #1 0x401da1 in zalloc include/wendelin/utils.h:65
          #2 0x408128 in shmfs_ramh_open bigfile/tests/../ram_shmfs.c:202
          #3 0x407611 in ramh_open bigfile/tests/../ram.c:81
          #4 0x402560 in fileh_open bigfile/tests/../virtmem.c:131
          #5 0x427ca1 in test_pagefault_savestate bigfile/tests/test_virtmem.c:1022
          #6 0x4281ba in main bigfile/tests/test_virtmem.c:1061
          #7 0x7f29c83b8b44 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b44)
      
      NOTE similar leak remains open in ram_close(), but it is a bit involved
      to fix and the effort will be removed anyway after we switch to kernel
      virtual memory manager. Besides ramh are opened and closed all the time
      and ram only once.
      997ebacd
  4. 05 Nov, 2015 1 commit
    • Kirill Smelkov's avatar
      bigfile/ram_shmfs: Warn users explicitly if fallocate() is not supported · e8c05a22
      Kirill Smelkov authored
      Currently wendelin.core does not work on e.g. Debian 7, because that
      distro has too old kernel without support for fallocate on tmpfs.
      But the diagnostics of failure is not clear and looks like just being
      out of memory:
      
          bigfile/tests/../virtmem.c:845 OOM      BUG!
      
      what happens in fact is that
      
          - virtmem tries to allocate a page -> calls shmfs_alloc_page(),
          - fallocate() fails with "operation not supported" error code
          - virtmem sees this as page allocation failure,
          - tries to reclaim pages,
          - but there are no allocated pages at all -> OOM
      
      Detect whether fallocate() error is operational error, or simply
      "fallocate not supported" and if latter, report to user. Now it looks
      like:
      
          bigfile/tests/../ram_shmfs.c:129 shmfs_alloc_page WARN: fallocate() not supported
          bigfile/tests/../virtmem.c:845 OOM      BUG!
      
      /cc @Tyagov
      e8c05a22
  5. 29 Apr, 2015 1 commit
    • Kirill Smelkov's avatar
      bigfile/ram_shmfs: Try to support compiling on older systems · 48defba0
      Kirill Smelkov authored
      For example on Debian 7 Wheezy the kernel (linux 3.2) supports holepunching,
      because holepunching was added in linux 2.6.38:
      
          http://git.kernel.org/linus/79124f18b335172e1916075c633745e12dae1dac
      
      but glibc does not provide fallocate mode constants, and compilation fails:
      
          gcc -pthread -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -D_GNU_SOURCE -I./include -I./3rdparty/ccan -I./3rdparty/include -I/opt/slapgrid/f2a5f59d0d2b521681b9333ee76a2859/parts/python2.7/include/python2.7 -c bigfile/ram_shmfs.c -o build/temp.linux-x86_64-2.7/bigfile/ram_shmfs.o -std=gnu99 -fplan9-extensions -fvisibility=hidden -Wno-declaration-after-statement -Wno-error=declaration-after-statement
          bigfile/ram_shmfs.c: In function ‘shmfs_drop_memory’:
          bigfile/ram_shmfs.c:135:31: error: ‘FALLOC_FL_PUNCH_HOLE’ undeclared (first use in this function)
          bigfile/ram_shmfs.c:135:31: note: each undeclared identifier is reported only once for each function it appears in
          bigfile/ram_shmfs.c:135:54: error: ‘FALLOC_FL_KEEP_SIZE’ undeclared (first use in this function)
          error: command 'gcc' failed with exit status 1
      
      Try to fix it via fallbacking to provide the needed defines on older systems ourselves.
      
      Cc: Klaus Wölfel <klaus@nexedi.com>
      Cc: Ivan Tyagov <ivan@tyagov.com>
      48defba0
  6. 03 Apr, 2015 1 commit
    • Kirill Smelkov's avatar
      bigfile: RAM subsystem · 8c935a5f
      Kirill Smelkov authored
      This thing allows to get aliasable RAM from OS kernel and to manage it.
      Currently we get memory from a tmpfs mount, and hugetlbfs should also
      work, but is TODO because hugetlbfs in the kernel needs to be improved.
      
      We need aliasing because we'll need to be able to memory map the same
      page into several places in address space, e.g. for taking two slices
      overlapping slice of the same array at different times.
      
      Comes with test programs that show we aliasing does not work for
      anonymous memory.
      8c935a5f