On Wed, Sep 11, 2013 at 09:41:18PM +0200, azurIt wrote:
> >On Wed, Sep 11, 2013 at 08:54:48PM +0200, azurIt wrote:
> >> >On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote:
> >> >> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
> >> >> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200,
On Wed, Sep 11, 2013 at 12:56 PM, Benjamin Tissoires
wrote:
> When working on report indexes, always validate that they are in bounds.
> Without this, a HID device could report a malicious feature report that
> could trick the driver into a heap overflow:
>
> [ 634.885003] usb 1-1: New USB
On Wed, Sep 11, 2013 at 12:56 PM, Benjamin Tissoires
wrote:
> Hi guys,
>
> here is the v3 of the CVE fixes.
>
> I have tested the multitouch and logitech-dj part, and the lenovo-tpkbd has
> been
> tested in the bug referenced in patch 10.
>
> Cheers,
> Benjamin
>
> Changes since v2:
> - fix
From: Kees Cook
A HID device could send a malicious output report that would cause the
steelseries HID driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 167.981534] usb 1-1: New USB device found, idVendor=1038, idProduct=1410
...
[
From: Michael Opdenacker
Date: Sat, 7 Sep 2013 07:20:57 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/korina.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker
Applied.
--
To unsubscribe from this
On 09/10/2013 06:52 PM, Javier Martinez Canillas wrote:
> On 09/11/2013 12:34 AM, Stephen Warren wrote:
>> On 09/10/2013 03:37 PM, Mark Brown wrote:
>>> On Tue, Sep 10, 2013 at 01:53:47PM -0600, Stephen Warren wrote:
>>>
Doesn't this patch call gpio_request() on the GPIO first, and
hence
We can use the devres API in hid modules, so use it to avoid some kfree
and potential leaks.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/hid-lenovo-tpkbd.c | 30 --
1 file changed, 8 insertions(+), 22 deletions(-)
diff --git a/drivers/hid/hid-lenovo-tpkbd.c
From: Kees Cook
A HID device could send a malicious output report that would cause the
logitech-dj HID driver to leak kernel memory contents to the device, or
trigger a NULL dereference during initialization:
[ 304.424553] usb 1-1: New USB device found, idVendor=046d, idProduct=c52b
...
[
From: Kees Cook
From: Kees Cook
A HID device could send a malicious output report that would cause the
lenovo-tpkbd HID driver to write just beyond the output report allocation
during initialization, causing a heap overflow:
[ 76.109807] usb 1-1: New USB device found, idVendor=17ef,
In __cpufreq_remove_dev_prepare(), the code which decides whether to remove
the sysfs link or nominate a new policy cpu, is governed by an if/else block
with a rather complex set of conditionals. Worse, they harbor a subtlety
which leads to certain unintended behavior.
The code looks like this:
From: Kees Cook
A HID device could send a malicious output report that would cause the
lg, lg3, and lg4 HID drivers to write beyond the output report allocation
during an event, causing a heap overflow:
[ 325.245240] usb 1-1: New USB device found, idVendor=046d, idProduct=c287
...
[
On 09/11/2013 09:37 PM, Jiang Liu wrote:
> From: Jiang Liu
>
> Commit 9a46ad6d6df3b54 "smp: make smp_call_function_many() use logic
> similar to smp_call_function_single()" has unified the way to handle
> single and multiple cross-CPU function calls. Now only one interrupt
> is needed for
From: Kees Cook
This driver must validate the availability of the HID output report and
its size before it can write LED states via buzz_set_leds(). This stops
a heap overflow that is possible if a device provides a malicious HID
output report:
[ 108.171280] usb 1-1: New USB device found,
On 09/12/2013 12:33 AM, Stephen Warren wrote:
> On 09/11/2013 12:42 PM, Srivatsa S. Bhat wrote:
> ...
>> OK, I took a second look at the code, and I suspect that applying the
>> second patch might help. So can you try by applying both the patches
>> please[1][2]?
>>
> ...
>> [1].
On 09/12/2013 01:37 AM, Stephen Warren wrote:
> On 09/11/2013 01:46 PM, Srivatsa S. Bhat wrote:
>> On 09/12/2013 12:33 AM, Stephen Warren wrote:
>>> On 09/11/2013 12:42 PM, Srivatsa S. Bhat wrote:
>>> ...
OK, I took a second look at the code, and I suspect that applying the
second patch
On Wed, Sep 11, 2013 at 03:14:52PM -0400, Steven Rostedt wrote:
> On Wed, 11 Sep 2013 14:56:54 -0400
> Konrad Rzeszutek Wilk wrote:
>
>
> > > I'm looking to NAK your patch because it is obvious that the jump label
> > > code isn't doing what you expect it to be doing. And it wasn't until my
> >
On Wed, 2013-09-11 at 12:25 -0700, Kees Cook wrote:
> On Wed, Sep 11, 2013 at 12:09 PM, Joe Perches wrote:
> > On Wed, 2013-09-11 at 11:19 -0700, Kees Cook wrote:
> >> On Wed, Sep 11, 2013 at 2:31 AM, Dan Carpenter
> >> wrote:
> >> > On Tue, Sep 10, 2013 at 10:19:17PM -0700, Kees Cook wrote:
>
Hi Jiri,
Well, while debugging hid-lenovo-tpkbd, I also cleaned it up a little (so this
goes on top of the CVE series):
- use devres API
- remove usb references (so that the regressions tests through uhid are working)
This has also been tested by
From: Kees Cook
The zeroplus HID driver was not checking the size of allocated values
in fields it used. A HID device could send a malicious output report
that would cause the driver to write beyond the output report allocation
during initialization, causing a heap overflow:
[ 1442.728680] usb
On Wed, 2013-09-11 at 13:18 -0700, Kees Cook wrote:
> On Wed, Sep 11, 2013 at 1:06 PM, Joe Perches wrote:
> > On Wed, 2013-09-11 at 12:30 -0700, Kees Cook wrote:
> >> The %n format is not ignored, so remove the incorrect comment about it.
> >
> > I think it may be better to reimplement the
When working on report indexes, always validate that they are in bounds.
Without this, a HID device could report a malicious feature report that
could trick the driver into a heap overflow:
[ 634.885003] usb 1-1: New USB device found, idVendor=0596, idProduct=0500
...
[ 676.469629] BUG
On Wed, 2013-09-11 at 12:30 -0700, Kees Cook wrote:
> The %n format is not ignored, so remove the incorrect comment about it.
I think it may be better to reimplement the ignoring.
Maybe:
---
lib/vsprintf.c | 18 +---
net/ipv4/fib_trie.c | 30 +--
net/ipv4/ping.c
On Wed, 11 Sep 2013, Michal Hocko wrote:
> On Wed 11-09-13 08:40:57, Anton Vorontsov wrote:
> > On Mon, Sep 09, 2013 at 01:08:47PM +0200, Michal Hocko wrote:
> > > On Fri 06-09-13 22:59:16, Hugh Dickins wrote:
> > > > Hit divide-by-0 in vmpressure_work_fn(): checking vmpr->scanned before
> > > >
> -Original Message-
> From: Wei Yongjun [mailto:weiyj...@gmail.com]
> Sent: Wednesday, September 11, 2013 4:20 AM
> To: KY Srinivasan; Haiyang Zhang
> Cc: yongjun_...@trendmicro.com.cn; de...@linuxdriverproject.org; linux-
> ker...@vger.kernel.org
> Subject: [PATCH] Drivers: hv: vmbus:
This patch adds support for the Silicon Labs CP2112
"Single-Chip HID USB to SMBus Master Bridge."
I wrote this to support a USB temperature and humidity
sensor I've been working on. It's been tested by using
SMBus byte-read, byte-data-read/write, and word-data-read
transfer modes to talk to an
If tpkbd_probe_tp() bails out, the probe() function return an error,
but hid_hw_stop() is never called.
fixes:
https://bugzilla.redhat.com/show_bug.cgi?id=1003998
Cc: sta...@vger.kernel.org
Signed-off-by: Benjamin Tissoires
---
v3:
- new patch
drivers/hid/hid-lenovo-tpkbd.c | 15
When dealing with usage_index, be sure to properly use unsigned instead of
int to avoid overflows.
When working on report fields, always validate that their report_counts are
in bounds.
Without this, a HID device could report a malicious feature report that
could trick the driver into a heap
On Wed, Sep 11, 2013 at 06:26:25PM +0100, Al Viro wrote:
> On Wed, Sep 11, 2013 at 12:33:35PM -0400, Waiman Long wrote:
>
> > >Folks, any suggestions on better names? The semantics we are getting is
> >
> > I will welcome any better name suggestion and will incorporate that
> > in the patch.
>
On 09/11/2013 12:42 PM, Srivatsa S. Bhat wrote:
...
> OK, I took a second look at the code, and I suspect that applying the
> second patch might help. So can you try by applying both the patches
> please[1][2]?
>
...
> [1]. http://marc.info/?l=linux-kernel=137889516210816=2
> [2].
>On Wed, Sep 11, 2013 at 08:54:48PM +0200, azurIt wrote:
>> >On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote:
>> >> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
>> >> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote:
>> >> >> >> >On Tue, Sep 10, 2013 at 09:32:53PM
On 9/11/13 11:49 AM, Eric Sandeen wrote:
> On 9/11/13 6:30 AM, Theodore Ts'o wrote:
>> On Tue, Sep 10, 2013 at 10:13:16PM -0500, Eric Sandeen wrote:
>>>
>>> Above doesn't tell us the prevalence of various contexts on the actual
>>> system,
>>> but they are all under 100 bytes in any case.
>>
>>
On Mon, Sep 09, 2013 at 10:47:01AM -0700, Andy Lutomirski wrote:
>
> I think that coming up with something that's both non-POSIX and
> half-arsed is a bad idea, but doing something that's non-POSIX and
> well thought-through could be valuable.
I know Harlan Stenn of the Network Time Foundation
On Wed, 11 Sep 2013 21:48:39 +0300
Sergey Senozhatsky wrote:
> On (09/11/13 12:13), Steven Rostedt wrote:
> > On Wed, 11 Sep 2013 09:00:16 -0700
> > Greg KH wrote:
> >
> > > On Wed, Sep 11, 2013 at 05:36:29PM +0300, Sergey Senozhatsky wrote:
> > > > This one on top of stable 3.6.11 git.
> > >
Hello.
On 09/09/2013 03:39 AM, Marc Weber wrote:
1) VER3 and _MAX are of same size:
#define NV_PCI_REGSZ_VER3 0x604
#define NV_PCI_REGSZ_MAX0x604
2) It looks like there is a case where VER3 get's assigned to
register_size:
if (id->driver_data &
* John Stultz (john.stu...@linaro.org) wrote:
> On 09/11/2013 08:12 AM, Mathieu Desnoyers wrote:
> > LTTng uses ktime to have the same time-base across kernel and
> > user-space, so traces gathered from LTTng-modules and LTTng-UST can be
> > correlated. We plan on using ktime until a fast,
On 09/11/2013 05:19 AM, Bill Huang wrote:
> Re-model Tegra cpufreq driver to support all Tegra series of SoCs.
>
> * Make tegra-cpufreq.c a generic Tegra cpufreq driver.
> * Move Tegra20 specific codes into tegra20-cpufreq.c.
> * Bind Tegra cpufreq dirver with a fake device so defer probe would
On Wed, Sep 11, 2013 at 12:09 PM, Joe Perches wrote:
> On Wed, 2013-09-11 at 11:19 -0700, Kees Cook wrote:
>> On Wed, Sep 11, 2013 at 2:31 AM, Dan Carpenter
>> wrote:
>> > On Tue, Sep 10, 2013 at 10:19:17PM -0700, Kees Cook wrote:
>> >> In the former case, format characters will get processed
[+cc dri-devel]
On 09/11/2013 11:38 AM, Steven Rostedt wrote:
On Wed, 11 Sep 2013 11:16:43 -0400
Peter Hurley wrote:
The funny part is, there's a comment there that shows that this was
done even for "PREEMPT_RT". Unfortunately, the call to
"get_scanout_position()" can call functions that use
The %n format is not ignored, so remove the incorrect comment about it.
Signed-off-by: Kees Cook
---
lib/vsprintf.c |1 -
1 file changed, 1 deletion(-)
diff --git a/lib/vsprintf.c b/lib/vsprintf.c
index 26559bd..d25d1f8 100644
--- a/lib/vsprintf.c
+++ b/lib/vsprintf.c
@@ -1576,7 +1576,6 @@
This of course has been a long-running debate. Similarly, we could make much
better use of RDRAND if instead of doing data reduction in rngd we could feed
it to the pool and just credit fractional bits. The FIPS tests that rngd runs
are weak and obsoleted, but perhaps better than nothing (now
> * %n is ignored
Really it should trigger a WARN_ON_ONCE(). There is code like
show_console_dev() which relies on it to work. If we ignore %n it
causes another bug.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
(9/3/13 4:39 AM), Janani Venkataraman wrote:
Hello,
We are working on an infrastructure to create a system core file of a specific
process at run-time, non-disruptively. It can also be extended to a case where
a process is able to take a self-core dump.
gcore, an existing utility creates a
On Wed, Sep 11, 2013 at 12:22 PM, Dan Carpenter
wrote:
> On Wed, Sep 11, 2013 at 11:19:11AM -0700, Kees Cook wrote:
>> On Wed, Sep 11, 2013 at 2:31 AM, Dan Carpenter
>> wrote:
>> > On Tue, Sep 10, 2013 at 10:19:17PM -0700, Kees Cook wrote:
>> >> In the former case, format characters will get
On Wed, 2013-09-11 at 10:49 -0700, Andy Lutomirski wrote:
> On Wed, Sep 11, 2013 at 10:22 AM, David Safford wrote:
> >>On 09/09/2013 02:11 PM, H. Peter Anvin wrote:
>
> A TPM that has an excellent internal entropy source and is FIPS 140-2
> compliant with no bugs whatsoever may still use
On 11.09.13 20:35, Steven Rostedt wrote:
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner wrote:
That said, maybe preempt_disable is no longer the optimal choice there
and there's some better way to achieve good protection against
interruptions of that bit of code? My knowledge here is a
On Wed, Sep 11, 2013 at 10:00 PM, Felipe Balbi wrote:
> On Wed, Sep 11, 2013 at 09:48:13PM +0300, Alexey Pelykh wrote:
>> On Wed, Sep 11, 2013 at 9:38 PM, Felipe Balbi wrote:
>> > Hi,
>> >
>> > On Wed, Sep 11, 2013 at 09:22:26AM +0300, Alexey Pelykh wrote:
>> >> Hi Felipe,
>> >>
>> >> Thanks for
On Wed, 2013-09-11 at 11:19 -0700, Kees Cook wrote:
> On Wed, Sep 11, 2013 at 2:31 AM, Dan Carpenter
> wrote:
> > On Tue, Sep 10, 2013 at 10:19:17PM -0700, Kees Cook wrote:
> >> In the former case, format characters will get processed by the
> >> sprintf logic. In the latter, they are printed
On Wed, Sep 11, 2013 at 2:45 PM, Theodore Ts'o wrote:
> We should definitely do this. If the TPM driver could fetch some
> randomness and then call add_device_randomness() to feed this into the
> random driver's entropy pool when it initializes itself, that would be
> ***really*** cool.
rngd
On Wed, Sep 11, 2013 at 11:19:11AM -0700, Kees Cook wrote:
> On Wed, Sep 11, 2013 at 2:31 AM, Dan Carpenter
> wrote:
> > On Tue, Sep 10, 2013 at 10:19:17PM -0700, Kees Cook wrote:
> >> In the former case, format characters will get processed by the
> >> sprintf logic. In the latter, they are
On Wed, Sep 11, 2013 at 12:06 PM, Jeff Garzik wrote:
> On Wed, Sep 11, 2013 at 2:45 PM, Theodore Ts'o wrote:
>> We should definitely do this. If the TPM driver could fetch some
>> randomness and then call add_device_randomness() to feed this into the
>> random driver's entropy pool when it
On Wed, Sep 11, 2013 at 08:54:48PM +0200, azurIt wrote:
> >On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote:
> >> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
> >> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote:
> >> >> >> >On Tue, Sep 10, 2013 at 09:32:53PM +0200,
On Wed, Sep 11, 2013 at 09:48:13PM +0300, Alexey Pelykh wrote:
> On Wed, Sep 11, 2013 at 9:38 PM, Felipe Balbi wrote:
> > Hi,
> >
> > On Wed, Sep 11, 2013 at 09:22:26AM +0300, Alexey Pelykh wrote:
> >> Hi Felipe,
> >>
> >> Thanks for finding this issue. Indeed, there is a bug on 3M+ baud
> >>
>On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote:
>> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
>> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote:
>> >> >> >On Tue, Sep 10, 2013 at 09:32:53PM +0200, azurIt wrote:
>> >> >> >> Here is full kernel log between 6:00 and
On Wed, Sep 11, 2013 at 10:49:59AM -0700, Andy Lutomirski wrote:
>
> A TPM that has an excellent internal entropy source and is FIPS 140-2
> compliant with no bugs whatsoever may still use Dual_EC_DRBG, which
> looks increasingly likely to be actively malicious.
To be fair, given the limited CPU
On Wed, Sep 11, 2013 at 02:26:44PM -0400, Steven Rostedt wrote:
> On Wed, 11 Sep 2013 14:01:13 -0400
> Konrad Rzeszutek Wilk wrote:
>
>
> >
> >
> > I am thins would still work:
> >
> >
> > 47 static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
> >
> > 148 {
On Wed, 11 Sep 2013 14:56:54 -0400
Konrad Rzeszutek Wilk wrote:
> > I'm looking to NAK your patch because it is obvious that the jump label
> > code isn't doing what you expect it to be doing. And it wasn't until my
>
> Actually it is OK. They need to be enabled before the SMP code kicks in.
>
On Wed, Sep 11, 2013 at 02:40:38PM -0400, J. Bruce Fields wrote:
> On Wed, Sep 11, 2013 at 06:26:25PM +0100, Al Viro wrote:
> > On Wed, Sep 11, 2013 at 12:33:35PM -0400, Waiman Long wrote:
> >
> > > >Folks, any suggestions on better names? The semantics we are getting is
> > >
> > > I will
On 09/11/2013 11:33 PM, Srivatsa S. Bhat wrote:
> On 09/11/2013 09:35 PM, Stephen Warren wrote:
>> On 09/11/2013 04:21 AM, Srivatsa S. Bhat wrote:
>>> On 09/11/2013 04:04 AM, Rafael J. Wysocki wrote:
On Tuesday, September 10, 2013 02:53:01 PM Stephen Warren wrote:
> On 09/09/2013 05:14
On Wed, Sep 11, 2013 at 08:33:21AM -0700, Linus Torvalds wrote:
> An excessively complex macro that makes the arguments trivially
> simpler is not worth it.
OK, stripped it down further, I couldn't quite see how to collapse the
unary and binary operator variants though :/
---
On Wed, 11 Sep 2013 21:07:10 +0200
Mario Kleiner wrote:
>
>
> On 11.09.13 20:35, Steven Rostedt wrote:
> > On Wed, 11 Sep 2013 20:29:07 +0200
> > Mario Kleiner wrote:
> >
> >> That said, maybe preempt_disable is no longer the optimal choice there
> >> and there's some better way to achieve
* John Stultz (john.stu...@linaro.org) wrote:
> On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
[...]
Now focusing on features (the fix discussion is in a separate
sub-thread):
>
> > LTTng uses ktime to have the same time-base across kernel and
> > user-space, so traces gathered from
On Thu, Aug 29 2013, Joe Perches wrote:
> Use the helper function instead of __GFP_ZERO.
Applied.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
>+ /* buffer range for efivars */
>+ case 1000 ... 2000:
>+ cmpr = 56;
>+ break;
> Seiji: let me know how the efivars tests go.
efivars works fine.
Uncompressed size about 1800 bytes. It matches the value of cmpr, 56.
Please feel free to add my "Tested-by"
On 09/11/2013 05:19 AM, Bill Huang wrote:
> Remove inclustion of the not needed header files and remove the logic
> to check the CPU ID to not exceeding the maximum supported CPUs.
> diff --git a/drivers/cpufreq/tegra-cpufreq.c b/drivers/cpufreq/tegra-cpufreq.c
> - * Copyright (C) 2010 Google,
On Wed, Sep 11, 2013 at 10:09 AM, Wei Yongjun wrote:
> From: Wei Yongjun
>
> The dereference to 'pdata' should be moved below the NULL test.
>
> Signed-off-by: Wei Yongjun
Acked-by: Rob Clark
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>
On Wed, Sep 11, 2013 at 9:38 PM, Felipe Balbi wrote:
> Hi,
>
> On Wed, Sep 11, 2013 at 09:22:26AM +0300, Alexey Pelykh wrote:
>> Hi Felipe,
>>
>> Thanks for finding this issue. Indeed, there is a bug on 3M+ baud
>> rates. First patch is close to a complete fix, but still contains
>> div-by-zero
On (09/11/13 12:13), Steven Rostedt wrote:
> On Wed, 11 Sep 2013 09:00:16 -0700
> Greg KH wrote:
>
> > On Wed, Sep 11, 2013 at 05:36:29PM +0300, Sergey Senozhatsky wrote:
> > > This one on top of stable 3.6.11 git.
> >
> > What do you mean by this?
> >
I thought it was for linux-3.6.y stable
Hi,
On Wed, Sep 11, 2013 at 09:22:26AM +0300, Alexey Pelykh wrote:
> Hi Felipe,
>
> Thanks for finding this issue. Indeed, there is a bug on 3M+ baud
> rates. First patch is close to a complete fix, but still contains
> div-by-zero issue. Here is my version:
>
> diff --git
On Wed, 11 Sep 2013 20:29:07 +0200
Mario Kleiner wrote:
> That said, maybe preempt_disable is no longer the optimal choice there
> and there's some better way to achieve good protection against
> interruptions of that bit of code? My knowledge here is a bit rusty, and
> the intel kms drivers
- big_oops_buf_sz = (psinfo->bufsize * 100) / 45;
+ big_oops_buf_sz = (psinfo->bufsize * 100) / cmpr;
Tested on an ERST backed system. Seems to be working (we save a little less
information
per ERST record than before this change (uncompressed size goes down from
~17500 to
~16400
On 9/11/13 1:15 PM, Greg KH wrote:
> On Wed, Sep 11, 2013 at 01:00:30PM -0400, Jeff Mahoney wrote:
>> A common way to handle kobject lifetimes in embedded in objects with
>> different lifetime rules is to pair the kobject with a struct completion.
>>
>> This introduces a kobj_completion structure
On 9/11/13 1:28 PM, Al Viro wrote:
> On Wed, Sep 11, 2013 at 01:00:30PM -0400, Jeff Mahoney wrote:
>> A common way to handle kobject lifetimes in embedded in objects with
>> different lifetime rules is to pair the kobject with a struct completion.
>>
>> This introduces a kobj_completion structure
On 09/11/2013 01:26 PM, Al Viro wrote:
On Wed, Sep 11, 2013 at 12:33:35PM -0400, Waiman Long wrote:
Folks, any suggestions on better names? The semantics we are getting is
I will welcome any better name suggestion and will incorporate that
in the patch.
FWIW, the suggestions I've seen so
On Wed, 11 Sep 2013 14:01:13 -0400
Konrad Rzeszutek Wilk wrote:
>
>
> I am thins would still work:
>
>
> 47 static __always_inline void arch_spin_unlock(arch_spinlock_t *lock)
>
> 148 {
>
> 149
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: David Jeffery
[ Upstream commit 1c327d962fc420aea046c16215a552710bde8231 ]
In nlmsvc_retry_blocked, the check that the list is non-empty and acquiring
the pointer of the first entry is
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: George Cherian
[ Upstream commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 ]
Xhci controllers with hci_version > 0.96 gives spurious success
events on short packet completion. During
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Ian Abbott
[ Upstream commit 69acbaac303e8cb948801a9ddd0ac24e86cc4a1b ]
Comedi devices can do blocking read() or write() (or poll()) if an
asynchronous command has been set up,
On Wed, Sep 11, 2013 at 2:06 AM, Andi Kleen wrote:
>> Indeed, get_wchan ensures that fp> fp+8:
>>
>> 434 if (fp < (unsigned long)stack ||
>> 435 fp >= (unsigned long)stack+THREAD_SIZE)
>> 436 return 0;
>> 437 ip = *(u64
-Original Message-
From: Dan Carpenter [mailto:dan.carpen...@oracle.com]
Sent: Wednesday, September 11, 2013 2:39 AM
To: Miller, Mike (OS Dev); Andrew Morton
Cc: ISS StorageDev; linux-kernel@vger.kernel.org;
kernel-janit...@vger.kernel.org; Moritz Muehlenhoff
Subject: [patch -resend]
Hey Ivan-
On Tue, Aug 06, 2013 at 12:14:46PM +0300, Ivan T. Ivanov wrote:
[..]
> Enable low-level debug print routines to direct their
> output to the serial port on MSM 8974 devices.
>
> Signed-off-by: Ivan T. Ivanov
> ---
> arch/arm/Kconfig.debug |8
>
On Wed, Sep 11, 2013 at 2:31 AM, Dan Carpenter wrote:
> On Tue, Sep 10, 2013 at 10:19:17PM -0700, Kees Cook wrote:
>> In the former case, format characters will get processed by the
>> sprintf logic. In the latter, they are printed as-is. In this specific
>> case, if there was a way to inject
On Wed, Sep 11, 2013 at 09:35:08AM -0700, Andy Lutomirski wrote:
> I bet that this improves cross-cpu wakeup latency, too -- the old code
> would presumably wake up the cpu and then immediately interrupt it.
Yeah,. its what clued Mike in to there being a problem.
> It might be nice to rename one
On 09/11/2013 09:35 PM, Stephen Warren wrote:
> On 09/11/2013 04:21 AM, Srivatsa S. Bhat wrote:
>> On 09/11/2013 04:04 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, September 10, 2013 02:53:01 PM Stephen Warren wrote:
On 09/09/2013 05:14 PM, Rafael J. Wysocki wrote:
> On Monday, September
On Wed, Sep 11, 2013 at 11:05 AM, Peter Zijlstra wrote:
> On Wed, Sep 11, 2013 at 09:35:08AM -0700, Andy Lutomirski wrote:
>> I bet that this improves cross-cpu wakeup latency, too -- the old code
>> would presumably wake up the cpu and then immediately interrupt it.
>
> Yeah,. its what clued
On 09/11/2013 11:46 AM, Laxman Dewangan wrote:
> On Wednesday 11 September 2013 10:47 PM, Stephen Warren wrote:
>> On 09/11/2013 06:58 AM, Laxman Dewangan wrote:
>>> The Turn-on time of the regulator depends on the regulator device's
>>> electrical characteristics. Sometimes regulator turn-on time
Am 11.09.2013 18:14, schrieb Javier Martinez Canillas:
On 09/11/2013 05:30 PM, Alexander Holler wrote:
Am 22.08.2013 00:02, schrieb Linus Walleij:
On Tue, Aug 20, 2013 at 12:04 AM, Laurent Pinchart
wrote:
On Wednesday 31 July 2013 01:44:53 Linus Walleij wrote:
I don't see how sharing
Hi Thomas, Daniel,
On Mon, Sep 02, 2013 at 10:01:56PM +0200, Daniel Lezcano wrote:
[..]
>
> The following changes since commit cfb6d656d569510ac9239583ce09e4c92ad54719:
>
> Merge branch 'timers/clockevents-next' of
> git://git.linaro.org/people/dlezcano/clockevents into timers/core
>
On Wednesday 11 September 2013 11:16 PM, Stephen Warren wrote:
On 09/11/2013 11:46 AM, Laxman Dewangan wrote:
On Wednesday 11 September 2013 10:47 PM, Stephen Warren wrote:
- regulator-enable-ramp-delay: The time taken, in uSec, for the supply
rail to reach the target voltage, plus/minus
Hi John,
* John Stultz (john.stu...@linaro.org) wrote:
> On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
> > Starting from commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40
> > "timekeeping: Hold timekeepering locks in do_adjtimex and hardpps"
> > (3.10 kernels), the xtime write seqlock is held
Len, here are some test results.
On a 2-socket AMD 6276 system with the existing turbostat I see
pk cor CPU GHz TSC
0.74 1.15
0 0 8 1.48 2.30
0 1 9 1.48 2.30
0 2 10 1.53 2.30
0 3 11 1.46 2.30
0 4 12 1.49 2.30
0 5 13 1.47 2.30
0 6 14 1.48 2.30
0 7 15 1.54
On 09/11/2013 12:09 PM, Laxman Dewangan wrote:
> On Wednesday 11 September 2013 11:16 PM, Stephen Warren wrote:
>> On 09/11/2013 11:46 AM, Laxman Dewangan wrote:
>>> On Wednesday 11 September 2013 10:47 PM, Stephen Warren wrote:
- regulator-enable-ramp-delay: The time taken, in uSec, for the
On 09/10/2013 01:01 PM, Mark Brown wrote:
On Mon, Sep 09, 2013 at 04:12:21PM -0500, Daniel Santos wrote:
One of my original requirements for this driver is that it is
reusable for different devices that use the MCP2210, not just my own
hardware. There are a number of ways to accomplish this,
On Wed, 11 Sep 2013 13:25:52 -0400
Konrad Rzeszutek Wilk wrote:
> commit 97ce2c88f9ad42e3c60a9beb9fca87abf3639faa
> Author: Jeremy Fitzhardinge
> Date: Wed Oct 12 16:17:54 2011 -0700
>
> jump-label: initialize jump-label subsystem much earlier
>
> Initialize jump_labels much,
On Wed, Sep 11, 2013 at 02:33:05PM +0200, azurIt wrote:
> >On Tue, Sep 10, 2013 at 11:32:47PM +0200, azurIt wrote:
> >> >On Tue, Sep 10, 2013 at 11:08:53PM +0200, azurIt wrote:
> >> >> >On Tue, Sep 10, 2013 at 09:32:53PM +0200, azurIt wrote:
> >> >> >> Here is full kernel log between 6:00 and
On Tue, Aug 06, 2013 at 12:14:46PM +0300, Ivan T. Ivanov wrote:
Attached patch enables earlyprink for this board.
[920] booting linux @ 0x8000, ramdisk @ 0x200 (1067699), tags/device tree @
0x1e0
Uncompressing Linux... done, booting the kernel.
[0.00] Booting Linux on physical
On 09/11/2013 10:49 AM, Mathieu Desnoyers wrote:
> Hi John,
>
> * John Stultz (john.stu...@linaro.org) wrote:
>> On 09/11/2013 08:08 AM, Mathieu Desnoyers wrote:
>>> Starting from commit 06c017fdd4dc48451a29ac37fc1db4a3f86b7f40
>>> "timekeeping: Hold timekeepering locks in do_adjtimex and hardpps"
On Wed, Sep 11, 2013 at 01:52:37PM -0400, Steven Rostedt wrote:
> On Wed, 11 Sep 2013 13:25:52 -0400
> Konrad Rzeszutek Wilk wrote:
>
>
> > commit 97ce2c88f9ad42e3c60a9beb9fca87abf3639faa
> > Author: Jeremy Fitzhardinge
> > Date: Wed Oct 12 16:17:54 2011 -0700
> >
> > jump-label:
On Wed, Sep 11, 2013 at 10:22 AM, David Safford wrote:
>>On 09/09/2013 02:11 PM, H. Peter Anvin wrote:
>>> It recently came to my attention that there are no standards whatsoever
>>> for random number generated by TPMs. In fact, there *are* TPMs where
>>> random numbers are generated by an
Hi All,
I try to do pcie hotplug testing. I create ext4 file system on disk and mount,
then I do surprise hotplug. When I insert disk I see below error messagee. I am
new to Linux kernel, Please let me know any clue for below error. Thank you for
your help.
[I convert error from image to
3.6.11.9-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Sarah Sharp
[ Upstream commit 203a86613fb3bf2767335659513fa98563a3eb71 ]
When the host controller fails to respond to an Enable Slot command, and
the host fails to respond to the
201 - 300 of 1346 matches
Mail list logo
