Andrea Arcangeli | 1 Feb 01:01 2008

Re: mmu_notifier: close hole in fork

On Thu, Jan 31, 2008 at 02:01:43PM -0800, Christoph Lameter wrote:
> Talking to Robin and Jack we found taht we still have a hole during fork. 
> Fork may set a pte writeprotect. At that point the remote pte are 
> not marked readonly(!). Remote writes may occur to pages that are marked 
> readonly locally without this patch.

Good catch! This was missing also in my #v5 (KVM doesn't need that
because the only possible cows on sptes can be generated by ksm, but
it would have been a problem for GRU). The more I think about it, the
more I think GRU will run so nicely with follow_page taking zero
additional locking and with the nicely scalable PT lock that doesn't
require 1024 threads to trash on the same lock on 1024 different cpus
if they access addresses that aren't in the same naturally aligned 2M
chunk of virtual address space. I understood follow_page was
performance critical for GRU, if yes, then I hope my _dual_ approach
is by far the best for at least GRU (and KVM of course for the very
same reason), and of course it'll fit XPMEM too the moment you add
invalidate_range_start/end too.

Signed-off-by: Andrea Arcangeli <andrea@...>

diff --git a/mm/memory.c b/mm/memory.c
--- a/mm/memory.c
+++ b/mm/memory.c
 <at>  <at>  -494,6 +494,7  <at>  <at>  static int copy_pte_range(struct mm_stru
 	spinlock_t *src_ptl, *dst_ptl;
 	int progress = 0;
 	int rss[2];
+	unsigned long start;

(Continue reading)

Santiago Garcia Mantinan | 1 Feb 01:04 2008

Re: dl2k stopped working on 2.6.24

> I have today compiled dl2k from git, the version with the 2007-12-23 patches
> from Al Viro: dl2k endianness fixes (.24 fodder?) Right before the Al Viro
> patches. This seems to be working perfectly on my system.

Ok, I've been applying Al's patches one by one, everything went fine till I
applied the "dl2k: MSCR, MSSR, ESR, PHY_SCR fixes" patch. With this patch I
experimented the behaviour I commented on my first message.

I don't know what else to try now, any ideas?


Manty/BestiaTester ->
Robert Hancock | 1 Feb 01:09 2008

Re: PROBLEM REMAINS: [sata_nv ADMA breaks ATAPI] Crash on accessing DVD-RAM

Alexander wrote:
> Hello!
> The problem described at and
> at and supposedly fixed by the
> patch is still
> there. I have compiled 2.6.24-rc7 kernel and booted my PC with it just to find
> out that my SATA DVD-RW is
> sr0: scsi3-mmc drive: 0x/0x caddy
> as it was before with and earlier 2.6 kernels compiled for x86_64.
> Trying to use sr0 after this results in dead hang or reboot.
> When I put sata_nv.adma=0 or mem=4096M then it's all ok:

Can you (or others experiencing this problem) test the latest patch 
attached to the RH Bugzilla entry here:

and see if it resolves the problem? I have one report of success so far.
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo <at>
More majordomo info at

Andrea Arcangeli | 1 Feb 01:13 2008

Re: mmu_notifier: Move mmu_notifier_release up to get rid of the invalidat_all() callback

On Thu, Jan 31, 2008 at 02:21:58PM -0800, Christoph Lameter wrote:
> Is this okay for KVM too?

->release isn't implemented at all in KVM, only the list_del generates

I think current code could be already safe through the mm_count pin,
becasue KVM relies on the fact anybody pinning through mm_count like
KVM does, is forbidden to call unregister and it's forced to wait the
auto-disarming when mm_users hits zero, but I feel like something's
still wrong if I think that I'm not using call_rcu to free the
notifier (OTOH we agreed the list had to be frozen and w/o readers
(modulo _release) before _release is called, so if this initial
assumption is ok it seems I may be safe w/o call_rcu?).

But it's really tricky path. Anyway this is the last of my worries
right now, it works perfectly fine with a single user obviously, and
the moment KVM threads runs remotely through GRU/XPMEM isn't happening
too soon ;) so let's concentrate on the rest first. I can say
hlist_del_init doesn't seem to provide any benefit given nobody could
possibly decide to call register or unregister after _release run.

This email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Robert Hancock | 1 Feb 01:14 2008

Re: a7839e96 (PNP: increase max resources) breaks my ALSA intel8x0 sound card

Andrew Morton wrote:
>> There was a patch floating around to ignore PnPACPI reservations which 
>> conflict with PCI BARs, which appears to be what's happening in this 
>> case. That patch originally worked for any board, but was later made 
>> specific to a certain Supermicro motherboard which had the sata_nv 
>> controller MMIO regions marked as reserved, preventing the driver from 
>> loading. We may need a more general solution. See:
> Thanks.  If we were to remove the supermicro-specificity, would this be a
> sufficiently general solution?

I think so. There was one objection that it introduced a dependency on 
pnpacpi loading after PCI bus enumeration, though.

Linus also suggested that pnpacpi could be marking the resources as 
"present but unused" so that drivers can request those regions but we 
still prevent dynamically assigning resources into them.
Andrew Vasquez | 1 Feb 01:14 2008

Re: [PATCH 2/3] pci: Remove users of pci_enable_device_bars()

On Tue, 08 Jan 2008, Benjamin Herrenschmidt wrote:

> On Mon, 2008-01-07 at 11:42 -0800, Andrew Vasquez wrote:
> > That's fine.  I take it these patches will be funneled via
> > gregkh/pci-2.6.git.  There's some qla2xxx updates which are queued for
> > post-2.6.24 consumption in jejb/scsi-misc-2.6.git which don't appear
> > to have any conflicts.
> > 
> > I do though have a series of patches which I'll hold off on submitting
> > to linux-scsi until these PCI changes are merged, as there's some
> > minor conflicts merging the three branches.  James B, will that be
> > fine?
> > 
> > The patches themselves appear to be working fine within several of our
> > test rings.  I hold off on some of the cleanup post-merge time...
> Thanks for testing ! They should be queued with Greg indeed.

Just curious, this patch-set hasn't made it upstream to linux-2.6.git,
will the work be deferred to 2.6.26??

H. Peter Anvin | 1 Feb 01:23 2008

Re: [PATCH] x86: add a crc32 checksum to the kernel image.

H. Peter Anvin wrote:
> Hm.  I have some minor concerns about this:
> * The classical length field is only available in multiples of 16 (I 
> realize your patches change that to some degree, but I'd hate to make 
> the guarantee that the image payload is the last thing in the image -- 
> it loses flexibility for the future.)  The end of the image isn't 
> available in all cases, so this would require padding it out to a 
> 16-byte boundary before appending the CRC32.  An mmap is guaranteed to 
> be zero-padded out to the next page boundary, so explicitly rounding sz 
> up (instead of when calculating sys_size) should do the job.

Thinking about this more carefully, we should probably have it rounded 
up to a 16-byte boundary *including* the CRC32, so the CRC32 is included 
in the notional image.

Pavel Machek | 1 Feb 01:42 2008

how to tell i386 from x86-64 kernel


Quiz: on a booted system, how do you tell 32bit from 64bit kernel?

A1: zcat /proc/config.gz | grep CONFIG_64

...but config.gz is optional

A2: cat /proc/meminfo  | grep High

...but i386 kernel could have highmem disabled

What is _your_ answer? ;-)>

(cesky, pictures)
David Newall | 1 Feb 01:43 2008

Re: [PATCH] x86: add a crc32 checksum to the kernel image.

Isn't a crc32 calculation already defined?  Yes; in lib/crc32.c.  One is
surely enough.
Ray Lee | 1 Feb 01:46 2008

Re: how to tell i386 from x86-64 kernel

On Jan 31, 2008 4:42 PM, Pavel Machek <pavel <at>> wrote:
> Quiz: on a booted system, how do you tell 32bit from 64bit kernel?

Uhm, is this a trick question? What's wrong with uname(2)?