On Fri, 12 Apr 2019 at 12:27, Nicholas Piggin wrote:
>
> The nohz idle balancer runs on the lowest idle CPU. This can
> interfere with isolated CPUs, so confine it to HK_FLAG_MISC
> housekeeping CPUs.
>
> HK_FLAG_SCHED is not used for this because it is not set anywhere
> at the moment. This could
Hi all,
In commit
2875248b5e1a ("s390/kexec_file: Fix potential segment overlap in ELF loader")
Fixes tag
Fixes: 91a05d9e1d6b ("s390/kexec_file: Add ELF loader")
has these problem(s):
- Target SHA1 does not exist
Did you mean
Fixes: 8be018827154 ("s390/kexec_file: Add ELF loader")
--
On Sat, 27 Apr 2019 08:06:46 +0200,
Wenwen Wang wrote:
>
> In parse_audio_selector_unit(), the string array 'namelist' is allocated
> through kmalloc_array(), and each string pointer in this array, i.e.,
> 'namelist[]', is allocated through kmalloc() in the following for loop.
> Then, a control in
On Fri, Apr 26, 2019 at 4:18 PM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a dev_dbg message, fix it.
>
> Signed-off-by: Colin Ian King
Acked-By: Gilad Ben-Yossef
Thanks!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
values of β will give rise to dom!
Hi all,
In commit
9bd1be60f55b ("dmaengine: stm32-dma: Fix unsigned variable compared with
zero")
Fixes tag
Fixes: f4fd2ec08f17: ("dmaengine: stm32-dma: use platform_get_irq()")
has these problem(s):
- The colon following the SHA1 is unexpected
Just use
git log -1 --format=
On Sun, 28 Apr 2019 08:42:32 +0200,
Wenwen Wang wrote:
>
> In usX2Y_In04_init(), a new urb is firstly created through usb_alloc_urb()
> and saved to 'usX2Y->In04urb'. Then, a buffer is allocated through
> kmalloc() and saved to 'usX2Y->In04Buf'. After the urb is initialized, a
> sanity check is pe
I added an interface which is more intuitive
and takes less write/read systemcalls.
I think that most people don't really care period
and quota of CFS Bandwidth,
They just use it like
"I will allow this process to use 50% of single core" in most cases.
But I know that we still need to care perio
From: Zhaoyang Huang
this patch introduce timestamp into workingset's entry and judge if the page is
active or inactive via active_file/refault_ratio instead of refault distance.
The original thought is coming from the logs we got from trace_printk in this
patch, we can find about 1/5 of the fil
On Wed, Apr 24, 2019 at 02:33:53PM +0300, Mike Rapoport wrote:
> On Tue, Apr 23, 2019 at 12:13:54AM -0700, Christoph Hellwig wrote:
> > On Sun, Apr 21, 2019 at 10:16:04PM +0100, Mel Gorman wrote:
> > > 32-bit NUMA systems should be non-existent in practice. The last NUMA
> > > system I'm aware of t
On Tue, Apr 23, 2019 at 07:49:57PM +0300, Meelis Roos wrote:
> > > ia64 (looks complicated ...)
> >
> > Well as far as I can tell it was not even used 12 or so years ago on
> > Itanium when I worked on that stuff.
>
> My notes tell that on UP ia64 (RX2620), !NUMA was broken with both
> SPARSEMEM
Friendly ping...
On 2019/4/16 14:44, Yue Haibing wrote:
> From: YueHaibing
>
> Syzkaller report this:
>
> BUG: KASAN: use-after-free in __list_add_valid+0xd4/0xe0 lib/list_debug.c:26
> Read of size 8 at addr 8881ef61ae20 by task syz-executor.0/5996
>
> CPU: 1 PID: 5996 Comm: syz-executor.0
Since cs_etm_queue::prev_packet is allocated for all cases, it will
never be NULL pointer; now validity checking prev_packet is pointless,
remove all of them.
Signed-off-by: Leo Yan
---
tools/perf/util/cs-etm.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/tools/perf/u
Robert Walker reported a segmentation fault is observed when process
CoreSight trace data; this issue can be easily reproduced by the
command 'perf report --itrace=i1000i' for decoding tracing data.
If neither the 'b' flag (synthesize branches events) nor 'l' flag
(synthesize last branch entries)
* Aubrey Li wrote:
> > But what we are really interested in are throughput numbers under
> > these three kernel variants, right?
>
> These are sysbench events per second number, higher is better.
>
> NA/AVX baseline(std%) coresched(std%) +/- nosmt(std%) +/-
> 1/1 508.5( 0.2%)
On Sun, 28 Apr 2019 07:28:20 +0100,
Anson Huang wrote:
>
> Ping...
I'm still building the 5.2 branch, no need to panic just yet.
Thanks,
M.
>
> > -Original Message-
> > From: Mukesh Ojha [mailto:mo...@codeaurora.org]
> > Sent: Monday, April 1, 2019 3:47 PM
> > To: Anson Huang
For license auditing purpose, let's add the SPDX tag.
Signed-off-by: Daniel Lezcano
Acked-by: Viresh Kumar
Acked-by: Philippe Ombredanne
---
drivers/thermal/cpu_cooling.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.c b/driver
The structure cpufreq_cooling_device provides a backpointer to the thermal
device but this one is used for a trace and to unregister. For the trace,
we don't really need this field and the unregister function as the same
pointer passed as parameter. Remove it.
Acked-by: Viresh Kumar
Signed-off-by
The copyright format does not conform to the format requested by
Linaro: https://wiki.linaro.org/Copyright
Fix it.
Signed-off-by: Daniel Lezcano
Viresh Kumar
---
drivers/thermal/cpu_cooling.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/thermal/cpu_cooling.
On Sat, Apr 27, 2019 at 5:15 AM Rob Herring wrote:
>
> On Wed, Apr 10, 2019 at 01:41:39PM -0400, Yangtao Li wrote:
> > Allwinner Process Voltage Scaling Tables defines the voltage and
> > frequency value based on the speedbin blown in the efuse combination.
> > The sunxi-cpufreq-nvmem driver reads
Add macros to define masks and bits for imx6sx MQS registers
Signed-off-by: Shengjiu Wang
---
include/linux/mfd/syscon/imx6q-iomuxc-gpr.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
b/include/linux/mfd/syscon/imx6q-iomuxc-gpr.h
index
Applied, thanks.
-- Daniel
On 26/04/2019 23:47, Alexandre Belloni wrote:
> Hi,
>
> This series immproves the Atmel TCB clocksource driver to address the
> most urgent shortcomings:
> - the current tcb_clksrc driver is probed too late to be able to be used at
>boot and we now have SoCs
On Sun, Apr 28, 2019 at 09:56:35AM +0800, Zhao, Yakui wrote:
> Thanks for the reminder about the access width.
> It is 64-bit register. What I said is the "movq", not "movl".
> (I understand that movl is incorrect for 64-bit register).
I didn't say anything about movl. I think what you're trying t
On Thu, 2019-04-25 at 23:44 +0800, Muchun Song wrote:
> I agree with you that the looking up of the glue dir and creation of its child
> should be protected by the same lock of gdp_mutex. So, do you agree with
> the fix of the following code snippet?
The basic idea yes, the whole bool *locked is h
On Sun, Apr 28, 2019 at 5:33 PM Ingo Molnar wrote:
> So because I'm a big fan of presenting data in a readable fashion, here
> are your results, tabulated:
I thought I tried my best to make it readable, but this one looks much better,
thanks, ;-)
>
> #
> # Sysbench throughput comparison of 3 di
Am Sonntag, 28. April 2019, 08:27:05 CEST schrieb Markus Elfring:
> > arch/arm/mach-rockchip/platsmp.c | 12 ++--
> > arch/arm/mach-rockchip/pm.c | 2 ++
>
> * Would a commit subject variant be nicer?
yeah, but I'll simply adjust that when applying.
> * I dare to present a reminder
rdev_attr_store() should lock and unlock mddev->reconfig_mutex in a
balanced way with mddev_lock() and mddev_unlock().
But when rdev->mddev is NULL, rdev_attr_store() would try to unlock
without locking before. Resolve this locking issue..
This locking issue was detected with Clang Thread Safety
Am Freitag, 26. April 2019, 09:08:08 CEST schrieb Wen Yang:
> The call to of_get_next_child returns a node pointer with refcount
> incremented thus it must be explicitly decremented after the last
> usage.
>
> Detected by coccinelle with the following warnings:
> ./arch/arm/mach-rockchip/pm.c:269:
>> How do you think about to adjust the exception handling in these function
>> implementations a bit more according to the Linux coding style
>> (so that the addition of duplicate function calls would be avoided)?
>
> I actually requested not doing wild gotos for of_node_put calls,
> as it m
Masahiro Yamada writes:
> Forwarding because this file is not in my tree.
>
>
>
>
>
> On Sat, Apr 27, 2019 at 7:22 AM Colin King wrote:
>>
>> From: Colin Ian King
>>
>> The pointer 'tree' is deferenced when assigning pointer 'trie', however
>> trie is being null checked a few lines later, so it
Hi Linus,
Third rc pull request
Nothing particularly special here. There is a small merge conflict
with Adrea's mm_still_valid patches which is resolved as below:
diff --cc drivers/infiniband/core/uverbs_main.c
index db20b6e0f253c9,f2e7ffe6fc5466..7843e89235c34b
--- a/drivers/infiniband/core/uve
Wanpeng Li's on April 28, 2019 5:01 pm:
> On Fri, 12 Apr 2019 at 12:27, Nicholas Piggin wrote:
>>
>> The nohz idle balancer runs on the lowest idle CPU. This can
>> interfere with isolated CPUs, so confine it to HK_FLAG_MISC
>> housekeeping CPUs.
>>
>> HK_FLAG_SCHED is not used for this because it
* Aubrey Li wrote:
> On Sun, Apr 28, 2019 at 5:33 PM Ingo Molnar wrote:
> > So because I'm a big fan of presenting data in a readable fashion, here
> > are your results, tabulated:
>
> I thought I tried my best to make it readable, but this one looks much better,
> thanks, ;-)
> >
> > #
> >
On 25/04/2019 12:12, Elaine Zhang wrote:
> Explicitly use the pinctrl to set/unset the right mode
> instead of relying on the pinctrl init mode.
> And it requires setting the tshut polarity before select pinctrl.
>
> When the temperature sensor mode is set to 0, it will automatically
> reset the b
ping ?
On 08/04/2019 18:30, Daniel Lezcano wrote:
>
> Hi Rob,
>
> the following patch has been pushed in 2016 by commit 51f0aeb2d21f1.
>
> Being able to specify which timer should act as a clocksource or a
> clockevent is often requested. Doing this from the driver itself forces
> to do some a
On Sun, Apr 28, 2019 at 07:02:45AM -0400, Gabriel Krisman Bertazi wrote:
> > On Sat, Apr 27, 2019 at 7:22 AM Colin King wrote:
> >>
> >> From: Colin Ian King
> >>
> >> The pointer 'tree' is deferenced when assigning pointer 'trie', however
> >> trie is being null checked a few lines later, so it
On Sun, 2019-04-28 at 05:38 +0100, Al Viro wrote:
> On Fri, Apr 26, 2019 at 01:30:53PM -0400, Jeff Layton wrote:
>
> > > I _probably_ would take allocation out of the loop (e.g. make it
> > > __getname(), called unconditionally) and turned it into the
> > > d_path.c-style read_seqbegin_or_lock()/n
Looking good, but see inline.
On Sat, Apr 27, 2019 at 10:39 PM Nicholas Mc Guire wrote:
>
> wait_for_completion_timeout() returns unsigned long (0 on timeout or
> remaining jiffies) not int - so rather than introducing an additional
> variable simply wrap the completion into an if().
Your commit
On 4/18/19 10:19 AM, Kees Cook wrote:
On Thu, Apr 18, 2019 at 12:55 AM Alex Ghiti wrote:
Regarding the help text, I agree that it does not seem to be frequent to
place
comment above config like that, I'll let Christoph and you decide what's
best. And I'll
add the possibility for the arch to def
Thanks for the contibution! See inline.
On Sat, Apr 27, 2019 at 10:39 PM Nicholas Mc Guire wrote:
>
> While the endiannes is being handled correctly sparse was unhappy with
> the missing annotation as be16_to_cpu() expects a __be16.
Your commit message has room for improvement here. See my remar
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit 77fc46976e0bfcd78d30fb4c9f0169752b4339c9:
arm64: dts: exynos: Add SlimSSS to Exynos5433 (2019-03-20 19:29:57 +0100)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux
Hi,
On top of previous pull request.
Best regards,
Krzysztof
The following changes since commit 8cc76b1c75722196fb3d7ffe67cbfeb721a7b0e3:
ARM: dts: exynos: Remove console argument from bootargs (2019-04-10 18:13:31
+0200)
are available in the Git repository at:
https://git.kernel.org/pu
On Sun, Apr 28, 2019 at 09:27:20AM -0400, Jeff Layton wrote:
> I don't see a problem doing what you suggest. An offset + fixed length
> buffer would be fine there.
>
> Is there a real benefit to using __getname though? It sucks when we have
> to reallocate but I doubt that it happens with any fre
Hi Greg and Rafael:
Benjamin Herrenschmidt 于2019年4月28日周日 下午6:10写道：
>
> The basic idea yes, the whole bool *locked is horrid though. Wouldn't it
> work to have a get_device_parent_locked that always returns with the mutex
> held,
> or just move the mutex to the caller or something simpler like t
The property is spelled 'bias-pull-up', as documented in
pinctrl-bindings.txt.
Signed-off-by: Jonathan Neuschäfer
---
.../devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt| 2 +-
.../devicetree/bindings/pinctrl/qcom,ipq4019-pinctrl.txt| 2 +-
.../devicetree/bindings/pinctrl/qc
Den 28.04.2019 11.51, skrev kernel test robot:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 09ded8af57bcef7287b8242087d3e7556380de62 ("drm/i915/fbdev: Move
> intel_fb_initial_config() to fbdev helper")
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git
On Sat, Apr 27, 2019 at 08:29:30PM -0700, Yury Norov wrote:
> On top of next-20190418.
>
> Similarly to recently revisited bitmap_parselist() [1],
> bitmap_parse() is ineffective and overcomplicated. This
> series reworks it, aligns its interface with bitmap_parselist()
> and makes usage simpler.
On Sun, 2019-04-28 at 15:48 +0100, Al Viro wrote:
> On Sun, Apr 28, 2019 at 09:27:20AM -0400, Jeff Layton wrote:
>
> > I don't see a problem doing what you suggest. An offset + fixed length
> > buffer would be fine there.
> >
> > Is there a real benefit to using __getname though? It sucks when we
On Sat, Apr 27, 2019 at 02:13:01PM -0500, f...@fredlawl.com wrote:
> From: Frederick Lawler
>
> Replace remaining instances of dev_*() printk wrappers with pci_*()
> printk wrappers. No functional change intended.
> - pci_printk(KERN_DEBUG, parent, "can't find device of ID%04x\n",
>
On Sat, 2019-04-27 at 11:41 -0700, Guenter Roeck wrote:
> On 4/27/19 8:13 AM, Ben Hutchings wrote:
> > This is the start of the stable review cycle for the 3.16.66 release.
> > There are 202 patches in this series, which will be posted as responses
> > to this one. If anyone has any issues with th
On Sun, Apr 28, 2019 at 11:47:58AM -0400, Jeff Layton wrote:
> We could stick that in ceph_dentry_info (->d_fsdata). We have a flags
> field in there already.
Yes, but... You have it freed in ->d_release(), AFAICS, and without
any delays. So lockless accesses will be trouble.
On Sat, Apr 27, 2019 at 02:13:03PM -0500, f...@fredlawl.com wrote:
> Now that all uses for the ctrl_*() printk wrappers are removed from
> files and replaces with pci_*() or pr_*() printk wrappers, remove the
> unused macro definitions. In addition to that, remove the MY_NAME macro.
> extern bool
v6:
- Add a new patch 1 to fix an existing rwsem bug that allows both
readers and writer to become rwsem owners simultaneously.
- Fix a missed wakeup bug (in patch 9) of the v5 series.
- Fix boot up hang problem on some kernel configurations caused
by the patch that merge owner into
The owner field in the rw_semaphore structure is used primarily for
optimistic spinning. However, identifying the rwsem owner can also be
helpful in debugging as well as tracing locking related issues when
analyzing crash dump. The owner field may also store state information
that can be important
When the front of the wait queue is a reader, other readers
immediately following the first reader will also be woken up at the
same time. However, if there is a writer in between. Those readers
behind the writer will not be woken up.
Because of optimistic spinning, the lock acquisition order is n
Because of writer lock stealing, it is possible that a constant
stream of incoming writers will cause a waiting writer or reader to
wait indefinitely leading to lock starvation.
This patch implements a lock handoff mechanism to disable lock stealing
and force lock handoff to the first waiter or wa
This patch enables readers to optimistically spin on a
rwsem when it is owned by a writer instead of going to sleep
directly. The rwsem_can_spin_on_owner() function is extracted
out of rwsem_optimistic_spin() and is called directly by
__rwsem_down_read_failed_common() and __rwsem_down_write_failed
When the rwsem is owned by reader, writers stop optimistic spinning
simply because there is no easy way to figure out if all the readers
are actively running or not. However, there are scenarios where
the readers are unlikely to sleep and optimistic spinning can help
performance.
This patch provid
Reader optimistic spinning is helpful when the reader critical section
is short and there aren't that many readers around. It makes readers
relatively more preferred than writers. When a writer times out spinning
on a reader-owned lock and set the nospinnable bits, there are two main
reasons for th
On 64-bit architectures, each rwsem writer will have its unique lock
word for acquiring the lock. Right now, the writer code recomputes the
lock word every time it tries to acquire the lock. This is a waste of
time. The lock word is now cached and reused when it is needed.
When CONFIG_RWSEM_OWNER_
After merging all the relevant rwsem code into one single file, there
are a number of optimizations and cleanups that can be done:
1) Remove all the EXPORT_SYMBOL() calls for functions that are not
accessed elsewhere.
2) Remove all the __visible tags as none of the functions will be
call
During my rwsem testing, it was found that after a down_read(), the
reader count may occasionally become 0 or even negative. Consequently,
a writer may steal the lock at that time and execute with the reader
in parallel thus breaking the mutual exclusion guarantee of the write
lock. In other words,
Bit 1 of sem->owner (RWSEM_ANONYMOUSLY_OWNED) is used to designate an
anonymous owner - readers or an anonymous writer. The setting of this
anonymous bit is used as an indicator that optimistic spinning cannot
be done on this rwsem.
With the upcoming reader optimistic spinning patches, a reader-ow
The upper bits of the count field is used as reader count. When
sufficient number of active readers are present, the most significant
bit will be set and the count becomes negative. If the number of active
readers keep on piling up, we may eventually overflow the reader counts.
This is not likely t
With separate count and owner, there are timing windows where the two
values are inconsistent. That can cause problem when trying to figure
out the exact state of the rwsem. For instance, a RT task will stop
optimistic spinning if the lock is acquired by a writer but the owner
field isn't set yet.
With the use of wake_q, we can do task wakeups without holding the
wait_lock. There is one exception in the rwsem code, though. It is
when the writer in the slowpath detects that there are waiters ahead
but the rwsem is not held by a writer. This can lead to a long wait_lock
hold time especially wh
This patch modifies rwsem_spin_on_owner() to return four possible
values to better reflect the state of lock holder which enables us to
make a better decision of what to do next.
Signed-off-by: Waiman Long
---
kernel/locking/rwsem.c | 65 ++
1 file changed
An RT task can do optimistic spinning only if the lock holder is
actually running. If the state of the lock holder isn't known, there
is a possibility that high priority of the RT task may block forward
progress of the lock holder if it happens to reside on the same CPU.
This will lead to deadlock.
It is very unlikely that successive preemption at the middle of
down_read's inc-check-dec sequence will cause the reader count to
overflow, For absolute correctness, however, we still need to prevent
that possibility from happening. So preemption will be disabled during
the down_read*() call.
For
Before combining owner and count, we are adding two new helpers for
accessing the owner value in the rwsem.
1) struct task_struct *rwsem_get_owner(struct rw_semaphore *sem)
2) bool is_rwsem_reader_owned(struct rw_semaphore *sem)
Signed-off-by: Waiman Long
---
kernel/locking/rwsem.c | 41 +
The current way of using various reader, writer and waiting biases
in the rwsem code are confusing and hard to understand. I have to
reread the rwsem count guide in the rwsem-xadd.c file from time to
time to remind myself how this whole thing works. It also makes the
rwsem code harder to be optimiz
Now we only have one implementation of rwsem. Even though we still use
xadd to handle reader locking, we use cmpxchg for writer instead. So
the filename rwsem-xadd.c is not strictly correct. Also no one outside
of the rwsem code need to know the internal implementation other than
function prototype
With the commit 59aabfc7e959 ("locking/rwsem: Reduce spinlock contention
in wakeup after up_read()/up_write()"), the rwsem_wake() forgoes doing
a wakeup if the wait_lock cannot be directly acquired and an optimistic
spinning locker is present. This can help performance by avoiding
spinning on the
On Sat, Apr 27, 2019 at 08:29:32PM -0700, Yury Norov wrote:
> Introduce BITS_TO_U64, BITS_TO_U32 and BITS_TO_BYTES as they are handy
> in the following changes (BITS_TO_U32 specifically). Sync tools/
> version of the macros with the kernel implementation.
AFAICS you basically reimplement them for
On Sat, Apr 27, 2019 at 08:29:31PM -0700, Yury Norov wrote:
> New function works like strchrnul() with a length limited strings.
The prototype better to be consistent with strchrnul() and memchr(), i.e.
the size parameter to go last.
--
With Best Regards,
Andy Shevchenko
On 4/28/19 11:57 AM, Waiman Long wrote:
> During my rwsem testing, it was found that after a down_read(), the
> reader count may occasionally become 0 or even negative. Consequently,
> a writer may steal the lock at that time and execute with the reader
> in parallel thus breaking the mutual exclus
On Sun, 2019-04-28 at 16:52 +0100, Al Viro wrote:
> On Sun, Apr 28, 2019 at 11:47:58AM -0400, Jeff Layton wrote:
>
> > We could stick that in ceph_dentry_info (->d_fsdata). We have a flags
> > field in there already.
>
> Yes, but... You have it freed in ->d_release(), AFAICS, and without
> any d
On Sun, Apr 28, 2019 at 09:40:00AM +1000, Tobin C. Harding wrote:
> Currently error return from kobject_init_and_add() is not followed by a
> call to kobject_put(). This means there is a memory leak.
>
> Add call to kobject_put() in error path of kobject_init_and_add().
>
> Signed-off-by: Tobin
On Sun, Apr 28, 2019 at 11:19:57AM +1000, Tobin C. Harding wrote:
> On Sat, Apr 27, 2019 at 09:28:09PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Apr 27, 2019 at 06:13:30PM +1000, Tobin C. Harding wrote:
> > > (Note at bottom on reasons for 'To' list 'Cc' list)
> > >
> > > Hi,
> > >
> > > kobje
On Sun, Apr 28, 2019 at 10:48:10AM +1000, Tobin C. Harding wrote:
> There is currently some confusion on how to wind back
> kobject_init_and_add() during the error paths in code that uses this
> function.
>
> Add documentation to kobject_add() and kobject_del() to help clarify the
> usage.
>
> Si
Thanks for cc'ing me...
On 04/26, Christian Brauner wrote:
>
> On Thu, Apr 25, 2019 at 03:00:09PM -0400, Joel Fernandes (Google) wrote:
> > +static unsigned int pidfd_poll(struct file *file, struct poll_table_struct
> > *pts)
> > +{
> > + struct task_struct *task;
> > + struct pid *pid;
> > +
On Sun, Apr 28, 2019 at 04:52:16PM +0100, Al Viro wrote:
> On Sun, Apr 28, 2019 at 11:47:58AM -0400, Jeff Layton wrote:
>
> > We could stick that in ceph_dentry_info (->d_fsdata). We have a flags
> > field in there already.
>
> Yes, but... You have it freed in ->d_release(), AFAICS, and without
On Sun, Apr 28, 2019 at 4:52 AM Jason Gunthorpe wrote:
>
> Nothing particularly special here. There is a small merge conflict
> with Adrea's mm_still_valid patches which is resolved as below:
I still don't understand *why* you play the crazy VM games to begin with.
What's wrong with just returni
On Sat, Apr 27, 2019 at 08:29:34PM -0700, Yury Norov wrote:
> bitmap_parse() is ineffective and full of opaque variables and opencoded
> parts. It leads to hard understanding of it. This rework includes:
> - remove bitmap_shift_left() call from the cycle. Now it makes the
>complexity of the al
from the commit "mtd: maps: Rename physmap_of_{versatile, gemini} into
physmap-{versatile, gemini}"
physmap_of_versatile.c renamed as physmap-versatile.c
updating the same in MAINTAINERS file.
Signed-off-by: Hariprasad Kelam
---
MAINTAINERS | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[ Added Linus ]
On Sat, 27 Apr 2019 12:26:57 +0200
Peter Zijlstra wrote:
> On Sat, Apr 27, 2019 at 12:06:38PM +0200, Nicolai Stange wrote:
> > ftrace_int3_handler()'s context is different from the interrupted call
> > instruction's one, obviously. In order to be able to emulate the call
> > wi
On Sun, Apr 28, 2019 at 8:58 AM Waiman Long wrote:
>
> +
> + /* 2nd pass */
> + list_for_each_entry(waiter, &wlist, list) {
This is not safe, as far as I can tell.
As this loop walks the list, you do that
smp_store_release(&waiter->task, NULL);
and that very action
Hi, Long
I guess you should mean "flow control", not "follow control".
And the commit subject should be swapped between 1/2 and 2/2,
otherwise, the subject is inconsistent with its own content.
Sean
On Thu, Apr 25, 2019 at 1:41 AM Long Cheng wrote:
>
> Add SW and HW follow control functi
> On Apr 27, 2019, at 3:06 AM, Nicolai Stange wrote:
>
> Before actually rewriting an insn, x86' DYNAMIC_FTRACE implementation
> places an int3 breakpoint on it. Currently, ftrace_int3_handler() simply
> treats the insn in question as nop and advances %rip past it.
How does this not crash all
On Sun, 28 Apr 2019 10:41:10 -0700
Andy Lutomirski wrote:
> > Note that at any given point
> > in time, there can be at most four such call insn emulations pending:
> > namely at most one per "process", "irq", "softirq" and "nmi" context.
> >
>
> That’s quite an assumption. I think your list
On Sun, Apr 28, 2019 at 10:41 AM Linus Torvalds
wrote:
>
> It's the *first* loop that you could play games with, because you hold
> the lock, and the list is stable during that loop. So the *first* loop
> could just walk the list, and then do one list splitting operation
> instead of doing that "l
The pull request you sent on Sat, 27 Apr 2019 15:38:54 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/25cce03b1d06e4b742f6dafdda2f4d80c13bdc18
Thank you!
--
Deet-doot-dot, I am a bot.
ht
The pull request you sent on Sun, 28 Apr 2019 11:52:12 +:
> git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git tags/for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/14f974d7f0f1f93d8c35f496ae774ba0f1b3389a
Thank you!
--
Deet-doot-dot, I am a bot
> On Apr 28, 2019, at 10:51 AM, Steven Rostedt wrote:
>
> On Sun, 28 Apr 2019 10:41:10 -0700
> Andy Lutomirski wrote:
>
>
>>> Note that at any given point
>>> in time, there can be at most four such call insn emulations pending:
>>> namely at most one per "process", "irq", "softirq" and "nm
On Wed, Apr 17, 2019 at 5:12 PM Vlastimil Babka wrote:
>
> On 4/6/19 7:59 AM, Pankaj Suryawanshi wrote:
> > Hello ,
> >
> > shrink_page_list() returns , number of pages reclaimed, when pages is
> > unevictable it returns VM_BUG_ON_PAGE(PageLRU(page) ||
> > PageUnevicatble(page),page);
> >
> > We c
The locking scheme for ISSI devices is based on stm_lock mechanism.
The is25x devices have 4 bits for selecting the range of blocks to
be locked for write.
The current implementation, blocks entire 512 blocks of flash memory.
Signed-off-by: Sagar Shrikant Kadam
---
drivers/mtd/spi-nor/spi-
Update spi_nor_id tablet for is25wp256 (32MB)device from ISSI,
present on HiFive Unleashed dev board (Rev: A00).
Set method to enable quad mode for ISSI device in flash parameters
table.
Signed-off-by: Sagar Shrikant Kadam
---
drivers/mtd/spi-nor/spi-nor.c | 10 +-
include/linux/mtd/spi
Nor device (is25wp256 mounted on HiFive unleashed Rev A00 board) from ISSI
have memory blocks guarded by block protection bits BP[0,1,2,3].
Clearing block protection bits,unlocks the flash memory regions
The unlock scheme is registered during nor scans.
Signed-off-by: Sagar Shrikant Kadam
---
d
The patch set is tested on HiFive Unleashed board and is based on mainline
kernel v 5.1-rc5. Its intended to add support for 32 MB spi-nor flash
mounted on the board. Memory Device supports 4/32/and 64 KB sectors size.
The device id table is updated accordingly.
Flash parameter table for ISSI devi
syzbot has found a reproducer for the following crash on:
HEAD commit:037904a2 Merge branch 'x86-urgent-for-linus' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=135ff034a0
kernel config: https://syzkaller.appspot.com/x/.config?x=a42d11
On Sun, Apr 28, 2019 at 07:04:00PM +0300, Andy Shevchenko wrote:
> On Sat, Apr 27, 2019 at 08:29:31PM -0700, Yury Norov wrote:
> > New function works like strchrnul() with a length limited strings.
>
> The prototype better to be consistent with strchrnul() and memchr(), i.e.
> the size parameter t
1 - 100 of 243 matches
Mail list logo
