The mmc_spi driver's mmc_cs_off() function states that "chipselect will always
be inactive after setup()"; however, the spi-davinci driver's setup() leaves CS
state unchanged.
Add a call to davinci_spi_chipselect(spi, BITBANG_CS_INACTIVE) to the spi-
davinci drivers' setup() function.
Signed-off-
On 09/10/2013 01:55 AM, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 09:42:46PM -0700, John Stultz wrote:
>> @@ -38,10 +39,58 @@
>> */
>> typedef struct seqcount {
>> unsigned sequence;
>> +#ifdef CONFIG_DEBUG_LOCK_ALLOC
>> +struct lockdep_map dep_map;
>> +#endif
>> } seqcount_t;
>>
On 09/10/2013 01:43 AM, Peter Zijlstra wrote:
> On Mon, Sep 09, 2013 at 09:42:46PM -0700, John Stultz wrote:
>> Currently seqlocks and seqcounts don't support lockdep.
>>
>> After running across a seqcount related deadlock in the timekeeping
>> code, I used a less-refined and more focused varient o
On Tue, Sep 10, 2013 at 8:29 AM, Arjan van de Ven wrote:
>>
> also.. yuck on using "dec"
> "dec" sucks, please use "sub foo ,1" instead
That's a bigger instruction, largely due to the constant.
> (dec sucks because of its broken flags behavior; it creates basically a
> bubble in the pipeline)
On 09/10/2013 12:29 AM, Ingo Molnar wrote:
> * John Stultz wrote:
>
>> Now, I'm still in the dark as to why HRTICK exposes this, but seems like
>> the following patch should resolve the issue (and quiets the lockdep
>> warnings in my testing). Let me know how it works for you!
>>
>> Ingo: This m
On Tue, 10 Sep 2013, Viresh Kumar wrote:
> On 10 September 2013 20:42, Guennadi Liakhovetski
> wrote:
> > 4. reverted that commit, resolving a trivial conflict. Added a debug
> > output in __cpufreq_driver_target() of
> >
> >
> > if (cpufreq_disabled())
> > return -ENODEV
On 09/10/2013 09:31 AM, Linus Torvalds wrote:
> On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse wrote:
>>
>> In cost-sensitive products (and what *isn't* cost-sensitive these days),
>> you really don't want to have to put an extra EEPROM on the board
>> somewhere
>
> Don't be silly. Nobody wants
On 09/10/2013 04:09 PM, J. Bruce Fields wrote:
> On Sat, Sep 07, 2013 at 10:44:00PM +0200, Toralf Förster wrote:
>> Today I run latest git tree with a patched UML (this patch + one for xterm
>> issues) and got 2 times a core dump
>> when I fuzzy test an UML machine with a nearly identical scenario
Lee Jones wrote:
>At the moment the driver is silent in some error cases and if
>successful.
>Prior to this patch there was no clear way to know if the driver
>succeeded
>or not without looking deep into sysfs.
>
>Signed-off-by: Lee Jones
>---
> drivers/iio/pressure/st_pressure_core.c | 3 +++
>
Fixed space prohibition before semicolon, particularly:
nvm.c:106: WARNING: space prohibited before semicolon
nvm.c:1098: WARNING: space prohibited before semicolon
nvm.c:1279: WARNING: space prohibited before semicolon
nvm.c:2834: WARNING: space prohibited before semicolon
nvm.c:3361: WARNING: sp
On 09/10/2013 05:00 PM, Joel Fernandes wrote:
> On 09/10/2013 08:17 AM, Javier Martinez Canillas wrote:
>> On 09/10/2013 09:00 AM, Joel Fernandes wrote:
>>> On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
On 07/31/2013 01:44 AM, Linus Walleij wrote:
> On Tue, Jul 30, 2013 at 6:30 A
[ Dave - your linux.ie email generates bounces for me, trying redhat instead ]
On Mon, Sep 9, 2013 at 11:25 PM, Sean V Kelley wrote:
>>
>> I'm also a bit bummed that hw acceleration of video doesn't seem to
>> work on Haswell, meaning that full-screen is now a jerky mess. I fear
>> that that is u
Hi Dan,
2013-09-03 Dan Aloni :
> Tested with this patch and a Bluetooth mouse on 3.10.10, on ThinkPad W530.
>
> Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0
> [ThinkPad]
>
> T: Bus=01 Lev=02 Prnt=02 Port=03 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
> D: Ver= 2.00 Cls=ff(vend.
Lee Jones wrote:
>This patch contains some pretty basic clean-ups in probe() pertaining
>to
>the simplification of error handling and a couple of readability
>adaptions.
>
>Signed-off-by: Lee Jones
>---
>drivers/iio/pressure/st_pressure_core.c | 32
>
> 1 file cha
On 09/10/2013 10:48 AM, Javier Martinez Canillas wrote:
> On 09/10/2013 05:00 PM, Joel Fernandes wrote:
>> On 09/10/2013 08:17 AM, Javier Martinez Canillas wrote:
>>> On 09/10/2013 09:00 AM, Joel Fernandes wrote:
On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
> On 07/31/2013 01:44
Waiman's conversion of d_path() and bits related to it, kern_path_mountpoint(),
several cleanups and fixes (exportfs one is -stable fodder, IMO). There
definitely will be more... ;-/ Please, pull from the usual place -
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
Shortlog
BugLink: http://bugs.launchpad.net/bugs/1222850
This input device can get into a state that produces a high
volume of device status errors. Attempt to throttle these
error messages such that the kernel log is not flooded.
Cc: Dmitry Torokhov
Signed-off-by: Tim Gardner
---
drivers/input/misc/cm
On Tue, 2013-09-10 at 08:31 -0700, Linus Torvalds wrote:
>
> Don't be silly. Nobody wants an extra chip. Especially not one that is
> programmable separately from the hardware.
But if I've got device attached to pin 15 of a GPIO controller
, surely that has to be programmed separately from the
On Mon, 2013-09-09 at 18:32 +0400, Konstantin Khlebnikov wrote:
> Luiz Capitulino wrote:
> > I'm getting the following soft lockup:
> >
> > CPU: 6 PID: 2278 Comm: killall5 Tainted: GF3.11.0-rc7+ #1
> > Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> > 0099 88011fd8
Hello,
As you probably know, in the current Linux kernel there is a staging
driver for the RTL8187SE device (based on my older RTL8180/RTL8185
Linux driver), while there also a regular (not staging) driver
supporting older RTL8185 and RTL8180 devices
(net/wireless/rtl818x/rtl8180) .
As far as I c
On Tue, 2013-09-10 at 11:54 -0400, Adam Jackson wrote:
> Suspend isn't an error condition, and I'm sick of seeing this (and only
> this) on the console when I suspend with quiet boot enabled.
[]
> diff --git a/drivers/misc/mei/pci-me.c b/drivers/misc/mei/pci-me.c
[]
> @@ -262,7 +262,7 @@ static int
On Tue, Sep 10, 2013 at 05:26:31PM +0300, Mika Westerberg wrote:
> On Tue, Sep 10, 2013 at 01:27:54PM +0100, Mark Brown wrote:
> > > There is one difference though -- runtime PM is now blocked by default and
> > > it needs to be unblocked from the userspace per each device.
> > ...as you say.
>
On 08/30/2013 04:19 AM, Rajendra Nayak wrote:
> []..
>
>> +
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
>> +
>> +#ifdef DEBUG
>> +#define prn(num) printk(#num "=%d\n", num)
>> +#define prx(num) printk(#num "=%x\n", num)
>> +#else
>> +#define prn(num) do { } while (0)
>> +#define prx(num) do { }
On Tue, Sep 10, 2013 at 5:28 PM, Peter Zijlstra wrote:
> On Tue, Sep 10, 2013 at 07:15:19AM -0700, Stephane Eranian wrote:
>> The threshold is where to generate the interrupt. It does not mean
>> where to stop PEBS recording.
>
> It does, since we don't set a reset value. So once a PEBS assist
> h
On Tue, Sep 10, 2013 at 04:45:32PM +0100, Gustavo Padovan wrote:
> Hi Dan,
>
> 2013-09-03 Dan Aloni :
>
> > Tested with this patch and a Bluetooth mouse on 3.10.10, on ThinkPad W530.
> >
> > Bus 001 Device 004: ID 0a5c:21e6 Broadcom Corp. BCM20702 Bluetooth 4.0
> > [ThinkPad]
> >
> > T: Bus=0
Suspend isn't an error condition, and I'm sick of seeing this (and only
this) on the console when I suspend with quiet boot enabled.
Signed-off-by: Adam Jackson
---
drivers/misc/mei/pci-me.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/misc/mei/pci-me.c b/drivers/m
On Tue, Sep 10, 2013 at 8:43 AM, Stephen Warren wrote:
>
> x86 PCs likely have at least some of this exact same HW, e.g. I2C-based
> LM90 thermal sensors. However, I /think/ this all gets hidden from the
> OS by ACPI or other firmware mechanisms. Do you prefer firmware
> abstraction over DT?
If t
On 10 September 2013 20:14, wrote:
> From: Lan Tianyu
>
> The cpufreq_set_policy() has been removed by commit 632786c. So remove
> related comment.
> ---
> drivers/cpufreq/cpufreq.c | 4
> 1 file changed, 4 deletions(-)
I have got another patch that takes care of this while fixing other i
On Tue, 10 Sep 2013, Olof Johansson wrote:
> On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote:
> > Signed-off-by: Lee Jones
> > ---
> > arch/arm/configs/u8500_defconfig | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/arch/arm/configs/u8500_defconfig
> > b/arch/arm/configs/u8500_
On Tue, Sep 10, 2013 at 07:15:19AM -0700, Stephane Eranian wrote:
> The threshold is where to generate the interrupt. It does not mean
> where to stop PEBS recording.
It does, since we don't set a reset value. So once a PEBS assist
happens, that counter stops until we reprogram it in the PMI.
> S
Export Xen symbols to dom0 via /proc/xen/xensyms (similar to /proc/kallsyms).
Signed-off-by: Boris Ostrovsky
---
drivers/xen/Kconfig | 5 ++
drivers/xen/xenfs/Makefile | 1 +
drivers/xen/xenfs/super.c| 3 +
drivers/xen/xenfs/xenfs.h| 1 +
drivers/xen/xe
On Tue, Sep 10, 2013 at 8:05 AM, David Woodhouse wrote:
>
> In cost-sensitive products (and what *isn't* cost-sensitive these days),
> you really don't want to have to put an extra EEPROM on the board
> somewhere
Don't be silly. Nobody wants an extra chip. Especially not one that is
programmable
nfsd changes for 3.12 are available from
git://linux-nfs.org/~bfields/linux.git nfsd-next
This was a very quiet cycle! Just a few bugfixes and some cleanup.
--b.
Harshula Jayasuriya (2):
nfsd: nfs4_file_get_access: need t
Avoid trapping to hypervisor on each MSR access during interrupt handling.
Instead, use cached MSR values provided in shared xenpmu_data by Xen. When
handling is completed, flush the registers to hypervisor who will load them
into HW.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/pmu.c
PMU emulation code: MSR caching in PMU context and LVTPC APIC
handling. (Portions of this code are taken from Xen's VPMU
implementation)
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 27 +++-
arch/x86/xen/pmu.c | 289 -
a
On Tue, Sep 10, 2013 at 08:29:16AM -0700, Arjan van de Ven wrote:
> also.. yuck on using "dec" "dec" sucks, please use "sub foo ,1"
> instead (dec sucks because of its broken flags behavior; it creates
> basically a bubble in the pipeline)
Then someone needs to go change:
atomic{,64}_dec*()
This is the Linux side of Xen PMU support for PV guests, including dom0. Only
kernel changes are here, toolstack patch will be provided separately.
Here is description from the hypervisor patch submission that applies to this
series as well:
This version has following limitations:
* For accurate
Map shared data structure that will hold CPU registers, VPMU context,
VCPU/PCPI IDs of the VCPU interrupted by PMU interrupt. Hypervisor
fills this information in its handler and passes it to the guest for
further processing.
Set up PMU VIRQ.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/Make
Set Xen's PMU mode via /sys/hypervisor/pmu/pmu_mode. Add XENPMU hypercall.
Signed-off-by: Boris Ostrovsky
---
arch/x86/include/asm/xen/hypercall.h | 6 ++
arch/x86/xen/xen-head.S | 5 +-
drivers/xen/sys-hypervisor.c | 118 +++
include/xen/
On 9/10/2013 6:56 AM, Ingo Molnar wrote:
* Ingo Molnar wrote:
So what we do in kick_process() is:
preempt_disable();
cpu = task_cpu(p);
if ((cpu != smp_processor_id()) && task_curr(p))
smp_send_reschedule(cpu);
preempt_enable();
The preem
> On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote:
> > Turns out that they're actually not required and the driver probes just
> > fine without them. The ID is incorrect at the moment anyway. They actually
> > currently specify the stn8815.
> >
> > Signed-off-by: Lee Jones
>
> How did you test
On 10 September 2013 20:42, Guennadi Liakhovetski wrote:
> 4. reverted that commit, resolving a trivial conflict. Added a debug
> output in __cpufreq_driver_target() of
>
>
> if (cpufreq_disabled())
> return -ENODEV;
> + pr_info("%s() %d\n", __func__, policy->transiti
On Tue, Sep 10, 2013 at 07:02:51AM -0700, Eric Dumazet wrote:
> On Tue, 2013-09-10 at 15:08 +0200, Peter Zijlstra wrote:
>
> > +static __always_inline int preempt_count(void)
> > +{
> > + return __this_cpu_read_4(__preempt_count) & ~PREEMPT_NEED_RESCHED;
> > +}
>
> Not sure why you used the _4
Hi,
On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote:
> Turns out that they're actually not required and the driver probes just
> fine without them. The ID is incorrect at the moment anyway. They actually
> currently specify the stn8815.
>
> Signed-off-by: Lee Jones
How did you test this patch?
On Tue, Sep 10, 2013 at 05:09:57PM +0200, Markezana, William wrote:
> From: William Markezana
>
> hwmon: (ms5637) Add Measurement Specialties MS5637support
> Signed-off-by: William Markezana
Hi William,
"pressure" is hardly a hardware monitoring attribute. It might make more sense
to add your
On Tue, Sep 10, 2013 at 5:49 AM, Lee Jones wrote:
> Signed-off-by: Lee Jones
> ---
> arch/arm/configs/u8500_defconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/u8500_defconfig
> b/arch/arm/configs/u8500_defconfig
> index 6b29109..24f88d6 100644
> --- a/arch/arm/c
On Tue, Sep 10, 2013 at 05:58:02PM +0300, Dan Carpenter wrote:
> Btw, the de...@driverdev.osuosl.org list seems to be down again. I
> still have not recieved the v3 patch. Use the
> driverdev-de...@linuxdriverproject.org email list instead.
They are the same "list", just different DNS entries.
From: Lan Tianyu
The cpufreq_set_policy() has been removed by commit 632786c. So remove
related comment.
---
drivers/cpufreq/cpufreq.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 5c75e31..a504313 100644
--- a/drivers/cpufreq/
On Tue, 10 Sep 2013, Viresh Kumar wrote:
> On 9 September 2013 20:41, Guennadi Liakhovetski
> wrote:
> > Sorry guys, I'm trying my best to stop this patch from propagating to
> > stable and to get it fixed asap, so, the CC list might be a bit excessive.
> > Also trying to fix the originally spar
On Tue, Sep 10, 2013 at 03:56:36PM +0200, Ingo Molnar wrote:
> * Ingo Molnar wrote:
> > > * 8106f42a: 65 ff 0c 25 e0 b7 00decl %gs:0xb7e0
> > > 8106f431: 00
> > > * 8106f432: 0f 94 c0sete %al
> > > * 8106f435: 84 c
On Tue, Sep 10, 2013 at 01:31:41PM +0200, Stephan Mueller wrote:
> Hi,
>
> /dev/random uses the get_cycles() function to obtain entropy in addition to
> jiffies and the event value of hardware events.
>
> Typically the high-resolution timer of get_cycles delivers the majority of
> entropy, beca
On 09/10/2013 04:09 AM, Mark Brown wrote:
> On Mon, Sep 09, 2013 at 10:13:56PM -0600, Stephen Warren wrote:
>> On 09/09/2013 09:53 PM, Guenter Roeck wrote:
>
>>> Earlier comments suggest that this is not the intended use case
>>> for regulator_get_optional().
>
> That's right.
>
>> Isn't the iss
On Mon, 2013-09-09 at 16:49 -0700, Linus Torvalds wrote:
>
> Ok. I still really despise the absolute incredible sh*t that is
> non-discoverable buses, and I hope that ARM SoC hardware designers all
> die in some incredibly painful accident. DT only does so much.
Setting aside the inevitable whin
On 09/10/2013 05:18 AM, Laxman Dewangan wrote:
> The Turn-ON time of the regulator depends on the regulator device's
> electrical characteristics. Sometimes regulator turn-on time also
> depends on the capacitive load on the given platform and it can be
> more than the datasheet value.
>
> The dri
From: Lan Tianyu
The cpufreq_set_policy() has been removed by commit 632786c. So remove
related comment.
Signed-off-by: Lan Tianyu
---
Update: miss signed-off due to using my new script. Sorry for nosiy.
drivers/cpufreq/cpufreq.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers
On 09/10/2013 08:17 AM, Javier Martinez Canillas wrote:
> On 09/10/2013 09:00 AM, Joel Fernandes wrote:
>> On 07/31/2013 03:35 AM, Javier Martinez Canillas wrote:
>>> On 07/31/2013 01:44 AM, Linus Walleij wrote:
On Tue, Jul 30, 2013 at 6:30 AM, Grant Likely
wrote:
> On Mon, Jul 29,
On 10 September 2013 17:19, Rafael J. Wysocki wrote:
> That said I'm actually unsure what problems *exactly* are fixed by commit
> 7c30ed5. The commit log only says that PRECHANGE or POSTCHAGE shouldn't be
> called twice in a row, but it doesn't say why. As the fallout indicates,
> that actually
On Fri, Aug 09, 2013 at 01:21:42AM -0400, Naoya Horiguchi wrote:
> Now we have extended hugepage migration and it's opened to many users
> of page migration, which is a good reason to consider hugepage as movable.
> So we can go to the direction to remove this parameter. In order to
> allow userspa
Btw, the de...@driverdev.osuosl.org list seems to be down again. I
still have not recieved the v3 patch. Use the
driverdev-de...@linuxdriverproject.org email list instead.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On 09/08/2013 10:39 PM, Joonsoo Kim wrote:
On Sun, Sep 08, 2013 at 10:46:00AM -0400, Sasha Levin wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest, running latest -next
kernel, I've
stumbled on the following:
[ 998.281867] BUG: unable to handle kernel NULL pointer dereferenc
Hi,
On Tue, 2013-09-10 at 08:59 -0500, Josh Cartwright wrote:
> [Hmm. Fixing b0rked LKML address; that might explain why I am not
> seeing Kumar's replies.]
>
Yes, sorry about this.
> On Tue, Sep 10, 2013 at 03:08:57PM +0300, Ivan T. Ivanov wrote:
> > Hi Kumar,
> >
> > On Fri, 2013-08-30 at
On Fri, Aug 09, 2013 at 01:21:38AM -0400, Naoya Horiguchi wrote:
> This patch extends do_mbind() to handle vma with VM_HUGETLB set.
> We will be able to migrate hugepage with mbind(2) after
> applying the enablement patch which comes later in this series.
>
> ChangeLog v3:
> - revert introducing
On (09/09/13 18:10), Jerome Marchand wrote:
> On 09/09/2013 03:46 PM, Jerome Marchand wrote:
> > On 09/09/2013 03:21 PM, Dan Carpenter wrote:
> >> On Mon, Sep 09, 2013 at 03:49:42PM +0300, Sergey Senozhatsky wrote:
> > Calling handle_pending_slot_free() for every RW operation may
> > cause
On Tue, Sep 10, 2013 at 7:29 AM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> On Tue, Sep 10, 2013 at 6:38 AM, Ingo Molnar wrote:
>> >
>> > * Stephane Eranian wrote:
>> >
>> >> Hi,
>> >>
>> >> Ok, so I am able to reproduce the problem using a simpler
>> >> test case with a simple multi
On Fri, Aug 09, 2013 at 01:21:36AM -0400, Naoya Horiguchi wrote:
> This patch extends check_range() to handle vma with VM_HUGETLB set.
> We will be able to migrate hugepage with migrate_pages(2) after
> applying the enablement patch which comes later in this series.
>
> Note that for larger hugepa
On 09/10/2013 03:38 AM, farisdeh...@gmail.com wrote:
From: Faris de Haan
Fixed a few of the coding style issues reported by checkpatch.pl
Signed-off-by: Faris de Haan
---
drivers/staging/rtl8188eu/core/rtw_wlan_util.c | 22 +++---
1 file changed, 11 insertions(+), 11 dele
* Stephane Eranian wrote:
> On Tue, Sep 10, 2013 at 6:38 AM, Ingo Molnar wrote:
> >
> > * Stephane Eranian wrote:
> >
> >> Hi,
> >>
> >> Ok, so I am able to reproduce the problem using a simpler
> >> test case with a simple multithreaded program where
> >> #threads >> #CPUs.
> >
> > Does it go
This information can be found in /lib/modules/`uname -r`/modules.softdep, and
has only recently been exported by the kernel.
Also remove the advice about copying modules.softdep to /lib/modules as it is
not clear how to do this correctly with several kernels installed with
potentially conflicting
* Jan Beulich wrote:
> >>> On 10.09.13 at 15:42, Ingo Molnar wrote:
>
> > * Peter Zijlstra wrote:
> >
> >> + .macro SAVE_ALL
> >> + pushl_cfi %eax
> >> + CFI_REL_OFFSET eax, 0
> >> + pushl_cfi %ebp
> >> + CFI_REL_OFFSET ebp, 0
> >> + pushl_cfi %edi
> >> + CFI_REL_OFFSET edi, 0
> >> +
On Tue, 2013-09-10 at 17:21 +0300, Jani Nikula wrote:
> On Tue, 10 Sep 2013, Matthew Garrett wrote:
> > On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
> >
> >> I think the parameter "Does the ACPI backlight interface work or not"
> >> belongs to the ACPI video driver.
> >
> > That depends o
On Tue, Sep 10, 2013 at 01:27:54PM +0100, Mark Brown wrote:
> On Tue, Sep 10, 2013 at 10:51:00AM +0300, Mika Westerberg wrote:
> > On Mon, Sep 09, 2013 at 04:40:28PM +0100, Mark Brown wrote:
>
> > > How is this going to interact with client devices which are already
> > > enabling runtime PM for t
On Tue, 10 Sep 2013, Matthew Garrett wrote:
> On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
>
>> I think the parameter "Does the ACPI backlight interface work or not"
>> belongs to the ACPI video driver.
>
> That depends on how Windows 8 works. If Windows 8 policy is handled by
> the GPU d
We kmalloc auxbuf but fail to kfree it if we get errors in various places.
Rework the error paths to avoid the resource leak.
Signed-off-by: Josh Boyer
---
fs/cachefiles/xattr.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/fs/cachefiles/xattr.c b/
On Tue, Sep 10, 2013 at 4:01 PM, Lucas De Marchi
wrote:
> On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu
> wrote:
>> On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote:
>>> Herbert Xu writes:
>>> > Hi Rusty:
>>> >
>>> > I don't know why this patch never went into the kernel, even
>>> >
Hi Linus,
The following changes since commit b936bf8b785f0fbe083d203049e4da1c56ec788f:
dm cache: avoid conflicting remove_mapping() in mq policy (2013-08-16
15:56:51 -0400)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm.git
tag
From: Namjae Jeon
v6: In v3 of the patch we released the allocated clutsers in
fat_file_release on the basis of d_count. Moving this from fat_file_release
to fat_evict_inode and on the basis of i_count , so that allocated
clusters are released at the last refrence of the inode when inode
evicts f
On Tue, Sep 10, 2013 at 6:38 AM, Ingo Molnar wrote:
>
> * Stephane Eranian wrote:
>
>> Hi,
>>
>> Ok, so I am able to reproduce the problem using a simpler
>> test case with a simple multithreaded program where
>> #threads >> #CPUs.
>
> Does it go away if you use 'perf record --all-cpus'?
>
Haven'
On Sat, Sep 07, 2013 at 10:44:00PM +0200, Toralf Förster wrote:
> Today I run latest git tree with a patched UML (this patch + one for xterm
> issues) and got 2 times a core dump
> when I fuzzy test an UML machine with a nearly identical scenario as already
> described but just shutdowned
> both
On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu
wrote:
> On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote:
>> Herbert Xu writes:
>> > Hi Rusty:
>> >
>> > I don't know why this patch never went into the kernel, even
>> > though the corresponding features have been added to modprobe
>> >
On Tue, 2013-09-10 at 15:08 +0200, Peter Zijlstra wrote:
> +static __always_inline int preempt_count(void)
> +{
> + return __this_cpu_read_4(__preempt_count) & ~PREEMPT_NEED_RESCHED;
> +}
Not sure why you used the _4 prefix on all accessors ?
>
> +#ifdef CONFIG_PREEMPT_COUNT
> + /*
> +
On 09/09, Eric W. Biederman wrote:
>
> Oleg Nesterov writes:
> >
> > Agreed, it also makes sense to clear ->nr_hashed. But I still think
> > that WARN_ON(ns->child_reaper) makes sense too.
>
> I don't know that I like warnings for impossible conditions.
But WARN_ON() should only check for "imposs
"case 0" in free_pid() assumes that disable_pid_allocation() should
clear PIDNS_HASH_ADDING before the last pid goes away. However this
doesn't happen if the 1st fork() fails to create the child reaper
which should call disable_pid_allocation().
Signed-off-by: Oleg Nesterov
---
kernel/pid.c |
[Hmm. Fixing b0rked LKML address; that might explain why I am not
seeing Kumar's replies.]
On Tue, Sep 10, 2013 at 03:08:57PM +0300, Ivan T. Ivanov wrote:
> Hi Kumar,
>
> On Fri, 2013-08-30 at 10:21 -0500, Kumar Gala wrote:
> > On Aug 29, 2013, at 12:26 PM, Ivan T. Ivanov wrote:
> > >>> +
> > >
Dmitry Torokhov wrote:
> On Thu, Aug 15, 2013 at 04:55:57PM +0100, Nick Dyer wrote:
>> rydb...@euromail.se wrote:
>>> First: thanks for the patches and you work on this driver.
>>
>> Thank you for your time in looking at these changes.
>>
>>> Now, I don't swear much, but I would like to emphasize l
On Tue, 2013-09-10 at 16:53 +0300, Jani Nikula wrote:
> I think the parameter "Does the ACPI backlight interface work or not"
> belongs to the ACPI video driver.
That depends on how Windows 8 works. If Windows 8 policy is handled by
the GPU drivers then it belongs in i915. If it's handled by the
>From 4675ca3470e3c2e325c5be6d9a11f47ac0917537 Mon Sep 17 00:00:00 2001
From: Eric Paris
Date: Tue, 10 Sep 2013 09:51:50 -0400
Subject: [PATCH] security: remove erroneous comment about capabilities.o link
ordering
Back when we had half ass LSM stacking we had to link capabilities.o
after bigger
On Tue, 2013-09-10 at 12:31 +0900, Yasuaki Ishimatsu wrote:
> (2013/09/10 9:24), Toshi Kani wrote:
:
> > diff --git a/kernel/cpu.c b/kernel/cpu.c
> > index d7f07a2..c10b285 100644
> > --- a/kernel/cpu.c
> > +++ b/kernel/cpu.c
> > @@ -420,11 +420,6 @@ int cpu_up(unsigned int cpu)
> > {
> > in
On 09/10/2013 10:47 AM, Lars Poeschel wrote:
> On Tuesday 10 September 2013 17:19:24, Mark Brown wrote:
>> On Wed, Sep 04, 2013 at 02:16:36PM -0600, Stephen Warren wrote:
>> > On 09/04/2013 03:05 AM, Lars Poeschel wrote:
>> > > The driver that tries to use the GPIO requested by this patch before HA
* Ingo Molnar wrote:
> So what we do in kick_process() is:
>
> preempt_disable();
> cpu = task_cpu(p);
> if ((cpu != smp_processor_id()) && task_curr(p))
> smp_send_reschedule(cpu);
> preempt_enable();
>
> The preempt_disable() looks sweet:
>
>
>>> On 10.09.13 at 15:42, Ingo Molnar wrote:
> * Peter Zijlstra wrote:
>
>> +.macro SAVE_ALL
>> +pushl_cfi %eax
>> +CFI_REL_OFFSET eax, 0
>> +pushl_cfi %ebp
>> +CFI_REL_OFFSET ebp, 0
>> +pushl_cfi %edi
>> +CFI_REL_OFFSET edi, 0
>> +pushl_cfi %esi
>> +CFI_REL_
* Peter Zijlstra wrote:
> These patches optimize preempt_enable by firstly folding the preempt and
> need_resched tests into one -- this should work for all architectures. And
> secondly by providing per-arch preempt_count implementations; with x86 using
> per-cpu preempt_count for fastest acces
On Mon, 09 Sep 2013, "Rafael J. Wysocki" wrote:
> On Monday, September 09, 2013 05:21:18 PM Daniel Vetter wrote:
>> On Mon, Sep 09, 2013 at 02:16:12PM +0200, Rafael J. Wysocki wrote:
>> > Hi,
>> >
>> > On Monday, September 09, 2013 11:32:10 AM Daniel Vetter wrote:
>> > > Hi Aaaron,
>> > >
>> > >
On Fri, Aug 09, 2013 at 01:21:34AM -0400, Naoya Horiguchi wrote:
> Before enabling each user of page migration to support hugepage,
> this patch enables the list of pages for migration to link not only
> LRU pages, but also hugepages. As a result, putback_movable_pages()
> and migrate_pages() can h
On Tue, Sep 10, 2013 at 02:35:27PM +0800, Libin wrote:
> From: Li Bin
>
> There is a redundant call for timer_stats_timer_set_start_info(),
> because it is the responsibility of the 'timer add' function:
>
> add_timer_on()
> |- timer_stats_timer_set_start_info()
>
> add_timer()
> |- mod_timer()
* Peter Zijlstra wrote:
> + .macro SAVE_ALL
> + pushl_cfi %eax
> + CFI_REL_OFFSET eax, 0
> + pushl_cfi %ebp
> + CFI_REL_OFFSET ebp, 0
> + pushl_cfi %edi
> + CFI_REL_OFFSET edi, 0
> + pushl_cfi %esi
> + CFI_REL_OFFSET esi, 0
> + pushl_cfi %edx
> + CFI_R
On 09/10/2013 02:13 AM, Marek Szyprowski wrote:
It is not needed to include asm/dma-contiguous.h header to compile
reserved memory initialization code, so remove it to avoid build break
on architectures without CMA support.
Signed-off-by: Marek Szyprowski
Tested-by: Guenter Roeck
---
dri
On Tue, 2013-09-10 at 09:50 +0800, Joe Jin wrote:
> On 09/09/13 21:41, Christoph Hellwig wrote:
> >> Modules linked in: oracleacfs(P)(U) oracleadvm(P)(U) oracleoks(P)(U)
> >
> > Please reproduce without this weird crap loaded.
> >
> These modules is filesystem and will not impact enclosure.
That
* Stephane Eranian wrote:
> Hi,
>
> Ok, so I am able to reproduce the problem using a simpler
> test case with a simple multithreaded program where
> #threads >> #CPUs.
Does it go away if you use 'perf record --all-cpus'?
> [ 2229.021934] WARNING: CPU: 6 PID: 17496 at
> arch/x86/kernel/cpu/pe
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git
tags/mmc-updates-for-3.12-rc1
to receive the MMC merge for 3.12. There are currently no conflicts,
and these patches have been tested in linux-next. Thanks.
The following changes since commit bfffbea1aae
Avoid unnecessary casts from int to bool in smp functions. Some
functions in kernel/smp.c have a wait parameter that can be set to one
if you want to wait for the command to complete. It's defined as bool
in a few of them and int in the rest. If a function with wait
declared as int calls a funct
601 - 700 of 938 matches
Mail list logo