Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

On Mon, Mar 13, 2017 at 01:41:36PM +0100, Christian König wrote: > From: Christian König > > Try to resize BAR0 to let CPU access all of VRAM. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + >

9p and EINTR?

Hi fsdevel, Some users of our distro (NixOS) ran into some 9p funkiness again... Eventually it was traced down to many 9p filesystem calls getting interrupted by signals (here, it was bash receiving SIGCHLDs from background jobs exiting) and returning with -EINTR. E.g. stat() manpage doesn't list

Re: [PATCH 4/4] drm/amdgpu: resize VRAM BAR for CPU access

On Mon, Mar 13, 2017 at 01:41:36PM +0100, Christian König wrote: > From: Christian König > > Try to resize BAR0 to let CPU access all of VRAM. > > Signed-off-by: Christian König > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 + > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 29

9p and EINTR?

Hi fsdevel, Some users of our distro (NixOS) ran into some 9p funkiness again... Eventually it was traced down to many 9p filesystem calls getting interrupted by signals (here, it was bash receiving SIGCHLDs from background jobs exiting) and returning with -EINTR. E.g. stat() manpage doesn't list

Audit fixes for v4.11 (#1)

Hi Linus, We've got an audit fix, and unfortunately it is two things I don't like: big and based on a -rcX tag. The size of the patch is (hopefully) explained well in the patch description, the -rcX base is to get access to code not present in the v4.11 pull request (audit/next is still based

Audit fixes for v4.11 (#1)

Hi Linus, We've got an audit fix, and unfortunately it is two things I don't like: big and based on a -rcX tag. The size of the patch is (hopefully) explained well in the patch description, the -rcX base is to get access to code not present in the v4.11 pull request (audit/next is still based

[PATCH 1/5] notify: Call mutex_destroy() before freeing mutex memory

The conversion of notify from using a spinlock to a mutex missed adding the call mutex_destroy(). Fixes: 986ab09 ("fsnotify: use a mutex instead of a spinlock to protect a groups mark list") Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik ---

[PATCH 1/5] notify: Call mutex_destroy() before freeing mutex memory

The conversion of notify from using a spinlock to a mutex missed adding the call mutex_destroy(). Fixes: 986ab09 ("fsnotify: use a mutex instead of a spinlock to protect a groups mark list") Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/group.c | 1 + 1 file changed, 1

[PATCH 5/5] inotify: Avoid taking spinlock for each event processed in read()

Splice off the notification list while processing read events, which allows it to be processed without taking and releasing the spinlock for each event. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/inotify/inotify_user.c | 28

[PATCH 5/5] inotify: Avoid taking spinlock for each event processed in read()

Splice off the notification list while processing read events, which allows it to be processed without taking and releasing the spinlock for each event. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/inotify/inotify_user.c | 28 1 file changed,

[PATCH 4/5] inotify: switch get_one_event() to use fsnotify_list_*() helpers

Preparing to switch inotify to code not taking the spinlock for each event in read() Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/inotify/inotify_user.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git

[PATCH 4/5] inotify: switch get_one_event() to use fsnotify_list_*() helpers

Preparing to switch inotify to code not taking the spinlock for each event in read() Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/inotify/inotify_user.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/fs/notify/inotify/inotify_user.c

[PATCH 3/5] notify: Split up some fsnotify functions

This splits up fsnotify_remove_first_event() and fsnotify_peek_first_event() into a helper function with a wrapper, and introduces two new versions that takes a list instead of the group as argument. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik ---

[PATCH 3/5] notify: Split up some fsnotify functions

This splits up fsnotify_remove_first_event() and fsnotify_peek_first_event() into a helper function with a wrapper, and introduces two new versions that takes a list instead of the group as argument. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik --- fs/notify/notification.c | 38

[PATCH 2/5] inotify: Use mutex to prevent threaded clients reading events out of order

Introduces mutex in the read() path to prevent a threaded client reading from the same fd consuming events out of order. This will matter when avoiding taking the spinlock when consuming each event in the read() path. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik

[PATCH 0/5] inofify: Reduce lock contention on read()

Hi, Running inotify on a very large number hierachy of directories and files can result in major lock contention between the producer and consumer of events. The current code takes the spinlock when pulling each event off the queue, which isn't overly idea. This patchset reduces the lock

[PATCH 2/5] inotify: Use mutex to prevent threaded clients reading events out of order

Introduces mutex in the read() path to prevent a threaded client reading from the same fd consuming events out of order. This will matter when avoiding taking the spinlock when consuming each event in the read() path. Signed-off-by: Jes Sorensen Reviewed-by: Josef Bacik ---

[PATCH 0/5] inofify: Reduce lock contention on read()

Hi, Running inotify on a very large number hierachy of directories and files can result in major lock contention between the producer and consumer of events. The current code takes the spinlock when pulling each event off the queue, which isn't overly idea. This patchset reduces the lock

Re: [PATCH 2/4] PCI: add functionality for resizing resources v2

On Mon, Mar 13, 2017 at 01:41:34PM +0100, Christian König wrote: > From: Christian König > > This allows device drivers to request resizing their BARs. > > The function only tries to reprogram the windows of the bridge directly above > the requesting device and only

Re: [PATCH 2/4] PCI: add functionality for resizing resources v2

On Mon, Mar 13, 2017 at 01:41:34PM +0100, Christian König wrote: > From: Christian König > > This allows device drivers to request resizing their BARs. > > The function only tries to reprogram the windows of the bridge directly above > the requesting device and only the BAR of the same type

[PATCH 3/3] clocksource: fttmr010: refactor to handle clock

The plain Faraday FTTMR010 timer needs a clock to figure out its tick rate, and the gemini reads it directly from the system controller set-up. Split the init function and add two paths for the two compatible-strings. We only support clocking using PCLK because of lack of documentation on how

[PATCH 2/3] clocksource: rename Gemini timer to Faraday

After some research it turns out that the "Gemini" timer is actually a generic IP block from Faraday Technology named FTTMR010, so as to not make things too confusing we need to rename the driver and its symbols to make sense. The implementation remains the same in this patch but we fix the

[PATCH 2/3] clocksource: rename Gemini timer to Faraday

After some research it turns out that the "Gemini" timer is actually a generic IP block from Faraday Technology named FTTMR010, so as to not make things too confusing we need to rename the driver and its symbols to make sense. The implementation remains the same in this patch but we fix the

[PATCH 3/3] clocksource: fttmr010: refactor to handle clock

The plain Faraday FTTMR010 timer needs a clock to figure out its tick rate, and the gemini reads it directly from the system controller set-up. Split the init function and add two paths for the two compatible-strings. We only support clocking using PCLK because of lack of documentation on how

[PATCH 1/3] clocksource: Augment bindings for Faraday timer

It turns out that the Cortina Gemini timer block is just a standard IP block from Faraday Technology named FTTMR010. In order to make things clear and understandable, we rename the bindings with a Faraday compatible as primary and the Cortina gemini as a more specific case. For the plain Faraday

[PATCH 1/3] clocksource: Augment bindings for Faraday timer

It turns out that the Cortina Gemini timer block is just a standard IP block from Faraday Technology named FTTMR010. In order to make things clear and understandable, we rename the bindings with a Faraday compatible as primary and the Cortina gemini as a more specific case. For the plain Faraday

Re: [PATCH -v6 03/13] futex: Remove rt_mutex_deadlock_account_*()

On Fri, Mar 24, 2017 at 02:29:27PM -0700, Darren Hart wrote: > On Wed, Mar 22, 2017 at 11:35:50AM +0100, Peter Zijlstra wrote: > > These are unused and clutter up the code. > > And apparently have been that way for a very long time. > > > > > Signed-off-by: Peter Zijlstra (Intel)

Re: [PATCH -v6 03/13] futex: Remove rt_mutex_deadlock_account_*()

On Fri, Mar 24, 2017 at 02:29:27PM -0700, Darren Hart wrote: > On Wed, Mar 22, 2017 at 11:35:50AM +0100, Peter Zijlstra wrote: > > These are unused and clutter up the code. > > And apparently have been that way for a very long time. > > > > > Signed-off-by: Peter Zijlstra (Intel) > >

Re: [PATCH 0/8] pinctrl: meson: add audio output pins

On Fri, 2017-03-24 at 12:52 -0700, Kevin Hilman wrote: > Jerome Brunet writes: > > > This patchset adds the pinctrl definition and the related device-tree > > bindings of the i2s output and spdif output pins on the meson gxbb and > > gxl SoCs. > > > > This is part of the

Re: [PATCH 0/8] pinctrl: meson: add audio output pins

On Fri, 2017-03-24 at 12:52 -0700, Kevin Hilman wrote: > Jerome Brunet writes: > > > This patchset adds the pinctrl definition and the related device-tree > > bindings of the i2s output and spdif output pins on the meson gxbb and > > gxl SoCs. > > > > This is part of the ongoing work to bring

Re: [PATCH -v6 03/13] futex: Remove rt_mutex_deadlock_account_*()

On Wed, Mar 22, 2017 at 11:35:50AM +0100, Peter Zijlstra wrote: > These are unused and clutter up the code. And apparently have been that way for a very long time. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Darren Hart (VMware) --

Re: [PATCH -v6 03/13] futex: Remove rt_mutex_deadlock_account_*()

On Wed, Mar 22, 2017 at 11:35:50AM +0100, Peter Zijlstra wrote: > These are unused and clutter up the code. And apparently have been that way for a very long time. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Darren Hart (VMware) -- Darren Hart VMware Open Source Technology

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On Fri, Mar 24, 2017 at 5:10 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Mar 24, 2017 at 04:34:23PM -0400, Dan Streetman wrote: >> On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky >> wrote: >> > >> > >> > On 03/22/2017 05:16 PM, Dan Streetman

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On Fri, Mar 24, 2017 at 5:10 PM, Konrad Rzeszutek Wilk wrote: > On Fri, Mar 24, 2017 at 04:34:23PM -0400, Dan Streetman wrote: >> On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky >> wrote: >> > >> > >> > On 03/22/2017 05:16 PM, Dan Streetman wrote: >> >> >> >> I have a question about a problem

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 12:17:28PM -0700, Linus Torvalds wrote: > On Fri, Mar 24, 2017 at 11:45 AM, Andy Lutomirski wrote: > > > > Is there some hack like if __builtin_is_unescaped(*val) *val = old; > > that would work? > > See my recent email suggesting a completely

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 12:17:28PM -0700, Linus Torvalds wrote: > On Fri, Mar 24, 2017 at 11:45 AM, Andy Lutomirski wrote: > > > > Is there some hack like if __builtin_is_unescaped(*val) *val = old; > > that would work? > > See my recent email suggesting a completely different interface, which >

Re: [PATCH] of: add stub for of_n_addr_cells

On Fri, Mar 24, 2017 at 11:39 AM, Tobias Regnery wrote: > With CONFIG_OF=n and CONFIG_COMPILE_TEST=y the rcar pci-e driver fails to > build on arm: > > drivers/pci/host/pcie-rcar.c: In function 'pci_dma_range_parser_init': > drivers/pci/host/pcie-rcar.c:1035:16: error:

Re: [PATCH] of: add stub for of_n_addr_cells

On Fri, Mar 24, 2017 at 11:39 AM, Tobias Regnery wrote: > With CONFIG_OF=n and CONFIG_COMPILE_TEST=y the rcar pci-e driver fails to > build on arm: > > drivers/pci/host/pcie-rcar.c: In function 'pci_dma_range_parser_init': > drivers/pci/host/pcie-rcar.c:1035:16: error: implicit declaration of

[ANNOUNCE] Git v2.12.2

The latest maintenance release Git v2.12.2 is now available at the usual places. These fixes have all been in the 'master' branch to be included in the next feature release. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a

[ANNOUNCE] Git v2.12.2

The latest maintenance release Git v2.12.2 is now available at the usual places. These fixes have all been in the 'master' branch to be included in the next feature release. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/ The following public repositories all have a

Re: [PATCH -v6 02/13] futex: Use smp_store_release() in mark_wake_futex()

On Wed, Mar 22, 2017 at 11:35:49AM +0100, Peter Zijlstra wrote: > Since the futex_q can dissapear the instruction after assigning NULL, > this really should be a RELEASE barrier. That stops loads from hitting > dead memory too. > > Signed-off-by: Peter Zijlstra (Intel) I

Re: [PATCH -v6 02/13] futex: Use smp_store_release() in mark_wake_futex()

On Wed, Mar 22, 2017 at 11:35:49AM +0100, Peter Zijlstra wrote: > Since the futex_q can dissapear the instruction after assigning NULL, > this really should be a RELEASE barrier. That stops loads from hitting > dead memory too. > > Signed-off-by: Peter Zijlstra (Intel) I reviewed this carefully

Re: [PATCH -v6 01/13] futex: Cleanup variable names for futex_top_waiter()

On Wed, Mar 22, 2017 at 11:35:48AM +0100, Peter Zijlstra wrote: > futex_top_waiter() returns the top-waiter on the pi_mutex. Assinging > this to a variable 'match' totally obscures the code. > > Signed-off-by: Peter Zijlstra (Intel) Yup, still happy to see this one.

Re: [PATCH -v6 01/13] futex: Cleanup variable names for futex_top_waiter()

On Wed, Mar 22, 2017 at 11:35:48AM +0100, Peter Zijlstra wrote: > futex_top_waiter() returns the top-waiter on the pi_mutex. Assinging > this to a variable 'match' totally obscures the code. > > Signed-off-by: Peter Zijlstra (Intel) Yup, still happy to see this one. Reviewed-by: Darren Hart

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On Fri, Mar 24, 2017 at 04:34:23PM -0400, Dan Streetman wrote: > On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky > wrote: > > > > > > On 03/22/2017 05:16 PM, Dan Streetman wrote: > >> > >> I have a question about a problem introduced by this commit: > >>

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On Fri, Mar 24, 2017 at 04:34:23PM -0400, Dan Streetman wrote: > On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky > wrote: > > > > > > On 03/22/2017 05:16 PM, Dan Streetman wrote: > >> > >> I have a question about a problem introduced by this commit: > >> c275a57f5ec3056f732843b11659d892235faff7

Re: [PATCH v4] statx: optimize copy of struct statx to userspace

On Thu, Mar 16, 2017 at 11:41:41AM +, David Howells wrote: > Eric Biggers wrote: > > > stat() instead initializes its struct on the stack and copies it to > > userspace with a single call to copy_to_user(). This turns out to be > > much faster, and changing statx to do

Re: [PATCH v4] statx: optimize copy of struct statx to userspace

On Thu, Mar 16, 2017 at 11:41:41AM +, David Howells wrote: > Eric Biggers wrote: > > > stat() instead initializes its struct on the stack and copies it to > > userspace with a single call to copy_to_user(). This turns out to be > > much faster, and changing statx to do this makes it almost

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 01:27:49PM -0700, Andy Lutomirski wrote: > On Fri, Mar 24, 2017 at 1:22 PM, Peter Zijlstra wrote: > > On Fri, Mar 24, 2017 at 11:45:46AM -0700, Andy Lutomirski wrote: > >> After playing with it a bit, I found some of the problem: you're > >> passing

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 01:27:49PM -0700, Andy Lutomirski wrote: > On Fri, Mar 24, 2017 at 1:22 PM, Peter Zijlstra wrote: > > On Fri, Mar 24, 2017 at 11:45:46AM -0700, Andy Lutomirski wrote: > >> After playing with it a bit, I found some of the problem: you're > >> passing val into

Re: linux-next: something wrong with 5-level paging

On Fri, Mar 24, 2017 at 5:06 AM, Kirill A. Shutemov wrote: > On Tue, Mar 21, 2017 at 03:03:20PM -0700, Andrei Vagin wrote: >> Hi, >> >> I reproduced it locally. This kernel doesn't boot via kexec, but it >> can boot if we set it via the qemu -kernel option. Then I tried to

Re: linux-next: something wrong with 5-level paging

On Fri, Mar 24, 2017 at 5:06 AM, Kirill A. Shutemov wrote: > On Tue, Mar 21, 2017 at 03:03:20PM -0700, Andrei Vagin wrote: >> Hi, >> >> I reproduced it locally. This kernel doesn't boot via kexec, but it >> can boot if we set it via the qemu -kernel option. Then I tried to >> boot the same kernel

Re: [PATCH] virtio_balloon: prevent uninitialized variable use

On Fri, Mar 24, 2017 at 09:40:07PM +0100, Arnd Bergmann wrote: > On Fri, Mar 24, 2017 at 9:11 PM, Ladi Prosek wrote: > > On Fri, Mar 24, 2017 at 7:38 PM, David Hildenbrand wrote: > >> On 23.03.2017 16:17, Arnd Bergmann wrote: > >>> The latest gcc-7.0.1

Re: [PATCH] virtio_balloon: prevent uninitialized variable use

On Fri, Mar 24, 2017 at 09:40:07PM +0100, Arnd Bergmann wrote: > On Fri, Mar 24, 2017 at 9:11 PM, Ladi Prosek wrote: > > On Fri, Mar 24, 2017 at 7:38 PM, David Hildenbrand wrote: > >> On 23.03.2017 16:17, Arnd Bergmann wrote: > >>> The latest gcc-7.0.1 snapshot reports a new warning: > >>> > >>>

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 1:46 PM, Peter Zijlstra wrote: > > I certainly like it better, but so far I'm having trouble reproducing > your results. What compiler version are you on? I have: gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) from

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 1:46 PM, Peter Zijlstra wrote: > > I certainly like it better, but so far I'm having trouble reproducing > your results. What compiler version are you on? I have: gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) from gcc-6.3.1-1.fc24.x86_64 and I'm attaching

ARM: SoC fixes for v4.11

The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81: Linux 4.11-rc2 (2017-03-12 14:47:08 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to

ARM: SoC fixes for v4.11

The following changes since commit 4495c08e84729385774601b5146d51d9e5849f81: Linux 4.11-rc2 (2017-03-12 14:47:08 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/armsoc-fixes for you to fetch changes up to

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 12:08:32PM -0700, Linus Torvalds wrote: > On Fri, Mar 24, 2017 at 10:23 AM, Peter Zijlstra wrote: > > > > I tried a few variants, but nothing really made it better. > > So I really hate how your thing has two return values, and fakes the > second one

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 12:08:32PM -0700, Linus Torvalds wrote: > On Fri, Mar 24, 2017 at 10:23 AM, Peter Zijlstra wrote: > > > > I tried a few variants, but nothing really made it better. > > So I really hate how your thing has two return values, and fakes the > second one using the pointer

Re: [PATCH 0/3] minitty: a minimal TTY layer alternative for embedded systems

On 24 March 2017 at 13:53, Greg Kroah-Hartman wrote: > On Fri, Mar 24, 2017 at 08:31:45AM -0400, Nicolas Pitre wrote: >> On Fri, 24 Mar 2017, Greg Kroah-Hartman wrote: >> >> > meta-comment, any reason you didn't cc: linux-serial@vger as well? >> >> I didn't realize

Re: [PATCH 0/3] minitty: a minimal TTY layer alternative for embedded systems

On 24 March 2017 at 13:53, Greg Kroah-Hartman wrote: > On Fri, Mar 24, 2017 at 08:31:45AM -0400, Nicolas Pitre wrote: >> On Fri, 24 Mar 2017, Greg Kroah-Hartman wrote: >> >> > meta-comment, any reason you didn't cc: linux-serial@vger as well? >> >> I didn't realize such a list even existed. I

Re: [PATCHv3 1/2] mfd: cpcap: Add missing include dependencies

Hi Sebastianm On 03/24/2017 09:47 AM, Sebastian Reichel wrote: > This fixes compilation for files, that try to include the > cpcap header in alphabetically sorted #include lists. > > Acked-by: Pavel Machek > Acked-by: Tony Lindgren > Signed-off-by: Sebastian

Re: [PATCHv3 1/2] mfd: cpcap: Add missing include dependencies

Hi Sebastianm On 03/24/2017 09:47 AM, Sebastian Reichel wrote: > This fixes compilation for files, that try to include the > cpcap header in alphabetically sorted #include lists. > > Acked-by: Pavel Machek > Acked-by: Tony Lindgren > Signed-off-by: Sebastian Reichel > --- > Changes since

Re: [oss-security] Linux kernel ping socket / AF_LLC connect() sin_family race

On Fri, Mar 24, 2017 at 9:27 PM, Solar Designer wrote: > Hi, > > I haven't fully investigated this issue, and the Subject is provisional > (but will probably get stuck). I am not yet sure which kernel > subsystem(s) to blame here (ping sockets? LLC sockets? other/more?), and

Re: [oss-security] Linux kernel ping socket / AF_LLC connect() sin_family race

On Fri, Mar 24, 2017 at 9:27 PM, Solar Designer wrote: > Hi, > > I haven't fully investigated this issue, and the Subject is provisional > (but will probably get stuck). I am not yet sure which kernel > subsystem(s) to blame here (ping sockets? LLC sockets? other/more?), and > there might be

Re: [PATCH v2 1/3] crypto: hw_random - Add new Exynos RNG driver

Am Freitag, 24. März 2017, 19:26:04 CET schrieb Krzysztof Kozlowski: Hi Krzysztof, > +static unsigned int exynos_rng_copy_random(struct exynos_rng_dev *rng, > +u8 *dst, unsigned int dlen) > +{ > + unsigned int cnt = 0; > + int i, j; > + u32

Re: [PATCH v2 1/3] crypto: hw_random - Add new Exynos RNG driver

Am Freitag, 24. März 2017, 19:26:04 CET schrieb Krzysztof Kozlowski: Hi Krzysztof, > +static unsigned int exynos_rng_copy_random(struct exynos_rng_dev *rng, > +u8 *dst, unsigned int dlen) > +{ > + unsigned int cnt = 0; > + int i, j; > + u32

Re: [PATCH] virtio_balloon: prevent uninitialized variable use

On Fri, Mar 24, 2017 at 9:11 PM, Ladi Prosek wrote: > On Fri, Mar 24, 2017 at 7:38 PM, David Hildenbrand wrote: >> On 23.03.2017 16:17, Arnd Bergmann wrote: >>> The latest gcc-7.0.1 snapshot reports a new warning: >>> >>> virtio/virtio_balloon.c: In function

Re: [PATCH] virtio_balloon: prevent uninitialized variable use

On Fri, Mar 24, 2017 at 9:11 PM, Ladi Prosek wrote: > On Fri, Mar 24, 2017 at 7:38 PM, David Hildenbrand wrote: >> On 23.03.2017 16:17, Arnd Bergmann wrote: >>> The latest gcc-7.0.1 snapshot reports a new warning: >>> >>> virtio/virtio_balloon.c: In function 'update_balloon_stats': >>>

Re: [PATCH v2 0/7] efi: Enhance capsule loader to support signed Quark images

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > This addresses the review feedback provided on round 1, specifically > - refactored queue to keep the Quark mess in > - only check for CSH on Quark CPUs > - added some smaller cleanups of the capsule loader > -

Re: [PATCH v2 0/7] efi: Enhance capsule loader to support signed Quark images

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > This addresses the review feedback provided on round 1, specifically > - refactored queue to keep the Quark mess in > - only check for CSH on Quark CPUs > - added some smaller cleanups of the capsule loader > - documented capsule header /

Re: [PATCH] regulator: core: Limit propagation of parent voltage count and list

On Fri, Mar 24, 2017 at 01:09:52PM -0700, Matthias Kaehlcke wrote: > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c > index 53d4fc70dbd0..121838e0125b 100644 > --- a/drivers/regulator/core.c > +++ b/drivers/regulator/core.c > @@ -2487,6 +2487,10 @@ static int

Re: [PATCH] regulator: core: Limit propagation of parent voltage count and list

On Fri, Mar 24, 2017 at 01:09:52PM -0700, Matthias Kaehlcke wrote: > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c > index 53d4fc70dbd0..121838e0125b 100644 > --- a/drivers/regulator/core.c > +++ b/drivers/regulator/core.c > @@ -2487,6 +2487,10 @@ static int

Re: [PATCH v2 7/7] efi/capsule: Add support for Quark security header

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > The firmware for Quark X102x prepends a security header to the capsule > which is needed to support the mandatory secure boot on this processor. > The header can be detected by checking for the "_CSH" signature and - >

Re: [PATCH v2 7/7] efi/capsule: Add support for Quark security header

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > The firmware for Quark X102x prepends a security header to the capsule > which is needed to support the mandatory secure boot on this processor. > The header can be detected by checking for the "_CSH" signature and - > to avoid any GUID

Re: [PATCH] arc: vdk: Fix support of UIO

On 03/23/2017 10:34 AM, Alexey Brodkin wrote: > MotherBoard section has its "ranges" set to 0xE000_-0xF000_. > But UIO node maps 4 different areas in different memory locations > and all outside MB's ranges. > > That obviously breaks UIO mappings in runtime. > > Signed-off-by: Alexey

Re: [PATCH] arc: vdk: Fix support of UIO

On 03/23/2017 10:34 AM, Alexey Brodkin wrote: > MotherBoard section has its "ranges" set to 0xE000_-0xF000_. > But UIO node maps 4 different areas in different memory locations > and all outside MB's ranges. > > That obviously breaks UIO mappings in runtime. > > Signed-off-by: Alexey

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky wrote: > > > On 03/22/2017 05:16 PM, Dan Streetman wrote: >> >> I have a question about a problem introduced by this commit: >> c275a57f5ec3056f732843b11659d892235faff7 >> "xen/balloon: Set balloon's initial state to

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On Wed, Mar 22, 2017 at 10:13 PM, Boris Ostrovsky wrote: > > > On 03/22/2017 05:16 PM, Dan Streetman wrote: >> >> I have a question about a problem introduced by this commit: >> c275a57f5ec3056f732843b11659d892235faff7 >> "xen/balloon: Set balloon's initial state to number of existing RAM pages"

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On Thu, Mar 23, 2017 at 3:56 AM, Juergen Gross wrote: > On 23/03/17 03:13, Boris Ostrovsky wrote: >> >> >> On 03/22/2017 05:16 PM, Dan Streetman wrote: >>> I have a question about a problem introduced by this commit: >>> c275a57f5ec3056f732843b11659d892235faff7 >>> "xen/balloon:

Re: maybe revert commit c275a57f5ec3 "xen/balloon: Set balloon's initial state to number of existing RAM pages"

On Thu, Mar 23, 2017 at 3:56 AM, Juergen Gross wrote: > On 23/03/17 03:13, Boris Ostrovsky wrote: >> >> >> On 03/22/2017 05:16 PM, Dan Streetman wrote: >>> I have a question about a problem introduced by this commit: >>> c275a57f5ec3056f732843b11659d892235faff7 >>> "xen/balloon: Set balloon's

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 1:22 PM, Peter Zijlstra wrote: > On Fri, Mar 24, 2017 at 11:45:46AM -0700, Andy Lutomirski wrote: >> After playing with it a bit, I found some of the problem: you're >> passing val into EXCEPTION_VALUE, which keeps it live. If I get rid >> of that,

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 1:22 PM, Peter Zijlstra wrote: > On Fri, Mar 24, 2017 at 11:45:46AM -0700, Andy Lutomirski wrote: >> After playing with it a bit, I found some of the problem: you're >> passing val into EXCEPTION_VALUE, which keeps it live. If I get rid >> of that, the generated code is

Re: [PATCH v2 5/7] efi/capsule: Prepare for loading images with security header

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > The Quark security header is nicely located in front of the capsule > image, but we still need to pass the image to the update service as if > there was none. Prepare efi_capsule_update and its user for this by >

Re: [PATCH v2 5/7] efi/capsule: Prepare for loading images with security header

On Fri, Mar 24, 2017 at 7:34 PM, Jan Kiszka wrote: > The Quark security header is nicely located in front of the capsule > image, but we still need to pass the image to the update service as if > there was none. Prepare efi_capsule_update and its user for this by > defining and evaluating a EFI

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 11:45:46AM -0700, Andy Lutomirski wrote: > After playing with it a bit, I found some of the problem: you're > passing val into EXCEPTION_VALUE, which keeps it live. If I get rid > of that, the generated code is great. Right, so I needed that because I land on ud2 through

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 11:45:46AM -0700, Andy Lutomirski wrote: > After playing with it a bit, I found some of the problem: you're > passing val into EXCEPTION_VALUE, which keeps it live. If I get rid > of that, the generated code is great. Right, so I needed that because I land on ud2 through

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 1:14 PM, Peter Zijlstra wrote: > On Fri, Mar 24, 2017 at 12:16:11PM -0700, Andy Lutomirski wrote: >> On Fri, Mar 24, 2017 at 11:13 AM, Peter Zijlstra >> wrote: > >> > Not to mention we cannot use the C11 atomics in kernel

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 1:14 PM, Peter Zijlstra wrote: > On Fri, Mar 24, 2017 at 12:16:11PM -0700, Andy Lutomirski wrote: >> On Fri, Mar 24, 2017 at 11:13 AM, Peter Zijlstra >> wrote: > >> > Not to mention we cannot use the C11 atomics in kernel because we want >> > to be able to runtime patch

Re: deadlock in synchronize_srcu() in debugfs?

On Fri, Mar 24, 2017 at 12:33:22PM -0700, Paul E. McKenney wrote: > On Fri, Mar 24, 2017 at 07:51:47PM +0100, Johannes Berg wrote: > > > > > Yes.  CPU2 has a pre-existing reader that CPU1's synchronize_srcu() > > > must wait for.  But CPU2's reader cannot end until CPU1 releases > > > its lock,

Re: deadlock in synchronize_srcu() in debugfs?

On Fri, Mar 24, 2017 at 12:33:22PM -0700, Paul E. McKenney wrote: > On Fri, Mar 24, 2017 at 07:51:47PM +0100, Johannes Berg wrote: > > > > > Yes.  CPU2 has a pre-existing reader that CPU1's synchronize_srcu() > > > must wait for.  But CPU2's reader cannot end until CPU1 releases > > > its lock,

Re: [PATCH] checkpatch: Flag spam header (X-Spam-Report) to prevent spurious warnings

You can disregard this, I missed the other thread and that looks fine. On 03/24/2017 01:14 PM, John 'Warthog9' Hawley wrote: > On 03/21/2017 11:31 AM, Joe Perches wrote: >> On Tue, 2017-03-21 at 09:30 -0700, John 'Warthog9' Hawley (VMware) wrote: >>> Spamassassin sticks a long (~79 character)

Re: [PATCH] checkpatch: Flag spam header (X-Spam-Report) to prevent spurious warnings

You can disregard this, I missed the other thread and that looks fine. On 03/24/2017 01:14 PM, John 'Warthog9' Hawley wrote: > On 03/21/2017 11:31 AM, Joe Perches wrote: >> On Tue, 2017-03-21 at 09:30 -0700, John 'Warthog9' Hawley (VMware) wrote: >>> Spamassassin sticks a long (~79 character)

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 12:20:37PM -0700, Linus Torvalds wrote: > I doubt it's a show-stopper, if only because nobody cares about UP any > more. Not even the embedded world does. For some obscure reason we recently introduced a variant for virt people. Where it would need memory barriers against

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 12:20:37PM -0700, Linus Torvalds wrote: > I doubt it's a show-stopper, if only because nobody cares about UP any > more. Not even the embedded world does. For some obscure reason we recently introduced a variant for virt people. Where it would need memory barriers against

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 12:16:11PM -0700, Andy Lutomirski wrote: > On Fri, Mar 24, 2017 at 11:13 AM, Peter Zijlstra wrote: > > Not to mention we cannot use the C11 atomics in kernel because we want > > to be able to runtime patch LOCK prefixes when only 1 CPU is available.

Re: locking/atomic: Introduce atomic_try_cmpxchg()

On Fri, Mar 24, 2017 at 12:16:11PM -0700, Andy Lutomirski wrote: > On Fri, Mar 24, 2017 at 11:13 AM, Peter Zijlstra wrote: > > Not to mention we cannot use the C11 atomics in kernel because we want > > to be able to runtime patch LOCK prefixes when only 1 CPU is available. > > Is this really a

Re: [PATCH] checkpatch: Flag spam header (X-Spam-Report) to prevent spurious warnings

On 03/21/2017 11:31 AM, Joe Perches wrote: > On Tue, 2017-03-21 at 09:30 -0700, John 'Warthog9' Hawley (VMware) wrote: >> Spamassassin sticks a long (~79 character) long string after a >> line that has a single space in it. The line with space causes >> checkpatch to erroniously think that it's in

Re: [PATCH] checkpatch: Flag spam header (X-Spam-Report) to prevent spurious warnings

On 03/21/2017 11:31 AM, Joe Perches wrote: > On Tue, 2017-03-21 at 09:30 -0700, John 'Warthog9' Hawley (VMware) wrote: >> Spamassassin sticks a long (~79 character) long string after a >> line that has a single space in it. The line with space causes >> checkpatch to erroniously think that it's in

<    1   2   3   4   5   6   7   8   9   10   >