Hosts the 0x221E linux distro kernel. https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y 2013-06-29T08:57:30Z 2013-06-29T08:57:30Z Al Viro viro@zeniv.linux.org.uk 2013-06-17T11:31:22Z urn:sha1:65004276fc45a37c133f09a86712e6f2daede342 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 2013-03-27T00:30:17Z Al Viro viro@zeniv.linux.org.uk 2013-03-27T00:30:17Z urn:sha1:e8cd81693bbbb15db57d3c9aa7dd90eda4842874 vcs_poll_data_free() calls unregister_vt_notifier(), which calls atomic_notifier_chain_unregister(), which calls synchronize_rcu(). Do it *after* we'd dropped ->f_lock. Cc: stable@vger.kernel.org (all kernels since 2.6.37) Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 2013-02-23T04:31:31Z Al Viro viro@zeniv.linux.org.uk 2013-01-23T22:07:38Z urn:sha1:496ad9aa8ef448058e36ca7a787c61f2e63f0f54 Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> 2012-03-08T19:10:27Z Alan Cox alan@linux.intel.com 2012-03-02T14:59:20Z urn:sha1:4001d7b7fc271052ebff43f327c26dc64806bbdf At this point we have the tty_lock guarding a couple of oddities, plus the translation and unimap still. We also extend the console_lock in a couple of spots where coverage is wrong and switch vcs_open to use the right lock ! [Fixed the locking issue Jiri reported] Signed-off-by: Alan Cox <alan@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2011-10-31T23:31:28Z Paul Gortmaker paul.gortmaker@windriver.com 2011-05-27T14:46:24Z urn:sha1:0e648f42f24f89e24c4dcac534d8e7086c9fd559 With module.h being implicitly everywhere via device.h, the absence of explicitly including something for EXPORT_SYMBOL went unnoticed. Since we are heading to fix things up and clean module.h from the device.h file, we need to explicitly include these files now. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> 2011-04-19T23:33:36Z Jovi Zhang bookjovi@gmail.com 2011-03-30T09:30:41Z urn:sha1:99edb3d10a9d384d69557bd09cc39b9ec62aa04e remove invalid location line in each file header after location moved from driver/char to driver/tty Signed-off-by: Jovi Zhang <bookjovi@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2011-03-17T00:21:00Z Linus Torvalds torvalds@linux-foundation.org 2011-03-17T00:21:00Z urn:sha1:f74b9444192c60603020c61d7915b72893137edc * 'config' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/bkl: BKL: That's all, folks fs/locks.c: Remove stale FIXME left over from BKL conversion ipx: remove the BKL appletalk: remove the BKL x25: remove the BKL ufs: remove the BKL hpfs: remove the BKL drivers: remove extraneous includes of smp_lock.h tracing: don't trace the BKL adfs: remove the big kernel lock 2011-03-01T23:02:40Z Arnd Bergmann arnd@arndb.de 2011-01-25T21:08:05Z urn:sha1:5edc341313a188d94cde7ef87ac31647cea8601a These were missed the last time I cleaned this up globally, because of code moving around or new code getting merged. Signed-off-by: Arnd Bergmann <arnd@arndb.de> 2011-02-17T19:13:19Z Jiri Olsa jolsa@redhat.com 2011-02-07T18:31:25Z urn:sha1:fcdba07ee390d9d9c15de8b2a17baef689284fcc seems there's no longer need for using con_buf/conf_buf_mtx as vcs_read/vcs_write buffer for user's data. The do_con_write function, that was the other user of this, is currently using its own kmalloc-ed buffer. Not sure when this got changed, as I was able to find this code in 2.6.9, but it's already gone as far as current git history goes - 2.6.12-rc2. AFAICS there's a behaviour change with the current change. The lseek is not completely mutually exclusive with the vcs_read/vcs_write - the file->f_pos might get updated via lseek callback during the vcs_read/vcs_write processing. I tried to find out if the prefered behaviour is to keep this in sync within read/write/lseek functions, but I did not find any pattern on different places. I guess if user end up calling write/lseek from different threads she should know what she's doing. If needed we could use dedicated fd mutex/buffer. Signed-off-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> 2011-02-17T19:13:19Z Jiri Olsa jolsa@redhat.com 2011-02-07T18:31:24Z urn:sha1:dc1892c4bc6960121ca4c8023a07c815cfd689be there's a race between vcs's lseek handler and VC release. The lseek handler does not hold console_lock and touches VC's size info. If during this the VC got released, there's an access violation. Following program triggers the issue for me: [SNIP] #define _BSD_SOURCE #include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> #include <sys/ioctl.h> #include <linux/vt.h> #include <unistd.h> #include <errno.h> static int run_seek(void) { while(1) { int fd; fd = open("./vcs30", O_RDWR); while(lseek(fd, 0, 0) != -1); close(fd); } } static int open_ioctl_tty(void) { return open("/dev/tty1", O_RDWR); } static int do_ioctl(int fd, int req, int i) { return ioctl(fd, req, i); } #define INIT(i) do_ioctl(ioctl_fd, VT_ACTIVATE, i) #define SHUT(i) do_ioctl(ioctl_fd, VT_DISALLOCATE, i) int main(int argc, char **argv) { int ioctl_fd = open_ioctl_tty(); if (ioctl < 0) { perror("open tty1 failed\n"); return -1; } if ((-1 == mknod("vcs30", S_IFCHR|0666, makedev(7, 30))) && (errno != EEXIST)) { printf("errno %d\n", errno); perror("failed to create vcs30"); return -1; } do_ioctl(ioctl_fd, VT_LOCKSWITCH, 0); if (!fork()) run_seek(); while(1) { INIT(30); SHUT(30); } return 0; } [SNIP] Signed-off-by: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>