Use kmalloc_array instead of kmalloc to allocate memory for an array.
Also, remove the dev_warn for a memory leak, making the if check more
sleek.
Signed-off-by: Muhammad Falak R Wani
---
On suggestion by Joe Perches
Changes since v0
-remove dev_warn for memory leak
-remove
This new test checks that all x86 registers are preserved across
32-bit syscalls. It tests syscalls through VDSO (if available)
and through INT 0x80, normally and under ptrace.
If kernel is a 64-bit one, high registers (r8..r15) are poisoned
before the syscall is called and are checked
On Sep 7, 2015, at 11:56 PM, Mark Rutland wrote:
Hi Mark,
> On Fri, Sep 04, 2015 at 03:23:05PM +0100, Jungseok Lee wrote:
>> Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation
>> is not needed in kernel_entry. Currently, S_SP information is vaild only
>> when sp_el0 is used.
On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
> >
> > That shifts the risk to user space though. But if there is a regression
> > there, it will manifest itself on all systems and not only with some
> > particular hardware.
>
> I'd
On Sep 7, 2015, at 11:36 PM, James Morse wrote:
Hi James,
> Having to handle interrupts on top of an existing kernel stack means the
> kernel stack must be large enough to accomodate both the maximum kernel
> usage, and the maximum irq handler usage. Switching to a different stack
> when
Mark 800MHz OPP as a suspend opp for Exynos4412 based
boards so effectively cpufreq-dt driver behavior w.r.t.
suspend frequency matches what the old exynos-cpufreq
driver has been doing.
This patch fixes suspend/resume support on Exynos4412 based
Trats2 board and reboot hang on Exynos4412 based
On Monday 07 September 2015 11:34:36 Nicolas Pitre wrote:
>
> That shifts the risk to user space though. But if there is a regression
> there, it will manifest itself on all systems and not only with some
> particular hardware.
I'd consider that a good thing, as it makes it easier to test
Add suspend frequency support and if needed set it to
the frequency obtained from the suspend opp (can be defined
using opp-v2 bindings and is optional).
Cc: Viresh Kumar
Cc: Thomas Abraham
Cc: Javier Martinez Canillas
Cc: Krzysztof Kozlowski
Cc: Marek Szyprowski
Cc: Tobias Jakobi
Add dev_pm_opp_get_suspend_opp() helper to obtain suspend opp.
Cc: Viresh Kumar
Cc: Thomas Abraham
Cc: Javier Martinez Canillas
Cc: Krzysztof Kozlowski
Cc: Marek Szyprowski
Cc: Tobias Jakobi
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/base/power/opp.c | 30
Some cpufreq drivers may set suspend frequency only for
selected setups but still would like to use the generic
suspend handler. Thus don't treat !policy->suspend_freq
condition as an incorrect one.
Cc: Viresh Kumar
Cc: Thomas Abraham
Cc: Javier Martinez Canillas
Cc: Krzysztof Kozlowski
Cc:
On Sep 7, 2015, at 11:33 PM, James Morse wrote:
> On 04/09/15 15:23, Jungseok Lee wrote:
>> ARM64 kernel allocates 16KB kernel stack when creating a process. In case
>> of low memory platforms with tough workloads on userland, this order-2
>> allocation request reaches to memory pressure and
Hi,
This patch series adds suspend frequency support (using opp-v2
bindings and suspend-opp functionality) to cpufreq-dt driver and
then adds suspend opp for Exynos4412 based boards.
This patch series fixes suspend/resume support on Exynos4412
based Trats2 board and reboot hang on Exynos4412
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity working as a
network backend on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on
The PV network protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using network
device on a non-modified Xen.
It's only necessary to adapt the ring size and break skb data in small
chunk of 4KB. The rest of the code is relying on the
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity using block
device on a non-modified Xen.
The block API is using segment which should at least be the size of a
Linux page. Therefore, the driver will have to break the page
The hypercall interface is always using 4KB page granularity. This is
requiring to use xen page definition macro when we deal with hypercall.
Note that pfn_to_gfn is working with a Xen pfn (i.e 4KB). We may want to
rename pfn_gfn to make this explicit.
We also allocate a 64KB page for the shared
For ARM64 guests, Linux is able to support either 64K or 4K page
granularity. Although, the hypercall interface is always based on 4K
page granularity.
With 64K page granularity, a single page will be spread over multiple
Xen frame.
To avoid splitting the page into 4K frame, take advantage of
The PV block protocol is using 4KB page granularity. The goal of this
patch is to allow a Linux using 64KB page granularity behaving as a
block backend on a non-modified Xen.
It's only necessary to adapt the ring size and the number of request per
indirect frames. The rest of the code is relying
Only use the first 4KB of the page to store the events channel info. It
means that we will waste 60KB every time we allocate page for:
* control block: a page is allocating per CPU
* event array: a page is allocating everytime we need to expand it
I think we can reduce the memory waste
All the ring (xenstore, and PV rings) are always based on the page
granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: David Vrabel
Reviewed-by: Stefano Stabellini
---
Cc: Konrad Rzeszutek Wilk
Cc: Boris Ostrovsky
Changes in v3:
- Fix errors reported by checkpatch.pl
The Xen interface is using 4KB page granularity. This means that each
grant is 4KB.
The current implementation allocates a Linux page per grant. On Linux
using 64KB page granularity, only the first 4KB of the page will be
used.
We could decrease the memory wasted by sharing the page with
The console ring is always based on the page granularity of Xen.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Greg Kroah-Hartman
Cc: Jiri Slaby
Cc: David Vrabel
Cc: Boris Ostrovsky
Cc: linuxppc-...@lists.ozlabs.org
Changes in v4:
- The ring is always 4K
The hypercall interface (as well as the toolstack) is always using 4KB
page granularity. When the toolstack is asking for mapping a series of
guest PFN in a batch, it expects to have the page map contiguously in
its virtual memory.
When Linux is using 64KB page granularity, the privcmd driver
Hi all,
ARM64 Linux is supporting both 4KB and 64KB page granularity. Although, Xen
hypercall interface and PV protocol are always based on 4KB page granularity.
Any attempt to boot a Linux guest with 64KB pages enabled will result to a
guest crash.
This series is a first attempt to allow those
All the usage of the field pfn are done using the same idiom:
pfn_to_page(grant->pfn)
This will return always the same page. Store directly the page in the
grant to clean up the code.
Signed-off-by: Julien Grall
Acked-by: Roger Pau Monné
Reviewed-by: Stefano Stabellini
---
Cc: Konrad
Currently, blkif_queue_request has 2 distinct execution path:
- Send a discard request
- Send a read/write request
The function is also allocating grants to use for generating the
request. Although, this is only used for read/write request.
Rather than having a function with 2 distinct
On 04/09/15 00:51, Steve Muckle wrote:
> Hi Morten, Dietmar,
>
> On 08/14/2015 09:23 AM, Morten Rasmussen wrote:
> ...
>> + * cfs_rq.avg.util_avg is the sum of running time of runnable tasks plus the
>> + * recent utilization of currently non-runnable tasks on a CPU. It
>> represents
>> + * the
Currently, a grant is always based on the Xen page granularity (i.e
4KB). When Linux is using a different page granularity, a single page
will be split between multiple grants.
The new helpers will be in charge of splitting the Linux page into grants
and call a function given by the caller on
Many PV drivers contain the idiom:
pfn = page_to_gfn(...) /* Or similar */
gnttab_grant_foreign_access_ref
Replace it by a new helper. Note that when Linux is using a different
page granularity than Xen, the helper only gives access to the first 4KB
grant.
This is useful where drivers are
On ARM all dma-capable devices on a same platform may not be protected
by an IOMMU. The DMA requests have to use the BFN (i.e MFN on ARM) in
order to use correctly the device.
While the DOM0 memory is allocated in a 1:1 fashion (PFN == MFN), grant
mapping will screw this contiguous mapping.
When
The skb doesn't change within the function. Therefore it's only
necessary to check if we need GSO once at the beginning.
Signed-off-by: Julien Grall
Acked-by: Wei Liu
---
Cc: Ian Campbell
Cc: net...@vger.kernel.org
Changes in v4:
- Add Wei's acked
Changes in v2:
-
The Xen hypercall interface is always using 4K page granularity on ARM
and x86 architecture.
With the incoming support of 64K page granularity for ARM64 guest, it
won't be possible to re-use the Linux page definition in Xen drivers.
Introduce Xen page definition helpers based on the Linux page
Prepare the code to support 64KB page granularity. The first
implementation will use a full Linux page per indirect and persistent
grant. When non-persistent grant is used, each page of a bio request
may be split in multiple grant.
Furthermore, the field page of the grant structure is only used
They are not used in common code expect in one place in balloon.c which is
only compiled when Linux is using PV MMU. It's not the case on ARM.
Rather than worrying how to handle the 64KB case, drop them.
Signed-off-by: Julien Grall
Reviewed-by: Stefano Stabellini
---
Cc: Russell King
On Mon, 7 Sep 2015, Arnd Bergmann wrote:
> Given how much more common 1GB hardware configurations are compared to 768MB
> configuration, we could however think about adding a VMSPLIT_3G_OPT option
> that x86 has (also VMSPLIT_2_75G on ARCH_TILE), to allow using the entire
> 1GB of lowmem without
Hi Al,
On 19/08/15 23:07, Al Stone wrote:
I finally got a chance to try this series on Juno. Well it exposed a
firmware bug in MADT table :)
[..]
acpi_tbl_entry_handler handler,
@@ -245,6 +484,8 @@ acpi_parse_entries(char *id, unsigned long table_size,
The following changes since commit 64291f7db5bd8150a74ad2036f1037e6a0428df2:
Linux 4.2 (2015-08-30 11:34:09 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
tags/regmap-v4.3
for you to fetch changes up to
On Fri 2015-09-04 16:49:46, Paul E. McKenney wrote:
> On Fri, Sep 04, 2015 at 02:11:30PM +0200, Petr Mladek wrote:
> > The deadline to force the quiescent state (jiffies_force_qs) is currently
> > updated only when the previous timeout passed. But the timeout used for
> > wait_event() is always
On Fri, Jul 31, 2015 at 04:33:59PM -0500, Shenwei Wang wrote:
> IMX7D contains a new version of GPC IP block (GPCv2). It has two
> major functions: power management and wakeup source management.
>
> GPCv2 provides low power mode control for Cortex-A7 and Cortex-M4
> domains. And it can support
I executed a clone detection tool* on drivers source code and I found
that there are similar files between drivers/gpu/drm/amd/ and
drivers/gpu/drm/radeon, but also inside each of theses folders.
Some examples:
drivers/gpu/drm/amd/amdgpu/dce_v11_0.c,drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
req->rc is pre-allocated early on with p9_tag_alloc and shouldn't be missing
Signed-off-by: Dominique Martinet
---
net/9p/trans_fd.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
Feel free to adapt error code/message if you can think of something better.
diff --git
From: Christophe Leroy
> Sent: 07 September 2015 15:25
...
> diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
> index 2ef50c6..05b3096 100644
> --- a/arch/powerpc/lib/copy_32.S
> +++ b/arch/powerpc/lib/copy_32.S
> @@ -172,7 +172,16 @@ _GLOBAL(memcpy)
> mtctr r0
>
On 09/07/2015 04:13 PM, Muhammad Falak R Wani wrote:
Use of resource-managed function devm_led_classdev_register
instead of led_classdev_register is preferred, consequently
remove redundant function micro_leds_remove.
Signed-off-by: Muhammad Falak R Wani
---
drivers/leds/leds-ipaq-micro.c |
On Mon, 7 Sep 2015, Marc Zyngier wrote:
> On 07/09/15 14:24, Thomas Gleixner wrote:
> > The history of this flag is as follows:
> >
> > On x86 interrupts can only be safely migrated while the interrupt is
> > handled.
>
> Woa! That's creative! :-) I suppose this doesn't work very well with CPU
>
On Fri 2015-09-04 16:24:22, Paul E. McKenney wrote:
> On Fri, Sep 04, 2015 at 02:11:29PM +0200, Petr Mladek wrote:
> > The value of "fqs_state" in struct rcu_state is always RCU_GP_IDLE.
> >
> > The real state is stored in a local variable in rcu_gp_kthread().
> > It is modified by rcu_gp_fqs()
On Fri, Sep 04, 2015 at 03:23:05PM +0100, Jungseok Lee wrote:
> Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation
> is not needed in kernel_entry. Currently, S_SP information is vaild only
> when sp_el0 is used.
I don't think this is true. The generic BUG implementation will
Hi Thomas,
On 07/09/15 14:24, Thomas Gleixner wrote:
> On Mon, 7 Sep 2015, Marc Zyngier wrote:
>> On 06/09/15 06:56, Jiang Liu wrote:
>>> On 2015/9/6 12:23, Yang Yingliang wrote:
Use irq_settings_set_move_pcntxt() helper irqs status with
_IRQ_MOVE_PCNTXT. So that it can do set affinity
On Mon, Sep 07 2015, Christophe Leroy wrote:
> memcpy() uses instruction dcbz to speed up copy by not wasting time
> loading cache line with data that will be overwritten.
> Some platform like mpc52xx do no have cache active at startup and
> can therefore not use memcpy(). Allthough no part of the
On 06/09/2015 21:38, Ezequiel Garcia wrote:
> On 27 Jul 02:50 PM, Alex Smith wrote:
>> Hi,
>>
>> This series adds support for the BCH controller and NAND devices on
>> the Ingenic JZ4780 SoC.
>>
>> Tested on the MIPS Creator Ci20 board. All dependencies are now in
>> mainline so it should be
Hi Muhammad,
On 09/07/2015 04:13 PM, Muhammad Falak R Wani wrote:
Spaces at the starting of a line are removed, indentation
using tab, instead of space. Also, warnings related to
line width of more than 80 characters is also taken care of.
Two warnings have been left alone to aid better
Hi,
On 06/09/2015 22:21, Ezequiel Garcia wrote:
> On 27 Jul 03:21 PM, Alex Smith wrote:
>> Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
>> well as the hardware BCH controller. DMA is not currently implemented.
>>
>> While older 47xx SoCs also have a BCH controller, they
On 04/09/15 15:23, Jungseok Lee wrote:
> Under EL1h, S_SP data is not seen in kernel_exit. Thus, x21 calculation
> is not needed in kernel_entry. Currently, S_SP information is vaild only
> when sp_el0 is used.
>
> Signed-off-by: Jungseok Lee
> diff --git a/arch/arm64/kernel/entry.S
On 04/09/15 15:23, Jungseok Lee wrote:
> Currently, kernel context and interrupts are handled using a single
> kernel stack navigated by sp_el1. This forces many systems to use
> 16KB stack, not 8KB one. Low memory platforms naturally suffer from
> both memory pressure and performance degradation
I executed a clone detection tool* on drivers source code and I found
that the files
drivers/usb/host/fusbh200-hcd.c
and
drivers/usb/host/fotg210-hcd.c
are very similar. The main difference between the two files are
replacing the string 'USBH20' by 'OTG21' and some white space fixes.
Some
On 07/09/15 13:42, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 11:24:49AM +0200, Peter Zijlstra wrote:
>
>> A quick run here gives:
>>
>> IVB-EP (2*20*2):
>
> As noted by someone; that should be 2*10*2, for a total of 40 cpus in
> this machine.
>
>>
>> perf stat --null --repeat 10 -- perf
Each of the Goodix devices supported by this driver has a fixed size for
the configuration information registers. The size varies depending on the
device and is specified in the datasheet.
Use the proper configuration length as specified in the datasheet for
each device model, so we do not read
Goodix devices can be configured by writing custom data to the device at
init. The configuration data is read with request_firmware from
"goodix__cfg.bin", where is the product id read from the device
(e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
GT9271).
The configuration
Use goodix_i2c_write_u8 instead of i2c_master_send to simplify code.
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index
Goodix devices have a configuration information register area that
specify various parameters for the device. The configuration information
has a specific format described in the Goodix datasheet. It includes X/Y
resolution, maximum supported touch points, interrupt flags, various
sesitivity
Having to handle interrupts on top of an existing kernel stack means the
kernel stack must be large enough to accomodate both the maximum kernel
usage, and the maximum irq handler usage. Switching to a different stack
when processing irqs allows us to make the stack size smaller.
Maximum kernel
Add support for runtime power management so that the device is
turned off when not used (when the userspace holds no open
handles of the input device). The device uses autosuspend with a
default delay of 2 seconds, so the device will suspend if no
handles to it are open for 2 seconds.
The runtime
Add ESD (Electrostatic Discharge) protection mechanism.
The driver enables ESD protection in HW and checks a register
to determine if ESD occurred. If ESD is signalled by the HW,
the driver will reset the device.
The ESD poll time (in ms) can be set through the sysfs property
esd_timeout. If it
Hi Ezequiel,
Thanks for reviewing the series.
On 06/09/2015 21:37, Ezequiel Garcia wrote:
> On 27 Jul 02:50 PM, Alex Smith wrote:
>> If nand_wait_ready() times out, this is silently ignored, and its
>> caller will then proceed to read from/write to the chip before it is
>> ready. This can
Implement suspend/resume for goodix driver.
The suspend and resume process uses the gpio pins.
If the device ACPI/DT information does not declare gpio pins,
suspend/resume will not be available for these devices.
This is based on Goodix datasheets for GT911 and GT9271
and on Goodix driver
Signed-off-by: Irina Tirdea
---
drivers/input/touchscreen/goodix.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c
b/drivers/input/touchscreen/goodix.c
index e36162b..6ae28c5 100644
--- a/drivers/input/touchscreen/goodix.c
+++
After power on, it is recommended that the driver resets the device.
The reset procedure timing is described in the datasheet and is used
at device init (before writing device configuration) and
for power management. It is a sequence of setting the interrupt
and reset pins high/low at specific
Add several enhancements to the Goodix touchscreen driver.
This version adds runtime power management and includes some cleanup.
Thanks,
Irina
Changes in v5:
- add some more style cleanup (reorder includes, use error instead
of ret for return values)
- add runtime power management patch
When building with allmodconfig the build was failing with the error:
arch/tile/kernel/usb.c:70:1: warning: data definition has no type or storage
class [enabled by default]
arch/tile/kernel/usb.c:70:1: error: type defaults to 'int' in declaration of
'arch_initcall' [-Werror=implicit-int]
Commit d49e46950772 ("perf evsel: Add a backpointer to the evlist
a evsel is in") updated perf_evlist__add() but not
perf_evlist__splice_list_tail().
This illustrates that it is better if perf_evlist__splice_list_tail()
calls perf_evlist__add() instead of duplicating the logic, so do that.
This
perf_evlist__propagate_maps() cannot easily tell if an evsel
has its own cpu map. To make that simpler, keep a copy of
the PMU cpu map and adjust the propagation logic accordingly.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 5 -
tools/perf/util/evsel.c| 1 +
On 04/09/15 15:23, Jungseok Lee wrote:
> ARM64 kernel allocates 16KB kernel stack when creating a process. In case
> of low memory platforms with tough workloads on userland, this order-2
> allocation request reaches to memory pressure and performance degradation
> simultaenously since VM page
Subsequent patches will need to call perf_evlist__propagate_maps
without reference to a "target". Add evlist->has_user_cpus to
record whether the user has specified which cpus to target
(and therefore whether that list of cpus should override the
default settings for a selected event i.e. the cpu
The .state is used by several threads of execution.
Propagate the state to make changes visible. Also propagate context
change in hv_fcopy_onchannelcallback.
Without this change fcopy may hang at random points.
Signed-off-by: Olaf Hering
---
drivers/hv/hv_fcopy.c | 36
perf_evlist__propagate_maps() incorrectly assumes evsel->threads
is NULL before reassigning it, but it won't be NULL when
perf_evlist__set_maps() is used to set different (or NULL) maps.
Thus thread_map__put must be used, which works even if
evsel->threads is NULL.
Signed-off-by: Adrian Hunter
Subsequent fixes will need a function that just propagates maps
for a single evsel so factor it out.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 37 +
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/tools/perf/util/evlist.c
The test titled "Test number of exit event of a simple workload"
was setting cpu/thread maps directly. Make it use the proper
function perf_evlist__set_maps() especially now that it also
propagates the maps.
Signed-off-by: Adrian Hunter
---
tools/perf/tests/task-exit.c | 22
The validation checks that the values that were just assigned, got
assigned i.e. the error can't ever happen. Subsequent patches will
call this code in places where errors are not being returned.
Changing those code paths to return this non-existent error is
counter-productive, so just remove it.
Fix it by making it call perf_evlist__set_maps() instead of
setting the maps itself.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index
Since there is a function to set maps, perf_evlist__create_maps()
should use it.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index
Make perf_evlist__set_maps() more resilient by allowing for the
possibility that one or another of the maps isn't being changed
and therefore should not be "put".
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
If evsels are added after maps are created, then they won't
have any maps propagated to them. Fix that.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 56 +---
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git
Don't need to check for NULL when "putting" evlist->maps and
evlist->threads because the "put" functions already do that.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/evlist.c
The test titled "Test software clock events have valid period values"
was setting cpu/thread maps directly. Make it use the proper
function perf_evlist__set_maps() especially now that it also
propagates the maps.
Signed-off-by: Adrian Hunter
---
tools/perf/tests/sw-clock.c | 22
If evsel->cpus is to be reassigned then the current value
must be "put", which works even if it is NULL. Simplify
the current logic by moving the "put" next to the assignment.
Signed-off-by: Adrian Hunter
---
tools/perf/util/evlist.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
Hi
Here is V2 of "Fix gaps propagating maps" that fixes some problems
revealed by to d988d5ee6478 ("perf evlist: Open event on evsel cpus and
threads")
Changes in V2:
Split into multiple patches
Add evsel->own_cpus to identify evsels with their own cpu map
And
The Copy-VMFile cmdlet on the host may fail because the guest fcopy
driver state machine gets out of sync. This happens because the ->state
and ->context variables are accessed by the main thread and from
interrupt context. If an interrupt happens between fcopy_respond_to_host
and hv_poll_channel
The callbacks in kvp, vss and fcopy code are called the main thread and
also from interrupt context. If a state change is done by the main
thread it is not immediately seen by the interrupt. As a result the
state machine gets out of sync.
Force propagation of state changes via get/set helpers
The .state is used by several threads of execution.
Propagate the state to make changes visible. Also propagate context
change in vss_on_msg.
Signed-off-by: Olaf Hering
---
drivers/hv/hv_snapshot.c | 37 -
1 file changed, 20 insertions(+), 17 deletions(-)
The .state is used by several threads of execution.
Propagate the state to make changes visible. Also propagate context
change in kvp_on_msg.
Signed-off-by: Olaf Hering
---
drivers/hv/hv_kvp.c | 38 +-
1 file changed, 21 insertions(+), 17 deletions(-)
diff
Use memset() to null out the btrfs_delayed_ref_root of
btrfs_transaction instead of setting all the members to 0 by hand.
Signed-off-by: Alexandru Moise <00moses.alexande...@gmail.com>
---
Rather than setting each member of ->delayed_refs by hand we should
adhere to the practice of using memset()
On Mon, Sep 07, 2015 at 04:01:22PM +0200, David Sterba wrote:
> So, updated patches should mention that in the subject eg:
>
> [PATCH v2] btrfs: memset cur_trans->delayed_refs to zero
>
> On Mon, Sep 07, 2015 at 04:45:02PM +0300, Alexandru Moise wrote:
> > Use memset() to null out the
memcpy() uses instruction dcbz to speed up copy by not wasting time
loading cache line with data that will be overwritten.
Some platform like mpc52xx do no have cache active at startup and
can therefore not use memcpy(). Allthough no part of the code
explicitly uses memcpy(), GCC makes calls to
Hi Takashi,
Thanks for chasing this.
Milo, could you express your opinion?
On 09/07/2015 02:25 PM, Takashi Iwai wrote:
The commit [b67893206fc0: leds:lp55xx: fix firmware loading error]
tries to address the firmware file handling with user helper, but it
sets a wrong Kconfig
On Tue, Sep 01, 2015 at 09:51:32AM +0200, Christian Borntraeger wrote:
> Am 28.08.2015 um 15:49 schrieb Alexander Kuleshov:
> > arch/s390/kernel/swsusp.S | 49
> > ---
> > 1 file changed, 17 insertions(+), 32 deletions(-)
> >
> > diff --git
zcomp_create() verifies the success of zcomp_strm_{multi,siggle}_create()
through comp->stream, which can potentially be pointing to memory that was
freed if these functions returned an error.
Fixes: beca3ec71fe5 ("zram: add multi stream functionality")
Cc: sta...@vger.kernel.org
Signed-off-by:
From: Colin Ian King
Commit f368ed6088ae9 ("char: make misc_deregister a void function")
did not remove unused variable res and now we get a build warning:
drivers/rtc/rtc-ds1374.c: In function 'ds1374_remove':
drivers/rtc/rtc-ds1374.c:667:6: warning: unused variable 'res'
[-Wunused-variable]
On Mon, Sep 07, 2015 at 10:33:32PM +0900, Sergey Senozhatsky wrote:
> On (09/07/15 13:53), Luis Henriques wrote:
> > > On (09/07/15 11:33), Luis Henriques wrote:
> > > > zcomp_create() verifies the success of
> > > > zcomp_strm_{multi,siggle}_create()
> > > > through comp->stream, which can
On Sep 5, 2015, at 2:12 AM, Alexnader Kuleshov wrote:
> Hello Jungseok,
Hello Alexnader,
> On 09-04-15, Jungseok Lee wrote:
>> +config IRQ_STACK
>> +bool "Use separate kernel stack when handling interrupts"
>> +depends on ARM64_4K_PAGES
>> +help
>> + Say Y here if you want to
Hello,
On 09/03/2015 06:00 PM, Javier Martinez Canillas wrote:
> The uvc driver creates the pads links before the media entity is
> registered with the media device. This doesn't work now that obj
> IDs are used to create links so the media_device has to be set.
>
> Move entities registration
Spaces at the starting of a line are removed, indentation
using tab, instead of space. Also, warnings related to
line width of more than 80 characters is also taken care of.
Two warnings have been left alone to aid better readability.
Signed-off-by: Muhammad Falak R Wani
---
201 - 300 of 1136 matches
Mail list logo
