June 2023 - Linux-stable-mirror

Fwd: Remounting ext4 filesystem from ro to rw fails when quotas are enabled

by Bagas Sanjaya

Hi, I notice a regression report on Bugzilla [1]. Quoting from it: > Since commit a44be64, remounting a read-only ext4 filesystem to become read-write fails when quotas are enabled. The mount syscall returns -EROFS and outputs the following in dmesg: > > ``` > EXT4-fs warning (device loop0): ext4_enable_quotas:7028: Failed to enable quota tracking (type=0, err=-30, ino=3). Please run e2fsck > ``` > > > Root cause > > The problem can be traced back to the changes introduced in commit a44be64. It appears that the issue arises because the SB_RDONLY bit of the s_flags field is now only cleared after executing the ext4_enable_quotas function. However, the vfs_setup_quota_inode function, called by ext4_enable_quotas, checks whether this bit is set (fs/quota/dquot.c:2331): > > ``` > if (IS_RDONLY(inode)) > return -EROFS; > ``` > > This condition therefore always triggers the -EROFS fail condition. > > > Steps to Reproduce > > The bug can be reproduced by executing the following script on a current mainline kernel with defconfig: > > ``` > #!/bin/bash > > set -ex > > truncate -s 1G /tmp/img > mkfs.ext4 /tmp/img > tune2fs -Q usrquota,grpquota,prjquota /tmp/img > losetup /dev/loop0 /tmp/img > mount -o ro /dev/loop0 /mnt > mount -o remount,rw /mnt > ``` > > Executing the script results in the following output: > > ``` > + truncate -s 1G /tmp/img > + mkfs.ext4 /tmp/img > mke2fs 1.47.0 (5-Feb-2023) > Discarding device blocks: done > Creating filesystem with 262144 4k blocks and 65536 inodes > Filesystem UUID: b96a3da2-043f-11ee-b6f0-47c69db05231 > Superblock backups stored on blocks: > 32768, 98304, 163840, 229376 > > Allocating group tables: done > Writing inode tables: done > Creating journal (8192 blocks): done > Writing superblocks and filesystem accounting information: done > > + tune2fs -Q usrquota,grpquota,prjquota /tmp/img > tune2fs 1.47.0 (5-Feb-2023) > + losetup /dev/loop0 /tmp/img > [ 6.766763] loop0: detected capacity change from 0 to 2097152 > + mount -o ro /dev/loop0 /mnt > [ 6.791561] EXT4-fs (loop0): mounted filesystem b96a3da2-043f-11ee-b6f0-47c69db05231 ro with ordered data mode. Quota mode: journalled. > + mount -o remount,rw /mnt > [ 6.805546] EXT4-fs warning (device loop0): ext4_enable_quotas:7028: Failed to enable quota tracking (type=0, err=-30, ino=3). Please run e2fsck to fix. > mount: /mnt: cannot remount /dev/loop0 read-write, is write-protected. > dmesg(1) may have more information after failed mount system call. > ``` See Bugzilla for the full thread. Ted, it looks like this regression is caused by your ext4_xattr_block_set() fix to earlier syzbot report. Would you like to take a look on it? Anyway, I'm adding it to regzbot: #regzbot introduced: a44be64bbecb15 https://bugzilla.kernel.org/show_bug.cgi?id=217529 #regzbot title: Remounting ext4 filesystem from ro to rw fails when quotas are enabled Thanks. [1]: https://bugzilla.kernel.org/show_bug.cgi?id=217529 -- An old man doll... just what I always wanted! - Clara

1 year, 6 months

3
2
0 0

[PATCH RESEND] PCI: Add function 1 DMA alias quirk for Marvell 88SE9235

by Robin Murphy

Marvell's own product brief implies the 92xx series are a closely related family, and sure enough it turns out that 9235 seems to need the same quirk as the other three, although possibly only when certain ports are used. CC: stable(a)vger.kernel.org Reported-by: Jason Adriaanse <jason_a69(a)yahoo.co.uk> Link: https://lore.kernel.org/linux-iommu/2a699a99-545c-1324-e052-7d2f41fed1ae@ya… Signed-off-by: Robin Murphy <robin.murphy(a)arm.com> --- Note that the actual regression which started the thread is a different matter, wherein a particular combination of parameters which used to put intel-iommu into passthrough mode now enables full translation instead. Take #2, hopefully not royally screwing up my email alises this time. Sorry about that... drivers/pci/quirks.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c index f4e2a88729fd..3186f2c84eab 100644 --- a/drivers/pci/quirks.c +++ b/drivers/pci/quirks.c @@ -4174,6 +4174,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9220, /* https://bugzilla.kernel.org/show_bug.cgi?id=42679#c49 */ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9230, quirk_dma_func1_alias); +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_MARVELL_EXT, 0x9235, + quirk_dma_func1_alias); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0642, quirk_dma_func1_alias); DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_TTI, 0x0645, -- 2.39.2.101.g768bb238c484.dirty

1 year, 6 months

3
2
0 0

[tiL6.1-P PATCH] regulator: tps65219: fix matching interrupts for their regulators

by Jerome Neanne

From: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> The driver's probe() first registers regulators in a loop and then in a second loop passes them as irq data to the interrupt handlers. However the function to get the regulator for given name tps65219_get_rdev_by_name() was a no-op due to argument passed by value, not pointer, thus the second loop assigned always same value - from previous loop. The interrupts, when fired, where executed with wrong data. Compiler also noticed it: drivers/regulator/tps65219-regulator.c: In function ‘tps65219_get_rdev_by_name’: drivers/regulator/tps65219-regulator.c:292:60: error: parameter ‘dev’ set but not used [-Werror=unused-but-set-parameter] Fixes: c12ac5fc3e0a ("regulator: drivers: Add TI TPS65219 PMIC regulators support") Cc: <stable(a)vger.kernel.org> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> Reviewed-by: Markus Schneider-Pargmann <msp(a)baylibre.com> Signed-off-by: Jerome Neanne <jneanne(a)baylibre.com> --- Notes: This is backport of upstream fix in TI mainline: Link: https://lore.kernel.org/all/20230507144656.192800-1-krzysztof.kozlowski@lin… drivers/regulator/tps65219-regulator.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/regulator/tps65219-regulator.c b/drivers/regulator/tps65219-regulator.c index 58f6541b6417..b0d8d6fed24d 100644 --- a/drivers/regulator/tps65219-regulator.c +++ b/drivers/regulator/tps65219-regulator.c @@ -289,13 +289,13 @@ static irqreturn_t tps65219_regulator_irq_handler(int irq, void *data) static int tps65219_get_rdev_by_name(const char *regulator_name, struct regulator_dev *rdevtbl[7], - struct regulator_dev *dev) + struct regulator_dev **dev) { int i; for (i = 0; i < ARRAY_SIZE(regulators); i++) { if (strcmp(regulator_name, regulators[i].name) == 0) { - dev = rdevtbl[i]; + *dev = rdevtbl[i]; return 0; } } @@ -348,7 +348,7 @@ static int tps65219_regulator_probe(struct platform_device *pdev) irq_data[i].dev = tps->dev; irq_data[i].type = irq_type; - tps65219_get_rdev_by_name(irq_type->regulator_name, rdevtbl, rdev); + tps65219_get_rdev_by_name(irq_type->regulator_name, rdevtbl, &rdev); if (IS_ERR(rdev)) { dev_err(tps->dev, "Failed to get rdev for %s\n", irq_type->regulator_name); -- 2.34.1

1 year, 6 months

3
2
0 0

10X Leads at Design Automation Conference – DAC 2023

by Michelle Brown

Would you like to purchase the Design Automation Conference – DAC 2023 Attendees contact list with verified emails and phone numbers? Attendees include Professionals from : * Institute of Electrical and Electronics Engineers (IEEE) * Special Interest Group on Design Automation (SIGDA) * Council on Electronic Design Automation (CEDA) * Designers * Researchers * Tool Developers * Vendors * And Many More What you are interested in… We can also provide you with Custom-Built Lists based on your target audience such as based on Industry, SIC Code, NAICS Code, Revenue, Job Titles and many more… If you are looking for anything else, please let us know and I will have our team run some counts along with a few samples at no cost. The list will include complete contact information such as Company Name, Contact Name, Email Address, Phone Number, Job Titles, Mailing Address, City, State, ZIP, Industry, Revenue etc. Please let us know if you require any additional information. Regards, Michelle Brown |Lead Generation Specialist Alfabet Events Disclaimer: If you do not wish to receive emails from us, please reply to this email with ‘OPT OUT’

1 year, 6 months

1
2
0 0

[PATCHv2 dlm/next] fs: dlm: fix nfs async lock callback handling

by Alexander Aring

This patch is fixing the current the callback handling if a nfs async lock request signaled if fl_lmops is set. When using `stress-ng --fcntl 32` on the kernel log there are several messages like: [11185.123533] dlm: dlm_plock_callback: vfs lock error 5d5127 file 000000002dd10f4d fl 000000007d13afae [11185.127135] dlm: dlm_plock_callback: vfs lock error 5d5127 file 000000002dd10f4d fl 00000000a6046fa0 [11185.142668] dlm: dlm_plock_callback: vfs lock error 5d5127 file 000000002dd10f4d fl 000000001d13dfa5 The commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock") removed the FL_SLEEP handling if the filesystem implements its own ->lock. The strategy is now that the most clients polling blocked requests by using trylock functionality. Before commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock") FL_SLEEP was used even with an own ->lock() callback. The fs implementation needed to handle it to make a difference between a blocking and non-blocking lock request. This was never being implemented in such way in DLM plock handling. Every lock request doesn't matter if it was a blocking request or not was handled as a non-blocking lock request. This patch fixes the behaviour until commit 40595cdc93ed ("nfs: block notification on fs with its own ->lock"), but it was probably broken long time before. Fixes: 40595cdc93ed ("nfs: block notification on fs with its own ->lock") Cc: stable(a)vger.kernel.org Signed-off-by: Alexander Aring <aahringo(a)redhat.com> --- changes since v2: - rephrase commit msg - add cc stable fs/dlm/plock.c | 22 +--------------------- 1 file changed, 1 insertion(+), 21 deletions(-) diff --git a/fs/dlm/plock.c b/fs/dlm/plock.c index 70a4752ed913..6f0ecb2176b0 100644 --- a/fs/dlm/plock.c +++ b/fs/dlm/plock.c @@ -217,27 +217,7 @@ static int dlm_plock_callback(struct plock_op *op) fl = op_data->fl; notify = op_data->callback; - if (op->info.rv) { - notify(fl, op->info.rv); - goto out; - } - - /* got fs lock; bookkeep locally as well: */ - flc->fl_flags &= ~FL_SLEEP; - if (posix_lock_file(file, flc, NULL)) { - /* - * This can only happen in the case of kmalloc() failure. - * The filesystem's own lock is the authoritative lock, - * so a failure to get the lock locally is not a disaster. - * As long as the fs cannot reliably cancel locks (especially - * in a low-memory situation), we're better off ignoring - * this failure than trying to recover. - */ - log_print("dlm_plock_callback: vfs lock error %llx file %p fl %p", - (unsigned long long)op->info.number, file, fl); - } - - rv = notify(fl, 0); + rv = notify(fl, op->info.rv); if (rv) { /* XXX: We need to cancel the fs lock here: */ log_print("dlm_plock_callback: lock granted after lock request " -- 2.31.1

1 year, 6 months

1
1
0 0

[PATCH v3 2/2] net/ncsi: change from ndo_set_mac_address to dev_set_mac_address

by Ivan Mikhaylov

Change ndo_set_mac_address to dev_set_mac_address because dev_set_mac_address provides a way to notify network layer about MAC change. In other case, services may not aware about MAC change and keep using old one which set from network adapter driver. As example, DHCP client from systemd do not update MAC address without notification from net subsystem which leads to the problem with acquiring the right address from DHCP server. Fixes: cb10c7c0dfd9e ("net/ncsi: Add NCSI Broadcom OEM command") Cc: stable(a)vger.kernel.org # v6.0+ 2f38e84 net/ncsi: make one oem_gma function for all mfr id Signed-off-by: Paul Fertser <fercerpav(a)gmail.com> Signed-off-by: Ivan Mikhaylov <fr0st61te(a)gmail.com> --- net/ncsi/ncsi-rsp.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/net/ncsi/ncsi-rsp.c b/net/ncsi/ncsi-rsp.c index 91c42253a711..069c2659074b 100644 --- a/net/ncsi/ncsi-rsp.c +++ b/net/ncsi/ncsi-rsp.c @@ -616,7 +616,6 @@ static int ncsi_rsp_handler_oem_gma(struct ncsi_request *nr, int mfr_id) { struct ncsi_dev_priv *ndp = nr->ndp; struct net_device *ndev = ndp->ndev.dev; - const struct net_device_ops *ops = ndev->netdev_ops; struct ncsi_rsp_oem_pkt *rsp; struct sockaddr saddr; u32 mac_addr_off = 0; @@ -643,7 +642,9 @@ static int ncsi_rsp_handler_oem_gma(struct ncsi_request *nr, int mfr_id) /* Set the flag for GMA command which should only be called once */ ndp->gma_flag = 1; - ret = ops->ndo_set_mac_address(ndev, &saddr); + rtnl_lock(); + ret = dev_set_mac_address(ndev, &saddr, NULL); + rtnl_unlock(); if (ret < 0) netdev_warn(ndev, "NCSI: 'Writing mac address to device failed\n"); -- 2.40.1

1 year, 6 months

2
1
0 0

[PATCH v4] ceph: fix use-after-free bug for inodes when flushing capsnaps

by xiubli＠redhat.com

From: Xiubo Li <xiubli(a)redhat.com> There is a race between capsnaps flush and removing the inode from 'mdsc->snap_flush_list' list: == Thread A == == Thread B == ceph_queue_cap_snap() -> allocate 'capsnapA' ->ihold('&ci->vfs_inode') ->add 'capsnapA' to 'ci->i_cap_snaps' ->add 'ci' to 'mdsc->snap_flush_list' ... == Thread C == ceph_flush_snaps() ->__ceph_flush_snaps() ->__send_flush_snap() handle_cap_flushsnap_ack() ->iput('&ci->vfs_inode') this also will release 'ci' ... == Thread D == ceph_handle_snap() ->flush_snaps() ->iterate 'mdsc->snap_flush_list' ->get the stale 'ci' ->remove 'ci' from ->ihold(&ci->vfs_inode) this 'mdsc->snap_flush_list' will WARNING To fix this we will increase the inode's i_count ref when adding 'ci' to the 'mdsc->snap_flush_list' list. Cc: stable(a)vger.kernel.org URL: https://bugzilla.redhat.com/show_bug.cgi?id=2209299 Reviewed-by: Milind Changire <mchangir(a)redhat.com> Signed-off-by: Xiubo Li <xiubli(a)redhat.com> --- V4: - s/put/need_put/ fs/ceph/caps.c | 6 ++++++ fs/ceph/snap.c | 4 +++- 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/fs/ceph/caps.c b/fs/ceph/caps.c index 8c1fc64b290c..bb78d0fbfa62 100644 --- a/fs/ceph/caps.c +++ b/fs/ceph/caps.c @@ -1684,6 +1684,7 @@ void ceph_flush_snaps(struct ceph_inode_info *ci, struct inode *inode = &ci->netfs.inode; struct ceph_mds_client *mdsc = ceph_inode_to_client(inode)->mdsc; struct ceph_mds_session *session = NULL; + int need_put = 0; int mds; dout("ceph_flush_snaps %p\n", inode); @@ -1728,8 +1729,13 @@ void ceph_flush_snaps(struct ceph_inode_info *ci, ceph_put_mds_session(session); /* we flushed them all; remove this inode from the queue */ spin_lock(&mdsc->snap_flush_lock); + if (!list_empty(&ci->i_snap_flush_item)) + need_put++; list_del_init(&ci->i_snap_flush_item); spin_unlock(&mdsc->snap_flush_lock); + + if (need_put) + iput(inode); } /* diff --git a/fs/ceph/snap.c b/fs/ceph/snap.c index 7943981914cf..e03b020d87d7 100644 --- a/fs/ceph/snap.c +++ b/fs/ceph/snap.c @@ -697,8 +697,10 @@ int __ceph_finish_cap_snap(struct ceph_inode_info *ci, capsnap->size); spin_lock(&mdsc->snap_flush_lock); - if (list_empty(&ci->i_snap_flush_item)) + if (list_empty(&ci->i_snap_flush_item)) { + ihold(inode); list_add_tail(&ci->i_snap_flush_item, &mdsc->snap_flush_list); + } spin_unlock(&mdsc->snap_flush_lock); return 1; /* caller may want to ceph_flush_snaps */ } -- 2.40.1

1 year, 6 months

3
2
0 0

soft lockup on Ampere Altra on v6.1.30

by Jeremi Piotrowski

We're currently trying to update the kernel in our distro (Flatcar) from v5.15.x to v6.1.x. When testing on Equinix Metal Ampere instances (c3.large.arm64) we now get a soft lockup about a minute after boot. Has anyone else seen this? The splat looks like this, full dmesg is at [1] (trying without the attachement this time as LKML detects my mail as spam :/) [ 84.297829] watchdog: BUG: soft lockup - CPU#45 stuck for 26s! [kworker/45:1:474] [ 84.297834] Modules linked in: veth xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink bonding mlx5_ib ipmi_ssif ipmi_devintf ib_core ipmi_msghandler evdev sch_fq_codel fuse configfs dmi_sysfs nls_ascii nls_cp437 vfat fat ext4 crc16 mbcache jbd2 dm_verity dm_bufio nvme nvme_core xhci_pci t10_pi xhci_hcd crc64_rocksoft_generic crc64_rocksoft igb crc_t10dif i2c_algo_bit crct10dif_generic mlx5_core usbcore i2c_core crc64 crct10dif_common usb_common hwmon pci_hyperv_intf btrfs blake2b_generic xor xor_neon lzo_compress zlib_deflate raid6_pq zstd_compress libcrc32c crc32c_generic dm_mirror dm_region_hash dm_log qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi dm_multipath dm_mod scsi_mod scsi_common br_netfilter bridge stp llc overlay [ 84.435381] CPU: 45 PID: 474 Comm: kworker/45:1 Not tainted 6.1.30-flatcar #1 [ 84.447678] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F17a (SCP: 1.07.20210713) 07/22/2021 [ 84.467226] Workqueue: rcu_par_gp sync_rcu_exp_select_node_cpus [ 84.478239] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 84.490336] pc : smp_call_function_single+0xe4/0x1d0 [ 84.500287] lr : __sync_rcu_exp_select_node_cpus+0x278/0x480 [ 84.510869] sp : ffff80000b99bcc0 [ 84.518979] x29: ffff80000b99bcc0 x28: 0000000000000200 x27: ffffab5be3134080 [ 84.530897] x26: ffffab5be302d6a8 x25: ffff07ff89f01f40 x24: ffff083e5fba8540 [ 84.542751] x23: ffffab5be2e43ab0 x22: 0000000000000a00 x21: ffffab5be2e47540 [ 84.554510] x20: 000000000000f5ff x19: ffff80000b99bce0 x18: ffff80002be3bc58 [ 84.566213] x17: 0000000000000000 x16: ffffab5be06cdfc0 x15: 0000000000000001 [ 84.577841] x14: 0000000000000000 x13: 0000000000000010 x12: ffffab5be2e43ab0 [ 84.589361] x11: 0000000000000001 x10: 0000000000000040 x9 : ffffab5be312c270 [ 84.600832] x8 : ffffab5be2e34008 x7 : 0000000000028fb0 x6 : ffffab5bdfd0ef20 [ 84.612285] x5 : 0000000000000000 x4 : ffff083e5fc1c748 x3 : 0000000000000001 [ 84.623812] x2 : 0000000000000000 x1 : ffff083e5fc1c740 x0 : 0000000000000029 [ 84.635277] Call trace: [ 84.641994] smp_call_function_single+0xe4/0x1d0 [ 84.650957] __sync_rcu_exp_select_node_cpus+0x278/0x480 [ 84.660664] sync_rcu_exp_select_node_cpus+0x14/0x20 [ 84.669988] process_one_work+0x214/0x490 [ 84.678313] worker_thread+0x6c/0x430 [ 84.686206] kthread+0x108/0x10c [ 84.693668] ret_from_fork+0x10/0x20 [ 84.701417] Kernel panic - not syncing: softlockup: hung tasks [ 84.711437] CPU: 45 PID: 474 Comm: kworker/45:1 Tainted: G L 6.1.30-flatcar #1 [ 84.724261] Hardware name: GIGABYTE R272-P30-JG/MP32-AR0-JG, BIOS F17a (SCP: 1.07.20210713) 07/22/2021 [ 84.741870] Workqueue: rcu_par_gp sync_rcu_exp_select_node_cpus [ 84.751900] Call trace: [ 84.758325] dump_backtrace+0xe0/0x140 [ 84.765958] show_stack+0x18/0x30 [ 84.773057] dump_stack_lvl+0x64/0x80 [ 84.780384] dump_stack+0x18/0x34 [ 84.787220] panic+0x180/0x358 [ 84.793698] watchdog_nmi_enable+0x0/0x10 [ 84.801040] __hrtimer_run_queues+0x17c/0x340 [ 84.808624] hrtimer_interrupt+0xe8/0x244 [ 84.815807] arch_timer_handler_phys+0x2c/0x44 [ 84.823388] handle_percpu_devid_irq+0x88/0x230 [ 84.830995] generic_handle_domain_irq+0x2c/0x44 [ 84.838682] gic_handle_irq+0x50/0x140 [ 84.845468] call_on_irq_stack+0x24/0x4c [ 84.852402] do_interrupt_handler+0x80/0x84 [ 84.859569] el1_interrupt+0x34/0x6c [ 84.866100] el1h_64_irq_handler+0x18/0x2c [ 84.873134] el1h_64_irq+0x64/0x68 [ 84.879415] smp_call_function_single+0xe4/0x1d0 [ 84.886933] __sync_rcu_exp_select_node_cpus+0x278/0x480 [ 84.895205] sync_rcu_exp_select_node_cpus+0x14/0x20 [ 84.903118] process_one_work+0x214/0x490 [ 84.910040] worker_thread+0x6c/0x430 [ 84.916645] kthread+0x108/0x10c [ 84.922733] ret_from_fork+0x10/0x20 Thanks, Jeremi [1]: https://gist.githubusercontent.com/dongsupark/3ab5fc464a995623a14542edd9b19…

1 year, 6 months

3
6
0 0

[PATCH v2] fs: avoid empty option when generating legacy mount string

by Thomas Weißschuh

As each option string fragment is always prepended with a comma it would happen that the whole string always starts with a comma. This could be interpreted by filesystem drivers as an empty option and may produce errors. For example the NTFS driver from ntfs.ko behaves like this and fails when mounted via the new API. Link: https://github.com/util-linux/util-linux/issues/2298 Fixes: 3e1aeb00e6d1 ("vfs: Implement a filesystem superblock creation/configuration context") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Changes in v2: - Mention Cc stable@ in sign-off area - Link to v1: https://lore.kernel.org/r/20230607-fs-empty-option-v1-1-20c8dbf4671b@weisss… --- fs/fs_context.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/fs_context.c b/fs/fs_context.c index 24ce12f0db32..851214d1d013 100644 --- a/fs/fs_context.c +++ b/fs/fs_context.c @@ -561,7 +561,8 @@ static int legacy_parse_param(struct fs_context *fc, struct fs_parameter *param) return -ENOMEM; } - ctx->legacy_data[size++] = ','; + if (size) + ctx->legacy_data[size++] = ','; len = strlen(param->key); memcpy(ctx->legacy_data + size, param->key, len); size += len; --- base-commit: 9561de3a55bed6bdd44a12820ba81ec416e705a7 change-id: 20230607-fs-empty-option-265622371023 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

1 year, 6 months

2
1
0 0

[PATCH v6 1/2] usb: gadget: udc: core: Offload usb_udc_vbus_handler processing

by Badhri Jagan Sridharan

usb_udc_vbus_handler() can be invoked from interrupt context by irq handlers of the gadget drivers, however, usb_udc_connect_control() has to run in non-atomic context due to the following: a. Some of the gadget driver implementations expect the ->pullup callback to be invoked in non-atomic context. b. usb_gadget_disconnect() acquires udc_lock which is a mutex. Hence offload invocation of usb_udc_connect_control() to workqueue. UDC should not be pulled up unless gadget driver is bound. The new flag "allow_connect" is now set by gadget_bind_driver() and cleared by gadget_unbind_driver(). This prevents work item to pull up the gadget even if queued when the gadget driver is already unbound. Cc: stable(a)vger.kernel.org Fixes: 1016fc0c096c ("USB: gadget: Fix obscure lockdep violation for udc_mutex") Signed-off-by: Badhri Jagan Sridharan <badhri(a)google.com> --- Changes since v1: - Address Alan Stern's comment on usb_udc_vbus_handler invocation from atomic context: * vbus_events_lock is now a spinlock and allocations in * usb_udc_vbus_handler are atomic now. Changes since v2: - Addressing Alan Stern's comments: ** connect_lock is now held by callers of * usb_gadget_pullup_update_locked() and gadget_(un)bind_driver() does * notdirectly hold the lock. ** Both usb_gadget_(dis)connect() and usb_udc_vbus_handler() would * set/clear udc->vbus and invoke usb_gadget_pullup_update_locked. ** Add "unbinding" to prevent new connections after the gadget is being * unbound. Changes since v3: ** Made a minor cleanup which I missed to do in v3 in * usb_udc_vbus_handler(). Changes since v4: - Addressing Alan Stern's comments: ** usb_udc_vbus_handler() now offloads invocation of usb_udc_connect_control() * from workqueue. ** Dropped vbus_events list as this was redundant. Updating to the * latest value is suffice Changes since v5: - Addressing Alan Stern's comments: ** Squashed allow_connect logic to this patch. ** Fixed comment length to wrap at 76 ** Cancelling vbus_work in del_gadget() --- drivers/usb/gadget/udc/core.c | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/usb/gadget/udc/core.c b/drivers/usb/gadget/udc/core.c index 52e6d2e84e35..d2e4f78c53e3 100644 --- a/drivers/usb/gadget/udc/core.c +++ b/drivers/usb/gadget/udc/core.c @@ -37,6 +37,9 @@ static const struct bus_type gadget_bus_type; * @vbus: for udcs who care about vbus status, this value is real vbus status; * for udcs who do not care about vbus status, this value is always true * @started: the UDC's started state. True if the UDC had started. + * @allow_connect: Indicates whether UDC is allowed to be pulled up. + * Set/cleared by gadget_(un)bind_driver() after gadget driver is bound or + * unbound. * * This represents the internal data structure which is used by the UDC-class * to hold information about udc driver and gadget together. @@ -48,6 +51,8 @@ struct usb_udc { struct list_head list; bool vbus; bool started; + bool allow_connect; + struct work_struct vbus_work; }; static struct class *udc_class; @@ -706,7 +711,7 @@ int usb_gadget_connect(struct usb_gadget *gadget) goto out; } - if (gadget->deactivated) { + if (gadget->deactivated || !gadget->udc->allow_connect) { /* * If gadget is deactivated we only save new state. * Gadget will be connected automatically after activation. @@ -1086,6 +1091,13 @@ static void usb_udc_connect_control(struct usb_udc *udc) usb_gadget_disconnect(udc->gadget); } +static void vbus_event_work(struct work_struct *work) +{ + struct usb_udc *udc = container_of(work, struct usb_udc, vbus_work); + + usb_udc_connect_control(udc); +} + /** * usb_udc_vbus_handler - updates the udc core vbus status, and try to * connect or disconnect gadget @@ -1094,6 +1106,14 @@ static void usb_udc_connect_control(struct usb_udc *udc) * * The udc driver calls it when it wants to connect or disconnect gadget * according to vbus status. + * + * This function can be invoked from interrupt context by irq handlers of + * the gadget drivers, however, usb_udc_connect_control() has to run in + * non-atomic context due to the following: + * a. Some of the gadget driver implementations expect the ->pullup + * callback to be invoked in non-atomic context. + * b. usb_gadget_disconnect() acquires udc_lock which is a mutex. + * Hence offload invocation of usb_udc_connect_control() to workqueue. */ void usb_udc_vbus_handler(struct usb_gadget *gadget, bool status) { @@ -1101,7 +1121,7 @@ void usb_udc_vbus_handler(struct usb_gadget *gadget, bool status) if (udc) { udc->vbus = status; - usb_udc_connect_control(udc); + schedule_work(&udc->vbus_work); } } EXPORT_SYMBOL_GPL(usb_udc_vbus_handler); @@ -1328,6 +1348,7 @@ int usb_add_gadget(struct usb_gadget *gadget) mutex_lock(&udc_lock); list_add_tail(&udc->list, &udc_list); mutex_unlock(&udc_lock); + INIT_WORK(&udc->vbus_work, vbus_event_work); ret = device_add(&udc->dev); if (ret) @@ -1459,6 +1480,7 @@ void usb_del_gadget(struct usb_gadget *gadget) flush_work(&gadget->work); device_del(&gadget->dev); ida_free(&gadget_id_numbers, gadget->id_number); + cancel_work_sync(&udc->vbus_work); device_unregister(&udc->dev); } EXPORT_SYMBOL_GPL(usb_del_gadget); @@ -1527,6 +1549,7 @@ static int gadget_bind_driver(struct device *dev) if (ret) goto err_start; usb_gadget_enable_async_callbacks(udc); + udc->allow_connect = true; usb_udc_connect_control(udc); kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE); @@ -1558,6 +1581,8 @@ static void gadget_unbind_driver(struct device *dev) kobject_uevent(&udc->dev.kobj, KOBJ_CHANGE); + udc->allow_connect = false; + cancel_work_sync(&udc->vbus_work); usb_gadget_disconnect(gadget); usb_gadget_disable_async_callbacks(udc); if (gadget->irq) base-commit: 922c0cb578ac9104a22c11a093cc1e0575c35a39 -- 2.41.0.rc0.172.g3f132b7071-goog

1 year, 6 months

2
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2023