> If you want to actually lock down a machine to implement content
> protection, then you need secure boot without unlockable boot-loader and a
> pile more bits in userspace.
So let me take my Intel hat off for a moment.
The upstream policy has always been that we don't merge things which
don't
On Tue, 5 Dec 2017 18:01:46 +0800
Gary Lin wrote:
> The series of patches introduce Security Version to EFI stub.
>
> Security Version is a monotonically increasing number and designed to
> prevent the user from loading an insecure kernel accidentally. The
> bootloader maintains a list of secur
> > That's general misuse of /tmp. Things like "command > /tmp/file"
> > without having pre-created the file with O_EXCL e.g. by mktemp(1).
>
> I'm sorry, I've been using Unix for over 30 years.
> /tmp is a place that temporary files were created - nothing special.
> Traditionally it was emptie
On Tue, 28 Nov 2017 13:39:58 -0800
Kees Cook wrote:
> On Tue, Nov 28, 2017 at 1:16 PM, Luis R. Rodriguez wrote:
> > And *all* auto-loading uses aliases? What's the difference between
> > auto-loading
> > and direct-loading?
>
> The difference is the process privileges. Unprivilged autoloadin
> I have no idea who came up with that brilliant idea of parsing comments in
> the code. It's so simple to make this parser completely fail that it's not
Stephen Johnson (author of the V7 portable C compiler), which is where
it's from (the lint tool). He also wrote yacc so he does know a bit about
On Wed, 22 Nov 2017 09:01:46 +0100
Salvatore Mesoraca wrote:
> Disallows O_CREAT open missing the O_EXCL flag, in world or
> group writable directories, even if the file doesn't exist yet.
> With few exceptions (e.g. shared lock files based on flock())
Enough exceptions to make it a bad idea.
F
On Wed, 2017-11-22 at 00:31 -0500, Sinan Kaya wrote:
> pci_get_bus_and_slot() is restrictive such that it assumes domain=0
> as
> where a PCI device is present. This restricts the device drivers to
> be
> reused for other domain numbers.
The ISP v2 will always been in domain 0.
Alan
> I am aware that Edison could run with a modified 4.4 kernel, I just
> don't know where the firmware is. I don't see anything for Merrifield in
> /lib/firmware/intel?
https://downloadmirror.intel.com/25028/eng/edison-image-from-src-package-ww25.5-15.zip
I have no idea why it never made it in
On Mon, 20 Nov 2017 17:29:53 +0100
Romain Perier wrote:
> So even if the correspondong syscall are disabled and the
> corresponding clocks too, you should return an -ENOSYS from the
> do_adjtimex helper, in case that another component tries to use it in
> the kernel, right ?
Probably - but you n
On Mon, 20 Nov 2017 16:22:06 +0100
peter enderborg wrote:
> On 11/20/2017 04:00 PM, Romain Perier wrote:
> > Hi,
> >
> > 2017-11-20 15:10 GMT+01:00 peter enderborg :
> >> I think it should return a error code at least.
> > In which case ? The idea was to don't change the behaviour of these
>
> It's true but it's also true that a lot of these algorithm can be tuned
> at build time. We have various memory allocators, tiny RCU, the ability
> to disable SMP, we can even tune certain filesystems to use more or less
> buffers, etc. It's not that bad at all and I'm not sure that many other
>
On Sat, 18 Nov 2017 11:14:00 -0800
Linus Torvalds wrote:
> You may be confusing things because of a newer version.
>
> On Sat, Nov 18, 2017 at 11:03 AM, Charlemagne Lasse
> wrote:
> >
> > That should be "GNU Lesser General Public" and not "GNU Library General
> > Public"
>
> That's just FSF
On Fri, 17 Nov 2017 18:01:57 -0600
Pierre-Louis Bossart wrote:
> PCI/ACPI selections should not happen in Kconfig for machine drivers,
> move to SOC selections.
>
> Add distinction between PCI and ACPI HiFi2 platforms. The PCI-based
> platforms may be removed at some point since Medfield is not
> > i just wanted to throw some stones on the bloated kernel problem which is
> > increasing
>
> People used to be working on that, but then it seemed like the "size"
> got to a point that people were comfortable with it. Are you sure that
There's also a lot of pushback to things that add a to
On Mon, 13 Nov 2017 14:09:10 -0800
Linus Torvalds wrote:
> On Mon, Nov 13, 2017 at 1:44 PM, David Howells wrote:
> >
> > Whilst that may be true, we either have to check signatures on every bit of
> > firmware that the appropriate driver doesn't say is meant to be signed or
> > not
> > bother.
On Mon, 13 Nov 2017 18:42:50 +0100
"Luis R. Rodriguez" wrote:
> On Sat, Nov 11, 2017 at 02:32:40AM +0000, Alan Cox wrote:
> > > My assumption here is:
> > > 1) there are some less important and so security-insensitive firmwares,
> > >by which I mean
On Wed, 8 Nov 2017 16:43:17 -0800
Patrick McLean wrote:
> As of 4.13.11 (and also with 4.14-rc) we have an issue where when
> serving nfs4 sometimes we get the following BUG. When this bug happens,
> it usually also causes the motherboard to no longer POST until we
> externally re-flash the BIOS
> My assumption here is:
> 1) there are some less important and so security-insensitive firmwares,
>by which I mean that such firmwares won't be expected to be signed in
>terms of vulnerability or integrity.
>(I can't give you examples though.)
> 2) firmware's signature will be presente
> When a file does not have a license, again, all lawyers I have worked
> with said it is implicitly GPLv2
I am surprised that they did not immediately see the fact that since the
code contributor was not neccessarily the rights holder you could make no
assumption as to the actual licencing beyond
te_table[i] % baud.
0 means "hang up", so this looks good providing it leaves the device in a
sane state.
Reviewed-by: Alan Cox
On Wed, 8 Nov 2017 17:53:12 +0100
Denys Vlasenko wrote:
> On 11/08/2017 05:34 PM, Linus Torvalds wrote:
> > On Wed, Nov 8, 2017 at 8:14 AM, Denys Vlasenko wrote:
> >
> >>
> >> Can we avoid maintain emulation of these isns, by asking Wine to remove
> >> their use instead?
> >
> > If we ask
> By default all files without license information are under the default
> license of the kernel, which is GPL version 2.
Which is factually incorrect.
They are under a licence that is at least as permissive as GPL v2.
However they may be under a more permissive licence and as you are not
> Given that it had no license text on it at all, it "defaults" to GPLv2,
> so the GPLv2 SPDX identifier was added to it.
>
> No copyright was changed, nothing at all happened except we explicitly
> list the license of the file, instead of it being "implicit" before.
Well if Christoph owns the co
> > > And from what I know, there is nothing that is "non-copyrightable".
> >
> > You'd be wrong on that. Lots of things are not copyrightable.
>
> Ok, fair enough, but code is not one of those :)
You'd still be wrong.
Alan
> It's not just running at boot though. It's also being hit by the fuzzer at
> runtime, via ptmx_open().
Then modify the routine to try N_NULL as a follow up (see
tty_ldisc_restore). N_NULL will never fail.
Alan
On Tue, 7 Nov 2017 08:39:40 +0100
Greg Kroah-Hartman wrote:
> On Mon, Nov 06, 2017 at 11:20:40PM -0800, Christoph Hellwig wrote:
> > NAK, for both the libxfs patch and the kernel one.
>
> What libxfs patch? And what "kernel one" are you referring to here?
>
> > I wrote the file and it has no
On Fri, 3 Nov 2017 22:33:08 +0100
SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 3 Nov 2017 22:20:38 +0100
>
> Add a jump target so that a bit of exception handling can be better reused
> at the end of this function.
Why not look at what the C compiler generates before making the
On Thu, 2 Nov 2017 20:01:07 +0100
Paul Menzel wrote:
> Dear Greg,
>
>
> Am 02.11.2017 um 17:53 schrieb Greg KH:
> > On Thu, Nov 02, 2017 at 04:39:36PM +0100, Paul Menzel wrote:
>
> >> If I want to output the Linux kernel messages to the serial console, but
> >> the
> >> `console=ttyS…` line
On Thu, 2 Nov 2017 13:13:55 -0400
"Theodore Ts'o" wrote:
> On Thu, Nov 02, 2017 at 04:42:56PM +0100, Paul Menzel wrote:
> >
> > The Linux serial console documentation [1] says that 115200 is the maximum
> > supported baudrate.
> >
> > > The maximum baudrate is 115200.
> >
> > Is that still
> > serialized link. Writes get delayed, they can bunch together, busses do
> > posting and queueing.
>
> Are you talking about the actual delay operation, or the pokes around it?
All of it. A write from the CPU except on the lowest end ones isn't
neccessarily going to occur in strict sequentia
On Tue, 31 Oct 2017 17:15:34 +0100
> Therefore, users are accustomed to having delays be longer (within a
> reasonable margin).
> However, very few users would expect delays to be *shorter* than requested.
If your udelay can be under by 10% then just bump the number by 10%.
However at that level
On Tue, 31 Oct 2017 19:06:51 -0700
Tejun Heo wrote:
> Hello,
>
> tty hangup code doesn't mark the console as being HUPed for, e.g.,
> /dev/console and that can put the session leader trying to
> disassociate from the controlling terminal in an indefinite D sleep.
>
> Looking at the code, I have
> > +static int __init dell_uart_bl_init(void)
> > +{
> > + ftty = filp_open("/dev/ttyS0", O_RDWR | O_NOCTTY | O_NDELAY, 0);
>
You have no idea what name is assigned. This doesn't work.
This isn't the way to do it any more because the 'tty from kernel'
problem finally got fixed. You can att
> I can reproduce this problem on CentOS now. It seems better to leave this
> problem to drivers, not the user process.
> Do you think we should examine serial drivers of ARM, like pl011?
Can you reproduce it on real hardware - I ask because the driver has been
around for years without reports an
> Now, what I need in the kernel is to _selectively_ suspend devices
> that are not needed in the "backup/emergency" mode.
Which means you need to get the applications using them to die - or you
could rewrite the driver top to bottom to have locking sufficient to
ensure that your power management
> When tty_open() is opening a serial tty at the first time, after
> alloc_tty_struct() is called, before tty->ops->open() is finished.
That's kind of unavoidable.
> Serial driever like pl011 on ARM is ready to setup kworker threads
> to receive data with flush_to_ldisc(). Serial input at this ti
> I could not find anything standard that let me power gate single
> device from userland. Perhaps it's considered as a too risky operation
> to expose to the user. I don't want to touch drivers too much as well
> not to make them dependant on extra system feature. Better to have a
> separate modul
On Sat, 21 Oct 2017 17:31:10 +0200
Benoit Vaillant wrote:
> Hello,
>
> This is my first post here so please do point me to other places if
> this is not the mailing list to follow. I've tried IRC #debian and
> #linux which pointed to ask here. So here I am.
Welcome
> Although I've got a lot of
On Sat, 2017-10-21 at 10:34 +0100, Mark Brown wrote:
> On Thu, Oct 19, 2017 at 08:33:23AM +0530, Vinod Koul wrote:
>
> > + * BSD LICENSE
> > + *
> > + * Copyright(c) 2015-17 Intel Corporation.
> > + *
> > + * Redistribution and use in source and binary forms, with or
> > without
> > + * modifi
> > I quick grep on Dual license users looks like we already have this
> > in kernel
> > code. See drivers/ntb/hw/intel/ntb_hw_intel.c
>
> Just because someone did something wrong in the past, doesn't mean
> they
> should keep doing more wrong things in the future :)
What makes you think it's wro
> > > And why dual license something that will only ever work on Linux?
> >
> > We have non Linux users (mostly RTOS folks) which we would like to
> > support
> > with as much as common code.
>
> Note, you need to be VERY CAREFUL about doing this. You need to have
> all sorts of infrastructure s
On Fri, 20 Oct 2017 09:30:55 -0500
Brijesh Singh wrote:
> From: Tom Lendacky
>
> Secure Encrypted Virtualization (SEV) does not support string I/O, so
> unroll the string I/O operation into a loop operating on one element at
> a time.
Does this also mean that any firmware running in the virtua
On Thu, 19 Oct 2017 18:28:12 +0300
Pavel Nikulin wrote:
> Hold!
>
> Greg, are you trying to put a new addendum to the terms of GPL v2?
In many parts of the world if you make a promise about not enforcing a
right to take some action (sometimes even an implied one) you cannot then
take that actio
On Thu, 19 Oct 2017 15:52:04 +0100
David Howells wrote:
> From: Matthew Garrett
>
> Writing to MSRs should not be allowed if the kernel is locked down, since
> it could lead to execution of arbitrary code in kernel mode. Based on a
> patch by Kees Cook.
There are a load of standard tools that
> But all that matters is the tag is there for tools to be able to extract
> it properly. And if we have that, it doesn't matter what the comment
> "style" would be, so might as well make it look "nicer".
>
> And, to take it to the next conclusion, if we have the SPDX identifier,
> we can get rid
> And even the boring ones have pretty imprecise RTCs... For example Nokia N9.
> I only power it up from time to time, I believe it drifts something like
> minute per month... For normal use with SIM card, it can probably correct
> from GSM network if you happen to have a cell phone signal, but...
. So we'll
> deactivate all SuperIO before activate special base_port in
> fintek_8250_enter_key().
>
> Tested on iBASE MI802.
Good point.
Reviewd-by: Alan Cox
Alan
> This function is called only for the PIO mode commands, so I doubt this
> is
> necessary...
That is true but there are platforms out there that issue disk level PIO
commands via DMA (or can do so). Indeed the Cyrix MediaGX could do that
in the 1990s but I never add support 8)
So I think i
> I think I'd actually like to meld this with your other ideas and what I've
> currently got. What do you think of this approach:
>
> /* kernel community doesn't feel userspace should have access at all
> * or other kernel drivers use this
> */
> if (blacklisted)
>
On Fri, 13 Oct 2017 15:03:10 +
> Take off your "kernel" hat and put on a "customer" hat for a few moments
> while I try to put this in practical terms why the whitelist approach doesn't
> scale for what I'm trying to do.
As a customer I'm more worried about someone trashing my system or
breaki
> Within Linux the security model is that items accessible through this
> interface
> are only accessible by root.
"root" has not been a security concept in the Linux kernel since about
2.0. If you are relying on file permissions then at best you are using
CAP_SYS_DAC which is too weak for this.
> A maximum limit of 16 operations per cpu_opv syscall invocation is
> enforced, so user-space cannot generate a too long preempt-off critical
> section.
Except that all the operations could be going to mmapped I/O space and if
I pick the right targets could take quite a long time to complete. It
On Thu, 12 Oct 2017 10:14:00 -0400
Richard Guy Briggs wrote:
> Containers are a userspace concept. The kernel knows nothing of them.
>
> The Linux audit system needs a way to be able to track the container
> provenance of events and actions. Audit needs the kernel's help to do
> this.
>
> Sin
On Thu, 12 Oct 2017 13:35:17 +0200
Peter Rosin wrote:
> Hi!
>
> I have encountered an "interesting" bug. It silently corrupts data
> and is generally nasty...
>
> On an I2C bus, driven by the at91 driver and DMA (an Atmel
> sama5d31 chip), I have an 256 byte eeprom (NXP SE97BTP). I'm using
> Li
On Fri, 06 Oct 2017 13:25:55 +0100
David Woodhouse wrote:
> On Fri, 2017-10-06 at 14:13 +0200, Pavel Machek wrote:
> > > You can change 'C++' to 'C99' too, while you're at it :)
> >
> > No. They are C++ comments... as in... dangerous infection that came
> > from C++. Yes, C99 is infected, too,
On Wed, 11 Oct 2017 11:27:36 -0500
Mario Limonciello wrote:
> There are some categories of tokens and SMBIOS calls that it makes
> sense to protect userspace from accessing. These are calls that
> may write to one time use fields or activate hardware debugging
> capabilities. They are not inten
On Thu, 12 Oct 2017 01:30:07 -0300
Gabriel Krisman Bertazi wrote:
> On very rare occasions, immediately after a suspend, one of our
> SandyBridge CI boxes hits the exception below on CPU0 while trying to
> reconfigure the energy bias register. As far as I can tell, this is not
> likely a race in
On Tue, 10 Oct 2017 19:24:11 +
wrote:
> > -Original Message-
> > From: Pali Rohár [mailto:pali.ro...@gmail.com]
> > Sent: Tuesday, October 10, 2017 2:12 PM
> > To: Limonciello, Mario
> > Cc: dvh...@infradead.org; Andy Shevchenko ;
> > LKML ; platform-driver-...@vger.kernel.org;
> > A
> There are some "write once" items that for the general purpose user that
> won't brick a box, but should probably be blacklisted though.
> I'll think this through some more.
I would strongly urge you to do whitelisting as it's good security. If
you can divide the calls into something like this i
> Would it make sense to first get the other drivers to upstream and
> then see what's the status of atomisp?
Agreed
> the board specific information from firmware is conveyed to the
> sensor drivers will change to what the rest of the sensor drivers are
> using. I think a most straightforward w
On Wed, 4 Oct 2017 17:48:39 -0500
Mario Limonciello wrote:
> This userspace character device will be used to perform SMBIOS calls
> from any applications.
>
> It provides an ioctl that will allow passing the 32k WMI calling
> interface buffer between userspace and kernel space.
What is your se
> For malformed Unicode or such, it'd make sense, yeah.
Not really. It's legitimate to have bad unicode in a directory, or have a
file system where some users are still in 8bit Russian encoding and some
are unicode for example.
The fix for this has always been the same - don't use shell script an
> I think this patch should be reverted. If somebody is vmallocing crazy
> amounts of memory in the exit path we should probably track them down
> individually; the patch doesn't reference any real instances of that.
> But we cannot start failing allocations that have never failed before.
>
> That
On Mon, 25 Sep 2017 15:01:13 +0200
Ulf Samuelsson wrote:
> Trying to open /dev/ttyUSB from a kernel driver (which works), but
> locking the
> serial port so noone else can access it does not work.
> Any advice would be appreciated.
File locks are advisory only.
For the rest of it you might wan
> Ok, I'll bite. How do you set a signal handler under this regime, since
> that needs to pass a function pointer to the syscall? Have a different
> function pointer type for when you want a real pointer instead of an
> offset pointer? Perhaps label them "near" and "far" pointers, since
> there's p
On Mon, 11 Sep 2017 20:49:27 +0200
Vincent Hervieux wrote:
> Currently atomisp module supports Intel's Baytrail SoC and contains
> some compilation switches to support Intel's Cherrytrail SoC instead.
> The patchset aims to :
> - 1/2: activate ATOMISP2400 or ATOMISP2401 from the menu.
> - 2/2: fi
> It's not the performance cost, it's rewriting all the pointers.
Which you don't need to do
> Without address translation, copying the existing mappings to a new
> range requires finding and adjusting every pointer to the old data,
No it doesn't. See Minix.
When you fork() rather than vfork yo
> > anymore. But I'm already _running_ this program. If I could fork() I
> > could already get a second copy of the sucker and call main() again
> > myself if necessary, but I can't, so...
You can - ptrace 8)
> > honoring the suid bit if people feel that way. I just wanna unblock
> > vfork() whil
On Thu, 17 Aug 2017 14:39:46 -0700
"Luck, Tony" wrote:
> From: Tony Luck
>
> The ACPI sysfs interface provides a way to read each ACPI table from
> userspace via entries in /sys/firmware/acpi/tables/
>
> The BERT table simply provides the size and address of the error
> record in BIOS reserved
> It seems that part of the problem is the lack of tty_port_put/tty_port_get
> calls in the VT code.
Yes
> > The only easy way I can think to keep the current semantics would instead
> > be to keep the tty port resources around and indexed somewhere but
> > blackhole input to/output from that po
> non-pointer value 0x0028fecaedff. The tty_port belongs to
> a vc_data structure, which gets freed after we find that
> console_driver->ttys[i]->count is zero in the VT_DISALLOCATE
> ioctl. Apparently at the same time, the agetty process owning
That wouldn't actually be a safe check. tty->cou
On Mon, 2017-08-07 at 21:44 +0800, Geliang Tang wrote:
> Use kvmalloc()/kvzalloc() instead of atomisp_kernel_malloc()
> /atomisp_kernel_zalloc().
>
> Signed-off-by: Geliang Tang
Definitely better now we have kvmalloc/kvzalloc.
Thanks
Alan
On Mon, 31 Jul 2017 14:09:43 -0500
David Lechner wrote:
> This is v2 of "fbcon: Use background color for margins"[1].
>
> It turns out that using the text background color was not a good choice. So,
> I've started over.
Can you explain why making the margins simply match the border colour
(whe
On Wed, 26 Jul 2017 06:54:01 +0900
Satoru Takeuchi wrote:
> # I'm a LKML subscriber, but not a x86 list subscriber
>
> I found the following new linux kernel bugzilla about Ryzen related problem.
> Since many developers don't check this bugzilla and I've also
> encountered this problem,
> I deci
also fixed.
> And the next step is the most complicated one handle .nr in uart_driver
> structure in more generic way.
>
> Thanks,
> Michal
Sorry for the delay been on jury service
Series
Reviewed-by: Alan Cox
> The patch is untested but I can work on this if that fits in with the
> plans for tty.
I think this is the right direction.
Alan
> Sure. I can fix the tty->count mismatch based on Alan's suggestion. However I
> don't understand why the exclusivity flag should belong to tty_port and not
> tty_struct. It will be good to know why.
We are trying to move all the flags that we can and structs into the
tty_port, except any tha
> (a) minimal: just use our existing default stack (and stack _only_)
> limit value for suid binaries that actually get extra permissions: {
> _STK_LIM, RLIM_INFINITY }.
Even that is dangerous because a setuid binary can be transitioning
between two users (none privileged) yet be subject to an rl
> spk_ttyio_initialise_ldisc is called separately for each module (e.g.
> speakup_apollo, speakup_ltlk etc) when it is loaded. spk_ttyio_release
> is also called separately for each module when it is unloaded. The ldisc
> stays around until the last of the modules is unloaded.
What guarantees that
> When opening from kernel, we don't use file pointer. The count mismatch
> is between tty->count and #fd's. So opening from kernel leads to #fd's
> being less than tty->count. I thought this difference is relevant to
> user-space opening of tty, and not to kernel opening of tty. Can you
> suggest
On Fri, 7 Jul 2017 20:13:01 +0100
Okash Khawaja wrote:
> Speakup opens tty using tty_open_by_driver. When closing, it calls
> tty_ldisc_release but doesn't close and remove the tty itself. As a
> result, that tty cannot then be opened from user space. This patch calls
> tty_release_struct which e
On Sun, 09 Jul 2017 12:41:53 +0100
Okash Khawaja wrote:
> On Sat, Jul 08, 2017 at 10:38:03AM +0200, Greg Kroah-Hartman wrote:
> > Overall, the idea looks sane to me. Keeping userspace from opening a
> > tty that the kernel has opened internally makes sense, hopefully
> > userspace doesn't get to
On Fri, 2017-07-07 at 17:20 +0530, Hari Prasath wrote:
> kmemdup can be used to replace kmalloc followed by a memcpy.This was
> pointed out by the coccinelle tool.
And kstrdup could do the job even better I think ?
Alan
}
>
> -static struct acpi_device_id gc0310_acpi_match[] = {
> +static const struct acpi_device_id gc0310_acpi_match[] = {
> {"XXGC0310"},
> {},
> };
(All four)
Acked-by: Alan Cox
> I was thinking about something that looks like serdev from consumer
> side, but instead directly works on struct uart_port, w/o actually
> allocating a tty (and also the funny things like signals, etc).
uart_port is only a subset of tty devices and also relies upon tty for
some of the locking an
> So where can I get a handle on the people inside Intel who are obviously
> using ACPI GPIO class for shoehorning what we in the linux kernel call
> syscon or register bit misc access into the GPIO ACPI container just
> because they feel it is convenient?
It's a Windowsism and since Windows is th
; a console and set it
up separately to actually 'enabling' it when you make it visible and
start scribbling. I don't see any other way to make the changeover
locking saner at this point without still having huge potential stalls in
printk().
Reviewed-by: Alan Cox
Alan
On Mon, 2017-06-26 at 13:22 -0700, Bjorn Andersson wrote:
> On Fri, Jun 23, 2017 at 9:03 AM, Greg Kroah-Hartman
> wrote:
> >
> > As Luis pointed out, there are no in-kernel users of
> > request_firmware_into_buf(), so remove it, and the now unused
> > internal
> > flag, which simplifies the logic
On Mon, 26 Jun 2017 00:43:12 +0200
"Enrico Weigelt, metux IT consult" wrote:
> Hi folks,
>
>
> is there already a way for accessing serial ports from drivers,
> w/o having to go through the TTY subsystem ?
>
> Serdev seems provide a connection between arbitrary TTYs to device
> drivers. But th
On Thu, 22 Jun 2017 14:24:58 -0600
Logan Gunthorpe wrote:
> On 6/22/2017 2:14 PM, Alan Cox wrote:
> > If a platform doesn't support 64bit I/O operations from the CPU then you
> > either need to use some kind of platform/architecture specific interface
> > if present or
On Thu, 22 Jun 2017 10:48:13 -0600
Logan Gunthorpe wrote:
> Currently, ioread64 and iowrite64 are only available io CONFIG_64BIT=y
> and CONFIG_GENERIC_IOMAP=n. Thus, seeing the functions are not
> universally available, it makes them unusable for driver developers.
> This leads to ugly hacks suc
On Thu, 22 Jun 2017 10:48:14 -0600
Logan Gunthorpe wrote:
> Alpha implements its own io operation and doesn't use the
> common library. Thus to make ioread64 and iowrite64 globally
> available we need to add implementations for alpha.
>
> For this, we simply use calls that chain two 32-bit opera
> > diff --git a/arch/x86/include/asm/uaccess_64.h
> > b/arch/x86/include/asm/uaccess_64.h
> > index c5504b9..16a8871 100644
> > --- a/arch/x86/include/asm/uaccess_64.h
> > +++ b/arch/x86/include/asm/uaccess_64.h
> > @@ -28,6 +28,9 @@ copy_user_generic(void *to, const void *from, unsigned
> > len
On Sun, 18 Jun 2017 22:06:59 +0100
Sudip Mukherjee wrote:
> On Sun, Jun 18, 2017 at 09:37:48PM +0300, Alexander Gerasiov wrote:
> > Hello Andy,
> >
> > While preparing the update I suddenly found, that parport_serial.c is
> > not the right place for this card. Since there is no serial ports on
>
On Mon, 19 Jun 2017 12:11:34 +0200
David van Leeuwen wrote:
> Hello,
>
> I have a system with two NVidia gtx 1080 graphics cards for deep
> neural net training. Every once in a while (1x per hour--day) the
> load of the system goes up from 4 to 258 in a matter of minutes,
> without CPU utilizat
On Mon, 12 Jun 2017 10:27:24 -0400
Mimi Zohar wrote:
> On Sun, 2017-06-11 at 22:32 -0400, Mimi Zohar wrote:
> > On Sun, 2017-06-11 at 13:44 +0200, Mickaël Salaün wrote:
>
> > > Using filesystem xattr seems like a good idea for this kind of
> > > exceptions and instead of a hardcoded interpret
> That would cut it, but TIOCPKT is too coupled with having a linked tty.
> I could make acm behave like a pty (accept TIOCPKT and issue the
> ctrl_status bits), but for that I need n_tty to know that packet does
> not always mean a linked tty is present, and that in case it isn't we
> take our own
> | A trusted path is one that is inside is a root owned directory that
> | is not group or world writable. /bin, /usr/bin, /usr/local/bin, are
> | (under normal circumstances) considered trusted. Any non-root
> | users home directory is not trusted, nor is /tmp.
You need the entire path to be r
On Tue, 13 Jun 2017 09:52:07 +0300
Tal Shorer wrote:
> If a tty driver wants to notify the user of some exceptional event,
> such as a usb cdc acm device set_line_coding event, it needs a way to
> modify the mask returned by poll() and possible also add wait queues.
> In order to do that, we allo
On Mon, 12 Jun 2017 20:26:13 +0300
Tal Shorer wrote:
> The user can issue USB_F_GET_LINE_CODING to get the current line coding
> as set by the host (or the default if unset yet).
No this is not how to do it. We don't want weirdass ioctls for each
different tty device type.
There are two ways th
201 - 300 of 5738 matches
Mail list logo
