On Thu, 29 Nov 2007 08:38:59 +0100, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> > The problem stems from the fact that both option and usb-storage can bind
> > to the modem when in storage mode: the former binds because of the
> Hi Gary, Kenji-san, et. al,
>
> * Gary Hade <[EMAIL PROTECTED]>:
>> Alex, What I was trying to suggest is a boot-time kernel
>> option, not a kernel configuration option. The basic idea is
>> to give the user (with a single binary kernel) the ability to
>> include your ACPI-PCI slot driver
On 29-11-2007 03:34, David Schwartz wrote:
>> Thanks for the help. Someday, I hope to understand this stuff.
>>
>> Larry
>
> Any code either deals with an object or it doesn't. If it doesn't deal with
> that object, it should not be acquiring locks on that object. If it does
> deal with that
On Wed, 2007-11-28 at 22:08 -0800, Greg KH wrote:
> On Wed, Nov 28, 2007 at 06:00:27PM +0100, Kay Sievers wrote:
> > On Wed, 2007-11-28 at 17:51 +0100, Cornelia Huck wrote:
> > > On Wed, 28 Nov 2007 17:36:29 +0100, Kay Sievers <[EMAIL PROTECTED]> wrote:
> > > > On Wed, 2007-11-28 at 17:12 +0100,
Am Donnerstag, 29. November 2007 07:33:03 schrieb Johann Wilhelm:
> But in my opinion the the modul-load-order should be forced by udev...
> this should work and we only have 1 position to keep in mind if we eg.
> get a new E220, support for the E270 or something else...
No, udev cannot help
Hi there,
Well your code basically looks nice... but keep in mind that there are
several different E220-devices (in fact i know of 2 different PIDs...
and I would be really surprised if they only use 2 of them...). So you
should check all possible PIDs...
But in my opinion the the
Am Donnerstag, 29. November 2007 01:13:05 schrieb Pete Zaitcev:
> The problem stems from the fact that both option and usb-storage can bind
> to the modem when in storage mode: the former binds because of the storage
> class, the latter binds because of VID/PID match. The modprobe loads both,
Function timekeeping_is_continuous() no longer checks flag
CLOCK_IS_CONTINUOUS, and it checks CLOCK_SOURCE_VALID_FOR_HRES
now. So rename the function accordingly.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
include/linux/time.h |2 +-
kernel/time/tick-sched.c |2 +-
On Nov. 29, 2007, 3:19 +0200, "Ming Lei" <[EMAIL PROTECTED]> wrote:
> 2007/11/29, Jan Engelhardt <[EMAIL PROTECTED]>:
>> On Nov 29 2007 01:05, J.A. Magallón wrote:
>>> Since begin of the ages the build of the nvidia driver says things like
>>> this:
>>>
>> Explicitly adding -Wpointer-arith to ones
Fix typo in comments.
BTW: I have to fix coding style in arch/ia64/kernel/time.c also,
otherwise checkpatch.pl will be complaining.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
arch/ia64/kernel/time.c | 14 +++---
arch/x86/kernel/time_64.c |2 +-
include/linux/hrtimer.h |
Function do_timer_interrupt_hook() don't take argument regs,
and structure hrtimer_sleeper don't have member cb_pending.
So delete comments refering to these symbols.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
include/asm-x86/mach-voyager/do_timer.h |1 -
include/linux/hrtimer.h
Add a missing '.' in prink information.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
kernel/time/tick-oneshot.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/time/tick-oneshot.c b/kernel/time/tick-oneshot.c
index 0258d31..0b5e513 100644
---
Those patches do some small fixes and code cleanups.
No actual bug is fixed though.
Li Zefan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
Flag CLOCK_SOURCE_WATCHDOG is cleared twice. Note clocksource_change_rating()
won't do anyting with the cs flag.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
kernel/time/clocksource.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/kernel/time/clocksource.c
list_for_each_safe() suffices here.
Signed-off-by: Li Zefan <[EMAIL PROTECTED]>
---
kernel/time/clockevents.c | 11 ---
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 822beeb..68fbe73 100644
---
On Sat, 24 Nov 2007 20:31:25 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> On Saturday, 24 of November 2007, Stefano Brivio wrote:
> > On Sat, 24 Nov 2007 19:48:58 +0100
> > "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> >
> > > NO_HZ? Highres timers?
> >
> > CONFIG_HZ_1000=y
> > #
Any comment?
Thanks
Sonic
On Nov 27, 2007 12:47 PM, sonic zhang <[EMAIL PROTECTED]> wrote:
> UDMA Mode - Frequency compatibility
>
> UDMA5 - 100 MB/s - SCLK = 133 MHz
> UDMA4 - 66 MB/s- SCLK >= 80 MHz
> UDMA3 - 44.4 MB/s - SCLK >= 50 MHz
> UDMA2 - 33 MB/s- SCLK >= 40 MHz
>
>
>
Andrew Morton wrote:
> On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> Andrew Morton wrote:
>>> On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
>>> wrote:
>>>
Hi,
>>> (cc linux-scsi, for sym53c8xx)
>>>
Soft lockup is detected
Thank you. Integrated the fixes in my patch.
On Nov 28, 2007 6:13 PM, Frans Pop <[EMAIL PROTECTED]> wrote:
> Two typos in comments.
>
> Cheers,
> FJP
>
> Michael Rubin wrote:
> > + * The flush tree organizes the dirtied_when keys with the rb_tree. Any
> > + * inodes with a duplicate dirtied_when
Please CC: me on any replies, as I am not subscribed to the list.
I want to do some bio IO on a block device (*no* filesystem involved).
First I need to get hold of the struct block_device. What is the current
recommended way to get from the name of a device (e.g. "/dev/sda1") to the
On Wed, Nov 28, 2007 at 03:33:12PM -0800, Stephen Hemminger wrote:
...
> WTF are you teaching a lesson on how NOT to do locking?
>
> Any code which has this kind of convoluted dependency on conditional
> locking is fundamentally broken.
>
As a matter of fact I've been thinking, about one more
On Wed, 2007-11-28 at 21:34 -0500, Mathieu Desnoyers wrote:
> Before I start digging deeper in checking whether it is already
> instrumented by the fs instrumentation (and would therefore be
> redundant), is there a particular data structure from mm/ that you
> suggest taking the swap file number
Paul Mundt wrote:
This builds on top of the earlier vmalloc_32_user() work introduced by
b50731732f926d6c49fd0724616a7344c31cd5cf, as we now have places in the
nommu allmodconfig that hit up against these missing APIs.
As vmalloc_32_user() is already implemented, this is moved over to
On Wed, Nov 28, 2007 at 02:03:28PM -0500, Alan Stern wrote:
> On Tue, 27 Nov 2007, Greg KH wrote:
>
> > Part of the difficulty in understanding the driver model - and the kobject
> > abstraction upon which it is built - is that there is no obvious starting
> > place. Dealing with kobjects
Second portion. Add a new seg_offset macro to calculate the offset. This
can be avoided if the linker relocates the per cpu area to zero. Includes
a patch to read trickle count via both methods to verify that it actually
works. Both patches on top of the per cpu cleanup patches that I sent
On Wed, Nov 28, 2007 at 05:35:32PM +0100, Cornelia Huck wrote:
> On Tue, 27 Nov 2007 15:04:06 -0800,
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > static struct foo_obj *create_foo_obj(const char *name)
> > {
> > struct foo_obj *foo;
> > int retval;
> >
> > /* allocate the memory for
On Wed, Nov 28, 2007 at 12:45:45PM +0100, Cornelia Huck wrote:
> On Tue, 27 Nov 2007 15:02:52 -0800,
> Greg KH <[EMAIL PROTECTED]> wrote:
> > - A kset can provide a set of default attributes that all kobjects that
> >belong to it automatically inherit and have created whenever a kobject
> >
On Wed, Nov 28, 2007 at 06:00:27PM +0100, Kay Sievers wrote:
> On Wed, 2007-11-28 at 17:51 +0100, Cornelia Huck wrote:
> > On Wed, 28 Nov 2007 17:36:29 +0100,
> > Kay Sievers <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > On Wed, 2007-11-28 at 17:12 +0100, Cornelia Huck wrote:
> > > > On Wed, 28 Nov
On Wed, Nov 28, 2007 at 01:23:02PM +0100, Kay Sievers wrote:
> On Wed, 2007-11-28 at 12:45 +0100, Cornelia Huck wrote:
> > On Tue, 27 Nov 2007 15:02:52 -0800, Greg KH <[EMAIL PROTECTED]> wrote:
>
> > > A kset serves these functions:
> > >
> > > - It serves as a bag containing a group of
Here is the first of two patches for x86_64 that move the pda into the per
cpu area and then make the x86 percpu macros work for x86_64. This needs
to be generalized for other arches. The __per_cpu_start offsets can be
taken care of by the linker. We can also tell the linker to completely
On Wed, Nov 28, 2007 at 10:01:08AM +0100, Cornelia Huck wrote:
> On Tue, 27 Nov 2007 15:02:52 -0800,
> Greg KH <[EMAIL PROTECTED]> wrote:
> > So, for example, UIO code has a structure that defines the memory region
> > associated with a uio device:
> >
> > struct uio_mem {
> > struct kobject
On Tue, Nov 27, 2007 at 08:50:14PM -0700, Jonathan Corbet wrote:
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > Jonathan, I used your old lwn.net article about kobjects as the basis
> > for this document, I hope you don't mind
>
> Certainly I have no objections, I'm glad it was useful.
Thanks, it
On 11/29/07, Ishizaki Kou <[EMAIL PROTECTED]> wrote:
[...snip...]
>
> There is no problem to use Michael's part, and I also prefer simple
> one like this.
>
> Cyrill, would you please update your patch?
>
> Best regards,
> Kou Ishizaki
>
Please see updated patch enveloped. (Can't do it inline
Christoph Lameter wrote:
> x86_64 can use a 32 bit offset instead of a 64 bit addres because it uses
> the small model. A load of a 64 bit address would require much more
> expensive instructions. A load of a 64 bit address is currently avoided
> through the use of the pda that contains the
Jakub Narebski wrote:
> Al Boldi wrote:
> > Johannes Schindelin wrote:
> >> By that definition, no SCM, not even CVS, is transparent. Nothing
> >> short of unpacked directories of all versions (wasting a lot of disk
> >> space) would.
> >
> > Who said anything about unpacking?
> >
> > I'm talking
On Thu, 29 Nov 2007 12:23:29 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> I noticed CONFIG_NUMA + CONFIG_CGROUP_MEM_CONT + CONFIG_SLUB cannot boot
> because of my patch.
> (SLAB is ok.)
> I'll post workaround soon.
>
==
This is a fix. tested on my ia64/NUMA box both on SLAB/SLUB.
This
Vegard Nossum wrote:
Hi,
On Nov 28, 2007 7:51 AM, Richard Knutsson <[EMAIL PROTECTED]> wrote:
Vegard Nossum wrote:
+static int
Not 'static bool'?
+page_is_tracked(struct page *page)
Why not returning 'false' and 'true'?
Sorry, I am not used to using bool
On Wed, Nov 28, 2007 at 11:00:36PM -0500, Mark Lord wrote:
> While doing insert/remove (quickly) tests on USB, I managed to trigger
> an Oops on 2.6.23.1 on the call to strlen() in make_class_name().
>
> This patch prevents this oops.
>
> There is still the larger problem of the overall race
>
On Wednesday 28 November 2007 11:02, Hugh Dickins wrote:
> mm's printk has been showing "%p" in abominable upper case recently:
> its trivial optimizations have changed the default from lower to upper,
> so the 'p' case needs to enforce lower explicitly.
>
> Signed-off-by: Hugh Dickins <[EMAIL
On Wed, Nov 28, 2007 at 06:08:16PM +0100, Roman Zippel wrote:
> On Wed, 28 Nov 2007, Paul Mundt wrote:
> > While allyes/mod/noconfigs do seem to work fine with KCONFIG_ALLCONFIG
> > provisions, randconfig tramples all over the provided values at perhaps
> > not surprisingly, random.
>
> Please be
While doing insert/remove (quickly) tests on USB, I managed to trigger
an Oops on 2.6.23.1 on the call to strlen() in make_class_name().
This patch prevents this oops.
There is still the larger problem of the overall race
that caused this in the first place, but much of the rest
of the code in
thanks, applied
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Thu, 29 Nov 2007 12:33:28 +0900 (JST)
[EMAIL PROTECTED] (YAMAMOTO Takashi) wrote:
> > +static inline struct mem_cgroup_per_zone *
> > +mem_cgroup_zoneinfo(struct mem_cgroup *mem, int nid, int zid)
> > +{
> > + if (!mem->info.nodeinfo[nid])
>
> can this be true?
>
> YAMAMOTO Takashi
When I
> +static inline struct mem_cgroup_per_zone *
> +mem_cgroup_zoneinfo(struct mem_cgroup *mem, int nid, int zid)
> +{
> + if (!mem->info.nodeinfo[nid])
can this be true?
YAMAMOTO Takashi
> + return NULL;
> + return >info.nodeinfo[nid]->zoneinfo[zid];
> +}
> +
-
To unsubscribe
On Thu, 29 Nov 2007, KAMEZAWA Hiroyuki wrote:
> ok, just use N_HIGH_MEMORY here and add comment for hotplugging support is
> not yet.
>
> Christoph-san, Lee-san, could you confirm following ?
>
> - when SLAB is used, kmalloc_node() against offline node will success.
> - when SLUB is used,
On Thu, 29 Nov 2007 12:19:37 +0900 (JST)
[EMAIL PROTECTED] (YAMAMOTO Takashi) wrote:
> > @@ -651,10 +758,11 @@
> > /* Avoid race with charge */
> > atomic_set(>ref_cnt, 0);
> > if (clear_page_cgroup(page, pc) == pc) {
> > + int active;
> >
Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> On 11/28/07, Cyrill Gorcunov <[EMAIL PROTECTED]> wrote:
> > On 11/28/07, Michael Ellerman <[EMAIL PROTECTED]> wrote:
> > > On Mon, 2007-11-26 at 10:46 +0300, Cyrill Gorcunov wrote:
> > > > This patch adds checking for NULL value returned to prevent
> +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-add-scan_global_lru-macro.patch
> +per-zone-and-reclaim-enhancements-for-memory-controller-take-3-nid-zid-helper-function-for-cgroup.patch
>
> @@ -651,10 +758,11 @@
> /* Avoid race with charge */
> atomic_set(>ref_cnt, 0);
> if (clear_page_cgroup(page, pc) == pc) {
> + int active;
> css_put(>css);
> + active = pc->flags &
On Thu, 29 Nov 2007 11:24:06 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Nov 2007 10:37:02 +0900
> KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
>
> > Maybe zonelists of NODE_DATA() is not initialized. you are right.
> > I think N_HIGH_MEMORY will be suitable here...(I'll
Quoting Casey Schaufler ([EMAIL PROTECTED]):
> From: Casey Schaufler <[EMAIL PROTECTED]>
>
> Bump the value of CAP_LAST_CAP to reflect the current last cap value.
> It appears that the patch that introduced CAP_LAST_CAP and the patch
> that introduced CAP_MAC_ADMIN came in more or less at the
Looks good to me.
Thanks.
Acked-by: Yasunori Goto <[EMAIL PROTECTED]>
> On Tue, Nov 27, 2007 at 10:53:45AM -0800, Dave Hansen wrote:
> >On Tue, 2007-11-27 at 10:26 +0800, WANG Cong wrote:
> >>
> >> @@ -414,7 +418,7 @@ int sparse_add_one_section(struct zone *
> >> out:
> >>
On Mon, 26 Nov 2007, Linus Torvalds wrote:
>
>
> On Thu, 22 Nov 2007, Mikulas Patocka wrote:
> >
> > netif_rx is meant to be called from interrupts because it doesn't wake up
> > ksoftirqd. For calling from outside interrupts, netif_rx_ni exists.
>
> Argh. Can you _please_ use more useful
> Thanks for the help. Someday, I hope to understand this stuff.
>
> Larry
Any code either deals with an object or it doesn't. If it doesn't deal with
that object, it should not be acquiring locks on that object. If it does
deal with that object, it must know the internal details of that object,
I am adding the rest.. two questions left :
* Dave Hansen ([EMAIL PROTECTED]) wrote:
> >
> > Index: linux-2.6-lttng/mm/memory.c
> > ===
> > --- linux-2.6-lttng.orig/mm/memory.c2007-11-28 08:42:09.0
> > -0500
> >
On Thu, 29 Nov 2007 10:37:02 +0900
KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> Maybe zonelists of NODE_DATA() is not initialized. you are right.
> I think N_HIGH_MEMORY will be suitable here...(I'll consider node-hotplug
> case later.)
>
> Thank you for test!
>
Could you try this ?
Two typos in comments.
Cheers,
FJP
Michael Rubin wrote:
> + * The flush tree organizes the dirtied_when keys with the rb_tree. Any
> + * inodes with a duplicate dirtied_when value are link listed together.
> This + * link list is sorted by the inode's i_flushed_when. When both the
> + *
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
> > percpu references are quite frequent already (vm statistics) and will be
> > more frequent after we have converted the per cpu arrays to per cpu
> > allocations.
> >
>
> Well, I think the point is moot, because x86 will always use 32-bit
>
Christoph Lameter wrote:
> The percpu areas need to be allocated in a NUMA aware fashion. Otherwise
> you use distant memory for the most performance sensitive areas. The NUMA
> subsystem must be so far up that these allocations can be performed in the
> right way. And this means at least you
drivers/net/e1000/e1000_ethtool.c:113:
#define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN
drivers/net/e1000e/ethtool.c:106:
#define E1000_TEST_LEN sizeof(e1000_gstrings_test) / ETH_GSTRING_LEN
E1000_TEST_LEN*ETH_GSTRING_LEN will expand to
sizeof(e1000_gstrings_test) /
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
> Don't think it matters either way. Before percpu is allocated, NUMA
> issues don't matter. Once they are - by whatever mechanism - you can
> set the segment bases up appropriately. The fact that you chose to put
> percpu data at address X
The cancel_delayed_work_sync has moved into ilw_cancel_deferred_work.
Thanks Zhu Yi.
[net/wireless/iwlwifi] : iwlwifi 4965 Fix race conditional panic.
Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
diff --git a/drivers/net/wireless/iwlwifi/iwl4965-base.c
--- Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Nov 28 2007 18:22, [EMAIL PROTECTED] wrote:
> >
> >Talpa is modular itself being composed of a set of kernel modules of which
> >not all are loaded simultaneously. Where possible LSM can be used and _no_
> >messing with syscall table will
2007/11/29, Zhu Yi <[EMAIL PROTECTED]>:
>
> Good catch. But it will be better if you add it into
> iwl_cancel_deferred_work().
>
Thanks.
I agree with you.
Actually, I considered it, but I was afraid of side effect.
Anyway, I'm attaching a new one.
Thanks.
Joonwoo
[net/wireless/iwlwifi] :
Christoph Lameter wrote:
> On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
>
>
>> I don't see the problem. The way i386 does it inherently supports
>> per-cpu data very early on (it uses the prototype percpu section until
>> the real percpu values are set up).
>>
>
> Ok so we could do
On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
> I don't see the problem. The way i386 does it inherently supports
> per-cpu data very early on (it uses the prototype percpu section until
> the real percpu values are set up).
Ok so we could do that for x86_64 as well? There is more complicated
On Wed, 28 Nov 2007 16:19:59 -0500
Lee Schermerhorn <[EMAIL PROTECTED]> wrote:
> As soon as this loop hits the first non-existent node on my platform, I
> get a NULL pointer deref down in __alloc_pages. Stack trace below.
>
> Perhaps N_POSSIBLE should be N_HIGH_MEMORY? That would require
Roel Kluin wrote:
> Add parentheses to prevent operator precedence errors
>
> Signed-off-by: Roel Kluin <[EMAIL PROTECTED]>
For the arch-ixp23xx part I should have added:
Acked-by: Lennert Buytenhek <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> * drop support for stack-protector (does it really help? do people
> use it?)
AFAIK we only ever had a single classical stack buffer overflow in the kernel.
It certainly doesn't seem to be a common security problem it is solving.
-Andi
-
To unsubscribe from this list: send the line
Christoph Lameter wrote:
> On Wed, 28 Nov 2007, Jeremy Fitzhardinge wrote:
>
> > Yes, I would like to convert x86_64 to match i386's percpu, and drop the
>
>> pda altogether. The only thing preventing this is the stack canary, and
>> I'm wondering how much value there is in keeping it, given
On Thu, 29 Nov 2007, Andi Kleen wrote:
> On Wed, Nov 28, 2007 at 04:11:37PM -0800, Christoph Lameter wrote:
> > 1. The stack canary
>
> You would need to change gcc with a new option and only allow the stack
> checking when the compiler supports the new option. However the problem
> is still how
2007/11/29, Jan Engelhardt <[EMAIL PROTECTED]>:
>
> On Nov 29 2007 01:05, J.A. Magallón wrote:
> >
> >Since begin of the ages the build of the nvidia driver says things like
> >this:
> >
>
> Explicitly adding -Wpointer-arith to ones own Makefile is like
> admitting the code might be problematic.
On Wed, Nov 28, 2007 at 04:11:37PM -0800, Christoph Lameter wrote:
> 1. The stack canary
You would need to change gcc with a new option and only allow the stack
checking when the compiler supports the new option. However the problem
is still how to get a reasonable fixed offset. Or perhaps just
>The previous code returned '\n' (that is, a single empty line)
>from most files, with one exception (xmit_hash_policy), where
>it returned 'NA\n'. This patch consolidates each file to return
>nothing at all if not applicable, not even a '\n'.
>
>I find this behaviour more usual, more useful,
On Wed, 2007-11-28 at 19:41 +0900, Joonwoo Park wrote:
> [net/wireless/iwlwifi] : iwlwifi 3945 Fix race conditional panic.
>
> Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
> ---
> diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c
> b/drivers/net/wireless/iwlwifi/iwl3945-base.c
> index
On Wed, Nov 28, 2007 at 04:02:38PM -0800, Kristen Carlson Accardi wrote:
> On Wed, 28 Nov 2007 13:31:47 -0800
> Gary Hade <[EMAIL PROTECTED]> wrote:
>
> > FYI, the node contains 2 hotpluggable PCIe slots and 5
> > non-hotpluggable PCIe slots but 'pci_slot' only exposed
> > the 2 hotpluggable
Andrew Patterson wrote:
> I tried with clean 2.6.24-rc3 and get the same bad behavior. This is on
> an ia64 box, so maybe that is an issue. I can try on an x86 box as well.
> Oh, one other thing. I tried a "uname -r" to make sure I had the
> correct kernel booted and got:
>
> # uname -r
>
in include/asm-arm/arch-omap/board-innovator.h:40
#define NR_IRQSIH_BOARD_BASE + NR_FPGA_IRQS
in include/asm-arm/arch-ixp23xx/irqs.h:156:
#define NR_IRQS NR_IXP23XX_IRQS + NR_IXP23XX_MACH_IRQS
This could lead to problems when this definition is used in:
arch/ia64/sn/kernel/irq.c:516:
On Thu, Nov 29, 2007 at 01:53:46AM +0100, Jan Engelhardt wrote:
>
> On Nov 28 2007 16:38, Greg KH wrote:
> >>
> >> And if we are talking about the situation when files are written to
> >> in controlled way (i.e. we are not concerned with malware running on
> >> the box in question and just want
=?utf-8?q?Ferenc_W=C3=A1gner?= wrote:
Signed-off-by: Ferenc Wágner <[EMAIL PROTECTED]>
Acked-by: Randy Dunlap <[EMAIL PROTECTED]>
Thanks.
---
Randy Dunlap <[EMAIL PROTECTED]> writes:
drivers/net/bonding/bond_sysfs.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff
On Wed, Nov 28, 2007 at 12:42:52PM +, Tvrtko A. Ursulin wrote:
>
> Hi Linus, all,
>
> During one recent LKML discussion
> (http://marc.info/?l=linux-kernel=119267398722085=2) about LSM going
> static you called for LSM users to speak up.
>
> We here at Sophos (the fourth largest endpoint
On Wednesday 28 November 2007 19:43:45 Andrew Morton wrote:
> > I guess all architectures except x86 are currently broken because they
> > reference the old sys_timerfd function.
>
> None of them were broken in my testing and I'm unsure why powerpc broke
> here.
PowerPC is unique in that it
On Nov 28 2007 16:38, Greg KH wrote:
>>
>> And if we are talking about the situation when files are written to
>> in controlled way (i.e. we are not concerned with malware running on
>> the box in question and just want to stop it from passing through
>> mailsewer, etc.), then there's no damn
On Nov 28 2007 18:22, [EMAIL PROTECTED] wrote:
>
>Talpa is modular itself being composed of a set of kernel modules of which
>not all are loaded simultaneously. Where possible LSM can be used and _no_
>messing with syscall table will take place. Unfortunately where another
>LSM user is present
> I'll try rt12...
>
> Same problems in rt12, getting lots of "delay of xxx usecs exceeds
> estimated spare time of ; restart" in jackd (on my T61 Lenovo laptop
> running fc7). Does not happen with 2.6.22.10 + rt9. This is both with
> the internal snd-hda-intel card and a pcmcia rme hdsp
This generalizes the getreg32 and putreg32 functions so they can be used on
the current task, as well as on a task stopped in TASK_TRACED and switched
off. This lays the groundwork to share this code for all kinds of
user-mode machine state access, not just ptrace.
Signed-off-by: Roland McGrath
This generalizes the getreg and putreg functions so they can be used on the
current task, as well as on a task stopped in TASK_TRACED and switched off.
This lays the groundwork to share this code for all kinds of user-mode
machine state access, not just ptrace.
Signed-off-by: Roland McGrath
This generalizes the getreg and putreg functions so they can be used on the
current task, as well as on a task stopped in TASK_TRACED and switched off.
This lays the groundwork to share this code for all kinds of user-mode
machine state access, not just ptrace.
Signed-off-by: Roland McGrath
This canonicalizes the indentation in the getreg and putreg functions.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace_32.c | 110 +-
1 files changed, 55 insertions(+), 55 deletions(-)
diff --git
This canonicalizes the indentation in the getreg and putreg functions.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/ptrace_64.c | 224 +-
1 files changed, 112 insertions(+), 112 deletions(-)
diff --git
On Nov 29 2007 01:05, J.A. Magallón wrote:
>
>Since begin of the ages the build of the nvidia driver says things like
>this:
>
Explicitly adding -Wpointer-arith to ones own Makefile is like
admitting the code might be problematic. :->
I think sizeof(void *) == 1 is taken as granted as
On Wed, Nov 28, 2007 at 06:30:40PM +, Al Viro wrote:
> On Wed, Nov 28, 2007 at 01:15:05PM -0500, [EMAIL PROTECTED] wrote:
> > (Note that the concept has interesting implications in the other direction
> > as
> > well - rather than stopping you from reading a file that has malware, you
> >
This cleans up the getreg32/putreg32 functions to use struct pt_regs in a
straightforward fashion, instead of equivalent ugly pointer arithmetic.
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/ia32/ptrace32.c | 21 +
1 files changed, 9 insertions(+), 12
On Wed, Nov 28, 2007 at 06:17:39PM -0500, Mark Lord wrote:
> Greg KH wrote:
>> On Wed, Nov 28, 2007 at 03:02:35PM -0500, Mark Lord wrote:
>>> While testing a new USB reader/cable today,
>>> I was plugging/unplugging the USB multi-flash reader (22 in 1),
>>> and produced this weird oops.
>>>
>>>
On Wed, Nov 28, 2007 at 11:29:57AM -0800, Michael Rubin wrote:
> >From [EMAIL PROTECTED] Wed Nov 28 11:10:06 2007
> Message-Id: <[EMAIL PROTECTED]>
> Date: Wed, 28 Nov 2007 11:01:21 -0800
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> Subject: [patch 1/1] Writeback fix for concurrent large
Maitre Bart wrote:
A given app is allocating a large amount of memory (~10M) with
malloc().
It passes this pointer to the kernel (device driver) via an custom
ioctl.
I would like the driver to work on that memory with a pointer (as if
it was allocated with vmalloc) as well as the user space too
From: Casey Schaufler <[EMAIL PROTECTED]>
Bump the value of CAP_LAST_CAP to reflect the current last cap value.
It appears that the patch that introduced CAP_LAST_CAP and the patch
that introduced CAP_MAC_ADMIN came in more or less at the same time.
Signed-off-by: Casey Schaufler <[EMAIL
Em Thu, Nov 29, 2007 at 01:05:31AM +0100, J.A. Magallón escreveu:
> Hi all...
>
> Since begin of the ages the build of the nvidia driver says things like
> this:
>
> include/asm/compat.h:210: warning: pointer of type 'void *' used in arithmetic
>
> There are several of this warnings. The code
Signed-off-by: Ferenc Wágner <[EMAIL PROTECTED]>
---
Randy Dunlap <[EMAIL PROTECTED]> writes:
> Wagner Ferenc wrote:
>> Randy Dunlap <[EMAIL PROTECTED]> writes:
>>
>>> Patches 1 & 3 use
>>>
>>> if (res) statement;
>>>
>>> but the preferred form is
>>>
>>> if (res)
>>>
Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> Quoting Serge E. Hallyn ([EMAIL PROTECTED]):
> > Quoting Casey Schaufler ([EMAIL PROTECTED]):
> > >
> > > --- Jiri Slaby <[EMAIL PROTECTED]> wrote:
> > >
> > > > On 11/28/2007 12:41 PM, Andrew Morton wrote:
> > > > >
> > > >
> > >
1 - 100 of 924 matches
Mail list logo
