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>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <AANLkTikq8jS6fK_VakFCQkYZtS3AprMMHDA6PnjAZGa7@mail.gmail.com>
Date:	Mon, 12 Jul 2010 10:43:41 +0800
From:	qingyuan huang <qingyuan82.huang@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: One question about the positions of flush_dcache_page and 
	bounce_copy_vec methods in copy_to_high_bio_irq

    Recently, I read the kernel codes from 2.6.32 to 2.6.35. I have a
question about the positions of flush_dcache_page and bounce_copy_vec
methods in copy_to_high_bio_irq function in mm/bounce.c file. In my
opinion, flush_dcache_page is written before bounce_copy_vec in order
to set the destination page in bounce_copy_vec  PG_dcache_dirty bit in
some platforms which have not hardware cache coherence protocol. But
when I read the flush_dcache_page codes in ARM and MIPS, I found there
could be some exceptions in this function copy_to_high_bio_irq. Take
ARM as a example, the flush_dcache_page in ARM platform has two
execution paths:
path1: set_bit(PG_dcache_dirty, &page->flags) (deffer flushing until
in update_mmu_cache)
path2: __flush_dcache_page (mapping, page); if(mapping) __flush_icache_all();
If the codes run in path2 not path1, because the cache is flushed
before copy operation , it could make a mistake in
copy_to_high_bio_irq function. At this situation, the I/D cache could
be incoherent, and the system could run the bad instructions in i
cache. If we switch the positions of the two funcitons, we could not
meet this qustion and it could not lower the performance.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ