Trond Myklebust <[EMAIL PROTECTED]> writes:
> On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
>> From: Eric W. Biederman <[EMAIL PROTECTED]>
>>
>> Start the reclaimer thread using kthread_run instead
>> of a combination of kernel_thread and daemonize.
>> The small amount of signal
> Index: linux-2.6/fs/buffer.c
> ===
> --- linux-2.6.orig/fs/buffer.c2007-04-19 19:59:26.0 +0200
> +++ linux-2.6/fs/buffer.c 2007-04-19 20:35:39.0 +0200
> @@ -733,7 +733,7 @@ int
On Thu, 2007-04-19 at 21:20 +0200, Miklos Szeredi wrote:
> > Index: linux-2.6/fs/buffer.c
> > ===
> > --- linux-2.6.orig/fs/buffer.c 2007-04-19 19:59:26.0 +0200
> > +++ linux-2.6/fs/buffer.c 2007-04-19
On 4/19/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
The one fly in the ointment for
linux remains X. I am still, to this moment, completely and utterly stunned
at why everyone is trying to find increasingly complex unique ways to manage
X when all it needs is more cpu[1].
[...and hence should be
What is the easiest way to completely undo a pull, reverting the branch
to the HEAD present before the pull?
If the pull doesn't merge successfully then usually doing a `git-reset
--hard` will blow everything away back to normal, but Linus may do
different things.
- David Brown
-
To
Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: rework the code for selecting the best DMA transfer mode
Depends on the "ide: fix UDMA/MWDMA/SWDMA masks" patch.
I'm now trying to rewrite hpt366.c to benefit more from these patches...
and alas, this very patch seems to be breaking
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/Kconfig |1 +
drivers/net/cxgb3/cxgb3_defs.h|5 +-
drivers/net/cxgb3/cxgb3_offload.c | 69
On Thu, 19 Apr 2007 21:00:55 +0200
Wim Van Sebroeck <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> > > On Tue, 17 Apr 2007 20:58:49 +0200 Wim Van Sebroeck <[EMAIL PROTECTED]>
> > > wrote:
> > > Would anyone object if we would merge the "full bells and whistles"
> > > drivers for
> > > the pcwd
David Brown wrote:
What is the easiest way to completely undo a pull, reverting the branch
to the HEAD present before the pull?
If the pull doesn't merge successfully then usually doing a `git-reset
--hard` will blow everything away back to normal, but Linus may do
different things.
I'm
Sergei Shtylyov wrote:
Hello.
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: rework the code for selecting the best DMA transfer mode
Depends on the "ide: fix UDMA/MWDMA/SWDMA masks" patch.
I'm now trying to rewrite hpt366.c to benefit more from these patches...
and alas, this very
On Thu, Apr 19, 2007 at 03:34:01PM -0400, Jeff Garzik wrote:
> David Brown wrote:
> >>What is the easiest way to completely undo a pull, reverting the branch
> >>to the HEAD present before the pull?
> >>
> >
> >If the pull doesn't merge successfully then usually doing a `git-reset
> >--hard` will
Matt Mackall wrote:
> I think adding a flags field and an allocate flag to my callback
> struct would be sufficient here.
>
Yes, probably.
What about something that wants to shatter superpages?
> The syntax is horrible, but I don't think we end up using the
> resultant type enough to justify
Hello, I wrote:
Bartlomiej Zolnierkiewicz wrote:
[PATCH] ide: rework the code for selecting the best DMA transfer mode
Depends on the "ide: fix UDMA/MWDMA/SWDMA masks" patch.
I'm now trying to rewrite hpt366.c to benefit more from these
patches...
and alas, this very patch seems to be
On Thu, Apr 19, 2007 at 12:09:42PM -0400, Trond Myklebust wrote:
> See
>http://client.linux-nfs.org/Linux-2.6.x/2.6.21-rc7/
>
> I'm giving the first 5 patches of that series (i.e.
> linux-2.6.21-001-cleanup_unstable_write.dif to
> linux-2.6.21-005-fix_nfsv4_resend.dif) an extra beating since
Hi Takashi,
Takashi Iwai napisał(a):
> At Mon, 16 Apr 2007 17:44:57 -0400,
> Chuck Ebbert wrote:
>> Adrian Bunk wrote:
>>
>>> This email lists some known regressions in Linus' tree compared to 2.6.20.
>>>
>>> Subject: snd_intel8x0: divide error:
>>> References :
From: Paul Mackerras <[EMAIL PROTECTED]>
Date: Sun, 15 Apr 2007 11:05:53 +1000
> I wrote:
>
> > So this doesn't change process_input_packet(), which treats the case
> > where the first byte is 0xff (PPP_ALLSTATIONS) but the second byte is
> > 0x03 (PPP_UI) as indicating a packet with a PPP
From: Andi Kleen <[EMAIL PROTECTED]>
Date: Thu, 19 Apr 2007 13:54:52 +0200
> So I'm planning to drop the option and arch/x86_64/kernel/functionlist
Please do so, I'm tired of editing that file every time I remove
something from the tree.
That file had alloc_skb_from_cache() in it, which nothing
On Thu, Apr 19, 2007 at 12:12:29PM -0700, Dave Hansen wrote:
> On Fri, 2007-04-06 at 17:03 -0500, Matt Mackall wrote:
> >
> > +static int pagemap_pte_range(pmd_t *pmd, unsigned long addr, unsigned
> > long end,
> > +void *private)
> > +{
> > + struct pagemapread
On Thu, Apr 19, 2007 at 12:44:57PM -0700, Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
> > I think adding a flags field and an allocate flag to my callback
> > struct would be sufficient here.
> >
>
> Yes, probably.
>
> What about something that wants to shatter superpages?
Haven't
I am testing a Gigabyte 965P-S3 motherboard with onboard Marvell
88E8056 Ethernet controller (sky2 driver). The CPU is a Core-2 Duo.
Strange errors occur under moderate load with X86-64 kernel.
Surprisingly, with i386 kernel the controller runs fine without errors.
These look bus/PCI related
From: David Howells <[EMAIL PROTECTED]>
Date: Thu, 19 Apr 2007 15:18:23 +0100
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > What is the ETA on your patches?
>
> That depends on Dave Miller now, I think. I'm assuming they need to go
> through the network GIT tree to get to Linus.
On Thu, Apr 19, 2007 at 12:06:38PM -0700, Dave Hansen wrote:
> On Fri, 2007-04-06 at 17:03 -0500, Matt Mackall wrote:
> >
> > +static ssize_t kpagemap_read(struct file *file, char __user *buf,
> > +size_t count, loff_t *ppos)
> > +{
> ...
> > + for (; i <
Stephen Smalley wrote:
>Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
>Vol 16 No 10) means information flow control, which you have agreed
>AppArmor does not and cannot provide.
Right, that's how I understand it, too.
However, I think some more caveats are in order. In
On Thu, 19 Apr 2007, Bernd Eckenfels wrote:
> In article <[EMAIL PROTECTED]> you wrote:
> > Perhaps -- until your httpd is compromised via a buffer overflow or
> > simply misbehaves due to a software or configuration flaw, then the
> > assumptions being made about its use of pathnames and their
On Thu, 2007-04-19 at 15:02 -0500, Matt Mackall wrote:
> On Thu, Apr 19, 2007 at 12:06:38PM -0700, Dave Hansen wrote:
> > On Fri, 2007-04-06 at 17:03 -0500, Matt Mackall wrote:
> > >
> > > +static ssize_t kpagemap_read(struct file *file, char __user *buf,
> > > +size_t
On Thu, 19 Apr 2007, Jeff Garzik wrote:
>
> What is the easiest way to completely undo a pull, reverting the branch to the
> HEAD present before the pull?
You can either do
git reset --hard ORIG_HEAD
(git will set ORIG_HEAD before things like pulls or resets, so you can
always go
On Thursday 19 April 2007, Ingo Molnar wrote:
> * Christian Hesse <[EMAIL PROTECTED]> wrote:
> > I now got some error message from my system:
> >
> > http://www.eworm.de/tmp/cfs-suspend.jpg
>
> ah, this pinpoints a bug: for performance reasons pick_next_task()
> assumes that the runqueue is not
Jeremy Fitzhardinge wrote:
> head.S creates the very initial pagetable for the kernel. This just
> maps enough space for the kernel itself, and an allocation bitmap.
> The amount of mapped memory is rounded up to 4Mbytes, and so this
> typically ends up mapping 8Mbytes of memory.
>
> When
>
> Is some version of this going in for 2.6.21, or is it not a real problem?
When it's only seen with Xen it's not a real problem right now.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi,
The device is present in many notebooks. Notebooks depend heavily on
suspend/resume functionality. tifm_core/7xx1/sd family is an ambitous,
but uncompleted project. It used to crash on resuming, or hang up on
suspending. A less common failure used to be trigerred by a fast card
Crispin Cowan wrote:
> How is it that you think a buffer overflow in httpd could allow an
> attacker to break out of an AppArmor profile?
James Morris wrote:
> [...] you can change the behavior of the application and then bypass
> policy entirely by utilizing any mechanism other than direct
Andi Kleen wrote:
Is some version of this going in for 2.6.21, or is it not a real problem?
When it's only seen with Xen it's not a real problem right now.
It's not just seen only with Xen, though. It will affect all kernels in
a particular range of sizes, and we have ordinary kernels
On Thu, Apr 19, 2007 at 08:54:13AM +0200, Jean Delvare wrote:
> The major difference is that the implementation in scx200_i2c is
> hardware-specific, while the i2c-gpio driver is a generic one, so it's
> a lot better.
>
> What this means is that i2c-gpio obsoletes scx200_i2c, so I am inclined
>
Stephen Smalley wrote:
>Integrity protection requires information flow control; you can't
>protect a high integrity process from being corrupted by a low integrity
>process if you don't control the flow of information. Plenty of attacks
>take the form of a untrusted process injecting data that
On Thu, 2007-04-19 at 20:08 +, David Wagner wrote:
> Stephen Smalley wrote:
> >Confinement in its traditional sense (e.g. the 1973 Lampson paper, ACM
> >Vol 16 No 10) means information flow control, which you have agreed
> >AppArmor does not and cannot provide.
>
> Right, that's how I
On Thursday 19 April 2007 22:55:50 H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> Is some version of this going in for 2.6.21, or is it not a real problem?
> >
> > When it's only seen with Xen it's not a real problem right now.
>
> It's not just seen only with Xen, though. It will affect all
I have a rackmount server that has a dual port onboard 82546EB card.
I've googled and seen this card apparently active with other users but
I seem to only get checksum errors.
[0.194129] Intel(R) PRO/1000 Network Driver - version 7.3.15-k2-NAPI
[0.194234] Copyright (c) 1999-2006 Intel
On Thu, 19 Apr 2007, Stephen Smalley wrote:
> Lastly, if you want to judge AA as a jail mechanism, I think you'll find
> it fails there too. So where does that leave it? An easy-to-use yet
> inadequate solution for MAC or jail.
It's not easy to use.
--
James Morris
<[EMAIL PROTECTED]>
-
To
Andi Kleen wrote:
On Thursday 19 April 2007 22:55:50 H. Peter Anvin wrote:
Andi Kleen wrote:
Is some version of this going in for 2.6.21, or is it not a real problem?
When it's only seen with Xen it's not a real problem right now.
It's not just seen only with Xen, though. It will affect all
use mutex instead of binary semaphore in
drivers/base/attribute_container.c
Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]>
--
diff --git a/drivers/base/attribute_container.c
b/drivers/base/attribute_container.c
index 073..1ec0654 100644
--- a/drivers/base/attribute_container.c
+++
Restore MADV_DONTNEED to its original Linux behaviour. This is still
not the same behaviour as POSIX, but applications may be depending on
the Linux behaviour already. Besides, glibc catches POSIX_MADV_DONTNEED
and makes sure nothing is done...
Signed-off-by: Rik van Riel <[EMAIL PROTECTED]>
On Thu, 2007-04-19 at 20:54 +, David Wagner wrote:
> Stephen Smalley wrote:
> >Integrity protection requires information flow control; you can't
> >protect a high integrity process from being corrupted by a low integrity
> >process if you don't control the flow of information. Plenty of
On Thu, 2007-04-19 at 13:20 -0600, Eric W. Biederman wrote:
> Trond Myklebust <[EMAIL PROTECTED]> writes:
>
> > On Thu, 2007-04-19 at 01:58 -0600, Eric W. Biederman wrote:
> >> From: Eric W. Biederman <[EMAIL PROTECTED]>
> >>
> >> Start the reclaimer thread using kthread_run instead
> >> of a
Hi,
If i enable "High Resolution Timer Support", my machine stops here at boot:
Clocksource tsc unstable (delta = -297340790165 ns)
Time: hpet clocksource has been installed.
If i disable HPET, it boots fine.
I attach my .config (with hpet enable) and my bootable dmesg.
Thanks.
--
Guilherme
H. Peter Anvin wrote:
> Andi Kleen wrote:
>> On Thursday 19 April 2007 22:55:50 H. Peter Anvin wrote:
>>> Andi Kleen wrote:
> Is some version of this going in for 2.6.21, or is it not a real
> problem?
When it's only seen with Xen it's not a real problem right now.
>>> It's not just
On Thu, 2007-04-19 at 17:19 -0400, Trond Myklebust wrote:
> > With pid namespaces all kernel threads will disappear so how do
> > we cope with the problem when the sysadmin can not see the kernel
> > threads?
Do they actually always disappear, or do we keep them in the
init_pid_namespace?
--
On Thu, 2007-04-19 at 14:58 -0500, Florin Iucha wrote:
> On Thu, Apr 19, 2007 at 12:09:42PM -0400, Trond Myklebust wrote:
> > See
> >http://client.linux-nfs.org/Linux-2.6.x/2.6.21-rc7/
> >
> > I'm giving the first 5 patches of that series (i.e.
> > linux-2.6.21-001-cleanup_unstable_write.dif
On Thu, 19 Apr 2007 17:34:19 +0530
Gautham R Shenoy <[EMAIL PROTECTED]> wrote:
> Threads which wait for completion on a frozen thread might result in
> causing the freezer to fail, if the waiting thread is freezeable.
>
> There are some well known cases where it's preferable to temporarily thaw
On 4/19/07, Gene Heskett <[EMAIL PROTECTED]> wrote:
Having tried re-nicing X a while back, and having the rest of the system
suffer in quite obvious ways for even 1 + or - from its default felt pretty
bad from this users perspective.
It is my considered opinion (yeah I know, I'm just a leaf in
Chuck Ebbert wrote:
> H. Peter Anvin wrote:
>
>> Andi Kleen wrote:
>>
>>> Then we would have seen reports surely?
>>>
Yes, I would have thought so. It surprised me that such an obvious bug
could be there, apparently for a long time. But it's real, and
potentially affects
Matt Mackall wrote:
> Haven't thought a huge amount about that. Perhaps it's best done with
> the level 3 callback?
>
Level 2, I think, assuming you count the pte pages as level 1. I think
it can be dealt with, so long as it correctly skips level 1 callbacks
for superpages, and does the test
On Thu, 19 Apr 2007 17:19:24 -0400
Trond Myklebust <[EMAIL PROTECTED]> wrote:
> > Regardless kernel threads should be an implementation detail
> > not a part of the user interface. If kernel threads are part
> > of the user interface it makes them very hard to change.
> >
> > So it isn't that
On Thu, Apr 19, 2007 at 02:37:53PM -0700, Jeremy Fitzhardinge wrote:
> Matt Mackall wrote:
> > Haven't thought a huge amount about that. Perhaps it's best done with
> > the level 3 callback?
> >
>
> Level 2, I think, assuming you count the pte pages as level 1. I think
> it can be dealt with,
On Thu, Apr 19, 2007 at 05:30:42PM -0400, Trond Myklebust wrote:
> > I'm far from the machine right now, so I will do some more tests
> > tonight, but right now, the new patchset is not good. What is the
> > difference between reverting the patch you sent yesterday and your
> > current fifth
On Tue, 17 Apr 2007, Nagendra Singh Tomar wrote:
> The return value of lookup_one_len() is used without testing for error
> return.
> This results in the following oops when SELinux is enabled and enforced. The
> reason for the Oops is as follows.
> The shell's (bash) SELinux domain is
Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham:
> Mauro Carvalho Chehab wrote:
> > Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu:
> >> Marco Gittler wrote:
> >>> this patch has applied the hints from mkrufky (dvb_attach,
> >>> firmware-naming)
> >>> and also one working
On Thu, 2007-04-19 at 14:40 -0700, Andrew Morton wrote:
> Using signals to communicate with kernel threads is fairly unpleasant, IMO.
> We have much simpler, faster and more idiomatic ways of communicating
> between threads in-kernel and there are better ways in which userspace can
> communicate
please copy netdev, or better yet [EMAIL PROTECTED] in
the future for e1000 issues like this. Feel free to move the
conversation there, if you would like.
On 4/19/07, David Ford <[EMAIL PROTECTED]> wrote:
I have a rackmount server that has a dual port onboard 82546EB card.
I've googled and
On Thu, 19 Apr 2007 13:13:22 -0600
[EMAIL PROTECTED] (Eric W. Biederman) wrote:
> Christoph Hellwig <[EMAIL PROTECTED]> writes:
>
> > On Thu, Apr 19, 2007 at 12:55:28AM -0600, Eric W. Biederman wrote:
> >> From: Eric W. Biederman <[EMAIL PROTECTED]> - unquoted
> >>
> >> thread_run is used
Hi,
On Thursday, 19 April 2007 14:02, Gautham R Shenoy wrote:
> This patch fixes the race pointed out by Oleg Nesterov.
>
> * Freezer marks a thread as freezeable.
> * The thread now marks itself PF_NOFREEZE causing it to
> freeze on calling try_to_freeze(). Thus the task is frozen, even
Matt Mackall wrote:
> I was counting from the top down.
>
Bottom-up is better; that way the levels don't change for 2,3,4 level
pagetables.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Thu, 19 Apr 2007 01:59:04 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> This patch is a minimal transformation to use the kthread API
> doing it's best to preserve the existing logic.
>
> Instead of starting kdvb-ca by calling kernel_thread,
> daemonize and sigfillset we kthread_run
On Thu, 19 Apr 2007, Dmitry Torokhov wrote:
> On 4/19/07, Alan Stern <[EMAIL PROTECTED]> wrote:
> > On Wed, 18 Apr 2007, Dmitry Torokhov wrote:
> >
> > > I am still do not understand why this is needed. Would it not be
> > > simplier just to use a reference to struct device instead of embedding
>
Hi !
I think this one is damn interestig for linux kernel development:
link: http://stackframe.blogspot.com/
contents: see below
regards
roland
ps:
i`m not directly related to vmware - so this is no advertisement!
Tuesday, April 17, 2007
Debugging Linux kernels with Workstation 6.0
We just
On Thu, Apr 19, 2007 at 09:35:04AM -0700, Christoph Lameter wrote:
> Variable Order Page Cache Patchset
>
> This patchset modifies the core VM so that higher order page cache pages
> become possible. The higher order page cache pages are compound pages
> and can be handled in the same way as
hermann pitton wrote:
> Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham:
>> Mauro Carvalho Chehab wrote:
>>> Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu:
Marco Gittler wrote:
> this patch has applied the hints from mkrufky (dvb_attach,
> firmware-naming)
Hello all,
Building the fglrx module against the current Linux kernel (2.6.20.7 as
of this e-mail) I'm getting an error:
FATAL: modpost: GPL-incompatible module fglrx.ko uses GPL-only symbol
'paravirt_ops'
which looks like someone (ATI?) might be doing something funny. I'm
just curious
On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
hermann pitton wrote:
> Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham:
>> Mauro Carvalho Chehab wrote:
>>> Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu:
Marco Gittler wrote:
> this patch has applied the
On Thu, 19 Apr 2007 01:59:03 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
> ---
> fs/smbfs/smbiod.c |2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git
On Friday 20 April 2007 04:16, Gene Heskett wrote:
> On Thursday 19 April 2007, Con Kolivas wrote:
>
> [and I snipped a good overview]
>
> >So yes go ahead and think up great ideas for other ways of metering out
> > cpu bandwidth for different purposes, but for X, given the absurd
> > simplicity
On Thu, Apr 19, 2007 at 12:10:34PM -0700, Christoph Lameter wrote:
> Variable Order Page Cache: Add functions to establish sizes
>
> We use the macros PAGE_CACHE_SIZE PAGE_CACHE_SHIFT PAGE_CACHE_MASK
> and PAGE_CACHE_ALIGN in various places in the kernel. These are now
> the base page size but we
Markus Rechberger wrote:
> On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> hermann pitton wrote:
>> > Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham:
>> >> Mauro Carvalho Chehab wrote:
>> >>> Em Qui, 2007-04-19 às 16:41 -0400, Michael Krufky escreveu:
>> Marco Gittler
On Thu, 19 Apr 2007 01:58:58 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> It is my goal to replace all kernel code that handles signals
> from user space, calls kernel_thread or calls daemonize. All
> of which the kthread_api makes unncessary. Handling signals
> from user space is a
On Thursday 19 April 2007, Sergey Yanovich wrote:
> The device is present in many notebooks. Notebooks depend heavily on
> suspend/resume functionality. tifm_core/7xx1/sd family is an ambitous,
> but uncompleted project. It used to crash on resuming, or hang up on
> suspending. A less common
On Friday 20 April 2007 05:26, Ray Lee wrote:
> On 4/19/07, Con Kolivas <[EMAIL PROTECTED]> wrote:
> > The one fly in the ointment for
> > linux remains X. I am still, to this moment, completely and utterly
> > stunned at why everyone is trying to find increasingly complex unique
> > ways to
On 4/19/07, Chris Bergeron <[EMAIL PROTECTED]> wrote:
It just seemed like it might be interesting and I couldn't find anything
to shed light on the error itself in the mailing list logs, and I'm
curious at what's happening.
What's happening is that some kernel developers don't like Linus's
On Thu, 19 Apr 2007 18:04:36 +0900
Simon Horman <[EMAIL PROTECTED]> wrote:
> On Thu, Apr 19, 2007 at 01:58:57AM -0600, Eric W. Biederman wrote:
> > From: Eric W. Biederman <[EMAIL PROTECTED]>
> >
> > Modify startup of ipvs sync threads to use kthread_run
> > instead of a weird combination of
On Thu, 19 Apr 2007, Linus Torvalds wrote:
>
> You can either do
>
> git reset --hard ORIG_HEAD
> git reset --hard @{1}
Btw, on the same kind of subject: the whole "what was my previous HEAD"
issues are obviously also how you'd generally want to see what those
new patches were,
Matthew Wilcox wrote:
> On Thu, Apr 19, 2007 at 07:39:59PM +0300, Dan Aloni wrote:
>> On Thu, Apr 19, 2007 at 05:47:43PM +0200, Jan-Benedict Glaw wrote:
>>> Where's the user?
>> A privately maintained kernel driver.
>>
>> Do we _must_ have in-tree users? I'd consider the change for
completion's
On Thu, 19 Apr 2007 10:32:38 +0100
David Howells <[EMAIL PROTECTED]> wrote:
> Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
> > This patch modifies the startup of krxtimod, krxiod, and krxsecd
> > to use kthread_run instead of a combination of kernel_thread
> > and daemonize making the code
On Thursday, April 5, 2007 3:37 pm Adam Jackson wrote:
> So I'm attempting to do something fairly heinous (X server across
> five video cards), and I hit a fun bug in bridge range setup. See
> attached lspci and dmesg, but the short of it is I've got two VGA
> chips on one card behind a bridge,
On Thu, 19 Apr 2007 01:58:54 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> This patch starts krfcommd using kthread_run instead of a combination
> of kernel_thread and daemonize making the code slightly simpler
> and more maintainable.
Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham:
> Markus Rechberger wrote:
> > On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> >> hermann pitton wrote:
> >> > Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham:
> >> >> Mauro Carvalho Chehab wrote:
> >> >>> Em Qui,
hermann pitton wrote:
> Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham:
>> Markus Rechberger wrote:
>>> On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
hermann pitton wrote:
> Am Freitag, den 20.04.2007, 00:55 +0400 schrieb Manu Abraham:
>> Mauro Carvalho Chehab
On Thu, 19 Apr 2007 01:58:53 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> This patch starts up khidp using kthread_run instead
> of kernel_thread and daemonize, resulting is slightly
> simpler and more maintainable code.
argh, they're all like this :(
It's a shame your changelogs
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
upstream-linus
to receive the following updates:
drivers/ata/pata_sis.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
Alan Cox (1):
pata_sis: Fix oops on
On Thu, 19 Apr 2007 01:58:51 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> From: Eric W. Biederman <[EMAIL PROTECTED]>
>
> This patch starts kbenpd using kthread_run replacing
> a combination of kernel_thread and daemonize. Making
> the code a little simpler and more maintainable.
>
>
> What's happening is that some kernel developers don't like Linus's
> stance on binary-only drivers and are trying to circumvent the norms
> of software copyright law using EXPORT_SYMBOL_GPL.
The troll is back I see.
Why don't you give him some useful information instead
- Turn off the
On Thu, 19 Apr 2007 01:58:50 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> This patch modifies the startup of the media_bay_task
> to use kthread_run and not a combination of kernel_thread,
> deamonize and sigfillset.
>
> In addition since we now always want to ignore signals
> the
Am Freitag, den 20.04.2007, 03:19 +0400 schrieb Manu Abraham:
> hermann pitton wrote:
> > Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham:
> >> Markus Rechberger wrote:
> >>> On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
> hermann pitton wrote:
> > Am Freitag, den
On Thu, 19 Apr 2007 01:58:48 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> Start the g4fand using kthread_run not a combination
> of kernel_thread and deamonize. This makes the code
> a little simpler and more maintainable.
I had a bit of trouble reviewing this one because I was
hermann pitton wrote:
> Am Freitag, den 20.04.2007, 03:19 +0400 schrieb Manu Abraham:
>> hermann pitton wrote:
>>> Am Freitag, den 20.04.2007, 02:51 +0400 schrieb Manu Abraham:
Markus Rechberger wrote:
> On 4/20/07, Manu Abraham <[EMAIL PROTECTED]> wrote:
>> hermann pitton wrote:
On Thu, Apr 19, 2007 at 04:11:50PM -0700, Jesse Barnes wrote:
> On Thursday, April 5, 2007 3:37 pm Adam Jackson wrote:
> > So I'm attempting to do something fairly heinous (X server across
> > five video cards), and I hit a fun bug in bridge range setup. See
> > attached lspci and dmesg, but the
On Thu, 19 Apr 2007 01:58:45 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
> This patch modifies the startup of eehd to use kthread_run
> not a combination of kernel_thread and daemonize. Making
> the code slightly simpler and more maintainable.
>
You're making me look at a lot of
On Thu, 19 Apr 2007 01:58:44 -0600
"Eric W. Biederman" <[EMAIL PROTECTED]> wrote:
>
> This patch starts the xpc kernel threads using kthread_run
> not a combination of kernel_thread and daemonize. Resuling
> in slightly simpler and more maintainable code.
>
> Cc: Jes Sorensen <[EMAIL
Use d_path() instead of seq_path when generating /proc/mounts and
/proc/$id/mountstats, reuse the same buffer for all mounts, and filter out
disconnected paths.
This path has no net effect in itself because d_path() so far doesn't
distinguish sconnected and disconnected paths yet. The next patch
Change d_path() so that it will never return a path starting with '/' if
the path doesn't lead up to the chroot directory. Also ensure that the
path returned never is the empty string: this would only occur with a lazily
unmounted file system; return "." in that case instead.
Signed-off-by:
First, when __d_path() hits a lazily unmounted mount point, it tries to prepend
the name of the lazily unmounted dentry to the path name. It gets this wrong,
and also overwrites the slash that separates the name from the following
pathname component. This patch fixes that; if a process was in
In AppArmor, we are interested in pathnames relative to the namespace root.
This is the same as d_path() except for the root where the search ends. Add
a function for computing the namespace-relative path.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
Reviewed-by: John Johansen <[EMAIL
Remove some duplicate code in generating the contents of /proc/mounts and
/proc/$pid/mountstats.
Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
---
fs/proc/base.c | 45 +++--
1 file changed, 15 insertions(+), 30 deletions(-)
---
501 - 600 of 964 matches
Mail list logo
