Jeff Garzik wrote:
> Jamie Lokier wrote:
> >By durable, I mean that fsync() should actually commit writes to
> >physical stable storage,
>
> Yes, it should.
Glad we agree :-)
> >I was surprised that fsync() doesn't do this already. There was a lot
> >of effort put into block I/O write barriers
On Tue, 26 Feb 2008, Stephen Rothwell wrote:
> On Mon, 25 Feb 2008 22:56:04 +0100 (CET) Geert Uytterhoeven <[EMAIL
> PROTECTED]> wrote:
> >
> > Can you please add
> > http://linux-m68k-cvs.ubb.ca/~geert/linux-m68k-patches-2.6/series?
> > So far there's only one patch in between
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c | 634 +
1 files changed, 323 insertions(+), 311 deletions(-)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 3600648..3853eb5 100644
---
Hi Bart,
here some trivial fixes that i wanted to get out the door.
--
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
Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]>
---
drivers/ide/ide-cd.c | 29 +
1 files changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/ide/ide-cd.c b/drivers/ide/ide-cd.c
index 546f436..3600648 100644
--- a/drivers/ide/ide-cd.c
+++
Paul Menage wrote:
> On Mon, Feb 25, 2008 at 7:23 PM, Li Zefan <[EMAIL PROTECTED]> wrote:
>> Should those pathces be rebased againt 2.6.25-rc3 ?
>>
>
> No, because they're against 2.6.25-rc2-mm1, which is already has (I
> think) any of the new bits in 2.6.25-rc3 that would be affected by
> these
On Mon, Feb 25, 2008 at 02:30:00AM -0500, Jeff Garzik wrote:
> Grant Grundler wrote:
>> On Mon, Feb 18, 2008 at 05:40:42PM +0100, Ondrej Zary wrote:
>>> I think that de2104x driver should be removed (or at least its
>>> MODULE_DEVICE_TABLE) and MODULE_DEVICE_TABLE with only 21040 and 21041
>>>
On Mon, Feb 25, 2008 at 17:00:24 -0800, Greg Kroah-Hartman wrote:
> We (the -stable team) are announcing the release of the 2.6.24.3
> kernel.
Hi,
I can see the patch in http://www.kernel.org/pub/linux/kernel/v2.6/,
but no incremental patch in
http://www.kernel.org/pub/linux/kernel/v2.6/incr/.
Aloha,
The "ext2_readdir() filp->f_pos fix" patch looks weird...
Perhaps the "filp->f_pos += le16_to_cpu(de->rec_len);" line should be
outside of the if statement like the indentation implies?
As it is, filp->f_pos gets corrupted if de->inode is ever zero...
This could possibly explain why I had
Jamie Lokier wrote:
By durable, I mean that fsync() should actually commit writes to
physical stable storage,
Yes, it should.
I was surprised that fsync() doesn't do this already. There was a lot
of effort put into block I/O write barriers during 2.5, so that
journalling filesystems can
On Tue, 26 Feb 2008 07:26:50 + Jamie Lokier <[EMAIL PROTECTED]> wrote:
> (It would be nicer if sync_file_range()
> took a vector of ranges for better elevator scheduling, but let's
> ignore that :-)
Two passes:
Pass 1: shove each of the segments into the queue with
Yinghai Lu wrote:
which is the same. set_cpu_cap() is indeed the cleaner form to do this
so your patch is correct as a cleanup.
set_cpu_cap is right
==
set_bit(X86_FEATURE_CONSTANT_TSC, >x86_capability); ===> is wrong
should be
set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > set_cpu_cap is right
> > ==
> > set_bit(X86_FEATURE_CONSTANT_TSC, >x86_capability); ===> is wrong
> > should be
> > set_bit(X86_FEATURE_CONSTANT_TSC, c->x86_capability);
> >
> > x86_capability is a array ...
> >
> > so this could prevent some data
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> > #define set_cpu_cap(c, bit) set_bit(bit, (unsigned long
> > *)((c)->x86_capability)
> >
> > which is the same. set_cpu_cap() is indeed the cleaner form to do this
> > so your patch is correct as a cleanup.
> set_cpu_cap is right
> ==
>
On Tue, Feb 26, 2008 at 01:13:56AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, 26 of February 2008, Christoph Hellwig wrote:
> > On Tue, Feb 26, 2008 at 12:52:56AM +0100, Rafael J. Wysocki wrote:
> > > > I'm not suggesting a partial revert; I just wonder which part of the
> > > > change is
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> so it could be off automatically when PARAVIRT_GUEST or X86_VSMP is
> not there
thanks, applied. This whole VSMP + PARAVIRT business has to be done
cleaner though before it's upstream ready, all the Kconfig magic looks
rather twisted.
Ingo
Dear kernel,
This is a proposal to add "proper" durable fsync() and fdatasync() to Linux.
First the problem, then a proposed solution "with benefits", so to speak.
I need feedback on the details, before implementing anything. Or
(hopefully) someone else thinks it's very important and does it
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Ingo Molnar wrote:
>> Jeremy, you might want to start tracking x86.git#testing:
>>
>> http://people.redhat.com/mingo/x86.git/README
>>
>> if you want to follow the latest & greatest x86.git code.
>>
>
> Right, will do.
generally it's as
commit feaa7bba026c181ce071d5a4884f7f9dd26207a1 removed call to
init_special_inode from inode lookuping, this cause problems as:
# mknod /mnt/gfs2/dev/null c 1 3
# cat /mnt/gfs2/dev/null
cat: /mnt/gfs2/dev/null: Invalid argument
without special inode, GFS2 cannot support char device file,
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> some BIOS only let AMD fam 10h handle bus0, and nvidia mcp55/ck804 to
> handle other buses. at that case MCFG will cover all over them.
>
> but with acpi=off, we can not use MCFG. this patch will double check
> the busnbits, and if it is less handling
struct inode_operations gfs2_dev_iops is always the same as gfs2_file_iops,
since Jan 2006, when GFS2 merged into mainstream kernel.
So one of them could be removed.
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
fs/gfs2/inode.c |2 +-
fs/gfs2/ops_inode.c | 10 --
On Mon, Feb 25, 2008 at 11:20 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Yinghai Lu <[EMAIL PROTECTED]> wrote:
>
>
> > also fix error in early_init_intel and reference about x86_capality,
> > because it is array already.., prevent possible data corruption...
>
> hm, why should there be
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> also fix error in early_init_intel and reference about x86_capality,
> because it is array already.., prevent possible data corruption...
hm, why should there be data corruption:
> - set_bit(X86_FEATURE_CONSTANT_TSC, >x86_capability);
> +
On Mon, 25 Feb 2008, Andrew Morton wrote:
> On Tue, 26 Feb 2008 16:22:43 +1100 Tim Connors <[EMAIL PROTECTED]> wrote:
>
> > Possibly because of the frequent renegotiating my iwl4965 card has
> > been making, it has now decided it's not going to pass packets
> > reliably until presumably next
* Yinghai Lu <[EMAIL PROTECTED]> wrote:
> early_init_intel is introduced by
>
> commit 2b16a2353814a513cdb5c5c739b76a19d7ea39ce
> Author: Andi Kleen <[EMAIL PROTECTED]>
> Date: Wed Jan 30 13:32:40 2008 +0100
>
> x86: move X86_FEATURE_CONSTANT_TSC into early cpu feature detection
>
> set
This "flaw" isn't a new thing, of course. I remember pointing out the rather
annoying proclivity of the PM framework to deadlock when suspend() tried to
remove USB devices ... back around 2.6.10 or so. Things have shuffled around
a bit, and gotten better in some cases, but not fundamentally
early_init_intel is introduced by
commit 2b16a2353814a513cdb5c5c739b76a19d7ea39ce
Author: Andi Kleen <[EMAIL PROTECTED]>
Date: Wed Jan 30 13:32:40 2008 +0100
x86: move X86_FEATURE_CONSTANT_TSC into early cpu feature detection
set CONSTANT_TSC for intel cpus
but it already set in
Hi,
> >>> I'll send out a prototype for comment.
> >
> > Something like the patch below. The effects of cgroup_disable=foo are:
> >
> > - foo doesn't show up in /proc/cgroups
>
> Or we can print out the disable flag, maybe this will be better?
> Because we can distinguish from disabled and not
On Mon, 25 Feb 2008, Paul Jackson wrote:
> $ grep mpol_store_user_nodemask mm/mempolicy.c
> static inline int mpol_store_user_nodemask(const struct mempolicy *pol)
> if (mpol_store_user_nodemask(policy))
> if (!mpol_store_user_nodemask(a))
> if
Please pull from the for-linus branch:
git pull git://oss.sgi.com:8090/xfs/xfs-2.6.git for-linus
This will update the following files:
fs/xfs/xfs_bit.c | 103 ++
fs/xfs/xfs_bit.h | 27 ++---
fs/xfs/xfs_rtalloc.c | 19
Hi,
On Tue, Feb 26, 2008 at 8:27 AM, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> > You could try passing the --callgraph option to opcontrol.
>
> Hmm, perhaps I am missing something but I don't think that does what
> sysprof does. At least I can't find where in the oprofile kernel code
> does
On Tue, 26 Feb 2008, Paul Jackson wrote:
> David wrote:
> +static nodemask_t mpol_relative_nodemask(const nodemask_t *orig,
> + const nodemask_t *rel)
> +{
> + nodemask_t ret;
> + nodemask_t tmp;
>
> Could you avoid needing the nodemask_t 'ret' on the
On Tue, 26 Feb 2008 16:22:43 +1100 Tim Connors <[EMAIL PROTECTED]> wrote:
> Possibly because of the frequent renegotiating my iwl4965 card has
> been making, it has now decided it's not going to pass packets
> reliably until presumably next time I reboot.
>
> I've noticed messages in syslog that
When EFI_DEBUG is defined to a non-zero value in arch/ia64/kernel/efi.c,
the efi memory regions are displayed. This patch enhances the
display code in a few ways:
1. Use TB, GB and MB as well as KB as units.
Although this introduces rounding errors (KB doesn't as
size is always a multiple
On Sun, Feb 24, 2008 at 5:12 AM, Nicholas Miell <[EMAIL PROTECTED]> wrote:
> > Sysprof tracks the full stack frame so it can provide meaningful call
> > tree (who called what) which is invaluable for spotting hot _paths_. I
> > don't see how oprofile can do that as it tracks instruction pointers
2008/2/25 Rafael J. Wysocki <[EMAIL PROTECTED]>:
> This message contains a list of some regressions from 2.6.24 reported since
> 2.6.25-rc1 was released, for which there are no fixes in the mainline I know
> of. If any of them have been fixed already, please let me know.
If you want that, I
On Tue, Feb 26, 2008 at 12:23:34AM +0100, [EMAIL PROTECTED] wrote:
> Hello,
>
> I would like to know who is in charge with the linux credit list since i will
> no longer use my current email. I'm using temporary this email to update
> existing info.
you'd better submit a patch for the files
On Mon, Feb 25, 2008 at 7:23 PM, Li Zefan <[EMAIL PROTECTED]> wrote:
>
> Should those pathces be rebased againt 2.6.25-rc3 ?
>
No, because they're against 2.6.25-rc2-mm1, which is already has (I
think) any of the new bits in 2.6.25-rc3 that would be affected by
these patches.
Paul
--
To
On Thursday 21 February 2008 21:58, Robin Holt wrote:
> On Thu, Feb 21, 2008 at 03:20:02PM +1100, Nick Piggin wrote:
> > > > So why can't you export a device from your xpmem driver, which
> > > > can be mmap()ed to give out "anonymous" memory pages to be used
> > > > for these communication
David wrote:
+static nodemask_t mpol_relative_nodemask(const nodemask_t *orig,
+const nodemask_t *rel)
+{
+ nodemask_t ret;
+ nodemask_t tmp;
Could you avoid needing the nodemask_t 'ret' on the stack, by passing
in a "nodemask_t *" pointer to
Hi all,
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between
On Tue, Feb 26, 2008 at 02:39:23PM +0900, Samuel Masham wrote:
> On Tue, Feb 26, 2008 at 10:00 AM, Greg Kroah-Hartman <[EMAIL PROTECTED]>
> wrote:
> > We (the -stable team) are announcing the release of the 2.6.24.3
> > kernel.
> >
>
> Hi Greg, Stable people :)
>
> Can you confirm you have the
On Saturday February 23, [EMAIL PROTECTED] wrote:
> On Wed, 20 Feb 2008 15:46:10 +0100 Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Another posting of the full swap over NFS series.
>
> Well I looked. There's rather a lot of it and I wouldn't pretend to
> understand it.
But pretending is
On Tue, Feb 26, 2008 at 1:48 PM, Dave Young <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 26, 2008 at 1:22 PM, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> > On Mon, 25 Feb 2008 10:14:36 +0800 Dave Young wrote:
> >
> > > On Sun, Feb 24, 2008 at 8:46 AM, Dave Jones <[EMAIL PROTECTED]> wrote:
> > > >
On Tue, Feb 26, 2008 at 1:22 PM, Randy Dunlap <[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008 10:14:36 +0800 Dave Young wrote:
>
> > On Sun, Feb 24, 2008 at 8:46 AM, Dave Jones <[EMAIL PROTECTED]> wrote:
> > > The boot_delay switch seems to be behaving strangely in the
> > > current -git.
David wrote:
+static inline int mpol_store_user_nodemask(const struct mempolicy *pol)
+{
+ return !!(pol->flags & MPOL_F_STATIC_NODES);
+}
Why the double-negative? As best as I can tell, the return value of
mpol_store_user_nodemask() is only used in conditional contexts:
$ grep
On Tue, Feb 26, 2008 at 10:00 AM, Greg Kroah-Hartman <[EMAIL PROTECTED]> wrote:
> We (the -stable team) are announcing the release of the 2.6.24.3
> kernel.
>
Hi Greg, Stable people :)
Can you confirm you have the mips irq probe crash fix in your queue
for the next stable release
See:
Possibly because of the frequent renegotiating my iwl4965 card has
been making, it has now decided it's not going to pass packets
reliably until presumably next time I reboot.
I've noticed messages in syslog that I hadn't seen when things were
working fine. The problem possibly has only surfaced
On Mon, Feb 25, 2008 at 8:05 PM, Ravikiran Thirumalai <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote:
> >> I don't quite understand the purpose of the patch to begin with. Looking
> at
> >> the current x86 git tree, apic_is_clustered_box is used only to
On Mon, 25 Feb 2008 10:14:36 +0800 Dave Young wrote:
> On Sun, Feb 24, 2008 at 8:46 AM, Dave Jones <[EMAIL PROTECTED]> wrote:
> > The boot_delay switch seems to be behaving strangely in the
> > current -git. Setting it to =10 makes the output 'bursty'
> > it becomes slow for some printk's
On Mon, Feb 25, 2008 at 11:30:03PM -0500, Miles Lane wrote:
> Hello,
>
> When I booted this kernel, the process was hugely delayed in shpchp.
> I don't think I usually build this driver, so perhaps this is its
> standard behavior when the hardware is missing, or some such? Or, is
> this a bug in
On Sat, Feb 16, 2008 at 11:37:33PM +, Adrian McMenamin wrote:
> Remove an unused variable from the definition of struct maple_device
>
> Signed-off-by: Adrian McMenamin <[EMAIL PROTECTED]>
> ---
>
> diff -ruN a/include/linux/maple.h b/include/linux/maple.h
> --- a/include/linux/maple.h
On Mon, Feb 18, 2008 at 02:09:10PM +0100, Roel Kluin wrote:
> !unlikely(hd->base) is equivalent to likely(!hd->base) (for instance see
> comments with commit fd312561adcc90e924f35d3032d5493aeb4c3017), I think
> the ioremap is expected to succeed? please confirm that's right.
> The patch below was
On Mon, Feb 25, 2008 at 07:40:26AM +, Adrian McMenamin wrote:
> On Mon, 2008-02-25 at 14:33 +0900, Paul Mundt wrote:
> > On Sun, Feb 24, 2008 at 10:32:53PM +, Adrian McMenamin wrote:
> > > On Sun, 2008-02-24 at 21:50 +, Adrian McMenamin wrote:
> > > > On Sun, 2008-02-24 at 14:30 +,
On Tue, 26 Feb 2008, Ian Kent wrote:
> +
> + /* Set mount requestor */
> + if (ino) {
> + if (ino) {
> + ino->uid = wq->uid;
> + ino->gid = wq->gid;
> + }
> + }
> +
> It was only later I tried oprofile and found it not only much more
> difficult to use, but also much less useful when I did get it to work.
This surprises me. Can you please elaborate on why oprofile is "much
less useful" than sysprof?
Anton - who has used oprofile to analyse and tune
Hi Peter,
> Usable for me is a cli interface. Also, I absolutely love opannotate.
I definitely agree there.
It's interesting to note that sysprof requires you to run the GUI as
root in order to work. Maybe Ingo and Arjan are confident there are no
bugs in all the libraries that sysprof links
David wrote:
+ /* add additional MPOL_* modes here */
That doesn't explicitly say what I was most worried about saying, which
is that those MPOL_* terms have values visible in the kernel's public
API, and it does say more than might be true, and it doesn't explain
why it says what it says.
Hi Andrew,
Patch to add a display mount option to show the device number
of the autofs mount super block.
Signed-off-by: Ian Kent < [EMAIL PROTECTED]>
Ian
---
diff -up
linux-2.6.25-rc2-mm1/fs/autofs4/inode.c.add-mount-device-display-option
linux-2.6.25-rc2-mm1/fs/autofs4/inode.c
---
> @@ -2242,6 +2241,9 @@ static long cgroup_create(struct cgroup *parent,
> struct dentry *dentry,
> cgrp->root = parent->root;
> cgrp->top_cgroup = parent->top_cgroup;
>
> + if (notify_on_release(parent))
> + set_bit(CGRP_NOTIFY_ON_RELEASE, >flags);
Good
On Mon, Feb 25, 2008 at 11:08:55PM +0100, Andreas Schwab wrote:
> Borislav Petkov <[EMAIL PROTECTED]> writes:
>
> > On Mon, Feb 25, 2008 at 08:38:22PM +0100, Andreas Schwab wrote:
> >> "Kiyoshi Ueda" <[EMAIL PROTECTED]> writes:
> >>
> >> > I'm looking at this problem, but currently no idea why
On Mon, 25 Feb 2008, Paul Jackson wrote:
> Eh ... each bit of added clarity to the code reduces
> errors.
>
> Looking around the kernel, it really seems to me to be
> a common coding to explicitly spell out enum values
> when for some reason they actually matter.
>
> Like most coding
> > From: Soren Sandmann <[EMAIL PROTECTED]>
> > Subject: [PATCH] x86: add the debugfs interface for the sysprof tool
> >
> > The sysprof tool is a very easy to use GUI tool to find out where
> > userspace is spending CPU time. See
> > http://www.daimi.au.dk/~sandmann/sysprof/ for more
On Tue, Feb 26, 2008 at 4:45 AM, Michael S. Tsirkin
<[EMAIL PROTECTED]> wrote:
On Mon, Feb 25, 2008 at 9:46 PM, Andrew Morton
<[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008 21:19:24 +0200 "Michael S. Tsirkin"
<[EMAIL PROTECTED]> wrote:
> You mean suspend-to-ram works correctly on your
On Tue, Feb 26, 2008 at 04:46:25AM +0100, Andi Kleen wrote:
>> I don't quite understand the purpose of the patch to begin with. Looking at
>> the current x86 git tree, apic_is_clustered_box is used only to determine if
>> tsc is synchronized on the platform. The AMD docs imply that TSC's are
David wrote:
> I don't suspect that a kernel developer is going
> to make such an egregious error.
Eh ... each bit of added clarity to the code reduces
errors.
Looking around the kernel, it really seems to me to be
a common coding to explicitly spell out enum values
when for some reason they
Hi Russell,
On Sat, 16 Feb 2008 00:09:43 + Russell King <[EMAIL PROTECTED]> wrote:
>
> On Tue, Feb 12, 2008 at 12:02:08PM +1100, Stephen Rothwell wrote:
> > I will attempt to build the tree between each merge (and a failed build
> > will again cause the offending tree to be dropped). These
Hi Marcel
>> --- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25
>> 17:17:11.0 +0900
>> +++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25
>> 17:30:23.0 +0900
>> @@ -1313,8 +1313,17 @@
>> hci_dev_lock(hdev);
>>
>> conn = hci_conn_hash_lookup_ba(hdev, ev->link_type,
On Mon, 25 Feb 2008 17:00:24 -0800 Greg Kroah-Hartman wrote:
> We (the -stable team) are announcing the release of the 2.6.24.3
> kernel.
>
> It fixes a number of different bugs and all users of the 2.6.24 series
> are encouraged to upgrade.
>
> I'll also be replying to this message with a copy
On Wednesday 20 February 2008 09:01, Alexey Dobriyan wrote:
> On Tue, Feb 19, 2008 at 11:47:11PM +0300, wrote:
> > > Are you reproducing it simply by running the
> > > ftest03 binary directly from the shell? How many times between oopses?
> > > It is multi-process but no threads, so races should
> I don't quite understand the purpose of the patch to begin with. Looking at
> the current x86 git tree, apic_is_clustered_box is used only to determine if
> tsc is synchronized on the platform. The AMD docs imply that TSC's are not
> guaranteed to be synced across cores between nodes --
On Mon, Feb 25, 2008 at 02:05:45PM -0800, Yinghai Lu wrote:
>On Mon, Feb 25, 2008 at 11:08 AM, Ravikiran Thirumalai
><[EMAIL PROTECTED]> wrote:
>> ...
>> Andi, Yes. AMD based vSMPowered systems uses clustered APICs, and this
>> check base on cpu vendor id is not good :(.
>
>please check if you
Thanks, Robert. My device does support multiple vectors.
When looking into functions called by pci_enable_msix(), I found
msi_compose_msg() in arch/i386/kernel/io_apic.c. It tries to get destination
CPU (TARGET_CPUS) and set this information to msg->address_lo. My question is
about
On Mon, 25 Feb 2008, Paul Jackson wrote:
> +enum {
> + MPOL_DEFAULT,
> + MPOL_PREFERRED,
> + MPOL_BIND,
> + MPOL_INTERLEAVE,
> + MPOL_MAX, /* always last member of enum */
>
> Aren't the values that these constants take part of the
> user visible kernel API?
>
> In
Andrew Morton wrote:
> On Mon, 25 Feb 2008 23:57:46 +0530 Balbir Singh <[EMAIL PROTECTED]> wrote:
>
>> The memory controller has a requirement that while writing values, we need
>> to use echo -n. This patch fixes the problem and makes the UI more
>> consistent.
>
> that's a decent improvement
Hi Andrew,
Patch to add miscellaneous device to autofs4 module for
ioctls.
Signed-off-by: Ian Kent < [EMAIL PROTECTED]>
Ian
---
diff -up linux-2.6.25-rc2-mm1/fs/autofs4/expire.c.device-node-ioctl
linux-2.6.25-rc2-mm1/fs/autofs4/expire.c
---
Hi Andrew,
Patch to track the uid and gid of the last process to request
a mount for on an autofs dentry.
Signed-off-by: Ian Kent < [EMAIL PROTECTED]>
Ian
---
diff -up linux-2.6.25-rc2-mm1/fs/autofs4/inode.c.track-last-mount-ids
linux-2.6.25-rc2-mm1/fs/autofs4/inode.c
---
Hi Andrew,
Patch to catch invalid dentry when calculating it's path.
Signed-off-by: Ian Kent <[EMAIL PROTECTED]>
Ian
---
diff -up linux-2.6.25-rc2-mm1/fs/autofs4/waitq.c.getpath-check-valid-dentry
linux-2.6.25-rc2-mm1/fs/autofs4/waitq.c
---
[EMAIL PROTECTED] wrote:
> This patchset is a roll-up of the non-contraversial items of the
> various patches that I've sent out recently, fixed according to the
> feedback received.
>
> In summary they are:
>
> - general rename of read_uint/write_uint to read_u64/write_u64
>
> - use these
Global variables should be defined in C files, not in headers.
1) Comment out unused vars
GlobalDnotifyRsp_Q
GlobalUidList
2) Declare vars in cifsfs.c that need it and change to extern in
cifsglob.h
3) Change to extern in cifsglob.h for vars that were already being
declared in cifsfs.c
4)
Hi Andrew,
There is a problem with active restarts in autofs (that is to
say restarting autofs when there are busy mounts).
Currently autofs uses "umount -l" to clear active mounts at
restart. While using lazy umount works for most cases, anything
that needs to walk back up the mount tree to
David wrote:
+enum {
+ MPOL_DEFAULT,
+ MPOL_PREFERRED,
+ MPOL_BIND,
+ MPOL_INTERLEAVE,
+ MPOL_MAX, /* always last member of enum */
Aren't the values that these constants take part of the
user visible kernel API?
In other words, if someone added another
Hi Quel,
-- Original message --
From: Thomas Gleixner <[EMAIL PROTECTED]>
On Fri, 22 Feb 2008, David Woodhouse wrote:
On Fri, 2008-02-22 at 08:23 +0100, Thomas Gleixner wrote:
+ del_timer(>info_timer);
+
hcon->l2cap_data = NULL;
Hi Louis,
I fixed all of errors except 80 characters warning.
Thanks
Louis JANG
Signed-off-by: Louis JANG <[EMAIL PROTECTED]>
--- linux-2.6.23/net/bluetooth/hci_event.c.orig 2008-02-25
17:17:11.0 +0900
+++ linux-2.6.23/net/bluetooth/hci_event.c 2008-02-25
17:30:23.0 +0900
Paul Menage wrote:
>>> I'll send out a prototype for comment.
>
> Something like the patch below. The effects of cgroup_disable=foo are:
>
> - foo doesn't show up in /proc/cgroups
Or we can print out the disable flag, maybe this will be better?
Because we can distinguish from disabled and not
* Jesper Juhl ([EMAIL PROTECTED]) wrote:
>
> get_marker() may return NULL, so test for it.
>
Hrm, yes, if we have two marker_probe_unregister callers calling it for
the same marker, one expecting it to fail and they race, yes, it can
happen. Although this is not expected to happen often if the
Quoting Christoph Hellwig <[EMAIL PROTECTED]>:
On Mon, Feb 25, 2008 at 02:49:22PM -0800, Andrew Morton wrote:
the things which it finds.
> +static DECLARE_MUTEX(kmmio_init_mutex);
That's not a mutex.
> + down(_init_mutex);
It's a semaphore. Please do convert it to a mutex.
Andy, I'd say
Paul Jackson wrote:
So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as lower
level mechanism that actually makes kernel aware of what's isolated what's not.
Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
but scheduler does not use cpusets
Hi
this patch is page reclaim improvement.
o previous discussion:
http://marc.info/?l=linux-mm=120339997125985=2
o test method
$ ./hackbench 120 process 1000
o test result (average of 5 times measure)
limit hackbench sys-time major-fault max-spent-time
time(s)
some BIOS only let AMD fam 10h handle bus0, and nvidia mcp55/ck804
to handle other buses. at that case MCFG will cover all over them.
but with acpi=off, we can not use MCFG. this patch will double check
the busnbits, and if it is less handling 256 bues, and acpi=off
will forcely reset the mmconf
Hi Aron,
Thanks for your patience.
If you still got into trouble, please let me know.
Thank you again,
-Original Message-
From: Aron Stansvik [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 26, 2008 6:52 AM
To: erich
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED];
在 2008-02-26Tue的 06:53 +0800，Jeff Garzik写道：
> Alan Cox wrote:
> >> Signed-off-by: Crane Cai <[EMAIL PROTECTED]>
> >> Acked-by: Jeff Garzik <[EMAIL PROTECTED]>
> >> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]>
> >
> > Vomitted-upon-by: Alan Cox <[EMAIL PROTECTED]>
> >
> >> -
Hi Peter,
Sorry for delay in reply.
Please, wrap your emails at 78 - most mailers can do this.
Done.
On Fri, 2008-02-22 at 14:05 -0800, Max Krasnyanskiy wrote:
Peter Zijlstra wrote:
On Thu, 2008-02-21 at 18:38 -0800, Max Krasnyanskiy wrote:
List of commits
cpuisol: Make cpu
>-Original Message-
>From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED]
>Sent: Sunday, February 24, 2008 3:18 AM
>To: Soeren Sonnenburg
>Cc: Oliver Pinter; Linux Kernel; Pallipadi, Venkatesh
>Subject: Re: 2.6.25-current-git hangs on boot
>
>On Sunday, 24 of February 2008, Soeren
Am Sonntag, 24. Februar 2008 schrieb Paul E. McKenney:
> On Sun, Feb 24, 2008 at 04:38:15PM +0100, Karsten Wiese wrote:
> > Am Samstag, 23. Februar 2008 schrieb Karsten Wiese:
> > > Am Samstag, 23. Februar 2008 schrieb Paul E. McKenney:
> > > > On Sat, Feb 23, 2008 at 01:41:02PM +0100, Karsten
> So. I see cpusets as a higher level API/mechanism and cpu_isolated_map as
> lower
> level mechanism that actually makes kernel aware of what's isolated what's
> not.
> Kind of like sched domain/cpuset relationship. ie cpusets affect sched domains
> but scheduler does not use cpusets directly.
Roman Zippel <[EMAIL PROTECTED]> wrote:
> I would actually prefer to introduce an explicit API for signed 64
> divides to get rid of the temps completely
Yeah, that's a better plan.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Daniel Phillips <[EMAIL PROTECTED]> wrote:
> On Monday 25 February 2008 15:19, David Howells wrote:
> > So I guess there's a problem in cachefiles's efficiency - possibly due
> > to the fact that it tries to be fully asynchronous.
>
> OK, not just my imagination, and it makes me feel better
On Feb 25 2008 23:13, Richard Knutsson wrote:
> Miles Bader wrote:
>> Why do people even respond to these trolls...?
>>
> Obviously, this must to have been discussed before, with a clear conclusion.
It has been discussed before, at http://lkml.org/lkml/2007/11/12/19 .
What is really
Hi,
On Thu, 21 Feb 2008, David Howells wrote:
> The kernel NTP code shouldn't hand 64-bit *signed* values to do_div(). Make
> it
> instead hand 64-bit unsigned values. This gets rid of a couple of warnings.
I would actually prefer to introduce an explicit API for signed 64
divides to get
1 - 100 of 1086 matches
Mail list logo
