Re: [PATCH] android: binder: no outgoing transaction when thread todo has transaction
Sherry, this was found by syzkaller, right? In that case, can you add
the tag so the issue gets closed automatically when this
gets merged?
On Tue, Aug 14, 2018 at 2:28 AM, Sherry Yang wrote:
> When a process dies, failed reply is sent to the sender of any transaction
> queued on a dead thread's todo list. The sender asserts that the
> received failed reply corresponds to the head of the transaction stack.
> This assert can fail if the dead thread is allowed to send outgoing
> transactions when there is already a transaction on its todo list,
> because this new transaction can end up on the transaction stack of the
> original sender. The following steps illustrate how this assertion can
> fail.
>
> 1. Thread1 sends txn19 to Thread2
>(T1->transaction_stack=txn19, T2->todo+=txn19)
> 2. Without processing todo list, Thread2 sends txn20 to Thread1
>(T1->todo+=txn20, T2->transaction_stack=txn20)
> 3. T1 processes txn20 on its todo list
>(T1->transaction_stack=txn20->txn19, T1->todo=)
> 4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
>T1->transaction_stack points to txn20 -- assertion failes
>
> Step 2. is the incorrect behavior. When there is a transaction on a
> thread's todo list, this thread should not be able to send any outgoing
> synchronous transactions. Only the head of the todo list needs to be
> checked because only threads that are waiting for proc work can directly
> receive work from another thread, and no work is allowed to be queued
> on such a thread without waking up the thread. This patch also enforces
> that a thread is not waiting for proc work when a work is directly
> enqueued to its todo list.
>
> Acked-by: Arve Hjønnevåg
> Signed-off-by: Sherry Yang
Reviewed-by: Martijn Coenen
Thanks,
Martijn
> ---
> drivers/android/binder.c | 44 +---
> 1 file changed, 32 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/android/binder.c b/drivers/android/binder.c
> index d58763b6b009..f2081934eb8b 100644
> --- a/drivers/android/binder.c
> +++ b/drivers/android/binder.c
> @@ -822,6 +822,7 @@ static void
> binder_enqueue_deferred_thread_work_ilocked(struct binder_thread *thread,
> struct binder_work *work)
> {
> + WARN_ON(!list_empty(&thread->waiting_thread_node));
> binder_enqueue_work_ilocked(work, &thread->todo);
> }
>
> @@ -839,6 +840,7 @@ static void
> binder_enqueue_thread_work_ilocked(struct binder_thread *thread,
>struct binder_work *work)
> {
> + WARN_ON(!list_empty(&thread->waiting_thread_node));
> binder_enqueue_work_ilocked(work, &thread->todo);
> thread->process_todo = true;
> }
> @@ -1270,19 +1272,12 @@ static int binder_inc_node_nilocked(struct
> binder_node *node, int strong,
> } else
> node->local_strong_refs++;
> if (!node->has_strong_ref && target_list) {
> + struct binder_thread *thread =
> container_of(target_list,
> + struct binder_thread,
> todo);
> binder_dequeue_work_ilocked(&node->work);
> - /*
> -* Note: this function is the only place where we
> queue
> -* directly to a thread->todo without using the
> -* corresponding binder_enqueue_thread_work() helper
> -* functions; in this case it's ok to not set the
> -* process_todo flag, since we know this node work
> will
> -* always be followed by other work that starts queue
> -* processing: in case of synchronous transactions, a
> -* BR_REPLY or BR_ERROR; in case of oneway
> -* transactions, a BR_TRANSACTION_COMPLETE.
> -*/
> - binder_enqueue_work_ilocked(&node->work, target_list);
> + BUG_ON(&thread->todo != target_list);
> + binder_enqueue_deferred_thread_work_ilocked(thread,
> +
> &node->work);
> }
> } else {
> if (!internal)
> @@ -2723,6 +2718,7 @@ static void binder_transaction(struct binder_proc *proc,
> {
> int ret;
> struct binder_transaction *t;
> + struct binder_work *w;
> struct binder_work *tcomplete;
> binder_size_t *offp, *off_end, *off_start;
> binder_size_t off_min;
> @@ -2864,6 +2860,29 @@ static void binder_transaction(struct binder_proc
> *proc,
> goto err_invalid_target_handle;
> }
> binder_inner_proc_lock(proc);
> +
> + w = list_first_entry_or_null(&thread->todo,
> +
Re: [PATCH] drivers/thermal/tegra: fix a doule free devce node
On 2018/8/14 14:39, Daniel Lezcano wrote:
> On 09/08/2018 15:40, zhong jiang wrote:
>> Device node iterators will get the return node. Meawhile, It is
>> also put the previous device node. An explicit put will cause
>> a double put.
> What about:
>
> Subject: drivers/thermal/tegra: Fix a double free on the device node
>
> "The function 'for_each_child_of_node' iterates over the node list by
> dropping the of_node reference of the previous node.
>
> Calling of_node_put() on the iterator is pointless and leads to an
> inconsistent refcounting in addition to a double free. Remove it."
Thank you for doing this. I am sorry for stupid issue.
Sincerely,
zhong jiang
>> Signed-off-by: zhong jiang
>> ---
>> drivers/thermal/tegra/soctherm.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/drivers/thermal/tegra/soctherm.c
>> b/drivers/thermal/tegra/soctherm.c
>> index ed28110..3aa55c9 100644
>> --- a/drivers/thermal/tegra/soctherm.c
>> +++ b/drivers/thermal/tegra/soctherm.c
>> @@ -980,7 +980,6 @@ static void soctherm_init_hw_throt_cdev(struct
>> platform_device *pdev)
>> tcd = thermal_of_cooling_device_register(np_stcc,
>> (char *)name, ts,
>> &throt_cooling_ops);
>> -of_node_put(np_stcc);
>> if (IS_ERR_OR_NULL(tcd)) {
>> dev_err(dev,
>> "throttle-cfg: %s: failed to register cooling
>> device\n",
>>
>
[PATCH] Use default .cfg file name for RTL8723BS devices with id of OBDA8723
For RTL8723BS devices the current config file name is a composite of
both the config name (rtl8723bs) and a postfix of the device-id.
Given the majority of RTL8723BS devices use a device-id of OBDA8723
this simplifies the config file name to use "rtl8723bs_config.bin"
as a default of for these devices.
Signed-off-by: Ian W MORRISON
---
drivers/bluetooth/hci_h5.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index 8eede1197cd2..cce422dc1b8d 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -852,7 +852,9 @@ static int h5_btrtl_setup(struct h5 *h5)
bool flow_control;
int err;
- btrtl_dev = btrtl_initialize(h5->hu->hdev, h5->id);
+ btrtl_dev = strcmp("OBDA8723", h5->id) ?
+ btrtl_initialize(h5->hu->hdev, h5->id) :
+ btrtl_initialize(h5->hu->hdev, NULL);
if (IS_ERR(btrtl_dev))
return PTR_ERR(btrtl_dev);
--
2.17.1
[PATCH 1/2] kconfig: report recursive dependency involving 'imply'
Currently, Kconfig does not report anything about the recursive
dependency where 'imply' keywords are involved.
[Test Code]
config A
bool "a"
config B
bool "b"
imply A
depends on A
In the code above, Kconfig cannot calculate the symbol values correctly
due to the circular dependency. For example, allyesconfig followed by
syncconfig results in an odd behavior because CONFIG_B becomes visible
in syncconfig.
$ make allyesconfig
scripts/kconfig/conf --allyesconfig Kconfig
#
# configuration written to .config
#
$ cat .config
#
# Automatically generated file; DO NOT EDIT.
# Main menu
#
CONFIG_A=y
$ make syncconfig
scripts/kconfig/conf --syncconfig Kconfig
*
* Restart config...
*
*
* Main menu
*
a (A) [Y/n/?] y
b (B) [N/y/?] (NEW)
To report this correctly, sym_check_expr_deps() should recurse to
not only sym->rev_dep.expr but also sym->implied.expr .
At this moment, sym_check_print_recursive() cannot distinguish
'select' and 'imply' since it does not know the precise context
where the recursive dependency is hit. This will be solved by
the next commit.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/symbol.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 4ec8b1f..7de7463a 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -1098,7 +1098,7 @@ static void sym_check_print_recursive(struct symbol
*last_sym)
sym->name ? sym->name : "",
next_sym->name ? next_sym->name : "");
} else {
- fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n",
+ fprintf(stderr, "%s:%d:\tsymbol %s is selected or
implied by %s\n",
prop->file->name, prop->lineno,
sym->name ? sym->name : "",
next_sym->name ? next_sym->name : "");
@@ -1161,8 +1161,13 @@ static struct symbol *sym_check_sym_deps(struct symbol
*sym)
if (sym2)
goto out;
+ sym2 = sym_check_expr_deps(sym->implied.expr);
+ if (sym2)
+ goto out;
+
for (prop = sym->prop; prop; prop = prop->next) {
- if (prop->type == P_CHOICE || prop->type == P_SELECT)
+ if (prop->type == P_CHOICE || prop->type == P_SELECT ||
+ prop->type == P_IMPLY)
continue;
stack.prop = prop;
sym2 = sym_check_expr_deps(prop->visible.expr);
--
2.7.4
[PATCH 2/2] kconfig: improve the recursive dependency report
This commit improves the warning messages of the recursive dependency.
Currently, sym->dir_dep.expr is not checked. Hence, any dependency in
property visibility is regarded as the dependency of the symbol.
[Test Code 1]
config A
bool "a"
depends on B
config B
bool "b"
depends on A
[Test Code 2]
config A
bool "a" if B
config B
bool "b"
depends on A
For both cases above, the same message is displayed:
symbol B depends on A
symbol A depends on B
This commit changes the message for the latter case like this:
symbol B depends on A
symbol A prompt is visible depending on B
Also, 'select' and 'imply' are distinguished.
Signed-off-by: Masahiro Yamada
---
scripts/kconfig/symbol.c | 48 ++--
1 file changed, 34 insertions(+), 14 deletions(-)
diff --git a/scripts/kconfig/symbol.c b/scripts/kconfig/symbol.c
index 7de7463a..9cc443b 100644
--- a/scripts/kconfig/symbol.c
+++ b/scripts/kconfig/symbol.c
@@ -1011,7 +1011,7 @@ static struct dep_stack {
struct dep_stack *prev, *next;
struct symbol *sym;
struct property *prop;
- struct expr *expr;
+ struct expr **expr;
} *check_top;
static void dep_stack_insert(struct dep_stack *stack, struct symbol *sym)
@@ -1076,31 +1076,42 @@ static void sym_check_print_recursive(struct symbol
*last_sym)
fprintf(stderr, "%s:%d:error: recursive dependency
detected!\n",
prop->file->name, prop->lineno);
- if (stack->expr) {
- fprintf(stderr, "%s:%d:\tsymbol %s %s value contains
%s\n",
- prop->file->name, prop->lineno,
+ if (sym_is_choice(sym)) {
+ fprintf(stderr, "%s:%d:\tchoice %s contains symbol
%s\n",
+ menu->file->name, menu->lineno,
+ sym->name ? sym->name : "",
+ next_sym->name ? next_sym->name : "");
+ } else if (sym_is_choice_value(sym)) {
+ fprintf(stderr, "%s:%d:\tsymbol %s is part of choice
%s\n",
+ menu->file->name, menu->lineno,
sym->name ? sym->name : "",
- prop_get_type_name(prop->type),
next_sym->name ? next_sym->name : "");
- } else if (stack->prop) {
+ } else if (stack->expr == &sym->dir_dep.expr) {
fprintf(stderr, "%s:%d:\tsymbol %s depends on %s\n",
prop->file->name, prop->lineno,
sym->name ? sym->name : "",
next_sym->name ? next_sym->name : "");
- } else if (sym_is_choice(sym)) {
- fprintf(stderr, "%s:%d:\tchoice %s contains symbol
%s\n",
- menu->file->name, menu->lineno,
+ } else if (stack->expr == &sym->rev_dep.expr) {
+ fprintf(stderr, "%s:%d:\tsymbol %s is selected by %s\n",
+ prop->file->name, prop->lineno,
sym->name ? sym->name : "",
next_sym->name ? next_sym->name : "");
- } else if (sym_is_choice_value(sym)) {
- fprintf(stderr, "%s:%d:\tsymbol %s is part of choice
%s\n",
- menu->file->name, menu->lineno,
+ } else if (stack->expr == &sym->implied.expr) {
+ fprintf(stderr, "%s:%d:\tsymbol %s is implied by %s\n",
+ prop->file->name, prop->lineno,
sym->name ? sym->name : "",
next_sym->name ? next_sym->name : "");
+ } else if (stack->expr) {
+ fprintf(stderr, "%s:%d:\tsymbol %s %s value contains
%s\n",
+ prop->file->name, prop->lineno,
+ sym->name ? sym->name : "",
+ prop_get_type_name(prop->type),
+ next_sym->name ? next_sym->name : "");
} else {
- fprintf(stderr, "%s:%d:\tsymbol %s is selected or
implied by %s\n",
+ fprintf(stderr, "%s:%d:\tsymbol %s %s is visible
depending on %s\n",
prop->file->name, prop->lineno,
sym->name ? sym->name : "",
+ prop_get_type_name(prop->type),
next_sym->name ? next_sym->name : "");
}
}
@@ -1157,14 +1168,23 @@ static struct symbol *sym_check_sym_deps(struct symbol
*sym)
dep_stack_insert(&stack, sym);
+ stack.exp
Re: [PATCH] drivers/thermal/tegra: fix a doule free devce node
On 09/08/2018 15:40, zhong jiang wrote:
> Device node iterators will get the return node. Meawhile, It is
> also put the previous device node. An explicit put will cause
> a double put.
What about:
Subject: drivers/thermal/tegra: Fix a double free on the device node
"The function 'for_each_child_of_node' iterates over the node list by
dropping the of_node reference of the previous node.
Calling of_node_put() on the iterator is pointless and leads to an
inconsistent refcounting in addition to a double free. Remove it."
> Signed-off-by: zhong jiang
> ---
> drivers/thermal/tegra/soctherm.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/thermal/tegra/soctherm.c
> b/drivers/thermal/tegra/soctherm.c
> index ed28110..3aa55c9 100644
> --- a/drivers/thermal/tegra/soctherm.c
> +++ b/drivers/thermal/tegra/soctherm.c
> @@ -980,7 +980,6 @@ static void soctherm_init_hw_throt_cdev(struct
> platform_device *pdev)
> tcd = thermal_of_cooling_device_register(np_stcc,
>(char *)name, ts,
>&throt_cooling_ops);
> - of_node_put(np_stcc);
> if (IS_ERR_OR_NULL(tcd)) {
> dev_err(dev,
> "throttle-cfg: %s: failed to register cooling
> device\n",
>
--
Facebook |
Twitter |
Re: [PATCH] mmc: Move the mmc driver init earlier
Hi Greg, Ulf Could you help to review this? many thanks! - Feng On Thu, Aug 02, 2018 at 05:15:39PM +0800, Feng Tang wrote: > Hi Ulf, > > On Tue, Jun 12, 2018 at 12:29:50PM +0200, Ulf Hansson wrote: > > On 12 June 2018 at 10:42, Feng Tang wrote: > > > Hi Ulf, > > > > > > Thanks for the review. > > > > > > On Tue, Jun 12, 2018 at 08:25:44AM +0200, Ulf Hansson wrote: > > >> On 8 June 2018 at 11:51, Feng Tang wrote: > > >> > When doing some boot time optimization for an eMMC rootfs NUCs, > > >> > we found the rootfs may spend around 100 microseconds waiting > > >> > for eMMC card to be initialized, then the rootfs could be > > >> > mounted. > > >> > [1.216561] Waiting for root device /dev/mmcblk1p1... > > >> > [1.289262] mmc1: new HS400 MMC card at address 0001 > > >> > [1.289667] mmcblk1: mmc1:0001 R1J56L 14.7 GiB > > >> > [1.289772] mmcblk1boot0: mmc1:0001 R1J56L partition 1 8.00 > > >> > MiB > > >> > [1.289869] mmcblk1boot1: mmc1:0001 R1J56L partition 2 8.00 > > >> > MiB > > >> > [1.289967] mmcblk1rpmb: mmc1:0001 R1J56L partition 3 4.00 > > >> > MiB > > >> > [1.292798] mmcblk1: p1 p2 p3 > > >> > [1.300576] EXT4-fs (mmcblk1p1): couldn't mount as ext3 due > > >> > to feature incompatibilities > > >> > [1.300912] EXT4-fs (mmcblk1p1): couldn't mount as ext2 due > > >> > to feature incompatibilities > > >> > > > >> > And this is a common problem for smartphones, tablets, embedded > > >> > devices and automotive products. This patch will make the eMMC/SD > > >> > card start initializing earlier, by changing its order in > > >> > drivers/Makefile. > > >> > > > >> > On our platform, the waiting for eMMC card is almost eliminated with > > >> > the patch, > > >> > which is critical to boot time. > > >> > > >> I am wondering what kernel version you are running here. There have > > >> been some changes to the mmc initialization path, which perhaps can > > >> help. > > > These logs in commit msg are based on kernel 4.14, and the patch is > > > generated > > > against kernel 4.17. > > > > Right. So it's quite recent, even if lot's of changes have been made > > to the mmc core since then. > > > > A few things (old/new) that is important. > > 1) Check if your mmc host driver support MMC_CAP_WAIT_WHILE_BUSY. That > > should have some effect, avoiding unnecessary polling. > > I've followed your suggestion to try 4.18-rc4 kernel, and there is around > 15% reduction in the rootfs mount's waiting for eMMC storage. And our > SDHCI pci controller does support MMC_CAP_WAIT_WHILE_BUSY. > > > > > 2) Since 4.18 rc1, you will be able to configure an over estimated > > "power on" delay (via DT as well). Look at commit > > 6d796c68cd15234a33a4bd2ef7231125fea2dc6c. > > > > 3) If you use a DT based platform, I think what people do is to > > re-organize the order of device nodes, such that as many as possible > > -EPROBE_DEFER is avoided to be returned by drivers. This is also not a > > good solution, but the best we have at this moment. > > Our platform is NUC with Celeron processors, whose most IO controllers > are PCI device. > > > > > > > > >> > > >> > > > >> > Signed-off-by: Feng Tang > > >> > --- > > >> > drivers/Makefile | 4 +++- > > >> > 1 file changed, 3 insertions(+), 1 deletion(-) > > >> > > > >> > diff --git a/drivers/Makefile b/drivers/Makefile > > >> > index 24cd47014657..c473afd3c688 100644 > > >> > --- a/drivers/Makefile > > >> > +++ b/drivers/Makefile > > >> > @@ -50,6 +50,9 @@ obj-$(CONFIG_REGULATOR) += regulator/ > > >> > # reset controllers early, since gpu drivers might rely on them to > > >> > initialize > > >> > obj-$(CONFIG_RESET_CONTROLLER) += reset/ > > >> > > > >> > +# put mmc early as many morden devices use emm/sd card as rootfs > > >> > storage > > >> > +obj-y += mmc/ > > >> > + > > >> > > >> Your suggested approach isn't really a solution, as it may work for > > >> your particular case but not for everybody else. > > > > > > Do you mean the patch may break some platforms? Yes, I only tested on > > > some IA based NUCs, and I did think about other architectures, things > > > that may affect MMC are gpio/clk/pinctrl, and those are still earlier > > > than mmc after change. > > > > I don't know if it breaks things, potentially it could, if drivers > > don't implement support for -EPROBE_DEFER properly. > > > > However, more importantly, it's not real fix to the problem, just > > something that seems to work for you. > > IMHO I don't think the 100ms waiting is a problem of mmc core or SDHCI > host controller :), complex HWs' initializations take time, like the > SATA disk, the GFX. > > Currently the mmc folder is too late in the drivers/Makefile, and network > device, thermal, spi, usb and many other controllers get initialized > before mmc (which is the common rootfs storage for smartphones and > embedded devices), which triggers
Re: [PATCH v2] mm: migration: fix migration of huge PMD shared pages
On Mon, Aug 13, 2018 at 05:30:58PM -0700, Mike Kravetz wrote:
> The page migration code employs try_to_unmap() to try and unmap the
> source page. This is accomplished by using rmap_walk to find all
> vmas where the page is mapped. This search stops when page mapcount
> is zero. For shared PMD huge pages, the page map count is always 1
> no matter the number of mappings. Shared mappings are tracked via
> the reference count of the PMD page. Therefore, try_to_unmap stops
> prematurely and does not completely unmap all mappings of the source
> page.
>
> This problem can result is data corruption as writes to the original
> source page can happen after contents of the page are copied to the
> target page. Hence, data is lost.
>
> This problem was originally seen as DB corruption of shared global
> areas after a huge page was soft offlined due to ECC memory errors.
> DB developers noticed they could reproduce the issue by (hotplug)
> offlining memory used to back huge pages. A simple testcase can
> reproduce the problem by creating a shared PMD mapping (note that
> this must be at least PUD_SIZE in size and PUD_SIZE aligned (1GB on
> x86)), and using migrate_pages() to migrate process pages between
> nodes while continually writing to the huge pages being migrated.
>
> To fix, have the try_to_unmap_one routine check for huge PMD sharing
> by calling huge_pmd_unshare for hugetlbfs huge pages. If it is a
> shared mapping it will be 'unshared' which removes the page table
> entry and drops the reference on the PMD page. After this, flush
> caches and TLB.
>
> Fixes: 39dde65c9940 ("shared page table for hugetlb page")
> Signed-off-by: Mike Kravetz
> ---
> v2: Fixed build issue for !CONFIG_HUGETLB_PAGE and typos in comment
>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
Re: [f2fs-dev] [PATCH v3] f2fs: fix performance issue observed with multi-thread sequential read
On 2018/8/14 12:04, Jaegeuk Kim wrote: > On 08/14, Chao Yu wrote: >> On 2018/8/14 4:11, Jaegeuk Kim wrote: >>> On 08/13, Chao Yu wrote: Hi Jaegeuk, On 2018/8/11 2:56, Jaegeuk Kim wrote: > This reverts the commit - "b93f771 - f2fs: remove writepages lock" > to fix the drop in sequential read throughput. > > Test: ./tiotest -t 32 -d /data/tio_tmp -f 32 -b 524288 -k 1 -k 3 -L > device: UFS > > Before - > read throughput: 185 MB/s > total read requests: 85177 (of these ~8 are 4KB size requests). > total write requests: 2546 (of these ~2208 requests are written in 512KB). > > After - > read throughput: 758 MB/s > total read requests: 2417 (of these ~2042 are 512KB reads). > total write requests: 2701 (of these ~2034 requests are written in 512KB). IMO, it only impact sequential read performance in a large file which may be fragmented during multi-thread writing. In android environment, mostly, the large file should be cold type, such as apk, mp3, rmvb, jpeg..., so I think we only need to serialize writepages() for cold data area writer. So how about adding a mount option to serialize writepage() for different type of log, e.g. in android, using serialize=4; by default, using serialize=7 HOT_DATA 1 WARM_DATA 2 COLD_DATA 4 >>> >>> Well, I don't think we need to give too many mount options for this >>> fragmented >>> case. How about doing this for the large files only like this? >> >> Thread A write 512 pages Thread B write 8 pages >> >> - writepages() >> - mutex_lock(&sbi->writepages); >> - writepage(); >> ... >> - writepages() >> - writepage() >> >> - writepage(); >> ... >> - mutex_unlock(&sbi->writepages); >> >> Above case will also cause fragmentation since we didn't serialize all >> concurrent IO with the lock. >> >> Do we need to consider such case? > > We can simply allow 512 and 8 in the same segment, which would not a big deal, > when considering starvation of Thread B. Yeah, but in reality, there would be more threads competing in same log header, so I worry that the effect of defragmenting will not so good as we expect, anyway, for benchmark, it's enough. Thanks, > >> >> Thanks, >> >>> >>> >From 4fea0b6e4da8512a72dd52afc7a51beb35966ad9 Mon Sep 17 00:00:00 2001 >>> From: Jaegeuk Kim >>> Date: Thu, 9 Aug 2018 17:53:34 -0700 >>> Subject: [PATCH] f2fs: fix performance issue observed with multi-thread >>> sequential read >>> >>> This reverts the commit - "b93f771 - f2fs: remove writepages lock" >>> to fix the drop in sequential read throughput. >>> >>> Test: ./tiotest -t 32 -d /data/tio_tmp -f 32 -b 524288 -k 1 -k 3 -L >>> device: UFS >>> >>> Before - >>> read throughput: 185 MB/s >>> total read requests: 85177 (of these ~8 are 4KB size requests). >>> total write requests: 2546 (of these ~2208 requests are written in 512KB). >>> >>> After - >>> read throughput: 758 MB/s >>> total read requests: 2417 (of these ~2042 are 512KB reads). >>> total write requests: 2701 (of these ~2034 requests are written in 512KB). >>> >>> Signed-off-by: Sahitya Tummala >>> Signed-off-by: Jaegeuk Kim >>> --- >>> Documentation/ABI/testing/sysfs-fs-f2fs | 8 >>> fs/f2fs/data.c | 10 ++ >>> fs/f2fs/f2fs.h | 2 ++ >>> fs/f2fs/segment.c | 1 + >>> fs/f2fs/super.c | 1 + >>> fs/f2fs/sysfs.c | 2 ++ >>> 6 files changed, 24 insertions(+) >>> >>> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs >>> b/Documentation/ABI/testing/sysfs-fs-f2fs >>> index 9b0123388f18..94a24aedcdb2 100644 >>> --- a/Documentation/ABI/testing/sysfs-fs-f2fs >>> +++ b/Documentation/ABI/testing/sysfs-fs-f2fs >>> @@ -51,6 +51,14 @@ Description: >>> Controls the dirty page count condition for the in-place-update >>> policies. >>> >>> +What: /sys/fs/f2fs//min_seq_blocks >>> +Date: August 2018 >>> +Contact: "Jaegeuk Kim" >>> +Description: >>> +Controls the dirty page count condition for batched sequential >>> +writes in ->writepages. >>> + >>> + >>> What: /sys/fs/f2fs//min_hot_blocks >>> Date: March 2017 >>> Contact: "Jaegeuk Kim" >>> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c >>> index 45f043ee48bd..f09231b1cc74 100644 >>> --- a/fs/f2fs/data.c >>> +++ b/fs/f2fs/data.c >>> @@ -2132,6 +2132,7 @@ static int __f2fs_write_data_pages(struct >>> address_space *mapping, >>> struct f2fs_sb_info *sbi = F2FS_I_SB(inode); >>> struct blk_plug plug; >>> int ret; >>> + bool locked = false; >>> >>> /* deal with chardevs and other special file */ >>> if (
[PATCH 0/2] add the Amlogic Meson PCIe controller driver.
The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI core. This patchset add the driver and dt-bindings of the controller. Yue Wang (2): dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller PCI: meson: add the Amlogic Meson PCIe controller driver .../devicetree/bindings/pci/amlogic,meson-pcie.txt | 57 ++ drivers/pci/controller/dwc/Kconfig | 12 + drivers/pci/controller/dwc/Makefile| 1 + drivers/pci/controller/dwc/pci-meson.c | 588 + 4 files changed, 658 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt create mode 100644 drivers/pci/controller/dwc/pci-meson.c -- 2.7.4
[PATCH 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe controller
From: Yue Wang
The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare
PCI core. This patch adds documentation for the DT bindings in Meson PCIe
controller.
Signed-off-by: Yue Wang
Signed-off-by: Hanjie Lin
---
.../devicetree/bindings/pci/amlogic,meson-pcie.txt | 57 ++
1 file changed, 57 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
new file mode 100644
index 000..48233e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/amlogic,meson-pcie.txt
@@ -0,0 +1,57 @@
+Amlogic Meson AXG DWC PCIE SoC controller
+
+Amlogic Meson PCIe host controller is based on the Synopsys DesignWare PCI
core.
+It shares common functions with the PCIe DesignWare core driver and
+inherits common properties defined in
+Documentation/devicetree/bindings/pci/designware-pci.txt.
+
+Additional properties are described here:
+
+Required properties:
+- compatible:
+ should contain "amlogic,axg-pcie" to identify the core.
+- reg:
+ Should contain the configuration address space.
+- reg-names: Must be
+ - "elbi"External local bus interface registers
+ - "cfg" Meson specific registers
+ - "config" PCIe configuration space
+- clocks: Must contain an entry for each entry in clock-names.
+- clock-names: Must include the following entries:
+ - "pcie"
+ - "pcie_bus"
+ - "pcie_general"
+ - "pcie_mipi_en"
+
+Example configuration:
+
+ pcie: pcie@d000 {
+ compatible = "amlogic,axg-pcie", "snps,dw-pcie";
+ reg = <0x0 0xf980 0x0 0x40
+ 0x0 0xff646000 0x0 0x2000
+ 0x0 0xf9f0 0x0 0x10>;
+ reg-names = "elbi", "cfg", "config";
+ reset-gpio = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
+ interrupts = <0 177 IRQ_TYPE_EDGE_RISING>;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0>;
+ interrupt-map = <0 0 0 0 &gic GIC_SPI 179
IRQ_TYPE_EDGE_RISING>;
+ bus-range = <0x0 0xff>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ device_type = "pci";
+ phys = <&pcie_phy>;
+ ranges = <0x8200 0 0 0x0 0xf9c0 0 0x0030>;
+ num-lanes = <1>;
+ pcie-num = <1>;
+
+ clocks = <&clkc CLKID_USB
+ &clkc CLKID_MIPI_ENABLE
+ &clkc CLKID_PCIE_A
+ &clkc CLKID_PCIE_CML_EN0>;
+ clock-names = "pcie_general",
+ "pcie_refpll",
+ "pcie_mipi_en",
+ "pcie",
+ "port";
+ };
--
2.7.4
[PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe controller driver
From: Yue Wang
The Amlogic Meson PCIe host controller is based on the Synopsys DesignWare
PCI core. This patch adds the driver support for Meson PCIe controller.
Signed-off-by: Yue Wang
Signed-off-by: Hanjie Lin
---
drivers/pci/controller/dwc/Kconfig | 12 +
drivers/pci/controller/dwc/Makefile| 1 +
drivers/pci/controller/dwc/pci-meson.c | 588 +
3 files changed, 601 insertions(+)
create mode 100644 drivers/pci/controller/dwc/pci-meson.c
diff --git a/drivers/pci/controller/dwc/Kconfig
b/drivers/pci/controller/dwc/Kconfig
index 91b0194..6cb36f6 100644
--- a/drivers/pci/controller/dwc/Kconfig
+++ b/drivers/pci/controller/dwc/Kconfig
@@ -193,4 +193,16 @@ config PCIE_HISI_STB
help
Say Y here if you want PCIe controller support on HiSilicon STB SoCs
+config PCI_MESON
+ bool "MESON PCIe controller"
+ depends on PCI
+ depends on PCI_MSI_IRQ_DOMAIN
+ select PCIEPORTBUS
+ select PCIE_DW_HOST
+ help
+ Say Y here if you want to enable PCI controller support on Amlogic
+ SoCs. The PCI controller on Amlogic is based on DesignWare hardware
+ and therefore the driver re-uses the DesignWare core functions to
+ implement the driver.
+
endmenu
diff --git a/drivers/pci/controller/dwc/Makefile
b/drivers/pci/controller/dwc/Makefile
index 5d2ce72..cf676bd 100644
--- a/drivers/pci/controller/dwc/Makefile
+++ b/drivers/pci/controller/dwc/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_PCIE_ARMADA_8K) += pcie-armada8k.o
obj-$(CONFIG_PCIE_ARTPEC6) += pcie-artpec6.o
obj-$(CONFIG_PCIE_KIRIN) += pcie-kirin.o
obj-$(CONFIG_PCIE_HISI_STB) += pcie-histb.o
+obj-$(CONFIG_PCI_MESON) += pci-meson.o
# The following drivers are for devices that use the generic ACPI
# pci_root.c driver but don't support standard ECAM config access.
diff --git a/drivers/pci/controller/dwc/pci-meson.c
b/drivers/pci/controller/dwc/pci-meson.c
new file mode 100644
index 000..1e96e45
--- /dev/null
+++ b/drivers/pci/controller/dwc/pci-meson.c
@@ -0,0 +1,588 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PCIe host controller driver for Amlogic MESON SoCs
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Author: Yue Wang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pcie-designware.h"
+
+#define to_meson_pcie(x) dev_get_drvdata((x)->dev)
+
+/* External local bus interface registers */
+#define PLR_OFFSET 0x700
+#define PCIE_PORT_LINK_CTRL_OFF(PLR_OFFSET + 0x10)
+#define FAST_LINK_MODE BIT(7)
+#define LINK_CAPABLE_MASK GENMASK(21, 16)
+#define LINK_CAPABLE_X1BIT(16)
+
+#define PCIE_GEN2_CTRL_OFF (PLR_OFFSET + 0x10c)
+#define NUM_OF_LANES_MASK GENMASK(12, 8)
+#define NUM_OF_LANES_X1BIT(8)
+#define DIRECT_SPEED_CHANGEBIT(17)
+
+#define TYPE1_HDR_OFFSET 0x0
+#define PCIE_STATUS_COMMAND(TYPE1_HDR_OFFSET + 0x04)
+#define PCI_IO_EN BIT(0)
+#define PCI_MEM_SPACE_EN BIT(1)
+#define PCI_BUS_MASTER_EN BIT(2)
+
+#define PCIE_BASE_ADDR0(TYPE1_HDR_OFFSET + 0x10)
+#define PCIE_BASE_ADDR1(TYPE1_HDR_OFFSET + 0x14)
+
+#define PCIE_CAP_OFFSET0x70
+#define PCIE_DEV_CTRL_DEV_STUS (PCIE_CAP_OFFSET + 0x08)
+#define PCIE_CAP_MAX_PAYLOAD_MASK GENMASK(7, 5)
+#define PCIE_CAP_MAX_PAYLOAD_SIZE(x) ((x) << 5)
+#define PCIE_CAP_MAX_READ_REQ_MASK GENMASK(14, 12)
+#define PCIE_CAP_MAX_READ_REQ_SIZE(x) ((x) << 12)
+
+#define PCI_CLASS_REVISION_MASKGENMASK(7, 0)
+
+/* PCIe specific config registers */
+#define PCIE_CFG0 0x0
+#define APP_LTSSM_ENABLE BIT(7)
+
+#define PCIE_CFG_STATUS12 0x30
+#define IS_SMLH_LINK_UP(x) ((x) & (1 << 6) ? 1 : 0)
+#define IS_RDLH_LINK_UP(x) ((x) & (1 << 16) ? 1 : 0)
+#define IS_LTSSM_UP(x) x) >> 10) & 0x1f) == 0x11 ? 1 : 0)
+
+#define PCIE_CFG_STATUS17 0x44
+#define PM_CURRENT_STATE(x)(((x) >> 7) & 0x1)
+
+#define WAIT_LINKUP_TIMEOUT2000
+#define PORT_CLK_RATE 1UL
+#define MAX_PAYLOAD_SIZE 256
+#define MAX_READ_REQ_SIZE 256
+
+enum pcie_data_rate {
+ PCIE_GEN1,
+ PCIE_GEN2,
+ PCIE_GEN3,
+ PCIE_GEN4
+};
+
+struct meson_pcie_mem_res {
+ void __iomem *elbi_base; /* DT 0th resource */
+ void __iomem *cfg_base; /* DT 2nd resource */
+};
+
+struct meson_pcie_clk_res {
+ struct clk *clk;
+ struct clk *mipi_gate;
+ struct clk *port_clk;
+ struct clk *general_clk;
+};
+
+struct meson_pcie {
+ struct dw_pcie pci;
+ struct meson_pcie_mem_res mem_res;
+ struct meson_pcie_clk_res clk_res;
+
Re: [PATCH] perf tools: Fix check-headers.sh AND list path of execution
On Mon, Aug 13, 2018 at 9:58 PM Arnaldo Carvalho de Melo wrote: > Thanks, applied the three patches to acme/perf/core. > > - Arnaldo Thanks.
[PATCH 0/2] add the Amlogic Meson PCIe phy driver.
This patcheset add the driver and dt-bindings for the Meson-PCIE-PHY controller. Yue Wang (2): dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe Phy controller PCI: meson: add the Amlogic Meson PCIe phy driver .../bindings/phy/amlogic,meson-pcie-phy.txt| 31 drivers/phy/amlogic/Kconfig| 8 ++ drivers/phy/amlogic/Makefile | 1 + drivers/phy/amlogic/phy-meson-axg-pcie.c | 160 + 4 files changed, 200 insertions(+) create mode 100644 Documentation/devicetree/bindings/phy/amlogic,meson-pcie-phy.txt create mode 100644 drivers/phy/amlogic/phy-meson-axg-pcie.c -- 2.7.4
[PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe phy driver
From: Yue Wang
The Meson-PCIE-PHY controller supports the 5-Gbps data rate
of the PCI Express Gen 2 specification and is backwardcompatible
with the 2.5-Gbps Gen 1.1 specification with only
inferred idle detection supported on AMLOGIC SoCs.
Signed-off-by: Yue Wang
Signed-off-by: Hanjie Lin
---
drivers/phy/amlogic/Kconfig | 8 ++
drivers/phy/amlogic/Makefile | 1 +
drivers/phy/amlogic/phy-meson-axg-pcie.c | 160 +++
3 files changed, 169 insertions(+)
create mode 100644 drivers/phy/amlogic/phy-meson-axg-pcie.c
diff --git a/drivers/phy/amlogic/Kconfig b/drivers/phy/amlogic/Kconfig
index 23fe1cd..3ab07f9 100644
--- a/drivers/phy/amlogic/Kconfig
+++ b/drivers/phy/amlogic/Kconfig
@@ -36,3 +36,11 @@ config PHY_MESON_GXL_USB3
Enable this to support the Meson USB3 PHY and OTG detection
IP block found in Meson GXL and GXM SoCs.
If unsure, say N.
+
+config PHY_MESON_AXG_PCIE
+ bool "Meson AXG PCIe PHY driver"
+ depends on OF && (ARCH_MESON || COMPILE_TEST)
+ select GENERIC_PHY
+ help
+ Enable PCIe PHY support for Meson AXG SoC series.
+ This driver provides PHY interface for Meson PCIe controller.
\ No newline at end of file
diff --git a/drivers/phy/amlogic/Makefile b/drivers/phy/amlogic/Makefile
index 4fd8848..5ab8578 100644
--- a/drivers/phy/amlogic/Makefile
+++ b/drivers/phy/amlogic/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_PHY_MESON8B_USB2) += phy-meson8b-usb2.o
obj-$(CONFIG_PHY_MESON_GXL_USB2) += phy-meson-gxl-usb2.o
obj-$(CONFIG_PHY_MESON_GXL_USB3) += phy-meson-gxl-usb3.o
+obj-$(CONFIG_PHY_MESON_AXG_PCIE) += phy-meson-axg-pcie.o
diff --git a/drivers/phy/amlogic/phy-meson-axg-pcie.c
b/drivers/phy/amlogic/phy-meson-axg-pcie.c
new file mode 100644
index 000..8bc5c49
--- /dev/null
+++ b/drivers/phy/amlogic/phy-meson-axg-pcie.c
@@ -0,0 +1,160 @@
+// SPDX-License-Identifier: (GPL-2.0+ or MIT)
+/*
+ * Amlogic MESON SoC series PCIe PHY driver
+ *
+ * Phy provider for PCIe controller on MESON SoC series
+ *
+ * Copyright (c) 2018 Amlogic, inc.
+ * Yue Wang
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct meson_pcie_phy_data {
+ const struct phy_ops*ops;
+};
+
+struct meson_pcie_reset {
+ struct reset_control*port_a;
+ struct reset_control*port_b;
+ struct reset_control*phy;
+ struct reset_control*apb;
+};
+
+struct meson_pcie_phy {
+ const struct meson_pcie_phy_data*data;
+ struct meson_pcie_reset reset;
+ void __iomem*phy_base;
+};
+
+static int meson_pcie_phy_init(struct phy *phy)
+{
+ struct meson_pcie_phy *mphy = phy_get_drvdata(phy);
+ struct meson_pcie_reset *mrst = &mphy->reset;
+
+ writel(0x1c, mphy->phy_base);
+ reset_control_assert(mrst->port_a);
+ reset_control_assert(mrst->port_b);
+ reset_control_assert(mrst->phy);
+ reset_control_assert(mrst->apb);
+ udelay(400);
+ reset_control_deassert(mrst->port_a);
+ reset_control_deassert(mrst->port_b);
+ reset_control_deassert(mrst->phy);
+ reset_control_deassert(mrst->apb);
+ udelay(500);
+
+ return 0;
+}
+
+static const struct phy_ops meson_phy_ops = {
+ .init = meson_pcie_phy_init,
+ .owner = THIS_MODULE,
+};
+
+static const struct meson_pcie_phy_data meson_pcie_phy_data = {
+ .ops= &meson_phy_ops,
+};
+
+static const struct of_device_id meson_pcie_phy_match[] = {
+ {
+ .compatible = "amlogic,axg-pcie-phy",
+ .data = &meson_pcie_phy_data,
+ },
+ {},
+};
+
+static int meson_pcie_phy_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct meson_pcie_phy *mphy;
+ struct meson_pcie_reset *mrst;
+ struct phy *generic_phy;
+ struct phy_provider *phy_provider;
+ struct resource *res;
+ const struct meson_pcie_phy_data *data;
+
+ data = of_device_get_match_data(dev);
+ if (!data)
+ return -ENODEV;
+
+ mphy = devm_kzalloc(dev, sizeof(*mphy), GFP_KERNEL);
+ if (!mphy)
+ return -ENOMEM;
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ mphy->phy_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(mphy->phy_base))
+ return PTR_ERR(mphy->phy_base);
+
+ mrst = &mphy->reset;
+
+ mrst->port_a = devm_reset_control_get_shared(dev, "port_a");
+ if (IS_ERR(mrst->port_a)) {
+ if (PTR_ERR(mrst->port_a) != -EPROBE_DEFER)
+ dev_err(dev, "couldn't get port a reset %ld\n",
+ PTR_ERR(mrst->port_a));
+
+ return PTR_ERR(mrst->port_a);
+ }
+
+ mrst->port_b = devm_reset_control_get_shared(dev, "port_b");
+ if (IS_ERR(mrst->port_b)) {
+ if (PTR_ERR
[PATCH 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe Phy controller
From: Yue Wang
The Meson-PCIE-PHY controller supports the 5-Gbps data rate
of the PCI Express Gen 2 specification and is backwardcompatible
with the 2.5-Gbps Gen 1.1 specification with only
inferred idle detection supported on AMLOGIC SoCs.
Signed-off-by: Hanjie Lin
Signed-off-by: Yue Wang
---
.../bindings/phy/amlogic,meson-pcie-phy.txt| 31 ++
1 file changed, 31 insertions(+)
create mode 100644
Documentation/devicetree/bindings/phy/amlogic,meson-pcie-phy.txt
diff --git a/Documentation/devicetree/bindings/phy/amlogic,meson-pcie-phy.txt
b/Documentation/devicetree/bindings/phy/amlogic,meson-pcie-phy.txt
new file mode 100644
index 000..db99085
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/amlogic,meson-pcie-phy.txt
@@ -0,0 +1,31 @@
+* Amlogic Meson AXG PCIE PHY binding
+
+Required properties:
+- compatible: Should be
+ - "amlogic,axg-pcie-phy"
+- #phys-cells: must be 0 (see phy-bindings.txt in this directory)
+- reg: The base address and length of the registers
+- resets: phandle to the reset lines
+- reset-names: must contain "phy" and "peripheral"
+ - "port_a" Port A reset
+ - "port_b" Port B reset
+ - "phy" PHY reset
+ - "apb" APB reset
+Optional properties:
+- phy-supply: see phy-bindings.txt in this directory
+
+Example:
+ pcie_phy: pcie-phy@ff644000 {
+ #phy-cells = <0>;
+ compatible = "amlogic,axg-pcie-phy";
+ reg = <0x0 0xff644000 0x0 0x2000>;
+ resets = <&reset RESET_PCIE_A>,
+ <&reset RESET_PCIE_B>,
+ <&reset RESET_PCIE_PHY>,
+ <&reset RESET_PCIE_APB>;
+ reset-names =
+ "port_a",
+ "port_b",
+ "phy",
+ "apb";
+ };
--
2.7.4
RE: [RESEND PATCH] tee: add kernel internal client interface
Hi jens:
Actually, we have already used the kernel client api in our product(poplar
board).
Thank you for the upstream.
Tested-by: Zeng Tao
Regards
Zengtao
>-Original Message-
>From: Jens Wiklander [mailto:jens.wiklan...@linaro.org]
>Sent: Monday, July 09, 2018 2:16 PM
>To: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>tee-...@lists.linaro.org
>Cc: Zengtao (B) ; Victor Chong
>; Jerome Forissier ;
>Jens Wiklander
>Subject: [RESEND PATCH] tee: add kernel internal client interface
>
>Adds a kernel internal TEE client interface to be used by other drivers.
>
>Signed-off-by: Jens Wiklander
>---
> drivers/tee/tee_core.c | 113 +---
> include/linux/tee_drv.h | 73 ++
> 2 files changed, 179 insertions(+), 7 deletions(-)
>
>diff --git a/drivers/tee/tee_core.c b/drivers/tee/tee_core.c index
>dd46b758852a..7b2bb4c50058 100644
>--- a/drivers/tee/tee_core.c
>+++ b/drivers/tee/tee_core.c
>@@ -38,15 +38,13 @@ static DEFINE_SPINLOCK(driver_lock); static struct
>class *tee_class; static dev_t tee_devt;
>
>-static int tee_open(struct inode *inode, struct file *filp)
>+static struct tee_context *teedev_open(struct tee_device *teedev)
> {
> int rc;
>- struct tee_device *teedev;
> struct tee_context *ctx;
>
>- teedev = container_of(inode->i_cdev, struct tee_device, cdev);
> if (!tee_device_get(teedev))
>- return -EINVAL;
>+ return ERR_PTR(-EINVAL);
>
> ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
> if (!ctx) {
>@@ -57,16 +55,16 @@ static int tee_open(struct inode *inode, struct file *filp)
> kref_init(&ctx->refcount);
> ctx->teedev = teedev;
> INIT_LIST_HEAD(&ctx->list_shm);
>- filp->private_data = ctx;
> rc = teedev->desc->ops->open(ctx);
> if (rc)
> goto err;
>
>- return 0;
>+ return ctx;
> err:
> kfree(ctx);
> tee_device_put(teedev);
>- return rc;
>+ return ERR_PTR(rc);
>+
> }
>
> void teedev_ctx_get(struct tee_context *ctx) @@ -100,6 +98,18 @@ static
>void teedev_close_context(struct tee_context *ctx)
> teedev_ctx_put(ctx);
> }
>
>+static int tee_open(struct inode *inode, struct file *filp) {
>+ struct tee_context *ctx;
>+
>+ ctx = teedev_open(container_of(inode->i_cdev, struct tee_device, cdev));
>+ if (IS_ERR(ctx))
>+ return PTR_ERR(ctx);
>+
>+ filp->private_data = ctx;
>+ return 0;
>+}
>+
> static int tee_release(struct inode *inode, struct file *filp) {
> teedev_close_context(filp->private_data);
>@@ -928,6 +938,95 @@ void *tee_get_drvdata(struct tee_device *teedev) }
>EXPORT_SYMBOL_GPL(tee_get_drvdata);
>
>+struct match_dev_data {
>+ struct tee_ioctl_version_data *vers;
>+ const void *data;
>+ int (*match)(struct tee_ioctl_version_data *, const void *); };
>+
>+static int match_dev(struct device *dev, const void *data) {
>+ const struct match_dev_data *match_data = data;
>+ struct tee_device *teedev = container_of(dev, struct tee_device, dev);
>+
>+ teedev->desc->ops->get_version(teedev, match_data->vers);
>+ return match_data->match(match_data->vers, match_data->data); }
>+
>+struct tee_context *
>+tee_client_open_context(struct tee_context *start,
>+ int (*match)(struct tee_ioctl_version_data *,
>+ const void *),
>+ const void *data, struct tee_ioctl_version_data *vers) {
>+ struct device *dev = NULL;
>+ struct device *put_dev = NULL;
>+ struct tee_context *ctx = NULL;
>+ struct tee_ioctl_version_data v;
>+ struct match_dev_data match_data = { vers ? vers : &v, data, match };
>+
>+ if (start)
>+ dev = &start->teedev->dev;
>+
>+ do {
>+ dev = class_find_device(tee_class, dev, &match_data, match_dev);
>+ if (!dev) {
>+ ctx = ERR_PTR(-ENOENT);
>+ break;
>+ }
>+
>+ put_device(put_dev);
>+ put_dev = dev;
>+
>+ ctx = teedev_open(container_of(dev, struct tee_device, dev));
>+ } while (IS_ERR(ctx) && PTR_ERR(ctx) != -ENOMEM);
>+
>+ put_device(put_dev);
>+ return ctx;
>+}
>+EXPORT_SYMBOL_GPL(tee_client_open_context);
>+
>+void tee_client_close_context(struct tee_context *ctx) {
>+ teedev_close_context(ctx);
>+}
>+EXPORT_SYMBOL_GPL(tee_client_close_context);
>+
>+void tee_client_get_version(struct tee_context *ctx,
>+ struct tee_ioctl_version_data *vers) {
>+ ctx->teedev->desc->ops->get_version(ctx->teedev, vers); }
>+EXPORT_SYMBOL_GPL(tee_client_get_version);
>+
>+int tee_client_open_session(struct tee_context *ctx,
>+ struct tee_ioctl_open_session_arg *arg,
>+ struct tee_param *param)
>+{
>+ if (!ctx->teedev->desc->ops->open_session)
>+ return
[PATCH RFC] Documentation/scheduler/sched-stats.txt: correct jiffies to ns
The unit of run_daly and rq_cpu_time is ns instead of jiffies. Signed-off-by: Weiping Zhang --- Documentation/scheduler/sched-stats.txt | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/Documentation/scheduler/sched-stats.txt b/Documentation/scheduler/sched-stats.txt index 8259b34a66ae..e7d1f614a1f1 100644 --- a/Documentation/scheduler/sched-stats.txt +++ b/Documentation/scheduler/sched-stats.txt @@ -48,9 +48,8 @@ Next two are try_to_wake_up() statistics: 6) # of times try_to_wake_up() was called to wake up the local cpu Next three are statistics describing scheduling latency: - 7) sum of all time spent running by tasks on this processor (in jiffies) - 8) sum of all time spent waiting to run by tasks on this processor (in -jiffies) + 7) sum of all time spent running by tasks on this processor (in ns) + 8) sum of all time spent waiting to run by tasks on this processor (in ns) 9) # of timeslices run on this cpu -- 2.14.1
Re: [PATCH] remoteproc/davinci: Mark error recovery as disabled
Hi Bjorn, On Tuesday 14 August 2018 12:22 AM, Bjorn Andersson wrote: > On Mon 13 Aug 08:11 PDT 2018, Suman Anna wrote: > >> Hi Bjorn, >> >> On 07/23/2018 06:27 PM, Suman Anna wrote: >>> The Davinci remoteproc driver does not support error recovery at >>> present, so mark the corresponding remoteproc flag appropriately >>> so that the debugfs flag shows the value as 'disabled' by default. >>> >>> Signed-off-by: Suman Anna >> >> Can you pick up this minor patch for 4.19 please, I do not see this in >> your rproc-next branch? >> > > Of course, the patch is applied now, will send my pull request in a few > days. Can you also please pick patch 1/4 here: https://patchwork.kernel.org/patch/10479365/ Thanks, Sekhar
Re: [PATCH v1 10/10] MAINTAINERS: Add entry for Qualcomm TSENS thermal drivers
On 8/9/2018 6:02 PM, Amit Kucheria wrote: Create an entry for the TSENS drivers and mark them as maintained Signed-off-by: Amit Kucheria Thanks Amit for signing up to maintain this driver. Acked-by: Rajendra Nayak --- MAINTAINERS | 7 +++ 1 file changed, 7 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 68b4ff8ed205..ca6183d6d545 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -11862,6 +11862,13 @@ L: linux-arm-...@vger.kernel.org S:Maintained F:drivers/iommu/qcom_iommu.c +QUALCOMM TSENS THERMAL DRIVER +M: Amit Kucheria +L: linux...@vger.kernel.org +L: linux-arm-...@vger.kernel.org +S: Maintained +F: drivers/thermal/qcom/ + QUALCOMM VENUS VIDEO ACCELERATOR DRIVER M:Stanimir Varbanov L:linux-me...@vger.kernel.org
Re: [PATCH v3 07/17] x86/pci: add Hygon PCI vendor and northbridge support
On 2018/8/14 6:14, Bjorn Helgaas wrote: On Sat, Aug 11, 2018 at 09:27:42PM +0800, Pu Wen wrote: diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 2950223..d0e98a9 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -511,6 +511,8 @@ #define PCI_DEVICE_ID_AMI_MEGARAID0x9010 #define PCI_DEVICE_ID_AMI_MEGARAID2 0x9060 +#define PCI_VENDOR_ID_HYGON 0x1d94 Please add this entry so pci_ids.h remains sorted by Vendor ID, then Device ID, as the comment at the top suggests. Thanks for the suggestion. Will place PCI_VENDOR_ID_HYGON between PCI_VENDOR_ID_AMAZON(0x1d0f) and PCI_VENDOR_ID_TEKRAM(0x1de1) in next patch set. Pu Wen With that changed, Acked-by: Bjorn Helgaas # pci_ids.h #define PCI_VENDOR_ID_AMD 0x1022 #define PCI_DEVICE_ID_AMD_K8_NB 0x1100 #define PCI_DEVICE_ID_AMD_K8_NB_ADDRMAP 0x1101 -- 2.7.4
Re: [PATCH 6/9] platform: goldfish: pipe: Fail compilation if structs are too large
On Mon, 2018-08-13 at 20:47 -0700, Roman Kiryanov wrote: > Hi, > > thank you for reviewing my patches. I decided to put BUILD_BUG_ON > close to places where it is important that these structs fit into a > memory page to give some context. And you make the reader figure out what type dev->buffers is unnecessarily when sizeof(struct goldfish_pipe_dev_buffers) is pretty obvious. > Regards, > Roman. cheers, Joe
Re: [PATCH v8 3/6] Uprobes: Support SDT markers having reference count (semaphore)
Hi Song, On 08/13/2018 10:42 PM, Song Liu wrote: > On Mon, Aug 13, 2018 at 6:17 AM, Oleg Nesterov wrote: >> On 08/13, Ravi Bangoria wrote: >>> But damn, process creation (exec) is trivial. We could add a new uprobe_exec() hook and avoid delayed_uprobe_install() in uprobe_mmap(). >>> >>> I'm sorry. I didn't get this. >> >> Sorry for confusion... >> >> I meant, if only exec*( could race with _register(), we could add another >> uprobe >> hook which updates all (delayed) counters before return to user-mode. >> Afaics, the really problematic case is dlopen() which can race with _register() too, right? >>> >>> dlopen() should internally use mmap() right? So what is the problem here? >>> Can >>> you please elaborate. >> >> What I tried to say is that we can't avoid >> uprobe_mmap()->delayed_uprobe_install() >> because dlopen() can race with _register() too, just like exec. >> >> Oleg. >> > > How about we do delayed_uprobe_install() per file? Say we keep a list > of delayed_uprobe > in load_elf_binary(). Then we can install delayed_uprobe after loading > all sections of the > file. I'm not sure if I totally understood the idea. But how this approach can solve dlopen() race with _register()? Rather, making delayed_uprobe_list an mm field seems simple and effective idea to me. The only overhead will be list_empty(mm->delayed_list) check. Please let me know if I misunderstood you. Thanks, Ravi
Re: [PATCH 2/2] rtc:rtc-ds1347: Use PTR_ERR_OR_ZERO to replace the open code
Hi zhong,
On Mon, Aug 13, 2018 at 07:31:25PM +0800, zhong jiang wrote:
> PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So
> just replace them rather than duplicating its implement.
>
> Signed-off-by: zhong jiang
Acked-by: Baruch Siach
Thanks,
baruch
> ---
> drivers/rtc/rtc-ds1347.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ds1347.c b/drivers/rtc/rtc-ds1347.c
> index 938512c..b97b67f 100644
> --- a/drivers/rtc/rtc-ds1347.c
> +++ b/drivers/rtc/rtc-ds1347.c
> @@ -155,10 +155,7 @@ static int ds1347_probe(struct spi_device *spi)
> rtc = devm_rtc_device_register(&spi->dev, "ds1347",
> &ds1347_rtc_ops, THIS_MODULE);
>
> - if (IS_ERR(rtc))
> - return PTR_ERR(rtc);
> -
> - return 0;
> + return PTR_ERR_OR_ZERO(rtc);
> }
>
> static struct spi_driver ds1347_driver = {
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
Re: [PATCH 2/2] f2fs: tune discard speed with storage usage rate
On 08/10, Chao Yu wrote:
> Previously, discard speed was fixed mostly, and in high usage rate
> device, we will speed up issuing discard, but it doesn't make sense
> that in a non-full filesystem, we still issue discard with slow speed.
Could you please elaborate the problem in more detail? The speed depends
on how many candidates?
Thanks,
>
> Anyway, it comes out undiscarded block makes FTL GC be lower efficient
> and causing high lifetime overhead.
>
> Let's tune discard speed as below:
>
> a. adjust default issue interval:
> originalafter
> min_interval: 50ms100ms
> mid_interval: 500ms 1000ms
> max_interval: 6ms 1ms
>
> b. if last time we stop issuing discard due to IO interruption of user,
> let's reset all {min,mid,max}_interval to default one.
>
> c. tune {min,mid,max}_interval with below calculation method:
>
> base_interval = default_interval / 10;
> total_interval = default_interval - base_interval;
> interval = base_interval + total_interval * (100 - dev_util) / 100;
>
> For example:
> min_interval (:100ms)
> dev_util (%) interval (ms)
> 0 100
> 1091
> 2082
> 3073
> ...
> 8028
> 9019
> 100 10
>
> Signed-off-by: Chao Yu
> ---
> fs/f2fs/f2fs.h| 11
> fs/f2fs/segment.c | 64 +--
> fs/f2fs/segment.h | 9 +++
> fs/f2fs/super.c | 2 +-
> 4 files changed, 67 insertions(+), 19 deletions(-)
>
> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> index 273ffdaf4891..a1dd2e1c3cb9 100644
> --- a/fs/f2fs/f2fs.h
> +++ b/fs/f2fs/f2fs.h
> @@ -185,10 +185,9 @@ enum {
>
> #define MAX_DISCARD_BLOCKS(sbi) BLKS_PER_SEC(sbi)
> #define DEF_MAX_DISCARD_REQUEST 8 /* issue 8 discards per
> round */
> -#define DEF_MIN_DISCARD_ISSUE_TIME 50 /* 50 ms, if exists */
> -#define DEF_MID_DISCARD_ISSUE_TIME 500 /* 500 ms, if device busy */
> -#define DEF_MAX_DISCARD_ISSUE_TIME 6 /* 60 s, if no candidates */
> -#define DEF_DISCARD_URGENT_UTIL 80 /* do more discard over
> 80% */
> +#define DEF_MIN_DISCARD_ISSUE_TIME 100 /* 100 ms, if exists */
> +#define DEF_MID_DISCARD_ISSUE_TIME 1000/* 1000 ms, if device busy */
> +#define DEF_MAX_DISCARD_ISSUE_TIME 1 /* 1 ms, if no candidates */
> #define DEF_CP_INTERVAL 60 /* 60 secs */
> #define DEF_IDLE_INTERVAL5 /* 5 secs */
>
> @@ -248,7 +247,8 @@ struct discard_entry {
> };
>
> /* default discard granularity of inner discard thread, unit: block count */
> -#define DEFAULT_DISCARD_GRANULARITY 1
> +#define MID_DISCARD_GRANULARITY 16
> +#define MIN_DISCARD_GRANULARITY 1
>
> /* max discard pend list number */
> #define MAX_PLIST_NUM512
> @@ -330,6 +330,7 @@ struct discard_cmd_control {
> atomic_t discard_cmd_cnt; /* # of cached cmd count */
> struct rb_root root;/* root of discard rb-tree */
> bool rbtree_check; /* config for consistence check
> */
> + bool io_interrupted;/* last state of io interrupted
> */
> };
>
> /* for the list of fsync inodes, used only during recovery */
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 8b52e8dfb12f..9564aaf1f27b 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -968,6 +968,44 @@ static void __check_sit_bitmap(struct f2fs_sb_info *sbi,
> #endif
> }
>
> +static void __adjust_discard_speed(unsigned int *interval,
> + unsigned int def_interval, int dev_util)
> +{
> + unsigned int base_interval, total_interval;
> +
> + base_interval = def_interval / 10;
> + total_interval = def_interval - base_interval;
> +
> + /*
> + * if def_interval = 100, adjusted interval should be in range of
> + * [10, 100].
> + */
> + *interval = base_interval + total_interval * (100 - dev_util) / 100;
> +}
> +
> +static void __tune_discard_policy(struct f2fs_sb_info *sbi,
> + struct discard_policy *dpolicy)
> +{
> + struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
> + int dev_util;
> +
> + if (dcc->io_interrupted) {
> + dpolicy->min_interval = DEF_MIN_DISCARD_ISSUE_TIME;
> + dpolicy->mid_interval = DEF_MID_DISCARD_ISSUE_TIME;
> + dpolicy->max_interval = DEF_MAX_DISCARD_ISSUE_TIME;
> + return;
> + }
> +
> + dev_util = dev_utilization(sbi);
> +
> + __adjust_discard_speed(&dpolicy->min_interval,
> + DEF_MIN_DISCARD_ISSUE_TIME, dev_util);
> + __adjust_discard_speed(&dpolicy->mid_interval,
> + DEF_MID_DISCARD_ISSUE_TIME, dev_util);
> + __adjust_discard_speed(&dpolicy->max_interval,
> +
Re: [PATCH 1/2] rtc:rtc-digicolor: Use PTR_ERR_OR_ZERO to replace the open code
Hi zhong,
On Mon, Aug 13, 2018 at 07:31:24PM +0800, zhong jiang wrote:
> PTR_ERR_OR_ZERO has implemented the if(IS_ERR(...)) + PTR_ERR, So
> just replace them rather than duplicating its implement.
>
> Signed-off-by: zhong jiang
Acked-by: Baruch Siach
Thanks,
baruch
> ---
> drivers/rtc/rtc-digicolor.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/rtc/rtc-digicolor.c b/drivers/rtc/rtc-digicolor.c
> index b253bf1..fd6850c 100644
> --- a/drivers/rtc/rtc-digicolor.c
> +++ b/drivers/rtc/rtc-digicolor.c
> @@ -202,10 +202,8 @@ static int __init dc_rtc_probe(struct platform_device
> *pdev)
> platform_set_drvdata(pdev, rtc);
> rtc->rtc_dev = devm_rtc_device_register(&pdev->dev, pdev->name,
> &dc_rtc_ops, THIS_MODULE);
> - if (IS_ERR(rtc->rtc_dev))
> - return PTR_ERR(rtc->rtc_dev);
>
> - return 0;
> + return PTR_ERR_OR_ZERO(rtc->rtc_dev);
> }
>
> static const struct of_device_id dc_dt_ids[] = {
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
[PATCH 3/5] fs/locks: allow a lock request to block other requests.
Currently, a lock can block pending requests, but all pending
requests are equal. If lots of pending requests are
mutually exclusive, this means they will all be woken up
and all but one will fail. This can hurt performance.
So we will allow pending requests to block other requests.
Only the first request will be woken, and it will wake the others.
This patch doesn't implement this fully, but prepares the way.
- It acknowledges that a request might be blocking other requests,
and when the request is converted to a lock, those blocked
requests are moved across.
- When a request is requeued or discarded, all blocked requests are
woken.
- When deadlock-detection looks for the lock which blocks a
given request, we follow the chain of ->fl_blocker all
the way to the top.
Signed-off-by: NeilBrown
---
fs/locks.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index de0b9276f23d..9439eebd4eb9 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -408,9 +408,19 @@ void locks_copy_lock(struct file_lock *new, struct
file_lock *fl)
fl->fl_ops->fl_copy_lock(new, fl);
}
}
-
EXPORT_SYMBOL(locks_copy_lock);
+static void locks_move_blocks(struct file_lock *new, struct file_lock *fl)
+{
+ struct file_lock *f;
+
+ spin_lock(&blocked_lock_lock);
+ list_splice_init(&fl->fl_blocked, &new->fl_blocked);
+ list_for_each_entry(f, &fl->fl_blocked, fl_block)
+ f->fl_blocker = new;
+ spin_unlock(&blocked_lock_lock);
+}
+
static inline int flock_translate_cmd(int cmd) {
if (cmd & LOCK_MAND)
return cmd & (LOCK_MAND | LOCK_RW);
@@ -683,11 +693,15 @@ static void __locks_delete_block(struct file_lock *waiter)
static void __locks_wake_up_blocks(struct file_lock *blocker)
{
+ /* Wake up all requests in blocker->fl_blocked, including
+* requests blocked by those requests.
+*/
while (!list_empty(&blocker->fl_blocked)) {
struct file_lock *waiter;
waiter = list_first_entry(&blocker->fl_blocked,
struct file_lock, fl_block);
+ list_splice_init(&waiter->fl_blocked, &blocker->fl_blocked);
__locks_delete_block(waiter);
if (waiter->fl_lmops && waiter->fl_lmops->lm_notify)
waiter->fl_lmops->lm_notify(waiter);
@@ -699,6 +713,7 @@ static void __locks_wake_up_blocks(struct file_lock
*blocker)
static void locks_delete_block(struct file_lock *waiter)
{
spin_lock(&blocked_lock_lock);
+ __locks_wake_up_blocks(waiter);
__locks_delete_block(waiter);
spin_unlock(&blocked_lock_lock);
}
@@ -714,13 +729,19 @@ static void locks_delete_block(struct file_lock *waiter)
* blocked_lock_lock in some cases when we see that the fl_blocked list is
empty.
*/
static void __locks_insert_block(struct file_lock *blocker,
- struct file_lock *waiter)
+struct file_lock *waiter)
{
BUG_ON(!list_empty(&waiter->fl_block));
waiter->fl_blocker = blocker;
list_add_tail(&waiter->fl_block, &blocker->fl_blocked);
if (IS_POSIX(blocker) && !IS_OFDLCK(blocker))
locks_insert_global_blocked(waiter);
+
+ /* The requests in waiter->fl_blocked are known to conflict with
+* waiter, but might not conflict with blocker, or the requests
+* and lock which block it. So they all need to be woken.
+*/
+ __locks_wake_up_blocks(waiter);
}
/* Must be called with flc_lock held. */
@@ -893,8 +914,11 @@ static struct file_lock *what_owner_is_waiting_for(struct
file_lock *block_fl)
struct file_lock *fl;
hash_for_each_possible(blocked_hash, fl, fl_link,
posix_owner_key(block_fl)) {
- if (posix_same_owner(fl, block_fl))
- return fl->fl_blocker;
+ if (posix_same_owner(fl, block_fl)) {
+ while (fl->fl_blocker)
+ fl = fl->fl_blocker;
+ return fl;
+ }
}
return NULL;
}
@@ -987,6 +1011,7 @@ static int flock_lock_inode(struct inode *inode, struct
file_lock *request)
if (request->fl_flags & FL_ACCESS)
goto out;
locks_copy_lock(new_fl, request);
+ locks_move_blocks(new_fl, request);
locks_insert_lock_ctx(new_fl, &ctx->flc_flock);
new_fl = NULL;
error = 0;
@@ -1179,6 +1204,7 @@ static int posix_lock_inode(struct inode *inode, struct
file_lock *request,
goto out;
}
locks_copy_lock(new_fl, request);
+ locks_move_blocks(new_fl, request);
locks_insert_lock_ctx(new_fl, &fl->fl_list);
fl = new_fl;
new_fl = NU
[PATCH 5/5] fs/locks: create a tree of dependent requests.
When we find an existing lock which conflicts with a request,
and the request wants to wait, we currently add the request
to a list. When the lock is removed, the whole list is woken.
This can cause the thundering-herd problem.
To reduce the problem, we make use of the (new) fact that
a pending request can itself have a list of blocked requests.
When we find a conflict, we look through the existing blocked requests.
If any one of them blocks the new request, the new request is attached
below that request, otherwise it is added to the list of blocked
requests, which are now known to be mutually non-conflicting.
This way, when the lock is released, only a set of non-conflicting
locks will be woken, the rest can stay asleep.
If the lock request cannot be granted and the request needs to be
requeued, all the other requests it blocks will then be woken
Reported-and-tested-by: Martin Wilck
Signed-off-by: NeilBrown
---
fs/locks.c | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index c7a372cebff1..af250afceff4 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -727,11 +727,25 @@ static void locks_delete_block(struct file_lock *waiter)
* fl_blocked list itself is protected by the blocked_lock_lock, but by
ensuring
* that the flc_lock is also held on insertions we can avoid taking the
* blocked_lock_lock in some cases when we see that the fl_blocked list is
empty.
+ *
+ * Rather than just adding to the list, we check for conflicts with any
existing
+ * waiters, and add beneath any waiter that blocks the new waiter.
+ * Thus wakeups don't happen until needed.
*/
static void __locks_insert_block(struct file_lock *blocker,
-struct file_lock *waiter)
+struct file_lock *waiter,
+bool conflict(struct file_lock *,
+ struct file_lock *))
{
+ struct file_lock *fl;
BUG_ON(!list_empty(&waiter->fl_block));
+
+new_blocker:
+ list_for_each_entry(fl, &blocker->fl_blocked, fl_block)
+ if (conflict(fl, waiter)) {
+ blocker = fl;
+ goto new_blocker;
+ }
waiter->fl_blocker = blocker;
list_add_tail(&waiter->fl_block, &blocker->fl_blocked);
if (IS_POSIX(blocker) && !IS_OFDLCK(blocker))
@@ -746,10 +760,12 @@ static void __locks_insert_block(struct file_lock
*blocker,
/* Must be called with flc_lock held. */
static void locks_insert_block(struct file_lock *blocker,
- struct file_lock *waiter)
+ struct file_lock *waiter,
+ bool conflict(struct file_lock *,
+struct file_lock *))
{
spin_lock(&blocked_lock_lock);
- __locks_insert_block(blocker, waiter);
+ __locks_insert_block(blocker, waiter, conflict);
spin_unlock(&blocked_lock_lock);
}
@@ -1008,7 +1024,7 @@ static int flock_lock_inode(struct inode *inode, struct
file_lock *request)
if (!(request->fl_flags & FL_SLEEP))
goto out;
error = FILE_LOCK_DEFERRED;
- locks_insert_block(fl, request);
+ locks_insert_block(fl, request, flock_locks_conflict);
goto out;
}
if (request->fl_flags & FL_ACCESS)
@@ -1082,7 +1098,8 @@ static int posix_lock_inode(struct inode *inode, struct
file_lock *request,
spin_lock(&blocked_lock_lock);
if (likely(!posix_locks_deadlock(request, fl))) {
error = FILE_LOCK_DEFERRED;
- __locks_insert_block(fl, request);
+ __locks_insert_block(fl, request,
+posix_locks_conflict);
}
spin_unlock(&blocked_lock_lock);
goto out;
@@ -1555,7 +1572,7 @@ int __break_lease(struct inode *inode, unsigned int mode,
unsigned int type)
break_time -= jiffies;
if (break_time == 0)
break_time++;
- locks_insert_block(fl, new_fl);
+ locks_insert_block(fl, new_fl, leases_conflict);
trace_break_lease_block(inode, new_fl);
spin_unlock(&ctx->flc_lock);
percpu_up_read_preempt_enable(&file_rwsem);
[PATCH 4/5] fs/locks: change all *_conflict() functions to return bool.
posix_locks_conflict() and flock_locks_conflict() both return int.
leases_conflict() returns bool.
This inconsistency will cause problems for the next patch if not
fixed.
So change posix_locks_conflict() and flock_locks_conflict() to return
bool.
Also change the locks_conflict() helper.
And convert some
return (foo);
to
return foo;
Signed-off-by: NeilBrown
---
fs/locks.c | 27 +++
1 file changed, 15 insertions(+), 12 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 9439eebd4eb9..c7a372cebff1 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -803,47 +803,50 @@ locks_delete_lock_ctx(struct file_lock *fl, struct
list_head *dispose)
/* Determine if lock sys_fl blocks lock caller_fl. Common functionality
* checks for shared/exclusive status of overlapping locks.
*/
-static int locks_conflict(struct file_lock *caller_fl, struct file_lock
*sys_fl)
+static bool locks_conflict(struct file_lock *caller_fl,
+ struct file_lock *sys_fl)
{
if (sys_fl->fl_type == F_WRLCK)
- return 1;
+ return true;
if (caller_fl->fl_type == F_WRLCK)
- return 1;
- return 0;
+ return true;
+ return false;
}
/* Determine if lock sys_fl blocks lock caller_fl. POSIX specific
* checking before calling the locks_conflict().
*/
-static int posix_locks_conflict(struct file_lock *caller_fl, struct file_lock
*sys_fl)
+static bool posix_locks_conflict(struct file_lock *caller_fl,
+struct file_lock *sys_fl)
{
/* POSIX locks owned by the same process do not conflict with
* each other.
*/
if (posix_same_owner(caller_fl, sys_fl))
- return (0);
+ return false;
/* Check whether they overlap */
if (!locks_overlap(caller_fl, sys_fl))
- return 0;
+ return false;
- return (locks_conflict(caller_fl, sys_fl));
+ return locks_conflict(caller_fl, sys_fl);
}
/* Determine if lock sys_fl blocks lock caller_fl. FLOCK specific
* checking before calling the locks_conflict().
*/
-static int flock_locks_conflict(struct file_lock *caller_fl, struct file_lock
*sys_fl)
+static bool flock_locks_conflict(struct file_lock *caller_fl,
+struct file_lock *sys_fl)
{
/* FLOCK locks referring to the same filp do not conflict with
* each other.
*/
if (caller_fl->fl_file == sys_fl->fl_file)
- return (0);
+ return false;
if ((caller_fl->fl_type & LOCK_MAND) || (sys_fl->fl_type & LOCK_MAND))
- return 0;
+ return false;
- return (locks_conflict(caller_fl, sys_fl));
+ return locks_conflict(caller_fl, sys_fl);
}
void
[PATCH 0/5 v2] locks: avoid thundering-herd wake-ups
V2, which added wake_non_conflicts() was more broken than V1 - as Bruce explained there is no transitivity in the blocking relation between locks. So this series takes a simpler approach. It still attached waiters between other waiters as necessary to ensure that: - a waiter is blocked by it's parent (fl->blocker) and all further ancestors, and - the list of waiters on fl_blocked are mutually non-conflicting. When a lock (the root of a tree of requests) is released, only its immediate children (fl_blocked) are woken. When any lock is woken (either because its fl_blocker was released to due to a signal or similar) it with either: - be granted - be aborted - be re-queued beneath some other lock. In the first case tree of blocked locks is moved across to the newly created lock, and the invariants still hold. In the order two cases, the tree or blocked waiters are all detached and woken. Note that this series has not received much testing yet. Original description: If you have a many-core machine, and have many threads all wanting to briefly lock a give file (udev is known to do this), you can get quite poor performance. When one thread releases a lock, it wakes up all other threads that are waiting (classic thundering-herd) - one will get the lock and the others go to sleep. When you have few cores, this is not very noticeable: by the time the 4th or 5th thread gets enough CPU time to try to claim the lock, the earlier threads have claimed it, done what was needed, and released. With 50+ cores, the contention can easily be measured. This patchset creates a tree of pending lock request in which siblings don't conflict and each lock request does conflict with its parent. When a lock is released, only requests which don't conflict with each other a woken. Testing shows that lock-acquisitions-per-second is now fairly stable even as number of contending process goes to 1000. Without this patch, locks-per-second drops off steeply after a few 10s of processes. There is a small cost to this extra complexity. At 20 processes running a particular test on 72 cores, the lock acquisitions per second drops from 1.8 million to 1.4 million with this patch. For 100 processes, this patch still provides 1.4 million while without this patch there are about 700,000. NeilBrown --- NeilBrown (5): fs/locks: rename some lists and pointers. fs/locks: split out __locks_wake_up_blocks(). fs/locks: allow a lock request to block other requests. fs/locks: change all *_conflict() functions to return bool. fs/locks: create a tree of dependent requests. fs/cifs/file.c |2 - fs/locks.c | 156 ++- include/linux/fs.h |7 +- include/trace/events/filelock.h | 16 ++-- 4 files changed, 119 insertions(+), 62 deletions(-) -- Signature
[PATCH 2/5] fs/locks: split out __locks_wake_up_blocks().
This functionality will be useful in future patches, so
split it out from locks_wake_up_blocks().
Signed-off-by: NeilBrown
---
fs/locks.c | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 322491e70e41..de0b9276f23d 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -681,6 +681,21 @@ static void __locks_delete_block(struct file_lock *waiter)
waiter->fl_blocker = NULL;
}
+static void __locks_wake_up_blocks(struct file_lock *blocker)
+{
+ while (!list_empty(&blocker->fl_blocked)) {
+ struct file_lock *waiter;
+
+ waiter = list_first_entry(&blocker->fl_blocked,
+ struct file_lock, fl_block);
+ __locks_delete_block(waiter);
+ if (waiter->fl_lmops && waiter->fl_lmops->lm_notify)
+ waiter->fl_lmops->lm_notify(waiter);
+ else
+ wake_up(&waiter->fl_wait);
+ }
+}
+
static void locks_delete_block(struct file_lock *waiter)
{
spin_lock(&blocked_lock_lock);
@@ -735,17 +750,7 @@ static void locks_wake_up_blocks(struct file_lock *blocker)
return;
spin_lock(&blocked_lock_lock);
- while (!list_empty(&blocker->fl_blocked)) {
- struct file_lock *waiter;
-
- waiter = list_first_entry(&blocker->fl_blocked,
- struct file_lock, fl_block);
- __locks_delete_block(waiter);
- if (waiter->fl_lmops && waiter->fl_lmops->lm_notify)
- waiter->fl_lmops->lm_notify(waiter);
- else
- wake_up(&waiter->fl_wait);
- }
+ __locks_wake_up_blocks(blocker);
spin_unlock(&blocked_lock_lock);
}
[PATCH 1/5] fs/locks: rename some lists and pointers.
struct file lock contains an 'fl_next' pointer which
is used to point to the lock that this request is blocked
waiting for. So rename it to fl_blocker.
The fl_blocked list_head in an active lock is the head of a list of
blocked requests. In a request it is a node in that list.
These are two distinct uses, so replace with two list_heads
with different names.
fl_blocked is the head of a list of blocked requests
fl_block is a node on that list.
The two different list_heads are never used at the same time, but that
will change in a future patch.
Note that a tracepoint is changed to report fl_blocker instead
of fl_next.
Signed-off-by: NeilBrown
---
fs/cifs/file.c |2 +-
fs/locks.c | 40 ---
include/linux/fs.h |7 +--
include/trace/events/filelock.h | 16
4 files changed, 35 insertions(+), 30 deletions(-)
diff --git a/fs/cifs/file.c b/fs/cifs/file.c
index 8d41ca7bfcf1..066ed2e4ba96 100644
--- a/fs/cifs/file.c
+++ b/fs/cifs/file.c
@@ -1092,7 +1092,7 @@ cifs_posix_lock_set(struct file *file, struct file_lock
*flock)
rc = posix_lock_file(file, flock, NULL);
up_write(&cinode->lock_sem);
if (rc == FILE_LOCK_DEFERRED) {
- rc = wait_event_interruptible(flock->fl_wait, !flock->fl_next);
+ rc = wait_event_interruptible(flock->fl_wait,
!flock->fl_blocker);
if (!rc)
goto try_again;
posix_unblock_lock(flock);
diff --git a/fs/locks.c b/fs/locks.c
index db7b6917d9c5..322491e70e41 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -194,7 +194,7 @@ static DEFINE_HASHTABLE(blocked_hash, BLOCKED_HASH_BITS);
* This lock protects the blocked_hash. Generally, if you're accessing it, you
* want to be holding this lock.
*
- * In addition, it also protects the fl->fl_block list, and the fl->fl_next
+ * In addition, it also protects the fl->fl_blocked list, and the
fl->fl_blocker
* pointer for file_lock structures that are acting as lock requests (in
* contrast to those that are acting as records of acquired locks).
*
@@ -203,7 +203,7 @@ static DEFINE_HASHTABLE(blocked_hash, BLOCKED_HASH_BITS);
* protected by this lock, we can skip acquiring it iff we already hold the
* flc_lock.
*
- * In particular, adding an entry to the fl_block list requires that you hold
+ * In particular, adding an entry to the fl_blocked list requires that you hold
* both the flc_lock and the blocked_lock_lock (acquired in that order).
* Deleting an entry from the list however only requires the file_lock_lock.
*/
@@ -302,6 +302,7 @@ static void locks_init_lock_heads(struct file_lock *fl)
{
INIT_HLIST_NODE(&fl->fl_link);
INIT_LIST_HEAD(&fl->fl_list);
+ INIT_LIST_HEAD(&fl->fl_blocked);
INIT_LIST_HEAD(&fl->fl_block);
init_waitqueue_head(&fl->fl_wait);
}
@@ -341,6 +342,7 @@ void locks_free_lock(struct file_lock *fl)
{
BUG_ON(waitqueue_active(&fl->fl_wait));
BUG_ON(!list_empty(&fl->fl_list));
+ BUG_ON(!list_empty(&fl->fl_blocked));
BUG_ON(!list_empty(&fl->fl_block));
BUG_ON(!hlist_unhashed(&fl->fl_link));
@@ -676,7 +678,7 @@ static void __locks_delete_block(struct file_lock *waiter)
{
locks_delete_global_blocked(waiter);
list_del_init(&waiter->fl_block);
- waiter->fl_next = NULL;
+ waiter->fl_blocker = NULL;
}
static void locks_delete_block(struct file_lock *waiter)
@@ -692,16 +694,16 @@ static void locks_delete_block(struct file_lock *waiter)
* it seems like the reasonable thing to do.
*
* Must be called with both the flc_lock and blocked_lock_lock held. The
- * fl_block list itself is protected by the blocked_lock_lock, but by ensuring
+ * fl_blocked list itself is protected by the blocked_lock_lock, but by
ensuring
* that the flc_lock is also held on insertions we can avoid taking the
- * blocked_lock_lock in some cases when we see that the fl_block list is empty.
+ * blocked_lock_lock in some cases when we see that the fl_blocked list is
empty.
*/
static void __locks_insert_block(struct file_lock *blocker,
struct file_lock *waiter)
{
BUG_ON(!list_empty(&waiter->fl_block));
- waiter->fl_next = blocker;
- list_add_tail(&waiter->fl_block, &blocker->fl_block);
+ waiter->fl_blocker = blocker;
+ list_add_tail(&waiter->fl_block, &blocker->fl_blocked);
if (IS_POSIX(blocker) && !IS_OFDLCK(blocker))
locks_insert_global_blocked(waiter);
}
@@ -725,18 +727,18 @@ static void locks_wake_up_blocks(struct file_lock
*blocker)
/*
* Avoid taking global lock if list is empty. This is safe since new
* blocked requests are only added to the list under the flc_lock, and
-* the flc_lock is always held here. Note that removal from the fl_block
+* the flc_lock is always held
Re: [PATCH 6/9] platform: goldfish: pipe: Fail compilation if structs are too large
Hi,
thank you for reviewing my patches. I decided to put BUILD_BUG_ON
close to places where it is important that these structs fit into a
memory page to give some context.
Regards,
Roman.
On Mon, Aug 13, 2018 at 6:48 PM Joe Perches wrote:
>
> On Mon, 2018-08-13 at 16:38 -0700, r...@google.com wrote:
> > From: Roman Kiryanov
> >
> > Since the driver provides no workaround prevent in cases if structs do
> > no fit into a memory page, it is better to fail complation to find about
> > the issue earlt instead of returning errors at runtime.
>
> Minor earlt/early typo
>
> > diff --git a/drivers/platform/goldfish/goldfish_pipe.c
> > b/drivers/platform/goldfish/goldfish_pipe.c
> []
> > @@ -797,9 +798,7 @@ static int goldfish_pipe_device_init(struct
> > platform_device *pdev)
> >* needs to be contained in a single physical page. The easiest choice
> >* is to just allocate a page and place the buffers in it.
> >*/
> > - if (WARN_ON(sizeof(*dev->buffers) > PAGE_SIZE))
> > - return -ENOMEM;
> > -
> > + BUILD_BUG_ON(sizeof(*dev->buffers) > PAGE_SIZE);
> > page = (char *)__get_free_page(GFP_KERNEL);
> > if (!page) {
> > kfree(dev->pipes);
> > @@ -842,8 +841,7 @@ static int goldfish_pipe_probe(struct platform_device
> > *pdev)
> > struct resource *r;
> > struct goldfish_pipe_dev *dev = pipe_dev;
> >
> > - if (WARN_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE))
> > - return -ENOMEM;
> > + BUILD_BUG_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE);
> >
> > /* not thread safe, but this should not happen */
> > WARN_ON(dev->base != NULL);
>
> Why separate these BUILD_BUG_ONs into 2 different functions?
>
> Why not just
> BUILD_BUG_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE);
> BUILD_BUG_ON(sizeof(struct goldfish_pipe_dev_buffers) > PAGE_SIZE);
>
Re: [PATCH 8/9] platform: goldfish: pipe: Replace pr_ with dev_ for logging
Hi Roman,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v4.18 next-20180813]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/rkir-google-com/platform-goldfish-pipe-Fix-comments-to-fit-80-columns/20180814-104717
config: i386-randconfig-x008-201832 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/platform//goldfish/goldfish_pipe.c: In function
'goldfish_pipe_read_write':
>> drivers/platform//goldfish/goldfish_pipe.c:405:22: error: 'struct
>> goldfish_pipe_dev' has no member named 'pdev_dev'
pdev_dev = pipe->dev->pdev_dev;
^~
vim +405 drivers/platform//goldfish/goldfish_pipe.c
379
380 static ssize_t goldfish_pipe_read_write(struct file *filp,
381 char __user *buffer, size_t bufflen, int is_write)
382 {
383 struct goldfish_pipe *pipe = filp->private_data;
384 int count = 0, ret = -EINVAL;
385 unsigned long address, address_end, last_page;
386 unsigned int last_page_size;
387 struct device *pdev_dev;
388
389 /* If the emulator already closed the pipe, no need to go
further */
390 if (unlikely(test_bit(BIT_CLOSED_ON_HOST, &pipe->flags)))
391 return -EIO;
392 /* Null reads or writes succeeds */
393 if (unlikely(bufflen == 0))
394 return 0;
395 /* Check the buffer range for access */
396 if (unlikely(!access_ok(is_write ? VERIFY_WRITE : VERIFY_READ,
397 buffer, bufflen)))
398 return -EFAULT;
399
400 address = (unsigned long)buffer;
401 address_end = address + bufflen;
402 last_page = (address_end - 1) & PAGE_MASK;
403 last_page_size = ((address_end - 1) & ~PAGE_MASK) + 1;
404
> 405 pdev_dev = pipe->dev->pdev_dev;
406
407 while (address < address_end) {
408 s32 consumed_size;
409 int status;
410
411 ret = transfer_max_buffers(pipe, address, address_end,
is_write,
412 last_page, last_page_size,
&consumed_size,
413 &status);
414 if (ret < 0)
415 break;
416
417 if (consumed_size > 0) {
418 /* No matter what's the status, we've
transferred
419 * something.
420 */
421 count += consumed_size;
422 address += consumed_size;
423 }
424 if (status > 0)
425 continue;
426 if (status == 0) {
427 /* EOF */
428 ret = 0;
429 break;
430 }
431 if (count > 0) {
432 /*
433 * An error occurred, but we already transferred
434 * something on one of the previous iterations.
435 * Just return what we already copied and log
this
436 * err.
437 */
438 if (status != PIPE_ERROR_AGAIN)
439 dev_err_ratelimited(pdev_dev,
440 "goldfish_pipe: backend error
%d on %s\n",
441 status, is_write ? "write" :
"read");
442 break;
443 }
444
445 /*
446 * If the error is not PIPE_ERROR_AGAIN, or if we are in
447 * non-blocking mode, just return the error code.
448 */
449 if (status != PIPE_ERROR_AGAIN ||
450 (filp->f_flags & O_NONBLOCK) != 0) {
451 ret = goldfish_pipe_error_convert(status);
452 break;
453 }
454
455 status = wait_for_host_signal(pipe, is_write);
456 if (status < 0)
457 return status;
458 }
459
460 if (count > 0)
461 return count;
462
Re: [1/2] dt-bindings: phy: Add stingray usb phy documentation
Hi JC, On Tue, Aug 14, 2018 at 7:24 AM, Jayachandran C wrote: > Hi Srinath, Ray, > > On Fri, Jul 07, 2017 at 06:37:04PM +0530, Srinath Mannam wrote: >> Add DT binding document for stingray usb phy driver. >> >> Signed-off-by: Srinath Mannam >> Reviewed-by: Ray Jui >> Acked-by: Rob Herring > > The Broadcom Vulcan chip (now Cavium ThunderX2) uses the same USB PHY > from what I understand. Our hardware team reports that there are some > failures seen without the a custom PHY driver. > > Do you require this PHY driver on regular operation on Stingray? Or is > this for some specific functionality? I am asking since the issue > reported here is on switching between a USB 3.0 and USB 2.0 devices. We need it for regular operation in stingray. > > Any plans on submitting this driver again? I will submit it ASAP. Regards, Srinath. > > Thanks, > JC
Re: [PATCH 1/2] kconfig: remove unused sym_get_env_prop() function
2018-08-14 2:20 GMT+09:00 Sam Ravnborg :
> On Tue, Aug 14, 2018 at 01:48:38AM +0900, Masahiro Yamada wrote:
>> This function is unused since commit 104daea149c4 ("kconfig: reference
>> environment variables directly and remove 'option env='").
>>
>> Signed-off-by: Masahiro Yamada
>
> Both patches are obviously correct.
> Feel free to add:
> Acked-by: Sam Ravnborg
>
> and apply to kbuild so we can get them in this cycle.
>
> Sam
Applied to linux-kbuild/kconfig with Sam's Ack.
--
Best Regards
Masahiro Yamada
Re: [PATCH] kconfig: fix the rule of mainmenu_stmt symbol
2018-08-09 15:47 GMT+09:00 Masahiro Yamada :
> The rule of mainmenu_stmt does not have debug print of zconf_lineno(),
> but if it had, it would print a wrong line number for the same reason
> as commit b2d00d7c61c8 ("kconfig: fix line numbers for if-entries in
> menu tree").
>
> The mainmenu_stmt does not need to eat following empty lines because
> they are reduced to common_stmt.
>
> Signed-off-by: Masahiro Yamada
> ---
Applied to linux-kbuild/kconfig.
> scripts/kconfig/zconf.y | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
> index 4b68272..95a4fd3 100644
> --- a/scripts/kconfig/zconf.y
> +++ b/scripts/kconfig/zconf.y
> @@ -31,7 +31,7 @@ struct symbol *symbol_hash[SYMBOL_HASHSIZE];
> static struct menu *current_menu, *current_entry;
>
> %}
> -%expect 31
> +%expect 30
>
> %union
> {
> @@ -117,7 +117,7 @@ start: mainmenu_stmt stmt_list | stmt_list;
>
> /* mainmenu entry */
>
> -mainmenu_stmt: T_MAINMENU prompt nl
> +mainmenu_stmt: T_MAINMENU prompt T_EOL
> {
> menu_add_prompt(P_MENU, $2, NULL);
> };
> --
> 2.7.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Masahiro Yamada
Re: linux-next: Signed-off-by missing for commit in the kbuild tree
Stephen,
2018-08-14 6:33 GMT+09:00 Stephen Rothwell :
> Hi Masahiro,
>
> Commit
>
> bd714f5f14e0 ("Coccinelle: doubletest: reduce side effect false positives")
>
> is missing a Signed-off-by from its committer.
Thanks for catching this.
I will fix it.
> --
> Cheers,
> Stephen Rothwell
--
Best Regards
Masahiro Yamada
Re: [PATCH] Support mksh as /bin/sh.
2018-08-14 7:32 GMT+09:00 Kees Cook : > On Mon, Aug 13, 2018 at 3:14 AM, wrote: >> From: Arkadiusz Miśkiewicz >> >> mksh needs space between ! and ( to work properly. Otherwise this >> happens: >> >> + make oldconfig >> scripts/kconfig/conf --oldconfig Kconfig >> ./scripts/clang-version.sh[18]: COPYING: not found >> printf: ‘__clang_major__’: expected a numeric value >> printf: ‘__clang_minor__’: expected a numeric value >> printf: ‘__clang_patchlevel__’: expected a numeric value >> init/Kconfig:24:warning: 'CLANG_VERSION': number is invalid >> >> Signed-off-by: Arkadiusz Miśkiewicz > > Reviewed-by: Kees Cook > > -Kees > I could not find this patch in ML. Arkadiusz, Please resend this patch to linux-kbu...@vger.kernel.org >> --- >> scripts/clang-version.sh | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh >> index dbf0a31eb111..e65fbc3079d4 100755 >> --- a/scripts/clang-version.sh >> +++ b/scripts/clang-version.sh >> @@ -12,7 +12,7 @@ >> >> compiler="$*" >> >> -if !( $compiler --version | grep -q clang) ; then >> +if ! ( $compiler --version | grep -q clang) ; then >> echo 0 >> exit 1 >> fi >> -- >> 2.18.0 >> > > > > -- > Kees Cook > Pixel Security -- Best Regards Masahiro Yamada
Re: [PATCH v2 2/4] dt-bindings: soc: amlogic: add meson-canvas documentation
2018-08-13 21:07 GMT+02:00 Rob Herring :
> On Wed, Aug 08, 2018 at 12:00:09AM +0200, Maxime Jourdan wrote:
>> DT bindings doc for amlogic,meson-canvas
>>
>> Signed-off-by: Maxime Jourdan
>> ---
>> .../soc/amlogic/amlogic,meson-canvas.txt | 36 +++
>> 1 file changed, 36 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-canvas.txt
>>
>> diff --git
>> a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-canvas.txt
>> b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-canvas.txt
>> new file mode 100644
>> index ..5f0351717bee
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-canvas.txt
>> @@ -0,0 +1,36 @@
>> +Amlogic Canvas
>> +
>> +
>> +A canvas is a collection of metadata that describes a pixel buffer.
>> +Those metadata include: width, height, phyaddr, wrapping, block mode
>> +and endianness.
>> +
>> +Many IPs within Amlogic SoCs rely on canvas indexes to read/write pixel data
>> +rather than use the phy addresses directly. For instance, this is the case
>> for
>> +the video decoders and the display.
>> +
>> +Amlogic SoCs have 256 canvas.
>> +
>> +Device Tree Bindings:
>> +-
>> +
>> +Canvas Provider
>> +--
>> +
>> +Required properties:
>> +- compatible: "amlogic,canvas"
>> +
>> +Parent node should have the following properties :
>> +- compatible: "amlogic,gx-dmc-sysctrl", "syscon", "simple-mfd"
>
> Is this documented somewhere? One child function is not a reason for an
> MFD and child nodes. And child nodes like this with no resources are
> unnecessary.
>
Hi Rob, this was done to follow the same path as other buses on the
platform that have sysctrls in order to provide regmaps to the
devices.
I can see how it's not really necessary here though, would it be okay
with you if I turned "canvas" into a simple bus subnode, using __iomem
in the device ?
>> +- reg: base address and size of the DMC system control register space.
>> +
>> +Example:
>> +
>> +sysctrl_DMC: system-controller@0 {
>> + compatible = "amlogic,gx-dmc-sysctrl", "syscon", "simple-mfd";
>> + reg = <0x0 0x0 0x0 0x1000>;
>> +
>> + canvas: canvas-provider@0 {
>> + compatible = "amlogic,canvas";
>> + };
>> +};
>> --
>> 2.18.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gcc-plugins: require GCC
2018-08-14 6:29 GMT+09:00 Stefan Agner : > On 13.08.2018 22:18, Kees Cook wrote: >> On Mon, Aug 13, 2018 at 1:10 PM, Kees Cook wrote: >>> On Mon, Aug 13, 2018 at 12:38 AM, Masahiro Yamada >>> wrote: 2018-08-11 18:48 GMT+09:00 Stefan Agner : > Unsurprisingly GCC plugins require GCC as a compiler. This avoids > GCC plugins being selectable when using clang. > > Signed-off-by: Stefan Agner > --- > arch/Kconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/Kconfig b/arch/Kconfig > index 1aa59063f1fd..8c693a837ed7 100644 > --- a/arch/Kconfig > +++ b/arch/Kconfig > @@ -422,7 +422,7 @@ config HAVE_GCC_PLUGINS > > menuconfig GCC_PLUGINS > bool "GCC plugins" > - depends on HAVE_GCC_PLUGINS > + depends on HAVE_GCC_PLUGINS && CC_IS_GCC > depends on PLUGIN_HOSTCC != "" > help > GCC plugins are loadable modules that provide extra features to > the > -- > 2.18.0 > I guess the more correct way is to fix scripts/gcc-plugin.sh This shell script should exit 0 only when GCC plugin is supported. >>> >>> I'm of two minds: we already have the gcc test in Kconfig so we might >>> want to avoid redundant checks, but maybe the script should be a >>> "complete" test. I guess the latter. I will send a patch. >> >> Actually, how about we do the test in Kconfig, but ahead of the >> script? That will reduce redundancy: >> >> diff --git a/arch/Kconfig b/arch/Kconfig >> index 1aa59063f1fd..18f518624e41 100644 >> --- a/arch/Kconfig >> +++ b/arch/Kconfig >> @@ -409,7 +409,7 @@ preferred-plugin-hostcc := $(if-success,[ >> $(gcc-version) -ge 40800 ],$(HOSTCXX), >> >> config PLUGIN_HOSTCC >> string >> - default "$(shell,$(srctree)/scripts/gcc-plugin.sh >> "$(preferred-plugin-hostcc)" "$(HOSTCXX)" "$(CC)")" >> + default "$(shell,$(srctree)/scripts/gcc-plugin.sh >> "$(preferred-plugin-hostcc)" "$(HOSTCXX)" "$(CC)")" if CC_IS_GCC >> help >> Host compiler used to build GCC plugins. This can be $(HOSTCXX), >> $(HOSTCC), or a null string if GCC plugin is unsupported. > > I like this better. A script which is called gcc-plugin.sh should only > be called if gcc is used... > This does not work like that. $(shell,$(srctree)/scripts/gcc-plugin.sh "$(preferred-plugin-hostcc)" "$(HOSTCXX)" "$(CC)") is expanded in the parse stage regardless of CC_IS_GCC. If nobody comes up with a better way, I am fine with this. Reviewed-by: Masahiro Yamada > -- > Stefan > >> >> >> -Kees -- Best Regards Masahiro Yamada
Re: [PATCH] md/bcache: Remove NULL check.
On Mon, Aug 13, 2018 at 06:00:11PM +0800, Coly Li wrote:
> On 2018/8/13 5:38 PM, Sean Fu wrote:
> > Remove unnessesary NULL check before kmem_cache_destroy() in
> > drivers/md/bcache/request.c
> >
> > Signed-off-by: Sean Fu
>
> Hi Sean,
>
> A same change is posted in my previous checkpatch fixes series. You may
> find it from,
> https://git.kernel.org/pub/scm/linux/kernel/git/colyli/linux-bcache.git/?h=for-next
>
> The identical patch is,
> https://git.kernel.org/pub/scm/linux/kernel/git/colyli/linux-bcache.git/commit/?h=for-next&id=26b39d0732955ecb839d0afe8d6211d70f213384
>
Thank you for your reply.
Sean Fu
> Thanks.
>
> Coly Li
>
> > ---
> > drivers/md/bcache/request.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/md/bcache/request.c b/drivers/md/bcache/request.c
> > index ae67f5f..0ddee35 100644
> > --- a/drivers/md/bcache/request.c
> > +++ b/drivers/md/bcache/request.c
> > @@ -1306,8 +1306,7 @@ void bch_flash_dev_request_init(struct bcache_device
> > *d)
> >
> > void bch_request_exit(void)
> > {
> > - if (bch_search_cache)
> > - kmem_cache_destroy(bch_search_cache);
> > + kmem_cache_destroy(bch_search_cache);
> > }
> >
> > int __init bch_request_init(void)
> >
>
[PATCH] arm/mach-at91/pm: Do not double put the device node
Device node iterators put the previous value of the index variable,
so an explicit put causes a double put.
I detect the issue with the help of Coccinelle.
Signed-off-by: zhong jiang
---
arch/arm/mach-at91/pm.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/arm/mach-at91/pm.c b/arch/arm/mach-at91/pm.c
index 32fae4d..a5ec35f 100644
--- a/arch/arm/mach-at91/pm.c
+++ b/arch/arm/mach-at91/pm.c
@@ -143,15 +143,12 @@ static int at91_pm_config_ws(unsigned int pm_mode, bool
set)
/* Check if enabled on SHDWC. */
if (wsi->shdwc_mr_bit && !(val & wsi->shdwc_mr_bit))
- goto put_node;
+ continue;
mode |= wsi->pmc_fsmr_bit;
if (wsi->set_polarity)
polarity |= wsi->pmc_fsmr_bit;
}
-
-put_node:
- of_node_put(np);
}
if (mode) {
--
1.7.12.4
Re: [PATCH 1/3] arm64: implement ftrace with regs
On Mon, 13 Aug 2018 11:54:06 +0100 Julien Thierry wrote: > > --- a/arch/arm64/Makefile > > +++ b/arch/arm64/Makefile > > @@ -78,6 +78,15 @@ ifeq ($(CONFIG_ARM64_MODULE_PLTS),y) > > KBUILD_LDFLAGS_MODULE += -T $(srctree)/arch/arm64/kernel/module.lds > > endif > > > > +ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS > > + CC_FLAGS_FTRACE := -fpatchable-function-entry=2 > > + KBUILD_CPPFLAGS += -DCC_USING_PATCHABLE_FUNCTION_ENTRY > > + ifeq ($(call cc-option,-fpatchable-function-entry=2),) > > +$(warning Cannot use CONFIG_DYNAMIC_FTRACE_WITH_REGS: \ > > + -fpatchable-function-entry not supported by compiler) > > Shouldn't this be an error? The option -fpatchable-function-entry has > been added to the CC_FLAGS_FTRACE, so any call to the compiler is gonna > break anyway. Or am I missing something? I'm guessing this adds a more informative message on that error. One will know why -fpatchable-function-entry was added to the CFLAGS. I'm for more informative error messages being a victim of poor error messages causing me to dig deep into the guts of the build infrastructure to figure out simple issues. -- Steve
Re: [1/2] dt-bindings: phy: Add stingray usb phy documentation
Hi Srinath, Ray, On Fri, Jul 07, 2017 at 06:37:04PM +0530, Srinath Mannam wrote: > Add DT binding document for stingray usb phy driver. > > Signed-off-by: Srinath Mannam > Reviewed-by: Ray Jui > Acked-by: Rob Herring The Broadcom Vulcan chip (now Cavium ThunderX2) uses the same USB PHY from what I understand. Our hardware team reports that there are some failures seen without the a custom PHY driver. Do you require this PHY driver on regular operation on Stingray? Or is this for some specific functionality? I am asking since the issue reported here is on switching between a USB 3.0 and USB 2.0 devices. Any plans on submitting this driver again? Thanks, JC
Re: [PATCH 6/9] platform: goldfish: pipe: Fail compilation if structs are too large
On Mon, 2018-08-13 at 16:38 -0700, r...@google.com wrote:
> From: Roman Kiryanov
>
> Since the driver provides no workaround prevent in cases if structs do
> no fit into a memory page, it is better to fail complation to find about
> the issue earlt instead of returning errors at runtime.
Minor earlt/early typo
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c
> b/drivers/platform/goldfish/goldfish_pipe.c
[]
> @@ -797,9 +798,7 @@ static int goldfish_pipe_device_init(struct
> platform_device *pdev)
>* needs to be contained in a single physical page. The easiest choice
>* is to just allocate a page and place the buffers in it.
>*/
> - if (WARN_ON(sizeof(*dev->buffers) > PAGE_SIZE))
> - return -ENOMEM;
> -
> + BUILD_BUG_ON(sizeof(*dev->buffers) > PAGE_SIZE);
> page = (char *)__get_free_page(GFP_KERNEL);
> if (!page) {
> kfree(dev->pipes);
> @@ -842,8 +841,7 @@ static int goldfish_pipe_probe(struct platform_device
> *pdev)
> struct resource *r;
> struct goldfish_pipe_dev *dev = pipe_dev;
>
> - if (WARN_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE))
> - return -ENOMEM;
> + BUILD_BUG_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE);
>
> /* not thread safe, but this should not happen */
> WARN_ON(dev->base != NULL);
Why separate these BUILD_BUG_ONs into 2 different functions?
Why not just
BUILD_BUG_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE);
BUILD_BUG_ON(sizeof(struct goldfish_pipe_dev_buffers) > PAGE_SIZE);
Re: [PATCH 1/2] perf tools: Make check-headers.sh check based on kernel dir
Jiri Olsa writes:
> diff --git a/tools/perf/check-headers.sh b/tools/perf/check-headers.sh
> index ea48aa6f8d19..9d466e853aec 100755
> --- a/tools/perf/check-headers.sh
> +++ b/tools/perf/check-headers.sh
> @@ -88,6 +88,8 @@ check () {
> # differences.
> test -d ../../include || exit 0
>
> +pushd ../.. > /dev/null
> +
> # simple diff check
> for i in $HEADERS; do
>check $i -B
This breaks the build when sh is not bash:
./check-headers.sh: 91: ./check-headers.sh: pushd: not found
./check-headers.sh: 107: ./check-headers.sh: popd: not found
Makefile.perf:205: recipe for target 'sub-make' failed
cheers
Re: [PATCH 1/9] platform: goldfish: pipe: Fix comments to fit 80 columns
On Mon, 2018-08-13 at 16:38 -0700, r...@google.com wrote:
> From: Roman Kiryanov
>
> Some comment lines are longer than 80 symbols.
[]
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c
> b/drivers/platform/goldfish/goldfish_pipe.c
[]
> @@ -84,7 +84,10 @@ enum PipePollFlags {
> PIPE_POLL_HUP = 1 << 2
> };
>
> -/* Possible status values used to signal errors - see
> goldfish_pipe_error_convert */
> +/*
> + * Possible status values used to signal errors - see
> + * goldfish_pipe_error_convert
If this is to be wrapped at all, and this really doesn't
need to be wrapped, it would probably be more sensible as:
/*
* Possible status values used to signal errors
* see: goldfish_pipe_error_convert
*/
Re: [PATCH 8/9] platform: goldfish: pipe: Replace pr_ with dev_ for logging
On Mon, 2018-08-13 at 16:38 -0700, r...@google.com wrote:
> dev_ is preferred if struct device is available.
[]
> diff --git a/drivers/platform/goldfish/goldfish_pipe.c
> b/drivers/platform/goldfish/goldfish_pipe.c
[]
> @@ -384,6 +384,7 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
> int count = 0, ret = -EINVAL;
> unsigned long address, address_end, last_page;
> unsigned int last_page_size;
> + struct device *pdev_dev;
>
> /* If the emulator already closed the pipe, no need to go further */
> if (unlikely(test_bit(BIT_CLOSED_ON_HOST, &pipe->flags)))
> @@ -401,6 +402,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
> last_page = (address_end - 1) & PAGE_MASK;
> last_page_size = ((address_end - 1) & ~PAGE_MASK) + 1;
>
> + pdev_dev = pipe->dev->pdev_dev;
> +
> while (address < address_end) {
> s32 consumed_size;
> int status;
> @@ -433,7 +436,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
>* err.
>*/
> if (status != PIPE_ERROR_AGAIN)
> - pr_info_ratelimited("goldfish_pipe: backend
> error %d on %s\n",
> + dev_err_ratelimited(pdev_dev,
> + "goldfish_pipe: backend error %d on
> %s\n",
> status, is_write ? "write" : "read");
> break;
> }
Wouldn't it be simpler to use pipe->dev->pdev_dev here instead
of creating and assigning a probably unused use-once pointer?
What does the output look like now?
Is the "pipe->dev->pdev_dev->name" then "goldfish_pipe: " output
useful?
[PATCH] get_maintainer: Allow option --mpath to read all files in
There is an external use case for multiple private MAINTAINER
style files in a separate directory. Allow it.
--mpath has a default of "./MAINTAINERS".
The value entered can be either a file or a directory.
The behaviors are now:
--mpath Read only the specific file as file
--mpath Read all files in as files
--mpath --find-maintainer-files
Recurse through and read all files named
MAINTAINERS
Signed-off-by: Joe Perches
---
scripts/get_maintainer.pl | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 0ebdefe74d5b..c1c088ef1420 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -396,7 +396,12 @@ sub read_all_maintainer_files {
if (-d $path) {
$path .= '/' if ($path !~ m@/$@);
- if ($path eq "${lk_path}MAINTAINERS/") {
+ if ($find_maintainer_files) {
+ find( { wanted => \&find_is_maintainer_file,
+ preprocess => \&find_ignore_git,
+ no_chdir => 1,
+ }, "$path");
+ } else {
opendir(DIR, "$path") or die $!;
my @files = readdir(DIR);
closedir(DIR);
@@ -404,12 +409,6 @@ sub read_all_maintainer_files {
push(@mfiles, "$path$file") if ($file !~ /^\./);
}
}
- if ($find_maintainer_files) {
- find( { wanted => \&find_is_maintainer_file,
- preprocess => \&find_ignore_git,
- no_chdir => 1,
- }, "$path");
- }
} elsif (-f "$path") {
push(@mfiles, "$path");
} else {
Re: [PATCH] zsmalloc: fix linking bug in init_zspage
Hi Minchan, On (08/14/18 09:24), Minchan Kim wrote: > > Any thoughts? > > If we want a refactoring, I'm not against but description said it tiggered > BUG_ON on zs_map_object rarely. That means it should be stable material > and need more description to understand. Please be more specific with > some example. I don't have any BUG_ON on hands. Would be great if zhouxianrong could post some backtraces or more info/explanation. > The reason I'm hesitating is zsmalloc moves ZS_FULL group > when the zspage->inuse is equal to class->objs_per_zspage so I thought > it shouldn't allocate last partial object. Maybe, allocating last partial object does look a bit hacky - it's not a valid object anyway, but I'm not suggesting that we need to change it. Let's hear from zhouxianrong. -ss
Re: [PATCH] fsi: ast: select GENERIC_ALLOCATOR
On Tue, 2018-08-14 at 00:37 +0200, Arnd Bergmann wrote:
> In randconfig builds without CONFIG_GENERIC_ALLOCATOR, this driver
> fails to link:
>
> ERROR: "gen_pool_alloc_algo" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
> ERROR: "gen_pool_fixed_alloc" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
> ERROR: "of_gen_pool_get" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
> ERROR: "gen_pool_free" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
>
> Select the dependency as all other users do.
>
> Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed
> ColdFire")
> Signed-off-by: Arnd Bergmann
> ---
Thanks, I'll pick it up and send to Greg with a slightly different
subject
Cheers,
Ben.
> drivers/fsi/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
> index af3a20dd5aa4..99c99a5d57fe 100644
> --- a/drivers/fsi/Kconfig
> +++ b/drivers/fsi/Kconfig
> @@ -46,6 +46,7 @@ config FSI_MASTER_AST_CF
> tristate "FSI master based on Aspeed ColdFire coprocessor"
> depends on GPIOLIB
> depends on GPIO_ASPEED
> + select GENERIC_ALLOCATOR
> ---help---
> This option enables a FSI master using the AST2400 and AST2500 GPIO
> lines driven by the internal ColdFire coprocessor. This requires
[PATCH v2] mm: migration: fix migration of huge PMD shared pages
The page migration code employs try_to_unmap() to try and unmap the
source page. This is accomplished by using rmap_walk to find all
vmas where the page is mapped. This search stops when page mapcount
is zero. For shared PMD huge pages, the page map count is always 1
no matter the number of mappings. Shared mappings are tracked via
the reference count of the PMD page. Therefore, try_to_unmap stops
prematurely and does not completely unmap all mappings of the source
page.
This problem can result is data corruption as writes to the original
source page can happen after contents of the page are copied to the
target page. Hence, data is lost.
This problem was originally seen as DB corruption of shared global
areas after a huge page was soft offlined due to ECC memory errors.
DB developers noticed they could reproduce the issue by (hotplug)
offlining memory used to back huge pages. A simple testcase can
reproduce the problem by creating a shared PMD mapping (note that
this must be at least PUD_SIZE in size and PUD_SIZE aligned (1GB on
x86)), and using migrate_pages() to migrate process pages between
nodes while continually writing to the huge pages being migrated.
To fix, have the try_to_unmap_one routine check for huge PMD sharing
by calling huge_pmd_unshare for hugetlbfs huge pages. If it is a
shared mapping it will be 'unshared' which removes the page table
entry and drops the reference on the PMD page. After this, flush
caches and TLB.
Fixes: 39dde65c9940 ("shared page table for hugetlb page")
Signed-off-by: Mike Kravetz
---
v2: Fixed build issue for !CONFIG_HUGETLB_PAGE and typos in comment
include/linux/hugetlb.h | 6 ++
mm/rmap.c | 21 +
2 files changed, 27 insertions(+)
diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 36fa6a2a82e3..7524663028ec 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -170,6 +170,12 @@ static inline unsigned long hugetlb_total_pages(void)
return 0;
}
+static inline int huge_pmd_unshare(struct mm_struct *mm, unsigned long *addr,
+ pte_t *ptep)
+{
+ return 0;
+}
+
#define follow_hugetlb_page(m,v,p,vs,a,b,i,w,n)({ BUG(); 0; })
#define follow_huge_addr(mm, addr, write) ERR_PTR(-EINVAL)
#define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
diff --git a/mm/rmap.c b/mm/rmap.c
index 09a799c9aebd..cf2340adad10 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1409,6 +1409,27 @@ static bool try_to_unmap_one(struct page *page, struct
vm_area_struct *vma,
subpage = page - page_to_pfn(page) + pte_pfn(*pvmw.pte);
address = pvmw.address;
+ /*
+* PMDs for hugetlbfs pages could be shared. In this case,
+* pages with shared PMDs will have a mapcount of 1 no matter
+* how many times they are actually mapped. Map counting for
+* PMD sharing is mostly done via the reference count on the
+* PMD page itself. If the page we are trying to unmap is a
+* hugetlbfs page, attempt to 'unshare' at the PMD level.
+* huge_pmd_unshare clears the PUD and adjusts reference
+* counting on the PMD page which effectively unmaps the page.
+* Take care of flushing cache and TLB for page in this
+* specific mapping here.
+*/
+ if (PageHuge(page) &&
+ huge_pmd_unshare(mm, &address, pvmw.pte)) {
+ unsigned long end_add = address + vma_mmu_pagesize(vma);
+
+ flush_cache_range(vma, address, end_add);
+ flush_tlb_range(vma, address, end_add);
+ mmu_notifier_invalidate_range(mm, address, end_add);
+ continue;
+ }
if (IS_ENABLED(CONFIG_MIGRATION) &&
(flags & TTU_MIGRATION) &&
--
2.17.1
[PATCH] android: binder: no outgoing transaction when thread todo has transaction
When a process dies, failed reply is sent to the sender of any transaction
queued on a dead thread's todo list. The sender asserts that the
received failed reply corresponds to the head of the transaction stack.
This assert can fail if the dead thread is allowed to send outgoing
transactions when there is already a transaction on its todo list,
because this new transaction can end up on the transaction stack of the
original sender. The following steps illustrate how this assertion can
fail.
1. Thread1 sends txn19 to Thread2
(T1->transaction_stack=txn19, T2->todo+=txn19)
2. Without processing todo list, Thread2 sends txn20 to Thread1
(T1->todo+=txn20, T2->transaction_stack=txn20)
3. T1 processes txn20 on its todo list
(T1->transaction_stack=txn20->txn19, T1->todo=)
4. T2 dies, T2->todo cleanup attempts to send failed reply for txn19, but
T1->transaction_stack points to txn20 -- assertion failes
Step 2. is the incorrect behavior. When there is a transaction on a
thread's todo list, this thread should not be able to send any outgoing
synchronous transactions. Only the head of the todo list needs to be
checked because only threads that are waiting for proc work can directly
receive work from another thread, and no work is allowed to be queued
on such a thread without waking up the thread. This patch also enforces
that a thread is not waiting for proc work when a work is directly
enqueued to its todo list.
Acked-by: Arve Hjønnevåg
Signed-off-by: Sherry Yang
---
drivers/android/binder.c | 44 +---
1 file changed, 32 insertions(+), 12 deletions(-)
diff --git a/drivers/android/binder.c b/drivers/android/binder.c
index d58763b6b009..f2081934eb8b 100644
--- a/drivers/android/binder.c
+++ b/drivers/android/binder.c
@@ -822,6 +822,7 @@ static void
binder_enqueue_deferred_thread_work_ilocked(struct binder_thread *thread,
struct binder_work *work)
{
+ WARN_ON(!list_empty(&thread->waiting_thread_node));
binder_enqueue_work_ilocked(work, &thread->todo);
}
@@ -839,6 +840,7 @@ static void
binder_enqueue_thread_work_ilocked(struct binder_thread *thread,
struct binder_work *work)
{
+ WARN_ON(!list_empty(&thread->waiting_thread_node));
binder_enqueue_work_ilocked(work, &thread->todo);
thread->process_todo = true;
}
@@ -1270,19 +1272,12 @@ static int binder_inc_node_nilocked(struct binder_node
*node, int strong,
} else
node->local_strong_refs++;
if (!node->has_strong_ref && target_list) {
+ struct binder_thread *thread = container_of(target_list,
+ struct binder_thread, todo);
binder_dequeue_work_ilocked(&node->work);
- /*
-* Note: this function is the only place where we queue
-* directly to a thread->todo without using the
-* corresponding binder_enqueue_thread_work() helper
-* functions; in this case it's ok to not set the
-* process_todo flag, since we know this node work will
-* always be followed by other work that starts queue
-* processing: in case of synchronous transactions, a
-* BR_REPLY or BR_ERROR; in case of oneway
-* transactions, a BR_TRANSACTION_COMPLETE.
-*/
- binder_enqueue_work_ilocked(&node->work, target_list);
+ BUG_ON(&thread->todo != target_list);
+ binder_enqueue_deferred_thread_work_ilocked(thread,
+ &node->work);
}
} else {
if (!internal)
@@ -2723,6 +2718,7 @@ static void binder_transaction(struct binder_proc *proc,
{
int ret;
struct binder_transaction *t;
+ struct binder_work *w;
struct binder_work *tcomplete;
binder_size_t *offp, *off_end, *off_start;
binder_size_t off_min;
@@ -2864,6 +2860,29 @@ static void binder_transaction(struct binder_proc *proc,
goto err_invalid_target_handle;
}
binder_inner_proc_lock(proc);
+
+ w = list_first_entry_or_null(&thread->todo,
+struct binder_work, entry);
+ if (!(tr->flags & TF_ONE_WAY) && w &&
+ w->type == BINDER_WORK_TRANSACTION) {
+ /*
+* Do not allow new outgoing transaction from a
+* thread that has a transaction at the head of
+* its todo list. Only need to check the head
+* because binder_select_thread_
Re: [PATCH] zsmalloc: fix linking bug in init_zspage
Hi Sergey,
On Mon, Aug 13, 2018 at 07:55:36PM +0900, Sergey Senozhatsky wrote:
> On (08/13/18 15:05), Minchan Kim wrote:
> > > From: zhouxianrong
> > >
> > > The last partial object in last subpage of zspage should not be linked
> > > in allocation list. Otherwise it could trigger BUG_ON explicitly at
> > > function zs_map_object. But it happened rarely.
> >
> > Could you be more specific? What case did you see the problem?
> > Is it a real problem or one founded by review?
> [..]
> > > Signed-off-by: zhouxianrong
> > > ---
> > > mm/zsmalloc.c | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
> > > index 8d87e973a4f5..24dd8da0aa59 100644
> > > --- a/mm/zsmalloc.c
> > > +++ b/mm/zsmalloc.c
> > > @@ -1040,6 +1040,8 @@ static void init_zspage(struct size_class *class,
> > > struct zspage *zspage)
> > >* Reset OBJ_TAG_BITS bit to last link to tell
> > >* whether it's allocated object or not.
> > >*/
> > > + if (off > PAGE_SIZE)
> > > + link -= class->size / sizeof(*link);
> > > link->next = -1UL << OBJ_TAG_BITS;
> > > }
> > > kunmap_atomic(vaddr);
>
> Hmm. This can be a real issue. Unless I'm missing something.
>
> So... I might be wrong, but the way I see the bug report is:
>
> When we link objects during zspage init, we do the following:
>
> while ((off += class->size) < PAGE_SIZE) {
> link->next = freeobj++ << OBJ_TAG_BITS;
> link += class->size / sizeof(*link);
> }
>
> Note that we increment the link first, link += class->size / sizeof(*link),
> and check for the offset only afterwards. So by the time we break out of
> the while-loop the link *might* point to the partial object which starts at
> the last page of zspage, but *never* ends, because we don't have next_page
> in current zspage. So that's why that object should not be linked in,
> because it's not a valid allocates object - we simply don't have space
> for it anymore.
>
> zspage [ page 1 ][ page 2 ]
> ...link
> [..###]
>
> therefore the last object must be "link - 1" for such cases.
>
> I think, the following change can also do the trick:
>
> while ((off + class->size) < PAGE_SIZE) {
> link->next = freeobj++ << OBJ_TAG_BITS;
> link += class->size / sizeof(*link);
> off += class->size;
> }
>
> Once again, I might be wrong on this.
> Any thoughts?
If we want a refactoring, I'm not against but description said it tiggered
BUG_ON on zs_map_object rarely. That means it should be stable material
and need more description to understand. Please be more specific with
some example. The reason I'm hesitating is zsmalloc moves ZS_FULL group
when the zspage->inuse is equal to class->objs_per_zspage so I thought
it shouldn't allocate last partial object.
Thanks.
Re: [PATCH v8 1/6] Uprobes: Simplify uprobe_register() body
On Mon, 13 Aug 2018 01:56:12 -0700 Srikar Dronamraju wrote: > * Ravi Bangoria [2018-08-09 09:48:51]: > > > Simplify uprobe_register() function body and let __uprobe_register() > > handle everything. Also move dependency functions around to fix build > > failures. > > > > One nit: > s/to fix build/failures/to avoid build failures/ I pulled in this patch with the above update to the change log. > > > > > Signed-off-by: Ravi Bangoria > > --- > > > Acked-by: Srikar Dronamraju Thanks, I added your ack and Song's Reviewed-by tags. -- Steve
Re: [PATCH v8 3/6] Uprobes: Support SDT markers having reference count (semaphore)
On Mon, 13 Aug 2018 20:01:41 -0400 Steven Rostedt wrote: > On Fri, 10 Aug 2018 23:14:01 -0700 > Song Liu wrote: > > > On Fri, Aug 10, 2018 at 12:58 PM, Steven Rostedt > > wrote: > > > On Thu, 9 Aug 2018 16:38:28 +0200 > > > Oleg Nesterov wrote: > > > > > >> I need to read this (hopefully final) version carefully. I'll try to do > > >> this before next Monday. > > >> > > > > > > Monday may be the opening of the merge window (more likely Sunday). Do > > > you think this is good enough for pushing it in this late in the game, > > > or do you think we should wait another cycle? > > > > > > -- Steve > > > > We (Facebook) have use cases in production that would benefit from this > > work, so > > I would rather see this gets in sooner than later. After a brief > > review (I will more > > careful review before Monday), I think this set is not likely to break > > existing uprobes > > (those w/o ref_ctr). Therefore, I think it is safe to put it in this cycle. > > > > It's still going under review, and the merge window is now open. I'd > prefer that this waits till the next merge window. > > But this said, patch 1&2 look simple enough to include this merge window. I'll pull them in and start testing. -- Steve
Re: [RFC] vruntime updated incorrectly when rt_mutex boots prio?
On 08/07/2018 10:40 AM, 'Todd Kjos' via kernel-team wrote:
This issue was discovered on a 4.9-based android device, but the
relevant mainline code appears to be the same. The symptom is that
over time the some workloads become sluggish resulting in missed
frames or sluggishness. It appears to be the same issue described in
http://lists.infradead.org/pipermail/linux-arm-kernel/2018-March/567836.html.
Here is the scenario: A task is deactivated while still in the fair
class. The task is then boosted to RT, so rt_mutex_setprio() is
called. This changes the task to RT and calls check_class_changed(),
which eventually calls detach_task_cfs_rq(), which is where
vruntime_normalized() sees that the task's state is TASK_WAKING, which
results in skipping the subtraction of the rq's min_vruntime from the
task's vruntime. Later, when the prio is deboosted and the task is
moved back to the fair class, the fair rq's min_vruntime is added to
the task's vruntime, resulting in vruntime inflation.
This was reproduced for me on tip of mainline by using the program at
the end of this mail. It was run in a 2 CPU virtualbox VM. Relevant
annotated bits of the trace:
low-prio thread vruntime is 752ms
pi-vruntime-tes-598 [001] d... 520.572459: sched_stat_runtime:
comm=pi-vruntime-tes pid=598 runtime=29953 [ns] vruntime=752888705 [ns]
low-prio thread waits on a_sem
pi-vruntime-tes-598 [001] d... 520.572465: sched_switch:
prev_comm=pi-vruntime-tes prev_pid=598 prev_prio=120 prev_state=D ==>
next_comm=swapper/1 next_pid=0 next_prio=120
high prio thread finishes wakeup, then sleeps for 1ms
-0 [000] dNh. 520.572483: sched_wakeup:
comm=pi-vruntime-tes pid=597 prio=19 target_cpu=000
-0 [000] d... 520.572486: sched_switch:
prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=pi-vruntime-tes next_pid=597 next_prio=19
pi-vruntime-tes-597 [000] d... 520.572498: sched_switch:
prev_comm=pi-vruntime-tes prev_pid=597 prev_prio=19 prev_state=D ==>
next_comm=swapper/0 next_pid=0 next_prio=120
high prio thread wakes up after 1ms sleep, posts a_sem which starts to
wake low-prio thread, then tries to grab pi_mutex, which low-prio thread has
-0 [000] d.h. 520.573876: sched_waking:
comm=pi-vruntime-tes pid=597 prio=19 target_cpu=000
-0 [000] dNh. 520.573879: sched_wakeup:
comm=pi-vruntime-tes pid=597 prio=19 target_cpu=000
-0 [000] d... 520.573887: sched_switch:
prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=pi-vruntime-tes next_pid=597 next_prio=19
pi-vruntime-tes-597 [000] d... 520.573895: sched_waking:
comm=pi-vruntime-tes pid=598 prio=120 target_cpu=001
low-prio thread pid 598 gets pi_mutex priority inheritance, this happens
while low-prio thread is in waking state
pi-vruntime-tes-597 [000] d... 520.573911: sched_pi_setprio:
comm=pi-vruntime-tes pid=598 oldprio=120 newprio=19
high-prio thread sleeps on pi_mutex
pi-vruntime-tes-597 [000] d... 520.573919: sched_switch:
prev_comm=pi-vruntime-tes prev_pid=597 prev_prio=19 prev_state=D ==>
next_comm=swapper/0 next_pid=0 next_prio=120
low-prio thread finishes wakeup
-0 [001] dNh. 520.573932: sched_wakeup:
comm=pi-vruntime-tes pid=598 prio=19 target_cpu=001
-0 [001] d... 520.573936: sched_switch:
prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=S ==>
next_comm=pi-vruntime-tes next_pid=598 next_prio=19
low-prio thread releases pi-mutex, loses pi boost, high-prio thread
wakes for pi-mutex
pi-vruntime-tes-598 [001] d... 520.573946: sched_pi_setprio:
comm=pi-vruntime-tes pid=598 oldprio=19 newprio=120
pi-vruntime-tes-598 [001] dN.. 520.573954: sched_waking:
comm=pi-vruntime-tes pid=597 prio=19 target_cpu=000
low-prio thread vruntime is 1505ms
pi-vruntime-tes-598 [001] dN.. 520.573966: sched_stat_runtime:
comm=pi-vruntime-tes pid=598 runtime=20150 [ns] vruntime=1505797560 [ns]
The program:
/*
* Test case for vruntime management during rtmutex priority inheritance
* promotion and demotion.
*
* build with -lpthread
*/
#define _GNU_SOURCE
#include
#include
#include
#include
#include
#define ERROR_CHECK(x) \
if (x) \
fprintf(stderr, "Error at line %d", __LINE__);
pthread_mutex_t pi_mutex;
sem_t a_sem;
sem_t b_sem;
void *rt_thread_func(void *arg) {
int policy;
int i = 0;
cpu_set_t cpuset;
CPU_ZERO(&cpuset);
CPU_SET(0, &cpuset);
ERROR_CHECK(pthread_setaffinity_np(pthread_self(),
sizeof(cpu_set_t),
&cpuset));
while(i++ < 100) {
sem_wait(&b_sem);
usleep(1000);
sem_post(&a_sem);
pthread_mutex_lock(&pi_mutex);
pthread_mutex_unlock(&pi_mutex);
}
}
void *low_prio_thread_func(void *arg) {
int i = 0;
cpu_set_t cpuset;
Re: [PATCH v8 3/6] Uprobes: Support SDT markers having reference count (semaphore)
On Mon, 13 Aug 2018 13:50:19 +0200
Oleg Nesterov wrote:
> On 08/13, Ravi Bangoria wrote:
> >
> > On 08/11/2018 01:27 PM, Song Liu wrote:
> > >> +
> > >> +static void delayed_uprobe_delete(struct delayed_uprobe *du)
> > >> +{
> > >> + if (!du)
> > >> + return;
> > > Do we really need this check?
> >
> > Not necessary though, but I would still like to keep it for a safety.
>
> Heh. I tried to ignore all minor problems in this version, but now that Song
> mentioned this unnecessary check...
>
> Personally I really dislike the checks like this one.
>
> - It can confuse the reader who will try to understand the purpose
>
> - it can hide a bug if delayed_uprobe_delete(du) is actually called
> with du == NULL.
>
> IMO, you should either remove it and let the kernel crash (to notice the
> problem), or turn it into
>
> if (WARN_ON(!du))
> return;
I'd prefer the more robust WARN_ON(!du) above instead of removing it.
-- Steve
Re: [PATCH] mm, slub: restore the original intention of prefetch_freepointer()
On Thu, Aug 9, 2018 at 1:52 AM, Vlastimil Babka wrote:
> In SLUB, prefetch_freepointer() is used when allocating an object from cache's
> freelist, to make sure the next object in the list is cache-hot, since it's
> probable it will be allocated soon.
>
> Commit 2482ddec670f ("mm: add SLUB free list pointer obfuscation") has
> unintentionally changed the prefetch in a way where the prefetch is turned to
> a
> real fetch, and only the next->next pointer is prefetched. In case there is
> not
> a stream of allocations that would benefit from prefetching, the extra real
> fetch might add a useless cache miss to the allocation. Restore the previous
> behavior.
>
> Signed-off-by: Vlastimil Babka
> Cc: Kees Cook
> Cc: Daniel Micay
> Cc: Eric Dumazet
> Cc: Christoph Lameter
> Cc: Pekka Enberg
> Cc: David Rientjes
> Cc: Joonsoo Kim
> ---
> While I don't expect this to be causing the bug at hand, it's worth fixing.
> For the bug it might mean that the page fault moves elsewhere.
>
> mm/slub.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 51258eff4178..ce2b9e5cea77 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -271,8 +271,7 @@ static inline void *get_freepointer(struct kmem_cache *s,
> void *object)
>
> static void prefetch_freepointer(const struct kmem_cache *s, void *object)
> {
> - if (object)
> - prefetch(freelist_dereference(s, object + s->offset));
> + prefetch(object + s->offset);
Ah -- gotcha. I think I misunderstood the purpose here. You're not
prefetching what is being pointed at, you're literally prefetching
what is stored there. That wouldn't require dereferencing the freelist
pointer, no.
Thanks!
Acked-by: Kees Cook
> }
>
> static inline void *get_freepointer_safe(struct kmem_cache *s, void *object)
> --
> 2.18.0
>
--
Kees Cook
Pixel Security
Re: [PATCH v8 3/6] Uprobes: Support SDT markers having reference count (semaphore)
On Fri, 10 Aug 2018 23:14:01 -0700 Song Liu wrote: > On Fri, Aug 10, 2018 at 12:58 PM, Steven Rostedt wrote: > > On Thu, 9 Aug 2018 16:38:28 +0200 > > Oleg Nesterov wrote: > > > >> I need to read this (hopefully final) version carefully. I'll try to do > >> this before next Monday. > >> > > > > Monday may be the opening of the merge window (more likely Sunday). Do > > you think this is good enough for pushing it in this late in the game, > > or do you think we should wait another cycle? > > > > -- Steve > > We (Facebook) have use cases in production that would benefit from this work, > so > I would rather see this gets in sooner than later. After a brief > review (I will more > careful review before Monday), I think this set is not likely to break > existing uprobes > (those w/o ref_ctr). Therefore, I think it is safe to put it in this cycle. > It's still going under review, and the merge window is now open. I'd prefer that this waits till the next merge window. -- Steve
Re: [PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning
2018-08-14 7:09 GMT+09:00 Arnd Bergmann :
> Passing an enum into FIELD_GET() produces a long but harmless warning on
> newer compilers:
>
> from include/linux/linkage.h:7,
> from include/linux/kernel.h:7,
> from include/linux/skbuff.h:17,
> from include/linux/if_ether.h:23,
> from include/linux/etherdevice.h:25,
> from drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:63:
> drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function
> 'iwl_mvm_rx_mpdu_mq':
> include/linux/bitfield.h:56:20: error: enum constant in boolean context
> [-Werror=int-in-bool-context]
>BUILD_BUG_ON_MSG(!(_mask), _pfx "mask is zero"); \
> ^
> ...
> include/linux/bitfield.h:103:3: note: in expansion of macro '__BF_FIELD_CHECK'
>__BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \
>^~~~
> drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:1025:21: note: in expansion of
> macro 'FIELD_GET'
> le16_encode_bits(FIELD_GET(IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK,
How about fixing the root cause
in drivers/net/wireless/intel/iwlwifi/fw/api/rx.h ?
#define IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK 0x1eULL
enum iwl_rx_he_phy looks really strange.
Passing enum to FIELD_GET is odd,
so I prefer keeping this warned.
> The problem here is that the caller has no idea how the macro gets
> expanding, leading to a false-positive. It can be trivially avoided
> by doing a comparison against zero.
>
> This only recently started appearing as the iwlwifi driver was patched
> to use FIELD_GET.
>
> Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax")
> Signed-off-by: Arnd Bergmann
> ---
> include/linux/bitfield.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> index 65a6981eef7b..3f1ef4450a7c 100644
> --- a/include/linux/bitfield.h
> +++ b/include/linux/bitfield.h
> @@ -53,7 +53,7 @@
> ({ \
> BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \
> _pfx "mask is not constant"); \
> - BUILD_BUG_ON_MSG(!(_mask), _pfx "mask is zero");\
> + BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");\
> BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \
> ~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
> _pfx "value too large for the field"); \
> --
> 2.18.0
>
--
Best Regards
Masahiro Yamada
Re: [PATCH v2 1/3] pinctrl: msm: Really mask level interrupts to prevent latching
Hi,
On Wed, Jul 25, 2018 at 3:28 PM, Stephen Boyd wrote:
> The interrupt controller hardware in this pin controller has two status
> enable bits. The first "normal" status enable bit enables or disables
> the summary interrupt line being raised when a gpio interrupt triggers
> and the "raw" status enable bit allows or prevents the hardware from
> latching an interrupt into the status register for a gpio interrupt.
> Currently we just toggle the "normal" status enable bit in the mask and
> unmask ops so that the summary irq interrupt going to the CPU's
> interrupt controller doesn't trigger for the masked gpio interrupt.
>
> For a level triggered interrupt, the flow would be as follows: the pin
> controller sees the interrupt, latches the status into the status
> register, raises the summary irq to the CPU, summary irq handler runs
> and calls handle_level_irq(), handle_level_irq() masks and acks the gpio
> interrupt, the interrupt handler runs, and finally unmask the interrupt.
> When the interrupt handler completes, we expect that the interrupt line
> level will go back to the deasserted state so the genirq code can unmask
> the interrupt without it triggering again.
>
> If we only mask the interrupt by clearing the "normal" status enable bit
> then we'll ack the interrupt but it will continue to show up as pending
> in the status register because the raw status bit is enabled, the
> hardware hasn't deasserted the line, and thus the asserted state latches
> into the status register again. When the hardware deasserts the
> interrupt the pin controller still thinks there is a pending unserviced
> level interrupt because it latched it earlier. This behavior causes
> software to see an extra interrupt for level type interrupts each time
> the interrupt is handled.
>
> Let's fix this by clearing the raw status enable bit for level type
> interrupts so that the hardware stops latching the status of the
> interrupt after we ack it. We don't do this for edge type interrupts
> because it seems that toggling the raw status enable bit for edge type
> interrupts causes spurious edge interrupts.
>
> Cc: Bjorn Andersson
> Cc: Doug Anderson
> Signed-off-by: Stephen Boyd
> ---
>
> Changes from v1:
> - Squashed raw_status_bit write into same write on unmask (Doug
>Andersson)
>
> drivers/pinctrl/qcom/pinctrl-msm.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c
> b/drivers/pinctrl/qcom/pinctrl-msm.c
> index 2155a30c282b..3970dc599092 100644
> --- a/drivers/pinctrl/qcom/pinctrl-msm.c
> +++ b/drivers/pinctrl/qcom/pinctrl-msm.c
> @@ -634,6 +634,19 @@ static void msm_gpio_irq_mask(struct irq_data *d)
> raw_spin_lock_irqsave(&pctrl->lock, flags);
>
> val = readl(pctrl->regs + g->intr_cfg_reg);
> + /*
> +* Leaving the RAW_STATUS_EN bit enabled causes level interrupts that
> +* are still asserted to re-latch after we ack them. Clear the raw
> +* status enable bit too so the interrupt can't even latch into the
> +* hardware while it's masked, but only do this for level interrupts
> +* because edge interrupts have a problem with the raw status bit
> +* toggling and causing spurious interrupts.
This whole "spurious interrupts" explanation still seems dodgy. Have
you experienced it yourself, or is this looking through some previous
commits? As per my comments in v1, I'd still rather the comment state
the reason as: it's important to _not_ lose edge interrupts when
masked.
> +*/
> + if (irqd_get_trigger_type(d) & IRQ_TYPE_LEVEL_MASK) {
> + val &= ~BIT(g->intr_raw_status_bit);
> + writel(val, pctrl->regs + g->intr_cfg_reg);
> + }
In v1 you claimed you were going to combine this with the next write
(you said you'd combine things in both mask and unmask). ...is there
a reason why you didn't? As per my comments in v1 I believe it's
safer from a correctness point of view to combine them.
-Doug
[PATCH 9/9] platform: goldfish: pipe: Add a blank line to separate struct members
From: Roman Kiryanov
To improve readability and to be consistent with other
struct members.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 3f8e440d62ae..d0621da2c334 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -157,6 +157,7 @@ struct goldfish_pipe {
/* A wake queue for sleeping until host signals an event */
wait_queue_head_t wake_queue;
+
/* Pointer to the parent goldfish_pipe_dev instance */
struct goldfish_pipe_dev *dev;
};
--
2.18.0.865.gffc8e1a3cd6-goog
[PATCH 4/9] platform: goldfish: pipe: Separate the host interface to a separate header
From: Roman Kiryanov
These are several enums that must kept in sync with the host side.
This change explicitly separates them into a dedicated header file.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 69 +--
.../platform/goldfish/goldfish_pipe_qemu.h| 112 ++
2 files changed, 113 insertions(+), 68 deletions(-)
create mode 100644 drivers/platform/goldfish/goldfish_pipe_qemu.h
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 0607897c6a59..8f9580454154 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -63,6 +63,7 @@
#include
#include
#include
+#include "goldfish_pipe_qemu.h"
/*
* Update this when something changes in the driver's behavior so the host
@@ -73,74 +74,6 @@ enum {
PIPE_CURRENT_DEVICE_VERSION = 2
};
-/*
- * IMPORTANT: The following constants must match the ones used and defined
- * in external/qemu/hw/goldfish_pipe.c in the Android source tree.
- */
-
-/* List of bitflags returned in status of CMD_POLL command */
-enum PipePollFlags {
- PIPE_POLL_IN= 1 << 0,
- PIPE_POLL_OUT = 1 << 1,
- PIPE_POLL_HUP = 1 << 2
-};
-
-/*
- * Possible status values used to signal errors - see
- * goldfish_pipe_error_convert
- */
-enum PipeErrors {
- PIPE_ERROR_INVAL = -1,
- PIPE_ERROR_AGAIN = -2,
- PIPE_ERROR_NOMEM = -3,
- PIPE_ERROR_IO = -4
-};
-
-/* Bit-flags used to signal events from the emulator */
-enum PipeWakeFlags {
- PIPE_WAKE_CLOSED = 1 << 0, /* emulator closed pipe */
- PIPE_WAKE_READ = 1 << 1, /* pipe can now be read from */
- PIPE_WAKE_WRITE = 1 << 2 /* pipe can now be written to */
-};
-
-/* Bit flags for the 'flags' field */
-enum PipeFlagsBits {
- BIT_CLOSED_ON_HOST = 0, /* pipe closed by host */
- BIT_WAKE_ON_WRITE = 1, /* want to be woken on writes */
- BIT_WAKE_ON_READ = 2, /* want to be woken on reads */
-};
-
-enum PipeRegs {
- PIPE_REG_CMD = 0,
-
- PIPE_REG_SIGNAL_BUFFER_HIGH = 4,
- PIPE_REG_SIGNAL_BUFFER = 8,
- PIPE_REG_SIGNAL_BUFFER_COUNT = 12,
-
- PIPE_REG_OPEN_BUFFER_HIGH = 20,
- PIPE_REG_OPEN_BUFFER = 24,
-
- PIPE_REG_VERSION = 36,
-
- PIPE_REG_GET_SIGNALLED = 48,
-};
-
-enum PipeCmdCode {
- PIPE_CMD_OPEN = 1, /* to be used by the pipe device itself */
- PIPE_CMD_CLOSE,
- PIPE_CMD_POLL,
- PIPE_CMD_WRITE,
- PIPE_CMD_WAKE_ON_WRITE,
- PIPE_CMD_READ,
- PIPE_CMD_WAKE_ON_READ,
-
- /*
-* TODO(zyy): implement a deferred read/write execution to allow
-* parallel processing of pipe operations on the host.
-*/
- PIPE_CMD_WAKE_ON_DONE_IO,
-};
-
enum {
MAX_BUFFERS_PER_COMMAND = 336,
MAX_SIGNALLED_PIPES = 64,
diff --git a/drivers/platform/goldfish/goldfish_pipe_qemu.h
b/drivers/platform/goldfish/goldfish_pipe_qemu.h
new file mode 100644
index ..51f3d9f82af6
--- /dev/null
+++ b/drivers/platform/goldfish/goldfish_pipe_qemu.h
@@ -0,0 +1,112 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Google, Inc.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+/*
+ * IMPORTANT: The following constants must match the ones used and defined in
+ * external/qemu/include/hw/misc/goldfish_pipe.h
+ */
+
+#ifndef ANDROID_PIPE_COMMON_H
+#define ANDROID_PIPE_COMMON_H
+
+/* List of bitflags returned in status of CMD_POLL command */
+enum PipePollFlags {
+ PIPE_POLL_IN= 1 << 0,
+ PIPE_POLL_OUT = 1 << 1,
+ PIPE_POLL_HUP = 1 << 2
+};
+
+/* Possible status values used to signal errors */
+enum PipeErrors {
+ PIPE_ERROR_INVAL= -1,
+ PIPE_ERROR_AGAIN= -2,
+ PIPE_ERROR_NOMEM= -3,
+ PIPE_ERROR_IO = -4
+};
+
+/* Bit-flags used to signal events from the emulator */
+enum PipeWakeFlags {
+ /* emulator closed pipe */
+ PIPE_WAKE_CLOSED= 1 << 0,
+
+ /* pipe can now be read from */
+ PIPE_WAKE_READ = 1 << 1,
+
+ /* pipe can now be written to */
+ PIPE_WAKE_WRITE = 1 << 2,
+
+ /* unlock this pipe's DMA buffer */
+ PIPE_WAKE_UNLOCK_DMA= 1 << 3,
+
+ /* unlock DMA buffer of the pipe shared to this pipe */
+ PIPE_WAKE_UNLOCK_DMA_SHARED = 1 << 4,
+};
+
+/* Possible pipe closing reasons */
+enum PipeCloseReason {
+ /* guest sent a
[PATCH 5/9] platform: goldfish: pipe: Update the comment for GFP_ATOMIC
From: Roman Kiryanov
Provide an explanation why GFP_ATOMIC is needed to prevent changing it to
other values.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 8f9580454154..a4db4d12b09c 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -639,7 +639,10 @@ static int get_free_pipe_id_locked(struct
goldfish_pipe_dev *dev)
return id;
{
- /* Reallocate the array */
+ /* Reallocate the array.
+* Since get_free_pipe_id_locked runs with interrupts disabled,
+* we don't want to make calls that could lead to sleep.
+*/
u32 new_capacity = 2 * dev->pipes_capacity;
struct goldfish_pipe **pipes =
kcalloc(new_capacity, sizeof(*pipes), GFP_ATOMIC);
--
2.18.0.865.gffc8e1a3cd6-goog
[PATCH 7/9] platform: goldfish: pipe: Replace an array of 1 with a variable
From: Roman Kiryanov
There is no reason to have an array of 1.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 28 +++
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 5eed4c824a53..6f3fc4b30fba 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -204,7 +204,7 @@ struct goldfish_pipe_dev {
unsigned char __iomem *base;
};
-static struct goldfish_pipe_dev pipe_dev[1] = {};
+struct goldfish_pipe_dev goldfish_pipe_dev;
static int goldfish_cmd_locked(struct goldfish_pipe *pipe, enum PipeCmdCode
cmd)
{
@@ -563,12 +563,12 @@ static struct goldfish_pipe *signalled_pipes_pop_front(
static void goldfish_interrupt_task(unsigned long unused)
{
- struct goldfish_pipe_dev *dev = pipe_dev;
/* Iterate over the signalled pipes and wake them one by one */
struct goldfish_pipe *pipe;
int wakes;
- while ((pipe = signalled_pipes_pop_front(dev, &wakes)) != NULL) {
+ while ((pipe = signalled_pipes_pop_front(&goldfish_pipe_dev, &wakes)) !=
+ NULL) {
if (wakes & PIPE_WAKE_CLOSED) {
pipe->flags = 1 << BIT_CLOSED_ON_HOST;
} else {
@@ -606,7 +606,7 @@ static irqreturn_t goldfish_pipe_interrupt(int irq, void
*dev_id)
unsigned long flags;
struct goldfish_pipe_dev *dev = dev_id;
- if (dev != pipe_dev)
+ if (dev != &goldfish_pipe_dev)
return IRQ_NONE;
/* Request the signalled pipes from the device */
@@ -671,7 +671,7 @@ static int get_free_pipe_id_locked(struct goldfish_pipe_dev
*dev)
*/
static int goldfish_pipe_open(struct inode *inode, struct file *file)
{
- struct goldfish_pipe_dev *dev = pipe_dev;
+ struct goldfish_pipe_dev *dev = &goldfish_pipe_dev;
unsigned long flags;
int id;
int status;
@@ -761,7 +761,7 @@ static const struct file_operations goldfish_pipe_fops = {
.release = goldfish_pipe_release,
};
-static struct miscdevice goldfish_pipe_dev = {
+static struct miscdevice goldfish_pipe_miscdev = {
.minor = MISC_DYNAMIC_MINOR,
.name = "goldfish_pipe",
.fops = &goldfish_pipe_fops,
@@ -769,8 +769,8 @@ static struct miscdevice goldfish_pipe_dev = {
static int goldfish_pipe_device_init(struct platform_device *pdev)
{
+ struct goldfish_pipe_dev *dev = &goldfish_pipe_dev;
char *page;
- struct goldfish_pipe_dev *dev = pipe_dev;
int err = devm_request_irq(&pdev->dev, dev->irq,
goldfish_pipe_interrupt,
IRQF_SHARED, "goldfish_pipe", dev);
@@ -779,7 +779,7 @@ static int goldfish_pipe_device_init(struct platform_device
*pdev)
return err;
}
- err = misc_register(&goldfish_pipe_dev);
+ err = misc_register(&goldfish_pipe_miscdev);
if (err) {
dev_err(&pdev->dev, "unable to register v2 device\n");
return err;
@@ -828,18 +828,16 @@ static int goldfish_pipe_device_init(struct
platform_device *pdev)
static void goldfish_pipe_device_deinit(struct platform_device *pdev)
{
- struct goldfish_pipe_dev *dev = pipe_dev;
-
- misc_deregister(&goldfish_pipe_dev);
- kfree(dev->pipes);
- free_page((unsigned long)dev->buffers);
+ misc_deregister(&goldfish_pipe_miscdev);
+ kfree(goldfish_pipe_dev.pipes);
+ free_page((unsigned long)goldfish_pipe_dev.buffers);
}
static int goldfish_pipe_probe(struct platform_device *pdev)
{
int err;
struct resource *r;
- struct goldfish_pipe_dev *dev = pipe_dev;
+ struct goldfish_pipe_dev *dev = &goldfish_pipe_dev;
BUILD_BUG_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE);
@@ -889,7 +887,7 @@ static int goldfish_pipe_probe(struct platform_device *pdev)
static int goldfish_pipe_remove(struct platform_device *pdev)
{
- struct goldfish_pipe_dev *dev = pipe_dev;
+ struct goldfish_pipe_dev *dev = &goldfish_pipe_dev;
goldfish_pipe_device_deinit(pdev);
dev->base = NULL;
return 0;
--
2.18.0.865.gffc8e1a3cd6-goog
[PATCH 6/9] platform: goldfish: pipe: Fail compilation if structs are too large
From: Roman Kiryanov
Since the driver provides no workaround prevent in cases if structs do
no fit into a memory page, it is better to fail complation to find about
the issue earlt instead of returning errors at runtime.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index a4db4d12b09c..5eed4c824a53 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -63,6 +63,7 @@
#include
#include
#include
+#include
#include "goldfish_pipe_qemu.h"
/*
@@ -797,9 +798,7 @@ static int goldfish_pipe_device_init(struct platform_device
*pdev)
* needs to be contained in a single physical page. The easiest choice
* is to just allocate a page and place the buffers in it.
*/
- if (WARN_ON(sizeof(*dev->buffers) > PAGE_SIZE))
- return -ENOMEM;
-
+ BUILD_BUG_ON(sizeof(*dev->buffers) > PAGE_SIZE);
page = (char *)__get_free_page(GFP_KERNEL);
if (!page) {
kfree(dev->pipes);
@@ -842,8 +841,7 @@ static int goldfish_pipe_probe(struct platform_device *pdev)
struct resource *r;
struct goldfish_pipe_dev *dev = pipe_dev;
- if (WARN_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE))
- return -ENOMEM;
+ BUILD_BUG_ON(sizeof(struct goldfish_pipe_command) > PAGE_SIZE);
/* not thread safe, but this should not happen */
WARN_ON(dev->base != NULL);
--
2.18.0.865.gffc8e1a3cd6-goog
[PATCH 8/9] platform: goldfish: pipe: Replace pr_ with dev_ for logging
From: Roman Kiryanov
dev_ is preferred if struct device is available.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 6f3fc4b30fba..3f8e440d62ae 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -384,6 +384,7 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
int count = 0, ret = -EINVAL;
unsigned long address, address_end, last_page;
unsigned int last_page_size;
+ struct device *pdev_dev;
/* If the emulator already closed the pipe, no need to go further */
if (unlikely(test_bit(BIT_CLOSED_ON_HOST, &pipe->flags)))
@@ -401,6 +402,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
last_page = (address_end - 1) & PAGE_MASK;
last_page_size = ((address_end - 1) & ~PAGE_MASK) + 1;
+ pdev_dev = pipe->dev->pdev_dev;
+
while (address < address_end) {
s32 consumed_size;
int status;
@@ -433,7 +436,8 @@ static ssize_t goldfish_pipe_read_write(struct file *filp,
* err.
*/
if (status != PIPE_ERROR_AGAIN)
- pr_info_ratelimited("goldfish_pipe: backend
error %d on %s\n",
+ dev_err_ratelimited(pdev_dev,
+ "goldfish_pipe: backend error %d on
%s\n",
status, is_write ? "write" : "read");
break;
}
--
2.18.0.865.gffc8e1a3cd6-goog
[PATCH 2/9] platform: goldfish: pipe: Update license
From: Roman Kiryanov
goldfish_pipe is distributed under GPL v2.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 567005fe11f8..065b2eaab9cc 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) 2012 Intel, Inc.
* Copyright (C) 2013 Intel, Inc.
@@ -983,4 +984,4 @@ static struct platform_driver goldfish_pipe_driver = {
module_platform_driver(goldfish_pipe_driver);
MODULE_AUTHOR("David Turner ");
-MODULE_LICENSE("GPL");
+MODULE_LICENSE("GPL v2");
--
2.18.0.865.gffc8e1a3cd6-goog
[PATCH 1/9] platform: goldfish: pipe: Fix comments to fit 80 columns
From: Roman Kiryanov
Some comment lines are longer than 80 symbols.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 3e32a4c14d5f..567005fe11f8 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -84,7 +84,10 @@ enum PipePollFlags {
PIPE_POLL_HUP = 1 << 2
};
-/* Possible status values used to signal errors - see
goldfish_pipe_error_convert */
+/*
+ * Possible status values used to signal errors - see
+ * goldfish_pipe_error_convert
+ */
enum PipeErrors {
PIPE_ERROR_INVAL = -1,
PIPE_ERROR_AGAIN = -2,
@@ -149,9 +152,9 @@ struct goldfish_pipe_command;
/* A per-pipe command structure, shared with the host */
struct goldfish_pipe_command {
- s32 cmd;/* PipeCmdCode, guest -> host */
- s32 id; /* pipe id, guest -> host */
- s32 status; /* command execution status, host -> guest */
+ s32 cmd;/* PipeCmdCode, guest -> host */
+ s32 id; /* pipe id, guest -> host */
+ s32 status; /* command execution status, host -> guest */
s32 reserved; /* to pad to 64-bit boundary */
union {
/* Parameters for PIPE_CMD_{READ,WRITE} */
--
2.18.0.865.gffc8e1a3cd6-goog
[PATCH 3/9] platform: goldfish: pipe: Fix checkpatch warning
From: Roman Kiryanov
Function's opening brace has to be at the beginning of the next line.
Signed-off-by: Roman Kiryanov
---
drivers/platform/goldfish/goldfish_pipe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/platform/goldfish/goldfish_pipe.c
b/drivers/platform/goldfish/goldfish_pipe.c
index 065b2eaab9cc..0607897c6a59 100644
--- a/drivers/platform/goldfish/goldfish_pipe.c
+++ b/drivers/platform/goldfish/goldfish_pipe.c
@@ -587,7 +587,8 @@ static void signalled_pipes_add_locked(struct
goldfish_pipe_dev *dev,
}
static void signalled_pipes_remove_locked(struct goldfish_pipe_dev *dev,
- struct goldfish_pipe *pipe) {
+ struct goldfish_pipe *pipe)
+{
if (pipe->prev_signalled)
pipe->prev_signalled->next_signalled = pipe->next_signalled;
if (pipe->next_signalled)
--
2.18.0.865.gffc8e1a3cd6-goog
Re: [PATCH] perf/x86/amd/uncore: Set ThreadMask and SliceMask for L3 Cache perf events
Hi Janakarajan, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on tip/perf/core] [also build test WARNING on v4.18 next-20180813] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Janakarajan-Natarajan/perf-x86-amd-uncore-Set-ThreadMask-and-SliceMask-for-L3-Cache-perf-events/20180814-064324 config: i386-randconfig-x002-201832 (attached as .config) compiler: gcc-7 (Debian 7.3.0-16) 7.3.0 reproduce: # save the attached .config to linux build tree make ARCH=i386 All warnings (new ones prefixed by >>): In file included from include/linux/perf_event.h:25:0, from arch/x86//events/amd/uncore.c:11: arch/x86//events/amd/uncore.c: In function 'amd_uncore_event_init': >> arch/x86/include/asm/perf_event.h:51:11: warning: left shift count >= width >> of type [-Wshift-count-overflow] ((0xFUL) << AMD64_L3_SLICE_SHIFT) ^ >> arch/x86//events/amd/uncore.c:218:19: note: in expansion of macro >> 'AMD64_L3_SLICE_MASK' hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK); ^~~ arch/x86/include/asm/perf_event.h:55:12: warning: left shift count >= width of type [-Wshift-count-overflow] ((0xFFUL) << AMD64_L3_THREAD_SHIFT) ^ >> arch/x86//events/amd/uncore.c:218:41: note: in expansion of macro >> 'AMD64_L3_THREAD_MASK' hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK); ^~~~ -- In file included from include/linux/perf_event.h:25:0, from arch/x86/events/amd/uncore.c:11: arch/x86/events/amd/uncore.c: In function 'amd_uncore_event_init': >> arch/x86/include/asm/perf_event.h:51:11: warning: left shift count >= width >> of type [-Wshift-count-overflow] ((0xFUL) << AMD64_L3_SLICE_SHIFT) ^ arch/x86/events/amd/uncore.c:218:19: note: in expansion of macro 'AMD64_L3_SLICE_MASK' hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK); ^~~ arch/x86/include/asm/perf_event.h:55:12: warning: left shift count >= width of type [-Wshift-count-overflow] ((0xFFUL) << AMD64_L3_THREAD_SHIFT) ^ arch/x86/events/amd/uncore.c:218:41: note: in expansion of macro 'AMD64_L3_THREAD_MASK' hwc->config |= (AMD64_L3_SLICE_MASK | AMD64_L3_THREAD_MASK); ^~~~ vim +51 arch/x86/include/asm/perf_event.h 39 40 #define AMD64_EVENTSEL_INT_CORE_SEL_SHIFT 37 41 #define AMD64_EVENTSEL_INT_CORE_SEL_MASK\ 42 (0xFULL << AMD64_EVENTSEL_INT_CORE_SEL_SHIFT) 43 44 #define AMD64_EVENTSEL_EVENT\ 45 (ARCH_PERFMON_EVENTSEL_EVENT | (0x0FULL << 32)) 46 #define INTEL_ARCH_EVENT_MASK \ 47 (ARCH_PERFMON_EVENTSEL_UMASK | ARCH_PERFMON_EVENTSEL_EVENT) 48 49 #define AMD64_L3_SLICE_SHIFT48 50 #define AMD64_L3_SLICE_MASK \ > 51 ((0xFUL) << AMD64_L3_SLICE_SHIFT) 52 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: application/gzip
Re: [PATCH] mm: migration: fix migration of huge PMD shared pages
On 08/13/2018 03:58 AM, Kirill A. Shutemov wrote: > On Sun, Aug 12, 2018 at 08:41:08PM -0700, Mike Kravetz wrote: >> The page migration code employs try_to_unmap() to try and unmap the >> source page. This is accomplished by using rmap_walk to find all >> vmas where the page is mapped. This search stops when page mapcount >> is zero. For shared PMD huge pages, the page map count is always 1 >> not matter the number of mappings. Shared mappings are tracked via >> the reference count of the PMD page. Therefore, try_to_unmap stops >> prematurely and does not completely unmap all mappings of the source >> page. >> >> This problem can result is data corruption as writes to the original >> source page can happen after contents of the page are copied to the >> target page. Hence, data is lost. >> >> This problem was originally seen as DB corruption of shared global >> areas after a huge page was soft offlined. DB developers noticed >> they could reproduce the issue by (hotplug) offlining memory used >> to back huge pages. A simple testcase can reproduce the problem by >> creating a shared PMD mapping (note that this must be at least >> PUD_SIZE in size and PUD_SIZE aligned (1GB on x86)), and using >> migrate_pages() to migrate process pages between nodes. >> >> To fix, have the try_to_unmap_one routine check for huge PMD sharing >> by calling huge_pmd_unshare for hugetlbfs huge pages. If it is a >> shared mapping it will be 'unshared' which removes the page table >> entry and drops reference on PMD page. After this, flush caches and >> TLB. >> >> Signed-off-by: Mike Kravetz >> --- >> I am not %100 sure on the required flushing, so suggestions would be >> appreciated. This also should go to stable. It has been around for >> a long time so still looking for an appropriate 'fixes:'. > > I believe we need flushing. And huge_pmd_unshare() usage in > __unmap_hugepage_range() looks suspicious: I don't see how we flush TLB in > that case. Thanks Kirill, __unmap_hugepage_range() has two callers: 1) unmap_hugepage_range, which wraps the call with tlb_gather_mmu and tlb_finish_mmu on the range. IIUC, this should cause an appropriate TLB flush. 2) __unmap_hugepage_range_final via unmap_single_vma. unmap_single_vma has three callers: - unmap_vmas which assumes the caller will flush the whole range after return. - zap_page_range wraps the call with tlb_gather_mmu/tlb_finish_mmu - zap_page_range_single wraps the call with tlb_gather_mmu/tlb_finish_mmu So, it appears we are covered. But, I could be missing something. My primary reason for asking the question was with respect to the code added to try_to_unmap_one. In my testing, the changes I added appeared to be required. Just wanted to make sure. I need to fix a build issue and will send another version. -- Mike Kravetz
Re: [LKP] ca90800a91 [ 3.251519] WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:4061 __alloc_pages_nodemask
Hi, This is the expected output when running the lib/test_overflow.c tests. Thanks, -Kees On Sun, Aug 12, 2018 at 5:13 PM, kernel test robot wrote: > Greetings, > > 0day kernel testing robot got the below dmesg and the first bad commit is > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master > > commit ca90800a91ba723d78ded634d037c1d2df8b54d6 > Author: Kees Cook > AuthorDate: Thu May 10 16:40:03 2018 -0700 > Commit: Kees Cook > CommitDate: Tue Jun 5 12:16:51 2018 -0700 > > test_overflow: Add memory allocation overflow tests > > Make sure that the memory allocators are behaving as expected in the face > of overflows of multiplied arguments or when using the array_size()-family > helpers. > > Example output of new tests (with the expected __alloc_pages_slowpath > and vmalloc warnings about refusing giant allocations removed): > > [ 93.062076] test_overflow: kmalloc detected saturation > [ 93.062988] test_overflow: kmalloc_node detected saturation > [ 93.063818] test_overflow: kzalloc detected saturation > [ 93.064539] test_overflow: kzalloc_node detected saturation > [ 93.120386] test_overflow: kvmalloc detected saturation > [ 93.143458] test_overflow: kvmalloc_node detected saturation > [ 93.166861] test_overflow: kvzalloc detected saturation > [ 93.189924] test_overflow: kvzalloc_node detected saturation > [ 93.221671] test_overflow: vmalloc detected saturation > [ 93.246326] test_overflow: vmalloc_node detected saturation > [ 93.270260] test_overflow: vzalloc detected saturation > [ 93.293824] test_overflow: vzalloc_node detected saturation > [ 93.294597] test_overflow: devm_kmalloc detected saturation > [ 93.295383] test_overflow: devm_kzalloc detected saturation > [ 93.296217] test_overflow: all tests passed > > Signed-off-by: Kees Cook > > 610b15c50e overflow.h: Add allocation size calculation helpers > ca90800a91 test_overflow: Add memory allocation overflow tests > ec0c96714e Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net > 4110b42356 Add linux-next specific files for 20180810 > +-++++---+ > | | 610b15c50e | > ca90800a91 | ec0c96714e | next-20180810 | > +-++++---+ > | boot_successes | 72 | 0 > | 0 | 0 | > | boot_failures | 1 | 49 > | 18 | 20| > | Mem-Info| 1 | 49 > | 18 | 20| > | WARNING:at_mm/page_alloc.c:#__alloc_pages_nodemask | 0 | 49 > | 18 | 20| > | EIP:__alloc_pages_nodemask | 0 | 49 > | 18 | 20| > | WARNING:at_arch/x86/mm/dump_pagetables.c:#note_page | 0 | 0 > | 0 | 20| > | EIP:note_page | 0 | 0 > | 0 | 20| > +-++++---+ > > [3.249253] test_overflow: s8 : 19 tests > [3.249696] test_overflow: u16: 17 tests > [3.250151] test_overflow: s16: 17 tests > [3.250599] test_overflow: u32: 17 tests > [3.251039] test_overflow: s32: 17 tests > [3.251519] WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:4061 > __alloc_pages_nodemask+0x2e9/0xe12 > [3.252625] CPU: 0 PID: 1 Comm: swapper/0 Tainted: GT > 4.17.0-rc4-6-gca90800 #1151 > [3.253474] EIP: __alloc_pages_nodemask+0x2e9/0xe12 > [3.253474] EFLAGS: 00210246 CPU: 0 > [3.253474] EAX: 00200140 EBX: ECX: EDX: 0001 > [3.253474] ESI: 7a7af300 EDI: 014040c0 EBP: 7fc4fde4 ESP: 7fc4fd38 > [3.253474] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 > [3.253474] CR0: 80050033 CR2: CR3: 02a9 CR4: 06d0 > [3.253474] Call Trace: > [3.253474] ? sched_clock_cpu+0x11c/0x155 > [3.253474] ? _raw_spin_unlock+0x2c/0x45 > [3.253474] ? free_one_page+0x28b/0x423 > [3.253474] ? kmalloc_order+0x20/0x2f > [3.253474] ? kmalloc_order_trace+0x1b/0xe0 > [3.253474] ? __kmalloc+0x180/0x227 > [3.253474] ? kfree+0x1d3/0x1f6 > [3.253474] ? test_kmalloc+0xe6/0x137 > [3.253474] ? test_module_init+0x2297/0x30e3 > [3.253474] ? preempt_count_sub+0xa/0x67 > [3.253474] ? preempt_count_sub+0x44/0x67 > [3.253474] ? _raw_spin_unlock_irqrestore+0x41/0x6a > [3.253474] ? add_device_randomness+0xb1/0x208 > [3.253474] ? test_kzalloc+0x137/0x137 > [3.253474] ? do_
Re: [PATCH] ARM: dts: imx7ulp: update pinfunc header file
On Tue, Jul 31, 2018 at 06:10:35AM +0800, Anson Huang wrote: > The i.MX7ULP B0 chip has some pin changes for USB and VIU > module, update pinfunc header file accordingly. > > Signed-off-by: Anson Huang > --- > arch/arm/boot/dts/imx7ulp-pinfunc.h | 16 +++- > 1 file changed, 15 insertions(+), 1 deletion(-) Acked-by: Rob Herring
Re: [PATCH] cpumask: provide a dummy cpumask_next_wrap
From: Arnd Bergmann
Date: Mon, 13 Aug 2018 23:55:16 +0200
> The virtio_net driver has become the first one to call cpumask_next_wrap()
> even if CONFIG_SMP is disabled, leading to a build error:
>
> drivers/net/virtio_net.c: In function 'virtnet_set_affinity':
> drivers/net/virtio_net.c:1916:10: error: implicit declaration of function
> 'cpumask_next_wrap'; did you mean 'cpumask_next_and'?
> [-Werror=implicit-function-declaration]
> cpu = cpumask_next_wrap(cpu, cpu_online_mask,
>
> Add a stub function along the lines of cpumask_first(), cpumask_next() etc.
> I'm not entirely sure what should be returned in this case, but at
> least for virtio_net, anything should work.
>
> Fixes: 2ca653d607ce ("virtio_net: Stripe queue affinities across cores.")
> Signed-off-by: Arnd Bergmann
This should already be fixed in my tree, and:
> +static inline int cpumask_next_wrap(int n, const struct cpumask *mask, int
> start, bool wrap)
> +{
> + return n;
> +}
this doesn't handle the "n==0 && wrap" case properly, in that situation you
should
return '1'.
Re: [GIT PULL] security subsystem: general update for v4.19
On Tue, 14 Aug 2018, James Morris wrote: > I'll followup with updates for Smack and TPM once this is merged. As well as an update for the Integrity subsystem. -- James Morris
[GIT PULL] security subsystem: general update for v4.19
Please pull these general updates for v4.19. Summary: - kstrdup() return value fix from Eric Biggers - Add new security_load_data hook to differentiate security checking of kernel-loaded binaries in the case of there being no associated file descriptor, from Mimi Zohar. - Add ability to IMA to specify a policy at build-time, rather than just via command line params or by loading a custom policy, from Mimi. - Allow IMA and LSMs to prevent sysfs firmware load fallback (e.g. if using signed firmware), from Mimi. - Allow IMA to deny loading of kexec kernel images, as they cannot be measured by IMA, from Mimi. I'll followup with updates for Smack and TPM once this is merged. --- The following changes since commit 7daf201d7fe8334e2d2364d4e8ed3394ec9af819: Linux 4.18-rc2 (2018-06-24 20:54:29 +0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next-general for you to fetch changes up to 87ea58433208d17295e200d56be5e2a4fe4ce7d6: security: check for kstrdup() failure in lsm_append() (2018-07-17 21:27:06 -0700) Arnd Bergmann (1): security: export security_kernel_load_data function Eric Biggers (1): security: check for kstrdup() failure in lsm_append() James Morris (1): Merge tag 'v4.18-rc2' into next-general Mimi Zohar (8): security: define new LSM hook named security_kernel_load_data kexec: add call to LSM hook in original kexec_load syscall ima: based on policy require signed kexec kernel images firmware: add call to LSM hook before firmware sysfs fallback ima: based on policy require signed firmware (sysfs fallback) ima: add build time policy module: replace the existing LSM hook in init_module ima: based on policy warn about loading firmware (pre-allocated buffer) Paul Moore (1): MAINTAINERS: remove the outdated "LINUX SECURITY MODULE (LSM) FRAMEWORK" entry MAINTAINERS | 5 --- drivers/base/firmware_loader/fallback.c | 7 include/linux/ima.h | 7 include/linux/lsm_hooks.h | 6 +++ include/linux/security.h| 27 + kernel/kexec.c | 8 kernel/module.c | 2 +- security/integrity/ima/Kconfig | 58 security/integrity/ima/ima.h| 1 + security/integrity/ima/ima_main.c | 68 ++--- security/integrity/ima/ima_policy.c | 48 +-- security/loadpin/loadpin.c | 6 +++ security/security.c | 13 +++ security/selinux/hooks.c| 15 14 files changed, 248 insertions(+), 23 deletions(-)
Re: [PATCH] mailbox: mediatek: add module license
On 08/13/2018 02:44 PM, Arnd Bergmann wrote:
> The missing license tag in the new driver causes a compile-time warning,
> and may result in the module being unusable if it calls EXPORT_SYMBOL_GPL()
> functions:
>
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/mailbox/mtk-cmdq-mailbox.o
>
> Fixes: 623a6143a845 ("mailbox: mediatek: Add Mediatek CMDQ driver")
> Signed-off-by: Arnd Bergmann
> ---
> drivers/mailbox/mtk-cmdq-mailbox.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/mailbox/mtk-cmdq-mailbox.c
> b/drivers/mailbox/mtk-cmdq-mailbox.c
> index 6f92c5ee12f7..aec46d5d3506 100644
> --- a/drivers/mailbox/mtk-cmdq-mailbox.c
> +++ b/drivers/mailbox/mtk-cmdq-mailbox.c
> @@ -567,3 +567,5 @@ static void __exit cmdq_drv_exit(void)
>
> subsys_initcall(cmdq_drv_init);
> module_exit(cmdq_drv_exit);
> +
> +MODULE_LICENSE("GPL v2");
>
https://lore.kernel.org/lkml/99f4666b-95fc-a1dd-04d3-3d1d80399...@infradead.org/
--
~Randy
[PATCH] fsi: ast: select GENERIC_ALLOCATOR
In randconfig builds without CONFIG_GENERIC_ALLOCATOR, this driver
fails to link:
ERROR: "gen_pool_alloc_algo" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "gen_pool_fixed_alloc" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "of_gen_pool_get" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
ERROR: "gen_pool_free" [drivers/fsi/fsi-master-ast-cf.ko] undefined!
Select the dependency as all other users do.
Fixes: 6a794a27daca ("fsi: master-ast-cf: Add new FSI master using Aspeed
ColdFire")
Signed-off-by: Arnd Bergmann
---
drivers/fsi/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/fsi/Kconfig b/drivers/fsi/Kconfig
index af3a20dd5aa4..99c99a5d57fe 100644
--- a/drivers/fsi/Kconfig
+++ b/drivers/fsi/Kconfig
@@ -46,6 +46,7 @@ config FSI_MASTER_AST_CF
tristate "FSI master based on Aspeed ColdFire coprocessor"
depends on GPIOLIB
depends on GPIO_ASPEED
+ select GENERIC_ALLOCATOR
---help---
This option enables a FSI master using the AST2400 and AST2500 GPIO
lines driven by the internal ColdFire coprocessor. This requires
--
2.18.0
Re: [PATCH] perf/x86: Add __ro_after_init annotations
On Fri, Aug 10, 2018 at 8:43 AM, Zubin Mithra wrote:
> x86_pmu_{format,events,attr,caps}_group is written to in
> init_hw_perf_events and not modified after. This makes them suitable
> candidates for annotating as __ro_after_init.
>
> Signed-off-by: Zubin Mithra
Reviewed-by: Kees Cook
-Kees
> ---
> arch/x86/events/core.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> index 5f4829f10129..88e5f67f5d4c 100644
> --- a/arch/x86/events/core.c
> +++ b/arch/x86/events/core.c
> @@ -1584,7 +1584,7 @@ static void __init pmu_check_apic(void)
>
> }
>
> -static struct attribute_group x86_pmu_format_group = {
> +static struct attribute_group x86_pmu_format_group __ro_after_init = {
> .name = "format",
> .attrs = NULL,
> };
> @@ -1715,7 +1715,7 @@ static struct attribute *events_attr[] = {
> NULL,
> };
>
> -static struct attribute_group x86_pmu_events_group = {
> +static struct attribute_group x86_pmu_events_group __ro_after_init = {
> .name = "events",
> .attrs = events_attr,
> };
> @@ -2230,7 +2230,7 @@ static struct attribute *x86_pmu_attrs[] = {
> NULL,
> };
>
> -static struct attribute_group x86_pmu_attr_group = {
> +static struct attribute_group x86_pmu_attr_group __ro_after_init = {
> .attrs = x86_pmu_attrs,
> };
>
> @@ -2248,7 +2248,7 @@ static struct attribute *x86_pmu_caps_attrs[] = {
> NULL
> };
>
> -static struct attribute_group x86_pmu_caps_group = {
> +static struct attribute_group x86_pmu_caps_group __ro_after_init = {
> .name = "caps",
> .attrs = x86_pmu_caps_attrs,
> };
> --
> 2.18.0.597.ga71716f1ad-goog
>
--
Kees Cook
Pixel Security
[PATCH v2] ASoC: wm9712: fix replace codec to component
From: Marcel Ziswiler
Since commit 143b44845d87 ("ASoC: wm9712: replace codec to component")
"wm9712-codec" got renamed to "wm9712-component", however, this change
never got propagated down to the actual board/platform drivers. E.g. on
Colibri T20 this lead to the following spew upon boot with sound/touch
being broken:
[2.214121] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
registered
[2.222137] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[2.344384] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
registered
[2.351885] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[2.668339] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
registered
[2.675811] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[3.208408] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
registered
[3.216312] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[3.235397] tegra-snd-wm9712 sound: ASoC: CODEC DAI wm9712-hifi not
registered
[3.248938] tegra-snd-wm9712 sound: snd_soc_register_card failed (-517)
...
[ 14.970443] ALSA device list:
[ 14.996628] No soundcards found.
This commit finally fixes this again.
Signed-off-by: Marcel Ziswiler
---
Changes in v2:
- Simply rename "wm9712-component" back to "wm9712-codec" as suggested
by Kuninori and Charles.
sound/soc/codecs/wm9712.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/wm9712.c b/sound/soc/codecs/wm9712.c
index 953d94d50586..ade34c26ad2f 100644
--- a/sound/soc/codecs/wm9712.c
+++ b/sound/soc/codecs/wm9712.c
@@ -719,7 +719,7 @@ static int wm9712_probe(struct platform_device *pdev)
static struct platform_driver wm9712_component_driver = {
.driver = {
- .name = "wm9712-component",
+ .name = "wm9712-codec",
},
.probe = wm9712_probe,
--
2.14.4
Re: [PATCH] bluetooth: hci_h5: avoid unused variable warnings
On Mon, Aug 13, 2018 at 3:04 PM, Arnd Bergmann wrote:
> When CONFIG_BT_HCIUART_RTL is disabled, the hci_h5 driver produces a build
> warning because of an incorrect set of #ifdef guards:
>
> drivers/bluetooth/hci_h5.c:920:22: error: 'rtl_vnd' defined but not used
> [-Werror=unused-variable]
>
> Replacing the #ifdef with an IS_ENABLED() check shuts up the error
> and simplifies the logic.
>
> Signed-off-by: Arnd Bergmann
Reviewed-by: Kees Cook
-Kees
> ---
> drivers/bluetooth/hci_h5.c | 10 +++---
> 1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
> index 8eede1197cd2..b10e64ba0ff4 100644
> --- a/drivers/bluetooth/hci_h5.c
> +++ b/drivers/bluetooth/hci_h5.c
> @@ -841,7 +841,6 @@ static void h5_serdev_remove(struct serdev_device *serdev)
> hci_uart_unregister_device(&h5->serdev_hu);
> }
>
> -#ifdef CONFIG_BT_HCIUART_RTL
> static int h5_btrtl_setup(struct h5 *h5)
> {
> struct btrtl_device_info *btrtl_dev;
> @@ -923,24 +922,21 @@ static struct h5_vnd rtl_vnd = {
> .close = h5_btrtl_close,
> .acpi_gpio_map = acpi_btrtl_gpios,
> };
> -#endif
>
> -#ifdef CONFIG_ACPI
> static const struct acpi_device_id h5_acpi_match[] = {
> -#ifdef CONFIG_BT_HCIUART_RTL
> { "OBDA8723", (kernel_ulong_t)&rtl_vnd },
> -#endif
> { },
> };
> MODULE_DEVICE_TABLE(acpi, h5_acpi_match);
> -#endif
>
> static struct serdev_device_driver h5_serdev_driver = {
> .probe = h5_serdev_probe,
> .remove = h5_serdev_remove,
> .driver = {
> .name = "hci_uart_h5",
> - .acpi_match_table = ACPI_PTR(h5_acpi_match),
> + .acpi_match_table = (IS_ENABLED(CONFIG_BT_HCIUART_RTL) &&
> +IS_ENABLED(CONFIG_ACPI)) ?
> + h5_acpi_match : 0,
> },
> };
>
> --
> 2.18.0
>
--
Kees Cook
Pixel Security
[PATCH v3 6/7] mtd: rawnand: ams-delta: Simplify pointer resolution on read/write
Simplify data read/write sub-functions by making them accept private
structure pointer instead of resolving it again from mtd_info.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Boris Brezillon
---
drivers/mtd/nand/raw/ams-delta.c | 30 +++---
1 file changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c
index 5f9180fe4f8b..59fc417e8fa9 100644
--- a/drivers/mtd/nand/raw/ams-delta.c
+++ b/drivers/mtd/nand/raw/ams-delta.c
@@ -73,10 +73,9 @@ static const struct mtd_partition partition_info[] = {
.size = 3 * SZ_256K },
};
-static void ams_delta_write_next_byte(struct mtd_info *mtd, u_char byte)
+static void ams_delta_write_next_byte(struct ams_delta_nand *priv, u_char byte)
{
- struct nand_chip *this = mtd_to_nand(mtd);
- struct ams_delta_nand *priv = nand_get_controller_data(this);
+ struct nand_chip *this = &priv->nand_chip;
writew(byte, this->IO_ADDR_W);
@@ -85,10 +84,8 @@ static void ams_delta_write_next_byte(struct mtd_info *mtd,
u_char byte)
gpiod_set_value(priv->gpiod_nwe, 1);
}
-static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
+static void ams_delta_write_byte(struct ams_delta_nand *priv, u_char byte)
{
- struct nand_chip *this = mtd_to_nand(mtd);
- struct ams_delta_nand *priv = nand_get_controller_data(this);
void __iomem *io_base = priv->io_base;
if (priv->data_in) {
@@ -96,13 +93,12 @@ static void ams_delta_write_byte(struct mtd_info *mtd,
u_char byte)
priv->data_in = false;
}
- ams_delta_write_next_byte(mtd, byte);
+ ams_delta_write_next_byte(priv, byte);
}
-static u_char ams_delta_read_next_byte(struct mtd_info *mtd)
+static u_char ams_delta_read_next_byte(struct ams_delta_nand *priv)
{
- struct nand_chip *this = mtd_to_nand(mtd);
- struct ams_delta_nand *priv = nand_get_controller_data(this);
+ struct nand_chip *this = &priv->nand_chip;
u_char res;
gpiod_set_value(priv->gpiod_nre, 0);
@@ -126,30 +122,34 @@ static u_char ams_delta_read_byte(struct mtd_info *mtd)
priv->data_in = true;
}
- return ams_delta_read_next_byte(mtd);
+ return ams_delta_read_next_byte(priv);
}
static void ams_delta_write_buf(struct mtd_info *mtd, const u_char *buf,
int len)
{
+ struct nand_chip *this = mtd_to_nand(mtd);
+ struct ams_delta_nand *priv = nand_get_controller_data(this);
int i = 0;
if (len > 0)
- ams_delta_write_byte(mtd, buf[i++]);
+ ams_delta_write_byte(priv, buf[i++]);
while (i < len)
- ams_delta_write_next_byte(mtd, buf[i++]);
+ ams_delta_write_next_byte(priv, buf[i++]);
}
static void ams_delta_read_buf(struct mtd_info *mtd, u_char *buf, int len)
{
+ struct nand_chip *this = mtd_to_nand(mtd);
+ struct ams_delta_nand *priv = nand_get_controller_data(this);
int i = 0;
if (len > 0)
buf[i++] = ams_delta_read_byte(mtd);
while (i < len)
- buf[i++] = ams_delta_read_next_byte(mtd);
+ buf[i++] = ams_delta_read_next_byte(priv);
}
/*
@@ -173,7 +173,7 @@ static void ams_delta_hwcontrol(struct mtd_info *mtd, int
cmd,
}
if (cmd != NAND_CMD_NONE)
- ams_delta_write_byte(mtd, cmd);
+ ams_delta_write_byte(priv, cmd);
}
static int ams_delta_nand_ready(struct mtd_info *mtd)
--
2.16.4
[PATCH v3 3/7] ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
Data port used by Amstrad Delta NAND driver is actually an OMAP MPUIO
device, already under control of gpio-omap driver. The NAND driver
gets access to the port by ioremapping it and performs read/write
operations. That is done without any proteciton from other users
legally manipulating the port pins over GPIO API.
The plan is to convert the driver to access the port over GPIO consumer
API. Before that is implemented, the driver can already obtain
exclusive access to the port by requesting an array of its GPIO
descriptors.
Add respective entries to the NAND GPIO lookup table.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Boris Brezillon
Reviewed-by: Linus Walleij
---
arch/arm/mach-omap1/board-ams-delta.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap1/board-ams-delta.c
b/arch/arm/mach-omap1/board-ams-delta.c
index eedacdfe9725..16f7bbe47607 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -337,7 +337,8 @@ static struct platform_device ams_delta_nand_device = {
.resource = ams_delta_nand_resources,
};
-#define OMAP_GPIO_LABEL"gpio-0-15"
+#define OMAP_GPIO_LABEL"gpio-0-15"
+#define OMAP_MPUIO_LABEL "mpuio"
static struct gpiod_lookup_table ams_delta_nand_gpio_table = {
.table = {
@@ -349,6 +350,14 @@ static struct gpiod_lookup_table ams_delta_nand_gpio_table
= {
GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_NAND_NWE, "nwe", 0),
GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_NAND_ALE, "ale", 0),
GPIO_LOOKUP(LATCH2_LABEL, LATCH2_PIN_NAND_CLE, "cle", 0),
+ GPIO_LOOKUP_IDX(OMAP_MPUIO_LABEL, 0, "data", 0, 0),
+ GPIO_LOOKUP_IDX(OMAP_MPUIO_LABEL, 1, "data", 1, 0),
+ GPIO_LOOKUP_IDX(OMAP_MPUIO_LABEL, 2, "data", 2, 0),
+ GPIO_LOOKUP_IDX(OMAP_MPUIO_LABEL, 3, "data", 3, 0),
+ GPIO_LOOKUP_IDX(OMAP_MPUIO_LABEL, 4, "data", 4, 0),
+ GPIO_LOOKUP_IDX(OMAP_MPUIO_LABEL, 5, "data", 5, 0),
+ GPIO_LOOKUP_IDX(OMAP_MPUIO_LABEL, 6, "data", 6, 0),
+ GPIO_LOOKUP_IDX(OMAP_MPUIO_LABEL, 7, "data", 7, 0),
{ },
},
};
--
2.16.4
[PATCH v3 4/7] mtd: rawnand: ams-delta: request data port GPIO resource
Data port used by the driver is actually an OMAP MPUIO device, already
under control of gpio-omap driver. For that reason we used to not
request the memory region of the port as that would fail because the
region is already busy. Despite that, we are still accessing the port
by just ioremapping it and performing read/write operations. Moreover,
we are doing that without any proteciton from other users legally
manipulating the port pins over GPIO API.
The plan is to convert the driver to access the port over functions
exposed by the gpio-omap driver. Before that happens, already prevent
from other users accessing the port pins by requesting an array of its
GPIO descriptors.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Boris Brezillon
Reviewed-by: Linus Walleij
---
drivers/mtd/nand/raw/ams-delta.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c
index 48233d638d2a..09d6901fc94d 100644
--- a/drivers/mtd/nand/raw/ams-delta.c
+++ b/drivers/mtd/nand/raw/ams-delta.c
@@ -161,6 +161,7 @@ static int ams_delta_init(struct platform_device *pdev)
struct mtd_info *mtd;
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
void __iomem *io_base;
+ struct gpio_descs *data_gpiods;
int err = 0;
if (!res)
@@ -261,6 +262,13 @@ static int ams_delta_init(struct platform_device *pdev)
dev_err(&pdev->dev, "CLE GPIO request failed (%d)\n", err);
goto out_mtd;
}
+ /* Request array of data pins, initialize them as input */
+ data_gpiods = devm_gpiod_get_array(&pdev->dev, "data", GPIOD_IN);
+ if (IS_ERR(data_gpiods)) {
+ err = PTR_ERR(data_gpiods);
+ dev_err(&pdev->dev, "data GPIO request failed: %d\n", err);
+ goto out_mtd;
+ }
/* Scan to find existence of the device */
err = nand_scan(mtd, 1);
--
2.16.4
[PATCH v3 7/7] mtd: rawnand: ams-delta: use GPIO API for data I/O
Don't readw()/writew() data directly from/to GPIO port which is under control of gpio-omap driver, use GPIO API instead. Degrade of performance on Amstrad Delta is significant, can be recognized as a regression, that's why I'm still submitting this patch as RFC. The driver should work with any 8+-bit bidirectional GPIO port, not only OMAP. Signed-off-by: Janusz Krzysztofik Reviewed-by: Linus Walleij --- Exceprts fro timestamped boot logs showing performance degrade. Before the change: [5.469426] Creating 6 MTD partitions on "ams-delta-nand": [5.480909] 0x-0x0038 : "Kernel" [5.502659] 0x0038-0x003c : "u-boot" [5.523055] 0x003c-0x0040 : "u-boot params" [5.543612] 0x0040-0x0044 : "Amstrad LDR" [5.564607] 0x0044-0x01f4 : "File system" [5.601760] 0x01f4-0x0200 : "PBL reserved" [5.624369] usbcore: registered new interface driver dm9601 [5.636233] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [5.649191] ohci-omap: OHCI OMAP driver [5.660713] ohci ohci: OMAP OHCI [5.671299] ohci ohci: new USB bus registered, assigned bus number 1 [5.686862] ohci ohci: irq 54, io mem 0xfffba000 [5.785897] hub 1-0:1.0: USB hub found [5.797856] hub 1-0:1.0: 3 ports detected [5.817576] usbcore: registered new interface driver usb-storage [5.832551] ams-delta-serio ams-delta-serio: incomplete constraints, dummy supplies not allowed [5.858588] ams-delta-serio ams-delta-serio: regulator request failed (-19) [5.879312] input: omap-keypad as /devices/platform/omap-keypad/input/input0 [5.902490] omap_rtc omap_rtc: already running [5.922929] omap_rtc omap_rtc: registered as rtc0 [5.945570] softdog: initialized. soft_noboot=0 soft_margin=60 sec soft_panic=0 (nowayout=0) [5.976712] usbcore: registered new interface driver btusb [6.007348] cx20442-codec cx20442-codec: incomplete constraints, dummy supplies not allowed [6.040575] cx20442-codec cx20442-codec: failed to get POR supply (-19) [6.060916] cx20442-codec cx20442-codec: ASoC: failed to probe component -517 [6.083486] ams-delta-audio ams-delta-audio: ASoC: failed to instantiate card -517 [6.121850] ams-delta-audio ams-delta-audio: snd_soc_register_card failed (-517) [6.163047] NET: Registered protocol family 17 [6.182770] Bluetooth: BNEP (Ethernet Emulation) ver 1.3 [6.203517] Bluetooth: BNEP socket layer initialized [6.283017] serial8250 serial8250.1: Linked as a consumer to regulator.1 [6.306113] usb 1-1: new full-speed USB device number 2 using ohci [6.328825] clock: disabling unused clocks to save power [6.350426] Skipping reset check for DSP domain clock "dsptim_ck" [6.372272] Skipping reset check for DSP domain clock "dspxor_ck" [6.393712] Skipping reset check for DSP domain clock "dspper_ck" [6.428311] ams-delta-serio ams-delta-serio: Linked as a consumer to regulator.2 [6.467801] serio serio0: AMS DELTA keyboard adapter [6.492511] cx20442-codec cx20442-codec: Linked as a consumer to regulator.1 [6.527382] ams-delta-audio ams-delta-audio: cx20442-voice <-> omap-mcbsp.1 mapping ok [6.577387] input: AMS_DELTA hook_switch as /devices/platform/ams-delta-audio/sound/card0/input1 [6.627497] input: AT Raw Set 2 keyboard as /devices/platform/ams-delta-serio/serio0/input/input2 [6.673663] omap_rtc omap_rtc: setting system clock to 2013-02-09 07:22:13 UTC (1360394533) [6.715895] modem_nreset: incomplete constraints, leaving on [6.738677] ALSA device list: [6.758398] #0: AMS_DELTA [7.036234] dm9601 1-1:1.0 eth0: register 'dm9601' at usb-ohci-1, Davicom DM96xx USB 10/100 Ethernet, 00:60:6e:00:00:11 [ 133.860599] random: crng init done [ 138.275853] VFS: Mounted root (jffs2 filesystem) on device 31:4. After the change: [6.261107] Creating 6 MTD partitions on "ams-delta-nand": [6.272046] 0x-0x0038 : "Kernel" [6.294436] 0x0038-0x003c : "u-boot" [6.314454] 0x003c-0x0040 : "u-boot params" [6.335353] 0x0040-0x0044 : "Amstrad LDR" [6.356669] 0x0044-0x01f4 : "File system" [6.393713] 0x01f4-0x0200 : "PBL reserved" [6.416771] usbcore: registered new interface driver dm9601 [6.428631] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [6.441533] ohci-omap: OHCI OMAP driver [6.452758] ohci ohci: OMAP OHCI [6.463300] ohci ohci: new USB bus registered, assigned bus number 1 [6.478817] ohci ohci: irq 54, io mem 0xfffba000 [6.580520] hub 1-0:1.0: USB hub found [6.592424] hub 1-0:1.0: 3 ports detected [6.612363] usbcore: registered new interface driver usb-storage [6.627358] ams-delta-serio ams-delta-serio: incomplete constraints, dummy supplies not allowed [6.653296] ams-delta-serio ams-delta-serio: regulator request fa
[PATCH v3 2/7] mtd: rawnand: ams-delta: Use private structure
Introduce a driver private structure and allocate it on device probe.
Use it for storing nand_chip structure, GPIO descriptors prevoiusly
stored in static variables as well as io_base pointer previously passed
as nand controller data or platform driver data. Subsequent patches
may populate the structure with more members as needed.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Boris Brezillon
---
drivers/mtd/nand/raw/ams-delta.c | 126 +--
1 file changed, 69 insertions(+), 57 deletions(-)
diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c
index af313c620264..48233d638d2a 100644
--- a/drivers/mtd/nand/raw/ams-delta.c
+++ b/drivers/mtd/nand/raw/ams-delta.c
@@ -34,14 +34,18 @@
/*
* MTD structure for E3 (Delta)
*/
-static struct mtd_info *ams_delta_mtd = NULL;
-static struct gpio_desc *gpiod_rdy;
-static struct gpio_desc *gpiod_nce;
-static struct gpio_desc *gpiod_nre;
-static struct gpio_desc *gpiod_nwp;
-static struct gpio_desc *gpiod_nwe;
-static struct gpio_desc *gpiod_ale;
-static struct gpio_desc *gpiod_cle;
+
+struct ams_delta_nand {
+ struct nand_chipnand_chip;
+ struct gpio_desc*gpiod_rdy;
+ struct gpio_desc*gpiod_nce;
+ struct gpio_desc*gpiod_nre;
+ struct gpio_desc*gpiod_nwp;
+ struct gpio_desc*gpiod_nwe;
+ struct gpio_desc*gpiod_ale;
+ struct gpio_desc*gpiod_cle;
+ void __iomem*io_base;
+};
/*
* Define partitions for flash devices
@@ -71,26 +75,28 @@ static const struct mtd_partition partition_info[] = {
static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
{
struct nand_chip *this = mtd_to_nand(mtd);
- void __iomem *io_base = (void __iomem *)nand_get_controller_data(this);
+ struct ams_delta_nand *priv = nand_get_controller_data(this);
+ void __iomem *io_base = priv->io_base;
writew(0, io_base + OMAP_MPUIO_IO_CNTL);
writew(byte, this->IO_ADDR_W);
- gpiod_set_value(gpiod_nwe, 0);
+ gpiod_set_value(priv->gpiod_nwe, 0);
ndelay(40);
- gpiod_set_value(gpiod_nwe, 1);
+ gpiod_set_value(priv->gpiod_nwe, 1);
}
static u_char ams_delta_read_byte(struct mtd_info *mtd)
{
u_char res;
struct nand_chip *this = mtd_to_nand(mtd);
- void __iomem *io_base = (void __iomem *)nand_get_controller_data(this);
+ struct ams_delta_nand *priv = nand_get_controller_data(this);
+ void __iomem *io_base = priv->io_base;
- gpiod_set_value(gpiod_nre, 0);
+ gpiod_set_value(priv->gpiod_nre, 0);
ndelay(40);
writew(~0, io_base + OMAP_MPUIO_IO_CNTL);
res = readw(this->IO_ADDR_R);
- gpiod_set_value(gpiod_nre, 1);
+ gpiod_set_value(priv->gpiod_nre, 1);
return res;
}
@@ -123,11 +129,13 @@ static void ams_delta_read_buf(struct mtd_info *mtd,
u_char *buf, int len)
static void ams_delta_hwcontrol(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
{
+ struct nand_chip *this = mtd_to_nand(mtd);
+ struct ams_delta_nand *priv = nand_get_controller_data(this);
if (ctrl & NAND_CTRL_CHANGE) {
- gpiod_set_value(gpiod_nce, !(ctrl & NAND_NCE));
- gpiod_set_value(gpiod_cle, !!(ctrl & NAND_CLE));
- gpiod_set_value(gpiod_ale, !!(ctrl & NAND_ALE));
+ gpiod_set_value(priv->gpiod_nce, !(ctrl & NAND_NCE));
+ gpiod_set_value(priv->gpiod_cle, !!(ctrl & NAND_CLE));
+ gpiod_set_value(priv->gpiod_ale, !!(ctrl & NAND_ALE));
}
if (cmd != NAND_CMD_NONE)
@@ -136,7 +144,10 @@ static void ams_delta_hwcontrol(struct mtd_info *mtd, int
cmd,
static int ams_delta_nand_ready(struct mtd_info *mtd)
{
- return gpiod_get_value(gpiod_rdy);
+ struct nand_chip *this = mtd_to_nand(mtd);
+ struct ams_delta_nand *priv = nand_get_controller_data(this);
+
+ return gpiod_get_value(priv->gpiod_rdy);
}
@@ -145,7 +156,9 @@ static int ams_delta_nand_ready(struct mtd_info *mtd)
*/
static int ams_delta_init(struct platform_device *pdev)
{
+ struct ams_delta_nand *priv;
struct nand_chip *this;
+ struct mtd_info *mtd;
struct resource *res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
void __iomem *io_base;
int err = 0;
@@ -154,15 +167,16 @@ static int ams_delta_init(struct platform_device *pdev)
return -ENXIO;
/* Allocate memory for MTD device structure and private data */
- this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
- if (!this) {
+ priv = devm_kzalloc(&pdev->dev, sizeof(struct ams_delta_nand),
+ GFP_KERNEL);
+ if (!priv) {
pr_warn("Unable to allocate E3 NAND MTD device structure.\n");
- err = -ENOMEM;
- goto out;
+
[PATCH v3 0/7] mtd: rawnand: ams-delta: Use GPIO API for data I/O
Implement the idea suggested by Artem Bityutskiy and Tony Lindgren,
described in commit b027274d2e3a ("mtd: ams-delta: fix
request_mem_region() failure"). Use pure GPIO API as suggested by
Boris Brezillon.
Janusz Krzysztofik (7):
mtd: rawnand: ams-delta: show parent device in sysfs
mtd: rawnand: ams-delta: Use private structure
ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND data port
mtd: rawnand: ams-delta: request data port GPIO resource
mtd: rawnand: ams-delta: Set port direction when needed
mtd: rawnand: ams-delta: Simplify pointer resolution on read/write
mtd: rawnand: ams-delta: use GPIO API for data I/O
Changelog:
v3:
[PATCH v3 1/7] mtd: rawnand: ams-delta: show parent device in sysfs
- renamed and an explanation added based on other similar patches on
Marek Vasut request, thanks.
[PATCH v3 2/7] mtd: rawnand: ams-delta: Use private structure
- no changes.
[PATCH v3 3/7] ARM: OMAP1: ams-delta: Provide GPIO lookup table for NAND
data port
- no changes.
[PATCH v3 4/7] mtd: rawnand: ams-delta: request data port GPIO resource
- no changes.
[PATCH v3 5/7] mtd: rawnand: ams-delta: Set port direction when needed
- modified to set port direction only when needed instead of on each
transfer as suggested by Boris, thanks, though I kept separate
*_next_byte() functions to maximize performance as much as possible,
- moved back in front of "mtd: rawnand: ams-delta: use GPIO API for data
I/O" with a comment added referring to the planned switch to GPIO API.
[PATCH v3 6/7] mtd: rawnand: ams-delta: Simplify pointer resolution
- moved back in front of "mtd: rawnand: ams-delta: use GPIO API for data
I/O" on Boris request, thanks.
[RFC PATCH v3 7/7] mtd: rawnand: ams-delta: use GPIO API for data I/O
- rebased back on top of the two mentioned above,
- not intended to apply it yet due to performance issues on Amstrad Delta.
Removed from the series:
[RFC PATCH v2 09/12] gpiolib: Identify GPIO descriptor arrays with direct
mapping
[RFC PATCH v2 10/12] gpiolib: Introduce bitmap get/set array API extension
[RFC PATCH v2 11/12] mtd: rawnand: ams-delta: Use GPIO API bitmap extension
[RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions
- intended to be still iterated in a follow up series until performance
issues are resolved.
[RFC PATCH v2 06/12] ARM: OMAP1: ams-delta: drop obsolete NAND resources
- postponed until acceptable performance on Amstrad Delta is achieved.
v2:
[RFC PATCH v2 00/12] mtd: rawnand: ams-delta: Use GPIO API for data I/O
- renamed from former [RFC PATCH 0/8] mtd: rawnand: ams-delta: Use
gpio-omap accessors for data I/O
[RFC PATCH v2 01/12] mtd: rawnand: ams-delta: Assign mtd->dev.parent,
not mtd->owner
- split out from former [RFC PATCH 1/8] on Boris request, thanks.
[RFC PATCH v2 02/12] mtd: rawnand: ams-delta: Use private structure
- remaining part of the former [RFC PATCH 1/8].
[RFC PATCH v2 03/12] ARM: OMAP1: ams-delta: Provide GPIO lookup table
for NAND data port
- split out from former [RFC PATCH 5/8] on Boris requesst, thanks,
[RFC PATCH v2 04/12] mtd: rawnand: ams-delta: request data port GPIO resource
- remaining part of the former [RFC PATCH 5/8],
[RFC PATCH v2 05/12] mtd: rawnand: ams-delta: use GPIO API for data read/write
- reworked from former [RFC PATCH 8/8] on Boris requesst to use pure
GPIO API, thanks,
- moved up in front of former [RFC PATCH 3/8] on Boris request, thanks.
[RFC PATCH v2 06/12] ARM: OMAP1: ams-delta: drop obsolete NAND resources
- split out from former [RFC PATCH 8/8].
[RFC PATCH v2 07/12] mtd: rawnand: ams-delta: Set port direction once per
transfer
- reworked from former [RFC PATCH 3/8] on top of [RFC PATCH v2 05/12].
[RFC PATCH v2 08/12] mtd: rawnand: ams-delta: Simplify pointer resolution
on read/write
- reworked from former [RFC PATCH 4/8] on top of [RFC PATCH v2 08/12],
- renamed from 'Optimize' to 'Simplify' on Boris request, thanks.
[RFC PATCH v2 09/12] gpiolib: Identify GPIO descriptor arrays with direct
mapping
- new patch.
[RFC PATCH v2 10/12] gpiolib: Introduce bitmap get/set array API extension
- new patch.
[RFC PATCH v2 11/12] mtd: rawnand: ams-delta: Use GPIO API bitmap extension
- new patch.
[RFC PATCH v2 12/12] gpiolib: Add fast processing path to bitmap API functions
- new patch.
Removed from the series:
[RFC PATCH 2/8] mtd: rawnand: ams-delta: Write protect device during probe
- postponed on Boris request, thanks.
[RFC PATCH 6/8] gpio: omap: Add get/set_multiple() callbacks
- already applied by Linux in linux-gpio tree, thanks.
[RFC PATCH 7/8] mtd: rawnand: ams-delta: Check sanity of data GPIO resource
- most controversial one, no longer needed after switching to GPIO API.
diffstat
arch/arm/mach-omap1/board-ams-delta.c | 11 -
drivers/mtd/nand/raw/ams-delta.c | 351 +++---
2 files changed, 209 insert
[PATCH v3 5/7] mtd: rawnand: ams-delta: Set port direction when needed
In its current shape, the driver sets data port direction before each
byte read/write operation, even during multi-byte transfers. Improve
performance of the driver by setting the port direction only when
needed.
This optimisation will become particularly important as soon as
planned conversion of the driver to GPIO API for data I/O will be
implemented.
Signed-off-by: Janusz Krzysztofik
---
drivers/mtd/nand/raw/ams-delta.c | 59
1 file changed, 47 insertions(+), 12 deletions(-)
diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c
index 09d6901fc94d..5f9180fe4f8b 100644
--- a/drivers/mtd/nand/raw/ams-delta.c
+++ b/drivers/mtd/nand/raw/ams-delta.c
@@ -45,6 +45,7 @@ struct ams_delta_nand {
struct gpio_desc*gpiod_ale;
struct gpio_desc*gpiod_cle;
void __iomem*io_base;
+ booldata_in;
};
/*
@@ -72,50 +73,83 @@ static const struct mtd_partition partition_info[] = {
.size = 3 * SZ_256K },
};
-static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
+static void ams_delta_write_next_byte(struct mtd_info *mtd, u_char byte)
{
struct nand_chip *this = mtd_to_nand(mtd);
struct ams_delta_nand *priv = nand_get_controller_data(this);
- void __iomem *io_base = priv->io_base;
- writew(0, io_base + OMAP_MPUIO_IO_CNTL);
writew(byte, this->IO_ADDR_W);
+
gpiod_set_value(priv->gpiod_nwe, 0);
ndelay(40);
gpiod_set_value(priv->gpiod_nwe, 1);
}
-static u_char ams_delta_read_byte(struct mtd_info *mtd)
+static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
{
- u_char res;
struct nand_chip *this = mtd_to_nand(mtd);
struct ams_delta_nand *priv = nand_get_controller_data(this);
void __iomem *io_base = priv->io_base;
+ if (priv->data_in) {
+ writew(0, io_base + OMAP_MPUIO_IO_CNTL);
+ priv->data_in = false;
+ }
+
+ ams_delta_write_next_byte(mtd, byte);
+}
+
+static u_char ams_delta_read_next_byte(struct mtd_info *mtd)
+{
+ struct nand_chip *this = mtd_to_nand(mtd);
+ struct ams_delta_nand *priv = nand_get_controller_data(this);
+ u_char res;
+
gpiod_set_value(priv->gpiod_nre, 0);
ndelay(40);
- writew(~0, io_base + OMAP_MPUIO_IO_CNTL);
+
res = readw(this->IO_ADDR_R);
+
gpiod_set_value(priv->gpiod_nre, 1);
return res;
}
+static u_char ams_delta_read_byte(struct mtd_info *mtd)
+{
+ struct nand_chip *this = mtd_to_nand(mtd);
+ struct ams_delta_nand *priv = nand_get_controller_data(this);
+ void __iomem *io_base = priv->io_base;
+
+ if (!priv->data_in) {
+ writew(~0, io_base + OMAP_MPUIO_IO_CNTL);
+ priv->data_in = true;
+ }
+
+ return ams_delta_read_next_byte(mtd);
+}
+
static void ams_delta_write_buf(struct mtd_info *mtd, const u_char *buf,
int len)
{
- int i;
+ int i = 0;
+
+ if (len > 0)
+ ams_delta_write_byte(mtd, buf[i++]);
- for (i=0; i 0)
+ buf[i++] = ams_delta_read_byte(mtd);
- for (i=0; idev, "data GPIO request failed: %d\n", err);
goto out_mtd;
}
+ priv->data_in = true;
/* Scan to find existence of the device */
err = nand_scan(mtd, 1);
--
2.16.4
[PATCH v3 1/7] mtd: rawnand: ams-delta: show parent device in sysfs
Fix a bug where parent device symlinks aren't shown in sysfs. While at it, make use of the default owner set by mtdcore. Signed-off-by: Janusz Krzysztofik Reviewed-by: Boris Brezillon --- drivers/mtd/nand/raw/ams-delta.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/ams-delta.c b/drivers/mtd/nand/raw/ams-delta.c index 2a8872ebd14a..af313c620264 100644 --- a/drivers/mtd/nand/raw/ams-delta.c +++ b/drivers/mtd/nand/raw/ams-delta.c @@ -162,7 +162,7 @@ static int ams_delta_init(struct platform_device *pdev) } ams_delta_mtd = nand_to_mtd(this); - ams_delta_mtd->owner = THIS_MODULE; + ams_delta_mtd->dev.parent = &pdev->dev; /* * Don't try to request the memory region from here, -- 2.16.4
Re: [PATCH] Support mksh as /bin/sh.
On Mon, Aug 13, 2018 at 3:14 AM, wrote: > From: Arkadiusz Miśkiewicz > > mksh needs space between ! and ( to work properly. Otherwise this > happens: > > + make oldconfig > scripts/kconfig/conf --oldconfig Kconfig > ./scripts/clang-version.sh[18]: COPYING: not found > printf: ‘__clang_major__’: expected a numeric value > printf: ‘__clang_minor__’: expected a numeric value > printf: ‘__clang_patchlevel__’: expected a numeric value > init/Kconfig:24:warning: 'CLANG_VERSION': number is invalid > > Signed-off-by: Arkadiusz Miśkiewicz Reviewed-by: Kees Cook -Kees > --- > scripts/clang-version.sh | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/clang-version.sh b/scripts/clang-version.sh > index dbf0a31eb111..e65fbc3079d4 100755 > --- a/scripts/clang-version.sh > +++ b/scripts/clang-version.sh > @@ -12,7 +12,7 @@ > > compiler="$*" > > -if !( $compiler --version | grep -q clang) ; then > +if ! ( $compiler --version | grep -q clang) ; then > echo 0 > exit 1 > fi > -- > 2.18.0 > -- Kees Cook Pixel Security
Re: [PATCH v3 07/17] x86/pci: add Hygon PCI vendor and northbridge support
On Sat, Aug 11, 2018 at 09:27:42PM +0800, Pu Wen wrote: > As Hygon register its PCI Vendor ID as a new one "0x1d94", so add a new > definition PCI_VENDOR_ID_HYGON in include/linux/pci_ids.h. > > Also Hygon PCI Device ID(0x1450/0x1463/0x1464) for Host bridge is added > to amd_nb.c. And it need to define new arrays for Hygon: > hygon_root_ids[], hygon_nb_misc_ids[], hygon_nb_link_ids[]. > > To enable Hygon north bridge support, add new variable root_ids, and > assign its value based on whether CPU vendor is AMD or Hygon. Modify > the CONFIG_AMD_NB to depends on either AMD or Hygon. > > Add Hygon support in amd_postcore_init(), early_root_info_init(). > > Signed-off-by: Pu Wen > --- > arch/x86/Kconfig | 2 +- > arch/x86/kernel/amd_nb.c | 51 > ++-- > arch/x86/pci/amd_bus.c | 6 -- > include/linux/pci_ids.h | 2 ++ > 4 files changed, 52 insertions(+), 9 deletions(-) > diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h > index 2950223..d0e98a9 100644 > --- a/include/linux/pci_ids.h > +++ b/include/linux/pci_ids.h > @@ -511,6 +511,8 @@ > #define PCI_DEVICE_ID_AMI_MEGARAID 0x9010 > #define PCI_DEVICE_ID_AMI_MEGARAID2 0x9060 > > +#define PCI_VENDOR_ID_HYGON 0x1d94 Please add this entry so pci_ids.h remains sorted by Vendor ID, then Device ID, as the comment at the top suggests. With that changed, Acked-by: Bjorn Helgaas# pci_ids.h > #define PCI_VENDOR_ID_AMD0x1022 > #define PCI_DEVICE_ID_AMD_K8_NB 0x1100 > #define PCI_DEVICE_ID_AMD_K8_NB_ADDRMAP 0x1101 > -- > 2.7.4 >
[PATCH] bitfield: avoid gcc-8 -Wint-in-bool-context warning
Passing an enum into FIELD_GET() produces a long but harmless warning on
newer compilers:
from include/linux/linkage.h:7,
from include/linux/kernel.h:7,
from include/linux/skbuff.h:17,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:63:
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c: In function 'iwl_mvm_rx_mpdu_mq':
include/linux/bitfield.h:56:20: error: enum constant in boolean context
[-Werror=int-in-bool-context]
BUILD_BUG_ON_MSG(!(_mask), _pfx "mask is zero"); \
^
...
include/linux/bitfield.h:103:3: note: in expansion of macro '__BF_FIELD_CHECK'
__BF_FIELD_CHECK(_mask, _reg, 0U, "FIELD_GET: "); \
^~~~
drivers/net/wireless/intel/iwlwifi/mvm/rxmq.c:1025:21: note: in expansion of
macro 'FIELD_GET'
le16_encode_bits(FIELD_GET(IWL_RX_HE_PHY_SIBG_SYM_OR_USER_NUM_MASK,
The problem here is that the caller has no idea how the macro gets
expanding, leading to a false-positive. It can be trivially avoided
by doing a comparison against zero.
This only recently started appearing as the iwlwifi driver was patched
to use FIELD_GET.
Fixes: 514c30696fbc ("iwlwifi: add support for IEEE802.11ax")
Signed-off-by: Arnd Bergmann
---
include/linux/bitfield.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index 65a6981eef7b..3f1ef4450a7c 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -53,7 +53,7 @@
({ \
BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \
_pfx "mask is not constant"); \
- BUILD_BUG_ON_MSG(!(_mask), _pfx "mask is zero");\
+ BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");\
BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \
~((_mask) >> __bf_shf(_mask)) & (_val) : 0, \
_pfx "value too large for the field"); \
--
2.18.0
Re: [PATCH] cpumask: provide a dummy cpumask_next_wrap
On Tue, Aug 14, 2018 at 12:02 AM Caleb Raitto wrote: > > On Mon, Aug 13, 2018 at 2:55 PM Arnd Bergmann wrote: > > > > The virtio_net driver has become the first one to call cpumask_next_wrap() > > even if CONFIG_SMP is disabled, leading to a build error: > > > > drivers/net/virtio_net.c: In function 'virtnet_set_affinity': > > drivers/net/virtio_net.c:1916:10: error: implicit declaration of function > > 'cpumask_next_wrap'; did you mean 'cpumask_next_and'? > > [-Werror=implicit-function-declaration] > > cpu = cpumask_next_wrap(cpu, cpu_online_mask, > > > > Add a stub function along the lines of cpumask_first(), cpumask_next() etc. > > I'm not entirely sure what should be returned in this case, but at > > least for virtio_net, anything should work. > > Sorry about the build break, I think this patch with a fix was already merged: > > cpumask: make cpumask_next_wrap available without smp > https://patchwork.ozlabs.org/patch/956670/ Ok, that's also a better fix than mine I think. Thanks, Arnd
[PATCH] bluetooth: hci_h5: avoid unused variable warnings
When CONFIG_BT_HCIUART_RTL is disabled, the hci_h5 driver produces a build
warning because of an incorrect set of #ifdef guards:
drivers/bluetooth/hci_h5.c:920:22: error: 'rtl_vnd' defined but not used
[-Werror=unused-variable]
Replacing the #ifdef with an IS_ENABLED() check shuts up the error
and simplifies the logic.
Signed-off-by: Arnd Bergmann
---
drivers/bluetooth/hci_h5.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/bluetooth/hci_h5.c b/drivers/bluetooth/hci_h5.c
index 8eede1197cd2..b10e64ba0ff4 100644
--- a/drivers/bluetooth/hci_h5.c
+++ b/drivers/bluetooth/hci_h5.c
@@ -841,7 +841,6 @@ static void h5_serdev_remove(struct serdev_device *serdev)
hci_uart_unregister_device(&h5->serdev_hu);
}
-#ifdef CONFIG_BT_HCIUART_RTL
static int h5_btrtl_setup(struct h5 *h5)
{
struct btrtl_device_info *btrtl_dev;
@@ -923,24 +922,21 @@ static struct h5_vnd rtl_vnd = {
.close = h5_btrtl_close,
.acpi_gpio_map = acpi_btrtl_gpios,
};
-#endif
-#ifdef CONFIG_ACPI
static const struct acpi_device_id h5_acpi_match[] = {
-#ifdef CONFIG_BT_HCIUART_RTL
{ "OBDA8723", (kernel_ulong_t)&rtl_vnd },
-#endif
{ },
};
MODULE_DEVICE_TABLE(acpi, h5_acpi_match);
-#endif
static struct serdev_device_driver h5_serdev_driver = {
.probe = h5_serdev_probe,
.remove = h5_serdev_remove,
.driver = {
.name = "hci_uart_h5",
- .acpi_match_table = ACPI_PTR(h5_acpi_match),
+ .acpi_match_table = (IS_ENABLED(CONFIG_BT_HCIUART_RTL) &&
+IS_ENABLED(CONFIG_ACPI)) ?
+ h5_acpi_match : 0,
},
};
--
2.18.0
Re: [PATCH] cpumask: provide a dummy cpumask_next_wrap
On Mon, Aug 13, 2018 at 2:55 PM Arnd Bergmann wrote: > > The virtio_net driver has become the first one to call cpumask_next_wrap() > even if CONFIG_SMP is disabled, leading to a build error: > > drivers/net/virtio_net.c: In function 'virtnet_set_affinity': > drivers/net/virtio_net.c:1916:10: error: implicit declaration of function > 'cpumask_next_wrap'; did you mean 'cpumask_next_and'? > [-Werror=implicit-function-declaration] > cpu = cpumask_next_wrap(cpu, cpu_online_mask, > > Add a stub function along the lines of cpumask_first(), cpumask_next() etc. > I'm not entirely sure what should be returned in this case, but at > least for virtio_net, anything should work. Sorry about the build break, I think this patch with a fix was already merged: cpumask: make cpumask_next_wrap available without smp https://patchwork.ozlabs.org/patch/956670/ Thanks, -Caleb
[PATCH] cpumask: provide a dummy cpumask_next_wrap
The virtio_net driver has become the first one to call cpumask_next_wrap()
even if CONFIG_SMP is disabled, leading to a build error:
drivers/net/virtio_net.c: In function 'virtnet_set_affinity':
drivers/net/virtio_net.c:1916:10: error: implicit declaration of function
'cpumask_next_wrap'; did you mean 'cpumask_next_and'?
[-Werror=implicit-function-declaration]
cpu = cpumask_next_wrap(cpu, cpu_online_mask,
Add a stub function along the lines of cpumask_first(), cpumask_next() etc.
I'm not entirely sure what should be returned in this case, but at
least for virtio_net, anything should work.
Fixes: 2ca653d607ce ("virtio_net: Stripe queue affinities across cores.")
Cc: Peter Zijlstra
Cc: Caleb Raitto
Cc: Willem de Bruijn
Cc: David S. Miller
Signed-off-by: Arnd Bergmann
---
include/linux/cpumask.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index 57f20a0a7794..079ba06309bd 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -159,6 +159,11 @@ static inline unsigned int cpumask_next_and(int n,
return n+1;
}
+static inline int cpumask_next_wrap(int n, const struct cpumask *mask, int
start, bool wrap)
+{
+ return n;
+}
+
/* cpu must be a valid cpu, ie 0, so there's no other choice. */
static inline unsigned int cpumask_any_but(const struct cpumask *mask,
unsigned int cpu)
--
2.18.0
[PATCH v9 03/22] s390/zcrypt: Show load of cards and queues in sysfs
From: Harald Freudenberger
Show the current load value of cards and queues in sysfs.
The load value for each card and queue is maintained by
the zcrypt device driver for dispatching and load
balancing requests over the available devices.
This patch provides the load value to userspace via a
new read only sysfs attribute 'load' per card and queue.
Signed-off-by: Harald Freudenberger
Signed-off-by: Christian Borntraeger
Signed-off-by: Tony Krowiak
---
drivers/s390/crypto/zcrypt_card.c | 12
drivers/s390/crypto/zcrypt_queue.c | 12
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/s390/crypto/zcrypt_card.c
b/drivers/s390/crypto/zcrypt_card.c
index 233e1e6..da2c8df 100644
--- a/drivers/s390/crypto/zcrypt_card.c
+++ b/drivers/s390/crypto/zcrypt_card.c
@@ -83,9 +83,21 @@ static ssize_t zcrypt_card_online_store(struct device *dev,
static DEVICE_ATTR(online, 0644, zcrypt_card_online_show,
zcrypt_card_online_store);
+static ssize_t zcrypt_card_load_show(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+ struct zcrypt_card *zc = to_ap_card(dev)->private;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(&zc->load));
+}
+
+static DEVICE_ATTR(load, 0444, zcrypt_card_load_show, NULL);
+
static struct attribute *zcrypt_card_attrs[] = {
&dev_attr_type.attr,
&dev_attr_online.attr,
+ &dev_attr_load.attr,
NULL,
};
diff --git a/drivers/s390/crypto/zcrypt_queue.c
b/drivers/s390/crypto/zcrypt_queue.c
index 720434e..91a52f2 100644
--- a/drivers/s390/crypto/zcrypt_queue.c
+++ b/drivers/s390/crypto/zcrypt_queue.c
@@ -75,8 +75,20 @@ static ssize_t zcrypt_queue_online_store(struct device *dev,
static DEVICE_ATTR(online, 0644, zcrypt_queue_online_show,
zcrypt_queue_online_store);
+static ssize_t zcrypt_queue_load_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct zcrypt_queue *zq = to_ap_queue(dev)->private;
+
+ return snprintf(buf, PAGE_SIZE, "%d\n", atomic_read(&zq->load));
+}
+
+static DEVICE_ATTR(load, 0444, zcrypt_queue_load_show, NULL);
+
static struct attribute *zcrypt_queue_attrs[] = {
&dev_attr_online.attr,
+ &dev_attr_load.attr,
NULL,
};
--
1.7.1
