summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2020-12-10file: Rename __close_fd to close_fd and remove the files parameterEric W. Biederman
The function __close_fd was added to support binder[1]. Now that binder has been fixed to no longer need __close_fd[2] all calls to __close_fd pass current->files. Therefore transform the files parameter into a local variable initialized to current->files, and rename __close_fd to close_fd to reflect this change, and keep it in sync with the similar changes to __alloc_fd, and __fd_install. This removes the need for callers to care about the extra care that needs to be take if anything except current->files is passed, by limiting the callers to only operation on current->files. [1] 483ce1d4b8c3 ("take descriptor-related part of close() to file.c") [2] 44d8047f1d87 ("binder: use standard functions to allocate fds") Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200817220425.9389-17-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-21-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: Merge __alloc_fd into alloc_fdEric W. Biederman
The function __alloc_fd was added to support binder[1]. With binder fixed[2] there are no more users. As alloc_fd just calls __alloc_fd with "files=current->files", merge them together by transforming the files parameter into a local variable initialized to current->files. [1] dcfadfa4ec5a ("new helper: __alloc_fd()") [2] 44d8047f1d87 ("binder: use standard functions to allocate fds") Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200817220425.9389-16-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-20-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: In f_dupfd read RLIMIT_NOFILE once.Eric W. Biederman
Simplify the code, and remove the chance of races by reading RLIMIT_NOFILE only once in f_dupfd. Pass the read value of RLIMIT_NOFILE into alloc_fd which is the other location the rlimit was read in f_dupfd. As f_dupfd is the only caller of alloc_fd this changing alloc_fd is trivially safe. Further this causes alloc_fd to take all of the same arguments as __alloc_fd except for the files_struct argument. Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200817220425.9389-15-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-19-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: Merge __fd_install into fd_installEric W. Biederman
The function __fd_install was added to support binder[1]. With binder fixed[2] there are no more users. As fd_install just calls __fd_install with "files=current->files", merge them together by transforming the files parameter into a local variable initialized to current->files. [1] f869e8a7f753 ("expose a low-level variant of fd_install() for binder") [2] 44d8047f1d87 ("binder: use standard functions to allocate fds") Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1:https://lkml.kernel.org/r/20200817220425.9389-14-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-18-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10proc/fd: In fdinfo seq_show don't use get_files_structEric W. Biederman
When discussing[1] exec and posix file locks it was realized that none of the callers of get_files_struct fundamentally needed to call get_files_struct, and that by switching them to helper functions instead it will both simplify their code and remove unnecessary increments of files_struct.count. Those unnecessary increments can result in exec unnecessarily unsharing files_struct which breaking posix locks, and it can result in fget_light having to fallback to fget reducing system performance. Instead hold task_lock for the duration that task->files needs to be stable in seq_show. The task_lock was already taken in get_files_struct, and so skipping get_files_struct performs less work overall, and avoids the problems with the files_struct reference count. [1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com Suggested-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200817220425.9389-12-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-17-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10bpf/task_iter: In task_file_seq_get_next use task_lookup_next_fd_rcuEric W. Biederman
When discussing[1] exec and posix file locks it was realized that none of the callers of get_files_struct fundamentally needed to call get_files_struct, and that by switching them to helper functions instead it will both simplify their code and remove unnecessary increments of files_struct.count. Those unnecessary increments can result in exec unnecessarily unsharing files_struct which breaking posix locks, and it can result in fget_light having to fallback to fget reducing system performance. Using task_lookup_next_fd_rcu simplifies task_file_seq_get_next, by moving the checking for the maximum file descritor into the generic code, and by remvoing the need for capturing and releasing a reference on files_struct. As the reference count of files_struct no longer needs to be maintained bpf_iter_seq_task_file_info can have it's files member removed and task_file_seq_get_next no longer needs it's fstruct argument. The curr_fd local variable does need to become unsigned to be used with fnext_task. As curr_fd is assigned from and assigned a u32 making curr_fd an unsigned int won't cause problems and might prevent them. [1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com Suggested-by: Oleg Nesterov <oleg@redhat.com> v1: https://lkml.kernel.org/r/20200817220425.9389-11-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-16-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10proc/fd: In proc_readfd_common use task_lookup_next_fd_rcuEric W. Biederman
When discussing[1] exec and posix file locks it was realized that none of the callers of get_files_struct fundamentally needed to call get_files_struct, and that by switching them to helper functions instead it will both simplify their code and remove unnecessary increments of files_struct.count. Those unnecessary increments can result in exec unnecessarily unsharing files_struct which breaking posix locks, and it can result in fget_light having to fallback to fget reducing system performance. Using task_lookup_next_fd_rcu simplifies proc_readfd_common, by moving the checking for the maximum file descritor into the generic code, and by remvoing the need for capturing and releasing a reference on files_struct. As task_lookup_fd_rcu may update the fd ctx->pos has been changed to be the fd +2 after task_lookup_fd_rcu returns. [1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com Suggested-by: Oleg Nesterov <oleg@redhat.com> Tested-by: Andy Lavr <andy.lavr@gmail.com> v1: https://lkml.kernel.org/r/20200817220425.9389-10-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-15-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: Implement task_lookup_next_fd_rcuEric W. Biederman
As a companion to fget_task and task_lookup_fd_rcu implement task_lookup_next_fd_rcu that will return the struct file for the first file descriptor number that is equal or greater than the fd argument value, or NULL if there is no such struct file. This allows file descriptors of foreign processes to be iterated through safely, without needed to increment the count on files_struct. Some concern[1] has been expressed that this function takes the task_lock for each iteration and thus for each file descriptor. This place where this function will be called in a commonly used code path is for listing /proc/<pid>/fd. I did some small benchmarks and did not see any measurable performance differences. For ordinary users ls is likely to stat each of the directory entries and tid_fd_mode called from tid_fd_revalidae has always taken the task lock for each file descriptor. So this does not look like it will be a big change in practice. At some point is will probably be worth changing put_files_struct to free files_struct after an rcu grace period so that task_lock won't be needed at all. [1] https://lkml.kernel.org/r/20200817220425.9389-10-ebiederm@xmission.com v1: https://lkml.kernel.org/r/20200817220425.9389-9-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-14-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10kcmp: In get_file_raw_ptr use task_lookup_fd_rcuEric W. Biederman
Modify get_file_raw_ptr to use task_lookup_fd_rcu. The helper task_lookup_fd_rcu does the work of taking the task lock and verifying that task->files != NULL and then calls files_lookup_fd_rcu. So let use the helper to make a simpler implementation of get_file_raw_ptr. Acked-by: Cyrill Gorcunov <gorcunov@gmail.com> Link: https://lkml.kernel.org/r/20201120231441.29911-13-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10proc/fd: In tid_fd_mode use task_lookup_fd_rcuEric W. Biederman
When discussing[1] exec and posix file locks it was realized that none of the callers of get_files_struct fundamentally needed to call get_files_struct, and that by switching them to helper functions instead it will both simplify their code and remove unnecessary increments of files_struct.count. Those unnecessary increments can result in exec unnecessarily unsharing files_struct which breaking posix locks, and it can result in fget_light having to fallback to fget reducing system performance. Instead of manually coding finding the files struct for a task and then calling files_lookup_fd_rcu, use the helper task_lookup_fd_rcu that combines those to steps. Making the code simpler and removing the need to get a reference on a files_struct. [1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com Suggested-by: Oleg Nesterov <oleg@redhat.com> Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200817220425.9389-7-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-12-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: Implement task_lookup_fd_rcuEric W. Biederman
As a companion to lookup_fd_rcu implement task_lookup_fd_rcu for querying an arbitrary process about a specific file. Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200818103713.aw46m7vprsy4vlve@wittgenstein Link: https://lkml.kernel.org/r/20201120231441.29911-11-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: Rename fcheck lookup_fd_rcuEric W. Biederman
Also remove the confusing comment about checking if a fd exists. I could not find one instance in the entire kernel that still matches the description or the reason for the name fcheck. The need for better names became apparent in the last round of discussion of this set of changes[1]. [1] https://lkml.kernel.org/r/CAHk-=wj8BQbgJFLa+J0e=iT-1qpmCRTbPAJ8gd6MJQ=kbRPqyQ@mail.gmail.com Link: https://lkml.kernel.org/r/20201120231441.29911-10-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: Replace fcheck_files with files_lookup_fd_rcuEric W. Biederman
This change renames fcheck_files to files_lookup_fd_rcu. All of the remaining callers take the rcu_read_lock before calling this function so the _rcu suffix is appropriate. This change also tightens up the debug check to verify that all callers hold the rcu_read_lock. All callers that used to call files_check with the files->file_lock held have now been changed to call files_lookup_fd_locked. This change of name has helped remind me of which locks and which guarantees are in place helping me to catch bugs later in the patchset. The need for better names became apparent in the last round of discussion of this set of changes[1]. [1] https://lkml.kernel.org/r/CAHk-=wj8BQbgJFLa+J0e=iT-1qpmCRTbPAJ8gd6MJQ=kbRPqyQ@mail.gmail.com Link: https://lkml.kernel.org/r/20201120231441.29911-9-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: Factor files_lookup_fd_locked out of fcheck_filesEric W. Biederman
To make it easy to tell where files->file_lock protection is being used when looking up a file create files_lookup_fd_locked. Only allow this function to be called with the file_lock held. Update the callers of fcheck and fcheck_files that are called with the files->file_lock held to call files_lookup_fd_locked instead. Hopefully this makes it easier to quickly understand what is going on. The need for better names became apparent in the last round of discussion of this set of changes[1]. [1] https://lkml.kernel.org/r/CAHk-=wj8BQbgJFLa+J0e=iT-1qpmCRTbPAJ8gd6MJQ=kbRPqyQ@mail.gmail.com Link: https://lkml.kernel.org/r/20201120231441.29911-8-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10file: Rename __fcheck_files to files_lookup_fd_rawEric W. Biederman
The function fcheck despite it's comment is poorly named as it has no callers that only check it's return value. All of fcheck's callers use the returned file descriptor. The same is true for fcheck_files and __fcheck_files. A new less confusing name is needed. In addition the names of these functions are confusing as they do not report the kind of locks that are needed to be held when these functions are called making error prone to use them. To remedy this I am making the base functio name lookup_fd and will and prefixes and sufficies to indicate the rest of the context. Name the function (previously called __fcheck_files) that proceeds from a struct files_struct, looks up the struct file of a file descriptor, and requires it's callers to verify all of the appropriate locks are held files_lookup_fd_raw. The need for better names became apparent in the last round of discussion of this set of changes[1]. [1] https://lkml.kernel.org/r/CAHk-=wj8BQbgJFLa+J0e=iT-1qpmCRTbPAJ8gd6MJQ=kbRPqyQ@mail.gmail.com Link: https://lkml.kernel.org/r/20201120231441.29911-7-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10proc/fd: In proc_fd_link use fget_taskEric W. Biederman
When discussing[1] exec and posix file locks it was realized that none of the callers of get_files_struct fundamentally needed to call get_files_struct, and that by switching them to helper functions instead it will both simplify their code and remove unnecessary increments of files_struct.count. Those unnecessary increments can result in exec unnecessarily unsharing files_struct which breaking posix locks, and it can result in fget_light having to fallback to fget reducing system performance. Simplifying proc_fd_link is a little bit tricky. It is necessary to know that there is a reference to fd_f ile while path_get is running. This reference can either be guaranteed to exist either by locking the fdtable as the code currently does or by taking a reference on the file in question. Use fget_task to remove the need for get_files_struct and to take a reference to file in question. [1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com Suggested-by: Oleg Nesterov <oleg@redhat.com> v1: https://lkml.kernel.org/r/20200817220425.9389-8-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-6-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10bpf: In bpf_task_fd_query use fget_taskEric W. Biederman
Use the helper fget_task to simplify bpf_task_fd_query. As well as simplifying the code this removes one unnecessary increment of struct files_struct. This unnecessary increment of files_struct.count can result in exec unnecessarily unsharing files_struct and breaking posix locks, and it can result in fget_light having to fallback to fget reducing performance. This simplification comes from the observation that none of the callers of get_files_struct actually need to call get_files_struct that was made when discussing[1] exec and posix file locks. [1] https://lkml.kernel.org/r/20180915160423.GA31461@redhat.com Suggested-by: Oleg Nesterov <oleg@redhat.com> v1: https://lkml.kernel.org/r/20200817220425.9389-5-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-5-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10kcmp: In kcmp_epoll_target use fget_taskEric W. Biederman
Use the helper fget_task and simplify the code. As well as simplifying the code this removes one unnecessary increment of struct files_struct. This unnecessary increment of files_struct.count can result in exec unnecessarily unsharing files_struct and breaking posix locks, and it can result in fget_light having to fallback to fget reducing performance. Suggested-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com> v1: https://lkml.kernel.org/r/20200817220425.9389-4-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-4-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10exec: Remove reset_files_structEric W. Biederman
Now that exec no longer needs to restore the previous value of current->files on error there are no more callers of reset_files_struct so remove it. Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200817220425.9389-3-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-3-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10exec: Simplify unshare_filesEric W. Biederman
Now that exec no longer needs to return the unshared files to their previous value there is no reason to return displaced. Instead when unshare_fd creates a copy of the file table, call put_files_struct before returning from unshare_files. Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200817220425.9389-2-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-2-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10exec: Move unshare_files to fix posix file locking during execEric W. Biederman
Many moons ago the binfmts were doing some very questionable things with file descriptors and an unsharing of the file descriptor table was added to make things better[1][2]. The helper steal_lockss was added to avoid breaking the userspace programs[3][4][6]. Unfortunately it turned out that steal_locks did not work for network file systems[5], so it was removed to see if anyone would complain[7][8]. It was thought at the time that NPTL would not be affected as the unshare_files happened after the other threads were killed[8]. Unfortunately because there was an unshare_files in binfmt_elf.c before the threads were killed this analysis was incorrect. This unshare_files in binfmt_elf.c resulted in the unshares_files happening whenever threads were present. Which led to unshare_files being moved to the start of do_execve[9]. Later the problems were rediscovered and the suggested approach was to readd steal_locks under a different name[10]. I happened to be reviewing patches and I noticed that this approach was a step backwards[11]. I proposed simply moving unshare_files[12] and it was pointed out that moving unshare_files without auditing the code was also unsafe[13]. There were then several attempts to solve this[14][15][16] and I even posted this set of changes[17]. Unfortunately because auditing all of execve is time consuming this change did not make it in at the time. Well now that I am cleaning up exec I have made the time to read through all of the binfmts and the only playing with file descriptors is either the security modules closing them in security_bprm_committing_creds or is in the generic code in fs/exec.c. None of it happens before begin_new_exec is called. So move unshare_files into begin_new_exec, after the point of no return. If memory is very very very low and the application calling exec is sharing file descriptor tables between processes we might fail past the point of no return. Which is unfortunate but no different than any of the other places where we allocate memory after the point of no return. This movement allows another process that shares the file table, or another thread of the same process and that closes files or changes their close on exec behavior and races with execve to cause some unexpected things to happen. There is only one time of check to time of use race and it is just there so that execve fails instead of an interpreter failing when it tries to open the file it is supposed to be interpreting. Failing later if userspace is being silly is not a problem. With this change it the following discription from the removal of steal_locks[8] finally becomes true. Apps using NPTL are not affected, since all other threads are killed before execve. Apps using LinuxThreads are only affected if they - have multiple threads during exec (LinuxThreads doesn't kill other threads, the app may do it with pthread_kill_other_threads_np()) - rely on POSIX locks being inherited across exec Both conditions are documented, but not their interaction. Apps using clone() natively are affected if they - use clone(CLONE_FILES) - rely on POSIX locks being inherited across exec I have investigated some paths to make it possible to solve this without moving unshare_files but they all look more complicated[18]. Reported-by: Daniel P. Berrangé <berrange@redhat.com> Reported-by: Jeff Layton <jlayton@redhat.com> History-tree: git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git [1] 02cda956de0b ("[PATCH] unshare_files" [2] 04e9bcb4d106 ("[PATCH] use new unshare_files helper") [3] 088f5d7244de ("[PATCH] add steal_locks helper") [4] 02c541ec8ffa ("[PATCH] use new steal_locks helper") [5] https://lkml.kernel.org/r/E1FLIlF-0007zR-00@dorka.pomaz.szeredi.hu [6] https://lkml.kernel.org/r/0060321191605.GB15997@sorel.sous-sol.org [7] https://lkml.kernel.org/r/E1FLwjC-0000kJ-00@dorka.pomaz.szeredi.hu [8] c89681ed7d0e ("[PATCH] remove steal_locks()") [9] fd8328be874f ("[PATCH] sanitize handling of shared descriptor tables in failing execve()") [10] https://lkml.kernel.org/r/20180317142520.30520-1-jlayton@kernel.org [11] https://lkml.kernel.org/r/87r2nwqk73.fsf@xmission.com [12] https://lkml.kernel.org/r/87bmfgvg8w.fsf@xmission.com [13] https://lkml.kernel.org/r/20180322111424.GE30522@ZenIV.linux.org.uk [14] https://lkml.kernel.org/r/20180827174722.3723-1-jlayton@kernel.org [15] https://lkml.kernel.org/r/20180830172423.21964-1-jlayton@kernel.org [16] https://lkml.kernel.org/r/20180914105310.6454-1-jlayton@kernel.org [17] https://lkml.kernel.org/r/87a7ohs5ow.fsf@xmission.com [18] https://lkml.kernel.org/r/87pn8c1uj6.fsf_-_@x220.int.ebiederm.org Acked-by: Christian Brauner <christian.brauner@ubuntu.com> v1: https://lkml.kernel.org/r/20200817220425.9389-1-ebiederm@xmission.com Link: https://lkml.kernel.org/r/20201120231441.29911-1-ebiederm@xmission.com Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10exec: Don't open code get_close_on_execEric W. Biederman
Al Viro pointed out that using the phrase "close_on_exec(fd, rcu_dereference_raw(current->files->fdt))" instead of wrapping it in rcu_read_lock(), rcu_read_unlock() is a very questionable optimization[1]. Once wrapped with rcu_read_lock()/rcu_read_unlock() that phrase becomes equivalent the helper function get_close_on_exec so simplify the code and make it more robust by simply using get_close_on_exec. [1] https://lkml.kernel.org/r/20201207222214.GA4115853@ZenIV.linux.org.uk Suggested-by: Al Viro <viro@ftp.linux.org.uk> Link: https://lkml.kernel.org/r/87k0tqr6zi.fsf_-_@x220.int.ebiederm.org Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
2020-12-10PCI: Mark AMD Raven iGPU ATS as broken in some platformsAlex Deucher
Edgar reported [1] AMD Raven iGPU errors on several of his systems. There is no root cause. Turn off ATS on these systems to avoid the issue. [1] https://lore.kernel.org/linux-iommu/MWHPR10MB1310CDB6829DDCF5EA84A14689150@MWHPR10MB1310.namprd10.prod.outlook.com/ [bhelgaas: commit log] Link: https://lore.kernel.org/r/MWHPR10MB131082779A86BE4CCCF190B789CB0@MWHPR10MB1310.namprd10.prod.outlook.com Reported-by: Edgar Merger <Edgar.Merger@emerson.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
2020-12-10thermal: broadcom: simplify the return expression of bcm2711_thermal_probe()Zheng Yongjun
Simplify the return expression. Signed-off-by: Zheng Yongjun <zhengyongjun3@huawei.com> Reviewed-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201210135432.1249-1-zhengyongjun3@huawei.com
2020-12-10RDMA/core: Update kernel documentation for ib_create_named_qp()Lukas Bulwahn
Commit 66f57b871efc ("RDMA/restrack: Support all QP types") extends ib_create_qp() to a named ib_create_named_qp(), which takes the caller's name as argument, but it did not add the new argument description to the function's kerneldoc. make htmldocs warns: ./drivers/infiniband/core/verbs.c:1206: warning: Function parameter or member 'caller' not described in 'ib_create_named_qp' Add a description for this new argument based on the description of the same argument in other related functions. Fixes: 66f57b871efc ("RDMA/restrack: Support all QP types") Link: https://lore.kernel.org/r/20201207173255.13355-1-lukas.bulwahn@gmail.com Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-12-10f2fs: compress: fix compression chksumChao Yu
This patch addresses minor issues in compression chksum. Fixes: b28f047b28c5 ("f2fs: compress: support chksum") Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2020-12-10f2fs: fix shift-out-of-bounds in sanity_check_raw_super()Chao Yu
syzbot reported a bug which could cause shift-out-of-bounds issue, fix it. Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x107/0x163 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:395 sanity_check_raw_super fs/f2fs/super.c:2812 [inline] read_raw_super_block fs/f2fs/super.c:3267 [inline] f2fs_fill_super.cold+0x16c9/0x16f6 fs/f2fs/super.c:3519 mount_bdev+0x34d/0x410 fs/super.c:1366 legacy_get_tree+0x105/0x220 fs/fs_context.c:592 vfs_get_tree+0x89/0x2f0 fs/super.c:1496 do_new_mount fs/namespace.c:2896 [inline] path_mount+0x12ae/0x1e70 fs/namespace.c:3227 do_mount fs/namespace.c:3240 [inline] __do_sys_mount fs/namespace.c:3448 [inline] __se_sys_mount fs/namespace.c:3425 [inline] __x64_sys_mount+0x27f/0x300 fs/namespace.c:3425 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Reported-by: syzbot+ca9a785f8ac472085994@syzkaller.appspotmail.com Signed-off-by: Anant Thazhemadam <anant.thazhemadam@gmail.com> Signed-off-by: Chao Yu <yuchao0@huawei.com> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2020-12-10remoteproc: pru: Add support for various PRU cores on K3 J721E SoCsSuman Anna
The K3 J721E family of SoCs have a revised version of the AM65x ICSSG IP and contains two instances of this newer ICSSG IP. Each ICSSG processor subsystem contains 2 primary PRU cores, 2 auxiliary PRU cores called RTUs, and 2 new auxiliary cores called Transmit PRUs (Tx_PRUs). Enhance the existing PRU remoteproc driver to support these new PRU and RTU cores by using specific compatibles. The cores have the same memory copying limitations as on AM65x, so reuses the custom memcpy function within the driver's ELF loader implementation. The initial names for the firmware images for each PRU core are retrieved from DT nodes, and can be adjusted through sysfs if required. Signed-off-by: Suman Anna <s-anna@ti.com> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-7-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add support for various PRU cores on K3 AM65x SoCsSuman Anna
The K3 AM65x family of SoCs have the next generation of the PRU-ICSS processor subsystem, commonly referred to as ICSSG. Each ICSSG processor subsystem on AM65x SR1.0 contains two primary PRU cores and two new auxiliary PRU cores called RTUs. The AM65x SR2.0 SoCs have a revised ICSSG IP that is based off the subsequent IP revision used on J721E SoCs. This IP instance has two new custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs) in addition to the existing PRUs and RTUs. Each RTU and Tx_PRU cores have their own dedicated IRAM (smaller than a PRU), Control and debug feature sets, but is different in terms of sub-modules integrated around it and does not have the full capabilities associated with a PRU core. The RTU core is typically used to aid a PRU core in accelerating data transfers, while the Tx_PRU cores is normally used to control the TX L2 FIFO if enabled in Ethernet applications. Both can also be used to run independent applications. The RTU and Tx_PRU cores though share the same Data RAMs as the PRU cores, so the memories have to be partitioned carefully between different applications. The new cores also support a new sub-module called Task Manager to support two different context thread executions. Enhance the existing PRU remoteproc driver to support these new PRU, RTU and Tx PRU cores by using specific compatibles. The initial names for the firmware images for each PRU core are retrieved from DT nodes, and can be adjusted through sysfs if required. The PRU remoteproc driver has to be specifically modified to use a custom memcpy function within its ELF loader implementation for these new cores in order to overcome a limitation with copying data into each of the core's IRAM memories. These memory ports support only 4-byte writes, and any sub-word order byte writes clear out the remaining bytes other than the bytes being written within the containing word. The default ARM64 memcpy also cannot be used as it throws an exception when the preferred 8-byte copy operation is attempted. This choice is made by using a state flag that is set only on K3 SoCs. Signed-off-by: Suman Anna <s-anna@ti.com> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-6-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add pru-specific debugfs supportSuman Anna
The remoteproc core creates certain standard debugfs entries, that does not give a whole lot of useful information for the PRUs. The PRU remoteproc driver is enhanced to add additional debugfs entries for PRU. These will be auto-cleaned up when the parent rproc debug directory is removed. The enhanced debugfs support adds two new entries: 'regs' and 'single_step'. The 'regs' dumps out the useful CTRL sub-module registers as well as each of the 32 GPREGs and CT_REGs registers. The GPREGs and CT_REGs though are printed only when the PRU is halted and accessible as per the IP design. The 'single_step' utilizes the single-step execution of the PRU cores. Writing a non-zero value performs a single step, and a zero value restores the PRU to execute in the same mode as the mode before the first single step. (note: if the PRU is halted because of a halt instruction, then no change occurs). Logic for setting the PC and jumping over a halt instruction shall be added in the future. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-5-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add support for PRU specific interrupt configurationGrzegorz Jaszczyk
The firmware blob can contain optional ELF sections: .resource_table section and .pru_irq_map one. The second one contains the PRUSS interrupt mapping description, which needs to be setup before powering on the PRU core. To avoid RAM wastage this ELF section is not mapped to any ELF segment (by the firmware linker) and therefore is not loaded to PRU memory. The PRU interrupt configuration is handled within the PRUSS INTC irqchip driver and leverages the system events to interrupt channels and host interrupts mapping configuration. Relevant irq routing information is passed through a special .pru_irq_map ELF section (for interrupts routed to and used by PRU cores) or via the PRU application's device tree node (for interrupts routed to and used by the main CPU). The mappings are currently programmed during the booting/shutdown of the PRU. The interrupt configuration passed through .pru_irq_map ELF section is optional. It varies on specific firmware functionality and therefore have to be unwinded during PRU stop and performed again during PRU start. Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Co-developed-by: Suman Anna <s-anna@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-4-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10remoteproc: pru: Add a PRU remoteproc driverSuman Anna
The Programmable Real-Time Unit Subsystem (PRUSS) consists of dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs) for program execution. This patch adds a remoteproc platform driver for managing the individual PRU RISC cores life cycle. The PRUs do not have a unified address space (have an Instruction RAM and a primary Data RAM at both 0x0). The PRU remoteproc driver therefore uses a custom remoteproc core ELF loader ops. The added .da_to_va ops is only used to provide translations for the PRU Data RAMs. This remoteproc driver does not have support for error recovery and system suspend/resume features. Different compatibles are used to allow providing scalability for instance-specific device data if needed. The driver uses a default firmware-name retrieved from device-tree for each PRU core, and the firmwares are expected to be present in the standard Linux firmware search paths. They can also be adjusted by userspace if required through the sysfs interface provided by the remoteproc core. The PRU remoteproc driver uses a client-driven boot methodology: it does _not_ support auto-boot so that the PRU load and boot is dictated by the corresponding client drivers for achieving various usecases. This allows flexibility for the client drivers or applications to set a firmware name (if needed) based on their desired functionality and boot the PRU. The sysfs bind and unbind attributes have also been suppressed so that the PRU devices cannot be unbound and thereby shutdown a PRU from underneath a PRU client driver. The driver currently supports the AM335x, AM437x, AM57xx and 66AK2G SoCs, and support for other TI SoCs will be added in subsequent patches. Co-developed-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Andrew F. Davis <afd@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Co-developed-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-3-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10dt-bindings: remoteproc: Add binding doc for PRU cores in the PRU-ICSSSuman Anna
The Programmable Real-Time Unit and Industrial Communication Subsystem (PRU-ICSS or simply PRUSS) on various TI SoCs consists of dual 32-bit RISC cores (Programmable Real-Time Units, or PRUs) for program execution. The K3 AM65x amd J721E SoCs have the next generation of the PRU-ICSS IP, commonly called ICSSG. The ICSSG IP on AM65x SoCs has two PRU cores, two auxiliary custom PRU cores called Real Time Units (RTUs). The K3 AM65x SR2.0 and J721E SoCs have a revised version of the ICSSG IP, and include two additional custom auxiliary PRU cores called Transmit PRUs (Tx_PRUs). This patch adds the bindings for these PRU cores. The binding covers the OMAP architecture SoCs - AM33xx, AM437x and AM57xx; Keystone 2 architecture based 66AK2G SoC; and the K3 architecture based SoCs - AM65x and J721E. The Davinci based OMAPL138 SoCs will be covered in a future patch. Reviewed-by: Rob Herring <robh@kernel.org> Co-developed-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Roger Quadros <rogerq@ti.com> Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Grzegorz Jaszczyk <grzegorz.jaszczyk@linaro.org> Link: https://lore.kernel.org/r/20201208141002.17777-2-grzegorz.jaszczyk@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-12-10x86/resctrl: Fix incorrect local bandwidth when mba_sc is enabledXiaochen Shen
The MBA software controller (mba_sc) is a feedback loop which periodically reads MBM counters and tries to restrict the bandwidth below a user-specified value. It tags along the MBM counter overflow handler to do the updates with 1s interval in mbm_update() and update_mba_bw(). The purpose of mbm_update() is to periodically read the MBM counters to make sure that the hardware counter doesn't wrap around more than once between user samplings. mbm_update() calls __mon_event_count() for local bandwidth updating when mba_sc is not enabled, but calls mbm_bw_count() instead when mba_sc is enabled. __mon_event_count() will not be called for local bandwidth updating in MBM counter overflow handler, but it is still called when reading MBM local bandwidth counter file 'mbm_local_bytes', the call path is as below: rdtgroup_mondata_show() mon_event_read() mon_event_count() __mon_event_count() In __mon_event_count(), m->chunks is updated by delta chunks which is calculated from previous MSR value (m->prev_msr) and current MSR value. When mba_sc is enabled, m->chunks is also updated in mbm_update() by mistake by the delta chunks which is calculated from m->prev_bw_msr instead of m->prev_msr. But m->chunks is not used in update_mba_bw() in the mba_sc feedback loop. When reading MBM local bandwidth counter file, m->chunks was changed unexpectedly by mbm_bw_count(). As a result, the incorrect local bandwidth counter which calculated from incorrect m->chunks is shown to the user. Fix this by removing incorrect m->chunks updating in mbm_bw_count() in MBM counter overflow handler, and always calling __mon_event_count() in mbm_update() to make sure that the hardware local bandwidth counter doesn't wrap around. Test steps: # Run workload with aggressive memory bandwidth (e.g., 10 GB/s) git clone https://github.com/intel/intel-cmt-cat && cd intel-cmt-cat && make ./tools/membw/membw -c 0 -b 10000 --read # Enable MBA software controller mount -t resctrl resctrl -o mba_MBps /sys/fs/resctrl # Create control group c1 mkdir /sys/fs/resctrl/c1 # Set MB throttle to 6 GB/s echo "MB:0=6000;1=6000" > /sys/fs/resctrl/c1/schemata # Write PID of the workload to tasks file echo `pidof membw` > /sys/fs/resctrl/c1/tasks # Read local bytes counters twice with 1s interval, the calculated # local bandwidth is not as expected (approaching to 6 GB/s): local_1=`cat /sys/fs/resctrl/c1/mon_data/mon_L3_00/mbm_local_bytes` sleep 1 local_2=`cat /sys/fs/resctrl/c1/mon_data/mon_L3_00/mbm_local_bytes` echo "local b/w (bytes/s):" `expr $local_2 - $local_1` Before fix: local b/w (bytes/s): 11076796416 After fix: local b/w (bytes/s): 5465014272 Fixes: ba0f26d8529c (x86/intel_rdt/mba_sc: Prepare for feedback loop) Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Tony Luck <tony.luck@intel.com> Cc: <stable@vger.kernel.org> Link: https://lkml.kernel.org/r/1607063279-19437-1-git-send-email-xiaochen.shen@intel.com
2020-12-10Merge tag 'kvmarm-fixes-5.10-5' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD kvm/arm64 fixes for 5.10, take #5 - Don't leak page tables on PTE update - Correctly invalidate TLBs on table to block transition - Only update permissions if the fault level matches the expected mapping size
2020-12-10MAINTAINERS: SOFT-ROCE: Change Zhu Yanjun's email addressZhu Yanjun
Change Zhu's working email to his private one. Link: https://lore.kernel.org/r/20201203190659.126932-1-leon@kernel.org Signed-off-by: Zhu Yanjun <yanjunz@nvidia.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-12-10RDMA/mlx5: Remove unneeded semicolonTom Rix
A semicolon is not needed after a switch statement. Link: https://lore.kernel.org/r/20201031134638.2135060-1-trix@redhat.com Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
2020-12-10selftests/bpf: Make selftest compilation work on clang 11Jiri Olsa
We can't compile test_core_reloc_module.c selftest with clang 11, compile fails with: CLNG-LLC [test_maps] test_core_reloc_module.o progs/test_core_reloc_module.c:57:21: error: use of unknown builtin \ '__builtin_preserve_type_info' [-Wimplicit-function-declaration] out->read_ctx_sz = bpf_core_type_size(struct bpf_testmod_test_read_ctx); Skipping these tests if __builtin_preserve_type_info() is not supported by compiler. Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20201209142912.99145-1-jolsa@kernel.org
2020-12-10selftests/bpf: Xsk selftests - adding xdpxceiver to .gitignoreWeqaar Janjua
This patch adds *xdpxceiver* to selftests/bpf/.gitignore Reported-by: Yonghong Song <yhs@fb.com> Suggested-by: Yonghong Song <yhs@fb.com> Signed-off-by: Weqaar Janjua <weqaar.a.janjua@intel.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20201210115435.3995-1-weqaar.a.janjua@intel.com
2020-12-10selftests/bpf: Drop tcp-{client,server}.py from MakefileVeronika Kabatova
The files don't exist anymore so this breaks generic kselftest builds when using "make install" or "make gen_tar". Fixes: 247f0ec361b7 ("selftests/bpf: Drop python client/server in favor of threads") Signed-off-by: Veronika Kabatova <vkabatov@redhat.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20201210120134.2148482-1-vkabatov@redhat.com
2020-12-10misc: pvpanic: Replace OF headers by mod_devicetable.hAndy Shevchenko
There is no use for OF headers in the driver, but mod_devicetable.h must be included. Update driver accordingly. Cc: Peng Hao <peng.hao2@zte.com.cn> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-5-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10misc: pvpanic: Combine ACPI and platform driversAndy Shevchenko
There is nothing special in the driver that requires to have a special ACPI driver for it. Combine both into simple platform driver. Cc: Peng Hao <peng.hao2@zte.com.cn> Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-4-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10usb: host: sl811: Switch to use platform_get_mem_or_io()Andy Shevchenko
Switch to use new platform_get_mem_or_io() instead of home grown analogue. Note, the code has been moved upper in the function to allow farther cleanups, such as resource sanity check. Cc: linux-usb@vger.kernel.org Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-3-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10vfio: platform: Switch to use platform_get_mem_or_io()Andy Shevchenko
Switch to use new platform_get_mem_or_io() instead of home grown analogue. Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Cornelia Huck <cohuck@redhat.com> Cc: kvm@vger.kernel.org Acked-by: Eric Auger <eric.auger@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-2-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10driver core: platform: Introduce platform_get_mem_or_io()Andy Shevchenko
There are at least few existing users of the proposed API which retrieves either MEM or IO resource from platform device. Make it common to utilize in the existing and new users. Cc: Eric Auger <eric.auger@redhat.com> Cc: Alex Williamson <alex.williamson@redhat.com> Cc: kvm@vger.kernel.org Cc: linux-usb@vger.kernel.org Cc: Peng Hao <peng.hao2@zte.com.cn> Cc: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Cornelia Huck <cohuck@redhat.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://lore.kernel.org/r/20201209203642.27648-1-andriy.shevchenko@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10serial: 8250_omap: Avoid FIFO corruption caused by MDR1 accessAlexander Sverdlin
It has been observed that once per 300-1300 port openings the first transmitted byte is being corrupted on AM3352 ("v" written to FIFO appeared as "e" on the wire). It only happened if single byte has been transmitted right after port open, which means, DMA is not used for this transfer and the corruption never happened afterwards. Therefore I've carefully re-read the MDR1 errata (link below), which says "when accessing the MDR1 registers that causes a dummy under-run condition that will freeze the UART in IrDA transmission. In UART mode, this may corrupt the transferred data". Strictly speaking, omap_8250_mdr1_errataset() performs a read access and if the value is the same as should be written, exits without errata-recommended FIFO reset. A brief check of the serial_omap_mdr1_errataset() from the competing omap-serial driver showed it has no read access of MDR1. After removing the read access from omap_8250_mdr1_errataset() the data corruption never happened any more. Link: https://www.ti.com/lit/er/sprz360i/sprz360i.pdf Fixes: 61929cf0169d ("tty: serial: Add 8250-core based omap driver") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20201210055257.1053028-1-alexander.sverdlin@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10serial: imx: Move imx_uart_probe_dt() content into probe()Fabio Estevam
Now that the driver only probes via devicetree, we can move the content of imx_uart_probe_dt() directly into imx_uart_probe() to make the code simpler. Suggested-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Fabio Estevam <festevam@gmail.com> Link: https://lore.kernel.org/r/20201209214712.15247-1-festevam@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10slimbus: qcom: fix potential NULL dereference in qcom_slim_prg_slew()Zhang Changzhong
platform_get_resource_byname() may fail and in this case a NULL dereference will occur. Fix it to use devm_platform_ioremap_resource_byname() instead of calling platform_get_resource_byname() and devm_ioremap(). This is detected by Coccinelle semantic patch. @@ expression pdev, res, n, t, e, e1, e2; @@ res = \(platform_get_resource\|platform_get_resource_byname\)(pdev, t, n); + if (!res) + return -EINVAL; ... when != res == NULL e = devm_ioremap(e1, res->start, e2); Fixes: ad7fcbc308b0 ("slimbus: qcom: Add Qualcomm Slimbus controller driver") Signed-off-by: Zhang Changzhong <zhangchangzhong@huawei.com> Link: https://lore.kernel.org/r/1607392473-20610-1-git-send-email-zhangchangzhong@huawei.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10siox: Make remove callback return voidUwe Kleine-König
The driver core ignores the return value of the remove callback, so don't give siox drivers the chance to provide a value. All siox drivers only allocate devm-managed resources in .probe, so there is no .remove callback to fix. Tested-by: Thorsten Scherer <t.scherer@eckelmann.de> Acked-by: Thorsten Scherer <t.scherer@eckelmann.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201125093106.240643-3-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-10siox: Use bus_type functions for probe, remove and shutdownUwe Kleine-König
The eventual goal is to get rid of the callbacks in struct device_driver. Tested-by: Thorsten Scherer <t.scherer@eckelmann.de> Acked-by: Thorsten Scherer <t.scherer@eckelmann.de> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Link: https://lore.kernel.org/r/20201125093106.240643-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit (git 2.34.1) at 2025-09-22 23:39:04 +0000