* No zone_reclaim if PF_MALLOC is set.
From: Christoph Lameter @ 2006-03-09 4:36 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
If the process has already set PF_MALLOC and is already using
current->reclaim_state then do not try to reclaim memory from the zone.
This is set by kswapd and/or synchrononous global reclaim which will not
take it lightly if we zap the reclaim_state.
Signed-off-by: Christoph Lameter <clameter@sig.com>
Index: linux-2.6.16-rc5/mm/vmscan.c
===================================================================
--- linux-2.6.16-rc5.orig/mm/vmscan.c 2006-02-26 21:09:35.000000000 -0800
+++ linux-2.6.16-rc5/mm/vmscan.c 2006-03-08 20:35:47.000000000 -0800
@@ -1883,7 +1883,8 @@ int zone_reclaim(struct zone *zone, gfp_
if (!(gfp_mask & __GFP_WAIT) ||
zone->all_unreclaimable ||
- atomic_read(&zone->reclaim_in_progress) > 0)
+ atomic_read(&zone->reclaim_in_progress) > 0 ||
+ (p->flags & PF_MEMALLOC))
return 0;
node_id = zone->zone_pgdat->node_id;
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Jesse Barnes @ 2006-03-09 4:36 UTC (permalink / raw)
To: Paul Mackerras
Cc: Linus Torvalds, akpm, linux-arch, linux-kernel, mingo, Alan Cox,
linuxppc64-dev
In-Reply-To: <17423.42185.78767.837295@cargo.ozlabs.ibm.com>
On Wednesday, March 08, 2006 7:45 pm, Paul Mackerras wrote:
> If we can have the following rules:
>
> * If you have stores to regular memory, followed by an MMIO store,
> and you want the device to see the stores to regular memory at the
> point where it receives the MMIO store, then you need a wmb() between
> the stores to regular memory and the MMIO store.
>
> * If you have PIO or MMIO accesses, and you need to ensure the
> PIO/MMIO accesses don't get reordered with respect to PIO/MMIO
> accesses on another CPU, put the accesses inside a spin-locked
> region, and put a mmiowb() between the last access and the
> spin_unlock.
>
> * smp_wmb() doesn't necessarily do any ordering of MMIO accesses
> vs. other accesses, and in that sense it is weaker than wmb().
This is a good set of rules. Hopefully David can add something like
this to his doc.
> ... then I can remove the sync from write*, which would be nice, and
> make mmiowb() be a sync. I wonder how long we're going to spend
> chasing driver bugs after that, though. :)
Hm, a static checker should be able to find this stuff, shouldn't it?
Jesse
^ permalink raw reply
* Re: filldir[64] oddness
From: Stephen Rothwell @ 2006-03-09 4:34 UTC (permalink / raw)
To: Dave Jones; +Cc: linux-kernel
In-Reply-To: <20060309042744.GA23148@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 992 bytes --]
On Wed, 8 Mar 2006 23:27:44 -0500 Dave Jones <davej@redhat.com> wrote:
>
> I'm puzzled by an aparent use of uninitialised memory
> that coverity's checker picked up.
>
> fs/readdir.c
>
> #define NAME_OFFSET(de) ((int) ((de)->d_name - (char __user *) (de)))
> #define ROUND_UP(x) (((x)+sizeof(long)-1) & ~(sizeof(long)-1))
>
> 140 static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
> 141 ino_t ino, unsigned int d_type)
> 142 {
> 143 struct linux_dirent __user * dirent;
> 144 struct getdents_callback * buf = (struct getdents_callback *) __buf
> 145 int reclen = ROUND_UP(NAME_OFFSET(dirent) + namlen + 2);
>
> How come that NAME_OFFSET isn't causing an oops when
> it dereferences stackjunk->d_name ?
because d_name is an array, so the reference is really &(dirent->d_name[0]) and no
dereference occurs ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Jesse Barnes @ 2006-03-09 4:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: Paul Mackerras, akpm, linux-arch, linux-kernel, mingo, Alan Cox,
linuxppc64-dev
In-Reply-To: <Pine.LNX.4.64.0603081716400.32577@g5.osdl.org>
On Wednesday, March 08, 2006 5:27 pm, Linus Torvalds wrote:
> That said, when I heard of the NUMA IO issues on the SGI platform, I
> was initially pretty horrified. It seems to have worked out ok, and
> as long as we're talking about machines where you can concentrate on
> validating just a few drivers, it seems to be a good tradeoff.
It's actually not too bad. We tried hard to make the arch code support
the semantics that Linux drivers expect. mmiowb() was an optimization
we added (though it's much less of an optimization than read_relaxed()
was) to make things a little faster. Like you say, the alternative was
to embed the same functionality into spin_unlock or something (IRIX
actually had an io_spin_unlock that did that iirc), but that would mean
an MMIO access on every unlock, which would be bad.
So ultimately mmiowb() is the only thing drivers really have to care
about on Altix (assuming they do DMA mapping correctly), and the rules
for that are fairly simple. Then they can additionally use
read_relaxed() to optimize performance a bit (quite a bit on big
systems).
> Would I want the hard-to-think-about IO ordering on a regular desktop
> platform? No.
I guess you don't want anyone to send you an O2 then? :)
Jesse
^ permalink raw reply
* Re: filldir[64] oddness
From: Vadim Lobanov @ 2006-03-09 4:33 UTC (permalink / raw)
To: Dave Jones; +Cc: Linux Kernel
In-Reply-To: <20060309042744.GA23148@redhat.com>
On Wed, 8 Mar 2006, Dave Jones wrote:
> I'm puzzled by an aparent use of uninitialised memory
> that coverity's checker picked up.
>
> fs/readdir.c
>
> #define NAME_OFFSET(de) ((int) ((de)->d_name - (char __user *) (de)))
> #define ROUND_UP(x) (((x)+sizeof(long)-1) & ~(sizeof(long)-1))
>
> 140 static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
> 141 ino_t ino, unsigned int d_type)
> 142 {
> 143 struct linux_dirent __user * dirent;
> 144 struct getdents_callback * buf = (struct getdents_callback *) __buf
> 145 int reclen = ROUND_UP(NAME_OFFSET(dirent) + namlen + 2);
>
> How come that NAME_OFFSET isn't causing an oops when
> it dereferences stackjunk->d_name ?
If I had to guess...
Because NAME_OFFSET(de) is essentially doing
de->d_name - de
which should be equivalent to just the static offset of d_name within
struct linux_direct. Which should be constant, no? Why does it need to
pass a pointer to compute this? Who knows.
> Dave
>
> --
> http://www.codemonkey.org.uk
- Vadim Lobanov
^ permalink raw reply
* Re: filldir[64] oddness
From: David S. Miller @ 2006-03-09 4:32 UTC (permalink / raw)
To: davej; +Cc: linux-kernel
In-Reply-To: <20060309042744.GA23148@redhat.com>
From: Dave Jones <davej@redhat.com>
Date: Wed, 8 Mar 2006 23:27:44 -0500
> #define NAME_OFFSET(de) ((int) ((de)->d_name - (char __user *) (de)))
> #define ROUND_UP(x) (((x)+sizeof(long)-1) & ~(sizeof(long)-1))
>
> 140 static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
> 141 ino_t ino, unsigned int d_type)
> 142 {
> 143 struct linux_dirent __user * dirent;
> 144 struct getdents_callback * buf = (struct getdents_callback *) __buf
> 145 int reclen = ROUND_UP(NAME_OFFSET(dirent) + namlen + 2);
>
> How come that NAME_OFFSET isn't causing an oops when
> it dereferences stackjunk->d_name ?
d_name a char[] array, and we're just doing pointer arithmetic
here. It's the same as "offsetof(d_name, struct linux_dirent)"
or something like that.
I think coverity is being trigger happy in this case :-)
^ permalink raw reply
* Re: [Updated]: How to become a kernel driver maintainer
From: Randy.Dunlap @ 2006-03-09 4:32 UTC (permalink / raw)
To: Ben Collins; +Cc: linux-kernel, torvalds
In-Reply-To: <1141841013.24202.194.camel@grayson>
On Wed, 08 Mar 2006 13:03:33 -0500 Ben Collins wrote:
> Only small changes, title and a little rewording regarding "local
> development copy". I will submit a patch if there are no more changes to
> this document.
in addition to other comments:
> Another benefit of having the driver in the kernel tree is to promote
> the
> hardware that it supports. Many companies who have written drivers for
s/who/that/ (companies are not a person; "who" is for persons)
> their hardware to run under Linux have not yet taken the leap to placing
> the driver in the main kernel. The "Old Way" of providing downloadable
> drivers doesn't work as well for Linux, since it's almost impossible to
> provide pre-compiled versions for any given system. Having the driver in
> the kernel tree means it will always be available. It also means that
> users wishing to purchase hardware that "Just Works" with Linux will
> have
> more options. A well written and stable driver is a good reason for a
well-written
> user
> to choose that particular type of hardware.
>
> Having drivers in the main kernel tree benefits everyone.
>
>
> What should I do to prepare for code submission?
> ------------------------------------------------
>
> First you need to inspect your code and make sure it meets criteria for
> inclusion. Read Documentation/CodingStyle for help on proper coding
> format
> (indentation, comment style, etc). It is strongly suggested that your
> driver builds cleanly when checked by the "sparse" tool. You will
> probably
> need to annotate the driver so sparse can tell that it is following the
> kernel's rules for address space accesses and endianness. Adding these
> annotations is a simple, but time-consuming, operation that often
> exposes
> real portability problems in drivers.
>
> Once you have properly formatted the code, you also need to check a few
> other areas. Most drivers include backward compatibility for older
> kernels
> (usually ifdef's with LINUX_VERSION_CODE). This backward compatibility
> needs to be removed. It's considered a waste of code for the driver to
> be
> backward compatible within the kernel source tree, since it is going to
> be
> compiled with a known version of the kernel.
Also use "make checkstack", "make buildcheck", and "make namespacecheck"
to check for problems that they can detect.
> Proper location in the kernel source needs to be determined. Find
> drivers
> similar to yours, and use the same location. For example, USB network
> drivers go in drivers/usb/net/, and filesystems go in fs/.
>
> The driver should then be prepared for building from the main source
> tree
> in this location. A proper Makefile and Kconfig file in the Kbuild
> format
and Kbuild Makefile & Kconfig files are described in Documentation/kbuild/*
> should be provided. Most times it is enough to just add your entries to
> existing files. Here are some good rules to follow:
>
> - If your driver is a single source file (or single .c with a
> single .h),
> then it's typical to place the driver in an existing directory. Also,
> modify existing Makefile/Kconfig for that directory.
>
> - If your driver is made up of several source files, then it is typical
> to create a subdirectory for it under the existing directory where it
> applies. Separate Makefile should be included, with a reference in
> the
> parent Makefile to make sure to descend into the one you created.
>
> + In this case, it is usually still correct to just add the Kconfig
> entry to the existing one. Unless your driver has 2 or more config
s/Unless/If/
> options (debug options, extra features, etc), then creating a
> standalone Kconfig may be best. Make sure to source this new
> Kconfig
> from the parent directory.
>
> - When creating the Kconfig entries be sure to keep in mind the
> criteria
> for the driver to be build. For example, a wireless network driver
> may
s/build/built/
> need to "depend on NET && IEEE80211". Also, if you driver is
> specific
s/you/your/
> to a certain architecture, be sure the Kconfig entry reflects this.
> DO
> NOT force your driver to a specific architecture simply because the
> driver is not written portably.
>
> Lastly, you'll need to create an entry in the MAINTAINERS file. It
> should
> reference you or the team responsible for the code being submitted (this
> should be the same person/team submitting the code).
and the mailing list that should be used for correspondence.
> Code review
> -----------
>
> Once your patches are ready, you can submit them to the linux-kernel
> mailing list. However, since most drivers fall under some subsystem
> (net,
> usb, etc), then it is often required that you also Cc the mailing list
> for
> this subsystem (see MAINTAINERS file for help finding the correct
> address).
I disagree that lkml should always be used. It is becoming terribly
over-burdened recently so either people are spending more time reading
too much email or they are ignoring it. It would be better IMO to
send patches for focused mailing lists that are appropriate for the
driver.
> The code review process is there for two reasons. First, it ensures that
> only good code, that follows current API's and coding practices, gets
> into
> the kernel. The kernel developers know you have good intentions of
> maintaining your driver, but too often a driver is submitted to the
> kernel, and some time later becomes unmaintained. Then developers who
> are
> not familiar with the code or it's purpose are left with keeping it
s/it's/its/
> compiling and working. So the code needs to be readable, and easily
> modified.
> What is expected of me after my driver is accepted?
> ---------------------------------------------------
>
> The real work of maintainership begins after your code is in the tree.
> This is where some maintainers fail, and is the reason the kernel
> developers are so reluctant to allow new drivers into the main tree.
I disagree with that last part. I guess I have seen some reluctance
occasionally, but I don't think that it's the (main) reason for
drivers not being accepted into the kernel tree.
> How should I maintain my code after it's in the kernel tree?
> ------------------------------------------------------------
>
> Whatever you decide to use for keeping your kernel tree, just remember
> that the kernel tree source is the primary code. Your repository should
> mainly be used for queuing patches, and doing development. Users should
> not have to regularly go to your source in order to get a stable and
> usable driver.
amen.
---
~Randy
^ permalink raw reply
* filldir[64] oddness
From: Dave Jones @ 2006-03-09 4:27 UTC (permalink / raw)
To: Linux Kernel
I'm puzzled by an aparent use of uninitialised memory
that coverity's checker picked up.
fs/readdir.c
#define NAME_OFFSET(de) ((int) ((de)->d_name - (char __user *) (de)))
#define ROUND_UP(x) (((x)+sizeof(long)-1) & ~(sizeof(long)-1))
140 static int filldir(void * __buf, const char * name, int namlen, loff_t offset,
141 ino_t ino, unsigned int d_type)
142 {
143 struct linux_dirent __user * dirent;
144 struct getdents_callback * buf = (struct getdents_callback *) __buf
145 int reclen = ROUND_UP(NAME_OFFSET(dirent) + namlen + 2);
How come that NAME_OFFSET isn't causing an oops when
it dereferences stackjunk->d_name ?
Dave
--
http://www.codemonkey.org.uk
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Jesse Barnes @ 2006-03-09 4:26 UTC (permalink / raw)
To: Paul Mackerras
Cc: akpm, linux-arch, linux-kernel, Linus Torvalds, mingo, Alan Cox,
linuxppc64-dev
In-Reply-To: <17423.35719.758492.297725@cargo.ozlabs.ibm.com>
On Wednesday, March 08, 2006 5:57 pm, Paul Mackerras wrote:
> > The rules for using
> > the barriers really aren't that bad... for mmiowb() you basically
> > want to do it before an unlock in any critical section where you've
> > done PIO writes.
>
> Do you mean just PIO, or do you mean PIO or MMIO writes?
I'd have to check, but iirc it was just MMIO. We assumed PIO (inX/outX)
was defined to be very strongly ordered (and thus slow) in Linux. But
Linus is apparently flexible on that point for the new ioreadX/iowriteX
stuff.
> Yes, there is a lot of confusion, unfortunately. There is also some
> difficulty in defining things to be any different from what x86 does.
Well, Alpha has smp_barrier_depends or whatever, that's *really* funky.
> > That's why I suggested in an earlier thread that you enumerate all
> > the memory ordering combinations on ppc and see if we can't define
> > them all.
>
> The main difficulty we strike on PPC is that cacheable accesses tend
> to get ordered independently of noncacheable accesses. The only
> instruction we have that orders cacheable accesses with respect to
> noncacheable accesses is the sync instruction, which is a heavyweight
> "synchronize everything" operation. It acts as a full memory barrier
> for both cacheable and noncacheable loads and stores.
Ah, ok, sounds like your chip needs an ISA extension or two then. :)
> The other barriers we have are the lwsync instruction and the eieio
> instruction. The lwsync instruction (light-weight sync) acts as a
> memory barrier for cacheable loads and stores except that it allows a
> following load to go before a preceding store.
This sounds like ia64 acquire semantics, a fence, but only in the
downward direction.
> The eieio instruction has two separate and independent effects. It
> acts as a full barrier for accesses to noncacheable nonprefetchable
> memory (i.e. MMIO or PIO registers), and it acts as a write barrier
> for accesses to cacheable memory. It doesn't do any ordering between
> cacheable and noncacheable accesses though.
Weird, ok, so for cacheable stuff it's equivalent to ia64's release
semantics, but has additional effects for noncacheable accesses. Too
bad it doesn't tie the two together somehow.
> There is also the isync (instruction synchronize) instruction, which
> isn't explicitly a memory barrier. It prevents any following
> instructions from executing until the outcome of any previous
> conditional branches are known, and until it is known that no
> previous instruction can generate an exception. Thus it can be used
> to create a one-way barrier in spin_lock and read*.
Hm, interesting.
> Unfortunately, if you get the barriers wrong your driver will still
> work most of the time on pretty much any machine, whereas if you get
> the DMA mapping wrong your driver won't work at all on some machines.
> Nevertheless, we should get these things defined properly and then
> try to make sure drivers do the right things.
Agreed. Having a set of rules that driver writers can use would help
too. Given that PPC doesn't appear to have a lightweight way of
synchronizing between I/O and memory accesses, it sounds like full
syncs will be needed in a lot of cases.
Jesse
^ permalink raw reply
* [Ocfs2-devel] Ocfs2 performance bugs of doom
From: Andi Kleen @ 2006-03-09 4:19 UTC (permalink / raw)
To: Nick Piggin
Cc: Daniel Phillips, Mark Fasheh, Andrew Morton, linux-kernel,
ocfs2-devel
In-Reply-To: <440FDC8E.9060907@yahoo.com.au>
On Thursday 09 March 2006 08:43, Nick Piggin wrote:
> Just interested: do the locks have any sort of locality of lookup?
> If so, then have you tried moving hot (ie. the one you've just found,
> or newly inserted) hash entries to the head of the hash list?
>
> In applications with really good locality you can sometimes get away
> with small hash tables (10s even 100s of collisions on average) without
> taking too big a hit this way, because your entries basically get sorted
> LRU for you.
LRU hashes have really bad cache behaviour though if that is not the case
because you possibily need to bounce around the hash heads as DIRTY
cache lines instead of keeping them in SHARED state.
My feeling would be that scalability is more important for this, which would
discourage this.
-Andi
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Jesse Barnes @ 2006-03-09 4:18 UTC (permalink / raw)
To: Paul Mackerras
Cc: Matthew Wilcox, Linus Torvalds, David Howells, Alan Cox, akpm,
mingo, linux-arch, linuxppc64-dev, linux-kernel
In-Reply-To: <17423.34439.977741.295065@cargo.ozlabs.ibm.com>
On Wednesday, March 08, 2006 5:36 pm, Paul Mackerras wrote:
> Jesse Barnes writes:
> > It uses a per-node address space to reference the local bridge.
> > The local bridge then waits until the remote bridge has acked the
> > write before, then sets the outstanding write register to the
> > appropriate value.
>
> That sounds like mmiowb can only be used when preemption is disabled,
> such as inside a spin-locked region - is that right?
There's a scheduler hook to flush things if a process moves. I think
Brent Casavant submitted that patch recently.
Jesse
^ permalink raw reply
* RE: [PATCH] Fix MPC8548CDS rebooting procedure
From: Haruki Dai-r35557 @ 2006-03-09 4:16 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
> -----Original Message-----
> From: Kumar Gala [mailto:galak@kernel.crashing.org]=20
> Sent: Wednesday, March 08, 2006 9:14 PM
> To: Haruki Dai-r35557
> Cc: linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
>=20
>=20
> On Mar 8, 2006, at 1:24 PM, Haruki Dai-r35557 wrote:
>=20
> >> -----Original Message-----
> >> From: Kumar Gala [mailto:galak@kernel.crashing.org]
> >> Sent: Wednesday, March 08, 2006 12:33 PM
> >> To: Haruki Dai-r35557
> >> Cc: linuxppc-dev@ozlabs.org
> >> Subject: Re: [PATCH] Fix MPC8548CDS rebooting procedure
> >>
> >>
> >> On Mar 8, 2006, at 11:22 AM, Haruki Dai-r35557 wrote:
> >>
> >>> This patch fixes the MPC8548 CDS rebooting procedure.
> >>> Without this patche, issuing reboot from shell doesn't reboot the=20
> >>> machine.
> >>>
> >>> Signed-off-by: Dai Haruki <dai.haruki@freescale.com>
> >>
> >> Dai, I'm avoid taking patches for 85xx that effect new=20
> functionality. =20
> >> If you want change this to work with arch/powerpc and make=20
> it a run=20
> >> time check for 8548.
> >
> > Hi Kumar, what kind of new feature is affected by this bug=20
> fix? 8548=20
> > requires reboot to set the hardware reset bits. The mpc85xx_restart
> > () is
> > not ported to arch/powerpc yet. Which portion of the=20
> arch/powerpc code=20
> > should be modified in order to restart the machine correctly?
> > And how do you want me to do run time check? Check SVR?
>=20
> Restart has never worked properly on the 85xx boards from=20
> freescale since they never provided a reasonable way to reset=20
> the systems in software. So I consider this new=20
> functionality at this point.
>=20
> The powerpc.git tree has an=20
> arch/powerpc/platforms/85xx/misc.c that has a mpc85xx_restart() in it.
Thanks. I didn't work on the powerpc.git tree. I will submit the patch
based on the powerpc.git tree.
>=20
> As for run time checking, yes use something like SVR or PVR=20
> to determine the feature. In this case its probably best to=20
> using something like PVR and check for E500r1. I imagine=20
> 8540, 8541, 8555, 8560 don't support this feature (all=20
> e500r1), but all future 8548 and newer parts will (e500r2, etc.)
OK. I will modify it as you suggest.=20
regards,
Dai.
>=20
> - kumar
>=20
^ permalink raw reply
* [PATCH] Don't recurse into parents marked uninteresting.
From: Matthias Urlichs @ 2006-03-09 4:04 UTC (permalink / raw)
To: git
In-Reply-To: <pan.2006.03.08.20.04.24.62170@smurf.noris.de>
revision.c:make_parents_uninteresting() is exponential with the number
of merges in the tree. That's fine -- unless some other part of git
already has pulled the whole commit tree into memory ...
---
... or, in other words, "Don't do that, please."
With this patch, all tests still succeed, and the "git push" which
triggered the problem takes 5min instead of an estimated 10mio years.
---
revision.c | 24 +++++++++++++-----------
1 files changed, 13 insertions(+), 11 deletions(-)
32c9750691d1ef225ca1641fdf6902e53c25fe5b
diff --git a/revision.c b/revision.c
index 2a33637..713f27e 100644
--- a/revision.c
+++ b/revision.c
@@ -82,18 +82,20 @@ void mark_parents_uninteresting(struct c
while (parents) {
struct commit *commit = parents->item;
- commit->object.flags |= UNINTERESTING;
+ if (!(commit->object.flags & UNINTERESTING)) {
+ commit->object.flags |= UNINTERESTING;
- /*
- * Normally we haven't parsed the parent
- * yet, so we won't have a parent of a parent
- * here. However, it may turn out that we've
- * reached this commit some other way (where it
- * wasn't uninteresting), in which case we need
- * to mark its parents recursively too..
- */
- if (commit->parents)
- mark_parents_uninteresting(commit);
+ /*
+ * Normally we haven't parsed the parent
+ * yet, so we won't have a parent of a parent
+ * here. However, it may turn out that we've
+ * reached this commit some other way (where it
+ * wasn't uninteresting), in which case we need
+ * to mark its parents recursively too..
+ */
+ if (commit->parents)
+ mark_parents_uninteresting(commit);
+ }
/*
* A missing commit is ok iff its parent is marked
--
Matthias Urlichs
^ permalink raw reply related
* Re: [PATCH] mm: yield during swap prefetching
From: Con Kolivas @ 2006-03-09 4:08 UTC (permalink / raw)
To: Zan Lynx
Cc: André Goddard Rosa, Lee Revell, Andrew Morton, linux-mm,
linux-kernel, ck
In-Reply-To: <1141874012.21958.138.camel@localhost>
[-- Attachment #1: Type: text/plain, Size: 1667 bytes --]
Zan Lynx writes:
> On Thu, 2006-03-09 at 11:07 +1100, Con Kolivas wrote:
>> Games worked on windows for a decade on single core without real time
>> scheduling because that's what they were written for.
>>
>> Now that games are written for windows with dual core they work well -
>> again
>> without real time scheduling.
>>
>> Why should a port of these games to linux require real time?
>
> That isn't what I said. I said nothing about *requiring* anything, only
> about how to do it better.
>
> Here is what Con said that I was disagreeing with. All the rest was to
> justify my disagreement.
>
> Con said, "... games should _not_ need special scheduling classes. They
> are not written in a real time smart way and they do not have any
> realtime constraints or requirements."
>
> And he said later, "No they shouldn't need real time scheduling to work
> well if they are coded properly."
>
> Here is a list of simple statements of what I am saying:
> Games do have real-time requirements.
> The OS guessing about real-time priorities will sometimes get it wrong.
> Guessing task priority is worse than being told and knowing for sure.
> Games should, in an ideal world, be using real-time OS scheduling.
> Games would work better using real-time OS scheduling.
At the risk of being repetitive to the point of tiresome, my point is that
there are no real time requirements in games. You're assuming that
everything will be better if we assume that there are rt requirements and
that we're simulating pseudo real time conditions currently. That's just not
the case and never has been. That's why it has worked fine for so long.
Cheers,
Con
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Kernel panic on PC with broken hard drive, after DMA errors
From: Robert Hancock @ 2006-03-09 4:03 UTC (permalink / raw)
To: Martin Michlmayr, linux-kernel
In-Reply-To: <5Okau-77g-9@gated-at.bofh.it>
Martin Michlmayr wrote:
> My laptop hard drive recently died (or is in the process of dying).
> HP wanted me to do some more tests before sending me a replacement, so
> I tried booting Linux again today. I got lots of DMA errors, which
> was really to be expected, but then I got a kernel panic. While I'd
> not blame the kernel when a panic occurs with broken RAM or CPU, I'm
> sure sure the kernel should panic just because of a broken IDE drive.
>
> I posted a picture of the panic at http://cyrius.com/tmp/ide_panic.jpg
> Is this something that can be fixed or is my hardware really so broken
> that the kernel cannot deal with it?
Probably is a genuine bug. These kinds of reports have come up a few
times recently as I recall - it seems some of the error handling in the
drivers/ide code isn't quite so robust..
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@nospamshaw.ca
Home Page: http://www.roberthancock.com/
^ permalink raw reply
* Re: State of the Linux PCI and PCI Hotplug Subsystems for 2.6.16-rc5
From: Kenji Kaneshige @ 2006-03-09 4:01 UTC (permalink / raw)
To: Greg KH; +Cc: torvalds, akpm, linux-kernel, linux-pci, pcihpd-discuss
In-Reply-To: <20060306223545.GA20885@kroah.com>
Greg KH wrote:
> Here's a summary of the current state of the Linux PCI and PCI Hotplug
> subsystems as of 2.6.16-rc5
>
> If the information in here is incorrect, or anyone knows of any
> outstanding issues not listed here, please let me know.
>
> List of outstanding regressions from 2.6.15:
> - none known.
>
> List of outstanding regressions from older kernel versions:
> - some cardbus users still have issues with the change to the
> PCI resource allocation stuff.
> http://bugzilla.kernel.org/show_bug.cgi?id=5736 shows this
> issue, but seems to be stalled for now :(
>
> Here is a list of the current outstanding bugs for the PCI subsystem as
> tracked at bugzilla.kernel.org. If anyone can help out with any of
> these, please add information to the bug reports.
>
> * 5736 [greg@kroah.com] - pci broken on PIIX/ICH laptop (CARDBUS_IO_SIZE
> too small?).
>
>
> Future stuff:
> Wow, for a subsystem that no one cared about for a long time (PCI
> Hotplug) all of a sudden we have so many patches floating around that
> it is difficult to handle all of them. If you are interested in the
> changes in this area that will be coming in 2.6.17, please see my
> quilt tree at
> http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
>
> Summary of the changes found there are:
> - shpchp driver reworks that fix issues and handle the module
> being able to be unloaded properly
> - acpiphp driver changes to try to be able to work properly for
> laptop docking stations. There is still remaining work to do
> in this area.
> - We have unstable patches to handle multi-domain PCI busses for
> i386 and x86 arches in this tree. Unfortunately they still
> seem to break NUMA and other random boxes, so they will not be
> heading for mainline any time soon. If anyone has one of
> these boxes and wishes to work on this, please let me know.
> - MSI cleanups and fixes to get things to work on ia64.
> - Other minor PCI and PCI bug fixes.
>
>
> I still have a few outstanding patches in my TODO queue that I have not
> applied to my quilt tree. These patches do the following:
> - boot parameter to disable MSI
> - various PCI quirks added
> - remove PCI_LEGACY_PROC functionality.
> - more acpiphp driver fixes.
> - kzalloc cleanup for drivers/pci
> - cpqphp driver cleanups as found by the Coverty checker.
> - other minor things.
>
> I hope to get to these by the end of the week, depending on other 2.6.16
> stabilization work. If you don't hear back from me by then, and you
> have sent me a PCI or PCI Hotplug patch, please resend it and poke me
> about it.
>
> There are no new PCI driver API changes are pending that I am aware of.
>
> Was this summary useful for people? Anything that I should add to it?
>
Could you please add "PCI legacy I/O port free driver"
(http://www.ussg.iu.edu/hypermail/linux/kernel/0603.0/1923.html)
to Future stuff? I hope the set of patches would be tested on -mm tree
for a while.
Thanks,
Kenji Kaneshige
^ permalink raw reply
* Re: Best bet for SPARC SMP and Sunfire V240
From: Josh Grebe @ 2006-03-09 3:54 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <a728f9f90603071426g547ba79at30c36e545db70f01@mail.gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
David S. Miller wrote:
>
> This fix works for me on SB2500, where I could reproduce your
> problem. Let me know how it goes. Stupid 32-bit truncation
> bug :(
Dave,
You Rock.
Thanks,
Josh
Linux v240 2.6.16-rc5-git11-sparse #6 SMP Wed Mar 8 21:49:16 CST
2006 sparc64 sun4u TI UltraSparc IIIi (Jalapeno) GNU/Linux
[ 10.209530] Memory: 2071184k available (2104k kernel code, 720k
data, 144k init) [fffff80000000000,000000103feee000]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFED6b2T/OY5rt9JCMRAvcjAKCw4gcM9Lo2Ri5a+IXqrr3CEU5qswCfaY3P
Gw+heYATfCpsGbl0GYPQZTs\x1aCA
-----END PGP SIGNATURE-----
^ permalink raw reply
* opinions on bigphysarea and DSDT-in-initrd patches
From: Ryan Underwood @ 2006-03-09 3:48 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
Hi,
I grepped through the latest ML digests and didn't see any mention of
these patches recently. I was wondering what the general opinion was on
potentially merging them. They are both hardware support patches. I
asked about the Debian kernel team maintaining them of instead
linux-kernel, but met with a lack of response there.
First is bigphysarea:
http://pv105234.reshsg.uci.edu/~jfeise/Downloads/zr36120/
This is necessary for hardware which doesn't support scatter gather DMA.
It is non invasive since it only becomes activated when the user
supplies a kernel cmdline argument. I've tested the latest version and
it works fine.
Also, I'm wondering if it is possible to include ACPI DSDT-in-initrd
patch on ACPI-supported platforms (i386, x86-64 and ia64 AFAIK).
http://gaugusch.at/kernel.shtml
This saves a user from having to rebuild the entire kernel when his
firmware DSDT either has known bugs, or he is in the process of
debugging it. In fact it would have saved me a whole lot of time this
week.
Note that this is different from the DSDT-append-to-initrd approach that
was discussed previously. I think it is a better design now, but
curious about your thoughts.
Thanks,
--
Ryan Underwood, <nemesis@icequake.net>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] Document Linux's memory barriers [try #2]
From: Paul Mackerras @ 2006-03-09 3:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: akpm, linux-arch, linux-kernel, mingo, Alan Cox, linuxppc64-dev
In-Reply-To: <Pine.LNX.4.64.0603081716400.32577@g5.osdl.org>
Linus Torvalds writes:
> x86 mmiowb would have to be a real op too if there were any multi-pathed
> PCI buses out there for x86, methinks.
Not if the manufacturers wanted to be able to run existing standard
x86 operating systems on it, surely.
I presume that on x86 the PCI host bridges and caches are all part of
the coherence domain, and that the rule about stores being observed in
order applies to what the PCI host bridge can see as much as it does
to any other agent in the coherence domain. And if I have understood
you correctly, the store ordering rule applies both to stores to
regular cacheable memory and stores to noncacheable nonprefetchable
MMIO registers without distinction.
If that is so, then I don't see how the writel's can get out of order.
Put another way, we expect spinlock regions to order stores to regular
memory, and AFAICS the x86 ordering rules mean that the same guarantee
should apply to stores to MMIO registers. (It's entirely possible
that I don't fully understand the x86 memory ordering rules, of
course. :)
> Basically, the issue boils down to one thing: no "normal" barrier will
> _ever_ show up on the bus on x86 (ie ia64, afaik). That, together with any
A spin_lock does show up on the bus, doesn't it?
> Would I want the hard-to-think-about IO ordering on a regular desktop
> platform? No.
In fact I think that mmiowb can actually be useful on PPC, if we can
be sure that all the drivers we care about will use it correctly.
If we can have the following rules:
* If you have stores to regular memory, followed by an MMIO store, and
you want the device to see the stores to regular memory at the point
where it receives the MMIO store, then you need a wmb() between the
stores to regular memory and the MMIO store.
* If you have PIO or MMIO accesses, and you need to ensure the
PIO/MMIO accesses don't get reordered with respect to PIO/MMIO
accesses on another CPU, put the accesses inside a spin-locked
region, and put a mmiowb() between the last access and the
spin_unlock.
* smp_wmb() doesn't necessarily do any ordering of MMIO accesses
vs. other accesses, and in that sense it is weaker than wmb().
... then I can remove the sync from write*, which would be nice, and
make mmiowb() be a sync. I wonder how long we're going to spend
chasing driver bugs after that, though. :)
Paul.
^ permalink raw reply
* Re: [PATCH] EDAC: core EDAC support code
From: Al Viro @ 2006-03-09 3:44 UTC (permalink / raw)
To: Dave Peterson; +Cc: Arjan van de Ven, Greg KH, Linux Kernel Mailing List
In-Reply-To: <200603081919.59763.dsp@llnl.gov>
On Wed, Mar 08, 2006 at 07:19:59PM -0800, Dave Peterson wrote:
> I'm not familiar with the internals of the module unloading code.
> However, my understanding of the discussion so far is that the kernel
> will refuse to unload a module while any of its kobjects still have
> nonzero reference counts (either by waiting for the reference counts
> to hit 0 or returning -EBUSY).
>
> If this is the case,
... the world you are living in is drastically different from the one
where the rest of us lives.
^ permalink raw reply
* two leaks in scsi_alloc_sdev failure paths
From: Dave Jones @ 2006-03-09 3:36 UTC (permalink / raw)
To: linux-scsi
If the scsi_alloc_queue or the slave_alloc calls in scsi_alloc_device fail,
we forget to release the locally allocated sdev on the failure path.
Coverity #609
Signed-off-by: Dave Jones <davej@redhat.com>
--- linux-2.6/drivers/scsi/scsi_scan.c~ 2006-03-08 22:28:50.000000000 -0500
+++ linux-2.6/drivers/scsi/scsi_scan.c 2006-03-08 22:31:38.000000000 -0500
@@ -252,7 +252,7 @@ static struct scsi_device *scsi_alloc_sd
/* release fn is set up in scsi_sysfs_device_initialise, so
* have to free and put manually here */
put_device(&starget->dev);
- goto out;
+ goto out_free;
}
sdev->request_queue->queuedata = sdev;
@@ -278,6 +278,8 @@ static struct scsi_device *scsi_alloc_sd
out_device_destroy:
transport_destroy_device(&sdev->sdev_gendev);
put_device(&sdev->sdev_gendev);
+out_free:
+ kfree(sdev);
out:
if (display_failure_msg)
printk(ALLOC_FAILURE_MSG, __FUNCTION__);
--
http://www.codemonkey.org.uk
^ permalink raw reply
* [PATCH] crypto: add alignment handling to digest layer
From: Atsushi Nemoto @ 2006-03-09 3:36 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-crypto, herbert, akpm
Some hash modules load/store data words directly. The digest layer
should pass properly aligned buffer to update()/final() method. This
patch also add cra_alignmask to some hash modules.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
digest.c | 42 +++++++++++++++++++++++++++---------------
michael_mic.c | 1 +
sha1.c | 1 +
sha256.c | 1 +
sha512.c | 2 ++
tgr192.c | 3 +++
6 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/crypto/digest.c b/crypto/digest.c
index d9b6ac9..062d0a5 100644
--- a/crypto/digest.c
+++ b/crypto/digest.c
@@ -27,6 +27,7 @@ static void update(struct crypto_tfm *tf
struct scatterlist *sg, unsigned int nsg)
{
unsigned int i;
+ unsigned int alignmask = crypto_tfm_alg_alignmask(tfm);
for (i = 0; i < nsg; i++) {
@@ -38,12 +39,24 @@ static void update(struct crypto_tfm *tf
unsigned int bytes_from_page = min(l, ((unsigned int)
(PAGE_SIZE)) -
offset);
- char *p = crypto_kmap(pg, 0) + offset;
+ char *src = crypto_kmap(pg, 0);
+ char *p = src + offset;
+ if (unlikely(offset & alignmask)) {
+ unsigned int bytes =
+ alignmask + 1 - (offset & alignmask);
+ bytes = min(bytes, bytes_from_page);
+ tfm->__crt_alg->cra_digest.dia_update
+ (crypto_tfm_ctx(tfm), p,
+ bytes);
+ p += bytes;
+ bytes_from_page -= bytes;
+ l -= bytes;
+ }
tfm->__crt_alg->cra_digest.dia_update
(crypto_tfm_ctx(tfm), p,
bytes_from_page);
- crypto_kunmap(p, 0);
+ crypto_kunmap(src, 0);
crypto_yield(tfm);
offset = 0;
pg++;
@@ -54,7 +67,15 @@ static void update(struct crypto_tfm *tf
static void final(struct crypto_tfm *tfm, u8 *out)
{
- tfm->__crt_alg->cra_digest.dia_final(crypto_tfm_ctx(tfm), out);
+ unsigned long alignmask = crypto_tfm_alg_alignmask(tfm);
+ if (unlikely((unsigned long)out & alignmask)) {
+ unsigned int size = crypto_tfm_alg_digestsize(tfm);
+ u8 buffer[size + alignmask];
+ u8 *dst = (u8 *)ALIGN((unsigned long)buffer, alignmask + 1);
+ tfm->__crt_alg->cra_digest.dia_final(crypto_tfm_ctx(tfm), dst);
+ memcpy(out, dst, size);
+ } else
+ tfm->__crt_alg->cra_digest.dia_final(crypto_tfm_ctx(tfm), out);
}
static int setkey(struct crypto_tfm *tfm, const u8 *key, unsigned int keylen)
@@ -69,18 +90,9 @@ static int setkey(struct crypto_tfm *tfm
static void digest(struct crypto_tfm *tfm,
struct scatterlist *sg, unsigned int nsg, u8 *out)
{
- unsigned int i;
-
- tfm->crt_digest.dit_init(tfm);
-
- for (i = 0; i < nsg; i++) {
- char *p = crypto_kmap(sg[i].page, 0) + sg[i].offset;
- tfm->__crt_alg->cra_digest.dia_update(crypto_tfm_ctx(tfm),
- p, sg[i].length);
- crypto_kunmap(p, 0);
- crypto_yield(tfm);
- }
- crypto_digest_final(tfm, out);
+ init(tfm);
+ update(tfm, sg, nsg);
+ final(tfm, out);
}
int crypto_init_digest_flags(struct crypto_tfm *tfm, u32 flags)
diff --git a/crypto/michael_mic.c b/crypto/michael_mic.c
index 4f6ab23..701f859 100644
--- a/crypto/michael_mic.c
+++ b/crypto/michael_mic.c
@@ -145,6 +145,7 @@ static struct crypto_alg michael_mic_alg
.cra_blocksize = 8,
.cra_ctxsize = sizeof(struct michael_mic_ctx),
.cra_module = THIS_MODULE,
+ .cra_alignmask = 3,
.cra_list = LIST_HEAD_INIT(michael_mic_alg.cra_list),
.cra_u = { .digest = {
.dia_digestsize = 8,
diff --git a/crypto/sha1.c b/crypto/sha1.c
index 21571ed..b96f57d 100644
--- a/crypto/sha1.c
+++ b/crypto/sha1.c
@@ -112,6 +112,7 @@ static struct crypto_alg alg = {
.cra_blocksize = SHA1_HMAC_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct sha1_ctx),
.cra_module = THIS_MODULE,
+ .cra_alignmask = 3,
.cra_list = LIST_HEAD_INIT(alg.cra_list),
.cra_u = { .digest = {
.dia_digestsize = SHA1_DIGEST_SIZE,
diff --git a/crypto/sha256.c b/crypto/sha256.c
index 9d5ef67..d62264a 100644
--- a/crypto/sha256.c
+++ b/crypto/sha256.c
@@ -313,6 +313,7 @@ static struct crypto_alg alg = {
.cra_blocksize = SHA256_HMAC_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct sha256_ctx),
.cra_module = THIS_MODULE,
+ .cra_alignmask = 3,
.cra_list = LIST_HEAD_INIT(alg.cra_list),
.cra_u = { .digest = {
.dia_digestsize = SHA256_DIGEST_SIZE,
diff --git a/crypto/sha512.c b/crypto/sha512.c
index 3e6e939..7dbec4f 100644
--- a/crypto/sha512.c
+++ b/crypto/sha512.c
@@ -281,6 +281,7 @@ static struct crypto_alg sha512 = {
.cra_blocksize = SHA512_HMAC_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct sha512_ctx),
.cra_module = THIS_MODULE,
+ .cra_alignmask = 3,
.cra_list = LIST_HEAD_INIT(sha512.cra_list),
.cra_u = { .digest = {
.dia_digestsize = SHA512_DIGEST_SIZE,
@@ -295,6 +296,7 @@ static struct crypto_alg sha384 = {
.cra_flags = CRYPTO_ALG_TYPE_DIGEST,
.cra_blocksize = SHA384_HMAC_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct sha512_ctx),
+ .cra_alignmask = 3,
.cra_module = THIS_MODULE,
.cra_list = LIST_HEAD_INIT(sha384.cra_list),
.cra_u = { .digest = {
diff --git a/crypto/tgr192.c b/crypto/tgr192.c
index 2d8e44f..1eae1bb 100644
--- a/crypto/tgr192.c
+++ b/crypto/tgr192.c
@@ -627,6 +627,7 @@ static struct crypto_alg tgr192 = {
.cra_blocksize = TGR192_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct tgr192_ctx),
.cra_module = THIS_MODULE,
+ .cra_alignmask = 7,
.cra_list = LIST_HEAD_INIT(tgr192.cra_list),
.cra_u = {.digest = {
.dia_digestsize = TGR192_DIGEST_SIZE,
@@ -641,6 +642,7 @@ static struct crypto_alg tgr160 = {
.cra_blocksize = TGR192_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct tgr192_ctx),
.cra_module = THIS_MODULE,
+ .cra_alignmask = 7,
.cra_list = LIST_HEAD_INIT(tgr160.cra_list),
.cra_u = {.digest = {
.dia_digestsize = TGR160_DIGEST_SIZE,
@@ -655,6 +657,7 @@ static struct crypto_alg tgr128 = {
.cra_blocksize = TGR192_BLOCK_SIZE,
.cra_ctxsize = sizeof(struct tgr192_ctx),
.cra_module = THIS_MODULE,
+ .cra_alignmask = 7,
.cra_list = LIST_HEAD_INIT(tgr128.cra_list),
.cra_u = {.digest = {
.dia_digestsize = TGR128_DIGEST_SIZE,
^ permalink raw reply related
* Kernel panic on PC with broken hard drive, after DMA errors
From: Martin Michlmayr @ 2006-03-09 3:29 UTC (permalink / raw)
To: linux-ide, linux-kernel
My laptop hard drive recently died (or is in the process of dying).
HP wanted me to do some more tests before sending me a replacement, so
I tried booting Linux again today. I got lots of DMA errors, which
was really to be expected, but then I got a kernel panic. While I'd
not blame the kernel when a panic occurs with broken RAM or CPU, I'm
sure sure the kernel should panic just because of a broken IDE drive.
I posted a picture of the panic at http://cyrius.com/tmp/ide_panic.jpg
Is this something that can be fixed or is my hardware really so broken
that the kernel cannot deal with it?
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply
* [U-Boot-Users] PPC CLKIN
From: Kumar Gala @ 2006-03-09 3:27 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20060308234955.DB4783525CB@atlas.denx.de>
On Mar 8, 2006, at 5:49 PM, Wolfgang Denk wrote:
> In message
> <1628E43D99629C46988BE46087A3FBB94B48E7@ep-01.EmbeddedPlanet.local>
> you wrote:
>> We currently have several PQII and PQIII PrPMC boards that
>> dynamically
>> support PCI bus speeds between 25 MHz and 133 MHz. These boards
>> provide
>> a CPLD register that gives PCI frequency. I would like to take
>> advantage
>> of this register, if possible, within u-boot rather than using a
>> #define
>> such as CONFIG_83XX_CLKIN, CONFIG_8260_CLKIN, or
>> CONFIG_SYS_CLK_FREQ for
>> the input clock frequency to the processor. Is there a suggested
>> method
>> of doing this?
>
> Yes: don't change the code if there is no reeal need for it.
>
>> For testing I have implemented the following in get_sys_info() in
>> speed.c for an MPC8560 board:
>>
>> #if !defined (CONFIG_SYS_CLK_FREQ)
>> sysInfo->freqSystemBus = plat_ratio * get_sys_clk();
>> #else
>> sysInfo->freqSystemBus = plat_ratio * CONFIG_SYS_CLK_FREQ;
>> #endif
>
> A simple "#define CONFIG_SYS_CLK_FREQ get_sys_clk()" seems to be
> equivalent without need to change anything. Note that I didn't check
> all uses of the CONFIG_SYS_CLK_FREQ variable in the code.
>
>> The get_sys_clk() function resides in the board code directory. Would
>> this be an acceptable method? It would minimize any impact to other
>> existing boards.
>
> What about my suggestion?
This should work. It is how the CDS platform works. Take a look at
board/cds/common/cadmus.c and include/configs/*CDS*.h
- kumar
^ permalink raw reply
* [PATCH] crypto: fix unaligned access in khazad module
From: Atsushi Nemoto @ 2006-03-09 3:26 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-crypto, herbert, akpm
On 64-bit platform, reading directly from keys (which supposed to be
32-bit aligned) will result in unaligned access.
Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp>
diff --git a/crypto/khazad.c b/crypto/khazad.c
index 807f2bf..c7e1d25 100644
--- a/crypto/khazad.c
+++ b/crypto/khazad.c
@@ -26,6 +26,7 @@
#include <asm/scatterlist.h>
#include <linux/crypto.h>
#include <linux/types.h>
+#include <asm/unaligned.h>
#define KHAZAD_KEY_SIZE 16
#define KHAZAD_BLOCK_SIZE 8
@@ -769,8 +770,8 @@ static int khazad_setkey(void *ctx_arg,
return -EINVAL;
}
- K2 = be64_to_cpu(key[0]);
- K1 = be64_to_cpu(key[1]);
+ K2 = be64_to_cpu(get_unaligned(&key[0]));
+ K1 = be64_to_cpu(get_unaligned(&key[1]));
/* setup the encrypt key */
for (r = 0; r <= KHAZAD_ROUNDS; r++) {
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.