fib6_del_route has redundant code
Hi all, I think the following code in fib6_del_route in the latest kernel is useless. 1125 if (fn->leaf == NULL && fn->fn_flags_TL_ROOT) 1126 fn->leaf = _null_entry; ip6_null_entry will never be unlinked from fn->leaf now, that is, fn->leaf == NULL will never meet. In previous kernel, When adding a default route, ip6_null_entry will be unlinked from fn->leaf. So, when deleting a default route, it need to check whether the deleted route is the last one, if so, ip6_null_entry will link to fn->leaf again. I am not sure if there is another place unlinks ip6_null_entry from fn->leaf. Regards, Gui Jiafeng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fs/autofs: Use time_before, time_before_eq, etc.
On Wed, 26 Dec 2007, H. Peter Anvin wrote:
> Ray Lee wrote:
> > On Dec 26, 2007 7:21 AM, Julia Lawall <[EMAIL PROTECTED]> wrote:
> > > - if (jiffies - ent->last_usage < timeout)
> > > + if (time_before(jiffies, ent->last_usage + timeout))
> >
> > I don't think this is a safe change? subtraction is always safe (if
> > you think about it as 'distance'), addition isn't always safe unless
> > you know the range. The time_before macro will expand that out to
> > (effectively):
> >
> > if ( (long)(ent->last_usage + timeout) - (long)(jiffies) < 0 )
> >
> > which seems to introduce an overflow condition in the first term.
> >
> > Dunno, I may be wrong (happens often), but at the very least what
> > you've transformed it into is no longer obviously correct, and so it's
> > not a great change.
>
> Indeed. The bottom form will have overflow issues at time
> jiffies_wraparound/2, whereas the top form will have overflow issues only near
> jiffies_wraparound/1.
OK, so it seems like it is not such a good idea.
There are, however, over 200 files that contain calls to the various time
functions that follow this pattern, eg:
arch/arm/kernel/ecard.c:563
if (!last || time_after(jiffies, last + 5*HZ)) {
Perhaps they should be coverted to use a subtraction as well?
julia
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/55] KVM: Per-architecture hypercall definitions
[copying Anthony, the original author]
Pavel Machek wrote:
Hi!
Currently kvm provides hypercalls only for x86* architectures. To
provide hypercall infrastructure for other kvm architectures I split
kvm_para.h into a generic header file and architecture specific
definitions.
diff --git a/include/asm-x86/kvm_para.h b/include/asm-x86/kvm_para.h
new file mode 100644
index 000..c6f3fd8
--- /dev/null
+++ b/include/asm-x86/kvm_para.h
@@ -0,0 +1,105 @@
+#ifndef __X86_KVM_PARA_H
+#define __X86_KVM_PARA_H
+
+/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
+ * should be used to determine that a VM is running under KVM.
+ */
+#define KVM_CPUID_SIGNATURE0x4000
so it returns 'KVMKVMKVM' in %rax, too?
No, as documented. 'KVMKVMKVM' is spread among all three registers (9
bytes won't fit into one...)
+/* For KVM hypercalls, a three-byte sequence of either the vmrun or the vmmrun
+ * instruction. The hypervisor may replace it with something else but only the
+ * instructions are guaranteed to be supported.
+ *
+ * Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
+ * The hypercall number should be placed in rax and the return
rax? First, this file is shared with i386, AFAICT.
rax is used here in the sense of 'rax on x86-64, eax on i386'. I guess
this should be documented.
+ * placed in rax. No other registers will be clobbered unless explicited
+ * noted by the particular hypercall.
+ */
+
+static inline long kvm_hypercall0(unsigned int nr)
+{
+ long ret;
+ asm volatile(KVM_HYPERCALL
+: "=a"(ret)
+: "a"(nr));
Second, if it is to be placed in rax, nr should be unsigned long?
Hm. Since hypercall numbers are shared with i386, we can't have >4G of
them. So the hypercall number should be redefined to be in eax,
regardless of arch (while the arguments still are unsigned longs).
+static inline int kvm_para_available(void)
+{
+ unsigned int eax, ebx, ecx, edx;
+ char signature[13];
+
+ cpuid(KVM_CPUID_SIGNATURE, , , , );
+ memcpy(signature + 0, , 4);
+ memcpy(signature + 4, , 4);
+ memcpy(signature + 8, , 4);
+ signature[12] = 0;
+
ebx|ecx|ed
+ if (strcmp(signature, "KVMKVMKVM") == 0)
+ return 1;
Should the comment say
+/* This CPUID returns the signature 'KVMKVMKVM\0\0\0' in ebx, ecx, and edx. It
+ * should be used to determine that a VM is running under KVM.
+ */
Plus, I'd use memcmp, and actually test for those zeros, too.
...which probably can be done later, as this is pure move...
Pavel
Or maybe direct 32-bit compares, and document the 32-bit values of the
registers directly, to avoid any chance of confusion.
Thanks for the comments, I'll update the patches.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/55] KVM patch queue review for 2.6.25 merge window (part II)
Sam Ravnborg wrote:
On Wed, Dec 26, 2007 at 01:05:05PM +0200, Avi Kivity wrote:
The second 2.6.25 kvm patch series, for your review. Three more to go.
Hi Avi.
A diffstat in your introduction mail would be nice so one does not
have to check 50+ patches to see if it touches any file I can give
feedback on.
Right, sorry for not including it originally:
(this is the diffstat for the entire patchset, not just this batch)
arch/x86/Kconfig |6 +
arch/x86/Makefile |2 +
{drivers => arch/x86}/kvm/Kconfig |4 +-
{drivers => arch/x86}/kvm/Makefile |6 +-
{drivers => arch/x86}/kvm/i8259.c |8 +-
{drivers => arch/x86}/kvm/irq.c| 22 +-
arch/x86/kvm/irq.h | 88 +
{drivers => arch/x86}/kvm/kvm_svm.h|2 +-
{drivers => arch/x86}/kvm/lapic.c | 141 +-
arch/x86/kvm/lapic.h | 44 +
{drivers => arch/x86}/kvm/mmu.c| 1016 --
arch/x86/kvm/mmu.h | 44 +
{drivers => arch/x86}/kvm/paging_tmpl.h| 410 +--
arch/x86/kvm/segment_descriptor.h | 29 +
{drivers => arch/x86}/kvm/svm.c| 347 +-
{drivers => arch/x86}/kvm/svm.h|3 +-
{drivers => arch/x86}/kvm/vmx.c| 1068 +++---
{drivers => arch/x86}/kvm/vmx.h| 26 +-
drivers/kvm/kvm_main.c => arch/x86/kvm/x86.c | 4099
+---
arch/x86/kvm/x86_emulate.c | 1912 +
drivers/Kconfig|2 -
drivers/Makefile |1 -
drivers/kvm/irq.h | 165 -
drivers/kvm/segment_descriptor.h | 17 -
drivers/kvm/x86_emulate.c | 1662
include/asm-x86/Kbuild |1 +
include/asm-x86/kvm.h | 176 +
drivers/kvm/kvm.h => include/asm-x86/kvm_host.h| 530 +--
include/asm-x86/kvm_para.h | 105 +
.../asm-x86/kvm_x86_emulate.h | 69 +-
include/linux/Kbuild |2 +-
include/linux/kvm.h| 162 +-
include/linux/kvm_host.h | 290 ++
include/linux/kvm_para.h | 80 +-
include/linux/kvm_types.h | 54 +
kernel/fork.c |1 +
{drivers => virt}/kvm/ioapic.c | 99 +-
virt/kvm/ioapic.h | 95 +
virt/kvm/iodev.h | 63 +
virt/kvm/kvm_main.c| 1393 +++
40 files changed, 8139 insertions(+), 6105 deletions(-)
As you can see, the {drivers/ -> virt/, arch/x86/} transition dominates
the diffstat. Note that this does not include ia64 support, which is
planned for the 2.6.25 merge window and only awaits a bit of paperwork.
The Kconfig/Makefile changes which are probably most of interest to you
should arrive in the last batch.
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH linux-acpi] Fix /proc/acpi/alarm set error
/proc/acpi/alarm can't be set correctly, here is a sample: [EMAIL PROTECTED] /]# echo "2006 09" > /proc/acpi/alarm [EMAIL PROTECTED] /]# cat /proc/acpi/alarm 2007-12-09 09:09:09 [EMAIL PROTECTED] /]# echo "2006 04" > /proc/acpi/alarm [EMAIL PROTECTED] /]# cat /proc/acpi/alarm 2007-12-04 04:04:04 [EMAIL PROTECTED] /]# Obviously, it is wrong, it should consider it as an invalid input. This patch'll fix this issue, after applying this patch, the result is: [EMAIL PROTECTED] /]# echo "2008 09" > /proc/acpi/alarm -bash: echo: write error: Invalid argument [EMAIL PROTECTED] /]# Signed-off by Yi Yang <[EMAIL PROTECTED]> diff --git a/drivers/acpi/sleep/proc.c b/drivers/acpi/sleep/proc.c index 1538355..fce78fb 100644 --- a/drivers/acpi/sleep/proc.c +++ b/drivers/acpi/sleep/proc.c @@ -178,6 +178,9 @@ static int get_date_field(char **p, u32 * value) * Try to find delimeter, only to insert null. The end of the * string won't have one, but is still valid. */ + if (*p == NULL) + return result; + next = strpbrk(*p, "- :"); if (next) *next++ = '\0'; @@ -190,6 +193,8 @@ static int get_date_field(char **p, u32 * value) if (next) *p = next; + else + *p = NULL; return result; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.24-rc6-mm1 - drivers/char/tpm/tpm_bios.c oddness?
On Sat, 22 Dec 2007 23:30:56 PST, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/
Looks like an uninitialized variable dereference for SEPARATOR events:
# mount -t securityfs none /sys/kernel/security/
# ls /sys/kernel/security/
tpm0
# l /sys/kernel/security/tpm0/
total 0
0 -r--r- 1 root root 0 2007-12-26 23:28 ascii_bios_measurements
0 -r--r- 1 root root 0 2007-12-26 23:28 binary_bios_measurements
# cat /sys/kernel/security/tpm0/ascii_bios_measurements
0 07 [S-CRTM Contents]
0 07 [S-CRTM Contents]
0 07 [S-CRTM Contents]
0 07 [S-CRTM Contents]
4 c1e25c3f6b0dc78d57296aa2870ca6f782ccf80f 05 [Calling INT 19h]
0 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
1 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
2 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
3 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
4 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
5 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
6 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
7 85e53271e14006f0265921d02d4d736cdc580b0b 04 [ÿ]
4 38f30a0a967fcf2bfee1e3b2971de540115048c8 05 [Returned INT 19h]
4 f9d3a33e4ba6109fb60e8df6ec0f10330733c8b2 0c [Compact Hash]
5 9bd5c812613f67ce1c75d0ea48b9933a547683cb 0c [Compact Hash]
Looks like the problem is likely in get_event_name:
case NONHOST_INFO:
name = tcpa_event_type_strings[event->event_type];
n_len = strlen(name);
break;
case SEPARATOR:
case ACTION:
if (MAX_TEXT_EVENT > event->event_size) {
name = event_entry;
n_len = event->event_size;
}
break;
Should there be a 'break;' after the SEPARATOR line? Given the name, it
probably doesn't have a name/length pair attached to an event, right?
pgpm8r6XHuyoY.pgp
Description: PGP signature
Re: Major regression on hackbench with SLUB (more numbers)
On Wed, 26 Dec 2007, Al Viro wrote: > Erm... Let me spell it out: current lifetime rules are completely broken. > As it is, create/destroy/create cache sequence will do kobject_put() on > kfree'd object. Even without people playing with holding sysfs files > open or doing IO on those. Urgh. Help! Isnt there some sanity with sysfs? > a) you have kobject embedded into struct with the lifetime rules of its > own. When its refcount hits zero you kfree() the sucker, even if you > still have references to embedded kobject. So alloate it separately? > b) your symlinks stick around. Even when cache is long gone you still > have a sysfs symlink with its embedded kobject as a target. They are > eventually removed when cache with the same name gets created. _Then_ > you get the target kobject dropped - when the memory it used to be in > had been freed for hell knows how long and reused by something that would > not appreciate slub.c code suddenly deciding to decrement some word in > that memory. H.. That would also be addressed by a having a separately allocated kobject? > c) you leak references to these kobject; kobject_del() only removes it > from the tree undoing the effect of kobject_add() and you still need > kobject_put() to deal with the last reference. Patches would be appreciated Had a hard time to get the sysfs support to work right. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: SCSI errors on powerpc with 2.6.24-rc6-mm1
FUJITA Tomonori wrote: > On Thu, 27 Dec 2007 10:08:25 +0530 > Balbir Singh <[EMAIL PROTECTED]> wrote: > >> FUJITA Tomonori wrote: >>> On Mon, 24 Dec 2007 10:18:50 +0530 >>> Balbir Singh <[EMAIL PROTECTED]> wrote: >>> >> [snip] >> >>> I might break the IOMMU code. Can you reproduce it easily? If so, >>> reverting my IOMMU patches (I've attached a patch to revert them) fix >>> the problem? >> [snip] >> >> >> Yes, this patch fixes the problem for me. > > Thanks, so you can reproduce it easily, right? > Yes, quite easily > The problem is that I don't want to revert these changes. I'll see > how these changes cause the problem shortly. I'll try and find some bandwidth to review/test the patches and help you figure out the right solution. -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG][PATCH] bluetooth: put_device before device_del fix
Because of workqueue delay, the put_device could be called before device_del,
so move it to del_conn.
Signed-off-by: Dave Young <[EMAIL PROTECTED]>
---
net/bluetooth/hci_conn.c | 10 +-
net/bluetooth/hci_sysfs.c |1 +
2 files changed, 2 insertions(+), 9 deletions(-)
diff -upr linux/net/bluetooth/hci_conn.c linux.new/net/bluetooth/hci_conn.c
--- linux/net/bluetooth/hci_conn.c 2007-12-27 13:12:48.0 +0800
+++ linux.new/net/bluetooth/hci_conn.c 2007-12-27 13:17:50.0 +0800
@@ -254,22 +254,14 @@ int hci_conn_del(struct hci_conn *conn)
}
tasklet_disable(>tx_task);
-
- hci_conn_del_sysfs(conn);
-
hci_conn_hash_del(hdev, conn);
if (hdev->notify)
hdev->notify(hdev, HCI_NOTIFY_CONN_DEL);
-
tasklet_enable(>tx_task);
-
skb_queue_purge(>data_q);
-
+ hci_conn_del_sysfs(conn);
hci_dev_put(hdev);
- /* will free via device release */
- put_device(>dev);
-
return 0;
}
diff -upr linux/net/bluetooth/hci_sysfs.c linux.new/net/bluetooth/hci_sysfs.c
--- linux/net/bluetooth/hci_sysfs.c 2007-12-27 13:12:48.0 +0800
+++ linux.new/net/bluetooth/hci_sysfs.c 2007-12-27 13:14:06.0 +0800
@@ -320,6 +320,7 @@ static void del_conn(struct work_struct
{
struct hci_conn *conn = container_of(work, struct hci_conn, work);
device_del(>dev);
+ put_device(>dev);
}
void hci_conn_del_sysfs(struct hci_conn *conn)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1: __raw_spin_is_contended undefined
On Wed, Dec 26, 2007 at 09:21:58PM -0500, Joseph Fannin wrote: > On Sat, Dec 22, 2007 at 11:30:56PM -0800, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ > > > > This doesn't build on powerpc with my .config: > > In file included from arch/powerpc/kernel/asm-offsets.c:17: > include/linux/sched.h: In function ???spin_needbreak???: > include/linux/sched.h:1947: error: implicit declaration of function > ???__raw_spin_is_contended??? > > I don't see where __raw_spin_is_contended is defined for any arch > other than x86, so I guess this will happen on any non-x86 arch when > SMP=y and PREEMPT=y are set? And CONFIG_GENERIC_LOCKBREAK is not defined, which is what powerpc needs. Thanks for reporting, Nick --- Index: linux-2.6/arch/powerpc/Kconfig === --- linux-2.6.orig/arch/powerpc/Kconfig +++ linux-2.6/arch/powerpc/Kconfig @@ -53,6 +53,11 @@ config RWSEM_XCHGADD_ALGORITHM bool default y +config GENERIC_LOCKBREAK + bool + default y + depends on SMP && PREEMPT + config ARCH_HAS_ILOG2_U32 bool default y -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG][PATCH -mm] bluetooth : rfcomm add get/put device in del_conn
On Dec 26, 2007 11:13 AM, Dave Young <[EMAIL PROTECTED]> wrote:
>
> On Tue, Dec 25, 2007 at 06:07:24PM +0800, Dave Young wrote:
> > On Dec 25, 2007 6:03 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> > > Due to 2.6.24-rc6-mm1 kernel changes (maybe kobject or driver core), If I
> > > exec:
> > >
> > > rfcomm connect 0 1
> > >
> > > kernel will oops after connect timeout.
> > >
> > > hand copy some oops text:
> > >
> > > EIP is at driver_sysfs_remove+0x1a/0x40
> > > Call Trace:
> > > show_trace_log_lvl+0x1a/0x30
> > > show_stack_log_lvl+0x9a/0xc0
> > > show_registers+0xc7/0x270
> > > die+0x129/0x240
> > > do_page_fault+0x3a1/0x670
> > > error_code+0x72/0x78
> > > __device_release_driver+0x1e/0xa0
> > > device_release_driver+0x30/0x50
> > > bus_remove_device+0x63/0x90
> > > device_del+0x55/0x190
> > > del_conn+0xb/0x10 [bluetooth]
> > > run_workqueue+0xe1/0x210
> > > worker_thread+0x99/0xf0
> > > kthread+0x5c/0xa0
> > > kernel_thread_helper+0x7/0x18
> > >
> > > (The remote bluetooth device is a mobile phone which is power off)
> > >
> > > The reason is that in bus_remobe_dev, the klist_del function will release
> > > the device, so just add a get/put pair around the device_del in del_conn.
> > >
> > > Signed-off-by: Dave Young <[EMAIL PROTECTED]>
> > >
> > > ---
> > > net/bluetooth/hci_sysfs.c |2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff -upr linux/net/bluetooth/hci_sysfs.c
> > > linux.new/net/bluetooth/hci_sysfs.c
> > > --- linux/net/bluetooth/hci_sysfs.c 2007-12-25 17:45:09.0
> > > +0800
> > > +++ linux.new/net/bluetooth/hci_sysfs.c 2007-12-25 17:45:51.0
> > > +0800
> > > @@ -319,7 +319,9 @@ void hci_conn_add_sysfs(struct hci_conn
> > > static void del_conn(struct work_struct *work)
> > > {
> > > struct hci_conn *conn = container_of(work, struct hci_conn, work);
> > > + get_device(>dev);
> > > device_del(>dev);
> > > + put_device(>dev);
> > > }
> > >
> > > void hci_conn_del_sysfs(struct hci_conn *conn)
> > >
> >
> > Hi greg,
> >
> > BTW, Is it a possible bug of driver core or kobject ?
> >
>
> In device_del
>
> if(parent)
> klist_del() will drop the kref of device
>
> and then in bus_remove_device
> klist_del() will drop it again, so the device would be released.
>
> then the following works will oops.
>
> So might my patch is a wrong fix. how about the below one:
>
> Signed-off-by: Dave Young <[EMAIL PROTECTED]>
>
> ---
> drivers/base/core.c |2 ++
> 1 file changed, 2 insertions(+)
>
> diff -upr linux/drivers/base/core.c linux.new/drivers/base/core.c
> --- linux/drivers/base/core.c 2007-12-26 11:00:49.0 +0800
> +++ linux.new/drivers/base/core.c 2007-12-26 11:01:18.0 +0800
> @@ -926,6 +926,7 @@ void device_del(struct device * dev)
> struct device * parent = dev->parent;
> struct class_interface *class_intf;
>
> + dev = get_device(dev);
> if (parent)
> klist_del(>knode_parent);
> if (MAJOR(dev->devt))
> @@ -966,6 +967,7 @@ void device_del(struct device * dev)
> cleanup_device_parent(dev);
> kobject_del(>kobj);
> put_device(parent);
> + put_device(dev);
> }
>
> /**
>
Hi all,
The patches in this thread of me are wrong fixes, I'm sorry for this.
I've found the real problem(BUG), it's in bluetooth connection code,
because of workqueue delay, the device could be put before the
device_del called.
I will submit a new patch in a while.
Regards
dave
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: SCSI errors on powerpc with 2.6.24-rc6-mm1
On Thu, 27 Dec 2007 10:08:25 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote: > FUJITA Tomonori wrote: > > On Mon, 24 Dec 2007 10:18:50 +0530 > > Balbir Singh <[EMAIL PROTECTED]> wrote: > > > [snip] > > > > > I might break the IOMMU code. Can you reproduce it easily? If so, > > reverting my IOMMU patches (I've attached a patch to revert them) fix > > the problem? > > [snip] > > > Yes, this patch fixes the problem for me. Thanks, so you can reproduce it easily, right? The problem is that I don't want to revert these changes. I'll see how these changes cause the problem shortly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: SCSI errors on powerpc with 2.6.24-rc6-mm1
FUJITA Tomonori wrote: > On Mon, 24 Dec 2007 10:18:50 +0530 > Balbir Singh <[EMAIL PROTECTED]> wrote: > [snip] > > I might break the IOMMU code. Can you reproduce it easily? If so, > reverting my IOMMU patches (I've attached a patch to revert them) fix > the problem? [snip] Yes, this patch fixes the problem for me. Tested-by: Balbir Singh <[EMAIL PROTECTED]> -- Warm Regards, Balbir Singh Linux Technology Center IBM, ISTL -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] sg_ring: convert core ATA code to sg_ring.
Hello, Rusty. Rusty Russell wrote: > On Wednesday 26 December 2007 19:36:36 Tejun Heo wrote: >> It would be better to build upon sg chaining as we already have it. I >> think it can be made much easier with a bit more safe guards, >> generalization and some helpers. > > I did this work to replace sg chaining. The current chaining code gives > us longer sgs, and (if used carefully) the ability to append in some > circumstances. But it's clumsy, and we can do better. This is my attempt. Ah.. okay. That makes sense then. I fully agree that sg chaining as it currently stands is pretty ugly to use. Appending extra entries requires reserving one extra space in the sg list to be appended to accommodate the last entry of the original list, which will be used for chaining now. Also, it's quite brittle in that information can get out of sync easily (there's no one API for sg list manipulation, things have to be done manually). > I understand that people are experiencing whiplash from the idea of > another change just after the sg chaining changes which have already gone in. > > > At the very least, I think I'll have to come up with a better transition > plan for SCSI drivers, rather than trying to convert them all at once... In > theory, sg chaining can be done through the sg ring arrays, but that's pretty > horrible. I don't necessarily think large one time conversion is bad. They're necessary at times and make sense when they can increase long term maintainability of the code. One thing I'm concerned about is the mixture of sg chaining and sg ring. It would be best if we can agree on conversion plan (or sg chaining extension plan). Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net/ipv4/netfilter/ip_tables.c: remove some inlines
On Monday 17 December 2007 14:47, Patrick McHardy wrote: > Please CC netfilter-devel on netfilter patches. > > Denys Vlasenko wrote: > > Hi Patrick, Harald, > > > > I was working on unrelated problem and noticed that ip_tables.c > > seem to abuse inline. I prepared a patch which removes inlines > > except those which are used by packet matching code > > (and thus are really performance-critical). > > I added comments explaining that remaining inlines are > > performance critical. > > > > Result as reported by size: > > > >textdata bss dec hex filename > > - 6451 380 8869191b07 ip_tables.o > > + 6339 348 7267591a67 ip_tables.o > > > > Please take this patch into netfilter queue. > > This clashes with my pending patches, which I'll push upstream > today. I also spent some time resyncing ip_tables and ip6_tables > so a diff of both (with some sed'ing) shows only the actual > differences, so please update ip6_tables as well. I would be happy to rediff the patch. Which tree should I sync against in order to not collide with your changes? -- vda -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Exporting capability code/name pairs
This patch enables to export the code/name pairs of capabilities under
/capability of securityfs.
In the current libcap, it obtains the list of capabilities from header file
on the build environment statically. However, it is not enough portable
between different versions of kernels, because an already built libcap
cannot have knowledge about new added capabilities.
Dynamic collection of code/name pairs of capabilities will resolve this
matter.
But it is not perfect one. I have a bit concern about this patch now.
1. I want to generate cap_entries array from linux/capability.h
automatically. Is there any good idea?
2. We have to mount securityfs explicitly, or using /etc/fstab.
It can make a matter when we want to use this features
in very early boot sequence.
Any comment please.
usage:
---
# mount -t securityfs none /sys/kernel/security
# cd /sys/kernel/security/capability
# ls
cap_audit_controlcap_kill cap_setpcap cap_sys_rawio
cap_audit_write cap_lease cap_setuid cap_sys_resource
cap_chowncap_linux_immutable cap_sys_admin cap_sys_time
cap_dac_override cap_mknod cap_sys_bootcap_sys_tty_config
cap_dac_read_search cap_net_admin cap_sys_chroot index
cap_fowner cap_net_bind_service cap_sys_module version
cap_fsetid cap_net_broadcast cap_sys_nice
cap_ipc_lock cap_setfcap cap_sys_pacct
cap_ipc_ownercap_setgidcap_sys_ptrace
# cat cap_audit_write ; echo
29
# cat cap_sys_chroot ; echo
18
# cat version ; echo
0x19980330
# cat index; echo
31
#
--
OSS Platform Development Division, NEC
KaiGai Kohei <[EMAIL PROTECTED]>
Signed-off-by: KaiGai Kohei <[EMAIL PROTECTED]>
---
capability.c | 127 +++
1 file changed, 127 insertions(+)
diff --git a/kernel/capability.c b/kernel/capability.c
index efbd9cd..5d9bf53 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -245,3 +245,131 @@ int capable(int cap)
return __capable(current, cap);
}
EXPORT_SYMBOL(capable);
+
+/*
+ * Capability code/name pair exporting
+ */
+
+/*
+ * capability code/name pairs are exported under /sys/security/capability/
+ */
+struct cap_entry_data {
+ unsigned int code;
+ const char *name;
+};
+
+static struct cap_entry_data cap_entries[] = {
+ /* max number of supported format */
+ { _LINUX_CAPABILITY_VERSION,"version" },
+ /* max number of capability */
+ { CAP_LAST_CAP, "index" },
+ /* list of capabilities */
+ { CAP_CHOWN,"cap_chown" },
+ { CAP_DAC_OVERRIDE, "cap_dac_override" },
+ { CAP_DAC_READ_SEARCH, "cap_dac_read_search" },
+ { CAP_FOWNER, "cap_fowner" },
+ { CAP_FSETID, "cap_fsetid" },
+ { CAP_KILL, "cap_kill" },
+ { CAP_SETGID, "cap_setgid" },
+ { CAP_SETUID, "cap_setuid" },
+ { CAP_SETPCAP, "cap_setpcap" },
+ { CAP_LINUX_IMMUTABLE, "cap_linux_immutable" },
+ { CAP_NET_BIND_SERVICE, "cap_net_bind_service" },
+ { CAP_NET_BROADCAST,"cap_net_broadcast" },
+ { CAP_NET_ADMIN,"cap_net_admin" },
+ { CAP_NET_RAW, "cap_net_admin" },
+ { CAP_IPC_LOCK, "cap_ipc_lock" },
+ { CAP_IPC_OWNER,"cap_ipc_owner" },
+ { CAP_SYS_MODULE, "cap_sys_module" },
+ { CAP_SYS_RAWIO,"cap_sys_rawio" },
+ { CAP_SYS_CHROOT, "cap_sys_chroot" },
+ { CAP_SYS_PTRACE, "cap_sys_ptrace" },
+ { CAP_SYS_PACCT,"cap_sys_pacct" },
+ { CAP_SYS_ADMIN,"cap_sys_admin" },
+ { CAP_SYS_BOOT, "cap_sys_boot" },
+ { CAP_SYS_NICE, "cap_sys_nice" },
+ { CAP_SYS_RESOURCE, "cap_sys_resource" },
+ { CAP_SYS_TIME, "cap_sys_time" },
+ { CAP_SYS_TTY_CONFIG, "cap_sys_tty_config" },
+ { CAP_MKNOD,"cap_mknod" },
+ { CAP_LEASE,"cap_lease" },
+ { CAP_AUDIT_WRITE, "cap_audit_write" },
+ { CAP_AUDIT_CONTROL,"cap_audit_control" },
+ { CAP_SETFCAP, "cap_setfcap" },
+ { CAP_MAC_OVERRIDE, "cap_mac_override" },
+ { CAP_MAC_ADMIN,"cap_mac_admin" },
+ { -1, NULL},
+};
+
+static ssize_t cap_entry_read(struct file *file, char __user *buffer,
+ size_t count, loff_t *ppos)
+{
+ struct cap_entry_data *cap_entry;
+ size_t len, ofs = *ppos;
+ char tmp[32];
+ int rc;
+
+ cap_entry =
Re: RFC: permit link(2) to work across --bind mounts ?
Mark Lord wrote: > Why does link(2) not support hard-linking across bind mount points > of the same underlying filesystem ? do we need link(2) at all? bind mounts are supposed to be (hard/soft) link minus the headaches. -- Democracy is about two wolves and a sheep deciding what to eat for dinner. begin:vcard fn:Rogelio M. Serrano Jr n:M. Serrano Jr;Rogelio org:SMSG Communications Philippines;Technical Department adr:;;Republic of the Philippines email;internet:[EMAIL PROTECTED] title:Programmer tel;work:+6327534145 tel;home:+6329527026 tel;cell:+639209202267 x-mozilla-html:FALSE version:2.1 end:vcard signature.asc Description: OpenPGP digital signature
Re: More verizon problems
Gene Heskett wrote: Resend, with more odd data from fetchmail.log appended. Just for a heads up, for about the last 8 hours, verizon, my ISP, has been inserting themselves into the path between my gmail account and my local fetchmail of this email subcription at pop.gmail.com. Worse yet they are bouncing the messages in a way that makes it look as if I sent them when they in fact originated at vger.kernel.org. Somehow they have convinced themselves that any mailing list this busy must be spam and is to be bounced. Either that or they, verizon, since they sleep with M$, have taken a large under the table payment to screw with linux in any way they can. It bears investigating. I called just now and screamed bloody murder at tech support, and in about 15 minutes I started getting the list again, BUT they are still in the path between vger and my fetchmail daemon as shown below. Or at least that is how I am interpreting the incoming headers, which now look like this by the time they hit my inbox but with my SA headers clipped: --- Received: from incoming.verizon.net [206.46.232.10] by coyote.coyote.den with POP3 (fetchmail-6.3.6) for <[EMAIL PROTECTED]> (single-drop); Thu, 20 Dec 2007 21:10:08 -0500 (EST) Received: from mailbag1.bizmailsrvcs.net ([172.18.12.131]) by vms051.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTP id <[EMAIL PROTECTED]> for [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:08:11 -0600 (CST) Received: from [64.233.162.238] (port= helo=nz-out-0506.google.com) by mailbag1.bizmailsrvcs.net with esmtp (Exim 4.68) (envelope-from <[EMAIL PROTECTED]>) id 1J5XG9-00052G-Dufor [EMAIL PROTECTED]; Thu, 20 Dec 2007 20:05:09 -0600 Right here I see that google forwarded your mail from their (google) server sending to the bizmailsrvcs.net (verizon) server, and VZ didn't jump in the path, google put them there. Received: by nz-out-0506.google.com with SMTP id x7so90741nzc.3 for <[EMAIL PROTECTED]>; Thu, 20 Dec 2007 18:08:08 -0800 (PST) Most likely cause is that you forwarded mail from google to verizon, which is probably a bad thing on many levels. Not Verizon's fault. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: SCSI errors on powerpc with 2.6.24-rc6-mm1
On Mon, 24 Dec 2007 10:18:50 +0530
Balbir Singh <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've just seen this on my dmesg, this is new, never seen this before on
> this box and it happens only with this version of the kernel.
>
> In this configuration, the page size is set to 64K and I've enabled fake
> NUMA nodes on PowerPC.
>
> tce_buildmulti_pSeriesLP: plpar_tce_put failed. rc=-4
> index = 0x402
> npages = 0x0
> tce[0] val = 0x15ad0001
> Call Trace:
> [cffe74f0] [c00491a4]
> .tce_buildmulti_pSeriesLP+0x26c/0x2ac (unreliable)
> [cffe75c0] [c00295e4] .iommu_map_sg+0x1d4/0x418
> [cffe76d0] [c0028664] .dma_iommu_map_sg+0x3c/0x50
> [cffe7750] [c03b6c30] .scsi_dma_map+0x70/0x94
> [cffe77d0] [c03dedbc] .ipr_queuecommand+0x300/0x500
> [cffe7880] [c03ae964] .scsi_dispatch_cmd+0x21c/0x2b8
> [cffe7920] [c03b67a0] .scsi_request_fn+0x310/0x460
> [cffe79d0] [c024ab90] .blk_run_queue+0x94/0xec
> [cffe7a70] [c03b3b08] .scsi_run_queue+0x24c/0x27c
> [cffe7b20] [c03b4424] .scsi_next_command+0x48/0x70
> [cffe7bc0] [c03b4b48] .scsi_end_request+0xbc/0xe4
> [cffe7c60] [c03b5294] .scsi_io_completion+0x170/0x3e8
> [cffe7d40] [c03ae0e4] .scsi_finish_command+0xb4/0xd4
> [cffe7dd0] [c03b584c] .scsi_softirq_done+0x114/0x138
> [cffe7e60] [c024af70] .blk_done_softirq+0xa0/0xd0
> [cffe7ef0] [c007a2a0] .__do_softirq+0xa8/0x164
> [cffe7f90] [c0027edc] .call_do_softirq+0x14/0x24
> [c0003e183950] [c000bdcc] .do_softirq+0x74/0xc0
> [c0003e1839e0] [c007a450] .irq_exit+0x5c/0xac
> [c0003e183a60] [c000c414] .do_IRQ+0x17c/0x1f4
> [c0003e183b00] [c0004c24] hardware_interrupt_entry+0x24/0x28
> --- Exception: 501 at .ppc64_runlatch_off+0x28/0x60
> LR = .pseries_dedicated_idle_sleep+0xd8/0x1a4
> [c0003e183df0] [c0048494]
> .pseries_dedicated_idle_sleep+0x78/0x1a4 (unreliable)
> [c0003e183e80] [c001110c] .cpu_idle+0x10c/0x1e8
> [c0003e183f00] [c002b5b0] .start_secondary+0x1b4/0x1d8
> [c0003e183f90] [c00083c4] .start_secondary_prolog+0xc/0x10
I might break the IOMMU code. Can you reproduce it easily? If so,
reverting my IOMMU patches (I've attached a patch to revert them) fix
the problem?
Thanks,
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index ff2a62d..59899b2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -244,9 +244,6 @@ config IOMMU_VMERGE
Most drivers don't have this problem; it is safe to say Y here.
-config IOMMU_HELPER
- def_bool PPC64
-
config HOTPLUG_CPU
bool "Support for enabling/disabling CPUs"
depends on SMP && HOTPLUG && EXPERIMENTAL && (PPC_PSERIES || PPC_PMAC)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 6fcb7cb..1806d96 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -31,8 +31,8 @@ static inline unsigned long device_to_mask(struct device *dev)
static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
- return iommu_alloc_coherent(dev, dev->archdata.dma_data, size,
- dma_handle, device_to_mask(dev), flag,
+ return iommu_alloc_coherent(dev->archdata.dma_data, size, dma_handle,
+ device_to_mask(dev), flag,
dev->archdata.numa_node);
}
@@ -52,7 +52,7 @@ static dma_addr_t dma_iommu_map_single(struct device *dev,
void *vaddr,
size_t size,
enum dma_data_direction direction)
{
- return iommu_map_single(dev, dev->archdata.dma_data, vaddr, size,
+ return iommu_map_single(dev->archdata.dma_data, vaddr, size,
device_to_mask(dev), direction);
}
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 18e8860..050e9ac 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -82,19 +81,17 @@ static int __init setup_iommu(char *str)
__setup("protect4gb=", setup_protect4gb);
__setup("iommu=", setup_iommu);
-static unsigned long iommu_range_alloc(struct device *dev,
- struct iommu_table *tbl,
+static unsigned long iommu_range_alloc(struct iommu_table *tbl,
unsigned long npages,
unsigned long *handle,
unsigned long mask,
unsigned int align_order)
{
-
Re: 2.6.24-rc6-mm1: some section mismatches on sparc64
From: Mariusz Kozlowski <[EMAIL PROTECTED]> Date: Wed, 26 Dec 2007 13:29:07 +0100 > WARNING: vmlinux.o(.text+0x46b04): Section mismatch: reference to > .init.text:sun4v_ktsb_register (between 'smp_callin' and > 'smp_fill_in_sib_core_maps') Well known and I see them every build and so does everyone else on sparc64. They are harmless and as time allows I try to find ways to get rid of them but it's very low priority. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1: __raw_spin_is_contended undefined
On Sat, Dec 22, 2007 at 11:30:56PM -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc6/2.6.24-rc6-mm1/ > This doesn't build on powerpc with my .config: In file included from arch/powerpc/kernel/asm-offsets.c:17: include/linux/sched.h: In function ‘spin_needbreak’: include/linux/sched.h:1947: error: implicit declaration of function ‘__raw_spin_is_contended’ I don't see where __raw_spin_is_contended is defined for any arch other than x86, so I guess this will happen on any non-x86 arch when SMP=y and PREEMPT=y are set? This comes from "spinlock: lockbreak cleanup" in git-x86. -- Joseph Fannin [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: list corruption on ib_srp load in v2.6.24-rc5
On Wed, 26 Dec 2007 12:14:11 -0500
David Dillow <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2007-12-23 at 01:41 +0900, FUJITA Tomonori wrote:
> > transport_container_unregister(>rport_attr_cont) should not fail here.
> >
> > It fails because there is still a srp rport.
> >
> > I think that as Pete pointed out, srp_remove_one needs to call
> > srp_remove_host.
> >
> > Can you try this?
>
> That patched oopsed in scsi_remove_host(), but reversing the order has
> survived over 500 insert/probe/remove cycles.
Thanks,
Can you post the oops message? The srp class might have bugs related
to it.
> Tested-by: David Dillow <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
> b/drivers/infiniband/ulp/srp/ib_srp.c
> index 950228f..77e8b90 100644
> --- a/drivers/infiniband/ulp/srp/ib_srp.c
> +++ b/drivers/infiniband/ulp/srp/ib_srp.c
> @@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device *device)
> list_for_each_entry_safe(target, tmp_target,
>>target_list, list) {
> scsi_remove_host(target->scsi_host);
> + srp_remove_host(target->scsi_host);
> srp_disconnect_target(target);
> ib_destroy_cm_id(target->cm_id);
> srp_free_target_ib(target);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 ports could not bond to a aggregator in 802.3ad mode issue
Yes, you are right. The incorrect behavior is due to we don't setup the lacpdu of switch correctly. The bonding driver is correct. Thanks for your comment! I do not believe so. IEEE 802.3 section 43.3.9 states, in part, "Links that are not successful candidates for aggregation (e.g., links that are attached to other devices that cannot perform aggregation or links that have been manually configured to be non-aggregatable) are enabled to operate as individual IEEE 802.3 links. For consistency of modeling, such a link is regarded as being attached to a compatible Aggregator that can only be associated with a single link. That is, from the perspective of Link Aggregation, non-aggregated links are not a special case; they compose an aggregation with a maximum membership of one link." I do not see that it is correct to attach the links to a common aggregator, as your output indicates that no partner association has been created (the Partner MAC is all zeroes) and the links are therefore apparently connected to a device that cannot perform aggregation. --- -Jay Vosburgh, IBM Linux Technology Center, [EMAIL PROTECTED] Regards, Lewis Li -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: read-ahead in NFS server
saeed bishara wrote: Hi, my NFS server seems not to utilize the read-ahead feature, my exported dir is located on ext3 fs over sata disk. the sata controller can issue commands up to 1MB, also I modified the read ahead under the sys to 1MB. but when the client do reads in 32KB chunks (rsize), I can see in the server side that all IOs are ~32KB. my kernel version is 2.6.22.7. according to the nfsd code, the NFS server should utilize the read-ahead feature, but what should I do to make it work? (linux-nfs added to cc) I cannot speak for the NFS server code specifically, but 32kb sounds like a network read (or write) data size limit. Are you using TCP? Are you using NFSv4, or an older version? Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Wed, 2007-12-26 at 20:57 -0500, Vivek Goyal wrote: [...] > > 9. Now, you are in the original kernel again. You can read/write the > >memory image of kexeced kernel via /proc/kimgcore. > > > > Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't > we have just one say /proc/vmcore. Irrespective of what kernel you are > in /proc/vmcore gives you the access to the memory of kernel which was > previously booted. In theory we can kexec another kernel even in a kexeced kernel, that is, in kernel A kexec kernel B, and in kernel B kexec another kernel C. In this situation, both /proc/vmcore and /proc/kimgcore has valid contents. So I think, it may be better to keep two interfaces. In fact, current kexec jump implementation use a dummy "jump back helper image" in kexeced kernel to jump back to the original kernel. The "jump back helper image" has no PT_LOAD segment, it is used to provide a struct kimage (including control page, swap page) and entry point to jump back. Best Regards, Huang Ying -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] sg_ring for scsi
On Wed, 26 Dec 2007 11:27:40 +1100
Rusty Russell <[EMAIL PROTECTED]> wrote:
> On Friday 21 December 2007 15:37:46 FUJITA Tomonori wrote:
> > Some scsi drivers like ips access to sglist in a tricky way.
>
> Indeed. I fail to see how this code works, in fact:
>
> drivers/scsi/ips.c:ips_queue() line 1101
>
> if (ips_is_passthru(SC)) {
>
> ips_copp_wait_item_t *scratch;
>
> /* A Reset IOCTL is only sent by the boot CD in extreme cases.
> */
> /* There can never be any system activity ( network or disk ),
> but check */
> /* anyway just as a good practice.
> */
> pt = (ips_passthru_t *) scsi_sglist(SC);
> if ((pt->CoppCP.cmd.reset.op_code == IPS_CMD_RESET_CHANNEL) &&
> (pt->CoppCP.cmd.reset.adapter_flag == 1)) {
>
> Casting the scsi_sglist(SC) (which ips_is_passthrough treated as a
> scatterlist) to an ips_passthrough_t seems completely bogus. It looks like
> it wants to access the region mapped by the scatterlist.
Yeah, it seems to be broken.
> There are many signs through the code that it needs a great deal of
> work: what is the purpose of sg_break? Why does the code check if kmap_atomic
> fails?
sg_break is a workaround for the hardware restrictions, I think.
> ===
> Convert the ips SCSI driver to sg_ring.
>
> Slightly non-trivial conversion, will need testing.
As I said, I don't think that converting SCSI drivers to sg_ring (with
lots of non-trivial work) provides any benefits. Surely, sg_ring
enables us to modify sg lists but SCSI drivers don't need the
feature. What SCSI drivers needs is just a efficient way to get the
next sg entry (they use 'sg++' in the past and sg_next now).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3 -mm] kexec jump -v8
On Fri, Dec 21, 2007 at 03:33:19PM +0800, Huang, Ying wrote: [..] > The following user-space tools can be used with kexec jump. > > 1. kexec-tools needs to be patched to support kexec jump. The patches >and the precompiled kexec can be download from the following URL: >source: > http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-src_git_kh8.tar.bz2 >patches: > http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec-tools-patches_git_kh8.tar.bz2 >binary: > http://khibernation.sourceforge.net/download/release_v8/kexec-tools/kexec_git_kh8 > > 2. makedumpfile with patches are used as memory image saving tool, it >can exclude free pages from original kernel memory image file. The >patches and the precompiled makedumpfile can be download from the >following URL: >source: > http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-src_cvs_kh8.tar.bz2 >patches: > http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile-patches_cvs_kh8.tar.bz2 >binary: > http://khibernation.sourceforge.net/download/release_v8/makedumpfile/makedumpfile_cvs_kh8 > > 3. A simplest memory image restoring tool named "krestore" is >implemented. It can be downloaded from the following URL: >source: > http://khibernation.sourceforge.net/download/release_v8/krestore/krestore-src_cvs_kh8.tar.bz2 >binary: > http://khibernation.sourceforge.net/download/release_v8/krestore/krestore_cvs_kh8 > > An initramfs image can be used as the root file system of kexeced > kernel. An initramfs image built with "BuildRoot" can be downloaded > from the following URL: > initramfs image: > http://khibernation.sourceforge.net/download/release_v8/initramfs/rootfs_cvs_kh8.gz > All user space tools above are included in the initramfs image. > > > Usage example of jumping between original and kexeced kernel: > > 1. Compile and install patched kernel with following options selected: > > CONFIG_X86_32=y > CONFIG_RELOCATABLE=y > CONFIG_KEXEC=y > CONFIG_CRASH_DUMP=y > CONFIG_PM=y > > 2. Build an initramfs image contains kexec-tool, or download the >pre-built initramfs image, called rootfs.gz in following text. > > 3. Boot kernel compiled in step 1. > > 4. Load kernel compiled in step 1 with /sbin/kexec. If You want to use >"krestore" tool, the --elf64-core-headers should be specified in >command line of /sbin/kexec. The shell command line can be as >follow: > >/sbin/kexec --load-jump-back /boot/bzImage --mem-min=0x10 > --mem-max=0xff --elf64-core-headers --initrd=rootfs.gz > > 5. Boot the kexeced kernel with following shell command line: > >/sbin/kexec -e > > 6. The kexeced kernel will boot as normal kexec. In kexeced kernel the >memory image of original kernel can read via /proc/vmcore or >/dev/oldmem, and can be written via /dev/oldmem. You can >save/restore/modify it as you want to. > > 7. Prepare jumping back from kexeced kernel with following shell >command lines: > >jump_back_entry=`cat /proc/cmdline | tr ' ' '\n' | grep > kexec_jump_back_entry | cut -d '='` >/sbin/kexec --load-jump-back-helper=$jump_back_entry > > 8. Jump back to the original kernel with following shell command line: > >/sbin/kexec -e > > 9. Now, you are in the original kernel again. You can read/write the >memory image of kexeced kernel via /proc/kimgcore. > Why do we need two interfaces, /proc/vmcore and /proc/kimgcore? Can't we have just one say /proc/vmcore. Irrespective of what kernel you are in /proc/vmcore gives you the access to the memory of kernel which was previously booted. Thanks Vivek -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arch/x86: Use offsetof
Jan Engelhardt wrote: On Dec 26 2007 17:01, H. Peter Anvin wrote: @@ -215,7 +215,9 @@ asmlinkage int sys_vm86old(struct pt_reg ret = -EFAULT; if (tmp) goto out; - memset(, 0, (int) - (int)); + memset(, 0, + offsetof(struct kernel_vm86_struct, regs32) - + offsetof(struct kernel_vm86_struct, vm86plus)); I do not think this makes it more readable... (int) -> (char *) would make it portable and readable, AFAICT. Pavel The right way to do it is: memset(, 0, sizeof info.vm86plus); Either way, downcasting a pointer to (int) is dangerous, even if this one occurrence happens to be in 32-bit-only code. Actually, it would be safe (although stupid) in this case since the difference would still be 32 bits or less. Doesn't make it any less wrong. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arch/x86: Use offsetof
On Dec 26 2007 17:01, H. Peter Anvin wrote: >> > @@ -215,7 +215,9 @@ asmlinkage int sys_vm86old(struct pt_reg >> > ret = -EFAULT; >> > if (tmp) >> >goto out; >> > - memset(, 0, (int) - (int)); >> > + memset(, 0, >> > + offsetof(struct kernel_vm86_struct, regs32) - >> > + offsetof(struct kernel_vm86_struct, vm86plus)); >> >> I do not think this makes it more readable... (int) -> (char *) would >> make it portable and readable, AFAICT. >> Pavel > > The right way to do it is: > > memset(, 0, sizeof info.vm86plus); Either way, downcasting a pointer to (int) is dangerous, even if this one occurrence happens to be in 32-bit-only code. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Device node - How does kernel know about it
Hi, How do the device nodes work as an interface between user and kernel programs, and how to go debugging it? This is as part of my debugging effort on an embedded board. * It all started with the problem of "not printing" any thing that comes from ramdisk (echo and printf statements), while kernel printk's work perfectly fine. * Ramdisk is also executing fine, just that prints are not coming out of serial. I can see the execution of various user programs with a printk in sys_execve() routine. Ramdisk has all the required files like /dev/console, /dev/ttyS0, etc. * Looking further into tty driver, I noticed that call to tty_write() or do_tty_write() is not happening at all. So, somewhere the interface between kernel and user program is lost. * Just to check it out, I tried to write a small kernel module and a test program. - Attached memtest.c module (not really testing memory there. :-)) - Attached testmemtest.c user program, that just open's it and reads the information - Created a device node using "mknod /dev/memtest c 168 0" - When I do "insmod memtest.ko" inside the ramdisk bootup scripts, I could see all the printk's on the console - When I execute "testmemtest" next in the same script, it does not display the printk inside of memtest.c module. This only indicates that read call did not really go to the kernel side. - Just to check my program's validity, I checked on a similar machine and all the code works fine. - "uname -r" also matches with what I built. So, chances of exiting from open call because of mismatch is remote. Since userland cannot print, I have no idea what exactly is happening there. Now going back to the original question... How does a kernel know about device nodes and how to link with it. Basically I believe interface between user programs and kernel is lost at device nodes. Appreciate any help in continuing my debugging efforts. Thanks Siva memtest.c Description: memtest.c testmemtest.c Description: testmemtest.c
[PATCH] SH/Dreamcast - add support for GD-Rom device
This patch adds support for the CD-Rom drive on the SEGA Dreamcast.
The SEGA Dreamcast has a built in CD-Rom drive, electrically similar
to an ATA-3 drive, but implementing a proprietary packet interface -
the so-called Sega Packet Interface (SPI)- and also supporting a
proprietary format of disk - the Giga Disk Rom, with a 1GB capacity.
The drive is know as the "GD-Rom drive".
This patch partially implements the SPI and also supports reading GD
Rom disks. Unlike previous GD Rom drivers (which were never in the
mainline), this driver implements DMA and not PIO for reads. It is a
new driver, not a modified version of previous drivers.
This is the fourth iteration of this patch - which should work with
both 2.6-24-rc5 and Paul Mundt's 2.6.25 queue.
Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]>
diff -rupN linux-2.6-orig/drivers/block/Kconfig linux-2.6/drivers/block/Kconfig
--- linux-2.6-orig/drivers/block/Kconfig 2007-12-26 17:27:14.0 +
+++ linux-2.6/drivers/block/Kconfig 2007-12-27 00:08:39.0 +
@@ -105,6 +105,18 @@ config PARIDE
"MicroSolutions backpack protocol", "DataStor Commuter protocol"
etc.).
+config GDROM
+ tristate "SEGA Dreamcast GD-ROM drive"
+ depends on SH_DREAMCAST
+ help
+ A standard SEGA Dreamcast comes with a modified CD ROM drive called a
+ "GD-ROM" by SEGA to signify it is capable of reading special disks
+ with up to 1 GB of data. This drive will also read standard CD ROM
+ disks. Select this option to access any disks in your GD ROM drive.
+ Most users will want to say "Y" here.
+ You can also build this as a module which will be called gdrom.ko
+
+
source "drivers/block/paride/Kconfig"
config BLK_CPQ_DA
diff -rupN linux-2.6-orig/drivers/cdrom/gdrom.c linux-2.6/drivers/cdrom/gdrom.c
--- linux-2.6-orig/drivers/cdrom/gdrom.c 1970-01-01 01:00:00.0 +0100
+++ linux-2.6/drivers/cdrom/gdrom.c 2007-12-27 00:57:01.0 +
@@ -0,0 +1,776 @@
+/* GD ROM driver for the SEGA Dreamcast
+ * copyright Adrian McMenamin, 2007
+ * With thanks to Marcus Comstedt and Nathan Keynes
+ * for work in reversing PIO and DMA
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define GDROM_DEV_NAME "gdrom"
+#define GD_SESSION_OFFSET 150
+
+/* GD Rom commands */
+#define GDROM_COM_SOFTRESET 0x08
+#define GDROM_COM_EXECDIAG 0x90
+#define GDROM_COM_PACKET 0xA0
+#define GDROM_COM_IDDEV 0xA1
+
+/* GD Rom registers */
+#define GDROM_BASE_REG 0xA05F7000
+#define GDROM_ALTSTATUS_REG (GDROM_BASE_REG + 0x18)
+#define GDROM_DATA_REG (GDROM_BASE_REG + 0x80)
+#define GDROM_ERROR_REG (GDROM_BASE_REG + 0x84)
+#define GDROM_INTSEC_REG (GDROM_BASE_REG + 0x88)
+#define GDROM_SECNUM_REG (GDROM_BASE_REG + 0x8C)
+#define GDROM_BCL_REG (GDROM_BASE_REG + 0x90)
+#define GDROM_BCH_REG (GDROM_BASE_REG + 0x94)
+#define GDROM_DSEL_REG (GDROM_BASE_REG + 0x98)
+#define GDROM_STATUSCOMMAND_REG (GDROM_BASE_REG + 0x9C)
+#define GDROM_RESET_REG (GDROM_BASE_REG + 0x4E4)
+
+#define GDROM_DMA_STARTADDR_REG (GDROM_BASE_REG + 0x404)
+#define GDROM_DMA_LENGTH_REG (GDROM_BASE_REG + 0x408)
+#define GDROM_DMA_DIRECTION_REG (GDROM_BASE_REG + 0x40C)
+#define GDROM_DMA_ENABLE_REG (GDROM_BASE_REG + 0x414)
+#define GDROM_DMA_STATUS_REG (GDROM_BASE_REG + 0x418)
+#define GDROM_DMA_WAIT_REG (GDROM_BASE_REG + 0x4A0)
+#define GDROM_DMA_ACCESS_CTRL_REG (GDROM_BASE_REG + 0x4B8)
+
+#define GDROM_HARD_SECTOR 2048
+#define BLOCK_LAYER_SECTOR 512
+#define GD_TO_BLK 4
+
+static const struct {
+ int sense_key;
+ const char * const text;
+} sense_texts[] = {
+ {NO_SENSE, "GDROM: OK"},
+ {RECOVERED_ERROR, "GDROM: Recovered from error"},
+ {NOT_READY, "GDROM: Device not ready"},
+ {MEDIUM_ERROR, "GDROM: Disk not ready"},
+ {HARDWARE_ERROR, "GDROM: Hardware error"},
+ {ILLEGAL_REQUEST, "GDROM: Command has failed"},
+ {UNIT_ATTENTION, "GDROM: Device needs attention - disk may have been changed"},
+ {DATA_PROTECT, "GDROM: Data protection error"},
+ {ABORTED_COMMAND, "GDROM: Command aborted"},
+};
+
+static struct platform_device *pd;
REISER4: Attention Edward Shishkin - reiser4progs-1.0.6
REISER4: Attention Edward Shishkin (reiser4progs-1.0.6)
-
-
Hi Edward, it has been pointed out that you CHANGED reiser4progs-1.0.6
in your version
http://chichkin_i.zelnet.ru/namesys/reiser4progs-1.0.6.tar.gz
from the version previously supplied by namesys.com
ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.6.tar.gz
Does this have any relevance for REISER4 that I should know about?
I have included a diff between the two versions.
-
-
diff -pruN reiser4progs-1.0.6-namesys/include/reiser4/plugin.h
reiser4progs-1.0.6-shinkin/include/reiser4/plugin.h
--- reiser4progs-1.0.6-namesys/include/reiser4/plugin.h 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/include/reiser4/plugin.h 2007-02-27
15:25:16.0 +
@@ -273,11 +273,10 @@ enum reiser4_crypto_id {
enum reiser4_compress_mode_id {
CMODE_NONE_ID = 0x0,
- CMODE_COL8_ID = 0x1,
- CMODE_COL16_ID = 0x2,
- CMODE_COL32_ID = 0x3,
+ CMODE_LATTD_ID = 0x1,
+ CMODE_ULTIM_ID = 0x2,
+ CMODE_FORCE_ID = 0x3,
CMODE_CONVX_ID = 0x4,
- CMODE_FORCE_ID = 0x5,
CMODE_LAST_ID
};
diff -pruN reiser4progs-1.0.6-namesys/libreiser4/factory.c
reiser4progs-1.0.6-shinkin/libreiser4/factory.c
--- reiser4progs-1.0.6-namesys/libreiser4/factory.c 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/libreiser4/factory.c 2007-02-27
15:40:43.0 +
@@ -269,11 +269,10 @@ errno_t reiser4_factory_init(void) {
__load_plug(gzip1);
__load_plug(nocompress);
- __load_plug(col8);
- __load_plug(col16);
- __load_plug(col32);
- __load_plug(convx);
+ __load_plug(lattd);
+ __load_plug(ultim);
__load_plug(force);
+ __load_plug(convx);
__load_plug(clust64);
__load_plug(clust32);
diff -pruN reiser4progs-1.0.6-namesys/libreiser4/profile.c
reiser4progs-1.0.6-shinkin/libreiser4/profile.c
--- reiser4progs-1.0.6-namesys/libreiser4/profile.c 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/libreiser4/profile.c 2007-01-20
11:08:31.0 +
@@ -145,7 +145,7 @@ reiser4_profile_t defprof = {
.hidden = 0,
.max = CMODE_LAST_ID,
#endif
- .id = {CMODE_COL8_ID, 0, CMODE_PLUG_TYPE},
+ .id = {CMODE_CONVX_ID, 0, CMODE_PLUG_TYPE},
},
[PROF_CRYPTO] = {
#ifndef ENABLE_MINIMAL
diff -pruN reiser4progs-1.0.6-namesys/plugin/compress/compress_mode.c
reiser4progs-1.0.6-shinkin/plugin/compress/compress_mode.c
---
reiser4progs-1.0.6-namesys/plugin/compress/compress_mode.c 2006-11-01
14:50:34.0 +
+++
reiser4progs-1.0.6-shinkin/plugin/compress/compress_mode.c 2007-02-27
15:32:30.0 +
@@ -19,22 +19,22 @@ reiser4_plug_t nocompress_plug = {
.desc = "'Don't compress' compression mode plugin.",
};
-reiser4_plug_t col8_plug = {
- .id= {CMODE_COL8_ID, 0, CMODE_PLUG_TYPE},
- .label = "col8",
- .desc = "'Check on lattice-8' compression mode plugin.",
+reiser4_plug_t lattd_plug = {
+ .id= {CMODE_LATTD_ID, 0, CMODE_PLUG_TYPE},
+ .label = "latt",
+ .desc = "'Check on dynamic lattice' compression mode plugin.",
};
-reiser4_plug_t col16_plug = {
- .id= {CMODE_COL16_ID, 0, CMODE_PLUG_TYPE},
- .label = "col16",
- .desc = "'Check on lattice-16' compression mode plugin.",
+reiser4_plug_t ultim_plug = {
+ .id= {CMODE_ULTIM_ID, 0, CMODE_PLUG_TYPE},
+ .label = "ultim",
+ .desc = "'Check ultimately' compression mode plugin.",
};
-reiser4_plug_t col32_plug = {
- .id= {CMODE_COL32_ID, 0, CMODE_PLUG_TYPE},
- .label = "col32",
- .desc = "'Check on lattice-32' compression mode plugin.",
+reiser4_plug_t force_plug = {
+ .id= {CMODE_FORCE_ID, 0, CMODE_PLUG_TYPE},
+ .label = "force",
+ .desc = "'Compress evrything' compression mode plugin.",
};
reiser4_plug_t convx_plug = {
@@ -42,11 +42,4 @@ reiser4_plug_t convx_plug = {
.label = "conv",
.desc = "'Convert to extent' compression mode plugin.",
};
-
-reiser4_plug_t force_plug = {
- .id= {CMODE_FORCE_ID, 0, CMODE_PLUG_TYPE},
- .label = "force",
- .desc = "'Compress evrything' compression mode plugin.",
-};
-
#endif
More new features than ever. Check out the new AOL Mail ! -
http://webmail.aol.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arch/x86: Use offsetof
Al Viro wrote:
On Wed, Dec 26, 2007 at 05:01:38PM -0800, H. Peter Anvin wrote:
The right way to do it is:
memset(, 0, sizeof info.vm86plus);
If it's just one field _and_ we don't have padding we want to zero out -
certainly...
It is - [comments removed for clarity]:
struct kernel_vm86_struct {
struct kernel_vm86_regs regs;
#define VM86_TSS_ESP0 flags
unsigned long flags;
unsigned long screen_bitmap;
unsigned long cpu_type;
struct revectored_struct int_revectored;
struct revectored_struct int21_revectored;
struct vm86plus_info_struct vm86plus;
struct pt_regs *regs32;
};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
REISER4: Attention Edward Shishkin (reiser4progs-1.0.6)
REISER4: Attention Edward Shishkin (reiser4progs-1.0.6)
-
-
Hi Edward, it has been pointed out that you CHANGED reiser4progs-1.0.6
in your version
http://chichkin_i.zelnet.ru/namesys/reiser4progs-1.0.6.tar.gz
from the version previously supplied by namesys.com
ftp://ftp.namesys.com/pub/reiser4progs/reiser4progs-1.0.6.tar.gz
Does this have any relevance for REISER4 that I should know about?
I have included a diff between the two versions.
-
-
diff -pruN reiser4progs-1.0.6-namesys/include/reiser4/plugin.h
reiser4progs-1.0.6-shinkin/include/reiser4/plugin.h
--- reiser4progs-1.0.6-namesys/include/reiser4/plugin.h 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/include/reiser4/plugin.h 2007-02-27
15:25:16.0 +
@@ -273,11 +273,10 @@ enum reiser4_crypto_id {
enum reiser4_compress_mode_id {
CMODE_NONE_ID = 0x0,
- CMODE_COL8_ID = 0x1,
- CMODE_COL16_ID = 0x2,
- CMODE_COL32_ID = 0x3,
+ CMODE_LATTD_ID = 0x1,
+ CMODE_ULTIM_ID = 0x2,
+ CMODE_FORCE_ID = 0x3,
CMODE_CONVX_ID = 0x4,
- CMODE_FORCE_ID = 0x5,
CMODE_LAST_ID
};
diff -pruN reiser4progs-1.0.6-namesys/libreiser4/factory.c
reiser4progs-1.0.6-shinkin/libreiser4/factory.c
--- reiser4progs-1.0.6-namesys/libreiser4/factory.c 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/libreiser4/factory.c 2007-02-27
15:40:43.0 +
@@ -269,11 +269,10 @@ errno_t reiser4_factory_init(void) {
__load_plug(gzip1);
__load_plug(nocompress);
- __load_plug(col8);
- __load_plug(col16);
- __load_plug(col32);
- __load_plug(convx);
+ __load_plug(lattd);
+ __load_plug(ultim);
__load_plug(force);
+ __load_plug(convx);
__load_plug(clust64);
__load_plug(clust32);
diff -pruN reiser4progs-1.0.6-namesys/libreiser4/profile.c
reiser4progs-1.0.6-shinkin/libreiser4/profile.c
--- reiser4progs-1.0.6-namesys/libreiser4/profile.c 2006-11-01
14:50:34.0 +
+++ reiser4progs-1.0.6-shinkin/libreiser4/profile.c 2007-01-20
11:08:31.0 +
@@ -145,7 +145,7 @@ reiser4_profile_t defprof = {
.hidden = 0,
.max = CMODE_LAST_ID,
#endif
- .id = {CMODE_COL8_ID, 0, CMODE_PLUG_TYPE},
+ .id = {CMODE_CONVX_ID, 0, CMODE_PLUG_TYPE},
},
[PROF_CRYPTO] = {
#ifndef ENABLE_MINIMAL
diff -pruN reiser4progs-1.0.6-namesys/plugin/compress/compress_mode.c
reiser4progs-1.0.6-shinkin/plugin/compress/compress_mode.c
---
reiser4progs-1.0.6-namesys/plugin/compress/compress_mode.c 2006-11-01
14:50:34.0 +
+++
reiser4progs-1.0.6-shinkin/plugin/compress/compress_mode.c 2007-02-27
15:32:30.0 +
@@ -19,22 +19,22 @@ reiser4_plug_t nocompress_plug = {
.desc = "'Don't compress' compression mode plugin.",
};
-reiser4_plug_t col8_plug = {
- .id= {CMODE_COL8_ID, 0, CMODE_PLUG_TYPE},
- .label = "col8",
- .desc = "'Check on lattice-8' compression mode plugin.",
+reiser4_plug_t lattd_plug = {
+ .id= {CMODE_LATTD_ID, 0, CMODE_PLUG_TYPE},
+ .label = "latt",
+ .desc = "'Check on dynamic lattice' compression mode plugin.",
};
-reiser4_plug_t col16_plug = {
- .id= {CMODE_COL16_ID, 0, CMODE_PLUG_TYPE},
- .label = "col16",
- .desc = "'Check on lattice-16' compression mode plugin.",
+reiser4_plug_t ultim_plug = {
+ .id= {CMODE_ULTIM_ID, 0, CMODE_PLUG_TYPE},
+ .label = "ultim",
+ .desc = "'Check ultimately' compression mode plugin.",
};
-reiser4_plug_t col32_plug = {
- .id= {CMODE_COL32_ID, 0, CMODE_PLUG_TYPE},
- .label = "col32",
- .desc = "'Check on lattice-32' compression mode plugin.",
+reiser4_plug_t force_plug = {
+ .id= {CMODE_FORCE_ID, 0, CMODE_PLUG_TYPE},
+ .label = "force",
+ .desc = "'Compress evrything' compression mode plugin.",
};
reiser4_plug_t convx_plug = {
@@ -42,11 +42,4 @@ reiser4_plug_t convx_plug = {
.label = "conv",
.desc = "'Convert to extent' compression mode plugin.",
};
-
-reiser4_plug_t force_plug = {
- .id= {CMODE_FORCE_ID, 0, CMODE_PLUG_TYPE},
- .label = "force",
- .desc = "'Compress evrything' compression mode plugin.",
-};
-
#endif
More new features than ever. Check out the new AOL Mail ! -
http://webmail.aol.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arch/x86: Use offsetof
On Wed, Dec 26, 2007 at 05:01:38PM -0800, H. Peter Anvin wrote: > The right way to do it is: > > memset(, 0, sizeof info.vm86plus); If it's just one field _and_ we don't have padding we want to zero out - certainly... -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arch/x86: Use offsetof
Pavel Machek wrote: diff -u -p a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c --- a/arch/x86/kernel/vm86_32.c 2007-10-22 11:25:00.0 +0200 +++ b/arch/x86/kernel/vm86_32.c 2007-12-26 16:27:15.0 +0100 @@ -215,7 +215,9 @@ asmlinkage int sys_vm86old(struct pt_reg ret = -EFAULT; if (tmp) goto out; - memset(, 0, (int) - (int)); + memset(, 0, + offsetof(struct kernel_vm86_struct, regs32) - + offsetof(struct kernel_vm86_struct, vm86plus)); I do not think this makes it more readable... (int) -> (char *) would make it portable and readable, AFAICT. Pavel The right way to do it is: memset(, 0, sizeof info.vm86plus); -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] sg_ring: convert core ATA code to sg_ring.
On Wednesday 26 December 2007 19:36:36 Tejun Heo wrote: > It would be better to build upon sg chaining as we already have it. I > think it can be made much easier with a bit more safe guards, > generalization and some helpers. Hi Tejun, I did this work to replace sg chaining. The current chaining code gives us longer sgs, and (if used carefully) the ability to append in some circumstances. But it's clumsy, and we can do better. This is my attempt. I understand that people are experiencing whiplash from the idea of another change just after the sg chaining changes which have already gone in. At the very least, I think I'll have to come up with a better transition plan for SCSI drivers, rather than trying to convert them all at once... In theory, sg chaining can be done through the sg ring arrays, but that's pretty horrible. Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/16] adapt lguest launcher to per-cpuness
On Thursday 27 December 2007 01:24:10 Steven Rostedt wrote:
> On Wed, 26 Dec 2007, Rusty Russell wrote:
> > On Friday 21 December 2007 00:33:42 Glauber de Oliveira Costa wrote:
> > > + if (!vcpu_id) {
> > > + /*
> > > + * Service input, then unset the BREAK to
> > > + * release the Waker.
> > > + */
> > > + handle_input(lguest_fd);
> > > + if (pwrite(lguest_fd, args, sizeof(args), 0) < 0)
> > > + err(1, "Resetting break");
> > > + }
> >
> > I hate winged comments: those two extra lines, wasted!
>
> For multiple lines, wings are a Good Thing (TM). Otherwise it looks
> sloppy.
>
> /* Service input, then unset the BREAK to
>* release the Waker. */
>
> extra asterisk! ok then
No, that is correct. See all the rest of the lguest comments, or ask Dave
Miller :)
Of course, if you can keep a comment concisely in one line, it's even better.
But since colorizing editors are so common, the extra wings just steal
vertical space.
> Some one buy Rusty a bigger hard-drive to store those extra lines.
More importantly, a bigger screen to hold the code :)
Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Trying to convert old modules to newer kernels
Lennart Sorensen wrote: On Thu, Dec 20, 2007 at 04:27:37PM -0500, linux-os (Dick Johnson) wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Well I guess you can either fix the assembly once and for all to handle the current linux way of doing things, or you can patch to kernel back to the old ways of doing things when using your driver. I suppose you could just add some wrapper functions to your assembly that uses the new regparm calling method and then calls your methods the old way and selectively enable those when regparm is used by the kernel if you want to support all kernel versions. Or you could use inline assembly in C functions to handle the calling convention for you. If I were to guess, based on nothing but what's in this thread, people who write modules in assembler would want to avoid the the wrapper overhead. Of course putting image processing in the kernel at all instead of user programs is not something I ever do... -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Trying to convert old modules to newer kernels
James Courtier-Dutton wrote: J.A. Magallón wrote: I need to get rid of -mregparm=3 on gcc's command line. It is completely incompatible with the standard calling conventions used in all our assembly-language files in our drivers. We make very high-speed number-crunching drivers that munge high-speed data into images. We need to do that in assembly as we have always done. Just for curiosity... yep, I understand now you have everything written in assembler, but why not consider start writing it in C and stop doing the compiler work (such as pipelining, out of order reordering, loop unrolling for specific processor, and so on...) That's what everyone taught me, nowadays you won't be better than the compiler in anything longer than three lines... Not true for image processing. compilers are not too good with optimizing mmx and sse algorithms. This is why user space libraries like ffmpeg still use assembly code. If half of what I read about the Intel compiler is true, that may no longer be true. That being said, I don't think sse and mmx are available in kernel space, so I would have suggested doing all the grunt work in userspace would be better for this persons application so that he could use sse and mmx etc. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1 - e1000 breakage
On Wed, 26 Dec 2007, Andrew Morton wrote: > > (under current -mm, the e1000 driver doesn't find my ethernet card & the > > tcl tests won't run without an external interface). > > You might need to enable CONFIG_E1000E. Indeed, it works for me. - 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: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 21:32:58 schrieb Pavel Machek: > On Wed 2007-12-26 21:23:37, Oliver Neukum wrote: > > Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: > > > Is there an easy way to tell if all the devices are runtime suspended? > > > > Do you really want to know whether they are suspended or whether they > > could be suspended? > > If they are suspended. > > My plan is: let the drivers autosuspend on their own. If I see all of > them are autosuspended, then it looks like great time to put whole > system into s2ram... Your calculation of cost/benefit will be wrong. A driver will have timeouts based on the cost of a suspend/resume cycle of that device only. You'd have to calculate of keeping the whole system awake against that. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
atimes not updated over NFS
After upgrading an NFS server from kernel 2.6.12 to 2.6.23, the atime of files is not updated any more when clients read them : client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz client$ md5sum /nfsmnt/zz d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz client$ date +%Y-%m-%d_%H:%M:%S 2007-12-21_15:00:28 client$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz Reading the file locally, i.e. on the NFS server, does update the atime : server$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz -rw-r--r-- 1 xxx xxx 0 2007-12-21_14:58:11 /nfsmnt/zz serveur$ md5sum /nfsmnt/zz d41d8cd98f00b204e9800998ecf8427e /nfsmnt/zz serveur$ date +%Y-%m-%d_%H:%M:%S 2007-12-21_15:04:00 serveur$ ll -u --time-style +%Y-%m-%d_%H:%M:%S /nfsmnt/zz -rw-r--r-- 1 xxx xxx 0 2007-12-21_15:03:57 /nfsmnt/zz /nfsmnt is mounted with options : - server : rw,noexec,nosuid,nodev,nodiratime - client : rw,user=root,nosuid,nodev,nodiratime,intr,rsize=8192,wsize=8192 Any ideas ? -- André Majorel http://www.teaser.fr/~amajorel/> Do not use this account for regular correspondence. See the URL above for contact information. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Correct use of __init and __devinit
On Mon, 24 Dec 2007 14:01:43 +0100 Sam Ravnborg <[EMAIL PROTECTED]> wrote: > So of the principle of least suprise it is best to use __devinit > for the probe function as most other drivers do. And if > the driver model happens to call your probe function after > init time then we will not oops. If you're dealing with platform_devices, you can use platform_driver_probe() and remove the probe() function from the platform_driver struct to ensure this never happens. This is only ok for non-hotpluggable devices, of course. Haavard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 ports could not bond to a aggregator in 802.3ad mode issue
>After the setting, I cat the proc entry and got the following information [...] >802.3ad info >LACP rate: slow >Active Aggregator Info: >Aggregator ID: 1 >Number of ports: 2 >Actor Key: 17 >Partner Key: 1 >Partner Mac Address: 00:00:00:00:00:00 [...] >The behavior changes from 'one aggregator with one port' to 'one aggregator >with 2 ports', the latter seems more accurate. Is there a bug in bonding >driver code v3.1.3 (June 13, 2007)? I do not believe so. IEEE 802.3 section 43.3.9 states, in part, "Links that are not successful candidates for aggregation (e.g., links that are attached to other devices that cannot perform aggregation or links that have been manually configured to be non-aggregatable) are enabled to operate as individual IEEE 802.3 links. For consistency of modeling, such a link is regarded as being attached to a compatible Aggregator that can only be associated with a single link. That is, from the perspective of Link Aggregation, non-aggregated links are not a special case; they compose an aggregation with a maximum membership of one link." I do not see that it is correct to attach the links to a common aggregator, as your output indicates that no partner association has been created (the Partner MAC is all zeroes) and the links are therefore apparently connected to a device that cannot perform aggregation. -J --- -Jay Vosburgh, IBM Linux Technology Center, [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.24-rc6-mm1 - git-lblnet.patch and networking horkage
On Thu, 27 Dec 2007 01:16:25 +1100 (EST) James Morris <[EMAIL PROTECTED]> wrote: > On Wed, 26 Dec 2007, James Morris wrote: > > > What does the following say ? > > > > # sestatus && rpm -q selinux-policy > > Don't worry about that -- I reproduced it with Paul Moore's git tree: > git://git.infradead.org/users/pcmoore/lblnet-2.6_testing > > (under current -mm, the e1000 driver doesn't find my ethernet card & the > tcl tests won't run without an external interface). You might need to enable CONFIG_E1000E. > The offending commit is when SELinux is converted to the new ifindex > interface: > > 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 is first bad commit > commit 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 > Author: Paul Moore <[EMAIL PROTECTED]> > Date: Fri Dec 21 11:44:26 2007 -0500 > > SELinux: Convert the netif code to use ifindex values > > [...] > > In some case (not yet fully identified -- also happens when avahi starts > up, although seemingly silently & without obvious issues), SELinux is > passed an ifindex of 1515870810, which corresponds to 0x5a5a5a5a, the slab > poison value, suggesting a race in the calling code where we're being > asked to check an skb which has been freed. > > The SELinux code is erroring out before performing an access check > (perhaps there should be WARN_ON, at least), so this will affect both > permissive and enforcing mode without generating any log messages. > > Andrew: I suggest dropping the patchset from -mm until Paul gets back from > vacation. OK, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] w1-gpio: Add GPIO w1 bus master driver
On Fri, 21 Dec 2007 09:34:01 +0200
Ville Syrjala <[EMAIL PROTECTED]> wrote:
> +static struct platform_device foo_w1_device = {
> + .name = "w1-gpio",
> + .id = -1,
Assigning -1 to a u32 member isn't a very nice example. What does it
mean anyway?
> +static int __init w1_gpio_probe(struct platform_device *pdev)
This must be __devinit, or if you want to save a bit of memory...
> + .probe = w1_gpio_probe,
...remove this line, and...
> +static int __init w1_gpio_init(void)
> +{
> + return platform_driver_register(_gpio_driver);
...call platform_driver_probe(_gpio_driver, w1_gpio_probe) here.
Haavard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Major regression on hackbench with SLUB (more numbers)
On Wed, Dec 26, 2007 at 01:31:35PM -0800, Christoph Lameter wrote: > On Mon, 24 Dec 2007, Theodore Tso wrote: > > > So two questions: why isn't -f the default? And is /sys/slab > > Because it gives misleading output. It displays the name of the first > of multiple slabs that share the same storage structures. Erm... Let me spell it out: current lifetime rules are completely broken. As it is, create/destroy/create cache sequence will do kobject_put() on kfree'd object. Even without people playing with holding sysfs files open or doing IO on those. a) you have kobject embedded into struct with the lifetime rules of its own. When its refcount hits zero you kfree() the sucker, even if you still have references to embedded kobject. b) your symlinks stick around. Even when cache is long gone you still have a sysfs symlink with its embedded kobject as a target. They are eventually removed when cache with the same name gets created. _Then_ you get the target kobject dropped - when the memory it used to be in had been freed for hell knows how long and reused by something that would not appreciate slub.c code suddenly deciding to decrement some word in that memory. c) you leak references to these kobject; kobject_del() only removes it from the tree undoing the effect of kobject_add() and you still need kobject_put() to deal with the last reference. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ide-cd: move the remaining cdrom.c ioctl handling code to ide-cd_ioctl.c
On Wed, Dec 26, 2007 at 09:50:14PM +0100, Borislav Petkov wrote:
Actually you should drop the previous one for it wasn't incomplete. Here's,
hopefully, a better one :).
--
From: Borislav Petkov <[EMAIL PROTECTED]>
There should be no functional changes from this.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c | 217 +---
drivers/ide/ide-cd.h |8 ++-
drivers/ide/ide-cd_ioctl.c | 210 ++
3 files changed, 218 insertions(+), 217 deletions(-)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 23d4987..07e850d 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1396,7 +1396,7 @@ void msf_from_bcd (struct atapi_msf *msf)
msf->frame = BCD2BIN(msf->frame);
}
-static int cdrom_check_status(ide_drive_t *drive, struct request_sense *sense)
+int cdrom_check_status(ide_drive_t *drive, struct request_sense *sense)
{
struct request req;
struct cdrom_info *info = drive->driver_data;
@@ -1417,85 +1417,6 @@ static int cdrom_check_status(ide_drive_t *drive, struct
request_sense *sense)
return ide_cd_queue_pc(drive, );
}
-/* Lock the door if LOCKFLAG is nonzero; unlock it otherwise. */
-int ide_cd_lockdoor(ide_drive_t *drive, int lockflag,
- struct request_sense *sense)
-{
- struct cdrom_info *cd = drive->driver_data;
- struct request_sense my_sense;
- struct request req;
- int stat;
-
- if (sense == NULL)
- sense = _sense;
-
- /* If the drive cannot lock the door, just pretend. */
- if (cd->cd_flags & IDE_CD_FLAG_NO_DOORLOCK) {
- stat = 0;
- } else {
- ide_cd_init_rq(drive, );
- req.sense = sense;
- req.cmd[0] = GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL;
- req.cmd[4] = lockflag ? 1 : 0;
- stat = ide_cd_queue_pc(drive, );
- }
-
- /* If we got an illegal field error, the drive
- probably cannot lock the door. */
- if (stat != 0 &&
- sense->sense_key == ILLEGAL_REQUEST &&
- (sense->asc == 0x24 || sense->asc == 0x20)) {
- printk (KERN_ERR "%s: door locking not supported\n",
- drive->name);
- cd->cd_flags |= IDE_CD_FLAG_NO_DOORLOCK;
- stat = 0;
- }
-
- /* no medium, that's alright. */
- if (stat != 0 && sense->sense_key == NOT_READY && sense->asc == 0x3a)
- stat = 0;
-
- if (stat == 0) {
- if (lockflag)
- cd->cd_flags |= IDE_CD_FLAG_DOOR_LOCKED;
- else
- cd->cd_flags &= ~IDE_CD_FLAG_DOOR_LOCKED;
- }
-
- return stat;
-}
-
-
-/* Eject the disk if EJECTFLAG is 0.
- If EJECTFLAG is 1, try to reload the disk. */
-static int cdrom_eject(ide_drive_t *drive, int ejectflag,
- struct request_sense *sense)
-{
- struct cdrom_info *cd = drive->driver_data;
- struct cdrom_device_info *cdi = >devinfo;
- struct request req;
- char loej = 0x02;
-
- if ((cd->cd_flags & IDE_CD_FLAG_NO_EJECT) && !ejectflag)
- return -EDRIVE_CANT_DO_THIS;
-
- /* reload fails on some drives, if the tray is locked */
- if ((cd->cd_flags & IDE_CD_FLAG_DOOR_LOCKED) && ejectflag)
- return 0;
-
- ide_cd_init_rq(drive, );
-
- /* only tell drive to close tray if open, if it can do that */
- if (ejectflag && (cdi->mask & CDC_CLOSE_TRAY))
- loej = 0;
-
- req.sense = sense;
- req.cmd[0] = GPCMD_START_STOP_UNIT;
- req.cmd[4] = loej | (ejectflag != 0);
-
- return ide_cd_queue_pc(drive, );
-}
-
static int cdrom_read_capacity(ide_drive_t *drive, unsigned long *capacity,
unsigned long *sectors_per_frame,
struct request_sense *sense)
@@ -1711,53 +1632,6 @@ int ide_cd_read_toc(ide_drive_t *drive, struct
request_sense *sense)
return 0;
}
-/* the generic packet interface to cdrom.c */
-static int ide_cdrom_packet(struct cdrom_device_info *cdi,
- struct packet_command *cgc)
-{
- struct request req;
- ide_drive_t *drive = cdi->handle;
-
- if (cgc->timeout <= 0)
- cgc->timeout = ATAPI_WAIT_PC;
-
- /* here we queue the commands from the uniform CD-ROM
- layer. the packet must be complete, as we do not
- touch it at all. */
- ide_cd_init_rq(drive, );
- memcpy(req.cmd, cgc->cmd, CDROM_PACKET_SIZE);
- if (cgc->sense)
- memset(cgc->sense, 0, sizeof(struct request_sense));
- req.data = cgc->buffer;
- req.data_len = cgc->buflen;
- req.timeout = cgc->timeout;
-
- if (cgc->quiet)
- req.cmd_flags |= REQ_QUIET;
-
- req.sense = cgc->sense;
-
Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage
On Thu, 26 Dec 2007, Paul Moore wrote: > As James said I'm away right now and computer access is limited. > However, I'm stuck in the airport right now and spent some time looking > at the code ... Based on what has been found so far I wonder if the > problem isn't a race but a problem of skb->iif never being initialized > correctly? To my untrained eye it looks like __netdev_alloc_skb() > should be setting skb->iif (like it does for skb->dev) but it currently > doesn't. ->iif will be zeroed during skb allocation, then set during netif_receive_skb(). - 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: Major regression on hackbench with SLUB (more numbers)
On Mon, 24 Dec 2007, Theodore Tso wrote: > So two questions: why isn't -f the default? And is /sys/slab Because it gives misleading output. It displays the name of the first of multiple slabs that share the same storage structures. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] slub: /proc/slabinfo ABI compatibility
On Mon, 24 Dec 2007, Pekka Enberg wrote: > On Dec 24, 2007 9:12 PM, Christoph Lameter <[EMAIL PROTECTED]> wrote: > > Hmmm... What is the combination of config variables that causes this? I > > moved the count_partial function in mm in order to make the merge of slab > > defrag easier. > > I think it's CONFIG_PROC_FS without CONFIG_SYSFS. The only user of count_partial is in slab_objects() which is in a section that is #if defined(CONFIG_SYSFS) && defined(CONFIG_SLUB_DEBUG) There should be no use if CONFIG_SYSFS is not set. I think we get a warning about a function that is never called when compiling the current mm code without SLUB_DEBUG or CONFIG_SYSFS (because the slab defrag use has not been merged yet). In mm count_partial() is always defined. In Linus tree count_partial() comes just before slab_objects(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Suspend-devel] Fwd: Kernel Oops with 2.6.23
On Mon 2007-12-17 21:45:54, Ritesh Raj Sarraf wrote: > On Tuesday 04 December 2007, Pavel Machek wrote: > > On Mon 2007-12-03 06:01:26, Ritesh Raj Sarraf wrote: > > > On Sunday 02 December 2007, Pavel Machek wrote: > > > > killall -9 pulseaudio. If pulseaudio is not dead within 60 seconds, > > > > you hit a kernel bug. If it needs suspend to be reproduced, you > > > > probably have a suspend bug. > > > > > > Hi Pavel, > > > > > > Something similar to this are multiple cases where the kernel is not able > > > to kill a process at all. > > > > > > A good example is an application pumping IO to a multipathed device. When > > > all the paths to the multipathed devices go down, and you'd like to kill > > > the process, there is no way left to do it. In fact, a reboot also > > > doesn't work in such cases. Reboot gets hung in midway trying to kill the > > > process. The user is left to do a hard reset of the machine. > > > > > > In situations like these, the processes go into D state. > > > > > > Here's what the manpage of ps says: > > > > > > PROCESS STATE CODES > > >Here are the different values that the s, stat and state output > > > specifiers (header "STAT" or "S") > > >will display to describe the state of a process. > > >DUninterruptible sleep (usually IO) > > > > > > Does it mean that processes in D state are excluded by the kernel from > > > being killed ? Or is it still a kernel bug ? > > > > Still a kernel bug. Processes should not stay in D state for long. > > Pavel > > Hi Pavel, > > Sometime back we discussed about 'D' state processes which are not killed by > the kernel by any signal. > > Here's a bugzilla detailing the symptom. > https://bugzilla.redhat.com/show_bug.cgi?id=419581 > [I/O Processes don't get killed when all the paths to the LUN are down] > > It is still being assumed as working as designed. This is borderline. I guess multipath should use new TASK_KILLABLE infrastructure, but I do not expect RedHat to backport that. Feel free to implement that yourself, it should be quite easy. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-stable causes oomkiller to be invoked
On Fri, 21 Dec 2007, Dhaval Giani wrote: > No, it does not stop the oom I am seeing here. Duh. Disregard that patch. It looks like check_pgt_cache() is not called. This could happen if tlb_flush_mmu is never called during the fork/terminate sequences in your script. pgd_free is called *after* a possible tlb flush so the pgd page is on the quicklist (which is good for the next process which needs a pgd). The tlb_flush_mmu's during pte eviction should trim the quicklist. For some reason this is not happening on your box (it works here). Could you try this script that insures that check_pgt_cache is called after every pgd_free? Index: linux-2.6/arch/x86/mm/pgtable_32.c === --- linux-2.6.orig/arch/x86/mm/pgtable_32.c 2007-12-26 12:55:10.0 -0800 +++ linux-2.6/arch/x86/mm/pgtable_32.c 2007-12-26 12:55:54.0 -0800 @@ -366,6 +366,15 @@ void pgd_free(pgd_t *pgd) } /* in the non-PAE case, free_pgtables() clears user pgd entries */ quicklist_free(0, pgd_dtor, pgd); + + /* +* We must call check_pgd_cache() here because the pgd is freed after +* tlb flushing and the call to check_pgd_cache. In some cases the VM +* may not call tlb_flush_mmu during process termination (??). +* If this is repeated then we may never call check_pgd_cache. +* The quicklist will grow and grow. So call check_pgd_cache here. +*/ + check_pgt_cache(); } void check_pgt_cache(void) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Regarding request for IBM camera patch to be applied to the main tree
On Fri, 21 Dec 2007 14:32:09 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 21, 2007 at 03:21:30PM -0600, David Hilvert wrote:
> > > > http://www.linux-usb.org/ibmcam/
> >
> > > > http://auricle.dyndns.org/xvp610/
> >
> > [Remainder of private e-mail context snipped; message has been blind-CC'ed
> > to
> > the original recipients. Please CC any replies intended for me.]
> >
> > As the author of the second patch noted, I had avoided sending it to lkml
> > due
> > to the difficulty of determining whether the patch is correct (e.g., having
> > no
> > ill effect on other cameras), due, in turn, to lack of documentation for
> > this
> > series of cameras. Perhaps dmitri could comment further on this, if he has
> > time and access to test on any other cameras that might fall under the
> > 'model
> > 3' designation (whatever this designation might mean). The (rather old,
> > now)
> > patch in question (against 2.6.1 or so, and perhaps other versions)
> > follows; if
> > I recall correctly, it was designed to minimize change lines rather than
> > provide for overall clarity, so that a clearer final implementation is
> > probably
> > possible.
> >
> >
> > diff -urN linux-2.6.1/drivers/usb/media/ibmcam.c
> > linux-2.6.1-patched/drivers/usb/media/ibmcam.c
> > --- linux-2.6.1/drivers/usb/media/ibmcam.c Fri Jan 9 00:59:19 2004
> > +++ linux-2.6.1-patched/drivers/usb/media/ibmcam.c Fri Feb 6 14:54:33 2004
>
> I suggest forward porting it to the latest tree and submit it to the usb
> video maintainers for inclusion.
>
> thanks,
>
> greg k-h
Port to 2.6.23.12 follows:
--- linux-2.6.23.12/drivers/media/video/usbvideo/ibmcam.c 2007-12-18
21:55:57.0 +
+++ linux-2.6.23.12-patched/drivers/media/video/usbvideo/ibmcam.c
2007-12-26 20:34:45.0 +
@@ -802,6 +802,21 @@
return scan_Continue;
}
+/*
+ * ibmcam_model3_parse_lines()
+ *
+ * | Even lines | Odd Lines |
+ * ---|
+ * |YYYY|UYVYUYVY.UYVY|
+ * |YYYY|UYVYUYVY.UYVY|
+ * ||.|
+ * |YYYY|UYVYUYVY.UYVY|
+ * |+-|
+ *
+ * There is one (U, V) chroma pair for every four luma (Y) values. This
+ * function reads a pair of lines at a time and obtains missing chroma values
+ * from adjacent pixels.
+ */
static enum ParseState ibmcam_model3_parse_lines(
struct uvd *uvd,
struct usbvideo_frame *frame,
@@ -816,6 +831,7 @@
const int ccm = 128; /* Color correction median - see below */
int i, u, v, rw, data_w=0, data_h=0, color_corr;
static unsigned char lineBuffer[640*3];
+ int line;
color_corr = (uvd->vpic.colour - 0x8000) >> 8; /* -128..+127 =
-ccm..+(ccm-1)*/
RESTRICT_TO_RANGE(color_corr, -ccm, ccm+1);
@@ -869,15 +885,15 @@
return scan_NextFrame;
}
- /* Make sure there's enough data for the entire line */
- len = 3 * data_w; /* */
+ /* Make sure that lineBuffer can store two lines of data */
+ len = 3 * data_w; /* */
assert(len <= sizeof(lineBuffer));
- /* Make sure there's enough data for the entire line */
+ /* Make sure there's enough data for two lines */
if (RingQueue_GetLength(>dp) < len)
return scan_Out;
- /* Suck one line out of the ring queue */
+ /* Suck two lines of data out of the ring queue */
RingQueue_Dequeue(>dp, lineBuffer, len);
data = lineBuffer;
@@ -887,15 +903,23 @@
rw = (int)VIDEOSIZE_Y(frame->request) - (int)(frame->curline) - 1;
RESTRICT_TO_RANGE(rw, 0, VIDEOSIZE_Y(frame->request)-1);
- for (i = 0; i < VIDEOSIZE_X(frame->request); i++) {
- int y, rv, gv, bv; /* RGB components */
+ /* Iterate over two lines. */
+ for (line = 0; line < 2; line++) {
+ for (i = 0; i < VIDEOSIZE_X(frame->request); i++) {
+ int y;
+ int rv, gv, bv; /* RGB components */
+
+ if (i >= data_w) {
+ RGB24_PUTPIXEL(frame, i, rw, 0, 0, 0);
+ continue;
+ }
- if (i < data_w) {
- y = data[i];/* Luminosity is the first line */
+ /* first line is YYY...Y; second is UYVY...UYVY */
+ y = data[(line == 0) ? i : (i*2 + 1)];
/* Apply static color correction */
- u = color[i*2] + hue_corr;
- v = color[i*2 + 1] + hue2_corr;
+ u = color[(i/2)*4] + hue_corr;
+ v = color[(i/2)*4 + 2] + hue2_corr;
/* Apply color correction */
if (color_corr != 0) {
@@ -903,13 +927,21 @@
u = 128 + ((ccm
Re: [RFC] sleepy linux
Pavel Machek wrote: On Wed 2007-12-26 12:43:56, H. Peter Anvin wrote: Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 3) Network card that is either down or can wake up system on any packet (and not loose too many packets) This is the big crux I see. You're going to constantly wake up the machine due to broadcast packets, and spend a lot of power just going in and out of S3. How many machines care a lot about saving power while they are connected to an ethernet? Wlan might be more of a problem. A lot of them should. An inordinate amount of machines sit there burning power for no reason. You can argue that S3 isn't needed -- that nohz + C3/C4 + turning off the screen would be enough, and that might be + legit. NOHZ + C4 + turn off screen + turn off disk + turn off SATA is still ~8W on thinkpad x60. S3 is ~1W. That's quite significant difference. (But yes, connected-to-ethernet is not most important use scenario.) Pavel Still... if we could get the desktops of the world down anywhere close to that range when not used, it would be a huge win. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ide-cd: move the remaining cdrom.c ioctl handling code to ide-cd_ioctl.c
Hi Bart,
the following moves the remaining cdrom.c ioctl-related pieces to their proper
location. It applies on top of your 63 redux patches and shouldn't be changing
anything in the current functionality of the driver.
--
From: Borislav Petkov <[EMAIL PROTECTED]>
There should be no functional changes caused by this patch.
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c | 186 +---
drivers/ide/ide-cd.h |7 ++-
drivers/ide/ide-cd_ioctl.c | 179 ++
3 files changed, 186 insertions(+), 186 deletions(-)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 23d4987..b19e713 100644
--- a/drivers/ide/ide-cd.c
+++ b/drivers/ide/ide-cd.c
@@ -1396,7 +1396,7 @@ void msf_from_bcd (struct atapi_msf *msf)
msf->frame = BCD2BIN(msf->frame);
}
-static int cdrom_check_status(ide_drive_t *drive, struct request_sense *sense)
+int cdrom_check_status(ide_drive_t *drive, struct request_sense *sense)
{
struct request req;
struct cdrom_info *info = drive->driver_data;
@@ -1417,85 +1417,6 @@ static int cdrom_check_status(ide_drive_t *drive, struct
request_sense *sense)
return ide_cd_queue_pc(drive, );
}
-/* Lock the door if LOCKFLAG is nonzero; unlock it otherwise. */
-int ide_cd_lockdoor(ide_drive_t *drive, int lockflag,
- struct request_sense *sense)
-{
- struct cdrom_info *cd = drive->driver_data;
- struct request_sense my_sense;
- struct request req;
- int stat;
-
- if (sense == NULL)
- sense = _sense;
-
- /* If the drive cannot lock the door, just pretend. */
- if (cd->cd_flags & IDE_CD_FLAG_NO_DOORLOCK) {
- stat = 0;
- } else {
- ide_cd_init_rq(drive, );
- req.sense = sense;
- req.cmd[0] = GPCMD_PREVENT_ALLOW_MEDIUM_REMOVAL;
- req.cmd[4] = lockflag ? 1 : 0;
- stat = ide_cd_queue_pc(drive, );
- }
-
- /* If we got an illegal field error, the drive
- probably cannot lock the door. */
- if (stat != 0 &&
- sense->sense_key == ILLEGAL_REQUEST &&
- (sense->asc == 0x24 || sense->asc == 0x20)) {
- printk (KERN_ERR "%s: door locking not supported\n",
- drive->name);
- cd->cd_flags |= IDE_CD_FLAG_NO_DOORLOCK;
- stat = 0;
- }
-
- /* no medium, that's alright. */
- if (stat != 0 && sense->sense_key == NOT_READY && sense->asc == 0x3a)
- stat = 0;
-
- if (stat == 0) {
- if (lockflag)
- cd->cd_flags |= IDE_CD_FLAG_DOOR_LOCKED;
- else
- cd->cd_flags &= ~IDE_CD_FLAG_DOOR_LOCKED;
- }
-
- return stat;
-}
-
-
-/* Eject the disk if EJECTFLAG is 0.
- If EJECTFLAG is 1, try to reload the disk. */
-static int cdrom_eject(ide_drive_t *drive, int ejectflag,
- struct request_sense *sense)
-{
- struct cdrom_info *cd = drive->driver_data;
- struct cdrom_device_info *cdi = >devinfo;
- struct request req;
- char loej = 0x02;
-
- if ((cd->cd_flags & IDE_CD_FLAG_NO_EJECT) && !ejectflag)
- return -EDRIVE_CANT_DO_THIS;
-
- /* reload fails on some drives, if the tray is locked */
- if ((cd->cd_flags & IDE_CD_FLAG_DOOR_LOCKED) && ejectflag)
- return 0;
-
- ide_cd_init_rq(drive, );
-
- /* only tell drive to close tray if open, if it can do that */
- if (ejectflag && (cdi->mask & CDC_CLOSE_TRAY))
- loej = 0;
-
- req.sense = sense;
- req.cmd[0] = GPCMD_START_STOP_UNIT;
- req.cmd[4] = loej | (ejectflag != 0);
-
- return ide_cd_queue_pc(drive, );
-}
-
static int cdrom_read_capacity(ide_drive_t *drive, unsigned long *capacity,
unsigned long *sectors_per_frame,
struct request_sense *sense)
@@ -1742,22 +1663,6 @@ static int ide_cdrom_packet(struct cdrom_device_info
*cdi,
return cgc->stat;
}
-static
-int ide_cdrom_tray_move (struct cdrom_device_info *cdi, int position)
-{
- ide_drive_t *drive = cdi->handle;
- struct request_sense sense;
-
- if (position) {
- int stat = ide_cd_lockdoor(drive, 0, );
-
- if (stat)
- return stat;
- }
-
- return cdrom_eject(drive, !position, );
-}
-
int ide_cdrom_get_capabilities(ide_drive_t *drive, u8 *buf)
{
struct cdrom_info *info = drive->driver_data;
@@ -1797,95 +1702,6 @@ void ide_cdrom_update_speed(ide_drive_t *drive, u8 *buf)
cd->max_speed = (maxspeed + (176/2)) / 176;
}
-/*
- * add logic to try GET_EVENT command first to check for media and tray
- * status. this should be supported by newer cd-r/w and all DVD etc
- * drives
- */
-static
-int
Re: [RFC] sleepy linux
On Wed 2007-12-26 12:43:56, H. Peter Anvin wrote: > Oliver Neukum wrote: >> Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 3) Network card that is either down or can wake up system on any packet (and not loose too many packets) >>> This is the big crux I see. You're going to constantly wake up the >>> machine due to broadcast packets, and spend a lot of power just going in >>> and out of S3. >> How many machines care a lot about saving power while they are connected >> to an ethernet? Wlan might be more of a problem. > > A lot of them should. An inordinate amount of machines sit there burning > power for no reason. You can argue that S3 isn't needed -- that nohz + > C3/C4 + turning off the screen would be enough, and that might be > + legit. NOHZ + C4 + turn off screen + turn off disk + turn off SATA is still ~8W on thinkpad x60. S3 is ~1W. That's quite significant difference. (But yes, connected-to-ethernet is not most important use scenario.) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80 on some AMD64x2 laptops, etc.
On Sun 2007-12-16 15:34:58, H. Peter Anvin wrote: > Pavel Machek wrote: >> Hi! >>> The process of safely making delicate changes here is beyond my >>> responsibility as just a user - believe me, I'm not suggesting that a >>> risky fix be put in .24. I can patch my own kernels, and I can even >>> share an unofficial patch with others for now, or suggest that Fedora and >>> Ubuntu add it to their downstream. >>> >>> May I make a small suggestion, though. If the decision is a DMI-keyed >>> switch from out-80 to udelay(2) gets put in, perhaps there should also >>> be a way for people to test their own configuration for the underlying >>> problem made available as a script. Though it is a "hack", all you need >>> to freeze a problem system is to run a loop doing about 1000 "cat >>> /dev/nvram > /dev/null" commands. If that leads to a freeze, one might >>> ask to have the motherboard added to the DMI-key list. >> Can you freeze it by catting /dev/rtc, too? That may be significant, >> because that is readable for group audio (at least on some >> systems)... which would smell like "small security hole" to me. > > Heck, on my system (Fedora 7), it's mode 644... Ok, time to CC security team, I'd say. Problem is, that some AMD64x2 nVidia laptops crash on port 0x80 access... which is easily user-triggerable by using /dev/rtc. If it is 644 on Fedora, I guess we have a problem. Otoh, it is "only" a denial of service, and it can probably be attributed to "buggy hardware". Is that still relevant for security team? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/55] KVM patch queue review for 2.6.25 merge window (part II)
On Wed, Dec 26, 2007 at 01:05:05PM +0200, Avi Kivity wrote: > The second 2.6.25 kvm patch series, for your review. Three more to go. Hi Avi. A diffstat in your introduction mail would be nice so one does not have to check 50+ patches to see if it touches any file I can give feedback on. Sam -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fs/autofs: Use time_before, time_before_eq, etc.
Ray Lee wrote: On Dec 26, 2007 7:21 AM, Julia Lawall <[EMAIL PROTECTED]> wrote: - if (jiffies - ent->last_usage < timeout) + if (time_before(jiffies, ent->last_usage + timeout)) I don't think this is a safe change? subtraction is always safe (if you think about it as 'distance'), addition isn't always safe unless you know the range. The time_before macro will expand that out to (effectively): if ( (long)(ent->last_usage + timeout) - (long)(jiffies) < 0 ) which seems to introduce an overflow condition in the first term. Dunno, I may be wrong (happens often), but at the very least what you've transformed it into is no longer obviously correct, and so it's not a great change. Indeed. The bottom form will have overflow issues at time jiffies_wraparound/2, whereas the top form will have overflow issues only near jiffies_wraparound/1. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Oliver Neukum wrote: Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: 3) Network card that is either down or can wake up system on any packet (and not loose too many packets) This is the big crux I see. You're going to constantly wake up the machine due to broadcast packets, and spend a lot of power just going in and out of S3. How many machines care a lot about saving power while they are connected to an ethernet? Wlan might be more of a problem. A lot of them should. An inordinate amount of machines sit there burning power for no reason. You can argue that S3 isn't needed -- that nohz + C3/C4 + turning off the screen would be enough, and that might be legit. Heck, I'm constantly frustrated by every distro upgrade breaking power management for my monitor. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: tlb_finish_mmu() bogisity
Argh. This is indeed bogus. The one reporting the problem states that the
patch did not address the issue. The report was regarding pgd freeing
which is handled slightly differently from pte frees.
[PATCH] Revert quicklist need->flush fix
Did not fix the reported issue. Apart from other weirdness this causes a
bad link between the TLB flushing logic and the quicklists. If there is
indeed an issue that an arch needs a tlb flush before free then the arch
code needs to set tlb->need_flush before calling quicklist_free.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
Index: linux-2.6/include/asm-generic/tlb.h
===
--- linux-2.6.orig/include/asm-generic/tlb.h2007-12-26 12:26:32.0
-0800
+++ linux-2.6/include/asm-generic/tlb.h 2007-12-26 12:26:39.0 -0800
@@ -86,9 +86,6 @@ tlb_flush_mmu(struct mmu_gather *tlb, un
static inline void
tlb_finish_mmu(struct mmu_gather *tlb, unsigned long start, unsigned long end)
{
-#ifdef CONFIG_QUICKLIST
- tlb->need_flush += &__get_cpu_var(quicklist)[0].nr_pages != 0;
-#endif
tlb_flush_mmu(tlb, start, end);
/* keep the page table cache within bounds */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Testing RAM from userspace / question about memmap= arguments
В сообщении от Wednesday 26 December 2007 12:17:56 Arjan van de Ven написал(а): > On Wed, 26 Dec 2007 00:09:57 +0100 > Pavel Machek <[EMAIL PROTECTED]> wrote: > > > On Sat 2007-12-22 12:09:59, Arjan van de Ven wrote: > > > On Tue, 18 Dec 2007 17:06:24 + > > > > memtest86+ does various magic to basically bypass the caches (by > > > disabling them ;-)... Doing that in a live kernel situation, and > > > from userspace to boot.. that's... and issue. > > > > Are you sure? I always assumed that memtest just used patterns bigger > > than L1/L2 caches... > > that's... not nearly usable or enough. Caches are relatively smart > about things like use-once and they're huge. 12Mb today. You'd need > patterns bigger than 100Mb to get even close to being reasonably > confident that there's nothing left. > > > ... and IIRC my celeron testing confirmed it, if > > I disabled L2 cache in BIOS, memtest behave differently. > > > > Anyway, if you can do iopl(), we may as well let you disable caches, > > but you are right, that will need a kernel patch. > > and a new syscall of some sorts I suspect; "flush all caches" is a ring > 0 operation (and you probably need to do it in an ipi anyway on all > cpus) > I think that PAT support will help a lot. How about opening/mmaping /dev/mem, and setting uncacheable attribute there. Actually it is even possible today with MTRRs. Regards, Maxim Levitsky -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] aoe: document the behavior of /dev/etherd/err
Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>
---
drivers/block/aoe/aoechr.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/block/aoe/aoechr.c b/drivers/block/aoe/aoechr.c
index 2620073..871f284 100644
--- a/drivers/block/aoe/aoechr.c
+++ b/drivers/block/aoe/aoechr.c
@@ -33,6 +33,10 @@ struct ErrMsg {
char *msg;
};
+/* A ring buffer of error messages, to be read through
+ * "/dev/etherd/err". When no messages are present,
+ * readers will block waiting for messages to appear.
+ */
static struct ErrMsg emsgs[NMSG];
static int emsgs_head_idx, emsgs_tail_idx;
static struct semaphore emsgs_sema;
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 21:23:37, Oliver Neukum wrote: > Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: > > On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: > > > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > > > > Heute 00:07:31 > > > > > > > > This is RFC. It does not even work for me... it sleeps but it will not > > > > wake up, because SATA wakeup code is missing. Code attached for > > > > illustration. > > > > > > > > I wonder if this is the right approach? What is right interface to the > > > > drivers? > > > > > > IMHO you are making to many special cases. The system can be "sleepy" > > > if all devices can be runtime suspended and all CPUs are idle. > > > > Is there an easy way to tell if all the devices are runtime suspended? > > Do you really want to know whether they are suspended or whether they > could be suspended? If they are suspended. My plan is: let the drivers autosuspend on their own. If I see all of them are autosuspended, then it looks like great time to put whole system into s2ram... > > I guess I need to know from atomic context :-(. > > Urgh. suspend() must be able to sleep and can fail. That's ok. ... I also don't need to call any suspend() routines, because all the drivers are already suspended, right? And yes, I want device activity to prevent s2ram. If user is burning CD, machine should not sleep. If user is actively typing, machine should not sleep. My vision is: screen saver tells kernel keyboard need not be very responsive, at that point keyboard driver can autosuspend the keyboard, and if that was the last device, whole system sleeps. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] aoe: initialize locking structures before registering char devices
This patch was made against 2.6.24-rc6-mm1.
In March 2007, Alexey Dobriyan suggested this change, which
eliminates a race after register_chardev has been called but
the locking primitives protecting the error messages ring
buffer have not yet been initialized.
The initialization could happen at compile time, but that
would leave aoe as the only user of __DECLARE_SEMAPHORE_GENERIC.
Signed-off-by: Ed L. Cashin <[EMAIL PROTECTED]>
---
drivers/block/aoe/aoechr.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/block/aoe/aoechr.c b/drivers/block/aoe/aoechr.c
index e8e60e7..2620073 100644
--- a/drivers/block/aoe/aoechr.c
+++ b/drivers/block/aoe/aoechr.c
@@ -259,13 +259,13 @@ aoechr_init(void)
{
int n, i;
+ sema_init(_sema, 0);
+ spin_lock_init(_lock);
n = register_chrdev(AOE_MAJOR, "aoechr", _fops);
if (n < 0) {
printk(KERN_ERR "aoe: can't register char device\n");
return n;
}
- sema_init(_sema, 0);
- spin_lock_init(_lock);
aoe_class = class_create(THIS_MODULE, "aoe");
if (IS_ERR(aoe_class)) {
unregister_chrdev(AOE_MAJOR, "aoechr");
--
1.5.3.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-pm] [RFC] sleepy linux
Hi, On Wed, 2007-12-26 at 00:07 +0100, ext Pavel Machek wrote: > This is RFC. It does not even work for me... it sleeps but it will not > wake up, because SATA wakeup code is missing. Code attached for illustration. > > I wonder if this is the right approach? What is right interface to the > drivers? > > > Sleepy Linux > > > Copyright 2007 Pavel Machek <[EMAIL PROTECTED]> > GPLv2 > > Current Linux versions can enter suspend-to-RAM just fine, but only > can do it on explicit request. But suspend-to-RAM is important, eating > something like 10% of power needed for idle system. Starting suspend > manually is not too convinient; it is not an option on multiuser > machine, and even on single user machine, some things are not easy: > > 1) Download this big chunk in mozilla, then go to sleep > > 2) Compile this, then go to sleep Why can't these cases be based on CPUIdle? > 3) You can sleep now, but wake me up in 8:30 with mp3 player This is about setting up properly the wakeup sources which means: - the wakeup source is really capable of generating wakeups for the target idle state - the wakeup source is not actually capable of genrating wakeups from the target idle state, which can be solved in 2 ways: - if the duration of the activity is known, set up an alarm (assuming alarms are proper wakeup sources) so that the system is ready just in time, in a less efficient but more responsive power saving state - if the duration of the activity is unknown choose the more efficient amongst the following solutions: - go to deep sleep state and periodically wakeup and poll, with a period compatible with the timing of the event source - prevent too deep sleep states till the event happens > Todays hardware is mostly capable of doing better: with correctly set > up wakeups, machine can sleep and successfully pretend it is not > sleeping -- by waking up whenever something interesting happens. Of > course, it is easier on machines not connected to the network, and on > notebook computers. It might be that some hw doesn't provide deep power saving state for some devices, but if the only missing feature is the wakeup capability, it could be effectively replaced by some HW timer. > Requirements: > > 0) Working suspend-to-RAM, with kernel being able to bring video back. > > 1) RTC clock that can wake up system > > 2) Lid that can wake up a system, >or keyboard that can wake up system and does not loose keypress >or special screensaver setup > > 3) Network card that is either down >or can wake up system on any packet (and not loose too many packets) These are just few system specific case, but if you start including USB devices, the situation is going to get quite complicated very soon, if you explicitly include certain HW devices in your model. -- Cheers, Igor Igor Stoppa <[EMAIL PROTECTED]> (Nokia Multimedia - CP - OSSO / Helsinki, Finland) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 21:17:22 schrieb Pavel Machek: > On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: > > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > > > Heute 00:07:31 > > > > > > This is RFC. It does not even work for me... it sleeps but it will not > > > wake up, because SATA wakeup code is missing. Code attached for > > > illustration. > > > > > > I wonder if this is the right approach? What is right interface to the > > > drivers? > > > > IMHO you are making to many special cases. The system can be "sleepy" > > if all devices can be runtime suspended and all CPUs are idle. > > Is there an easy way to tell if all the devices are runtime suspended? Do you really want to know whether they are suspended or whether they could be suspended? > I guess I need to know from atomic context :-(. Urgh. suspend() must be able to sleep and can fail. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > > Heute 00:07:31 > > > > This is RFC. It does not even work for me... it sleeps but it will not > > wake up, because SATA wakeup code is missing. Code attached for > > illustration. > > > > I wonder if this is the right approach? What is right interface to the > > drivers? > > IMHO you are making to many special cases. The system can be "sleepy" > if all devices can be runtime suspended and all CPUs are idle. Is there an easy way to tell if all the devices are runtime suspended? I guess I need to know from atomic context :-(. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 19:56:59 schrieb H. Peter Anvin: > > 3) Network card that is either down > > or can wake up system on any packet (and not loose too many packets) > > > > This is the big crux I see. You're going to constantly wake up the > machine due to broadcast packets, and spend a lot of power just going in > and out of S3. How many machines care a lot about saving power while they are connected to an ethernet? Wlan might be more of a problem. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fs/autofs: Use time_before, time_before_eq, etc.
On Dec 26, 2007 7:21 AM, Julia Lawall <[EMAIL PROTECTED]> wrote: > - if (jiffies - ent->last_usage < timeout) > + if (time_before(jiffies, ent->last_usage + timeout)) I don't think this is a safe change? subtraction is always safe (if you think about it as 'distance'), addition isn't always safe unless you know the range. The time_before macro will expand that out to (effectively): if ( (long)(ent->last_usage + timeout) - (long)(jiffies) < 0 ) which seems to introduce an overflow condition in the first term. Dunno, I may be wrong (happens often), but at the very least what you've transformed it into is no longer obviously correct, and so it's not a great change. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [PATCHv2] powerpc: DBox2 Board Support
On Wednesday 26 December 2007, Jochen Friedrich wrote:
> >> + memory {
> >> + device_type = "memory";
> >> + reg = <0 200>;
> >> + };
> >
> > I thought there are both models with 32MB and 16MB available.
> > If that's true, shouldn't this be filled out by the boot loader?
>
> IIRC, the cuImage wrapper overwrites this with the boot loader
> parameters.
Then maybe set it to zero size in the dts file, and add a comment.
> OTOH, the memory is part of the localbus (CS1). Should it be a child
> of localbus in this case?
No, memory nodes are required to be at the root of the device tree
for historic reasons.
> I didn't check FB_OF. On Dbox2, the avia driver creates a
> framebuffer device.
fb_of needs some properties in the device tree set up correctly,
but is very simple otherwise. If it does all you need, it's
probably a good idea to use that and get rid of the avia framebuffer
driver
> There are two mods available using the block layer, although currently i don't
> support any of them:
>
> 1. using the GPIO lines of the modem port, it's possible to connect a SD card.
>It might be possible to use it using the GPIO SPI driver (but it would need
>some glue code to create a platform device).
>
> 2. using the memory expansion port and CS2, there is an IDE interface
> available
>with a CPLD acting as localbus/IDE bridge. There is a device driver for
>ARCH=ppc.
>
> Unfortunately, i don't own any of these modifications.
If neither of these is in the mainline kernel, it doesn't make sense to
have support for the block layer in defconfig, so just try how much
memory you can free up with this.
> >> +static void __init dbox2_setup_arch(void)
> >> +{
> >> + struct device_node *np;
> >> + static u8 __iomem *config;
> >> +
> >> + cpm_reset();
> >> + init_ioports();
> >> +
> >> + /* Enable external IRQs for AVIA chips */
> >> + clrbits32(_immr->im_siu_conf.sc_siumcr, 0x0c00);
> >
> > This smells like a hack. What are AVIA chips, and shouldn't
> > their driver enable the IRQs?
>
> No. This just configures the Pin as IRQ input. Maybe, the new GPIO
> functions could be used for this, instead. Then it could be done
> in the driver (the driver should't directly mess with SIU internals).
Maybe it should then be done in the boot wrapper. If the device
tree lists this line as an interrupt, I'd say that is what it should
be.
> >> +static struct of_device_id __initdata of_bus_ids[] = {
> >> + { .name = "soc", },
> >> + { .name = "cpm", },
> >> + { .name = "localbus", },
> >> + {},
> >> +};
> >
> > Shouldn't this check for 'compatible' properties instead of 'name'?
>
> I copied this from mpc885ads_setup.c.
Right, I noticed before that we're rather inconsistent with this.
It would really be good to have more common standards on this.
> > I also once did a patch that let you have a default 'of_bus_ids'
> > member in the ppc_md. I never got around to submitting that, but
> > if there is interest, I can dig it out again.
>
> That would be nice :)
The reason I haven't submitted it yet is that I'm not sure whether
there are cases where we actually _need_ to test for 'name' instead
of 'compatible' because of existing device trees in firmware.
I might just do a patch and see if someone complains about the
idea.
Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] arch/x86: Use offsetof
Hi! > From: Julia Lawall <[EMAIL PROTECTED]> > > In the patch cc154ac64aa8d3396b187f64cef01ce67f433324, Al Viro observed > that the proper way to compute the distance between two structure fields is > to use offsetof() or a cast to a pointer to character. The same change can > be applied to a few more files. > > The change was made using the following semantic patch > (http://www.emn.fr/x-info/coccinelle/) > > // > @r@ > type T; > T s; > type T1, T2; > identifier fld1, fld2; > typedef uint8_t; > typedef u8; > @@ > > ( > (char *) - (char *) > | > (uint8_t *) - (uint8_t *) > | > (u8 *) - (u8 *) > | > - (T1) - (T2) > + offsetof(T,fld1) - offsetof(T,fld2) > ) > // > > Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> > --- > > diff -u -p a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c > --- a/arch/x86/kernel/vm86_32.c 2007-10-22 11:25:00.0 +0200 > +++ b/arch/x86/kernel/vm86_32.c 2007-12-26 16:27:15.0 +0100 > @@ -215,7 +215,9 @@ asmlinkage int sys_vm86old(struct pt_reg > ret = -EFAULT; > if (tmp) > goto out; > - memset(, 0, (int) - (int)); > + memset(, 0, > +offsetof(struct kernel_vm86_struct, regs32) - > +offsetof(struct kernel_vm86_struct, vm86plus)); I do not think this makes it more readable... (int) -> (char *) would make it portable and readable, AFAICT. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fs/autofs: Use time_before, time_before_eq, etc.
On Wed, 26 Dec 2007, H. Peter Anvin wrote: > Julia Lawall wrote: > > From: Julia Lawall <[EMAIL PROTECTED]> > > > > The functions time_before, time_before_eq, time_after, and time_after_eq > > are more robust for comparing jiffies against other values. > > > > More robust, how? You already almost introduced a bug here... I'm just summarizing the comment that goes with the definition of the time_after etc functions: include/linux/jiffies.h:88 /* * These inlines deal with timer wrapping correctly. You are * strongly encouraged to use them * 1. Because people otherwise forget * 2. Because if the timer wrap changes in future you won't have to * alter your driver code. * julia -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 06/55] KVM: Per-architecture hypercall definitions
Hi!
> Currently kvm provides hypercalls only for x86* architectures. To
> provide hypercall infrastructure for other kvm architectures I split
> kvm_para.h into a generic header file and architecture specific
> definitions.
>
> Signed-off-by: Christian Borntraeger <[EMAIL PROTECTED]>
> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
> ---
> include/asm-x86/kvm_para.h | 105
>
> include/linux/kvm_para.h | 105
> +---
> 2 files changed, 117 insertions(+), 93 deletions(-)
> create mode 100644 include/asm-x86/kvm_para.h
>
> diff --git a/include/asm-x86/kvm_para.h b/include/asm-x86/kvm_para.h
> new file mode 100644
> index 000..c6f3fd8
> --- /dev/null
> +++ b/include/asm-x86/kvm_para.h
> @@ -0,0 +1,105 @@
> +#ifndef __X86_KVM_PARA_H
> +#define __X86_KVM_PARA_H
> +
> +/* This CPUID returns the signature 'KVMKVMKVM' in ebx, ecx, and edx. It
> + * should be used to determine that a VM is running under KVM.
> + */
> +#define KVM_CPUID_SIGNATURE 0x4000
so it returns 'KVMKVMKVM' in %rax, too?
> +/* For KVM hypercalls, a three-byte sequence of either the vmrun or the
> vmmrun
> + * instruction. The hypervisor may replace it with something else but only
> the
> + * instructions are guaranteed to be supported.
> + *
> + * Up to four arguments may be passed in rbx, rcx, rdx, and rsi respectively.
> + * The hypercall number should be placed in rax and the return
rax? First, this file is shared with i386, AFAICT.
> + * placed in rax. No other registers will be clobbered unless explicited
> + * noted by the particular hypercall.
> + */
> +
> +static inline long kvm_hypercall0(unsigned int nr)
> +{
> + long ret;
> + asm volatile(KVM_HYPERCALL
> + : "=a"(ret)
> + : "a"(nr));
Second, if it is to be placed in rax, nr should be unsigned long?
> +static inline int kvm_para_available(void)
> +{
> + unsigned int eax, ebx, ecx, edx;
> + char signature[13];
> +
> + cpuid(KVM_CPUID_SIGNATURE, , , , );
> + memcpy(signature + 0, , 4);
> + memcpy(signature + 4, , 4);
> + memcpy(signature + 8, , 4);
> + signature[12] = 0;
> +
ebx|ecx|ed
> + if (strcmp(signature, "KVMKVMKVM") == 0)
> + return 1;
Should the comment say
> +/* This CPUID returns the signature 'KVMKVMKVM\0\0\0' in ebx, ecx, and edx.
> It
> + * should be used to determine that a VM is running under KVM.
> + */
Plus, I'd use memcmp, and actually test for those zeros, too.
...which probably can be done later, as this is pure move...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 09/13] remove race between use and initialization of locks
On Fri, Dec 21, 2007 at 10:00:40PM -0800, Andrew Morton wrote:
> On Thu, 20 Dec 2007 17:15:57 -0500 "Ed L. Cashin" <[EMAIL PROTECTED]> wrote:
...
> > +static __DECLARE_SEMAPHORE_GENERIC(emsgs_sema, 0);
...
> > - sema_init(_sema, 0);
> > - spin_lock_init(_lock);
> > aoe_class = class_create(THIS_MODULE, "aoe");
> > if (IS_ERR(aoe_class)) {
> > unregister_chrdev(AOE_MAJOR, "aoechr");
>
> I think it would be better to go back to initialising emsgs_lock at runtime
> rather than fattening the exported semaphore API like this.
I don't think there is anything wrong with having a complete set of
initialization routines for a semaphore, but it's certainly easy
enough to go back to Alexey Dobriyan's original suggestion, which was
to simply move the initialization calls before register_chardev.
I will follow this email with a patch that does that.
> emssgs_sema is a weird-looking thing. There really should be some comments
> in there because it is unobvious what the code is attempting to do.
>
> What is the code attempting to do?
There is a ring buffer of error messages. Userland processes can read
these error messages by reading /dev/etherd/err, blocking if there are
no error messages to read yet.
The emsgs_sema semaphore is used to manage the reader(s) waiting for
error messages. When there are sleepers waiting, "up" is used to wake
one up when a new error message is produced. A reader gets a single
message, not just some text with a mixture of different errors.
If I do,
cat /dev/etherd/err > /my/log/file
... then I can hit control-c or send a SIGTERM to stop it.
> It appears to me that nblocked_emsgs_readers gets incorrectly
> decremented if the down_interruptible() got interrupted, btw.
The counter will be incremented again if the process goes back to
sleep waiting for an error message, but the process might be getting
killed. The counter is really just for sleeping readers.
--
Ed L Cashin <[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: [RFC] sleepy linux
Pavel Machek wrote: Yep... for the first version, I'll be very happy if it autosleeps when I'm traveling by bus or something. Working with ethernet plugged in is quite a distant goal. (But I guess some cleverness could be done on the router or something. Automagically converting "interesting" packets into WoL enabled ones, or...?) Pavel You've just eliminated 90%+ of the available Ethernet infrastructure. However, there may be Ethernet controllers which can do something smart with incoming packets, and perhaps more importantly, we can always write a spec and try to push it to Intel, Broadcom, Realtek and Nvidia. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 18:28:04, Oliver Neukum wrote: > Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > > Heute 00:07:31 > > > > This is RFC. It does not even work for me... it sleeps but it will not > > wake up, because SATA wakeup code is missing. Code attached for > > illustration. > > > > I wonder if this is the right approach? What is right interface to the > > drivers? > > IMHO you are making to many special cases. The system can be "sleepy" > if all devices can be runtime suspended and all CPUs are idle. Pretty much, except that "timer device" needs to be runtime suspended, too... We probably should not sleep if wakeup is scheduled 1 second in future. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
On Wed 2007-12-26 10:56:59, H. Peter Anvin wrote: > Pavel Machek wrote: >> This is RFC. It does not even work for me... it sleeps but it will not >> wake up, because SATA wakeup code is missing. Code attached for >> illustration. >> I wonder if this is the right approach? What is right interface to the >> drivers? >> 3) Network card that is either down >>or can wake up system on any packet (and not loose too many packets) > > This is the big crux I see. You're going to constantly wake up the machine > due to broadcast packets, and spend a lot of power just going in and out of > S3. Yep... for the first version, I'll be very happy if it autosleeps when I'm traveling by bus or something. Working with ethernet plugged in is quite a distant goal. (But I guess some cleverness could be done on the router or something. Automagically converting "interesting" packets into WoL enabled ones, or...?) Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Pavel Machek wrote: This is RFC. It does not even work for me... it sleeps but it will not wake up, because SATA wakeup code is missing. Code attached for illustration. I wonder if this is the right approach? What is right interface to the drivers? 3) Network card that is either down or can wake up system on any packet (and not loose too many packets) This is the big crux I see. You're going to constantly wake up the machine due to broadcast packets, and spend a lot of power just going in and out of S3. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Order of Loading mmc driver modules.
Hi All, I am working with pxamci driver(2.6.22.1). I have made , core and host as separate modules. what is the correct order of loading the modules i am doing in this order first core (mmc_core.ko), then card(mmc_block.ko) after that host driver ( pxamci.ko). Is this correct. I do not know much about Linux device model. i saw that pxamci.ko driver registers it self as platform_driver. When does its probe function is called. Is it called immediately after platform_driver_register(_driver) is called. also in card driver (mmc_block.ko) in block.c file i saw a probe function(mmc_blk_probe). How does it is invoked . Thanks in advance for your help. -- Thanks raki -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: /dev/urandom uses uninit bytes, leaks user data
Andrew Lutomirski wrote: No, it's there, and if there's little enough entropy around it can be recovered by brute force. A little entropy is enough to prevent a brute force attack. You would have to have ZERO entropy after a cold boot so the attacker would know exactly the contents of the pool, AND know that one and ONLY one other task has read from /dev/urandom, AND exactly what time that task did so, AND how many bytes it read. Only then could the attacker read from urandom and based on those bytes and the previous known pool state, brute force the 3 bytes that came from some unknown location in the other task's memory. Step 1: Boot a system without a usable entropy source. Step 2: add some (predictable) "entropy" from userspace which isn't a multiple of 4, so up to three extra bytes get added. Step 3: Read a few bytes of /dev/random and send them over the network. Only root can do 1 and 2, at which point, it's already game over. Again, no. Root could do this accidentally. Step 1 happens all the time (see the comments on non-unique UUIDs). Step 2 just requires a It does not happen all the time. It happens on a system that has just been cold booted from read only distribution media with a broken cmos clock, no user keyboard interaction, and no hardware rng and that's it. Every other system is going to have some entropy from the last boot at least. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Why does reading from /dev/urandom deplete entropy so much?
Marc Haber wrote: On Tue, Dec 11, 2007 at 10:42:49AM -0500, Bill Davidsen wrote: The original point was that urandom draws entropy from random, and that it is an an inobvious and unintentional drain on the entropy pool. At least that's how I read it. And you are reading it correct. At least one of the major TLS libraries does it this way, putting unnecessary stress on the kernel entropy pool. While I now consider this a bug in the library, there surely are gazillions of similiarily flawed applications out there in the wild. It seems to me that reading from (u)random disturbs the entropy pool, so the more consumers reading from the pool in unpredictable ways, the better. As it is currently implemented, it lowers the entropy estimate, but the pool will have MORE entropy if several applications keep reading /dev/random periodically when they need random bytes instead of just reading it once to seed their own prng. IMHO, it is the entropy estimate that is broken, not the TLS library. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] is checkpatch.pl broken
[H. Peter Anvin - Wed, Dec 26, 2007 at 09:44:18AM -0800] > Cyrill Gorcunov wrote: >> >>> >> It's a quite true, sorry for this and thanks for the note. And Peter, >> the line I marked >> is not to be splitted even having additional spaces over math operators. >> Look >> >> orig: >> mbr_base = (buf_base+sector_size-1) & ~(sector_size-1); >> new (could be): >> mbr_base = (buf_base + sector_size - 1) & ~(sector_size - 1); >> >> Is a new version that bad? > > Certainly isn't any better. > > -hpa > ok, i'm leaving this section then, thanks for comments Peter. - Cyrill - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: VGA Drivers
pradeep pradeep wrote: > Hi, > I want to support a new PCI based VGA card in > linux. I want to know what is the VGA driver stack in > the Linux. Can any one help me where to start. Assuming you're not talking about a VGA grabber card here... Graphics/ X drivers are mostly in userspace except some DRI/DRM infrastructure and AGP code. You should start looking at the XOrg project. The kernel has some framebuffer support, but I'm not sure that is what you are looking for. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Suspend code ordering (again)
Alexey Starikovskiy wrote: I don't know. Windows was compliant only with 1.x spec until Vista. With Vista claims are 3.x compliance. In other words, the 1.x spec is the only thing that matters, at least in the short term (*noone* is giving up XP compatibility at this point.) -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] fs/autofs: Use time_before, time_before_eq, etc.
Julia Lawall wrote: From: Julia Lawall <[EMAIL PROTECTED]> The functions time_before, time_before_eq, time_after, and time_after_eq are more robust for comparing jiffies against other values. More robust, how? You already almost introduced a bug here... -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [x86] is checkpatch.pl broken
Cyrill Gorcunov wrote: It's a quite true, sorry for this and thanks for the note. And Peter, the line I marked is not to be splitted even having additional spaces over math operators. Look orig: mbr_base = (buf_base+sector_size-1) & ~(sector_size-1); new (could be): mbr_base = (buf_base + sector_size - 1) & ~(sector_size - 1); Is a new version that bad? Certainly isn't any better. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] sleepy linux
Am Mittwoch, 26. Dezember 2007 00:07:31 schrieb Pavel Machek: > Heute 00:07:31 > > This is RFC. It does not even work for me... it sleeps but it will not > wake up, because SATA wakeup code is missing. Code attached for illustration. > > I wonder if this is the right approach? What is right interface to the > drivers? IMHO you are making to many special cases. The system can be "sleepy" if all devices can be runtime suspended and all CPUs are idle. Regards Oliver -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: list corruption on ib_srp load in v2.6.24-rc5
On Sun, 2007-12-23 at 01:41 +0900, FUJITA Tomonori wrote:
> transport_container_unregister(>rport_attr_cont) should not fail here.
>
> It fails because there is still a srp rport.
>
> I think that as Pete pointed out, srp_remove_one needs to call
> srp_remove_host.
>
> Can you try this?
That patched oopsed in scsi_remove_host(), but reversing the order has
survived over 500 insert/probe/remove cycles.
Tested-by: David Dillow <[EMAIL PROTECTED]>
---
diff --git a/drivers/infiniband/ulp/srp/ib_srp.c
b/drivers/infiniband/ulp/srp/ib_srp.c
index 950228f..77e8b90 100644
--- a/drivers/infiniband/ulp/srp/ib_srp.c
+++ b/drivers/infiniband/ulp/srp/ib_srp.c
@@ -2054,6 +2054,7 @@ static void srp_remove_one(struct ib_device *device)
list_for_each_entry_safe(target, tmp_target,
>target_list, list) {
scsi_remove_host(target->scsi_host);
+ srp_remove_host(target->scsi_host);
srp_disconnect_target(target);
ib_destroy_cm_id(target->cm_id);
srp_free_target_ib(target);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/7] sg_ring: convert core ATA code to sg_ring.
On Wed, 2007-12-26 at 17:36 +0900, Tejun Heo wrote: > (PS, I haven't followed the sg chaining discussion. Why is sg chaining > an optional feature? Performance overhead on low end machines?) The idea of SG chaining is to allow drivers that wish to take advantage of it to increase their transfer lengths beyond MAX_HW_SEGMENTS*PAGE_SIZE by using chaining. However, drivers that stay below MAX_HW_SEGMENTS for the scatterlist length don't need to be altered. The ultimate goal (well, perhaps more wish) is to have all drivers converted, so SCSI can use something small for the default scatterlist sizing and dump all the sglist mempool stuff (although this may never be reached). James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Testing RAM from userspace / question about memmap= arguments
On Wed, 26 Dec 2007 00:09:57 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote: > On Sat 2007-12-22 12:09:59, Arjan van de Ven wrote: > > On Tue, 18 Dec 2007 17:06:24 + > > memtest86+ does various magic to basically bypass the caches (by > > disabling them ;-)... Doing that in a live kernel situation, and > > from userspace to boot.. that's... and issue. > > Are you sure? I always assumed that memtest just used patterns bigger > than L1/L2 caches... that's... not nearly usable or enough. Caches are relatively smart about things like use-once and they're huge. 12Mb today. You'd need patterns bigger than 100Mb to get even close to being reasonably confident that there's nothing left. > ... and IIRC my celeron testing confirmed it, if > I disabled L2 cache in BIOS, memtest behave differently. > > Anyway, if you can do iopl(), we may as well let you disable caches, > but you are right, that will need a kernel patch. and a new syscall of some sorts I suspect; "flush all caches" is a ring 0 operation (and you probably need to do it in an ipi anyway on all cpus) -- If you want to reach me at my work email, use [EMAIL PROTECTED] For development, discussion and tips for power savings, visit http://www.lesswatts.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage
On Wed, 26 Dec 2007 19:52:56 +1100, James Morris said: > On Wed, 26 Dec 2007, [EMAIL PROTECTED] wrote: > > > On Wed, 26 Dec 2007 18:34:26 +1100, James Morris said: > > > > > Can you post your .config ? > > > > The gzip'ed config as of when I quit bisecting is attached. It's probably > > not directly usable unless you have a quilt tree that's positioned fairly > > close to git-lblnet.patch. > > What does the following say ? > > # sestatus && rpm -q selinux-policy I'm running MLS in permissive mode, so there shouldn't be any SElinux denials happening. pgpazqwH4fsrD.pgp Description: PGP signature
Re: TOMOYO Linux Security Goal
Quoting Tetsuo Handa ([EMAIL PROTECTED]): > This document is intended to specify the security goal that TOMOYO Linux is > trying to achieve, so that users can evaluate whether TOMOYO Linux will meet > their needs, and kernel developers can evaluate whether TOMOYO Linux deserved > to be in-tree. > > 1. About TOMOYO Linux > > Project Homepage: http://tomoyo.sourceforge.jp/index.html.en > Project Wiki: http://elinux.org/TomoyoLinux > > TOMOYO Linux is a DIY tool for understanding and protecting your system. > TOMOYO Linux policy definitions are absolutely readable to Linux users, and > TOMOYO Linux supports unique policy learning mechanism which automatically Are they in fact unique? > gathers information and arranges the results as policy definitions. > These things made it possible for users to write policy from scratch. > Troubleshooting can be done by users. > We put some TOMOYO Linux policy examples on our web site. > > http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/etch/domain_policy.conf?v=policy-sample > > 2. TOMOYO Linux Security Goal This section seems to me to be the most important one, and could really use a little more detail. > The TOMOYO Linux's security goal is to provide "MAC that covers practical > requirements This email promised me a security goal, but instead of laying out requirements it meets, its says it meets "practical requirements". That's really not helpful. What kernel resources does TOMOYO authorize? All those which SELinux does? > for most users and keeps usable for most administrators". > TOMOYO Linux is not a tool for security professional but for average users > and administrators. So your point was that your main goal is simplicity? Ok a few things you could add: 1. Tomoyo provide no sort of information flow control. 2. TOMOYO is purely restrictive. 3. Learning mode is primary source of policy so you depend on change of behavior to detect intruders. 4. but any intruder who attempts to do something which the compomised sftware wouldn't have done should be stopped and detected. This gives a precise (though perhaps wrong as I'm guessing :) picture of what TOMOYO can do and how it fits in with SMACK, apparmor, capabilities, and SELinux. thanks, -serge > 3. Our Approach > > To meet the above goal, TOMOYO Linux attempts to make the system where > everything is prearranged in an easy-to-understand way. > > * Make the all subject's all access requests that will occur at least once > during the lifetime of the kernel known in advance. > > * Let the administrator understand what access requests will each subject > raise in his/her system and write policy which only allows expected and > desirable access requests for his/her needs. > > Unlike AppArmor, TOMOYO Linux is intended to protect the whole system from > attackers exploiting vulnerabilities in applications that the system hosts. > The threat is that an attacker can cause a vulnerable application to do > something unexpected and undesirable. TOMOYO Linux addresses this threat by > recording all applications' behaviors in the test environment and forcing > all applications behave within recorded behaviors in the production > environment. > > TOMOYO Linux has a unique concept of "process invocation history" > (in short, PIH). The PIH is a developmental lineage of a process. > When a process executes a program, the process creates a copy with fork() and > replace the copy with execve(). > TOMOYO Linux appends the pathname of the executed program to the PIH of > the replaced process, and associates process's PIH (stored in task_struct) > with a domain. > As a result, the context switching (a.k.a. domain transition) is > unidirectional. > This rule allows administrator distinguish and manage fine-grained context. > Domain transition forms tree structure like a directory tree of filesystems. > Each domain has different set of permissions that are essential for that > domain. > > 4. Things you can do with TOMOYO Linux. > > Create policy from scratch. > > You want to use ready-made policy files supplied by somebody else > because testing all paths needed for your usage sounds boring? > > OK, then you can choose other implementations that provide > ready-made policy files, but you should check whether these files > contain enough permissions for your usage or not. It is inevitable thing > to test all paths needed for your usage if you want to use white listing > access control. > > Also, ready-made policy files tend to contain redundant permissions > for your usage which often leads to serious problem. > > TOMOYO Linux is a DIY tool for understanding and protecting your Linux box. > TOMOYO Linux's "learning mode" will automatically generate > policy files with necessary and sufficient permissions for you. > > Understand all possible requests. > > TOMOYO Linux reports what is happening
[PATCH 3/3] drivers/scsi: Use offsetof
From: Julia Lawall <[EMAIL PROTECTED]> In the patch cc154ac64aa8d3396b187f64cef01ce67f433324, Al Viro observed that the proper way to compute the distance between two structure fields is to use offsetof() or a cast to a pointer to character. The same change can be applied to a few more files. The change was made using the following semantic patch (http://www.emn.fr/x-info/coccinelle/) // @r3 disable ptr_to_array@ type T; T *s; type T1, T2; identifier fld1; @@ ( (char *)>fld1 - (char *)s | (uint8_t *)>fld1 - (uint8_t *)s | (u8 *)>fld1 - (u8 *)s | - (T1)>fld1 - (T2)s + offsetof(T,fld1) ) // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -u -p a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c --- a/drivers/scsi/BusLogic.c 2007-10-22 11:25:20.0 +0200 +++ b/drivers/scsi/BusLogic.c 2007-12-26 16:33:42.0 +0100 @@ -2856,7 +2856,10 @@ static int BusLogic_QueueCommand(struct CCB->Opcode = BusLogic_InitiatorCCB_ScatterGather; CCB->DataLength = Count * sizeof(struct BusLogic_ScatterGatherSegment); if (BusLogic_MultiMasterHostAdapterP(HostAdapter)) - CCB->DataPointer = (unsigned int) CCB->DMA_Handle + ((unsigned long) >ScatterGatherList - (unsigned long) CCB); + CCB->DataPointer = + (unsigned int) CCB->DMA_Handle + + offsetof(struct BusLogic_CCB, +ScatterGatherList); else CCB->DataPointer = Virtual_to_32Bit_Virtual(CCB->ScatterGatherList); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] drivers/s390: Use offsetof
From: Julia Lawall <[EMAIL PROTECTED]>
In the patch cc154ac64aa8d3396b187f64cef01ce67f433324, Al Viro observed
that the proper way to compute the distance between two structure fields is
to use offsetof() or a cast to a pointer to character. The same change can
be applied to a few more files.
The change was made using the following semantic patch
(http://www.emn.fr/x-info/coccinelle/)
//
@r3 disable ptr_to_array@
type T;
T *s;
type T1, T2;
identifier fld1;
@@
(
(char *)>fld1 - (char *)s
|
(uint8_t *)>fld1 - (uint8_t *)s
|
(u8 *)>fld1 - (u8 *)s
|
- (T1)>fld1 - (T2)s
+ offsetof(T,fld1)
)
@@
type T;
expression E;
@@
- (int)(offsetof(T,E))
+ offsetof(T,E)
//
Signed-off-by: Julia Lawall <[EMAIL PROTECTED]>
---
diff -u -p a/drivers/s390/scsi/zfcp_dbf.c b/drivers/s390/scsi/zfcp_dbf.c
--- a/drivers/s390/scsi/zfcp_dbf.c 2007-10-22 11:25:20.0 +0200
+++ b/drivers/s390/scsi/zfcp_dbf.c 2007-12-26 16:25:51.0 +0100
@@ -614,7 +614,7 @@ void zfcp_san_dbf_event_incoming_els(str
struct fsf_status_read_buffer *status_buffer =
(struct fsf_status_read_buffer *)fsf_req->data;
int length = (int)status_buffer->length -
- (int)((void *)_buffer->payload - (void *)status_buffer);
+ offsetof(struct fsf_status_read_buffer, payload);
_zfcp_san_dbf_event_common_els("iels", 1, fsf_req, status_buffer->d_id,
fc_host_port_id(adapter->scsi_host),
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] arch/x86: Use offsetof
From: Julia Lawall <[EMAIL PROTECTED]> In the patch cc154ac64aa8d3396b187f64cef01ce67f433324, Al Viro observed that the proper way to compute the distance between two structure fields is to use offsetof() or a cast to a pointer to character. The same change can be applied to a few more files. The change was made using the following semantic patch (http://www.emn.fr/x-info/coccinelle/) // @r@ type T; T s; type T1, T2; identifier fld1, fld2; typedef uint8_t; typedef u8; @@ ( (char *) - (char *) | (uint8_t *) - (uint8_t *) | (u8 *) - (u8 *) | - (T1) - (T2) + offsetof(T,fld1) - offsetof(T,fld2) ) // Signed-off-by: Julia Lawall <[EMAIL PROTECTED]> --- diff -u -p a/arch/x86/kernel/vm86_32.c b/arch/x86/kernel/vm86_32.c --- a/arch/x86/kernel/vm86_32.c 2007-10-22 11:25:00.0 +0200 +++ b/arch/x86/kernel/vm86_32.c 2007-12-26 16:27:15.0 +0100 @@ -215,7 +215,9 @@ asmlinkage int sys_vm86old(struct pt_reg ret = -EFAULT; if (tmp) goto out; - memset(, 0, (int) - (int)); + memset(, 0, + offsetof(struct kernel_vm86_struct, regs32) - + offsetof(struct kernel_vm86_struct, vm86plus)); info.regs32 = tsk->thread.vm86_info = v86; do_sys_vm86(, tsk); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage
As James said I'm away right now and computer access is limited. However, I'm stuck in the airport right now and spent some time looking at the code ... Based on what has been found so far I wonder if the problem isn't a race but a problem of skb->iif never being initialized correctly? To my untrained eye it looks like __netdev_alloc_skb() should be setting skb->iif (like it does for skb->dev) but it currently doesn't. Am I barking up the wrong tree here? . paul moore . linux security @ hp -Original Message- From: James Morris <[EMAIL PROTECTED]> Date: Wednesday, Dec 26, 2007 7:16 am Subject: Re: 2.6.24-rc6-mm1 - git-lblnet.patch and networking horkage To: [EMAIL PROTECTED] CC: Andrew Morton <[EMAIL PROTECTED]>, Paul Moore <[EMAIL PROTECTED]>, linux-kernel@vger.kernel.org, Stephen Smalley <[EMAIL PROTECTED]> On Wed, 26 Dec 2007, James Morris wrote: > >> What does the following say ? > > # sestatus && rpm -q selinux-policy > >Don't worry about that -- I reproduced it with Paul Moore's git tree: >git://git.infradead.org/users/pcmoore/lblnet-2.6_testing > >(under current -mm, the e1000 driver doesn't find my ethernet card & the >tcl tests won't run without an external interface). > >The offending commit is when SELinux is converted to the new ifindex >interface: > > 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 is first bad commit > commit 9c6ad8f6895db7a517c04c2147cb5e7ffb83a315 > Author: Paul Moore <[EMAIL PROTECTED]> > Date: Fri Dec 21 11:44:26 2007 -0500 > > SELinux: Convert the netif code to use ifindex values > > [...] > >In some case (not yet fully identified -- also happens when avahi starts >up, although seemingly silently & without obvious issues), SELinux is >passed an ifindex of 1515870810, which corresponds to 0x5a5a5a5a, the slab >poison value, suggesting a race in the calling code where we're being >asked to check an skb which has been freed. > >The SELinux code is erroring out before performing an access check >(perhaps there should be WARN_ON, at least), so this will affect both >permissive and enforcing mode without generating any log messages. > >Andrew: I suggest dropping the patchset from -mm until Paul gets back from >vacation. > > >- 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: [PATCH 00/63] ide-cd: redux
On Tue, Dec 25, 2007 at 02:05:14PM -0800, Andrew Morton wrote: > On Thu, 20 Dec 2007 01:48:49 +0100 Bartlomiej Zolnierkiewicz <[EMAIL > PROTECTED]> wrote: > > > This patch series is a major rework of the ide-cd driver. > > woo-hoo. > > > PS ide-cd Maintainer position is still open... > > boo-hoo. > > I wish someone would fix that "The drive appears confused (ireason = > 0x%02x)" thing. I had a go a while back but iirc the reporter disappeared > on me. It is somewhat common. > > Or do you think this patch might indeed fix it? Andrew, take a look at patch #12 in this series: "ide-cd: fix "missing data" handling in cdrom_pc_intr()." -- Regards/Gruß, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
