Re: [PATCH] perf tools: fix build for various architectures
On Tue, Nov 27, 2012 at 12:16:31PM +, Mark Rutland wrote: > Signed-off-by: Mark Rutland > Cc: Arnaldo Carvalho de Melo > Cc: David Howells > Cc: Deng-Cheng Zhu > Cc: Ingo Molnar > Cc: Kyle McMartin Looks obviously right. Acked-by: Kyle McMartin > Cc: Martin Schwidefsky > Cc: Paul Mackerras > Cc: Peter Zijlstra > Cc: Tony Luck > Cc: Will Deacon -- 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 read the FAQ at http://www.tux.org/lkml/
[RFC PATCH] fips: check whether a module registering an alg or template is signed
fips mode needs to prevent unsigned modules from registering crypto
algorithms, and currently panics if an unsigned module is attempted to
be loaded. Instead, forbid (by returning -EINVAL) registering a crypto
alg or template if fips mode is enabled and the module signature is not
valid.
crypto_sig_check should return 1 (and allow the registration) if any
of the following are true:
1/ fips is not enabled (but CONFIG_CRYPTO_FIPS is enabled.)
2/ the algorithm is built into the kernel (THIS_MODULE == NULL)
3/ the algorithm is in a module, and the module sig check passes
and fail in any of the other cases.
Checking in crypto_check_alg and crypto_register_template seems to hit
the callpoints as far as I can see.
Signed-off-by: Kyle McMartin
---
rusty,
How about something like this? It keeps the FIPS mess in the
crypto/fips.c file (aside from something that goes away entirely in the
!CONFIG_CRYPTO_FIPS case.)
regards, Kyle
--- a/crypto/algapi.c
+++ b/crypto/algapi.c
@@ -52,6 +52,9 @@ static int crypto_check_alg(struct crypto_alg *alg)
if (alg->cra_priority < 0)
return -EINVAL;
+ if (!crypto_sig_check(alg->cra_module))
+ return -EINVAL;
+
return crypto_set_driver_name(alg);
}
@@ -435,6 +438,11 @@ int crypto_register_template(struct crypto_template *tmpl)
goto out;
}
+ if (!crypto_sig_check(tmpl->module)) {
+ err = -EINVAL;
+ goto out;
+ }
+
list_add(&tmpl->list, &crypto_template_list);
crypto_notify(CRYPTO_MSG_TMPL_REGISTER, tmpl);
err = 0;
diff --git a/crypto/fips.c b/crypto/fips.c
index 5539700..2ebbe0f 100644
--- a/crypto/fips.c
+++ b/crypto/fips.c
@@ -15,6 +15,19 @@
int fips_enabled;
EXPORT_SYMBOL_GPL(fips_enabled);
+/* forbid loading modules in fips mode if the module is not signed */
+int crypto_sig_check(struct module *m)
+{
+#if defined(CONFIG_MODULE_SIG)
+ if (!fips_enabled || !m || (m && m->sig_ok))
+ return 1;
+ else
+ return 0;
+#else
+ return 1;
+#endif
+}
+
/* Process kernel command-line parameter at boot time. fips=0 or fips=1 */
static int fips_enable(char *str)
{
diff --git a/crypto/internal.h b/crypto/internal.h
index 9ebedae..937bfaf 100644
--- a/crypto/internal.h
+++ b/crypto/internal.h
@@ -139,5 +139,14 @@ static inline void crypto_notify(unsigned long val, void
*v)
blocking_notifier_call_chain(&crypto_chain, val, v);
}
+#if defined(CONFIG_CRYPTO_FIPS)
+int crypto_sig_check(struct module *m);
+#else
+static inline int crypto_sig_check(struct module *m)
+{
+ return 1;
+}
+#endif
+
#endif /* _CRYPTO_INTERNAL_H */
--
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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] fips: check whether a module registering an alg or template is signed
On Wed, Feb 06, 2013 at 09:02:46AM +0100, Stephan Mueller wrote: > On 05.02.2013 23:58:30, +0100, Kyle McMartin wrote: > > Hi Kyle, > Thanks for the review, Stephan. > Just reading this paragraph, there is one missing puzzle piece: the > *entire* kernel crypto API must shut down, even if only one kernel > module with one cipher (or block chaining mode, ...) has a broken signature. > > The overall requirement is: if one self test fails, the entire FIPS > 140-2 crypto module must become unavailable. (please note and do not get > confused by the overload of the term "module" -- we have the KOs the > kernel loads, and we have something called a FIPS 140-2 module which is > the entire crypto "library" subject to a FIPS 140-2 validation) > > This signature check is one self test required at runtime. > > I added comments inline into the patch. > > > > > crypto_sig_check should return 1 (and allow the registration) if any > > of the following are true: > > + if (!crypto_sig_check(alg->cra_module)) > > + return -EINVAL; > > Instead of an EINVAL, the kernel either must panic(), or a global flag > is introduced which is evaluated by every kernel crypto API call. If > that flag is, say, false, none of the kernel crypto API calls must succeed. Returning -EINVAL means the module does not successfully load, and nothing is registered. I don't see why you would need to taint or panic, if nothing untoward actually occured? I don't object to it, if it's necessary, I just didn't think it was. If Herbert doesn't object to this patch, I'd move the panic from kernel/module.c to here. > > + > > return crypto_set_driver_name(alg); > > } > > > > @@ -435,6 +438,11 @@ int crypto_register_template(struct crypto_template > > *tmpl) > > > I am wondering whether the modification of these two functions are > sufficient. As I wrote in a previous email, there are a number of > register functions the kernel crypto API exports and which are used. > Between these two, I believe all codepaths that could bring in a mode, cipher, or other cryptographic algorithm are covered. > > goto out; > > } regards, Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] fips: check whether a module registering an alg or template is signed
On Wed, Feb 06, 2013 at 06:45:45PM +0100, Stephan Mueller wrote: > Unfortunately there has already something terrible happened: an > additional piece of code loaded into the FIPS 140-2 module could not be > loaded because a self test failed. This is a terrible accident in FIPS > 140-2 speak. :-) > > That means, the FIPS 140-2 module, aka kernel crypto API must become > unavailable. As one self test failed, the entire module must become > unavailable. > > I am sorry, but there is no way around it. Just to quote the relevant > part from the FIPS 140-2 specification, section 4.9: > > If a cryptographic module fails a self-test, the module shall enter an > error state and output an error indicator > via the status output interface. The cryptographic module shall not > perform any cryptographic operations > while in an error state. All data output via the data output interface > shall be inhibited when an error state > exists. > OK. If Herbert and Rusty are ok with this, I'll send an additional patch moving the panic which should satisfy this requirement. > > ==> the signature test we are discussing here is one of these self > tests, in particular a conditional self test defined in section 4.9.2 of > the FIPS 140-2 standard. > > > necessary, I just didn't think it was. If Herbert doesn't object to this > > patch, I'd move the panic from kernel/module.c to here. > > I am perfectly happy with the move of the code. > regards, Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MODSIGN: only panic in fips mode if sig_enforce is set
On Wed, Jan 23, 2013 at 04:18:32PM +0100, Stephan Mueller wrote: > 3. in the cipher initialization code of the crypto API (i.e. the one > behind crypto_register_alg()), you check the signature check flag -- > panic the kernel when the flag shows that the signature check failed > > This way you limit the panic on signature checks in FIPS mode to the > crypto modules. > I was hoping we could just do what we do for driver/staging and set a flag in modpost for crypto modules, but it looks like since we have crypto modules outside of crypto/ for things like aesni, that won't work. Maybe that is a better choice, but it seems like an awful kludge. --Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
[PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
After thinking about it a while, this seems like the best way to solve
the problem, although it does still kind of offend my delicate
sensibilities...
Doing this check in the crypto layer seems kind of like a layering
violation to me (and, to be honest, I think it'd be a gross-hack getting
from the callee back to the caller module.)
Instead, doing it in kernel/module.c and looking at the undefined symbol
list again looks to me like an ordering problem since we're doing the
signature check before we've even done the elf header check. We'd have
to move the panic to a part of the module code that may not necessarily
make sense.
Whereas checking the undefined symbol list at modpost time is fairly
logical, and adding a new MODULE_INFO entry in the CONFIG_CRYPTO_FIPS
case is a well understood thing to do, and should catch all the crypto
registrations regardless of where they exist in-tree...
Seems to build and work with both values of CONFIG_CRYPTO_FIPS.
Thoughts?
Signed-off-by: Kyle McMartin
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2459,8 +2459,10 @@ static int module_sig_check(struct load_info *info)
return 0;
}
- /* Not having a signature is only an error if we're strict. */
- if (err < 0 && fips_enabled)
+ /* Not having a signature is only an error if we're strict, and
+* the module registers a crypto algorithm (checked in modpost)
+*/
+ if (err < 0 && fips_enabled && !get_modinfo(info, "crypto_fips"))
panic("Module verification failed with error %d in FIPS mode\n",
err);
if (err == -ENOKEY && !sig_enforce)
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index ff36c50..79f46e2 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -1888,6 +1888,23 @@ static void add_staging_flag(struct buffer *b, const
char *name)
buf_printf(b, "\nMODULE_INFO(staging, \"Y\");\n");
}
+static void add_crypto_flag(struct buffer *b, struct module *mod)
+{
+#if defined(CONFIG_CRYPTO_FIPS)
+ struct symbol *s;
+
+ /* iterate unresolved symbols looking for...
+* - crypto_register_algs
+*/
+ for (s = mod->unres; s; s = s->next) {
+ if (strcmp("crypto_register_algs", s->name) == 0)
+ buf_printf(b, "\nMODULE_INFO(crypto_fips, \"Y\");\n");
+ }
+#else
+ return;
+#endif /*CONFIG_CRYPTO_FIPS*/
+}
+
/**
* Record CRCs for unresolved symbols
**/
@@ -2202,6 +2219,7 @@ int main(int argc, char **argv)
add_header(&buf, mod);
add_intree_flag(&buf, !external_module);
add_staging_flag(&buf, mod->name);
+ add_crypto_flag(&buf, mod);
err |= add_versions(&buf, mod);
add_depends(&buf, mod, modules);
add_moddevtable(&buf, mod);
--
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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
On Thu, Jan 24, 2013 at 02:06:10PM -0500, Kyle McMartin wrote: > + if (err < 0 && fips_enabled && !get_modinfo(info, "crypto_fips")) Sigh, that should be get_modinfo(...) if (err < 0 && fips_enabled && get_modinfo(info, "crypto_fips")) Thinko when converting from flagging things as "nocrypto" to the above, since it touches far fewer .ko --Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
[PATCH] unhide CONFIG_PANIC_ON_OOPS
CONFIG_EXPERT doesn't really make sense, and hides it unintentionally. Remove superfluous "default n" pointed out by Ingo as well. Signed-off-by: Kyle McMartin --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -243,8 +243,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE default 1 if BOOTPARAM_SOFTLOCKUP_PANIC config PANIC_ON_OOPS - bool "Panic on Oops" if EXPERT - default n + bool "Panic on Oops" help Say Y here to enable the kernel to panic when it oopses. This has the same effect as setting oops=panic on the kernel command -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
On Fri, Jan 25, 2013 at 10:06:01AM +1030, Rusty Russell wrote: > Kyle McMartin writes: > > After thinking about it a while, this seems like the best way to solve > > the problem, although it does still kind of offend my delicate > > sensibilities... > > You're far too polite. This patch was horrible, partial and ugly. > Yeah, fair enough. -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent = pa11_dma_alloc_consistent?
On Mon, Feb 11, 2008 at 05:23:33PM +0100, Roel Kluin wrote:
>
How about just doing something like this:
diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c
index 9448d4e..63f9b7f 100644
--- a/arch/parisc/kernel/pci-dma.c
+++ b/arch/parisc/kernel/pci-dma.c
@@ -409,7 +409,7 @@ pcxl_dma_init(void)
__initcall(pcxl_dma_init);
-static void * pa11_dma_alloc_consistent (struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
+static void * pcxl_dma_alloc_consistent (struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
unsigned long vaddr;
unsigned long paddr;
@@ -435,7 +435,7 @@ static void * pa11_dma_alloc_consistent (struct device
*dev, size_t size, dma_ad
return (void *)vaddr;
}
-static void pa11_dma_free_consistent (struct device *dev, size_t size, void
*vaddr, dma_addr_t dma_handle)
+static void pcxl_dma_free_consistent (struct device *dev, size_t size, void
*vaddr, dma_addr_t dma_handle)
{
int order;
@@ -548,9 +548,9 @@ static void pa11_dma_sync_sg_for_device(struct device *dev,
struct scatterlist *
struct hppa_dma_ops pcxl_dma_ops = {
.dma_supported =pa11_dma_supported,
- .alloc_consistent = pa11_dma_alloc_consistent,
- .alloc_noncoherent =pa11_dma_alloc_consistent,
- .free_consistent = pa11_dma_free_consistent,
+ .alloc_consistent = pcxl_dma_alloc_consistent,
+ .alloc_noncoherent =pcxl_dma_alloc_consistent,
+ .free_consistent = pcxl_dma_free_consistent,
.map_single = pa11_dma_map_single,
.unmap_single = pa11_dma_unmap_single,
.map_sg = pa11_dma_map_sg,
@@ -567,7 +567,7 @@ static void *fail_alloc_consistent(struct device *dev,
size_t size,
return NULL;
}
-static void *pa11_dma_alloc_noncoherent(struct device *dev, size_t size,
+static void *pcx_dma_alloc_noncoherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
void *addr;
@@ -579,7 +579,7 @@ static void *pa11_dma_alloc_noncoherent(struct device *dev,
size_t size,
return addr;
}
-static void pa11_dma_free_noncoherent(struct device *dev, size_t size,
+static void pcx_dma_free_noncoherent(struct device *dev, size_t size,
void *vaddr, dma_addr_t iova)
{
free_pages((unsigned long)vaddr, get_order(size));
@@ -589,8 +589,8 @@ static void pa11_dma_free_noncoherent(struct device *dev,
size_t size,
struct hppa_dma_ops pcx_dma_ops = {
.dma_supported =pa11_dma_supported,
.alloc_consistent = fail_alloc_consistent,
- .alloc_noncoherent =pa11_dma_alloc_noncoherent,
- .free_consistent = pa11_dma_free_noncoherent,
+ .alloc_noncoherent =pcx_dma_alloc_noncoherent,
+ .free_consistent = pcx_dma_free_noncoherent,
.map_single = pa11_dma_map_single,
.unmap_single = pa11_dma_unmap_single,
.map_sg = pa11_dma_map_sg,
--
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?][arch/parisc/kernel/pci-dma.c] pcxl_dma_ops.alloc_noncoherent
On Mon, Feb 11, 2008 at 07:56:10PM +0100, Roel Kluin wrote:
> +/*
> + * dma_alloc_noncoherent is a fallback for boxes PA7200 and below which
> + * cannot allocate coherent memory.
> + */
> static void *pa11_dma_alloc_noncoherent(struct device *dev, size_t size,
> dma_addr_t *dma_handle, gfp_t flag)
> {
Why? This is located below pcxl_dma_ops so its obviously only relevant
for pcx.
> @@ -586,6 +590,10 @@ static void pa11_dma_free_noncoherent(struct device
> *dev, size_t size,
> return;
> }
>
> +/*
> + * PCXL allocates coherent memory even for dma_alloc_noncoherent() due to the
> + * uncached trick for coherent memory.
> + */
This isn't correct either.
> struct hppa_dma_ops pcx_dma_ops = {
> .dma_supported =pa11_dma_supported,
> .alloc_consistent = fail_alloc_consistent,
>
--
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: parisc compile error
On Wed, Feb 13, 2008 at 07:49:12AM +0100, rubisher wrote:
> --- include/asm-parisc/pgtable.h.Orig 2007-10-22 08:19:20.0 +
> +++ include/asm-parisc/pgtable.h 2008-02-12 16:28:36.0 +
> +extern void *vmalloc_start;
> +#define PCXL_DMA_MAP_SIZE (8*1024*1024)
> +#define VMALLOC_START ((unsigned long)vmalloc_start)
> +/* this is a fixmap remnant, see fixmap.h */
> +#define VMALLOC_END (KERNEL_MAP_END)
> +
i moved this to fixmap.h, since i think it makes more sense there,
really.
> static inline void pte_free_kernel(struct mm_struct *mm, struct page *pte)
> {
> pgtable_page_dtor(pte);
> pte_free_kernel(page_address((pte));
> }
>
this is a stunning bit of ignorant patching courtesy of
2f569afd9ced9ebec9a6eb3dbf6f83429be0a7b4 which:
-#define pte_free(mm, page) pte_free_kernel(page_address(page))
+static inline void pte_free_kernel(struct mm_struct *mm, struct page
*pte)
+{
+ pgtable_page_dtor(pte);
+ pte_free_kernel(page_address((pte));
+}
only wrong on *two* counts.
anyway, fixed this up. sigh.
--
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: parisc compile error
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
> - some lake of changes of kset to kobj:
thanks, i don't build this driver, somehow it made its way out of my
configs. patch looks correct though. applied.
> --- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
> +
> +++ ./drivers/parisc/pdc_stable.c 2008-02-13 11:22:16.0 +
> @@ -829,7 +829,7 @@
> struct kobj_attribute *attr,
> const char *buf, size_t count)
> {
> - return pdcs_auto_write(kset, attr, buf, count, PF_AUTOBOOT);
> + return pdcs_auto_write(kobj, attr, buf, count, PF_AUTOBOOT);
> }
>
> /**
> @@ -845,7 +845,7 @@
>struct kobj_attribute *attr,
>const char *buf, size_t count)
> {
> - return pdcs_auto_write(kset, attr, buf, count, PF_AUTOSEARCH);
> + return pdcs_auto_write(kobj, attr, buf, count, PF_AUTOSEARCH);
> }
>
> /**
> @@ -1066,7 +1066,7 @@
> }
>
> /* Don't forget the root entries */
> - error = sysfs_create_group(stable_kobj, pdcs_attr_group);
> + error = sysfs_create_group(stable_kobj, &pdcs_attr_group);
>
> /* register the paths kset as a child of the stable kset */
> paths_kset = kset_create_and_add("paths", NULL, stable_kobj);
> === <> ===
>
> And the kernel build, but I don't yet try to boot it...
>
> Hth,
> r.
> ---
> Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
> http://www.scarlet.be/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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] perf: builtin-trace.c: check if MAP_32BIT is defined
From: Kyle McMartin MAP_32BIT is defined only on x86... this means perf fails to build on all other platforms. Signed-off-by: Kyle McMartin --- a/tools/perf/builtin-trace.c +++ b/tools/perf/builtin-trace.c @@ -100,7 +100,9 @@ static size_t syscall_arg__scnprintf_mmap_flags(char *bf, size_t size, P_MMAP_FLAG(SHARED); P_MMAP_FLAG(PRIVATE); +#ifdef MAP_32BIT P_MMAP_FLAG(32BIT); +#endif P_MMAP_FLAG(ANONYMOUS); P_MMAP_FLAG(DENYWRITE); P_MMAP_FLAG(EXECUTABLE); -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] parisc: Export flush_cache_page() (needed by lustre)
On Thu, Sep 05, 2013 at 09:01:59AM -0700, James Bottomley wrote:
> > +EXPORT_SYMBOL_GPL(flush_cache_page);
>
> This is an internal API: no architecture exports this. Whoever is
> trying to use it needs to use the correct API, so this is the wrong
> patch.
>
I suspect it's copy_{to,from}_user_page being called here:
drivers/staging/lustre/lustre/libcfs/linux/linux-curproc.c:
copy_to_user_page(vma, page, addr,
which we could probably take out of line.
--Kyle
--
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 read the FAQ at http://www.tux.org/lkml/
Re: ftrace 'failed to modify' bug when loading reiserfs.ko
On Fri, Sep 06, 2013 at 10:24:13AM -0400, Steven Rostedt wrote: > > Is it really safe to load modules that were compiled with different > options? Certainly not, offsets can change based on config options. > Sounds like a failure in the install scripts to me. > Definitely a bug in those scripts, os-prober would need to run before modules_install, since if $INSTALL_MOD_PATH is the same between config changes, there's no guarantee the modules are loadable on the running kernel without a reboot. --Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] kernel: add support for init_array constructors
On Fri, Sep 06, 2013 at 07:51:18PM +0200, Frantisek Hrbata wrote: > > > v2: - reuse mod->ctors for .init_array section for modules, because gcc > > > uses > > > .ctors or .init_array, but not both at the same time > > > > > > Signed-off-by: Frantisek Hrbata > > > > Might be nice to document which gcc version changed this, so people can > > choose whether to cherry-pick this change? > > Thank you for pointing this out. As per gcc git this was introduced by commit > ef1da80 and released in 4.7 version. > > $ git describe --contains ef1da80 > gcc-4_7_0-release~4358 > > Do you want me to post v3 with this info included in the descrition? > It actually depends on the combination of binutils/ld and gcc you use, not simply which gcc version you use. :/ --Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 4/4] kernel: add support for init_array constructors
On Mon, Sep 09, 2013 at 06:28:14PM +0200, Frantisek Hrbata wrote: > I'm not sure if coexistence of .ctors and .init_array sections should result > in > denial of module, but I for sure know nothing about this :). Could you maybe > privide one example of the "weird thing"? > They shouldn't exist unless placed there intentionally... I suspect a call_if_changed Makefile target to regenerated a header would solve this problem sufficiently for a given toolchain version. A little exposition: .init_array and .ctors are laid out on top of each other, with an ordering that's a bit complicated... the sort of the ctor functions ends up being .ctor.x upwards towards 65535, and .init_array.x downwards from 65535 towards 0, with priority 65535-x, so that .init_array.32768 would be called before .ctor.32768. It's all a complete mess. Perhaps if CONFIG_GCOV is on, we should enforce MODVERSIONS and make sure the GCC version doesn't change for the running kernel? Maybe it would be sufficient to just detect what the toolchain supports and do that? I have a patch based on the configure.ac in gcc that does something like that, which would be trivial to use to generate a header based on gcc version. > Anyway many thanks for taking time to look at this. Below is my attepmt to > implement the check you proposed. > > untested/uncompiled regards, Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
[PATCH] arm64/Makefile: provide vdso_install target
Provide a vdso_install target in the arm64 Makefile, as other architectures with a vdso do. Signed-off-by: Kyle McMartin --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -60,6 +60,10 @@ zinstall install: vmlinux dtbs: scripts $(Q)$(MAKE) $(build)=$(boot)/dts dtbs +PHONY += vdso_install +vdso_install: + $(Q)$(MAKE) $(build)=arch/arm64/kernel/vdso $@ + # We use MRPROPER_FILES and CLEAN_FILES now archclean: $(Q)$(MAKE) $(clean)=$(boot) -- 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 read the FAQ at http://www.tux.org/lkml/
[PATCH] Kbuild: pass headers to headers_install.sh on stdin
While using make V=1 to test some things, I noticed on our builders that headers_install was failing because the argument list to /bin/sh was too long. Working around it is slightly kludgy... First, passing the args list to headers_install.sh via stdin instead of as arguments. Secondly, filtering $srctree out of $input-files to reduce the length of the args list to the subshell. Lastly, re-add $srctree when we loop over $input-files and pass the file list back through to headers_install.sh. You can reproduce the issue locally by putting your build dir in a long path. make[2]: execvp: /bin/sh: Argument list too long make[2]: *** [/home/kyle/A(lots of times)/linux/usr/include/linux/.install] Error 127 make[1]: *** [linux] Error 2 make: *** [headers_install] Error 2 Signed-off-by: Kyle McMartin --- a/scripts/Makefile.headersinst +++ b/scripts/Makefile.headersinst @@ -59,6 +59,8 @@ input-files := $(foreach hdr, $(header-y), \ $(wildcard $(gendir)/$(hdr)), \ $(error Missing generated UAPI file $(gendir)/$(hdr)) \ )) +input-files:= $(foreach hdr, $(input-files), \ + $(subst $(srctree)/,,$(hdr))) # Work out what needs to be removed oldheaders:= $(patsubst $(installdir)/%,%,$(wildcard $(installdir)/*.h)) @@ -72,7 +74,9 @@ printdir = $(patsubst $(INSTALL_HDR_PATH)/%/,%,$(dir $@)) quiet_cmd_install = INSTALL $(printdir) ($(words $(all-files))\ file$(if $(word 2, $(all-files)),s)) cmd_install = \ -$(CONFIG_SHELL) $< $(installdir) $(input-files); \ +for f in $(input-files); do \ +echo "$(srctree)/$$f"; \ +done | $(CONFIG_SHELL) $< $(installdir); \ for F in $(wrapper-files); do \ echo "\#include " > $(installdir)/$$F;\ done; \ diff --git a/scripts/headers_install.sh b/scripts/headers_install.sh index 643764f..4e53688 100644 --- a/scripts/headers_install.sh +++ b/scripts/headers_install.sh @@ -2,7 +2,7 @@ if [ $# -lt 1 ] then - echo "Usage: headers_install.sh OUTDIR [FILES...] + echo "Usage: FILES | headers_install.sh OUTDIR echo echo "Prepares kernel header files for use by user space, by removing" echo "all compiler.h definitions and #includes, removing any" @@ -10,7 +10,7 @@ then echo "asm/inline/volatile keywords." echo echo "OUTDIR: directory to write each userspace header FILE to." - echo "FILES: list of header files to operate on." + echo "FILES: list of header files to operate on, passed stdin." exit 1 fi @@ -18,13 +18,12 @@ fi # Grab arguments OUTDIR="$1" -shift # Iterate through files listed on command line FILE= trap 'rm -f "$OUTDIR/$FILE" "$OUTDIR/$FILE.sed"' EXIT -for i in "$@" +while read i do FILE="$(basename "$i")" sed -r \ -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Kbuild: pass headers to headers_install.sh on stdin
On Thu, Jun 06, 2013 at 07:41:57PM +0200, Michal Marek wrote: > Dne 6.6.2013 19:05, Kyle McMartin napsal(a): > > While using make V=1 to test some things, I noticed on our builders that > > headers_install was failing because the argument list to /bin/sh was too > > long. Working around it is slightly kludgy... > > This is already fixed with > > > commit c0ff68f1611d6855a06d672989ad5cfea160a4eb > Author: Nicolas Dichtel > Date: Mon Apr 29 14:15:51 2013 +0200 > > kbuild: fix make headers_install when path is too long > > > in linux-next. > OK, I guess. --Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arch: parisc: kernel: using strlcpy() instead of strcpy()
On Thu, May 30, 2013 at 09:18:43AM +0800, Chen Gang wrote: > > 'boot_args' is an input args, and 'boot_command_line' has a fix length. > > So need use strlcpy() instead of strcpy() to avoid memory overflow. > This is basically impossible, since boot_args is fixed in size by palo, initialized to zero, and length checked in the bootloader. It's also only 256+4 bytes compared to the 1024 bytes set aside for boot_command_line. That said, it's harmless to use strlcpy here, and obviously (more) correct. Thanks! Acked-by: Kyle McMartin -- 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 read the FAQ at http://www.tux.org/lkml/
Revert "serial: 8250: Make SERIAL_8250_RUNTIME_UARTS work correctly"
This reverts commit cfcec52e9781f08948c6eb98198d65c45be75a70.
This regresses a longstanding behaviour on X86 systems, which end up with
PCI serial ports moving between ttyS4 and ttyS0 when you bisect to opposite
sides of this commit, resulting in the need to constantly modify the console
setting in order to bisect across it.
Please revert, we can work on solving this for ARM platforms in a less
disruptive way.
Signed-off-by: Kyle McMartin
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -2755,7 +2755,7 @@ static void __init serial8250_isa_init_ports(void)
if (nr_uarts > UART_NR)
nr_uarts = UART_NR;
- for (i = 0; i < UART_NR; i++) {
+ for (i = 0; i < nr_uarts; i++) {
struct uart_8250_port *up = &serial8250_ports[i];
struct uart_port *port = &up->port;
@@ -2916,7 +2916,7 @@ static int __init serial8250_console_setup(struct console
*co, char *options)
* if so, search for the first available port that does have
* console support.
*/
- if (co->index >= UART_NR)
+ if (co->index >= nr_uarts)
co->index = 0;
port = &serial8250_ports[co->index].port;
if (!port->iobase && !port->membase)
@@ -2957,7 +2957,7 @@ int serial8250_find_port(struct uart_port *p)
int line;
struct uart_port *port;
- for (line = 0; line < UART_NR; line++) {
+ for (line = 0; line < nr_uarts; line++) {
port = &serial8250_ports[line].port;
if (uart_match_port(p, port))
return line;
@@ -3110,7 +3110,7 @@ static int serial8250_remove(struct platform_device *dev)
{
int i;
- for (i = 0; i < UART_NR; i++) {
+ for (i = 0; i < nr_uarts; i++) {
struct uart_8250_port *up = &serial8250_ports[i];
if (up->port.dev == &dev->dev)
@@ -3178,7 +3178,7 @@ static struct uart_8250_port
*serial8250_find_match_or_unused(struct uart_port *
/*
* First, find a port entry which matches.
*/
- for (i = 0; i < UART_NR; i++)
+ for (i = 0; i < nr_uarts; i++)
if (uart_match_port(&serial8250_ports[i].port, port))
return &serial8250_ports[i];
@@ -3187,7 +3187,7 @@ static struct uart_8250_port
*serial8250_find_match_or_unused(struct uart_port *
* free entry. We look for one which hasn't been previously
* used (indicated by zero iobase).
*/
- for (i = 0; i < UART_NR; i++)
+ for (i = 0; i < nr_uarts; i++)
if (serial8250_ports[i].port.type == PORT_UNKNOWN &&
serial8250_ports[i].port.iobase == 0)
return &serial8250_ports[i];
@@ -3196,7 +3196,7 @@ static struct uart_8250_port
*serial8250_find_match_or_unused(struct uart_port *
* That also failed. Last resort is to find any entry which
* doesn't have a real port associated with it.
*/
- for (i = 0; i < UART_NR; i++)
+ for (i = 0; i < nr_uarts; i++)
if (serial8250_ports[i].port.type == PORT_UNKNOWN)
return &serial8250_ports[i];
--
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 read the FAQ at http://www.tux.org/lkml/
Re: Revert "serial: 8250: Make SERIAL_8250_RUNTIME_UARTS work correctly"
On Mon, Jun 03, 2013 at 09:55:31AM -0700, Greg KH wrote: > On Mon, Jun 03, 2013 at 09:38:26AM -0400, Kyle McMartin wrote: > > This reverts commit cfcec52e9781f08948c6eb98198d65c45be75a70. > > > > This regresses a longstanding behaviour on X86 systems, which end up with > > PCI serial ports moving between ttyS4 and ttyS0 when you bisect to opposite > > sides of this commit, resulting in the need to constantly modify the console > > setting in order to bisect across it. > > > > Please revert, we can work on solving this for ARM platforms in a less > > disruptive way. > > Ugh, how did this break x86 systems? Karthik, you said this wouldn't > affect anyone else, what did you test it on? > > > Signed-off-by: Kyle McMartin > > I'll go queue this up for the next -rc release, thanks Kyle. > No worries, I undertand what Karthik is talking about, so I'll try to figure this out. CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 is what was set in my .config, resulting in: [3.9.y] 0: uart:16550A port:1030 irq:16 tx:16522 rx:0 RTS|CTS|DTR|CD 1: uart:unknown port:02F8 irq:3 2: uart:unknown port:03E8 irq:4 3: uart:unknown port:02E8 irq:3 [3.10-rc2] 0: uart:unknown port:03F8 irq:4 1: uart:unknown port:02F8 irq:3 2: uart:unknown port:03E8 irq:4 3: uart:unknown port:02E8 irq:3 4: uart:16550A port:1030 irq:16 tx:16226 rx:0 RTS|CTS|DTR|CD There's undeniably something wrong if RUNTIME_UARTS=0 doesn't result in his serial ports showing up, I'll try to help debug that, but I think the 3.9 behaviour is desireable if no "legacy" uarts are found. regards, Kyle -- 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 read the FAQ at http://www.tux.org/lkml/
[PATCH] score: remove redundant kcore_list entries
kcore_vmalloc is in fs/proc/kcore.c and kcore_mem is unused across
the tree. Noticed while grepping the tree for some other kcore stuff.
(score looks pretty unmaintained to me.)
Signed-off-by: Kyle McMartin
--- a/arch/score/mm/init.c
+++ b/arch/score/mm/init.c
@@ -41,8 +41,6 @@
unsigned long empty_zero_page;
EXPORT_SYMBOL_GPL(empty_zero_page);
-static struct kcore_list kcore_mem, kcore_vmalloc;
-
static void setup_zero_page(void)
{
struct page *page;
--
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 read the FAQ at http://www.tux.org/lkml/
[PATCH] ioatdma: check dma_mapping_error in ioat_dma_self_test
Not checking dma_mapping_error on these dma_map_single uses keeps
showing up in our test runs with DMA-API debugging enabled.
[ 19.744756] ioatdma: Intel(R) QuickData Technology Driver 4.00
[ 19.748979] [ cut here ]
[ 19.748991] WARNING: at lib/dma-debug.c:933 check_unmap+0x407/0x8a0()
Signed-off-by: Kyle McMartin
--- a/drivers/dma/ioat/dma.c
+++ b/drivers/dma/ioat/dma.c
@@ -832,7 +832,17 @@ int ioat_dma_self_test(struct ioatdma_device *device)
}
dma_src = dma_map_single(dev, src, IOAT_TEST_SIZE, DMA_TO_DEVICE);
+ if (dma_mapping_error(dev, dma_src)) {
+ err = -ENODEV;
+ goto free_resources;
+ }
dma_dest = dma_map_single(dev, dest, IOAT_TEST_SIZE, DMA_FROM_DEVICE);
+ if (dma_mapping_error(dev, dma_dest)) {
+ err = -ENODEV;
+ dma_unmap_single(dev, dma_src, IOAT_TEST_SIZE, DMA_TO_DEVICE);
+ goto free_resources;
+ }
+
flags = DMA_COMPL_SKIP_SRC_UNMAP | DMA_COMPL_SKIP_DEST_UNMAP |
DMA_PREP_INTERRUPT;
tx = device->common.device_prep_dma_memcpy(dma_chan, dma_dest, dma_src,
--
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 read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 05/12] PCI: Require CAP_COMPROMISE_KERNEL for PCI BAR access
On Wed, Mar 27, 2013 at 11:03:26AM -0400, Josh Boyer wrote:
> On Mon, Mar 18, 2013 at 5:32 PM, Matthew Garrett
> wrote:
> > Any hardware that can potentially generate DMA has to be locked down from
> > userspace in order to avoid it being possible for an attacker to cause
> > arbitrary kernel behaviour. Default to paranoid - in future we can
> > potentially relax this for sufficiently IOMMU-isolated devices.
> >
> > Signed-off-by: Matthew Garrett
>
> As noted here:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=90
>
> this breaks pci passthru with QEMU. The suggestion in the bug is to move
> the check from read/write to open, but sysfs makes that somewhat
> difficult. The open code is part of the core sysfs functionality shared
> with the majority of sysfs files, so adding a check there would restrict
> things that clearly don't need to be restricted.
>
> Kyle had the idea to add a cap field to the attribute structure, and do
> a capable check if that is set. That would allow for a more generic
> usage of capabilities in sysfs code, at the cost of slightly increasing
> the structure size and open path. That seems somewhat promising if we
> stick with capabilities.
>
> I would love to just squarely blame capabilities for causing this, but we
> can't just replace it with an efi_enabled(EFI_SECURE_BOOT) check because
> of the sysfs open case. I'm not sure there are great answers here.
>
Yeah, that was something like this (I don't even remember which Fedora
kernel version this was against.)
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -546,9 +546,6 @@ pci_write_config(struct file* filp, struct kobject *kobj,
loff_t init_off = off;
u8 *data = (u8*) buf;
- if (!capable(CAP_COMPROMISE_KERNEL))
- return -EPERM;
-
if (off > dev->cfg_size)
return 0;
if (off + count > dev->cfg_size) {
@@ -772,6 +769,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_io->attr.name = "legacy_io";
b->legacy_io->size = 0x;
b->legacy_io->attr.mode = S_IRUSR | S_IWUSR;
+ b->legacy_io->attr.cap = CAP_COMPROMISE_KERNEL;
b->legacy_io->read = pci_read_legacy_io;
b->legacy_io->write = pci_write_legacy_io;
b->legacy_io->mmap = pci_mmap_legacy_io;
@@ -786,6 +784,7 @@ void pci_create_legacy_files(struct pci_bus *b)
b->legacy_mem->attr.name = "legacy_mem";
b->legacy_mem->size = 1024*1024;
b->legacy_mem->attr.mode = S_IRUSR | S_IWUSR;
+ b->legacy_io->attr.cap = CAP_COMPROMISE_KERNEL;
b->legacy_mem->mmap = pci_mmap_legacy_mem;
pci_adjust_legacy_attr(b, pci_mmap_mem);
error = device_create_bin_file(&b->dev, b->legacy_mem);
@@ -855,9 +854,6 @@ pci_mmap_resource(struct kobject *kobj, struct
bin_attribute *attr,
resource_size_t start, end;
int i;
- if (!capable(CAP_COMPROMISE_KERNEL))
- return -EPERM;
-
for (i = 0; i < PCI_ROM_RESOURCE; i++)
if (res == &pdev->resource[i])
break;
@@ -965,9 +961,6 @@ pci_write_resource_io(struct file *filp, struct kobject
*kobj,
struct bin_attribute *attr, char *buf,
loff_t off, size_t count)
{
- if (!capable(CAP_COMPROMISE_KERNEL))
- return -EPERM;
-
return pci_resource_io(filp, kobj, attr, buf, off, count, true);
}
@@ -1027,6 +1020,7 @@ static int pci_create_attr(struct pci_dev *pdev, int num,
int write_combine)
}
res_attr->attr.name = res_attr_name;
res_attr->attr.mode = S_IRUSR | S_IWUSR;
+ res_attr->attr.cap = CAP_COMPROMISE_KERNEL;
res_attr->size = pci_resource_len(pdev, num);
res_attr->private = &pdev->resource[num];
retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr);
@@ -1142,6 +1136,7 @@ static struct bin_attribute pci_config_attr = {
.attr = {
.name = "config",
.mode = S_IRUGO | S_IWUSR,
+ .cap = CAP_COMPROMISE_KERNEL,
},
.size = PCI_CFG_SPACE_SIZE,
.read = pci_read_config,
@@ -1152,6 +1147,7 @@ static struct bin_attribute pcie_config_attr = {
.attr = {
.name = "config",
.mode = S_IRUGO | S_IWUSR,
+ .cap = CAP_COMPROMISE_KERNEL,
},
.size = PCI_CFG_SPACE_EXP_SIZE,
.read = pci_read_config,
@@ -1201,6 +1197,7 @@ static int pci_create_capabilities_sysfs(struct pci_dev
*dev)
attr->size = dev->vpd->len;
attr->attr.name = "vpd";
attr->attr.mode = S_IRUSR | S_IWUSR;
+ attr->attr.cap = CAP_COMPROMISE_KERNEL;
attr->read = read_vpd_attr;
attr->write = write_vpd_attr;
retval = sysfs_create_bin_file(&dev->dev.kobj, attr);
diff --git a/fs/sysfs/bin.c b/fs/sys
[PATCH] DocBook/device-drivers.tmpl: fix 8250.c reference
htmldocs will fail, because device-drivers.tmpl references the non-existant file 8250.c (which got renamed to 8250_core.c) Signed-off-by: Kyle McMartin --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -227,7 +227,7 @@ X!Isound/sound_firmware.c 16x50 UART Driver !Edrivers/tty/serial/serial_core.c -!Edrivers/tty/serial/8250/8250.c +!Edrivers/tty/serial/8250/8250_core.c -- 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 read the FAQ at http://www.tux.org/lkml/
Re: parisc compile error
On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote:
>
Can I get your Signed-off-by for this, Joel? (I assume you are Joel :)
cheers, Kyle
> - some lake of changes of kset to kobj:
> --- ./drivers/parisc/pdc_stable.c.Orig2008-01-28 07:09:26.0
> +
> +++ ./drivers/parisc/pdc_stable.c 2008-02-13 11:22:16.0 +
> @@ -829,7 +829,7 @@
> struct kobj_attribute *attr,
> const char *buf, size_t count)
> {
> - return pdcs_auto_write(kset, attr, buf, count, PF_AUTOBOOT);
> + return pdcs_auto_write(kobj, attr, buf, count, PF_AUTOBOOT);
> }
>
> /**
> @@ -845,7 +845,7 @@
>struct kobj_attribute *attr,
>const char *buf, size_t count)
> {
> - return pdcs_auto_write(kset, attr, buf, count, PF_AUTOSEARCH);
> + return pdcs_auto_write(kobj, attr, buf, count, PF_AUTOSEARCH);
> }
>
> /**
> @@ -1066,7 +1066,7 @@
> }
>
> /* Don't forget the root entries */
> - error = sysfs_create_group(stable_kobj, pdcs_attr_group);
> + error = sysfs_create_group(stable_kobj, &pdcs_attr_group);
>
> /* register the paths kset as a child of the stable kset */
> paths_kset = kset_create_and_add("paths", NULL, stable_kobj);
> === <> ===
>
> And the kernel build, but I don't yet try to boot it...
>
> Hth,
> r.
> ---
> Scarlet One, ADSL 6 Mbps + Telephone, from EUR 29,95...
> http://www.scarlet.be/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
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: parisc compile error
On Mon, Feb 18, 2008 at 11:32:58AM +0100, rubisher wrote: > > On Wed, Feb 13, 2008 at 01:42:10PM +0100, rubisher wrote: > > > > > > > Can I get your Signed-off-by for this, Joel? (I assume you are Joel :) > > > Yes the previous account seems to be a bit old and look more and more like a > gc; I so take the opportunity of ml's change to use another pseudo ;-) > > That said those 2 hunks help build (even boot my 32bit up kernel on b2k and > d380 boxes): > ok, good to know. > Signed-off-by: Joel Soete > great, thanks! > (any advise is welcome obviously ;-) > cheers, kyle -- 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] lguest: fix undefined asm-offsets symbols
lguest uses asm-offsets to generate ... offsets, obviously, for use in the lguest switcher code. When the hypervisor code is built as a module though, the asm offsets it needs won't be generated since CONFIG_LGUEST will be undefined. Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> --- diff --git a/arch/x86/kernel/asm-offsets_32.c b/arch/x86/kernel/asm-offsets_32.c index a33d530..44bafdd 100644 --- a/arch/x86/kernel/asm-offsets_32.c +++ b/arch/x86/kernel/asm-offsets_32.c @@ -134,7 +134,7 @@ void foo(void) OFFSET(LGUEST_DATA_pgdir, lguest_data, pgdir); #endif -#ifdef CONFIG_LGUEST +#if defined(CONFIG_LGUEST) || defined(CONFIG_LGUEST_MODULE) BLANK(); OFFSET(LGUEST_PAGES_host_gdt_desc, lguest_pages, state.host_gdt_desc); OFFSET(LGUEST_PAGES_host_idt_desc, lguest_pages, state.host_idt_desc); -- 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 pci-remove-parisc-consumer-of-the-pci-global_list.patch added to gregkh-2.6 tree
On Wed, Feb 20, 2008 at 02:25:02PM -0800, [EMAIL PROTECTED] wrote: > > This is a note to let you know that I've just added the patch titled > > Subject: PCI: remove parisc consumer of the pci global_list > Thanks for finding this, both of you. Probably saves me some heartaches for 2.6.26-rc1. :) cheers, Kyle -- 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: parisc compile error
On Fri, Feb 08, 2008 at 01:12:32AM +0200, Adrian Bunk wrote: > Commit 9e2779fa281cfda13ac060753d674bbcaa23367e broke parisc: > > <-- snip --> > > ... > CC arch/parisc/kernel/asm-offsets.s > In file included from include/asm/pgtable.h:13, > from arch/parisc/kernel/asm-offsets.c:36: > include/linux/mm.h: In function 'is_vmalloc_addr': > include/linux/mm.h:243: error: 'VMALLOC_START' undeclared (first use in this > function) > include/linux/mm.h:243: error: (Each undeclared identifier is reported only > once > include/linux/mm.h:243: error: for each function it appears in.) > include/linux/mm.h:243: error: 'VMALLOC_END' undeclared (first use in this > function) > make[1]: *** [arch/parisc/kernel/asm-offsets.s] Error 1 > yes, it's in my batch of fixes. thanks for the reminder. cheers, kyle -- 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: parisc compile error
On Thu, Feb 07, 2008 at 03:33:07PM -0800, Christoph Lameter wrote: > On Thu, 7 Feb 2008, Kyle McMartin wrote: > > > yes, it's in my batch of fixes. > > So I do not have to worry about it? > haha no. i don't expect people to have to untangle the mess of includes that is :) cheers, kyle -- 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] MODSIGN: only panic in fips mode if sig_enforce is set
Commit 1d0059f3a added a test to check if the system is booted in fips
mode, and if so, panic the system if an unsigned module is loaded.
However the wording of the changelog "in signature enforcing mode" leads
one to assume that sig_enforce should be set for the panic to occur and
that these two tests are transposed.
Move the test for -ENOKEY && !sig_enforce before the test of fips_mode,
so that err will be 0, and the panic will not trigger unless we've
explicitly disabled unsigned modules with sig_enforce set, so that
systemtap and 3rd party modules will work in fips mode. (This also
matches the behaviour by Red Hat Enterprise Linux 6.)
Things which need to deny module loading such as secure boot already set
sig_enforce, so there's no issue here.
Reported-by: Jan Stancek
Signed-off-by: Kyle McMartin
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -2460,11 +2460,11 @@ static int module_sig_check(struct load_info *info)
}
/* Not having a signature is only an error if we're strict. */
+ if (err == -ENOKEY && !sig_enforce)
+ err = 0;
if (err < 0 && fips_enabled)
panic("Module verification failed with error %d in FIPS mode\n",
err);
- if (err == -ENOKEY && !sig_enforce)
- err = 0;
return err;
}
--
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 read the FAQ at http://www.tux.org/lkml/
[PATCH] CONFIG_PANIC_ON_OOPS should be shown if DEBUG_KERNEL
CONFIG_EXPERT is a bit silly a place for this, and hides it unnecessarily. CONFIG_DEBUG_KERNEL makes much more sense. Signed-off-by: Kyle McMartin --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -243,7 +243,7 @@ config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE default 1 if BOOTPARAM_SOFTLOCKUP_PANIC config PANIC_ON_OOPS - bool "Panic on Oops" if EXPERT + bool "Panic on Oops" if DEBUG_KERNEL default n help Say Y here to enable the kernel to panic when it oopses. This -- 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 read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] schedule obsolete OSS drivers for removal
On Tue, Jul 26, 2005 at 05:08:37PM +0200, Adrian Bunk wrote: > This patch schedules obsolete OSS drivers (with ALSA drivers that > support the same hardware) for removal. oss/harmony.c can probably go, unless someone from parisc-linux objects. I've written a (working) replacement[1] for oss/ad1889.c which is in our cvs, and will go upstream shortly. oss/ad1889.c doesn't (and hasn't ever) worked, so it should probably be removed. Stuart, Randolph, comments? 1. http://cvs.parisc-linux.org/linux-2.6/sound/pci/ad1889.c?rev=1.30&view=markup Cheers, -- Kyle McMartin - 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] call sysrq_timer_list_show from a workqueue
handle_sysrq can be called from interrupt context. sysrq_timer_list_show
eventually starts poking at module symbols which take the module mutex.
so instead, let's just kick off a workqueue.
[ doesn't happen on my laptop with the keyboard, but does when
triggered from /proc/sysrq-trigger ]
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
diff --git a/drivers/char/sysrq.c b/drivers/char/sysrq.c
index de60e1e..09bb030 100644
--- a/drivers/char/sysrq.c
+++ b/drivers/char/sysrq.c
@@ -159,10 +159,16 @@ static struct sysrq_key_op sysrq_sync_op = {
.enable_mask= SYSRQ_ENABLE_SYNC,
};
-static void sysrq_handle_show_timers(int key, struct tty_struct *tty)
+static void sysrq_show_timers_callback(struct work_struct *whocares)
{
sysrq_timer_list_show();
}
+static DECLARE_WORK(show_timers_work, sysrq_show_timers_callback);
+
+static void sysrq_handle_show_timers(int key, struct tty_struct *tty)
+{
+ schedule_work(&show_timers_work);
+}
static struct sysrq_key_op sysrq_show_timers_op = {
.handler= sysrq_handle_show_timers,
--
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] call sysrq_timer_list_show from a workqueue
On Tue, Jan 08, 2008 at 10:28:04PM +1100, Rusty Russell wrote: > De-mutex more symbol lookup paths in the module code > > Kyle McMartin reports sysrq_timer_list_show() can hit the module > mutex; these paths don't need to though, since we long ago changed all > the module list manipulation to occur via stop_machine(). > > Disabling preemption is enough. > > Signed-off-by: Rusty Russell <[EMAIL PROTECTED]> > ACK that it (obviously) fixes the lock checker spew. Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> cheers, Kyle -- 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: [RFT] Port 0x80 I/O speed
On Wed, Dec 12, 2007 at 12:31:18AM +0100, Rene Herman wrote:
> asm volatile ("rdtsc": "=A" (tsc));
rdtsc returns a 64-bit value in two 32-bit regs, you need to do
inline unsigned long long rdtsc(void)
{
unsigned int lo, hi;
asm volatile ("rdtsc": "=a" (lo), "=d" (hi));
return (unsigned long long)hi << 32 | lo;
}
as in msr.h, otherwise you'll only be looking at the value in %rax.
cheers,
Kyle
--
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: RFC: remove __read_mostly
On Thu, Dec 13, 2007 at 11:20:44PM +0100, Adrian Bunk wrote: > Is there anywhere in the kernel a case where __read_mostly brings a > measurable improvement or can it be removed? > Yes, definitely[1]... the problem is, and this is also true of other annotations[2], that people go absolutely nuts adding these annotations without doing any profiling to see whether they actually improve things. I'd bet, in the __read_mostly case at least, that there's no improvement in almost all cases. cheers, Kyle 1. It's hugely relevant on big-SMP machines. 2. I mean __read_mostly, likely, unlikely, etc., not the useful sparse annotations. -- 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.24-rc8-mm1
On Thu, Jan 17, 2008 at 02:35:14AM -0800, Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc8/2.6.24-rc8-mm1/ > Odd nobody else has seen this... oldconfig fails for me on Debian... kconfig/conf.c is using setlocale() without including the locale.h header. HOSTCC scripts/kconfig/conf.o scripts/kconfig/conf.c: In function 'main': scripts/kconfig/conf.c:502: warning: implicit declaration of function 'setlocale' scripts/kconfig/conf.c:502: error: 'LC_ALL' undeclared (first use in this function) scripts/kconfig/conf.c:502: error: (Each undeclared identifier is reported only once Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> --- a/scripts/kconfig/conf.c2008-01-17 15:45:59.0 -0800 +++ b/scripts/kconfig/conf.c2008-01-18 10:01:54.0 -0800 @@ -3,6 +3,8 @@ * Released under the terms of the GNU GPL v2.0. */ +#include + #include #include #include -- 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: G33 graphics broken after 2.6.23-rc6
On Fri, Oct 05, 2007 at 08:20:01PM -0400, Matthew Reppert wrote: > It works fine in the Ubuntu kernels (pre 2.6.22-13) and in mainline through > 2.6.23-rc6; since 2.6.23-rc7 (and Ubuntu 2.6.22-13), the X server won't > start up, and I get this at the end of my Xorg.log: > AOL. And I was in the middle of watching a bloody movie too. commit f443675affe3f16dd428e46f0f7fd3f4d703eeab Author: Zhenyu Wang <[EMAIL PROTECTED]> Date: Tue Sep 11 15:23:57 2007 -0700 intel_agp: fix stolen mem range on G33 G33 GTT stolen memory is below graphics data stolen memory and be seperate, so don't subtract it in stolen mem counting. Signed-off-by: Zhenyu Wang <[EMAIL PROTECTED]> Acked-by: Dave Airlie <[EMAIL PROTECTED]> Cc: Dave Jones <[EMAIL PROTECTED]> Signed-off-by: Andrew Morton <[EMAIL PROTECTED]> Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]> Looks to be the commit that breaks things. Regards, Kyle M. - 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: G33 graphics broken after 2.6.23-rc6
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote: > commit f443675affe3f16dd428e46f0f7fd3f4d703eeab > intel_agp: fix stolen mem range on G33 > G33 GTT stolen memory is below graphics data stolen memory and be > seperate, > so don't subtract it in stolen mem counting. > Found it, without this corresponding change to xf86-video-intel, this breaks utterly: commit 2a8592f2ebcba86b1127aa889155d58a3dc186ca Author: Zhenyu Wang <[EMAIL PROTECTED]> Date: Wed Sep 5 14:52:56 2007 +0800 Fix G33 GTT stolen mem range G33 GTT table lives in seperate stolen mem with graphics data stolen mem. I think this should be reverted for 2.6.23, it certainly doesn't seem to have been appropriate for 2.6.23-rc6. Cheers, Kyle M. - 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/
Revert "intel_agp: fix stolen mem range on G33"
This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
breaks horribly if you aren't running an unreleased xf86-video-intel
driver out of git.
Conflicts:
drivers/char/agp/intel-agp.c
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/char/agp/intel-agp.c |5 -
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/drivers/char/agp/intel-agp.c b/drivers/char/agp/intel-agp.c
index a5d0e95..141ca17 100644
--- a/drivers/char/agp/intel-agp.c
+++ b/drivers/char/agp/intel-agp.c
@@ -506,11 +506,6 @@ static void intel_i830_init_gtt_entries(void)
break;
}
} else {
- /* G33's GTT stolen memory is separate from gfx data
-* stolen memory.
-*/
- if (IS_G33)
- size = 0;
switch (gmch_ctrl & I855_GMCH_GMS_MASK) {
case I855_GMCH_GMS_STOLEN_1M:
gtt_entries = MB(1) - KB(size);
--
1.5.3.3
On Sat, Oct 06, 2007 at 01:34:10AM -0400, Kyle McMartin wrote:
> On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote:
> > commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
> > intel_agp: fix stolen mem range on G33
> > G33 GTT stolen memory is below graphics data stolen memory and be
> > seperate,
> > so don't subtract it in stolen mem counting.
> >
>
> Found it, without this corresponding change to xf86-video-intel, this
> breaks utterly:
>
> commit 2a8592f2ebcba86b1127aa889155d58a3dc186ca
> Author: Zhenyu Wang <[EMAIL PROTECTED]>
> Date: Wed Sep 5 14:52:56 2007 +0800
>
> Fix G33 GTT stolen mem range
>
> G33 GTT table lives in seperate stolen mem with
> graphics data stolen mem.
>
> I think this should be reverted for 2.6.23, it certainly doesn't seem to have
> been appropriate for 2.6.23-rc6.
>
> Cheers,
> Kyle M.
> -
> 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/
>
-
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: parisc arch makefile clean-up needed [Was: cleaning up "make headers_install" for various architectures]
On Wed, Oct 10, 2007 at 08:38:58PM +0200, Sam Ravnborg wrote: > parisc arch Makefile needs some love and care... > It basically hasn't been touched since 2.4, I already have a patch to clean up a lot of things when Randy pointed it out a while ago. Thanks for the reminder, I'll queue it for 2.6.24. Regards, Kyle > The logic selecting CROSS_COMPILE seems fishy and wrong - > the error reported by rday is obvious in this respect. > > FINAL_LD is unused - kill it. > > Building with oldpalo has been broken for a loong time - time to kill it? > Hint - the "cd ../palo" is not working as expected. > And use of TOPDIR is deprecated. > > The libs-y assignment should learn from the other architectures how to > get the gcc lib filename: > $(shell $(CC) $(CFLAGS) -print-libgcc-file-name) > > > And this snippet is also wrong: > PALO := $(shell if which palo; then : ; \ > elif [ -x /sbin/palo ]; then echo /sbin/palo; \ > fi) > > palo: vmlinux > @if [ -x $PALO ]; then \ > > > Make does not export variables so $PALO is not the same as $(PALO). > The latter should be used. > > I did not supply a patch because I do not fully understand the > logic behind setting CROSS_COMPILE and 64BIT or not. > But I will be happy to review a patch to fix the issues in the > parisc Makefile. I'll add this to the patch as well. - 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] bug.h: Introduce HAVE_ARCH_WARN
On Thu, Oct 11, 2007 at 12:12:11PM -0500, Olof Johansson wrote: > HAVE_ARCH_WARN is used to determine if an arch already has a __WARN() > macro, or if a generic one is needed. > > With this, some of the arch-specific WARN_ON() implementations can be > made common instead (see follow-up patch for powerpc). > > Signed-off-by: Olof Johansson <[EMAIL PROTECTED]> > ack parisc hunk (obviously :) cheers, kyle - 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 2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()
On Fri, Oct 12, 2007 at 11:23:39AM +1000, Paul Mackerras wrote: > Olof Johansson writes: > > > Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about > > 4K text on a ppc64_defconfig. The main reason seems to be that prepping > > the arguments to the conditional trap instructions is more work than > > just doing a compare and branch. > > It might be more instructions but it takes fewer cycles, I would > expect. Do you have the actual instruction sequences to compare? > I really hope WARN_ON/BUG_ON aren't hotpaths on powerpc. ;-) Cheers, Kyle - 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: Linux 2.6.24-rc6
On Thu, Dec 20, 2007 at 05:41:09PM -0800, Linus Torvalds wrote: > The regression list keeps shrinking, so we're still on track for a full > 2.6.24 release in early January. Assuming we don't all overeat during the > holidays and nobody gets any work done. But we all know that the holidays > are really the time when we get away from the boring "real work", and can > spend 24/7 on kernel hacking instead, right? > The patch-2.6.24-rc6.bz2 doesn't seem to apply to a pristine linux-2.6.23 tree? I see this while updating Fedora: + '[' '!' -f /home/kyle/rpms/kernel/devel/patch-2.6.24-rc6.bz2 ']' + case "$patch" in + bunzip2 + patch -p1 -F1 -s 1 out of 3 hunks FAILED -- saving rejects to file drivers/video/mbx/reg_bits.h.rej error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep) cheers, Kyle -- 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: Linux 2.6.24-rc6
On Thu, Dec 20, 2007 at 09:48:05PM -0500, Kyle McMartin wrote: > 1 out of 3 hunks FAILED -- saving rejects to file > drivers/video/mbx/reg_bits.h.rej > error: Bad exit status from /var/tmp/rpm-tmp.22316 (%prep) > I think I see the problem, it's lack of context in the diff, commit ba282daa919f89c871780f344a71e5403a70b634 Author: Raphael Assenat <[EMAIL PROTECTED]> Date: Tue Oct 16 01:28:40 2007 -0700 seems to duplicate the DINTRS & DINTRE defines for no obvious reason, confusing the hell out of patch. regards, Kyle -- 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] mbx: Fix up duplicate defines in reg_bits.h
Otherwise patch gets horribly confused and falls over applying the diff. Not sure why these were being defined twice. Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> --- Well, we can get it fixed for -git1, I respun the patch-2.6.24-rc6 diff with git diff -p v2.6.23..HEAD and applied it to a pristine linux-2.6.23 tree without issue. cheers, Kyle drivers/video/mbx/reg_bits.h | 24 1 files changed, 0 insertions(+), 24 deletions(-) diff --git a/drivers/video/mbx/reg_bits.h b/drivers/video/mbx/reg_bits.h index 5f14b4b..8dc4283 100644 --- a/drivers/video/mbx/reg_bits.h +++ b/drivers/video/mbx/reg_bits.h @@ -540,30 +540,6 @@ #define DINTRE_HBLNK1_EN (1 << 1) #define DINTRE_HBLNK0_EN (1 << 0) -/* DINTRS - Display Interrupt Status Register */ -#define DINTRS_CUR_OR_S(1 << 18) -#define DINTRS_STR2_OR_S (1 << 17) -#define DINTRS_STR1_OR_S (1 << 16) -#define DINTRS_CUR_UR_S(1 << 6) -#define DINTRS_STR2_UR_S (1 << 5) -#define DINTRS_STR1_UR_S (1 << 4) -#define DINTRS_VEVENT1_S (1 << 3) -#define DINTRS_VEVENT0_S (1 << 2) -#define DINTRS_HBLNK1_S(1 << 1) -#define DINTRS_HBLNK0_S(1 << 0) - -/* DINTRE - Display Interrupt Enable Register */ -#define DINTRE_CUR_OR_EN (1 << 18) -#define DINTRE_STR2_OR_EN (1 << 17) -#define DINTRE_STR1_OR_EN (1 << 16) -#define DINTRE_CUR_UR_EN (1 << 6) -#define DINTRE_STR2_UR_EN (1 << 5) -#define DINTRE_STR1_UR_EN (1 << 4) -#define DINTRE_VEVENT1_EN (1 << 3) -#define DINTRE_VEVENT0_EN (1 << 2) -#define DINTRE_HBLNK1_EN (1 << 1) -#define DINTRE_HBLNK0_EN (1 << 0) - /* DLSTS - display load status register */ #define DLSTS_RLD_ADONE(1 << 23) -- 1.5.3.6 -- 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: Linux 2.6.24-rc6
On Thu, Dec 20, 2007 at 07:49:05PM -0800, Linus Torvalds wrote: > > > On Thu, 20 Dec 2007, Kyle McMartin wrote: > > > > I think I see the problem, it's lack of context in the diff, > > No, the problem is that "git diff" is apparently broken by a recent > optimization. The diff is simply broken. > > The tar-ball and the git archive itself is fine, but yes, the diff from > 2.6.23 to 2.6.24-rc6 is bad. It's the "trim_common_tail()" optimization > that has caused way too much pain. > > Sorry about that, I'll fix it up asap. > no biggie, thanks! cheers, Kyle -- 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: Linux 2.6.24-rc6
On Thu, Dec 20, 2007 at 08:40:54PM -0800, Linus Torvalds wrote: > That was a rather long-winded explanation of what happened, mainly because > it was all very unexpected to me, and I had personally mistakenly thought > the git optimization was perfectly valid and actually had to go through > the end result to see what was going on. > > Anyway, the diff on kernel.org should be all ok now, and mirrored out too. > Thanks again for being so quick to track this down, applies fine and is out for building in rawhide now. cheers, Kyle -- 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 -mm 18/43] powerpc compat_binfmt_elf
On Fri, Dec 21, 2007 at 12:56:09AM -0800, Roland McGrath wrote: > > On Thu, Dec 20, 2007 at 03:58:16AM -0800, Roland McGrath wrote: > > > +obj-$(CONFIG_PPC64) += ../../../fs/compat_binfmt_elf.o > > > > Building files from another directory is nasty. Please add a > > CONFIG_BINFMT_COMPAT_ELF so we can simply build it in fs/ > > If that's better, please post the precise Kconfig magic you have in mind to > have it set when it should be. > Just taking a stab that hch means, config BINFMT_COMPAT_ELF def_bool n depends on 64BIT and then in arch/powerpc/Kconfig config COMPAT bool default y if PPC64 select BINFMT_COMPAT_ELF or somesuch. Regards, Kyle -- 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: [RFC v2] Documentation about unaligned memory access
Hi Daniel, On Thu, Nov 29, 2007 at 04:15:23PM +, Daniel Drake wrote: > Unaligned memory accesses occur when you try to read N bytes of data starting > from an address that is not evenly divisible by N (i.e. addr % N != 0). > For example, reading 4 bytes of data from address 0x10004 is fine, but > reading 4 bytes of data from address 0x10005 would be an unaligned memory > access. > This is rather ambiguous, while most people know what you mean, clarifying it a bit might be nice. How about something like, Unaligned memory accesses occur when trying to read more than a byte (i.e. u16, u32, u64) in a single instruction from an address that is not evenly divisible by the width of the type (i.e. addr % width != 0). For example, if you had 4GB of virtual memory, picture it as an array of bytes, u8 memory[4096 * (1024 * 1024)];/* 4G bytes */ Aligned accesses would be accessing this array in this manner, u16 memory[(4096 * (1024 * 1024)) / sizeof(u16)] /* 2G bytes */ u32 memory[(4096 * (1024 * 1024)) / sizeof(u32)] /* 1G bytes */ u64 memory[(4096 * (1024 * 1024)) / sizeof(u64)] /* 512M bytes */ And an unaligned access would be accessing on a non-integer multiple boundary. Ok, that kind of sucked too. But you get the idea. > > Why unaligned access is bad > === > The rest of this looks good. Acked-by: Kyle McMartin <[EMAIL PROTECTED]> cheers, Kyle - 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: Something similar to inotify in 2.4.
On Thu, Nov 29, 2007 at 07:09:51PM +0200, Vitaliy Ivanov wrote: > Hi all, > > Can anyone advice whether there is something similar to inotify in 2.4 kernel? > > Need efficient way to track file system changes. > > Maybe some other tools, approaches under 2.4? > dnotify[1]? but it might make you cry. cheers, Kyle 1. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/dnotify.txt;h=6984fca6002a304272ea3606e0ad1a34568221d6;hb=HEAD - 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: [BUG] 2.6.24-rc3-git2 softlockup detected
On Thu, Nov 29, 2007 at 12:35:33AM -0800, Andrew Morton wrote:
> ten million is close enough to infinity for me to assume that we broke the
> driver and that's never going to terminate.
>
how about this? doesn't break things on my pa8800:
diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c
b/drivers/scsi/sym53c8xx_2/sym_hipd.c
index 463f119..ef01cb1 100644
--- a/drivers/scsi/sym53c8xx_2/sym_hipd.c
+++ b/drivers/scsi/sym53c8xx_2/sym_hipd.c
@@ -1037,10 +1037,13 @@ restart_test:
/*
* Wait 'til done (with timeout)
*/
- for (i=0; i=SYM_SNOOP_TIMEOUT) {
+ msleep(10);
+ } while (i++ < SYM_SNOOP_TIMEOUT);
+
+ if (i >= SYM_SNOOP_TIMEOUT) {
printf ("CACHE TEST FAILED: timeout.\n");
return (0x20);
}
diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.h
b/drivers/scsi/sym53c8xx_2/sym_hipd.h
index ad07880..85c483b 100644
--- a/drivers/scsi/sym53c8xx_2/sym_hipd.h
+++ b/drivers/scsi/sym53c8xx_2/sym_hipd.h
@@ -339,7 +339,7 @@
/*
* Misc.
*/
-#define SYM_SNOOP_TIMEOUT (1000)
+#define SYM_SNOOP_TIMEOUT (1000)
#define BUS_8_BIT 0
#define BUS_16_BIT 1
-
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: Bogus PCI vendor ID
On Wed, Nov 28, 2007 at 09:41:24PM +0100, Kai Ruhnau wrote: > Kyle McMartin wrote: > > On Sun, Nov 25, 2007 at 01:36:19PM +0100, Kai Ruhnau wrote: > > > >> If this is the same like the kernel option 'pci=conf1', that fixes the > >> vendor IDs. > >> > > > > Same effect. Ubuntu and many other distros are shipping kernels with > > MMCONFIG off by default for reasons like this. Check to see if you have > > an updated BIOS from your motherboard manufacturer? > > > > No, nothing available there. (OEM board, running fine under Vista, I > don't expect to get support there...) > Ah, that's interesting, as Vista is supposed to require working MMCONFIG support to be certified. regards, Kyle - 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: Where is the interrupt going?
On Thu, Nov 22, 2007 at 01:56:25AM +, Alan Cox wrote: > > status = request_irq (apcsi[i].board_irq, > > apc8620_handler, > > IRQF_DISABLED, > > You set IRQF_DISABLED > > Do you then enable the interrupt anywhere later on ? > IRQF_DISABLED just means that the handler is atomic wrt other local interrupts. Shouldn't be the cause of this. cheers, Kyle - 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: Where is the interrupt going?
On Wed, Nov 21, 2007 at 05:08:30PM -0800, Al Niessner wrote: > On with the detailed technical information. I developed a kernel module > for an PCI card back in 2.4, moved it to 2.6.3, then 2.6.11 or so and > now I am trying to move it to 2.6.22. When I began the to move to > 2.6.22, I changed all of the deprecated calls for finding the card on > the PCI bus, modified the interrupt handler prototype, and changed my > readvv/writev to aio_read/aio_write following > http://lwn.net/Articles/202449/. So initialization looks like this: > Hi Al, >From the sounds of it, you might have an interrupt routing problem. Can you describe the machine you have this plugged into? Possibly attaching a copy of "dmesg" and "/proc/interrupts"? Feel free to attach the driver source to your email if the size is reasonable (which it sounds like it is.) As a "big hammer" in case it is an APIC problem, please try booting the kernel with the "noapic" parameter. cheers, Kyle - 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: Bogus PCI vendor ID
On Sun, Nov 25, 2007 at 01:36:19PM +0100, Kai Ruhnau wrote: > If this is the same like the kernel option 'pci=conf1', that fixes the > vendor IDs. > Same effect. Ubuntu and many other distros are shipping kernels with MMCONFIG off by default for reasons like this. Check to see if you have an updated BIOS from your motherboard manufacturer? cheers, Kyle - 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: [parisc] 2.6.24-rc3 (64-bit, smp) fails to boot on 9000/785/J5600
On Tue, Nov 27, 2007 at 10:26:34AM +0100, Frans Pop wrote: > v2.6.24-rc3-19-g2ffbb83 fails very early in the boot procedure. > 2.6.23 compiled with similar config boots fine. > > System is running Debian unstable; kernel was compiled using gcc 4.1.2. > Ah, I diagnosed this last week. Will post the patch in a bit. - 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: [RFC] New kobject/kset/ktype documentation and example code
On Tue, Nov 27, 2007 at 03:02:52PM -0800, Greg KH wrote: > Last updated November 27, 2008 > The future is now! ;-) cheers, Kyle - 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: [ANNOUNCE] Btrfs v0.10 (online growing/shrinking, ext3 conversion, and more)
On Tue, Jan 15, 2008 at 10:52:38AM -0500, Chris Mason wrote:
> http://oss.oracle.com/projects/btrfs/
>
> Btrfs is still in an early alpha state, and the disk format is not finalized.
> v0.10 introduces a new disk format, and is not compatible with v0.9.
>
Looks like fun. btrfsck fails to check if it actually received a
dev argument though, so if you don't pass a device, we get a nice
segfault.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
diff -Nur btrfs-progs-0.10/btrfsck.c btrfs-progs-0.10-kyle/btrfsck.c
--- btrfs-progs-0.10/btrfsck.c 2008-01-15 10:33:32.0 -0500
+++ btrfs-progs-0.10-kyle/btrfsck.c 2008-01-15 11:49:24.0 -0500
@@ -709,6 +709,11 @@
return err;
}
+void print_usage(void) {
+ fprintf(stderr, "usage: btrfsck dev\n");
+ exit(1);
+}
+
int main(int ac, char **av) {
struct btrfs_root *root;
struct cache_tree extent_cache;
@@ -727,6 +732,9 @@
int slot;
struct btrfs_root_item ri;
+ if (ac < 2)
+ print_usage();
+
radix_tree_init();
cache_tree_init(&extent_cache);
cache_tree_init(&seen);
--
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] x86: add is_f00f_bug helper to fault_32|64.c
On Tue, Jan 15, 2008 at 06:48:35PM -0800, Harvey Harrison wrote:
> +#ifdef CONFIG_X86_F00F_BUG
> +void do_invalid_op(struct pt_regs *, unsigned long);
> +#endif
> +
> +static int is_f00f_bug(struct pt_regs *regs, unsigned long address)
> +{
> +#ifdef CONFIG_X86_F00F_BUG
> + unsigned long nr;
You can just put the prototype inside the function, you know...
--
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: x86: remove casts
On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote: > parent a9f7faa5fd229a65747f02ab0f2d45ee35856760 > commit ^- did you just make that up? ;-) -- 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: x86: remove casts
On Wed, Jan 16, 2008 at 11:57:54PM +0100, Jan Engelhardt wrote: > > On Jan 16 2008 17:20, Kyle McMartin wrote: > >On Wed, Jan 16, 2008 at 10:15:39PM +0100, Jan Engelhardt wrote: > >> parent a9f7faa5fd229a65747f02ab0f2d45ee35856760 > >> commit > > > >^- did you just make that up? ;-) > > Yes. git does not care anyway. > right. the point was if you had generated a sha1 of all ones. that would be kind of neat. -- 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/
[mm patch] i915: fix invalid opcode exception on cpus without clflush
i915_flush_ttm was unconditionally executing a clflush instruction
to (obviously) flush the cache. Instead, check if the cpu supports
clflush, and if not, fall back to calling wbinvd to flush the entire
cache.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
--- a/drivers/char/drm/i915_buffer.c
+++ b/drivers/char/drm/i915_buffer.c
@@ -286,7 +286,18 @@ void i915_flush_ttm(struct drm_ttm *ttm)
return;
DRM_MEMORYBARRIER();
+
+#ifdef CONFIG_X86_32
+ /* Hopefully nobody has built an x86-64 processor without clflush */
+ if (!cpu_has_clflush) {
+ wbinvd();
+ DRM_MEMORYBARRIER();
+ return;
+ }
+#endif
+
for (i = ttm->num_pages - 1; i >= 0; i--)
drm_cache_flush_page(drm_ttm_get_page(ttm, i));
+
DRM_MEMORYBARRIER();
}
--
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: [mm patch] i915: fix invalid opcode exception on cpus without clflush
On Thu, Jan 17, 2008 at 09:03:17PM -0500, H. Peter Anvin wrote: > The #ifdef is bogus. If it's required, it should go into > asm-x86/required_features.h and then cpu_has_clflush is static; otherwise > it's just plain wrong. > I have no objection to making cpu_has_clflush constant on x86_64. The point was to get rid of a needless test & branch on 64-bit, and making it constant will have the same effect. cheers, Kyle -- 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] x86: make clflush a required feature on x86_64
Hopefully nobody will be stupid enough to implement a cpu without it. Frankly, it seems safe enough given we already require SSE2. This means the compiler can optimise away "if (!cpu_has_clflush)" blocks. Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> --- include/asm-x86/cpufeature_64.h |3 +++ include/asm-x86/required-features.h |4 +++- 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/include/asm-x86/cpufeature_64.h b/include/asm-x86/cpufeature_64.h index e18496b..ef11d27 100644 --- a/include/asm-x86/cpufeature_64.h +++ b/include/asm-x86/cpufeature_64.h @@ -18,6 +18,9 @@ #undef cpu_has_mp #define cpu_has_mp 1 /* XXX */ +#undef cpu_has_clflush +#definecpu_has_clflush1 + #undef cpu_has_k6_mtrr #define cpu_has_k6_mtrr0 diff --git a/include/asm-x86/required-features.h b/include/asm-x86/required-features.h index 7400d3a..cc27664 100644 --- a/include/asm-x86/required-features.h +++ b/include/asm-x86/required-features.h @@ -45,6 +45,7 @@ #define NEED_XMM (1<<(X86_FEATURE_XMM & 31)) #define NEED_XMM2 (1<<(X86_FEATURE_XMM2 & 31)) #define NEED_LM(1<<(X86_FEATURE_LM & 31)) +#define NEED_CLFLSH(1<<(X86_FEATURE_CLFLSH & 31)) #else #define NEED_PSE 0 #define NEED_MSR 0 @@ -53,11 +54,12 @@ #define NEED_XMM 0 #define NEED_XMM2 0 #define NEED_LM0 +#define NEED_CLFLSH0 #endif #define REQUIRED_MASK0 (NEED_FPU|NEED_PSE|NEED_MSR|NEED_PAE|\ NEED_CX8|NEED_PGE|NEED_FXSR|NEED_CMOV|\ -NEED_XMM|NEED_XMM2) +NEED_XMM|NEED_XMM2|NEED_CLFLSH) #define SSE_MASK (NEED_XMM|NEED_XMM2) #define REQUIRED_MASK1 (NEED_LM|NEED_3DNOW) -- 1.5.3.7 -- 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] x86: merge asm-x86/alternative.h
Straightforward merge. Kind of a pity that gas doesn't really have the
concept of a "long" (long is 4-bytes for some reason.) Nor is it able to
pad to a non-power of two boundary (for struct alignment) to get rid
of the struct alt_instr padding.
Build tested on i386, i386 with lguest & xen paravirt enabled, and
x86_64. Boot tested on x86_64.
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
include/asm-x86/alternative.h| 169 +-
include/asm-x86/alternative_32.h | 154 --
include/asm-x86/alternative_64.h | 159 ---
3 files changed, 166 insertions(+), 316 deletions(-)
delete mode 100644 include/asm-x86/alternative_32.h
delete mode 100644 include/asm-x86/alternative_64.h
diff --git a/include/asm-x86/alternative.h b/include/asm-x86/alternative.h
index 9eef6a3..7047a0f 100644
--- a/include/asm-x86/alternative.h
+++ b/include/asm-x86/alternative.h
@@ -1,5 +1,168 @@
-#ifdef CONFIG_X86_32
-# include "alternative_32.h"
+#ifndef _X86_ALTERNATIVE_H
+#define _X86_ALTERNATIVE_H
+
+#ifdef __KERNEL__
+
+#include
+#include
+
+#ifdef CONFIG_X86_64
+# define ALT_ASMPTR".quad"
+# define ALT_ALIGN "8"
+# define ALT_INSTR_PAD 5
#else
-# include "alternative_64.h"
+# define ALT_ASMPTR".long"
+# define ALT_ALIGN "4"
+# define ALT_INSTR_PAD 1
#endif
+
+struct alt_instr {
+ u8 *instr; /* original instruction */
+ u8 *replacement;
+ u8 cpuid; /* cpuid bit set for replacement */
+ u8 instrlen; /* length of original instruction */
+ u8 replacementlen; /* length of new instruction, <= instrlen */
+ u8 _pad[ALT_INSTR_PAD];
+};
+
+/*
+ * Alternative inline assembly for SMP.
+ *
+ * The LOCK_PREFIX macro defined here replaces the LOCK and
+ * LOCK_PREFIX macros used everywhere in the source tree.
+ *
+ * SMP alternatives use the same data structures as the other
+ * alternatives and the X86_FEATURE_UP flag to indicate the case of a
+ * UP system running a SMP kernel. The existing apply_alternatives()
+ * works fine for patching a SMP kernel for UP.
+ *
+ * The SMP alternative tables can be kept after boot and contain both
+ * UP and SMP versions of the instructions to allow switching back to
+ * SMP at runtime, when hotplugging in a new CPU, which is especially
+ * useful in virtualized environments.
+ *
+ * The very common lock prefix is handled as special case in a
+ * separate table which is a pure address list without replacement ptr
+ * and size information. That keeps the table sizes small.
+ */
+
+#ifdef CONFIG_SMP
+#define LOCK_PREFIX \
+ ".section .smp_locks,\"a\"\n" \
+ " .align " ALT_ALIGN "\n" \
+ " " ALT_ASMPTR " 661f\n" /* address */ \
+ ".previous\n" \
+ "661:\n\tlock; "
+#else /* ! CONFIG_SMP */
+#define LOCK_PREFIX ""
+#endif
+
+/* This must be included *after* the definition of LOCK_PREFIX */
+#include
+
+extern void alternative_instructions(void);
+extern void apply_alternatives(struct alt_instr *start, struct alt_instr *end);
+
+struct module;
+
+#ifdef CONFIG_SMP
+extern void alternatives_smp_module_add(struct module *mod, char *name,
+ void *locks, void *locks_end,
+ void *text, void *text_end);
+extern void alternatives_smp_module_del(struct module *mod);
+extern void alternatives_smp_switch(int smp);
+#else
+static inline void alternatives_smp_module_add(struct module *mod, char *name,
+ void *locks, void *locks_end,
+ void *text, void *text_end) {}
+static inline void alternatives_smp_module_del(struct module *mod) {}
+static inline void alternatives_smp_switch(int smp) {}
+#endif
+
+#endif
+
+/*
+ * Alternative instructions for different CPU types or capabilities.
+ *
+ * This allows to use optimized instructions even on generic binary
+ * kernels.
+ *
+ * length of oldinstr must be longer or equal the length of newinstr
+ * It can be padded with nops as needed.
+ *
+ * For non barrier like inlines please define new variants
+ * without volatile and memory clobber.
+ */
+#define alternative(oldinstr, newinstr, feature) \
+ asm volatile ("661:\n\t" oldinstr "\n662:\n" \
+ ".section .altinstructions,\"a\"\n"\
+ " .align " ALT_ALIGN " \n" \
+ " " ALT_ASMPTR " 661b\n" /* label */ \
+ " " ALT_ASMPTR " 663f\n"
Re: [PATCH] x86: merge asm-x86/alternative.h
On Fri, Jan 18, 2008 at 12:02:05AM -0500, H. Peter Anvin wrote: > Meh. Waste of my time, you've already done it, but the patch wasn't on linux-kernel, so I didn't notice. --Kyle -- 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] x86_64: remove redundant cpu_has_ definitions
On Fri, Jan 18, 2008 at 12:04:54AM -0500, H. Peter Anvin wrote: > Unnecessary. These overrides are only needed for the anticases (known to > be zero) or for some special hacks. > Cool, guess that means a bunch of them can go... > Stuff that have proper CPUID bits get these defined as constants via the > REQUIRED_MASK macros. > PSE, PGE, XMM, XMM2, and FXSR are defined as required features, and will be optimized to a constant at compile time. Remove their redundant definitions. Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> --- a/include/asm-x86/cpufeature.h +++ b/include/asm-x86/cpufeature.h @@ -195,21 +195,6 @@ #undef cpu_has_centaur_mcr #define cpu_has_centaur_mcr0 -#undef cpu_has_pse -#define cpu_has_pse1 - -#undef cpu_has_pge -#define cpu_has_pge1 - -#undef cpu_has_xmm -#define cpu_has_xmm1 - -#undef cpu_has_xmm2 -#define cpu_has_xmm2 1 - -#undef cpu_has_fxsr -#define cpu_has_fxsr 1 - #endif /* CONFIG_X86_64 */ #endif /* _ASM_X86_CPUFEATURE_H */ -- 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] x86: make clflush a required feature on x86_64
On Fri, Jan 18, 2008 at 06:53:53AM +0100, Andi Kleen wrote: > One problem that we had in the past is that some simulators > only implement the absolutely minimum feature set and you > might have well broken one of these with this. Yeah, true. Please ignore the patch folks. cheers, Kyle -- 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 2/6] drivers/parisc/ccio-dma.c: clean up remove duplicated headers
On Fri, Dec 14, 2007 at 02:56:46PM -0400, Francisco Alecrim wrote: > Remove duplicated headers in drivers/parisc/ccio-dma.c: > drivers/parisc/ccio-dma.c: linux/proc_fs.h is included more than once. > Seems kind of pointless, but I'll apply it. cheers, Kyle -- 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] ia64: Avoid unnecessary TLB flushes when allocating memory
On Tue, Dec 18, 2007 at 10:05:45AM +0900, KAMEZAWA Hiroyuki wrote:
> On Thu, 13 Dec 2007 15:03:07 +
>
> > + if (mm != active_mm) {
> > + /* Restore region IDs for mm */
> > + if (mm && active_mm) {
> > + activate_context(mm);
> > + } else {
> > + flush_tlb_all();
> > + return;
> > + }
> > }
> should be
>
platform_global_tlb_purge is already (and afaict, only) called under
preempt_disable already. then again, the sn2 global_tlb_purge
does it, so possibly for completeness sake it should be added here as
well?
regards, kyle
--
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: [ia64] BUG: sleeping in atomic
On Wed, Dec 19, 2007 at 04:54:30PM +1100, David Chinner wrote:
> [ 5667.086055] BUG: sleeping function called from invalid context at
> kernel/fork.c:401
>
The problem is that mmput is called under the read_lock by
find_thread_for_addr... The comment above seems to indicate that gdb
needs to be able to access any child tasks register backing store
memory... This seems pretty broken.
cheers, Kyle
---
Who knows, maybe gdb is saner now?
diff --git a/arch/ia64/kernel/ptrace.c b/arch/ia64/kernel/ptrace.c
index 2e96f17..b609704 100644
--- a/arch/ia64/kernel/ptrace.c
+++ b/arch/ia64/kernel/ptrace.c
@@ -1418,7 +1418,7 @@ asmlinkage long
sys_ptrace (long request, pid_t pid, unsigned long addr, unsigned long data)
{
struct pt_regs *pt;
- unsigned long urbs_end, peek_or_poke;
+ unsigned long urbs_end;
struct task_struct *child;
struct switch_stack *sw;
long ret;
@@ -1430,23 +1430,12 @@ sys_ptrace (long request, pid_t pid, unsigned long
addr, unsigned long data)
goto out;
}
- peek_or_poke = (request == PTRACE_PEEKTEXT
- || request == PTRACE_PEEKDATA
- || request == PTRACE_POKETEXT
- || request == PTRACE_POKEDATA);
- ret = -ESRCH;
- read_lock(&tasklist_lock);
- {
- child = find_task_by_pid(pid);
- if (child) {
- if (peek_or_poke)
- child = find_thread_for_addr(child, addr);
- get_task_struct(child);
- }
- }
- read_unlock(&tasklist_lock);
- if (!child)
+ child = ptrace_get_task_struct(pid);
+ if (IS_ERR(child)) {
+ ret = PTR_ERR(child);
goto out;
+ }
+
ret = -EPERM;
if (pid == 1) /* no messing around with init! */
goto out_tsk;
--
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: diff command line?
On Sat, Mar 05, 2005 at 10:48:00AM -0500, Gene Heskett wrote: > Greetings; > > What are the options normally used to generate a diff for public > consumption on this list? > > The - stuffs is what I'm looking for. > linux/Documentation/SubmittingPatches - 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: PAGE_SIZE on 64bit and 32bit machines
On Mon, Nov 12, 2007 at 05:58:08PM +0200, Yoav Artzi wrote: > Looking at the source, I see: > > #ifdef CONFIG_4KSTACKS > #define THREAD_SIZE(4096) > #else > #define THREAD_SIZE(8192) > #endif > > > So if I configure the option CONFIG_4KSTACK, I will get a 4KB kernel > stack. Am I missing something here? > This is only on i386 (32-bit x86...)[1] On x86-64, we have 8K kernel stacks (THREAD_ORDER 1), and 16K irqstacks (IRQSTACK_ORDER 2). The relevant defines are found in for x86_64, and for i386. Cheers, Kyle 1. That is, stack size is only configurable on 32bit. - 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 2/9] AOUT: Mark arches that support A.OUT format [try #6]
On Wed, Nov 14, 2007 at 12:18:42AM +, David Howells wrote: > Mark arches that support A.OUT format by including the following in their > master Kconfig files: > > config ARCH_SUPPORTS_AOUT > def_bool y > ... > Signed-off-by: David Howells <[EMAIL PROTECTED]> > big Acked-by: Kyle McMartin <[EMAIL PROTECTED]> to the whole set arch-dependant set... Thanks, Kyle - 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 2/9] AOUT: Mark arches that support A.OUT format [try #6]
On Tue, Nov 13, 2007 at 07:23:46PM -0500, Kyle McMartin wrote: > On Wed, Nov 14, 2007 at 12:18:42AM +, David Howells wrote: > > Mark arches that support A.OUT format by including the following in their > > master Kconfig files: > > > > config ARCH_SUPPORTS_AOUT > > def_bool y > > > ... > > Signed-off-by: David Howells <[EMAIL PROTECTED]> > > > > big Acked-by: Kyle McMartin <[EMAIL PROTECTED]> to the whole set > arch-dependant set... > except parisc doesn't support a.out :P cheers, kyle - 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] Only show RESOURCES_64BIT on relevant architectures
To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT! I *think* I have the logic of this right... Anyway, I was annoyed by having to do the bloody ugly casts to unsigned long long in arch-specific code. As near as I can tell, we only want this selectable in the case of PAE on x86, and some random PPC and MIPS embedded boards. For everyone else, it should be whatever the value of 64BIT is. And I can be happy and continue using unsigned long and going about my merry business. Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> --- diff --git a/mm/Kconfig b/mm/Kconfig index c070ec0..c25a838 100644 --- a/mm/Kconfig +++ b/mm/Kconfig @@ -172,6 +172,7 @@ config MIGRATION config RESOURCES_64BIT bool "64 bit Memory and IO resources (EXPERIMENTAL)" if (!64BIT && EXPERIMENTAL) + depends on (MIPS || PPC32 || X86_PAE) || 64BIT default 64BIT help This option allows memory and IO resources to be 64 bit. - 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] Only show RESOURCES_64BIT on relevant architectures
On Sun, Oct 28, 2007 at 06:09:49PM -0700, David Miller wrote: > From: Kyle McMartin <[EMAIL PROTECTED]> > Date: Sun, 28 Oct 2007 16:15:49 -0400 > > > To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT! > > > > I *think* I have the logic of this right... Anyway, I was annoyed by > > having to do the bloody ugly casts to unsigned long long in > > arch-specific code. As near as I can tell, we only want this selectable > > in the case of PAE on x86, and some random PPC and MIPS embedded boards. > > > > For everyone else, it should be whatever the value of 64BIT is. > > > > And I can be happy and continue using unsigned long and going about my > > merry business. > > > > Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]> > > 32-bit sparc has 36-bit physical addresses and thus needs > 64-bit resources too I didn't realize this, since it wasn't set in any of the configs, or select-ed by any of the Kconfig. Will add this in the next go 'round. Cheers, Kyle - 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] Only show RESOURCES_64BIT on relevant architectures
On Mon, Oct 29, 2007 at 08:10:10AM +, Russell King wrote: > On Sun, Oct 28, 2007 at 04:15:49PM -0400, Kyle McMartin wrote: > > To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT! > > > > I *think* I have the logic of this right... Anyway, I was annoyed by > > having to do the bloody ugly casts to unsigned long long in > > arch-specific code. As near as I can tell, we only want this selectable > > in the case of PAE on x86, and some random PPC and MIPS embedded boards. > > May I suggest trying: > > $ grep RESOURCES_64BIT=y arch/*/configs/* arch/*/defconfig > > to locate those architectures which use this? > > FYI, that grep says ARM, ia64, mips, parisc, powerpc, PPC, s390, sparc64, > and x86 use this feature. > It would be nice if the people who actually needed it would have select-ed it. That's how I built the list. Most of the other examples you listed are obviously 64bit... there should be more occurances, but I guess they've (alpha, for instance) not updated their defconfig in a dogs age. Anyway, sorry I didn't notice ARM. I'll add it to the list on the next round. Regards, Kyle (but seriously, this should be select-ed, not just set in a defconfig somewhere...) - 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][RESEND] Semi-pointless NULL test in uli526x driver
On Sat, Aug 04, 2007 at 08:32:12PM +0200, Jesper Juhl wrote:
> I don't think dev_id can ever actually be NULL, so the whole block
> inside "if (!dev) {" could probably just go away. But I guess
> there's a good reason someone put that ULI526X_DBUG() in there - and
> if 'dev_id' /can/ actually be NULL then it's nice to have and in
> that case this patch actually fixes a possible crash (hence the
> version number update).
It *can* be null, in the case of another handler being registered on the
same irq number, passing NULL for the cookie.
Ack. Will apply.
Regards,
Kyle
-
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: Few interrupts with NO_HZ
On Mon, Aug 06, 2007 at 12:52:36PM +0200, Jan Engelhardt wrote: >CPU0 > 0:282 IO-APIC-edge timer Look at the LOC line. - 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 14/24] make atomic_read() behave consistently on parisc
On Thu, Aug 09, 2007 at 10:01:54AM -0400, Chris Snook wrote: > From: Chris Snook <[EMAIL PROTECTED]> > > Purify volatile use for atomic[64]_t on parisc. > > Signed-off-by: Chris Snook <[EMAIL PROTECTED]> > Sure, why not. ACKed-by: Kyle McMartin <[EMAIL PROTECTED]> - 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: [TULIP] Need new maintainer
On Mon, Jul 30, 2007 at 01:04:13PM -0600, Valerie Henson wrote: > The Tulip network driver needs a new maintainer! I no longer have > time to maintain the Tulip network driver and I'm stepping down. Jeff > Garzik would be happy to get volunteers. > Since I already take care of a major consumer of these devices (parisc, which pretty much all have tulip) I'm willing to take care of this. Alternately, Grant is probably willing. Cheers, Kyle - 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: inotify and /proc/
On Mon, Jul 30, 2007 at 10:40:59PM -0500, Joseph Pingenot wrote: > From Al Viro on Tuesday, 31 July, 2007: > >On Mon, Jul 30, 2007 at 10:31:13PM -0500, Joseph Pingenot wrote: > >> >From Joseph Pingenot on Monday, 30 July, 2007: > >> >From Al Viro on Tuesday, 31 July, 2007: > >> >>On Mon, Jul 30, 2007 at 09:16:16PM -0500, Joseph Pingenot wrote: > >> >>> I was trying to use inotify to watch process changes (especially > >> >>> process > >> >>> termination) by watching /proc/. > >> >>> Sadly, although I could see something reading various files, nothing > >> >>> was issued when the process I was watching exited and the directory > >> >>> went away. > >> >>> Is this intentional, or a bug? > >> >>It's a bug you intend to introduce in your program... IOW, don't > >> >>do that. > >> >More background, please? > >> >What's the way to check for a process exiting without spinning? > >> I should also specify that the process being waited on is not a > >> child process-it's just some other process on the system. > >Umm... Any details on intended use? IOW, is that "I want to write > >an utility that would wait for given PID to exit, just for the hell > >of it" or is there something you are trying to implement using that? > > I'm trying to implement pwait. It blocks until a specified PID exits, > and then it exits. > ptrace with options set to PTRACE_O_TRACEEXIT? --Kyle - 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] parisc: fix sg_page() fallout
On Tue, Oct 23, 2007 at 09:30:35AM +0200, Jens Axboe wrote: > > arch/parisc/kernel/pci-dma.c:545: error: 'struct scatterlist' has no member > > named 'page' > > Applied. > Thanks! Cheers, Kyle - 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: Could convert a buffer that allocated by vmalloc to pages?
On Tue, Jan 23, 2007 at 10:15:33PM +0800, Yu-Chen Wu wrote: > printk(KERN_INFO "vmalloc_to_page tpage :%x\n",tpage); > //===info of dmesg== > [ 1561.768492] page allocated:60ea9000 > [ 1561.768497] vmalloc_to_page tpage :7fcf7e18 > > Why the page address get from vmalloc_to_page is different with the first > page address of the vm_struct (73d65000)? > Memory returned by vmalloc is only virtually contiguous, not physically contiguous. If you're allocating memory for DMA, see the interface documented in Documentation/DMA-mapping.txt for more information. -- Kyle - 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: que: How can we Eliminate the DMA Zone from the kernel?
On Thu, Jan 25, 2007 at 12:56:30PM +, Seetharam Dharmosoth wrote: > Hi, > > Want to remove DMA zone the from the Linux Kernel. > (Don't want to use DMA Zone, because i am not > using ISA bus, am using PCI bus. So, I don't need > this) > Just because you don't need ISA, doesn't mean you don't need ZONE_DMA. Various PCI cards have limitations on what addresses they can DMA to (24 bits on some old PCI sound cards iirc, and more recently a 30 bit DMA limitation on some Broadcom networking equipment.) - 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/
[git patches] parisc updates for 2.6.20
I know I missed the -rc1 deadline. Sorry about that. Unless Andrew has any objections, I'd like to ask for a merge of the parisc-2.6 git tree... The following changes since commit 62d0cfcb27cf755cebdc93ca95dabc83608007cd: Linus Torvalds (1): Linux 2.6.20 are found in the git repository at: /pub/scm/linux/kernel/git/kyle/parisc-2.6.git Carlos O'Donell Jr (2): [PARISC] Reorder syscalls to match unistd.h [PARISC] Compat signal fixes for 64-bit parisc David Howells (1): WorkStruct: Fix up some PA-RISC work items Grant Grundler (1): [PARISC] Remove GCC_VERSION usage as suggested by Adrian Bunk Guy Martin (1): [PARISC] Add missing statfs64 and fstatfs64 syscalls Helge Deller (27): [PARISC] Show more memory information and memory layout at bootup [PARISC] avoid compiler warnings when compiling 64bit [TRIVIAL] [PARISC] Fix module.c printk message, add missing ')' [PARISC] lasi_82596: use BUILD_BUG_ON() and constify static array [PARISC] Generic BUG [PARISC] fix build for WARN_ON() when CONFIG_DEBUG_BUGVERBOSE=y [PARISC] whitespace cleanups and unify 32/64bit user-access assembler inlines [PARISC] fix fixup declarations for 32bit and use CONFIG_64BIT [PARISC] dump stack backtrace on BUG() and add syslog-levels to printk()s [PARISC] add missing syscalls for vmsplice, move_pages, getcpu & epoll_pwait [PARISC] Use fstatat64 instead of newfstatat syscall [PARISC] a and b in "break a,b" message were swapped [PARISC] GENERIC_TIME patchset for parisc [PARISC] disable cr16 clocksource when multiple CPUs are online [PARISC] Convert soft power switch driver to kthread [PARISC] detect recursive kernel crash earlier [PARISC] use less assembler statements in syscall path [PARISC] implement standard ENTRY(), END() and ENDPROC() [PARISC] Fixes /proc/cpuinfo cache output on B160L [PARISC] fix ENTRY() and ENDPROC() for 64bit-parisc [PARISC] more ENTRY(), ENDPROC(), END() conversions [PARISC] add ASM_EXCEPTIONTABLE_ENTRY() macro [PARISC] use CONFIG_64BIT instead of __LP64__ [PARISC] convert to use CONFIG_64BIT instead of __LP64__ [PARISC] add ENTRY()/ENDPROC() and simplify assembly of HP/UX emulation code [PARISC] do not export get_register/set_register [PARISC] fix section mismatch warnings in harmony sound driver Kyle McMartin (20): [PARISC] Unbreak discontigmem mem_init() [PARISC] Reserve 1GB of space for vmalloc/tmpalias space on parisc64 [PARISC] bloody printf fmt string warnings [PARISC] Remove duplicate PDC_PAT_CELL defines [PARISC] Move spinlock_t out of struct cpu_data [PARISC] Fix thinko in cpu_data.lock removal Merge branch 'parisc' from /home/kyle/repos/parisc-2.6.git [PARISC] "Fix" circular includes [PARISC] use fls_long in irq.c [PARISC] Add TIF_RESTORE_SIGMASK support [PARISC] display parisc device modalias in sysfs [PARISC] move parisc_device_id definition to mod_devicetable.h [PARISC] generate modalias for parisc_device_id tables [PARISC] rename *_ANY_ID to PA_*_ANY_ID in the exported header [PARISC] factor syscall_restart code out of do_signal [PARISC] clean up debugging printks in smp.c [PARISC] kill ENTRY_SYS_CPUS [PARISC] fix sys_rt_sigqueueinfo Revert "[PARISC] Optimize TLB flush on SMP systems" [PARISC] Use symbolic last syscall in __NR_Linux_syscalls Mariusz Kozlowski (1): [PARISC] pdcpat remove extra brackets Matthew Wilcox (13): [PARISC] Delete arch/parisc/mm/kmap.c again [PARISC] parisc-agp: Fix integer/pointer warning [PARISC] sparse fixes [PARISC] more sparse fixes [PARISC] Fix PCI bus numbering in the presence of Cardbus bridges [PARISC] Make Lasi Ethernet depend on GSC only PA-RISC: Fix bogus warnings from modpost [PARISC] Only write to memory in test_and_set_bit/test_and_clear_bit if we're [PARISC] Add prototypes for flush_user_dcache_range and flush_user_icache_range [PARISC] Remove sched.h from uaccess.h on parisc [PARISC] Fix show_stack() when we can't kmalloc [PARISC] lba_pci format warnings Revert "[PATCH] make kernel/signal.c:kill_proc_info() static" Mike Frysinger (1): use __u64 rather than u64 in parisc statfs structs Randolph Chung (2): [PARISC] Optimize TLB flush on SMP systems [PARISC] Clean up the cache and tlb headers Randy Dunlap (1): parisc: fix module_param iommu permission Ryan Bradetich (9): [PARISC] Fix ccio_request_resource when CONFIG_IOMMU_CCIO is not defined [PARISC] HPPB bus updates for E-Class systems [PARISC] [MUX] Mux driver bug fix [PARISC] [MUX] Mux driver updates [PARISC] [MUX] Claim resources for the Mux drive
Re: [PATCH] dma-mapping-broken.h: flesh-out DMA API stubs
On Fri, Feb 23, 2007 at 07:13:32AM +0100, Heiko Carstens wrote: > How about this for telling that an architecture doesn't support DMA? > At least we could get rid of dma-mapping-broken.h and don't need to > compile some afterwards dead code. > > Signed-off-by: Heiko Carstens <[EMAIL PROTECTED]> This like a lot better of an idea than stubbing out things which should never be built in the first place... Cheers, Kyle - 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: why is asm-parisc/ioctl.h subtly different from asm-generic/ioctl.h?
On Sat, Feb 24, 2007 at 05:34:15AM -0500, Robert P. J. Day wrote:
>
> just noticed that parisc's ioctl.h file, rather than simply
> including asm-generic/ioctl.h, has its own copy whose sole
> (meaningful) difference from the generic one is:
>
> $ diff include/{asm-generic,asm-parisc}/ioctl.h
> ...
> 41,42c54,55
> < #define _IOC_WRITE1U
> < #define _IOC_READ 2U
> ---
> > #define _IOC_WRITE2U
> > #define _IOC_READ 1U
>
> so parisc is identical except that it switches the meaning of the
> direction field? is there a reason for this? just curious.
>
HP-UX compatibility.
#define IOC_OUT 0x4000
#define IOC_IN (int)0x8000
PS: It would be wise to ask questions on the pertinent mailing lists...
--Kyle
-
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: ioread32 endianess.
On Mon, Feb 26, 2007 at 06:36:05PM +0300, Alexey Zaytsev wrote: > Hello. > > May I ask you, guys, if ioread32 and his friends should treat the data > as host-endian or bus-endian? E.g, should the data read from PCI on a > big-endian host be byte swapped or not? > It should be in bus-endian. This is why ioreadXbe() exist. Cheers, Kyle - 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/
resource_size_t printk whinging
I submitted this patch a while ago, but nobody commented on it.
All these casts of resource_size_t to (unsigned long long) seem horribly
wasteful to me...
Of course, to add a new format qualifier, we lose out on checking the format
string by gcc... Nowadays, this role can be done by sparse.
(Or perhaps gcc can be extended such that a string of allowable qualifiers
can be passed along in kernel.h, that would just be super...)
This is mostly just to provoke a little bit of further discussion.
Signed-off-by-but-not-really-much-point: Kyle McMartin
<[EMAIL PROTECTED]>
---
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 9ddf25c..a79985d 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -107,25 +107,16 @@ extern unsigned long simple_strtoul(const char *,char
**,unsigned int);
extern long simple_strtol(const char *,char **,unsigned int);
extern unsigned long long simple_strtoull(const char *,char **,unsigned int);
extern long long simple_strtoll(const char *,char **,unsigned int);
-extern int sprintf(char * buf, const char * fmt, ...)
- __attribute__ ((format (printf, 2, 3)));
-extern int vsprintf(char *buf, const char *, va_list)
- __attribute__ ((format (printf, 2, 0)));
-extern int snprintf(char * buf, size_t size, const char * fmt, ...)
- __attribute__ ((format (printf, 3, 4)));
-extern int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
- __attribute__ ((format (printf, 3, 0)));
-extern int scnprintf(char * buf, size_t size, const char * fmt, ...)
- __attribute__ ((format (printf, 3, 4)));
-extern int vscnprintf(char *buf, size_t size, const char *fmt, va_list args)
- __attribute__ ((format (printf, 3, 0)));
-extern char *kasprintf(gfp_t gfp, const char *fmt, ...)
- __attribute__ ((format (printf, 2, 3)));
-
-extern int sscanf(const char *, const char *, ...)
- __attribute__ ((format (scanf, 2, 3)));
-extern int vsscanf(const char *, const char *, va_list)
- __attribute__ ((format (scanf, 2, 0)));
+extern int sprintf(char * buf, const char * fmt, ...);
+extern int vsprintf(char *buf, const char *, va_list);
+extern int snprintf(char * buf, size_t size, const char * fmt, ...);
+extern int vsnprintf(char *buf, size_t size, const char *fmt, va_list args);
+extern int scnprintf(char * buf, size_t size, const char * fmt, ...);
+extern int vscnprintf(char *buf, size_t size, const char *fmt, va_list args);
+extern char *kasprintf(gfp_t gfp, const char *fmt, ...);
+
+extern int sscanf(const char *, const char *, ...);
+extern int vsscanf(const char *, const char *, va_list);
extern int get_option(char **str, int *pint);
extern char *get_options(const char *str, int nints, int *ints);
@@ -140,16 +131,12 @@ extern struct pid *session_of_pgrp(struct pid *pgrp);
extern void dump_thread(struct pt_regs *regs, struct user *dump);
#ifdef CONFIG_PRINTK
-asmlinkage int vprintk(const char *fmt, va_list args)
- __attribute__ ((format (printf, 1, 0)));
-asmlinkage int printk(const char * fmt, ...)
- __attribute__ ((format (printf, 1, 2)));
+asmlinkage int vprintk(const char *fmt, va_list args);
+asmlinkage int printk(const char * fmt, ...);
#else
-static inline int vprintk(const char *s, va_list args)
- __attribute__ ((format (printf, 1, 0)));
+static inline int vprintk(const char *s, va_list args);
static inline int vprintk(const char *s, va_list args) { return 0; }
-static inline int printk(const char *s, ...)
- __attribute__ ((format (printf, 1, 2)));
+static inline int printk(const char *s, ...);
static inline int printk(const char *s, ...) { return 0; }
#endif
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index b025864..7a0fd29 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -343,7 +343,8 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
/* get the conversion qualifier */
qualifier = -1;
if (*fmt == 'h' || *fmt == 'l' || *fmt == 'L' ||
- *fmt =='Z' || *fmt == 'z' || *fmt == 't') {
+ *fmt == 'Z' || *fmt == 'z' || *fmt == 't' ||
+ *fmt == 'r' || *fmt == 'R') {
qualifier = *fmt;
++fmt;
if (qualifier == 'l' && *fmt == 'l') {
@@ -477,6 +478,8 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
va_list args)
num = (unsigned short) va_arg(args, int);
if (flags & SIGN)
num = (signed short) num;
+ } else if (qualifier == 'R' || qualifier == 'R') {
+ num = va_arg(args, resource_size_t);
} else {
num = va_arg(args, unsigned int);
Re: resource_size_t printk whinging
On Tue, Feb 27, 2007 at 12:02:50PM +0100, Geert Uytterhoeven wrote:
> But we don't run sparse on every build. We do run gcc (a lot).
>
We probably could, in theory...
> > --- a/lib/vsprintf.c
> > +++ b/lib/vsprintf.c
> > @@ -477,6 +478,8 @@ int vsnprintf(char *buf, size_t size, const char *fmt,
> > va_list args)
> > num = (unsigned short) va_arg(args, int);
> > if (flags & SIGN)
> > num = (signed short) num;
> > + } else if (qualifier == 'R' || qualifier == 'R') {
> ^ ^
> One of them must be lowercase `r'.
>
Duh. I'm a muppet.
-
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: ioread32 endianess.
On Tue, Feb 27, 2007 at 03:31:20PM +0300, Alexey Zaytsev wrote: > Than how should one write a portable endian-independent driver? Should > I wrap ioread32 with an le32_to_cpu? > PCI is always little endian, unless it's not. In which case you're probably dealing with a graphics card which likely has some kind of palindromic register which you can read and write to set the endianness of the host interface. Whoo. Run on sentence. - 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: ioread32 endianess.
On Tue, Feb 27, 2007 at 08:20:21AM -0500, Kyle McMartin wrote:
> PCI is always little endian, unless it's not. In which case you're probably
> dealing with a graphics card which likely has some kind of palindromic
> register which you can read and write to set the endianness of the host
> interface. Whoo. Run on sentence.
>
Perhaps we should have a Documentation/ entry for this...
io(read|write){8,16,32} are the "pci iomap" functions (see
asm-generic/iomap.h) they always byteswap so the value is little endian.
io(read|write){8,16,32}be are sister functions added to deal with big
endian busses. They always byteswap so the value is in big endian.
Both these previous functions can handle using a cookie based on an IO port
range, or an MMIO region.
(read|write){b,w,l} are the old style MMIO-mapped accessors. They also always
byteswap so the value is in little endian. There is no big endian equivalent
for the generic case.
__raw_(read|write){b,w,l} are also old style accessors. They always operate
in host endianness.
The above are (AFAIK) the only functions guaranteed to exist for MMIO.
Of course, most platforms either provide (in|out){b,w,l} or don't support
Port IO as well, but MMIO is the really complicated case.
In any event, should shed a bit more light on using
these.
Cheers,
Kyle M.
-
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/
