On Tue, 9 Apr 2013, Thomas Gleixner wrote:
> Dave,
>
> On Tue, 9 Apr 2013, Dave Hansen wrote:
>
> > Hey Thomas,
> >
> > I don't think the patch helped my case. Looks like the same BUG_ON().
> >
> > I accidentally booted with possible_cpus=10 instead of 160. I wasn't
> > able to trigger this
On 04/08/2013 11:06 PM, Gilad Ben-Yossef wrote:
On Tue, Apr 9, 2013 at 9:03 AM, Gilad Ben-Yossef wrote:
I also wonder whether there could be unexpected interactions between ->high
and ->batch not changing together atomically. For example, could adjusting
this knob cause ->batch to rise
On 04/09/2013 12:30 PM, Luck, Tony wrote:
- misc_register(_chrdev_device);
+ if (misc_register(_chrdev_device) != 0)
+ pr_warn("Failed to register mcelog device\n");
Did this actually happen to you? Or is this just "good practice" to check the
return value from
On Tue, Apr 09, 2013 at 06:51:09PM +0800, Zhenzhong Duan wrote:
> xen_send_IPI_mask_allbutself uses native vector as input other than
> xen_vector.
Ouch. But it looks as the only user of the .send_IPI_mask_allbutself
is just xen_send_IPI_allbutself? Or is there another user of this?
Is there a
On Tue, 2013-04-09 at 05:48 +, Ram Pai wrote:
> On Mon, Apr 08, 2013 at 03:47:35PM -0600, Toshi Kani wrote:
> > Added release_mem_region_adjustable(), which releases a requested
> > region from a currently busy memory resource. This interface
> > adjusts the matched memory resource
On Tue, Apr 09, 2013 at 11:57:21AM -0700, Tejun Heo wrote:
[..]
> And destroy all per-ioc and cgroup logics in block layer in the
> process.
Oh, I am in no-way suggesting don't use bio_associate_current(). I am
just trying to analyze the performance issue right now and saying that
as far as
On Tuesday 09 April 2013, Harvey Harrison wrote:
>
> On Tue, Apr 9, 2013 at 11:39 AM, Lee Jones wrote:
> >
> > The aim is to make the code that little more readable.
> >
> > Signed-off-by: Lee Jones
> > ---
>
> >
> > #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>
> Not part of your patch, but
On Tue, 09 Apr 2013, Harvey Harrison wrote:
> On Tue, Apr 9, 2013 at 11:39 AM, Lee Jones wrote:
> >
> > The aim is to make the code that little more readable.
> >
> > Signed-off-by: Lee Jones
> > ---
>
> >
> > #define MAX(a, b) (((a) < (b)) ? (b) : (a))
>
> Not part of your patch, but
Hello,
On Tue, Apr 09, 2013 at 01:32:01AM +0200, Lennart Poettering wrote:
> The other big thing we want from the systemd side is saner
> notifications when cgroups run empty. i.e. currently we don't get
> these at all in containers (since the agent can be only installed
> once, for the host).
On Tue, 09 Apr 2013, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Lee Jones wrote:
> > Confusingly d40_log_cfg() is used to set up the logical channel
> > configuration registers, but d40_phy_cfg() is used to configure
> > physical and logical registers, so it should be called in both
> >
On Tue, 09 Apr 2013, Arnd Bergmann wrote:
> On Tuesday 09 April 2013, Lee Jones wrote:
> > Someone has spent a fair amount of effort writing a runtime configuration
> > changing algorithm for DMA clients. However, the config appears to never
> > actually make it to hardware. In order for the
Sourav Poddar writes:
> Hi Kevin,
> On Friday 05 April 2013 11:10 PM, Kevin Hilman wrote:
>> Sourav Poddar writes:
>>
>>> With dt boot, uart wakeup after suspend is non functional while using
>>> "no_console_suspend" in the bootargs. With "no_console_suspend" used, we
>>> should prevent the
Hi Linus,
Here's one small fix for vfio that I'd like to get in for 3.9;
tightening the range checking around a vfio ioctl. Thanks!
Alex
The following changes since commit 25e9789ddd9d14a8971f4a421d04f282719ab733:
vfio: include for kmalloc (2013-03-15 12:58:20 -0600)
are available in the
From: Kees Cook
Date: Tue, 9 Apr 2013 10:50:24 -0700
> To avoid future stack content leaks in the various protocols, pre-clear
> the returned memory.
>
> Signed-off-by: Kees Cook
> Suggested-by: Brad Spengler
No thanks, clearing 2 full cache lines unnecessarily on every socket
call has real
On Tue, Apr 9, 2013 at 11:39 AM, Lee Jones wrote:
>
> The aim is to make the code that little more readable.
>
> Signed-off-by: Lee Jones
> ---
>
> #define MAX(a, b) (((a) < (b)) ? (b) : (a))
Not part of your patch, but probably a good idea to switch to the
generic MAX macro, this
one is
From: Suravee Suthikulpanit
Add logic to decode AMD IOMMU event flag based on information from AMD IOMMU
specification.
This should simplify debugging IOMMU errors. Also, dump DTE information in
additional cases.
This is an example:
AMD-Vi: Event logged [INVALID_DEVICE_REQUEST device=51:00.0
On 04/09/2013 11:54 AM, Eric Northup wrote:
>
> The GDT is a problem if the address returned by 'sgdt' is
> kernel-writable - it doesn't necessarily reveal the random offset, but
> I'm pretty sure that writing to the GDT could cause privilege
> escalation.
>
That is a pretty safe assumption...
On Tuesday 09 April 2013, Lee Jones wrote:
> Someone has spent a fair amount of effort writing a runtime configuration
> changing algorithm for DMA clients. However, the config appears to never
> actually make it to hardware. In order for the configuration to take hold
> we need to issue a
On 9.4.2013 20:08, Mikulas Patocka wrote:
>
>
> On Tue, 26 Mar 2013, Milan Broz wrote:
>
>> - Are we sure we are not inroducing some another side channel in disc
>> encryption? (Unprivileged user can measure timing here).
>> (Perhaps stupid reason but please do not prefer performance to
On Tuesday 09 April 2013, Lee Jones wrote:
> Confusingly d40_log_cfg() is used to set up the logical channel
> configuration registers, but d40_phy_cfg() is used to configure
> physical and logical registers, so it should be called in both
> cases. It is the function call's final attribute which
Hello,
On Tue, Apr 09, 2013 at 02:42:48PM -0400, Vivek Goyal wrote:
> I guess plugging boundary is more important than issuing order as
> block layer should take care of mering the bio and put in right
> order (attempt_plug_merge()).
Yeah, the exact order probably doesn't affect things too much
On 04/09/2013 11:46 AM, Kees Cook wrote:
>
> Ah-ha! Yes, I see now when comparing the debug/kernel_page_tables
> reports. It's just the High Kernel Mapping that we care about.
> Addresses outside that range are less of a leak. Excellent, then GDT
> may not be a problem. Whew.
>
It does beg the
On Tuesday 09 April 2013, Lee Jones wrote:
> There are various pieces of configuration which do not need to happen
> until after a channel is allocated. Here we move some of these so they're
> dealt with when it's time to configure the channel, rather than allocate
> it.
>
> Cc: Vinod Koul
> Cc:
On Tuesday 09 April 2013, Lee Jones wrote:
> The aim is to make the code that little more readable.
>
> Signed-off-by: Lee Jones
I don't find the new version any more or less readable than the old one,
but I have no objections if other people think it's a good idea.
Acked-by: Arnd Bergmann
--
Hi Kevin,
On Friday 05 April 2013 11:10 PM, Kevin Hilman wrote:
Sourav Poddar writes:
With dt boot, uart wakeup after suspend is non functional while using
"no_console_suspend" in the bootargs. With "no_console_suspend" used, we
should prevent the runtime suspend of the uart port which is
On Tue, Apr 09, 2013 at 06:30:58PM +, Luck, Tony wrote:
> - misc_register(_chrdev_device);
> + if (misc_register(_chrdev_device) != 0)
> + pr_warn("Failed to register mcelog device\n");
>
> Did this actually happen to you? Or is this just "good practice" to check the
>
On Tue, Apr 9, 2013 at 11:46 AM, Kees Cook wrote:
> On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin wrote:
>> On 04/09/2013 11:31 AM, Kees Cook wrote:
> ...
> 0x880001e0-0x88001fe0 480M RW PSE GLB
> NX pmd
>
That is the 1:1 memory
On Tue, Apr 9, 2013 at 11:50 AM, H. Peter Anvin wrote:
> On 04/09/2013 11:46 AM, Kees Cook wrote:
>>
>> Ah-ha! Yes, I see now when comparing the debug/kernel_page_tables
>> reports. It's just the High Kernel Mapping that we care about.
>> Addresses outside that range are less of a leak.
On Tuesday 09 April 2013, Lee Jones wrote:
> Devices which utilise DMA tend to use the same channel numbers for
> transmitting and receiving. For this reason and the fact that it'll
> decrease the burden of platform data passed to each device, we're
> amalgamating source and destination device
On Wed, Mar 27, 2013 at 12:10:43PM +0100, Roger Pau Monne wrote:
> Indirect descriptors introduce a new block operation
> (BLKIF_OP_INDIRECT) that passes grant references instead of segments
> in the request. This grant references are filled with arrays of
> blkif_request_segment_aligned, this way
On Tue 09-04-13 11:06:17, Darrick J. Wong wrote:
> Walking a bio's page mappings has proved problematic, so create a new bio flag
> to indicate that a bio's data needs to be snapshotted in order to guarantee
> stable pages during writeback. Next, for the one user (ext3/jbd) of
> snapshotting,
On 04/08/2013 08:47 PM, Randy Dunlap wrote:
From: Randy Dunlap
Fix randconfig error when USB is not enabled:
ERROR: "usb_control_msg" [drivers/media/common/cypress_firmware.ko] undefined!
Signed-off-by: Randy Dunlap
Cc: Antti Palosaari
Reviewed-by: Antti Palosaari
---
On Tue, Apr 9, 2013 at 11:39 AM, H. Peter Anvin wrote:
> On 04/09/2013 11:31 AM, Kees Cook wrote:
...
0x880001e0-0x88001fe0 480M RW PSE GLB
NX pmd
>>>
>>> That is the 1:1 memory map area...
>>
>> Meaning what?
>>
>> -Kees
>>
>
> That's the
On 04/09/2013 11:31 AM, Kees Cook wrote:
>>> ...
>>> 0x880001e0-0x88001fe0 480M RW PSE GLB
>>> NX pmd
>>>
>>
>> That is the 1:1 memory map area...
>
> Meaning what?
>
> -Kees
>
That's the area in which we just map 1:1 to memory. Anything allocated
with
Dave,
On Tue, 9 Apr 2013, Dave Hansen wrote:
> Hey Thomas,
>
> I don't think the patch helped my case. Looks like the same BUG_ON().
>
> I accidentally booted with possible_cpus=10 instead of 160. I wasn't
> able to trigger this in that case, even repeatedly on/offlining them.
> But, once I
On Tue, Apr 09, 2013 at 11:10:31AM -0700, Tejun Heo wrote:
> Hey,
>
> On Tue, Apr 09, 2013 at 02:08:06PM -0400, Mikulas Patocka wrote:
> > > Hmmm? Why not just keep the issuing order along with plugging
> > > boundaries?
> >
> > What do you mean?
> >
> > I used to have a patch that keeps order
According to the DMA documentation allocating a channel and configuring
it are two separate actions. By removing the configuration code from the
channel allocation path we lighten the burden on the information required to
successfully allocate a channel.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Per
Someone has spent a fair amount of effort writing a runtime configuration
changing algorithm for DMA clients. However, the config appears to never
actually make it to hardware. In order for the configuration to take hold
we need to issue a d40_config_write(), as this is the routine which writes
it
The channels reserved for memcpy are the same for all currently
supported platforms. With this in mind, we can ease the platform
data passing requirement by moving these assignments out from
platform code and place them directly into the driver.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Per Forlin
There are only two default memcpy configurations used for the DMA40
driver; one for physical memcpy and one for logical memcpy. Instead
of invariably passing the same configurations though platform data,
we're moving them into the driver instead.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Per Forlin
Devices which utilise DMA tend to use the same channel numbers for
transmitting and receiving. For this reason and the fact that it'll
decrease the burden of platform data passed to each device, we're
amalgamating source and destination device types.
Signed-off-by: Lee Jones
---
The aim is to make the code that little more readable.
Signed-off-by: Lee Jones
---
drivers/dma/ste_dma40.c | 34 +-
1 file changed, 17 insertions(+), 17 deletions(-)
diff --git a/drivers/dma/ste_dma40.c b/drivers/dma/ste_dma40.c
index c14db3e..7b96e75 100644
Confusingly d40_log_cfg() is used to set up the logical channel
configuration registers, but d40_phy_cfg() is used to configure
physical _and_ logical registers, so it should be called in both
cases. It is the function call's final attribute which determines
whether it's a physical or logical
There are various pieces of configuration which do not need to happen
until after a channel is allocated. Here we move some of these so they're
dealt with when it's time to configure the channel, rather than allocate
it.
Cc: Vinod Koul
Cc: Dan Williams
Cc: Per Forlin
Signed-off-by: Lee Jones
On Tue, Apr 09, 2013 at 01:51:43PM -0400, Mikulas Patocka wrote:
> Hi
>
> I placed the dm-crypt parallization patches at:
> http://people.redhat.com/~mpatocka/patches/kernel/dm-crypt-paralelizace/current/
>
> The patches paralellize dm-crypt and make it possible to use all processor
> cores.
>
On Tue, Apr 09, 2013 at 02:29:11PM +0800, Wei Yongjun wrote:
> From: Wei Yongjun
>
> memory allocated by kmem_cache_alloc() should be freed using
> kmem_cache_free(), not kfree().
>
> Signed-off-by: Wei Yongjun
Oops, thanks for fixing it. Applied to wq/for-3.10.
Thanks!
--
tejun
--
To
On Tue, 9 Apr 2013, Dave Martin wrote:
> On Tue, Apr 02, 2013 at 12:11:25PM -0400, Nicolas Pitre wrote:
> > I'm concerned about mixing big.LITTLE and Xen as well. I don't think
> > this is going to make an easy match. KVM might have an easier fit here.
> >
> > But, in any case, even if the
On 09-04-2013 14:27, Andrew Bresticker wrote:
You do two things in this change on cpu_cooling.c: (1) fix the case where
the loop is kept running indefinitely. (2) Reserve a specific role for each
index in this function.
So the issue is that the changes are not independent. With just the
fix
On Tuesday 09 April 2013, Stephen Boyd wrote:
> >>>
> >>> Sneaking it in through the fixes branch would make life easier for us,
> >>> but it doesn't feel right.
> >> Arnd, can you pick this up into the arm-soc tree now? It would be good
> >> to get this into next so that conflicts are avoided
- misc_register(_chrdev_device);
+ if (misc_register(_chrdev_device) != 0)
+ pr_warn("Failed to register mcelog device\n");
Did this actually happen to you? Or is this just "good practice" to check the
return value from misc_register?
If this can really happen, we
On Tue, Apr 9, 2013 at 11:26 AM, H. Peter Anvin wrote:
> On 04/09/2013 11:22 AM, Kees Cook wrote:
>>
>> $ ./sgdt
>> 88001fc04000
>> # cat /sys/kernel/debug/kernel_page_tables
>> ...
>> ---[ Low Kernel Mapping ]---
>> ...
>> 0x880001e0-0x88001fe0 480M RW PSE
Yo!
On Tue, Apr 09, 2013 at 01:00:59PM +0530, Viresh Kumar wrote:
> + workqueue.power_efficient
> + Workqueues can be performance or power oriented. For
> + performance we may want to keep them running on a single
> + cpu, so that it
On 04/09/2013 11:22 AM, Kees Cook wrote:
>
> $ ./sgdt
> 88001fc04000
> # cat /sys/kernel/debug/kernel_page_tables
> ...
> ---[ Low Kernel Mapping ]---
> ...
> 0x880001e0-0x88001fe0 480M RW PSE GLB NX
> pmd
>
That is the 1:1 memory map area...
> You do two things in this change on cpu_cooling.c: (1) fix the case where
> the loop is kept running indefinitely. (2) Reserve a specific role for each
> index in this function.
So the issue is that the changes are not independent. With just the
fix for the infinite loop, get_cpu_frequency()
On Tue, Apr 09, 2013 at 05:33:29PM +0400, Andrey Vagin wrote:
> do_loopback calls lock_mount(path) and forget to unlock_mount
> if clone_mnt or copy_mnt fails.
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
A nasty bug in fs/namespace.c caught by Andrey + a couple of
less serious unpleasantness - ecryptfs misc device playing hopeless
games with try_module_get() and palinfo procfs support being... not
quite correctly done, to be polite. Please, pull from
On Tue, Apr 9, 2013 at 2:23 AM, Thomas Gleixner wrote:
> On Mon, 8 Apr 2013, H. Peter Anvin wrote:
>
>> On 04/08/2013 03:43 PM, Kees Cook wrote:
>> > This makes the IDT unconditionally read-only. This primarily removes
>> > the IDT from being a target for arbitrary memory write attacks. It has
>>
Print a warning if machine check handler fails to register
/dev/mcelog device.
Signed-off-by: Khalid Aziz
---
arch/x86/kernel/cpu/mcheck/mce.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index
__hfsplus_ext_write_extent() suppresses errors coming from hfs_brec_find().
The patch implements error code propagation.
Signed-off-by: Alexey Khoroshilov
---
fs/hfsplus/extents.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/fs/hfsplus/extents.c
hfs_find_init() may fail with ENOMEM, but there are places,
where the returned value is not checked. The consequences can be
very unpleasant, e.g. kfree uninitialized pointer and
inappropriate mutex unlocking.
The patch adds checks for errors in hfs_find_init().
Found by Linux Driver
Hey,
On Tue, Apr 09, 2013 at 02:08:06PM -0400, Mikulas Patocka wrote:
> > Hmmm? Why not just keep the issuing order along with plugging
> > boundaries?
>
> What do you mean?
>
> I used to have a patch that keeps order of requests as they were
> introduced, but sorting the requests according to
On Tue, 2013-04-09 at 10:50 -0700, Kees Cook wrote:
> To avoid future stack content leaks in the various protocols, pre-clear
> the returned memory.
>
> Signed-off-by: Kees Cook
> Suggested-by: Brad Spengler
> ---
> net/socket.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
On Tue, 26 Mar 2013, Milan Broz wrote:
> - Are we sure we are not inroducing some another side channel in disc
> encryption? (Unprivileged user can measure timing here).
> (Perhaps stupid reason but please do not prefer performance to security
> in encryption. Enough we have timing attacks for
On Tue, 9 Apr 2013, Tejun Heo wrote:
> On Tue, Apr 09, 2013 at 01:51:43PM -0400, Mikulas Patocka wrote:
> > The patch dm-crypt-sort-requests.patch sorts write requests submitted by a
> > single thread. The requests are sorted according to the sector number,
> > rb-tree is used for efficient
Walking a bio's page mappings has proved problematic, so create a new bio flag
to indicate that a bio's data needs to be snapshotted in order to guarantee
stable pages during writeback. Next, for the one user (ext3/jbd) of
snapshotting, hook all the places where writes can be initiated without
On Wed, Apr 03, 2013 at 04:42:44PM +0200, Jan Kara wrote:
> On Wed 03-04-13 15:20:19, Mel Gorman wrote:
> > On Tue, Apr 02, 2013 at 10:01:43AM -0700, Darrick J. Wong wrote:
> > > Hi,
> > >
> > > A couple of weeks have gone by without further comments about this patch.
> > >
> > > Are you
On Tue, Apr 09, 2013 at 01:51:43PM -0400, Mikulas Patocka wrote:
> The patch dm-crypt-sort-requests.patch sorts write requests submitted by a
> single thread. The requests are sorted according to the sector number,
> rb-tree is used for efficient sorting.
Hmmm? Why not just keep the issuing
The headers are now needed inside scripts/mod since 6543bec
("mod/file2alias: make modalias generation safe for cross compiling").
Signed-off-by: Andreas Schwab
---
Prabhakar Lad writes:
> Whats the status of it ?
I think it has sufficiently been tested by now.
Andreas.
---
Makefile | 3 ++-
On 04/09/2013 12:39 PM, Michael S. Tsirkin wrote:
On Fri, Apr 05, 2013 at 04:54:39PM -0400, Michael R. Hines wrote:
To be more specific, here's what I did:
1. apply kernel module patch - re-insert module
1. QEMU does: ibv_reg_mr(IBV_ACCESS_GIFT | IBV_ACCESS_REMOTE_READ)
2. Start the
Hi
I placed the dm-crypt parallization patches at:
http://people.redhat.com/~mpatocka/patches/kernel/dm-crypt-paralelizace/current/
The patches paralellize dm-crypt and make it possible to use all processor
cores.
The patch dm-crypt-remove-percpu.patch removes some percpu variables and
To avoid future stack content leaks in the various protocols, pre-clear
the returned memory.
Signed-off-by: Kees Cook
Suggested-by: Brad Spengler
---
net/socket.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/socket.c b/net/socket.c
index 88f759a..4d2af0d
Gets rid of these warnings when compile module for 64 bit targets:
CC drivers/mfd/syscon.o
drivers/mfd/syscon.c: In function 'syscon_probe':
drivers/mfd/syscon.c:155:2: warning: format '%x' expects argument of type
'unsigned int', but argument 3 has type 'resource_size_t' [-Wformat]
Jens Axboe wrote:
>On Tue, Apr 09 2013, Bjørn Mork wrote:
>> Hello,
>>
>> the following simple test causes a deadlock between the loop driver,
>> umount and blkid i v3.9-rc6 (tested on a standard Debian wheezy
>> installating, i.e. with udev 175):
>>
>> qmitest:~# file cd-image-cfg1.iso
>>
On Tue, 2013-04-02 at 05:13 +0200, Carsten Emde wrote:
> Steven,
> > I'm pleased to announce the 3.6.11.1-rt32 stable release.
> Unfortunately, there is another compile error:
> drivers/gpu/drm/i915/i915_gem.c: In function ‘i915_gem_wait_for_error’:
> drivers/gpu/drm/i915/i915_gem.c:118:3:
* Tony Lindgren [130409 09:54]:
> * Roger Quadros [130409 03:00]:
> > On 04/05/2013 06:58 PM, Tony Lindgren wrote:
> > >
> > > Can't you just use the clock name there to get it?
> >
> > In device tree we don't pass around clock names. You can either get
> > a phandle or an index to the clock.
On Tue, Apr 09 2013, Bjørn Mork wrote:
> Hello,
>
> the following simple test causes a deadlock between the loop driver,
> umount and blkid i v3.9-rc6 (tested on a standard Debian wheezy
> installating, i.e. with udev 175):
>
> qmitest:~# file cd-image-cfg1.iso
> cd-image-cfg1.iso: # ISO 9660
On Fri, Apr 05, 2013 at 04:54:39PM -0400, Michael R. Hines wrote:
> To be more specific, here's what I did:
>
> 1. apply kernel module patch - re-insert module
> 1. QEMU does: ibv_reg_mr(IBV_ACCESS_GIFT | IBV_ACCESS_REMOTE_READ)
> 2. Start the RDMA migration
> 3. Migration completes
On Tue, Apr 09, 2013 at 07:11:21PM +0200, Daniel Mack wrote:
> The reply was fyi only, as the patch also went to spi-devel-general. Can
> you pick it from there or should Josef send it again with your address
> in Cc:?
Please make sure stuff goes to my inbox, I *can* pick up from
-devel-general
Hi Guenter,
> > > I was waiting for feedback from Wim, who submitted a similar driver,
> > > about his
> > > thoughts. Key question is how to reserve access to the shared resource -
> > > either
> > > through an exported function in the mfd driver requesting a mutex, or
> > > through
> > >
On Tue, Apr 09, 2013 at 09:22:58AM -0500, Suthikulpanit, Suravee wrote:
> The reason I implemented the "per-thread IOMMU handling" and the
> "workaround" together in one patch
> is because it simplifies the synchronization of clearing and
> checking the interrupt enabling bits.
> In the previous
On 04/09/13 07:52, Rob Landley wrote:
> On 04/05/2013 02:53:12 PM, Byron Stanoszek wrote:
>> Rob,
>>
>> FWIW I have a patch to do something like this. It even gives you a rdsize=xxx
>> tunable kernel parameter that lets you specify the size of the tmpfs, which
>> acts like the -osize= mount flag
One additional measure that may be useful is to make kswapd prefer one
specific processor on a socket. Two benefits arise from that:
1. Better use of cpu caches and therefore higher speed, less
serialization.
2. Reduction of the disturbances to one processor.
--
To unsubscribe from this list:
On Tue, Apr 09, 2013 at 03:21:35PM +0200, Richard Cochran wrote:
> On Tue, Apr 09, 2013 at 02:50:03PM +0200, Daniel Vetter wrote:
> >
> > This should be fixed with the above mentioned patch. The issue is that the
> > bios fumbles around with the output configuration behind our backs, so the
> >
From: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Jacob Shin
---
tools/perf/Documentation/perf-record.txt | 14 ++
tools/perf/util/parse-events.c |2 +-
2 files changed, 11 insertions(+), 5 deletions(-)
diff --git
From: Suravee Suthikulpanit
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Jacob Shin
---
tools/perf/tests/parse-events.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index
Implement hardware breakpoint address mask for AMD Family 16h (and
any other future) processors. CPUID feature bit indicates the hardware
support for DRn_ADDR_MASK MSRs.
Signed-off-by: Jacob Shin
---
arch/x86/Kconfig |1 +
arch/x86/include/asm/cpufeature.h |2 ++
Some architectures (for us, AMD Family 16h) allow for "don't care" bit
mask to further qualify a hardware breakpoint address, in order to
trap on range of addresses. Update perf uapi to add bp_addr_mask field
and define HAVE_HW_BREAKPOINT_ADDR_MASK.
Signed-off-by: Jacob Shin
---
arch/Kconfig
The following patchset adds address masks to existing perf hardware
breakpoint mechanism to allow trapping on an address range (currently
only single address) on supported architectures.
perf uapi is updated, x86 AMD implementation (for AMD Family 16h and
beyond) is provided, and perf tool has
From: Suravee Suthikulpanit
Allow perf tool to pass in breakpoint address mask to match an address
range, i.e.:
$ perf stat -e mem:0x1000:w:0xf a.out
Will count writes to [0x1000 ~ 0x1010)
Signed-off-by: Suravee Suthikulpanit
Signed-off-by: Jacob Shin
---
tools/perf/util/parse-events.c |
On 09-04-2013 13:02, Andrew Bresticker wrote:
Hi Eduardo,
On Tue, Apr 9, 2013 at 7:55 AM, Eduardo Valentin
wrote:
Hi Andrew,
On 08-04-2013 19:54, Andrew Bresticker wrote:
The loops which are used to perform lookups in CPU frequency tables in
cpu_cooling and the Exynos thermal driver do
On 04/09/2013 10:12 AM, Vivek Goyal wrote:
> On Tue, Apr 09, 2013 at 09:49:28AM -0700, H. Peter Anvin wrote:
>> On 04/09/2013 09:47 AM, Vivek Goyal wrote:
>>> On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
Please, no semicolons. We already have established syntax for
From: Li Zefan
Date: Tue, 9 Apr 2013 14:03:47 +0800
> The callers always pass current to sock_update_netprio().
>
> Signed-off-by: Li Zefan
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
From: Li Zefan
Date: Tue, 9 Apr 2013 14:03:35 +0800
> The callers always pass current to sock_update_classid().
>
> Signed-off-by: Li Zefan
Applied.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
From: Li Zefan
Date: Tue, 9 Apr 2013 13:59:28 +0800
> We read the value but make no use of it.
>
> Signed-off-by: Li Zefan
Applied.
--
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
Hi Hector,
> Dear Marek Vasut,
>
> On 04/09/2013 10:15 AM, Marek Vasut wrote:
> > Dear Hector Palacios,
> >
> >> Dear Marek Vasut,
> >>
> >> On 04/08/2013 06:28 PM, Marek Vasut wrote:
> >>> Dear Shawn Guo,
> >>>
> On Mon, Apr 08, 2013 at 03:58:05PM +0200, Hector Palacios wrote:
> >
On 09-04-2013 13:09, Andrew Bresticker wrote:
Hi Eduardo,
On Tue, Apr 9, 2013 at 8:00 AM, Eduardo Valentin
wrote:
Hi Andrew,
On 08-04-2013 19:56, Andrew Bresticker wrote:
When selecting a target cooling state in get_target_state(), make sure
that the state is at least as high as the
On 04/08/2013 06:46 PM, Doug Anderson wrote:
Al,
On Mon, Apr 8, 2013 at 4:06 PM, Al Viro wrote:
Folks, see if vfs.git#experimental works for you; the PITA had apparently
been caused by change of open() semantics for /proc//fd/ -
it started to behave like a FIFO, i.e. wait for peer to show up.
On Tue, Apr 09, 2013 at 09:49:28AM -0700, H. Peter Anvin wrote:
> On 04/09/2013 09:47 AM, Vivek Goyal wrote:
> > On Tue, Apr 09, 2013 at 08:00:57AM -0700, H. Peter Anvin wrote:
> >> Please, no semicolons. We already have established syntax for suboptions
> >> (option=suboption,suboption,...) and
On 09.04.2013 19:08, Mark Brown wrote:
> On Tue, Apr 09, 2013 at 07:06:32PM +0200, Daniel Mack wrote:
>> Cc: Mark
>>
>> On 09.04.2013 18:40, Josef Ahmad wrote:
>>> spi_bitbang_setup() deasserts the chip select line to initialise
>>> the device. The chip select GPIO line is obtained from
>
>
On 04/08/2013 06:54 PM, Luck, Tony wrote:
>> I think it is a good idea to switch directly to strtobool. But anyway, if you
>> don't want to respin the patch it is fine as it is.
> I didn't know that strtobool() existed ... but now that I do I agree that it
> would
> be better to use it here. But
301 - 400 of 1762 matches
Mail list logo
