* [PATCH 4/5] lguest: use KVM hypercalls
@ 2009-03-26 23:52 Rusty Russell
2009-04-02 21:55 ` [Lguest] " Simon Holm Thøgersen
0 siblings, 1 reply; 46+ messages in thread
From: Rusty Russell @ 2009-03-26 23:52 UTC (permalink / raw)
To: lguest-mnsaURCQ41sdnm+yROfE0A
Cc: virtualization-qjLDD68F18O7TbgM5vRIOg, Matias Zabaljauregui,
Ingo Molnar, linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Matias Zabaljauregui <zabaljauregui-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Impact: cleanup
This patch allow us to use KVM hypercalls
Signed-off-by: Matias Zabaljauregui <zabaljauregui at gmail.com>
Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
---
arch/x86/include/asm/lguest_hcall.h | 24 +---------
arch/x86/lguest/boot.c | 80 +++++++++++++++++++++-------------
arch/x86/lguest/i386_head.S | 4 -
drivers/lguest/interrupts_and_traps.c | 7 +-
drivers/lguest/lguest_device.c | 4 -
drivers/lguest/x86/core.c | 62 +++++++++++++++++++++++++-
6 files changed, 123 insertions(+), 58 deletions(-)
diff --git a/arch/x86/include/asm/lguest_hcall.h b/arch/x86/include/asm/lguest_hcall.h
--- a/arch/x86/include/asm/lguest_hcall.h
+++ b/arch/x86/include/asm/lguest_hcall.h
@@ -27,36 +27,20 @@
#ifndef __ASSEMBLY__
#include <asm/hw_irq.h>
+#include <asm/kvm_para.h>
/*G:031 But first, how does our Guest contact the Host to ask for privileged
* operations? There are two ways: the direct way is to make a "hypercall",
* to make requests of the Host Itself.
*
- * Our hypercall mechanism uses the highest unused trap code (traps 32 and
- * above are used by real hardware interrupts). Fifteen hypercalls are
+ * We use the KVM hypercall mechanism. Eighteen hypercalls are
* available: the hypercall number is put in the %eax register, and the
- * arguments (when required) are placed in %edx, %ebx and %ecx. If a return
+ * arguments (when required) are placed in %ebx, %ecx and %edx. If a return
* value makes sense, it's returned in %eax.
*
* Grossly invalid calls result in Sudden Death at the hands of the vengeful
* Host, rather than returning failure. This reflects Winston Churchill's
* definition of a gentleman: "someone who is only rude intentionally". */
-static inline unsigned long
-hcall(unsigned long call,
- unsigned long arg1, unsigned long arg2, unsigned long arg3)
-{
- /* "int" is the Intel instruction to trigger a trap. */
- asm volatile("int $" __stringify(LGUEST_TRAP_ENTRY)
- /* The call in %eax (aka "a") might be overwritten */
- : "=a"(call)
- /* The arguments are in %eax, %edx, %ebx & %ecx */
- : "a"(call), "d"(arg1), "b"(arg2), "c"(arg3)
- /* "memory" means this might write somewhere in memory.
- * This isn't true for all calls, but it's safe to tell
- * gcc that it might happen so it doesn't get clever. */
- : "memory");
- return call;
-}
/*:*/
/* Can't use our min() macro here: needs to be a constant */
@@ -65,7 +49,7 @@ hcall(unsigned long call,
#define LHCALL_RING_SIZE 64
struct hcall_args {
/* These map directly onto eax, ebx, ecx, edx in struct lguest_regs */
- unsigned long arg0, arg2, arg3, arg1;
+ unsigned long arg0, arg1, arg2, arg3;
};
#endif /* !__ASSEMBLY__ */
diff --git a/arch/x86/lguest/boot.c b/arch/x86/lguest/boot.c
--- a/arch/x86/lguest/boot.c
+++ b/arch/x86/lguest/boot.c
@@ -107,7 +107,7 @@ static void async_hcall(unsigned long ca
local_irq_save(flags);
if (lguest_data.hcall_status[next_call] != 0xFF) {
/* Table full, so do normal hcall which will flush table. */
- hcall(call, arg1, arg2, arg3);
+ kvm_hypercall3(call, arg1, arg2, arg3);
} else {
lguest_data.hcalls[next_call].arg0 = call;
lguest_data.hcalls[next_call].arg1 = arg1;
@@ -134,13 +134,32 @@ static void async_hcall(unsigned long ca
*
* So, when we're in lazy mode, we call async_hcall() to store the call for
* future processing: */
-static void lazy_hcall(unsigned long call,
+static void lazy_hcall1(unsigned long call,
+ unsigned long arg1)
+{
+ if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE)
+ kvm_hypercall1(call, arg1);
+ else
+ async_hcall(call, arg1, 0, 0);
+}
+
+static void lazy_hcall2(unsigned long call,
+ unsigned long arg1,
+ unsigned long arg2)
+{
+ if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE)
+ kvm_hypercall2(call, arg1, arg2);
+ else
+ async_hcall(call, arg1, arg2, 0);
+}
+
+static void lazy_hcall3(unsigned long call,
unsigned long arg1,
unsigned long arg2,
unsigned long arg3)
{
if (paravirt_get_lazy_mode() == PARAVIRT_LAZY_NONE)
- hcall(call, arg1, arg2, arg3);
+ kvm_hypercall3(call, arg1, arg2, arg3);
else
async_hcall(call, arg1, arg2, arg3);
}
@@ -150,7 +169,7 @@ static void lguest_leave_lazy_mode(void)
static void lguest_leave_lazy_mode(void)
{
paravirt_leave_lazy(paravirt_get_lazy_mode());
- hcall(LHCALL_FLUSH_ASYNC, 0, 0, 0);
+ kvm_hypercall0(LHCALL_FLUSH_ASYNC);
}
/*G:033
@@ -224,7 +243,7 @@ static void lguest_write_idt_entry(gate_
/* Keep the local copy up to date. */
native_write_idt_entry(dt, entrynum, g);
/* Tell Host about this new entry. */
- hcall(LHCALL_LOAD_IDT_ENTRY, entrynum, desc[0], desc[1]);
+ kvm_hypercall3(LHCALL_LOAD_IDT_ENTRY, entrynum, desc[0], desc[1]);
}
/* Changing to a different IDT is very rare: we keep the IDT up-to-date every
@@ -236,7 +255,7 @@ static void lguest_load_idt(const struct
struct desc_struct *idt = (void *)desc->address;
for (i = 0; i < (desc->size+1)/8; i++)
- hcall(LHCALL_LOAD_IDT_ENTRY, i, idt[i].a, idt[i].b);
+ kvm_hypercall3(LHCALL_LOAD_IDT_ENTRY, i, idt[i].a, idt[i].b);
}
/*
@@ -256,8 +275,8 @@ static void lguest_load_idt(const struct
*/
static void lguest_load_gdt(const struct desc_ptr *desc)
{
- BUG_ON((desc->size+1)/8 != GDT_ENTRIES);
- hcall(LHCALL_LOAD_GDT, __pa(desc->address), GDT_ENTRIES, 0);
+ BUG_ON((desc->size + 1) / 8 != GDT_ENTRIES);
+ kvm_hypercall2(LHCALL_LOAD_GDT, __pa(desc->address), GDT_ENTRIES);
}
/* For a single GDT entry which changes, we do the lazy thing: alter our GDT,
@@ -267,7 +286,7 @@ static void lguest_write_gdt_entry(struc
const void *desc, int type)
{
native_write_gdt_entry(dt, entrynum, desc, type);
- hcall(LHCALL_LOAD_GDT, __pa(dt), GDT_ENTRIES, 0);
+ kvm_hypercall2(LHCALL_LOAD_GDT, __pa(dt), GDT_ENTRIES);
}
/* OK, I lied. There are three "thread local storage" GDT entries which change
@@ -279,7 +298,7 @@ static void lguest_load_tls(struct threa
* can't handle us removing entries we're currently using. So we clear
* the GS register here: if it's needed it'll be reloaded anyway. */
loadsegment(gs, 0);
- lazy_hcall(LHCALL_LOAD_TLS, __pa(&t->tls_array), cpu, 0);
+ lazy_hcall2(LHCALL_LOAD_TLS, __pa(&t->tls_array), cpu);
}
/*G:038 That's enough excitement for now, back to ploughing through each of
@@ -377,7 +396,7 @@ static unsigned long current_cr0;
static unsigned long current_cr0;
static void lguest_write_cr0(unsigned long val)
{
- lazy_hcall(LHCALL_TS, val & X86_CR0_TS, 0, 0);
+ lazy_hcall1(LHCALL_TS, val & X86_CR0_TS);
current_cr0 = val;
}
@@ -391,7 +410,7 @@ static unsigned long lguest_read_cr0(voi
* the vowels have been optimized out. */
static void lguest_clts(void)
{
- lazy_hcall(LHCALL_TS, 0, 0, 0);
+ lazy_hcall1(LHCALL_TS, 0);
current_cr0 &= ~X86_CR0_TS;
}
@@ -413,7 +432,7 @@ static void lguest_write_cr3(unsigned lo
static void lguest_write_cr3(unsigned long cr3)
{
lguest_data.pgdir = cr3;
- lazy_hcall(LHCALL_NEW_PGTABLE, cr3, 0, 0);
+ lazy_hcall1(LHCALL_NEW_PGTABLE, cr3);
cr3_changed = true;
}
@@ -488,7 +507,7 @@ static void lguest_pte_update(struct mm_
static void lguest_pte_update(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- lazy_hcall(LHCALL_SET_PTE, __pa(mm->pgd), addr, ptep->pte_low);
+ lazy_hcall3(LHCALL_SET_PTE, __pa(mm->pgd), addr, ptep->pte_low);
}
static void lguest_set_pte_at(struct mm_struct *mm, unsigned long addr,
@@ -504,8 +523,8 @@ static void lguest_set_pmd(pmd_t *pmdp,
static void lguest_set_pmd(pmd_t *pmdp, pmd_t pmdval)
{
*pmdp = pmdval;
- lazy_hcall(LHCALL_SET_PMD, __pa(pmdp)&PAGE_MASK,
- (__pa(pmdp)&(PAGE_SIZE-1))/4, 0);
+ lazy_hcall2(LHCALL_SET_PMD, __pa(pmdp) & PAGE_MASK,
+ (__pa(pmdp) & (PAGE_SIZE - 1)) / 4);
}
/* There are a couple of legacy places where the kernel sets a PTE, but we
@@ -521,7 +540,7 @@ static void lguest_set_pte(pte_t *ptep,
{
*ptep = pteval;
if (cr3_changed)
- lazy_hcall(LHCALL_FLUSH_TLB, 1, 0, 0);
+ lazy_hcall1(LHCALL_FLUSH_TLB, 1);
}
/* Unfortunately for Lguest, the pv_mmu_ops for page tables were based on
@@ -537,7 +556,7 @@ static void lguest_flush_tlb_single(unsi
static void lguest_flush_tlb_single(unsigned long addr)
{
/* Simply set it to zero: if it was not, it will fault back in. */
- lazy_hcall(LHCALL_SET_PTE, lguest_data.pgdir, addr, 0);
+ lazy_hcall3(LHCALL_SET_PTE, lguest_data.pgdir, addr, 0);
}
/* This is what happens after the Guest has removed a large number of entries.
@@ -545,7 +564,7 @@ static void lguest_flush_tlb_single(unsi
* have changed, ie. virtual addresses below PAGE_OFFSET. */
static void lguest_flush_tlb_user(void)
{
- lazy_hcall(LHCALL_FLUSH_TLB, 0, 0, 0);
+ lazy_hcall1(LHCALL_FLUSH_TLB, 0);
}
/* This is called when the kernel page tables have changed. That's not very
@@ -553,14 +572,14 @@ static void lguest_flush_tlb_user(void)
* slow), so it's worth separating this from the user flushing above. */
static void lguest_flush_tlb_kernel(void)
{
- lazy_hcall(LHCALL_FLUSH_TLB, 1, 0, 0);
+ lazy_hcall1(LHCALL_FLUSH_TLB, 1);
}
/* This routine is called when a process exits, and we're throwing away the
* page table. */
static void lguest_pgd_free(struct mm_struct *mm, pgd_t *pgd)
{
- lazy_hcall(LHCALL_INVALIDATE_PGTABLE, __pa(pgd), 0, 0);
+ lazy_hcall1(LHCALL_INVALIDATE_PGTABLE, __pa(pgd));
}
/*
@@ -697,7 +716,7 @@ static int lguest_clockevent_set_next_ev
}
/* Please wake us this far in the future. */
- hcall(LHCALL_SET_CLOCKEVENT, delta, 0, 0);
+ kvm_hypercall1(LHCALL_SET_CLOCKEVENT, delta);
return 0;
}
@@ -708,7 +727,7 @@ static void lguest_clockevent_set_mode(e
case CLOCK_EVT_MODE_UNUSED:
case CLOCK_EVT_MODE_SHUTDOWN:
/* A 0 argument shuts the clock down. */
- hcall(LHCALL_SET_CLOCKEVENT, 0, 0, 0);
+ kvm_hypercall0(LHCALL_SET_CLOCKEVENT);
break;
case CLOCK_EVT_MODE_ONESHOT:
/* This is what we expect. */
@@ -783,8 +802,8 @@ static void lguest_load_sp0(struct tss_s
static void lguest_load_sp0(struct tss_struct *tss,
struct thread_struct *thread)
{
- lazy_hcall(LHCALL_SET_STACK, __KERNEL_DS|0x1, thread->sp0,
- THREAD_SIZE/PAGE_SIZE);
+ lazy_hcall3(LHCALL_SET_STACK, __KERNEL_DS | 0x1, thread->sp0,
+ THREAD_SIZE / PAGE_SIZE);
}
/* Let's just say, I wouldn't do debugging under a Guest. */
@@ -856,7 +875,7 @@ static struct apic_ops lguest_basic_apic
/* STOP! Until an interrupt comes in. */
static void lguest_safe_halt(void)
{
- hcall(LHCALL_HALT, 0, 0, 0);
+ kvm_hypercall0(LHCALL_HALT);
}
/* The SHUTDOWN hypercall takes a string to describe what's happening, and
@@ -866,7 +885,8 @@ static void lguest_safe_halt(void)
* rather than virtual addresses, so we use __pa() here. */
static void lguest_power_off(void)
{
- hcall(LHCALL_SHUTDOWN, __pa("Power down"), LGUEST_SHUTDOWN_POWEROFF, 0);
+ kvm_hypercall2(LHCALL_SHUTDOWN, __pa("Power down"),
+ LGUEST_SHUTDOWN_POWEROFF);
}
/*
@@ -876,7 +896,7 @@ static void lguest_power_off(void)
*/
static int lguest_panic(struct notifier_block *nb, unsigned long l, void *p)
{
- hcall(LHCALL_SHUTDOWN, __pa(p), LGUEST_SHUTDOWN_POWEROFF, 0);
+ kvm_hypercall2(LHCALL_SHUTDOWN, __pa(p), LGUEST_SHUTDOWN_POWEROFF);
/* The hcall won't return, but to keep gcc happy, we're "done". */
return NOTIFY_DONE;
}
@@ -917,7 +937,7 @@ static __init int early_put_chars(u32 vt
len = sizeof(scratch) - 1;
scratch[len] = '\0';
memcpy(scratch, buf, len);
- hcall(LHCALL_NOTIFY, __pa(scratch), 0, 0);
+ kvm_hypercall1(LHCALL_NOTIFY, __pa(scratch));
/* This routine returns the number of bytes actually written. */
return len;
@@ -927,7 +947,7 @@ static __init int early_put_chars(u32 vt
* Launcher to reboot us. */
static void lguest_restart(char *reason)
{
- hcall(LHCALL_SHUTDOWN, __pa(reason), LGUEST_SHUTDOWN_RESTART, 0);
+ kvm_hypercall2(LHCALL_SHUTDOWN, __pa(reason), LGUEST_SHUTDOWN_RESTART);
}
/*G:050
diff --git a/arch/x86/lguest/i386_head.S b/arch/x86/lguest/i386_head.S
--- a/arch/x86/lguest/i386_head.S
+++ b/arch/x86/lguest/i386_head.S
@@ -27,8 +27,8 @@ ENTRY(lguest_entry)
/* We make the "initialization" hypercall now to tell the Host about
* us, and also find out where it put our page tables. */
movl $LHCALL_LGUEST_INIT, %eax
- movl $lguest_data - __PAGE_OFFSET, %edx
- int $LGUEST_TRAP_ENTRY
+ movl $lguest_data - __PAGE_OFFSET, %ebx
+ .byte 0x0f,0x01,0xc1 /* KVM_HYPERCALL */
/* Set up the initial stack so we can run C code. */
movl $(init_thread_union+THREAD_SIZE),%esp
diff --git a/drivers/lguest/interrupts_and_traps.c b/drivers/lguest/interrupts_and_traps.c
--- a/drivers/lguest/interrupts_and_traps.c
+++ b/drivers/lguest/interrupts_and_traps.c
@@ -288,9 +288,10 @@ static int direct_trap(unsigned int num)
/* The Host needs to see page faults (for shadow paging and to save the
* fault address), general protection faults (in/out emulation) and
- * device not available (TS handling), and of course, the hypercall
- * trap. */
- return num != 14 && num != 13 && num != 7 && num != LGUEST_TRAP_ENTRY;
+ * device not available (TS handling), invalid opcode fault (kvm hcall),
+ * and of course, the hypercall trap. */
+ return num != 14 && num != 13 && num != 7 &&
+ num != 6 && num != LGUEST_TRAP_ENTRY;
}
/*:*/
diff --git a/drivers/lguest/lguest_device.c b/drivers/lguest/lguest_device.c
--- a/drivers/lguest/lguest_device.c
+++ b/drivers/lguest/lguest_device.c
@@ -161,7 +161,7 @@ static void set_status(struct virtio_dev
/* We set the status. */
to_lgdev(vdev)->desc->status = status;
- hcall(LHCALL_NOTIFY, (max_pfn<<PAGE_SHIFT) + offset, 0, 0);
+ kvm_hypercall1(LHCALL_NOTIFY, (max_pfn << PAGE_SHIFT) + offset);
}
static void lg_set_status(struct virtio_device *vdev, u8 status)
@@ -209,7 +209,7 @@ static void lg_notify(struct virtqueue *
* virtqueue structure. */
struct lguest_vq_info *lvq = vq->priv;
- hcall(LHCALL_NOTIFY, lvq->config.pfn << PAGE_SHIFT, 0, 0);
+ kvm_hypercall1(LHCALL_NOTIFY, lvq->config.pfn << PAGE_SHIFT);
}
/* An extern declaration inside a C file is bad form. Don't do it. */
diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
--- a/drivers/lguest/x86/core.c
+++ b/drivers/lguest/x86/core.c
@@ -290,6 +290,57 @@ static int emulate_insn(struct lg_cpu *c
return 1;
}
+/* Our hypercalls mechanism used to be based on direct software interrupts.
+ * After Anthony's "Refactor hypercall infrastructure" kvm patch, we decided to
+ * change over to using kvm hypercalls.
+ *
+ * KVM_HYPERCALL is actually a "vmcall" instruction, which generates an invalid
+ * opcode fault (fault 6) on non-VT cpus, so the easiest solution seemed to be
+ * an *emulation approach*: if the fault was really produced by an hypercall
+ * (is_hypercall() does exactly this check), we can just call the corresponding
+ * hypercall host implementation function.
+ *
+ * But these invalid opcode faults are notably slower than software interrupts.
+ * So we implemented the *patching (or rewriting) approach*: every time we hit
+ * the KVM_HYPERCALL opcode in Guest code, we patch it to the old "int 0x1f"
+ * opcode, so next time the Guest calls this hypercall it will use the
+ * faster trap mechanism.
+ *
+ * Matias even benchmarked it to convince you: this shows the average cycle
+ * cost of a hypercall. For each alternative solution mentioned above we've
+ * made 5 runs of the benchmark:
+ *
+ * 1) direct software interrupt: 2915, 2789, 2764, 2721, 2898
+ * 2) emulation technique: 3410, 3681, 3466, 3392, 3780
+ * 3) patching (rewrite) technique: 2977, 2975, 2891, 2637, 2884
+ *
+ * One two-line function is worth a 20% hypercall speed boost!
+ */
+static void rewrite_hypercall(struct lg_cpu *cpu)
+{
+ /* This are the opcodes we use to patch the Guest. The opcode for "int
+ * $0x1f" is "0xcd 0x1f" but vmcall instruction is 3 bytes long, so we
+ * complete the sequence with a NOP (0x90). */
+ u8 insn[3] = {0xcd, 0x1f, 0x90};
+
+ __lgwrite(cpu, guest_pa(cpu, cpu->regs->eip), insn, sizeof(insn));
+}
+
+static bool is_hypercall(struct lg_cpu *cpu)
+{
+ u8 insn[3];
+
+ /* This must be the Guest kernel trying to do something.
+ * The bottom two bits of the CS segment register are the privilege
+ * level. */
+ if ((cpu->regs->cs & 3) != GUEST_PL)
+ return false;
+
+ /* Is it a vmcall? */
+ __lgread(cpu, insn, guest_pa(cpu, cpu->regs->eip), sizeof(insn));
+ return insn[0] == 0x0f && insn[1] == 0x01 && insn[2] == 0xc1;
+}
+
/*H:050 Once we've re-enabled interrupts, we look at why the Guest exited. */
void lguest_arch_handle_trap(struct lg_cpu *cpu)
{
@@ -337,7 +388,7 @@ void lguest_arch_handle_trap(struct lg_c
break;
case 32 ... 255:
/* These values mean a real interrupt occurred, in which case
- * the Host handler has already been run. We just do a
+ * the Host handler has already been run. We just do a
* friendly check if another process should now be run, then
* return to run the Guest again */
cond_resched();
@@ -347,6 +398,15 @@ void lguest_arch_handle_trap(struct lg_c
* up the pointer now to indicate a hypercall is pending. */
cpu->hcall = (struct hcall_args *)cpu->regs;
return;
+ case 6:
+ /* kvm hypercalls trigger an invalid opcode fault (6).
+ * We need to check if ring == GUEST_PL and
+ * faulting instruction == vmcall. */
+ if (is_hypercall(cpu)) {
+ rewrite_hypercall(cpu);
+ return;
+ }
+ break;
}
/* We didn't handle the trap, so it needs to go to the Guest. */
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls
2009-03-26 23:52 [PATCH 4/5] lguest: use KVM hypercalls Rusty Russell
@ 2009-04-02 21:55 ` Simon Holm Thøgersen
[not found] ` <1238709324.5823.8.camel-78RDdhuQolGs1BDpvl8NfQ@public.gmane.org>
[not found] ` <1239043798.27826.93.camel@zetabook>
0 siblings, 2 replies; 46+ messages in thread
From: Simon Holm Thøgersen @ 2009-04-02 21:55 UTC (permalink / raw)
To: Rusty Russell
Cc: virtualization, lguest, Ingo Molnar, linux-kernel,
Matias Zabaljauregui
fre, 27 03 2009 kl. 10:22 +1030, skrev Rusty Russell:
> From: Matias Zabaljauregui <zabaljauregui@gmail.com>
>
> Impact: cleanup
>
> This patch allow us to use KVM hypercalls
Something has broken in relation to this change. I'm not sure it is this
change itself or one following, but I get the following error when using
lguest:
lguest: unhandled trap 6 at 0x418726 (0x0)
> +static bool is_hypercall(struct lg_cpu *cpu)
> +{
> + u8 insn[3];
> +
> + /* This must be the Guest kernel trying to do something.
> + * The bottom two bits of the CS segment register are the privilege
> + * level. */
> + if ((cpu->regs->cs & 3) != GUEST_PL)
> + return false;
> +
> + /* Is it a vmcall? */
> + __lgread(cpu, insn, guest_pa(cpu, cpu->regs->eip), sizeof(insn));
I've put a printk for insn here that shows up twice. The first time insn
holds the values below, and the second time it holds the values that are
patched in by rewrite_hypercall.
> + return insn[0] == 0x0f && insn[1] == 0x01 && insn[2] == 0xc1;
> +}
I'll investigate further tomorrow, unless someone is already on top of
this. My kernel is 2.6.29-07100-g833bb30 btw.
Simon Holm Thøgersen
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/virtualization
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <1238709324.5823.8.camel-78RDdhuQolGs1BDpvl8NfQ@public.gmane.org>
@ 2009-04-02 23:37 ` Matias Zabaljauregui
2009-04-03 9:28 ` Simon Holm Thøgersen
2009-04-05 13:04 ` Rusty Russell
1 sibling, 1 reply; 46+ messages in thread
From: Matias Zabaljauregui @ 2009-04-02 23:37 UTC (permalink / raw)
To: Simon Holm Thøgersen
Cc: lguest-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matias Zabaljauregui,
virtualization-qjLDD68F18O7TbgM5vRIOg, Ingo Molnar
On Thu, 2009-04-02 at 23:55 +0200, Simon Holm Thøgersen wrote:
> fre, 27 03 2009 kl. 10:22 +1030, skrev Rusty Russell:
> > From: Matias Zabaljauregui <zabaljauregui@gmail.com>
> >
> > Impact: cleanup
> >
> > This patch allow us to use KVM hypercalls
>
> Something has broken in relation to this change. I'm not sure it is this
> change itself or one following, but I get the following error when using
> lguest:
>
> lguest: unhandled trap 6 at 0x418726 (0x0)
Hi, could you please attach your config?
are you using the same kernel for guest and host?
I just tested it with 2.6.29-07100-g833bb30 and works OK for me.
thanks
Matias
_______________________________________________
Lguest mailing list
Lguest@ozlabs.org
https://ozlabs.org/mailman/listinfo/lguest
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
2009-04-02 23:37 ` Matias Zabaljauregui
@ 2009-04-03 9:28 ` Simon Holm Thøgersen
0 siblings, 0 replies; 46+ messages in thread
From: Simon Holm Thøgersen @ 2009-04-03 9:28 UTC (permalink / raw)
To: Matias Zabaljauregui
Cc: lguest-mnsaURCQ41sdnm+yROfE0A,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Matias Zabaljauregui,
virtualization-qjLDD68F18O7TbgM5vRIOg, Ingo Molnar
[-- Attachment #1: Type: text/plain, Size: 887 bytes --]
tor, 02 04 2009 kl. 20:37 -0300, skrev Matias Zabaljauregui:
> On Thu, 2009-04-02 at 23:55 +0200, Simon Holm Thøgersen wrote:
> > fre, 27 03 2009 kl. 10:22 +1030, skrev Rusty Russell:
> > > From: Matias Zabaljauregui <zabaljauregui-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > >
> > > Impact: cleanup
> > >
> > > This patch allow us to use KVM hypercalls
> >
> > Something has broken in relation to this change. I'm not sure it is this
> > change itself or one following, but I get the following error when using
> > lguest:
> >
> > lguest: unhandled trap 6 at 0x418726 (0x0)
>
>
> Hi, could you please attach your config?
Sure, here's the one I used for commit 4cd8b5e, which I just tested with
the same result.
> are you using the same kernel for guest and host?
Yes.
> I just tested it with 2.6.29-07100-g833bb30 and works OK for me.
Simon
[-- Attachment #2: lguest-bug.config --]
[-- Type: application/x-config, Size: 55979 bytes --]
[-- Attachment #3: Type: text/plain, Size: 158 bytes --]
_______________________________________________
Lguest mailing list
Lguest-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/lguest
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <1238709324.5823.8.camel-78RDdhuQolGs1BDpvl8NfQ@public.gmane.org>
2009-04-02 23:37 ` Matias Zabaljauregui
@ 2009-04-05 13:04 ` Rusty Russell
[not found] ` <200904052234.48483.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
1 sibling, 1 reply; 46+ messages in thread
From: Rusty Russell @ 2009-04-05 13:04 UTC (permalink / raw)
To: Simon Holm Thøgersen
Cc: virtualization-qjLDD68F18O7TbgM5vRIOg,
lguest-mnsaURCQ41sdnm+yROfE0A, Ingo Molnar, Matias Zabaljauregui,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
On Friday 03 April 2009 08:25:24 Simon Holm Thøgersen wrote:
> fre, 27 03 2009 kl. 10:22 +1030, skrev Rusty Russell:
> > From: Matias Zabaljauregui <zabaljauregui@gmail.com>
> >
> > Impact: cleanup
> >
> > This patch allow us to use KVM hypercalls
>
> Something has broken in relation to this change. I'm not sure it is this
> change itself or one following, but I get the following error when using
> lguest:
>
> lguest: unhandled trap 6 at 0x418726 (0x0)
Any chance you didn't rebuild the Launcher?
Rusty.
_______________________________________________
Lguest mailing list
Lguest@ozlabs.org
https://ozlabs.org/mailman/listinfo/lguest
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <200904052234.48483.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
@ 2009-04-06 6:56 ` Simon Holm Thøgersen
2009-04-08 16:24 ` [Lguest] " Patrick McHardy
0 siblings, 1 reply; 46+ messages in thread
From: Simon Holm Thøgersen @ 2009-04-06 6:56 UTC (permalink / raw)
To: Rusty Russell
Cc: virtualization-qjLDD68F18O7TbgM5vRIOg,
lguest-mnsaURCQ41sdnm+yROfE0A, Ingo Molnar, Matias Zabaljauregui,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
søn, 05 04 2009 kl. 22:34 +0930, skrev Rusty Russell:
> On Friday 03 April 2009 08:25:24 Simon Holm Thøgersen wrote:
> > fre, 27 03 2009 kl. 10:22 +1030, skrev Rusty Russell:
> > > From: Matias Zabaljauregui <zabaljauregui@gmail.com>
> > >
> > > Impact: cleanup
> > >
> > > This patch allow us to use KVM hypercalls
> >
> > Something has broken in relation to this change. I'm not sure it is this
> > change itself or one following, but I get the following error when using
> > lguest:
> >
> > lguest: unhandled trap 6 at 0x418726 (0x0)
>
> Any chance you didn't rebuild the Launcher?
Nope, I've double and triple checked that. I still kind of expect
something weird at my end though, so I'd be interested to know the
result of others using my config.
Simon
_______________________________________________
Lguest mailing list
Lguest@ozlabs.org
https://ozlabs.org/mailman/listinfo/lguest
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls
2009-04-06 6:56 ` Simon Holm Thøgersen
@ 2009-04-08 16:24 ` Patrick McHardy
0 siblings, 0 replies; 46+ messages in thread
From: Patrick McHardy @ 2009-04-08 16:24 UTC (permalink / raw)
To: odie
Cc: Rusty Russell, lguest, virtualization, Ingo Molnar,
Linux Kernel Mailinglist, Matias Zabaljauregui
[-- Attachment #1: Type: text/plain, Size: 1055 bytes --]
Simon Holm Th������������������������ wrote:
> søn, 05 04 2009 kl. 22:34 +0930, skrev Rusty Russell:
>> On Friday 03 April 2009 08:25:24 Simon Holm Thøgersen wrote:
>>> fre, 27 03 2009 kl. 10:22 +1030, skrev Rusty Russell:
>>>> From: Matias Zabaljauregui <zabaljauregui@gmail.com>
>>>>
>>>> Impact: cleanup
>>>>
>>>> This patch allow us to use KVM hypercalls
>>> Something has broken in relation to this change. I'm not sure it is this
>>> change itself or one following, but I get the following error when using
>>> lguest:
>>>
>>> lguest: unhandled trap 6 at 0x418726 (0x0)
>> Any chance you didn't rebuild the Launcher?
>
> Nope, I've double and triple checked that. I still kind of expect
> something weird at my end though, so I'd be interested to know the
> result of others using my config.
I'm seeing the same problem with the attached config. IIRC it was even
the exact same (invalid) address, unfortunately I can't retest right
now since the system is in use. The launcher has been rebuilt.
[-- Attachment #2: config --]
[-- Type: text/plain, Size: 56815 bytes --]
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.29
# Mon Apr 6 13:48:09 2009
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_FAST_CMPXCHG_LOCAL=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_DEFAULT_IDLE=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_HAVE_DYNAMIC_PER_CPU_AREA=y
# CONFIG_HAVE_CPUMASK_OF_CPU_MAP is not set
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set
CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
#
# RCU Subsystem
#
CONFIG_CLASSIC_RCU=y
# CONFIG_TREE_RCU is not set
# CONFIG_PREEMPT_RCU is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_PREEMPT_RCU_TRACE is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
# CONFIG_GROUP_SCHED is not set
# CONFIG_CGROUPS is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
CONFIG_NAMESPACES=y
# CONFIG_UTS_NS is not set
# CONFIG_IPC_NS is not set
# CONFIG_USER_NS is not set
# CONFIG_PID_NS is not set
# CONFIG_NET_NS is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_PCI_QUIRKS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
# CONFIG_MARKERS is not set
CONFIG_OPROFILE=m
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_API_DEBUG=y
# CONFIG_SLOW_WORK is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=m
CONFIG_IOSCHED_DEADLINE=m
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
# CONFIG_FREEZER is not set
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
# CONFIG_SMP is not set
# CONFIG_SPARSE_IRQ is not set
CONFIG_X86_MPPARSE=y
# CONFIG_X86_EXTENDED_PLATFORM is not set
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_PARAVIRT_GUEST=y
# CONFIG_VMI is not set
# CONFIG_KVM_CLOCK is not set
# CONFIG_KVM_GUEST is not set
CONFIG_LGUEST_GUEST=y
CONFIG_PARAVIRT=y
# CONFIG_PARAVIRT_CLOCK is not set
# CONFIG_PARAVIRT_DEBUG is not set
# CONFIG_MEMTEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
CONFIG_MPENTIUM4=y
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CPU=y
CONFIG_X86_L1_CACHE_BYTES=64
CONFIG_X86_INTERNODE_CACHE_BYTES=64
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=7
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_CYRIX_32=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_CPU_SUP_TRANSMETA_32=y
CONFIG_CPU_SUP_UMC_32=y
CONFIG_X86_DS=y
CONFIG_X86_PTRACE_BTS=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
# CONFIG_IOMMU_HELPER is not set
# CONFIG_IOMMU_API is not set
CONFIG_NR_CPUS=1
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS is not set
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
# CONFIG_X86_CPU_DEBUG is not set
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_UNEVICTABLE_LRU=y
CONFIG_HAVE_MLOCK=y
CONFIG_HAVE_MLOCKED_PAGE_BIT=y
# CONFIG_HIGHPTE is not set
# CONFIG_X86_CHECK_BIOS_CORRUPTION is not set
CONFIG_X86_RESERVE_LOW_64K=y
# CONFIG_MATH_EMULATION is not set
# CONFIG_MTRR is not set
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
CONFIG_CC_STACKPROTECTOR_ALL=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
CONFIG_PHYSICAL_START=0x100000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x100000
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management and ACPI options
#
CONFIG_PM=y
# CONFIG_PM_DEBUG is not set
# CONFIG_SUSPEND is not set
# CONFIG_HIBERNATION is not set
CONFIG_ACPI=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
# CONFIG_ACPI_AC is not set
# CONFIG_ACPI_BATTERY is not set
# CONFIG_ACPI_BUTTON is not set
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_PCI_SLOT=m
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
CONFIG_CPU_FREQ_STAT_DETAILS=y
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=m
CONFIG_CPU_FREQ_GOV_USERSPACE=m
CONFIG_CPU_FREQ_GOV_ONDEMAND=m
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
#
# CPUFreq processor drivers
#
CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=m
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
CONFIG_X86_P4_CLOCKMOD=m
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set
#
# shared options
#
CONFIG_X86_SPEEDSTEP_LIB=m
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
# CONFIG_PCI_GOOLPC is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not set
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
# CONFIG_PCI_IOV is not set
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_OLPC is not set
# CONFIG_PCCARD is not set
# CONFIG_HOTPLUG_PCI is not set
#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_HAVE_AOUT=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
CONFIG_HAVE_ATOMIC_IOMAP=y
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=m
CONFIG_XFRM=y
CONFIG_XFRM_USER=m
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
# CONFIG_XFRM_STATISTICS is not set
CONFIG_XFRM_IPCOMP=m
CONFIG_NET_KEY=m
CONFIG_NET_KEY_MIGRATE=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_ASK_IP_FIB_HASH is not set
CONFIG_IP_FIB_TRIE=y
# CONFIG_IP_FIB_HASH is not set
# CONFIG_IP_FIB_TRIE_STATS is not set
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
CONFIG_IP_MROUTE=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_ARPD=y
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=m
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=m
CONFIG_TCP_CONG_CUBIC=m
CONFIG_TCP_CONG_WESTWOOD=m
CONFIG_TCP_CONG_HTCP=m
CONFIG_TCP_CONG_HSTCP=m
CONFIG_TCP_CONG_HYBLA=m
CONFIG_TCP_CONG_VEGAS=y
CONFIG_TCP_CONG_SCALABLE=m
CONFIG_TCP_CONG_LP=m
CONFIG_TCP_CONG_VENO=m
CONFIG_TCP_CONG_YEAH=m
CONFIG_TCP_CONG_ILLINOIS=m
# CONFIG_DEFAULT_BIC is not set
# CONFIG_DEFAULT_CUBIC is not set
# CONFIG_DEFAULT_HTCP is not set
CONFIG_DEFAULT_VEGAS=y
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="vegas"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
CONFIG_IPV6_PRIVACY=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
CONFIG_INET6_AH=m
CONFIG_INET6_ESP=m
CONFIG_INET6_IPCOMP=m
CONFIG_IPV6_MIP6=y
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=m
CONFIG_INET6_XFRM_MODE_TUNNEL=m
CONFIG_INET6_XFRM_MODE_BEET=m
CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=y
CONFIG_IPV6_SIT=m
CONFIG_IPV6_NDISC_NODETYPE=y
CONFIG_IPV6_TUNNEL=m
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=y
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
CONFIG_NF_CONNTRACK=m
CONFIG_NF_CT_ACCT=y
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NF_CONNTRACK_EVENTS=y
CONFIG_NF_CT_PROTO_DCCP=m
CONFIG_NF_CT_PROTO_GRE=m
CONFIG_NF_CT_PROTO_SCTP=m
CONFIG_NF_CT_PROTO_UDPLITE=m
CONFIG_NF_CONNTRACK_AMANDA=m
CONFIG_NF_CONNTRACK_FTP=m
CONFIG_NF_CONNTRACK_H323=m
CONFIG_NF_CONNTRACK_IRC=m
CONFIG_NF_CONNTRACK_NETBIOS_NS=m
CONFIG_NF_CONNTRACK_PPTP=m
CONFIG_NF_CONNTRACK_SANE=m
CONFIG_NF_CONNTRACK_SIP=m
CONFIG_NF_CONNTRACK_TFTP=m
CONFIG_NF_CT_NETLINK=m
CONFIG_NETFILTER_TPROXY=m
CONFIG_NETFILTER_XTABLES=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
CONFIG_NETFILTER_XT_MATCH_CLUSTER=m
CONFIG_NETFILTER_XT_MATCH_COMMENT=m
CONFIG_NETFILTER_XT_MATCH_CONNBYTES=m
CONFIG_NETFILTER_XT_MATCH_CONNLIMIT=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=m
CONFIG_NETFILTER_XT_MATCH_DCCP=m
CONFIG_NETFILTER_XT_MATCH_DSCP=m
CONFIG_NETFILTER_XT_MATCH_ESP=m
CONFIG_NETFILTER_XT_MATCH_HASHLIMIT=m
CONFIG_NETFILTER_XT_MATCH_HELPER=m
CONFIG_NETFILTER_XT_MATCH_HL=m
CONFIG_NETFILTER_XT_MATCH_IPRANGE=m
CONFIG_NETFILTER_XT_MATCH_LENGTH=m
CONFIG_NETFILTER_XT_MATCH_LIMIT=m
CONFIG_NETFILTER_XT_MATCH_MAC=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m
CONFIG_NETFILTER_XT_MATCH_OWNER=m
CONFIG_NETFILTER_XT_MATCH_POLICY=m
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=m
CONFIG_NETFILTER_XT_MATCH_QUOTA=m
CONFIG_NETFILTER_XT_MATCH_RATEEST=m
CONFIG_NETFILTER_XT_MATCH_REALM=m
CONFIG_NETFILTER_XT_MATCH_RECENT=m
# CONFIG_NETFILTER_XT_MATCH_RECENT_PROC_COMPAT is not set
CONFIG_NETFILTER_XT_MATCH_SCTP=m
CONFIG_NETFILTER_XT_MATCH_SOCKET=m
CONFIG_NETFILTER_XT_MATCH_STATE=m
CONFIG_NETFILTER_XT_MATCH_STATISTIC=m
CONFIG_NETFILTER_XT_MATCH_STRING=m
CONFIG_NETFILTER_XT_MATCH_TCPMSS=m
CONFIG_NETFILTER_XT_MATCH_TIME=m
CONFIG_NETFILTER_XT_MATCH_U32=m
# CONFIG_IP_VS is not set
#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=m
CONFIG_NF_CONNTRACK_IPV4=m
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_QUEUE=m
CONFIG_IP_NF_IPTABLES=m
CONFIG_IP_NF_MATCH_ADDRTYPE=m
CONFIG_IP_NF_MATCH_AH=m
CONFIG_IP_NF_MATCH_ECN=m
CONFIG_IP_NF_MATCH_TTL=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_TARGET_REJECT=m
CONFIG_IP_NF_TARGET_LOG=m
CONFIG_IP_NF_TARGET_ULOG=m
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=m
CONFIG_IP_NF_TARGET_NETMAP=m
CONFIG_IP_NF_TARGET_REDIRECT=m
CONFIG_NF_NAT_SNMP_BASIC=m
CONFIG_NF_NAT_PROTO_DCCP=m
CONFIG_NF_NAT_PROTO_GRE=m
CONFIG_NF_NAT_PROTO_UDPLITE=m
CONFIG_NF_NAT_PROTO_SCTP=m
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_TFTP=m
CONFIG_NF_NAT_AMANDA=m
CONFIG_NF_NAT_PPTP=m
CONFIG_NF_NAT_H323=m
CONFIG_NF_NAT_SIP=m
CONFIG_IP_NF_MANGLE=m
CONFIG_IP_NF_TARGET_CLUSTERIP=m
CONFIG_IP_NF_TARGET_ECN=m
CONFIG_IP_NF_TARGET_TTL=m
CONFIG_IP_NF_RAW=m
CONFIG_IP_NF_ARPTABLES=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP_NF_ARP_MANGLE=m
#
# IPv6: Netfilter Configuration
#
CONFIG_NF_CONNTRACK_IPV6=m
CONFIG_IP6_NF_QUEUE=m
CONFIG_IP6_NF_IPTABLES=m
CONFIG_IP6_NF_MATCH_AH=m
CONFIG_IP6_NF_MATCH_EUI64=m
CONFIG_IP6_NF_MATCH_FRAG=m
CONFIG_IP6_NF_MATCH_OPTS=m
CONFIG_IP6_NF_MATCH_HL=m
CONFIG_IP6_NF_MATCH_IPV6HEADER=m
CONFIG_IP6_NF_MATCH_MH=m
CONFIG_IP6_NF_MATCH_RT=m
CONFIG_IP6_NF_TARGET_HL=m
CONFIG_IP6_NF_TARGET_LOG=m
CONFIG_IP6_NF_FILTER=m
CONFIG_IP6_NF_TARGET_REJECT=m
CONFIG_IP6_NF_MANGLE=m
CONFIG_IP6_NF_RAW=m
CONFIG_BRIDGE_NF_EBTABLES=m
CONFIG_BRIDGE_EBT_BROUTE=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_BRIDGE_EBT_T_NAT=m
CONFIG_BRIDGE_EBT_802_3=m
CONFIG_BRIDGE_EBT_AMONG=m
CONFIG_BRIDGE_EBT_ARP=m
CONFIG_BRIDGE_EBT_IP=m
CONFIG_BRIDGE_EBT_IP6=m
CONFIG_BRIDGE_EBT_LIMIT=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_PKTTYPE=m
CONFIG_BRIDGE_EBT_STP=m
CONFIG_BRIDGE_EBT_VLAN=m
CONFIG_BRIDGE_EBT_ARPREPLY=m
CONFIG_BRIDGE_EBT_DNAT=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_BRIDGE_EBT_REDIRECT=m
CONFIG_BRIDGE_EBT_SNAT=m
CONFIG_BRIDGE_EBT_LOG=m
CONFIG_BRIDGE_EBT_ULOG=m
CONFIG_BRIDGE_EBT_NFLOG=m
CONFIG_IP_DCCP=m
CONFIG_INET_DCCP_DIAG=m
#
# DCCP CCIDs Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP_CCID2_DEBUG is not set
CONFIG_IP_DCCP_CCID3=y
# CONFIG_IP_DCCP_CCID3_DEBUG is not set
CONFIG_IP_DCCP_CCID3_RTO=100
CONFIG_IP_DCCP_TFRC_LIB=y
#
# DCCP Kernel Hacking
#
# CONFIG_IP_DCCP_DEBUG is not set
# CONFIG_NET_DCCPPROBE is not set
CONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
CONFIG_SCTP_HMAC_SHA1=y
# CONFIG_SCTP_HMAC_MD5 is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_STP=m
CONFIG_GARP=m
CONFIG_BRIDGE=m
# CONFIG_NET_DSA is not set
CONFIG_VLAN_8021Q=m
CONFIG_VLAN_8021Q_GVRP=y
# CONFIG_DECNET is not set
CONFIG_LLC=m
CONFIG_LLC2=m
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_PHONET is not set
CONFIG_NET_SCHED=y
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=m
CONFIG_NET_SCH_HTB=m
CONFIG_NET_SCH_HFSC=m
CONFIG_NET_SCH_PRIO=m
CONFIG_NET_SCH_MULTIQ=m
CONFIG_NET_SCH_RED=m
CONFIG_NET_SCH_SFQ=m
CONFIG_NET_SCH_TEQL=m
CONFIG_NET_SCH_TBF=m
CONFIG_NET_SCH_GRED=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_NET_SCH_NETEM=m
CONFIG_NET_SCH_DRR=m
CONFIG_NET_SCH_INGRESS=m
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=m
CONFIG_NET_CLS_TCINDEX=m
CONFIG_NET_CLS_ROUTE4=m
CONFIG_NET_CLS_ROUTE=y
CONFIG_NET_CLS_FW=m
CONFIG_NET_CLS_U32=m
CONFIG_CLS_U32_PERF=y
CONFIG_CLS_U32_MARK=y
CONFIG_NET_CLS_RSVP=m
CONFIG_NET_CLS_RSVP6=m
CONFIG_NET_CLS_FLOW=m
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
CONFIG_NET_EMATCH_CMP=m
CONFIG_NET_EMATCH_NBYTE=m
CONFIG_NET_EMATCH_U32=m
CONFIG_NET_EMATCH_META=m
CONFIG_NET_EMATCH_TEXT=m
CONFIG_NET_CLS_ACT=y
CONFIG_NET_ACT_POLICE=m
CONFIG_NET_ACT_GACT=m
CONFIG_GACT_PROB=y
CONFIG_NET_ACT_MIRRED=m
CONFIG_NET_ACT_IPT=m
CONFIG_NET_ACT_NAT=m
CONFIG_NET_ACT_PEDIT=m
CONFIG_NET_ACT_SIMP=m
CONFIG_NET_ACT_SKBEDIT=m
CONFIG_NET_CLS_IND=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
#
# Network testing
#
CONFIG_NET_PKTGEN=m
# CONFIG_NET_TCPPROBE is not set
CONFIG_NET_DROP_MONITOR=y
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_CFG80211=m
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_WIRELESS_OLD_REGULATORY=y
CONFIG_WIRELESS_EXT=y
CONFIG_WIRELESS_EXT_SYSFS=y
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=m
#
# Rate control algorithm selection
#
CONFIG_MAC80211_RC_MINSTREL=y
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_LEDS=y
CONFIG_MAC80211_DEBUGFS=y
CONFIG_MAC80211_DEBUG_MENU=y
CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT=y
# CONFIG_MAC80211_NOINLINE is not set
CONFIG_MAC80211_VERBOSE_DEBUG=y
CONFIG_MAC80211_HT_DEBUG=y
CONFIG_MAC80211_TKIP_DEBUG=y
CONFIG_MAC80211_IBSS_DEBUG=y
CONFIG_MAC80211_VERBOSE_PS_DEBUG=y
CONFIG_MAC80211_DEBUG_COUNTERS=y
CONFIG_MAC80211_VERBOSE_SPECT_MGMT_DEBUG=y
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
CONFIG_PARPORT_1284=y
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_BLK_DEV_NBD=m
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=m
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=8192
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_VIRTIO_BLK=y
# CONFIG_BLK_DEV_HD is not set
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_ISL29003 is not set
# CONFIG_C2PORT is not set
#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_93CX6 is not set
CONFIG_HAVE_IDE=y
CONFIG_IDE=m
#
# Please see Documentation/ide/ide.txt for help/info on IDE drives
#
CONFIG_IDE_XFER_MODE=y
CONFIG_IDE_ATAPI=y
# CONFIG_BLK_DEV_IDE_SATA is not set
CONFIG_IDE_GD=m
CONFIG_IDE_GD_ATA=y
# CONFIG_IDE_GD_ATAPI is not set
CONFIG_BLK_DEV_IDECD=m
CONFIG_BLK_DEV_IDECD_VERBOSE_ERRORS=y
# CONFIG_BLK_DEV_IDETAPE is not set
CONFIG_BLK_DEV_IDEACPI=y
# CONFIG_IDE_TASK_IOCTL is not set
CONFIG_IDE_PROC_FS=y
#
# IDE chipset support/bugfixes
#
# CONFIG_IDE_GENERIC is not set
# CONFIG_BLK_DEV_PLATFORM is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_IDEPNP is not set
CONFIG_BLK_DEV_IDEDMA_SFF=y
#
# PCI IDE chipsets support
#
CONFIG_BLK_DEV_IDEPCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_BLK_DEV_GENERIC=m
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_RZ1000 is not set
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD74XX is not set
# CONFIG_BLK_DEV_ATIIXP is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_TRIFLEX is not set
# CONFIG_BLK_DEV_CS5520 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_CS5535 is not set
# CONFIG_BLK_DEV_CS5536 is not set
# CONFIG_BLK_DEV_HPT366 is not set
# CONFIG_BLK_DEV_JMICRON is not set
# CONFIG_BLK_DEV_SC1200 is not set
# CONFIG_BLK_DEV_PIIX is not set
# CONFIG_BLK_DEV_IT8172 is not set
# CONFIG_BLK_DEV_IT8213 is not set
# CONFIG_BLK_DEV_IT821X is not set
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_PDC202XX_OLD is not set
# CONFIG_BLK_DEV_PDC202XX_NEW is not set
# CONFIG_BLK_DEV_SVWKS is not set
# CONFIG_BLK_DEV_SIIMAGE is not set
CONFIG_BLK_DEV_SIS5513=m
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_BLK_DEV_TC86C001 is not set
CONFIG_BLK_DEV_IDEDMA=y
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
CONFIG_SCSI_NETLINK=y
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
# CONFIG_SCSI_SCAN_ASYNC is not set
CONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
CONFIG_SCSI_FC_ATTRS=y
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_LIBFC is not set
# CONFIG_FCOE is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_PMP is not set
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y
# CONFIG_SATA_SVW is not set
# CONFIG_ATA_PIIX is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
CONFIG_SATA_PROMISE=m
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
CONFIG_SATA_SIS=y
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
CONFIG_ATA_GENERIC=m
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
CONFIG_PATA_SIS=y
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_SCH is not set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
#
# Enable only one of the two stacks, unless you know what you are doing
#
# CONFIG_FIREWIRE is not set
# CONFIG_IEEE1394 is not set
CONFIG_I2O=m
CONFIG_I2O_LCT_NOTIFY_ON_CHANGES=y
CONFIG_I2O_EXT_ADAPTEC=y
CONFIG_I2O_CONFIG=m
CONFIG_I2O_CONFIG_OLD_IOCTL=y
CONFIG_I2O_BUS=m
CONFIG_I2O_BLOCK=m
CONFIG_I2O_SCSI=m
CONFIG_I2O_PROC=m
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
CONFIG_COMPAT_NET_DEV_OPS=y
CONFIG_IFB=m
CONFIG_DUMMY=m
CONFIG_BONDING=m
CONFIG_MACVLAN=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
CONFIG_VETH=m
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_ETHOC is not set
# CONFIG_DNET is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_IBM_NEW_EMAC_NO_FLOW_CTRL is not set
# CONFIG_IBM_NEW_EMAC_MAL_CLR_ICINTSTAT is not set
# CONFIG_IBM_NEW_EMAC_MAL_COMMON_ERR is not set
CONFIG_NET_PCI=y
# CONFIG_PCNET32 is not set
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_E100 is not set
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_R6040 is not set
CONFIG_SIS900=y
# CONFIG_EPIC100 is not set
# CONFIG_SMSC9420 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not set
# CONFIG_ATL2 is not set
CONFIG_NETDEV_1000=y
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
CONFIG_E1000=m
# CONFIG_E1000E is not set
# CONFIG_IP1000 is not set
# CONFIG_IGB is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_R8169=y
CONFIG_R8169_VLAN=y
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_VIA_VELOCITY is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_JME is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not set
CONFIG_WLAN_80211=y
# CONFIG_LIBERTAS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_MWL8K is not set
CONFIG_P54_COMMON=m
# CONFIG_P54_USB is not set
CONFIG_P54_PCI=m
CONFIG_P54_LEDS=y
CONFIG_ATH5K=m
CONFIG_ATH5K_DEBUG=y
# CONFIG_ATH9K is not set
# CONFIG_AR9170_USB is not set
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_IWLWIFI is not set
# CONFIG_HOSTAP is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_ZD1211RW is not set
# CONFIG_RT2X00 is not set
# CONFIG_HERMES is not set
#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=m
CONFIG_PPP_SYNC_TTY=m
CONFIG_PPP_DEFLATE=m
CONFIG_PPP_BSDCOMP=m
CONFIG_PPP_MPPE=m
CONFIG_PPPOE=m
CONFIG_PPPOL2TP=m
# CONFIG_SLIP is not set
CONFIG_SLHC=m
CONFIG_NET_FC=y
CONFIG_NETCONSOLE=y
CONFIG_NETCONSOLE_DYNAMIC=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
CONFIG_VIRTIO_NET=y
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=m
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_INPUT_MOUSE is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
# CONFIG_INPUT_MISC is not set
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
CONFIG_SERIO_PCIPS2=y
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_DEVKMEM is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_PRINTER is not set
# CONFIG_PPDEV is not set
CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=m
CONFIG_HW_RANDOM_TIMERIOMEM=m
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_GEODE is not set
# CONFIG_HW_RANDOM_VIA is not set
CONFIG_HW_RANDOM_VIRTIO=m
CONFIG_NVRAM=m
CONFIG_RTC=m
# CONFIG_GEN_RTC is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_HPET is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_CHARDEV=m
CONFIG_I2C_HELPER_AUTO=y
#
# I2C Hardware Bus support
#
#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
CONFIG_I2C_SIS5595=m
CONFIG_I2C_SIS630=m
CONFIG_I2C_SIS96X=m
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_SIMTEC is not set
#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set
#
# Graphics adapter I2C/DDC channel drivers
#
# CONFIG_I2C_VOODOO3 is not set
#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_STUB is not set
# CONFIG_SCx200_ACB is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
# CONFIG_SPI is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_BATTERY_BQ27x00 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7473 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
CONFIG_SENSORS_SIS5595=m
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_HWMON_DEBUG_CHIP is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_HWMON is not set
# CONFIG_WATCHDOG is not set
CONFIG_SSB_POSSIBLE=y
#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_REGULATOR is not set
#
# Multimedia devices
#
#
# Multimedia core support
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_VIDEO_MEDIA is not set
#
# Multimedia drivers
#
# CONFIG_DAB is not set
#
# Graphics support
#
# CONFIG_AGP is not set
# CONFIG_DRM is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=m
# CONFIG_FB is not set
# CONFIG_BACKLIGHT_LCD_SUPPORT is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VGACON_SOFT_SCROLLBACK is not set
CONFIG_DUMMY_CONSOLE=y
# CONFIG_SOUND is not set
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_HID_PID is not set
# CONFIG_USB_HIDDEV is not set
#
# Special HID drivers
#
CONFIG_HID_A4TECH=m
CONFIG_HID_APPLE=m
CONFIG_HID_BELKIN=m
CONFIG_HID_CHERRY=m
CONFIG_HID_CHICONY=m
CONFIG_HID_CYPRESS=m
# CONFIG_DRAGONRISE_FF is not set
CONFIG_HID_EZKEY=m
CONFIG_HID_KYE=m
CONFIG_HID_GYRATION=m
CONFIG_HID_KENSINGTON=m
CONFIG_HID_LOGITECH=m
# CONFIG_LOGITECH_FF is not set
# CONFIG_LOGIRUMBLEPAD2_FF is not set
CONFIG_HID_MICROSOFT=m
CONFIG_HID_MONTEREY=m
CONFIG_HID_NTRIG=m
CONFIG_HID_PANTHERLORD=m
# CONFIG_PANTHERLORD_FF is not set
CONFIG_HID_PETALYNX=m
CONFIG_HID_SAMSUNG=m
CONFIG_HID_SONY=m
CONFIG_HID_SUNPLUS=m
# CONFIG_GREENASIA_FF is not set
CONFIG_HID_TOPSEED=m
# CONFIG_THRUSTMASTER_FF is not set
# CONFIG_ZEROPLUS_FF is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
# CONFIG_USB_OTG is not set
CONFIG_USB_MON=m
# CONFIG_USB_WUSB is not set
# CONFIG_USB_WUSB_CBAF is not set
#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
CONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_WHCI_HCD is not set
# CONFIG_USB_HWA_HCD is not set
#
# Enable Host or Gadget support to see Inventra options
#
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=m
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set
#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#
#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
# CONFIG_USB_SERIAL is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_VST is not set
# CONFIG_USB_GADGET is not set
#
# OTG and related infrastructure
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=m
#
# LED drivers
#
# CONFIG_LEDS_ALIX2 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_IDE_DISK is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set
#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y
#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=y
# CONFIG_EDAC_AMD76X is not set
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
# CONFIG_EDAC_X38 is not set
# CONFIG_EDAC_I5400 is not set
# CONFIG_EDAC_I82860 is not set
# CONFIG_EDAC_R82600 is not set
# CONFIG_EDAC_I5000 is not set
# CONFIG_EDAC_I5100 is not set
# CONFIG_EDAC_AMD8131 is not set
# CONFIG_EDAC_AMD8111 is not set
# CONFIG_RTC_CLASS is not set
# CONFIG_DMADEVICES is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_DELL_WMI is not set
# CONFIG_TC1100_WMI is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_INTEL_MENLOW is not set
# CONFIG_EEEPC_LAPTOP is not set
CONFIG_ACPI_WMI=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_ISCSI_IBFT_FIND is not set
#
# File systems
#
CONFIG_EXT2_FS=m
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
# CONFIG_EXT2_FS_SECURITY is not set
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
# CONFIG_EXT3_FS_SECURITY is not set
# CONFIG_EXT4_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
# CONFIG_XFS_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_QUOTA=y
# CONFIG_QUOTA_NETLINK_INTERFACE is not set
CONFIG_PRINT_QUOTA_WARNING=y
CONFIG_QUOTA_TREE=m
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=m
CONFIG_QUOTACTL=y
CONFIG_AUTOFS_FS=m
CONFIG_AUTOFS4_FS=m
CONFIG_FUSE_FS=m
#
# Caches
#
# CONFIG_FSCACHE is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
# CONFIG_NTFS_RW is not set
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_RPCSEC_GSS_KRB5=m
CONFIG_RPCSEC_GSS_SPKM3=m
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp850"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=m
# CONFIG_DLM is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_FRAME_WARN=1024
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_SCHED_DEBUG=y
# CONFIG_SCHEDSTATS is not set
CONFIG_TIMER_STATS=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_RCU_CPU_STALL_DETECTOR is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_LKDTM is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_SYSCTL_SYSCALL_CHECK=y
# CONFIG_DEBUG_PAGEALLOC is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_HW_BRANCH_TRACER=y
CONFIG_HAVE_FTRACE_SYSCALLS=y
CONFIG_RING_BUFFER=y
CONFIG_TRACING=y
CONFIG_TRACING_SUPPORT=y
#
# Tracers
#
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SYSPROF_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_CONTEXT_SWITCH_TRACER is not set
# CONFIG_EVENT_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_BOOT_TRACER is not set
# CONFIG_TRACE_BRANCH_PROFILING is not set
# CONFIG_POWER_TRACER is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_HW_BRANCH_TRACER is not set
# CONFIG_KMEMTRACE is not set
# CONFIG_WORKQUEUE_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_DYNAMIC_DEBUG is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
# CONFIG_KGDB_TESTS is not set
CONFIG_STRICT_DEVMEM=y
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
# CONFIG_EARLY_PRINTK_DBGP is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_4KSTACKS=y
CONFIG_DOUBLEFAULT=y
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
CONFIG_IO_DELAY_0XED=y
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=1
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
# CONFIG_OPTIMIZE_INLINING is not set
#
# Security options
#
CONFIG_KEYS=y
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITYFS is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not set
# CONFIG_IMA is not set
CONFIG_CRYPTO=y
#
# Crypto core or helper
#
# CONFIG_CRYPTO_FIPS is not set
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=m
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=m
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
#
# Authenticated Encryption with Associated Data
#
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m
#
# Block modes
#
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
#
# Hash modes
#
CONFIG_CRYPTO_HMAC=y
CONFIG_CRYPTO_XCBC=m
#
# Digest
#
CONFIG_CRYPTO_CRC32C=m
# CONFIG_CRYPTO_CRC32C_INTEL is not set
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
#
# Ciphers
#
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_586=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_586=m
#
# Compression
#
CONFIG_CRYPTO_DEFLATE=m
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=m
#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_CRYPTO_DEV_GEODE is not set
CONFIG_CRYPTO_DEV_HIFN_795X=m
CONFIG_CRYPTO_DEV_HIFN_795X_RNG=y
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
CONFIG_LGUEST=m
CONFIG_VIRTIO=y
CONFIG_VIRTIO_RING=y
# CONFIG_VIRTIO_PCI is not set
# CONFIG_VIRTIO_BALLOON is not set
CONFIG_BINARY_PRINTF=y
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
CONFIG_GENERIC_FIND_LAST_BIT=y
CONFIG_CRC_CCITT=m
# CONFIG_CRC16 is not set
# CONFIG_CRC_T10DIF is not set
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC7 is not set
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_TEXTSEARCH=y
CONFIG_TEXTSEARCH_KMP=m
CONFIG_TEXTSEARCH_BM=m
CONFIG_TEXTSEARCH_FSM=m
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_NLATTR=y
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <200904081021.39877.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
@ 2009-04-08 20:58 ` Matias Zabaljauregui
2009-04-09 10:32 ` Simon Holm Thøgersen
2009-04-09 12:24 ` Patrick McHardy
0 siblings, 2 replies; 46+ messages in thread
From: Matias Zabaljauregui @ 2009-04-08 20:58 UTC (permalink / raw)
To: odie-t5LvXY1cjzpaa/9Udqfwiw, Patrick McHardy
Cc: virtualization-qjLDD68F18O7TbgM5vRIOg,
lguest-mnsaURCQ41sdnm+yROfE0A
Simon, Patrick,
On Wed, 2009-04-08 at 10:21 +0930, Rusty Russell wrote:
> On Tuesday 07 April 2009 04:19:58 Matias Zabaljauregui wrote:
> > But then, when it tries to re-execute the faulting instruction, which is
> > now patched with "cd 1f 90" (int 0x1f, nop), it raises an invalid code
> > fault again, instead of doing the trap.
>
> COW on the page? Perhaps try flushing all the shadow pagetables after a
> rewrite?
>
> Rusty.
Rusty suggested that perhaps we need to flush all shadow after rewriting.
Could you please try this patch?
BTW, shouldn't this also affect my test boxes if this were the case?
Thanks,
Matias
diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
index a6b7176..b4747f7 100644
--- a/drivers/lguest/x86/core.c
+++ b/drivers/lguest/x86/core.c
@@ -324,6 +324,7 @@ static void rewrite_hypercall(struct lg_cpu *cpu)
u8 insn[3] = {0xcd, 0x1f, 0x90};
__lgwrite(cpu, guest_pa(cpu, cpu->regs->eip), insn, sizeof(insn));
+ guest_pagetable_clear_all(cpu);
}
static bool is_hypercall(struct lg_cpu *cpu)
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
2009-04-08 20:58 ` Matias Zabaljauregui
@ 2009-04-09 10:32 ` Simon Holm Thøgersen
[not found] ` <1239273165.5687.10.camel-78RDdhuQolGs1BDpvl8NfQ@public.gmane.org>
2009-04-09 12:24 ` Patrick McHardy
1 sibling, 1 reply; 46+ messages in thread
From: Simon Holm Thøgersen @ 2009-04-09 10:32 UTC (permalink / raw)
To: Matias Zabaljauregui
Cc: virtualization-qjLDD68F18O7TbgM5vRIOg,
lguest-mnsaURCQ41sdnm+yROfE0A, Patrick McHardy
ons, 08 04 2009 kl. 17:58 -0300, skrev Matias Zabaljauregui:
> Simon, Patrick,
>
> On Wed, 2009-04-08 at 10:21 +0930, Rusty Russell wrote:
> > On Tuesday 07 April 2009 04:19:58 Matias Zabaljauregui wrote:
> > > But then, when it tries to re-execute the faulting instruction, which is
> > > now patched with "cd 1f 90" (int 0x1f, nop), it raises an invalid code
> > > fault again, instead of doing the trap.
> >
> > COW on the page? Perhaps try flushing all the shadow pagetables after a
> > rewrite?
> >
> > Rusty.
>
> Rusty suggested that perhaps we need to flush all shadow after rewriting.
> Could you please try this patch?
Yes, it fixes the issue.
>
> BTW, shouldn't this also affect my test boxes if this were the case?
>
Could be the timing differences between our boxes I guess?
The compiler used seems to play a role as well, though. I compiled a
kernel on another box and using that there was no problems even without
the patch. If you are interested in testing the faulty kernel I could
make it available to you.
Simon
>
> diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
> index a6b7176..b4747f7 100644
> --- a/drivers/lguest/x86/core.c
> +++ b/drivers/lguest/x86/core.c
> @@ -324,6 +324,7 @@ static void rewrite_hypercall(struct lg_cpu *cpu)
> u8 insn[3] = {0xcd, 0x1f, 0x90};
>
> __lgwrite(cpu, guest_pa(cpu, cpu->regs->eip), insn, sizeof(insn));
> + guest_pagetable_clear_all(cpu);
> }
>
> static bool is_hypercall(struct lg_cpu *cpu)
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
2009-04-08 20:58 ` Matias Zabaljauregui
2009-04-09 10:32 ` Simon Holm Thøgersen
@ 2009-04-09 12:24 ` Patrick McHardy
[not found] ` <49DDE91A.8060603-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
1 sibling, 1 reply; 46+ messages in thread
From: Patrick McHardy @ 2009-04-09 12:24 UTC (permalink / raw)
To: Matias Zabaljauregui
Cc: lguest-mnsaURCQ41sdnm+yROfE0A,
virtualization-qjLDD68F18O7TbgM5vRIOg
Matias Zabaljauregui wrote:
> Simon, Patrick,
>
> Rusty suggested that perhaps we need to flush all shadow after rewriting.
> Could you please try this patch?
I get a new error with this patch:
lguest: unhandled trap 13 at 0xc0513417 (0x0)
c0513410 <lguest_init>:
c0513410: 55 push %ebp
c0513411: 89 e5 mov %esp,%ebp
c0513413: 53 push %ebx
c0513414: 83 ec 14 sub $0x14,%esp
c0513417: 65 a1 14 00 00 00 mov %gs:0x14,%eax
c051341d: 89 45 f8 mov %eax,-0x8(%ebp)
c0513420: 31 c0 xor %eax,%eax
c0513422: c7 05 ac 06 4e c0 ab movl $0xc04754ab,0xc04e06ac
which goes away by turning of CONFIG_STACKPROTECTOR. Now it seems
to work, but the host crashes before the guests are fully up somewhere
in the tun-device. I couldn't capture the oops yet, but I'll try
to fix it myself.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <49DDE91A.8060603-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
@ 2009-04-09 13:20 ` Patrick McHardy
2009-04-09 13:59 ` [Lguest] " Eric W. Biederman
[not found] ` <49DDF614.1060909-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
0 siblings, 2 replies; 46+ messages in thread
From: Patrick McHardy @ 2009-04-09 13:20 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Matias Zabaljauregui,
virtualization-qjLDD68F18O7TbgM5vRIOg
[-- Attachment #1: Type: text/plain, Size: 1029 bytes --]
Patrick McHardy wrote:
> which goes away by turning of CONFIG_STACKPROTECTOR. Now it seems
> to work, but the host crashes before the guests are fully up somewhere
> in the tun-device. I couldn't capture the oops yet, but I'll try
> to fix it myself.
This was caused by a local change of mine to attach to existing
tun-devices, combined with a bug in the tun driver, which looks
like it was introduced by this patch:
commit c70f182940f988448f3c12a209d18b1edc276e33
Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Date: Tue Jan 20 11:07:17 2009 +0000
tun: Fix races between tun_net_close and free_netdev.
When creating the device using tunctl the sk->sk_sleep poiner is
set to the read_wait completion of the file opened by tunctl, but
it is not refreshed when attaching to lguest or released when
closing the file, causing a stale pointer dereference in
tun_sock_write_space().
Eric, please review. Thanks.
Signed-off-by: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
[-- Attachment #2: tun.diff --]
[-- Type: text/x-patch, Size: 589 bytes --]
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a1b0697..0af7ceb 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -173,6 +173,8 @@ static void __tun_detach(struct tun_struct *tun)
tun->tfile = NULL;
netif_tx_unlock_bh(tun->dev);
+ tun->sk->sk_sleep = NULL;
+
/* Drop read queue */
skb_queue_purge(&tun->readq);
@@ -873,6 +875,9 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
else
return -EINVAL;
+ sk = tun->sk;
+ sk->sk_sleep = &tfile->read_wait;
+
err = tun_attach(tun, file);
if (err < 0)
return err;
[-- Attachment #3: Type: text/plain, Size: 158 bytes --]
_______________________________________________
Lguest mailing list
Lguest-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/lguest
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls
2009-04-09 13:20 ` Patrick McHardy
@ 2009-04-09 13:59 ` Eric W. Biederman
[not found] ` <m1bpr6hqrm.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
[not found] ` <49DDF614.1060909-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
1 sibling, 1 reply; 46+ messages in thread
From: Eric W. Biederman @ 2009-04-09 13:59 UTC (permalink / raw)
To: Patrick McHardy
Cc: lguest, Herbert Xu, odie, virtualization, Matias Zabaljauregui
Patrick McHardy <kaber@trash.net> writes:
> Patrick McHardy wrote:
>> which goes away by turning of CONFIG_STACKPROTECTOR. Now it seems
>> to work, but the host crashes before the guests are fully up somewhere
>> in the tun-device. I couldn't capture the oops yet, but I'll try
>> to fix it myself.
>
> This was caused by a local change of mine to attach to existing
> tun-devices, combined with a bug in the tun driver, which looks
> like it was introduced by this patch:
>
> commit c70f182940f988448f3c12a209d18b1edc276e33
> Author: Eric W. Biederman <ebiederm@xmission.com>
> Date: Tue Jan 20 11:07:17 2009 +0000
>
> tun: Fix races between tun_net_close and free_netdev.
A combination of my patch and the patches that added a socket
into the tun driver.
> When creating the device using tunctl the sk->sk_sleep poiner is
> set to the read_wait completion of the file opened by tunctl, but
> it is not refreshed when attaching to lguest or released when
> closing the file, causing a stale pointer dereference in
> tun_sock_write_space().
>
> Eric, please review. Thanks.
That looks a little better. Certainly as the socket currently
lives with the tun_struct instead of the tun_file it make sense.
I'm not at all certain it makes sense for the socket to live in
tun_struct instead of tun_file.
I happened to glance at the code about a week ago, and realized that
the introduction of the socket had done horribly things to the
guarantees I had introduced, and I haven't had a chance to think
through and figure out what the code should be doing.
I am certain that:
opening a tap device and then "ip link del tap0" while holding
the tap open leads into a territory of madness right now.
And apparently so does reattaching to an existing tun device.
Patrick I'm not seeing anything in the particular patch you pointed
out that would cause crashes.
Other lurking bugs aside your patch appears slightly off.
tun->sk->sk_sleep in __tun_detach is correct.
Setting sk_sleep on both paths to tun_attach instead
of in tun_attach is wrong. You are performing the assignment
before we complete the permission checks into tun_attach, which
means there is no guarantee that the tun_attach will succeed.
Eric
> Signed-off-by: Patrick McHardy <kaber@trash.net>
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index a1b0697..0af7ceb 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -173,6 +173,8 @@ static void __tun_detach(struct tun_struct *tun)
> tun->tfile = NULL;
> netif_tx_unlock_bh(tun->dev);
>
> + tun->sk->sk_sleep = NULL;
> +
> /* Drop read queue */
> skb_queue_purge(&tun->readq);
>
> @@ -873,6 +875,9 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> else
> return -EINVAL;
>
> + sk = tun->sk;
> + sk->sk_sleep = &tfile->read_wait;
> +
> err = tun_attach(tun, file);
> if (err < 0)
> return err;
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <1239273165.5687.10.camel-78RDdhuQolGs1BDpvl8NfQ@public.gmane.org>
@ 2009-04-13 16:25 ` Matias Zabaljauregui
2009-04-15 8:42 ` Rusty Russell
0 siblings, 1 reply; 46+ messages in thread
From: Matias Zabaljauregui @ 2009-04-13 16:25 UTC (permalink / raw)
To: Simon Holm Thøgersen
Cc: virtualization-qjLDD68F18O7TbgM5vRIOg,
lguest-mnsaURCQ41sdnm+yROfE0A, Patrick McHardy
Hi,
On Thu, 2009-04-09 at 12:32 +0200, Simon Holm Thøgersen wrote:
> ons, 08 04 2009 kl. 17:58 -0300, skrev Matias Zabaljauregui:
> > Simon, Patrick,
> >
> > On Wed, 2009-04-08 at 10:21 +0930, Rusty Russell wrote:
> > > On Tuesday 07 April 2009 04:19:58 Matias Zabaljauregui wrote:
> > > > But then, when it tries to re-execute the faulting instruction, which is
> > > > now patched with "cd 1f 90" (int 0x1f, nop), it raises an invalid code
> > > > fault again, instead of doing the trap.
> > >
> > > COW on the page? Perhaps try flushing all the shadow pagetables after a
> > > rewrite?
> > >
> > > Rusty.
> >
> > Rusty suggested that perhaps we need to flush all shadow after rewriting.
> > Could you please try this patch?
>
> Yes, it fixes the issue.
great, thanks for testing.
> >
> > BTW, shouldn't this also affect my test boxes if this were the case?
> >
> Could be the timing differences between our boxes I guess?
I haven't read COW code, but I cannot figure out how CPU timing
differences could affect a logic driven by faults. I will investigate
further and let you know if I can yield any conclusion.
>
> The compiler used seems to play a role as well, though. I compiled a
> kernel on another box and using that there was no problems even without
> the patch. If you are interested in testing the faulty kernel I could
> make it available to you.
> Simon
Regards,
Matias
> >
> > diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
> > index a6b7176..b4747f7 100644
> > --- a/drivers/lguest/x86/core.c
> > +++ b/drivers/lguest/x86/core.c
> > @@ -324,6 +324,7 @@ static void rewrite_hypercall(struct lg_cpu *cpu)
> > u8 insn[3] = {0xcd, 0x1f, 0x90};
> >
> > __lgwrite(cpu, guest_pa(cpu, cpu->regs->eip), insn, sizeof(insn));
> > + guest_pagetable_clear_all(cpu);
> > }
> >
> > static bool is_hypercall(struct lg_cpu *cpu)
>
>
_______________________________________________
Lguest mailing list
Lguest@ozlabs.org
https://ozlabs.org/mailman/listinfo/lguest
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <49DDF614.1060909-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
@ 2009-04-13 16:29 ` Matias Zabaljauregui
2009-04-14 11:55 ` Patrick McHardy
0 siblings, 1 reply; 46+ messages in thread
From: Matias Zabaljauregui @ 2009-04-13 16:29 UTC (permalink / raw)
To: Patrick McHardy
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Eric W. Biederman,
virtualization-qjLDD68F18O7TbgM5vRIOg
Hello Patrick,
On Thu, 2009-04-09 at 15:20 +0200, Patrick McHardy wrote:
> Patrick McHardy wrote:
> > which goes away by turning of CONFIG_STACKPROTECTOR. Now it seems
> > to work, but the host crashes before the guests are fully up somewhere
> > in the tun-device. I couldn't capture the oops yet, but I'll try
> > to fix it myself.
>
> This was caused by a local change of mine to attach to existing
> tun-devices, combined with a bug in the tun driver, which looks
> like it was introduced by this patch:
>
> commit c70f182940f988448f3c12a209d18b1edc276e33
> Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Date: Tue Jan 20 11:07:17 2009 +0000
>
> tun: Fix races between tun_net_close and free_netdev.
>
So, can we assume that everything is ok if we turn off STACK_PROTECTOR ?
thanks
Matias
> When creating the device using tunctl the sk->sk_sleep poiner is
> set to the read_wait completion of the file opened by tunctl, but
> it is not refreshed when attaching to lguest or released when
> closing the file, causing a stale pointer dereference in
> tun_sock_write_space().
>
> Eric, please review. Thanks.
>
> Signed-off-by: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <m1bpr6hqrm.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
@ 2009-04-14 11:54 ` Patrick McHardy
[not found] ` <49E47976.8020005-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2009-04-15 8:36 ` [Lguest] " Herbert Xu
0 siblings, 2 replies; 46+ messages in thread
From: Patrick McHardy @ 2009-04-14 11:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Herbert Xu,
virtualization-qjLDD68F18O7TbgM5vRIOg, Matias Zabaljauregui
[-- Attachment #1: Type: text/plain, Size: 1894 bytes --]
Eric W. Biederman wrote:
> Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org> writes:
>
>> When creating the device using tunctl the sk->sk_sleep poiner is
>> set to the read_wait completion of the file opened by tunctl, but
>> it is not refreshed when attaching to lguest or released when
>> closing the file, causing a stale pointer dereference in
>> tun_sock_write_space().
>>
>> Eric, please review. Thanks.
>
> That looks a little better. Certainly as the socket currently
> lives with the tun_struct instead of the tun_file it make sense.
> I'm not at all certain it makes sense for the socket to live in
> tun_struct instead of tun_file.
>
> I happened to glance at the code about a week ago, and realized that
> the introduction of the socket had done horribly things to the
> guarantees I had introduced, and I haven't had a chance to think
> through and figure out what the code should be doing.
>
> I am certain that:
> opening a tap device and then "ip link del tap0" while holding
> the tap open leads into a territory of madness right now.
>
> And apparently so does reattaching to an existing tun device.
>
> Patrick I'm not seeing anything in the particular patch you pointed
> out that would cause crashes.
It might have been a different patch or a combination, I assumed it
was your patch since git annotate pointed to it and it was a very
recent change.
> Other lurking bugs aside your patch appears slightly off.
>
> tun->sk->sk_sleep in __tun_detach is correct.
>
> Setting sk_sleep on both paths to tun_attach instead
> of in tun_attach is wrong. You are performing the assignment
> before we complete the permission checks into tun_attach, which
> means there is no guarantee that the tun_attach will succeed.
I see. How about this patch instead? It moves the sk_sleep assignment
to tun_attach, after the permission checks took place.
Thanks.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 1170 bytes --]
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a1b0697..4c5ae95 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -155,6 +155,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
err = 0;
tfile->tun = tun;
tun->tfile = tfile;
+ tun->sk->sk_sleep = &tfile->read_wait;
dev_hold(tun->dev);
atomic_inc(&tfile->count);
@@ -173,6 +174,8 @@ static void __tun_detach(struct tun_struct *tun)
tun->tfile = NULL;
netif_tx_unlock_bh(tun->dev);
+ tun->sk->sk_sleep = NULL;
+
/* Drop read queue */
skb_queue_purge(&tun->readq);
@@ -861,7 +864,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
struct sock *sk;
struct tun_struct *tun;
struct net_device *dev;
- struct tun_file *tfile = file->private_data;
int err;
dev = __dev_get_by_name(net, ifr->ifr_name);
@@ -925,7 +927,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
sk->sk_write_space = tun_sock_write_space;
sk->sk_destruct = tun_sock_destruct;
sk->sk_sndbuf = INT_MAX;
- sk->sk_sleep = &tfile->read_wait;
tun->sk = sk;
container_of(sk, struct tun_sock, sk)->tun = tun;
[-- Attachment #3: Type: text/plain, Size: 158 bytes --]
_______________________________________________
Lguest mailing list
Lguest-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
https://ozlabs.org/mailman/listinfo/lguest
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
2009-04-13 16:29 ` [PATCH 4/5] lguest: use KVM hypercalls Matias Zabaljauregui
@ 2009-04-14 11:55 ` Patrick McHardy
0 siblings, 0 replies; 46+ messages in thread
From: Patrick McHardy @ 2009-04-14 11:55 UTC (permalink / raw)
To: Matias Zabaljauregui
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Eric W. Biederman,
virtualization-qjLDD68F18O7TbgM5vRIOg
Matias Zabaljauregui wrote:
> Hello Patrick,
>
> On Thu, 2009-04-09 at 15:20 +0200, Patrick McHardy wrote:
>> Patrick McHardy wrote:
>>> which goes away by turning of CONFIG_STACKPROTECTOR. Now it seems
>>> to work, but the host crashes before the guests are fully up somewhere
>>> in the tun-device. I couldn't capture the oops yet, but I'll try
>>> to fix it myself.
>> This was caused by a local change of mine to attach to existing
>> tun-devices, combined with a bug in the tun driver, which looks
>> like it was introduced by this patch:
>>
>> commit c70f182940f988448f3c12a209d18b1edc276e33
>> Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
>> Date: Tue Jan 20 11:07:17 2009 +0000
>>
>> tun: Fix races between tun_net_close and free_netdev.
>>
>
> So, can we assume that everything is ok if we turn off STACK_PROTECTOR ?
From a lguest perspective, yes.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <49E47976.8020005-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
@ 2009-04-14 17:10 ` Eric W. Biederman
0 siblings, 0 replies; 46+ messages in thread
From: Eric W. Biederman @ 2009-04-14 17:10 UTC (permalink / raw)
To: Patrick McHardy
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Herbert Xu,
virtualization-qjLDD68F18O7TbgM5vRIOg, Matias Zabaljauregui
Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org> writes:
> Eric W. Biederman wrote:
>> Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org> writes:
>>
>>> When creating the device using tunctl the sk->sk_sleep poiner is
>>> set to the read_wait completion of the file opened by tunctl, but
>>> it is not refreshed when attaching to lguest or released when
>>> closing the file, causing a stale pointer dereference in
>>> tun_sock_write_space().
>>>
>>> Eric, please review. Thanks.
>>
>> That looks a little better. Certainly as the socket currently
>> lives with the tun_struct instead of the tun_file it make sense.
>> I'm not at all certain it makes sense for the socket to live in
>> tun_struct instead of tun_file.
>>
>> I happened to glance at the code about a week ago, and realized that
>> the introduction of the socket had done horribly things to the
>> guarantees I had introduced, and I haven't had a chance to think
>> through and figure out what the code should be doing.
>>
>> I am certain that:
>> opening a tap device and then "ip link del tap0" while holding
>> the tap open leads into a territory of madness right now.
>>
>> And apparently so does reattaching to an existing tun device.
>>
>> Patrick I'm not seeing anything in the particular patch you pointed
>> out that would cause crashes.
>
> It might have been a different patch or a combination, I assumed it
> was your patch since git annotate pointed to it and it was a very
> recent change.
No problem. tun was remarkably active this last while.
Sounds like a testament to virtual environments.
>> Other lurking bugs aside your patch appears slightly off.
>>
>> tun->sk->sk_sleep in __tun_detach is correct.
>>
>> Setting sk_sleep on both paths to tun_attach instead
>> of in tun_attach is wrong. You are performing the assignment
>> before we complete the permission checks into tun_attach, which
>> means there is no guarantee that the tun_attach will succeed.
>
> I see. How about this patch instead? It moves the sk_sleep assignment
> to tun_attach, after the permission checks took place.
Acked-by: "Eric W. Biederman" <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Looks good.
> Thanks.
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index a1b0697..4c5ae95 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -155,6 +155,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
> err = 0;
> tfile->tun = tun;
> tun->tfile = tfile;
> + tun->sk->sk_sleep = &tfile->read_wait;
> dev_hold(tun->dev);
> atomic_inc(&tfile->count);
>
> @@ -173,6 +174,8 @@ static void __tun_detach(struct tun_struct *tun)
> tun->tfile = NULL;
> netif_tx_unlock_bh(tun->dev);
>
> + tun->sk->sk_sleep = NULL;
> +
> /* Drop read queue */
> skb_queue_purge(&tun->readq);
>
> @@ -861,7 +864,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> struct sock *sk;
> struct tun_struct *tun;
> struct net_device *dev;
> - struct tun_file *tfile = file->private_data;
> int err;
>
> dev = __dev_get_by_name(net, ifr->ifr_name);
> @@ -925,7 +927,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> sk->sk_write_space = tun_sock_write_space;
> sk->sk_destruct = tun_sock_destruct;
> sk->sk_sndbuf = INT_MAX;
> - sk->sk_sleep = &tfile->read_wait;
>
> tun->sk = sk;
> container_of(sk, struct tun_sock, sk)->tun = tun;
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls
2009-04-14 11:54 ` Patrick McHardy
[not found] ` <49E47976.8020005-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
@ 2009-04-15 8:36 ` Herbert Xu
[not found] ` <20090415083610.GA8579-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
1 sibling, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 8:36 UTC (permalink / raw)
To: Patrick McHardy
Cc: Eric W. Biederman, Matias Zabaljauregui, odie, Rusty Russell,
lguest, virtualization, David S. Miller, netdev
On Tue, Apr 14, 2009 at 01:54:30PM +0200, Patrick McHardy wrote:
>
> I see. How about this patch instead? It moves the sk_sleep assignment
> to tun_attach, after the permission checks took place.
Thanks for pointing out this gaping hole in my patch. I think
it may be better to remove read_wait altogether and just use
socket.wait in tun_struct.
Let me whip up a patch.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
2009-04-13 16:25 ` Matias Zabaljauregui
@ 2009-04-15 8:42 ` Rusty Russell
[not found] ` <200904151812.23318.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Rusty Russell @ 2009-04-15 8:42 UTC (permalink / raw)
To: Matias Zabaljauregui
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Patrick McHardy,
virtualization-qjLDD68F18O7TbgM5vRIOg
On Tue, 14 Apr 2009 01:55:39 am Matias Zabaljauregui wrote:
> > > BTW, shouldn't this also affect my test boxes if this were the case?
> > >
> > Could be the timing differences between our boxes I guess?
>
> I haven't read COW code, but I cannot figure out how CPU timing
> differences could affect a logic driven by faults. I will investigate
> further and let you know if I can yield any conclusion.
I first thought it was guest image layout, until I reproduced it completely
accidentally here.
Matias, can I have a Signed-off-by for your patch (enhanced with comment
below):
Subject: lguest: fix KVM-style hypercalls with vmlinux images
Date: Wed, 08 Apr 2009 17:58:39 -0300
From: Matias Zabaljauregui <zabaljauregui-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Impact: fix guest crash 'lguest: unhandled trap 6 at 0x418726 (0x0)'
The Launcher mmaps the kernel image. The Guest executes and
immediately faults in the first text page (read-only). Then it hits a
hypercall, and we rewrite that hypercall, causing a copy-on-write.
But the Guest pagetables still refer to the old page: we fault again,
but as Host we see the hypercall already rewritten, and pass the fault
back to the Guest. The Guest hasn't set up an IDT yet, so we kill it.
This doesn't happen with bzImages: they unpack themselves and so the
text pages are already read-write.
Signed-off-by: Rusty Russell <rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
Tested-by: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
---
drivers/lguest/x86/core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/lguest/x86/core.c b/drivers/lguest/x86/core.c
index a6b7176..b4747f7 100644
--- a/drivers/lguest/x86/core.c
+++ b/drivers/lguest/x86/core.c
@@ -324,6 +324,11 @@ static void rewrite_hypercall(struct lg_cpu *cpu)
u8 insn[3] = {0xcd, 0x1f, 0x90};
__lgwrite(cpu, guest_pa(cpu, cpu->regs->eip), insn, sizeof(insn));
+ /* The above write might have caused a copy of that page to be made
+ * (if it was read-only). We need to make sure the Guest has
+ * up-to-date pagetables. As this doesn't happen often, we can just
+ * drop them all. */
+ guest_pagetable_clear_all(cpu);
}
static bool is_hypercall(struct lg_cpu *cpu)
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <20090415083610.GA8579-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-15 8:47 ` Herbert Xu
2009-04-15 9:07 ` [Lguest] " Christian Borntraeger
` (2 more replies)
0 siblings, 3 replies; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 8:47 UTC (permalink / raw)
To: Patrick McHardy
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
virtualization-qjLDD68F18O7TbgM5vRIOg, Matias Zabaljauregui,
Eric W. Biederman, netdev-u79uwXL29TY76Z2rM5mHXA, David S. Miller
On Wed, Apr 15, 2009 at 04:36:10PM +0800, Herbert Xu wrote:
>
> Let me whip up a patch.
tun: Fix sk_sleep races when attaching/detaching
As the sk_sleep wait queue actually lives in tfile, which may be
detached from the tun device, bad things will happen when we use
sk_sleep after detaching.
Since the tun device is the persistent data structure here (when
requested by the user), it makes much more sense to have the wait
queue live there. There is no reason to have it in tfile at all
since the only time we can wait is if we have a tun attached.
In fact we already have a wait queue in tun_struct, so we might
as well use it.
Reported-by: Christian Borntraeger <borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Reported-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Reported-by: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
Signed-off-by: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a1b0697..412b578 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -93,7 +93,6 @@ struct tun_file {
atomic_t count;
struct tun_struct *tun;
struct net *net;
- wait_queue_head_t read_wait;
};
struct tun_sock;
@@ -333,7 +332,7 @@ static void tun_net_uninit(struct net_device *dev)
/* Inform the methods they need to stop using the dev.
*/
if (tfile) {
- wake_up_all(&tfile->read_wait);
+ wake_up_all(&tun->socket.wait);
if (atomic_dec_and_test(&tfile->count))
__tun_detach(tun);
}
@@ -393,7 +392,7 @@ static int tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
/* Notify and wake up reader process */
if (tun->flags & TUN_FASYNC)
kill_fasync(&tun->fasync, SIGIO, POLL_IN);
- wake_up_interruptible(&tun->tfile->read_wait);
+ wake_up_interruptible(&tun->socket.wait);
return 0;
drop:
@@ -490,7 +489,7 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);
- poll_wait(file, &tfile->read_wait, wait);
+ poll_wait(file, &tun->socket.wait, wait);
if (!skb_queue_empty(&tun->readq))
mask |= POLLIN | POLLRDNORM;
@@ -762,7 +761,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
goto out;
}
- add_wait_queue(&tfile->read_wait, &wait);
+ add_wait_queue(&tun->socket.wait, &wait);
while (len) {
current->state = TASK_INTERRUPTIBLE;
@@ -793,7 +792,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
}
current->state = TASK_RUNNING;
- remove_wait_queue(&tfile->read_wait, &wait);
+ remove_wait_queue(&tun->socket.wait, &wait);
out:
tun_put(tun);
@@ -861,7 +860,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
struct sock *sk;
struct tun_struct *tun;
struct net_device *dev;
- struct tun_file *tfile = file->private_data;
int err;
dev = __dev_get_by_name(net, ifr->ifr_name);
@@ -921,11 +919,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
/* This ref count is for tun->sk. */
dev_hold(dev);
+ init_waitqueue_head(&tun->socket.wait);
sock_init_data(&tun->socket, sk);
sk->sk_write_space = tun_sock_write_space;
sk->sk_destruct = tun_sock_destruct;
sk->sk_sndbuf = INT_MAX;
- sk->sk_sleep = &tfile->read_wait;
tun->sk = sk;
container_of(sk, struct tun_sock, sk)->tun = tun;
@@ -1265,7 +1263,6 @@ static int tun_chr_open(struct inode *inode, struct file * file)
atomic_set(&tfile->count, 0);
tfile->tun = NULL;
tfile->net = get_net(current->nsproxy->net_ns);
- init_waitqueue_head(&tfile->read_wait);
file->private_data = tfile;
return 0;
}
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls
2009-04-15 8:47 ` Herbert Xu
@ 2009-04-15 9:07 ` Christian Borntraeger
2009-04-15 11:07 ` Patrick McHardy
2009-04-15 13:23 ` Eric W. Biederman
2 siblings, 0 replies; 46+ messages in thread
From: Christian Borntraeger @ 2009-04-15 9:07 UTC (permalink / raw)
To: Herbert Xu
Cc: Patrick McHardy, Eric W. Biederman, Matias Zabaljauregui, odie,
Rusty Russell, lguest, virtualization, David S. Miller, netdev
Am Wednesday 15 April 2009 10:47:17 schrieb Herbert Xu:
> tun: Fix sk_sleep races when attaching/detaching
>
> As the sk_sleep wait queue actually lives in tfile, which may be
> detached from the tun device, bad things will happen when we use
> sk_sleep after detaching.
>
> Since the tun device is the persistent data structure here (when
> requested by the user), it makes much more sense to have the wait
> queue live there. There is no reason to have it in tfile at all
> since the only time we can wait is if we have a tun attached.
> In fact we already have a wait queue in tun_struct, so we might
> as well use it.
>
> Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
> Reported-by: Eric W. Biederman <ebiederm@xmission.com>
> Reported-by: Patrick McHardy <kaber@trash.net>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Tested-by: Christian Borntraeger <borntraeger@de.ibm.com>
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls
2009-04-15 8:47 ` Herbert Xu
2009-04-15 9:07 ` [Lguest] " Christian Borntraeger
@ 2009-04-15 11:07 ` Patrick McHardy
2009-04-15 13:23 ` Eric W. Biederman
2 siblings, 0 replies; 46+ messages in thread
From: Patrick McHardy @ 2009-04-15 11:07 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric W. Biederman, Matias Zabaljauregui, odie, Rusty Russell,
lguest, virtualization, David S. Miller, netdev,
Christian Borntraeger
Herbert Xu wrote:
> On Wed, Apr 15, 2009 at 04:36:10PM +0800, Herbert Xu wrote:
>> Let me whip up a patch.
>
> tun: Fix sk_sleep races when attaching/detaching
>
> As the sk_sleep wait queue actually lives in tfile, which may be
> detached from the tun device, bad things will happen when we use
> sk_sleep after detaching.
>
> Since the tun device is the persistent data structure here (when
> requested by the user), it makes much more sense to have the wait
> queue live there. There is no reason to have it in tfile at all
> since the only time we can wait is if we have a tun attached.
> In fact we already have a wait queue in tun_struct, so we might
> as well use it.
Tested and works fine, thanks Herbert.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls
2009-04-15 8:47 ` Herbert Xu
2009-04-15 9:07 ` [Lguest] " Christian Borntraeger
2009-04-15 11:07 ` Patrick McHardy
@ 2009-04-15 13:23 ` Eric W. Biederman
[not found] ` <m18wm2rqy6.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2 siblings, 1 reply; 46+ messages in thread
From: Eric W. Biederman @ 2009-04-15 13:23 UTC (permalink / raw)
To: Herbert Xu
Cc: Patrick McHardy, Matias Zabaljauregui, odie, Rusty Russell,
lguest, virtualization, David S. Miller, netdev,
Christian Borntraeger
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Wed, Apr 15, 2009 at 04:36:10PM +0800, Herbert Xu wrote:
>>
>> Let me whip up a patch.
>
> tun: Fix sk_sleep races when attaching/detaching
>
> As the sk_sleep wait queue actually lives in tfile, which may be
> detached from the tun device, bad things will happen when we use
> sk_sleep after detaching.
>
> Since the tun device is the persistent data structure here (when
> requested by the user), it makes much more sense to have the wait
> queue live there. There is no reason to have it in tfile at all
> since the only time we can wait is if we have a tun attached.
> In fact we already have a wait queue in tun_struct, so we might
> as well use it.
There is a GIGANTIC reason to have the wait queue on tfile.
If you open a file, and do ip link del tapN you can still
be blocked waiting in poll.
The problem is specifically free_poll_entry, where we call
remove_wait_queue and fput without calling any file methods.
So all of this happens without struct tun_file's count being
elevated. Which means tun_net_uninit can detach before we get
off of the stupid poll wait queue.
As documented in:
commit b2430de37ef0bc0799ffba7b5219d38ca417eb76
Author: Eric W. Biederman <ebiederm@xmission.com>
Date: Tue Jan 20 11:03:21 2009 +0000
tun: Move read_wait into tun_file
The poll interface requires that the waitqueue exist while the struct
file is open. In the rare case when a tun device disappears before
the tun file closes we fail to provide this property, so move
read_wait.
This is safe now that tun_net_xmit is atomic with tun_detach.
Signed-off-by: Eric W. Biederman <ebiederm@aristanetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
I specifically moved the wait queue out of tun struct to avoid this
race.
I will see about getting the vfs to do something saner in my generic
revoke work. But for 2.6.30 we have to live with the nasties that
are there.
Nacked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Eric
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <m18wm2rqy6.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
@ 2009-04-15 13:28 ` Herbert Xu
[not found] ` <20090415132802.GA11408-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 13:28 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 06:23:29AM -0700, Eric W. Biederman wrote:
>
> There is a GIGANTIC reason to have the wait queue on tfile.
>
> If you open a file, and do ip link del tapN you can still
> be blocked waiting in poll.
>
> The problem is specifically free_poll_entry, where we call
> remove_wait_queue and fput without calling any file methods.
> So all of this happens without struct tun_file's count being
> elevated. Which means tun_net_uninit can detach before we get
> off of the stupid poll wait queue.
What about taking a netdev refcount before calling poll_wait?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <20090415132802.GA11408-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-15 13:35 ` Eric W. Biederman
[not found] ` <m1skkaox8h.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Eric W. Biederman @ 2009-04-15 13:35 UTC (permalink / raw)
To: Herbert Xu
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> writes:
> On Wed, Apr 15, 2009 at 06:23:29AM -0700, Eric W. Biederman wrote:
>>
>> There is a GIGANTIC reason to have the wait queue on tfile.
>>
>> If you open a file, and do ip link del tapN you can still
>> be blocked waiting in poll.
>>
>> The problem is specifically free_poll_entry, where we call
>> remove_wait_queue and fput without calling any file methods.
>> So all of this happens without struct tun_file's count being
>> elevated. Which means tun_net_uninit can detach before we get
>> off of the stupid poll wait queue.
>
> What about taking a netdev refcount before calling poll_wait?
Because as far as I can tell we would just leak that refcount.
The poll code does not appear to call back into any of the file
methods when it frees itself from the wait queue.
Eric
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <m1skkaox8h.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
@ 2009-04-15 13:46 ` Herbert Xu
[not found] ` <20090415134610.GA11683-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-15 14:06 ` [Lguest] " Eric W. Biederman
0 siblings, 2 replies; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 13:46 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 06:35:58AM -0700, Eric W. Biederman wrote:
>
> Because as far as I can tell we would just leak that refcount.
>
> The poll code does not appear to call back into any of the file
> methods when it frees itself from the wait queue.
OK my suggestion was stupid.
But I still don't see how this race is possible at all.
So process A has a tun fd open and is spinning in poll(2). Now
process B comes along and deletes that tun device. Process A's
fd should have a netdev reference that keeps the device and
associated structures alive.
Oh I see what's going on. We're automatically detaching the
device in uninit. This is just wrong. Just because process B
deleted the netdev, process A should not be involutarily detached.
Does anything actually rely on this behaviour?
If not we should just change it to not do that.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <20090415134610.GA11683-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-15 13:55 ` Herbert Xu
[not found] ` <20090415135502.GA11827-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 13:55 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 09:46:10PM +0800, Herbert Xu wrote:
>
> Does anything actually rely on this behaviour?
I doubt it :)
> If not we should just change it to not do that.
It appears that this was introduced in
commit c70f182940f988448f3c12a209d18b1edc276e33
Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Date: Tue Jan 20 11:07:17 2009 +0000
tun: Fix races between tun_net_close and free_netdev.
Presumably in order to fix the problem of trying to unregister
the same device twice.
I what we should do is to mark the device as dead instead of
detaching if a third party deletes it. That's all you need
to know to stop close(2) from trying the unregister a device
that's already been unregistered.
What else am I missing?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [Lguest] [PATCH 4/5] lguest: use KVM hypercalls
2009-04-15 13:46 ` Herbert Xu
[not found] ` <20090415134610.GA11683-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-15 14:06 ` Eric W. Biederman
[not found] ` <m11vruovu5.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
1 sibling, 1 reply; 46+ messages in thread
From: Eric W. Biederman @ 2009-04-15 14:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Patrick McHardy, Matias Zabaljauregui, odie, Rusty Russell,
lguest, virtualization, David S. Miller, netdev,
Christian Borntraeger
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Wed, Apr 15, 2009 at 06:35:58AM -0700, Eric W. Biederman wrote:
>>
>> Because as far as I can tell we would just leak that refcount.
>>
>> The poll code does not appear to call back into any of the file
>> methods when it frees itself from the wait queue.
>
> OK my suggestion was stupid.
>
> But I still don't see how this race is possible at all.
>
> So process A has a tun fd open and is spinning in poll(2). Now
> process B comes along and deletes that tun device. Process A's
> fd should have a netdev reference that keeps the device and
> associated structures alive.
>
> Oh I see what's going on. We're automatically detaching the
> device in uninit. This is just wrong. Just because process B
> deleted the netdev, process A should not be involutarily detached.
>
> Does anything actually rely on this behaviour?
Yes.
There is the boring rmmod case that has always existed.
There is more interesting case of moving your tap device
into another network namespace.
In which case there is the possibility of the network namespace
exiting and destroying all of the virtual network devices before
we close the file handle.
I implemented the rtnetlink methods so we can test the uninit
behavior without going through all sorts of hoops.
Eric
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <m11vruovu5.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
@ 2009-04-15 14:08 ` Herbert Xu
[not found] ` <20090415140819.GA11991-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 14:08 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 07:06:10AM -0700, Eric W. Biederman wrote:
>
> There is the boring rmmod case that has always existed.
>
> There is more interesting case of moving your tap device
> into another network namespace.
>
> In which case there is the possibility of the network namespace
> exiting and destroying all of the virtual network devices before
> we close the file handle.
In that case what's the problem with holding a refcount to the
unregistered device until the process owning the fd closes it?
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <20090415135502.GA11827-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-15 14:10 ` Eric W. Biederman
[not found] ` <m1ocuynh2f.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Eric W. Biederman @ 2009-04-15 14:10 UTC (permalink / raw)
To: Herbert Xu
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> writes:
> On Wed, Apr 15, 2009 at 09:46:10PM +0800, Herbert Xu wrote:
>>
>> Does anything actually rely on this behaviour?
>
> I doubt it :)
>
>> If not we should just change it to not do that.
>
> It appears that this was introduced in
>
> commit c70f182940f988448f3c12a209d18b1edc276e33
> Author: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
> Date: Tue Jan 20 11:07:17 2009 +0000
>
> tun: Fix races between tun_net_close and free_netdev.
>
> Presumably in order to fix the problem of trying to unregister
> the same device twice.
>
> I what we should do is to mark the device as dead instead of
> detaching if a third party deletes it. That's all you need
> to know to stop close(2) from trying the unregister a device
> that's already been unregistered.
>
> What else am I missing?
Hopefully my earlier explanation helps. I will get back to
you as soon as I can. But I am off on vacation for the
rest of the week.
Eric
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <m1ocuynh2f.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
@ 2009-04-15 14:12 ` Herbert Xu
0 siblings, 0 replies; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 14:12 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 07:10:32AM -0700, Eric W. Biederman wrote:
>
> Hopefully my earlier explanation helps. I will get back to
> you as soon as I can. But I am off on vacation for the
> rest of the week.
I'm sorry but I don't think we can wait for that. We might just
have to fix it whatever way we can. You can unfix it when you
come back :)
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <20090415140819.GA11991-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-15 14:18 ` Eric W. Biederman
[not found] ` <m1iql6m24b.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Eric W. Biederman @ 2009-04-15 14:18 UTC (permalink / raw)
To: Herbert Xu
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> writes:
> On Wed, Apr 15, 2009 at 07:06:10AM -0700, Eric W. Biederman wrote:
>>
>> There is the boring rmmod case that has always existed.
>>
>> There is more interesting case of moving your tap device
>> into another network namespace.
>>
>> In which case there is the possibility of the network namespace
>> exiting and destroying all of the virtual network devices before
>> we close the file handle.
>
> In that case what's the problem with holding a refcount to the
> unregistered device until the process owning the fd closes it?
Network devices do not hold a network namespace alive. Only sockets
and processes do.
So holding the reference only blocks us indefinitely in
netdev_wait_allrefs, blocking the network namespace exit, and holding
net_mutex indefinitely.
My gut feel is that the socket needs to live in tun_file. Instead
of in tun_struct. Making that change looked just tricky enough
I couldn't sort through it when I glanced at the tun code, after I noticed
you had added a socket.
Eric
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <m1iql6m24b.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
@ 2009-04-15 14:23 ` Herbert Xu
2009-04-15 14:38 ` Herbert Xu
1 sibling, 0 replies; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 14:23 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 07:18:44AM -0700, Eric W. Biederman wrote:
>
> My gut feel is that the socket needs to live in tun_file. Instead
> of in tun_struct. Making that change looked just tricky enough
> I couldn't sort through it when I glanced at the tun code, after I noticed
> you had added a socket.
Referring to tun_file to get sk_sleep is just too error-prone.
Unlike the transmit direction, the receive direction does not
present itself to the easy xmit lock solution that's currently
used to make tun_detach atomic.
The receive callback that currently uses sk_sleep can happen
anywhere.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <m1iql6m24b.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-15 14:23 ` Herbert Xu
@ 2009-04-15 14:38 ` Herbert Xu
[not found] ` <20090415143834.GA12384-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
1 sibling, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 14:38 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 07:18:44AM -0700, Eric W. Biederman wrote:
>
> So holding the reference only blocks us indefinitely in
> netdev_wait_allrefs, blocking the network namespace exit, and holding
> net_mutex indefinitely.
OK that's a killer because process A in my previous scenario can
kill the device itself and cause a dead-lock.
So how about this? We replace the dev destructor with our own that
doesn't immediately call free_netdev. We only call free_netdev once
all tun fd's attached to the device have been closed.
This can be achieved by simply adding a counter to tun_struct.
We'd also change the async detach path to set a marker instead
of detaching. That marker can then be checked in places like
tun_get.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <200904151812.23318.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
@ 2009-04-15 14:55 ` Matias Zabaljauregui
0 siblings, 0 replies; 46+ messages in thread
From: Matias Zabaljauregui @ 2009-04-15 14:55 UTC (permalink / raw)
To: Rusty Russell
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Patrick McHardy,
virtualization-qjLDD68F18O7TbgM5vRIOg
Hi,
On Wed, 2009-04-15 at 18:12 +0930, Rusty Russell wrote:
> On Tue, 14 Apr 2009 01:55:39 am Matias Zabaljauregui wrote:
> > > > BTW, shouldn't this also affect my test boxes if this were the case?
> > > >
> > > Could be the timing differences between our boxes I guess?
> >
> > I haven't read COW code, but I cannot figure out how CPU timing
> > differences could affect a logic driven by faults. I will investigate
> > further and let you know if I can yield any conclusion.
>
> I first thought it was guest image layout, until I reproduced it completely
> accidentally here.
>
> Matias, can I have a Signed-off-by for your patch (enhanced with comment
> below):
>
I think I just missed it, sorry for the delay (i was on the road).
Thanks for you fix
Matias
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <20090415143834.GA12384-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-15 14:56 ` Eric W. Biederman
[not found] ` <m1zleiklsl.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-16 11:08 ` [1/2] tun: Only free a netdev when all tun descriptors are closed Herbert Xu
1 sibling, 1 reply; 46+ messages in thread
From: Eric W. Biederman @ 2009-04-15 14:56 UTC (permalink / raw)
To: Herbert Xu
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org> writes:
> On Wed, Apr 15, 2009 at 07:18:44AM -0700, Eric W. Biederman wrote:
>>
>> So holding the reference only blocks us indefinitely in
>> netdev_wait_allrefs, blocking the network namespace exit, and holding
>> net_mutex indefinitely.
>
> OK that's a killer because process A in my previous scenario can
> kill the device itself and cause a dead-lock.
>
> So how about this? We replace the dev destructor with our own that
> doesn't immediately call free_netdev. We only call free_netdev once
> all tun fd's attached to the device have been closed.
>
> This can be achieved by simply adding a counter to tun_struct.
> We'd also change the async detach path to set a marker instead
> of detaching. That marker can then be checked in places like
> tun_get.
That sounds like it would work, and allow us to have big tun_struct.
Which is sounds simpler overall.
I still have the feeling that putting the socket in tun_file instead
of in tun_struct might be conceptually cleaner, but one big blob that
is allocated and destroyed together is certainly easier and a lot
less racy to deal with.
Eric
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [PATCH 4/5] lguest: use KVM hypercalls
[not found] ` <m1zleiklsl.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
@ 2009-04-15 22:27 ` Herbert Xu
0 siblings, 0 replies; 46+ messages in thread
From: Herbert Xu @ 2009-04-15 22:27 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 07:56:42AM -0700, Eric W. Biederman wrote:
>
> I still have the feeling that putting the socket in tun_file instead
> of in tun_struct might be conceptually cleaner, but one big blob that
> is allocated and destroyed together is certainly easier and a lot
> less racy to deal with.
As I said the difficulty with putting the socket in tun_file
is how do you get it on the RX callback path without introducing
new races.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* [1/2] tun: Only free a netdev when all tun descriptors are closed
[not found] ` <20090415143834.GA12384-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-15 14:56 ` Eric W. Biederman
@ 2009-04-16 11:08 ` Herbert Xu
[not found] ` <20090416110818.GA20950-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-24 8:55 ` [1/2] tun: Only free a netdev when all tun descriptors are closed Christian Borntraeger
1 sibling, 2 replies; 46+ messages in thread
From: Herbert Xu @ 2009-04-16 11:08 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Wed, Apr 15, 2009 at 10:38:34PM +0800, Herbert Xu wrote:
>
> So how about this? We replace the dev destructor with our own that
> doesn't immediately call free_netdev. We only call free_netdev once
> all tun fd's attached to the device have been closed.
Here's the patch. I'd appreciate if everyone can review it
and see if they can recreate the original race by
1) Starting a process using tun and polls on it;
2) Doing ip tun del tunXXX while the process is polling.
tun: Only free a netdev when all tun descriptors are closed
The commit c70f182940f988448f3c12a209d18b1edc276e33 ("tun: Fix
races between tun_net_close and free_netdev") fixed a race where
an asynchronous deletion of a tun device can hose a poll(2) on
a tun fd attached to that device.
However, this came at the cost of moving the tun wait queue into
the tun file data structure. The problem with this is that it
imposes restrictions on when and where the tun device can access
the wait queue since the tun file may change at any time due to
detaching and reattaching.
In particular, now that we need to use the wait queue on the
receive path it becomes difficult to properly synchronise this
with the detachment of the tun device.
This patch solves the original race in a different way. Since
the race is only because the underlying memory gets freed, we
can prevent it simply by ensuring that we don't do that until
all tun descriptors ever attached to the device (even if they
have since be detached because they may still be sitting in poll)
have been closed.
This is done by using reference counting the attached tun file
descriptors. The refcount in tun->sk has been reappropriated
for this purpose since it was already being used for that, albeit
from the opposite angle.
Note that we no longer zero tfile->tun since tun_get will return
NULL anyway after the refcount on tfile hits zero. Instead it
represents whether this device has ever been attached to a device.
Signed-off-by: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index a1b0697..540f829 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -156,6 +156,7 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
tfile->tun = tun;
tun->tfile = tfile;
dev_hold(tun->dev);
+ sock_hold(tun->sk);
atomic_inc(&tfile->count);
out:
@@ -165,11 +166,8 @@ out:
static void __tun_detach(struct tun_struct *tun)
{
- struct tun_file *tfile = tun->tfile;
-
/* Detach from net device */
netif_tx_lock_bh(tun->dev);
- tfile->tun = NULL;
tun->tfile = NULL;
netif_tx_unlock_bh(tun->dev);
@@ -339,6 +337,13 @@ static void tun_net_uninit(struct net_device *dev)
}
}
+static void tun_free_netdev(struct net_device *dev)
+{
+ struct tun_struct *tun = netdev_priv(dev);
+
+ sock_put(tun->sk);
+}
+
/* Net device open. */
static int tun_net_open(struct net_device *dev)
{
@@ -810,7 +815,7 @@ static void tun_setup(struct net_device *dev)
tun->group = -1;
dev->ethtool_ops = &tun_ethtool_ops;
- dev->destructor = free_netdev;
+ dev->destructor = tun_free_netdev;
}
/* Trivial set of netlink ops to allow deleting tun or tap
@@ -847,7 +852,7 @@ static void tun_sock_write_space(struct sock *sk)
static void tun_sock_destruct(struct sock *sk)
{
- dev_put(container_of(sk, struct tun_sock, sk)->tun->dev);
+ free_netdev(container_of(sk, struct tun_sock, sk)->tun->dev);
}
static struct proto tun_proto = {
@@ -919,8 +924,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (!sk)
goto err_free_dev;
- /* This ref count is for tun->sk. */
- dev_hold(dev);
sock_init_data(&tun->socket, sk);
sk->sk_write_space = tun_sock_write_space;
sk->sk_destruct = tun_sock_destruct;
@@ -1275,20 +1278,18 @@ static int tun_chr_close(struct inode *inode, struct file *file)
struct tun_file *tfile = file->private_data;
struct tun_struct *tun = __tun_get(tfile);
-
if (tun) {
- DBG(KERN_INFO "%s: tun_chr_close\n", tun->dev->name);
-
- rtnl_lock();
- __tun_detach(tun);
-
/* If desireable, unregister the netdevice. */
- if (!(tun->flags & TUN_PERSIST)) {
- sock_put(tun->sk);
- unregister_netdevice(tun->dev);
- }
+ if (!(tun->flags & TUN_PERSIST))
+ unregister_netdev(tun->dev);
+ else
+ tun_put(tun);
+ } else
+ tun = tfile->tun;
- rtnl_unlock();
+ if (tun) {
+ DBG(KERN_INFO "%s: tun_chr_close\n", tun->dev->name);
+ sock_put(tun->sk);
}
put_net(tfile->net);
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related [flat|nested] 46+ messages in thread
* [2/2] tun: Fix sk_sleep races when attaching/detaching
[not found] ` <20090416110818.GA20950-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-16 11:09 ` Herbert Xu
[not found] ` <20090416110952.GB20950-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-16 11:09 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Thu, Apr 16, 2009 at 07:08:18PM +0800, Herbert Xu wrote:
>
> tun: Only free a netdev when all tun descriptors are closed
With that patch we can now safely move read_wait.
tun: Fix sk_sleep races when attaching/detaching
As the sk_sleep wait queue actually lives in tfile, which may be
detached from the tun device, bad things will happen when we use
sk_sleep after detaching.
Since the tun device is the persistent data structure here (when
requested by the user), it makes much more sense to have the wait
queue live there. There is no reason to have it in tfile at all
since the only time we can wait is if we have a tun attached.
In fact we already have a wait queue in tun_struct, so we might
as well use it.
Reported-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Tested-by: Christian Borntraeger <borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Tested-by: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
Signed-off-by: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 540f829..7cfe3d1 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -93,7 +93,6 @@ struct tun_file {
atomic_t count;
struct tun_struct *tun;
struct net *net;
- wait_queue_head_t read_wait;
};
struct tun_sock;
@@ -331,7 +330,7 @@ static void tun_net_uninit(struct net_device *dev)
/* Inform the methods they need to stop using the dev.
*/
if (tfile) {
- wake_up_all(&tfile->read_wait);
+ wake_up_all(&tun->socket.wait);
if (atomic_dec_and_test(&tfile->count))
__tun_detach(tun);
}
@@ -398,7 +397,7 @@ static int tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
/* Notify and wake up reader process */
if (tun->flags & TUN_FASYNC)
kill_fasync(&tun->fasync, SIGIO, POLL_IN);
- wake_up_interruptible(&tun->tfile->read_wait);
+ wake_up_interruptible(&tun->socket.wait);
return 0;
drop:
@@ -495,7 +494,7 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);
- poll_wait(file, &tfile->read_wait, wait);
+ poll_wait(file, &tun->socket.wait, wait);
if (!skb_queue_empty(&tun->readq))
mask |= POLLIN | POLLRDNORM;
@@ -767,7 +766,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
goto out;
}
- add_wait_queue(&tfile->read_wait, &wait);
+ add_wait_queue(&tun->socket.wait, &wait);
while (len) {
current->state = TASK_INTERRUPTIBLE;
@@ -798,7 +797,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
}
current->state = TASK_RUNNING;
- remove_wait_queue(&tfile->read_wait, &wait);
+ remove_wait_queue(&tun->socket.wait, &wait);
out:
tun_put(tun);
@@ -866,7 +865,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
struct sock *sk;
struct tun_struct *tun;
struct net_device *dev;
- struct tun_file *tfile = file->private_data;
int err;
dev = __dev_get_by_name(net, ifr->ifr_name);
@@ -924,11 +922,11 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (!sk)
goto err_free_dev;
+ init_waitqueue_head(&tun->socket.wait);
sock_init_data(&tun->socket, sk);
sk->sk_write_space = tun_sock_write_space;
sk->sk_destruct = tun_sock_destruct;
sk->sk_sndbuf = INT_MAX;
- sk->sk_sleep = &tfile->read_wait;
tun->sk = sk;
container_of(sk, struct tun_sock, sk)->tun = tun;
@@ -1268,7 +1266,6 @@ static int tun_chr_open(struct inode *inode, struct file * file)
atomic_set(&tfile->count, 0);
tfile->tun = NULL;
tfile->net = get_net(current->nsproxy->net_ns);
- init_waitqueue_head(&tfile->read_wait);
file->private_data = tfile;
return 0;
}
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [2/2] tun: Fix sk_sleep races when attaching/detaching
[not found] ` <20090416110952.GB20950-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-20 8:35 ` Herbert Xu
2009-04-20 9:26 ` David Miller
0 siblings, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-20 8:35 UTC (permalink / raw)
To: Eric W. Biederman
Cc: lguest-mnsaURCQ41sdnm+yROfE0A, Christian Borntraeger,
David S. Miller, virtualization-qjLDD68F18O7TbgM5vRIOg,
Matias Zabaljauregui, netdev-u79uwXL29TY76Z2rM5mHXA,
Patrick McHardy
On Thu, Apr 16, 2009 at 07:09:52PM +0800, Herbert Xu wrote:
>
> tun: Fix sk_sleep races when attaching/detaching
That patch doesn't apply anymore because of contextual changes
caused by the first patch. Here's an update.
tun: Fix sk_sleep races when attaching/detaching
As the sk_sleep wait queue actually lives in tfile, which may be
detached from the tun device, bad things will happen when we use
sk_sleep after detaching.
Since the tun device is the persistent data structure here (when
requested by the user), it makes much more sense to have the wait
queue live there. There is no reason to have it in tfile at all
since the only time we can wait is if we have a tun attached.
In fact we already have a wait queue in tun_struct, so we might
as well use it.
Reported-by: Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Tested-by: Christian Borntraeger <borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
Tested-by: Patrick McHardy <kaber-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
Signed-off-by: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 95ae40a..735bf41 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -93,7 +93,6 @@ struct tun_file {
atomic_t count;
struct tun_struct *tun;
struct net *net;
- wait_queue_head_t read_wait;
};
struct tun_sock;
@@ -331,7 +330,7 @@ static void tun_net_uninit(struct net_device *dev)
/* Inform the methods they need to stop using the dev.
*/
if (tfile) {
- wake_up_all(&tfile->read_wait);
+ wake_up_all(&tun->socket.wait);
if (atomic_dec_and_test(&tfile->count))
__tun_detach(tun);
}
@@ -398,7 +397,7 @@ static int tun_net_xmit(struct sk_buff *skb, struct net_device *dev)
/* Notify and wake up reader process */
if (tun->flags & TUN_FASYNC)
kill_fasync(&tun->fasync, SIGIO, POLL_IN);
- wake_up_interruptible(&tun->tfile->read_wait);
+ wake_up_interruptible(&tun->socket.wait);
return 0;
drop:
@@ -495,7 +494,7 @@ static unsigned int tun_chr_poll(struct file *file, poll_table * wait)
DBG(KERN_INFO "%s: tun_chr_poll\n", tun->dev->name);
- poll_wait(file, &tfile->read_wait, wait);
+ poll_wait(file, &tun->socket.wait, wait);
if (!skb_queue_empty(&tun->readq))
mask |= POLLIN | POLLRDNORM;
@@ -768,7 +767,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
goto out;
}
- add_wait_queue(&tfile->read_wait, &wait);
+ add_wait_queue(&tun->socket.wait, &wait);
while (len) {
current->state = TASK_INTERRUPTIBLE;
@@ -799,7 +798,7 @@ static ssize_t tun_chr_aio_read(struct kiocb *iocb, const struct iovec *iv,
}
current->state = TASK_RUNNING;
- remove_wait_queue(&tfile->read_wait, &wait);
+ remove_wait_queue(&tun->socket.wait, &wait);
out:
tun_put(tun);
@@ -867,7 +866,6 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
struct sock *sk;
struct tun_struct *tun;
struct net_device *dev;
- struct tun_file *tfile = file->private_data;
int err;
dev = __dev_get_by_name(net, ifr->ifr_name);
@@ -925,10 +923,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
if (!sk)
goto err_free_dev;
+ init_waitqueue_head(&tun->socket.wait);
sock_init_data(&tun->socket, sk);
sk->sk_write_space = tun_sock_write_space;
sk->sk_sndbuf = INT_MAX;
- sk->sk_sleep = &tfile->read_wait;
tun->sk = sk;
container_of(sk, struct tun_sock, sk)->tun = tun;
@@ -1270,7 +1268,6 @@ static int tun_chr_open(struct inode *inode, struct file * file)
atomic_set(&tfile->count, 0);
tfile->tun = NULL;
tfile->net = get_net(current->nsproxy->net_ns);
- init_waitqueue_head(&tfile->read_wait);
file->private_data = tfile;
return 0;
}
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related [flat|nested] 46+ messages in thread
* Re: [2/2] tun: Fix sk_sleep races when attaching/detaching
2009-04-20 8:35 ` Herbert Xu
@ 2009-04-20 9:26 ` David Miller
2009-04-20 9:35 ` Herbert Xu
0 siblings, 1 reply; 46+ messages in thread
From: David Miller @ 2009-04-20 9:26 UTC (permalink / raw)
To: herbert
Cc: ebiederm, kaber, zabaljauregui, odie, rusty, lguest,
virtualization, netdev, borntraeger
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 20 Apr 2009 16:35:50 +0800
> On Thu, Apr 16, 2009 at 07:09:52PM +0800, Herbert Xu wrote:
>>
>> tun: Fix sk_sleep races when attaching/detaching
>
> That patch doesn't apply anymore because of contextual changes
> caused by the first patch. Here's an update.
>
> tun: Fix sk_sleep races when attaching/detaching
Do you think these two patches are ready to go into net-2.6
now?
Thanks.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [2/2] tun: Fix sk_sleep races when attaching/detaching
2009-04-20 9:26 ` David Miller
@ 2009-04-20 9:35 ` Herbert Xu
2009-04-20 10:02 ` David Miller
0 siblings, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-20 9:35 UTC (permalink / raw)
To: David Miller
Cc: ebiederm, kaber, zabaljauregui, odie, rusty, lguest,
virtualization, netdev, borntraeger
On Mon, Apr 20, 2009 at 02:26:35AM -0700, David Miller wrote:
>
> Do you think these two patches are ready to go into net-2.6
> now?
I think so.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [2/2] tun: Fix sk_sleep races when attaching/detaching
2009-04-20 9:35 ` Herbert Xu
@ 2009-04-20 10:02 ` David Miller
0 siblings, 0 replies; 46+ messages in thread
From: David Miller @ 2009-04-20 10:02 UTC (permalink / raw)
To: herbert
Cc: ebiederm, kaber, zabaljauregui, odie, rusty, lguest,
virtualization, netdev, borntraeger
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Mon, 20 Apr 2009 17:35:49 +0800
> On Mon, Apr 20, 2009 at 02:26:35AM -0700, David Miller wrote:
>>
>> Do you think these two patches are ready to go into net-2.6
>> now?
>
> I think so.
Great, applied, thanks Herbert.
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [1/2] tun: Only free a netdev when all tun descriptors are closed
2009-04-16 11:08 ` [1/2] tun: Only free a netdev when all tun descriptors are closed Herbert Xu
[not found] ` <20090416110818.GA20950-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-24 8:55 ` Christian Borntraeger
[not found] ` <200904241055.49794.borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
1 sibling, 1 reply; 46+ messages in thread
From: Christian Borntraeger @ 2009-04-24 8:55 UTC (permalink / raw)
To: Herbert Xu
Cc: Eric W. Biederman, Patrick McHardy, Matias Zabaljauregui, odie,
Rusty Russell, lguest, virtualization, David S. Miller, netdev,
Carsten Otte
Am Thursday 16 April 2009 13:08:18 schrieb Herbert Xu:
> On Wed, Apr 15, 2009 at 10:38:34PM +0800, Herbert Xu wrote:
> >
> > So how about this? We replace the dev destructor with our own that
> > doesn't immediately call free_netdev. We only call free_netdev once
> > all tun fd's attached to the device have been closed.
>
> Here's the patch. I'd appreciate if everyone can review it
> and see if they can recreate the original race by
>
> 1) Starting a process using tun and polls on it;
> 2) Doing ip tun del tunXXX while the process is polling.
>
> tun: Only free a netdev when all tun descriptors are closed
>
> The commit c70f182940f988448f3c12a209d18b1edc276e33 ("tun: Fix
> races between tun_net_close and free_netdev") fixed a race where
> an asynchronous deletion of a tun device can hose a poll(2) on
> a tun fd attached to that device.
Sorry for the late reply, but this patch creates another regression:
Now TUNSETIFF returns EBUSY on a persistent tap device:
open("/dev/net/tun", O_RDWR) = 11
ioctl(11, 0x400454ca, 0x3ffff8e2270) = -1 EBUSY (Device or resource busy)
Some debugging (thanks to Carsten Otte) showed that
tun_set_iff calls tun_attach (the first call inside the if(dev)). tun_attach
now checks for tun->tfile but this is already set.
Looks like we need another fix on top :-(
Christian
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [1/2] tun: Only free a netdev when all tun descriptors are closed
[not found] ` <200904241055.49794.borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
@ 2009-04-24 12:11 ` Herbert Xu
[not found] ` <20090424121156.GA28039-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
0 siblings, 1 reply; 46+ messages in thread
From: Herbert Xu @ 2009-04-24 12:11 UTC (permalink / raw)
To: Christian Borntraeger
Cc: Carsten Otte, lguest-mnsaURCQ41sdnm+yROfE0A, David S. Miller,
virtualization-qjLDD68F18O7TbgM5vRIOg, Matias Zabaljauregui,
Eric W. Biederman, netdev-u79uwXL29TY76Z2rM5mHXA, Patrick McHardy
On Fri, Apr 24, 2009 at 10:55:49AM +0200, Christian Borntraeger wrote:
> Am Thursday 16 April 2009 13:08:18 schrieb Herbert Xu:
>
> > Here's the patch. I'd appreciate if everyone can review it
> > and see if they can recreate the original race by
> >
> > 1) Starting a process using tun and polls on it;
> > 2) Doing ip tun del tunXXX while the process is polling.
> >
> > tun: Only free a netdev when all tun descriptors are closed
> >
> > The commit c70f182940f988448f3c12a209d18b1edc276e33 ("tun: Fix
> > races between tun_net_close and free_netdev") fixed a race where
> > an asynchronous deletion of a tun device can hose a poll(2) on
> > a tun fd attached to that device.
>
> Sorry for the late reply, but this patch creates another regression:
> Now TUNSETIFF returns EBUSY on a persistent tap device:
>
> open("/dev/net/tun", O_RDWR) = 11
> ioctl(11, 0x400454ca, 0x3ffff8e2270) = -1 EBUSY (Device or resource busy)
The patch you qouted has been superceded by many versions :)
Can you please test the latest that's in davem's tree?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 46+ messages in thread
* Re: [1/2] tun: Only free a netdev when all tun descriptors are closed
[not found] ` <20090424121156.GA28039-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
@ 2009-04-24 12:40 ` Christian Borntraeger
0 siblings, 0 replies; 46+ messages in thread
From: Christian Borntraeger @ 2009-04-24 12:40 UTC (permalink / raw)
To: Herbert Xu
Cc: Carsten Otte, lguest-mnsaURCQ41sdnm+yROfE0A, David S. Miller,
virtualization-qjLDD68F18O7TbgM5vRIOg, Matias Zabaljauregui,
Eric W. Biederman, netdev-u79uwXL29TY76Z2rM5mHXA, Patrick McHardy
Am Friday 24 April 2009 14:11:56 schrieb Herbert Xu:
> The patch you qouted has been superceded by many versions :)
Yes, I got lost in this mail thread...
> Can you please test the latest that's in davem's tree?
Done. With
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fdavem%2Fnet-2.6.git;a=commitdiff_plain;h=9c3fea6ab04a7bd9298e635bf29b4a5379f6c476
http://git.kernel.org/?p=linux%2Fkernel%2Fgit%2Fdavem%2Fnet-2.6.git;a=commitdiff_plain;h=c40af84a6726f63e35740d26f841992e8f31f92c
Everything works fine. Thank you and sorry for the noise.
Christian
^ permalink raw reply [flat|nested] 46+ messages in thread
end of thread, other threads:[~2009-04-24 12:40 UTC | newest]
Thread overview: 46+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-03-26 23:52 [PATCH 4/5] lguest: use KVM hypercalls Rusty Russell
2009-04-02 21:55 ` [Lguest] " Simon Holm Thøgersen
[not found] ` <1238709324.5823.8.camel-78RDdhuQolGs1BDpvl8NfQ@public.gmane.org>
2009-04-02 23:37 ` Matias Zabaljauregui
2009-04-03 9:28 ` Simon Holm Thøgersen
2009-04-05 13:04 ` Rusty Russell
[not found] ` <200904052234.48483.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2009-04-06 6:56 ` Simon Holm Thøgersen
2009-04-08 16:24 ` [Lguest] " Patrick McHardy
[not found] ` <1239043798.27826.93.camel@zetabook>
[not found] ` <200904081021.39877.rusty@rustcorp.com.au>
[not found] ` <200904081021.39877.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2009-04-08 20:58 ` Matias Zabaljauregui
2009-04-09 10:32 ` Simon Holm Thøgersen
[not found] ` <1239273165.5687.10.camel-78RDdhuQolGs1BDpvl8NfQ@public.gmane.org>
2009-04-13 16:25 ` Matias Zabaljauregui
2009-04-15 8:42 ` Rusty Russell
[not found] ` <200904151812.23318.rusty-8n+1lVoiYb80n/F98K4Iww@public.gmane.org>
2009-04-15 14:55 ` Matias Zabaljauregui
2009-04-09 12:24 ` Patrick McHardy
[not found] ` <49DDE91A.8060603-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2009-04-09 13:20 ` Patrick McHardy
2009-04-09 13:59 ` [Lguest] " Eric W. Biederman
[not found] ` <m1bpr6hqrm.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-14 11:54 ` Patrick McHardy
[not found] ` <49E47976.8020005-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2009-04-14 17:10 ` Eric W. Biederman
2009-04-15 8:36 ` [Lguest] " Herbert Xu
[not found] ` <20090415083610.GA8579-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-15 8:47 ` Herbert Xu
2009-04-15 9:07 ` [Lguest] " Christian Borntraeger
2009-04-15 11:07 ` Patrick McHardy
2009-04-15 13:23 ` Eric W. Biederman
[not found] ` <m18wm2rqy6.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-15 13:28 ` Herbert Xu
[not found] ` <20090415132802.GA11408-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-15 13:35 ` Eric W. Biederman
[not found] ` <m1skkaox8h.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-15 13:46 ` Herbert Xu
[not found] ` <20090415134610.GA11683-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-15 13:55 ` Herbert Xu
[not found] ` <20090415135502.GA11827-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-15 14:10 ` Eric W. Biederman
[not found] ` <m1ocuynh2f.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-15 14:12 ` Herbert Xu
2009-04-15 14:06 ` [Lguest] " Eric W. Biederman
[not found] ` <m11vruovu5.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-15 14:08 ` Herbert Xu
[not found] ` <20090415140819.GA11991-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-15 14:18 ` Eric W. Biederman
[not found] ` <m1iql6m24b.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-15 14:23 ` Herbert Xu
2009-04-15 14:38 ` Herbert Xu
[not found] ` <20090415143834.GA12384-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-15 14:56 ` Eric W. Biederman
[not found] ` <m1zleiklsl.fsf-+imSwln9KH6u2/kzUuoCbdi2O/JbrIOy@public.gmane.org>
2009-04-15 22:27 ` Herbert Xu
2009-04-16 11:08 ` [1/2] tun: Only free a netdev when all tun descriptors are closed Herbert Xu
[not found] ` <20090416110818.GA20950-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-16 11:09 ` [2/2] tun: Fix sk_sleep races when attaching/detaching Herbert Xu
[not found] ` <20090416110952.GB20950-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-20 8:35 ` Herbert Xu
2009-04-20 9:26 ` David Miller
2009-04-20 9:35 ` Herbert Xu
2009-04-20 10:02 ` David Miller
2009-04-24 8:55 ` [1/2] tun: Only free a netdev when all tun descriptors are closed Christian Borntraeger
[not found] ` <200904241055.49794.borntraeger-tA70FqPdS9bQT0dZR+AlfA@public.gmane.org>
2009-04-24 12:11 ` Herbert Xu
[not found] ` <20090424121156.GA28039-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2009-04-24 12:40 ` Christian Borntraeger
[not found] ` <49DDF614.1060909-dcUjhNyLwpNeoWH0uzbU5w@public.gmane.org>
2009-04-13 16:29 ` [PATCH 4/5] lguest: use KVM hypercalls Matias Zabaljauregui
2009-04-14 11:55 ` Patrick McHardy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).