* [dpdk-dev] [PATCH] crypto/nitrox: fix coverity defects
From: Nagadheeraj Rottela @ 2020-02-20 11:04 UTC (permalink / raw)
To: akhil.goyal; +Cc: dev, jsrikanth, Nagadheeraj Rottela
Address the defects reported by coverity: Unintended sign extension
and Out-of-bounds access.
Coverity issue: 349899, 349905, 349911, 349921, 349923, 349926
Fixes: 32e4930d5a3b ("crypto/nitrox: add hardware queue management")
Fixes: 9fdef0cc2385 ("crypto/nitrox: create symmetric cryptodev")
Signed-off-by: Nagadheeraj Rottela <rnagadheeraj@marvell.com>
---
drivers/crypto/nitrox/nitrox_csr.h | 18 +++++++++---------
drivers/crypto/nitrox/nitrox_sym.c | 3 ++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/nitrox/nitrox_csr.h b/drivers/crypto/nitrox/nitrox_csr.h
index 8cd92e38b..b4c969b26 100644
--- a/drivers/crypto/nitrox/nitrox_csr.h
+++ b/drivers/crypto/nitrox/nitrox_csr.h
@@ -12,15 +12,15 @@
#define NITROX_CSR_ADDR(bar_addr, offset) (bar_addr + (offset))
/* NPS packet registers */
-#define NPS_PKT_IN_INSTR_CTLX(_i) (0x10060 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_BADDRX(_i) (0x10068 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_RSIZEX(_i) (0x10070 + ((_i) * 0x40000))
-#define NPS_PKT_IN_DONE_CNTSX(_i) (0x10080 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INSTR_BAOFF_DBELLX(_i) (0x10078 + ((_i) * 0x40000))
-#define NPS_PKT_IN_INT_LEVELSX(_i) (0x10088 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_CTLX(_i) (0x10000 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_CNTSX(_i) (0x10008 + ((_i) * 0x40000))
-#define NPS_PKT_SLC_INT_LEVELSX(_i) (0x10010 + ((_i) * 0x40000))
+#define NPS_PKT_IN_INSTR_CTLX(_i) (0x10060UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_BADDRX(_i) (0x10068UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_RSIZEX(_i) (0x10070UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_DONE_CNTSX(_i) (0x10080UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INSTR_BAOFF_DBELLX(_i) (0x10078UL + ((_i) * 0x40000UL))
+#define NPS_PKT_IN_INT_LEVELSX(_i) (0x10088UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_CTLX(_i) (0x10000UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_CNTSX(_i) (0x10008UL + ((_i) * 0x40000UL))
+#define NPS_PKT_SLC_INT_LEVELSX(_i) (0x10010UL + ((_i) * 0x40000UL))
/* AQM Virtual Function Registers */
#define AQMQ_QSZX(_i) (0x20008 + ((_i)*0x40000))
diff --git a/drivers/crypto/nitrox/nitrox_sym.c b/drivers/crypto/nitrox/nitrox_sym.c
index 56410c44d..d1b32fec9 100644
--- a/drivers/crypto/nitrox/nitrox_sym.c
+++ b/drivers/crypto/nitrox/nitrox_sym.c
@@ -683,7 +683,8 @@ nitrox_sym_pmd_create(struct nitrox_device *ndev)
struct rte_cryptodev *cdev;
rte_pci_device_name(&ndev->pdev->addr, name, sizeof(name));
- snprintf(name + strlen(name), RTE_CRYPTODEV_NAME_MAX_LEN, "_n5sym");
+ snprintf(name + strlen(name), RTE_CRYPTODEV_NAME_MAX_LEN - strlen(name),
+ "_n5sym");
ndev->rte_sym_dev.driver = &nitrox_rte_sym_drv;
ndev->rte_sym_dev.numa_node = ndev->pdev->device.numa_node;
ndev->rte_sym_dev.devargs = NULL;
--
2.13.6
^ permalink raw reply related
* Re: [PATCH nf-next v4 0/9] nftables: Set implementation for arbitrary concatenation of ranges
From: Stefano Brivio @ 2020-02-20 11:04 UTC (permalink / raw)
To: Phil Sutter
Cc: Pablo Neira Ayuso, netfilter-devel, Florian Westphal,
Kadlecsik József, Eric Garver
In-Reply-To: <20200220105240.GG20005@orbyte.nwl.cc>
Hi Phil,
On Thu, 20 Feb 2020 11:52:41 +0100
Phil Sutter <phil@nwl.cc> wrote:
> Hi Stefano,
>
> When playing with adding multiple elements, I suddenly noticed a
> disturbance in the force (general protection fault). Here's a
> reproducer:
>
> | $NFT -f - <<EOF
> | table t {
> | set s {
> | type ipv4_addr . inet_service
> | flags interval
> | }
> | }
> | EOF
> |
> | $NFT add element t s '{ 10.0.0.1 . 22-25, 10.0.0.1 . 10-20 }'
> | $NFT flush set t s
> | $NFT add element t s '{ 10.0.0.1 . 10-20, 10.0.0.1 . 22-25 }'
>
> It is pretty reliable, though sometimes needs a second call. Looks like some
> things going on in parallel which shouldn't. Here's a typical last breath:
>
> [ 71.319848] general protection fault, probably for non-canonical address 0x6f6b6e696c2e756e: 0000 [#1] PREEMPT SMP PTI
> [ 71.321540] CPU: 3 PID: 1201 Comm: kworker/3:2 Not tainted 5.6.0-rc1-00377-g2bb07f4e1d861 #192
> [ 71.322746] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190711_202441-buildvm-armv7-10.arm.fedoraproject.org-2.fc31 04/01/2014
> [ 71.324430] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
> [ 71.325387] RIP: 0010:nft_set_elem_destroy+0xa5/0x110 [nf_tables]
Ouch, thanks for reporting, I'll check in a few hours.
--
Stefano
^ permalink raw reply
* Re: [PATCH v4 3/3] clocksource: Add Low Power STM32 timers driver
From: Daniel Lezcano @ 2020-02-20 11:05 UTC (permalink / raw)
To: Benjamin GAIGNARD, lee.jones@linaro.org, robh+dt@kernel.org,
mark.rutland@arm.com, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
tglx@linutronix.de, Fabrice GASNIER
Cc: devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Benjamin Gaignard,
Pascal PAILLET-LME
In-Reply-To: <9cc4af9e-27d0-96c3-b3f1-20c88f89b70a@st.com>
On 20/02/2020 11:45, Benjamin GAIGNARD wrote:
[ ... ]
>>> +{
>>> + struct stm32_lp_private *priv = to_priv(clkevt);
>>> +
>>> + /* disable LPTIMER to be able to write into IER register*/
>>> + regmap_write(priv->reg, STM32_LPTIM_CR, 0);
>>> + /* enable ARR interrupt */
>>> + regmap_write(priv->reg, STM32_LPTIM_IER, STM32_LPTIM_ARRMIE);
>>> + /* enable LPTIMER to be able to write into ARR register */
>>> + regmap_write(priv->reg, STM32_LPTIM_CR, STM32_LPTIM_ENABLE);
>>> + /* set next event counter */
>>> + regmap_write(priv->reg, STM32_LPTIM_ARR, evt);
>>> +
>>> + /* start counter */
>>> + if (is_periodic)
>>> + regmap_write(priv->reg, STM32_LPTIM_CR,
>>> + STM32_LPTIM_CNTSTRT | STM32_LPTIM_ENABLE);
>>> + else
>>> + regmap_write(priv->reg, STM32_LPTIM_CR,
>>> + STM32_LPTIM_SNGSTRT | STM32_LPTIM_ENABLE);
>> The regmap config in stm32-lptimer is not defined with the fast_io flag
>> (on purpose or not?) that means we can potentially deadlock here as the
>> lock is a mutex.
>>
>> Isn't it detected with the lock validation scheme?
> It wasn't a problem with other parts of the mfd and I don't notice
> issues so I guess it is ok.
Given your comment below, the case can't happen I agree but there is
still a heavy operation with the locking.
>>> + return 0;
>>> +}
>>> +static int stm32_clkevent_lp_remove(struct platform_device *pdev)
>>> +{
>>> + return -EBUSY; /* cannot unregister clockevent */
>>> +}
>> Won't be the mfd into an inconsistent state here? The other subsystems
>> will be removed but this one will prevent to unload the module leading
>> to a situation where the mfd is partially removed but still there
>> without a possible recovery, no?
> We can't enable the timer part of the mfd at the same time than the
> other features.
Hmm, interesting case. The DT binding does not give this information,
especially in the example. You should fix the DT by giving two examples IMO.
Rob, how do you describe this situation (exclusive properties)?
> It has be exclusive and that exclude the problem you describe above.
Ok, the regmap_write is not a free operation and in this case you can
get rid of all the regmap-ish in this driver.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* Re: [dpdk-dev] [PATCH 3/4] ci: use an explicit list of Travis jobs
From: Thomas Monjalon @ 2020-02-20 11:05 UTC (permalink / raw)
To: David Marchand; +Cc: aconole, dev, Michael Santana
In-Reply-To: <20200219194131.29417-4-david.marchand@redhat.com>
19/02/2020 20:41, David Marchand:
> Maintaining the .travis.yml requires some knowledge of how Travis
> computes the jobs list (combination of os: arch: compiler: etc...).
> Let's switch to an explicit list to find all jobs at a glance.
>
> To enhance readability, jobs have been sorted per arch/compiler with
> comments to isolate blocks.
>
> Setting required_packages for aarch64 native jobs is unnecessary,
> the global addons: values are the same.
>
> This commit does not change the jobs list (21 jobs in total).
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Thank you for thinking to poor humans like me with no Travis-fu skill.
^ permalink raw reply
* Re: [PATCH v2] mm: kmemleak: Use address-of operator on section symbols
From: Catalin Marinas @ 2020-02-20 11:05 UTC (permalink / raw)
To: Nathan Chancellor
Cc: Andrew Morton, linux-mm, linux-kernel, clang-built-linux,
Nick Desaulniers
In-Reply-To: <20200220051551.44000-1-natechancellor@gmail.com>
On Wed, Feb 19, 2020 at 10:15:51PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> These are not true arrays, they are linker defined symbols, which are
> just addresses. Using the address of operator silences the warning and
> does not change the resulting assembly with either clang/ld.lld or
> gcc/ld (tested with diff + objdump -Dr).
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/895
> Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v4 3/3] clocksource: Add Low Power STM32 timers driver
From: Daniel Lezcano @ 2020-02-20 11:05 UTC (permalink / raw)
To: Benjamin GAIGNARD, lee.jones@linaro.org, robh+dt@kernel.org,
mark.rutland@arm.com, mcoquelin.stm32@gmail.com, Alexandre TORGUE,
tglx@linutronix.de, Fabrice GASNIER
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Pascal PAILLET-LME, Benjamin Gaignard,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <9cc4af9e-27d0-96c3-b3f1-20c88f89b70a@st.com>
On 20/02/2020 11:45, Benjamin GAIGNARD wrote:
[ ... ]
>>> +{
>>> + struct stm32_lp_private *priv = to_priv(clkevt);
>>> +
>>> + /* disable LPTIMER to be able to write into IER register*/
>>> + regmap_write(priv->reg, STM32_LPTIM_CR, 0);
>>> + /* enable ARR interrupt */
>>> + regmap_write(priv->reg, STM32_LPTIM_IER, STM32_LPTIM_ARRMIE);
>>> + /* enable LPTIMER to be able to write into ARR register */
>>> + regmap_write(priv->reg, STM32_LPTIM_CR, STM32_LPTIM_ENABLE);
>>> + /* set next event counter */
>>> + regmap_write(priv->reg, STM32_LPTIM_ARR, evt);
>>> +
>>> + /* start counter */
>>> + if (is_periodic)
>>> + regmap_write(priv->reg, STM32_LPTIM_CR,
>>> + STM32_LPTIM_CNTSTRT | STM32_LPTIM_ENABLE);
>>> + else
>>> + regmap_write(priv->reg, STM32_LPTIM_CR,
>>> + STM32_LPTIM_SNGSTRT | STM32_LPTIM_ENABLE);
>> The regmap config in stm32-lptimer is not defined with the fast_io flag
>> (on purpose or not?) that means we can potentially deadlock here as the
>> lock is a mutex.
>>
>> Isn't it detected with the lock validation scheme?
> It wasn't a problem with other parts of the mfd and I don't notice
> issues so I guess it is ok.
Given your comment below, the case can't happen I agree but there is
still a heavy operation with the locking.
>>> + return 0;
>>> +}
>>> +static int stm32_clkevent_lp_remove(struct platform_device *pdev)
>>> +{
>>> + return -EBUSY; /* cannot unregister clockevent */
>>> +}
>> Won't be the mfd into an inconsistent state here? The other subsystems
>> will be removed but this one will prevent to unload the module leading
>> to a situation where the mfd is partially removed but still there
>> without a possible recovery, no?
> We can't enable the timer part of the mfd at the same time than the
> other features.
Hmm, interesting case. The DT binding does not give this information,
especially in the example. You should fix the DT by giving two examples IMO.
Rob, how do you describe this situation (exclusive properties)?
> It has be exclusive and that exclude the problem you describe above.
Ok, the regmap_write is not a free operation and in this case you can
get rid of all the regmap-ish in this driver.
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2] xfs: add agf freeblocks verify in xfs_agf_verify
From: Zheng Bin @ 2020-02-20 11:13 UTC (permalink / raw)
To: sandeen, bfoster, dchinner, darrick.wong, linux-xfs; +Cc: renxudong1, yi.zhang
We recently used fuzz(hydra) to test XFS and automatically generate
tmp.img(XFS v5 format, but some metadata is wrong)
xfs_repair information(just one AG):
agf_freeblks 0, counted 3224 in ag 0
agf_longest 536874136, counted 3224 in ag 0
sb_fdblocks 613, counted 3228
Test as follows:
mount tmp.img tmpdir
cp file1M tmpdir
sync
In 4.19-stable, sync will stuck, the reason is:
xfs_mountfs
xfs_check_summary_counts
if ((!xfs_sb_version_haslazysbcount(&mp->m_sb) ||
XFS_LAST_UNMOUNT_WAS_CLEAN(mp)) &&
!xfs_fs_has_sickness(mp, XFS_SICK_FS_COUNTERS))
return 0; -->just return, incore sb_fdblocks still be 613
xfs_initialize_perag_data
cp file1M tmpdir -->ok(write file to pagecache)
sync -->stuck(write pagecache to disk)
xfs_map_blocks
xfs_iomap_write_allocate
while (count_fsb != 0) {
nimaps = 0;
while (nimaps == 0) { --> endless loop
nimaps = 1;
xfs_bmapi_write(..., &nimaps) --> nimaps becomes 0 again
xfs_bmapi_write
xfs_bmap_alloc
xfs_bmap_btalloc
xfs_alloc_vextent
xfs_alloc_fix_freelist
xfs_alloc_space_available -->fail(agf_freeblks is 0)
In linux-next, sync not stuck, cause commit c2b3164320b5 ("xfs:
use the latest extent at writeback delalloc conversion time") remove
the above while, dmesg is as follows:
[ 55.250114] XFS (loop0): page discard on page ffffea0008bc7380, inode 0x1b0c, offset 0.
Users do not know why this page is discard, the better soultion is:
1. Like xfs_repair, make sure sb_fdblocks is equal to counted
(xfs_initialize_perag_data did this, who is not called at this mount)
2. Add agf verify, if fail, will tell users to repair
This patch use the second soultion.
Signed-off-by: Zheng Bin <zhengbin13@huawei.com>
Signed-off-by: Ren Xudong <renxudong1@huawei.com>
---
v1->v2: modify comment, add more agf verify
fs/xfs/libxfs/xfs_alloc.c | 17 +++++++++++++++++
1 file changed, 17 insertions(+)
diff --git a/fs/xfs/libxfs/xfs_alloc.c b/fs/xfs/libxfs/xfs_alloc.c
index d8053bc..5faed42 100644
--- a/fs/xfs/libxfs/xfs_alloc.c
+++ b/fs/xfs/libxfs/xfs_alloc.c
@@ -2839,6 +2839,7 @@ xfs_agf_verify(
{
struct xfs_mount *mp = bp->b_mount;
struct xfs_agf *agf = XFS_BUF_TO_AGF(bp);
+ int i;
if (xfs_sb_version_hascrc(&mp->m_sb)) {
if (!uuid_equal(&agf->agf_uuid, &mp->m_sb.sb_meta_uuid))
@@ -2858,6 +2859,22 @@ xfs_agf_verify(
be32_to_cpu(agf->agf_flcount) <= xfs_agfl_size(mp)))
return __this_address;
+ if (be32_to_cpu(agf->agf_length) > mp->m_sb.sb_dblocks ||
+ be32_to_cpu(agf->agf_btreeblks) > be32_to_cpu(agf->agf_length) ||
+ be32_to_cpu(agf->agf_rmap_blocks) > be32_to_cpu(agf->agf_length) ||
+ be32_to_cpu(agf->agf_refcount_blocks) > be32_to_cpu(agf->agf_length) ||
+ be32_to_cpu(agf->agf_spare2) != 0)
+ return __this_address;
+
+ for (i = 0; i < ARRAY_SIZE(agf->agf_spare64); i++)
+ if (be64_to_cpu(agf->agf_spare64[i]) != 0)
+ return __this_address;
+
+ if (be32_to_cpu(agf->agf_freeblks) < be32_to_cpu(agf->agf_longest) ||
+ be32_to_cpu(agf->agf_freeblks) > be32_to_cpu(agf->agf_length) ||
+ be32_to_cpu(agf->agf_freeblks) > mp->m_sb.sb_fdblocks)
+ return __this_address;
+
if (be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNO]) < 1 ||
be32_to_cpu(agf->agf_levels[XFS_BTNUM_CNT]) < 1 ||
be32_to_cpu(agf->agf_levels[XFS_BTNUM_BNO]) > XFS_BTREE_MAXLEVELS ||
--
2.7.4
^ permalink raw reply related
* Re: [cip-dev] : isar-cip-core and cip-kernel-config
From: Chris Paterson @ 2020-02-20 11:06 UTC (permalink / raw)
To: Gylstorff Quirin, cip-dev@lists.cip-project.org,
Kiszka, Jan (CT RDA IOT SES-DE)
In-Reply-To: <ca39ce48-8602-0e79-99af-2f44200e2b12@siemens.com>
Hello Quirin,
> From: Gylstorff Quirin <quirin.gylstorff@siemens.com>
> Sent: 18 February 2020 16:20
>
> Hi all,
>
> I am currently trying to have all targets in isar-cip-core running with
> the matching configuration from cip-kernel-config. For some targets
> there are missing config entries to boot Debian 10 e.g. [1].
>
> Should I add these configuration directly to the matching defconfig in
> cip-kernel-config or add new defconfig/snippets for isar-cip-core?
Good question.
I think cip-kernel-config was created to help the CIP maintainers know what configurations etc. to support/maintain.
How will it affect the maintainers if we start adding config options that are only required for testing, rather then for SLTS support? (Or do we technically also need SLTS support for the 'test' config options?)
>
> Currently I am adding them directly to the defconfigs as it is IHMO
> more manageable as it avoid snippets/configs all over the place.
Would another option be to have complete configurations for testing, rather than just the extra snippets?
It would mean we need to maintain two copies of mostly the same thing, but it'll make scripting easier and be clear what is for the Kernel maintainers and what is for testing.
Would it be possible to use the same 'testing' configurations/snippets for both deby and isar versions of cip-core?
Kind regards, Chris
>
> [1]:
> https://gitlab.com/Quirin.Gy/cip-kernel-config/-
> /commit/92979dba2e3c03a422b5b9e8f9c592db9ff43f30
>
> --
> Quirin Gylstorff
>
> Siemens AG
> Corporate Technology
> Research in Digitalization and Automation
> Smart Embedded Systems
> CT RDA IOT SES-DE
> Otto-Hahn-Ring 6
> 81739 Muenchen, Germany
> Mobile: +49 173 3746683
> mailto:quirin.gylstorff@siemens.com
> www.siemens.com/ingenuityforlife
>
> Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Jim
> Hagemann Snabe; Managing Board: Joe Kaeser, Chairman, President and
> Chief Executive Officer; Roland Busch, Lisa Davis, Klaus Helmrich,
> Cedrik Neike, Michael Sen, Ralf P. Thomas; Registered offices: Berlin
> and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB
> 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322
>
> Important notice: This e-mail and any attachment thereof contain
> corporate proprietary information. If you have received it by mistake,
> please notify us immediately by reply e-mail and delete this e-mail and
> its attachments from your system. Thank you.
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
^ permalink raw reply
* [RFC PATCH 0/3] efi: put an API version number in the PE/COFF header
From: Ard Biesheuvel @ 2020-02-20 11:06 UTC (permalink / raw)
To: linux-efi
Cc: Ard Biesheuvel, lersek, leif, pjones, mjg59, agraf,
ilias.apalodimas, xypron.glpk, daniel.kiper, nivedita,
James.Bottomley
After having added new ways to load the initrd and the mixed mode kernel,
we will need to tell the loader about this, so it can use the new, generic
method if supported, and fall back to the existing method(s) otherwise.
This is an RFC - if there are better ways to record this in the image
somehow, please shout.
Cc: lersek@redhat.com
Cc: leif@nuviainc.com
Cc: pjones@redhat.com
Cc: mjg59@google.com
Cc: agraf@csgraf.de
Cc: ilias.apalodimas@linaro.org
Cc: xypron.glpk@gmx.de
Cc: daniel.kiper@oracle.com
Cc: nivedita@alum.mit.edu
Cc: James.Bottomley@hansenpartnership.com
Ard Biesheuvel (3):
efi/x86: Use symbolic constants in PE header instead of bare numbers
efi/libstub: Introduce symbolic constants for the stub major/minor
version
efi: Bump the Linux EFI stub major version number to #1
arch/arm/boot/compressed/efi-header.S | 4 +-
arch/arm64/kernel/efi-header.S | 4 +-
arch/x86/boot/header.S | 64 ++++++++++----------
include/linux/pe.h | 21 +++++++
4 files changed, 58 insertions(+), 35 deletions(-)
--
2.17.1
^ permalink raw reply
* [RFC PATCH 1/3] efi/x86: Use symbolic constants in PE header instead of bare numbers
From: Ard Biesheuvel @ 2020-02-20 11:06 UTC (permalink / raw)
To: linux-efi
Cc: Ard Biesheuvel, lersek, leif, pjones, mjg59, agraf,
ilias.apalodimas, xypron.glpk, daniel.kiper, nivedita,
James.Bottomley
In-Reply-To: <20200220110649.1303-1-ardb@kernel.org>
Replace bare numbers in the PE/COFF header structure with symbolic
constants so they become self documenting.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
| 60 ++++++++++----------
1 file changed, 31 insertions(+), 29 deletions(-)
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 44aeb63ca6ae..9110b58aa2ec 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -15,7 +15,7 @@
* hex while segment addresses are written as segment:offset.
*
*/
-
+#include <linux/pe.h>
#include <asm/segment.h>
#include <asm/boot.h>
#include <asm/page_types.h>
@@ -43,8 +43,7 @@ SYSSEG = 0x1000 /* historical load address >> 4 */
bootsect_start:
#ifdef CONFIG_EFI_STUB
# "MZ", MS-DOS header
- .byte 0x4d
- .byte 0x5a
+ .word MZ_MAGIC
#endif
# Normalize the start address
@@ -97,39 +96,30 @@ bugger_off_msg:
#ifdef CONFIG_EFI_STUB
pe_header:
- .ascii "PE"
- .word 0
+ .long PE_MAGIC
coff_header:
#ifdef CONFIG_X86_32
- .word 0x14c # i386
+ .set image_file_add_flags, IMAGE_FILE_32BIT_MACHINE
+ .set pe_opt_magic, PE_OPT_MAGIC_PE32
+ .word IMAGE_FILE_MACHINE_I386
#else
- .word 0x8664 # x86-64
+ .set image_file_add_flags, 0
+ .set pe_opt_magic, PE_OPT_MAGIC_PE32PLUS
+ .word IMAGE_FILE_MACHINE_AMD64
#endif
.word section_count # nr_sections
.long 0 # TimeDateStamp
.long 0 # PointerToSymbolTable
.long 1 # NumberOfSymbols
.word section_table - optional_header # SizeOfOptionalHeader
-#ifdef CONFIG_X86_32
- .word 0x306 # Characteristics.
- # IMAGE_FILE_32BIT_MACHINE |
- # IMAGE_FILE_DEBUG_STRIPPED |
- # IMAGE_FILE_EXECUTABLE_IMAGE |
- # IMAGE_FILE_LINE_NUMS_STRIPPED
-#else
- .word 0x206 # Characteristics
- # IMAGE_FILE_DEBUG_STRIPPED |
- # IMAGE_FILE_EXECUTABLE_IMAGE |
- # IMAGE_FILE_LINE_NUMS_STRIPPED
-#endif
+ .word IMAGE_FILE_EXECUTABLE_IMAGE | \
+ image_file_add_flags | \
+ IMAGE_FILE_DEBUG_STRIPPED | \
+ IMAGE_FILE_LINE_NUMS_STRIPPED # Characteristics
optional_header:
-#ifdef CONFIG_X86_32
- .word 0x10b # PE32 format
-#else
- .word 0x20b # PE32+ format
-#endif
+ .word pe_opt_magic
.byte 0x02 # MajorLinkerVersion
.byte 0x14 # MinorLinkerVersion
@@ -170,7 +160,7 @@ extra_header_fields:
.long 0x200 # SizeOfHeaders
.long 0 # CheckSum
- .word 0xa # Subsystem (EFI application)
+ .word IMAGE_SUBSYSTEM_EFI_APPLICATION # Subsystem (EFI application)
.word 0 # DllCharacteristics
#ifdef CONFIG_X86_32
.long 0 # SizeOfStackReserve
@@ -210,7 +200,10 @@ section_table:
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
- .long 0x60500020 # Characteristics (section flags)
+ .long IMAGE_SCN_CNT_CODE | \
+ IMAGE_SCN_MEM_READ | \
+ IMAGE_SCN_MEM_EXECUTE | \
+ IMAGE_SCN_ALIGN_16BYTES # Characteristics
#
# The EFI application loader requires a relocation section
@@ -228,7 +221,10 @@ section_table:
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
- .long 0x42100040 # Characteristics (section flags)
+ .long IMAGE_SCN_CNT_INITIALIZED_DATA | \
+ IMAGE_SCN_MEM_READ | \
+ IMAGE_SCN_MEM_DISCARDABLE | \
+ IMAGE_SCN_ALIGN_1BYTES # Characteristics
#ifdef CONFIG_EFI_MIXED
#
@@ -244,7 +240,10 @@ section_table:
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
- .long 0x42100040 # Characteristics (section flags)
+ .long IMAGE_SCN_CNT_INITIALIZED_DATA | \
+ IMAGE_SCN_MEM_READ | \
+ IMAGE_SCN_MEM_DISCARDABLE | \
+ IMAGE_SCN_ALIGN_1BYTES # Characteristics
#endif
#
@@ -263,7 +262,10 @@ section_table:
.long 0 # PointerToLineNumbers
.word 0 # NumberOfRelocations
.word 0 # NumberOfLineNumbers
- .long 0x60500020 # Characteristics (section flags)
+ .long IMAGE_SCN_CNT_CODE | \
+ IMAGE_SCN_MEM_READ | \
+ IMAGE_SCN_MEM_EXECUTE | \
+ IMAGE_SCN_ALIGN_16BYTES # Characteristics
.set section_count, (. - section_table) / 40
#endif /* CONFIG_EFI_STUB */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] bdi: fix use-after-free for bdi device
From: Yufen Yu @ 2020-02-20 11:07 UTC (permalink / raw)
To: Jan Kara; +Cc: Tejun Heo, axboe, linux-block, bvanassche
In-Reply-To: <20200219125505.GP16121@quack2.suse.cz>
Hi,
On 2020/2/19 20:55, Jan Kara wrote:
> Hi!
>
> On Sat 15-02-20 21:54:08, Yufen Yu wrote:
>
> I've now noticed there's commit 68f23b8906 "memcg: fix a crash in wb_workfn
> when a device disappears" from end of January which tries to address the
> issue you're looking into. Now AFAIU the code is till somewhat racy after
> that commit so I wanted to mention this mostly so that you fixup also the
> new bdi_dev_name() while you're fixing blkg_dev_name().
>
> Also I was wondering about one thing: If we really care about bdi->dev only
> for the name, won't we be much better off with just copying the name to
> bdi->name on registration? Sure it would consume a bit of memory for the
> name copy but I don't think we really care and things would be IMO *much*
> simpler that way... Yufen, Tejun, what do you think?
>
I think copying the name to bdi->name is also need protected by lock.
Otherwise, the reader of bdi->name may read incorrect value when
re-registion have not copy the name completely. Right? So, I also think
using RCU to protect object lifetimes may be a better way.
Thanks,
Yufen
^ permalink raw reply
* [RFC PATCH 2/3] efi/libstub: Introduce symbolic constants for the stub major/minor version
From: Ard Biesheuvel @ 2020-02-20 11:06 UTC (permalink / raw)
To: linux-efi
Cc: Ard Biesheuvel, lersek, leif, pjones, mjg59, agraf,
ilias.apalodimas, xypron.glpk, daniel.kiper, nivedita,
James.Bottomley
In-Reply-To: <20200220110649.1303-1-ardb@kernel.org>
Now that we have added new ways to load the initrd or the mixed mode
kernel, we will also need a way to tell the loader about this. Add
symbolic constants for the PE/COFF major/minor version numbers (which
fortunately have always been 0x0 for all architectures), so that we
can bump them later to document the capabilities of the stub.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
| 4 ++--
| 4 ++--
| 4 ++--
include/linux/pe.h | 3 +++
4 files changed, 9 insertions(+), 6 deletions(-)
--git a/arch/arm/boot/compressed/efi-header.S b/arch/arm/boot/compressed/efi-header.S
index e38fbda02b93..62286da318e7 100644
--- a/arch/arm/boot/compressed/efi-header.S
+++ b/arch/arm/boot/compressed/efi-header.S
@@ -70,8 +70,8 @@ extra_header_fields:
.long SZ_512 @ FileAlignment
.short 0 @ MajorOsVersion
.short 0 @ MinorOsVersion
- .short 0 @ MajorImageVersion
- .short 0 @ MinorImageVersion
+ .short LINUX_EFISTUB_MAJOR_VERSION @ MajorImageVersion
+ .short LINUX_EFISTUB_MINOR_VERSION @ MinorImageVersion
.short 0 @ MajorSubsystemVersion
.short 0 @ MinorSubsystemVersion
.long 0 @ Win32VersionValue
--git a/arch/arm64/kernel/efi-header.S b/arch/arm64/kernel/efi-header.S
index 40c704c5d3a5..914999ccaf8a 100644
--- a/arch/arm64/kernel/efi-header.S
+++ b/arch/arm64/kernel/efi-header.S
@@ -36,8 +36,8 @@ extra_header_fields:
.long PECOFF_FILE_ALIGNMENT // FileAlignment
.short 0 // MajorOperatingSystemVersion
.short 0 // MinorOperatingSystemVersion
- .short 0 // MajorImageVersion
- .short 0 // MinorImageVersion
+ .short LINUX_EFISTUB_MAJOR_VERSION // MajorImageVersion
+ .short LINUX_EFISTUB_MINOR_VERSION // MinorImageVersion
.short 0 // MajorSubsystemVersion
.short 0 // MinorSubsystemVersion
.long 0 // Win32VersionValue
--git a/arch/x86/boot/header.S b/arch/x86/boot/header.S
index 9110b58aa2ec..a87d788ea54e 100644
--- a/arch/x86/boot/header.S
+++ b/arch/x86/boot/header.S
@@ -147,8 +147,8 @@ extra_header_fields:
.long 0x20 # FileAlignment
.word 0 # MajorOperatingSystemVersion
.word 0 # MinorOperatingSystemVersion
- .word 0 # MajorImageVersion
- .word 0 # MinorImageVersion
+ .word LINUX_EFISTUB_MAJOR_VERSION # MajorImageVersion
+ .word LINUX_EFISTUB_MINOR_VERSION # MinorImageVersion
.word 0 # MajorSubsystemVersion
.word 0 # MinorSubsystemVersion
.long 0 # Win32VersionValue
diff --git a/include/linux/pe.h b/include/linux/pe.h
index c86bd3a2f70f..e0869f3eadd6 100644
--- a/include/linux/pe.h
+++ b/include/linux/pe.h
@@ -10,6 +10,9 @@
#include <linux/types.h>
+#define LINUX_EFISTUB_MAJOR_VERSION 0x0
+#define LINUX_EFISTUB_MINOR_VERSION 0x0
+
#define MZ_MAGIC 0x5a4d /* "MZ" */
#define PE_MAGIC 0x00004550 /* "PE\0\0" */
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 4/4] crypto: hisilicon/sec2 - Add pbuffer mode for SEC driver
From: John Garry @ 2020-02-20 11:07 UTC (permalink / raw)
To: Xu Zaibo, herbert, davem
Cc: qianweili, tanghui20, forest.zhouchang, linuxarm, zhangwei375,
shenyang39, yekai13, linux-crypto
In-Reply-To: <69fe2d60-428e-9747-b7c0-d69cf25efc0e@huawei.com>
On 20/02/2020 10:10, Xu Zaibo wrote:
> Hi,
>
>
> On 2020/2/20 17:50, John Garry wrote:
>> On 20/02/2020 09:04, Zaibo Xu wrote:
>>> From: liulongfang <liulongfang@huawei.com>
>>>
>>> In the scenario of SMMU translation, the SEC performance of short
>>> messages
>>> (<512Bytes) cannot meet our expectations. To avoid this, we reserve the
>>> plat buffer (PBUF) memory for small packets when creating TFM.
>>>
>>
>> I haven't gone through the code here, but why not use this method also
>> for non-translated? What are the pros and cons?
> Because non-translated has no performance or throughput problems.
>
OK, so no problem, but I was asking could it be improved, and, if so,
what would be the drawbacks?
As for the change to check if the IOMMU is translating, it seems exact
same as that for the hi1616 driver...
> cheers,
> Zaibo
>
> .
>>
>> The commit message is very light on details.
>>
>> Thanks
>> john
>>
>> .
>>
>
>
> .
^ permalink raw reply
* [RFC PATCH 3/3] efi: Bump the Linux EFI stub major version number to #1
From: Ard Biesheuvel @ 2020-02-20 11:06 UTC (permalink / raw)
To: linux-efi
Cc: Ard Biesheuvel, lersek, leif, pjones, mjg59, agraf,
ilias.apalodimas, xypron.glpk, daniel.kiper, nivedita,
James.Bottomley
In-Reply-To: <20200220110649.1303-1-ardb@kernel.org>
Now that we have introduced new, generic ways for the OS loader to
interface with Linux kernels during boot, we need to record this
fact in a way that allows loaders to discover this information, and
fall back to the existing methods for older kernels.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
---
include/linux/pe.h | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/include/linux/pe.h b/include/linux/pe.h
index e0869f3eadd6..8ad71d763a77 100644
--- a/include/linux/pe.h
+++ b/include/linux/pe.h
@@ -10,7 +10,25 @@
#include <linux/types.h>
-#define LINUX_EFISTUB_MAJOR_VERSION 0x0
+/*
+ * Linux EFI stub v1.0 adds the following functionality:
+ * - Loading initrd from the LINUX_EFI_INITRD_MEDIA_GUID device path,
+ * - Loading/starting the kernel from firmware that targets a different
+ * machine type, via the entrypoint exposed in the .compat PE/COFF section.
+ *
+ * The recommended way of loading and starting v1.0 or later kernels is to use
+ * the LoadImage() and StartImage() EFI boot services, and expose the initrd
+ * via the LINUX_EFI_INITRD_MEDIA_GUID device path.
+ *
+ * Versions older than v1.0 support initrd loading via the image load options
+ * (using initrd=, limited to the volume from which the kernel itself was
+ * loaded), or via arch specific means (bootparams, DT, etc).
+ *
+ * On x86, LoadImage() and StartImage() can be omitted if the EFI handover
+ * protocol is implemented, which can be inferred from the version,
+ * handover_offset and xloadflags fields in the bootparams structure.
+ */
+#define LINUX_EFISTUB_MAJOR_VERSION 0x1
#define LINUX_EFISTUB_MINOR_VERSION 0x0
#define MZ_MAGIC 0x5a4d /* "MZ" */
--
2.17.1
^ permalink raw reply related
* Re: [dpdk-dev] [PATCH 4/4] ci: reorganise Travis jobs
From: Thomas Monjalon @ 2020-02-20 11:07 UTC (permalink / raw)
To: David Marchand; +Cc: aconole, dev, Michael Santana
In-Reply-To: <20200219194131.29417-5-david.marchand@redhat.com>
19/02/2020 20:41, David Marchand:
> Let's prune the jobs list to limit the amount of time spent by the robot
> in Travis.
>
> Since meson enables automatically the relevant components, there is not
> much gain in testing with extra_packages vs required_packages only.
>
> For a given arch/compiler/env combination, compilation is first tested
> in all jobs that run tests or build the docs or run the ABI checks.
> In the same context, for jobs that accumulates running tests, building
> the docs etc..., those steps are independent and can be split to save
> some cpu on Travis.
>
> With this, we go down from 21 to 15 jobs.
>
> Note: this patch requires a flush of the existing caches in Travis.
>
> Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>
A small step for DPDK but a big save for the earth ;)
^ permalink raw reply
* Re: [PATCH v3 04/17] s390x: protvirt: Add diag308 subcodes 8 - 10
From: Janosch Frank @ 2020-02-20 11:06 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220110720.6142d055.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 4222 bytes --]
On 2/20/20 11:07 AM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:23 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> For diag308 subcodes 8 - 10 we have a new ipib of type 5. The ipib
>> holds the address and length of the secure execution header, as well
>> as a list of guest components.
>>
>> Each component is a block of memory, for example kernel or initrd,
>> which needs to be decrypted by the Ultravisor in order to run a
>> protected VM. The secure execution header instructs the Ultravisor on
>> how to handle the protected VM and its components.
>>
>> Subcodes 8 and 9 are similiar to 5 and 6 and subcode 10 will finally
>> start the protected guest.
>>
>> Subcodes 8-10 are not valid in protected mode, we have to do a subcode
>> 3 and then the 8 and 10 combination for a protected reboot.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> ---
>> hw/s390x/ipl.c | 48 ++++++++++++++++++++++++++++++++++++++++++---
>> hw/s390x/ipl.h | 31 +++++++++++++++++++++++++++++
>> target/s390x/diag.c | 27 ++++++++++++++++++++++---
>> 3 files changed, 100 insertions(+), 6 deletions(-)
>
> (...)
>
>> void s390_ipl_update_diag308(IplParameterBlock *iplb)
>> {
>> S390IPLState *ipl = get_ipl_device();
>>
>> - ipl->iplb = *iplb;
>> - ipl->iplb_valid = true;
>> + if (iplb->pbt == 5) {
>
> Magic value; maybe introduce a #define or at least a comment?
Well, there is already one defined, but it seems I never came around to
use it -_-
>
>> + ipl->iplb_pbt5 = *iplb;
>> + ipl->iplb_valid_pbt5 = true;
>> + } else {
>> + ipl->iplb = *iplb;
>> + ipl->iplb_valid = true;
>> + }
>> ipl->netboot = is_virtio_net_device(iplb);
>> }
>
>> @@ -133,6 +154,7 @@ struct S390IPLState {
>> /*< private >*/
>> DeviceState parent_obj;
>> IplParameterBlock iplb;
>> + IplParameterBlock iplb_pbt5;
>
> Add /* for protected virtualization */ ?
>
> Or, if this is not used for anything else, call it iplb_pv?
ack.
>
>> QemuIplParameters qipl;
>> uint64_t start_addr;
>> uint64_t compat_start_addr;
>
> (...)
>
>> diff --git a/target/s390x/diag.c b/target/s390x/diag.c
>> index b5aec06d6b..4ba6033609 100644
>> --- a/target/s390x/diag.c
>> +++ b/target/s390x/diag.c
>> @@ -52,6 +52,8 @@ int handle_diag_288(CPUS390XState *env, uint64_t r1, uint64_t r3)
>> #define DIAG_308_RC_OK 0x0001
>> #define DIAG_308_RC_NO_CONF 0x0102
>> #define DIAG_308_RC_INVALID 0x0402
>> +#define DIAG_308_RC_NO_PV_CONF 0x0a02
>> +#define DIAG_308_RC_INV_FOR_PV 0x0b02
>
> DIAG_308_RC_INVAL_FOR_PV ?
ack
>
>>
>> #define DIAG308_RESET_MOD_CLR 0
>> #define DIAG308_RESET_LOAD_NORM 1
>
> (...)
>
>> @@ -128,17 +135,31 @@ out:
>> g_free(iplb);
>> return;
>> case DIAG308_STORE:
>> + case DIAG308_PV_STORE:
>> if (diag308_parm_check(env, r1, addr, ra, true)) {
>> return;
>> }
>> - iplb = s390_ipl_get_iplb();
>> + if (subcode == DIAG308_PV_STORE) {
>> + iplb = s390_ipl_get_iplb_secure();
>> + } else {
>> + iplb = s390_ipl_get_iplb();
>> + }
>
> iplb = (subcode == DIAG308_PV_STORE) ?
> s390_ipl_get_iplb_secure() : s390_ipl_get_iplb();
>
> Matter of taste, I guess.
I'll have a look what I find nicer to read
>
>> if (iplb) {
>> cpu_physical_memory_write(addr, iplb, be32_to_cpu(iplb->len));
>> env->regs[r1 + 1] = DIAG_308_RC_OK;
>> } else {
>> env->regs[r1 + 1] = DIAG_308_RC_NO_CONF;
>> }
>> - return;
>> + break;
>> + case DIAG308_PV_START:
>> + iplb = s390_ipl_get_iplb_secure();
>> + if (!iplb || !iplb_valid_pv(iplb)) {
>> + env->regs[r1 + 1] = DIAG_308_RC_NO_PV_CONF;
>> + return;
>> + }
>> +
>> + s390_ipl_reset_request(cs, S390_RESET_PV);
>> + break;
>> default:
>> s390_program_interrupt(env, PGM_SPECIFICATION, ra);
>> break;
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] crypto/nitrox: fix coverity defects
From: Akhil Goyal @ 2020-02-20 11:07 UTC (permalink / raw)
To: Nagadheeraj Rottela, Thomas Monjalon; +Cc: dev@dpdk.org, jsrikanth@marvell.com
In-Reply-To: <20200220110431.30074-1-rnagadheeraj@marvell.com>
>
> Address the defects reported by coverity: Unintended sign extension
> and Out-of-bounds access.
>
> Coverity issue: 349899, 349905, 349911, 349921, 349923, 349926
>
> Fixes: 32e4930d5a3b ("crypto/nitrox: add hardware queue management")
> Fixes: 9fdef0cc2385 ("crypto/nitrox: create symmetric cryptodev")
>
> Signed-off-by: Nagadheeraj Rottela <rnagadheeraj@marvell.com>
> ---
Thomas,
Can you take this directly on master.
Thanks,
Akhil
^ permalink raw reply
* [PATCH v2 1/2] sparc,x86: vdso: remove meaningless undefining CONFIG_OPTIMIZE_INLINING
From: Masahiro Yamada @ 2020-02-20 11:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Ingo Molnar, Thomas Gleixner, x86,
clang-built-linux, Miguel Ojeda, sparclinux, Masahiro Yamada,
Andy Lutomirski, Borislav Petkov, David S. Miller, H. Peter Anvin,
linux-kernel
The code, #undef CONFIG_OPTIMIZE_INLINING, is not working as expected
because <linux/compiler_types.h> is parsed before vclock_gettime.c
since 28128c61e08e ("kconfig.h: Include compiler types to avoid missed
struct attributes").
Since then, <linux/compiler_types.h> is included really early by
using the '-include' option. So, you cannot negate the decision of
<linux/compiler_types.h> in this way.
You can confirm it by checking the pre-processed code, like this:
$ make arch/x86/entry/vdso/vdso32/vclock_gettime.i
There is no difference with/without CONFIG_CC_OPTIMIZE_FOR_SIZE.
It is about two years since 28128c61e08e. Nobody has reported a
problem (or, nobody has even noticed the fact that this code is not
working).
It is ugly and unreliable to attempt to undefine a CONFIG option from
C files, and anyway the inlining heuristic is up to the compiler.
Just remove the broken code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
---
Changes in v2:
- fix a type
- add Acked-by
arch/sparc/vdso/vdso32/vclock_gettime.c | 4 ----
arch/x86/entry/vdso/vdso32/vclock_gettime.c | 4 ----
2 files changed, 8 deletions(-)
diff --git a/arch/sparc/vdso/vdso32/vclock_gettime.c b/arch/sparc/vdso/vdso32/vclock_gettime.c
index 026abb3b826c..d7f99e6745ea 100644
--- a/arch/sparc/vdso/vdso32/vclock_gettime.c
+++ b/arch/sparc/vdso/vdso32/vclock_gettime.c
@@ -4,10 +4,6 @@
#define BUILD_VDSO32
-#ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
-#undef CONFIG_OPTIMIZE_INLINING
-#endif
-
#ifdef CONFIG_SPARC64
/*
diff --git a/arch/x86/entry/vdso/vdso32/vclock_gettime.c b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
index 9242b28418d5..3c26488db94d 100644
--- a/arch/x86/entry/vdso/vdso32/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
@@ -1,10 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#define BUILD_VDSO32
-#ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
-#undef CONFIG_OPTIMIZE_INLINING
-#endif
-
#ifdef CONFIG_X86_64
/*
--
2.17.1
^ permalink raw reply related
* [PATCH v2 2/2] compiler: Remove CONFIG_OPTIMIZE_INLINING entirely
From: Masahiro Yamada @ 2020-02-20 11:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Ingo Molnar, Thomas Gleixner, x86,
clang-built-linux, Miguel Ojeda, sparclinux, Masahiro Yamada,
Borislav Petkov, H. Peter Anvin, linux-kernel
In-Reply-To: <20200220110807.32534-1-masahiroy@kernel.org>
Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
forcibly") made this always-on option. We released v5.4 and v5.5
including that commit.
Remove the CONFIG option and clean up the code now.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
---
Changes in v2:
- add Reviewed-by
arch/x86/configs/i386_defconfig | 1 -
arch/x86/configs/x86_64_defconfig | 1 -
include/linux/compiler_types.h | 11 +----------
kernel/configs/tiny.config | 1 -
lib/Kconfig.debug | 12 ------------
5 files changed, 1 insertion(+), 25 deletions(-)
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 59ce9ed58430..d961d831c266 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -288,7 +288,6 @@ CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_DEBUG_BOOT_PARAMS=y
-CONFIG_OPTIMIZE_INLINING=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SELINUX=y
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index 0b9654c7a05c..4826254c6140 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -285,7 +285,6 @@ CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_DEBUG_BOOT_PARAMS=y
-CONFIG_OPTIMIZE_INLINING=y
CONFIG_UNWINDER_ORC=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 72393a8c1a6c..e970f97a7fcb 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -129,22 +129,13 @@ struct ftrace_likely_data {
#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
/*
- * Force always-inline if the user requests it so via the .config.
* Prefer gnu_inline, so that extern inline functions do not emit an
* externally visible function. This makes extern inline behave as per gnu89
* semantics rather than c99. This prevents multiple symbol definition errors
* of extern inline functions at link time.
* A lot of inline functions can cause havoc with function tracing.
- * Do not use __always_inline here, since currently it expands to inline again
- * (which would break users of __always_inline).
*/
-#if !defined(CONFIG_OPTIMIZE_INLINING)
-#define inline inline __attribute__((__always_inline__)) __gnu_inline \
- __inline_maybe_unused notrace
-#else
-#define inline inline __gnu_inline \
- __inline_maybe_unused notrace
-#endif
+#define inline inline __gnu_inline __inline_maybe_unused notrace
/*
* gcc provides both __inline__ and __inline as alternate spellings of
diff --git a/kernel/configs/tiny.config b/kernel/configs/tiny.config
index 7fa0c4ae6394..8a44b93da0f3 100644
--- a/kernel/configs/tiny.config
+++ b/kernel/configs/tiny.config
@@ -6,7 +6,6 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
-CONFIG_OPTIMIZE_INLINING=y
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 69def4a9df00..5abde39c3c69 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -305,18 +305,6 @@ config HEADERS_INSTALL
user-space program samples. It is also needed by some features such
as uapi header sanity checks.
-config OPTIMIZE_INLINING
- def_bool y
- help
- This option determines if the kernel forces gcc to inline the functions
- developers have marked 'inline'. Doing so takes away freedom from gcc to
- do what it thinks is best, which is desirable for the gcc 3.x series of
- compilers. The gcc 4.x series have a rewritten inlining algorithm and
- enabling this option will generate a smaller kernel there. Hopefully
- this algorithm is so good that allowing gcc 4.x and above to make the
- decision will become the default in the future. Until then this option
- is there to test gcc for this.
-
config DEBUG_SECTION_MISMATCH
bool "Enable full Section mismatch analysis"
help
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 2/3] PCI: brcmstb: Add regulator support
From: Gregory Fong @ 2020-02-20 11:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: Jaedon Shin, Nicolas Saenz Julienne, bcm-kernel-feedback-list,
Jim Quinlan, Bjorn Helgaas, Rob Herring, Mark Rutland,
Lorenzo Pieralisi, Andrew Murray, Linus Walleij,
Bartosz Golaszewski, linux-gpio, linux-arm-kernel, linux-pci
In-Reply-To: <aaa85a4d-8b36-893e-3e7a-dc27b4d6bae5@gmail.com>
On Wed, Feb 12, 2020 at 7:58 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 2/12/2020 6:59 PM, Jaedon Shin wrote:
> > ARM-based Broadcom STB SoCs have GPIO-based voltage regulator for PCIe
> > turning off/on power supplies.
> >
> > Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
> > ---
> > drivers/gpio/gpio-brcmstb.c | 13 ++++-
> > drivers/pci/controller/pcie-brcmstb.c | 76 +++++++++++++++++++++++++++
> > 2 files changed, 88 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
> > index 05e3f99ae59c..0cee5fcd2782 100644
> > --- a/drivers/gpio/gpio-brcmstb.c
> > +++ b/drivers/gpio/gpio-brcmstb.c
> > @@ -777,7 +777,18 @@ static struct platform_driver brcmstb_gpio_driver = {
> > .remove = brcmstb_gpio_remove,
> > .shutdown = brcmstb_gpio_shutdown,
> > };
> > -module_platform_driver(brcmstb_gpio_driver);
> > +
> > +static int __init brcmstb_gpio_init(void)
> > +{
> > + return platform_driver_register(&brcmstb_gpio_driver);
> > +}
> > +subsys_initcall(brcmstb_gpio_init);
> > +
> > +static void __exit brcmstb_gpio_exit(void)
> > +{
> > + platform_driver_unregister(&brcmstb_gpio_driver);
> > +}
> > +module_exit(brcmstb_gpio_exit);
>
> We do this in the downstream tree, but there is no reason, we should
> just deal with EPROBE_DEFER being returned from the regulator subsystem
> until the GPIO provide is available.
>
Agreed, also see this thread from January 2016:
https://lore.kernel.org/linux-mips/568EAA99.1020603@gmail.com/
Best regards,
Gregory
^ permalink raw reply
* Re: [PATCH 2/3] PCI: brcmstb: Add regulator support
From: Gregory Fong @ 2020-02-20 11:07 UTC (permalink / raw)
To: Florian Fainelli
Cc: Mark Rutland, Lorenzo Pieralisi, linux-gpio, linux-pci,
Linus Walleij, Jaedon Shin, Bartosz Golaszewski, Rob Herring,
bcm-kernel-feedback-list, linux-arm-kernel, Jim Quinlan,
Bjorn Helgaas, Nicolas Saenz Julienne, Andrew Murray
In-Reply-To: <aaa85a4d-8b36-893e-3e7a-dc27b4d6bae5@gmail.com>
On Wed, Feb 12, 2020 at 7:58 PM Florian Fainelli <f.fainelli@gmail.com> wrote:
> On 2/12/2020 6:59 PM, Jaedon Shin wrote:
> > ARM-based Broadcom STB SoCs have GPIO-based voltage regulator for PCIe
> > turning off/on power supplies.
> >
> > Signed-off-by: Jaedon Shin <jaedon.shin@gmail.com>
> > ---
> > drivers/gpio/gpio-brcmstb.c | 13 ++++-
> > drivers/pci/controller/pcie-brcmstb.c | 76 +++++++++++++++++++++++++++
> > 2 files changed, 88 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
> > index 05e3f99ae59c..0cee5fcd2782 100644
> > --- a/drivers/gpio/gpio-brcmstb.c
> > +++ b/drivers/gpio/gpio-brcmstb.c
> > @@ -777,7 +777,18 @@ static struct platform_driver brcmstb_gpio_driver = {
> > .remove = brcmstb_gpio_remove,
> > .shutdown = brcmstb_gpio_shutdown,
> > };
> > -module_platform_driver(brcmstb_gpio_driver);
> > +
> > +static int __init brcmstb_gpio_init(void)
> > +{
> > + return platform_driver_register(&brcmstb_gpio_driver);
> > +}
> > +subsys_initcall(brcmstb_gpio_init);
> > +
> > +static void __exit brcmstb_gpio_exit(void)
> > +{
> > + platform_driver_unregister(&brcmstb_gpio_driver);
> > +}
> > +module_exit(brcmstb_gpio_exit);
>
> We do this in the downstream tree, but there is no reason, we should
> just deal with EPROBE_DEFER being returned from the regulator subsystem
> until the GPIO provide is available.
>
Agreed, also see this thread from January 2016:
https://lore.kernel.org/linux-mips/568EAA99.1020603@gmail.com/
Best regards,
Gregory
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial: samsung_tty: remove SERIAL_SAMSUNG_DEBUG
From: Greg Kroah-Hartman @ 2020-02-20 11:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-serial, Kukjin Kim, Donghoon Yu, Hyunki Koo, HYUN-KI KOO,
Shinbeom Choi, Jiri Slaby, linux-arm-kernel, linux-samsung-soc,
linux-kernel
In-Reply-To: <20200220105541.GB24587@pi3>
On Thu, Feb 20, 2020 at 11:55:41AM +0100, Krzysztof Kozlowski wrote:
> On Thu, Feb 20, 2020 at 11:26:28AM +0100, Greg Kroah-Hartman wrote:
> > Since a05025d0ce72 ("tty: serial: samsung_tty: use standard debugging
> > macros") this configuration option is not used at all, so remove it from
> > the Kconfig file.
> >
> > Cc: Kukjin Kim <kgene@kernel.org>
> > Cc: Donghoon Yu <hoony.yu@samsung.com>
> > Cc: Hyunki Koo <kkoos00@naver.com>
> > Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> > Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > Cc: Jiri Slaby <jslaby@suse.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-samsung-soc@vger.kernel.org
> > Cc: linux-serial@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > drivers/tty/serial/Kconfig | 9 ---------
> > 1 file changed, 9 deletions(-)
>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Thanks for the quick review of both of these!
greg k-h
^ permalink raw reply
* Re: [PATCH 2/2] tty: serial: samsung_tty: remove SERIAL_SAMSUNG_DEBUG
From: Greg Kroah-Hartman @ 2020-02-20 11:09 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Donghoon Yu, linux-samsung-soc, linux-kernel, Shinbeom Choi,
Hyunki Koo, Kukjin Kim, linux-arm-kernel, linux-serial,
Jiri Slaby, HYUN-KI KOO
In-Reply-To: <20200220105541.GB24587@pi3>
On Thu, Feb 20, 2020 at 11:55:41AM +0100, Krzysztof Kozlowski wrote:
> On Thu, Feb 20, 2020 at 11:26:28AM +0100, Greg Kroah-Hartman wrote:
> > Since a05025d0ce72 ("tty: serial: samsung_tty: use standard debugging
> > macros") this configuration option is not used at all, so remove it from
> > the Kconfig file.
> >
> > Cc: Kukjin Kim <kgene@kernel.org>
> > Cc: Donghoon Yu <hoony.yu@samsung.com>
> > Cc: Hyunki Koo <kkoos00@naver.com>
> > Cc: HYUN-KI KOO <hyunki00.koo@samsung.com>
> > Cc: Shinbeom Choi <sbeom.choi@samsung.com>
> > Cc: Krzysztof Kozlowski <krzk@kernel.org>
> > Cc: Jiri Slaby <jslaby@suse.com>
> > Cc: linux-arm-kernel@lists.infradead.org
> > Cc: linux-samsung-soc@vger.kernel.org
> > Cc: linux-serial@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> > Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > ---
> > drivers/tty/serial/Kconfig | 9 ---------
> > 1 file changed, 9 deletions(-)
>
> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
Thanks for the quick review of both of these!
greg k-h
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 2/2] compiler: Remove CONFIG_OPTIMIZE_INLINING entirely
From: Masahiro Yamada @ 2020-02-20 11:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Ingo Molnar, Thomas Gleixner, x86,
clang-built-linux, Miguel Ojeda, sparclinux, Masahiro Yamada,
Borislav Petkov, H. Peter Anvin, linux-kernel
In-Reply-To: <20200220110807.32534-1-masahiroy@kernel.org>
Commit ac7c3e4ff401 ("compiler: enable CONFIG_OPTIMIZE_INLINING
forcibly") made this always-on option. We released v5.4 and v5.5
including that commit.
Remove the CONFIG option and clean up the code now.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
---
Changes in v2:
- add Reviewed-by
arch/x86/configs/i386_defconfig | 1 -
arch/x86/configs/x86_64_defconfig | 1 -
include/linux/compiler_types.h | 11 +----------
kernel/configs/tiny.config | 1 -
lib/Kconfig.debug | 12 ------------
5 files changed, 1 insertion(+), 25 deletions(-)
diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig
index 59ce9ed58430..d961d831c266 100644
--- a/arch/x86/configs/i386_defconfig
+++ b/arch/x86/configs/i386_defconfig
@@ -288,7 +288,6 @@ CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_DEBUG_BOOT_PARAMS=y
-CONFIG_OPTIMIZE_INLINING=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SELINUX=y
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index 0b9654c7a05c..4826254c6140 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -285,7 +285,6 @@ CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_DEBUG_BOOT_PARAMS=y
-CONFIG_OPTIMIZE_INLINING=y
CONFIG_UNWINDER_ORC=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 72393a8c1a6c..e970f97a7fcb 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -129,22 +129,13 @@ struct ftrace_likely_data {
#define __compiler_offsetof(a, b) __builtin_offsetof(a, b)
/*
- * Force always-inline if the user requests it so via the .config.
* Prefer gnu_inline, so that extern inline functions do not emit an
* externally visible function. This makes extern inline behave as per gnu89
* semantics rather than c99. This prevents multiple symbol definition errors
* of extern inline functions at link time.
* A lot of inline functions can cause havoc with function tracing.
- * Do not use __always_inline here, since currently it expands to inline again
- * (which would break users of __always_inline).
*/
-#if !defined(CONFIG_OPTIMIZE_INLINING)
-#define inline inline __attribute__((__always_inline__)) __gnu_inline \
- __inline_maybe_unused notrace
-#else
-#define inline inline __gnu_inline \
- __inline_maybe_unused notrace
-#endif
+#define inline inline __gnu_inline __inline_maybe_unused notrace
/*
* gcc provides both __inline__ and __inline as alternate spellings of
diff --git a/kernel/configs/tiny.config b/kernel/configs/tiny.config
index 7fa0c4ae6394..8a44b93da0f3 100644
--- a/kernel/configs/tiny.config
+++ b/kernel/configs/tiny.config
@@ -6,7 +6,6 @@ CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
-CONFIG_OPTIMIZE_INLINING=y
# CONFIG_SLAB is not set
# CONFIG_SLUB is not set
CONFIG_SLOB=y
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 69def4a9df00..5abde39c3c69 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -305,18 +305,6 @@ config HEADERS_INSTALL
user-space program samples. It is also needed by some features such
as uapi header sanity checks.
-config OPTIMIZE_INLINING
- def_bool y
- help
- This option determines if the kernel forces gcc to inline the functions
- developers have marked 'inline'. Doing so takes away freedom from gcc to
- do what it thinks is best, which is desirable for the gcc 3.x series of
- compilers. The gcc 4.x series have a rewritten inlining algorithm and
- enabling this option will generate a smaller kernel there. Hopefully
- this algorithm is so good that allowing gcc 4.x and above to make the
- decision will become the default in the future. Until then this option
- is there to test gcc for this.
-
config DEBUG_SECTION_MISMATCH
bool "Enable full Section mismatch analysis"
help
--
2.17.1
^ permalink raw reply related
* [PATCH v2 1/2] sparc,x86: vdso: remove meaningless undefining CONFIG_OPTIMIZE_INLINING
From: Masahiro Yamada @ 2020-02-20 11:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Arnd Bergmann, Ingo Molnar, Thomas Gleixner, x86,
clang-built-linux, Miguel Ojeda, sparclinux, Masahiro Yamada,
Andy Lutomirski, Borislav Petkov, David S. Miller, H. Peter Anvin,
linux-kernel
The code, #undef CONFIG_OPTIMIZE_INLINING, is not working as expected
because <linux/compiler_types.h> is parsed before vclock_gettime.c
since 28128c61e08e ("kconfig.h: Include compiler types to avoid missed
struct attributes").
Since then, <linux/compiler_types.h> is included really early by
using the '-include' option. So, you cannot negate the decision of
<linux/compiler_types.h> in this way.
You can confirm it by checking the pre-processed code, like this:
$ make arch/x86/entry/vdso/vdso32/vclock_gettime.i
There is no difference with/without CONFIG_CC_OPTIMIZE_FOR_SIZE.
It is about two years since 28128c61e08e. Nobody has reported a
problem (or, nobody has even noticed the fact that this code is not
working).
It is ugly and unreliable to attempt to undefine a CONFIG option from
C files, and anyway the inlining heuristic is up to the compiler.
Just remove the broken code.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
---
Changes in v2:
- fix a type
- add Acked-by
arch/sparc/vdso/vdso32/vclock_gettime.c | 4 ----
arch/x86/entry/vdso/vdso32/vclock_gettime.c | 4 ----
2 files changed, 8 deletions(-)
diff --git a/arch/sparc/vdso/vdso32/vclock_gettime.c b/arch/sparc/vdso/vdso32/vclock_gettime.c
index 026abb3b826c..d7f99e6745ea 100644
--- a/arch/sparc/vdso/vdso32/vclock_gettime.c
+++ b/arch/sparc/vdso/vdso32/vclock_gettime.c
@@ -4,10 +4,6 @@
#define BUILD_VDSO32
-#ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
-#undef CONFIG_OPTIMIZE_INLINING
-#endif
-
#ifdef CONFIG_SPARC64
/*
diff --git a/arch/x86/entry/vdso/vdso32/vclock_gettime.c b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
index 9242b28418d5..3c26488db94d 100644
--- a/arch/x86/entry/vdso/vdso32/vclock_gettime.c
+++ b/arch/x86/entry/vdso/vdso32/vclock_gettime.c
@@ -1,10 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
#define BUILD_VDSO32
-#ifndef CONFIG_CC_OPTIMIZE_FOR_SIZE
-#undef CONFIG_OPTIMIZE_INLINING
-#endif
-
#ifdef CONFIG_X86_64
/*
--
2.17.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.