call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Acked-by: Tejun Heo
Signed-off-by: Colin Cross
---
drivers/staging/an
call because
it doesn't hold any locks or release any resources when interrupted
that might be needed by another freezing task or a kernel driver
during suspend, and is a common site where idle userspace tasks are
blocked.
Signed-off-by: Colin Cross
---
drivers/staging/android/binder.c | 5 +++
Avoid waking up every thread sleeping in a binder call during
suspend and resume by calling a freezable blocking call.
Signed-off-by: Colin Cross
---
drivers/staging/android/binder.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/android/binder.c b
.
Cc: stable
Cc: Dae S. Kim
Signed-off-by: Colin Cross
---
drivers/staging/android/android_alarm.h |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/android_alarm.h
b/drivers/staging/android/android_alarm.h
index f2ffd96..d0cafd6 100644
--- a
On Sat, Jul 7, 2012 at 4:05 PM, Greg KH wrote:
> On Sat, Jul 07, 2012 at 03:39:09PM -0700, Colin Cross wrote:
>> On many (most?) ARM SoCs, the reboot flag is not stored on disk, or
>> anywhere else userspace can access. It is stored in a power
>> management controller
On Sun, Jul 1, 2012 at 5:10 PM, NeilBrown wrote:
> On Fri, 29 Jun 2012 21:37:36 -0700 Colin Cross wrote:
>
>> What's the point of the existing syscall option if it doesn't work on
>> all platforms, or at least all platforms that want to support it? It
>> doesn
On Fri, Jun 29, 2012 at 9:19 PM, Greg KH wrote:
> On Fri, Jun 29, 2012 at 08:43:34PM -0700, Colin Cross wrote:
>> On Fri, Jun 29, 2012 at 8:23 PM, Greg KH wrote:
>> > On Fri, Jun 29, 2012 at 12:36:30PM -0700, Andrew Boie wrote:
>> >> Android userspace tells the ker
On Fri, Jun 29, 2012 at 8:23 PM, Greg KH wrote:
> On Fri, Jun 29, 2012 at 12:36:30PM -0700, Andrew Boie wrote:
>> Android userspace tells the kernel that it wants to boot into recovery
>> or some other non-default OS environment by passing a string argument
>> to reboot(). It is left to the OEM to
On Fri, Jun 15, 2012 at 3:19 PM, Luck, Tony wrote:
>> milli-seconds for recording? This would cripple the kernel. On slow
>> machines, incorporating lockdep into function tracing (and other debug
>> options) causes the system to live lock. Tracing the timer interrupt
>> took so long that by the ti
On Fri, Jun 15, 2012 at 3:00 PM, Luck, Tony wrote:
>> With function tracing the impact to performance is tremendous. Just
>> recording two long words is a 130% hit to performance. Now multiply that
>> to recording strings.
>
> If pstore is writing to a flash based backend - then there will be many
On Fri, May 11, 2012 at 5:17 PM, Anton Vorontsov
wrote:
> This includes devices' memory (e.g. framebuffers or memory mapped
> EEPROMs on a local bus), as well as the normal RAM that we don't use
> for the main memory.
>
> For the normal (but unused) ram we could use kmaps, but this assumes
> highm
On Tue, May 22, 2012 at 7:17 AM, Anton Vorontsov
wrote:
> Otherwise, the files will survive just one reboot, and on a subsequent
> boot they will disappear.
>
> Also, as noticed by Colin Cross, this also causes an interesting behavior
> change in the console logging. Before t
On Fri, May 18, 2012 at 3:24 PM, Anton Vorontsov
wrote:
> Without the update, we'll only see the new dmesg buffer after the
> reboot, but previously we could see it right away. Making an oops
> visible in pstore filesystem before reboot is a somewhat dubious
> feature, but removing it wasn't an in
On Fri, May 18, 2012 at 3:24 PM, Anton Vorontsov
wrote:
> Otherwise, unlinked file will reappear on the next boot.
>
> Reported-by: Kees Cook
> Signed-off-by: Anton Vorontsov
> ---
> fs/pstore/ram.c | 1 +
> fs/pstore/ram_core.c | 6 ++
> include/linux/pstore_ram.h |
On Fri, May 18, 2012 at 3:24 PM, Anton Vorontsov
wrote:
> Otherwise, the files will survive just one reboot, and on a subsequent
> boot they will disappear.
>
> Signed-off-by: Anton Vorontsov
> ---
> fs/pstore/ram_core.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/pstore/ram_c
On Thu, May 17, 2012 at 1:37 AM, Anton Vorontsov
wrote:
> Hi all,
>
> In v2:
>
> - Updated documentation per Colin Cross' comments;
> - Corrected return value in ramoops_pstore_write() (noticed by Kees Cook);
> - Fixed large writes handling in pstore_console_write(), i.e
On Thu, May 17, 2012 at 1:40 AM, Anton Vorontsov
wrote:
> This is all straightforward: we just use the last region for
> console logging. If there's just one region, we fall-back to
> the old behaviour: just a oops/dumps logging.
>
> Signed-off-by: Anton Vorontsov
I don't think using the last re
On Wed, May 16, 2012 at 3:11 PM, Anton Vorontsov wrote:
> On Wed, May 16, 2012 at 10:56:09AM -0700, Colin Cross wrote:
> [...]
>> > +You can specify either RAM memory or peripheral devices' memory. However,
>> > when
>> > +specifying RAM, be
On Wed, May 16, 2012 at 5:56 AM, Anton Vorontsov
wrote:
> Suggested-by: Shuah Khan
> Signed-off-by: Anton Vorontsov
> ---
> Documentation/ramoops.txt | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
> index 4ba7db2
On Fri, May 11, 2012 at 5:17 PM, Anton Vorontsov
wrote:
> The routine just creates a persistent ram zone at a specified address.
>
> For persistent_ram_init_ringbuffer() we'd need to add a
> 'struct persistent_ram' to the global list, and associate it with a
> device. We don't need all this comple
persistent_ram_zone *prz,
> c = prz->buffer_size;
> }
>
> - buffer_size_add_clamp(prz, c);
> + buffer_size_add(prz, c);
>
> start = buffer_start_add(prz, c);
>
> --
> 1.7.9.2
>
Acked-by: Colin Cross
This is a bug f
_SIG) {
> if (buffer_size(prz) > prz->buffer_size ||
> @@ -442,6 +442,9 @@ struct persistent_ram_zone *__persistent_ram_init(struct
> device *dev, bool ecc)
> atomic_set(&prz->buffer->size, 0);
>
> return prz;
&g
22 matches
Mail list logo
