public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH v2 01/11] lib: Add support for guarded buffers
Date: Mon, 19 Aug 2019 14:42:00 +0200	[thread overview]
Message-ID: <20190819124159.GA11715@rei.lan> (raw)
In-Reply-To: <877e79wmme.fsf@rpws.prws.suse.cz>

Hi!
> We could add guarded buffers to huge numbers of tests by wrapping the
> user supplied buffer in various calls to SAFE_* macros and tst_*
> functions. This could be configurable at compile time and it should be
> detectable if a buffer is already guarded, so double wrapping should not
> be an issue.

Fair point. The detection would however be O(n), well we can do a little
trick like maintaing the memory range in which all the mmaps were done
and rule out any heap based allocation in O(1) easily, but anything that
crosses the malloc threshold would be O(n).

> However I am not sure the current API makes this easy. We should
> probably have a tst_free(void *buf) and/or tst_buffer_alloc(struct
> tst_buffer *buf) and tst_buffer_free(struct tst_buffer *buf) (which
> could just put the buffer on a free list for reuse).

I guess that this calls for completely different API since 99% time we
will do with just single buffer.

Unless we are:

* The test is compiled with pthreads
  and we managed to run two SAFE_MACROS() concurently

* The buffer is bigger than one page

* We call SAFE_MACROS() recursively, which we don't

So all of this could be done by a tst_temp_alloc() and tst_temp_free()
that would attempt to grab single pre-allocated buffer and only fall
back to allocating/freeing new buffer when the buffer is currently in
use.

> I am not sure if this is something which needs to be addressed now or
> can be left for another patch set. My main concern is that one of the
> existing API functions will need to be changed.

I guess that it would be easier to make these changes incrementally,
because adding more functionality to this patchset would only make it
harder to review and I would like to get this API in so that we can
star making use of it.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2019-08-19 12:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-12 14:39 [LTP] [PATCH v2 00/11] Introduce guarded buffers Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 01/11] lib: Add support for " Cyril Hrubis
2019-08-19  9:06   ` Richard Palethorpe
2019-08-19 12:42     ` Cyril Hrubis [this message]
2019-08-20  8:25       ` Richard Palethorpe
2019-08-21  9:11         ` Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 02/11] lib: Add a canary " Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 03/11] doc: Add guarded buffers documentation Cyril Hrubis
2019-08-19  9:44   ` Richard Palethorpe
2019-08-12 14:39 ` [LTP] [PATCH v2 04/11] syscalls/accept02: Make use of guarded buffers Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 05/11] syscalls/preadv01: " Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 06/11] syscalls/accept4_01: " Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 07/11] syscalls/add_key04: " Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 08/11] syscalls/adjtimex: " Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 09/11] syscalls/clock_getres01: " Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 10/11] syscalls/clock_settime01: " Cyril Hrubis
2019-08-12 14:39 ` [LTP] [PATCH v2 11/11] syscalls/sendmmsg01: " Cyril Hrubis
2019-08-13  9:53 ` [LTP] [PATCH v2 00/11] Introduce " Li Wang
2019-08-13 10:29   ` Cyril Hrubis
2019-08-20 11:23   ` Cyril Hrubis
2019-08-20 11:55     ` Li Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190819124159.GA11715@rei.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox