Re: [PATCH] tipc: checking returns and Re: Possible Circular Locking in TIPC
On Thu, Jan 04, 2007 at 04:16:20PM +, Jon Maloy wrote:
> Regards
> ///jon
>
> Jarek Poplawski wrote:
>
> >
> >I know lockdep is sometimes
> >too careful but nevertheless some change is needed
> >to fix a real bug or give additional information
> >to lockdep.
> >
> >
> I don't know lockdep well enough yet, but I will try to find out if that
> is possible.
If you are sure there is no circular locking possible
between these two functions and this entry->lock here
isn't endangered by other functions, you could try to
make lockdep "silent" like this:
write_lock_bh(&ref_table_lock);
if (tipc_ref_table.first_free) {
index = tipc_ref_table.first_free;
entry = &(tipc_ref_table.entries[index]);
index_mask = tipc_ref_table.index_mask;
/* take lock in case a previous user of entry still holds it */
-spin_lock_bh(&entry->lock, );
+ local_bh_disable();
+ spin_lock_nested(&entry->lock, SINGLE_DEPTH_NESTING);
next_plus_upper = entry->data.next_plus_upper;
tipc_ref_table.first_free = next_plus_upper & index_mask;
reference = (next_plus_upper & ~index_mask) + index;
entry->data.reference = reference;
entry->object = object;
if (lock != 0)
*lock = &entry->lock;
/* may stay as is or: */
-spin_unlock_bh(&entry->lock);
+ spin_unlock(&entry->lock);
+ local_bh_enable();
}
write_unlock_bh(&ref_table_lock);
Cheers,
Jarek P.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/9] KVM: Simplify mmu_alloc_roots()
From: Ingo Molnar <[EMAIL PROTECTED]> Small optimization/cleanup: page == page_header(page->page_hpa) Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> Index: linux-2.6/drivers/kvm/mmu.c === --- linux-2.6.orig/drivers/kvm/mmu.c +++ linux-2.6/drivers/kvm/mmu.c @@ -820,9 +820,9 @@ static void mmu_alloc_roots(struct kvm_v hpa_t root = vcpu->mmu.root_hpa; ASSERT(!VALID_PAGE(root)); - root = kvm_mmu_get_page(vcpu, root_gfn, 0, - PT64_ROOT_LEVEL, 0, NULL)->page_hpa; - page = page_header(root); + page = kvm_mmu_get_page(vcpu, root_gfn, 0, + PT64_ROOT_LEVEL, 0, NULL); + root = page->page_hpa; ++page->root_count; vcpu->mmu.root_hpa = root; return; @@ -836,10 +836,10 @@ static void mmu_alloc_roots(struct kvm_v root_gfn = vcpu->pdptrs[i] >> PAGE_SHIFT; else if (vcpu->mmu.root_level == 0) root_gfn = 0; - root = kvm_mmu_get_page(vcpu, root_gfn, i << 30, + page = kvm_mmu_get_page(vcpu, root_gfn, i << 30, PT32_ROOT_LEVEL, !is_paging(vcpu), - NULL)->page_hpa; - page = page_header(root); + NULL); + root = page->page_hpa; ++page->root_count; vcpu->mmu.pae_root[i] = root | PT_PRESENT_MASK; } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/9] KVM: Make loading cr3 more robust
From: Ingo Molnar <[EMAIL PROTECTED]> Prevent the guest's loading of a corrupt cr3 (pointing at no guest phsyical page) from crashing the host. Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]> Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> Index: linux-2.6/drivers/kvm/kvm_main.c === --- linux-2.6.orig/drivers/kvm/kvm_main.c +++ linux-2.6/drivers/kvm/kvm_main.c @@ -463,7 +463,19 @@ void set_cr3(struct kvm_vcpu *vcpu, unsi vcpu->cr3 = cr3; spin_lock(&vcpu->kvm->lock); - vcpu->mmu.new_cr3(vcpu); + /* +* Does the new cr3 value map to physical memory? (Note, we +* catch an invalid cr3 even in real-mode, because it would +* cause trouble later on when we turn on paging anyway.) +* +* A real CPU would silently accept an invalid cr3 and would +* attempt to use it - with largely undefined (and often hard +* to debug) behavior on the guest side. +*/ + if (unlikely(!gfn_to_memslot(vcpu->kvm, cr3 >> PAGE_SHIFT))) + inject_gp(vcpu); + else + vcpu->mmu.new_cr3(vcpu); spin_unlock(&vcpu->kvm->lock); } EXPORT_SYMBOL_GPL(set_cr3); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/9] KVM: MMU: Add missing dirty bit
If we emulate a write, we fail to set the dirty bit on the guest pte, leading
the guest to believe the page is clean, and thus lose data. Bad.
Fix by setting the guest pte dirty bit under such conditions.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/kvm/paging_tmpl.h
===
--- linux-2.6.orig/drivers/kvm/paging_tmpl.h
+++ linux-2.6/drivers/kvm/paging_tmpl.h
@@ -317,6 +317,7 @@ static int FNAME(fix_write_pf)(struct kv
} else if (kvm_mmu_lookup_page(vcpu, gfn)) {
pgprintk("%s: found shadow page for %lx, marking ro\n",
__FUNCTION__, gfn);
+ *guest_ent |= PT_DIRTY_MASK;
*write_pt = 1;
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/9] KVM: Add missing 'break'
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> Index: linux-2.6/drivers/kvm/kvm_main.c === --- linux-2.6.orig/drivers/kvm/kvm_main.c +++ linux-2.6/drivers/kvm/kvm_main.c @@ -1922,6 +1922,7 @@ static long kvm_dev_ioctl(struct file *f num_msrs_to_save * sizeof(u32))) goto out; r = 0; + break; } default: ; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/9] KVM: Don't set guest cr3 from vmx_vcpu_setup()
It overwrites the right cr3 set from mmu setup. Happens only with the test harness. Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> Index: linux-2.6/drivers/kvm/vmx.c === --- linux-2.6.orig/drivers/kvm/vmx.c +++ linux-2.6/drivers/kvm/vmx.c @@ -1027,8 +1027,6 @@ static int vmx_vcpu_setup(struct kvm_vcp vmcs_writel(GUEST_RIP, 0xfff0); vmcs_writel(GUEST_RSP, 0); - vmcs_writel(GUEST_CR3, 0); - //todo: dr0 = dr1 = dr2 = dr3 = 0; dr6 = 0x0ff0 vmcs_writel(GUEST_DR7, 0x400); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/9] KVM: Avoid oom on cr3 switch
From: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/kvm/mmu.c
===
--- linux-2.6.orig/drivers/kvm/mmu.c
+++ linux-2.6/drivers/kvm/mmu.c
@@ -905,6 +905,8 @@ static void paging_new_cr3(struct kvm_vc
{
pgprintk("%s: cr3 %lx\n", __FUNCTION__, vcpu->cr3);
mmu_free_roots(vcpu);
+ if (unlikely(vcpu->kvm->n_free_mmu_pages < KVM_MIN_FREE_MMU_PAGES))
+ kvm_mmu_free_some_pages(vcpu);
mmu_alloc_roots(vcpu);
kvm_mmu_flush_tlb(vcpu);
kvm_arch_ops->set_cr3(vcpu, vcpu->mmu.root_hpa);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/9] KVM: Initialize vcpu->kvm a little earlier
Fixes oops on early close of /dev/kvm. Signed-off-by: Avi Kivity <[EMAIL PROTECTED]> Index: linux-2.6/drivers/kvm/kvm_main.c === --- linux-2.6.orig/drivers/kvm/kvm_main.c +++ linux-2.6/drivers/kvm/kvm_main.c @@ -230,6 +230,7 @@ static int kvm_dev_open(struct inode *in struct kvm_vcpu *vcpu = &kvm->vcpus[i]; mutex_init(&vcpu->mutex); + vcpu->kvm = kvm; vcpu->mmu.root_hpa = INVALID_PAGE; INIT_LIST_HEAD(&vcpu->free_pages); } @@ -530,7 +531,6 @@ static int kvm_dev_ioctl_create_vcpu(str vcpu->guest_fx_image = vcpu->host_fx_image + FX_IMAGE_SIZE; vcpu->cpu = -1; /* First load will set up TR */ - vcpu->kvm = kvm; r = kvm_arch_ops->vcpu_create(vcpu); if (r < 0) goto out_free_vcpus; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/9] KVM: Improve reporting of vmwrite errors
This will allow us to see the root cause when a vmwrite error happens.
Signed-off-by: Avi Kivity <[EMAIL PROTECTED]>
Index: linux-2.6/drivers/kvm/vmx.c
===
--- linux-2.6.orig/drivers/kvm/vmx.c
+++ linux-2.6/drivers/kvm/vmx.c
@@ -152,15 +152,21 @@ static u64 vmcs_read64(unsigned long fie
#endif
}
+static noinline void vmwrite_error(unsigned long field, unsigned long value)
+{
+ printk(KERN_ERR "vmwrite error: reg %lx value %lx (err %d)\n",
+ field, value, vmcs_read32(VM_INSTRUCTION_ERROR));
+ dump_stack();
+}
+
static void vmcs_writel(unsigned long field, unsigned long value)
{
u8 error;
asm volatile (ASM_VMX_VMWRITE_RAX_RDX "; setna %0"
: "=q"(error) : "a"(value), "d"(field) : "cc" );
- if (error)
- printk(KERN_ERR "vmwrite error: reg %lx value %lx (err %d)\n",
- field, value, vmcs_read32(VM_INSTRUCTION_ERROR));
+ if (unlikely(error))
+ vmwrite_error(field, value);
}
static void vmcs_write16(unsigned long field, u16 value)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/9] KVM: Flush out my patch queue
This patchset is mostly fallout from the mmu stuff that I've neglected to integrate with the main patchset sent yesterday. It includes a fashionable missing dirty bit fix, and other fixes and cleanups. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.16.29 1/1] memory: enhance Linux swap subsystem
A new patch has been done by me, based on the previous quilt patch
(2.6.16.29). Here is
changelog
--
NEW
New kernel thread kppsd is added to execute background scanning task
periodically (mm/vmscan.c).
PPS statistic is added into /proc/meminfo, its prototype is in
include/linux/mm.h.
Documentation/vm_pps.txt is also updated to show the aboved two new features,
some sections is re-written for comprehension.
BUG
New loop code is introduced in shrink_private_vma (mm/vmscan.c) and
pps_swapoff (mm/swapfile.c), contrast with old code, even lhtemp is freed
during loop, it's also safe.
A bug is catched in mm/memory.c:zap_pte_range -- if a PrivatePage is
being written back, it will be migrated back to Linux legacy page system.
A fault done by me in previous patch is remedied in stage 5, now stage 5 can
work.
MISCELLANEOUS
UP code has been separated from SMP code in dftlb.
--
Index: linux-2.6.16.29/Documentation/vm_pps.txt
===
--- linux-2.6.16.29.orig/Documentation/vm_pps.txt 2007-01-04
14:47:35.0 +0800
+++ linux-2.6.16.29/Documentation/vm_pps.txt2007-01-04 14:49:36.0
+0800
@@ -6,11 +6,11 @@
// Purpose <([{
The file is used to document the idea which is published firstly at
http://www.ussg.iu.edu/hypermail/linux/kernel/0607.2/0451.html, as a part of my
-OS -- main page http://blog.chinaunix.net/u/21764/index.php. In brief, a patch
-of the document to enchance the performance of Linux swap subsystem. You can
-find the overview of the idea in section and how I patch it into Linux 2.6.16.29 in section .
+OS -- main page http://blog.chinaunix.net/u/21764/index.php. In brief, the
+patch of the document is for enchancing the performance of Linux swap
+subsystem. You can find the overview of the idea in section and how I patch it into Linux 2.6.16.29 in section
+.
// }])>
// How to Reclaim Pages more Efficiently <([{
@@ -21,7 +21,9 @@
OK! to modern OS, its memory subsystem can be divided into three layers
1) Space layer (InodeSpace, UserSpace and CoreSpace).
2) VMA layer (PrivateVMA and SharedVMA, memory architecture-independent layer).
-3) PTE and page layer (architecture-dependent).
+3) PTE, zone/memory inode layer (architecture-dependent).
+4) Maybe it makes you sense that Page should be placed on the 3rd layer, but
+ here, it's placed on the 2nd layer since it's the basic unit of VMA.
Since the 2nd layer assembles the much statistic of page-acess information, so
it's nature that swap subsystem should be deployed and implemented on the 2nd
@@ -41,7 +43,8 @@
Unfortunately, Linux 2.6.16.29 swap subsystem is based on the 3rd layer -- a
system on zone::active_list/inactive_list.
-I've finished a patch, see section .
Note, it ISN'T perfect.
+I've finished a patch, see section . Note, it
+ISN'T perfect.
// }])>
// Pure Private Page System -- pps <([{
@@ -70,7 +73,18 @@
3) -- how private pages enter in/go off pps.
4) which VMA is belonging to pps.
-PPS uses init_mm.mm_list list to enumerate all swappable UserSpace.
+PPS uses init_mm.mm_list list to enumerate all swappable UserSpace
+(shrink_private_vma).
+
+A new kernel thread -- kppsd is introduced in mm/vmscan.c, its task is to
+execute the stages of pps periodically, note an appropriate timeout ticks is
+necessary so we can give application a chance to re-map back its PrivatePage
+from UnmappedPTE to PTE, that is, show their conglomeration affinity.
+scan_control::pps_cmd field is used to control the behavior of kppsd, = 1 for
+accelerating scanning process and reclaiming pages, it's used in balance_pgdat.
+
+PPS statistic data is appended to /proc/meminfo entry, its prototype is in
+include/linux/mm.h.
I'm also glad to highlight my a new idea -- dftlb which is described in
section .
@@ -97,15 +111,19 @@
gone when a CPU starts to execute the task in timer interrupt, so don't use
dftlb.
combine stage 1 with stage 2, and send IPI immediately in fill_in_tlb_tasks.
+
+dftlb increases mm_struct::mm_users to prevent the mm from being freed when
+other CPU works on it.
// }])>
// Stage Definition <([{
The whole process of private page page-out is divided into six stages, as
-showed in shrink_pvma_scan_ptes of mm/vmscan.c
+showed in shrink_pvma_scan_ptes of mm/vmscan.c, the code groups the similar
+pages to a series.
1) PTE to untouched PTE (access bit is cleared), append flushing
tasks to dftlb.
2) Convert untouched PTE to UnmappedPTE.
3) Link SwapEntry to every UnmappedPTE.
-4) Synchronize the page of a UnmappedPTE with its physical swap page.
+4) Flush PrivatePage of UnmappedPTE to its disk SwapPage.
5) Reclaimed the page and shift UnmappedPTE to SwappedPTE.
6) SwappedPTE stage.
// }])>
@@ -114,7 +132,15 @@
New VMA flag (VM_PURE_PRIVATE) is appended into VMA in include/linux/mm.h.
New PTE type (UnmappedPTE) is appended into PTE system in
-include/asm-i386/pgtable.h.
+include/asm-i386/pgtable.h. Its prototyp
Re: NCPFS and brittle connections
Pierre Ossman wrote: Petr Vandrovec wrote: Nobody is working on it (at least to my knowledge), and to me it is feature - it always worked this way, like smbfs did back in the past - if you send signal 9 to process using mount point, and there is some transaction in progress, nobody can correctly finish that transaction anymore. Fixing it would require non-trivial amount of code, and given that NCP itself is more or less dead protocol I do not feel that it is necessary. Someone needs to tell our customers then so they'll stop using it. :) When I asked at Brainshare 2001 when support for files over 4GB files will be added to NCP, they told me that I should switch to CIFS or NFS... Years after that confirmed it - only NW6.5SP3 finally got NCPs to support for files over 4GB, although you could have such files even on NW5. If you want to fix it, feel free. Culprit is RQ_INPROGRESS handling in ncp_abort_request - it just aborts whole connection so it does not have to provide temporary buffers and special handling for reply - as buffers currently specified as reply buffers are owned by caller, so after aborting request you cannot use them anymore. Do you have any pointers to how it was solved with smbfs? Relevant patches perhaps? Provided a similar solution can be applied here. I believe it was fixed when smbiod was introduced. When find_request() returns failure, it simple throws away data received from network. Unfortunately NCP does not run on top of TCP stream, but on top of IPX/UDP, and so dropping reply is not sufficient - you must continue resending request (so you must buffer it somewhere...) until you get result from server - after you receive answer from server, you can finally throw away both request & reply, and move on. Petr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.16.29 1/1] memory: enhance Linux swap subsystem
No, a new idea to re-write swap subsystem at all. In fact, it's an impossible task to me, so I provide a compromising solution -- pps (pure private page system). 2006/12/30, Zhou Yingchao <[EMAIL PROTECTED]>: 2006/12/27, yunfeng zhang <[EMAIL PROTECTED]>: > To multiple address space, multiple memory inode architecture, we can introduce > a new core object -- section which has several features Do you mean "in-memory inode" or "memory node(pglist_data)" by "memory inode" ? > The idea issued by me is whether swap subsystem should be deployed on layer 2 or > layer 3 which is described in Documentation/vm_pps.txt of my patch. To multiple > memory inode architecture, the special memory model should be encapsulated on > layer 3 (architecture-dependent), I think. I guess that you are wanting to do something to remove arch-dependent code in swap subsystem. Just like the pud introduced in the page-table related codes. Is it right? However, you should verify that your changes will not deteriorate system performance. Also, you need to maintain it for a long time with the evolution of mainline kernel before it is accepted. Best regards -- Yingchao Zhou *** Institute Of Computing Technology Chinese Academy of Sciences *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi kernel tree support on the same distro?
Steve Brueggeman wrote: There are some difficulties with gcc versions between linux-2.4 and linux-2.6, but I do not recall all of the details off of the top of my head. If I recall correctly, one of the issues is, linux-2.4 ?prefers? gcc-2.96, while newer linux-2.6 support/prefer gcc-3.? or greater. gcc 3.4.x works great on both 2.6 and 2.4, no issues whatsoever. At any rate, what I've done is create a chroot environment. I created this chroot directory by installing an older distribution that was created with linux-2.4 in mind (example, RedHat v8.2) into that at chroot directory. The easiest way to do this that I'm aware of is to install the older distribution (minimal development, no server junk, no X junk) on another computer, then copy from that computer to a directory on your development computer. it's even easier to not do that and install and compile everything in one rootfs, which is perfectly possible and I have done so many times. You can leave away the chroot and any possible security issues that you fear, allthough those are pretty much nonexistant. The only real bottom line issue is that module-init-tools cannot load modules on a 2.4 kernel, and modutils doesn't do that on 2.6, so you will have to switch or wrap them to detect the running kernel. The same goes for udev vs. devfs. of course, setting up a qemu image or separate partition is easier, but that was not the question I think. Most binary distro's won't support this, but I think all of the source distro's and more specific ones support it and a few handle it out of the box. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 4/4 block: explicit plugging
On Thu, Jan 04 2007, Nick Piggin wrote: > Jens Axboe wrote: > >Nick writes: > > > >This is a patch to perform block device plugging explicitly in the > >submitting > >process context rather than implicitly by the block device. > > Hi Jens, > > Hey thanks for doing so much hard work with this, I couldn't have fixed > all the block layer stuff myself. QRCU looks like a good solution for the > barrier/sync operations (/me worried that one wouldn't exist), and a > novel use of RCU! > > The only thing I had been thinking about before it is ready for primetime > -- as far as the VM side of things goes -- is whether we should change > the hard calls to address_space operations, such that they might be > avoided or customised when there is no backing block device? > > I'm sure the answer to this is "yes", so I have an idea for a simple > implementation... but I'd like to hear thoughts from network fs / raid > people? I suppose that would be the proper thing to do, for non __make_request() operated backing devices. I'll add the hooks, then we can cook up a raid implementation if need be. -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] TTY_IO: Remove unnecessary kmalloc casts
On Fri, Jan 05, 2007 at 01:56:09AM -0500, Robert P. J. Day wrote: > On Fri, 5 Jan 2007, Ahmed S. Darwish wrote: > > > Remove unnecessary kmalloc casts in drivers/char/tty_io.c > > rather than remove these casts a file or two at a time, why not just > do them all at once and submit a single patch? there aren't that many > of them: OK, Thanks for the tip .. -- Ahmed S. Darwish http://darwish-07.blogspot.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc3] TTY_IO: Remove unnecessary kmalloc casts
On Fri, 5 Jan 2007, Ahmed S. Darwish wrote:
> Remove unnecessary kmalloc casts in drivers/char/tty_io.c
rather than remove these casts a file or two at a time, why not just
do them all at once and submit a single patch? there aren't that many
of them:
grep -Er "\([^\)\*]+\*\) ?k[cmz]alloc ?\(" .
rday
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
On Fri, Jan 05 2007, Suparna Bhattacharya wrote: > On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote: > > On Thu, 4 Jan 2007 10:26:21 +0530 > > Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > > > > > On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote: > > > > On Thu, 28 Dec 2006 13:53:08 +0530 > > > > Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > > > > > > > > > This patchset implements changes to make filesystem AIO read > > > > > and write asynchronous for the non O_DIRECT case. > > > > > > > > Unfortunately the unplugging changes in Jen's block tree have trashed > > > > these > > > > patches to a degree that I'm not confident in my repair attempts. So > > > > I'll > > > > drop the fasio patches from -mm. > > > > > > I took a quick look and the conflicts seem pretty minor to me, the > > > unplugging > > > changes mostly touch nearby code. > > > > Well... the conflicts (both mechanical and conceptual) are such that a > > round of retesting is needed. > > > > > Please let know how you want this fixed up. > > > > > > >From what I can tell the comments in the unplug patches seem to say that > > > it needs more work and testing, so perhaps a separate fixup patch may be > > > a better idea rather than make the fsaio patchset dependent on this. > > > > Patches against next -mm would be appreciated, please. Sorry about that. > > > > I _assume_ Jens is targetting 2.6.21? > > When is the next -mm likely to be out ? > > I was considering regenerating the blk unplug patches against the > fsaio changes instead of the other way around, if Jens were willing to > accept that. But if the next -mm is just around the corner then its > not an issue. I don't really care much, but I work against mainline and anything but occasional one-off generations of a patch against a different base is not very likely. The -mm order should just reflect the merge order of the patches, what is the fsaio target? -- Jens Axboe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 0/8] user ns: Introduction
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> Quoting Andrew Morton ([EMAIL PROTECTED]):
> > On Thu, 4 Jan 2007 12:06:35 -0600
> > "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> >
> > > This patchset adds a user namespace, which allows a process to
> > > unshare its user_struct table, allowing for separate accounting
> > > per user namespace.
> >
> > With these patches applied and with CONFIG_USER_NS=n, my selinux-enabled
> > standard FC5 machine throws a complete fit:
...
> >
> > Setting CONFIG_USER_NS=y fixes this.
>
> Ok, I see. The CONFIG_USER_NS split is absolutely horrible. Should
> really get rid of the user_ns pointers altogether when !CONFIG_USER_NS.
> I'll try to fix it up without putting ifdefs all over - planning to send
> a patch tomorrow.
Actually it's not that bad. Following patch fixes what I believe is
the underlying problem, and in any case was a definite bug.
thanks,
-serge
From: Serge E. Hallyn <[EMAIL PROTECTED]>
Subject: [PATCH 1/1] user ns: fix !CONFIG_USER_NS mount denial
Don't do user_ns permission checks when !CONFIG_USER_NS.
Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
---
fs/namespace.c |6 ++
include/linux/sched.h |8
include/linux/user_namespace.h | 15 +++
3 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/fs/namespace.c b/fs/namespace.c
index 2ed89d4..664c6f2 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -236,10 +236,8 @@ static struct vfsmount *clone_mnt(struct
struct super_block *sb = old->mnt_sb;
struct vfsmount *mnt;
- if (!(old->mnt_flags & MNT_SHARE_NS)) {
- if (old->mnt_user_ns != current->nsproxy->user_ns)
- return ERR_PTR(-EPERM);
- }
+ if (!clone_mnt_userns_permission(old))
+ return ERR_PTR(-EPERM);
mnt = alloc_vfsmnt(old->mnt_devname);
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 55ecf81..0542f34 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1588,6 +1588,7 @@ extern int cond_resched(void);
extern int cond_resched_lock(spinlock_t * lock);
extern int cond_resched_softirq(void);
+#ifdef CONFIG_USER_NS
/*
* Check whether a task and a vfsmnt belong to the same uidns.
* Since the initial namespace is exempt from these checks,
@@ -1606,6 +1607,13 @@ static inline int task_mnt_same_uidns(st
return 1;
return 0;
}
+#else
+static inline int task_mnt_same_uidns(struct task_struct *tsk,
+ struct vfsmount *mnt)
+{
+ return 1;
+}
+#endif
/*
diff --git a/include/linux/user_namespace.h b/include/linux/user_namespace.h
index be3e484..e4ce9cb 100644
--- a/include/linux/user_namespace.h
+++ b/include/linux/user_namespace.h
@@ -35,6 +35,16 @@ static inline void put_user_ns(struct us
kref_put(&ns->kref, free_user_ns);
}
+static inline int clone_mnt_userns_permission(struct vfsmount *old)
+{
+ if (!(old->mnt_flags & MNT_SHARE_NS)) {
+ if (old->mnt_user_ns != current->nsproxy->user_ns)
+ return 0;
+ }
+
+ return 1;
+}
+
#else
static inline struct user_namespace *get_user_ns(struct user_namespace *ns)
@@ -59,6 +69,11 @@ static inline int copy_user_ns(int flags
static inline void put_user_ns(struct user_namespace *ns)
{
}
+
+static inline int clone_mnt_userns_permission(struct vfsmount *old)
+{
+ return 1;
+}
#endif
#endif /* _LINUX_USER_H */
--
1.4.1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: open(O_DIRECT) on a tmpfs?
Hugh Dickins wrote on Thursday, January 04, 2007 11:14 AM
> On Thu, 4 Jan 2007, Hua Zhong wrote:
> > So I'd argue that it makes more sense to support O_DIRECT
> > on tmpfs as the memory IS the backing store.
>
> A few more voices in favour and I'll be persuaded. Perhaps I'm
> out of date: when O_DIRECT came in, just a few filesystems supported
> it, and it was perfectly normal for open O_DIRECT to be failed; but
> I wouldn't want tmpfs to stand out now as a lone obstacle.
Maybe a bit hackish, all we need is to have an empty .direct_IO method
in shmem_aops to make __dentry_open() to pass the O_DIRECT check. The
following patch adds 40 bytes to kernel text on x86-64. An even more
hackish but zero cost route is to make .direct_IO variable non-zero via
a cast of -1 or some sort (that is probably ugly as hell).
diff -Nurp linus-2.6.git/mm/shmem.c linus-2.6.git.ken/mm/shmem.c
--- linus-2.6.git/mm/shmem.c2006-12-27 19:06:11.0 -0800
+++ linus-2.6.git.ken/mm/shmem.c2007-01-04 21:03:14.0 -0800
@@ -2314,10 +2314,18 @@ static void destroy_inodecache(void)
kmem_cache_destroy(shmem_inode_cachep);
}
+ssize_t shmem_direct_IO(int rw, struct kiocb *iocb, const struct iovec *iov,
+ loff_t offset, unsigned long nr_segs)
+{
+ /* dummy direct_IO function. Not to be executed */
+ BUG();
+}
+
static const struct address_space_operations shmem_aops = {
.writepage = shmem_writepage,
.set_page_dirty = __set_page_dirty_nobuffers,
#ifdef CONFIG_TMPFS
+ .direct_IO = shmem_direct_IO,
.prepare_write = shmem_prepare_write,
.commit_write = simple_commit_write,
#endif
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: JMicron JMB363 problems
xt knight wrote: I've been receiving odd error messages (accompanied by freezing up) over the days. They are originating from the JMicron controller. Setup: Gigabyte GA-965P-DS3 (Intel 965P Express) rev 2.0, latest BIOS (F9) -Intel ICH8 on-board [IDE emulation mode] --250G Maxtor SATA -- /dev/sda --250G Western Digital SATA -- /dev/sdb -JMicron JBM363 on-board [IDE mode] --Toshiba-Samsung DVD burner IDE (primary) -- /dev/hde --HP DVD burner IDE (slave) -- /dev/hdf Have you tried running this controller with the libata driver in AHCI mode? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20-rc3] TTY_IO: Remove unnecessary kmalloc casts
Remove unnecessary kmalloc casts in drivers/char/tty_io.c
Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
diff --git a/drivers/char/tty_io.c b/drivers/char/tty_io.c
index 47a6eac..97f54b0 100644
--- a/drivers/char/tty_io.c
+++ b/drivers/char/tty_io.c
@@ -1932,16 +1932,14 @@ static int init_dev(struct tty_driver *driver, int idx,
}
if (!*tp_loc) {
- tp = (struct ktermios *) kmalloc(sizeof(struct ktermios),
- GFP_KERNEL);
+ tp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
if (!tp)
goto free_mem_out;
*tp = driver->init_termios;
}
if (!*ltp_loc) {
- ltp = (struct ktermios *) kmalloc(sizeof(struct ktermios),
-GFP_KERNEL);
+ ltp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
if (!ltp)
goto free_mem_out;
memset(ltp, 0, sizeof(struct ktermios));
@@ -1965,16 +1963,14 @@ static int init_dev(struct tty_driver *driver, int idx,
}
if (!*o_tp_loc) {
- o_tp = (struct ktermios *)
- kmalloc(sizeof(struct ktermios), GFP_KERNEL);
+ o_tp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
if (!o_tp)
goto free_mem_out;
*o_tp = driver->other->init_termios;
}
if (!*o_ltp_loc) {
- o_ltp = (struct ktermios *)
- kmalloc(sizeof(struct ktermios), GFP_KERNEL);
+ o_ltp = kmalloc(sizeof(struct ktermios), GFP_KERNEL);
if (!o_ltp)
goto free_mem_out;
memset(o_ltp, 0, sizeof(struct ktermios));
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
JMicron JMB363 problems
I've been receiving odd error messages (accompanied by freezing up)
over the days. They are originating from the JMicron controller.
Setup:
Gigabyte GA-965P-DS3 (Intel 965P Express) rev 2.0, latest BIOS (F9)
-Intel ICH8 on-board [IDE emulation mode]
--250G Maxtor SATA -- /dev/sda
--250G Western Digital SATA -- /dev/sdb
-JMicron JBM363 on-board [IDE mode]
--Toshiba-Samsung DVD burner IDE (primary) -- /dev/hde
--HP DVD burner IDE (slave) -- /dev/hdf
Intel Core 2 Duo E6300 (1.86 GHz)
Kernel: Linux andy-desktop 2.6.19.1 #1 SMP Thu Dec 28 01:08:25 EST
2006 x86_64 GNU/Linux
--
Here are the messages:
Jan 4 13:25:04 andy-desktop kernel: [ 6326.349175] hde:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 13:39:50 andy-desktop kernel: [ 7211.582430] hdf:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 13:40:50 andy-desktop kernel: [ 7271.633086] hdf:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
--
One night, my dmesg was filled with this:
Jan 4 15:43:30 andy-desktop kernel: [14624.213835] hdf: status error:
status=0x58 { DriveReady SeekComplete DataRequest }
Jan 4 15:43:30 andy-desktop kernel: [14624.213842] ide: failed opcode
was: unknown
Jan 4 15:43:30 andy-desktop kernel: [14624.213846] hdf: drive not
ready for command
Jan 4 15:43:32 andy-desktop kernel: [14626.213105] hdf: status error:
status=0x58 { DriveReady SeekComplete DataRequest }
--
Today I got this:
Jan 4 18:22:35 andy-desktop kernel: [ 7944.113598] hdf:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 18:22:57 andy-desktop kernel: [ 7966.141664] hdf:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 18:23:23 andy-desktop kernel: [ 7992.180909] hdf:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 18:38:26 andy-desktop kernel: [ 8893.593383] hdf:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 18:43:02 andy-desktop kernel: [ 9169.847963] hde:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 18:44:57 andy-desktop kernel: [ 9283.998206] hde:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 18:50:25 andy-desktop kernel: [ 9612.470630] hde:
cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to
recover by ending request.
Jan 4 18:55:22 andy-desktop kernel: [ 9909.174069] cdrom_pc_intr,
write: dev hdf: type=d, flags=1088
Jan 4 18:55:22 andy-desktop kernel: [ 9909.174073]
Jan 4 18:55:22 andy-desktop kernel: [ 9909.174074] sector 0, nr/cnr 0/0
Jan 4 18:55:22 andy-desktop kernel: [ 9909.174077] bio
, biotail , buffer ,
data , len 0
--
Controller:
03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363
AHCI Controller (rev 02)
--
lsmod:
Module Size Used by
isofs 38372 1
vmnet 43168 15
vmmon 146188 11
binfmt_misc14476 1
rfcomm 43944 0
hidp 21120 2
l2cap 27264 10 rfcomm,hidp
bluetooth 60420 5 rfcomm,hidp,l2cap
cpufreq_userspace 6432 0
cpufreq_stats 8416 0
cpufreq_powersave 3456 0
cpufreq_ondemand 10640 0
freq_table 6592 2 cpufreq_stats,cpufreq_ondemand
cpufreq_conservative 9992 0
video 19336 0
sbs18240 0
i2c_ec 7168 1 sbs
button 9120 0
battery12296 0
container 6400 0
ac 7304 0
asus_acpi 19620 0
nls_utf83712 1
ntfs 99784 1
ipv6 278944 16
af_packet 26252 2
dm_mod 63568 0
md_mod 81308 1
ppdev 11400 0
sbp2 28164 0
psmouse41744 0
lp 14920 0
snd_emu10k1_synth 9216 0
snd_emux_synth 39040 1 snd_emu10k1_synth
snd_seq_virmidi 9344 1 snd_emux_synth
snd_seq_midi_emul 9088 1 snd_emux_synth
snd_seq_dummy 5636 0
snd_seq_oss35584 0
snd_seq_midi 10816 0
snd_seq_midi_event 9856 3 snd_seq_virmidi,snd_seq_oss,snd_seq_midi
snd_seq58368 9
snd_emux_synth,snd_seq_virmidi,snd_seq_midi_emul,snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event
sky2 45064 0
snd_hda_intel 23200 0
snd_hda_codec 203008 1 snd_hda_intel
nvidia 7748376 32
tsdev 1024
Re: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
On Thu, Jan 04, 2007 at 09:02:42AM -0800, Andrew Morton wrote: > On Thu, 4 Jan 2007 10:26:21 +0530 > Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > > > On Wed, Jan 03, 2007 at 02:15:56PM -0800, Andrew Morton wrote: > > > On Thu, 28 Dec 2006 13:53:08 +0530 > > > Suparna Bhattacharya <[EMAIL PROTECTED]> wrote: > > > > > > > This patchset implements changes to make filesystem AIO read > > > > and write asynchronous for the non O_DIRECT case. > > > > > > Unfortunately the unplugging changes in Jen's block tree have trashed > > > these > > > patches to a degree that I'm not confident in my repair attempts. So I'll > > > drop the fasio patches from -mm. > > > > I took a quick look and the conflicts seem pretty minor to me, the > > unplugging > > changes mostly touch nearby code. > > Well... the conflicts (both mechanical and conceptual) are such that a > round of retesting is needed. > > > Please let know how you want this fixed up. > > > > >From what I can tell the comments in the unplug patches seem to say that > > it needs more work and testing, so perhaps a separate fixup patch may be > > a better idea rather than make the fsaio patchset dependent on this. > > Patches against next -mm would be appreciated, please. Sorry about that. > > I _assume_ Jens is targetting 2.6.21? When is the next -mm likely to be out ? I was considering regenerating the blk unplug patches against the fsaio changes instead of the other way around, if Jens were willing to accept that. But if the next -mm is just around the corner then its not an issue. Regards Suparna > > -- > To unsubscribe, send a message with 'unsubscribe linux-aio' in > the body to [EMAIL PROTECTED] For more info on Linux AIO, > see: http://www.kvack.org/aio/ > Don't email: mailto:"[EMAIL PROTECTED]">[EMAIL PROTECTED] -- Suparna Bhattacharya ([EMAIL PROTECTED]) Linux Technology Center IBM Software Lab, India - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 0/8] user ns: Introduction
Quoting Andrew Morton ([EMAIL PROTECTED]):
> On Thu, 4 Jan 2007 12:06:35 -0600
> "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
>
> > This patchset adds a user namespace, which allows a process to
> > unshare its user_struct table, allowing for separate accounting
> > per user namespace.
>
> With these patches applied and with CONFIG_USER_NS=n, my selinux-enabled
> standard FC5 machine throws a complete fit:
>
> [ 12.323958] EDAC MC: Ver: 2.0.1 Jan 4 2007
> [ 12.357476] TCP cubic registered
> [ 12.360784] NET: Registered protocol family 1
> [ 12.364125] NET: Registered protocol family 17
> [ 12.367761] speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPI config is
> deprecated.
> [ 12.367763] Use X86_ACPI_CPUFREQ (acpi-cpufreq) instead.
> [ 12.374666] Using IPI Shortcut mode
> [ 12.378222] Time: tsc clocksource has been installed.
> [ 12.381987] Time: acpi_pm clocksource has been installed.
> [ 12.386522] ACPI: (supports S0 S3 S4 S5)
> [6.344000] Freeing unused kernel memory: 184k freed
> [6.56] input: PS/2 Mouse as /class/input/input1
> [6.58] input: AlpsPS/2 ALPS GlidePoint as /class/input/input2
> [6.76] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
> [6.764000] ide: Assuming 33MHz system bus speed for PIO modes; override
> with idebus=xx
> [6.824000] EXT3-fs: INFO: recovery required on readonly filesystem.
> [6.824000] EXT3-fs: write access will be enabled during recovery.
> [ 10.832000] kjournald starting. Commit interval 5 seconds
> [ 10.836000] EXT3-fs: recovery complete.
> [ 10.84] EXT3-fs: mounted filesystem with ordered data mode.
> [ 11.852000] audit(1167940353.844:2): enforcing=1 old_enforcing=0
> auid=4294967295
> [ 11.948000] security: 3 users, 6 roles, 1417 types, 151 bools, 1 sens,
> 256 cats
> [ 11.952000] security: 57 classes, 41080 rules
> [ 11.956000] security: class key not defined in policy
> [ 11.956000] security: class context not defined in policy
> [ 11.96] security: class dccp_socket not defined in policy
> [ 11.964000] security: permission dccp_recv in class node not defined in
> policy
> [ 11.964000] security: permission dccp_send in class node not defined in
> policy
> [ 11.968000] security: permission dccp_recv in class netif not defined in
> policy
> [ 11.972000] security: permission dccp_send in class netif not defined in
> policy
> [ 11.972000] security: permission setkeycreate in class process not
> defined in policy
> [ 11.976000] security: permission setsockcreate in class process not
> defined in policy
> [ 11.98] security: permission polmatch in class association not
> defined in policy
> [ 11.98] SELinux: Completing initialization.
> [ 11.984000] SELinux: Setting up existing superblocks.
> [ 12.004000] SELinux: initialized (dev sda6, type ext3), uses xattr
> [ 12.204000] SELinux: initialized (dev tmpfs, type tmpfs), uses transition
> SIDs
> [ 12.208000] SELinux: initialized (dev debugfs, type debugfs), uses
> genfs_contexts
> [ 12.208000] SELinux: initialized (dev selinuxfs, type selinuxfs), uses
> genfs_contexts
> [ 12.212000] SELinux: initialized (dev mqueue, type mqueue), uses
> transition SIDs
> [ 12.216000] SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses
> genfs_contexts
> [ 12.216000] SELinux: initialized (dev devpts, type devpts), uses
> transition SIDs
> [ 12.22] SELinux: initialized (dev eventpollfs, type eventpollfs), uses
> genfs_contexts
> [ 12.224000] SELinux: initialized (dev inotifyfs, type inotifyfs), uses
> genfs_contexts
> [ 12.224000] SELinux: initialized (dev tmpfs, type tmpfs), uses transition
> SIDs
> [ 12.228000] SELinux: initialized (dev futexfs, type futexfs), uses
> genfs_contexts
> [ 12.232000] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
> [ 12.232000] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
> [ 12.236000] SELinux: initialized (dev proc, type proc), uses genfs_contexts
> [ 12.24] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
> [ 12.24] SELinux: initialized (dev rootfs, type rootfs), uses
> genfs_contexts
> [ 12.244000] SELinux: initialized (dev sysfs, type sysfs), uses
> genfs_contexts
> [ 12.26] audit(1167940354.256:3): policy loaded auid=4294967295
> [ 12.944000] SELinux: initialized (dev usbfs, type usbfs), uses
> genfs_contexts
> [ 15.376000] audit(1167969158.994:4): avc: denied { audit_write } for
> pid=386 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0
> tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
> [ 33.936000] audit(1167969177.567:2292): avc: denied { search } for
> pid=2141 comm="klogd" name="/" dev=tmpfs ino=1225
> scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
> tclass=dir
> [ 33.94] audit(1167969177.579:2293): avc: denied { search } for
> pid=2141 comm="kl
2.6.20-rc3-mm1
Temporarily at http://userweb.kernel.org/~akpm/2.6.20-rc3-mm1/ will appear later at ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc3-mm1/ - Added the IBM ACPi driver tree to the -mm lineup, as git-ibm-acpi.patch (Henrique de Moraes Holschuh <[EMAIL PROTECTED]>) - Lots of block-layer changes rewriting the plug/unplug code. Seems to work. Boilerplate: - See the `hot-fixes' directory for any important updates to this patchset. - To fetch an -mm tree using git, use (for example) git-fetch git://git.kernel.org/pub/scm/linux/kernel/git/smurf/linux-trees.git tag v2.6.16-rc2-mm1 git-checkout -b local-v2.6.16-rc2-mm1 v2.6.16-rc2-mm1 - -mm kernel commit activity can be reviewed by subscribing to the mm-commits mailing list. echo "subscribe mm-commits" | mail [EMAIL PROTECTED] - If you hit a bug in -mm and it is not obvious which patch caused it, it is most valuable if you can perform a bisection search to identify which patch introduced the bug. Instructions for this process are at http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt But beware that this process takes some time (around ten rebuilds and reboots), so consider reporting the bug first and if we cannot immediately identify the faulty patch, then perform the bisection search. - When reporting bugs, please try to Cc: the relevant maintainer and mailing list on any email. - When reporting bugs in this kernel via email, please also rewrite the email Subject: in some manner to reflect the nature of the bug. Some developers filter by Subject: when looking for messages to read. - Semi-daily snapshots of the -mm lineup are uploaded to ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/ and are announced on the mm-commits list. Changes since 2.6.20-rc2-mm1: origin.patch git-acpi.patch git-ibm-acpi.patch git-alsa.patch git-arm.patch git-avr32.patch git-cifs.patch git-dvb.patch git-gfs2-nmw.patch git-ieee1394.patch git-infiniband.patch git-input.patch git-libata-all.patch git-lxdialog.patch git-mmc.patch git-mtd.patch git-ubi.patch git-netdev-all.patch git-ioat.patch git-ocfs2.patch git-pcmcia.patch git-selinux.patch git-pciseg.patch git-sh.patch git-scsi-rc-fixes.patch git-block.patch git-sas.patch git-qla3xxx.patch git-watchdog.patch git-wireless.patch git-cryptodev.patch git-gccbug.patch git trees -fix-ipmi-watchdog-set_param_str-using-kstrdup.patch -aio-fix-buggy-put_ioctx-call-in-aio_complete.patch -fix-lock-inversion-aio_kick_handler.patch -powerpc-iseries-link-error-in-allmodconfig.patch -change-warn_on-back-to-bug-at.patch -rcu-rcutorture-suspend-fix.patch -fix-oom-killer-kills-current-every-time-if-there-is.patch -add-gitignore-file-for-relocs-in-arch-i386.patch -pci-probe-fix-macro-that-confuses-kernel-doc.patch -char-mxser-fix-oops-when-removing-opened.patch -ib-mthca-fix-fmr-breakage-caused-by-kmemdup-conversion.patch -maintainers-email-addr-change-for-eric-moore.patch -make-fn_keys-work-again-on-power-macbooks.patch -char-isicom-eliminate-spinlock-recursion.patch -update-to-documentation-ttytxt-on-line-disciplines.patch -fix-mrproper-incompleteness.patch -sched-fix-cond_resched_softirq-offset.patch -fix-compilation-of-via-pmu-backlight.patch -module-fix-mod_sysfs_setup-return-value.patch -mm-ramfs-breaks-without-config_block.patch -mm-slob-is-broken-by-recent-cleanup-of-slabh.patch -cciss-build-with-proc_fs=n.patch -page_mkclean_one-fix-call-to-set_pte_at.patch -spi-define-null-tx_buf-to-mean-shift-out-zeroes.patch -m25p80-build-fixes-with-mtd-debug.patch -spi-mtd-mtd_dataflash-oops-prevention.patch -arm-omap-fix-gpmc-compiler-errors.patch -arm-omap-fix-missing-header-on-apollon-board.patch -buglet-in-vmscanc.patch -cpuset-procfs-warning-fix.patch -respect-srctree-objtree-in-documentation-docbook-makefile.patch -spi_s3c24xx_gpio-use-right-header.patch -lockdep-printk-warning-fix.patch -restore-pdeath_signal-behaviour.patch -gregkh-driver-driver-core-warn-users-that-the-sysfs-power-interface-really-is-broken.patch -gregkh-driver-driver-core-prefix-driver-links-in-sys-module-by-bus-name.patch -altix-acpi-_prt-support.patch -git-iee1394-printk-warning-fix.patch -git-ieee1394-build-fix.patch -git-ieee1394-build-fix-2.patch -git-ieee1394-build-fix-3.patch -pci-quirks-fix-the-festering-mess-that-claims-to-handle-ide-quirks-ide-fix.patch -git-ubi-build-fix.patch -git-ubi-mtd_read-arg-fix.patch -ebtables-dont-compute-gap-before-checking-struct.patch -pci-quirk-1k-i-o-space-iobl_adr-fix-on-p64h2.patch -pciehp-cleanup-init_slot.patch -pciehp-cleanup-slot-list.patch -pciehp-remove-unnecessary-php_ctlr.patch -pciehp-remove-unused-pci_bus-from-struct-controller.patch -pciehp-cleanup-register-access.patch -pciehp-cleanup-pciehph.patch -pciehp-remove-unused-pcie_cap_base.patch -pciehp-cleanup-wait-command-completion.patch -pciehp-fix-wait-command-completion.patch -pciehp-add-emi-support.p
[PATCH 2.6.20-rc3] Remove unneeded kmalloc casts
Remove unneeded kmalloc casts
Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
diff --git a/drivers/net/wireless/ipw2100.c b/drivers/net/wireless/ipw2100.c
index 0e94fbb..682b1bb 100644
--- a/drivers/net/wireless/ipw2100.c
+++ b/drivers/net/wireless/ipw2100.c
@@ -3361,11 +3361,9 @@ static int ipw2100_msg_allocate(struct ipw2100_priv
*priv)
void *v;
dma_addr_t p;
- priv->msg_buffers =
- (struct ipw2100_tx_packet *)kmalloc(IPW_COMMAND_POOL_SIZE *
- sizeof(struct
- ipw2100_tx_packet),
- GFP_KERNEL);
+ priv->msg_buffers = kmalloc(IPW_COMMAND_POOL_SIZE *
+ sizeof(struct ipw2100_tx_packet),
+ GFP_KERNEL);
if (!priv->msg_buffers) {
printk(KERN_ERR DRV_NAME ": %s: PCI alloc failed for msg "
"buffers.\n", priv->net_dev->name);
@@ -4395,11 +4393,9 @@ static int ipw2100_tx_allocate(struct ipw2100_priv *priv)
return err;
}
- priv->tx_buffers =
- (struct ipw2100_tx_packet *)kmalloc(TX_PENDED_QUEUE_LENGTH *
- sizeof(struct
- ipw2100_tx_packet),
- GFP_ATOMIC);
+ priv->tx_buffers = kmalloc(TX_PENDED_QUEUE_LENGTH *
+ sizeof(struct ipw2100_tx_packet),
+ GFP_ATOMIC);
if (!priv->tx_buffers) {
printk(KERN_ERR DRV_NAME
": %s: alloc failed form tx buffers.\n",
@@ -4548,9 +4544,9 @@ static int ipw2100_rx_allocate(struct ipw2100_priv *priv)
/*
* allocate packets
*/
- priv->rx_buffers = (struct ipw2100_rx_packet *)
- kmalloc(RX_QUEUE_LENGTH * sizeof(struct ipw2100_rx_packet),
- GFP_KERNEL);
+ priv->rx_buffers = kmalloc(RX_QUEUE_LENGTH *
+ sizeof(struct ipw2100_rx_packet),
+ GFP_KERNEL);
if (!priv->rx_buffers) {
IPW_DEBUG_INFO("can't allocate rx packet buffer table\n");
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Duplicated functions (was: fix memory corruption from misinterpreted bad_inode_ops return values)
Al Viro wrote: > On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote: > > The real (but harder) fix for the wasted space issue > > would be to get the toolchain to automatically combine functions that > > end up compiling into identical assembly. > > Can't do. [...] > Comparing pointers to > functions for equality is a well-defined operation and it's not > to be messed with. I agree -- it definitely could never be an "always on" optimization. What I was postulating would be a special post-processing step that could be run by people interested in squeezing the kernel as small as possible. I'd bet that there's not many functions in the kernel that rely on having a unique address. If some exist they could be put in their own ELF section via a "__unique_function_address_needed" macro or something. > You _can_ compile g into jump to f, but that's it. Actually if you don't mind sacrificing alignment (which we do anyway with -Os, I think) you could give a function two unique addresses just by prepending it with a single-byte noop instruction. But anyway... how about some actual data? Just out of curiosity I threw together a quick script (attached) that parses the output of "objdump --disassemble vmlinux" and tries to find functions that share the same opcodes. The short summary of the results: a bit of .text savings but not an amazing amount -- on my tiny nfsroot test kernel it found 4034 bytes worth of possible savings (out of a total of 1460830 bytes of opcodes in .text) About what I expected, actually. One line in its output really stands out, however: | 218 bytes: __copy_from_user_ll_nozero, __copy_from_user_ll, __copy_to_user_ll Those three big functions are exactly the same, which actually makes sense if you think about how they're implemented. That's a bunch of *very* hot Icache lines we're wasting there! Anyway, hopefully some folks will find the script interesting. In particular maybe the janitors can play with it. I'd wager some of the things it turns up are good candidates for code re-use. -Mitch Script's output: Duplicated functions: 98 bytes: nlmsvc_proc_granted, nlm4svc_proc_granted 10 bytes: return_EIO, hung_up_tty_write 10 bytes: free_pid_ns, mempool_kfree, free_bd_holder, nfs4_free_open_state, ipc_immediate_free, dir_release, pci_release_bus_bridge_dev, put_tty_driver, device_create_release, class_create_release, class_device_create_release, isa_dev_release, neigh_parms_destroy, unx_destroy_cred, pmap_map_release, rpc_free_iostats, free 15 bytes: xor_64, xor_64 7 bytes: native_set_pte, native_set_pmd, debugfs_u32_set 24 bytes: part_uevent_store, store_uevent 54 bytes: atm_init_aal34, atm_init_aal5 22 bytes: nfs4_encode_void, nlmsvc_encode_void, nlm4svc_encode_void 42 bytes: seq_release_private, content_release 10 bytes: profile_event_register, profile_event_unregister, nocrypt, nocrypt_iv 7 bytes: nfs_proc_commit_setup, udp_lib_hash, udp_lib_hash 179 bytes: nlmsvc_proc_sm_notify, nlm4svc_proc_sm_notify 29 bytes: nfs4_decode_void, nlmsvc_decode_void, nlm4svc_decode_void 62 bytes: nfs3_commit_done, nfs3_write_done 7 bytes: print_trace_stack, i8237A_suspend, store, module_frob_arch_sections, get_gate_vma, in_gate_area, in_gate_area_no_task, no_blink, noop_ret, no_action, next_online_pgdat, __pud_alloc, __pmd_alloc, generic_pipe_buf_pin, simple_sync_file, nfs4_callback_null, fuse_prepare_write, default_read_file, dummycon_dummy, vgacon_dummy, read_null, hung_up_tty_read, con_chars_in_buffer, class_device_create_uevent, anon_transport_dummy_function, ramdisk_writepages, sock_no_poll, noop_dequeue, ipv4_dst_check, rpcproc_encode_null, rpcproc_decode_null, pvc_shutdown, svc_shutdown 20 bytes: fn_show_ptregs, sysrq_handle_showregs 29 bytes: part_next, diskstats_next 10 bytes: atomic_notifier_call_chain, raw_notifier_call_chain 107 bytes: nlm_decode_cookie, nlm4_decode_cookie 5 bytes: do_spurious_interrupt_bug, c_stop, machine_shutdown, machine_halt, syscall_vma_close, native_nop, sighand_ctor, r_stop, s_stop, audit_log_task_context, noop, default_unplug_io_fn, frag_stop, single_stop, t_stop, devinfo_stop, int_seq_stop, parse_solaris_x86, parse_freebsd, parse_netbsd, parse_openbsd, parse_unixware, parse_minix, nfs_server_list_stop, nfs_volume_list_stop, nfs3_forget_cached_acls, fuse_read_inode, ipc_lock_by_ptr, ipc_unlock, crypto_exit_cipher_ops, crypto_exit_digest_ops, ioport_unmap, pci_remove_legacy_files, k_ignore, con_throttle, nv_vlan_rx_kill_vid, input_devices_seq_stop, input_handlers_seq_stop, proto_seq_stop, dev_seq_stop, softnet_seq_stop, dev_mc_seq_stop, neigh_stat_seq_stop, netlink_seq_stop, rt_cpu_seq_stop, tcp_twsk_destructor, raw_seq_stop, udp_seq_stop, icmp_address, icmp_discard, fib_seq_stop, unix_seq_stop, packet_seq_stop, rpc_default_callback, nul_destroy, nul_destroy_cred, c_stop, vcc_seq_stop, smp_setup_processor_id, remapped_pgdat_init, pre_setup_arch_hook, trap_init_hook, sched_init_s
Re: VM: Fix nasty and subtle race in shared mmap'ed page writeback
Andrea Gelmini wrote: On Thu, Jan 04, 2007 at 05:03:43PM +1100, Nick Piggin wrote: Anyway that leaves us with the question of why Andrea's database is getting corrupted. Hopefully he can give us a minimal test-case. yep, I can give you a complete image of my machine, or a root access. replicate the problem it's not complicated, but it requires some time (you have to expire/update usenet/newsgroup headers). I can talk with Bauno to see if he can produce an automated program that replicate user behavior. Myself, I don't think I have the time or capability to help much if the corruption involves a complicated set of userspace software, especially if you don't have a point where a regression was introduced. I was thinking like a 100 line C program that I can reproduce here ;) If you can even describe the steps it does: (eg. mmap file A, write(2) to it, truncate it, , should contain 1s but it contains 0s!), then we might have some suggestions to try. One obvious thing is change filesystems or filesystem block sizes, try ext2 or even tmpfs. Another is to try using write(2) instead of mmap to write data. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: open(O_DIRECT) on a tmpfs?
Denis Vlasenko wrote: On Thursday 04 January 2007 17:19, Bill Davidsen wrote: Hugh Dickins wrote: In many cases the use of O_DIRECT is purely to avoid impact on cache used by other applications. An application which writes a large quantity of data will have less impact on other applications by using O_DIRECT, assuming that the data will not be read from cache due to application pattern or the data being much larger than physical memory. But O_DIRECT is _not_ about cache. At least I think it was not about cache initially, it was more about DMAing data directly from/to application address space to/from disks, saving memcpy's and double allocations. Why do you think it has that special alignment requirements? Are they cache related? Not at all! I don't know whether that is the case. The two issues are related -- the IO is be done zero-copy because there is no cache involved, and due to there being no cache, there are alignment restrictions. I think IRIX might have implemented O_DIRECT first, and although the semantics are a bit vague, I think it has always been to do zero copy IO _and_ to bypass cache (ie. no splice-like tricks). After that people started adding unrelated semantics on it - "oh, we use O_DIRECT in our database code and it pushes EVERYTHING else out of cache. This is bad. Let's overload O_DIRECT to also mean 'do not pollute the cache'. Here's the patch". It is because they already do their own caching, so going through another, dumber, cache of same or less size (the pagecache) is useless. fadvise does not change that. That said, tmpfs's page are not really a cache (except when they are swapcache, but let's not complicate things). So O_DIRECT on tmpfs may not exactly be wrong. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHSET 4][PATCH 1/1] AIO fallback for pipes, sockets and pollable fds
As glibc POSIX AIO switches over completely to using native AIO it needs
basic AIO support for various file types - including sockets, pipes etc.
Since userland will no longer be simulating asynchronous behaviour
with threads, it expects the underlying implementation to be asynchronous.
Which is still an issue with native linux AIO.
One (not so appealing) alternative that has been considered in the past is
a fallback path that spawns a kernel thread per AIO request. This in some
sense amounts to pushing the problem down from user to kernel space.
Fortunately we can do better. We can effectively simulate AIO in kernel
using async poll and O_NONBLOCK for all pollable fds, i.e. sockets, pipes
etc.
With this scheme in place, all that needs to be done to add AIO support
for any pollable file type is to make sure that the corresponding
f_op->aio_read/aio_write implements O_NONBLOCK behaviour if called in
aio context, i.e. with an async kiocb. The high level common AIO code
takes care of the rest, by enabling retries for completing the rest of
the IO to be initiated directly via poll wait notifications.
This fallback option should be good enough to get us to working POSIX AIO,
now that filesystem AIO already takes care of ISREG files which do not
support O_NONBLOCK. I have tested this with modified pipetest runs, also
using sockets instead of pipes.
---
linux-2.6.20-rc1-root/fs/aio.c | 54 +
linux-2.6.20-rc1-root/fs/pipe.c| 17 +++
linux-2.6.20-rc1-root/net/socket.c |6 ++--
3 files changed, 69 insertions(+), 8 deletions(-)
diff -puN fs/aio.c~aio-fallback-nonblock fs/aio.c
--- linux-2.6.20-rc1/fs/aio.c~aio-fallback-nonblock 2007-01-03
19:16:36.0 +0530
+++ linux-2.6.20-rc1-root/fs/aio.c 2007-01-05 10:29:52.0 +0530
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -1315,6 +1316,42 @@ static void aio_advance_iovec(struct kio
BUG_ON(ret > 0 && iocb->ki_left == 0);
}
+/* Wrapper structure used by poll queuing */
+struct aio_pqueue {
+ poll_table pt;
+ struct kiocb *iocb;
+};
+
+static int aio_cancel_wait(struct kiocb *iocb, struct io_event *event)
+{
+ wait_queue_head_t *wq = (struct wait_queue_head_t *)iocb->private;
+ if (wq)
+ wake_up(wq);
+ event->res = iocb->ki_nbytes - iocb->ki_left;
+ event->res2 = 0;
+ /* drop the cancel reference */
+ aio_put_req(iocb);
+ return 0;
+}
+
+/* Sets things up for a readiness event to trigger the iocb's retry */
+static void aio_poll_table_queue_proc(struct file *file,
+ wait_queue_head_t *whead, poll_table *pt)
+{
+ struct kiocb *iocb = container_of(pt, struct aio_pqueue, pt)->iocb;
+
+ if (unlikely(iocb->private && iocb->ki_dtor)) {
+ /* FIXME: We really shouldn't have to do this */
+ /* the siocb allocation in socket.c is unused AFAIK */
+ iocb->ki_dtor(iocb);
+ iocb->ki_dtor = NULL;
+ }
+
+ iocb->private = whead;
+ iocb->ki_cancel = aio_cancel_wait;
+ prepare_to_wait(whead, &iocb->ki_wait.wait, 0);
+}
+
static ssize_t aio_rw_vect_retry(struct kiocb *iocb)
{
struct file *file = iocb->ki_filp;
@@ -1334,6 +1371,7 @@ static ssize_t aio_rw_vect_retry(struct
opcode = IOCB_CMD_PWRITEV;
}
+ready:
do {
ret = rw_op(iocb, &iocb->ki_iovec[iocb->ki_cur_seg],
iocb->ki_nr_segs - iocb->ki_cur_seg,
@@ -1352,6 +1390,22 @@ static ssize_t aio_rw_vect_retry(struct
if ((ret == 0) || (iocb->ki_left == 0))
ret = iocb->ki_nbytes - iocb->ki_left;
+ if (ret == -EAGAIN && file->f_op->poll) {
+ /* This means fop->aio_read implements O_NONBLOCK behaviour */
+ /* Let us try to simulate aio retries using ->poll */
+ struct aio_pqueue pollq = {.iocb = iocb};
+ int events = (opcode == IOCB_CMD_PWRITEV) ?
+ POLLOUT | POLLERR | POLLHUP :
+ POLLIN | POLLERR | POLLHUP;
+
+ init_poll_funcptr(&pollq.pt, aio_poll_table_queue_proc);
+ ret = file->f_op->poll(file, &pollq.pt);
+ if (ret >= 0) {
+ if (ret & events)
+ goto ready;
+ ret = -EIOCBRETRY;
+ }
+ }
return ret;
}
diff -puN net/socket.c~aio-fallback-nonblock net/socket.c
--- linux-2.6.20-rc1/net/socket.c~aio-fallback-nonblock 2007-01-03
19:16:36.0 +0530
+++ linux-2.6.20-rc1-root/net/socket.c 2007-01-03 19:16:36.0 +0530
@@ -701,7 +701,8 @@ static ssize_t do_sock_read(struct msghd
msg->msg_controllen = 0;
msg->msg_iov = (struct iovec *)iov;
msg->msg_iovlen = nr_segs;
- msg->msg_flags = (file->f_flags & O_NONBLOCK) ? MSG_DONTWAIT : 0;
Re: [patch] dont export asm/page.h to userspace
On Thu, 4 Jan 2007 22:28:30 -0500 Mike Frysinger <[EMAIL PROTECTED]> wrote: > On 1/4/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > > It should not be exported to userspace at all. Care to submit a patch? > > trivial patch attached > -mike > > > [application/pgp-signature (828B)] > > [linux-dont-export-asm-page.patch text/x-diff (326B)] > diff --git a/include/asm-generic/Kbuild.asm b/include/asm-generic/Kbuild.asm > index a37e95f..642d277 100644 > --- a/include/asm-generic/Kbuild.asm > +++ b/include/asm-generic/Kbuild.asm > @@ -32,4 +32,3 @@ unifdef-y += user.h > # These probably shouldn't be exported > unifdef-y += shmparam.h > unifdef-y += elf.h > -unifdef-y += page.h box:/usr/src/25> make headers_check CHK include/linux/version.h CHK include/linux/compile.h CHK include/linux/utsrelease.h make[1]: `scripts/unifdef' is up to date. REMOVE include/asm/page.h REMOVE include/asm/.check.page.h CHECK include/asm-generic/siginfo.h CHECK include/asm-generic/resource.h CHECK include/asm-generic/statfs.h CHECK include/asm-generic/signal.h CHECK include/asm-generic/mman.h CHECK include/asm-generic/ipc.h CHECK include/asm-generic/ioctl.h CHECK include/asm-generic/fcntl.h CHECK include/asm-generic/errno.h CHECK include/asm-generic/errno-base.h CHECK include/asm/vm86.h CHECK include/asm/user.h /usr/src/devel/usr/include/asm/user.h requires asm/page.h, which does not exist in exported headers make[2]: *** [/usr/src/devel/usr/include/asm/.check.user.h] Error 1 make[1]: *** [asm-i386] Error 2 make: *** [headers_check] Error 2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET 1][PATCH 0/6] Filesystem AIO read/write
Suparna Bhattacharya wrote: On Thu, Jan 04, 2007 at 05:50:11PM +1100, Nick Piggin wrote: OK, but I think that after IO submission, you do not run sync_page to unplug the block device, like the normal IO path would (via lock_page, before the explicit plug patches). In the buffered AIO case, we do run sync page like normal IO ... just that we don't block in io_schedule(), everything else is pretty much similar. You do? OK I must have misread it. Ignore that, then ;) I'm sure more merging or batching could be done, but also consider that most programs will not ever make use of any added complexity. I guess I didn't express myself well - by batching I meant being able to surround submission of a batch of iocbs with explicit plug/unplug instead of explicit plug/unplug for each iocb separately. Of course there is no easy way to do that, since at the io_submit() level we do not know about the block device (each iocb could be directed to a different fd and not just block devices). So it may not be worth thinking about. Well we currently _could_ do that, because the block device plugging code will detect if the request queue changes, and flush built up requests... However, I think we may want to make the plug operations a callback rather than hardcoded block device plugging, so that will make it harder... but you have a good point about increasing the scope of the plugging, it would be a win if we can do it. Regarding your patches, I've just had a quick look and have a question -- what do you do about blocking in page reclaim and dirty balancing? Aren't those major points of blocking with buffered IO? Did your test cases dirty enough to start writeout or cause a lot of reclaim? (admittedly, blocking in reclaim will now be much less common since the dirty mapping accounting). In my earlier versions of patches I actually had converted these waits to be async retriable, but then I came to the conclusion that the additional complexity wasn't worth it. For one it didn't seem to make a difference compared to the other bigger cases, and I was looking primarily at handling the gross blocking points (say to enable an application to keep device queues busy) and not making everything asynchronous; for another we had a long discussion thread waay back about not making AIO submitters exempt from throttling or memory availability waits. OK, I was just curious. For keeping queues busy, your patchset should work well (sleeping for more memory should be pretty uncommon). But for overlapping computation with IO, it may not work so well if it encounters throttling. -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] Vmi initialize fs for smp
Now that Jeremy's change to move the kernel PDA to %fs has arrived, convert the AP processor setup for SMP to use FS instead of GS. Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]> diff -r 2ac108843573 arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.cThu Jan 04 20:01:52 2007 -0800 +++ b/arch/i386/kernel/vmi.cThu Jan 04 20:02:42 2007 -0800 @@ -533,8 +533,8 @@ vmi_startup_ipi_hook(int phys_apicid, un ap.ds = __USER_DS; ap.es = __USER_DS; - ap.fs = 0; - ap.gs = __KERNEL_PDA; + ap.fs = __KERNEL_PDA; + ap.gs = 0; ap.eflags = 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Vmi compile fix
The variable no_timer_check does not exist in UP builds; don't try to set it in the vmi init code. Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]> diff -r 21d7686ee318 arch/i386/kernel/vmi.c --- a/arch/i386/kernel/vmi.cThu Jan 04 15:23:30 2007 -0800 +++ b/arch/i386/kernel/vmi.cThu Jan 04 15:55:39 2007 -0800 @@ -913,7 +913,9 @@ void __init vmi_init(void) local_irq_save(flags); activate_vmi(); +#ifdef CONFIG_SMP no_timer_check = 1; +#endif local_irq_restore(flags & X86_EFLAGS_IF); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] Vmi native fix
In paravirt builds with VMI compiled in, vmi_bringup is called
unconditionally, not via a paravirt-ops table (as no other hypervisor
uses the APIC startup technique). Make the calls to setup VMI state
conditional on the presence of the VMI ROM.
Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
diff -r 1915e2685a3c arch/i386/kernel/vmi.c
--- a/arch/i386/kernel/vmi.cThu Jan 04 15:56:40 2007 -0800
+++ b/arch/i386/kernel/vmi.cThu Jan 04 15:57:38 2007 -0800
@@ -645,7 +645,8 @@ void vmi_bringup(void)
void vmi_bringup(void)
{
/* We must establish the lowmem mapping for MMU ops to work */
- vmi_ops.set_linear_mapping(0, __PAGE_OFFSET, max_low_pfn, 0);
+ if (vmi_rom)
+ vmi_ops.set_linear_mapping(0, __PAGE_OFFSET, max_low_pfn, 0);
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] VMI hotfixes
Hotfixes for VMI code from -rc2-mm1. This fixes several critical problems, a compile fix for +PARAVIRT+VMI-SMP, a bogus indirect call to a VMI function on native, and corrects the FS/GS startup state for SMP to match the new FS/GS PDA changes. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 8/8] user ns: implement user ns unshare
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > On Thu, 04 Jan 2007 16:52:53 CST, "Serge E. Hallyn" said: > > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > > On Thu, 04 Jan 2007 19:07:00 GMT, Frederik Deweerdt said: > > > > > int err = 0; > > > > > > > > The "= 0" is superfluous here. > > > > > > Umm? bss gets cleared automagically, but when did we start auto-zeroing > > > the stack? > > > > No, no, that's what i thought he meant at first too, but I actually > > manually set err on all paths anyway :) > > Oh. So it's *really* just "superfluous until somebody changes the code"... True. -serge - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Multi kernel tree support on the same distro?
There are some difficulties with gcc versions between linux-2.4 and linux-2.6, but I do not recall all of the details off of the top of my head. If I recall correctly, one of the issues is, linux-2.4 ?prefers? gcc-2.96, while newer linux-2.6 support/prefer gcc-3.? or greater. At any rate, what I've done is create a chroot environment. I created this chroot directory by installing an older distribution that was created with linux-2.4 in mind (example, RedHat v8.2) into that at chroot directory. The easiest way to do this that I'm aware of is to install the older distribution (minimal development, no server junk, no X junk) on another computer, then copy from that computer to a directory on your development computer. Then chroot to that directory with something like chroot /home/linux-2.4-devel /bin/bash mount /proc Note that I have had some issues with having a linux-2.6 kernel on /proc with a linux-2.4 distribution, but nothing that greatly affects code development. Of course, I'm assuming that you are the only person that has access to this development computer, because chroot is a security risk (example: cd /; cd ..) Sorry for being short on details, but I hope this helps. Steve Brueggeman On Thu, 04 Jan 2007 16:14:42 -0800, you wrote: >Akula2 wrote: >> Hello All, >> >> I am looking to use multiple kernel trees on the same distro. Example:- >> >> 2.6.19.1 for - software/tools development >> 2.4.34for - embedded systems development. >> >> I do know that 2.6 supports embedded in a big waybut still >> requirement demands to work with such boards as an example:- >> >> http://www.embeddedarm.com/linux/ARM.htm >> >> My question is HOW-TO enable a distro with multi kernel trees? >> Presently am using Fedora Core 5/6 for much of the development >> activities (Cell BE SDK related at Labs). >> >> Any hints/suggestions would be a great leap for me to do this on my own. > >this is really no big problem (as in: works OOTB), except that if you want to >boot & run >both kernels on the same (rootfs) installation, you will need to create >wrappers around >modutils and module-init-tools, as well as udev/devfs, or whichever device >file system >you prefer to use for each kernel. There are a few minor other details but >none really >shocking. > >We've done this for "our" source distro, and it works just fine. > >Cheers, > >Auke >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" in >the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
On Fri, 05 Jan 2007 00:54:32 +0100 Stelian Pop <[EMAIL PROTECTED]> wrote: > Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit : > > On Fri, 05 Jan 2007 00:36:23 +0100 > > Stelian Pop <[EMAIL PROTECTED]> wrote: > > > > > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi > > > subsystem, > > > and made correspondent necessary changes for this to work. > > > > neato. > > > > err, how does one use this? > > :) > > Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not > only this one), the Fn key events aren't seen by sonypi or sony_acpi > GHKE method, but do generate an ACPI notify event. Speak English ;) > For those laptops, the patch forwards the ACPI event to the ACPI system > and can be later interpreted in userspace using > acpid's /etc/acpi/default.sh (example directly from Nilton): The only things Mr Red Hat gave me are /etc/acpi/events/sample.conf and /etc/acpi/events/video.conf. > > case "$group" in > > button) > > case "$action" in > > power) /usr/sbin/hibernate > > ;; > > > > lid) cat /proc/acpi/button/lid/LID/state > > ;; > > > > *) logger "ACPI action $action is not defined ($@)" > > ;; > > esac > > ;; > > > > SNC) echo "$@" > /dev/tcp/localhost/50007 > > ;; > > > > *) logger "ACPI group $group / action $action is not defined" > > ;; > > esac > > > > In which I just forward the SNC event to another userspace application > > listening on a TCP port. > I pressed then released a button and dmesg said [ 76.961568] evbug.c: Event. Dev: , Type: 1, Code: 148, Value: 1 [ 76.961576] evbug.c: Event. Dev: , Type: 0, Code: 0, Value: 0 [ 76.963277] evbug.c: Event. Dev: , Type: 1, Code: 148, Value: 0 [ 76.963284] evbug.c: Event. Dev: , Type: 0, Code: 0, Value: 0 [ 76.967341] evbug.c: Event. Dev: , Type: 1, Code: 148, Value: 1 [ 76.967349] evbug.c: Event. Dev: , Type: 0, Code: 0, Value: 0 [ 76.968136] evbug.c: Event. Dev: , Type: 1, Code: 148, Value: 0 [ 76.968143] evbug.c: Event. Dev: , Type: 0, Code: 0, Value: 0 Nothing else happened. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 0/8] user ns: Introduction
On Thu, 4 Jan 2007 12:06:35 -0600
"Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
> This patchset adds a user namespace, which allows a process to
> unshare its user_struct table, allowing for separate accounting
> per user namespace.
With these patches applied and with CONFIG_USER_NS=n, my selinux-enabled
standard FC5 machine throws a complete fit:
[ 12.323958] EDAC MC: Ver: 2.0.1 Jan 4 2007
[ 12.357476] TCP cubic registered
[ 12.360784] NET: Registered protocol family 1
[ 12.364125] NET: Registered protocol family 17
[ 12.367761] speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPI config is
deprecated.
[ 12.367763] Use X86_ACPI_CPUFREQ (acpi-cpufreq) instead.
[ 12.374666] Using IPI Shortcut mode
[ 12.378222] Time: tsc clocksource has been installed.
[ 12.381987] Time: acpi_pm clocksource has been installed.
[ 12.386522] ACPI: (supports S0 S3 S4 S5)
[6.344000] Freeing unused kernel memory: 184k freed
[6.56] input: PS/2 Mouse as /class/input/input1
[6.58] input: AlpsPS/2 ALPS GlidePoint as /class/input/input2
[6.76] Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
[6.764000] ide: Assuming 33MHz system bus speed for PIO modes; override
with idebus=xx
[6.824000] EXT3-fs: INFO: recovery required on readonly filesystem.
[6.824000] EXT3-fs: write access will be enabled during recovery.
[ 10.832000] kjournald starting. Commit interval 5 seconds
[ 10.836000] EXT3-fs: recovery complete.
[ 10.84] EXT3-fs: mounted filesystem with ordered data mode.
[ 11.852000] audit(1167940353.844:2): enforcing=1 old_enforcing=0
auid=4294967295
[ 11.948000] security: 3 users, 6 roles, 1417 types, 151 bools, 1 sens, 256
cats
[ 11.952000] security: 57 classes, 41080 rules
[ 11.956000] security: class key not defined in policy
[ 11.956000] security: class context not defined in policy
[ 11.96] security: class dccp_socket not defined in policy
[ 11.964000] security: permission dccp_recv in class node not defined in
policy
[ 11.964000] security: permission dccp_send in class node not defined in
policy
[ 11.968000] security: permission dccp_recv in class netif not defined in
policy
[ 11.972000] security: permission dccp_send in class netif not defined in
policy
[ 11.972000] security: permission setkeycreate in class process not defined
in policy
[ 11.976000] security: permission setsockcreate in class process not defined
in policy
[ 11.98] security: permission polmatch in class association not defined
in policy
[ 11.98] SELinux: Completing initialization.
[ 11.984000] SELinux: Setting up existing superblocks.
[ 12.004000] SELinux: initialized (dev sda6, type ext3), uses xattr
[ 12.204000] SELinux: initialized (dev tmpfs, type tmpfs), uses transition
SIDs
[ 12.208000] SELinux: initialized (dev debugfs, type debugfs), uses
genfs_contexts
[ 12.208000] SELinux: initialized (dev selinuxfs, type selinuxfs), uses
genfs_contexts
[ 12.212000] SELinux: initialized (dev mqueue, type mqueue), uses transition
SIDs
[ 12.216000] SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses
genfs_contexts
[ 12.216000] SELinux: initialized (dev devpts, type devpts), uses transition
SIDs
[ 12.22] SELinux: initialized (dev eventpollfs, type eventpollfs), uses
genfs_contexts
[ 12.224000] SELinux: initialized (dev inotifyfs, type inotifyfs), uses
genfs_contexts
[ 12.224000] SELinux: initialized (dev tmpfs, type tmpfs), uses transition
SIDs
[ 12.228000] SELinux: initialized (dev futexfs, type futexfs), uses
genfs_contexts
[ 12.232000] SELinux: initialized (dev pipefs, type pipefs), uses task SIDs
[ 12.232000] SELinux: initialized (dev sockfs, type sockfs), uses task SIDs
[ 12.236000] SELinux: initialized (dev proc, type proc), uses genfs_contexts
[ 12.24] SELinux: initialized (dev bdev, type bdev), uses genfs_contexts
[ 12.24] SELinux: initialized (dev rootfs, type rootfs), uses
genfs_contexts
[ 12.244000] SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts
[ 12.26] audit(1167940354.256:3): policy loaded auid=4294967295
[ 12.944000] SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts
[ 15.376000] audit(1167969158.994:4): avc: denied { audit_write } for
pid=386 comm="hwclock" capability=29 scontext=system_u:system_r:hwclock_t:s0
tcontext=system_u:system_r:hwclock_t:s0 tclass=capability
[ 33.936000] audit(1167969177.567:2292): avc: denied { search } for
pid=2141 comm="klogd" name="/" dev=tmpfs ino=1225
scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=dir
[ 33.94] audit(1167969177.579:2293): avc: denied { search } for
pid=2141 comm="klogd" name="/" dev=tmpfs ino=1225
scontext=system_u:system_r:klogd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0
tclass=dir
[ 33.952000] audit(1167969177.591:2294): avc: denied { search } for
pid=2141 comm="klogd" name="/" dev=tmpfs in
Re: PROBLEM: LSIFC909 mpt card fails to recognize devices
On Thu, Jan 04, 2007 at 04:59:22PM -0800, Andrew Morton wrote: > On Thu, 04 Jan 2007 19:06:46 -0500 > Justin Rosander <[EMAIL PROTECTED]> wrote: > > > Please forward this to the appropriate maintainer. Thank you. > > > > [1.] One line summary of the problem:My fibre channel drives fail to > > be recognized by my LSIFC909 card. > > Please send the output of `lspci -vn' > - Recompile the driver with MPT_DEBUG_INIT enabled in the driver Makefile, and repost the output. Eric Moore - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.20-rc3] cpufreq: check sysfs_create_link return value
Trivial patch to check sysfs_create_link return values. Fail gracefully
if needed.
Signed-off-by: Ahmed Darwish <[EMAIL PROTECTED]>
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index d913304..72ee576 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -722,8 +722,13 @@ static int cpufreq_add_dev (struct sys_device * sys_dev)
spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
dprintk("CPU already managed, adding link\n");
- sysfs_create_link(&sys_dev->kobj,
- &managed_policy->kobj, "cpufreq");
+ ret = sysfs_create_link(&sys_dev->kobj,
+ &managed_policy->kobj,
+ "cpufreq");
+ if (ret) {
+ mutex_unlock(&policy->lock);
+ goto err_out_driver_exit;
+ }
cpufreq_debug_enable_ratelimit();
mutex_unlock(&policy->lock);
@@ -770,8 +775,12 @@ static int cpufreq_add_dev (struct sys_device * sys_dev)
dprintk("CPU %u already managed, adding link\n", j);
cpufreq_cpu_get(cpu);
cpu_sys_dev = get_cpu_sysdev(j);
- sysfs_create_link(&cpu_sys_dev->kobj, &policy->kobj,
- "cpufreq");
+ ret = sysfs_create_link(&cpu_sys_dev->kobj, &policy->kobj,
+ "cpufreq");
+ if (ret) {
+ mutex_unlock(&policy->lock);
+ goto err_out_unregister;
+ }
}
policy->governor = NULL; /* to assure that the starting sequence is
--
Ahmed S. Darwish
http://darwish-07.blogspot.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] dont export asm/page.h to userspace
On 1/4/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote: > It should not be exported to userspace at all. Care to submit a patch? trivial patch attached -mike pgpVvto1SV01x.pgp Description: PGP signature diff --git a/include/asm-generic/Kbuild.asm b/include/asm-generic/Kbuild.asm index a37e95f..642d277 100644 --- a/include/asm-generic/Kbuild.asm +++ b/include/asm-generic/Kbuild.asm @@ -32,4 +32,3 @@ unifdef-y += user.h # These probably shouldn't be exported unifdef-y += shmparam.h unifdef-y += elf.h -unifdef-y += page.h
Re: SATA problems
Pablo Sebastian Greco wrote: Tejun Heo wrote: Pablo Sebastian Greco wrote: By crash I mean the whole system going down, having to reset the entire machine. I'm sending you 4 files: dmesg: current boot dmesg, just a boot, because no errors appeared after last crash, since the server is out of production right now (errors usually appear under heavy load, and this primarily a transparent proxy for about 1000 simultaneous users) lspci: the way you asked for it messages and messages.1: files where you can see old boots and crashes (even a soft lockup). If there is anything else I can do, let me know. If you need direct access to the server, I can arrange that too. Can you try 2.6.20-rc3 and see if 'CLO not available' message goes away (please post boot dmesg)? The crash/lock is because filesystem code does not cope with IO errors very well. I can't tell why timeouts are occurring in the first place. It seems that only samsung drives are affected (sda2, 3, 4). Hmmm... Please apply the attached patch to 2.6.20-rc3 and test it. Thanks. Here's boot dmesg with 2.6.20-rc3 + blacklist. And you are right about only affecting samsung drives, but since only those drives get all the heavy load, couldn't tell exactly. I'm putting the server in production right now, so I think in a few hours I'll have more info. Thanks. Pablo. After an uptime of 13:34 under heavy load and no errors, I'm pretty sure your patch is correct. Is there a way to backport this to 2.6.18.x? Just an off topic question, does anyone know why I get so uneven IRQ handling on 2.6.19-20 and almost perfect on 2.6.20-rc2-mm1? Thanks for everything. Pablo. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wireless Q
On Thursday 04 January 2007 17:14, John W. Linville wrote: >On Thu, Jan 04, 2007 at 12:51:49AM -0500, Gene Heskett wrote: >> I bought a Belkin Wireless G card, a pci 802-11 radio of some sort. >> >> The main chip on it wears the label "RTL8185L" >> >> Is there any support for making this a wireless server in the kernel >> at the present time? >> >> I have visions of sticking it in the last pci slot of a box running >> DD-WRT if there is a driver available. > >Gene, > >There is no such driver in the kernel at this time. There is an >out-of-kernel driver available here: > > http://rtl8180-sa2400.sourceforge.net/ > >YMMV. > >FWIW, I know of at least one person working on a driver for the >d80211-based stack in wireless-dev. I'm not sure when that will be >available publicly. > >Hth! > Possibly in the future John. I took the Belkin back and got a Netgear WG311T for another $35. Staples let me open it there and based on the fact that the cd has some drivers on it that start with ATHE_* (the chipset has a tincover soldered to the board over it so we can't ID it that way), I'm assuming its an Atheros chipset, and Brian does has that support available in DD-WRT, which is where this puppy will live. But I'm up to my butt in alligators ATM, so it may be a day or 3 till I can try it. I have a 160GB drive laying on the lappies carry case in the doorway, to go up and be installed in the neighbors box to replace a 30GB that upchucked all over their windows install, and convince it to let me install windows on that box the 2nd time. M$ are such rectums over that. Its piracy you know. :( And its already 21:22 here and I'd druther space it for the night. :( I probably will since I kept them up till midnight last night finding the missing 1.5 megabaud download speed and making their wireless in a new Acer lappy work. But its unsecured and that makes me nervous if some war driver comes by. Not a high probability out here in the sticks, but you never know. So I gotta go ask some dumb questions here and there. Thanks John. >John -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"svc: unknown version (3)" when CONFIG_NFSD_V4=y
Hi Neil, NFS mounting succeeded, but the kernel gives a warning. I'm running 2.6.20-rc2-mm1. # mount -o vers=3 localhost:/suse /mnt [ 689.651606] svc: unknown version (3) # mount | grep suse localhost:/suse on /mnt type nfs (rw,nfsvers=3,addr=127.0.0.1) Any clues about it? Short .config: # # Automatically generated make config: don't edit # Linux kernel version: 2.6.20-rc2-mm1 # Thu Jan 4 15:55:02 2007 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y .. # # Network File Systems # CONFIG_NFS_FS=m CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y # CONFIG_NFS_V4 is not set CONFIG_NFS_DIRECTIO=y CONFIG_NFSD=m CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFSD_TCP=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=m # CONFIG_SMB_NLS_DEFAULT is not set CONFIG_CIFS=m CONFIG_CIFS_STATS=y # CONFIG_CIFS_STATS2 is not set # CONFIG_CIFS_WEAK_PW_HASH is not set CONFIG_CIFS_XATTR=y CONFIG_CIFS_POSIX=y # CONFIG_CIFS_DEBUG2 is not set # CONFIG_CIFS_EXPERIMENTAL is not set # CONFIG_NCP_FS is not set # CONFIG_CODA_FS is not set # CONFIG_AFS_FS is not set CONFIG_9P_FS=m .. Thanks, Wu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [uml-devel] [PATCH 1/6] UML - Console locking fixes
On Wed, Jan 03, 2007 at 04:07:34PM +0100, Blaisorblade wrote: > > + spin_lock(&line->count_lock); > > + if(!line->valid) > > + goto out_unlock; > > + > > + err = 0; > > + if(tty->count > 1) > > + goto out_unlock; > > > > - /* The IRQ which takes this lock is not yet enabled and won't be run > > -* before the end, so we don't need to use spin_lock_irq.*/ > > - spin_lock(&line->lock); > > + mutex_lock(&line->open_mutex); > > + spin_unlock(&line->count_lock); > > This is an obnoxious thing to do unless you specifically prove otherwise. Didn't I? The proof goes like this: we only take the semaphore if tty->count == 1, in which case we are opening the device for the first time and there can't be anyone else looking at it, so the mutex_lock won't sleep. However, now that you're making me think about it again, I'm wondering about the sanity of introducing a mutex which is guaranteed not to sleep. This is starting to make sense, with (tty->count > 1) being the OPENING flag: > In the first solution, you can create a OPENING flag (via a state variable), > and add the rule that (unlike the count) nobody but the original setter is > allowed to change it, and that who finds it set (say a concurrent open) must > return without touching it. Then, I think the mutex can just be thrown away. Jeff -- Work email - jdike at linux dot intel dot com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: execve hanging in selinux_bprm_post_apply_creds
On Thu, Jan 04, 2007 at 16:03:34 -0800, Andrew Morton wrote: > On Fri, 5 Jan 2007 00:26:42 +0200 > Sami Farin <[EMAIL PROTECTED]> wrote: > > > Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk. > > After a while or two programs stopped responding and I had to reboot. > > > > I'm not sure is this bug or feature... > > bug ;) =) > > 2007-01-04 22:41:55.360538500 <4>softlimit D 61707865 0 18679 > > 18678 (NOTLB) > > 2007-01-04 22:41:55.360549500 <4> ec5efdd0 0046 f8964fda 61707865 > > 006a 0072 0043 005b > > 2007-01-04 22:41:55.360551500 <4> f7264580 00a9 00fb 000e > > 00cc 0055 c1805700 f4f2e13c > > 2007-01-04 22:41:55.360553500 <4> 0001be4d 1f64183b 073d f4f2e030 > > c05785ac 0246 f4f2e030 ec5efe18 > > 2007-01-04 22:41:55.360554500 <4>Call Trace: > > 2007-01-04 22:41:55.360571500 <4> [] > > __mutex_lock_slowpath+0x85/0x1df > > 2007-01-04 22:41:55.360572500 <4> [] mutex_lock+0x21/0x24 > > 2007-01-04 22:41:55.360573500 <4> [] > > selinux_bprm_post_apply_creds+0x65/0x40a > > 2007-01-04 22:41:55.360575500 <4> [] compute_creds+0x4f/0x52 > > 2007-01-04 22:41:55.360576500 <4> [] load_elf_binary+0x944/0xd0e > > 2007-01-04 22:41:55.360589500 <4> [] > > search_binary_handler+0x9a/0x24c > > 2007-01-04 22:41:55.360590500 <4> [] do_execve+0x163/0x1f1 > > 2007-01-04 22:41:55.360592500 <4> [] sys_execve+0x32/0x84 > > 2007-01-04 22:41:55.360593500 <4> [] syscall_call+0x7/0xb > > 2007-01-04 22:41:55.360594500 <4> [<00ecc410>] 0xecc410 > > 2007-01-04 22:41:55.360620500 <4> === > > > > ... > > > > 2007-01-04 22:41:55.359020500 <4>crond D DDC59E64 0 18627 > > 1837 18668 (NOTLB) > > 2007-01-04 22:41:55.359022500 <4> ddc59e78 0046 c01454c5 ddc59e64 > > ddc59e58 c04f4d56 ddc59e74 00d0 > > 2007-01-04 22:41:55.359033500 <4> f7a50ac0 f78d8a5e 06e3 11f7 > > c1967030 c17fd700 d10a6b7c > > 2007-01-04 22:41:55.359034500 <4> 000166f0 f78db4eb 06e3 d10a6a70 > > c05785ac 0246 d10a6a70 ddc59ec0 > > 2007-01-04 22:41:55.359036500 <4>Call Trace: > > 2007-01-04 22:41:55.359037500 <4> [] > > __mutex_lock_slowpath+0x85/0x1df > > 2007-01-04 22:41:55.359047500 <4> [] mutex_lock+0x21/0x24 > > 2007-01-04 22:41:55.359049500 <4> [] audit_log_exit+0x120/0x799 > > 2007-01-04 22:41:55.359050500 <4> [] audit_syscall_exit+0x75/0x325 > > 2007-01-04 22:41:55.359051500 <4> [] do_syscall_trace+0x1a5/0x1eb > > -- > > 2007-01-04 22:41:55.359305500 <4> 2d6d 33456ed0 06e5 e7163a70 > > 7fff 7fff ed0aa9e0 e4c03d5c > > 2007-01-04 22:41:55.359306500 <4>Call Trace: > > 2007-01-04 22:41:55.359319500 <4> [] schedule_timeout+0x94/0x96 > > 2007-01-04 22:41:55.359321500 <4> [] > > unix_stream_data_wait+0xa0/0xe7 > > 2007-01-04 22:41:55.359322500 <4> [] > > unix_stream_recvmsg+0x2c1/0x414 > > 2007-01-04 22:41:55.359323500 <4> [] do_sock_read+0xc4/0xcc > > 2007-01-04 22:41:55.359334500 <4> [] sock_aio_read+0x6a/0x7b > > 2007-01-04 22:41:55.359335500 <4> [] do_sync_read+0xca/0x119 > > 2007-01-04 22:41:55.359337500 <4> [] vfs_read+0xb4/0x18a > > 2007-01-04 22:41:55.359338500 <4> [] sys_read+0x3d/0x64 > > 2007-01-04 22:41:55.359349500 <4> [] syscall_call+0x7/0xb > > 2007-01-04 22:41:55.359350500 <4> [<00ecc410>] 0xecc410 > > Curious. It look like running restorecon left tty_mutex held. I just did > a full tty_mutex audit on 2.6.20-rc3 and all looks to be OK. > > Is it repeatable? Once in a lifetime. But... system didn't blow up when I ran "restorecon -R /wrk" again after reboot. -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Hi, I own a Sony Vaio VGN-SZ340 and I had problems regarding acpi + it's dual core processor. The guys from Intel gave me a workaround and now it recognises both cores. The problem is that it does not do cpu frequency scaling for both cores, just for cpu0...And when I boot with acpi the Nvidia graphic card doesnt work also. I don't know if you know about these problems regarding sony acpi. The guys from Intel said that this notebook have 2 dst's. So to detect both cores the workaround just uses the second dst (although frequency scaling does work for both.) I can help you to fix this bug...I have the machine where we can do some tests.. Best regards, On 1/4/07, Andrew Morton <[EMAIL PROTECTED]> wrote: On Fri, 05 Jan 2007 00:36:23 +0100 Stelian Pop <[EMAIL PROTECTED]> wrote: > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem, > and made correspondent necessary changes for this to work. neato. err, how does one use this? - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cx88xx: Fix lockup on suspend
Suspending with the cx88xx module loaded causes the system to lock up because the cx88_audio_thread kthread was missing a try_to_freeze() call, which caused it to go into a tight loop and result in softlockup when suspending. Fix that. Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> --- linux-2.6.20-rc3-git4-orig/drivers/media/video/cx88/cx88-tvaudio.c 2007-01-04 19:51:45.0 -0600 +++ linux-2.6.20-rc3-git4/drivers/media/video/cx88/cx88-tvaudio.c 2007-01-04 19:25:19.0 -0600 @@ -38,6 +38,7 @@ #include #include #include +#include #include #include #include @@ -961,6 +962,7 @@ int cx88_audio_thread(void *data) msleep_interruptible(1000); if (kthread_should_stop()) break; + try_to_freeze(); /* just monitor the audio status for now ... */ memset(&t, 0, sizeof(t)); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: S.M.A.R.T no longer available in 2.6.20-rc2-mm2 with libata
On Thursday 04 January 2007 17:12, Ed Sweetman wrote: >Alistair John Strachan wrote: >> On Thursday 04 January 2007 01:50, Ed Sweetman wrote: >>> Not sure what went on between 2.6.19-rc5-mm2 and 2.6.20-rc2-mm2 in >>> libata land but SMART is no longer available on my hdds. I'm >>> assuming this is not the intended behavior. >>> >>> In case this is chipset specific, IDE interface: nVidia Corporation >>> CK804 Serial ATA Controller (rev f3) >>> >>> I'm using Libata nvidia driver, the drives happen to be sata drives, >>> but even the pata ones no longer report having SMART. >> >> What program are you trying to use here? As I reported around -rc1 >> time, hddtemp is broken by 2.6.20-rc but Jens posted a patch to fix >> it. > Which I believe must already be in -rc3. I just started it after configuring it, restarted gkrellm and there they all were. But I haven't tried any earlier kernels with it either. >I must have missed that blurb. hddtemp is indeed the program I was >looking at. And it does seem that it is the only one broken. Just >re-installed the other smartctl tools and they do work. Thanks. >- >To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in the body of a message to [EMAIL PROTECTED] >More majordomo info at http://vger.kernel.org/majordomo-info.html >Please read the FAQ at http://www.tux.org/lkml/ -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2007 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 8/8] user ns: implement user ns unshare
On Thu, 04 Jan 2007 16:52:53 CST, "Serge E. Hallyn" said: > Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]): > > On Thu, 04 Jan 2007 19:07:00 GMT, Frederik Deweerdt said: > > > > int err = 0; > > > > > > The "= 0" is superfluous here. > > > > Umm? bss gets cleared automagically, but when did we start auto-zeroing > > the stack? > > No, no, that's what i thought he meant at first too, but I actually > manually set err on all paths anyway :) Oh. So it's *really* just "superfluous until somebody changes the code"... pgpNkBEJKrvoT.pgp Description: PGP signature
2.6.20-rc3-git4 oops on suspend: __drain_pages
Saw this oops on 2.6.20-rc3-git4 when attempting to suspend. This only happened in 1 of 3 attempts. Jan 4 19:36:43 newcastle kernel: Linux version 2.6.20-rc3-git4 ([EMAIL PROTECTED]) (gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)) #1 SMP Thu Jan 4 19:24:09 CST 2007 Jan 4 19:36:43 newcastle kernel: Command line: ro root=/dev/VolGroup00/LogVol00 Jan 4 19:36:43 newcastle kernel: BIOS-provided physical RAM map: Jan 4 19:36:43 newcastle kernel: BIOS-e820: - 0009f400 (usable) Jan 4 19:36:43 newcastle kernel: BIOS-e820: 0009f400 - 000a (reserved) Jan 4 19:36:43 newcastle kernel: BIOS-e820: 000f - 0010 (reserved) Jan 4 19:36:43 newcastle kernel: BIOS-e820: 0010 - 7fff (usable) Jan 4 19:36:43 newcastle kernel: BIOS-e820: 7fff - 7fff3000 (ACPI NVS) Jan 4 19:36:43 newcastle kernel: BIOS-e820: 7fff3000 - 8000 (ACPI data) Jan 4 19:36:43 newcastle kernel: BIOS-e820: e000 - f000 (reserved) Jan 4 19:36:43 newcastle kernel: BIOS-e820: fec0 - 0001 (reserved) Jan 4 19:36:43 newcastle kernel: end_pfn_map = 1048576 Jan 4 19:36:43 newcastle kernel: DMI 2.3 present. Jan 4 19:36:43 newcastle kernel: SRAT: PXM 0 -> APIC 0 -> Node 0 Jan 4 19:36:43 newcastle kernel: SRAT: PXM 0 -> APIC 1 -> Node 0 Jan 4 19:36:43 newcastle kernel: SRAT: Node 0 PXM 0 0-a Jan 4 19:36:44 newcastle kernel: SRAT: Node 0 PXM 0 0-8000 Jan 4 19:36:44 newcastle kernel: Bootmem setup node 0 -7fff Jan 4 19:36:44 newcastle kernel: Zone PFN ranges: Jan 4 19:36:44 newcastle kernel: DMA 0 -> 4096 Jan 4 19:36:44 newcastle kernel: DMA324096 -> 1048576 Jan 4 19:36:44 newcastle kernel: Normal1048576 -> 1048576 Jan 4 19:36:44 newcastle kernel: early_node_map[2] active PFN ranges Jan 4 19:36:44 newcastle kernel: 0:0 -> 159 Jan 4 19:36:44 newcastle kernel: 0: 256 -> 524272 Jan 4 19:36:44 newcastle kernel: Nvidia board detected. Ignoring ACPI timer override. Jan 4 19:36:44 newcastle kernel: If you got timer trouble try acpi_use_timer_override Jan 4 19:36:44 newcastle kernel: ACPI: PM-Timer IO Port: 0x4008 Jan 4 19:36:44 newcastle kernel: ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Jan 4 19:36:44 newcastle kernel: Processor #0 (Bootup-CPU) Jan 4 19:36:44 newcastle kernel: ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Jan 4 19:36:44 newcastle kernel: Processor #1 Jan 4 19:36:44 newcastle kernel: ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) Jan 4 19:36:44 newcastle kernel: ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) Jan 4 19:36:44 newcastle kernel: ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) Jan 4 19:36:44 newcastle kernel: IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 Jan 4 19:36:45 newcastle kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) Jan 4 19:36:45 newcastle kernel: ACPI: BIOS IRQ0 pin2 override ignored. Jan 4 19:36:45 newcastle kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Jan 4 19:36:45 newcastle kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 14 high edge) Jan 4 19:36:45 newcastle kernel: ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 15 high edge) Jan 4 19:36:45 newcastle kernel: Setting APIC routing to physical flat Jan 4 19:36:45 newcastle kernel: Using ACPI (MADT) for SMP configuration information Jan 4 19:36:45 newcastle kernel: Nosave address range: 0009f000 - 000a Jan 4 19:36:45 newcastle kernel: Nosave address range: 000a - 000f Jan 4 19:36:45 newcastle kernel: Nosave address range: 000f - 0010 Jan 4 19:36:46 newcastle kernel: Allocating PCI resources starting at 8800 (gap: 8000:6000) Jan 4 19:36:46 newcastle kernel: SMP: Allowing 2 CPUs, 0 hotplug CPUs Jan 4 19:36:46 newcastle kernel: PERCPU: Allocating 67264 bytes of per cpu data Jan 4 19:36:46 newcastle kernel: Built 1 zonelists. Total pages: 514297 Jan 4 19:36:46 newcastle kernel: Kernel command line: ro root=/dev/VolGroup00/LogVol00 Jan 4 19:36:46 newcastle kernel: Initializing CPU#0 Jan 4 19:36:46 newcastle kernel: PID hash table entries: 4096 (order: 12, 32768 bytes) Jan 4 19:36:46 newcastle kernel: Console: colour VGA+ 80x25 Jan 4 19:36:46 newcastle kernel: Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Jan 4 19:36:46 newcastle kernel: Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Jan 4 19:36:46 newcastle kernel: Checking aperture... Jan 4 19:36:46 newcastle kernel: CPU 0: aperture @ 63000 size 32 MB Jan 4 19:36:46 newcastle kernel: Aperture too small (32 MB) Jan 4 19:36:46 newcastle kernel: No AGP bridge found Jan 4 19:36:46 newcastle kernel: Memory: 2051468k/2097088k available (2230k kernel code, 45232k reserve
[PATCH] All Transmeta CPUs have constant TSCs
[i386] All Transmeta CPUs have constant TSCs All Transmeta CPUs ever produced have constant-rate TSCs. Signed-off-by: H. Peter Anvin <[EMAIL PROTECTED]> --- commit 07e54489ef8a3341b20ae42b53b1254a68061204 tree 204fa19fe2b2dd3ddb1add83ec66ccda7360f4e6 parent 7523c4dd9923cab748dad9b79d0165e118e3d03b author H. Peter Anvin <[EMAIL PROTECTED]> Thu, 04 Jan 2007 17:44:34 -0800 committer H. Peter Anvin <[EMAIL PROTECTED]> Thu, 04 Jan 2007 17:44:34 -0800 arch/i386/kernel/cpu/transmeta.c |3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/arch/i386/kernel/cpu/transmeta.c b/arch/i386/kernel/cpu/transmeta.c index 4056fb7..b536e81 100644 --- a/arch/i386/kernel/cpu/transmeta.c +++ b/arch/i386/kernel/cpu/transmeta.c @@ -72,6 +72,9 @@ static void __cpuinit init_transmeta(struct cpuinfo_x86 *c) wrmsr(0x80860004, ~0, uk); c->x86_capability[0] = cpuid_edx(0x0001); wrmsr(0x80860004, cap_mask, uk); + + /* All Transmeta CPUs have a constant TSC */ + set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability); /* If we can run i686 user-space code, call us an i686 */ #define USER686 (X86_FEATURE_TSC|X86_FEATURE_CX8|X86_FEATURE_CMOV) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc2-mm1: INFO: possible recursive locking detected in con_close
On Fri, Dec 29, 2006 at 11:00:41AM +, Frederik Deweerdt wrote:
> On Thu, Dec 28, 2006 at 10:25:12PM +0100, Laurent Riffard wrote:
> > Le 28.12.2006 11:42, Andrew Morton a ?crit :
> > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc2/2.6.20-rc2-mm1/
> >
> > Hello,
> >
> > got this with 2.6.20-rc2-mm1, reverting
> > gregkh-driver-driver-core-fix-race-in-sysfs-between-sysfs_remove_file-and-read-write.patch
> > made it disappear.
> >
> Hi,
>
> This is due to sysfs_hash_and_remove() holding dir->d_inode->i_mutex
> before calling sysfs_drop_dentry() which calls orphan_all_buffers()
> which in turn takes node->i_mutex.
> The following patch solves the problem by defering the buffers orphaning
> after the dir->d_inode->imutex is released. Not sure it's the best
> solution though, Greg?
>
> Regards,
> Frederik
>
> Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]>
Maneesh and Oliver, any objections to this patch?
thanks,
greg k-h
>
> diff --git a/fs/sysfs/inode.c b/fs/sysfs/inode.c
> index 8c533cb..7cac0b6 100644
> --- a/fs/sysfs/inode.c
> +++ b/fs/sysfs/inode.c
> @@ -230,10 +230,10 @@ static inline void orphan_all_buffers(struct inode
> *node)
> * Unhashes the dentry corresponding to given sysfs_dirent
> * Called with parent inode's i_mutex held.
> */
> -void sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry * parent)
> +struct inode *sysfs_drop_dentry(struct sysfs_dirent * sd, struct dentry *
> parent)
> {
> struct dentry * dentry = sd->s_dentry;
> - struct inode *inode;
> + struct inode *inode = NULL;
>
> if (dentry) {
> spin_lock(&dcache_lock);
> @@ -248,19 +248,19 @@ void sysfs_drop_dentry(struct sysfs_dirent * sd, struct
> dentry * parent)
> spin_unlock(&dentry->d_lock);
> spin_unlock(&dcache_lock);
> simple_unlink(parent->d_inode, dentry);
> - orphan_all_buffers(inode);
> - iput(inode);
> } else {
> spin_unlock(&dentry->d_lock);
> spin_unlock(&dcache_lock);
> }
> }
> + return inode;
> }
>
> int sysfs_hash_and_remove(struct dentry * dir, const char * name)
> {
> struct sysfs_dirent * sd;
> struct sysfs_dirent * parent_sd;
> + struct inode *inode;
> int found = 0;
>
> if (!dir)
> @@ -277,7 +277,7 @@ int sysfs_hash_and_remove(struct dentry * dir, const char
> * name)
> continue;
> if (!strcmp(sysfs_get_name(sd), name)) {
> list_del_init(&sd->s_sibling);
> - sysfs_drop_dentry(sd, dir);
> + inode = sysfs_drop_dentry(sd, dir);
> sysfs_put(sd);
> found = 1;
> break;
> @@ -285,5 +285,10 @@ int sysfs_hash_and_remove(struct dentry * dir, const
> char * name)
> }
> mutex_unlock(&dir->d_inode->i_mutex);
>
> + if (found == 1 && inode) {
> + orphan_all_buffers(inode);
> + iput(inode);
> + }
> +
> return found ? 0 : -ENOENT;
> }
> diff --git a/fs/sysfs/sysfs.h b/fs/sysfs/sysfs.h
> index 5100a12..ef9d217 100644
> --- a/fs/sysfs/sysfs.h
> +++ b/fs/sysfs/sysfs.h
> @@ -17,7 +17,7 @@ extern int sysfs_create_subdir(struct kobject *, const char
> *, struct dentry **)
> extern void sysfs_remove_subdir(struct dentry *);
>
> extern const unsigned char * sysfs_get_name(struct sysfs_dirent *sd);
> -extern void sysfs_drop_dentry(struct sysfs_dirent *sd, struct dentry
> *parent);
> +extern struct inode * sysfs_drop_dentry(struct sysfs_dirent *sd, struct
> dentry *parent);
> extern int sysfs_setattr(struct dentry *dentry, struct iattr *iattr);
>
> extern struct rw_semaphore sysfs_rename_sem;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] X.25: Trivial, SOCK_DEBUG's in x25_facilities missing newlines
From: ahendry <[EMAIL PROTECTED]> Date: Thu, 04 Jan 2007 15:39:24 +1100 > Trivial. Newlines missing on the SOCK_DEBUG's for X.25 facility negotiation. > > Signed-off-by: Andrew Hendry <[EMAIL PROTECTED]> Applied, thanks Andrew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: LSIFC909 mpt card fails to recognize devices
On Thu, 04 Jan 2007 19:06:46 -0500 Justin Rosander <[EMAIL PROTECTED]> wrote: > Please forward this to the appropriate maintainer. Thank you. > > [1.] One line summary of the problem:My fibre channel drives fail to > be recognized by my LSIFC909 card. Please send the output of `lspci -vn' - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Heads up on a series of AIO patchsets
generic_write_checks() are done in the submission path, not
repeated during
retries, so such types of checks are not intended to run in the aio
thread.
Ah, I see, I was missing the short-cut which avoids re-running parts
of the write path if we're in a retry.
if (!is_sync_kiocb(iocb) && kiocbIsRestarted(iocb)) {
/* nothing to transfer, may just need to sync data */
return ocount;
It's pretty subtle that this has to be placed before the first
significant current reference and that nothing in the path can return
-EIOCBRETRY until after all of the significant current references.
In totally unrelated news, I noticed that current->io_wait is set to
NULL instead of ¤t->__wait after having run the iocb. I wonder
if it shouldn't be saved and restored instead. And maybe update the
comment over is_sync_wait()? Just an observation.
That is great and I look forward to it :) I am, however assuming that
whatever implementation you come up will have a different interface
from current linux aio -- i.e. a next generation aio model, that
will be
easily integratable with kevents etc.
Yeah, that's the hope.
Which takes me back to Ingo's point - lets have the new evolve
parallely
with the old, if we can, and not hold up the patches for POSIX AIO to
start using kernel AIO, or for epoll to integrate with AIO.
Sure, though there are only so many hours in a day :).
OK, I just took a quick look at your blog and I see that you
are basically implementing Linus' microthreads scheduling approach -
one year since we had that discussion.
Yeah. I wanted to see what it would look like.
Glad to see that you found a way to make it workable ...
We, that remains to be seen. If nothing else we'll at least hav
code to point at when discussing it. If we all agree it's not the
right way and dismiss the notion, fine, that's progress :).
(I'm guessing that you are copying over the part
of the stack in use at the time of every switch, is that correct ?
That was my first pass, yeah. It turned the knob a little too far
towards the "invasive but efficient" direction for my taste. I'm now
giving it a try by having full stacks for each blocked op, we'll see
how that goes.
At what
point do you do the allocation of the saved stacks ?
I was allocating at block-time to keep memory consumption down, but I
think my fiddling around with it convinced me that isn't workable.
- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Sdhci-devel] sdhci ubuntu problem.
Dnia 03-01-2007, śro o godzinie 22:21 +0100, Pierre Ossman napisał(a): > emilus wrote: > > Uff... > > I just change system back to debian because of other problems with > > Ubuntu. > > And suprise ... SD doesn't work! I'm very suprised... > > There was no problem before. Card reader works with 2GB cards too and > > everything was fine. > > So I have installed the newest kernel 2.6.19 without succes. > > but I found that there is a specific drivers for my TI (in 2.6.19) so I > > > > Ah... didn't notice that it was a TI controller you had. Then you > usually need an ugly setpci hack for it to work with sdhci. But the new > tifm_sd driver is the preferred solution. > > > try it. And nothing better... but. > > when card is inserted in card reader at boot time sth. happen. > > I attach dmesg with it. > > > > As you have ndiswrapper rearing its ugly head just above, I would guess > it starts up your wlan card at interrupt 21 and kills it. I would > suggest trying without ndiswrapper loaded. > > As this is now a tifm_sd related issue, I would recommend that Alex > Dubov takes over and the list of choice being the kernel mailing list > (both cc:d). Ok... I started fight with tifm driver. I made a 2.6.18 kernel from debian by debian way with mmc debug enabled and downloaded tifm source v. 0.6. I made this module separately just by make/make install. I put tifm_7xx1 tifm_sd into /etc/modules. and everything working perfect. there is no ndiswrapper problem with irq. thx for help ew - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc3: known unfixed regressions (v3)
Adrian Bunk <[EMAIL PROTECTED]> wrote: > This email lists some known regressions in 2.6.20-rc3 compared to 2.6.19 > that are not yet fixed in Linus' tree. > > If you find your name in the Cc header, you are either submitter of one > of the bugs, maintainer of an affectected subsystem or driver, a patch > of you caused a breakage or I'm considering you in any other way possibly > involved with one or more of these issues. > > Due to the huge amount of recipients, please trim the Cc when answering. [...] > Subject: SPARC64: Can't mount / (CONFIG_SCSI_SCAN_ASYNC=y ?) > References : http://lkml.org/lkml/2006/12/13/181 > http://lkml.org/lkml/2007/01/04/75 > Submitter : Horst H. von Brand <[EMAIL PROTECTED]> > Status : unknown Fixed in 2.6.20-rc3 (perhaps was due to SCSI_SCAN_ASYNC) -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de InformaticaFono: +56 32 2654431 Universidad Tecnica Federico Santa Maria +56 32 2654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 2797513 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] containers: Generic Process Containers (V6)
Hi Serge, On 1/3/07, Serge E. Hallyn <[EMAIL PROTECTED]> wrote: From: Serge E. Hallyn <[EMAIL PROTECTED]> Subject: [RFC] [PATCH 1/1] container: define a namespace container subsystem Here's a stab at a namespace container subsystem based on Paul Menage's containers patch, just to experiment with how semantics suit what we want. Thanks for looking at this. What you have here is the basic boilerplate for any generic container subsystem. I realise that my current containers patch has some incompatibilities with the way that nsproxy wants to work. A few things we'll want to address: 1. We'll want to be able to hook things like rmdir, so that we can rm -rf /containers/vserver1 to kill all processes in that container and all child containers. The current model is that rmdir fails if there are any processes still in the container; so you'd have to kill processes by looking for pids in the "tasks" info file. This was behaviour inherited from the cpusets code; I'd be open to making this more configurable (e.g. specifying that rmdir should try to kill any remaining tasks). 2. We need a semantic difference between attaching to a container, and being the first to join the container you just created. Right - the way to do this would probably be some kind of "container_clone()" function that duplicates the properties of the current container in a child, and immediately moves the current process into that container. 3. We will want to be able to give the container attach function more info, so that we can ask to attach to just the network namespace, but none of the others, in the container we're attaching to. If you want to be able to attach to different namespaces separately, then possibly they should be separate container subsystems? Paul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
On Jan 5 2007 00:36, Stelian Pop wrote:
>@@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv
>
> static acpi_handle sony_acpi_handle;
> static struct proc_dir_entry *sony_acpi_dir;
>+static struct acpi_device *sony_acpi_acpi_device = NULL;
acpi_acpi?
>@@ -310,7 +315,7 @@ static int sony_acpi_add(struct acpi_dev
>item->acpiset, &handle)))
> continue;
>
>- item->proc = create_proc_entry(item->name, 0600,
>+ item->proc = create_proc_entry(item->name, 0666,
> acpi_device_dir(device));
> if (!item->proc) {
> printk(LOG_PFX "unable to create proc entry\n");
Is this safe? I would not want normal users to poke on that.
-`J'
--
Himself owner of a VAIO U3.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Multi kernel tree support on the same distro?
Akula2 wrote: Hello All, I am looking to use multiple kernel trees on the same distro. Example:- 2.6.19.1 for - software/tools development 2.4.34for - embedded systems development. I do know that 2.6 supports embedded in a big waybut still requirement demands to work with such boards as an example:- http://www.embeddedarm.com/linux/ARM.htm My question is HOW-TO enable a distro with multi kernel trees? Presently am using Fedora Core 5/6 for much of the development activities (Cell BE SDK related at Labs). Any hints/suggestions would be a great leap for me to do this on my own. this is really no big problem (as in: works OOTB), except that if you want to boot & run both kernels on the same (rootfs) installation, you will need to create wrappers around modutils and module-init-tools, as well as udev/devfs, or whichever device file system you prefer to use for each kernel. There are a few minor other details but none really shocking. We've done this for "our" source distro, and it works just fine. Cheers, Auke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PROBLEM: LSIFC909 mpt card fails to recognize devices
Hello,
Please forward this to the appropriate maintainer. Thank you.
[1.] One line summary of the problem:My fibre channel drives fail to
be recognized by my LSIFC909 card.
[2.] Full description of the problem/report: see #1.
[3.] Keywords (i.e., modules, networking, kernel):
[4.] Kernel version (from /proc/version): 2.6.17-rt3
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
[6.] A small shell script or example program which triggers the
problem (if possible)
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
If some fields are empty or look unusual you may have an old version.
Compare to the current minimal requirements in Documentation/Changes.
Linux pelleas 2.6.17-rt3 #1 PREEMPT Thu Jan 4 00:25:15 EST 2007 i686 GNU/Linux
Gnu C 4.1.2 Gnu make 3.81
binutils 2.17 util-linux 2.12r
mount 2.12r module-init-tools 3.3-pre2
e2fsprogs 1.39 xfsprogs 2.8.11
PPP2.4.4 Linux C Library2.3.6 Dynamic
linker (ldd) 2.3.6 Procps 3.2.7
Net-tools 1.60 Console-tools 0.2.3
Sh-utils 5.96 udev 100
Modules Loaded mptctl mptfc mptscsih mptbase nvidia ppdev lp ipv6
dm_mod it87 hwmon_vid eeprom i2c_isa i2c_viapro snd_emu10k1_synth
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_seq_dummy
snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq tda9887 tuner
sd_mod snd_emu10k1 shpchp snd_rawmidi snd_ac97_codec snd_ac97_bus
pci_hotplug snd_pcm_oss snd_mixer_oss saa7134 video_buf compat_ioctl32
v4l2_common v4l1_compat snd_pcm snd_seq_device ir_kbd_i2c snd_timer
snd_page_alloc snd_util_mem snd_hwdep ir_common snd i2c_core psmouse
via_agp agpgart rtc eth1394 videodev analog evdev hci_usb joydev
mousedev pcspkr tsdev soundcore 8250_pnp bluetooth serio_raw ns558
gameport usblp parport_pc parport floppy ext3 jbd mbcache usb_storage
ide_cd cdrom ide_disk usbhid via82cxxx ohci1394 ieee1394 generic
ide_core scsi_transport_fc scsi_mod uhci_hcd ehci_hcd usbcore via_rhine
mii thermal processor fan
[7.2.] Processor information (from /proc/cpuinfo):
[7.3.] Module information (from /proc/modules):
mptctl 22468 0 - Live 0xd0d56000
mptfc 12872 0 - Live 0xd085a000
mptscsih 21376 1 mptfc, Live 0xd0cc8000
mptbase 46048 3 mptctl,mptfc,mptscsih, Live 0xd087d000
sd_mod 18952 0 - Live 0xd0aa8000
scsi_mod 123528 5 mptfc,mptscsih,sd_mod,usb_storage,scsi_transport_fc, Live
0xd08a4000
[7.4.] Loaded driver and hardware information (/proc/ioports, /proc/iomem)
[7.5.] PCI information ('lspci -vvv' as root)
[7.6.] SCSI information (from /proc/scsi/scsi)
[7.7.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
[X.] Other notes, patches, fixes, workarounds:
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: execve hanging in selinux_bprm_post_apply_creds
On Fri, 5 Jan 2007 00:26:42 +0200 Sami Farin <[EMAIL PROTECTED]> wrote: > Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk. > After a while or two programs stopped responding and I had to reboot. > > I'm not sure is this bug or feature... bug ;) > I upgraded selinux policy before running restorecon. > > 2007-01-04 22:41:55.360538500 <4>softlimit D 61707865 0 18679 18678 >(NOTLB) > 2007-01-04 22:41:55.360549500 <4> ec5efdd0 0046 f8964fda 61707865 > 006a 0072 0043 005b > 2007-01-04 22:41:55.360551500 <4> f7264580 00a9 00fb 000e > 00cc 0055 c1805700 f4f2e13c > 2007-01-04 22:41:55.360553500 <4> 0001be4d 1f64183b 073d f4f2e030 > c05785ac 0246 f4f2e030 ec5efe18 > 2007-01-04 22:41:55.360554500 <4>Call Trace: > 2007-01-04 22:41:55.360571500 <4> [] > __mutex_lock_slowpath+0x85/0x1df > 2007-01-04 22:41:55.360572500 <4> [] mutex_lock+0x21/0x24 > 2007-01-04 22:41:55.360573500 <4> [] > selinux_bprm_post_apply_creds+0x65/0x40a > 2007-01-04 22:41:55.360575500 <4> [] compute_creds+0x4f/0x52 > 2007-01-04 22:41:55.360576500 <4> [] load_elf_binary+0x944/0xd0e > 2007-01-04 22:41:55.360589500 <4> [] > search_binary_handler+0x9a/0x24c > 2007-01-04 22:41:55.360590500 <4> [] do_execve+0x163/0x1f1 > 2007-01-04 22:41:55.360592500 <4> [] sys_execve+0x32/0x84 > 2007-01-04 22:41:55.360593500 <4> [] syscall_call+0x7/0xb > 2007-01-04 22:41:55.360594500 <4> [<00ecc410>] 0xecc410 > 2007-01-04 22:41:55.360620500 <4> === > > ... > > 2007-01-04 22:41:55.359020500 <4>crond D DDC59E64 0 18627 1837 >18668 (NOTLB) > 2007-01-04 22:41:55.359022500 <4> ddc59e78 0046 c01454c5 ddc59e64 > ddc59e58 c04f4d56 ddc59e74 00d0 > 2007-01-04 22:41:55.359033500 <4> f7a50ac0 f78d8a5e 06e3 11f7 > c1967030 c17fd700 d10a6b7c > 2007-01-04 22:41:55.359034500 <4> 000166f0 f78db4eb 06e3 d10a6a70 > c05785ac 0246 d10a6a70 ddc59ec0 > 2007-01-04 22:41:55.359036500 <4>Call Trace: > 2007-01-04 22:41:55.359037500 <4> [] > __mutex_lock_slowpath+0x85/0x1df > 2007-01-04 22:41:55.359047500 <4> [] mutex_lock+0x21/0x24 > 2007-01-04 22:41:55.359049500 <4> [] audit_log_exit+0x120/0x799 > 2007-01-04 22:41:55.359050500 <4> [] audit_syscall_exit+0x75/0x325 > 2007-01-04 22:41:55.359051500 <4> [] do_syscall_trace+0x1a5/0x1eb > -- > 2007-01-04 22:41:55.359305500 <4> 2d6d 33456ed0 06e5 e7163a70 > 7fff 7fff ed0aa9e0 e4c03d5c > 2007-01-04 22:41:55.359306500 <4>Call Trace: > 2007-01-04 22:41:55.359319500 <4> [] schedule_timeout+0x94/0x96 > 2007-01-04 22:41:55.359321500 <4> [] unix_stream_data_wait+0xa0/0xe7 > 2007-01-04 22:41:55.359322500 <4> [] unix_stream_recvmsg+0x2c1/0x414 > 2007-01-04 22:41:55.359323500 <4> [] do_sock_read+0xc4/0xcc > 2007-01-04 22:41:55.359334500 <4> [] sock_aio_read+0x6a/0x7b > 2007-01-04 22:41:55.359335500 <4> [] do_sync_read+0xca/0x119 > 2007-01-04 22:41:55.359337500 <4> [] vfs_read+0xb4/0x18a > 2007-01-04 22:41:55.359338500 <4> [] sys_read+0x3d/0x64 > 2007-01-04 22:41:55.359349500 <4> [] syscall_call+0x7/0xb > 2007-01-04 22:41:55.359350500 <4> [<00ecc410>] 0xecc410 > Curious. It look like running restorecon left tty_mutex held. I just did a full tty_mutex audit on 2.6.20-rc3 and all looks to be OK. Is it repeatable? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc2-mm1 -- INFO: possible recursive locking detected
On Thu, Jan 04, 2007 at 11:50:02PM +, Hugh Dickins wrote: > On Thu, 4 Jan 2007, Greg KH wrote: > > On Sat, Dec 30, 2006 at 02:47:20AM -0800, Miles Lane wrote: > > > Sorry Andrew, I am not sure which maintainer to contact about this. I > > > CCed gregkh for sysfs and Yi for ipw2200. Hopefully this is helpful. > > > BTW, I also found that none of my network drivers were recognized by > > > hal (lshal did not show their "net" entries) unless I set > > > CONFIG_SYSFS_DEPRECATED=y. I am running Ubuntu development (Feisty > > > Fawn), so it seems like I ought to be running pretty current hal > > > utilities: hal-device-manager 0.5.8.1-4ubuntu1. After > > > reenabling CONFIG_SYSFS_DEPRECATED, I am able to use my IPW2200 > > > driver, in spite of this recursive locking message, so this INFO > > > message may not indicate a problem. > > > > Does this show up on the 2.6.20-rc3 kernel too? > > Yes. Well, I can't speak for Miles on Ubuntu, but I have ipw2200 > on openSUSE 10.2 (using ifplugd if that matters), and have to build > my 2.6.20-rc3 with CONFIG_SYSFS_DEPRECATED=y in order to get an IP > address (no idea whether it's a hald issue in my case). Likewise > needed CONFIG_SYSFS_DEPRECATED=y with 2.6.19-rc-mm on SuSE 10.1. I was referring to the locking traceback :) But anyway, Kay, I thought that 10.2 would work with CONFIG_SYSFS_DEPRECATED=y? And yes, 10.1 I know will not work that way, but as it's not supported anymore, that's not a big deal :) > --- 2.6.20-rc3/init/Kconfig 2007-01-01 10:30:46.0 + > +++ linux/init/Kconfig2007-01-04 23:36:40.0 + > @@ -266,7 +266,7 @@ config SYSFS_DEPRECATED > that belong to a class, back into the /sys/class heirachy, in > order to support older versions of udev. > > - If you are using a distro that was released in 2006 or later, > + If you are using a distro that was released in 2008 or later, > it should be safe to say N here. Well, I'm using a distro released in 2006 that works just fine (Gentoo unstable, Debian unstable should also work. I think even Gentoo stable works too, but haven't tried that out...) thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 15:44 -0800, Andrew Morton a écrit : > On Fri, 05 Jan 2007 00:36:23 +0100 > Stelian Pop <[EMAIL PROTECTED]> wrote: > > > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi > > subsystem, > > and made correspondent necessary changes for this to work. > > neato. > > err, how does one use this? :) Well, it seems that on some Vaios (including Nilton's pcg-frv26 but not only this one), the Fn key events aren't seen by sonypi or sony_acpi GHKE method, but do generate an ACPI notify event. For those laptops, the patch forwards the ACPI event to the ACPI system and can be later interpreted in userspace using acpid's /etc/acpi/default.sh (example directly from Nilton): > case "$group" in > button) > case "$action" in > power) /usr/sbin/hibernate > ;; > > lid) cat /proc/acpi/button/lid/LID/state > ;; > > *) logger "ACPI action $action is not defined ($@)" > ;; > esac > ;; > > SNC) echo "$@" > /dev/tcp/localhost/50007 > ;; > > *) logger "ACPI group $group / action $action is not defined" > ;; > esac > > In which I just forward the SNC event to another userspace application > listening on a TCP port. Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
On Thu, Jan 04, 2007 at 03:21:06PM -0800, Mitchell Blank Jr wrote:
> Linus Torvalds wrote:
> > Well, that probably would work, but it's also true that returning a 64-bit
> > value on a 32-bit platform really _does_ depend on more than the size.
>
> Yeah, obviously this is restricted to the signed-integer case. My point
> was just that you could have the compiler figure out which variant to pick
> for loff_t automatically.
>
> > "let's not play tricks with function types at all".
>
> I think I agree. The real (but harder) fix for the wasted space issue
> would be to get the toolchain to automatically combine functions that
> end up compiling into identical assembly.
Can't do.
int f(void)
{
return 0;
}
int g(void)
{
return 0;
}
int is_f(int (*p)(void))
{
return p == f;
}
main()
{
printf("%d %d\n", is_f(f), is_f(g));
}
would better produce
1 0
for anything resembling a sane C compiler. Comparing pointers to
functions for equality is a well-defined operation and it's not
to be messed with.
You _can_ compile g into jump to f, but that's it. And that, AFAICS,
is what gcc does.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-rc2-mm1 -- INFO: possible recursive locking detected
On Thu, 4 Jan 2007, Greg KH wrote: > On Sat, Dec 30, 2006 at 02:47:20AM -0800, Miles Lane wrote: > > Sorry Andrew, I am not sure which maintainer to contact about this. I > > CCed gregkh for sysfs and Yi for ipw2200. Hopefully this is helpful. > > BTW, I also found that none of my network drivers were recognized by > > hal (lshal did not show their "net" entries) unless I set > > CONFIG_SYSFS_DEPRECATED=y. I am running Ubuntu development (Feisty > > Fawn), so it seems like I ought to be running pretty current hal > > utilities: hal-device-manager 0.5.8.1-4ubuntu1. After > > reenabling CONFIG_SYSFS_DEPRECATED, I am able to use my IPW2200 > > driver, in spite of this recursive locking message, so this INFO > > message may not indicate a problem. > > Does this show up on the 2.6.20-rc3 kernel too? Yes. Well, I can't speak for Miles on Ubuntu, but I have ipw2200 on openSUSE 10.2 (using ifplugd if that matters), and have to build my 2.6.20-rc3 with CONFIG_SYSFS_DEPRECATED=y in order to get an IP address (no idea whether it's a hald issue in my case). Likewise needed CONFIG_SYSFS_DEPRECATED=y with 2.6.19-rc-mm on SuSE 10.1. Hugh --- 2.6.20-rc3/init/Kconfig 2007-01-01 10:30:46.0 + +++ linux/init/Kconfig 2007-01-04 23:36:40.0 + @@ -266,7 +266,7 @@ config SYSFS_DEPRECATED that belong to a class, back into the /sys/class heirachy, in order to support older versions of udev. - If you are using a distro that was released in 2006 or later, + If you are using a distro that was released in 2008 or later, it should be safe to say N here. config RELAY - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
On Fri, 05 Jan 2007 00:36:23 +0100 Stelian Pop <[EMAIL PROTECTED]> wrote: > Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi > subsystem, > and made correspondent necessary changes for this to work. neato. err, how does one use this? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: /usr/include/*/acpi.h
Petr Baudis wrote:
On Thu, Jan 04, 2007 at 04:15:45PM CET, Len Brown wrote:
This header files are part of the linux kernel, and thus of course
available in /usr/include/{asm,linux}.
So you pick up all of the kernel include/linux and include/asm*?
(but exclude include/acpi/, which is as much a kernel header as the above)
Yes, we do not exclude any files from the kernel headers package, since
it is safer to have an extra file there than miss something that
something in userspace *could* need - or that is not needed now but can
silently become useful for something userspace in the future. An "all
headers part of the linux kernel" is much safer definition than "a
somewhat random selection of kernel headers".
I wouldn't agree with this. We have what headers are to be used in
userspace now well defined with the "make headers_install" feature in
the kernel, which is what Fedora Core 6 is basing its kernel headers on.
Including all headers is simply asking for userspace to use functions,
etc. from the kernel source which they have no business using.
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 12:51 -0800, Andrew Morton a écrit :
> The place to start (please) is the patches in -mm:
>
> 2.6-sony_acpi4.patch
> sony_apci-resume.patch
> sony_apci-resume-fix.patch
> acpi-add-backlight-support-to-the-sony_acpi.patch
> acpi-add-backlight-support-to-the-sony_acpi-v2.patch
> video-sysfs-support-take-2-add-dev-argument-for-backlight_device_register-sony_acpi-fix.patch
In addition to those, I also have the attached patch in my local tree.
Stelian.
---
Added acpi_bus_generate event for forwarding Fn-keys pressed to acpi subsystem,
and made correspondent necessary changes for this to work.
Signed-off-by: Nilton Volpato <[EMAIL PROTECTED]>
---
drivers/acpi/sony_acpi.c | 55 --
1 files changed, 29 insertions(+), 26 deletions(-)
diff --git a/drivers/acpi/sony_acpi.c b/drivers/acpi/sony_acpi.c
index e23522a..0c9367f 100644
--- a/drivers/acpi/sony_acpi.c
+++ b/drivers/acpi/sony_acpi.c
@@ -33,7 +33,7 @@
#define ACPI_SNC_CLASS "sony"
#define ACPI_SNC_HID "SNY5001"
-#define ACPI_SNC_DRIVER_NAME "ACPI Sony Notebook Control Driver v0.2"
+#define ACPI_SNC_DRIVER_NAME "ACPI Sony Notebook Control Driver v0.3"
#define LOG_PFXKERN_WARNING "sony_acpi: "
@@ -61,6 +61,7 @@ static struct acpi_driver sony_acpi_driv
static acpi_handle sony_acpi_handle;
static struct proc_dir_entry *sony_acpi_dir;
+static struct acpi_device *sony_acpi_acpi_device = NULL;
static struct sony_acpi_value {
char*name; /* name of the entry */
@@ -245,7 +246,9 @@ static int sony_acpi_write(struct file *
static void sony_acpi_notify(acpi_handle handle, u32 event, void *data)
{
- printk(LOG_PFX "sony_acpi_notify\n");
+ if (debug)
+ printk(LOG_PFX "sony_acpi_notify, event: %d\n", event);
+ acpi_bus_generate_event(sony_acpi_acpi_device, 1, event);
}
static acpi_status sony_walk_callback(acpi_handle handle, u32 level,
@@ -269,6 +272,8 @@ static int sony_acpi_add(struct acpi_dev
int result;
struct sony_acpi_value *item;
+ sony_acpi_acpi_device = device;
+
sony_acpi_handle = device->handle;
acpi_driver_data(device) = NULL;
@@ -282,16 +287,16 @@ static int sony_acpi_add(struct acpi_dev
result = -ENODEV;
goto outwalk;
}
+ }
- status = acpi_install_notify_handler(sony_acpi_handle,
-ACPI_DEVICE_NOTIFY,
-sony_acpi_notify,
-NULL);
- if (ACPI_FAILURE(status)) {
- printk(LOG_PFX "unable to install notify handler\n");
- result = -ENODEV;
- goto outnotify;
- }
+ status = acpi_install_notify_handler(sony_acpi_handle,
+ACPI_DEVICE_NOTIFY,
+sony_acpi_notify,
+NULL);
+ if (ACPI_FAILURE(status)) {
+ printk(LOG_PFX "unable to install notify handler\n");
+ result = -ENODEV;
+ goto outnotify;
}
for (item = sony_acpi_values; item->name; ++item) {
@@ -310,7 +315,7 @@ static int sony_acpi_add(struct acpi_dev
item->acpiset, &handle)))
continue;
- item->proc = create_proc_entry(item->name, 0600,
+ item->proc = create_proc_entry(item->name, 0666,
acpi_device_dir(device));
if (!item->proc) {
printk(LOG_PFX "unable to create proc entry\n");
@@ -329,13 +334,11 @@ static int sony_acpi_add(struct acpi_dev
return 0;
outproc:
- if (debug) {
- status = acpi_remove_notify_handler(sony_acpi_handle,
- ACPI_DEVICE_NOTIFY,
- sony_acpi_notify);
- if (ACPI_FAILURE(status))
- printk(LOG_PFX "unable to remove notify handler\n");
- }
+ status = acpi_remove_notify_handler(sony_acpi_handle,
+ ACPI_DEVICE_NOTIFY,
+ sony_acpi_notify);
+ if (ACPI_FAILURE(status))
+ printk(LOG_PFX "unable to remove notify handler\n");
outnotify:
for (item = sony_acpi_values; item->name; ++item)
if (item->proc)
@@ -350,13 +353,13 @@ static int sony_acpi_remove(struct acpi_
acpi_status status;
struct sony_acpi_value *item;
- if (debug) {
- status = acpi_remove_notify_handler(sony_acpi_handle,
-
execve hanging in selinux_bprm_post_apply_creds
Kernel 2.6.19.1 SMP on Pentium D. I ran command restorecon -R /wrk. After a while or two programs stopped responding and I had to reboot. I'm not sure is this bug or feature... I upgraded selinux policy before running restorecon. 2007-01-04 22:41:55.360538500 <4>softlimit D 61707865 0 18679 18678 (NOTLB) 2007-01-04 22:41:55.360549500 <4> ec5efdd0 0046 f8964fda 61707865 006a 0072 0043 005b 2007-01-04 22:41:55.360551500 <4> f7264580 00a9 00fb 000e 00cc 0055 c1805700 f4f2e13c 2007-01-04 22:41:55.360553500 <4> 0001be4d 1f64183b 073d f4f2e030 c05785ac 0246 f4f2e030 ec5efe18 2007-01-04 22:41:55.360554500 <4>Call Trace: 2007-01-04 22:41:55.360571500 <4> [] __mutex_lock_slowpath+0x85/0x1df 2007-01-04 22:41:55.360572500 <4> [] mutex_lock+0x21/0x24 2007-01-04 22:41:55.360573500 <4> [] selinux_bprm_post_apply_creds+0x65/0x40a 2007-01-04 22:41:55.360575500 <4> [] compute_creds+0x4f/0x52 2007-01-04 22:41:55.360576500 <4> [] load_elf_binary+0x944/0xd0e 2007-01-04 22:41:55.360589500 <4> [] search_binary_handler+0x9a/0x24c 2007-01-04 22:41:55.360590500 <4> [] do_execve+0x163/0x1f1 2007-01-04 22:41:55.360592500 <4> [] sys_execve+0x32/0x84 2007-01-04 22:41:55.360593500 <4> [] syscall_call+0x7/0xb 2007-01-04 22:41:55.360594500 <4> [<00ecc410>] 0xecc410 2007-01-04 22:41:55.360620500 <4> === ... 2007-01-04 22:41:55.359020500 <4>crond D DDC59E64 0 18627 1837 18668 (NOTLB) 2007-01-04 22:41:55.359022500 <4> ddc59e78 0046 c01454c5 ddc59e64 ddc59e58 c04f4d56 ddc59e74 00d0 2007-01-04 22:41:55.359033500 <4> f7a50ac0 f78d8a5e 06e3 11f7 c1967030 c17fd700 d10a6b7c 2007-01-04 22:41:55.359034500 <4> 000166f0 f78db4eb 06e3 d10a6a70 c05785ac 0246 d10a6a70 ddc59ec0 2007-01-04 22:41:55.359036500 <4>Call Trace: 2007-01-04 22:41:55.359037500 <4> [] __mutex_lock_slowpath+0x85/0x1df 2007-01-04 22:41:55.359047500 <4> [] mutex_lock+0x21/0x24 2007-01-04 22:41:55.359049500 <4> [] audit_log_exit+0x120/0x799 2007-01-04 22:41:55.359050500 <4> [] audit_syscall_exit+0x75/0x325 2007-01-04 22:41:55.359051500 <4> [] do_syscall_trace+0x1a5/0x1eb -- 2007-01-04 22:41:55.359305500 <4> 2d6d 33456ed0 06e5 e7163a70 7fff 7fff ed0aa9e0 e4c03d5c 2007-01-04 22:41:55.359306500 <4>Call Trace: 2007-01-04 22:41:55.359319500 <4> [] schedule_timeout+0x94/0x96 2007-01-04 22:41:55.359321500 <4> [] unix_stream_data_wait+0xa0/0xe7 2007-01-04 22:41:55.359322500 <4> [] unix_stream_recvmsg+0x2c1/0x414 2007-01-04 22:41:55.359323500 <4> [] do_sock_read+0xc4/0xcc 2007-01-04 22:41:55.359334500 <4> [] sock_aio_read+0x6a/0x7b 2007-01-04 22:41:55.359335500 <4> [] do_sync_read+0xca/0x119 2007-01-04 22:41:55.359337500 <4> [] vfs_read+0xb4/0x18a 2007-01-04 22:41:55.359338500 <4> [] sys_read+0x3d/0x64 2007-01-04 22:41:55.359349500 <4> [] syscall_call+0x7/0xb 2007-01-04 22:41:55.359350500 <4> [<00ecc410>] 0xecc410 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sonypc with Sony Vaio VGN-SZ1VP
Le jeudi 04 janvier 2007 à 20:15 +0100, Mattia Dongili a écrit : > > If someone want to step forward now it is a great time ! > > I have the hw and I'd be happy to do some basic working on the code Cool ! > but: > - I'll probably need some help; Feel free to ask... > - I'll have an almost-blackout between the end of February and the end > of April as I'm moving to a different country and I'll need some time > before I can be active again (I hope I'll have at least easy mail > access for all the time though). Well, I am the current "maintainer" for this and it has probably been a year since I left Sony's laptop world, so I guess it won't make much difference if you're not very active for a month or two :) Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: sata_sil24 lockups under heavy i/o
Mark Wagner wrote:
[1.] One line summary of the problem:
sata_sil24 lockups under heavy i/o
[2.] Full description of the problem/report:
I have a PCI-based sata_sil24 card. It has 4 ports. It was functioning
well with two disks attached. Once I attached 2 additional disks (for
a total of 4) and started heavy i/o (extending a software raid5 device)
the system began locking up for a few minutes at a time. After the
system recovers the disk transfer speed is reduced from UDMA/100 to
UDMA/66 or UDMA/44.
I don't think this is anything to do with the sata_sil24 driver.
Something really wierd seems to be going on with interrupts on this machine:
/proc/interrupts
CPU0
0: 20507744XT-PIC-XTtimer
1:262XT-PIC-XTi8042
2: 0XT-PIC-XTcascade
5: 962175XT-PIC-XTsym53c8xx, uhci_hcd:usb1,
uhci_hcd:usb2
7: 3678XT-PIC-XTparport0
8: 2XT-PIC-XTrtc
10:9153035XT-PIC-XTide2, eth0
11: 30XT-PIC-XTsym53c8xx
12:1026266XT-PIC-XTlibata
14: 840214XT-PIC-XTide0
15: 569928XT-PIC-XTide1
NMI: 11264
LOC: 20506755
ERR:234
MIS: 0
Output of dmesg:
...
Local APIC disabled by BIOS -- reenabling.
Found and enabled local APIC!
Hmm, you might want to try not forcing the local APIC enabled by
removing the lapic option from the kernel command line. Don't know if it
could be related though.
VP_IDE: IDE controller at PCI slot :00:04.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci:00:04.1
ide0: BM-DMA at 0xd800-0xd807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xd808-0xd80f, BIOS settings: hdc:DMA, hdd:DMA
Probing IDE interface ide0...
input: AT Translated Set 2 keyboard as /class/input/input0
hda: MAXTOR STM3160812A, ATA DISK drive
hda: IRQ probe failed (0xfef8)
hdb: WDC WD1600JB-00EVA0, ATA DISK drive
hdb: IRQ probe failed (0xfef8)
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: IC35L120AVVA07-0, ATA DISK drive
hdc: IRQ probe failed (0xbef8)
hdd: WDC WD1200JB-00GVA0, ATA DISK drive
hdd: IRQ probe failed (0xbef8)
These "IRQ proble failed" errors don't seem right at all.
Then:
NETDEV WATCHDOG: eth0: transmit timed out
eth0: transmit timed out, tx_status 00 status e000.
diagnostics: net 0cd8 media 8880 dma 00a0 fifo
Flags; bus-master 1, dirty 203390(14) current 203406(14)
Transmit list 01bea840 vs. c1beaac0.
So eth0's not happy.
ata2.00: exception Emask 0x0 SAct 0x7 SErr 0x0 action 0x6 frozen
ata2.00: tag 0 cmd 0x60 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata2.00: tag 1 cmd 0x60 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata2.00: tag 2 cmd 0x60 Emask 0x4 stat 0x40 err 0x0 (timeout)
ata2: hard resetting port
The SATA card is getting timeouts. And from your other mail:
> hda: DMA timeout error
> hda: dma timeout error: status=0x58 { DriveReady SeekComplete
DataRequest }
> ide: failed opcode was: unknown
> hda: status timeout: status=0xd0 { Busy }
> ide: failed opcode was: unknown
> hda: no DRQ after issuing MULTWRITE_EXT
Your onboard IDE controller is also timing out.. Sounds to me like some
kind of general IRQ problem, though you'd have to be losing interrupts
on IRQ 10, 12 and 14 which seems pretty extreme. Maybe a hardware
problem, are you sure you have enough power to run this many drives in
the box?
--
Robert Hancock Saskatoon, SK, Canada
To email, remove "nospam" from [EMAIL PROTECTED]
Home Page: http://www.roberthancock.com/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
Linus Torvalds wrote:
> On Thu, 4 Jan 2007, Andrew Morton wrote:
>
>> That's what I currently have queued. It increases bad_inode.o text from
>> 200-odd bytes to 700-odd :(
>>
> Then I think we're ok. We do care about bytes, but we care more about
> bytes that actually ever hit the icache or dcache, and this will
> effectively do neither.
>
>
Oh good. Resolution? ;-)
Andrew, if you stick with what you've got, you might want this on top of it.
Mostly cosmetic, making placement of * for pointers consistently " *foo"
not "* foo," (was a mishmash before, from cut-n-paste), but also making
.poll return POLLERR.
Thanks,
-Eric
Signed-off-by: Eric Sandeen <[EMAIL PROTECTED]>
Index: linux-2.6.19/fs/bad_inode.c
===
--- linux-2.6.19.orig/fs/bad_inode.c
+++ linux-2.6.19/fs/bad_inode.c
@@ -46,18 +46,17 @@ static ssize_t bad_file_aio_write(struct
return -EIO;
}
-static int bad_file_readdir(struct file * filp, void * dirent,
- filldir_t filldir)
+static int bad_file_readdir(struct file *filp, void *dirent, filldir_t filldir)
{
return -EIO;
}
static unsigned int bad_file_poll(struct file *filp, poll_table *wait)
{
- return -EIO;
+ return POLLERR;
}
-static int bad_file_ioctl (struct inode * inode, struct file * filp,
+static int bad_file_ioctl (struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg)
{
return -EIO;
@@ -75,12 +74,12 @@ static long bad_file_compat_ioctl(struct
return -EIO;
}
-static int bad_file_mmap(struct file * file, struct vm_area_struct * vma)
+static int bad_file_mmap(struct file *file, struct vm_area_struct *vma)
{
return -EIO;
}
-static int bad_file_open(struct inode * inode, struct file * filp)
+static int bad_file_open(struct inode *inode, struct file *filp)
{
return -EIO;
}
@@ -90,12 +89,12 @@ static int bad_file_flush(struct file *f
return -EIO;
}
-static int bad_file_release(struct inode * inode, struct file * filp)
+static int bad_file_release(struct inode *inode, struct file *filp)
{
return -EIO;
}
-static int bad_file_fsync(struct file * file, struct dentry *dentry,
+static int bad_file_fsync(struct file *file, struct dentry *dentry,
int datasync)
{
return -EIO;
@@ -140,7 +139,7 @@ static int bad_file_check_flags(int flag
return -EIO;
}
-static int bad_file_dir_notify(struct file * file, unsigned long arg)
+static int bad_file_dir_notify(struct file *file, unsigned long arg)
{
return -EIO;
}
@@ -194,54 +193,54 @@ static const struct file_operations bad_
.splice_read= bad_file_splice_read,
};
-static int bad_inode_create (struct inode * dir, struct dentry * dentry,
+static int bad_inode_create (struct inode *dir, struct dentry *dentry,
int mode, struct nameidata *nd)
{
return -EIO;
}
-static struct dentry *bad_inode_lookup(struct inode * dir,
+static struct dentry *bad_inode_lookup(struct inode *dir,
struct dentry *dentry, struct nameidata *nd)
{
return ERR_PTR(-EIO);
}
-static int bad_inode_link (struct dentry * old_dentry, struct inode * dir,
+static int bad_inode_link (struct dentry *old_dentry, struct inode *dir,
struct dentry *dentry)
{
return -EIO;
}
-static int bad_inode_unlink(struct inode * dir, struct dentry *dentry)
+static int bad_inode_unlink(struct inode *dir, struct dentry *dentry)
{
return -EIO;
}
-static int bad_inode_symlink (struct inode * dir, struct dentry *dentry,
- const char * symname)
+static int bad_inode_symlink (struct inode *dir, struct dentry *dentry,
+ const char *symname)
{
return -EIO;
}
-static int bad_inode_mkdir(struct inode * dir, struct dentry * dentry,
+static int bad_inode_mkdir(struct inode *dir, struct dentry *dentry,
int mode)
{
return -EIO;
}
-static int bad_inode_rmdir (struct inode * dir, struct dentry *dentry)
+static int bad_inode_rmdir (struct inode *dir, struct dentry *dentry)
{
return -EIO;
}
-static int bad_inode_mknod (struct inode * dir, struct dentry *dentry,
+static int bad_inode_mknod (struct inode *dir, struct dentry *dentry,
int mode, dev_t rdev)
{
return -EIO;
}
-static int bad_inode_rename (struct inode * old_dir, struct dentry *old_dentry,
- struct inode * new_dir, struct dentry *new_dentry)
+static int bad_inode_rename (struct inode *old_dir, struct dentry *old_dentry,
+ struct inode *new_dir, struct dentry *new_dentry)
{
return -EIO;
}
@@ -337,7 +336,7 @@ static struct inode_operations bad_inode
* on it to fail from this point on.
*/
-void make_bad_inode(struct inode * inode)
+void make_bad_inode(struct inode *inode)
{
remove
Re: [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Le jeudi 04 janvier 2007 à 20:59 -0200, Mauro Carvalho Chehab a écrit : > > The largest value we use here is 0x0200. Perhaps v4l2_std_id shouldn't > > be 64-bit? > Too late to change it to 32 bits. It is at V4L2 userspace API since > kernel 2.6.0. We can, however use this approach as a workaround, with > the proper documentation. Maybe with a BUG_ON(id > UINT_MAX) ? Linus, do you want a patch for this or will you take the _ucmppdi2 ppc patch as per http://lkml.org/lkml/2006/12/17/46 instead ? Thanks, Stelian. -- Stelian Pop <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
On Thu, 04 Jan 2007 20:59:08 -0200 Mauro Carvalho Chehab <[EMAIL PROTECTED]> wrote: > > The largest value we use here is 0x0200. Perhaps v4l2_std_id shouldn't > > be 64-bit? > Too late to change it to 32 bits. It is at V4L2 userspace API since > kernel 2.6.0. You could perhaps make it 32-bit internally, and still 64-bit on the kernel<->userspace boundary. 64-bit quantities are expensive.. > We can, however use this approach as a workaround, with > the proper documentation. I'll handle it after I return from vacations > next week. Thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
On Thu, 4 Jan 2007, Andrew Morton wrote: > > That's what I currently have queued. It increases bad_inode.o text from > 200-odd bytes to 700-odd :( Then I think we're ok. We do care about bytes, but we care more about bytes that actually ever hit the icache or dcache, and this will effectively do neither. > That one should be ok. System calls by definition have the same return type, since they all have the same call site. So that one really does fit the "argument types differ, but the return type is the same" case. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
Em Qui, 2007-01-04 às 14:48 -0800, Andrew Morton escreveu:
> On Thu, 04 Jan 2007 12:10:14 +0100
> Stelian Pop <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > This patch replaces a switch statement using 64 bit values with the
> > if/else equivalent in order to prevent a call __ucmpdi2 generated by
> > some versions of gcc (verified with gcc-4.1.2 20060928):
> >
> > drivers/built-in.o: In function `v4l2_norm_to_name':
> > (.text+0x71100): undefined reference to `__ucmpdi2'
> >
> > Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
> >
> > ---
> >
> > drivers/media/video/v4l2-common.c | 126
> > ++---
> > 1 files changed, 62 insertions(+), 64 deletions(-)
> >
> > diff --git a/drivers/media/video/v4l2-common.c
> > b/drivers/media/video/v4l2-common.c
> > index 752c82c..0c3c2f6 100644
> > --- a/drivers/media/video/v4l2-common.c
> > +++ b/drivers/media/video/v4l2-common.c
> > @@ -91,70 +91,68 @@ char *v4l2_norm_to_name(v4l2_std_id id)
> > {
> > char *name;
> >
> > - switch (id) {
>
> It'd be simpler to just do
>
> switch ((unsigned int)id) {
>
> here (with a suitable comment).
>
> The largest value we use here is 0x0200. Perhaps v4l2_std_id shouldn't
> be 64-bit?
Too late to change it to 32 bits. It is at V4L2 userspace API since
kernel 2.6.0. We can, however use this approach as a workaround, with
the proper documentation. I'll handle it after I return from vacations
next week.
>
Cheers,
Mauro.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
On Thu, 4 Jan 2007 14:35:09 -0800 (PST)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Anybody want to send in the patch that just generates separate versions
> for
>
> loff_t eio_llseek(struct file *file, loff_t offset, int origin)
> {
> return -EIO;
> }
>
> int eio_readdir(struct file *filp, void *dirent, filldir_t filldir)
> {
> return -EIO;
> ..
>
That's what I currently have queued. It increases bad_inode.o text from
200-odd bytes to 700-odd :(
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: kernel + gcc 4.1 = several problems
On Jan 4, 2007, at 13:34, Segher Boessenkool wrote: The "signed wrap is undefined" thing doesn't fit in this category though: -- It is an important optimisation for loops with a signed induction variable; It certainly isn't that important. Even SpecINT compiled with -O3 and top-of-tree GCC *improves* 1% by adding -fwrapv. If the compiler itself can rely on wrap-around semantics and doesn't have to worry about introducing overflows between optimization passes, it can reorder simple chains of additions. This is more important for many real-world applications than being able to perform some complex loop-interchange. Compiler developers always make the mistake of overrating their optimizations. If GCC does really poorly on a few important loops that matter, that issue is easily addressed. If GCC generates unreliable code for millions of boring lines of important real-world C, the compiler is worthless. -Geert - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: wireless Q
On Thu, Jan 04, 2007 at 12:51:49AM -0500, Gene Heskett wrote: > I bought a Belkin Wireless G card, a pci 802-11 radio of some sort. > > The main chip on it wears the label "RTL8185L" > > Is there any support for making this a wireless server in the kernel at > the present time? > > I have visions of sticking it in the last pci slot of a box running DD-WRT > if there is a driver available. Gene, There is no such driver in the kernel at this time. There is an out-of-kernel driver available here: http://rtl8180-sa2400.sourceforge.net/ YMMV. FWIW, I know of at least one person working on a driver for the d80211-based stack in wireless-dev. I'm not sure when that will be available publicly. Hth! John -- John W. Linville [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PATCH i2c/m41t00 do not forget to write year
m41t00.c forgets to set the year field in set_rtc_time; fix that. Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]> --- drivers/i2c/chips/m41t00.c 2007-01-02 20:57:59.0 +0100 +++ drivers/i2c/chips/m41t00.c 2007-01-04 22:11:35.0 +0100 @@ -209,6 +209,7 @@ m41t00_set(void *arg) buf[m41t00_chip->hour] = (buf[m41t00_chip->hour] & ~0x3f) | (hour& 0x3f); buf[m41t00_chip->day] = (buf[m41t00_chip->day] & ~0x3f) | (day & 0x3f); buf[m41t00_chip->mon] = (buf[m41t00_chip->mon] & ~0x1f) | (mon & 0x1f); + buf[m41t00_chip->year] = year; if (i2c_master_send(save_client, wbuf, 9) < 0) dev_err(&save_client->dev, "m41t00_set: Write error\n"); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
Linus Torvalds wrote: > Well, that probably would work, but it's also true that returning a 64-bit > value on a 32-bit platform really _does_ depend on more than the size. Yeah, obviously this is restricted to the signed-integer case. My point was just that you could have the compiler figure out which variant to pick for loff_t automatically. > "let's not play tricks with function types at all". I think I agree. The real (but harder) fix for the wasted space issue would be to get the toolchain to automatically combine functions that end up compiling into identical assembly. -Mitch - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Finding hardlinks
Hi! > > > High probability is all you have. Cosmic radiation hitting your > > > computer will more likly cause problems, than colliding 64bit inode > > > numbers ;) > > > > Some of us have machines designed to cope with cosmic rays, and would be > > unimpressed with a decrease in reliability. > > With the suggested samefile() interface you'd get a failure with just > about 100% reliability for any application which needs to compare a > more than a few files. The fact is open files are _very_ expensive, > no wonder they are limited in various ways. > > What should 'tar' do when it runs out of open files, while searching > for hardlinks? Should it just give up? Then the samefile() interface > would be _less_ reliable than the st_ino one by a significant margin. You need at most two simultenaously open files for examining any number of hardlinks. So yes, you can make it reliable. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Bug] OOPS with nf_conntrack_ipv6, probably fragmented UDPv6
On Thu, 04 Jan 2007 17:58:23 +0100 Bernhard Schmidt <[EMAIL PROTECTED]> wrote: > Hi, > > I've hit another kernel oops with 2.6.20-rc3 on i386 platform. It is > reproducible, as soon as I load nf_conntrack_ipv6 and try to send > something large (scp or so) inside an OpenVPN tunnel on my client > (patched with UDPv6 transport) the router (another box) OOPSes. > > tcpdump suggests the problem appears as soon as my client sends > fragmented UDPv6 packets towards the destination. It does not happen > when nf_conntrack_ipv6 is not loaded. This is the OOPS as dumped from > the serial console: > > heimdall login: Oops: [#1] > Modules linked in: sit sch_red sch_htb pppoe pppox ppp_generic slhc > xt_CLASSIFY ipt_TOS xt_length ipt_tos ipt_TCPMSS xt_tcpudp > ipt_MASQUERADE xt_state iptable_mangle iptable_filter > iptable_nat nf_nat nf_conntrack_ipv4 ip_tables x_tables > nf_conntrack_ipv6 nf_conntrack nfnetlink > CPU:0 > EIP:0060:[<0001>]Not tainted VLI > EFLAGS: 00010246 (2.6.20-rc3 #2) > EIP is at 0x1 > eax: cd215bc0 ebx: cd1f3160 ecx: cc59002a edx: cd215bc0 > esi: cd215bc0 edi: cd215bc0 ebp: esp: c030bd3c > ds: 007b es: 007b ss: 0068 > Process swapper (pid: 0, ti=c030a000 task=c02e93a0 task.ti=c030a000) > Stack: c0212cc4 0004 cc83f160 cd2130c0 cd215bc0 cd2130c0 cd215bc0 > c021734b > c030bdb4 c0307a60 000a cceee800 cceee800 cd215bc0 cd1f3160 > > c021896b c0307a60 cd215bc0 cd215bc0 cceee800 cd1f3160 c025f1c6 > > Call Trace: > [] __kfree_skb+0x84/0xe0 > [] dev_hard_start_xmit+0x1bb/0x1d0 > [] dev_queue_xmit+0x11b/0x1b0 > [] ip6_output2+0x276/0x2b0 > [] ip6_output_finish+0x0/0xf0 > [] ip6_output+0x90a/0x940 > [] cache_alloc_refill+0x2c5/0x3f0 > [] pskb_expand_head+0xdd/0x130 > [] ip6_forward+0x465/0x4b0 > [] ip6_rcv_finish+0x16/0x30 > [] nf_ct_frag6_output+0x86/0xb0 [nf_conntrack_ipv6] > [] ip6_rcv_finish+0x0/0x30 > [] ipv6_defrag+0x3b/0x50 [nf_conntrack_ipv6] > [] ip6_rcv_finish+0x0/0x30 > [] nf_iterate+0x38/0x70 > [] ip6_rcv_finish+0x0/0x30 > [] nf_hook_slow+0x4d/0xc0 > [] ip6_rcv_finish+0x0/0x30 > [] ipv6_rcv+0x1e0/0x250 > [] ip6_rcv_finish+0x0/0x30 > [] netif_receive_skb+0x1a8/0x200 > [] process_backlog+0x6e/0xe0 > [] net_rx_action+0x52/0xd0 > [] __do_softirq+0x35/0x80 > [] do_softirq+0x22/0x30 > [] do_IRQ+0x5e/0x70 > [] common_interrupt+0x23/0x30 > [] default_idle+0x0/0x40 > [] default_idle+0x27/0x40 > [] cpu_idle+0x37/0x50 > [] start_kernel+0x266/0x270 > [] unknown_bootoption+0x0/0x210 > === > Code: Bad EIP value. > EIP: [<0001>] 0x1 SS:ESP 0068:c030bd3c > <0>Kernel panic - not syncing: Fatal exception in interrupt > <0>Rebooting in 20 seconds..<4>atkbd.c: Spurious ACK on > isa0060/serio0. Some program might be trying access hardware directly. > At a guess I'd say that skb->nfct->destroy has value 0x0001. Not a good function address. Presumably it is suppsoed to be zero... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 8/8] user ns: implement user ns unshare
Quoting [EMAIL PROTECTED] ([EMAIL PROTECTED]):
> On Thu, 04 Jan 2007 19:07:00 GMT, Frederik Deweerdt said:
> > On Thu, Jan 04, 2007 at 12:13:10PM -0600, Serge E. Hallyn wrote:
> > > From: Serge E. Hallyn <[EMAIL PROTECTED]>
> > > Subject: [PATCH -mm 8/8] user ns: implement user ns unshare
> > >
> > > Implement CLONE_NEWUSER flag useable at clone/unshare.
> > >
> > > Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
> > > ---
> >
> > > int copy_user_ns(int flags, struct task_struct *tsk)
> > > {
> > > - struct user_namespace *old_ns = tsk->nsproxy->user_ns;
> > > + struct user_namespace *new_ns, *old_ns = tsk->nsproxy->user_ns;
> > > int err = 0;
> >
> > The "= 0" is superfluous here.
>
> Umm? bss gets cleared automagically, but when did we start auto-zeroing
> the stack?
No, no, that's what i thought he meant at first too, but I actually
manually set err on all paths anyway :)
-serge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix __ucmpdi2 in v4l2_norm_to_name()
On Thu, 04 Jan 2007 12:10:14 +0100
Stelian Pop <[EMAIL PROTECTED]> wrote:
> Hi,
>
> This patch replaces a switch statement using 64 bit values with the
> if/else equivalent in order to prevent a call __ucmpdi2 generated by
> some versions of gcc (verified with gcc-4.1.2 20060928):
>
> drivers/built-in.o: In function `v4l2_norm_to_name':
> (.text+0x71100): undefined reference to `__ucmpdi2'
>
> Signed-off-by: Stelian Pop <[EMAIL PROTECTED]>
>
> ---
>
> drivers/media/video/v4l2-common.c | 126
> ++---
> 1 files changed, 62 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-common.c
> b/drivers/media/video/v4l2-common.c
> index 752c82c..0c3c2f6 100644
> --- a/drivers/media/video/v4l2-common.c
> +++ b/drivers/media/video/v4l2-common.c
> @@ -91,70 +91,68 @@ char *v4l2_norm_to_name(v4l2_std_id id)
> {
> char *name;
>
> - switch (id) {
It'd be simpler to just do
switch ((unsigned int)id) {
here (with a suitable comment).
The largest value we use here is 0x0200. Perhaps v4l2_std_id shouldn't
be 64-bit?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
Linus Torvalds wrote:
> Anybody want to send in the patch that just generates separate versions
> for
>
> loff_t eio_llseek(struct file *file, loff_t offset, int origin)
> {
> return -EIO;
> }
>
> int eio_readdir(struct file *filp, void *dirent, filldir_t filldir)
> {
> return -EIO;
> ..
>
> and so on?
That's more or less what I sent at http://lkml.org/lkml/2007/1/3/244
+static int bad_file_readdir(struct file * filp, void * dirent,
+ filldir_t filldir)
+{
+ return -EIO;
+}
... etc
Thanks,
-Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: BUG, 2.6.20-rc3 raid autodetection [repost due to forgotten CC]
On Thu, 2007-01-04 at 22:45 +0100, Kasper Sandberg wrote: > On Thu, 2007-01-04 at 22:06 +0100, Bartlomiej Zolnierkiewicz wrote: > > On 1/4/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > On Thu, 2007-01-04 at 21:07 +0100, Bartlomiej Zolnierkiewicz wrote: > > > > On 1/4/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > > > On Thu, 2007-01-04 at 20:07 +0100, Bartlomiej Zolnierkiewicz wrote: > > > > > > On 1/4/07, Kasper Sandberg <[EMAIL PROTECTED]> wrote: > > > > > > > Hello. > > > > > > > > > > > > > > i just attempted to test .20-rc3-git4 on a box, which has 6 > > > > > > > drives in > > > > > > > raid5. it uses raid autodetection, and 2 ide controllers (via and > > > > > > > promise 20269). > > > > > > > > > > > > > > there are two problems. > > > > > > > > > > > > > > first, and most importantly, it doesent autodetect, i attempted > > > > > > > with > > > > > > > both the old ide drivers, and the new pata on libata drivers, the > > > > > > > drives > > > > > > > appears to be found, but the raid autoassembling just doesent > > > > > > > happen. > > > > > > > > > > > > > > this is .17, which works: > > > > > > > http://sh.nu/p/8001 > > > > > > > > > > > > > > this is .20-rc3-git4 which doesent work, in pata-on-libata mode: > > > > > > > http://sh.nu/p/8000 > > > > > > > > > > > > > > this is .20-rc3-git4 which doesent work, in old ide mode: > > > > > > > http://sh.nu/p/8002 > > > > > > > > > > > > For some reason IDE disk driver is not claiming IDE devices. > > > > > > > > > > > > Could you please double check that IDE disk driver is built-in > > > > > > (CONFIG_BLK_DEV_IDEDISK=y in the kernel configuration) > > > > > > and not compiled as module? > > > > > i need not check even once, i do not have module support enabled, so > > > > > > > > OK > > > > > > > > > everything 100% surely is built in. this is the case for .17 too > > > > > (and earlier, this box was started with .15 i think.) > > > > > > > > Could you send me your config? > > > > I'll try to reproduce this locally. > > > sure thing. > > > > > > http://sh.nu/p/8004 <-- .17 working > > > > CONFIG_BLK_DEV_IDEDISK=y > > > > > http://sh.nu/p/8005 <-- .20-rc3-git4 nonworking, idemode, the one with > > > libata i dont have anymore, but the only difference is that i use the > > > libata drivers, but as its same result, shouldnt matter > > > > # CONFIG_BLK_DEV_IDEDISK is not set > > > > so not everything is "100% surely" built-in ;) > i see your point, im afraid i may have misinterpreted you, since you > said "and not compiled as module", so i thought you meant i had to make > sure it wasnt moduled only. > > i will try with this now, what about pataonlibata, do i need this for > that too? > > > > Bart > > -- Redeeman <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6 patch] remove the broken VIDEO_PLANB driver
> If you need explanations about the code or the hardware, don't hesitate > to ask. Not sure what I still remember, but I still have my old paper > notes. Heh, ok. No idea when I'll have time to look tho. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [UPDATED PATCH] fix memory corruption from misinterpreted bad_inode_ops return values
On Thu, 4 Jan 2007, Mitchell Blank Jr wrote:
>
> I don't think you need to do fancy #ifdef's:
>
> static s32 return_eio_32(void) { return -EIO; }
> static s64 return_eio_64(void) { return -EIO; }
> extern void return_eio_unknown(void); /* Doesn't exist */
> #define return_eio(type)((sizeof(type) == 4) \
> ? ((void *) return_eio_32) \
> : ((sizeof(type) == 8) \
> ? ((void *) return_eio_64) \
> : ((void *) return_eio_unknown)))
Well, that probably would work, but it's also true that returning a 64-bit
value on a 32-bit platform really _does_ depend on more than the size.
For an example of this, try compiling this:
long long a(void)
{
return -1;
}
struct dummy { int a, b };
struct dummy b(void)
{
struct dummy retval = { -1 , -1 };
return retval;
}
on x86.
Now, I don't think we actually have anything like this in the kernel, and
your example is likely to work very well in practice, but once we start
doing tricks like this, I actually think it's getting easier to just say
"let's not play tricks with function types at all".
Anybody want to send in the patch that just generates separate versions
for
loff_t eio_llseek(struct file *file, loff_t offset, int origin)
{
return -EIO;
}
int eio_readdir(struct file *filp, void *dirent, filldir_t filldir)
{
return -EIO;
..
and so on?
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCHSET] Managed device resources
On Thu, Jan 04, 2007 at 05:26:43PM -0500, Jeff Garzik wrote: > Greg KH wrote: > >Hm, but I guess without the follow-up patches for libata, it will not > >really get tested much. Jeff, if I accept this, what's your feelings of > >letting libata be the "test bed" for it? > > > It would be easiest for me to merge this through my > libata-dev.git#upstream tree. That will auto-propagate it to -mm, and > ensure that both base and libata bits are sent in one batch. > > Just shout if you see NAK-able bits... > > Work for you? That works for me. The only question I have is on the EXPORT_SYMBOL() stuff for the new driver/base/ functions. Tejun, traditionally the driver core has all exported symbols marked with EXPORT_SYMBOL_GPL(). So, any objection to marking the new ones (becides the "mirror" functions) in this manner? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
how to get serial_no from usb HD disk (HDIO_GET_IDENTITY ioctl, hdparm -i)
How can I get serial_no from usb-attached HD drive ? The HDIO_GET_IDENTITY ioctl fails (like 'hdparm -i'). Any advice on how to extract the drive serialNo from the usb disk ? Can I write kernel module to extract the SerialNo ? (I don't need whole 'struct hd_driveid', only the SerialNo). Thanks Yakov - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC: 2.6 patch] remove the broken VIDEO_PLANB driver
Hi Adrian, hi Ben, On 5 Jan, this message from Benjamin Herrenschmidt echoed through cyberspace: > On Thu, 2007-01-04 at 19:53 +0100, Adrian Bunk wrote: >> The VIDEO_PLANB driver: >> - has been marked as BROKEN for more than two years and >> - is still marked as BROKEN. >> >> Drivers that had been marked as BROKEN for such a long time seem to >> be unlikely to be revived in the forseeable future. I was waiting for this one :-) I have to admit I don't have the time to work on this anymore, so either Ben can fix something, or I will sadly add my s-o-b. >> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > I suppose I could give it a go as I do have a machine with that > hardware rusting somewhere... Don't remove it right away, I'll have a > look. If you need explanations about the code or the hardware, don't hesitate to ask. Not sure what I still remember, but I still have my old paper notes. Cheers Michel - Michel Lanners | " Read Philosophy. Study Art. 23, Rue Paul Henkes|Ask Questions. Make Mistakes. L-1710 Luxembourg | email [EMAIL PROTECTED]| http://www.cpu.lu/~mlan| Learn Always. " - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCHSET] Managed device resources
Greg KH wrote: Hm, but I guess without the follow-up patches for libata, it will not really get tested much. Jeff, if I accept this, what's your feelings of letting libata be the "test bed" for it? It would be easiest for me to merge this through my libata-dev.git#upstream tree. That will auto-propagate it to -mm, and ensure that both base and libata bits are sent in one batch. Just shout if you see NAK-able bits... Work for you? Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.16.37
On Sun, Dec 31, 2006 at 05:05:55PM -0500, Chuck Ebbert wrote: > In-Reply-To: <[EMAIL PROTECTED]> > > On Thu, 28 Dec 2006 14:53:08 +0100, Adrian Bunk wrote: > > > Changes since 2.6.16.36: > > ... > > If you're not going to merge the critical x86 fixes I sent, > I won't bother sending anything more. Sorry, they didn't went in before 2.6.16.37-rc1, and except for releasing 2.6.16.37-rc1 unchanged as 2.6.16.37 I didn't work on 2.6.16 during christmas and new year. I've now applied all three patches. There's already a CVE number for "i386: save/restore eflags in context switch". Are there also CVE numbers for the equivalent x86_64 patch and "x86_64: fix ia32 syscall count"? Thanks for your patches Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm 8/8] user ns: implement user ns unshare
On Thu, 04 Jan 2007 19:07:00 GMT, Frederik Deweerdt said:
> On Thu, Jan 04, 2007 at 12:13:10PM -0600, Serge E. Hallyn wrote:
> > From: Serge E. Hallyn <[EMAIL PROTECTED]>
> > Subject: [PATCH -mm 8/8] user ns: implement user ns unshare
> >
> > Implement CLONE_NEWUSER flag useable at clone/unshare.
> >
> > Signed-off-by: Serge E. Hallyn <[EMAIL PROTECTED]>
> > ---
>
> > int copy_user_ns(int flags, struct task_struct *tsk)
> > {
> > - struct user_namespace *old_ns = tsk->nsproxy->user_ns;
> > + struct user_namespace *new_ns, *old_ns = tsk->nsproxy->user_ns;
> > int err = 0;
>
> The "= 0" is superfluous here.
Umm? bss gets cleared automagically, but when did we start auto-zeroing
the stack?
pgpNqO855gkiy.pgp
Description: PGP signature
