Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> > Which is the sudo case and why sudo uses a separate pty/tty pair as it's > > not just TIOCSTI that's an issue but there are a load of ioctls that do > > things like cause signals to the process or are just annoying - > > vhangup(), changing the speed etc > > > > (And for console changing the ke

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> open() what? As far as I know, for System-V PTYs, there is no path you can > open() that will give you the PTY master. Am I missing something? Sorry brain fade - no. > > >> > If I want to do the equvalent of the TIOCSTI attack then I fork a process > >> > and exit the parent. The child can now

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> Really? By "pty", are you referring to the master? If so, as far as I know, > to go from the slave to the master, you need one of: > > - ptrace access to a process that already has an FD to the master, via >ptrace() or so (/proc/$pid/fd/$fd won't work) > - for a BSD PTY (which AFAIK isn't

Re: [PATCH 00/16] Intel FPGA Device Drivers

> That is where we disagree. I do not see bitstream as firmware. For instance > now you can run OpenCL on some FPGA, so this is exactly like GPU we should > request open source stack from OpenCL down to bitstream. It's an accelerator with a bunch of firmwares where you load the right one. We've go

Re: [PATCH v5 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, 25 Apr 2017 15:56:32 +0200 Jann Horn wrote: > On Tue, Apr 25, 2017 at 3:47 PM, Alan Cox wrote: > >> There could be a few user programs that would be effected by this > >> change. > >> See: > >> notable programs are: agetty, cs

Re: [PATCH v2 2/9] tty_port: allow a port to be opened with a tty that has no file handle

On Mon, 16 Jan 2017 16:54:29 -0600 Rob Herring wrote: > From: Alan Cox > > Let us create tty objects entirely in kernel space. Untested proposal to > show why all the ideas around rewriting half the uart stack are not needed. > > With this a kernel created non file backed tty object could be u

Re: [PATCH 6/9] dt/bindings: Add a serial/UART attached device binding

On Fri, 6 Jan 2017 10:26:32 -0600 Rob Herring wrote: > Add a common binding for describing serial/UART attached devices. Common > examples are Bluetooth, WiFi, NFC and GPS devices. > > Serial attached devices are represented as child nodes of a UART node. > This may need to be extended for more

Re: [PATCH] serial/8250: remove comment about schedule_timeout

On Thu, 5 Jan 2017 13:48:40 -0200 Thadeu Lima de Souza Cascardo wrote: > Ted T'so has added the function size_fifo in 1999 for the 2.3 series > [1], a long time ago. > > During the 2.5 cycle, Russell King has restructured the serial drivers > and, in that process, has suggested using schedule_t

Re: Geode LX AES/RNG driver triggers warning

On Sat, 31 Dec 2016 00:58:54 +0100 David Gstir wrote: > Hi! > > I recently tested kernel v4.9 on my AMD Geode platform and noticed that its > AES hardware driver triggers this warning on initialization: ... > I narrowed it down to commit 6e9b5e76882c ("hwrng: geode - Migrate to managed > API

Re: [PATCH 1/4] serial: core: Add LED trigger support

> > If we have different UART drivers, only one of them provides ttyS*, no? > > Other drivers will have to use another namespace. > > I remember this was a problem a couple of years ago last I tried, with > the 8250 driver being actually preventing other drivers from using > ttyS*, but if you do

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

> If the parameters plausibly make it possible for root to modify the > kernel in interesting ways, then restricting them makes sense. My gut > sense is that parameters that allow the alteration of the base address > of memory mapped devices are clearly a problem in this respect, but port > io

Re: [PATCH 01/39] Annotate module params that specify hardware parameters (eg. ioport)

On Thu, 01 Dec 2016 16:02:26 + David Howells wrote: > Greg KH wrote: > > > Also, I think Alan's comment about it the last time it came up was more like > > a "look at all of the other ways you could do bad things to hardware!" > > comment, not a "you need to also do this thing too!" type of

Re: [PATCH 09/39] Annotate hardware config module parameters in drivers/i2c/

O> > > Suggested-by: One Thousand Gnomes > > > > I know this is only a Suggested-by and not a Signed-off-by, but still I > > believe the Developer's Certificate of Origin applies, and it says: > > "using your real name (sorry, no pseudonyms or anonym

Re: [PATCH] Lock down drivers that can have io ports, io mem, irqs and dma changed

On Tue, 29 Nov 2016 14:03:31 + David Howells wrote: > How about the attached? Obviously it need extending to other drivers. > > I thought that if I'm changing the module_param annotations anyway then it's > probably worth bunging in an extra parameter that notes what the parameter > modifie

Re: [PATCH 00/16] Kernel lockdown

> This applies equally to the kernel command line, and given that we > cannot authenticate it, we should whitelist params that we know to be > safe, and filter out all others. A similar concern exists for the > device tree on ARM/arm64, and we already disable the DTB loader in the > UEFI stub if se

Re: [PATCH] x86/boot: Fail the boot if !M486 and CPUID is missing

> Rather than trying to work around these issues, just have the kernel > fail loudly if it's running on a CPUID-less 486, doesn't have CPUID, > and doesn't have CONFIG_M486 set. NAK This still breaks the Geode at the very least and I think the ELAN and some of the other older socket 7 devices. Th

Re: [PATCH 1/4] statx: Add a system call to make enhanced file info available

> > increase in timestamp resoultion of at least another 10e-3 is > > likely > > Is it, though? To be useful, surely you have to be able to jam quite a few > instructions into a 1ns block, including memory accesses. > > Rather than providing: > > struct timestamp { > _

Re: [PATCHv0 1/1] fbdev: add Intel FPGA FRAME BUFFER driver

> AIUI, we're not taking new FB drivers. This should be a DRM driver > instead. Yes - clone one of the dumb DRM drivers, or if you've got any little bits of acceleration (even rolling the display) then it's possibly worth accelerating for text mode. > > +- max-width: The width of the framebuffer

Re: why is the sys_close symbol exported ?

On Fri, 18 Nov 2016 09:56:52 +0100 jmfriedt wrote: > Following the various rootkit and system call redirection developments, the > current > way of identifying the location of the system call table seems to be brute > force scanning > the memory for the location of one of the system calls. Thi

Re: [RFC][PATCH 0/4] Enhanced file stat system call

> Hmmm... Interesting question. Probably should. But you could be insane and > RAID an nbd and a local disk. Further, does NFS over a loopback device to > nfsd on the same machine qualify as root? What if that's exposing a local fs > on NBD? Perhaps I should drop 'REMOTE' for now. It sounds l

Re: [RFC][PATCH 0/4] Enhanced file stat system call

> (2) Lightweight stat (AT_STATX_DONT_SYNC): Ask for just those details of > interest, and allow a network fs to approximate anything not of > interest, without going to the server. > > (3) Heavyweight stat (AT_STATX_FORCE_SYNC): Force a network fs to flush > buffers and go to the

Re: [PATCH 00/16] Kernel lockdown

Whether it's a good idea aside You need to filter or lock down kernel module options because a lot of modules let you set the I/O port or similar (eg mmio) which means you can hack the entire machine with say the 8250 driver just by using it with an mmio of the right location to patch the secure s

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

> > It's not a safe assumption for x86 at least. There are a few systems with > > multiple ISA busses particularly older laptops with a docking station. > > But do they have multiple ISA domains? There is no real harm in supporting > it, the (small) downsides I can think of are: I don't believe

Re: [PATCH V5 3/3] ARM64 LPC: LPC driver implementation on Hip06

On Wed, 09 Nov 2016 22:34:38 +0100 Arnd Bergmann wrote: > On Wednesday, November 9, 2016 12:10:43 PM CET Gabriele Paoloni wrote: > > > On Tuesday, November 8, 2016 11:47:09 AM CET zhichang.yuan wrote: > > > > + /* > > > > +* The first PCIBIOS_MIN_IO is reserved specifically for

Re: [PATCH 0/4] x86: enable User-Mode Instruction Prevention

> I took a closer look at the dosemu code. It appears that it does not That doesn't tell you want DOS itself will try and do... > purposely utilize SGDT to obtain the descriptor table while in vm86. It > does use SGDT (in protected mode) to emulate certain functionality such > as the Virtual xxx

Re: [PATCH V5 2/3] ARM64 LPC: Add missing range exception for special ISA

> I think it is a relatively safe assumption that there is only one > ISA bridge. A lot of old drivers hardcode PIO or memory addresses It's not a safe assumption for x86 at least. There are a few systems with multiple ISA busses particularly older laptops with a docking station. > when talking t

Re: Bogus "APIC: NR_CPUS/possible_cpus limit of 4 reached" messages

On Thu, 6 Oct 2016 13:27:37 +0200 Markus Trippelsdorf wrote: > On current trunk I get during boot: > > [0.00] APIC: NR_CPUS/possible_cpus limit of 4 reached. Processor > 4/0x84 ignored. > [0.00] APIC: NR_CPUS/possible_cpus limit of 4 reached. Processor > 5/0x85 ignored. > >

Re: Should drivers like nvme let userspace control their latency via dev_pm_qos?

On Fri, 16 Sep 2016 08:26:03 -0700 Andy Lutomirski wrote: > I'm adding power management to the nvme driver, and I'm exposing > exactly one knob via sysfs: the maximum permissible latency. This > isn't a power domain issue, and it has no dependencies -- it's > literally just the maximum latency t

Re: [RFC] writev() semantics with invalid iovec in the middle

> Unfortunately, some of LTP writev tests end up checking that writev() does > behave that way - they feed it a three-element iovec with shorter-than-page > segments, the second of which is all invalid. And they check that the > entire first segment had been written. 1003.1 says "Each iovec entr

Re: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

On Thu, 15 Sep 2016 16:19:52 +0300 Andrey Utkin wrote: > On Thu, Sep 15, 2016 at 03:15:53PM +0200, Hans Verkuil wrote: > > It could be related to the fact that a PCI write may be delayed unless > > it is followed by a read (see also the comments in > > drivers/media/pci/ivtv/ivtv-driver.h). >

Re: [PATCH v2 0/8] Support Intel® Turbo Boost Max Technology 3.0

On Thu, 15 Sep 2016 14:14:30 +0200 Pavel Machek wrote: > Hi! > > > - Feature is enabled by default for single socket systems > > > > With Intel® Turbo Boost Max Technology 3.0 (ITMT), single-threaded > > performance is > > optimized by identifying processor's fastest core and running critical

Re: [PATCH] pty: make ptmx file ops read-only after init

On Wed, 14 Sep 2016 09:59:42 +0200 Jiri Slaby wrote: > On 09/09/2016, 12:35 AM, Kees Cook wrote: > > The ptmx_fops structure is only changed during init, so mark it as such. > > Right, but I am missing what is the benefit? You would have to elaborate > here... The pages end up marked read onl

Re: [PATCH 0/9] tty: tty_struct dependency clean-ups

On Sun, 11 Sep 2016 22:05:07 -0500 Rob Herring wrote: > On Sun, Sep 11, 2016 at 4:14 PM, One Thousand Gnomes > wrote: > > On Fri, 9 Sep 2016 17:37:01 -0500 > > Rob Herring wrote: > > > >> This patch series removes or prepares to remove some of the depen

Re: [PATCH 9/9] tty: serial_core: add tty NULL check in uart_port_startup

On Fri, 9 Sep 2016 17:37:10 -0500 Rob Herring wrote: > If we don't have a tty when calling uart_port_startup, skip the baudrate > and modem control setup which depend on tty->termios struct. Either > tty_port clients will configure the line in a separate call or we'll > move termios into the tty

Re: [PATCH 4/9] tty: move TTY_IO_ERROR flag to tty_port iflags

On Fri, 9 Sep 2016 17:37:05 -0500 Rob Herring wrote: > TTY_IO_ERROR is a property of the tty port rather than the tty, so move > it to tty_port struct and remove another dependency on tty_struct from > drivers. > > Partially converted with coccinelle: > > @@ > identifier t; > identifier func;

Re: [PATCH 0/9] tty: tty_struct dependency clean-ups

On Fri, 9 Sep 2016 17:37:01 -0500 Rob Herring wrote: > This patch series removes or prepares to remove some of the dependencies > on tty_struct within tty_port drivers. This will allow using tty_ports > directly for so called UART slave devices. You can create a tty_struct kernel side with t

Re: [PATCH 3/9] tty: move hw_stopped flag to tty_port

On Fri, 9 Sep 2016 17:37:04 -0500 Rob Herring wrote: > hw_stopped is a property of the tty port rather than the tty, so move it > to tty_port struct and remove another dependency on tty_struct from > drivers. > > Converted with coccinelle: This one makes sense. It's moving the object to the ri

Re: [lkp] [tty] 761ed4a945: BUG: unable to handle kernel NULL pointer dereference at 000000000000046c

On Fri, 9 Sep 2016 11:40:47 -0500 Rob Herring wrote: > On Wed, Sep 7, 2016 at 3:47 PM, Rob Herring wrote: > > On Tue, Sep 6, 2016 at 1:33 AM, kernel test robot > > wrote: > >> > >> FYI, we noticed the following commit: > >> > >> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next

Re: tty: use-after-free in n_tty_receive_buf_fast

On Sat, 3 Sep 2016 14:42:08 +0200 Dmitry Vyukov wrote: > Hello, > > The following program causes use-after-free in n_tty_receive_buf_fast: > > https://gist.githubusercontent.com/dvyukov/ac81bed0238f280ddf9067e6234cd8b0/raw/791c07ac0cdb27e2e399464d68fa0234d2aa8bd1/gistfile1.txt > Known bug. It'

Re: 6pack: stack-out-of-bounds in sixpack_receive_buf

> different runs). Looking at code, the following looks suspicious -- we > limit copy by 512 bytes, but use the original count which can be > larger than 512: > > static void sixpack_receive_buf(struct tty_struct *tty, > const unsigned char *cp, char *fp, int count) > { > unsigned char buf

Re: 6pack: stack-out-of-bounds in sixpack_receive_buf

On Sat, 3 Sep 2016 15:38:08 +0200 Dmitry Vyukov wrote: > Hello, > > While running syzkaller fuzzer I've got the following report: > > BUG: KASAN: stack-out-of-bounds in sixpack_receive_buf+0xf8a/0x1450 at > addr 880037fbf850 > Read of size 1 by task syz-executor/6759 > page:eadfefc0

Re: tty: sleeping function in invalid in context do_con_write and deadlock in gsm_control_retransmit

On Sat, 3 Sep 2016 13:07:27 +0200 Dmitry Vyukov wrote: > Hello, > > While running syzkaller fuzzer on > 0f98f121e1670eaa2a2fbb675e07d6ba7f0e146f of linux-next, I've for the > following splash. Note there are 2 separate bugs (but maybe related): > There are a couple of known cases where strange

Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords

On Fri, 26 Aug 2016 17:26:18 -0400 James Bottomley wrote: > On Fri, 2016-08-26 at 22:12 +0100, One Thousand Gnomes wrote: > > > A non-security use case would be to run the binary (without > > > modification) with a different ELF interpreter (assuming this > > >

Re: [PATCH] binfmt_misc: allow selecting the interpreter based on xattr keywords

> A non-security use case would be to run the binary (without > modification) with a different ELF interpreter (assuming this allows to > override binfmt_elf, but self-sandboxing would need that as well). This > would make it easier to use older or newer libcs for select binaries on > the syst

Re: [RFC PATCH 0/3] UART slave device bus

> Either we'd have to call tty_port->rx a character at a time or > implement some temporary buffer. I don't think we want to call things > like BT receive code a byte at a time. This needs to be a layer > higher. flush_to_ldisc either needs to be duplicated to handle > tty_port->rx or generalized t

Re: CVE-2014-9900 fix is not upstream

> > I see someone did request it 2 years ago: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63479 > > I don't think this is sufficient. Basically if you write one field in a > struct after a memset again, the compiler is allowed by the standard to > write padding bytes again, causing them to

Re: [RFC PATCH 0/3] UART slave device bus

> So you mean if I do "hciconfig hci0 down", then the uart-bus should > "down" the tty and only on "hciconfig hci0 up" it should "up" the > tty? I would expect a uart-bus slave-device takes control of the > device ("up" it) on probe. It's hardwired anyway. Today you can switch stacks at runtime, y

Re: [PATCH 1/2] tty: serial_core: convert uart_open to use tty_port_open

On Mon, 22 Aug 2016 17:39:09 -0500 Rob Herring wrote: > tty_port_open handles much of the common parts of tty opening. Convert > uart_open to use it and move the serial_core specific parts into > tty_port.activate function. This will be needed to use tty_port functions > directly from in kernel c

Re: [REGRESSION] Select hang with zero sized UDP packets

On Wed, 24 Aug 2016 11:22:09 +0300 "Dan Akunis" wrote: > When select wakes up on a UDP socket, user is expecting to get data. Getting > 0 from recvfrom() or whatever read function she uses, is a wrong attitude. > I agree with David. > > The unit test that expects select to wake up is wrong and

Re: [RFC PATCH 0/3] UART slave device bus

> > That would still be a regression. Not everyone even uses the kernel > > bluetooth stack. It would only return EBUSY if you had done an "up" > > on it via the direct bluetooth stack. > > So it returns EBUSY when uart-bus is used. Since uart-bus is about > hardwired devices that's basically al

Re: [RFC PATCH 0/3] UART slave device bus

> It's not enough to automatically set a ldisc. There is also need for > additional resouces. For example the Nokia bluetooth driver needs > some extra GPIOs. The same is true for the in-tree hci_bcm, which > misuses the platform_device exactly like Greg doesn't want it. This is one of those cases

Re: [RFC PATCH 0/3] UART slave device bus

> There are usb-serial devices, which could benefit from support > btw. I would find it really useful, if the Dangerous Prototype's > Bus Pirate would expose native /dev/i2c and /dev/spi and it's > based on FT232. That should just need an ldisc. I2C and SPI should at this point be sane for hotplug

Re: [RFC PATCH 0/3] UART slave device bus

On Tue, 23 Aug 2016 00:00:17 +0200 Pavel Machek wrote: > On Mon 2016-08-22 22:32:23, One Thousand Gnomes wrote: > > > why would we even have it create a /dev/ttyX for these devices in the > > > first place. Lets just not create an uevent for it and lets not create

Re: [RFC PATCH 0/3] UART slave device bus

> I now wonder if we can not just turn the ldisc into a bus. So we have a ldisc > bus that exposes devices that have no business of having a userspace > /dev/ttyX exposed. And our Bluetooth UART support just turns into a ldisc > driver on the ldisc bus. The ldisc and tty have the wrong object l

Re: [RFC PATCH 0/3] UART slave device bus

> why would we even have it create a /dev/ttyX for these devices in the first > place. Lets just not create an uevent for it and lets not create a dev_t for > it. Because if you don't it's a regression. It's not permissible to break existing userspace. > Internally the setup stage does a hcicon

Re: [RFC PATCH 0/3] UART slave device bus

> I'm talking about serio, not my design which I already said the > receive side at least needs work. > > The serio API for rx and tx is a single character at a time. I thought > we agreed that's not sufficient for things like BT. Yes. > > >> - a child of the uart node > >> - a reg property con

Re: [RFC PATCH 0/3] UART slave device bus

> Would it make sense then to define a DT binding that can cover these > four cases independent of the Linux usage: > > a) an existing tty line discipline matched to a tty port > b) a serio device using the N_MOUSE line discipline (which >happens to cover non-mouse devices these days) These t

Re: [RFC PATCH 0/3] UART slave device bus

> > I think there are two other valuable features provided by serio: > > > > - an existing set of drivers written to the API > > - the implementation of the tty_ldisc > > True, though I'd expect little of the data flow part of it to be reused. Then your design is broken. > - a child of the uar

Re: [PATCH] drm/gma500: dont expose bytes from kernel stack

On Mon, 22 Aug 2016 09:29:17 +0200 Daniel Vetter wrote: > On Sun, Aug 21, 2016 at 08:39:38PM +0200, Heinrich Schuchardt wrote: > > Components m1, m2, p2, dot, vco of variable clock should be > > initialized to avoid bytes from the kernel stack to be > > exposed. > > > > Signed-off-by: Heinrich S

Re: [RFC PATCH 0/3] UART slave device bus

> When and how fast is the work queue scheduled? > And by which event? That depends upon the platform and how busy the machine is. The dumb uarts generally schedule it as soon as they've emptied the hardware. Some controllers it may be done off a timer, others off DMA completion events > > The w

Re: [RFC PATCH 0/3] UART slave device bus

> Let me ask a question about your centralized and pre-cooked buffering > approach. > > As far as I see, even then the kernel API must notify the driver at the right > moment > that a new block has arrived. Right? The low level driver queues words (data byte, flag byte) The buffer processing wo

Re: [RFC PATCH 0/3] UART slave device bus

> A single one is already difficult... And some scenarios need to shield the > UART > from user space (currently there is always one /dev/tty per UART - unless the > UART is completely disabled). That bit is already covered and one or two devices support this because they have things like 3 seria

Re: [RFC PATCH 0/3] UART slave device bus

On Fri, 19 Aug 2016 19:42:37 +0200 "H. Nikolaus Schaller" wrote: > > Am 19.08.2016 um 13:06 schrieb One Thousand Gnomes > > : > > > >> If possible, please do a callback for every character that arrives. > >> And not only if the rx buffer become

Re: [RFC PATCH 0/3] UART slave device bus

> Plenty? Really?. Lets break down the tty drivers in the kernel which > don't use uart_port. That's the wrong list - those that use uart port but don't always use the uart_insert_char helpers will also break. So you can start by adding 8250 amba-pl011 atmel_serial bcm63xx_uart bfin_

Re: [RFC PATCH 0/3] UART slave device bus

> If possible, please do a callback for every character that arrives. > And not only if the rx buffer becomes full, to give the slave driver > a chance to trigger actions almost immediately after every character. > This probably runs in interrupt context and can happen often. We don't realisticall

Re: [RFC PATCH 0/3] UART slave device bus

> > 2. Only n_tty actually uses the tty_port layer buffering > > So the first point on 4K is not enough only applies to n_tty? If I > don't need the tty_port buffer logic, then how am I re-inventing it? There are two layers of buffering. 1. Some devices buffer bytes into an internal ring buffe

Re: [RFC PATCH 0/3] UART slave device bus

> I meant "Either some function similar to userspace's poll() is > needed, ...". Something like uart_dev_wait_for_rx() You can't really do that - it might never return and then how do you want to handle timeouts and cleanups > Alternatively the rx function could be a callback, that > is called wh

Re: Seeking recommendation on whether a bahviour is right/wrong

On Fri, 19 Aug 2016 10:56:37 +0530 Ajay Garg wrote: > Hi All. > > I have been trying to debug a strange issue occurring on a "mostly > mainline"-linux-kernel, running on a proprietary embedded-platform. Then you should talk to whoever provided you that kernel, and probably also read up on journ

Re: [Xen-devel] XSA 154 and ISA region (640K -> 1MB) WB cache instead of UC

On Thu, 18 Aug 2016 05:12:54 -0600 "Jan Beulich" wrote: > >>> On 18.08.16 at 12:16, wrote: > > On 18/08/16 11:06, Jan Beulich wrote: > > On 17.08.16 at 22:32, wrote: > >>>Looking at the kernel it assumes that WB is ok for 640KB->1MB. > >>>The comment says: > >>>" /* Low IS

Re: [RFC PATCH 0/3] UART slave device bus

On Thu, 18 Aug 2016 12:57:59 +0200 Greg Kroah-Hartman wrote: > On Thu, Aug 18, 2016 at 12:54:15PM +0200, H. Nikolaus Schaller wrote: > > Hi Pavel, > > > > > Am 18.08.2016 um 12:47 schrieb Pavel Machek : > > > > > > > > >> > > >> Thereof 4 files, ~260 changes w/o gps demo and documentation

Re: [RFC PATCH 0/3] UART slave device bus

On Wed, 17 Aug 2016 20:14:42 -0500 Rob Herring wrote: This was proposed ages ago and the point clearly made that a) the idea doesn't work because uarts are not required to use the uart layer and even those that do sometimes only use half of it b) that you should use the tty_port abstraction So

Re: Regression - SATA disks behind USB ones on v4.8-rc1, breaking boot. [Re: Who reordered my disks (probably v4.8-rc1 problem)]

On Sun, 14 Aug 2016 17:34:18 +0800 Tom Yan wrote: > Since when it is expected that SATA disks will always be probed before > USB disks? We can't guarantee that even if we make sure all ata > drivers are loaded before usb-storage/uas. That's why we need > consistent namings (e.g. /dev/disk/by-id/*

Re: [PATCH 0/2] drm: add SimpleDRM driver

> firmware framebuffer in early boot until a real driver takes over. It's a > replacement really for all the various uefi/vesa/whatever fbdev drivers. > Full reliance on the firmware very much intended. Most of those have firmware interfaces for things like colour setting and hardware scrolling. I

Re: [PATCH 0001/1285] Replace numeric parameter like 0444 with macro

On Tue, 2 Aug 2016 18:33:22 +0800 Baole Ni wrote: > I find that the developers often just specified the numeric value > when calling a macro which is defined with a parameter for access permission. > As we know, these numeric value for access permission have had the > corresponding macro, > and

Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

> It might make sense to filter non-shared edge triggered interrupts out > of irqpoll for that reason. Anything that supports a level triggered > interrupt should be fine. That would also break some platforms that use it today 8(. We'd need another irqpoll mode - at which point being able to forc

Re: [PATCH] usb:serial: Add Fintek F81532/534 driver

O > +static int f81534_set_normal_register(struct usb_device *dev, u16 reg, u8 > data) > +{ > + size_t count = F81534_USB_MAX_RETRY; > + int status; > + u8 *tmp; > + > + tmp = kmalloc(sizeof(u8), GFP_KERNEL); > + if (!tmp) > + return -ENOMEM; You end up doing huge

Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

> Serial consoles are already polled for output. So nothing should > care until userspace starts, and the full serial driver initializes. At which point it hangs > So I suspect either "irqfixup" or "irqpoll" would handle this for you. > If not I am certain a small tweak to some of that code woul

Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

> I wonder if it would just be simpler to make it be a CONFIG option > which causes the irq value to zero in arch/x86/include/asm/serial.h? That assumes x86 and legacy ports. For modern boxes its data from elsewhere Devicetree folks can just set up their devicetree that way, the ACPI afflicted ca

Re: [PATCH] 8250: option 'force_polling' for buggy IRQs

> I simply thought this patch may be useful for other people as well, that's > why I sent it upstream. If you set the IRQ to 0 it should poll anyway (0 means 'no IRQ') so I don't think the option is needed. At least it seems sufficient to get me by when I meet buggy PC BIOSes and the like Alan

Re: [PATCH v4 00/12] allow BFLT executables on systems with a MMU

On Fri, 22 Jul 2016 17:28:13 +1000 Greg Ungerer wrote: > On 22/07/16 00:48, Nicolas Pitre wrote: > > On Thu, 21 Jul 2016, Greg Ungerer wrote: > >> Hi Nicolas, > >> > >> On 21/07/16 05:22, Nicolas Pitre wrote: > >>> This series provides the necessary changes to allow "flat" executable > >>> bi

Re: [PATCH] ata: hpt366: fix incorrect mask when checking at cmd_high_time

On Tue, 12 Jul 2016 12:16:19 +0100 Colin King wrote: > From: Colin Ian King > > According to the HPT366 data sheet, PCI config space dword 0x40-0x43 > bits 11:8 specify the primary drive cmd_high_time, however, > currently just 3 bits of the 4 are being used because the mask > is 0x700 and not

Re: [PATCH] prctl: remove one-shot limitation for changing exe link

> >> 1) Attach to process via ptrace (protected by CAP_SYS_PTRACE) > >> 2) Unmap all the process file mappings, related to "exe" file. > >> 3) Change exe link (protected by CAP_SYS_RESOURCE). > >> > >> IOW, some other process already has an access to process internals (and > >> thus > >> it's alr

Re: [PATCH v2 10/10] binfmt_flat: allow compressed flat binary format to work on MMU systems

On Mon, 18 Jul 2016 11:45:53 -0400 (EDT) Nicolas Pitre wrote: > On Mon, 18 Jul 2016, One Thousand Gnomes wrote: > > > On Sun, 17 Jul 2016 23:31:56 -0400 > > Nicolas Pitre wrote: > > > > > Let's take the simple and obvious approach by decompressing the

Re: Kernel stability on baytrail machines

On Tue, 12 Jul 2016 16:41:58 -0300 Ezequiel Garcia wrote: > Hi Alan, > > (Adding interested people to this thread) > > On 09 Apr 08:14 PM, One Thousand Gnomes wrote: > > > > I do feel that the importance of the mentioned bug is currently > > > > underesti

Re: [PATCH v2 10/10] binfmt_flat: allow compressed flat binary format to work on MMU systems

On Sun, 17 Jul 2016 23:31:56 -0400 Nicolas Pitre wrote: > Let's take the simple and obvious approach by decompressing the binary > into a kernel buffer and then copying it to user space. Those who are > looking for more performance on a MMU system are unlikely to choose this > executable format

Re: strange Mac OSX RST behavior

> yes, we do in fact see a POLLRDHUP from the FIN in this case and > read of zero, but we still have more data to write to the socket, and > b/c the RST is dropped here, the socket stays in TIME_WAIT until > things eventually time out... After the FIN when you send/retransmit your next segment do

Re: strange Mac OSX RST behavior

> On Mac OSX 10.11.5 (latest version), we have found that when tcp > connections are abruptly terminated (via ^C), a FIN is sent followed > by an RST packet. The RST is sent with the same sequence number as the > FIN, and thus dropped since the stack only accepts RST packets matching > rcv_nxt (RFC

Re: Canonical has own Ubuntu driver for ALPS 73 03 28 devices

> The fix in the DKMS package you referenced was not written by > Canonical but by ALPS, as it came from them I think it is reasonable > they send it to upstream, isn't it? As you can see the patch is non-trivial. You published it on to milliosn of users, you'd think also mentioning its existence

Re: [PATCH 2/6] hid: intel_ish-hid: ISH Transport layer

On Mon, 20 Jun 2016 11:29:28 +0200 (CEST) Jiri Kosina wrote: > On Fri, 17 Jun 2016, Srinivas Pandruvada wrote: > > > > > +config INTEL_ISH_HID_TRANSPORT > > > > + bool > > > > + default n > > > > + > > > > +config INTEL_ISH_HID > > > > + bool "Intel Integrated Sensor Hub" > > > >

Re: [PATCH v2] Linux VM workaround for Knights Landing A/D leak

On Tue, 14 Jun 2016 10:24:16 -0700 Dave Hansen wrote: > On 06/14/2016 10:01 AM, Lukasz Anaczkowski wrote: > > v2 (Lukasz Anaczkowski): > > () fixed compilation breakage > ... > > By unconditionally defining the workaround code, even on kernels where > there is no chance of ever hitting thi

Re: [very-RFC 0/8] TSN driver for the kernel

On Mon, 13 Jun 2016 21:51:36 +0200 Richard Cochran wrote: > On Mon, Jun 13, 2016 at 01:47:13PM +0200, Richard Cochran wrote: > > 3. ALSA support for tunable AD/DA clocks. The rate of the Listener's > >DA clock must match that of the Talker and the other Listeners. > >Either you adjust it

VFS regression ? Re: disfunctional floppy driver in kernels 4.5, 4.6 and 4.7

On Sat, 11 Jun 2016 01:02:55 +0200 Wim Osterholt wrote: > L.S. > > up to vanilla kernel 4.4.13 floppy functionality performs like it should. > (On an x86 PC that is. With a 1.44MB diskette drive.) > >From kernel 4.5* and up it changed to barely usable. > > After a virgin start (cold or warm b

Re: [PATCH 5/5] intel_idle: Add S0ix validation

> How would this spuriously trigger during boot? This code is only run > during freeze. If there's some issue with not entering S0ix before a > module or firmware is loaded, it's better to not use suspend to idle > until those are in place. Ok yes you are correct it's not likely to trigger during

Re: Anyone have a clone of wireless-legacy.git?

On Thu, 2 Jun 2016 14:38:04 -0400 "John W. Linville" wrote: > It has recently come to my attention that the old wireless-legacy.git > tree is no longer available on kernel.org. I honestly have no idea > what happened to it -- for all I know I fat-fingered it some time > ago or whatever. Anyway,

Re: [PATCH 5/5] intel_idle: Add S0ix validation

On Thu, 2 Jun 2016 11:25:05 +0200 Peter Zijlstra wrote: > On Wed, Jun 01, 2016 at 09:33:29PM -0700, dbaseh...@chromium.org wrote: > > +/* > > + * Default chosen to have <= 1% power increase while allowing fast > > detection of > > + * SLP S0 entry errors. Waking up 10 times a second shows ~30% i

Re: [PATCH] mm: add config option to select the initial overcommit mode

> But wouldn't those affect a given process at at time? > Does that means that the OOM-killer is woken up to kill process X when those > situations arise on process Y? Not sure I understand the question. > Also, under what conditions would copy-on-write fail? When you have no memory or swap pag

Re: [PATCH] mm: add config option to select the initial overcommit mode

> My understanding is that there was a time when there was no overcommit at all. > If that's the case, understanding why overcommit was introduced would be > helpful. Linux always had overcommit. The origin of overcommit is virtual memory for the most part. In a classic swapping system without V

Re: [PATCH] mm: add config option to select the initial overcommit mode

> It seems important to point out that Sebastian's patch does NOT change > the default behavior. It merely creates a knob allowing one to override > the default via Kconfig. > > +choice > + prompt "Overcommit Mode" > + default OVERCOMMIT_GUESS > + depends on EXPERT Which is still comp

Re: [PATCH] mm: add config option to select the initial overcommit mode

> > Perhaps Sebastian's choice could be made to depend on CONFIG_EMBEDDED, > > rather than CONFIG_EXPERT? > > Even if the overcommit behavior is different on those systems the > primary question hasn't been answered yet. Why cannot this be done from > the userspace? In other words what wouldn't

Re: [PATCH] mm: add config option to select the initial overcommit mode

On Fri, 13 May 2016 15:34:52 +0200 Sebastian Frias wrote: > Hi Austin, > > On 05/13/2016 03:11 PM, Austin S. Hemmelgarn wrote: > > On 2016-05-13 08:39, Sebastian Frias wrote: > >> > >> My point is that it seems to be possible to deal with such conditions in a > >> more controlled way, ie: a w

  1   2   3   4   5   6   7   8   >