Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! > > I should take some sleep now, so I can't test the patch, but I don't > > think it will help. If someone has PF_FREEZE set, he should be in > > refrigerator. > > OK, so if that doesn't help, here's an alternate approach - this > lets xfsbufd track when its entering the refrigerator(), so that > other callers know that attempts to wake it are futile. Thanks, this patch helped. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi, On Tuesday, 12 of April 2005 01:51, Pavel Machek wrote: ]--snip--[ > > Since the refrigerator() call is in place in the main xfsbufd loop, > > I suspect we're hitting that second case here, where a low memory > > situation is resulting in someone attempting to wakeup xfsbufd -- > > I'm not sure if this is the right way to check if we're in that > > state, but does this patch help? (it would certainly prevent the > > spurious wakeups, but only if the caller has PF_FREEZE set - will > > that be the case here?) > > I should take some sleep now, so I can't test the patch, but I don't > think it will help. If someone has PF_FREEZE set, he should be in > refrigerator. Or he was in TASK_UNINTERRUPTIBLE while processes were being frozen. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Tue, Apr 12, 2005 at 01:04:25PM +0200, Pavel Machek wrote: > > OK, so if that doesn't help, here's an alternate approach - this > > lets xfsbufd track when its entering the refrigerator(), so that > > other callers know that attempts to wake it are futile. > > Thanks, this patch helped. I can confirm, the 2nd patch worked and the 1st one didn't. (This is against 2.6.12-rc2-mm1 with sched-x86-patch-name-is-way-too-long.patch backed out. ;) ) -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi, On Tuesday, 12 of April 2005 01:51, Pavel Machek wrote: ]--snip--[ Since the refrigerator() call is in place in the main xfsbufd loop, I suspect we're hitting that second case here, where a low memory situation is resulting in someone attempting to wakeup xfsbufd -- I'm not sure if this is the right way to check if we're in that state, but does this patch help? (it would certainly prevent the spurious wakeups, but only if the caller has PF_FREEZE set - will that be the case here?) I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. Or he was in TASK_UNINTERRUPTIBLE while processes were being frozen. :-) Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. OK, so if that doesn't help, here's an alternate approach - this lets xfsbufd track when its entering the refrigerator(), so that other callers know that attempts to wake it are futile. Thanks, this patch helped. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
> I should take some sleep now, so I can't test the patch, but I don't
> think it will help. If someone has PF_FREEZE set, he should be in
> refrigerator.
OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd track when its entering the refrigerator(), so that
other callers know that attempts to wake it are futile.
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 10:14:27.468202824 +1000
@@ -1746,13 +1746,15 @@ STATIC DECLARE_COMPLETION(pagebuf_daemon
STATIC struct task_struct *pagebuf_daemon_task;
STATIC int pagebuf_daemon_active;
STATIC int force_flush;
-
+STATIC int force_sleep;
STATIC int
pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (force_sleep)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
@@ -1778,7 +1780,12 @@ pagebuf_daemon(
INIT_LIST_HEAD();
do {
- try_to_freeze(PF_FREEZE);
+ if (unlikely(current->flags & PF_FREEZE)) {
+ force_sleep = 1;
+ refrigerator(PF_FREEZE);
+ } else {
+ force_sleep = 0;
+ }
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout((xfs_buf_timer_centisecs * HZ) / 100);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! > > > > > No, XFS is my root filesystem. :( (Now that I think about it, would > > > > > modularizing XFS and using an initrd be OK?) > > > > > > > > Yes, loading xfs from initrd should help. [At least it did during > > > > suse9.3 testing.] > > > > > > Once I modularized xfs and switched to using an initrd, the problem > > > disappeared. > > > > I reproduced it locally. Problem is that xfsbufd goes refrigerated, > > but someone still tries to wake it up *very* often. Probably something > > else in xfs needs refrigerating, too, but I'm not a XFS wizard... > > Thanks Pavel - I've been reading the thread from the other side > of the fence, not understanding the swsusp side of things. :) > > There are two ways the xfsbufd thread will wake up - either by its > timer going off (for it to flush delayed write metadata buffers) > or by being explicitly woken up when we're low on memory (in which > case it also flushes out dirty metadata, such that pages can be > cleaned and made available to the system). > > Since the refrigerator() call is in place in the main xfsbufd loop, > I suspect we're hitting that second case here, where a low memory > situation is resulting in someone attempting to wakeup xfsbufd -- > I'm not sure if this is the right way to check if we're in that > state, but does this patch help? (it would certainly prevent the > spurious wakeups, but only if the caller has PF_FREEZE set - will > that be the case here?) I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
> Hi!
>
> > > > No, XFS is my root filesystem. :( (Now that I think about it, would
> > > > modularizing XFS and using an initrd be OK?)
> > >
> > > Yes, loading xfs from initrd should help. [At least it did during
> > > suse9.3 testing.]
> >
> > Once I modularized xfs and switched to using an initrd, the problem
> > disappeared.
>
> I reproduced it locally. Problem is that xfsbufd goes refrigerated,
> but someone still tries to wake it up *very* often. Probably something
> else in xfs needs refrigerating, too, but I'm not a XFS wizard...
Thanks Pavel - I've been reading the thread from the other side
of the fence, not understanding the swsusp side of things. :)
There are two ways the xfsbufd thread will wake up - either by its
timer going off (for it to flush delayed write metadata buffers)
or by being explicitly woken up when we're low on memory (in which
case it also flushes out dirty metadata, such that pages can be
cleaned and made available to the system).
Since the refrigerator() call is in place in the main xfsbufd loop,
I suspect we're hitting that second case here, where a low memory
situation is resulting in someone attempting to wakeup xfsbufd --
I'm not sure if this is the right way to check if we're in that
state, but does this patch help? (it would certainly prevent the
spurious wakeups, but only if the caller has PF_FREEZE set - will
that be the case here?)
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 08:59:38.973557728 +1000
@@ -1753,6 +1753,8 @@ pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (current->flags & PF_FREEZE)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Mon, 2005-04-11 at 12:45 +0200, Thomas Graf wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 09:22
> > On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
> > wrote:
> > > + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > > +
> > > + skb = alloc_skb(size, GFP_ATOMIC);
> > > + if (!skb) {
> > > + printk(KERN_ERR "Failed to allocate new skb with
> > > size=%u.\n", size);
> > > + return;
> > > + }
> > > +
> > > + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size -
> > > sizeof(*nlh));
> > >
> > > This is not correct, what happens is:
> > > size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > > --> align(hdr)+align(data)
> > > size - sizeof(*nlh)
> > > --> (align(hdr)-hdr)+align(data)
> > > NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
> > > --> align(hdr)+(align(hdr)-hdr)+align(data)
> > >
> > > At the moment align(hdr) == hdr since nlmsghdr is already aligned
> > > but this might change and your code will break.
> >
> > As far as I remember, header is always supposed to be aligned properly
> > "by design", so it even could be nonaligned here.
>
> No, have a look at the macros:
>
> #define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(sizeof(struct nlmsghdr)))
> #define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len))
>
> NLMSG_LENGTH points to the end of the payload in the message, NLMSG_SPACE
> represents the total size aligned properly for a possible next multipart
> message.
>
> It is unlikely that nlmsghdr will ever be unaligned but there can be no
> reason to introduce code that can break with perfectly legal changes just
> because of that.
But NLMSG_ALIGN(sizeof(hdr)) is always equal to sizeof(hdr), that size
was select not accidentally.
I will change it, no problem, it is good from aesthetic point of view.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! > > > No, XFS is my root filesystem. :( (Now that I think about it, would > > > modularizing XFS and using an initrd be OK?) > > > > Yes, loading xfs from initrd should help. [At least it did during > > suse9.3 testing.] > > Once I modularized xfs and switched to using an initrd, the problem > disappeared. I reproduced it locally. Problem is that xfsbufd goes refrigerated, but someone still tries to wake it up *very* often. Probably something else in xfs needs refrigerating, too, but I'm not a XFS wizard... Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-11 09:22
> On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
> wrote:
> > + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > +
> > + skb = alloc_skb(size, GFP_ATOMIC);
> > + if (!skb) {
> > + printk(KERN_ERR "Failed to allocate new skb with
> > size=%u.\n", size);
> > + return;
> > + }
> > +
> > + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh));
> >
> > This is not correct, what happens is:
> > size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> > --> align(hdr)+align(data)
> > size - sizeof(*nlh)
> > --> (align(hdr)-hdr)+align(data)
> > NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
> > --> align(hdr)+(align(hdr)-hdr)+align(data)
> >
> > At the moment align(hdr) == hdr since nlmsghdr is already aligned
> > but this might change and your code will break.
>
> As far as I remember, header is always supposed to be aligned properly
> "by design", so it even could be nonaligned here.
No, have a look at the macros:
#define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(sizeof(struct nlmsghdr)))
#define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len))
NLMSG_LENGTH points to the end of the payload in the message, NLMSG_SPACE
represents the total size aligned properly for a possible next multipart
message.
It is unlikely that nlmsghdr will ever be unaligned but there can be no
reason to introduce code that can break with perfectly legal changes just
because of that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Unable to boot 2.6.12-rc2-mm1 with command line maxcpus=1
Hi, I am having problems while booting 2.6.12-rc2-mm1 on i386 with command line maxcpus=1. Without this commandline, system boots fine otherwise it hangs. Serial output is pasted below. If maxcpus=1 is given along with acpi=off then system boots fine. I am not sure where the problem is. 2.6.12-rc1-mm4 does not have this problem. Any idea what is going on? config file is attached with the mail. Thanks Vivek LILO boot: linux linux-upt base 2.6.5-sy2.6.12-rc1-mm1 hzless Rachita-crash vivek sharyathi boot: vivek Loading vivek. Linux version 2.6.12-rc2-mm1-1M ([EMAIL PROTECTED]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-31)) #1 SMP PREEMPT Mon Apr 11 11:40:30 IST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009e000 (usable) BIOS-e820: 0009e000 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - efff6500 (usable) BIOS-e820: efff6500 - f000 (ACPI data) BIOS-e820: fffb - 0001 (reserved) BIOS-e820: 0001 - 0002 (usable) user-defined physical RAM map: user: - 0009e000 (usable) user: 0009e000 - 000a (reserved) user: 000e - 0010 (reserved) user: 0010 - 8000 (usable) 1152MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 0009e140 DMI 2.1 present. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x07] enabled) Processor #7 6:10 APIC version 17 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) Processor #3 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) Processor #4 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) Processor #5 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled) Processor #6 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1]) ACPI: IOAPIC (id[0x0e] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 14, version 19, address 0xfec0, GSI 0-63 ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 8 low edge) ACPI: NMI_SRC (dfl dfl global_irq 58) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 8000:8000) Built 1 zonelists Initializing CPU#0 Kernel command line: BOOT_IMAGE=vivek ro BOOT_FILE=/boot/bzImage-2.6.12-rc2-mm1-1M root=/dev/sda3 consle=tty0 console=ttyS0,38400 maxcpus=1 [EMAIL PROTECTED] mem=2G PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 900.198 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 2024916k/2097152k available (3086k kernel code, 71432k reserved, 1142k data, 232k init, 1179648k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 2048K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Cascades) stepping 04 Total of 1 processors activated (1769.47 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=0 pin2=-1 Brought up 1 CPUs NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd26c, last bus=15 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 ACPI: Assume root
Re: 2.6.12-rc2-mm1
Barry K. Nathan wrote: > On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: >> Can you try without XFS? > > No, XFS is my root filesystem. :( (Now that I think about it, would > modularizing XFS and using an initrd be OK?) Yes, although it is not totally trivial. > I'll see if I can reproduce this on one of my test boxes. I'll *try* to > get to it later today, but it's possible that I won't be able to get to > it until next Friday or Saturday. > >> I do not why it interferes, but I've seen that before on suse >> kernels... > > Have you seen it without the resume-from-initrd patch too, or only with > that patch? We have seen it in 9.3-beta, exact scenario was: - root fs is XFS, ide driver is modular => xfs module and ide-controller module is in initramfs => first all modules were loaded (device driver + fs) => resume was triggered, resume was _really_ slow. we worked around it in the initramfs by first loading device drivers, triggering resume, then loading the fs modules and continuing boot. In the resume case, we'd never reach the "load fs modules" part and generally it seems a good idea (if the drivers are modular) to keep the setup before resume as minimalistic as possible. We never tried with XFS compiled in. It seems we can no longer hide from fixing XFS ;-) Best regards, Stefan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1
Barry K. Nathan wrote: On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, although it is not totally trivial. I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. I do not why it interferes, but I've seen that before on suse kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? We have seen it in 9.3-beta, exact scenario was: - root fs is XFS, ide driver is modular = xfs module and ide-controller module is in initramfs = first all modules were loaded (device driver + fs) = resume was triggered, resume was _really_ slow. we worked around it in the initramfs by first loading device drivers, triggering resume, then loading the fs modules and continuing boot. In the resume case, we'd never reach the load fs modules part and generally it seems a good idea (if the drivers are modular) to keep the setup before resume as minimalistic as possible. We never tried with XFS compiled in. It seems we can no longer hide from fixing XFS ;-) Best regards, Stefan - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Unable to boot 2.6.12-rc2-mm1 with command line maxcpus=1
Hi, I am having problems while booting 2.6.12-rc2-mm1 on i386 with command line maxcpus=1. Without this commandline, system boots fine otherwise it hangs. Serial output is pasted below. If maxcpus=1 is given along with acpi=off then system boots fine. I am not sure where the problem is. 2.6.12-rc1-mm4 does not have this problem. Any idea what is going on? config file is attached with the mail. Thanks Vivek LILO boot: linux linux-upt base 2.6.5-sy2.6.12-rc1-mm1 hzless Rachita-crash vivek sharyathi boot: vivek Loading vivek. Linux version 2.6.12-rc2-mm1-1M ([EMAIL PROTECTED]) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-31)) #1 SMP PREEMPT Mon Apr 11 11:40:30 IST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009e000 (usable) BIOS-e820: 0009e000 - 000a (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - efff6500 (usable) BIOS-e820: efff6500 - f000 (ACPI data) BIOS-e820: fffb - 0001 (reserved) BIOS-e820: 0001 - 0002 (usable) user-defined physical RAM map: user: - 0009e000 (usable) user: 0009e000 - 000a (reserved) user: 000e - 0010 (reserved) user: 0010 - 8000 (usable) 1152MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 0009e140 DMI 2.1 present. ACPI: LAPIC (acpi_id[0x00] lapic_id[0x07] enabled) Processor #7 6:10 APIC version 17 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x03] lapic_id[0x02] enabled) Processor #2 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x04] lapic_id[0x03] enabled) Processor #3 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x05] lapic_id[0x04] enabled) Processor #4 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x06] lapic_id[0x05] enabled) Processor #5 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC (acpi_id[0x07] lapic_id[0x06] enabled) Processor #6 6:10 APIC version 17 WARNING: maxcpus limit of 1 reached. Processor ignored. ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x03] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x04] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x05] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x06] dfl dfl lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x07] dfl dfl lint[0x1]) ACPI: IOAPIC (id[0x0e] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 14, version 19, address 0xfec0, GSI 0-63 ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 8 low edge) ACPI: NMI_SRC (dfl dfl global_irq 58) Enabling APIC mode: Flat. Using 1 I/O APICs Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 8000 (gap: 8000:8000) Built 1 zonelists Initializing CPU#0 Kernel command line: BOOT_IMAGE=vivek ro BOOT_FILE=/boot/bzImage-2.6.12-rc2-mm1-1M root=/dev/sda3 consle=tty0 console=ttyS0,38400 maxcpus=1 [EMAIL PROTECTED] mem=2G PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 900.198 MHz processor. Using tsc for high-res timesource Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 2024916k/2097152k available (3086k kernel code, 71432k reserved, 1142k data, 232k init, 1179648k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Mount-cache hash table entries: 512 CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 2048K Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. CPU0: Intel Pentium III (Cascades) stepping 04 Total of 1 processors activated (1769.47 BogoMIPS). ENABLING IO-APIC IRQs ..TIMER: vector=0x31 pin1=0 pin2=-1 Brought up 1 CPUs NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd26c, last bus=15 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 ACPI: Assume root
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-11 09:22
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
wrote:
+ size = NLMSG_SPACE(sizeof(*msg) + msg-len);
+
+ skb = alloc_skb(size, GFP_ATOMIC);
+ if (!skb) {
+ printk(KERN_ERR Failed to allocate new skb with
size=%u.\n, size);
+ return;
+ }
+
+ nlh = NLMSG_PUT(skb, 0, msg-seq, NLMSG_DONE, size - sizeof(*nlh));
This is not correct, what happens is:
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-- align(hdr)+align(data)
size - sizeof(*nlh)
-- (align(hdr)-hdr)+align(data)
NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
-- align(hdr)+(align(hdr)-hdr)+align(data)
At the moment align(hdr) == hdr since nlmsghdr is already aligned
but this might change and your code will break.
As far as I remember, header is always supposed to be aligned properly
by design, so it even could be nonaligned here.
No, have a look at the macros:
#define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(sizeof(struct nlmsghdr)))
#define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len))
NLMSG_LENGTH points to the end of the payload in the message, NLMSG_SPACE
represents the total size aligned properly for a possible next multipart
message.
It is unlikely that nlmsghdr will ever be unaligned but there can be no
reason to introduce code that can break with perfectly legal changes just
because of that.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I reproduced it locally. Problem is that xfsbufd goes refrigerated, but someone still tries to wake it up *very* often. Probably something else in xfs needs refrigerating, too, but I'm not a XFS wizard... Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Mon, 2005-04-11 at 12:45 +0200, Thomas Graf wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-11 09:22
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED])
wrote:
+ size = NLMSG_SPACE(sizeof(*msg) + msg-len);
+
+ skb = alloc_skb(size, GFP_ATOMIC);
+ if (!skb) {
+ printk(KERN_ERR Failed to allocate new skb with
size=%u.\n, size);
+ return;
+ }
+
+ nlh = NLMSG_PUT(skb, 0, msg-seq, NLMSG_DONE, size -
sizeof(*nlh));
This is not correct, what happens is:
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-- align(hdr)+align(data)
size - sizeof(*nlh)
-- (align(hdr)-hdr)+align(data)
NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
-- align(hdr)+(align(hdr)-hdr)+align(data)
At the moment align(hdr) == hdr since nlmsghdr is already aligned
but this might change and your code will break.
As far as I remember, header is always supposed to be aligned properly
by design, so it even could be nonaligned here.
No, have a look at the macros:
#define NLMSG_LENGTH(len) ((len)+NLMSG_ALIGN(sizeof(struct nlmsghdr)))
#define NLMSG_SPACE(len) NLMSG_ALIGN(NLMSG_LENGTH(len))
NLMSG_LENGTH points to the end of the payload in the message, NLMSG_SPACE
represents the total size aligned properly for a possible next multipart
message.
It is unlikely that nlmsghdr will ever be unaligned but there can be no
reason to introduce code that can break with perfectly legal changes just
because of that.
But NLMSG_ALIGN(sizeof(hdr)) is always equal to sizeof(hdr), that size
was select not accidentally.
I will change it, no problem, it is good from aesthetic point of view.
--
Evgeniy Polyakov
Crash is better than data corruption -- Arthur Grabowski
signature.asc
Description: This is a digitally signed message part
Re: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Mon, Apr 11, 2005 at 12:57:59PM +0200, Pavel Machek wrote:
Hi!
No, XFS is my root filesystem. :( (Now that I think about it, would
modularizing XFS and using an initrd be OK?)
Yes, loading xfs from initrd should help. [At least it did during
suse9.3 testing.]
Once I modularized xfs and switched to using an initrd, the problem
disappeared.
I reproduced it locally. Problem is that xfsbufd goes refrigerated,
but someone still tries to wake it up *very* often. Probably something
else in xfs needs refrigerating, too, but I'm not a XFS wizard...
Thanks Pavel - I've been reading the thread from the other side
of the fence, not understanding the swsusp side of things. :)
There are two ways the xfsbufd thread will wake up - either by its
timer going off (for it to flush delayed write metadata buffers)
or by being explicitly woken up when we're low on memory (in which
case it also flushes out dirty metadata, such that pages can be
cleaned and made available to the system).
Since the refrigerator() call is in place in the main xfsbufd loop,
I suspect we're hitting that second case here, where a low memory
situation is resulting in someone attempting to wakeup xfsbufd --
I'm not sure if this is the right way to check if we're in that
state, but does this patch help? (it would certainly prevent the
spurious wakeups, but only if the caller has PF_FREEZE set - will
that be the case here?)
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 08:59:38.973557728 +1000
@@ -1753,6 +1753,8 @@ pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (current-flags PF_FREEZE)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
Hi! No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I reproduced it locally. Problem is that xfsbufd goes refrigerated, but someone still tries to wake it up *very* often. Probably something else in xfs needs refrigerating, too, but I'm not a XFS wizard... Thanks Pavel - I've been reading the thread from the other side of the fence, not understanding the swsusp side of things. :) There are two ways the xfsbufd thread will wake up - either by its timer going off (for it to flush delayed write metadata buffers) or by being explicitly woken up when we're low on memory (in which case it also flushes out dirty metadata, such that pages can be cleaned and made available to the system). Since the refrigerator() call is in place in the main xfsbufd loop, I suspect we're hitting that second case here, where a low memory situation is resulting in someone attempting to wakeup xfsbufd -- I'm not sure if this is the right way to check if we're in that state, but does this patch help? (it would certainly prevent the spurious wakeups, but only if the caller has PF_FREEZE set - will that be the case here?) I should take some sleep now, so I can't test the patch, but I don't think it will help. If someone has PF_FREEZE set, he should be in refrigerator. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [xfs-masters] swsusp vs. xfs [was Re: 2.6.12-rc2-mm1]
On Tue, Apr 12, 2005 at 01:51:10AM +0200, Pavel Machek wrote:
I should take some sleep now, so I can't test the patch, but I don't
think it will help. If someone has PF_FREEZE set, he should be in
refrigerator.
OK, so if that doesn't help, here's an alternate approach - this
lets xfsbufd track when its entering the refrigerator(), so that
other callers know that attempts to wake it are futile.
cheers.
--
Nathan
--- fs/xfs/linux-2.6/xfs_buf.c.orig 2005-04-12 09:00:26.375351560 +1000
+++ fs/xfs/linux-2.6/xfs_buf.c 2005-04-12 10:14:27.468202824 +1000
@@ -1746,13 +1746,15 @@ STATIC DECLARE_COMPLETION(pagebuf_daemon
STATIC struct task_struct *pagebuf_daemon_task;
STATIC int pagebuf_daemon_active;
STATIC int force_flush;
-
+STATIC int force_sleep;
STATIC int
pagebuf_daemon_wakeup(
int priority,
unsigned intmask)
{
+ if (force_sleep)
+ return 0;
force_flush = 1;
barrier();
wake_up_process(pagebuf_daemon_task);
@@ -1778,7 +1780,12 @@ pagebuf_daemon(
INIT_LIST_HEAD(tmp);
do {
- try_to_freeze(PF_FREEZE);
+ if (unlikely(current-flags PF_FREEZE)) {
+ force_sleep = 1;
+ refrigerator(PF_FREEZE);
+ } else {
+ force_sleep = 0;
+ }
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout((xfs_buf_timer_centisecs * HZ) / 100);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
> * jamal <[EMAIL PROTECTED]> 2005-04-10 10:39
> > Please crosspost on netdev - you should know that by now;->
> >
> > I actually disagreee with Herbert on this. Theres definetely good
> > need to have a more usable messaging system that rides on top of
> > netlink. It is not that netlink cant be extended (I actually think thats
> > a separate topic)
>
> I find it quite easy already but I guess a few macros would improve
> it even more. The routing attribute macros could be made generic to
> so can benefit from the advanages of TLVs.
>
> Evgeniy, Sorry for not having time earlier to give your patch a
> review. I'm not yet through completely and won't comment on the
> overall architecture until I have understood it all.
>
> diff -Nru /tmp/empty/cn_queue.c linux-2.6/drivers/connector/cn_queue.c
> --- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.0 +0300
> +++ linux-2.6/drivers/connector/cn_queue.c 2004-09-24 00:01:00.0
> +int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb)
> +{
> + struct cn_callback_entry *cbq, *n, *__cbq;
> + int found = 0;
> +
> + cbq = cn_queue_alloc_callback_entry(cb);
> + if (!cbq)
> + return -ENOMEM;
> +
> + atomic_inc(>refcnt);
> + cbq->pdev = dev;
> +
> + spin_lock(>queue_lock);
> + list_for_each_entry_safe(__cbq, n, >queue_list, callback_entry) {
>
> Why _safe? There is no way a entry can be removed here.
No particular reason - it easier to copy-paste it from other line :)
> + if (cn_cb_equal(&__cbq->cb->id, >id)) {
> + found = 1;
> + break;
> + }
> + }
> diff -Nru /tmp/empty/connector.c linux-2.6/drivers/connector/connector.c
> --- /tmp/empty/connector.c 1970-01-01 03:00:00.0 +0300
> +++ linux-2.6/drivers/connector/connector.c 2004-09-24 00:01:00.0
> +void cn_netlink_send(struct cn_msg *msg, u32 __groups)
> +{
> + struct cn_callback_entry *n, *__cbq;
> + unsigned int size;
> + struct sk_buff *skb;
> + struct nlmsghdr *nlh;
> + struct cn_msg *data;
> + struct cn_dev *dev =
> + u32 groups = 0;
> + int found = 0;
> +
> + if (!__groups)
> + {
> + spin_lock(>cbdev->queue_lock);
> + list_for_each_entry_safe(__cbq, n, >cbdev->queue_list,
> callback_entry) {
>
> Same here
>
> + if (cn_cb_equal(&__cbq->cb->id, >id)) {
> + found = 1;
> + groups = __cbq->group;
> + }
> + }
> + spin_unlock(>cbdev->queue_lock);
> +
> + if (!found) {
> + printk(KERN_ERR "Failed to find multicast netlink
> group for callback[0x%x.0x%x]. seq=%u\n",
> + msg->id.idx, msg->id.val, msg->seq);
> + return;
> + }
> + }
> + else
> + groups = __groups;
> +
> + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> +
> + skb = alloc_skb(size, GFP_ATOMIC);
> + if (!skb) {
> + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
> size);
> + return;
> + }
> +
> + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh));
>
> This is not correct, what happens is:
> size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> --> align(hdr)+align(data)
> size - sizeof(*nlh)
> --> (align(hdr)-hdr)+align(data)
> NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
> --> align(hdr)+(align(hdr)-hdr)+align(data)
>
> At the moment align(hdr) == hdr since nlmsghdr is already aligned
> but this might change and your code will break.
As far as I remember, header is always supposed to be aligned properly
"by design", so it even could be nonaligned here.
--
Evgeniy Polyakov ( s0mbre )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.12-rc2-mm1
On Mon, Apr 11, 2005 at 01:00:53AM +0200, Pavel Machek wrote: > > No, XFS is my root filesystem. :( (Now that I think about it, would > > modularizing XFS and using an initrd be OK?) > > Yes, loading xfs from initrd should help. [At least it did during > suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I just noticed a difference between the kernel messages with XFS built-in and with it modularized. I'm having trouble putting my finger on it; it seems like the screen gets cleared at some point during resume, and with XFS built-in, it starts reading the data from swap *after* the screen gets cleared. In contrast, if the enable-initrd patch is removed or XFS is modularized, it reads in from swap *before* the screen gets cleared. Or something like that. I'll see if I can get anything more detailed & useful with a serial console... Failing that, I'll try a camcorder or digital camera and transcribe from that. -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
Hi! > > Can you try without XFS? > > No, XFS is my root filesystem. :( (Now that I think about it, would > modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] > I'll see if I can reproduce this on one of my test boxes. I'll *try* to > get to it later today, but it's possible that I won't be able to get to > it until next Friday or Saturday. > > > I do not why it interferes, but I've seen that before on suse > > kernels... > > Have you seen it without the resume-from-initrd patch too, or only with > that patch? Only with resume-from-initrd. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1
On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: > Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. > I do not why it interferes, but I've seen that before on suse > kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
Hi! > (Sorry I took so long to respond. I was busy with tons of stuff > offline...) > > On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: > > Do you have XFS compiled in, by chance? > > Yes. Can you try without XFS? I do not why it interferes, but I've seen that before on suse kernels... Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1
(Sorry I took so long to respond. I was busy with tons of stuff offline...) On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: > Do you have XFS compiled in, by chance? Yes. > You are not actually resuming from initrd, right? That is correct. -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
* jamal <[EMAIL PROTECTED]> 2005-04-10 10:39
> Please crosspost on netdev - you should know that by now;->
>
> I actually disagreee with Herbert on this. Theres definetely good
> need to have a more usable messaging system that rides on top of
> netlink. It is not that netlink cant be extended (I actually think thats
> a separate topic)
I find it quite easy already but I guess a few macros would improve
it even more. The routing attribute macros could be made generic to
so can benefit from the advanages of TLVs.
Evgeniy, Sorry for not having time earlier to give your patch a
review. I'm not yet through completely and won't comment on the
overall architecture until I have understood it all.
diff -Nru /tmp/empty/cn_queue.c linux-2.6/drivers/connector/cn_queue.c
--- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.0 +0300
+++ linux-2.6/drivers/connector/cn_queue.c 2004-09-24 00:01:00.0
+int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb)
+{
+ struct cn_callback_entry *cbq, *n, *__cbq;
+ int found = 0;
+
+ cbq = cn_queue_alloc_callback_entry(cb);
+ if (!cbq)
+ return -ENOMEM;
+
+ atomic_inc(>refcnt);
+ cbq->pdev = dev;
+
+ spin_lock(>queue_lock);
+ list_for_each_entry_safe(__cbq, n, >queue_list, callback_entry) {
Why _safe? There is no way a entry can be removed here.
+ if (cn_cb_equal(&__cbq->cb->id, >id)) {
+ found = 1;
+ break;
+ }
+ }
diff -Nru /tmp/empty/connector.c linux-2.6/drivers/connector/connector.c
--- /tmp/empty/connector.c 1970-01-01 03:00:00.0 +0300
+++ linux-2.6/drivers/connector/connector.c 2004-09-24 00:01:00.0
+void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+{
+ struct cn_callback_entry *n, *__cbq;
+ unsigned int size;
+ struct sk_buff *skb;
+ struct nlmsghdr *nlh;
+ struct cn_msg *data;
+ struct cn_dev *dev =
+ u32 groups = 0;
+ int found = 0;
+
+ if (!__groups)
+ {
+ spin_lock(>cbdev->queue_lock);
+ list_for_each_entry_safe(__cbq, n, >cbdev->queue_list,
callback_entry) {
Same here
+ if (cn_cb_equal(&__cbq->cb->id, >id)) {
+ found = 1;
+ groups = __cbq->group;
+ }
+ }
+ spin_unlock(>cbdev->queue_lock);
+
+ if (!found) {
+ printk(KERN_ERR "Failed to find multicast netlink group
for callback[0x%x.0x%x]. seq=%u\n",
+ msg->id.idx, msg->id.val, msg->seq);
+ return;
+ }
+ }
+ else
+ groups = __groups;
+
+ size = NLMSG_SPACE(sizeof(*msg) + msg->len);
+
+ skb = alloc_skb(size, GFP_ATOMIC);
+ if (!skb) {
+ printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
size);
+ return;
+ }
+
+ nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh));
This is not correct, what happens is:
size = NLMSG_SPACE(sizeof(*msg) + msg->len);
--> align(hdr)+align(data)
size - sizeof(*nlh)
--> (align(hdr)-hdr)+align(data)
NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
--> align(hdr)+(align(hdr)-hdr)+align(data)
At the moment align(hdr) == hdr since nlmsghdr is already aligned
but this might change and your code will break.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 2005-04-10 at 10:56, James Morris wrote: > On 10 Apr 2005, jamal wrote: > > > Thats what the original motivation for konnector was. To make it easy > > for joe dumbass. > > Who you really want writing kernel code :-) Ok, let me take that back then ;-> The value is in allowing people who are kernel hackers that are trying to focus on an entirely different problem to not really know much about the internals of the messaging subsystem (if you wanna call netlink that). A good example will be the fork patches which were posted recently. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On 10 Apr 2005, jamal wrote: > Thats what the original motivation for konnector was. To make it easy > for joe dumbass. Who you really want writing kernel code :-) - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
Evgeniy, Please crosspost on netdev - you should know that by now;-> I actually disagreee with Herbert on this. Theres definetely good need to have a more usable messaging system that rides on top of netlink. It is not that netlink cant be extended (I actually think thats a separate topic) - its just that its usability curve is too high. Thats what the original motivation for konnector was. To make it easy for joe dumbass. And i think if konnector sticks to just doing that it will end up being valuable. I do think (and ive said this before) that Evgeniy is pushing it by going beyond this simple agenda/focus. Unfortunately, I actually dont think he is listening _at all_ on this specific issue. Evgeniy, just stick to the original focus and if it is accepted and understood then lets move on to adding new features. Otherwise the result of you adding yet one more feature for CBUS or whatever is clearly to question what the original motivation was. And i dont think you are able to add any other points to justify the existence of any new konnector feature other than describe the original goals. At least thats what i saw reading this thread. Otherwise if you really dont know what you want yet lets just pull this whole thing out IMO. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 10 Apr 2005 14:10:05 +0200
Thomas Graf <[EMAIL PROTECTED]> wrote:
> * Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-10 15:37
> > --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
> > +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
> > @@ -747,7 +747,7 @@
> > if (p->exclude_sk == sk)
> > goto out;
> >
> > - if (nlk->pid == p->pid || !(nlk->groups & p->group))
> > + if (nlk->pid == p->pid || (nlk->groups != p->group))
> > goto out;
> >
> > if (p->failure) {
>
> Not valid, would break RTMGRP_*.
Yes, it will break too many existing application,
it would be new API, like do_one_broadcast_direct().
If I understand Kay right, it is what he needs
for the new multicast.
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
* Evgeniy Polyakov <[EMAIL PROTECTED]> 2005-04-10 15:37
> --- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
> +++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
> @@ -747,7 +747,7 @@
> if (p->exclude_sk == sk)
> goto out;
>
> - if (nlk->pid == p->pid || !(nlk->groups & p->group))
> + if (nlk->pid == p->pid || (nlk->groups != p->group))
> goto out;
>
> if (p->failure) {
Not valid, would break RTMGRP_*.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 10 Apr 2005 15:37:57 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > The second one is a huge monster that can not be used in embedded > systems, calling userspace process from inside the kernel is > now very flexible way. is NOT very flexible way... Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 10 Apr 2005 13:08:44 +0200 Kay Sievers <[EMAIL PROTECTED]> wrote: > On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote: > > On Sun, 10 Apr 2005 19:52:54 +1000 > > Herbert Xu <[EMAIL PROTECTED]> wrote: > > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > > > > User should not know about low-level transport - > > > > it is like socket layer - write only data and do not care about > > > > how it will be delivered. > > > > > > The delineation between transport and upper layer is fuzzy. > > > In one situation the protocol might be transport and in another > > > it could be above the transport. > > > > > > So I don't buy this argument. > > > > Connector allows to hide transport layer completely - > > concider acrypto or superio - that subsystems do not know > > about network, author of the temperature driver for superio > > should not know how skb is allocated and processed, > > and acrypto is not network related system, so why > > they should know about network API? > > Why should they know what is skb, how it is allocated, > > why shared skb can not be used in netlink and so on? > > Users of the connector are only cared about > > destination ID and how to send/receive message. > > And what to do if we do not want something like connector > > to be used for userspace control - we need to create > > each time new netlink socket unit, like kobject's one, > > or netlink_ulog, we need to register it in netlink.h, > > where already there too many units. > > > > > > In the previous versions netlink group was assigned as incremented > > > > counter, > > > > that was not convenient, but now we have 2-way ID, which is better > > > > from users point of view - idx is supposed to be major id, val - > > > > some subsystem of that set. > > > > > > Actually netlink does let you bind to a specific ID. > > > > > > Of course you may argue that a single u32 is not enough. However, > > > nothing is stopping you from introducing netlink v2 that extends > > > this. > > > > > > In fact this is my main gripe with your patch: Why aren't you > > > extending netlink instead of hacking something on top of the existing > > > netlink? If the extensions require breaking compatibility: Fine, > > > you just need to call it netlink v2. > > > > When connector was created in the middle of 2004, it's main aim > > was allowing easy userspace control over netlink. > > Creating it's own skb receive parser was acceptible for > > one project, for two, but it is definitely not the solution > > for general use. And also I think it is not so easy to include new > > netlink family unit for some completely unrelated to network subsystem. > > > > So I decided to create only one skb parser, and put all skb processing > > in one place, so any user has to do only registration with it's > > own receive callback, and sending function. > > Sure, but that would apply the a generic netlink extension too, right? Sending is the only and not the most significant part of the connector. Of course cn_netlink_send() can be split into prepare_send() and commit_send(), where commit_send() will live in af_netlink.c and do allocation and so on. But it will not change the fact, that kernel users still need to allocate a netlink socket, register it's own family unit, and so on... Direct netlink usage is like using raw socket or even tun/tap device for TCP/IP, noone use it in that way, although we can, but connector is like using socket interface. > > Thus, transport layer was completely hidden from connector users, > > there are no complex netlink macros there, no network API > > and all complex related issues, no huge code duplication in each device, > > which does not want to mess with 32/64 ioctl issues, but > > want easy userspace control. > > I don't see the need for unimplemented abstractions here. You can > replace a generic netlink-use just the same way as you can replace the > connector's own netlink code below the connector API. There is not much > difference. Kernel users do not want to implement it's own transport over netlink. Socket allocation was changed in 2.5 - we could need to change each driver that use it instead of changing only one place in connector.c Abstration over netlink already implemented in connector and is used in acrypto, superio and even kobject_uevent was changed to do it. > > Later connector was changed a bit to allow easy notification > > ability and new bus was added. > > Connector is the solution for d-bus related projects, since > > all control is in one place, there are destination ID, > > there is no complex API. > > Sorry, what does this have to do with DBUS? Kernel now has only two ways to inform to userspace about it's things - kobject [uevent] and hotplug. There is inotify/dnotify too, but it is diferent in some way. The second one is a huge monster that can not be used in embedded systems, calling userspace process from inside the kernel is now very flexible way. The first
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote: > On Sun, 10 Apr 2005 19:52:54 +1000 > Herbert Xu <[EMAIL PROTECTED]> wrote: > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > > User should not know about low-level transport - > > > it is like socket layer - write only data and do not care about > > > how it will be delivered. > > > > The delineation between transport and upper layer is fuzzy. > > In one situation the protocol might be transport and in another > > it could be above the transport. > > > > So I don't buy this argument. > > Connector allows to hide transport layer completely - > concider acrypto or superio - that subsystems do not know > about network, author of the temperature driver for superio > should not know how skb is allocated and processed, > and acrypto is not network related system, so why > they should know about network API? > Why should they know what is skb, how it is allocated, > why shared skb can not be used in netlink and so on? > Users of the connector are only cared about > destination ID and how to send/receive message. > And what to do if we do not want something like connector > to be used for userspace control - we need to create > each time new netlink socket unit, like kobject's one, > or netlink_ulog, we need to register it in netlink.h, > where already there too many units. > > > > In the previous versions netlink group was assigned as incremented > > > counter, > > > that was not convenient, but now we have 2-way ID, which is better > > > from users point of view - idx is supposed to be major id, val - > > > some subsystem of that set. > > > > Actually netlink does let you bind to a specific ID. > > > > Of course you may argue that a single u32 is not enough. However, > > nothing is stopping you from introducing netlink v2 that extends > > this. > > > > In fact this is my main gripe with your patch: Why aren't you > > extending netlink instead of hacking something on top of the existing > > netlink? If the extensions require breaking compatibility: Fine, > > you just need to call it netlink v2. > > When connector was created in the middle of 2004, it's main aim > was allowing easy userspace control over netlink. > Creating it's own skb receive parser was acceptible for > one project, for two, but it is definitely not the solution > for general use. And also I think it is not so easy to include new > netlink family unit for some completely unrelated to network subsystem. > > So I decided to create only one skb parser, and put all skb processing > in one place, so any user has to do only registration with it's > own receive callback, and sending function. Sure, but that would apply the a generic netlink extension too, right? > Thus, transport layer was completely hidden from connector users, > there are no complex netlink macros there, no network API > and all complex related issues, no huge code duplication in each device, > which does not want to mess with 32/64 ioctl issues, but > want easy userspace control. I don't see the need for unimplemented abstractions here. You can replace a generic netlink-use just the same way as you can replace the connector's own netlink code below the connector API. There is not much difference. > Later connector was changed a bit to allow easy notification > ability and new bus was added. > Connector is the solution for d-bus related projects, since > all control is in one place, there are destination ID, > there is no complex API. Sorry, what does this have to do with DBUS? > Concider the latest xfrm event changes - good that we already > have netlink socket there, but in each sending function > [there are at least three new] > we have all those skb_alloc, skb_put, NLMSG_* and so on which are > absolutely identical. > According to names and structures itself, they are too close > to what connector is for, and how it is implemented, so we already > have several connectors in the tree, and do we really want > to proceed with it all over the place? That's not the point. Nobody asks to replace the whole connector by raw netlink. But the message subscription and multicasting could be part of the generic netlink framework. The connector API would still be on-top if it and nothing changes besides that we would have a nice low-level api to use for other systems too. The basic idea behind the connector as a nice generic framework for netlink, as it fills the missing multicast case, while we already can do singlecast and broadcast with netlink. It is just the same way the kernel plays with other core functionality too. If something is not represented in the vfs-layer your are asked to add it to the generic part and not implement it privately for your filesystem only. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 10 Apr 2005 19:52:54 +1000
Herbert Xu <[EMAIL PROTECTED]> wrote:
> Please add netdev to the CC list since this discussion pertains to
> the networking subsystem.
>
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > User should not know about low-level transport -
> > it is like socket layer - write only data and do not care about
> > how it will be delivered.
>
> The delineation between transport and upper layer is fuzzy.
> In one situation the protocol might be transport and in another
> it could be above the transport.
>
> So I don't buy this argument.
Connector allows to hide transport layer completely -
concider acrypto or superio - that subsystems do not know
about network, author of the temperature driver for superio
should not know how skb is allocated and processed,
and acrypto is not network related system, so why
they should know about network API?
Why should they know what is skb, how it is allocated,
why shared skb can not be used in netlink and so on?
Users of the connector are only cared about
destination ID and how to send/receive message.
And what to do if we do not want something like connector
to be used for userspace control - we need to create
each time new netlink socket unit, like kobject's one,
or netlink_ulog, we need to register it in netlink.h,
where already there too many units.
> > In the previous versions netlink group was assigned as incremented
> > counter,
> > that was not convenient, but now we have 2-way ID, which is better
> > from users point of view - idx is supposed to be major id, val -
> > some subsystem of that set.
>
> Actually netlink does let you bind to a specific ID.
>
> Of course you may argue that a single u32 is not enough. However,
> nothing is stopping you from introducing netlink v2 that extends
> this.
>
> In fact this is my main gripe with your patch: Why aren't you
> extending netlink instead of hacking something on top of the existing
> netlink? If the extensions require breaking compatibility: Fine,
> you just need to call it netlink v2.
When connector was created in the middle of 2004, it's main aim
was allowing easy userspace control over netlink.
Creating it's own skb receive parser was acceptible for
one project, for two, but it is definitely not the solution
for general use. And also I think it is not so easy to include new
netlink family unit for some completely unrelated to network subsystem.
So I decided to create only one skb parser, and put all skb processing
in one place, so any user has to do only registration with it's
own receive callback, and sending function.
Thus, transport layer was completely hidden from connector users,
there are no complex netlink macros there, no network API
and all complex related issues, no huge code duplication in each device,
which does not want to mess with 32/64 ioctl issues, but
want easy userspace control.
Later connector was changed a bit to allow easy notification
ability and new bus was added.
Connector is the solution for d-bus related projects, since
all control is in one place, there are destination ID,
there is no complex API.
Concider the latest xfrm event changes - good that we already
have netlink socket there, but in each sending function
[there are at least three new]
we have all those skb_alloc, skb_put, NLMSG_* and so on which are
absolutely identical.
According to names and structures itself, they are too close
to what connector is for, and how it is implemented, so we already
have several connectors in the tree, and do we really want
to proceed with it all over the place?
> 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
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
Please add netdev to the CC list since this discussion pertains to
the networking subsystem.
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> User should not know about low-level transport -
> it is like socket layer - write only data and do not care about
> how it will be delivered.
The delineation between transport and upper layer is fuzzy.
In one situation the protocol might be transport and in another
it could be above the transport.
So I don't buy this argument.
> In the previous versions netlink group was assigned as incremented
> counter,
> that was not convenient, but now we have 2-way ID, which is better
> from users point of view - idx is supposed to be major id, val -
> some subsystem of that set.
Actually netlink does let you bind to a specific ID.
Of course you may argue that a single u32 is not enough. However,
nothing is stopping you from introducing netlink v2 that extends
this.
In fact this is my main gripe with your patch: Why aren't you
extending netlink instead of hacking something on top of the existing
netlink? If the extensions require breaking compatibility: Fine,
you just need to call it netlink v2.
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
Please add netdev to the CC list since this discussion pertains to
the networking subsystem.
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
User should not know about low-level transport -
it is like socket layer - write only data and do not care about
how it will be delivered.
The delineation between transport and upper layer is fuzzy.
In one situation the protocol might be transport and in another
it could be above the transport.
So I don't buy this argument.
In the previous versions netlink group was assigned as incremented
counter,
that was not convenient, but now we have 2-way ID, which is better
from users point of view - idx is supposed to be major id, val -
some subsystem of that set.
Actually netlink does let you bind to a specific ID.
Of course you may argue that a single u32 is not enough. However,
nothing is stopping you from introducing netlink v2 that extends
this.
In fact this is my main gripe with your patch: Why aren't you
extending netlink instead of hacking something on top of the existing
netlink? If the extensions require breaking compatibility: Fine,
you just need to call it netlink v2.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 10 Apr 2005 19:52:54 +1000
Herbert Xu [EMAIL PROTECTED] wrote:
Please add netdev to the CC list since this discussion pertains to
the networking subsystem.
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
User should not know about low-level transport -
it is like socket layer - write only data and do not care about
how it will be delivered.
The delineation between transport and upper layer is fuzzy.
In one situation the protocol might be transport and in another
it could be above the transport.
So I don't buy this argument.
Connector allows to hide transport layer completely -
concider acrypto or superio - that subsystems do not know
about network, author of the temperature driver for superio
should not know how skb is allocated and processed,
and acrypto is not network related system, so why
they should know about network API?
Why should they know what is skb, how it is allocated,
why shared skb can not be used in netlink and so on?
Users of the connector are only cared about
destination ID and how to send/receive message.
And what to do if we do not want something like connector
to be used for userspace control - we need to create
each time new netlink socket unit, like kobject's one,
or netlink_ulog, we need to register it in netlink.h,
where already there too many units.
In the previous versions netlink group was assigned as incremented
counter,
that was not convenient, but now we have 2-way ID, which is better
from users point of view - idx is supposed to be major id, val -
some subsystem of that set.
Actually netlink does let you bind to a specific ID.
Of course you may argue that a single u32 is not enough. However,
nothing is stopping you from introducing netlink v2 that extends
this.
In fact this is my main gripe with your patch: Why aren't you
extending netlink instead of hacking something on top of the existing
netlink? If the extensions require breaking compatibility: Fine,
you just need to call it netlink v2.
When connector was created in the middle of 2004, it's main aim
was allowing easy userspace control over netlink.
Creating it's own skb receive parser was acceptible for
one project, for two, but it is definitely not the solution
for general use. And also I think it is not so easy to include new
netlink family unit for some completely unrelated to network subsystem.
So I decided to create only one skb parser, and put all skb processing
in one place, so any user has to do only registration with it's
own receive callback, and sending function.
Thus, transport layer was completely hidden from connector users,
there are no complex netlink macros there, no network API
and all complex related issues, no huge code duplication in each device,
which does not want to mess with 32/64 ioctl issues, but
want easy userspace control.
Later connector was changed a bit to allow easy notification
ability and new bus was added.
Connector is the solution for d-bus related projects, since
all control is in one place, there are destination ID,
there is no complex API.
Concider the latest xfrm event changes - good that we already
have netlink socket there, but in each sending function
[there are at least three new]
we have all those skb_alloc, skb_put, NLMSG_* and so on which are
absolutely identical.
According to names and structures itself, they are too close
to what connector is for, and how it is implemented, so we already
have several connectors in the tree, and do we really want
to proceed with it all over the place?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmVHI~} [EMAIL PROTECTED]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote: On Sun, 10 Apr 2005 19:52:54 +1000 Herbert Xu [EMAIL PROTECTED] wrote: Evgeniy Polyakov [EMAIL PROTECTED] wrote: User should not know about low-level transport - it is like socket layer - write only data and do not care about how it will be delivered. The delineation between transport and upper layer is fuzzy. In one situation the protocol might be transport and in another it could be above the transport. So I don't buy this argument. Connector allows to hide transport layer completely - concider acrypto or superio - that subsystems do not know about network, author of the temperature driver for superio should not know how skb is allocated and processed, and acrypto is not network related system, so why they should know about network API? Why should they know what is skb, how it is allocated, why shared skb can not be used in netlink and so on? Users of the connector are only cared about destination ID and how to send/receive message. And what to do if we do not want something like connector to be used for userspace control - we need to create each time new netlink socket unit, like kobject's one, or netlink_ulog, we need to register it in netlink.h, where already there too many units. In the previous versions netlink group was assigned as incremented counter, that was not convenient, but now we have 2-way ID, which is better from users point of view - idx is supposed to be major id, val - some subsystem of that set. Actually netlink does let you bind to a specific ID. Of course you may argue that a single u32 is not enough. However, nothing is stopping you from introducing netlink v2 that extends this. In fact this is my main gripe with your patch: Why aren't you extending netlink instead of hacking something on top of the existing netlink? If the extensions require breaking compatibility: Fine, you just need to call it netlink v2. When connector was created in the middle of 2004, it's main aim was allowing easy userspace control over netlink. Creating it's own skb receive parser was acceptible for one project, for two, but it is definitely not the solution for general use. And also I think it is not so easy to include new netlink family unit for some completely unrelated to network subsystem. So I decided to create only one skb parser, and put all skb processing in one place, so any user has to do only registration with it's own receive callback, and sending function. Sure, but that would apply the a generic netlink extension too, right? Thus, transport layer was completely hidden from connector users, there are no complex netlink macros there, no network API and all complex related issues, no huge code duplication in each device, which does not want to mess with 32/64 ioctl issues, but want easy userspace control. I don't see the need for unimplemented abstractions here. You can replace a generic netlink-use just the same way as you can replace the connector's own netlink code below the connector API. There is not much difference. Later connector was changed a bit to allow easy notification ability and new bus was added. Connector is the solution for d-bus related projects, since all control is in one place, there are destination ID, there is no complex API. Sorry, what does this have to do with DBUS? Concider the latest xfrm event changes - good that we already have netlink socket there, but in each sending function [there are at least three new] we have all those skb_alloc, skb_put, NLMSG_* and so on which are absolutely identical. According to names and structures itself, they are too close to what connector is for, and how it is implemented, so we already have several connectors in the tree, and do we really want to proceed with it all over the place? That's not the point. Nobody asks to replace the whole connector by raw netlink. But the message subscription and multicasting could be part of the generic netlink framework. The connector API would still be on-top if it and nothing changes besides that we would have a nice low-level api to use for other systems too. The basic idea behind the connector as a nice generic framework for netlink, as it fills the missing multicast case, while we already can do singlecast and broadcast with netlink. It is just the same way the kernel plays with other core functionality too. If something is not represented in the vfs-layer your are asked to add it to the generic part and not implement it privately for your filesystem only. Thanks, Kay - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 10 Apr 2005 13:08:44 +0200 Kay Sievers [EMAIL PROTECTED] wrote: On Sun, 2005-04-10 at 14:32 +0400, Evgeniy Polyakov wrote: On Sun, 10 Apr 2005 19:52:54 +1000 Herbert Xu [EMAIL PROTECTED] wrote: Evgeniy Polyakov [EMAIL PROTECTED] wrote: User should not know about low-level transport - it is like socket layer - write only data and do not care about how it will be delivered. The delineation between transport and upper layer is fuzzy. In one situation the protocol might be transport and in another it could be above the transport. So I don't buy this argument. Connector allows to hide transport layer completely - concider acrypto or superio - that subsystems do not know about network, author of the temperature driver for superio should not know how skb is allocated and processed, and acrypto is not network related system, so why they should know about network API? Why should they know what is skb, how it is allocated, why shared skb can not be used in netlink and so on? Users of the connector are only cared about destination ID and how to send/receive message. And what to do if we do not want something like connector to be used for userspace control - we need to create each time new netlink socket unit, like kobject's one, or netlink_ulog, we need to register it in netlink.h, where already there too many units. In the previous versions netlink group was assigned as incremented counter, that was not convenient, but now we have 2-way ID, which is better from users point of view - idx is supposed to be major id, val - some subsystem of that set. Actually netlink does let you bind to a specific ID. Of course you may argue that a single u32 is not enough. However, nothing is stopping you from introducing netlink v2 that extends this. In fact this is my main gripe with your patch: Why aren't you extending netlink instead of hacking something on top of the existing netlink? If the extensions require breaking compatibility: Fine, you just need to call it netlink v2. When connector was created in the middle of 2004, it's main aim was allowing easy userspace control over netlink. Creating it's own skb receive parser was acceptible for one project, for two, but it is definitely not the solution for general use. And also I think it is not so easy to include new netlink family unit for some completely unrelated to network subsystem. So I decided to create only one skb parser, and put all skb processing in one place, so any user has to do only registration with it's own receive callback, and sending function. Sure, but that would apply the a generic netlink extension too, right? Sending is the only and not the most significant part of the connector. Of course cn_netlink_send() can be split into prepare_send() and commit_send(), where commit_send() will live in af_netlink.c and do allocation and so on. But it will not change the fact, that kernel users still need to allocate a netlink socket, register it's own family unit, and so on... Direct netlink usage is like using raw socket or even tun/tap device for TCP/IP, noone use it in that way, although we can, but connector is like using socket interface. Thus, transport layer was completely hidden from connector users, there are no complex netlink macros there, no network API and all complex related issues, no huge code duplication in each device, which does not want to mess with 32/64 ioctl issues, but want easy userspace control. I don't see the need for unimplemented abstractions here. You can replace a generic netlink-use just the same way as you can replace the connector's own netlink code below the connector API. There is not much difference. Kernel users do not want to implement it's own transport over netlink. Socket allocation was changed in 2.5 - we could need to change each driver that use it instead of changing only one place in connector.c Abstration over netlink already implemented in connector and is used in acrypto, superio and even kobject_uevent was changed to do it. Later connector was changed a bit to allow easy notification ability and new bus was added. Connector is the solution for d-bus related projects, since all control is in one place, there are destination ID, there is no complex API. Sorry, what does this have to do with DBUS? Kernel now has only two ways to inform to userspace about it's things - kobject [uevent] and hotplug. There is inotify/dnotify too, but it is diferent in some way. The second one is a huge monster that can not be used in embedded systems, calling userspace process from inside the kernel is now very flexible way. The first one has it's own socket, it's own protocol and infrastructure based on strings. What if we want to inform about some new event? Should we use kobject_uevent mechanism? Not anything can
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 10 Apr 2005 15:37:57 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: The second one is a huge monster that can not be used in embedded systems, calling userspace process from inside the kernel is now very flexible way. is NOT very flexible way... Evgeniy Polyakov Only failure makes us experts. -- Theo de Raadt - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-10 15:37
--- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
+++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
@@ -747,7 +747,7 @@
if (p-exclude_sk == sk)
goto out;
- if (nlk-pid == p-pid || !(nlk-groups p-group))
+ if (nlk-pid == p-pid || (nlk-groups != p-group))
goto out;
if (p-failure) {
Not valid, would break RTMGRP_*.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 10 Apr 2005 14:10:05 +0200
Thomas Graf [EMAIL PROTECTED] wrote:
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-04-10 15:37
--- ./net/netlink/af_netlink.c.orig 2005-04-10 15:46:48.0 +0400
+++ ./net/netlink/af_netlink.c 2005-04-10 15:47:04.0 +0400
@@ -747,7 +747,7 @@
if (p-exclude_sk == sk)
goto out;
- if (nlk-pid == p-pid || !(nlk-groups p-group))
+ if (nlk-pid == p-pid || (nlk-groups != p-group))
goto out;
if (p-failure) {
Not valid, would break RTMGRP_*.
Yes, it will break too many existing application,
it would be new API, like do_one_broadcast_direct().
If I understand Kay right, it is what he needs
for the new multicast.
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
Evgeniy, Please crosspost on netdev - you should know that by now;- I actually disagreee with Herbert on this. Theres definetely good need to have a more usable messaging system that rides on top of netlink. It is not that netlink cant be extended (I actually think thats a separate topic) - its just that its usability curve is too high. Thats what the original motivation for konnector was. To make it easy for joe dumbass. And i think if konnector sticks to just doing that it will end up being valuable. I do think (and ive said this before) that Evgeniy is pushing it by going beyond this simple agenda/focus. Unfortunately, I actually dont think he is listening _at all_ on this specific issue. Evgeniy, just stick to the original focus and if it is accepted and understood then lets move on to adding new features. Otherwise the result of you adding yet one more feature for CBUS or whatever is clearly to question what the original motivation was. And i dont think you are able to add any other points to justify the existence of any new konnector feature other than describe the original goals. At least thats what i saw reading this thread. Otherwise if you really dont know what you want yet lets just pull this whole thing out IMO. cheers, jamal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On 10 Apr 2005, jamal wrote: Thats what the original motivation for konnector was. To make it easy for joe dumbass. Who you really want writing kernel code :-) - James -- James Morris [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, 2005-04-10 at 10:56, James Morris wrote: On 10 Apr 2005, jamal wrote: Thats what the original motivation for konnector was. To make it easy for joe dumbass. Who you really want writing kernel code :-) Ok, let me take that back then ;- The value is in allowing people who are kernel hackers that are trying to focus on an entirely different problem to not really know much about the internals of the messaging subsystem (if you wanna call netlink that). A good example will be the fork patches which were posted recently. cheers, jamal - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
* jamal [EMAIL PROTECTED] 2005-04-10 10:39
Please crosspost on netdev - you should know that by now;-
I actually disagreee with Herbert on this. Theres definetely good
need to have a more usable messaging system that rides on top of
netlink. It is not that netlink cant be extended (I actually think thats
a separate topic)
I find it quite easy already but I guess a few macros would improve
it even more. The routing attribute macros could be made generic to
so can benefit from the advanages of TLVs.
Evgeniy, Sorry for not having time earlier to give your patch a
review. I'm not yet through completely and won't comment on the
overall architecture until I have understood it all.
diff -Nru /tmp/empty/cn_queue.c linux-2.6/drivers/connector/cn_queue.c
--- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.0 +0300
+++ linux-2.6/drivers/connector/cn_queue.c 2004-09-24 00:01:00.0
+int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb)
+{
+ struct cn_callback_entry *cbq, *n, *__cbq;
+ int found = 0;
+
+ cbq = cn_queue_alloc_callback_entry(cb);
+ if (!cbq)
+ return -ENOMEM;
+
+ atomic_inc(dev-refcnt);
+ cbq-pdev = dev;
+
+ spin_lock(dev-queue_lock);
+ list_for_each_entry_safe(__cbq, n, dev-queue_list, callback_entry) {
Why _safe? There is no way a entry can be removed here.
+ if (cn_cb_equal(__cbq-cb-id, cb-id)) {
+ found = 1;
+ break;
+ }
+ }
diff -Nru /tmp/empty/connector.c linux-2.6/drivers/connector/connector.c
--- /tmp/empty/connector.c 1970-01-01 03:00:00.0 +0300
+++ linux-2.6/drivers/connector/connector.c 2004-09-24 00:01:00.0
+void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+{
+ struct cn_callback_entry *n, *__cbq;
+ unsigned int size;
+ struct sk_buff *skb;
+ struct nlmsghdr *nlh;
+ struct cn_msg *data;
+ struct cn_dev *dev = cdev;
+ u32 groups = 0;
+ int found = 0;
+
+ if (!__groups)
+ {
+ spin_lock(dev-cbdev-queue_lock);
+ list_for_each_entry_safe(__cbq, n, dev-cbdev-queue_list,
callback_entry) {
Same here
+ if (cn_cb_equal(__cbq-cb-id, msg-id)) {
+ found = 1;
+ groups = __cbq-group;
+ }
+ }
+ spin_unlock(dev-cbdev-queue_lock);
+
+ if (!found) {
+ printk(KERN_ERR Failed to find multicast netlink group
for callback[0x%x.0x%x]. seq=%u\n,
+ msg-id.idx, msg-id.val, msg-seq);
+ return;
+ }
+ }
+ else
+ groups = __groups;
+
+ size = NLMSG_SPACE(sizeof(*msg) + msg-len);
+
+ skb = alloc_skb(size, GFP_ATOMIC);
+ if (!skb) {
+ printk(KERN_ERR Failed to allocate new skb with size=%u.\n,
size);
+ return;
+ }
+
+ nlh = NLMSG_PUT(skb, 0, msg-seq, NLMSG_DONE, size - sizeof(*nlh));
This is not correct, what happens is:
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-- align(hdr)+align(data)
size - sizeof(*nlh)
-- (align(hdr)-hdr)+align(data)
NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
-- align(hdr)+(align(hdr)-hdr)+align(data)
At the moment align(hdr) == hdr since nlmsghdr is already aligned
but this might change and your code will break.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
(Sorry I took so long to respond. I was busy with tons of stuff offline...) On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: Do you have XFS compiled in, by chance? Yes. You are not actually resuming from initrd, right? That is correct. -Barry K. Nathan [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
Hi! (Sorry I took so long to respond. I was busy with tons of stuff offline...) On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: Do you have XFS compiled in, by chance? Yes. Can you try without XFS? I do not why it interferes, but I've seen that before on suse kernels... Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.12-rc2-mm1
On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. I do not why it interferes, but I've seen that before on suse kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? -Barry K. Nathan [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
Hi! Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. I do not why it interferes, but I've seen that before on suse kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? Only with resume-from-initrd. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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.12-rc2-mm1
On Mon, Apr 11, 2005 at 01:00:53AM +0200, Pavel Machek wrote: No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I just noticed a difference between the kernel messages with XFS built-in and with it modularized. I'm having trouble putting my finger on it; it seems like the screen gets cleared at some point during resume, and with XFS built-in, it starts reading the data from swap *after* the screen gets cleared. In contrast, if the enable-initrd patch is removed or XFS is modularized, it reads in from swap *before* the screen gets cleared. Or something like that. I'll see if I can get anything more detailed useful with a serial console... Failing that, I'll try a camcorder or digital camera and transcribe from that. -Barry K. Nathan [EMAIL PROTECTED] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
* jamal [EMAIL PROTECTED] 2005-04-10 10:39
Please crosspost on netdev - you should know that by now;-
I actually disagreee with Herbert on this. Theres definetely good
need to have a more usable messaging system that rides on top of
netlink. It is not that netlink cant be extended (I actually think thats
a separate topic)
I find it quite easy already but I guess a few macros would improve
it even more. The routing attribute macros could be made generic to
so can benefit from the advanages of TLVs.
Evgeniy, Sorry for not having time earlier to give your patch a
review. I'm not yet through completely and won't comment on the
overall architecture until I have understood it all.
diff -Nru /tmp/empty/cn_queue.c linux-2.6/drivers/connector/cn_queue.c
--- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.0 +0300
+++ linux-2.6/drivers/connector/cn_queue.c 2004-09-24 00:01:00.0
+int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb)
+{
+ struct cn_callback_entry *cbq, *n, *__cbq;
+ int found = 0;
+
+ cbq = cn_queue_alloc_callback_entry(cb);
+ if (!cbq)
+ return -ENOMEM;
+
+ atomic_inc(dev-refcnt);
+ cbq-pdev = dev;
+
+ spin_lock(dev-queue_lock);
+ list_for_each_entry_safe(__cbq, n, dev-queue_list, callback_entry) {
Why _safe? There is no way a entry can be removed here.
No particular reason - it easier to copy-paste it from other line :)
+ if (cn_cb_equal(__cbq-cb-id, cb-id)) {
+ found = 1;
+ break;
+ }
+ }
diff -Nru /tmp/empty/connector.c linux-2.6/drivers/connector/connector.c
--- /tmp/empty/connector.c 1970-01-01 03:00:00.0 +0300
+++ linux-2.6/drivers/connector/connector.c 2004-09-24 00:01:00.0
+void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+{
+ struct cn_callback_entry *n, *__cbq;
+ unsigned int size;
+ struct sk_buff *skb;
+ struct nlmsghdr *nlh;
+ struct cn_msg *data;
+ struct cn_dev *dev = cdev;
+ u32 groups = 0;
+ int found = 0;
+
+ if (!__groups)
+ {
+ spin_lock(dev-cbdev-queue_lock);
+ list_for_each_entry_safe(__cbq, n, dev-cbdev-queue_list,
callback_entry) {
Same here
+ if (cn_cb_equal(__cbq-cb-id, msg-id)) {
+ found = 1;
+ groups = __cbq-group;
+ }
+ }
+ spin_unlock(dev-cbdev-queue_lock);
+
+ if (!found) {
+ printk(KERN_ERR Failed to find multicast netlink
group for callback[0x%x.0x%x]. seq=%u\n,
+ msg-id.idx, msg-id.val, msg-seq);
+ return;
+ }
+ }
+ else
+ groups = __groups;
+
+ size = NLMSG_SPACE(sizeof(*msg) + msg-len);
+
+ skb = alloc_skb(size, GFP_ATOMIC);
+ if (!skb) {
+ printk(KERN_ERR Failed to allocate new skb with size=%u.\n,
size);
+ return;
+ }
+
+ nlh = NLMSG_PUT(skb, 0, msg-seq, NLMSG_DONE, size - sizeof(*nlh));
This is not correct, what happens is:
size = NLMSG_SPACE(sizeof(*msg) + msg-len);
-- align(hdr)+align(data)
size - sizeof(*nlh)
-- (align(hdr)-hdr)+align(data)
NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
-- align(hdr)+(align(hdr)-hdr)+align(data)
At the moment align(hdr) == hdr since nlmsghdr is already aligned
but this might change and your code will break.
As far as I remember, header is always supposed to be aligned properly
by design, so it even could be nonaligned here.
--
Evgeniy Polyakov ( s0mbre )
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, Apr 07, 2005 at 11:02:22PM -0700, David S. Miller wrote: > On Fri, 08 Apr 2005 09:19:39 +0400 > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > I know, the same thing holds for most architectures, including i386. > > > However, this is not an issue for uni-processor kernels anywhere else, > > > so what's so special about MIPS? > > > > Does i386 or ppc has cached and uncached memory? > > Yes, they do. > > > No, i386, ppc and others do not require sync on uncached memory access, > > and only instruction not data cache sync on SMP. > > On MIPS, all the MIPS atomic operations will operate on cached memory. > And as far as a uniprocessor cpu is concerned, updating the cache is > all that matters. > > In fact, this SYNC instruction seems unnecessary even on SMP. If the > cache is updated, it is part of the coherent memory space and thus > MOESI main bus SMP cache coherency transactions will see the update > value. When another processor does a "read-to-share" or "read-to-own" > request on the main bus, the processor which did the atomic OP will > provide the correct data from it's cache in response to that transaction. > > So what you have to do is show me an example where the MIPS kernel can > do an atomic.h operation on uncached memory. I even think that is > invalid, come to think of it. It better be... My impression is that the MIPS story isn't so simple, because the architecture only offers very weak coherency guarantees. Most of the SMP implementations offer strong coherency in practice, but at least one (RM9000) doesn't. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1
Hi! > > > Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the > > > problem goes away if I remove this patch: > > > swsusp-enable-resume-from-initrd.patch > > > > That really helps, thanks. > > You're welcome. > > > The patch looks fairly innocent. I'll give up on this and cc the > > developers. > > Yeah, it *seemed* innocent enough -- that's why I had to do a binary > search on the 2.6.11-mm3 "series" file in order to find it as the > culprit... Do you have XFS compiled in, by chance? You are not actually resuming from initrd, right? Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 01:55 -0400, James Morris wrote: > On Fri, 8 Apr 2005, Evgeniy Polyakov wrote: > > > > > Sure, but seems I need to ask again: What is the exact reason not to > > > > implement > > > > the muticast message multiplexing/subscription part of the connector as > > > > a > > > > generic part of netlink? That would be nice to have and useful for other > > > > subsystems too as an option to the current broadcast. > > > > > > This is a good point, in general, consider generically extending Netlink > > > itself instead of creating these separate things. > > > > > Connector requires it's own registration technique for > > 1. hide all transport [netlink] layer from higher protocols which use > > connector > > Why? User should not know about low-level transport - it is like socket layer - write only data and do not care about how it will be delivered. > > 2. create different group appointment for the given connector's ID > > [it was different, now new group which is eqal to idx field is appointed > > to > > the new callback] > > I don't understand. In the previous versions netlink group was assigned as incremented counter, that was not convenient, but now we have 2-way ID, which is better from users point of view - idx is supposed to be major id, val - some subsystem of that set. > > 3. provide more generic set of ids > > What do you mean by "ids"? Each connector message requires pair of u32 ids - idx and val. Idx is generic system id [which is equal to the appropriate netlink group in current implementation], while val is id of some subsytem inside idx. Using only group without it's own connector's id will heavily complex callback register/unregister notification [Jamal's suggested feature] for example. > > - James -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 09:19 +0400, Evgeniy Polyakov wrote: > On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote: > > On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote: > > > > > > > Yes but what will go wrong on uni-processor MIPS when you don't do the > > > > sync in atomic_sub_return? > > > > > > Sync synchornizes cached mamory access, > > > without it new value may be stored only into cache, > > > but not into memory. > > > > I know, the same thing holds for most architectures, including i386. > > However, this is not an issue for uni-processor kernels anywhere else, > > so what's so special about MIPS? > > Does i386 or ppc has cached and uncached memory? > No, i386, ppc and others do not require sync on uncached memory access, > and only instruction not data cache sync on SMP. Ugh, now I see your point :) For UP we may have some nitpics with DMA, but I doubt anyone will use atomic pointer for DMA. sync will not be an issue in atomic ops. > > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 08 Apr 2005 09:19:39 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > I know, the same thing holds for most architectures, including i386. > > However, this is not an issue for uni-processor kernels anywhere else, > > so what's so special about MIPS? > > Does i386 or ppc has cached and uncached memory? Yes, they do. > No, i386, ppc and others do not require sync on uncached memory access, > and only instruction not data cache sync on SMP. On MIPS, all the MIPS atomic operations will operate on cached memory. And as far as a uniprocessor cpu is concerned, updating the cache is all that matters. In fact, this SYNC instruction seems unnecessary even on SMP. If the cache is updated, it is part of the coherent memory space and thus MOESI main bus SMP cache coherency transactions will see the update value. When another processor does a "read-to-share" or "read-to-own" request on the main bus, the processor which did the atomic OP will provide the correct data from it's cache in response to that transaction. So what you have to do is show me an example where the MIPS kernel can do an atomic.h operation on uncached memory. I even think that is invalid, come to think of it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 08 Apr 2005 09:19:39 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: I know, the same thing holds for most architectures, including i386. However, this is not an issue for uni-processor kernels anywhere else, so what's so special about MIPS? Does i386 or ppc has cached and uncached memory? Yes, they do. No, i386, ppc and others do not require sync on uncached memory access, and only instruction not data cache sync on SMP. On MIPS, all the MIPS atomic operations will operate on cached memory. And as far as a uniprocessor cpu is concerned, updating the cache is all that matters. In fact, this SYNC instruction seems unnecessary even on SMP. If the cache is updated, it is part of the coherent memory space and thus MOESI main bus SMP cache coherency transactions will see the update value. When another processor does a read-to-share or read-to-own request on the main bus, the processor which did the atomic OP will provide the correct data from it's cache in response to that transaction. So what you have to do is show me an example where the MIPS kernel can do an atomic.h operation on uncached memory. I even think that is invalid, come to think of it. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 09:19 +0400, Evgeniy Polyakov wrote: On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote: On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote: Yes but what will go wrong on uni-processor MIPS when you don't do the sync in atomic_sub_return? Sync synchornizes cached mamory access, without it new value may be stored only into cache, but not into memory. I know, the same thing holds for most architectures, including i386. However, this is not an issue for uni-processor kernels anywhere else, so what's so special about MIPS? Does i386 or ppc has cached and uncached memory? No, i386, ppc and others do not require sync on uncached memory access, and only instruction not data cache sync on SMP. Ugh, now I see your point :) For UP we may have some nitpics with DMA, but I doubt anyone will use atomic pointer for DMA. sync will not be an issue in atomic ops. Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 01:55 -0400, James Morris wrote: On Fri, 8 Apr 2005, Evgeniy Polyakov wrote: Sure, but seems I need to ask again: What is the exact reason not to implement the muticast message multiplexing/subscription part of the connector as a generic part of netlink? That would be nice to have and useful for other subsystems too as an option to the current broadcast. This is a good point, in general, consider generically extending Netlink itself instead of creating these separate things. Connector requires it's own registration technique for 1. hide all transport [netlink] layer from higher protocols which use connector Why? User should not know about low-level transport - it is like socket layer - write only data and do not care about how it will be delivered. 2. create different group appointment for the given connector's ID [it was different, now new group which is eqal to idx field is appointed to the new callback] I don't understand. In the previous versions netlink group was assigned as incremented counter, that was not convenient, but now we have 2-way ID, which is better from users point of view - idx is supposed to be major id, val - some subsystem of that set. 3. provide more generic set of ids What do you mean by ids? Each connector message requires pair of u32 ids - idx and val. Idx is generic system id [which is equal to the appropriate netlink group in current implementation], while val is id of some subsytem inside idx. Using only group without it's own connector's id will heavily complex callback register/unregister notification [Jamal's suggested feature] for example. - James -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: 2.6.12-rc2-mm1
Hi! Ok, I've narrowed the problem down to one patch. In 2.6.11-mm3, the problem goes away if I remove this patch: swsusp-enable-resume-from-initrd.patch That really helps, thanks. You're welcome. The patch looks fairly innocent. I'll give up on this and cc the developers. Yeah, it *seemed* innocent enough -- that's why I had to do a binary search on the 2.6.11-mm3 series file in order to find it as the culprit... Do you have XFS compiled in, by chance? You are not actually resuming from initrd, right? Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, Apr 07, 2005 at 11:02:22PM -0700, David S. Miller wrote: On Fri, 08 Apr 2005 09:19:39 +0400 Evgeniy Polyakov [EMAIL PROTECTED] wrote: I know, the same thing holds for most architectures, including i386. However, this is not an issue for uni-processor kernels anywhere else, so what's so special about MIPS? Does i386 or ppc has cached and uncached memory? Yes, they do. No, i386, ppc and others do not require sync on uncached memory access, and only instruction not data cache sync on SMP. On MIPS, all the MIPS atomic operations will operate on cached memory. And as far as a uniprocessor cpu is concerned, updating the cache is all that matters. In fact, this SYNC instruction seems unnecessary even on SMP. If the cache is updated, it is part of the coherent memory space and thus MOESI main bus SMP cache coherency transactions will see the update value. When another processor does a read-to-share or read-to-own request on the main bus, the processor which did the atomic OP will provide the correct data from it's cache in response to that transaction. So what you have to do is show me an example where the MIPS kernel can do an atomic.h operation on uncached memory. I even think that is invalid, come to think of it. It better be... My impression is that the MIPS story isn't so simple, because the architecture only offers very weak coherency guarantees. Most of the SMP implementations offer strong coherency in practice, but at least one (RM9000) doesn't. -- Daniel Jacobowitz CodeSourcery, LLC - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 8 Apr 2005, Evgeniy Polyakov wrote: > > > Sure, but seems I need to ask again: What is the exact reason not to > > > implement > > > the muticast message multiplexing/subscription part of the connector as a > > > generic part of netlink? That would be nice to have and useful for other > > > subsystems too as an option to the current broadcast. > > > > This is a good point, in general, consider generically extending Netlink > > itself instead of creating these separate things. > > Connector requires it's own registration technique for > 1. hide all transport [netlink] layer from higher protocols which use > connector Why? > 2. create different group appointment for the given connector's ID > [it was different, now new group which is eqal to idx field is appointed > to > the new callback] I don't understand. > 3. provide more generic set of ids What do you mean by "ids"? - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 15:08 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote: > > > > > Yes but what will go wrong on uni-processor MIPS when you don't do the > > > sync in atomic_sub_return? > > > > Sync synchornizes cached mamory access, > > without it new value may be stored only into cache, > > but not into memory. > > I know, the same thing holds for most architectures, including i386. > However, this is not an issue for uni-processor kernels anywhere else, > so what's so special about MIPS? Does i386 or ppc has cached and uncached memory? No, i386, ppc and others do not require sync on uncached memory access, and only instruction not data cache sync on SMP. > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 09:11:56AM +0400, Evgeniy Polyakov wrote:
>
> > Yes but what will go wrong on uni-processor MIPS when you don't do the
> > sync in atomic_sub_return?
>
> Sync synchornizes cached mamory access,
> without it new value may be stored only into cache,
> but not into memory.
I know, the same thing holds for most architectures, including i386.
However, this is not an issue for uni-processor kernels anywhere else,
so what's so special about MIPS?
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 14:53 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote: > > > > > > Unfortunately not, that sync is required exactly for return value store. > > > > > > On UP? > > > > Yes, some quotes: > > Yes but what will go wrong on uni-processor MIPS when you don't do the > sync in atomic_sub_return? Sync synchornizes cached mamory access, without it new value may be stored only into cache, but not into memory. > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 8 Apr 2005 14:53:02 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote: > Yes but what will go wrong on uni-processor MIPS when you don't do the > sync in atomic_sub_return? Indeed. I see nothing in those quotes which indicate that the SYNC is needed on uniprocessor. It's only saying things such as "SYNC only affects load and store instructions" and "LL/SC can only be performed on cacheable memory". Stuff like that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 08:55:27AM +0400, Evgeniy Polyakov wrote:
>
> > > Unfortunately not, that sync is required exactly for return value store.
> >
> > On UP?
>
> Yes, some quotes:
Yes but what will go wrong on uni-processor MIPS when you don't do the
sync in atomic_sub_return?
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 14:17 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote: > > > > > > On UP do not. > > > > > > Shouldn't we should be fixing the MIPS implementation of > > > atomic_sub_return to not do the sync on UP then? > > > > Unfortunately not, that sync is required exactly for return value store. > > On UP? Yes, some quotes: The memory access type of a location affects the behavior of I-fetch, load, store, and prefetch operations to the location. In addition, memory access types affect some instruction descriptions. Load linked (LL, LLD) and store conditional (SC, SCD) have defined operation only for locations with cached memory access type. SYNC affects only load and stores made to locations with uncached or cached coherent memory access types. 3. The SC [comment: store conditional] stores a new value into the memory word, unless the new value has been modified. If the word has not been modified, the store succeeds and a 1 is stored in the destination register. Otherwise the Store Conditional fails, memory is not modified, and a 0 is loaded into the destination register. Since the instruction format has only a single field to select a data register (rt), this destination register is the same as the register which was stored. Load Linked and Store Conditional instructions (LL, LLD, SC, and SCD) do not implicitly perform SYNC operations in the R1 processor. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 08 Apr 2005 07:52:34 +0400 Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > sparc64 has 32->64 conversation on exit. It's extremely cheap, the conversion instruction pairs with the retl instruction so it's essentially free. Talking about an arithmetic instruction over is complete nonsense when the atomic CAS instruction itself takes a minimum of 32 processor cycles :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 8 Apr 2005 14:17:24 +1000 Herbert Xu <[EMAIL PROTECTED]> wrote: > On UP? I think the barrier can be eliminated on MIPS on UP. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 08:21:28AM +0400, Evgeniy Polyakov wrote:
>
> > > On UP do not.
> >
> > Shouldn't we should be fixing the MIPS implementation of
> > atomic_sub_return to not do the sync on UP then?
>
> Unfortunately not, that sync is required exactly for return value store.
On UP?
--
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 14:02 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote: > > > > > > mips has additional sync. > > > > > > But atomic_dec + 2 barries is going to do the sync as well, no? > > > > On UP do not. > > Shouldn't we should be fixing the MIPS implementation of > atomic_sub_return to not do the sync on UP then? Unfortunately not, that sync is required exactly for return value store. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 08:02:49AM +0400, Evgeniy Polyakov wrote:
>
> > > mips has additional sync.
> >
> > But atomic_dec + 2 barries is going to do the sync as well, no?
>
> On UP do not.
Shouldn't we should be fixing the MIPS implementation of
atomic_sub_return to not do the sync on UP then?
--
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 13:50 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote: > > On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote: > > > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote: > > > > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote: > > > > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > atomic_dec_and_test() is more expensive than 2 barriers + > > > > > > atomic_dec(), > > > > > > but in case of connector I think the price is not so high. > > > > > > > > > > Can you list the platforms on which this is true? > > > > > > > > sparc64, some mips [at least in UP]. > > > > > > Are you sure? The implementations of atomic_sub and atomic_sub_return > > > (which correspond to atomic_dec and atomic_dec_and_test) seem to be > > > comparable in cost on those two architectures. > > > > mips has additional sync. > > But atomic_dec + 2 barries is going to do the sync as well, no? On UP do not. > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 07:52:34AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote:
> > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> > > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > atomic_dec_and_test() is more expensive than 2 barriers +
> > > > > atomic_dec(),
> > > > > but in case of connector I think the price is not so high.
> > > >
> > > > Can you list the platforms on which this is true?
> > >
> > > sparc64, some mips [at least in UP].
> >
> > Are you sure? The implementations of atomic_sub and atomic_sub_return
> > (which correspond to atomic_dec and atomic_dec_and_test) seem to be
> > comparable in cost on those two architectures.
>
> mips has additional sync.
But atomic_dec + 2 barries is going to do the sync as well, no?
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 13:32 +1000, Herbert Xu wrote: > On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote: > > On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote: > > > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > > > > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(), > > > > but in case of connector I think the price is not so high. > > > > > > Can you list the platforms on which this is true? > > > > sparc64, some mips [at least in UP]. > > Are you sure? The implementations of atomic_sub and atomic_sub_return > (which correspond to atomic_dec and atomic_dec_and_test) seem to be > comparable in cost on those two architectures. mips has additional sync. sparc64 has 32->64 conversation on exit. > Perhaps Dave can clarify for us about sparc64? Dave? > Cheers, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 2005-04-07 at 11:47 -0400, James Morris wrote: > On Thu, 7 Apr 2005, Kay Sievers wrote: > > > Sure, but seems I need to ask again: What is the exact reason not to > > implement > > the muticast message multiplexing/subscription part of the connector as a > > generic part of netlink? That would be nice to have and useful for other > > subsystems too as an option to the current broadcast. > > This is a good point, in general, consider generically extending Netlink > itself instead of creating these separate things. I just do not understand, what does netlink multicasting means and how it is different from what we have now. Currently we have group registratin in bind(), and then send data to the bound socket if it has appropriate group. Or should some error be propagated to the caller, if there is no appropriate listener? Connector requires it's own registration technique for 1. hide all transport [netlink] layer from higher protocols which use connector 2. create different group appointment for the given connector's ID [it was different, now new group which is eqal to idx field is appointed to the new callback] 3. provide more generic set of ids > > - James -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, Apr 08, 2005 at 07:33:58AM +0400, Evgeniy Polyakov wrote:
> On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote:
> > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> > >
> > > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> > > but in case of connector I think the price is not so high.
> >
> > Can you list the platforms on which this is true?
>
> sparc64, some mips [at least in UP].
Are you sure? The implementations of atomic_sub and atomic_sub_return
(which correspond to atomic_dec and atomic_dec_and_test) seem to be
comparable in cost on those two architectures.
Perhaps Dave can clarify for us about sparc64?
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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Fri, 2005-04-08 at 12:59 +1000, Herbert Xu wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(), > > but in case of connector I think the price is not so high. > > Can you list the platforms on which this is true? sparc64, some mips [at least in UP]. I do not know about others, but I think that any arch, where atomic operations are serialized, has sync/isync in atomic_dec_and_test() and does not for atomic_dec(). > Thanks, -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(),
> but in case of connector I think the price is not so high.
Can you list the platforms on which this is true?
Thanks,
--
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: 2.6.12-rc2-mm1
On Thu, 2005-04-07 at 18:08 -0700, Siddha, Suresh B wrote: > On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote: > > Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped > > itself to death after 2 infinite loop tasks had been pinned to one > > of the CPUs. See how you go. > > Its goes well beyond the initial 7000 number I mentioned. Thanks. > OK, good thanks for testing that. I'll send it to Andrew. > One side-effect of this patch is: for example we have only two processes > running on a cpu and both are pinned to that cpu. If someone comes and > changes the affinity of one of these processes to all cpu's in the system, > then it might take MAX_PINNED_INTERVAL before this process moves to an idle > cpu. > Yeah, that is true. OTOH it is a bit of a special case, and our multiprocessor scheduling in general practically shuts down when we have a situation with a single queue with a lot of pinned tasks. What did I have for MAX_PINNED_INTERVAL? ~1second. I guess that could come down a bit - maybe 1/4 or 1/2 a second? I think it is a "good enough for now" kind of situation. -- SUSE Labs, Novell Inc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1
On Thu, Apr 07, 2005 at 03:11:12AM +1000, Nick Piggin wrote: > Using the attached patch, a puny dual PIII-650 with ~400MB RAM swapped > itself to death after 2 infinite loop tasks had been pinned to one > of the CPUs. See how you go. Its goes well beyond the initial 7000 number I mentioned. Thanks. One side-effect of this patch is: for example we have only two processes running on a cpu and both are pinned to that cpu. If someone comes and changes the affinity of one of these processes to all cpu's in the system, then it might take MAX_PINNED_INTERVAL before this process moves to an idle cpu. thanks, suresh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1: ieee1394 process hang
On Thu, Apr 07, 2005 at 01:58:45AM -0700, Andrew Morton wrote: > > I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my > > Apple iSight camera, it is not detected; repeated > > connections/disconnections don't help. When I tried to rmmod all the > > appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the > > rmmod command hung. Alt-Sysreq-t shows this: > > I don't think there have been any 1394 changes recently. This bug might be > more fallout from Pat's recent changes. > > More attempts have been made to fix that stuff up. Maybe you could try > http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.12-rc2-mm1.5.gz I'm not so sure, last week I had similar results with an external IEEE 1394 disk drive. On the first attempt it wasn't detected, in the 2nd and 3rd attempt detecting worked ok. After copying a data for like 2min the system paniced with no useful data in the log. Further attempts resulted in more hangs and panics. The kernel was the latest and greatest FC3 kernel, kernel-2.6.10-1.770_FC3. (I'm a 1h flight away from the system so can't do any more testing on that system) Ralf - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1 - printk timing broken
Hi Andrew, Le Tuesday 05 April 2005 09:45, Andrew Morton a écrit : > Brice Goglin <[EMAIL PROTECTED]> wrote: > > Andrew Morton a écrit : > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6. > > >12-rc2/2.6.12-rc2-mm1/ > > > > Hi Andrew, > > > > printk timing seems broken. > > It always shows [ 0.00] on my Compaq Evo N600c. > > What sort of CPU does that thing have? Please share the /proc/cpuinfo > output. i can reproduce this "[ 0.00]"-bug with a Thinkpad A31p with a P4M: cpu family : 15 model : 2 model name : Mobile Intel(R) Pentium(R) 4 - M CPU 2.00GHz stepping: 7 cpu MHz : 1998.447 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe cid > Does reverting > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc >2/2.6.12-rc2-mm1/broken-out/sched-x86-sched_clock-to-use-tsc-on-config_h >pet-or-config_numa-systems.patch fix it? for me too - yes strange, because the cpu supports tsc as the flags indicate in the cpuinfo i posted. hopefully this mystery is no more, soon ;-) best regards, Damir -- Don't confuse things that need action with those that take care of themselves. pgpKOpBaYyukE.pgp Description: PGP signature
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 7 Apr 2005, Kay Sievers wrote: > Sure, but seems I need to ask again: What is the exact reason not to implement > the muticast message multiplexing/subscription part of the connector as a > generic part of netlink? That would be nice to have and useful for other > subsystems too as an option to the current broadcast. This is a good point, in general, consider generically extending Netlink itself instead of creating these separate things. - James -- James Morris <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 2005-04-07 at 16:23 +0200, Kay Sievers wrote: > Sure, but seems I need to ask again: What is the exact reason not to implement > the muticast message multiplexing/subscription part of the connector as a > generic part of netlink? That would be nice to have and useful for other > subsystems too as an option to the current broadcast. I do not understamd, what is netlink multicast and how it differs from the existing behaviour? Netlink message can be delivered only if someone listens for it. Subscription part of connector is similar to existing group mechanims, it is moved a bit higher from do_one_broadcast(), since it is required for proper high-layer protocol and it's users do not care about netlink groups, but only it's own ID's, which can be different. > Thanks, > Kay -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, Apr 07, 2005 at 03:24:34PM +0400, Evgeniy Polyakov wrote: > On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote: > > On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote: > > > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote: > > > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote: > > > > > The main idea was to simplify userspace control and notification > > > > > system - so people did not waste it's time learning how skb's are > > > > > allocated > > > > > and processed, how socket layer is designed and what all those > > > > > netlink_* and NLMSG* mean if they do not need it. > > > > > > > > Isn't connector built on top of netlink? If so, is there any reason for > > > > it to be a new subsystem rather than an extension the the netlink API? > > > > > > Connector is not netlink API extension in any way. > > > It uses netlink as transport layer, one can change > > > cn_netlink_send()/cn_input() > > > into something like bidirectional ioctl and use it. > > > > > > Only one cn_netlink_send() function can be "described" as API > > > extension, > > > although even it is not entirely true. > > > > I see much overlap here too. Wouldn't it be nice to see the transport > > part of the connector code to be implemented as a generic netlink > > multicast? We already have uni- and broadcast for netlink. > > Netlink broadcast is multicast actually, > if listener exists, then message will be sent to him, > if no - skb will be just freed. > > > Isn't the whole purpose of the connector to hook in notifications that > > act only if someone is listening? That is a perfect multicast case. :) > > Connector can be used to send data from userspace to kernelspace, > so it allows sending controlling messages without ioctl() compatibility > mess and so on. > > One may use cn_netlink_send() to send notification without being > registered > in connector, if it's second parameter is 0, then appropriate > connector listener will be searched for. Sure, but seems I need to ask again: What is the exact reason not to implement the muticast message multiplexing/subscription part of the connector as a generic part of netlink? That would be nice to have and useful for other subsystems too as an option to the current broadcast. > It is different from netlink messages, > netlink is a transport layer for connector. That's still possible and the kernel usually doesn't care about unimplemented alternatives. :) Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 2005-04-07 at 12:41 +0200, Kay Sievers wrote: > On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote: > > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote: > > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote: > > > > The main idea was to simplify userspace control and notification > > > > system - so people did not waste it's time learning how skb's are > > > > allocated > > > > and processed, how socket layer is designed and what all those > > > > netlink_* and NLMSG* mean if they do not need it. > > > > > > Isn't connector built on top of netlink? If so, is there any reason for > > > it to be a new subsystem rather than an extension the the netlink API? > > > > Connector is not netlink API extension in any way. > > It uses netlink as transport layer, one can change > > cn_netlink_send()/cn_input() > > into something like bidirectional ioctl and use it. > > > > Only one cn_netlink_send() function can be "described" as API > > extension, > > although even it is not entirely true. > > I see much overlap here too. Wouldn't it be nice to see the transport > part of the connector code to be implemented as a generic netlink > multicast? We already have uni- and broadcast for netlink. Netlink broadcast is multicast actually, if listener exists, then message will be sent to him, if no - skb will be just freed. > Isn't the whole purpose of the connector to hook in notifications that > act only if someone is listening? That is a perfect multicast case. :) Connector can be used to send data from userspace to kernelspace, so it allows sending controlling messages without ioctl() compatibility mess and so on. One may use cn_netlink_send() to send notification without being registered in connector, if it's second parameter is 0, then appropriate connector listener will be searched for. It is different from netlink messages, netlink is a transport layer for connector. > At the time we added kobject_uevent I was missing something like this. > The broadcast groups did not really fit, and we decided not to use them, > and unicast wasn't a option here. There is a check for listener in netlink_broadcast() - sk_for_each_bound (). > Thanks, > Kay -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 2005-04-07 at 13:52 +0400, Evgeniy Polyakov wrote: > On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote: > > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote: > > > The main idea was to simplify userspace control and notification > > > system - so people did not waste it's time learning how skb's are > > > allocated > > > and processed, how socket layer is designed and what all those > > > netlink_* and NLMSG* mean if they do not need it. > > > > Isn't connector built on top of netlink? If so, is there any reason for > > it to be a new subsystem rather than an extension the the netlink API? > > Connector is not netlink API extension in any way. > It uses netlink as transport layer, one can change > cn_netlink_send()/cn_input() > into something like bidirectional ioctl and use it. > > Only one cn_netlink_send() function can be "described" as API > extension, > although even it is not entirely true. I see much overlap here too. Wouldn't it be nice to see the transport part of the connector code to be implemented as a generic netlink multicast? We already have uni- and broadcast for netlink. Isn't the whole purpose of the connector to hook in notifications that act only if someone is listening? That is a perfect multicast case. :) At the time we added kobject_uevent I was missing something like this. The broadcast groups did not really fit, and we decided not to use them, and unicast wasn't a option here. Thanks, Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 2005-04-07 at 01:32 -0700, Andrew Morton wrote: > Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > > > > Plus, I'm still quite unsettled about the whole object lifecycle > > > management, refcounting and locking in there. The fact that the code is > > > littered with peculiar barriers says "something weird is happening here", > > > and it remains unobvious to me why such a very common kernel pattern was > > > implemented in such an unusual manner. > > > > > > So. I'd like to see the whole thing reexplained and resubmitted so we can > > > think about it all again. > > > > All those barriers can be replaced with atomic_dec_and_test(), > > What a shame you didn't say atomic_dec_and_lock()... Oops... > > i.e. with something that returns the value. > > Methods that return value requires explicit barriers. > > > > Actually there are quite many places where we have: > > > > cpu0 cpu1 > > use object > > atomic_dec() > > if atomic_read/atomic_dec_and_test == 0 > > free object. > > Yes, but those places normally also use locking to prevent the obvious race. In case of connector all free/remove/destroy places can be accessed only after appropriate object is unlinked and no new work [only that work remains that already incremented the counter] can be assigned to the object. It was design goal [the same is true for w1, superio, acrypto] to create such a lifecycle: object is created work is assigned with atomical refcnt incrementing object is "scheduled"[1] to be removed object is destroyed if it is not used [i.e. it's refcnt is zero]. [1]: "scheduled" means that work [removal in our case] can be done not now, but after some condition, like refcnt zeroing. > Yes, atomic_dec_and_test() and barrier removal would be better. Especially > if it's associated with code commentary which explains why the whole thing > isn't racy (ie: explains why no other CPU can look this object up). atomic_dec_and_test() is more expensive than 2 barriers + atomic_dec(), but in case of connector I think the price is not so high. Should questionable design notes be described in in-source documentation or patch description is enough? > > > Which comments were not addressed? > > > > CBUS code comments [I did not get ack on CBUS itself], and two below > > issues. > > I continue to not see any point in cbus. It moves work from one place to > another while increasing the amount of code and quite probably increasing > the net amount of work too. Ok. Cache utilisation and ability to send events from any context and under the locks are significant issues which are solved in CBUS, but they are not the most important reasons. Ability to not slow down fast pathes - that is the main reason. Concider situation when one may want to have notification of each new write system call - let's say without such notification it took about 1 second to write one page from userspace, now with notification sending, which is not so fast, it will take 1.5 seconds, but with CBUS write() still costs 1 second plus later, when we do not care about writing performance and scheduler decides to run CBUS thread, those notifications will take additional 0.5 seconds to be delivered. But if one requires not delayed fact of the notification, but almost immediate event - one can still use direct connector's methods. So the main usage case for CBUS is sutuations when we do not want to slow process down just to send notification about it, instead we can create such a notification, and deliver it later. It is design issue - queue events in fast pathes, lock contexts, irq [soft irq] contexts and safely send them later. It also provides better controlling mechanism over messages to be sent - using limited number of messages to be sent in a time, CBUS smoothes shape peaks which are created by huge amount of notification to be send in a time. > IOW it looks like a net loss which happens to provide gains in one rather > uninteresting microbenchmark. No messages were lost during tests, since there were no OOM condition [atomic allocation never fails] and userspace application read it's socket queue properly, so socket queue and thus connector was not starved by userspace. That benchmark showed that CBUS/connector does not slow down fast fork() path while delivering messages, and all notifications about forks were delivered. From your point of view it is better to complete notification work before event itself is finished, but you definitely want to queue block requests before they reach low-level device driver, and queue skbs but not process them in receive IRQ handler. Last two cases are created exactly for not slowing down fast path, so other fast events [new interrupts] may occure and all them [and the real work can be done] can be processed later. > I'll gleefully admit that I'm wrong, but I don't think that has been > demonstrated yet. >
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 2005-04-07 at 10:12 +0100, Ian Campbell wrote: > On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote: > > The main idea was to simplify userspace control and notification > > system - so people did not waste it's time learning how skb's are > > allocated > > and processed, how socket layer is designed and what all those > > netlink_* and NLMSG* mean if they do not need it. > > Isn't connector built on top of netlink? If so, is there any reason for > it to be a new subsystem rather than an extension the the netlink API? Connector is not netlink API extension in any way. It uses netlink as transport layer, one can change cn_netlink_send()/cn_input() into something like bidirectional ioctl and use it. Only one cn_netlink_send() function can be "described" as API extension, although even it is not entirely true. Better design explanation can be found in lkml/netdev archives. > Ian. -- Evgeniy Polyakov Crash is better than data corruption -- Arthur Grabowski signature.asc Description: This is a digitally signed message part
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Thu, 2005-04-07 at 12:13 +0400, Evgeniy Polyakov wrote: > The main idea was to simplify userspace control and notification > system - so people did not waste it's time learning how skb's are > allocated > and processed, how socket layer is designed and what all those > netlink_* and NLMSG* mean if they do not need it. Isn't connector built on top of netlink? If so, is there any reason for it to be a new subsystem rather than an extension the the netlink API? Ian. -- Ian Campbell Employees and their families are not eligible. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1: ieee1394 process hang
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > > I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my > Apple iSight camera, it is not detected; repeated > connections/disconnections don't help. When I tried to rmmod all the > appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the > rmmod command hung. Alt-Sysreq-t shows this: I don't think there have been any 1394 changes recently. This bug might be more fallout from Pat's recent changes. More attempts have been made to fix that stuff up. Maybe you could try http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.12-rc2-mm1.5.gz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.12-rc2-mm1: ieee1394 process hang
I'm having problems with 1394 in 2.6.12-rc2-mm1. When I connect my Apple iSight camera, it is not detected; repeated connections/disconnections don't help. When I tried to rmmod all the appropriate modules (rmmod video1394 raw1394 ohci1394 ieee1394), the rmmod command hung. Alt-Sysreq-t shows this: rmmod D F75593C0 0 7206 7193 (NOTLB) e43fbda0 0086 e43fbdd0 f75593c0 f78bbd20 29b325f2 04d2 0848 2ec09330 04d2 e0556560 e0556688 f792f258 e43fbdd4 e43fb000 e43fbdf4 c02ade0e e0556560 c01142b0 Call Trace: [] wait_for_completion+0x6e/0xc0 [] device_del+0x16/0x70 [] device_unregister+0xb/0x20 [] nodemgr_remove_ne+0x6d/0x90 [ieee1394] [] __nodemgr_remove_host_dev+0xb/0x10 [ieee1394] [] device_for_each_child+0x29/0x50 [] nodemgr_remove_host_dev+0x15/0x40 [ieee1394] [] __unregister_host+0x75/0xb0 [ieee1394] [] highlevel_remove_host+0x2d/0x60 [ieee1394] [] hpsb_remove_host+0x3b/0x60 [ieee1394] [] ohci1394_pci_remove+0x8b/0x250 [ohci1394] [] pci_device_remove+0x2c/0x40 [] device_release_driver+0x7c/0x80 [] __remove_driver+0x8/0x10 [] driver_for_each_device+0x43/0x70 [] driver_detach+0x16/0x18 [] bus_remove_driver+0x26/0x40 [] driver_unregister+0xe/0x20 [] pci_unregister_driver+0xe/0x20 [] sys_delete_module+0x14d/0x160 [] sysenter_past_esp+0x54/0x75 This last worked for me in 2.6.12-rc1-mm3; I didn't have a chance to test -rc1-mm4. .config attached and lspci attached. J 00:00.0 Host bridge: Intel Corp. 82855PM Processor to I/O Controller (rev 03) Subsystem: IBM: Unknown device 0529 Flags: bus master, fast devsel, latency 0 Memory at d000 (32-bit, prefetchable) [size=256M] Capabilities: [e4] Vendor Specific Information Capabilities: [a0] AGP version 2.0 00:01.0 PCI bridge: Intel Corp. 82855PM Processor to AGP Controller (rev 03) (prog-if 00 [Normal decode]) Flags: bus master, 66Mhz, fast devsel, latency 96 Bus: primary=00, secondary=01, subordinate=01, sec-latency=64 I/O behind bridge: 3000-3fff Memory behind bridge: c010-c01f Prefetchable memory behind bridge: e000-e7ff 00:1d.0 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM: Unknown device 052d Flags: bus master, medium devsel, latency 0, IRQ 11 I/O ports at 1800 [size=32] 00:1d.1 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM: Unknown device 052d Flags: bus master, medium devsel, latency 0, IRQ 5 I/O ports at 1820 [size=32] 00:1d.2 USB Controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) (prog-if 00 [UHCI]) Subsystem: IBM: Unknown device 052d Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at 1840 [size=32] 00:1d.7 USB Controller: Intel Corp. 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) (prog-if 20 [EHCI]) Subsystem: IBM: Unknown device 052e Flags: bus master, medium devsel, latency 0, IRQ 5 Memory at c000 (32-bit, non-prefetchable) [size=1K] Capabilities: [50] Power Management version 2 Capabilities: [58] Debug port 00:1e.0 PCI bridge: Intel Corp. 82801 Mobile PCI Bridge (rev 81) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=02, subordinate=08, sec-latency=64 I/O behind bridge: 4000-8fff Memory behind bridge: c020-cfff Prefetchable memory behind bridge: e800-efff 00:1f.0 ISA bridge: Intel Corp. 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) Flags: bus master, medium devsel, latency 0 00:1f.1 IDE interface: Intel Corp. 82801DBM (ICH4-M) IDE Controller (rev 01) (prog-if 8a [Master SecP PriP]) Subsystem: IBM: Unknown device 052d Flags: bus master, medium devsel, latency 0, IRQ 9 I/O ports at I/O ports at I/O ports at I/O ports at I/O ports at 1860 [size=16] Memory at 4000 (32-bit, non-prefetchable) [size=1K] 00:1f.3 SMBus: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) Subsystem: IBM: Unknown device 052d Flags: medium devsel, IRQ 10 I/O ports at 1880 [size=32] 00:1f.5 Multimedia audio controller: Intel Corp. 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) Subsystem: IBM: Unknown device 0534 Flags: bus master, medium devsel, latency 0, IRQ 10 I/O ports at 1c00 [size=256] I/O ports at 18c0 [size=64] Memory at cc00 (32-bit, non-prefetchable) [size=512] Memory at c800 (32-bit, non-prefetchable) [size=256] Capabilities: [50] Power Management
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote: > > > > > Plus, I'm still quite unsettled about the whole object lifecycle > > management, refcounting and locking in there. The fact that the code is > > littered with peculiar barriers says "something weird is happening here", > > and it remains unobvious to me why such a very common kernel pattern was > > implemented in such an unusual manner. > > > > So. I'd like to see the whole thing reexplained and resubmitted so we can > > think about it all again. > > All those barriers can be replaced with atomic_dec_and_test(), What a shame you didn't say atomic_dec_and_lock()... > i.e. with something that returns the value. > Methods that return value requires explicit barriers. > > Actually there are quite many places where we have: > > cpu0 cpu1 > use object > atomic_dec() > if atomic_read/atomic_dec_and_test == 0 > free object. Yes, but those places normally also use locking to prevent the obvious race. Yes, atomic_dec_and_test() and barrier removal would be better. Especially if it's associated with code commentary which explains why the whole thing isn't racy (ie: explains why no other CPU can look this object up). > > Which comments were not addressed? > > CBUS code comments [I did not get ack on CBUS itself], and two below > issues. I continue to not see any point in cbus. It moves work from one place to another while increasing the amount of code and quite probably increasing the net amount of work too. IOW it looks like a net loss which happens to provide gains in one rather uninteresting microbenchmark. I'll gleefully admit that I'm wrong, but I don't think that has been demonstrated yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: connector is missing in 2.6.12-rc2-mm1
On Thu, Apr 07, 2005 at 12:30:49PM +0400, Evgeniy Polyakov wrote: > On Thu, 2005-04-07 at 01:17 -0700, Greg KH wrote: > > On Wed, Apr 06, 2005 at 11:42:57PM -0700, Andrew Morton wrote: > > > Guillaume Thouvenin <[EMAIL PROTECTED]> wrote: > > > > > > > > Hello, > > > > > > > > I don't see the connector directory in the 2.6.12-rc2-mm1 tree. So it > > > > seems that you removed the connector? > > > > > > Greg dropped it for some reason. I think that's best because it needed a > > > significant amount of rework. I'd like to see it resubitted in totality > > > so > > > we can take another look at it. > > > > Greg dropped it because he's radically changing the way he handles > > patches. I still have them around here somewhere... > > He probably was quite dissapointed/overflowed by it's quality and > quantity, but please thank him for his comments and tell him it > was very pleasant to work with. Heh, that must have been what happened... :) > > Yeah, here they are. Hm, I'd really like to stop carrying them around, > > as my workload doesn't lend itself to handling these. > > > > If you don't mind, can you create up a new connector, super-io, and > > kobject-connector patch and send them to andrew for him to add to -mm? > > That way I'll not have to worry about them anymore, as they keep > > floating in-and-out of the -mm releases depending on the state of my > > trees. I can still handle your w1 patches, and have 2 of them pending. > > > > Is that ok with you? > > Ok, I will prepare new series of that patches and will push them > upstream. Great, that makes my life a lot easier. 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/
