Re: [PATCH 2/2] staging: android: ion: Combine cache and uncache pools

Hi Sumit, On 2018/2/7 22:34, Sumit Semwal wrote: > Hello Yisheng, > > On 7 February 2018 at 09:29, Yisheng Xie wrote: >> Now we call dma_map in the dma_buf API callbacks and handle explicit >> caching by the dma_buf sync API, which make cache and uncache pools >> in the

Re: [PATCH] binder: replace "%p" with "%pK"

On Wed, Feb 07, 2018 at 01:57:37PM -0800, Todd Kjos wrote: > The format specifier "%p" can leak kernel addresses. Use > "%pK" instead. There were 4 remaining cases in binder.c. Luckily this isn't an issue in mainline as we don't print %p values out anymore as of 4.15. That being said, this is a

[PATCH] binder: replace "%p" with "%pK"

The format specifier "%p" can leak kernel addresses. Use "%pK" instead. There were 4 remaining cases in binder.c. Signed-off-by: Todd Kjos --- drivers/android/binder.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/android/binder.c

[PATCH] ANDROID: binder: remove WARN() for redundant txn error

binder_send_failed_reply() is called when a synchronous transaction fails. It reports an error to the thread that is waiting for the completion. Given that the transaction is synchronous, there should never be more than 1 error response to that thread -- this was being asserted with a WARN().

[PATCH RESEND 0/4] hv_balloon: fixes for num_pages_onlined accounting and misc improvements

I just noticed that this series got lost; the initial submission was on Nov, 8 but nothing happened after. Resending. Original description: While doing routing code review I noticed that commit 6df8d9aaf3af ("Drivers: hv: balloon: Correctly update onlined page count") introduced an issue with

[PATCH RESEND 3/4] hv_balloon: fix bugs in num_pages_onlined accounting

Our num_pages_onlined accounting is buggy: 1) In case we're offlining a memory block which was present at boot (e.g. when there was no hotplug at all) we subtract 32k from 0 and as num_pages_onlined is unsigned get a very big positive number. 2) Commit 6df8d9aaf3af ("Drivers: hv: balloon:

[PATCH RESEND 1/4] hv_balloon: fix printk loglevel

We have a mix of different ideas of which loglevel should be used. Unify on the following: - pr_info() for normal operation - pr_warn() for 'strange' host behavior - pr_err() for all errors. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/hv_balloon.c | 12 ++-- 1

[PATCH RESEND 2/4] hv_balloon: simplify hv_online_page()/hv_page_online_one()

Instead of doing pfn_to_page() and continuosly casting page to unsigned long just cache the pfn of the page with page_to_pfn(). Signed-off-by: Vitaly Kuznetsov --- drivers/hv/hv_balloon.c | 27 +-- 1 file changed, 5 insertions(+), 22 deletions(-)

[PATCH RESEND 4/4] hv_balloon: trace post_status

Hyper-V balloon driver makes non-trivial calculations to convert Linux's representation of free/used memory to what Hyper-V host expects to see. Add a tracepoint to see what's being sent and where the data comes from. Signed-off-by: Vitaly Kuznetsov --- drivers/hv/Makefile

Re: staging: ion: ION allocation fall back order depends on heap linkage order

On 02/07/2018 05:32 PM, Laura Abbott wrote: > On 02/07/2018 07:10 AM, Alexey Skidanov wrote: >> >> >> On 02/07/2018 04:58 PM, Laura Abbott wrote: >>> On 02/06/2018 11:05 PM, Alexey Skidanov wrote: > Yup, you've hit upon a key problem. Having fallbacks be stable > was always a

Re: staging: ion: ION allocation fall back order depends on heap linkage order

On 02/07/2018 07:10 AM, Alexey Skidanov wrote: On 02/07/2018 04:58 PM, Laura Abbott wrote: On 02/06/2018 11:05 PM, Alexey Skidanov wrote: Yup, you've hit upon a key problem. Having fallbacks be stable was always a problem and the recommendation these days is to not rely on them. You can

Re: staging: ion: ION allocation fall back order depends on heap linkage order

On 02/07/2018 04:58 PM, Laura Abbott wrote: > On 02/06/2018 11:05 PM, Alexey Skidanov wrote: >> >> >>> Yup, you've hit upon a key problem. Having fallbacks be stable >>> was always a problem and the recommendation these days is to >>> not rely on them. You can specify a heap at a time and

Re: staging: ion: ION allocation fall back order depends on heap linkage order

On 02/06/2018 11:05 PM, Alexey Skidanov wrote: Yup, you've hit upon a key problem. Having fallbacks be stable was always a problem and the recommendation these days is to not rely on them. You can specify a heap at a time and fallback manually if you want that behavior. If you have a

Re: [PATCH 1/2] staging: android: ion: Cleanup ion_page_pool_alloc_pages

Hi Yisheng, On 7 February 2018 at 09:29, Yisheng Xie wrote: > ion_page_pool_alloc_pages calls alloc_pages to allocate pages for page > pools. If alloc_pages return NULL, it will return NULL, or it will > return the pages allocate from alloc_pages. So we can just return >

Re: [PATCH 2/2] staging: android: ion: Combine cache and uncache pools

Hello Yisheng, On 7 February 2018 at 09:29, Yisheng Xie wrote: > Now we call dma_map in the dma_buf API callbacks and handle explicit > caching by the dma_buf sync API, which make cache and uncache pools > in the same handling flow, which can be combined. > Thanks for the

Re: [PATCH] Update rf_type_definition

This is better. But the subject should say [PATCH v2] and we need a driver prefix. On Wed, Feb 07, 2018 at 06:23:34AM +0900, l4stpr0g...@gmail.com wrote: > From: Kangmin Park > > enum RT_RF_TYPE_DEFINITION on rtl8723bs/include/rtw_rf.h > is different from enum

Re: [PATCH] Resolve RF Type mismatch

Also the patch prefix is wrong in the email subject. It should say, [PATCH] staging: rtl8723bs: Resolve RF Type mismatch On Wed, Feb 07, 2018 at 01:31:48AM +0900, Kangmin Park wrote: > Oops, Sorry for being stupid cuz of first time to use git email. No problem. We were all newbies once. Send

Re: [PATCH] Resolve RF Type mismatch

On Wed, Feb 07, 2018 at 12:57:13AM +0900, Kangmin Park wrote: > From: pr0gr4m No changelog, no sign-off. Changelogs are required but especially in this case, it's not immediately obvious what this patch is about. This patch has unrelated white space changes as well.