Re: [PATCH] fix cpufreq_stats attrs removal

[Alexey Dobriyan]

On Thu, Mar 22, 2007 at 06:02:01PM +0100, Mattia Dongili wrote:
> On Wed, Mar 21, 2007 at 08:10:42PM -0800, Andrew Morton wrote:
> > I ain't picky, but as a short-term thing it'd be kinda nice if it didn't
> > oops the kernel.
> 
> There are other symptoms to this same bug:
> 
> 1. unload p4-clockmod: /sys/.../cpu0/cpufreq is removed all together
> 2. load p4-clockmod: /sys/.../cpu0/cpufreq appears but no 'stats' subdir
>(yes, cpufreq_stats is loaded)
> 3. rmmod cpufreq_stats: Ooops!
> 
> Call Trace:
>  [] remove_dir+0x33/0xc4
>  [] remove_files+0x1a/0x28
>  [] sysfs_remove_group+0x63/0x71
>  [] cpufreq_stat_cpu_callback+0x51/0x8a [cpufreq_stats]
>  [] cpufreq_stats_exit+0x47/0x4b [cpufreq_stats]
>  [] sys_delete_module+0x190/0x1b7
>  [] do_wp_page+0x231/0x3e7
>  [] syscall_call+0x7/0xb
> 
> The problem is cpufreq_stats doesn't know when a cpufreq driver is
> removed and doesn't cleanup. I guess this affects any setup with
> cpufreq_stats.
> The attached patch seems to solve both symptoms and yes... it's quite
> invasive as it introduce one more cpufreq policy notification (REMOVED).
> 
> BTW: the patch is against .21-rc4-mm1 but applies with some fuzz to
> 2.6.20 too

Also, it doesn't work.

/sys/*/cpufreq/stats dir stays if you cd into it _before_ rmmod.

# modprobe p4-clockmod
$ /sys/devices/system/cpu/cpu0/cpufreq/stats
# rmmod p4-clockmod
$ cat time_in_state

p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
BUG: unable to handle kernel paging request at virtual address 6b6b6b6f
 printing eip:
c01955e1
*pde = 
Oops:  [#1]
last sysfs file: devices/system/cpu/cpu0/cpufreq/stats/time_in_state
Modules linked in: speedstep_lib ohci_hcd af_packet e1000 ehci_hcd uhci_hcd 
usbcore
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202   (2.6.21-rc5-mm1 #2)
EIP is at sysfs_open_file+0xb6/0x26f
eax: 6b6b6b6b   ebx: c03b3cb0   ecx:    edx: f732772c
esi:    edi: c0681400   ebp: f36fad10   esp: f3595ee0
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process cat (pid: 7545, ti=f3594000 task=f3773510 task.ti=f3594000)
Stack: 1000 f376f26c f732772c f376f26c f36fad10 f376f26c f3595f38 c019552b 
   c015ced8 c18d3190 f3746a18 f36fad10 8000 f3595f38 ff9c c015d052 
   f36fad10   c015d094  f3595f38 f3746a18 c18d3190 
Call Trace:
 [] sysfs_open_file+0x0/0x26f
 [] __dentry_open+0xa4/0x191
 [] nameidata_to_filp+0x31/0x3a
 [] do_filp_open+0x39/0x40
 [] get_unused_fd+0xa1/0xb2
 [] _spin_unlock+0x14/0x1c
 [] get_unused_fd+0xa1/0xb2
 [] do_sys_open+0x3a/0x6d
 [] sys_open+0x1c/0x20
 [] sysenter_past_esp+0x5f/0x99
 ===
INFO: lockdep is turned off.
Code: 0f 85 24 01 00 00 8b 43 04 85 c0 74 0f 83 38 02 0f 84 c4 01 00 00 ff 80 
80 01 00 00 8b 54 24 08 8b 42 28 85 c0 0f 84 62 01 00 00 <8b> 40 04 85 c0 0f 84 
57 01 00 00 8b 40 04 89 44 24 0c 8b 74 24 
EIP: [] sysfs_open_file+0xb6/0x26f SS:ESP 0068:f3595ee0
Slab corruption: start=f73276e0, len=256
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](load_elf_binary+0xa79/0x1a19)
060: 6b 6b 6b 6b 6c 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Prev obj: start=f73275d4, len=256
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](load_elf_binary+0x1764/0x1a19)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
Next obj: start=f73277ec, len=256
Redzone: 0x5a2cf071/0x5a2cf071.
Last user: [](load_elf_binary+0x1764/0x1a19)
000: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b
010: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b

> --- linux-2.6.20/drivers/cpufreq/cpufreq.c2007-03-22 17:00:38.0 
> +0100
> +++ linux-2.6.20.dirty/drivers/cpufreq/cpufreq.c  2007-03-22 
> 16:51:09.0 +0100
> @@ -989,6 +989,10 @@ static int __cpufreq_remove_dev (struct 
>  
>   unlock_policy_rwsem_write(cpu);
>  
> + /* notify of policy cancellation */
> + blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> + CPUFREQ_REMOVE, data);
> +
>   kobject_unregister(&data->kobj);
>  
>   kobject_put(&data->kobj);
> diff -rup linux-2.6.20/drivers/cpufreq/cpufreq_stats.c 
> linux-2.6.20.dirty/drivers/cpufreq/cpufreq_stats.c
> --- linux-2.6.20/drivers/cpufreq/cpufreq_stats.c  2007-03-22 
> 17:00:38.0 +0100
> +++ linux-2.6.20.dirty/drivers/cpufreq/cpufreq_stats.c2007-03-22 
> 17:06:24.0 +0100
> @@ -257,18 +257,23 @@ static int
>  cpufreq_stat_notifier_policy (struct notifier_block *nb, unsigned long val,
>   void *data)
>  {
> - int ret;
> + int ret = 0;
>   struct cpufreq_policy *policy = data;
>   struct cpufreq_frequency_table *table;
>   unsigned int cpu = policy->cpu;
> - if (val != CPUFREQ_NOTIFY)
> - return 0;
> - table = cpufreq_frequency_get_table(cpu);
> - if (!table)
> - return 0;
> - if ((ret = cpufreq_stats_create_table(policy, table)))
> - return ret;
>

2.6.21-rc5-mm3

[Andrew Morton]

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/

- git-cryptodev has things in it again

- Re-added git-e1000: a large amount of e1000 driver work

- git-net has a huge amount of material in it, but I dropped it because it
  went oops.

- git-block is back, minus the problematic unplugging rework.

- Lots of x86 updates.

- lguest is being redone and has been dropped

- The IDE development tree has been restored



Boilerplate:

- See the `hot-fixes' directory for any important updates to this patchset.

- To fetch an -mm tree using git, use (for example)

  git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git 
tag v2.6.16-rc2-mm1
  git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1

- -mm kernel commit activity can be reviewed by subscribing to the
  mm-commits mailing list.

echo "subscribe mm-commits" | mail [EMAIL PROTECTED]

- If you hit a bug in -mm and it is not obvious which patch caused it, it is
  most valuable if you can perform a bisection search to identify which patch
  introduced the bug.  Instructions for this process are at

http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt

  But beware that this process takes some time (around ten rebuilds and
  reboots), so consider reporting the bug first and if we cannot immediately
  identify the faulty patch, then perform the bisection search.

- When reporting bugs, please try to Cc: the relevant maintainer and mailing
  list on any email.

- When reporting bugs in this kernel via email, please also rewrite the
  email Subject: in some manner to reflect the nature of the bug.  Some
  developers filter by Subject: when looking for messages to read.

- Occasional snapshots of the -mm lineup are uploaded to
  ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on
  the mm-commits list.




Changes since 2.6.21-rc5-mm2:


 origin.patch
 git-acpi.patch
 git-alsa.patch
 git-agpgart.patch
 git-arm-master.patch
 git-arm.patch
 git-avr32.patch
 git-cpufreq.patch
 git-powerpc.patch
 git-drm.patch
 git-dvb.patch
 git-gfs2-nmw.patch
 git-hid.patch
 git-ia64.patch
 git-ieee1394.patch
 git-infiniband.patch
 git-kbuild.patch
 git-kvm.patch
 git-leds.patch
 git-libata-all.patch
 git-md-accel.patch
 git-mips.patch
 git-mmc.patch
 git-mtd.patch
 git-ubi.patch
 git-netdev-all.patch
 git-e1000.patch
 git-ioat.patch
 git-ocfs2.patch
 git-parisc.patch
 git-r8169.patch
 git-selinux.patch
 git-pciseg.patch
 git-s390.patch
 git-scsi-misc.patch
 git-block.patch
 git-unionfs.patch
 git-watchdog.patch
 git-wireless.patch
 git-ipwireless_cs.patch
 git-cryptodev.patch
 git-gccbug.patch

 git trees

-knfsd-allow-nfsd-readdir-to-return-64bit-cookies.patch
-knfsd-nfsd4-fix-inheritance-flags-on-v4-ace-derived-from-posix-default-ace.patch
-knfsd-nfsd4-demote-clientid-in-use-printk-to-a-dprintk.patch
-knfsd-nfsd4-remove-superfluous-cancel_delayed_work-call.patch
-md-allow-raid4-arrays-to-be-reshaped.patch
-md-clear-the-congested_fn-when-stopping-a-raid5.patch
-md-convert-compile-time-warnings-into-runtime-warnings.patch
-generic_serial-fix-decoding-of-baud-rate.patch
-correct-slow-acpi_pm-rating.patch
-isdn-fix-bchannel_bh-call-from-isar_bh.patch
-uml-fix-epoll.patch
-tty-minor-merge-correction.patch
-utsns-fix-config_uts_ns-behavior.patch
-drivers-spi-fix-section-mismatches.patch
-uml-fix-static-linking.patch
-uml-use-correct-register-file-size-everywhere.patch
-ntp-avoid-time_offset-overflows.patch
-ntp-avoid-time_offset-overflows-fix.patch
-drivers-eisa-pci_eisacpci_eisa_init-should-be-init.patch
-fix-struct-device-member-name-in-pcmcia-au1000_generic.patch
-block-io-errors-on-i2o-disk.patch
-ipcns-fix-config_ipc_ns-behavior.patch
-i2o-remove-markus-from-maintainers.patch
-fix-kernel-build-with-embedded-proc_fs-proc_sysctl.patch
-hrtimers-fix-reprogramming-smp-race.patch
-splice-dont-steal.patch
-splice-dont-readpage.patch
-cpuidle-fix-boot-hang.patch
-cpuidle-unsigned-bitfield.patch
-acpi-dock-use-null-for-pointer.patch
-sound-strlcpy-is-smart-enough.patch
-ehea-strlcpy-is-smart-enough.patch
-baycom_ser_fdx-also-allow-i-o-ports-=-0x1000-and-enhanced.patch
-remove-unused-header-file-drivers-net-skfp-h-lnkstath.patch
-tulip-fix-shutdown-dma-irq-race.patch
-sun3-3x-lance-trivial-fix-improved.patch
-forcedeth-fix-nic-poll.patch
-forcedeth-fix-tx-timeout.patch
-forcedeth-work-around-null-skb-dereference-crash-fix.patch
-drivers-net-vioc-possible-cleanups.patch
-bluetooth-hid-quirks-mightymouse-quirk.patch
-fix-gregkh-pci-pci-cleanup-the-includes-of-linux-pcih.patch
-msi-read-flush-msi-x-table.patch
-s390-kmalloc-kzalloc-casting-cleanups.patch
-block-blk_max_pfn-is-somtimes-wrong.patch
-make-elv_register-output-atomic.patch
-gregkh-usb-usb-usb_serial_driver-insufficient-for-clean-disconnect-handling.patch
-mm-set-hashdist_default-to-1-for-x86_64-numa.patch
-i386-modpost-apic-related-warning-fixes.patch
-arch-i386-kernel-alternativec-should-include-asm-bugsh.pat

Re: [patch] remove artificial software max_loop limit

[Ken Chen]

On 3/30/07, Ken Chen <[EMAIL PROTECTED]> wrote:

Remove artificial maximum 256 loop device that can be created due to a
legacy device number limit.  Searching through lkml archive, there are
several instances where users complained about the artificial limit
that the loop driver impose.  There is no reason to have such limit.

This patch rid the limit entirely and make loop device and associated
block queue instantiation on demand.  With on-demand instantiation, it
also gives the benefit of not wasting memory if these devices are not
in use (compare to current implementation that always create 8 loop
devices), a net improvement in both areas.  This version is both
tested with creation of large number of loop devices and is compatible
with existing losetup/mount user land tools.

Signed-off-by: Ken Chen <[EMAIL PROTECTED]>


Spotted one bug: the sequence of loop device lookup, instantiation,
and then insert into global loop_devices_list better be in one
critical section, otherwise smp race ensues.  Fix that up and also use
mutex lock instead of spin_lock for loop_devices_list.

Signed-off-by: Ken Chen <[EMAIL PROTECTED]>

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 6b5b642..1e87aea 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -77,9 +77,8 @@

#include 

-static int max_loop = 8;
-static struct loop_device *loop_dev;
-static struct gendisk **disks;
+static LIST_HEAD(loop_devices);
+static DEFINE_MUTEX(loop_devices_mutex);

/*
 * Transfer functions
@@ -183,7 +182,7 @@ figure_loop_size(struct loop_device *lo)
if (unlikely((loff_t)x != size))
return -EFBIG;

-   set_capacity(disks[lo->lo_number], x);
+   set_capacity(lo->lo_disk, x);
return 0;   
}

@@ -812,7 +811,7 @@ static int loop_set_fd
lo->lo_queue->queuedata = lo;
lo->lo_queue->unplug_fn = loop_unplug;

-   set_capacity(disks[lo->lo_number], size);
+   set_capacity(lo->lo_disk, size);
bd_set_size(bdev, size << 9);

set_blocksize(bdev, lo_blocksize);
@@ -832,7 +831,7 @@ out_clr:
lo->lo_device = NULL;
lo->lo_backing_file = NULL;
lo->lo_flags = 0;
-   set_capacity(disks[lo->lo_number], 0);
+   set_capacity(lo->lo_disk, 0);
invalidate_bdev(bdev, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(mapping, lo->old_gfp_mask);
@@ -918,7 +917,7 @@ static int loop_clr_fd
memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
memset(lo->lo_file_name, 0, LO_NAME_SIZE);
invalidate_bdev(bdev, 0);
-   set_capacity(disks[lo->lo_number], 0);
+   set_capacity(lo->lo_disk, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(filp->f_mapping, gfp);
lo->lo_state = Lo_unbound;
@@ -1322,6 +1321,18 @@ static long lo_compat_ioctl
}
#endif

+static struct loop_device *loop_find_dev(int number)
+{
+   struct loop_device *lo;
+
+   list_for_each_entry(lo, &loop_devices, lo_list) {
+   if (lo->lo_number == number)
+   return lo;
+   }
+   return NULL;
+}
+
+static struct loop_device *loop_init_one(int i);
static int lo_open(struct inode *inode, struct file *file)
{
struct loop_device *lo = inode->i_bdev->bd_disk->private_data;
@@ -1330,6 +1341,11 @@ static int lo_open
lo->lo_refcnt++;
mutex_unlock(&lo->lo_ctl_mutex);

+   mutex_lock(&loop_device_mutex);
+   if (!loop_find_dev(lo->lo_number + 1))
+   loop_init_one(lo->lo_number + 1);
+   mutex_unlock(&loop_device_mutex);
+
return 0;
}

@@ -1357,8 +1373,6 @@ static struct block_device_operations lo_fops
/*
 * And now the modules code and kernel interface.
 */
-module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
MODULE_LICENSE("GPL");
MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);

@@ -1383,7 +1397,7 @@ int loop_unregister_transfer(int number)

xfer_funcs[n] = NULL;

-   for (lo = &loop_dev[0]; lo < &loop_dev[max_loop]; lo++) {
+   list_for_each_entry(lo, &loop_devices, lo_list) {
mutex_lock(&lo->lo_ctl_mutex);

if (lo->lo_encryption == xfer)
@@ -1398,102 +1412,106 @@ int loop_unregister_transfer(int number)
EXPORT_SYMBOL(loop_register_transfer);
EXPORT_SYMBOL(loop_unregister_transfer);

-static int __init loop_init(void)
+static struct loop_device *loop_init_one(int i)
{
-   int i;
+   struct loop_device *lo;
+   struct gendisk *disk;

-   if (max_loop < 1 || max_loop > 256) {
-   printk(KERN_WARNING "loop: invalid max_loop (must be between"
-   " 1 and 256), using default (8)\n");
-   max_loop = 8;
-   }
+   lo = kzalloc(sizeof(*lo), GFP_KERNEL);
+   if (!lo)
+   goto out;

-   if (register_blkdev(LOOP_MAJOR, "loop"))
-   return -EIO;
+   lo->lo_queue = blk_alloc_queue(GFP_KERNEL);

Re: Early hang with 2.6.21-rc4-rt1

[Ingo Molnar]

* Roland Dreier <[EMAIL PROTECTED]> wrote:

> Great, thanks ... I'm not sure which of the 2 patches fixed things, 
> but I now got the following trace.  I've not really analyzed this, but 
> it definitely looks like tun_init() is doing something fishy... 
> ("149776 us maximum-latency"!!)

best would be to enable FUNCTION_TRACING and to do:

echo 1 > /proc/sys/kernel/trace_enabled
echo 1 > /proc/sys/kernel/mcount_enabled

this will give you an exact trace of what happened, in 
/proc/latency_trace.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] remove artificial software max_loop limit

[Jan Engelhardt]

On Mar 30 2007 01:48, Ken Chen wrote:
> On 3/30/07, Ken Chen <[EMAIL PROTECTED]> wrote:

> @@ -812,7 +811,7 @@ static int loop_set_fd
> lo->lo_queue->queuedata = lo;
> lo->lo_queue->unplug_fn = loop_unplug;
>
> - set_capacity(disks[lo->lo_number], size);
> + set_capacity(lo->lo_disk, size);
> bd_set_size(bdev, size << 9);
>
>   set_blocksize(bdev, lo_blocksize);
> @@ -832,7 +831,7 @@ out_clr:
> lo->lo_device = NULL;
> lo->lo_backing_file = NULL;
> lo->lo_flags = 0;
> - set_capacity(disks[lo->lo_number], 0);
> + set_capacity(lo->lo_disk, 0);
> invalidate_bdev(bdev, 0);
> bd_set_size(bdev, 0);
> mapping_set_gfp_mask(mapping, lo->old_gfp_mask);

Welcome to Google Mail, we eat your whitespace :-)

> + sprintf(disk->disk_name, "loop%d", i);

Let's make this %u, no?

> +static struct kobject *loop_probe(dev_t dev, int *part, void *data)
> +{
> + unsigned int number = dev & MINORMASK;
> + struct loop_device *lo;
>
> - for (i = 0; i < max_loop; i++) {
> - disks[i] = alloc_disk(1);
> - if (!disks[i])
> - goto out_mem3;
> - }

Could not we use kobject_uevent(), like I did (though perhaps without
the k.oops), to make udev create a node?


Jan
-- 
-
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/

Ze Cyclades card testing

[Jiri Slaby]

Hi!

I have made some changes in cyclades driver and have only Cyclades Y card to
test, so I'm finding somebody to test Ze card. Doesn't anybody either have the
card or know a person, who has it, please?

thanks,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E

Hnus <[EMAIL PROTECTED]> is an alias for /dev/null
-
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 dependency generation

[Jan Beulich]

>>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 18:38 >>>
>On Thu, 29 Mar 2007 17:06:24 +0100 Jan Beulich wrote:
>
>> >>> Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 17:39 >>>
>> >> --- linux-2.6.21-rc5/scripts/basic/fixdep.c   2007-02-04 
>> >> 19:44:54.0 +0100
>> >> +++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c  2007-03-29 
>> >> 11:11:10.0 +0200
>> >> @@ -29,8 +29,7 @@
>> >>   * option which is mentioned in any of the listed prequisites.
>> >>   *
>> >>   * To be exact, split-include populates a tree in include/config/,
>> >> - * e.g. include/config/his/driver.h, which contains the #define/#undef
>> >> - * for the CONFIG_HIS_DRIVER option.
>> >
>> >I don't see why you deleted the line above.
>> 
>> Because it is no longer true. These files are empty as of 2.6.18.
>
>We seem to be talking about different lines above.  Yes, the files
>are empty, but they are named based on the CONFIG_symbol name, which
>is what I was trying to get at.  So how about a comment like this:
>
> * To be exact, split-include populates a tree in include/config/,
> * e.g., include/config/sysctl/syscall.h,
> * for the CONFIG_SYSCTL_SYSCALL option, when that option
> * is enabled (=y or =m).

Shouldn't that then be '..., when that option is or ever was enabled
(=y or =m) since last cleaning the tree'?

Jan
-
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: Early hang with 2.6.21-rc4-rt1

[Ingo Molnar]

* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> > Great, thanks ... I'm not sure which of the 2 patches fixed things, 
> > but I now got the following trace.  I've not really analyzed this, 
> > but it definitely looks like tun_init() is doing something fishy... 
> > ("149776 us maximum-latency"!!)
> 
> best would be to enable FUNCTION_TRACING and to do:
> 
>   echo 1 > /proc/sys/kernel/trace_enabled
>   echo 1 > /proc/sys/kernel/mcount_enabled
> 
> this will give you an exact trace of what happened, in 
> /proc/latency_trace.

btw., if you use -rt, it makes sense to disable the UNWIND options in 
the .config - the unwinder causes quite some overhead at places.

Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] remove artificial software max_loop limit

[Ken Chen]

On 3/30/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:

> lo->lo_device = NULL;
> lo->lo_backing_file = NULL;
> lo->lo_flags = 0;
> - set_capacity(disks[lo->lo_number], 0);
> + set_capacity(lo->lo_disk, 0);
> invalidate_bdev(bdev, 0);
> bd_set_size(bdev, 0);
> mapping_set_gfp_mask(mapping, lo->old_gfp_mask);

Welcome to Google Mail, we eat your whitespace :-)


Oh, crap.  Google mail is innocent.  It was me who did some ugly
copy-paste between apps.


> + sprintf(disk->disk_name, "loop%d", i);

Let's make this %u, no?


I don't mind either way, this thing won't be bigger than 1^20 anyway.
Oh, which reminds me that we probably should explicitly test and cap
that limit (1^20 that is).


> +static struct kobject *loop_probe(dev_t dev, int *part, void *data)
> +{
> + unsigned int number = dev & MINORMASK;
> + struct loop_device *lo;
>
> - for (i = 0; i < max_loop; i++) {
> - disks[i] = alloc_disk(1);
> - if (!disks[i])
> - goto out_mem3;
> - }

Could not we use kobject_uevent(), like I did (though perhaps without
the k.oops), to make udev create a node?


Well, I go with a version that doesn't panic kernel, which is a
deciding factor here ;-)


Full patch attached.

diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 6b5b642..1e87aea 100644
--- a/drivers/block/loop.c
+++ b/drivers/block/loop.c
@@ -77,9 +77,8 @@

#include 

-static int max_loop = 8;
-static struct loop_device *loop_dev;
-static struct gendisk **disks;
+static LIST_HEAD(loop_devices);
+static DEFINE_MUTEX(loop_devices_mutex);

/*
 * Transfer functions
@@ -183,7 +182,7 @@ figure_loop_size(struct loop_device *lo)
if (unlikely((loff_t)x != size))
return -EFBIG;

-   set_capacity(disks[lo->lo_number], x);
+   set_capacity(lo->lo_disk, x);
return 0;   
}

@@ -812,7 +811,7 @@ static int loop_set_fd
lo->lo_queue->queuedata = lo;
lo->lo_queue->unplug_fn = loop_unplug;

-   set_capacity(disks[lo->lo_number], size);
+   set_capacity(lo->lo_disk, size);
bd_set_size(bdev, size << 9);

set_blocksize(bdev, lo_blocksize);
@@ -832,7 +831,7 @@ out_clr:
lo->lo_device = NULL;
lo->lo_backing_file = NULL;
lo->lo_flags = 0;
-   set_capacity(disks[lo->lo_number], 0);
+   set_capacity(lo->lo_disk, 0);
invalidate_bdev(bdev, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(mapping, lo->old_gfp_mask);
@@ -918,7 +917,7 @@ static int loop_clr_fd
memset(lo->lo_crypt_name, 0, LO_NAME_SIZE);
memset(lo->lo_file_name, 0, LO_NAME_SIZE);
invalidate_bdev(bdev, 0);
-   set_capacity(disks[lo->lo_number], 0);
+   set_capacity(lo->lo_disk, 0);
bd_set_size(bdev, 0);
mapping_set_gfp_mask(filp->f_mapping, gfp);
lo->lo_state = Lo_unbound;
@@ -1322,6 +1321,18 @@ static long lo_compat_ioctl
}
#endif

+static struct loop_device *loop_find_dev(int number)
+{
+   struct loop_device *lo;
+
+   list_for_each_entry(lo, &loop_devices, lo_list) {
+   if (lo->lo_number == number)
+   return lo;
+   }
+   return NULL;
+}
+
+static struct loop_device *loop_init_one(int i);
static int lo_open(struct inode *inode, struct file *file)
{
struct loop_device *lo = inode->i_bdev->bd_disk->private_data;
@@ -1330,6 +1341,11 @@ static int lo_open
lo->lo_refcnt++;
mutex_unlock(&lo->lo_ctl_mutex);

+   mutex_lock(&loop_device_mutex);
+   if (!loop_find_dev(lo->lo_number + 1))
+   loop_init_one(lo->lo_number + 1);
+   mutex_unlock(&loop_device_mutex);
+
return 0;
}

@@ -1357,8 +1373,6 @@ static struct block_device_operations lo_fops
/*
 * And now the modules code and kernel interface.
 */
-module_param(max_loop, int, 0);
-MODULE_PARM_DESC(max_loop, "Maximum number of loop devices (1-256)");
MODULE_LICENSE("GPL");
MODULE_ALIAS_BLOCKDEV_MAJOR(LOOP_MAJOR);

@@ -1383,7 +1397,7 @@ int loop_unregister_transfer(int number)

xfer_funcs[n] = NULL;

-   for (lo = &loop_dev[0]; lo < &loop_dev[max_loop]; lo++) {
+   list_for_each_entry(lo, &loop_devices, lo_list) {
mutex_lock(&lo->lo_ctl_mutex);

if (lo->lo_encryption == xfer)
@@ -1398,102 +1412,106 @@ int loop_unregister_transfer(int number)
EXPORT_SYMBOL(loop_register_transfer);
EXPORT_SYMBOL(loop_unregister_transfer);

-static int __init loop_init(void)
+static struct loop_device *loop_init_one(int i)
{
-   int i;
+   struct loop_device *lo;
+   struct gendisk *disk;

-   if (max_loop < 1 || max_loop > 256) {
-   printk(KERN_WARNING "loop: invalid max_loop (must be between"
-   " 1 and 256), using default (8)\n");
-   max_loop = 8;
-   }
+   lo = kzalloc(sizeof(*lo), GFP_KERNEL);
+   if (!lo)
+   goto out;

-   if (regis

Re: [PATCH] CPUSETS: add mems to basic usage documentation

[Paul Jackson]

Simon Horman wrote:
> +++ linux-2.6/Documentation/cpusets.txt   2007-03-30 13:03:19.0 
> +0900
> ...
> +Add some mems:
> +# /bin/echo 0-7 > mems

Nice change - thanks.

Acked-by: Paul Jackson <[EMAIL PROTECTED]>


(I probably would not add a dmesg complaint; we don't usually
do that for ordinary system call failures.  Pay close attention
to the resulting errno - in this case ENOSPC.)

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson <[EMAIL PROTECTED]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

[Jan Glauber]

Hi Thomas,

> with 2.6.20.4 it works great, but when switching to 2.6.21-rcX it breaks 
> with this:
> 
> drivers/crypto/Kconfig:55: can't open file "arch/s390/crypto/Kconfig"

arch/s390/crypto/Kconfig is included there since that is the right place
for the config options to show up.

> I tried to fix drivers/crypto/Kconfig by changing the code to:
> 
> if S390
> source "arch/s390/crypto/Kconfig"
> endif
> 
> but it still gets sourced...

You would need something like:

source "arch/s390/crypto/Kconfig"
depends on S390

But that is not implemented and I doubt it will since deleting parts of
the kernel tree is not something that is required to work.

Jan

-
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] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[David Howells]

Wu, Bryan <[EMAIL PROTECTED]> wrote:

> It takes lots of time in malloc()->mmap()->do_mmap_private()->memset(). When
> malloc a big area, memset() the area to zero makes the performance very bad.

Ummm...

How do you then cope with attempting to run that same application under
MMU-mode Linux?  Won't MMU mmap() give EINVAL?  If so, then that'd be grounds
for NAK'ing this patch in the form given.

My theory is that NOMMU binaries should run just as well under an MMU-mode
kernel as under a NOMMU kernel.

What you're asking for is also a security risk - though obviously on NOMMU-mode
one that's fairly irrelevant.  It might even make a lot of sense there to move
the clearance into uClibc where possible rather than doing it in the kernel.

On MMU-mode kernels, the option should just be ignored.

I'd also recommend you stick a 'D' on the end of 'MAP_UNINITIALIZE' or may be
call it MAP_UNCLEARED'.  But that's a minor point, but you're not telling
mmap() to go and uninitialise the memory...

Lastly, why do you actually need VM_UNINITIALIZE at all?  The flag is only used
in a place where MAP_UNINITIALIZE is still available (okay, you'll have to hand
it down as an extra argument).  That looks like a waste of a VM_xxx flag, and
we don't have that many to spare.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space

[Ingo Molnar]

On Thu, 2007-02-22 at 17:06 -0800, Venkatesh Pallipadi wrote:
> Patchset enables force detection of HPET, when it is not listed by
> BIOS.
> and enables use of HPET as a event source. HPET timers
> configures in stamdard interrupt mode can be used as dependable per
> CPU timer
> on laptops that are known to have LAPIC stoppage with ACPI C3 state.

(sorry about the belated reply)

cool patchset! I suspect the most logical place to start this would be
on upstream 32-bit, which has the hpet clockevents changes already.
Plus the i386 and x86_64 hpet code should be unified.

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

[Robert P. J. Day]

On Fri, 30 Mar 2007, Jan Glauber wrote:

> Hi Thomas,
>
> > with 2.6.20.4 it works great, but when switching to 2.6.21-rcX it breaks
> > with this:
> >
> > drivers/crypto/Kconfig:55: can't open file "arch/s390/crypto/Kconfig"
>
> arch/s390/crypto/Kconfig is included there since that is the right place
> for the config options to show up.
>
> > I tried to fix drivers/crypto/Kconfig by changing the code to:
> >
> > if S390
> > source "arch/s390/crypto/Kconfig"
> > endif
> >
> > but it still gets sourced...
>
> You would need something like:
>
> source "arch/s390/crypto/Kconfig"
>   depends on S390
>
> But that is not implemented and I doubt it will since deleting parts
> of the kernel tree is not something that is required to work.

  i would think the obvious solution is to move the entire contents of
the s390-specific crypto/Kconfig into the generic one.  obviously,
everything would still work since all of those config options would
still depend on S390.

  i'm betting the S390 folks would *really* hate that idea but, if you
look closely, the generic Kconfig file *already* has some
arch-dependent content:

...
config CRYPTO_DEV_PADLOCK
tristate "Support for VIA PadLock ACE"
depends on X86_32 <-
...

  i think it's a matter of deciding how to be consistent.  either you
allow individual architectures to define their own additional Kconfig
files or you don't.  mixing the two approaches is a recipe for
confusion.

rday


-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page

-
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/

Heads up on VFS based union mount

[Bharata B Rao]

The need for a unified/merged view of two or more filesystems/directories
has been felt for sometime now. Though a few out-of-the-kernel solutions
existed for this, it is only recently that the unionfs(1) solution has gone
into -mm. At the time of merging unionfs into -mm, a few questions were
raised about the appropriateness of having this namespace unification
feature as a separate stackable file system. Encouraged by this comment
from Andrew (http://lkml.org/lkml/2007/1/8/280) and also the interest about
unionfs in recently concluded Linux Storage and Filesystem Workshop(2),
I started looking into Jan Blunck's 2004 diploma thesis work where he had
implemented a VFS based union mount feature. Now Jan and I are working
towards moving this to latest kernel and bringing it to a stage that it
can posted as an RFC. While we are at it, we thought lets give a heads up
on our union mount effort and try to get some early feedbacks/opinions.

While unionfs implements a new filesystem and maintains a set
of VFS objects which stack the real VFS objects under them to get the
unification feature, union mount achieves the same stacking with
minimal (atleast conceptually minimal) changes at the VFS layer.

In union mount approach we maintain this stacking information in the
dentry structure. When a filesytem is union mounted on a mountpoint,
the dentry of the mount root would hold a reference to the mountpoint
dentry as an overlaid dentry and these two dentries together form
a union stack. Any subsequent readdir operation on this union mounted
dentry would work on the overlaid dentry also thereby providing the
merged view of the two filesystems.

Since the stacking information is maintained at the VFS layer, union
mount makes some heavy changes to the VFS lookup code and minor changes
to many VFS routines. Also the whiteout filetype is handled in kernel
and the physical filesytem is expected to support the new whiteout file type.
For copyup, we are right now using a hack of pipe/splice to get the
in-kernel file copy between two layers.

We are planning to post the RFC code pretty soon. More documentation
about the approach would accompany the code.

(1) Unionfs: http://www.filesystems.org/project-unionfs.html
(2) LWN article on LSF07: http://lwn.net/Articles/226351/

Regards,
Bharata.
-
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] Use X86_EFLAGS_IF in x86-64/irqflags.h.

[Andi Kleen]

On Fri, Mar 30, 2007 at 01:12:23PM +1000, Rusty Russell wrote:
> On Thu, 2007-03-29 at 14:19 +0200, Andi Kleen wrote:
> > On Thu, Mar 29, 2007 at 09:06:57PM +1000, Rusty Russell wrote:
> 
> [SNIP: processor-flags.h patch for i386 ]
> 
> > Ok. Can you do it for x86-64 too?
> 
> OK, here it is.  Compiles, but -rc5-mm2 doesn't link for me on x86-64 at
> the moment.

What's the problem? 

> 
> Something seems quite wrong with CONFIG_X86_VSMP.  AFAICT (1 << 18) is
> the "alignment check" flag, not the "virtual interrupt" flag which I
> expected.

They abuse that intentionally as a way to talk to their hypervisor.
You don't want to know details.

-Andi
-
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/4] coredump: add an interface to control the core dump routine

[Kawai, Hidehiro]

Hi,

Andrew Morton wrote:

> On Thu, 29 Mar 2007 20:16:59 +0100
> David Howells <[EMAIL PROTECTED]> wrote:
> 
>>Pavel Machek <[EMAIL PROTECTED]> wrote:
>>
Userland core dumper is useful because it is relatively easy to be
customized, but its reliability highly depends on the application
programs.
>>>
>>>Fix userland core dumper to be reliable, then.
>>
>>I don't think it's that easy.  The userland core dumper, as I understand it,
>>has to work *within* an application program (it's a library), thus the
>>application program my scotch the core dumper in a couple of ways:
> 
> That's no longer necessarily true with the recently-added
> dump-to-an-application feature:
> 
> core_pattern:
>   ...
> . If the first character of the pattern is a '|', the kernel will treat
>   the rest of the pattern as a command to run.  The core dump will be
>   written to the standard input of that program instead of to a file.

I think dumping core over a pipe is almost good.  Filtering and writing
out a core by a separete userspace program can be reliable because it is
independent of the failed user process.  But I have one concern; data
transfer over a pipe is slow.  It took 7 seconds to transfer 2GB
anonymous shared memory (detailed at the last of this mail).

In the case of dumping hundreds processes which share giga bytes memory,
it will take a few minutes even if the huge shared memory is not written
to a disk.  If a user wants to restart the failed application as soon
as possible to keep downtime to a minimum, this extra transfer time will
be a barrier.  So I think in-kernel filtering is still needed.


I performed a simple experiment to confirm the transfer speed:
  1. run a program which allocates 2GB anonymous shared memory
  2. the program receives SIGSEGV
  3. core image is generated and passed to tp_pipe(*) over a pipe
  4. tp_pipe reads the pipe and revokes the received data while
 data arrives
  5. tp_pipe logs time of completing the data transfer
  6. repeat 1 to 5 ten times and calculate the average and standard
 deviation

  (*) test program which I prepared for this experiment

Here is the result:
 Average: 7.041 sec
  Standard deviation: 0.903


And cpuinfo and meminfo of my box:

$ cat /proc/cpuinfo
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Xeon(TM) CPU 3.20GHz
stepping: 1
cpu MHz : 3200.343
cache size  : 1024 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc 
pni monitor ds_cpl cid cx16 xtpr
bogomips: 6404.82
clflush size: 64

processor   : 1
vendor_id   : GenuineIntel
cpu family  : 15
model   : 4
model name  : Intel(R) Xeon(TM) CPU 3.20GHz
stepping: 1
cpu MHz : 3200.343
cache size  : 1024 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 5
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc 
pni monitor ds_cpl cid cx16 xtpr
bogomips: 6400.75
clflush size: 64
$ cat /proc/meminfo
MemTotal:  8309240 kB
MemFree:   8216036 kB
Buffers: 11888 kB
Cached:  45200 kB
SwapCached:  0 kB
Active:  42324 kB
Inactive:26008 kB
HighTotal: 7470896 kB
HighFree:  7405504 kB
LowTotal:   838344 kB
LowFree:810532 kB
SwapTotal:16386260 kB
SwapFree: 16386260 kB
Dirty:   4 kB
Writeback:   0 kB
AnonPages:   11232 kB
Mapped:   5828 kB
Slab:11916 kB
SReclaimable: 5604 kB
SUnreclaim:   6312 kB
PageTables:896 kB
NFS_Unstable:0 kB
Bounce:  0 kB
CommitLimit:  20540880 kB
Committed_AS:33540 kB
VmallocTotal:   118776 kB
VmallocUsed:  8324 kB
VmallocChunk:   110408 kB
HugePages_Total: 0
HugePages_Free:  0
HugePages_Rsvd:  0
Hugepagesize: 2048 kB

Thanks,
-- 
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory

-
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: Software RAID (non-preempt) server blocking question. (2.6.20.4)

[Justin Piszcz]

On Fri, 30 Mar 2007, Neil Brown wrote:


On Thursday March 29, [EMAIL PROTECTED] wrote:




Did you look at "cat /proc/mdstat" ?? What sort of speed was the check
running at?

Around 44MB/s.

I do use the following optimization, perhaps a bad idea if I want other
processes to 'stay alive'?

echo "Setting minimum resync speed to 200MB/s..."
echo "This improves the resync speed from 2.1MB/s to 44MB/s"
echo 20 > /sys/block/md0/md/sync_speed_min
echo 20 > /sys/block/md1/md/sync_speed_min
echo 20 > /sys/block/md2/md/sync_speed_min
echo 20 > /sys/block/md3/md/sync_speed_min
echo 20 > /sys/block/md4/md/sync_speed_min



Yes, well

You told it to use up to 200MB/s and the drives are only delivering
44MB/s, so they will be taking nearly all of the available bandwidth.
You shouldn't be too surprised if other things suffer.

NeilBrown



Understood, will reduce this, thanks.

Justin.
-
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] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[Aubrey Li]

On 3/30/07, David Howells <[EMAIL PROTECTED]> wrote:

Wu, Bryan <[EMAIL PROTECTED]> wrote:

> It takes lots of time in malloc()->mmap()->do_mmap_private()->memset(). When
> malloc a big area, memset() the area to zero makes the performance very bad.

Ummm...

How do you then cope with attempting to run that same application under
MMU-mode Linux?  Won't MMU mmap() give EINVAL?  If so, then that'd be grounds
for NAK'ing this patch in the form given.

My theory is that NOMMU binaries should run just as well under an MMU-mode
kernel as under a NOMMU kernel.

What you're asking for is also a security risk - though obviously on NOMMU-mode
one that's fairly irrelevant.  It might even make a lot of sense there to move
the clearance into uClibc where possible rather than doing it in the kernel.

On MMU-mode kernels, the option should just be ignored.

I'd also recommend you stick a 'D' on the end of 'MAP_UNINITIALIZE' or may be
call it MAP_UNCLEARED'.  But that's a minor point, but you're not telling
mmap() to go and uninitialise the memory...

Lastly, why do you actually need VM_UNINITIALIZE at all?  The flag is only used
in a place where MAP_UNINITIALIZE is still available (okay, you'll have to hand
it down as an extra argument).  That looks like a waste of a VM_xxx flag, and
we don't have that many to spare.



Well, I don't understand why we have to clear the allocation memory.
I suggest we just remove the memset(addr, 0, len) operation at all.
Read the malloc manual, you'll get

malloc() allocates size bytes and returns a pointer to the allocated memory.
The memory is not cleared.

So, if not clearing the memory causes one application hang/crash,
that's the bug of that application and it need to be fixed.

The patch in my option is:

diff --git a/mm/nommu.c b/mm/nommu.c
index cbbc137..fe2b6d4 100644
--- a/mm/nommu.c
+++ b/mm/nommu.c
@@ -759,10 +759,6 @@ static int do_mmap_private(struct vm_are
   /* clear the last little bit */
   if (ret < len)
   memset(base + ret, 0, len - ret);
-
-   } else {
-   /* if it's an anonymous mapping, then just clear it */
-   memset(base, 0, len);
   }

   return 0;


-Aubrey
-
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/

Kernel LZO compression + jffs2 and crypto usage

[Richard Purdie]

I've put the LZO patch series I sent a few weeks ago in a git tree:

http://git.o-hand.com/?p=linux-rpurdie;a=shortlog;h=linux-rpurdie-lzo

(git://git.o-hand.com/linux-rpurdie linux-rpurdie-lzo)

I'm not sure of the best way to merge this since it touches two
subsystems. David, do you want to pull the initial patch and jffs2 parts
and then the crpyto patch can follow through the crypto tree? I'm hoping
this can make 2.6.22. 

Let me know if there is anything further I can do to help.

Cheers,

Richard

-
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.21-rc5-mm3

[Rafael J. Wysocki]

On Friday, 30 March 2007 10:05, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/
> 
> - git-cryptodev has things in it again
> 
> - Re-added git-e1000: a large amount of e1000 driver work
> 
> - git-net has a huge amount of material in it, but I dropped it because it
>   went oops.
> 
> - git-block is back, minus the problematic unplugging rework.
> 
> - Lots of x86 updates.
> 
> - lguest is being redone and has been dropped
> 
> - The IDE development tree has been restored

On my system (x86_64) 'make install_modules' produces a lot of warning messages:

if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map  
2.6.21-rc5-mm3; fi
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol __nf_ct_l4proto_find
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_find_get
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_l4proto_register
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_l4proto_udp6
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_checksum
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol __nfa_fill
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_ct_get_tuple
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol __nf_ct_event_cache_init
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_l3proto_register
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_ct_log_invalid
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_l4proto_tcp6
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol need_conntrack
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_l4proto_unregister
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol per_cpu__nf_conntrack_stat
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol __nf_conntrack_confirm
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_ct_invert_tuple
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol per_cpu__nf_conntrack_ecache
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_l3proto_unregister
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_ct_deliver_cached_events
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol __nf_ct_refresh_acct
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko 
needs unknown symbol nf_conntrack_in
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_rt.ko needs 
unknown symbol xt_register_match
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_rt.ko needs 
unknown symbol xt_unregister_match
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_owner.ko 
needs unknown symbol xt_register_match
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_owner.ko 
needs unknown symbol xt_unregister_match
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_mh.ko needs 
unknown symbol xt_register_match
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_mh.ko needs 
unknown symbol xt_unregister_match
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_ipv6header.ko needs 
unknown symbol xt_register_match
WARNING: 
/lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_ipv6header.ko needs 
unknown symbol xt_unregister_match
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_hl.ko needs 
unknown symbol xt_register_match
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_hl.ko needs 
unknown symbol xt_unregister_match
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_hbh.ko 
needs unknown symbol xt_unregister_matches
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_hbh.ko 
needs unknown symbol xt_register_matches
WARNING: /lib/modules/2.6.21-rc5-mm3/kernel/net/ipv6/netfilter/ip6t_frag.ko 
needs unknown symbol xt_register_match
WARNING: /l

Re: [PATCH] Use X86_EFLAGS_IF in x86-64/irqflags.h.

[Rusty Russell]

On Fri, 2007-03-30 at 12:12 +0200, Andi Kleen wrote:
> On Fri, Mar 30, 2007 at 01:12:23PM +1000, Rusty Russell wrote:
> > On Thu, 2007-03-29 at 14:19 +0200, Andi Kleen wrote:
> > > On Thu, Mar 29, 2007 at 09:06:57PM +1000, Rusty Russell wrote:
> > 
> > [SNIP: processor-flags.h patch for i386 ]
> > 
> > > Ok. Can you do it for x86-64 too?
> > 
> > OK, here it is.  Compiles, but -rc5-mm2 doesn't link for me on x86-64 at
> > the moment.
> 
> What's the problem? 

Sorry, should have included it, I assumed a known issue:

  LD  .tmp_vmlinux1
ld: section .vsyscall_1 [00533400 -> 0053342e] overlaps section 
.jiffies [00533400 -> 00533407]
ld: .tmp_vmlinux1: section .vsyscall_1 lma 0x533400 overlaps previous sections
make: *** [.tmp_vmlinux1] Error 1

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/

[PATCH] Provide dummy devm_ioport_* if !HAS_IOPORT

[Russell King]

Provide an dummy implementation of devm_ioport_map() and
devm_ioport_unmap() to allow drivers (eg, pata_platform) to build for
platforms where CONFIG_NO_IOPORT is selected.

Signed-off-by: Russell King <[EMAIL PROTECTED]>
---
 include/linux/io.h |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/include/linux/io.h b/include/linux/io.h
index c244a0c..8cf8df6 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -33,9 +33,22 @@ int ioremap_page_range(unsigned long addr, unsigned long end,
 /*
  * Managed iomap interface
  */
+#ifdef CONFIG_HAS_IOPORT
 void __iomem * devm_ioport_map(struct device *dev, unsigned long port,
   unsigned int nr);
 void devm_ioport_unmap(struct device *dev, void __iomem *addr);
+#else
+static inline void __iomem * devm_ioport_map(struct device *dev,
+unsigned long port,
+unsigned int nr)
+{
+   return NULL;
+}
+
+static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
+{
+}
+#endif
 
 void __iomem * devm_ioremap(struct device *dev, unsigned long offset,
unsigned long size);

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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/

[RFC] pata_platform for ARM RiscPC

[Russell King]

Add pata_platform device for RiscPC, thereby converting the primary
IDE channel on the machine to PATA.

Signed-off-by: Russell King <[EMAIL PROTECTED]>
---

Since this is dependent on the previous patch (to avoid build errors)
this needs to wait until the devm_ioport patch is merged.  I'll
therefore push this through the ARM tree at the appropriate time.

 arch/arm/mach-rpc/riscpc.c |   35 +++
 drivers/ata/Kconfig|2 +-
 2 files changed, 36 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-rpc/riscpc.c b/arch/arm/mach-rpc/riscpc.c
index 208a2b5..711a2db 100644
--- a/arch/arm/mach-rpc/riscpc.c
+++ b/arch/arm/mach-rpc/riscpc.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -159,11 +160,45 @@ static struct plat_serial8250_port serial_platform_data[] 
= {
},
 };
 
+static struct pata_platform_info pata_platform_data = {
+   .ioport_shift   = 2,
+};
+
+static struct resource pata_resources[] = {
+   [0] = {
+   .start  = 0x030107c0,
+   .end= 0x030107df,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .start  = 0x03010fd8,
+   .end= 0x03010fdb,
+   .flags  = IORESOURCE_MEM,
+   },
+   [2] = {
+   .start  = IRQ_HARDDISK,
+   .end= IRQ_HARDDISK,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device pata_device = {
+   .name   = "pata_platform",
+   .id = -1,
+   .num_resources  = ARRAY_SIZE(pata_resources),
+   .resource   = pata_resources,
+   .dev= {
+   .platform_data  = &pata_platform_data,
+   .coherent_dma_mask = ~0,/* grumble */
+   },
+};
+
 static struct platform_device *devs[] __initdata = {
&iomd_device,
&kbd_device,
&serial_device,
&acornfb_device,
+   &pata_device,
 };
 
 static int __init rpc_init(void)
diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index d16b5b0..d8a9758 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -545,7 +545,7 @@ config PATA_WINBOND_VLB
 
 config PATA_PLATFORM
tristate "Generic platform device PATA support"
-   depends on EMBEDDED
+   depends on EMBEDDED || ARCH_RPC
help
  This option enables support for generic directly connected ATA
  devices commonly found on embedded systems.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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] Provide dummy devm_ioport_* if !HAS_IOPORT

[Christoph Hellwig]

On Fri, Mar 30, 2007 at 12:00:22PM +0100, Russell King wrote:
> Provide an dummy implementation of devm_ioport_map() and
> devm_ioport_unmap() to allow drivers (eg, pata_platform) to build for

Btw, I there a chance we can collect all the devm_* crap into a single
implementation and header file instead of spreading it all over the
tree?

-
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: Kernel LZO compression + jffs2 and crypto usage

[Herbert Xu]

On Fri, Mar 30, 2007 at 11:11:58AM +0100, Richard Purdie wrote:
>
> I'm not sure of the best way to merge this since it touches two
> subsystems. David, do you want to pull the initial patch and jffs2 parts
> and then the crpyto patch can follow through the crypto tree? I'm hoping
> this can make 2.6.22. 

That would be my preference.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[David Howells]

Aubrey Li <[EMAIL PROTECTED]> wrote:

> malloc() allocates size bytes and returns a pointer to the allocated memory.
> The memory is not cleared.

But this is *not* malloc().  It's mmap().  Are you prepared to guarantee that
there are no applications out there that don't rely on anon mmap() giving
zeroed memory?

The MMU-mode clearing is done for security reasons - there shouldn't be any
leakage between processes, and because the zero page can just be faulted in.

Personally, I'd prefer to maintain compatibility with MMU-mode wherever
possible, but I'm happy with overrides like the MAP_UNINITIALISED flag
suggested.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

broken device locking, sg vs. sg_io on block devices

[Eduard Bloch]

Hello,

I am talking this issue to LKML now.

Short story: using O_EXCL on /dev/srX alone does not help to prevent
other process from killing your burn process by just reading the
/dev/sgX device associated with yours, and vice versa. We have done the
best we could to make safe operation (in contrary to Schilling's
kill-this-evil-hald-thing bitching) but that is not enough, the locking
has to be established on kernel layer.

Long story:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960
https://bugzilla.novell.com/show_bug.cgi?id=226019
http://lists.alioth.debian.org/pipermail/debburn-devel/2007-February/000297.html
and other error messages.

There is AFAICS no simple way to establish locking across the driver
borders. If kernel developers have a good idea, any help is appreciated.

Below are the typical symptoms: wodim operates via /dev/sgX because the
user chosen it this way, some other process (most likely hald) comes
along and reads from /dev/sr0 and the drive gets confused. Boom.

Regards,
Eduard.

* Gerald Lutter [Mon, Mar 26 2007, 06:10:44PM]:
> Hello List,
> 
> i've tried to burn the grml_0.9.iso to a cdr/cd-rw medium using wodim from 
> cdrkit 1.1.2 and the burner HL-DT-ST GMA-4082N. The iso can be fetched 
> >from "http://www.grml.org";.
> 
> To make a long story short, burning this image to dvd+r and dvd+rw media 
> works 
> without any problems but I need this image on a cdr or cd-rw medium. I've 
> attatched the output of the command I used to this mail:
> 
> /usr/bin/wodim -vvv -VVV gracetime=2 dev=2,0,0 speed=10 
   ^
> driveropts=burnfree -eject -overburn -data /tmp/grml_0.9.iso
...
> 
Track 01:0 of  692 MB written.
> write track data: error after 317440 bytes
...
> Sense Key: 0x2 Not Ready, Segment 0
> Sense Code: 0x04 Qual 0x08 (logical unit not ready, long write in progress) 
> Fru 0x0
> Sense flags: Blk 0 (not valid) 


-- 
* Amaya knuddelt Ganneff because of his email to private :*
 ich wusst doch dass die irgendwo was schlechtes nach sich zieht.
-
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/

staircase deadline 0.37 backport 2.6.18.8 and 2.6.19.7 & debian sarge/etch kernel availability

[Fortier,Vincent [Montreal]]

 
Hi all,
 
Backports of the staircase deadline cpu scheduler version 0.37 for
2.6.18.8 and 2.6.19.7 kernels are available at
http://linux-dev.qc.ec.gc.ca/.

Also, Debian Etch 4.0 and Sarge 3.1 kernels for i686 are available (Deb
etch amd64 is currently compiling and FC6 will follow).

Vincent Fortier
Informatique
Environnement Canada

-
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:cleanup] Make /dev/port conditional on config symbol

[Russell King]

Instead of having /dev/port support dependent in multiple places on
a string of preprocessor symbols, define a new configuration directive
for it.  This ensures that all four places remain consistent with
each other.

Signed-off-by: Russell King <[EMAIL PROTECTED]>
---
 drivers/char/Kconfig |6 ++
 drivers/char/mem.c   |8 
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/char/Kconfig b/drivers/char/Kconfig
index 3429ece..a754603 100644
--- a/drivers/char/Kconfig
+++ b/drivers/char/Kconfig
@@ -1038,5 +1038,11 @@ config TELCLOCK
  /sys/devices/platform/telco_clock, with a number of files for
  controlling the behavior of this hardware.
 
+config DEVPORT
+   bool
+   depends on !M68K
+   depends on ISA || PCI
+   default y
+
 endmenu
 
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index f5c160c..8bca2f1 100644
--- a/drivers/char/mem.c
+++ b/drivers/char/mem.c
@@ -552,7 +552,7 @@ static ssize_t write_kmem(struct file * file, const char 
__user * buf,
return virtr + wrote;
 }
 
-#if (defined(CONFIG_ISA) || defined(CONFIG_PCI)) && !defined(__mc68000__)
+#ifdef CONFIG_DEVPORT
 static ssize_t read_port(struct file * file, char __user * buf,
 size_t count, loff_t *ppos)
 {
@@ -835,7 +835,7 @@ static const struct file_operations null_fops = {
.splice_write   = splice_write_null,
 };
 
-#if (defined(CONFIG_ISA) || defined(CONFIG_PCI)) && !defined(__mc68000__)
+#ifdef CONFIG_DEVPORT
 static const struct file_operations port_fops = {
.llseek = memory_lseek,
.read   = read_port,
@@ -913,7 +913,7 @@ static int memory_open(struct inode * inode, struct file * 
filp)
case 3:
filp->f_op = &null_fops;
break;
-#if (defined(CONFIG_ISA) || defined(CONFIG_PCI)) && !defined(__mc68000__)
+#ifdef CONFIG_DEVPORT
case 4:
filp->f_op = &port_fops;
break;
@@ -960,7 +960,7 @@ static const struct {
{1, "mem", S_IRUSR | S_IWUSR | S_IRGRP, &mem_fops},
{2, "kmem",S_IRUSR | S_IWUSR | S_IRGRP, &kmem_fops},
{3, "null",S_IRUGO | S_IWUGO,   &null_fops},
-#if (defined(CONFIG_ISA) || defined(CONFIG_PCI)) && !defined(__mc68000__)
+#ifdef CONFIG_DEVPORT
{4, "port",S_IRUSR | S_IWUSR | S_IRGRP, &port_fops},
 #endif
{5, "zero",S_IRUGO | S_IWUGO,   &zero_fops},

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:
-
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: [QUESTION] check for mem in slab

[Pekka Enberg]

On 3/30/07, Heiko Carstens <[EMAIL PROTECTED]> wrote:

> in file mm/slab.c and routine kmem_cache_init() I found there
> is no checking for allocated memory on line:
>
>   /* 4) Replace the bootstrap head arrays */
>   {
>   struct array_cache *ptr;
>
>   ptr = kmalloc(sizeof(struct arraycache_init), GFP_KERNEL);
>
> --> no check for ptr == NULL <--
[...]
> is that OK? or it's a bug?

It's ok. If that allocation fails your machine won't come up anyway.


We ought to add a BUG_ON or comment at least there as this keeps
popping up again and again.
-
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/

[bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

[Ingo Molnar]

i just found a new category of driver regressions in 2.6.21, doing 
allyesconfig bzImage bootup tests: the init methods of various drivers 
hangs in driver_unregister().

It is caused by this problem: the semantics of driver_unregister() [also 
implicitly called in pci_driver_unregister()] has apparently changed 
recently. If a driver does:

pci_register_driver(&my_driver);
...
if (some_failure) {
pci_unregister_driver(&my_driver);
...
}

it will hang the bootup in the following piece of code:

 drivers/base/driver.c:

  void driver_unregister(struct device_driver * drv)
  {
 bus_remove_driver(drv);
 wait_for_completion(&drv->unloaded);

the completion is never done - because nobody removes the bus while the 
init is still happening, obviously. (and bootup is serialized anyway)

now, the majority of drivers does the driver unregistry from its 
module-cleanup function, so it's not affected by this problem. But if 
you apply the debug patch attached further below, and do an allyesconfig 
bzImage bootup, there's 3 hits already:

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [] show_trace_log_lvl+0x19/0x2e
  [] show_trace+0x12/0x14
  [] dump_stack+0x14/0x16
  [] driver_unregister+0x3d/0x43
  [] pci_unregister_driver+0x10/0x5f
  [] slgt_init+0x9b/0x1ca
  [] init+0x15d/0x2bd
  [] kernel_thread_helper+0x7/0x10

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [] show_trace_log_lvl+0x19/0x2e
  [] show_trace+0x12/0x14
  [] dump_stack+0x14/0x16
  [] driver_unregister+0x3d/0x43
  [] pci_unregister_driver+0x10/0x5f
  [] init_ipmi_si+0x70a/0x738
  [] init+0x15d/0x2bd
  [] kernel_thread_helper+0x7/0x10

 BUG: at drivers/base/driver.c:187 driver_unregister()
  [] show_trace_log_lvl+0x19/0x2e
  [] show_trace+0x12/0x14
  [] dump_stack+0x14/0x16
  [] driver_unregister+0x3d/0x43
  [] pci_unregister_driver+0x10/0x5f
  [] tlan_probe+0x2dd/0x30e
  [] init+0x15d/0x2bd
  [] kernel_thread_helper+0x7/0x10

possibly more could trigger. Each of these 3 places caused an actual 
bootup hang on my testbox, so these are real regressions and need to be 
fixed.

because there are a good number of drivers that do 
pci_unregister_device() from their init function, and because i cannot 
see anything obviously wrong in doing an unregister call after a 
failure, i think it's driver_unregister() that needs to be fixed. Greg, 
what do you think?

Ingo

Index: linux/drivers/base/driver.c
===
--- linux.orig/drivers/base/driver.c
+++ linux/drivers/base/driver.c
@@ -183,7 +183,8 @@ int driver_register(struct device_driver
 void driver_unregister(struct device_driver * drv)
 {
bus_remove_driver(drv);
-   wait_for_completion(&drv->unloaded);
+   if (!drv->unloaded.done)
+   WARN_ON(1);
 }
 
 /**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"

[Ingo Molnar]

there's a new type of message in allyesconfig-bzImage bootup test:

Calling initcall 0xc1b6d692: fixed_init+0x0/0x33()
Fixed PHY: Registered new driver
Device '[EMAIL PROTECTED]:1' does not have a release() function, it is broken 
and must be fixed.
BUG: at drivers/base/core.c:120 device_release()
 [] show_trace_log_lvl+0x19/0x2e
 [] show_trace+0x12/0x14
 [] dump_stack+0x14/0x16
 [] device_release+0x7c/0x7e
 [] kobject_cleanup+0x44/0x5e
 [] kobject_release+0xb/0xd
 [] kref_put+0x63/0x71
 [] kobject_put+0x14/0x16
 [] put_device+0x11/0x13
 [] device_unregister+0x12/0x15
 [] fixed_mdio_register_device+0x210/0x23b
 [] fixed_init+0x1e/0x33
 [] init+0x15d/0x2bd
 [] kernel_thread_helper+0x7/0x10
 ===
Device '[EMAIL PROTECTED]:1' does not have a release() function, it is broken 
and must be fixed.
BUG: at drivers/base/core.c:120 device_release()
 [] show_trace_log_lvl+0x19/0x2e
 [] show_trace+0x12/0x14
 [] dump_stack+0x14/0x16
 [] device_release+0x7c/0x7e
 [] kobject_cleanup+0x44/0x5e
 [] kobject_release+0xb/0xd
 [] kref_put+0x63/0x71
 [] kobject_put+0x14/0x16
 [] put_device+0x11/0x13
 [] device_unregister+0x12/0x15
 [] fixed_mdio_register_device+0x210/0x23b
 [] fixed_init+0x2f/0x33
 [] init+0x15d/0x2bd
 [] kernel_thread_helper+0x7/0x10
 ===
Calling initcall 0xc1b6d6c5: sundance_init+0x0/0x16()
Calling initcall 0xc1b6d6db: hamachi_init+0x0/0x16()
-
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.20.3-cks1 ext3 oops

[Maciej Soltysiak]

Hi,

I was doing large FTP transfers to an ext3 partition on a 2.6.20.3-cks1 
machine and it spat on me.

Here it is, hope you guys can read important stuff from it:

BUG: at fs/buffer.c:1639 __block_write_full_page()
[] __block_write_full_page+0x320/0x330
[] ext3_get_block+0x0/0x100
[] block_write_full_page+0xf6/0x100
[] ext3_get_block+0x0/0x100
[] ext3_journalled_writepage+0x14d/0x160
[] generic_writepages+0x1ee/0x320
[] ext3_journalled_writepage+0x0/0x160
[] do_writepages+0x49/0x50
[] __writeback_single_inode+0x8a/0x370
[] __writeback_single_inode+0xbe/0x370
[] schedule_timeout+0x52/0xd0
[] sync_sb_inodes+0x161/0x210
[] writeback_inodes+0x72/0x90
[] background_writeout+0x7c/0xa0
[] pdflush+0x0/0x180
[] pdflush+0xd5/0x180
[] background_writeout+0x0/0xa0
[] kthread+0xa9/0xe0
[] kthread+0x0/0xe0
[] kernel_thread_helper+0x7/0x10
===
c0175556

Modules linked in: binfmt_misc sit nfs lockd nfs_acl sunrpc ipt_ECN
iptable_mangle w83627ehf i2c_isa i2c_viapro i2c_core via_agp agpgart rtc

<0>Assertion failure in journal_start() at fs/jbd/transaction.c:273: 
"handle->h_transaction->t_journal == journal"


Modules linked in: binfmt_misc sit nfs lockd nfs_acl sunrpc ipt_ECN
iptable_mangle w83627ehf i2c_isa i2c_viapro i2c_core via_agp agpgart rtc

<1>Fixing recursive fault but reboot is needed!
swapper: page allocation failure. order:0, mode:0x20
[] __alloc_pages+0x2f9/0x310
[] cache_alloc_refill+0x27d/0x490
[] __kmalloc+0x85/0x90
[] __alloc_skb+0x55/0x110
[] boomerang_rx+0x345/0x450
[] boomerang_interrupt+0x156/0x410
[] handle_IRQ_event+0x25/0x60
[] handle_fasteoi_irq+0x44/0x90


I don't think that the -ck patch i am using skews it in any way, it 
seems to be ext3/swap/memory related.


I am not on the list, if you need anything from me, just use my email or cc.

Best regards,
Maciej Soltysiak

-
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: Interface for the new fallocate() system call

[Heiko Carstens]

On Fri, Mar 30, 2007 at 02:14:17AM -0500, Jakub Jelinek wrote:
> On Thu, Mar 29, 2007 at 10:10:10AM -0700, Andrew Morton wrote:
> > > Platform: s390
> > > --
> > > s390 prefers following layout:
> > > 
> > >int fallocate(int fd, loff_t offset, loff_t len, int mode)
> > > 
> > > For details on why and how "int, int, loff_t, loff_t" is a problem on
> > > s390, please see Heiko's mail on 16th March. Here is the link:
> > > http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg133595.html
> > > 
> > > Platform: ppc, arm
> > > --
> > > ppc (32 bit) has a problem with "int, loff_t, loff_t, int" layout,
> > > since this will result in a pad between fd and offset, making seven
> > > arguments total - which is not supported by ppc32. It supports only
> > > 6 arguments. Thus the desired layout by ppc32 is:
> > > 
> > >int fallocate(int fd, int mode, loff_t offset, loff_t len)
> > > 
> > > Even ARM prefers above kind of layout. For details please see the
> > > definition of sys_arm_sync_file_range().
> > 
> > This is a clean-looking option.  Can s390 be changed to support seven-arg
> > syscalls?
> 
> Wouldn't
> int fallocate(loff_t offset, loff_t len, int fd, int mode)
> work on both s390 and ppc/arm?  glibc will certainly wrap it and
> reorder the arguments as needed, so there is no need to keep fd first.

That would be fine for s390.
-
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: Interface for the new fallocate() system call

[Paul Mackerras]

Heiko Carstens writes:

> If possible I'd prefer the six-32-bit-args approach.

It does mean extra unnecessary work for 64-bit platforms, though...

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/

Re: Interface for the new fallocate() system call

[Paul Mackerras]

Jakub Jelinek writes:

> Wouldn't
> int fallocate(loff_t offset, loff_t len, int fd, int mode)
> work on both s390 and ppc/arm?  glibc will certainly wrap it and
> reorder the arguments as needed, so there is no need to keep fd first.

That looks fine to me.

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/

Re: [uml-devel] [PATCH] UML - fix I/O hang when multiple devices are in use

[Blaisorblade]

On giovedì 29 marzo 2007, Jeff Dike wrote:
> On Thu, Mar 29, 2007 at 02:36:43AM +0200, Blaisorblade wrote:
> > > Sometimes you need to. I'd probably just remove the do_ubd check and
> > > always recall the request function when handling completions, it's
> > > easier and safe.
>
> If I'm understanding this correctly, this is what happens now.  There
> is still the flag check and return if the queue is being run, but I
> don't see the advantage of removing that.
>
> > Anyway, the main speedups to do on the UBD driver are:
> > * implement write barriers (so much less fsync) - this is performance
> > killer n.1
>
> You mean preventing the upper layers from calling fsync?

No. Since we don't know when the upper layers (including the journaling layer) 
wants to fsync, we call it everytime. But they pass this information. Chris 
Lightfoot implemented write barriers just before the API was changed, 
together with much of the other stuff I'm talking about.

It's impressive to check his original mail - the scenario with create a 32M 
file + delete it, where delete takes a minute on vanilla and 1 second on his 
patched code. I've downloaded the patch for future reference, even if I don't 
know when I'll have time to look at it.

> > * possibly to use the new 2.6 request layout with scatter/gather I/O, and
> > vectorized I/O on the host
>
> Yeah, this is something I've thought about on occassion but never
> done.
>
> > * while at vectorizing I/O using async I/O
>
> I have that, but haven't merged it since I see no performance benefit
> for some reason.
>
> > * to avoid passing requests on pipes (n.2) - on fast disk I/O becomes
> > cpu-bound.
>
> Right - I cooked up a scheme a while ago that had the requests on a
> list, being removed from one end and added to the other, with some
> minimal number of bytes going across the pipe to ensure a wakeup if
> the other side was possibly asleep.  But I never implemented it.
>
> > * using futexes instead of pipes for synchronization (required for
> > previous one).
>
> Yup - for this, we either need to test the host for futuxes and use
> pipes as a fallback or give up on 2.4 as the host.
>
> > I forgot one thing: remember ubd=mmap? Something like that could have
> > been done using MAP_PRIVATE, so that write had still to be called
> > explicitly but unchanged data was shared with the host.
> >
> > Once a page gets dirty but is then cleaned, sharing it back is
> > difficult - but even without that good savings could be
> > achievable. That's to explore for the very future though.
>
> Interesting idea.  That does avoid the formerly fatal mmap problem.
> If you unmap it, the private copy goes away because it lost its last
> reference, and if you map it again, you get the shared version.
>
> That's a lot of mapping and unmapping though.  I wonder if just
> calling mmap would cause the COWed page to be dropped...
>
>   Jeff



-- 
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
-
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: Interface for the new fallocate() system call

[Jörn Engel]

On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote:
> Heiko Carstens writes:
> 
> > If possible I'd prefer the six-32-bit-args approach.
> 
> It does mean extra unnecessary work for 64-bit platforms, though...

Wouldn't that work be confined to fallocate()?  If I understand Heiko
correctly, the alternative would slow s390 down for every syscall,
including more performance-critical ones.

Jörn

-- 
tglx1 thinks that joern should get a (TM) for "Thinking Is Hard"
-- Thomas Gleixner
-
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: Interface for the new fallocate() system call

[Heiko Carstens]

On Fri, Mar 30, 2007 at 12:44:49PM +0200, Jörn Engel wrote:
> On Fri, 30 March 2007 19:15:58 +1000, Paul Mackerras wrote:
> > It does mean extra unnecessary work for 64-bit platforms, though...
> 
> Wouldn't that work be confined to fallocate()?  If I understand Heiko
> correctly, the alternative would slow s390 down for every syscall,
> including more performance-critical ones.

That is correct.
-
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/5] RT kernel: force detect HPET from PCI space

[Pallipadi, Venkatesh]

 

>-Original Message-
>From: Ingo Molnar [mailto:[EMAIL PROTECTED] 
>Sent: Friday, March 30, 2007 2:47 AM
>To: Pallipadi, Venkatesh
>Cc: linux-kernel; Thomas Gleixner
>Subject: Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space
>
>On Thu, 2007-02-22 at 17:06 -0800, Venkatesh Pallipadi wrote:
>> Patchset enables force detection of HPET, when it is not listed by
>> BIOS.
>> and enables use of HPET as a event source. HPET timers
>> configures in stamdard interrupt mode can be used as dependable per
>> CPU timer
>> on laptops that are known to have LAPIC stoppage with ACPI C3 state.
>
>(sorry about the belated reply)
>
>cool patchset! I suspect the most logical place to start this would be
>on upstream 32-bit, which has the hpet clockevents changes already.
>Plus the i386 and x86_64 hpet code should be unified.
>

Yes. I restarted the work recently with i386 and upstream. I should
have the some patches in couple of weeks time.

Thanks,
Venki
-
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: broken device locking, sg vs. sg_io on block devices

[Christoph Hellwig]

On Fri, Mar 30, 2007 at 01:17:44PM +0200, Eduard Bloch wrote:
> Hello,
> 
> I am talking this issue to LKML now.
> 
> Short story: using O_EXCL on /dev/srX alone does not help to prevent
> other process from killing your burn process by just reading the
> /dev/sgX device associated with yours, and vice versa. We have done the
> best we could to make safe operation (in contrary to Schilling's
> kill-this-evil-hald-thing bitching) but that is not enough, the locking
> has to be established on kernel layer.
> 
> Long story:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960
> https://bugzilla.novell.com/show_bug.cgi?id=226019
> http://lists.alioth.debian.org/pipermail/debburn-devel/2007-February/000297.html
> and other error messages.
> 
> There is AFAICS no simple way to establish locking across the driver
> borders. If kernel developers have a good idea, any help is appreciated.
> 
> Below are the typical symptoms: wodim operates via /dev/sgX because the
> user chosen it this way, some other process (most likely hald) comes
> along and reads from /dev/sr0 and the drive gets confused. Boom.

You have thre problems here, and none of them are in the kernel :)

First the hardsware is broken when it can't deal with concurrent requests,
I'd try to get a refund for it.  Second wodim should never ever use
/dev/sg if the sr node is available.  And third HAL should stop poking
devices all the time.  Then again hald is a totally lost cause and
I can only recommend to uninstall it ASAP.
-
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] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[Aubrey Li]

On 3/30/07, David Howells <[EMAIL PROTECTED]> wrote:

Aubrey Li <[EMAIL PROTECTED]> wrote:

> malloc() allocates size bytes and returns a pointer to the allocated memory.
> The memory is not cleared.

But this is *not* malloc().  It's mmap().  Are you prepared to guarantee that
there are no applications out there that don't rely on anon mmap() giving
zeroed memory?


I can't find mmap must give zeroed memory in the mmap manual.
Is there any reason relying on anon mmap() giving zerod memory?
Can you show me an example?



The MMU-mode clearing is done for security reasons - there shouldn't be any
leakage between processes, and because the zero page can just be faulted in.


NO-MMU can't do this clearing. Performance is down.


Personally, I'd prefer to maintain compatibility with MMU-mode wherever
possible, but I'm happy with overrides like the MAP_UNINITIALISED flag
suggested.


Not necessary IMHO.

-Aubrey
-
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: Corrupt XFS -Filesystems on new Hardware and Kernel

[Oliver Joa]

Hi,

David Chinner wrote:

[...]


Next time you get a shutdown, can you unmount the filesystems and
run xfs_check and then "xfs_repair -n" on the filesystem. These will
tell you the inode numbers that are bad. Can you post the errors
reported by these tools?



xfs_check gives this:

bad format 0 for inode 8458341 type 010
bad format 0 for inode 8458344 type 010
bad format 0 for inode 8458348 type 010
block 1/4962 type unknown not expected
block 1/4963 type unknown not expected
block 1/4970 type unknown not expected
block 1/4975 type unknown not expected
block 1/4976 type unknown not expected
link count mismatch for inode 8458341 (name ?), nlink 0, counted 1
link count mismatch for inode 8458344 (name ?), nlink 0, counted 1
link count mismatch for inode 8458348 (name ?), nlink 0, counted 1



xfs_repair -n gives this:

Phase 1 - find and verify superblock...
Phase 2 - using internal log
- scan filesystem freespace and inode maps...
- found root inode chunk
Phase 3 - for each AG...
- scan (but don't clear) agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
bad inode format in inode 8458341
bad inode format in inode 8458344
bad inode format in inode 8458348
bad inode format in inode 8458341
would have cleared inode 8458341
bad inode format in inode 8458344
would have cleared inode 8458344
bad inode format in inode 8458348
would have cleared inode 8458348
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
entry "cpufreq.c" at block 0 offset 152 in directory inode 8458336 
references free inode 8458341

would clear inode number in entry at offset 152...
entry "head.S" at block 0 offset 232 in directory inode 8458336 
references free inode 8458344

would clear inode number in entry at offset 232...
entry "irq.c" at block 0 offset 320 in directory inode 8458336 
references free inode 8458348

would clear inode number in entry at offset 320...
bad inode format in inode 8458341
would have cleared inode 8458341
bad inode format in inode 8458344
would have cleared inode 8458344
bad inode format in inode 8458348
would have cleared inode 8458348
- agno = 2
- agno = 3
- agno = 4
- agno = 5
- agno = 6
- agno = 7
- agno = 8
- agno = 9
- agno = 10
- agno = 11
- agno = 12
- agno = 13
- agno = 14
- agno = 15
No modify flag set, skipping phase 5
Phase 6 - check inode connectivity...
- traversing filesystem starting at / ...
entry "cpufreq.c" in directory inode 8458336 points to free inode 
8458341, would junk entry
entry "head.S" in directory inode 8458336 points to free inode 8458344, 
would junk entry
entry "irq.c" in directory inode 8458336 points to free inode 8458348, 
would junk entry

- traversal finished ...
- traversing all unattached subtrees ...
- traversals finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify link counts...
No modify flag set, skipping filesystem flush and exiting.



Once you have the bad inode numbers, can you run the following
on the bad inodes:

# xfs_db -r -c "inode " -c "p" 



xfs_db on inode 8458341 gives:

core.magic = 0x494e
core.mode = 0100644
core.version = 1
core.format = 0 (dev)
core.nlinkv1 = 1
core.uid = 0
core.gid = 0
core.flushiter = 6
core.atime.sec = Tue Jan 30 22:42:51 2007
core.atime.nsec = 0
core.mtime.sec = Wed Jan 10 19:10:37 2007
core.mtime.nsec = 0
core.ctime.sec = Wed Mar 28 18:15:36 2007
core.ctime.nsec = 612718490
core.size = 6209
core.nblocks = 2
core.extsize = 0
core.nextents = 1
core.naextents = 0
core.forkoff = 0
core.aformat = 2 (extents)
core.dmevmask = 0
core.dmstate = 0
core.newrtbm = 0
core.prealloc = 0
core.realtime = 0
core.immutable = 0
core.append = 0
core.sync = 0
core.noatime = 0
core.nodump = 0
core.rtinherit = 0
core.projinherit = 0
core.nosymlinks = 0
core.extsz = 0
core.extszinherit = 0
core.nodefrag = 0
core.gen = 0
next_unlinked = null
u.dev = 0



xfs_db on inode 8458344 gives:

core.magic = 0x494e
core.mode = 0100644
core.version = 1
core.format = 0 (dev)
core.nlinkv1 = 1
core.uid = 0
core.gid = 0
core.flushiter = 6
core.atime.sec = Tue Jan 30 22:42:51 2007
core.atime.nsec = 0
core.mtime.sec = Wed Jan 10 19:10:37 2007
core.mtime.nsec = 0
core.ctime.sec = Wed Mar 28 18:15:36 2007
core.ctime.nsec = 612849562
core.size = 2326
core.nblocks = 1
core.extsize = 0
core.nextents = 

[PATCH] crypto: RSA algorithm patch (kernel version 2.6.21-rc5-git6)

[Tasos Parisinos]

From: Tasos Parisinos <[EMAIL PROTECTED]>

This patch adds module rsa.ko in the kernel (built-in or as a kernel module) 
and offers an API to do fast modular exponentiation, using the Montgomery 
algorithm, thus the exponentiation is not generic but can be used only when

the modulus is odd, such as RSA public/private key pairs. This module is the
computational core (using multiple precision integer arithmetics) and does not
provide any means to do key management, implement padding schemas e.t.c. so the
calling code should implement all those as needed. 


Signed-off-by: Tasos Parisinos <[EMAIL PROTECTED]>

---

This module exports some symbols, through its header file include/crypto/rsa.h 
and does not use the glue code of include/crypto.h. This decision was taken 
because this glue code is not really suitable for asymmetric cryptography in my

opinion. First of all RSA is not a block cipher but a stream cipher. It does not
only have a key but also an exponent that are two different entities. And the 
most
important is that the key size can be of any length. So it is not practical -yet- 
to register the algorithm with the crypto api using a struct such as crypto_alg. 
So another module can include the file include/crypto/rsa.h and call its interface 
functions to create the operands for the modular exponentiation, execute the 
exponentiation and use the results. All these functions and structures are 
well documented kernel-doc style. Also in this way the calling in-kernel code can

implement key management, padding schemas, hashing e.t.c as needed. The main 
purpose
behind the creation of this module was to create the cryptographic 
infrastructure
to develop an in-kernel system of signed modules.

diff -uprN -X linux.orig/Documentation/dontdiff \
linux.orig/crypto/Kconfig linux/crypto/Kconfig
--- linux.orig/crypto/Kconfig 2007-03-26 01:56:23.0 +0300
+++ linux/crypto/Kconfig 2007-03-30 13:27:33.0 +0300
@@ -440,6 +440,31 @@ config CRYPTO_CAMELLIA
  See also:
  

+config CRYPTO_RSA
+   tristate "RSA asymmetric cipher algorithm"
+   help
+ RSA asymmetric cipher algorithm.
+
+ This module uses the montgomery algorithm to compute fast modular
+ exponentiation. All operands of the modular exponentiation can be
+ of any bit length, thus you can use any public and/or private key
+ lengths.
+
+ If it is selected it will add approximately 8K to the kernel size.
+ Select M to build this as a module. The module will be called rsa.
+
+config RSA_AUX_OPERAND_SIZE
+   int "Size of the preallocated auxilliary operands"
+   default "128"
+   depends on CRYPTO_RSA
+   help
+ The rsa module needs some preallocated space to avoid computation-time
+ allocations. The 'rsa_op' is the struct used by the rsa module to hold
+ a multi-precision integer operand. This struct maps such an integer on
+ multiple 32bit limbs. Here you select the size (in 32bit limbs) of the
+ preallocated auxilliary operands. This size should be close to the key
+ sizes that are usually used.
+
config CRYPTO_TEST
tristate "Testing module"
depends on m
diff -uprN -X linux.orig/Documentation/dontdiff \
linux.orig/crypto/Makefile linux/crypto/Makefile
--- linux.orig/crypto/Makefile 2007-03-26 01:56:23.0 +0300
+++ linux/crypto/Makefile 2007-03-30 13:27:33.0 +0300
@@ -46,5 +46,6 @@ obj-$(CONFIG_CRYPTO_ANUBIS) += anubis.o
obj-$(CONFIG_CRYPTO_DEFLATE) += deflate.o
obj-$(CONFIG_CRYPTO_MICHAEL_MIC) += michael_mic.o
obj-$(CONFIG_CRYPTO_CRC32C) += crc32c.o
+obj-$(CONFIG_CRYPTO_RSA) += rsa.o

obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
diff -uprN -X linux.orig/Documentation/dontdiff \
linux.orig/crypto/rsa.c linux/crypto/rsa.c
--- linux.orig/crypto/rsa.c 1970-01-01 02:00:00.0 +0200
+++ linux/crypto/rsa.c 2007-03-30 14:20:07.0 +0300
@@ -0,0 +1,766 @@
+/*
+ * Cryptographic API
+ *
+ * RSA cipher algorithm implementation
+ *
+ * Copyright (c) 2007 Tasos Parisinos <[EMAIL PROTECTED]>
+ * Copyright (c) 2007 Sciensis Advanced Technology Systems
+ *
+ * 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
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#define AUX_OPERAND_COUNT  4
+#define U32_MAX0x
+#define U32_MSB_SET0x8000
+#define LEFTOP aux[0]
+#define RIGHTOPaux[1]
+
+static int rsa_op_resize(rsa_op **n, int size)
+{
+   int retval = 0;
+   rsa_op *handle = *n;
+
+   /* If there is no allocated rsa_op passed in, allocate one */
+   if (!handle)
+   return rsa_op_alloc(n, size);
+
+   /* If the rsa_op passed in

Re: [PATCH] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[Alan Cox]

> I can't find mmap must give zeroed memory in the mmap manual.
> Is there any reason relying on anon mmap() giving zerod memory?

Its how all Unix/Linux like systems behave. You have to clear the memory
to something to deal with security on any kind of real system, and zero
is a good a value as any

> > Personally, I'd prefer to maintain compatibility with MMU-mode wherever
> > possible, but I'm happy with overrides like the MAP_UNINITIALISED flag
> > suggested.
> >
> Not necessary IMHO.

mmap() for anonymous memory pools should not normally be a hot path,
because the C library malloc is supposed to show some brains. If you need
special behaviour (eg for performance hacks) then create yourself
a /dev/zero like device which just maps uncleared pages. Its not much
code and it keeps special cases out of the core kernel.
-
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/

What is the active page in Linux kernel, so inactive?

[Bin Chen]

I am quite confusing about the concept that Linux usage of the term
active and inactive pages. Some book tells me active pages is the
'working set' in system, but what is the 'working set'? There is a
page cache system in the system, and when a page is freed when not
needed by some way, the page will first considered be added to the
page cache. Once some stuff need more pages, it also get it from page
cache.

So it is easy to understand that there is two list in the page cache,
one for 'used' pages, that is, the page actually used by some one. And
the other one is 'unused', that is, unused by any one but is still
cached.

But I doubt whether the 'used' and 'unused' correspond to active and
inactive correctly? If I am right, when the system memory is tight,
the pages in the active list will be swapped out and the pages will be
added to the inactive list? Or the pages that has swapped out go
directly to the buddy allocator?

Thanks in advance.

abai
-
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/

What is the anonymous page

[Bin Chen]

Are the program heap pages anonymous pages?
Are the mmaped pages are not anonymous pages?

Thanks in advance.
abai
-
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] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

[Greg KH]

On Fri, Mar 30, 2007 at 02:04:16PM +0200, Ingo Molnar wrote:
> 
> i just found a new category of driver regressions in 2.6.21, doing 
> allyesconfig bzImage bootup tests: the init methods of various drivers 
> hangs in driver_unregister().
> 
> It is caused by this problem: the semantics of driver_unregister() [also 
> implicitly called in pci_driver_unregister()] has apparently changed 
> recently. If a driver does:
> 
>   pci_register_driver(&my_driver);
>   ...
>   if (some_failure) {
>   pci_unregister_driver(&my_driver);
>   ...
>   }
> 
> it will hang the bootup in the following piece of code:
> 
>  drivers/base/driver.c:
> 
>   void driver_unregister(struct device_driver * drv)
>   {
>  bus_remove_driver(drv);
>  wait_for_completion(&drv->unloaded);
> 
> the completion is never done - because nobody removes the bus while the 
> init is still happening, obviously. (and bootup is serialized anyway)
> 
> now, the majority of drivers does the driver unregistry from its 
> module-cleanup function, so it's not affected by this problem. But if 
> you apply the debug patch attached further below, and do an allyesconfig 
> bzImage bootup, there's 3 hits already:
> 
>  BUG: at drivers/base/driver.c:187 driver_unregister()
>   [] show_trace_log_lvl+0x19/0x2e
>   [] show_trace+0x12/0x14
>   [] dump_stack+0x14/0x16
>   [] driver_unregister+0x3d/0x43
>   [] pci_unregister_driver+0x10/0x5f
>   [] slgt_init+0x9b/0x1ca
>   [] init+0x15d/0x2bd
>   [] kernel_thread_helper+0x7/0x10
> 
>  BUG: at drivers/base/driver.c:187 driver_unregister()
>   [] show_trace_log_lvl+0x19/0x2e
>   [] show_trace+0x12/0x14
>   [] dump_stack+0x14/0x16
>   [] driver_unregister+0x3d/0x43
>   [] pci_unregister_driver+0x10/0x5f
>   [] init_ipmi_si+0x70a/0x738
>   [] init+0x15d/0x2bd
>   [] kernel_thread_helper+0x7/0x10
> 
>  BUG: at drivers/base/driver.c:187 driver_unregister()
>   [] show_trace_log_lvl+0x19/0x2e
>   [] show_trace+0x12/0x14
>   [] dump_stack+0x14/0x16
>   [] driver_unregister+0x3d/0x43
>   [] pci_unregister_driver+0x10/0x5f
>   [] tlan_probe+0x2dd/0x30e
>   [] init+0x15d/0x2bd
>   [] kernel_thread_helper+0x7/0x10
> 
> possibly more could trigger. Each of these 3 places caused an actual 
> bootup hang on my testbox, so these are real regressions and need to be 
> fixed.
> 
> because there are a good number of drivers that do 
> pci_unregister_device() from their init function, and because i cannot 
> see anything obviously wrong in doing an unregister call after a 
> failure, i think it's driver_unregister() that needs to be fixed. Greg, 
> what do you think?

Yes, we should allow the ability to call unregister_driver from within
the module_init function.

But I don't understand what is causing you to see this problem.  Who is
holding the reference on the struct device at this point in time?  Is it
the fact that userspace has some files open and it hasn't released them
yet?

I don't see anything implicit in the driver_unregister() path that
should not work from within the module_init() path.  Kay, am I missing
anything here?

(patch left below for Kay's benefit)

thanks,

greg k-h

> Index: linux/drivers/base/driver.c
> ===
> --- linux.orig/drivers/base/driver.c
> +++ linux/drivers/base/driver.c
> @@ -183,7 +183,8 @@ int driver_register(struct device_driver
>  void driver_unregister(struct device_driver * drv)
>  {
>   bus_remove_driver(drv);
> - wait_for_completion(&drv->unloaded);
> + if (!drv->unloaded.done)
> + WARN_ON(1);
>  }
>  
>  /**
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"

[Greg KH]

On Fri, Mar 30, 2007 at 02:06:57PM +0200, Ingo Molnar wrote:
> 
> there's a new type of message in allyesconfig-bzImage bootup test:
> 
> Calling initcall 0xc1b6d692: fixed_init+0x0/0x33()
> Fixed PHY: Registered new driver
> Device '[EMAIL PROTECTED]:1' does not have a release() function, it is broken 
> and must be fixed.
> BUG: at drivers/base/core.c:120 device_release()
>  [] show_trace_log_lvl+0x19/0x2e
>  [] show_trace+0x12/0x14
>  [] dump_stack+0x14/0x16
>  [] device_release+0x7c/0x7e
>  [] kobject_cleanup+0x44/0x5e
>  [] kobject_release+0xb/0xd
>  [] kref_put+0x63/0x71
>  [] kobject_put+0x14/0x16
>  [] put_device+0x11/0x13
>  [] device_unregister+0x12/0x15
>  [] fixed_mdio_register_device+0x210/0x23b
>  [] fixed_init+0x1e/0x33
>  [] init+0x15d/0x2bd
>  [] kernel_thread_helper+0x7/0x10
>  ===
> Device '[EMAIL PROTECTED]:1' does not have a release() function, it is broken 
> and must be fixed.
> BUG: at drivers/base/core.c:120 device_release()
>  [] show_trace_log_lvl+0x19/0x2e
>  [] show_trace+0x12/0x14
>  [] dump_stack+0x14/0x16
>  [] device_release+0x7c/0x7e
>  [] kobject_cleanup+0x44/0x5e
>  [] kobject_release+0xb/0xd
>  [] kref_put+0x63/0x71
>  [] kobject_put+0x14/0x16
>  [] put_device+0x11/0x13
>  [] device_unregister+0x12/0x15
>  [] fixed_mdio_register_device+0x210/0x23b
>  [] fixed_init+0x2f/0x33
>  [] init+0x15d/0x2bd
>  [] kernel_thread_helper+0x7/0x10

That means that whatever driver has fixed_mdio_register_device() in it
is broken and needs to be fixed.

It is independant from your previous question about unregistering the
device from within module_init().

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: broken device locking, sg vs. sg_io on block devices

[Eduard Bloch]

#include 
* Christoph Hellwig [Fri, Mar 30 2007, 02:43:27PM]:

> > Long story:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413960
> > https://bugzilla.novell.com/show_bug.cgi?id=226019
> > http://lists.alioth.debian.org/pipermail/debburn-devel/2007-February/000297.html
> > and other error messages.
> > 
> > There is AFAICS no simple way to establish locking across the driver
> > borders. If kernel developers have a good idea, any help is appreciated.
> > 
> > Below are the typical symptoms: wodim operates via /dev/sgX because the
> > user chosen it this way, some other process (most likely hald) comes
> > along and reads from /dev/sr0 and the drive gets confused. Boom.
> 
> You have thre problems here, and none of them are in the kernel :)
> 
> First the hardsware is broken when it can't deal with concurrent requests,
> I'd try to get a refund for it.  Second wodim should never ever use
> /dev/sg if the sr node is available.  And third HAL should stop poking
> devices all the time.  Then again hald is a totally lost cause and
> I can only recommend to uninstall it ASAP.

Then make /dev/sg* unusable when something opens /dev/sr. Please.
Otherwise it is just another assumption of how things might or should
work, not really matching the use cases in the wild. And here are
some real world facts:

 - there is a fixed mapping between the fake-SCSI numbers and devices
   established by Schilling. People are using it, it is hardcoded into
   frontend applications. We cannot change that overnight without
   breaking even more stuff.
   
   If there is a simple way to get the mapping between the sg and sr
   devices that would be great and almost solve the problems, but I
   cannot discover a such thing in the kernel.

 - hald is using O_EXCL already, as wodim does, and this seems to work
   well as long as they are acting on the same virtual devices.

 - hald is installed together with KDE. Do you suggest to remove KDE as
   well? I don't think so.

 - of course the hardware does not handle concurent requests, it is
   designed that way. It is burden of kernel to canalize the access and
   deal with concurrency issues. Obviously the kernel can and shall not
   do all the work but at least the basic safety mechanisms must work
   reliably and currently they don't.

Eduard.
-- 
 Halloechen, ihr Spinner, so frueh auf?
 nein, wir schlafen alle im kollektiv
 mein alkoven ist kaputt
 alkohol kaputt?
-
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] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"

[Ingo Molnar]

* Greg KH <[EMAIL PROTECTED]> wrote:

> > Device '[EMAIL PROTECTED]:1' does not have a release() function, it is 
> > broken and must be fixed.
> > BUG: at drivers/base/core.c:120 device_release()
> >  [] show_trace_log_lvl+0x19/0x2e
> >  [] show_trace+0x12/0x14
> >  [] dump_stack+0x14/0x16
> >  [] device_release+0x7c/0x7e
> >  [] kobject_cleanup+0x44/0x5e
> >  [] kobject_release+0xb/0xd
> >  [] kref_put+0x63/0x71
> >  [] kobject_put+0x14/0x16
> >  [] put_device+0x11/0x13
> >  [] device_unregister+0x12/0x15
> >  [] fixed_mdio_register_device+0x210/0x23b
> >  [] fixed_init+0x2f/0x33
> >  [] init+0x15d/0x2bd
> >  [] kernel_thread_helper+0x7/0x10
> 
> That means that whatever driver has fixed_mdio_register_device() in it 
> is broken and needs to be fixed.

that would be drivers/net/phy/fixed.c.

> It is independant from your previous question about unregistering the 
> device from within module_init().

(yes - hence the different subject line, etc.)

Ingo
-
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] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[Aubrey Li]

On 3/30/07, Alan Cox <[EMAIL PROTECTED]> wrote:

> I can't find mmap must give zeroed memory in the mmap manual.
> Is there any reason relying on anon mmap() giving zerod memory?

Its how all Unix/Linux like systems behave.

Fair enough.



You have to clear the memory
to something to deal with security on any kind of real system, and zero
is a good a value as any

> > Personally, I'd prefer to maintain compatibility with MMU-mode wherever
> > possible, but I'm happy with overrides like the MAP_UNINITIALISED flag
> > suggested.
> >
> Not necessary IMHO.

mmap() for anonymous memory pools should not normally be a hot path,
because the C library malloc is supposed to show some brains. If you need
special behaviour (eg for performance hacks) then create yourself
a /dev/zero like device which just maps uncleared pages. Its not much
code and it keeps special cases out of the core kernel.


On MMU-mode, /dev/zero's-->mmap gives zerod memory.
On NO-MMU-mode, we have to do memset(,,,) to give zerod memory. So the
different malloc size has the different time cost.
So Bryan's test case shows the terrible performance result.
---
Summary is, when I run the app "time test",

on x86:
real0m0.066s
user0m0.008s
sys 0m0.058s

on Blackfin:
real3m 37.69s
user0m 0.04s
sys 3m 37.58s
---
So now the question is,
Keep the same behave as MMU but with bad performance, or keep the same
performance as MMU but without the same behave, Which one is more
important?

-Aubrey
-
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: Use C++ in kernel module?

[Alistair John Strachan]

On Friday 30 March 2007 07:59, Bongani Hlope wrote:
> On Friday 30 March 2007 05:49:14 Jan Engelhardt wrote:
> > On Mar 30 2007 11:37, Conke Hu wrote:
> > > Is it possible to use C++ in linux kernel module? how?
> > > I've tested but failed, there is an unknown symbol in the .o file from
> > > c++ source code.
> >
> > You answered it yourself. Linux does not have a C++ runtime.
> > It is possible to use a very limited set of C++ features, usually not
> > worth the fight.
> >
> >
> > Jan
>
> Do the "C++ kernel modules" crowd actually know C++? If they knew how C++
> was designed, they would know that it requires some runtime support, which
> will stop them from asking this question over and over again. I'm begining
> to think that most of these questions are asked by people who think OO
> programing should used in the kernel (which is already done anyway)

Not to mention this, attached to every single LKML email:

> 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/

http://www.tux.org/lkml/#s15-3

"Why don't we rewrite the Linux kernel in C++?"

"Why not add a C++ interface layer to the kernel to support C++ drivers?"

"Can we make the kernel headers C++-friendly?"

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
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 dependency generation

[Sam Ravnborg]

On Thu, Mar 29, 2007 at 10:27:14AM +0100, Jan Beulich wrote:
> Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way
> the split config tree is built, but failed to also adjust fixdep
> accordingly - if changing a config option from or to m, files
> referencing the respective CONFIG_..._MODULE (but not the
> corresponding CONFIG_...) didn't get rebuilt.
Do you have a test case for this?
I want to play a little with this before I submit it.

> 
> Once at it, also eliminate false dependencies due to use of
> ...CONFIG_... identifiers.
But that will break UM - no??
See following note from fixdep:
 * Note 2: if somebody writes HELLO_CONFIG_BOOM in a file, it will depend onto
 * CONFIG_BOOM. This could seem a bug (not too hard to fix), but please do not
 * fix it! Some UserModeLinux files (look at arch/um/) call CONFIG_BOOM as
 * UML_CONFIG_BOOM, to avoid conflicts with /usr/include/linux/autoconf.h,
 * through arch/um/include/uml-config.h; this fixdep "bug" makes sure that
 * those files will have correct dependencies.

Sam

> 
> Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
> 
> --- linux-2.6.21-rc5/scripts/basic/fixdep.c   2007-02-04 19:44:54.0 
> +0100
> +++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c  2007-03-29 
> 11:11:10.0 +0200
> @@ -29,8 +29,7 @@
>   * option which is mentioned in any of the listed prequisites.
>   *
>   * To be exact, split-include populates a tree in include/config/,
> - * e.g. include/config/his/driver.h, which contains the #define/#undef
> - * for the CONFIG_HIS_DRIVER option.
> + * e.g. include/config/his/driver.h, consiting of empty files.
>   *
>   * So if the user changes his CONFIG_HIS_DRIVER option, only the objects
>   * which depend on "include/linux/config/his/driver.h" will be rebuilt,
> @@ -223,7 +222,7 @@ void use_config(char *m, int slen)
>  void parse_config_file(char *map, size_t len)
>  {
>   int *end = (int *) (map + len);
> - /* start at +1, so that p can never be < map */
> + /* start at +1, so that p can never be <= map */
>   int *m   = (int *) map + 1;
>   char *p, *q;
>  
> @@ -235,6 +234,8 @@ void parse_config_file(char *map, size_t
>   continue;
>   conf:
>   if (p > map + len - 7)
> + break;
> + if (isalnum(p[-1]) || p[-1] == '_')
>   continue;
>   if (memcmp(p, "CONFIG_", 7))
>   continue;
> @@ -245,6 +246,8 @@ void parse_config_file(char *map, size_t
>   continue;
>  
>   found:
> + if (!memcmp(q - 7, "_MODULE", 7))
> + q -= 7;
>   use_config(p+7, q-p-7);
>   }
>  }
> 
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [test] hackbench.c interactivity results: vanilla versus SD/RSDL

[Xenofon Antidides]

- Original Message 
From: Ingo Molnar <[EMAIL PROTECTED]>
To: Con Kolivas <[EMAIL PROTECTED]>
Cc: linux list ; Andrew Morton <[EMAIL 
PROTECTED]>; Mike Galbraith <[EMAIL PROTECTED]>
Sent: Thursday, March 29, 2007 9:22:49 PM
Subject: [test] hackbench.c interactivity results: vanilla versus SD/RSDL


* Ingo Molnar <[EMAIL PROTECTED]> wrote:

> * Con Kolivas <[EMAIL PROTECTED]> wrote:
> 
> > I'm cautiously optimistic that we're at the thin edge of the bugfix 
> > wedge now.
[...]

> and the numbers he posted:
> 
>  http://marc.info/?l=linux-kernel&m=117448900626028&w=2

We been staring at these numbers for while now and we come to the conclusion 
they wrong.

The test is f is 3 tasks, two on different and one on same cpu as sh here:
virgin 2.6.21-rc3-rsdl-smp
top - 13:52:50 up 7 min, 12 users,  load average: 3.45, 2.89, 1.51

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  P COMMAND
 6560 root  31   0  2892 1236 1032 R   82  0.1   1:50.24 1 sh
 6558 root  28   0  1428  276  228 S   42  0.0   1:00.09 1 f
 6557 root  30   0  1424  280  228 R   35  0.0   1:00.25 0 f
 6559 root  39   0  1424  276  228 R   33  0.0   0:58.36 0 f

6560 sh is asking for 100% cpu on cpu number 1
6558 f is asking for 50% cpu on cpu number 1
6557 f is asking for 50% cpu on cpu number 0
6559 f is asking for 50% cpu on cpu number 0

So if 6560 and 6558 are asking for cpu from cpu number 1:
6560 wants 100% and 6558 wants 50%.
6560 should get 2/3 cpu 6558 should get 1/3 cpu

2.6.21-rc3-rsdl-smp gives 65% sh and 35% f

patched 2.6.21-rc3-rsdl-smp gives 60% sh and 40% f

2.6.20.3-smp gives 51% sh and 49% f

We think cpu correctness is 2.6.21-rc3-rsdl-smp
 in that test.

Xant





 

Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food & Drink Q&A.
http://answers.yahoo.com/dir/?link=list&sid=396545367
-
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] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[David Howells]

Aubrey Li <[EMAIL PROTECTED]> wrote:

> Summary is, when I run the app "time test",
> 
> on x86:
> real0m0.066s
> user0m0.008s
> sys 0m0.058s
> 
> on Blackfin:
> real3m 37.69s
> user0m 0.04s
> sys 3m 37.58s

That's not a good comparison: you're comparing two different machines of two
different archs.

> Keep the same behave as MMU but with bad performance, or keep the same
> performance as MMU but without the same behave, Which one is more
> important?

The thing to do is to pass a flag to mmap() to suppress the memset (as
suggested).  This can then be used by the uClibc malloc() implementation and
does not impact any application that does an anon mmap() expecting the memory
returned to be zeroed.

David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fix dependency generation

[Randy Dunlap]

Jan Beulich wrote:

Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 18:38 >>>

On Thu, 29 Mar 2007 17:06:24 +0100 Jan Beulich wrote:


Randy Dunlap <[EMAIL PROTECTED]> 29.03.07 17:39 >>>

--- linux-2.6.21-rc5/scripts/basic/fixdep.c 2007-02-04 19:44:54.0 
+0100
+++ 2.6.21-rc5-fixdep-mod/scripts/basic/fixdep.c2007-03-29 
11:11:10.0 +0200
@@ -29,8 +29,7 @@
  * option which is mentioned in any of the listed prequisites.
  *
  * To be exact, split-include populates a tree in include/config/,
- * e.g. include/config/his/driver.h, which contains the #define/#undef
- * for the CONFIG_HIS_DRIVER option.

I don't see why you deleted the line above.

Because it is no longer true. These files are empty as of 2.6.18.

We seem to be talking about different lines above.  Yes, the files
are empty, but they are named based on the CONFIG_symbol name, which
is what I was trying to get at.  So how about a comment like this:

* To be exact, split-include populates a tree in include/config/,
* e.g., include/config/sysctl/syscall.h,
* for the CONFIG_SYSCTL_SYSCALL option, when that option
* is enabled (=y or =m).


Shouldn't that then be '..., when that option is or ever was enabled
(=y or =m) since last cleaning the tree'?


Uh, I have no idea, but I guess that's OK with me.

--
~Randy
-
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: Student Project Ideas

[Pavel Machek]

Hi!

>  I've been hacking on the Linux kernel all semester for 
>  my OS:
> Internals class. We are given full autonomy in picking 
> our final
> programming project and I would love for mine to be 
> /useful/ for the
> Linux kernel and not just a theoretical exorcise. If 
> anybody has any
> bug fixes or features maybe they never got around to, 
> and would be
> suitable for this situation, I would love to hear about 
> them.

netnice would be nice. As in netnice -n 19 wget interesting_video.

Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

exposing FSB clock speed in /sys

[Stephane Eranian]

Hello,

It seems that the kernel does not expose the Front-Side Bus (FSN) Clock
speed to user applications. I found code in the kernel dealing with
frequency scaling that extracts the information for x86 processors but
the value is never exposed.

Knowledge the the FSB speed is very useful to monitoring tools. It is used
to compute certain bus-related metrics.

Looking at the code, it seems that there is no standard way of extracting
the FSB speed. For each processor model, you have different MSRs. I would
think that the routines in the cpufreq code could be moved out and used
as the basis to expose the information somewhere in /sys.

Any comments?

-- 
-Stephane
-
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 dependency generation

[Jan Beulich]

>>> Sam Ravnborg <[EMAIL PROTECTED]> 30.03.07 17:08 >>>
>On Thu, Mar 29, 2007 at 10:27:14AM +0100, Jan Beulich wrote:
>> Commit 2e3646e51b2d6415549b310655df63e7e0d7a080 changed the way
>> the split config tree is built, but failed to also adjust fixdep
>> accordingly - if changing a config option from or to m, files
>> referencing the respective CONFIG_..._MODULE (but not the
>> corresponding CONFIG_...) didn't get rebuilt.
>Do you have a test case for this?
>I want to play a little with this before I submit it.

On i386, set CONFIG_APM=y, build, then change it to m.

>> 
>> Once at it, also eliminate false dependencies due to use of
>> ...CONFIG_... identifiers.
>But that will break UM - no??
>See following note from fixdep:
> * Note 2: if somebody writes HELLO_CONFIG_BOOM in a file, it will depend onto
> * CONFIG_BOOM. This could seem a bug (not too hard to fix), but please do not
> * fix it! Some UserModeLinux files (look at arch/um/) call CONFIG_BOOM as
> * UML_CONFIG_BOOM, to avoid conflicts with /usr/include/linux/autoconf.h,
> * through arch/um/include/uml-config.h; this fixdep "bug" makes sure that
> * those files will have correct dependencies.

Hmm, didn't see this note. Then this might warrant special casing UML, but
penalizing all code due to this seems at least odd to me.

Jan
-
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] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[Aubrey Li]

On 3/30/07, David Howells <[EMAIL PROTECTED]> wrote:

Aubrey Li <[EMAIL PROTECTED]> wrote:

> Keep the same behave as MMU but with bad performance, or keep the same
> performance as MMU but without the same behave, Which one is more
> important?

The thing to do is to pass a flag to mmap() to suppress the memset (as
suggested).  This can then be used by the uClibc malloc() implementation and
does not impact any application that does an anon mmap() expecting the memory
returned to be zeroed.



As Mike mentioned, it implies breakage in POSIX behavior
and is specific to no-mmu only.

What kind of application does an anonymous mmap() expecting the memory
returned to be zeroed?

-Aubrey
-
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: exposing FSB clock speed in /sys

[Arjan van de Ven]

On Fri, 2007-03-30 at 07:39 -0800, Stephane Eranian wrote:
> Hello,
> 
> It seems that the kernel does not expose the Front-Side Bus (FSN) Clock
> speed to user applications

and that is a good thing ;)



> Knowledge the the FSB speed is very useful to monitoring tools. It is used
> to compute certain bus-related metrics.

perhaps. 
> 
> Looking at the code, it seems that there is no standard way of extracting
> the FSB speed. For each processor model, you have different MSRs. I would
> think that the routines in the cpufreq code could be moved out and used
> as the basis to expose the information somewhere in /sys.

... yet not all CPU's *have* an FSB. Notably AMD ones do not, and I'm
sure you've read on a lot of online tech magazines that other vendors
may also not have one in the future  :-)

Exposing a concept that we KNOW does not make sense via a kernel
interface (which means we need to keep it around forever) is in my
opinion quite a bad mistake to make Please lets not do this.



-
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/

[RFD driver-core] Lifetime problems of the current driver model

[Tejun Heo]

Hello, all.

This document tries to describe lifetime problems of the current
device driver model primarily from the point view of device drivers
and establish consensus, or at least, start discussion about how to
solve these problems.  This is primarily based on my experience with
IDE and SCSI layers and my knowledge on other drivers is limited, so I
might have generalized too aggressively.  Feel free to point out.


Table of Contents

1. Why is it this complex?
1-1. Rule #a and #b
1-2. Rule #b and #c
2. How do we solve this?
2-1. Rule #a and #b
2-2. Rule #b and #c
3. How do we get there from here?
4. Some afterthoughts


1. Why is it this complex?

Object lifetime management in device drivers is complex and thus
error-prone under the current driver model.  The primary reason is
that device drivers have to match impedances of three different life
time rules.

Rule a. The device itself.  Many devices are hot pluggable these days.
   Devices come when they come and go when they go.

Rule b. Driver model object lifetime rule.  Fundamental data
   structures used by device drivers are reference counted and
   their lifetime can be arbitrarily extended by userspace sysfs
   access.

Rule c. Module life time rule.  Most device drivers can be compiled as
   modules and thus module busy count should be managed properly.


1-1. Rule #a and #b

Being what it is, the primary concern of a device driver is the
'device' itself.  A device driver should create and release objects
representing the devices it manages as they come and go.  In one way
or another, this just has to be done, so this rule is pretty obvious
and intuitive to device driver writers.

The current device driver model mandates implementation of rule #b in
device drivers.  This makes the object lifetime management complicated
and, more importantly, less intuitive to driver writers.  As
implementing such lifetime management in each device driver is too
painful, most device driver midlayers handle this.  e.g. SCSI midlayer
handles driver model lifetime rules and presents simplified
register/unregister-immediately interface to all low level SCSI
drivers.  IDE tries to do similar and USB and netdev have their own
mechanisms too.

I'm not familiar with other layers, but it took quite a while to get
this right in the SCSI midlayer.  The current code works and low level
drivers can do away with most of lifetime management but the added
complexity is saddening to look at.


1-2. Rule #b and #c

On the surface, it seems that we're doing this mostly correctly but
subtle bugs caused by interaction between driver model lifetime and
module lifetime rules aren't difficult to find.

This happens because the two lifetime rules are closely related but
the relation is not properly represented in device driver model
itself.  A module cannot be unloaded unless all device driver objects
it hosts are released, but the only way to guarantee that is to always
grab module reference whenever grabbing relevant kobject reference.
This is ugly to code and too easy to get wrong.  Here are two such
examples.

Example 1. sysfs_schedule_callback() not grabbing the owning module

 This function is recently added to be used by suicidal sysfs nodes
 such that they don't deadlock when trying to unregister themselves.

+#include 
 static void sysfs_schedule_callback_work(struct work_struct *work)
 {
struct sysfs_schedule_callback_struct *ss = container_of(work,
struct sysfs_schedule_callback_struct, work);

+   msleep(100);
(ss->func)(ss->data);
kobject_put(ss->kobj);
kfree(ss);
 }

 int sysfs_schedule_callback(struct kobject *kobj, void (*func)(void *),
void *data)
 {
struct sysfs_schedule_callback_struct *ss;

ss = kmalloc(sizeof(*ss), GFP_KERNEL);
if (!ss)
return -ENOMEM;
kobject_get(kobj);
ss->kobj = kobj;
ss->func = func;
ss->data = data;
INIT_WORK(&ss->work, sysfs_schedule_callback_work);
schedule_work(&ss->work);
return 0;
 }

 Two lines starting with '+' are inserted to make the problem
 reliably reproducible.  With the above changes,

 # insmod drivers/scsi/scsi_mod.ko; insmod drivers/scsi/sd_mod.ko; insmod 
drivers/ata/libata.ko; insmod drivers/ata/ahci.ko
 # echo 1 > /sys/block/sda/device/delete; rmmod ahci; rmmod libata; rmmod 
sd_mod; rmmod scsi_mod

 It's assumed that ahci detects /dev/sda.  The above command sequence
 causes the following oops.

 BUG: unable to handle kernel paging request at virtual address e0984020
 [--snip--]
 EIP is at 0xe0984020
 [--snip--]
  [] run_workqueue+0x92/0x140
  [] worker_thread+0x137/0x160
  [] kthread+0xa3/0xd0
  [] kernel_thread_helper+0x7/0x10

 The problem here is that kobjec_get() in sysfs_schedule_callback()
 doesn't grab the module backing the kobject it's grabbing.  By the
 time (ss->func)(ss->kobj) runs, scsi_mod is already gone.

Example 2. sys

Re: [RFD driver-core] Lifetime problems of the current driver model

[James Bottomley]

On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
> Orphaning sysfs nodes on unregistration is a big step in this
> direction.  With sysfs reference counting out of the picture,
> implementing 'disconnect immediate' interface only on a few components
> (including request_queue) should suffice for most block device
> drivers.  I'm not familiar with other drivers but I don't think
> they'll be very different.

I agree with this statement.  The big question in my mind is how do we
do it?

The essential problem, and the reason why the lifetime rules are
entangled is that fundamentally, sysfs entries are managed by kobjects.
The things the device drivers are interested in is struct device, which
is usually embedded in driver data structures.  Unfortunately, the
required kobject is usually embedded in struct device meaning that the
relevant driver structure cannot be freed while the sysfs entry still
exists.

It seems to me that the only way to Orphan the sysfs entries is to
separate the kobject and the struct device so their lifetime rules are
no longer entangled.  Then we can free the driver structure with the
embedded struct device while still keeping the necessary kobject around
to perform orphaned sysfs operations.

So it seems to me that what we need to do is to give struct device its
own kref and a pointer to a kobject.  Then we can manage the separate
lifetimes independently.  The device would basically allocate and take a
reference to the kobject on device_add() and relinquish it again (and
null out the kobject pointer) on device_del().  The complexity here is
that we now have to allocate the kobject somewhere else ... probably in
device_add() (it doesn't come for free with the device structures).

James


-
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: [RFD driver-core] Lifetime problems of the current driver model

[Dmitry Torokhov]

Hi James,

On 3/30/07, James Bottomley <[EMAIL PROTECTED]> wrote:

On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
> Orphaning sysfs nodes on unregistration is a big step in this
> direction.  With sysfs reference counting out of the picture,
> implementing 'disconnect immediate' interface only on a few components
> (including request_queue) should suffice for most block device
> drivers.  I'm not familiar with other drivers but I don't think
> they'll be very different.

I agree with this statement.  The big question in my mind is how do we
do it?

The essential problem, and the reason why the lifetime rules are
entangled is that fundamentally, sysfs entries are managed by kobjects.
The things the device drivers are interested in is struct device, which
is usually embedded in driver data structures.  Unfortunately, the
required kobject is usually embedded in struct device meaning that the
relevant driver structure cannot be freed while the sysfs entry still
exists.

It seems to me that the only way to Orphan the sysfs entries is to
separate the kobject and the struct device so their lifetime rules are
no longer entangled.  Then we can free the driver structure with the
embedded struct device while still keeping the necessary kobject around
to perform orphaned sysfs operations.

So it seems to me that what we need to do is to give struct device its
own kref and a pointer to a kobject.  Then we can manage the separate
lifetimes independently.  The device would basically allocate and take a
reference to the kobject on device_add() and relinquish it again (and
null out the kobject pointer) on device_del().  The complexity here is
that we now have to allocate the kobject somewhere else ... probably in
device_add() (it doesn't come for free with the device structures).



If you want to manage lifetime rules independently you might want to
not embed struct device into you subsystems objects but attach them
via pointers and use device_create(). Now that we orphan sysfs access
upon unregistering device this will severe all ties from driver core
to your system once you start teardown of a device and you should be
in clear.

However there are simpler subsystems (input, serio, etc.) where there
is only one core module which provides services to device drivers and
handles registration and deregistration. For such substustems it makes
sense to embed struct devices and manage lifetime for all components
at once.

--
Dmitry
-
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: [RFD driver-core] Lifetime problems of the current driver model

[Cornelia Huck]

On Fri, 30 Mar 2007 18:43:02 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:

> One way to solve this problem is to subordinate lifetime rule #b to
> rule #c.  Each kobject points to its owning module such that grabbing
> a kobject automatically grabs the module.  The problem with this
> approach is that it requires wide update and makes kobject_get
> heavier.

Shouldn't getting/putting the module refcount be solely done in
kobject.c? Grab the module reference when the kobject is created and
release the module reference in kobject_cleanup() after the release
function has been called. This doesn't make kobject_get() heavier, and
it ensures we don't delete the module until after the last kobject it is
supposed to clean up has been released.
-
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: [RFD driver-core] Lifetime problems of the current driver model

[Tejun Heo]

Cornelia Huck wrote:
> On Fri, 30 Mar 2007 18:43:02 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
>> One way to solve this problem is to subordinate lifetime rule #b to
>> rule #c.  Each kobject points to its owning module such that grabbing
>> a kobject automatically grabs the module.  The problem with this
>> approach is that it requires wide update and makes kobject_get
>> heavier.
> 
> Shouldn't getting/putting the module refcount be solely done in
> kobject.c? Grab the module reference when the kobject is created and
> release the module reference in kobject_cleanup() after the release
> function has been called. This doesn't make kobject_get() heavier, and
> it ensures we don't delete the module until after the last kobject it is
> supposed to clean up has been released.

If we do that, we wouldn't be able to unload a module if there is any
kobject referencing it even when the node has no openers, so no easy way
out there.  :-(

-- 
tejun
-
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: [RFD driver-core] Lifetime problems of the current driver model

[Tejun Heo]

James Bottomley wrote:
> On Fri, 2007-03-30 at 18:43 +0900, Tejun Heo wrote:
>> Orphaning sysfs nodes on unregistration is a big step in this
>> direction.  With sysfs reference counting out of the picture,
>> implementing 'disconnect immediate' interface only on a few components
>> (including request_queue) should suffice for most block device
>> drivers.  I'm not familiar with other drivers but I don't think
>> they'll be very different.
> 
> I agree with this statement.  The big question in my mind is how do we
> do it?
> 
> The essential problem, and the reason why the lifetime rules are
> entangled is that fundamentally, sysfs entries are managed by kobjects.
> The things the device drivers are interested in is struct device, which
> is usually embedded in driver data structures.  Unfortunately, the
> required kobject is usually embedded in struct device meaning that the
> relevant driver structure cannot be freed while the sysfs entry still
> exists.
> 
> It seems to me that the only way to Orphan the sysfs entries is to
> separate the kobject and the struct device so their lifetime rules are
> no longer entangled.  Then we can free the driver structure with the
> embedded struct device while still keeping the necessary kobject around
> to perform orphaned sysfs operations.
> 
> So it seems to me that what we need to do is to give struct device its
> own kref and a pointer to a kobject.  Then we can manage the separate
> lifetimes independently.  The device would basically allocate and take a
> reference to the kobject on device_add() and relinquish it again (and
> null out the kobject pointer) on device_del().  The complexity here is
> that we now have to allocate the kobject somewhere else ... probably in
> device_add() (it doesn't come for free with the device structures).

My plan was to make sysfs more independent from struct device/kobject.
e.g. Something like the following.

* kobject_get() on attr/symlink creation
* open() doesn't need extra kobject reference
* deleting a node makes it release the kobject reference and the kobject
pointer is nullified.

This way the sysfs reference counting can be put completely out of
picture without impacting the rest of code.  Handling symlink and
suicidal attributes might need some extra attention but I think they can
be done.

In the long term, I think sysfs should be independent from driver model
and kobject such that an entity which wants to use sysfs but is not a
device doesn't have to dance with kobject just to use sysfs.

Thanks.

-- 
tejun
-
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: [RFD driver-core] Lifetime problems of the current driver model

[Cornelia Huck]

On Fri, 30 Mar 2007 22:19:52 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:

> > Shouldn't getting/putting the module refcount be solely done in
> > kobject.c? Grab the module reference when the kobject is created and
> > release the module reference in kobject_cleanup() after the release
> > function has been called. This doesn't make kobject_get() heavier, and
> > it ensures we don't delete the module until after the last kobject it is
> > supposed to clean up has been released.
> 
> If we do that, we wouldn't be able to unload a module if there is any
> kobject referencing it even when the node has no openers, so no easy way
> out there.  :-(

But we must not unload the module when there is still a kobject around
referencing a release function in the module, or we will oops if the
kobject is finally released. If needed, the module must clean up its
kobjects in its exit function.
-
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: [RFD driver-core] Lifetime problems of the current driver model

[Tejun Heo]

Cornelia Huck wrote:
> On Fri, 30 Mar 2007 22:19:52 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
>>> Shouldn't getting/putting the module refcount be solely done in
>>> kobject.c? Grab the module reference when the kobject is created and
>>> release the module reference in kobject_cleanup() after the release
>>> function has been called. This doesn't make kobject_get() heavier, and
>>> it ensures we don't delete the module until after the last kobject it is
>>> supposed to clean up has been released.
>> If we do that, we wouldn't be able to unload a module if there is any
>> kobject referencing it even when the node has no openers, so no easy way
>> out there.  :-(
> 
> But we must not unload the module when there is still a kobject around
> referencing a release function in the module, or we will oops if the
> kobject is finally released. If needed, the module must clean up its
> kobjects in its exit function.

It's a little bit more convoluted than that.  Module reference count of
zero doesn't indicate that there is no one referencing the module.  It
just means that the module can be unloaded.  ie. There still can be any
number of kobjects with release function backed by the module but as
long as all of them can be deleted and released by module exit function,
the module is unloadable at that point.

IOW, module reference count does not count number of objects depending
on the module.  It counts the number of active usages of those objects.

-- 
tejun
-
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: [RFD driver-core] Lifetime problems of the current driver model

[Cornelia Huck]

On Fri, 30 Mar 2007 22:58:39 +0900,
Tejun Heo <[EMAIL PROTECTED]> wrote:

> It's a little bit more convoluted than that.  Module reference count of
> zero doesn't indicate that there is no one referencing the module.  It
> just means that the module can be unloaded.  ie. There still can be any
> number of kobjects with release function backed by the module but as
> long as all of them can be deleted and released by module exit function,
> the module is unloadable at that point.
> 
> IOW, module reference count does not count number of objects depending
> on the module.  It counts the number of active usages of those objects.

We must make sure that the module is never deleted while there may be
calls to ->release functions - the exit function can only return when
all ->release calls have returned. This can be guaranteed if we (1)
don't allow the module to unload if there are outstanding kobjects (we
may need a "self destruct" knob then) or (2) make sure the ->release
functions are outside of the module (see, for example,
drivers/s390/s390_rdev.c).

(Gah, that stuff is always giving me headaches. Sorry if I'm not making
sense...)
-
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: [RFD driver-core] Lifetime problems of the current driver model

[Tejun Heo]

Cornelia Huck wrote:
> On Fri, 30 Mar 2007 22:58:39 +0900,
> Tejun Heo <[EMAIL PROTECTED]> wrote:
> 
>> It's a little bit more convoluted than that.  Module reference count of
>> zero doesn't indicate that there is no one referencing the module.  It
>> just means that the module can be unloaded.  ie. There still can be any
>> number of kobjects with release function backed by the module but as
>> long as all of them can be deleted and released by module exit function,
>> the module is unloadable at that point.
>>
>> IOW, module reference count does not count number of objects depending
>> on the module.  It counts the number of active usages of those objects.
> 
> We must make sure that the module is never deleted while there may be
> calls to ->release functions - the exit function can only return when
> all ->release calls have returned. This can be guaranteed if we (1)
> don't allow the module to unload if there are outstanding kobjects (we
> may need a "self destruct" knob then) or (2) make sure the ->release
> functions are outside of the module (see, for example,
> drivers/s390/s390_rdev.c).

(3) make sure all existing kobjects are released by module exit function.

For example, let's say there is a hypothetical disk device /dev/dk0
driven by a hypothetical driver mydrv.  /dev/dk0 is represented like the
following in the sysfs tree.

/sys/devices/pci:00/:00:1f.0/dk0/{myknob0,myknob1}

Owner of both attrs myknob0 and myknob1 is mydrv and opening either
increases the reference counts of dk0 and mydrv and closing does the
opposite.

* When there is no opener of either knob and the /dev/dk0 isn't used by
anyone.  Reference count of dk0 is 1, mydrv 0.

* User issues rmmod mydrv.  As mydrv's reference count is zero, unload
proceeds and mydrv's exit function is called.

* mydrv's exit function looks like the following.

  mydrv_exit()
  {
sysfs_remove_file(dk0, myknob0);
sysfs_remove_file(dk1, myknob1);
device_del(dk0);
deinit controller;
release all resources;
  }

The device_del(dk0) drops dk0's reference count to zero and its
->release is invoked immediately.

This method is widely used to allow modules to be unloaded even when
there still are valid objects if there's no active user.

> (Gah, that stuff is always giving me headaches. Sorry if I'm not making
> sense...)

Yeap, this is confusing.  Hope my explanation makes sense.

-- 
tejun
-
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: [KJ][PATCH] BIT macro cleanup

[Milind Arun Choudhary]

On 3/29/07, Richard Knutsson <[EMAIL PROTECTED]> wrote:

Alexey Dobriyan wrote:
> On Wed, Mar 28, 2007 at 09:03:09AM +0530, Milind Arun Choudhary wrote:
>
>> +#define BIT(nr)   (1UL << ((nr) % BITS_PER_LONG))
>>
>
> I think this would be a disaster because something like
>
>BIT(123)
>
> would not even generate a warning.
>
There were a discussion on this, at KJ, when BIT was first used with a
modular operation. I said the same thing as you do now, but a big user
of BIT is the input-subsystem who defined their BIT as above. Also it
was mentioned that the compiler can only find the statical errors, a
variable input can break it in runtime.
+ if we _really_ want to check the tree for such warnings, it is easy to
remove the modular operation temporarily (and keep away of input/)

I don't say I like this, just that it is a choose between possible errors.

as discussed in earlier thread there are two kinds of users of BIT
1. input sybsystem which needs the "% BITS_PER_LONG"
2. & all other who don't, so that they are warned when the bit no overflows
I think a simple macro cant serve both the purposes

so IMHO there should be two macros
+#define BIT(nr)(1UL << (nr))
which server the first case

&
+#define XXXBITXXX(nr)  (1UL << ((nr) % BITS_PER_LONG))
for input users
earlier i suggested a name BITWRAP
but some people hate it i think
'm fine with any other name as well
inputssuggest a name

so that we can still keep these two macros (along with LLBIT) in
bitops.h & use apporpriately

only hassle is the whole input tree is to be searched & replaced for BIT
is this OK

--
Milind Arun Choudhary
-
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.20-rc4-mm1: different values for OHCI_QUIRK_ZFMICRO

[Tony Olech]

Sorry guys,
I have spent the last three weeks trying to track
down a problem one of our customers has been having,
the only thing I have been able to determine is that using
mutex'es the kernel crashes and using semaphores instead
works. Now I realize that the target is to use mutexes,
but I have been really at my wits end trying to solve the
problem. As a result I am just now doing an external
module tar ball version and with a bit of luck I should
be able to post it on our web site, so that our customers
can download it, before I take my two week easter
holiday starting in one hour. Since I have restructured
the driver several times trying to get a handle on the
problem, I think the kernel patch is going to be a complete
replacement, which will take a couple of weeks to squeeze
all the lines into 80 columns.

Tony Olech

- Original Message - 
From: "Randy Dunlap" <[EMAIL PROTECTED]>

To: "Adrian Bunk" <[EMAIL PROTECTED]>
Cc: "David Brownell" <[EMAIL PROTECTED]>; "Andrew Morton" <[EMAIL PROTECTED]>;
"Benjamin Herrenschmidt" <[EMAIL PROTECTED]>; "David Brownell"
<[EMAIL PROTECTED]>; "Geoff Levand"
<[EMAIL PROTECTED]>; "Greg Kroah-Hartman" <[EMAIL PROTECTED]>; "Tony
Olech" <[EMAIL PROTECTED]>; ;

Sent: Thursday, March 29, 2007 11:06 PM
Subject: Re: 2.6.20-rc4-mm1: different values for OHCI_QUIRK_ZFMICRO



On Tue, 20 Feb 2007 01:06:54 +0100 Adrian Bunk wrote:


On Sun, Jan 14, 2007 at 06:36:10AM -0800, David Brownell wrote:
> On Sunday 14 January 2007 1:10 am, Adrian Bunk wrote:
> > <--  snip  -->
>
> Waiting for Tony to submit bugfixes to his driver...

Still unfixed as of 2.6.20-mm1.

> > ...
> >   CC  drivers/usb/misc/ftdi-elan.o
> > 
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/usb/misc/ftdi-elan.c:2307:1:
> > warning: "OHCI_QUIRK_ZFMICRO" redefined
> > In file included from
> > 
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/usb/misc/ftdi-elan.c:76:
> > 
/home/bunk/linux/kernel-2.6/linux-2.6.20-rc4-mm1/drivers/usb/misc/../host/ohci.h:399:1:
> > warning: this is the location of the previous definition
> > ...
> > $ grep -r ^#define * | grep OHCI_QUIRK_ZFMICRO
> > drivers/usb/host/ohci.h:#define OHCI_QUIRK_ZFMICRO  0x20
> > /* Compaq ZFMicro chipset*/
> > drivers/usb/host/u132-hcd.c:#define OHCI_QUIRK_ZFMICRO 0x10
> > drivers/usb/misc/ftdi-elan.c:#define OHCI_QUIRK_ZFMICRO 0x10
> > $
> >
> > <--  snip  -->


so is there a patch around for this yet?

or shall someone other than Tony (??) make one?


---
~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 1/4] coredump: add an interface to control the core dump routine

[Andrew Morton]

On Fri, 30 Mar 2007 19:29:23 +0900 "Kawai, Hidehiro" <[EMAIL PROTECTED]> wrote:

> > core_pattern:
> >   ...
> > . If the first character of the pattern is a '|', the kernel will treat
> >   the rest of the pattern as a command to run.  The core dump will be
> >   written to the standard input of that program instead of to a file.
> 
> I think dumping core over a pipe is almost good.  Filtering and writing
> out a core by a separete userspace program can be reliable because it is
> independent of the failed user process.  But I have one concern; data
> transfer over a pipe is slow.  It took 7 seconds to transfer 2GB
> anonymous shared memory (detailed at the last of this mail).
> 
> In the case of dumping hundreds processes which share giga bytes memory,
> it will take a few minutes even if the huge shared memory is not written
> to a disk.  If a user wants to restart the failed application as soon
> as possible to keep downtime to a minimum, this extra transfer time will
> be a barrier.  So I think in-kernel filtering is still needed.

Yes, I agree - I don't think we presently have a way of avoiding having
to send all of that uninteresting data down the pipe.

One may, however, be able to play tricks with /proc//mem from within
the corefile-generating program: select the vmas which are to be dumped,
read only those ones.  I don't know how practical that would be.
-
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: Student Project Ideas

[Gerb Stralko]

http://www.netnice.org/

it does exactly that...this project started at my college, and we've
done some cool research with this little project. Take a look, alot of
research papers too...

On 3/30/07, Pavel Machek <[EMAIL PROTECTED]> wrote:

Hi!

>  I've been hacking on the Linux kernel all semester for
>  my OS:
> Internals class. We are given full autonomy in picking
> our final
> programming project and I would love for mine to be
> /useful/ for the
> Linux kernel and not just a theoretical exorcise. If
> anybody has any
> bug fixes or features maybe they never got around to,
> and would be
> suitable for this situation, I would love to hear about
> them.

netnice would be nice. As in netnice -n 19 wget interesting_video.

Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch] remove artificial software max_loop limit

[Jan Engelhardt]

On Mar 30 2007 02:25, Ken Chen wrote:
>
> Oh, crap.  Google mail is innocent.  It was me who did some ugly
> copy-paste between apps.

Well, you did it again :p

> I don't mind either way, this thing won't be bigger than 1^20 anyway.
> Oh, which reminds me that we probably should explicitly test and cap
> that limit (1^20 that is).

I do not think is needed, since it will already be caught by the
layout of a dev_t.

> +static struct loop_device *loop_find_dev(int number)
> +{
> + struct loop_device *lo;
> +
> + list_for_each_entry(lo, &loop_devices, lo_list) {
> + if (lo->lo_number == number)
> + return lo;
> + }

Can do without {}


Jan
-- 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why is arch/s390/crypto/Kconfig sourced when building for another arch ?

[Jan Glauber]

On Fri, 2007-03-30 at 05:55 -0400, Robert P. J. Day wrote:
>   i'm betting the S390 folks would *really* hate that idea but, if you
> look closely, the generic Kconfig file *already* has some
> arch-dependent content:
> 
> ...
> config CRYPTO_DEV_PADLOCK
> tristate "Support for VIA PadLock ACE"
> depends on X86_32 <-
> ...

Yes, but the padlock driver is located under drivers/crypto. The s390
crypto stuff is not. It is under arch/s390/crypto, thats why the Kconfig
file is there...

Both solutions (the current and your proposed) are somehow ugly. 
I don't care too much, where the Kconfig entries are, as long as it
works. So if you're interested in changing it go forward and post a
patch...

Jan

>   i think it's a matter of deciding how to be consistent.  either you
> allow individual architectures to define their own additional Kconfig
> files or you don't.  mixing the two approaches is a recipe for
> confusion.
> 
> rday
> 
> 

-
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] crypto: RSA algorithm patch (kernel version 2.6.21-rc5-git6)

[Randy Dunlap]

On Fri, 30 Mar 2007 16:26:36 +0300 Tasos Parisinos wrote:

Hi,

Just a few whitespace nits that you can fix with any other
comments that you get...

> +static char rsa_op_compare(rsa_op *l, rsa_op *r)
> +{
> + int i;
> + u32 *lbuf, *rbuf;
> +
> + /* Compare the two operands based on sign */
> + if (l->sign != r->sign)
> + return (l->sign)? -1: 1;

  -1 : 1;

> + /* Compare the two operands based on their size */
> + if (l->size > r->size && rsa_op_clz(l) < (l->size - r->size) * 32)
> + return 1;
> + else if (r->size > l->size && rsa_op_clz(r) < (r->size - l->size) * 32)
> + return -1;
> +
> + /* Compare the two operands based on their hex values */
> + lbuf = l->data;
> + rbuf = r->data;
> + for (i = min(l->size, r->size) - 1; i >= 0; i--)
> + if (lbuf[i] > rbuf[i])
> + return 1;
> + else if (lbuf[i] < rbuf[i])
> + return -1;
> + return 0;
> +}
> +
> +static int rsa_op_shift(rsa_op **n, int bits)
> +{
> + int i, distance, size, lz, retval;
> + u32 *buf;
> + rsa_op *handle;
> +
> + if (!bits)
> + return 0;
> + handle = *n;
> +
> + /* Shifting to the right, no resize needed */
> + if (bits > 0) {
> + /* Drop off one limb for each 32 bit shift */
> + distance = bits / 32;
> + size = handle->size;
> + buf = handle->data;
> + for (i = 0; i < size; i++)
> + buf[i] = (i + distance >= size)? 0: buf[i + distance];

 0 :

> +
> + /* Shift the remaining 'bits' mod 32 */
> + bits = bits % 32;
> + if (bits) {
> + size -= distance;
> + distance = 32 - bits;
> + for (i = 0; i < size; i++) {
> + buf[i] = buf[i] >> bits;
> + if (i < size - 1)
> + buf[i] |=  buf[i + 1] << distance;
> + }
> + }
> +
> + rsa_op_canonicalize(handle);
> + return 0;
> + }
> +
> + bits = -bits;
> + lz = rsa_op_clz(handle) + (handle->limbs - handle->size) * 32;
> +
> + /*
> +  * Shifting to the left.
> +  * Reallocation is needed when the leading zeroes are less than
> +  * the shift distance
> +  */
> + if (lz < bits) {
> + /* Compute the size of the reallocation */
> + size = (bits - lz + 31) / 32;
> + retval = rsa_op_resize(n, handle->limbs + size);
> + if (retval < 0)
> + return retval;
> + handle = *n;
> + }
> + else
> + handle->size += ((bits - rsa_op_clz(handle) + 31) / 32);
> +
> + buf = handle->data;
> + distance = bits / 32;
> + /* Shift data 1 byte to the left for each 32 bit shift */
> + if (distance) {
> + /* Shift bytes */
> + for (i = handle->size - distance - 1; i >= 0; i--)
> + buf[i + distance] = buf[i];
> +
> + /* Zero the shifted in bytes */
> + memset(handle->data, 0, distance * sizeof(u32));
> + }
> +
> + /* Shift the remaining 'bits' mod 32 */
> + bits = bits % 32;
> + distance = 32 - bits;
> + if (bits)
> + for (i = handle->size - 1; i >= 0; i--) {
> + buf[i] = buf[i] << bits;
> + if (i > 0)
> + buf[i] |= (buf[i - 1] >> distance);
> + }
> +
> + return 0;
> +}
> +
> +
> +
> +
> +
> +
> +
> +/**
> +/**
> + * rsa_op_print - print the value of an rsa_op
> + * @n: pointer to the rsa_op to be printed
> + * @how: true to print canonicalized
> + */
> +void rsa_op_print(rsa_op *n, bool how)
> +{
> + int i, j;
> + u32 limb;
> + u8 byte;
> + bool started = false;
> +
> + printk("Operand @ 0x%x, %d limbs in size, %d limbs allocated, value = ",
> +(u32)n, n->size, n->limbs);
> +
> + /* Print the sign */
> + printk("%s", (n->sign)? "-": " ");
> +
> + /* Print the hex value */
> + for (i = n->size - 1; i >= 0; i--) {
> + limb = n->data[i];
> +
> + /* Ignore leading zero limbs if canonicalization is selected */
> + if (!limb && !started && how)
> + continue;
> +
> + /*
> +  * Print each limb as though each of its nibbles was a character
> +  * from the set '0' to '9' and 'a' to 'f'
> +  */
> + for (j = 28; j >= 0; j -= 4) {
> + byte = (u8)((limb >> j) & 0x0F);
> +
> + /*
> +  * Ignore leading zero bytes if canonicalization
> +  * is selected
> +  */
> +   

Re: [bug] fixed_init(): BUG: at drivers/base/core.c:120 device_release(), was: "2.6.21-rc5: known regressions"

[Vitaly Bordug]

On Fri, 30 Mar 2007 16:25:14 +0200
Ingo Molnar <[EMAIL PROTECTED]> wrote:

> 
> * Greg KH <[EMAIL PROTECTED]> wrote:
> 
> > > Device '[EMAIL PROTECTED]:1' does not have a release() function, it is 
> > > broken and must be fixed.
> > > BUG: at drivers/base/core.c:120 device_release()
> > >  [] show_trace_log_lvl+0x19/0x2e
> > >  [] show_trace+0x12/0x14
> > >  [] dump_stack+0x14/0x16
> > >  [] device_release+0x7c/0x7e
> > >  [] kobject_cleanup+0x44/0x5e
> > >  [] kobject_release+0xb/0xd
> > >  [] kref_put+0x63/0x71
> > >  [] kobject_put+0x14/0x16
> > >  [] put_device+0x11/0x13
> > >  [] device_unregister+0x12/0x15
> > >  [] fixed_mdio_register_device+0x210/0x23b
> > >  [] fixed_init+0x2f/0x33
> > >  [] init+0x15d/0x2bd
> > >  [] kernel_thread_helper+0x7/0x10
> > 
> > That means that whatever driver has fixed_mdio_register_device() in it 
> > is broken and needs to be fixed.
> 
> that would be drivers/net/phy/fixed.c.
> 

OK, I'll look into it, thanks for pointing out.

> > It is independant from your previous question about unregistering the 
> > device from within module_init().
> 
> (yes - hence the different subject line, etc.)
> 


-- 
Sincerely, 
Vitaly
-
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.21-rc5-mm3

[Michal Piotrowski]

On 30/03/07, Andrew Morton <[EMAIL PROTECTED]> wrote:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/



It's my lucky Friday, kernel hangs shortly after

PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Removing info for No Bus:vcs1
PM: Removing info for No Bus:vcsa1
PM: Adding info for No Bus:vcs1
PM: Adding info for No Bus:vcsa1
PM: Adding info for No Bus:rtc
Real Time Clock Driver v1.12ac

due to

GOOD
mm-only-hrtimers-debug-patch.patch
mm-only-hrtimers-debug-patch-fix.patch
BAD

patches. Both patches works fine for me in vanilla tree.

http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5-mm3/mm-config
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc5-mm3/mm-console.log

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Why is NCQ enabled by default by libata? (2.6.20)

[Lennart Sorensen]

On Thu, Mar 29, 2007 at 02:47:20PM -0700, David Schwartz wrote:
> Which sounds faster to you:
> 
> 1) "Do A, B, C, and D."
>"Okay, I've finished A, B, C, and B."
> or
> 
> 2) "Do A."
>"Okay." 
>"Do B."
>"Okay."
>"Do C."
>"Okay."
>"Do D."
>"Okay."
> 
> The first looks a bit more efficient to me.

It also looks like the first one got confused by having to remember all
those letters it had done. :)

--
Len Sorensen
-
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.21-rc5-mm3

[Dmitry Torokhov]

On 3/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote:


ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/

- git-cryptodev has things in it again

- Re-added git-e1000: a large amount of e1000 driver work

- git-net has a huge amount of material in it, but I dropped it because it
 went oops.

- git-block is back, minus the problematic unplugging rework.

- Lots of x86 updates.

- lguest is being redone and has been dropped

- The IDE development tree has been restored



Andrew,

Did you drop git-input? I do not see it anywhere

--
Dmitry
-
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: [test] hackbench.c interactivity results: vanilla versus SD/RSDL

[Mike Galbraith]

On Fri, 2007-03-30 at 15:05 +, Xenofon Antidides wrote:
> - Original Message 
> From: Ingo Molnar <[EMAIL PROTECTED]>
> To: Con Kolivas <[EMAIL PROTECTED]>
> Cc: linux list ; Andrew Morton <[EMAIL 
> PROTECTED]>; Mike Galbraith <[EMAIL PROTECTED]>
> Sent: Thursday, March 29, 2007 9:22:49 PM
> Subject: [test] hackbench.c interactivity results: vanilla versus SD/RSDL
> 
> 
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> 
> > * Con Kolivas <[EMAIL PROTECTED]> wrote:
> > 
> > > I'm cautiously optimistic that we're at the thin edge of the bugfix 
> > > wedge now.
> [...]
> 
> > and the numbers he posted:
> > 
> >  http://marc.info/?l=linux-kernel&m=117448900626028&w=2
> 
> We been staring at these numbers for while now and we come to the conclusion 
> they wrong.
> 
> The test is f is 3 tasks, two on different and one on same cpu as sh here:
> virgin 2.6.21-rc3-rsdl-smp
> top - 13:52:50 up 7 min, 12 users,  load average: 3.45, 2.89, 1.51
> 
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  P COMMAND
>  6560 root  31   0  2892 1236 1032 R   82  0.1   1:50.24 1 sh
>  6558 root  28   0  1428  276  228 S   42  0.0   1:00.09 1 f
>  6557 root  30   0  1424  280  228 R   35  0.0   1:00.25 0 f
>  6559 root  39   0  1424  276  228 R   33  0.0   0:58.36 0 f

This is a 1 second sample, tasks migrate.

-Mike

-
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/5] RT kernel: force detect HPET from PCI space

[Nicolas Mailhot]

Anyone got the same thing for CK804? I had my hopes high, and then I saw
the DECLARE_PCI_FIXUP_HEADER values [and the thread title was
misleading]

-- 
Nicolas Mailhot
-
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: [QUESTION] check for mem in slab

[Cyrill Gorcunov]

[Pekka Enberg - Fri, Mar 30, 2007 at 02:55:26PM +0300]
| On 3/30/07, Heiko Carstens <[EMAIL PROTECTED]> wrote:
| >> in file mm/slab.c and routine kmem_cache_init() I found there
| >> is no checking for allocated memory on line:
| >>
| >>   /* 4) Replace the bootstrap head arrays */
| >>   {
| >>   struct array_cache *ptr;
| >>
| >>   ptr = kmalloc(sizeof(struct arraycache_init), GFP_KERNEL);
| >>
| >> --> no check for ptr == NULL <--
| >[...]
| >> is that OK? or it's a bug?
| >
| >It's ok. If that allocation fails your machine won't come up anyway.
| 
| We ought to add a BUG_ON or comment at least there as this keeps
| popping up again and again.
| 

Thanks for answer

Cyrill

-
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.21-rc5-mm3

[Ingo Molnar]

* Michal Piotrowski <[EMAIL PROTECTED]> wrote:

> It's my lucky Friday, kernel hangs shortly after
> 
> PM: Removing info for No Bus:vcsa1
> PM: Adding info for No Bus:vcs1
> PM: Adding info for No Bus:vcsa1
> PM: Removing info for No Bus:vcs1
> PM: Removing info for No Bus:vcsa1
> PM: Adding info for No Bus:vcs1
> PM: Adding info for No Bus:vcsa1
> PM: Adding info for No Bus:rtc
> Real Time Clock Driver v1.12ac
> 
> due to
> 
> GOOD
> mm-only-hrtimers-debug-patch.patch
> mm-only-hrtimers-debug-patch-fix.patch
> BAD
> 
> patches. Both patches works fine for me in vanilla tree.

hm. now that's a mystery ... Any way to figure out where it hangs? 
nmi_watchdog=1/2, softlockup, etc?

Ingo
-
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.21-rc5-mm3

[Andrew Morton]

On Fri, 30 Mar 2007 12:38:11 -0400 "Dmitry Torokhov" <[EMAIL PROTECTED]> wrote:

> On 3/30/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/
> >
> > - git-cryptodev has things in it again
> >
> > - Re-added git-e1000: a large amount of e1000 driver work
> >
> > - git-net has a huge amount of material in it, but I dropped it because it
> >  went oops.
> >
> > - git-block is back, minus the problematic unplugging rework.
> >
> > - Lots of x86 updates.
> >
> > - lguest is being redone and has been dropped
> >
> > - The IDE development tree has been restored
> >
> 
> Andrew,
> 
> Did you drop git-input? I do not see it anywhere
> 

hm, odd, my git-input pull came up with a short changelog and no diff, so
it was decided that the tree was empty.  I don't know what could have
caused that.  Seems OK now though.

-
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/5] RT kernel: force detect HPET from PCI space

[Venki Pallipadi]

On Fri, Mar 30, 2007 at 06:50:19PM +0200, Nicolas Mailhot wrote:
> Anyone got the same thing for CK804? I had my hopes high, and then I saw
> the DECLARE_PCI_FIXUP_HEADER values [and the thread title was
> misleading]
> 

Sorry about the wrong subject. It should have had ICH in the subject somewhere.
On the brighter side, if you find the chipset document for your chipset,
It should be as easy as this patch to force enable it :-).

Thanks,
Venki
-
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: broken device locking, sg vs. sg_io on block devices

[Alan Cox]

>If there is a simple way to get the mapping between the sg and sr
>devices that would be great and almost solve the problems, but I
>cannot discover a such thing in the kernel.

You can go trying to match bus values but we have SG_IO on /dev/sr. This
is an old known problem with /dev/sg, and it is one reason Jens and co
fixed it with the SG_IO interface.

>  - hald is using O_EXCL already, as wodim does, and this seems to work
>well as long as they are acting on the same virtual devices.

You might want to try hal polling the master while burning on the slave
and vice versa that also used to cause some systems problems.

>  - of course the hardware does not handle concurent requests, it is
>designed that way. It is burden of kernel to canalize the access and
>deal with concurrency issues. Obviously the kernel can and shall not

It's the job of the kernel to serialize requests coming in and it does
that for you both with SCSI and even old IDE. If you ask it to do
something stupid then that becomes the desktops problem.

>do all the work but at least the basic safety mechanisms must work
>reliably and currently they don't.

The kernel does not have sufficient information to handle /dev/sg locking
by itself. That is one reason /dev/sg is a privileged interface. It's
designed to let you do anything however crazy you like, as root. If you
do something stupid it breaks. The whole point of /dev/sg is that you can
do anything with it. You shouldn't be using /dev/sg for normal CD burning
applications on 2.6. 

For sane systems use the SG_IO interface on the proper device file. That
also fixes the need for setuid access and the like except when issuing
"dangerous" commands.

Christoph is wrong about one point, the hardware isn't broken, The IDE bus
is merely badly designed in this area. 

HAL breaks systems, it causes some laptops to burn power and on a few
boxes kills your disk performance. It'll also stop a few boxes reading
video-cd disks. Most of that appears to be HAL problems or indirectly
through problems in the locking scheme chosen (O_EXCL not fcntl locks).

The desktop user space should really know what it is doing with the CD
device if it wants to do things like CD burning. If the serial port
people could get this right in 1977 then there is no excuse fo the CD
using people not getting it right in 2007

Alan
-
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] nommu arch dont zero the anonymous mapping by adding UNINITIALIZE flag

[Alan Cox]

> Summary is, when I run the app "time test",
> 
> on x86:
> real0m0.066s
> user0m0.008s
> sys 0m0.058s
> 
> on Blackfin:
> real3m 37.69s
> user0m 0.04s
> sys 3m 37.58s

What would be relevant would be Blackfin with clearing and blackfin
without

> ---
> So now the question is,
> Keep the same behave as MMU but with bad performance, or keep the same
> performance as MMU but without the same behave, Which one is more
> important?

Behaviour.

You can implement a /dev/pages that is a copy of /dev/zero in tiny
amounts of code and use that for the specific problem cases.

Alan
-
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 dependency generation

[Jeff Dike]

On Fri, Mar 30, 2007 at 04:43:17PM +0100, Jan Beulich wrote:
> >But that will break UM - no??
> >See following note from fixdep:
> > * Note 2: if somebody writes HELLO_CONFIG_BOOM in a file, it will depend 
> > onto
> > * CONFIG_BOOM. This could seem a bug (not too hard to fix), but please do 
> > not
> > * fix it! Some UserModeLinux files (look at arch/um/) call CONFIG_BOOM as
> > * UML_CONFIG_BOOM, to avoid conflicts with /usr/include/linux/autoconf.h,
> > * through arch/um/include/uml-config.h; this fixdep "bug" makes sure that
> > * those files will have correct dependencies.
> 
> Hmm, didn't see this note. Then this might warrant special casing UML, but
> penalizing all code due to this seems at least odd to me.

If I understand this, I would think that special-casing UML_CONFIG_*
instead of *_CONFIG_* would be the way to go.

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/

Re: 2.6.21-rc5-mm3

[Michal Piotrowski]

Ingo Molnar napisał(a):
> * Michal Piotrowski <[EMAIL PROTECTED]> wrote:
> 
>> It's my lucky Friday, kernel hangs shortly after
>>
>> PM: Removing info for No Bus:vcsa1
>> PM: Adding info for No Bus:vcs1
>> PM: Adding info for No Bus:vcsa1
>> PM: Removing info for No Bus:vcs1
>> PM: Removing info for No Bus:vcsa1
>> PM: Adding info for No Bus:vcs1
>> PM: Adding info for No Bus:vcsa1
>> PM: Adding info for No Bus:rtc
>> Real Time Clock Driver v1.12ac
>>
>> due to
>>
>> GOOD
>> mm-only-hrtimers-debug-patch.patch
>> mm-only-hrtimers-debug-patch-fix.patch
>> BAD
>>
>> patches. Both patches works fine for me in vanilla tree.
> 
> hm. now that's a mystery ... Any way to figure out where it hangs? 
> nmi_watchdog=1/2, softlockup, etc?
> 
>   Ingo
> 

nmi_watchdog=1 boots fine

nmi_watchdog=2 shows this

BUG: NMI Watchdog detected LOCKUP on CPU0, eip c014ce9c, registers:
Modules linked in: ide_cd cdrom rtc unix
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 0093   (2.6.21-rc5-mm3 #10)
EIP is at read_pointer+0x49/0x2d8
eax: c7a8dd04   ebx:    ecx:    edx: c043d19c
esi: c043d184   edi: c043d19c   ebp: c7a8dbf4   esp: c7a8dbbc
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process udevd (pid: 864, ti=c7a8c000 task=c97cd4d0 task.ti=c7a8c000)
Stack: 000b c7a8dc70 c7a8dbf4 c014d6d0 c7a8dd04 c043e454 c7a8dbf4 c011fdd1 
   c043e404 c043e454 c043d190 0005cd94 c043d184 c7a8dd04 c7a8dd14 c014dd3a 
       c7a8df44 c7a8dd74 c741eefb 0008 
Call Trace:
 [] unwind+0x414/0xfa2
 [] dump_trace_unwind+0xb4/0xe5
 [] unwind_init_running+0x25/0x2b
 [] dump_trace+0x63/0x1eb
 [] save_stack_trace+0x23/0x42
 [] update_cpu_base_expires_next+0x56/0x5a
 [] hrtimer_interrupt+0x17c/0x1b8
 [] smp_apic_timer_interrupt+0x72/0x85
 [] apic_timer_interrupt+0x33/0x38
 [] lock_release+0x1d2/0x1da
 [] up_read+0x19/0x2e
 [] do_page_fault+0x28f/0x55b
 [] error_code+0x79/0x80
 [] __put_user_4+0x12/0x18
DWARF2 unwinder stuck at __put_user_4+0x12/0x18
Leftover inexact backtrace:
 [] ret_from_fork+0x6/0x1c
 ===
Code: a8 47 83 c0 00 0f 84 a3 02 00 00 8b 55 d8 8b 02 89 7c 24 0c 89 44 24 08 
89 5c 24 04 c7 04 24 7c 54 3f c0 e9 75 02 00 00 8b 45 d8 <8b> 08 89 4d f0 89 d8 
83 e0 07 83 f8 01 74 7f 7f 04 85 c0 eb 08 

l *0xc014ce9c
0xc014ce9c is in read_pointer (/mnt/md0/devel/linux-mm/kernel/unwind.c:526).
521
522 if (ptrType < 0 || ptrType == DW_EH_PE_omit) {
523 dprintk(1, "Invalid pointer encoding %02X (%p,%p).", 
ptrType, *pLoc, end);
524 return 0;
525 }
526 ptr.p8 = *pLoc;
527 switch(ptrType & DW_EH_PE_FORM) {
528 case DW_EH_PE_data2:
529 if (end < (const void *)(ptr.p16u + 1)) {
530 dprintk(1, "Data16 overrun (%p,%p).", ptr.p8, 
end);

UNWIND_INFO stuff

BUG: NMI Watchdog detected LOCKUP<0>Kernel panic - not syncing: Aiee, killing 
interrupt handler!
 on CPU1, eip c014cd37, registers:
Modules linked in: ide_cd cdrom rtc unix
CPU:1
EIP:0060:[]Not tainted VLI
EFLAGS: 0012   (2.6.21-rc5-mm3 #10)
EIP is at cie_for_fde+0x45/0x65
eax: 0001c260   ebx: c04431f4   ecx: 0001c264   edx: 0010
esi: c04431f8   edi: c97f7da4   ebp: c97f7c94   esp: c97f7c8c
ds: 007b   es: 007b   fs: 00d8  gs: 0033  ss: 0068
Process udevd (pid: 843, ti=c97f6000 task=c97f2ac0 task.ti=c97f6000)
Stack: 0003aac0 c045f458 c97f7db4 c014dd93   c97f3014 01cc 
   c97f7f0c c97f7e14 c741eefb 0008 c97f7f0c c04431f8 c020c184 c97f7f0c 
   c97f7f44 c97f7f44  0008 c0834780  c97f7d34 c0142dc8 
Call Trace:
 [] unwind+0x46d/0xfa2
 [] dump_trace_unwind+0xb4/0xe5
 [] unwind_init_running+0x25/0x2b
 [] dump_trace+0x63/0x1eb
 [] save_stack_trace+0x23/0x42
 [] update_cpu_base_expires_next+0x56/0x5a
 [] hrtimer_interrupt+0x17c/0x1b8
 [] smp_apic_timer_interrupt+0x72/0x85
 [] apic_timer_interrupt+0x33/0x38
 [] __get_user_4+0x14/0x17
DWARF2 unwinder stuck at __get_user_4+0x14/0x17
Leftover inexact backtrace:
 [] do_execve+0xdd/0x210
 [] sys_execve+0x3f/0x62
 [] sysenter_past_esp+0x5f/0x99
 ===
Code: c9 74 42 f6 c1 03 75 3b b8 04 00 00 00 2b 42 10 01 d8 39 c1 77 2d 89 c8 
83 e0 fc 29 c3 8d 73 04 8b 53 04 83 fa 08 76 1b 8d 41 fc <39> c2 73 14 80 e2 03 
75 0f 83 7e 04 00 74 0b eb 07 be ac 47 83 

l *0xc014cd37
0xc014cd37 is in cie_for_fde (/mnt/md0/devel/linux-mm/kernel/unwind.c:498).
493 return ¬_fde; /* this is a CIE */
494 if ((fde[1] & (sizeof(*fde) - 1))
495 || fde[1] > (unsigned long)(fde + 1) - (unsigned 
long)table->address)
496 return NULL; /* this is not a valid FDE */
497 cie = fde + 1 - fde[1] / sizeof(*fde);
498 if (*cie <= sizeof(*cie) + 4
499 || *cie >= fde[1] - sizeof(*fde)
500 || (*cie & (sizeof(*cie) - 1))
501 || cie[1])
502 

Re: [PATCH 1/5] RT kernel: force detect HPET from PCI space

[Nicolas Mailhot]

Le vendredi 30 mars 2007 à 09:59 -0700, Venki Pallipadi a écrit :
> On Fri, Mar 30, 2007 at 06:50:19PM +0200, Nicolas Mailhot wrote:
> > Anyone got the same thing for CK804? I had my hopes high, and then I saw
> > the DECLARE_PCI_FIXUP_HEADER values [and the thread title was
> > misleading]
> > 
> 
> Sorry about the wrong subject. It should have had ICH in the subject 
> somewhere.

I think I'll recover :)

> On the brighter side, if you find the chipset document for your chipset,
> It should be as easy as this patch to force enable it :-).

It's only at the rainbow end, right?

-- 
Nicolas Mailhot
-
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: exposing FSB clock speed in /sys

[Alan Cox]

> Looking at the code, it seems that there is no standard way of extracting
> the FSB speed. For each processor model, you have different MSRs. I would
> think that the routines in the cpufreq code could be moved out and used
> as the basis to expose the information somewhere in /sys.

It's well un-documented, but one of the problems is that for many
processor lines the information isn't in public documents (eg the older
processors like the PII/PIII)

Alan
-
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.21-rc5-mm3

[Valdis . Kletnieks]

On Fri, 30 Mar 2007 01:05:59 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm3/

Building with CONFIG_MAC80211_DEBUGFS=y but CONFIG_MAC80211_DEBUG_COUNTERS=n
blows chunks on my box:

  CC [M]  net/mac80211/debugfs.o
net/mac80211/debugfs.c: In function ‘stats_wme_rx_queue_read’:
net/mac80211/debugfs.c:266: error: ‘struct ieee80211_local’ has no member 
named ‘wme_rx_queue’
net/mac80211/debugfs.c: In function ‘stats_wme_tx_queue_read’:
net/mac80211/debugfs.c:286: error: ‘struct ieee80211_local’ has no member 
named ‘wme_tx_queue’
make[2]: *** [net/mac80211/debugfs.o] Error 1



pgpIyZRb7esVY.pgp
Description: PGP signature

Re: [bug] hung bootup in various drivers, was: "2.6.21-rc5: known regressions"

[Ingo Molnar]

* Greg KH <[EMAIL PROTECTED]> wrote:

> >  BUG: at drivers/base/driver.c:187 driver_unregister()
> >   [] show_trace_log_lvl+0x19/0x2e
> >   [] show_trace+0x12/0x14
> >   [] dump_stack+0x14/0x16
> >   [] driver_unregister+0x3d/0x43
> >   [] pci_unregister_driver+0x10/0x5f
> >   [] slgt_init+0x9b/0x1ca
> >   [] init+0x15d/0x2bd
> >   [] kernel_thread_helper+0x7/0x10

> Yes, we should allow the ability to call unregister_driver from within 
> the module_init function.
> 
> But I don't understand what is causing you to see this problem.  Who 
> is holding the reference on the struct device at this point in time?  
> Is it the fact that userspace has some files open and it hasn't 
> released them yet?

at least in the slgt_init() case the affected codepath is trivial:

if ((rc = pci_register_driver(&pci_driver)) < 0) {
printk("%s pci_register_driver error=%d\n", driver_name, rc);
return rc;
}
pci_registered = 1;

if (!slgt_device_list) {
printk("%s no devices found\n",driver_name);
pci_unregister_driver(&pci_driver);
return -ENODEV;

slgt_device_list is NULL because no matching PCI ID is on my system (i 
dont have this hardware), so the ->probe() function did not get called 
at all.

i.e. a pure pci_register_driver() + pci_unregister_driver() sequence 
seems to cause a hang. I.e. it seems to be a pure driver-base-core 
matter.

Ingo
-
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.21-rc1 and 2.6.21-rc2 kwin dies silently

[Adrian Bunk]

On Thu, Mar 29, 2007 at 12:35:42PM +0100, Sid Boyce wrote:
>...
> 1) Ran the commands as above,cg-clone; git start; git bisect bad 
> ;git bisect good  I presume.
> 2) 2.6.20-git10 is the last good kernel.
> 3) 2.6.20-git11 and later are all bad.
> 4) I do cg-clone which gives a kernel whose Makefile is 2.6.21-rc4 (or 
> whatever is current).
>...

No, that's what should be repeated:

# start round
cp /path/to/.config .
make oldconfig
make
# install kernel, check whether it's good or bad, then:
git bisect [bad|good]
# start next round

> Regards
> Sid.

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/

[RFC][PATCH 0/2] Darwinux: Binary compat support for Mach-O/Darwin in Linux

[Kyle Moffett]

I've gotten some time to start working with this code again and I'm  
looking for some review on my first couple patches.  After these two  
patches the code does little more than print out lots of details  
about the binary being run to the syslog and then fail with -ENOEXEC,  
but it's a start.  I'm currently fixing up my icky memory-mapping  
code to avoid allocating big chunks of kernel memory for tables in  
the binary, and once I make some progress on that I'll submit it too.


I'd appreciate any information on what is required in the load_binary  
function in my binfmt.  In particular, if there's anything which fs/ 
binfmt_elf.c does do which is *NOT* required, I'd be interested to  
know what and why.  Thanks for all your assistance.


Cheers,
Kyle Moffett
-
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/