Hi Pavel.
On 09/14/2018 11:42 PM, Pavel Machek wrote:
> Hi!
>
>>> You may want to learn more about device tree and/or talk to the device
>>> tree maintainers. This is an old article. https://lwn.net/Articles/561462/
>>
>> The article title is "Device trees as ABI". A device tree is defined
>> in
Hi Pavel.
On 09/14/2018 11:42 PM, Pavel Machek wrote:
> Hi!
>
>>> You may want to learn more about device tree and/or talk to the device
>>> tree maintainers. This is an old article. https://lwn.net/Articles/561462/
>>
>> The article title is "Device trees as ABI". A device tree is defined
>> in
внимания;
Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных
администратором, который в настоящее время работает на 10.9GB, Вы не сможете
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый
ящик почты. Чтобы восстановить работоспособность
внимания;
Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных
администратором, который в настоящее время работает на 10.9GB, Вы не сможете
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый
ящик почты. Чтобы восстановить работоспособность
export nvme disk name, queue id, sq_head, sq_tail to trace event
usage example:
go to the event directory:
cd /sys/kernel/debug/tracing/events/nvme/nvme_sq
filter by disk name:
echo 'disk=="nvme1n1"' > filter
enable the event:
echo 1 > enable
check results from trace_pipe:
cat
export nvme disk name, queue id, sq_head, sq_tail to trace event
usage example:
go to the event directory:
cd /sys/kernel/debug/tracing/events/nvme/nvme_sq
filter by disk name:
echo 'disk=="nvme1n1"' > filter
enable the event:
echo 1 > enable
check results from trace_pipe:
cat
внимания;
Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных
администратором, который в настоящее время работает на 10.9GB, Вы не сможете
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый
ящик почты. Чтобы восстановить работоспособность
внимания;
Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных
администратором, который в настоящее время работает на 10.9GB, Вы не сможете
отправить или получить новую почту, пока вы повторно не проверить ваш почтовый
ящик почты. Чтобы восстановить работоспособность
Commit-ID: 6a1cac56f41f9ea94e440dfcc1cac44b41a1b194
Gitweb: https://git.kernel.org/tip/6a1cac56f41f9ea94e440dfcc1cac44b41a1b194
Author: Brijesh Singh
AuthorDate: Fri, 14 Sep 2018 08:45:59 -0500
Committer: Thomas Gleixner
CommitDate: Sat, 15 Sep 2018 20:48:46 +0200
x86/kvm: Use
Commit-ID: b3f0907c71e006e12fde74ea9a745b6096b6f90f
Gitweb: https://git.kernel.org/tip/b3f0907c71e006e12fde74ea9a745b6096b6f90f
Author: Brijesh Singh
AuthorDate: Fri, 14 Sep 2018 08:45:58 -0500
Committer: Thomas Gleixner
CommitDate: Sat, 15 Sep 2018 20:48:45 +0200
x86/mm: Add
Commit-ID: 6a1cac56f41f9ea94e440dfcc1cac44b41a1b194
Gitweb: https://git.kernel.org/tip/6a1cac56f41f9ea94e440dfcc1cac44b41a1b194
Author: Brijesh Singh
AuthorDate: Fri, 14 Sep 2018 08:45:59 -0500
Committer: Thomas Gleixner
CommitDate: Sat, 15 Sep 2018 20:48:46 +0200
x86/kvm: Use
Commit-ID: b3f0907c71e006e12fde74ea9a745b6096b6f90f
Gitweb: https://git.kernel.org/tip/b3f0907c71e006e12fde74ea9a745b6096b6f90f
Author: Brijesh Singh
AuthorDate: Fri, 14 Sep 2018 08:45:58 -0500
Committer: Thomas Gleixner
CommitDate: Sat, 15 Sep 2018 20:48:45 +0200
x86/mm: Add
On Fri, Sep 14, 2018 at 09:38:52PM +0200, Arnd Bergmann wrote:
> On Fri, Sep 14, 2018 at 8:17 PM gregkh wrote:
> >
> > On Fri, Sep 14, 2018 at 05:15:52PM +0200, Arnd Bergmann wrote:
> > > On Thu, Sep 13, 2018 at 4:40 AM Al Viro wrote:
>
> > > + case TCSETX:
> > > + case TCSETXF:
> >
On Fri, Sep 14, 2018 at 09:38:52PM +0200, Arnd Bergmann wrote:
> On Fri, Sep 14, 2018 at 8:17 PM gregkh wrote:
> >
> > On Fri, Sep 14, 2018 at 05:15:52PM +0200, Arnd Bergmann wrote:
> > > On Thu, Sep 13, 2018 at 4:40 AM Al Viro wrote:
>
> > > + case TCSETX:
> > > + case TCSETXF:
> >
Am Samstag, 15. September 2018, 11:03:57 CEST schrieb agajjar:
> Hi Heiko,
>
> On 9/14/2018 11:23 PM, Heiko Stuebner wrote:
> > Hi Akash,
> >
> > Am Freitag, 14. September 2018, 14:09:09 CEST schrieb Akash Gajjar:
> >> Rockpro64 board is a rockchip RK3399 based board from pine64.org.
> >> This
Am Samstag, 15. September 2018, 11:03:57 CEST schrieb agajjar:
> Hi Heiko,
>
> On 9/14/2018 11:23 PM, Heiko Stuebner wrote:
> > Hi Akash,
> >
> > Am Freitag, 14. September 2018, 14:09:09 CEST schrieb Akash Gajjar:
> >> Rockpro64 board is a rockchip RK3399 based board from pine64.org.
> >> This
On Fri, Aug 3, 2018 at 9:47 PM, Masahiro Yamada
wrote:
> Randy Dunlap reports UML occasionally fails to build with -j and
> O= options.
With v4.19-rc2 I'm still seeing a failure (for any parallelism) under ARCH=um
$ make -j8 ARCH=um O=/tmp/foo
...
/home/kees/src/linux-build/um/Makefile:1185:
On Fri, Aug 3, 2018 at 9:47 PM, Masahiro Yamada
wrote:
> Randy Dunlap reports UML occasionally fails to build with -j and
> O= options.
With v4.19-rc2 I'm still seeing a failure (for any parallelism) under ARCH=um
$ make -j8 ARCH=um O=/tmp/foo
...
/home/kees/src/linux-build/um/Makefile:1185:
On Sat, 15 Sep 2018, Rich Felker wrote:
> On Sat, Sep 15, 2018 at 05:34:24PM +0200, Thomas Gleixner wrote:
> > By doing that you paper over a non functional fixup which could cause other
> > really hard to decode runtime failures. If that fails there is a bug
> > somewhere else and that runtime
On Sat, 15 Sep 2018, Rich Felker wrote:
> On Sat, Sep 15, 2018 at 05:34:24PM +0200, Thomas Gleixner wrote:
> > By doing that you paper over a non functional fixup which could cause other
> > really hard to decode runtime failures. If that fails there is a bug
> > somewhere else and that runtime
Urgent Attention Needed.
We have been trying to reach out to you severally in respect to your
compensation scheme funds worth $500,000 provided by the federal
government powered by the world bank group, but due to unclassified
reasons our mails to you have been bounced and our server alerted
Urgent Attention Needed.
We have been trying to reach out to you severally in respect to your
compensation scheme funds worth $500,000 provided by the federal
government powered by the world bank group, but due to unclassified
reasons our mails to you have been bounced and our server alerted
On Sat, Sep 15, 2018 at 06:54:30PM +0800, YueHaibing wrote:
> Drop call to of_match_device, which is subsumed by the subsequent
> call to of_device_get_match_data. The code becomes simpler, and a
> temporary variable can be dropped.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing
On Sat, Sep 15, 2018 at 06:54:30PM +0800, YueHaibing wrote:
> Drop call to of_match_device, which is subsumed by the subsequent
> call to of_device_get_match_data. The code becomes simpler, and a
> temporary variable can be dropped.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing
Document device tree bindings for ROHM BH1750 ambient light sensor driver.
Signed-off-by: ryang
---
.../devicetree/bindings/iio/light/bh1750.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/bh1750.txt
diff --git
Document device tree bindings for ROHM BH1750 ambient light sensor driver.
Signed-off-by: ryang
---
.../devicetree/bindings/iio/light/bh1750.txt | 18 ++
1 file changed, 18 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/light/bh1750.txt
diff --git
Add device tree support for ROHM BH1750 series ambient light sensors.
Signed-off-by: ryang
---
drivers/iio/light/bh1750.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
index a814828e69f5..50b599abb383 100644
---
Add device tree support for ROHM BH1750 series ambient light sensors.
Signed-off-by: ryang
---
drivers/iio/light/bh1750.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
index a814828e69f5..50b599abb383 100644
---
On Sun, 16 Sep 2018, Feng Tang wrote:
> I have tried to change some header files incluing fixmap.h/apicdef.h/
> vsyscall.h, and most of the .c files compile fine now, but I can not
> use the "__end_of_permanent_fixed_addresses" in head_64.S as it is a
> enum type, and could not be recognized by
On Sun, 16 Sep 2018, Feng Tang wrote:
> I have tried to change some header files incluing fixmap.h/apicdef.h/
> vsyscall.h, and most of the .c files compile fine now, but I can not
> use the "__end_of_permanent_fixed_addresses" in head_64.S as it is a
> enum type, and could not be recognized by
On 2018/09/15 11:33, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 11da3a7f84f1 Linux 4.19-rc3
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=141ffbca40
> kernel config:
On 2018/09/15 11:33, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 11da3a7f84f1 Linux 4.19-rc3
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=141ffbca40
> kernel config:
Hi Sasha,
Sasha Levin wrote on Sat, 15 Sep 2018
01:29:55 +:
> From: Boris Brezillon
>
> [ Upstream commit 8f3931ed975e1d775b87ce85d65ecacd54138359 ]
>
> We want to allow this driver to be selected when COMPILE_TEST=y, this
> means the driver can be compiled for any arch, including MIPS.
Hi Sasha,
Sasha Levin wrote on Sat, 15 Sep 2018
01:29:55 +:
> From: Boris Brezillon
>
> [ Upstream commit 8f3931ed975e1d775b87ce85d65ecacd54138359 ]
>
> We want to allow this driver to be selected when COMPILE_TEST=y, this
> means the driver can be compiled for any arch, including MIPS.
On Sat, Sep 15, 2018 at 12:15:54PM -0400, Rich Felker wrote:
> On Sat, Sep 15, 2018 at 05:34:24PM +0200, Thomas Gleixner wrote:
> > On Thu, 30 Aug 2018, Rich Felker wrote:
> > > On Thu, Aug 30, 2018 at 11:19:58AM +0200, Thomas Gleixner wrote:
> > > > On Wed, 29 Aug 2018, Rich Felker wrote:
> > > >
On Sat, Sep 15, 2018 at 12:15:54PM -0400, Rich Felker wrote:
> On Sat, Sep 15, 2018 at 05:34:24PM +0200, Thomas Gleixner wrote:
> > On Thu, 30 Aug 2018, Rich Felker wrote:
> > > On Thu, Aug 30, 2018 at 11:19:58AM +0200, Thomas Gleixner wrote:
> > > > On Wed, 29 Aug 2018, Rich Felker wrote:
> > > >
Hi Thomas,
On Sat, Sep 15, 2018 at 12:29:50PM +0200, Thomas Gleixner wrote:
> On Tue, 11 Sep 2018, Feng Tang wrote:
> > Thanks for the suggestion, and I have 2 patches: one adds a build warning,
> >
> > the other prepares fixmap page table on demand and doesn't need warning.
>
> The latter
Hi Thomas,
On Sat, Sep 15, 2018 at 12:29:50PM +0200, Thomas Gleixner wrote:
> On Tue, 11 Sep 2018, Feng Tang wrote:
> > Thanks for the suggestion, and I have 2 patches: one adds a build warning,
> >
> > the other prepares fixmap page table on demand and doesn't need warning.
>
> The latter
In preparation for runtime randomization of the zone lists, take all
(well, most of) the list_*() functions in the buddy allocator and put
them in helper functions. Provide a common control point for injecting
additional behavior when freeing pages.
Cc: Michal Hocko
Cc: Dave Hansen
In preparation for runtime randomization of the zone lists, take all
(well, most of) the list_*() functions in the buddy allocator and put
them in helper functions. Provide a common control point for injecting
additional behavior when freeing pages.
Cc: Michal Hocko
Cc: Dave Hansen
On 09/14, Jeff Layton wrote:
>
> POSIX mandates that open fds and their associated file locks should be
> preserved across an execve. This works, unless the process is
> multithreaded at the time that execve is called.
>
> In that case, we'll end up unsharing the files_struct but the locks will
>
On 09/14, Jeff Layton wrote:
>
> POSIX mandates that open fds and their associated file locks should be
> preserved across an execve. This works, unless the process is
> multithreaded at the time that execve is called.
>
> In that case, we'll end up unsharing the files_struct but the locks will
>
Data exfiltration attacks via speculative execution and
return-oriented-programming attacks rely on the ability to infer the
location of sensitive data objects. The kernel page allocator, has
predictable first-in-first-out behavior for physical pages. Pages are
freed in physical address order when
When freeing a page with an order >= shuffle_page_order randomly select
the front or back of the list for insertion.
While the mm tries to defragment physical pages into huge pages this can
tend to make the page allocator more predictable over time. Inject the
front-back randomness to preserve
Data exfiltration attacks via speculative execution and
return-oriented-programming attacks rely on the ability to infer the
location of sensitive data objects. The kernel page allocator, has
predictable first-in-first-out behavior for physical pages. Pages are
freed in physical address order when
When freeing a page with an order >= shuffle_page_order randomly select
the front or back of the list for insertion.
While the mm tries to defragment physical pages into huge pages this can
tend to make the page allocator more predictable over time. Inject the
front-back randomness to preserve
Some data exfiltration and return-oriented-programming attacks rely on
the ability to infer the location of sensitive data objects. The kernel
page allocator, especially early in system boot, has predictable
first-in-first out behavior for physical pages. Pages are freed in
physical address order
Some data exfiltration and return-oriented-programming attacks rely on
the ability to infer the location of sensitive data objects. The kernel
page allocator, especially early in system boot, has predictable
first-in-first out behavior for physical pages. Pages are freed in
physical address order
On Sat, Sep 15, 2018 at 05:34:24PM +0200, Thomas Gleixner wrote:
> On Thu, 30 Aug 2018, Rich Felker wrote:
> > On Thu, Aug 30, 2018 at 11:19:58AM +0200, Thomas Gleixner wrote:
> > > On Wed, 29 Aug 2018, Rich Felker wrote:
> > >
> > > > I just spent a number of hours helping someone track down a
On Sat, Sep 15, 2018 at 05:34:24PM +0200, Thomas Gleixner wrote:
> On Thu, 30 Aug 2018, Rich Felker wrote:
> > On Thu, Aug 30, 2018 at 11:19:58AM +0200, Thomas Gleixner wrote:
> > > On Wed, 29 Aug 2018, Rich Felker wrote:
> > >
> > > > I just spent a number of hours helping someone track down a
On 09/14, Jeff Layton wrote:
>
> Currently, we have a single refcount variable inside the files_struct.
> When we go to unshare the files_struct, we check this counter and if
> it's elevated, then we allocate a new files_struct instead of just
> repurposing the old one, under the assumption that
On 09/14, Jeff Layton wrote:
>
> Currently, we have a single refcount variable inside the files_struct.
> When we go to unshare the files_struct, we check this counter and if
> it's elevated, then we allocate a new files_struct instead of just
> repurposing the old one, under the assumption that
On Thu, 30 Aug 2018, Rich Felker wrote:
> On Thu, Aug 30, 2018 at 11:19:58AM +0200, Thomas Gleixner wrote:
> > On Wed, 29 Aug 2018, Rich Felker wrote:
> >
> > > I just spent a number of hours helping someone track down a bug that
> > > looks like it's some kind of futex_cmpxchg_enabled detection
On Thu, 30 Aug 2018, Rich Felker wrote:
> On Thu, Aug 30, 2018 at 11:19:58AM +0200, Thomas Gleixner wrote:
> > On Wed, 29 Aug 2018, Rich Felker wrote:
> >
> > > I just spent a number of hours helping someone track down a bug that
> > > looks like it's some kind of futex_cmpxchg_enabled detection
On Thu, 6 Sep 2018, Thomas Gleixner wrote:
> On Wed, 5 Sep 2018, Rick Ratzel wrote:
>
> > We're looking for suggestions on how best to proceed with a new change
> > that ideally both supports the use case described above, as well as
> > addresses the symptoms brought up in the initial commit
On Thu, 6 Sep 2018, Thomas Gleixner wrote:
> On Wed, 5 Sep 2018, Rick Ratzel wrote:
>
> > We're looking for suggestions on how best to proceed with a new change
> > that ideally both supports the use case described above, as well as
> > addresses the symptoms brought up in the initial commit
Thx for the review, that's very helpful.
On Wed, Sep 12, 2018 at 05:55:14PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 09:24:45PM +0800, Guo Ren wrote:
>
> > +#define ATOMIC_OP(op, c_op)
> > \
> > +static inline void atomic_##op(int i,
Thx for the review, that's very helpful.
On Wed, Sep 12, 2018 at 05:55:14PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 12, 2018 at 09:24:45PM +0800, Guo Ren wrote:
>
> > +#define ATOMIC_OP(op, c_op)
> > \
> > +static inline void atomic_##op(int i,
On Sat, 15 Sep 2018 at 14:30, Ingo Molnar wrote:
>
>
> * Vincent Guittot wrote:
>
> > Hi Ingo,
> >
> > On Sat, 15 Sep 2018 at 13:47, Ingo Molnar wrote:
> > >
> > >
> > > * tip-bot for Vincent Guittot wrote:
> > >
> > > > Commit-ID: 2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> > > > Gitweb:
On Sat, 15 Sep 2018 at 14:30, Ingo Molnar wrote:
>
>
> * Vincent Guittot wrote:
>
> > Hi Ingo,
> >
> > On Sat, 15 Sep 2018 at 13:47, Ingo Molnar wrote:
> > >
> > >
> > > * tip-bot for Vincent Guittot wrote:
> > >
> > > > Commit-ID: 2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> > > > Gitweb:
On Fri, Sep 14, 2018 at 12:13:38PM +0200, Romain Izard wrote:
> When using watchdog_init_timeout to update the default timeout value,
> an error means that there is no "timeout-sec" in the relevant device
> tree node.
>
> This should not prevent binding of the driver to the device.
>
> Fixes:
On Fri, Sep 14, 2018 at 12:13:38PM +0200, Romain Izard wrote:
> When using watchdog_init_timeout to update the default timeout value,
> an error means that there is no "timeout-sec" in the relevant device
> tree node.
>
> This should not prevent binding of the driver to the device.
>
> Fixes:
Is this commit queued up for inclusion into the stable tree?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/of/base.c?h=next-20180913=e54192b48da75f025ae4b277925eaf6aca1d13bd
Applying the patch on top of v4.18.8 fixes the booting problem for me.
The contents of
Is this commit queued up for inclusion into the stable tree?
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/of/base.c?h=next-20180913=e54192b48da75f025ae4b277925eaf6aca1d13bd
Applying the patch on top of v4.18.8 fixes the booting problem for me.
The contents of
On Mon, Jan 13, 2014 at 04:11:38PM -0800, Dave Hansen wrote:
>
> From: Dave Hansen
>
> Right now, there is a "Enable paravirtualization code" option in
> the "Processor Features" menu, which means Xen. There is also a
> group of host-side paravirtualization options specific to KVM
> under the
On Mon, Jan 13, 2014 at 04:11:38PM -0800, Dave Hansen wrote:
>
> From: Dave Hansen
>
> Right now, there is a "Enable paravirtualization code" option in
> the "Processor Features" menu, which means Xen. There is also a
> group of host-side paravirtualization options specific to KVM
> under the
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
# HEAD: 002b87d2aace62b4f3841c3aa43309d2380092be x86/APM: Fix build warning
when PROC_FS is not enabled
Misc fixes:
- EFI crash fix
- Xen
Linus,
Please pull the latest x86-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
x86-urgent-for-linus
# HEAD: 002b87d2aace62b4f3841c3aa43309d2380092be x86/APM: Fix build warning
when PROC_FS is not enabled
Misc fixes:
- EFI crash fix
- Xen
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 882a78a9f39f5535b209b4aa0a1741e35b8c67fb sched/fair: Fix kernel-doc
notation warning
Misc fixes: various scheduler metrics corner
Linus,
Please pull the latest sched-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-urgent-for-linus
# HEAD: 882a78a9f39f5535b209b4aa0a1741e35b8c67fb sched/fair: Fix kernel-doc
notation warning
Misc fixes: various scheduler metrics corner
This patch removes do {} while (0) loop for single statement macros.
Issue found by checkpatch.
Signed-off-by: Nishad Kamdar
---
drivers/staging/mt7621-mmc/sd.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/mt7621-mmc/sd.c
This patch removes do {} while (0) loop for single statement macros.
Issue found by checkpatch.
Signed-off-by: Nishad Kamdar
---
drivers/staging/mt7621-mmc/sd.c | 28 +++-
1 file changed, 7 insertions(+), 21 deletions(-)
diff --git a/drivers/staging/mt7621-mmc/sd.c
on Thu, Sep 13, 2018 at 8:32 PM Amir Goldstein wrote:
>On Thu, Sep 13, 2018 at 2:25 PM Nixiaoming wrote:
>>
>> On Tue, Sep 11, 2018 at 11:12 PM Amir Goldstein wrote:
>> >On Tue, Sep 11, 2018 at 9:51 AM Nixiaoming wrote:
>> >>
>> >> Inotify api cannot display information about users and
on Thu, Sep 13, 2018 at 8:32 PM Amir Goldstein wrote:
>On Thu, Sep 13, 2018 at 2:25 PM Nixiaoming wrote:
>>
>> On Tue, Sep 11, 2018 at 11:12 PM Amir Goldstein wrote:
>> >On Tue, Sep 11, 2018 at 9:51 AM Nixiaoming wrote:
>> >>
>> >> Inotify api cannot display information about users and
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: cb48b6a26cace226d8b299a48c73e808eb0c4f61 Merge tag
'perf-urgent-for-mingo-4.19-20180912' of
Linus,
Please pull the latest perf-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
perf-urgent-for-linus
# HEAD: cb48b6a26cace226d8b299a48c73e808eb0c4f61 Merge tag
'perf-urgent-for-mingo-4.19-20180912' of
The whole static protection magic is silently fixing up anything which is
handed in. That's just wrong. The offending call sites need to be fixed.
Add a debug mechanism which emits a warning if a requested mapping needs to be
fixed up. The DETECT debug mechanism is really not meant to be enabled
The whole static protection magic is silently fixing up anything which is
handed in. That's just wrong. The offending call sites need to be fixed.
Add a debug mechanism which emits a warning if a requested mapping needs to be
fixed up. The DETECT debug mechanism is really not meant to be enabled
On Fri, Sep 14, 2018 at 12:53:00PM -0700, Paul Burton wrote:
> Hi Mike,
>
> On Mon, Sep 10, 2018 at 12:23:18PM +0300, Mike Rapoport wrote:
> > MIPS already has memblock support and all the memory is already registered
> > with it.
> >
> > This patch replaces bootmem memory reservations with
On Fri, Sep 14, 2018 at 12:53:00PM -0700, Paul Burton wrote:
> Hi Mike,
>
> On Mon, Sep 10, 2018 at 12:23:18PM +0300, Mike Rapoport wrote:
> > MIPS already has memblock support and all the memory is already registered
> > with it.
> >
> > This patch replaces bootmem memory reservations with
Linus,
Please pull the latest locking-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-for-linus
# HEAD: 0b405c65ad459f5f4d3db1672246172bd19d946d locking/ww_mutex: Fix
spelling mistake "cylic" -> "cyclic"
Misc fixes: liblockdep
Linus,
Please pull the latest locking-urgent-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
locking-urgent-for-linus
# HEAD: 0b405c65ad459f5f4d3db1672246172bd19d946d locking/ww_mutex: Fix
spelling mistake "cylic" -> "cyclic"
Misc fixes: liblockdep
* Vincent Guittot wrote:
> Hi Ingo,
>
> On Sat, 15 Sep 2018 at 13:47, Ingo Molnar wrote:
> >
> >
> > * tip-bot for Vincent Guittot wrote:
> >
> > > Commit-ID: 2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> > > Gitweb:
> > >
* Vincent Guittot wrote:
> Hi Ingo,
>
> On Sat, 15 Sep 2018 at 13:47, Ingo Molnar wrote:
> >
> >
> > * tip-bot for Vincent Guittot wrote:
> >
> > > Commit-ID: 2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> > > Gitweb:
> > >
Hi Ingo,
On Sat, 15 Sep 2018 at 13:47, Ingo Molnar wrote:
>
>
> * tip-bot for Vincent Guittot wrote:
>
> > Commit-ID: 2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> > Gitweb:
> > https://git.kernel.org/tip/2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> > Author: Vincent Guittot
> >
Hi Ingo,
On Sat, 15 Sep 2018 at 13:47, Ingo Molnar wrote:
>
>
> * tip-bot for Vincent Guittot wrote:
>
> > Commit-ID: 2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> > Gitweb:
> > https://git.kernel.org/tip/2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> > Author: Vincent Guittot
> >
Hello Alexey,
On 09/08/2018 01:13:07+0300, Alexey Khoroshilov wrote:
> After moving rtc_register_device() sysfs group is left unremoved
> on the error path.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> Fixes: 236b7187034e ("rtc:
Hello Alexey,
On 09/08/2018 01:13:07+0300, Alexey Khoroshilov wrote:
> After moving rtc_register_device() sysfs group is left unremoved
> on the error path.
>
> Found by Linux Driver Verification project (linuxtesting.org).
>
> Signed-off-by: Alexey Khoroshilov
> Fixes: 236b7187034e ("rtc:
* tip-bot for Vincent Guittot wrote:
> Commit-ID: 2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> Gitweb:
> https://git.kernel.org/tip/2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> Author: Vincent Guittot
> AuthorDate: Thu, 19 Jul 2018 14:00:06 +0200
> Committer: Ingo Molnar
> CommitDate:
* tip-bot for Vincent Guittot wrote:
> Commit-ID: 2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> Gitweb:
> https://git.kernel.org/tip/2e62c4743adc4c7bfcbc1f45118fc7bec58cf30a
> Author: Vincent Guittot
> AuthorDate: Thu, 19 Jul 2018 14:00:06 +0200
> Committer: Ingo Molnar
> CommitDate:
Use rtc_add_group to add the common sysfs group to avoid a possible race
condition.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-isl1208.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
index
Use rtc_add_group to add the common sysfs group to avoid a possible race
condition.
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-isl1208.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/rtc/rtc-isl1208.c b/drivers/rtc/rtc-isl1208.c
index
* Arnd Bergmann wrote:
> diff --git a/arch/x86/include/uapi/asm/elf.h b/arch/x86/include/uapi/asm/elf.h
> new file mode 100644
> index ..a640e1224939
> --- /dev/null
> +++ b/arch/x86/include/uapi/asm/elf.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH
* Arnd Bergmann wrote:
> diff --git a/arch/x86/include/uapi/asm/elf.h b/arch/x86/include/uapi/asm/elf.h
> new file mode 100644
> index ..a640e1224939
> --- /dev/null
> +++ b/arch/x86/include/uapi/asm/elf.h
> @@ -0,0 +1,30 @@
> +/* SPDX-License-Identifier: GPL-2.0 WITH
On 2018-09-15 12:54, YueHaibing wrote:
> Drop call to of_match_device, which is subsumed by the subsequent
> call to of_device_get_match_data. The code becomes simpler, and a
> temporary variable can be dropped.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Peter Rosin
On 2018-09-15 12:54, YueHaibing wrote:
> Drop call to of_match_device, which is subsumed by the subsequent
> call to of_device_get_match_data. The code becomes simpler, and a
> temporary variable can be dropped.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Peter Rosin
On 2018-09-15 12:52, YueHaibing wrote:
> Drop call to of_match_device, which is subsumed by the subsequent
> call to of_device_get_match_data. The code becomes simpler, and a
> temporary variable can be dropped.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Peter Rosin
On 2018-09-15 12:52, YueHaibing wrote:
> Drop call to of_match_device, which is subsumed by the subsequent
> call to of_device_get_match_data. The code becomes simpler, and a
> temporary variable can be dropped.
>
> Found by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Peter Rosin
Ping.
On 2018/7/25 15:07, YueHaibing wrote:
> Sean Wang reported dma_zalloc_coherent doesn't work as expect on his
> armv7,the allocated mem is not zeroed.The reason is __alloc_from_pool
> doesn't honor __GFP_ZERO.
>
> As commit 6829e274a623 ("arm64: dma-mapping: always clear allocated
Ping.
On 2018/7/25 15:07, YueHaibing wrote:
> Sean Wang reported dma_zalloc_coherent doesn't work as expect on his
> armv7,the allocated mem is not zeroed.The reason is __alloc_from_pool
> doesn't honor __GFP_ZERO.
>
> As commit 6829e274a623 ("arm64: dma-mapping: always clear allocated
101 - 200 of 262 matches
Mail list logo
