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 26, 2024
-
-
Andrew Ballance authored
[ Upstream commit dae4a017 ] With python 3.12, '\#' results in this warning SyntaxWarning: invalid escape sequence '\#' Signed-off-by:
Andrew Ballance <andrewjballance@gmail.com> Reviewed-by:
Justin Stitt <justinstitt@google.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Manuel Fombuena authored
[ Upstream commit 1741a826 ] Add support for the pointing stick (Accupoint) and 2 mouse buttons. Present on some Toshiba/dynabook Portege X30 and X40 laptops. It should close https://bugzilla.kernel.org/show_bug.cgi?id=205817 Signed-off-by:
Manuel Fombuena <fombuena@outlook.com> Signed-off-by:
Jiri Kosina <jkosina@suse.com> Signed-off-by:
-
Jiaxun Yang authored
[ Upstream commit 9d6e21dd ] Clear Cause.BD after we use instruction_pointer_set to override EPC. This can prevent exception_epc check against instruction code at new return address. It won't be considered as "in delay slot" after epc being overridden anyway. Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
-
Kunwu Chan authored
[ Upstream commit 3693bb44 ] kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. Signed-off-by:
Kunwu Chan <chentao@kylinos.cn> Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202401161119.iof6BQsf-lkp@intel.com/ Suggested-by:
Markus Elfring <Markus.Elfring@web.de> Reviewed-by:
Juergen Gross <jgross@suse.com> Link: https://lore.kernel.org/r/20240119094948.275390-1-chentao@kylinos.cn Signed-off-by:
-
Hans de Goede authored
[ Upstream commit 551539a8 ] The DMI strings used for the LattePanda board DMI quirks are very generic. Using the dmidecode database from https://linux-hardware.org/ shows that the chosen DMI strings also match the following 2 laptops which also have a rt5645 codec: Insignia NS-P11W7100 https://linux-hardware.org/?computer=E092FFF8BA04 Insignia NS-P10W8100 https://linux-hardware.org/?computer=AFB6C0BF7934 All 4 hw revisions of the LattePanda board have "S70CR" in their BIOS version DMI strings: DF-BI-7-S70CR100-* DF-BI-7-S70CR110-* DF-BI-7-S70CR200-* LP-BS-7-S70CR700-* See e.g. https://linux-hardware.org/?computer=D98250A817C0 Add a partial (non exact) DMI match on this string to make the LattePanda board DMI match more precise to avoid false-positive matches. Signed-off-by:
Hans de Goede <hdegoede@redhat.com> Link: https://msgid.link/r/20240211212736.179605-1-hdegoede@redhat.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Jakub Kicinski authored
[ Upstream commit 49d82106 ] This exact case was fail for async crypto and we weren't catching it. Signed-off-by:
Jakub Kicinski <kuba@kernel.org> Reviewed-by:
Simon Horman <horms@kernel.org> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Hou Tao authored
[ Upstream commit 87667336 ] When updating or deleting an inner map in map array or map htab, the map may still be accessed by non-sleepable program or sleepable program. However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map directly through bpf_map_put(), if the ref-counter is the last one (which is true for most cases), the inner map will be freed by ops->map_free() in a kworker. But for now, most .map_free() callbacks don't use synchronize_rcu() or its variants to wait for the elapse of a RCU grace period, so after the invocation of ops->map_free completes, the bpf program which is accessing the inner map may incur use-after-free problem. Fix the free of inner map by invoking bpf_map_free_deferred() after both one RCU grace period and one tasks trace RCU grace period if the inner map has been removed from the outer map before. The deferment is accomplished by using call_rcu() or call_rcu_tasks_trace() when releasing the last ref-counter of bpf map. The newly-added rcu_head field in bpf_map shares the same storage space with work field to reduce the size of bpf_map. Fixes: bba1dc0b ("bpf: Remove redundant synchronize_rcu.") Fixes: 638e4b82 ("bpf: Allows per-cpu maps and map-in-map in sleepable programs") Signed-off-by:
Hou Tao <houtao1@huawei.com> Link: https://lore.kernel.org/r/20231204140425.1480317-5-houtao@huaweicloud.com Signed-off-by:
Alexei Starovoitov <ast@kernel.org> Signed-off-by:
Robert Kolchmeyer <rkolchmeyer@google.com> Signed-off-by:
-
Paul E. McKenney authored
[ Upstream commit e6c86c51 ] As an accident of implementation, an RCU Tasks Trace grace period also acts as an RCU grace period. However, this could change at any time. This commit therefore creates an rcu_trace_implies_rcu_gp() that currently returns true to codify this accident. Code relying on this accident must call this function to verify that this accident is still happening. Reported-by:
Hou Tao <houtao@huaweicloud.com> Signed-off-by:
Paul E. McKenney <paulmck@kernel.org> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Martin KaFai Lau <martin.lau@linux.dev> Link: https://lore.kernel.org/r/20221014113946.965131-2-houtao@huaweicloud.com Signed-off-by:
-
Jens Axboe authored
Commit 6e5e6d27 upstream. This is dead code after we dropped support for passing io_uring fds over SCM_RIGHTS, get rid of it. Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Jens Axboe authored
Commit a4104821 upstream. Since we no longer allow sending io_uring fds over SCM_RIGHTS, move to using io_is_uring_fops() to detect whether this is a io_uring fd or not. With that done, kill off io_uring_get_socket() as nobody calls it anymore. This is in preparation to yanking out the rest of the core related to unix gc with io_uring. Signed-off-by:
-
- Mar 15, 2024
-
-
Sasha Levin authored
Tested-by:
Pavel Machek (CIP) <pavel@denx.de> Tested-by:
Dominique Martinet <dominique.martinet@atmark-techno.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Tested-by:
kernelci.org bot <bot@kernelci.org> Signed-off-by:
-
Jan Kundrát authored
[ Upstream commit 3f42b142 ] After upgrading from 5.16 to 6.1, our board with a MAX14830 started producing lots of garbage data over UART. Bisection pointed out commit 285e76fc as the culprit. That patch tried to replace hand-written code which I added in 2b4bac48 ("serial: max310x: Use batched reads when reasonably safe") with the generic regmap infrastructure for batched operations. Unfortunately, the `regmap_raw_read` and `regmap_raw_write` which were used are actually functions which perform IO over *multiple* registers. That's not what is needed for accessing these Tx/Rx FIFOs; the appropriate functions are the `_noinc_` versions, not the `_raw_` ones. Fix this regression by using `regmap_noinc_read()` and `regmap_noinc_write()` along with the necessary `regmap_config` setup; with this patch in place, our board communicates happily again. Since our board uses SPI for talking to this chip, the I2C part is completely untested. Fixes: 285e76fc ("serial: max310x: use regmap methods for SPI batch operations") Cc: stable@vger.kernel.org Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
Jan Kundrát <jan.kundrat@cesnet.cz> Link: https://lore.kernel.org/r/79db8e82aadb0e174bc82b9996423c3503c8fb37.1680732084.git.jan.kundrat@cesnet.cz Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Cosmin Tanislav authored
[ Upstream commit 2e1f2d9a ] I2C implementation on this chip has a few key differences compared to SPI, as described in previous patches. * extended register space access needs no extra logic * slave address is used to select which UART to communicate with To accommodate these differences, add an I2C interface config, set the RevID register address and implement an empty method for setting the GlobalCommand register, since no special handling is needed for the extended register space. To handle the port-specific slave address, create an I2C dummy device for each port, except the base one (UART0), which is expected to be the one specified in firmware, and create a regmap for each I2C device. Add minimum and maximum slave addresses to each devtype for sanity checking. Also, use a separate regmap config with no write_flag_mask, since I2C has a R/W bit in its slave address, and set the max register to the address of the RevID register, since the extended register space needs no extra logic. Finally, add the I2C driver. Reviewed-by:
Cosmin Tanislav <cosmin.tanislav@analog.com> Link: https://lore.kernel.org/r/20220605144659.4169853-5-demonsingur@gmail.com Signed-off-by:
-
Cosmin Tanislav authored
[ Upstream commit b3883ab5 ] SPI can only use 5 address bits, since one bit is reserved for specifying R/W and 2 bits are used to specify the UART port. To access registers that have addresses past 0x1F, an extended register space can be enabled by writing to the GlobalCommand register (address 0x1F). I2C uses 8 address bits. The R/W bit is placed in the slave address, and so is the UART port. Because of this, registers that have addresses higher than 0x1F can be accessed normally. To access the RevID register, on SPI, 0xCE must be written to the 0x1F address to enable the extended register space, after which the RevID register is accessible at address 0x5. 0xCD must be written to the 0x1F address to disable the extended register space. On I2C, the RevID register is accessible at address 0x25. Create an interface config struct, and add a method for toggling the extended register space and a member for the RevId register address. Implement these for SPI. Reviewed-by:
-
Marek Vasut authored
[ Upstream commit d77e7456 ] Currently the regmap_config structure only allows the user to implement single element register read/write using .reg_read/.reg_write callbacks. The regmap_bus already implements bulk counterparts of both, and is being misused as a workaround for the missing bulk read/write callbacks in regmap_config by a couple of drivers. To stop this misuse, add the bulk read/write callbacks to regmap_config and call them from the regmap core code. Signed-off-by:
Marek Vasut <marex@denx.de> Cc: Jagan Teki <jagan@amarulasolutions.com> Cc: Mark Brown <broonie@kernel.org> Cc: Maxime Ripard <maxime@cerno.tech> Cc: Robert Foss <robert.foss@linaro.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Zimmermann <tzimmermann@suse.de> To: dri-devel@lists.freedesktop.org Link: https://lore.kernel.org/r/20220430025145.640305-1-marex@denx.de Signed-off-by:
-
Ansuel Smith authored
[ Upstream commit 02d6fdec ] Some device requires a special handling for reg_update_bits and can't use the normal regmap read write logic. An example is when locking is handled by the device and rmw operations requires to do atomic operations. Allow to declare a dedicated function in regmap_config for reg_update_bits in no bus configuration. Signed-off-by:
Ansuel Smith <ansuelsmth@gmail.com> Link: https://lore.kernel.org/r/20211104150040.1260-1-ansuelsmth@gmail.com Signed-off-by:
-
Andrea Parri (Microsoft) authored
[ Upstream commit 0c85c54b ] Running out of request IDs on a channel essentially produces the same effect as running out of space in the ring buffer, in that -EAGAIN is returned. The error message in hv_ringbuffer_write() should either be dropped (since we don't output a message when the ring buffer is full) or be made conditional/debug-only. Suggested-by:
Michael Kelley <mikelley@microsoft.com> Signed-off-by:
Andrea Parri (Microsoft) <parri.andrea@gmail.com> Fixes: e8b7db38 ("Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening") Link: https://lore.kernel.org/r/20210301191348.196485-1-parri.andrea@gmail.com Signed-off-by:
Wei Liu <wei.liu@kernel.org> Signed-off-by:
-
Andy Shevchenko authored
[ Upstream commit 61acabaa ] In one error case the clock may be left prepared and enabled. Unprepare and disable clock in that case to balance state of the hardware. Fixes: d4d6f03c ("serial: max310x: Try to get crystal clock rate from property") Reported-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20210625153733.12911-1-andriy.shevchenko@linux.intel.com Signed-off-by:
-
Oleg Nesterov authored
[ Upstream commit f7ec1cd5 ] lock_task_sighand() can trigger a hard lockup. If NR_CPUS threads call getrusage() at the same time and the process has NR_THREADS, spin_lock_irq will spin with irqs disabled O(NR_CPUS * NR_THREADS) time. Change getrusage() to use sig->stats_lock, it was specifically designed for this type of use. This way it runs lockless in the likely case. TODO: - Change do_task_stat() to use sig->stats_lock too, then we can remove spin_lock_irq(siglock) in wait_task_zombie(). - Turn sig->stats_lock into seqcount_rwlock_t, this way the readers in the slow mode won't exclude each other. See https://lore.kernel.org/all/20230913154907.GA26210@redhat.com/ - stats_lock has to disable irqs because ->siglock can be taken in irq context, it would be very nice to change __exit_signal() to avoid the siglock->stats_lock dependency. Link: https://lkml.kernel.org/r/20240122155053.GA26214@redhat.com Signed-off-by:
Oleg Nesterov <oleg@redhat.com> Reported-by:
Dylan Hatch <dylanbhatch@google.com> Tested-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Oleg Nesterov authored
[ Upstream commit 13b7bc60 ] do/while_each_thread should be avoided when possible. Plus this change allows to avoid lock_task_sighand(), we can use rcu and/or sig->stats_lock instead. Link: https://lkml.kernel.org/r/20230909172629.GA20454@redhat.com Signed-off-by:
-
Oleg Nesterov authored
[ Upstream commit daa694e4 ] Patch series "getrusage: use sig->stats_lock", v2. This patch (of 2): thread_group_cputime() does its own locking, we can safely shift thread_group_cputime_adjusted() which does another for_each_thread loop outside of ->siglock protected section. This is also preparation for the next patch which changes getrusage() to use stats_lock instead of siglock, thread_group_cputime() takes the same lock. With the current implementation recursive read_seqbegin_or_lock() is fine, thread_group_cputime() can't enter the slow mode if the caller holds stats_lock, yet this looks more safe and better performance-wise. Link: https://lkml.kernel.org/r/20240122155023.GA26169@redhat.com Link: https://lkml.kernel.org/r/20240122155050.GA26205@redhat.com Signed-off-by:
-
Oleg Nesterov authored
[ Upstream commit c7ac8231 ] No functional changes, cleanup/preparation. Link: https://lkml.kernel.org/r/20230909172554.GA20441@redhat.com Signed-off-by:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
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:
-
