* Re: [PATCH net] ibmvnic: Harden device login requests
From: David Miller @ 2020-06-12 21:10 UTC (permalink / raw)
To: tlfalcon; +Cc: netdev, linuxppc-dev, danymadden
In-Reply-To: <1591986699-19484-1-git-send-email-tlfalcon@linux.ibm.com>
From: Thomas Falcon <tlfalcon@linux.ibm.com>
Date: Fri, 12 Jun 2020 13:31:39 -0500
> @@ -841,13 +841,14 @@ static int ibmvnic_login(struct net_device *netdev)
> {
> struct ibmvnic_adapter *adapter = netdev_priv(netdev);
> unsigned long timeout = msecs_to_jiffies(30000);
> + int retries = 10;
> int retry_count = 0;
> bool retry;
> int rc;
Reverse christmas tree, please.
^ permalink raw reply
* Re: [PATCH] ASoC: fsl_ssi: Fix bclk calculation for mono channel
From: Nicolin Chen @ 2020-06-12 19:29 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, timur, Xiubo.Lee, linuxppc-dev, tiwai, perex, broonie,
festevam, linux-kernel
In-Reply-To: <1591690768-1691-1-git-send-email-shengjiu.wang@nxp.com>
On Tue, Jun 09, 2020 at 04:19:28PM +0800, Shengjiu Wang wrote:
> For mono channel, ssi will switch to normal mode. In normal
> mode, the Word Length Control bits control the word length
> divider in clock generator, which is different with I2S master
> mode, the word length is fixed to 32bit.
>
> So we refine the famula for mono channel, otherwise there
> will be sound issue for S24_LE.
>
> Fixes: b0a7043d5c2c ("ASoC: fsl_ssi: Caculate bit clock rate using slot number and width")
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
> ---
> sound/soc/fsl/fsl_ssi.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
> index bad89b0d129e..e347776590f7 100644
> --- a/sound/soc/fsl/fsl_ssi.c
> +++ b/sound/soc/fsl/fsl_ssi.c
> @@ -695,6 +695,11 @@ static int fsl_ssi_set_bclk(struct snd_pcm_substream *substream,
> /* Generate bit clock based on the slot number and slot width */
> freq = slots * slot_width * params_rate(hw_params);
>
> + /* The slot_width is not fixed to 32 for normal mode */
> + if (params_channels(hw_params) == 1)
This function has a local variable that you can reuse here:
unsigned int slots = params_channels(hw_params);
> + freq = (slots <= 1 ? 2 : slots) * params_width(hw_params) *
> + params_rate(hw_params);
We have a small section of slots and slot_width calculation
at the top of this function where we can squash these in.
^ permalink raw reply
* [PATCH net] ibmvnic: Flush existing work items before device removal
From: Thomas Falcon @ 2020-06-12 18:34 UTC (permalink / raw)
To: netdev; +Cc: Thomas Falcon, linuxppc-dev, danymadden
Ensure that all scheduled work items have completed before continuing
with device removal and after further event scheduling has been
halted. This patch fixes a bug where a scheduled driver reset event
is processed following device removal.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 1cb2b7f3b2cb..a66fa75976d3 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -5197,6 +5197,9 @@ static int ibmvnic_remove(struct vio_dev *dev)
adapter->state = VNIC_REMOVING;
spin_unlock_irqrestore(&adapter->state_lock, flags);
+ flush_work(&adapter->ibmvnic_reset);
+ flush_delayed_work(&adapter->ibmvnic_delayed_reset);
+
rtnl_lock();
unregister_netdevice(netdev);
--
2.18.1
^ permalink raw reply related
* [PATCH net] ibmvnic: Harden device login requests
From: Thomas Falcon @ 2020-06-12 18:31 UTC (permalink / raw)
To: netdev; +Cc: Thomas Falcon, linuxppc-dev, danymadden
The VNIC driver's "login" command sequence is the final step
in the driver's initialization process with device firmware,
confirming the available device queue resources to be utilized
by the driver. Under high system load, firmware may not respond
to the request in a timely manner or may abort the request. In
such cases, the driver should reattempt the login command
sequence. In case of a device error, the number of retries
is bounded.
Signed-off-by: Thomas Falcon <tlfalcon@linux.ibm.com>
---
drivers/net/ethernet/ibm/ibmvnic.c | 21 +++++++++++++++++----
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ibm/ibmvnic.c b/drivers/net/ethernet/ibm/ibmvnic.c
index 197dc5b2c090..1cb2b7f3b2cb 100644
--- a/drivers/net/ethernet/ibm/ibmvnic.c
+++ b/drivers/net/ethernet/ibm/ibmvnic.c
@@ -841,13 +841,14 @@ static int ibmvnic_login(struct net_device *netdev)
{
struct ibmvnic_adapter *adapter = netdev_priv(netdev);
unsigned long timeout = msecs_to_jiffies(30000);
+ int retries = 10;
int retry_count = 0;
bool retry;
int rc;
do {
retry = false;
- if (retry_count > IBMVNIC_MAX_QUEUES) {
+ if (retry_count > retries) {
netdev_warn(netdev, "Login attempts exceeded\n");
return -1;
}
@@ -862,11 +863,23 @@ static int ibmvnic_login(struct net_device *netdev)
if (!wait_for_completion_timeout(&adapter->init_done,
timeout)) {
- netdev_warn(netdev, "Login timed out\n");
- return -1;
+ netdev_warn(netdev, "Login timed out, retrying...\n");
+ retry = true;
+ adapter->init_done_rc = 0;
+ retry_count++;
+ continue;
}
- if (adapter->init_done_rc == PARTIALSUCCESS) {
+ if (adapter->init_done_rc == ABORTED) {
+ netdev_warn(netdev, "Login aborted, retrying...\n");
+ retry = true;
+ adapter->init_done_rc = 0;
+ retry_count++;
+ /* FW or device may be busy, so
+ * wait a bit before retrying login
+ */
+ msleep(500);
+ } else if (adapter->init_done_rc == PARTIALSUCCESS) {
retry_count++;
release_sub_crqs(adapter, 1);
--
2.18.1
^ permalink raw reply related
* [PATCH v2] tty: serial: cpm_uart: Fix behaviour for non existing GPIOs
From: Christophe Leroy @ 2020-06-12 18:26 UTC (permalink / raw)
To: Greg Kroah-Hartman, Jiri Slaby, Linus Walleij
Cc: linuxppc-dev, linux-kernel, linux-serial
devm_gpiod_get_index() doesn't return NULL but -ENOENT when the
requested GPIO doesn't exist, leading to the following messages:
[ 2.742468] gpiod_direction_input: invalid GPIO (errorpointer)
[ 2.748147] can't set direction for gpio #2: -2
[ 2.753081] gpiod_direction_input: invalid GPIO (errorpointer)
[ 2.758724] can't set direction for gpio #3: -2
[ 2.763666] gpiod_direction_output: invalid GPIO (errorpointer)
[ 2.769394] can't set direction for gpio #4: -2
[ 2.774341] gpiod_direction_input: invalid GPIO (errorpointer)
[ 2.779981] can't set direction for gpio #5: -2
[ 2.784545] ff000a20.serial: ttyCPM1 at MMIO 0xfff00a20 (irq = 39, base_baud = 8250000) is a CPM UART
Use devm_gpiod_get_index_optional() instead.
At the same time, handle the error case and properly exit
with an error.
Fixes: 97cbaf2c829b ("tty: serial: cpm_uart: Convert to use GPIO descriptors")
Cc: stable@vger.kernel.org
Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
v2: Using devm_gpiod_get_index_optional() and exiting if error
---
drivers/tty/serial/cpm_uart/cpm_uart_core.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/cpm_uart/cpm_uart_core.c b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
index a04f74d2e854..4df47d02b34b 100644
--- a/drivers/tty/serial/cpm_uart/cpm_uart_core.c
+++ b/drivers/tty/serial/cpm_uart/cpm_uart_core.c
@@ -1215,7 +1215,12 @@ static int cpm_uart_init_port(struct device_node *np,
pinfo->gpios[i] = NULL;
- gpiod = devm_gpiod_get_index(dev, NULL, i, GPIOD_ASIS);
+ gpiod = devm_gpiod_get_index_optional(dev, NULL, i, GPIOD_ASIS);
+
+ if (IS_ERR(gpiod)) {
+ ret = PTR_ERR(gpiod);
+ goto out_irq;
+ }
if (gpiod) {
if (i == GPIO_RTS || i == GPIO_DTR)
@@ -1237,6 +1242,8 @@ static int cpm_uart_init_port(struct device_node *np,
return cpm_uart_request_port(&pinfo->port);
+out_irq:
+ irq_dispose_mapping(pinfo->port.irq);
out_pram:
cpm_uart_unmap_pram(pinfo, pram);
out_mem:
--
2.25.0
^ permalink raw reply related
* [PATCH V2] powerpc/pseries/svm: Drop unused align argument in alloc_shared_lppaca() function
From: Satheesh Rajendran @ 2020-06-12 14:29 UTC (permalink / raw)
To: linuxppc-dev
Cc: Sukadev Bhattiprolu, Ram Pai, linux-kernel, Satheesh Rajendran,
Laurent Dufour, Thiago Jung Bauermann
Argument "align" in alloc_shared_lppaca() was unused inside the
function. Let's drop it and update code comment for page alignment.
Cc: linux-kernel@vger.kernel.org
Cc: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Cc: Laurent Dufour <ldufour@linux.ibm.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Signed-off-by: Satheesh Rajendran <sathnaga@linux.vnet.ibm.com>
---
V2:
Added reviewed by Thiago.
Dropped align argument as per Michael suggest.
Modified commit msg.
V1: http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200609113909.17236-1-sathnaga@linux.vnet.ibm.com/
---
arch/powerpc/kernel/paca.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/paca.c b/arch/powerpc/kernel/paca.c
index 8d96169c597e..a174d64d9b4d 100644
--- a/arch/powerpc/kernel/paca.c
+++ b/arch/powerpc/kernel/paca.c
@@ -57,8 +57,8 @@ static void *__init alloc_paca_data(unsigned long size, unsigned long align,
#define LPPACA_SIZE 0x400
-static void *__init alloc_shared_lppaca(unsigned long size, unsigned long align,
- unsigned long limit, int cpu)
+static void *__init alloc_shared_lppaca(unsigned long size, unsigned long limit,
+ int cpu)
{
size_t shared_lppaca_total_size = PAGE_ALIGN(nr_cpu_ids * LPPACA_SIZE);
static unsigned long shared_lppaca_size;
@@ -68,6 +68,12 @@ static void *__init alloc_shared_lppaca(unsigned long size, unsigned long align,
if (!shared_lppaca) {
memblock_set_bottom_up(true);
+ /* See Documentation/powerpc/ultravisor.rst for mode details
+ *
+ * UV/HV data share is in PAGE granularity, In order to
+ * minimize the number of pages shared and maximize the
+ * use of a page, let's use page align.
+ */
shared_lppaca =
memblock_alloc_try_nid(shared_lppaca_total_size,
PAGE_SIZE, MEMBLOCK_LOW_LIMIT,
@@ -122,7 +128,7 @@ static struct lppaca * __init new_lppaca(int cpu, unsigned long limit)
return NULL;
if (is_secure_guest())
- lp = alloc_shared_lppaca(LPPACA_SIZE, 0x400, limit, cpu);
+ lp = alloc_shared_lppaca(LPPACA_SIZE, limit, cpu);
else
lp = alloc_paca_data(LPPACA_SIZE, 0x400, limit, cpu);
--
2.26.2
^ permalink raw reply related
* Re: [RFC PATCH v3 0/4] Reuse the dma channel if available in Back-End
From: Mark Brown @ 2020-06-12 13:59 UTC (permalink / raw)
To: nicoleotsuka, Shengjiu Wang, timur, tiwai, festevam, lars,
Xiubo.Lee, alsa-devel, linux-kernel, perex, lgirdwood,
linuxppc-dev
In-Reply-To: <cover.1591947428.git.shengjiu.wang@nxp.com>
On Fri, 12 Jun 2020 15:37:47 +0800, Shengjiu Wang wrote:
> Reuse the dma channel if available in Back-End
>
> Shengjiu Wang (4):
> ASoC: soc-card: export snd_soc_lookup_component_nolocked
> ASoC: dmaengine_pcm: export soc_component_to_pcm
> ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End
> ASoC: fsl_asrc_dma: Fix data copying speed issue with EDMA
>
> [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/4] ASoC: soc-card: export snd_soc_lookup_component_nolocked
commit: 6fbea6b6a838f9aa941fe53a3637fd8d8aab1eba
[2/4] ASoC: dmaengine_pcm: export soc_component_to_pcm
commit: a9a21e1eafc94b79502cab8272b392f7f63ef7bb
[3/4] ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End
commit: 706e2c8811585f42612b6cff218ab3adbe63a4ee
[4/4] ASoC: fsl_asrc_dma: Fix data copying speed issue with EDMA
commit: b287a6d9723c601dd947f1c27d4cc0192e384a5a
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
^ permalink raw reply
* Re: [PATCH v3 20/41] powerpc/book3s64/kuap/kuep: Make KUAP and KUEP a subfeature of PPC_MEM_KEYS
From: kernel test robot @ 2020-06-12 13:36 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev, mpe
Cc: Aneesh Kumar K.V, kbuild-all, bauerman, linuxram
In-Reply-To: <20200610095204.608183-21-aneesh.kumar@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4583 bytes --]
Hi "Aneesh,
I love your patch! Yet something to improve:
[auto build test ERROR on powerpc/next]
[also build test ERROR on next-20200611]
[cannot apply to v5.7]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url: https://github.com/0day-ci/linux/commits/Aneesh-Kumar-K-V/Kernel-userspace-access-execution-prevention-with-hash-translation/20200610-191943
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-randconfig-r003-20200612 (attached as .config)
compiler: powerpc64le-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=powerpc
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
arch/powerpc/mm/book3s64/pkeys.c: In function 'setup_kuep':
>> arch/powerpc/mm/book3s64/pkeys.c:207:28: error: 'boot_cpuid' undeclared (first use in this function)
207 | if (smp_processor_id() == boot_cpuid) {
| ^~~~~~~~~~
arch/powerpc/mm/book3s64/pkeys.c:207:28: note: each undeclared identifier is reported only once for each function it appears in
arch/powerpc/mm/book3s64/pkeys.c: In function 'setup_kuap':
arch/powerpc/mm/book3s64/pkeys.c:228:28: error: 'boot_cpuid' undeclared (first use in this function)
228 | if (smp_processor_id() == boot_cpuid) {
| ^~~~~~~~~~
vim +/boot_cpuid +207 arch/powerpc/mm/book3s64/pkeys.c
92e3da3cf193fd arch/powerpc/mm/pkeys.c Ram Pai 2018-01-18 200
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 201 #ifdef CONFIG_PPC_KUEP
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 202 void __init setup_kuep(bool disabled)
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 203 {
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 204 if (disabled || !early_radix_enabled())
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 205 return;
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 206
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 @207 if (smp_processor_id() == boot_cpuid) {
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 208 pr_info("Activating Kernel Userspace Execution Prevention\n");
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 209 cur_cpu_spec->mmu_features |= MMU_FTR_KUEP;
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 210 }
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 211
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 212 /*
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 213 * Radix always uses key0 of the IAMR to determine if an access is
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 214 * allowed. We set bit 0 (IBM bit 1) of key0, to prevent instruction
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 215 * fetch.
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 216 */
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 217 mtspr(SPRN_IAMR, AMR_KUEP_BLOCKED);
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 218 isync();
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 219 }
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 220 #endif
82b6d6aaa3e29c arch/powerpc/mm/book3s64/pkeys.c Aneesh Kumar K.V 2020-06-10 221
:::::: The code at line 207 was first introduced by commit
:::::: 82b6d6aaa3e29c1f61639eaf61333b3f84b34c4d powerpc/book3s64/kuep: Move KUEP related function outside radix
:::::: TO: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
:::::: CC: 0day robot <lkp@intel.com>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 24649 bytes --]
^ permalink raw reply
* Re: PowerPC KVM-PR issue
From: Christian Zigotzky @ 2020-06-12 13:01 UTC (permalink / raw)
To: linuxppc-dev, npiggin, kvm-ppc@vger.kernel.org
Cc: Darren Stevens, R.T.Dickinson, Christian Zigotzky
In-Reply-To: <54082b17-31bb-f529-2e9e-b84c5a5aa9ec@xenosoft.de>
On 11 June 2020 at 04:47 pm, Christian Zigotzky wrote:
> On 10 June 2020 at 01:23 pm, Christian Zigotzky wrote:
>> On 10 June 2020 at 11:06 am, Christian Zigotzky wrote:
>>> On 10 June 2020 at 00:18 am, Christian Zigotzky wrote:
>>>> Hello,
>>>>
>>>> KVM-PR doesn't work anymore on my Nemo board [1]. I figured out
>>>> that the Git kernels and the kernel 5.7 are affected.
>>>>
>>>> Error message: Fienix kernel: kvmppc_exit_pr_progint: emulation at
>>>> 700 failed (00000000)
>>>>
>>>> I can boot virtual QEMU PowerPC machines with KVM-PR with the
>>>> kernel 5.6 without any problems on my Nemo board.
>>>>
>>>> I tested it with QEMU 2.5.0 and QEMU 5.0.0 today.
>>>>
>>>> Could you please check KVM-PR on your PowerPC machine?
>>>>
>>>> Thanks,
>>>> Christian
>>>>
>>>> [1] https://en.wikipedia.org/wiki/AmigaOne_X1000
>>>
>>> I figured out that the PowerPC updates 5.7-1 [1] are responsible for
>>> the KVM-PR issue. Please test KVM-PR on your PowerPC machines and
>>> check the PowerPC updates 5.7-1 [1].
>>>
>>> Thanks
>>>
>>> [1]
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
>>>
>>>
>> I tested the latest Git kernel with Mac-on-Linux/KVM-PR today.
>> Unfortunately I can't use KVM-PR with MoL anymore because of this
>> issue (see screenshots [1]). Please check the PowerPC updates 5.7-1.
>>
>> Thanks
>>
>> [1]
>> -
>> https://i.pinimg.com/originals/0c/b3/64/0cb364a40241fa2b7f297d4272bbb8b7.png
>> -
>> https://i.pinimg.com/originals/9a/61/d1/9a61d170b1c9f514f7a78a3014ffd18f.png
>>
> Hi All,
>
> I bisected today because of the KVM-PR issue.
>
> Result:
>
> 9600f261acaaabd476d7833cec2dd20f2919f1a0 is the first bad commit
> commit 9600f261acaaabd476d7833cec2dd20f2919f1a0
> Author: Nicholas Piggin <npiggin@gmail.com>
> Date: Wed Feb 26 03:35:21 2020 +1000
>
> powerpc/64s/exception: Move KVM test to common code
>
> This allows more code to be moved out of unrelocated regions. The
> system call KVMTEST is changed to be open-coded and remain in the
> tramp area to avoid having to move it to entry_64.S. The custom
> nature
> of the system call entry code means the hcall case can be made more
> streamlined than regular interrupt handlers.
>
> mpe: Incorporate fix from Nick:
>
> Moving KVM test to the common entry code missed the case of HMI and
> MCE, which do not do __GEN_COMMON_ENTRY (because they don't want to
> switch to virt mode).
>
> This means a MCE or HMI exception that is taken while KVM is
> running a
> guest context will not be switched out of that context, and KVM won't
> be notified. Found by running sigfuz in guest with patched host on
> POWER9 DD2.3, which causes some TM related HMI interrupts (which are
> expected and supposed to be handled by KVM).
>
> This fix adds a __GEN_REALMODE_COMMON_ENTRY for those handlers to add
> the KVM test. This makes them look a little more like other handlers
> that all use __GEN_COMMON_ENTRY.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
> Link:
> https://lore.kernel.org/r/20200225173541.1549955-13-npiggin@gmail.com
>
> :040000 040000 ec21cec22d165f8696d69532734cb2985d532cb0
> 87dd49a9cd7202ec79350e8ca26cea01f1dbd93d M arch
>
> -----
>
> The following commit is the problem: powerpc/64s/exception: Move KVM
> test to common code [1]
>
> These changes were included in the PowerPC updates 5.7-1. [2]
>
> Another test:
>
> git checkout d38c07afc356ddebaa3ed8ecb3f553340e05c969 (PowerPC updates
> 5.7-1 [2] ) -> KVM-PR doesn't work.
>
> After that: git revert d38c07afc356ddebaa3ed8ecb3f553340e05c969 -m 1
> -> KVM-PR works.
>
> Could you please check the first bad commit? [1]
>
> Thanks,
> Christian
>
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9600f261acaaabd476d7833cec2dd20f2919f1a0
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d38c07afc356ddebaa3ed8ecb3f553340e05c969
Hi All,
I tried to revert the __GEN_REALMODE_COMMON_ENTRY fix for the latest Git
kernel and for the stable kernel 5.7.2 but without any success. There
was lot of restructuring work during the kernel 5.7 development time in
the PowerPC area so it isn't possible reactivate the old code. That
means we have lost the whole KVM-PR support. I also reported this issue
to Alexander Graf two days ago. He wrote: "Howdy :). It looks pretty
broken. Have you ever made a bisect to see where the problem comes from?"
Please check the KVM-PR code.
Thanks,
Christian
^ permalink raw reply
* Re: [PATCH kernel] powerpc/xive: Ignore kmemleak false positives
From: Michael Ellerman @ 2020-06-12 12:43 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev; +Cc: Alexey Kardashevskiy, Paul Mackerras
In-Reply-To: <20200612043303.84894-1-aik@ozlabs.ru>
Alexey Kardashevskiy <aik@ozlabs.ru> writes:
> xive_native_provision_pages() allocates memory and passes the pointer to
> OPAL so kmemleak cannot find the pointer usage in the kernel memory and
> produces a false positive report (below) (even if the kernel did scan
> OPAL memory, it is unable to deal with __pa() addresses anyway).
>
> This silences the warning.
>
> unreferenced object 0xc000200350c40000 (size 65536):
> comm "qemu-system-ppc", pid 2725, jiffies 4294946414 (age 70776.530s)
> hex dump (first 32 bytes):
> 02 00 00 00 50 00 00 00 00 00 00 00 00 00 00 00 ....P...........
> 01 00 08 07 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<0000000081ff046c>] xive_native_alloc_vp_block+0x120/0x250
> [<00000000d555d524>] kvmppc_xive_compute_vp_id+0x248/0x350 [kvm]
> [<00000000d69b9c9f>] kvmppc_xive_connect_vcpu+0xc0/0x520 [kvm]
> [<000000006acbc81c>] kvm_arch_vcpu_ioctl+0x308/0x580 [kvm]
> [<0000000089c69580>] kvm_vcpu_ioctl+0x19c/0xae0 [kvm]
> [<00000000902ae91e>] ksys_ioctl+0x184/0x1b0
> [<00000000f3e68bd7>] sys_ioctl+0x48/0xb0
> [<0000000001b2c127>] system_call_exception+0x124/0x1f0
> [<00000000d2b2ee40>] system_call_common+0xe8/0x214
>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
>
> Does kmemleak actually check the OPAL memory?
No it shouldn't.
The memory used by OPAL should all be reserved in the device tree. That
means we never give it to any of the Linux memory allocators, and
therefore kmemleak will never see an allocation from those areas and add
that area to its list of areas to scan.
At least that's my understanding of how kmemleak works.
> Because if it did, we would still have a warning as kmemleak does not
> trace __pa() addresses anyway.
Right.
I think this patch is an OK solution.
It's kind of odd that we donate pages and don't keep track of them. But
they're used by xive until it's reset, and we don't do that until we
kexec, at which point we don't need to know about them anyway.
cheers
^ permalink raw reply
* Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone
From: Alex Ghiti @ 2020-06-12 12:30 UTC (permalink / raw)
To: Atish Patra
Cc: Albert Ou, Anup Patel, linux-kernel@vger.kernel.org List,
Atish Patra, Paul Mackerras, Zong Li, Paul Walmsley,
Palmer Dabbelt, linux-riscv, linuxppc-dev
In-Reply-To: <CAOnJCULMXX1OyLsFZMWj2tMftsCY1rqmN1QxYH+Y7Z-3a5Ap7g@mail.gmail.com>
Hi Atish,
Le 6/11/20 à 5:34 PM, Atish Patra a écrit :
> On Sun, Jun 7, 2020 at 1:01 AM Alexandre Ghiti <alex@ghiti.fr> wrote:
>> This is a preparatory patch for relocatable kernel.
>>
>> The kernel used to be linked at PAGE_OFFSET address and used to be loaded
>> physically at the beginning of the main memory. Therefore, we could use
>> the linear mapping for the kernel mapping.
>>
>> But the relocated kernel base address will be different from PAGE_OFFSET
>> and since in the linear mapping, two different virtual addresses cannot
>> point to the same physical address, the kernel mapping needs to lie outside
>> the linear mapping.
>>
>> In addition, because modules and BPF must be close to the kernel (inside
>> +-2GB window), the kernel is placed at the end of the vmalloc zone minus
>> 2GB, which leaves room for modules and BPF. The kernel could not be
>> placed at the beginning of the vmalloc zone since other vmalloc
>> allocations from the kernel could get all the +-2GB window around the
>> kernel which would prevent new modules and BPF programs to be loaded.
>>
>> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr>
>> Reviewed-by: Zong Li <zong.li@sifive.com>
>> ---
>> arch/riscv/boot/loader.lds.S | 3 +-
>> arch/riscv/include/asm/page.h | 10 +++++-
>> arch/riscv/include/asm/pgtable.h | 38 ++++++++++++++-------
>> arch/riscv/kernel/head.S | 3 +-
>> arch/riscv/kernel/module.c | 4 +--
>> arch/riscv/kernel/vmlinux.lds.S | 3 +-
>> arch/riscv/mm/init.c | 58 +++++++++++++++++++++++++-------
>> arch/riscv/mm/physaddr.c | 2 +-
>> 8 files changed, 88 insertions(+), 33 deletions(-)
>>
>> diff --git a/arch/riscv/boot/loader.lds.S b/arch/riscv/boot/loader.lds.S
>> index 47a5003c2e28..62d94696a19c 100644
>> --- a/arch/riscv/boot/loader.lds.S
>> +++ b/arch/riscv/boot/loader.lds.S
>> @@ -1,13 +1,14 @@
>> /* SPDX-License-Identifier: GPL-2.0 */
>>
>> #include <asm/page.h>
>> +#include <asm/pgtable.h>
>>
>> OUTPUT_ARCH(riscv)
>> ENTRY(_start)
>>
>> SECTIONS
>> {
>> - . = PAGE_OFFSET;
>> + . = KERNEL_LINK_ADDR;
>>
>> .payload : {
>> *(.payload)
>> diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
>> index 2d50f76efe48..48bb09b6a9b7 100644
>> --- a/arch/riscv/include/asm/page.h
>> +++ b/arch/riscv/include/asm/page.h
>> @@ -90,18 +90,26 @@ typedef struct page *pgtable_t;
>>
>> #ifdef CONFIG_MMU
>> extern unsigned long va_pa_offset;
>> +extern unsigned long va_kernel_pa_offset;
>> extern unsigned long pfn_base;
>> #define ARCH_PFN_OFFSET (pfn_base)
>> #else
>> #define va_pa_offset 0
>> +#define va_kernel_pa_offset 0
>> #define ARCH_PFN_OFFSET (PAGE_OFFSET >> PAGE_SHIFT)
>> #endif /* CONFIG_MMU */
>>
>> extern unsigned long max_low_pfn;
>> extern unsigned long min_low_pfn;
>> +extern unsigned long kernel_virt_addr;
>>
>> #define __pa_to_va_nodebug(x) ((void *)((unsigned long) (x) + va_pa_offset))
>> -#define __va_to_pa_nodebug(x) ((unsigned long)(x) - va_pa_offset)
>> +#define linear_mapping_va_to_pa(x) ((unsigned long)(x) - va_pa_offset)
>> +#define kernel_mapping_va_to_pa(x) \
>> + ((unsigned long)(x) - va_kernel_pa_offset)
>> +#define __va_to_pa_nodebug(x) \
>> + (((x) >= PAGE_OFFSET) ? \
>> + linear_mapping_va_to_pa(x) : kernel_mapping_va_to_pa(x))
>>
>> #ifdef CONFIG_DEBUG_VIRTUAL
>> extern phys_addr_t __virt_to_phys(unsigned long x);
>> diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
>> index 35b60035b6b0..94ef3b49dfb6 100644
>> --- a/arch/riscv/include/asm/pgtable.h
>> +++ b/arch/riscv/include/asm/pgtable.h
>> @@ -11,23 +11,29 @@
>>
>> #include <asm/pgtable-bits.h>
>>
>> -#ifndef __ASSEMBLY__
>> -
>> -/* Page Upper Directory not used in RISC-V */
>> -#include <asm-generic/pgtable-nopud.h>
>> -#include <asm/page.h>
>> -#include <asm/tlbflush.h>
>> -#include <linux/mm_types.h>
>> -
>> -#ifdef CONFIG_MMU
>> +#ifndef CONFIG_MMU
>> +#define KERNEL_VIRT_ADDR PAGE_OFFSET
>> +#define KERNEL_LINK_ADDR PAGE_OFFSET
>> +#else
>> +/*
>> + * Leave 2GB for modules and BPF that must lie within a 2GB range around
>> + * the kernel.
>> + */
>> +#define KERNEL_VIRT_ADDR (VMALLOC_END - SZ_2G + 1)
>> +#define KERNEL_LINK_ADDR KERNEL_VIRT_ADDR
>>
>> #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
>> #define VMALLOC_END (PAGE_OFFSET - 1)
>> #define VMALLOC_START (PAGE_OFFSET - VMALLOC_SIZE)
>>
>> #define BPF_JIT_REGION_SIZE (SZ_128M)
>> -#define BPF_JIT_REGION_START (PAGE_OFFSET - BPF_JIT_REGION_SIZE)
>> -#define BPF_JIT_REGION_END (VMALLOC_END)
>> +#define BPF_JIT_REGION_START PFN_ALIGN((unsigned long)&_end)
>> +#define BPF_JIT_REGION_END (BPF_JIT_REGION_START + BPF_JIT_REGION_SIZE)
>> +
> As these mappings have changed a few times in recent months including
> this one, I think it would be
> better to have virtual memory layout documentation in RISC-V similar
> to other architectures.
>
> If you can include the page table layout for 3/4 level page tables in
> the same document, that would be really helpful.
>
Yes, I'll do that in a separate commit.
Thanks,
Alex
>> +#ifdef CONFIG_64BIT
>> +#define VMALLOC_MODULE_START BPF_JIT_REGION_END
>> +#define VMALLOC_MODULE_END (((unsigned long)&_start & PAGE_MASK) + SZ_2G)
>> +#endif
>>
>> /*
>> * Roughly size the vmemmap space to be large enough to fit enough
>> @@ -57,9 +63,16 @@
>> #define FIXADDR_SIZE PGDIR_SIZE
>> #endif
>> #define FIXADDR_START (FIXADDR_TOP - FIXADDR_SIZE)
>> -
>> #endif
>>
>> +#ifndef __ASSEMBLY__
>> +
>> +/* Page Upper Directory not used in RISC-V */
>> +#include <asm-generic/pgtable-nopud.h>
>> +#include <asm/page.h>
>> +#include <asm/tlbflush.h>
>> +#include <linux/mm_types.h>
>> +
>> #ifdef CONFIG_64BIT
>> #include <asm/pgtable-64.h>
>> #else
>> @@ -483,6 +496,7 @@ static inline void __kernel_map_pages(struct page *page, int numpages, int enabl
>>
>> #define kern_addr_valid(addr) (1) /* FIXME */
>>
>> +extern char _start[];
>> extern void *dtb_early_va;
>> void setup_bootmem(void);
>> void paging_init(void);
>> diff --git a/arch/riscv/kernel/head.S b/arch/riscv/kernel/head.S
>> index 98a406474e7d..8f5bb7731327 100644
>> --- a/arch/riscv/kernel/head.S
>> +++ b/arch/riscv/kernel/head.S
>> @@ -49,7 +49,8 @@ ENTRY(_start)
>> #ifdef CONFIG_MMU
>> relocate:
>> /* Relocate return address */
>> - li a1, PAGE_OFFSET
>> + la a1, kernel_virt_addr
>> + REG_L a1, 0(a1)
>> la a2, _start
>> sub a1, a1, a2
>> add ra, ra, a1
>> diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
>> index 8bbe5dbe1341..1a8fbe05accf 100644
>> --- a/arch/riscv/kernel/module.c
>> +++ b/arch/riscv/kernel/module.c
>> @@ -392,12 +392,10 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
>> }
>>
>> #if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
>> -#define VMALLOC_MODULE_START \
>> - max(PFN_ALIGN((unsigned long)&_end - SZ_2G), VMALLOC_START)
>> void *module_alloc(unsigned long size)
>> {
>> return __vmalloc_node_range(size, 1, VMALLOC_MODULE_START,
>> - VMALLOC_END, GFP_KERNEL,
>> + VMALLOC_MODULE_END, GFP_KERNEL,
>> PAGE_KERNEL_EXEC, 0, NUMA_NO_NODE,
>> __builtin_return_address(0));
>> }
>> diff --git a/arch/riscv/kernel/vmlinux.lds.S b/arch/riscv/kernel/vmlinux.lds.S
>> index 0339b6bbe11a..a9abde62909f 100644
>> --- a/arch/riscv/kernel/vmlinux.lds.S
>> +++ b/arch/riscv/kernel/vmlinux.lds.S
>> @@ -4,7 +4,8 @@
>> * Copyright (C) 2017 SiFive
>> */
>>
>> -#define LOAD_OFFSET PAGE_OFFSET
>> +#include <asm/pgtable.h>
>> +#define LOAD_OFFSET KERNEL_LINK_ADDR
>> #include <asm/vmlinux.lds.h>
>> #include <asm/page.h>
>> #include <asm/cache.h>
>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>> index 736de6c8739f..71da78914645 100644
>> --- a/arch/riscv/mm/init.c
>> +++ b/arch/riscv/mm/init.c
>> @@ -22,6 +22,9 @@
>>
>> #include "../kernel/head.h"
>>
>> +unsigned long kernel_virt_addr = KERNEL_VIRT_ADDR;
>> +EXPORT_SYMBOL(kernel_virt_addr);
>> +
>> unsigned long empty_zero_page[PAGE_SIZE / sizeof(unsigned long)]
>> __page_aligned_bss;
>> EXPORT_SYMBOL(empty_zero_page);
>> @@ -178,8 +181,12 @@ void __init setup_bootmem(void)
>> }
>>
>> #ifdef CONFIG_MMU
>> +/* Offset between linear mapping virtual address and kernel load address */
>> unsigned long va_pa_offset;
>> EXPORT_SYMBOL(va_pa_offset);
>> +/* Offset between kernel mapping virtual address and kernel load address */
>> +unsigned long va_kernel_pa_offset;
>> +EXPORT_SYMBOL(va_kernel_pa_offset);
>> unsigned long pfn_base;
>> EXPORT_SYMBOL(pfn_base);
>>
>> @@ -271,7 +278,7 @@ static phys_addr_t __init alloc_pmd(uintptr_t va)
>> if (mmu_enabled)
>> return memblock_phys_alloc(PAGE_SIZE, PAGE_SIZE);
>>
>> - pmd_num = (va - PAGE_OFFSET) >> PGDIR_SHIFT;
>> + pmd_num = (va - kernel_virt_addr) >> PGDIR_SHIFT;
>> BUG_ON(pmd_num >= NUM_EARLY_PMDS);
>> return (uintptr_t)&early_pmd[pmd_num * PTRS_PER_PMD];
>> }
>> @@ -372,14 +379,30 @@ static uintptr_t __init best_map_size(phys_addr_t base, phys_addr_t size)
>> #error "setup_vm() is called from head.S before relocate so it should not use absolute addressing."
>> #endif
>>
>> +static uintptr_t load_pa, load_sz;
>> +
>> +static void __init create_kernel_page_table(pgd_t *pgdir, uintptr_t map_size)
>> +{
>> + uintptr_t va, end_va;
>> +
>> + end_va = kernel_virt_addr + load_sz;
>> + for (va = kernel_virt_addr; va < end_va; va += map_size)
>> + create_pgd_mapping(pgdir, va,
>> + load_pa + (va - kernel_virt_addr),
>> + map_size, PAGE_KERNEL_EXEC);
>> +}
>> +
>> asmlinkage void __init setup_vm(uintptr_t dtb_pa)
>> {
>> uintptr_t va, end_va;
>> - uintptr_t load_pa = (uintptr_t)(&_start);
>> - uintptr_t load_sz = (uintptr_t)(&_end) - load_pa;
>> uintptr_t map_size = best_map_size(load_pa, MAX_EARLY_MAPPING_SIZE);
>>
>> + load_pa = (uintptr_t)(&_start);
>> + load_sz = (uintptr_t)(&_end) - load_pa;
>> +
>> va_pa_offset = PAGE_OFFSET - load_pa;
>> + va_kernel_pa_offset = kernel_virt_addr - load_pa;
>> +
>> pfn_base = PFN_DOWN(load_pa);
>>
>> /*
>> @@ -402,26 +425,22 @@ asmlinkage void __init setup_vm(uintptr_t dtb_pa)
>> create_pmd_mapping(fixmap_pmd, FIXADDR_START,
>> (uintptr_t)fixmap_pte, PMD_SIZE, PAGE_TABLE);
>> /* Setup trampoline PGD and PMD */
>> - create_pgd_mapping(trampoline_pg_dir, PAGE_OFFSET,
>> + create_pgd_mapping(trampoline_pg_dir, kernel_virt_addr,
>> (uintptr_t)trampoline_pmd, PGDIR_SIZE, PAGE_TABLE);
>> - create_pmd_mapping(trampoline_pmd, PAGE_OFFSET,
>> + create_pmd_mapping(trampoline_pmd, kernel_virt_addr,
>> load_pa, PMD_SIZE, PAGE_KERNEL_EXEC);
>> #else
>> /* Setup trampoline PGD */
>> - create_pgd_mapping(trampoline_pg_dir, PAGE_OFFSET,
>> + create_pgd_mapping(trampoline_pg_dir, kernel_virt_addr,
>> load_pa, PGDIR_SIZE, PAGE_KERNEL_EXEC);
>> #endif
>>
>> /*
>> - * Setup early PGD covering entire kernel which will allows
>> + * Setup early PGD covering entire kernel which will allow
>> * us to reach paging_init(). We map all memory banks later
>> * in setup_vm_final() below.
>> */
>> - end_va = PAGE_OFFSET + load_sz;
>> - for (va = PAGE_OFFSET; va < end_va; va += map_size)
>> - create_pgd_mapping(early_pg_dir, va,
>> - load_pa + (va - PAGE_OFFSET),
>> - map_size, PAGE_KERNEL_EXEC);
>> + create_kernel_page_table(early_pg_dir, map_size);
>>
>> /* Create fixed mapping for early FDT parsing */
>> end_va = __fix_to_virt(FIX_FDT) + FIX_FDT_SIZE;
>> @@ -441,6 +460,7 @@ static void __init setup_vm_final(void)
>> uintptr_t va, map_size;
>> phys_addr_t pa, start, end;
>> struct memblock_region *reg;
>> + static struct vm_struct vm_kernel = { 0 };
>>
>> /* Set mmu_enabled flag */
>> mmu_enabled = true;
>> @@ -467,10 +487,22 @@ static void __init setup_vm_final(void)
>> for (pa = start; pa < end; pa += map_size) {
>> va = (uintptr_t)__va(pa);
>> create_pgd_mapping(swapper_pg_dir, va, pa,
>> - map_size, PAGE_KERNEL_EXEC);
>> + map_size, PAGE_KERNEL);
>> }
>> }
>>
>> + /* Map the kernel */
>> + create_kernel_page_table(swapper_pg_dir, PMD_SIZE);
>> +
>> + /* Reserve the vmalloc area occupied by the kernel */
>> + vm_kernel.addr = (void *)kernel_virt_addr;
>> + vm_kernel.phys_addr = load_pa;
>> + vm_kernel.size = (load_sz + PMD_SIZE - 1) & ~(PMD_SIZE - 1);
>> + vm_kernel.flags = VM_MAP | VM_NO_GUARD;
>> + vm_kernel.caller = __builtin_return_address(0);
>> +
>> + vm_area_add_early(&vm_kernel);
>> +
>> /* Clear fixmap PTE and PMD mappings */
>> clear_fixmap(FIX_PTE);
>> clear_fixmap(FIX_PMD);
>> diff --git a/arch/riscv/mm/physaddr.c b/arch/riscv/mm/physaddr.c
>> index e8e4dcd39fed..35703d5ef5fd 100644
>> --- a/arch/riscv/mm/physaddr.c
>> +++ b/arch/riscv/mm/physaddr.c
>> @@ -23,7 +23,7 @@ EXPORT_SYMBOL(__virt_to_phys);
>>
>> phys_addr_t __phys_addr_symbol(unsigned long x)
>> {
>> - unsigned long kernel_start = (unsigned long)PAGE_OFFSET;
>> + unsigned long kernel_start = (unsigned long)kernel_virt_addr;
>> unsigned long kernel_end = (unsigned long)_end;
>>
>> /*
>> --
>> 2.20.1
>>
>>
>
^ permalink raw reply
* Re: [PATCH v2] All arch: remove system call sys_sysctl
From: Xiaoming Ni @ 2020-06-12 9:48 UTC (permalink / raw)
To: Eric W. Biederman, Rich Felker
Cc: linux-sh, catalin.marinas, paulus, ak, paulburton, geert,
mattst88, brgerst, acme, cyphar, viro, luto, tglx, surenb, rth,
young.liuyang, linux-parisc, rdunlap, linux-kernel, mcgrof,
linux-fsdevel, akpm, mark.rutland, linux-ia64, linux-xtensa,
jongk, linux, James.Bottomley, jcmvbkbc, linux-s390, ysato,
deller, yzaikin, mszeredi, gor, linux-alpha, linux-m68k,
linux-arm-kernel, chris, tony.luck, linux-api, zhouyanjie,
minchan, sargun, alexander.shishkin, heiko.carstens,
alex.huangjianhui, will, krzk, borntraeger, vbabka, samitolvanen,
flameeyes, ravi.bangoria, elver, keescook, arnd, bp, christian,
tsbogend, jiri, martin.petersen, yamada.masahiro, oleg,
sudeep.holla, olof, shawnguo, davem, bauerman, fenghua.yu, peterz,
dhowells, hpa, sparclinux, jolsa, svens, x86, linux, mingo,
naveen.n.rao, paulmck, sfr, npiggin, namhyung, dvyukov, axboe,
monstr, haolee.swjtu, linux-mips, ink, linuxppc-dev
In-Reply-To: <87k10dqx5g.fsf@x220.int.ebiederm.org>
On 2020/6/12 2:23, Eric W. Biederman wrote:
> Rich Felker <dalias@libc.org> writes:
>
>> On Thu, Jun 11, 2020 at 12:01:11PM -0500, Eric W. Biederman wrote:
>>> Rich Felker <dalias@libc.org> writes:
>>>
>>>> On Thu, Jun 11, 2020 at 06:43:00AM -0500, Eric W. Biederman wrote:
>>>>> Xiaoming Ni <nixiaoming@huawei.com> writes:
>>>>>
>>>>>> Since the commit 61a47c1ad3a4dc ("sysctl: Remove the sysctl system call"),
>>>>>> sys_sysctl is actually unavailable: any input can only return an error.
>>>>>>
>>>>>> We have been warning about people using the sysctl system call for years
>>>>>> and believe there are no more users. Even if there are users of this
>>>>>> interface if they have not complained or fixed their code by now they
>>>>>> probably are not going to, so there is no point in warning them any
>>>>>> longer.
>>>>>>
>>>>>> So completely remove sys_sysctl on all architectures.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Signed-off-by: Xiaoming Ni <nixiaoming@huawei.com>
>>>>>>
>>>>>> changes in v2:
>>>>>> According to Kees Cook's suggestion, completely remove sys_sysctl on all arch
>>>>>> According to Eric W. Biederman's suggestion, update the commit log
>>>>>>
>>>>>> V1: https://lore.kernel.org/lkml/1591683605-8585-1-git-send-email-nixiaoming@huawei.com/
>>>>>> Delete the code of sys_sysctl and return -ENOSYS directly at the function entry
>>>>>> ---
>>>>>> include/uapi/linux/sysctl.h | 15 --
>>>>> [snip]
>>>>>
>>>>>> diff --git a/include/uapi/linux/sysctl.h b/include/uapi/linux/sysctl.h
>>>>>> index 27c1ed2..84b44c3 100644
>>>>>> --- a/include/uapi/linux/sysctl.h
>>>>>> +++ b/include/uapi/linux/sysctl.h
>>>>>> @@ -27,21 +27,6 @@
>>>>>> #include <linux/types.h>
>>>>>> #include <linux/compiler.h>
>>>>>>
>>>>>> -#define CTL_MAXNAME 10 /* how many path components do we allow in a
>>>>>> - call to sysctl? In other words, what is
>>>>>> - the largest acceptable value for the nlen
>>>>>> - member of a struct __sysctl_args to have? */
>>>>>> -
>>>>>> -struct __sysctl_args {
>>>>>> - int __user *name;
>>>>>> - int nlen;
>>>>>> - void __user *oldval;
>>>>>> - size_t __user *oldlenp;
>>>>>> - void __user *newval;
>>>>>> - size_t newlen;
>>>>>> - unsigned long __unused[4];
>>>>>> -};
>>>>>> -
>>>>>> /* Define sysctl names first */
>>>>>>
>>>>>> /* Top-level names: */
>>>>> [snip]
>>>>>
>>>>> The uapi header change does not make sense. The entire point of the
>>>>> header is to allow userspace programs to be able to call sys_sysctl.
>>>>> It either needs to all stay or all go.
>>>>>
>>>>> As the concern with the uapi header is about userspace programs being
>>>>> able to compile please leave the header for now.
>>>>>
>>>>> We should leave auditing userspace and seeing if userspace code will
>>>>> still compile if we remove this header for a separate patch. The
>>>>> concerns and justifications for the uapi header are completely different
>>>>> then for the removing the sys_sysctl implementation.
>>>>>
>>>>> Otherwise
>>>>> Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
>>>>
>>>> The UAPI header should be kept because it's defining an API not just
>>>> for the kernel the headers are supplied with, but for all past
>>>> kernels. In particular programs needing a failsafe CSPRNG source that
>>>> works on old kernels may (do) use this as a fallback only if modern
>>>> syscalls are missing. Removing the syscall is no problem since it
>>>> won't be used, but if you remove the types/macros from the UAPI
>>>> headers, they'll have to copy that into their own sources.
>>>
>>> May we assume you know of a least one piece of userspace that will fail
>>> to compile if this header file is removed?
>>
>> I know at least one piece of software is using SYS_sysctl for a
>> fallback CSPRNG source. I'm not 100% sure that they're using the
>> kernel headers; they might have copied it already. I'm also not sure
>> how many there are.
>>
>> Regardless, I think the principle stands. There's no need to remove
>> definitions that are essentially maintenance-free now that the
>> interface is no longer available in new kernels, and doing so
>> contributes to the myth that you're supposed to use kernel headers
>> matching runtime kernel rather than it always being safe to use latest
>> headers.
>
> If there is no one using the definitions removing them saves people
> having to remember what they are there for.
>
> The big rule is don't break userspace. The goal is to allow people to
> upgrade their kernel without needing to worry about userspace breaking,
> and to be able to downgrade to the extent possible to help in tracking
> bugs.
>
> Not being able to compile userspace seems like a pretty clear cut case.
> Although there are some fuzzy edges given the history of the kernel
> headers. Things like your libc requiring kernel headers to be processed
> before they can be used. I think there are still some kernel headers
> that have that restriction when used with glibc as glibc uses different
> sizes for types like dev_t.
>
> The bottom line is we can't do it casually so that any work in the
> direction of removing from or deleting uapi headers needs to be it's own
> separate patch.
>
> Given how much effort it can be to show that userspace is not using
> something I don't expect us to be mucking with the uapi headers any time
> soon.
>
> Eric
>
Thanks everyone for your guidance, I will delete the update of uapi file
in v3 version.
But here I am still a bit confused: how to modify include/uapi?
Before commit 61a47c1ad3a4dc ("sysctl: Remove the sysctl system call"),
most of the enumeration variables defined in include/uapi/linux/sysctl.h
were used in kernel/sysctl_binary.c,
After commit 61a47c1ad3a4dc ("sysctl: Remove the sysctl system call"),
the code for enumerating variables in include/uapi/linux/sysctl.h cannot
be found in the current git repository
From the management of a single git repository, we can immediately
delete include/uapi/linux/sysctl.h for the reason of deleting unused
code. But from the complex cooperation of linux/libc/ltp/man/xxxx, it
may take a long time to modify uapi.
Is there any example for the update of uapi? How to control the rhythm?
How to update uapi?
Thanks
Xiaoming Ni
^ permalink raw reply
* [PATCH] powerpc/pci: unmap legacy INTx interrupts when a PHB is removed
From: Cédric Le Goater @ 2020-06-12 7:02 UTC (permalink / raw)
To: Michael Ellerman
Cc: Oliver O'Halloran, linuxppc-dev, Cédric Le Goater
When a passthrough IO adapter is removed from a pseries machine using
hash MMU and the XIVE interrupt mode, the POWER hypervisor, pHyp,
expects the guest OS to have cleared all page table entries related to
the adapter. If some are still present, the RTAS call which isolates
the PCI slot returns error 9001 "valid outstanding translations" and
the removal of the IO adapter fails.
INTx interrupt numbers need special care because Linux maps the
interrupts automatically in the Linux interrupt number space. For this
purpose, record the logical interrupt number of the INTx at the PHB
level and clear these interrupts when the PCI bus is removed. This
will also clear all the page table entries of the ESB pages when using
XIVE.
Cc: "Oliver O'Halloran" <oohall@gmail.com>
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
This deprecates patch :
http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20200429075122.1216388-3-clg@kaod.org/
Thanks,
arch/powerpc/include/asm/pci-bridge.h | 4 +++
arch/powerpc/kernel/pci-common.c | 45 +++++++++++++++++++++++++++
2 files changed, 49 insertions(+)
diff --git a/arch/powerpc/include/asm/pci-bridge.h b/arch/powerpc/include/asm/pci-bridge.h
index b92e81b256e5..9960dd249079 100644
--- a/arch/powerpc/include/asm/pci-bridge.h
+++ b/arch/powerpc/include/asm/pci-bridge.h
@@ -48,6 +48,8 @@ struct pci_controller_ops {
/*
* Structure of a PCI controller (host bridge)
+ *
+ * @intx: legacy INTx mappings
*/
struct pci_controller {
struct pci_bus *bus;
@@ -127,6 +129,8 @@ struct pci_controller {
void *private_data;
struct npu *npu;
+
+ unsigned int intx[PCI_NUM_INTX];
};
/* These are used for config access before all the PCI probing
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index be108616a721..8c442627f465 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -353,6 +353,49 @@ struct pci_controller *pci_find_controller_for_domain(int domain_nr)
return NULL;
}
+static void pci_intx_register(struct pci_dev *pdev, int virq)
+{
+ struct pci_controller *phb = pci_bus_to_host(pdev->bus);
+ int i;
+
+ for (i = 0; i < PCI_NUM_INTX; i++) {
+ /*
+ * Look for an empty or an equivalent slot, as INTx
+ * interrupts can be shared between adapters
+ */
+ if (phb->intx[i] == virq || !phb->intx[i]) {
+ phb->intx[i] = virq;
+ break;
+ }
+ }
+
+ if (i == PCI_NUM_INTX)
+ pr_err("PCI:%s INTx all mapped\n", pci_name(pdev));
+}
+
+/*
+ * Clearing the mapped INTx interrupts will also clear the underlying
+ * mappings of the ESB pages of the interrupts when under XIVE. It is
+ * a requirement of PowerVM to clear all memory mappings before
+ * removing a PHB.
+ */
+static void pci_intx_dispose(struct pci_bus *bus)
+{
+ struct pci_controller *phb = pci_bus_to_host(bus);
+ int i;
+
+ pr_debug("PCI: Clearing INTx for PHB %04x:%02x...\n",
+ pci_domain_nr(bus), bus->number);
+ for (i = 0; i < PCI_NUM_INTX; i++)
+ irq_dispose_mapping(phb->intx[i]);
+}
+
+void pcibios_remove_bus(struct pci_bus *bus)
+{
+ pci_intx_dispose(bus);
+}
+EXPORT_SYMBOL_GPL(pcibios_remove_bus);
+
/*
* Reads the interrupt pin to determine if interrupt is use by card.
* If the interrupt is used, then gets the interrupt line from the
@@ -401,6 +444,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
pci_dev->irq = virq;
+ /* Record all INTx mappings for later removal of a PHB */
+ pci_intx_register(pci_dev, virq);
return 0;
}
--
2.25.4
^ permalink raw reply related
* Re: [RFC PATCH v3 4/4] ASoC: fsl_asrc_dma: Fix data copying speed issue with EDMA
From: Nicolin Chen @ 2020-06-12 8:10 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, lars, timur, Xiubo.Lee, linux-kernel, linuxppc-dev,
lgirdwood, tiwai, broonie, perex, festevam
In-Reply-To: <424ed6c249bafcbe30791c9de0352821c5ea67e2.1591947428.git.shengjiu.wang@nxp.com>
On Fri, Jun 12, 2020 at 03:37:51PM +0800, Shengjiu Wang wrote:
> With EDMA, there is two dma channels can be used for dev_to_dev,
> one is from ASRC, one is from another peripheral (ESAI or SAI).
>
> If we select the dma channel of ASRC, there is an issue for ideal
> ratio case, the speed of copy data is faster than sample
> frequency, because ASRC output data is very fast in ideal ratio
> mode.
>
> So it is reasonable to use the dma channel of Back-End peripheral.
> then copying speed of DMA is controlled by data consumption
> speed in the peripheral FIFO,
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
^ permalink raw reply
* Re: [RFC PATCH v3 3/4] ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End
From: Nicolin Chen @ 2020-06-12 8:08 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, lars, timur, Xiubo.Lee, linux-kernel, linuxppc-dev,
lgirdwood, tiwai, broonie, perex, festevam
In-Reply-To: <3a79f0442cb4930c633cf72145cfe95a45b9c78e.1591947428.git.shengjiu.wang@nxp.com>
On Fri, Jun 12, 2020 at 03:37:50PM +0800, Shengjiu Wang wrote:
> The dma channel has been requested by Back-End cpu dai driver already.
> If fsl_asrc_dma requests dma chan with same dma:tx symlink, then
> there will be below warning with SDMA.
>
> [ 48.174236] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink
>
> So if we can reuse the dma channel of Back-End, then the issue can be
> fixed.
>
> In order to get the dma channel which is already requested in Back-End.
> we use the exported two functions (snd_soc_lookup_component_nolocked
> and soc_component_to_pcm). If we can get the dma channel, then reuse it,
> if can't, then request a new one.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
^ permalink raw reply
* Re: [RFC PATCH v3 2/4] ASoC: dmaengine_pcm: export soc_component_to_pcm
From: Nicolin Chen @ 2020-06-12 8:01 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, lars, timur, Xiubo.Lee, linux-kernel, linuxppc-dev,
lgirdwood, tiwai, broonie, perex, festevam
In-Reply-To: <429c6ae1f3c5b47eb893f475d531d71cdcfe34c0.1591947428.git.shengjiu.wang@nxp.com>
On Fri, Jun 12, 2020 at 03:37:49PM +0800, Shengjiu Wang wrote:
> In DPCM case, Front-End needs to get the dma chan which has
> been requested by Back-End and reuse it.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
^ permalink raw reply
* Re: [RFC PATCH v3 1/4] ASoC: soc-card: export snd_soc_lookup_component_nolocked
From: Nicolin Chen @ 2020-06-12 8:00 UTC (permalink / raw)
To: Shengjiu Wang
Cc: alsa-devel, lars, timur, Xiubo.Lee, linux-kernel, linuxppc-dev,
lgirdwood, tiwai, broonie, perex, festevam
In-Reply-To: <55f6e0d76f67a517b9a44136d790ff2a06b5caa8.1591947428.git.shengjiu.wang@nxp.com>
On Fri, Jun 12, 2020 at 03:37:48PM +0800, Shengjiu Wang wrote:
> snd_soc_lookup_component_nolocked can be used for the DPCM case
> that Front-End needs to get the unused platform component but
> added by Back-End cpu dai driver.
>
> If the component is gotten, then we can get the dma chan created
> by Back-End component and reused it in Front-End.
>
> Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
Reviewed-by: Nicolin Chen <nicoleotsuka@gmail.com>
^ permalink raw reply
* [RFC PATCH v3 4/4] ASoC: fsl_asrc_dma: Fix data copying speed issue with EDMA
From: Shengjiu Wang @ 2020-06-12 7:37 UTC (permalink / raw)
To: lars, perex, tiwai, lgirdwood, broonie, timur, nicoleotsuka,
Xiubo.Lee, festevam, alsa-devel, linux-kernel, linuxppc-dev
In-Reply-To: <cover.1591947428.git.shengjiu.wang@nxp.com>
With EDMA, there is two dma channels can be used for dev_to_dev,
one is from ASRC, one is from another peripheral (ESAI or SAI).
If we select the dma channel of ASRC, there is an issue for ideal
ratio case, the speed of copy data is faster than sample
frequency, because ASRC output data is very fast in ideal ratio
mode.
So it is reasonable to use the dma channel of Back-End peripheral.
then copying speed of DMA is controlled by data consumption
speed in the peripheral FIFO,
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_asrc_common.h | 2 ++
sound/soc/fsl/fsl_asrc_dma.c | 26 +++++++++++++++-----------
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc_common.h b/sound/soc/fsl/fsl_asrc_common.h
index 77665b15c8db..7e1c13ca37f1 100644
--- a/sound/soc/fsl/fsl_asrc_common.h
+++ b/sound/soc/fsl/fsl_asrc_common.h
@@ -32,6 +32,7 @@ enum asrc_pair_index {
* @dma_chan: inputer and output DMA channels
* @dma_data: private dma data
* @pos: hardware pointer position
+ * @req_dma_chan: flag to release dev_to_dev chan
* @private: pair private area
*/
struct fsl_asrc_pair {
@@ -45,6 +46,7 @@ struct fsl_asrc_pair {
struct dma_chan *dma_chan[2];
struct imx_dma_data dma_data;
unsigned int pos;
+ bool req_dma_chan;
void *private;
};
diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index d88e6343e0a2..5f01a58f422a 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -233,11 +233,11 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
pair->dma_chan[dir] =
dma_request_channel(mask, filter, &pair->dma_data);
+ pair->req_dma_chan = true;
} else {
- if (!be_chan)
- dma_release_channel(tmp_chan);
- pair->dma_chan[dir] =
- asrc->get_dma_channel(pair, dir);
+ pair->dma_chan[dir] = tmp_chan;
+ /* Do not flag to release if we are reusing the Back-End one */
+ pair->req_dma_chan = !be_chan;
}
if (!pair->dma_chan[dir]) {
@@ -276,7 +276,8 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
ret = dmaengine_slave_config(pair->dma_chan[dir], &config_be);
if (ret) {
dev_err(dev, "failed to config DMA channel for Back-End\n");
- dma_release_channel(pair->dma_chan[dir]);
+ if (pair->req_dma_chan)
+ dma_release_channel(pair->dma_chan[dir]);
return ret;
}
@@ -288,19 +289,22 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
static int fsl_asrc_dma_hw_free(struct snd_soc_component *component,
struct snd_pcm_substream *substream)
{
+ bool tx = substream->stream == SNDRV_PCM_STREAM_PLAYBACK;
struct snd_pcm_runtime *runtime = substream->runtime;
struct fsl_asrc_pair *pair = runtime->private_data;
+ u8 dir = tx ? OUT : IN;
snd_pcm_set_runtime_buffer(substream, NULL);
- if (pair->dma_chan[IN])
- dma_release_channel(pair->dma_chan[IN]);
+ if (pair->dma_chan[!dir])
+ dma_release_channel(pair->dma_chan[!dir]);
- if (pair->dma_chan[OUT])
- dma_release_channel(pair->dma_chan[OUT]);
+ /* release dev_to_dev chan if we aren't reusing the Back-End one */
+ if (pair->dma_chan[dir] && pair->req_dma_chan)
+ dma_release_channel(pair->dma_chan[dir]);
- pair->dma_chan[IN] = NULL;
- pair->dma_chan[OUT] = NULL;
+ pair->dma_chan[!dir] = NULL;
+ pair->dma_chan[dir] = NULL;
return 0;
}
--
2.21.0
^ permalink raw reply related
* [RFC PATCH v3 3/4] ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End
From: Shengjiu Wang @ 2020-06-12 7:37 UTC (permalink / raw)
To: lars, perex, tiwai, lgirdwood, broonie, timur, nicoleotsuka,
Xiubo.Lee, festevam, alsa-devel, linux-kernel, linuxppc-dev
In-Reply-To: <cover.1591947428.git.shengjiu.wang@nxp.com>
The dma channel has been requested by Back-End cpu dai driver already.
If fsl_asrc_dma requests dma chan with same dma:tx symlink, then
there will be below warning with SDMA.
[ 48.174236] fsl-esai-dai 2024000.esai: Cannot create DMA dma:tx symlink
So if we can reuse the dma channel of Back-End, then the issue can be
fixed.
In order to get the dma channel which is already requested in Back-End.
we use the exported two functions (snd_soc_lookup_component_nolocked
and soc_component_to_pcm). If we can get the dma channel, then reuse it,
if can't, then request a new one.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_asrc_dma.c | 25 ++++++++++++++++++++-----
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc_dma.c b/sound/soc/fsl/fsl_asrc_dma.c
index d6a3fc5f87e5..d88e6343e0a2 100644
--- a/sound/soc/fsl/fsl_asrc_dma.c
+++ b/sound/soc/fsl/fsl_asrc_dma.c
@@ -135,6 +135,8 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
struct snd_dmaengine_dai_dma_data *dma_params_be = NULL;
struct snd_pcm_runtime *runtime = substream->runtime;
struct fsl_asrc_pair *pair = runtime->private_data;
+ struct dma_chan *tmp_chan = NULL, *be_chan = NULL;
+ struct snd_soc_component *component_be = NULL;
struct fsl_asrc *asrc = pair->asrc;
struct dma_slave_config config_fe, config_be;
enum asrc_pair_index index = pair->index;
@@ -142,7 +144,6 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
int stream = substream->stream;
struct imx_dma_data *tmp_data;
struct snd_soc_dpcm *dpcm;
- struct dma_chan *tmp_chan;
struct device *dev_be;
u8 dir = tx ? OUT : IN;
dma_cap_mask_t mask;
@@ -197,18 +198,30 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
dma_cap_set(DMA_SLAVE, mask);
dma_cap_set(DMA_CYCLIC, mask);
+ /*
+ * The Back-End device might have already requested a DMA channel,
+ * so try to reuse it first, and then request a new one upon NULL.
+ */
+ component_be = snd_soc_lookup_component_nolocked(dev_be, SND_DMAENGINE_PCM_DRV_NAME);
+ if (component_be) {
+ be_chan = soc_component_to_pcm(component_be)->chan[substream->stream];
+ tmp_chan = be_chan;
+ }
+ if (!tmp_chan)
+ tmp_chan = dma_request_slave_channel(dev_be, tx ? "tx" : "rx");
+
/*
* An EDMA DEV_TO_DEV channel is fixed and bound with DMA event of each
* peripheral, unlike SDMA channel that is allocated dynamically. So no
- * need to configure dma_request and dma_request2, but get dma_chan via
- * dma_request_slave_channel directly with dma name of Front-End device
+ * need to configure dma_request and dma_request2, but get dma_chan of
+ * Back-End device directly via dma_request_slave_channel.
*/
if (!asrc->use_edma) {
/* Get DMA request of Back-End */
- tmp_chan = dma_request_slave_channel(dev_be, tx ? "tx" : "rx");
tmp_data = tmp_chan->private;
pair->dma_data.dma_request = tmp_data->dma_request;
- dma_release_channel(tmp_chan);
+ if (!be_chan)
+ dma_release_channel(tmp_chan);
/* Get DMA request of Front-End */
tmp_chan = asrc->get_dma_channel(pair, dir);
@@ -221,6 +234,8 @@ static int fsl_asrc_dma_hw_params(struct snd_soc_component *component,
pair->dma_chan[dir] =
dma_request_channel(mask, filter, &pair->dma_data);
} else {
+ if (!be_chan)
+ dma_release_channel(tmp_chan);
pair->dma_chan[dir] =
asrc->get_dma_channel(pair, dir);
}
--
2.21.0
^ permalink raw reply related
* [RFC PATCH v3 2/4] ASoC: dmaengine_pcm: export soc_component_to_pcm
From: Shengjiu Wang @ 2020-06-12 7:37 UTC (permalink / raw)
To: lars, perex, tiwai, lgirdwood, broonie, timur, nicoleotsuka,
Xiubo.Lee, festevam, alsa-devel, linux-kernel, linuxppc-dev
In-Reply-To: <cover.1591947428.git.shengjiu.wang@nxp.com>
In DPCM case, Front-End needs to get the dma chan which has
been requested by Back-End and reuse it.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
include/sound/dmaengine_pcm.h | 11 +++++++++++
sound/soc/soc-generic-dmaengine-pcm.c | 12 ------------
2 files changed, 11 insertions(+), 12 deletions(-)
diff --git a/include/sound/dmaengine_pcm.h b/include/sound/dmaengine_pcm.h
index b65220685920..8c5e38180fb0 100644
--- a/include/sound/dmaengine_pcm.h
+++ b/include/sound/dmaengine_pcm.h
@@ -161,4 +161,15 @@ int snd_dmaengine_pcm_prepare_slave_config(struct snd_pcm_substream *substream,
#define SND_DMAENGINE_PCM_DRV_NAME "snd_dmaengine_pcm"
+struct dmaengine_pcm {
+ struct dma_chan *chan[SNDRV_PCM_STREAM_LAST + 1];
+ const struct snd_dmaengine_pcm_config *config;
+ struct snd_soc_component component;
+ unsigned int flags;
+};
+
+static inline struct dmaengine_pcm *soc_component_to_pcm(struct snd_soc_component *p)
+{
+ return container_of(p, struct dmaengine_pcm, component);
+}
#endif
diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c
index f728309a0833..80a4e71f2d95 100644
--- a/sound/soc/soc-generic-dmaengine-pcm.c
+++ b/sound/soc/soc-generic-dmaengine-pcm.c
@@ -21,18 +21,6 @@
*/
#define SND_DMAENGINE_PCM_FLAG_NO_RESIDUE BIT(31)
-struct dmaengine_pcm {
- struct dma_chan *chan[SNDRV_PCM_STREAM_LAST + 1];
- const struct snd_dmaengine_pcm_config *config;
- struct snd_soc_component component;
- unsigned int flags;
-};
-
-static struct dmaengine_pcm *soc_component_to_pcm(struct snd_soc_component *p)
-{
- return container_of(p, struct dmaengine_pcm, component);
-}
-
static struct device *dmaengine_dma_dev(struct dmaengine_pcm *pcm,
struct snd_pcm_substream *substream)
{
--
2.21.0
^ permalink raw reply related
* [RFC PATCH v3 1/4] ASoC: soc-card: export snd_soc_lookup_component_nolocked
From: Shengjiu Wang @ 2020-06-12 7:37 UTC (permalink / raw)
To: lars, perex, tiwai, lgirdwood, broonie, timur, nicoleotsuka,
Xiubo.Lee, festevam, alsa-devel, linux-kernel, linuxppc-dev
In-Reply-To: <cover.1591947428.git.shengjiu.wang@nxp.com>
snd_soc_lookup_component_nolocked can be used for the DPCM case
that Front-End needs to get the unused platform component but
added by Back-End cpu dai driver.
If the component is gotten, then we can get the dma chan created
by Back-End component and reused it in Front-End.
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
include/sound/soc.h | 2 ++
sound/soc/soc-core.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 74868436ac79..565612a8d690 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -444,6 +444,8 @@ int devm_snd_soc_register_component(struct device *dev,
const struct snd_soc_component_driver *component_driver,
struct snd_soc_dai_driver *dai_drv, int num_dai);
void snd_soc_unregister_component(struct device *dev);
+struct snd_soc_component *snd_soc_lookup_component_nolocked(struct device *dev,
+ const char *driver_name);
struct snd_soc_component *snd_soc_lookup_component(struct device *dev,
const char *driver_name);
diff --git a/sound/soc/soc-core.c b/sound/soc/soc-core.c
index b07eca2c6ccc..d4c73e86d058 100644
--- a/sound/soc/soc-core.c
+++ b/sound/soc/soc-core.c
@@ -310,7 +310,7 @@ struct snd_soc_component *snd_soc_rtdcom_lookup(struct snd_soc_pcm_runtime *rtd,
}
EXPORT_SYMBOL_GPL(snd_soc_rtdcom_lookup);
-static struct snd_soc_component
+struct snd_soc_component
*snd_soc_lookup_component_nolocked(struct device *dev, const char *driver_name)
{
struct snd_soc_component *component;
@@ -329,6 +329,7 @@ static struct snd_soc_component
return found_component;
}
+EXPORT_SYMBOL_GPL(snd_soc_lookup_component_nolocked);
struct snd_soc_component *snd_soc_lookup_component(struct device *dev,
const char *driver_name)
--
2.21.0
^ permalink raw reply related
* [RFC PATCH v3 0/4] Reuse the dma channel if available in Back-End
From: Shengjiu Wang @ 2020-06-12 7:37 UTC (permalink / raw)
To: lars, perex, tiwai, lgirdwood, broonie, timur, nicoleotsuka,
Xiubo.Lee, festevam, alsa-devel, linux-kernel, linuxppc-dev
Reuse the dma channel if available in Back-End
Shengjiu Wang (4):
ASoC: soc-card: export snd_soc_lookup_component_nolocked
ASoC: dmaengine_pcm: export soc_component_to_pcm
ASoC: fsl_asrc_dma: Reuse the dma channel if available in Back-End
ASoC: fsl_asrc_dma: Fix data copying speed issue with EDMA
changes in v3:
- update according to Nicolin's comments
- split previous 0003 patch to two patches
changes in v2:
- update according to Mark's comments and split the patch
include/sound/dmaengine_pcm.h | 11 +++++++
include/sound/soc.h | 2 ++
sound/soc/fsl/fsl_asrc_common.h | 2 ++
sound/soc/fsl/fsl_asrc_dma.c | 47 +++++++++++++++++++--------
sound/soc/soc-core.c | 3 +-
sound/soc/soc-generic-dmaengine-pcm.c | 12 -------
6 files changed, 50 insertions(+), 27 deletions(-)
--
2.21.0
^ permalink raw reply
* Re: [PATCH 1/2] powerpc/64s: remove PROT_SAO support
From: Michael Ellerman @ 2020-06-12 6:14 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20200607120209.463501-1-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> ISA v3.1 does not support the SAO storage control attribute required to
> implement PROT_SAO. PROT_SAO was used by specialised system software
> (Lx86) that has been discontinued for about 7 years, and is not thought
> to be used elsewhere, so removal should not cause problems.
>
> We rather remove it than keep support for older processors, because
> live migrating guest partitions to newer processors may not be possible
> if SAO is in use.
They key details being:
- you don't remove PROT_SAO from the uapi header, so code using the
definition will still build.
- you change arch_validate_prot() to reject PROT_SAO, which means code
using it will see a failure from mmap() at runtime.
This obviously risks breaking userspace, even if we think it won't in
practice. I guess we don't really have any option given the hardware
support is being dropped.
Can you repost with a wider Cc list, including linux-mm and linux-arch?
I wonder if we should add a comment to the uapi header, eg?
diff --git a/arch/powerpc/include/uapi/asm/mman.h b/arch/powerpc/include/uapi/asm/mman.h
index c0c737215b00..d4fdbe768997 100644
--- a/arch/powerpc/include/uapi/asm/mman.h
+++ b/arch/powerpc/include/uapi/asm/mman.h
@@ -11,7 +11,7 @@
#include <asm-generic/mman-common.h>
-#define PROT_SAO 0x10 /* Strong Access Ordering */
+#define PROT_SAO 0x10 /* Unsupported since v5.9 */
#define MAP_RENAME MAP_ANONYMOUS /* In SunOS terminology */
#define MAP_NORESERVE 0x40 /* don't reserve swap pages */
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index f17442c3a092..d9e92586f8dc 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -20,9 +20,13 @@
> #define _PAGE_RW (_PAGE_READ | _PAGE_WRITE)
> #define _PAGE_RWX (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC)
> #define _PAGE_PRIVILEGED 0x00008 /* kernel access only */
> -#define _PAGE_SAO 0x00010 /* Strong access order */
> +
> +#define _PAGE_CACHE_CTL 0x00030 /* Bits for the folowing cache modes */
> + /* No bits set is normal cacheable memory */
> + /* 0x00010 unused, is SAO bit on radix POWER9 */
> #define _PAGE_NON_IDEMPOTENT 0x00020 /* non idempotent memory */
> #define _PAGE_TOLERANT 0x00030 /* tolerant memory, cache inhibited */
> +
Why'd you do it that way vs just dropping _PAGE_SAO from the or below?
> diff --git a/arch/powerpc/include/asm/cputable.h b/arch/powerpc/include/asm/cputable.h
> index bac2252c839e..c7e923b0000a 100644
> --- a/arch/powerpc/include/asm/cputable.h
> +++ b/arch/powerpc/include/asm/cputable.h
> @@ -191,7 +191,6 @@ static inline void cpu_feature_keys_init(void) { }
> #define CPU_FTR_SPURR LONG_ASM_CONST(0x0000000001000000)
> #define CPU_FTR_DSCR LONG_ASM_CONST(0x0000000002000000)
> #define CPU_FTR_VSX LONG_ASM_CONST(0x0000000004000000)
> -#define CPU_FTR_SAO LONG_ASM_CONST(0x0000000008000000)
Can you do:
+// Free LONG_ASM_CONST(0x0000000008000000)
> diff --git a/arch/powerpc/include/asm/kvm_book3s_64.h b/arch/powerpc/include/asm/kvm_book3s_64.h
> index 9bb9bb370b53..579c9229124b 100644
> --- a/arch/powerpc/include/asm/kvm_book3s_64.h
> +++ b/arch/powerpc/include/asm/kvm_book3s_64.h
> @@ -400,7 +400,8 @@ static inline bool hpte_cache_flags_ok(unsigned long hptel, bool is_ci)
>
> /* Handle SAO */
> if (wimg == (HPTE_R_W | HPTE_R_I | HPTE_R_M) &&
> - cpu_has_feature(CPU_FTR_ARCH_206))
> + cpu_has_feature(CPU_FTR_ARCH_206) &&
> + !cpu_has_feature(CPU_FTR_ARCH_31))
> wimg = HPTE_R_M;
Shouldn't it reject that combination if the host can't support it?
Or I guess it does, but yikes that code is not clear.
> diff --git a/arch/powerpc/include/asm/mman.h b/arch/powerpc/include/asm/mman.h
> index d610c2e07b28..43a62f3e21a0 100644
> --- a/arch/powerpc/include/asm/mman.h
> +++ b/arch/powerpc/include/asm/mman.h
> @@ -13,38 +13,24 @@
> #include <linux/pkeys.h>
> #include <asm/cpu_has_feature.h>
>
> -/*
> - * This file is included by linux/mman.h, so we can't use cacl_vm_prot_bits()
> - * here. How important is the optimization?
> - */
This comment seems confused, but also unrelated to this patch?
> diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c b/arch/powerpc/kernel/dt_cpu_ftrs.c
> index 3a409517c031..8d2e4043702f 100644
> --- a/arch/powerpc/kernel/dt_cpu_ftrs.c
> +++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
> @@ -622,7 +622,7 @@ static struct dt_cpu_feature_match __initdata
> {"processor-control-facility-v3", feat_enable_dbell, CPU_FTR_DBELL},
> {"processor-utilization-of-resources-register", feat_enable_purr, 0},
> {"no-execute", feat_enable, 0},
> - {"strong-access-ordering", feat_enable, CPU_FTR_SAO},
> + {"strong-access-ordering", feat_enable, 0},
Would it make more sense to drop it entirely? Or leave it commented out.
cheers
^ permalink raw reply related
* [PATCH 16/18] powerpc/pseries: remove memory "re-add" implementation
From: Nathan Lynch @ 2020-06-12 5:12 UTC (permalink / raw)
To: linuxppc-dev; +Cc: tyreld, srikar, ego, npiggin, svaidy
In-Reply-To: <20200612051238.1007764-1-nathanl@linux.ibm.com>
dlpar_memory() no longer has any callers which pass
PSERIES_HP_ELOG_ACTION_READD. Remove this case and the corresponding
unreachable code.
Signed-off-by: Nathan Lynch <nathanl@linux.ibm.com>
---
arch/powerpc/include/asm/rtas.h | 1 -
.../platforms/pseries/hotplug-memory.c | 42 -------------------
2 files changed, 43 deletions(-)
diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
index 0107d724e9da..55f9a154c95d 100644
--- a/arch/powerpc/include/asm/rtas.h
+++ b/arch/powerpc/include/asm/rtas.h
@@ -215,7 +215,6 @@ inline uint16_t pseries_errorlog_length(struct pseries_errorlog *sect)
#define PSERIES_HP_ELOG_ACTION_ADD 1
#define PSERIES_HP_ELOG_ACTION_REMOVE 2
-#define PSERIES_HP_ELOG_ACTION_READD 3
#define PSERIES_HP_ELOG_ID_DRC_NAME 1
#define PSERIES_HP_ELOG_ID_DRC_INDEX 2
diff --git a/arch/powerpc/platforms/pseries/hotplug-memory.c b/arch/powerpc/platforms/pseries/hotplug-memory.c
index 5ace2f9a277e..67ece3ac9ac2 100644
--- a/arch/powerpc/platforms/pseries/hotplug-memory.c
+++ b/arch/powerpc/platforms/pseries/hotplug-memory.c
@@ -487,40 +487,6 @@ static int dlpar_memory_remove_by_index(u32 drc_index)
return rc;
}
-static int dlpar_memory_readd_by_index(u32 drc_index)
-{
- struct drmem_lmb *lmb;
- int lmb_found;
- int rc;
-
- pr_info("Attempting to update LMB, drc index %x\n", drc_index);
-
- lmb_found = 0;
- for_each_drmem_lmb(lmb) {
- if (lmb->drc_index == drc_index) {
- lmb_found = 1;
- rc = dlpar_remove_lmb(lmb);
- if (!rc) {
- rc = dlpar_add_lmb(lmb);
- if (rc)
- dlpar_release_drc(lmb->drc_index);
- }
- break;
- }
- }
-
- if (!lmb_found)
- rc = -EINVAL;
-
- if (rc)
- pr_info("Failed to update memory at %llx\n",
- lmb->base_addr);
- else
- pr_info("Memory at %llx was updated\n", lmb->base_addr);
-
- return rc;
-}
-
static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
{
struct drmem_lmb *lmb, *start_lmb, *end_lmb;
@@ -617,10 +583,6 @@ static int dlpar_memory_remove_by_index(u32 drc_index)
{
return -EOPNOTSUPP;
}
-static int dlpar_memory_readd_by_index(u32 drc_index)
-{
- return -EOPNOTSUPP;
-}
static int dlpar_memory_remove_by_ic(u32 lmbs_to_remove, u32 drc_index)
{
@@ -902,10 +864,6 @@ int dlpar_memory(struct pseries_hp_errorlog *hp_elog)
break;
}
- break;
- case PSERIES_HP_ELOG_ACTION_READD:
- drc_index = hp_elog->_drc_u.drc_index;
- rc = dlpar_memory_readd_by_index(drc_index);
break;
default:
pr_err("Invalid action (%d) specified\n", hp_elog->action);
--
2.25.4
^ permalink raw reply related
* Re: ppc64le and 32-bit LE userland compatibility
From: Christophe Leroy @ 2020-06-12 5:13 UTC (permalink / raw)
To: Will Springer, linuxppc-dev
Cc: libc-alpha, eery, daniel, musl, binutils, libc-dev
In-Reply-To: <1787237.g5d078U9FE@sheen>
Le 06/06/2020 à 01:54, Will Springer a écrit :
> On Saturday, May 30, 2020 3:17:24 PM PDT Will Springer wrote:
>> On Saturday, May 30, 2020 8:37:43 AM PDT Christophe Leroy wrote:
>>> There is a series at
>>> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=173231
>>> to switch powerpc to the Generic C VDSO.
>>>
>>> Can you try and see whether it fixes your issue ?
>>>
>>> Christophe
>>
>> Sure thing, I spotted that after making the initial post. Will report
>> back with results.
>>
>> Will [she/her]
>
> Sorry for the wait, I just sat down to work on this again yesterday.
>
> Tested this series on top of stable/linux-5.7.y (5.7.0 at the time of
> writing), plus the one-line signal handler patch. Had to rewind to the
> state of powerpc/merge at the time of the mail before the patch would
> apply, then cherry-picked to 5.6 until I realized the patchset used some
> functionality that didn't land until 5.7, so I moved it there.
>
> Good news is that `date` now works correctly with the vdso call in 32-bit
> LE. Bad news is it seems to have broken things on the 64-bit side—in my
> testing, Void kicks off runit but hangs after starting eudev, and in a
> Debian Stretch system, systemd doesn't get to the point of printing
> anything whatsoever. (I had to `init=/bin/sh` to confirm the date worked
> in ppcle, although in ppc64le running `date` also hung the system when it
> made the vdso call...) Not sure how to approach debugging that, so I'd
> appreciate any pointers.
>
Does it breaks only ppc64le vdso or also ppc64 (be) vdso ?
I never had a chance to run any test on ppc64 as I only have a kernel
cross compiler.
Would you have a chance to build and run vdsotest from
https://github.com/nathanlynch/vdsotest ?
Thanks
Christophe
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox