linux-kernel - Status February 14, 2017

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <652f4377-4da8-a753-2672-5463dc053f12@oracle.com>
Date:   Tue, 14 Feb 2017 09:22:31 -0800
From:   Mike Kravetz <mike.kravetz@...cle.com>
To:     linux-kernel <linux-kernel@...r.kernel.org>
Cc:     linux_sparc_grp@...cle.com
Subject: Status February 14, 2017

- Finally some progress on sparc shared context efforts.  Turns out that
  the mondo timeout issue I spent a large amount of time chasing was a
  HW/FW issue with the non-production system I was using in the lab.  Sigh!
  Some good things did come from this:
  - I learned new debug techniques
  - I fixed up the reference counting code because in it's preliminary
    state it should not have caused any issues, but I was not sure.
  I have now been able to pass some initial stress/stability testing with
  a UEK4 jenkins based kernel.  Do note that this kernel also contains
  changes by Nitin Guputa and Bob Picco to change the way huge pages are
  handled.  These are the changes which are going upstream and will
  eventually replace the scheme developed for UEK2 that was forward ported
  to UEK4.

- A new issue with huge page reservations was brought up.  A task's memory
  policy is not taken into account when reservations are made.  However,
  when pages are allocated to satisfy faults the policy is used.  Therefore,
  it is possible that a reservation will succeed and an allocation at fault
  time will fail.  To be honest, I do not know the original intention of
  this code.  It is not well documented and the original authors are no
  longer active in this area.  I have become the default owner/maintainer
  of this stuff because nobody else wants to touch it. :)  So, I need to
  at least come up with proposal on how to proceed.

- After hugetlbfs support was added to userfaultfd, the qemu project took
  notece.  They are using userfaultfd for postcopy live migration.  They
  discovered the performance advantage of using huge pages.  However, when
  adding hugetlbfs support I added minimal functionality as this originally
  came from an Oracle DM request.  As a result, the current code only does 
  copies for private mappings.  Note that the DB does not do copies at all.
  The code really should support shared mappings as well.  Actually, some
  (Andrea) may consider this a bug.  This should not be too complicated,
  but the userfault code seems to present lots of 'corner cases'.

Plans

- Hand off a build of sparc shared context kernel for preliminary testing.
  Since this is early prototype code, I hope expectations are not too high.

- Make changes necessary for hugetlbfs userfaultfd copy to shared mappings.

- Come up with proposal/ideas for huge page reservation and memory policy
  interaction.

Out of Office

- US Holiday, February 20

- Vacation, March 13 - 17 

- LSF/MM, March 20 - 22

-- 
Mike Kravetz