* Re: [LKP] Re: [x86/mm/64] f154f29085: BUG:kernel_reboot-without-warning_in_boot_stage - clang KCOV?
From: Borislav Petkov @ 2022-01-05 11:36 UTC (permalink / raw)
To: Yin Fengwei
Cc: Marco Elver, Carel Si, Joerg Roedel, LKML, x86@kernel.org,
lkp@lists.01.org, lkp, bfields@fieldses.org, llvm@lists.linux.dev
In-Reply-To: <a5cb8140-5834-7649-e629-f2775cf5b9a9@intel.com>
On Wed, Jan 05, 2022 at 10:35:20AM +0800, Yin Fengwei wrote:
> Did you get update from clang folks for this behavior? Thanks.
No. Why?
--
Regards/Gruss,
Boris.
SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg
^ permalink raw reply
* Re: [PATCH 00/11] Add support for SUNIV and F1C100s.
From: Icenowy Zheng @ 2022-01-05 11:36 UTC (permalink / raw)
To: Jesse Taube, u-boot
Cc: jagan, andre.przywara, hdegoede, sjg, marek.behun, festevam,
narmstrong, tharvey, christianshewitt, pbrobinson, lokeshvutla,
jernej.skrabec, hs, samuel, arnaud.ferraris, giulio.benetti,
thirtythreeforty
In-Reply-To: <20220105003508.1143140-1-Mr.Bossman075@gmail.com>
在 2022-01-04星期二的 19:34 -0500，Jesse Taube写道：
> This patch set aims to add suport for the SUNIV and F1C100s.
> Suport has been in linux for a while now, but not in u-boot.
>
> This patchset contains:
> - CPU specific initialization code
> - SUNIV dram driver
> - SUNIV clock driver adaption
> - SUNIV gpio driver adaption
> - SUNIV uart driver adaption
> - F1C100s basic support
>
> I am hoping to get Icenowy's patches in as it seems she hasnt
> submitted
> in a while. The only edits I made to her code is rebasing it against
> ML
> and changing some formating. I also re-grouped her commits.
I got too lazy to send it (because I think F1C100s is just too weak)...
>
> I am wondering if the dram driver should be moved into device drivers
> rather than in mach-sunxi.
> I am also wondering if it is okay to submit some one elses code,
> and if so how should I do so.
As you are keeping my SoB and adding yours, it's totally okay.
Thanks for cleaning up these patches! ;-)
>
> Icenowy Zheng (11):
> arm: arm926ej-s: start.S: port save_boot_params support from armv7
> code
> arm: arm926ej-s: add sunxi code
> dt-bindings: clock: Add initial suniv headers
> dt-bindings: reset: Add initial suniv headers
> ARM: sunxi: Add support for F1C100s
> sunxi: Add F1C100s DRAM initial support
> sunxi: board: Add support for SUNIV
> configs: sunxi: Add common SUNIV header
> sunxi: Add support for SUNIV architecture
> ARM: dts: suniv: Add device tree files for F1C100s
> configs: sunxi: Add support for Lichee Pi Nano
>
> arch/arm/cpu/arm926ejs/Makefile | 1 +
> arch/arm/cpu/arm926ejs/start.S | 19 +
> arch/arm/cpu/arm926ejs/sunxi/Makefile | 15 +
> arch/arm/cpu/arm926ejs/sunxi/config.mk | 6 +
> arch/arm/cpu/arm926ejs/sunxi/fel_utils.S | 37 ++
> arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S | 67 +++
> arch/arm/cpu/arm926ejs/sunxi/start.c | 1 +
> arch/arm/cpu/arm926ejs/sunxi/timer.c | 114 +++++
> arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds | 62 +++
> arch/arm/dts/Makefile | 2 +
> arch/arm/dts/suniv-f1c100s-licheepi-nano.dts | 64 +++
> arch/arm/dts/suniv-f1c100s.dtsi | 6 +
> arch/arm/dts/suniv.dtsi | 224 ++++++++++
> arch/arm/include/asm/arch-sunxi/clock.h | 2 +-
> arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 25 ++
> arch/arm/include/asm/arch-sunxi/cpu_sun4i.h | 8 +
> arch/arm/include/asm/arch-sunxi/dram.h | 2 +
> arch/arm/include/asm/arch-sunxi/dram_suniv.h | 46 ++
> arch/arm/include/asm/arch-sunxi/gpio.h | 1 +
> arch/arm/mach-sunxi/Kconfig | 16 +-
> arch/arm/mach-sunxi/Makefile | 2 +
> arch/arm/mach-sunxi/board.c | 31 +-
> arch/arm/mach-sunxi/clock.c | 3 +-
> arch/arm/mach-sunxi/clock_sun6i.c | 46 +-
> arch/arm/mach-sunxi/cpu_info.c | 2 +
> arch/arm/mach-sunxi/dram_helpers.c | 4 +
> arch/arm/mach-sunxi/dram_suniv.c | 420
> ++++++++++++++++++
> board/sunxi/board.c | 4 +-
> configs/licheepi_nano_defconfig | 13 +
> configs/licheepi_nano_spiflash_defconfig | 25 ++
> include/configs/suniv.h | 14 +
> include/configs/sunxi-common.h | 67 ++-
> include/dt-bindings/clock/suniv-ccu.h | 68 +++
> include/dt-bindings/reset/suniv-ccu.h | 36 ++
> 34 files changed, 1424 insertions(+), 29 deletions(-)
> create mode 100644 arch/arm/cpu/arm926ejs/sunxi/Makefile
> create mode 100644 arch/arm/cpu/arm926ejs/sunxi/config.mk
> create mode 100644 arch/arm/cpu/arm926ejs/sunxi/fel_utils.S
> create mode 100644 arch/arm/cpu/arm926ejs/sunxi/lowlevel_init.S
> create mode 100644 arch/arm/cpu/arm926ejs/sunxi/start.c
> create mode 100644 arch/arm/cpu/arm926ejs/sunxi/timer.c
> create mode 100644 arch/arm/cpu/arm926ejs/sunxi/u-boot-spl.lds
> create mode 100644 arch/arm/dts/suniv-f1c100s-licheepi-nano.dts
> create mode 100644 arch/arm/dts/suniv-f1c100s.dtsi
> create mode 100644 arch/arm/dts/suniv.dtsi
> create mode 100644 arch/arm/include/asm/arch-sunxi/dram_suniv.h
> create mode 100644 arch/arm/mach-sunxi/dram_suniv.c
> create mode 100644 configs/licheepi_nano_defconfig
> create mode 100644 configs/licheepi_nano_spiflash_defconfig
> create mode 100644 include/configs/suniv.h
> create mode 100644 include/dt-bindings/clock/suniv-ccu.h
> create mode 100644 include/dt-bindings/reset/suniv-ccu.h
>
^ permalink raw reply
* [Cluster-devel] Upcoming change to the gfs2-utils.git repository
From: Andrew Price @ 2022-01-05 11:38 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <e9a2e359-685c-2497-d2bf-e36e2c474c7b@redhat.com>
On 04/01/2022 15:35, Andrew Price wrote:
> Happy new year, all!
>
> Just a heads-up that the main branch in gfs2-utils.git will be renamed
> from master to main tomorrow (January 5). I will follow the procedure here:
>
> ? https://wiki.clusterlabs.org/wiki/How_to_rename_git_default_branch
>
> The wiki page also has a section on how to update your local clone to
> use the new upstream branch name. Thanks to Ken for writing that up!
>
> This change affects https://pagure.io/gfs2-utils.git
>
> I will post a follow-up once the change has been completed.
This change is now complete. To update your gfs2-utils git branch
references locally, use:
$ git branch --set-upstream-to origin/main <branch>
for <branch>es that currently have origin/master as the remote ref.
To rename your local master branch to main:
$ git branch -m master main
Cheers,
Andy
^ permalink raw reply
* [PATCH] ASoC: fsl_asrc: refine the check of available clock divider
From: Shengjiu Wang @ 2022-01-05 11:08 UTC (permalink / raw)
To: timur, nicoleotsuka, Xiubo.Lee, festevam, broonie, alsa-devel,
lgirdwood, perex, tiwai
Cc: linuxppc-dev, linux-kernel
According to RM, the clock divider range is from 1 to 8, clock
prescaling ratio may be any power of 2 from 1 to 128.
So the supported divider is not all the value between
1 and 1024, just limited value in that range.
Create table for the supported divder and add function to
check the clock divider is available by comparing with
the table.
Fixes: d0250cf4f2ab ("ASoC: fsl_asrc: Add an option to select internal ratio mode")
Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com>
---
sound/soc/fsl/fsl_asrc.c | 69 +++++++++++++++++++++++++++++++++-------
1 file changed, 58 insertions(+), 11 deletions(-)
diff --git a/sound/soc/fsl/fsl_asrc.c b/sound/soc/fsl/fsl_asrc.c
index 24b41881a68f..d7d1536a4f37 100644
--- a/sound/soc/fsl/fsl_asrc.c
+++ b/sound/soc/fsl/fsl_asrc.c
@@ -19,6 +19,7 @@
#include "fsl_asrc.h"
#define IDEAL_RATIO_DECIMAL_DEPTH 26
+#define DIVIDER_NUM 64
#define pair_err(fmt, ...) \
dev_err(&asrc->pdev->dev, "Pair %c: " fmt, 'A' + index, ##__VA_ARGS__)
@@ -101,6 +102,55 @@ static unsigned char clk_map_imx8qxp[2][ASRC_CLK_MAP_LEN] = {
},
};
+/*
+ * According to RM, the divider range is 1 ~ 8,
+ * prescaler is power of 2 from 1 ~ 128.
+ */
+static int asrc_clk_divider[DIVIDER_NUM] = {
+ 1, 2, 4, 8, 16, 32, 64, 128, /* divider = 1 */
+ 2, 4, 8, 16, 32, 64, 128, 256, /* divider = 2 */
+ 3, 6, 12, 24, 48, 96, 192, 384, /* divider = 3 */
+ 4, 8, 16, 32, 64, 128, 256, 512, /* divider = 4 */
+ 5, 10, 20, 40, 80, 160, 320, 640, /* divider = 5 */
+ 6, 12, 24, 48, 96, 192, 384, 768, /* divider = 6 */
+ 7, 14, 28, 56, 112, 224, 448, 896, /* divider = 7 */
+ 8, 16, 32, 64, 128, 256, 512, 1024, /* divider = 8 */
+};
+
+/*
+ * Check if the divider is available for internal ratio mode
+ */
+static bool fsl_asrc_divider_avail(int clk_rate, int rate, int *div)
+{
+ u32 rem, i;
+ u64 n;
+
+ if (div)
+ *div = 0;
+
+ if (clk_rate == 0 || rate == 0)
+ return false;
+
+ n = clk_rate;
+ rem = do_div(n, rate);
+
+ if (div)
+ *div = n;
+
+ if (rem != 0)
+ return false;
+
+ for (i = 0; i < DIVIDER_NUM; i++) {
+ if (n == asrc_clk_divider[i])
+ break;
+ }
+
+ if (i == DIVIDER_NUM)
+ return false;
+
+ return true;
+}
+
/**
* fsl_asrc_sel_proc - Select the pre-processing and post-processing options
* @inrate: input sample rate
@@ -330,12 +380,12 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate)
enum asrc_word_width input_word_width;
enum asrc_word_width output_word_width;
u32 inrate, outrate, indiv, outdiv;
- u32 clk_index[2], div[2], rem[2];
+ u32 clk_index[2], div[2];
u64 clk_rate;
int in, out, channels;
int pre_proc, post_proc;
struct clk *clk;
- bool ideal;
+ bool ideal, div_avail;
if (!config) {
pair_err("invalid pair config\n");
@@ -415,8 +465,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate)
clk = asrc_priv->asrck_clk[clk_index[ideal ? OUT : IN]];
clk_rate = clk_get_rate(clk);
- rem[IN] = do_div(clk_rate, inrate);
- div[IN] = (u32)clk_rate;
+ div_avail = fsl_asrc_divider_avail(clk_rate, inrate, &div[IN]);
/*
* The divider range is [1, 1024], defined by the hardware. For non-
@@ -425,7 +474,7 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate)
* only result in different converting speeds. So remainder does not
* matter, as long as we keep the divider within its valid range.
*/
- if (div[IN] == 0 || (!ideal && (div[IN] > 1024 || rem[IN] != 0))) {
+ if (div[IN] == 0 || (!ideal && !div_avail)) {
pair_err("failed to support input sample rate %dHz by asrck_%x\n",
inrate, clk_index[ideal ? OUT : IN]);
return -EINVAL;
@@ -436,13 +485,12 @@ static int fsl_asrc_config_pair(struct fsl_asrc_pair *pair, bool use_ideal_rate)
clk = asrc_priv->asrck_clk[clk_index[OUT]];
clk_rate = clk_get_rate(clk);
if (ideal && use_ideal_rate)
- rem[OUT] = do_div(clk_rate, IDEAL_RATIO_RATE);
+ div_avail = fsl_asrc_divider_avail(clk_rate, IDEAL_RATIO_RATE, &div[OUT]);
else
- rem[OUT] = do_div(clk_rate, outrate);
- div[OUT] = clk_rate;
+ div_avail = fsl_asrc_divider_avail(clk_rate, outrate, &div[OUT]);
/* Output divider has the same limitation as the input one */
- if (div[OUT] == 0 || (!ideal && (div[OUT] > 1024 || rem[OUT] != 0))) {
+ if (div[OUT] == 0 || (!ideal && !div_avail)) {
pair_err("failed to support output sample rate %dHz by asrck_%x\n",
outrate, clk_index[OUT]);
return -EINVAL;
@@ -621,8 +669,7 @@ static void fsl_asrc_select_clk(struct fsl_asrc_priv *asrc_priv,
clk_index = asrc_priv->clk_map[j][i];
clk_rate = clk_get_rate(asrc_priv->asrck_clk[clk_index]);
/* Only match a perfect clock source with no remainder */
- if (clk_rate != 0 && (clk_rate / rate[j]) <= 1024 &&
- (clk_rate % rate[j]) == 0)
+ if (fsl_asrc_divider_avail(clk_rate, rate[j], NULL))
break;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
From: Baole Fang @ 2022-01-05 11:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Takashi Iwai
Cc: alsa-devel, Kailang Yang, Jeremy Szu, linux-kernel, Elia Devito,
Takashi Iwai, Werner Sembach, Hui Wang, Sami Loone,
Cameron Berkenpas
In-Reply-To: <YdV5MNWOwgrtH2UC@kroah.com>
Sorry, this is my first time to submit patch to Linux, so I'm not quite
familiar with the convention. Since I was changing based on v5.15.12 and
I saw others mentioning their upstream commit, I included the that
commit id.
Please forgive me and tell me what is supposed to be done if possible. I
still have a lot to learn.
Best Regards,
Baole Fang
On 2022/1/5 下午6:55, Greg Kroah-Hartman wrote:
> On Wed, Jan 05, 2022 at 09:26:16AM +0100, Takashi Iwai wrote:
>> On Wed, 05 Jan 2022 04:41:01 +0100,
>> Baole Fang wrote:
>>> commit 25960cafa06e6fcd830e6c792e6a7de68c1e25ed upstream.
>> I couldn't find this commit. Is this a bogus information?
>>
>>> Legion Y9000X 2020 has a speaker, but the speaker doesn't work.
>>> This can be fixed by applying alc285_fixup_ideapad_s740_coef
>>> to fix the speaker's coefficients.
>>> Besides, to support the transition between the speaker and the headphone,
>>> alc287_fixup_legion_15imhg05_speakers needs to be run.
>>>
>>> Signed-off-by: Baole Fang <fbl718@163.com>
>> The code change itself looks fine, so I'd apply it if the line above
>> can be omitted.
> That commit id comes from 5.15.12, and it is the commit id of the
> release commit:
> 25960cafa06e ("Linux 5.15.12")
> which makes no sense at all.
>
> Baole, why did you add this line?
>
> confused,
>
> greg k-h
^ permalink raw reply
* [PATCH] media: bdisp: Fix PM disable depth imbalance in bdisp_probe
From: Miaoqian Lin @ 2022-01-05 11:41 UTC (permalink / raw)
Cc: linmq006, Fabien Dessenne, Mauro Carvalho Chehab, Hans Verkuil,
linux-media, linux-kernel
The pm_runtime_enable will increase power disable depth.
If the probe fails, we should use pm_runtime_disable() to balance
pm_runtime_enable().
Fixes: 28ffeeb ("[media] bdisp: 2D blitter driver using v4l2 mem2mem framework")
Signed-off-by: Miaoqian Lin <linmq006@gmail.com>
---
drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
index 7d467f2ba072..ded4d026f84c 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
@@ -1396,6 +1396,8 @@ static int bdisp_probe(struct platform_device *pdev)
err_remove:
bdisp_debugfs_remove(bdisp);
v4l2_device_unregister(&bdisp->v4l2_dev);
+disable_pm_runtime:
+ pm_runtime_disable(dev);
err_clk:
if (!IS_ERR(bdisp->clock))
clk_unprepare(bdisp->clock);
--
2.17.1
^ permalink raw reply related
* Re: [PATCH] ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
From: Baole Fang @ 2022-01-05 11:39 UTC (permalink / raw)
To: Greg Kroah-Hartman, Takashi Iwai
Cc: Jaroslav Kysela, Takashi Iwai, Jeremy Szu, Werner Sembach,
Hui Wang, Cameron Berkenpas, Kailang Yang, Sami Loone,
Elia Devito, alsa-devel, linux-kernel
In-Reply-To: <YdV5MNWOwgrtH2UC@kroah.com>
Sorry, this is my first time to submit patch to Linux, so I'm not quite
familiar with the convention. Since I was changing based on v5.15.12 and
I saw others mentioning their upstream commit, I included the that
commit id.
Please forgive me and tell me what is supposed to be done if possible. I
still have a lot to learn.
Best Regards,
Baole Fang
On 2022/1/5 下午6:55, Greg Kroah-Hartman wrote:
> On Wed, Jan 05, 2022 at 09:26:16AM +0100, Takashi Iwai wrote:
>> On Wed, 05 Jan 2022 04:41:01 +0100,
>> Baole Fang wrote:
>>> commit 25960cafa06e6fcd830e6c792e6a7de68c1e25ed upstream.
>> I couldn't find this commit. Is this a bogus information?
>>
>>> Legion Y9000X 2020 has a speaker, but the speaker doesn't work.
>>> This can be fixed by applying alc285_fixup_ideapad_s740_coef
>>> to fix the speaker's coefficients.
>>> Besides, to support the transition between the speaker and the headphone,
>>> alc287_fixup_legion_15imhg05_speakers needs to be run.
>>>
>>> Signed-off-by: Baole Fang <fbl718@163.com>
>> The code change itself looks fine, so I'd apply it if the line above
>> can be omitted.
> That commit id comes from 5.15.12, and it is the commit id of the
> release commit:
> 25960cafa06e ("Linux 5.15.12")
> which makes no sense at all.
>
> Baole, why did you add this line?
>
> confused,
>
> greg k-h
^ permalink raw reply
* Re: [PATCH v2 07/10] dts: dra7-ipu-common-early-boot.dtsi: Add all the ipu early boot related nodes
From: Amjad Ouled-Ameur @ 2022-01-05 11:42 UTC (permalink / raw)
To: Tom Rini; +Cc: u-boot, khilman, Keerthy
In-Reply-To: <20211011185939.GA36912@bill-the-cat>
Hi Tom,
On 11/10/2021 20:59, Tom Rini wrote:
> On Thu, Sep 30, 2021 at 06:21:08PM +0200, Amjad Ouled-Ameur wrote:
>
>> From: Keerthy <j-keerthy@ti.com>
>>
>> Add all the ipu early boot related nodes
>>
>> Signed-off-by: Keerthy <j-keerthy@ti.com>
>> Signed-off-by: Amjad Ouled-Ameur <aouledameur@baylibre.com>
>> ---
>>
>> (no changes since v1)
>>
>> MAINTAINERS | 1 +
>> arch/arm/dts/dra7-ipu-common-early-boot.dtsi | 113 +++++++++++++++++++
>> 2 files changed, 114 insertions(+)
>> create mode 100644 arch/arm/dts/dra7-ipu-common-early-boot.dtsi
> This causes my J6 Eco board:
> CPU : DRA752-GP ES1.1
> Model: TI DRA742
> Board: DRA74x EVM REV G.0
> to stop booting in SPL with no output.
Thank you for reporting the issue.
After debugging the j6eco board, I realized that board stops booting
in SPL when new nodes with "u-boot,dm-spl;"property are added to the
DTS. The issue seems to be unrelated to this patchset but rather to a
SPL's DTS limitation on j6eco. I am currently looking into SPL's linker
file
and load addresses to understand better why SPL breaks.
Regards,
Amjad
>
^ permalink raw reply
* Re: [PATCH v6 0/5] Allow guest access to EFI confidential computing secret area
From: Dr. David Alan Gilbert @ 2022-01-05 11:43 UTC (permalink / raw)
To: Borislav Petkov
Cc: Dov Murik, Brijesh Singh, Tom Lendacky, linux-efi, Ashish Kalra,
Ard Biesheuvel, James Morris, Serge E. Hallyn, Andi Kleen,
Greg KH, Andrew Scull, Dave Hansen, James Bottomley,
Tobin Feldman-Fitzthum, Jim Cadden, Daniele Buono, linux-coco,
linux-security-module, linux-kernel
In-Reply-To: <YdSRWmqdNY7jRcer@zn.tnic>
* Borislav Petkov (bp@suse.de) wrote:
> On Tue, Jan 04, 2022 at 09:02:03AM +0200, Dov Murik wrote:
> > If the Guest Owner chooses to inject secrets via scp, it needs
> > to be sure it is scp-ing to the correct VM - the one that has SEV
> > enabled and was measured at launch.
>
> Hmm, I'd expect that to be part of the attestation dance. I admit,
> though, I have only listened about the whole attestation bla from the
> sidelines so I'm unclear whether that's part of that protocol. I guess
> Tom and Brijesh should have a better idea here.
There's more than one type of dance; this partially varies
depending on the system (SEV/TDX etc) and also depends on how you depend
to boot your VM (separate kernel or VM disk). Also it's important to
note that when the dance happens varies - in SEV and SEV-ES this happens
before the guest executes any code.
So at the end of the dance, the guest owner hands over that secret - but
only then does the geust start booting; that secret has to go somewhere
to be used by something later.
For example, something might pull out that key and use it to decrypt a
disk that then has other secrets on it (e.g. your ssh key).
Dave
> > One way to achieve that would be to inject the guest's SSH private key
>
> Well, is that "one way" or *the way*?
>
> > using the proposed efi_secret mechanism. This way the Guest Owner is
> > sure it is talking to the correct guest and not to some other VM that
> > was started by the untrusted cloud provider (say, with SEV disabled so
> > the cloud provider can steal its memory content).
>
> Because we would need *some* way of verifying the owner is talking
> to the correct guest. And if so, this should be made part of the big
> picture of SEV guest attestation. Or is this part of that attestation
> dance?
>
> I guess I'm wondering where in the big picture this fits into?
>
> > Indeed this proposed efi_secret module is in use for enabling SEV
> > confidential containers using Kata containers [1], but there's nothing
> > specific in the current patch series about containers. The patch series
> > just exposes the launch-injected SEV secrets to userspace as virtual files
> > (under securityfs).
> >
> > [1] https://github.com/confidential-containers/attestation-agent/tree/main/src/kbc_modules/offline_sev_kbc
>
> So one of the aspects for this is to use it in automated deployments.
>
> > It boils down to: the confidential guest needs to have access to a
> > secret which the untrusted host can't read, and which is essential for
> > the normal operation of the guest. This secret can be a decryption key,
> > an SSH private key, an API key to a Key Management system, etc. If a
> > malicious cloud provider tries to start that VM without a secret (or
> > with the wrong one), the actual workload that the guest is supposed to
> > run will not execute meaningfully.
> >
> > The proposed patch series exposes the SEV injected secrets as virtual
> > files, which can later be used as decryption keys (as done in the kata
> > confidential containers use-case), or SSH private keys, or any other
> > possible implementation.
>
> Right, and is this going to be the proper way to authenticate SEV guests
> to their owners or is this just another technique for safely supplying
> secrets into the guest?
>
> I hope I'm making some sense here...
>
> --
> Regards/Gruss,
> Boris.
>
> SUSE Software Solutions Germany GmbH, GF: Ivo Totev, HRB 36809, AG Nürnberg
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
^ permalink raw reply
* [Intel-wired-lan] [syzbot] kernel BUG in pskb_expand_head
From: Marc Kleine-Budde @ 2022-01-05 11:44 UTC (permalink / raw)
To: intel-wired-lan
In-Reply-To: <0000000000000fbea205d388d749@google.com>
On 19.12.2021 16:19:20, syzbot wrote:
> skb_over_panic net/core/skbuff.c:118 [inline]
> skb_over_panic net/core/skbuff.c:118 [inline] net/core/skbuff.c:1986
> skb_put.cold+0x24/0x24 net/core/skbuff.c:1986 net/core/skbuff.c:1986
> isotp_rcv_cf net/can/isotp.c:570 [inline]
> isotp_rcv_cf net/can/isotp.c:570 [inline] net/can/isotp.c:668
> isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 net/can/isotp.c:668
> struct tpcon {
> int idx;
> int len;
^^^
> u32 state;
> u8 bs;
> u8 sn;
> u8 ll_dl;
> u8 buf[MAX_MSG_LENGTH + 1];
> };
>
> static int isotp_rcv_ff(struct sock *sk, struct canfd_frame *cf, int ae)
> {
[...]
> /* Check for FF_DL escape sequence supporting 32 bit PDU length */
> if (so->rx.len) {
> ff_pci_sz = FF_PCI_SZ12;
> } else {
> /* FF_DL = 0 => get real length from next 4 bytes */
> so->rx.len = cf->data[ae + 2] << 24;
> so->rx.len += cf->data[ae + 3] << 16;
> so->rx.len += cf->data[ae + 4] << 8;
> so->rx.len += cf->data[ae + 5];
> ff_pci_sz = FF_PCI_SZ32;
> }
Full 32 Bit PDUs don't work with struct tpcon::len being an "int". I
think converting it to "unsigned int" should be done.
[...]
> }
>
> static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae,
> struct sk_buff *skb)
> {
> struct isotp_sock *so = isotp_sk(sk);
> struct sk_buff *nskb;
> int i;
>
> if (so->rx.state != ISOTP_WAIT_DATA)
> return 0;
>
> /* drop if timestamp gap is less than force_rx_stmin nano secs */
> if (so->opt.flags & CAN_ISOTP_FORCE_RXSTMIN) {
> if (ktime_to_ns(ktime_sub(skb->tstamp, so->lastrxcf_tstamp)) <
> so->force_rx_stmin)
> return 0;
>
> so->lastrxcf_tstamp = skb->tstamp;
> }
>
> hrtimer_cancel(&so->rxtimer);
>
> /* CFs are never longer than the FF */
> if (cf->len > so->rx.ll_dl)
> return 1;
>
> /* CFs have usually the LL_DL length */
> if (cf->len < so->rx.ll_dl) {
> /* this is only allowed for the last CF */
> if (so->rx.len - so->rx.idx > so->rx.ll_dl - ae - N_PCI_SZ)
> return 1;
> }
>
> if ((cf->data[ae] & 0x0F) != so->rx.sn) {
> /* wrong sn detected - report 'illegal byte sequence' */
> sk->sk_err = EILSEQ;
> if (!sock_flag(sk, SOCK_DEAD))
> sk_error_report(sk);
>
> /* reset rx state */
> so->rx.state = ISOTP_IDLE;
> return 1;
> }
> so->rx.sn++;
> so->rx.sn %= 16;
>
> for (i = ae + N_PCI_SZ; i < cf->len; i++) {
> so->rx.buf[so->rx.idx++] = cf->data[i];
> if (so->rx.idx >= so->rx.len)
> break;
> }
>
> if (so->rx.idx >= so->rx.len) {
> /* we are done */
> so->rx.state = ISOTP_IDLE;
>
> if ((so->opt.flags & ISOTP_CHECK_PADDING) &&
> check_pad(so, cf, i + 1, so->opt.rxpad_content)) {
> /* malformed PDU - report 'not a data message' */
> sk->sk_err = EBADMSG;
> if (!sock_flag(sk, SOCK_DEAD))
> sk_error_report(sk);
> return 1;
> }
>
> nskb = alloc_skb(so->rx.len, gfp_any());
> if (!nskb)
> return 1;
>
> memcpy(skb_put(nskb, so->rx.len), so->rx.buf,
^^^^^^^
> so->rx.len);
This is where the skb_over_panic() happens.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.osuosl.org/pipermail/intel-wired-lan/attachments/20220105/f5328330/attachment-0001.asc>
^ permalink raw reply
* Re: [PATCH] ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
From: Greg Kroah-Hartman @ 2022-01-05 11:44 UTC (permalink / raw)
To: Baole Fang
Cc: Takashi Iwai, Jaroslav Kysela, Takashi Iwai, Jeremy Szu,
Werner Sembach, Hui Wang, Cameron Berkenpas, Kailang Yang,
Sami Loone, Elia Devito, alsa-devel, linux-kernel
In-Reply-To: <757a4402-1067-e3c8-8ca3-43ee62047ebe@163.com>
On Wed, Jan 05, 2022 at 07:39:33PM +0800, Baole Fang wrote:
> Sorry, this is my first time to submit patch to Linux, so I'm not quite
> familiar with the convention. Since I was changing based on v5.15.12 and I
> saw others mentioning their upstream commit, I included the that commit id.
Those commits were coming from the stable backports only, they were not
done by the original author.
> Please forgive me and tell me what is supposed to be done if possible. I
> still have a lot to learn.
Please take a look at the "first kernel patch" tutorial on the
kernelnewbies.org site for a good example of how to do all of this.
Also the Documentation/SubmittingPatches file in the kernel source tree
should help out.
thanks,
greg k-h
^ permalink raw reply
* Re: [syzbot] kernel BUG in pskb_expand_head
From: Marc Kleine-Budde @ 2022-01-05 11:44 UTC (permalink / raw)
To: syzbot
Cc: anthony.l.nguyen, davem, eric.dumazet, hawk,
intel-wired-lan-owner, intel-wired-lan, jesse.brandeburg, kuba,
linux-can, linux-kernel, netdev, socketcan, syzkaller-bugs
In-Reply-To: <0000000000000fbea205d388d749@google.com>
[-- Attachment #1: Type: text/plain, Size: 3467 bytes --]
On 19.12.2021 16:19:20, syzbot wrote:
> skb_over_panic net/core/skbuff.c:118 [inline]
> skb_over_panic net/core/skbuff.c:118 [inline] net/core/skbuff.c:1986
> skb_put.cold+0x24/0x24 net/core/skbuff.c:1986 net/core/skbuff.c:1986
> isotp_rcv_cf net/can/isotp.c:570 [inline]
> isotp_rcv_cf net/can/isotp.c:570 [inline] net/can/isotp.c:668
> isotp_rcv+0xa38/0x1e30 net/can/isotp.c:668 net/can/isotp.c:668
> struct tpcon {
> int idx;
> int len;
^^^
> u32 state;
> u8 bs;
> u8 sn;
> u8 ll_dl;
> u8 buf[MAX_MSG_LENGTH + 1];
> };
>
> static int isotp_rcv_ff(struct sock *sk, struct canfd_frame *cf, int ae)
> {
[...]
> /* Check for FF_DL escape sequence supporting 32 bit PDU length */
> if (so->rx.len) {
> ff_pci_sz = FF_PCI_SZ12;
> } else {
> /* FF_DL = 0 => get real length from next 4 bytes */
> so->rx.len = cf->data[ae + 2] << 24;
> so->rx.len += cf->data[ae + 3] << 16;
> so->rx.len += cf->data[ae + 4] << 8;
> so->rx.len += cf->data[ae + 5];
> ff_pci_sz = FF_PCI_SZ32;
> }
Full 32 Bit PDUs don't work with struct tpcon::len being an "int". I
think converting it to "unsigned int" should be done.
[...]
> }
>
> static int isotp_rcv_cf(struct sock *sk, struct canfd_frame *cf, int ae,
> struct sk_buff *skb)
> {
> struct isotp_sock *so = isotp_sk(sk);
> struct sk_buff *nskb;
> int i;
>
> if (so->rx.state != ISOTP_WAIT_DATA)
> return 0;
>
> /* drop if timestamp gap is less than force_rx_stmin nano secs */
> if (so->opt.flags & CAN_ISOTP_FORCE_RXSTMIN) {
> if (ktime_to_ns(ktime_sub(skb->tstamp, so->lastrxcf_tstamp)) <
> so->force_rx_stmin)
> return 0;
>
> so->lastrxcf_tstamp = skb->tstamp;
> }
>
> hrtimer_cancel(&so->rxtimer);
>
> /* CFs are never longer than the FF */
> if (cf->len > so->rx.ll_dl)
> return 1;
>
> /* CFs have usually the LL_DL length */
> if (cf->len < so->rx.ll_dl) {
> /* this is only allowed for the last CF */
> if (so->rx.len - so->rx.idx > so->rx.ll_dl - ae - N_PCI_SZ)
> return 1;
> }
>
> if ((cf->data[ae] & 0x0F) != so->rx.sn) {
> /* wrong sn detected - report 'illegal byte sequence' */
> sk->sk_err = EILSEQ;
> if (!sock_flag(sk, SOCK_DEAD))
> sk_error_report(sk);
>
> /* reset rx state */
> so->rx.state = ISOTP_IDLE;
> return 1;
> }
> so->rx.sn++;
> so->rx.sn %= 16;
>
> for (i = ae + N_PCI_SZ; i < cf->len; i++) {
> so->rx.buf[so->rx.idx++] = cf->data[i];
> if (so->rx.idx >= so->rx.len)
> break;
> }
>
> if (so->rx.idx >= so->rx.len) {
> /* we are done */
> so->rx.state = ISOTP_IDLE;
>
> if ((so->opt.flags & ISOTP_CHECK_PADDING) &&
> check_pad(so, cf, i + 1, so->opt.rxpad_content)) {
> /* malformed PDU - report 'not a data message' */
> sk->sk_err = EBADMSG;
> if (!sock_flag(sk, SOCK_DEAD))
> sk_error_report(sk);
> return 1;
> }
>
> nskb = alloc_skb(so->rx.len, gfp_any());
> if (!nskb)
> return 1;
>
> memcpy(skb_put(nskb, so->rx.len), so->rx.buf,
^^^^^^^
> so->rx.len);
This is where the skb_over_panic() happens.
regards,
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Embedded Linux | https://www.pengutronix.de |
Vertretung West/Dortmund | Phone: +49-231-2826-924 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] ALSA: hda/realtek: Add quirk for Legion Y9000X 2020
From: Greg Kroah-Hartman @ 2022-01-05 11:44 UTC (permalink / raw)
To: Baole Fang
Cc: alsa-devel, Kailang Yang, Jeremy Szu, Takashi Iwai, linux-kernel,
Elia Devito, Takashi Iwai, Werner Sembach, Hui Wang, Sami Loone,
Cameron Berkenpas
In-Reply-To: <757a4402-1067-e3c8-8ca3-43ee62047ebe@163.com>
On Wed, Jan 05, 2022 at 07:39:33PM +0800, Baole Fang wrote:
> Sorry, this is my first time to submit patch to Linux, so I'm not quite
> familiar with the convention. Since I was changing based on v5.15.12 and I
> saw others mentioning their upstream commit, I included the that commit id.
Those commits were coming from the stable backports only, they were not
done by the original author.
> Please forgive me and tell me what is supposed to be done if possible. I
> still have a lot to learn.
Please take a look at the "first kernel patch" tutorial on the
kernelnewbies.org site for a good example of how to do all of this.
Also the Documentation/SubmittingPatches file in the kernel source tree
should help out.
thanks,
greg k-h
^ permalink raw reply
* Re: mt7621 i2c fails with upstream driver
From: Kristian Evensen @ 2022-01-05 11:45 UTC (permalink / raw)
To: linux-i2c
In-Reply-To: <CAKfDRXgUvN19PUd_ebRJs-k_ytrGwgA=e6d3QJ9cwJogUGpoyw@mail.gmail.com>
Hi again,
On Wed, Jan 5, 2022 at 10:51 AM Kristian Evensen
<kristian.evensen@gmail.com> wrote:
> Replacing the new with the old driver makes i2c work again, but I
> would like to try to avoid that. My knowledge of i2c is very limited,
> so I wondered if anyone knows what could be wrong or have any
> suggestions on things I can try to for example change in the driver?
I spent some more time instrumenting the driver. The call that always
times out is the call to mtk_i2c_master_start() made from
mtk_i2c_master_xfer(). From what I can tell, this is the first time
data is written and when I compared with the previous driver, I do not
find equivalents of master_{start,stop,cmd} writes, I only see direct
calls to iowrite/ioread.
Kristian
^ permalink raw reply
* Linux kernel 4.9.296 released
From: Linux Kernel Distribution System @ 2022-01-05 11:45 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 4.9.296 is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.296.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.9.296.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.9.296.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v4.9.296/v4.9.295
^ permalink raw reply
* Linux kernel 4.4.298 released
From: Linux Kernel Distribution System @ 2022-01-05 11:45 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 4.4.298 is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.4.298.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.4.298.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.4.298.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v4.4.298/v4.4.297
^ permalink raw reply
* [PATCH net] ppp: ensure minimum packet size in ppp_write()
From: Eric Dumazet @ 2022-01-05 11:48 UTC (permalink / raw)
To: David S . Miller, Jakub Kicinski
Cc: netdev, Eric Dumazet, Eric Dumazet, Paul Mackerras, linux-ppp,
syzbot
From: Eric Dumazet <edumazet@google.com>
It seems pretty clear ppp layer assumed user space
would always be kind to provide enough data
in their write() to a ppp device.
This patch makes sure user provides at least
2 bytes.
It adds PPP_PROTO_LEN macro that could replace
in net-next many occurrences of hard-coded 2 value.
I replaced only one occurrence to ease backports
to stable kernels.
The bug manifests in the following report:
BUG: KMSAN: uninit-value in ppp_send_frame+0x28d/0x27c0 drivers/net/ppp/ppp_generic.c:1740
ppp_send_frame+0x28d/0x27c0 drivers/net/ppp/ppp_generic.c:1740
__ppp_xmit_process+0x23e/0x4b0 drivers/net/ppp/ppp_generic.c:1640
ppp_xmit_process+0x1fe/0x480 drivers/net/ppp/ppp_generic.c:1661
ppp_write+0x5cb/0x5e0 drivers/net/ppp/ppp_generic.c:513
do_iter_write+0xb0c/0x1500 fs/read_write.c:853
vfs_writev fs/read_write.c:924 [inline]
do_writev+0x645/0xe00 fs/read_write.c:967
__do_sys_writev fs/read_write.c:1040 [inline]
__se_sys_writev fs/read_write.c:1037 [inline]
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Uninit was created at:
slab_post_alloc_hook mm/slab.h:524 [inline]
slab_alloc_node mm/slub.c:3251 [inline]
__kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974
kmalloc_reserve net/core/skbuff.c:354 [inline]
__alloc_skb+0x545/0xf90 net/core/skbuff.c:426
alloc_skb include/linux/skbuff.h:1126 [inline]
ppp_write+0x11d/0x5e0 drivers/net/ppp/ppp_generic.c:501
do_iter_write+0xb0c/0x1500 fs/read_write.c:853
vfs_writev fs/read_write.c:924 [inline]
do_writev+0x645/0xe00 fs/read_write.c:967
__do_sys_writev fs/read_write.c:1040 [inline]
__se_sys_writev fs/read_write.c:1037 [inline]
__x64_sys_writev+0xe5/0x120 fs/read_write.c:1037
do_syscall_x64 arch/x86/entry/common.c:51 [inline]
do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82
entry_SYSCALL_64_after_hwframe+0x44/0xae
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: linux-ppp@vger.kernel.org
Reported-by: syzbot <syzkaller@googlegroups.com>
---
drivers/net/ppp/ppp_generic.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
index 1180a0e2445fbfb3204fea785f1c1cf48bc77141..3ab24988198feaa147397f9ce231815ed1dfa293 100644
--- a/drivers/net/ppp/ppp_generic.c
+++ b/drivers/net/ppp/ppp_generic.c
@@ -69,6 +69,8 @@
#define MPHDRLEN 6 /* multilink protocol header length */
#define MPHDRLEN_SSN 4 /* ditto with short sequence numbers */
+#define PPP_PROTO_LEN 2
+
/*
* An instance of /dev/ppp can be associated with either a ppp
* interface unit or a ppp channel. In both cases, file->private_data
@@ -497,6 +499,9 @@ static ssize_t ppp_write(struct file *file, const char __user *buf,
if (!pf)
return -ENXIO;
+ /* All PPP packets should start with the 2-byte protocol */
+ if (count < PPP_PROTO_LEN)
+ return -EINVAL;
ret = -ENOMEM;
skb = alloc_skb(count + pf->hdrlen, GFP_KERNEL);
if (!skb)
@@ -1764,7 +1769,7 @@ ppp_send_frame(struct ppp *ppp, struct sk_buff *skb)
}
++ppp->stats64.tx_packets;
- ppp->stats64.tx_bytes += skb->len - 2;
+ ppp->stats64.tx_bytes += skb->len - PPP_PROTO_LEN;
switch (proto) {
case PPP_IP:
--
2.34.1.448.ga2b2bfdf31-goog
^ permalink raw reply related
* Linux kernel 4.19.224 released
From: Linux Kernel Distribution System @ 2022-01-05 11:50 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 4.19.224 is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.224.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.19.224.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.224.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v4.19.224/v4.19.223
^ permalink raw reply
* Linux kernel 4.14.261 released
From: Linux Kernel Distribution System @ 2022-01-05 11:50 UTC (permalink / raw)
To: linux-kernel-announce
Linux kernel version 4.14.261 is now available:
Full source: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.261.tar.xz
Patch: https://cdn.kernel.org/pub/linux/kernel/v4.x/patch-4.14.261.xz
PGP Signature: https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.14.261.tar.sign
You can view the summary of the changes at the following URL:
https://git.kernel.org/stable/ds/v4.14.261/v4.14.260
^ permalink raw reply
* Re: [PATCH V5 00/22] arch: Add basic LoongArch support
From: Xi Ruoyao @ 2022-01-05 11:51 UTC (permalink / raw)
To: Huacai Chen
Cc: Huacai Chen, Arnd Bergmann, Andy Lutomirski, Thomas Gleixner,
Peter Zijlstra, Andrew Morton, David Airlie, Jonathan Corbet,
Linus Torvalds, linux-arch, open list:DOCUMENTATION, LKML,
Xuefeng Li, Yanteng Si, Jiaxun Yang
In-Reply-To: <CAAhV-H6R=xWL18AH7HzeXHOVD_d-5m7RvdQCLkOR1NeDZ_0HMw@mail.gmail.com>
On Wed, 2022-01-05 at 17:40 +0800, Huacai Chen wrote:
> Hi, Ruoyao,
>
> The problem still exists in 5.16-rc8, can you try to change
> cpu_relax() definition to smp_mb()? It seems can fix the problem.
Is there any workload which can triggers the panic? I can't trigger it
by building and testing GCC, or building the kernel anymore.
And is your "stable" issue the same one I'd encountered? To me changing
barrier() to smp_mb() may fix some deadlock, but not a panic. (I'm not
an expert on CPU architecture or kernel programming, so maybe I'm wrong
here.)
I'll put my 3A5000 machine into a loop building kernel and see if I can
trigger the panic again...
--
Xi Ruoyao <xry111@mengyan1223.wang>
School of Aerospace Science and Technology, Xidian University
^ permalink raw reply
* Re: [PATCH net-next 07/15] net: dsa: remove cross-chip support for MRP
From: Vladimir Oltean @ 2022-01-05 11:51 UTC (permalink / raw)
To: Horatiu Vultur
Cc: netdev@vger.kernel.org, David S. Miller, Jakub Kicinski,
Andrew Lunn, Vivien Didelot, Florian Fainelli
In-Reply-To: <20220105100152.cnu3zcjmqp6vizer@soft-dev3-1.localhost>
On Wed, Jan 05, 2022 at 11:01:52AM +0100, Horatiu Vultur wrote:
> The 01/04/2022 19:14, Vladimir Oltean wrote:
> >
> > The cross-chip notifiers for MRP are bypass operations, meaning that
> > even though all switches in a tree are notified, only the switch
> > specified in the info structure is targeted.
> >
> > We can eliminate the unnecessary complexity by deleting the cross-chip
> > notifier logic and calling the ds->ops straight from port.c.
>
> It looks like structs dsa_notifier_mrp_info and
> dsa_notifier_mrp_ring_role_info are not used anywhere anymore. So they
> should also be deleted.
Well spotted, thanks.
> >
> > Cc: Horatiu Vultur <horatiu.vultur@microchip.com>
> > Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
> > ---
> > net/dsa/dsa_priv.h | 4 ---
> > net/dsa/port.c | 44 +++++++++++++++----------------
> > net/dsa/switch.c | 64 ----------------------------------------------
> > 3 files changed, 20 insertions(+), 92 deletions(-)
> >
> > diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
> > index b5ae21f172a8..54c23479b9ba 100644
> > --- a/net/dsa/dsa_priv.h
> > +++ b/net/dsa/dsa_priv.h
> > @@ -40,10 +40,6 @@ enum {
> > DSA_NOTIFIER_TAG_PROTO,
> > DSA_NOTIFIER_TAG_PROTO_CONNECT,
> > DSA_NOTIFIER_TAG_PROTO_DISCONNECT,
> > - DSA_NOTIFIER_MRP_ADD,
> > - DSA_NOTIFIER_MRP_DEL,
> > - DSA_NOTIFIER_MRP_ADD_RING_ROLE,
> > - DSA_NOTIFIER_MRP_DEL_RING_ROLE,
> > DSA_NOTIFIER_TAG_8021Q_VLAN_ADD,
> > DSA_NOTIFIER_TAG_8021Q_VLAN_DEL,
> > };
> > diff --git a/net/dsa/port.c b/net/dsa/port.c
> > index 05677e016982..5c72f890c6a2 100644
> > --- a/net/dsa/port.c
> > +++ b/net/dsa/port.c
> > @@ -907,49 +907,45 @@ int dsa_port_vlan_del(struct dsa_port *dp,
> > int dsa_port_mrp_add(const struct dsa_port *dp,
> > const struct switchdev_obj_mrp *mrp)
> > {
> > - struct dsa_notifier_mrp_info info = {
> > - .sw_index = dp->ds->index,
> > - .port = dp->index,
> > - .mrp = mrp,
> > - };
> > + struct dsa_switch *ds = dp->ds;
> > +
> > + if (!ds->ops->port_mrp_add)
> > + return -EOPNOTSUPP;
> >
> > - return dsa_port_notify(dp, DSA_NOTIFIER_MRP_ADD, &info);
> > + return ds->ops->port_mrp_add(ds, dp->index, mrp);
> > }
> >
> > int dsa_port_mrp_del(const struct dsa_port *dp,
> > const struct switchdev_obj_mrp *mrp)
> > {
> > - struct dsa_notifier_mrp_info info = {
> > - .sw_index = dp->ds->index,
> > - .port = dp->index,
> > - .mrp = mrp,
> > - };
> > + struct dsa_switch *ds = dp->ds;
> > +
> > + if (!ds->ops->port_mrp_del)
> > + return -EOPNOTSUPP;
> >
> > - return dsa_port_notify(dp, DSA_NOTIFIER_MRP_DEL, &info);
> > + return ds->ops->port_mrp_del(ds, dp->index, mrp);
> > }
> >
> > int dsa_port_mrp_add_ring_role(const struct dsa_port *dp,
> > const struct switchdev_obj_ring_role_mrp *mrp)
> > {
> > - struct dsa_notifier_mrp_ring_role_info info = {
> > - .sw_index = dp->ds->index,
> > - .port = dp->index,
> > - .mrp = mrp,
> > - };
> > + struct dsa_switch *ds = dp->ds;
> > +
> > + if (!ds->ops->port_mrp_add)
> > + return -EOPNOTSUPP;
> >
> > - return dsa_port_notify(dp, DSA_NOTIFIER_MRP_ADD_RING_ROLE, &info);
> > + return ds->ops->port_mrp_add_ring_role(ds, dp->index, mrp);
> > }
> >
> > int dsa_port_mrp_del_ring_role(const struct dsa_port *dp,
> > const struct switchdev_obj_ring_role_mrp *mrp)
> > {
> > - struct dsa_notifier_mrp_ring_role_info info = {
> > - .sw_index = dp->ds->index,
> > - .port = dp->index,
> > - .mrp = mrp,
> > - };
> > + struct dsa_switch *ds = dp->ds;
> > +
> > + if (!ds->ops->port_mrp_del)
> > + return -EOPNOTSUPP;
> >
> > - return dsa_port_notify(dp, DSA_NOTIFIER_MRP_DEL_RING_ROLE, &info);
> > + return ds->ops->port_mrp_del_ring_role(ds, dp->index, mrp);
> > }
> >
> > void dsa_port_set_tag_protocol(struct dsa_port *cpu_dp,
> > diff --git a/net/dsa/switch.c b/net/dsa/switch.c
> > index 393f2d8a860a..a164ec02b4e9 100644
> > --- a/net/dsa/switch.c
> > +++ b/net/dsa/switch.c
> > @@ -701,58 +701,6 @@ dsa_switch_disconnect_tag_proto(struct dsa_switch *ds,
> > return 0;
> > }
> >
> > -static int dsa_switch_mrp_add(struct dsa_switch *ds,
> > - struct dsa_notifier_mrp_info *info)
> > -{
> > - if (!ds->ops->port_mrp_add)
> > - return -EOPNOTSUPP;
> > -
> > - if (ds->index == info->sw_index)
> > - return ds->ops->port_mrp_add(ds, info->port, info->mrp);
> > -
> > - return 0;
> > -}
> > -
> > -static int dsa_switch_mrp_del(struct dsa_switch *ds,
> > - struct dsa_notifier_mrp_info *info)
> > -{
> > - if (!ds->ops->port_mrp_del)
> > - return -EOPNOTSUPP;
> > -
> > - if (ds->index == info->sw_index)
> > - return ds->ops->port_mrp_del(ds, info->port, info->mrp);
> > -
> > - return 0;
> > -}
> > -
> > -static int
> > -dsa_switch_mrp_add_ring_role(struct dsa_switch *ds,
> > - struct dsa_notifier_mrp_ring_role_info *info)
> > -{
> > - if (!ds->ops->port_mrp_add)
> > - return -EOPNOTSUPP;
> > -
> > - if (ds->index == info->sw_index)
> > - return ds->ops->port_mrp_add_ring_role(ds, info->port,
> > - info->mrp);
> > -
> > - return 0;
> > -}
> > -
> > -static int
> > -dsa_switch_mrp_del_ring_role(struct dsa_switch *ds,
> > - struct dsa_notifier_mrp_ring_role_info *info)
> > -{
> > - if (!ds->ops->port_mrp_del)
> > - return -EOPNOTSUPP;
Upon further self-review I found a bug here and in dsa_switch_mrp_add_ring_role,
that the incorrect function pointer is checked. If a driver implements
ds->ops->port_mrp_del but not ds->ops->port_mrp_del_ring_role, this will
cause a NULL pointer dereference. I'll submit a separate patch to
net-next for this (it's a bug but an inconsequential one, since there
isn't any DSA driver in that situation).
> > -
> > - if (ds->index == info->sw_index)
> > - return ds->ops->port_mrp_del_ring_role(ds, info->port,
> > - info->mrp);
> > -
> > - return 0;
> > -}
> > -
> > static int dsa_switch_event(struct notifier_block *nb,
> > unsigned long event, void *info)
> > {
> > @@ -826,18 +774,6 @@ static int dsa_switch_event(struct notifier_block *nb,
> > case DSA_NOTIFIER_TAG_PROTO_DISCONNECT:
> > err = dsa_switch_disconnect_tag_proto(ds, info);
> > break;
> > - case DSA_NOTIFIER_MRP_ADD:
> > - err = dsa_switch_mrp_add(ds, info);
> > - break;
> > - case DSA_NOTIFIER_MRP_DEL:
> > - err = dsa_switch_mrp_del(ds, info);
> > - break;
> > - case DSA_NOTIFIER_MRP_ADD_RING_ROLE:
> > - err = dsa_switch_mrp_add_ring_role(ds, info);
> > - break;
> > - case DSA_NOTIFIER_MRP_DEL_RING_ROLE:
> > - err = dsa_switch_mrp_del_ring_role(ds, info);
> > - break;
> > case DSA_NOTIFIER_TAG_8021Q_VLAN_ADD:
> > err = dsa_switch_tag_8021q_vlan_add(ds, info);
> > break;
> > --
> > 2.25.1
> >
>
> --
> /Horatiu
^ permalink raw reply
* Re: [PATCH] debugfs: lockdown: Allow reading debugfs files that are not world readable
From: Greg Kroah-Hartman @ 2022-01-05 11:51 UTC (permalink / raw)
To: Michal Suchanek
Cc: linux-kernel, Rafael J. Wysocki, Matthew Garrett, James Morris,
David Howells, Andy Shevchenko, acpi4asus-user,
platform-driver-x86, Thomas Gleixner
In-Reply-To: <20220104170505.10248-1-msuchanek@suse.de>
On Tue, Jan 04, 2022 at 06:05:05PM +0100, Michal Suchanek wrote:
>
> When the kernel is locked down the kernel allows reading only debugfs
> files with mode 444. Mode 400 is also valid but is not allowed.
>
> Make the 444 into a mask.
>
> Fixes: 5496197f9b08 ("debugfs: Restrict debugfs when the kernel is locked down")
> Signed-off-by: Michal Suchanek <msuchanek@suse.de>
> ---
> fs/debugfs/file.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Why has it taken so long for anyone to notice this (2 years!)?
Is that because no one uses the lockdown mode and tries to read debugfs
files?
>
> diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
> index 7d162b0efbf0..950c63fa4d0b 100644
> --- a/fs/debugfs/file.c
> +++ b/fs/debugfs/file.c
> @@ -147,7 +147,7 @@ static int debugfs_locked_down(struct inode *inode,
> struct file *filp,
> const struct file_operations *real_fops)
> {
> - if ((inode->i_mode & 07777) == 0444 &&
> + if ((inode->i_mode & 07777 & ~0444) == 0 &&
You are now allowing more than just 0400, is that intentional?
I never understood why files that were 0666 were not able to be read
here as well, why not allow that as well? What was magic about 0444
files?
thanks,
greg k-h
^ permalink raw reply
* Linux 4.4.298
From: Greg Kroah-Hartman @ 2022-01-05 11:52 UTC (permalink / raw)
To: linux-kernel, akpm, torvalds, stable; +Cc: lwn, jslaby, Greg Kroah-Hartman
I'm announcing the release of the 4.4.298 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
https://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
thanks,
greg k-h
------------
Makefile | 2 +-
drivers/input/joystick/spaceball.c | 11 +++++++++--
drivers/input/mouse/appletouch.c | 4 ++--
drivers/platform/x86/apple-gmux.c | 2 +-
drivers/scsi/vmw_pvscsi.c | 7 +++++--
drivers/usb/gadget/function/f_fs.c | 9 ++++++---
drivers/usb/host/xhci-pci.c | 5 ++++-
include/uapi/linux/nfc.h | 6 +++---
net/ipv4/af_inet.c | 10 ++++------
scripts/recordmcount.pl | 2 +-
security/selinux/hooks.c | 2 +-
11 files changed, 37 insertions(+), 23 deletions(-)
Alexey Makhalov (1):
scsi: vmw_pvscsi: Set residual data length conditionally
Dmitry V. Levin (1):
uapi: fix linux/nfc.h userspace compilation errors
Greg Kroah-Hartman (1):
Linux 4.4.298
Heiko Carstens (1):
recordmcount.pl: fix typo in s390 mcount regex
Krzysztof Kozlowski (1):
nfc: uapi: use kernel size_t to fix user-space builds
Leo L. Schwab (1):
Input: spaceball - fix parsing of movement data packets
Mathias Nyman (1):
xhci: Fresco FL1100 controller should not have BROKEN_MSI quirk set.
Muchun Song (1):
net: fix use-after-free in tw_timer_handler
Pavel Skripkin (1):
Input: appletouch - initialize work before device registration
Tom Rix (1):
selinux: initialize proto variable in selinux_ip_postroute_compat()
Vincent Pelletier (1):
usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.
Wang Qing (1):
platform/x86: apple-gmux: use resource_size() with res
^ permalink raw reply
* Re: iblinkinfo for Python
From: Leon Romanovsky @ 2022-01-05 11:52 UTC (permalink / raw)
To: Benjamin Drung; +Cc: linux-rdma
In-Reply-To: <44396b05adcf8a414a9f4d6a843fce16670a83c1.camel@ionos.com>
On Wed, Jan 05, 2022 at 11:32:40AM +0100, Benjamin Drung wrote:
> Hi,
>
> we have an in-house Shell script that uses iblinkinfo to check if the
> InfiniBand cabling is correct. This information can be derived from the
> node names that can be seen for the HCA port. I want to improve that
> check and rewrite it in Python, but I failed to find an easy and robust
> way to retrieve the node names for a HCA port:
>
> 1) Call "iblinkinfo --line" and parse the output. Parsing the output
> could probably be done with a complex regular expression. This solution
> is too ugly IMO.
>
> 2) Extend iblinkinfo to provide a JSON output. Then let the Python
> script call "iblinkinfo --json" and simply use json.load for parsing.
> This solution requires some C coding and probably a good json library
> should be used to avoid generating bogus JSON.
>
> 3) Use https://github.com/jgunthorpe/python-rdma but this library has
> not been touched for five years and needs porting to Python 3. So that
> is probably a lot of work as well.
>
> 4) Use pyverbs provided by rdma-core, but I found neither a single API
> call to query similar data to iblinkinfo, nor an example for that use
> case.
>
> What should I do?
Isn't this information available in sysfs?
[leonro@mtl-leonro-l-vm ~]$ cat /sys/class/infiniband/ibp0s9/node_desc
mtl-leonro-l-vm ibp0s9
Can you give an example?
Thanks
>
> --
> Benjamin Drung
>
> Senior DevOps Engineer and Debian & Ubuntu Developer
> Compute Platform Operations Cloud
>
> IONOS SE | Revaler Str. 30 | 10245 Berlin | Deutschland
> E-Mail: benjamin.drung@ionos.com | Web: www.ionos.de
>
> Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498
>
> Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning
> Kettler, Arthur Mai, Britta Schmidt, Achim Weiß
> Aufsichtsratsvorsitzender: Markus Kadelke
>
>
> Member of United Internet
>
^ permalink raw reply
* Re: Linux 4.4.298
From: Greg Kroah-Hartman @ 2022-01-05 11:52 UTC (permalink / raw)
To: linux-kernel, akpm, torvalds, stable; +Cc: lwn, jslaby, Greg Kroah-Hartman
In-Reply-To: <1641383524120143@kroah.com>
diff --git a/Makefile b/Makefile
index 6bc764fb1b97..f35474e260f1 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 297
+SUBLEVEL = 298
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/drivers/input/joystick/spaceball.c b/drivers/input/joystick/spaceball.c
index f4445a4e8d6a..cfa1be4ad868 100644
--- a/drivers/input/joystick/spaceball.c
+++ b/drivers/input/joystick/spaceball.c
@@ -35,6 +35,7 @@
#include <linux/module.h>
#include <linux/input.h>
#include <linux/serio.h>
+#include <asm/unaligned.h>
#define DRIVER_DESC "SpaceTec SpaceBall 2003/3003/4000 FLX driver"
@@ -91,9 +92,15 @@ static void spaceball_process_packet(struct spaceball* spaceball)
case 'D': /* Ball data */
if (spaceball->idx != 15) return;
- for (i = 0; i < 6; i++)
+ /*
+ * Skip first three bytes; read six axes worth of data.
+ * Axis values are signed 16-bit big-endian.
+ */
+ data += 3;
+ for (i = 0; i < ARRAY_SIZE(spaceball_axes); i++) {
input_report_abs(dev, spaceball_axes[i],
- (__s16)((data[2 * i + 3] << 8) | data[2 * i + 2]));
+ (__s16)get_unaligned_be16(&data[i * 2]));
+ }
break;
case 'K': /* Button data */
diff --git a/drivers/input/mouse/appletouch.c b/drivers/input/mouse/appletouch.c
index ef234c9b2f2f..11773838a34d 100644
--- a/drivers/input/mouse/appletouch.c
+++ b/drivers/input/mouse/appletouch.c
@@ -929,6 +929,8 @@ static int atp_probe(struct usb_interface *iface,
set_bit(BTN_TOOL_TRIPLETAP, input_dev->keybit);
set_bit(BTN_LEFT, input_dev->keybit);
+ INIT_WORK(&dev->work, atp_reinit);
+
error = input_register_device(dev->input);
if (error)
goto err_free_buffer;
@@ -936,8 +938,6 @@ static int atp_probe(struct usb_interface *iface,
/* save our data pointer in this interface device */
usb_set_intfdata(iface, dev);
- INIT_WORK(&dev->work, atp_reinit);
-
return 0;
err_free_buffer:
diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c
index 976efeb3f2ba..a0f10ccdca3e 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -461,7 +461,7 @@ static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
}
gmux_data->iostart = res->start;
- gmux_data->iolen = res->end - res->start;
+ gmux_data->iolen = resource_size(res);
if (gmux_data->iolen < GMUX_MIN_IO_LEN) {
pr_err("gmux I/O region too small (%lu < %u)\n",
diff --git a/drivers/scsi/vmw_pvscsi.c b/drivers/scsi/vmw_pvscsi.c
index d25cf084afe7..b0fd017abebd 100644
--- a/drivers/scsi/vmw_pvscsi.c
+++ b/drivers/scsi/vmw_pvscsi.c
@@ -562,9 +562,12 @@ static void pvscsi_complete_request(struct pvscsi_adapter *adapter,
* Commands like INQUIRY may transfer less data than
* requested by the initiator via bufflen. Set residual
* count to make upper layer aware of the actual amount
- * of data returned.
+ * of data returned. There are cases when controller
+ * returns zero dataLen with non zero data - do not set
+ * residual count in that case.
*/
- scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen);
+ if (e->dataLen && (e->dataLen < scsi_bufflen(cmd)))
+ scsi_set_resid(cmd, scsi_bufflen(cmd) - e->dataLen);
cmd->result = (DID_OK << 16);
break;
diff --git a/drivers/usb/gadget/function/f_fs.c b/drivers/usb/gadget/function/f_fs.c
index c045d4176a9c..390e592358e6 100644
--- a/drivers/usb/gadget/function/f_fs.c
+++ b/drivers/usb/gadget/function/f_fs.c
@@ -1476,11 +1476,15 @@ static void ffs_data_clear(struct ffs_data *ffs)
BUG_ON(ffs->gadget);
- if (ffs->epfiles)
+ if (ffs->epfiles) {
ffs_epfiles_destroy(ffs->epfiles, ffs->eps_count);
+ ffs->epfiles = NULL;
+ }
- if (ffs->ffs_eventfd)
+ if (ffs->ffs_eventfd) {
eventfd_ctx_put(ffs->ffs_eventfd);
+ ffs->ffs_eventfd = NULL;
+ }
kfree(ffs->raw_descs_data);
kfree(ffs->raw_strings);
@@ -1493,7 +1497,6 @@ static void ffs_data_reset(struct ffs_data *ffs)
ffs_data_clear(ffs);
- ffs->epfiles = NULL;
ffs->raw_descs_data = NULL;
ffs->raw_descs = NULL;
ffs->raw_strings = NULL;
diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index fd7925f20a6a..2fb202da44b8 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -91,7 +91,6 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
/* Look for vendor-specific quirks */
if (pdev->vendor == PCI_VENDOR_ID_FRESCO_LOGIC &&
(pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK ||
- pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1100 ||
pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1400)) {
if (pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_PDK &&
pdev->revision == 0x0) {
@@ -126,6 +125,10 @@ static void xhci_pci_quirks(struct device *dev, struct xhci_hcd *xhci)
pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1009)
xhci->quirks |= XHCI_BROKEN_STREAMS;
+ if (pdev->vendor == PCI_VENDOR_ID_FRESCO_LOGIC &&
+ pdev->device == PCI_DEVICE_ID_FRESCO_LOGIC_FL1100)
+ xhci->quirks |= XHCI_TRUST_TX_LENGTH;
+
if (pdev->vendor == PCI_VENDOR_ID_NEC)
xhci->quirks |= XHCI_NEC_HOST;
diff --git a/include/uapi/linux/nfc.h b/include/uapi/linux/nfc.h
index 399f39ff8048..1b6d54a328ba 100644
--- a/include/uapi/linux/nfc.h
+++ b/include/uapi/linux/nfc.h
@@ -261,7 +261,7 @@ enum nfc_sdp_attr {
#define NFC_SE_ENABLED 0x1
struct sockaddr_nfc {
- sa_family_t sa_family;
+ __kernel_sa_family_t sa_family;
__u32 dev_idx;
__u32 target_idx;
__u32 nfc_protocol;
@@ -269,14 +269,14 @@ struct sockaddr_nfc {
#define NFC_LLCP_MAX_SERVICE_NAME 63
struct sockaddr_nfc_llcp {
- sa_family_t sa_family;
+ __kernel_sa_family_t sa_family;
__u32 dev_idx;
__u32 target_idx;
__u32 nfc_protocol;
__u8 dsap; /* Destination SAP, if known */
__u8 ssap; /* Source SAP to be bound to */
char service_name[NFC_LLCP_MAX_SERVICE_NAME]; /* Service name URI */;
- size_t service_name_len;
+ __kernel_size_t service_name_len;
};
/* NFC socket protocols */
diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
index b12721ecb0b6..48d2ae83e268 100644
--- a/net/ipv4/af_inet.c
+++ b/net/ipv4/af_inet.c
@@ -1770,6 +1770,10 @@ static int __init inet_init(void)
tcp_v4_init();
+ /* Initialise per-cpu ipv4 mibs */
+ if (init_ipv4_mibs())
+ panic("%s: Cannot init ipv4 mibs\n", __func__);
+
/* Setup TCP slab cache for open requests. */
tcp_init();
@@ -1798,12 +1802,6 @@ static int __init inet_init(void)
if (init_inet_pernet_ops())
pr_crit("%s: Cannot init ipv4 inet pernet ops\n", __func__);
- /*
- * Initialise per-cpu ipv4 mibs
- */
-
- if (init_ipv4_mibs())
- pr_crit("%s: Cannot init ipv4 mibs\n", __func__);
ipv4_proc_init();
diff --git a/scripts/recordmcount.pl b/scripts/recordmcount.pl
index b690b294fc36..e1de4423abce 100755
--- a/scripts/recordmcount.pl
+++ b/scripts/recordmcount.pl
@@ -248,7 +248,7 @@ if ($arch eq "x86_64") {
} elsif ($arch eq "s390" && $bits == 64) {
if ($cc =~ /-DCC_USING_HOTPATCH/) {
- $mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*c0 04 00 00 00 00\\s*(bcrl\\s*0,|jgnop\\s*)[0-9a-f]+ <([^\+]*)>\$";
+ $mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*c0 04 00 00 00 00\\s*(brcl\\s*0,|jgnop\\s*)[0-9a-f]+ <([^\+]*)>\$";
$mcount_adjust = 0;
} else {
$mcount_regex = "^\\s*([0-9a-fA-F]+):\\s*R_390_(PC|PLT)32DBL\\s+_mcount\\+0x2\$";
diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 44f4495e3fbd..55d253c6ab2f 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -4974,7 +4974,7 @@ static unsigned int selinux_ip_postroute_compat(struct sk_buff *skb,
struct common_audit_data ad;
struct lsm_network_audit net = {0,};
char *addrp;
- u8 proto;
+ u8 proto = 0;
if (sk == NULL)
return NF_ACCEPT;
^ 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.