Peter Huewe wrote:
> +static char old_keypad_profile[][4][9] = {
> {"S0", "Left\n", "Left\n", ""},
> {"S1", "Down\n", "Down\n", ""},
> {"S2", "Up\n", "Up\n", ""},
Things like this should likely be const also. There are several here.
> -void panel_lcd_print(char *s)
> +static
Hi Dave,
Can you pull wimax as well?
Sorry about this, but it seems like the majority of the non-arch trees need to
go through the networking tree.
Perez-Gonzalez, Inaky wrote:
> > From: David Howells [mailto:dhowe...@redhat.com]
> >
> > Can you merge the following bra
Stephen Rothwell wrote:
> I just removed epapr_hcalls.h from the Kbuild file as I am not sure how
> it should be broken up. David, can you have a look at this, please?
Files should be broken up along around __KERNEL__ conditionals. If there are
no __KERNEL__ conditionals, it is assumed that th
Tabi Timur-B04825 wrote:
> What is include/uapi?
Take a look at http://lwn.net/Articles/507794/
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
Mauro Carvalho Chehab wrote:
> My understanding here is that, as the file location will change
> with this series, your original concern is now void, as userspace
> will require patches to use the new location. So, if we're willing
> to do it, let's put this one-driver-only obsolete API on a sepa
Alexander Graf wrote:
> Do I have to move them to their own header file or can I just #ifdef
> __KERNEL__ around the place where __ASSEMBLY__ starts to the end of the
> file?
That depends on whether it happens before or after my disintegration script is
run on the header. Ben has pulled my powe
Catalin Marinas wrote:
> The asm/Kbuild allows automatic generation of header files by specifying
> "generic-y += ...". The first patch in the series allows the same thing
> to be specified in uapi/asm/Kbuild.
>
> The subsequent patches remove some of the trivial header files in arm64,
> s390 an
Geert Uytterhoeven wrote:
> This leaves the following empty construct:
>
> #ifdef CONFIG_COLDFIRE
> #else
> #endif
Odd. It emitted it in both headers, which it shouldn't have.
> I'll remove it in a subsequent patch.
Thanks.
David
--
To unsubscribe from this list: send the line "
Grant Likely wrote:
> > Can you merge the following branch into the spi tree please.
>
> Do you want this merged into 3.7? If so, go ahead and push it directly
> to Linus. I've not been able to do any maintainership stuff for the
> last merge window or this one. Mark Brown has covered for me on
Unexport part of linux/ppp-comp.h as userspace can't make use of that bit.
Signed-off-by: David Howells
cc: Paul Mackerras
cc: David Miller
---
include/linux/ppp-comp.h |4
1 file changed, 4 insertions(+)
diff --git a/include/linux/ppp-comp.h b/include/linux/ppp-comp.h
It seems that was linux/blk_types.h incorrectly exported to fix up some missing
bits required by the exported parts of linux/fs.h (READ, WRITE, READA, etc.).
So unexport linux/blk_types.h and unexport the relevant bits of linux/fs.h.
Signed-off-by: David Howells
cc: Jens Axboe
cc: Tejun Heo
It seems that was linux/blk_types.h incorrectly exported to fix up some missing
bits required by the exported parts of linux/fs.h (READ, WRITE, READA, etc.).
So unexport linux/blk_types.h and unexport the relevant bits of linux/fs.h.
Signed-off-by: David Howells
cc: Jens Axboe
cc: Tejun Heo
userspace interface stuff, and:
include/linux/.../foo.h
for the strictly kernel internal stuff.
Signed-off-by: David Howells
Acked-by: Grant Likely
---
The following changes since commit 9e2d8656f5e8aa214e66b462680cf86b210b74a8:
Merge branch 'akpm' (Andrew's patch-bo
tegrate include/linux/byteorder/*.h as a unit.
Signed-off-by: David Howells
---
The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4:
Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security
(2012-10-13 11:29:00 +0900)
Linus Torvalds wrote:
> Hmm. So this thing makes me wonder:
>
> /* Not having a signature is only an error if we're strict. */
> if (err < 0 && fips_enabled)
> panic("Module verification failed with error %d in FIPS
> mode\n",
> err);
>
> d
Linus Torvalds wrote:
> In the meantime, please fix the fact that "tools/perf" broke.
Hmmm... I assumed that would've been built by allyesconfig... Apparently not.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
Ingo Molnar wrote:
> Arnaldo: the way we include some of the include files directly
> into tools/perf/ .c files [such as hw_breakpoint.h] and
> represent others transparently via utils/include/ [such as
> rbtree.h] is a bit messy and ought to be cleaned up I suspect.
I tried to make the USERI
Andi Kleen wrote:
> Does this fix it? -Andi
Works for me. I've added it to my FRV fixup patches.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.
doesn't matter which way round they're
packed from that point of view.
Signed-off-by: David Howells
cc: Al Viro
---
arch/frv/kernel/entry.S |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/frv/kernel/entry.S b/arch/frv/kernel/entry.S
index 0027329..ee0b
er is
reported only once
arch/frv/kernel/process.c:197: error: for each function it appears in.)
m
Signed-off-by: David Howells
cc: Al Viro
---
arch/frv/kernel/process.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/frv/kernel/process.c b/arch/frv/kernel/pro
ult/7344691/
Reported-by: Geert Uytterhoeven
Signed-off-by: Andi Kleen
Signed-off-by: David Howells
cc: Geert Uytterhoeven
---
arch/frv/kernel/setup.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
index 1f1e5ef..b8993c8 100644
--- a
incorrectly guarded bits back to the kernelspace header.
Whilst we're at it, the __KERNEL__ guards can be deleted as they're no longer
necessary.
Reported-by: Fengguang Wu
Reported-by: Lars-Peter Clausen
Signed-off-by: David Howells
cc: Fengguang Wu
cc: Lars-Peter Clausen
c
Valdis Kletnieks wrote:
> /bin/sh: -c: line 0: syntax error near unexpected token `;'
> /bin/sh: -c: line 0: `set -e; ; echo
> 'cmd_/usr/src/valdis/NVIDIA-Linux-x86_64-304.51/kernel/nvidia.ko := ' >
> /usr/src/valdis/NVIDIA-Linux-x86_64-304.51/kernel/.nvidia.ko.cmd'
I would guess that this is
Lars-Peter Clausen wrote:
> The second part of the patch adding it back to include/linux/elf-fdpic.h
> seems to be missing.
Oops. Yes. I forgot to 'stg add' it.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
doesn't matter which way round they're
packed from that point of view.
Signed-off-by: David Howells
cc: Al Viro
---
arch/frv/kernel/entry.S |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/frv/kernel/entry.S b/arch/frv/kernel/entry.S
index 0027329..ee0b
er is
reported only once
arch/frv/kernel/process.c:197: error: for each function it appears in.)
m
Signed-off-by: David Howells
cc: Al Viro
---
arch/frv/kernel/process.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/frv/kernel/process.c b/arch/frv/kernel/pro
ult/7344691/
Reported-by: Geert Uytterhoeven
Signed-off-by: Andi Kleen
Signed-off-by: David Howells
cc: Geert Uytterhoeven
---
arch/frv/kernel/setup.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
index 1f1e5ef..b8993c8 100644
--- a
incorrectly guarded bits back to the kernelspace header.
Whilst we're at it, the __KERNEL__ guards can be deleted as they're no longer
necessary.
Reported-by: Fengguang Wu
Reported-by: Lars-Peter Clausen
Signed-off-by: David Howells
cc: Fengguang Wu
cc: Lars-Peter Clausen
c
Randy Dunlap wrote:
> Building um (uml) for x86_64 (defconfig) has lots of errors like:
>
> In file included from include/linux/irq.h:22:0,
> from include/asm-generic/hardirq.h:12,
> from arch/um/include/generated/asm/hardirq.h:1,
> from include
linux/coredump.h should #include asm/siginfo.h for the siginfo_t type.
Without this the following error occurs when compiling UM defconfig:
include/linux/coredump.h:15:25: error: unknown type name 'siginfo_t'
Signed-off-by: David Howells
---
include/linux/coredump.h |1
Hi Randy,
Randy Dunlap wrote:
> Building um (uml) for x86_64 (defconfig) has lots of errors like:
>
> In file included from include/linux/irq.h:22:0,
> from include/asm-generic/hardirq.h:12,
> from arch/um/include/generated/asm/hardirq.h:1,
>
error when building x86_64 or usermode Linux (and probably
others):
include/linux/irqnr.h:4:30: fatal error: uapi/linux/irqnr.h: No such file or
directory
Signed-off-by: David Howells
cc: Randy Dunlap
cc: Alessandro Suardi
---
include/uapi/linux/irqnr.h |4
1 file changed, 4 inserti
Stanislav Kinsbursky wrote:
> +CFLAGS += -I../../../../arch/x86/include/generated/
> +CFLAGS += -I../../../../include/
> +CFLAGS += -I../../../../usr/include/
> +CFLAGS += -I../../../../arch/x86/include/
Do you need to add uapi/ into some of these?
David
--
To unsubscribe from this list: send t
doesn't matter which way round they're
packed from that point of view.
Signed-off-by: David Howells
Acked-by: Al Viro
---
arch/frv/kernel/entry.S |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/frv/kernel/entry.S b/arch/frv/kernel/entry.S
index 002732
ult/7344691/
Reported-by: Geert Uytterhoeven
Signed-off-by: Andi Kleen
Signed-off-by: David Howells
cc: Geert Uytterhoeven
---
arch/frv/kernel/setup.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/frv/kernel/setup.c b/arch/frv/kernel/setup.c
index 1f1e5ef..b8993c8 100644
--- a
incorrectly guarded bits back to the kernelspace header.
Whilst we're at it, the __KERNEL__ guards can be deleted as they're no longer
necessary.
Reported-by: Fengguang Wu
Reported-by: Lars-Peter Clausen
Signed-off-by: David Howells
cc: Fengguang Wu
cc: Lars-Peter Clausen
c
er is
reported only once
arch/frv/kernel/process.c:197: error: for each function it appears in.)
m
Reported-by: Geert Uytterhoeven
Signed-off-by: David Howells
Acked-by: Al Viro
cc: Geert Uytterhoeven
---
arch/frv/kernel/process.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
David Sharp wrote:
> > Please use the Kbuild infrastructure ("generic-y += ..." in
> > arch/*/include/asm/Kbuild)
> > instead of adding wrappers around the asm-generic version.
>
> mips apparently recencly got rid of arch/mips/include/asm/Kbuild.
It didn't. However, if you use patch to create
James Bottomley wrote:
> I'm getting a fairly massive merge failure over our misc tree:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/jejb/parisc-2.0 misc
>
> It looks like a conflict with the motion to using wrappered Kbuild for
> our asm-generic clones.
I can try merging your branch in a
UAPI Disintegration 2012-10-16
--------
David Howells (2):
Merge branch 'misc' of git://git.kernel.org/.../jejb/parisc-2.6.git/
UAPI: (Scripted) Disintegrate arch/parisc/include/asm
James Bottomley (1):
[PARI
Luis R. Rodriguez wrote:
> >> The include_next trick can work as well but that'd mean synching the UAPI
> >> files regularly into compat. I'd much prefer to have code intact when
> >> possible when backporting so the option I stuck with then was to patch
> >> the code directly and then as part of
161.
Found = in conditional, should be == at scripts/sign-file line 159.
This patch change replace '=' by '==' in elsif conditions for avoid the above
warning messages.
Signed-off-by: Chun-Yi Lee
Signed-off-by: David Howells
---
scripts/sign-file |6 +++---
1 file c
David Howells wrote:
> There have the following warning message when running modules install for
> sign ko files:
>
> # make modules_install
> ...
> INSTALL drivers/input/touchscreen/pcap_ts.ko
> Found = in conditional, should be == at scripts/sign-file line 164.
>
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
Acked-by: Thomas Gleixner
Acked-by: Michael Kerrisk
Acked-by: Paul E. McKenney
Acked-by: Dave Jones
---
include/scsi/Kbuild |3 ---
include/uapi/scsi/Kbuild|3 +++
include/uapi/scsi/scsi_bsg_fc.h
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
Acked-by: Thomas Gleixner
Acked-by: Michael Kerrisk
Acked-by: Paul E. McKenney
Acked-by: Dave Jones
---
include/scsi/fc/Kbuild|4
include/uapi/scsi/fc/Kbuild |4
include/uapi/scsi/fc/fc_els.h |0
include
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
Acked-by: Thomas Gleixner
Acked-by: Michael Kerrisk
Acked-by: Paul E. McKenney
Acked-by: Dave Jones
---
include/rdma/Kbuild |6 --
include/rdma/rdma_netlink.h | 36
Kees Cook wrote:
> This is a quick review of the devel-pekeys tree...
Thanks!
> +static int public_key_verify_signature_2(const struct key *key,
>
> Maybe name this "key_verify_signature" instead of using the trailing _2?
I would prefer that it begin with "public_key_" as that reflects the wh
> > More of my paranoia for array access here. :)
>
> I've added this at the top of pkc7_digest():
>
> if (pkcs7->sig.pkey_hash_algo > PKEY_HASH__LAST ||
> pkey_hash_algo_name[pkcs7->sig.pkey_hash_algo])
There should be a '!' here.
> return -ENOPKG;
David
--
To un
Cong Ding wrote:
> the variable sender is dereferenced in line 190, so it is no reason to check
> null again in line 198.
Did you mean "The variable 'chan'"?
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mo
Cong Ding wrote:
> > > the variable sender is dereferenced in line 190, so it is no reason to
> > > check
> > > null again in line 198.
> >
> > Did you mean "The variable 'chan'"?
> sorry, my fault. so should I send a new version to correct the typo?
Yep.
David
--
To unsubscribe from this lis
e arch/x86/include/asm (2012-12-12 22:58:24 +)
UAPI disintegration 2012-12-12
--------
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x
egration 2012-12-14
--------
David Howells (1):
UAPI: (Scripted) Disintegrate arch/x86/include/asm
arch/x86/include/asm/Kbuild | 26 ---
arch/x86/include/asm/boot.h | 9 +-
arch/x86/include/asm/debugreg.h | 79 +---
arch/x
Linus Torvalds wrote:
> > A quiet cycle for the security subsystem with just a few maintenance
> > updates.
>
> Ok, pulled. There were a few trivial conflicts (mostly due to some of
> the key allocation patches having already been merged, and some of the
> kuid/kgid changes due to the userns cha
Use keyring_alloc() to create special keyrings now that it has a permissions
parameter rather than using key_alloc() + key_instantiate_and_link().
Signed-off-by: David Howells
cc: Rusty Russell
---
kernel/modsign_pubkey.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions
From: Alan Cox
We set ret to NULL then test it. Remove the bogus test
Signed-off-by: Alan Cox
Signed-off-by: David Howells
---
security/keys/process_keys.c |2 --
1 file changed, 2 deletions(-)
diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index 58dfe08
nges up to 96433f6ee49032d7a8bda76de2b05cfde2914354:
UAPI: (Scripted) Disintegrate arch/alpha/include/asm (2012-12-17 14:12:19
+)
UAPI disintegration 2012-12-17
--------
David Howells (1):
xport to userspace, it had nothing outside of __KERNEL__.
Signed-off-by: David Howells
cc: Jean Delvare
---
arch/x86/include/uapi/asm/hw_breakpoint.h |4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/include/uapi/asm/hw_breakpoint.h
b/arch/x86/include/uapi/asm/hw_breakpo
space, it had nothing outside of __KERNEL__.
Signed-off-by: David Howells
cc: Jean Delvare
---
arch/x86/include/uapi/asm/setup.h |4
1 file changed, 4 insertions(+)
diff --git a/arch/x86/include/uapi/asm/setup.h
b/arch/x86/include/uapi/asm/setup.h
index e69de29..96a4d53 100644
--- a
1:06 +0100)
(from the branch description for modsign-post-KS local branch)
post Kernel-Summit module signing
--------
David Howells (24):
KEYS: Add payload preparsing opportunity prior to key instantiate or
update
MPILI
Geert Uytterhoeven wrote:
> Just wondering, what's the advantage of doing panic over just
> rejecting the module?
> Panic is a DoS?
FIPS mode is strange like that.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.
Rusty Russell wrote:
> And after those three fixes, I still get all fail:
>
> [3.361036] Request for unknown module key 'Magrathea: Glacier signing
> key: 6
> e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11
Can you look back further in your kernel output, see if you can spot the bit
wher
Rusty Russell wrote:
> Signed-off-by: Rusty Russell
Acked-by: David Howells
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
Rusty Russell wrote:
> -source ./.config
> +. ./.config
Does that make a difference?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
Rusty Russell wrote:
> warning: (MODULE_SIG) selects ASYMMETRIC_KEY_TYPE which has unmet direct
> dependencies (CRYPTO && KEYS)
>
> Ah, I see:
>
> + select CONFIG_KEYS
> + select CONFIG_CRYPTO
>
> I fixed this commit, rather than go around again.
Thanks.
select is irritatingly broke
Rusty Russell wrote:
> [3.361036] Request for unknown module key 'Magrathea: Glacier signing
> key: 6
> e03943da0f3b015ba6ed7f5e0cac4fe48680994' err -11
Okay, it turns out that my attempts to remove SHA1 by editing it out of the
.config file were doomed to failure because a couple of IPv6
description for modsign-post-KS local branch)
post Kernel-Summit module signing
--------
David Howells (2):
MODSIGN: Use the same digest for the autogen key sig as for the module sig
MODSIGN: Use utf8 strings in signer's name in
Rusty Russell wrote:
> [2.808075] Loading module verification certificates
> [2.809331] X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has
> expired
> [2.810500] MODSIGN: Problem loading in-kernel X.509 certificate (-127)
Hmmm... Other people have seen that.
Ah!
I wonde
Rusty Russell wrote:
> I noticed the Cert number didn't change with rebuilds: "distclean"
> didn't remove some files:
>
> $ git clean -f -f -x -d
> Removing extra_certificates
> Removing signing_key.priv
> Removing signing_key.x509
> Removing signing_key.x509.keyid
> Removing signing_key.x509.si
Looks reasonable, I think, so you can add:
Acked-by: David Howells
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Pleas
Mimi Zohar wrote:
> David, are you ok with how support for asymmetric keys is being added to
> EVM/IMA-appraisal for verifying signatures? Any comments?
I would also like to have a look at altering your trusted key type[*] to be a
subtype of asymmetric keys so that the asymmetric key type can c
Load all the files matching the pattern "*.x509" that are to be found in kernel
base source dir and base build dir into the module signing keyring.
The "extra_certificates" file is then redundant.
Signed-off-by: David Howells
---
kernel/Makefile
Separate the kernel signature checking keyring from module signing so that it
can be used by code other than the module-signing code.
Signed-off-by: David Howells
---
init/Kconfig | 13 +
kernel/Makefile | 17 ---
kernel/modsign_certificate.S | 18
.
Signed-off-by: David Howells
Reviewed-by: Kees Cook
---
include/linux/key-type.h |1 +
include/linux/key.h |3 +++
kernel/system_keyring.c |4 +++-
security/keys/key.c |8
security/keys/keyring.c |4
5 files changed, 19 insertions(+), 1 deletion
Mimi Zohar wrote:
> Lets assume accepting built in keys should is acceptable for all use
> cases. Adding additional keys from userspace is probably not acceptable
> for all use cases. Those keys should be added to specific 'trusted'
> keyrings.
>
> EVM and IMA-appraisal have separate keyrings
Sedat Dilek wrote:
> Culprit seems to be...
>
> commit d6941c0c6bd42c725e45240a86c4add92e9bfb3e
> "KEYS: Separate the kernel signature checking keyring from module signing"
Try updating. I pushed a new version out today. This is now at commit ID
c82af351e270e0d95059d09a1975b61494fbbcd7.
Davi
Cong Ding wrote:
> When I am doing "make randconfig", it causes the following building error if
> CONFIG_SYSTEM_TRUSTED_KEYRING is not defined and CONFIG_MODULE_SIG is defined.
Can you tell me what you're doing your build upon?
> -#ifdef CONFIG_SYSTEM_TRUSTED_KEYRING
> +#if defined(CONFIG_SYSTE
Sedat Dilek wrote:
> - select KEYS
> + depends on KEYS
This change was pushed upstream a few hours ago. It may not have made it into
linux-next yet.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mo
Casey Schaufler <[EMAIL PROTECTED]> wrote:
> > +static int smack_task_kernel_act_as(struct task_struct *p,
> > + struct task_security *sec, u32 secid)
> > +{
> > + return -ENOTSUPP;
> > +}
> ...
> > +static int smack_task_create_files_as(struct task_struct *p,
> > +
David Howells <[EMAIL PROTECTED]> wrote:
> > > Have you got before/after benchmark results?
> >
> > See attached.
>
> Attached here are results using BTRFS (patched so that it'll work at all)
> rather than Ext3 on the client on the partition backing the
Chris Mason <[EMAIL PROTECTED]> wrote:
> > The interesting case is where the disk cache is warm, but the pagecache is
> > cold (ie: just after a reboot after filling the caches). Here, for the two
> > big files case, BTRFS appears quite a bit better than Ext3, showing a 21%
> > reduction in time
Chris Mason <[EMAIL PROTECTED]> wrote:
> Thanks for trying this, of course I'll ask you to try again with the latest
> v0.13 code, it has a number of optimizations especially for CPU usage.
Here you go. The numbers are very similar.
David
=
FEW BIG FILES TEST O
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> I am eventually going to suggest cutting the backing filesystem entirely out
> of the picture,
You still need a database to manage the cache. A filesystem such as Ext3
makes a very handy database for four reasons:
(1) It exists and works.
(2) It h
WANG Cong <[EMAIL PROTECTED]> wrote:
> This patch makes the macro get_personality function-like.
>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
Acked-By: David Howells <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
WANG Cong <[EMAIL PROTECTED]> wrote:
> Use get_personality() macro instead of explicit reference
> for frv code.
>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
Acked-By: David Howells <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "unsub
WANG Cong <[EMAIL PROTECTED]> wrote:
> Use get_personality() macro instead of explicit reference
> for mn10300 code.
>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
Acked-By: David Howells <[EMAIL PROTECTED]>
--
To unsubscribe from this list: send the line "un
Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> (3)
>
> LOCK
>
> LOAD(a)
> MODIFY(b)
>
> UNLOCK
>
> and this last one is a problem. No?
I assume you meant:
LOCK
LOAD(b)
MODIFY(a)
UNLOCK
David
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> This factor of four (even worse on XFS, not quite as bad on Ext3) is
> worth ruminating upon. Is all of the difference explained by avoiding
> seeks on the server, which has the files in memory?
Here are some more stats for you to consider:
(1) Cop
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Monday 25 February 2008 15:19, David Howells wrote:
> > So I guess there's a problem in cachefiles's efficiency - possibly due
> > to the fact that it tries to be fully asynchronous.
>
> OK, not just my ima
Roman Zippel <[EMAIL PROTECTED]> wrote:
> I would actually prefer to introduce an explicit API for signed 64
> divides to get rid of the temps completely
Yeah, that's a better plan.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMA
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> I need to respond to this in pieces... first the bit that is bugging
> me:
>
> > > * two new page flags
> >
> > I need to keep track of two bits of per-cached-page information:
> >
> > (1) This page is known by the cache, and that the cache must b
ed in
using it.
Signed-off-by: David Howells
Cc: David S. Miller
Cc: Dmitry Kasatkin
Cc: Arnd Bergmann
---
include/asm-generic/bitops/count_zeros.h | 57
lib/mpi/longlong.h | 138 --
lib/mpi/mpi-bit.c|
From: Marc Dionne
Commit 3a50597de86 in mainline removed the definition of the
thread_group_cred structure, but left a now unused pointer in
struct cred.
Signed-off-by: Marc Dionne
Signed-off-by: David Howells
---
include/linux/cred.h |1 -
1 file changed, 1 deletion(-)
diff --git a
I've found a bug in the write path of the read/write semaphore stuff (at least
for the i386 arch). The attached kernel module (rwsem.c) and driver program
(driver.c) demonstrate it.
What happens is that once the driver finishes, you end up with a whole load of
processes forked off of driver that
Since you're willing to use CMPXCHG in your suggested implementation, would it
make it make life easier if you were willing to use XADD too?
Plus, are you really willing to limit the number of readers or writers to be
32767? If so, I think I can suggest a way that limits it to ~65535 apiece
inst
e
obtained as well as write locks and a revised driver program (driver.c) that
can use rwsem.c. Try the following tests:
driver -200 & driver 200 # fork 200 writers and then 200 readers
driver 200 & driver -200 # fork 200 readers and then 200 writers
David Howells
diff -uN
Can CONFIG_X86_XADD be equated to CONFIG_X86_CMPXCHG?
David
-
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/
_bias_granted, 1))
+ rwsemdebug("E\n");
+
+ /* grant an infinite number of read locks to the readers at the front of the
+queue
+* - note we increment the 'active part' of the count by the number of readers
+just woken,
+* less one for the activity decr
> I'd like you to look over it. It seems newer GCC's (snapshots and the
> upcoming 3.0) will be more strict when modifying some values through
> assembler-passed pointers - in this case, the passed semaphore structure got
> freed too early, causing massive stack corruption on early bootup.
>
> The
I've been discussing it with some other kernel and GCC people, and they think
that only "memory" is required.
> What are the reasons against mentioning sem->count directly as a "=m"
> reference? This makes the whole thing less fragile and no more dependent
> on the memory layout of the structure
default:
BUG();
- wake_up(&sem->wait);
- return sem;
-}
+ }
-struct rw_semaphore *rwsem_wake_writer(struct rw_semaphore *sem)
-{
- if (xchg(&sem->write_bias_granted, 1))
+ rwsemdebug("E\n");
+
+ /* grant an infinite n
701 - 800 of 7895 matches
Mail list logo
