* RE: [PATCH 3/5] RDMA/irdma: Make the source udp port vary
From: Saleem, Shiraz @ 2022-01-05 15:40 UTC (permalink / raw)
To: yanjun.zhu@linux.dev, liangwenpeng@huawei.com, jgg@ziepe.ca,
Ismail, Mustafa, zyjzyj2000@gmail.com, linux-rdma@vger.kernel.org
In-Reply-To: <20220105221237.2659462-4-yanjun.zhu@linux.dev>
> Subject: [PATCH 3/5] RDMA/irdma: Make the source udp port vary
>
> From: Zhu Yanjun <yanjun.zhu@linux.dev>
>
> Get the source udp port number for a QP based on the grh.flow_label or
> lqpn/rqrpn. This provides a better spread of traffic across NIC RX queues.
>
> Signed-off-by: Zhu Yanjun <yanjun.zhu@linux.dev>
> ---
> drivers/infiniband/hw/irdma/verbs.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
Acked-by: Shiraz Saleem <shiraz.saleem@intel.com>
^ permalink raw reply
* RE: [PATCH 0/8] Support btime and other NFSv4 specific attributes
From: Ondrej Valousek @ 2022-01-05 15:40 UTC (permalink / raw)
To: bfields@fieldses.org, Ondrej Valousek
Cc: Trond Myklebust, trondmy@kernel.org, linux-nfs@vger.kernel.org,
anna.schumaker@netapp.com
In-Reply-To: <20220105151008.GB24685@fieldses.org>
>> - AFAIK support for RFC8276 in NFS (only version 4.2) server is since kernel 5.9, right? NFS client supports these as well?
>> - The patches below implements the feature in both, nfs client AND server, right?
> Client only.
Right, but then it will be only useful if we use non-linux based NFS server right?
I mean simply:
1. $ stat /tmp/foo.txt --> shows birth date
2. # exportfs \*/tmp
3. # mount 127.0.0.1:/tmp /mnt
4. $ stat /mnt/foo.txt --> no birth date shown
Legal Disclaimer: This e-mail communication (and any attachment/s) is confidential and contains proprietary information, some or all of which may be legally privileged. It is intended solely for the use of the individual or entity to which it is addressed. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.
^ permalink raw reply
* Re: [PATCH v2 0/1] KVM: Dirty quota-based throttling
From: Shivam Kumar @ 2022-01-05 15:39 UTC (permalink / raw)
To: Sean Christopherson; +Cc: pbonzini, kvm, agraf
In-Reply-To: <YdR9TSVgalKEfPIQ@google.com>
On 04/01/22 10:31 pm, Sean Christopherson wrote:
> On Mon, Jan 03, 2022, Shivam Kumar wrote:
>> I would be grateful if I could receive some feedback on the dirty quota v2
>> patchset.
> 'Twas the week before Christmas, when all through the list,
> not a reviewer was stirring, not even a twit.
>
> There's a reason I got into programming and not literature. Anyways, your patch
> is in the review queue, it'll just be a few days/weeks. :-)
Thank you so much Sean for the update!
^ permalink raw reply
* pull-request: ieee802154 for net 2022-01-05
From: Stefan Schmidt @ 2022-01-05 15:39 UTC (permalink / raw)
To: davem, kuba; +Cc: linux-wpan, alex.aring, netdev
Hello Dave, Jakub.
An update from ieee802154 for your *net* tree.
Below I have a last minute fix for the atusb driver.
Pavel fixes a KASAN uninit report for the driver. This version is the
minimal impact fix to ease backporting. A bigger rework of the driver to
avoid potential similar problems is ongoing and will come through net-next
when ready.
regards
Stefan Schmidt
The following changes since commit 7d18a07897d07495ee140dd319b0e9265c0f68ba:
sch_qfq: prevent shift-out-of-bounds in qfq_init_qdisc (2022-01-04 12:36:51 +0000)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/sschmidt/wpan.git tags/ieee802154-for-net-2022-01-05
for you to fetch changes up to 754e4382354f7908923a1949d8dc8d05f82f09cb:
ieee802154: atusb: fix uninit value in atusb_set_extended_addr (2022-01-04 20:10:04 +0100)
----------------------------------------------------------------
Pavel Skripkin (1):
ieee802154: atusb: fix uninit value in atusb_set_extended_addr
drivers/net/ieee802154/atusb.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCH v2 6/6] input: zinitix: Add touchkey support
From: kernel test robot @ 2022-01-05 15:38 UTC (permalink / raw)
To: Nikita Travkin, dmitry.torokhov
Cc: kbuild-all, robh+dt, Michael.Srba, linus.walleij, broonie, luca,
linux-input, devicetree, phone-devel, linux-kernel
In-Reply-To: <20220105060323.7928-7-nikita@trvn.ru>
Hi Nikita,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on robh/for-next hid/for-next linus/master v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nikita-Travkin/Add-touch-keys-support-to-the-Zinitix-touch-driver/20220105-140610
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: powerpc-randconfig-s031-20220105 (https://download.01.org/0day-ci/archive/20220105/202201052355.c806rw3s-lkp@intel.com/config)
compiler: powerpc-linux-gcc (GCC) 11.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://github.com/0day-ci/linux/commit/545e0de93da58f29350c2908498a4621f5ef59e4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nikita-Travkin/Add-touch-keys-support-to-the-Zinitix-touch-driver/20220105-140610
git checkout 545e0de93da58f29350c2908498a4621f5ef59e4
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/ata/ drivers/input/touchscreen/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/input/touchscreen/zinitix.c:371:24: sparse: sparse: restricted __le16 degrades to integer
vim +371 drivers/input/touchscreen/zinitix.c
352
353 static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
354 {
355 struct bt541_ts_data *bt541 = bt541_handler;
356 struct i2c_client *client = bt541->client;
357 struct touch_event touch_event;
358 int error;
359 int i;
360 __le16 icon_events = 0;
361
362 memset(&touch_event, 0, sizeof(struct touch_event));
363
364 error = zinitix_read_data(bt541->client, BT541_POINT_STATUS_REG,
365 &touch_event, sizeof(struct touch_event));
366 if (error) {
367 dev_err(&client->dev, "Failed to read in touchpoint struct\n");
368 goto out;
369 }
370
> 371 if (touch_event.status & BIT_ICON_EVENT) {
372 error = zinitix_read_data(bt541->client, BT541_ICON_STATUS_REG,
373 &icon_events, sizeof(icon_events));
374 if (error) {
375 dev_err(&client->dev, "Failed to read icon events\n");
376 goto out;
377 }
378
379 zinitix_report_keys(bt541, le16_to_cpu(icon_events));
380 }
381
382 for (i = 0; i < MAX_SUPPORTED_FINGER_NUM; i++)
383 if (touch_event.point_coord[i].sub_status & SUB_BIT_EXIST)
384 zinitix_report_finger(bt541, i,
385 &touch_event.point_coord[i]);
386
387 input_mt_sync_frame(bt541->input_dev);
388 input_sync(bt541->input_dev);
389
390 out:
391 zinitix_write_cmd(bt541->client, BT541_CLEAR_INT_STATUS_CMD);
392 return IRQ_HANDLED;
393 }
394
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
^ permalink raw reply
* Re: [PATCH] mtd: nand: pxa3xx: set mtd->dev
From: Stefan Roese @ 2022-01-05 15:38 UTC (permalink / raw)
To: Robert Marko, u-boot, marek.behun, pali
In-Reply-To: <20220105150100.336958-1-robert.marko@sartura.hr>
On 1/5/22 16:01, Robert Marko wrote:
> Currently the pxa3xx driver does not set the udevice in the mtd_info
> struct and this prevents the mtd from parsing the partitions via DTS
> like for SPI-NOR.
>
> So simply set the mtd->dev to the driver udevice.
>
> Signed-off-by: Robert Marko <robert.marko@sartura.hr>
Reviewed-by: Stefan Roese <sr@denx.de>
Thanks,
Stefan
> ---
> drivers/mtd/nand/raw/pxa3xx_nand.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c b/drivers/mtd/nand/raw/pxa3xx_nand.c
> index 8ff58a7038..eb739bb3b9 100644
> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> @@ -1913,6 +1913,7 @@ static int pxa3xx_nand_probe(struct udevice *dev)
> * user's mtd partitions configuration would get broken.
> */
> mtd->name = "pxa3xx_nand-0";
> + mtd->dev = dev;
> info->cs = cs;
> ret = pxa3xx_nand_scan(mtd);
> if (ret) {
>
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de
^ permalink raw reply
* Re: [PATCH v2 6/6] input: zinitix: Add touchkey support
From: kernel test robot @ 2022-01-05 15:38 UTC (permalink / raw)
To: kbuild-all
In-Reply-To: <20220105060323.7928-7-nikita@trvn.ru>
[-- Attachment #1: Type: text/plain, Size: 3587 bytes --]
Hi Nikita,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on dtor-input/next]
[also build test WARNING on robh/for-next hid/for-next linus/master v5.16-rc8 next-20220105]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url: https://github.com/0day-ci/linux/commits/Nikita-Travkin/Add-touch-keys-support-to-the-Zinitix-touch-driver/20220105-140610
base: https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: powerpc-randconfig-s031-20220105 (https://download.01.org/0day-ci/archive/20220105/202201052355.c806rw3s-lkp(a)intel.com/config)
compiler: powerpc-linux-gcc (GCC) 11.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# apt-get install sparse
# sparse version: v0.6.4-dirty
# https://github.com/0day-ci/linux/commit/545e0de93da58f29350c2908498a4621f5ef59e4
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review Nikita-Travkin/Add-touch-keys-support-to-the-Zinitix-touch-driver/20220105-140610
git checkout 545e0de93da58f29350c2908498a4621f5ef59e4
# save the config file to linux build tree
mkdir build_dir
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-11.2.0 make.cross C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' O=build_dir ARCH=powerpc SHELL=/bin/bash drivers/ata/ drivers/input/touchscreen/
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>
sparse warnings: (new ones prefixed by >>)
>> drivers/input/touchscreen/zinitix.c:371:24: sparse: sparse: restricted __le16 degrades to integer
vim +371 drivers/input/touchscreen/zinitix.c
352
353 static irqreturn_t zinitix_ts_irq_handler(int irq, void *bt541_handler)
354 {
355 struct bt541_ts_data *bt541 = bt541_handler;
356 struct i2c_client *client = bt541->client;
357 struct touch_event touch_event;
358 int error;
359 int i;
360 __le16 icon_events = 0;
361
362 memset(&touch_event, 0, sizeof(struct touch_event));
363
364 error = zinitix_read_data(bt541->client, BT541_POINT_STATUS_REG,
365 &touch_event, sizeof(struct touch_event));
366 if (error) {
367 dev_err(&client->dev, "Failed to read in touchpoint struct\n");
368 goto out;
369 }
370
> 371 if (touch_event.status & BIT_ICON_EVENT) {
372 error = zinitix_read_data(bt541->client, BT541_ICON_STATUS_REG,
373 &icon_events, sizeof(icon_events));
374 if (error) {
375 dev_err(&client->dev, "Failed to read icon events\n");
376 goto out;
377 }
378
379 zinitix_report_keys(bt541, le16_to_cpu(icon_events));
380 }
381
382 for (i = 0; i < MAX_SUPPORTED_FINGER_NUM; i++)
383 if (touch_event.point_coord[i].sub_status & SUB_BIT_EXIST)
384 zinitix_report_finger(bt541, i,
385 &touch_event.point_coord[i]);
386
387 input_mt_sync_frame(bt541->input_dev);
388 input_sync(bt541->input_dev);
389
390 out:
391 zinitix_write_cmd(bt541->client, BT541_CLEAR_INT_STATUS_CMD);
392 return IRQ_HANDLED;
393 }
394
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
^ permalink raw reply
* [PATCH v4 2/2] ahci: AMD A85 FCH (Hudson D4): Skip 200 ms debounce delay in `sata_link_resume()`
From: Paul Menzel @ 2022-01-05 15:36 UTC (permalink / raw)
To: Damien Le Moal; +Cc: Paul Menzel, Tejun Heo, linux-ide, linux-kernel
In-Reply-To: <20220105153618.2395-1-pmenzel@molgen.mpg.de>
Commit 4effb658a0 from October 2003 [1, historical git archive] with the
commit message
> [libata] Merge Serial ATA core, and drivers for:
>
> Intel ICH5 (production)
> ServerWorks / Apple K2 (beta)
> VIA (beta)
> Silicon Image 3112 (broken!)
> Various Promise (alpha/beta)
adds the code below:
void sata_phy_reset(struct ata_port *ap)
{
[…]
/* wait for phy to become ready, if necessary */
do {
msleep(200);
sstatus = scr_read(ap, SCR_STATUS);
if ((sstatus & 0xf) != 1)
break;
} while (time_before(jiffies, timeout));
[…]
}
Later on in commit d7bb4cc75759 ([PATCH] libata-hp-prep: implement
sata_phy_debounce()) the commit is refactored [2], and the comment
clarified.
/*
* Writes to SControl sometimes get ignored under certain
* controllers (ata_piix SIDPR). Make sure DET actually is
* cleared.
*/
do {
scontrol = (scontrol & 0x0f0) | 0x300;
if ((rc = sata_scr_write(link, SCR_CONTROL, scontrol)))
return rc;
/*
* Some PHYs react badly if SStatus is pounded
* immediately after resuming. Delay 200ms before
* debouncing.
*/
if (!(link->flags & ATA_LFLAG_NO_DEBOUNCE_DELAY))
ata_msleep(link->ap, 200);
/* is SControl restored correctly? */
if ((rc = sata_scr_read(link, SCR_CONTROL, &scontrol)))
return rc;
} while ((scontrol & 0xf0f) != 0x300 && --tries);
A lot of PHYs do not need a delay though, so delaying 200 ms increases
the boot time by 30 percent unnecessarily for a lot of systems, making
“instant booting” quite hard.
As it’s unknown for what PHY the delay was added, create a new board
`board_ahci_no_debounce_delay` with the link flag
`ATA_LFLAG_NO_DEBOUNCE_DELAY,`, and, for now, configure the AMD A85 FCH
(Hudson D4) to use it.
On the ASUS F2A85-M PRO it reduces the Linux kernel boot time by the
expected 200 ms from 787 ms to 585 ms.
Tested on ASUS F2A85-M PRO:
Without patch, i. e., with 200 ms debounce delay:
[…]
[ 0.000000] DMI: ASUS F2A85-M_PRO/F2A85-M_PRO, BIOS 4.15-671-g7b043ef855 12/27/2021
[…]
[ 0.404885] ahci 0000:00:11.0: version 3.0
[ 0.405466] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 8 ports 6 Gbps 0x40 impl SATA mode
[ 0.405470] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck led clo pio
[ 0.408036] scsi host0: ahci
[ 0.408537] scsi host1: ahci
[ 0.408932] scsi host2: ahci
[ 0.409444] scsi host3: ahci
[ 0.409841] scsi host4: ahci
[ 0.410266] scsi host5: ahci
[ 0.410661] scsi host6: ahci
[ 0.411052] scsi host7: ahci
[ 0.411284] ata1: DUMMY
[ 0.411286] ata2: DUMMY
[ 0.411286] ata3: DUMMY
[ 0.411287] ata4: DUMMY
[ 0.411288] ata5: DUMMY
[ 0.411289] ata6: DUMMY
[ 0.411291] ata7: SATA max UDMA/133 abar m2048@0xf01cc000 port 0xf01cc400 irq 19
[ 0.411292] ata8: DUMMY
[…]
[ 0.422362] Key type encrypted registered
[ 0.424903] PM: Magic number: 1:28:636
[ 0.723979] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 0.724268] ata7.00: ATA-9: SanDisk SDSSDP064G, 2.0.0, max UDMA/133
[ 0.724271] ata7.00: 125045424 sectors, multi 1: LBA48 NCQ (depth 32)
[ 0.725537] ata7.00: configured for UDMA/133
[ 0.725898] scsi 6:0:0:0: Direct-Access ATA SanDisk SDSSDP06 0 PQ: 0 ANSI: 5
[ 0.726428] sd 6:0:0:0: [sda] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
[ 0.726442] sd 6:0:0:0: [sda] Write Protect is off
[ 0.726446] sd 6:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 0.726464] sd 6:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 0.727985] sda: sda1 sda2 sda3
[ 0.728588] sd 6:0:0:0: [sda] Attached SCSI disk
[ 0.738495] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[…]
[ 0.786812] Run /sbin/init as init process
With patch, i. e., skipping the debounce delay saves 200 ms from the boot
as expected.
[…]
[ 0.000000] DMI: ASUS F2A85-M_PRO/F2A85-M_PRO, BIOS 4.15-671-g7b043ef855 12/27/2021
[…]
[ 0.407372] ahci 0000:00:11.0: version 3.0
[ 0.407909] ahci 0000:00:11.0: AHCI 0001.0300 32 slots 8 ports 6 Gbps 0x40 impl SATA mode
[ 0.407913] ahci 0000:00:11.0: flags: 64bit ncq sntf ilck led clo pio
[ 0.410520] scsi host0: ahci
[ 0.411017] scsi host1: ahci
[ 0.411418] scsi host2: ahci
[ 0.411810] scsi host3: ahci
[ 0.412225] scsi host4: ahci
[ 0.412614] scsi host5: ahci
[ 0.413005] scsi host6: ahci
[ 0.413488] scsi host7: ahci
[ 0.413713] ata1: DUMMY
[ 0.413715] ata2: DUMMY
[ 0.413716] ata3: DUMMY
[ 0.413716] ata4: DUMMY
[ 0.413717] ata5: DUMMY
[ 0.413718] ata6: DUMMY
[ 0.413720] ata7: SATA max UDMA/133 abar m2048@0xf01cc000 port 0xf01cc400 irq 19
[ 0.413722] ata8: DUMMY
[…]
[ 0.425414] Key type encrypted registered
[ 0.427873] PM: Magic number: 1:234:838
[ 0.522131] ata7: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 0.522415] ata7.00: ATA-9: SanDisk SDSSDP064G, 2.0.0, max UDMA/133
[ 0.522418] ata7.00: 125045424 sectors, multi 1: LBA48 NCQ (depth 32)
[ 0.523636] ata7.00: configured for UDMA/133
[ 0.523993] scsi 6:0:0:0: Direct-Access ATA SanDisk SDSSDP06 0 PQ: 0 ANSI: 5
[ 0.524497] sd 6:0:0:0: [sda] 125045424 512-byte logical blocks: (64.0 GB/59.6 GiB)
[ 0.524511] sd 6:0:0:0: [sda] Write Protect is off
[ 0.524515] sd 6:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 0.524534] sd 6:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 0.525953] sda: sda1 sda2 sda3
[ 0.526541] sd 6:0:0:0: [sda] Attached SCSI disk
[ 0.536245] EXT4-fs (sda3): mounted filesystem with ordered data mode. Opts: (null). Quota mode: none.
[…]
[ 0.585327] Run /sbin/init as init process
[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=4effb658a0f800e159c29a2d881cac76c326087a
[2]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d7bb4cc7575929a60b0a718daa1bce87bea9a9cc
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
Cc: Tejun Heo <tj@kernel.org>
---
v4:
1. Use 0x7801 instead of macros
2. Use clearer name `no_debounce_delay` over `nodbdelay`
3. Provide more history in commit message
drivers/ata/ahci.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 1e1167e725a40..836b763c640fc 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -51,6 +51,7 @@ enum board_ids {
board_ahci,
board_ahci_ign_iferr,
board_ahci_mobile,
+ board_ahci_no_debounce_delay,
board_ahci_nomsi,
board_ahci_noncq,
board_ahci_nosntf,
@@ -141,6 +142,13 @@ static const struct ata_port_info ahci_port_info[] = {
.udma_mask = ATA_UDMA6,
.port_ops = &ahci_ops,
},
+ [board_ahci_no_debounce_delay] = {
+ .flags = AHCI_FLAG_COMMON,
+ .link_flags = ATA_LFLAG_NO_DEBOUNCE_DELAY,
+ .pio_mask = ATA_PIO4,
+ .udma_mask = ATA_UDMA6,
+ .port_ops = &ahci_ops,
+ },
[board_ahci_nomsi] = {
AHCI_HFLAGS (AHCI_HFLAG_NO_MSI),
.flags = AHCI_FLAG_COMMON,
@@ -437,6 +445,7 @@ static const struct pci_device_id ahci_pci_tbl[] = {
board_ahci_al },
/* AMD */
{ PCI_VDEVICE(AMD, 0x7800), board_ahci }, /* AMD Hudson-2 */
+ { PCI_VDEVICE(AMD, 0x7801), board_ahci_no_debounce_delay }, /* AMD Hudson-2 (AHCI mode) */
{ PCI_VDEVICE(AMD, 0x7900), board_ahci }, /* AMD CZ */
{ PCI_VDEVICE(AMD, 0x7901), board_ahci_mobile }, /* AMD Green Sardine */
/* AMD is using RAID class only for ahci controllers */
--
2.30.2
^ permalink raw reply related
* [syzbot] WARNING in signalfd_cleanup
From: syzbot @ 2022-01-05 15:37 UTC (permalink / raw)
To: changbin.du, daniel, davem, edumazet, hkallweit1, kuba,
linux-fsdevel, linux-kernel, netdev, syzkaller-bugs, viro,
yajun.deng
Hello,
syzbot found the following issue on:
HEAD commit: 6b8d4927540e Add linux-next specific files for 20220104
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=159d88e3b00000
kernel config: https://syzkaller.appspot.com/x/.config?x=45c9bbbf2ae8e3d3
dashboard link: https://syzkaller.appspot.com/bug?extid=5426c7ed6868c705ca14
compiler: gcc (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=117be65db00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15a75c8db00000
The issue was bisected to:
commit e4b8954074f6d0db01c8c97d338a67f9389c042f
Author: Eric Dumazet <edumazet@google.com>
Date: Tue Dec 7 01:30:37 2021 +0000
netlink: add net device refcount tracker to struct ethnl_req_info
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=12bca4e3b00000
final oops: https://syzkaller.appspot.com/x/report.txt?x=11bca4e3b00000
console output: https://syzkaller.appspot.com/x/log.txt?x=16bca4e3b00000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+5426c7ed6868c705ca14@syzkaller.appspotmail.com
Fixes: e4b8954074f6 ("netlink: add net device refcount tracker to struct ethnl_req_info")
------------[ cut here ]------------
WARNING: CPU: 0 PID: 3604 at kernel/sched/wait.c:245 __wake_up_pollfree+0x40/0x50 kernel/sched/wait.c:246
Modules linked in:
CPU: 0 PID: 3604 Comm: syz-executor714 Not tainted 5.16.0-rc8-next-20220104-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__wake_up_pollfree+0x40/0x50 kernel/sched/wait.c:245
Code: f3 ff ff 48 8d 6b 40 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 80 3c 02 00 75 11 48 8b 43 40 48 39 c5 75 03 5b 5d c3 <0f> 0b 5b 5d c3 48 89 ef e8 13 d8 69 00 eb e5 cc 48 c1 e7 06 48 63
RSP: 0018:ffffc90001aaf9f8 EFLAGS: 00010083
RAX: ffff88801cd623f0 RBX: ffff88801bec8048 RCX: 0000000000000000
RDX: 1ffff110037d9011 RSI: 0000000000000004 RDI: 0000000000000001
RBP: ffff88801bec8088 R08: 0000000000000000 R09: ffff88801bec804b
R10: ffffed10037d9009 R11: 0000000000000000 R12: ffff88801bec8040
R13: ffff88801e029d40 R14: dffffc0000000000 R15: ffff88807eb50000
FS: 00005555573ad300(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000200000c0 CR3: 000000001e5e4000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
wake_up_pollfree include/linux/wait.h:271 [inline]
signalfd_cleanup+0x42/0x60 fs/signalfd.c:38
__cleanup_sighand kernel/fork.c:1596 [inline]
__cleanup_sighand+0x72/0xb0 kernel/fork.c:1593
__exit_signal kernel/exit.c:159 [inline]
release_task+0xc02/0x17e0 kernel/exit.c:200
wait_task_zombie kernel/exit.c:1117 [inline]
wait_consider_task+0x2fa6/0x3b80 kernel/exit.c:1344
do_wait_thread kernel/exit.c:1407 [inline]
do_wait+0x6ca/0xce0 kernel/exit.c:1524
kernel_wait4+0x14c/0x260 kernel/exit.c:1687
__do_sys_wait4+0x13f/0x150 kernel/exit.c:1715
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7facd6682386
Code: 0f 1f 40 00 31 c9 e9 09 00 00 00 66 0f 1f 84 00 00 00 00 00 49 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 11 b8 3d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 5a c3 90 48 83 ec 28 89 54 24 14 48 89 74 24
RSP: 002b:00007ffdb91adef8 EFLAGS: 00000246 ORIG_RAX: 000000000000003d
RAX: ffffffffffffffda RBX: 000000000000c646 RCX: 00007facd6682386
RDX: 0000000040000001 RSI: 00007ffdb91adf14 RDI: 00000000ffffffff
RBP: 0000000000000f17 R08: 0000000000000032 R09: 00007ffdb91ec080
R10: 0000000000000000 R11: 0000000000000246 R12: 431bde82d7b634db
R13: 00007ffdb91adf14 R14: 0000000000000000 R15: 0000000000000000
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
syzbot can test patches for this issue, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH] drm: omapdrm: Fix implicit dma_buf fencing
From: Ivaylo Dimitrov @ 2022-01-05 15:36 UTC (permalink / raw)
To: tomba, sumit.semwal, christian.koenig
Cc: openpvrsgx-devgroup, merlijn, philipp, airlied, daniel, dri-devel,
linux-kernel, linux-media, linux-omap, Ivaylo Dimitrov
Currently omapdrm driver does not initialize dma_buf_export_info resv
member, which leads to a new dma_resv being allocated and attached to
the exported dma_buf. This leads to the issue that fences created on
dma_buf objects imported by other drivers are ignored by omapdrm, as only
fences in gem object resv are waited on. This leads to various issues like
displaying incomplete frames.
Fix that by initializing dma_buf resv to the resv of the gem object being
exported.
Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
index f1f93cabb61e..a111e5c91925 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c
@@ -88,6 +88,7 @@ struct dma_buf *omap_gem_prime_export(struct drm_gem_object *obj, int flags)
exp_info.size = omap_gem_mmap_size(obj);
exp_info.flags = flags;
exp_info.priv = obj;
+ exp_info.resv = obj->resv;
return drm_gem_dmabuf_export(obj->dev, &exp_info);
}
--
2.20.1
^ permalink raw reply related
* Re: [PATCHv2 for-next 5/5] RDMA/rtrs-clt: Rename rtrs_clt to rtrs_clt_sess
From: Vaishali Thakkar @ 2022-01-05 15:36 UTC (permalink / raw)
To: Guoqing Jiang; +Cc: Jack Wang, linux-rdma, bvanassche, leon, jgg, haris.iqbal
In-Reply-To: <c6289d43-1593-39c8-2869-2098ec3defd0@linux.dev>
On Tue, Jan 4, 2022 at 8:09 AM Guoqing Jiang <guoqing.jiang@linux.dev> wrote:
>
>
>
> On 1/3/22 9:33 PM, Jack Wang wrote:
> > From: Vaishali Thakkar<vaishali.thakkar@ionos.com>
> >
> > Structure rtrs_clt is used for sessions. So to
> > avoid confusions rename it to rtrs_clt_sess.
> >
> > Transformations are done with the help of
> > following coccinelle script.
> >
> > @@
> > @@
> > struct
> > - rtrs_clt
> > + rtrs_clt_sess
> >
> > Signed-off-by: Vaishali Thakkar<vaishali.thakkar@ionos.com>
> > Signed-off-by: Jack Wang<jinpu.wang@ionos.com>
> > ---
> > drivers/block/rnbd/rnbd-clt.c | 4 +-
> > drivers/block/rnbd/rnbd-clt.h | 2 +-
> > drivers/infiniband/ulp/rtrs/rtrs-clt-sysfs.c | 24 +++---
> > drivers/infiniband/ulp/rtrs/rtrs-clt.c | 78 ++++++++++----------
> > drivers/infiniband/ulp/rtrs/rtrs-clt.h | 19 ++---
> > drivers/infiniband/ulp/rtrs/rtrs.h | 21 +++---
> > 6 files changed, 77 insertions(+), 71 deletions(-)
> >
> > diff --git a/drivers/block/rnbd/rnbd-clt.c b/drivers/block/rnbd/rnbd-clt.c
> > index 2df0657cdf00..70bbbdb81db1 100644
> > --- a/drivers/block/rnbd/rnbd-clt.c
> > +++ b/drivers/block/rnbd/rnbd-clt.c
> > @@ -433,7 +433,7 @@ static void msg_conf(void *priv, int errno)
> > schedule_work(&iu->work);
> > }
> >
> > -static int send_usr_msg(struct rtrs_clt *rtrs, int dir,
> > +static int send_usr_msg(struct rtrs_clt_sess *rtrs, int dir,
> > struct rnbd_iu *iu, struct kvec *vec,
> > size_t len, struct scatterlist *sg, unsigned int sg_len,
> > void (*conf)(struct work_struct *work),
> > @@ -1010,7 +1010,7 @@ static int rnbd_client_xfer_request(struct rnbd_clt_dev *dev,
> > struct request *rq,
> > struct rnbd_iu *iu)
> > {
> > - struct rtrs_clt *rtrs = dev->sess->rtrs;
> > + struct rtrs_clt_sess *rtrs = dev->sess->rtrs;
> > struct rtrs_permit *permit = iu->permit;
> > struct rnbd_msg_io msg;
> > struct rtrs_clt_req_ops req_ops;
> > diff --git a/drivers/block/rnbd/rnbd-clt.h b/drivers/block/rnbd/rnbd-clt.h
> > index 9ef8c4f306f2..0c2cae7f39b9 100644
> > --- a/drivers/block/rnbd/rnbd-clt.h
> > +++ b/drivers/block/rnbd/rnbd-clt.h
> > @@ -75,7 +75,7 @@ struct rnbd_cpu_qlist {
> >
> > struct rnbd_clt_session {
> > struct list_head list;
> > - struct rtrs_clt *rtrs;
> > + struct rtrs_clt_sess *rtrs;
>
> While at it, how about change it to clt_sess? Otherwise there is symbol name
> pollution between rnbd_clt_session and rnbd_srv_session.
>
> [ ...]
>
> > /*
> > @@ -743,7 +744,7 @@ static int post_recv_path(struct rtrs_clt_path *clt_path)
> > struct path_it {
> > int i;
> > struct list_head skip_list;
> > - struct rtrs_clt *clt;
> > + struct rtrs_clt_sess *clt;
>
> To align with the change of type, s/clt/clt_sess? If so, it applies to
> others as well.
>
> [ ... ]
>
> > --- a/drivers/infiniband/ulp/rtrs/rtrs-clt.h
> > +++ b/drivers/infiniband/ulp/rtrs/rtrs-clt.h
> > @@ -126,7 +126,7 @@ struct rtrs_rbuf {
> >
> > struct rtrs_clt_path {
> > struct rtrs_path s;
> > - struct rtrs_clt *clt;
> > + struct rtrs_clt_sess **clt*;
>
> Ditto.
>
> [ ... ]
>
> > -struct rtrs_clt *rtrs_clt_open(struct rtrs_clt_ops *ops,
> > +struct rtrs_clt_sess *rtrs_clt_open(struct rtrs_clt_ops *ops,
> > const char *pathname,
> > const struct rtrs_addr *paths,
> > size_t path_cnt, u16 port,
> > size_t pdu_sz, u8 reconnect_delay_sec,
> > s16 max_reconnect_attempts, u32 nr_poll_queues);
> >
> > -void rtrs_clt_close(struct rtrs_clt *clt_path);
> > +void rtrs_clt_close(struct rtrs_clt_sess *clt_path);
>
> void rtrs_clt_close(struct rtrs_clt_sess *clt_sess);
>
> or
>
> void rtrs_clt_close(struct rtrs_clt_path *clt_path);
Good catch. Actually this should be
void rtrs_clt_close(struct rtrs_clt_sess *clt);
>
> Maybe rename those functions to rtrs_clt_session_{open,close} to resolve
> the ambiguous
> completely, or we can live with current name I am not sure.
For this series, I think we can live with the current name. :)
> BTW, I suppose the series deserve beer from Danil 😉
:)
> Thanks,
> Guoqing
>
^ permalink raw reply
* RE: [PATCH] drivers:iio:dac make expression evaluation 64-bit
From: Sa, Nuno @ 2022-01-05 15:36 UTC (permalink / raw)
To: Dan Carpenter, Muhammad Usama Anjum
Cc: Lars-Peter Clausen, Hennerich, Michael, Jonathan Cameron,
Chindris, Mihail, open list:IIO SUBSYSTEM AND DRIVERS, open list,
kernel@collabora.com, kernel-janitors@vger.kernel.org
In-Reply-To: <20220105133902.GD7674@kadam>
> From: Dan Carpenter <dan.carpenter@oracle.com>
> Sent: Wednesday, January 5, 2022 2:39 PM
> To: Muhammad Usama Anjum <usama.anjum@collabora.com>
> Cc: Lars-Peter Clausen <lars@metafoo.de>; Hennerich, Michael
> <Michael.Hennerich@analog.com>; Jonathan Cameron
> <jic23@kernel.org>; Chindris, Mihail <Mihail.Chindris@analog.com>;
> open list:IIO SUBSYSTEM AND DRIVERS <linux-iio@vger.kernel.org>;
> open list <linux-kernel@vger.kernel.org>; kernel@collabora.com;
> kernel-janitors@vger.kernel.org
> Subject: Re: [PATCH] drivers:iio:dac make expression evaluation 64-bit
>
> [External]
>
> On Wed, Dec 22, 2021 at 12:20:32AM +0500, Muhammad Usama Anjum
> wrote:
> > Two 32-bit values are being evaluated using 32-bit arithmetic and
> then
> > passed to s64 type. It is wrong. Expression should be evaluated using
> > 64-bit arithmetic and then passed.
> >
> > Fixes: 8f2b54824b ("drivers:iio:dac: Add AD3552R driver support")
> > Signed-off-by: Muhammad Usama Anjum
> <usama.anjum@collabora.com>
> > ---
> > drivers/iio/dac/ad3552r.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/iio/dac/ad3552r.c b/drivers/iio/dac/ad3552r.c
> > index 97f13c0b9631..b03d3c7cd4c4 100644
> > --- a/drivers/iio/dac/ad3552r.c
> > +++ b/drivers/iio/dac/ad3552r.c
> > @@ -770,7 +770,7 @@ static void
> ad3552r_calc_gain_and_offset(struct ad3552r_desc *dac, s32 ch)
> > dac->ch_data[ch].scale_dec = DIV_ROUND_CLOSEST((s64)rem
> * 1000000,
> > 65536);
> >
> > - dac->ch_data[ch].offset_int = div_s64_rem(v_min * 65536,
> span, &rem);
> > + dac->ch_data[ch].offset_int = div_s64_rem(v_min * 65536L,
> span, &rem);
>
> "v_min" is relatively close to zero on a number line so this can't
> overflow. There is no way that this change affects anything at runtime
> (except making the code a tiny tiny bit slower).
>
> And it should be 65536LL for 32 bit systems?
>
If I'm not missing nothing obvious, 65536LL is the right thing to do...
I did not really checked, but if v_min * 65536 can never overflow,
then yeah, this is not really "fixing" nothing.
- Nuno Sá
^ permalink raw reply
* [PATCH v4 1/2] ahci: Rename flag `ATA_LFLAG_NO_DB_DELAY` to `ATA_LFLAG_NO_DEBOUNCE_DELAY`
From: Paul Menzel @ 2022-01-05 15:36 UTC (permalink / raw)
To: Damien Le Moal; +Cc: Paul Menzel, linux-ide, linux-kernel
The new name is longer, but clearer.
Signed-off-by: Paul Menzel <pmenzel@molgen.mpg.de>
---
drivers/ata/ahci_brcm.c | 2 +-
drivers/ata/libata-sata.c | 2 +-
include/linux/libata.h | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/ata/ahci_brcm.c b/drivers/ata/ahci_brcm.c
index 6e9c5ade4c2ea..649815c196ed0 100644
--- a/drivers/ata/ahci_brcm.c
+++ b/drivers/ata/ahci_brcm.c
@@ -333,7 +333,7 @@ static struct ata_port_operations ahci_brcm_platform_ops = {
static const struct ata_port_info ahci_brcm_port_info = {
.flags = AHCI_FLAG_COMMON | ATA_FLAG_NO_DIPM,
- .link_flags = ATA_LFLAG_NO_DB_DELAY,
+ .link_flags = ATA_LFLAG_NO_DEBOUNCE_DELAY,
.pio_mask = ATA_PIO4,
.udma_mask = ATA_UDMA6,
.port_ops = &ahci_brcm_platform_ops,
diff --git a/drivers/ata/libata-sata.c b/drivers/ata/libata-sata.c
index b9c77885b8726..67b2e7cf3cc4e 100644
--- a/drivers/ata/libata-sata.c
+++ b/drivers/ata/libata-sata.c
@@ -317,7 +317,7 @@ int sata_link_resume(struct ata_link *link, const unsigned long *params,
* immediately after resuming. Delay 200ms before
* debouncing.
*/
- if (!(link->flags & ATA_LFLAG_NO_DB_DELAY))
+ if (!(link->flags & ATA_LFLAG_NO_DEBOUNCE_DELAY))
ata_msleep(link->ap, 200);
/* is SControl restored correctly? */
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 2a8404b26083c..15802e644962d 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -191,7 +191,7 @@ enum {
ATA_LFLAG_NO_LPM = (1 << 8), /* disable LPM on this link */
ATA_LFLAG_RST_ONCE = (1 << 9), /* limit recovery to one reset */
ATA_LFLAG_CHANGED = (1 << 10), /* LPM state changed on this link */
- ATA_LFLAG_NO_DB_DELAY = (1 << 11), /* no debounce delay on link resume */
+ ATA_LFLAG_NO_DEBOUNCE_DELAY = (1 << 11), /* no debounce delay on link resume */
/* struct ata_port flags */
ATA_FLAG_SLAVE_POSS = (1 << 0), /* host supports slave dev */
--
2.30.2
^ permalink raw reply related
* Re: [PATCH linux] nfs: Remove unnecessary ret assignment
From: Anna Schumaker @ 2022-01-05 15:36 UTC (permalink / raw)
To: cgel.zte
Cc: Trond Myklebust, Linux NFS Mailing List,
Linux Kernel Mailing List, luo penghao, Zeal Robot
In-Reply-To: <20211230063444.586292-1-luo.penghao@zte.com.cn>
Hi Luo,
On Fri, Dec 31, 2021 at 5:05 AM <cgel.zte@gmail.com> wrote:
>
> From: luo penghao <luo.penghao@zte.com.cn>
>
> Subsequent if judgments will assign new values to ret, so the
> statement here should be deleted
>
> The clang_analyzer complains as follows:
>
> fs/nfs/callback.c:
>
> Value stored to 'ret' is never read
The "else if (xprt->ops->bc_setup)" branch doesn't touch 'ret', so it
seems to me like the clang_analyzer is falsely reporting this.
Thanks,
Anna
>
> Reported-by: Zeal Robot <zealci@zte.com.cn>
> Signed-off-by: luo penghao <luo.penghao@zte.com.cn>
> ---
> fs/nfs/callback.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/fs/nfs/callback.c b/fs/nfs/callback.c
> index 86d856d..1c1c82a 100644
> --- a/fs/nfs/callback.c
> +++ b/fs/nfs/callback.c
> @@ -209,7 +209,6 @@ static int nfs_callback_up_net(int minorversion, struct svc_serv *serv,
> goto err_bind;
> }
>
> - ret = 0;
> if (!IS_ENABLED(CONFIG_NFS_V4_1) || minorversion == 0)
> ret = nfs4_callback_up_net(serv, net);
> else if (xprt->ops->bc_setup)
> --
> 2.15.2
>
>
^ permalink raw reply
* Re: [PATCH dt + pci 1/2] dt-bindings: Add 'slot-power-limit-milliwatt' PCIe port property
From: Pali Rohár @ 2022-01-05 15:36 UTC (permalink / raw)
To: Rob Herring; +Cc: Marek Behún, devicetree, PCI, Bjorn Helgaas
In-Reply-To: <CAL_JsqL0mfRb7k4V-wjyGgjpB3pu88yPNT38k8zs-HoiVYaekQ@mail.gmail.com>
On Wednesday 05 January 2022 09:26:22 Rob Herring wrote:
> On Wed, Jan 5, 2022 at 9:14 AM Pali Rohár <pali@kernel.org> wrote:
> >
> > On Wednesday 05 January 2022 08:27:21 Rob Herring wrote:
> > > On Wed, Jan 5, 2022 at 8:14 AM Marek Behún <kabel@kernel.org> wrote:
> > > >
> > > > On Fri, 12 Nov 2021 09:25:20 -0600
> > > > Rob Herring <robh@kernel.org> wrote:
> > > >
> > > > > On Sun, Oct 31, 2021 at 04:07:05PM +0100, Marek Behún wrote:
> > > > > > From: Pali Rohár <pali@kernel.org>
> > > > > >
> > > > > > This property specifies slot power limit in mW unit. It is a form-factor
> > > > > > and board specific value and must be initialized by hardware.
> > > > > >
> > > > > > Some PCIe controllers delegate this work to software to allow hardware
> > > > > > flexibility and therefore this property basically specifies what should
> > > > > > host bridge program into PCIe Slot Capabilities registers.
> > > > > >
> > > > > > The property needs to be specified in mW unit instead of the special format
> > > > > > defined by Slot Capabilities (which encodes scaling factor or different
> > > > > > unit). Host drivers should convert the value from mW to needed format.
> > > > > >
> > > > > > Signed-off-by: Pali Rohár <pali@kernel.org>
> > > > > > Signed-off-by: Marek Behún <kabel@kernel.org>
> > > > > > ---
> > > > > > Documentation/devicetree/bindings/pci/pci.txt | 6 ++++++
> > > > > > 1 file changed, 6 insertions(+)
> > > > > >
> > > > > > diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
> > > > > > index 6a8f2874a24d..7296d599c5ac 100644
> > > > > > --- a/Documentation/devicetree/bindings/pci/pci.txt
> > > > > > +++ b/Documentation/devicetree/bindings/pci/pci.txt
> > > > > > @@ -32,6 +32,12 @@ driver implementation may support the following properties:
> > > > > > root port to downstream device and host bridge drivers can do programming
> > > > > > which depends on CLKREQ signal existence. For example, programming root port
> > > > > > not to advertise ASPM L1 Sub-States support if there is no CLKREQ signal.
> > > > > > +- slot-power-limit-miliwatt:
> > > > >
> > > > > Typo.
> > > > >
> > > > > But we shouldn't be adding to pci.txt. This needs to go in the
> > > > > schema[1]. Patch to devicetree-spec list or GH PR is fine.
> > > >
> > > > Hello Rob,
> > > >
> > > > Pali's PR draft https://github.com/devicetree-org/dt-schema/pull/64
> > > > looks like it's going to take some time to work out.
> > > >
> > > > In the meantime, is it possible to somehow get the
> > > > slot-power-limit-milliwatt property merged into pci.txt so that we can start
> > > > putting it into existing device-trees?
> > > >
> > > > Or would it break dt_bindings_check if it isn't put into dt-schema's
> > > > pci-bus.yaml?
> > > >
> > > > Or should we simply put it into current version of pci-bus.yaml and
> > > > work out the split proposed by Pali's PR afterwards?
> > >
> > > In the existing pci-bus.yaml is fine.
> >
> > Hello Rob! I do not think that it is possible to add this property
> > correctly in to the existing pci-bus.yaml file. As this file is not
> > prepared for slot properties. And I guess that adding new property at
> > "random" place is against the idea of schema validation (that validation
> > procedure accepts only valid DTS files).
>
> The only issue I see is the property would be allowed in host bridge
> nodes rather than only root port or PCIe-PCIe bridge nodes because the
> current file is a mixture of all of those. I think a note that the
> property is not valid in host bridge nodes would be sufficient. It's
> still better than documenting in pci.txt.
Ok!
^ permalink raw reply
* Re: [PATCH 02/12] ceph: handle idmapped mounts in create_request_message()
From: Christian Brauner @ 2022-01-05 15:35 UTC (permalink / raw)
To: Jeff Layton
Cc: Christian Brauner, ceph-devel, Ilya Dryomov, Christoph Hellwig
In-Reply-To: <3864f17da4018151359785b9a49140e18fdb30bb.camel@kernel.org>
On Wed, Jan 05, 2022 at 10:03:06AM -0500, Jeff Layton wrote:
> On Wed, 2022-01-05 at 15:10 +0100, Christian Brauner wrote:
> > On Tue, Jan 04, 2022 at 12:40:51PM -0500, Jeff Layton wrote:
> > > On Tue, 2022-01-04 at 15:04 +0100, Christian Brauner wrote:
> > > > From: Christian Brauner <christian.brauner@ubuntu.com>
> > > >
> > > > Inode operations that create a new filesystem object such as ->mknod,
> > > > ->create, ->mkdir() and others don't take a {g,u}id argument explicitly.
> > > > Instead the caller's fs{g,u}id is used for the {g,u}id of the new
> > > > filesystem object.
> > > >
> > > > Cephfs mds creation request argument structures mirror this filesystem
> > > > behavior. They don't encode a {g,u}id explicitly. Instead the caller's
> > > > fs{g,u}id that is always sent as part of any mds request is used by the
> > > > servers to set the {g,u}id of the new filesystem object.
> > > >
> > > > In order to ensure that the correct {g,u}id is used map the caller's
> > > > fs{g,u}id for creation requests. This doesn't require complex changes.
> > > > It suffices to pass in the relevant idmapping recorded in the request
> > > > message. If this request message was triggered from an inode operation
> > > > that creates filesystem objects it will have passed down the relevant
> > > > idmaping. If this is a request message that was triggered from an inode
> > > > operation that doens't need to take idmappings into account the initial
> > > > idmapping is passed down which is an identity mapping and thus is
> > > > guaranteed to leave the caller's fs{g,u}id unchanged.,u}id is sent.
> > > >
> > > > The last few weeks before Christmas 2021 I have spent time not just
> > > > reading and poking the cephfs kernel code but also took a look at the
> > > > ceph mds server userspace to ensure I didn't miss some subtlety.
> > > >
> > > > This made me aware of one complication to solve. All requests send the
> > > > caller's fs{g,u}id over the wire. The caller's fs{g,u}id matters for the
> > > > server in exactly two cases:
> > > >
> > > > 1. to set the ownership for creation requests
> > > > 2. to determine whether this client is allowed access on this server
> > > >
> > > > Case 1. we already covered and explained. Case 2. is only relevant for
> > > > servers where an explicit uid access restriction has been set. That is
> > > > to say the mds server restricts access to requests coming from a
> > > > specific uid. Servers without uid restrictions will grant access to
> > > > requests from any uid by setting MDS_AUTH_UID_ANY.
> > > >
> > > > Case 2. introduces the complication because the caller's fs{g,u}id is
> > > > not just used to record ownership but also serves as the {g,u}id used
> > > > when checking access to the server.
> > > >
> > > > Consider a user mounting a cephfs client and creating an idmapped mount
> > > > from it that maps files owned by uid 1000 to be owned uid 0:
> > > >
> > > > mount -t cephfs -o [...] /unmapped
> > > > mount-idmapped --map-mount 1000:0:1 /idmapped
> > > >
> > > > That is to say if the mounted cephfs filesystem contains a file "file1"
> > > > which is owned by uid 1000:
> > > >
> > > > - looking at it via /unmapped/file1 will report it as owned by uid 1000
> > > > (One can think of this as the on-disk value.)
> > > > - looking at it via /idmapped/file1 will report it as owned by uid 0
> > > >
> > > > Now, consider creating new files via the idmapped mount at /idmapped.
> > > > When a caller with fs{g,u}id 1000 creates a file "file2" by going
> > > > through the idmapped mount mounted at /idmapped it will create a file
> > > > that is owned by uid 1000 on-disk, i.e.:
> > > >
> > > > - looking at it via /unmapped/file2 will report it as owned by uid 1000
> > > > - looking at it via /idmapped/file2 will report it as owned by uid 0
> > > >
> > > > Now consider an mds server that has a uid access restriction set and
> > > > only grants access to requests from uid 0.
> > > >
> > > > If the client sends a creation request for a file e.g. /idmapped/file2
> > > > it will send the caller's fs{g,u}id idmapped according to the idmapped
> > > > mount. So if the caller has fs{g,u}id 1000 it will be mapped to {g,u}id
> > > > 0 in the idmapped mount and will be sent over the wire allowing the
> > > > caller access to the mds server.
> > > >
> > > > However, if the caller is not issuing a creation request the caller's
> > > > fs{g,u}id will be send without the mount's idmapping applied. So if the
> > > > caller that just successfully created a new file on the restricted mds
> > > > server sends a request as fs{g,u}id 1000 access will be refused. This
> > > > however is inconsistent.
> > > >
> > >
> > > IDGI, why would you send the fs{g,u}id without the mount's idmapping
> > > applied in this case? ISTM that idmapping is wholly a client-side
> > > feature, and that you should always map id's regardless of whether
> > > you're creating or not.
> >
> > Since the idmapping is a property of the mount and not a property of the
> > caller the caller's fs{g,u}id aren't mapped. What is mapped are the
> > inode's i{g,u}id when accessed from a particular mount.
> >
> > The fs{g,u}id are only ever mapped when a new filesystem object is
> > created. So if I have an idmapped mount that makes it so that files
> > owned by 1000 on-disk appear to be owned by uid 0 then a user with uid 0
> > creating a new file will create files with uid 1000 on-disk when going
> > through that mount. For cephfs that'd be the uid we would be sending
> > with creation requests as I've currently written it.
> >
> > So then when the user looks at the file it created it will see it as
> > being owned by uid 0 from that idmapped mount (whereas on-disk it's
> > 1000). But the user's fs{g,u}id isn't per se changed when going through
> > that mount. So in my opinion I was thinking that the server with access
> > permissions set would want to always check permissions on the users
> > "raw" fs{g,u}id. That would mean I'd have to change the patch obviously.
> > My suggestion was to send the {g,u}id the file will be created with
> > separately. The alternative would be to not just pass the idmapping into
> > the creation iop's but into all iops so that we can always map it for
> > cephfs. But this would mean a lot of vfs changes for one filesystem. So
> > if we could first explore alternatives approaches I'd be grateful.
> >
>
> You'll probably need to do this for NFS anyway, if you have plans in
> that direction. Extending the protocol there will be much more
> difficult. I think that approach sounds much cleaner overall.
Ok. Is it ok if I take a little while to work on this?
I have some other work I need to be looking at first and then I have
Februrary "free".
>
> > (I'll be traveling for the latter half of this week starting today at
> > CET afternoon so apologies but I'll probably take some time to respond.)
>
> Ok. I guess you can get away with this on a local fs because the backend
> storage doesn't really care about uid/gids at all. The only permission
> checking is done in the kernel and you (presumably) can just map the
> inode's uid/gid prior to checking permissions.
Yes, we always map the inode as that's semantically cleaner and easier
to reason about in my opinion.
>
> I'm a little confused as to what you mean by "raw" id here. In your
> earlier example with a mapping of 1000:0:1, which one is the raw id for
> the actual user?
Oh, sorry. In this context I really just meant the values gotten from
current_fs{g,u}id() as they are sent now.
^ permalink raw reply
* Re: [PATCH 3/3] net: usb: r8152: remove unused definition
From: Greg KH @ 2022-01-05 15:34 UTC (permalink / raw)
To: Aaron Ma
Cc: kuba, henning.schild, linux-usb, netdev, linux-kernel, davem,
hayeswang, tiwai
In-Reply-To: <20220105151427.8373-3-aaron.ma@canonical.com>
On Wed, Jan 05, 2022 at 11:14:27PM +0800, Aaron Ma wrote:
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
Again, not good, you know better than to not provide a changelog text.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 2/3] net: usb: r8152: Set probe mode to sync
From: Greg KH @ 2022-01-05 15:33 UTC (permalink / raw)
To: Aaron Ma
Cc: kuba, henning.schild, linux-usb, netdev, linux-kernel, davem,
hayeswang, tiwai
In-Reply-To: <20220105151427.8373-2-aaron.ma@canonical.com>
On Wed, Jan 05, 2022 at 11:14:26PM +0800, Aaron Ma wrote:
> To avoid the race of get passthrough MAC,
> set probe mode to sync to check the used MAC address.
>
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> ---
> drivers/net/usb/r8152.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index 2483dc421dff..7cf2faf8d088 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -29,6 +29,8 @@
> #include <crypto/hash.h>
> #include <linux/usb/r8152.h>
>
> +static struct usb_driver rtl8152_driver;
> +
> /* Information for net-next */
> #define NETNEXT_VERSION "12"
>
> @@ -9546,6 +9548,9 @@ static int rtl8152_probe(struct usb_interface *intf,
> struct r8152 *tp;
> struct net_device *netdev;
> int ret;
> + struct device_driver *rtl8152_drv = &rtl8152_driver.drvwrap.driver;
> +
> + rtl8152_drv->probe_type = PROBE_FORCE_SYNCHRONOUS;
If you really need to set this type of thing then set BEFORE you
register the driver. After-the-fact like this is way too late, sorry.
You are already in the probe function which is after the driver core
checked this flag :(
How did you test this?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] softmmu: fix device deletion events with -device JSON syntax
From: Laurent Vivier @ 2022-01-05 15:31 UTC (permalink / raw)
To: Daniel P. Berrangé
Cc: Kevin Wolf, Eduardo Habkost, Thomas Huth, Peter Krempa,
qemu-devel, Markus Armbruster, Paolo Bonzini, Eric Blake
In-Reply-To: <YdW2qk19K5N7gr9W@redhat.com>
On 05/01/2022 16:18, Daniel P. Berrangé wrote:
> On Wed, Jan 05, 2022 at 04:00:54PM +0100, Laurent Vivier wrote:
>> On 05/01/2022 15:55, Daniel P. Berrangé wrote:
>>> On Wed, Jan 05, 2022 at 03:49:12PM +0100, Laurent Vivier wrote:
>>>> On 05/01/2022 13:38, Daniel P. Berrangé wrote:
>>>>> The -device JSON syntax impl leaks a reference on the created
>>>>> DeviceState instance. As a result when you hot-unplug the
>>>>> device, the device_finalize method won't be called and thus
>>>>> it will fail to emit the required DEVICE_DELETED event.
>>>>>
>>>>> A 'json-cli' feature was previously added against the
>>>>> 'device_add' QMP command QAPI schema to indicated to mgmt
>>>>> apps that -device supported JSON syntax. Given the hotplug
>>>>> bug that feature flag is no unusable for its purpose, so
>>>>
>>>> Not sure to understand: do you mean "now unusable"?
>>>
>>> An application wants to known whether QEMU can support JSON
>>> syntax with -device. If they look for the 'json-cli' feature
>>> as a witness, they'll end up using JSON with QEMU 6.2 which
>>> is giving them broken hotplug. This is unusable for any
>>> non-trivial use cases. So we need a new witness to indicate
>>> whether JSON is viable with -device, that only the newly
>>> fixed QEMU will report.
>>
>> I understand that, my problem was with your sentence:
>>
>> "Given the hotplug bug that feature flag is no unusable for its purpose"
>
> What's the problem with that ? It is reasonabled to say a -device impl
> which is broken for hotplug is not usable for non-toy use cases.
The problem for me is the double negation: "no" and "unusable"
Thanks,
Laurent
^ permalink raw reply
* Re: [PATCHv6] PCI: layerscape: Change to use the DWC common link-up check function
From: Lorenzo Pieralisi @ 2022-01-05 15:33 UTC (permalink / raw)
To: Zhiqiang Hou; +Cc: linux-pci, robh, bhelgaas, minghuan.Lian, leoyang.li
In-Reply-To: <20211224094000.8513-1-Zhiqiang.Hou@nxp.com>
On Fri, Dec 24, 2021 at 05:40:00PM +0800, Zhiqiang Hou wrote:
> From: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
>
> The current Layerscape PCIe driver directly uses the physical layer
> LTSSM code to check the link-up state, which treats the > L0 states
> as link-up. This is not correct, since there is not explicit map
> between link-up state and LTSSM. So this patch changes to use the
> DWC common link-up check function.
>
> Signed-off-by: Hou Zhiqiang <Zhiqiang.Hou@nxp.com>
> Reviewed-by: Rob Herring <robh@kernel.org>
> ---
> V6:
> - This patch is splited from the V5 version of Layerscape PCIe Power
> Management support series.
> - Removed the driver data structure.
>
> drivers/pci/controller/dwc/pci-layerscape.c | 152 ++------------------
> 1 file changed, 11 insertions(+), 141 deletions(-)
Applied to pci/dwc, thanks.
Lorenzo
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape.c b/drivers/pci/controller/dwc/pci-layerscape.c
> index 5b9c625df7b8..6a4f0619bb1c 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape.c
> @@ -3,6 +3,7 @@
> * PCIe host controller driver for Freescale Layerscape SoCs
> *
> * Copyright (C) 2014 Freescale Semiconductor.
> + * Copyright 2021 NXP
> *
> * Author: Minghuan Lian <Minghuan.Lian@freescale.com>
> */
> @@ -22,12 +23,6 @@
>
> #include "pcie-designware.h"
>
> -/* PEX1/2 Misc Ports Status Register */
> -#define SCFG_PEXMSCPORTSR(pex_idx) (0x94 + (pex_idx) * 4)
> -#define LTSSM_STATE_SHIFT 20
> -#define LTSSM_STATE_MASK 0x3f
> -#define LTSSM_PCIE_L0 0x11 /* L0 state */
> -
> /* PEX Internal Configuration Registers */
> #define PCIE_STRFMR1 0x71c /* Symbol Timer & Filter Mask Register1 */
> #define PCIE_ABSERR 0x8d0 /* Bridge Slave Error Response Register */
> @@ -35,20 +30,8 @@
>
> #define PCIE_IATU_NUM 6
>
> -struct ls_pcie_drvdata {
> - u32 lut_offset;
> - u32 ltssm_shift;
> - u32 lut_dbg;
> - const struct dw_pcie_host_ops *ops;
> - const struct dw_pcie_ops *dw_pcie_ops;
> -};
> -
> struct ls_pcie {
> struct dw_pcie *pci;
> - void __iomem *lut;
> - struct regmap *scfg;
> - const struct ls_pcie_drvdata *drvdata;
> - int index;
> };
>
> #define to_ls_pcie(x) dev_get_drvdata((x)->dev)
> @@ -83,38 +66,6 @@ static void ls_pcie_drop_msg_tlp(struct ls_pcie *pcie)
> iowrite32(val, pci->dbi_base + PCIE_STRFMR1);
> }
>
> -static int ls1021_pcie_link_up(struct dw_pcie *pci)
> -{
> - u32 state;
> - struct ls_pcie *pcie = to_ls_pcie(pci);
> -
> - if (!pcie->scfg)
> - return 0;
> -
> - regmap_read(pcie->scfg, SCFG_PEXMSCPORTSR(pcie->index), &state);
> - state = (state >> LTSSM_STATE_SHIFT) & LTSSM_STATE_MASK;
> -
> - if (state < LTSSM_PCIE_L0)
> - return 0;
> -
> - return 1;
> -}
> -
> -static int ls_pcie_link_up(struct dw_pcie *pci)
> -{
> - struct ls_pcie *pcie = to_ls_pcie(pci);
> - u32 state;
> -
> - state = (ioread32(pcie->lut + pcie->drvdata->lut_dbg) >>
> - pcie->drvdata->ltssm_shift) &
> - LTSSM_STATE_MASK;
> -
> - if (state < LTSSM_PCIE_L0)
> - return 0;
> -
> - return 1;
> -}
> -
> /* Forward error response of outbound non-posted requests */
> static void ls_pcie_fix_error_response(struct ls_pcie *pcie)
> {
> @@ -139,96 +90,20 @@ static int ls_pcie_host_init(struct pcie_port *pp)
> return 0;
> }
>
> -static int ls1021_pcie_host_init(struct pcie_port *pp)
> -{
> - struct dw_pcie *pci = to_dw_pcie_from_pp(pp);
> - struct ls_pcie *pcie = to_ls_pcie(pci);
> - struct device *dev = pci->dev;
> - u32 index[2];
> - int ret;
> -
> - pcie->scfg = syscon_regmap_lookup_by_phandle(dev->of_node,
> - "fsl,pcie-scfg");
> - if (IS_ERR(pcie->scfg)) {
> - ret = PTR_ERR(pcie->scfg);
> - dev_err(dev, "No syscfg phandle specified\n");
> - pcie->scfg = NULL;
> - return ret;
> - }
> -
> - if (of_property_read_u32_array(dev->of_node,
> - "fsl,pcie-scfg", index, 2)) {
> - pcie->scfg = NULL;
> - return -EINVAL;
> - }
> - pcie->index = index[1];
> -
> - return ls_pcie_host_init(pp);
> -}
> -
> -static const struct dw_pcie_host_ops ls1021_pcie_host_ops = {
> - .host_init = ls1021_pcie_host_init,
> -};
> -
> static const struct dw_pcie_host_ops ls_pcie_host_ops = {
> .host_init = ls_pcie_host_init,
> };
>
> -static const struct dw_pcie_ops dw_ls1021_pcie_ops = {
> - .link_up = ls1021_pcie_link_up,
> -};
> -
> -static const struct dw_pcie_ops dw_ls_pcie_ops = {
> - .link_up = ls_pcie_link_up,
> -};
> -
> -static const struct ls_pcie_drvdata ls1021_drvdata = {
> - .ops = &ls1021_pcie_host_ops,
> - .dw_pcie_ops = &dw_ls1021_pcie_ops,
> -};
> -
> -static const struct ls_pcie_drvdata ls1043_drvdata = {
> - .lut_offset = 0x10000,
> - .ltssm_shift = 24,
> - .lut_dbg = 0x7fc,
> - .ops = &ls_pcie_host_ops,
> - .dw_pcie_ops = &dw_ls_pcie_ops,
> -};
> -
> -static const struct ls_pcie_drvdata ls1046_drvdata = {
> - .lut_offset = 0x80000,
> - .ltssm_shift = 24,
> - .lut_dbg = 0x407fc,
> - .ops = &ls_pcie_host_ops,
> - .dw_pcie_ops = &dw_ls_pcie_ops,
> -};
> -
> -static const struct ls_pcie_drvdata ls2080_drvdata = {
> - .lut_offset = 0x80000,
> - .ltssm_shift = 0,
> - .lut_dbg = 0x7fc,
> - .ops = &ls_pcie_host_ops,
> - .dw_pcie_ops = &dw_ls_pcie_ops,
> -};
> -
> -static const struct ls_pcie_drvdata ls2088_drvdata = {
> - .lut_offset = 0x80000,
> - .ltssm_shift = 0,
> - .lut_dbg = 0x407fc,
> - .ops = &ls_pcie_host_ops,
> - .dw_pcie_ops = &dw_ls_pcie_ops,
> -};
> -
> static const struct of_device_id ls_pcie_of_match[] = {
> - { .compatible = "fsl,ls1012a-pcie", .data = &ls1046_drvdata },
> - { .compatible = "fsl,ls1021a-pcie", .data = &ls1021_drvdata },
> - { .compatible = "fsl,ls1028a-pcie", .data = &ls2088_drvdata },
> - { .compatible = "fsl,ls1043a-pcie", .data = &ls1043_drvdata },
> - { .compatible = "fsl,ls1046a-pcie", .data = &ls1046_drvdata },
> - { .compatible = "fsl,ls2080a-pcie", .data = &ls2080_drvdata },
> - { .compatible = "fsl,ls2085a-pcie", .data = &ls2080_drvdata },
> - { .compatible = "fsl,ls2088a-pcie", .data = &ls2088_drvdata },
> - { .compatible = "fsl,ls1088a-pcie", .data = &ls2088_drvdata },
> + { .compatible = "fsl,ls1012a-pcie", },
> + { .compatible = "fsl,ls1021a-pcie", },
> + { .compatible = "fsl,ls1028a-pcie", },
> + { .compatible = "fsl,ls1043a-pcie", },
> + { .compatible = "fsl,ls1046a-pcie", },
> + { .compatible = "fsl,ls2080a-pcie", },
> + { .compatible = "fsl,ls2085a-pcie", },
> + { .compatible = "fsl,ls2088a-pcie", },
> + { .compatible = "fsl,ls1088a-pcie", },
> { },
> };
>
> @@ -247,11 +122,8 @@ static int ls_pcie_probe(struct platform_device *pdev)
> if (!pci)
> return -ENOMEM;
>
> - pcie->drvdata = of_device_get_match_data(dev);
> -
> pci->dev = dev;
> - pci->ops = pcie->drvdata->dw_pcie_ops;
> - pci->pp.ops = pcie->drvdata->ops;
> + pci->pp.ops = &ls_pcie_host_ops;
>
> pcie->pci = pci;
>
> @@ -260,8 +132,6 @@ static int ls_pcie_probe(struct platform_device *pdev)
> if (IS_ERR(pci->dbi_base))
> return PTR_ERR(pci->dbi_base);
>
> - pcie->lut = pci->dbi_base + pcie->drvdata->lut_offset;
> -
> if (!ls_pcie_is_bridge(pcie))
> return -ENODEV;
>
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH 1/3 v3] net: usb: r8152: Check used MAC passthrough address
From: Greg KH @ 2022-01-05 15:31 UTC (permalink / raw)
To: Aaron Ma
Cc: kuba, henning.schild, linux-usb, netdev, linux-kernel, davem,
hayeswang, tiwai
In-Reply-To: <20220105151427.8373-1-aaron.ma@canonical.com>
On Wed, Jan 05, 2022 at 11:14:25PM +0800, Aaron Ma wrote:
> When plugin multiple r8152 ethernet dongles to Lenovo Docks
> or USB hub, MAC passthrough address from BIOS should be
> checked if it had been used to avoid using on other dongles.
>
> Currently builtin r8152 on Dock still can't be identified.
> First detected r8152 will use the MAC passthrough address.
>
> v2:
> Skip builtin PCI MAC address which is share MAC address with
> passthrough MAC.
> Check thunderbolt based ethernet.
>
> v3:
> Add return value.
All of this goes below the --- line.
You have read the kernel documentation for how to do all of this, right?
If not, please re-read it.
>
> Fixes: f77b83b5bbab ("net: usb: r8152: Add MAC passthrough support for
> more Lenovo Docks")
This line should not be wrapped.
> Signed-off-by: Aaron Ma <aaron.ma@canonical.com>
> ---
> drivers/net/usb/r8152.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
> index f9877a3e83ac..2483dc421dff 100644
> --- a/drivers/net/usb/r8152.c
> +++ b/drivers/net/usb/r8152.c
> @@ -25,6 +25,7 @@
> #include <linux/atomic.h>
> #include <linux/acpi.h>
> #include <linux/firmware.h>
> +#include <linux/pci.h>
Why does a USB driver care about PCI stuff?
> #include <crypto/hash.h>
> #include <linux/usb/r8152.h>
>
> @@ -1605,6 +1606,7 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
> char *mac_obj_name;
> acpi_object_type mac_obj_type;
> int mac_strlen;
> + struct net_device *ndev;
>
> if (tp->lenovo_macpassthru) {
> mac_obj_name = "\\MACA";
> @@ -1662,6 +1664,19 @@ static int vendor_mac_passthru_addr_read(struct r8152 *tp, struct sockaddr *sa)
> ret = -EINVAL;
> goto amacout;
> }
> + rcu_read_lock();
> + for_each_netdev_rcu(&init_net, ndev) {
> + if (ndev->dev.parent && dev_is_pci(ndev->dev.parent) &&
Ick ick ick.
No, don't go poking around in random parent devices of a USB device,
that is a sure way to break things.
> + !pci_is_thunderbolt_attached(to_pci_dev(ndev->dev.parent)))
So thunderbolt USB hubs are a problem here?
No, this is not the correct way to handle this at all. There should be
some sort of identifier on the USB device itself to say that it is in a
docking station and needs to have special handling. If not, then the
docking station is broken and needs to be returned.
Can you please revert the offending patch first so that people's systems
go back to working properly first? Then worry about trying to uniquely
identify these crazy devices.
Again, this is not a way to do it, sorry.
greg k-h
^ permalink raw reply
* Re: [PATCH net 1/1] net: openvswitch: Fix ct_state nat flags for conns arriving from tc
From: Daniel Borkmann @ 2022-01-05 15:30 UTC (permalink / raw)
To: Jamal Hadi Salim, Paul Blakey, dev, netdev, Cong Wang,
Pravin B Shelar, davem, Jiri Pirko, Jakub Kicinski
Cc: Saeed Mahameed, Oz Shlomo, Vlad Buslov, Roi Dayan, john.fastabend
In-Reply-To: <776c2688-72db-4ad6-45e5-73bc08b78615@mojatatu.com>
On 1/5/22 3:57 PM, Jamal Hadi Salim wrote:
> On 2022-01-04 03:28, Paul Blakey wrote:
> [..]
>> --- a/include/linux/skbuff.h
>> +++ b/include/linux/skbuff.h
>> @@ -287,7 +287,9 @@ struct tc_skb_ext {
>> __u32 chain;
>> __u16 mru;
>> __u16 zone;
>> - bool post_ct;
>> + bool post_ct:1;
>> + bool post_ct_snat:1;
>> + bool post_ct_dnat:1;
>> };
>
> is skb_ext intended only for ovs? If yes, why does it belong
> in the core code? Ex: Looking at tcf_classify() which is such
> a core function in the fast path any packet going via tc, it
> is now encumbered with with checking presence of skb_ext.
> I know passing around metadata is a paramount requirement
> for programmability but this is getting messier with speacial
> use cases for ovs and/or offload...
Full ack on the bloat for corner cases like ovs offload, especially
given distros just enable most stuff anyway and therefore no light
fast path as with !CONFIG_NET_TC_SKB_EXT. :(
Could this somehow be hidden behind static key or such if offloads
are not used, so we can shrink it back to just calling into plain
__tcf_classify() for sw-only use cases (like BPF)?
^ permalink raw reply
* Re: [PATCH] tools: kwbimage: Fix checksum calculation for v1 images
From: Stefan Roese @ 2022-01-05 15:30 UTC (permalink / raw)
To: Pierre Bourdon, u-boot; +Cc: Pali Rohár, Marek Behún
In-Reply-To: <20211225195019.1509965-1-delroth@gmail.com>
On 12/25/21 20:50, Pierre Bourdon wrote:
> Recent changes caused fields in the image main header to be modified
> after the header checksum had already been computed. Move the checksum
> computation to once again be the last operation performed on the header.
>
> Fixes: 2b0980c24027 ("tools: kwbimage: Fill the real header size into the main header")
>
> Signed-off-by: Pierre Bourdon <delroth@gmail.com>
Reviewed-by: Stefan Roese <sr@denx.de>
Thanks,
Stefan
> ---
> tools/kwbimage.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tools/kwbimage.c b/tools/kwbimage.c
> index 875f636c7a..0951d7861c 100644
> --- a/tools/kwbimage.c
> +++ b/tools/kwbimage.c
> @@ -1398,9 +1398,6 @@ static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
> headersz, image, secure_hdr))
> return NULL;
>
> - /* Calculate and set the header checksum */
> - main_hdr->checksum = image_checksum8(main_hdr, headersz);
> -
> *imagesz = headersz;
>
> /* Fill the real header size without padding into the main header */
> @@ -1410,6 +1407,9 @@ static void *image_create_v1(size_t *imagesz, struct image_tool_params *params,
> main_hdr->headersz_lsb = cpu_to_le16(headersz & 0xFFFF);
> main_hdr->headersz_msb = (headersz & 0xFFFF0000) >> 16;
>
> + /* Calculate and set the header checksum */
> + main_hdr->checksum = image_checksum8(main_hdr, headersz);
> +
> return image;
> }
>
>
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: sr@denx.de
^ permalink raw reply
* BUG: unable to handle kernel NULL pointer dereference in iptable_nat_table_init
From: Sabri N. Ferreiro @ 2022-01-05 15:28 UTC (permalink / raw)
To: Pablo Neira Ayuso, Jozsef Kadlecsik, Florian Westphal,
David S. Miller, Hideaki YOSHIFUJI, David Ahern, Jakub Kicinski,
netfilter-devel, coreteam, netdev, linux-kernel
Cc: mosesfonscqf75
Hi,
When using Syzkaller to fuzz the Linux kernel, it triggers the following crash.
HEAD commit: a7904a538933 Linux 5.16-rc6
git tree: upstream
console output:
https://docs.google.com/document/d/1hfN-JPPEtV8aGF9OvIboVVu7XYgUp-tp9G7DVXWNJ6k/view
kernel config: https://docs.google.com/document/d/1w94kqQ4ZSIE6BW-5WIhqp4_Zh7XTPH57L5OF2Xb6O6o/view
If you fix this issue, please add the following tag to the commit:
Reported-by: Yuheng Shen <mosesfonscqf75@gmail.com>
Sorry for my lack of this crash reproducer, I hope the symbolic report
will help you.
audit: type=1400 audit(1641210298.987:9): avc: denied { module_load
} for pid=2094 comm="modprobe"
path="/lib/modules/5.15.0-rc6/kernel/net/ipv4/netfilter/iptable_nat.ko"
dev="sda" ino=429877 scontext=system_u:system_r:kernel_t:s0
tcontext=system_u:object_r:unlabeled_t:s0 tclass=system permissive=1
BUG: kernel NULL pointer dereference, address: 0000000000000000
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: 0002 [#1] SMP KASAN NOPTI
CPU: 1 PID: 350 Comm: syz-executor.3 Not tainted 5.15.0-rc6 #10
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
RIP: 0010:iptable_nat_table_init+0xc9/0x150 [iptable_nat]
Code: 00 00 49 89 c7 31 db 4d 89 67 10 4c 89 fe 48 89 ef e8 8b 0e 06
f4 85 c0 75 30 83 c3 01 49 83 c7 28 83 fb 04 75 e1 48 8b 0c 24 <4c> 89
31 4c 89 ef 89 04 24 e8 49 7b 66 f2 8b 04 24 48 83 c4 08 5b
RSP: 0018:ffff8880039ef9a0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000004 RCX: 0000000000000000
RDX: ffff888001daa180 RSI: 0000000000000000 RDI: ffff8880039ef8d0
RBP: ffff888025150000 R08: 0000000000000001 R09: ffff8880039ef8d7
R10: ffffed100073df1a R11: 0000000000000001 R12: ffff8880056f2000
R13: ffff888001bdb800 R14: ffff888004ac7700 R15: ffff888004ac77a0
FS: 0000555555766480(0000) GS:ffff88806d280000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 0000000004654004 CR4: 0000000000770ee0
PKRU: 55555554
Call Trace:
xt_find_table_lock+0x2a3/0x450
root/fuzz/kernel/5.15/net/netfilter/x_tables.c:1259
xt_request_find_table_lock+0x25/0xb0
root/fuzz/kernel/5.15/net/netfilter/x_tables.c:1284
get_info+0x133/0x4b0 root/fuzz/kernel/5.15/net/ipv6/netfilter/ip6_tables.c:981
do_ipt_get_ctl+0x12f/0x850
root/fuzz/kernel/5.15/net/ipv4/netfilter/ip_tables.c:1653
nf_getsockopt+0x65/0xc0 root/fuzz/kernel/5.15/net/netfilter/nf_sockopt.c:116
ip_getsockopt root/fuzz/kernel/5.15/net/ipv4/ip_sockglue.c:1777 [inline]
ip_getsockopt+0x115/0x150 root/fuzz/kernel/5.15/net/ipv4/ip_sockglue.c:1756
tcp_getsockopt+0x7e/0xc0 root/fuzz/kernel/5.15/net/ipv4/tcp.c:4254
__sys_getsockopt+0x128/0x220 root/fuzz/kernel/5.15/net/socket.c:2220
__do_sys_getsockopt root/fuzz/kernel/5.15/net/socket.c:2235 [inline]
__se_sys_getsockopt root/fuzz/kernel/5.15/net/socket.c:2232 [inline]
__x64_sys_getsockopt+0xba/0x150 root/fuzz/kernel/5.15/net/socket.c:2232
do_syscall_x64 root/fuzz/kernel/5.15/arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x38/0x90 root/fuzz/kernel/5.15/arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f56ab2736de
Code: 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f
84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 <48> 3d
01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff93e04eb8 EFLAGS: 00000246 ORIG_RAX: 0000000000000037
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f56ab2736de
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 0000000000000003 R08: 00007fff93e04eec R09: 0000000000000278
R10: 00007f56ab3662c8 R11: 0000000000000246 R12: 00007fff93e04eec
R13: 00007f56ab2e52b5 R14: 00007f56ab3662c8 R15: 00007f56ab3662c0
Modules linked in: iptable_nat
CR2: 0000000000000000
---[ end trace e420cba137499491 ]---
^ permalink raw reply
* Re: [PATCH v2] random: avoid superfluous call to RDRAND in CRNG extraction
From: Ard Biesheuvel @ 2022-01-05 15:28 UTC (permalink / raw)
To: Jason A. Donenfeld
Cc: Linux Kernel Mailing List, Theodore Y. Ts'o,
Linux Crypto Mailing List
In-Reply-To: <20211231114903.60882-1-Jason@zx2c4.com>
On Fri, 31 Dec 2021 at 12:50, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> RDRAND is not fast. RDRAND is actually quite slow. We've known this for
> a while, which is why functions like get_random_u{32,64} were converted
> to use batching of our ChaCha-based CRNG instead.
>
> Yet CRNG extraction still includes a call to RDRAND, in the hot path of
> every call to get_random_bytes(), /dev/urandom, and getrandom(2).
>
> This call to RDRAND here seems quite superfluous. CRNG is already
> extracting things based on a 256-bit key, based on good entropy, which
> is then reseeded periodically, updated, backtrack-mutated, and so
> forth. The CRNG extraction construction is something that we're already
> relying on to be secure and solid. If it's not, that's a serious
> problem, and it's unlikely that mixing in a measly 32 bits from RDRAND
> is going to alleviate things.
>
> And in the case where the CRNG doesn't have enough entropy yet, we're
> already initializing the ChaCha key row with RDRAND in
> crng_init_try_arch_early().
>
> Removing the call to RDRAND improves performance on an i7-11850H by
> 370%. In other words, the vast majority of the work done by
> extract_crng() prior to this commit was devoted to fetching 32 bits of
> RDRAND.
>
> Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
> ---
> drivers/char/random.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index 4de0feb69781..17ec60948795 100644
> --- a/drivers/char/random.c
> +++ b/drivers/char/random.c
> @@ -1023,7 +1023,7 @@ static void crng_reseed(struct crng_state *crng, struct entropy_store *r)
> static void _extract_crng(struct crng_state *crng,
> __u8 out[CHACHA_BLOCK_SIZE])
> {
> - unsigned long v, flags, init_time;
> + unsigned long flags, init_time;
>
> if (crng_ready()) {
> init_time = READ_ONCE(crng->init_time);
> @@ -1033,8 +1033,6 @@ static void _extract_crng(struct crng_state *crng,
> &input_pool : NULL);
> }
> spin_lock_irqsave(&crng->lock, flags);
> - if (arch_get_random_long(&v))
> - crng->state[14] ^= v;
> chacha20_block(&crng->state[0], out);
> if (crng->state[12] == 0)
> crng->state[13]++;
Given that arch_get_random_long() may be backed by other things than
special instructions on some architectures/platforms, avoiding it if
we can on any path that may be a hot path is good, so
Acked-by: Ard Biesheuvel <ardb@kernel.org>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.