Hi!
> > Strictly speaking this is not a bug at least when sticking to regular
> > files as POSIX which says that the change is not written out. In this
> > case the file content is correct and forcing the data to be written out
> > by msync() makes the test pass. The SHM mappings seems to preserve
Hi!
I'm currently revisiting mmap related tests in LTP (Linux Test Project)
and I've came to the tests testing that writes to the partially
mapped page (at the end of mapping) are carried out correctly.
These tests fails because even after the object is unmapped and the
file-descriptor closed the
Hi!
> I've seen the LTP open posix mmap/{11-4,11-5} issues in the past myself
> and was something I wanted to discuss on the lists myself. Thanks for
> bringing this up.
>
> Jut to reiterate: the expectations are
>
> 1. zero filling of unmapped (trailing) partial page
> 2. NO Writeout (to disk) o
Hi!
> > +static unsigned long count_vma_pages_range(struct mm_struct *mm,
> > + unsigned long addr, unsigned long end)
> > +{
> > + unsigned long nr_pages = 0;
> > + struct vm_area_struct *vma;
> > +
> > + /* Find first overlaping mapping */
> > + vma = find_vma_intersection(mm, a
Hi!
> > and there's no good
> > reason to believe that this behavior would have persisted
> > indefinitely.
> >
> > The msync(2) man page (as currently written in man-pages.git) is
> > silent on the behavior if both flags are unset, so this change should
> > not break an application written by som
Good news everyone,
The Linux Test Project test suite stable release for *April 2014* has
been released.
Since the last release 210 patches by 27 authors were merged.
Notable changes are:
* Continued effort to cleanup old testcases
(about 30 testcases were cleaned up/rewritten)
* 20 new sysc
Hi!
>
> However, unless I'm sorely mistaken, the larger problem is that glibc
> removed the futex() call entirely, so these man pages don't describe
> something users even have access to anymore. I had to revert to calling
> the syscalls directly in the futextest test suite because of this:
>
> h
Hi!
> > However, unless I'm sorely mistaken, the larger problem is that glibc
> > removed the futex() call entirely, so these man pages don't describe
> > something users even have access to anymore. I had to revert to calling
> > the syscalls directly in the futextest test suite because of this:
>
Hi!
> People have a number of times noted that there are problems
> with syscall(), but I'm not knowledgeable on the details.
> I'd happily take a patch to the man page (which, for historical
> reasons, is actually syscall(2)) that explains the the problems
> (and ideally notes those platforms whe
Hi!
> > Have a look at this commit that tries to deal with passing 64 bit
> > numbers to syscalls. On 32 bit ABI (but not on X32) these needs to be
> > split up (accordingly to machine endianity).
> >
> > https://github.com/linux-test-project/ltp/commit/04afb02b4280a20c262054e8f99a3fad4ad54916
> >
Hi!
> >> I really believe the proper fix is to use assembly syscall stubs. In
> >> klibc I build a fairly elaborate machinery to autogenerate such syscall
> >> stubs for a variety of architectures.
> >
> > Then it would be nice to share these between klibc and LTP (and possible
> > everybody else
Hi!
> I've used LTP in the past (quite a bit), and I felt there was some
> advantage to keeping futextest independent.
What advantages did you have in mind?
> Perhaps things have changed enough since then (~2009 era) that we
> should reconsider.
I've been working on LTP for a about three years n
Hi!
> > That is not the main concern here. If I extract the code I would have to
> > watch for any changes manually. If it was in a library or a separate
> > repository all that would be needed is to add it as dependency/git
> > submodule and I would get all updates automatically.
> >
>
> Yes, an
Hi!
> >> I've used LTP in the past (quite a bit), and I felt there was some
> >> advantage to keeping futextest independent.
> >
> >What advantages did you have in mind?
>
> Not CVS was a big one at the time ;-)
>
> OK, I don't mean to be disparaging here... But since you asked, back in
> '09 LTP
Good news everyone,
the Linux Test Project test suite stable release for *August 2014* has
been released.
Since the last release 311 patches by 24 authors were merged.
Notable changes are:
* New testcases and improved coverage for: madvise, waitid, timerfd_*,
getcwd, sched_setaffinity, sendfi
Hi!
> >> How much LTP harness type code needs to be used?
> >
> >Not much.
> >
> >For this complexity of tests you would just need to call the tst_resm()
> >interface to report success/failure and, at the end of the test,
> >tst_exit() to return the stored overall test status.
> >
> >And ideally ca
16 matches
Mail list logo
