Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplay tty devices

On Fri, Apr 12, 2024 at 09:13:17AM -0400, Thor Lancelot Simon wrote: > On Sat, Apr 06, 2024 at 11:56:27PM +0900, Izumi Tsutsui wrote: > > > > I'd like to add new APIs to use wskbd(4) input on non-wsdisplay > > tty devices, especially news68k that can use a putchar

Re: [RFC] new APIs to use wskbd(4) input on non-wsdisplay tty devices

On Sat, Apr 06, 2024 at 11:56:27PM +0900, Izumi Tsutsui wrote: > > I'd like to add new APIs to use wskbd(4) input on non-wsdisplay > tty devices, especially news68k that can use a putchar function > provided by firmware PROM as a kernel console device. Wouldn't a tty be a better abstraction for

Re: Forcing a USB device to "ugen"

On Tue, Mar 26, 2024 at 12:25:07AM +, Taylor R Campbell wrote: > > We should really expose a /dev/ugen* instance for _every_ USB device; > those that have kernel drivers attached have only limited access via > /dev/ugen* (no reads, writes, transfer ioctls, ), until you do >

Re: PVH boot with qemu

On Mon, Dec 11, 2023 at 10:22:18AM +0100, Emile `iMil' Heitor wrote: > > Or would you prefer the same kernel to be able to boot in both XENPVH and > GENPVH modes? I am focusing on making the resulting kernel smaller but this > could be done also. Yes, the same kernel should be able to boot on

Re: Maxphys on -current?

On Fri, Aug 04, 2023 at 09:48:18PM +0200, Jarom??r Dole??ek wrote: > > For the branch, I particularly disliked that there were quite a few > changes which looked either unrelated, or avoidable. There should not have been any "unrelated" changes. I would not be surprised if there were changes

Re: How to submit patches?

he set of people with the knowledge to review work in this area is not so large, and copying the per-port lists might help get their attention. -- Thor Lancelot Simon t...@panix.com "Somehow it works like a joke, but it mak

Re: Comparison of different-width ints in ixg(4)

On Sun, Oct 09, 2022 at 09:24:32AM -0500, Mario Campos wrote: > On Sat, Oct 8, 2022 at 1:00 PM Taylor R Campbell > wrote: > > > > > Date: Sat, 8 Oct 2022 10:58:58 -0500 > > > From: Mario Campos > > > > > > I ran a SAST tool, CodeQL, against trunk and found a couple of > > > instances (below)

Re: MP-safe /dev/console and /dev/constty

On Sat, Oct 01, 2022 at 07:59:23PM -0400, Mouse wrote: > > usual approach to such things. Your suggestion of pushing it into a > separate function (which presumably would just mean using return > instead of break to terminate the code block) strikes me as worth > considering in general but a bad

Re: regarding the changes to kernel entropy gathering

> and hifn(4) have RNGs; and there are some dedicated RNG devices like > ualea(4). Can we actually use the TPM RNG from in-kernel? Whether we should is a different, interesting question, given how it is typically implemented. -- Thor Lancelot Simon

Re: regarding the changes to kernel entropy gathering

On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote: > At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon wrote: > > > But what you're missing is that neither does what you > > think. When rndctl -L runs after the system comes up multiuser, all > > entrop

Re: regarding the changes to kernel entropy gathering

On Mon, Apr 05, 2021 at 02:13:31PM -0700, Greg A. Woods wrote: > At Mon, 5 Apr 2021 15:37:49 -0400, Thor Lancelot Simon wrote: > Subject: Re: regarding the changes to kernel entropy gathering > > > > On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote: > > &g

Re: regarding the changes to kernel entropy gathering

On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote: > > BTW, to me reusing the same entropy on every reboot seems less secure. Sure. But that's not what the code actually does. Please, read the code in more depth (or in this case, breadth), then argue about it.

Re: regarding the changes to kernel entropy gathering

On Mon, Apr 05, 2021 at 09:30:16AM -0700, Greg A. Woods wrote: > At Mon, 5 Apr 2021 10:46:19 +0200, Manuel Bouyer > wrote: > Subject: Re: regarding the changes to kernel entropy gathering > > > > If I understood it properly, there's no need for such a knob. > > echo

Re: regarding the changes to kernel entropy gathering

On Sun, Apr 04, 2021 at 01:08:20PM -0700, Greg A. Woods wrote: > > I trust the randomness and in-observability and isolation of the > behaviour of my system's fans far more than I would trust Intel's RDRAND > or RDSEED instructions. I do not. However, I do differ with Taylor in that I believe

Re: nothing contributing entropy in Xen domUs? (causing python3.7 rebuild to get stuck in kernel in "entropy" during an "import" statement)

On Wed, Mar 31, 2021 at 11:24:07AM +0200, Manuel Bouyer wrote: > On Tue, Mar 30, 2021 at 10:42:53PM +, Taylor R Campbell wrote: > > > > There are no virtual RNG devices on the system in question, according > > to the quoted `rndctl -l' output. Perhaps the VM host needs to be > > taught to

Re: Set USB device ownership based on vedorid/productid

On Mon, Feb 15, 2021 at 12:15:28PM -0500, Mouse wrote: > > Does NetBSD provide any framework that allows USB device > > ownership/permissions to be autmatically set on USB > > VendorId/DeviceId? > > As far as I know it doesn't; a quick look at 8.0's manpages didn't show > me anything. (9.1 is

Re: partial failures in write(2) (and read(2))

On Fri, Feb 05, 2021 at 08:10:06PM -0500, Mouse wrote: > > It is possible for write() calls to fail partway through, after > > already having written some data. > > It is. As you note later, it's also possible for read(). > > The rightest thing to do, it seems to me, would be to return the

Re: /dev/random issue

> dd if=/tmp/file of=/dev/random bs=32 count=1 > > This will be preserved accross reboots, so it is a one-time only fix. > > Martin -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If yo

Re: "wireguard" implementation improperly merged and needs revert

On Sat, Aug 22, 2020 at 08:35:39PM +0200, Jason A. Donenfeld wrote: > > In its current form, there are implementation flaws and violations > that I do not consider acceptable, and deploying this kind of thing is > highly irresponsible and harmful to your users. Can you please explain what these

Re: /dev/crypto missing

cond rewrite on their new devvcrypto ENGINE to make it do so. -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will

Re: AES leaks, cgd ciphers, and vector units in the kernel

Architecture, MSA?). BearSSL's aes_ct64 64-bit bitsliced > implementation might be worth adopting for 64-bit CPUs without a > vector unit, if anyone cares -- maybe alpha or mips64. But I think > I'm at the limit of what I'm willing to do for fun with the hardware I > have easy access to. --

Re: makesyscalls

Python is essentially uncrosscompilable and its maintainers have repeatedly rudely rejected efforts to make it so. If that weren't the case, and the way installed Python modules were "managed" (I use the term liberally) were made sane, I'd think it were a fine thing to use in base. But it is the

Re: KAUTH_SYSTEM_UNENCRYPTED_SWAP

it always as i've been unable to think of any use case that > > is the only solution. > > Always encrypted swap would be even better but ... slow machines. Compared to the time required to put the pages out to disk? Could try chacha8. -- Thor Lancelot Simon

Initial entropy with no HWRNG

On Tue, May 12, 2020 at 10:00:20AM +0300, Andreas Gustafsson wrote: > > Adding more sources could mean > reintroducing some timing based sources after careful analysis, but > also things like having the installer install an initial random seed > on the target machine (and if the installer itself

Re: Rump makes the kernel problematically brittle

- with testing, with userspace network stacks, and more. But it is tremendously unfortunate that it was checked into our tree before it was ready, and has remained that way ever since. I'd love to see a GSoC project to actually make rump build like the kernel...but it may be too much

Re: Blocking vcache_tryvget() across VOP_INACTIVE() - unneeded

ither. Do we want such a thing? Or do we want to press on towards more modern "that didn't work, try again" approaches like pserialize or the COW scheme you describe? -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for cha

Re: Proposal: removing urio(4), Rio 500 MP3 player (1999), and Rio-related packages

it's a bit of a shame to see uscanner or any other target-specific driver go, with an inherently unsafe generic target driver as replacement, though perhaps in this case it's necessary. -- Thor Lancelot Simon t...@panix.com "Whether or

Re: racy acccess in kern_runq.c

On Fri, Dec 06, 2019 at 09:00:33AM +, Andrew Doran wrote: > > Please don't commit this. These accesses are racy by design. There is no > safety issue and we do not want to disturb the activity of other CPUs in > this code path by locking them. We also don't want to use atomics either.

Re: Fonts for console/fb for various locales: a proposal

On Sat, Sep 28, 2019 at 02:39:19PM +0200, tlaro...@polynum.com wrote: > > 4. Rasterizing (c). This is the whole purpose of METAFONT. METAFONT is a > rasterizer. Rasterization of vector fonts by privileged code has been a major source of security holes in other operating systems. Does the very

Re: fexecve

On Sun, Sep 08, 2019 at 06:27:11PM -, Christos Zoulas wrote: > In article <20190908180303.ga6...@panix.com>, > Thor Lancelot Simon wrote: > >On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote: > >> > >> Here's a simple fexecve(2) impl

Re: fexecve

On Sun, Sep 08, 2019 at 01:23:46PM -0400, Christos Zoulas wrote: > > Here's a simple fexecve(2) implementation. Comments? I think this is dangerous in systems which use chroot into filesystems mounted noexec (or nosuid) and file-descriptor passing into the constrained environment to feed data.

Re: /dev/random is hot garbage

o replace them, if that helped. -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but becau

Re: Interface description support

On Mon, Jun 24, 2019 at 08:08:24AM -0400, Mouse wrote: > > I think I would prefer that attempting to set a description that > equals an interface name is rejected, and, when attaching an interface > after boot (ie, after interface descriptions can have been set), when > choosing an interface

Re: of_getnode_byname: infinite loop

On Sat, Apr 27, 2019 at 07:52:07AM +0200, yarl-bau...@mailoo.org wrote: > I would like to insist since I got no answer. I think you forgot to attach the proposed patch. Thor

Re: Regarding the ULTRIX and OSF1 compats

On Sun, Mar 17, 2019 at 05:41:18AM +0800, Paul Goyette wrote: > On Sat, 16 Mar 2019, Maxime Villard wrote: > > > Regarding COMPAT_OSF1: I'm not totally sure, but it seems that Alpha's > > COMPAT_LINUX uses COMPAT_OSF1 as dependency (even if there is no proper > > dependency in the module),

Re: svr4, again

ble utility, in addition to > > being > > clear dead wood (in terms of use case, commits in these areas, and ability > > to > > test changes). > > > > Does anyone have anything to say? -- Thor Lancelot Simon t...@pani

Re: scsipi: physio split the request

On Tue, Jan 01, 2019 at 02:48:05PM -0500, Thor Lancelot Simon wrote: > > The work remaining to be done on the branch, as I see it, is: [...] I missed one. I got fed up dealing with the way arguments are passed through the mount syscalls (especially for ufs) so the work of letting mount(8

Re: scsipi: physio split the request

On Thu, Dec 27, 2018 at 09:07:41AM +, Emmanuel Dreyfus wrote: > Hello > > A few years ago I made a failed attempt at running LTFS on a LTO 6 drive. > I resumed the effort, and once I got the LTFS code ported, running > a command like mkltfs fails with kernel console saying: >

Re: Importing libraries for the kernel

on't own either implementation and thus can't contribute them. They did _not_ cause measureable performance problems of any kind, and though it is theoretically possible to do this sort of thing via a tightly-protected userspace helper process, I prototyped that too and it gets very ugly, very fast -- the i

Re: noatime mounts inhibiting atime updates via utime()

ced lifespan of > the drive. Yes - this originally came to my attention with LFS, where at one point in the distant past, the atime updates were triggering full-segment writes for every file *read*! I think LFS may still have a local workaround for this. Perhaps it should be generalized. --

Re: pci_intr_alloc() vs pci_intr_establish() - retry type?

On Wed, Nov 28, 2018 at 12:34:42PM -0500, Michael wrote: > > Or, for that matter, if it can use one IRQ or - say - 8 MSI. Right, this is pretty common, isn't it? -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope

Re: nvmm

On Mon, Oct 08, 2018 at 12:02:14PM +0200, Maxime Villard wrote: > Here is support for hardware-accelerated virtualization on x86 [1]. A generic > MI driver, to which MD backends can be plugged. Most of it has already been > discussed in private. > > I intend to commit it soon, in: > >

Re: Missing compat_43 stuff for netbsd32?

On Tue, Sep 11, 2018 at 03:35:24PM +, Eduardo Horvath wrote: > > It's probably only useful for running ancient SunOS 4.x binaries, maybe > Ultrix, Irix or OSF-1 depending on how closely they followed BSD 4.3. Actually, I think amd64, sparc64, and mips64 are the only platforms where it could

Re: Too many PMC implementations

a statistical profiler that DTrace offers. The basic requirement for FBT is a dynamic patcher (to really do it right); though some __predict-false branches can be inserted at the head of every function and a global used instead. -- Thor Lancelot Simon t.

Re: Too many PMC implementations

boss. Should it have, then, been ripped out? It's certainly a lot more complex than gprof. -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand

Re: Too many PMC implementations

ot imply it is "not useful" simpliciter. -- Thor Lancelot Simon t...@panix.com "Whether or not there's hope for change is not the question. If you want to be a free person, you don't stand up for human rights because it will work, but because it is right." --Andrei Sakharov

Re: 8.0 performance issue when running build.sh?

0.01 kernel_lockfrag6_slowtimo+1f > 0.01 4 0.00 kernel_lockkevent1+698 > > so .. no need to worry about kernel_lock for this load any more. Actually, I wonder if we could kill off the time spent by fileassoc. Is it still used only by veriexec? We can ea

Re: hashtables

On Tue, Jul 24, 2018 at 10:14:57PM +, co...@sdf.org wrote: > > I don't have any opinions about hashtables - I just know that > implementing one would take me really long and would probably still be > buggy in the end, and I didn't find a similar API that claims to be a > hashtable. > > Is

Re: hashtables

On Tue, Jul 24, 2018 at 07:01:36PM +, co...@sdf.org wrote: > hi netbsd, > > if I were to state I totally need hashtables, what already existing API > would you tell me to use instead? The kernel has lots of hash tables in it. If a hash table is the right datastructure for your purpose, why

Re: 8.0 performance issue when running build.sh?

t think the master runs builds any more, does it? So it shouldn't be doing much and should have tons of CPU and memory bandwidth available to move that data. -- Thor Lancelot Simont...@panix.com "The two most common variations translate as foll

Re: 8.0 performance issue when running build.sh?

On Thu, Jul 12, 2018 at 07:39:10PM +0200, Martin Husemann wrote: > On Thu, Jul 12, 2018 at 12:30:39PM -0400, Thor Lancelot Simon wrote: > > Are you running the builds from tmpfs to tmpfs, like the build cluster > > does? > > No, I don't have enough ram to test it tha

Re: 8.0 performance issue when running build.sh?

On Thu, Jul 12, 2018 at 05:29:57PM +0200, Martin Husemann wrote: > On Tue, Jul 10, 2018 at 11:01:01AM +0200, Martin Husemann wrote: > > So stay tuned, maybe only Intel to blame ;-) > > Nope, that wasn't it. > > I failed to reproduce *any* slowdown on an AMD CPU locally, maya@ kindly > repeated

Re: Removing bitrotted sys/dev/pci/n8 (NetOctave NSP2000)

On Tue, Jul 10, 2018 at 06:56:53PM +, co...@sdf.org wrote: > Hi, > > The code in sys/dev/pci/n8 has bitrotted - it still makes references to > LKM_ system things, so it is unlikely it builds. > This has been the case since netbsd-6. I still have the hardware, but I seriously doubt anyone's

Re: CVS commit: src/sys/arch/x86/x86

On Mon, Jul 09, 2018 at 12:24:15PM +0200, Kamil Rytarowski wrote: > > The C11 standard could indeed use consistent wording. In one place > "correctly aligned" in other alignment "restrictions" and > "requirements". None of these terms is marked as a keyword or term and I > read them in the

Re: CVS commit: src/sys/arch

e it can break things or harm performance (the trick conditionally used in some device drivers of intentionally misaligning structures so their fields accessed by DMA meet DMA alignment constraints comes to mind). -- Thor Lancelot Simont...@panix.co

Re: new errno ?

ould have panic'd here, heh", why not simply return > an error code appropriate for the situation that would have otherwise > resulted in calling panic()? There are many to choose from :-) > > -- thorpej > -- Thor Lancelot Simont...

Re: Revisiting uvm_loan() for 'direct' write pipes

red that for typical message sizes to/from the microkernel, mapping instead of copying was definitely a lose. In this case, could we do better gathering the IPIs so the cost were amortized over many pages? -- Thor Lancelot Simont...@panix.com "The

Re: secmodel_securelevel(9) and machdep.svs.enabled

On Wed, Apr 25, 2018 at 09:43:18PM +0100, Alexander Nasonov wrote: > > Thinking a bit more about this, I don't think my patch will prevent > data leakage from the kernel because /dev/mem and /dev/kmem are > readable at all securelevels. It can only prevent leakage in some If that is true it's a

Re: meltdown

On Thu, Jan 04, 2018 at 04:58:30PM -0500, Mouse wrote: > > As I understand it, on intel cpus and possibly more, we'll need to > > unmap the kernel on userret, or else userland can read arbitrary > > kernel memory. > > "Possibly more"? Anything that does speculative execution needs a good > hard

Re: RFC: ipsec(4) pseudo interface

On Mon, Dec 18, 2017 at 06:49:44PM +0900, Kengo NAKAHARA wrote: > Hi, > > We implement ipsec(4) pseudo interface for route-based VPNs. This pseudo > interface manages its security policy(SP) by itself, in particular, we do > # ifconfig ipsec0 tunnel 10.0.0.1 10.0.0.2 > the SPs "10.0.0.1 ->

Re: Merging ugen into the usb stack

On Fri, Dec 15, 2017 at 08:30:00PM +0100, Martin Husemann wrote: > - when libusb takes over controll (as Steffen described) a kernel driver >that would have attached (i.e. when the skipping does not happen or >the userland application is configured wrong) is detached, so no >

Re: increase softint_bytes

On Thu, Nov 16, 2017 at 10:25:54PM +0100, Jarom??r Dole??ek wrote: > > If I count correctly, with current 8192 bytes the system supports some 100 > softints, which seems to be on quite low side - more advanced hardware and > drivers usually use queue and softint per cpu, so it can quickly run out

Re: kaslr: better rng

kern that prevent you from doing so? > > No, there are no constraints. I just didn't know we could use libkern. So you > can forget about my prng.c, I'll use libkern's SHA512 until we have SHA3. > > > Le 12/11/2017 ?? 03:13, Thor Lancelot Simon a ??crit : > > cpu_rng already

Re: amd64: kernel aslr support

>and haven't changed. > > Very nicely done! Seriously! Nice work! -- Thor Lancelot Simont...@panix.com "The two most common variations translate as follows: illegitimi non carborundum = the unlawful are not silicon carbide illegitimis non carborundum = the unlawful don't have silicon carbide."

Re: kaslr: better rng

On Sat, Nov 11, 2017 at 09:23:39PM +, Taylor R Campbell wrote: > > Speaking of which, you should read 256 bits out of rdseed, not 64, and > fall back to rdrand if rdseed is not available. cpu_rng already has the code needed to do this -- best to use it, perhaps? Thor

Re: kaslr: better rng

two RNGs? -- Thor Lancelot Simont...@panix.com "The two most common variations translate as follows: illegitimi non carborundum = the unlawful are not silicon carbide illegitimis non carborundum = the unlawful don't have silicon carbide."

Re: kaslr: better rng

On Mon, Nov 06, 2017 at 07:30:35AM +0100, Maxime Villard wrote: > I'm in a point where I need to have a better rng before continuing - and an > rng that can be used in the bootloader, in the prekern and in the kernel > (early). > > I would like to use a system similar to the /var/db/entropy-file

Re: New line discipline flag to prevent userland open/close of the device

On Sun, Oct 29, 2017 at 12:47:26PM +0100, Martin Husemann wrote: > While analyzing PR port-sparc64/52622 I ran into the following issue. > > On some sun hardware, the com0 device is used to connect an old style > keyboard, > and com1 is used for mouse. On other sparc64 machines, com0/com1 are

Re: amd64: kernel aslr support

> * The RNG is not really strong. Help in this area would be greatly >appreciated. This is tricky mostly because once you start probing for hardware devices or even CPU features, you're going to find yourself wanting more and more of the support you'd get from the "real kernel". For

Re: intel sgx support

a whole class of use cases. Thor On Wed, Sep 27, 2017 at 09:54:44AM -0400, Stephen Herwig wrote: > Has anyone looked at adding Intel SGX support to NetBSD? > > Thanks, > Stephen -- Thor Lancelot Simont...@panix.com "We cannot usual

Re: how to tell if a process is 64-bit

what _do_ we do on modern, 32-bit MIPS? Are we still O32? It does kind of look like it -- all our 32-bit MIPS ports' sets files seem to be linked to ../../../shared/mipsel/ which must be O32 since it is also used for the pmax sets. -- Thor Lancelot Simon

Re: how to tell if a process is 64-bit

On Fri, Sep 08, 2017 at 07:38:24AM -0400, Mouse wrote: > > In a cross-platform process utility tool the question came up how to > > decide if a process is 64-bit. > > First, I have to ask: what does it mean to say that a particular > process is - or isn't - 64-bit? I think the only simple answer

Re: Proposal: Disable autoload of compat_xyz modules

On Wed, Aug 02, 2017 at 12:35:22PM +, Taylor R Campbell wrote: > > I propose to disable the following modules by default, but leave the > code so you can still modload them or include them in your custom > kernel config if you want: > > compat_osf1 This probably still has users on Alpha. >

Re: wscons/wsmux question

On Sun, Jun 18, 2017 at 12:14:41PM +0800, Paul Goyette wrote: > > Would anyone object if I were to remove all of the "#if NWSMUX > 0" > conditionals, and simply require the wsmux code to be included (via > files.wscons) whenever any child dev (wsdisplay, wskbd, wsmouse, or wsbell) > is

Re: RFC: localcount_hadref() or localcount_trydarin()

rn instruction-based accelerators rather than the DMA-and-interrupts style this probably matters less. * Once per Phase 2 IPsec association -- potentially tens of thousands per second in recovery from an outage -- this likely matters more to

Re: Restricting rdtsc [was: kernel aslr]

On Tue, Apr 04, 2017 at 05:39:35PM +0200, Maxime Villard wrote: > sorry for the delay > > Le 31/03/2017 ? 19:23, Andreas Gustafsson a ?crit : > > It's ASLR that's broken, not rdtsc, and I strongly object to > > restricting the latter just to that people can continue to gain > > a false sense of

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

On Tue, Apr 04, 2017 at 12:39:46AM +0200, Jarom??r Dole??ek wrote: > > Is there any reason we wouldn't want to set QAM=1 by default for > sd(4)? Seems like pretty obvious performance improvement tweak. Supposedly, there are some rather old drives -- mid-1990s or thereabouts -- that may keep some

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

On Sat, Apr 01, 2017 at 09:26:50AM +, Michael van Elst wrote: > > >Setting WCE on SCSI drives is simply a bad idea. It is > >not necessary for performance and creates data integrity > >isues. > > I don't know details about data integrity issues although > I'm sure there are some. But

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

On Sat, Apr 01, 2017 at 06:46:24PM +0200, Michael van Elst wrote: > On Sat, Apr 01, 2017 at 11:12:42AM -0400, Thor Lancelot Simon wrote: > > > That said, very high-latency transports like iSCSI require a lot more > > data than we can put into flight at once. We just

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

On Sat, Apr 01, 2017 at 08:54:40AM +, Michael van Elst wrote: > t...@panix.com (Thor Lancelot Simon) writes: > > >When SCSI tagged queueing is used properly, it is not necessary to set WCE > >to get good write performance, and doing so is in fact harmful, since it &

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

On Fri, Mar 31, 2017 at 07:16:25PM +0200, Jarom??r Dole??ek wrote: > > The problem is that it does not always use SIMPLE and ORDERED tags in a > > way that would facilitate the use of ORDERED tags to enforce barriers. > > Our scsipi layer actually never issues ORDERED tags right now as far > as I

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

On Fri, Mar 31, 2017 at 02:16:44PM +0200, Edgar Fu? wrote: > Oh well. > > TLS> If the answer is that you're running with WCE on in the mode pages, then > TLS> don't do that: > EF> I don't get that. If you turn off the write cache, you need neither cache > EF> flushes nor ordering, no? > MB> You

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

tags have been committed to stable storage; and if that's not enough, you can, I believe, use a HEAD tag. Why isn't that good enough? If the answer is that you're running with WCE on in the mode pages, then don't do that: use SIMPLE tags for all writes except when you intend a barrier, and ORDERED when

Re: Restricting rdtsc [was: kernel aslr]

On Tue, Mar 28, 2017 at 04:58:58PM +0200, Maxime Villard wrote: > Having read several papers on the exploitation of cache latency to defeat > aslr (kernel or not), it appears that disabling the rdtsc instruction is a > good mitigation on x86. However, some applications can legitimately use it, >

Re: Exposing FUA as alternative to DIOCCACHESYNC for WAPBL

On Tue, Mar 28, 2017 at 01:17:18AM +0200, Jarom??r Dole??ek wrote: > 2017-03-12 11:15 GMT+01:00 Edgar Fu?? : > > Some comments as I probably count as one of the larger WAPBL consumers (we > > have ~150 employee's Home and Mail on NFS on FFS2+WAPBL on RAIDframe on > > SAS):

Re: kernel aslr: someone interested?

On Sat, Mar 25, 2017 at 09:20:14AM +0100, Maxime Villard wrote: > > Verily, 5-level page trees with higher entropy will be introduced by Intel > soon, the instructions that leak kernel addresses can be made privileged > (UMIP), cache issues are being fixed; and in short, I wouldn't be surprised >

Re: 10Gb and 40Gb equipment available

On Thu, Feb 16, 2017 at 10:42:21AM -0500, Thor Lancelot Simon wrote: > NetBSD has received a donation of 10Gb Ethernet switches (Arista 7124S or SX > and 7050). > > We will use some of these switches in our own infrastructure but are > offering others for long-term use by develo

10Gb and 40Gb equipment available

pment work. Please let me know before the end of February if you want hardware from this donation, and why. -- Thor Lancelot Simon t...@panix.com Cry, the beloved country, for the unborn child that is the inheritor of our fear.

Re: workqueue for pr_input

On Mon, Jan 23, 2017 at 05:58:20PM +0900, Ryota Ozaki wrote: > > The demerit is that that mechanism adds non-trivial > overhead; RTT of ping increases by 30 usec. I don't see why overhead for control protocols like ICMP matters. I think if you look at longstanding commercial designs for

Re: Plan: journalling fixes for WAPBL

On Mon, Jan 02, 2017 at 06:08:04PM +, David Holland wrote: > On Mon, Jan 02, 2017 at 01:01:34PM -0500, Thor Lancelot Simon wrote: > > On Mon, Jan 02, 2017 at 05:31:23PM +, David Holland wrote: > > > (from a while back) > > > > > > However, I'm mis

Re: Plan: journalling fixes for WAPBL

A-attached SSDs... > what are/were they doing? Aggressive prefetching, extreme efforts to reduce command latency at the drive end of the SATA link (and higher link speeds), plus much larger request sizes than we can issue. -- Thor Lancelot Simon

Re: History of disklables

e disk contents (to write either an Ultrix or 4.4BSD label into place). -- Thor Lancelot Simon t...@panix.com Ring the bells that still can ring.

Re: Possible buffer cache race?

r cache size much smaller so recycling's going on all the time, figure out how to instrument it, and debug... -- Thor Lancelot Simont...@panix.com "The dirtiest word in art is the C-word. I can't even say 'craft' without feeling dirty."-Chuck Close

Re: vioif vs if_vio

On Sat, Sep 24, 2016 at 02:02:16PM +0800, Paul Goyette wrote: > Shouldn't the vioif(4) device be more properly named if_vio(4), to be > consistent with other network interfaces? I think the code was imported with the same filenames as its original source, to ease merging of updates. > With its

Re: FUA and TCQ (was: Plan: journalling fixes for WAPBL)

On Fri, Sep 23, 2016 at 01:02:26PM +, paul.kon...@dell.com wrote: > > > On Sep 23, 2016, at 5:49 AM, Edgar Fu?? wrote: > > > >> The whole point of tagged queueing is to let you *not* set [the write > >> cache] bit in the mode pages and still get good performance. > >

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 07:45:00PM +0200, Manuel Bouyer wrote: > On Fri, Sep 23, 2016 at 05:15:16PM +, Eric Haszlakiewicz wrote: > > On September 23, 2016 10:51:30 AM EDT, Warner Losh wrote: > > >All NCQ gives you is the ability to schedule multiple requests and > > >to get

Re: FUA and TCQ

On Fri, Sep 23, 2016 at 09:38:08AM -0400, Greg Troxel wrote: > > Johnny Billquist writes: > > > With rotating rust, the order of operations can make a huge difference > > in speed. With SSDs you don't have those seek times to begin with, so > > I would expect the gains to be

Re: Plan: journalling fixes for WAPBL

On Fri, Sep 23, 2016 at 11:47:24AM +0200, Manuel Bouyer wrote: > On Thu, Sep 22, 2016 at 09:33:18PM -0400, Thor Lancelot Simon wrote: > > > AFAIK ordered tags only guarantees that the write will happen in order, > > > but not that the writes are actually d

Re: Plan: journalling fixes for WAPBL

On Thu, Sep 22, 2016 at 04:06:55PM +0200, Manuel Bouyer wrote: > On Thu, Sep 22, 2016 at 07:50:27AM -0400, Thor Lancelot Simon wrote: > > On Thu, Sep 22, 2016 at 01:27:48AM +0200, Jarom??r Dole??ek wrote: > > > > > > 3.2 use FUA (Force Unit Access) for commit record w

Re: Plan: journalling fixes for WAPBL

On Thu, Sep 22, 2016 at 01:27:48AM +0200, Jarom??r Dole??ek wrote: > > 3.2 use FUA (Force Unit Access) for commit record write > This avoids need to issue even the second DIOCCACHESYNC, as flushing > the disk cache is not really all that useful, I like the thread over > at: >

  1   2   3   4   5   6   >