On Tue, 24 Jul 2018 17:51:33 -0700
r...@google.com wrote:
> From: Roman Kiryanov
>
> The driver never mutates this variable - no benefits of
> keeping it mutable.
>
> Signed-off-by: Roman Kiryanov
> ---
> Changes in v2:
> - Replaced "const u32" with "#define".
v1 was IMHO definitely better.
> >> If we determined tsc early in boot using one of the quick methods:
> >> from cpuid/msr/quick_pit, can we assume that frequencies of all other
> >> CPUs will be determined the same way? Or do we still have to fallback
Not on 32bit at least. You can have a mixed slot 1 SMP system such as
an
> >> If we determined tsc early in boot using one of the quick methods:
> >> from cpuid/msr/quick_pit, can we assume that frequencies of all other
> >> CPUs will be determined the same way? Or do we still have to fallback
Not on 32bit at least. You can have a mixed slot 1 SMP system such as
an
> >
> > > + if (!port->iso7816_config)
> > > + return -ENOIOCTLCMD;
> >
> > Why this error value?
> >
>
> It was a mimic of RS485.
Which is what you want - it means the upper tty layer knows to offer the
ioctl to other places and then return appropriately.
Alan
> >
> > > + if (!port->iso7816_config)
> > > + return -ENOIOCTLCMD;
> >
> > Why this error value?
> >
>
> It was a mimic of RS485.
Which is what you want - it means the upper tty layer knows to offer the
ioctl to other places and then return appropriately.
Alan
On Wed, 18 Jul 2018 05:01:52 +0200
Adam Borowski wrote:
> Hi!
> Here's a patchset with two entangled improvements:
>
> * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
> allows disabling it, rendering such characters with a bright background
> instead.
That's a
On Wed, 18 Jul 2018 05:01:52 +0200
Adam Borowski wrote:
> Hi!
> Here's a patchset with two entangled improvements:
>
> * it'd be good to get rid of blinking where possible. Even CGA (thus VGA)
> allows disabling it, rendering such characters with a bright background
> instead.
That's a
no_speculation table added by commit
> > > fec9434a12f3
> > > to arch/x86/kernel/cpu/common.c. Is this intentional? Would a
> > > patch
> > > adding it and possibly other omissions be welcome?
> >
> > Probably. Dave?
>
> IIRC, Alan Cox was
no_speculation table added by commit
> > > fec9434a12f3
> > > to arch/x86/kernel/cpu/common.c. Is this intentional? Would a
> > > patch
> > > adding it and possibly other omissions be welcome?
> >
> > Probably. Dave?
>
> IIRC, Alan Cox was
> Oops, I was just doing some testing and thought that correct behavior
> for crafted FS is to return arbitrary valid error code (like -EIO) or
> some arbitrary data, say, not larger than FS (not disclosing the
> kernel memory, of course). Please excuse me if I was wrong. If fixing
> this would
> Oops, I was just doing some testing and thought that correct behavior
> for crafted FS is to return arbitrary valid error code (like -EIO) or
> some arbitrary data, say, not larger than FS (not disclosing the
> kernel memory, of course). Please excuse me if I was wrong. If fixing
> this would
> Ugh, I thought glibc got support for it, I guess everyone just
> hand-codes it in their applications for now. Sad.
The glibc people actively contributed to its design and then went radio
silent on the subject.
Alan
> Ugh, I thought glibc got support for it, I guess everyone just
> hand-codes it in their applications for now. Sad.
The glibc people actively contributed to its design and then went radio
silent on the subject.
Alan
> The Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel
> framework is a generic, flexible system that supports thin kernel
> drivers. Gasket kernel drivers are expected to handle opening and
> closing devices, mmap'ing BAR space as requested, a small selection of
> ioctls, and
> The Gasket (Google ASIC Software, Kernel Extensions, and Tools) kernel
> framework is a generic, flexible system that supports thin kernel
> drivers. Gasket kernel drivers are expected to handle opening and
> closing devices, mmap'ing BAR space as requested, a small selection of
> ioctls, and
On Tue, 26 Jun 2018 11:05:21 +0200
Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 04:11:07PM +0100, Alan Cox wrote:
> > On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote:
> > > On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote:
> > > > Fir
On Tue, 26 Jun 2018 11:05:21 +0200
Peter Zijlstra wrote:
> On Fri, Jun 22, 2018 at 04:11:07PM +0100, Alan Cox wrote:
> > On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote:
> > > On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote:
> > > > Fir
On Fri, 22 Jun 2018 12:28:17 -0400 (EDT)
Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Alan Cox wrote:
>
> > > The other point is a quite pointless assumption that existing scrollback
> > > is
> > > "optimized". Even vgacon mostly uses software scroll
On Fri, 22 Jun 2018 12:28:17 -0400 (EDT)
Nicolas Pitre wrote:
> On Fri, 22 Jun 2018, Alan Cox wrote:
>
> > > The other point is a quite pointless assumption that existing scrollback
> > > is
> > > "optimized". Even vgacon mostly uses software scroll
On Wed, 20 Jun 2018 11:44:13 +0900
Linus Torvalds wrote:
> On Wed, Jun 20, 2018 at 11:34 AM Steven Rostedt wrote:
> >
> > Perhaps we should do an audit of the console drivers and remove all
> > printk, pr_* , WARN*, BUG* from them.
>
> Only the actual _printing_ parts.
No because they are
On Wed, 20 Jun 2018 11:44:13 +0900
Linus Torvalds wrote:
> On Wed, Jun 20, 2018 at 11:34 AM Steven Rostedt wrote:
> >
> > Perhaps we should do an audit of the console drivers and remove all
> > printk, pr_* , WARN*, BUG* from them.
>
> Only the actual _printing_ parts.
No because they are
> The other point is a quite pointless assumption that existing scrollback is
> "optimized". Even vgacon mostly uses software scrollback these days, as the
> amount of VGA display memory is really small.
All of our console driver code is horribly unoptimized for most of
todays hardware. Long ago
> The other point is a quite pointless assumption that existing scrollback is
> "optimized". Even vgacon mostly uses software scrollback these days, as the
> amount of VGA display memory is really small.
All of our console driver code is horribly unoptimized for most of
todays hardware. Long ago
On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote:
> On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote:
> > Firmware may contain split locked instructions.
>
> I think that's the wrong attitude. You should mandate in your BIOS
> development guide that Firmware _MUST_NOT_ contain
On Thu, 2018-06-21 at 21:58 +0200, Peter Zijlstra wrote:
> On Sun, May 27, 2018 at 08:45:55AM -0700, Fenghua Yu wrote:
> > Firmware may contain split locked instructions.
>
> I think that's the wrong attitude. You should mandate in your BIOS
> development guide that Firmware _MUST_NOT_ contain
> But forward bisection (when bug is fixed) unfortunately won't work
> because these commits are not connected to HEAD. And forward bisection
> is very important, otherwise who will bring order to all these
> hundreds of open bugs?
> https://syzkaller.appspot.com/
Bisection isn't so important
> But forward bisection (when bug is fixed) unfortunately won't work
> because these commits are not connected to HEAD. And forward bisection
> is very important, otherwise who will bring order to all these
> hundreds of open bugs?
> https://syzkaller.appspot.com/
Bisection isn't so important
> It doesn't come as a surprise that recursive printk() calls are not the
> only way for us to deadlock in printk() and we still have a whole bunch
> of other printk() deadlock scenarios. For instance, those that involve
> TTY port->lock spin_lock and UART port->lock spin_lock.
The tty layer code
> It doesn't come as a surprise that recursive printk() calls are not the
> only way for us to deadlock in printk() and we still have a whole bunch
> of other printk() deadlock scenarios. For instance, those that involve
> TTY port->lock spin_lock and UART port->lock spin_lock.
The tty layer code
> + } else {
> + while ((lsr & BOTH_EMPTY) != BOTH_EMPTY) {
> + lsr = serial_in(p, UART_LSR);
> + cpu_relax();
> + }
> + }
This still needs a timeout in case some kind of
> + } else {
> + while ((lsr & BOTH_EMPTY) != BOTH_EMPTY) {
> + lsr = serial_in(p, UART_LSR);
> + cpu_relax();
> + }
> + }
This still needs a timeout in case some kind of
> A malicious program most probably won't care about that. Therefore, my
> next question is: which memory regions can be exploited by a malicious
> program? The complete physical memory or only the memory provided to the
> malicious program? Should be the latter if this approach should have any
>
> A malicious program most probably won't care about that. Therefore, my
> next question is: which memory regions can be exploited by a malicious
> program? The complete physical memory or only the memory provided to the
> malicious program? Should be the latter if this approach should have any
>
> Could you describe the performance degradation? Why is this not a
> "doctor it hurts when I do that" situation?
They already know it hurts - the question is why and where.
Alan
> Could you describe the performance degradation? Why is this not a
> "doctor it hurts when I do that" situation?
They already know it hurts - the question is why and where.
Alan
On Thu, 3 May 2018 18:27:14 + (UTC)
Grant Edwards wrote:
> On 2018-05-03, Muni Sekhar wrote:
>
> > If I need to set a custom baud rates(e.g. 14400, 128000, 256000), does
> > Linux serial framework has any supporting method?
>
> Sure,
On Thu, 3 May 2018 18:27:14 + (UTC)
Grant Edwards wrote:
> On 2018-05-03, Muni Sekhar wrote:
>
> > If I need to set a custom baud rates(e.g. 14400, 128000, 256000), does
> > Linux serial framework has any supporting method?
>
> Sure, use the termios2 structure instead of the termios
On Fri, 2018-05-11 at 17:09 +0200, Julia Lawall wrote:
>
> On Fri, 11 May 2018, Christophe JAILLET wrote:
>
> > The use of 'fail1' and 'fail2' is not correct. Reorder these calls
> > to
> > branch at the right place of the error handling path.
>
> Maybe it would be good to improve the names at
On Fri, 2018-05-11 at 17:09 +0200, Julia Lawall wrote:
>
> On Fri, 11 May 2018, Christophe JAILLET wrote:
>
> > The use of 'fail1' and 'fail2' is not correct. Reorder these calls
> > to
> > branch at the right place of the error handling path.
>
> Maybe it would be good to improve the names at
> > I think memory allocation and io waits can't be decoupled from
> > scheduling as they are now.
>
> The scheduler is not decoupled from either, it is intimately involved
> in both. However, none of the decision making smarts for either reside
> in the scheduler, nor should they.
It belongs
> > I think memory allocation and io waits can't be decoupled from
> > scheduling as they are now.
>
> The scheduler is not decoupled from either, it is intimately involved
> in both. However, none of the decision making smarts for either reside
> in the scheduler, nor should they.
It belongs
> 2) Compiler transformations can elide binary operations, so we cannot
>rely on source level AND (&) or MOD (%) operations to narrow the
>range of an expression, regardless of the types of either operand.
>
>This means that source-level AND and MOD operations cannot be relied
>
> 2) Compiler transformations can elide binary operations, so we cannot
>rely on source level AND (&) or MOD (%) operations to narrow the
>range of an expression, regardless of the types of either operand.
>
>This means that source-level AND and MOD operations cannot be relied
>
On Wed, 25 Apr 2018 22:20:50 +0900
DaeRyong Jeong wrote:
> tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
> by th->used and updates tb->used.
> But tty_insert_flip_string_fixed_flag() can be executed concurrently and
> tb->used can be updated
On Wed, 25 Apr 2018 22:20:50 +0900
DaeRyong Jeong wrote:
> tty_insert_flip_string_fixed_flag() copies chars to the buffer indicated
> by th->used and updates tb->used.
> But tty_insert_flip_string_fixed_flag() can be executed concurrently and
> tb->used can be updated improperly.
The tty input
> The current kernel driver code looks up the physical address of a page of
> user-allocated memory by traversing the page table, and then writing the
> physical address to the external MMU. If we were to move the driver to
> userspace, this procedure would require exposing the physical address to
> The current kernel driver code looks up the physical address of a page of
> user-allocated memory by traversing the page table, and then writing the
> physical address to the external MMU. If we were to move the driver to
> userspace, this procedure would require exposing the physical address to
> But we don't have the full ACPI interpreter up in the early part of
> the kernel. All these 'early' devices have their own setup/config
> which is the source of the issue. Or maybe I am wrong about the full
> interpreter and the early drivers are just not taking advantage of the
> ACPI device
> But we don't have the full ACPI interpreter up in the early part of
> the kernel. All these 'early' devices have their own setup/config
> which is the source of the issue. Or maybe I am wrong about the full
> interpreter and the early drivers are just not taking advantage of the
> ACPI device
> The primary factor affecting UART throughput is the baud rate, apart
> from this any other factors affect the UART throughput?
UART
CPU power
interrupt latency
all the usual suspects.
> > For 400 bps uart baud rate, what should be the theoretical peak
> data throughput?
>
Depends
> The primary factor affecting UART throughput is the baud rate, apart
> from this any other factors affect the UART throughput?
UART
CPU power
interrupt latency
all the usual suspects.
> > For 400 bps uart baud rate, what should be the theoretical peak
> data throughput?
>
Depends
> so an error on the 1st page gets propagated to the caller,
> and that get_user_pages_unlocked eventually calls __get_user_pages
> so it does return an error sometimes.
>
> Would it be correct to apply the second part of the patch then
> (pasted below for reference) or should get_user_pages_fast
> so an error on the 1st page gets propagated to the caller,
> and that get_user_pages_unlocked eventually calls __get_user_pages
> so it does return an error sometimes.
>
> Would it be correct to apply the second part of the patch then
> (pasted below for reference) or should get_user_pages_fast
> How? When there are random DMA-capable PCI devices that are driven by
> userland tools that are mmap()ing the BARs out of sysfs, how do we
> simultaneously avoid breaking those devices while also preventing the
> majority of users from being vulnerable to an attacker just DMAing over the
>
> How? When there are random DMA-capable PCI devices that are driven by
> userland tools that are mmap()ing the BARs out of sysfs, how do we
> simultaneously avoid breaking those devices while also preventing the
> majority of users from being vulnerable to an attacker just DMAing over the
>
> Furthermore, there is a fundamental deviation from common security
> sense here, where things like command line parameters and other
> lockdown specific tunables are blacklisted rather than whitelisted,
I've been complaining about this from the start but it appears to be a
write only authorship
> Furthermore, there is a fundamental deviation from common security
> sense here, where things like command line parameters and other
> lockdown specific tunables are blacklisted rather than whitelisted,
I've been complaining about this from the start but it appears to be a
write only authorship
On Wed, 04 Apr 2018 00:12:04 +
Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds
>
> wrote:
> > Still better than telling them to disable/enable secure boot, which
> > they may or may not even be able to to.
>
> Users
On Wed, 04 Apr 2018 00:12:04 +
Matthew Garrett wrote:
> On Tue, Apr 3, 2018 at 5:08 PM Linus Torvalds
>
> wrote:
> > Still better than telling them to disable/enable secure boot, which
> > they may or may not even be able to to.
>
> Users who can boot a non-vendor Linux distribution on
> But more importantly, it takes roughly half a second to set up the
> device. I understand, that the probing is part of AHCI(?), and in this
> case the Crucial m4 SSD drive/firmware is especially slow. So, I assume
> it will be hard to improve anything in the code to decrease the time.
> But more importantly, it takes roughly half a second to set up the
> device. I understand, that the probing is part of AHCI(?), and in this
> case the Crucial m4 SSD drive/firmware is especially slow. So, I assume
> it will be hard to improve anything in the code to decrease the time.
<penguin-ker...@i-love.sakura.ne.jp>
> Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
> Cc: Jiri Slaby <jsl...@suse.com>
> Cc: Dmitry Vyukov <dvyu...@google.com>
> Cc: Johannes Weiner <han...@cmpxchg.org>
> Cc: Alan Cox <alan@llwyncelyn.cymru>
> Cc: Christoph Hellwig <h...@lst.de>
> Cc: Michal Hocko <mho...@suse.com>
Seems reasonable to me
Alan
; Cc: Greg Kroah-Hartman
> Cc: Jiri Slaby
> Cc: Dmitry Vyukov
> Cc: Johannes Weiner
> Cc: Alan Cox
> Cc: Christoph Hellwig
> Cc: Michal Hocko
Seems reasonable to me
Alan
On Tue, 27 Mar 2018 12:05:23 -0400
Mathieu Desnoyers wrote:
> Expose a new system call allowing each thread to register one userspace
> memory area to be used as an ABI between kernel and user-space for two
> purposes: user-space restartable sequences and quick
On Tue, 27 Mar 2018 12:05:23 -0400
Mathieu Desnoyers wrote:
> Expose a new system call allowing each thread to register one userspace
> memory area to be used as an ABI between kernel and user-space for two
> purposes: user-space restartable sequences and quick access to read the
> current CPU
On Mon, 26 Mar 2018 20:56:45 -0600
Aaron Durbin <adur...@chromium.org> wrote:
> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote:
> >> Sadly, this situation
> >> is not unique to this hardware. There is hardware all over that does
>
On Mon, 26 Mar 2018 20:56:45 -0600
Aaron Durbin wrote:
> On Mon, Mar 26, 2018 at 12:24 PM, Alan Cox wrote:
> >> Sadly, this situation
> >> is not unique to this hardware. There is hardware all over that does
> >> not meet the current assumptions being made in the
> I suspect a large part of the problem is that our device isn't really
> a PCIe device. It's a PCI device retrofitted with a TI
> XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge. Large numbers of this
That really shouldn't be an issue. Just about every PC up to a few years
ago has something that
> I suspect a large part of the problem is that our device isn't really
> a PCIe device. It's a PCI device retrofitted with a TI
> XIO2000(A)/XIO2200A PCI Express-to-PCI Bridge. Large numbers of this
That really shouldn't be an issue. Just about every PC up to a few years
ago has something that
> Sadly, this situation
> is not unique to this hardware. There is hardware all over that does
> not meet the current assumptions being made in the early uart drivers
> within the kernel.
Is there any fundamental reason you can't just embed dt entries in the
ACPI table to describe the other
> Sadly, this situation
> is not unique to this hardware. There is hardware all over that does
> not meet the current assumptions being made in the early uart drivers
> within the kernel.
Is there any fundamental reason you can't just embed dt entries in the
ACPI table to describe the other
> Can we probe safely for this device?
99% of the time yes the inb gives us a straight answer. However (and
we've hit this with port 0x81 for real) there are concerns that some
systems will trap those addresses into SMM and do weirdness that makes
the 0xFF check fail.
Alan
> Can we probe safely for this device?
99% of the time yes the inb gives us a straight answer. However (and
we've hit this with port 0x81 for real) there are concerns that some
systems will trap those addresses into SMM and do weirdness that makes
the 0xFF check fail.
Alan
> Please explain WHY 2017 is the cut-off date. I still have no clue how
> that
> is decided aside of being a random number.
Because if it's prior to 2017 then it'll almost certainly have those
registers even if the firmware says otherwise. After that point we
think the firmware is going to give
> Please explain WHY 2017 is the cut-off date. I still have no clue how
> that
> is decided aside of being a random number.
Because if it's prior to 2017 then it'll almost certainly have those
registers even if the firmware says otherwise. After that point we
think the firmware is going to give
On Wed, 07 Mar 2018 13:46:24 -0800
Dave Hansen wrote:
> From: Dave Hansen
>
> I think we need to soften the language a bit. It might scare folks
> off, especially the:
>
>We prefer to fully disclose the bug as soon as
On Wed, 07 Mar 2018 13:46:24 -0800
Dave Hansen wrote:
> From: Dave Hansen
>
> I think we need to soften the language a bit. It might scare folks
> off, especially the:
>
>We prefer to fully disclose the bug as soon as possible.
>
> which is not really the case. Linus says:
>
>
> FWIW, alpha and m68k are known boot with qemu (even though m68k
> generates a warning traceback with the mainline kernel).
M68K works - people actively use it. Crazy people true 8). Alpha I
believe one or two people boot. I just need to track down some discs for
my Alpha 8)
Alan
> FWIW, alpha and m68k are known boot with qemu (even though m68k
> generates a warning traceback with the mainline kernel).
M68K works - people actively use it. Crazy people true 8). Alpha I
believe one or two people boot. I just need to track down some discs for
my Alpha 8)
Alan
On Wed, 21 Feb 2018 09:03:00 +
> The thing I like about rate limiting (for everyone including root) is
> that it does not break anybody's workflow (unless EFI variable access
> occurs on a hot path, in which case you're either a) asking for it, or
> b) the guy trying to DoS us), and that it
On Wed, 21 Feb 2018 09:03:00 +
> The thing I like about rate limiting (for everyone including root) is
> that it does not break anybody's workflow (unless EFI variable access
> occurs on a hot path, in which case you're either a) asking for it, or
> b) the guy trying to DoS us), and that it
> Regarding the older architectures I mentioned (m32r, frv, mn10300),
> the situation is a bit different as they don't have the problems with
> build testing but they do have problems with using less of the
> standard interfaces (syscall, timer, gpio, rtc, ...), so they do add
> more to the
> Regarding the older architectures I mentioned (m32r, frv, mn10300),
> the situation is a bit different as they don't have the problems with
> build testing but they do have problems with using less of the
> standard interfaces (syscall, timer, gpio, rtc, ...), so they do add
> more to the
> Given this is the current state of the code (it's part of btrfs) I believe
> the following could/should be done:
Is there benchmarking data to show that a custom lock is justified
(especiaally given it's going to mean btrfs and rtlinux don't play
together nicely since it won't be able to see
> Given this is the current state of the code (it's part of btrfs) I believe
> the following could/should be done:
Is there benchmarking data to show that a custom lock is justified
(especiaally given it's going to mean btrfs and rtlinux don't play
together nicely since it won't be able to see
On Mon, 19 Feb 2018 16:43:50 -0800
Linus Torvalds <torva...@linux-foundation.org> wrote:
> On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote:
> >
> > In theory there's nothing stopping a guest getting a 'you are about to
> > gain/lose I
On Mon, 19 Feb 2018 16:43:50 -0800
Linus Torvalds wrote:
> On Mon, Feb 19, 2018 at 4:13 PM, Alan Cox wrote:
> >
> > In theory there's nothing stopping a guest getting a 'you are about to
> > gain/lose IBRS' message or having a new 'CPU' hotplugged and the old one
&g
On Tue, 20 Feb 2018 00:00:23 +
"Van De Ven, Arjan" wrote:
> > On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:
> >
> > > the guest is not the problem; guests obviously will already honor if
> > > Enhanced
> > > IBRS is enumerated. The problem is
On Tue, 20 Feb 2018 00:00:23 +
"Van De Ven, Arjan" wrote:
> > On Mon, 19 Feb 2018 23:42:24 +, "Van De Ven, Arjan" said:
> >
> > > the guest is not the problem; guests obviously will already honor if
> > > Enhanced
> > > IBRS is enumerated. The problem is mixed migration pools where
> If the UEFI is as secure as storing an unencrypted file on a hard
> drive, I am satisfied. Or do you have a better idea where to store the
> SSH keys for a diskless system that boots via network?
Store them in the TPM ?
If you are booting over a network and not doing some kind of TPM based
> If the UEFI is as secure as storing an unencrypted file on a hard
> drive, I am satisfied. Or do you have a better idea where to store the
> SSH keys for a diskless system that boots via network?
Store them in the TPM ?
If you are booting over a network and not doing some kind of TPM based
On Tue, 13 Feb 2018 22:04:48 +0100
Pavel Machek <pa...@ucw.cz> wrote:
> On Thu 2018-02-08 20:52:40, Alan Cox wrote:
> > > > Also worth nothing that the difference between the cpu and memory
> > > > speeds is much lower - so far fewer instructions could be spe
On Tue, 13 Feb 2018 22:04:48 +0100
Pavel Machek wrote:
> On Thu 2018-02-08 20:52:40, Alan Cox wrote:
> > > > Also worth nothing that the difference between the cpu and memory
> > > > speeds is much lower - so far fewer instructions could be speculatively
> > &
> if (c->x86_cache_size >= 0)
> seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size);
>
> which is silly, because that really can be done with:
>
> if (c->x86_cache_size)
>
> as there is no point in printing 'cache size 0KB', which means
> x86_cache_size can be
> if (c->x86_cache_size >= 0)
> seq_printf(m, "cache size\t: %d KB\n", c->x86_cache_size);
>
> which is silly, because that really can be done with:
>
> if (c->x86_cache_size)
>
> as there is no point in printing 'cache size 0KB', which means
> x86_cache_size can be
On Sun, 11 Feb 2018 11:42:47 -0800
Andy Lutomirski wrote:
> On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote:
>
> >> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote:
> >>
> >>> Does Debian make it easy to upgrade to a 64-bit
On Sun, 11 Feb 2018 11:42:47 -0800
Andy Lutomirski wrote:
> On Feb 11, 2018, at 9:40 AM, Mark D Rustad wrote:
>
> >> On Feb 11, 2018, at 2:59 AM, Adam Borowski wrote:
> >>
> >>> Does Debian make it easy to upgrade to a 64-bit kernel if you have a
> >>> 32-bit install?
> >>
> >> Quite
On Thu, 8 Feb 2018 16:22:40 +0100
Arnd Bergmann <a...@arndb.de> wrote:
> On Thu, Feb 8, 2018 at 2:49 PM, Alan Cox <gno...@lxorguk.ukuu.org.uk> wrote:
> >> What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
> >> MMX). I've tried a spectre
On Thu, 8 Feb 2018 16:22:40 +0100
Arnd Bergmann wrote:
> On Thu, Feb 8, 2018 at 2:49 PM, Alan Cox wrote:
> >> What about Pentium II and 3? I'm using 5 such machines (and also a Pentium
> >> MMX). I've tried a spectre test before and it wasn't reading anything
> >>
> > Also worth nothing that the difference between the cpu and memory
> > speeds is much lower - so far fewer instructions could be speculatively
> > executed while waiting a cache miss.
But they also have more instructions that take a lot of clocks and are
easier to stall - eg by doing things
101 - 200 of 11107 matches
Mail list logo