Re: [PATCH v2 -mm 6/7] DCA: Add Direct Cache Access driver
On Thu, 23 Aug 2007 17:15:22 -0700 Shannon Nelson wrote:
> Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
> Acked-by: David S. Miller <[EMAIL PROTECTED]>
> ---
>
> drivers/Kconfig |2 +
> drivers/Makefile|1
> drivers/dca/Kconfig | 11 +++
> drivers/dca/Makefile|2 +
> drivers/dca/dca-core.c | 168
> +++
> drivers/dca/dca-sysfs.c | 88 +
> include/linux/dca.h | 47 +
> 7 files changed, 319 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/dca/Kconfig b/drivers/dca/Kconfig
> new file mode 100644
> index 000..d901615
> --- /dev/null
> +++ b/drivers/dca/Kconfig
> @@ -0,0 +1,11 @@
> +#
> +# DCA server configuration
> +#
> +
> +config DCA
> + tristate "DCA support for clients and providers"
> + ---help---
> + This is a server to help modules that want to use Direct Cache
> + Access to find DCA providers that will supply correct CPU tags.
> + default m
We conventionally put help text last in each config entry.
& Help text should be indented by 1 tab + 2 spaces.
> diff --git a/drivers/dca/dca-core.c b/drivers/dca/dca-core.c
> new file mode 100644
> index 000..c0ff9bd
> --- /dev/null
> +++ b/drivers/dca/dca-core.c
> @@ -0,0 +1,168 @@
> +/*
> + * Copyright(c) 2007 Intel Corporation. All rights reserved.
> + *
> +/*
> + * This driver supports an interface for DCA clients and providers to meet.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +MODULE_LICENSE("GPL");
> +
> +/* For now we're assuming a single, global, DCA provider for the system. */
> +
> +static DEFINE_SPINLOCK(dca_lock);
> +
> +struct dca_provider *global_dca = NULL;
Can global_dca be static, or is it used in other source files?
It would be good to have all of these global/exported interfaces
documented somewhere. Did I miss it in another file?
If not, you could use kernel-doc to add inline function docs.
See Documentation/kernel-doc-nano-HOWTO.txt.
> +u8 dca_get_tag(int cpu)
> +{
> + if (!global_dca)
> + return -ENODEV;
> + return global_dca->ops->get_tag(global_dca, cpu);
> +}
> +EXPORT_SYMBOL(dca_get_tag);
> +
> +
> +static BLOCKING_NOTIFIER_HEAD(dca_provider_chain);
> +
> +
> +static int __init dca_init(void)
> +{
> + int err;
> +
> + err = dca_sysfs_init();
> + if (err)
> + return err;
> + return 0;
or just (in all cases):
return err;
> +}
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
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] PS3: Update MAINTAINERS
Hi Matt, All, > The drawback is mostly in getting the rejection/moderation message. > > Whitelisting is fine. If you configure the list to not send the > moderation warning to legitimate non-subscribers, you'll eliminate 99% > of the annoyance. Good call, have changed the configuration accordingly. Thanks for the feedback all :) Cheers, Hugh - 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] Fix preemptible lazy mode bug
I recently sent off a fix for lazy vmalloc faults which can happen under
paravirt when lazy mode is enabled. Unfortunately, I jumped the gun a
bit on fixing this. I neglected to notice that since the new call to
flush the MMU update queue is called from the page fault handler, it can
be pre-empted. Both VMI and Xen use per-cpu variables to track lazy
mode state, as all previous calls to set, disable, or flush lazy mode
happened from a non-preemptable state.
I have no idea how to convincingly produce the problem, as generating a
kernel pre-emption at the required point is, um, difficult, but it is
most certainly a real possibility, and potentially more likely than the
bug I fixed originally.
Rusty, you may have to modify lguest code if you use lazy mode and rely
on per-cpu variables during the callout for paravirt_ops.set_lazy_mode.
I have tested as best as I can, and am trying to write a suite destined
for LTP which will help catch and debug these issues.
Zach
Since set_lazy_mode(LAZY_MODE_FLUSH) is now called from the page fault
handler, it can potentially happen in a preemptible state. We therefore
must make all lazy mode paravirt-ops handlers non-preemptible.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED](none)>
---
arch/i386/kernel/vmi.c| 14 ++
arch/i386/xen/enlighten.c |4 +++-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/i386/kernel/vmi.c b/arch/i386/kernel/vmi.c
index 18673e0..9e669cb 100644
--- a/arch/i386/kernel/vmi.c
+++ b/arch/i386/kernel/vmi.c
@@ -555,21 +555,27 @@ vmi_startup_ipi_hook(int phys_apicid, unsigned long start_eip,
static void vmi_set_lazy_mode(enum paravirt_lazy_mode mode)
{
static DEFINE_PER_CPU(enum paravirt_lazy_mode, lazy_mode);
+ int cpu;
+ enum paravirt_lazy_mode cur_mode;
if (!vmi_ops.set_lazy_mode)
return;
+ cpu = get_cpu();
+ cur_mode = per_cpu(lazy_mode, cpu);
+
/* Modes should never nest or overlap */
- BUG_ON(__get_cpu_var(lazy_mode) && !(mode == PARAVIRT_LAZY_NONE ||
- mode == PARAVIRT_LAZY_FLUSH));
+ BUG_ON(cur_mode && !(mode == PARAVIRT_LAZY_NONE ||
+ mode == PARAVIRT_LAZY_FLUSH));
if (mode == PARAVIRT_LAZY_FLUSH) {
vmi_ops.set_lazy_mode(0);
- vmi_ops.set_lazy_mode(__get_cpu_var(lazy_mode));
+ vmi_ops.set_lazy_mode(cur_mode);
} else {
vmi_ops.set_lazy_mode(mode);
- __get_cpu_var(lazy_mode) = mode;
+ per_cpu(lazy_mode, cpu) = mode;
}
+ put_cpu();
}
static inline int __init check_vmi_rom(struct vrom_header *rom)
diff --git a/arch/i386/xen/enlighten.c b/arch/i386/xen/enlighten.c
index f0c3751..2dafb8a 100644
--- a/arch/i386/xen/enlighten.c
+++ b/arch/i386/xen/enlighten.c
@@ -251,7 +251,7 @@ static void xen_halt(void)
static void xen_set_lazy_mode(enum paravirt_lazy_mode mode)
{
- BUG_ON(preemptible());
+ get_cpu();
switch (mode) {
case PARAVIRT_LAZY_NONE:
@@ -267,11 +267,13 @@ static void xen_set_lazy_mode(enum paravirt_lazy_mode mode)
/* flush if necessary, but don't change state */
if (x86_read_percpu(xen_lazy_mode) != PARAVIRT_LAZY_NONE)
xen_mc_flush();
+ put_cpu();
return;
}
xen_mc_flush();
x86_write_percpu(xen_lazy_mode, mode);
+ put_cpu();
}
static unsigned long xen_store_tr(void)
--
1.4.4.4
Re: [patch 1/1] md: Software Raid autodetect dev list not array
I'll look at this again on my next weekend and make the changes.
If it exists I'd rather it functioned without issues. My initrds are
created by gentoo's genkernel script, which places dmraid on them.
I'm not sure if it supports autodetect or not.
On 8/24/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> On Wednesday August 22, [EMAIL PROTECTED] wrote:
> > From: Michael J. Evans <[EMAIL PROTECTED]>
> >
> > In current release kernels the md module (Software RAID) uses a static array
> > (dev_t[128]) to store partition/device info temporarily for autostart.
> >
> > This patch replaces that static array with a list.
>
> I must admit that I'm not very keen on this.
> I would much rather that in-kernel autodetect were deprecated rather
> than enhanced.
>
> Just use 'mdadm' in an initrd, or during normal boot, to assemble all
> your arrays.
>
> However.
>
> > =
> > --- linux/drivers/md/md.c.orig2007-08-21 03:19:42.511576248 -0700
> > +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
> > @@ -24,4 +24,6 @@
> >
> > + - autodetect dev list not array: Michael J. Evans <[EMAIL PROTECTED]>
> > +
> > This program is free software; you can redistribute it and/or modify
> > it under the terms of the GNU General Public License as published by
> > the Free Software Foundation; either version 2, or (at your option)
> > @@ -5752,13 +5754,25 @@ void md_autodetect_dev(dev_t dev)
> > * Searches all registered partitions for autorun RAID arrays
> > * at boot time.
> > */
> > -static dev_t detected_devices[128];
> > -static int dev_cnt;
> > +
> > +static LIST_HEAD(all_detected_devices);
> > +/* FIXME : Should these 4 lines instead go in to include/linux/raid/md_k.h
> > ?
>
> No. No-one outside this file uses them, so they are fine where they
> are.
>
> > */
> > +struct detected_devices_node {
> > + struct list_head list;
> > + dev_t dev;
> > +};
> >
> > void md_autodetect_dev(dev_t dev)
> > {
> > - if (dev_cnt >= 0 && dev_cnt < 127)
> > - detected_devices[dev_cnt++] = dev;
> > + struct detected_devices_node *node_detected_dev;
> > + node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
> > + if (node_detected_dev) {
> > + node_detected_dev->dev = dev;
> > + list_add(_detected_dev->list, _detected_devices);
>
> Probably list_add_tail would be better so the ordering is the same as
> it was before?
>
>
> > + } else {
> > + printk(KERN_CRIT "md: kzAlloc node failed, skipping device."
> > + " : 0x%p.\n", node_detected_dev);
> > + }
>
>
>
> > }
> >
> >
> > @@ -5765,7 +5779,13 @@ static void autostart_arrays(int part)
> > static void autostart_arrays(int part)
> > {
> > mdk_rdev_t *rdev;
> > - int i;
> > + struct detected_devices_node *node_detected_dev;
> > + dev_t dev;
> > + int i_scanned, i_passed, i_loops;
> > + signed int i_found;
> > + i_scanned = 0;
> > + i_passed = 0;
> > + i_loops = 0;
>
> i_passed is never used.
>
> And what is the point of i_loops (and i_scanned)? The comments
> at the top of the patch should explain this if there is a good reason.
>
> >
> > printk(KERN_INFO "md: Autodetecting RAID arrays.\n");
> >
> > @@ -5772,3 +5792,11 @@ static void autostart_arrays(int part)
> > - for (i = 0; i < dev_cnt; i++) {
> > - dev_t dev = detected_devices[i];
> > -
> > + /* FIXME: max 'int' #DEFINEd somewhere? not 0x7FFF ? */
> > + while (!list_empty(_detected_devices) && i_loops < 0x7FFF) {
> > + i_scanned++;
> > + node_detected_dev = NULL;
> > + node_detected_dev = list_entry(all_detected_devices.next,
> > + struct detected_devices_node, list);
> > + if (node_detected_dev) {
>
> list_entry will *never* return NULL. It simply doesn't pointer
> arithmetic. (Well, I guess it could return NULL if it was passed
> NULL, and the struct-offset were 0, but that isn't the case here).
>
> So you don't need this 'if' at all.
>
> > + list_del(_detected_dev->list);
> > + dev = node_detected_dev->dev;
> > + kfree(node_detected_dev);
> > + /* Indent is now off by one, but the old code is after this.
> > */
>
> so you don't need to worrying about indents.
>
>
> > @@ -5781,8 +5809,16 @@ static void autostart_arrays(int part)
> > continue;
> > }
> > list_add(>same_set, _raid_disks);
> > + /* Indent is now off by one, but the old code is above this.
> > */
> > +
> > + } else {
> > + printk(KERN_CRIT "md: Invalid list node,
> > skipping.\n");
> > + }
> > + i_loops++;
> > }
> > - dev_cnt = 0;
> > +
> > + printk(KERN_INFO "md: Passes %d :
Re: [PATCH (take 2)] request_irq fix DEBUG_SHIRQ handling Re: 2.6.23-rc2-mm1: rtl8139 inconsistent lock state
On Thu, Aug 23, 2007 at 10:44:30AM +0200, Jarek Poplawski wrote: > Andrew Morton pointed out that my changelog was unusable. Sorry! > Here is a second try with the changelog and kernel version changed. ... > >(take 2) > > Subject: request_irq() - fix DEBUG_SHIRQ handling ... > Signed-off-by: Jarek Poplawski <[EMAIL PROTECTED]> > > --- > > diff -Nurp 2.6.23-rc3-git6-/kernel/irq/manage.c > 2.6.23-rc3-git6/kernel/irq/manage.c > --- 2.6.23-rc3-git6-/kernel/irq/manage.c 2007-08-23 10:11:35.0 > +0200 > +++ 2.6.23-rc3-git6/kernel/irq/manage.c 2007-08-23 10:16:29.0 > +0200 So, this time I f-ed the diff part: it's not exactly against 2.6.23-rc-git6. But, it's Andrew to blame: he should've known that some old & slow chips can't do science and poetry at the same time. Sorry (for him)! Anyway, beside an offset, should be OK... Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 -mm 3/7] I/OAT: code cleanup from checkpatch output
On Thu, 23 Aug 2007 17:15:06 -0700 Shannon Nelson wrote: > Take care of a bunch of little code nits in ioatdma files > > Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]> > Acked-by: David S. Miller <[EMAIL PROTECTED]> > --- > > drivers/dma/ioat_dma.c | 200 > +++- > 1 files changed, 111 insertions(+), 89 deletions(-) > > diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c > index 55227d4..9a4d154 100644 > --- a/drivers/dma/ioat_dma.c > +++ b/drivers/dma/ioat_dma.c > - printk(KERN_INFO "Intel(R) I/OAT DMA Engine found, %d channels\n", > - device->common.chancnt); > + printk(KERN_INFO " " > + "ioatdma: Intel(R) I/OAT DMA Engine found, %d channels\n", > + device->common.chancnt); > > err = ioat_self_test(device); > if (err) > @@ -764,7 +784,8 @@ err_set_dma_mask: > pci_disable_device(pdev); > err_enable_device: > > - printk(KERN_ERR "Intel(R) I/OAT DMA Engine initialization failed\n"); > + printk(KERN_INFO " " > + "ioatdma: Intel(R) I/OAT DMA Engine initialization failed\n"); > > return err; > } What's with these (KERN_INFO " " "...more strings"); ?? --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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.22.5 forcedeth timeout hang
On Thu, Aug 23, 2007 at 06:48:23PM -0500, Mr. Berkley Shands wrote:
> 100% reproducible hang on xmit timeout.
> Just do a "make -j4 modules" on an nfs mounted kernel source.
Most likely you also had the problem with 2.6.22.2 (maybe you have not
tested this one, though). There were bug fixes for forcedeth introduced
in this version, one of them being buggy. The patch below fixes it. Can
you please give it a try ? If it does not fix the problem, please try
2.6.22.1 which does not include those changes. I'm interested because
I have those changes pending for 2.6.20.17 too.
diff --git a/drivers/net/forcedeth.c b/drivers/net/forcedeth.c
index 10f4e3b..1938d6d 100644
--- a/drivers/net/forcedeth.c
+++ b/drivers/net/forcedeth.c
@@ -552,7 +552,7 @@ union ring_type {
#define PHY_OUI_MARVELL0x5043
#define PHY_OUI_CICADA 0x03f1
#define PHY_OUI_VITESSE0x01c1
-#define PHY_OUI_REALTEK0x01c1
+#define PHY_OUI_REALTEK0x0732
#define PHYID1_OUI_MASK0x03ff
#define PHYID1_OUI_SHFT6
#define PHYID2_OUI_MASK0xfc00
Thanks,
Willy
-
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] CFS scheduler, -v20, for v2.6.22.5, v2.6.21.7, v2.6.20.16
Hi Ingo, On Thu, Aug 23, 2007 at 11:43:46AM +0200, Ingo Molnar wrote: > > By popular demand, here is release -v20 of the CFS scheduler. It is a > full backport of the latest & greatest v2.6.23-rc3 CFS code to > v2.6.22.5, v2.6.21.7 and v2.6.20.16. Great, thanks a lot ! I had been grepping 2.6.23's shortlog to catch all patches beginning with "sched:", hoping to miss none. I had caught up with -rc2 with something that worked fairly well, but I never was 100% sure it was OK. So, once again, thanks ;-) Willy - 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] Fix rmmod of asus_laptop
Applied.
thanks,
-Len
On Thursday 16 August 2007 12:18, Guillaume Chazarain wrote:
> [Resent, with a bigger recipients list]
>
> Hi,
>
> The asus laptop driver conditionnaly registers leds in asus_led_register()
> depending on their availability, but unconditionnaly registers them all at
> exit time or when the module fails to load. Unregistering not registered leds
> result in the following Oops. So we should check before unregistering.
>
> DEV: Unregistering device. ID = 'asus-laptop'
> PM: Removing info for No Bus:asus-laptop
> kobject_uevent_env
> fill_kobj_path: path = '/class/backlight/asus-laptop'
> kobject asus-laptop: cleaning up
> DEV: Unregistering device. ID = ''
> BUG: unable to handle kernel NULL pointer dereference at virtual
> address 0064
> printing eip:
> c026a9a3
> *pde =
> Oops: [#1]
> PREEMPT
> Modules linked in: radeon drm cpufreq_ondemand acpi_cpufreq freq_table
> lm90 hwmon ipv6 binfmt_misc dm_mirror dm_mod snd_intel8x0
> snd_intel8x0m snd_ac97_codec snd_seq_dummy ac97_bus snd_seq_oss
> snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss hci_usb
> snd_mixer_oss bluetooth snd_pcm ohci1394 snd_timer ieee1394 sr_mod snd
> cdrom ipw2200 ieee80211 firewire_ohci asus_laptop rtc_cmos
> firewire_core button video i2c_i801 rtc_core serio_raw soundcore irda
> crc_ccitt crc_itu_t output ac ieee80211_crypt battery i2c_core
> led_class sdhci mmc_core snd_page_alloc iTCO_wdt sg rtc_lib skge
> ehci_hcd ohci_hcd uhci_hcd
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00210296 (2.6.23-rc3-patched #2)
> EIP is at device_del+0xb/0x23a
> eax: ebx: ecx: 0033 edx: f7d0c7c0
> esi: f88ab580 edi: 0880 ebp: f594ef1c esp: f594ef0c
> ds: 007b es: 007b fs: gs: 0033 ss: 0068
> Process rmmod (pid: 2552, ti=f594e000 task=f628e5b0 task.ti=f594e000)
> Stack: c011fb2e f88ab580 0880 f594ef30 c026abf8 c03a85df 00a4
>f88ab780 f594ef40 f8864218 f88ab780 f594ef48 f88a90f8 f594ef50
>f88a91c9 f594efb0 c013cee1 73757361 70616c5f 00706f74 c015c10a 0004
> Call Trace:
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_stack_log_lvl+0x9d/0xa5
> [] show_registers+0x1cd/0x2e3
> [] die+0x11d/0x218
> [] do_page_fault+0x511/0x5e9
> [] error_code+0x6a/0x70
> [] device_unregister+0x26/0x32
> [] led_classdev_unregister+0x58/0x94 [led_class]
> [] asus_led_exit+0x17/0x41 [asus_laptop]
> [] asus_laptop_exit+0xd/0x3f [asus_laptop]
> [] sys_delete_module+0x17b/0x1a2
> [] sysenter_past_esp+0x6b/0xa1
> ===
> Code: 8b 56 04 89 d8 e8 10 fb ff ff 85 ff 74 0d 8b 97 d0 00 00 00 89
> d8 e8 9d ff ff ff 5b 5e 5f 5d c3 55 89 e5 57 56 53 89 c3 83 ec 04 <8b>
> 40 64 85 c0 89 45 f0 74 08 8d 43 10 e8 e0 ee 0b 00 8b 83 20
> EIP: [] device_del+0xb/0x23a SS:ESP 0068:f594ef0c
>
> Signed-off-by: Guillaume Chazarain <[EMAIL PROTECTED]>
> ---
>
> diff -r 1559df81a153 drivers/misc/asus-laptop.c
> --- a/drivers/misc/asus-laptop.c Mon Aug 13 05:00:33 2007 +
> +++ b/drivers/misc/asus-laptop.c Tue Aug 14 13:06:40 2007 +0200
> @@ -1072,7 +1072,8 @@ static void asus_backlight_exit(void)
> }
>
> #define ASUS_LED_UNREGISTER(object) \
> - led_classdev_unregister(##_led)
> + if (object##_led.dev) \
> + led_classdev_unregister(##_led)
>
> static void asus_led_exit(void)
> {
>
-
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 04/14] Convert from class_device to device for drivers/macintosh
On Mon, 2007-08-20 at 15:48 -0700, [EMAIL PROTECTED] wrote: > -- > Content-Disposition: inline; filename=macintosh.patch > > Convert from class_device to device for macintosh. This is part of the > work to eliminate struct class_device. Good. That stuff shouldn't have been a class in the first place. ADB is a bus type, not a class. Ben. > --- > drivers/macintosh/adb.c |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- a/drivers/macintosh/adb.c > +++ b/drivers/macintosh/adb.c > @@ -875,5 +875,5 @@ adbdev_init(void) > adb_dev_class = class_create(THIS_MODULE, "adb"); > if (IS_ERR(adb_dev_class)) > return; > - class_device_create(adb_dev_class, NULL, MKDEV(ADB_MAJOR, 0), NULL, > "adb"); > + device_create(adb_dev_class, NULL, MKDEV(ADB_MAJOR, 0), "adb"); > } > - 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 take #2] MAINTAINTERS: use our mail list as Blackfin arch maintainters.
On Fri, Aug 24, 2007 at 12:04:47PM +0800, Bryan Wu wrote: > On Thu, 2007-08-23 at 19:24 -0500, Matt Mackall wrote: > > On Wed, Aug 22, 2007 at 10:55:11PM +0800, Bryan Wu wrote: > > > -L: [EMAIL PROTECTED] (subscribers-only) > > > +L: [EMAIL PROTECTED] > > > > Does your list generate a complaint message back to the sender if a > > non-subscriber posts to it? If so, it qualifies as a subscribers-only > > list. > > > > As Mike said, "it is moderated which means you do not need to subscribe, > we will > forward any relevant messages" And as I said, "does your list generate a complaint message back to the sender?" It's the moderation message that's the problem. -- Mathematics is the supreme nostalgia of our time. - 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: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Thu, Aug 23, 2007 at 08:55:04PM -0600, Matthew Wilcox wrote: > On Thu, Aug 23, 2007 at 09:52:54PM -0500, Matt Mackall wrote: > > The other part of the puzzle is including the wider Linux community. > > As I said; what's wrong with just using SPI membership? It's not like > it is remotely hard for kernel hackers to gain membership in SPI. And > somebody else takes care of the bureaucracy for you. My impression as an SPI member is that in practice most SPI members come from the SPI projects [1], and due to Debian's size Debian developers are the majority of SPI members. If you elect at KS it'll favor kernel developers. If you let all SPI members elect it'll favor Debian developers. The Linux Foundation homepage says "The Technical Advisory Board (TAB) provides the Linux kernel community a direct voice into The Linux Foundation’s activities...". If this is the intention, an election at the KS is the best solution. cu Adrian [1] the most important task of SPI is handling money for the SPI projects (and having an US tax-exempt status) -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 28/30] jfs: avoid pointless casts of kmalloc() return val
Thanks, but Jack Stone submitted the same patch a few weeks ago. It's
already in the jfs git tree and the -mm kernel.
Shaggy
On Fri, 2007-08-24 at 02:36 +0200, Jesper Juhl wrote:
> There's no need to cast the, void *, return value of kmalloc() when
> assigning to a pointer variable.
>
> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
> ---
> fs/jfs/jfs_dtree.c |8 ++--
> 1 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
> index c14ba3c..3f15b36 100644
> --- a/fs/jfs/jfs_dtree.c
> +++ b/fs/jfs/jfs_dtree.c
> @@ -592,9 +592,7 @@ int dtSearch(struct inode *ip, struct component_name *
> key, ino_t * data,
> struct component_name ciKey;
> struct super_block *sb = ip->i_sb;
>
> - ciKey.name =
> - (wchar_t *) kmalloc((JFS_NAME_MAX + 1) * sizeof(wchar_t),
> - GFP_NOFS);
> + ciKey.name = kmalloc((JFS_NAME_MAX + 1) * sizeof(wchar_t), GFP_NOFS);
> if (ciKey.name == 0) {
> rc = -ENOMEM;
> goto dtSearch_Exit2;
> @@ -957,9 +955,7 @@ static int dtSplitUp(tid_t tid,
> smp = split->mp;
> sp = DT_PAGE(ip, smp);
>
> - key.name =
> - (wchar_t *) kmalloc((JFS_NAME_MAX + 2) * sizeof(wchar_t),
> - GFP_NOFS);
> + key.name = kmalloc((JFS_NAME_MAX + 2) * sizeof(wchar_t), GFP_NOFS);
> if (key.name == 0) {
> DT_PUTPAGE(smp);
> rc = -ENOMEM;
--
David Kleikamp
IBM Linux Technology Center
-
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 take #2] MAINTAINTERS: use our mail list as Blackfin arch maintainters.
On Thu, 2007-08-23 at 19:24 -0500, Matt Mackall wrote: > On Wed, Aug 22, 2007 at 10:55:11PM +0800, Bryan Wu wrote: > > -L: [EMAIL PROTECTED] (subscribers-only) > > +L: [EMAIL PROTECTED] > > Does your list generate a complaint message back to the sender if a > non-subscriber posts to it? If so, it qualifies as a subscribers-only > list. > As Mike said, "it is moderated which means you do not need to subscribe, we will forward any relevant messages" Thanks - Bryan Wu - 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] lguest should depend on CONFIG_FUTEX
On Thu, 2007-08-23 at 17:25 +0400, Alexey Dobriyan wrote: > It uses get_futex_key(). > > Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]> Good catch. Thanks, sent to Linus. Cheers, Rusty. - 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 2/9] Use NOMEMALLOC reclaim to allow reclaim if PF_MEMALLOC is set
On Thu, Aug 23, 2007 at 11:26:48AM +0200, Peter Zijlstra wrote: > On Thu, 2007-08-23 at 05:38 +0200, Nick Piggin wrote: > > On Tue, Aug 21, 2007 at 04:07:15PM +0200, Peter Zijlstra wrote: > > > On Tue, 2007-08-21 at 02:39 +0200, Nick Piggin wrote: > > > > > > > > Although interestingly, we are not guaranteed to have enough memory to > > > > completely initialise writeout of a single page. > > > > > > Yes, that is due to the unbounded nature of direct reclaim, no? > > > > Even writing out a single page to a plain old block backed filesystem > > can take a fair chunk of memory. I'm not really sure how problematic > > this is with a "real" filesystem, but even with something pretty simple, > > you might have to do block allocation, which itself might have to do > > indirect block allocation (which itself can be 3 or 4 levels), all of > > which have to actually update block bitmaps (which themselves may be > > many pages big). Then you also may have to even just allocate the > > buffer_head structure itself. And that's just to write out a single > > buffer in the page (on a 64K page system, there might be 64 of these). > > Right, nikita once talked me though all that when we talked about > clustered writeout. > > IIRC filesystems were supposed to keep mempools big enough to do this > for a single writepage at a time. Not sure its actually done though. It isn't ;) At least I don't think so for the minix-derived ones I've seen. But no matter, this is going a bit off topic anyway. > > But again, on the pragmatic side, the best behaviour I think is just > > to have writeouts not allocate from reserves without first trying to > > reclaim some clean memory, and also limit the number of users of the > > reserve. We want this anyway, right, because we don't want regular > > reclaim to start causing things like atomic allocation failures when > > load goes up. > > My idea is to extend kswapd, run cpus_per_node instances of kswapd per > node for each of GFP_KERNEL, GFP_NOFS, GFP_NOIO. (basically 3 kswapds > per cpu) > > whenever we would hit direct reclaim, add ourselves to a special > waitqueue corresponding to the type of GFP and kick all the > corresponding kswapds. I don't know what this is solving? You don't need to run all reclaim from kswapd process in order to limit concurrency. Just explicitly limit it when a process applies for PF_MEMALLOC reserves. I had a patch to do this at one point, but it never got much testing -- I think there were other problems iwth a single process able to do unbounded writeout and such anyway. But yeah, I don't think getting rid of direct reclaim will do anything magical. > Now Linus' big objection is that all these processes would hit a wall > and not progress until the watermarks are high again. > > Here is were the 'special' part of the waitqueue comes into order. > > Instead of freeing pages to the page allocator, these kswapds would hand > out pages to the waiting processes in a round robin fashion. Only if > there are no more waiting processes left, would the page go to the buddy > system. Directly getting back pages (and having more than 1 kswapd per node) may be things worth exploring at some point. But I don't see how muchi bearing they have to any deadlock problems. > > > And then there is the deadlock in add_to_swap() that I still have to > > > look into, I hope it can eventually be solved using reserve based > > > allocation. > > > > Yes it should have a reserve. It wouldn't be hard, all you need is > > enough memory to be able to swap out a single page I would think (ie. > > one preload's worth). > > Yeah, just need to look at the locking an batching, and ensure it has > enough preload to survive one batch, once all the locks are dropped it > can breathe again :-) I don't think you'd need to do anything remotely fancy ;) Just so long as it can allocate a swapcache entry for a single page to write out, that page will be written and eventually reclaimed, along with its radix tree nodes. > > > The biggest issue is receiving the completion notification. Network > > > needs to fall back to a state where it does not blindly consumes memory > > > or drops _all_ packets. An intermediate state is required, one where we > > > can receive and inspect incoming packets but commit to very few. > > > > Yes, I understand this is the main problem. But it is not _helped_ by > > the fact that reclaim reserves include the atomic allocation reserves. > > I haven't run this problem for a long time, but I'd venture to guess the > > _main_ reason the deadlock is hit is not because of networking allocating > > a lot of other irrelevant data, but because of reclaim using up most of > > the atomic allocation reserves. > > Ah, interesting notion. > > > And this observation is not tied to recurisve reclaim: if we somehow had > > a reserve for atomic allocations that was aside from the reclaim reserve, > > I think such a system would be practically free of deadlock
[PATCH 2/2] sysctl: For irda update sysctl_checks list of binary paths.
It turns out that the net/irda code didn't register any of
it's binary paths in the global sysctl.h header file so
I missed them completely when making an authoritative list
of binary sysctl paths in the kernel. So add them to
the list of valid binary sysctl paths.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
kernel/sysctl_check.c | 19 +++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index d5e0337..aa5b6f6 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -702,6 +702,24 @@ static struct trans_ctl_table trans_net_dccp_table[] = {
{}
};
+static struct trans_ctl_table trans_net_irda_table[] = {
+ { NET_IRDA_DISCOVERY, "discovery" },
+ { NET_IRDA_DEVNAME, "devname" },
+ { NET_IRDA_DEBUG, "debug" },
+ { NET_IRDA_FAST_POLL, "fast_poll_increase" },
+ { NET_IRDA_DISCOVERY_SLOTS, "discovery_slots" },
+ { NET_IRDA_DISCOVERY_TIMEOUT, "discovery_timeout" },
+ { NET_IRDA_SLOT_TIMEOUT,"slot_timeout" },
+ { NET_IRDA_MAX_BAUD_RATE, "max_baud_rate" },
+ { NET_IRDA_MIN_TX_TURN_TIME,"min_tx_turn_time" },
+ { NET_IRDA_MAX_TX_DATA_SIZE,"max_tx_data_size" },
+ { NET_IRDA_MAX_TX_WINDOW, "max_tx_window" },
+ { NET_IRDA_MAX_NOREPLY_TIME,"max_noreply_time" },
+ { NET_IRDA_WARN_NOREPLY_TIME, "warn_noreply_time" },
+ { NET_IRDA_LAP_KEEPALIVE_TIME, "lap_keepalive_time" },
+ {}
+};
+
static struct trans_ctl_table trans_net_table[] = {
{ NET_CORE, "core", trans_net_core_table },
/* NET_ETHER not used */
@@ -723,6 +741,7 @@ static struct trans_ctl_table trans_net_table[] = {
{ NET_LLC, "llc", trans_net_llc_table },
{ NET_NETFILTER,"netfilter",trans_net_netfilter_table },
{ NET_DCCP, "dccp", trans_net_dccp_table },
+ { NET_IRDA, "irda", trans_net_irda_table },
{ 2089, "nf_conntrack_max" },
{}
};
--
1.5.1.1.181.g2de0
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] sysctl: Properly register the irda binary sysctl numbers.
Grumble. These numbers should have been in sysctl.h from the
beginning if we ever expected anyone to use them. Oh well put
them there now so we can find them and make maintenance easier.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
include/linux/sysctl.h | 20
net/irda/irsysctl.c| 34 ++
2 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index 88f0941..77c9ae2 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -238,6 +238,7 @@ enum
NET_LLC=18,
NET_NETFILTER=19,
NET_DCCP=20,
+ NET_IRDA=412,
};
/* /proc/sys/kernel/random */
@@ -795,6 +796,25 @@ enum {
NET_BRIDGE_NF_FILTER_PPPOE_TAGGED = 5,
};
+/* proc/sys/net/irda */
+enum {
+ NET_IRDA_DISCOVERY=1,
+ NET_IRDA_DEVNAME=2,
+ NET_IRDA_DEBUG=3,
+ NET_IRDA_FAST_POLL=4,
+ NET_IRDA_DISCOVERY_SLOTS=5,
+ NET_IRDA_DISCOVERY_TIMEOUT=6,
+ NET_IRDA_SLOT_TIMEOUT=7,
+ NET_IRDA_MAX_BAUD_RATE=8,
+ NET_IRDA_MIN_TX_TURN_TIME=9,
+ NET_IRDA_MAX_TX_DATA_SIZE=10,
+ NET_IRDA_MAX_TX_WINDOW=11,
+ NET_IRDA_MAX_NOREPLY_TIME=12,
+ NET_IRDA_WARN_NOREPLY_TIME=13,
+ NET_IRDA_LAP_KEEPALIVE_TIME=14,
+};
+
+
/* CTL_FS names: */
enum
{
diff --git a/net/irda/irsysctl.c b/net/irda/irsysctl.c
index 957e04f..525343a 100644
--- a/net/irda/irsysctl.c
+++ b/net/irda/irsysctl.c
@@ -31,12 +31,6 @@
#include /* irda_debug */
#include
-#define NET_IRDA 412 /* Random number */
-enum { DISCOVERY=1, DEVNAME, DEBUG, FAST_POLL, DISCOVERY_SLOTS,
- DISCOVERY_TIMEOUT, SLOT_TIMEOUT, MAX_BAUD_RATE, MIN_TX_TURN_TIME,
- MAX_TX_DATA_SIZE, MAX_TX_WINDOW, MAX_NOREPLY_TIME, WARN_NOREPLY_TIME,
- LAP_KEEPALIVE_TIME };
-
extern int sysctl_discovery;
extern int sysctl_discovery_slots;
extern int sysctl_discovery_timeout;
@@ -94,7 +88,7 @@ static int do_devname(ctl_table *table, int write, struct
file *filp,
/* One file */
static ctl_table irda_table[] = {
{
- .ctl_name = DISCOVERY,
+ .ctl_name = NET_IRDA_DISCOVERY,
.procname = "discovery",
.data = _discovery,
.maxlen = sizeof(int),
@@ -102,7 +96,7 @@ static ctl_table irda_table[] = {
.proc_handler = _dointvec
},
{
- .ctl_name = DEVNAME,
+ .ctl_name = NET_IRDA_DEVNAME,
.procname = "devname",
.data = sysctl_devname,
.maxlen = 65,
@@ -112,7 +106,7 @@ static ctl_table irda_table[] = {
},
#ifdef CONFIG_IRDA_DEBUG
{
- .ctl_name = DEBUG,
+ .ctl_name = NET_IRDA_DEBUG,
.procname = "debug",
.data = _debug,
.maxlen = sizeof(int),
@@ -122,7 +116,7 @@ static ctl_table irda_table[] = {
#endif
#ifdef CONFIG_IRDA_FAST_RR
{
- .ctl_name = FAST_POLL,
+ .ctl_name = NET_IRDA_FAST_POLL,
.procname = "fast_poll_increase",
.data = _fast_poll_increase,
.maxlen = sizeof(int),
@@ -131,7 +125,7 @@ static ctl_table irda_table[] = {
},
#endif
{
- .ctl_name = DISCOVERY_SLOTS,
+ .ctl_name = NET_IRDA_DISCOVERY_SLOTS,
.procname = "discovery_slots",
.data = _discovery_slots,
.maxlen = sizeof(int),
@@ -142,7 +136,7 @@ static ctl_table irda_table[] = {
.extra2 = _discovery_slots
},
{
- .ctl_name = DISCOVERY_TIMEOUT,
+ .ctl_name = NET_IRDA_DISCOVERY_TIMEOUT,
.procname = "discovery_timeout",
.data = _discovery_timeout,
.maxlen = sizeof(int),
@@ -150,7 +144,7 @@ static ctl_table irda_table[] = {
.proc_handler = _dointvec
},
{
- .ctl_name = SLOT_TIMEOUT,
+ .ctl_name = NET_IRDA_SLOT_TIMEOUT,
.procname = "slot_timeout",
.data = _slot_timeout,
.maxlen = sizeof(int),
@@ -161,7 +155,7 @@ static ctl_table irda_table[] = {
.extra2 = _slot_timeout
},
{
- .ctl_name = MAX_BAUD_RATE,
+ .ctl_name = NET_IRDA_MAX_BAUD_RATE,
.procname = "max_baud_rate",
.data = _max_baud_rate,
.maxlen = sizeof(int),
@@ -172,7 +166,7 @@ static ctl_table irda_table[] = {
.extra2 = _max_baud_rate
},
{
-
Re: 2.6.23-rc3-mm1 - irda goes belly up
Andrew Morton <[EMAIL PROTECTED]> writes: > > Yes, the ENOMEM is bogus. But irda_sysctl_register() saw a NULL return > from register_sysctl_table() and simply has no clue why it failed, and is > forced to assume ENOMEM. That's a design shortcoming in > register_sysctl_table(), whcih should have returned an ERR_PTR. Doesn't > matter much. I should say something about the return value issue. Currently the only time this matters is when someone messes up in development, and if it isn't an out of memory error we get messages in dmesg so it shouldn't be to hard to sort out. I agree it is a bit of a short coming that we can only return NULL and it might be worth changing that at some point. Perhaps when I introduce register_sysctl_path would be a good time. Going through all of the callers just to give a better return value when they can't do anything about it anyway seems to be a lot of work for a very minor improvement. Eric - 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] clean up exports in fs/{open,read_write}.c
Takashi-san fixed sound/isa/wavefront/wavefront_synth.c to use
request_firmware instead of sys_*. Since that is the last driver in the
kernel that uses sys_{read,close}, this patch kills these exports. sys_open
is left exported for sparc64 only.
Cc: Takashi Iwai <[EMAIL PROTECTED]>
Cc: Christoph Hellwig <[EMAIL PROTECTED]>
Cc: Arjan van de Ven <[EMAIL PROTECTED]>
Signed-off-by: Eugene Teo <[EMAIL PROTECTED]>
---
fs/open.c |4 ++--
fs/read_write.c |1 -
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/fs/open.c b/fs/open.c
index 1d9e5e9..dc121ce 100644
--- a/fs/open.c
+++ b/fs/open.c
@@ -1056,7 +1056,9 @@ asmlinkage long sys_open(const char __user *filename, int
flags, int mode)
prevent_tail_call(ret);
return ret;
}
+#ifdef CONFIG_SPARC64
EXPORT_SYMBOL_GPL(sys_open);
+#endif
asmlinkage long sys_openat(int dfd, const char __user *filename, int flags,
int mode)
@@ -1148,8 +1150,6 @@ out_unlock:
return -EBADF;
}
-EXPORT_SYMBOL(sys_close);
-
/*
* This routine simulates a hangup on the tty, to arrange that users
* are given clean terminals at login time.
diff --git a/fs/read_write.c b/fs/read_write.c
index 507ddff..d913d1e 100644
--- a/fs/read_write.c
+++ b/fs/read_write.c
@@ -370,7 +370,6 @@ asmlinkage ssize_t sys_read(unsigned int fd, char __user *
buf, size_t count)
return ret;
}
-EXPORT_SYMBOL_GPL(sys_read);
asmlinkage ssize_t sys_write(unsigned int fd, const char __user * buf, size_t
count)
{
-
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/1] md: Software Raid autodetect dev list not array
On Wednesday August 22, [EMAIL PROTECTED] wrote:
> From: Michael J. Evans <[EMAIL PROTECTED]>
>
> In current release kernels the md module (Software RAID) uses a static array
> (dev_t[128]) to store partition/device info temporarily for autostart.
>
> This patch replaces that static array with a list.
I must admit that I'm not very keen on this.
I would much rather that in-kernel autodetect were deprecated rather
than enhanced.
Just use 'mdadm' in an initrd, or during normal boot, to assemble all
your arrays.
However.
> =
> --- linux/drivers/md/md.c.orig2007-08-21 03:19:42.511576248 -0700
> +++ linux/drivers/md/md.c 2007-08-21 04:30:09.775525710 -0700
> @@ -24,4 +24,6 @@
>
> + - autodetect dev list not array: Michael J. Evans <[EMAIL PROTECTED]>
> +
> This program is free software; you can redistribute it and/or modify
> it under the terms of the GNU General Public License as published by
> the Free Software Foundation; either version 2, or (at your option)
> @@ -5752,13 +5754,25 @@ void md_autodetect_dev(dev_t dev)
> * Searches all registered partitions for autorun RAID arrays
> * at boot time.
> */
> -static dev_t detected_devices[128];
> -static int dev_cnt;
> +
> +static LIST_HEAD(all_detected_devices);
> +/* FIXME : Should these 4 lines instead go in to include/linux/raid/md_k.h ?
No. No-one outside this file uses them, so they are fine where they
are.
> */
> +struct detected_devices_node {
> + struct list_head list;
> + dev_t dev;
> +};
>
> void md_autodetect_dev(dev_t dev)
> {
> - if (dev_cnt >= 0 && dev_cnt < 127)
> - detected_devices[dev_cnt++] = dev;
> + struct detected_devices_node *node_detected_dev;
> + node_detected_dev = kzalloc(sizeof(*node_detected_dev), GFP_KERNEL);\
> + if (node_detected_dev) {
> + node_detected_dev->dev = dev;
> + list_add(_detected_dev->list, _detected_devices);
Probably list_add_tail would be better so the ordering is the same as
it was before?
> + } else {
> + printk(KERN_CRIT "md: kzAlloc node failed, skipping device."
> + " : 0x%p.\n", node_detected_dev);
> + }
> }
>
>
> @@ -5765,7 +5779,13 @@ static void autostart_arrays(int part)
> static void autostart_arrays(int part)
> {
> mdk_rdev_t *rdev;
> - int i;
> + struct detected_devices_node *node_detected_dev;
> + dev_t dev;
> + int i_scanned, i_passed, i_loops;
> + signed int i_found;
> + i_scanned = 0;
> + i_passed = 0;
> + i_loops = 0;
i_passed is never used.
And what is the point of i_loops (and i_scanned)? The comments
at the top of the patch should explain this if there is a good reason.
>
> printk(KERN_INFO "md: Autodetecting RAID arrays.\n");
>
> @@ -5772,3 +5792,11 @@ static void autostart_arrays(int part)
> - for (i = 0; i < dev_cnt; i++) {
> - dev_t dev = detected_devices[i];
> -
> + /* FIXME: max 'int' #DEFINEd somewhere? not 0x7FFF ? */
> + while (!list_empty(_detected_devices) && i_loops < 0x7FFF) {
> + i_scanned++;
> + node_detected_dev = NULL;
> + node_detected_dev = list_entry(all_detected_devices.next,
> + struct detected_devices_node, list);
> + if (node_detected_dev) {
list_entry will *never* return NULL. It simply doesn't pointer
arithmetic. (Well, I guess it could return NULL if it was passed
NULL, and the struct-offset were 0, but that isn't the case here).
So you don't need this 'if' at all.
> + list_del(_detected_dev->list);
> + dev = node_detected_dev->dev;
> + kfree(node_detected_dev);
> + /* Indent is now off by one, but the old code is after this. */
so you don't need to worrying about indents.
> @@ -5781,8 +5809,16 @@ static void autostart_arrays(int part)
> continue;
> }
> list_add(>same_set, _raid_disks);
> + /* Indent is now off by one, but the old code is above this. */
> +
> + } else {
> + printk(KERN_CRIT "md: Invalid list node, skipping.\n");
> + }
> + i_loops++;
> }
> - dev_cnt = 0;
> +
> + printk(KERN_INFO "md: Passes %d : Scanned %d and added %d devices.\n",
> + i_loops, i_scanned, i_passed);
>
> autorun_devices(part);
> }
I'm not dead-set against the change, and if you tidy it up I'll
probably accept it, but I really think you would be better off skipping
the in-kernel autodetect stuff altogether and use mdadm to assemble
your arrays.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Re: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Thu, Aug 23, 2007 at 08:55:04PM -0600, Matthew Wilcox wrote: > On Thu, Aug 23, 2007 at 09:52:54PM -0500, Matt Mackall wrote: > > The other part of the puzzle is including the wider Linux community. > > As I said; what's wrong with just using SPI membership? It's not like > it is remotely hard for kernel hackers to gain membership in SPI. And > somebody else takes care of the bureaucracy for you. Ahh, I didn't realize you were suggesting making -them- do the work instead of just stealing their model. I suppose that could work, provided no one finds being an SPI member objectionable and they'd provide us with their member list. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc3-mm1 - irda goes belly up
Andrew Morton <[EMAIL PROTECTED]> writes: > > Cute. Eric, can you please suggest what we should do here? Grumble. Ok. This is a two sided bug. The NET_IRDA define as not put in sysctl.h where it belongs so I missed it, when making the list of all existing binary sysctls. So really I need to put update the sysctl_check tables to have the NET_IRDA numbers, because at least at first skim everything looks ok on the binary side. Patches to follow shortly. Eric - 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][resend] fix IDE legacy mode resources
Hi,
I got the following error on MIPS Cobalt.
PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:09.1
pata_via :00:09.1: failed to request/iomap BARs for port 0 (errno=-16)
PCI: Unable to reserve I/O region #3:[EMAIL PROTECTED] for device :00:09.1
pata_via :00:09.1: failed to request/iomap BARs for port 1 (errno=-16)
pata_via :00:09.1: no available native port
The legacy mode IDE resources set the following order.
pci_setup_device()
Legacy mode ATA controllers have fixed addresses.
IDE resources: 0x1F0-0x1F7, 0x3F6, 0x170-0x177, 0x376
|
V
pcibios_fixup_bus()
MIPS Cobalt PCI bus regions have the -0x1000 offset from PCI resources.
pcibios_fixup_bus() fix PCI bus regions.
0x1F0 - 0x1000 = 0xF1F0
|
V
ata_pci_init_one()
PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device
:00:09.1
In some architectures, PCI bus regions have the offset from PCI resources.
For this reason, pci_setup_device() should set PCI bus regions to
dev->resource[].
Yoichi
---
Fix legacy mode IDE resources
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -pruN -X generic/Documentation/dontdiff generic-orig/drivers/pci/probe.c
generic/drivers/pci/probe.c
--- generic-orig/drivers/pci/probe.c2007-07-26 17:07:44.151670750 +0900
+++ generic/drivers/pci/probe.c 2007-07-26 17:25:42.227046250 +0900
@@ -744,22 +744,40 @@ static int pci_setup_device(struct pci_d
*/
if (class == PCI_CLASS_STORAGE_IDE) {
u8 progif;
+ struct pci_bus_region region;
+ struct resource resource;
pci_read_config_byte(dev, PCI_CLASS_PROG, );
if ((progif & 1) == 0) {
- dev->resource[0].start = 0x1F0;
- dev->resource[0].end = 0x1F7;
- dev->resource[0].flags = LEGACY_IO_RESOURCE;
- dev->resource[1].start = 0x3F6;
- dev->resource[1].end = 0x3F6;
- dev->resource[1].flags = LEGACY_IO_RESOURCE;
+ resource.start = 0x1F0;
+ resource.end = 0x1F7;
+ resource.flags = LEGACY_IO_RESOURCE;
+ pcibios_resource_to_bus(dev, ,
);
+ dev->resource[0].start = region.start;
+ dev->resource[0].end = region.end;
+ dev->resource[0].flags = resource.flags;
+ resource.start = 0x3F6;
+ resource.end = 0x3F6;
+ resource.flags = LEGACY_IO_RESOURCE;
+ pcibios_resource_to_bus(dev, ,
);
+ dev->resource[1].start = region.start;
+ dev->resource[1].end = region.end;
+ dev->resource[1].flags = resource.flags;
}
if ((progif & 4) == 0) {
- dev->resource[2].start = 0x170;
- dev->resource[2].end = 0x177;
- dev->resource[2].flags = LEGACY_IO_RESOURCE;
- dev->resource[3].start = 0x376;
- dev->resource[3].end = 0x376;
- dev->resource[3].flags = LEGACY_IO_RESOURCE;
+ resource.start = 0x170;
+ resource.end = 0x177;
+ resource.flags = LEGACY_IO_RESOURCE;
+ pcibios_resource_to_bus(dev, ,
);
+ dev->resource[2].start = region.start;
+ dev->resource[2].end = region.end;
+ dev->resource[2].flags = resource.flags;
+ resource.start = 0x376;
+ resource.end = 0x376;
+ resource.flags = LEGACY_IO_RESOURCE;
+ pcibios_resource_to_bus(dev, ,
);
+ dev->resource[3].start = region.start;
+ dev->resource[3].end = region.end;
+ dev->resource[3].flags = resource.flags;
}
}
break;
-
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: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Thu, Aug 23, 2007 at 09:52:54PM -0500, Matt Mackall wrote: > The other part of the puzzle is including the wider Linux community. As I said; what's wrong with just using SPI membership? It's not like it is remotely hard for kernel hackers to gain membership in SPI. And somebody else takes care of the bureaucracy for you. -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Thu, Aug 23, 2007 at 09:34:34PM -0500, Josh Boyer wrote: > On 8/23/07, Andy Isaacson <[EMAIL PROTECTED]> wrote: > > On Wed, Aug 22, 2007 at 08:35:07PM -0500, James Bottomley wrote: > > > > While I think that's laudable, we definitely don't have the resources > > > > for that, as everyone on the TAB already has a full workload. And it > > > > hardly seems worth the trouble for a once-a-year election. > > > > > > Exactly ... we want a process that's simple and transparent. We chose > > > voting at the KS because almost all the attendees satisfy the "made > > > significant contributions to Linux" requirement without us having to do > > > anything or make any controversial determinations. Like Matt said, > > > better suggestions are welcome. > > > > This is a dumb suggestion, but... > > > > How about one vote per git commit merged to linus' tree? > > > > Might be worthwhile to allocate votes for Acked-By and so on, as well. > > Because git only goes back to 2.6.12. If you haven't had a patch accepted since 2.6.12, it's not really clear you're still a contributor. Giving various kernel janitors more votes than people doing more difficult work might be frowned on though. But I can see giving, say, the top N contributors by some simple metric a vote. That'd broaden the base. (But given that only about 30% of last year's KS attendees voted even though they were a more or less captive audience, I'd be surprised if many bothered.) The other part of the puzzle is including the wider Linux community. -- Mathematics is the supreme nostalgia of our time. - 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/
Possible problems reading a DVD-RAM disc
While doing a long mega-copy from one side of a DVD-RAM disc formatted with the vfat filesystem to an smbfs network share, I got lots and lots of these in the dmesg: Buffer I/O error on device sr0, logical block 4396 lost page write due to I/O error on sr0 sr 6:0:0:0: [sr0] Result: hostbyte=0x00 driverbyte=0x08 sr 6:0:0:0: [sr0] Sense Key : 0x7 [current] sr 6:0:0:0: [sr0] <> ASC=0x92 ASCQ=0x0ASC=0x92 ASCQ=0x0 end_request: I/O error, dev sr0, sector 17584 Buffer I/O error on device sr0, logical block 4396 lost page write due to I/O error on sr0 The DVD-RAM is detected like so (my system is an nVidia nForce 590 SLI, with kernel 2.6.22.1 and the new SCSI-using PATA/SATA drivers in use): pata_amd :00:0c.0: version 0.3.8 PCI: Setting latency timer of device :00:0c.0 to 64 scsi6 : pata_amd scsi7 : pata_amd ata7: PATA max UDMA/133 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001f400 irq 14 ata8: PATA max UDMA/133 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001f408 irq 15 ata7.00: ATAPI: MATSHITADVD-RAM LF-D310, A123, max UDMA/33 ata7.00: configured for UDMA/33 ata8: port disabled. ignoring. scsi 6:0:0:0: CD-ROMMATSHITA DVD-RAM LF-D310 A123 PQ: 0 ANSI: 5 sr0: scsi3-mmc drive: 0x/0x dvd-ram cd/rw xa/form2 cdda tray Uniform CD-ROM driver Revision: 3.20 sr 6:0:0:0: Attached scsi CD-ROM sr0 Are the above errors related to media flaws, drive flaws, driver flaws, or usage flaws (i.e. "I copied $LARGE_AMOUNT from a DVD-RAM disc to a network share", "Don't do that.")? -- SCREW THE ADS! http://adblock.mozdev.org/ - 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 4/9] s2io, rename BIT macro
Jiri Slaby wrote: s2io, rename BIT macro BIT macro will be global definiton of (1< --- [snip] cnt++; if (cnt == 5) diff --git a/drivers/net/s2io.h b/drivers/net/s2io.h index 92983ee..448f899 100644 --- a/drivers/net/s2io.h +++ b/drivers/net/s2io.h @@ -14,7 +14,7 @@ #define _S2IO_H #define TBD 0 -#define BIT(loc) (0x8000ULL >> (loc)) +#define s2BIT(loc) (0x8000ULL >> (loc)) #define vBIT(val, loc, sz) (((u64)val) << (64-loc-sz)) #define INV(d) ((d&0xff)<<24) | (((d>>8)&0xff)<<16) | (((d>>16)&0xff)<<8)| ((d>>24)&0xff) Sorry for the late response, but would it not be better/easier to use BIT() instead (or a global #define LLBIT(nr) (1ULL << (nr))) and just recalculate the values? Richard Knutsson - 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: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On 8/23/07, Andy Isaacson <[EMAIL PROTECTED]> wrote: > On Wed, Aug 22, 2007 at 08:35:07PM -0500, James Bottomley wrote: > > > While I think that's laudable, we definitely don't have the resources > > > for that, as everyone on the TAB already has a full workload. And it > > > hardly seems worth the trouble for a once-a-year election. > > > > Exactly ... we want a process that's simple and transparent. We chose > > voting at the KS because almost all the attendees satisfy the "made > > significant contributions to Linux" requirement without us having to do > > anything or make any controversial determinations. Like Matt said, > > better suggestions are welcome. > > This is a dumb suggestion, but... > > How about one vote per git commit merged to linus' tree? > > Might be worthwhile to allocate votes for Acked-By and so on, as well. Because git only goes back to 2.6.12. josh - 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: [Ecryptfs-devel] [PATCH] eCryptfs: fix possible fault in ecryptfs_sync_page
On Thu, 23 Aug 2007, Michael Halcrow write: >Note that there are other outstanding issues with eCryptfs on NFS. For >instance, prepare_write()/commit_write() have gone away in -mm, >leading to an oops when eCryptfs tries to call them directly Yes, I certainly encountered the problem during testing eCryptfs on -mm, and found Nick Piggin's new aops patchset lacks changes for eCryptfs. >which is >well deserved, since eCryptfs really should not be doing that. Unionfs >has just two places where it calls vfs_read() and vfs_write() >respectively; eCryptfs is a bit more complex, with multiple write >paths that end up writing encrypted data and updating metadata in the >header. I am currently trying to find a way to convert everything over >to vfs_read() and vfs_write() in eCryptfs, in a way that does not >ultimately result in a kernel hang. OK, I understand the reason and your plan. Thanks for letting me know! As you say, I honestly felt that it's a difficult task to write stackable filesystems using low level operations. It's good idea to replace them with the vfs functions. So, how long does it take for the conversion, do you think? Though I'm currenty focussing on eCryptfs in mainline, I'd like to shift my focus to the new one if it's preferable. Regards, Ryusuke Konishi - 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] sigqueue_free: fix the race with collect_signal()
Oleg Nesterov wrote:
Spotted by taoyue <[EMAIL PROTECTED]> and Jeremy Katz <[EMAIL PROTECTED]>.
collect_signal: sigqueue_free:
list_del_init(>list);
if (!list_empty(>list)) {
// not taken
}
q->flags &= ~SIGQUEUE_PREALLOC;
__sigqueue_free(first); __sigqueue_free(q);
Now, __sigqueue_free() is called twice on the same "struct sigqueue" with the
obviously bad implications.
In particular, this double free breaks the array_cache->avail logic, so the
same sigqueue could be "allocated" twice, and the bug can manifest itself via
the "impossible" BUG_ON(!SIGQUEUE_PREALLOC) in sigqueue_free/send_sigqueue.
Hopefully this can explain these mysterious bug-reports, see
http://marc.info/?t=11876692653
http://marc.info/?t=11846627305
Alexey Dobriyan reports this patch makes the difference for the testcase, but
nobody has an access to the application which opened the problems originally.
Also, this patch removes tasklist lock/unlock, ->siglock is enough.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- t/kernel/signal.c~SQFREE2007-08-22 20:06:31.0 +0400
+++ t/kernel/signal.c 2007-08-23 16:02:57.0 +0400
@@ -1297,20 +1297,19 @@ struct sigqueue *sigqueue_alloc(void)
void sigqueue_free(struct sigqueue *q)
{
unsigned long flags;
+ spinlock_t *lock = >sighand->siglock;
+
BUG_ON(!(q->flags & SIGQUEUE_PREALLOC));
/*
* If the signal is still pending remove it from the
-* pending queue.
+* pending queue. We must hold ->siglock while testing
+* q->list to serialize with collect_signal().
*/
- if (unlikely(!list_empty(>list))) {
- spinlock_t *lock = >sighand->siglock;
- read_lock(_lock);
- spin_lock_irqsave(lock, flags);
- if (!list_empty(>list))
- list_del_init(>list);
- spin_unlock_irqrestore(lock, flags);
- read_unlock(_lock);
- }
+ spin_lock_irqsave(lock, flags);
+ if (!list_empty(>list))
+ list_del_init(>list);
+ spin_unlock_irqrestore(lock, flags);
+
q->flags &= ~SIGQUEUE_PREALLOC;
__sigqueue_free(q);
}
Applying previous patch，it seems likely that the __sigqueue_free() is also
called twice.
collect_signal: sigqueue_free:
list_del_init(>list);
spin_lock_irqsave(lock, flags);
if (!list_empty(>list))
list_del_init(>list);
spin_unlock_irqrestore(lock, flags);
q->flags &= ~SIGQUEUE_PREALLOC;
__sigqueue_free(first); __sigqueue_free(q);
yue.tao
-
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] memchr (trivial) optimization
On Thu, Aug 23, 2007 at 06:03:29PM -0700, Jeremy Fitzhardinge wrote: > Matt Mackall wrote: > > 6e: 38 08 cmp%cl,(%eax) > > 70: 74 07 je 79 > > 72: 40 inc%eax > > > It's a bit gross that the compiler is using inc here rather than lea or > add, but still... > > Er, something's spending 30% of its time in memchr? This is not the > code to fix. Indeed. I'm just pointing out the general optimization of walking one counter instead of two. Hmm, perhaps the culprit is validate_nla? -- Mathematics is the supreme nostalgia of our time. - 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: Ideas on column length in kernel "problem"?
On Wed, Aug 22, 2007 at 11:54:41PM -0400, Scott Thompson wrote: > Many free (and not-free) mail clients wordwrap. Hushmail wraps at > 68 (verified), Yahoo has options to wrap at a max of 99, and Gmail > was somewhere around 85-90 as I recall. Not sure on other free / > inexpensive clients. I work for them FastMail (http://fastmail.fm/) have a tickbox in the web interface so you can turn off line-wrapping if you need to. Otherwise, as other people have said, use direct SMTP (we don't allow it for non-paying accounts, but do for all levels of paying user) and use a sane local client (in my case mutt+offlineimap) Bron. - 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]: posix timer: slab error 'double free'
Oleg Nesterov wrote:
(maintainers cc'ed)
On 08/21, taoyue wrote:
I write a simple stress test program for posix timer subsystem, to
reproduce the problem in the lastest mainline kernel.
My test program creates 200 threads, and each thread does the following job:
Please see my test program in the attachemnt "posix_timer_test.c". You
can compile my test program via the following command line:
Now we have a testcase. Great, thanks a lot!
Unfortunately, I can't use it because my /lib/libc-2.3.3.so doesn't implement
SIGEV_THREAD (this is a user-space thing).
However,
[] show_trace_log_lvl+0x1a/0x30
[] show_trace+0x12/0x14
[] dump_stack+0x16/0x18
[] __slab_error+0x26/0x28
[] cache_free_debugcheck+0x1d9/0x298
[] kmem_cache_free+0x66/0xb5
[] __sigqueue_free+0x2f/0x32
[] __dequeue_signal+0xdc/0x174
[] dequeue_signal+0xbb/0x149
[] sys_rt_sigtimedwait+0x7f/0x240
[] syscall_call+0x7/0xb
This is very nice trace, which says loudly that sigqueue_free() is racy
wrt collect_signal(). Very old bug, very small window.
I'll try to send the "right" fix tomorrow after sleep, but in the meanwhile,
could you please try the patch at the end?
(I am _not_ sure this can explain all problems you were seeing, though).
And I also apply the four patches from Oleg Nesterov from lkml:
http://lkm.org/lkml/2007/8/12/193
http://lkm.org/lkml/2007/8/12/194
http://lkm.org/lkml/2007/8/12/195
http://lkm.org/lkml/2007/8/12/196
^^^
(should be lkml)
Please drop them, except the first one. They have nothing to do with
these problems, and in fact you apllied the wrong versions.
Thanks!
Oleg.
--- t/kernel/signal.c~ 2007-08-21 22:29:25.0 +0400
+++ t/kernel/signal.c 2007-08-21 22:30:05.0 +0400
@@ -1305,7 +1305,7 @@ void sigqueue_free(struct sigqueue *q)
* If the signal is still pending remove it from the
* pending queue.
*/
- if (unlikely(!list_empty(>list))) {
+ if (1) {
spinlock_t *lock = >sighand->siglock;
read_lock(_lock);
spin_lock_irqsave(lock, flags);
Think you for your help. I reserved the first patch:
http://lkm.org/lkml/2007/8/12/193
and applied the previous patch, running the test program again.
Up to now, the test program has been running for more than one
day. It seems likely that the patches avoid the race condition.
yue.tao
-
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 20/30] scsi: In the Advansys driver, do not cast allocation function return values
On Fri, Aug 24, 2007 at 02:16:12AM +0200, Jesper Juhl wrote: > There's no reason to cast void pointers returned by the generic > memory allocation functions. I think I fixed all these already; please check scsi-misc. -- "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." - 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] CFS scheduler, -v20, for v2.6.22.5, v2.6.21.7, v2.6.20.16
On 8/23/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> By popular demand, here is release -v20 of the CFS scheduler. It is a
> full backport of the latest & greatest v2.6.23-rc3 CFS code to
> v2.6.22.5, v2.6.21.7 and v2.6.20.16. The patches can be downloaded from
> the usual place:
Ingo,
Great to see the older kernels updated, thanks for the patches.
I've got a bit of a modified 2.6.21.7, but when I built with
CONFIG_FAIR_GROUP_SCHED=y, I need the following change
to make things right (On a quick glance, my change matches the
2.6.23-rc3 code). Then again, I may just be doing something
stupid.
My apologies in advance if gmail decides to mangle the patch.
--- a/kernel/sched_fair.c.orig 2007-08-23 21:25:08.0 -0400
+++ a/kernel/sched_fair.c 2007-08-23 21:25:18.0 -0400
@@ -1057,7 +1057,7 @@ static void task_new_fair(struct rq *rq,
*/
static void set_curr_task_fair(struct rq *rq)
{
- struct sched_entity *se = >curr.se;
+ struct sched_entity *se = >curr->se;
for_each_sched_entity(se)
set_next_entity(cfs_rq_of(se), se);
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
-
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] CIFS: fix unbalanced calls to Get/FreeXid
merged into cifs-2.6.git tree
On 8/23/07, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> This patch fixes unbalanced calls to GetXid/FreeXid.
>
> Signed-off-by: Cyrill Gorcunov <[EMAIL PROTECTED]>
> ---
>
> fs/cifs/cifsfs.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/fs/cifs/cifsfs.c b/fs/cifs/cifsfs.c
> index cabb6a5..2493cc4 100644
> --- a/fs/cifs/cifsfs.c
> +++ b/fs/cifs/cifsfs.c
> @@ -346,7 +346,7 @@ int cifs_xquota_set(struct super_block *sb, int
> quota_type, qid_t qid,
> if (pTcon) {
> cFYI(1, ("set type: 0x%x id: %d", quota_type, qid));
> } else {
> - return -EIO;
> + rc = -EIO;
> }
>
> FreeXid(xid);
>
--
Thanks,
Steve
-
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: sysfs_dir_cache growing out of control
Greg KH wrote: > On Thu, Aug 23, 2007 at 08:44:10PM -0400, Joel Fuster wrote: >> Greg KH wrote: >>> On Wed, Aug 22, 2007 at 11:56:44PM -0400, Joel Fuster wrote: Joel Fuster wrote: > Hi, > I am running 2.6.22.3. For reasons that escape me, over time (days) the > sysfs_dir_cache, dentry, and inode_cache SLUB entries grow until they > consume all the memory on my system, requiring a reboot. >>> Hm, those items should consume all the memory, but it should be freed if >>> you have memory pressure from other places. Does it cause the machine >>> to lock up, or you just got scared when seeing them? >> Right. The problem is that the memory never seems to get freed no matter >> what I do. I've tried setting /proc/sys/vm/vfs_cache_pressure to 1, >> but after a few days all my programs are running out of swap and I have to >> reboot to get things back to a usable state. >> >>> Oh, and does the same thing happen if you do not use SLUB, but rather >>> the older SLAB? >> OK I just rebuilt 2.6.22.3 with SLAB and I seem to be getting the same >> result..obviously I haven't waited several days, but >> sysfs_dir_cache/dentry/inode_cache grow continuously when scanbuttond is >> running, and stop growing when it isn't. > > Do you have a pointer to the scanbuttond source code? I'll try to take > a look at this tomorrow. > I guess this one : https://sourceforge.net/projects/scanbuttond/ > thanks, > > greg k-h > - Gabriel - 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: [Tech-board-discuss] Re: [Ksummit-2007-discuss] Re: Linux Foundation Technical Advisory Board Elections
On Wed, Aug 22, 2007 at 08:35:07PM -0500, James Bottomley wrote: > > While I think that's laudable, we definitely don't have the resources > > for that, as everyone on the TAB already has a full workload. And it > > hardly seems worth the trouble for a once-a-year election. > > Exactly ... we want a process that's simple and transparent. We chose > voting at the KS because almost all the attendees satisfy the "made > significant contributions to Linux" requirement without us having to do > anything or make any controversial determinations. Like Matt said, > better suggestions are welcome. This is a dumb suggestion, but... How about one vote per git commit merged to linus' tree? Might be worthwhile to allocate votes for Acked-By and so on, as well. -andy - 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: division and cpu usage
> Hello. > > I'm new to kernel development and have some questions. > > 1. Why can't I divide with regular casting to double ((double)a / > (double)b)? It gives me strange errors when compiling: > > WARNING: "__divdf3" [/root] undefined! > WARNING: "__addf3" [/root/...] undefined! > WARNING: "__floatsidf" [/root/...] undefined! > > And if I compile with normal integers, I get zero as the result. As the HOWTO says: "The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported. Arbitrary long long divisions and floating point are not allowed. It can sometimes be difficult to understand the assumptions the kernel has on the toolchain and the extensions that it uses, and unfortunately there is no definitive reference for them. Please check the gcc info pages (`info gcc`) for some information on them." The short version is simply that it's very expensive to allow this, adding overhead even in cases where it isn't used, and there is very little benefit. For almost every imaginable case where you would want floating point in the kernel, fixed point works as well or better. Just scale your numbers by shifting them. DS - 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] memchr (trivial) optimization
Matt Mackall wrote: > 6e: 38 08 cmp%cl,(%eax) > 70: 74 07 je 79 > 72: 40 inc%eax > It's a bit gross that the compiler is using inc here rather than lea or add, but still... Er, something's spending 30% of its time in memchr? This is not the code to fix. J - 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: sysfs_dir_cache growing out of control
On Thu, Aug 23, 2007 at 08:44:10PM -0400, Joel Fuster wrote: > Greg KH wrote: >> On Wed, Aug 22, 2007 at 11:56:44PM -0400, Joel Fuster wrote: >>> Joel Fuster wrote: Hi, I am running 2.6.22.3. For reasons that escape me, over time (days) the sysfs_dir_cache, dentry, and inode_cache SLUB entries grow until they consume all the memory on my system, requiring a reboot. >> Hm, those items should consume all the memory, but it should be freed if >> you have memory pressure from other places. Does it cause the machine >> to lock up, or you just got scared when seeing them? > Right. The problem is that the memory never seems to get freed no matter > what I do. I've tried setting /proc/sys/vm/vfs_cache_pressure to 1, > but after a few days all my programs are running out of swap and I have to > reboot to get things back to a usable state. > >> Oh, and does the same thing happen if you do not use SLUB, but rather >> the older SLAB? > > OK I just rebuilt 2.6.22.3 with SLAB and I seem to be getting the same > result..obviously I haven't waited several days, but > sysfs_dir_cache/dentry/inode_cache grow continuously when scanbuttond is > running, and stop growing when it isn't. Do you have a pointer to the scanbuttond source code? I'll try to take a look at this tomorrow. thanks, greg k-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 0/30] Remove unneeded casts of [kv][mzc]alloc() return values
On 24/08/07, Jesper Juhl <[EMAIL PROTECTED]> wrote: [snip] > The patches in this series are > Damn, I managed to mess up that list. Here's how it should have looked : [PATCH 01/30] ia64: Remove unnecessary cast of allocation return value in sn_hwperf_enum_objects() [PATCH 02/30] cris: Remove unnecessary cast of allocation return value in intmem.c [PATCH 03/30] um: Don't unnecessarily cast allocation return value in ubd_kern.c [PATCH 04/30] powerpc: Don't cast kmalloc return value in ibmebus.c [PATCH 05/30] atm: No need to cast vmalloc() return value [PATCH 06/30] i2o: No need to cast kmalloc() return value in cfg_open() [PATCH 07/30] mtd: Get rid of pointless cast of kzalloc() return value in AT26xxx driver [PATCH 08/30] mtd: Avoid a pointless kmalloc() return value cast in TQM8xxL mapping handling code [PATCH 09/30] mtd: Don't cast kmalloc() return value in drivers/mtd/maps/pmcmsp-flash.c [PATCH 10/30] irda: Do not do pointless kmalloc return value cast in KingSun driver [PATCH 11/30] net: No need to cast vmalloc() return values in NetXen NIC driver [PATCH 12/30] net: No point in casting kmalloc return values in Gianfar Ethernet Driver [PATCH 13/30] net: Don't do pointless kmalloc return value casts in zd1211 driver [PATCH 14/30] net: Kill some unneeded allocation return value casts in libertas [PATCH 15/30] net: No need to cast kmalloc() return value in ipw2100 driver [PATCH 16/30] net: Avoid pointless allocation casts in BSD compression module [PATCH 17/30] isdn: Get rid of some pointless allocation casts in common and bsd comp. [PATCH 18/30] isdn: eicon - get rid of a pointless vmalloc() return value cast [PATCH 19/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver [PATCH 20/30] scsi: In the Advansys driver, do not cast allocation function return values [PATCH 21/30] oss: Remove unneeded vmalloc() return value casts in OSS [PATCH 22/30] ivtv: kzalloc() returns void pointer, no need to cast [PATCH 23/30] video: Remove pointless kmalloc() return value cast in Zoran PCI controller driver [PATCH 24/30] dvb: remove some unneeded vmalloc() return value casts from av7110 [PATCH 25/30] tty: dont needlessly cast kmalloc() return value [PATCH 26/30] md: vmalloc() returns void pointer so we don't need to cast it in dm-ioctl [PATCH 27/30] usb: avoid redundant cast of kmalloc() return value in OTi-6858 driver [PATCH 28/30] jfs: avoid pointless casts of kmalloc() return val [PATCH 29/30] mm: No need to cast vmalloc() return value in zone_wait_table_init() [PATCH 30/30] emu10k1: There's no need to cast vmalloc() return value in snd_emu10k1_create() Kind regards, Jesper - 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 30/30] emu10k1: There's no need to cast vmalloc() return value in snd_emu10k1_create()
vmalloc() returns void *. no need to cast.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
sound/pci/emu10k1/emu10k1_main.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/pci/emu10k1/emu10k1_main.c b/sound/pci/emu10k1/emu10k1_main.c
index 404ae1b..91d986b 100644
--- a/sound/pci/emu10k1/emu10k1_main.c
+++ b/sound/pci/emu10k1/emu10k1_main.c
@@ -1722,8 +1722,8 @@ int __devinit snd_emu10k1_create(struct snd_card *card,
goto error;
}
- emu->page_ptr_table = (void **)vmalloc(emu->max_cache_pages *
sizeof(void*));
- emu->page_addr_table = (unsigned long*)vmalloc(emu->max_cache_pages *
sizeof(unsigned long));
+ emu->page_ptr_table = vmalloc(emu->max_cache_pages * sizeof(void *));
+ emu->page_addr_table = vmalloc(emu->max_cache_pages * sizeof(unsigned
long));
if (emu->page_ptr_table == NULL || emu->page_addr_table == NULL) {
err = -ENOMEM;
goto error;
--
1.5.2.2
-
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: sysfs_dir_cache growing out of control
Greg KH wrote:
On Wed, Aug 22, 2007 at 11:56:44PM -0400, Joel Fuster wrote:
Joel Fuster wrote:
Hi,
I am running 2.6.22.3. For reasons that escape me, over time (days) the
sysfs_dir_cache, dentry, and inode_cache SLUB entries grow until they
consume all the memory on my system, requiring a reboot.
Hm, those items should consume all the memory, but it should be freed if
you have memory pressure from other places. Does it cause the machine
to lock up, or you just got scared when seeing them?
Right. The problem is that the memory never seems to get freed no
matter what I do. I've tried setting /proc/sys/vm/vfs_cache_pressure to
1, but after a few days all my programs are running out of swap and
I have to reboot to get things back to a usable state.
Oh, and does the same thing happen if you do not use SLUB, but rather
the older SLAB?
OK I just rebuilt 2.6.22.3 with SLAB and I seem to be getting the same
result..obviously I haven't waited several days, but
sysfs_dir_cache/dentry/inode_cache grow continuously when scanbuttond is
running, and stop growing when it isn't.
An strace of one poll loop for scanbuttond follows:
nanosleep({0, 33300}, NULL) = 0
open("/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
fstat(1, {st_mode=S_IFDIR|0755, st_size=80, ...}) = 0
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
getdents(1, /* 4 entries */, 4096) = 96
getdents(1, /* 0 entries */, 4096) = 0
close(1)= 0
open("/dev/bus/usb/002", O_RDONLY|O_NONBLOCK|O_DIRECTORY) = 1
fstat(1, {st_mode=S_IFDIR|0755, st_size=60, ...}) = 0
fcntl(1, F_SETFD, FD_CLOEXEC) = 0
getdents(1, /* 3 entries */, 4096) = 72
open("/dev/bus/usb/002/001", O_RDWR)= -1 EACCES (Permission denied)
open("/dev/bus/usb/002/001", O_RDONLY) = 2
ioctl(2, USBDEVFS_CONNECTINFO, 0x7fffb3a08420) = -1 EPERM (Operation not
permitted)
I don't see any sysfs accesses there, only usbfs accesses.
Yes, I don't know enough to understand why this would affect
sysfs_dir_cache, but there definitely seems to be a connection.
Thanks for the help,
Joel
-
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 29/30] mm: No need to cast vmalloc() return value in zone_wait_table_init()
vmalloc() returns a void pointer, so there's no need to cast its return value in mm/page_alloc.c::zone_wait_table_init(). Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- mm/page_alloc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 6427653..a8615c2 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2442,7 +2442,7 @@ int zone_wait_table_init(struct zone *zone, unsigned long zone_size_pages) * To use this new node's memory, further consideration will be * necessary. */ - zone->wait_table = (wait_queue_head_t *)vmalloc(alloc_size); + zone->wait_table = vmalloc(alloc_size); } if (!zone->wait_table) return -ENOMEM; -- 1.5.2.2 - 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 28/30] jfs: avoid pointless casts of kmalloc() return val
There's no need to cast the, void *, return value of kmalloc() when
assigning to a pointer variable.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
fs/jfs/jfs_dtree.c |8 ++--
1 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/fs/jfs/jfs_dtree.c b/fs/jfs/jfs_dtree.c
index c14ba3c..3f15b36 100644
--- a/fs/jfs/jfs_dtree.c
+++ b/fs/jfs/jfs_dtree.c
@@ -592,9 +592,7 @@ int dtSearch(struct inode *ip, struct component_name * key,
ino_t * data,
struct component_name ciKey;
struct super_block *sb = ip->i_sb;
- ciKey.name =
- (wchar_t *) kmalloc((JFS_NAME_MAX + 1) * sizeof(wchar_t),
- GFP_NOFS);
+ ciKey.name = kmalloc((JFS_NAME_MAX + 1) * sizeof(wchar_t), GFP_NOFS);
if (ciKey.name == 0) {
rc = -ENOMEM;
goto dtSearch_Exit2;
@@ -957,9 +955,7 @@ static int dtSplitUp(tid_t tid,
smp = split->mp;
sp = DT_PAGE(ip, smp);
- key.name =
- (wchar_t *) kmalloc((JFS_NAME_MAX + 2) * sizeof(wchar_t),
- GFP_NOFS);
+ key.name = kmalloc((JFS_NAME_MAX + 2) * sizeof(wchar_t), GFP_NOFS);
if (key.name == 0) {
DT_PUTPAGE(smp);
rc = -ENOMEM;
--
1.5.2.2
-
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 27/30] usb: avoid redundant cast of kmalloc() return value in OTi-6858 driver
In drivers/usb/serial/oti6858.c::pl2303_buf_alloc() the return value of kmalloc() is being cast to "struct pl2303_buf *", but that need not be done here since kmalloc() returns "void *". Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/usb/serial/oti6858.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/usb/serial/oti6858.c b/drivers/usb/serial/oti6858.c index d7db71e..fc5e808 100644 --- a/drivers/usb/serial/oti6858.c +++ b/drivers/usb/serial/oti6858.c @@ -1161,7 +1161,7 @@ static struct pl2303_buf *pl2303_buf_alloc(unsigned int size) if (size == 0) return NULL; - pb = (struct pl2303_buf *)kmalloc(sizeof(struct pl2303_buf), GFP_KERNEL); + pb = kmalloc(sizeof(struct pl2303_buf), GFP_KERNEL); if (pb == NULL) return NULL; -- 1.5.2.2 - 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: Fork Bombing Patch
On 23/08/07, Krzysztof Halasa <[EMAIL PROTECTED]> wrote: > Chris Snook <[EMAIL PROTECTED]> writes: > > > Wrapping a single printk that's unrelated to debugging in an #ifdef > > CONFIG_* or a sysctl strikes me as abuse of those configuration > > facilities. > > Abuse, probably not (if a thing is required on one system and must > not be on another, it has to be configurable). If the printk is > a good idea... IMHO hardly, at best. We don't warn about trying to > write to /vmlinuz after all. > > ulimit/pam_limits should fix the (IMHO nonexistent) problem nicely. > One has to plug all the holes, though (e.g. $HOME/.forward). > -- > Krzysztof Halasa > - > 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/ > Hi, I agree with Chris on this point, it seems like this sort of detection (and reporting) should be a job for a user-space daemon, rather than polluting kernel code (and logs) with warning messages of this sort... I don't think the type of warning this patch yields is appropriate for kernel logs, nor do I think the kernel should be the entity to decide that this warning should be given. It _feels_ wrong. -- Regards, Tom Spink University of Edinburgh - 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 04/30] powerpc: Don't cast kmalloc return value in ibmebus.c
> kmalloc() returns a void pointer so there is absolutely no need to > cast it in ibmebus_chomp(). > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> Acked-By: Joachim Fenkes <[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/
[PATCH 26/30] md: vmalloc() returns void pointer so we don't need to cast it in dm-ioctl
In drivers/md/dm-ioctl.c::copy_params() there's a call to vmalloc() where we currently cast the return value, but that's pretty pointles given that vmalloc() returns "void *". Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/md/dm-ioctl.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c index b441d82..efbf9b6 100644 --- a/drivers/md/dm-ioctl.c +++ b/drivers/md/dm-ioctl.c @@ -1358,7 +1358,7 @@ static int copy_params(struct dm_ioctl __user *user, struct dm_ioctl **param) if (tmp.data_size < sizeof(tmp)) return -EINVAL; - dmi = (struct dm_ioctl *) vmalloc(tmp.data_size); + dmi = vmalloc(tmp.data_size); if (!dmi) return -ENOMEM; -- 1.5.2.2 - 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 25/30] tty: dont needlessly cast kmalloc() return value
kmalloc() hands us a void pointer, we don't need to cast it.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/char/tty_io.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index 51ea93c..9c867cf 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -2063,8 +2063,7 @@ static int init_dev(struct tty_driver *driver, int idx,
}
if (!*tp_loc) {
- tp = (struct ktermios *) kmalloc(sizeof(struct ktermios),
- GFP_KERNEL);
+ tp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
if (!tp)
goto free_mem_out;
*tp = driver->init_termios;
@@ -2094,8 +2093,7 @@ static int init_dev(struct tty_driver *driver, int idx,
}
if (!*o_tp_loc) {
- o_tp = (struct ktermios *)
- kmalloc(sizeof(struct ktermios), GFP_KERNEL);
+ o_tp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
if (!o_tp)
goto free_mem_out;
*o_tp = driver->other->init_termios;
--
1.5.2.2
-
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 24/30] dvb: remove some unneeded vmalloc() return value casts from av7110
vmalloc() returns void * - no need to cast it.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/media/dvb/ttpci/av7110.c|2 +-
drivers/media/dvb/ttpci/av7110_ir.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb/ttpci/av7110.c b/drivers/media/dvb/ttpci/av7110.c
index 8178832..27fa5f8 100644
--- a/drivers/media/dvb/ttpci/av7110.c
+++ b/drivers/media/dvb/ttpci/av7110.c
@@ -1543,7 +1543,7 @@ static int get_firmware(struct av7110* av7110)
}
/* check if the firmware is available */
- av7110->bin_fw = (unsigned char *) vmalloc(fw->size);
+ av7110->bin_fw = vmalloc(fw->size);
if (NULL == av7110->bin_fw) {
dprintk(1, "out of memory\n");
release_firmware(fw);
diff --git a/drivers/media/dvb/ttpci/av7110_ir.c
b/drivers/media/dvb/ttpci/av7110_ir.c
index 6322800..651863b 100644
--- a/drivers/media/dvb/ttpci/av7110_ir.c
+++ b/drivers/media/dvb/ttpci/av7110_ir.c
@@ -280,7 +280,7 @@ static int av7110_ir_write_proc(struct file *file, const
char __user *buffer,
if (count < size)
return -EINVAL;
- page = (char *) vmalloc(size);
+ page = vmalloc(size);
if (!page)
return -ENOMEM;
--
1.5.2.2
-
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 23/30] video: Remove pointless kmalloc() return value cast in Zoran PCI controller driver
No need to cast the void pointer returned by kmalloc() in
drivers/media/video/zoran_driver.c::v4l_fbuffer_alloc().
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/media/video/zoran_driver.c |5 +
1 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/zoran_driver.c
b/drivers/media/video/zoran_driver.c
index 72a037b..bc2e5b3 100644
--- a/drivers/media/video/zoran_driver.c
+++ b/drivers/media/video/zoran_driver.c
@@ -347,10 +347,7 @@ v4l_fbuffer_alloc (struct file *file)
if (fh->v4l_buffers.buffer_size <= MAX_KMALLOC_MEM) {
/* Use kmalloc */
- mem =
- (unsigned char *) kmalloc(fh->v4l_buffers.
- buffer_size,
- GFP_KERNEL);
+ mem = kmalloc(fh->v4l_buffers.buffer_size, GFP_KERNEL);
if (mem == 0) {
dprintk(1,
KERN_ERR
--
1.5.2.2
-
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 take #2] MAINTAINTERS: use our mail list as Blackfin arch maintainters.
On Wed, Aug 22, 2007 at 10:55:11PM +0800, Bryan Wu wrote: > -L: [EMAIL PROTECTED] (subscribers-only) > +L: [EMAIL PROTECTED] Does your list generate a complaint message back to the sender if a non-subscriber posts to it? If so, it qualifies as a subscribers-only list. -- Mathematics is the supreme nostalgia of our time. - 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-usb-devel] [GIT PATCH] USB fixes for 2.6.23-rc3
On Fri, Aug 24, 2007 at 01:31:39AM +0200, Adrian Bunk wrote: > On Thu, Aug 23, 2007 at 04:28:31PM -0700, Greg KH wrote: > > On Thu, Aug 23, 2007 at 04:18:15PM -0700, Randy Dunlap wrote: > > > On Thu, 23 Aug 2007 15:49:56 -0700 Greg KH wrote: > > > > > > > On Fri, Aug 24, 2007 at 12:43:47AM +0200, Guennadi Liakhovetski wrote: > > > > > Hi Greg, > > > > > > > > > > sorry, this is a private egoistic request, so I took the liberty and > > > > > removed Linus and Andrew from CC: If this wouldn't make things more > > > > > difficult / worse for you and anyone else, could you perhaps post > > > > > such > > > > > patch chains as a reply to the first message (patch 0/x) and not each > > > > > subsequent patch as a reply to the previous one? It would make it > > > > > easier > > > > > to view for _me_ (remember egoistic?) because my mail agent (pine) > > > > > presents mail threads where every reply level produces a small right > > > > > offset in the subject line, so, starting from about reply number 20 > > > > > the > > > > > subject is completely off-screen. > > > > > > > > > > Again, this is a minor trouble, and, perhaps, I am the only one > > > > > suffering > > > > > from it, but if it doesn't matter either way for everyone else, I > > > > > would > > > > > really appreciate it that way. > > > > > > > > Heh, people ask me about this every few months or so, so you are not > > > > alone. > > > > > > I'd prefer that change also. In fact I just modified (trivial) > > > send_lots_of_email.pl (gregkh_patchbomb mailer) to do this, > > > except that I just have it create an mbox that I email via > > > msmtp. (and it reads a 'sendpatchset' control file for input > > > instead of needing to modify the script source file itself) > > > > I use git-send-email these days, and it already supports this with the > > --no-chain-reply-to option. I'll consider using it next time, if at > > least one more person complains about this :) > >... > > *complain* :) Heh, ok, fair enough, I'll do --no-chain-reply-to next time and see how it turns out. thanks, greg k-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/
[PATCH 22/30] ivtv: kzalloc() returns void pointer, no need to cast
Since kzalloc() returns a void pointer, we don't need to cast the
return value in drivers/media/video/ivtv/ivtv-queue.c
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/media/video/ivtv/ivtv-queue.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/ivtv/ivtv-queue.c
b/drivers/media/video/ivtv/ivtv-queue.c
index a04f938..45825b8 100644
--- a/drivers/media/video/ivtv/ivtv-queue.c
+++ b/drivers/media/video/ivtv/ivtv-queue.c
@@ -196,7 +196,7 @@ int ivtv_stream_alloc(struct ivtv_stream *s)
s->name, s->buffers, s->buf_size, s->buffers * s->buf_size /
1024);
if (ivtv_might_use_pio(s)) {
- s->PIOarray = (struct ivtv_SG_element *)kzalloc(SGsize,
GFP_KERNEL);
+ s->PIOarray = kzalloc(SGsize, GFP_KERNEL);
if (s->PIOarray == NULL) {
IVTV_ERR("Could not allocate PIOarray for %s stream\n",
s->name);
return -ENOMEM;
@@ -204,7 +204,7 @@ int ivtv_stream_alloc(struct ivtv_stream *s)
}
/* Allocate DMA SG Arrays */
- s->SGarray = (struct ivtv_SG_element *)kzalloc(SGsize, GFP_KERNEL);
+ s->SGarray = kzalloc(SGsize, GFP_KERNEL);
if (s->SGarray == NULL) {
IVTV_ERR("Could not allocate SGarray for %s stream\n", s->name);
if (ivtv_might_use_pio(s)) {
--
1.5.2.2
-
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 20/30] scsi: In the Advansys driver, do not cast allocation function return values
There's no reason to cast void pointers returned by the generic
memory allocation functions.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/scsi/advansys.c |9 +++--
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/advansys.c b/drivers/scsi/advansys.c
index 79c0b6e..b28729c 100644
--- a/drivers/scsi/advansys.c
+++ b/drivers/scsi/advansys.c
@@ -18513,7 +18513,7 @@ advansys_board_found(int iop, struct device *dev, int
bus_type)
* Allocate buffer carrier structures. The total size
* is about 4 KB, so allocate all at once.
*/
- carrp = (ADV_CARR_T *) kmalloc(ADV_CARRIER_BUFSIZE, GFP_ATOMIC);
+ carrp = kmalloc(ADV_CARRIER_BUFSIZE, GFP_ATOMIC);
ASC_DBG1(1, "advansys_board_found: carrp 0x%lx\n",
(ulong)carrp);
if (carrp == NULL) {
@@ -18529,8 +18529,7 @@ advansys_board_found(int iop, struct device *dev, int
bus_type)
for (req_cnt = adv_dvc_varp->max_host_qng;
req_cnt > 0; req_cnt--) {
- reqp = (adv_req_t *)
- kmalloc(sizeof(adv_req_t) * req_cnt, GFP_ATOMIC);
+ reqp = kmalloc(sizeof(adv_req_t) * req_cnt, GFP_ATOMIC);
ASC_DBG3(1,
"advansys_board_found: reqp 0x%lx, req_cnt %d,
bytes %lu\n",
@@ -18552,9 +18551,7 @@ advansys_board_found(int iop, struct device *dev, int
bus_type)
boardp->adv_sgblkp = NULL;
for (sg_cnt = 0; sg_cnt < ADV_TOT_SG_BLOCK; sg_cnt++) {
- sgp = (adv_sgblk_t *)
- kmalloc(sizeof(adv_sgblk_t), GFP_ATOMIC);
-
+ sgp = kmalloc(sizeof(adv_sgblk_t), GFP_ATOMIC);
if (sgp == NULL) {
break;
}
--
1.5.2.2
-
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 21/30] oss: Remove unneeded vmalloc() return value casts in OSS
vmalloc() returns a void pointer that we don't need to cast.
This patch should clean this up in sound/oss/.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
sound/oss/midibuf.c |4 ++--
sound/oss/pss.c |6 +++---
sound/oss/sequencer.c |4 ++--
sound/oss/sscape.c|2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/sound/oss/midibuf.c b/sound/oss/midibuf.c
index a40be0c..66f8a7f 100644
--- a/sound/oss/midibuf.c
+++ b/sound/oss/midibuf.c
@@ -177,7 +177,7 @@ int MIDIbuf_open(int dev, struct file *file)
return err;
parms[dev].prech_timeout = MAX_SCHEDULE_TIMEOUT;
- midi_in_buf[dev] = (struct midi_buf *) vmalloc(sizeof(struct midi_buf));
+ midi_in_buf[dev] = vmalloc(sizeof(struct midi_buf));
if (midi_in_buf[dev] == NULL)
{
@@ -187,7 +187,7 @@ int MIDIbuf_open(int dev, struct file *file)
}
midi_in_buf[dev]->len = midi_in_buf[dev]->head = midi_in_buf[dev]->tail
= 0;
- midi_out_buf[dev] = (struct midi_buf *) vmalloc(sizeof(struct
midi_buf));
+ midi_out_buf[dev] = vmalloc(sizeof(struct midi_buf));
if (midi_out_buf[dev] == NULL)
{
diff --git a/sound/oss/pss.c b/sound/oss/pss.c
index ece428b..b140584 100644
--- a/sound/oss/pss.c
+++ b/sound/oss/pss.c
@@ -872,7 +872,7 @@ static int pss_coproc_ioctl(void *dev_info, unsigned int
cmd, void __user *arg,
return 0;
case SNDCTL_COPR_LOAD:
- buf = (copr_buffer *) vmalloc(sizeof(copr_buffer));
+ buf = vmalloc(sizeof(copr_buffer));
if (buf == NULL)
return -ENOSPC;
if (copy_from_user(buf, arg, sizeof(copr_buffer))) {
@@ -884,7 +884,7 @@ static int pss_coproc_ioctl(void *dev_info, unsigned int
cmd, void __user *arg,
return err;
case SNDCTL_COPR_SENDMSG:
- mbuf = (copr_msg *)vmalloc(sizeof(copr_msg));
+ mbuf = vmalloc(sizeof(copr_msg));
if (mbuf == NULL)
return -ENOSPC;
if (copy_from_user(mbuf, arg, sizeof(copr_msg))) {
@@ -908,7 +908,7 @@ static int pss_coproc_ioctl(void *dev_info, unsigned int
cmd, void __user *arg,
case SNDCTL_COPR_RCVMSG:
err = 0;
- mbuf = (copr_msg *)vmalloc(sizeof(copr_msg));
+ mbuf = vmalloc(sizeof(copr_msg));
if (mbuf == NULL)
return -ENOSPC;
data = (unsigned short *)mbuf->data;
diff --git a/sound/oss/sequencer.c b/sound/oss/sequencer.c
index 5c215f7..cfe3dd0 100644
--- a/sound/oss/sequencer.c
+++ b/sound/oss/sequencer.c
@@ -1649,13 +1649,13 @@ void sequencer_init(void)
{
if (sequencer_ok)
return;
- queue = (unsigned char *)vmalloc(SEQ_MAX_QUEUE * EV_SZ);
+ queue = vmalloc(SEQ_MAX_QUEUE * EV_SZ);
if (queue == NULL)
{
printk(KERN_ERR "sequencer: Can't allocate memory for sequencer
output queue\n");
return;
}
- iqueue = (unsigned char *)vmalloc(SEQ_MAX_QUEUE * IEV_SZ);
+ iqueue = vmalloc(SEQ_MAX_QUEUE * IEV_SZ);
if (iqueue == NULL)
{
printk(KERN_ERR "sequencer: Can't allocate memory for sequencer
input queue\n");
diff --git a/sound/oss/sscape.c b/sound/oss/sscape.c
index 30c36d1..9d6b9b0 100644
--- a/sound/oss/sscape.c
+++ b/sound/oss/sscape.c
@@ -573,7 +573,7 @@ static int sscape_coproc_ioctl(void *dev_info, unsigned int
cmd, void __user *ar
return 0;
case SNDCTL_COPR_LOAD:
- buf = (copr_buffer *) vmalloc(sizeof(copr_buffer));
+ buf = vmalloc(sizeof(copr_buffer));
if (buf == NULL)
return -ENOSPC;
if (copy_from_user(buf, arg, sizeof(copr_buffer)))
--
1.5.2.2
-
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 03/30] um: Don't unnecessarily cast allocation return value in ubd_kern.c
On Fri, Aug 24, 2007 at 01:43:49AM +0200, Jesper Juhl wrote: > vmalloc() returns a void pointer, so casting to (void *) is pretty pointless. Righto, I'll take care of this. Jeff -- Work email - jdike at linux dot intel dot com - 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 19/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver
[kv]alloc() return void *. No need to cast the return value.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/scsi/osst.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/osst.c b/drivers/scsi/osst.c
index 08060fb..3ad9d49 100644
--- a/drivers/scsi/osst.c
+++ b/drivers/scsi/osst.c
@@ -1404,7 +1404,7 @@ static int osst_read_back_buffer_and_rewrite(struct
osst_tape * STp, struct osst
int dbg = debugging;
#endif
- if ((buffer = (unsigned char *)vmalloc((nframes + 1) * OS_DATA_SIZE))
== NULL)
+ if ((buffer = vmalloc((nframes + 1) * OS_DATA_SIZE)) == NULL)
return (-EIO);
printk(KERN_INFO "%s:I: Reading back %d frames from drive buffer%s\n",
@@ -2216,7 +2216,7 @@ static int osst_write_header(struct osst_tape * STp,
struct osst_request ** aSRp
if (STp->raw) return 0;
if (STp->header_cache == NULL) {
- if ((STp->header_cache = (os_header_t
*)vmalloc(sizeof(os_header_t))) == NULL) {
+ if ((STp->header_cache = vmalloc(sizeof(os_header_t))) == NULL)
{
printk(KERN_ERR "%s:E: Failed to allocate header
cache\n", name);
return (-ENOMEM);
}
@@ -2404,7 +2404,7 @@ static int __osst_analyze_headers(struct osst_tape * STp,
struct osst_request **
name, ppos, update_frame_cntr);
#endif
if (STp->header_cache == NULL) {
- if ((STp->header_cache = (os_header_t
*)vmalloc(sizeof(os_header_t))) == NULL) {
+ if ((STp->header_cache = vmalloc(sizeof(os_header_t)))
== NULL) {
printk(KERN_ERR "%s:E: Failed to allocate
header cache\n", name);
return 0;
}
@@ -5756,7 +5756,7 @@ static int osst_probe(struct device *dev)
write_lock(_scsi_tapes_lock);
if (os_scsi_tapes == NULL) {
os_scsi_tapes =
- (struct osst_tape **)kmalloc(osst_max_dev *
sizeof(struct osst_tape *),
+ kmalloc(osst_max_dev * sizeof(struct osst_tape *),
GFP_ATOMIC);
if (os_scsi_tapes == NULL) {
write_unlock(_scsi_tapes_lock);
--
1.5.2.2
-
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 v2 -mm 6/7] DCA: Add Direct Cache Access driver
Direct Cache Access (DCA) is a method for warming the CPU cache before data
is used, with the intent of lessening the impact of cache misses. This
patch adds a manager and interface for matching up client requests for DCA
services with devices that offer DCA services.
In order to use DCA, a module must do bus writes with the appropriate tag
bits set to trigger a cache read for a specific CPU. However, different
CPUs and chipsets can require different sets of tag bits, and the methods
for determining the correct bits may be simple hardcoding or may be a
hardware specific magic incantation. This interface is a way for DCA
clients to find the correct tag bits for the targeted CPU without needing
to know the specifics.
[Dave Miller] use DEFINE_SPINLOCK()
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/Kconfig |2 +
drivers/Makefile|1
drivers/dca/Kconfig | 11 +++
drivers/dca/Makefile|2 +
drivers/dca/dca-core.c | 168 +++
drivers/dca/dca-sysfs.c | 88 +
include/linux/dca.h | 47 +
7 files changed, 319 insertions(+), 0 deletions(-)
diff --git a/drivers/Kconfig b/drivers/Kconfig
index 3e1c442..b447e60 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -82,6 +82,8 @@ source "drivers/rtc/Kconfig"
source "drivers/dma/Kconfig"
+source "drivers/dca/Kconfig"
+
source "drivers/auxdisplay/Kconfig"
source "drivers/kvm/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index f0878b2..dbd9fa5 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -85,6 +85,7 @@ obj-$(CONFIG_CRYPTO) += crypto/
obj-$(CONFIG_SUPERH) += sh/
obj-$(CONFIG_GENERIC_TIME) += clocksource/
obj-$(CONFIG_DMA_ENGINE) += dma/
+obj-$(CONFIG_DCA) += dca/
obj-$(CONFIG_HID) += hid/
obj-$(CONFIG_PPC_PS3) += ps3/
obj-$(CONFIG_OF) += of/
diff --git a/drivers/dca/Kconfig b/drivers/dca/Kconfig
new file mode 100644
index 000..d901615
--- /dev/null
+++ b/drivers/dca/Kconfig
@@ -0,0 +1,11 @@
+#
+# DCA server configuration
+#
+
+config DCA
+ tristate "DCA support for clients and providers"
+ ---help---
+ This is a server to help modules that want to use Direct Cache
+ Access to find DCA providers that will supply correct CPU tags.
+ default m
+
diff --git a/drivers/dca/Makefile b/drivers/dca/Makefile
new file mode 100644
index 000..b2db56b
--- /dev/null
+++ b/drivers/dca/Makefile
@@ -0,0 +1,2 @@
+obj-$(CONFIG_DCA) += dca.o
+dca-objs := dca-core.o dca-sysfs.o
diff --git a/drivers/dca/dca-core.c b/drivers/dca/dca-core.c
new file mode 100644
index 000..c0ff9bd
--- /dev/null
+++ b/drivers/dca/dca-core.c
@@ -0,0 +1,168 @@
+/*
+ * Copyright(c) 2007 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/*
+ * This driver supports an interface for DCA clients and providers to meet.
+ */
+
+#include
+#include
+#include
+#include
+
+MODULE_LICENSE("GPL");
+
+/* For now we're assuming a single, global, DCA provider for the system. */
+
+static DEFINE_SPINLOCK(dca_lock);
+
+struct dca_provider *global_dca = NULL;
+
+int dca_add_requester(struct device *dev)
+{
+ int err, slot;
+
+ if (!global_dca)
+ return -ENODEV;
+
+ spin_lock(_lock);
+ slot = global_dca->ops->add_requester(global_dca, dev);
+ spin_unlock(_lock);
+ if (slot < 0)
+ return slot;
+
+ err = dca_sysfs_add_req(global_dca, dev, slot);
+ if (err) {
+ spin_lock(_lock);
+ global_dca->ops->remove_requester(global_dca, dev);
+ spin_unlock(_lock);
+ return err;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(dca_add_requester);
+
+int dca_remove_requester(struct device *dev)
+{
+ int slot;
+ if (!global_dca)
+ return -ENODEV;
+
+ spin_lock(_lock);
+ slot = global_dca->ops->remove_requester(global_dca, dev);
+ spin_unlock(_lock);
+ if (slot < 0)
+ return slot;
[PATCH v2 -mm 7/7] I/OAT: Add DCA services
Add code to connect to the DCA driver and provide cpu tags for use by
drivers that would like to use Direct Cache Access hints.
[Adrian Bunk]Several Kconfig cleanup items
[Andrew Morten, Chris Leech] fix for using cpu_physical_id() even when
built for uni-processor
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/dca/Kconfig|7 -
drivers/dma/Kconfig| 60 ++-
drivers/dma/Makefile |2
drivers/dma/ioat.c | 12 ++
drivers/dma/ioat_dca.c | 267
drivers/dma/ioatdma.h |2
6 files changed, 318 insertions(+), 32 deletions(-)
diff --git a/drivers/dca/Kconfig b/drivers/dca/Kconfig
index d901615..c2ed77c 100644
--- a/drivers/dca/Kconfig
+++ b/drivers/dca/Kconfig
@@ -3,9 +3,6 @@
#
config DCA
- tristate "DCA support for clients and providers"
- ---help---
- This is a server to help modules that want to use Direct Cache
- Access to find DCA providers that will supply correct CPU tags.
- default m
+ tristate
+
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 8f670da..955a99b 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -2,42 +2,52 @@
# DMA engine configuration
#
-menu "DMA Engine support"
- depends on HAS_DMA
+menuconfig DMADEVICES
+ bool "DMA Offload Engine support"
+ depends on (PCI && X86) || ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
+ help
+ Intel(R) offload engines enable offloading memory copies in the
+ network stack and RAID operations in the MD driver.
+
+if DMADEVICES
+
+comment "DMA Devices"
+
+config INTEL_IOATDMA
+ tristate "Intel I/OAT DMA support"
+ depends on PCI && X86
+ select DMA_ENGINE
+ select DCA
+ help
+ Enable support for the Intel(R) I/OAT DMA engine present
+ in recent chipsets.
+
+ Say Y here if you have such a chipset.
+
+ If unsure, say N.
+
+config INTEL_IOP_ADMA
+ tristate "Intel IOP ADMA support"
+ depends on ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX
+ select ASYNC_CORE
+ select DMA_ENGINE
+ help
+ Enable support for the Intel(R) IOP Series RAID engines.
config DMA_ENGINE
- bool "Support for DMA engines"
- ---help---
- DMA engines offload bulk memory operations from the CPU to dedicated
- hardware, allowing the operations to happen asynchronously.
+ bool
comment "DMA Clients"
+ depends on DMA_ENGINE
config NET_DMA
bool "Network: TCP receive copy offload"
depends on DMA_ENGINE && NET
default y
- ---help---
+ help
This enables the use of DMA engines in the network stack to
offload receive copy-to-user operations, freeing CPU cycles.
Since this is the main user of the DMA engine, it should be enabled;
say Y here.
-comment "DMA Devices"
-
-config INTEL_IOATDMA
- tristate "Intel I/OAT DMA support"
- depends on DMA_ENGINE && PCI
- default m
- ---help---
- Enable support for the Intel(R) I/OAT DMA engine.
-
-config INTEL_IOP_ADMA
-tristate "Intel IOP ADMA support"
-depends on DMA_ENGINE && (ARCH_IOP32X || ARCH_IOP33X || ARCH_IOP13XX)
- select ASYNC_CORE
-default m
----help---
- Enable support for the Intel(R) IOP Series RAID engines.
-
-endmenu
+endif
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index cec0c9c..b152cd8 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_DMA_ENGINE) += dmaengine.o
obj-$(CONFIG_NET_DMA) += iovlock.o
obj-$(CONFIG_INTEL_IOATDMA) += ioatdma.o
-ioatdma-objs := ioat.o ioat_dma.o
+ioatdma-objs := ioat.o ioat_dma.o ioat_dca.o
obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
diff --git a/drivers/dma/ioat.c b/drivers/dma/ioat.c
index 9d9f672..8ae8c53 100644
--- a/drivers/dma/ioat.c
+++ b/drivers/dma/ioat.c
@@ -1,6 +1,6 @@
/*
* Intel I/OAT DMA Linux driver
- * Copyright(c) 2004 - 2007 Intel Corporation.
+ * Copyright(c) 2007 Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify it
* under the terms and conditions of the GNU General Public License,
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include "ioatdma.h"
#include "ioatdma_registers.h"
#include "ioatdma_hw.h"
@@ -49,6 +50,7 @@ struct ioat_device {
struct pci_dev *pdev;
void __iomem*iobase;
struct ioatdma_device *dma;
+ struct dca_provider *dca;
};
static int __devinit ioat_probe(struct pci_dev *pdev,
@@ -65,6 +67,7 @@ static int ioat_setup_functionality(struct pci_dev *pdev,
void __iomem *iobase)
switch (version) {
case IOAT_VER_1_2:
device->dma = ioat_dma_probe(pdev, iobase);
+
[PATCH v2 -mm 4/7] I/OAT: Split PCI startup from DMA handling code
Split the general PCI startup from the DMA handling code in order to
prepare for adding support for DCA services and future versions of the
ioatdma device.
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/dma/Makefile |2
drivers/dma/ioat.c | 186
drivers/dma/ioat_dma.c | 196 +++---
drivers/dma/ioatdma.h| 16 +++-
drivers/dma/ioatdma_hw.h |2
5 files changed, 245 insertions(+), 157 deletions(-)
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 77bee99..cec0c9c 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -1,5 +1,5 @@
obj-$(CONFIG_DMA_ENGINE) += dmaengine.o
obj-$(CONFIG_NET_DMA) += iovlock.o
obj-$(CONFIG_INTEL_IOATDMA) += ioatdma.o
-ioatdma-objs := ioat_dma.o
+ioatdma-objs := ioat.o ioat_dma.o
obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
diff --git a/drivers/dma/ioat.c b/drivers/dma/ioat.c
new file mode 100644
index 000..9d9f672
--- /dev/null
+++ b/drivers/dma/ioat.c
@@ -0,0 +1,186 @@
+/*
+ * Intel I/OAT DMA Linux driver
+ * Copyright(c) 2004 - 2007 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ */
+
+/*
+ * This driver supports an Intel I/OAT DMA engine, which does asynchronous
+ * copy operations.
+ */
+
+#include
+#include
+#include
+#include
+#include "ioatdma.h"
+#include "ioatdma_registers.h"
+#include "ioatdma_hw.h"
+
+MODULE_VERSION("1.24");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Intel Corporation");
+
+static struct pci_device_id ioat_pci_tbl[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_CNB) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_SCNB) },
+ { PCI_DEVICE(PCI_VENDOR_ID_UNISYS, PCI_DEVICE_ID_UNISYS_DMA_DIRECTOR) },
+ { 0, }
+};
+
+struct ioat_device {
+ struct pci_dev *pdev;
+ void __iomem*iobase;
+ struct ioatdma_device *dma;
+};
+
+static int __devinit ioat_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id);
+static void __devexit ioat_remove(struct pci_dev *pdev);
+
+static int ioat_setup_functionality(struct pci_dev *pdev, void __iomem *iobase)
+{
+ struct ioat_device *device = pci_get_drvdata(pdev);
+ u8 version;
+ int err = 0;
+
+ version = readb(iobase + IOAT_VER_OFFSET);
+ switch (version) {
+ case IOAT_VER_1_2:
+ device->dma = ioat_dma_probe(pdev, iobase);
+ break;
+ default:
+ err = -ENODEV;
+ break;
+ }
+ return err;
+}
+
+static void ioat_shutdown_functionality(struct pci_dev *pdev)
+{
+ struct ioat_device *device = pci_get_drvdata(pdev);
+
+ if (device->dma) {
+ ioat_dma_remove(device->dma);
+ device->dma = NULL;
+ }
+}
+
+static struct pci_driver ioat_pci_drv = {
+ .name = "ioatdma",
+ .id_table = ioat_pci_tbl,
+ .probe = ioat_probe,
+ .shutdown = ioat_shutdown_functionality,
+ .remove = __devexit_p(ioat_remove),
+};
+
+static int __devinit ioat_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ void __iomem *iobase;
+ struct ioat_device *device;
+ unsigned long mmio_start, mmio_len;
+ int err;
+
+ err = pci_enable_device(pdev);
+ if (err)
+ goto err_enable_device;
+
+ err = pci_request_regions(pdev, ioat_pci_drv.name);
+ if (err)
+ goto err_request_regions;
+
+ err = pci_set_dma_mask(pdev, DMA_64BIT_MASK);
+ if (err)
+ err = pci_set_dma_mask(pdev, DMA_32BIT_MASK);
+ if (err)
+ goto err_set_dma_mask;
+
+ err = pci_set_consistent_dma_mask(pdev, DMA_64BIT_MASK);
+ if (err)
+ err = pci_set_consistent_dma_mask(pdev, DMA_32BIT_MASK);
+ if (err)
+ goto err_set_dma_mask;
+
+ mmio_start = pci_resource_start(pdev, 0);
+ mmio_len = pci_resource_len(pdev, 0);
+
[PATCH v2 -mm 5/7] I/OAT: Add support for MSI and MSI-X
Add support for MSI and MSI-X interrupt handling, including the ability
to choose the desired interrupt method.
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/dma/ioat_dma.c | 353 ---
drivers/dma/ioatdma.h | 12 +
drivers/dma/ioatdma_registers.h |6 +
3 files changed, 305 insertions(+), 66 deletions(-)
diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
index 9012176..0909fee 100644
--- a/drivers/dma/ioat_dma.c
+++ b/drivers/dma/ioat_dma.c
@@ -47,6 +47,71 @@
static void ioat_dma_start_null_desc(struct ioat_dma_chan *ioat_chan);
static void ioat_dma_memcpy_cleanup(struct ioat_dma_chan *ioat_chan);
+#define for_each_bit(bit, addr, size) \
+ for ((bit) = find_first_bit((addr), (size)); \
+(bit) < (size); \
+(bit) = find_next_bit((addr), (size), (bit) + 1))
+
+
+struct ioat_dma_chan *ioat_lookup_chan_by_index(struct ioatdma_device *device,
+ int index)
+{
+ return device->idx[index];
+}
+
+/**
+ * ioat_dma_do_interrupt - handler used for single vector interrupt mode
+ * @irq: interrupt id
+ * @data: interrupt data
+ */
+static irqreturn_t ioat_dma_do_interrupt(int irq, void *data)
+{
+ struct ioatdma_device *instance = data;
+ struct ioat_dma_chan *ioat_chan;
+ unsigned long attnstatus;
+ int bit;
+ u8 intrctrl;
+
+ intrctrl = readb(instance->reg_base + IOAT_INTRCTRL_OFFSET);
+
+ if (!(intrctrl & IOAT_INTRCTRL_MASTER_INT_EN))
+ return IRQ_NONE;
+
+ if (!(intrctrl & IOAT_INTRCTRL_INT_STATUS)) {
+ writeb(intrctrl, instance->reg_base + IOAT_INTRCTRL_OFFSET);
+ return IRQ_NONE;
+ }
+
+ attnstatus = readl(instance->reg_base + IOAT_ATTNSTATUS_OFFSET);
+ for_each_bit (bit, , BITS_PER_LONG) {
+ ioat_chan = ioat_lookup_chan_by_index(instance, bit);
+ tasklet_schedule(_chan->cleanup_task);
+ }
+
+ writeb(intrctrl, instance->reg_base + IOAT_INTRCTRL_OFFSET);
+ return IRQ_HANDLED;
+}
+
+/**
+ * ioat_dma_do_interrupt_msix - handler used for vector-per-channel interrupt
mode
+ * @irq: interrupt id
+ * @data: interrupt data
+ */
+static irqreturn_t ioat_dma_do_interrupt_msix(int irq, void *data)
+{
+ struct ioat_dma_chan *ioat_chan = data;
+
+ tasklet_schedule(_chan->cleanup_task);
+
+ return IRQ_HANDLED;
+}
+
+static void ioat_dma_cleanup_tasklet(unsigned long data);
+
+/**
+ * ioat_dma_enumerate_channels - find and initialize the device's channels
+ * @device: the device to be enumerated
+ */
static int ioat_dma_enumerate_channels(struct ioatdma_device *device)
{
u8 xfercap_scale;
@@ -76,6 +141,11 @@ static int ioat_dma_enumerate_channels(struct
ioatdma_device *device)
ioat_chan->common.device = >common;
list_add_tail(_chan->common.device_node,
>common.channels);
+ device->idx[i] = ioat_chan;
+ tasklet_init(_chan->cleanup_task,
+ioat_dma_cleanup_tasklet,
+(unsigned long) ioat_chan);
+ tasklet_disable(_chan->cleanup_task);
}
return device->common.chancnt;
}
@@ -234,6 +304,7 @@ static int ioat_dma_alloc_chan_resources(struct dma_chan
*chan)
writel(((u64) ioat_chan->completion_addr) >> 32,
ioat_chan->reg_base + IOAT_CHANCMP_OFFSET_HIGH);
+ tasklet_enable(_chan->cleanup_task);
ioat_dma_start_null_desc(ioat_chan);
return i;
}
@@ -245,9 +316,14 @@ static void ioat_dma_free_chan_resources(struct dma_chan
*chan)
struct ioat_desc_sw *desc, *_desc;
int in_use_descs = 0;
+ tasklet_disable(_chan->cleanup_task);
ioat_dma_memcpy_cleanup(ioat_chan);
+ /* Delay 100ms after reset to allow internal DMA logic to quiesce
+* before removing DMA descriptor resources.
+*/
writeb(IOAT_CHANCMD_RESET, ioat_chan->reg_base + IOAT_CHANCMD_OFFSET);
+ mdelay(100);
spin_lock_bh(_chan->desc_lock);
list_for_each_entry_safe(desc, _desc, _chan->used_desc, node) {
@@ -276,6 +352,34 @@ static void ioat_dma_free_chan_resources(struct dma_chan
*chan)
in_use_descs - 1);
ioat_chan->last_completion = ioat_chan->completion_addr = 0;
+ ioat_chan->pending = 0;
+}
+/**
+ * ioat_dma_get_next_descriptor - return the next available descriptor from
+ * the chain
+ * @ioat_chan: IOAT DMA channel handle
+ * Gets the next descriptor from the chain, and must be called with the
+ * channel's desc_lock held. Allocates more descriptors if the channel
+ * has run out.
+ */
+static struct ioat_desc_sw *ioat_dma_get_next_descriptor(
+ struct ioat_dma_chan
[PATCH v2 -mm 2/7] I/OAT: Rename the source file
Rename the ioatdma.c file in preparation for splitting into multiple files,
which will allow for easier adding new functionality.
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/dma/Makefile |1
drivers/dma/ioat_dma.c | 828
drivers/dma/ioatdma.c | 828
3 files changed, 829 insertions(+), 828 deletions(-)
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index b3839b6..77bee99 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_DMA_ENGINE) += dmaengine.o
obj-$(CONFIG_NET_DMA) += iovlock.o
obj-$(CONFIG_INTEL_IOATDMA) += ioatdma.o
+ioatdma-objs := ioat_dma.o
obj-$(CONFIG_INTEL_IOP_ADMA) += iop-adma.o
diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
new file mode 100644
index 000..55227d4
--- /dev/null
+++ b/drivers/dma/ioat_dma.c
@@ -0,0 +1,828 @@
+/*
+ * Copyright(c) 2004 - 2006 Intel Corporation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program; if not, write to the Free Software Foundation, Inc., 59
+ * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * The full GNU General Public License is included in this distribution in the
+ * file called COPYING.
+ */
+
+/*
+ * This driver supports an Intel I/OAT DMA engine, which does asynchronous
+ * copy operations.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "ioatdma.h"
+#include "ioatdma_registers.h"
+#include "ioatdma_hw.h"
+
+#define to_ioat_chan(chan) container_of(chan, struct ioat_dma_chan, common)
+#define to_ioat_device(dev) container_of(dev, struct ioat_device, common)
+#define to_ioat_desc(lh) container_of(lh, struct ioat_desc_sw, node)
+#define tx_to_ioat_desc(tx) container_of(tx, struct ioat_desc_sw, async_tx)
+
+/* internal functions */
+static int __devinit ioat_probe(struct pci_dev *pdev, const struct
pci_device_id *ent);
+static void ioat_shutdown(struct pci_dev *pdev);
+static void __devexit ioat_remove(struct pci_dev *pdev);
+
+static int enumerate_dma_channels(struct ioat_device *device)
+{
+ u8 xfercap_scale;
+ u32 xfercap;
+ int i;
+ struct ioat_dma_chan *ioat_chan;
+
+ device->common.chancnt = readb(device->reg_base + IOAT_CHANCNT_OFFSET);
+ xfercap_scale = readb(device->reg_base + IOAT_XFERCAP_OFFSET);
+ xfercap = (xfercap_scale == 0 ? -1 : (1UL << xfercap_scale));
+
+ for (i = 0; i < device->common.chancnt; i++) {
+ ioat_chan = kzalloc(sizeof(*ioat_chan), GFP_KERNEL);
+ if (!ioat_chan) {
+ device->common.chancnt = i;
+ break;
+ }
+
+ ioat_chan->device = device;
+ ioat_chan->reg_base = device->reg_base + (0x80 * (i + 1));
+ ioat_chan->xfercap = xfercap;
+ spin_lock_init(_chan->cleanup_lock);
+ spin_lock_init(_chan->desc_lock);
+ INIT_LIST_HEAD(_chan->free_desc);
+ INIT_LIST_HEAD(_chan->used_desc);
+ /* This should be made common somewhere in dmaengine.c */
+ ioat_chan->common.device = >common;
+ list_add_tail(_chan->common.device_node,
+ >common.channels);
+ }
+ return device->common.chancnt;
+}
+
+static void
+ioat_set_src(dma_addr_t addr, struct dma_async_tx_descriptor *tx, int index)
+{
+ struct ioat_desc_sw *iter, *desc = tx_to_ioat_desc(tx);
+ struct ioat_dma_chan *ioat_chan = to_ioat_chan(tx->chan);
+
+ pci_unmap_addr_set(desc, src, addr);
+
+ list_for_each_entry(iter, >async_tx.tx_list, node) {
+ iter->hw->src_addr = addr;
+ addr += ioat_chan->xfercap;
+ }
+
+}
+
+static void
+ioat_set_dest(dma_addr_t addr, struct dma_async_tx_descriptor *tx, int index)
+{
+ struct ioat_desc_sw *iter, *desc = tx_to_ioat_desc(tx);
+ struct ioat_dma_chan *ioat_chan = to_ioat_chan(tx->chan);
+
+ pci_unmap_addr_set(desc, dst, addr);
+
+ list_for_each_entry(iter, >async_tx.tx_list, node) {
+ iter->hw->dst_addr = addr;
+ addr += ioat_chan->xfercap;
+ }
+}
+
+static dma_cookie_t
+ioat_tx_submit(struct dma_async_tx_descriptor *tx)
+{
+ struct ioat_dma_chan
[PATCH v2 -mm 3/7] I/OAT: code cleanup from checkpatch output
Take care of a bunch of little code nits in ioatdma files
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/dma/ioat_dma.c | 200 +++-
1 files changed, 111 insertions(+), 89 deletions(-)
diff --git a/drivers/dma/ioat_dma.c b/drivers/dma/ioat_dma.c
index 55227d4..9a4d154 100644
--- a/drivers/dma/ioat_dma.c
+++ b/drivers/dma/ioat_dma.c
@@ -1,10 +1,10 @@
/*
- * Copyright(c) 2004 - 2006 Intel Corporation. All rights reserved.
+ * Intel I/OAT DMA Linux driver
+ * Copyright(c) 2004 - 2007 Intel Corporation.
*
* This program is free software; you can redistribute it and/or modify it
- * under the terms of the GNU General Public License as published by the Free
- * Software Foundation; either version 2 of the License, or (at your option)
- * any later version.
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
*
* This program is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
@@ -12,11 +12,12 @@
* more details.
*
* You should have received a copy of the GNU General Public License along with
- * this program; if not, write to the Free Software Foundation, Inc., 59
- * Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
*
- * The full GNU General Public License is included in this distribution in the
- * file called COPYING.
*/
/*
@@ -35,17 +36,22 @@
#include "ioatdma_registers.h"
#include "ioatdma_hw.h"
+#define INITIAL_IOAT_DESC_COUNT 128
+
#define to_ioat_chan(chan) container_of(chan, struct ioat_dma_chan, common)
#define to_ioat_device(dev) container_of(dev, struct ioat_device, common)
#define to_ioat_desc(lh) container_of(lh, struct ioat_desc_sw, node)
#define tx_to_ioat_desc(tx) container_of(tx, struct ioat_desc_sw, async_tx)
/* internal functions */
-static int __devinit ioat_probe(struct pci_dev *pdev, const struct
pci_device_id *ent);
+static void ioat_dma_start_null_desc(struct ioat_dma_chan *ioat_chan);
+static void ioat_dma_memcpy_cleanup(struct ioat_dma_chan *ioat_chan);
+static int __devinit ioat_probe(struct pci_dev *pdev,
+ const struct pci_device_id *ent);
static void ioat_shutdown(struct pci_dev *pdev);
static void __devexit ioat_remove(struct pci_dev *pdev);
-static int enumerate_dma_channels(struct ioat_device *device)
+static int ioat_dma_enumerate_channels(struct ioat_device *device)
{
u8 xfercap_scale;
u32 xfercap;
@@ -73,13 +79,14 @@ static int enumerate_dma_channels(struct ioat_device
*device)
/* This should be made common somewhere in dmaengine.c */
ioat_chan->common.device = >common;
list_add_tail(_chan->common.device_node,
- >common.channels);
+ >common.channels);
}
return device->common.chancnt;
}
-static void
-ioat_set_src(dma_addr_t addr, struct dma_async_tx_descriptor *tx, int index)
+static void ioat_set_src(dma_addr_t addr,
+struct dma_async_tx_descriptor *tx,
+int index)
{
struct ioat_desc_sw *iter, *desc = tx_to_ioat_desc(tx);
struct ioat_dma_chan *ioat_chan = to_ioat_chan(tx->chan);
@@ -93,8 +100,9 @@ ioat_set_src(dma_addr_t addr, struct dma_async_tx_descriptor
*tx, int index)
}
-static void
-ioat_set_dest(dma_addr_t addr, struct dma_async_tx_descriptor *tx, int index)
+static void ioat_set_dest(dma_addr_t addr,
+ struct dma_async_tx_descriptor *tx,
+ int index)
{
struct ioat_desc_sw *iter, *desc = tx_to_ioat_desc(tx);
struct ioat_dma_chan *ioat_chan = to_ioat_chan(tx->chan);
@@ -107,8 +115,7 @@ ioat_set_dest(dma_addr_t addr, struct
dma_async_tx_descriptor *tx, int index)
}
}
-static dma_cookie_t
-ioat_tx_submit(struct dma_async_tx_descriptor *tx)
+static dma_cookie_t ioat_tx_submit(struct dma_async_tx_descriptor *tx)
{
struct ioat_dma_chan *ioat_chan = to_ioat_chan(tx->chan);
struct ioat_desc_sw *desc = tx_to_ioat_desc(tx);
@@ -141,13 +148,13 @@ ioat_tx_submit(struct dma_async_tx_descriptor *tx)
if (append)
writeb(IOAT_CHANCMD_APPEND,
ioat_chan->reg_base + IOAT_CHANCMD_OFFSET);
-
+
return cookie;
}
static struct ioat_desc_sw *ioat_dma_alloc_descriptor(
- struct ioat_dma_chan *ioat_chan,
- gfp_t flags)
+ struct ioat_dma_chan *ioat_chan,
+ gfp_t
[PATCH v2 -mm 1/7] I/OAT: New device ids
Add device ids for new revs of the Intel I/OAT DMA engine
Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
---
drivers/dma/ioatdma.c |5 +++--
include/linux/pci_ids.h |2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index 2d1f178..55227d4 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -516,8 +516,9 @@ static enum dma_status ioat_dma_is_complete(struct dma_chan
*chan,
static struct pci_device_id ioat_pci_tbl[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT) },
- { PCI_DEVICE(PCI_VENDOR_ID_UNISYS,
-PCI_DEVICE_ID_UNISYS_DMA_DIRECTOR) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_CNB) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_SCNB) },
+ { PCI_DEVICE(PCI_VENDOR_ID_UNISYS, PCI_DEVICE_ID_UNISYS_DMA_DIRECTOR) },
{ 0, }
};
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index 07fc574..d4883bd 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2287,6 +2287,8 @@
#define PCI_DEVICE_ID_INTEL_MCH_PC 0x3599
#define PCI_DEVICE_ID_INTEL_MCH_PC10x359a
#define PCI_DEVICE_ID_INTEL_E7525_MCH 0x359e
+#define PCI_DEVICE_ID_INTEL_IOAT_CNB 0x360b
+#define PCI_DEVICE_ID_INTEL_IOAT_SCNB 0x65ff
#define PCI_DEVICE_ID_INTEL_82371SB_0 0x7000
#define PCI_DEVICE_ID_INTEL_82371SB_1 0x7010
#define PCI_DEVICE_ID_INTEL_82371SB_2 0x7020
-
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 18/30] isdn: eicon - get rid of a pointless vmalloc() return value cast
vmalloc() returns void*.
No need to cast in drivers/isdn/hardware/eicon/platform.h::diva_os_malloc()
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/isdn/hardware/eicon/platform.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/isdn/hardware/eicon/platform.h
b/drivers/isdn/hardware/eicon/platform.h
index 15d4942..8756ef1 100644
--- a/drivers/isdn/hardware/eicon/platform.h
+++ b/drivers/isdn/hardware/eicon/platform.h
@@ -167,7 +167,7 @@ static __inline__ void* diva_os_malloc (unsigned long
flags, unsigned long size)
void *ret = NULL;
if (size) {
- ret = (void *) vmalloc((unsigned int) size);
+ ret = vmalloc((unsigned int)size);
}
return (ret);
}
--
1.5.2.2
-
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 v2 -mm 0/7] I/OAT: Add support for DCA - Direct Cache Access
Andrew, Here's a new rev of the IOAT DCA patches that are currently in -mm. These patches include updates based on feedback on the first set, as well as a couple of other fixes we found internally. These were originally posted on 20-Jul-2007 - see http://marc.info/?l=linux-kernel=118489237427303=2 The following series implements support for providers and clients of Direct Cache Access (DCA), a method for warming the cache in the correct CPU before needing data. ioat-new-device-ids.patch - add devices id's for newer Intel chipsets which support DMA and DCA ioat-rename-source-file.patch - prepare for adding new functionality ioat-dma-cleanups.patch - cleanup some code ugliness ioat-split-startup-code.patch - split the DMA support code from the PCI startup ioat-add-msi-msix-support.patch - add support for various interrupt handling schemes ioat-add-dca-support.patch - add the dca driver ioat-add-ioat-dca.patch - add DCA services to the ioatdma driver b/drivers/Kconfig |2 b/drivers/Makefile|1 b/drivers/dca/Kconfig |8 b/drivers/dca/Makefile|2 b/drivers/dca/dca-core.c | 168 ++ b/drivers/dca/dca-sysfs.c | 88 +++ b/drivers/dma/Kconfig | 60 +- b/drivers/dma/Makefile|1 b/drivers/dma/ioat.c | 196 +++ b/drivers/dma/ioat_dca.c | 267 ++ b/drivers/dma/ioat_dma.c | 967 ++ b/drivers/dma/ioatdma.h | 30 + b/drivers/dma/ioatdma_hw.h|2 b/drivers/dma/ioatdma_registers.h |6 b/include/linux/dca.h | 47 + b/include/linux/pci_ids.h |2 drivers/dma/ioatdma.c | 827 17 files changed, 1816 insertions(+), 858 deletions(-) Thanks, sln -- == Mr. Shannon Nelson LAN Access Division, Intel Corp. [EMAIL PROTECTED]I don't speak for Intel (503) 712-7659Parents can't afford to be squeamish. - 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 17/30] isdn: Get rid of some pointless allocation casts in common and bsd comp.
vmalloc() returns a void pointer - no need to cast the return value.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/isdn/i4l/isdn_bsdcomp.c |5 ++---
drivers/isdn/i4l/isdn_common.c |2 +-
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/isdn/i4l/isdn_bsdcomp.c b/drivers/isdn/i4l/isdn_bsdcomp.c
index 90a2379..02d9918 100644
--- a/drivers/isdn/i4l/isdn_bsdcomp.c
+++ b/drivers/isdn/i4l/isdn_bsdcomp.c
@@ -341,7 +341,7 @@ static void *bsd_alloc (struct isdn_ppp_comp_data *data)
* Allocate space for the dictionary. This may be more than one page in
* length.
*/
- db->dict = (struct bsd_dict *) vmalloc (hsize * sizeof (struct
bsd_dict));
+ db->dict = vmalloc(hsize * sizeof(struct bsd_dict));
if (!db->dict) {
bsd_free (db);
return NULL;
@@ -354,8 +354,7 @@ static void *bsd_alloc (struct isdn_ppp_comp_data *data)
if (!decomp)
db->lens = NULL;
else {
- db->lens = (unsigned short *) vmalloc ((maxmaxcode + 1) *
- sizeof (db->lens[0]));
+ db->lens = vmalloc((maxmaxcode + 1) * sizeof(db->lens[0]));
if (!db->lens) {
bsd_free (db);
return (NULL);
diff --git a/drivers/isdn/i4l/isdn_common.c b/drivers/isdn/i4l/isdn_common.c
index c97330b..ec5f404 100644
--- a/drivers/isdn/i4l/isdn_common.c
+++ b/drivers/isdn/i4l/isdn_common.c
@@ -2291,7 +2291,7 @@ static int __init isdn_init(void)
int i;
char tmprev[50];
- if (!(dev = (isdn_dev *) vmalloc(sizeof(isdn_dev {
+ if (!(dev = vmalloc(sizeof(isdn_dev {
printk(KERN_WARNING "isdn: Could not allocate
device-struct.\n");
return -EIO;
}
--
1.5.2.2
-
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] memchr (trivial) optimization
On Thu, Aug 23, 2007 at 02:13:20AM +0200, Ingo Oeser wrote:
> On Wednesday 22 August 2007, lode leroy wrote:
> > While profiling something completely unrelated, I noticed
> > that on the workloads I used memchr for, I saw a 30%-40% improvement
> > in performance, with the following trivial changes...
> > (basically, it saves 3 operations for each call)
>
> Yes, but then you could be a bit more explicit to the compiler
> on what you are doing here:
>
> void *memchr(const void *s, int c, size_t n)
> {
> const unsigned char *p = s;
>
> for (; n != 0; n--, p++) {
>if ((unsigned char)c == *p) {
>return (void *)p;
> }
> return NULL;
> }
>
> Now the compiler should see the loop more clearly.
And you can do even better with this:
void *memchr(const void *s, int c, size_t n)
{
const unsigned char *p = s, *e = s + n;
const unsigned char *e = p + n;
for (; p < e ; p++)
if ((unsigned char)c == *p)
return (void *)p;
return NULL;
}
which changes the inner loop from:
50: 38 08 cmp%cl,(%eax)
52: 74 08 je 5c
54: 4a dec%edx
55: 40 inc%eax
56: 85 d2 test %edx,%edx
58: 75 f6 jne50
to:
6e: 38 08 cmp%cl,(%eax)
70: 74 07 je 79
72: 40 inc%eax
73: 39 d0 cmp%edx,%eax
75: 72 f7 jb 6e
--
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc3-mm1 - memory layout change? - lost support for MAP_32BIT? - mono crashes
(some more CCs added) On Thu, 23 Aug 2007, Andrew Morton wrote: > It is quite unobvious to me that the whole pie-randomization thing is > worth merging. Why shouldn't we just drop the lot? Hi Andrew, well, whenever it comes to address space layout randomization, there usually follows a huge debate whether it is needed or not, some people think it's useful and powerful security protection against 0day attacks, other people think that it's just fighting the bugs in userspace software in a wrong way. Opinions differ, that's why there is a way to turn the VA space randomization completely off trivially. We already have randomized stack, randomized mmap base, randomized vdso page in mainline kernel, but code and heap still stay on deterministic addresses. I think providing the possibility for users to have really full address space randomization (if they want to) is much better than providing the current slightly crippled state, when some parts of address space are randomized and some are not. Or do you think we should rather rip all the randomization off? And it's almost certain to me that users want this functionality - look major distros. They seem to have out-of-tree patches to provide this functionality to their users, IMHO. Thanks, -- Jiri Kosina - 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 16/30] net: Avoid pointless allocation casts in BSD compression module
The general kernel memory allocation functions return void pointers
and there is no need to cast their return values.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/net/bsd_comp.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/net/bsd_comp.c b/drivers/net/bsd_comp.c
index 202d4a4..88edb98 100644
--- a/drivers/net/bsd_comp.c
+++ b/drivers/net/bsd_comp.c
@@ -406,8 +406,7 @@ static void *bsd_alloc (unsigned char *options, int
opt_len, int decomp)
* Allocate space for the dictionary. This may be more than one page in
* length.
*/
-db->dict = (struct bsd_dict *) vmalloc (hsize *
- sizeof (struct bsd_dict));
+db->dict = vmalloc(hsize * sizeof(struct bsd_dict));
if (!db->dict)
{
bsd_free (db);
@@ -426,8 +425,7 @@ static void *bsd_alloc (unsigned char *options, int
opt_len, int decomp)
*/
else
{
-db->lens = (unsigned short *) vmalloc ((maxmaxcode + 1) *
- sizeof (db->lens[0]));
+db->lens = vmalloc((maxmaxcode + 1) * sizeof(db->lens[0]));
if (!db->lens)
{
bsd_free (db);
--
1.5.2.2
-
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 14/30] net: Kill some unneeded allocation return value casts in libertas
kmalloc() and friends return void*, no need to cast it. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/net/wireless/libertas/debugfs.c |2 +- drivers/net/wireless/libertas/ethtool.c |3 +-- 2 files changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/net/wireless/libertas/debugfs.c b/drivers/net/wireless/libertas/debugfs.c index 715cbda..6ade63e 100644 --- a/drivers/net/wireless/libertas/debugfs.c +++ b/drivers/net/wireless/libertas/debugfs.c @@ -1839,7 +1839,7 @@ static ssize_t wlan_debugfs_write(struct file *f, const char __user *buf, char *p2; struct debug_data *d = (struct debug_data *)f->private_data; - pdata = (char *)kmalloc(cnt, GFP_KERNEL); + pdata = kmalloc(cnt, GFP_KERNEL); if (pdata == NULL) return 0; diff --git a/drivers/net/wireless/libertas/ethtool.c b/drivers/net/wireless/libertas/ethtool.c index 96f1974..7dad493 100644 --- a/drivers/net/wireless/libertas/ethtool.c +++ b/drivers/net/wireless/libertas/ethtool.c @@ -60,8 +60,7 @@ static int libertas_ethtool_get_eeprom(struct net_device *dev, // mutex_lock(>mutex); - adapter->prdeeprom = - (char *)kmalloc(eeprom->len+sizeof(regctrl), GFP_KERNEL); + adapter->prdeeprom = kmalloc(eeprom->len+sizeof(regctrl), GFP_KERNEL); if (!adapter->prdeeprom) return -ENOMEM; memcpy(adapter->prdeeprom, , sizeof(regctrl)); -- 1.5.2.2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22.5 forcedeth timeout hang
100% reproducible hang on xmit timeout.
Just do a "make -j4 modules" on an nfs mounted kernel source.
attached is the messages log
berkley
--
// E. F. Berkley Shands, MSc//
** Exegy Inc.**
349 Marshall Road, Suite 100
St. Louis , MO 63119
Direct: (314) 218-3600 X450
Cell: (314) 303-2546
Office: (314) 218-3600
Fax: (314) 218-3601
The Usual Disclaimer follows...
This e-mail and any documents accompanying it may contain legally privileged
and/or confidential information belonging to Exegy, Inc. Such information may
be protected from disclosure by law. The information is intended for use by
only the addressee. If you are not the intended recipient, you are hereby
notified that any disclosure or use of the information is strictly prohibited.
If you have received this e-mail in error, please immediately contact the
sender by e-mail or phone regarding instructions for return or destruction and
do not use or disclose the content to others.
Aug 23 18:34:55 crash kernel: [30819.690155] NETDEV WATCHDOG: eth1: transmit
timed out
Aug 23 18:34:55 crash kernel: [30819.690162] eth1: Got tx_timeout. irq: 0036
Aug 23 18:34:55 crash kernel: [30819.690164] eth1: Ring at 16e086000
Aug 23 18:34:55 crash kernel: [30819.690166] eth1: Dumping tx registers
Aug 23 18:34:55 crash kernel: [30819.690171] 0: 0036 00ff 0003
024e03ca
Aug 23 18:34:55 crash kernel: [30819.690176] 20: 06255300 ff701365
Aug 23 18:34:55 crash kernel: [30819.690181] 40: 0420e20e a855 2e20
Aug 23 18:34:55 crash kernel: [30819.690186] 60:
Aug 23 18:34:55 crash kernel: [30819.690192] 80: 003b0f3c 0001 0004
007f0020 061c 0001 0020 7f87
Aug 23 18:34:55 crash kernel: [30819.690197] a0: 0014050f 0016 5781e000
020a 0001 a800cccd fcf5
Aug 23 18:34:55 crash kernel: [30819.690203] c0: 1002 0001 0001
0001 0001 0001 0001 0001
Aug 23 18:34:55 crash kernel: [30819.690207] e0: 0001 0001 0001
0001 0001 0001 0001 0001
Aug 23 18:34:55 crash kernel: [30819.690213] 100: 6e086800 6e086000 007f00ff
8000 00010032 002c 6e0874c0
Aug 23 18:34:55 crash kernel: [30819.690220] 120: 6e086360 1ca37240 a000ffeb
6e0874cc 6e08636c 0fe08000
Aug 23 18:34:55 crash kernel: [30819.690225] 140: 00304120 80002600 0001
0001
Aug 23 18:34:55 crash kernel: [30819.690229] 160:
Aug 23 18:34:55 crash kernel: [30819.690235] 180: 0016 0008 0194796d
8103 002a 3800 0194000f 0003
Aug 23 18:34:55 crash kernel: [30819.690241] 1a0: 0016 0008 0194796d
8103 002a 3800 0194000f 0003
Aug 23 18:34:55 crash kernel: [30819.690246] 1c0: 0016 0008 0194796d
8103 002a 3800 0194000f 0003
Aug 23 18:34:55 crash kernel: [30819.690252] 1e0: 0016 0008 0194796d
8103 002a 3800 0194000f 0003
Aug 23 18:34:55 crash kernel: [30819.690257] 200:
Aug 23 18:34:55 crash kernel: [30819.690261] 220:
Aug 23 18:34:55 crash kernel: [30819.690266] 240:
Aug 23 18:34:55 crash kernel: [30819.690271] 260: fe020001
0100 7e020001 0100
Aug 23 18:34:55 crash kernel: [30819.690276] 280:
Aug 23 18:34:55 crash kernel: [30819.690280] 2a0:
Aug 23 18:34:55 crash kernel: [30819.690285] 2c0:
0001 0001 0001
Aug 23 18:34:55 crash kernel: [30819.690287] eth1: Dumping tx ring
Aug 23 18:34:55 crash kernel: [30819.690292] 000: 8fd00892 2052 //
88115c92 2052 // 875ae892 2052 // 8a660492
2052
Aug 23 18:34:55 crash kernel: [30819.690298] 004: 0001 61fdb492 2052 //
8bf3f892 2052 // 8daa7092 2052 // 8fa29892
2052
Aug 23 18:34:55 crash kernel: [30819.690304] 008: 0001 0d558892 2052 //
8e0bf892 2052 // 8fd00492 2052 // 8d160092
2052
Aug 23 18:34:55 crash kernel: [30819.690310] 00c: 0001 27698092 2052 //
7fc6cc92 2052 // 8d03ec92 2052 // 88085492
2052
Aug 23 18:34:55 crash kernel: [30819.690317] 010: 850ee492 2052 //
8bba8c92 2052 // 0001 56108492 2052 //
[PATCH 09/30] mtd: Don't cast kmalloc() return value in drivers/mtd/maps/pmcmsp-flash.c
kmalloc() returns a void pointer. No need to cast it. Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/mtd/maps/pmcmsp-flash.c | 13 + 1 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/mtd/maps/pmcmsp-flash.c b/drivers/mtd/maps/pmcmsp-flash.c index 7e0377e..dfdb120 100644 --- a/drivers/mtd/maps/pmcmsp-flash.c +++ b/drivers/mtd/maps/pmcmsp-flash.c @@ -73,12 +73,9 @@ int __init init_msp_flash(void) return -ENXIO; printk(KERN_NOTICE "Found %d PMC flash devices\n", fcnt); - msp_flash = (struct mtd_info **)kmalloc( - fcnt * sizeof(struct map_info *), GFP_KERNEL); - msp_parts = (struct mtd_partition **)kmalloc( - fcnt * sizeof(struct mtd_partition *), GFP_KERNEL); - msp_maps = (struct map_info *)kmalloc( - fcnt * sizeof(struct mtd_info), GFP_KERNEL); + msp_flash = kmalloc(fcnt * sizeof(struct map_info *), GFP_KERNEL); + msp_parts = kmalloc(fcnt * sizeof(struct mtd_partition *), GFP_KERNEL); + msp_maps = kmalloc(fcnt * sizeof(struct mtd_info), GFP_KERNEL); memset(msp_maps, 0, fcnt * sizeof(struct mtd_info)); /* loop over the flash devices, initializing each */ @@ -95,8 +92,8 @@ int __init init_msp_flash(void) continue; } - msp_parts[i] = (struct mtd_partition *)kmalloc( - pcnt * sizeof(struct mtd_partition), GFP_KERNEL); + msp_parts[i] = kmalloc(pcnt * sizeof(struct mtd_partition), + GFP_KERNEL); memset(msp_parts[i], 0, pcnt * sizeof(struct mtd_partition)); /* now initialize the devices proper */ -- 1.5.2.2 - 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 10/30] irda: Do not do pointless kmalloc return value cast in KingSun driver
kmalloc() returns a void pointer, so there is no need to cast it in drivers/net/irda/kingsun-sir.c::kingsun_probe(). Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/net/irda/kingsun-sir.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/net/irda/kingsun-sir.c b/drivers/net/irda/kingsun-sir.c index bdd5c97..4e5101a 100644 --- a/drivers/net/irda/kingsun-sir.c +++ b/drivers/net/irda/kingsun-sir.c @@ -509,12 +509,12 @@ static int kingsun_probe(struct usb_interface *intf, spin_lock_init(>lock); /* Allocate input buffer */ - kingsun->in_buf = (__u8 *)kmalloc(kingsun->max_rx, GFP_KERNEL); + kingsun->in_buf = kmalloc(kingsun->max_rx, GFP_KERNEL); if (!kingsun->in_buf) goto free_mem; /* Allocate output buffer */ - kingsun->out_buf = (__u8 *)kmalloc(KINGSUN_FIFO_SIZE, GFP_KERNEL); + kingsun->out_buf = kmalloc(KINGSUN_FIFO_SIZE, GFP_KERNEL); if (!kingsun->out_buf) goto free_mem; -- 1.5.2.2 - 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 08/30] mtd: Avoid a pointless kmalloc() return value cast in TQM8xxL mapping handling code
In drivers/mtd/maps/tqm8xxl.c::init_tqm_mtd() it is pointless casting
the return value of kmalloc() since it returns void*.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/mtd/maps/tqm8xxl.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/maps/tqm8xxl.c b/drivers/mtd/maps/tqm8xxl.c
index 37e4ded..1d75ce4 100644
--- a/drivers/mtd/maps/tqm8xxl.c
+++ b/drivers/mtd/maps/tqm8xxl.c
@@ -141,8 +141,7 @@ int __init init_tqm_mtd(void)
goto error_mem;
}
- map_banks[idx]->name = (char *)kmalloc(16, GFP_KERNEL);
-
+ map_banks[idx]->name = kmalloc(16, GFP_KERNEL);
if (!map_banks[idx]->name) {
ret = -ENOMEM;
/* FIXME: What if some MTD devices were probed already?
*/
--
1.5.2.2
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.23-rc3-mm1 - memory layout change? - lost support for MAP_32BIT? - mono crashes
On Thu, 23 Aug 2007 11:28:25 +0200 (CEST) Jiri Kosina <[EMAIL PROTECTED]> wrote: > Handle MAP_32BIT flags properly in x86_64 flexmmap > > We need to handle MAP_32BIT flags of mmap() properly for 64bit > applications with filexible mmap layout. > > This patch introduces x86_64-specific version of > arch_get_unmapped_area_topdown() which differs from the generic one in > handling of the MAP_32BIT flag -- when this flag is passed to mmap(), we > stick back to the legacy layout for this particular mmap, which gives > proper 32bit range. > arch/x86_64/kernel/sys_x86_64.c | 98 include/asm-x86_64/pgtable.h|1 well that's another hunk of code for us to maintain and to slow all our computers down. It is quite unobvious to me that the whole pie-randomization thing is worth merging. Why shouldn't we just drop the lot? This patch is using mmap()'s randomization functionality in such a way that it maps the main executable of (specially compiled/linked -pie/-fpie) ET_DYN binaries onto a random address (in cases in which mmap() is allowed to perform a randomization). The code has been extraced from Ingo's exec-shield patch http://people.redhat.com/mingo/exec-shield/ that certainly doesn't tell anyone why we should merge this code into Linux. - 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 07/30] mtd: Get rid of pointless cast of kzalloc() return value in AT26xxx driver
kzalloc() returns a void pointer - no need to cast it in
drivers/mtd/devices/at91_dataflash26.c::add_dataflash()
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/mtd/devices/at91_dataflash26.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/devices/at91_dataflash26.c
b/drivers/mtd/devices/at91_dataflash26.c
index 64ce37f..9c4aac4 100644
--- a/drivers/mtd/devices/at91_dataflash26.c
+++ b/drivers/mtd/devices/at91_dataflash26.c
@@ -360,8 +360,7 @@ static int __init add_dataflash(int channel, char *name,
int nr_pages,
device->read = at91_dataflash26_read;
device->write = at91_dataflash26_write;
- priv = (struct dataflash_local *)kzalloc(sizeof(struct dataflash_local),
- GFP_KERNEL);
+ priv = kzalloc(sizeof(struct dataflash_local), GFP_KERNEL);
if (!priv) {
kfree(device);
return -ENOMEM;
--
1.5.2.2
-
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 06/30] i2o: No need to cast kmalloc() return value in cfg_open()
In drivers/message/i2o/i2o_config.c::cfg_open() there's a completely
pointless cast of kmalloc()'s return value. This patch removes it.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
drivers/message/i2o/i2o_config.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/message/i2o/i2o_config.c b/drivers/message/i2o/i2o_config.c
index 84e046e..fb8c668 100644
--- a/drivers/message/i2o/i2o_config.c
+++ b/drivers/message/i2o/i2o_config.c
@@ -1053,10 +1053,9 @@ static int i2o_cfg_ioctl(struct inode *inode, struct
file *fp, unsigned int cmd,
static int cfg_open(struct inode *inode, struct file *file)
{
- struct i2o_cfg_info *tmp =
- (struct i2o_cfg_info *)kmalloc(sizeof(struct i2o_cfg_info),
- GFP_KERNEL);
unsigned long flags;
+ struct i2o_cfg_info *tmp =
+ kmalloc(sizeof(struct i2o_cfg_info), GFP_KERNEL);
if (!tmp)
return -ENOMEM;
--
1.5.2.2
-
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 05/30] atm: No need to cast vmalloc() return value
vmalloc() returns void*, no need to cast it in drivers/atm/lanai.c Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> --- drivers/atm/lanai.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/atm/lanai.c b/drivers/atm/lanai.c index 144a49f..59e7dde 100644 --- a/drivers/atm/lanai.c +++ b/drivers/atm/lanai.c @@ -1459,7 +1459,7 @@ static int __devinit vcc_table_allocate(struct lanai_dev *lanai) return (lanai->vccs == NULL) ? -ENOMEM : 0; #else int bytes = (lanai->num_vci) * sizeof(struct lanai_vcc *); - lanai->vccs = (struct lanai_vcc **) vmalloc(bytes); + lanai->vccs = vmalloc(bytes); if (unlikely(lanai->vccs == NULL)) return -ENOMEM; memset(lanai->vccs, 0, bytes); -- 1.5.2.2 - 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 04/30] powerpc: Don't cast kmalloc return value in ibmebus.c
kmalloc() returns a void pointer so there is absolutely no need to
cast it in ibmebus_chomp().
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ibmebus.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
index 9a8c9af..9514e66 100644
--- a/arch/powerpc/kernel/ibmebus.c
+++ b/arch/powerpc/kernel/ibmebus.c
@@ -383,7 +383,8 @@ static int ibmebus_match_path(struct device *dev, void
*data)
static char *ibmebus_chomp(const char *in, size_t count)
{
- char *out = (char*)kmalloc(count + 1, GFP_KERNEL);
+ char *out = kmalloc(count + 1, GFP_KERNEL);
+
if (!out)
return NULL;
--
1.5.2.2
-
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 03/30] um: Don't unnecessarily cast allocation return value in ubd_kern.c
vmalloc() returns a void pointer, so casting to (void *) is pretty pointless.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
arch/um/drivers/ubd_kern.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
index 0eabe73..25b248a 100644
--- a/arch/um/drivers/ubd_kern.c
+++ b/arch/um/drivers/ubd_kern.c
@@ -615,7 +615,7 @@ static int ubd_open_dev(struct ubd *ubd_dev)
blk_queue_max_sectors(ubd_dev->queue, 8 * sizeof(long));
err = -ENOMEM;
- ubd_dev->cow.bitmap = (void *) vmalloc(ubd_dev->cow.bitmap_len);
+ ubd_dev->cow.bitmap = vmalloc(ubd_dev->cow.bitmap_len);
if(ubd_dev->cow.bitmap == NULL){
printk(KERN_ERR "Failed to vmalloc COW bitmap\n");
goto error;
--
1.5.2.2
-
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 02/30] cris: Remove unnecessary cast of allocation return value in intmem.c
kmalloc() returns a void pointer so there's no need to cast the
return value.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
arch/cris/arch-v32/mm/intmem.c | 10 --
1 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/arch/cris/arch-v32/mm/intmem.c b/arch/cris/arch-v32/mm/intmem.c
index 41ee7f7..691cf3b 100644
--- a/arch/cris/arch-v32/mm/intmem.c
+++ b/arch/cris/arch-v32/mm/intmem.c
@@ -27,8 +27,8 @@ static void crisv32_intmem_init(void)
{
static int initiated = 0;
if (!initiated) {
- struct intmem_allocation* alloc =
- (struct intmem_allocation*)kmalloc(sizeof *alloc, GFP_KERNEL);
+ struct intmem_allocation *alloc =
+ kmalloc(sizeof *alloc, GFP_KERNEL);
INIT_LIST_HEAD(_allocations);
intmem_virtual = ioremap(MEM_INTMEM_START, MEM_INTMEM_SIZE);
initiated = 1;
@@ -55,8 +55,7 @@ void* crisv32_intmem_alloc(unsigned size, unsigned align)
if (allocation->status == STATUS_FREE &&
allocation->size >= size + alignment) {
if (allocation->size > size + alignment) {
- struct intmem_allocation* alloc =
- (struct intmem_allocation*)
+ struct intmem_allocation *alloc =
kmalloc(sizeof *alloc, GFP_ATOMIC);
alloc->status = STATUS_FREE;
alloc->size = allocation->size - size -
alignment;
@@ -64,8 +63,7 @@ void* crisv32_intmem_alloc(unsigned size, unsigned align)
list_add(>entry, >entry);
if (alignment) {
- struct intmem_allocation* tmp;
- tmp = (struct intmem_allocation*)
+ struct intmem_allocation *tmp =
kmalloc(sizeof *tmp,
GFP_ATOMIC);
tmp->offset = allocation->offset;
tmp->size = alignment;
--
1.5.2.2
-
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 01/30] ia64: Remove unnecessary cast of allocation return value in sn_hwperf_enum_objects()
vmalloc() returns a void pointer - no need to cast it.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
arch/ia64/sn/kernel/sn2/sn_hwperf.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/ia64/sn/kernel/sn2/sn_hwperf.c
b/arch/ia64/sn/kernel/sn2/sn_hwperf.c
index df8d5be..1a8e496 100644
--- a/arch/ia64/sn/kernel/sn2/sn_hwperf.c
+++ b/arch/ia64/sn/kernel/sn2/sn_hwperf.c
@@ -66,7 +66,8 @@ static int sn_hwperf_enum_objects(int *nobj, struct
sn_hwperf_object_info **ret)
}
sz = sn_hwperf_obj_cnt * sizeof(struct sn_hwperf_object_info);
- if ((objbuf = (struct sn_hwperf_object_info *) vmalloc(sz)) == NULL) {
+ objbuf = vmalloc(sz);
+ if (objbuf == NULL) {
printk("sn_hwperf_enum_objects: vmalloc(%d) failed\n", (int)sz);
e = -ENOMEM;
goto out;
--
1.5.2.2
-
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/
division and cpu usage
Hello. I'm new to kernel development and have some questions. 1. Why can't I divide with regular casting to double ((double)a / (double)b)? It gives me strange errors when compiling: WARNING: "__divdf3" [/root] undefined! WARNING: "__addf3" [/root/...] undefined! WARNING: "__floatsidf" [/root/...] undefined! And if I compile with normal integers, I get zero as the result. 2. I'm trying to get the percentage of CPU used for a certain task_struct and figured the following formula: (task->utime + task->stime) / jiffies Before calculating I convert all the variables to jiffies. Is this correct? Please help. Greets, Lukla - 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: unable to handle kernel NULL pointer dereference - linux-2.6.22
[Adding netdev to CC]
On 21/08/07, poison <[EMAIL PROTECTED]> wrote:
> Hello,
> after running a few instances of bittorent-curses on 2.6.22 - 2.6.22.3 it
> takes about 15min to 2hrs for my System to hang. 2.6.21.7 is definately fine,
> 2.6.21 probably (ran for 4hrs without hanging).
> If I'm lucky the Oops below makes it to my syslog (unfortunately SysRq-{p,s,i}
> doesn't work when it hangs, neither can I ssh into it):
>
> Aug 18 19:47:41 draco kernel: BUG: unable to handle kernel NULL pointer
> dereference at virtual address
> Aug 18 19:47:41 draco kernel: printing eip:
> Aug 18 19:47:41 draco kernel: c038fcba
> Aug 18 19:47:41 draco kernel: *pdpt = 33830001
> Aug 18 19:47:41 draco kernel: *pde =
> Aug 18 19:47:41 draco kernel: Oops: 0002 [#1]
> Aug 18 19:47:41 draco kernel: SMP
> Aug 18 19:47:41 draco kernel: Modules linked in: snd_hda_intel snd_emu10k1
> cls_u32 sch_sfq sch_htb snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq
> snd_pcm_oss snd_mixer_oss rfcomm hidp l2cap nfsd exportfs lockd sunrpc
> coretemp hwmon eeprom snd_rawmidi snd_ac97_codec hci_usb ac97_bus
> snd_seq_device snd_util_mem snd_pcm bluetooth snd_hwdep snd_timer snd
> snd_page_alloc i2c_i801 emu10k1_gp gameport i2c_core sg
> Aug 18 19:47:41 draco kernel: CPU:0
> Aug 18 19:47:41 draco kernel: EIP:0060:[]Not tainted VLI
> Aug 18 19:47:41 draco kernel: EFLAGS: 00210202 (2.6.22.2poison #14)
> Aug 18 19:47:41 draco kernel: EIP is at tcp_sendmsg+0x40a/0xb70
> Aug 18 19:47:41 draco kernel: eax: ebx: ec5b807c ecx: c04b43a0
> edx: ec5b807c
> Aug 18 19:47:41 draco kernel: esi: ec5b8000 edi: 0100 ebp: ec524180
> esp: f3a11d30
> Aug 18 19:47:41 draco kernel: ds: 007b es: 007b fs: 00d8 gs: 0033 ss:
> 0068
> Aug 18 19:47:41 draco kernel: Process bittorrent-curs (pid: 3974, ti=f3a1
> task=f3a0e000 task.ti=f3a1)
> Aug 18 19:47:41 draco kernel: Stack: ebe562f5 000b
> f3a11d94 ec5b807c
> Aug 18 19:47:41 draco kernel:0001 00100100 f3a11f40
> 0040 0200 0200 04b6
> Aug 18 19:47:41 draco kernel:08604707 00200200 f3e5c798 eeaa4b40
> f3a0e000 01f5 00100100
> Aug 18 19:47:41 draco kernel: Call Trace:
> Aug 18 19:47:41 draco kernel: [] inet_sendmsg+0x37/0x70
> Aug 18 19:47:41 draco kernel: [] sock_sendmsg+0xbf/0xf0
> Aug 18 19:47:41 draco kernel: [] autoremove_wake_function+0x0/0x50
> Aug 18 19:47:41 draco kernel: [] default_wake_function+0x0/0x10
> Aug 18 19:47:41 draco last message repeated 3 times
> Aug 18 19:47:41 draco kernel: [] find_extend_vma+0x1d/0x70
> Aug 18 19:47:41 draco kernel: [] sys_sendto+0x12f/0x180
> Aug 18 19:47:41 draco kernel: [] futex_wake+0xac/0xd0
> Aug 18 19:47:41 draco kernel: [] do_futex+0x6bd/0xbd0
> Aug 18 19:47:41 draco kernel: [] sys_send+0x33/0x40
> Aug 18 19:47:41 draco kernel: [] sys_socketcall+0x142/0x280
> Aug 18 19:47:41 draco kernel: [] copy_to_user+0x30/0x60
> Aug 18 19:47:41 draco kernel: [] syscall_call+0x7/0xb
> Aug 18 19:47:41 draco kernel: ===
> Aug 18 19:47:41 draco kernel: Code: 85 fb 06 00 00 80 ca 10 8b 83 94 00 00 00
> 88 53 68 f0 81 00 00 00 01 00 8b 44 24 18 ff 40 08 8b 54 24 18 8b 42 04 89 13
> 89 43 04 <89> 18 89 5a 04 8b 8e 2c 01 00 00 85 c9 0f 84 19 06 00 00 8b 83
> Aug 18 19:47:41 draco kernel: EIP: [] tcp_sendmsg+0x40a/0xb70 SS:ESP
> 0068:f3a11d30
> Aug 18 19:47:51 draco kernel:
> Aug 18 19:47:51 draco kernel: Pid: 3812, comm:X
> Aug 18 19:47:51 draco kernel: EIP: 0060:[] CPU: 0
> Aug 18 19:47:51 draco kernel: EIP is at __get_free_pages+0x22/0x40
> Aug 18 19:47:51 draco kernel: EFLAGS: 3246Not tainted
> (2.6.22.2poison #14)
> Aug 18 19:47:51 draco kernel: EAX: 00d0 EBX: 00d0 ECX: c0496b40 EDX:
>
> Aug 18 19:47:51 draco kernel: ESI: EDI: f5ba1be4 EBP: f49a4d80 DS:
> 007b ES: 007b FS: 00d8
> Aug 18 19:47:51 draco kernel: CR0: 8005003b CR2: b7384000 CR3: 37165000 CR4:
> 06f0
> Aug 18 19:47:51 draco kernel: [] __pollwait+0xa6/0x100
> Aug 18 19:47:51 draco kernel: [] unix_poll+0x17/0xa0
> Aug 18 19:47:51 draco kernel: [] sock_poll+0xc/0x10
> Aug 18 19:47:51 draco kernel: [] do_select+0x25c/0x490
> Aug 18 19:47:51 draco kernel: [] __pollwait+0x0/0x100
> Aug 18 19:47:51 draco kernel: [] default_wake_function+0x0/0x10
> Aug 18 19:47:51 draco last message repeated 19 times
> Aug 18 19:47:51 draco kernel: [] core_sys_select+0x1c8/0x2f0
> Aug 18 19:47:51 draco kernel: [] do_readv_writev+0x120/0x190
> Aug 18 19:47:51 draco kernel: [] sock_aio_write+0x0/0x110
> Aug 18 19:47:51 draco kernel: [] sys_select+0x4d/0x1b0
> Aug 18 19:47:51 draco kernel: [] vfs_writev+0x3c/0x50
> Aug 18 19:47:51 draco kernel: [] sys_writev+0x47/0x80
> Aug 18 19:47:51 draco kernel: [] syscall_call+0x7/0xb
> Aug 18 19:47:51 draco kernel: ===
> ---
>
> It's also attached together with one from a tainted 2.6.22.3
>
> The error is
Re: [BUG] 2.6.23-rc3-mm1 Oops: Machine check, sig: 7 [#1]
Andrew Morton writes: > Dunno, it beats me. powerpc booted OK for me. Ben, have you been playing > around in powerpc mmap code? How come the oops claims it died at > kernel_execve+0x8/0x14 but the call trace points up into the vma management > code? The exception c01 in kernel_execve is just the system call entry. The real problem is the machine check that happened in rb_insert_color, called from __vma_link_rb. However, a machine check is an imprecise exception, so whatever caused the problem may have happened a little earlier than that. Most likely it is due to an attempt to access a physical address where nothing exists. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/30] Remove unneeded casts of [kv][mzc]alloc() return values
Hi, The [kv][mzc]alloc() functions return a void pointer, so when assigning to a pointer type variable there is no need to cast the return value. This is something that is already commonly being cleaned up when people change nearby code and it's also something people are usually asked not to do when submitting new code. I took a look at how many such casts are currently left and didn't find that many, so I cleaned them up. I've probably missed some, but this patch series should clean up the majority of the remaining ones at least. The patches in this series are [PATCH 1/30] ia64: Remove unnecessary cast of allocation return value in sn_hwperf_enum_objects() [PATCH 1/30] cris: Remove unnecessary cast of allocation return value in intmem.c [PATCH 1/30] um: Don't unnecessarily cast allocation return value in ubd_kern.c [PATCH 1/30] powerpc: Don't cast kmalloc return value in ibmebus.c [PATCH 1/30] atm: No need to cast vmalloc() return value [PATCH 1/30] i2o: No need to cast kmalloc() return value in cfg_open() [PATCH 1/30] mtd: Get rid of pointless cast of kzalloc() return value in AT26xxx driver [PATCH 1/30] mtd: Avoid a pointless kmalloc() return value cast in TQM8xxL mapping handling code [PATCH 1/30] mtd: Don't cast kmalloc() return value in drivers/mtd/maps/pmcmsp-flash.c [PATCH 1/30] irda: Do not do pointless kmalloc return value cast in KingSun driver [PATCH 1/30] net: No need to cast vmalloc() return values in NetXen NIC driver [PATCH 1/30] net: No point in casting kmalloc return values in Gianfar Ethernet Driver [PATCH 1/30] net: Don't do pointless kmalloc return value casts in zd1211 driver [PATCH 1/30] net: Kill some unneeded allocation return value casts in libertas [PATCH 1/30] net: No need to cast kmalloc() return value in ipw2100 driver [PATCH 1/30] net: Avoid pointless allocation casts in BSD compression module [PATCH 1/30] isdn: Get rid of some pointless allocation casts in common and bsd comp. [PATCH 1/30] isdn: eicon - get rid of a pointless vmalloc() return value cast [PATCH 1/30] scsi: Remove explicit casts of [kv]alloc return values in osst driver [PATCH 1/30] scsi: In the Advansys driver, do not cast allocation function return values [PATCH 1/30] oss: Remove unneeded vmalloc() return value casts in OSS [PATCH 1/30] ivtv: kzalloc() returns void pointer, no need to cast [PATCH 1/30] video: Remove pointless kmalloc() return value cast in Zoran PCI controller driver [PATCH 1/30] dvb: remove some unneeded vmalloc() return value casts from av7110 [PATCH 1/30] tty: dont needlessly cast kmalloc() return value [PATCH 1/30] md: vmalloc() returns void pointer so we don't need to cast it in dm-ioctl [PATCH 1/30] usb: avoid redundant cast of kmalloc() return value in OTi-6858 driver [PATCH 1/30] jfs: avoid pointless casts of kmalloc() return val [PATCH 1/30] mm: No need to cast vmalloc() return value in zone_wait_table_init() [PATCH 1/30] emu10k1: There's no need to cast vmalloc() return value in snd_emu10k1_create() I'll send them all as replies to this email, to LKML and maintainers. Kind regards, Jesper - 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-usb-devel] [GIT PATCH] USB fixes for 2.6.23-rc3
On Thu, Aug 23, 2007 at 04:28:31PM -0700, Greg KH wrote: > On Thu, Aug 23, 2007 at 04:18:15PM -0700, Randy Dunlap wrote: > > On Thu, 23 Aug 2007 15:49:56 -0700 Greg KH wrote: > > > > > On Fri, Aug 24, 2007 at 12:43:47AM +0200, Guennadi Liakhovetski wrote: > > > > Hi Greg, > > > > > > > > sorry, this is a private egoistic request, so I took the liberty and > > > > removed Linus and Andrew from CC: If this wouldn't make things more > > > > difficult / worse for you and anyone else, could you perhaps post such > > > > patch chains as a reply to the first message (patch 0/x) and not each > > > > subsequent patch as a reply to the previous one? It would make it > > > > easier > > > > to view for _me_ (remember egoistic?) because my mail agent (pine) > > > > presents mail threads where every reply level produces a small right > > > > offset in the subject line, so, starting from about reply number 20 the > > > > subject is completely off-screen. > > > > > > > > Again, this is a minor trouble, and, perhaps, I am the only one > > > > suffering > > > > from it, but if it doesn't matter either way for everyone else, I would > > > > really appreciate it that way. > > > > > > Heh, people ask me about this every few months or so, so you are not > > > alone. > > > > I'd prefer that change also. In fact I just modified (trivial) > > send_lots_of_email.pl (gregkh_patchbomb mailer) to do this, > > except that I just have it create an mbox that I email via > > msmtp. (and it reads a 'sendpatchset' control file for input > > instead of needing to modify the script source file itself) > > I use git-send-email these days, and it already supports this with the > --no-chain-reply-to option. I'll consider using it next time, if at > least one more person complains about this :) >... *complain* :) > thanks, > > greg k-h cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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 i386] fix leak of ../kernel from top level directory in Makefile
This patch fixes a compile time error that results in the kernel being unable to compile due to a reference to ../kernel from the top level directory of the kernel source if a file ../kernel exists outside of the kernel tree. -ben Signed-off-by: Benjamin LaHaise <[EMAIL PROTECTED]> diff --git a/arch/i386/mach-generic/Makefile b/arch/i386/mach-generic/Makefile index 77fbc9f..bd23339 100644 --- a/arch/i386/mach-generic/Makefile +++ b/arch/i386/mach-generic/Makefile @@ -2,6 +2,6 @@ # Makefile for the generic architecture # -EXTRA_CFLAGS += -I../kernel +EXTRA_CFLAGS += -I$(TOPDIR)/arch/i386/kernel obj-y := probe.o summit.o bigsmp.o es7000.o default.o ../mach-es7000/ diff --git a/arch/i386/mach-voyager/Makefile b/arch/i386/mach-voyager/Makefile index f24d296..78898b7 100644 --- a/arch/i386/mach-voyager/Makefile +++ b/arch/i386/mach-voyager/Makefile @@ -2,7 +2,7 @@ # Makefile for the linux kernel. # -EXTRA_CFLAGS += -I../kernel +EXTRA_CFLAGS += -I$(TOPDIR)/arch/i386/kernel obj-y := setup.o voyager_basic.o voyager_thread.o obj-$(CONFIG_SMP) += voyager_smp.o voyager_cat.o - 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-usb-devel] [GIT PATCH] USB fixes for 2.6.23-rc3
On Thu, Aug 23, 2007 at 04:18:15PM -0700, Randy Dunlap wrote: > On Thu, 23 Aug 2007 15:49:56 -0700 Greg KH wrote: > > > On Fri, Aug 24, 2007 at 12:43:47AM +0200, Guennadi Liakhovetski wrote: > > > Hi Greg, > > > > > > sorry, this is a private egoistic request, so I took the liberty and > > > removed Linus and Andrew from CC: If this wouldn't make things more > > > difficult / worse for you and anyone else, could you perhaps post such > > > patch chains as a reply to the first message (patch 0/x) and not each > > > subsequent patch as a reply to the previous one? It would make it easier > > > to view for _me_ (remember egoistic?) because my mail agent (pine) > > > presents mail threads where every reply level produces a small right > > > offset in the subject line, so, starting from about reply number 20 the > > > subject is completely off-screen. > > > > > > Again, this is a minor trouble, and, perhaps, I am the only one suffering > > > from it, but if it doesn't matter either way for everyone else, I would > > > really appreciate it that way. > > > > Heh, people ask me about this every few months or so, so you are not > > alone. > > I'd prefer that change also. In fact I just modified (trivial) > send_lots_of_email.pl (gregkh_patchbomb mailer) to do this, > except that I just have it create an mbox that I email via > msmtp. (and it reads a 'sendpatchset' control file for input > instead of needing to modify the script source file itself) I use git-send-email these days, and it already supports this with the --no-chain-reply-to option. I'll consider using it next time, if at least one more person complains about this :) > PATCH 0/n: intro/summary > |_ PATCH 1/n: desc1 > |_ PATCH 2/n: desc2 > |_ PATCH 3/n: desc3 > > should imply a patch order also, shouldn't it? At least it does > to me and to users of Paul Jackson's 'sendpatchset' script, > which acts in this way. Yeah, you are right that things are now numbered, so it might be better (my old send_lots_of_email.pl script didn't number things very well, if at all from what I remember). But odds are, I'll still get complaints. But hey, it looks like people will complain either way :) thanks, greg k-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: intel_rng: FWH not detected (and no entropy)
Pierre Chifflier wrote: On Thu, Aug 23, 2007 at 09:53:04AM -0300, Henrique de Moraes Holschuh wrote: On Thu, 23 Aug 2007, Pierre Chifflier wrote: I'm not sure the mhat a hardware RNG is present, so I want to check. Open the mobo, and locate all FLASH chips. If one of them is a 82802AB or 82802AC, then you *MIGHT* have an Intel FWH with a HRNG (some of the FWHs have their RNGs disabled, and since Intel stopped guaranteeing the RNG is there, they would install one such FWH in their boards just the same). If none are a 82802AB or 82802AC, you don't have an Intel FWH with a HRNG. Even if you had an Intel board that is known to sometimes have an Intel FWH with an RNG, like the D875PBZ, that wouldn't mean much. They could have used an non-Intel equivalent part for that production run, for unknown reasons. You really have to check. Well, I've seen nothing more than the 82801DB (which was listed in lspci). So maybe there is no HRNG :( This leaves the main problem, which is the lack of entropy. Does anyone have an idea on how to solve this problem ? It appeared with recent kernels. For ex, 2.6.8 had an entropy pool always > 3000, while 2.6.18 and other recent kernels show ~ 150. # sysctl kernel.random.poolsize kernel.random.poolsize = 4096 # sysctl kernel.random.entropy_avail kernel.random.entropy_avail = 196 This is really annoying, since the box should also use SSL/TLS operations, and it will be real slow .. I believe that the timing of network interrupts used to be used to provide entropy, however in later kernels this was taken out as it was thought unsafe, since an attacker could detect or control the timing of these packets and thus determine the contents of the entropy pool. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - 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/
[M68KNOMMU]: include linux/fs.h for do_pip()
Include linux/fs.h to get the prototype for do_pipe(). Build fix. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naur ORG.linux-2.6.23-rc3/arch/m68knommu/kernel/sys_m68k.c linux-2.6.23-rc3/arch/m68knommu/kernel/sys_m68k.c --- ORG.linux-2.6.23-rc3/arch/m68knommu/kernel/sys_m68k.c 2007-07-09 09:32:17.0 +1000 +++ linux-2.6.23-rc3/arch/m68knommu/kernel/sys_m68k.c 2007-08-14 16:17:27.0 +1000 @@ -18,6 +18,7 @@ #include #include #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/
[M68KNOMMU]: include linux/fs.h for getname()
Include linux/fs.h to get the prototype for getname(). Build fix. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naur ORG.linux-2.6.23-rc3/arch/m68knommu/kernel/process.c linux-2.6.23-rc3/arch/m68knommu/kernel/process.c --- ORG.linux-2.6.23-rc3/arch/m68knommu/kernel/process.c2007-08-14 15:30:46.0 +1000 +++ linux-2.6.23-rc3/arch/m68knommu/kernel/process.c2007-08-14 16:17:36.0 +1000 @@ -28,6 +28,7 @@ #include #include #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/
[M68KNOMMU]: include asm-generic/pgtable.h
Include asm-generic/pgtable.h to pick up the lazy_mmu_mode and lazy_cpu_mode macros. Won't build without them. Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]> --- diff -Naur ORG.linux-2.6.23-rc3/include/asm-m68knommu/pgtable.h linux-2.6.23-rc3/include/asm-m68knommu/pgtable.h --- ORG.linux-2.6.23-rc3/include/asm-m68knommu/pgtable.h2007-08-14 15:31:17.0 +1000 +++ linux-2.6.23-rc3/include/asm-m68knommu/pgtable.h2007-08-14 16:17:10.0 +1000 @@ -65,4 +65,6 @@ #defineVMALLOC_START 0 #defineVMALLOC_END 0x +#include + #endif /* _M68KNOMMU_PGTABLE_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: [linux-usb-devel] [GIT PATCH] USB fixes for 2.6.23-rc3
On Thu, 23 Aug 2007 15:49:56 -0700 Greg KH wrote: > On Fri, Aug 24, 2007 at 12:43:47AM +0200, Guennadi Liakhovetski wrote: > > Hi Greg, > > > > sorry, this is a private egoistic request, so I took the liberty and > > removed Linus and Andrew from CC: If this wouldn't make things more > > difficult / worse for you and anyone else, could you perhaps post such > > patch chains as a reply to the first message (patch 0/x) and not each > > subsequent patch as a reply to the previous one? It would make it easier > > to view for _me_ (remember egoistic?) because my mail agent (pine) > > presents mail threads where every reply level produces a small right > > offset in the subject line, so, starting from about reply number 20 the > > subject is completely off-screen. > > > > Again, this is a minor trouble, and, perhaps, I am the only one suffering > > from it, but if it doesn't matter either way for everyone else, I would > > really appreciate it that way. > > Heh, people ask me about this every few months or so, so you are not > alone. I'd prefer that change also. In fact I just modified (trivial) send_lots_of_email.pl (gregkh_patchbomb mailer) to do this, except that I just have it create an mbox that I email via msmtp. (and it reads a 'sendpatchset' control file for input instead of needing to modify the script source file itself) > Unfortunately, I really like the cascade affect, it shows that the > patches do have to be applied in consecutive order for them to work > properly (which some people seem to forget and then get mad at me when > they try to cherry-pick intermediate patches and apply them to older > kernels for odd reasons...) A patch series such as: PATCH 0/n: intro/summary |_ PATCH 1/n: desc1 |_ PATCH 2/n: desc2 |_ PATCH 3/n: desc3 should imply a patch order also, shouldn't it? At least it does to me and to users of Paul Jackson's 'sendpatchset' script, which acts in this way. > If I wanted to respond in an egotistical way, I could just tell you to > use an email client that can handle the cascade affect properly, like > mine does :) --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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] enforce noreplace-smp in alternative_instructions()
Frederik Deweerdt wrote: > On Wed, Aug 22, 2007 at 02:06:48AM -0700, Andrew Morton wrote: > >> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc3/2.6.23-rc3-mm1/ >> >> > Hi Jeremy, > > arch/i386/kernel/alternative.c:alternative_instructions() doesn't > check for noreplace-smp before setting capability bits and freeing the > __smp_locks section. > > Every call to alternatives_smp_unlock() checks for noreplace-smp > beforehand, so remove the check from there. > > Boot tested on i386 with UP+noreplace-smp (lguest) and SMP (real hardware) > Does this fix a real problem? Or is there just some redundancy? Wouldn't it be better to put the noreplace_smp test in one place? J - 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/
