[PATCH v3 3/7] pinctrl: armada-37xx: Add pin controller support for Armada 37xx

The Armada 37xx SoC come with 2 pin controllers: one on the south bridge (managing 28 pins) and one on the north bridge (managing 36 pins). At the hardware level the controller configure the pins by group and not pin by pin. This constraint is reflected in the design of the driver: only the group

[PATCH v3 3/7] pinctrl: armada-37xx: Add pin controller support for Armada 37xx

The Armada 37xx SoC come with 2 pin controllers: one on the south bridge (managing 28 pins) and one on the north bridge (managing 36 pins). At the hardware level the controller configure the pins by group and not pin by pin. This constraint is reflected in the design of the driver: only the group

Re: [PATCH] kasan: avoid -Wmaybe-uninitialized warning

On Thu, Mar 23, 2017 at 4:04 PM, Arnd Bergmann wrote: > gcc-7 produces this warning: > > mm/kasan/report.c: In function 'kasan_report': > mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used > uninitialized in this function [-Werror=maybe-uninitialized] >

Re: [PATCH] kasan: avoid -Wmaybe-uninitialized warning

On Thu, Mar 23, 2017 at 4:04 PM, Arnd Bergmann wrote: > gcc-7 produces this warning: > > mm/kasan/report.c: In function 'kasan_report': > mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used > uninitialized in this function [-Werror=maybe-uninitialized] >

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote: > Does the patch from Jason in the > > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > > thread fix the issue for you? In brief, yes it does. I followed up on that

[PATCH v3 7/7] ARM64: dts: marvell: armada37xx: add pinctrl definition

Start to populate the device tree of the Armada 37xx with the pincontrol configuration used on the board providing a dts. Signed-off-by: Gregory CLEMENT --- arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +-

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote: > Does the patch from Jason in the > > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > > thread fix the issue for you? In brief, yes it does. I followed up on that

[PATCH v3 7/7] ARM64: dts: marvell: armada37xx: add pinctrl definition

Start to populate the device tree of the Armada 37xx with the pincontrol configuration used on the board providing a dts. Signed-off-by: Gregory CLEMENT --- arch/arm64/boot/dts/marvell/armada-3720-db.dts | 8 +- arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 31 +++- 2

[PATCH] x86/syscalls/32: ignore arch_prctl for other architectures

sys_arch_prctl is only provided on x86, and there is no reason to add it elsewhere. However, including it on the 32-bit syscall table caused a warning for most configurations on non-x86: :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp] This adds an exception to the syscall

[PATCH v3 6/7] ARM64: dts: marvell: Add pinctrl nodes for Armada 3700

Add the nodes for the two pin controller present in the Armada 37xx SoCs. Initially the node was named gpio1 using the same name that for the register range in the datasheet. However renaming it pinctr_nb (nb for North Bridge) makes more sens. Signed-off-by: Gregory CLEMENT

[PATCH v3 5/7] pinctrl: aramda-37xx: Add irqchip support

The Armada 37xx SoCs can handle interrupt through GPIO. However it can only manage the edge ones. The way the interrupt are managed are classical so we can use the generic interrupt chip model. The only unusual "feature" is that many interrupts are connected to the parent interrupt controller.

[PATCH] x86/syscalls/32: ignore arch_prctl for other architectures

sys_arch_prctl is only provided on x86, and there is no reason to add it elsewhere. However, including it on the 32-bit syscall table caused a warning for most configurations on non-x86: :1328:2: warning: #warning syscall arch_prctl not implemented [-Wcpp] This adds an exception to the syscall

[PATCH v3 6/7] ARM64: dts: marvell: Add pinctrl nodes for Armada 3700

Add the nodes for the two pin controller present in the Armada 37xx SoCs. Initially the node was named gpio1 using the same name that for the register range in the datasheet. However renaming it pinctr_nb (nb for North Bridge) makes more sens. Signed-off-by: Gregory CLEMENT ---

[PATCH v3 5/7] pinctrl: aramda-37xx: Add irqchip support

The Armada 37xx SoCs can handle interrupt through GPIO. However it can only manage the edge ones. The way the interrupt are managed are classical so we can use the generic interrupt chip model. The only unusual "feature" is that many interrupts are connected to the parent interrupt controller.

[PATCH] virtio_balloon: prevent uninitialized variable use

The latest gcc-7.0.1 snapshot reports a new warning: virtio/virtio_balloon.c: In function 'update_balloon_stats': virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in this function [-Werror=uninitialized] virtio/virtio_balloon.c:260:26: error: 'events[3]' is used

[PATCH] virtio_balloon: prevent uninitialized variable use

The latest gcc-7.0.1 snapshot reports a new warning: virtio/virtio_balloon.c: In function 'update_balloon_stats': virtio/virtio_balloon.c:258:26: error: 'events[2]' is used uninitialized in this function [-Werror=uninitialized] virtio/virtio_balloon.c:260:26: error: 'events[3]' is used

[PATCH] EDAC, pnd2_edac: fix build error without CONFIG_EDAC_DEBUG

Calling into functions inside of the #ifdef causes an obvious compile error: drivers/edac/pnd2_edac.c: In function 'pnd2_init': drivers/edac/pnd2_edac.c:1521:2: error: implicit declaration of function 'setup_pnd2_debug'; did you mean 'setup_log_buf'? [-Werror=implicit-function-declaration]

[PATCH] EDAC, pnd2_edac: fix build error without CONFIG_EDAC_DEBUG

Calling into functions inside of the #ifdef causes an obvious compile error: drivers/edac/pnd2_edac.c: In function 'pnd2_init': drivers/edac/pnd2_edac.c:1521:2: error: implicit declaration of function 'setup_pnd2_debug'; did you mean 'setup_log_buf'? [-Werror=implicit-function-declaration]

[PATCH] ALSA: au88x0: avoid theoretical uninitialized access

The latest gcc-7.0.1 snapshot points out that we if nr_ch is zero, we never initialize some variables: sound/pci/au88x0/au88x0_core.c: In function 'vortex_adb_allocroute': sound/pci/au88x0/au88x0_core.c:2304:68: error: 'mix[0]' may be used uninitialized in this function

[PATCH] ALSA: au88x0: avoid theoretical uninitialized access

The latest gcc-7.0.1 snapshot points out that we if nr_ch is zero, we never initialize some variables: sound/pci/au88x0/au88x0_core.c: In function 'vortex_adb_allocroute': sound/pci/au88x0/au88x0_core.c:2304:68: error: 'mix[0]' may be used uninitialized in this function

Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall

Okay well then people are fine with a BUG_ON approach. I will do a next iteration tailored to that. I will also try to add the static inline suggestion from Peter. On Wed, Mar 22, 2017 at 1:54 PM, H. Peter Anvin wrote: > On 03/22/17 13:49, Thomas Garnier wrote: >> >> We can

Re: [PATCH v4 1/4] syscalls: Restore address limit after a syscall

Okay well then people are fine with a BUG_ON approach. I will do a next iteration tailored to that. I will also try to add the static inline suggestion from Peter. On Wed, Mar 22, 2017 at 1:54 PM, H. Peter Anvin wrote: > On 03/22/17 13:49, Thomas Garnier wrote: >> >> We can default to BUGging. I

Re: [PATCH 00/23] hisi_sas: error handling and other misc fixes and improvements

John Garry writes: John, > This patchset introduces a range of error handling > and other misc improvements for the HiSilicon SAS > controller, including: > - controller reset function > - softreset for SATA error handling > - fixes for slot free'ing > - v2 hw error

Re: [PATCH 00/23] hisi_sas: error handling and other misc fixes and improvements

John Garry writes: John, > This patchset introduces a range of error handling > and other misc improvements for the HiSilicon SAS > controller, including: > - controller reset function > - softreset for SATA error handling > - fixes for slot free'ing > - v2 hw error handling improvements > -

Re: [PATCH] ARM: dts: at91: add envelope detector mux to the Axentia TSE-850

On 17/03/2017 at 23:24:46 +0100, Peter Rosin wrote: > The envelope detector can analyze 6 different signals, selectable with a > mux controlled by three gpio pins. > > Signed-off-by: Peter Rosin > --- > > Hi! > > This patch makes use of the mux subsystem and a couple of

Re: [PATCH] ARM: dts: at91: add envelope detector mux to the Axentia TSE-850

On 17/03/2017 at 23:24:46 +0100, Peter Rosin wrote: > The envelope detector can analyze 6 different signals, selectable with a > mux controlled by three gpio pins. > > Signed-off-by: Peter Rosin > --- > > Hi! > > This patch makes use of the mux subsystem and a couple of drivers > available in

[GIT PULL] sound fixes for 4.11-rc4

Linus, please pull sound fixes for v4.11-rc4 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-4.11-rc4 The topmost commit is 3f307834e695f59dac4337a40316bdecfb9d0508 sound fixes for 4.11-rc4

[GIT PULL] sound fixes for 4.11-rc4

Linus, please pull sound fixes for v4.11-rc4 from: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git tags/sound-4.11-rc4 The topmost commit is 3f307834e695f59dac4337a40316bdecfb9d0508 sound fixes for 4.11-rc4

[GIT PULL] Btrfs

Hi Linus We have a small set of fixes for the next RC: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 Zygo tracked down a very old bug with inline compressed extents. I didn't tag this one for stable because I want to do individual tested backports. It's

[GIT PULL] Btrfs

Hi Linus We have a small set of fixes for the next RC: git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs.git for-linus-4.11 Zygo tracked down a very old bug with inline compressed extents. I didn't tag this one for stable because I want to do individual tested backports. It's

Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

Hi Christoph! Hi Michael! (Mail roughly based on text from https://bugzilla.kernel.org/show_bug.cgi?id=194911 ) I'm seeing random crashes during boot every few boot attempts when running Linux 4.11-rc/mainline in a Fedora 26 guest under a CentOS7 host (CPU: Intel(R) Pentium(R) CPU G3220) using

Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

Hi Christoph! Hi Michael! (Mail roughly based on text from https://bugzilla.kernel.org/show_bug.cgi?id=194911 ) I'm seeing random crashes during boot every few boot attempts when running Linux 4.11-rc/mainline in a Fedora 26 guest under a CentOS7 host (CPU: Intel(R) Pentium(R) CPU G3220) using

[PATCH -v3 6/8] sched,tracing: Update trace_sched_pi_setprio()

Pass the PI donor task, instead of a numerical priority. Numerical priorities are not sufficient to describe state ever since SCHED_DEADLINE. Annotate all sched tracepoints that are currently broken; fixing them will bork userspace. *hate*. Reviewed-by: Steven Rostedt

Re: [PATCH] x86/boot: Support uncompressed kernel

On Thu, Mar 23, 2017 at 5:51 AM, Chao Peng wrote: > Compressed kernel has its own drawback: uncompressing takes time. Even > though the time is short enough to ignore for most cases but for cases that > time is critical this is still a big number. In our on-going

[PATCH -v3 6/8] sched,tracing: Update trace_sched_pi_setprio()

Pass the PI donor task, instead of a numerical priority. Numerical priorities are not sufficient to describe state ever since SCHED_DEADLINE. Annotate all sched tracepoints that are currently broken; fixing them will bork userspace. *hate*. Reviewed-by: Steven Rostedt Signed-off-by: Peter

Re: [PATCH] x86/boot: Support uncompressed kernel

On Thu, Mar 23, 2017 at 5:51 AM, Chao Peng wrote: > Compressed kernel has its own drawback: uncompressing takes time. Even > though the time is short enough to ignore for most cases but for cases that > time is critical this is still a big number. In our on-going optimization > for kernel boot

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On 23.03.2017 15:56, Christoph Hellwig wrote: > Does the patch from Jason in the > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > thread fix the issue for you? Ha, sorry, I'm travelling and wasn't aware that Laura earlier today did

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On 23.03.2017 15:56, Christoph Hellwig wrote: > Does the patch from Jason in the > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > thread fix the issue for you? Ha, sorry, I'm travelling and wasn't aware that Laura earlier today did

Re: [PATCH] arm/arm64: KVM: send SIGBUS error to qemu

Hi Dongjiu Geng, On 23/03/17 13:01, Dongjiu Geng wrote: > when the pfn is KVM_PFN_ERR_HWPOISON, it indicates to send > SIGBUS signal from KVM's fault-handling code to qemu, qemu > can handle this signal according to the fault address. I'm afraid I beat you to it on this one:

Re: [PATCH] arm/arm64: KVM: send SIGBUS error to qemu

Hi Dongjiu Geng, On 23/03/17 13:01, Dongjiu Geng wrote: > when the pfn is KVM_PFN_ERR_HWPOISON, it indicates to send > SIGBUS signal from KVM's fault-handling code to qemu, qemu > can handle this signal according to the fault address. I'm afraid I beat you to it on this one:

[PATCH] reiserfs: avoid a -Wmaybe-uninitialized warning

The latest gcc-7.0.1 snapshot warns about an unintialized variable use: In file included from fs/reiserfs/lbalance.c:8:0: fs/reiserfs/lbalance.c: In function 'leaf_item_bottle.isra.3': fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)_ih+8).v' may be used uninitialized in this function

[PATCH] reiserfs: avoid a -Wmaybe-uninitialized warning

The latest gcc-7.0.1 snapshot warns about an unintialized variable use: In file included from fs/reiserfs/lbalance.c:8:0: fs/reiserfs/lbalance.c: In function 'leaf_item_bottle.isra.3': fs/reiserfs/reiserfs.h:1279:13: error: '*((void *)_ih+8).v' may be used uninitialized in this function

[PATCH -v3 2/8] sched/rtmutex/deadline: Fix a PI crash for deadline tasks

From: Xunlei Pang A crash happened while I was playing with deadline PI rtmutex. BUG: unable to handle kernel NULL pointer dereference at 0018 IP: [] rt_mutex_get_top_task+0x1f/0x30 PGD 232a75067 PUD 230947067 PMD 0 Oops: [#1] SMP CPU: 1

[PATCH -v3 2/8] sched/rtmutex/deadline: Fix a PI crash for deadline tasks

From: Xunlei Pang A crash happened while I was playing with deadline PI rtmutex. BUG: unable to handle kernel NULL pointer dereference at 0018 IP: [] rt_mutex_get_top_task+0x1f/0x30 PGD 232a75067 PUD 230947067 PMD 0 Oops: [#1] SMP CPU: 1 PID: 10994 Comm:

[PATCH -v3 0/8] PI vs SCHED_DEADLINE fixes

Now that this pesky little problem with futexes is (hopefully) dealt with; https://lkml.kernel.org/r/20170322103547.756091...@infradead.org We can get on with fixing the actual bug this all started out with. These patches, started by Xunlei Pang, rework the PI infrastructure a bit fixing

[PATCH -v3 1/8] rtmutex: Deboost before waking up the top waiter

From: Xunlei Pang We should deboost before waking the high-priority task, such that we don't run two tasks with the same "state" (priority, deadline, sched_class, etc). In order to make sure the boosting task doesn't start running between unlock and deboost (due to 'spurious'

[PATCH -v3 4/8] rtmutex: Clean up

Previous patches changed the meaning of the return value of rt_mutex_slowunlock(); update comments and code to reflect this. Signed-off-by: Peter Zijlstra (Intel) --- kernel/futex.c |7 --- kernel/locking/rtmutex.c| 28

[PATCH -v3 0/8] PI vs SCHED_DEADLINE fixes

Now that this pesky little problem with futexes is (hopefully) dealt with; https://lkml.kernel.org/r/20170322103547.756091...@infradead.org We can get on with fixing the actual bug this all started out with. These patches, started by Xunlei Pang, rework the PI infrastructure a bit fixing

[PATCH -v3 1/8] rtmutex: Deboost before waking up the top waiter

From: Xunlei Pang We should deboost before waking the high-priority task, such that we don't run two tasks with the same "state" (priority, deadline, sched_class, etc). In order to make sure the boosting task doesn't start running between unlock and deboost (due to 'spurious' wakeup), we move

[PATCH -v3 4/8] rtmutex: Clean up

Previous patches changed the meaning of the return value of rt_mutex_slowunlock(); update comments and code to reflect this. Signed-off-by: Peter Zijlstra (Intel) --- kernel/futex.c |7 --- kernel/locking/rtmutex.c| 28 +---

[PATCH -v3 7/8] rtmutex: Fix PI chain order integrity

rt_mutex_waiter::prio is a copy of task_struct::prio which is updated during the PI chain walk, such that the PI chain order isn't messed up by (asynchronous) task state updates. Currently rt_mutex_waiter_less() uses task state for deadline tasks; this is broken, since the task state can, as said

[PATCH -v3 7/8] rtmutex: Fix PI chain order integrity

rt_mutex_waiter::prio is a copy of task_struct::prio which is updated during the PI chain walk, such that the PI chain order isn't messed up by (asynchronous) task state updates. Currently rt_mutex_waiter_less() uses task state for deadline tasks; this is broken, since the task state can, as said

[PATCH -v3 5/8] sched/rtmutex: Refactor rt_mutex_setprio()

With the introduction of SCHED_DEADLINE the whole notion that priority is a single number is gone, therefore the @prio argument to rt_mutex_setprio() doesn't make sense anymore. So rework the code to pass a pi_task instead. Note this also fixes a problem with pi_top_task caching; previously we

[PATCH -v3 5/8] sched/rtmutex: Refactor rt_mutex_setprio()

With the introduction of SCHED_DEADLINE the whole notion that priority is a single number is gone, therefore the @prio argument to rt_mutex_setprio() doesn't make sense anymore. So rework the code to pass a pi_task instead. Note this also fixes a problem with pi_top_task caching; previously we

[PATCH -v3 8/8] rtmutex: Fix more prio comparisons

There was a pure ->prio comparison left in try_to_wake_rt_mutex(), convert it to use rt_mutex_waiter_less(), noting that greater-or-equal is not-less (both in kernel priority view). This necessitated the introduction of cmp_task() which creates a pointer to an unnamed stack variable of struct

[PATCH -v3 8/8] rtmutex: Fix more prio comparisons

There was a pure ->prio comparison left in try_to_wake_rt_mutex(), convert it to use rt_mutex_waiter_less(), noting that greater-or-equal is not-less (both in kernel priority view). This necessitated the introduction of cmp_task() which creates a pointer to an unnamed stack variable of struct

[PATCH -v3 3/8] sched/deadline/rtmutex: Dont miss the dl_runtime/dl_period update

From: Xunlei Pang Currently dl tasks will actually return at the very beginning of rt_mutex_adjust_prio_chain() in !detect_deadlock cases: if (waiter->prio == task->prio) { if (!detect_deadlock) goto out_unlock_pi; // out here else

[PATCH -v3 3/8] sched/deadline/rtmutex: Dont miss the dl_runtime/dl_period update

From: Xunlei Pang Currently dl tasks will actually return at the very beginning of rt_mutex_adjust_prio_chain() in !detect_deadlock cases: if (waiter->prio == task->prio) { if (!detect_deadlock) goto out_unlock_pi; // out here else requeue = false;

[PATCH] kasan: avoid -Wmaybe-uninitialized warning

gcc-7 produces this warning: mm/kasan/report.c: In function 'kasan_report': mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used uninitialized in this function [-Werror=maybe-uninitialized] print_shadow_for_address(info->first_bad_addr);

[PATCH] kasan: avoid -Wmaybe-uninitialized warning

gcc-7 produces this warning: mm/kasan/report.c: In function 'kasan_report': mm/kasan/report.c:351:3: error: 'info.first_bad_addr' may be used uninitialized in this function [-Werror=maybe-uninitialized] print_shadow_for_address(info->first_bad_addr);

[PATCH] scsi: advansys: fix uninitialized data access

gcc-7.0.1 now warns about a previously unnoticed access of uninitialized struct members: drivers/scsi/advansys.c: In function 'AscMsgOutSDTR': drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > > Putting these together: > > > > The memory was allocated in usb_internal_control_msg() line 93. > > The later events occurred within the call in line 100 to > > usb_start_wait_urb(). > > > > The invalid access occurred

[PATCH] scsi: advansys: fix uninitialized data access

gcc-7.0.1 now warns about a previously unnoticed access of uninitialized struct members: drivers/scsi/advansys.c: In function 'AscMsgOutSDTR': drivers/scsi/advansys.c:3860:26: error: '*((void *)_buf+5)' may be used uninitialized in this function [-Werror=maybe-uninitialized]

Re: usb: use-after-free write in usb_hcd_link_urb_to_ep

On Thu, 23 Mar 2017, Dmitry Vyukov wrote: > > Putting these together: > > > > The memory was allocated in usb_internal_control_msg() line 93. > > The later events occurred within the call in line 100 to > > usb_start_wait_urb(). > > > > The invalid access occurred

[PATCH] hwmon: asus_atk0110.c fix uninitialized data access

The latest gcc-7 snapshot adds a warning to point out that when atk_read_value_old or atk_read_value_new fails, we copy uninitialized data into sensor->cached_value: drivers/hwmon/asus_atk0110.c: In function 'atk_input_show': drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used

[PATCH] hwmon: asus_atk0110.c fix uninitialized data access

The latest gcc-7 snapshot adds a warning to point out that when atk_read_value_old or atk_read_value_new fails, we copy uninitialized data into sensor->cached_value: drivers/hwmon/asus_atk0110.c: In function 'atk_input_show': drivers/hwmon/asus_atk0110.c:651:26: error: 'value' may be used

Re: [PATCH] arm64: add dump_stack to show_regs

On Mon, Mar 20, 2017 at 09:05:04PM +0800, Kefeng Wang wrote: > > > On 2017/3/20 19:02, Mark Rutland wrote: > > On Sun, Mar 19, 2017 at 03:15:25PM +0800, Ding Tianhong wrote: > >> Recently I found that when the system trigger a soft lockup in interrupt, > >> there is only showing the regs, but no

Re: [PATCH] arm64: add dump_stack to show_regs

On Mon, Mar 20, 2017 at 09:05:04PM +0800, Kefeng Wang wrote: > > > On 2017/3/20 19:02, Mark Rutland wrote: > > On Sun, Mar 19, 2017 at 03:15:25PM +0800, Ding Tianhong wrote: > >> Recently I found that when the system trigger a soft lockup in interrupt, > >> there is only showing the regs, but no

International Monetary Fund (IMF)...(ATM-7750)

International Reconciliation and Logistics Vault International Monetary Fund (IMF) COMPENSATION SETTLEMENT OF ESCROW ACCOUNTS. It is a pleasure to write you that we have reconciled with our logistic department on the reimbursement of some fund spent by you during the cause of your inadequate

International Monetary Fund (IMF)...(ATM-7750)

International Reconciliation and Logistics Vault International Monetary Fund (IMF) COMPENSATION SETTLEMENT OF ESCROW ACCOUNTS. It is a pleasure to write you that we have reconciled with our logistic department on the reimbursement of some fund spent by you during the cause of your inadequate

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote: > Does the patch from Jason in the > > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > > thread fix the issue for you? I didn't see this thread before. I'll check

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:56:22PM +0100, Christoph Hellwig wrote: > Does the patch from Jason in the > > "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for > virtqueues") causes crashes in guest" > > thread fix the issue for you? I didn't see this thread before. I'll check

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:51:25PM +0100, Thorsten Leemhuis wrote: > Hi Christoph! Hi Michael! > > (Mail roughly based on text from > https://bugzilla.kernel.org/show_bug.cgi?id=194911 ) > > I'm seeing random crashes during boot every few boot attempts when > running Linux 4.11-rc/mainline in a

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

On Thu, Mar 23, 2017 at 03:51:25PM +0100, Thorsten Leemhuis wrote: > Hi Christoph! Hi Michael! > > (Mail roughly based on text from > https://bugzilla.kernel.org/show_bug.cgi?id=194911 ) > > I'm seeing random crashes during boot every few boot attempts when > running Linux 4.11-rc/mainline in a

[PATCH 3/3] infiniband: hns: avoid gcc-7.0.1 warning for uninitialized data

hns_roce_v1_cq_set_ci() calls roce_set_bit() on an uninitialized field, which will then change only a few of its bits, causing a warning with the latest gcc: infiniband/hw/hns/hns_roce_hw_v1.c: In function 'hns_roce_v1_cq_set_ci': infiniband/hw/hns/hns_roce_hw_v1.c:1854:23: error: 'doorbell[1]'

[PATCH 2/3] net: hns: fix uninitialized data use

When dev_dbg() is enabled, we print uninitialized data, as gcc-7.0.1 now points out: ethernet/hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_set_promisc_tcam': ethernet/hisilicon/hns/hns_dsaf_main.c:2947:75: error: 'tbl_tcam_data.low.val' may be used uninitialized in this function

[PATCH 3/3] infiniband: hns: avoid gcc-7.0.1 warning for uninitialized data

hns_roce_v1_cq_set_ci() calls roce_set_bit() on an uninitialized field, which will then change only a few of its bits, causing a warning with the latest gcc: infiniband/hw/hns/hns_roce_hw_v1.c: In function 'hns_roce_v1_cq_set_ci': infiniband/hw/hns/hns_roce_hw_v1.c:1854:23: error: 'doorbell[1]'

[PATCH 2/3] net: hns: fix uninitialized data use

When dev_dbg() is enabled, we print uninitialized data, as gcc-7.0.1 now points out: ethernet/hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_set_promisc_tcam': ethernet/hisilicon/hns/hns_dsaf_main.c:2947:75: error: 'tbl_tcam_data.low.val' may be used uninitialized in this function

[PATCH 1/3] net: hns: avoid gcc-7.0.1 warning for uninitialized data

hns_dsaf_set_mac_key() calls dsaf_set_field() on an uninitialized field, which will then change only a few of its bits, causing a warning with the latest gcc: hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_set_mac_uc_entry': hisilicon/hns/hns_dsaf_reg.h:1046:12: error:

[PATCH 1/3] net: hns: avoid gcc-7.0.1 warning for uninitialized data

hns_dsaf_set_mac_key() calls dsaf_set_field() on an uninitialized field, which will then change only a few of its bits, causing a warning with the latest gcc: hisilicon/hns/hns_dsaf_main.c: In function 'hns_dsaf_set_mac_uc_entry': hisilicon/hns/hns_dsaf_reg.h:1046:12: error:

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

Does the patch from Jason in the "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest" thread fix the issue for you?

Re: Random guest crashes since 5c34d002dcc7 ("virtio_pci: use shared interrupts for virtqueues")

Does the patch from Jason in the "[REGRESSION] 07ec51480b5e ("virtio_pci: use shared interrupts for virtqueues") causes crashes in guest" thread fix the issue for you?

[PATCH] scsi: lpfc: fix building without debugfs support

On a randconfig build without CONFIG_SCSI_LPFC_DEBUG_FS, I ran into multiple compile failures: drivers/scsi/lpfc/lpfc_debugfs.h: In function 'lpfc_debug_dump_wq': drivers/scsi/lpfc/lpfc_debugfs.h:405:15: error: 'DUMP_FCP' undeclared (first use in this function); did you mean 'DUMP_VAR'?

[PATCH] scsi: lpfc: fix building without debugfs support

On a randconfig build without CONFIG_SCSI_LPFC_DEBUG_FS, I ran into multiple compile failures: drivers/scsi/lpfc/lpfc_debugfs.h: In function 'lpfc_debug_dump_wq': drivers/scsi/lpfc/lpfc_debugfs.h:405:15: error: 'DUMP_FCP' undeclared (first use in this function); did you mean 'DUMP_VAR'?

Re: Still OOM problems with 4.9er/4.10er kernels

On 2017/03/23 17:38, Mike Galbraith wrote: > On Thu, 2017-03-23 at 08:16 +0100, Gerhard Wiesinger wrote: >> On 21.03.2017 08:13, Mike Galbraith wrote: >>> On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote: >>> Is this the correct information? >>> Incomplete, but enough to reiterate

Re: Still OOM problems with 4.9er/4.10er kernels

On 2017/03/23 17:38, Mike Galbraith wrote: > On Thu, 2017-03-23 at 08:16 +0100, Gerhard Wiesinger wrote: >> On 21.03.2017 08:13, Mike Galbraith wrote: >>> On Tue, 2017-03-21 at 06:59 +0100, Gerhard Wiesinger wrote: >>> Is this the correct information? >>> Incomplete, but enough to reiterate

deadlock in synchronize_srcu() in debugfs?

Hi, Before I go hunting - has anyone seen a deadlock in synchronize_srcu() in debugfs_remove() before? We're observing that with our (backported, but very recent) driver against 4.9 (and 4.10, I think), but there are no backports of any debugfs things so the backport itself doesn't seem like a

deadlock in synchronize_srcu() in debugfs?

Hi, Before I go hunting - has anyone seen a deadlock in synchronize_srcu() in debugfs_remove() before? We're observing that with our (backported, but very recent) driver against 4.9 (and 4.10, I think), but there are no backports of any debugfs things so the backport itself doesn't seem like a

Re: netlink: NULL timer crash

On Thu, Mar 23, 2017 at 5:55 AM, Dmitry Vyukov wrote: > Hello, > > The following program triggers call of NULL timer func: > > https://gist.githubusercontent.com/dvyukov/c210d01c74b911273469a93862ea7788/raw/2a3182772a6a6e20af3e71c02c2a1c2895d803fb/gistfile1.txt > > > BUG:

Re: netlink: NULL timer crash

On Thu, Mar 23, 2017 at 5:55 AM, Dmitry Vyukov wrote: > Hello, > > The following program triggers call of NULL timer func: > > https://gist.githubusercontent.com/dvyukov/c210d01c74b911273469a93862ea7788/raw/2a3182772a6a6e20af3e71c02c2a1c2895d803fb/gistfile1.txt > > > BUG: unable to handle kernel

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

* Sebastian Reichel [170322 18:02]: > Hi, > > On Wed, Mar 22, 2017 at 08:57:16AM -0700, Tony Lindgren wrote: > > * Pavel Machek [170322 02:29]: > > > On Wed 2017-03-22 01:09:11, Sebastian Reichel wrote: > > > > This fixes compilation for files, that try to include

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

* Sebastian Reichel [170322 18:02]: > Hi, > > On Wed, Mar 22, 2017 at 08:57:16AM -0700, Tony Lindgren wrote: > > * Pavel Machek [170322 02:29]: > > > On Wed 2017-03-22 01:09:11, Sebastian Reichel wrote: > > > > This fixes compilation for files, that try to include the > > > > cpcap header in

RE: [PATCH] Add initial SX3000b platform code to MIPS arch

Will be sending a revised version splitting the irqchip related code to a different patch and using a generic platform code... -Original Message- From: Amit Kama IL Sent: Wednesday, March 22, 2017 7:38 AM To: 'r...@linux-mips.org' Cc: 'devicet...@vger.kernel.org'

RE: [PATCH] Add initial SX3000b platform code to MIPS arch

Will be sending a revised version splitting the irqchip related code to a different patch and using a generic platform code... -Original Message- From: Amit Kama IL Sent: Wednesday, March 22, 2017 7:38 AM To: 'r...@linux-mips.org' Cc: 'devicet...@vger.kernel.org' ;

Re: [PATCH] ARM: imx_v6_v7_defconfig: Select SMSC_PHY

Hi Leonard, On Wed, Mar 22, 2017 at 04:27:37PM +0200, Leonard Crestez wrote: > The imx6sl-evk board has a LAN8720A ethernet phy supported by SMSC_PHY. > Add this driver to the default imx config since the device is present on > one of the evaluation boards. Upstream currently no evaluation board

Re: [PATCH] ARM: imx_v6_v7_defconfig: Select SMSC_PHY

Hi Leonard, On Wed, Mar 22, 2017 at 04:27:37PM +0200, Leonard Crestez wrote: > The imx6sl-evk board has a LAN8720A ethernet phy supported by SMSC_PHY. > Add this driver to the default imx config since the device is present on > one of the evaluation boards. Upstream currently no evaluation board

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

On Thu, Mar 23, 2017 at 02:41:53PM +0100, Linus Walleij wrote: > On Thu, Mar 23, 2017 at 1:34 PM, Uwe Kleine-König > wrote: > > > Maybe we can make gpiod_get_optional look like this: > > > > if (!dev->of_node && isnt_a_acpi_device(dev) && > >

Re: [PATCH 4/4] tty/serial: sh-sci: remove uneeded IS_ERR_OR_NULL calls

On Thu, Mar 23, 2017 at 02:41:53PM +0100, Linus Walleij wrote: > On Thu, Mar 23, 2017 at 1:34 PM, Uwe Kleine-König > wrote: > > > Maybe we can make gpiod_get_optional look like this: > > > > if (!dev->of_node && isnt_a_acpi_device(dev) && > > !IS_ENABLED(GPIOLIB)) > >

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

On Tue, 14 Mar 2017 00:53:55 +0100 Christian Lamparter wrote: > On Monday, March 13, 2017 10:05:11 PM CET Alban wrote: > > Currently SoC platforms use a firmware request to get the EEPROM data. > > This is mostly a hack and rely on using a user-helper scripts which is >

Re: [PATCH 3/7] ath9k: Add support for reading the EEPROM data using the nvmem API

On Tue, 14 Mar 2017 00:53:55 +0100 Christian Lamparter wrote: > On Monday, March 13, 2017 10:05:11 PM CET Alban wrote: > > Currently SoC platforms use a firmware request to get the EEPROM data. > > This is mostly a hack and rely on using a user-helper scripts which is > > deprecated. A nicer

<    7   8   9   10   11   12   13   14   15   16   >