[PATCH] drivers: input: mouse: Change postive to positive in the file alps.c
s/postive/positive/
Signed-off-by: Bhaskar Chowdhury
---
drivers/input/mouse/alps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/mouse/alps.c b/drivers/input/mouse/alps.c
index b067bfd2699c..4a6b33bbe7ea 100644
--- a/drivers/input/mouse/alps.c
+++ b/drivers/input/mouse/alps.c
@@ -986,7 +986,7 @@ static void alps_get_finger_coordinate_v7(struct
input_mt_pos *mt,
case V7_PACKET_ID_TWO:
mt[1].x &= ~0x000F;
mt[1].y |= 0x000F;
- /* Detect false-postive touches where x & y report max value */
+ /* Detect false-positive touches where x & y report max value */
if (mt[1].y == 0x7ff && mt[1].x == 0xff0) {
mt[1].x = 0;
/* y gets set to 0 at the end of this function */
--
2.26.2
Re: Droid 4 charging
* Pavel Machek [210219 21:58]: > > > If I turn off charging with echo 0 > input_current_limit, 0.2 to 0.4A > > > is drawn from USB, and battery is not discharged: > > > > > > root@devuan-droid4:/sys/class/power_supply/usb# echo 0 > > > > input_current_limit > > > root@devuan-droid4:/sys/class/power_supply/usb# cat current_now > > > 0 > > > > Hmm so have you measured that setting the current limit to 0 actually > > draws something from the USB? > > Yes, it does, if I do the echo when charge is done. (I have small USB > passthrough with volt and amp meters). It has been behaving weirdly in > other cases.p OK great, seems like we can just change the charger timeout then. > > I recall clearing the ichrgr bits stops the vbus draw completely, but > > I could be wrong. > > > > > Is that a better way to handle full battery? > > > > We could experiment with switching over to usb power when the battery is > > full. Looking at the docs for mc1378 it might be possible that setting > > CPCAP_REG_CRM_FET_OVRD and clearing CPCAP_REG_CRM_FET_CTRL after the > > battery is full disables charging but still keep drawing power from > > the usb. I'd assume the current limit still needs to be nonzero there > > too? Totally untested.. > > I may be able to test patches... Yeah this too might be worth testing on some donor device.. > > And switching back to battery power on usb disconnect will potentially > > only give us very little time based on the different line length for > > vbus and ground pins compared to data pins on the usb connector.. And > > uvos had some concerns about the battery capacity putting it back online, > > so adding him to Cc also. > > You mean, we'd have to take interrupt and switch registers in order to > switch back to battery power, and system would crash if we did not > make it in time? Yes hopefully we don't need to do that. My guess is we should find some FET_OVRD and FET_CTRL setting we can always keep enabled after charger negotation. Maybe we already have the right settings based on your tests :) Regards, Tony
Re: [PATCH v4 0/4] mm/gup: page unpining improvements
On Thu, Feb 18, 2021 at 03:33:39PM +, Joao Martins wrote:
> in a bvec at once? e.g. something like from this:
>
> bio_for_each_segment_all(bvec, bio, iter_all) {
> if (mark_dirty && !PageCompound(bvec->bv_page))
> set_page_dirty_lock(bvec->bv_page);
> put_page(bvec->bv_page);
> }
>
> (...) to this instead:
>
> bio_for_each_bvec_all(bvec, bio, i)
> unpin_user_page_range_dirty_lock(bvec->bv_page,
> DIV_ROUND_UP(bvec->bv_len, PAGE_SIZE),
> mark_dirty && !PageCompound(bvec->bv_page));
Yes, like that modulo the fix in your reply and any other fixes.
[PATCH] scsi: ipr: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
./drivers/scsi/ipr.c:4209:61-62: WARNING opportunity for kobj_to_dev()
./drivers/scsi/ipr.c:4268:61-62: WARNING opportunity for kobj_to_dev()
./drivers/scsi/ipr.c:4457:61-62: WARNING opportunity for kobj_to_dev()
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/ipr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/ipr.c b/drivers/scsi/ipr.c
index e451102..4d8a975 100644
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@ -4206,7 +4206,7 @@ static ssize_t ipr_next_async_err_log(struct file *filep,
struct kobject *kobj,
struct bin_attribute *bin_attr, char *buf,
loff_t off, size_t count)
{
- struct device *cdev = container_of(kobj, struct device, kobj);
+ struct device *cdev = kobj_to_dev(kobj);
struct Scsi_Host *shost = class_to_shost(cdev);
struct ipr_ioa_cfg *ioa_cfg = (struct ipr_ioa_cfg *)shost->hostdata;
struct ipr_hostrcb *hostrcb;
@@ -4265,7 +4265,7 @@ static ssize_t ipr_read_dump(struct file *filp, struct
kobject *kobj,
struct bin_attribute *bin_attr,
char *buf, loff_t off, size_t count)
{
- struct device *cdev = container_of(kobj, struct device, kobj);
+ struct device *cdev = kobj_to_dev(kobj);
struct Scsi_Host *shost = class_to_shost(cdev);
struct ipr_ioa_cfg *ioa_cfg = (struct ipr_ioa_cfg *)shost->hostdata;
struct ipr_dump *dump;
@@ -4454,7 +4454,7 @@ static ssize_t ipr_write_dump(struct file *filp, struct
kobject *kobj,
struct bin_attribute *bin_attr,
char *buf, loff_t off, size_t count)
{
- struct device *cdev = container_of(kobj, struct device, kobj);
+ struct device *cdev = kobj_to_dev(kobj);
struct Scsi_Host *shost = class_to_shost(cdev);
struct ipr_ioa_cfg *ioa_cfg = (struct ipr_ioa_cfg *)shost->hostdata;
int rc;
--
1.8.3.1
[PATCH v7 2/2] docs: add documentation for checkpatch
Add documentation for kernel script checkpatch.pl. This documentation is also parsed by checkpatch to enable a verbose mode. The checkpatch message types are grouped by usage. Under each group the types are described briefly. 34 of such types are documented. Signed-off-by: Dwaipayan Ray --- Documentation/dev-tools/checkpatch.rst | 525 + Documentation/dev-tools/index.rst | 1 + 2 files changed, 526 insertions(+) create mode 100644 Documentation/dev-tools/checkpatch.rst diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst new file mode 100644 index ..ffb8f66be887 --- /dev/null +++ b/Documentation/dev-tools/checkpatch.rst @@ -0,0 +1,525 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +== +Checkpatch +== + +This document describes the kernel script checkpatch.pl. + +.. Table of Contents + + === Introduction + === Options + === Message Levels + === Type Descriptions + +Introduction + + +Checkpatch (scripts/checkpatch.pl) is a perl script which checks for trivial +style violations in patches and optionally corrects them. Checkpatch can +also be run on file contexts and without the kernel tree. + +Checkpatch is not always right. Your judgement takes precedence over checkpatch +messages. If your code looks better with the violations, then its probably +best left alone. + + +Options +=== + +This section will describe the options checkpatch can be run with. + +Usage:: + + ./scripts/checkpatch.pl [OPTION]... [FILE]... + +Available options: + + - -q, --quiet + + Enable quiet mode. + + - -v, --verbose + Enable verbose mode. Additional verbose test descriptions are output + so as to provide information on why that particular message is shown. + + - --no-tree + + Run checkpatch without the kernel tree. + + - --no-signoff + + Disable the 'Signed-off-by' line check. The sign-off is a simple line at + the end of the explanation for the patch, which certifies that you wrote it + or otherwise have the right to pass it on as an open-source patch. + + Example:: + +Signed-off-by: Random J Developer + + Setting this flag effectively stops a message for a missing signed-off-by + line in a patch context. + + - --patch + + Treat FILE as a patch. This is the default option and need not be + explicitly specified. + + - --emacs + + Set output to emacs compile window format. This allows emacs users to jump + from the error in the compile window directly to the offending line in the + patch. + + - --terse + + Output only one line per report. + + - --showfile + + Show the diffed file position instead of the input file position. + + - -g, --git + + Treat FILE as a single commit or a git revision range. + + Single commit with: + + - + - ^ + - ~n + + Multiple commits with: + + - .. + - ... + - - + + - -f, --file + + Treat FILE as a regular source file. This option must be used when running + checkpatch on source files in the kernel. + + - --subjective, --strict + + Enable stricter tests in checkpatch. By default the tests emitted as CHECK + do not activate by default. Use this flag to activate the CHECK tests. + + - --list-types + + Every message emitted by checkpatch has an associated TYPE. Add this flag + to display all the types in checkpatch. + + Note that when this flag is active, checkpatch does not read the input FILE, + and no message is emitted. Only a list of types in checkpatch is output. + + - --types TYPE(,TYPE2...) + + Only display messages with the given types. + + Example:: + + ./scripts/checkpatch.pl mypatch.patch --types EMAIL_SUBJECT,BRACES + + - --ignore TYPE(,TYPE2...) + + Checkpatch will not emit messages for the specified types. + + Example:: + + ./scripts/checkpatch.pl mypatch.patch --ignore EMAIL_SUBJECT,BRACES + + - --show-types + + By default checkpatch doesn't display the type associated with the messages. + Set this flag to show the message type in the output. + + - --max-line-length=n + + Set the max line length (default 100). If a line exceeds the specified + length, a LONG_LINE message is emitted. + + + The message level is different for patch and file contexts. For patches, + a WARNING is emitted. While a milder CHECK is emitted for files. So for + file contexts, the --strict flag must also be enabled. + + - --min-conf-desc-length=n + + Set the Kconfig entry minimum description length, if shorter, warn. + + - --tab-size=n + + Set the number of spaces for tab (default 8). + + - --root=PATH + + PATH to the kernel tree root. + + This option must be specified when invoking checkpatch from outside + the kernel root. + + - --no-summary + + Suppress the per file summary. + + - --mailback + + Only produce a report in case of Warnings or Errors. Milder Checks are + excluded from this. + + - --summary-file + + Include the
[PATCH v7 1/2] checkpatch: add verbose mode
Add a new verbose mode to checkpatch.pl to emit additional verbose
test descriptions. The verbose mode is optional and can be enabled
by the flag -v or --verbose.
The test descriptions are parsed from the checkpatch documentation
file at `Documentation/dev-tools/checkpatch.rst`. The test
descriptions in the docs are kept in a fixed format grouped by
usage. Some examples of this format are:
**LINE_SPACING**
Vertical space is wasted given the limited number of lines an
editor window can display when multiple blank lines are used.
**MISSING_SIGN_OFF**
The patch is missing a Signed-off-by line. A signed-off-by
line should be added according to Developer's certificate of
Origin.
To avoid lengthy output, the verbose description is printed only
for the first instance of a particular message type.
The --verbose option cannot be used along with the --terse option.
Verbose mode can be used with the --list-types option.
The --list-types output also supports color coding now.
Signed-off-by: Dwaipayan Ray
---
scripts/checkpatch.pl | 133 +++---
1 file changed, 113 insertions(+), 20 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 9a549b009d2f..7bc3f02fc543 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -23,6 +23,9 @@ my $V = '0.32';
use Getopt::Long qw(:config no_auto_abbrev);
my $quiet = 0;
+my $verbose = 0;
+my %verbose_messages = ();
+my %verbose_emitted = ();
my $tree = 1;
my $chk_signoff = 1;
my $chk_patch = 1;
@@ -61,6 +64,7 @@ my $spelling_file = "$D/spelling.txt";
my $codespell = 0;
my $codespellfile = "/usr/share/codespell/dictionary.txt";
my $conststructsfile = "$D/const_structs.checkpatch";
+my $docsfile = "$D/../Documentation/dev-tools/checkpatch.rst";
my $typedefsfile;
my $color = "auto";
my $allow_c99_comments = 1; # Can be overridden by --ignore
C99_COMMENT_TOLERANCE
@@ -78,6 +82,7 @@ Version: $V
Options:
-q, --quietquiet
+ -v, --verbose verbose mode
--no-tree run without a kernel tree
--no-signoff do not check for 'Signed-off-by' line
--patchtreat FILE as patchfile (default)
@@ -158,15 +163,51 @@ sub list_types {
my $text = <$script>;
close($script);
- my @types = ();
+ my %types = ();
# Also catch when type or level is passed through a variable
- for ($text =~
/(?:(?:\bCHK|\bWARN|\bERROR|&\{\$msg_level})\s*\(|\$msg_type\s*=)\s*"([^"]+)"/g)
{
- push (@types, $_);
+ while ($text =~
/(?:(\bCHK|\bWARN|\bERROR|&\{\$msg_level})\s*\(|\$msg_type\s*=)\s*"([^"]+)"/g) {
+ if (defined($1)) {
+ if (exists($types{$2})) {
+ $types{$2} .= ",$1" if ($types{$2} ne $1);
+ } else {
+ $types{$2} = $1;
+ }
+ } else {
+ $types{$2} = "UNDETERMINED";
+ }
}
- @types = sort(uniq(@types));
+
print("#\tMessage type\n\n");
- foreach my $type (@types) {
+ if ($color) {
+ print(" ( Color coding: ");
+ print(RED . "ERROR" . RESET);
+ print(" | ");
+ print(YELLOW . "WARNING" . RESET);
+ print(" | ");
+ print(GREEN . "CHECK" . RESET);
+ print(" | ");
+ print("Multiple levels / Undetermined");
+ print(" )\n\n");
+ }
+
+ foreach my $type (sort keys %types) {
+ my $orig_type = $type;
+ if ($color) {
+ my $level = $types{$type};
+ if ($level eq "ERROR") {
+ $type = RED . $type . RESET;
+ } elsif ($level eq "WARN") {
+ $type = YELLOW . $type . RESET;
+ } elsif ($level eq "CHK") {
+ $type = GREEN . $type . RESET;
+ }
+ }
print(++$count . "\t" . $type . "\n");
+ if ($verbose && exists($verbose_messages{$orig_type})) {
+ my $message = $verbose_messages{$orig_type};
+ $message =~ s/\n/\n\t/g;
+ print("\t" . $message . "\n\n");
+ }
}
exit($exitcode);
@@ -198,6 +239,46 @@ if (-f $conf) {
unshift(@ARGV, @conf_args) if @conf_args;
}
+sub load_docs {
+ open(my $docs, '<', "$docsfile")
+ or warn "$P: Can't read the documentation file $docsfile $!\n";
+
+ my $type = '';
+ my $desc = '';
+ my $in_desc = 0;
+
+ while (<$docs>) {
+ chomp;
+ my $line = $_;
+ $line =~ s/\s+$//;
+
+ if ($line =~ /^\s*\*\*(.+)\*\*$/) {
+ if
[PATCH v7 0/2] checkpatch: add verbose mode
Add a new verbose mode to checkpatch. The verbose test descriptions are read from the checkpatch documentation file at `Documentation/dev-tools/checkpatch.rst`. The verbose mode is optional and can be enabled by the flag -v or --verbose. The documentation file is only parsed by checkpatch.pl if the verbose mode is enabled. The verbose mode can not be used together with the --terse option. Changes in v7: - Add color coding support to --list-types option Changes in v6: - Allow using verbose mode with --list-types option Changes in v5: - Change the reference format to use absolute links. - Print verbose descriptions only for the first time a message type is encountered. Changes in v4: - Change the type description format - Group the message types by usage - Make handling of --terse with --verbose simpler Changes in v3: - Simplify documentation file parsing in checkpatch - Document a total of 33 message types for checkpatch Changes in v2: - Use .rst Field Lists to specify the type descriptions. - Add a few more type descriptions to documentation. Dwaipayan Ray (2): checkpatch: add verbose mode docs: add documentation for checkpatch Documentation/dev-tools/checkpatch.rst | 525 + Documentation/dev-tools/index.rst | 1 + scripts/checkpatch.pl | 133 ++- 3 files changed, 639 insertions(+), 20 deletions(-) create mode 100644 Documentation/dev-tools/checkpatch.rst -- 2.30.0
Re: [PATCH 1/7] fsdax: Output address in dax_iomap_pfn() and rename it
hi,
Add address output in dax_iomap_pfn() in order to perform a memcpy() in
CoW case. Since this function both output address and pfn, rename it to
dax_iomap_direct_access().
Signed-off-by: Shiyang Ruan
---
fs/dax.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/fs/dax.c b/fs/dax.c
index 5b47834f2e1b..b012b2db7ba2 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -998,8 +998,8 @@ static sector_t dax_iomap_sector(struct iomap *iomap,
loff_t pos)
return (iomap->addr + (pos & PAGE_MASK) - iomap->offset) >> 9;
}
-static int dax_iomap_pfn(struct iomap *iomap, loff_t pos, size_t size,
-pfn_t *pfnp)
+static int dax_iomap_direct_access(struct iomap *iomap, loff_t pos, size_t
size,
+ void **kaddr, pfn_t *pfnp)
{
const sector_t sector = dax_iomap_sector(iomap, pos);
pgoff_t pgoff;
@@ -1011,11 +1011,13 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t
pos, size_t size,
return rc;
id = dax_read_lock();
length = dax_direct_access(iomap->dax_dev, pgoff, PHYS_PFN(size),
- NULL, pfnp);
+ kaddr, pfnp);
if (length < 0) {
rc = length;
goto out;
}
+ if (!pfnp)
Should this be "if (!*pfnp)"?
Regards,
Xiaoguang Wang
+ goto out_check_addr;
rc = -EINVAL;
if (PFN_PHYS(length) < size)
goto out;
@@ -1025,6 +1027,12 @@ static int dax_iomap_pfn(struct iomap *iomap, loff_t
pos, size_t size,
if (length > 1 && !pfn_t_devmap(*pfnp))
goto out;
rc = 0;
+
+out_check_addr:
+ if (!kaddr)
+ goto out;
+ if (!*kaddr)
+ rc = -EFAULT;
out:
dax_read_unlock(id);
return rc;
@@ -1348,7 +1356,8 @@ static vm_fault_t dax_iomap_pte_fault(struct vm_fault
*vmf, pfn_t *pfnp,
count_memcg_event_mm(vma->vm_mm, PGMAJFAULT);
major = VM_FAULT_MAJOR;
}
- error = dax_iomap_pfn(, pos, PAGE_SIZE, );
+ error = dax_iomap_direct_access(, pos, PAGE_SIZE,
+ NULL, );
if (error < 0)
goto error_finish_iomap;
@@ -1566,7 +1575,8 @@ static vm_fault_t dax_iomap_pmd_fault(struct vm_fault *vmf, pfn_t *pfnp,
switch (iomap.type) {
case IOMAP_MAPPED:
- error = dax_iomap_pfn(, pos, PMD_SIZE, );
+ error = dax_iomap_direct_access(, pos, PMD_SIZE,
+ NULL, );
if (error < 0)
goto finish_iomap;
Re: [PATCH 2/2] arm64: dts: fsl: add support for Kontron pitx-imx8m board
Hi Krysztof,
Am So., 21. Feb. 2021 um 13:11 Uhr schrieb Krzysztof Kozlowski
:
>
> On Thu, Feb 18, 2021 at 01:33:29PM +0100, Heiko Thiery wrote:
> > The Kontron pitx-imx8m board is based on an i.MX8MQ soc.
> >
> > Signed-off-by: Heiko Thiery
> > ---
> > arch/arm64/boot/dts/freescale/Makefile| 1 +
> > .../freescale/imx8mq-kontron-pitx-imx8m.dts | 675 ++
> > 2 files changed, 676 insertions(+)
> > create mode 100644
> > arch/arm64/boot/dts/freescale/imx8mq-kontron-pitx-imx8m.dts
> >
> > diff --git a/arch/arm64/boot/dts/freescale/Makefile
> > b/arch/arm64/boot/dts/freescale/Makefile
> > index 6438db3822f8..9fc2c6f64407 100644
> > --- a/arch/arm64/boot/dts/freescale/Makefile
> > +++ b/arch/arm64/boot/dts/freescale/Makefile
> > @@ -47,6 +47,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-evk.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mp-phyboard-pollux-rdk.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mq-hummingboard-pulse.dtb
> > +dtb-$(CONFIG_ARCH_MXC) += imx8mq-kontron-pitx-imx8m.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-devkit.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r2.dtb
> > dtb-$(CONFIG_ARCH_MXC) += imx8mq-librem5-r3.dtb
> > diff --git a/arch/arm64/boot/dts/freescale/imx8mq-kontron-pitx-imx8m.dts
> > b/arch/arm64/boot/dts/freescale/imx8mq-kontron-pitx-imx8m.dts
> > new file mode 100644
> > index ..79805928204e
> > --- /dev/null
> > +++ b/arch/arm64/boot/dts/freescale/imx8mq-kontron-pitx-imx8m.dts
> > @@ -0,0 +1,675 @@
> > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> > +/*
> > + * Device Tree File for the Kontron pitx-imx8m board.
> > + *
> > + * Copyright (C) 2021 Heiko Thiery
> > + */
> > +
> > +/dts-v1/;
> > +
> > +#include "imx8mq.dtsi"
> > +#include
> > +
> > +/ {
> > + model = "Kontron pITX-imx8m";
> > + compatible = "kontron,pitx-imx8m", "fsl,imx8mq";
> > +
> > + aliases {
> > + i2c0 =
> > + i2c1 =
> > + i2c2 =
> > + mmc0 =
> > + mmc1 =
> > + serial0 =
> > + serial1 =
> > + serial2 =
> > + spi0 =
> > + spi1 =
> > + };
> > +
> > + chosen {
> > + stdout-path = "serial2:115200n8";
> > + };
> > +
> > + regulators {
> > + compatible = "simple-bus";
> > + #address-cells = <1>;
> > + #size-cells = <0>;
> > +
> > + reg_usdhc2_vmmc: regulator-v-3v3-sd {
>
> That's a messed unit addressing. You have here simple-bus but no unit
> addresses. Move it out of regulators node and run make dtc W=1 (it would
> point you this issue).
Ok, I will change that.
But I'm not able to run dtc on my dts. dtc throws an error.
# dtc -I dts -O dtb imx8mq-kontron-pitx-imx8m.dts
Error: imx8mq-kontron-pitx-imx8m.dts:10.1-9 syntax error
FATAL ERROR: Unable to parse input tree
It is about the includes. How can I run dtc for a intree dts to add
the -W option?
> > + compatible = "regulator-fixed";
> > + regulator-name = "V_3V3_SD";
> > + regulator-min-microvolt = <330>;
> > + regulator-max-microvolt = <330>;
> > + gpio = < 19 GPIO_ACTIVE_HIGH>;
> > + off-on-delay-us = <2>;
> > + enable-active-high;
> > + };
> > + };
> > +
> > + usb_hub_reset: usb-hub-reset {
> > + compatible = "gpio-reset";
> > + reset-gpios = < 4 GPIO_ACTIVE_LOW>;
> > + reset-delay-us = <3000>;
> > + reset-post-delay-ms = <50>;
> > + #reset-cells = <0>;
> > + };
> > +
> > + tpm_reset: tpm-reset {
> > + compatible = "gpio-reset";
> > + reset-gpios = < 2 GPIO_ACTIVE_LOW>;
> > + reset-delay-us = <2>;
> > + reset-post-delay-ms = <60>;
> > + #reset-cells = <0>;
> > + };
> > +
> > + pcie0_refclk: pcie0-refclk {
>
> Generic node names (from the dt spec candidate is "clock").
Should I simply set the node name to pcie0-clock? And pcie1-clock for
the next one?
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <1>;
> > + };
> > +
> > + pcie1_refclk: pcie1-refclk {
>
> Same.
>
> > + compatible = "fixed-clock";
> > + #clock-cells = <0>;
> > + clock-frequency = <1>;
> > + };
> > +
> > + gpio-keys {
> > + compatible = "gpio-keys";
> > + pinctrl-names = "default";
> > + pinctrl-0 = <_gpio_keys>;
> > +
> > + pciewake {
> > + label = "PCIE_Wake";
> > + gpios = < 8 GPIO_ACTIVE_LOW>;
> > + linux,input-type = <4>; /* EV_MSC */
> > + linux,code = <3>; /* MSC_RAW */
> > + gpio-key,wakeup;
>
Re: [PATCH v17 08/10] PM: hibernate: disable when there are active secretmem users
On Mon, Feb 08, 2021 at 10:49:18AM +0200, Mike Rapoport wrote: > It is unsafe to allow saving of secretmem areas to the hibernation > snapshot as they would be visible after the resume and this essentially > will defeat the purpose of secret memory mappings. Sorry for being a bit late to this - from the point of view of running processes (and even the kernel once resume is complete), hibernation is effectively equivalent to suspend to RAM. Why do they need to be handled differently here?
Re: [PATCH] mm/kasan: switch from strlcpy to strscpy
On Mon, Feb 22, 2021 at 6:10 AM Zhiyuan Dai wrote: > > strlcpy is marked as deprecated in Documentation/process/deprecated.rst, > and there is no functional difference when the caller expects truncation > (when not checking the return value). strscpy is relatively better as it > also avoids scanning the whole source string. Looks like a good thing to do. > Signed-off-by: Zhiyuan Dai Acked-by: Alexander Potapenko > --- > mm/kasan/report_generic.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c > index 8a9c889..fc7f7ad 100644 > --- a/mm/kasan/report_generic.c > +++ b/mm/kasan/report_generic.c > @@ -148,7 +148,7 @@ static bool __must_check tokenize_frame_descr(const char > **frame_descr, > } > > /* Copy token (+ 1 byte for '\0'). */ > - strlcpy(token, *frame_descr, tok_len + 1); > + strscpy(token, *frame_descr, tok_len + 1); > } > > /* Advance frame_descr past separator. */ > -- > 1.8.3.1 > -- Alexander Potapenko Software Engineer Google Germany GmbH Erika-Mann-Straße, 33 80636 München Geschäftsführer: Paul Manicle, Halimah DeLaine Prado Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg
Re: [PATCH 5/9] security: keys: trusted: Allow storage of PCR values in creation data
On Sat, Feb 20, 2021 at 05:09:07AM +0200, Jarkko Sakkinen wrote: > Something popped into mind: could we make PCR 23 reservation dynamic > instead of a config option. > > E.g. if the user space uses it, then it's dirty and hibernate will > fail. I really dislike the static compilation time firewall on it. We can fail hibernation if userland hasn't flagged things, but the concern is that if you hibernate with PCR 23 blocking enabled and then reboot with the blocking disabled, userland can obtain the blob from the hibernation image, extend PCR 23, modify the image and use the key they've recovered to make it look legitimate, enable PCR 23 blocking again and then resume into their own code.
Re: [PATCH 7/9] pm: hibernate: Optionally use TPM-backed keys to protect image integrity
On Fri, Feb 19, 2021 at 06:20:13PM -0800, Randy Dunlap wrote: > For all of the Kconfig* configuration files throughout the source tree, > the indentation is somewhat different. Lines under a ``config`` definition > are indented with one tab, while help text is indented an additional two > spaces. Whoops, I've no idea how I screwed that up. I'll fix for V2, thanks! > Also, one feature should not be responsible for enabling other "subsystems," > such as KEYS and CRYPTO. They should instead be listed as dependencies. ACK.
Re: [PATCH] mm/kasan: remove volatile keyword
On Mon, Feb 22, 2021 at 6:22 AM Zhiyuan Dai wrote:
>
> Like volatile, the kernel primitives which make concurrent
> access to data safe (spinlocks, mutexes, memory barriers,
> etc.) are designed to prevent unwanted optimization.
>
> If they are being used properly, there will be no need to
> use volatile as well. If volatile is still necessary,
> there is almost certainly a bug in the code somewhere.
> In properly-written kernel code, volatile can only serve
> to slow things down.
>
> see: Documentation/process/volatile-considered-harmful.rst
Nack.
This function does not require volatile variables. It uses volatile in
the same way as C/C++ atomic functions -- it only supports operating
on volatile variables. The same meaning as for const here. Such
functions need to use all possible type modifiers to support all
possible uses.
Anyway, the function is declared in kasan.h. So you would need to
change the signate there in the first place. But the kernel will
either not compile, or it won't compile in future when somebody adds
__kasan_check_read/write for a volatile variable. Such a change first
requires removing all volatile uses from the entire kernel and banning
volatile.
> Signed-off-by: Zhiyuan Dai
> ---
> mm/kasan/shadow.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
> index 7c2c08c..d5ff9ca 100644
> --- a/mm/kasan/shadow.c
> +++ b/mm/kasan/shadow.c
> @@ -25,13 +25,13 @@
>
> #include "kasan.h"
>
> -bool __kasan_check_read(const volatile void *p, unsigned int size)
> +bool __kasan_check_read(const void *p, unsigned int size)
> {
> return check_memory_region((unsigned long)p, size, false, _RET_IP_);
> }
> EXPORT_SYMBOL(__kasan_check_read);
>
> -bool __kasan_check_write(const volatile void *p, unsigned int size)
> +bool __kasan_check_write(const void *p, unsigned int size)
> {
> return check_memory_region((unsigned long)p, size, true, _RET_IP_);
> }
> --
> 1.8.3.1
>
[PATCH] ethernet/broadcom:remove unneeded variable: "ret"
From: dingsenjie
remove unneeded variable: "ret".
Signed-off-by: dingsenjie
---
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
index 28069b2..f30193f 100644
--- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
+++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c
@@ -1395,7 +1395,6 @@ int bnx2x_send_final_clnup(struct bnx2x *bp, u8
clnup_func, u32 poll_cnt)
u32 op_gen_command = 0;
u32 comp_addr = BAR_CSTRORM_INTMEM +
CSTORM_FINAL_CLEANUP_COMPLETE_OFFSET(clnup_func);
- int ret = 0;
if (REG_RD(bp, comp_addr)) {
BNX2X_ERR("Cleanup complete was not 0 before sending\n");
@@ -1420,7 +1419,7 @@ int bnx2x_send_final_clnup(struct bnx2x *bp, u8
clnup_func, u32 poll_cnt)
/* Zero completion for next FLR */
REG_WR(bp, comp_addr, 0);
- return ret;
+ return 0;
}
u8 bnx2x_is_pcie_pending(struct pci_dev *dev)
--
1.9.1
[PATCH] scsi: lpfc: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
./drivers/scsi/lpfc/lpfc_attr.c:4389:6-7: WARNING opportunity for
kobj_to_dev()
./drivers/scsi/lpfc/lpfc_attr.c:6326:60-61: WARNING opportunity for
kobj_to_dev()
./drivers/scsi/lpfc/lpfc_attr.c:6386:60-61: WARNING opportunity for
kobj_to_dev()
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/lpfc/lpfc_attr.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/lpfc/lpfc_attr.c b/drivers/scsi/lpfc/lpfc_attr.c
index 4528166..a3bde0e 100644
--- a/drivers/scsi/lpfc/lpfc_attr.c
+++ b/drivers/scsi/lpfc/lpfc_attr.c
@@ -4385,8 +4385,7 @@ static DEVICE_ATTR(txcmplq_hw, S_IRUGO,
struct bin_attribute *bin_attr,
char *buf, loff_t off, size_t count)
{
- struct device *dev = container_of(kobj, struct device,
- kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct Scsi_Host *shost = class_to_shost(dev);
struct lpfc_vport *vport = (struct lpfc_vport *) shost->hostdata;
struct lpfc_hba *phba = vport->phba;
@@ -6323,7 +6322,7 @@ struct device_attribute *lpfc_vport_attrs[] = {
char *buf, loff_t off, size_t count)
{
size_t buf_off;
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct Scsi_Host *shost = class_to_shost(dev);
struct lpfc_vport *vport = (struct lpfc_vport *) shost->hostdata;
struct lpfc_hba *phba = vport->phba;
@@ -6383,7 +6382,7 @@ struct device_attribute *lpfc_vport_attrs[] = {
{
size_t buf_off;
uint32_t * tmp_ptr;
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct Scsi_Host *shost = class_to_shost(dev);
struct lpfc_vport *vport = (struct lpfc_vport *) shost->hostdata;
struct lpfc_hba *phba = vport->phba;
--
1.8.3.1
Re: [PATCH 3/9] security: keys: trusted: Parse out individual components of the key blob
On Sat, Feb 20, 2021 at 05:05:36AM +0200, Jarkko Sakkinen wrote: > On Sat, Feb 20, 2021 at 01:32:49AM +, Matthew Garrett wrote: > > Performing any sort of state validation of a sealed TPM blob requires > > being able to access the individual members in the response. Parse the > > blob sufficiently to be able to stash pointers to each member, along > > with the length. > > > > Signed-off-by: Matthew Garrett > > I'll just say LGTM for now. Did not see anything obviously wrong in > the code change (and does make sense to nitpick minor things just > yet). > > Need to understand the whole use case just a little bit better. I wrote this up with some more detail at https://mjg59.dreamwidth.org/55845.html - it seemed longer than appropriate for a commit message, but if you'd like more detail somewhere I can certainly add it.
Re: [PATCH] vdpa/mlx5: set_features should allow reset to zero
On Mon, Feb 22, 2021 at 12:14:17PM +0800, Jason Wang wrote:
>
> On 2021/2/19 7:54 下午, Si-Wei Liu wrote:
> > Commit 452639a64ad8 ("vdpa: make sure set_features is invoked
> > for legacy") made an exception for legacy guests to reset
> > features to 0, when config space is accessed before features
> > are set. We should relieve the verify_min_features() check
> > and allow features reset to 0 for this case.
> >
> > It's worth noting that not just legacy guests could access
> > config space before features are set. For instance, when
> > feature VIRTIO_NET_F_MTU is advertised some modern driver
> > will try to access and validate the MTU present in the config
> > space before virtio features are set.
>
>
> This looks like a spec violation:
>
> "
>
> The following driver-read-only field, mtu only exists if VIRTIO_NET_F_MTU is
> set.
> This field specifies the maximum MTU for the driver to use.
> "
>
> Do we really want to workaround this?
>
> Thanks
And also:
The driver MUST follow this sequence to initialize a device:
1. Reset the device.
2. Set the ACKNOWLEDGE status bit: the guest OS has noticed the device.
3. Set the DRIVER status bit: the guest OS knows how to drive the device.
4. Read device feature bits, and write the subset of feature bits understood by
the OS and driver to the
device. During this step the driver MAY read (but MUST NOT write) the
device-specific configuration
fields to check that it can support the device before accepting it.
5. Set the FEATURES_OK status bit. The driver MUST NOT accept new feature bits
after this step.
6. Re-read device status to ensure the FEATURES_OK bit is still set: otherwise,
the device does not
support our subset of features and the device is unusable.
7. Perform device-specific setup, including discovery of virtqueues for the
device, optional per-bus setup,
reading and possibly writing the device’s virtio configuration space, and
population of virtqueues.
8. Set the DRIVER_OK status bit. At this point the device is “live”.
so accessing config space before FEATURES_OK is a spec violation, right?
>
> > Rejecting reset to 0
> > prematurely causes correct MTU and link status unable to load
> > for the very first config space access, rendering issues like
> > guest showing inaccurate MTU value, or failure to reject
> > out-of-range MTU.
> >
> > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> > devices")
> > Signed-off-by: Si-Wei Liu
> > ---
> > drivers/vdpa/mlx5/net/mlx5_vnet.c | 15 +--
> > 1 file changed, 1 insertion(+), 14 deletions(-)
> >
> > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > index 7c1f789..540dd67 100644
> > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > @@ -1490,14 +1490,6 @@ static u64 mlx5_vdpa_get_features(struct vdpa_device
> > *vdev)
> > return mvdev->mlx_features;
> > }
> > -static int verify_min_features(struct mlx5_vdpa_dev *mvdev, u64 features)
> > -{
> > - if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
> > - return -EOPNOTSUPP;
> > -
> > - return 0;
> > -}
> > -
> > static int setup_virtqueues(struct mlx5_vdpa_net *ndev)
> > {
> > int err;
> > @@ -1558,18 +1550,13 @@ static int mlx5_vdpa_set_features(struct
> > vdpa_device *vdev, u64 features)
> > {
> > struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> > struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
> > - int err;
> > print_features(mvdev, features, true);
> > - err = verify_min_features(mvdev, features);
> > - if (err)
> > - return err;
> > -
> > ndev->mvdev.actual_features = features & ndev->mvdev.mlx_features;
> > ndev->config.mtu = cpu_to_mlx5vdpa16(mvdev, ndev->mtu);
> > ndev->config.status |= cpu_to_mlx5vdpa16(mvdev, VIRTIO_NET_S_LINK_UP);
> > - return err;
> > + return 0;
> > }
> > static void mlx5_vdpa_set_config_cb(struct vdpa_device *vdev, struct
> > vdpa_callback *cb)
[PATCH] mtd: rawnand: qcom: Rename parameter name in macro
This change will rename parameter name in macro nandc_set_read_loc().renamed parameter names are cw_offset, read_size, is_last_read_loc. Sinc in QPIC V2 on-wards there is separate location register to read last code word, so to just differnciate b/w is_last_read_loc from last_cw this change needed. Signed-off-by: Md Sadre Alam --- drivers/mtd/nand/raw/qcom_nandc.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/mtd/nand/raw/qcom_nandc.c b/drivers/mtd/nand/raw/qcom_nandc.c index 4189a7f..bfefb4e 100644 --- a/drivers/mtd/nand/raw/qcom_nandc.c +++ b/drivers/mtd/nand/raw/qcom_nandc.c @@ -181,11 +181,11 @@ #defineECC_BCH_4BITBIT(2) #defineECC_BCH_8BITBIT(3) -#define nandc_set_read_loc(nandc, reg, offset, size, is_last) \ +#define nandc_set_read_loc(nandc, reg, cw_offset, read_size, is_last_read_loc) \ nandc_set_reg(nandc, NAND_READ_LOCATION_##reg, \ - ((offset) << READ_LOCATION_OFFSET) | \ - ((size) << READ_LOCATION_SIZE) | \ - ((is_last) << READ_LOCATION_LAST)) + ((cw_offset) << READ_LOCATION_OFFSET) | \ + ((read_size) << READ_LOCATION_SIZE) | \ + ((is_last_read_loc) << READ_LOCATION_LAST)) /* * Returns the actual register address for all NAND_DEV_ registers -- 2.7.4
Re: [PATCH] lightnvm: use kobj_to_dev()
On 22/02/2021 07.06, Chaitanya Kulkarni wrote:
This fixs coccicheck warning:-
drivers/nvme//host/lightnvm.c:1243:60-61: WARNING opportunity for
kobj_to_dev()
Signed-off-by: Chaitanya Kulkarni
---
drivers/nvme/host/lightnvm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/nvme/host/lightnvm.c b/drivers/nvme/host/lightnvm.c
index b705988629f2..e3240d189093 100644
--- a/drivers/nvme/host/lightnvm.c
+++ b/drivers/nvme/host/lightnvm.c
@@ -1240,7 +1240,7 @@ static struct attribute *nvm_dev_attrs[] = {
static umode_t nvm_dev_attrs_visible(struct kobject *kobj,
struct attribute *attr, int index)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct gendisk *disk = dev_to_disk(dev);
struct nvme_ns *ns = disk->private_data;
struct nvm_dev *ndev = ns->ndev;
Thanks, Chaitanya. I'll pull it in.
[PATCH] scsi: qedf: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
./drivers/scsi/qedf/qedf_attr.c:105:26-27: WARNING opportunity for
kobj_to_dev()
./drivers/scsi/qedf/qedf_attr.c:134:24-25: WARNING opportunity for
kobj_to_dev()
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/qedf/qedf_attr.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/scsi/qedf/qedf_attr.c b/drivers/scsi/qedf/qedf_attr.c
index d995f72..33d2281 100644
--- a/drivers/scsi/qedf/qedf_attr.c
+++ b/drivers/scsi/qedf/qedf_attr.c
@@ -101,8 +101,7 @@ void qedf_capture_grc_dump(struct qedf_ctx *qedf)
size_t count)
{
ssize_t ret = 0;
- struct fc_lport *lport = shost_priv(dev_to_shost(container_of(kobj,
- struct device, kobj)));
+ struct fc_lport *lport = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
struct qedf_ctx *qedf = lport_priv(lport);
if (test_bit(QEDF_GRCDUMP_CAPTURE, >flags)) {
@@ -130,8 +129,7 @@ void qedf_capture_grc_dump(struct qedf_ctx *qedf)
return ret;
- lport = shost_priv(dev_to_shost(container_of(kobj,
- struct device, kobj)));
+ lport = shost_priv(dev_to_shost(kobj_to_dev(kobj)));
qedf = lport_priv(lport);
buf[1] = 0;
--
1.8.3.1
Re: [PATCH] Revert "ath9k: fix ath_tx_process_buffer() potential null ptr dereference"
Shuah Khan wrote:
> This reverts commit a56c14bb21b296fb6d395164ab62ef2e419e5069.
>
> ath_tx_process_buffer() doesn't dereference or check sta and passes it
> to ath_tx_complete_aggr() and ath_tx_complete_buf().
>
> ath_tx_complete_aggr() checks the pointer before use. No problem here.
>
> ath_tx_complete_buf() doesn't check or dereference sta and passes it on
> to ath_tx_complete(). ath_tx_complete() doesn't check or dereference sta,
> but assigns it to tx_info->status.status_driver_data[0]
>
> ath_tx_complete_buf() is called from ath_tx_complete_aggr() passing
> null ieee80211_sta pointer.
>
> There is a potential for dereference later on, if and when the
> tx_info->status.status_driver_data[0]is referenced. In addition, the
> rcu read lock might be released before referencing the contents.
>
> ath_tx_complete_buf() should be fixed to check sta perhaps? Worth
> looking into.
>
> Reverting this patch because it doesn't solve the problem and introduces
> memory leak by skipping buffer completion if the pointer (sta) is NULL.
>
> Fixes: a56c14bb21b2 ("ath9k: fix ath_tx_process_buffer() potential null ptr
> dereference")
> Signed-off-by: Shuah Khan
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
14ebaeeff8d0 Revert "ath9k: fix ath_tx_process_buffer() potential null ptr
dereference"
--
https://patchwork.kernel.org/project/linux-wireless/patch/20210217211801.22540-1-sk...@linuxfoundation.org/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[GIT PULL] exfat update for 5.12-rc1
Hi Linus, This is exfat update pull request for v5.12-rc1. I add description of this pull request on below. Please pull exfat with following ones. Thanks! The following changes since commit f40ddce88593482919761f74910f42f4b84c004b: Linux 5.11 (2021-02-14 14:32:24 -0800) are available in the Git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/linkinjeon/exfat.git tags/exfat-for-5.12-rc1 for you to fetch changes up to f728760aa923f1dd3a4818368dbdbd2c7d63b370: exfat: improve performance of exfat_free_cluster when using dirsync mount option (2021-02-22 09:55:14 +0900) Description for this pull request: - Improve file deletion performance with dirsync mount option. - fix shift-out-of-bounds in exfat_fill_super() generated by syzkaller. Hyeongseok Kim (1): exfat: improve performance of exfat_free_cluster when using dirsync mount option Namjae Jeon (1): exfat: fix shift-out-of-bounds in exfat_fill_super() fs/exfat/balloc.c| 4 ++-- fs/exfat/exfat_fs.h | 2 +- fs/exfat/exfat_raw.h | 4 fs/exfat/fatent.c| 43 +-- fs/exfat/super.c | 31 ++- 5 files changed, 70 insertions(+), 14 deletions(-)
Re: [PATCH] virtio: don't prompt CONFIG_VIRTIO_PCI_MODERN
On Mon, Feb 22, 2021 at 11:42:44AM +0800, Jason Wang wrote:
>
> On 2021/2/19 11:38 下午, Guenter Roeck wrote:
> > On 2/19/21 12:45 AM, Jason Wang wrote:
> > > We used to prompt CONFIG_VIRTIO_PCI_MODERN to user which may bring a
> > > lot of confusion. E.g it may break various default configs which want
> > > virtio devices.
> > >
> > > So this patch fixes this by hide the prompot and document the
> > ... by hiding the prompt and documenting ...
>
>
> Hi Michael:
>
> Would you like me to post a new version or you can fix those typos when
> applying the patch?
>
> Thanks
A new version. However I have a suggestion.
How about we call the new library VIRTIO_PCI_LIB? That would be
a new auto-selected symbol.
We can then keep VIRTIO_PCI as a symbol enabling the actual driver.
>
> >
> > > dependency.
> > >
> > > Cc: Arnd Bergmann
> > > Cc: Anders Roxell
> > > Cc: Guenter Roeck
> > > Reported-by: Naresh Kamboju
> > > Fixes: 86b87c9d858b6 ("virtio-pci: introduce modern device module")
> > > Signed-off-by: Jason Wang
> > Reviewed-by: Guenter Roeck
> >
> > > ---
> > > drivers/virtio/Kconfig | 9 +
> > > 1 file changed, 5 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
> > > index 6b9b81f4b8c2..be7df369bc2b 100644
> > > --- a/drivers/virtio/Kconfig
> > > +++ b/drivers/virtio/Kconfig
> > > @@ -13,12 +13,12 @@ config ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
> > > VIRTIO_F_ACCESS_PLATFORM
> > > config VIRTIO_PCI_MODERN
> > > - tristate "Modern Virtio PCI Device"
> > > - depends on PCI
> > > + tristate
> > > help
> > > Modern PCI device implementation. This module implements the
> > > basic probe and control for devices which are based on modern
> > > - PCI device with possible vendor specific extensions.
> > > + PCI device with possible vendor specific extensions. Any
> > > + module that selects this module must depend on PCI.
> > > menuconfig VIRTIO_MENU
> > > bool "Virtio drivers"
> > > @@ -28,7 +28,8 @@ if VIRTIO_MENU
> > > config VIRTIO_PCI
> > > tristate "PCI driver for virtio devices"
> > > - depends on VIRTIO_PCI_MODERN
> > > + depends on PCI
> > > + select VIRTIO_PCI_MODERN
> > > select VIRTIO
> > > help
> > > This driver provides support for virtio based paravirtual
> > > device
> > >
Re: [PATCH] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop
陈浩 writes:
> By git blame command, I know that the assignment of .driver.pm =
> RTW_PM_OPS
>
> was in commit 44bc17f7f5b3b("rtw88: support wowlan feature for
> 8822c"),
>
> and another commit 7dc7c41607d19("avoid unused function warnings")
>
> pointed out rtw_pci_resume() and rtw_pci_suspend() are not used at
> all.
>
> So I think it's safe to remove them.
>
> Currently, I find that the rtl8822ce wifi chip and the pci bridge of
> it are not linked by pci
>
> after wake up by `lspci` command.
>
> when I set `pcie_aspm.policy=performance ` in the GRUB. The machine
> sleep and
>
> wake up normal.So I think when this ops is assignmented,the sleep and
> wake up procedure
>
> may cause pci device not linked.
Please don't use HTML, our lists automatically drop all HTML email.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] scsi: iscsi: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
./drivers/scsi/scsi_transport_iscsi.c:436:60-61: WARNING opportunity for
kobj_to_dev()
./drivers/scsi/scsi_transport_iscsi.c:1128:60-61: WARNING opportunity
for kobj_to_dev()
./drivers/scsi/scsi_transport_iscsi.c:4043:61-62: WARNING opportunity
for kobj_to_dev()
./drivers/scsi/scsi_transport_iscsi.c:4312:61-62: WARNING opportunity
for kobj_to_dev()
./drivers/scsi/scsi_transport_iscsi.c:4456:61-62: WARNING opportunity
for kobj_to_dev()
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/scsi_transport_iscsi.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/scsi/scsi_transport_iscsi.c
b/drivers/scsi/scsi_transport_iscsi.c
index 2e68c0a..467ed95 100644
--- a/drivers/scsi/scsi_transport_iscsi.c
+++ b/drivers/scsi/scsi_transport_iscsi.c
@@ -433,7 +433,7 @@ struct device_attribute dev_attr_##_prefix##_##_name =
\
static umode_t iscsi_iface_attr_is_visible(struct kobject *kobj,
struct attribute *attr, int i)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct iscsi_iface *iface = iscsi_dev_to_iface(dev);
struct iscsi_transport *t = iface->transport;
int param;
@@ -1125,7 +1125,7 @@ static umode_t
iscsi_flashnode_conn_attr_is_visible(struct kobject *kobj,
struct attribute *attr,
int i)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct iscsi_bus_flash_conn *fnode_conn = iscsi_dev_to_flash_conn(dev);
struct iscsi_transport *t = fnode_conn->transport;
int param;
@@ -4040,7 +4040,7 @@ static ISCSI_CLASS_ATTR(conn, field, S_IRUGO,
\
static umode_t iscsi_conn_attr_is_visible(struct kobject *kobj,
struct attribute *attr, int i)
{
- struct device *cdev = container_of(kobj, struct device, kobj);
+ struct device *cdev = kobj_to_dev(kobj);
struct iscsi_cls_conn *conn = transport_class_to_conn(cdev);
struct iscsi_transport *t = conn->transport;
int param;
@@ -4309,7 +4309,7 @@ static ISCSI_CLASS_ATTR(priv_sess, field, S_IRUGO |
S_IWUSR, \
static umode_t iscsi_session_attr_is_visible(struct kobject *kobj,
struct attribute *attr, int i)
{
- struct device *cdev = container_of(kobj, struct device, kobj);
+ struct device *cdev = kobj_to_dev(kobj);
struct iscsi_cls_session *session = transport_class_to_session(cdev);
struct iscsi_transport *t = session->transport;
int param;
@@ -4453,7 +4453,7 @@ static ISCSI_CLASS_ATTR(host, field, S_IRUGO,
show_host_param_##param,\
static umode_t iscsi_host_attr_is_visible(struct kobject *kobj,
struct attribute *attr, int i)
{
- struct device *cdev = container_of(kobj, struct device, kobj);
+ struct device *cdev = kobj_to_dev(kobj);
struct Scsi_Host *shost = transport_class_to_shost(cdev);
struct iscsi_internal *priv = to_iscsi_internal(shost->transportt);
int param;
--
1.8.3.1
Re: [PATCH v2] pwm: sunxi: Add Allwinner SoC PWM controller driver
On Sat, Feb 20, 2021 at 10:18:27AM +0800, 班涛 wrote: > Uwe Kleine-König 于2021年2月3日周三 下午11:12写道： > > > Hello Ban, > > > > On Wed, Feb 03, 2021 at 08:53:17PM +0800, Ban Tao wrote: > > > v1->v2: > > > > FTR: v1 wasn't sent to any list, so don't try to find it in some > > archive. > > > > Sorry, I understand. So is the next patch v3? Or v2? Using v3 is fine. Please don't send another series that is called v2. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | https://www.pengutronix.de/ | signature.asc Description: PGP signature
Re: [PATCH] drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features
Hi Nicolas,
W dniu 22.02.2021 o 06:31, Nicolas Boichat pisze:
> On Mon, Feb 22, 2021 at 3:08 AM Laurent Pinchart
> wrote:
>> Hi Nicolas,
>>
>> Thank you for the patch.
>>
>> On Thu, Feb 11, 2021 at 11:33:55AM +0800, Nicolas Boichat wrote:
>>> Many of the DSI flags have names opposite to their actual effects,
>>> e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
>>> be disabled. Fix this by including _NO_ in the flag names, e.g.
>>> MIPI_DSI_MODE_NO_EOT_PACKET.
>>>
>>> Signed-off-by: Nicolas Boichat
>> This looks good to me, it increases readability.
>>
>> Reviewed-by: Laurent Pinchart
>>
>> Please however see the end of the mail for a comment.
Reviewed-by: Andrzej Hajda
And comment at the end.
>>
>>> ---
>>> I considered adding _DISABLE_ instead, but that'd make the
>>> flag names a big too long.
>>>
>>> Generated with:
>>> flag=MIPI_DSI_MODE_VIDEO_HFP; git grep $flag | cut -f1 -d':' | \
>>>xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HFP/" {}
>>> flag=MIPI_DSI_MODE_VIDEO_HBP; git grep $flag | cut -f1 -d':' | \
>>>xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HBP/" {}
>>> flag=MIPI_DSI_MODE_VIDEO_HSA; git grep $flag | cut -f1 -d':' | \
>>>xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HSA/" {}
>>> flag=MIPI_DSI_MODE_EOT_PACKET; git grep $flag | cut -f1 -d':' | \
>>>xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_NO_EOT_PACKET/" {}
>>> (then minor format changes)
>> Ever tried coccinelle ? :-)
> Fun project for next time ,-)
>
>>> drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
>>> drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
>>> drivers/gpu/drm/bridge/cdns-dsi.c| 4 ++--
>>> drivers/gpu/drm/bridge/tc358768.c| 2 +-
>>> drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
>>> drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
>>> drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
>>> drivers/gpu/drm/msm/dsi/dsi_host.c | 8
>>> drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 2 +-
>>> drivers/gpu/drm/panel/panel-dsi-cm.c | 2 +-
>>> drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
>>> drivers/gpu/drm/panel/panel-khadas-ts050.c | 2 +-
>>> drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 2 +-
>>> drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
>>> drivers/gpu/drm/panel/panel-novatek-nt35510.c| 2 +-
>>> drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c | 2 +-
>>> drivers/gpu/drm/panel/panel-samsung-s6d16d0.c| 2 +-
>>> drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 2 +-
>>> drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c| 2 +-
>>> drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 4 ++--
>>> drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +-
>>> drivers/gpu/drm/panel/panel-simple.c | 2 +-
>>> drivers/gpu/drm/panel/panel-sony-acx424akp.c | 2 +-
>>> drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 2 +-
>>> include/drm/drm_mipi_dsi.h | 8
>>> 25 files changed, 36 insertions(+), 36 deletions(-)
>>>
>>> []
>>> diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
>>> index 360e6377e84b..ba91cf22af51 100644
>>> --- a/include/drm/drm_mipi_dsi.h
>>> +++ b/include/drm/drm_mipi_dsi.h
>>> @@ -119,15 +119,15 @@ struct mipi_dsi_host
>>> *of_find_mipi_dsi_host_by_node(struct device_node *node);
>>> /* enable hsync-end packets in vsync-pulse and v-porch area */
>>> #define MIPI_DSI_MODE_VIDEO_HSE BIT(4)
>> We're mixing bits that enable a feature and bits that disable a feature.
>> Are these bits defined in the DSI spec, or internal to DRM ? In the
>> latter case, would it make sense to standardize on one "polarity" ? That
>> would be a more intrusive change in drivers though.
> Yes, that'd require auditing every single code path and reverse the
> logic as needed. I'm not volunteering for that ,-P (hopefully the
> current change is still an improvement).
>
> Hopefully real DSI experts can comment (Andrzej?), I think the default
> are sensible settings?
Hehe, "real DSI expert" :), ok I've read spec few times :)
If I remember correctly the spec did not prioritizes these modes, specs
are publicly available if somebody want to check it feel free.
These values were taken from defaults for Exynos DSI, as nobody at the
time has better idea.
We could try to optimize it by looking for example in different dsi
hosts defaults, or maybe dsi devices, but I am not sure if it is worth time.
This solution is good for me.
Regards
Andrzej
>
>
>>> /* disable hfront-porch area */
>>> -#define MIPI_DSI_MODE_VIDEO_HFP BIT(5)
>>> +#define MIPI_DSI_MODE_VIDEO_NO_HFP BIT(5)
>>> /* disable hback-porch area */
>>> -#define MIPI_DSI_MODE_VIDEO_HBP BIT(6)
>>> +#define
arch/x86/um/shared/sysdep/stub_32.h:80:1: warning: 'inline' is not at beginning of declaration
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 31caf8b2a847214be856f843e251fc2ed2cd1075
commit: 9f0b4807a44ff81cf59421c8a86641efec586610 um: rework userspace stubs to
not hard-code stub location
date: 9 days ago
config: um-i386_defconfig (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce (this is a W=1 build):
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9f0b4807a44ff81cf59421c8a86641efec586610
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 9f0b4807a44ff81cf59421c8a86641efec586610
# save the attached .config to linux build tree
make W=1 ARCH=um SUBARCH=i386
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
In file included from arch/x86/um/shared/sysdep/stub.h:9,
from arch/um/kernel/skas/clone.c:14:
>> arch/x86/um/shared/sysdep/stub_32.h:80:1: warning: 'inline' is not at
>> beginning of declaration [-Wold-style-declaration]
80 | static void inline remap_stack_and_trap(void)
| ^~
--
In file included from arch/x86/um/shared/sysdep/stub.h:9,
from arch/um/os-Linux/skas/process.c:23:
>> arch/x86/um/shared/sysdep/stub_32.h:80:1: warning: 'inline' is not at
>> beginning of declaration [-Wold-style-declaration]
80 | static void inline remap_stack_and_trap(void)
| ^~
arch/um/os-Linux/skas/process.c:106:6: warning: no previous prototype for
'wait_stub_done' [-Wmissing-prototypes]
106 | void wait_stub_done(int pid)
| ^~
arch/um/os-Linux/skas/process.c:720:6: warning: no previous prototype for
'__switch_mm' [-Wmissing-prototypes]
720 | void __switch_mm(struct mm_id *mm_idp)
| ^~~
vim +/inline +80 arch/x86/um/shared/sysdep/stub_32.h
79
> 80 static void inline remap_stack_and_trap(void)
81 {
82 __asm__ volatile (
83 "movl %%esp,%%ebx ;"
84 "andl %0,%%ebx ;"
85 "movl %1,%%eax ;"
86 "movl %%ebx,%%edi ; addl %2,%%edi ; movl (%%edi),%%edi
;"
87 "movl %%ebx,%%ebp ; addl %3,%%ebp ; movl (%%ebp),%%ebp
;"
88 "int $0x80 ;"
89 "addl %4,%%ebx ; movl %%eax, (%%ebx) ;"
90 "int $3"
91 : :
92 "g" (~(UM_KERN_PAGE_SIZE - 1)),
93 "g" (STUB_MMAP_NR),
94 "g" (UML_STUB_FIELD_FD),
95 "g" (UML_STUB_FIELD_OFFSET),
96 "g" (UML_STUB_FIELD_CHILD_ERR),
97 "c" (UM_KERN_PAGE_SIZE),
98 "d" (PROT_READ | PROT_WRITE),
99 "S" (MAP_FIXED | MAP_SHARED)
100 :
101 "memory");
102 }
103
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] mailbox: arm_mhuv2: Skip calling kfree() with invalid pointer
It is possible that 'data' passed to kfree() is set to a error value
instead of allocated space. Make sure it doesn't get called with invalid
pointer.
Fixes: 5a6338cce9f4 ("mailbox: arm_mhuv2: Add driver")
Cc: v5.11 # v5.11
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Viresh Kumar
---
drivers/mailbox/arm_mhuv2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/arm_mhuv2.c b/drivers/mailbox/arm_mhuv2.c
index cdfb1939fabf..d997f8ebfa98 100644
--- a/drivers/mailbox/arm_mhuv2.c
+++ b/drivers/mailbox/arm_mhuv2.c
@@ -699,7 +699,9 @@ static irqreturn_t mhuv2_receiver_interrupt(int irq, void
*arg)
ret = IRQ_HANDLED;
}
- kfree(data);
+ if (!IS_ERR(data))
+ kfree(data);
+
return ret;
}
--
2.25.0.rc1.19.g042ed3e048af
Re: [PATCH net-next RFC v4] net: hdlc_x25: Queue outgoing LAPB frames
On 2021-02-19 21:28, Xie He wrote: On Fri, Feb 19, 2021 at 10:39 AM Jakub Kicinski wrote: Not entirely sure what the argument is about but adding constants would certainly help. Leon wants me to replace this: dev->needed_headroom = 3 - 1; with this: /* 2 is the result of 3 - 1 */ dev->needed_headroom = 2; But I don't feel his way is better than my way. More fundamentally IDK if we can make such a fundamental change here. When users upgrade from older kernel are all their scripts going to work the same? Won't they have to bring the new netdev up? Yes, this patch will break backward compatibility. Users with old scripts will find them no longer working. However, it's hard for me to find a better way to solve the problem described in the commit message. So I sent this as an RFC to see what people think about this. (Martin Schiller seems to be OK with this.) Well, I said I would like to test it. I'm not really happy with this change because it breaks compatibility. We then suddenly have 2 interfaces; the X.25 routings are to be set via the "new" hdlc_x25 interfaces instead of the hdlc interfaces. I currently just don't have a nicer solution to fix this queueing problem either. On the other hand, since the many years we have been using the current state, I have never noticed any problems with discarded frames. So it might be more a theoretical problem than a practical one. I think users who don't use scripts can adapt quickly and users who use scripts can also trivally fix their scripts. Actually many existing commits in the kernel also (more or less) cause some user-visible changes. But I admit this patch is a really big change.
Re: [PATCH v8 2/4] KEYS: trusted: Introduce TEE based Trusted Keys
On Tue, 16 Feb 2021 at 12:59, Jarkko Sakkinen wrote: > > On Mon, Feb 15, 2021 at 06:37:00PM +0530, Sumit Garg wrote: > > On Fri, 12 Feb 2021 at 05:04, Jarkko Sakkinen wrote: > > > > > > On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote: > > > > Hi Jarkko, > > > > > > > > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen wrote: > > > > > > > > > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote: > > > > > > > > > > > > > > > > > > On 1/21/21 4:24 PM, Jarkko Sakkinen wrote: > > > > > > > On Thu, Jan 21, 2021 at 05:07:42PM +0200, Jarkko Sakkinen wrote: > > > > > > >> On Thu, Jan 21, 2021 at 09:44:07AM +0100, Jerome Forissier wrote: > > > > > > >>> > > > > > > >>> > > > > > > >>> On 1/21/21 1:02 AM, Jarkko Sakkinen via OP-TEE wrote: > > > > > > On Wed, Jan 20, 2021 at 12:53:28PM +0530, Sumit Garg wrote: > > > > > > > On Wed, 20 Jan 2021 at 07:01, Jarkko Sakkinen > > > > > > > wrote: > > > > > > >> > > > > > > >> On Tue, Jan 19, 2021 at 12:30:42PM +0200, Jarkko Sakkinen > > > > > > >> wrote: > > > > > > >>> On Fri, Jan 15, 2021 at 11:32:31AM +0530, Sumit Garg wrote: > > > > > > On Thu, 14 Jan 2021 at 07:35, Jarkko Sakkinen > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Jan 13, 2021 at 04:47:00PM +0530, Sumit Garg > > > > > > > wrote: > > > > > > >> Hi Jarkko, > > > > > > >> > > > > > > >> On Mon, 11 Jan 2021 at 22:05, Jarkko Sakkinen > > > > > > >> wrote: > > > > > > >>> > > > > > > >>> On Tue, Nov 03, 2020 at 09:31:44PM +0530, Sumit Garg > > > > > > >>> wrote: > > > > > > Add support for TEE based trusted keys where TEE > > > > > > provides the functionality > > > > > > to seal and unseal trusted keys using hardware unique > > > > > > key. > > > > > > > > > > > > Refer to Documentation/tee.txt for detailed > > > > > > information about TEE. > > > > > > > > > > > > Signed-off-by: Sumit Garg > > > > > > >>> > > > > > > >>> I haven't yet got QEMU environment working with > > > > > > >>> aarch64, this produces > > > > > > >>> just a blank screen: > > > > > > >>> > > > > > > >>> ./output/host/usr/bin/qemu-system-aarch64 -M virt -cpu > > > > > > >>> cortex-a53 -smp 1 -kernel output/images/Image -initrd > > > > > > >>> output/images/rootfs.cpio -serial stdio > > > > > > >>> > > > > > > >>> My BuildRoot fork for TPM and keyring testing is > > > > > > >>> located over here: > > > > > > >>> > > > > > > >>> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/buildroot-tpmdd.git/ > > > > > > >>> > > > > > > >>> The "ARM version" is at this point in aarch64 branch. > > > > > > >>> Over time I will > > > > > > >>> define tpmdd-x86_64 and tpmdd-aarch64 boards and > > > > > > >>> everything will be then > > > > > > >>> in the master branch. > > > > > > >>> > > > > > > >>> To create identical images you just need to > > > > > > >>> > > > > > > >>> $ make tpmdd_defconfig && make > > > > > > >>> > > > > > > >>> Can you check if you see anything obviously wrong? I'm > > > > > > >>> eager to test this > > > > > > >>> patch set, and in bigger picture I really need to have > > > > > > >>> ready to run > > > > > > >>> aarch64 environment available. > > > > > > >> > > > > > > >> I would rather suggest you to follow steps listed here > > > > > > >> [1] as to test > > > > > > >> this feature on Qemu aarch64 we need to build firmwares > > > > > > >> such as TF-A, > > > > > > >> OP-TEE, UEFI etc. which are all integrated into OP-TEE > > > > > > >> Qemu build > > > > > > >> system [2]. And then it would be easier to migrate them > > > > > > >> to your > > > > > > >> buildroot environment as well. > > > > > > >> > > > > > > >> [1] > > > > > > >> https://lists.trustedfirmware.org/pipermail/op-tee/2020-May/27.html > > > > > > >> [2] > > > > > > >> https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8 > > > > > > >> > > > > > > >> -Sumit > > > > > > > > > > > > > > Can you provide 'keyctl_change'? Otherwise, the steps are > > > > > > > easy to follow. > > > > > > > > > > > > > > > > > > > $ cat keyctl_change > > > > > > diff --git a/common.mk b/common.mk > > > > > > index aeb7b41..663e528 100644 > > > > > > --- a/common.mk > > > > > > +++ b/common.mk > > > > > > @@ -229,6 +229,7 @@ BR2_PACKAGE_OPTEE_TEST_SDK ?= > > > > > > $(OPTEE_OS_TA_DEV_KIT_DIR) > >
Re: [PATCH] RTIC: selinux: ARM64: Move selinux_state to a separate page
On 2021-02-17 15:23, Ard Biesheuvel wrote: On Wed, 17 Feb 2021 at 10:42, Will Deacon wrote: [Please include arm64 and kvm folks for threads involving the stage-2 MMU] On Tue, Feb 16, 2021 at 03:47:52PM +0530, Preeti Nagar wrote: > The changes introduce a new security feature, RunTime Integrity Check > (RTIC), designed to protect Linux Kernel at runtime. The motivation > behind these changes is: > 1. The system protection offered by Security Enhancements(SE) for > Android relies on the assumption of kernel integrity. If the kernel > itself is compromised (by a perhaps as yet unknown future vulnerability), > SE for Android security mechanisms could potentially be disabled and > rendered ineffective. > 2. Qualcomm Snapdragon devices use Secure Boot, which adds cryptographic > checks to each stage of the boot-up process, to assert the authenticity > of all secure software images that the device executes. However, due to > various vulnerabilities in SW modules, the integrity of the system can be > compromised at any time after device boot-up, leading to un-authorized > SW executing. > > The feature's idea is to move some sensitive kernel structures to a > separate page and monitor further any unauthorized changes to these, > from higher Exception Levels using stage 2 MMU. Moving these to a > different page will help avoid getting page faults from un-related data. > The mechanism we have been working on removes the write permissions for > HLOS in the stage 2 page tables for the regions to be monitored, such > that any modification attempts to these will lead to faults being > generated and handled by handlers. If the protected assets are moved to > a separate page, faults will be generated corresponding to change attempts > to these assets only. If not moved to a separate page, write attempts to > un-related data present on the monitored pages will also be generated. > > Using this feature, some sensitive variables of the kernel which are > initialized after init or are updated rarely can also be protected from > simple overwrites and attacks trying to modify these. Although I really like the idea of using stage-2 to protect the kernel, I think the approach you outline here is deeply flawed. Identifying "sensitive variables" of the kernel to protect is subjective and doesn't scale. Furthermore, the triaging of what constitues a valid access is notably absent from your description and is assumedly implemented in an opaque blob at EL2. I think a better approach would be along the lines of: 1. Introduce the protection at stage-1 (like we already have for mapping e.g. the kernel text R/O) 2. Implement the handlers in the kernel, so the heuristics are clear. 3. Extend this to involve KVM, so that the host can manage its own stage-2 to firm-up the stage-1 protections. Agree here. Making an arbitrary set of data structures r/o behind the OS's back doesn't seem like an easy thing to maintain or reason about, especially if this r/o-ness is only enforced on a tiny subset of devices. If something needs to be writable only at boot, we have __ro_after_init, and having hypervisor assisted enforcement of /that/ might be a worthwhile thing to consider, including perhaps ways to do controlled patching of this region at runtime. Thank you for the suggestions. We will look into the possibility of protection of __ro_after_init and controlled updates to these. I understand, if this can be made generic as Will also suggested, it might be more useful and easy to scale and maintain. I also think we should avoid tying this to specific data structures. Rather, we should introduce a mechanism to make arbitrary data read-only. I've CC'd Ard and Marc, as I think they've both been thinking about this sort of thing recently as well. Will
arch/mips/pci/pci-ar2315.c:178:13: warning: no previous prototype for function 'dma_to_phys'
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 31caf8b2a847214be856f843e251fc2ed2cd1075
commit: 7bc5c428a660d4d1bc95ba54bf4cb6bccf8c3029 dma-direct: remove
__dma_to_phys
date: 5 months ago
config: mips-randconfig-r032-20210222 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
c9439ca36342fb6013187d0a69aef92736951476)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install mips cross compiling tool for clang build
# apt-get install binutils-mips-linux-gnu
#
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7bc5c428a660d4d1bc95ba54bf4cb6bccf8c3029
git remote add linus
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 7bc5c428a660d4d1bc95ba54bf4cb6bccf8c3029
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=mips
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
arch/mips/pci/pci-ar2315.c:173:12: warning: no previous prototype for
function '__phys_to_dma' [-Wmissing-prototypes]
dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
^
arch/mips/pci/pci-ar2315.c:173:1: note: declare 'static' if the function is
not intended to be used outside of this translation unit
dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
^
static
>> arch/mips/pci/pci-ar2315.c:178:13: warning: no previous prototype for
>> function 'dma_to_phys' [-Wmissing-prototypes]
phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
^
arch/mips/pci/pci-ar2315.c:178:1: note: declare 'static' if the function is
not intended to be used outside of this translation unit
phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
^
static
2 warnings generated.
vim +/dma_to_phys +178 arch/mips/pci/pci-ar2315.c
172
> 173 dma_addr_t __phys_to_dma(struct device *dev, phys_addr_t paddr)
174 {
175 return paddr + ar2315_dev_offset(dev);
176 }
177
> 178 phys_addr_t dma_to_phys(struct device *dev, dma_addr_t dma_addr)
179 {
180 return dma_addr - ar2315_dev_offset(dev);
181 }
182
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[RFC PATCH 4/4] i40e: don't open i40iw client for kdump
i40iw consumes huge amounts of memory. For example, on a x86_64 machine,
i40iw consumed 1.5GB for Intel Corporation Ethernet Connection X722 for
for 1GbE while "craskernel=auto" only reserved 160M. With the module
parameter "resource_profile=2", we can reduce the memory usage of i40iw
to ~300M which is still too much for kdump.
Disabling the client registration would spare us the client interface
operation open , i.e., i40iw_open for iwarp/uda device. Thus memory is
saved for kdump.
Signed-off-by: Coiby Xu
---
drivers/net/ethernet/intel/i40e/i40e_client.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_client.c
b/drivers/net/ethernet/intel/i40e/i40e_client.c
index a2dba32383f6..aafc2587f389 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_client.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_client.c
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
#include "i40e.h"
#include "i40e_prototype.h"
@@ -741,6 +742,12 @@ int i40e_register_client(struct i40e_client *client)
{
int ret = 0;
+ /* Don't open i40iw client for kdump because i40iw will consume huge
+* amounts of memory.
+*/
+ if (is_kdump_kernel())
+ return ret;
+
if (!client) {
ret = -EIO;
goto out;
--
2.30.1
[RFC PATCH 3/4] i40e: use minimal admin queue for kdump
The minimum size of admin send/receive queue is 1 and 2 respectively.
The admin send queue can't be set to 1 because in that case, the
firmware would fail to init.
Signed-off-by: Coiby Xu
---
drivers/net/ethernet/intel/i40e/i40e.h | 2 ++
drivers/net/ethernet/intel/i40e/i40e_main.c | 9 +++--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e.h
b/drivers/net/ethernet/intel/i40e/i40e.h
index 118473dfdcbd..e106c33ff958 100644
--- a/drivers/net/ethernet/intel/i40e/i40e.h
+++ b/drivers/net/ethernet/intel/i40e/i40e.h
@@ -66,6 +66,8 @@
#define I40E_FDIR_RING_COUNT 32
#define I40E_MAX_AQ_BUF_SIZE 4096
#define I40E_AQ_LEN256
+#define I40E_MIN_ARQ_LEN 1
+#define I40E_MIN_ASQ_LEN 2
#define I40E_AQ_WORK_LIMIT 66 /* max number of VFs + a little */
#define I40E_MAX_USER_PRIORITY 8
#define I40E_DEFAULT_TRAFFIC_CLASS BIT(0)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 5307f1744766..2fd8db80b585 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -14847,8 +14847,13 @@ static int i40e_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
i40e_check_recovery_mode(pf);
- hw->aq.num_arq_entries = I40E_AQ_LEN;
- hw->aq.num_asq_entries = I40E_AQ_LEN;
+ if (is_kdump_kernel()) {
+ hw->aq.num_arq_entries = I40E_MIN_ARQ_LEN;
+ hw->aq.num_asq_entries = I40E_MIN_ASQ_LEN;
+ } else {
+ hw->aq.num_arq_entries = I40E_AQ_LEN;
+ hw->aq.num_asq_entries = I40E_AQ_LEN;
+ }
hw->aq.arq_buf_size = I40E_MAX_AQ_BUF_SIZE;
hw->aq.asq_buf_size = I40E_MAX_AQ_BUF_SIZE;
pf->adminq_work_limit = I40E_AQ_WORK_LIMIT;
--
2.30.0
Re: [PATCH] efifb: Ensure graphics device for efifb stays at PCI D0
On Mon, Feb 1, 2021 at 11:21 PM Alex Deucher wrote: > > On Sat, Jan 30, 2021 at 6:27 AM Kai-Heng Feng > wrote: > > > > We are seeing root ports on some desktop boards support D3cold for > > discrete graphics card. So when efifb is in use while graphics device > > isn't bound to a driver, PCI and ACPI will put the graphics to D3cold > > when runtime suspend kicks in, makes efifb stop working. > > > > So ensure the graphics device won't be runtime suspended, to keep efifb > > work all the time. > > > > Signed-off-by: Kai-Heng Feng > > Reviewed-by: Alex Deucher A gentle ping... > > > --- > > drivers/video/fbdev/efifb.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/video/fbdev/efifb.c b/drivers/video/fbdev/efifb.c > > index e57c00824965..19edd7206409 100644 > > --- a/drivers/video/fbdev/efifb.c > > +++ b/drivers/video/fbdev/efifb.c > > @@ -16,6 +16,7 @@ > > #include > > #include > > #include > > +#include > > #include > > #include > > #include /* For drm_get_panel_orientation_quirk */ > > @@ -575,6 +576,7 @@ static int efifb_probe(struct platform_device *dev) > > goto err_fb_dealoc; > > } > > fb_info(info, "%s frame buffer device\n", info->fix.id); > > + pm_runtime_get_sync(_pci_dev->dev); > > return 0; > > > > err_fb_dealoc: > > @@ -601,6 +603,7 @@ static int efifb_remove(struct platform_device *pdev) > > unregister_framebuffer(info); > > sysfs_remove_groups(>dev.kobj, efifb_groups); > > framebuffer_release(info); > > + pm_runtime_put(_pci_dev->dev); > > > > return 0; > > } > > -- > > 2.29.2 > > > > ___ > > dri-devel mailing list > > dri-de...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC PATCH 2/4] i40e: use minimal rx and tx ring buffers for kdump
Use the minimum of the number of descriptors thus we will allocate the
minimal ring buffers for kdump.
Signed-off-by: Coiby Xu
---
drivers/net/ethernet/intel/i40e/i40e_main.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
b/drivers/net/ethernet/intel/i40e/i40e_main.c
index 069c86e2f69d..5307f1744766 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_main.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
@@ -10552,6 +10552,11 @@ static int i40e_set_num_rings_in_vsi(struct i40e_vsi
*vsi)
return -ENODATA;
}
+ if (is_kdump_kernel()) {
+ vsi->num_tx_desc = I40E_MIN_NUM_DESCRIPTORS;
+ vsi->num_rx_desc = I40E_MIN_NUM_DESCRIPTORS;
+ }
+
return 0;
}
--
2.30.0
[RFC PATCH 1/4] i40e: use minimal tx and rx pairs for kdump
Set the number of the MSI-X vectors to 1. When MSI-X is enabled, it's not allowed to use more TC queue pairs than MSI-X vectors (pf->num_lan_msix) exist. Thus the number of tx and rx pairs (vsi->num_queue_pairs) will be equal to the number of MSI-X vectors, i.e., 1. Signed-off-by: Coiby Xu --- drivers/net/ethernet/intel/i40e/i40e_main.c | 9 + 1 file changed, 9 insertions(+) diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c b/drivers/net/ethernet/intel/i40e/i40e_main.c index 1db482d310c2..069c86e2f69d 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_main.c +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c @@ -6,6 +6,7 @@ #include #include #include +#include /* Local includes */ #include "i40e.h" @@ -15000,6 +15001,14 @@ static int i40e_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (err) goto err_switch_setup; + /* Reduce tx and rx pairs for kdump +* When MSI-X is enabled, it's not allowed to use more TC queue +* pairs than MSI-X vectors (pf->num_lan_msix) exist. Thus +* vsi->num_queue_pairs will be equal to pf->num_lan_msix, i.e., 1. +*/ + if (is_kdump_kernel()) + pf->num_lan_msix = 1; + pf->udp_tunnel_nic.set_port = i40e_udp_tunnel_set_port; pf->udp_tunnel_nic.unset_port = i40e_udp_tunnel_unset_port; pf->udp_tunnel_nic.flags = UDP_TUNNEL_NIC_INFO_MAY_SLEEP; -- 2.30.0
[PATCH] w1: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
./include/linux/w1.h:314:62-63: WARNING opportunity for kobj_to_dev()
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
include/linux/w1.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/w1.h b/include/linux/w1.h
index 949d3b1..93f3be8 100644
--- a/include/linux/w1.h
+++ b/include/linux/w1.h
@@ -311,7 +311,7 @@ static inline struct w1_slave* dev_to_w1_slave(struct
device *dev)
static inline struct w1_slave* kobj_to_w1_slave(struct kobject *kobj)
{
- return dev_to_w1_slave(container_of(kobj, struct device, kobj));
+ return dev_to_w1_slave(kobj_to_dev(kobj));
}
static inline struct w1_master* dev_to_w1_master(struct device *dev)
--
1.8.3.1
[PATCH stable-rc queue/4.9 0/1] repatch
I found a dead code in the queue/4.9 branch of the stable-rc repository.
2021-02-03:
commit c27f392040e2f6 ("futex: Provide distinct return value when
owner is exiting")
The function handle_exit_race does not exist. Therefore, the
change in handle_exit_race() is ignored in the patch round.
2021-02-22:
commit e55cb811e612 ("futex: Cure exit race")
Define the handle_exit_race() function,
but no branch in the function returns EBUSY.
As a result, dead code occurs in the attach_to_pi_owner():
int ret = handle_exit_race(uaddr, uval, p);
...
if (ret == -EBUSY)
*exiting = p; /* dead code */
To fix the dead code, modify the commit e55cb811e612 ("futex: Cure exit race"),
or install a patch to incorporate the changes in handle_exit_race().
I am unfamiliar with the processing of the stable-rc queue branch,
and I cannot find the patch mail of the current branch in
https://lore.kernel.org/lkml/?q=%22futex%3A+Cure+exit+race%22
Therefore, I re-integrated commit ac31c7ff8624 ("futex: Provide distinct
return value when owner is exiting").
-
Thomas Gleixner (1):
futex: Provide distinct return value when owner is exiting
kernel/futex.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.27.0
[PATCH stable-rc queue/4.9 1/1] futex: Provide distinct return value when owner is exiting
From: Thomas Gleixner commit ac31c7ff8624409ba3c4901df9237a616c187a5d upstream. attach_to_pi_owner() returns -EAGAIN for various cases: - Owner task is exiting - Futex value has changed The caller drops the held locks (hash bucket, mmap_sem) and retries the operation. In case of the owner task exiting this can result in a live lock. As a preparatory step for seperating those cases, provide a distinct return value (EBUSY) for the owner exiting case. No functional change. Signed-off-by: Thomas Gleixner Reviewed-by: Ingo Molnar Acked-by: Peter Zijlstra (Intel) Link: https://lkml.kernel.org/r/20191106224556.935606...@linutronix.de [nixiaoming: Modify handle_exit_race() to avoid dead code.] Cc: sta...@vger.kernel.org # queue/4.9 Signed-off-by: Xiaoming Ni --- kernel/futex.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/futex.c b/kernel/futex.c index b65dbb5d60bb..0fd785410150 100644 --- a/kernel/futex.c +++ b/kernel/futex.c @@ -1207,11 +1207,11 @@ static int handle_exit_race(u32 __user *uaddr, u32 uval, u32 uval2; /* -* If the futex exit state is not yet FUTEX_STATE_DEAD, wait -* for it to finish. +* If the futex exit state is not yet FUTEX_STATE_DEAD, tell the +* caller that the alleged owner is busy. */ if (tsk && tsk->futex_state != FUTEX_STATE_DEAD) - return -EAGAIN; + return -EBUSY; /* * Reread the user space value to handle the following situation: -- 2.27.0
[PATCH] platform/x86: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
./drivers/platform/x86/ideapad-laptop.c:523:60-61: WARNING opportunity
for kobj_to_dev()
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/platform/x86/ideapad-laptop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/platform/x86/ideapad-laptop.c
b/drivers/platform/x86/ideapad-laptop.c
index 5b81baf..d6ca4f0 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -520,7 +520,7 @@ static umode_t ideapad_is_visible(struct kobject *kobj,
struct attribute *attr,
int idx)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct ideapad_private *priv = dev_get_drvdata(dev);
bool supported;
--
1.8.3.1
Re: [RFC PATCH v5 0/4] add simple copy support
On Fri 19 Feb 2021 at 20:45, SelvaKumar S
wrote:
This patchset tries to add support for TP4065a ("Simple Copy
Command"),
v2020.05.04 ("Ratified")
The Specification can be found in following link.
https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs-1.zip
404 not found.
Should it be
https://nvmexpress.org/wp-content/uploads/NVM-Express-1.4-Ratified-TPs.zip
?
Simple copy command is a copy offloading operation and is used
to copy
multiple contiguous ranges (source_ranges) of LBA's to a single
destination
LBA within the device reducing traffic between host and device.
This implementation doesn't add native copy offload support for
stacked
devices rather copy offload is done through emulation. Possible
use
cases are F2FS gc and BTRFS relocation/balance.
*blkdev_issue_copy* takes source bdev, no of sources, array of
source
ranges (in sectors), destination bdev and destination offset(in
sectors).
If both source and destination block devices are same and
copy_offload = 1,
then copy is done through native copy offloading. Copy emulation
is used
in other cases.
As SCSI XCOPY can take two different block devices and no of
source range is
equal to 1, this interface can be extended in future to support
SCSI XCOPY.
For devices supporting native simple copy, attach the control
information
as payload to the bio and submit to the device. For devices
without native
copy support, copy emulation is done by reading each source
range into memory
and writing it to the destination. Caller can choose not to try
emulation if copy offload is not supported by setting
BLKDEV_COPY_NOEMULATION flag.
Following limits are added to queue limits and are exposed in
sysfs
to userspace
- *copy_offload* controls copy_offload. set 0 to disable copy
offload, 1 to enable native copy offloading support.
- *max_copy_sectors* limits the sum of all source_range length
- *max_copy_nr_ranges* limits the number of source ranges
- *max_copy_range_sectors* limit the maximum number of sectors
that can constitute a single source range.
max_copy_sectors = 0 indicates the device doesn't support copy
offloading.
*copy offload* sysfs entry is configurable and can be used
toggle
between emulation and native support depending upon the usecase.
Changes from v4
1. Extend dm-kcopyd to leverage copy-offload, while copying
within the
same device. The other approach was to have copy-emulation by
moving
dm-kcopyd to block layer. But it also required moving core dm-io
infra,
causing a massive churn across multiple dm-targets.
2. Remove export in bio_map_kern()
3. Change copy_offload sysfs to accept 0 or else
4. Rename copy support flag to QUEUE_FLAG_SIMPLE_COPY
5. Rename payload entries, add source bdev field to be used
while
partition remapping, remove copy_size
6. Change the blkdev_issue_copy() interface to accept
destination and
source values in sector rather in bytes
7. Add payload to bio using bio_map_kern() for copy_offload case
8. Add check to return error if one of the source range length
is 0
9. Add BLKDEV_COPY_NOEMULATION flag to allow user to not try
copy
emulation incase of copy offload is not supported. Caller can
his use
his existing copying logic to complete the io.
10. Bug fix copy checks and reduce size of rcu_lock()
Planned for next:
- adding blktests
- handling larger (than device limits) copy
- decide on ioctl interface (man-page etc.)
Changes from v3
1. gfp_flag fixes.
2. Export bio_map_kern() and use it to allocate and add pages to
bio.
3. Move copy offload, reading to buf, writing from buf to
separate functions.
4. Send read bio of copy offload by chaining them and submit
asynchronously.
5. Add gendisk->part0 and part->bd_start_sect changes to
blk_check_copy().
6. Move single source range limit check to blk_check_copy()
7. Rename __blkdev_issue_copy() to blkdev_issue_copy and remove
old helper.
8. Change blkdev_issue_copy() interface generic to accepts
destination bdev
to support XCOPY as well.
9. Add invalidate_kernel_vmap_range() after reading data for
vmalloc'ed memory.
10. Fix buf allocoation logic to allocate buffer for the total
size of copy.
11. Reword patch commit description.
Changes from v2
1. Add emulation support for devices not supporting copy.
2. Add *copy_offload* sysfs entry to enable and disable
copy_offload
in devices supporting simple copy.
3. Remove simple copy support for stacked devices.
Changes from v1:
1. Fix memory leak in __blkdev_issue_copy
2. Unmark blk_check_copy inline
3. Fix line break in blk_check_copy_eod
4. Remove p checks and made code more readable
5. Don't use bio_set_op_attrs and remove op and set
bi_opf directly
6. Use struct_size to calculate total_size
7. Fix partition remap of copy destination
8. Remove mcl,mssrl,msrc from nvme_ns
9. Initialize copy queue limits to 0 in nvme_config_copy
10. Remove return in
Re: [PATCH] RTIC: selinux: ARM64: Move selinux_state to a separate page
On 2021-02-16 23:39, Nick Desaulniers wrote:
On Tue, Feb 16, 2021 at 2:19 AM Preeti Nagar
wrote:
The changes introduce a new security feature, RunTime Integrity Check
(RTIC), designed to protect Linux Kernel at runtime. The motivation
behind these changes is:
1. The system protection offered by Security Enhancements(SE) for
Android relies on the assumption of kernel integrity. If the kernel
itself is compromised (by a perhaps as yet unknown future
vulnerability),
SE for Android security mechanisms could potentially be disabled and
rendered ineffective.
2. Qualcomm Snapdragon devices use Secure Boot, which adds
cryptographic
checks to each stage of the boot-up process, to assert the
authenticity
of all secure software images that the device executes. However, due
to
various vulnerabilities in SW modules, the integrity of the system can
be
compromised at any time after device boot-up, leading to un-authorized
SW executing.
The feature's idea is to move some sensitive kernel structures to a
separate page and monitor further any unauthorized changes to these,
from higher Exception Levels using stage 2 MMU. Moving these to a
different page will help avoid getting page faults from un-related
data.
The mechanism we have been working on removes the write permissions
for
HLOS in the stage 2 page tables for the regions to be monitored, such
that any modification attempts to these will lead to faults being
generated and handled by handlers. If the protected assets are moved
to
a separate page, faults will be generated corresponding to change
attempts
to these assets only. If not moved to a separate page, write attempts
to
un-related data present on the monitored pages will also be generated.
Using this feature, some sensitive variables of the kernel which are
initialized after init or are updated rarely can also be protected
from
simple overwrites and attacks trying to modify these.
Currently, the change moves selinux_state structure to a separate
page.
The page is 2MB aligned not 4K to avoid TLB related performance impact
as,
for some CPU core designs, the TLB does not cache 4K stage 2 (IPA to
PA)
mappings if the IPA comes from a stage 1 mapping. In future, we plan
to
move more security-related kernel assets to this page to enhance
protection.
Signed-off-by: Preeti Nagar
This addresses my feedback from the RFC regarding the section symbols.
No comment on whether there is a better approach, or the 2MB vs page
alignment, but perhaps other folks cc'ed can please take a look.
Acked-by: Nick Desaulniers
Thank you! I look forward to reviews and suggestions from the added
folks.
---
The RFC patch reviewed available at:
https://lore.kernel.org/linux-security-module/1610099389-28329-1-git-send-email-pna...@codeaurora.org/
---
include/asm-generic/vmlinux.lds.h | 10 ++
include/linux/init.h | 6 ++
security/Kconfig | 11 +++
security/selinux/hooks.c | 2 +-
4 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/include/asm-generic/vmlinux.lds.h
b/include/asm-generic/vmlinux.lds.h
index b97c628..d1a5434 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -770,6 +770,15 @@
*(.scommon)
\
}
+#ifdef CONFIG_SECURITY_RTIC
+#define RTIC_BSS
\
+ . = ALIGN(SZ_2M);
\
+ KEEP(*(.bss.rtic))
\
+ . = ALIGN(SZ_2M);
+#else
+#define RTIC_BSS
+#endif
+
/*
* Allow archectures to redefine BSS_FIRST_SECTIONS to add extra
* sections to the front of bss.
@@ -782,6 +791,7 @@
. = ALIGN(bss_align);
\
.bss : AT(ADDR(.bss) - LOAD_OFFSET) {
\
BSS_FIRST_SECTIONS
\
+ RTIC_BSS
\
. = ALIGN(PAGE_SIZE);
\
*(.bss..page_aligned)
\
. = ALIGN(PAGE_SIZE);
\
diff --git a/include/linux/init.h b/include/linux/init.h
index e668832..e6d452a 100644
--- a/include/linux/init.h
+++ b/include/linux/init.h
@@ -300,6 +300,12 @@ void __init parse_early_options(char *cmdline);
/* Data marked not to be saved by software suspend */
#define __nosavedata __section(".data..nosave")
+#ifdef CONFIG_SECURITY_RTIC
+#define __rticdata __section(".bss.rtic")
+#else
+#define __rticdata
+#endif
+
#ifdef MODULE
#define __exit_p(x) x
#else
diff --git a/security/Kconfig b/security/Kconfig
index 7561f6f..1af913a 100644
--- a/security/Kconfig
+++ b/security/Kconfig
@@ -291,5 +291,16 @@ config LSM
source "security/Kconfig.hardening"
+config SECURITY_RTIC
[PATCH] drm/radeon: A gray screen appears when going into hibernation(S4)
Radeon Card: Caicos[Radeon HD 6450/7450/8450 /R5 230 OEM] there is no gray screen when echo 4>/sys/module/drm/parameters/debug, so the WREG32 function after DRM_DEBUG_KMS may have wrong when going into hibernation.the delay of msleep(50) just can fix gray screen. Signed-off-by: wangjingyu Signed-off-by: zhuyong --- drivers/gpu/drm/radeon/radeon_display.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/radeon/radeon_display.c b/drivers/gpu/drm/radeon/radeon_display.c index ddfe91efa61e..1f7f0904e4a5 100644 --- a/drivers/gpu/drm/radeon/radeon_display.c +++ b/drivers/gpu/drm/radeon/radeon_display.c @@ -215,6 +215,7 @@ void radeon_crtc_load_lut(struct drm_crtc *crtc) if (!crtc->enabled) return; + msleep(50); if (ASIC_IS_DCE5(rdev)) dce5_crtc_load_lut(crtc); else if (ASIC_IS_DCE4(rdev)) -- 2.11.0
[PATCH] scsi: ibmvfc: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
./drivers/scsi/ibmvscsi/ibmvfc.c:3161:60-61: WARNING opportunity for
kobj_to_dev()
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
drivers/scsi/ibmvscsi/ibmvfc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/ibmvscsi/ibmvfc.c b/drivers/scsi/ibmvscsi/ibmvfc.c
index 65f168c..e947149 100644
--- a/drivers/scsi/ibmvscsi/ibmvfc.c
+++ b/drivers/scsi/ibmvscsi/ibmvfc.c
@@ -3158,7 +3158,7 @@ static ssize_t ibmvfc_read_trace(struct file *filp,
struct kobject *kobj,
struct bin_attribute *bin_attr,
char *buf, loff_t off, size_t count)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct Scsi_Host *shost = class_to_shost(dev);
struct ibmvfc_host *vhost = shost_priv(shost);
unsigned long flags = 0;
--
1.8.3.1
Re: [PATCH v2 0/3] Add some perf support for mips
On 02/04/2021 11:35 AM, Tiezhu Yang wrote: v2: add R26 and R27 to the enum perf_event_mips_regs in patch #1 Tiezhu Yang (3): MIPS: kernel: Support extracting off-line stack traces from user-space with perf perf tools: Support mips unwinding and dwarf-regs perf tools: Generate mips syscalls_n64.c syscall table Hi Arnaldo, The kernel part patch #1 has been merged. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1ddc96bd42da Could the perf tool patches #2 and #3 have a chance to be merged before 5.12-rc1? If yes, we can use this feature in 5.12-rc1. https://lore.kernel.org/patchwork/patch/1375476/ https://lore.kernel.org/patchwork/patch/1375475/ Thanks, Tiezhu arch/mips/Kconfig | 2 + arch/mips/include/uapi/asm/perf_regs.h | 40 +++ arch/mips/kernel/Makefile | 2 +- arch/mips/kernel/perf_regs.c | 68 tools/perf/Makefile.config | 9 +- tools/perf/arch/mips/Makefile | 22 ++ tools/perf/arch/mips/entry/syscalls/mksyscalltbl | 32 ++ .../perf/arch/mips/entry/syscalls/syscall_n64.tbl | 358 + tools/perf/arch/mips/include/dwarf-regs-table.h| 31 ++ tools/perf/arch/mips/include/perf_regs.h | 84 + tools/perf/arch/mips/util/Build| 3 + tools/perf/arch/mips/util/dwarf-regs.c | 38 +++ tools/perf/arch/mips/util/perf_regs.c | 6 + tools/perf/arch/mips/util/unwind-libunwind.c | 22 ++ tools/perf/check-headers.sh| 1 + tools/perf/util/dwarf-regs.c | 3 + tools/perf/util/syscalltbl.c | 4 + 17 files changed, 723 insertions(+), 2 deletions(-) create mode 100644 arch/mips/include/uapi/asm/perf_regs.h create mode 100644 arch/mips/kernel/perf_regs.c create mode 100644 tools/perf/arch/mips/Makefile create mode 100644 tools/perf/arch/mips/entry/syscalls/mksyscalltbl create mode 100644 tools/perf/arch/mips/entry/syscalls/syscall_n64.tbl create mode 100644 tools/perf/arch/mips/include/dwarf-regs-table.h create mode 100644 tools/perf/arch/mips/include/perf_regs.h create mode 100644 tools/perf/arch/mips/util/Build create mode 100644 tools/perf/arch/mips/util/dwarf-regs.c create mode 100644 tools/perf/arch/mips/util/perf_regs.c create mode 100644 tools/perf/arch/mips/util/unwind-libunwind.c
[PATCH 4/4] Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU
Add an openssl command option example for generating CodeSign extended key usage in X.509 when CONFIG_CHECK_CODESIGN_EKU is enabled. Signed-off-by: "Lee, Chun-Yi" --- Documentation/admin-guide/module-signing.rst | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/admin-guide/module-signing.rst b/Documentation/admin-guide/module-signing.rst index 7d7c7c8a545c..b57b30c7125f 100644 --- a/Documentation/admin-guide/module-signing.rst +++ b/Documentation/admin-guide/module-signing.rst @@ -170,6 +170,12 @@ generate the public/private key files:: -config x509.genkey -outform PEM -out kernel_key.pem \ -keyout kernel_key.pem +When ``CONFIG_CHECK_CODESIGN_EKU`` option be enabled, the following openssl +command option should be added for generating CodeSign extended key usage in +X.509:: + +-addext "extendedKeyUsage=codeSigning" + The full pathname for the resulting kernel_key.pem file can then be specified in the ``CONFIG_MODULE_SIG_KEY`` option, and the certificate and key therein will be used instead of an autogenerated keypair. -- 2.16.4
[PATCH 3/4] modsign: Add codeSigning EKU when generating X.509 key generation config
Add codeSigning EKU to the X.509 key generation config for the build time autogenerated kernel key. Signed-off-by: "Lee, Chun-Yi" --- certs/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/certs/Makefile b/certs/Makefile index f4c25b67aad9..1ef4d6ca43b7 100644 --- a/certs/Makefile +++ b/certs/Makefile @@ -88,6 +88,7 @@ $(obj)/x509.genkey: @echo >>$@ "keyUsage=digitalSignature" @echo >>$@ "subjectKeyIdentifier=hash" @echo >>$@ "authorityKeyIdentifier=keyid" + @echo >>$@ "extendedKeyUsage=codeSigning" endif # CONFIG_MODULE_SIG_KEY $(eval $(call config_filename,MODULE_SIG_KEY)) -- 2.16.4
[PATCH 2/4] PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification
This patch adds the logic for checking the CodeSigning extended
key usage when verifying signature of kernel module or
kexec PE binary in PKCS#7.
Signed-off-by: "Lee, Chun-Yi"
---
certs/system_keyring.c | 2 +-
crypto/asymmetric_keys/Kconfig | 9 +
crypto/asymmetric_keys/pkcs7_trust.c | 37 +---
include/crypto/pkcs7.h | 3 ++-
4 files changed, 46 insertions(+), 5 deletions(-)
diff --git a/certs/system_keyring.c b/certs/system_keyring.c
index 798291177186..4104f5465d8a 100644
--- a/certs/system_keyring.c
+++ b/certs/system_keyring.c
@@ -242,7 +242,7 @@ int verify_pkcs7_message_sig(const void *data, size_t len,
goto error;
}
}
- ret = pkcs7_validate_trust(pkcs7, trusted_keys);
+ ret = pkcs7_validate_trust(pkcs7, trusted_keys, usage);
if (ret < 0) {
if (ret == -ENOKEY)
pr_devel("PKCS#7 signature not signed with a trusted
key\n");
diff --git a/crypto/asymmetric_keys/Kconfig b/crypto/asymmetric_keys/Kconfig
index 1f1f004dc757..1754812df989 100644
--- a/crypto/asymmetric_keys/Kconfig
+++ b/crypto/asymmetric_keys/Kconfig
@@ -96,4 +96,13 @@ config SIGNED_PE_FILE_VERIFICATION
This option provides support for verifying the signature(s) on a
signed PE binary.
+config CHECK_CODESIGN_EKU
+ bool "Check codeSigning extended key usage"
+ depends on PKCS7_MESSAGE_PARSER=y
+ depends on SYSTEM_DATA_VERIFICATION
+ help
+ This option provides support for checking the codeSigning extended
+ key usage when verifying the signature in PKCS#7. It affects kernel
+ module verification and kexec PE binary verification.
+
endif # ASYMMETRIC_KEY_TYPE
diff --git a/crypto/asymmetric_keys/pkcs7_trust.c
b/crypto/asymmetric_keys/pkcs7_trust.c
index 61af3c4d82cc..1d2318ff63db 100644
--- a/crypto/asymmetric_keys/pkcs7_trust.c
+++ b/crypto/asymmetric_keys/pkcs7_trust.c
@@ -16,12 +16,36 @@
#include
#include "pkcs7_parser.h"
+#ifdef CONFIG_CHECK_CODESIGN_EKU
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+ struct public_key *public_key = key->payload.data[asym_crypto];
+
+ switch (usage) {
+ case VERIFYING_MODULE_SIGNATURE:
+ case VERIFYING_KEXEC_PE_SIGNATURE:
+ return !!(public_key->eku & EKU_codeSigning);
+ default:
+ break;
+ }
+ return true;
+}
+#else
+static bool check_codesign_eku(struct key *key,
+enum key_being_used_for usage)
+{
+ return true;
+}
+#endif
+
/**
* Check the trust on one PKCS#7 SignedInfo block.
*/
static int pkcs7_validate_trust_one(struct pkcs7_message *pkcs7,
struct pkcs7_signed_info *sinfo,
- struct key *trust_keyring)
+ struct key *trust_keyring,
+ enum key_being_used_for usage)
{
struct public_key_signature *sig = sinfo->sig;
struct x509_certificate *x509, *last = NULL, *p;
@@ -112,6 +136,12 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
return -ENOKEY;
matched:
+ if (!check_codesign_eku(key, usage)) {
+ pr_warn("sinfo %u: The signer %x key is not CodeSigning\n",
+ sinfo->index, key_serial(key));
+ key_put(key);
+ return -ENOKEY;
+ }
ret = verify_signature(key, sig);
key_put(key);
if (ret < 0) {
@@ -156,7 +186,8 @@ static int pkcs7_validate_trust_one(struct pkcs7_message
*pkcs7,
* May also return -ENOMEM.
*/
int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
-struct key *trust_keyring)
+struct key *trust_keyring,
+enum key_being_used_for usage)
{
struct pkcs7_signed_info *sinfo;
struct x509_certificate *p;
@@ -167,7 +198,7 @@ int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
p->seen = false;
for (sinfo = pkcs7->signed_infos; sinfo; sinfo = sinfo->next) {
- ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring);
+ ret = pkcs7_validate_trust_one(pkcs7, sinfo, trust_keyring,
usage);
switch (ret) {
case -ENOKEY:
continue;
diff --git a/include/crypto/pkcs7.h b/include/crypto/pkcs7.h
index 38ec7f5f9041..b3b48240ba73 100644
--- a/include/crypto/pkcs7.h
+++ b/include/crypto/pkcs7.h
@@ -30,7 +30,8 @@ extern int pkcs7_get_content_data(const struct pkcs7_message
*pkcs7,
* pkcs7_trust.c
*/
extern int pkcs7_validate_trust(struct pkcs7_message *pkcs7,
- struct key *trust_keyring);
+ struct key *trust_keyring,
+
[PATCH 1/4] X.509: Add CodeSigning extended key usage parsing
This patch adds the logic for parsing the CodeSign extended key usage
extension in X.509. The parsing result will be set to the eku flag
which is carried by public key. It can be used in the PKCS#7
verification.
Signed-off-by: "Lee, Chun-Yi"
---
crypto/asymmetric_keys/x509_cert_parser.c | 24
include/crypto/public_key.h | 1 +
include/linux/oid_registry.h | 5 +
3 files changed, 30 insertions(+)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c
b/crypto/asymmetric_keys/x509_cert_parser.c
index 52c9b455fc7d..65721313b265 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -497,6 +497,8 @@ int x509_process_extension(void *context, size_t hdrlen,
struct x509_parse_context *ctx = context;
struct asymmetric_key_id *kid;
const unsigned char *v = value;
+ int i = 0;
+ enum OID oid;
pr_debug("Extension: %u\n", ctx->last_oid);
@@ -526,6 +528,28 @@ int x509_process_extension(void *context, size_t hdrlen,
return 0;
}
+ if (ctx->last_oid == OID_extKeyUsage) {
+ if (v[0] != ((ASN1_UNIV << 6) | ASN1_CONS_BIT | ASN1_SEQ) ||
+ v[1] != vlen - 2)
+ return -EBADMSG;
+ i += 2;
+
+ while (i < vlen) {
+ /* A 10 bytes EKU OID Octet blob =
+* ASN1_OID + size byte + 8 bytes OID */
+ if (v[i] != ASN1_OID || v[i + 1] != 8 || (i + 10) >
vlen)
+ return -EBADMSG;
+
+ oid = look_up_OID(v + i + 2, v[i + 1]);
+ if (oid == OID_codeSigning) {
+ ctx->cert->pub->eku |= EKU_codeSigning;
+ }
+ i += 10;
+ }
+ pr_debug("extKeyUsage: %d\n", ctx->cert->pub->eku);
+ return 0;
+ }
+
return 0;
}
diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h
index 948c5203ca9c..07a1b28460a2 100644
--- a/include/crypto/public_key.h
+++ b/include/crypto/public_key.h
@@ -29,6 +29,7 @@ struct public_key {
bool key_is_private;
const char *id_type;
const char *pkey_algo;
+ unsigned int eku : 9; /* Extended Key Usage (9-bit) */
};
extern void public_key_free(struct public_key *key);
diff --git a/include/linux/oid_registry.h b/include/linux/oid_registry.h
index 4462ed2c18cd..e20e8eb53b21 100644
--- a/include/linux/oid_registry.h
+++ b/include/linux/oid_registry.h
@@ -113,9 +113,14 @@ enum OID {
OID_SM2_with_SM3, /* 1.2.156.10197.1.501 */
OID_sm3WithRSAEncryption, /* 1.2.156.10197.1.504 */
+ /* Extended key purpose OIDs [RFC 5280] */
+ OID_codeSigning,/* 1.3.6.1.5.5.7.3.3 */
+
OID__NR
};
+#define EKU_codeSigning(1 << 2)
+
extern enum OID look_up_OID(const void *data, size_t datasize);
extern int sprint_oid(const void *, size_t, char *, size_t);
extern int sprint_OID(enum OID, char *, size_t);
--
2.16.4
[PATCH v4 0/4] Check codeSigning extended key usage extension
NIAP PP_OS certification requests that the OS shall validate the CodeSigning extended key usage extension field for integrity verifiction of exectable code: https://www.niap-ccevs.org/MMO/PP/-442-/ FIA_X509_EXT.1.1 This patchset adds the logic for parsing the codeSigning EKU extension field in X.509. And checking the CodeSigning EKU when verifying signature of kernel module or kexec PE binary in PKCS#7. v4: Fixed the wording in patch description. v3: - Add codeSigning EKU to x509.genkey key generation config. - Add openssl command option example for generating CodeSign EKU to module-signing.rst document. v2: Changed the help wording in the Kconfig. Lee, Chun-Yi (4): X.509: Add CodeSigning extended key usage parsing PKCS#7: Check codeSigning EKU for kernel module and kexec pe verification modsign: Add codeSigning EKU when generating X.509 key generation config Documentation/admin-guide/module-signing.rst: add openssl command option example for CodeSign EKU Documentation/admin-guide/module-signing.rst | 6 + certs/Makefile | 1 + certs/system_keyring.c | 2 +- crypto/asymmetric_keys/Kconfig | 9 +++ crypto/asymmetric_keys/pkcs7_trust.c | 37 +--- crypto/asymmetric_keys/x509_cert_parser.c| 24 ++ include/crypto/pkcs7.h | 3 ++- include/crypto/public_key.h | 1 + include/linux/oid_registry.h | 5 9 files changed, 83 insertions(+), 5 deletions(-) -- 2.16.4
Re: [PATCH] staging: ks7010: Replace macros with do while loop.
On Mon, Feb 22, 2021 at 01:43:24AM +0530, chakravarthikulkarni wrote: > This commit fix errors found in checkpath.pl. > Error message is: > > It is a good idea to keep complex macros in do while loop. > Otherwise result may have side effect. > > Signed-off-by: chakravarthikulkarni This breaks the build. Also just ignore this checkpatch warning. The original defines are fine. regards, dan carpenter
drivers/mailbox/arm_mhuv2.c:702 mhuv2_receiver_interrupt() error: 'data' dereferencing possible ERR_PTR()
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 55f62bc873477dae2c45bbbc30b86cf3e0982f3b
commit: 5a6338cce9f4133c478d3b10b300f96dd644379a mailbox: arm_mhuv2: Add driver
config: arm64-randconfig-m031-20210221 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
smatch warnings:
drivers/mailbox/arm_mhuv2.c:702 mhuv2_receiver_interrupt() error: 'data'
dereferencing possible ERR_PTR()
vim +/data +702 drivers/mailbox/arm_mhuv2.c
5a6338cce9f413 Viresh Kumar 2020-11-17 674 static irqreturn_t
mhuv2_receiver_interrupt(int irq, void *arg)
5a6338cce9f413 Viresh Kumar 2020-11-17 675 {
5a6338cce9f413 Viresh Kumar 2020-11-17 676 struct mhuv2 *mhu = arg;
5a6338cce9f413 Viresh Kumar 2020-11-17 677 struct mbox_chan *chan =
get_irq_chan_rx(mhu);
5a6338cce9f413 Viresh Kumar 2020-11-17 678 struct device *dev =
mhu->mbox.dev;
5a6338cce9f413 Viresh Kumar 2020-11-17 679 struct mhuv2_mbox_chan_priv
*priv;
5a6338cce9f413 Viresh Kumar 2020-11-17 680 int ret = IRQ_NONE;
5a6338cce9f413 Viresh Kumar 2020-11-17 681 void *data;
5a6338cce9f413 Viresh Kumar 2020-11-17 682
5a6338cce9f413 Viresh Kumar 2020-11-17 683 if (IS_ERR(chan)) {
5a6338cce9f413 Viresh Kumar 2020-11-17 684 dev_warn(dev, "Failed
to find channel for the rx interrupt\n");
5a6338cce9f413 Viresh Kumar 2020-11-17 685 return IRQ_NONE;
5a6338cce9f413 Viresh Kumar 2020-11-17 686 }
5a6338cce9f413 Viresh Kumar 2020-11-17 687 priv = chan->con_priv;
5a6338cce9f413 Viresh Kumar 2020-11-17 688
5a6338cce9f413 Viresh Kumar 2020-11-17 689 /* Read and clear the data
first */
5a6338cce9f413 Viresh Kumar 2020-11-17 690 data =
priv->ops->read_data(mhu, chan);
5a6338cce9f413 Viresh Kumar 2020-11-17 691
5a6338cce9f413 Viresh Kumar 2020-11-17 692 if (!chan->cl) {
5a6338cce9f413 Viresh Kumar 2020-11-17 693 dev_warn(dev, "Received
data on channel (%u) not currently attached to a mailbox client\n",
5a6338cce9f413 Viresh Kumar 2020-11-17 694
priv->ch_wn_idx);
5a6338cce9f413 Viresh Kumar 2020-11-17 695 } else if (IS_ERR(data)) {
5a6338cce9f413 Viresh Kumar 2020-11-17 696 dev_err(dev, "Failed to
read data: %lu\n", PTR_ERR(data));
"data" is an error pointer.
5a6338cce9f413 Viresh Kumar 2020-11-17 697 } else {
5a6338cce9f413 Viresh Kumar 2020-11-17 698
mbox_chan_received_data(chan, data);
5a6338cce9f413 Viresh Kumar 2020-11-17 699 ret = IRQ_HANDLED;
5a6338cce9f413 Viresh Kumar 2020-11-17 700 }
5a6338cce9f413 Viresh Kumar 2020-11-17 701
5a6338cce9f413 Viresh Kumar 2020-11-17 @702 kfree(data);
^^^
This will crash.
5a6338cce9f413 Viresh Kumar 2020-11-17 703 return ret;
5a6338cce9f413 Viresh Kumar 2020-11-17 704 }
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
[PATCH] mtd: rawnand: qcom: Add helper to check last code word
This change will add helper qcom_nandc_is_last_cw()
which will check for last code word and return true for
last code word and false for other code word.
Signed-off-by: Md Sadre Alam
---
drivers/mtd/nand/raw/qcom_nandc.c | 24 +++-
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/nand/raw/qcom_nandc.c
b/drivers/mtd/nand/raw/qcom_nandc.c
index ae8870ec..4189a7f 100644
--- a/drivers/mtd/nand/raw/qcom_nandc.c
+++ b/drivers/mtd/nand/raw/qcom_nandc.c
@@ -661,6 +661,12 @@ static void nandc_set_reg(struct qcom_nand_controller
*nandc, int offset,
*reg = cpu_to_le32(val);
}
+/* Helper to check the code word, whether it is last cw or not */
+static bool qcom_nandc_is_last_cw(struct nand_ecc_ctrl *ecc, int cw)
+{
+ return cw == (ecc->steps - 1);
+}
+
/* helper to configure address register values */
static void set_address(struct qcom_nand_host *host, u16 column, int page)
{
@@ -1632,7 +1638,7 @@ qcom_nandc_read_cw_raw(struct mtd_info *mtd, struct
nand_chip *chip,
data_size1 = mtd->writesize - host->cw_size * (ecc->steps - 1);
oob_size1 = host->bbm_size;
- if (cw == (ecc->steps - 1)) {
+ if (qcom_nandc_is_last_cw(ecc, cw)) {
data_size2 = ecc->size - data_size1 -
((ecc->steps - 1) * 4);
oob_size2 = (ecc->steps * 4) + host->ecc_bytes_hw +
@@ -1713,7 +1719,7 @@ check_for_erased_page(struct qcom_nand_host *host, u8
*data_buf,
}
for_each_set_bit(cw, _cws, ecc->steps) {
- if (cw == (ecc->steps - 1)) {
+ if (qcom_nandc_is_last_cw(ecc, cw)) {
data_size = ecc->size - ((ecc->steps - 1) * 4);
oob_size = (ecc->steps * 4) + host->ecc_bytes_hw;
} else {
@@ -1773,7 +1779,7 @@ static int parse_read_errors(struct qcom_nand_host *host,
u8 *data_buf,
u32 flash, buffer, erased_cw;
int data_len, oob_len;
- if (i == (ecc->steps - 1)) {
+ if (qcom_nandc_is_last_cw(ecc, i)) {
data_len = ecc->size - ((ecc->steps - 1) << 2);
oob_len = ecc->steps << 2;
} else {
@@ -1872,7 +1878,7 @@ static int read_page_ecc(struct qcom_nand_host *host, u8
*data_buf,
for (i = 0; i < ecc->steps; i++) {
int data_size, oob_size;
- if (i == (ecc->steps - 1)) {
+ if (qcom_nandc_is_last_cw(ecc, i)) {
data_size = ecc->size - ((ecc->steps - 1) << 2);
oob_size = (ecc->steps << 2) + host->ecc_bytes_hw +
host->spare_bytes;
@@ -2051,7 +2057,7 @@ static int qcom_nandc_write_page(struct nand_chip *chip,
const uint8_t *buf,
for (i = 0; i < ecc->steps; i++) {
int data_size, oob_size;
- if (i == (ecc->steps - 1)) {
+ if (qcom_nandc_is_last_cw(ecc, i)) {
data_size = ecc->size - ((ecc->steps - 1) << 2);
oob_size = (ecc->steps << 2) + host->ecc_bytes_hw +
host->spare_bytes;
@@ -2068,10 +2074,10 @@ static int qcom_nandc_write_page(struct nand_chip
*chip, const uint8_t *buf,
* when ECC is enabled, we don't really need to write anything
* to oob for the first n - 1 codewords since these oob regions
* just contain ECC bytes that's written by the controller
-* itself. For the last codeword, we skip the bbm positions and
-* write to the free oob area.
+* itself. For the last codeword, we skip the bbm positions and
write
+* to the free oob area.
*/
- if (i == (ecc->steps - 1)) {
+ if (qcom_nandc_is_last_cw(ecc, i)) {
oob_buf += host->bbm_size;
write_data_dma(nandc, FLASH_BUF_ACC + data_size,
@@ -2126,7 +2132,7 @@ static int qcom_nandc_write_page_raw(struct nand_chip
*chip,
data_size1 = mtd->writesize - host->cw_size * (ecc->steps - 1);
oob_size1 = host->bbm_size;
- if (i == (ecc->steps - 1)) {
+ if (qcom_nandc_is_last_cw(ecc, i)) {
data_size2 = ecc->size - data_size1 -
((ecc->steps - 1) << 2);
oob_size2 = (ecc->steps << 2) + host->ecc_bytes_hw +
--
2.7.4
drivers/clocksource/dw_apb_timer_of.c:66 timer_get_base_and_rate() warn: 'timer_clk' not released on lines: 64.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 55f62bc873477dae2c45bbbc30b86cf3e0982f3b
commit: 5d9814df0aec56a638bbf20795abb4cfaf3cd331
clocksource/drivers/dw_apb_timer_of: Add error handling if no clock available
config: arm64-randconfig-m031-20210221 (attached as .config)
compiler: aarch64-linux-gcc (GCC) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/clocksource/dw_apb_timer_of.c:66 timer_get_base_and_rate() warn:
'timer_clk' not released on lines: 64.
Old smatch warnings:
drivers/clocksource/dw_apb_timer_of.c:66 timer_get_base_and_rate() warn:
'*base' not released on lines: 56,64.
vim +/timer_clk +66 drivers/clocksource/dw_apb_timer_of.c
5d9814df0aec56 drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2020-12-05
17 static int __init timer_get_base_and_rate(struct device_node *np,
af75655c066621 arch/arm/mach-picoxcell/time.cJamie Iles 2011-07-25
18 void __iomem **base, u32 *rate)
af75655c066621 arch/arm/mach-picoxcell/time.cJamie Iles 2011-07-25
19 {
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
20 struct clk *timer_clk;
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
21 struct clk *pclk;
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
22 struct reset_control *rstc;
5d9814df0aec56 drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2020-12-05
23 int ret;
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
24
af75655c066621 arch/arm/mach-picoxcell/time.cJamie Iles 2011-07-25
25 *base = of_iomap(np, 0);
af75655c066621 arch/arm/mach-picoxcell/time.cJamie Iles 2011-07-25
26
af75655c066621 arch/arm/mach-picoxcell/time.cJamie Iles 2011-07-25
27 if (!*base)
2a4849d2674b96 drivers/clocksource/dw_apb_timer_of.c Rob Herring2018-08-27
28 panic("Unable to map regs for %pOFn", np);
af75655c066621 arch/arm/mach-picoxcell/time.cJamie Iles 2011-07-25
29
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
30 /*
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
31 * Reset the timer if the reset control is available, wiping
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
32 * out the state the firmware may have left it
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
33 */
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
34 rstc = of_reset_control_get(np, NULL);
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
35 if (!IS_ERR(rstc)) {
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
36 reset_control_assert(rstc);
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
37 reset_control_deassert(rstc);
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
38 }
1f174a1a2cdebc drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2018-09-17
39
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
40 /*
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
41 * Not all implementations use a periphal clock, so don't panic
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
42 * if it's not present
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
43 */
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
44 pclk = of_clk_get_by_name(np, "pclk");
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
45 if (!IS_ERR(pclk))
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
46 if (clk_prepare_enable(pclk))
2a4849d2674b96 drivers/clocksource/dw_apb_timer_of.c Rob Herring2018-08-27
47 pr_warn("pclk for %pOFn is present, but could not be
activated\n",
2a4849d2674b96 drivers/clocksource/dw_apb_timer_of.c Rob Herring2018-08-27
48 np);
a8b447f2a7 drivers/clocksource/dw_apb_timer_of.c Heiko Stuebner 2013-06-04
49
5d9814df0aec56 drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2020-12-05
50 if (!of_property_read_u32(np, "clock-freq", rate) &&
5d9814df0aec56 drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen2020-12-05
51 !of_property_read_u32(np, "clock-frequency", rate))
5d9814df0aec56 drivers/clocksource/dw_apb_timer_of.c Dinh Nguyen202
RE: [PATCH net] r8152: move r8153_mac_clk_spd
Jakub Kicinski > Sent: Saturday, February 20, 2021 2:23 AM [...] > Any word on what user-visible misbehavior this causes? I think it influences the power saving for suspending. I am checking it with our engineers. > Can you provide a Fixes tag? Yes. I will add it when I updating this patch. Best Regards, Hayes
Re: [PATCH V4 0/3] scripts: dtc: Build fdtoverlay
On Thu, Feb 04, 2021 at 08:25:23AM -0600, Rob Herring wrote: > On Sun, Jan 31, 2021 at 10:39 PM David Gibson > wrote: > > > > On Mon, Jan 25, 2021 at 09:42:21PM -0600, Frank Rowand wrote: > > > Hi David, > > > > > > On 1/22/21 12:34 AM, David Gibson wrote: > > > > On Wed, Jan 20, 2021 at 10:47:40AM +0530, Viresh Kumar wrote: > > > >> +David. > > > >> > > > >> On 19-01-21, 11:12, Frank Rowand wrote: > > > >>> On 1/12/21 2:28 AM, Viresh Kumar wrote: > > > We will start building overlays for platforms soon in the kernel and > > > would need fdtoverlay tool going forward. Lets start fetching and > > > building it. > > > > > > While at it, also remove fdtdump.c file, which isn't used by the > > > kernel. > > > > > > V4: > > > - Don't fetch and build fdtdump.c > > > - Remove fdtdump.c > > > > > > Viresh Kumar (3): > > > scripts: dtc: Add fdtoverlay.c to DTC_SOURCE > > > scripts: dtc: Build fdtoverlay tool > > > scripts: dtc: Remove the unused fdtdump.c file > > > > > > scripts/dtc/Makefile | 6 +- > > > scripts/dtc/fdtdump.c| 163 > > > --- > > > scripts/dtc/update-dtc-source.sh | 6 +- > > > 3 files changed, 8 insertions(+), 167 deletions(-) > > > delete mode 100644 scripts/dtc/fdtdump.c > > > > > > >>> > > > >>> My first inclination was to accept fdtoverlay, as is, from the > > > >>> upstream > > > >>> project. > > > >>> > > > >>> But my experiences debugging use of fdtoverlay against the existing > > > >>> unittest overlay files has me very wary of accepting fdtoverlay in > > > >>> it's current form. > > > >>> > > > >>> As an exmple, adding an overlay that fails to reply results in the > > > >>> following build messages: > > > >>> > > > >>>linux--5.11-rc> make zImage > > > >>>make[1]: Entering directory > > > >>> '/local/frowand_nobackup/src/git_linus/build/dragon_linus_5.11-rc' > > > >>> GEN Makefile > > > >>> CALL > > > >>> /local/frowand_nobackup/src/git_linus/linux--5.11-rc/scripts/checksyscalls.sh > > > >>> CALL > > > >>> /local/frowand_nobackup/src/git_linus/linux--5.11-rc/scripts/atomic/check-atomics.sh > > > >>> CHK include/generated/compile.h > > > >>> FDTOVERLAY drivers/of/unittest-data/static_test.dtb > > > >>> > > > >>>Failed to apply 'drivers/of/unittest-data/overlay.dtb': > > > >>> FDT_ERR_NOTFOUND > > > >>>make[4]: *** > > > >>> [/local/frowand_nobackup/src/git_linus/linux--5.11-rc/drivers/of/unittest-data/Makefile:96: > > > >>> drivers/of/unittest-data/static_test.dtb] Error 1 > > > >>>make[3]: *** > > > >>> [/local/frowand_nobackup/src/git_linus/linux--5.11-rc/scripts/Makefile.build:496: > > > >>> drivers/of/unittest-data] Error 2 > > > >>>make[2]: *** > > > >>> [/local/frowand_nobackup/src/git_linus/linux--5.11-rc/scripts/Makefile.build:496: > > > >>> drivers/of] Error 2 > > > >>>make[1]: *** > > > >>> [/local/frowand_nobackup/src/git_linus/linux--5.11-rc/Makefile:1805: > > > >>> drivers] Error 2 > > > >>>make[1]: Leaving directory > > > >>> '/local/frowand_nobackup/src/git_linus/build/dragon_linus_5.11-rc' > > > >>>make: *** [Makefile:185: __sub-make] Error 2 > > > >>> > > > >>> > > > >>> The specific error message (copied from above) is: > > > >>> > > > >>>Failed to apply 'drivers/of/unittest-data/overlay.dtb': > > > >>> FDT_ERR_NOTFOUND > > > >>> > > > >>> which is cryptic and does not even point to the location in the > > > >>> overlay that > > > >>> is problematic. If you look at the source of fdtoverlay / libfdt, > > > >>> you will > > > >>> find that FDT_ERR_NOTFOUND may be generated in one of many places. > > > >>> > > > >>> I do _not_ want to do a full review of fdtoverlay, but I think that > > > >>> it is > > > >>> reasonable to request enhancing fdtoverlay in the parent project to > > > >>> generate > > > >>> usable error messages before enabling fdtoverlay in the Linux kernel > > > >>> tree. > > > > > > > > > > > That's... actually much harder than it sounds. fdtoverlay is > > > > basically a trivial wrapper around the fdt_overlay_apply() function in > > > > libfdt. Matching the conventions of the rest of the library, really > > > > it's only way to report errors is a single error code. > > > > > > > > Returning richer errors is not an easy problem in a C library, > > > > especially one designed to be usable in embedded systems, without an > > > > allocator or much else available. > > > > > > > > Of course it would be possible to write a friendly command line tool > > > > specifically for applying overlays, which could give better errors. > > > > fdtoverlay as it stands isn't really that - it was pretty much written > > > > just to invoke fdt_overlay_apply() in testcases. > > > > > > Thank you for providing that context. > > > > > > I do not know if there is a way to enable the code that is currently
Re: [PATCH v2] staging: wimax: Fix block comment style issue in stack.c
On Sun, Feb 21, 2021 at 10:07:59PM +0530, Amrit Khera wrote:
> diff --git a/drivers/staging/wimax/stack.c b/drivers/staging/wimax/stack.c
> index ace24a6dfd2d..345a022810ef 100644
> --- a/drivers/staging/wimax/stack.c
> +++ b/drivers/staging/wimax/stack.c
> @@ -57,17 +57,7 @@ MODULE_PARM_DESC(debug,
>
> /*
> * Authoritative source for the RE_STATE_CHANGE attribute policy
Delete the whole comment. This sentence doesn't make any sense by
itself once we have removed the rest.
> - *
> - * We don't really use it here, but /me likes to keep the definition
> - * close to where the data is generated.
> */
> -/*
> -static const struct nla_policy wimax_gnl_re_status_change[WIMAX_GNL_ATTR_MAX
> + 1] = {
> - [WIMAX_GNL_STCH_STATE_OLD] = { .type = NLA_U8 },
> - [WIMAX_GNL_STCH_STATE_NEW] = { .type = NLA_U8 },
> -};
regards,
dan carpenter
(.text.ks8851_probe_common+0x370): undefined reference to `__this_module'
Hi Marek, FYI, the error/warning still remains. tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master head: 31caf8b2a847214be856f843e251fc2ed2cd1075 commit: ef3631220d2b3d8d14cf64464760505baa60d6ac net: ks8851: Register MDIO bus and the internal PHY date: 7 weeks ago config: parisc-randconfig-r034-20210222 (attached as .config) compiler: hppa-linux-gcc (GCC) 9.3.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ef3631220d2b3d8d14cf64464760505baa60d6ac git remote add linus https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git git fetch --no-tags linus master git checkout ef3631220d2b3d8d14cf64464760505baa60d6ac # save the attached .config to linux build tree COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=parisc If you fix the issue, kindly add following tag as appropriate Reported-by: kernel test robot All errors (new ones prefixed by >>): hppa-linux-ld: drivers/net/ethernet/micrel/ks8851_common.o: in function `ks8851_probe_common': >> (.text.ks8851_probe_common+0x370): undefined reference to `__this_module' >> hppa-linux-ld: (.text.ks8851_probe_common+0x374): undefined reference to >> `__this_module' --- 0-DAY CI Kernel Test Service, Intel Corporation https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org .config.gz Description: application/gzip
[PATCH] ndtest: Switch to using the new API kobj_to_dev()
fixed the following coccicheck:
./tools/testing/nvdimm/test/ndtest.c:785:60-61: WARNING opportunity for
kobj_to_dev()
Reported-by: Abaci Robot
Signed-off-by: Yang Li
---
tools/testing/nvdimm/test/ndtest.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/nvdimm/test/ndtest.c
b/tools/testing/nvdimm/test/ndtest.c
index 6862915..004a36f 100644
--- a/tools/testing/nvdimm/test/ndtest.c
+++ b/tools/testing/nvdimm/test/ndtest.c
@@ -782,7 +782,7 @@ static ssize_t format1_show(struct device *dev, struct
device_attribute *attr,
static umode_t ndtest_nvdimm_attr_visible(struct kobject *kobj,
struct attribute *a, int n)
{
- struct device *dev = container_of(kobj, struct device, kobj);
+ struct device *dev = kobj_to_dev(kobj);
struct nvdimm *nvdimm = to_nvdimm(dev);
struct ndtest_dimm *dimm = nvdimm_provider_data(nvdimm);
--
1.8.3.1
[PATCH] thermal: amlogic: Omit superfluous error message in amlogic_thermal_probe()
The function devm_platform_ioremap_resource has already contains error
message, so remove the redundant dev_err here.
Signed-off-by: Tang Bin
---
drivers/thermal/amlogic_thermal.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/thermal/amlogic_thermal.c
b/drivers/thermal/amlogic_thermal.c
index ccb1fe18e..bba9f3b14 100644
--- a/drivers/thermal/amlogic_thermal.c
+++ b/drivers/thermal/amlogic_thermal.c
@@ -253,10 +253,8 @@ static int amlogic_thermal_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, pdata);
base = devm_platform_ioremap_resource(pdev, 0);
- if (IS_ERR(base)) {
- dev_err(dev, "failed to get io address\n");
+ if (IS_ERR(base))
return PTR_ERR(base);
- }
pdata->regmap = devm_regmap_init_mmio(dev, base,
pdata->data->regmap_config);
--
2.20.1.windows.1
Re: [PATCH] vdpa/mlx5: set_features should allow reset to zero
On Sun, Feb 21, 2021 at 04:52:05PM -0500, Michael S. Tsirkin wrote:
> On Sun, Feb 21, 2021 at 04:44:37PM +0200, Eli Cohen wrote:
> > On Fri, Feb 19, 2021 at 06:54:58AM -0500, Si-Wei Liu wrote:
> > > Commit 452639a64ad8 ("vdpa: make sure set_features is invoked
> > > for legacy") made an exception for legacy guests to reset
> > > features to 0, when config space is accessed before features
> > > are set. We should relieve the verify_min_features() check
> > > and allow features reset to 0 for this case.
> > >
> > > It's worth noting that not just legacy guests could access
> > > config space before features are set. For instance, when
> > > feature VIRTIO_NET_F_MTU is advertised some modern driver
> > > will try to access and validate the MTU present in the config
> > > space before virtio features are set. Rejecting reset to 0
> > > prematurely causes correct MTU and link status unable to load
> > > for the very first config space access, rendering issues like
> > > guest showing inaccurate MTU value, or failure to reject
> > > out-of-range MTU.
> > >
> > > Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5
> > > devices")
> > > Signed-off-by: Si-Wei Liu
> > > ---
> > > drivers/vdpa/mlx5/net/mlx5_vnet.c | 15 +--
> > > 1 file changed, 1 insertion(+), 14 deletions(-)
> > >
> > > diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > index 7c1f789..540dd67 100644
> > > --- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > +++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
> > > @@ -1490,14 +1490,6 @@ static u64 mlx5_vdpa_get_features(struct
> > > vdpa_device *vdev)
> > > return mvdev->mlx_features;
> > > }
> > >
> > > -static int verify_min_features(struct mlx5_vdpa_dev *mvdev, u64 features)
> > > -{
> > > - if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
> > > - return -EOPNOTSUPP;
> > > -
> > > - return 0;
> > > -}
> > > -
> >
> > But what if VIRTIO_F_ACCESS_PLATFORM is not offerred? This does not
> > support such cases.
>
> Did you mean "catch such cases" rather than "support"?
>
Actually I meant this driver/device does not support such cases.
>
> > Maybe we should call verify_min_features() from mlx5_vdpa_set_status()
> > just before attempting to call setup_driver().
> >
> > > static int setup_virtqueues(struct mlx5_vdpa_net *ndev)
> > > {
> > > int err;
> > > @@ -1558,18 +1550,13 @@ static int mlx5_vdpa_set_features(struct
> > > vdpa_device *vdev, u64 features)
> > > {
> > > struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
> > > struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
> > > - int err;
> > >
> > > print_features(mvdev, features, true);
> > >
> > > - err = verify_min_features(mvdev, features);
> > > - if (err)
> > > - return err;
> > > -
> > > ndev->mvdev.actual_features = features & ndev->mvdev.mlx_features;
> > > ndev->config.mtu = cpu_to_mlx5vdpa16(mvdev, ndev->mtu);
> > > ndev->config.status |= cpu_to_mlx5vdpa16(mvdev, VIRTIO_NET_S_LINK_UP);
> > > - return err;
> > > + return 0;
> > > }
> > >
> > > static void mlx5_vdpa_set_config_cb(struct vdpa_device *vdev, struct
> > > vdpa_callback *cb)
> > > --
> > > 1.8.3.1
> > >
>
Re: [PATCH 2/2] usb: gadget: s3c: Fix the error handling path in 's3c2410_udc_probe()'
On Sun, Feb 21, 2021 at 08:41:33AM +0100, Christophe JAILLET wrote:
> Some 'clk_prepare_enable()' and 'clk_get()' must be undone in the error
> handling path of the probe function, as already done in the remove
> function.
>
> Fixes: 1c6d47aa4f4b ("USB Gadget driver for Samsung s3c2410 ARM SoC")
> Signed-off-by: Christophe JAILLET
> ---
> checkpatch reports:
> WARNING: Unknown commit id '1c6d47aa4f4b', maybe rebased or not pulled?
> According to
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/usb/gadget/s3c2410_udc.c?id=3fc154b6b8134b98bb94d60cad9a46ec1ffbe372
> the commit ID looks correct to me. Maybe something should be tweaked somewhere
> before applying, but I don't know what!
Same thing. The hash is 3fc154b6b8134b98bb94d60cad9a46ec1ffbe372
regards,
dan carpenter
Re: [PATCH 1/2] usb: gadget: s3c: Fix incorrect resources releasing
On Sun, Feb 21, 2021 at 08:41:17AM +0100, Christophe JAILLET wrote:
> Since commit fe0f8e5c9ba8 ("usb: gadget: s3c: use platform resources"),
This the wrong hash. It should be 188db4435ac6 from the URL you posted
below.
regards,
dan carpenter
Re: [PATCH] staging: wimax: fix sparse incorrect type issue
On Mon, Feb 22, 2021 at 11:10 AM Dan Carpenter wrote: > > On Sat, Feb 20, 2021 at 05:04:00PM +0530, karthik alapati wrote: > > fix sparse warning by casting to explicit user address-space > > pointer type > > > > Signed-off-by: karthik alapati > > --- > > drivers/staging/wlan-ng/p80211netdev.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/staging/wlan-ng/p80211netdev.c > > b/drivers/staging/wlan-ng/p80211netdev.c > > index 6f9666dc0..70570e8a5 100644 > > --- a/drivers/staging/wlan-ng/p80211netdev.c > > +++ b/drivers/staging/wlan-ng/p80211netdev.c > > @@ -569,7 +569,7 @@ static int p80211knetdev_do_ioctl(struct net_device > > *dev, > > goto bail; > > } > > > > - msgbuf = memdup_user(req->data, req->len); > > + msgbuf = memdup_user((void __user *)req->data, req->len); > > This doesn't fix anything it just silences the warning. Linus Torvalds > worked very hard to create Sparse for the express purpose of printing > the warning. People don't realize that warnings are very valuable > because they show where the bugs are. > > Please look at this some more and figure out how to fix the warning. > > To be honest, I'm tempted to not accept any patch which doesn't also fix > the buffer overflows when we pass: > > result = p80211req_dorequest(wlandev, msgbuf); > > How do we know that "msgbuf" is large enough? > > regards, > dan carpenter > Thanks dan but right after sending this patch i immediately replied to it stating to ignore this patch as i found this already applied in staging-testing branch https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git/commit/?h=staging-testing=3a8a144d2a754df45127c74e273fa166f690ba43
[PATCH v2] virtio-mmio: Use to_virtio_mmio_device() to simply code
The file virtio_mmio.c has defined the function to_virtio_mmio_device,
so use it instead of container_of() to simply code.
Signed-off-by: Tang Bin
---
Changes from v1
- Separate the patch with style changes.
---
drivers/virtio/virtio_mmio.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 627ac0487..e530591cd 100644
--- a/drivers/virtio/virtio_mmio.c
+++ b/drivers/virtio/virtio_mmio.c
@@ -517,8 +517,7 @@ static void virtio_mmio_release_dev(struct device *_d)
{
struct virtio_device *vdev =
container_of(_d, struct virtio_device, dev);
- struct virtio_mmio_device *vm_dev =
- container_of(vdev, struct virtio_mmio_device, vdev);
+ struct virtio_mmio_device *vm_dev = to_virtio_mmio_device(vdev);
struct platform_device *pdev = vm_dev->pdev;
devm_kfree(>dev, vm_dev);
--
2.20.1.windows.1
Re: [PATCH] xhci-pci: Set AMD Renoir USB controller to D3 when shutdown
On Fri, Feb 19, 2021 at 4:07 PM Aaron Ma wrote: > > > > On 2/11/21 8:50 PM, Greg Kroah-Hartman wrote: > > On Wed, Feb 10, 2021 at 03:13:30PM +0200, Mathias Nyman wrote: > >> On 9.2.2021 10.37, Greg Kroah-Hartman wrote: > >>> On Fri, Feb 05, 2021 at 02:50:15PM +0800, Kai-Heng Feng wrote: > On Fri, Feb 5, 2021 at 2:45 PM Aaron Ma wrote: > > > > > > On 2/5/21 12:27 PM, Kai-Heng Feng wrote: > >> Can you please test the following patch, which should address the root > >> cause: > >> https://lore.kernel.org/linux-acpi/20201201213019.1558738-1-furq...@google.com/ > >> > >> It also helps another AMD laptop on S5: > >> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1912935 > >> > > > > No, this patch doesn't help on ThinkPad AMD platform. > > Thanks for the confirmation! > > Acked-by: Kai-Heng Feng > >>> > >>> Mathias, want me to take this in my tree now, or are you going to send > >>> me more patches for 5.12-rc1? > >>> > >> > >> Nothing more for 5.12-rc1 from me. > >> > >> Could this be a PCI quirk instead of xhci? > >> Maybe there is some PCI flag for this already, haven't checked yet. > >> > >> We want a specific PCI device to go to PCI D3cold at PCI shutdown... > > > > There probably is. Kay-Heng, can you look into doing that instead? > > > > There is no such PCI quirk, usually it calls driver to shutdown. Let me work on it. There are other devices need to be in D3 for shutdown, a generic approach across all devices will be better. Kai-Heng > > Regards, > Aaron > > > thanks, > > > > greg k-h > >
Re: [PATCH v3 5/7] drm: bridge: Queue the bridge chain instead of stacking
Hi Jagan,
Thank you for the patch.
On Mon, Feb 15, 2021 at 01:11:00AM +0530, Jagan Teki wrote:
> drm_bridge_attach has stacked the bridge chain, so the bridge
> that gets pushed last can trigger its bridge function pre_enable
> first from drm_atomic_bridge_chain_pre_enable.
>
> This indeed gives a chance to trigger slave bridge pre_enable
> first without triggering its host bridge pre_enable for the
> usual host to slave device model like DSI host with panel slave.
>
> For fully enabled bridge drivers, host bridge pre_enable has all
> host related clock, reset, PHY configuration code that needs to
> initialized before sending commands or configuration from a slave
> to communicate its host.
>
> Queue the bridge chain instead of stacking it so-that the bridges
> that got enqueued first can have a chance to trigger first.
First of all, won't thus break all the drivers that currently rely on
the existing behaviour ?
> Cc: Maarten Lankhorst
> Cc: Thomas Zimmermann
> Signed-off-by: Jagan Teki
> ---
> Changes for v3:
> - new patch
>
> drivers/gpu/drm/drm_bridge.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 64f0effb52ac..e75d1a080c55 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -191,9 +191,9 @@ int drm_bridge_attach(struct drm_encoder *encoder, struct
> drm_bridge *bridge,
> bridge->encoder = encoder;
>
> if (previous)
> - list_add(>chain_node, >chain_node);
> + list_add_tail(>chain_node, >chain_node);
> else
> - list_add(>chain_node, >bridge_chain);
> + list_add_tail(>chain_node, >bridge_chain);
Then, this will create a really weird order, as the list will contain
bridges in the reverse order. Assuming three bridges, A, B and C, which
are connected at the hardware level as follows:
Encoder -> A -> B -> C
the list would contain
Encoder -> C -> B -> A
This isn't intuitive, and if you want to reverse the order in which
bridge operations are called, it would be better to do so in the
operations themselves, for instance replacing
list_for_each_entry_reverse() with list_for_each_entry() in
drm_atomic_bridge_chain_pre_enable(). Still, this will likely break
drivers that depend on the existing order, so I don't think that's an
acceptable solution as-is.
>
> if (bridge->funcs->attach) {
> ret = bridge->funcs->attach(bridge, flags);
--
Regards,
Laurent Pinchart
Re: [RFC PATCH v2 2/3] usb: xhci-mtk: modify the SOF/ITP interval for mt8195
On Mon, 2021-02-08 at 13:43 +0200, Mathias Nyman wrote:
> On 7.2.2021 4.27, Chunfeng Yun wrote:
> > Hi Mathias,
> >
> > On Wed, 2021-02-03 at 18:26 +0800, Chunfeng Yun wrote:
> >> There are 4 USB controllers on MT8195, the controllers (IP1~IP3,
> >> exclude IP0) have a wrong default SOF/ITP interval which is
> >> calculated from the frame counter clock 24Mhz by default, but
> >> in fact, the frame counter clock is 48Mhz, so we should set
> >> the accurate interval according to 48Mhz for those controllers.
> >> Note: the first controller no need set it.
> >>
> >> Signed-off-by: Chunfeng Yun
> >> ---
> >> v2: fix typo of comaptible
> >> ---
> >> drivers/usb/host/xhci-mtk.c | 63 +
> >> 1 file changed, 63 insertions(+)
> >>
> >> diff --git a/drivers/usb/host/xhci-mtk.c b/drivers/usb/host/xhci-mtk.c
> >> index 8f321f39ab96..0a68c4ac8b48 100644
> >> --- a/drivers/usb/host/xhci-mtk.c
> >> +++ b/drivers/usb/host/xhci-mtk.c
> >> @@ -68,11 +68,71 @@
> >> #define SSC_IP_SLEEP_EN BIT(4)
> >> #define SSC_SPM_INT_ENBIT(1)
> >>
> > Can I Read/Write the following xHCI controller's registers in
> > xhci-mtk.c?
> >
> > Ideally, xhci-mtk.c should not access them, because xhci-mtk is only a
> > glue driver used to initialize clocks/power and IPPC registers which
> > don't belong to xHCI controller.
> >
>
> These *_EOF registers look like they are Mediatek vendor specific registers
> and not part of public xHCI register-level spec.
> So I think accessing them from xhci-mtk.c makes sense.
>
> If those register offsets are hardcoded like this in the Mediatek spec then
> this is fine,
Check it with our DE, it's this case.
> but if those offsets are found from a vendor specific xHCI
> extended capability entry (see xhci spec section 7) then we should dig them
> out
> from there.
> >> +/* xHCI csr */
> >> +#define LS_EOF0x930
> >> +#define LS_EOF_OFFSET 0x89
> >> +
> >> +#define FS_EOF0x934
> >> +#define FS_EOF_OFFSET 0x2e
> >> +
> >> +#define SS_GEN1_EOF 0x93c
> >> +#define SS_GEN1_EOF_OFFSET0x78
> >> +
> >> +#define HFCNTR_CFG0x944
> >> +#define ITP_DELTA_CLK (0xa << 1)
> >> +#define ITP_DELTA_CLK_MASKGENMASK(5, 1)
> >> +#define FRMCNT_LEV1_RANG (0x12b << 8)
> >> +#define FRMCNT_LEV1_RANG_MASK GENMASK(19, 8)
> >> +
> >> +#define SS_GEN2_EOF 0x990
> >> +#define SS_GEN2_EOF_OFFSET0x3c
> >> +#define EOF_OFFSET_MASK GENMASK(11, 0)
> >> +
> >> enum ssusb_uwk_vers {
> >>SSUSB_UWK_V1 = 1,
> >>SSUSB_UWK_V2,
> >> };
> >>
> >> +/*
> >> + * MT8195 has 4 controllers, the controller1~3's default SOF/ITP interval
> >> + * is calculated from the frame counter clock 24M, but in fact, the clock
> >> + * is 48M, so need change the interval.
> >> + */
> >> +static void xhci_mtk_set_frame_interval(struct xhci_hcd_mtk *mtk)
> >> +{
> >> + struct device *dev = mtk->dev;
> >> + struct usb_hcd *hcd = mtk->hcd;
> >> + u32 value;
> >> +
> >> + if (!of_device_is_compatible(dev->of_node, "mediatek,mt8195-xhci"))
> >> + return;
> >> +
> >> + value = readl(hcd->regs + HFCNTR_CFG);
> >> + value &= ~(ITP_DELTA_CLK_MASK | FRMCNT_LEV1_RANG_MASK);
> >> + value |= (ITP_DELTA_CLK | FRMCNT_LEV1_RANG);
> >> + writel(value, hcd->regs + HFCNTR_CFG);
> >> +
> >> + value = readl(hcd->regs + LS_EOF);
> >> + value &= ~EOF_OFFSET_MASK;
> >> + value |= LS_EOF_OFFSET;
> >> + writel(value, hcd->regs + LS_EOF);
> >> +
> >> + value = readl(hcd->regs + FS_EOF);
> >> + value &= ~EOF_OFFSET_MASK;
> >> + value |= FS_EOF_OFFSET;
> >> + writel(value, hcd->regs + FS_EOF);
> >> +
> >> + value = readl(hcd->regs + SS_GEN1_EOF);
> >> + value &= ~EOF_OFFSET_MASK;
> >> + value |= SS_GEN1_EOF_OFFSET;
> >> + writel(value, hcd->regs + SS_GEN1_EOF);
> >> +
> >> + value = readl(hcd->regs + SS_GEN2_EOF);
> >> + value &= ~EOF_OFFSET_MASK;
> >> + value |= SS_GEN2_EOF_OFFSET;
> >> + writel(value, hcd->regs + SS_GEN2_EOF);
>
> Minor nit about names,
> Register offsets from MMIO start are named *_EOF while clock multipliers? are
> named *_EOF_OFFSET.
> This was a bit confusing
Good point, the names come from register map docs, I'll modify it,
thanks a lot
>
> Thanks
> -Mathias
Re: [PATCH] staging: wimax/i2400m: fix byte-order issue
On Sat, Feb 20, 2021 at 05:56:47PM +0530, karthik alapati wrote: > fix sparse byte-order warnings by converting host byte-order > types to le32 types > > Signed-off-by: karthik alapati This is a v2 patch... regards, dan carpenter
Re: [PATCH] staging: wimax: fix sparse incorrect type issue
On Sat, Feb 20, 2021 at 05:04:00PM +0530, karthik alapati wrote: > fix sparse warning by casting to explicit user address-space > pointer type > > Signed-off-by: karthik alapati > --- > drivers/staging/wlan-ng/p80211netdev.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/wlan-ng/p80211netdev.c > b/drivers/staging/wlan-ng/p80211netdev.c > index 6f9666dc0..70570e8a5 100644 > --- a/drivers/staging/wlan-ng/p80211netdev.c > +++ b/drivers/staging/wlan-ng/p80211netdev.c > @@ -569,7 +569,7 @@ static int p80211knetdev_do_ioctl(struct net_device *dev, > goto bail; > } > > - msgbuf = memdup_user(req->data, req->len); > + msgbuf = memdup_user((void __user *)req->data, req->len); This doesn't fix anything it just silences the warning. Linus Torvalds worked very hard to create Sparse for the express purpose of printing the warning. People don't realize that warnings are very valuable because they show where the bugs are. Please look at this some more and figure out how to fix the warning. To be honest, I'm tempted to not accept any patch which doesn't also fix the buffer overflows when we pass: result = p80211req_dorequest(wlandev, msgbuf); How do we know that "msgbuf" is large enough? regards, dan carpenter
Re: [PATCH] riscv: Get rid of MAX_EARLY_MAPPING_SIZE
Hi Dmitry, Le 2/21/21 à 10:38 AM, Dmitry Vyukov a écrit : On Sun, Feb 21, 2021 at 3:22 PM Alexandre Ghiti wrote: At early boot stage, we have a whole PGDIR to map the kernel, so there is no need to restrict the early mapping size to 128MB. Removing this define also allows us to simplify some compile time logic. This fixes large kernel mappings with a size greater than 128MB, as it is the case for syzbot kernels whose size was just ~130MB. Note that on rv64, for now, we are then limited to PGDIR size for early mapping as we can't use PGD mappings (see [1]). That should be enough given the relative small size of syzbot kernels compared to PGDIR_SIZE which is 1GB. [1] https://lore.kernel.org/lkml/20200603153608.30056-1-a...@ghiti.fr/ I've applied this patch to (as it contains the HEAD fix): commit f49815047c1a3e3644a0ba38f3825c5cde8a0922 (HEAD, riscv/for-next) Author: Tobias Klauser Date: Tue Feb 16 18:33:05 2021 +0100 riscv: Disable KSAN_SANITIZE for vDSO and the kernel started booting with my large config. It quickly crashed (see below), but at least it started booting, so it's an improvement. Tested-by: Dmitry Vyukov Thanks for that. Linux version 5.11.0-rc2-00069-gf49815047c1a-dirty (dvyu...@dvyukov-desk.muc.corp.google.com) (riscv64-linux-gnu-gcc (Debian 10.2.1-6+build1) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #34 SMP PREEMPT Sun Feb 21 15:51:40 CET 2021 OF: fdt: Ignoring memory range 0x8000 - 0x8020 Machine model: riscv-virtio,qemu earlycon: ns16550a0 at MMIO 0x1000 (options '') printk: bootconsole [ns16550a0] enabled efi: UEFI not found. cma: Reserved 16 MiB at 0xfec0 Zone ranges: DMA32[mem 0x8020-0x] Normal empty Movable zone start for each node Early memory node ranges node 0: [mem 0x8020-0x] Zeroed struct page in unavailable ranges: 512 pages Initmem setup node 0 [mem 0x8020-0x] SBI specification v0.2 detected SBI implementation ID=0x1 Version=0x8 SBI v0.2 TIME extension detected SBI v0.2 IPI extension detected SBI v0.2 RFENCE extension detected software IO TLB: mapped [mem 0xf7c0-0xfbc0] (64MB) [ cut here ] DEBUG_LOCKS_WARN_ON(early_boot_irqs_disabled) WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:4085 lockdep_hardirqs_on_prepare+0x384/0x388 kernel/locking/lockdep.c:4085 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0-rc2-00069-gf49815047c1a-dirty #34 Hardware name: riscv-virtio,qemu (DT) epc : lockdep_hardirqs_on_prepare+0x384/0x388 kernel/locking/lockdep.c:4085 ra : lockdep_hardirqs_on_prepare+0x384/0x388 kernel/locking/lockdep.c:4085 epc : ffec125a ra : ffec125a sp : ffe006603ce0 gp : ffe006c338f0 tp : ffe006689e00 t0 : ffe00669a9a8 t1 : ffc400cc0738 t2 : s0 : ffe006603d20 s1 : ffe006689e00 a0 : 002d a1 : 000f a2 : 0002 a3 : ffed2718 a4 : a5 : a6 : 00f0 a7 : ffe0066039c7 s2 : ffe004a337c0 s3 : ffe0076fa1b8 s4 : s5 : ffe006689e00 s6 : 0001 s7 : ffe07fcfc000 s8 : ffe07fcfd000 s9 : ffe006c3c0d0 s10: f000 s11: ffe004a1fbb8 t3 : 2d2d2d2d t4 : ffc400cc0737 t5 : ffc400cc0739 t6 : ffe0066039c8 status: 0100 badaddr: cause: 0003 Call Trace: [] lockdep_hardirqs_on_prepare+0x384/0x388 kernel/locking/lockdep.c:4085 [] trace_hardirqs_on+0x116/0x174 kernel/trace/trace_preemptirq.c:49 [] _save_context+0xa2/0xe2 [] local_flush_tlb_all arch/riscv/include/asm/tlbflush.h:16 [inline] [] populate arch/riscv/mm/kasan_init.c:95 [inline] [] kasan_init+0x23e/0x31a arch/riscv/mm/kasan_init.c:157 irq event stamp: 0 hardirqs last enabled at (0): [<>] 0x0 hardirqs last disabled at (0): [<>] 0x0 softirqs last enabled at (0): [<>] 0x0 softirqs last disabled at (0): [<>] 0x0 random: get_random_bytes called from init_oops_id kernel/panic.c:546 [inline] with crng_init=0 random: get_random_bytes called from init_oops_id kernel/panic.c:543 [inline] with crng_init=0 random: get_random_bytes called from print_oops_end_marker kernel/panic.c:556 [inline] with crng_init=0 random: get_random_bytes called from __warn+0x1be/0x20a kernel/panic.c:613 with crng_init=0 ---[ end trace ]--- Unable to handle kernel paging request at virtual address dfc81004 Oops [#1] Modules linked in: CPU: 0 PID: 0 Comm: swapper Tainted: GW 5.11.0-rc2-00069-gf49815047c1a-dirty #34 Hardware name: riscv-virtio,qemu (DT) epc : __memset+0x60/0xfc arch/riscv/lib/memset.S:67 ra : populate arch/riscv/mm/kasan_init.c:96 [inline] ra : kasan_init+0x256/0x31a arch/riscv/mm/kasan_init.c:157 epc : ffe001791cf0 ra :
[PATCH] mm/mempolicy: minor coding style tweaks
Add whitespace to fix coding style issues, improve code reading.
Signed-off-by: Zhiyuan Dai
---
mm/mempolicy.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 2c3a865..740633d 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -330,7 +330,7 @@ static void mpol_rebind_nodemask(struct mempolicy *pol,
const nodemask_t *nodes)
else if (pol->flags & MPOL_F_RELATIVE_NODES)
mpol_relative_nodemask(, >w.user_nodemask, nodes);
else {
- nodes_remap(tmp, pol->v.nodes,pol->w.cpuset_mems_allowed,
+ nodes_remap(tmp, pol->v.nodes, pol->w.cpuset_mems_allowed,
*nodes);
pol->w.cpuset_mems_allowed = *nodes;
}
@@ -1151,7 +1151,7 @@ int do_migrate_pages(struct mm_struct *mm, const
nodemask_t *from,
tmp = *from;
while (!nodes_empty(tmp)) {
- int s,d;
+ int s, d;
int source = NUMA_NO_NODE;
int dest = 0;
--
1.8.3.1
Re: [PATCH v2 1/7] sched/fair: Ignore percpu threads for imbalance pulls
On Fri, Feb 19, 2021 at 12:59:57PM +, Valentin Schneider wrote:
> From: Lingutla Chandrasekhar
>
> In load balancing, when balancing group is unable to pull task
> due to ->cpus_ptr constraints from busy group, then it sets
> LBF_SOME_PINNED to lb env flags, as a consequence, sgc->imbalance
> is set for its parent domain level. which makes the group
> classified as imbalance to get help from another balancing cpu.
>
> Consider a 4-CPU big.LITTLE system with CPUs 0-1 as LITTLEs and
> CPUs 2-3 as Bigs with below scenario:
> - CPU0 doing newly_idle balancing
> - CPU1 running percpu kworker and RT task (small tasks)
> - CPU2 running 2 big tasks
> - CPU3 running 1 medium task
>
> While CPU0 is doing newly_idle load balance at MC level, it fails to
> pull percpu kworker from CPU1 and sets LBF_SOME_PINNED to lb env flag
> and set sgc->imbalance at DIE level domain. As LBF_ALL_PINNED not cleared,
> it tries to redo the balancing by clearing CPU1 in env cpus, but it don't
> find other busiest_group, so CPU0 stops balacing at MC level without
> clearing 'sgc->imbalance' and restart the load balacing at DIE level.
>
> And CPU0 (balancing cpu) finds LITTLE's group as busiest_group with group
> type as imbalance, and Bigs that classified the level below imbalance type
> would be ignored to pick as busiest, and the balancing would be aborted
> without pulling any tasks (by the time, CPU1 might not have running tasks).
>
> It is suboptimal decision to classify the group as imbalance due to
> percpu threads. So don't use LBF_SOME_PINNED for per cpu threads.
>
> Signed-off-by: Lingutla Chandrasekhar
> [Use kthread_is_per_cpu() rather than p->nr_cpus_allowed]
> Signed-off-by: Valentin Schneider
> ---
> kernel/sched/fair.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 8a8bd7b13634..2d4dcf1a3372 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7539,6 +7539,10 @@ int can_migrate_task(struct task_struct *p, struct
> lb_env *env)
> if (throttled_lb_pair(task_group(p), env->src_cpu, env->dst_cpu))
> return 0;
>
> + /* Disregard pcpu kthreads; they are where they need to be. */
> + if ((p->flags & PF_KTHREAD) && kthread_is_per_cpu(p))
> + return 0;
> +
> if (!cpumask_test_cpu(env->dst_cpu, p->cpus_ptr)) {
> int cpu;
>
Looks good to me. Thanks Valentin for the help.
Thanks,
Pavan
--
Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project.
Re: [PATCH] drm/dsi: Add _NO_ to MIPI_DSI_* flags disabling features
On Mon, Feb 22, 2021 at 3:08 AM Laurent Pinchart
wrote:
>
> Hi Nicolas,
>
> Thank you for the patch.
>
> On Thu, Feb 11, 2021 at 11:33:55AM +0800, Nicolas Boichat wrote:
> > Many of the DSI flags have names opposite to their actual effects,
> > e.g. MIPI_DSI_MODE_EOT_PACKET means that EoT packets will actually
> > be disabled. Fix this by including _NO_ in the flag names, e.g.
> > MIPI_DSI_MODE_NO_EOT_PACKET.
> >
> > Signed-off-by: Nicolas Boichat
>
> This looks good to me, it increases readability.
>
> Reviewed-by: Laurent Pinchart
>
> Please however see the end of the mail for a comment.
>
> > ---
> > I considered adding _DISABLE_ instead, but that'd make the
> > flag names a big too long.
> >
> > Generated with:
> > flag=MIPI_DSI_MODE_VIDEO_HFP; git grep $flag | cut -f1 -d':' | \
> > xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HFP/" {}
> > flag=MIPI_DSI_MODE_VIDEO_HBP; git grep $flag | cut -f1 -d':' | \
> > xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HBP/" {}
> > flag=MIPI_DSI_MODE_VIDEO_HSA; git grep $flag | cut -f1 -d':' | \
> > xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_VIDEO_NO_HSA/" {}
> > flag=MIPI_DSI_MODE_EOT_PACKET; git grep $flag | cut -f1 -d':' | \
> > xargs -I{} sed -i -e "s/$flag/MIPI_DSI_MODE_NO_EOT_PACKET/" {}
> > (then minor format changes)
>
> Ever tried coccinelle ? :-)
Fun project for next time ,-)
>
> > drivers/gpu/drm/bridge/adv7511/adv7533.c | 2 +-
> > drivers/gpu/drm/bridge/analogix/anx7625.c| 2 +-
> > drivers/gpu/drm/bridge/cdns-dsi.c| 4 ++--
> > drivers/gpu/drm/bridge/tc358768.c| 2 +-
> > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 8
> > drivers/gpu/drm/mcde/mcde_dsi.c | 2 +-
> > drivers/gpu/drm/mediatek/mtk_dsi.c | 2 +-
> > drivers/gpu/drm/msm/dsi/dsi_host.c | 8
> > drivers/gpu/drm/panel/panel-asus-z00t-tm5p5-n35596.c | 2 +-
> > drivers/gpu/drm/panel/panel-dsi-cm.c | 2 +-
> > drivers/gpu/drm/panel/panel-elida-kd35t133.c | 2 +-
> > drivers/gpu/drm/panel/panel-khadas-ts050.c | 2 +-
> > drivers/gpu/drm/panel/panel-leadtek-ltk050h3146w.c | 2 +-
> > drivers/gpu/drm/panel/panel-leadtek-ltk500hd1829.c | 2 +-
> > drivers/gpu/drm/panel/panel-novatek-nt35510.c| 2 +-
> > drivers/gpu/drm/panel/panel-osd-osd101t2587-53ts.c | 2 +-
> > drivers/gpu/drm/panel/panel-samsung-s6d16d0.c| 2 +-
> > drivers/gpu/drm/panel/panel-samsung-s6e63j0x03.c | 2 +-
> > drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c| 2 +-
> > drivers/gpu/drm/panel/panel-samsung-s6e8aa0.c| 4 ++--
> > drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 2 +-
> > drivers/gpu/drm/panel/panel-simple.c | 2 +-
> > drivers/gpu/drm/panel/panel-sony-acx424akp.c | 2 +-
> > drivers/gpu/drm/panel/panel-xinpeng-xpp055c272.c | 2 +-
> > include/drm/drm_mipi_dsi.h | 8
> > 25 files changed, 36 insertions(+), 36 deletions(-)
> >
> > []
> > diff --git a/include/drm/drm_mipi_dsi.h b/include/drm/drm_mipi_dsi.h
> > index 360e6377e84b..ba91cf22af51 100644
> > --- a/include/drm/drm_mipi_dsi.h
> > +++ b/include/drm/drm_mipi_dsi.h
> > @@ -119,15 +119,15 @@ struct mipi_dsi_host
> > *of_find_mipi_dsi_host_by_node(struct device_node *node);
> > /* enable hsync-end packets in vsync-pulse and v-porch area */
> > #define MIPI_DSI_MODE_VIDEO_HSE BIT(4)
>
> We're mixing bits that enable a feature and bits that disable a feature.
> Are these bits defined in the DSI spec, or internal to DRM ? In the
> latter case, would it make sense to standardize on one "polarity" ? That
> would be a more intrusive change in drivers though.
Yes, that'd require auditing every single code path and reverse the
logic as needed. I'm not volunteering for that ,-P (hopefully the
current change is still an improvement).
Hopefully real DSI experts can comment (Andrzej?), I think the default
are sensible settings?
>
> > /* disable hfront-porch area */
> > -#define MIPI_DSI_MODE_VIDEO_HFP BIT(5)
> > +#define MIPI_DSI_MODE_VIDEO_NO_HFP BIT(5)
> > /* disable hback-porch area */
> > -#define MIPI_DSI_MODE_VIDEO_HBP BIT(6)
> > +#define MIPI_DSI_MODE_VIDEO_NO_HBP BIT(6)
> > /* disable hsync-active area */
> > -#define MIPI_DSI_MODE_VIDEO_HSA BIT(7)
> > +#define MIPI_DSI_MODE_VIDEO_NO_HSA BIT(7)
> > /* flush display FIFO on vsync pulse */
> > #define MIPI_DSI_MODE_VSYNC_FLUSHBIT(8)
> > /* disable EoT packets in HS mode */
> > -#define MIPI_DSI_MODE_EOT_PACKET BIT(9)
> > +#define MIPI_DSI_MODE_NO_EOT_PACKET BIT(9)
> > /* device supports non-continuous clock behavior (DSI spec 5.6.1) */
> > #define MIPI_DSI_CLOCK_NON_CONTINUOUSBIT(10)
> > /* transmit data in low power */
>
> --
> Regards,
>
> Laurent Pinchart
Re: [PATCH] cpufreq: schedutil: Don't consider freq reduction to busy CPU if need_freq_update is set
On 19-02-21, 19:45, Yue Hu wrote:
> We will set next_f to next_freq(previous freq) if next_f is
> reduced for busy CPU. Then the next sugov_update_next_freq() will check
> if next_freq matches next_f if need_freq_update is not set.
> Obviously, we will do nothing for the case. And The related check to
> fast_switch_enabled and raw_spin_{lock,unlock} operations are
> unnecessary.
Right, but we will still need sugov_update_next_freq() to have the
same implementation regardless and so I am not sure if we should add
this change:
diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 41e498b0008a..7289e1adab73 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -362,6 +362,9 @@ static void sugov_update_single_freq(struct
update_util_data *hook, u64 time,
* recently, as the reduction is likely to be premature then.
*/
if (sugov_cpu_is_busy(sg_cpu) && next_f < sg_policy->next_freq) {
+ if (!sg_policy->need_freq_update)
+ return;
+
next_f = sg_policy->next_freq;
/* Restore cached freq as next_freq has changed */
--
viresh
[PATCH] mm/memory_hotplug: minor coding style tweaks
This patch move the pointer location to fix coding style issues,
improve code reading.
Signed-off-by: Zhiyuan Dai
---
mm/memory_hotplug.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index f9d57b9..a46c297 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -764,7 +764,7 @@ static inline struct zone *default_zone_for_pfn(int nid,
unsigned long start_pfn
return movable_node_enabled ? movable_zone : kernel_zone;
}
-struct zone * zone_for_pfn_range(int online_type, int nid, unsigned start_pfn,
+struct zone *zone_for_pfn_range(int online_type, int nid, unsigned start_pfn,
unsigned long nr_pages)
{
if (online_type == MMOP_ONLINE_KERNEL)
--
1.8.3.1
[PATCH] mm/kasan: remove volatile keyword
Like volatile, the kernel primitives which make concurrent
access to data safe (spinlocks, mutexes, memory barriers,
etc.) are designed to prevent unwanted optimization.
If they are being used properly, there will be no need to
use volatile as well. If volatile is still necessary,
there is almost certainly a bug in the code somewhere.
In properly-written kernel code, volatile can only serve
to slow things down.
see: Documentation/process/volatile-considered-harmful.rst
Signed-off-by: Zhiyuan Dai
---
mm/kasan/shadow.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/kasan/shadow.c b/mm/kasan/shadow.c
index 7c2c08c..d5ff9ca 100644
--- a/mm/kasan/shadow.c
+++ b/mm/kasan/shadow.c
@@ -25,13 +25,13 @@
#include "kasan.h"
-bool __kasan_check_read(const volatile void *p, unsigned int size)
+bool __kasan_check_read(const void *p, unsigned int size)
{
return check_memory_region((unsigned long)p, size, false, _RET_IP_);
}
EXPORT_SYMBOL(__kasan_check_read);
-bool __kasan_check_write(const volatile void *p, unsigned int size)
+bool __kasan_check_write(const void *p, unsigned int size)
{
return check_memory_region((unsigned long)p, size, true, _RET_IP_);
}
--
1.8.3.1
[PATCH] mm/kasan: switch from strlcpy to strscpy
strlcpy is marked as deprecated in Documentation/process/deprecated.rst, and there is no functional difference when the caller expects truncation (when not checking the return value). strscpy is relatively better as it also avoids scanning the whole source string. Signed-off-by: Zhiyuan Dai --- mm/kasan/report_generic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/kasan/report_generic.c b/mm/kasan/report_generic.c index 8a9c889..fc7f7ad 100644 --- a/mm/kasan/report_generic.c +++ b/mm/kasan/report_generic.c @@ -148,7 +148,7 @@ static bool __must_check tokenize_frame_descr(const char **frame_descr, } /* Copy token (+ 1 byte for '\0'). */ - strlcpy(token, *frame_descr, tok_len + 1); + strscpy(token, *frame_descr, tok_len + 1); } /* Advance frame_descr past separator. */ -- 1.8.3.1
Re: [PATCH v3] staging: rtl8723bs: fix code style comparison warning
On Fri, Feb 19, 2021 at 06:23:54PM +, Kurt Manucredo wrote: > > > checkpatch gives the following WARNING: > WARNING: Comparisons should place the constant on the right side of the test > this patch fixes the coding style warning. > > Signed-off-by: Kurt Manucredo > --- Looks okay to me. Thanks! Reviewed-by: Dan Carpenter regards, dan carpenter
Re: [PATCH] RTIC: selinux: ARM64: Move selinux_state to a separate page
On 2021-02-17 02:02, Miguel Ojeda wrote: On Tue, Feb 16, 2021 at 11:22 AM Preeti Nagar wrote: The changes introduce a new security feature, RunTime Integrity Check (RTIC), designed to protect Linux Kernel at runtime. The motivation behind these changes is: 1. The system protection offered by Security Enhancements(SE) for Android relies on the assumption of kernel integrity. If the kernel itself is compromised (by a perhaps as yet unknown future vulnerability), SE for Android security mechanisms could potentially be disabled and rendered ineffective. 2. Qualcomm Snapdragon devices use Secure Boot, which adds cryptographic checks to each stage of the boot-up process, to assert the authenticity of all secure software images that the device executes. However, due to various vulnerabilities in SW modules, the integrity of the system can be compromised at any time after device boot-up, leading to un-authorized SW executing. The feature's idea is to move some sensitive kernel structures to a separate page and monitor further any unauthorized changes to these, from higher Exception Levels using stage 2 MMU. Moving these to a different page will help avoid getting page faults from un-related data. The mechanism we have been working on removes the write permissions for HLOS in the stage 2 page tables for the regions to be monitored, such that any modification attempts to these will lead to faults being generated and handled by handlers. If the protected assets are moved to a separate page, faults will be generated corresponding to change attempts to these assets only. If not moved to a separate page, write attempts to un-related data present on the monitored pages will also be generated. Using this feature, some sensitive variables of the kernel which are initialized after init or are updated rarely can also be protected from simple overwrites and attacks trying to modify these. Currently, the change moves selinux_state structure to a separate page. The page is 2MB aligned not 4K to avoid TLB related performance impact as, for some CPU core designs, the TLB does not cache 4K stage 2 (IPA to PA) mappings if the IPA comes from a stage 1 mapping. In future, we plan to move more security-related kernel assets to this page to enhance protection. Part of this commit message should likely be added as a new file under Documentation/ somewhere. Yes, that will be helpful, will put it in Documentation/security in the next update. Thank you! diff --git a/security/Kconfig b/security/Kconfig index 7561f6f..1af913a 100644 --- a/security/Kconfig +++ b/security/Kconfig @@ -291,5 +291,16 @@ config LSM source "security/Kconfig.hardening" +config SECURITY_RTIC + bool "RunTime Integrity Check feature" + depends on ARM64 + help + RTIC(RunTime Integrity Check) feature is to protect Linux kernel + at runtime. This relocates some of the security sensitive kernel + structures to a separate RTIC specific page. + + This is to enable monitoring and protection of these kernel assets + from a higher exception level(EL) against any unauthorized changes. Rewording suggestion: The RTIC (RunTime Integrity Check) feature protects the kernel at runtime by relocating some of its security-sensitive structures to a separate RTIC-specific page. This enables monitoring and and protecting them from a higher exception level against unauthorized changes. Thanks :) Cheers, Miguel
Re: [PATCH] doc: use KCFLAGS instead of EXTRA_CFLAGS to pass flags from command line
Reviewed-by: Alex Shi
在 2021/2/21 下午11:25, Masahiro Yamada 写道:
> You should use KCFLAGS to pass additional compiler flags from the
> command line. Using EXTRA_CFLAGS is wrong.
>
> EXTRA_CFLAGS is supposed to specify flags applied only to the current
> Makefile (and now deprecated in favor of ccflags-y).
>
> It is still used in arch/mips/kvm/Makefile (and possibly in external
> modules too). Passing EXTRA_CFLAGS from the command line overwrites
> it and breaks the build.
>
> I also fixed drivers/gpu/drm/tilcdc/Makefile because commit 816175dd1fd7
> ("drivers/gpu/drm/tilcdc: Makefile, only -Werror when no -W* in
> EXTRA_CFLAGS") was based on the same misunderstanding.
>
> Signed-off-by: Masahiro Yamada
> ---
>
> Documentation/process/4.Coding.rst| 2 +-
> Documentation/process/submit-checklist.rst| 2 +-
> Documentation/translations/it_IT/process/4.Coding.rst | 2 +-
> Documentation/translations/it_IT/process/submit-checklist.rst | 2 +-
> Documentation/translations/zh_CN/process/4.Coding.rst | 2 +-
> drivers/gpu/drm/tilcdc/Makefile | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
>
Re: [PATCH net] bcm63xx_enet: fix sporadic kernel panic
On 2/21/2021 17:35, Sieng Piaw Liew wrote:
In ndo_stop functions, netdev_completed_queue() is called during forced
tx reclaim, after netdev_reset_queue(). This may trigger kernel panic if
there is any tx skb left.
This patch moves netdev_reset_queue() to after tx reclaim, so BQL can
complete successfully then reset.
Signed-off-by: Sieng Piaw Liew
Acked-by: Florian Fainelli
Fixes: 4c59b0f5543d ("bcm63xx_enet: add BQL support")
--
Florian
[PATCH] mm/ioremap: remove volatile keyword in iounmap function
Like volatile, the kernel primitives which make concurrent
access to data safe (spinlocks, mutexes, memory barriers,
etc.) are designed to prevent unwanted optimization.
If they are being used properly, there will be no need to
use volatile as well. If volatile is still necessary,
there is almost certainly a bug in the code somewhere.
In properly-written kernel code, volatile can only serve
to slow things down.
see: Documentation/process/volatile-considered-harmful.rst
Signed-off-by: Zhiyuan Dai
---
mm/ioremap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/ioremap.c b/mm/ioremap.c
index 5fa1ab4..c49dd41 100644
--- a/mm/ioremap.c
+++ b/mm/ioremap.c
@@ -281,7 +281,7 @@ void __iomem *ioremap_prot(phys_addr_t addr, size_t size,
unsigned long prot)
}
EXPORT_SYMBOL(ioremap_prot);
-void iounmap(volatile void __iomem *addr)
+void iounmap(void __iomem *addr)
{
vunmap((void *)((unsigned long)addr & PAGE_MASK));
}
--
1.8.3.1
Re: [PATCH] RTIC: selinux: ARM64: Move selinux_state to a separate page
On 2021-02-17 15:45, Marc Zyngier wrote: On 2021-02-17 09:42, Will Deacon wrote: [Please include arm64 and kvm folks for threads involving the stage-2 MMU] On Tue, Feb 16, 2021 at 03:47:52PM +0530, Preeti Nagar wrote: The changes introduce a new security feature, RunTime Integrity Check (RTIC), designed to protect Linux Kernel at runtime. The motivation behind these changes is: 1. The system protection offered by Security Enhancements(SE) for Android relies on the assumption of kernel integrity. If the kernel itself is compromised (by a perhaps as yet unknown future vulnerability), SE for Android security mechanisms could potentially be disabled and rendered ineffective. 2. Qualcomm Snapdragon devices use Secure Boot, which adds cryptographic checks to each stage of the boot-up process, to assert the authenticity of all secure software images that the device executes. However, due to various vulnerabilities in SW modules, the integrity of the system can be compromised at any time after device boot-up, leading to un-authorized SW executing. The feature's idea is to move some sensitive kernel structures to a separate page and monitor further any unauthorized changes to these, from higher Exception Levels using stage 2 MMU. Moving these to a different page will help avoid getting page faults from un-related data. The mechanism we have been working on removes the write permissions for HLOS in the stage 2 page tables for the regions to be monitored, such that any modification attempts to these will lead to faults being generated and handled by handlers. If the protected assets are moved to a separate page, faults will be generated corresponding to change attempts to these assets only. If not moved to a separate page, write attempts to un-related data present on the monitored pages will also be generated. Using this feature, some sensitive variables of the kernel which are initialized after init or are updated rarely can also be protected from simple overwrites and attacks trying to modify these. Although I really like the idea of using stage-2 to protect the kernel, I think the approach you outline here is deeply flawed. Identifying "sensitive variables" of the kernel to protect is subjective and doesn't scale. Furthermore, the triaging of what constitues a valid access is notably absent from your description and is assumedly implemented in an opaque blob at EL2. I think a better approach would be along the lines of: 1. Introduce the protection at stage-1 (like we already have for mapping e.g. the kernel text R/O) 2. Implement the handlers in the kernel, so the heuristics are clear. 3. Extend this to involve KVM, so that the host can manage its own stage-2 to firm-up the stage-1 protections. +1 on that. Even if, as I suspect, this is targeting some unspecified hypervisor that is not KVM, the first course of action should be for this to be implemented in the kernel's own hypervisor first so that anyone can review understand what is at play. Thanks, M. Thank you for your comments. The key value add of the feature is a third party independent entity keeping a watch on crucial kernel assets, such that in case the kernel itself is compromised, still, the protection can remain intact. Can this be achieved if the implementation is done in KVM? I've limited knowledge of KVM currently, can surely look into more details for a better understanding. Agree that the mechanism for triaging what constitutes valid access needs a clear approach. We will discuss your suggestions internally if we can use them to improve the overall feature design and share updated patches. Thank you!
Re: [PATCH v6 1/2] checkpatch: add verbose mode
On Mon, Feb 22, 2021 at 8:14 AM Joe Perches wrote: > > On Mon, 2021-02-22 at 00:05 +0530, Dwaipayan Ray wrote: > > On Sun, Feb 21, 2021 at 11:36 PM Joe Perches wrote: > > > > > > On Sun, 2021-02-21 at 17:28 +0530, Dwaipayan Ray wrote: > > > > Add a new verbose mode to checkpatch.pl to emit additional verbose > > > > test descriptions. The verbose mode is optional and can be enabled > > > > by the flag -v or --verbose. > > > > > > OK, maybe add color coding to the list_types output. > > Okay, nice idea! > [] > > Sure, I will do something like this. > > Are there any other improvements you can see right now > > or will the coloring thing suffice? > > A lot more descriptive output for the .rst file and > of course a lot more of the types documented... > Sure I was hoping to do that over time after getting this series in... Nevertheless I will send the v7 in right away with the color code changes. Thanks, Dwaipayan.
Re: [PATCH] erofs: support adjust lz4 history window size
Hi Jianan,
On Thu, Feb 18, 2021 at 08:00:49PM +0800, Huang Jianan via Linux-erofs wrote:
> From: huangjianan
>
> lz4 uses LZ4_DISTANCE_MAX to record history preservation. When
> using rolling decompression, a block with a higher compression
> ratio will cause a larger memory allocation (up to 64k). It may
> cause a large resource burden in extreme cases on devices with
> small memory and a large number of concurrent IOs. So appropriately
> reducing this value can improve performance.
>
> Decreasing this value will reduce the compression ratio (except
> when input_size currently only supports 4k output, reducing this value will not
> significantly reduce the compression benefits.
>
> Signed-off-by: Huang Jianan
> Signed-off-by: Guo Weichao
> ---
> fs/erofs/decompressor.c | 13 +
> fs/erofs/erofs_fs.h | 3 ++-
> fs/erofs/internal.h | 3 +++
> fs/erofs/super.c| 3 +++
> 4 files changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/fs/erofs/decompressor.c b/fs/erofs/decompressor.c
> index 1cb1ffd10569..94ae56b3ff71 100644
> --- a/fs/erofs/decompressor.c
> +++ b/fs/erofs/decompressor.c
> @@ -36,22 +36,27 @@ static int z_erofs_lz4_prepare_destpages(struct
> z_erofs_decompress_req *rq,
> struct page *availables[LZ4_MAX_DISTANCE_PAGES] = { NULL };
> unsigned long bounced[DIV_ROUND_UP(LZ4_MAX_DISTANCE_PAGES,
> BITS_PER_LONG)] = { 0 };
> + unsigned int lz4_distance_pages = LZ4_MAX_DISTANCE_PAGES;
> void *kaddr = NULL;
> unsigned int i, j, top;
>
> + if (EROFS_SB(rq->sb)->compr_alg)
> + lz4_distance_pages = DIV_ROUND_UP(EROFS_SB(rq->sb)->compr_alg,
> + PAGE_SIZE) + 1;
> +
Thanks for your patch, I agree that will reduce runtime memory
footpoint. and keep max sliding window ondisk in bytes (rather
than in blocks) is better., but could we calculate lz4_distance_pages
ahead when reading super_block?
Also, in the next cycle, I'd like to introduce a bitmap for available
algorithms (maximum 16-bit) for the next LZMA algorithm, and for each
available algorithm introduces an on-disk variable-array like below:
bitmap(16-bit)2 1 0
... LZMALZ4
__le16 compr_opt_off; /* get the opt array start offset
(I think also in 4-byte) */
compr alg 0 (lz4) __le16 alg_opt_size;
/* next opt off = roundup(off + alg_opt_size, 4); */
__le16 lz4_max_distance;
/* 4-byte aligned */
compr alg x (if available) u8 alg_opt_size;
...
...
When reading sb, first, it scans the whole bitmap, and get all the
available algorithms in the image at once. And then read such compr
opts one-by-one.
Do you have some interest and extra time to implement it? :) That
makes me work less since I'm debugging mbpcluster compression now...
Thanks,
Gao Xiang
Re: [PATCH v8 09/22] counter: Return error code on invalid modes
On Sat, Feb 20, 2021 at 10:43:06AM -0600, David Lechner wrote: > On 2/12/21 6:13 AM, William Breathitt Gray wrote: > > Only a select set of modes (function, action, etc.) are valid for a > > given device configuration. This patch ensures that invalid modes result > > in a return -EINVAL. Such a situation should never occur in reality, but > > it's good to define a default switch cases for the sake of making the > > intent of the code clear. > > > > Cc: Syed Nayyar Waris > > Cc: Kamel Bouhara > > Cc: Fabrice Gasnier > > Cc: Maxime Coquelin > > Cc: Alexandre Torgue > > Cc: David Lechner > > Signed-off-by: William Breathitt Gray > > --- > > Reviewed-by: David Lechner > > (In response to Jonathan's comment, I think this is fine rather than > adding more churn to change all of the breaks to returns - but will > keep that in mind for future changes.) Due to some other updates I'm making to this patchset, I went ahead already and updated the breaks to returns in the few places where applicable. The changes to this patch are minor, but being pedantic I'll hold off on adding your Reviewed-by line until the next revision so you have the opportunity to formally approve it. William Breathitt Gray signature.asc Description: PGP signature
Re: [PATCH v8 0/3] CPUFreq: Add support for opp-sharing cpus
On 19-02-21, 19:16, Sudeep Holla wrote: > Hi Viresh, > > On Fri, Feb 19, 2021 at 09:49:44AM +0530, Viresh Kumar wrote: > > On 18-02-21, 22:23, Nicola Mazzucato wrote: > > > Hi Viresh, > > > > > > In this V8 I have addressed your comments: > > > - correct the goto in patch 1/3 > > > - improve comment in patch 2/3 for dev_pm_opp_get_opp_count() > > > > LGTM. I will apply them after the merge window is over. Thanks. > > I am planning to merge the series on scmi[1] which changes scmi-cpufreq.c > and will conflict with these changes I think. If possible either, > > 1. Share a branch with these changes that I can merge or > 2. I can take patch 1/3 and 2/3 with other scmi changes with your Ack. > > I am fine either way, let me know by v5.12-rc1 I have applied 3/3, you can take first two and add my Ack. Acked-by: Viresh Kumar -- viresh
Re: [PATCH] vdpa/mlx5: set_features should allow reset to zero
On 2021/2/19 7:54 下午, Si-Wei Liu wrote:
Commit 452639a64ad8 ("vdpa: make sure set_features is invoked
for legacy") made an exception for legacy guests to reset
features to 0, when config space is accessed before features
are set. We should relieve the verify_min_features() check
and allow features reset to 0 for this case.
It's worth noting that not just legacy guests could access
config space before features are set. For instance, when
feature VIRTIO_NET_F_MTU is advertised some modern driver
will try to access and validate the MTU present in the config
space before virtio features are set.
This looks like a spec violation:
"
The following driver-read-only field, mtu only exists if
VIRTIO_NET_F_MTU is set. This field specifies the maximum MTU for the
driver to use.
"
Do we really want to workaround this?
Thanks
Rejecting reset to 0
prematurely causes correct MTU and link status unable to load
for the very first config space access, rendering issues like
guest showing inaccurate MTU value, or failure to reject
out-of-range MTU.
Fixes: 1a86b377aa21 ("vdpa/mlx5: Add VDPA driver for supported mlx5 devices")
Signed-off-by: Si-Wei Liu
---
drivers/vdpa/mlx5/net/mlx5_vnet.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/vdpa/mlx5/net/mlx5_vnet.c
b/drivers/vdpa/mlx5/net/mlx5_vnet.c
index 7c1f789..540dd67 100644
--- a/drivers/vdpa/mlx5/net/mlx5_vnet.c
+++ b/drivers/vdpa/mlx5/net/mlx5_vnet.c
@@ -1490,14 +1490,6 @@ static u64 mlx5_vdpa_get_features(struct vdpa_device
*vdev)
return mvdev->mlx_features;
}
-static int verify_min_features(struct mlx5_vdpa_dev *mvdev, u64 features)
-{
- if (!(features & BIT_ULL(VIRTIO_F_ACCESS_PLATFORM)))
- return -EOPNOTSUPP;
-
- return 0;
-}
-
static int setup_virtqueues(struct mlx5_vdpa_net *ndev)
{
int err;
@@ -1558,18 +1550,13 @@ static int mlx5_vdpa_set_features(struct vdpa_device
*vdev, u64 features)
{
struct mlx5_vdpa_dev *mvdev = to_mvdev(vdev);
struct mlx5_vdpa_net *ndev = to_mlx5_vdpa_ndev(mvdev);
- int err;
print_features(mvdev, features, true);
- err = verify_min_features(mvdev, features);
- if (err)
- return err;
-
ndev->mvdev.actual_features = features & ndev->mvdev.mlx_features;
ndev->config.mtu = cpu_to_mlx5vdpa16(mvdev, ndev->mtu);
ndev->config.status |= cpu_to_mlx5vdpa16(mvdev, VIRTIO_NET_S_LINK_UP);
- return err;
+ return 0;
}
static void mlx5_vdpa_set_config_cb(struct vdpa_device *vdev, struct vdpa_callback *cb)
Re: [PATCH v2] IMA: support for duplicate data measurement
On Thu, 2021-02-18 at 14:05 -0800, Tushar Sugandhi wrote: > On 2021-02-17 12:49 p.m., Tushar Sugandhi wrote: > > On 2021-02-17 12:39 p.m., Mimi Zohar wrote: > >> On Wed, 2021-02-17 at 10:53 -0800, Tushar Sugandhi wrote: > >>> Thanks for the feedback Mimi. > >>> Appreciate it. > >>> > >>> On 2021-02-17 7:03 a.m., Mimi Zohar wrote: > Hi Tushar, > > The Subject line could be improved. Perhaps something like - "IMA: > support for duplicate measurement records" > > >>> Will do. > >>> > On Tue, 2021-02-16 at 18:46 -0800, Tushar Sugandhi wrote: > > IMA does not measure duplicate data since TPM extend is a very > > expensive > > operation. However, in some cases, the measurement of duplicate data > > is necessary to accurately determine the current state of the system. > > Eg, SELinux state changing from 'audit', to 'enforcing', and back to > > 'audit' again. In this example, currently, IMA will not measure the > > last state change to 'audit'. This limits the ability of attestation > > services to accurately determine the current state of the measurements > > on the system. > > This patch description is written from your specific usecase > perspective, but it impacts file and buffer data measurements as well, > not only critical data measurements. In all of these situations, with > this patch a new measurement record is added/appended to the > measurement list. Please re-write the patch description making it more > generic. > > For example, I would start with something like, "IMA does not include > duplicate file, buffer or critical data measurement records ..." > > >>> Agreed. > >>> I will generalize the description further and send the v3 for review. > >> > >> It would be good to boot with the ima_policy=tcb policy with/without > >> your patch and account for the different number of measurements. Are > >> all the differences related to duplicate measurements - original file > >> hash -> new file hash -> original file hash - similar to what you > >> described. > >> > > Thanks for the ima_policy=tcb pointer. > > > > I tested my patch with: > > - duplicate buffer content for "measure func=CRITICAL_DATA" > > - and reading the same file twice with "measure func=FILE_CHECK > > mask=MAY_READ" > > > > In both the above use cases, IMA is measuring the duplicate entries with > > the patch, and not measuring the duplicate entries w/o the patch. > > > > I will test the "ima_policy=tcb" boot-scenario as you suggested, before > > posting the next version. > > > > I booted the system with "ima_policy=tcb" policy with/without my patch. > I also removed /etc/ima/ima-policy for testing these use-cases. > (so that it wouldn't override the policy generated by boot param > "ima_policy=tcb"). > > I double checked the contents of the kernel policy: > #cat /sys/kernel/security/integrity/ima/policy > dont_measure fsmagic=0x9fa0 > dont_measure fsmagic=0x62656572 > dont_measure fsmagic=0x64626720 > dont_measure fsmagic=0x1021994 > dont_measure fsmagic=0x1cd1 > dont_measure fsmagic=0x42494e4d > dont_measure fsmagic=0x73636673 > dont_measure fsmagic=0xf97cff8c > dont_measure fsmagic=0x43415d53 > dont_measure fsmagic=0x27e0eb > dont_measure fsmagic=0x63677270 > dont_measure fsmagic=0x6e736673 > dont_measure fsmagic=0xde5e81e4 > measure func=MMAP_CHECK mask=MAY_EXEC > measure func=BPRM_CHECK mask=MAY_EXEC > measure func=FILE_CHECK mask=^MAY_READ euid=0 > measure func=FILE_CHECK mask=^MAY_READ uid=0 > measure func=MODULE_CHECK > measure func=FIRMWARE_CHECK > measure func=POLICY_CHECK > > And then I compared the contents of the ascii_runtime_measurements with > and without my patch. > > And here are my findings: > > (1) Files like systemd-udevd, x2go_sessions etc. get measured multiple > times with the CONFIG_IMA_DISABLE_HTABLE=y. > They only get measured once with the config "=n". > > 10 668df8723f5a1f57a0afe3b50d44054d66363f3e ima-ng > sha1:51f66e82421b93b21ad1e0a25e5efa4155c6a8e0 /lib/systemd/systemd-udevd > 10 668df8723f5a1f57a0afe3b50d44054d66363f3e ima-ng > sha1:51f66e82421b93b21ad1e0a25e5efa4155c6a8e0 /lib/systemd/systemd-udevd > > (2) There are lot more instances of /tmp/ measurement records > with the CONFIG_IMA_DISABLE_HTABLE=y. > Eg, > > 10 33515851cfee4acbf24de9482ff018d33def1083 ima-ng > sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/oUWCVeypLR > 10 9d1dc0e1e54ee2e16308a824fc5780bd21b38208 ima-ng > sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/etX8dy7qqy > 10 8643a5543179b86c02d7e3e01e16b3bd2f8dbb9f ima-ng > sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/I4zTWEuyMf > 10 56e9547a4ed39036d2e790cfad78b467aa979e32 ima-ng > sha1:da39a3ee5e6b4b0d3255bfef95601890afd80709 /tmp/Lh5wDm6_Ep > > I believe both the observations
Re: [PATCH 07/10] clocksource/drivers/hyper-v: Handle vDSO differences inline
On Wed, Jan 27, 2021 at 12:23:42PM -0800, Michael Kelley wrote:
> While the driver for the Hyper-V Reference TSC and STIMERs is architecture
> neutral, vDSO is implemented for x86/x64, but not for ARM64. Current code
> calls into utility functions under arch/x86 (and coming, under arch/arm64)
> to handle the difference.
>
> Change this approach to handle the difference inline based on whether
> VDSO_CLOCK_MODE_HVCLOCK is present. The new approach removes code under
> arch/* since the difference is tied more to the specifics of the Linux
> implementation than to the architecture.
>
> No functional change.
>
> Signed-off-by: Michael Kelley
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> arch/x86/include/asm/mshyperv.h| 4
> drivers/clocksource/hyperv_timer.c | 10 --
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index 4d3e0c5..ed9dc56 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -27,10 +27,6 @@ static inline u64 hv_get_register(unsigned int reg)
> return value;
> }
>
> -#define hv_set_clocksource_vdso(val) \
> - ((val).vdso_clock_mode = VDSO_CLOCKMODE_HVCLOCK)
> -#define hv_enable_vdso_clocksource() \
> - vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
> #define hv_get_raw_timer() rdtsc_ordered()
>
> /*
> diff --git a/drivers/clocksource/hyperv_timer.c
> b/drivers/clocksource/hyperv_timer.c
> index 9425308..9cee6db 100644
> --- a/drivers/clocksource/hyperv_timer.c
> +++ b/drivers/clocksource/hyperv_timer.c
> @@ -372,7 +372,9 @@ static void resume_hv_clock_tsc(struct clocksource *arg)
>
> static int hv_cs_enable(struct clocksource *cs)
> {
> - hv_enable_vdso_clocksource();
> +#ifdef VDSO_CLOCKMODE_HVCLOCK
> + vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
> +#endif
> return 0;
> }
>
> @@ -385,6 +387,11 @@ static int hv_cs_enable(struct clocksource *cs)
> .suspend= suspend_hv_clock_tsc,
> .resume = resume_hv_clock_tsc,
> .enable = hv_cs_enable,
> +#ifdef VDSO_CLOCKMODE_HVCLOCK
> + .vdso_clock_mode = VDSO_CLOCKMODE_HVCLOCK,
> +#else
> + .vdso_clock_mode = VDSO_CLOCKMODE_NONE,
> +#endif
> };
>
> static u64 notrace read_hv_clock_msr(void)
> @@ -439,7 +446,6 @@ static bool __init hv_init_tsc_clocksource(void)
> tsc_msr = tsc_msr | 0x1 | (u64)phys_addr;
> hv_set_register(HV_REGISTER_REFERENCE_TSC, tsc_msr);
>
> - hv_set_clocksource_vdso(hyperv_cs_tsc);
> clocksource_register_hz(_cs_tsc, NSEC_PER_SEC/100);
>
> hv_sched_clock_offset = hv_read_reference_counter();
> --
> 1.8.3.1
>
Re: [PATCH 06/10] Drivers: hv: vmbus: Move handling of VMbus interrupts
On Wed, Jan 27, 2021 at 12:23:41PM -0800, Michael Kelley wrote:
> VMbus interrupts are most naturally modelled as per-cpu IRQs. But
> because x86/x64 doesn't have per-cpu IRQs, the core VMbus interrupt
> handling machinery is done in code under arch/x86 and Linux IRQs are
> not used. Adding support for ARM64 means adding equivalent code
> using per-cpu IRQs under arch/arm64.
>
> A better model is to treat per-cpu IRQs as the normal path (which it is
> for modern architectures), and the x86/x64 path as the exception. Do this
> by incorporating standard Linux per-cpu IRQ allocation into the main VMbus
> driver, and bypassing it in the x86/x64 exception case. For x86/x64,
> special case code is retained under arch/x86, but no VMbus interrupt
> handling code is needed under arch/arm64.
>
> No functional change.
>
> Signed-off-by: Michael Kelley
Reviewed-by: Boqun Feng
Regards,
Boqun
> ---
> arch/x86/include/asm/mshyperv.h | 1 -
> arch/x86/kernel/cpu/mshyperv.c | 13 +++--
> drivers/hv/hv.c | 8 +-
> drivers/hv/vmbus_drv.c | 63
> -
> include/asm-generic/mshyperv.h | 7 ++---
> 5 files changed, 70 insertions(+), 22 deletions(-)
>
> diff --git a/arch/x86/include/asm/mshyperv.h b/arch/x86/include/asm/mshyperv.h
> index d12a188..4d3e0c5 100644
> --- a/arch/x86/include/asm/mshyperv.h
> +++ b/arch/x86/include/asm/mshyperv.h
> @@ -32,7 +32,6 @@ static inline u64 hv_get_register(unsigned int reg)
> #define hv_enable_vdso_clocksource() \
> vclocks_set_used(VDSO_CLOCKMODE_HVCLOCK);
> #define hv_get_raw_timer() rdtsc_ordered()
> -#define hv_get_vector() HYPERVISOR_CALLBACK_VECTOR
>
> /*
> * Reference to pv_ops must be inline so objtool
> diff --git a/arch/x86/kernel/cpu/mshyperv.c b/arch/x86/kernel/cpu/mshyperv.c
> index f628e3dc..5679100a1 100644
> --- a/arch/x86/kernel/cpu/mshyperv.c
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -55,23 +55,18 @@
> set_irq_regs(old_regs);
> }
>
> -int hv_setup_vmbus_irq(int irq, void (*handler)(void))
> +void hv_setup_vmbus_handler(void (*handler)(void))
> {
> - /*
> - * The 'irq' argument is ignored on x86/x64 because a hard-coded
> - * interrupt vector is used for Hyper-V interrupts.
> - */
> vmbus_handler = handler;
> - return 0;
> }
> +EXPORT_SYMBOL_GPL(hv_setup_vmbus_handler);
>
> -void hv_remove_vmbus_irq(void)
> +void hv_remove_vmbus_handler(void)
> {
> /* We have no way to deallocate the interrupt gate */
> vmbus_handler = NULL;
> }
> -EXPORT_SYMBOL_GPL(hv_setup_vmbus_irq);
> -EXPORT_SYMBOL_GPL(hv_remove_vmbus_irq);
> +EXPORT_SYMBOL_GPL(hv_remove_vmbus_handler);
>
> /*
> * Routines to do per-architecture handling of stimer0
> diff --git a/drivers/hv/hv.c b/drivers/hv/hv.c
> index afe7a62..917b29e 100644
> --- a/drivers/hv/hv.c
> +++ b/drivers/hv/hv.c
> @@ -16,6 +16,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include "hyperv_vmbus.h"
> @@ -214,10 +215,12 @@ void hv_synic_enable_regs(unsigned int cpu)
> hv_set_register(HV_REGISTER_SIEFP, siefp.as_uint64);
>
> /* Setup the shared SINT. */
> + if (vmbus_irq != -1)
> + enable_percpu_irq(vmbus_irq, 0);
> shared_sint.as_uint64 = hv_get_register(HV_REGISTER_SINT0 +
> VMBUS_MESSAGE_SINT);
>
> - shared_sint.vector = hv_get_vector();
> + shared_sint.vector = vmbus_interrupt;
> shared_sint.masked = false;
>
> /*
> @@ -285,6 +288,9 @@ void hv_synic_disable_regs(unsigned int cpu)
> sctrl.as_uint64 = hv_get_register(HV_REGISTER_SCONTROL);
> sctrl.enable = 0;
> hv_set_register(HV_REGISTER_SCONTROL, sctrl.as_uint64);
> +
> + if (vmbus_irq != -1)
> + disable_percpu_irq(vmbus_irq);
> }
>
>
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 8affe68..62721a7 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -48,8 +48,10 @@ struct vmbus_dynid {
>
> static void *hv_panic_page;
>
> +static long __percpu *vmbus_evt;
> +
> /* Values parsed from ACPI DSDT */
> -static int vmbus_irq;
> +int vmbus_irq;
> int vmbus_interrupt;
>
> /*
> @@ -1354,7 +1356,13 @@ static void vmbus_isr(void)
> tasklet_schedule(_cpu->msg_dpc);
> }
>
> - add_interrupt_randomness(hv_get_vector(), 0);
> + add_interrupt_randomness(vmbus_interrupt, 0);
> +}
> +
> +static irqreturn_t vmbus_percpu_isr(int irq, void *dev_id)
> +{
> + vmbus_isr();
> + return IRQ_HANDLED;
> }
>
> /*
> @@ -1469,9 +1477,28 @@ static int vmbus_bus_init(void)
> if (ret)
> return ret;
>
> - ret = hv_setup_vmbus_irq(vmbus_irq, vmbus_isr);
> - if (ret)
> - goto err_setup;
> + /*
> + * VMbus interrupts are best modeled as per-cpu interrupts. If
> + * on an architecture with support for per-cpu IRQs (e.g. ARM64),
> +
[PATCH v2] x86/mce: fix wrong no-return-ip logic in do_machine_check()
>From commit b2f9d678e28c ("x86/mce: Check for faults tagged in
EXTABLE_CLASS_FAULT exception table entries"), When there is a
memory MCE_AR_SEVERITY error with no return ip, Only a SIGBUS
signal is send to current. As the page is not poisoned, the SIGBUS
process's coredump step in kernel will touch the error page again,
which result to a fatal error. We need to poison the page and then
kill current in memory-failure module.
So fix it using the orinigal checking method.
Signed-off-by: Aili Yao
---
arch/x86/kernel/cpu/mce/core.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index e133ce1e562b..70380d7d98b3 100644
--- a/arch/x86/kernel/cpu/mce/core.c
+++ b/arch/x86/kernel/cpu/mce/core.c
@@ -1414,7 +1414,10 @@ noinstr void do_machine_check(struct pt_regs *regs)
/* If this triggers there is no way to recover. Die hard. */
BUG_ON(!on_thread_stack() || !user_mode(regs));
- queue_task_work(, kill_current_task);
+ if (worst == MCE_AR_SEVERITY)
+ queue_task_work(, 0);
+ else if (kill_current_task)
+ queue_task_work(, kill_current_task);
} else {
/*
--
2.25.1
[PATCH -next] Documentation: proc.rst: add more about the 6 fields in loadavg
Address Jon's feedback on the previous patch by adding info about
field separators in the /proc/loadavg file.
Signed-off-by: Randy Dunlap
Cc: Jonathan Corbet
Cc: linux-...@vger.kernel.org
---
Documentation/filesystems/proc.rst |4
1 file changed, 4 insertions(+)
--- linux-next-20210219.orig/Documentation/filesystems/proc.rst
+++ linux-next-20210219/Documentation/filesystems/proc.rst
@@ -691,6 +691,10 @@ files are there, and which are missing.
number of processes currently runnable (running or on ready
queue);
total number of processes in system;
last pid created.
+All fields are separated by one space except "number of
+processes currently runnable" and "total number of processes
+in system", which are separated by a slash ('/'). Example:
+ 0.61 0.61 0.55 3/828 22084
locksKernel locks
meminfo Memory info
misc Miscellaneous
Re: [PATCH] virtio: remove export for virtio_config_{enable, disable}
On 2021/2/21 12:28 上午, Xianting Tian wrote:
virtio_config_enable(), virtio_config_disable() are only used inside
drivers/virtio/virtio.c, so it doesn't need export the symbols.
Signed-off-by: Xianting Tian
Acked-by: Jason Wang
---
drivers/virtio/virtio.c | 6 ++
include/linux/virtio.h | 2 --
2 files changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 42e09cc..4b15c00 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -141,15 +141,14 @@ void virtio_config_changed(struct virtio_device *dev)
}
EXPORT_SYMBOL_GPL(virtio_config_changed);
-void virtio_config_disable(struct virtio_device *dev)
+static void virtio_config_disable(struct virtio_device *dev)
{
spin_lock_irq(>config_lock);
dev->config_enabled = false;
spin_unlock_irq(>config_lock);
}
-EXPORT_SYMBOL_GPL(virtio_config_disable);
-void virtio_config_enable(struct virtio_device *dev)
+static void virtio_config_enable(struct virtio_device *dev)
{
spin_lock_irq(>config_lock);
dev->config_enabled = true;
@@ -158,7 +157,6 @@ void virtio_config_enable(struct virtio_device *dev)
dev->config_change_pending = false;
spin_unlock_irq(>config_lock);
}
-EXPORT_SYMBOL_GPL(virtio_config_enable);
void virtio_add_status(struct virtio_device *dev, unsigned int status)
{
diff --git a/include/linux/virtio.h b/include/linux/virtio.h
index 55ea329..b1894e0 100644
--- a/include/linux/virtio.h
+++ b/include/linux/virtio.h
@@ -132,8 +132,6 @@ static inline struct virtio_device *dev_to_virtio(struct
device *_dev)
void virtio_break_device(struct virtio_device *dev);
void virtio_config_changed(struct virtio_device *dev);
-void virtio_config_disable(struct virtio_device *dev);
-void virtio_config_enable(struct virtio_device *dev);
int virtio_finalize_features(struct virtio_device *dev);
#ifdef CONFIG_PM_SLEEP
int virtio_device_freeze(struct virtio_device *dev);
RE: [v2][PATCH] Revert "mfd: syscon: Don't free allocated name for regmap_config"
Hi Marc,
Is there any comment on this patch?
Could you please help to review this patch so that I can improve it if it still
has weakness?
Thanks,
Limeng
> -Original Message-
> From: Li, Meng
> Sent: Friday, January 15, 2021 9:51 AM
> To: linux-kernel@vger.kernel.org
> Cc: m...@kernel.org; lee.jo...@linaro.org; a...@arndb.de; Hao, Kexin
> ; Li, Meng
> Subject: [v2][PATCH] Revert "mfd: syscon: Don't free allocated name for
> regmap_config"
>
> From: Limeng
>
> This reverts commit 529a1101212a785c5df92c314b0e718287150c3b.
>
> The reverted patch moves the memory free to error path, but introduce a
> memory leak. There is another commit 94cc89eb8fa5("regmap: debugfs:
> Fix handling of name string for debugfs init delays") fixing this debugfs init
> issue from root cause. With this fixing, the name field in struct
> regmap_debugfs_node is removed. When initialize debugfs for syscon driver,
> the name field of struct regmap_config is not used anymore. So, revert this
> patch directly to avoid memory leak.
>
> v2:
> Notify the author of the reverted commit by adding Cc:
>
> Fixes: 529a1101212a("mfd: syscon: Don't free allocated name for
> regmap_config")
> Cc: Marc Zyngier
> Cc: sta...@vger.kernel.org
> Signed-off-by: Meng Li
> ---
> drivers/mfd/syscon.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/mfd/syscon.c b/drivers/mfd/syscon.c index
> ca465794ea9c..df5cebb372a5 100644
> --- a/drivers/mfd/syscon.c
> +++ b/drivers/mfd/syscon.c
> @@ -108,6 +108,7 @@ static struct syscon *of_syscon_register(struct
> device_node *np, bool check_clk)
> syscon_config.max_register = resource_size() - reg_io_width;
>
> regmap = regmap_init_mmio(NULL, base, _config);
> + kfree(syscon_config.name);
> if (IS_ERR(regmap)) {
> pr_err("regmap init failed\n");
> ret = PTR_ERR(regmap);
> @@ -144,7 +145,6 @@ static struct syscon *of_syscon_register(struct
> device_node *np, bool check_clk)
> regmap_exit(regmap);
> err_regmap:
> iounmap(base);
> - kfree(syscon_config.name);
> err_map:
> kfree(syscon);
> return ERR_PTR(ret);
> --
> 2.17.1
Re: [PATCH] virtio: don't prompt CONFIG_VIRTIO_PCI_MODERN
On 2021/2/19 11:38 下午, Guenter Roeck wrote:
On 2/19/21 12:45 AM, Jason Wang wrote:
We used to prompt CONFIG_VIRTIO_PCI_MODERN to user which may bring a
lot of confusion. E.g it may break various default configs which want
virtio devices.
So this patch fixes this by hide the prompot and document the
... by hiding the prompt and documenting ...
Hi Michael:
Would you like me to post a new version or you can fix those typos when
applying the patch?
Thanks
dependency.
Cc: Arnd Bergmann
Cc: Anders Roxell
Cc: Guenter Roeck
Reported-by: Naresh Kamboju
Fixes: 86b87c9d858b6 ("virtio-pci: introduce modern device module")
Signed-off-by: Jason Wang
Reviewed-by: Guenter Roeck
---
drivers/virtio/Kconfig | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/virtio/Kconfig b/drivers/virtio/Kconfig
index 6b9b81f4b8c2..be7df369bc2b 100644
--- a/drivers/virtio/Kconfig
+++ b/drivers/virtio/Kconfig
@@ -13,12 +13,12 @@ config ARCH_HAS_RESTRICTED_VIRTIO_MEMORY_ACCESS
VIRTIO_F_ACCESS_PLATFORM
config VIRTIO_PCI_MODERN
- tristate "Modern Virtio PCI Device"
- depends on PCI
+ tristate
help
Modern PCI device implementation. This module implements the
basic probe and control for devices which are based on modern
- PCI device with possible vendor specific extensions.
+ PCI device with possible vendor specific extensions. Any
+ module that selects this module must depend on PCI.
menuconfig VIRTIO_MENU
bool "Virtio drivers"
@@ -28,7 +28,8 @@ if VIRTIO_MENU
config VIRTIO_PCI
tristate "PCI driver for virtio devices"
- depends on VIRTIO_PCI_MODERN
+ depends on PCI
+ select VIRTIO_PCI_MODERN
select VIRTIO
help
This driver provides support for virtio based paravirtual device
