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] [thread-next>] [day] [month] [year] [list]
Message-ID: <2ea1731b0906172324g4654966eq22cf0bdbd3eafabf@mail.gmail.com>
Date:	Thu, 18 Jun 2009 08:24:35 +0200
From:	Marco Stornelli <marco.stornelli@...il.com>
To:	Paul Mundt <lethal@...ux-sh.org>,
	Marco <marco.stornelli@...il.com>,
	Linux FS Devel <linux-fsdevel@...r.kernel.org>,
	linux@....linux.org.uk, linux-m68k@...ts.linux-m68k.org,
	uclinux-dist-devel@...ckfin.uclinux.org,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Daniel Walker <dwalker@....ucsc.edu>
Subject: Re: [PATCH 13/14] Pramfs: Write Protection

2009/6/18 Paul Mundt <lethal@...ux-sh.org>:
> On Wed, Jun 17, 2009 at 06:58:00PM +0200, Marco wrote:
>> Jared Hulbert wrote:
>> > > Why not just fix flush_tlb_range()?
>> > >
>> > > If an arch has a flush_tlb_kernel_page() that works then it stands to
>> > > reason that the flush_tlb_kernel_range() shouldn't work with minimal
>> > > effort, no?
>> >
>> > flush_tlb_kernel_page() is a new one to me, it doesn't have any mention
>> > in Documentation/cachetlb.txt anyways.
>> >
>> > Many of the flush_tlb_kernel_range() implementations do ranged checks
>> > with tunables to determine whether it is more expensive to selectively
>> > flush vs just blowing the entire TLB away.
>> >
>> > Likewise, there is no reason why those 4 architectures can not just shove
>> > that if (end <= start + PAGE_SIZE) check in the beginning of their
>> > flush_tlb_kernel_range() and fall back on flush_tlb_kernel_page() for
>> > those cases. Hiding this in generic code is definitely not the way to go.
>>
>> Ok I'll change that function at arch level and I'll remove the ifdef,
>> I'll call only flush_tlb_kernel_page(), but I'd like to know what is
>> the opinion of the arch maintainers to do that.  (Who is the maintainer
>> of H8300 arch?)
>>
> No, you should call flush_tlb_kernel_range() and just fix up the
> flush_tlb_kernel_range() calls to wrap in to flush_tlb_kernel_page(). As
> far as the kernel is concerned, flush_tlb_kernel_page() is not a standard
> interface, as it has no mention in Documentation/cachetlb.txt.
> flush_tlb_page() and flush_tlb_kernel_range() on the other hand are both
> standard interfaces.

Oops, my fault. I meant flush_tlb_kernel_range not the page version,
sorry. I agree with you.

>
> H8300 is a nommu platform, so it has no TLB to flush. Yoshinori Sato is
> the maintainer. Consult the MAINTAINERS file, that's what it is there for.
>

I know the MAINTAINERS file but for h8300 there isn't an exactly
indication (/arch/h8300 as for the other archs).

Marco
--
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