On Sunday 28 October 2007 22:23:15 Rafael J. Wysocki wrote:
> On Sunday, 28 October 2007 21:00, Maxim Levitsky wrote:
> > On Saturday 27 October 2007 23:46:45 Rafael J. Wysocki wrote:
> > > On Saturday, 27 October 2007 14:05, Maxim Levitsky wrote:
> > > > Hi,
> > > >
> > > > Recently I noticed
The Abit Fatal1ty F-190HD motherboard has a Realtek rlt8169 gigabit
ethernet controller onboard. It shows up in lspci as:
02:00.0 Ethernet controller: Unknown device 0001:8168 (rev 01)
Subsystem: ABIT Computer Corp. Unknown device 2410
Flags: bus master, fast devsel, latency 0,
it saves some bytes memory
Signed-off-by: Vasily Averin <[EMAIL PROTECTED]>
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -110,12 +110,12 @@ struct target_type {
};
struct io_restrictions {
+ unsigned long seg_boundary_mask;
unsigned int
i2o crashed when CONFIG_DEBUG_SG is enabled because i2o_block_request structure
includes array of scatterlists that should be initialised
Signed-off-by: Vasily Averin <[EMAIL PROTECTED]>
--- a/drivers/message/i2o/i2o_block.c
+++ b/drivers/message/i2o/i2o_block.c
@@ -1137,6 +1137,18 @@ static
max_phys_segments and max_sectors were swapped
Signed-off-by: Vasily Averin <[EMAIL PROTECTED]>
--- a/drivers/message/i2o/i2o_block.c
+++ b/drivers/message/i2o/i2o_block.c
@@ -1076,8 +1076,8 @@ static int i2o_block_probe(struct device *dev)
blk_queue_max_sectors(queue, max_sectors);
Device mapper uses its own bounce_pfn that may differ from one on underlying
device. In that way dm can build incorrect requests that contain sg elements
greater than underlying device is able to handle.
This is the cause of slab corruption in i2o layer, occurred on i386 arch when
very long
Hi,
On 10/29/07, Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > We don't need preempt_enable for CONFIG_SMP, right?
>
> preempt_enable is needed if preemption is enabled.
Disabled? But yeah, I see that slab_trylock() can leave preemption
disabled if cmpxchg fails. Was confused by the
On Sun, 28 Oct 2007 21:34:58 -0700, H. Peter Anvin wrote:
> Mikael Pettersson wrote:
> > My old 486 fails to boot with the 2.6.24-rc1 kernel.
> > Grub loads it, 4 lines of text appear but not the kernel's
> > "Linux version greet", and the machine reboots.
> > Double-checked with a serial
On Sun, 28 Oct 2007 21:33:02 -0700, H. Peter Anvin wrote:
> Mikael Pettersson wrote:
> > My old 486 fails to boot with the 2.6.24-rc1 kernel.
> > Grub loads it, 4 lines of text appear but not the kernel's
> > "Linux version greet", and the machine reboots.
> > Double-checked with a serial
hrmph, CC to members only list removed.
On Mon, 2007-10-29 at 07:08 +0100, Mike Galbraith wrote:
> Greetings,
>
> I've stumbled across a 2.6.22->2.6.23 regression. First md5sum access
> of an empty NTFS file leads to kernel I/O error gripe, a second access
> leaves md5sum hung. 2.6.22.10 has
Shane Huang wrote:
>> I would like those to be removed, but to be conservative we should
>> first get some testing feedback that confirms this just like those
>> provided to me from the AMD folks for the RS690, RX790 and RD580
>> cases.
>>
>> Otherwise the risk to break people's systems is very
> -Original Message-
> From: Anton Vorontsov [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 27, 2007 10:38 PM
> To: Sergei Shtylyov
> Cc: Anton Vorontsov; [EMAIL PROTECTED]; Li Yang-r58472;
> linux-kernel@vger.kernel.org; [EMAIL PROTECTED]
> Subject: Re: [PATCH] ucc_geth: add
Jeff Garrett wrote:
> Several threads that suggest this message is related to poor NCQ
> support, but I did not see any for this drive. It's a Western Digital
> WD1500ADFD-00NLR1. Is this the same thing, and should this drive be
> blacklisted?
How reproducible is the problem?
--
tejun
-
To
Greetings,
I've stumbled across a 2.6.22->2.6.23 regression. First md5sum access
of an empty NTFS file leads to kernel I/O error gripe, a second access
leaves md5sum hung. 2.6.22.10 has no trouble accessing this file.
Looking at the 22->23 diff, I don't see a quick and dirty stab
candidate,
> I would like those to be removed, but to be conservative we should
> first get some testing feedback that confirms this just like those
> provided to me from the AMD folks for the RS690, RX790 and RD580
> cases.
>
> Otherwise the risk to break people's systems is very real.
In fact, our team
On 10/29/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> On Sunday 28 October 2007 16:39, Jiri Kosina wrote:
> > On Sun, 28 Oct 2007, Torsten Kaiser wrote:
> >
> > > But it looks like that uses another driver:
> > > hiddev0hidraw1: USB HID v1.10 Device [Western Digital External HDD] on
> > >
On Sun, Oct 28, 2007 at 01:03:36PM -0700, Greg KH wrote:
> On Sun, Oct 28, 2007 at 03:53:20PM -0400, Barak Fargoun wrote:
...
> > About your question: today, some of the hypervisors are using linux
> > kernel as their domain-0 (e.g. Xen). In order to implement direct
> > hardware access for these
Tobin Davis wrote:
> First think I noticed, why are you compiling all the drivers into the
> kernel instead of as modules? Do you need every sound device supported
> simultaneously?
>
> Tobin
>
> On Fri, 2007-10-26 at 22:45 +0530, Kamalesh Babulal wrote:
>> Takashi Iwai wrote:
>> > At Fri, 26
David wrote:
> If we can't identify any applications that would be broken by this, what's
> the difference in simply implementing Choice B and then, if we hear
> complaints, add your hack to revert back to Choice A behavior based on the
> get_mempolicy() call you specified is always part of
On Monday 29 October 2007 14:03:52 Matt Mackall wrote:
> And on SLOB, which doesn't have those bloaty power-of-2 constraints?
> Looks like ~500 reallocs, including 25 bytes of memcpy. Ouch!
In other words, the system was compiled for size optimization and that's
what happened.
The question
Change the hrtimer printk "Switched to high resolution mode .." to
be KERN_DEBUG, rather than KERN_INFO. If users need to see this they
can pass "loglevel" or "debug" on the command line, or check dmesg.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
Any objections? It gets a little
On Mon, 29 Oct 2007 00:02:02 -0500 Olof Johansson <[EMAIL PROTECTED]> wrote:
>
> I posted this one a few days ago, without adding a new ifdef (just moving the
> declaration down into the already existing ifdef below it):
>
> http://marc.info/?l=linux-kernel=119311699109698=2
Yeah, missed that
On Sat, Oct 27, 2007 at 04:19:14PM +0200, Adrian Bunk wrote:
> This patch fixes later NULL dereferences spotted by the Coverity
> checker.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
NACK... see below
> ---
>
> BTW: The avr32 and s390 versions of kprobe_exceptions_notify() are
>
From: Al Viro <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 05:03:23 +
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Sun, 28 Oct 2007 15:08:56 -0700
Crispin Cowan <[EMAIL PROTECTED]> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
>
initializing a field in data shared with the card with
cpu_to_le32(something) | 0x10 is broken - the field
is, indeed, little-endian and we need cpu_to_le32() on
both parts.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr_hba.c |2 +-
1 files changed, 1
doh...
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr_hba.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/arcmsr/arcmsr_hba.c b/drivers/scsi/arcmsr/arcmsr_hba.c
index acbc50f..d466a2d 100644
---
Use of ptrdiff_t in places like
- if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf, u_tmp->len))
+ if (!access_ok(VERIFY_WRITE, (u8 __user *)
+ (ptrdiff_t) u_tmp->rx_buf,
+
a) for type B we should _not_ iounmap() acb->pmu; it's not ioremapped.
b) for type B we should iounmap() two regions we _do_ ioremap.
c) if ioremap() fails, we need to bail out (and clean up).
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr.h |9 -
driver still has serious portability problems
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
drivers/scsi/arcmsr/arcmsr.h | 32 ---
drivers/scsi/arcmsr/arcmsr_attr.c |6 +-
drivers/scsi/arcmsr/arcmsr_hba.c | 170 ++---
3 files changed, 103
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
include/net/sctp/auth.h |2 +-
net/sctp/auth.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/net/sctp/auth.h b/include/net/sctp/auth.h
index 9e8f13b..5db261a 100644
--- a/include/net/sctp/auth.h
+++
On Mon, Oct 29, 2007 at 01:59:11PM +1100, Stephen Rothwell wrote:
> drivers/video/aty/radeon_pm.c:30: warning: 'radeon_reinitialize_M10' declared
> 'static' but never defined
>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
I posted this one a few days ago, without adding a new ifdef
* off by one in dmar_get_fault_reason() (maximal index in
array is ARRAY_SIZE()-1, not ARRAY_SIZE())
* NULL noise removal
* __iomem annotation fix
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/drivers/pci/intel-iommu.c b/drivers/pci/intel-iommu.c
index
From: Al Viro <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 04:37:58 +
> rpcrdma stuff lacks endianness annotations for on-the-wire data.
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe
On Sun, 28 Oct 2007, Paul Jackson wrote:
> And, unless someone in the know tells us otherwise, I have to assume
> that this could break them. Now, the odds are that they simply don't
> run that solution stack on any system making active use of cpusets,
> so the odds are this would be no problem
On Mon, Oct 29, 2007 at 02:24:30PM +1100, Stephen Rothwell wrote:
> On Sun, 28 Oct 2007 19:53:55 -0700 (PDT) Christoph Lameter <[EMAIL
> PROTECTED]> wrote:
> >
> > That was already fixed AFAICT.
>
> Not in Linus' tree, yet.
Nope, it's still sitting in -mm. Al Viro just posted the same fix too.
nr_slabs is atomic_long_t, not atomic_t
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/mm/slub.c b/mm/slub.c
index aac1dd3..bcdb2c8 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2734,7 +2734,7 @@ static void slab_mem_offline_callback(void *arg)
* and
rpcrdma stuff lacks endianness annotations for on-the-wire data.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/include/linux/sunrpc/rpc_rdma.h b/include/linux/sunrpc/rpc_rdma.h
index 0013a0d..87b895d 100644
--- a/include/linux/sunrpc/rpc_rdma.h
+++ b/include/linux/sunrpc/rpc_rdma.h
Mikael Pettersson wrote:
My old 486 fails to boot with the 2.6.24-rc1 kernel.
Grub loads it, 4 lines of text appear but not the kernel's
"Linux version greet", and the machine reboots.
Double-checked with a serial console: nothing appears
before it reboots.
All 2.6 kernels up to 2.6.23 worked
Mikael Pettersson wrote:
My old 486 fails to boot with the 2.6.24-rc1 kernel.
Grub loads it, 4 lines of text appear but not the kernel's
"Linux version greet", and the machine reboots.
Double-checked with a serial console: nothing appears
before it reboots.
What four lines of text?
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
index 8456397..59822de 100644
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -165,7 +165,7 @@ static void __init kmap_init(void)
kmap_prot = PAGE_KERNEL;
}
-static void
arch/i386/{Kconfig,Makefile}.cpu got moved
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
diff --git a/arch/um/Kconfig.i386 b/arch/um/Kconfig.i386
index 9876d80..e0ac74e 100644
--- a/arch/um/Kconfig.i386
+++ b/arch/um/Kconfig.i386
@@ -1,6 +1,6 @@
menu "Host processor type and features"
-source
Don't undef __i386__/__x86_64__ in uml anymore, make sure that (few) places
that required adjusting the ifdefs got those.
Signed-off-by: Al Viro <[EMAIL PROTECTED]>
---
arch/um/Makefile-i386 |3 +--
arch/um/Makefile-x86_64 |5 +
drivers/char/mem.c|4 ++--
> Nobody can show an example of an application that would be broken because
> of this and, given the scenario and sequence of events that it requires to
> be broken when implementing the default as Choice B, I don't think it's as
> much of an issue as you believe.
Well, neither you nor I have
This should already be in the cifs-2.6.git tree and next -mm (I am
waiting on the finish up of some CIFS ACL mapping code before
requesting another cifs merge with mainline)
http://git.kernel.org/?p=linux/kernel/git/sfrench/cifs-2.6.git;a=commitdiff;h=c94897790e7c67dcfe3a0b6f035996398c268313
On
On 10/1/07, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> Hi Dave,
>
> > The hci_sysfs uses work queue to finish the sysfs add/del fuction.
> > But when the same device connection failed, if another connection of
> > same device come in before the delete work finish, sysfs will warn
> > about
On Sun, 28 Oct 2007, Pekka J Enberg wrote:
> - local_irq_restore(flags);
> + object = do_slab_alloc(s, c, gfpflags, node, addr);
> + if (unlikely(!object))
> + goto out;
Undoing the optimization that one of the earlier patches added.
The #ifdef version is for me at least
On Sun, 28 Oct 2007 19:53:55 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]>
wrote:
>
> That was already fixed AFAICT.
Not in Linus' tree, yet.
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
pgpttYSDYSayZ.pgp
Description: PGP signature
On Sun, 2007-10-28 at 16:41 -0600, Matthew Wilcox wrote:
> On Sun, Oct 28, 2007 at 05:50:30PM -0400, Trond Myklebust wrote:
> > > You can't fix the false EDEADLK detection without solving the halting
> > > problem. Best of luck with that.
> >
> > I can see that it would be difficult to do
From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Mon, 29 Oct 2007 13:59:11 +1100
> drivers/video/aty/radeon_pm.c:30: warning: 'radeon_reinitialize_M10' declared
> 'static' but never defined
>
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
Acked-by: David S. Miller <[EMAIL PROTECTED]>
-
On Sat, Oct 27, 2007 at 08:09:30PM +1000, Rusty Russell wrote:
> On Saturday 27 October 2007 06:57:14 Matt Mackall wrote:
> > Well I expect once you start letting people easily build strings by
> > concatenation, you'll very shortly afterwards have people using them
> > in loops. And having
On Sun, 28 Oct 2007, Pekka J Enberg wrote:
> It would be easier to review the actual locking changes if you did the
> SlabXXX removal in a separate patch.
There are no locking changes.
> > -static __always_inline void slab_lock(struct page *page)
> > +static __always_inline void
On Sun, 28 Oct 2007, Pekka J Enberg wrote:
> Can you please write a comment of the locking rules when cmpxchg_local()
> is used? Looks as if we could push that local_irq_save() to slub_lock()
> and local_irq_restore() to slub_unlock() and deal with the unused flags
> variable for the
drivers/video/aty/radeon_pm.c:30: warning: 'radeon_reinitialize_M10' declared
'static' but never defined
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
drivers/video/aty/radeon_pm.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell
On 10/28/07, Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> While you're at it, it's probably worth splitting this out into
> a small helper function.
Why? Is the same pattern called from more than one place?
Regards,
Daniel
-
To unsubscribe from this list: send the line "unsubscribe
Hi Andrew,
Andrew Morton wrote:
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
Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
fs/cifs/cifssmb.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
diff --git a/fs/cifs/cifssmb.c b/fs/cifs/cifssmb.c
index f0d9a48..aa9dc9e 100644
---
On Mon, 29 Oct 2007, Stephen Rothwell wrote:
> so shouldn't be passed to atomic_read.
That was already fixed AFAICT.
-
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 Saturday 27 October 2007 9:09:47 am Matthew Garrett wrote:
> On Thu, Oct 25, 2007 at 09:06:22AM -0600, Bjorn Helgaas wrote:
> > But we really *should* reserve things used by opregions, shouldn't
> > we? After all, the whole point of resource reservation is to prevent
> > conflicts.
>
> Only if
On Sunday 28 October 2007 16:39, Jiri Kosina wrote:
> On Sun, 28 Oct 2007, Torsten Kaiser wrote:
>
> > But it looks like that uses another driver:
> > hiddev0hidraw1: USB HID v1.10 Device [Western Digital External HDD] on
> > usb-:00:02.1-5.2
> > Otherwise I would be willing to try to test
On Sun, 28 Oct 2007 20:40:56 -0400 Erez Zadok wrote:
> Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
> indicates that it is an internal function not to be exported to modules;
> therefore it should have a more traditional do_XXX name. The new do_ioctl
> is exported in
On Sun, Oct 28, 2007 at 11:38:26PM +, Alan Cox wrote:
> > > The spec and SYSV certainly ignore threading in this situation and you
> > > know that perfectly well (or did in 2004)
> >
> > The discussion petered out (or that mailing list archive lost articles
> > from the thread) without any
On Fri, 2007-10-26 at 13:23 +0200, Ingo Molnar wrote:
> * Zhang, Yanmin <[EMAIL PROTECTED]> wrote:
>
> > I tested 2.6.24-rc1 on my x86_64 machine which has 2 quad-core processors.
> >
> > Comparing with 2.6.23, aim7 has about -30% regression. I did a bisect
> > and found patch
> >
so shouldn't be passed to atomic_read.
mm/slub.c: In function 'slab_mem_offline_callback':
mm/slub.c:2737: warning: passing argument 1 of 'atomic_read' from incompatible
pointer type
mm/slub.c:2737: warning: passing argument 1 of 'atomic_read' from incompatible
pointer type
mm/slub.c:2737:
On Sun, Oct 28, 2007 at 04:41:57PM -0600, Matthew Wilcox wrote:
> On Sun, Oct 28, 2007 at 05:50:30PM -0400, Trond Myklebust wrote:
> > > You can't fix the false EDEADLK detection without solving the halting
> > > problem. Best of luck with that.
> >
> > I can see that it would be difficult to do
David Miller wrote:
>
>> Subject: Settings to /proc/sys/net/ipv[46]/conf/all are
>> not propagated. via sysctl too
>> Submitter : Serge van den Boom <[EMAIL PROTECTED]>
>> References: http://bugzilla.kernel.org/show_bug.cgi?id=9224
>> Handled-By: Hideaki YOSHIFUJI <[EMAIL
On Monday, 29 October 2007 02:17, David Miller wrote:
> From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
> Date: Sun, 28 Oct 2007 23:51:55 +0100
>
> > Subject : Settings to /proc/sys/net/ipv[46]/conf/all are not
> > propagated. via sysctl too
> > Submitter : Serge van den Boom <[EMAIL
From: "Rafael J. Wysocki" <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 23:51:55 +0100
> Subject : Settings to /proc/sys/net/ipv[46]/conf/all are not
> propagated. via sysctl too
> Submitter : Serge van den Boom <[EMAIL PROTECTED]>
> References:
On Sun, Oct 28, 2007 at 06:40:52PM +, Alan Cox wrote:
> On Sun, 28 Oct 2007 12:27:32 -0600
> Matthew Wilcox <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Oct 28, 2007 at 01:43:21PM -0400, J. Bruce Fields wrote:
> > > We currently attempt to return -EDEALK to blocking fcntl() file locking
> > >
From: Kyle McMartin <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 16:15:49 -0400
> To quote lolcats: CONFIG_RESOURCES_64BIT DO NOT WANT!
>
> I *think* I have the logic of this right... Anyway, I was annoyed by
> having to do the bloody ugly casts to unsigned long long in
> arch-specific code. As
From: "David Gaarenstroom" <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 21:11:13 +0100
> > I would like those to be removed, but to be conservative we should
> > first get some testing feedback that confirms this just like those
> > provided to me from the AMD folks for the RS690, RX790 and RD580
>
From: Greg KH <[EMAIL PROTECTED]>
Date: Sun, 28 Oct 2007 13:03:36 -0700
> But doesn't aligning such regions on that alignment break some devices
> as that is not what the device is asking for in the BIOS?
There are also platforms where bootup firmware chooses the
allocations, and that is what we
On Fri, 2007-10-26 at 12:31 +0100, Alan Cox wrote:
> On Fri, 26 Oct 2007 09:03:11 +0800
> "Huang, Ying" <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-10-25 at 18:09 +0200, Thomas Gleixner wrote:
> > > > EFI runtime
> > > > services initialization are implemented in efi.c. Some x86_64
> > > >
On Sun, 28 Oct 2007, Paul Jackson wrote:
> The Linux documentation is not a legal contract. Anytime we change the
> actual behaviour of the code, we have to ask ourselves what will be the
> impact of that change on existing users and usages. The burden is on
> us to minimize breaking things (by
Security fixes since 2.6.16.55:
- CVE-2007-3739: Don't allow the stack to grow into hugetlb reserved regions
- CVE-2007-4133: hugetlb: fix prio_tree unit
Location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/
git tree:
Rename old vfs_ioctl to do_ioctl, because the comment above it clearly
indicates that it is an internal function not to be exported to modules;
therefore it should have a more traditional do_XXX name. The new do_ioctl
is exported in fs.h but not to modules.
Rename the old do_ioctl to vfs_ioctl
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/unionfs/commonfops.c | 32 ++--
1 files changed, 6 insertions(+), 26 deletions(-)
diff --git a/fs/unionfs/commonfops.c b/fs/unionfs/commonfops.c
index 50e5775..c99b519 100644
--- a/fs/unionfs/commonfops.c
+++
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/ioctl.c | 164 +++-
1 files changed, 84 insertions(+), 80 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index c2a773e..652cacf 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -12,8 +12,8
Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>
---
fs/ioctl.c | 128 ++-
1 files changed, 74 insertions(+), 54 deletions(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 34e3f58..8dd2ef1 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -54,32
This series of 4 proposed patches changes fs/ioctl.c and Unionfs as
follows. This series is against v2.6.24-rc1-192-gef49c32.
Patch 1: just applies coding standards to fs/ioctl.c (while I'm at it, I
figured it's worth cleaning VFS files one at a time).
Patch 2: does two things:
(a) Renames
On Fri, 2007-10-26 at 11:53 +0200, Peter Zijlstra wrote:
> On Fri, 2007-10-26 at 17:43 +0800, Zhang, Yanmin wrote:
> > I tested 2.6.24-rc1 on my x86_64 machine which has 2 quad-core processors.
> >
> > Comparing with 2.6.23, aim7 has about -30% regression. I did a bisect and
> > found
> > patch
On Mon, Oct 29, 2007 at 10:50:05AM +1100, Stephen Rothwell wrote:
> Hi Olof,
>
> diffstat output is very useful - especially for patches like this that
> touch lots of files. It makes it easier for potential reviewers to see
> if they should be potential reviewers. :-)
Hi,
Good point. I'll
My old 486 fails to boot with the 2.6.24-rc1 kernel.
Grub loads it, 4 lines of text appear but not the kernel's
"Linux version greet", and the machine reboots.
Double-checked with a serial console: nothing appears
before it reboots.
All 2.6 kernels up to 2.6.23 worked fine on this machine.
On 10/29/07, Crispin Cowan <[EMAIL PROTECTED]> wrote:
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant.
Hi Olof,
diffstat output is very useful - especially for patches like this that
touch lots of files. It makes it easier for potential reviewers to see
if they should be potential reviewers. :-)
--
Cheers,
Stephen Rothwell[EMAIL PROTECTED]
http://www.canb.auug.org.au/~sfr/
David wrote:
> From a standpoint of the MPOL_PREFERRED memory policy itself, there
> is no documented behavior or standard that specifies its interaction
> with cpusets. Thus, it's "undefined." We are completely free
> to implement an undefined behavior as we choose and change it as
> Linux
On Sun, 28 Oct 2007 17:38:14 -0600
Matthew Wilcox <[EMAIL PROTECTED]> wrote:
> On Sun, Oct 28, 2007 at 09:38:55PM +, Alan Cox wrote:
> > > It doesn't require the system to detect it, only mandate what to return
> > > if it does detect it.
> >
> > We should be detecting at least the obvious
On Sun, Oct 28, 2007 at 09:38:55PM +, Alan Cox wrote:
> > It doesn't require the system to detect it, only mandate what to return
> > if it does detect it.
>
> We should be detecting at least the obvious case.
What is the obvious case? A task that has never called clone()?
> If SYSV only
> > The spec and SYSV certainly ignore threading in this situation and you
> > know that perfectly well (or did in 2004)
>
> The discussion petered out (or that mailing list archive lost articles
> from the thread) without any kind of resolution, or indeed interest.
I think the resolution was
On Sun, Oct 28, 2007 at 11:55:52PM +0100, Jiri Kosina wrote:
> On Sun, 28 Oct 2007, Matthew Wilcox wrote:
>
> > Bzzt. You get a false deadlock with multiple threads like so:
> > Thread A of task B takes lock 1
> > Thread C of task D takes lock 2
> > Thread C of task D blocks on lock 1
> > Thread
On Sun, 28 Oct 2007 18:37:24 +0100
Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> Please use CONFIG_X86_64.
>
> cu
> Adrian
>
Now uses CONFIG_X86_64.
Brad.
--- linux-2.6/drivers/char/i8k.c.orig 2007-10-28 12:27:34.0 +
+++ linux-2.6/drivers/char/i8k.c2007-10-28
> To reject an LSM for providing "bad" security, IMHO you should have to
> show how it is possible to subvert the self-stated goals of that LSM.
> Complaints that the LSM fails to meet some goal outside of its stated
> purpose is irrelevant. Conjecture that it probably can be violated
> because of
Matt Domsch wrote:
On Sun, Oct 28, 2007 at 07:06:23PM +0100, [EMAIL PROTECTED] wrote:
Matt Domsch wrote:
On Sun, Oct 28, 2007 at 05:12:37PM +0100, [EMAIL PROTECTED] wrote:
Hello,
this driver implements backlight control on Dell laptops
which use SMI for changing brightness levels.
The
Krzysztof Halasa wrote:
> Stefan Richter <[EMAIL PROTECTED]> writes:
>> # ./a.out 00:0a.3
>> I/O region #1 is at C800
>> It seems your VT6307 chip is connected to 93c46 EEPROM
>
> Interesting, really. Perhaps they aimed at I2C too with 9306 but
> screwed up the silicon? Would have
This allows a flag to be set on loop devices so that when they are
closed for the last time, they'll self-destruct.
Signed-off-by: David Woodhouse <[EMAIL PROTECTED]>
diff --git a/drivers/block/loop.c b/drivers/block/loop.c
index 56e2304..7fae828 100644
--- a/drivers/block/loop.c
+++
On Sunday, 28 October 2007 23:53, Alan Cox wrote:
> > Subject : 2.6.24-rc1: pata_acpi fails to activate DMA for
> > DVD-ROM on ALi M5229 secondary channel
> > Submitter : Andrey Borzenkov <[EMAIL PROTECTED]>
> > References : http://marc.info/?l=linux-kernel=119342005216716=2
> >
On Sunday, 28 October 2007 23:48, Frans Pop wrote:
> The regression in process CPU usage display in top is still there:
> http://bugzilla.kernel.org/show_bug.cgi?id=9135
>
> It's a regression from .22, not from .23, but I guess it should still be
> listed.
Well, my intention is to list the most
On Sun, 28 Oct 2007, Matthew Wilcox wrote:
> Bzzt. You get a false deadlock with multiple threads like so:
> Thread A of task B takes lock 1
> Thread C of task D takes lock 2
> Thread C of task D blocks on lock 1
> Thread E of task B blocks on lock 2
A potential for deadlock occurs if a
On Sun, Oct 28, 2007 at 10:48:33PM +, Alan Cox wrote:
> > Bzzt. You get a false deadlock with multiple threads like so:
> >
> > Thread A of task B takes lock 1
> > Thread C of task D takes lock 2
> > Thread C of task D blocks on lock 1
> > Thread E of task B blocks on lock 2
>
> The spec
On Sun, Oct 28, 2007 at 10:46:47PM +, Richard Purdie wrote:
> On Thu, 2007-10-25 at 22:54 +0100, Richard Purdie wrote:
> > On Thu, 2007-10-25 at 13:02 -0700, Andrew Morton wrote:
> > > It was in the inital report, at
> > > http://bugzilla.kernel.org/show_bug.cgi?id=9217 :
> >
> > This is the
1 - 100 of 546 matches
Mail list logo
