Bug 485718

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Performance isn't the only motivation for inclusion of
mmu_notifier hooks.  As Andrea Arcangeli pointed out:

    Performance isn't the only reason. KVM guest-smp tlb flushing isn't
    safe without mmu notifiers and could corrupt memory (without mmu
    notifier feature enabled KVM may add pages to the kernel freelist
    while some other vcpu may still be writing to them through guest mode).

Created attachment 334024 [details]
patches to resolve case in bzip2'ed tar archive

Patch looks good. Wondering comment on populate_range can be removed,
all it matters are the pte manipulations and those are under the
_start/_end critical section. I already told Eduardo first time I seen
the backport few months ago.

Some potential kABI impact is there, that's why I mentioned it
yesterday during the conf call as I remembered there was one.

@@ -393,6 +394,9 @@
   /* aio bits */
   rwlock_t     ioctx_list_lock;
   struct kioctx                *ioctx_list;
+#ifdef CONFIG_MMU_NOTIFIER
+       struct mmu_notifier_mm *mmu_notifier_mm;
+#endif
 };

This grows the mm_struct. However existing drivers not using mmu
notifier shouldn't ever touch this new data, if they keep manipulating
their known offsets from the start of of the mm_struct things
shouldn't break and drivers shouldn't normally allocate any
'mm_struct' themself. So I guess things wouldn't break in a obvious
way for binary only drivers, but still I guess modversions won't allow
any driver with knowledge about mm_struct to load.

(In reply to comment #6)

> This grows the mm_struct. However existing drivers not using mmu
> notifier shouldn't ever touch this new data, if they keep manipulating
> their known offsets from the start of of the mm_struct things
> shouldn't break and drivers shouldn't normally allocate any
> 'mm_struct' themself. So I guess things wouldn't break in a obvious
> way for binary only drivers, but still I guess modversions won't allow
> any driver with knowledge about mm_struct to load.

That was my argument as well.  Drivers shouldn't care about the size
of an mm_struct and we're not changing offsets for existing members.
But the kABI checker still fails.  Even with the rework which removes
this pointer and uses an index residing in an unused structure padding
hole, the kABI checker fails -- neither size of the struct nor member
offsets have changed but the modversion checksum does.  This has been
addressed in the latest version of the patch.

Created attachment 335546 [details]
patches to resolve case in bzip2'ed tar archive

Removes pointer from mm_struct and uses an index residing
in an unused structure padding hole to avoid expanding
the structure size.  This patch also reconciles changes
from -132 to -133 in mm/memory.c with an update of the
core patch to linux-2.6-mmu_notifier-core-backport2.patch.

Created attachment 337085 [details]
patch series to resolve case in bzip2'ed tar archive

Update incorporating review comments.

Created attachment 338178 [details]
patch series to resolve case in bzip2'ed tar archive

in kernel-2.6.18-139.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html