What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note that
there's much less headers included in the final version.
Signed-off-by: Glauber de
Hello,
I am trying to build a basic initramfs image into the kernel, using
the CONFIG_INITRAMFS_SOURCE. The required result is a single image
loaded into a target containing usermode application (busybox).
I use cross compile mipsel-unknown-linux-uclibc in order to build the
kernel and the
On Tue, Dec 18, 2007 at 05:50:42PM +0100, Stefan Richter wrote:
Do I understand correctly?: A device and the CPUs communicate via two
separate memory areas: A data buffer and a status FIFO. The NUMA
interconnect may reorder accesses of the device to the areas. (Write
accesses? Read
svc_pool_map_set_cpumask will only affect current as of now. Add a
new arg so that it can change the cpumask on any given task. Also if
we're not changing current we don't care what the oldmask was, so
allow it to be a NULL pointer.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
lockd_start_done is a global var that can be reused if lockd is
restarted, but it's never reinitialized. On all but the first use,
wait_for_completion isn't actually waiting on it since it has
already completed once.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/lockd/svc.c |1 +
1
On Mon, 17 Dec 2007, James Bottomley wrote:
On Mon, 2007-12-17 at 13:43 -0800, Andrew Morton wrote:
On Mon, 17 Dec 2007 16:02:02 -0500
John Stoffel [EMAIL PROTECTED] wrote:
Just to confirm, the propsed patch to st.c fixes the issue with
2.6.24-rc5 as well at 2.6.24-rc5-mm1
...and only have lockd exit when the last reference is dropped.
The problem is this:
When a lock that a client is blocking on comes free, lockd does this in
nlmsvc_grant_blocked():
nlm_async_call(block-b_call, NLMPROC_GRANTED_MSG, nlmsvc_grant_ops);
the callback from this call is
Have lockd_up start lockd using svc_create_kthread. With this change,
lockd_down now blocks until lockd actually exits, so there's no longer
need for the waitqueue code at the end of lockd_down. This also means
that only one lockd can be running at a time which simplifies the code
within lockd's
Move the initialzation in __svc_create_thread that happens prior to
thread creation to a new function. Export the function so that when
we replace __svc_create_thread with a kthread version, callers will
have complete control over this initialization.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
Needed since the plan is to not have a svc_create_thread helper and to
have current users of that function just call kthread_run directly.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
net/sunrpc/sunrpc_syms.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git
This is the third patchset to fix the use-after-free problem in lockd,
and to convert lockd to use the kthread API instead of kernel_thread.
The main change from the last patchset is the elimination of the
svc_create_kthread helper function, and having lockd_up call kthread_run
directly. I've also
lockd makes itself freezable, but never calls try_to_freeze(). Have it
call try_to_freeze() within the main loop.
Signed-off-by: Jeff Layton [EMAIL PROTECTED]
---
fs/lockd/svc.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/fs/lockd/svc.c b/fs/lockd/svc.c
index
James Nichols a écrit :
Well... please dont start a flame war :(
Back to your SYN_SENT problem, I suppose the remote IP is known, so you
probably could post here the result of a tcdpump ?
tcpdump -p -n -s 1600 host IP_of_problematic_peer -c 500
Most probably remote peer received too many
Glauber de Oliveira Costa wrote:
What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are deleted. Note
that there's much less headers included in the final
Andrew,
Thanks your your comments, I'm currently preparing/testing a revised patch
based on your suggestions, which I will post later this week.
A couple of comments inline.
Steve
I wouldn't bother with EXPERIMENTAL personally. It seems a farily
pointless thing.
OK, I copied one of the
Thanks to Josef Bacik for finding these.
A couple of ecryptfs error paths don't properly unlock things they locked.
Signed-off-by: Eric Sandeen [EMAIL PROTECTED]
Cc: Josef Bacik [EMAIL PROTECTED]
---
Index: linux-2.6.24-rc3/fs/ecryptfs/crypto.c
* Glauber de Oliveira Costa [EMAIL PROTECTED] wrote:
On Dec 18, 2007 6:54 PM, Frans Pop [EMAIL PROTECTED] wrote:
Glauber de Oliveira Costa wrote:
What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
On 12/18/2007 02:45 PM, James Nichols wrote:
I've run tcpdump for all IPs during this problem. I haven't tried
doing it for a single explicit IP address- due to the nature of the
workload it's very difficult to know which IPs will be hit at any
given moment. What I did see in the full IP
On Tue, 18 Dec 2007 20:52:07 +0100 (CET) Geert Uytterhoeven [EMAIL PROTECTED]
wrote:
On Tue, 18 Dec 2007, Andrew Morton wrote:
On Sun, 16 Dec 2007 11:51:00 +0100 (CET) Geert Uytterhoeven [EMAIL
PROTECTED] wrote:
On recent kernels, I get the following error when using an initrd:
|
However, your older patch series looks like you want this behavior also
in areas which are mapped by dma_map_sg(), do you?. Still, adding two
functions of the kind like above, if necessary, might still be
preferable to changing the call parameters of existing functions or to
overloading
On Tue, 18 Dec 2007, Richard Henderson wrote:
I've added dmesg, /proc/iomem, and lspci -v output to that bug.
Basically, we have
c000-cfff : free
ddf0-dfef : PCI Bus #04
e000-efff : pnp 00:0b
f000-fedf : less than 256MB
Gaah.
Make the anon_vma list lock a read/write lock. Heaviest use of this
lock is in the page_referenced()/try_to_unmap() calls from vmscan
[shrink_page_list()]. These functions can use a read lock to allow
some parallelism for different cpus trying to reclaim pages mapped
via the same set of vmas.
On large memory systems, the VM can spend way too much time scanning
through pages that it cannot (or should not) evict from memory. Not
only does it use up CPU time, but it also provokes lock contention
and can leave large systems under memory presure in a catatonic state.
This patch series
Define page_file_cache() function to answer the question:
is page backed by a file?
Originally part of Rik van Riel's split-lru patch. Extracted
to make available for other, independent reclaim patches.
Moved inline function to linux/mm_inline.h where it will
be needed by subsequent
+ lts' convert anon_vma list lock to reader/write lock patch
+ Nick Piggin's move and rework isolate_lru_page() patch
Free swap cache entries when swapping in pages if vm_swap_full()
[swap space 1/2 used?]. Uses new pagevec to reduce pressure
on locks.
Signed-off-by: Rik van Riel [EMAIL
Debug whether we end up classifying the wrong pages as
filesystem backed. This has not triggered in stress
tests on my system, but who knows...
Signed-off-by: Rik van Riel [EMAIL PROTECTED]
Index: linux-2.6.24-rc3-mm2/include/linux/mm_inline.h
We avoid evicting and scanning anonymous pages for the most part, but
under some workloads we can end up with most of memory filled with
anonymous pages. At that point, we suddenly need to clear the referenced
bits on all of memory, which can take ages on very large memory systems.
We can reduce
V2 - V3:
+ rebase to 23-mm1 atop RvR's split lru series [no change]
+ fix function return types [void - int] to fix build when
not configured.
New in V2.
We need to hold the mmap_sem for write to initiatate mlock()/munlock()
because we may need to merge/split vmas. However, this can lead to
On Dec 18, 2007 6:54 PM, Frans Pop [EMAIL PROTECTED] wrote:
Glauber de Oliveira Costa wrote:
What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are moved
to processor.h around ifdefs, and the original files are
[EMAIL PROTECTED] wrote:
Reorderings are possible on reads and
writes. Things get synced up by either an interrupt or a write to
a memory region with a barrier attribute. Memory allocated with
dma_alloc_coherent() gets the barrier attribute. The idea here is
to allow memory allocated with
V2 - V3:
+ rebase to 23-mm1 atop RvR's split LRU series
V1 - V2:
no changes
Report non-reclaimable pages per zone and system wide.
Note: may want to track/report some specific reasons for
nonreclaimability for deciding when to splice the noreclaim
lists back to the normal lru. That
Update the split anon file LRU code to deal with the recent
memory controller changes.
Signed-off-by: Rik van Riel [EMAIL PROTECTED]
Index: linux-2.6.24-rc3-mm2/include/linux/memcontrol.h
===
---
V2 - V3:
+ rebase to 23-mm1 atop RvR's split LRU series.
+ Use scan_mapping_noreclaim_page() on unlock. See below.
V1 - V2:
+ modify to use reworked 'scan_all_zones_noreclaim_pages()'
See 'TODO' below - still pending.
While working with Nick Piggin's mlock patches, I noticed that
shmem
Swapin_readahead can read in a lot of data that the processes in
memory never need. Adding swap cache pages to the inactive list
prevents them from putting too much pressure on the working set.
This has the potential to help the programs that are already in
memory, but it could also be a
V2 - V3:
+ rebase to 23-mm1 atop RvR's split lru series [no changes]
V1 - V2:
+ modified mmap.c:mmap_region() to return error if mlock_vma_pages_range()
does. This can only occur if the vma gets removed/changed while
we're switching mmap_sem lock modes. Most callers don't care, but
V2 - V3:
+ rebase to 23-mm1 atop RvR's split LRU series [no changes]
V1 - V2:
+ add ramfs pages to this class of non-reclaimable pages by
marking ramfs address_space [mapping] as non-reclaimble.
Christoph Lameter pointed out that ram disk pages also clutter the
LRU lists. When vmscan finds
V2 - V3:
+ rebase to 23-mm1 atop RvR's split LRU series
New in V2
This patch adds a function to scan individual or all zones' noreclaim
lists and move any pages that have become reclaimable onto the respective
zone's inactive list, where shrink_inactive_list() will deal with them.
This replaces
I have seen soft cpu lockups in page_referenced_file() due to
contention on i_mmap_lock() for different pages. Making the
i_mmap_lock a reader/writer lock should increase parallelism
in vmscan for file back pages mapped into many address spaces.
Read lock the i_mmap_lock for all usage except:
V1 - V2 [lts]:
+ fix botched merge -- add back get_page_unless_zero()
From: Nick Piggin [EMAIL PROTECTED]
To: Linux Memory Management [EMAIL PROTECTED]
Subject: [patch 1/4] mm: move and rework isolate_lru_page
Date: Mon, 12 Mar 2007 07:38:44 +0100 (CET)
isolate_lru_page logically
V1 - V2 [lts]:
+ Remove extraneous __dec_zone_state(zone, NR_ACTIVE) pointed
out by Mel G.
From [EMAIL PROTECTED] Wed Aug 29 11:39:51 2007
Currently we are defining explicit variables for the inactive
and active list. An indexed array can be more generic and avoid
repeating similar code in
V1 - V3:
+ rebase to 23-mm1 atop RvR's split LRU series
+ define NR_NORECLAIM and LRU_NORECLAIM to avoid errors when not
configured.
V1 - V2:
+ handle review comments -- various typos and errors.
+ extract putback_all_noreclaim_pages() into a separate patch
and rework as
V2 - V3:
+ rebase to 23-mm1 atop RvR's split lru series
+ fix definitions of NR_MLOCK to fix build errors when not configured.
V1 - V2:
+ new in V2 -- pulled in reworked from Nick's previous series
From: Nick Piggin [EMAIL PROTECTED]
To: Linux Memory Management [EMAIL PROTECTED]
Cc: Nick
Split the LRU lists in two, one set for pages that are backed by
real file systems (file) and one for pages that are backed by
memory and swap (anon). The latter includes tmpfs.
Eventually mlocked pages will be taken off the LRUs alltogether.
A patch for that already exists and just needs to be
V2 - V3:
+ rebase to 23-mm1 atop RvR's split lru series
+ fix page flags macros for *PageMlocked() when not configured.
+ ensure lru_add_drain_all() runs on all cpus when NORECLIM_MLOCK
configured. Was just for NUMA.
V1 - V2:
+ moved this patch [and related patches] up to right after
On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=425794#c0
That bugzilla entry doesn't even have a dmesg output or anything like
that. I'd really like to see what the
I've added dmesg, /proc/iomem, and lspci -v output to that bug.
On Dec 18 2007 21:37, Eric Dumazet wrote:
If turning off tcp_sack makes the problem go away, why dont you
turn it off all the time ?
That would just be workaround. I welcome the efforts to track this;
not all users have the time to do so.
Disabling tcp_sack also disabled it kernel-wide,
On Tue, Dec 18, 2007 at 12:22:34PM -0800, Richard Henderson wrote:
On Tue, Dec 18, 2007 at 10:21:50AM -0800, Linus Torvalds wrote:
... and that would be an X server issue!).
Of course, fixing the X server to *handle* 64-bit BARs is the correct
solution. I've no idea how involved that is,
Some 'extern struct seq_operations' are wrongly defined in fs/proc/proc_misc.c
(they miss a const qualifier)
In order to fix this correctly, move the extern ... declaration from .c
file to an appropriate include file, as advised by checkpatch.pl
Note : extern struct seq_operations
On Tuesday 18 December 2007, Glauber de Oliveira Costa wrote:
On Dec 18, 2007 6:54 PM, Frans Pop [EMAIL PROTECTED] wrote:
Glauber de Oliveira Costa wrote:
What's left in processor_32.h and processor_64.h cannot be cleanly
integrated. However, it's just a couple of definitions. They are
Alon Bar-Lev wrote:
Hello,
I am trying to build a basic initramfs image into the kernel, using
the CONFIG_INITRAMFS_SOURCE. The required result is a single image
loaded into a target containing usermode application (busybox).
I use cross compile mipsel-unknown-linux-uclibc in order to build
Johannes Weiner wrote:
Hi,
Stephen Clark [EMAIL PROTECTED] writes:
userspace
Please supply the full dmesg output on the non-working kernel the
corresponding .config (or /proc/config.gz).
Added Dave to CC.
Hannes
Duh - I rebooted into the new kernel and no longer see
IOPL_MASK went away and kvm/vmx.c doesn't compile.
Signed-off-by: Roland McGrath [EMAIL PROTECTED]
---
diff --git a/drivers/kvm/vmx.c b/drivers/kvm/vmx.c
index bb56ae3..000 100644
--- a/drivers/kvm/vmx.c
+++ b/drivers/kvm/vmx.c
@@ -524,7 +524,7 @@ static unsigned long vmx_get_rflags(stru
On 12/18/2007 04:09 PM, Linus Torvalds wrote:
I wonder what the heck is the point of that pnp entry. Just for fun, can
you try to just disable CONFIG_PNP, and see if it all works then?
pnpacpi=off should work.
PnP is also trying (and failing) to reserve all physical memory.
--
To
Thomas Meyer wrote:
Hi,
is somebody actually working on this bug?
http://bugzilla.kernel.org/show_bug.cgi?id=9370
I don't want to be impolite, but it's now more than a month since the
bug was opened.
The bug still exists in v2.6.24-rc5-43-gda8cadb:
Have you tried simply removing the line
On Wed, 19 Dec 2007, Ivan Kokshaysky wrote:
Doh. Let's fix the kernel first...
Does this make any difference? (the patch is self explaining ;-)
Heh, indeed. Good catch - that
Prefetchable memory behind bridge: -0fff
on device 00:01.0 does look totally
On Tue, Dec 18, 2007 at 01:09:15PM -0800, Linus Torvalds wrote:
However, I wonder about that
e000-efff : pnp 00:0b
thing. I actually suspect that that whole allocation is literally *meant*
for that 256MB graphics aperture, but the kernel explicitly avoids it
because it's
Actual code let compiler generates idiv instruction on x86.
Using a right shift is OK here and readable as well.
Before patch
10: 57 push %edi
11: 56 push %esi
12: 89 d6 mov%edx,%esi
14: 53
add_to_swap_cache doesn't amount to much: merge it into its sole caller
read_swap_cache_async. But we'll be needing to call __add_to_swap_cache
from shmem.c, so promote it to the new add_to_swap_cache. Both were
static, so there's no interface confusion to worry about.
And lose that
move_to_swap_cache and move_from_swap_cache functions (which swizzle a
page between tmpfs page cache and swap cache, to avoid page copying) are
only used by shmem.c; and our subsequent fix for unionfs needs different
treatments in the two instances of move_from_swap_cache. Move them from
Oops, try that again with Jens' new address.
Phillip Susi wrote:
Thomas Meyer wrote:
Hi,
is somebody actually working on this bug?
http://bugzilla.kernel.org/show_bug.cgi?id=9370
I don't want to be impolite, but it's now more than a month since the
bug was opened.
The bug still exists in
tmpfs has long allowed for a fresh filepage to be created in pagecache,
just before shmem_getpage gets the chance to match it up with the swappage
which already belongs to that offset. But unionfs_writepage now does a
find_or_create_page, divorced from shmem_getpage, which leaves conflicting
tmpfs is expected to limit the memory used (unless mounted with nr_blocks=0
or size=0). But if a stacked filesystem such as unionfs gets pages from a
sparse tmpfs file by reading holes, and then writes to them, it can easily
exceed any such limit at present.
So suppress the SGP_READ don't
Nick has observed that shmem.c still uses GFP_ATOMIC when adding to page
cache or swap cache, without any radix tree preload: so tending to deplete
emergency reserves of memory.
GFP_ATOMIC remains appropriate in shmem_writepage's add_to_swap_cache:
it's being called under memory pressure, so must
Intensive swapoff testing shows shmem_unuse spinning on an entry in
shmem_swaplist pointing to itself: how does that come about? Days pass...
First guess is this: shmem_delete_inode tests list_empty without taking the
global mutex (so the swapping case doesn't slow down the common case); but
On 12/18/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Make sure your /init doesn't depend on an interpreter or library which
isn't available.
Thank you for your answer.
I already checked.
/init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
But shouldn't I get a
Here's a few patches to unionfs, which together with the tmpfs
patches I just posted, get that combination working better.
fs/stack.c |6 +++
fs/unionfs/inode.c | 83 +--
fs/unionfs/mmap.c |3 -
3 files changed, 47 insertions(+), 45
On Tue, 18 Dec 2007, Chuck Ebbert wrote:
On 12/18/2007 04:09 PM, Linus Torvalds wrote:
I wonder what the heck is the point of that pnp entry. Just for fun, can
you try to just disable CONFIG_PNP, and see if it all works then?
pnpacpi=off should work.
PnP is also trying (and
The memcgroup regime relies upon a cgroup reclaiming pages from itself
within add_to_page_cache: which may involve some waiting. Whereas shmem
and tmpfs rely upon using add_to_page_cache while holding a spinlock:
when it cannot wait. The consequence is that when a cgroup reaches its
limit,
On Tue, Dec 18, 2007 at 10:25:50PM +0100, Eric Dumazet wrote:
Some 'extern struct seq_operations' are wrongly defined in
fs/proc/proc_misc.c (they miss a const qualifier)
In order to fix this correctly, move the extern ... declaration from .c
file to an appropriate include file, as
From: Stefan Richter [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 11:38:27 +0100
Also note:
- The very same code did not oops at this point in 2.6.22. It only
started doing so in 2.6.23.
2.6.23 is when the sparc64 IOMMU code started relying upon
the dev_archdata bits being correct.
--
To
From: Stefan Richter [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 11:38:27 +0100
- There has been no other report of this kind for any other
architecture yet. I would expect e.g. the PPC64 folks to report
bugs in our dma mappings eventually.
Irrelevant fact, powerpc handles it's
Tidy up mem_cgroup_charge_common before extending it. Adjust some
comments, but mainly clean up its loop: I've an aversion to loops
full of continues, then a break or a goto at the bottom. And the
is_atomic test should be on the __GFP_WAIT bit, not GFP_ATOMIC bits.
Signed-off-by: Hugh Dickins
* Avi Kivity [EMAIL PROTECTED] wrote:
Booting RHEL 5 i386 in kvm with -no-kvm-irqchip -smp 4 will hang in udev.
I bisected this to a change in the _guest_ kernel:
commit 95492e4646e5de8b43d9a7908d6177fb737b61f0
Author: Ingo Molnar [EMAIL PROTECTED]
Date: Fri Feb 16 01:27:34 2007 -0800
There are a couple of reasons (patches follow) why it would be good to open
a window for sleep in shmem_unuse_inode, between its search for a matching
swap entry, and its handling of the entry found.
shmem_unuse_inode must then use igrab to hold the inode against deletion in
that window, and its
peerchen [EMAIL PROTECTED] writes:
According to the HyperTransport spec, 'En' indicate if the MSI Mapping is
active.
Set the 'En' bit when setup pci and add the quirk for some nvidia devices.
The patch base on kernel 2.6.24-rc5
Ok. This is starting to look good.
Signed-off-by: Andy
Both unionfs and memcgroups pose challenges to tmpfs and shmem. To help
fix, it's best to move the swap swizzling functions from swap_state.c
to shmem.c. As a preliminary to that, move swap stats updating down
into __add_to_swap_cache, which will remain internal to swap_state.c.
Well, actually,
Neither unionfs nor memcgroups are working correctly with tmpfs and shmem.
If either or both are to go forward to 2.6.25, we shall need these patches
(against 2.6.24-rc5-mm1, but not dependent on unionfs or memcgroups) to go
in ahead. A small set for unionfs and a smaller set for memcgroups
* Roland McGrath [EMAIL PROTECTED] wrote:
IOPL_MASK went away and kvm/vmx.c doesn't compile.
thanks, applied.
Ingo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
LTP's iogen01 doio tests hang nicely on 32-bit SMP when /tmp is a unionfs
mount of a tmpfs. See the comment on i_size_write in linux/fs.h: it needs
to be locked, otherwise i_size_read can spin forever waiting for a lost
seqcount update.
Most filesystems are already holding i_mutex for this, but
Remove !mapping_cap_writeback_dirty shortcircuit from unionfs_writepages.
It was introduced to avoid the stray AOP_WRITEPAGE_ACTIVATE coming from
shmem_writepage; but that has since been fixed in shmem_writepage and in
write_cache_pages. It stayed because it looked like a good optimization,
not
On Tue, 18 Dec 2007, Richard Henderson wrote:
Another way to look at this is that the graphics BAR came in from
the BIOS allocated at c000, and we ignored that.
We did?
Perhaps there's a way to give weight to the BIOS settings when
consdering where the PCI region is supposed to
In order to fix unionfs truncation, we need to move the lower notify_change
out of the loop in unionfs_setattr. But when I came to do that, I couldn't
understand that loop at all: its continues and breaks and gotos are obscure,
most particularly the if (copyup || (bindex != bstart)) continue;
fsx-linux in a unionfs soon fails (with oops on tmpfs): truncation doesn't
work right.
When shrinking a file, unionfs_setattr needs to vmtruncate the upper level
before notifying change to the lower level, to eliminate those dirty pages
beyond new eof which otherwise drift down to the lower
Alon Bar-Lev wrote:
On 12/18/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Make sure your /init doesn't depend on an interpreter or library which
isn't available.
Thank you for your answer.
I already checked.
/init is hardlink to busybox, it depends on libc.so.0 which is available at /lib
shmem_unuse is at present an unbroken search through every swap vector page
of every tmpfs file which might be swapped, all under shmem_swaplist_lock.
This dates from long ago, when the caller held mmlist_lock over it all too:
long gone, but there's never been much pressure for preemptible
Here's a couple of patches to get memcgroups working better with tmpfs
and shmem, in conjunction with the tmpfs patches I just posted. There
will be another to come later on, but I shouldn't wait any longer to get
these out to you.
(The missing patch will want to leave a mem_cgroup associated
Why does link(2) not support hard-linking across bind mount points
of the same underlying filesystem ?
Is it as simple as something like this patch below (minus the printk)?
Not likely, but then I'm not a filesystem guru.
???
--- old/fs/namei.c 2007-12-15 12:33:13.0 -0500
+++
We (the -stable team) are announcing the release of the 2.6.23.12 kernel.
It just reverts one patch that has been causing some users some
problems. For details about the problems, see:
http://bugzilla.kernel.org/show_bug.cgi?id=9514
If you are not having any problems with the 2.6.23.11
diff --git a/Makefile b/Makefile
index ada10d5..96c3f02 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 23
-EXTRAVERSION = .11
+EXTRAVERSION = .12
NAME = Arr Matey! A Hairy Bilge Rat!
# *DOCUMENTATION*
diff --git a/drivers/pnp/pnpacpi/rsparser.c
On Wed, Dec 19, 2007 at 12:09:46AM +0200, Alon Bar-Lev wrote:
On 12/18/07, H. Peter Anvin [EMAIL PROTECTED] wrote:
Make sure your /init doesn't depend on an interpreter or library which
isn't available.
Thank you for your answer.
I already checked.
/init is hardlink to busybox, it
On Tue, Dec 18, 2007 at 04:25:05PM +0100, Jan Kara wrote:
Although we don't allow writes over s_maxbytes, it can happen that a file's
size is larger than s_maxbytes. For example we can write the file from
a computer with a different architecture (which has larger s_maxbytes),
boot a kernel
In message [EMAIL PROTECTED], Hugh Dickins writes:
redirty:
set_page_dirty(page);
- return AOP_WRITEPAGE_ACTIVATE; /* Return with the page locked */
+ if (wbc-for_reclaim)
+ return AOP_WRITEPAGE_ACTIVATE; /* Return with page locked */
+ unlock_page(page);
+
Mark Lord wrote:
Why does link(2) not support hard-linking across bind mount points
of the same underlying filesystem ?
Is it as simple as something like this patch below (minus the printk)?
Not likely, but then I'm not a filesystem guru.
???
--- old/fs/namei.c2007-12-15
On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote:
Why does link(2) not support hard-linking across bind mount points
of the same underlying filesystem ?
Because it gives you a security boundary around a subtree.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
In message [EMAIL PROTECTED], Hugh Dickins writes:
In order to fix unionfs truncation, we need to move the lower notify_change
out of the loop in unionfs_setattr. But when I came to do that, I couldn't
[...]
Hugh, I want to understand how patches 3/4 and 4/4 are related. In patch 3
you say in
On Tue, Dec 18, 2007 at 11:00:16PM +, Al Viro wrote:
On Tue, Dec 18, 2007 at 05:46:21PM -0500, Mark Lord wrote:
Why does link(2) not support hard-linking across bind mount points
of the same underlying filesystem ?
Because it gives you a security boundary around a subtree.
PS: that
Steve Davies [EMAIL PROTECTED] :
[...]
I assume that the NIC is not allowing tagged packets into the driver
due to its built-in hardware acceleration/filtering :(
Is it inappropriate to beg for help and suggestions?
Try to disable the vlan related Rx filtering ?
--
Ueimor
--
To unsubscribe
On 12/18/2007 06:06 PM, Haavard Skinnemoen wrote:
From: Remy Bohmer [EMAIL PROTECTED]
This patch splits up the interrupt handler of the serial port
into a interrupt top-half and a tasklet.
[...]
[EMAIL PROTECTED]: misc cleanups and simplifications]
Signed-off-by: Remy Bohmer [EMAIL
Kprobe reenter logic from deeply indented section to helper function.
This improves code readability.
Signed-off-by: Harvey Harrison [EMAIL PROTECTED]
Signed-off-by: Ingo Molnar [EMAIL PROTECTED]
Signed-off-by: Thomas Gleixner [EMAIL PROTECTED]
Signed-off-by: Masami Hiramatsu [EMAIL PROTECTED]
This patch removes some redundant code in the function setup_sigcontext().
The registers ar.ccv,b7,r14,ar.csd,ar.ssd,r2-r3 and r16-r31 are not restored
in restore_sigcontext() when (flags IA64_SC_FLAG_IN_SYSCALL) is true.
So we don't need to zero those variables in setup_sigcontext().
601 - 700 of 816 matches
Mail list logo
