Re: [patch] rd: support XIP

2007-12-04 Thread Duane Griffin
On 04/12/2007, Nick Piggin <[EMAIL PROTECTED]> wrote:
> +   gfp_flags = GFP_NOIO | __GFP_ZERO;
> +#ifndef CONFIG_BLK_DEV_XIP
> +   gfp_flags |= __GFP_HIGHMEM;
> +#endif
> page = alloc_page(GFP_NOIO | __GFP_HIGHMEM | __GFP_ZERO);

I think that should be alloc_page(gfp_flags), no?

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Unkillable gdb process gets system unusably slow

2007-11-23 Thread Duane Griffin
On 23/11/2007, Timo Sirainen <[EMAIL PROTECTED]> wrote:
> Fully reproducible with me. v2.6.23.1 x86-64 SMP kernel, Core 2 CPU, gdb
> v6.6.90.20070912-debian.

Fixed in 2.6.23.2, see discussion starting here:
http://marc.info/?l=linux-kernel&m=119379156819358&w=2

> gdb ./hang
> run
> fr 1
> p (char*)base
>
> p command hangs and the entire system becomes unusably slow. kill -9
> doesn't kill gdb.
>
> /* gcc hang.c -o hang -g -Wall */
> #include 
> #include 
> #include 
> #include 
> #include 
>
> int main(void)
> {
> int fd;
> char buf[100];
> void *base;
>
> fd = open("hang.tmp", O_RDWR | O_CREAT, 0600);
> if (fd == -1) perror("open");
>
> base = mmap(NULL, 100, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
> if (base == MAP_FAILED)
> perror("mmap");
> memcpy(buf, base, sizeof(buf));
> return 0;
> }

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: patch remove-broken-ptrace-special-case-code-from-file-mapping.patch queued to -stable tree

2007-11-02 Thread Duane Griffin
On 02/11/2007, Chuck Ebbert <[EMAIL PROTECTED]> wrote:
> On 11/02/2007 12:58 PM, Greg KH wrote:
> > Unless Nick really objects, and then I'll drop yours and use his, but I
> > don't think that Duane verified that his patch fixed the issue.
> >
>
> I put Nick's in Fedora, so it had better work...  ;)

I've tested both patches, and they both fix the problem. So no
worries, either way :)

As Linus said, his patch does change the behaviour. I'm not qualified
to judge how risky that is, however I think that the change is an
improvement. In fact in my original bug report I suggested the old
behaviour could be considered buggy and the new behaviour might be
preferable.

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

2007-10-31 Thread Duane Griffin
On 31/10/2007, Linus Torvalds <[EMAIL PROTECTED]> wrote:
> But I just rebooted and tested - the cleaned-up patch does seem to work
> fine, and I get "Cannot access memory at address " rather than any
> reported problem.

I can confirm the same thing here, FWIW.

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

2007-10-31 Thread Duane Griffin
On 31/10/2007, Nick Piggin <[EMAIL PROTECTED]> wrote:
> Well that's probably the best bug report I've ever had, thanks Duane!

Aw, shucks!

> The issue is a silly thinko -- I didn't pay enough attention to the ptrace
> rules in filemap_fault :( partly I think that's because I don't understand
> them and am scared of them ;)
>
> The following minimal patch fixes it here, and should probably be applied to
> 2.6.23 stable as well as 2.6.24. If you could verify it, that would be much
> appreciated.

I can confirm that it fixes the problem, thanks Nick!

Feel free to add:
Tested-by: Duane Griffin <[EMAIL PROTECTED]>

> However I actually don't really like how this all works. I don't like that
> filemap.c should have to know about ptrace, or exactly what ptrace wants here.
> It's a bit hairy to force insert page into pagecache and pte into pagetables
> here, given the races.
>
> In access_process_vm, can't we just zero fill in the case of a sigbus? Linus?
> That will also avoid changing applicatoin behaviour due to a gdb read...
>
> Thanks,
> Nick
>
> --
> Duane Griffin noticed a 2.6.23 regression that will cause gdb to hang when
> it tries to access the memory of another process beyond i_size.
>
> This is because the solution to the fault vs invalidate race requires that
> we recheck i_size after the page lock is taken. However in that case, I
> had not accounted for the fact that ptracers are granted an exception to this
> rule.
>
> Cc: Duane Griffin <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED]
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]
> ---
> Index: linux-2.6/mm/filemap.c
> ===
> --- linux-2.6.orig/mm/filemap.c
> +++ linux-2.6/mm/filemap.c
> @@ -1374,7 +1374,7 @@ retry_find:
>
> /* Must recheck i_size under page lock */
> size = (i_size_read(inode) + PAGE_CACHE_SIZE - 1) >> PAGE_CACHE_SHIFT;
> -   if (unlikely(vmf->pgoff >= size)) {
> +   if (unlikely(vmf->pgoff >= size) && vma->vm_mm == current->mm) {
> unlock_page(page);
> page_cache_release(page);
> goto outside_data_content;
>

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


2.6.23 regression: accessing invalid mmap'ed memory from gdb causes unkillable spinning

2007-10-30 Thread Duane Griffin
Accessing a memory mapped region past the last page containing a valid
file mapping produces a SIGBUS fault (as it should). Running a program
that does this under gdb, then accessing the invalid memory from gdb,
causes it to start consuming 100% CPU and become unkillable. Once in
that state, SysRq-T doesn't show a stack trace for gdb, although it is
shown as running and stack traces are dumped for other tasks.

2.6.22 does not have this bug (gdb just prints '\0' as the contents,
although arguably that is also a bug, and it should instead report the
SIGBUS).

Bisection indicates the problem was introduced by:

54cb8821de07f2ffcd28c380ce9b93d5784b40d7
"mm: merge populate and nopage into fault (fixes nonlinear)"

The following program demonstrates the issue:

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

int main(int argc, char *argv[])
{
int fd;
struct stat buf;

if (argc != 2) {
fprintf(stderr, "usage: %s \n", argv[0]);
exit(1);
}

fd = open(argv[1], O_RDONLY);
fstat(fd, &buf);
int count = buf.st_size + sysconf(_SC_PAGE_SIZE);
char *file = (char *) mmap(NULL, count, PROT_READ, MAP_PRIVATE, fd, 0);
if (file == MAP_FAILED) {
fprintf(stderr, "mmap failed: %s\n", strerror(errno));
} else {
char ch;
fprintf(stderr, "using offset %d\n", (count - 1));
ch = file[count - 1];
munmap(file, count);
}
close(fd);
return 0;
}

To reproduce the bug, run it under gdb, go up a couple of frames to
the main function, then access invalid memory, for e.g. with: "print
file[4095]", or whatever offset was reported.

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH V2] dir_index: error out instead of BUG on corrupt dx dirs

2007-09-10 Thread Duane Griffin
On 10/09/2007, Eric Sandeen <[EMAIL PROTECTED]> wrote:
> I don't know if it's worth differentiating messages for different types
> of corruption (root block vs. others, etc...) - I guess the other error
> cases do.

Might be useful for a developer wanting to know exactly which error
check was triggering. Unlikely to be of much interest or use to the
user, so I wouldn't worry too much about the exact wording.

> Here's a patch rolling up yours with mine + discussed changes, and
> consolidating the fsck suggestion message.
>
> How's it look to you?  Suppose I'd better run this a bit to be sure it's
> not hitting any common cases and issuing new warnings...?

The warnings shouldn't include explicit newlines, aside from that it
looks good to me. I've tested it with the corruption utility and all
combinations (count & limit, root & indirect) seem to work correctly.

> Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>

Acked-by: Duane Griffin <[EMAIL PROTECTED]>

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RESEND][PATCH] dir_index: error out instead of BUG on corrupt hash dir limit

2007-09-10 Thread Duane Griffin
On 10/09/2007, Eric Sandeen <[EMAIL PROTECTED]> wrote:
> Duane Griffin wrote:
> > Sorry I missed this first time around. I came up with a very similar
> > fix recently, following a gentoo bug report.  However there are a few
> > more asserts later that you aren't currently handling. Below is an
> > incremental patch on top of yours that converts them too.
>
> Ah, good point... I focused a bit too much on the single problem at hand
> didn't I.  :)

Easy to do :)

> > Note that one
> > of them is in an if (0) block and maybe should be left alone -- what do
> > you think?
>
> If it's just there for debug, maybe leaving an assert is ok, to get a
> dump & system state etc.  If it is converted, a printk would probably be
> good so you know you're falling back, otherwise that extra checking is a
> bit pointless if it's silent.

Good point. Perhaps best to just back that part out.

> I wonder if
> we should fix up all the new error condition printk's a bit to be more
> descriptive of the problem at hand; for example, the one I sent should
> maybe say:
>
> +   ext3_warning(dir->i_sb, __FUNCTION__,
> +"Corrupt root limit in dir inode %ld\n", 
> dir->i_ino);
>
> I wanted to leave the word "corrupt" in there, or at least something to
> clue in the user that maybe fsck is in order...

I struggled with the wording, too. I originally went with "Invalid dx
limit/count", but wasn't terribly happy with it. "Corrupt" is more
accurate and informative. Perhaps the warning should also explicitly
recommend running fsck:

"Corrupt root limit in dir inode %ld, running e2fsck is recommended\n"

Cheers,
Duane.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RESEND][PATCH] dir_index: error out instead of BUG on corrupt hash dir limit

2007-09-09 Thread Duane Griffin
Hi Eric,

On Fri, Aug 31, 2007 at 09:48:43PM -0500, Eric Sandeen wrote:
> (resend, this one got lost?  Got an acked-by from Andreas
> last go-round)

Sorry I missed this first time around. I came up with a very similar
fix recently, following a gentoo bug report.  However there are a few
more asserts later that you aren't currently handling. Below is an
incremental patch on top of yours that converts them too. Note that one
of them is in an if (0) block and maybe should be left alone -- what do
you think?

I tested all the changed code paths, except the if (0) one, using a
utility that appropriately corrupts ext3 images. The source code is
attached to the gentoo bug report here:

http://bugs.gentoo.org/show_bug.cgi?id=183207

Signed-off-by: Duane Griffin <[EMAIL PROTECTED]>

Index: linux-2.6-git/fs/ext3/namei.c
===
--- linux-2.6-git.orig/fs/ext3/namei.c
+++ linux-2.6-git/fs/ext3/namei.c
@@ -393,7 +393,15 @@ dx_probe(struct dentry *dentry, struct i
while (1)
{
count = dx_get_count(entries);
-   assert (count && count <= dx_get_limit(entries));
+   if (!count || count > dx_get_limit(entries)) {
+   ext3_warning(dir->i_sb, __FUNCTION__,
+"Corrupt limit in dir inode %ld\n",
+dir->i_ino);
+   brelse(bh);
+   *err = ERR_BAD_DX_DIR;
+   goto fail2;
+   }
+
p = entries + 1;
q = entries + count - 1;
while (p <= q)
@@ -419,7 +427,11 @@ dx_probe(struct dentry *dentry, struct i
break;
}
}
-   assert (at == p - 1);
+   if (at != p - 1) {
+   brelse(bh);
+   *err = ERR_BAD_DX_DIR;
+   goto fail2;
+   }
}
 
at = p - 1;
@@ -431,8 +443,16 @@ dx_probe(struct dentry *dentry, struct i
if (!(bh = ext3_bread (NULL,dir, dx_get_block(at), 0, err)))
goto fail2;
at = entries = ((struct dx_node *) bh->b_data)->entries;
-   assert (dx_get_limit(entries) == dx_node_limit (dir));
+   if (dx_get_limit(entries) != dx_node_limit (dir)) {
+   ext3_warning(dir->i_sb, __FUNCTION__,
+"Corrupt limit in dir inode %ld\n",
+dir->i_ino);
+   brelse(bh);
+   *err = ERR_BAD_DX_DIR;
+   goto fail2;
+   }
frame++;
+   frame->bh = NULL;
}
 fail2:
while (frame >= frame_in) {
Index: linux-2.6-git/fs/ext4/namei.c
===
--- linux-2.6-git.orig/fs/ext4/namei.c
+++ linux-2.6-git/fs/ext4/namei.c
@@ -393,7 +393,15 @@ dx_probe(struct dentry *dentry, struct i
while (1)
{
count = dx_get_count(entries);
-   assert (count && count <= dx_get_limit(entries));
+   if (!count || count > dx_get_limit(entries)) {
+   ext3_warning(dir->i_sb, __FUNCTION__,
+"Corrupt limit in dir inode %ld\n",
+dir->i_ino);
+   brelse(bh);
+   *err = ERR_BAD_DX_DIR;
+   goto fail2;
+   }
+
p = entries + 1;
q = entries + count - 1;
while (p <= q)
@@ -419,7 +427,11 @@ dx_probe(struct dentry *dentry, struct i
break;
}
}
-   assert (at == p - 1);
+   if (at != p - 1) {
+   brelse(bh);
+   *err = ERR_BAD_DX_DIR;
+   goto fail2;
+   }
}
 
at = p - 1;
@@ -431,8 +443,16 @@ dx_probe(struct dentry *dentry, struct i
if (!(bh = ext4_bread (NULL,dir, dx_get_block(at), 0, err)))
goto fail2;
at = entries = ((struct dx_node *) bh->b_data)->entries;
-   assert (dx_get_limit(entries) == dx_node_limit (dir));
+   if (dx_get_limit(entries) != dx_node_limit (dir)) {
+   ext3_warning(dir->i_sb, __FUNCTION__,
+"Corrupt limit in dir inode %ld\n",
+

Re: [PATCH v2 -mm 8/9] netconsole: Support multiple logging targets

2007-07-10 Thread Duane Griffin

On 10/07/07, Satyam Sharma <[EMAIL PROTECTED]> wrote:

+   /* Avoid taking lock and disabling interrupts unnecessarily */
+   if (unlikely(list_empty(&target_list)))
+   return;


Is the unlikely a good idea here? Not having any targets may be
unusual but it isn't ridiculous. It might even be a sensible default
for distros. My (very limited) understanding of unlikely is that it
could impose a very large penalty in that case and would make a very
marginal difference at best in the common case.

Cheers,
Duane.

--
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch 1/2] HFS+: Refactor ASCII to unicode conversion routine for later reuse

2007-06-26 Thread Duane Griffin

On 25/06/07, Roman Zippel <[EMAIL PROTECTED]> wrote:


I like the idea of this, but not that it generates larger code, so I
reformatted it a little to get rid of the decomposed_uc struct which
required an unnecessary data copy, so now the it even generates slightly
smaller code. :)


Ah, nice one! Returning the pointer into the table is a much nicer way
of doing things.


+   if (decompose && (dstr = decompose_unichar(c, &dsize))) {
+   if (outlen + dsize > HFSPLUS_MAX_STRLEN)
break;
do {
-   ustr->unicode[outlen++] = 
cpu_to_be16(hfsplus_decompose_table[off++]);
-   } while (--size > 0);
-   continue;
-   }
-   done:
-   ustr->unicode[outlen++] = cpu_to_be16(c);
+   ustr->unicode[outlen++] = cpu_to_be16(*dstr++);
+   } while (--dsize > 0);


Andrew's comments about the loop in the second patch apply here too, I
think. The original code did have a check for this condition, so I
guess it is a potential problem. How about this (on top of your
version of the patches):

Index: linux-2.6.21.5/fs/hfsplus/unicode.c
===
--- linux-2.6.21.5.orig/fs/hfsplus/unicode.c
+++ linux-2.6.21.5/fs/hfsplus/unicode.c
@@ -280,7 +280,9 @@ static inline u16 *decompose_unichar(wch
   return NULL;

   off = hfsplus_decompose_table[off + (uc & 0xf)];
-   *size = off & 3;
+   if ((*size = off & 3) == 0)
+   return NULL;
+
   return hfsplus_decompose_table + (off / 4);
}

I'm using gmail to send this, so it will mess up the tabs I'm afraid :(


bye, Roman


Cheers,
Duane.

--
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[patch 0/2] HFS+: custom dentry hash and comparison operations

2007-06-19 Thread Duane Griffin
The HFS+ filesystem is case-insensitive and does automatic unicode
decomposition by default, but does not provide custom dentry
operations. This can lead to multiple dentries being cached for lookups
on a filename with varying case and/or character (de)composition.

These patches add custom dentry hash and comparison operations for
case-sensitive and/or automatically decomposing HFS+ filesystems.
Unicode decomposition and case-folding are performed as required to
ensure equivalent filenames are hashed to the same values and compare
as equal.

Tested on i386, x86_64 and PPC.

See bug reports here for more information:
http://bugzilla.kernel.org/show_bug.cgi?id=7240
http://bugs.gentoo.org/show_bug.cgi?id=178298

Cheers,
Duane Griffin.

-- 
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[patch 1/2] HFS+: Refactor ASCII to unicode conversion routine for later reuse

2007-06-19 Thread Duane Griffin
Refactor existing HFS+ ASCII to unicode string conversion routine to
split out character conversion functionality. This will be reused by
the custom dentry hash and comparison routines. This approach avoids
unnecessary memory allocation compared to using the string conversion
routine directly in the new functions.

Signed-off-by: Duane Griffin <[EMAIL PROTECTED]>
---

--- linux-2.6.21.orig/fs/hfsplus/unicode.c
+++ linux-2.6.21/fs/hfsplus/unicode.c
@@ -239,58 +239,97 @@ out:
return res;
 }
 
-int hfsplus_asc2uni(struct super_block *sb, struct hfsplus_unistr *ustr, const 
char *astr, int len)
+/*
+ * Convert one or more ASCII characters into a single unicode character.
+ * Returns the number of ASCII characters corresponding to the unicode char.
+ */
+static
+int asc2uc(struct super_block *sb, const char *astr, int len, wchar_t *uc)
 {
-   struct nls_table *nls = HFSPLUS_SB(sb).nls;
-   int size, off, decompose;
-   wchar_t c;
-   u16 outlen = 0;
+   int size = HFSPLUS_SB(sb).nls->char2uni(astr, len, uc);
+   if (size <= 0) {
+   *uc = '?';
+   size = 1;
+   }
+   switch (*uc) {
+   case 0x2400:
+   *uc = 0;
+   break;
+   case ':':
+   *uc = '/';
+   break;
+   }
+   return size;
+}
+
+struct decomposed_uc {
+   int size;
+   wchar_t str[3];
+};
+
+/* Decomposes a single unicode character. */
+static void decompose_uc(wchar_t uc, struct decomposed_uc *duc)
+{
+   int off, ii;
 
-   decompose = !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE);
+   duc->size = 1;
+   duc->str[0] = uc;
+
+   off = hfsplus_decompose_table[(uc >> 12) & 0xf];
+   if (off == 0 || off == 0x)
+   return;
+
+   off = hfsplus_decompose_table[off + ((uc >> 8) & 0xf)];
+   if (!off)
+   return;
+
+   off = hfsplus_decompose_table[off + ((uc >> 4) & 0xf)];
+   if (!off)
+   return;
+
+   off = hfsplus_decompose_table[off + (uc & 0xf)];
+
+   duc->size = off & 3;
+   off /= 4;
+   for (ii = 0; ii < duc->size; ++ii)
+   duc->str[ii] = hfsplus_decompose_table[off++];
+}
+
+/*
+ * Convert a ASCII character(s) to a unicode character.
+ * The unicode character will be decomposed, if required.
+ * Returns the number of ASCII characters converted.
+ */
+static int asc2ucd(struct super_block *sb,
+   const char *astr, int len, struct decomposed_uc *duc)
+{
+   int size = asc2uc(sb, astr, len, duc->str);
+   bool decompose = !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE);
+
+   if (decompose && *duc->str >= 0xc0)
+   decompose_uc(*duc->str, duc);
+   else
+   duc->size = 1;
+
+   return size;
+}
+
+int hfsplus_asc2uni(struct super_block *sb,
+   struct hfsplus_unistr *ustr, const char *astr, int len)
+{
+   u16 outlen = 0;
+   struct decomposed_uc duc;
 
while (outlen < HFSPLUS_MAX_STRLEN && len > 0) {
-   size = nls->char2uni(astr, len, &c);
-   if (size <= 0) {
-   c = '?';
-   size = 1;
-   }
+   int ii;
+   int size = asc2ucd(sb, astr, len, &duc);
+   if (outlen + duc.size > HFSPLUS_MAX_STRLEN)
+   break;
+
astr += size;
len -= size;
-   switch (c) {
-   case 0x2400:
-   c = 0;
-   break;
-   case ':':
-   c = '/';
-   break;
-   }
-   if (c >= 0xc0 && decompose) {
-   off = hfsplus_decompose_table[(c >> 12) & 0xf];
-   if (!off)
-   goto done;
-   if (off == 0x) {
-   goto done;
-   }
-   off = hfsplus_decompose_table[off + ((c >> 8) & 0xf)];
-   if (!off)
-   goto done;
-   off = hfsplus_decompose_table[off + ((c >> 4) & 0xf)];
-   if (!off)
-   goto done;
-   off = hfsplus_decompose_table[off + (c & 0xf)];
-   size = off & 3;
-   if (!size)
-   goto done;
-   off /= 4;
-   if (outlen + size > HFSPLUS_MAX_STRLEN)
-   break;
-   do {
-   ustr->unicode[outlen++] = 
cpu_to_be16(hfsplus_decompose_table[off++]);
-   

[patch 2/2] HFS+: Add custom dentry hash and comparison operations

2007-06-19 Thread Duane Griffin
Add custom dentry hash and comparison operations for HFS+ filesystems
that are case-insensitive and/or do automatic unicode decomposition.
The new operations reuse the existing HFS+ ASCII to unicode conversion,
unicode decomposition and case folding functionality.

Signed-off-by: Duane Griffin <[EMAIL PROTECTED]>
---

--- linux-2.6.21.orig/fs/hfsplus/dir.c
+++ linux-2.6.21/fs/hfsplus/dir.c
@@ -36,6 +36,11 @@ static struct dentry *hfsplus_lookup(str
u16 type;
 
sb = dir->i_sb;
+
+   if (!(HFSPLUS_SB(sb).flags & HFSPLUS_SB_HFSX) ||
+   !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE))
+   dentry->d_op = &hfsplus_dentry_operations;
+
dentry->d_fsdata = NULL;
hfs_find_init(HFSPLUS_SB(sb).cat_tree, &fd);
hfsplus_cat_build_key(sb, fd.search_key, dir->i_ino, &dentry->d_name);
--- linux-2.6.21.orig/fs/hfsplus/hfsplus_fs.h
+++ linux-2.6.21/fs/hfsplus/hfsplus_fs.h
@@ -321,6 +321,7 @@ void hfsplus_file_truncate(struct inode 
 /* inode.c */
 extern const struct address_space_operations hfsplus_aops;
 extern const struct address_space_operations hfsplus_btree_aops;
+extern struct dentry_operations hfsplus_dentry_operations;
 
 void hfsplus_inode_read_fork(struct inode *, struct hfsplus_fork_raw *);
 void hfsplus_inode_write_fork(struct inode *, struct hfsplus_fork_raw *);
@@ -353,6 +354,8 @@ int hfsplus_strcasecmp(const struct hfsp
 int hfsplus_strcmp(const struct hfsplus_unistr *, const struct hfsplus_unistr 
*);
 int hfsplus_uni2asc(struct super_block *, const struct hfsplus_unistr *, char 
*, int *);
 int hfsplus_asc2uni(struct super_block *, struct hfsplus_unistr *, const char 
*, int);
+int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str);
+int hfsplus_compare_dentry(struct dentry *dentry, struct qstr *s1, struct qstr 
*s2);
 
 /* wrapper.c */
 int hfsplus_read_wrapper(struct super_block *);
--- linux-2.6.21.orig/fs/hfsplus/inode.c
+++ linux-2.6.21/fs/hfsplus/inode.c
@@ -130,6 +130,12 @@ const struct address_space_operations hf
.writepages = hfsplus_writepages,
 };
 
+struct dentry_operations hfsplus_dentry_operations = {
+   .d_revalidate = NULL,
+   .d_hash   = hfsplus_hash_dentry,
+   .d_compare= hfsplus_compare_dentry,
+};
+
 static struct dentry *hfsplus_file_lookup(struct inode *dir, struct dentry 
*dentry,
  struct nameidata *nd)
 {
--- linux-2.6.21.orig/fs/hfsplus/super.c
+++ linux-2.6.21/fs/hfsplus/super.c
@@ -396,6 +396,10 @@ static int hfsplus_fill_super(struct sup
} else
hfs_find_exit(&fd);
 
+   if (!(HFSPLUS_SB(sb).flags & HFSPLUS_SB_HFSX) ||
+   !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_NODECOMPOSE))
+   sb->s_root->d_op = &hfsplus_dentry_operations;
+
if (sb->s_flags & MS_RDONLY)
goto out;
 
--- linux-2.6.21.orig/fs/hfsplus/unicode.c
+++ linux-2.6.21/fs/hfsplus/unicode.c
@@ -314,6 +314,22 @@ static int asc2ucd(struct super_block *s
return size;
 }
 
+/*
+ * Convert a ASCII character(s) to a unicode character.
+ * The unicode character will be decomposed and/or case-folded, if required.
+ * Returns the number of ASCII characters converted.
+ */
+static int asc2ucdf(struct super_block *sb,
+   const char *astr, int len, struct decomposed_uc *duc)
+{
+   int ii;
+   int size = asc2ucd(sb, astr, len, duc);
+   bool fold = !(HFSPLUS_SB(sb).flags & HFSPLUS_SB_HFSX);
+   for (ii = 0; fold && ii <= duc->size; ++ii)
+   duc->str[ii] = case_fold(duc->str[ii]);
+   return size;
+}
+
 int hfsplus_asc2uni(struct super_block *sb,
struct hfsplus_unistr *ustr, const char *astr, int len)
 {
@@ -336,3 +352,89 @@ int hfsplus_asc2uni(struct super_block *
return -ENAMETOOLONG;
return 0;
 }
+
+/*
+ * Hash a string to an integer as appropriate for the HFS+ filesystem.
+ * Composed unicode characters are decomposed and case-folding is performed
+ * if the appropriate bits are (un)set on the superblock.
+ */
+int hfsplus_hash_dentry(struct dentry *dentry, struct qstr *str)
+{
+   int len = str->len;
+   const char *astr = str->name;
+   struct decomposed_uc duc;
+   unsigned hash = init_name_hash();
+
+   while (len > 0) {
+   int ii;
+   int size = asc2ucdf(dentry->d_sb, astr, len, &duc);
+   astr += size;
+   len -= size;
+   for (ii = 0; ii < duc.size; ++ii) {
+   if (duc.str[ii])
+   hash = partial_name_hash(duc.str[ii], hash);
+   }
+   }
+   str->hash = end_name_hash(hash);
+
+   return 0;
+}
+
+/*
+ * Compare strings with HFS+ filename ordering.
+ * Composed unicode characters are decomposed and case-folding is performed
+ * if the appropriate bits are 

Re: 2.6.22-rc3 hibernate(?) fails totally - regression (xfs on raid6)

2007-06-07 Thread Duane Griffin

On 07/06/07, David Greaves <[EMAIL PROTECTED]> wrote:

> How hard does the machine freeze?  Can you use sysrq?  If so, please
> dump sysrq-t.
I suspect there is a problem writing to the consoles...

I recompiled (rc4+patch) with sysrq support, suspended, resumed and tried
sysrq-t but got no output.

I *can* change VTs and see the various login prompts, bitmap messages and the
console messages. Caps/Num lock lights work.

Fearing incompetence I tried sysrq-s sysrq-u sysrq-b and got a reboot so sysrq
is OK.


Try sysrq-9 before the sysrq-t. Probably the messages are not being
printed to console with your default output level.

Cheers,
Duane Griffin.

--
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Kconfig powernow-k8 driver should depend on ACPI P-States driver

2007-05-16 Thread Duane Griffin

On 16/05/07, Prakash Punnoor <[EMAIL PROTECTED]> wrote:

Maybe you want to give a hint in the p states driver help text?


I think a hint is the right thing to do, but in the PowerNow! driver
rather than the p states one. How about adding something like this to
the X86_POWERNOW_K8 (and X86_POWERNOW_K7?) help text:

"ACPI support is required for non-UP systems and requires ACPI_PROCESSOR
to be selected. If ACPI_PROCESSOR is compiled as a module then this
option must be too in order for ACPI support to be available."

Cheers,
Duane.

--
"I never could learn to drink that blood and call it wine" - Bob Dylan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/