* Re: [PATCH 3/3] backports: empty define for __ro_after_init
From: Arend Van Spriel @ 2016-11-14 19:26 UTC (permalink / raw)
To: Luis R. Rodriguez, Johannes Berg, Kees Cook; +Cc: backports
In-Reply-To: <20161114185917.GZ13978@wotan.suse.de>
On 14-11-2016 19:59, Luis R. Rodriguez wrote:
> On Sat, Nov 12, 2016 at 10:07:22PM +0100, Johannes Berg wrote:
>> On Sat, 2016-11-12 at 20:18 +0000, Arend van Spriel wrote:
>>> nl80211 now uses section qualifier __ro_after_init. However, this
>>> is not available in kernels before v4.6. Neither is the section
>>> itself hence adding an empty define in backports.
>>
>>> +#if (LINUX_VERSION_CODE < KERNEL_VERSION(4,6,0))
>>> +#define __ro_after_init
>>> +#endif
>>
>> Due to how __ro_after_init works, it *has* to be a macro originally, so
>> you could just ifndef on itself:
>>
>> #ifndef __ro_after_init
>> #define __ro_after_init
>> #endif
>>
>> and be slightly more compatible in case somebody ever backports it.
>
> Agreed.
Agree as well hence I posted a V2 yesterday ;-)
Regards,
Arend
--
To unsubscribe from this list: send the line "unsubscribe backports" in
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 18/21] qmp: add x-debug-block-dirty-bitmap-sha256
From: John Snow @ 2016-11-14 19:25 UTC (permalink / raw)
To: Vladimir Sementsov-Ogievskiy, qemu-block, qemu-devel
Cc: kwolf, famz, armbru, mreitz, stefanha, pbonzini, den
In-Reply-To: <1478715476-132280-19-git-send-email-vsementsov@virtuozzo.com>
On 11/09/2016 01:17 PM, Vladimir Sementsov-Ogievskiy wrote:
> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
> ---
> block/dirty-bitmap.c | 5 +++++
> blockdev.c | 33 +++++++++++++++++++++++++++++++++
> include/block/dirty-bitmap.h | 2 ++
> include/qemu/hbitmap.h | 8 ++++++++
> qapi/block-core.json | 26 ++++++++++++++++++++++++++
> util/hbitmap.c | 11 +++++++++++
> 6 files changed, 85 insertions(+)
>
> diff --git a/block/dirty-bitmap.c b/block/dirty-bitmap.c
> index fe34d48..775181c 100644
> --- a/block/dirty-bitmap.c
> +++ b/block/dirty-bitmap.c
> @@ -589,3 +589,8 @@ BdrvDirtyBitmap *bdrv_dirty_bitmap_next(BlockDriverState *bs,
> return bitmap == NULL ? QLIST_FIRST(&bs->dirty_bitmaps) :
> QLIST_NEXT(bitmap, list);
> }
> +
> +char *bdrv_dirty_bitmap_sha256(const BdrvDirtyBitmap *bitmap, Error **errp)
> +{
> + return hbitmap_sha256(bitmap->bitmap, errp);
> +}
> diff --git a/blockdev.c b/blockdev.c
> index db2bdbb..c028070 100644
> --- a/blockdev.c
> +++ b/blockdev.c
> @@ -2811,6 +2811,39 @@ void qmp_block_dirty_bitmap_clear(const char *node, const char *name,
> aio_context_release(aio_context);
> }
>
> +/**
> + * Completely clear a bitmap, for the purposes of synchronizing a bitmap
> + * immediately after a full backup operation.
> + */
> +BlockDirtyBitmapSha256 *qmp_x_debug_block_dirty_bitmap_sha256(const char *node,
> + const char *name,
> + Error **errp)
> +{
> + AioContext *aio_context;
> + BdrvDirtyBitmap *bitmap;
> + BlockDriverState *bs;
> + BlockDirtyBitmapSha256 *ret = NULL;
> + char *sha256;
> +
> + bitmap = block_dirty_bitmap_lookup(node, name, &bs, &aio_context, errp);
> + if (!bitmap || !bs) {
> + return NULL;
> + }
> +
> + sha256 = bdrv_dirty_bitmap_sha256(bitmap, errp);
> + if (sha256 == NULL) {
> + goto out;
> + }
> +
> + ret = g_new(BlockDirtyBitmapSha256, 1);
> + ret->sha256 = sha256;
> +
> +out:
> + aio_context_release(aio_context);
> +
> + return ret;
> +}
> +
> void hmp_drive_del(Monitor *mon, const QDict *qdict)
> {
> const char *id = qdict_get_str(qdict, "id");
> diff --git a/include/block/dirty-bitmap.h b/include/block/dirty-bitmap.h
> index d71edc4..b022b34 100644
> --- a/include/block/dirty-bitmap.h
> +++ b/include/block/dirty-bitmap.h
> @@ -86,4 +86,6 @@ BdrvDirtyBitmap *bdrv_dirty_bitmap_next(BlockDriverState *bs,
>
> bool bdrv_has_persistent_bitmaps(BlockDriverState *bs);
>
> +char *bdrv_dirty_bitmap_sha256(const BdrvDirtyBitmap *bitmap, Error **errp);
> +
> #endif
> diff --git a/include/qemu/hbitmap.h b/include/qemu/hbitmap.h
> index 5c9dd74..d6f3838 100644
> --- a/include/qemu/hbitmap.h
> +++ b/include/qemu/hbitmap.h
> @@ -240,6 +240,14 @@ void hbitmap_deserialize_ones(HBitmap *hb, uint64_t start, uint64_t count,
> void hbitmap_deserialize_finish(HBitmap *hb);
>
> /**
> + * hbitmap_sha256:
> + * @bitmap: HBitmap to operate on.
> + *
> + * Returns SHA256 hash of the last level.
> + */
> +char *hbitmap_sha256(const HBitmap *bitmap, Error **errp);
> +
> +/**
> * hbitmap_free:
> * @hb: HBitmap to operate on.
> *
> diff --git a/qapi/block-core.json b/qapi/block-core.json
> index 2c33a30..f72cfef 100644
> --- a/qapi/block-core.json
> +++ b/qapi/block-core.json
> @@ -1289,6 +1289,32 @@
> 'data': 'BlockDirtyBitmap' }
>
> ##
> +# @BlockDirtyBitmapSha256:
> +#
> +# SHA256 hash of dirty bitmap data
> +#
> +# @sha256: bitmap SHA256 hash
> +#
> +# Since: 2.8
> +##
> + { 'struct': 'BlockDirtyBitmapSha256',
> + 'data': {'sha256': 'str'} }
> +
> +##
> +# @x-debug-block-dirty-bitmap-sha256
> +#
> +# Get bitmap SHA256
> +#
> +# Returns: BlockDirtyBitmapSha256 on success
> +# If @node is not a valid block device, DeviceNotFound
> +# If @name is not found, GenericError with an explanation
> +#
> +# Since 2.8
> +##
> + { 'command': 'x-debug-block-dirty-bitmap-sha256',
> + 'data': 'BlockDirtyBitmap', 'returns': 'BlockDirtyBitmapSha256' }
> +
> +##
> # @blockdev-mirror
> #
> # Start mirroring a block device's writes to a new destination.
> diff --git a/util/hbitmap.c b/util/hbitmap.c
> index 72623f4..96af071 100644
> --- a/util/hbitmap.c
> +++ b/util/hbitmap.c
> @@ -13,6 +13,7 @@
> #include "qemu/hbitmap.h"
> #include "qemu/host-utils.h"
> #include "trace.h"
> +#include "crypto/hash.h"
>
> /* HBitmaps provides an array of bits. The bits are stored as usual in an
> * array of unsigned longs, but HBitmap is also optimized to provide fast
> @@ -707,3 +708,13 @@ void hbitmap_free_meta(HBitmap *hb)
> hbitmap_free(hb->meta);
> hb->meta = NULL;
> }
> +
> +char *hbitmap_sha256(const HBitmap *bitmap, Error **errp)
> +{
> + size_t size = bitmap->sizes[HBITMAP_LEVELS - 1] * sizeof(unsigned long);
> + char *data = (char *)bitmap->levels[HBITMAP_LEVELS - 1];
> + char *hash = NULL;
> + qcrypto_hash_digest(QCRYPTO_HASH_ALG_SHA256, data, size, &hash, errp);
By adding this here, you're adding a linking dependency to
libqemuutil.a, which causes the test-hbitmap test to fail to link from
this patch forward.
I'm not sure what the correct approach should be, but at a minimum we
need to link crypto/hash.o to test/test-hbitmap.o to be able to run that
test. We get build failures otherwise.
> +
> + return hash;
> +}
>
^ permalink raw reply
* Re: [PATCH v7 00/17] port branch.c to use ref-filter's printing options
From: Karthik Nayak @ 2016-11-14 19:24 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xqRjMThZF7u_W6G0sHjFP3j5PMr=TszC6UxL2XCYO+CVA@mail.gmail.com>
Hello,
On Wed, Nov 9, 2016 at 5:45 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 12:11 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> This is part of unification of the commands 'git tag -l, git branch -l
>> and git for-each-ref'. This ports over branch.c to use ref-filter's
>> printing options.
>>
>> Initially posted here: $(gmane/279226). It was decided that this series
>> would follow up after refactoring ref-filter parsing mechanism, which
>> is now merged into master (9606218b32344c5c756f7c29349d3845ef60b80c).
>>
>> v1 can be found here: $(gmane/288342)
>> v2 can be found here: $(gmane/288863)
>> v3 can be found here: $(gmane/290299)
>> v4 can be found here: $(gmane/291106)
>> v5b can be found here: $(gmane/292467)
>> v6 can be found here: http://marc.info/?l=git&m=146330914118766&w=2
>>
>
> I reviewed the full series. I found a few minor things I would have
> done differently, but overall I think it looks good. Thanks for the
> hard work and the time invested here. I remember seeing this on the
> list quite some time ago, so it's nice to see it finally come
> together.
>
Thanks for the review. I've gone through all the mails and will follow
up with replies.
Will post the next version as soon as possible. Thanks.
--
Regards,
Karthik Nayak
^ permalink raw reply
* [PATCH 2/2] blk-mq: Avoid memory reclaim when remapping queues
From: Gabriel Krisman Bertazi @ 2016-11-14 19:24 UTC (permalink / raw)
To: axboe
Cc: linux-block, Gabriel Krisman Bertazi, Brian King, Douglas Miller,
linux-scsi
In-Reply-To: <1479151478-19725-1-git-send-email-krisman@linux.vnet.ibm.com>
While stressing memory and IO at the same time we changed SMT settings,
we were able to consistently trigger deadlocks in the mm system, which
froze the entire machine.
I think that under memory stress conditions, the large allocations
performed by blk_mq_init_rq_map may trigger a reclaim, which stalls
waiting on the block layer remmaping completion, thus deadlocking the
system. The trace below was collected after the machine stalled,
waiting for the hotplug event completion.
The simplest fix for this is to make allocations in this path
non-reclaimable, with GFP_NOWAIT. With this patch, We couldn't hit the
issue anymore.
This should apply on top of Jen's for-next branch cleanly.
Call Trace:
[c000000f0160aaf0] [c000000f0160ab50] 0xc000000f0160ab50 (unreliable)
[c000000f0160acc0] [c000000000016624] __switch_to+0x2e4/0x430
[c000000f0160ad20] [c000000000b1a880] __schedule+0x310/0x9b0
[c000000f0160ae00] [c000000000b1af68] schedule+0x48/0xc0
[c000000f0160ae30] [c000000000b1b4b0] schedule_preempt_disabled+0x20/0x30
[c000000f0160ae50] [c000000000b1d4fc] __mutex_lock_slowpath+0xec/0x1f0
[c000000f0160aed0] [c000000000b1d678] mutex_lock+0x78/0xa0
[c000000f0160af00] [d000000019413cac] xfs_reclaim_inodes_ag+0x33c/0x380 [xfs]
[c000000f0160b0b0] [d000000019415164] xfs_reclaim_inodes_nr+0x54/0x70 [xfs]
[c000000f0160b0f0] [d0000000194297f8] xfs_fs_free_cached_objects+0x38/0x60 [xfs]
[c000000f0160b120] [c0000000003172c8] super_cache_scan+0x1f8/0x210
[c000000f0160b190] [c00000000026301c] shrink_slab.part.13+0x21c/0x4c0
[c000000f0160b2d0] [c000000000268088] shrink_zone+0x2d8/0x3c0
[c000000f0160b380] [c00000000026834c] do_try_to_free_pages+0x1dc/0x520
[c000000f0160b450] [c00000000026876c] try_to_free_pages+0xdc/0x250
[c000000f0160b4e0] [c000000000251978] __alloc_pages_nodemask+0x868/0x10d0
[c000000f0160b6f0] [c000000000567030] blk_mq_init_rq_map+0x160/0x380
[c000000f0160b7a0] [c00000000056758c] blk_mq_map_swqueue+0x33c/0x360
[c000000f0160b820] [c000000000567904] blk_mq_queue_reinit+0x64/0xb0
[c000000f0160b850] [c00000000056a16c] blk_mq_queue_reinit_notify+0x19c/0x250
[c000000f0160b8a0] [c0000000000f5d38] notifier_call_chain+0x98/0x100
[c000000f0160b8f0] [c0000000000c5fb0] __cpu_notify+0x70/0xe0
[c000000f0160b930] [c0000000000c63c4] notify_prepare+0x44/0xb0
[c000000f0160b9b0] [c0000000000c52f4] cpuhp_invoke_callback+0x84/0x250
[c000000f0160ba10] [c0000000000c570c] cpuhp_up_callbacks+0x5c/0x120
[c000000f0160ba60] [c0000000000c7cb8] _cpu_up+0xf8/0x1d0
[c000000f0160bac0] [c0000000000c7eb0] do_cpu_up+0x120/0x150
[c000000f0160bb40] [c0000000006fe024] cpu_subsys_online+0x64/0xe0
[c000000f0160bb90] [c0000000006f5124] device_online+0xb4/0x120
[c000000f0160bbd0] [c0000000006f5244] online_store+0xb4/0xc0
[c000000f0160bc20] [c0000000006f0a68] dev_attr_store+0x68/0xa0
[c000000f0160bc60] [c0000000003ccc30] sysfs_kf_write+0x80/0xb0
[c000000f0160bca0] [c0000000003cbabc] kernfs_fop_write+0x17c/0x250
[c000000f0160bcf0] [c00000000030fe6c] __vfs_write+0x6c/0x1e0
[c000000f0160bd90] [c000000000311490] vfs_write+0xd0/0x270
[c000000f0160bde0] [c0000000003131fc] SyS_write+0x6c/0x110
[c000000f0160be30] [c000000000009204] system_call+0x38/0xec
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Cc: Brian King <brking@linux.vnet.ibm.com>
Cc: Douglas Miller <dougmill@linux.vnet.ibm.com>
Cc: linux-block@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
---
block/blk-mq.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 7f7c4ba91adf..3e44303646cb 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1597,7 +1597,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct blk_mq_tag_set *set,
INIT_LIST_HEAD(&tags->page_list);
tags->rqs = kzalloc_node(set->queue_depth * sizeof(struct request *),
- GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY,
+ GFP_NOWAIT | __GFP_NOWARN | __GFP_NORETRY,
set->numa_node);
if (!tags->rqs) {
blk_mq_free_tags(tags);
@@ -1623,7 +1623,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct blk_mq_tag_set *set,
do {
page = alloc_pages_node(set->numa_node,
- GFP_KERNEL | __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO,
+ GFP_NOWAIT | __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO,
this_order);
if (page)
break;
@@ -1644,7 +1644,7 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct blk_mq_tag_set *set,
* Allow kmemleak to scan these pages as they contain pointers
* to additional allocations like via ops->init_request().
*/
- kmemleak_alloc(p, order_to_size(this_order), 1, GFP_KERNEL);
+ kmemleak_alloc(p, order_to_size(this_order), 1, GFP_NOWAIT);
entries_per_page = order_to_size(this_order) / rq_size;
to_do = min(entries_per_page, set->queue_depth - i);
left -= to_do * rq_size;
--
2.7.4
^ permalink raw reply related
* [PATCH 1/2] blk-mq: Fix failed allocation path when mapping queues
From: Gabriel Krisman Bertazi @ 2016-11-14 19:24 UTC (permalink / raw)
To: axboe
Cc: linux-block, Gabriel Krisman Bertazi, Brian King, Douglas Miller,
linux-scsi
In blk_mq_map_swqueue, there is a memory optimization that frees the
tags of a queue that has gone unmapped. Later, if that hctx is remapped
after another topology change, the tags need to be reallocated.
If this allocation fails, a simple WARN_ON triggers, but the block layer
ends up with an active hctx without any corresponding set of tags.
Then, any income IO to that hctx can trigger an Oops.
I can reproduce it consistently by running IO, flipping CPUs on and off
and eventually injecting a memory allocation failure in that path.
In the fix below, if the system experiences a failed allocation of any
hctx's tags, we remap all the ctxs of that queue to the hctx_0, which
should always keep it's tags. There is a minor performance hit, since
our mapping just got worse after the error path, but this is
the simplest solution to handle this error path. The performance hit
will disappear after another successful remap.
I considered dropping the memory optimization all together, but it
seemed a bad trade-off to handle this very specific error case.
My one concern about this patch is if remapping an arbitrary queue to
hctx_0 could result in outstanding requests getting submitted to the
wrong hctx. I couldn't observe this happening during tests, but I'm not
entirely sure it'll never happen. I believe the queue will be empty if
we are trying to allocate tags for it, unless it was using another alive
hctx queue and for some reason got reassigned to this new hctx. is this
possible at all?
This should apply cleanly on top of Jen's for-next branch.
The Oops is the one below:
SP (3fff935ce4d0) is in userspace
1:mon> e
cpu 0x1: Vector: 300 (Data Access) at [c000000fe99eb110]
pc: c0000000005e868c: __sbitmap_queue_get+0x2c/0x180
lr: c000000000575328: __bt_get+0x48/0xd0
sp: c000000fe99eb390
msr: 900000010280b033
dar: 28
dsisr: 40000000
current = 0xc000000fe9966800
paca = 0xc000000007e80300 softe: 0 irq_happened: 0x01
pid = 11035, comm = aio-stress
Linux version 4.8.0-rc6+ (root@bean) (gcc version 5.4.0 20160609
(Ubuntu/IBM 5.4.0-6ubuntu1~16.04.2) ) #3 SMP Mon Oct 10 20:16:53 CDT 2016
1:mon> s
[c000000fe99eb3d0] c000000000575328 __bt_get+0x48/0xd0
[c000000fe99eb400] c000000000575838 bt_get.isra.1+0x78/0x2d0
[c000000fe99eb480] c000000000575cb4 blk_mq_get_tag+0x44/0x100
[c000000fe99eb4b0] c00000000056f6f4 __blk_mq_alloc_request+0x44/0x220
[c000000fe99eb500] c000000000570050 blk_mq_map_request+0x100/0x1f0
[c000000fe99eb580] c000000000574650 blk_mq_make_request+0xf0/0x540
[c000000fe99eb640] c000000000561c44 generic_make_request+0x144/0x230
[c000000fe99eb690] c000000000561e00 submit_bio+0xd0/0x200
[c000000fe99eb740] c0000000003ef740 ext4_io_submit+0x90/0xb0
[c000000fe99eb770] c0000000003e95d8 ext4_writepages+0x588/0xdd0
[c000000fe99eb910] c00000000025a9f0 do_writepages+0x60/0xc0
[c000000fe99eb940] c000000000246c88 __filemap_fdatawrite_range+0xf8/0x180
[c000000fe99eb9e0] c000000000246f90 filemap_write_and_wait_range+0x70/0xf0
[c000000fe99eba20] c0000000003dd844 ext4_sync_file+0x214/0x540
[c000000fe99eba80] c000000000364718 vfs_fsync_range+0x78/0x130
[c000000fe99ebad0] c0000000003dd46c ext4_file_write_iter+0x35c/0x430
[c000000fe99ebb90] c00000000038c280 aio_run_iocb+0x3b0/0x450
[c000000fe99ebce0] c00000000038dc28 do_io_submit+0x368/0x730
[c000000fe99ebe30] c000000000009404 system_call+0x38/0xec
Signed-off-by: Gabriel Krisman Bertazi <krisman@linux.vnet.ibm.com>
Cc: Brian King <brking@linux.vnet.ibm.com>
Cc: Douglas Miller <dougmill@linux.vnet.ibm.com>
Cc: linux-block@vger.kernel.org
Cc: linux-scsi@vger.kernel.org
---
block/blk-mq.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/block/blk-mq.c b/block/blk-mq.c
index 3c5aaead71bb..7f7c4ba91adf 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -1862,7 +1862,7 @@ static void blk_mq_init_cpu_queues(struct request_queue *q,
static void blk_mq_map_swqueue(struct request_queue *q,
const struct cpumask *online_mask)
{
- unsigned int i;
+ unsigned int i, hctx_idx;
struct blk_mq_hw_ctx *hctx;
struct blk_mq_ctx *ctx;
struct blk_mq_tag_set *set = q->tag_set;
@@ -1885,6 +1885,15 @@ static void blk_mq_map_swqueue(struct request_queue *q,
if (!cpumask_test_cpu(i, online_mask))
continue;
+ hctx_idx = q->mq_map[i];
+ /* unmapped hw queue can be remapped after CPU topo changed */
+ if (!set->tags[hctx_idx]) {
+ set->tags[hctx_idx] = blk_mq_init_rq_map(set, hctx_idx);
+
+ if (!set->tags[hctx_idx])
+ q->mq_map[i] = 0;
+ }
+
ctx = per_cpu_ptr(q->queue_ctx, i);
hctx = blk_mq_map_queue(q, i);
@@ -1901,7 +1910,10 @@ static void blk_mq_map_swqueue(struct request_queue *q,
* disable it and free the request entries.
*/
if (!hctx->nr_ctx) {
- if (set->tags[i]) {
+ /* Never unmap queue 0. We need it as a
+ * fallback in case of a new remap fails
+ * allocation. */
+ if (i && set->tags[i]) {
blk_mq_free_rq_map(set, set->tags[i], i);
set->tags[i] = NULL;
}
@@ -1909,11 +1921,8 @@ static void blk_mq_map_swqueue(struct request_queue *q,
continue;
}
- /* unmapped hw queue can be remapped after CPU topo changed */
- if (!set->tags[i])
- set->tags[i] = blk_mq_init_rq_map(set, i);
hctx->tags = set->tags[i];
- WARN_ON(!hctx->tags);
+ BUG_ON(!hctx->tags);
/*
* Set the map size to the number of mapped software queues.
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] tracing: ignore FTRACE_FL_DISABLED while walking dyn_ftrace records
From: Steven Rostedt @ 2016-11-14 19:24 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Dave Jones, Martin KaFai Lau, linux-kernel, kernel-team
In-Reply-To: <1478560460-3818619-1-git-send-email-ast@fb.com>
On Mon, 7 Nov 2016 15:14:20 -0800
Alexei Starovoitov <ast@fb.com> wrote:
> ftrace_shutdown() checks for sanity of ftrace records
> and if dyn_ftrace->flags is not zero, it will warn.
> It can happen that 'flags' are set to FTRACE_FL_DISABLED at this point,
> since some module was loaded, but before ftrace_module_enable()
> cleared the flags for this module.
>
> In other words the module.c is doing:
> ftrace_module_init(mod); // calls ftrace_update_code() that sets flags=FTRACE_FL_DISABLED
> ... // here ftrace_shutdown() is called that warns, since
> err = prepare_coming_module(mod); // didn't have a chance to clear FTRACE_FL_DISABLED
>
> Fix it by ignoring disabled records.
> It's similar to what __ftrace_hash_rec_update() is already doing.
>
Alexei,
Do you have a clear reproducer of this bug?
-- Steve
> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
> ---
> kernel/trace/ftrace.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index 2050a7652a86..326498baab83 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -2763,7 +2763,7 @@ static int ftrace_shutdown(struct ftrace_ops *ops, int command)
> struct dyn_ftrace *rec;
>
> do_for_each_ftrace_rec(pg, rec) {
> - if (FTRACE_WARN_ON_ONCE(rec->flags))
> + if (FTRACE_WARN_ON_ONCE(rec->flags & ~FTRACE_FL_DISABLED))
> pr_warn(" %pS flags:%lx\n",
> (void *)rec->ip, rec->flags);
> } while_for_each_ftrace_rec();
^ permalink raw reply
* Re: [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-14 19:17 UTC (permalink / raw)
To: Neil Armstrong, Martin Blumenstingl
Cc: carlo, linux-amlogic, linux-arm-kernel, linux-kernel, devicetree
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
Since the P23x and Q20x boards are identical, should we just come up
with a singel dtsi for them all? e.g move the -p23x.dtsi to -pq2xx.dtsi
or something?
I don't think it's a big deal, but it does seem like we should avoid the
copy/paste wherever possible.
Kevin
^ permalink raw reply
* Re: [PATCH v7 16/17] branch: use ref-filter printing APIs
From: Karthik Nayak @ 2016-11-14 19:23 UTC (permalink / raw)
To: Jacob Keller; +Cc: Git mailing list
In-Reply-To: <CA+P7+xr20UyKMKUZBpP-SjtEhbow2df+iT6nF67mOAZ8BAaxEg@mail.gmail.com>
Hello
On Wed, Nov 9, 2016 at 5:44 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
> On Tue, Nov 8, 2016 at 12:12 PM, Karthik Nayak <karthik.188@gmail.com> wrote:
>> From: Karthik Nayak <karthik.188@gmail.com>
>>
>> Port branch.c to use ref-filter APIs for printing. This clears out
>> most of the code used in branch.c for printing and replaces them with
>> calls made to the ref-filter library.
>
> Nice. This looks correct based on checking against the current
> branch.c implementation by hand. There was one minor change I
> suggested but I'm not really sure it buys is that much.
>
Thanks for this review. More down.
>> + if (filter->verbose > 1)
>> + strbuf_addf(&local, "%%(if)%%(upstream)%%(then)[%s%%(upstream:short)%s%%(if)%%(upstream:track)"
>> + "%%(then): %%(upstream:track,nobracket)%%(end)] %%(end)%%(contents:subject)",
>> + branch_get_color(BRANCH_COLOR_UPSTREAM), branch_get_color(BRANCH_COLOR_RESET));
>
> When we have extra verbose, we check whether we have an upstream, and
> if so, we print the short name of that upstream inside brackets. If we
> have tracking information, we print that without brackets, and then we
> end this section. Finally we print the subject.
>
> We could almost re-use the code for the subject bits, but I'm not sure
> it's worth it. Maybe drop the %contents:subject part and add it
> afterwards since we always want it? It would remove some duplication
> but overall not sure it's actually worth it.
>
If you see that's the last part we add to the 'local' strbuf in the
verbose case.
If we want to remove the duplication we'll end up adding one more
strbuf_addf(...).
So I guess its better this way.
--
Regards,
Karthik Nayak
^ permalink raw reply
* Re: [PATCH RFC] mm: Add debug_virt_to_phys()
From: Florian Fainelli @ 2016-11-14 19:23 UTC (permalink / raw)
To: Laura Abbott, linux-kernel
Cc: Russell King, Catalin Marinas, Will Deacon, Arnd Bergmann,
Nicolas Pitre, Chris Brandt, Pratyush Anand, Ard Biesheuvel,
Mark Rutland, James Morse, Neeraj Upadhyay, Andrew Morton,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov,
Jerome Marchand, Konstantin Khlebnikov, Joonsoo Kim,
moderated list:ARM PORT,
open list:GENERIC INCLUDE/ASM HEADER FILES,
open list:MEMORY MANAGEMENT
In-Reply-To: <aee5072c-4e09-547e-2f58-7b2106bced3c@redhat.com>
On 11/14/2016 10:45 AM, Laura Abbott wrote:
> On 11/11/2016 04:44 PM, Florian Fainelli wrote:
>> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
>> debug_virt_to_phys() which helps catch vmalloc space addresses being
>> passed. This is helpful in debugging bogus drivers that just assume
>> linear mappings all over the place.
>>
>> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
>> __virt_to_phys() as being the functional implementation of the address
>> translation, so we special case the debug stub to call into
>> __virt_to_phys directly.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/include/asm/memory.h | 4 ++++
>> arch/arm64/include/asm/memory.h | 4 ++++
>> include/asm-generic/memory_model.h | 4 ++++
>> mm/debug.c | 15 +++++++++++++++
>> 4 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>> index 76cbd9c674df..448dec9b8b00 100644
>> --- a/arch/arm/include/asm/memory.h
>> +++ b/arch/arm/include/asm/memory.h
>> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index b71086d25195..c9e436b28523 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -186,11 +186,15 @@ extern u64 kimage_voffset;
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
>> index 5148150cc80b..426085757258 100644
>> --- a/include/asm-generic/memory_model.h
>> +++ b/include/asm-generic/memory_model.h
>> @@ -80,6 +80,10 @@
>> #define page_to_pfn __page_to_pfn
>> #define pfn_to_page __pfn_to_page
>>
>> +#ifdef CONFIG_DEBUG_VM
>> +unsigned long debug_virt_to_phys(volatile void *address);
>> +#endif /* CONFIG_DEBUG_VM */
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif
>> diff --git a/mm/debug.c b/mm/debug.c
>> index 9feb699c5d25..72b2ca9b11f4 100644
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
>> );
>> }
>>
>> +#include <asm/memory.h>
>> +#include <linux/mm.h>
>> +
>> +unsigned long debug_virt_to_phys(volatile void *address)
>> +{
>> + BUG_ON(is_vmalloc_addr((const void *)address));
>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
>> + defined(CONFIG_MICROBLAZE)
>> + return __virt_to_phys(address);
>> +#else
>> + return virt_to_phys(address);
>> +#endif
>> +}
>> +EXPORT_SYMBOL(debug_virt_to_phys);
>> +
>> #endif /* CONFIG_DEBUG_VM */
>>
>
> is_vmalloc_addr is necessary but not sufficient. This misses
> cases like module addresses.
Indeed, thanks.
> The x86 version (CONFIG_DEBUG_VIRTUAL)
> bounds checks against the known linear map to catch all cases.
> I'm for a generic approach to this if it can catch all cases
> that an architecture specific version would catch.
For one, my patch causes an early BUG to occur on ARM64 during
arch/arm64/kernel/setup.c::setup_arch when we call
cpu_uninstall_idmap(). I suspect there could be a bunch of little checks
like these where we'd have to have an architecture specific "is this
physical/virtual address valid" that may make a generic implementation
hard to come up with.
--
Florian
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCH RFC] mm: Add debug_virt_to_phys()
From: Florian Fainelli @ 2016-11-14 19:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <aee5072c-4e09-547e-2f58-7b2106bced3c@redhat.com>
On 11/14/2016 10:45 AM, Laura Abbott wrote:
> On 11/11/2016 04:44 PM, Florian Fainelli wrote:
>> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
>> debug_virt_to_phys() which helps catch vmalloc space addresses being
>> passed. This is helpful in debugging bogus drivers that just assume
>> linear mappings all over the place.
>>
>> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
>> __virt_to_phys() as being the functional implementation of the address
>> translation, so we special case the debug stub to call into
>> __virt_to_phys directly.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/include/asm/memory.h | 4 ++++
>> arch/arm64/include/asm/memory.h | 4 ++++
>> include/asm-generic/memory_model.h | 4 ++++
>> mm/debug.c | 15 +++++++++++++++
>> 4 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>> index 76cbd9c674df..448dec9b8b00 100644
>> --- a/arch/arm/include/asm/memory.h
>> +++ b/arch/arm/include/asm/memory.h
>> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index b71086d25195..c9e436b28523 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -186,11 +186,15 @@ extern u64 kimage_voffset;
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
>> index 5148150cc80b..426085757258 100644
>> --- a/include/asm-generic/memory_model.h
>> +++ b/include/asm-generic/memory_model.h
>> @@ -80,6 +80,10 @@
>> #define page_to_pfn __page_to_pfn
>> #define pfn_to_page __pfn_to_page
>>
>> +#ifdef CONFIG_DEBUG_VM
>> +unsigned long debug_virt_to_phys(volatile void *address);
>> +#endif /* CONFIG_DEBUG_VM */
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif
>> diff --git a/mm/debug.c b/mm/debug.c
>> index 9feb699c5d25..72b2ca9b11f4 100644
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
>> );
>> }
>>
>> +#include <asm/memory.h>
>> +#include <linux/mm.h>
>> +
>> +unsigned long debug_virt_to_phys(volatile void *address)
>> +{
>> + BUG_ON(is_vmalloc_addr((const void *)address));
>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
>> + defined(CONFIG_MICROBLAZE)
>> + return __virt_to_phys(address);
>> +#else
>> + return virt_to_phys(address);
>> +#endif
>> +}
>> +EXPORT_SYMBOL(debug_virt_to_phys);
>> +
>> #endif /* CONFIG_DEBUG_VM */
>>
>
> is_vmalloc_addr is necessary but not sufficient. This misses
> cases like module addresses.
Indeed, thanks.
> The x86 version (CONFIG_DEBUG_VIRTUAL)
> bounds checks against the known linear map to catch all cases.
> I'm for a generic approach to this if it can catch all cases
> that an architecture specific version would catch.
For one, my patch causes an early BUG to occur on ARM64 during
arch/arm64/kernel/setup.c::setup_arch when we call
cpu_uninstall_idmap(). I suspect there could be a bunch of little checks
like these where we'd have to have an architecture specific "is this
physical/virtual address valid" that may make a generic implementation
hard to come up with.
--
Florian
^ permalink raw reply
* Re: [PATCH RFC] mm: Add debug_virt_to_phys()
From: Florian Fainelli @ 2016-11-14 19:23 UTC (permalink / raw)
To: Laura Abbott, linux-kernel
Cc: Russell King, Catalin Marinas, Will Deacon, Arnd Bergmann,
Nicolas Pitre, Chris Brandt, Pratyush Anand, Ard Biesheuvel,
Mark Rutland, James Morse, Neeraj Upadhyay, Andrew Morton,
Vlastimil Babka, Michal Hocko, Kirill A. Shutemov,
Jerome Marchand, Konstantin Khlebnikov, Joonsoo Kim,
moderated list:ARM PORT,
open list:GENERIC INCLUDE/ASM HEADER FILES
In-Reply-To: <aee5072c-4e09-547e-2f58-7b2106bced3c@redhat.com>
On 11/14/2016 10:45 AM, Laura Abbott wrote:
> On 11/11/2016 04:44 PM, Florian Fainelli wrote:
>> When CONFIG_DEBUG_VM is turned on, virt_to_phys() maps to
>> debug_virt_to_phys() which helps catch vmalloc space addresses being
>> passed. This is helpful in debugging bogus drivers that just assume
>> linear mappings all over the place.
>>
>> For ARM, ARM64, Unicore32 and Microblaze, the architectures define
>> __virt_to_phys() as being the functional implementation of the address
>> translation, so we special case the debug stub to call into
>> __virt_to_phys directly.
>>
>> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> arch/arm/include/asm/memory.h | 4 ++++
>> arch/arm64/include/asm/memory.h | 4 ++++
>> include/asm-generic/memory_model.h | 4 ++++
>> mm/debug.c | 15 +++++++++++++++
>> 4 files changed, 27 insertions(+)
>>
>> diff --git a/arch/arm/include/asm/memory.h b/arch/arm/include/asm/memory.h
>> index 76cbd9c674df..448dec9b8b00 100644
>> --- a/arch/arm/include/asm/memory.h
>> +++ b/arch/arm/include/asm/memory.h
>> @@ -260,11 +260,15 @@ static inline unsigned long __phys_to_virt(phys_addr_t x)
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/arch/arm64/include/asm/memory.h b/arch/arm64/include/asm/memory.h
>> index b71086d25195..c9e436b28523 100644
>> --- a/arch/arm64/include/asm/memory.h
>> +++ b/arch/arm64/include/asm/memory.h
>> @@ -186,11 +186,15 @@ extern u64 kimage_voffset;
>> * translation for translating DMA addresses. Use the driver
>> * DMA support - see dma-mapping.h.
>> */
>> +#ifndef CONFIG_DEBUG_VM
>> #define virt_to_phys virt_to_phys
>> static inline phys_addr_t virt_to_phys(const volatile void *x)
>> {
>> return __virt_to_phys((unsigned long)(x));
>> }
>> +#else
>> +#define virt_to_phys debug_virt_to_phys
>> +#endif
>>
>> #define phys_to_virt phys_to_virt
>> static inline void *phys_to_virt(phys_addr_t x)
>> diff --git a/include/asm-generic/memory_model.h b/include/asm-generic/memory_model.h
>> index 5148150cc80b..426085757258 100644
>> --- a/include/asm-generic/memory_model.h
>> +++ b/include/asm-generic/memory_model.h
>> @@ -80,6 +80,10 @@
>> #define page_to_pfn __page_to_pfn
>> #define pfn_to_page __pfn_to_page
>>
>> +#ifdef CONFIG_DEBUG_VM
>> +unsigned long debug_virt_to_phys(volatile void *address);
>> +#endif /* CONFIG_DEBUG_VM */
>> +
>> #endif /* __ASSEMBLY__ */
>>
>> #endif
>> diff --git a/mm/debug.c b/mm/debug.c
>> index 9feb699c5d25..72b2ca9b11f4 100644
>> --- a/mm/debug.c
>> +++ b/mm/debug.c
>> @@ -161,4 +161,19 @@ void dump_mm(const struct mm_struct *mm)
>> );
>> }
>>
>> +#include <asm/memory.h>
>> +#include <linux/mm.h>
>> +
>> +unsigned long debug_virt_to_phys(volatile void *address)
>> +{
>> + BUG_ON(is_vmalloc_addr((const void *)address));
>> +#if defined(CONFIG_ARM) || defined(CONFIG_ARM64) || defined(CONFIG_UNICORE32) || \
>> + defined(CONFIG_MICROBLAZE)
>> + return __virt_to_phys(address);
>> +#else
>> + return virt_to_phys(address);
>> +#endif
>> +}
>> +EXPORT_SYMBOL(debug_virt_to_phys);
>> +
>> #endif /* CONFIG_DEBUG_VM */
>>
>
> is_vmalloc_addr is necessary but not sufficient. This misses
> cases like module addresses.
Indeed, thanks.
> The x86 version (CONFIG_DEBUG_VIRTUAL)
> bounds checks against the known linear map to catch all cases.
> I'm for a generic approach to this if it can catch all cases
> that an architecture specific version would catch.
For one, my patch causes an early BUG to occur on ARM64 during
arch/arm64/kernel/setup.c::setup_arch when we call
cpu_uninstall_idmap(). I suspect there could be a bunch of little checks
like these where we'd have to have an architecture specific "is this
physical/virtual address valid" that may make a generic implementation
hard to come up with.
--
Florian
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH v3] mailbox: PCC: Fix lockdep warning when request PCC channel
From: Hoan Tran @ 2016-11-14 19:21 UTC (permalink / raw)
To: Prakash, Prashanth
Cc: Rafael J. Wysocki, Jassi Brar, linux acpi, lkml, Loc Ho, Duc Dang
In-Reply-To: <4d6fd670-05d3-914d-b394-0d4cb94b247f@codeaurora.org>
Hi,
On Sun, Nov 13, 2016 at 11:44 AM, Prakash, Prashanth
<pprakash@codeaurora.org> wrote:
> HI Hoan,
>
> On 11/9/2016 11:39 PM, Hoan Tran wrote:
>> Hi All,
>>
>> On Thu, Oct 27, 2016 at 3:34 PM, Hoan Tran <hotran@apm.com> wrote:
>>> This patch fixes the lockdep warning below
>>>
>>> [ 7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
>>> [ 7.229776] ------------[ cut here ]------------
>>> [ 7.229787] WARNING: CPU: 1 PID: 1 at linux-next/kernel/locking/lockdep.c:2876 loc
>>> kdep_trace_alloc+0xe0/0xf0
>>> [ 7.229790] Modules linked in:
>>> [ 7.229793]
>>> [ 7.229798] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-11756-g86c5152 #46
>>> ...
>>> [ 7.229900] Call trace:
>>> [ 7.229903] Exception stack(0xffff8007da837890 to 0xffff8007da8379c0)
>>> [ 7.229906] 7880: ffff8007da834000 0001000000000000
>>> [ 7.229909] 78a0: ffff8007da837a70 ffff0000081111a0 00000000600000c5 000000000000003d
>>> [ 7.229912] 78c0: 9374bc6a7f3c7832 0000000000381878 ffff000009db7ab8 000000000000002f
>>> [ 7.229915] 78e0: ffff00000811aabc ffff000008be2548 ffff8007da837990 ffff00000811adf8
>>> [ 7.229918] 7900: ffff8007da834000 00000000024080c0 00000000000000c0 ffff000009021000
>>> [ 7.229921] 7920: 0000000000000000 0000000000000000 ffff000008c8f7c8 ffff8007da579810
>>> [ 7.229923] 7940: 000000000000002f ffff8007da858000 0000000000000000 0000000000000001
>>> [ 7.229926] 7960: 0000000000000001 0000000000000000 ffff00000811a468 0000000000000002
>>> [ 7.229929] 7980: 656c62617369645f 0000000000038187 00000000000000ee ffff8007da837850
>>> [ 7.229932] 79a0: ffff000009db50c0 ffff000009db569d 0000000000000006 ffff000089db568f
>>> [ 7.229936] [<ffff0000081111a0>] lockdep_trace_alloc+0xe0/0xf0
>>> [ 7.229940] [<ffff0000081f4950>] __kmalloc_track_caller+0x50/0x250
>>> [ 7.229945] [<ffff00000857c088>] devres_alloc_node+0x28/0x60
>>> [ 7.229949] [<ffff0000081220e0>] devm_request_threaded_irq+0x50/0xe0
>>> [ 7.229955] [<ffff0000087e6220>] pcc_mbox_request_channel+0x110/0x170
>>> [ 7.229960] [<ffff0000084b2660>] acpi_cppc_processor_probe+0x264/0x414
>>> [ 7.229963] [<ffff0000084ae9f4>] __acpi_processor_start+0x28/0xa0
>>> [ 7.229966] [<ffff0000084aeab0>] acpi_processor_start+0x44/0x54
>>> [ 7.229970] [<ffff00000857897c>] driver_probe_device+0x1fc/0x2b0
>>> [ 7.229974] [<ffff000008578ae4>] __driver_attach+0xb4/0xc0
>>> [ 7.229977] [<ffff00000857683c>] bus_for_each_dev+0x5c/0xa0
>>> [ 7.229980] [<ffff000008578110>] driver_attach+0x20/0x30
>>> [ 7.229983] [<ffff000008577c20>] bus_add_driver+0x110/0x230
>>> [ 7.229987] [<ffff000008579320>] driver_register+0x60/0x100
>>> [ 7.229991] [<ffff000008d478b8>] acpi_processor_driver_init+0x2c/0xb0
>>> [ 7.229996] [<ffff000008083168>] do_one_initcall+0x38/0x130
>>> [ 7.230000] [<ffff000008d20d6c>] kernel_init_freeable+0x210/0x2b4
>>> [ 7.230004] [<ffff000008945d90>] kernel_init+0x10/0x110
>>> [ 7.230007] [<ffff000008082e80>] ret_from_fork+0x10/0x50
>>>
>>> It's because the spinlock inside pcc_mbox_request_channel() is
>>> kept too long. This patch releases spinlock before request_irq()
>>> and free_irq() to fix this issue as spinlock is only needed to
>>> protect the channel data.
>>>
>>> Signed-off-by: Hoan Tran <hotran@apm.com>
>>> ---
>>> v3
>>> * Free mailbox irq before reset the channel data
>>> * Free channel if it fails to request the mailbox irq
>>>
>>> v2
>>> * Release spinlock before request_irq() and free_irq() instead of
>>> using mutex
>>>
>>>
>>> drivers/mailbox/pcc.c | 70 +++++++++++++++++++++++++--------------------------
>>> 1 file changed, 35 insertions(+), 35 deletions(-)
>>>
>>> diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
>>> index 08c87fa..4b2f061 100644
>>> --- a/drivers/mailbox/pcc.c
>>> +++ b/drivers/mailbox/pcc.c
>>> @@ -224,6 +224,38 @@ static irqreturn_t pcc_mbox_irq(int irq, void *p)
>>> }
>>>
>>> /**
>>> + * pcc_mbox_free_channel - Clients call this to free their Channel.
>>> + *
>>> + * @chan: Pointer to the mailbox channel as returned by
>>> + * pcc_mbox_request_channel()
>>> + */
>>> +void pcc_mbox_free_channel(struct mbox_chan *chan)
>>> +{
>>> + u32 id = chan - pcc_mbox_channels;
>>> + unsigned long flags;
>>> +
>>> + if (!chan || !chan->cl)
>>> + return;
>>> +
>>> + if (id >= pcc_mbox_ctrl.num_chans) {
>>> + pr_debug("pcc_mbox_free_channel: Invalid mbox_chan passed\n");
>>> + return;
>>> + }
>>> +
>>> + if (pcc_doorbell_irq[id] > 0)
>>> + devm_free_irq(chan->mbox->dev, pcc_doorbell_irq[id], chan);
>>> +
>>> + spin_lock_irqsave(&chan->lock, flags);
>>> + chan->cl = NULL;
>>> + chan->active_req = NULL;
>>> + if (chan->txdone_method == (TXDONE_BY_POLL | TXDONE_BY_ACK))
>>> + chan->txdone_method = TXDONE_BY_POLL;
>>> +
>>> + spin_unlock_irqrestore(&chan->lock, flags);
>>> +}
>>> +EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
>>> +
>>> +/**
>>> * pcc_mbox_request_channel - PCC clients call this function to
>>> * request a pointer to their PCC subspace, from which they
>>> * can get the details of communicating with the remote.
>>> @@ -267,6 +299,8 @@ struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *cl,
>>> if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
>>> chan->txdone_method |= TXDONE_BY_ACK;
>>>
>>> + spin_unlock_irqrestore(&chan->lock, flags);
>>> +
>>> if (pcc_doorbell_irq[subspace_id] > 0) {
>>> int rc;
>>>
>>> @@ -275,50 +309,16 @@ struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *cl,
>>> if (unlikely(rc)) {
>>> dev_err(dev, "failed to register PCC interrupt %d\n",
>>> pcc_doorbell_irq[subspace_id]);
>>> + pcc_mbox_free_channel(chan);
>>> chan = ERR_PTR(rc);
>>> }
>>> }
>>>
>>> - spin_unlock_irqrestore(&chan->lock, flags);
>>> -
>>> return chan;
>>> }
>>> EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
>>>
>>> /**
>>> - * pcc_mbox_free_channel - Clients call this to free their Channel.
>>> - *
>>> - * @chan: Pointer to the mailbox channel as returned by
>>> - * pcc_mbox_request_channel()
>>> - */
>>> -void pcc_mbox_free_channel(struct mbox_chan *chan)
>>> -{
>>> - u32 id = chan - pcc_mbox_channels;
>>> - unsigned long flags;
>>> -
>>> - if (!chan || !chan->cl)
>>> - return;
>>> -
>>> - if (id >= pcc_mbox_ctrl.num_chans) {
>>> - pr_debug("pcc_mbox_free_channel: Invalid mbox_chan passed\n");
>>> - return;
>>> - }
>>> -
>>> - spin_lock_irqsave(&chan->lock, flags);
>>> - chan->cl = NULL;
>>> - chan->active_req = NULL;
>>> - if (chan->txdone_method == (TXDONE_BY_POLL | TXDONE_BY_ACK))
>>> - chan->txdone_method = TXDONE_BY_POLL;
>>> -
>>> - if (pcc_doorbell_irq[id] > 0)
>>> - devm_free_irq(chan->mbox->dev, pcc_doorbell_irq[id], chan);
>>> -
>>> - spin_unlock_irqrestore(&chan->lock, flags);
>>> -}
>>> -EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
> Instead of completely relocating an exported function within the file, I think
> we can just include the "pcc.h" header, which makes it a little easier to review.
I just sent out another patch which included pcc.h instead.
Thanks
Hoan
>
> Otherwise, the control flow looks ok now.
>
> --
> Thanks,
> Prashanth
^ permalink raw reply
* [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2016-11-14 19:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFofZdFfGA8gbS9FJxAX5Ub-s8yZWDcNVOgwiEBpho4oyw@mail.gmail.com>
Hi,
On 11/11/2016 06:34 AM, Ulf Hansson wrote:
> On 10 November 2016 at 20:56, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Rob, Ulf, Jon,
>>
>> On 10/27/2016 08:15 AM, Dave Gerlach wrote:
>>>
>>> +Jon
>>> On 10/26/2016 04:59 PM, Rob Herring wrote:
>>>>
>>>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com>
>>>> wrote:
>>>>>
>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>
>>>>>> Hi,
>>>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>>>>>>
>>>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>>>
>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>>>> control device power states.
>>>>>>>>
>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>
>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>> ---
>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54
>>>>>>>> +++++++++++++
>>>>>>>> MAINTAINERS | 2 +
>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>> ++++++++++++++++++++++
>>>>>>>> 3 files changed, 146 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..32f38a349656
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> @@ -0,0 +1,54 @@
>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>> +---------------------------------------------
>>>>>>>> +
>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>> that is
>>>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>> system
>>>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>>>>> domain
>>>>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>>>>> use of
>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>> +
>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>> +
>>>>>>>> +PM Domain Node
>>>>>>>> +==============
>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>> PMMC,
>>>>>>>> +which in this case is the single implementation as documented by the
>>>>>>>> generic
>>>>>>>> +PM domain bindings in
>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the
>>>>>>>> devices.
>>>>>>>>
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +k2g_pds: k2g_pds {
>>>>>>>
>>>>>>>
>>>>>>> should use generic name like "power-contoller", e.g. k2g_pds:
>>>>>>> power-controller
>>>>>>
>>>>>>
>>>>>> Ok, that makes more sense.
>>>>>>
>>>>>>>
>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>> + ti,sci = <&pmmc>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +PM Domain Consumers
>>>>>>>> +===================
>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>> provide
>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>> device
>>>>>>>> +specific ID that identifies the device.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>> node.
>>>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI
>>>>>>>> to
>>>>>>>> + be used for device control.
>>>>>>>
>>>>>>>
>>>>>>> This ID doesn't look right.
>>>>>>>
>>>>>>> Why not use #power-domain-cells = <1> and pass the index in the DT?
>>>>>>> ...
>>>>
>>>>
>>>> Exactly. ti,sci-id is a NAK for me.
>>>
>>>
>>> I was told not to use the onecell during v1 discussion. I agree this would
>>> be
>>> ideal but I cannot due to what the bindings represent, the phandle
>>> parameter is
>>> an index into a list of genpds, whereas we need an actual ID number we can
>>> use
>>> and I do not have the ability to get that from the phandle.
>>>
>>> @Ulf/Jon, is there any hope of bringing back custom xlate functions for
>>> genpd
>>> providers? I don't have a good background on why it was even removed. I
>>> can
>>> maintain a single genpd for all devices but I need a way to parse this ID,
>>> whether it's from a separate property or a phandle. It is locked now to
>>> indexing
>>> into a list of genpds but I need additional per device information for
>>> devices
>>> bound to a genpd and I need either a custom parameter or the ability to
>>> parse
>>> the phandle myself.
>>>
>>
>> Any comments here? The meaning of the phandle onecell is fixed in the genpd
>> framework so I'm not sure how we want to move forward with this, I need to
>> pass a power domain ID to the genpd driver, and if this shouldn't be a new
>> property I'm not sure what direction we should take.
>>
>> Regards,
>> Dave
>>
>>
>>>>
>>>>>>>
>>>>>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for
>>>>>>>> k2g.
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +uart0: serial at 02530c00 {
>>>>>>>> + compatible = "ns16550a";
>>>>>>>> + ...
>>>>>>>> + power-domains = <&k2g_pds>;
>>>>>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>>>>>
>>>>>>>
>>>>>>> ... like this:
>>>>>>>
>>>>>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>>>>>
>>>>>>
>>>>>> That's how I did it in version one actually. I was able to define my
>>>>>> own xlate function to parse the phandle and get that index, but Ulf
>>>>>> pointed me to this series by Jon Hunter [1] that simplified genpd
>>>>>> providers and dropped the concept of adding your own xlate. This locks
>>>>>> the onecell approach to using a fixed static array of genpds that get
>>>>>> indexed into (without passing the index to the provider, just the
>>>>>> genpd that's looked up), which doesn't fit our usecase, as we don't
>>>>>> want a 1 to 1 genpd to device mapping based on the comments provided
>>>>>> in v1. Now we just use the genpd device attach/detach hooks to parse
>>>>>> the sci-id and then use it in the genpd device start/stop hooks.
>>>>
>>>>
>>>> I have no idea what any of this means. All sounds like driver
>>>> architecture, not anything to do with bindings.
>>>
>>>
>>> This was a response to Kevin, not part of binding description.
>>>
>>>>
>>>>>
>>>>> Ah, right. I remember now. This approach allows you to use a single
>>>>> genpd as discussed earlier.
>>>>>
>>>>> Makes sense now, suggestion retracted.
>>>>
>>>>
>>>> IIRC, the bindings in Jon's case had a node for each domain and didn't
>>>> need any additional property.
>>>
>>>
>>> Yes but we only have one domain and index into it, not into a list of
>>> domains,
>
> Exactly. And this my main point as well. We are not talking about a
> domain property but a device property.
>
>>> so the additional property is solving a different problem.
>
> Yes.
>
> Perhaps you could try to elaborate about what the TI SCI ID really
> represents for the device, as to help Rob understand the bigger
> picture?
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.
Thanks for the response. Yes, you've pretty much hit it on the head. It
is not an index into a list of genpds but rather identifies the device
*within* a single genpd. It is a property specific to each device that
resides in a ti-sci-genpd, not a mapping describing which genpd the
device belongs to. The generic power domain binding is concerned with
mapping the device to a specific genpd, which is does fine for us, but
we have a sub mapping for devices that exist inside a genpd which, we
must describe as well, hence the ti,sci-id.
Regards,
Dave
>
> Hope that helps.
>
> Kind regards
> Uffe
>
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: Add TI SCI PM Domains
From: Dave Gerlach @ 2016-11-14 19:20 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring
Cc: Nishanth Menon, devicetree@vger.kernel.org, Santosh Shilimkar,
linux-pm@vger.kernel.org, Kevin Hilman, Sudeep Holla,
Rafael J . Wysocki, linux-kernel@vger.kernel.org, Jon Hunter,
Tero Kristo, Russell King, Keerthy,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CAPDyKFofZdFfGA8gbS9FJxAX5Ub-s8yZWDcNVOgwiEBpho4oyw@mail.gmail.com>
Hi,
On 11/11/2016 06:34 AM, Ulf Hansson wrote:
> On 10 November 2016 at 20:56, Dave Gerlach <d-gerlach@ti.com> wrote:
>> Rob, Ulf, Jon,
>>
>> On 10/27/2016 08:15 AM, Dave Gerlach wrote:
>>>
>>> +Jon
>>> On 10/26/2016 04:59 PM, Rob Herring wrote:
>>>>
>>>> On Mon, Oct 24, 2016 at 12:00 PM, Kevin Hilman <khilman@baylibre.com>
>>>> wrote:
>>>>>
>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>
>>>>>> Hi,
>>>>>> On 10/21/2016 01:48 PM, Kevin Hilman wrote:
>>>>>>>
>>>>>>> Dave Gerlach <d-gerlach@ti.com> writes:
>>>>>>>
>>>>>>>> Add a generic power domain implementation, TI SCI PM Domains, that
>>>>>>>> will hook into the genpd framework and allow the TI SCI protocol to
>>>>>>>> control device power states.
>>>>>>>>
>>>>>>>> Also, provide macros representing each device index as understood
>>>>>>>> by TI SCI to be used in the device node power-domain references.
>>>>>>>> These are identifiers for the K2G devices managed by the PMMC.
>>>>>>>>
>>>>>>>> Signed-off-by: Nishanth Menon <nm@ti.com>
>>>>>>>> Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
>>>>>>>> ---
>>>>>>>> .../devicetree/bindings/soc/ti/sci-pm-domain.txt | 54
>>>>>>>> +++++++++++++
>>>>>>>> MAINTAINERS | 2 +
>>>>>>>> include/dt-bindings/genpd/k2g.h | 90
>>>>>>>> ++++++++++++++++++++++
>>>>>>>> 3 files changed, 146 insertions(+)
>>>>>>>> create mode 100644
>>>>>>>> Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> create mode 100644 include/dt-bindings/genpd/k2g.h
>>>>>>>>
>>>>>>>> diff --git
>>>>>>>> a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> new file mode 100644
>>>>>>>> index 000000000000..32f38a349656
>>>>>>>> --- /dev/null
>>>>>>>> +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt
>>>>>>>> @@ -0,0 +1,54 @@
>>>>>>>> +Texas Instruments TI-SCI Generic Power Domain
>>>>>>>> +---------------------------------------------
>>>>>>>> +
>>>>>>>> +Some TI SoCs contain a system controller (like the PMMC, etc...)
>>>>>>>> that is
>>>>>>>> +responsible for controlling the state of the IPs that are present.
>>>>>>>> +Communication between the host processor running an OS and the
>>>>>>>> system
>>>>>>>> +controller happens through a protocol known as TI-SCI [1]. This pm
>>>>>>>> domain
>>>>>>>> +implementation plugs into the generic pm domain framework and makes
>>>>>>>> use of
>>>>>>>> +the TI SCI protocol power on and off each device when needed.
>>>>>>>> +
>>>>>>>> +[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
>>>>>>>> +
>>>>>>>> +PM Domain Node
>>>>>>>> +==============
>>>>>>>> +The PM domain node represents the global PM domain managed by the
>>>>>>>> PMMC,
>>>>>>>> +which in this case is the single implementation as documented by the
>>>>>>>> generic
>>>>>>>> +PM domain bindings in
>>>>>>>> Documentation/devicetree/bindings/power/power_domain.txt.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- compatible: should be "ti,sci-pm-domain"
>>>>>>>> +- #power-domain-cells: Must be 0.
>>>>>>>> +- ti,sci: Phandle to the TI SCI device to use for managing the
>>>>>>>> devices.
>>>>>>>>
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +k2g_pds: k2g_pds {
>>>>>>>
>>>>>>>
>>>>>>> should use generic name like "power-contoller", e.g. k2g_pds:
>>>>>>> power-controller
>>>>>>
>>>>>>
>>>>>> Ok, that makes more sense.
>>>>>>
>>>>>>>
>>>>>>>> + compatible = "ti,sci-pm-domain";
>>>>>>>> + #power-domain-cells = <0>;
>>>>>>>> + ti,sci = <&pmmc>;
>>>>>>>> +};
>>>>>>>> +
>>>>>>>> +PM Domain Consumers
>>>>>>>> +===================
>>>>>>>> +Hardware blocks that require SCI control over their state must
>>>>>>>> provide
>>>>>>>> +a reference to the sci-pm-domain they are part of and a unique
>>>>>>>> device
>>>>>>>> +specific ID that identifies the device.
>>>>>>>> +
>>>>>>>> +Required Properties:
>>>>>>>> +--------------------
>>>>>>>> +- power-domains: phandle pointing to the corresponding PM domain
>>>>>>>> node.
>>>>>>>> +- ti,sci-id: index representing the device id to be passed oevr SCI
>>>>>>>> to
>>>>>>>> + be used for device control.
>>>>>>>
>>>>>>>
>>>>>>> This ID doesn't look right.
>>>>>>>
>>>>>>> Why not use #power-domain-cells = <1> and pass the index in the DT?
>>>>>>> ...
>>>>
>>>>
>>>> Exactly. ti,sci-id is a NAK for me.
>>>
>>>
>>> I was told not to use the onecell during v1 discussion. I agree this would
>>> be
>>> ideal but I cannot due to what the bindings represent, the phandle
>>> parameter is
>>> an index into a list of genpds, whereas we need an actual ID number we can
>>> use
>>> and I do not have the ability to get that from the phandle.
>>>
>>> @Ulf/Jon, is there any hope of bringing back custom xlate functions for
>>> genpd
>>> providers? I don't have a good background on why it was even removed. I
>>> can
>>> maintain a single genpd for all devices but I need a way to parse this ID,
>>> whether it's from a separate property or a phandle. It is locked now to
>>> indexing
>>> into a list of genpds but I need additional per device information for
>>> devices
>>> bound to a genpd and I need either a custom parameter or the ability to
>>> parse
>>> the phandle myself.
>>>
>>
>> Any comments here? The meaning of the phandle onecell is fixed in the genpd
>> framework so I'm not sure how we want to move forward with this, I need to
>> pass a power domain ID to the genpd driver, and if this shouldn't be a new
>> property I'm not sure what direction we should take.
>>
>> Regards,
>> Dave
>>
>>
>>>>
>>>>>>>
>>>>>>>> +See dt-bindings/genpd/k2g.h for the list of valid identifiers for
>>>>>>>> k2g.
>>>>>>>> +
>>>>>>>> +Example:
>>>>>>>> +--------------------
>>>>>>>> +uart0: serial@02530c00 {
>>>>>>>> + compatible = "ns16550a";
>>>>>>>> + ...
>>>>>>>> + power-domains = <&k2g_pds>;
>>>>>>>> + ti,sci-id = <K2G_DEV_UART0>;
>>>>>>>
>>>>>>>
>>>>>>> ... like this:
>>>>>>>
>>>>>>> power-domains = <&k2g_pds K2G_DEV_UART0>;
>>>>>>
>>>>>>
>>>>>> That's how I did it in version one actually. I was able to define my
>>>>>> own xlate function to parse the phandle and get that index, but Ulf
>>>>>> pointed me to this series by Jon Hunter [1] that simplified genpd
>>>>>> providers and dropped the concept of adding your own xlate. This locks
>>>>>> the onecell approach to using a fixed static array of genpds that get
>>>>>> indexed into (without passing the index to the provider, just the
>>>>>> genpd that's looked up), which doesn't fit our usecase, as we don't
>>>>>> want a 1 to 1 genpd to device mapping based on the comments provided
>>>>>> in v1. Now we just use the genpd device attach/detach hooks to parse
>>>>>> the sci-id and then use it in the genpd device start/stop hooks.
>>>>
>>>>
>>>> I have no idea what any of this means. All sounds like driver
>>>> architecture, not anything to do with bindings.
>>>
>>>
>>> This was a response to Kevin, not part of binding description.
>>>
>>>>
>>>>>
>>>>> Ah, right. I remember now. This approach allows you to use a single
>>>>> genpd as discussed earlier.
>>>>>
>>>>> Makes sense now, suggestion retracted.
>>>>
>>>>
>>>> IIRC, the bindings in Jon's case had a node for each domain and didn't
>>>> need any additional property.
>>>
>>>
>>> Yes but we only have one domain and index into it, not into a list of
>>> domains,
>
> Exactly. And this my main point as well. We are not talking about a
> domain property but a device property.
>
>>> so the additional property is solving a different problem.
>
> Yes.
>
> Perhaps you could try to elaborate about what the TI SCI ID really
> represents for the device, as to help Rob understand the bigger
> picture?
>
> To me, the TI SCI ID, is similar to a "conid" for any another "device
> resource" (like clock, pinctrl, regulator etc) which we can describe
> in DT and assign to a device node. The only difference here, is that
> we don't have common API to fetch the resource (like clk_get(),
> regulator_get()), but instead we fetches the device's resource from
> SoC specific code, via genpd's device ->attach() callback.
Thanks for the response. Yes, you've pretty much hit it on the head. It
is not an index into a list of genpds but rather identifies the device
*within* a single genpd. It is a property specific to each device that
resides in a ti-sci-genpd, not a mapping describing which genpd the
device belongs to. The generic power domain binding is concerned with
mapping the device to a specific genpd, which is does fine for us, but
we have a sub mapping for devices that exist inside a genpd which, we
must describe as well, hence the ti,sci-id.
Regards,
Dave
>
> Hope that helps.
>
> Kind regards
> Uffe
>
^ permalink raw reply
* [PATCH v4] mailbox: PCC: Fix lockdep warning when request PCC channel
From: Hoan Tran @ 2016-11-14 19:19 UTC (permalink / raw)
To: Rafael J. Wysocki, Jassi Brar, Prakash Prashanth
Cc: linux-acpi, linux-kernel, lho, Duc Dang, Hoan Tran
This patch fixes the lockdep warning below
[ 7.229767] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
[ 7.229776] ------------[ cut here ]------------
[ 7.229787] WARNING: CPU: 1 PID: 1 at linux-next/kernel/locking/lockdep.c:2876 loc
kdep_trace_alloc+0xe0/0xf0
[ 7.229790] Modules linked in:
[ 7.229793]
[ 7.229798] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.8.0-11756-g86c5152 #46
...
[ 7.229900] Call trace:
[ 7.229903] Exception stack(0xffff8007da837890 to 0xffff8007da8379c0)
[ 7.229906] 7880: ffff8007da834000 0001000000000000
[ 7.229909] 78a0: ffff8007da837a70 ffff0000081111a0 00000000600000c5 000000000000003d
[ 7.229912] 78c0: 9374bc6a7f3c7832 0000000000381878 ffff000009db7ab8 000000000000002f
[ 7.229915] 78e0: ffff00000811aabc ffff000008be2548 ffff8007da837990 ffff00000811adf8
[ 7.229918] 7900: ffff8007da834000 00000000024080c0 00000000000000c0 ffff000009021000
[ 7.229921] 7920: 0000000000000000 0000000000000000 ffff000008c8f7c8 ffff8007da579810
[ 7.229923] 7940: 000000000000002f ffff8007da858000 0000000000000000 0000000000000001
[ 7.229926] 7960: 0000000000000001 0000000000000000 ffff00000811a468 0000000000000002
[ 7.229929] 7980: 656c62617369645f 0000000000038187 00000000000000ee ffff8007da837850
[ 7.229932] 79a0: ffff000009db50c0 ffff000009db569d 0000000000000006 ffff000089db568f
[ 7.229936] [<ffff0000081111a0>] lockdep_trace_alloc+0xe0/0xf0
[ 7.229940] [<ffff0000081f4950>] __kmalloc_track_caller+0x50/0x250
[ 7.229945] [<ffff00000857c088>] devres_alloc_node+0x28/0x60
[ 7.229949] [<ffff0000081220e0>] devm_request_threaded_irq+0x50/0xe0
[ 7.229955] [<ffff0000087e6220>] pcc_mbox_request_channel+0x110/0x170
[ 7.229960] [<ffff0000084b2660>] acpi_cppc_processor_probe+0x264/0x414
[ 7.229963] [<ffff0000084ae9f4>] __acpi_processor_start+0x28/0xa0
[ 7.229966] [<ffff0000084aeab0>] acpi_processor_start+0x44/0x54
[ 7.229970] [<ffff00000857897c>] driver_probe_device+0x1fc/0x2b0
[ 7.229974] [<ffff000008578ae4>] __driver_attach+0xb4/0xc0
[ 7.229977] [<ffff00000857683c>] bus_for_each_dev+0x5c/0xa0
[ 7.229980] [<ffff000008578110>] driver_attach+0x20/0x30
[ 7.229983] [<ffff000008577c20>] bus_add_driver+0x110/0x230
[ 7.229987] [<ffff000008579320>] driver_register+0x60/0x100
[ 7.229991] [<ffff000008d478b8>] acpi_processor_driver_init+0x2c/0xb0
[ 7.229996] [<ffff000008083168>] do_one_initcall+0x38/0x130
[ 7.230000] [<ffff000008d20d6c>] kernel_init_freeable+0x210/0x2b4
[ 7.230004] [<ffff000008945d90>] kernel_init+0x10/0x110
[ 7.230007] [<ffff000008082e80>] ret_from_fork+0x10/0x50
It's because the spinlock inside pcc_mbox_request_channel() is
kept too long. This patch releases spinlock before request_irq()
and free_irq() to fix this issue as spinlock is only needed to
protect the channel data.
Signed-off-by: Hoan Tran <hotran@apm.com>
---
v4
* Include acpi/pcc.h
v3
* Free mailbox irq before reset the channel data
* Free channel if it fails to request the mailbox irq
v2
* Release spinlock before request_irq() and free_irq() instead of
using mutex
drivers/mailbox/pcc.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c
index 08c87fa..1f32688 100644
--- a/drivers/mailbox/pcc.c
+++ b/drivers/mailbox/pcc.c
@@ -65,6 +65,7 @@
#include <linux/mailbox_controller.h>
#include <linux/mailbox_client.h>
#include <linux/io-64-nonatomic-lo-hi.h>
+#include <acpi/pcc.h>
#include "mailbox.h"
@@ -267,6 +268,8 @@ struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *cl,
if (chan->txdone_method == TXDONE_BY_POLL && cl->knows_txdone)
chan->txdone_method |= TXDONE_BY_ACK;
+ spin_unlock_irqrestore(&chan->lock, flags);
+
if (pcc_doorbell_irq[subspace_id] > 0) {
int rc;
@@ -275,12 +278,11 @@ struct mbox_chan *pcc_mbox_request_channel(struct mbox_client *cl,
if (unlikely(rc)) {
dev_err(dev, "failed to register PCC interrupt %d\n",
pcc_doorbell_irq[subspace_id]);
+ pcc_mbox_free_channel(chan);
chan = ERR_PTR(rc);
}
}
- spin_unlock_irqrestore(&chan->lock, flags);
-
return chan;
}
EXPORT_SYMBOL_GPL(pcc_mbox_request_channel);
@@ -304,20 +306,19 @@ void pcc_mbox_free_channel(struct mbox_chan *chan)
return;
}
+ if (pcc_doorbell_irq[id] > 0)
+ devm_free_irq(chan->mbox->dev, pcc_doorbell_irq[id], chan);
+
spin_lock_irqsave(&chan->lock, flags);
chan->cl = NULL;
chan->active_req = NULL;
if (chan->txdone_method == (TXDONE_BY_POLL | TXDONE_BY_ACK))
chan->txdone_method = TXDONE_BY_POLL;
- if (pcc_doorbell_irq[id] > 0)
- devm_free_irq(chan->mbox->dev, pcc_doorbell_irq[id], chan);
-
spin_unlock_irqrestore(&chan->lock, flags);
}
EXPORT_SYMBOL_GPL(pcc_mbox_free_channel);
-
/**
* pcc_send_data - Called from Mailbox Controller code. Used
* here only to ring the channel doorbell. The PCC client
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] doc: mention transfer data leaks in more places
From: Junio C Hamano @ 2016-11-14 19:19 UTC (permalink / raw)
To: Matt McCutchen; +Cc: git, Jeff King
In-Reply-To: <1479148255.2406.30.camel@mattmccutchen.net>
Matt McCutchen <matt@mattmccutchen.net> writes:
> The "SECURITY" section of the gitnamespaces(7) man page described two
> ways for a client to steal data from a server that wasn't intended to be
> shared. Similar attacks can be performed by a server on a client, so
> adapt the section to cover both directions and add it to the
> git-fetch(1), git-pull(1), and git-push(1) man pages. Also add
> references to this section from the documentation of server
> configuration options that attempt to control data leakage but may not
> be fully effective.
This round looks OK. Will queue. Thanks.
^ permalink raw reply
* Re: [PATCH v4 7/8] v4l: Add signal lock status to source change events
From: Steve Longerbeam @ 2016-11-14 19:19 UTC (permalink / raw)
To: Hans Verkuil, Steve Longerbeam, lars
Cc: mchehab, linux-media, linux-kernel, Mauro Carvalho Chehab
In-Reply-To: <8ff2fc76-2290-d353-08cd-2aa31c31a19c@xs4all.nl>
On 11/14/2016 03:36 AM, Hans Verkuil wrote:
> On 08/03/2016 08:03 PM, Steve Longerbeam wrote:
>> Add a signal lock status change to the source changes bitmask.
>> This indicates there was a signal lock or unlock event detected
>> at the input of a video decoder.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>> Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
>>
>> ---
>>
>> v4:
>> - converted to rst from DocBook
>>
>> v3: no changes
>> v2: no changes
>> ---
>> Documentation/media/uapi/v4l/vidioc-dqevent.rst | 9 +++++++++
>> Documentation/media/videodev2.h.rst.exceptions | 1 +
>> include/uapi/linux/videodev2.h | 1 +
>> 3 files changed, 11 insertions(+)
>>
>> diff --git a/Documentation/media/uapi/v4l/vidioc-dqevent.rst b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>> index 73c0d5b..7d8a053 100644
>> --- a/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>> +++ b/Documentation/media/uapi/v4l/vidioc-dqevent.rst
>> @@ -564,6 +564,15 @@ call.
>> an input. This can come from an input connector or from a video
>> decoder.
>>
>> + - .. row 2
>> +
>> + - ``V4L2_EVENT_SRC_CH_LOCK_STATUS``
>> +
>> + - 0x0002
>> +
>> + - This event gets triggered when there is a signal lock or
>> + unlock detected at the input of a video decoder.
>> +
>>
>> Return Value
>> ============
>> diff --git a/Documentation/media/videodev2.h.rst.exceptions b/Documentation/media/videodev2.h.rst.exceptions
>> index 9bb9a6c..f412cc8 100644
>> --- a/Documentation/media/videodev2.h.rst.exceptions
>> +++ b/Documentation/media/videodev2.h.rst.exceptions
>> @@ -453,6 +453,7 @@ replace define V4L2_EVENT_CTRL_CH_FLAGS ctrl-changes-flags
>> replace define V4L2_EVENT_CTRL_CH_RANGE ctrl-changes-flags
>>
>> replace define V4L2_EVENT_SRC_CH_RESOLUTION src-changes-flags
>> +replace define V4L2_EVENT_SRC_CH_LOCK_STATUS src-changes-flags
>>
>> replace define V4L2_EVENT_MD_FL_HAVE_FRAME_SEQ v4l2-event-motion-det
>>
>> diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
>> index 724f43e..08a153f 100644
>> --- a/include/uapi/linux/videodev2.h
>> +++ b/include/uapi/linux/videodev2.h
>> @@ -2078,6 +2078,7 @@ struct v4l2_event_frame_sync {
>> };
>>
>> #define V4L2_EVENT_SRC_CH_RESOLUTION (1 << 0)
>> +#define V4L2_EVENT_SRC_CH_LOCK_STATUS (1 << 1)
>>
>> struct v4l2_event_src_change {
>> __u32 changes;
>>
> Quoting from an old (July) conversation about this:
>
>>>> I'm not entirely sure I like this. Typically losing lock means that this event
>>>> is triggered with the V4L2_EVENT_SRC_CH_RESOLUTION flag set, and userspace has
>>>> to check the new timings etc., which will fail if there is no lock anymore.
>>>>
>>>> This information is also available through ENUMINPUT.
>>>>
>>>> I would need to know more about why you think this is needed, because I don't
>>>> see what this adds.
>> Hi Hans,
>>
>> At least on the ADV718x, a source resolution change (from an
>> autodetected video
>> standard change) and a signal lock status change are distinct events.
>> For example
>> there can be a temporary loss of input signal lock without a change in
>> detected
>> input video standard/resolution.
> OK, but what can the application do with that event? If the glitch didn't
> affect the video, then it is pointless.
Hi Hans, that's just it, for i.mx6 it does affect video. On i.mx6 a
temporary
loss of signal from the adv7180 often results in a "split image", or rolling
image from captured frame to the next, and the only way to recover
from this failure is to restart the pipeline (stream off -- stream on). So
the application needs to be informed of this temporary loss of signal
event in order to restart streaming.
>
> If the lock is lost, then normally you loose video as well. If not, then
> applications are not interested in the event.
Yes, the lost lock causes a temporary or permanent loss of video,
but with no other indications from the adv7180 (such as a detected
video standard change). And on i.mx6, the lost lock often (actually
usually) causes a split or rolling image.
Steve
^ permalink raw reply
* Re: [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-14 19:17 UTC (permalink / raw)
To: Neil Armstrong, Martin Blumenstingl
Cc: carlo, linux-amlogic, linux-kernel, linux-arm-kernel, devicetree
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
Since the P23x and Q20x boards are identical, should we just come up
with a singel dtsi for them all? e.g move the -p23x.dtsi to -pq2xx.dtsi
or something?
I don't think it's a big deal, but it does seem like we should avoid the
copy/paste wherever possible.
Kevin
^ permalink raw reply
* [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-14 19:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
Since the P23x and Q20x boards are identical, should we just come up
with a singel dtsi for them all? e.g move the -p23x.dtsi to -pq2xx.dtsi
or something?
I don't think it's a big deal, but it does seem like we should avoid the
copy/paste wherever possible.
Kevin
^ permalink raw reply
* [RFC PATCH] ARM64: dts: Add support for Meson GXM
From: Kevin Hilman @ 2016-11-14 19:17 UTC (permalink / raw)
To: linus-amlogic
In-Reply-To: <20161114094411.30199-1-narmstrong@baylibre.com>
Neil Armstrong <narmstrong@baylibre.com> writes:
> Following the Amlogic Linux kernel, it seem the only differences
> between the GXL and GXM SoCs are the CPU Clusters.
>
> Simply add a meson-gxm dtsi and reproduce the P23x to Q20x boards
> dts files since the S905D and S912 SoCs shares the same pinout
> and the P23x and Q20x boards are identical.
Since the P23x and Q20x boards are identical, should we just come up
with a singel dtsi for them all? e.g move the -p23x.dtsi to -pq2xx.dtsi
or something?
I don't think it's a big deal, but it does seem like we should avoid the
copy/paste wherever possible.
Kevin
^ permalink raw reply
* Re: [PATCH v2 3/3] remoteproc: qcom: add Venus video core firmware loader driver
From: Stephen Boyd @ 2016-11-14 19:16 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Ohad Ben-Cohen, Bjorn Andersson, Andy Gross, Rob Herring,
Mark Rutland, Srinivas Kandagatla, linux-remoteproc, linux-kernel,
linux-arm-msm, linux-soc, devicetree
In-Reply-To: <1478539853-23218-4-git-send-email-stanimir.varbanov@linaro.org>
On 11/07, Stanimir Varbanov wrote:
> +#include <linux/module.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/qcom_scm.h>
> +#include <linux/remoteproc.h>
> +
> +#include "qcom_mdt_loader.h"
> +#include "remoteproc_internal.h"
> +
> +#define VENUS_CRASH_REASON_SMEM 425
This is unused. Is there going to be some common smem API to get
the crash reason?
> +
> +static const struct of_device_id venus_of_match[] = {
> + { .compatible = "qcom,venus-pil" },
> + { },
> +};
Add a MODULE_DEVICE_TABLE?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 3/3] remoteproc: qcom: add Venus video core firmware loader driver
From: Stephen Boyd @ 2016-11-14 19:16 UTC (permalink / raw)
To: Stanimir Varbanov
Cc: Ohad Ben-Cohen, Bjorn Andersson, Andy Gross, Rob Herring,
Mark Rutland, Srinivas Kandagatla,
linux-remoteproc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478539853-23218-4-git-send-email-stanimir.varbanov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/07, Stanimir Varbanov wrote:
> +#include <linux/module.h>
> +#include <linux/of_reserved_mem.h>
> +#include <linux/platform_device.h>
> +#include <linux/qcom_scm.h>
> +#include <linux/remoteproc.h>
> +
> +#include "qcom_mdt_loader.h"
> +#include "remoteproc_internal.h"
> +
> +#define VENUS_CRASH_REASON_SMEM 425
This is unused. Is there going to be some common smem API to get
the crash reason?
> +
> +static const struct of_device_id venus_of_match[] = {
> + { .compatible = "qcom,venus-pil" },
> + { },
> +};
Add a MODULE_DEVICE_TABLE?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Haster Response.//..
From: UNCLAIMED ASSET @ 2016-11-14 19:15 UTC (permalink / raw)
To: netdev
Mr. Steve Bhatti,
Drift / regionsjef
Santander Bank Plc,
47-48 Piccadilly
PICCADILLY
W1J0DT
London, Storbritannia
Hei,
Jeg er Steve Bhatti, fra Harlesden North West London, leder for regnskap Revisjonen og formell senior programmerer sjef hos Deutsche bank, her i England (Santander Bank Plc). Jeg har også jobbet for Nyeste ministrene Bank Plc.
Jeg trenger din haster hjelp til å overføre summen av (£ 21,5) millioner britiske pund på kontoen din innen 11 eller 15 bankdager. Disse pengene har vært sovende i mange år i vår Bank uten krav. Jeg ønsker banken å frigjøre penger til deg som nærmeste person til vår avdøde kunden (eieren av kontoen) som dessverre mistet livet februar 2003 gjennom det sørlige USA romfergen Columbia, døde han en enkelt mann. Jeg ønsker ikke penger til å gå inn i bankens egne konto som en forlatt fondet. Så dette er grunnen til at jeg kontakter deg slik at banken kan frigjøre penger til deg som skal pårørende til den avdøde kunden. (Late David McDowell Brown) en amerikansk statsborger av Arlington Virginia.
Vennligst Jeg vil at du skal holde Forslaget som en topp hemmelig og slette den hvis du ikke er interessert.
Her deler ratio; 50% til meg og 40% til deg mens 10% er for eventuelle utgifter i løpet av transaksjonen. Hvis du er interessert, ta kontakt med meg umiddelbart via min private / direkte post: steve.s.bhatti@gmail.com
Gi meg følgende under, som vi har 7 dager for å kjøre den gjennom. Dette er veldig HASTER.
1. Fullt navn:
2. Direkte Mobilnummer:
3. Kontakt Adresse:
4. Yrke:
5. Alder:
6. Kjønn:
7. Nasjonalitet:
Vennlig hilsen,
Dr. Steve Bhatti.
^ permalink raw reply
* Re: AF_VSOCK loopback
From: Stefan Hajnoczi @ 2016-11-14 19:14 UTC (permalink / raw)
To: Jorgen S. Hansen; +Cc: cavery@redhat.com, netdev@vger.kernel.org
In-Reply-To: <BY2PR0501MB20561F98987156779668ECB1DABB0@BY2PR0501MB2056.namprd05.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
On Fri, Nov 11, 2016 at 02:14:44PM +0000, Jorgen S. Hansen wrote:
> Hi Stefan,
>
> All datagram communication in VMCI based AF_VSOCK is going through the host - also for loopback communication. The only difference wrt loopback is that the VMCI queue pairs implementing the shared queues for the stream protocols aren't registered with the hypervisor - they are created specifying the VMCI_QPFLAG_LOCAL flag, and exist only as local guest memory.
>
> So in the current form, there isn't much loopback code in the vmci AF_VSOCK implementation, so it doesn't seem like there would be much to share either.
Thanks for clarifying. I'm playing with a virtio-vsock implementation
of loopback and expect send patches later this week.
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
^ permalink raw reply
* Re: [PATCH v3 5/6] grep: enable recurse-submodules to work on <tree> objects
From: Brandon Williams @ 2016-11-14 19:14 UTC (permalink / raw)
To: Jonathan Tan; +Cc: Junio C Hamano, git, sbeller
In-Reply-To: <5a60b630-15fc-6b63-fb03-25aa0d1ef081@google.com>
On 11/14, Jonathan Tan wrote:
> On 11/14/2016 10:56 AM, Junio C Hamano wrote:
> >Jonathan Tan <jonathantanmy@google.com> writes:
> >
> >>>>to:
> >>>>HEAD:file
> >>>>HEAD:sub/file
> >>>>
> >>>>Signed-off-by: Brandon Williams <bmwill@google.com>
> >>>>---
> >>>
> >>>Unrelated tangent, but this makes readers wonder what the updated
> >>>trailer code would do to the last paragraph ;-). Does it behave
> >>>sensibly (with some sane definition of sensibleness)?
> >>>
> >>>I am guessing that it would, because neither To: or HEAD: is what we
> >>>normally recognize as a known trailer block element.
> >>
> >>Yes, it behaves sensibly :-) because "Signed-off-by:" is preceded by a
> >>blank line, so the trailer block consists only of that line.
> >
> >Oh, that was not what I was wondering. Imagine Brandon writing his
> >message that ends in these three questionable lines and then running
> >"commit -s --amend" to add his sign-off---that was the case I was
> >wondering.
>
> Ah, I see. In that case, it would consider the last block as a
> trailer block and attach it directly:
>
> to:
> HEAD:file
> HEAD:sub/file
> Signed-off-by: ...
>
> It is true that neither to: nor HEAD: are known trailers, but my
> patch set accepts trailer blocks that are 100% well-formed
> regardless of whether the trailers are known (to provide backwards
> compatibility with git-interpret-trailers, and to satisfy the
> certain use cases that I brought up). The "known trailer" check is
> used when the trailer block is not 100% well-formed.
>
> This issue can be avoided if those lines were indented with at least
> one space or at least one tab.
Who would have thought my simple example would cause this kind of
discussion! I can update the commit message and indent the output so
that it looks like the following:
to:
HEAD:file
HEAD:sub/file
--
Brandon Williams
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.