Re: [PATCH] iwlwifi: fix memory leaks in iwl_pcie_ctxt_info_gen3_init
On Fri, 2019-09-27 at 15:56 -0500, Navid Emamdoost wrote:
> In iwl_pcie_ctxt_info_gen3_init there are cases that the allocated dma
> memory is leaked in case of error.
> DMA memories prph_scratch, prph_info, and ctxt_info_gen3 are allocated
> and initialized to be later assigned to trans_pcie. But in any error case
> before such assignment the allocated memories should be released.
> First of such error cases happens when iwl_pcie_init_fw_sec fails.
> Current implementation correctly releases prph_scratch. But in two
> sunsequent error cases where dma_alloc_coherent may fail, such releases
> are missing. This commit adds release for prph_scratch when allocation
> for prph_info fails, and adds releases for prph_scratch and prph_info
> when allocation for ctxt_info_gen3 fails.
>
> Fixes: 2ee824026288 ("iwlwifi: pcie: support context information for 22560
> devices")
>
> Signed-off-by: Navid Emamdoost
> ---
Thanks, Navid! I have applied this to our internal tree and it will
reach the mainline following our usual upstreaming process.
--
Cheers,
Luca.
Re: [PATCH] usb: dwc3: pci: prevent memory leak in dwc3_pci_probe
> … This commit replaces return with the goto. How do you think about to omit the wording “This commit” from your change descriptions? https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=97f9a3c4eee55b0178b518ae7114a6a53372913d#n151 Regards, Markus
Re: [PATCH v2 1/1] i2c: iproc: Add i2c repeated start capability
On Sat, Sep 28, 2019 at 11:53 PM Wolfram Sang wrote: > > On Thu, Sep 26, 2019 at 10:10:08AM +0530, Rayagonda Kokatanur wrote: > > From: Lori Hikichi > > > > Enable handling of i2c repeated start. The current code > > handles a multi msg i2c transfer as separate i2c bus > > transactions. This change will now handle this case > > using the i2c repeated start protocol. The number of msgs > > in a transfer is limited to two, and must be a write > > followed by a read. > > > > Signed-off-by: Lori Hikichi > > Signed-off-by: Rayagonda Kokatanur > > Signed-off-by: Icarus Chau > > Signed-off-by: Ray Jui > > Signed-off-by: Shivaraj Shetty > > --- > > changes from v1: > > - Address code review comment from Wolfram Sang > > No, sorry, this is not a proper changelog. I review so many patches, I > can't recall what I suggested to do for every patch. Please describe > what changes you actually made. It is also better when digging through > mail archives. > Sorry for inconvenience, I updated the changelog and resent the patch. I have kept the patch version as v2 only. Hope that is fine. Best regards, Rayagonda
[PATCH v2 1/1] i2c: iproc: Add i2c repeated start capability
From: Lori Hikichi
Enable handling of i2c repeated start. The current code
handles a multi msg i2c transfer as separate i2c bus
transactions. This change will now handle this case
using the i2c repeated start protocol. The number of msgs
in a transfer is limited to two, and must be a write
followed by a read.
Signed-off-by: Lori Hikichi
Signed-off-by: Rayagonda Kokatanur
Signed-off-by: Icarus Chau
Signed-off-by: Ray Jui
Signed-off-by: Shivaraj Shetty
---
changes from v1:
- Address following review comments from Wolfarm Sang,
Use i2c_8bit_addr_from_msg() api instead of decoding i2c_msg struct and
remove check against number of i2c message as it will be taken care
by core using quirks flags.
drivers/i2c/busses/i2c-bcm-iproc.c | 63 ++
1 file changed, 50 insertions(+), 13 deletions(-)
diff --git a/drivers/i2c/busses/i2c-bcm-iproc.c
b/drivers/i2c/busses/i2c-bcm-iproc.c
index d7fd76b..e478db7 100644
--- a/drivers/i2c/busses/i2c-bcm-iproc.c
+++ b/drivers/i2c/busses/i2c-bcm-iproc.c
@@ -81,6 +81,7 @@
#define M_CMD_PROTOCOL_MASK 0xf
#define M_CMD_PROTOCOL_BLK_WR0x7
#define M_CMD_PROTOCOL_BLK_RD0x8
+#define M_CMD_PROTOCOL_PROCESS 0xa
#define M_CMD_PEC_SHIFT 8
#define M_CMD_RD_CNT_SHIFT 0
#define M_CMD_RD_CNT_MASK0xff
@@ -675,13 +676,20 @@ static int bcm_iproc_i2c_xfer_wait(struct
bcm_iproc_i2c_dev *iproc_i2c,
return 0;
}
-static int bcm_iproc_i2c_xfer_single_msg(struct bcm_iproc_i2c_dev *iproc_i2c,
-struct i2c_msg *msg)
+/*
+ * If 'process_call' is true, then this is a multi-msg transfer that requires
+ * a repeated start between the messages.
+ * More specifically, it must be a write (reg) followed by a read (data).
+ * The i2c quirks are set to enforce this rule.
+ */
+static int bcm_iproc_i2c_xfer_internal(struct bcm_iproc_i2c_dev *iproc_i2c,
+ struct i2c_msg *msgs, bool process_call)
{
int i;
u8 addr;
u32 val, tmp, val_intr_en;
unsigned int tx_bytes;
+ struct i2c_msg *msg = &msgs[0];
/* check if bus is busy */
if (!!(iproc_i2c_rd_reg(iproc_i2c,
@@ -707,14 +715,29 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
val = msg->buf[i];
/* mark the last byte */
- if (i == msg->len - 1)
- val |= BIT(M_TX_WR_STATUS_SHIFT);
+ if (!process_call && (i == msg->len - 1))
+ val |= 1 << M_TX_WR_STATUS_SHIFT;
iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
}
iproc_i2c->tx_bytes = tx_bytes;
}
+ /* Process the read message if this is process call */
+ if (process_call) {
+ msg++;
+ iproc_i2c->msg = msg; /* point to second msg */
+
+ /*
+* The last byte to be sent out should be a slave
+* address with read operation
+*/
+ addr = i2c_8bit_addr_from_msg(msg);
+ /* mark it the last byte out */
+ val = addr | (1 << M_TX_WR_STATUS_SHIFT);
+ iproc_i2c_wr_reg(iproc_i2c, M_TX_OFFSET, val);
+ }
+
/* mark as incomplete before starting the transaction */
if (iproc_i2c->irq)
reinit_completion(&iproc_i2c->done);
@@ -733,7 +756,7 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
* underrun interrupt, which will be triggerred when the TX FIFO is
* empty. When that happens we can then pump more data into the FIFO
*/
- if (!(msg->flags & I2C_M_RD) &&
+ if (!process_call && !(msg->flags & I2C_M_RD) &&
msg->len > iproc_i2c->tx_bytes)
val_intr_en |= BIT(IE_M_TX_UNDERRUN_SHIFT);
@@ -743,6 +766,8 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
*/
val = BIT(M_CMD_START_BUSY_SHIFT);
if (msg->flags & I2C_M_RD) {
+ u32 protocol;
+
iproc_i2c->rx_bytes = 0;
if (msg->len > M_RX_FIFO_MAX_THLD_VALUE)
iproc_i2c->thld_bytes = M_RX_FIFO_THLD_VALUE;
@@ -758,7 +783,10 @@ static int bcm_iproc_i2c_xfer_single_msg(struct
bcm_iproc_i2c_dev *iproc_i2c,
/* enable the RX threshold interrupt */
val_intr_en |= BIT(IE_M_RX_THLD_SHIFT);
- val |= (M_CMD_PROTOCOL_BLK_RD << M_CMD_PROTOCOL_SHIFT) |
+ protocol = process_call ?
+ M_CMD_PROTOCOL_PROCESS : M_CMD_PROTOCOL_BLK_RD;
+
+ val |= (protocol << M_CMD_PROTOCOL_SHIFT) |
(msg->len << M_CMD_RD_CNT_SHIFT);
} else {
val |= (M_CMD_PROTOCOL_BLK
Re: [PATCH] iwlwifi: dvm: excessive if in rs_bt_update_lq()
On Wed, 2019-09-25 at 23:49 +0300, Denis Efremov wrote: > There is no need to check 'priv->bt_ant_couple_ok' twice in > rs_bt_update_lq(). The second check is always true. Thus, the > expression can be simplified. > > Signed-off-by: Denis Efremov > --- > drivers/net/wireless/intel/iwlwifi/dvm/rs.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c > b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c > index 74229fcb63a9..226165db7dfd 100644 > --- a/drivers/net/wireless/intel/iwlwifi/dvm/rs.c > +++ b/drivers/net/wireless/intel/iwlwifi/dvm/rs.c > @@ -851,7 +851,7 @@ static void rs_bt_update_lq(struct iwl_priv *priv, struct > iwl_rxon_context *ctx, >* Is there a need to switch between >* full concurrency and 3-wire? >*/ > - if (priv->bt_ci_compliance && priv->bt_ant_couple_ok) > + if (priv->bt_ci_compliance) > full_concurrent = true; > else > full_concurrent = false; Thanks, Denis! I have applied this to our internal tree and it will reach the mainline following our usual upstreaming process. -- Cheers, Luca.
Re: [PATCH] mm/page_alloc: fix a crash in free_pages_prepare()
On 27.09.19 23:59, Andrew Morton wrote: > On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai wrote: > >>> >>> So I think you've moved the arch_free_page() to be after the final >>> thing which can access page contents, yes? If so, we should have a >>> comment in free_pages_prepare() to attmept to prevent this problem from >>> reoccurring as the code evolves? >> >> Right, something like this above arch_free_page() there? >> >> /* >> * It needs to be just above kernel_map_pages(), as s390 could mark those >> * pages unused and then trigger a fault when accessing. >> */ > > I did this. > > --- a/mm/page_alloc.c~mm-page_alloc-fix-a-crash-in-free_pages_prepare-fix > +++ a/mm/page_alloc.c > @@ -1179,7 +1179,13 @@ static __always_inline bool free_pages_p > kernel_init_free_pages(page, 1 << order); > > kernel_poison_pages(page, 1 << order, 0); > + /* > + * arch_free_page() can make the page's contents inaccessible. s390 > + * does this. So nothing which can access the page's contents should > + * happen after this. > + */ > arch_free_page(page, order); > + > if (debug_pagealloc_enabled()) > kernel_map_pages(page, 1 << order, 0); With that Acked-by: Christian Borntraeger
Re: [PATCH] mm/page_alloc: fix a crash in free_pages_prepare()
On 28.09.19 11:06, David Hildenbrand wrote:
> On 28.09.19 00:17, Alexander Duyck wrote:
>> On Fri, Sep 27, 2019 at 2:59 PM Andrew Morton
>> wrote:
>>>
>>> On Fri, 27 Sep 2019 17:28:06 -0400 Qian Cai wrote:
>>>
>
> So I think you've moved the arch_free_page() to be after the final
> thing which can access page contents, yes? If so, we should have a
> comment in free_pages_prepare() to attmept to prevent this problem from
> reoccurring as the code evolves?
Right, something like this above arch_free_page() there?
/*
* It needs to be just above kernel_map_pages(), as s390 could mark those
* pages unused and then trigger a fault when accessing.
*/
>>>
>>> I did this.
>>>
>>> --- a/mm/page_alloc.c~mm-page_alloc-fix-a-crash-in-free_pages_prepare-fix
>>> +++ a/mm/page_alloc.c
>>> @@ -1179,7 +1179,13 @@ static __always_inline bool free_pages_p
>>> kernel_init_free_pages(page, 1 << order);
>>>
>>> kernel_poison_pages(page, 1 << order, 0);
>>> + /*
>>> +* arch_free_page() can make the page's contents inaccessible. s390
>>> +* does this. So nothing which can access the page's contents
>>> should
>>> +* happen after this.
>>> +*/
>>> arch_free_page(page, order);
>>> +
>>> if (debug_pagealloc_enabled())
>>> kernel_map_pages(page, 1 << order, 0);
>>>
>>
>> So the question I would have is what is the state of the page after it
>> has been marked unused and then pulled back in? I'm assuming it will
>> be all 0s.
>
> I think this comment relates to the s390x implementation, so I'll try to
> explain that. After arch_free_page() the page might have been zapped in
> the hypervisor, but that might happen deferred. The guest ends up
> triggering the ESSA instruction in arch_free_page(). That instruction
> sets some extended-page-table-related ("pgste") bits in the hypervisor
> tables for the guest ("gmap") and fills a buffer with these entries. The
> page is marked _PGSTE_GPS_USAGE_UNUSED.
Yes. And that also means that architecturally it can be 0 or it can contain
the old content depending on whether the host has paged that page out or not
and how many pages have been marked unused.
I am also sure that the implementation of z/VM and KVM do differ in that regard.
For example KVM does not make use of the logical zero state but z/VM does.
In essence you can consider this like a ballooner that takes away the page
lazily.
For a writeup of the details see
https://www.kernel.org/doc/ols/2006/ols2006v2-pages-321-336.pdf
(This also contains additional states that were never merged upstream)
[RFC PATCH] Don't copy mark from encapsulated packet when routing VXLAN
When using rule-based routing to send traffic via VXLAN, a routing loop may occur. Say you have the following routing setup: ip rule add from all fwmark 0x2/0x2 lookup 2 ip route add table 2 default via 10.244.2.0 dev vxlan1 onlink The intention is to route packets with mark 2 through VXLAN, and this works fine. However, the current vxlan code copies the mark to the encapsulated packet. Immediately after egress on the VXLAN interface, the encapsulated packet is routed, with no opportunity to mangle the encapsulated packet. The mark is copied from the inner packet to the outer packet, and the same routing rule and table shown above will apply, resulting in ELOOP. This patch simply doesn't copy the mark from the encapsulated packet. I don't intend this code to land as is, but I want to start a discussion on how to make separate routing of VXLAN inner and encapsulated traffic easier. Signed-off-by: Jethro Beekman --- drivers/net/vxlan.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index 3d9bcc9..f9ed1b7 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -2236,7 +2236,6 @@ static struct rtable *vxlan_get_route(struct vxlan_dev *vxlan, struct net_device memset(&fl4, 0, sizeof(fl4)); fl4.flowi4_oif = oif; fl4.flowi4_tos = RT_TOS(tos); - fl4.flowi4_mark = skb->mark; fl4.flowi4_proto = IPPROTO_UDP; fl4.daddr = daddr; fl4.saddr = *saddr; @@ -2294,7 +2293,6 @@ static struct dst_entry *vxlan6_get_route(struct vxlan_dev *vxlan, fl6.daddr = *daddr; fl6.saddr = *saddr; fl6.flowlabel = ip6_make_flowinfo(RT_TOS(tos), label); - fl6.flowi6_mark = skb->mark; fl6.flowi6_proto = IPPROTO_UDP; fl6.fl6_dport = dport; fl6.fl6_sport = sport; -- 2.7.4 smime.p7s Description: S/MIME Cryptographic Signature
Re: [PATCH] iwlwifi: dbg_ini: fix memory leak in alloc_sgtable
On Thu, 2019-09-12 at 23:23 -0500, Navid Emamdoost wrote: > In alloc_sgtable if alloc_page fails, the alocated table should be > released. > > Signed-off-by: Navid Emamdoost > --- > drivers/net/wireless/intel/iwlwifi/fw/dbg.c | 1 + > 1 file changed, 1 insertion(+) Thanks, Navid! I have applied this to our internal tree and it will reach the mainline following our usual upstreaming process. -- Cheers, Luca.
Re: [PATCH] spi: gpio: prevent memory leak in spi_gpio_probe
* Please avoid typos in the commit message. * I would prefer an other wording for the change description. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=97f9a3c4eee55b0178b518ae7114a6a53372913d#n151 Regards, Markus
[PATCH v6 1/1] memory_hotplug: Add a bounds check to __add_pages
From: Alastair D'Silva
On PowerPC, the address ranges allocated to OpenCAPI LPC memory
are allocated from firmware. These address ranges may be higher
than what older kernels permit, as we increased the maximum
permissable address in commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB"). It is
possible that the addressable range may change again in the
future.
In this scenario, we end up with a bogus section returned from
__section_nr (see the discussion on the thread "mm: Trigger bug on
if a section is not found in __section_nr").
Adding a check here means that we fail early and have an
opportunity to handle the error gracefully, rather than rumbling
on and potentially accessing an incorrect section.
Further discussion is also on the thread ("powerpc: Perform a bounds
check in arch_add_memory")
http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com
Signed-off-by: Alastair D'Silva
---
mm/memory_hotplug.c | 20
1 file changed, 20 insertions(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c73f09913165..a5eddf3c3c1f 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -278,6 +278,22 @@ static int check_pfn_span(unsigned long pfn, unsigned long
nr_pages,
return 0;
}
+static int check_hotplug_memory_addressable(unsigned long pfn,
+ unsigned long nr_pages)
+{
+ const u64 max_addr = PFN_PHYS(pfn + nr_pages) - 1;
+
+ if (max_addr >> MAX_PHYSMEM_BITS) {
+ const u64 max_allowed = (1ull << (MAX_PHYSMEM_BITS + 1)) - 1;
+ WARN(1,
+"Hotplugged memory exceeds maximum addressable address,
range=%#llx-%#llx, maximum=%#llx\n",
+PFN_PHYS(pfn), max_addr, max_allowed);
+ return -E2BIG;
+ }
+
+ return 0;
+}
+
/*
* Reasonably generic function for adding memory. It is
* expected that archs that support memory hotplug will
@@ -291,6 +307,10 @@ int __ref __add_pages(int nid, unsigned long pfn, unsigned
long nr_pages,
unsigned long nr, start_sec, end_sec;
struct vmem_altmap *altmap = restrictions->altmap;
+ err = check_hotplug_memory_addressable(pfn, nr_pages);
+ if (err)
+ return err;
+
if (altmap) {
/*
* Validate altmap is within bounds of the total request
--
2.21.0
[PATCH v6 0/1] Add bounds check for Hotplugged memory
From: Alastair D'Silva This series adds bounds checks for hotplugged memory, ensuring that it is within the physically addressable range (for platforms that define MAX_(POSSIBLE_)PHYSMEM_BITS. This allows for early failure, rather than attempting to access bogus section numbers. Changelog: V6: - Fix printf formats V5: - Factor out calculation into max_allowed var - Declare unchanging vars as const - Use PFN_PHYS macro instead of shifting by PAGE_SHIFT V4: - Relocate call to __add_pages - Add a warning when the addressable check fails V3: - Perform the addressable check before we take the hotplug lock V2: - Don't use MAX_POSSIBLE_PHYSMEM_BITS as it's wider that what may be available Alastair D'Silva (1): memory_hotplug: Add a bounds check to __add_pages mm/memory_hotplug.c | 20 1 file changed, 20 insertions(+) -- 2.21.0
[PATCH V10 0/2] mailbox: arm: introduce smc triggered mailbox
From: Peng Fan V10: - Add R-b tag from Andre, Rob and Florian - Two minor fixes - Drop "passed from consumers" in patch 1/2 per Andre's comments - Drop interrupts.h in patch 2/2 per Andre's comments V9: - Add Florian's R-b tag in patch 1/2 - Mark arm,func-id as a required property per Andre's comments in patch 1/2. - Make invoke_smc_mbox_fn as a private entry in a channal per Florian's comments in pach 2/2 - Include linux/types.h in arm-smccc-mbox.h in patch 2/2 - Drop function_id from arm_smccc_mbox_cmd since func-id is from DT in patch 2/2/. Andre, I have marked arm,func-id as a required property and dropped function-id from client, please see whether you are happy with the patchset. Hope we could finalize and get patches land in. Thanks, Peng. V8: Add missed arm-smccc-mbox.h V7: Typo fix #mbox-cells changed to 0 Add a new header file arm-smccc-mbox.h Use ARM_SMCCC_IS_64 Andre, The function_id is still kept in arm_smccc_mbox_cmd, because arm,func-id property is optional, so clients could pass function_id to mbox driver. V6: Switch to per-channel a mbox controller Drop arm,num-chans, transports, method Add arm,hvc-mbox compatible Fix smc/hvc args, drop client id and use correct type. https://patchwork.kernel.org/cover/11146641/ V5: yaml fix https://patchwork.kernel.org/cover/7741/ V4: yaml fix for num-chans in patch 1/2. https://patchwork.kernel.org/cover/6521/ V3: Drop interrupt Introduce transports for mem/reg usage Add chan-id for mem usage Convert to yaml format https://patchwork.kernel.org/cover/11043541/ V2: This is a modified version from Andre Przywara's patch series https://lore.kernel.org/patchwork/cover/812997/. The modification are mostly: Introduce arm,num-chans Introduce arm_smccc_mbox_cmd txdone_poll and txdone_irq are both set to false arm,func-ids are kept, but as an optional property. Rewords SCPI to SCMI, because I am trying SCMI over SMC, not SCPI. Introduce interrupts notification. [1] is a draft implementation of i.MX8MM SCMI ATF implementation that use smc as mailbox, power/clk is included, but only part of clk has been implemented to work with hardware, power domain only supports get name for now. The traditional Linux mailbox mechanism uses some kind of dedicated hardware IP to signal a condition to some other processing unit, typically a dedicated management processor. This mailbox feature is used for instance by the SCMI protocol to signal a request for some action to be taken by the management processor. However some SoCs does not have a dedicated management core to provide those services. In order to service TEE and to avoid linux shutdown power and clock that used by TEE, need let firmware to handle power and clock, the firmware here is ARM Trusted Firmware that could also run SCMI service. The existing SCMI implementation uses a rather flexible shared memory region to communicate commands and their parameters, it still requires a mailbox to actually trigger the action. This patch series provides a Linux mailbox compatible service which uses smc calls to invoke firmware code, for instance taking care of SCMI requests. The actual requests are still communicated using the standard SCMI way of shared memory regions, but a dedicated mailbox hardware IP can be replaced via this new driver. This simple driver uses the architected SMC calling convention to trigger firmware services, also allows for using "HVC" calls to call into hypervisors or firmware layers running in the EL2 exception level. Patch 1 contains the device tree binding documentation, patch 2 introduces the actual mailbox driver. Please note that this driver just provides a generic mailbox mechanism, It could support synchronous TX/RX, or synchronous TX with asynchronous RX. And while providing SCMI services was the reason for this exercise, this driver is in no way bound to this use case, but can be used generically where the OS wants to signal a mailbox condition to firmware or a hypervisor. Also the driver is in no way meant to replace any existing firmware interface, but actually to complement existing interfaces. [1] https://github.com/MrVan/arm-trusted-firmware/tree/scmi Peng Fan (2): dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox mailbox: introduce ARM SMC based mailbox .../devicetree/bindings/mailbox/arm-smc.yaml | 96 drivers/mailbox/Kconfig| 7 + drivers/mailbox/Makefile | 2 + drivers/mailbox/arm-smc-mailbox.c | 166 + include/linux/mailbox/arm-smccc-mbox.h | 20 +++ 5 files changed, 291 insertions(+) create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml create mode 100644 drivers/mailbox/arm-smc-mailbox.c create mode 100644 include/linux/mailbox/arm-smccc-mbox.h -- 2.16.4
[PATCH V10 1/2] dt-bindings: mailbox: add binding doc for the ARM SMC/HVC mailbox
From: Peng Fan
The ARM SMC/HVC mailbox binding describes a firmware interface to trigger
actions in software layers running in the EL2 or EL3 exception levels.
The term "ARM" here relates to the SMC instruction as part of the ARM
instruction set, not as a standard endorsed by ARM Ltd.
Reviewed-by: Rob Herring
Reviewed-by: Andre Przywara
Reviewed-by: Florian Fainelli
Signed-off-by: Peng Fan
---
.../devicetree/bindings/mailbox/arm-smc.yaml | 96 ++
1 file changed, 96 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mailbox/arm-smc.yaml
diff --git a/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
new file mode 100644
index ..c165946a64e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mailbox/arm-smc.yaml
@@ -0,0 +1,96 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mailbox/arm-smc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM SMC Mailbox Interface
+
+maintainers:
+ - Peng Fan
+
+description: |
+ This mailbox uses the ARM smc (secure monitor call) or hvc (hypervisor
+ call) instruction to trigger a mailbox-connected activity in firmware,
+ executing on the very same core as the caller. The value of r0/w0/x0
+ the firmware returns after the smc call is delivered as a received
+ message to the mailbox framework, so synchronous communication can be
+ established. The exact meaning of the action the mailbox triggers as
+ well as the return value is defined by their users and is not subject
+ to this binding.
+
+ One example use case of this mailbox is the SCMI interface, which uses
+ shared memory to transfer commands and parameters, and a mailbox to
+ trigger a function call. This allows SoCs without a separate management
+ processor (or when such a processor is not available or used) to use
+ this standardized interface anyway.
+
+ This binding describes no hardware, but establishes a firmware interface.
+ Upon receiving an SMC using the described SMC function identifier, the
+ firmware is expected to trigger some mailbox connected functionality.
+ The communication follows the ARM SMC calling convention.
+ Firmware expects an SMC function identifier in r0 or w0. The supported
+ identifier is listed in the the arm,func-id property as described below.
+ The firmware can return one value in the first SMC result register,
+ it is expected to be an error value, which shall be propagated to the
+ mailbox client.
+
+ Any core which supports the SMC or HVC instruction can be used, as long
+ as a firmware component running in EL3 or EL2 is handling these calls.
+
+properties:
+ compatible:
+oneOf:
+ - description:
+ For implementations using ARM SMC instruction.
+const: arm,smc-mbox
+
+ - description:
+ For implementations using ARM HVC instruction.
+const: arm,hvc-mbox
+
+ "#mbox-cells":
+const: 0
+
+ arm,func-id:
+description: |
+ An single 32-bit value specifying the function ID used by the mailbox.
+ The function ID follows the ARM SMC calling convention standard.
+$ref: /schemas/types.yaml#/definitions/uint32
+
+required:
+ - compatible
+ - "#mbox-cells"
+ - arm,func-id
+
+examples:
+ - |
+sram@93f000 {
+ compatible = "mmio-sram";
+ reg = <0x0 0x93f000 0x0 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x93f000 0x1000>;
+
+ cpu_scp_lpri: scp-shmem@0 {
+compatible = "arm,scmi-shmem";
+reg = <0x0 0x200>;
+ };
+};
+
+smc_tx_mbox: tx_mbox {
+ #mbox-cells = <0>;
+ compatible = "arm,smc-mbox";
+ arm,func-id = <0xc2fe>;
+};
+
+firmware {
+ scmi {
+compatible = "arm,scmi";
+mboxes = <&smc_tx_mbox>;
+mbox-names = "tx";
+shmem = <&cpu_scp_lpri>;
+ };
+};
+
+...
--
2.16.4
[PATCH V10 2/2] mailbox: introduce ARM SMC based mailbox
From: Peng Fan
This mailbox driver implements a mailbox which signals transmitted data
via an ARM smc (secure monitor call) instruction. The mailbox receiver
is implemented in firmware and can synchronously return data when it
returns execution to the non-secure world again.
An asynchronous receive path is not implemented.
This allows the usage of a mailbox to trigger firmware actions on SoCs
which either don't have a separate management processor or on which such
a core is not available. A user of this mailbox could be the SCP
interface.
Modified from Andre Przywara's v2 patch
https://lore.kernel.org/patchwork/patch/812999/
Reviewed-by: Florian Fainelli
Reviewed-by: Andre Przywara
Signed-off-by: Peng Fan
---
drivers/mailbox/Kconfig| 7 ++
drivers/mailbox/Makefile | 2 +
drivers/mailbox/arm-smc-mailbox.c | 166 +
include/linux/mailbox/arm-smccc-mbox.h | 20
4 files changed, 195 insertions(+)
create mode 100644 drivers/mailbox/arm-smc-mailbox.c
create mode 100644 include/linux/mailbox/arm-smccc-mbox.h
diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
index ab4eb750bbdd..7707ee26251a 100644
--- a/drivers/mailbox/Kconfig
+++ b/drivers/mailbox/Kconfig
@@ -16,6 +16,13 @@ config ARM_MHU
The controller has 3 mailbox channels, the last of which can be
used in Secure mode only.
+config ARM_SMC_MBOX
+ tristate "Generic ARM smc mailbox"
+ depends on OF && HAVE_ARM_SMCCC
+ help
+ Generic mailbox driver which uses ARM smc calls to call into
+ firmware for triggering mailboxes.
+
config IMX_MBOX
tristate "i.MX Mailbox"
depends on ARCH_MXC || COMPILE_TEST
diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
index c22fad6f696b..93918a84c91b 100644
--- a/drivers/mailbox/Makefile
+++ b/drivers/mailbox/Makefile
@@ -7,6 +7,8 @@ obj-$(CONFIG_MAILBOX_TEST) += mailbox-test.o
obj-$(CONFIG_ARM_MHU) += arm_mhu.o
+obj-$(CONFIG_ARM_SMC_MBOX) += arm-smc-mailbox.o
+
obj-$(CONFIG_IMX_MBOX) += imx-mailbox.o
obj-$(CONFIG_ARMADA_37XX_RWTM_MBOX)+= armada-37xx-rwtm-mailbox.o
diff --git a/drivers/mailbox/arm-smc-mailbox.c
b/drivers/mailbox/arm-smc-mailbox.c
new file mode 100644
index ..a6ec56f41f7f
--- /dev/null
+++ b/drivers/mailbox/arm-smc-mailbox.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016,2017 ARM Ltd.
+ * Copyright 2019 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+typedef unsigned long (smc_mbox_fn)(unsigned int, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long, unsigned long,
+ unsigned long);
+
+struct arm_smc_chan_data {
+ unsigned int function_id;
+ smc_mbox_fn *invoke_smc_mbox_fn;
+};
+
+static int arm_smc_send_data(struct mbox_chan *link, void *data)
+{
+ struct arm_smc_chan_data *chan_data = link->con_priv;
+ struct arm_smccc_mbox_cmd *cmd = data;
+ unsigned long ret;
+
+ if (ARM_SMCCC_IS_64(chan_data->function_id)) {
+ ret = chan_data->invoke_smc_mbox_fn(chan_data->function_id,
+ cmd->args_smccc64[0],
+ cmd->args_smccc64[1],
+ cmd->args_smccc64[2],
+ cmd->args_smccc64[3],
+ cmd->args_smccc64[4],
+ cmd->args_smccc64[5]);
+ } else {
+ ret = chan_data->invoke_smc_mbox_fn(chan_data->function_id,
+ cmd->args_smccc32[0],
+ cmd->args_smccc32[1],
+ cmd->args_smccc32[2],
+ cmd->args_smccc32[3],
+ cmd->args_smccc32[4],
+ cmd->args_smccc32[5]);
+ }
+
+ mbox_chan_received_data(link, (void *)ret);
+
+ return 0;
+}
+
+static unsigned long __invoke_fn_hvc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsigned long arg2, unsigned long arg3,
+unsigned long arg4, unsigned long arg5)
+{
+ struct arm_smccc_res res;
+
+ arm_smccc_hvc(function_id, arg0, arg1, arg2, arg3, arg4,
+ arg5, 0, &res);
+ return res.a0;
+}
+
+static unsigned long __invoke_fn_smc(unsigned int function_id,
+unsigned long arg0, unsigned long arg1,
+unsig
Re: [PATCH 4.19 33/63] tpm: Fix TPM 1.2 Shutdown sequence to prevent future TPM operations
> From: Vadim Sukhomlinov
>
> commit db4d8cb9c9f2af71c4d087817160d866ed572cc9 upstream
>
> TPM 2.0 Shutdown involve sending TPM2_Shutdown to TPM chip and disabling
> future TPM operations. TPM 1.2 behavior was different, future TPM
> operations weren't disabled, causing rare issues. This patch ensures
> that future TPM operations are disabled.
> diff --git a/drivers/char/tpm/tpm-chip.c b/drivers/char/tpm/tpm-chip.c
> index 46caadca916a0..dccc61af9ffab 100644
> --- a/drivers/char/tpm/tpm-chip.c
> +++ b/drivers/char/tpm/tpm-chip.c
> @@ -187,12 +187,15 @@ static int tpm_class_shutdown(struct device *dev)
> {
> struct tpm_chip *chip = container_of(dev, struct tpm_chip, dev);
>
> + down_write(&chip->ops_sem);
> if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> down_write(&chip->ops_sem);
> tpm2_shutdown(chip, TPM2_SU_CLEAR);
> chip->ops = NULL;
> up_write(&chip->ops_sem);
> }
> + chip->ops = NULL;
> + up_write(&chip->ops_sem);
This is wrong, it takes &chip->ops_sem twice, that can't be
good. db4d8cb9c9f2af71c4d087817160d866ed572cc9 does not have that
problem.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: x86/random: Speculation to the rescue
On Sun, Sep 29, 2019 at 07:59:19PM -0700, Linus Torvalds wrote: > All my smoke testing looked fine - I disabled trusting the CPU, I > increased the required entropy a lot, and to actually trigger the > lockup issue without the broken user space, I made /dev/urandom do > that "wait for entropy" thing too. Hohum, seems to get rid of the longish delay during boot on my test boxes here: $ grep random /var/log/messages <--- that's before Sep 30 07:46:07 cz vmunix: [0.00] random: get_random_bytes called from start_kernel+0x304/0x4ac with crng_init=0 Sep 30 07:46:07 cz vmunix: [1.505641] random: fast init done Sep 30 07:46:07 cz vmunix: [7.124808] random: dd: uninitialized urandom read (512 bytes read) Sep 30 07:46:07 cz vmunix: [8.507672] random: dbus-daemon: uninitialized urandom read (12 bytes read) Sep 30 07:46:07 cz vmunix: [8.518621] random: dbus-daemon: uninitialized urandom read (12 bytes read) Sep 30 07:46:07 cz vmunix: [8.565073] random: avahi-daemon: uninitialized urandom read (4 bytes read) Sep 30 07:46:21 cz vmunix: [ 23.092795] random: crng init done Sep 30 07:46:21 cz vmunix: [ 23.096419] random: 3 urandom warning(s) missed due to ratelimiting <--- that's after and we're 15 secs faster: Sep 30 07:47:53 cz vmunix: [0.329599] random: get_random_bytes called from start_kernel+0x304/0x4ac with crng_init=0 Sep 30 07:47:53 cz vmunix: [1.949216] random: fast init done Sep 30 07:47:53 cz vmunix: [4.806132] random: dd: uninitialized urandom read (512 bytes read) Sep 30 07:47:53 cz vmunix: [5.954547] random: dbus-daemon: uninitialized urandom read (12 bytes read) Sep 30 07:47:53 cz vmunix: [5.965483] random: dbus-daemon: uninitialized urandom read (12 bytes read) Sep 30 07:47:53 cz vmunix: [6.014102] random: avahi-daemon: uninitialized urandom read (4 bytes read) Sep 30 07:47:55 cz vmunix: [8.238514] random: crng init done Sep 30 07:47:55 cz vmunix: [8.240205] random: 3 urandom warning(s) missed due to ratelimiting Seeing how those uninitialized urandom read warns still happen, I added a dump_stack() to see when we do wait for the random bytes first and I got this: [5.522348] random: dbus-daemon: uninitialized urandom read (12 bytes read) [5.532008] random: dbus-daemon: uninitialized urandom read (12 bytes read) [5.579922] random: avahi-daemon: uninitialized urandom read (4 bytes read) [5.751790] elogind-daemon[1730]: New seat seat0. [5.756376] elogind-daemon[1730]: Watching system buttons on /dev/input/event6 (Power Button) [5.777381] elogind-daemon[1730]: Watching system buttons on /dev/input/event3 (Power Button) [5.781485] elogind-daemon[1730]: Watching system buttons on /dev/input/event5 (Lid Switch) [5.783547] elogind-daemon[1730]: Watching system buttons on /dev/input/event4 (Sleep Button) [5.885300] elogind-daemon[1730]: Watching system buttons on /dev/input/event0 (AT Translated Set 2 keyboard) [5.911602] CPU: 2 PID: 1798 Comm: sshd Not tainted 5.3.0+ #1 [5.914672] Hardware name: HP HP EliteBook 745 G3/807E, BIOS N73 Ver. 01.39 04/16/2019 [5.917774] Call Trace: [5.920905] dump_stack+0x46/0x60 [5.924044] wait_for_random_bytes.part.32+0x21/0x163 [5.927256] ? handle_mm_fault+0x50/0xc0 [5.930425] ? _raw_spin_unlock_irq+0x17/0x40 [5.933604] ? __do_page_fault+0x225/0x500 [5.936763] __x64_sys_getrandom+0x70/0xb0 [5.939902] do_syscall_64+0x4c/0x180 [5.943003] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [5.946152] RIP: 0033:0x7f4417f4d495 [5.949225] Code: 74 4c 8d 0c 37 41 ba 3e 01 00 00 66 2e 0f 1f 84 00 00 00 00 00 4d 39 c8 73 27 4c 89 ce 31 d2 4c 89 c7 44 89 d0 4c 29 c6 0f 05 <48> 3d 00 f0 ff ff 77 2b 48 85 c0 78 0e 74 3c 49 01 c0 4d 39 c8 72 [5.952902] RSP: 002b:7ffc69e6e328 EFLAGS: 0202 ORIG_RAX: 013e [5.956227] RAX: ffda RBX: 0020 RCX: 7f4417f4d495 [5.959530] RDX: RSI: 0020 RDI: 559262c74780 [5.962820] RBP: 559262c708b0 R08: 559262c74780 R09: 559262c747a0 [5.966104] R10: 013e R11: 0202 R12: 7ffc69e6e470 [5.969373] R13: 0002 R14: 7f4417f4d460 R15: 7fff [7.852837] random: crng init done [7.854637] random: 3 urandom warning(s) missed due to ratelimiting [ 17.767786] elogind-daemon[1730]: New session c1 of user root. so sshd does getrandom(2) while those other userspace things don't. Oh well. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] compiler: enable CONFIG_OPTIMIZE_INLINING forcibly
Hi.
On Fri, Sep 27, 2019 at 7:58 PM Nicolas Saenz Julienne
wrote:
>
> On Fri, 2019-08-30 at 12:43 +0900, Masahiro Yamada wrote:
> > Commit 9012d011660e ("compiler: allow all arches to enable
> > CONFIG_OPTIMIZE_INLINING") allowed all architectures to enable
> > this option. A couple of build errors were reported by randconfig,
> > but all of them have been ironed out.
> >
> > Towards the goal of removing CONFIG_OPTIMIZE_INLINING entirely
> > (and it will simplify the 'inline' macro in compiler_types.h),
> > this commit changes it to always-on option. Going forward, the
> > compiler will always be allowed to not inline functions marked
> > 'inline'.
> >
> > This is not a problem for x86 since it has been long used by
> > arch/x86/configs/{x86_64,i386}_defconfig.
> >
> > I am keeping the config option just in case any problem crops up for
> > other architectures.
> >
> > The code clean-up will be done after confirming this is solid.
> >
> > Signed-off-by: Masahiro Yamada
>
> [ Resending as the mail delivery system failed to resolve some the hosts,
> namely Masahiro's ]
>
> [ Adding some ARM people as they might be able to help ]
>
> This was found to cause a regression on a Raspberry Pi 2 B built with
> bcm2835_defconfig which among other things has no SMP support.
>
> The relevant logs (edited to remove the noise) are:
>
> [5.827333] Run /init as init process
> Loading, please wait...
> Failed to set SO_PASSCRED: Bad address
> Failed to bind netlink socket: Bad address
> Failed to create manager: Bad address
> Failed to set SO_PASSCRED: Bad address
> [9.021623] systemd[1]: SO_PASSCRED failed: Bad address
> [!!] Failed to start up manager.
> [9.079148] systemd[1]: Freezing execution.
>
> I looked into it, it turns out that the call to get_user() in
> sock_setsockopt()
> is returning -EFAULT. Down the assembly rabbit hole that get_user() is I
> found-out that it's the macro 'check_uaccess' who's triggering the error.
>
> I'm clueless at this point, so I hope you can give me some hints on what's
> going bad here.
>
> Regards,
> Nicolas
>
>
I posted a fix:
https://lore.kernel.org/patchwork/patch/1132459/
Thanks.
--
Best Regards
Masahiro Yamada
Re: [PATCH] fs: affs: fix a memory leak in affs_remount
* Please avoid typos in the commit message. * I would prefer an other wording for the change description. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?id=97f9a3c4eee55b0178b518ae7114a6a53372913d#n151 > But this is not actually used later! Can this information trigger the deletion of questionable source code instead of adding a missing function call “kfree(new_opts)”? How do you think about to add the tag “Fixes”? Regards, Markus
[PATCH] ARM: fix __get_user_check() in case uaccess_* calls are not inlined
KernelCI reports that bcm2835_defconfig is no longer booting since
commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
forcibly"):
https://lkml.org/lkml/2019/9/26/825
I also received a regression report from Nicolas Saenz Julienne:
https://lkml.org/lkml/2019/9/27/263
This problem has cropped up on arch/arm/config/bcm2835_defconfig
because it enables CONFIG_CC_OPTIMIZE_FOR_SIZE. The compiler tends
to prefer not inlining functions with -Os. I was able to reproduce
it with other boards and defconfig files by manually enabling
CONFIG_CC_OPTIMIZE_FOR_SIZE.
The __get_user_check() specifically uses r0, r1, r2 registers.
So, uaccess_save_and_enable() and uaccess_restore() must be inlined
in order to avoid those registers being overwritten in the callees.
Prior to commit 9012d011660e ("compiler: allow all arches to enable
CONFIG_OPTIMIZE_INLINING"), the 'inline' marker was always enough for
inlining functions, except on x86.
Since that commit, all architectures can enable CONFIG_OPTIMIZE_INLINING.
So, __always_inline is now the only guaranteed way of forcible inlining.
I want to keep as much compiler's freedom as possible about the inlining
decision. So, I changed the function call order instead of adding
__always_inline around.
Call uaccess_save_and_enable() before assigning the __p ("r0"), and
uaccess_restore() after evacuating the __e ("r0").
Fixes: 9012d011660e ("compiler: allow all arches to enable
CONFIG_OPTIMIZE_INLINING")
Reported-by: "kernelci.org bot"
Reported-by: Nicolas Saenz Julienne
Signed-off-by: Masahiro Yamada
---
arch/arm/include/asm/uaccess.h | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/uaccess.h b/arch/arm/include/asm/uaccess.h
index 303248e5b990..559f252d7e3c 100644
--- a/arch/arm/include/asm/uaccess.h
+++ b/arch/arm/include/asm/uaccess.h
@@ -191,11 +191,12 @@ extern int __get_user_64t_4(void *);
#define __get_user_check(x, p) \
({ \
unsigned long __limit = current_thread_info()->addr_limit - 1; \
+ unsigned int __ua_flags = uaccess_save_and_enable();\
register typeof(*(p)) __user *__p asm("r0") = (p); \
register __inttype(x) __r2 asm("r2"); \
register unsigned long __l asm("r1") = __limit; \
register int __e asm("r0"); \
- unsigned int __ua_flags = uaccess_save_and_enable();\
+ unsigned int __err; \
switch (sizeof(*(__p))) { \
case 1: \
if (sizeof((x)) >= 8) \
@@ -223,9 +224,10 @@ extern int __get_user_64t_4(void *);
break; \
default: __e = __get_user_bad(); break; \
} \
- uaccess_restore(__ua_flags);\
+ __err = __e;\
x = (typeof(*(p))) __r2;\
- __e;\
+ uaccess_restore(__ua_flags);\
+ __err; \
})
#define get_user(x, p) \
--
2.17.1
Re: [PATCH v5 1/1] memory_hotplug: Add a bounds check to __add_pages
On Mon, 2019-09-30 at 12:21 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> On PowerPC, the address ranges allocated to OpenCAPI LPC memory
> are allocated from firmware. These address ranges may be higher
> than what older kernels permit, as we increased the maximum
> permissable address in commit 4ffe713b7587
> ("powerpc/mm: Increase the max addressable memory to 2PB"). It is
> possible that the addressable range may change again in the
> future.
>
> In this scenario, we end up with a bogus section returned from
> __section_nr (see the discussion on the thread "mm: Trigger bug on
> if a section is not found in __section_nr").
>
> Adding a check here means that we fail early and have an
> opportunity to handle the error gracefully, rather than rumbling
> on and potentially accessing an incorrect section.
>
> Further discussion is also on the thread ("powerpc: Perform a bounds
> check in arch_add_memory")
> http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com
>
> Signed-off-by: Alastair D'Silva
> ---
> mm/memory_hotplug.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index c73f09913165..1909607da640 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -278,6 +278,22 @@ static int check_pfn_span(unsigned long pfn,
> unsigned long nr_pages,
> return 0;
> }
>
> +static int check_hotplug_memory_addressable(unsigned long pfn,
> + unsigned long nr_pages)
> +{
> + const u64 max_addr = PFN_PHYS(pfn + nr_pages) - 1;
> +
> + if (max_addr >> MAX_PHYSMEM_BITS) {
> + const u64 max_allowed = (1ull << (MAX_PHYSMEM_BITS +
> 1)) - 1;
> + WARN(1,
> + "Hotplugged memory exceeds maximum addressable
> address, range=%#lx-%#lx, maximum=%#lx\n",
Gah, these should all be %#llx.
> + PFN_PHYS(pfn), max_addr, max_allowed);
> + return -E2BIG;
> + }
> +
> + return 0;
> +}
> +
> /*
> * Reasonably generic function for adding memory. It is
> * expected that archs that support memory hotplug will
> @@ -291,6 +307,10 @@ int __ref __add_pages(int nid, unsigned long
> pfn, unsigned long nr_pages,
> unsigned long nr, start_sec, end_sec;
> struct vmem_altmap *altmap = restrictions->altmap;
>
> + err = check_hotplug_memory_addressable(pfn, nr_pages);
> + if (err)
> + return err;
> +
> if (altmap) {
> /*
>* Validate altmap is within bounds of the total
> request
[PATCH] ARM: module: remove 'always false' statement
The each field of 'struct elf32_rel' is declared as below.
typedef struct elf32_rel {
Elf32_Addr r_offset;
Elf32_Word r_info;
} Elf32_Rel;
typedef __u32 Elf32_Addr;
typedef __u32 Elf32_Word;
This means that 'r_offset' and 'r_info' could contain non-negative value.
So 'always false' statement can be dropped.
Signed-off-by: Austin Kim
---
arch/arm/kernel/module.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/module.c b/arch/arm/kernel/module.c
index deef17f..617de32 100644
--- a/arch/arm/kernel/module.c
+++ b/arch/arm/kernel/module.c
@@ -83,7 +83,7 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab,
unsigned int symindex,
#endif
offset = ELF32_R_SYM(rel->r_info);
- if (offset < 0 || offset > (symsec->sh_size /
sizeof(Elf32_Sym))) {
+ if (offset > (symsec->sh_size / sizeof(Elf32_Sym))) {
pr_err("%s: section %u reloc %u: bad relocation sym
offset\n",
module->name, relindex, i);
return -ENOEXEC;
@@ -92,8 +92,8 @@ apply_relocate(Elf32_Shdr *sechdrs, const char *strtab,
unsigned int symindex,
sym = ((Elf32_Sym *)symsec->sh_addr) + offset;
symname = strtab + sym->st_name;
- if (rel->r_offset < 0 || rel->r_offset > dstsec->sh_size -
sizeof(u32)) {
- pr_err("%s: section %u reloc %u sym '%s': out of bounds
relocation, offset %d size %u\n",
+ if (rel->r_offset > dstsec->sh_size - sizeof(u32)) {
+ pr_err("%s: section %u reloc %u sym '%s': out of bounds
relocation, offset %u size %u\n",
module->name, relindex, i, symname,
rel->r_offset, dstsec->sh_size);
return -ENOEXEC;
--
2.6.2
Re: [PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings
On Mon, Sep 30, 2019 at 8:35 AM Borislav Petkov wrote: > > On Tue, Sep 24, 2019 at 07:46:59AM +0300, Alexander Kapshuk wrote: > > gawk 5.0.1 generates the regexp warnings shown below: > > GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c > > awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape > > sequence `\:' is not a known regexp operator > > awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350: > > (FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape > > sequence `\&' is not a known regexp operator > > > > Ealier versions of gawk are not known to generate these warnings. > > > > The gawk manual referenced below does not list characters ':' and '&' > > as needing escaping, so 'unescape' them. > > https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html > > > > Running diff on the output generated by the script before and after > > applying the patch reported no differences. > > > > Signed-off-by: Alexander Kapshuk > > Reported-by: kbuild test robot > > Reviewed-by: Borislav Petkov > > This is not how Reviewed-by works. Read here: > > https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes > > for future reference. I fixed it up now. > > Thx. > > -- > Regards/Gruss, > Boris. > > https://people.kernel.org/tglx/notes-about-netiquette Thank you for taking in the patch and clarifying my misunderstanding about the use of 'Reviewed-by'. Point taken.
Re: [PATCH v6] perf: Sharing PMU counters across compatible events
Hi Peter, > On Sep 18, 2019, at 10:23 PM, Song Liu wrote: > > This patch tries to enable PMU sharing. To make perf event scheduling > fast, we use special data structures. > > An array of "struct perf_event_dup" is added to the perf_event_context, > to remember all the duplicated events under this ctx. All the events > under this ctx has a "dup_id" pointing to its perf_event_dup. Compatible > events under the same ctx share the same perf_event_dup. The following > figure shows a simplified version of the data structure. > > ctx -> perf_event_dup -> master > ^ > | > perf_event /| > | > perf_event / > > Connection among perf_event and perf_event_dup are built when events are > added or removed from the ctx. So these are not on the critical path of > schedule or perf_rotate_context(). > > On the critical paths (add, del read), sharing PMU counters doesn't > increase the complexity. Helper functions event_pmu_[add|del|read]() are > introduced to cover these cases. All these functions have O(1) time > complexity. > > We allocate a separate perf_event for perf_event_dup->master. This needs > extra attention, because perf_event_alloc() may sleep. To allocate the > master event properly, a new pointer, tmp_master, is added to perf_event. > tmp_master carries a separate perf_event into list_[add|del]_event(). > The master event has valid ->ctx and holds ctx->refcount. > > Details about the handling of the master event is added to > include/linux/perf_event.h, before struct perf_event_dup. Could you please share your comments/suggestions on this work? Thanks, Song
Re: [PATCH] arm64: tegra: only map accessible sysram
On 9/29/19 2:08 PM, Mian Yousaf Kaukab wrote: > Most of the SysRAM is secure and only accessible by TF-A. > Don't map this inaccessible memory in kernel. Only map pages > used by bpmp driver. I don't believe this change is correct. The actual patch doesn't implement mapping a subset of the RAM (a software issue), but rather it changes the DT representation of the SYSRAM hardware. The SYSRAM hardware always does start at 0x3000, even if a subset of the address range is dedicated to a specific purpose. If the kernel must map only part of the RAM, then some additional property should indicate this. Also, I believe it's incorrect to hard-code into the kernel's DT the range of addresses used by the secure monitor/OS, since this can vary depending on what the user actually chooses to install as the secure monitor/OS. Any indication of such regions should be filled in at runtime by some boot firmware or the secure monitor/OS itself, or retrieved using some runtime API rather than DT.
Re: [PATCH RESEND] gen-insn-attr-x86.awk: Fix regexp warnings
On Tue, Sep 24, 2019 at 07:46:59AM +0300, Alexander Kapshuk wrote: > gawk 5.0.1 generates the regexp warnings shown below: > GEN /home/sasha/torvalds/tools/objtool/arch/x86/lib/inat-tables.c > awk: ../arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape > sequence `\:' is not a known regexp operator > awk: ../arch/x86/tools/gen-insn-attr-x86.awk:350: > (FILENAME=../arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape > sequence `\&' is not a known regexp operator > > Ealier versions of gawk are not known to generate these warnings. > > The gawk manual referenced below does not list characters ':' and '&' > as needing escaping, so 'unescape' them. > https://www.gnu.org/software/gawk/manual/html_node/Escape-Sequences.html > > Running diff on the output generated by the script before and after > applying the patch reported no differences. > > Signed-off-by: Alexander Kapshuk > Reported-by: kbuild test robot > Reviewed-by: Borislav Petkov This is not how Reviewed-by works. Read here: https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes for future reference. I fixed it up now. Thx. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette
Re: [PATCH] perf: rework memory accounting in perf_mmap()
> On Sep 16, 2019, at 1:10 PM, Hechao Li wrote: > > Song Liu wrote on Mon [2019-Sep-16 12:43:16 -0700]: >> Hi Peter, >> >>> On Sep 4, 2019, at 2:46 PM, Song Liu wrote: >>> >>> perf_mmap() always increases user->locked_vm. As a result, "extra" could >>> grow bigger than "user_extra", which doesn't make sense. Here is an >>> example case: >>> >>> Note: Assume "user_lock_limit" is very small. >>> | # of perf_mmap calls |vma->vm_mm->pinned_vm|user->locked_vm| >>> | 0| 0 | 0 | >>> | 1| user_extra | user_extra| >>> | 2| 3 * user_extra | 2 * user_extra| >>> | 3| 6 * user_extra | 3 * user_extra| >>> | 4| 10 * user_extra | 4 * user_extra| >>> >>> Fix this by maintaining proper user_extra and extra. >>> >>> Reported-by: Hechao Li >>> Cc: Jie Meng >>> Cc: Peter Zijlstra >>> Signed-off-by: Song Liu >> >> Could you please share your feedbacks/comments on this one? >> >> Thanks, >> Song > > The change looks good to me. Thanks, Song. > > Reviewed-By: Hechao Li Thanks Hechao! Hi Peter, Does this fix look good to you? Thanks, Song
[PATCH] iio: adc: Variables could be uninitalized if regmap_read() fails
Several functions in this file are trying to use regmap_read() to
initialize the specific variable, however, if regmap_read() fails,
the variable could be uninitialized but used directly, which is
potentially unsafe. The return value of regmap_read() should be
checked and handled.
Signed-off-by: Yizhuo
---
drivers/iio/adc/bcm_iproc_adc.c | 45 -
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/drivers/iio/adc/bcm_iproc_adc.c b/drivers/iio/adc/bcm_iproc_adc.c
index 646ebdc0a8b4..6df19ceb5ff2 100644
--- a/drivers/iio/adc/bcm_iproc_adc.c
+++ b/drivers/iio/adc/bcm_iproc_adc.c
@@ -137,6 +137,7 @@ static irqreturn_t iproc_adc_interrupt_thread(int irq, void
*data)
u32 channel_intr_status;
u32 intr_status;
u32 intr_mask;
+ int ret;
struct iio_dev *indio_dev = data;
struct iproc_adc_priv *adc_priv = iio_priv(indio_dev);
@@ -145,8 +146,19 @@ static irqreturn_t iproc_adc_interrupt_thread(int irq,
void *data)
* Make sure this interrupt is intended for us.
* Handle only ADC channel specific interrupts.
*/
- regmap_read(adc_priv->regmap, IPROC_INTERRUPT_STATUS, &intr_status);
- regmap_read(adc_priv->regmap, IPROC_INTERRUPT_MASK, &intr_mask);
+ ret = regmap_read(adc_priv->regmap,
+ IPROC_INTERRUPT_STATUS, &intr_status);
+ if (ret) {
+ dev_err(&indio_dev->dev, "Fail to read
IPROC_INTERRUPT_STATUS.\n");
+ return ret;
+ }
+
+ ret = regmap_read(adc_priv->regmap, IPROC_INTERRUPT_MASK, &intr_mask);
+ if (ret) {
+ dev_err(&indio_dev->dev, "Fail to read
IPROC_INTERRUPT_MASK.\n");
+ return ret;
+ }
+
intr_status = intr_status & intr_mask;
channel_intr_status = (intr_status & IPROC_ADC_INTR_MASK) >>
IPROC_ADC_INTR;
@@ -162,6 +174,7 @@ static irqreturn_t iproc_adc_interrupt_handler(int irq,
void *data)
struct iproc_adc_priv *adc_priv;
struct iio_dev *indio_dev = data;
unsigned int valid_entries;
+ int ret;
u32 intr_status;
u32 intr_channels;
u32 channel_status;
@@ -169,23 +182,37 @@ static irqreturn_t iproc_adc_interrupt_handler(int irq,
void *data)
adc_priv = iio_priv(indio_dev);
- regmap_read(adc_priv->regmap, IPROC_INTERRUPT_STATUS, &intr_status);
+ ret = regmap_read(adc_priv->regmap,
+ IPROC_INTERRUPT_STATUS, &intr_status);
+ if (ret) {
+ dev_err(&indio_dev->dev, "Fail to read
IPROC_INTERRUPT_STATUS.\n");
+ return ret;
+ }
+
dev_dbg(&indio_dev->dev,
"iproc_adc_interrupt_handler(),INTRPT_STS:%x\n",
intr_status);
intr_channels = (intr_status & IPROC_ADC_INTR_MASK) >> IPROC_ADC_INTR;
if (intr_channels) {
- regmap_read(adc_priv->regmap,
+ ret = regmap_read(adc_priv->regmap,
IPROC_ADC_CHANNEL_INTERRUPT_STATUS +
IPROC_ADC_CHANNEL_OFFSET * adc_priv->chan_id,
&ch_intr_status);
+ if (ret) {
+ dev_err(&indio_dev->dev, "Fail to read the
register.\n");
+ return ret;
+ }
if (ch_intr_status & IPROC_ADC_CHANNEL_WTRMRK_INTR_MASK) {
- regmap_read(adc_priv->regmap,
+ ret = regmap_read(adc_priv->regmap,
IPROC_ADC_CHANNEL_STATUS +
IPROC_ADC_CHANNEL_OFFSET *
adc_priv->chan_id,
&channel_status);
+ if (ret) {
+ dev_err(&indio_dev->dev, "Fail to read the
register.\n");
+ return ret;
+ }
valid_entries = ((channel_status &
IPROC_ADC_CHANNEL_VALID_ENTERIES_MASK) >>
@@ -230,6 +257,7 @@ static int iproc_adc_do_read(struct iio_dev *indio_dev,
u32 mask;
u32 val_check;
int failed_cnt = 0;
+ int ret;
struct iproc_adc_priv *adc_priv = iio_priv(indio_dev);
mutex_lock(&adc_priv->mutex);
@@ -284,7 +312,12 @@ static int iproc_adc_do_read(struct iio_dev *indio_dev,
* Testing has shown that this may loop a few time, but we have never
* hit the full count.
*/
- regmap_read(adc_priv->regmap, IPROC_INTERRUPT_MASK, &val_check);
+ ret = regmap_read(adc_priv->regmap, IPROC_INTERRUPT_MASK, &val_check);
+ if (ret) {
+ dev_err(&indio_dev->dev, "Fail to read
IPROC_INTERRUPT_MASK.\n");
+ return ret;
+ }
+
while (val_check != val) {
failed_cnt++;
--
Re: [PATCH v4] arm64: use generic free_initrd_mem()
On 09/28/2019 01:32 PM, Mike Rapoport wrote:
> From: Mike Rapoport
>
> arm64 calls memblock_free() for the initrd area in its implementation of
> free_initrd_mem(), but this call has no actual effect that late in the boot
> process. By the time initrd is freed, all the reserved memory is managed by
> the page allocator and the memblock.reserved is unused, so the only purpose
> of the memblock_free() call is to keep track of initrd memory for debugging
> and accounting.
Thats correct. memblock_free_all() gets called before free_initrd_mem().
>
> Without the memblock_free() call the only difference between arm64 and the
> generic versions of free_initrd_mem() is the memory poisoning.
>
> Move memblock_free() call to the generic code, enable it there
> for the architectures that define ARCH_KEEP_MEMBLOCK and use the generic
> implementation of free_initrd_mem() on arm64.
This improves free_initrd_mem() generic implementation for others to use.
>
> Signed-off-by: Mike Rapoport
Tested-by: Anshuman Khandual #arm64
Reviewed-by: Anshuman Khandual
> ---
>
> v4:
> * memblock_free() aligned area around the initrd
>
> v3:
> * fix powerpc build
>
> v2:
> * add memblock_free() to the generic free_initrd_mem()
> * rebase on the current upstream
>
>
> arch/arm64/mm/init.c | 12
> init/initramfs.c | 8
> 2 files changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 45c00a5..87a0e3b 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -580,18 +580,6 @@ void free_initmem(void)
> unmap_kernel_range((u64)__init_begin, (u64)(__init_end - __init_begin));
> }
>
> -#ifdef CONFIG_BLK_DEV_INITRD
> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> -{
> - unsigned long aligned_start, aligned_end;
> -
> - aligned_start = __virt_to_phys(start) & PAGE_MASK;
> - aligned_end = PAGE_ALIGN(__virt_to_phys(end));
> - memblock_free(aligned_start, aligned_end - aligned_start);
> - free_reserved_area((void *)start, (void *)end, 0, "initrd");
> -}
> -#endif
> -
> /*
> * Dump out memory limit information on panic.
> */
> diff --git a/init/initramfs.c b/init/initramfs.c
> index c47dad0..8ec1be4 100644
> --- a/init/initramfs.c
> +++ b/init/initramfs.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
>
> static ssize_t __init xwrite(int fd, const char *p, size_t count)
> {
> @@ -529,6 +530,13 @@ extern unsigned long __initramfs_size;
>
> void __weak free_initrd_mem(unsigned long start, unsigned long end)
> {
> +#ifdef CONFIG_ARCH_KEEP_MEMBLOCK
> + unsigned long aligned_start = ALIGN_DOWN(start, PAGE_SIZE);
> + unsigned long aligned_end = ALIGN(end, PAGE_SIZE);
> +
> + memblock_free(__pa(aligned_start), aligned_end - aligned_start);
> +#endif
> +
> free_reserved_area((void *)start, (void *)end, POISON_FREE_INITMEM,
> "initrd");
> }
>
[PATCH] AF_PACKET doesnt strip VLAN information
When an application sends with AF_PACKET and places a vlan header on
the raw packet; then the AF_PACKET needs to move the tag into the skb
so that it gets processed normally through the rest of the transmit
path.
This is particularly a problem on Hyper-V where the host only allows
vlan in the offload info.
Cc: xe-linux-exter...@cisco.com
---
net/packet/af_packet.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index e2742b0..cfe0904 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -1849,15 +1849,35 @@ static int packet_rcv_spkt(struct sk_buff *skb, struct
net_device *dev,
return 0;
}
-static void packet_parse_headers(struct sk_buff *skb, struct socket *sock)
+static int packet_parse_headers(struct sk_buff *skb, struct socket *sock)
{
if ((!skb->protocol || skb->protocol == htons(ETH_P_ALL)) &&
sock->type == SOCK_RAW) {
+ __be16 ethertype;
+
skb_reset_mac_header(skb);
+
+ ethertype = eth_hdr(skb)->h_proto;
+ /*
+* If Vlan tag is present in the packet
+* move it to skb
+ */
+ if (eth_type_vlan(ethertype)) {
+ int err;
+ __be16 vlan_tci;
+
+ err = __skb_vlan_pop(skb, &vlan_tci);
+ if (unlikely(err))
+ return err;
+
+ __vlan_hwaccel_put_tag(skb, ethertype, vlan_tci);
+ }
+
skb->protocol = dev_parse_header_protocol(skb);
}
skb_probe_transport_header(skb);
+ return 0;
}
/*
@@ -1979,7 +1999,9 @@ static int packet_sendmsg_spkt(struct socket *sock,
struct msghdr *msg,
if (unlikely(extra_len == 4))
skb->no_fcs = 1;
- packet_parse_headers(skb, sock);
+ err = packet_parse_headers(skb, sock);
+ if (err)
+ goto out_unlock;
dev_queue_xmit(skb);
rcu_read_unlock();
--
2.7.4
Re: [EXT] Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device
On 2019-09-30 04:43, Biwen Li wrote: >> >> On 2019-09-29 12:36, Biwen Li wrote: >>> On some Layerscape boards like LS2085ARDB and LS2088ARDB, input >>> pull-up resistors on PCA954x MUX device are missing on board, So, if >>> MUX are disabled after powered-on, input lines will float leading to >>> incorrect functionality. SDA and SCL are not "inputs". They are part of a bus and are both bidirectional signals. Speaking of input signals in an I2C context is ambiguous. >> >> Hi! >> >> Are you saying that the parent bus of the mux is relying on some pull-ups >> inside >> the mux? > Yes, as follows: > > VCC > > --- > > |--- > || > > \\ > > /10K resister / 10k resister > > \\ > > || > || >I2C1_SCL I2C1_SCL > | -- > |SCL | > |SCL | >I2C1_SDA | PCA9547 |I2C1_SDA | | > PCA9547 | > |SDA | > |---|SDA | > >-- > --wrong design(need software fix as above or hardware fix)-- > --proper design-- Ok, got it (but the "picture" didn't help). >> >>> Hence, PCA954x MUX device should never be turned-off after power-on. >>> >>> Add property to skip disabling PCA954x MUX device if device tree >>> contains "i2c-mux-never-disable" >>> for PCA954x device node. >>> >>> Errata ID: E-00013 on board LS2085ARDB and LS2088ARDB (Board revision >>> found on Rev.B, Rev.C and Rev.D) >> >> I think you should follow the example of the i2c-mux-gpio driver and >> implement >> the idle-state property instead. >> >> That is a lot more consistent, assuming it solves the problem at hand? > Got it, thanks, I will try it. I'll wait for that patch then, instead of spending more energy on the never-disable approach. Cheers, Peter
[PATCH] PCI: Add Loongson vendor ID and device IDs
Add the Loongson vendor ID and device IDs to pci_ids.h to be used in the future. The Loongson IDs can be found at the following link: https://git.kernel.org/pub/scm/utils/pciutils/pciutils.git/tree/pci.ids Co-developed-by: Lu Zeng Signed-off-by: Lu Zeng Signed-off-by: Tiezhu Yang --- include/linux/pci_ids.h | 19 +++ 1 file changed, 19 insertions(+) diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h index 21a5724..119639d 100644 --- a/include/linux/pci_ids.h +++ b/include/linux/pci_ids.h @@ -3111,4 +3111,23 @@ #define PCI_VENDOR_ID_NCUBE0x10ff +#define PCI_VENDOR_ID_LOONGSON 0x0014 +#define PCI_DEVICE_ID_LOONGSON_HT 0x7a00 +#define PCI_DEVICE_ID_LOONGSON_APB 0x7a02 +#define PCI_DEVICE_ID_LOONGSON_GMAC0x7a03 +#define PCI_DEVICE_ID_LOONGSON_OTG 0x7a04 +#define PCI_DEVICE_ID_LOONGSON_GPU_2K1000 0x7a05 +#define PCI_DEVICE_ID_LOONGSON_DC 0x7a06 +#define PCI_DEVICE_ID_LOONGSON_HDA 0x7a07 +#define PCI_DEVICE_ID_LOONGSON_SATA0x7a08 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X1 0x7a09 +#define PCI_DEVICE_ID_LOONGSON_SPI 0x7a0b +#define PCI_DEVICE_ID_LOONGSON_LPC 0x7a0c +#define PCI_DEVICE_ID_LOONGSON_DMA 0x7a0f +#define PCI_DEVICE_ID_LOONGSON_EHCI0x7a14 +#define PCI_DEVICE_ID_LOONGSON_GPU_7A1000 0x7a15 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X4 0x7a19 +#define PCI_DEVICE_ID_LOONGSON_OHCI0x7a24 +#define PCI_DEVICE_ID_LOONGSON_PCIE_X8 0x7a29 + #endif /* _LINUX_PCI_IDS_H */ -- 2.1.0
Re: [PATCH] kasan: fix the missing underflow in memmove and memcpy with CONFIG_KASAN_GENERIC=y
On Fri, 2019-09-27 at 21:41 +0200, Dmitry Vyukov wrote:
> On Fri, Sep 27, 2019 at 4:22 PM Walter Wu wrote:
> >
> > On Fri, 2019-09-27 at 15:07 +0200, Dmitry Vyukov wrote:
> > > On Fri, Sep 27, 2019 at 5:43 AM Walter Wu
> > > wrote:
> > > >
> > > > memmove() and memcpy() have missing underflow issues.
> > > > When -7 <= size < 0, then KASAN will miss to catch the underflow issue.
> > > > It looks like shadow start address and shadow end address is the same,
> > > > so it does not actually check anything.
> > > >
> > > > The following test is indeed not caught by KASAN:
> > > >
> > > > char *p = kmalloc(64, GFP_KERNEL);
> > > > memset((char *)p, 0, 64);
> > > > memmove((char *)p, (char *)p + 4, -2);
> > > > kfree((char*)p);
> > > >
> > > > It should be checked here:
> > > >
> > > > void *memmove(void *dest, const void *src, size_t len)
> > > > {
> > > > check_memory_region((unsigned long)src, len, false, _RET_IP_);
> > > > check_memory_region((unsigned long)dest, len, true, _RET_IP_);
> > > >
> > > > return __memmove(dest, src, len);
> > > > }
> > > >
> > > > We fix the shadow end address which is calculated, then generic KASAN
> > > > get the right shadow end address and detect this underflow issue.
> > > >
> > > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=199341
> > > >
> > > > Signed-off-by: Walter Wu
> > > > Reported-by: Dmitry Vyukov
> > > > ---
> > > > lib/test_kasan.c | 36
> > > > mm/kasan/generic.c | 8 ++--
> > > > 2 files changed, 42 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/lib/test_kasan.c b/lib/test_kasan.c
> > > > index b63b367a94e8..8bd014852556 100644
> > > > --- a/lib/test_kasan.c
> > > > +++ b/lib/test_kasan.c
> > > > @@ -280,6 +280,40 @@ static noinline void __init
> > > > kmalloc_oob_in_memset(void)
> > > > kfree(ptr);
> > > > }
> > > >
> > > > +static noinline void __init kmalloc_oob_in_memmove_underflow(void)
> > > > +{
> > > > + char *ptr;
> > > > + size_t size = 64;
> > > > +
> > > > + pr_info("underflow out-of-bounds in memmove\n");
> > > > + ptr = kmalloc(size, GFP_KERNEL);
> > > > + if (!ptr) {
> > > > + pr_err("Allocation failed\n");
> > > > + return;
> > > > + }
> > > > +
> > > > + memset((char *)ptr, 0, 64);
> > > > + memmove((char *)ptr, (char *)ptr + 4, -2);
> > > > + kfree(ptr);
> > > > +}
> > > > +
> > > > +static noinline void __init kmalloc_oob_in_memmove_overflow(void)
> > > > +{
> > > > + char *ptr;
> > > > + size_t size = 64;
> > > > +
> > > > + pr_info("overflow out-of-bounds in memmove\n");
> > > > + ptr = kmalloc(size, GFP_KERNEL);
> > > > + if (!ptr) {
> > > > + pr_err("Allocation failed\n");
> > > > + return;
> > > > + }
> > > > +
> > > > + memset((char *)ptr, 0, 64);
> > > > + memmove((char *)ptr + size, (char *)ptr, 2);
> > > > + kfree(ptr);
> > > > +}
> > > > +
> > > > static noinline void __init kmalloc_uaf(void)
> > > > {
> > > > char *ptr;
> > > > @@ -734,6 +768,8 @@ static int __init kmalloc_tests_init(void)
> > > > kmalloc_oob_memset_4();
> > > > kmalloc_oob_memset_8();
> > > > kmalloc_oob_memset_16();
> > > > + kmalloc_oob_in_memmove_underflow();
> > > > + kmalloc_oob_in_memmove_overflow();
> > > > kmalloc_uaf();
> > > > kmalloc_uaf_memset();
> > > > kmalloc_uaf2();
> > > > diff --git a/mm/kasan/generic.c b/mm/kasan/generic.c
> > > > index 616f9dd82d12..34ca23d59e67 100644
> > > > --- a/mm/kasan/generic.c
> > > > +++ b/mm/kasan/generic.c
> > > > @@ -131,9 +131,13 @@ static __always_inline bool
> > > > memory_is_poisoned_n(unsigned long addr,
> > > > size_t size)
> > > > {
> > > > unsigned long ret;
> > > > + void *shadow_start = kasan_mem_to_shadow((void *)addr);
> > > > + void *shadow_end = kasan_mem_to_shadow((void *)addr + size - 1)
> > > > + 1;
> > > >
> > > > - ret = memory_is_nonzero(kasan_mem_to_shadow((void *)addr),
> > > > - kasan_mem_to_shadow((void *)addr + size - 1) +
> > > > 1);
> > > > + if ((long)size < 0)
> > > > + shadow_end = kasan_mem_to_shadow((void *)addr + size);
> > >
> > > Hi Walter,
> > >
> > > Thanks for working on this.
> > >
> > > If size<0, does it make sense to continue at all? We will still check
> > > 1PB of shadow memory? What happens when we pass such huge range to
> > > memory_is_nonzero?
> > > Perhaps it's better to produce an error and bail out immediately if
> > > size<0?
> >
> > I agree with what you said. when size<0, it is indeed an unreasonable
> > behavior, it should be blocked from continuing to do.
> >
> >
> > > Also, what's the failure mode of the tests? Didn't they badly corrupt
> > > memory? We tried to keep tests such that
RE: [PATCH] staging: exfat: add exfat filesystem code to
> [..] > > Put it in drivers/staging/sdfat/. > > > > But really we want someone from Samsung to say that they will treat > > the staging version as upstream. It doesn't work when people apply > > fixes to their version and a year later back port the fixes into > > staging. The staging tree is going to have tons and tons of white space > > fixes so backports are a pain. All development needs to be upstream > > first where the staging driver is upstream. Otherwise we should just > > wait for Samsung to get it read to be merged in fs/ and not through the > > staging tree. > Quite frankly, > This whole thing came as a huge-huge surprise to us, we did not initiate > upstreaming of exfat/sdfat code and, as of this moment, I'm not exactly > sure that we are prepared for any immediate radical changes to our internal > development process which people all of a sudden want from us. I need to > discuss with related people on internal thread. > please wait a while:) We decide to contribute sdfat directly and treat upstream exfat. Perhaps more time is needed for patch preparation(exfat rename + vfat removal + clean-up) and internal processes. After contributing sdfat v2.2.0 as the base, We will also provide change-set of sdfat v2.3.0 later. Thanks! > > Thanks! > > > > regards, > > dan carpenter > >
[PATCH] spi: lpspi: fix memory leak in fsl_lpspi_probe
In fsl_lpspi_probe an SPI controller is allocated either via
spi_alloc_slave or spi_alloc_master. In all but one error cases this
controller is put by going to error handling code. This commit fixes the
case when pm_runtime_get_sync fails and it should go to the error
handling path.
Fixes: 944c01a889d9 ("spi: lpspi: enable runtime pm for lpspi")
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-fsl-lpspi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/spi/spi-fsl-lpspi.c b/drivers/spi/spi-fsl-lpspi.c
index d08e9324140e..3528ed5eea9b 100644
--- a/drivers/spi/spi-fsl-lpspi.c
+++ b/drivers/spi/spi-fsl-lpspi.c
@@ -938,7 +938,7 @@ static int fsl_lpspi_probe(struct platform_device *pdev)
ret = pm_runtime_get_sync(fsl_lpspi->dev);
if (ret < 0) {
dev_err(fsl_lpspi->dev, "failed to enable clock\n");
- return ret;
+ goto out_controller_put;
}
temp = readl(fsl_lpspi->base + IMX7ULP_PARAM);
--
2.17.1
linux-next: Tree for Sep 30
Hi all, Changes since 20190926: The powerpc tree (well, Linus' tree really) gained a build failure for which I applied a patch. Non-merge commits (relative to Linus' tree): 462 574 files changed, 9710 insertions(+), 4176 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 310 trees (counting Linus' and 77 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (a3c0e7b1fe1f Merge tag 'libnvdimm-fixes-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm) Merging fixes/master (609488bc979f Linux 5.3-rc2) Merging kbuild-current/fixes (f97c81dc6ca5 Merge tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc) Merging arc-current/for-curr (089cf7f6ecb2 Linux 5.3-rc7) Merging arm-current/fixes (5b3efa4f1479 ARM: 8901/1: add a criteria for pfn_valid of arm) Merging arm-soc-fixes/arm/fixes (9bfd7319e8d3 Merge tag 'fixes-5.4-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes) Merging arm64-fixes/for-next/fixes (799c85105233 arm64: Fix reference to docs for ARM64_TAGGED_ADDR_ABI) Merging m68k-current/for-linus (0f1979b402df m68k: Remove ioremap_fullcache()) Merging powerpc-fixes/fixes (253c892193ab powerpc/eeh: Fix eeh eeh_debugfs_break_device() with SRIOV devices) Merging s390-fixes/fixes (d45331b00ddb Linux 5.3-rc4) Merging sparc/master (038029c03e21 sparc: remove unneeded uapi/asm/statfs.h) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (02dc96ef6c25 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging bpf/master (3c30819dc68a Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf) Merging ipsec/master (00b368502d18 xen-netfront: do not assume sk_buff_head list is empty in error handling) Merging netfilter/master (faeacb6ddb13 net: tap: clean up an indentation issue) Merging ipvs/master (58e8b37069ff Merge branch 'net-phy-dp83867-add-some-fixes') Merging wireless-drivers/master (2b481835cf4e wil6210: use after free in wil_netif_rx_any()) Merging mac80211/master (f794dc2304d8 sctp: fix the missing put_user when dumping transport thresholds) Merging rdma-fixes/for-rc (531a64e4c35b RDMA/siw: Fix IPv6 addr_list locking) Merging sound-current/for-linus (f41f900568d9 ALSA: usb-audio: Add DSD support for EVGA NU Audio) Merging sound-asoc-fixes/for-linus (84b66885fdcf Merge branch 'asoc-5.4' into asoc-linus) Merging regmap-fixes/for-linus (0161b8716465 Merge branch 'regmap-5.3' into regmap-linus) Merging regulator-fixes/for-linus (f9a60abc26d9 Merge branch 'regulator-5.4' into regulator-linus) Merging spi-fixes/for-linus (60b76d1c3b0a Merge branch 'spi-5.4' into spi-linus) Merging pci-current/for-linus (5184d449600f Merge tag 'microblaze-v5.4-rc1' of git://git.monstr.eu/linux-2.6-microblaze) Merging driver-core.current/driver-core-linus (02dc96ef6c25 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging tty.current/tty-linus (02dc96ef6c25 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging usb.current/usb-linus (02dc96ef6c25 Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net) Merging usb-gadget-fixes/fixes (4a56a478a525 usb: gadget: mass_storage: Fix races between fsg_disable and fsg_set_alt) Merging usb-serial-fixes/us
[PATCH] spi: gpio: prevent memroy leak in spi_gpio_probe
In spi_gpio_probe an SPI master is allocated via spi_alloc_master, but
this controller should be released if devm_add_action_or_reset fails,
otherwise memory leaks. This commit adds Fixes: spi_contriller_put in
case of failure for devm_add_action_or_reset.
Fixes: 8b797490b4db ("spi: gpio: Make sure spi_master_put() is called in every
error path")
Signed-off-by: Navid Emamdoost
---
drivers/spi/spi-gpio.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/spi/spi-gpio.c b/drivers/spi/spi-gpio.c
index 1d3e23ec20a6..f9c5bbb74714 100644
--- a/drivers/spi/spi-gpio.c
+++ b/drivers/spi/spi-gpio.c
@@ -371,8 +371,10 @@ static int spi_gpio_probe(struct platform_device *pdev)
return -ENOMEM;
status = devm_add_action_or_reset(&pdev->dev, spi_gpio_put, master);
- if (status)
+ if (status) {
+ spi_master_put(master);
return status;
+ }
if (of_id)
status = spi_gpio_probe_dt(pdev, master);
--
2.17.1
Re: x86/random: Speculation to the rescue
On Sun, Sep 29, 2019 at 06:16:33PM -0700, Linus Torvalds wrote: > > - or just say "hey, a lot of people find jitter entropy reasonable, > so let's just try this". > I'm OK with this as a starting point. If a jitter entropy system allow us to get pass this logjam, let's do it. At least for the x86 architecture, it will be security through obscurity. And if the alternative is potentially failing where the adversary can attack the CRNG, it's my preference. It's certainly better than nothing. That being said, I'd very much like to see someone do an analysis of how well these jitter schemes work on an RISC-V iplementation (you know, the ones that were so simplistic and didn't have any speculation so they weren't vulnerable to Specture/Meltdown). If jitter approaches turn out not to work that well on RISC-V, perhaps that will be a goad for future RISC-V chips to include the crypto extension to their ISA. In the long term (not in time for the 5.4 merge window), I'm convinced that we should be trying as many ways of getting entropy as possible. If we're using UEFI, we should be trying to get it from UEFI's secure random number generator; if there is a TPM, we should be trying to get random numbers from the RPM, and mix them in, and so on. After all, the reason why lived with getrandom(0) blocking for five years was because for the vast majority of x86 platforms, it simply wasn't problem in practice. We need to get back to that place where in practice, we've harvested as much uncertainty from hardware as possible, so most folks are comfortable that attacking the CRNG is no longer the simplest way to crack system security. - Ted
[v2,2/2] dt-bindings: i2c-mux-pca954x: Add optional property i2c-mux-never-disable
The patch adds an optional property i2c-mux-never-disable Signed-off-by: Biwen Li --- Change in v2: - update documentation Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt index 30ac6a60f041..71b73d0fdb62 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt @@ -34,6 +34,7 @@ Optional Properties: - first cell is the pin number - second cell is used to specify flags. See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt + - i2c-mux-never-disable: always forces mux to be enabled. Example: -- 2.17.1
[v2,1/2] i2c: pca954x: Add property to skip disabling PCA954x MUX device
On some Layerscape boards like LS2085ARDB and LS2088ARDB,
input pull-up resistors on PCA954x MUX device are missing on board,
So, if MUX are disabled after powered-on, input lines will float
leading to incorrect functionality.
Hence, PCA954x MUX device should never be turned-off after
power-on.
Add property to skip disabling PCA954x MUX device
if device tree contains "i2c-mux-never-disable"
for PCA954x device node.
Errata ID: E-00013 on board LS2085ARDB and LS2088ARDB
(The hardware bug found on board revision
Rev.B, Rev.C and Rev.D)
Signed-off-by: Biwen Li
---
Change in v2:
- update variable name
disable_mux->never_disable
drivers/i2c/muxes/i2c-mux-pca954x.c | 37 +
1 file changed, 33 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
b/drivers/i2c/muxes/i2c-mux-pca954x.c
index 923aa3a5a3dc..b4647b033163 100644
--- a/drivers/i2c/muxes/i2c-mux-pca954x.c
+++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
@@ -93,6 +93,11 @@ struct pca954x {
struct irq_domain *irq;
unsigned int irq_mask;
raw_spinlock_t lock;
+ /*
+* never disable value will write to control register of mux
+* to always enable mux
+*/
+ u8 never_disable;
};
/* Provide specs for the PCA954x types we know about */
@@ -258,6 +263,11 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc,
u32 chan)
struct i2c_client *client = data->client;
s8 idle_state;
+ if (data->never_disable) {
+ data->last_chan = data->chip->nchans;
+ return pca954x_reg_write(muxc->parent, client,
data->never_disable);
+ }
+
idle_state = READ_ONCE(data->idle_state);
if (idle_state >= 0)
/* Set the mux back to a predetermined channel */
@@ -462,16 +472,32 @@ static int pca954x_probe(struct i2c_client *client,
}
}
+ /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB:
+* The point here is that you must not disable a mux if there
+* are no pullups on the input or you mess up the I2C. This
+* needs to be put into the DTS really as the kernel cannot
+* know this otherwise.
+*/
+
+ data->never_disable = np &&
+ of_property_read_bool(np, "i2c-mux-never-disable") &&
+ data->chip->muxtype == pca954x_ismux ?
+ data->chip->enable : 0;
+
/* Write the mux register at addr to verify
* that the mux is in fact present. This also
* initializes the mux to disconnected state.
*/
- if (i2c_smbus_write_byte(client, 0) < 0) {
+ if (i2c_smbus_write_byte(client, data->never_disable) < 0) {
dev_warn(dev, "probe failed\n");
return -ENODEV;
}
- data->last_chan = 0; /* force the first selection */
+ if (data->never_disable)
+ data->last_chan = data->chip->nchans;
+ else
+ data->last_chan = 0; /* force the first selection
*/
+
data->idle_state = MUX_IDLE_AS_IS;
idle_disconnect_dt = np &&
@@ -531,8 +557,11 @@ static int pca954x_resume(struct device *dev)
struct i2c_mux_core *muxc = i2c_get_clientdata(client);
struct pca954x *data = i2c_mux_priv(muxc);
- data->last_chan = 0;
- return i2c_smbus_write_byte(client, 0);
+ if (data->never_disable)
+ data->last_chan = data->chip->nchans;
+ else
+ data->last_chan = 0;
+ return i2c_smbus_write_byte(client, data->never_disable);
}
#endif
--
2.17.1
Re: [PATCH v8] perf diff: Report noisy for cycles diff
Hi Jiri, Hi Arnaldo, Can this patch be accepted? Thanks Jin Yao On 9/25/2019 9:14 AM, Jin Yao wrote: This patch prints the stddev and hist for the cycles diff of program block. It can help us to understand if the cycles is noisy or not. This patch is inspired by Andi Kleen's patch https://lwn.net/Articles/600471/ We create new option '--cycles-hist'. Example: perf record -b ./div perf record -b ./div perf diff -c cycles # Baseline [Program Block Range] Cycles Diff Shared Object Symbol # .. . # 46.72% [div.c:40 -> div.c:40]0 div[.] main 46.72% [div.c:42 -> div.c:44]0 div[.] main 46.72% [div.c:42 -> div.c:39]0 div[.] main 20.54% [random_r.c:357 -> random_r.c:394]1 libc-2.27.so [.] __random_r 20.54% [random_r.c:357 -> random_r.c:380]0 libc-2.27.so [.] __random_r 20.54% [random_r.c:388 -> random_r.c:388]0 libc-2.27.so [.] __random_r 20.54% [random_r.c:388 -> random_r.c:391]0 libc-2.27.so [.] __random_r 17.04% [random.c:288 -> random.c:291]0 libc-2.27.so [.] __random 17.04% [random.c:291 -> random.c:291]0 libc-2.27.so [.] __random 17.04% [random.c:293 -> random.c:293]0 libc-2.27.so [.] __random 17.04% [random.c:295 -> random.c:295]0 libc-2.27.so [.] __random 17.04% [random.c:295 -> random.c:295]0 libc-2.27.so [.] __random 17.04% [random.c:298 -> random.c:298]0 libc-2.27.so [.] __random 8.40% [div.c:22 -> div.c:25]0 div[.] compute_flag 8.40% [div.c:27 -> div.c:28]0 div[.] compute_flag 5.14% [rand.c:26 -> rand.c:27]0 libc-2.27.so [.] rand 5.14% [rand.c:28 -> rand.c:28]0 libc-2.27.so [.] rand 2.15% [rand@plt+0 -> rand@plt+0]0 div[.] rand@plt 0.00% [kernel.kallsyms] [k] __x86_indirect_thunk_rax 0.00% [do_mmap+714 -> do_mmap+732] -10 [kernel.kallsyms] [k] do_mmap 0.00% [do_mmap+737 -> do_mmap+765]1 [kernel.kallsyms] [k] do_mmap 0.00% [do_mmap+262 -> do_mmap+299]0 [kernel.kallsyms] [k] do_mmap 0.00% [__x86_indirect_thunk_r15+0 -> __x86_indirect_thunk_r15+0]7 [kernel.kallsyms] [k] __x86_indirect_thunk_r15 0.00% [native_sched_clock+0 -> native_sched_clock+119] -1 [kernel.kallsyms] [k] native_sched_clock 0.00%[native_write_msr+0 -> native_write_msr+16] -13 [kernel.kallsyms] [k] native_write_msr When we enable the option '--cycles-hist', the output is perf diff -c cycles --cycles-hist # Baseline [Program Block Range] Cycles Diffstddev/Hist Shared Object Symbol # .. . . # 46.72% [div.c:40 -> div.c:40]0 ± 37.8% ▁█▁▁██▁█ div[.] main 46.72% [div.c:42 -> div.c:44]0 ± 49.4% ▁▁▂█ div[.] main 46.72% [div.c:42 -> div.c:39]0 ± 24.1% ▃█▂▄▁▃▂▁ div[.] main 20.54% [random_r.c:357 -> random_r.c:394]1 ± 33.5% ▅▂▁█▃▁▂▁ libc-2.27.so [.] __random_r 20.54% [random_r.c:357 -> random_r.c:380]0 ± 39.4% ▁▁█▁██▅▁ libc-2.27.so [.] __random_r 20.54% [random_r.c:388 -> random_r.c:388]0 libc-2.27.so [.] __random_r 20.54% [ran
[PATCH] fs: affs: fix a memroy leak in affs_remount
In affs_remount if data is provided it is duplicated into new_opts. But this is not actually used later! The allocated memory for new_opts is only released if pare_options fail. This commit adds release for new_opts. Signed-off-by: Navid Emamdoost --- fs/affs/super.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/affs/super.c b/fs/affs/super.c index cc463ae47c12..1d38fdbc5148 100644 --- a/fs/affs/super.c +++ b/fs/affs/super.c @@ -598,6 +598,8 @@ affs_remount(struct super_block *sb, int *flags, char *data) memcpy(sbi->s_volume, volume, 32); spin_unlock(&sbi->symlink_lock); + kfree(new_opts); + if ((bool)(*flags & SB_RDONLY) == sb_rdonly(sb)) return 0; -- 2.17.1
Re: [GIT PULL] SMB3 Fixes
The pull request you sent on Sat, 28 Sep 2019 16:36:21 -0500: > git://git.samba.org/sfrench/cifs-2.6.git tags/5.4-rc-smb3-fixes has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/7edee5229c8f4e075fe71274620bb11ead885c9b Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: [GIT PULL] Documentation/process/embargoed-hardware-issues patches for 5.4-rc1
The pull request you sent on Sun, 29 Sep 2019 12:53:47 +0200: > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc.git > tags/char-misc-5.4-rc1 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/97f9a3c4eee55b0178b518ae7114a6a53372913d Thank you! -- Deet-doot-dot, I am a bot. https://korg.wiki.kernel.org/userdoc/prtracker
Re: x86/random: Speculation to the rescue
On Sun, Sep 29, 2019 at 6:16 PM Linus Torvalds wrote: > > But I've committed that patch and the revert of the ext4 revert to a > local branch, I'll do some basic testing of it (which honestly on my > machines are kind of pointless, since all of them support rdrand), but > assuming it passes the basic smoke tests - and I expect it to - I'll > merge it for rc1. All my smoke testing looked fine - I disabled trusting the CPU, I increased the required entropy a lot, and to actually trigger the lockup issue without the broken user space, I made /dev/urandom do that "wait for entropy" thing too. It all looked sane to me, and the urandom part also had the side effect of then silencing all the "reading urandom without entropy" warning cases as expected. So it's merged. Note that what I merged did _not_ contain the urandom changes, that was purely for my testing. But it might well be a reasonable thing to do at some point. Of course, whether this jitter-entropy approach is reasonable in the first place ends up likely being debated, but it does seem to be the simplest way forward. Linus
RE: [EXT] Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device
> > Hello Biwen, > > > + /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB: > > +* The point here is that you must not disable a mux if there > > +* are no pullups on the input or you mess up the I2C. This > > +* needs to be put into the DTS really as the kernel cannot > > +* know this otherwise. > > +*/ > > Can you please explain what a "mess up" is? This is a hardware bug that happened on NXP board LS2085ARDB and LS2088ARDB. So give a software fix for the hardware bug. > > And also, should we put this new DTS property in related default bindings? > > If not, are you planning a documentation update for the users to notify them > about this? I will update bindings document on v2. > > -- > Cengiz Can
RE: [EXT] Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device
>
> On 2019-09-29 12:36, Biwen Li wrote:
> > On some Layerscape boards like LS2085ARDB and LS2088ARDB, input
> > pull-up resistors on PCA954x MUX device are missing on board, So, if
> > MUX are disabled after powered-on, input lines will float leading to
> > incorrect functionality.
>
> Hi!
>
> Are you saying that the parent bus of the mux is relying on some pull-ups
> inside
> the mux?
Yes, as follows:
VCC
---
|---
||
\\
/10K resister / 10k resister
\\
||
||
I2C1_SCL I2C1_SCL |
--
|SCL |
|SCL |
I2C1_SDA | PCA9547 |I2C1_SDA | |
PCA9547 |
|SDA |
|---|SDA |
--
--wrong design(need software fix as above or hardware fix)--
--proper design--
>
> > Hence, PCA954x MUX device should never be turned-off after power-on.
> >
> > Add property to skip disabling PCA954x MUX device if device tree
> > contains "i2c-mux-never-disable"
> > for PCA954x device node.
> >
> > Errata ID: E-00013 on board LS2085ARDB and LS2088ARDB (Board revision
> > found on Rev.B, Rev.C and Rev.D)
>
> I think you should follow the example of the i2c-mux-gpio driver and implement
> the idle-state property instead.
>
> That is a lot more consistent, assuming it solves the problem at hand?
Got it, thanks, I will try it.
>
> >
> > Signed-off-by: Biwen Li
> > ---
> > drivers/i2c/muxes/i2c-mux-pca954x.c | 33
> > +
> > 1 file changed, 29 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
> > b/drivers/i2c/muxes/i2c-mux-pca954x.c
> > index 923aa3a5a3dc..ea8aca54d572 100644
> > --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> > +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> > @@ -93,6 +93,7 @@ struct pca954x {
> > struct irq_domain *irq;
> > unsigned int irq_mask;
> > raw_spinlock_t lock;
> > + u8 disable_mux; /* do not disable mux if val not 0 */
>
> Awful number of negations there. The name is also backwards given that a
> non-zero value means that the mux should *not* be disabled. I would have
> reused the name from the binding.
>
> bool never_disable;
>
> A bit less confusing...
Got it,thanks, I will let it clear in v2.
>
> > };
> >
> > /* Provide specs for the PCA954x types we know about */ @@ -258,6
> > +259,11 @@ static int pca954x_deselect_mux(struct i2c_mux_core *muxc,
> u32 chan)
> > struct i2c_client *client = data->client;
> > s8 idle_state;
> >
> > + if (data->disable_mux != 0) {
>
> Please drop " != 0" and use the variable as a truth value. More instances
> below...
Got it, I will correct it in v2.
>
> > + data->last_chan = data->chip->nchans;
> > + return pca954x_reg_write(muxc->parent, client,
> data->disable_mux);
> > + }
> > +
> > idle_state = READ_ONCE(data->idle_state);
> > if (idle_state >= 0)
> > /* Set the mux back to a predetermined channel */ @@
> > -462,16 +468,32 @@ static int pca954x_probe(struct i2c_client *client,
> > }
> > }
> >
> > + /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB:
> > + * The point here is that you must not disable a mux if there
> > + * are no pullups on the input or you mess up the I2C. This
> > + * needs to be put into the DTS really as the kernel cannot
> > + * know this otherwise.
> > + */
> > +
> > + data->disable_mux = np &&
> > + of_property_read_bool(np, "i2c-mux-never-disable") &&
>
> i2c-mux-never-disable needs to be documented. However see above for my
> point that you should do it like the i2c-mux-gpio driver. Any usage of
> idle-state
> still needs to be documented f
[PATCH] usb: dwc3: pci: prevent memory leak in dwc3_pci_probe
In dwc3_pci_probe a call to platform_device_alloc allocates a device
which is correctly put in case of error except one case: when the call to
platform_device_add_properties fails it directly returns instead of
going to error handling. This commit replaces return with the goto.
Fixes: 1a7b12f69a94 ("usb: dwc3: pci: Supply device properties via driver data")
Signed-off-by: Navid Emamdoost
---
drivers/usb/dwc3/dwc3-pci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 5e8e18222f92..023f0357efd7 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -258,7 +258,7 @@ static int dwc3_pci_probe(struct pci_dev *pci, const struct
pci_device_id *id)
ret = platform_device_add_properties(dwc->dwc3, p);
if (ret < 0)
- return ret;
+ goto err;
ret = dwc3_pci_quirks(dwc);
if (ret)
--
2.17.1
Re: [PATCH] virt: vbox: fix memory leak in hgcm_call_preprocess_linaddr
It is a neat fix now, thank you.
On Sat, Sep 28, 2019 at 4:54 AM Hans de Goede wrote:
>
> Hi,
>
> On 28-09-2019 01:04, Navid Emamdoost wrote:
> > In hgcm_call_preprocess_linaddr memory is allocated for bounce_buf but
> > is not released if copy_form_user fails. The release is added.
> >
> > Fixes: 579db9d45cb4 ("virt: Add vboxguest VMMDEV communication code")
> >
> > Signed-off-by: Navid Emamdoost
>
> Thank you for catching this, I agree this is a bug, but I think we
> can fix it in a cleaner way (see below).
>
> > ---
> > drivers/virt/vboxguest/vboxguest_utils.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/virt/vboxguest/vboxguest_utils.c
> > b/drivers/virt/vboxguest/vboxguest_utils.c
> > index 75fd140b02ff..7965885a50fa 100644
> > --- a/drivers/virt/vboxguest/vboxguest_utils.c
> > +++ b/drivers/virt/vboxguest/vboxguest_utils.c
> > @@ -222,8 +222,10 @@ static int hgcm_call_preprocess_linaddr(
> >
> > if (copy_in) {
> > ret = copy_from_user(bounce_buf, (void __user *)buf, len);
> > - if (ret)
> > + if (ret) {
> > + kvfree(bounce_buf);
> > return -EFAULT;
> > + }
> > } else {
> > memset(bounce_buf, 0, len);
> > }
> >
>
> First let me quote some more of the function, pre leak fix, for context:
>
> bounce_buf = kvmalloc(len, GFP_KERNEL);
> if (!bounce_buf)
> return -ENOMEM;
>
> if (copy_in) {
> ret = copy_from_user(bounce_buf, (void __user *)buf, len);
> if (ret)
> return -EFAULT;
> } else {
> memset(bounce_buf, 0, len);
> }
>
> *bounce_buf_ret = bounce_buf;
>
> This function gets called repeatedly by hgcm_call_preprocess(), and the
> caller of hgcm_call_preprocess() already takes care of freeing the
> bounce bufs both on a (later) error and on success:
>
> ret = hgcm_call_preprocess(parms, parm_count, &bounce_bufs, &size);
> if (ret) {
> /* Even on error bounce bufs may still have been allocated */
> goto free_bounce_bufs;
> }
>
> ...
>
> free_bounce_bufs:
> if (bounce_bufs) {
> for (i = 0; i < parm_count; i++)
> kvfree(bounce_bufs[i]);
> kfree(bounce_bufs);
> }
>
> So we are already taking care of freeing bounce-bufs allocated for previous
> parameters to the call (which me must do anyways), so a cleaner fix would
> be to store the allocated bounce_buf in the bounce_bufs array before
> doing the copy_from_user, then if copy_from_user fails it will be cleaned
> up by the code at the free_bounce_bufs label.
>
> IOW I believe it is better to fix this by changing the part of
> hgcm_call_preprocess_linaddr I quoted to:
>
> bounce_buf = kvmalloc(len, GFP_KERNEL);
> if (!bounce_buf)
> return -ENOMEM;
>
> *bounce_buf_ret = bounce_buf;
>
> if (copy_in) {
> ret = copy_from_user(bounce_buf, (void __user *)buf, len);
> if (ret)
> return -EFAULT;
> } else {
> memset(bounce_buf, 0, len);
> }
>
> This should also fix the leak in IMHO is a clear way of doing so.
>
> Regards,
>
> Hans
>
>
>
>
>
--
Navid.
[PATCH v5 0/1] Add bounds check for Hotplugged memory
From: Alastair D'Silva This series adds bounds checks for hotplugged memory, ensuring that it is within the physically addressable range (for platforms that define MAX_(POSSIBLE_)PHYSMEM_BITS. This allows for early failure, rather than attempting to access bogus section numbers. Changelog: V5: - Factor out calculation into max_allowed var - Declare unchanging vars as const - Use PFN_PHYS macro instead of shifting by PAGE_SHIFT V4: - Relocate call to __add_pages - Add a warning when the addressable check fails V3: - Perform the addressable check before we take the hotplug lock V2: - Don't use MAX_POSSIBLE_PHYSMEM_BITS as it's wider that what may be available Alastair D'Silva (1): memory_hotplug: Add a bounds check to __add_pages mm/memory_hotplug.c | 20 1 file changed, 20 insertions(+) -- 2.21.0
[PATCH v5 1/1] memory_hotplug: Add a bounds check to __add_pages
From: Alastair D'Silva
On PowerPC, the address ranges allocated to OpenCAPI LPC memory
are allocated from firmware. These address ranges may be higher
than what older kernels permit, as we increased the maximum
permissable address in commit 4ffe713b7587
("powerpc/mm: Increase the max addressable memory to 2PB"). It is
possible that the addressable range may change again in the
future.
In this scenario, we end up with a bogus section returned from
__section_nr (see the discussion on the thread "mm: Trigger bug on
if a section is not found in __section_nr").
Adding a check here means that we fail early and have an
opportunity to handle the error gracefully, rather than rumbling
on and potentially accessing an incorrect section.
Further discussion is also on the thread ("powerpc: Perform a bounds
check in arch_add_memory")
http://lkml.kernel.org/r/20190827052047.31547-1-alast...@au1.ibm.com
Signed-off-by: Alastair D'Silva
---
mm/memory_hotplug.c | 20
1 file changed, 20 insertions(+)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index c73f09913165..1909607da640 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -278,6 +278,22 @@ static int check_pfn_span(unsigned long pfn, unsigned long
nr_pages,
return 0;
}
+static int check_hotplug_memory_addressable(unsigned long pfn,
+ unsigned long nr_pages)
+{
+ const u64 max_addr = PFN_PHYS(pfn + nr_pages) - 1;
+
+ if (max_addr >> MAX_PHYSMEM_BITS) {
+ const u64 max_allowed = (1ull << (MAX_PHYSMEM_BITS + 1)) - 1;
+ WARN(1,
+"Hotplugged memory exceeds maximum addressable address,
range=%#lx-%#lx, maximum=%#lx\n",
+PFN_PHYS(pfn), max_addr, max_allowed);
+ return -E2BIG;
+ }
+
+ return 0;
+}
+
/*
* Reasonably generic function for adding memory. It is
* expected that archs that support memory hotplug will
@@ -291,6 +307,10 @@ int __ref __add_pages(int nid, unsigned long pfn, unsigned
long nr_pages,
unsigned long nr, start_sec, end_sec;
struct vmem_altmap *altmap = restrictions->altmap;
+ err = check_hotplug_memory_addressable(pfn, nr_pages);
+ if (err)
+ return err;
+
if (altmap) {
/*
* Validate altmap is within bounds of the total request
--
2.21.0
[V5 1/2] dmaengine: fsl-dpaa2-qdma: Add the DPDMAI(Data Path DMA Interface) support
The MC(Management Complex) exports the DPDMAI(Data Path DMA Interface)
object as an interface to operate the DPAA2(Data Path Acceleration
Architecture 2) qDMA Engine. The DPDMAI enables sending frame-based
requests to qDMA and receiving back confirmation response on transaction
completion, utilizing the DPAA2 QBMan(Queue Manager and Buffer Manager
hardware) infrastructure. DPDMAI object provides up to two priorities for
processing qDMA requests.
The following list summarizes the DPDMAI main features and capabilities:
1. Supports up to two scheduling priorities for processing
service requests.
- Each DPDMAI transmit queue is mapped to one of two service
priorities, allowing further prioritization in hardware between
requests from different DPDMAI objects.
2. Supports up to two receive queues for incoming transaction
completion confirmations.
- Each DPDMAI receive queue is mapped to one of two receive
priorities, allowing further prioritization between other
interfaces when associating the DPDMAI receive queues to DPIO
or DPCON(Data Path Concentrator) objects.
3. Supports different scheduling options for processing received
packets:
- Queues can be configured either in 'parked' mode (default),
or attached to a DPIO object, or attached to DPCON object.
4. Allows interaction with one or more DPIO objects for
dequeueing/enqueueing frame descriptors(FD) and for
acquiring/releasing buffers.
5. Supports enable, disable, and reset operations.
Add dpdmai to support some platforms with dpaa2 qdma engine.
Signed-off-by: Peng Ma
---
changed for v5:
- Clean up the format.
- Delete some useless struct and macro.
- Fix spell.
- Move the description of function from header to C file.
drivers/dma/fsl-dpaa2-qdma/dpdmai.c | 366 +++
drivers/dma/fsl-dpaa2-qdma/dpdmai.h | 177 +
2 files changed, 543 insertions(+), 0 deletions(-)
create mode 100644 drivers/dma/fsl-dpaa2-qdma/dpdmai.c
create mode 100644 drivers/dma/fsl-dpaa2-qdma/dpdmai.h
diff --git a/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
new file mode 100644
index 000..fbc2b2f
--- /dev/null
+++ b/drivers/dma/fsl-dpaa2-qdma/dpdmai.c
@@ -0,0 +1,366 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2019 NXP
+
+#include
+#include
+#include
+#include "dpdmai.h"
+
+struct dpdmai_rsp_get_attributes {
+ __le32 id;
+ u8 num_of_priorities;
+ u8 pad0[3];
+ __le16 major;
+ __le16 minor;
+};
+
+struct dpdmai_cmd_queue {
+ __le32 dest_id;
+ u8 priority;
+ u8 queue;
+ u8 dest_type;
+ u8 pad;
+ __le64 user_ctx;
+ union {
+ __le32 options;
+ __le32 fqid;
+ };
+};
+
+struct dpdmai_rsp_get_tx_queue {
+ __le64 pad;
+ __le32 fqid;
+};
+
+#define MC_CMD_OP(_cmd, _param, _offset, _width, _type, _arg) \
+ ((_cmd).params[_param] |= mc_enc((_offset), (_width), _arg))
+
+/* cmd, param, offset, width, type, arg_name */
+#define DPDMAI_CMD_CREATE(_cmd, _cfg) \
+do { \
+ typeof(_cmd) (cmd) = (_cmd); \
+ typeof(_cfg) (cfg) = (_cfg); \
+ MC_CMD_OP(cmd, 0, 8, 8, u8, (cfg)->priorities[0]);\
+ MC_CMD_OP(cmd, 0, 16, 8, u8, (cfg)->priorities[1]);\
+} while (0)
+
+static inline u64 mc_enc(int lsoffset, int width, u64 val)
+{
+ return (val & MAKE_UMASK64(width)) << lsoffset;
+}
+
+/**
+ * dpdmai_open() - Open a control session for the specified object
+ * @mc_io: Pointer to MC portal's I/O object
+ * @cmd_flags: Command flags; one or more of 'MC_CMD_FLAG_'
+ * @dpdmai_id: DPDMAI unique ID
+ * @token: Returned token; use in subsequent API calls
+ *
+ * This function can be used to open a control session for an
+ * already created object; an object may have been declared in
+ * the DPL or by calling the dpdmai_create() function.
+ * This function returns a unique authentication token,
+ * associated with the specific object ID and the specific MC
+ * portal; this token must be used in all subsequent commands for
+ * this specific object.
+ *
+ * Return: '0' on Success; Error code otherwise.
+ */
+int dpdmai_open(struct fsl_mc_io *mc_io, u32 cmd_flags,
+ int dpdmai_id, u16 *token)
+{
+ struct fsl_mc_command cmd = { 0 };
+ __le64 *cmd_dpdmai_id;
+ int err;
+
+ /* prepare command */
+ cmd.header = mc_encode_cmd_header(DPDMAI_CMDID_OPEN,
+ cmd_flags, 0);
+
+ cmd_dpdmai_id = cmd.params;
+ *cmd_dpdmai_id = cpu_to_le32(dpdmai_id);
+
+ /* send command to mc*/
+ err = mc_send_command(mc_io, &cmd);
+ if (err)
+ return err;
+
+ /* retrieve response parameters */
+ *token = mc_cmd_hdr_read_token(&cmd);
+
+ return 0;
+}
+
+/**
+ * dpdma
[V5 2/2] dmaengine: fsl-dpaa2-qdma: Add NXP dpaa2 qDMA controller driver for Layerscape SoCs
DPPA2(Data Path Acceleration Architecture 2) qDMA supports
virtualized channel by allowing DMA jobs to be enqueued into
different work queues. Core can initiate a DMA transaction by
preparing a frame descriptor(FD) for each DMA job and enqueuing
this job through a hardware portal. DPAA2 components can also
prepare a FD and enqueue a DMA job through a hardware portal.
The qDMA prefetches DMA jobs through DPAA2 hardware portal. It
then schedules and dispatches to internal DMA hardware engines,
which generate read and write requests. Both qDMA source data and
destination data can be either contiguous or non-contiguous using
one or more scatter/gather tables.
The qDMA supports global bandwidth flow control where all DMA
transactions are stalled if the bandwidth threshold has been reached.
Also supported are transaction based read throttling.
Add NXP dppa2 qDMA to support some of Layerscape SoCs.
such as: LS1088A, LS208xA, LX2, etc.
Signed-off-by: Peng Ma
---
changed for v5:
- Clean up the format and code.
- Update comments.
- Add error logs.
drivers/dma/Kconfig |2 +
drivers/dma/Makefile|1 +
drivers/dma/fsl-dpaa2-qdma/Kconfig |9 +
drivers/dma/fsl-dpaa2-qdma/Makefile |3 +
drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c | 825 +++
drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.h | 153 ++
6 files changed, 993 insertions(+), 0 deletions(-)
create mode 100644 drivers/dma/fsl-dpaa2-qdma/Kconfig
create mode 100644 drivers/dma/fsl-dpaa2-qdma/Makefile
create mode 100644 drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
create mode 100644 drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.h
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 76859aa..e4dd9c6 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -673,6 +673,8 @@ source "drivers/dma/sh/Kconfig"
source "drivers/dma/ti/Kconfig"
+source "drivers/dma/fsl-dpaa2-qdma/Kconfig"
+
# clients
comment "DMA Clients"
depends on DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 5bddf6f..15a318d 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -76,6 +76,7 @@ obj-$(CONFIG_UNIPHIER_MDMAC) += uniphier-mdmac.o
obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
obj-$(CONFIG_ZX_DMA) += zx_dma.o
obj-$(CONFIG_ST_FDMA) += st_fdma.o
+obj-$(CONFIG_FSL_DPAA2_QDMA) += fsl-dpaa2-qdma/
obj-y += mediatek/
obj-y += qcom/
diff --git a/drivers/dma/fsl-dpaa2-qdma/Kconfig
b/drivers/dma/fsl-dpaa2-qdma/Kconfig
new file mode 100644
index 000..258ed6b
--- /dev/null
+++ b/drivers/dma/fsl-dpaa2-qdma/Kconfig
@@ -0,0 +1,9 @@
+menuconfig FSL_DPAA2_QDMA
+ tristate "NXP DPAA2 QDMA"
+ depends on ARM64
+ depends on FSL_MC_BUS && FSL_MC_DPIO
+ select DMA_ENGINE
+ select DMA_VIRTUAL_CHANNELS
+ help
+ NXP Data Path Acceleration Architecture 2 QDMA driver,
+ using the NXP MC bus driver.
diff --git a/drivers/dma/fsl-dpaa2-qdma/Makefile
b/drivers/dma/fsl-dpaa2-qdma/Makefile
new file mode 100644
index 000..c1d0226
--- /dev/null
+++ b/drivers/dma/fsl-dpaa2-qdma/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+# Makefile for the NXP DPAA2 qDMA controllers
+obj-$(CONFIG_FSL_DPAA2_QDMA) += dpaa2-qdma.o dpdmai.o
diff --git a/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
new file mode 100644
index 000..c70a796
--- /dev/null
+++ b/drivers/dma/fsl-dpaa2-qdma/dpaa2-qdma.c
@@ -0,0 +1,825 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright 2019 NXP
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "../virt-dma.h"
+#include "dpdmai.h"
+#include "dpaa2-qdma.h"
+
+static bool smmu_disable = true;
+
+static struct dpaa2_qdma_chan *to_dpaa2_qdma_chan(struct dma_chan *chan)
+{
+ return container_of(chan, struct dpaa2_qdma_chan, vchan.chan);
+}
+
+static struct dpaa2_qdma_comp *to_fsl_qdma_comp(struct virt_dma_desc *vd)
+{
+ return container_of(vd, struct dpaa2_qdma_comp, vdesc);
+}
+
+static int dpaa2_qdma_alloc_chan_resources(struct dma_chan *chan)
+{
+ struct dpaa2_qdma_chan *dpaa2_chan = to_dpaa2_qdma_chan(chan);
+ struct dpaa2_qdma_engine *dpaa2_qdma = dpaa2_chan->qdma;
+ struct device *dev = &dpaa2_qdma->priv->dpdmai_dev->dev;
+
+ dpaa2_chan->fd_pool = dma_pool_create("fd_pool", dev,
+ sizeof(struct dpaa2_fd),
+ sizeof(struct dpaa2_fd), 0);
+ if (!dpaa2_chan->fd_pool)
+ goto err;
+
+ dpaa2_chan->fl_pool = dma_pool_create("fl_pool", dev,
+ sizeof(struct dpaa2_fl_entry),
+ sizeof(struct dpaa2_fl_entry), 0);
+ if (!dpaa2_chan->fl_pool)
+ goto err_fd;
+
+ dpaa2_chan->sdd_pool =
+ dma_pool_create("sdd_pool", dev,
+
[PATCH v10 1/3] arm64: cpufeature: introduce helper cpu_has_hw_af()
We unconditionally set the HW_AFDBM capability and only enable it on
CPUs which really have the feature. But sometimes we need to know
whether this cpu has the capability of HW AF. So decouple AF from
DBM by new helper cpu_has_hw_af().
Signed-off-by: Jia He
Suggested-by: Suzuki Poulose
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/cpufeature.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/include/asm/cpufeature.h
b/arch/arm64/include/asm/cpufeature.h
index 9cde5d2e768f..949bc7c85030 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -659,6 +659,16 @@ static inline u32 id_aa64mmfr0_parange_to_phys_shift(int
parange)
default: return CONFIG_ARM64_PA_BITS;
}
}
+
+/* Check whether hardware update of the Access flag is supported */
+static inline bool cpu_has_hw_af(void)
+{
+ if (IS_ENABLED(CONFIG_ARM64_HW_AFDBM))
+ return read_cpuid(ID_AA64MMFR1_EL1) & 0xf;
+
+ return false;
+}
+
#endif /* __ASSEMBLY__ */
#endif
--
2.17.1
[PATCH v10 2/3] arm64: mm: implement arch_faults_on_old_pte() on arm64
On arm64 without hardware Access Flag, copying fromuser will fail because
the pte is old and cannot be marked young. So we always end up with zeroed
page after fork() + CoW for pfn mappings. we don't always have a
hardware-managed access flag on arm64.
Hence implement arch_faults_on_old_pte on arm64 to indicate that it might
cause page fault when accessing old pte.
Signed-off-by: Jia He
Reviewed-by: Catalin Marinas
---
arch/arm64/include/asm/pgtable.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7576df00eb50..e96fb82f62de 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -885,6 +885,20 @@ static inline void update_mmu_cache(struct vm_area_struct
*vma,
#define phys_to_ttbr(addr) (addr)
#endif
+/*
+ * On arm64 without hardware Access Flag, copying from user will fail because
+ * the pte is old and cannot be marked young. So we always end up with zeroed
+ * page after fork() + CoW for pfn mappings. We don't always have a
+ * hardware-managed access flag on arm64.
+ */
+static inline bool arch_faults_on_old_pte(void)
+{
+ WARN_ON(preemptible());
+
+ return !cpu_has_hw_af();
+}
+#define arch_faults_on_old_pte arch_faults_on_old_pte
+
#endif /* !__ASSEMBLY__ */
#endif /* __ASM_PGTABLE_H */
--
2.17.1
[PATCH v10 0/3] fix double page fault on arm64
When we tested pmdk unit test vmmalloc_fork TEST1 in arm64 guest, there will be a double page fault in __copy_from_user_inatomic of cow_user_page. As told by Catalin: "On arm64 without hardware Access Flag, copying from user will fail because the pte is old and cannot be marked young. So we always end up with zeroed page after fork() + CoW for pfn mappings. we don't always have a hardware-managed access flag on arm64." Changes v10: add r-b from Catalin and a-b from Kirill in PATCH 03 remoe Reported-by in PATCH 01 v9: refactor cow_user_page for indention optimization (Catalin) hold the ptl longer (Catalin) v8: change cow_user_page's return type (Matthew) v7: s/pte_spinlock/pte_offset_map_lock (Kirill) v6: fix error case of returning with spinlock taken (Catalin) move kmap_atomic to avoid handling kunmap_atomic v5: handle the case correctly when !pte_same fix kbuild test failed v4: introduce cpu_has_hw_af (Suzuki) bail out if !pte_same (Kirill) v3: add vmf->ptl lock/unlock (Kirill A. Shutemov) add arch_faults_on_old_pte (Matthew, Catalin) v2: remove FAULT_FLAG_WRITE when setting pte access flag (Catalin) Jia He (3): arm64: cpufeature: introduce helper cpu_has_hw_af() arm64: mm: implement arch_faults_on_old_pte() on arm64 mm: fix double page fault on arm64 if PTE_AF is cleared arch/arm64/include/asm/cpufeature.h | 10 +++ arch/arm64/include/asm/pgtable.h| 14 mm/memory.c | 99 - 3 files changed, 108 insertions(+), 15 deletions(-) -- 2.17.1
[PATCH v10 3/3] mm: fix double page fault on arm64 if PTE_AF is cleared
When we tested pmdk unit test [1] vmmalloc_fork TEST1 in arm64 guest, there
will be a double page fault in __copy_from_user_inatomic of cow_user_page.
Below call trace is from arm64 do_page_fault for debugging purpose
[ 110.016195] Call trace:
[ 110.016826] do_page_fault+0x5a4/0x690
[ 110.017812] do_mem_abort+0x50/0xb0
[ 110.018726] el1_da+0x20/0xc4
[ 110.019492] __arch_copy_from_user+0x180/0x280
[ 110.020646] do_wp_page+0xb0/0x860
[ 110.021517] __handle_mm_fault+0x994/0x1338
[ 110.022606] handle_mm_fault+0xe8/0x180
[ 110.023584] do_page_fault+0x240/0x690
[ 110.024535] do_mem_abort+0x50/0xb0
[ 110.025423] el0_da+0x20/0x24
The pte info before __copy_from_user_inatomic is (PTE_AF is cleared):
[9b007000] pgd=00023d4f8003, pud=00023da9b003,
pmd=00023d4b3003, pte=36298607bd3
As told by Catalin: "On arm64 without hardware Access Flag, copying from
user will fail because the pte is old and cannot be marked young. So we
always end up with zeroed page after fork() + CoW for pfn mappings. we
don't always have a hardware-managed access flag on arm64."
This patch fix it by calling pte_mkyoung. Also, the parameter is
changed because vmf should be passed to cow_user_page()
Add a WARN_ON_ONCE when __copy_from_user_inatomic() returns error
in case there can be some obscure use-case.(by Kirill)
[1] https://github.com/pmem/pmdk/tree/master/src/test/vmmalloc_fork
Signed-off-by: Jia He
Reported-by: Yibo Cai
Reviewed-by: Catalin Marinas
Acked-by: Kirill A. Shutemov
---
mm/memory.c | 99 +
1 file changed, 84 insertions(+), 15 deletions(-)
diff --git a/mm/memory.c b/mm/memory.c
index b1ca51a079f2..1f56b0118ef5 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -118,6 +118,13 @@ int randomize_va_space __read_mostly =
2;
#endif
+#ifndef arch_faults_on_old_pte
+static inline bool arch_faults_on_old_pte(void)
+{
+ return false;
+}
+#endif
+
static int __init disable_randmaps(char *s)
{
randomize_va_space = 0;
@@ -2145,32 +2152,82 @@ static inline int pte_unmap_same(struct mm_struct *mm,
pmd_t *pmd,
return same;
}
-static inline void cow_user_page(struct page *dst, struct page *src, unsigned
long va, struct vm_area_struct *vma)
+static inline bool cow_user_page(struct page *dst, struct page *src,
+struct vm_fault *vmf)
{
+ bool ret;
+ void *kaddr;
+ void __user *uaddr;
+ bool force_mkyoung;
+ struct vm_area_struct *vma = vmf->vma;
+ struct mm_struct *mm = vma->vm_mm;
+ unsigned long addr = vmf->address;
+
debug_dma_assert_idle(src);
+ if (likely(src)) {
+ copy_user_highpage(dst, src, addr, vma);
+ return true;
+ }
+
/*
* If the source page was a PFN mapping, we don't have
* a "struct page" for it. We do a best-effort copy by
* just copying from the original user address. If that
* fails, we just zero-fill it. Live with it.
*/
- if (unlikely(!src)) {
- void *kaddr = kmap_atomic(dst);
- void __user *uaddr = (void __user *)(va & PAGE_MASK);
+ kaddr = kmap_atomic(dst);
+ uaddr = (void __user *)(addr & PAGE_MASK);
+
+ /*
+* On architectures with software "accessed" bits, we would
+* take a double page fault, so mark it accessed here.
+*/
+ force_mkyoung = arch_faults_on_old_pte() && !pte_young(vmf->orig_pte);
+ if (force_mkyoung) {
+ pte_t entry;
+
+ vmf->pte = pte_offset_map_lock(mm, vmf->pmd, addr, &vmf->ptl);
+ if (!likely(pte_same(*vmf->pte, vmf->orig_pte))) {
+ /*
+* Other thread has already handled the fault
+* and we don't need to do anything. If it's
+* not the case, the fault will be triggered
+* again on the same address.
+*/
+ ret = false;
+ goto pte_unlock;
+ }
+
+ entry = pte_mkyoung(vmf->orig_pte);
+ if (ptep_set_access_flags(vma, addr, vmf->pte, entry, 0))
+ update_mmu_cache(vma, addr, vmf->pte);
+ }
+ /*
+* This really shouldn't fail, because the page is there
+* in the page tables. But it might just be unreadable,
+* in which case we just give up and fill the result with
+* zeroes.
+*/
+ if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) {
/*
-* This really shouldn't fail, because the page is there
-* in the page tables. But it might just be unreadable,
-* in which case we just give up and fill the result with
-* zeroes.
+* Give a warn in case th
Re: [PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()
On 2019/09/30 9:28, Sasha Levin wrote:
> On Sun, Sep 29, 2019 at 11:43:38PM +0900, Tetsuo Handa wrote:
>> On 2019/09/29 22:54, Greg Kroah-Hartman wrote:
>>> From: Waiman Long
>>>
>>> [ Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf ]
>>>
>>> Tetsuo Handa had reported he saw an incorrect "downgrading a read lock"
>>> warning right after a previous lockdep warning. It is likely that the
>>> previous warning turned off lock debugging causing the lockdep to have
>>> inconsistency states leading to the lock downgrade warning.
>>>
>>> Fix that by add a check for debug_locks at the beginning of
>>> __lock_downgrade().
>>
>> Please drop "[PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in
>> __lock_downgrade()".
>> We had a revert patch shown below in the past.
>
> We had a revert in the stable trees, but that revert was incorrect.
>
> Take a look at commit 513e1073d52e55 upstream, it patches
> __lock_set_class() (even though the subject line says
> __lock_downgrade()). So this is not a backporting error as the revert
> said it is, but is rather the intended location to be patched.
>
> If this is actually wrong, then it should be addressed upstream first.
>
Hmm, upstream has two commits with same author, same date, same subject,
different hash, different content.
I couldn't find from
https://lkml.kernel.org/r/1547093005-26085-1-git-send-email-long...@redhat.com
that
we want to patch both __lock_set_class() and __lock_downgrade(), but I found
that the tip-bot has patched
__lock_downgrade() on "2019-01-21 11:29" and __lock_set_class() on "2019-02-04
8:56".
Seems that we by error patched both functions, though patching both functions
should be harmless...
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4115) static int
00ef9f734 kernel/lockdep.c (Peter Zijlstra2008-12-04
09:00:17 +0100 4116) __lock_set_class(struct lockdep_map *lock, const char
*name,
00ef9f734 kernel/lockdep.c (Peter Zijlstra2008-12-04
09:00:17 +0100 4117)struct lock_class_key *key, unsigned int
subclass,
00ef9f734 kernel/lockdep.c (Peter Zijlstra2008-12-04
09:00:17 +0100 4118)unsigned long ip)
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4119) {
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4120) struct task_struct *curr = current;
8c8889d8e kernel/locking/lockdep.c (Imre Deak 2019-05-24
23:15:08 +0300 4121) unsigned int depth, merged = 0;
41c2c5b86 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:15 +0900 4122) struct held_lock *hlock;
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4123) struct lock_class *class;
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4124) int i;
64aa348ed kernel/lockdep.c (Peter Zijlstra2008-08-11
09:30:21 +0200 4125)
513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4126) if (unlikely(!debug_locks))
513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4127) return 0;
513e1073d kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4128)
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4162) static int __lock_downgrade(struct lockdep_map *lock,
unsigned long ip)
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4163) {
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4164) struct task_struct *curr = current;
8c8889d8e kernel/locking/lockdep.c (Imre Deak 2019-05-24
23:15:08 +0300 4165) unsigned int depth, merged = 0;
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4166) struct held_lock *hlock;
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4167) int i;
6419c4af7 kernel/locking/lockdep.c (J. R. Okajima 2017-02-03
01:38:17 +0900 4168)
714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4169) if (unlikely(!debug_locks))
714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4170) return 0;
714925805 kernel/locking/lockdep.c (Waiman Long 2019-01-09
23:03:25 -0500 4171)
commit 513e1073d52e55b8024b4f238a48de7587c64ccf
Author: Waiman Long
Date: Wed Jan 9 23:03:25 2019 -0500
locking/lockdep: Add debug_locks check in __lock_downgrade()
commit 71492580571467fb7177aade19c18ce7486267f5
Author: Waiman Long
Date: Wed Jan 9 23:03:25 2019 -0500
locking/lockdep: Add debug_locks check in __lock_downgrade()
Re: [PATCH v3] patman: Use the Change-Id, version, and prefix in the Message-Id
On Fri, 27 Sep 2019 at 10:25, Douglas Anderson wrote: > > As per the centithread on ksummit-discuss [1], there are folks who > feel that if a Change-Id is present in a developer's local commit that > said Change-Id could be interesting to include in upstream posts. > Specifically if two commits are posted with the same Change-Id there's > a reasonable chance that they are either the same commit or a newer > version of the same commit. Specifically this is because that's how > gerrit has trained people to work. > > There is much angst about Change-Id in upstream Linux, but one thing > that seems safe and non-controversial is to include the Change-Id as > part of the string of crud that makes up a Message-Id. > > Let's give that a try. > > In theory (if there is enough adoption) this could help a tool more > reliably find various versions of a commit. This actually might work > pretty well for U-Boot where (I believe) quite a number of developers > use patman, so there could be critical mass (assuming that enough of > these people also use a git hook that adds Change-Id to their > commits). I was able to find this git hook by searching for "gerrit > change id git hook" in my favorite search engine. > > In theory one could imagine something like this could be integrated > into other tools, possibly even git-send-email. Getting it into > patman seems like a sane first step, though. > > NOTE: this patch is being posted using a patman containing this patch, > so you should be able to see the Message-Id of this patch and see that > it contains my local Change-Id, which ends in 2b9 if you want to > check. > > [1] > https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2019-August/006739.html > > Signed-off-by: Douglas Anderson > --- > > Changes in v3: > - Allow faking the time of Message-Id for testing (testBasic) > - Add skip_blank for Change-Id (testBasic). > - Check the Message-Id in testBasic. Applied to u-boot-dm/next, thanks! > > Changes in v2: > - Add a "v" before the version part of the Message-Id > - Reorder the parts of the Message-Id as per Johannes. > > tools/patman/README | 8 - > tools/patman/commit.py | 3 ++ > tools/patman/patchstream.py | 64 +++-- > tools/patman/test.py| 15 +++-- > 4 files changed, 85 insertions(+), 5 deletions(-)
Re: x86/random: Speculation to the rescue
On Sat, Sep 28, 2019 at 4:53 PM Linus Torvalds wrote: > > But hey, here's a made-up patch. It basically does jitter entropy, but > it uses a more complex load than the fibonacci LFSR folding: it calls > "schedule()" in a loop, and it sets up a timer to fire. Ok, I'm sure a lot of people will end up finding this distasteful, and I'll admit to just waffling about it myself. But I am supposed to close the merge window today, and honestly, I want _something_ to happen about the getrandom() issue during the 5.4 merge cycle. So I had a few choices - just ignore things and hope some consensus happens - start the movement to a new getrandom() interface and encourage user space to say "yeah, I don't need _secure_ random numbers" - or just say "hey, a lot of people find jitter entropy reasonable, so let's just try this". And I went with that last choice. If it works, it makes the getrandom() interface changes a non-issue. I'm not saying my patch is going to be the last word on the issue. I'm _personally_ ok with it and believe it's not crazy, and if it then makes serious people go "Eww" and send some improvements to it, then it has served its purpose. But I've committed that patch and the revert of the ext4 revert to a local branch, I'll do some basic testing of it (which honestly on my machines are kind of pointless, since all of them support rdrand), but assuming it passes the basic smoke tests - and I expect it to - I'll merge it for rc1. I also have my old readdir branch that I decided I want to merge due to the (completely independent) discussion about filldir issues, so I'll probably end up delaying rc1 until tomorrow, but just a heads up. I don't want to leave this until "some time later in the -rc series", although I will be _more_ than happy to have people send me fixes to my somewhat simplistic patch. That said, my patch may be simplistic, but I suspect using a loop with a real load like schedule() and arming a timer is a lot more realistic than some of the jitter entropy papers with their _very_ trivial LFSR's and some made-up pointer chasing. But yeah, I think improvements to it are also not unexpected or unreasonable ;) Linus
Re: [PATCH v3 04/10] sched/fair: rework load_balance
On Thu, 2019-09-19 at 09:33 +0200, Vincent Guittot wrote: > > Also the load balance decisions have been consolidated in the 3 > functions > below after removing the few bypasses and hacks of the current code: > - update_sd_pick_busiest() select the busiest sched_group. > - find_busiest_group() checks if there is an imbalance between local > and > busiest group. > - calculate_imbalance() decides what have to be moved. I really like the direction this series is going. However, I suppose I should run these patches for a few days with some of our test workloads before I send out an ack for this patch :) -- All Rights Reversed. signature.asc Description: This is a digitally signed message part
[PATCH] acpi: Mute gcc warning
When build with "EXTRA_CFLAGS=-Wall" gcc warns:
arch/x86/boot/compressed/acpi.c:29:30: warning: get_cmdline_acpi_rsdp defined
but not used [-Wunused-function]
Fixes: 41fa1ee9c6d6 ("acpi: Ignore acpi_rsdp kernel param when the kernel has
been locked down")
Signed-off-by: Zhenzhong Duan
Cc: Josh Boyer
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: "H. Peter Anvin"
Cc: Chao Fan
---
arch/x86/boot/compressed/acpi.c | 48 -
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/x86/boot/compressed/acpi.c b/arch/x86/boot/compressed/acpi.c
index 149795c..25019d4 100644
--- a/arch/x86/boot/compressed/acpi.c
+++ b/arch/x86/boot/compressed/acpi.c
@@ -21,30 +21,6 @@
struct mem_vector immovable_mem[MAX_NUMNODES*2];
/*
- * Max length of 64-bit hex address string is 19, prefix "0x" + 16 hex
- * digits, and '\0' for termination.
- */
-#define MAX_ADDR_LEN 19
-
-static acpi_physical_address get_cmdline_acpi_rsdp(void)
-{
- acpi_physical_address addr = 0;
-
-#ifdef CONFIG_KEXEC
- char val[MAX_ADDR_LEN] = { };
- int ret;
-
- ret = cmdline_find_option("acpi_rsdp", val, MAX_ADDR_LEN);
- if (ret < 0)
- return 0;
-
- if (kstrtoull(val, 16, &addr))
- return 0;
-#endif
- return addr;
-}
-
-/*
* Search EFI system tables for RSDP. If both ACPI_20_TABLE_GUID and
* ACPI_TABLE_GUID are found, take the former, which has more features.
*/
@@ -298,6 +274,30 @@ acpi_physical_address get_rsdp_addr(void)
}
#if defined(CONFIG_RANDOMIZE_BASE) && defined(CONFIG_MEMORY_HOTREMOVE)
+/*
+ * Max length of 64-bit hex address string is 19, prefix "0x" + 16 hex
+ * digits, and '\0' for termination.
+ */
+#define MAX_ADDR_LEN 19
+
+static acpi_physical_address get_cmdline_acpi_rsdp(void)
+{
+ acpi_physical_address addr = 0;
+
+#ifdef CONFIG_KEXEC
+ char val[MAX_ADDR_LEN] = { };
+ int ret;
+
+ ret = cmdline_find_option("acpi_rsdp", val, MAX_ADDR_LEN);
+ if (ret < 0)
+ return 0;
+
+ if (kstrtoull(val, 16, &addr))
+ return 0;
+#endif
+ return addr;
+}
+
/* Compute SRAT address from RSDP. */
static unsigned long get_acpi_srat_table(void)
{
--
1.8.3.1
Re: [PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()
On Sun, Sep 29, 2019 at 11:43:38PM +0900, Tetsuo Handa wrote: On 2019/09/29 22:54, Greg Kroah-Hartman wrote: From: Waiman Long [ Upstream commit 513e1073d52e55b8024b4f238a48de7587c64ccf ] Tetsuo Handa had reported he saw an incorrect "downgrading a read lock" warning right after a previous lockdep warning. It is likely that the previous warning turned off lock debugging causing the lockdep to have inconsistency states leading to the lock downgrade warning. Fix that by add a check for debug_locks at the beginning of __lock_downgrade(). Please drop "[PATCH 4.19 36/63] locking/lockdep: Add debug_locks check in __lock_downgrade()". We had a revert patch shown below in the past. We had a revert in the stable trees, but that revert was incorrect. Take a look at commit 513e1073d52e55 upstream, it patches __lock_set_class() (even though the subject line says __lock_downgrade()). So this is not a backporting error as the revert said it is, but is rather the intended location to be patched. If this is actually wrong, then it should be addressed upstream first. -- Thanks, Sasha
Re: [PATCH 2/4] rsicv: avoid sending a SIGTRAP to a user thread trapped in WARN()
On Sat, Sep 28, 2019 at 6:56 AM Christoph Hellwig wrote: > > Oh and s/rsicv/riscv/ in the subject, please. Oh! Thank you for finding this typo. I will correct it.
linux-next: build failure after merge of the powerpc tree
Hi all,
After merging the powerpc tree, today's linux-next build (powerpc64
allnoconfig) failed like this:
arch/powerpc/mm/book3s64/pgtable.c: In function 'flush_partition':
arch/powerpc/mm/book3s64/pgtable.c:216:3: error: implicit declaration of
function 'radix__flush_all_lpid_guest'; did you mean 'radix__flush_all_lpid'?
[-Werror=implicit-function-declaration]
216 | radix__flush_all_lpid_guest(lpid);
| ^~~
| radix__flush_all_lpid
Caused by commit
99161de3a283 ("powerpc/64s/radix: tidy up TLB flushing code")
radix__flush_all_lpid_guest() is only declared for CONFIG_PPC_RADIX_MMU
which is not set for this build.
I am not sure why this did not show up earlier (maybe a Kconfig
change?).
I added the following hack for today.
From: Stephen Rothwell
Date: Mon, 30 Sep 2019 10:09:17 +1000
Subject: [PATCH] powerpc/64s/radix: fix for "tidy up TLB flushing code" and
!CONFIG_PPC_RADIX_MMU
Signed-off-by: Stephen Rothwell
---
arch/powerpc/include/asm/book3s/64/tlbflush-radix.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
index 4ce795d30377..ca8db193ae38 100644
--- a/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
+++ b/arch/powerpc/include/asm/book3s/64/tlbflush-radix.h
@@ -35,6 +35,10 @@ static inline void radix__flush_all_lpid(unsigned int lpid)
{
WARN_ON(1);
}
+static inline void radix__flush_all_lpid_guest(unsigned int lpid)
+{
+ WARN_ON(1);
+}
#endif
extern void radix__flush_hugetlb_tlb_range(struct vm_area_struct *vma,
--
2.23.0.rc1
--
Cheers,
Stephen Rothwell
pgpGH1YpIi9UZ.pgp
Description: OpenPGP digital signature
Re: [GIT PULL][SECURITY] Kernel lockdown patches for v5.4
On Sat, 28 Sep 2019, Linus Torvalds wrote: > On Fri, Sep 27, 2019 at 11:19 AM Linus Torvalds > wrote: > > > > This is one of the pull requests that I have to go through commit by > > commit because of the history of this thing. > > > > And I've yet to empty my queue of all the _regular_ things that came > > in this merge window, so I haven't had time. > > I've emptied my queue (well, in the meantime I got new pull requests, > but what else is new..) and went through the security pulls yesterday > and this morning, and found nothing objectionable. > > So it's merged now. Thanks. Matthew has agreed to maintain this code now that it's merged. Matthew: please submit a maintainer entry for this. -- James Morris
Re: [PATCH] arm64: dts: rockchip: Fix usb-c on Hugsun X99 TV Box
On Sun, Sep 29, 2019 at 01:22:17PM +0200, Vicente Bergas wrote:
> On Sunday, September 29, 2019 5:22:30 AM CEST, Vivek Unune wrote:
> > Fix usb-c on X99 TV Box. Tested with armbian w/ kernel 5.3
> >
> > Signed-off-by: Vivek Unune
> > ---
> > arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > index 0d1f5f9a0de9..c133e8d64b2a 100644
> > --- a/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > +++ b/arch/arm64/boot/dts/rockchip/rk3399-hugsun-x99.dts
> > @@ -644,7 +644,7 @@
> > status = "okay";
> > u2phy0_host: host-port {
> > - phy-supply = <&vcc5v0_host>;
> > + phy-supply = <&vcc5v0_typec>;
> > status = "okay";
> > };
> > @@ -712,7 +712,7 @@
> > &usbdrd_dwc3_0 {
> > status = "okay";
> > - dr_mode = "otg";
> > + dr_mode = "host";
> > };
> > &usbdrd3_1 {
>
> Hi Vivek,
>
> which is the relationship of your patch and this commit:
>
> e1d9149e8389f1690cdd4e4056766dd26488a0fe
> arm64: dts: rockchip: Fix USB3 Type-C on rk3399-sapphire
>
> with respect to this other commit:
>
> c09b73cfac2a9317f1104169045c519c6021aa1d
> usb: dwc3: don't set gadget->is_otg flag
>
> ?
>
> I did not test reverting e1d9149e since c09b73cf was applied.
>
> Regards,
> Vicenç.
>
Hi Vicenç,
Indeed, I was motivated by e1d9149e ("arm64: dts: rockchip: Fix USB3
Type-C on rk3399-sapphire"). X99 TV box showed exact same symptoms
with usb-c port. After applying the fix, it worked.
I was not aware of c09b73cf ("usb: dwc3: don't set gadget->is_otg
flag") and it will be interesting to test it. This might render
my fix unecessary.
Thanks,
Vivek
hello
Hello My name is Joe Akaba I am a lawyer by profession. I wish to offer you the next of kin to my client. You will inherit the sum of ($8.5 Million) dollars my client left in the bank before his death. My client is a citizen of your country who died in auto crash with his wife and only son. I will be entitled with 50% of the total fund while 50% will be for you. Please contact my private email here for more details:joeakab...@gmail.com Many thanks in advance, Mr.Joe Akaba Hallo Mein Name ist Joe Akaba . Ich bin von Beruf Rechtsanwalt. Ich möchte Ihnen anbieten die nächsten Verwandten zu meinem Klienten. Sie erben die Summe von ($8.5 Millionen US-Dollar) Dollar, die mein Kunde vor seinem Tod in der Bank gelassen hat. Mein Mandant ist ein Staatsbürger Ihres Landes, der mit seiner Frau bei einem Autounfall ums Leben gekommen ist und nur Sohn. Ich werde mit 50% des Gesamtfonds berechtigt sein, während 50% sein für dich. Bitte kontaktieren Sie meine private E-Mail hier für weitere Informationen: joeakab...@gmail.com Vielen Dank im Voraus, Mr.Joe Akaba
Re: [PATCH 1/1] media: dvbsky: use a single mutex and state buffers for all R/W ops
This works very well for me.
(and please see unrelated comment below)
On 9/29/19 10:04 AM, Andrei Koshkosh wrote:
Signed-off-by: Andrei Koshkosh
---
drivers/media/usb/dvb-usb-v2/dvbsky.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index c41e10b..6a118a0 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -22,7 +22,6 @@ MODULE_PARM_DESC(disable_rc, "Disable inbuilt IR receiver.");
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
struct dvbsky_state {
- struct mutex stream_mutex;
u8 ibuf[DVBSKY_BUF_LEN];
u8 obuf[DVBSKY_BUF_LEN];
u8 last_lock;
@@ -61,16 +60,18 @@ static int dvbsky_stream_ctrl(struct dvb_usb_device *d, u8
onoff)
{
struct dvbsky_state *state = d_to_priv(d);
int ret;
- u8 obuf_pre[3] = { 0x37, 0, 0 };
- u8 obuf_post[3] = { 0x36, 3, 0 };
+ static u8 obuf_pre[3] = { 0x37, 0, 0 };
+ static u8 obuf_post[3] = { 0x36, 3, 0 };
- mutex_lock(&state->stream_mutex);
- ret = dvbsky_usb_generic_rw(d, obuf_pre, 3, NULL, 0);
+ mutex_lock(&d->usb_mutex);
+ memcpy(state->obuf, obuf_pre, 3);
+ ret = dvb_usbv2_generic_write_locked(d, state->obuf, 3);
if (!ret && onoff) {
msleep(20);
- ret = dvbsky_usb_generic_rw(d, obuf_post, 3, NULL, 0);
+ memcpy(state->obuf, obuf_post, 3);
+ ret = dvb_usbv2_generic_write_locked(d, state->obuf, 3);
}
- mutex_unlock(&state->stream_mutex);
+ mutex_unlock(&d->usb_mutex);
return ret;
}
@@ -599,7 +600,6 @@ static int dvbsky_init(struct dvb_usb_device *d)
if (ret)
return ret;
*/
commented-out code has call to non-existing function.
- mutex_init(&state->stream_mutex);
state->last_lock = 0;
Thanks,
Jan Pieter.
Re: [PATCH] dt-bindings: arm: rockchip: fix Theobroma-System board bindings
Am Dienstag, 17. September 2019, 10:34:53 CEST schrieb Heiko Stuebner: > The naming convention for the existing Theobroma boards is > soc-q7module-baseboard, so rk3399-puma-haikou and the in-kernel > devicetrees also follow that scheme. > > For some reason in the binding a wrong or outdated naming slipped > in which does not match the used devicetrees and makes the dt-schema > complain now. > > Fix this by using the names used in the wild by actual boards. > > Signed-off-by: Heiko Stuebner added a Fixes tag and applies as fix for 5.4
Re: [PATCH 4/6] arm64: dts: rockchip: Rename roc-pc with libretech notation
Hi Jagan,
Am Donnerstag, 19. September 2019, 07:28:20 CEST schrieb Jagan Teki:
> Though the ROC-PC is manufactured by firefly, it is co-designed
> by libretch like other Libretech computer boards from allwinner,
> amlogic does.
>
> So, it is always meaningful to keep maintain those vendors who
> are part of design participation so-that the linux mainline
> code will expose outside world who are the makers of such
> hardware prototypes.
>
> So, rename the existing rk3399-roc-pc.dts with libretch notation,
> rk3399-libretech-roc-rk3399-pc.dts
>
> Signed-off-by: Jagan Teki
> ---
> arch/arm64/boot/dts/rockchip/Makefile | 2 +-
> .../{rk3399-roc-pc.dts => rk3399-libretech-roc-rk3399-pc.dts} | 0
Somewhat "randomly" renaming files for "exposure" of the maker isn't the
way to go. Especially as the file name itself is merely a handle and not
meant for fame. The board filename should mainly enable developers to
hopefully the correct board file to use/change - and "rk3399-roc-pc"
is sufficiently unique to do that.
Similar to how the NanoPi boards do that.
And renames not only loose the history of changes but also in this case
the file is in the kernel since july 2018 - more than a year, so this might
actually affect the workflow of someone.
So I'd really expect an actual technical reason for a rename.
Heiko
> 2 files changed, 1 insertion(+), 1 deletion(-)
> rename arch/arm64/boot/dts/rockchip/{rk3399-roc-pc.dts =>
> rk3399-libretech-roc-rk3399-pc.dts} (100%)
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile
> b/arch/arm64/boot/dts/rockchip/Makefile
> index 1f18a9392d15..73c10ddb4300 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -21,12 +21,12 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-captain.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-khadas-edge-v.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-leez-p710.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-libretech-roc-rk3399-pc.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopc-t4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-m4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-nanopi-neo4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-orangepi.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-puma-haikou.dtb
> -dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-roc-pc.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock-pi-4.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rock960.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3399-rockpro64.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
> similarity index 100%
> rename from arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> rename to arch/arm64/boot/dts/rockchip/rk3399-libretech-roc-rk3399-pc.dts
>
Re: [PATCH 1/6] arm64: dts: rockchip: Fix rk3399-roc-pc pwm2 pin
Hi Jagan,
Am Donnerstag, 19. September 2019, 07:28:17 CEST schrieb Jagan Teki:
> ROC-PC is not able to boot linux console if PWM2_d is
> unattached to any pinctrl logic.
>
> To be precise the linux boot hang with last logs as,
> ...
> .
> [0.003367] Console: colour dummy device 80x25
> [0.003788] printk: console [tty0] enabled
> [0.004178] printk: bootconsole [uart8250] disabled
>
> In ROC-PC the PWM2_d pin is connected to LOG_DVS_PWM of
> VDD_LOG. So, for normal working operations this needs to
> active and pull-down.
>
> This patch fix, by attaching pinctrl active and pull-down
> the pwm2.
This looks highly dubious on first glance. The pwm subsystem nor
the Rockchip pwm driver do not do any pinctrl handling.
So I don't really see where that "active" pinctrl state is supposed
to come from.
Comparing with the pwm driver in the vendor tree I see that there
is such a state defined there. But that code there also looks strange
as that driver never again leaves this active state after entering it.
Also for example all the Gru devices run with quite a number of pwm-
regulators without needing additional fiddling with the pwm itself, so
I don't really see why that should be different here.
Heiko
>
> Signed-off-by: Jagan Teki
> ---
> arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> index 19f7732d728c..c53f3d571620 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3399-roc-pc.dts
> @@ -548,6 +548,8 @@
> };
>
> &pwm2 {
> + pinctrl-names = "active";
> + pinctrl-0 = <&pwm2_pin_pull_down>;
> status = "okay";
> };
>
>
Re: [PATCH] i2c: pca954x: Add property to skip disabling PCA954x MUX device
On 2019-09-29 12:36, Biwen Li wrote:
> On some Layerscape boards like LS2085ARDB and LS2088ARDB,
> input pull-up resistors on PCA954x MUX device are missing on board,
> So, if MUX are disabled after powered-on, input lines will float
> leading to incorrect functionality.
Hi!
Are you saying that the parent bus of the mux is relying on some
pull-ups inside the mux?
> Hence, PCA954x MUX device should never be turned-off after
> power-on.
>
> Add property to skip disabling PCA954x MUX device
> if device tree contains "i2c-mux-never-disable"
> for PCA954x device node.
>
> Errata ID: E-00013 on board LS2085ARDB and LS2088ARDB
> (Board revision found on Rev.B, Rev.C and Rev.D)
I think you should follow the example of the i2c-mux-gpio driver
and implement the idle-state property instead.
That is a lot more consistent, assuming it solves the problem
at hand?
>
> Signed-off-by: Biwen Li
> ---
> drivers/i2c/muxes/i2c-mux-pca954x.c | 33 +
> 1 file changed, 29 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/i2c/muxes/i2c-mux-pca954x.c
> b/drivers/i2c/muxes/i2c-mux-pca954x.c
> index 923aa3a5a3dc..ea8aca54d572 100644
> --- a/drivers/i2c/muxes/i2c-mux-pca954x.c
> +++ b/drivers/i2c/muxes/i2c-mux-pca954x.c
> @@ -93,6 +93,7 @@ struct pca954x {
> struct irq_domain *irq;
> unsigned int irq_mask;
> raw_spinlock_t lock;
> + u8 disable_mux; /* do not disable mux if val not 0 */
Awful number of negations there. The name is also backwards given that
a non-zero value means that the mux should *not* be disabled. I would
have reused the name from the binding.
bool never_disable;
A bit less confusing...
> };
>
> /* Provide specs for the PCA954x types we know about */
> @@ -258,6 +259,11 @@ static int pca954x_deselect_mux(struct i2c_mux_core
> *muxc, u32 chan)
> struct i2c_client *client = data->client;
> s8 idle_state;
>
> + if (data->disable_mux != 0) {
Please drop " != 0" and use the variable as a truth value. More
instances below...
> + data->last_chan = data->chip->nchans;
> + return pca954x_reg_write(muxc->parent, client,
> data->disable_mux);
> + }
> +
> idle_state = READ_ONCE(data->idle_state);
> if (idle_state >= 0)
> /* Set the mux back to a predetermined channel */
> @@ -462,16 +468,32 @@ static int pca954x_probe(struct i2c_client *client,
> }
> }
>
> + /* Errata ID E-00013 on board LS2088ARDB and LS2088ARDB:
> + * The point here is that you must not disable a mux if there
> + * are no pullups on the input or you mess up the I2C. This
> + * needs to be put into the DTS really as the kernel cannot
> + * know this otherwise.
> + */
> +
> + data->disable_mux = np &&
> + of_property_read_bool(np, "i2c-mux-never-disable") &&
i2c-mux-never-disable needs to be documented. However see above for my
point that you should do it like the i2c-mux-gpio driver. Any usage
of idle-state still needs to be documented for pca954x binding.
> + data->chip->muxtype == pca954x_ismux ?
> + data->chip->enable : 0;
Why do you not allow never-disable for switches?
Cheers,
Peter
> +
> /* Write the mux register at addr to verify
>* that the mux is in fact present. This also
>* initializes the mux to disconnected state.
>*/
> - if (i2c_smbus_write_byte(client, 0) < 0) {
> + if (i2c_smbus_write_byte(client, data->disable_mux) < 0) {
> dev_warn(dev, "probe failed\n");
> return -ENODEV;
> }
>
> - data->last_chan = 0; /* force the first selection */
> + if (data->disable_mux != 0)
> + data->last_chan = data->chip->nchans;
> + else
> + data->last_chan = 0; /* force the first selection
> */
> +
> data->idle_state = MUX_IDLE_AS_IS;
>
> idle_disconnect_dt = np &&
> @@ -531,8 +553,11 @@ static int pca954x_resume(struct device *dev)
> struct i2c_mux_core *muxc = i2c_get_clientdata(client);
> struct pca954x *data = i2c_mux_priv(muxc);
>
> - data->last_chan = 0;
> - return i2c_smbus_write_byte(client, 0);
> + if (data->disable_mux != 0)
> + data->last_chan = data->chip->nchans;
> + else
> + data->last_chan = 0;
> + return i2c_smbus_write_byte(client, data->disable_mux);
> }
> #endif
>
>
Re: linux-next: no release today
Hi Mark, On Mon, 16 Sep 2019 02:37:27 +0100 Mark Brown wrote: > > On Thu, Sep 05, 2019 at 04:02:37PM +1000, Stephen Rothwell wrote: > > > As I said yesterday, there will be no release today, or any day until > > September 30. > > I'm going to try to provide some builds for this week (16th-20th). > There may also be a build for the 15th depending on how much rebuilding > the rest of the trees is needed for the build I've got ongoing. I just want to say a big thank you for taking this on again. -- Cheers, Stephen Rothwell pgpKEXZ6_MbGs.pgp Description: OpenPGP digital signature
Re: [PATCH v2] perf tools: avoid sample_reg_masks being const + weak
On Fri, Sep 27, 2019 at 02:43:41PM -0700, Ian Rogers wrote:
> Being const + weak breaks with some compilers that constant-propagate
> from the weak symbol. This behavior is outside of the specification, but
> in LLVM is chosen to match GCC's behavior.
>
> LLVM's implementation was set in this patch:
> https://github.com/llvm/llvm-project/commit/f49573d1eedcf1e44893d5a062ac1b72c8419646
> A const + weak symbol is set to be weak_odr:
> https://llvm.org/docs/LangRef.html
> ODR is one definition rule, and given there is one constant definition
> constant-propagation is possible. It is possible to get this code to
> miscompile with LLVM when applying link time optimization. As compilers
> become more aggressive, this is likely to break in more instances.
>
> Move the definition of sample_reg_masks to the conditional part of
> perf_regs.h and guard usage with HAVE_PERF_REGS_SUPPORT. This avoids the
> weak symbol.
>
> Fix an issue when HAVE_PERF_REGS_SUPPORT isn't defined from patch v1.
>
> Signed-off-by: Ian Rogers
Acked-by: Jiri Olsa
thanks,
jirka
> ---
> tools/perf/util/parse-regs-options.c | 8 ++--
> tools/perf/util/perf_regs.c | 4
> tools/perf/util/perf_regs.h | 4 ++--
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/tools/perf/util/parse-regs-options.c
> b/tools/perf/util/parse-regs-options.c
> index ef46c2848808..e687497b3aac 100644
> --- a/tools/perf/util/parse-regs-options.c
> +++ b/tools/perf/util/parse-regs-options.c
> @@ -13,7 +13,7 @@ static int
> __parse_regs(const struct option *opt, const char *str, int unset, bool intr)
> {
> uint64_t *mode = (uint64_t *)opt->value;
> - const struct sample_reg *r;
> + const struct sample_reg *r = NULL;
> char *s, *os = NULL, *p;
> int ret = -1;
> uint64_t mask;
> @@ -46,19 +46,23 @@ __parse_regs(const struct option *opt, const char *str,
> int unset, bool intr)
>
> if (!strcmp(s, "?")) {
> fprintf(stderr, "available registers: ");
> +#ifdef HAVE_PERF_REGS_SUPPORT
> for (r = sample_reg_masks; r->name; r++) {
> if (r->mask & mask)
> fprintf(stderr, "%s ", r->name);
> }
> +#endif
> fputc('\n', stderr);
> /* just printing available regs */
> return -1;
> }
> +#ifdef HAVE_PERF_REGS_SUPPORT
> for (r = sample_reg_masks; r->name; r++) {
> if ((r->mask & mask) && !strcasecmp(s, r->name))
> break;
> }
> - if (!r->name) {
> +#endif
> + if (!r || !r->name) {
> ui__warning("Unknown register \"%s\", check man
> page or run \"perf record %s?\"\n",
> s, intr ? "-I" : "--user-regs=");
> goto error;
> diff --git a/tools/perf/util/perf_regs.c b/tools/perf/util/perf_regs.c
> index 2774cec1f15f..5ee47ae1509c 100644
> --- a/tools/perf/util/perf_regs.c
> +++ b/tools/perf/util/perf_regs.c
> @@ -3,10 +3,6 @@
> #include "perf_regs.h"
> #include "event.h"
>
> -const struct sample_reg __weak sample_reg_masks[] = {
> - SMPL_REG_END
> -};
> -
> int __weak arch_sdt_arg_parse_op(char *old_op __maybe_unused,
>char **new_op __maybe_unused)
> {
> diff --git a/tools/perf/util/perf_regs.h b/tools/perf/util/perf_regs.h
> index 47fe34e5f7d5..e014c2c038f4 100644
> --- a/tools/perf/util/perf_regs.h
> +++ b/tools/perf/util/perf_regs.h
> @@ -15,8 +15,6 @@ struct sample_reg {
> #define SMPL_REG2(n, b) { .name = #n, .mask = 3ULL << (b) }
> #define SMPL_REG_END { .name = NULL }
>
> -extern const struct sample_reg sample_reg_masks[];
> -
> enum {
> SDT_ARG_VALID = 0,
> SDT_ARG_SKIP,
> @@ -27,6 +25,8 @@ uint64_t arch__intr_reg_mask(void);
> uint64_t arch__user_reg_mask(void);
>
> #ifdef HAVE_PERF_REGS_SUPPORT
> +extern const struct sample_reg sample_reg_masks[];
> +
> #include
>
> #define DWARF_MINIMAL_REGS ((1ULL << PERF_REG_IP) | (1ULL << PERF_REG_SP))
> --
> 2.23.0.444.g18eeb5a265-goog
>
[GIT PULL] tracing: A few minor fix ups
Linus,
A few more tracing fixes:
- Fixed a buffer overflow by checking nr_args correctly in probes
- Fixed a warning that is reported by clang
- Fixed a possible memory leak in error path of filter processing
- Fixed the selftest that checks for failures, but wasn't failing
- Minor clean up on call site output of a memory trace event
Please pull the latest trace-v5.4-3 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
trace-v5.4-3
Tag SHA1: 6bd391b341525bebf22f3fbbaea7ffb35f7cccb6
Head SHA1: 8ed4889eb83179dbc9a105cfed65cc42ecb61097
Changbin Du (1):
mm, tracing: Print symbol name for call_site in trace events
Masami Hiramatsu (1):
tracing/probe: Fix to check the difference of nr_args before adding probe
Nathan Chancellor (1):
tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN macro
Navid Emamdoost (1):
tracing: Have error path in predicate_parse() free its allocated memory
Steven Rostedt (VMware) (1):
selftests/ftrace: Fix same probe error test
include/trace/events/kmem.h | 7 ---
kernel/trace/trace.h | 10 +-
kernel/trace/trace_events_filter.c | 6 --
kernel/trace/trace_probe.c | 16
.../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 2 +-
5 files changed, 30 insertions(+), 11 deletions(-)
---
diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index eb57e3037deb..69e8bb8963db 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -35,8 +35,8 @@ DECLARE_EVENT_CLASS(kmem_alloc,
__entry->gfp_flags = gfp_flags;
),
- TP_printk("call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu
gfp_flags=%s",
- __entry->call_site,
+ TP_printk("call_site=%pS ptr=%p bytes_req=%zu bytes_alloc=%zu
gfp_flags=%s",
+ (void *)__entry->call_site,
__entry->ptr,
__entry->bytes_req,
__entry->bytes_alloc,
@@ -131,7 +131,8 @@ DECLARE_EVENT_CLASS(kmem_free,
__entry->ptr= ptr;
),
- TP_printk("call_site=%lx ptr=%p", __entry->call_site, __entry->ptr)
+ TP_printk("call_site=%pS ptr=%p",
+ (void *)__entry->call_site, __entry->ptr)
);
DEFINE_EVENT(kmem_free, kfree,
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 26b0a08f3c7d..f801d154ff6a 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -365,11 +365,11 @@ static inline struct trace_array *top_trace_array(void)
__builtin_types_compatible_p(typeof(var), type *)
#undef IF_ASSIGN
-#define IF_ASSIGN(var, entry, etype, id) \
- if (FTRACE_CMP_TYPE(var, etype)) { \
- var = (typeof(var))(entry); \
- WARN_ON(id && (entry)->type != id); \
- break; \
+#define IF_ASSIGN(var, entry, etype, id) \
+ if (FTRACE_CMP_TYPE(var, etype)) { \
+ var = (typeof(var))(entry); \
+ WARN_ON(id != 0 && (entry)->type != id);\
+ break; \
}
/* Will cause compile errors if type is not found. */
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index c773b8fb270c..c9a74f82b14a 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -452,8 +452,10 @@ predicate_parse(const char *str, int nr_parens, int
nr_preds,
switch (*next) {
case '(': /* #2 */
- if (top - op_stack > nr_parens)
- return ERR_PTR(-EINVAL);
+ if (top - op_stack > nr_parens) {
+ ret = -EINVAL;
+ goto out_free;
+ }
*(++top) = invert;
continue;
case '!': /* #3 */
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index baf58a3612c0..905b10af5d5c 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -178,6 +178,16 @@ void __trace_probe_log_err(int offset, int err_type)
if (!command)
return;
+ if (trace_probe_log.index >= trace_probe_log.argc) {
+ /**
+* Set the error position is next to the last arg + space.
+* Note that len includes the terminal null and the cursor
+* appaers at pos + 1.
+*/
+ pos = len;
+ offset = 0;
+ }
+
/*
[PATCH] arm64: tegra: only map accessible sysram
Most of the SysRAM is secure and only accessible by TF-A.
Don't map this inaccessible memory in kernel. Only map pages
used by bpmp driver.
Signed-off-by: Mian Yousaf Kaukab
---
Only tegra186 is tested. Tested on Jetson TX2.
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 14 +++---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 14 +++---
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
index 47cd831fcf44..a861f46125fd 100644
--- a/arch/arm64/boot/dts/nvidia/tegra186.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra186.dtsi
@@ -1174,23 +1174,23 @@
power-domains = <&bpmp TEGRA186_POWER_DOMAIN_GPU>;
};
- sysram@3000 {
+ sysram@3004e000 {
compatible = "nvidia,tegra186-sysram", "mmio-sram";
- reg = <0x0 0x3000 0x0 0x5>;
+ reg = <0x0 0x3004e000 0x0 0x2000>;
#address-cells = <2>;
#size-cells = <2>;
- ranges = <0 0x0 0x0 0x3000 0x0 0x5>;
+ ranges = <0 0x0 0x0 0x3004e000 0x0 0x2000>;
- cpu_bpmp_tx: shmem@4e000 {
+ cpu_bpmp_tx: shmem@e000 {
compatible = "nvidia,tegra186-bpmp-shmem";
- reg = <0x0 0x4e000 0x0 0x1000>;
+ reg = <0x0 0x0 0x0 0x1000>;
label = "cpu-bpmp-tx";
pool;
};
- cpu_bpmp_rx: shmem@4f000 {
+ cpu_bpmp_rx: shmem@f000 {
compatible = "nvidia,tegra186-bpmp-shmem";
- reg = <0x0 0x4f000 0x0 0x1000>;
+ reg = <0x0 0x1000 0x0 0x1000>;
label = "cpu-bpmp-rx";
pool;
};
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 3c0cf54f0aab..98b9399d6b7f 100644
--- a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
@@ -1430,23 +1430,23 @@
0x8200 0x0 0x4000 0x1f 0x4000 0x0
0xc000>; /* non-prefetchable memory (3GB) */
};
- sysram@4000 {
+ sysram@4004e000 {
compatible = "nvidia,tegra194-sysram", "mmio-sram";
- reg = <0x0 0x4000 0x0 0x5>;
+ reg = <0x0 0x4004e000 0x0 0x2000>;
#address-cells = <1>;
#size-cells = <1>;
- ranges = <0x0 0x0 0x4000 0x5>;
+ ranges = <0x0 0x0 0x4004e000 0x2000>;
- cpu_bpmp_tx: shmem@4e000 {
+ cpu_bpmp_tx: shmem@e000 {
compatible = "nvidia,tegra194-bpmp-shmem";
- reg = <0x4e000 0x1000>;
+ reg = <0x0 0x1000>;
label = "cpu-bpmp-tx";
pool;
};
- cpu_bpmp_rx: shmem@4f000 {
+ cpu_bpmp_rx: shmem@f000 {
compatible = "nvidia,tegra194-bpmp-shmem";
- reg = <0x4f000 0x1000>;
+ reg = <0x1000 0x1000>;
label = "cpu-bpmp-rx";
pool;
};
--
2.16.4
[for-linus][PATCH 1/5] tracing/probe: Fix to check the difference of nr_args before adding probe
From: Masami Hiramatsu
Steven reported that a test triggered:
==
BUG: KASAN: slab-out-of-bounds in trace_kprobe_create+0xa9e/0xe40
Read of size 8 at addr 8880c4f25a48 by task ftracetest/4798
CPU: 2 PID: 4798 Comm: ftracetest Not tainted 5.3.0-rc6-test+ #30
Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03
07/14/2016
Call Trace:
dump_stack+0x7c/0xc0
? trace_kprobe_create+0xa9e/0xe40
print_address_description+0x6c/0x332
? trace_kprobe_create+0xa9e/0xe40
? trace_kprobe_create+0xa9e/0xe40
__kasan_report.cold.6+0x1a/0x3b
? trace_kprobe_create+0xa9e/0xe40
kasan_report+0xe/0x12
trace_kprobe_create+0xa9e/0xe40
? print_kprobe_event+0x280/0x280
? match_held_lock+0x1b/0x240
? find_held_lock+0xac/0xd0
? fs_reclaim_release.part.112+0x5/0x20
? lock_downgrade+0x350/0x350
? kasan_unpoison_shadow+0x30/0x40
? __kasan_kmalloc.constprop.6+0xc1/0xd0
? trace_kprobe_create+0xe40/0xe40
? trace_kprobe_create+0xe40/0xe40
create_or_delete_trace_kprobe+0x2e/0x60
trace_run_command+0xc3/0xe0
? trace_panic_handler+0x20/0x20
? kasan_unpoison_shadow+0x30/0x40
trace_parse_run_command+0xdc/0x163
vfs_write+0xe1/0x240
ksys_write+0xba/0x150
? __ia32_sys_read+0x50/0x50
? tracer_hardirqs_on+0x61/0x180
? trace_hardirqs_off_caller+0x43/0x110
? mark_held_locks+0x29/0xa0
? do_syscall_64+0x14/0x260
do_syscall_64+0x68/0x260
Fix to check the difference of nr_args before adding probe
on existing probes. This also may set the error log index
bigger than the number of command parameters. In that case
it sets the error position is next to the last parameter.
Link:
http://lkml.kernel.org/r/156966474783.3478.13217501608215769150.stgit@devnote2
Fixes: ca89bc071d5e ("tracing/kprobe: Add multi-probe per event support")
Reported-by: Steven Rostedt (VMware)
Signed-off-by: Masami Hiramatsu
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_probe.c | 16
1 file changed, 16 insertions(+)
diff --git a/kernel/trace/trace_probe.c b/kernel/trace/trace_probe.c
index baf58a3612c0..905b10af5d5c 100644
--- a/kernel/trace/trace_probe.c
+++ b/kernel/trace/trace_probe.c
@@ -178,6 +178,16 @@ void __trace_probe_log_err(int offset, int err_type)
if (!command)
return;
+ if (trace_probe_log.index >= trace_probe_log.argc) {
+ /**
+* Set the error position is next to the last arg + space.
+* Note that len includes the terminal null and the cursor
+* appaers at pos + 1.
+*/
+ pos = len;
+ offset = 0;
+ }
+
/* And make a command string from argv array */
p = command;
for (i = 0; i < trace_probe_log.argc; i++) {
@@ -1084,6 +1094,12 @@ int trace_probe_compare_arg_type(struct trace_probe *a,
struct trace_probe *b)
{
int i;
+ /* In case of more arguments */
+ if (a->nr_args < b->nr_args)
+ return a->nr_args + 1;
+ if (a->nr_args > b->nr_args)
+ return b->nr_args + 1;
+
for (i = 0; i < a->nr_args; i++) {
if ((b->nr_args <= i) ||
((a->args[i].type != b->args[i].type) ||
--
2.20.1
[for-linus][PATCH 3/5] tracing: Have error path in predicate_parse() free its allocated memory
From: Navid Emamdoost
In predicate_parse, there is an error path that is not going to
out_free instead it returns directly which leads to a memory leak.
Link: http://lkml.kernel.org/r/20190920225800.3870-1-navid.emamdo...@gmail.com
Signed-off-by: Navid Emamdoost
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace_events_filter.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/kernel/trace/trace_events_filter.c
b/kernel/trace/trace_events_filter.c
index c773b8fb270c..c9a74f82b14a 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -452,8 +452,10 @@ predicate_parse(const char *str, int nr_parens, int
nr_preds,
switch (*next) {
case '(': /* #2 */
- if (top - op_stack > nr_parens)
- return ERR_PTR(-EINVAL);
+ if (top - op_stack > nr_parens) {
+ ret = -EINVAL;
+ goto out_free;
+ }
*(++top) = invert;
continue;
case '!': /* #3 */
--
2.20.1
[for-linus][PATCH 4/5] mm, tracing: Print symbol name for call_site in trace events
From: Changbin Du
To improve the readability of raw slab trace points, print the call_site ip
using '%pS'. Then we can grep events with function names.
[002] 808.188897: kmem_cache_free: call_site=putname+0x47/0x50
ptr=cef40c80
[002] 808.188898: kfree: call_site=security_cred_free+0x42/0x50
ptr=62400820
[002] 808.188904: kmem_cache_free: call_site=put_cred_rcu+0x88/0xa0
ptr=58d74ef8
[002] 808.188913: kmem_cache_alloc: call_site=prepare_creds+0x26/0x100
ptr=58d74ef8 bytes_req=168 bytes_alloc=576 gfp_flags=GFP_KERNEL
[002] 808.188917: kmalloc: call_site=security_prepare_creds+0x77/0xa0
ptr=62400820 bytes_req=8 bytes_alloc=336 gfp_flags=GFP_KERNEL|__GFP_ZERO
[002] 808.188920: kmem_cache_alloc: call_site=getname_flags+0x4f/0x1e0
ptr=cef40c80 bytes_req=4096 bytes_alloc=4480 gfp_flags=GFP_KERNEL
[002] 808.188925: kmem_cache_free: call_site=putname+0x47/0x50
ptr=cef40c80
[002] 808.188926: kfree: call_site=security_cred_free+0x42/0x50
ptr=62400820
[002] 808.188931: kmem_cache_free: call_site=put_cred_rcu+0x88/0xa0
ptr=58d74ef8
Link: http://lkml.kernel.org/r/20190914103215.23301-1-changbin...@gmail.com
Signed-off-by: Changbin Du
Signed-off-by: Steven Rostedt (VMware)
---
include/trace/events/kmem.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/trace/events/kmem.h b/include/trace/events/kmem.h
index eb57e3037deb..69e8bb8963db 100644
--- a/include/trace/events/kmem.h
+++ b/include/trace/events/kmem.h
@@ -35,8 +35,8 @@ DECLARE_EVENT_CLASS(kmem_alloc,
__entry->gfp_flags = gfp_flags;
),
- TP_printk("call_site=%lx ptr=%p bytes_req=%zu bytes_alloc=%zu
gfp_flags=%s",
- __entry->call_site,
+ TP_printk("call_site=%pS ptr=%p bytes_req=%zu bytes_alloc=%zu
gfp_flags=%s",
+ (void *)__entry->call_site,
__entry->ptr,
__entry->bytes_req,
__entry->bytes_alloc,
@@ -131,7 +131,8 @@ DECLARE_EVENT_CLASS(kmem_free,
__entry->ptr= ptr;
),
- TP_printk("call_site=%lx ptr=%p", __entry->call_site, __entry->ptr)
+ TP_printk("call_site=%pS ptr=%p",
+ (void *)__entry->call_site, __entry->ptr)
);
DEFINE_EVENT(kmem_free, kfree,
--
2.20.1
[for-linus][PATCH 0/5] tracing: Minor fixes for the last pull request
Some final fix ups that will be sent to Linus shortly. Changbin Du (1): mm, tracing: Print symbol name for call_site in trace events Masami Hiramatsu (1): tracing/probe: Fix to check the difference of nr_args before adding probe Nathan Chancellor (1): tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN macro Navid Emamdoost (1): tracing: Have error path in predicate_parse() free its allocated memory Steven Rostedt (VMware) (1): selftests/ftrace: Fix same probe error test include/trace/events/kmem.h | 7 --- kernel/trace/trace.h | 10 +- kernel/trace/trace_events_filter.c | 6 -- kernel/trace/trace_probe.c | 16 .../ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 2 +- 5 files changed, 30 insertions(+), 11 deletions(-)
[for-linus][PATCH 2/5] tracing: Fix clang -Wint-in-bool-context warnings in IF_ASSIGN macro
From: Nathan Chancellor
After r372664 in clang, the IF_ASSIGN macro causes a couple hundred
warnings along the lines of:
kernel/trace/trace_output.c:1331:2: warning: converting the enum
constant to a boolean [-Wint-in-bool-context]
kernel/trace/trace.h:409:3: note: expanded from macro
'trace_assign_type'
IF_ASSIGN(var, ent, struct ftrace_graph_ret_entry,
^
kernel/trace/trace.h:371:14: note: expanded from macro 'IF_ASSIGN'
WARN_ON(id && (entry)->type != id); \
^
264 warnings generated.
This warning can catch issues with constructs like:
if (state == A || B)
where the developer really meant:
if (state == A || state == B)
This is currently the only occurrence of the warning in the kernel
tree across defconfig, allyesconfig, allmodconfig for arm32, arm64,
and x86_64. Add the implicit '!= 0' to the WARN_ON statement to fix
the warnings and find potential issues in the future.
Link:
https://github.com/llvm/llvm-project/commit/28b38c277a2941e9e891b2db30652cfd962f070b
Link: https://github.com/ClangBuiltLinux/linux/issues/686
Link: http://lkml.kernel.org/r/20190926162258.466321-1-natechancel...@gmail.com
Reviewed-by: Nick Desaulniers
Signed-off-by: Nathan Chancellor
Signed-off-by: Steven Rostedt (VMware)
---
kernel/trace/trace.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 26b0a08f3c7d..f801d154ff6a 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -365,11 +365,11 @@ static inline struct trace_array *top_trace_array(void)
__builtin_types_compatible_p(typeof(var), type *)
#undef IF_ASSIGN
-#define IF_ASSIGN(var, entry, etype, id) \
- if (FTRACE_CMP_TYPE(var, etype)) { \
- var = (typeof(var))(entry); \
- WARN_ON(id && (entry)->type != id); \
- break; \
+#define IF_ASSIGN(var, entry, etype, id) \
+ if (FTRACE_CMP_TYPE(var, etype)) { \
+ var = (typeof(var))(entry); \
+ WARN_ON(id != 0 && (entry)->type != id);\
+ break; \
}
/* Will cause compile errors if type is not found. */
--
2.20.1
[for-linus][PATCH 5/5] selftests/ftrace: Fix same probe error test
From: "Steven Rostedt (VMware)"
The "same probe" selftest that tests that adding the same probe fails
doesn't add the same probe and passes, which fails the test.
Fixes: b78b94b82122 ("selftests/ftrace: Update kprobe event error testcase")
Signed-off-by: Steven Rostedt (VMware)
---
.../selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
index 8a4025e912cb..ef1e9bafb098 100644
--- a/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
+++ b/tools/testing/selftests/ftrace/test.d/kprobe/kprobe_syntax_errors.tc
@@ -95,7 +95,7 @@ echo 'p:kprobes/testevent _do_fork abcd=\1' > kprobe_events
check_error 'p:kprobes/testevent _do_fork ^bcd=\1' # DIFF_ARG_TYPE
check_error 'p:kprobes/testevent _do_fork ^abcd=\1:u8' # DIFF_ARG_TYPE
check_error 'p:kprobes/testevent _do_fork ^abcd=\"foo"'# DIFF_ARG_TYPE
-check_error '^p:kprobes/testevent _do_fork'# SAME_PROBE
+check_error '^p:kprobes/testevent _do_fork abcd=\1'# SAME_PROBE
fi
exit 0
--
2.20.1
[PATCH v2 4/6] media: cedrus: Detect first slice of a frame
When codec supports multiple slices in one frame, VPU has to know when
first slice of each frame is being processed, presumably to correctly
clear/set data in auxiliary buffers.
Add first_slice field to cedrus_run structure and set it according to
timestamps of capture and output buffers. If timestamps are different,
it's first slice and viceversa.
Signed-off-by: Jernej Skrabec
---
drivers/staging/media/sunxi/cedrus/cedrus.h | 1 +
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus.h
b/drivers/staging/media/sunxi/cedrus/cedrus.h
index 2f017a651848..32cb38e541c6 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus.h
+++ b/drivers/staging/media/sunxi/cedrus/cedrus.h
@@ -70,6 +70,7 @@ struct cedrus_mpeg2_run {
struct cedrus_run {
struct vb2_v4l2_buffer *src;
struct vb2_v4l2_buffer *dst;
+ bool first_slice;
union {
struct cedrus_h264_run h264;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index 56ca4c9ad01c..e49c3396ca4d 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -31,6 +31,8 @@ void cedrus_device_run(void *priv)
run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+ run.first_slice = !run.dst->vb2_buf.copied_timestamp ||
+ run.src->vb2_buf.timestamp != run.dst->vb2_buf.timestamp;
/* Apply request(s) controls if needed. */
src_req = run.src->vb2_buf.req_obj.req;
--
2.23.0
[PATCH v2 3/6] media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers
These helpers are used by stateless codecs when they support multiple
slices per frame and hold capture buffer flag is set. It's expected that
all such codecs will use this code.
Signed-off-by: Jernej Skrabec
---
drivers/media/v4l2-core/v4l2-mem2mem.c | 35 ++
include/media/v4l2-mem2mem.h | 4 +++
2 files changed, 39 insertions(+)
diff --git a/drivers/media/v4l2-core/v4l2-mem2mem.c
b/drivers/media/v4l2-core/v4l2-mem2mem.c
index 19937dd3c6f6..2677a07e4c9b 100644
--- a/drivers/media/v4l2-core/v4l2-mem2mem.c
+++ b/drivers/media/v4l2-core/v4l2-mem2mem.c
@@ -1154,6 +1154,41 @@ int v4l2_m2m_ioctl_try_decoder_cmd(struct file *file,
void *fh,
}
EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_try_decoder_cmd);
+int v4l2_m2m_ioctl_stateless_try_decoder_cmd(struct file *file, void *fh,
+struct v4l2_decoder_cmd *dc)
+{
+ if (dc->cmd != V4L2_DEC_CMD_FLUSH)
+ return -EINVAL;
+
+ dc->flags = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_stateless_try_decoder_cmd);
+
+int v4l2_m2m_ioctl_stateless_decoder_cmd(struct file *file, void *priv,
+struct v4l2_decoder_cmd *dc)
+{
+ struct v4l2_fh *fh = file->private_data;
+ struct vb2_v4l2_buffer *out_vb, *cap_vb;
+ int ret;
+
+ ret = v4l2_m2m_ioctl_stateless_try_decoder_cmd(file, priv, dc);
+ if (ret < 0)
+ return ret;
+
+ out_vb = v4l2_m2m_last_src_buf(fh->m2m_ctx);
+ cap_vb = v4l2_m2m_last_dst_buf(fh->m2m_ctx);
+
+ if (out_vb)
+ out_vb->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
+ else if (cap_vb && cap_vb->is_held)
+ v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(v4l2_m2m_ioctl_stateless_decoder_cmd);
+
/*
* v4l2_file_operations helpers. It is assumed here same lock is used
* for the output and the capture buffer queue.
diff --git a/include/media/v4l2-mem2mem.h b/include/media/v4l2-mem2mem.h
index c9fa96c8eed1..8ae2f56c7fa3 100644
--- a/include/media/v4l2-mem2mem.h
+++ b/include/media/v4l2-mem2mem.h
@@ -714,6 +714,10 @@ int v4l2_m2m_ioctl_try_encoder_cmd(struct file *file, void
*fh,
struct v4l2_encoder_cmd *ec);
int v4l2_m2m_ioctl_try_decoder_cmd(struct file *file, void *fh,
struct v4l2_decoder_cmd *dc);
+int v4l2_m2m_ioctl_stateless_try_decoder_cmd(struct file *file, void *fh,
+struct v4l2_decoder_cmd *dc);
+int v4l2_m2m_ioctl_stateless_decoder_cmd(struct file *file, void *priv,
+struct v4l2_decoder_cmd *dc);
int v4l2_m2m_fop_mmap(struct file *file, struct vm_area_struct *vma);
__poll_t v4l2_m2m_fop_poll(struct file *file, poll_table *wait);
--
2.23.0
[PATCH v2 6/6] media: cedrus: Add support for holding capture buffer
When frame contains multiple slices and driver works in slice mode, it's
more efficient to hold capture buffer in queue until all slices of a
same frame are decoded.
Add support for that to Cedrus driver by exposing and implementing
V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability.
Signed-off-by: Jernej Skrabec
---
drivers/staging/media/sunxi/cedrus/cedrus_dec.c | 9 +
drivers/staging/media/sunxi/cedrus/cedrus_hw.c| 8 +---
drivers/staging/media/sunxi/cedrus/cedrus_video.c | 14 ++
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
index e49c3396ca4d..67f7d4326fc1 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_dec.c
@@ -31,6 +31,14 @@ void cedrus_device_run(void *priv)
run.src = v4l2_m2m_next_src_buf(ctx->fh.m2m_ctx);
run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+
+ if (v4l2_m2m_release_capture_buf(run.src, run.dst)) {
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(run.dst, VB2_BUF_STATE_DONE);
+ run.dst = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
+ }
+ run.dst->is_held = run.src->flags & V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
+
run.first_slice = !run.dst->vb2_buf.copied_timestamp ||
run.src->vb2_buf.timestamp != run.dst->vb2_buf.timestamp;
@@ -46,6 +54,7 @@ void cedrus_device_run(void *priv)
V4L2_CID_MPEG_VIDEO_MPEG2_SLICE_PARAMS);
run.mpeg2.quantization = cedrus_find_control_data(ctx,
V4L2_CID_MPEG_VIDEO_MPEG2_QUANTIZATION);
+ run.dst->is_held = false;
break;
case V4L2_PIX_FMT_H264_SLICE:
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
index fc8579b90dab..b466041c25db 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_hw.c
@@ -122,7 +122,7 @@ static irqreturn_t cedrus_irq(int irq, void *data)
dev->dec_ops[ctx->current_codec]->irq_clear(ctx);
src_buf = v4l2_m2m_src_buf_remove(ctx->fh.m2m_ctx);
- dst_buf = v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
if (!src_buf || !dst_buf) {
v4l2_err(&dev->v4l2_dev,
@@ -136,8 +136,10 @@ static irqreturn_t cedrus_irq(int irq, void *data)
state = VB2_BUF_STATE_DONE;
v4l2_m2m_buf_done(src_buf, state);
- v4l2_m2m_buf_done(dst_buf, state);
-
+ if (!dst_buf->is_held) {
+ v4l2_m2m_dst_buf_remove(ctx->fh.m2m_ctx);
+ v4l2_m2m_buf_done(dst_buf, state);
+ }
v4l2_m2m_job_finish(ctx->dev->m2m_dev, ctx->fh.m2m_ctx);
return IRQ_HANDLED;
diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
index 3ec3a2db790c..82198b2bb081 100644
--- a/drivers/staging/media/sunxi/cedrus/cedrus_video.c
+++ b/drivers/staging/media/sunxi/cedrus/cedrus_video.c
@@ -303,6 +303,17 @@ static int cedrus_s_fmt_vid_out(struct file *file, void
*priv,
ctx->src_fmt = f->fmt.pix;
+ switch (ctx->src_fmt.pixelformat) {
+ case V4L2_PIX_FMT_H264_SLICE:
+ vq->subsystem_flags |=
+ VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
+ break;
+ default:
+ vq->subsystem_flags &=
+ (u32)~VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF;
+ break;
+ }
+
/* Propagate colorspace information to capture. */
ctx->dst_fmt.colorspace = f->fmt.pix.colorspace;
ctx->dst_fmt.xfer_func = f->fmt.pix.xfer_func;
@@ -336,6 +347,9 @@ const struct v4l2_ioctl_ops cedrus_ioctl_ops = {
.vidioc_streamon= v4l2_m2m_ioctl_streamon,
.vidioc_streamoff = v4l2_m2m_ioctl_streamoff,
+ .vidioc_try_decoder_cmd =
v4l2_m2m_ioctl_stateless_try_decoder_cmd,
+ .vidioc_decoder_cmd = v4l2_m2m_ioctl_stateless_decoder_cmd,
+
.vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
.vidioc_unsubscribe_event = v4l2_event_unsubscribe,
};
--
2.23.0
[PATCH v2 2/6] videodev2.h: add V4L2_DEC_CMD_FLUSH
From: Hans Verkuil
Add this new V4L2_DEC_CMD_FLUSH decoder command and document it.
Reviewed-by: Boris Brezillon
Reviewed-by: Alexandre Courbot
Signed-off-by: Hans Verkuil
[Adjusted description]
Signed-off-by: Jernej Skrabec
---
Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +-
Documentation/media/videodev2.h.rst.exceptions | 1 +
include/uapi/linux/videodev2.h | 1 +
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
index 57f0066f4cff..f1a504836f31 100644
--- a/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
+++ b/Documentation/media/uapi/v4l/vidioc-decoder-cmd.rst
@@ -208,7 +208,15 @@ introduced in Linux 3.3. They are, however, mandatory for
stateful mem2mem decod
been started yet, the driver will return an ``EPERM`` error code. When
the decoder is already running, this command does nothing. No
flags are defined for this command.
-
+* - ``V4L2_DEC_CMD_FLUSH``
+ - 4
+ - Flush any held capture buffers. Only valid for stateless decoders.
+ This command is typically used when the application reached the
+ end of the stream and the last output buffer had the
+ ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag set. This would prevent
+ dequeueing the capture buffer containing the last decoded frame.
+ So this command can be used to explicitly flush that final decoded
+ frame. This command does nothing if there are no held capture buffers.
Return Value
diff --git a/Documentation/media/videodev2.h.rst.exceptions
b/Documentation/media/videodev2.h.rst.exceptions
index adeb6b7a15cb..a79028e4d929 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -434,6 +434,7 @@ replace define V4L2_DEC_CMD_START decoder-cmds
replace define V4L2_DEC_CMD_STOP decoder-cmds
replace define V4L2_DEC_CMD_PAUSE decoder-cmds
replace define V4L2_DEC_CMD_RESUME decoder-cmds
+replace define V4L2_DEC_CMD_FLUSH decoder-cmds
replace define V4L2_DEC_CMD_START_MUTE_AUDIO decoder-cmds
replace define V4L2_DEC_CMD_PAUSE_TO_BLACK decoder-cmds
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 4fa9f543742d..91a79e16089c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1978,6 +1978,7 @@ struct v4l2_encoder_cmd {
#define V4L2_DEC_CMD_STOP(1)
#define V4L2_DEC_CMD_PAUSE (2)
#define V4L2_DEC_CMD_RESUME (3)
+#define V4L2_DEC_CMD_FLUSH (4)
/* Flags for V4L2_DEC_CMD_START */
#define V4L2_DEC_CMD_START_MUTE_AUDIO (1 << 0)
--
2.23.0
[PATCH v2 1/6] vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF
From: Hans Verkuil
This patch adds support for the V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF flag.
It also adds a new V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF capability and
a v4l2_m2m_release_capture_buf() helper function.
Drivers should set vb2_queue->subsystem_flags to
VB2_V4L2_FL_SUPPORTS_M2M_HOLD_CAPTURE_BUF to indicate support for this flag.
The device_run() function should look like this:
if (v4l2_m2m_release_capture_buf(out_vb, cap_vb)) {
v4l2_m2m_dst_buf_remove(m2m_ctx);
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
cap_vb = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
}
cap_vb->is_held = out_vb->flags & V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
...
v4l2_m2m_buf_done(out_vb, VB2_BUF_STATE_DONE);
if (!cap_vb->is_held) {
v4l2_m2m_dst_buf_remove(m2m_ctx);
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
}
In order to handle the corner case where V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF
is always set for the output buffer, and you reached the last frame (so no
new output buffer will be queued with a new timestamp), the driver must
implement support for the V4L2_DEC_CMD_FLUSH command, and that should do:
struct vb2_v4l2_buffer *out_vb = v4l2_m2m_last_src_buf(m2m_ctx);
struct vb2_v4l2_buffer *cap_vb = v4l2_m2m_last_dst_buf(m2m_ctx);
if (out_vb)
out_vb->flags &= ~V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF;
else if (cap_vb && cap_vb->is_held)
v4l2_m2m_buf_done(cap_vb, VB2_BUF_STATE_DONE);
For formats that do not support slicing (e.g. VP8), the FLUSH command
just does nothing.
Signed-off-by: Hans Verkuil
Tested-by: Boris Brezillon
Reviewed-by: Boris Brezillon
[Adjust example code]
Signed-off-by: Jernej Skrabec
---
Documentation/media/uapi/v4l/buffer.rst | 13 ++
.../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++
.../media/common/videobuf2/videobuf2-v4l2.c | 8 +++-
include/media/v4l2-mem2mem.h | 42 +++
include/media/videobuf2-core.h| 3 ++
include/media/videobuf2-v4l2.h| 5 +++
include/uapi/linux/videodev2.h| 13 +++---
7 files changed, 84 insertions(+), 6 deletions(-)
diff --git a/Documentation/media/uapi/v4l/buffer.rst
b/Documentation/media/uapi/v4l/buffer.rst
index 1cbd9cde57f3..afb03906ead9 100644
--- a/Documentation/media/uapi/v4l/buffer.rst
+++ b/Documentation/media/uapi/v4l/buffer.rst
@@ -607,6 +607,19 @@ Buffer Flags
applications shall use this flag for output buffers if the data in
this buffer has not been created by the CPU but by some
DMA-capable unit, in which case caches have not been used.
+* .. _`V4L2-BUF-FLAG-M2M-HOLD-CAPTURE-BUF`:
+
+ - ``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF``
+ - 0x0200
+ - Only valid if ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF`` is
+set. It is typically used with stateless decoders where multiple
+ output buffers each decode to a slice of the decoded frame.
+ Applications can set this flag when queueing the output buffer
+ to prevent the driver from dequeueing the capture buffer after
+ the output buffer has been decoded (i.e. the capture buffer is
+ 'held'). If the timestamp of this output buffer differs from that
+ of the previous output buffer, then that indicates the start of a
+ new frame and the previously held capture buffer is dequeued.
* .. _`V4L2-BUF-FLAG-LAST`:
- ``V4L2_BUF_FLAG_LAST``
diff --git a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
index d7faef10e39b..d0c643db477a 100644
--- a/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
+++ b/Documentation/media/uapi/v4l/vidioc-reqbufs.rst
@@ -125,6 +125,7 @@ aborting or finishing any DMA in progress, an implicit
.. _V4L2-BUF-CAP-SUPPORTS-DMABUF:
.. _V4L2-BUF-CAP-SUPPORTS-REQUESTS:
.. _V4L2-BUF-CAP-SUPPORTS-ORPHANED-BUFS:
+.. _V4L2-BUF-CAP-SUPPORTS-M2M-HOLD-CAPTURE-BUF:
.. cssclass:: longtable
@@ -150,6 +151,11 @@ aborting or finishing any DMA in progress, an implicit
- The kernel allows calling :ref:`VIDIOC_REQBUFS` while buffers are still
mapped or exported via DMABUF. These orphaned buffers will be freed
when they are unmapped or when the exported DMABUF fds are closed.
+* - ``V4L2_BUF_CAP_SUPPORTS_M2M_HOLD_CAPTURE_BUF``
+ - 0x0020
+ - Only valid for stateless decoders. If set, then userspace can set the
+``V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF`` flag to hold off on returning
the
+ capture buffer until the OUTPUT timestamp changes.
Return Value
diff --git a/drivers/media/common/videobuf2/videobuf2-v4l2.c
b/drivers/media/common/videobuf2/videobuf2-v4l2.c
index 5a9ba3846f0a..699787f48f46 100644
--- a/drivers/media/common/videobuf2/videobuf2-v4l2.c
+++ b/drivers/media/common/videobuf2/videobuf2-v4l2.c
@@ -50,7 +50,8 @@ module_param(debug, int, 0644);
V4L2_BUF_FLAG_TIMESTAMP_MASK)
/* Output bu
[PATCH v2 5/6] media: cedrus: h264: Support multiple slices per frame
With recent changes, support for decoding multi-slice frames can be easily added now. Signal VPU if current slice is first in frame or not and add information about first macroblock coordinates. Signed-off-by: Jernej Skrabec --- drivers/staging/media/sunxi/cedrus/cedrus_h264.c | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c index d6a782703c9b..b7260cfeb6f4 100644 --- a/drivers/staging/media/sunxi/cedrus/cedrus_h264.c +++ b/drivers/staging/media/sunxi/cedrus/cedrus_h264.c @@ -301,6 +301,8 @@ static void cedrus_set_params(struct cedrus_ctx *ctx, dma_addr_t src_buf_addr; u32 offset = slice->header_bit_size; u32 len = (slice->size * 8) - offset; + unsigned int pic_width_in_mbs; + bool mbaff_pic; u32 reg; cedrus_write(dev, VE_H264_VLD_LEN, len); @@ -370,12 +372,19 @@ static void cedrus_set_params(struct cedrus_ctx *ctx, reg |= VE_H264_SPS_DIRECT_8X8_INFERENCE; cedrus_write(dev, VE_H264_SPS, reg); + mbaff_pic = !(slice->flags & V4L2_H264_SLICE_FLAG_FIELD_PIC) && + (sps->flags & V4L2_H264_SPS_FLAG_MB_ADAPTIVE_FRAME_FIELD); + pic_width_in_mbs = sps->pic_width_in_mbs_minus1 + 1; + // slice parameters reg = 0; + reg |= ((slice->first_mb_in_slice % pic_width_in_mbs) & 0xff) << 24; + reg |= (((slice->first_mb_in_slice / pic_width_in_mbs) * (mbaff_pic + 1)) & 0xff) << 16; reg |= decode->nal_ref_idc ? BIT(12) : 0; reg |= (slice->slice_type & 0xf) << 8; reg |= slice->cabac_init_idc & 0x3; - reg |= VE_H264_SHS_FIRST_SLICE_IN_PIC; + if (run->first_slice) + reg |= VE_H264_SHS_FIRST_SLICE_IN_PIC; if (slice->flags & V4L2_H264_SLICE_FLAG_FIELD_PIC) reg |= VE_H264_SHS_FIELD_PIC; if (slice->flags & V4L2_H264_SLICE_FLAG_BOTTOM_FIELD) -- 2.23.0
[PATCH v2 0/6] media: cedrus: h264: Support multi-slice frames
This series adds support for decoding multi-slice H264 frames along with support for V4L2_DEC_CMD_FLUSH and V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF. Code was tested by modified ffmpeg, which can be found here: https://github.com/jernejsk/FFmpeg, branch mainline-test It has to be configured with at least following options: --enable-v4l2-request --enable-libudev --enable-libdrm Samples used for testing: http://jernej.libreelec.tv/videos/h264/BA1_FT_C.mp4 http://jernej.libreelec.tv/videos/h264/h264.mp4 Command line used for testing: ffmpeg -hwaccel drm -hwaccel_device /dev/dri/card0 -i h264.mp4 -pix_fmt bgra -f fbdev /dev/fb0 Please note that V4L2_DEC_CMD_FLUSH was not tested because I'm not sure how. ffmpeg follows exactly which slice is last in frame and sets hold flag accordingly. Improper usage of hold flag would corrupt ffmpeg assumptions and it would probably crash. Any ideas how to test this are welcome! Thanks to Jonas for adjusting ffmpeg. Please let me know what you think. Best regards, Jernej Changes from v1: - added Rb tags - updated V4L2_DEC_CMD_FLUSH documentation - updated first slice detection in Cedrus - hold capture buffer flag is set according to source format - added v4l m2m stateless_(try_)decoder_cmd ioctl helpers Hans Verkuil (2): vb2: add V4L2_BUF_FLAG_M2M_HOLD_CAPTURE_BUF videodev2.h: add V4L2_DEC_CMD_FLUSH Jernej Skrabec (4): media: v4l2-mem2mem: add stateless_(try_)decoder_cmd ioctl helpers media: cedrus: Detect first slice of a frame media: cedrus: h264: Support multiple slices per frame media: cedrus: Add support for holding capture buffer Documentation/media/uapi/v4l/buffer.rst | 13 ++ .../media/uapi/v4l/vidioc-decoder-cmd.rst | 10 +++- .../media/uapi/v4l/vidioc-reqbufs.rst | 6 +++ .../media/videodev2.h.rst.exceptions | 1 + .../media/common/videobuf2/videobuf2-v4l2.c | 8 +++- drivers/media/v4l2-core/v4l2-mem2mem.c| 35 ++ drivers/staging/media/sunxi/cedrus/cedrus.h | 1 + .../staging/media/sunxi/cedrus/cedrus_dec.c | 11 + .../staging/media/sunxi/cedrus/cedrus_h264.c | 11 - .../staging/media/sunxi/cedrus/cedrus_hw.c| 8 ++-- .../staging/media/sunxi/cedrus/cedrus_video.c | 14 ++ include/media/v4l2-mem2mem.h | 46 +++ include/media/videobuf2-core.h| 3 ++ include/media/videobuf2-v4l2.h| 5 ++ include/uapi/linux/videodev2.h| 14 -- 15 files changed, 175 insertions(+), 11 deletions(-) -- 2.23.0
Re: [PATCH] arm64: dts: rockchip: fix Rockpro64 RK808 interrupt line
Am Samstag, 21. September 2019, 15:14:57 CEST schrieb Hugh Cole-Baker:
> Fix the pinctrl and interrupt specifier for RK808 to use GPIO3_B2. On the
> Rockpro64 schematic [1] page 16, it shows GPIO3_B2 used for the interrupt
> line PMIC_INT_L from the RK808, and there's a note which translates as:
> "PMU termination GPIO1_C5 changed to this".
>
> Tested by setting an RTC wakealarm and checking /proc/interrupts counters.
> Without this patch, neither the rockchip_gpio_irq counter for the RK808,
> nor the RTC alarm counter increment when the alarm time is reached.
> With this patch, both interrupt counters increment by 1 as expected.
>
> [1] http://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf
>
> Fixes: e4f3fb4 ("arm64: dts: rockchip: add initial dts support for Rockpro64")
> Signed-off-by: Hugh Cole-Baker
applied as fix for 5.4
Thanks
Heiko
Why does /proc/partitions have sr0 and fd0 in it?
Hi, I was updating some tools such as udev, mdadm, lvm, and came across a hang and messages about unable to read fd0 which wasn't occurring with the old tools, but using same kernel. So I've found that in the old version the /proc/partitions didn't have fd0 whereas now it does. But both have sr0 in it. So that leads me to who populates the /proc/partitions, from the limited info you can find searching the Internet, it looks like the kernel. But obviously not since same kernel used with different results. The difference is the old system udev used the old debian create_static_nodes and didn't use devtmpfs, the new udev (eudev), uses devtmpfs and the create_static_nodes is a bash function instead of separate binary. I wonder if that has something to do with it. But since cd and floppy devices aren't partitioned traditionally (technically any block device could be but it would be non-standard) why are they in the /proc/partitions file (also the device, e.g. sda, is in there and it's not a partition). So is it not partitions but just block devices? If so, maybe /proc/partitions should be a symlink to a new /proc/blockdevices, so everyone is clear what actually goes in there (leave the old name just for backwards compatibility) ? Is there any docs on all this? Thanks!
MIPS SGI IP30
hi guys any news about the kernel? I still have a lot of trouble with the PCI. Carlo
Re: [PATCH AUTOSEL 5.3 20/49] firmware: bcm47xx_nvram: Correct size_t printf format
On 9/29/2019 10:30 AM, Sasha Levin wrote:
> From: Florian Fainelli
>
> [ Upstream commit feb4eb060c3aecc3c5076bebe699cd09f1133c41 ]
>
> When building on a 64-bit host, we will get warnings like those:
>
> drivers/firmware/broadcom/bcm47xx_nvram.c:103:3: note: in expansion of macro
> 'pr_err'
>pr_err("nvram on flash (%i bytes) is bigger than the reserved space in
> memory, will just copy the first %i bytes\n",
>^~
> drivers/firmware/broadcom/bcm47xx_nvram.c:103:28: note: format string is
> defined here
>pr_err("nvram on flash (%i bytes) is bigger than the reserved space in
> memory, will just copy the first %i bytes\n",
>~^
>%li
>
> Use %zu instead for that purpose.
This is not a fix that should be backported as it was done only to allow
the driver to the made buildable with COMPILE_TEST. Please drop it from
your auto-selection.
>
> Signed-off-by: Florian Fainelli
> Reviewed-by: Philippe Mathieu-Daudé
> Signed-off-by: Paul Burton
> Cc: linux-m...@linux-mips.org
> Cc: j...@perches.com
> Cc: Rafał Miłecki
> Cc: linux-m...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Sasha Levin
> ---
> drivers/firmware/broadcom/bcm47xx_nvram.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/broadcom/bcm47xx_nvram.c
> b/drivers/firmware/broadcom/bcm47xx_nvram.c
> index 77eb74666ecbc..6d2820f6aca13 100644
> --- a/drivers/firmware/broadcom/bcm47xx_nvram.c
> +++ b/drivers/firmware/broadcom/bcm47xx_nvram.c
> @@ -96,7 +96,7 @@ static int nvram_find_and_copy(void __iomem *iobase, u32
> lim)
> nvram_len = size;
> }
> if (nvram_len >= NVRAM_SPACE) {
> - pr_err("nvram on flash (%i bytes) is bigger than the reserved
> space in memory, will just copy the first %i bytes\n",
> + pr_err("nvram on flash (%zu bytes) is bigger than the reserved
> space in memory, will just copy the first %i bytes\n",
> nvram_len, NVRAM_SPACE - 1);
> nvram_len = NVRAM_SPACE - 1;
> }
> @@ -148,7 +148,7 @@ static int nvram_init(void)
> header.len > sizeof(header)) {
> nvram_len = header.len;
> if (nvram_len >= NVRAM_SPACE) {
> - pr_err("nvram on flash (%i bytes) is bigger than the
> reserved space in memory, will just copy the first %i bytes\n",
> + pr_err("nvram on flash (%zu bytes) is bigger than the
> reserved space in memory, will just copy the first %i bytes\n",
> header.len, NVRAM_SPACE);
> nvram_len = NVRAM_SPACE - 1;
> }
>
--
Florian
[GIT PULL] MMC updates for v5.4 take 2
Hi Linus, Here's a PR with a couple more updates/fixes for MMC fixes intended for v5.4. No worries if this doesn't get included in rc1. Details about the highlights are as usual found in the signed tag. Please pull this in! Kind regards Ulf Hansson The following changes since commit 3c6a6910a81eae3566bb5fef6ea0f624382595e6: Merge branch 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 (2019-09-23 09:31:42 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git tags/mmc-v5.4-2 for you to fetch changes up to e51df6ce668a8f75ce27f83ce0f60103c568c375: mmc: host: sdhci-pci: Add Genesys Logic GL975x support (2019-09-27 20:48:20 +0200) MMC host: - sdhci-pci: Add Genesys Logic GL975x support - sdhci-tegra: Recover loss in throughput for DMA - sdhci-of-esdhc: Fix DMA bug Adrian Hunter (1): mmc: sdhci: Let drivers define their DMA mask Ben Chuang (1): mmc: host: sdhci-pci: Add Genesys Logic GL975x support Nicolin Chen (1): mmc: tegra: Implement ->set_dma_mask() Russell King (2): mmc: sdhci: improve ADMA error reporting mmc: sdhci-of-esdhc: set DMA snooping based on DMA coherence drivers/mmc/host/Kconfig | 1 + drivers/mmc/host/Makefile | 2 +- drivers/mmc/host/sdhci-of-esdhc.c | 7 +- drivers/mmc/host/sdhci-pci-core.c | 2 + drivers/mmc/host/sdhci-pci-gli.c | 352 ++ drivers/mmc/host/sdhci-pci.h | 5 + drivers/mmc/host/sdhci-tegra.c| 48 +++--- drivers/mmc/host/sdhci.c | 27 +-- drivers/mmc/host/sdhci.h | 1 + 9 files changed, 410 insertions(+), 35 deletions(-) create mode 100644 drivers/mmc/host/sdhci-pci-gli.c
Re: [PATCH 2/3] clk: let init callback return an error code
Am Dienstag, 24. September 2019, 14:39:53 CEST schrieb Jerome Brunet: > If the init callback is allowed to request resources, it needs a return > value to report the outcome of such a request. > > Signed-off-by: Jerome Brunet > --- [...] > drivers/clk/rockchip/clk-pll.c| 28 --- for the Rockchip part Acked-by: Heiko Stuebner
Re: WireGuard to port to existing Crypto API
Hi, On Wed, Sep 25, 2019 at 10:29:45AM +0200, Jason A. Donenfeld wrote: > I've long resisted the idea of porting to the existing crypto API, > because I think there are serious problems with it, in terms of > primitives, API, performance, and overall safety. I didn't want to > ship WireGuard in a form that I thought was sub-optimal from a > security perspective, since WireGuard is a security-focused project. > > But it seems like with or without us, WireGuard will get ported to the > existing crypto API. So it's probably better that we just fully > embrace it, and afterwards work evolutionarily to get Zinc into Linux > piecemeal. I've ported WireGuard already several times as a PoC to the > API and have a decent idea of the ways it can go wrong and generally > how to do it in the least-bad way. > > I realize this kind of compromise might come as a disappointment for > some folks. But it's probably better that as a project we remain > intimately involved with our Linux kernel users and the security of > the implementation, rather than slinking away in protest because we > couldn't get it all in at once. So we'll work with upstream, port to > the crypto API, and get the process moving again. We'll pick up the > Zinc work after that's done. > > I also understand there might be interested folks out there who enjoy > working with the crypto API quite a bit and would be happy to work on > the WireGuard port. Please do get in touch if you'd like to > collaborate. I have some WIP code to port WG to the crypto API, more to get an idea how hard it would be, though I read you've ported it to the api already. My other project (btrfs) is going to use blake2 in kernel and for that I'm about to submit the code, that's where it's also of interest for wg. My work is at 'github.com/kdave/WireGuard branch lkca-1'. I tried to find a way how to minimize the impact on current wg code but make it possible to iteratively extend it to the crypto API. So, there's some config-time ifdefery to select which crypto functions are using kernel or zinc api. See wg.git/src/crypto/Kbuild.include at the top, plus some source ifdefs. I made an example of blake2s port, but only compile tested. There are several problems in general that need to be solved on the kernel side first, before wireguard can work inside the kernel code base: * missing crypto functions in kernel * blake2 * curve25519 (missing completely) * missing generic crypto API callback to use blake_init_key, it's possible to use only the no-key variant (I have a patch for that, it's really easy but it's change in API so ...) The known problem is the cumbersome way to use the crypto functions, eg. for chacha/poly, I understand the pain and perhaps the reasons to start a fresh crypto library. I'm afraid the first implementation with current state of crypto API will be slow, until the API is extended to provide simple ways to transform buffers without scatterlists, request allocations, locking tfm context and whatnot. Feel free to reuse anything from the code if you think it's going the right direction. I'm not sure if I'll have time to continue with the port but at least you can consider blake2 on the way upstream. d.
Re: [PATCH 5.2 00/45] 5.2.18-stable review
stable-rc/linux-5.2.y boot: 83 boots: 0 failed, 83 passed (v5.2.17-46-g70cc0b99b90f) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.2.y/kernel/v5.2.17-46-g70cc0b99b90f/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-5.2.y/kernel/v5.2.17-46-g70cc0b99b90f/ Tree: stable-rc Branch: linux-5.2.y Git Describe: v5.2.17-46-g70cc0b99b90f Git Commit: 70cc0b99b90f823b81175b1f15f73ced86135c5b Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 46 unique boards, 15 SoC families, 13 builds out of 209 --- For more info write to
Re: [PATCH 4.19 00/63] 4.19.76-stable review
stable-rc/linux-4.19.y boot: 80 boots: 1 failed, 78 passed with 1 conflict (v4.19.75-64-gb52c75f7b978) Full Boot Summary: https://kernelci.org/boot/all/job/stable-rc/branch/linux-4.19.y/kernel/v4.19.75-64-gb52c75f7b978/ Full Build Summary: https://kernelci.org/build/stable-rc/branch/linux-4.19.y/kernel/v4.19.75-64-gb52c75f7b978/ Tree: stable-rc Branch: linux-4.19.y Git Describe: v4.19.75-64-gb52c75f7b978 Git Commit: b52c75f7b9785d0d0e6bf145787ed2fc99f5483c Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git Tested: 43 unique boards, 15 SoC families, 13 builds out of 206 Boot Regressions Detected: arm: tegra_defconfig: gcc-8: tegra124-nyan-big: lab-collabora: new failure (last pass: v4.19.75-33-gdab8e08e7087) Boot Failure Detected: arm: tegra_defconfig: gcc-8: tegra124-nyan-big: 1 failed lab Conflicting Boot Failure Detected: (These likely are not failures as other labs are reporting PASS. Needs review.) arm: exynos_defconfig: exynos5422-odroidxu3: lab-collabora: PASS (gcc-8) lab-baylibre: FAIL (gcc-8) --- For more info write to
[GIT PULL] ARM: SoC fixes
Hi Linus, The following changes since commit 4d856f72c10ecb060868ed10ff1b1453943fc6c8: Linux 5.3 (2019-09-15 14:19:32 -0700) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git tags/armsoc-fixes for you to fetch changes up to 9bfd7319e8d353b8b81c4cfd4d7eced71adbfbb5: Merge tag 'fixes-5.4-merge-window' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/fixes (2019-09-29 11:20:48 -0700) ARM: SoC fixes A few fixes that have trickled in through the merge window: - Video fixes for OMAP due to panel-dpi driver removal - Clock fixes for OMAP that broke no-idle quirks + nfsroot on DRA7 - Fixing arch version on ASpeed ast2500 - Two fixes for reset handling on ARM SCMI Adam Ford (4): ARM: omap2plus_defconfig: Fix missing video ARM: dts: logicpd-torpedo-baseboard: Fix missing video ARM: dts: am3517-evm: Fix missing video ARM: dts: logicpd-som-lv: Fix i2c2 and i2c3 Pin mux Arnd Bergmann (1): ARM: aspeed: ast2500 is ARMv6K Olof Johansson (2): Merge tag 'scmi-fixes-5.4' of git://git.kernel.org/.../sudeep.holla/linux into arm/fixes Merge tag 'fixes-5.4-merge-window' of git://git.kernel.org/.../tmlind/linux-omap into arm/fixes Sudeep Holla (2): firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_reset reset: reset-scmi: add missing handle initialisation Tony Lindgren (3): bus: ti-sysc: Fix clock handling for no-idle quirks bus: ti-sysc: Fix handling of invalid clocks bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle() Documentation/devicetree/bindings/arm/arm,scmi.txt | 17 + MAINTAINERS| 1 + arch/arm/boot/dts/am3517-evm.dts | 23 +- arch/arm/boot/dts/logicpd-som-lv.dtsi | 26 +- arch/arm/boot/dts/logicpd-torpedo-baseboard.dtsi | 37 +-- arch/arm/configs/omap2plus_defconfig | 1 + arch/arm/mach-aspeed/Kconfig | 1 - arch/arm/mach-omap2/pdata-quirks.c | 4 +- drivers/bus/ti-sysc.c | 52 ++- drivers/clk/clk-scmi.c | 2 +- drivers/firmware/arm_scmi/Makefile | 2 +- drivers/firmware/arm_scmi/base.c | 2 +- drivers/firmware/arm_scmi/clock.c | 33 +- drivers/firmware/arm_scmi/common.h | 18 +- drivers/firmware/arm_scmi/driver.c | 366 + drivers/firmware/arm_scmi/perf.c | 264 ++- drivers/firmware/arm_scmi/power.c | 6 +- drivers/firmware/arm_scmi/reset.c | 231 + drivers/firmware/arm_scmi/sensors.c| 57 ++-- drivers/hwmon/scmi-hwmon.c | 2 +- drivers/reset/Kconfig | 11 + drivers/reset/Makefile | 1 + drivers/reset/reset-scmi.c | 125 +++ include/linux/scmi_protocol.h | 46 ++- 24 files changed, 1046 insertions(+), 282 deletions(-) create mode 100644 drivers/firmware/arm_scmi/reset.c create mode 100644 drivers/reset/reset-scmi.c
