On Wed, Oct 31, 2018 at 11:22:44AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xfs tree got a conflict in:
>
> Documentation/filesystems/porting
>
> between commit:
>
> 1a16dbaf798c ("Document d_splice_alias() calling conventions for ->lookup()
> users.")
On Wed, Oct 31, 2018 at 11:22:44AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the xfs tree got a conflict in:
>
> Documentation/filesystems/porting
>
> between commit:
>
> 1a16dbaf798c ("Document d_splice_alias() calling conventions for ->lookup()
> users.")
Hi, Randy,
On 五, 2018-10-26 at 20:35 -0700, Randy Dunlap wrote:
> On 10/26/18 2:14 AM, Rafael J. Wysocki wrote:
> >
> > On Monday, October 22, 2018 8:37:25 PM CEST Randy Dunlap wrote:
> > >
> > >
> > > On 8/16/18 2:33 PM, Randy Dunlap wrote:
> > > >
> > > > Hi,
> > > >
> > > > Sorry for the
Hi, Randy,
On 五, 2018-10-26 at 20:35 -0700, Randy Dunlap wrote:
> On 10/26/18 2:14 AM, Rafael J. Wysocki wrote:
> >
> > On Monday, October 22, 2018 8:37:25 PM CEST Randy Dunlap wrote:
> > >
> > >
> > > On 8/16/18 2:33 PM, Randy Dunlap wrote:
> > > >
> > > > Hi,
> > > >
> > > > Sorry for the
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
Hi Rakesh,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 310c7585e8300ddc46211df0757c11e4299ec482
commit: 6bae5ea9498926440ffc883f3dbceb0adc65e492 ASoC: hdac_hda: add asoc
extension for legacy HDA codec drivers
On Tue, Oct 30, 2018 at 04:50:39PM -0700, Paul E. McKenney wrote:
> On Sun, Oct 28, 2018 at 06:16:31PM -0700, Joel Fernandes wrote:
> > On Sun, Oct 28, 2018 at 10:21:42AM -0700, Paul E. McKenney wrote:
> > > On Sat, Oct 27, 2018 at 07:16:53PM -0700, Joel Fernandes (Google) wrote:
> > > > The RCU
On Tue, Oct 30, 2018 at 04:50:39PM -0700, Paul E. McKenney wrote:
> On Sun, Oct 28, 2018 at 06:16:31PM -0700, Joel Fernandes wrote:
> > On Sun, Oct 28, 2018 at 10:21:42AM -0700, Paul E. McKenney wrote:
> > > On Sat, Oct 27, 2018 at 07:16:53PM -0700, Joel Fernandes (Google) wrote:
> > > > The RCU
On Tue, Oct 30, 2018 at 11:10:47PM +, Daniel Colascione wrote:
> On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes
> wrote:
> > On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
> >> On 2018-10-30, Joel Fernandes wrote:
> >> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa
On Tue, Oct 30, 2018 at 11:10:47PM +, Daniel Colascione wrote:
> On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes
> wrote:
> > On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
> >> On 2018-10-30, Joel Fernandes wrote:
> >> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa
Hi all,
[I don't understand why all this new work turned up in the xfs tree
during the merge window ...]
Today's linux-next merge of the vfs tree got a conflict in:
fs/read_write.c
between commits:
42ec3d4c0218 ("vfs: make remap_file_range functions take and return bytes
completed")
It can be useful for a user to verify what type a given hardware
queue is, expose this information in sysfs.
I assume the user is expected to understand the meaning of the
enumeration it sees in accessing this field correct?
Would be nice to output some meaningful string but I'm not
yet
Hi all,
[I don't understand why all this new work turned up in the xfs tree
during the merge window ...]
Today's linux-next merge of the vfs tree got a conflict in:
fs/read_write.c
between commits:
42ec3d4c0218 ("vfs: make remap_file_range functions take and return bytes
completed")
It can be useful for a user to verify what type a given hardware
queue is, expose this information in sysfs.
I assume the user is expected to understand the meaning of the
enumeration it sees in accessing this field correct?
Would be nice to output some meaningful string but I'm not
yet
On Wed, Oct 31, 2018 at 09:49:08AM +1100, Aleksa Sarai wrote:
> On 2018-10-30, Joel Fernandes wrote:
> > > > [...]
> > > > > > > (Unfortunately
> > > > > > > there are lots of things that make it a bit difficult to use
> > > > > > > /proc/$pid
> > > > > > > exclusively for introspection of a
On Wed, Oct 31, 2018 at 09:49:08AM +1100, Aleksa Sarai wrote:
> On 2018-10-30, Joel Fernandes wrote:
> > > > [...]
> > > > > > > (Unfortunately
> > > > > > > there are lots of things that make it a bit difficult to use
> > > > > > > /proc/$pid
> > > > > > > exclusively for introspection of a
> > > >> This part is in the " Intel® Architecture Instruction Set Extensions
> > > >> and Future Features Programming Reference"
> > > >> https://software.intel.com/sites/default/files/managed/c5/15/arch
> > > >> itec ture-instruction-set-extensions-programming-reference.pdf
> > > >>
> > > > Yet
> > > >> This part is in the " Intel® Architecture Instruction Set Extensions
> > > >> and Future Features Programming Reference"
> > > >> https://software.intel.com/sites/default/files/managed/c5/15/arch
> > > >> itec ture-instruction-set-extensions-programming-reference.pdf
> > > >>
> > > > Yet
On Tue, Oct 30, 2018 at 03:34:54PM -0700, Kees Cook wrote:
> On Tue, Oct 30, 2018 at 3:32 PM, Tycho Andersen wrote:
> > On Tue, Oct 30, 2018 at 03:00:17PM -0700, Kees Cook wrote:
> >> On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen wrote:
> >> > On Tue, Oct 30, 2018 at 02:49:21PM -0700, Kees
On Tue, Oct 30, 2018 at 03:34:54PM -0700, Kees Cook wrote:
> On Tue, Oct 30, 2018 at 3:32 PM, Tycho Andersen wrote:
> > On Tue, Oct 30, 2018 at 03:00:17PM -0700, Kees Cook wrote:
> >> On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen wrote:
> >> > On Tue, Oct 30, 2018 at 02:49:21PM -0700, Kees
Hi, Oleg:
On 10/30/18 9:46 AM, Oleg Nesterov wrote:
> On 10/29, Enke Chen wrote:
>>
>> Reviewed-by: Oleg Nesterov
>
> Hmm. I didn't say this ;)
>
> But OK, feel free to keep this tag.
Thanks.
>
> I do not like this feauture. But I see no technical problems in this version
> and I never
Hi, Oleg:
On 10/30/18 9:46 AM, Oleg Nesterov wrote:
> On 10/29, Enke Chen wrote:
>>
>> Reviewed-by: Oleg Nesterov
>
> Hmm. I didn't say this ;)
>
> But OK, feel free to keep this tag.
Thanks.
>
> I do not like this feauture. But I see no technical problems in this version
> and I never
Hi all,
Today's linux-next merge of the xfs tree got a conflict in:
Documentation/filesystems/porting
between commit:
1a16dbaf798c ("Document d_splice_alias() calling conventions for ->lookup()
users.")
from Linus' tree and commit:
2e5dfc99f2e6 ("vfs: combine the clone and dedupe into
Hi all,
Today's linux-next merge of the xfs tree got a conflict in:
Documentation/filesystems/porting
between commit:
1a16dbaf798c ("Document d_splice_alias() calling conventions for ->lookup()
users.")
from Linus' tree and commit:
2e5dfc99f2e6 ("vfs: combine the clone and dedupe into
On Tue, Oct 30, 2018 at 5:04 PM Olof Johansson wrote:
>
> Fixes the following build error from tinyconfig:
>
> riscv64-unknown-linux-gnu-ld: kernel/sched/fair.o: in function `.L8':
> fair.c:(.text+0x70): undefined reference to `__lshrti3'
> riscv64-unknown-linux-gnu-ld: kernel/time/clocksource.o:
On Tue, Oct 30, 2018 at 5:04 PM Olof Johansson wrote:
>
> Fixes the following build error from tinyconfig:
>
> riscv64-unknown-linux-gnu-ld: kernel/sched/fair.o: in function `.L8':
> fair.c:(.text+0x70): undefined reference to `__lshrti3'
> riscv64-unknown-linux-gnu-ld: kernel/time/clocksource.o:
Fixes the following build error from tinyconfig:
riscv64-unknown-linux-gnu-ld: kernel/sched/fair.o: in function `.L8':
fair.c:(.text+0x70): undefined reference to `__lshrti3'
riscv64-unknown-linux-gnu-ld: kernel/time/clocksource.o: in function `.L0 ':
clocksource.c:(.text+0x334): undefined
Fixes the following build error from tinyconfig:
riscv64-unknown-linux-gnu-ld: kernel/sched/fair.o: in function `.L8':
fair.c:(.text+0x70): undefined reference to `__lshrti3'
riscv64-unknown-linux-gnu-ld: kernel/time/clocksource.o: in function `.L0 ':
clocksource.c:(.text+0x334): undefined
On Tue, Oct 30, 2018 at 11:23 PM, Christian Brauner
wrote:
> On Wed, Oct 31, 2018 at 12:10 AM Daniel Colascione wrote:
>> I think Aleksa's larger point is that it's useful to treat processes
>> as other file-descriptor-named, poll-able, wait-able resources.
>> Consistency is important. A process
On Tue, Oct 30, 2018 at 11:23 PM, Christian Brauner
wrote:
> On Wed, Oct 31, 2018 at 12:10 AM Daniel Colascione wrote:
>> I think Aleksa's larger point is that it's useful to treat processes
>> as other file-descriptor-named, poll-able, wait-able resources.
>> Consistency is important. A process
G'day Pavel,
On Tue, Oct 30, 2018 at 11:26:10AM +0100, Pavel Machek wrote:
> Hi!
>
> > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > >
> > > I didn't test it yet -- will do when I get home in the evening. But
> > > chances are it's good
G'day Pavel,
On Tue, Oct 30, 2018 at 11:26:10AM +0100, Pavel Machek wrote:
> Hi!
>
> > > https://github.com/hackerspace/olpc-xo175-linux/wiki/How-to-run-an-up-to-date-Linux-on-a-XO-1.75
> > >
> > > I didn't test it yet -- will do when I get home in the evening. But
> > > chances are it's good
On Sun, Oct 28, 2018 at 06:16:31PM -0700, Joel Fernandes wrote:
> On Sun, Oct 28, 2018 at 10:21:42AM -0700, Paul E. McKenney wrote:
> > On Sat, Oct 27, 2018 at 07:16:53PM -0700, Joel Fernandes (Google) wrote:
> > > The RCU example for 'rejecting stale data' on system-call auditting
> > > stops
On Sun, Oct 28, 2018 at 06:16:31PM -0700, Joel Fernandes wrote:
> On Sun, Oct 28, 2018 at 10:21:42AM -0700, Paul E. McKenney wrote:
> > On Sat, Oct 27, 2018 at 07:16:53PM -0700, Joel Fernandes (Google) wrote:
> > > The RCU example for 'rejecting stale data' on system-call auditting
> > > stops
On Tue, Oct 30, 2018 at 08:17:57PM -0300, Shayenne Moura wrote:
On 10/30, Greg Kroah-Hartman wrote:
On Tue, Oct 23, 2018 at 02:43:04PM -0300, Shayenne da Luz Moura wrote:
> Remove unneeded parentheses around the arguments of ||. This reduces
> clutter and code behave in the same way.
> Change
On Tue, Oct 30, 2018 at 08:17:57PM -0300, Shayenne Moura wrote:
On 10/30, Greg Kroah-Hartman wrote:
On Tue, Oct 23, 2018 at 02:43:04PM -0300, Shayenne da Luz Moura wrote:
> Remove unneeded parentheses around the arguments of ||. This reduces
> clutter and code behave in the same way.
> Change
sure, the version of driver looked good to me, add the missing Acked-by from me
Acked-by: Sean Wang
On Tue, Oct 30, 2018 at 5:51 AM Linus Walleij wrote:
>
> On Thu, Oct 18, 2018 at 5:06 PM Sean Wang wrote:
>
> > the driver currently only supports the basic operation, not including
> >
sure, the version of driver looked good to me, add the missing Acked-by from me
Acked-by: Sean Wang
On Tue, Oct 30, 2018 at 5:51 AM Linus Walleij wrote:
>
> On Thu, Oct 18, 2018 at 5:06 PM Sean Wang wrote:
>
> > the driver currently only supports the basic operation, not including
> >
On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote:
> Hi Paul,
>
> On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
> > As per this thread [1], it seems this smp_mb isn't needed anymore:
> > "So the smp_mb() that I was trying to add doesn't need to be there."
>
On Tue, Oct 30, 2018 at 03:26:49PM -0700, Joel Fernandes wrote:
> Hi Paul,
>
> On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
> > As per this thread [1], it seems this smp_mb isn't needed anymore:
> > "So the smp_mb() that I was trying to add doesn't need to be there."
>
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
tags/clk-for-linus
for you to fetch changes up to
On Wed, Oct 31, 2018 at 12:10 AM Daniel Colascione wrote:
>
> On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes
> wrote:
> > On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
> >> On 2018-10-30, Joel Fernandes wrote:
> >> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai
On Wed, Oct 31, 2018 at 12:10 AM Daniel Colascione wrote:
>
> On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes
> wrote:
> > On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
> >> On 2018-10-30, Joel Fernandes wrote:
> >> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai
The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3:
Linux 4.19-rc1 (2018-08-26 14:11:59 -0700)
are available in the Git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git
tags/clk-for-linus
for you to fetch changes up to
On 10/30, Greg Kroah-Hartman wrote:
> On Tue, Oct 23, 2018 at 02:43:04PM -0300, Shayenne da Luz Moura wrote:
> > Remove unneeded parentheses around the arguments of ||. This reduces
> > clutter and code behave in the same way.
> > Change suggested by checkpatch.pl.
> >
> > vbox_main.c:119: CHECK:
On 10/30, Greg Kroah-Hartman wrote:
> On Tue, Oct 23, 2018 at 02:43:04PM -0300, Shayenne da Luz Moura wrote:
> > Remove unneeded parentheses around the arguments of ||. This reduces
> > clutter and code behave in the same way.
> > Change suggested by checkpatch.pl.
> >
> > vbox_main.c:119: CHECK:
On Tue, 30 Oct 2018, Vito Caputo wrote:
If you create /proc/stat2 to omit interrupts, do we then create
/proc/stat3 to omit CPUs when just interrupts are of interest to the
application running on a 256-cpu machine?
Be real, this is a bogus argument. As mentioned, stat2 is named as such
On Tue, 30 Oct 2018, Vito Caputo wrote:
If you create /proc/stat2 to omit interrupts, do we then create
/proc/stat3 to omit CPUs when just interrupts are of interest to the
application running on a 256-cpu machine?
Be real, this is a bogus argument. As mentioned, stat2 is named as such
On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes wrote:
> On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
>> On 2018-10-30, Joel Fernandes wrote:
>> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote:
>> > [...]
>> > > > > (Unfortunately
>> > > > > there are lots of
On Tue, Oct 30, 2018 at 10:33 PM, Joel Fernandes wrote:
> On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
>> On 2018-10-30, Joel Fernandes wrote:
>> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote:
>> > [...]
>> > > > > (Unfortunately
>> > > > > there are lots of
The mm-of-the-moment snapshot 2018-10-30-16-08 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
The mm-of-the-moment snapshot 2018-10-30-16-08 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
On 10/30/2018 3:22 PM, kbuild test robot wrote:
Hi Jae,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on v4.19 next-20181030]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve
Hi Jaewon,
On 10/25/18 9:39 AM, Jaewon Kim wrote:
> This patch supports dynamic device-tree for AMBA device.
Add AMBA devices and buses to of_platform_notify() so that dynamic device-tree
will support AMBA.
> The AMBA device must be registered on the AMBA bus, not the platform bus.
>
>
On 10/30/2018 3:22 PM, kbuild test robot wrote:
Hi Jae,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on wsa/i2c/for-next]
[also build test WARNING on v4.19 next-20181030]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve
Hi Jaewon,
On 10/25/18 9:39 AM, Jaewon Kim wrote:
> This patch supports dynamic device-tree for AMBA device.
Add AMBA devices and buses to of_platform_notify() so that dynamic device-tree
will support AMBA.
> The AMBA device must be registered on the AMBA bus, not the platform bus.
>
>
On 2018-10-30, Joel Fernandes wrote:
> > > [...]
> > > > > > (Unfortunately
> > > > > > there are lots of things that make it a bit difficult to use
> > > > > > /proc/$pid
> > > > > > exclusively for introspection of a process -- especially in the
> > > > > > context
> > > > > > of
On 2018-10-30, Joel Fernandes wrote:
> > > [...]
> > > > > > (Unfortunately
> > > > > > there are lots of things that make it a bit difficult to use
> > > > > > /proc/$pid
> > > > > > exclusively for introspection of a process -- especially in the
> > > > > > context
> > > > > > of
On Tue, Oct 30, 2018 at 11:57:56AM -0700, Davidlohr Bueso wrote:
> On Mon, 29 Oct 2018, Vito Caputo wrote:
>
> > I'm definitely not in favor of just adding another stat file that is the
> > same format as the existing one with the intrs zeroed out. It's a dirty
> > hack; fine for your local
On Tue, Oct 30, 2018 at 11:57:56AM -0700, Davidlohr Bueso wrote:
> On Mon, 29 Oct 2018, Vito Caputo wrote:
>
> > I'm definitely not in favor of just adding another stat file that is the
> > same format as the existing one with the intrs zeroed out. It's a dirty
> > hack; fine for your local
On Tue, Oct 30, 2018 at 3:32 PM, Tycho Andersen wrote:
> On Tue, Oct 30, 2018 at 03:00:17PM -0700, Kees Cook wrote:
>> On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen wrote:
>> > On Tue, Oct 30, 2018 at 02:49:21PM -0700, Kees Cook wrote:
>> >> On Mon, Oct 29, 2018 at 3:40 PM, Tycho Andersen
On Tue, Oct 30, 2018 at 3:32 PM, Tycho Andersen wrote:
> On Tue, Oct 30, 2018 at 03:00:17PM -0700, Kees Cook wrote:
>> On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen wrote:
>> > On Tue, Oct 30, 2018 at 02:49:21PM -0700, Kees Cook wrote:
>> >> On Mon, Oct 29, 2018 at 3:40 PM, Tycho Andersen
On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > Can someone at least confirm whether unwinding from a function prologue
> > via
> > .eh_frame (but without .debug_frame) should actually be possible?
>
> Yes it should be possible. Asynchronous unwind tables should work
> from any
On Mittwoch, 24. Oktober 2018 16:48:18 CET Andi Kleen wrote:
> > Can someone at least confirm whether unwinding from a function prologue
> > via
> > .eh_frame (but without .debug_frame) should actually be possible?
>
> Yes it should be possible. Asynchronous unwind tables should work
> from any
On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
> On 2018-10-30, Joel Fernandes wrote:
> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote:
> > [...]
> > > > > (Unfortunately
> > > > > there are lots of things that make it a bit difficult to use
> > > > > /proc/$pid
>
On Wed, Oct 31, 2018 at 09:23:39AM +1100, Aleksa Sarai wrote:
> On 2018-10-30, Joel Fernandes wrote:
> > On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote:
> > [...]
> > > > > (Unfortunately
> > > > > there are lots of things that make it a bit difficult to use
> > > > > /proc/$pid
>
On Tue, Oct 30, 2018 at 03:00:17PM -0700, Kees Cook wrote:
> On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen wrote:
> > On Tue, Oct 30, 2018 at 02:49:21PM -0700, Kees Cook wrote:
> >> On Mon, Oct 29, 2018 at 3:40 PM, Tycho Andersen wrote:
> >> > * switch to a flags based future-proofing
On Tue, Oct 30, 2018 at 03:00:17PM -0700, Kees Cook wrote:
> On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen wrote:
> > On Tue, Oct 30, 2018 at 02:49:21PM -0700, Kees Cook wrote:
> >> On Mon, Oct 29, 2018 at 3:40 PM, Tycho Andersen wrote:
> >> > * switch to a flags based future-proofing
Hi Paul,
On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
> As per this thread [1], it seems this smp_mb isn't needed anymore:
> "So the smp_mb() that I was trying to add doesn't need to be there."
>
> So let us remove this part from the memory ordering documentation.
>
Hi Paul,
On Sat, Oct 27, 2018 at 09:30:46PM -0700, Joel Fernandes (Google) wrote:
> As per this thread [1], it seems this smp_mb isn't needed anymore:
> "So the smp_mb() that I was trying to add doesn't need to be there."
>
> So let us remove this part from the memory ordering documentation.
>
Fenghua,
> -Original Message-
> From: Fenghua Yu
> Sent: Tuesday, October 30, 2018 1:36 PM
> To: Moger, Babu ; Fenghua Yu
>
> Cc: Thomas Gleixner ; Ingo Molnar
> ; H Peter Anvin ; Tony Luck
> ; Peter Zijlstra ; Reinette
> Chatre ; James Morse
> ; Ravi V Shankar ; Sai
> Praneeth Prakhya
Fenghua,
> -Original Message-
> From: Fenghua Yu
> Sent: Tuesday, October 30, 2018 1:36 PM
> To: Moger, Babu ; Fenghua Yu
>
> Cc: Thomas Gleixner ; Ingo Molnar
> ; H Peter Anvin ; Tony Luck
> ; Peter Zijlstra ; Reinette
> Chatre ; James Morse
> ; Ravi V Shankar ; Sai
> Praneeth Prakhya
On Tue, Oct 30, 2018 at 08:59:25AM +, Daniel Colascione wrote:
> On Tue, Oct 30, 2018 at 3:06 AM, Joel Fernandes wrote:
> > On Mon, Oct 29, 2018 at 1:01 PM Daniel Colascione wrote:
> >>
> >> Thanks for taking a look.
> >>
> >> On Mon, Oct 29, 2018 at 7:45 PM, Joel Fernandes wrote:
> >> >
>
On Tue, Oct 30, 2018 at 08:59:25AM +, Daniel Colascione wrote:
> On Tue, Oct 30, 2018 at 3:06 AM, Joel Fernandes wrote:
> > On Mon, Oct 29, 2018 at 1:01 PM Daniel Colascione wrote:
> >>
> >> Thanks for taking a look.
> >>
> >> On Mon, Oct 29, 2018 at 7:45 PM, Joel Fernandes wrote:
> >> >
>
On 2018-10-30, Joel Fernandes wrote:
> On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote:
> [...]
> > > > (Unfortunately
> > > > there are lots of things that make it a bit difficult to use /proc/$pid
> > > > exclusively for introspection of a process -- especially in the context
> >
On 2018-10-30, Joel Fernandes wrote:
> On Wed, Oct 31, 2018 at 07:45:01AM +1100, Aleksa Sarai wrote:
> [...]
> > > > (Unfortunately
> > > > there are lots of things that make it a bit difficult to use /proc/$pid
> > > > exclusively for introspection of a process -- especially in the context
> >
On Tue, Oct 30, 2018 at 05:58:00AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 29, 2018 at 08:44:52PM -0700, Joel Fernandes wrote:
> > On Mon, Oct 29, 2018 at 07:27:35AM -0700, Paul E. McKenney wrote:
> > > On Mon, Oct 29, 2018 at 11:24:42AM +, Ran Rozenstein wrote:
> > > > Hi Paul and all,
>
On Tue, Oct 30, 2018 at 05:58:00AM -0700, Paul E. McKenney wrote:
> On Mon, Oct 29, 2018 at 08:44:52PM -0700, Joel Fernandes wrote:
> > On Mon, Oct 29, 2018 at 07:27:35AM -0700, Paul E. McKenney wrote:
> > > On Mon, Oct 29, 2018 at 11:24:42AM +, Ran Rozenstein wrote:
> > > > Hi Paul and all,
>
Hi Jarkko,
Commit
e22bf023c141 ("tpm: tpm_ibmvtpm: fix kdoc warnings")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpX4G3_hzzjA.pgp
Description: OpenPGP digital signature
syzbot has found a reproducer for the following crash on:
HEAD commit:6201f31a39f8 Add linux-next specific files for 20181030
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=178f699940
kernel config: https://syzkaller.appspot.com/x/.config?x
Hi Jarkko,
Commit
e22bf023c141 ("tpm: tpm_ibmvtpm: fix kdoc warnings")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpX4G3_hzzjA.pgp
Description: OpenPGP digital signature
syzbot has found a reproducer for the following crash on:
HEAD commit:6201f31a39f8 Add linux-next specific files for 20181030
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=178f699940
kernel config: https://syzkaller.appspot.com/x/.config?x
On Tue, Oct 30, 2018 at 02:52:43PM -0700, Kees Cook wrote:
> On Tue, Oct 30, 2018 at 2:38 PM, Joel Fernandes
> wrote:
> > On Tue, Oct 30, 2018 at 03:52:34PM +0800, Peng Wang wrote:
> >> When initialing prz with invalid data in buffer(no PERSISTENT_RAM_SIG),
> >> function call path is like this:
On 30/10/2018 23:02, Andy Lutomirski wrote:
On Oct 30, 2018, at 1:43 PM, Igor Stoppa wrote:
There is no need to process each of these tens of thousands allocations and
initialization as write-rare.
Would it be possible to do the same here?
I don’t see why not, although getting the
On Tue, Oct 30, 2018 at 02:52:43PM -0700, Kees Cook wrote:
> On Tue, Oct 30, 2018 at 2:38 PM, Joel Fernandes
> wrote:
> > On Tue, Oct 30, 2018 at 03:52:34PM +0800, Peng Wang wrote:
> >> When initialing prz with invalid data in buffer(no PERSISTENT_RAM_SIG),
> >> function call path is like this:
On 30/10/2018 23:02, Andy Lutomirski wrote:
On Oct 30, 2018, at 1:43 PM, Igor Stoppa wrote:
There is no need to process each of these tens of thousands allocations and
initialization as write-rare.
Would it be possible to do the same here?
I don’t see why not, although getting the
The Mapleboard MP130 is a single board computer based on the Allwinner
H3 SoC, with all schematics freely available. The Lite version includes
1GB main memory and 8GB eMMC.
https://www.mapleboard.org/en (still mostly in Chinese even when English
is selected)
This DTS is based upon the DTS
The Mapleboard MP130 is a single board computer based on the Allwinner
H3 SoC, with all schematics freely available. The Lite version includes
1GB main memory and 8GB eMMC.
https://www.mapleboard.org/en (still mostly in Chinese even when English
is selected)
This DTS is based upon the DTS
On Mon, Oct 29, 2018 at 03:13:05PM +0530, Viresh Kumar wrote:
> The example contains two values for the capacity currently, 446 in text
> and 578 in code. The numbers are all correct but can confuse some of the
> readers. This patch tries to explain how the numbers are calculated to
> avoid same
On Mon, Oct 29, 2018 at 03:13:05PM +0530, Viresh Kumar wrote:
> The example contains two values for the capacity currently, 446 in text
> and 578 in code. The numbers are all correct but can confuse some of the
> readers. This patch tries to explain how the numbers are calculated to
> avoid same
On Mon, Oct 29, 2018 at 04:20:52PM +0100, Maxime Ripard wrote:
> Thanks for your patch.
Thanks for the comments.
> On Thu, Oct 25, 2018 at 08:55:19PM +0100, Jonathan McDowell wrote:
...
> The prefix of your patch should be "ARM: dts: sun8i-h3: ..."
Ok.
> > diff --git
On Mon, Oct 29, 2018 at 04:20:52PM +0100, Maxime Ripard wrote:
> Thanks for your patch.
Thanks for the comments.
> On Thu, Oct 25, 2018 at 08:55:19PM +0100, Jonathan McDowell wrote:
...
> The prefix of your patch should be "ARM: dts: sun8i-h3: ..."
Ok.
> > diff --git
On Wed, 2018-09-19 at 10:14 -0700, Dhaval Giani wrote:
> Hi folks,
>
> Sasha and I are pleased to announce the Testing and Fuzzing track at
> LPC [ 1 ]. We are planning to continue the discussions from last
> year's microconference [2]. Many discussions from the Automated
> Testing Summit [3]
On Wed, 2018-09-19 at 10:14 -0700, Dhaval Giani wrote:
> Hi folks,
>
> Sasha and I are pleased to announce the Testing and Fuzzing track at
> LPC [ 1 ]. We are planning to continue the discussions from last
> year's microconference [2]. Many discussions from the Automated
> Testing Summit [3]
> -Original Message-
> From: Tim Chen [mailto:tim.c.c...@linux.intel.com]
> Sent: Tuesday, October 30, 2018 2:35 PM
> To: Schaufler, Casey ; Jiri Kosina
> ; Thomas Gleixner
> Cc: Tom Lendacky ; Ingo Molnar
> ; Peter Zijlstra ; Josh Poimboeuf
> ; Andrea Arcangeli ; David
> Woodhouse ; Andi
> -Original Message-
> From: Tim Chen [mailto:tim.c.c...@linux.intel.com]
> Sent: Tuesday, October 30, 2018 2:35 PM
> To: Schaufler, Casey ; Jiri Kosina
> ; Thomas Gleixner
> Cc: Tom Lendacky ; Ingo Molnar
> ; Peter Zijlstra ; Josh Poimboeuf
> ; Andrea Arcangeli ; David
> Woodhouse ; Andi
On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen wrote:
> On Tue, Oct 30, 2018 at 02:49:21PM -0700, Kees Cook wrote:
>> On Mon, Oct 29, 2018 at 3:40 PM, Tycho Andersen wrote:
>> > * switch to a flags based future-proofing mechanism for struct
>> > seccomp_notif and seccomp_notif_resp,
On Tue, Oct 30, 2018 at 2:54 PM, Tycho Andersen wrote:
> On Tue, Oct 30, 2018 at 02:49:21PM -0700, Kees Cook wrote:
>> On Mon, Oct 29, 2018 at 3:40 PM, Tycho Andersen wrote:
>> > * switch to a flags based future-proofing mechanism for struct
>> > seccomp_notif and seccomp_notif_resp,
brelse(iloc.bh) is useless here, it is always called with iloc.bh = NULL
Fixes dec214d00e0d ("ext4: xattr inode deduplication") # 4.13
cc: Tahsin Erdogan
Signed-off-by: Vasily Averin
---
fs/ext4/xattr.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/fs/ext4/xattr.c
On-stack initialization does not guarantee zeroying of unintialized
fields. So is.iloc.bh and bs.bh can be contain garbage of old stack
conent.
Errors in the beginning of ext4_xattr_set_handle() function
lead to jump to "cleanup:" label where brelse(is.iloc.bh)
and brelse(bs.bh) can access
101 - 200 of 1220 matches
Mail list logo
