summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-01-29xfs: avoid setting XFS_ILOG_CORE if i_version doesn't need incrementingJeff Layton1-6/+8
If XFS_ILOG_CORE is already set then go ahead and increment it. Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-by: Darrick J. Wong <darrick.wong@oracle.com> Acked-by: Dave Chinner <dchinner@redhat.com>
2018-01-29fs: only set S_VERSION when updating times if necessaryJeff Layton1-3/+7
We only really need to update i_version if someone has queried for it since we last incremented it. By doing that, we can avoid having to update the inode if the times haven't changed. If the times have changed, then we go ahead and forcibly increment the counter, under the assumption that we'll be going to the storage anyway, and the increment itself is relatively cheap. Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz>
2018-01-29IMA: switch IMA over to new i_version APIJeff Layton2-2/+4
Signed-off-by: Jeff Layton <jlayton@redhat.com>
2018-01-29xfs: convert to new i_version APIJeff Layton5-7/+15
Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-by: Darrick J. Wong <darrick.wong@oracle.com> Acked-by: Dave Chinner <dchinner@redhat.com>
2018-01-29ufs: use new i_version APIJeff Layton3-6/+9
Signed-off-by: Jeff Layton <jlayton@redhat.com>
2018-01-29ocfs2: convert to new i_version APIJeff Layton4-10/+14
Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz>
2018-01-29nfsd: convert to new i_version APIJeff Layton1-1/+2
Mostly just making sure we use the "get" wrappers so we know when it is being fetched for later use. Signed-off-by: Jeff Layton <jlayton@redhat.com>
2018-01-29nfs: convert to new i_version APIJeff Layton6-23/+26
For NFS, we just use the "raw" API since the i_version is mostly managed by the server. The exception there is when the client holds a write delegation, but we only need to bump it once there anyway to handle CB_GETATTR. Tested-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Jeff Layton <jlayton@redhat.com>
2018-01-29ext4: convert to new i_version APIJeff Layton7-17/+26
Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-by: Theodore Ts'o <tytso@mit.edu>
2018-01-29ext2: convert to new i_version APIJeff Layton2-6/+8
Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz>
2018-01-29exofs: switch to new i_version APIJeff Layton2-5/+7
Signed-off-by: Jeff Layton <jlayton@redhat.com>
2018-01-29btrfs: convert to new i_version APIJeff Layton3-5/+12
Signed-off-by: Jeff Layton <jlayton@redhat.com> Acked-by: David Sterba <dsterba@suse.com>
2018-01-29afs: convert to new i_version APIJeff Layton2-3/+5
For AFS, it's generally treated as an opaque value, so we use the *_raw variants of the API here. Note that AFS has quite a different definition for this counter. AFS only increments it on changes to the data to the data in regular files and contents of the directories. Inode metadata changes do not result in a version increment. We'll need to reconcile that somehow if we ever want to present this to userspace via statx. Signed-off-by: Jeff Layton <jlayton@redhat.com>
2018-01-29affs: convert to new i_version APIJeff Layton3-5/+8
Signed-off-by: Jeff Layton <jlayton@redhat.com>
2018-01-29fat: convert to new i_version APIJeff Layton4-19/+22
Signed-off-by: Jeff Layton <jlayton@redhat.com>
2018-01-29fs: don't take the i_lock in inode_inc_iversionJeff Layton1-3/+4
The rationale for taking the i_lock when incrementing this value is lost in antiquity. The readers of the field don't take it (at least not universally), so my assumption is that it was only done here to serialize incrementors. If that is indeed the case, then we can drop the i_lock from this codepath and treat it as a atomic64_t for the purposes of incrementing it. This allows us to use inode_inc_iversion without any danger of lock inversion. Note that the read side is not fetched atomically with this change. The assumption here is that that is not a critical issue since the i_version is not fully synchronized with anything else anyway. Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz>
2018-01-29fs: new API for handling inode->i_versionJeff Layton9-15/+249
Add a documentation blob that explains what the i_version field is, how it is expected to work, and how it is currently implemented by various filesystems. We already have inode_inc_iversion. Add several other functions for manipulating and accessing the i_version counter. For now, the implementation is trivial and basically works the way that all of the open-coded i_version accesses work today. Future patches will convert existing users of i_version to use the new API, and then convert the backend implementation to do things more efficiently. Signed-off-by: Jeff Layton <jlayton@redhat.com> Reviewed-by: Jan Kara <jack@suse.cz>
2018-01-29Merge tag 'nand/for-4.16' of git://git.infradead.org/linux-mtd into mtd/nextBoris Brezillon64-1913/+6462
Pull NAND changes from Boris Brezillon: " Core changes: * Fix NAND_CMD_NONE handling in nand_command[_lp]() hooks * Introduce the ->exec_op() infrastructure * Rework NAND buffers handling * Fix ECC requirements for K9F4G08U0D * Fix nand_do_read_oob() to return the number of bitflips * Mark K9F1G08U0E as not supporting subpage writes Driver changes: * MTK: Rework the driver to support new IP versions * OMAP OneNAND: Full rework to use new APIs (libgpio, dmaengine) and fix DT support * Marvell: Add a new driver to replace the pxa3xx one "
2018-01-29Merge tag 'spi-nor/for-4.16' of git://git.infradead.org/linux-mtd into mtd/nextBoris Brezillon9-164/+246
Pull spi-nor changes from Cyrille Pitchen: " This pull-request contains the following notable changes: Core changes: * Add support to new ISSI and Cypress/Spansion memory parts. * Fix support of Micron memories by checking error bits in the FSR. * Fix update of block-protection bits by reading back the SR. * Restore the internal state of the SPI flash memory when removing the device. Driver changes: * Maintenance for Freescale, Intel and Metiatek drivers. * Add support of the direct access mode for the Cadence QSPI controller. "
2018-01-29Linux 4.15Linus Torvalds1-1/+1
2018-01-28Merge tag 'perf-core-for-mingo-4.16-20180125' of ↵Ingo Molnar123-12939/+12587
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo: - Introduce a errno code to string facility to allow tools such as 'perf trace' to support multi-arch perf.data decoding/beautifying, uses errno header files copied from the kernel, this allows removing the need for audit-libs in arches generating its syscall tables from the kernel sources, so far x86 and s/390 (Hendrik Brueckner) - Intel-PT/BTS sample synthesizing fixes (Adrian Hunter) - Intel vendor event JSON updates for the Broadwell, BroadwellDE, BroadwellX, Goldmont, Haswell, HaswellX, IvyBridge, IvyBridge, IvyTown, IvyTown, Silvermont, Skylake and SkylakeX architectures. (Andi Kleen) - Use ui__error() to have --field error handling messages not to disappear due to TUI exit cleanup (Arnaldo Carvalho de Melo) - Don't warn about unavailability of builtin clang in 'perf trace', just continue fallbacking to using the external toolchain (Arnaldo Carvalho de Melo) - Move conditional O_CLOEXEC define to util.h to keep the build working on older distros where that is not available now that this define will be used in more source files (Arnaldo Carvalho de Melo) - Using O_CLOEXEC in do_open() to avoid having too many open files when using 'perf script' from the 'perf report' TUI scripts browser (Wang YanQing) - Add 'perf trace --print-sample' to help in debugging the printing of timestamp calculations, for instance (Arnaldo Carvalho de Melo) - Do not print from time delta for interrupted syscall lines in 'perf trace' (those ending with '...') just print the total syscall duration at raw_syscalls:sys_exit time (Arnaldo Carvalho de Melo) - Beautify FUTEX_BITSET_MATCH_ANY in the futex syscall in 'perf trace' (Arnaldo Carvalho de Melo) - Display EXTRA features for 'make VF=1' build (Jiri Olsa) - Add support for CoreSight trace decoding by making the perf tools use the external openCSD (Mathieu Poirier, Tor Jeremiassen) Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-01-28Merge branch 'x86-pti-for-linus' of ↵Linus Torvalds2-2/+0
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 retpoline fixlet from Thomas Gleixner: "Remove the ESP/RSP thunks for retpoline as they cannot ever work. Get rid of them before they show up in a release" * 'x86-pti-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/retpoline: Remove the esp/rsp thunk
2018-01-28Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds7-34/+60
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A set of small fixes for 4.15: - Fix vmapped stack synchronization on systems with 4-level paging and a large amount of memory caused by a missing 5-level folding which made the pgd synchronization logic to fail and causing double faults. - Add a missing sanity check in the vmalloc_fault() logic on 5-level paging systems. - Bring back protection against accessing a freed initrd in the microcode loader which was lost by a wrong merge conflict resolution. - Extend the Broadwell micro code loading sanity check. - Add a missing ENDPROC annotation in ftrace assembly code which makes ORC unhappy. - Prevent loading the AMD power module on !AMD platforms. The load itself is uncritical, but an unload attempt results in a kernel crash. - Update Peter Anvins role in the MAINTAINERS file" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/ftrace: Add one more ENDPROC annotation x86: Mark hpa as a "Designated Reviewer" for the time being x86/mm/64: Tighten up vmalloc_fault() sanity checks on 5-level kernels x86/mm/64: Fix vmapped stack syncing on very-large-memory 4-level systems x86/microcode: Fix again accessing initrd after having been freed x86/microcode/intel: Extend BDW late-loading further with LLC size check perf/x86/amd/power: Do not load AMD power module on !AMD platforms
2018-01-28Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds1-0/+3
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fix from Thomas Gleixner: "A single fix for a ~10 years old problem which causes high resolution timers to stop after a CPU unplug/plug cycle due to a stale flag in the per CPU hrtimer base struct. Paul McKenney was hunting this for about a year, but the heisenbug nature made it resistant against debug attempts for quite some time" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: hrtimer: Reset hrtimer cpu base proper on CPU hotplug
2018-01-28Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds3-5/+18
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Thomas Gleixner: "A single bug fix to prevent a subtle deadlock in the scheduler core code vs cpu hotplug" * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/core: Fix cpu.max vs. cpuhotplug deadlock
2018-01-28Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds2-20/+60
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Thomas Gleixner: "Four patches which all address lock inversions and deadlocks in the perf core code and the Intel debug store" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86: Fix perf,x86,cpuhp deadlock perf/core: Fix ctx::mutex deadlock perf/core: Fix another perf,trace,cpuhp lock inversion perf/core: Fix lock inversion between perf,trace,cpuhp
2018-01-28Merge branch 'locking-urgent-for-linus' of ↵Linus Torvalds2-3/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fixes from Thomas Gleixner: "Two final locking fixes for 4.15: - Repair the OWNER_DIED logic in the futex code which got wreckaged with the recent fix for a subtle race condition. - Prevent the hard lockup detector from triggering when dumping all held locks in the system" * 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/lockdep: Avoid triggering hardlockup from debug_show_all_locks() futex: Fix OWNER_DEAD fixup
2018-01-28fs/cifs/cifsacl.c Fixes typo in a commentAchilles Gaikwad1-1/+1
Signed-off-by: Achilles Gaikwad <achillesgaikwad@gmail.com> Signed-off-by: Steve French <smfrench@gmail.com>
2018-01-28x86/ftrace: Add one more ENDPROC annotationJosh Poimboeuf1-1/+1
When ORC support was added for the ftrace_64.S code, an ENDPROC for function_hook() was missed. This results in the following warning: arch/x86/kernel/ftrace_64.o: warning: objtool: .entry.text+0x0: unreachable instruction Fixes: e2ac83d74a4d ("x86/ftrace: Fix ORC unwinding from ftrace handlers") Reported-by: Steven Rostedt <rostedt@goodmis.org> Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Ingo Molnar <mingo@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lkml.kernel.org/r/20180128022150.dqierscqmt3uwwsr@treble
2018-01-27x86/speculation: Simplify indirect_branch_prediction_barrier()Borislav Petkov3-9/+13
Make it all a function which does the WRMSR instead of having a hairy inline asm. [dwmw2: export it, fix CONFIG_RETPOLINE issues] Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: ak@linux.intel.com Cc: dave.hansen@intel.com Cc: karahmed@amazon.de Cc: arjan@linux.intel.com Cc: torvalds@linux-foundation.org Cc: peterz@infradead.org Cc: bp@alien8.de Cc: pbonzini@redhat.com Cc: tim.c.chen@linux.intel.com Cc: gregkh@linux-foundation.org Link: https://lkml.kernel.org/r/1517070274-12128-4-git-send-email-dwmw@amazon.co.uk
2018-01-27x86/retpoline: Simplify vmexit_fill_RSB()Borislav Petkov6-65/+71
Simplify it to call an asm-function instead of pasting 41 insn bytes at every call site. Also, add alignment to the macro as suggested here: https://support.google.com/faqs/answer/7625886 [dwmw2: Clean up comments, let it clobber %ebx and just tell the compiler] Signed-off-by: Borislav Petkov <bp@suse.de> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: ak@linux.intel.com Cc: dave.hansen@intel.com Cc: karahmed@amazon.de Cc: arjan@linux.intel.com Cc: torvalds@linux-foundation.org Cc: peterz@infradead.org Cc: bp@alien8.de Cc: pbonzini@redhat.com Cc: tim.c.chen@linux.intel.com Cc: gregkh@linux-foundation.org Link: https://lkml.kernel.org/r/1517070274-12128-3-git-send-email-dwmw@amazon.co.uk
2018-01-27x86/cpufeatures: Clean up Spectre v2 related CPUID flagsDavid Woodhouse4-24/+34
We want to expose the hardware features simply in /proc/cpuinfo as "ibrs", "ibpb" and "stibp". Since AMD has separate CPUID bits for those, use them as the user-visible bits. When the Intel SPEC_CTRL bit is set which indicates both IBRS and IBPB capability, set those (AMD) bits accordingly. Likewise if the Intel STIBP bit is set, set the AMD STIBP that's used for the generic hardware capability. Hide the rest from /proc/cpuinfo by putting "" in the comments. Including RETPOLINE and RETPOLINE_AMD which shouldn't be visible there. There are patches to make the sysfs vulnerabilities information non-readable by non-root, and the same should apply to all information about which mitigations are actually in use. Those *shouldn't* appear in /proc/cpuinfo. The feature bit for whether IBPB is actually used, which is needed for ALTERNATIVEs, is renamed to X86_FEATURE_USE_IBPB. Originally-by: Borislav Petkov <bp@suse.de> Signed-off-by: David Woodhouse <dwmw@amazon.co.uk> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: ak@linux.intel.com Cc: dave.hansen@intel.com Cc: karahmed@amazon.de Cc: arjan@linux.intel.com Cc: torvalds@linux-foundation.org Cc: peterz@infradead.org Cc: bp@alien8.de Cc: pbonzini@redhat.com Cc: tim.c.chen@linux.intel.com Cc: gregkh@linux-foundation.org Link: https://lkml.kernel.org/r/1517070274-12128-2-git-send-email-dwmw@amazon.co.uk
2018-01-27hwmon: (dell-smm) Disable fan support for Dell Vostro 3360Oleksandr Natalenko1-0/+7
Calling fan related SMM functions implemented by Dell BIOS firmware on Dell Vostro 3360 freeze kernel for about 500ms. Unfortunately, it is unlikely for Dell to fix this since the machine is pretty old, so this commit just disables fan support to make the system usable again. Via "force" module param fan support can be enabled. Link: https://bugzilla.kernel.org/show_bug.cgi?id=195751 Link: http://lkml.iu.edu/hypermail/linux/kernel/1711.2/06083.html Reviewed-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27hwmon: (dell-smm) Disable fan support for Dell Inspiron 7720Pali Rohár1-1/+39
Calling fan related SMM functions implemented by Dell BIOS firmware on Dell Inspiron 7720 freeze kernel for about 500ms. Until Dell fixes it we need to disable fan support for Dell Inspiron 7720 as it makes system unusable. Via "force" module param fan support can be enabled. Reported-by: vova7890@mail.ru Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=195751 Cc: stable@vger.kernel.org # v4.0+, will need backport Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27hwmon: (dell-smm) Enable broken functionality via "force" module paramPali Rohár1-2/+5
Some Dell machines are broken and some functionality is disabled. Show warning into dmesg about this fact and allow user via "force" module param to override brokenness and enable broken functionality. Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
2018-01-27x86/cpu/bugs: Make retpoline module warning conditionalThomas Gleixner1-3/+11
If sysfs is disabled and RETPOLINE not defined: arch/x86/kernel/cpu/bugs.c:97:13: warning: ‘spectre_v2_bad_module’ defined but not used [-Wunused-variable] static bool spectre_v2_bad_module; Hide it. Fixes: caf7501a1b4e ("module/retpoline: Warn about missing retpoline in module") Reported-by: Borislav Petkov <bp@alien8.de> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: David Woodhouse <dwmw2@infradead.org>
2018-01-27Merge branch 'timers/urgent' into timers/coreThomas Gleixner539-2533/+7437
Pick up urgent bug fix and resolve the conflict. Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2018-01-27hrtimer: Reset hrtimer cpu base proper on CPU hotplugThomas Gleixner1-0/+3
The hrtimer interrupt code contains a hang detection and mitigation mechanism, which prevents that a long delayed hrtimer interrupt causes a continous retriggering of interrupts which prevent the system from making progress. If a hang is detected then the timer hardware is programmed with a certain delay into the future and a flag is set in the hrtimer cpu base which prevents newly enqueued timers from reprogramming the timer hardware prior to the chosen delay. The subsequent hrtimer interrupt after the delay clears the flag and resumes normal operation. If such a hang happens in the last hrtimer interrupt before a CPU is unplugged then the hang_detected flag is set and stays that way when the CPU is plugged in again. At that point the timer hardware is not armed and it cannot be armed because the hang_detected flag is still active, so nothing clears that flag. As a consequence the CPU does not receive hrtimer interrupts and no timers expire on that CPU which results in RCU stalls and other malfunctions. Clear the flag along with some other less critical members of the hrtimer cpu base to ensure starting from a clean state when a CPU is plugged in. Thanks to Paul, Sebastian and Anna-Maria for their help to get down to the root cause of that hard to reproduce heisenbug. Once understood it's trivial and certainly justifies a brown paperbag. Fixes: 41d2e4949377 ("hrtimer: Tune hrtimer_interrupt hang logic") Reported-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sebastian Sewior <bigeasy@linutronix.de> Cc: Anna-Maria Gleixner <anna-maria@linutronix.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/alpine.DEB.2.20.1801261447590.2067@nanos
2018-01-27x86: Mark hpa as a "Designated Reviewer" for the time beingH. Peter Anvin1-11/+1
Due to some unfortunate events, I have not been directly involved in the x86 kernel patch flow for a while now. I have also not been able to ramp back up by now like I had hoped to, and after reviewing what I will need to work on both internally at Intel and elsewhere in the near term, it is clear that I am not going to be able to ramp back up until late 2018 at the very earliest. It is not acceptable to not recognize that this load is currently taken by Ingo and Thomas without my direct participation, so I mark myself as R: (designated reviewer) rather than M: (maintainer) until further notice. This is in fact recognizing the de facto situation for the past few years. I have obviously no intention of going away, and I will do everything within my power to improve Linux on x86 and x86 for Linux. This, however, puts credit where it is due and reflects a change of focus. This patch also removes stale entries for portions of the x86 architecture which have not been maintained separately from arch/x86 for a long time. If there is a reason to re-introduce them then that can happen later. Signed-off-by: H. Peter Anvin <h.peter.anvin@intel.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Bruce Schlobohm <bruce.schlobohm@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20180125195934.5253-1-hpa@zytor.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-01-27Merge tag 'riscv-for-linus-4.15-maintainers' of ↵Linus Torvalds1-2/+2
git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux Pull RISC-V update from Palmer Dabbelt: "RISC-V: We have a new mailing list and git repo! Sorry to send something essentially as late as possible (Friday after an rc9), but we managed to get a mailing list for the RISC-V Linux port. We've been using patches@groups.riscv.org for a while, but that list has some problems (it's Google Groups and it's shared over all RISC-V software projects). The new infaread.org list is much better. We just got it on Wednesday but I used it a bit on Thursday to shake out all the configuration problems and it appears to be in working order. When I updated the mailing list I noticed that the MAINTAINERS file was pointing to our github repo, but now that we have a kernel.org repo I'd like to point to that instead so I changed that as well. We'll be centralizing all RISC-V Linux related development here as that seems to be the saner way to go about it. I can understand if it's too late to get this into 4.15, but given that it's not a code change I was hoping it'd still be OK. It would be nice to have the new mailing list and git repo in the release tarballs so when people start to find bugs they'll get to the right place" * tag 'riscv-for-linus-4.15-maintainers' of git://git.kernel.org/pub/scm/linux/kernel/git/palmer/riscv-linux: Update the RISC-V MAINTAINERS file
2018-01-27update internal version number for cifs.koSteve French1-1/+1
To version 2.11 Signed-off-by: Steve French <smfrench@gmail.com>
2018-01-27cifs: add .splice_writeAndrés Souto1-0/+6
add splice_write support in cifs vfs using iter_file_splice_write Signed-off-by: Andrés Souto <kai670@gmail.com> Signed-off-by: Steve French <smfrench@gmail.com>
2018-01-27CIFS: document tcon/ses/server refcount danceAurelien Aptel1-1/+31
Signed-off-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
2018-01-27move a few externs to smbdirect.h to eliminate warningSteve French2-9/+9
Quiet minor sparse warnings in new SMB3 rdma patch series ("symbol was not declared ...") by moving these externs to smbdirect.h Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
2018-01-27CIFS: zero sensitive data when freeingAurelien Aptel3-15/+8
also replaces memset()+kfree() by kzfree(). Signed-off-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com> Cc: <stable@vger.kernel.org>
2018-01-27Cleanup some minor endian issues in smb3 rdmaSteve French3-20/+21
Minor cleanup of some sparse warnings (including a few misc endian fixes for the new smb3 rdma code) Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Ronnie Sahlberg <lsahlber@redhat.com>
2018-01-27CIFS: dump IPC tcon in debug proc fileAurelien Aptel1-26/+35
dump it as first share with an "IPC: " prefix. Signed-off-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
2018-01-27CIFS: use tcon_ipc instead of use_ipc parameter of SMB2_ioctlAurelien Aptel4-37/+25
Since IPC now has a tcon object, the caller can just pass it. This allows domain-based DFS requests to work with smb2+. Link: https://bugzilla.samba.org/show_bug.cgi?id=12917 Fixes: 9d49640a21bf ("CIFS: implement get_dfs_refer for SMB2+") Signed-off-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
2018-01-27CIFS: make IPC a regular tconAurelien Aptel5-76/+133
* Remove ses->ipc_tid. * Make IPC$ regular tcon. * Add a direct pointer to it in ses->tcon_ipc. * Distinguish PIPE tcon from IPC tcon by adding a tcon->pipe flag. All IPC tcons are pipes but not all pipes are IPC. * All TreeConnect functions now cannot take a NULL tcon object. The IPC tcon has the same lifetime as the session it belongs to. It is created when the session is created and destroyed when the session is destroyed. Since no mounts directly refer to the IPC tcon, its refcount should always be set to initialisation value (1). Thus we make sure cifs_put_tcon() skips it. If the mount request resulting in a new session being created requires encryption, try to require it too for IPC. * set SERVER_NAME_LENGTH to serverName actual size The maximum length of an ipv6 string representation is defined in INET6_ADDRSTRLEN as 45+1 for null but lets keep what we know works. Signed-off-by: Aurelien Aptel <aaptel@suse.com> Signed-off-by: Steve French <smfrench@gmail.com> Reviewed-by: Pavel Shilovsky <pshilov@microsoft.com>
2018-01-26block: remove smart1,2.hCorentin Labbe1-278/+0
smart1,2.h is unused since commit d436641439e0 ("cpqarray: remove it from the kernel") Remove it from tree. Signed-off-by: Corentin Labbe <clabbe@baylibre.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
generated by cgit v1.2.3 (git 2.39.0) at 2024-10-19 00:11:52 +0300