Hi Every one,
I have got two questions regarding opening files within the Linux kernel. If
some body can help me, in sorting out this problem, i will be very thankful.
1) I have just a file path with me, an absolute path, but no dentry, no
inode, no vfsmount object, which function i can cal
On Fri, Apr 06, 2007 at 10:58:45PM -0700, [EMAIL PROTECTED] wrote:
> You know,... you cut out this bit:
>
> -
>
> > The following benchmarks are from
> >
> > http://linuxhelp.150m.com/resources/fs-benchmarks.htm or,
> > http://m.dom
Andrew Morton napsal(a):
> On Wed, 4 Apr 2007 23:45:38 +0200 (CEST) Jiri Slaby <[EMAIL PROTECTED]>
> wrote:
>
>> cyclades, remove volatiles
>
> The other changes seem uncontroversial, but this one has the potential
> to change runtime behaviour. And cyclades.c is a driver which some people
> a
Hi Ingo and all,
When I was examining the following program ...
1. There are a large amount of small jobs takes several msecs,
and the number of job increases constantly.
2. The process creates a thread or a process per job (I examined both
the thread model and the process model).
Just correcting some errors and typos.
Wouldn't want you to say that the linux kernel mailing list gave you
incorrect info.
COMPILING AND CONFIGURING A NEW KERNEL.
Download a recent kernel from http://www.kernel.org/
I will use the kernel linux-2.6.20.tar.bz2
You will have to change details o
At Sat, 07 Apr 2007 16:31:39 +0900,
Satoru Takeuchi wrote:
> Test programs(attached in the mail):
>
> - satprocess.c: Process model. It creates a child process and wait for it
>several times. Each child process exits immediately.
> - satthread.c: Thread model. It creates
David Brownell <[EMAIL PROTECTED]> writes:
> So in practical terms "\n \t" and "\n\t" are identical;
> although the former "should not" be used, it doesn't
> actually affect what CodingStyle is primarily trying to
> control (i.e. what the code looks like).
That's not what CodingStyle is trying to
* Linus Torvalds <[EMAIL PROTECTED]> wrote:
> In fact, I have a theory.. Your backtrace is:
>
> [] smp_apic_timer_interrupt+0x57/0x90
> [] retrigger_next_event+0x0/0xb0
> [] apic_timer_interrupt+0x28/0x30
> [] retrigger_next_event+0x0/0xb0
> [] __kfifo_put+0x8/0x90
> [] on_each_cpu+0x35/0
Inode number handling was incorrect in two ways.
1. sysfs uses the inode number allocated by new_inode() and never
hashes it. When reporting the inode number, it uses iunique() if
inode is inaccessible. This is incorrect because iunique() assumes
the inodes are hashed. This can cause d
Error handling in fs/sysfs/bin.c:write() was wrong because size_t
count is used to receive return value from flush_write() which is
negative on failure.
This patch updates write() such that int variable is used instead.
read() is updated the same way for consistency.
Signed-off-by: Tejun Heo <[EM
sysfs is now completely out of driver/module lifetime game. After
deletion, a sysfs node doesn't access anything outside sysfs proper,
so there's no reason to hold onto the attribute owners. Note that
often the wrong modules were accounted for as owners leading to
accessing removed modules.
This
Make sd->s_element a union of sysfs_elem_{dir|symlink|attr|bin_attr}
and rename it to s_elem. This is to achieve...
* some level of type checking : changing symlink to point to
sysfs_dirent instead of kobject is much safer and less painful now.
* easier / standardized dereferencing
* allow sysf
Currently there are four functions to create sysfs_dirent -
__sysfs_new_dirent(), sysfs_new_dirent(), __sysfs_make_dirent() and
sysfs_make_dirent(). Other than sysfs_make_dirent(), no function has
two users if calls to implement other functions are excluded.
This patch consolidates sysfs_dirent c
Implement bin_buffer which contains a mutex and pointer to PAGE_SIZE
buffer to properly synchronize accesses to per-openfile buffer and
prepare for immediate-kobj-disconnect.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
fs/sysfs/bin.c | 64 ++-
Add sysfs_dirent->s_parent. With this patch, each sd points to and
holds a reference to its parent. This allows walking sysfs tree
without referencing sd->s_dentry which can go away anytime if the user
doesn't control when it's deleted.
sd->s_parent is initialized and parent is referenced in
sys
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> [...] Soeren, can you confirm that you are using a !CONFIG_SMP kernel,
> and if yes, does the patch below fix the resume problem for you?
hm, you seem to have a CONFIG_SMP=y kernel. I dont immediately see where
we re-enable interrupts in the SMP case,
Opening a sysfs node references its associated kobject, so userland
can arbitrarily prolong lifetime of a kobject which complicates
lifetime rules in drivers. This patch makes the association between
kobject and sysfs immediately breakable.
Each sysfs_dirent representing a kobject has a rwsem. A
kobj->dentry can go away anytime unless the user controls when the
associated sysfs node is deleted. This patch implements
kobj_sysfs_assoc_lock which protects kobj->dentry. This will be used
to maintain kobj based API when converting sysfs to use sysfs_dirent
tree instead of dentry/kobject.
Not
Add s_name to sysfs_dirent. This is to further reduce dependency to
the associated dentry. Name is copied for directories and symlinks
but not for attributes.
Where possible, name dereferences are converted to use sd->s_name.
sysfs_symlink->link_name and sysfs_get_name() are unused now and
remov
Flatten cleanup paths in sysfs_add_link() and create_dir() to improve
readability and ease further changes to these functions. This is in
preparation of object reference simplification.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
fs/sysfs/dir.c | 73 ++-
There is no reason these functions should be inlined and soon to
follow sysfs object reference simplification will make these functions
heavier. Move them to dir.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
fs/sysfs/dir.c | 30 ++
fs/sysfs/sysfs.h | 32 ++
Hello, all.
This patchset is result of the following thread.
http://thread.gmane.org/gmane.linux.kernel/510293
This patchset takes sysfs out of device driver lifetime equation which
not not only fixes several race conditions caused by sysfs not holding
onto the proper module when referencing k
Now that sysfs_dirent can be disconnected from kobject on deletion,
there is no need to orphan each attribute files. All [bin_]attribute
nodes are automatically orphaned when the parent node is deleted.
Kill attribute file orphaning.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
fs/sysfs/file
sysfs symlink is implemented by referencing dentry and kobject from
sysfs_dirent - symlink entry references kobject, dentry is used to
walk the tree. This complicates object lifetimes rules and is
dangerous - for example, there is no way to tell to which module the
target of a symlink belongs and
Hello, Maneesh.
Maneesh Soni wrote:
> o sysfs_d_iput() is invoked in dentry reclaim path under memory pressure. This
> happens without i_mutex. It also nullifies s_dentry to indicate that
> the associated dentry is evicted. sysfs_readdir() accesses the s_dentry,
> and gets the inode number f
Benjamin Herrenschmidt wrote:
> This is an old problem. The proper fix is already implemented for
> arch/powerpc and consist of having virtual irq numbers (which helps for
> many other things anyway).
>
> Support for 4xx platforms in arch/powerpc is starting to get in, pop on
> [EMAIL PROTECTED]
Hi all
Updates on this take4 :
- All remarks from Nick were addressed I hope
- Current mm code have a problem with 64bit futexes, as spoted by Nick :
get_futex_key() does a check against sizeof(u32) regardless of futex being
64bits or not.
So it is possible a 64bit futex spans two pages of mem
On Sat, 2007-04-07 at 10:25 +0200, Ingo Molnar wrote:
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > [...] Soeren, can you confirm that you are using a !CONFIG_SMP kernel,
> > and if yes, does the patch below fix the resume problem for you?
>
> hm, you seem to have a CONFIG_SMP=y kernel. I don
Hi all,
This looks like a lockdep problem.
2.6.21-rc6
+ hrtimers_debug.patch (from Ingo)
- skge_wol_support (commit a504e64ab42bcc27074ea37405d06833ed6e0820) dropped
due to
swsusp problems
[14016.726946] BUG: at /mnt/md0/devel/linux-git/kernel/lockdep.c:2427
check_flags()
[14016.734331] [] sho
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-04-07 at 10:25 +0200, Ingo Molnar wrote:
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > [...] Soeren, can you confirm that you are using a !CONFIG_SMP kernel,
> > > and if yes, does the patch below fix the resume problem for yo
On Sat, 2007-04-07 at 10:12 +0200, Ingo Molnar wrote:
> Subject: [patch] high-res timers: UP resume fix
> From: Ingo Molnar <[EMAIL PROTECTED]>
>
> Soeren Sonnenburg reported that upon resume he is getting
> this backtrace:
>
> [] smp_apic_timer_interrupt+0x57/0x90
> [] retrigger_next_event+0x0
On Fri, 06 Apr 2007 15:41:54 -0700 Jeremy Fitzhardinge <[EMAIL PROTECTED]>
wrote:
> identify_cpu() is used to identify both the boot CPU and secondary
> CPUs, but it performs some actions which only apply to the boot CPU.
> Those functions are therefore really __init functions, but because
> they
On 07/04/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Wed, 4 Apr 2007 22:05:40 +0200 "Dmitry Adamushko"
> [...]
>
> o Make TASK_PREEMPTS_CURR(task, rq) return "true" only if the task's
> prio is higher than the current's one and the task is in the "active"
> array.
> This ensures we don't mak
* Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> following the conversation on "a redundant reschedule call in
> set_user_prio()", here is a possible approach.
>
> The patch is somewhat intrusive as it even dares to adapt
> TASK_PREEMPTS_CURR().
looks good to me, but the patch seems seriously
Hi!
On 7 Apr 2007, at 08:58, JanuGerman wrote:
1) I have just a file path with me, an absolute path, but no
dentry, no inode, no vfsmount object, which function i can call to
get a "file" object associated with the absoulte file path. I have
surfed arround the source code especially fs/o
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> so
>
> - your code only gets publically tested in its against-staircase
> version
>
> - the against-mainline version will get merged without having been
> publically tested outside of staircase
>
> which is probably all OK for a 2.6.22-rc1 thin
On Fri, Apr 06, 2007 at 12:43:03PM -0700, H. Peter Anvin wrote:
Hi,
> I strongly disagree. First of all, you're changing the semantics of a
> 13-year-old API. The semantics of the Linux console is that by
> specifying U+FFFD SUBSTITUTION GLYPH in your unicode table, you have
> specified the
On Saturday, 7 April 2007 00:20, Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2007-04-06 at 16:34 +0200, Rafael J. Wysocki wrote:
> > On Monday, 2 April 2007 22:51, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > > +/* Per process freezer specific flags */
> > > > > > +#define PF_FE_SUSPEND 0x000
Eric Dumazet wrote:
Hi all
Updates on this take4 :
- All remarks from Nick were addressed I hope
Yeah looks very nice. Thanks for doing that.
- Current mm code have a problem with 64bit futexes, as spoted by Nick :
get_futex_key() does a check against sizeof(u32) regardless of futex being
Hi,
from the function fs/udf/inode.c:udf_fill_inode -
...
UDF_I_DATA(inode) = kmalloc(inode->i_sb->s_blocksize - sizeof(struct
extendedFileEntry), GFP_KERNEL);
memcpy(UDF_I_DATA(inode), bh->b_data + sizeof(struct
extendedFileEntry), inode->i_sb->s_blocksize - sizeof(str
On Saturday, 7 April 2007 10:48, Thomas Gleixner wrote:
> On Sat, 2007-04-07 at 10:25 +0200, Ingo Molnar wrote:
> > * Ingo Molnar <[EMAIL PROTECTED]> wrote:
> >
> > > [...] Soeren, can you confirm that you are using a !CONFIG_SMP kernel,
> > > and if yes, does the patch below fix the resume probl
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> > We do in on_each_cpu() unconditionally. I missed that.
>
> BTW, the on_each_cpu() in clock_was_set() is unnecessary, because
> timekeeping_resume() is always run on one CPU.
yes - but that's not the only place where we do clock_was_set(), and
Hi.
On Sat, 2007-04-07 at 11:33 +0200, Rafael J. Wysocki wrote:
> On Saturday, 7 April 2007 00:20, Nigel Cunningham wrote:
> > > > > > > - current->flags |= PF_NOFREEZE;
> > > > > > > + freezer_exempt(FE_ALL);
> > > > > > > pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
> > > > > > > if
find updated patch below - only the patch description changed: i removed
the 'UP' thing (patch has relevance on SMP too), and added Thomas' ack.
Ingo
>
Subject: [patch] high-res timers: resume fix
From: Ingo Molnar <[EMAIL PROTECTED]>
Soeren Sonnenburg repor
On Saturday, 7 April 2007 11:47, Ingo Molnar wrote:
>
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > We do in on_each_cpu() unconditionally. I missed that.
> >
> > BTW, the on_each_cpu() in clock_was_set() is unnecessary, because
> > timekeeping_resume() is always run on one CPU.
>
>
On Sat, 2007-04-07 at 11:47 +0200, Ingo Molnar wrote:
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > > We do in on_each_cpu() unconditionally. I missed that.
> >
> > BTW, the on_each_cpu() in clock_was_set() is unnecessary, because
> > timekeeping_resume() is always run on one CPU.
>
>
On Saturday, 7 April 2007 11:49, Ingo Molnar wrote:
>
> find updated patch below - only the patch description changed: i removed
> the 'UP' thing (patch has relevance on SMP too), and added Thomas' ack.
>
> Ingo
>
> >
> Subject: [patch] high-res timers: resume
This patch fixes two things in module_init.
- fix register_chrdev() error check
Currently dtlk doesn't check register_chrdev() failure correctly.
register_chrdev() returns a errno on failure.
- check probe failure
dtlk ignores probe failure and allows the module loading without
such dev
On Sat, 07 Apr 2007 19:30:14 +1000
Nick Piggin <[EMAIL PROTECTED]> wrote:
> Eric Dumazet wrote:
> >
> > - Current mm code have a problem with 64bit futexes, as spoted by Nick :
> >
> > get_futex_key() does a check against sizeof(u32) regardless of futex being
> > 64bits or not.
> > So it is p
* Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
> Hm, I'm probably missing something obvious, but where is it going to
> be called from?
doh! :) Find new patch below :-/ Soeren, please test this one.
Ingo
>
Subject: [patch] high-res timers: resume fix
From:
Hi,
I can confirm this fixes problem.
Please include into 2.6.21
Michal
Dne pátek 06 duben 2007 21:58 Markus Rechberger napsal(a):
> I committed a patch which fixes this issue:
>
> http://mcentral.de/hg/~mrec/v4l-dvb-stable/
>
> That problem got caused by releasing data structures which are stil
On Thu, 05 Apr 2007 14:03:16 -0700 Daniel Walker <[EMAIL PROTECTED]> wrote:
> Before this change the timekeeping code would poll the clocksource
> list every interrupt. This changes that so the clocksource list is
> only checked when there has been and update, and no longer checks
> in interrupt c
On Sat, 2007-04-07 at 12:05 +0200, Ingo Molnar wrote:
> * Rafael J. Wysocki <[EMAIL PROTECTED]> wrote:
>
> > Hm, I'm probably missing something obvious, but where is it going to
> > be called from?
>
> doh! :) Find new patch below :-/ Soeren, please test this one.
OK, I did about 5 suspend/resu
Hi,
I just wanted to give my opinion on things...
(and enable utf8 to read this properly)
On Apr 7 2007 11:24, Egmont Koblinger wrote:
>
>> I strongly disagree. First of all, you're changing the semantics of a
>> 13-year-old API. The semantics of the Linux console is that by
>> specifying U
On Apr 7 2007 06:58, JanuGerman wrote:
>Hi Every one,
>
> I have got two questions regarding opening files within the Linux
> kernel. If some body can help me, in sorting out this problem, i will
> be very thankful.
>
>1) I have just a file path with me, an absolute path, but no dentry,
>
On Sat, Apr 07, 2007 at 10:43:39AM +0200, Eric Dumazet wrote:
> get_futex_key() does a check against sizeof(u32) regardless of futex being
> 64bits or not.
> So it is possible a 64bit futex spans two pages of memory...
That would be a user bug. 32-bit futexes have to be 32-bit aligned, 64-bit
fu
#include
First, we (me and Thomas Schmidt) are working on a draft for a mandatory
locking scheme which will take care of the most racy situations even
without having a proper in-kernel solution. But you need to exlain some
things, otherwise we cannot rely on your words.
> (open has side effects
Willy Tarreau wrote:
>
> ... for some usages (temporary space),
> light compression can increase speed. For instance, when processing logs,
> I get better speed by compressing intermediate files with LZO on the fly.
How can you do that on ext3?
Also, can you do that on a partition block-io level?
When the number of conntracks is reached nf_conntrack_max limit, early_drop() is
called and tries to free one of already used conntracks in one of the hash
buckets. If it does not find any conntracks that may be freed, it
leads to transmission errors.
However it is not fair because of current hash
Jakub Jelinek a écrit :
On Sat, Apr 07, 2007 at 10:43:39AM +0200, Eric Dumazet wrote:
get_futex_key() does a check against sizeof(u32) regardless of futex being
64bits or not.
So it is possible a 64bit futex spans two pages of memory...
That would be a user bug. 32-bit futexes have to be 32-
Hi Al,
On Sat, Apr 07, 2007 at 02:32:34PM +0300, Al Boldi wrote:
> Willy Tarreau wrote:
> >
> > ... for some usages (temporary space),
> > light compression can increase speed. For instance, when processing logs,
> > I get better speed by compressing intermediate files with LZO on the fly.
>
> Ho
Vasily Averin a e'crit :
When the number of conntracks is reached nf_conntrack_max limit, early_drop() is
called and tries to free one of already used conntracks in one of the hash
buckets. If it does not find any conntracks that may be freed, it
leads to transmission errors.
However it is not fa
Hi,
i'm using 2.6.21-rc5-git9 +
http://www.kernel.org/pub/linux/kernel/people/agk/patches/2.6/editing/dm-merge-max_hw_sector.patch
( i've been testing with and without it, and first encountered it on
2.6.18-debian )
I've setup a raid1 array md1 (it was created in a degraded mode using
the debi
[EMAIL PROTECTED] napisał(a):
> The mm snapshot broken-out-2007-04-07-03-27.tar.gz has been uploaded to
>
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-04-07-03-27.tar.gz
>
> It contains the following patches against 2.6.21-rc6:
>
LTP triggered a ptrace problem.
Le 06.04.2007 00:42, Ignatich a écrit :
While trying to find the cause of problems with reiser4 in recent
kernels I came across this.
Incomplete write handling seem to be missing from reiser4_write_extent()
thanks to reiser4-temp-fix.patch. Strangely, there is a patch by Edward
Shishkin that
Hi Willy,...
> With decent CPU, you can reach higher read/write data rates than what a
> single off-the-shelf disk can achieve. For this reason, I think that
> reiser4 would be worth trying for this particular usage.
Glad to see you are willing to give Reiser4 a go.
Good man.
--
Jan does have a point about bad blocks. A couple years ago
I had a relatively new disk start to go bad on random blocks.
I detected it fairly quickly but did have some data loss.
All the compressed archives which were hit were near
total losses; most other files were at least partially
recoverable
[EMAIL PROTECTED] writes:
> Why do you think I hate reiserfs developers? That is an insane claim.
> Why would I hate reiser3 developers?
> Why would I hate reiser4 developers?
> Why would I even dislike them?
>
> I think Hans Reiser is a genius. Is that what you mean by hate?
I think they could
Krzysztof -- Aren't you missing the point? Twice the speed would be
great,... even a 50% increase,... even a 0% increase.
I checked what bonnie++ actually writes to its test files, for you. It
is about 98-99% zeros.
Still, the results record sequential reads, of 232,729 K/sec, nearly
four times
On Fri, Apr 06, 2007 at 05:53:25PM -0700, Randy Dunlap wrote:
> From: Jan Engelhardt <[EMAIL PROTECTED]>
>
> Unfortunately, kernel-doc has problems with a struct field like this:
> uint8_t databuf[NAND_MAX_PAGESIZE + NAND_MAX_OOBSIZE];
>
> simply due to the spaces around the "+" sign, so dr
Hi,
The nfs statfs function returns a success code on error, and fills the
output buffer with invalid values. The attached patch makes it return a
correct error code instead.
Thanks,
Amnon
Signed-off-by: Amnon Aaronsohn <[EMAIL PROTECTED]>
--
--- linux-source-2.6.20-2.6.20/fs/nfs/super.c.or
On Sat, 7 Apr 2007 13:59:14 +0100, "Dale Amon" <[EMAIL PROTECTED]> said:
> Jan does have a point about bad blocks. A couple years ago
> I had a relatively new disk start to go bad on random blocks.
> I detected it fairly quickly but did have some data loss.
>
> All the compressed archives which we
If I open a file with O_APPEND and write() to it, it looks like the
file offset is updated and I can get it with lseek(SEEK_CUR). Can I
trust that this behavior won't change in future Linux versions?
Apparently this isn't standard, because at least OS X and Solaris
don't do this.
pwrite()
On March 30, 2007, Tejun Heo wrote:
> Hello, all.
>
> This document tries to describe lifetime problems of the current
> device driver model primarily from the point view of device drivers
> and establish consensus, or at least, start discussion about how to
> solve these problems. This is prima
On 4/7/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
I checked what bonnie++ actually writes to its test files, for you. It
is about 98-99% zeros.
Still, the results record sequential reads, of 232,729 K/sec, nearly
four times the physical disk read rate, 63,160 K/sec, of the hard drive.
Ex
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make handle_initrd() call try_to_freeze() in a suitable place instead of setting
PF_NOFREEZE for the current task.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
init/do_mounts_initrd.c |5 +++--
1 file changed, 3 insertions(+), 2 deletio
On Saturday 07 April 2007, Con Kolivas wrote:
>On Friday 06 April 2007 20:03, Ingo Molnar wrote:
>> * Con Kolivas <[EMAIL PROTECTED]> wrote:
>[...]
>>
>> firstly, testing on various workloads Mike's tweaks work pretty well,
>> while SD still doesnt handle the high-load case all that well. Note
>>
On Fri, 06 Apr 2007 16:33:32 EDT, Bill Davidsen said:
> Jan Engelhardt wrote:
> > Who cares if the user specifies max_loop=8 but still is able to open up
> > /dev/loop8, loop9, etc.? max_loop=X basically meant (at least to me)
> > "have at least X" loops ready.
> >
> You have just come up with
On Sat, 2007-04-07 at 11:24 +0200, Ingo Molnar wrote:
> * Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Where are we at with staircase anyway? Is it looking like a 2.6.22
> > thing? I don't personally think we've yet seen enough serious
> > performance testing to permit a merge, apart from other
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Add static inline function get_sect_count to include/linux/genhd.h to
complement get_start_sect. Returns sector_t capacity of block device
whether it is whole or a partition.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
This wi
On Sat, 2007-04-07 at 16:50 +1000, Con Kolivas wrote:
> On Friday 06 April 2007 20:03, Ingo Molnar wrote:
> > (There was one person who
> > reported wide-scale interactivity regressions against mainline but he
> > didnt answer my followup posts to trace/debug the scenario.)
>
> That was one user
[EMAIL PROTECTED] wrote:
On Fri, 06 Apr 2007 16:33:32 EDT, Bill Davidsen said:
Jan Engelhardt wrote:
Who cares if the user specifies max_loop=8 but still is able to open up
/dev/loop8, loop9, etc.? max_loop=X basically meant (at least to me)
"have at least X" loops ready.
On 4/7/07, Eric Dumazet <[EMAIL PROTECTED]> wrote:
I am not sure what you want to say.
What Jakub meant is that it is OK for the kernel to reject using
unaligned 64-bit futexes. Just return an error in all cases (not just
in some).
-
To unsubscribe from this list: send the line "unsubscribe li
On Fri, 06 Apr 2007 18:26:45 PDT, [EMAIL PROTECTED] said:
>
> YOU SHOULD compile all the drivers necessary to boot your system, into
> the kernel (ie, such drivers should not be built as modules).
>
> This way you will NOT need an initrd file.
It is quite possible to build a kernel that has all t
On Fri, Apr 06, 2007 at 11:55:10PM -0700, Andrew Morton wrote:
> On Fri, 06 Apr 2007 17:03:13 -0500 Matt Mackall <[EMAIL PROTECTED]> wrote:
>
> > Add /proc/pid/pagemap interface
> >
> > This interface provides a mapping for each page in an address space to
> > its physical page frame number, allo
JanuGerman wrote:
Hi Every one,
I have got two questions regarding opening files within the Linux kernel. If
some body can help me, in sorting out this problem, i will be very thankful.
First off, likely not something you should be doing:
http://kernelnewbies.org/FAQ/WhyWritingFilesFromKer
On Sat, 07 Apr 2007 00:45:32 PDT, [EMAIL PROTECTED] said:
> Use rpm-pkg to create a Red Hat RPM kernel package.
> # make rpm-pkg
>
> When built, the RPM package is put in
> /usr/src/packages/RPMS/*your*architecture*
>
> # cd /usr/src/packages/RPMS/x86_64
>
> Install the package (you may have to
Thanks Jan for the response.
>struct dentry *fbar = lookup_one_len("/foo/bar", current->fs->root);
But that gives me a dentry, where as file object is still not reachable.
Question: I am currently using a function called fs.h/dentry_open which takes a
"dentry", "vfsmount" object and fla
In their closed chambers (well, workshops,
http://lwn.net/Articles/226351/), the filesystem developers complain
about readdir. I fully appreciate the difficulties. But what I fail
to see so far is any proposal for an alternative interface.
The phase to get new functionality included in the next
On Sat, 07 Apr 2007 16:11:46 +0200, Krzysztof Halasa said:
> > Think about it,... read speeds that are some FOUR times the physical
> > disk read rate,... impossible without the use of compression (or
> > something similar).
>
> It's really impossible with compression only unless you're writing
>
On Sat, 2007-04-07 at 18:20 +0200, Mike Galbraith wrote:
> xx.c
>
> #include
> #include
>
> #define max(a,b) ((a) > (b) ? (a) : (b))
> #define min(a,b) ((a) < (b) ? (a) : (b))
>
> int main(void)
> {
> struct timeval then, now;
> struct timespec t = {0, 1000}, r;
>
> for(;;) {
>
Andrew Morton wrote:
> x86_64 uses this too.
>
> WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to
> .init.text:mtrr_bp_init from .text.identify_cpu after 'identify_cpu' (at
> offset 0x655)
>
OK, two patches to follow: a x86-64 variant of the bugs.h cleanup, and a
replac
On Sat, 07 Apr 2007 16:11:46 +0200, Krzysztof Halasa said:
>
> Gzip - 3 files (zeros only, raw DV data from video camera, x86_64
> kernel rpm file), 10 MB of data (10*1024*1024),
> $ l -Ggh zeros dv bin
> -rw-r--r-- 1 10M Apr 7 15:30 bin
> -rw-r--r-- 1 10M Apr 7 15:31 dv
> -rw-r--r-- 1 10M Apr 7
Most of asm-x86_64/bugs.h is code which should be in a C file, so put it there.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Linus Torvalds <[EMAIL PROTECTED]>
---
arch/x86_64/kernel/Makefile |3 ++-
arch/x86_64/kernel/bugs.c| 2
identify_cpu() is used to identify both the boot CPU and secondary
CPUs, but it performs some actions which only apply to the boot CPU.
Those functions are therefore really __init functions, but because
they're called by identify_cpu(), they must be marked __cpuinit.
This patch splits identify_cpu
On Sat, Apr 07, 2007 at 01:00:48PM +0200, Jan Engelhardt wrote:
Hi,
> Please, no dot, and no inverse color.
> Imagine someone had the following bitmap for :
No dot, I'm already convinced. To clarify the inverse thingy:
This is what the current kernel does:
1) tries to display the desired symb
From: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
Adds help text for ACORN_PARTITION_EESOX and improves help text for
MSDOS_PARTITION in fs/partitions/Kconfig.
Signed-off-by: John Anthony Kazos Jr. <[EMAIL PROTECTED]>
---
Applied against Linux v2.6.20.6.
--- linux-2.6.20.6-orig/fs/partitions/K
On 4/6/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Fri, Apr 06, 2007 at 04:32:24PM -0700, [EMAIL PROTECTED] wrote:
> +static int attach_task(struct container *cont, struct task_struct *tsk)
> {
[snip]
> + task_lock(tsk);
You need to check here if task state is PF_EXITING and fail
On Fri, 06 Apr 2007 19:47:36 PDT, [EMAIL PROTECTED] said:
> On Fri, 6 Apr 2007 11:21:19 -0400, "Jan Harkes" <[EMAIL PROTECTED]>
> > With compression there is a pretty high probability that one corrupted
> > byte or disk block will result in loss of a considerably larger amount
> > of data.
>
> B
Hi lads,
I had some problems compiling the external netfilter modules due to
missing definitions.
I googled a lot, saw a lot of people having the same problems but no
real answer to how to fix it.
So.. I made a little patch which make things work for me, at least.
Modules that work after applyi
1 - 100 of 199 matches
Mail list logo
