Select Git revision
Search by author
- Any Author
- authors
-
72162444 72162444 gaochangning
-
Aakash Dave aakash.dave
-
Aaron Kim akim
-
Aaron Kloc akloc
-
Aaron Lan aaron.lan
-
Aaron Nabil aaronna
-
Aaron Pohle aaron.pohle
-
Abbott Chung chung.abbott
-
Abdallah Omar abdallah_omar
-
Abdessamii Chalbi abdessamii.chalbi
-
Abdul Hussain Sirajudeen abdul.hussain
-
Abdullah Alghamdi a.alghamdi
-
Abdullah Elmarghany abdullah_elmarghany
-
Abel Fang abel_fang
-
Abel Vesa
abel.vesa
-
Abhijeet Badurkar abhijeet.badurkar
-
Abhijit Adsule adsule
-
Abhijit Murthy abhijit
-
Abhi Khanal akhanal
-
Abhilash Sahoo abhilashsahoo
- Mar 15, 2024
-
-
Prakash Sangappa authored
[ Upstream commit e656c7a9 ] For shared memory of type SHM_HUGETLB, hugetlb pages are reserved in shmget() call. If SHM_NORESERVE flags is specified then the hugetlb pages are not reserved. However when the shared memory is attached with the shmat() call the hugetlb pages are getting reserved incorrectly for SHM_HUGETLB shared memory created with SHM_NORESERVE which is a bug. ------------------------------- Following test shows the issue. $cat shmhtb.c int main() { int shmflags = 0660 | IPC_CREAT | SHM_HUGETLB | SHM_NORESERVE; int shmid; shmid = shmget(SKEY, SHMSZ, shmflags); if (shmid < 0) { printf("shmat: shmget() failed, %d\n", errno); return 1; } printf("After shmget()\n"); system("cat /proc/meminfo | grep -i hugepages_"); shmat(shmid, NULL, 0); printf("\nAfter shmat()\n"); system("cat /proc/meminfo | grep -i hugepages_"); shmctl(shmid, IPC_RMID, NULL); return 0; } #sysctl -w vm.nr_hugepages=20 #./shmhtb After shmget() HugePages_Total: 20 HugePages_Free: 20 HugePages_Rsvd: 0 HugePages_Surp: 0 After shmat() HugePages_Total: 20 HugePages_Free: 20 HugePages_Rsvd: 5 <-- HugePages_Surp: 0 -------------------------------- Fix is to ensure that hugetlb pages are not reserved for SHM_HUGETLB shared memory in the shmat() call. Link: https://lkml.kernel.org/r/1706040282-12388-1-git-send-email-prakash.sangappa@oracle.com Signed-off-by:
Prakash Sangappa <prakash.sangappa@oracle.com> Acked-by:
Muchun Song <muchun.song@linux.dev> Cc: <stable@vger.kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Mike Kravetz authored
[ Upstream commit 33b8f84a ] While reviewing a bug in hugetlb_reserve_pages, it was noticed that all callers ignore the return value. Any failure is considered an ENOMEM error by the callers. Change the function to be of type bool. The function will return true if the reservation was successful, false otherwise. Callers currently assume a zero return code indicates success. Change the callers to look for true to indicate success. No functional change, only code cleanup. Link: https://lkml.kernel.org/r/20201221192542.15732-1-mike.kravetz@oracle.com Signed-off-by:
Mike Kravetz <mike.kravetz@oracle.com> Reviewed-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Cc: David Hildenbrand <david@redhat.com> Cc: Dan Carpenter <dan.carpenter@oracle.com> Cc: Michal Hocko <mhocko@kernel.org> Cc: Davidlohr Bueso <dave@stgolabs.net> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Stable-dep-of: e656c7a9 ("mm: hugetlb pages should not be reserved by shmat() if SHM_NORESERVE") Signed-off-by:
-
Shradha Gupta authored
[ Upstream commit 9cae43da ] If hv_netvsc driver is unloaded and reloaded, the NET_DEVICE_REGISTER handler cannot perform VF register successfully as the register call is received before netvsc_probe is finished. This is because we register register_netdevice_notifier() very early( even before vmbus_driver_register()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvsc_probe. Cc: stable@vger.kernel.org Fixes: 85520856 ("hv_netvsc: Fix race of register_netdevice_notifier and VF register") Suggested-by:
Dexuan Cui <decui@microsoft.com> Signed-off-by:
Shradha Gupta <shradhagupta@linux.microsoft.com> Reviewed-by:
Haiyang Zhang <haiyangz@microsoft.com> Reviewed-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Juhee Kang authored
[ Upstream commit c60882a4 ] Use netif_is_bond_master() function instead of open code, which is ((event_dev->priv_flags & IFF_BONDING) && (event_dev->flags & IFF_MASTER)). This patch doesn't change logic. Signed-off-by:
Juhee Kang <claudiajkang@gmail.com> Signed-off-by:
-
Dexuan Cui authored
[ Upstream commit 64ff412a ] Currently the netvsc/VF binding logic only checks the PCI serial number. The Microsoft Azure Network Adapter (MANA) supports multiple net_device interfaces (each such interface is called a "vPort", and has its unique MAC address) which are backed by the same VF PCI device, so the binding logic should check both the MAC address and the PCI serial number. The change should not break any other existing VF drivers, because Hyper-V NIC SR-IOV implementation requires the netvsc network interface and the VF network interface have the same MAC address. Co-developed-by:
Shachar Raindel <shacharr@microsoft.com> Signed-off-by:
Stephen Hemminger <stephen@networkplumber.org> Signed-off-by:
-
Long Li authored
[ Upstream commit 34b06a2e ] On VF hot remove, NETDEV_GOING_DOWN is sent to notify the VF is about to go down. At this time, the VF is still sending/receiving traffic and we request the VSP to switch datapath. On completion, the datapath is switched to synthetic and we can proceed with VF hot remove. Signed-off-by:
Long Li <longli@microsoft.com> Reviewed-by:
Jakub Kicinski <kuba@kernel.org> Stable-dep-of: 9cae43da ("hv_netvsc: Register VF in netvsc_probe if NET_DEVICE_REGISTER missed") Signed-off-by:
-
Long Li authored
[ Upstream commit 8b31f8c9 ] The completion indicates if NVSP_MSG4_TYPE_SWITCH_DATA_PATH has been processed by the VSP. The traffic is steered to VF or synthetic after we receive this completion. Signed-off-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Andres Beltran authored
[ Upstream commit 4d18fcc9 ] Currently, pointers to guest memory are passed to Hyper-V as transaction IDs in netvsc. In the face of errors or malicious behavior in Hyper-V, netvsc should not expose or trust the transaction IDs returned by Hyper-V to be valid guest memory addresses. Instead, use small integers generated by vmbus_requestor as requests (transaction) IDs. Signed-off-by:
Andres Beltran <lkmlabelt@gmail.com> Co-developed-by:
Andrea Parri (Microsoft) <parri.andrea@gmail.com> Signed-off-by:
Michael Kelley <mikelley@microsoft.com> Acked-by:
Wei Liu <wei.liu@kernel.org> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Cc: netdev@vger.kernel.org Link: https://lore.kernel.org/r/20201109100402.8946-4-parri.andrea@gmail.com Signed-off-by:
-
Andres Beltran authored
[ Upstream commit e8b7db38 ] Currently, VMbus drivers use pointers into guest memory as request IDs for interactions with Hyper-V. To be more robust in the face of errors or malicious behavior from a compromised Hyper-V, avoid exposing guest memory addresses to Hyper-V. Also avoid Hyper-V giving back a bad request ID that is then treated as the address of a guest data structure with no validation. Instead, encapsulate these memory addresses and provide small integers as request IDs. Signed-off-by:
-
Zhang Yi authored
[ Upstream commit acf795dc ] ext4_da_map_blocks() only hold i_data_sem in shared mode and i_rwsem when inserting delalloc extents, it could be raced by another querying path of ext4_map_blocks() without i_rwsem, .e.g buffered read path. Suppose we buffered read a file containing just a hole, and without any cached extents tree, then it is raced by another delayed buffered write to the same area or the near area belongs to the same hole, and the new delalloc extent could be overwritten to a hole extent. pread() pwrite() filemap_read_folio() ext4_mpage_readpages() ext4_map_blocks() down_read(i_data_sem) ext4_ext_determine_hole() //find hole ext4_ext_put_gap_in_cache() ext4_es_find_extent_range() //no delalloc extent ext4_da_map_blocks() down_read(i_data_sem) ext4_insert_delayed_block() //insert delalloc extent ext4_es_insert_extent() //overwrite delalloc extent to hole This race could lead to inconsistent delalloc extents tree and incorrect reserved space counter. Fix this by converting to hold i_data_sem in exclusive mode when adding a new delalloc extent in ext4_da_map_blocks(). Cc: stable@vger.kernel.org Signed-off-by:
Zhang Yi <yi.zhang@huawei.com> Suggested-by:
Jan Kara <jack@suse.cz> Reviewed-by:
Theodore Ts'o <tytso@mit.edu> Signed-off-by:
-
Zhang Yi authored
[ Upstream commit 3fcc2b88 ] Refactor and cleanup ext4_da_map_blocks(), reduce some unnecessary parameters and branches, no logic changes. Signed-off-by:
-
Baokun Li authored
[ Upstream commit 6c120399 ] Now ext4_es_insert_extent() never return error, so make it return void. Signed-off-by:
Baokun Li <libaokun1@huawei.com> Reviewed-by:
-
Ondrej Mosnacek authored
[ Upstream commit 5a287d3d ] For these hooks the true "neutral" value is -EOPNOTSUPP, which is currently what is returned when no LSM provides this hook and what LSMs return when there is no security context set on the socket. Correct the value in <linux/lsm_hooks.h> and adjust the dispatch functions in security/security.c to avoid issues when the BPF LSM is enabled. Cc: stable@vger.kernel.org Fixes: 98e828a0 ("security: Refactor declaration of LSM hooks") Signed-off-by:
Ondrej Mosnacek <omosnace@redhat.com> [PM: subject line tweak] Signed-off-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
Paul Moore authored
[ Upstream commit b10b9c34 ] Commit 4ff09db1 ("bpf: net: Change sk_getsockopt() to take the sockptr_t argument") made it possible to call sk_getsockopt() with both user and kernel address space buffers through the use of the sockptr_t type. Unfortunately at the time of conversion the security_socket_getpeersec_stream() LSM hook was written to only accept userspace buffers, and in a desire to avoid having to change the LSM hook the commit author simply passed the sockptr_t's userspace buffer pointer. Since the only sk_getsockopt() callers at the time of conversion which used kernel sockptr_t buffers did not allow SO_PEERSEC, and hence the security_socket_getpeersec_stream() hook, this was acceptable but also very fragile as future changes presented the possibility of silently passing kernel space pointers to the LSM hook. There are several ways to protect against this, including careful code review of future commits, but since relying on code review to catch bugs is a recipe for disaster and the upstream eBPF maintainer is "strongly against defensive programming", this patch updates the LSM hook, and all of the implementations to support sockptr_t and safely handle both user and kernel space buffers. Acked-by:
Casey Schaufler <casey@schaufler-ca.com> Acked-by:
John Johansen <john.johansen@canonical.com> Signed-off-by:
-
Martin KaFai Lau authored
[ Upstream commit 4ff09db1 ] This patch changes sk_getsockopt() to take the sockptr_t argument such that it can be used by bpf_getsockopt(SOL_SOCKET) in a latter patch. security_socket_getpeersec_stream() is not changed. It stays with the __user ptr (optval.user and optlen.user) to avoid changes to other security hooks. bpf_getsockopt(SOL_SOCKET) also does not support SO_PEERSEC. Signed-off-by:
Martin KaFai Lau <martin.lau@kernel.org> Link: https://lore.kernel.org/r/20220902002802.2888419-1-kafai@fb.com Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Stable-dep-of: 5a287d3d ("lsm: fix default return value of the socket_getpeersec_*() hooks") Signed-off-by:
-
Martin KaFai Lau authored
[ Upstream commit ba74a760 ] A latter patch refactors bpf_getsockopt(SOL_SOCKET) with the sock_getsockopt() to avoid code duplication and code drift between the two duplicates. The current sock_getsockopt() takes sock ptr as the argument. The very first thing of this function is to get back the sk ptr by 'sk = sock->sk'. bpf_getsockopt() could be called when the sk does not have the sock ptr created. Meaning sk->sk_socket is NULL. For example, when a passive tcp connection has just been established but has yet been accept()-ed. Thus, it cannot use the sock_getsockopt(sk->sk_socket) or else it will pass a NULL ptr. This patch moves all sock_getsockopt implementation to the newly added sk_getsockopt(). The new sk_getsockopt() takes a sk ptr and immediately gets the sock ptr by 'sock = sk->sk_socket' The existing sock_getsockopt(sock) is changed to call sk_getsockopt(sock->sk). All existing callers have both sock->sk and sk->sk_socket pointer. The latter patch will make bpf_getsockopt(SOL_SOCKET) call sk_getsockopt(sk) directly. The bpf_getsockopt(SOL_SOCKET) does not use the optnames that require sk->sk_socket, so it will be safe. Signed-off-by:
-
Hugo Villeneuve authored
[ Upstream commit b35f8dbb ] If there is a problem after resetting a port, the do/while() loop that checks the default value of DIVLSB register may run forever and spam the I2C bus. Add a delay before each read of DIVLSB, and a maximum number of tries to prevent that situation from happening. Also fail probe if port reset is unsuccessful. Fixes: 10d8b34a ("serial: max310x: Driver rework") Cc: stable@vger.kernel.org Signed-off-by:
Hugo Villeneuve <hvilleneuve@dimonoff.com> Link: https://lore.kernel.org/r/20240116213001.3691629-5-hugo@hugovil.com Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Cosmin Tanislav authored
[ Upstream commit 6ef281da ] The driver currently does manual register manipulation in multiple places to talk to a specific UART port. In order to talk to a specific UART port over SPI, the bits U1 and U0 of the register address can be set, as explained in the Command byte configuration section of the datasheet. Make this more elegant by creating regmaps for each UART port and setting the read_flag_mask and write_flag_mask accordingly. All communcations regarding global registers are done on UART port 0, so replace the global regmap entirely with the port 0 regmap. Also, remove the 0x1f masks from reg_writeable(), reg_volatile() and reg_precious() methods, since setting the U1 and U0 bits of the register address happens inside the regmap core now. Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-3-demonsingur@gmail.com Signed-off-by:
-
Cosmin Tanislav authored
[ Upstream commit 285e76fc ] The SPI batch read/write operations can be implemented as simple regmap raw read and write, which will also try to do a gather write just as it is done here. Use the regmap raw read and write methods. Reviewed-by:
-
Andy Shevchenko authored
[ Upstream commit c808fab6 ] Device property API allows to gather device resources from different sources, such as ACPI. Convert the drivers to unleash the power of device property API. Signed-off-by:
-
Hugo Villeneuve authored
[ Upstream commit 8afa6c6d ] A stable clock is really required in order to use this UART, so log an error message and bail out if the chip reports that the clock is not stable. Fixes: 4cf9a888 ("serial: max310x: Check the clock readiness") Cc: stable@vger.kernel.org Suggested-by:
Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://www.spinics.net/lists/linux-serial/msg35773.html Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit d4d6f03c ] In some configurations, mainly ACPI-based, the clock frequency of the device is supplied by very well established 'clock-frequency' property. Hence, try to get it from the property at last if no other providers are available. Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210517172930.83353-1-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 974e454d ] Simplify the code which fetches the input clock by using devm_clk_get_optional(). If no input clock is present devm_clk_get_optional() will return NULL instead of an error which matches the behavior of the old code. Signed-off-by:
-
Michal Pecio authored
[ Upstream commit 7c4650de ] xHCI 4.9 explicitly forbids assuming that the xHC has released its ownership of a multi-TRB TD when it reports an error on one of the early TRBs. Yet the driver makes such assumption and releases the TD, allowing the remaining TRBs to be freed or overwritten by new TDs. The xHC should also report completion of the final TRB due to its IOC flag being set by us, regardless of prior errors. This event cannot be recognized if the TD has already been freed earlier, resulting in "Transfer event TRB DMA ptr not part of current TD" error message. Fix this by reusing the logic for processing isoc Transaction Errors. This also handles hosts which fail to report the final completion. Fix transfer length reporting on Babble errors. They may be caused by device malfunction, no guarantee that the buffer has been filled. Signed-off-by:
Michal Pecio <michal.pecio@gmail.com> Cc: stable@vger.kernel.org Signed-off-by:
Mathias Nyman <mathias.nyman@linux.intel.com> Link: https://lore.kernel.org/r/20240125152737.2983959-5-mathias.nyman@linux.intel.com Signed-off-by:
-
Mathias Nyman authored
[ Upstream commit 5372c65e ] The last TRB of a isoc TD might not trigger an event if there was an error event for a TRB mid TD. This is seen on a NEC Corporation uPD720200 USB 3.0 Host After an error mid a multi-TRB TD the xHC should according to xhci 4.9.1 generate events for passed TRBs with IOC flag set if it proceeds to the next TD. This event is either a copy of the original error, or a "success" transfer event. If that event is missing then the driver and xHC host get out of sync as the driver is still expecting a transfer event for that first TD, while xHC host is already sending events for the next TD in the list. This leads to "Transfer event TRB DMA ptr not part of current TD" messages. As a solution we tag the isoc TDs that get error events mid TD. If an event doesn't match the first TD, then check if the tag is set, and event points to the next TD. In that case give back the fist TD and process the next TD normally Make sure TD status and transferred length stay valid in both cases with and without final TD completion event. Reported-by:
-
Mathias Nyman authored
[ Upstream commit e9fcb077 ] The same values are parsed several times from transfer and event TRBs by different functions in the same call path, all while processing one transfer event. As the TRBs are in DMA memory and can be accessed by the xHC host we want to avoid this to prevent double-fetch issues. To resolve this pass the already parsed values to the different functions in the path of parsing a transfer event Signed-off-by:
-
Mathias Nyman authored
[ Upstream commit 55f6153d ] When finishing a TD we walk the endpoint dequeue trb pointer until it matches the last TRB of the TD. TDs can contain over 100 TRBs, meaning we call a function 100 times, do a few comparisons and increase a couple values for each of these calls, all in interrupt context. This can all be avoided by adding a pointer to the last TRB segment, and a number of TRBs in the TD. So instead of walking through each TRB just set the new dequeue segment, pointer, and number of free TRBs directly. Getting rid of the while loop also reduces the risk of getting stuck in a infinite loop in the interrupt handler. Loop relied on valid matching dequeue and last_trb values to break. Signed-off-by:
-
Johannes Berg authored
[ Upstream commit 386093c6 ] There doesn't seem to be any reason for the rpath being set in the binaries, at on systems that I tested on. On the other hand, setting rpath is actually harming binaries in some cases, e.g. if using nix-based compilation environments where /lib & /lib64 are not part of the actual environment. Add a new Kconfig option (under EXPERT, for less user confusion) that allows disabling the rpath additions. Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
Richard Weinberger <richard@nod.at> Stable-dep-of: 846cfbee ("um: Fix adding '-no-pie' for clang") Signed-off-by:
-
Nico Pache authored
[ Upstream commit 91b80cc5 ] On systems with 64k page size and 512M huge page sizes, the allocation and test succeeds but errors out at the munmap. As the comment states, munmap will failure if its not HUGEPAGE aligned. This is due to the length of the mapping being 1/2 the size of the hugepage causing the munmap to not be hugepage aligned. Fix this by making the mapping length the full hugepage if the hugepage is larger than the length of the mapping. Link: https://lkml.kernel.org/r/20240119131429.172448-1-npache@redhat.com Signed-off-by:
Nico Pache <npache@redhat.com> Cc: Donet Tom <donettom@linux.vnet.ibm.com> Cc: Shuah Khan <shuah@kernel.org> Cc: Christophe Leroy <christophe.leroy@c-s.fr> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Muhammad Usama Anjum authored
[ Upstream commit bc29036e ] Running charge_reserved_hugetlb.sh generates errors if sh is set to dash: ./charge_reserved_hugetlb.sh: 9: [[: not found ./charge_reserved_hugetlb.sh: 19: [[: not found ./charge_reserved_hugetlb.sh: 27: [[: not found ./charge_reserved_hugetlb.sh: 37: [[: not found ./charge_reserved_hugetlb.sh: 45: Syntax error: "(" unexpected Switch to using /bin/bash instead of /bin/sh. Make the switch for write_hugetlb_memory.sh as well which is called from charge_reserved_hugetlb.sh. Link: https://lkml.kernel.org/r/20240116090455.3407378-1-usama.anjum@collabora.com Signed-off-by:
Muhammad Usama Anjum <usama.anjum@collabora.com> Cc: Muhammad Usama Anjum <usama.anjum@collabora.com> Cc: Shuah Khan <shuah@kernel.org> Cc: David Laight <David.Laight@ACULAB.COM> Cc: <stable@vger.kernel.org> Signed-off-by:
-
Jason Xing authored
[ Upstream commit d380ce70 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
Jason Xing <kernelxing@tencent.com> Signed-off-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
-
Jason Xing authored
[ Upstream commit bc76645e ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Jason Xing authored
[ Upstream commit b5dffcb8 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Jason Xing authored
[ Upstream commit f99b494b ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Jason Xing authored
[ Upstream commit a2e70684 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Jason Xing authored
[ Upstream commit 43547d86 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Jason Xing authored
[ Upstream commit 806f462b ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Jason Xing authored
[ Upstream commit e799299a ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Jason Xing authored
[ Upstream commit 60a7a152 ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
Jason Xing authored
[ Upstream commit 119cae5e ] We need to protect the reader reading the sysctl value because the value can be changed concurrently. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Signed-off-by:
-
