> These patches propose to break the recursion instead by removing the
> linux/pagemap.h -> linux/highmem.h inclusion. I'd like to know
> whether there are any fundamental reasons that this include should be
> preserved.
Not fundamental reasons, but these patches break the ia64 build for most
con
On Fri, 26 Oct 2007, Paul Jackson wrote:
> 1) If you want the current behaviour, where set_mempolicy(MPOL_INTERLEAVE)
> calls mean what they say, and cpusets tries as best it can (imperfectly)
> to honor those memory policy calls, even in the face of changing cpusets,
> then leave mem
On Friday 26 October 2007 16:37, Arjan van de Ven wrote:
> In addition, I'd like to ask you to put a file in Documentation/
> somewhere that describes what AppArmor is intended security protection
> is (it's different from SELinux for sure for example); by having such a
> document for each LSM user
On Fri, 2007-10-26 at 11:46 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > Actually, my patch doesn't change the set_mempolicy() API at all, it
> > just co-opts a currently unused/illegal value for the nodemask to
> > indicate "all allowed nodes". Again, I need
From: Tony Jones <[EMAIL PROTECTED]>
Minor performance enhancement.
Thread flag TIF_SYSCALL_AUDIT is not cleared for new children when audit
context creation has been disabled (auditctl -e0). This can cause new children
forked from a parent created when audit was enabled to not take the fastest
On 10/26/07, Paul Jackson <[EMAIL PROTECTED]> wrote:
> Michael wrote:
> > PS Note my new addres for man-apges: [EMAIL PROTECTED]
>
> Noted.
>
> > Is there anything I can do to assist?
>
> Got any spare round tuit's ;)?
I ran out quite some time ago unfortunately.
Cheers,
Michael
-
To unsubscribe
On Fri, Oct 26, 2007 at 11:23:53AM -0700, John Johansen wrote:
> In the current code, both vfsmounts are always identical, and so one of
> the two should go, agreed.
>
> The thought behind passing both vfsmounts was that they could differ but
> point to the same super_block, in which case renames
> There are lots and lots of files that currently contain kerneldoc
> comments that are unreferenced by docbook (and have been for years).
> We should somehow sweep them all up into some sort of bucket
> automatically.
That'd be another thing, but yes, it'd be nice as well. Not something
I'm aimi
On Fri, 26 Oct 2007, Paul Jackson wrote:
> Without at least this sort of change to MPOL_INTERLEAVE nodemasks,
> allowing either empty nodemasks (Lee's proposal) or extending them
> outside the current cpuset (what I'm cooking up now), there is no way
> for a task that is currently confined to a si
On Fri, Oct 26, 2007 at 07:37:40PM +0100, Russell King wrote:
> On Fri, Oct 26, 2007 at 07:18:57PM +0200, Rodolfo Giometti wrote:
> > On Fri, Oct 26, 2007 at 06:00:31PM +0100, Russell King wrote:
> > > Or that - probably a sysfs attribute on the pcmcia socket would be
> > > better.
> >
> > Ok, but
Hi;
Following trivial patch corrects
[EMAIL PROTECTED] linux-2.6 $ make
CHK include/linux/version.h
CHK include/linux/utsrelease.h
CALLscripts/checksyscalls.sh
CHK include/linux/compile.h
LD net/ipv6/built-in.o
CC [M] net/ipv6/tcp_ipv6.o
net/ipv6/tcp_ipv6.c: In
On Fri, 2007-10-26 at 22:24 +0200, Andreas Gruenbacher wrote:
> On Friday 26 October 2007 13:30, Miklos Szeredi wrote:
> > There's a slight problem (other than HCH not liking it) with this
> > approach of passing the open file in iattr: for special files, the
> > struct file pointer makes no sense
On Fri, Oct 26, 2007 at 05:57:27AM -0600, Matthew Wilcox wrote:
> On Fri, Oct 26, 2007 at 12:11:01PM +1000, Rusty Russell wrote:
> > This just seems like more optimization and complexity that we need.
> > Interfaces
> > using vsnprintf don't seem like good candidates for optimization.
>
> Th
Alexey Starikovskiy wrote:
> Andrey Borzenkov wrote:
>> is it in -rc1 or can you point me to the patch (I'd rather avoid having
>> to pull from different git trees). Thank you.
> No, it should be rc1.
>>
>> And what about ACPI_PROCFS case? It still needs attention I believe.
> As you can see, ther
On Thu, 18 Oct 2007 23:17:41 +0400
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> I'm pleased to announce sixth release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tre
On Fri, 26 Oct 2007 14:05:47 -0700
Martin Bligh <[EMAIL PROTECTED]> wrote:
> > Martin was talking about some mad scheme wherin you'd create a bunch of
> > pseudo files (say, /proc/foo/0, /proc/foo/1, ..., /proc/foo/9) and each one
> > would become "ready" when the MM scanning priority reaches 10%,
On Fri, 26 Oct 2007, Christoph Lameter wrote:
> We would need two fields in the policy structure
>
> 1. The specified nodemask (generally ignored)
>
What I've called pol->passed_nodemask.
> 2. The effective nodemask (specified & cpuset_mems_allowed)
>
Which is pol->v.nodes.
> If we have the
Alexey Starikovskiy wrote:
> ACPI: use select POWER_SUPPLY for AC, BATTERY and SBS
>
> From: Alexey Starikovskiy <[EMAIL PROTECTED]>
>
> POWER_SUPPLY is needed for AC, battery, and SBS sysfs support.
> Use 'select' instead of 'depends on', as it is will not be selected
> by anything else, leading t
On Thu, 18 Oct 2007 16:15:31 -0400
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
> Hi,
>
> AIX contains the SIGDANGER signal to notify applications to free up some
> unused cached memory:
>
> http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
>
> There have been a few discussions on im
On Fri, 26 Oct 2007, David Rientjes wrote:
> Well, passing a single node to set_mempolicy() for MPOL_INTERLEAVE doesn't
> make a whole lot of sense in the first place. I prefer your solution of
> allowing set_mempolicy(MPOL_INTERLEAVE, NODE_MASK_ALL) to mean "interleave
> me over everything I'
Andrew Morton wrote:
On Thu, 18 Oct 2007 16:15:31 -0400
Marcelo Tosatti <[EMAIL PROTECTED]> wrote:
Hi,
AIX contains the SIGDANGER signal to notify applications to free up some
unused cached memory:
http://www.ussg.iu.edu/hypermail/linux/kernel/0007.0/0901.html
There have been a few discussio
Frans Pop wrote:
> Alexey Starikovskiy wrote:
>> Andrey Borzenkov wrote:
>>> is it in -rc1 or can you point me to the patch (I'd rather avoid having
>>> to pull from different git trees). Thank you.
>> No, it should be rc1.
>>> And what about ACPI_PROCFS case? It still needs attention I believe.
>>
On Fri, 26 Oct 2007, Christoph Lameter wrote:
> > Well, passing a single node to set_mempolicy() for MPOL_INTERLEAVE doesn't
> > make a whole lot of sense in the first place. I prefer your solution of
> > allowing set_mempolicy(MPOL_INTERLEAVE, NODE_MASK_ALL) to mean "interleave
> > me over ev
On Fri, 2007-10-26 at 13:45 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, Paul Jackson wrote:
>
> > Without at least this sort of change to MPOL_INTERLEAVE nodemasks,
> > allowing either empty nodemasks (Lee's proposal) or extending them
> > outside the current cpuset (what I'm cooking up no
On Fri, 26 Oct 2007, David Rientjes wrote:
> You would pass NODE_MASK_ALL if your intent was to interleave over
> everything you have access to, yes. Otherwise you can pass whatever you
> want access to and your interleaved nodemask becomes
> mpol_rebind_policy()'s newmask formal (the cpuset's
On Friday 26 October 2007, Roland Dreier wrote:
> > The function that is returning ENODEV is the driver probe function.
> According
> > to Documentation/DocBook/writing_usb_driver/ch03.html when that function
> is
> > called
> >
> > "The driver now needs to verify that this device is act
On Fri, 26 Oct 2007 14:14:23 +0300, Riku Voipio wrote:
> On Fri, Oct 26, 2007 at 10:36:47AM +0200, Jean Delvare wrote:
> > Patch looks correct, however it doesn't apply on top of Mark's tree. I
> > was able to get it to apply by reverting "(f75375s) fix pwm mode
> > setting" first, but then the bui
On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
> For some systems [not mine], the nodemasks can get quite large. I have
> a patch, that I've tested atop Mel Gorman's "onezonelist" patches that
> replaces the nodemasks embedded in struct mempolicy with pointers to
> dynamically allocated ones. How
On Fri, 26 Oct 2007 22:44:56 +0200
Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> On Friday 26 October 2007 16:37, Arjan van de Ven wrote:
> > In addition, I'd like to ask you to put a file in Documentation/
> > somewhere that describes what AppArmor is intended security
> > protection is (it's
On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
> You don't need to save the entire mask--just note that NODE_MASK_ALL was
> passed--like with my internal MPOL_CONTEXT flag. This would involve
> special casing NODE_MASK_ALL in the error checking, as currently
> set_mempolicy() complains loudly if yo
On Friday 26 October 2007 23:13, Arjan van de Ven wrote:
> My main concern for now is a description of what it tries to protect
> against/in what cases you would expect to use it.
Okay, I see what you mean. Thanks.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the bo
On Fri, 19 Oct 2007 09:00:23 -0400
"Salyzyn, Mark" <[EMAIL PROTECTED]> wrote:
> ACK with comment ...
Please don't top-post and then include 65 kbytes of unneeded goop.
> This API changed in 2.4.23 switching to irqreturn_t, and 2.6.19 dropping
> the struct_pt_regs argument, this is yet another AP
On Fri, 26 Oct 2007 14:11:12 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> Sure, but in terms of high-level userspace interface, being able to
> select() on a group of priority buckets (spread across different
> nodes, zones and cgroups) seems a lot more flexible than any
> signal-based approac
Andrew Morton wrote:
That was a goofup. I proposed that we should add a #define
TWO_ARG_IRQ_HANDLERS (or whatever) and I think I actually wrote the patch,
but it got lost.
I agree it would be a kind thing to do in this case.
Yep, I was thinking that including
#define IRQ_HANDLER_V3
On Fri, Oct 26, 2007 at 01:38:12PM -0700, Luck, Tony wrote:
> Not fundamental reasons, but these patches break the ia64 build for most
> configs with:
>
> In file included from kernel/futex.c:59:
> include/asm/futex.h: In function `futex_atomic_op_inuser':
> include/asm/futex.h:62: error: implicit
On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
> > > Now, if we could replace the 'cpuset_mems_allowed' nodemask with a
> > > pointer to something stable, it might be a win.
> >
> > The memory policies are already shared and have refcounters for that
> > purpose.
>
> I must have missed that in th
Hmm. If I read this right, this bug seems to have been introduced by
commit 65b8291c4000e5f38fc94fb2ca0cb7e8683c8a1b ("dio: invalidate clean
pages before dio write") back in March.
Before that, we'd call invalidate_inode_pages2_range() unconditionally
after the call mapping->a_ops->direct_IO()
On Fri, 2007-10-26 at 14:17 -0700, Christoph Lameter wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > For some systems [not mine], the nodemasks can get quite large. I have
> > a patch, that I've tested atop Mel Gorman's "onezonelist" patches that
> > replaces the nodemasks embedded i
On Fri, 26 Oct 2007, Matt Mackall wrote:
> The following replaces the earlier patches sent. It should address
> David Rientjes's comments, and has been compile tested on all the
> architectures that it touches, save for parisc.
>
Looks good, thanks.
-
To unsubscribe from this list: send the lin
On Fri, 26 Oct 2007, Matt Mackall wrote:
> From: Matt Mackall <[EMAIL PROTECTED]>
>
> This pulls the shared map display code out of show_map and puts it in
> show_smap where it belongs.
>
> Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
> Cc: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> Cc: David
On Fri, 19 Oct 2007 11:42:41 +1000
Greg Ungerer <[EMAIL PROTECTED]> wrote:
> A new style serial driver for the Freescale ColdFire UART to replace
> the old style one currently in the tree (drivers/serial/mcfserial.c).
>
> Currently this UART is only found in the ColdFire CPU family of parts
> (th
This patch fixes a race between direct IO writes and non-direct IO
reads on the same file. The symptom is a stale file page seen by
any non-direct-IO reader, which persists until the page is invalidated
somehow (e.g. page rewritten again, or memory pressure, or reboot).
An improper return test ca
On Fri, 2007-10-26 at 14:18 -0700, David Rientjes wrote:
> On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
>
> > You don't need to save the entire mask--just note that NODE_MASK_ALL was
> > passed--like with my internal MPOL_CONTEXT flag. This would involve
> > special casing NODE_MASK_ALL in the er
On Friday, October 26, 2007 12:08 pm Kay Sievers wrote:
> > How does this conversion look?
>
> Seems fine, at a first look. You moved the device structure into the
> object where it belongs, instead of allocating one, and saving the
> pointer. You should really considering changing the core to do t
On Fri, 26 Oct 2007, Lee Schermerhorn wrote:
> So, you pass the subset, you don't set the flag to indicate you want
> interleaving over all available. You must be thinking of some other use
> for saving the subset mask that I'm not seeing here. Maybe restoring to
> the exact nodes requested if t
> I'm now testing crash on 32bit, but there is an issue before
> applying the patches. My machine stopped at checking 'hlt'
> after kexec, showing below message.
>
> CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
> Checking 'hlt' instruction...
>
> v2.6.23.1 works fine for 1st kernel.
> I'm inves
Linus Torvalds wrote:
> The gcc lists seem to often get to the point where people quote the
> standard, and that's that. In that environment, the paper standard (that
> hass *nothing* to do with reality) trumps any other argument. "What we do
> is _allowed_ by the standard" seems to be a good a
"Kir Kolyshkin" <[EMAIL PROTECTED]> writes:
> Eric,
>
> Could you please hold off the horses a bit and wait till Pavel Emelyanov
> returns? It means next Monday; he's currently at a conference whose organisers
> don't provide internet access.
When we decided to go top down (i.e. user interface fi
Jason Uhlenkott wrote:
On Fri, Oct 26, 2007 at 01:22:17 +0100, Alan Cox wrote:
On Thu, 25 Oct 2007 16:06:40 -0700
Mike Waychison <[EMAIL PROTECTED]> wrote:
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have pe
On Fri, Oct 26, 2007 at 01:22:17 +0100, Alan Cox wrote:
> On Thu, 25 Oct 2007 16:06:40 -0700
> Mike Waychison <[EMAIL PROTECTED]> wrote:
>
> > Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an
> > open file descriptor.
> >
> > It would be nice to allow users to have permiss
On Friday 26 October 2007 22:58:11 Miklos Szeredi wrote:
> For special files, f_op->fsetattr will be NULL, since
> init_special_inode() will set up i_fop that way.
>
> So the filesystem's fsetattr() will only be called for regular files
> and/or directories, depending on how it sets up i_fop.
>
> W
"Kir Kolyshkin" <[EMAIL PROTECTED]> writes:
> Eric, this problem is a known one. Currently Pavel and Sukadev are working on
> a
> appropriate signal management for namespaces.
I'm fairly certain that the signal issue you they are dealing with
is how to keep children from killing the init of a pi
Linus Torvalds wrote:
> So we may
> actually end up doing some IO, but then returning the "wrong" error code
> from the invalidate. Hmm?
>
A point. In an all-seeing, all-caring universe, it would be the read
hitting the cached page that couldn't be invalidated that would get
the error, not
Rik van Riel wrote:
On Fri, 26 Oct 2007 14:11:12 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
Sure, but in terms of high-level userspace interface, being able to
select() on a group of priority buckets (spread across different
nodes, zones and cgroups) seems a lot more flexible than any
signa
On Fri, Oct 26, 2007 at 05:40:25AM -0400, Jeff Garzik wrote:
> mach-integrator/pci_v3.c: no need to reference 'irq' arg, its constant
>
> mach-omap1/pm.c: remove extra whitespace
>
> arch/arm/mach-sa1100/ssp.c: remove braces around single C stmt
>
> arch/arm/plat-omap/mcbsp.c:
> - remove
On Fri, Oct 26, 2007 at 05:40:22AM -0400, Jeff Garzik wrote:
> arch/arm/mach-pxa/ssp.c|2 +-
> arch/arm/mach-s3c2410/usb-simtec.c |2 +-
> arch/arm/plat-omap/mailbox.c |2 +-
FWIW
Acked-by: Lennert Buytenhek <[EMAIL PROTECTED]>
-
To unsubscri
Arjan van de Ven wrote:
> My main concern for now is a description of what it tries to protect
> against/in what cases you would expect to use it. THe reason for asking
> this explicitly is simple: Until now the LSM discussions always ended
> up in a nasty mixed up mess around disagreeing on the th
On Fri, 26 Oct 2007 14:59:01 -0700
Martin Bligh <[EMAIL PROTECTED]> wrote:
> Rik van Riel wrote:
> > On Fri, 26 Oct 2007 14:11:12 -0700
> > Andrew Morton <[EMAIL PROTECTED]> wrote:
> >
> >> Sure, but in terms of high-level userspace interface, being able to
> >> select() on a group of priority bu
On Fri, Oct 26, 2007 at 14:59:57 -0700, Mike Waychison wrote:
> Jason Uhlenkott wrote:
> >Additionally, ext3_bmap() has this to say about it:
> >
> >if (EXT3_I(inode)->i_state & EXT3_STATE_JDATA) {
> >/*
> > * This is a REALLY heavyweight approach, but the us
Zach Brown wrote:
> Linus Torvalds wrote:
>> Hmm. If I read this right, this bug seems to have been introduced by
>> commit 65b8291c4000e5f38fc94fb2ca0cb7e8683c8a1b ("dio: invalidate clean
>> pages before dio write") back in March.
>
> Agreed. And it's a really dumb bug. ->direct_io will almos
Karsten Keil wrote:
* change #warning to a code comment
* add comment and special ifdef'd 64-bit code for a situation where
we must store a pointer into a CAPI field 'Data', which is fixed by
the interface at 32 bits.
Signed-off-by: Jeff Garzik <[EMAIL PROTECTED]>
Acked-by: Karsten Keil <[E
On Fri, 26 Oct 2007, Zach Brown wrote:
>
> I think that test should be changed to
How about not testing at all? Which was what the old code did.
Just do the invalidate unconditionally for any writes, and screw the end
result of the invalidate, since we cannot afford to overwrite the previous
* Tony Jones ([EMAIL PROTECTED]) wrote:
> From: Tony Jones <[EMAIL PROTECTED]>
> Minor performance enhancement.
>
> Thread flag TIF_SYSCALL_AUDIT is not cleared for new children when audit
> context creation has been disabled (auditctl -e0). This can cause new
> children
> forked from a parent
On Fri, 26 Oct 2007, Giacomo Catenazzi wrote:
>
> So we have the great opportunity to change the standard, then
> gcc will change ;-)
I see the smiley, but sadly, new standards take ten years or more to
mature. Which means that even if the upcoming one is "perfect", things
will be wrong with
Jason Uhlenkott wrote:
On Fri, Oct 26, 2007 at 14:59:57 -0700, Mike Waychison wrote:
Jason Uhlenkott wrote:
Additionally, ext3_bmap() has this to say about it:
if (EXT3_I(inode)->i_state & EXT3_STATE_JDATA) {
/*
* This is a REALLY heavyweight approach, but
On Fri, 26 Oct 2007 15:16:53 -0700
Crispin Cowan <[EMAIL PROTECTED]> wrote:
>
> > On the first part (discussion of the model) I doubt we can get
> > people to agree, that's pretty much phylosophical... on the second
> > part (how well the code/design lives up to its own goals) the
> > analysis ca
Andrew Morton <[EMAIL PROTECTED]> wrote:
> hm, seems a bit ungainly. Why can't we just make all the aout things in
> binfmt_elf.c depend upon CONFIG_BINFMT_AOUT?
That works too, I guess. I'll change it.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Linus Torvalds wrote:
> Hmm. If I read this right, this bug seems to have been introduced by
> commit 65b8291c4000e5f38fc94fb2ca0cb7e8683c8a1b ("dio: invalidate clean
> pages before dio write") back in March.
Agreed. And it's a really dumb bug. ->direct_io will almost always
return -EIOCBQUEUE
"Kir Kolyshkin" <[EMAIL PROTECTED]> writes:
> Speaking of this particular patch -- I don't understand how you fix
> "innumerable little bugs" by providing stubs instead of real functions.
I think it would be a disaster to use pid namespaces as currently
implemented 2.6.24-rc1 in a production envi
On Fri, 26 Oct 2007, Hiroshi Shimamoto wrote:
Added Venki to CC
> > I'm now testing crash on 32bit, but there is an issue before
> > applying the patches. My machine stopped at checking 'hlt'
> > after kexec, showing below message.
> >
> > CPU: Intel(R) Xeon(TM) CPU 3.80GHz stepping 0a
> > Check
On Fri, Oct 26, 2007 at 01:07:50PM -0400, bfields wrote:
> On Thu, Oct 18, 2007 at 02:57:59PM -0400, George G. Davis wrote:
> > On Wed, Oct 17, 2007 at 02:51:57PM -0400, George G. Davis wrote:
> > > ---
> > > Not sure if this is the correct fix but it does resolve the hangs we're
> > > observing in
Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Zach Brown wrote:
>> I think that test should be changed to
>
> How about not testing at all? Which was what the old code did.
>
> Just do the invalidate unconditionally for any writes, and screw the end
> result of the invalidate, since we cannot
On 25 Oct 2007, Ph. Marek told this:
> -) use some ramfs/shmfs or similar, and overwrite the data occasionally
>- not current data
>- runtime overhead (processor load)
This is roughly what the nscd implementation in glibc does: the client
can work over a socket, but prefers to ask the daem
v9fs_match_trans function returns arbitrary transport module instead of NULL
when the requested transport is not registered. This patch modifies the
function to return NULL in that case.
Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]>
---
commit 25ed88ed319e40fb6426e2aaefcc5f136aadd4ee
tree 2
The list of options that the fd transport accepts is missing end-of-options
marker. This patch adds it.
Signed-off-by: Latchesar Ionkov <[EMAIL PROTECTED]>
---
commit 70ec0c7936c2516d128fdb1a32d749071b8846ec
tree 8de5495f83b94096825f8bfe0767e4fcbaf36ef3
parent 25ed88ed319e40fb6426e2aaefcc5f136aad
This patch fixes the following build error with CONFIG_SYSCTL=n:
<-- snip -->
...
ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
ERROR: "sysctl_rmem_max" [drivers/net/rrunner.ko] undefined!
make[2]: *** [__modpost] Error 1
<--
On Fri, 26 Oct 2007, Zach Brown wrote:
>
> I can throw together a patch if you haven't already committed one by the
> time you read this ;).
I'm not touching that code except to send out possible patches for others
to test and comment on. I have no test-cases, nor any real interest in it.
So
On Fri, Oct 26, 2007 at 11:46:39AM +0200, Tilman Schmidt wrote:
> On Thu, 25 Oct 2007 19:56:47 -0700, Greg KH wrote:
> > On Fri, Oct 26, 2007 at 01:09:14AM +0200, Tilman Schmidt wrote:
> >> Am 25.10.2007 00:31 schrieb Adrian Bunk:
> >> > Generally, the goal is to get external modules included into
v9fs_parse_options function uses strsep which modifies the value of the
v9ses->options field. That modified value is later passed to the function
that creates the transport potentially making the transport creation
function to fail.
This patch creates a copy of v9ses->option field that v9fs_parse_
Adrian Bunk <[EMAIL PROTECTED]> writes:
> This patch fixes the following build error with CONFIG_SYSCTL=n:
>
> <-- snip -->
>
> ...
> ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
> ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
> ERROR: "sysctl_rmem_max" [drivers/net/rrunner
On Friday, 26 October 2007 03:03, CSights wrote:
> Hi LKML,
> My computer running kernel 2.6.23 does not "hibernate" (suspend to disk
> using
> the kernel's methods) with a program (named stringTest) running in gdb, but
> has received a SIGABRT.
> The hibernate is successful when run
Eric W. Biederman wrote:
Adrian Bunk <[EMAIL PROTECTED]> writes:
This patch fixes the following build error with CONFIG_SYSCTL=n:
<-- snip -->
...
ERROR: "sysctl_rmem_max" [fs/dlm/dlm.ko] undefined!
ERROR: "sysctl_wmem_max" [drivers/net/rrunner.ko] undefined!
ERROR: "sysctl_rmem_max" [driv
Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Zach Brown wrote:
>> I can throw together a patch if you haven't already committed one by the
>> time you read this ;).
>
> I'm not touching that code except to send out possible patches for others
> to test and comment on. I have no test-cases, nor
This patch adds support LZO compression in mkcramfs tool, so it can
generate a cramfs image compress with LZO.
To compile mkcramfs with this patch, liblzo2-dev package must be
installed.
The patch is created against mkcramfs tool ver 1.1 which can be found
at:
http://sourceforge.net/projects/cramf
This is a kernel patch to add support LZO compression in cramfs.
I used LZO kernel library patch done by Richard Purdie
[EMAIL PROTECTED], and my cramfs patch requires his LZO library
patch.
Richard's LZO kernel library patch can be found at:
http://lwn.net/Articles/238723/
This patch is generate
The following series is meant to clean up FIBMAP paths with the eventual goal
of allowing users to be able to FIBMAP their data.
I'm sending this as an RFC as I've only tested this on a x86_64 kernel with a
32bit binary on ext2 and I've noticed a couple ext2_warnings already.
I'm unsure of the
Return an error if the user requests a negative logical block in a file.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
fs/ioctl.c |2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6.23/fs/ioctl.c
===
--- linux-2.6.23.ori
Move FIBMAP logic out of file_ioctl() in preparation for introducing FIBMAP64.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
fs/ioctl.c | 25 ++---
1 file changed, 18 insertions(+), 7 deletions(-)
Index: linux-2.6.23/fs/ioctl.c
==
Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
file descriptor.
It would be nice to allow users to have permission to see where their data is
landing on disk, and there really isn't a good reason to keep them from getting
at this information.
Signed-off-by: Mike W
Attempt to deal with races with truncate paths.
I'm not really sure on the locking here, but these seem to be taken by the
truncate path. BKL is left as some filesystem may(?) still require it.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
fs/ioctl.c |8
1 file changed, 8 inse
Introduce FIBMAP64. This is the same as FIBMAP, but takes a u64.
This new routine requires filesystems to implement bmap64 if they want to
support > 2^31 blocks in a logical file. We do this to give time for
filesystems to be properly audited.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
Propagate an error (EFBIG) to userspace if the physical block is too large to
return in a 32bit int instead of truncating it.
Signed-off-by: Mike Waychison <[EMAIL PROTECTED]>
fs/ioctl.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
Index: linux-2.6.23/fs/ioctl.c
==
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 16:31:47 -0700
> Eric W. Biederman wrote:
> > Adrian Bunk <[EMAIL PROTECTED]> writes:
> >
> >
> >>This patch fixes the following build error with CONFIG_SYSCTL=n:
> >>
> >><-- snip -->
> >>
> >>...
> >>ERROR: "sysctl_rmem_max" [fs/dlm
All,
The following is an extra entry to enable the touch screen on the new LG
C1 EXPRESS DUAL machine.
Thanks,
D.
diff -uprN -X linux-2.6.21.4__vanilla/Documentation/dontdiff
linux-2.6.21.4__vanilla/drivers/serial/8250_pnp.c
linux-2.6.21.4__C1-PB11A3/drivers/serial/8250_pnp.c
--- linux-2.6.21.4_
David Miller wrote:
If DLM really wants minimum, it can use SO_SNDBUFFORCE and
SO_RCVBUFFORCE socket options and use whatever limits it
likes.
But even this is questionable.
Drift...
Is that something netperf should be using though? Right now it uses the regular
SO_[SND|RCV]BUF calls and is
From: Rick Jones <[EMAIL PROTECTED]>
Date: Fri, 26 Oct 2007 16:46:36 -0700
> David Miller wrote:
> > If DLM really wants minimum, it can use SO_SNDBUFFORCE and
> > SO_RCVBUFFORCE socket options and use whatever limits it
> > likes.
> >
> > But even this is questionable.
>
> Drift...
>
> Is that
Linus Torvalds wrote:
>
> On Fri, 26 Oct 2007, Zach Brown wrote:
>> I can throw together a patch if you haven't already committed one by the
>> time you read this ;).
>
> I'm not touching that code except to send out possible patches for others
> to test and comment on. I have no test-cases, nor
On Fri, 26 Oct 2007 17:47:58 -0400
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > That was a goofup. I proposed that we should add a #define
> > TWO_ARG_IRQ_HANDLERS (or whatever) and I think I actually wrote the
> > patch, but it got lost.
> >
> > I agree it would be a kind t
> often I get "CIFS VFS: server not responding".
> together with "CIFS VFS: No response for cmd 50 mid xxx" The xxx number
> seems to vary. The problem seems to be triggered by any operation
> which touches lots of files quickly. E.g.
> by copying source file directories onto or from it or simpl
David Miller <[EMAIL PROTECTED]> writes:
> From: Rick Jones <[EMAIL PROTECTED]>
> Date: Fri, 26 Oct 2007 16:31:47 -0700
>
>> Eric W. Biederman wrote:
>> > Adrian Bunk <[EMAIL PROTECTED]> writes:
>> >
>> >
>> >>This patch fixes the following build error with CONFIG_SYSCTL=n:
>> >>
>> >><-- snip
401 - 500 of 558 matches
Mail list logo
