Re: [patch] ftp(1): change mtime for http/https links

2017-09-23 Thread Anton Lindqvist
On Fri, Sep 22, 2017 at 11:56:51PM +0100, Raf Czlonka wrote:
> On Fri, Sep 22, 2017 at 11:01:57PM BST, Jesper Wallin wrote:
> > Hi all,
> > 
> > My morning routine consists of downloading the latest snapshot files and
> > running the upgrade.  To avoid wasting bandwidth and time, I check the
> > local modification time of INSTALL.amd64, fetch the remote one and check
> > if the modification time has changed.
> 
> Hi Jesper,
> 
> This is unrelated to your diff but what I do instead is to check
> the BUILDINFO file - it's tiny and all the information you need,
> is already there.

Continuing OT: I also rely on the contents of BUILDINFO to determine if
a new snapshot is available:

  $ head `which snapshot`
  #!/bin/sh

  url="$(head -1 /etc/installurl)/snapshots/$(uname -m)"

  [ -e BUILDINFO ] && ftp -V -o- "${url}/BUILDINFO" | cmp -s BUILDINFO - && 
exit 1



Re: [patch] ftp(1): change mtime for http/https links

2017-09-23 Thread Jesper Wallin
Yeah, the SHA256.sig should be enough and just veify that everything is
correct.  If not, fetch the incorrect sets again.  I just wanted to give
a brief explaination on how I noticed this inconsistency.  But yeah,
thanks for pointing me to a better solution.


On Sat, Sep 23, 2017 at 05:12:32AM -0400, Ted Unangst wrote:
> Raf Czlonka wrote:
> > This is unrelated to your diff but what I do instead is to check
> > the BUILDINFO file - it's tiny and all the information you need,
> > is already there.
> 
> While we're on the subject, I'll point out that sometimes only the base sets
> change, but not the x sets. If you download SHA256 you can download only files
> that differ. (This also may work better if you switch mirrors or the
> timestamps drift for other reasons.) It's just a few lines of shell, though I
> don't have them handy atm.
> 
> (And for bonus points, you can use SHA256.sig and verify it's correct, then
> verify that BUILDINFO hasn't been tampered with, etc...)
> 
> ftp/http should still do the right thing, of course.



hostname.if5 patch

2017-09-23 Thread Tom Smyth
Hello Lads,

I have submitted a proposed patch for hostname.if5 to show a user how
to do Point to Point Addressing  on an interface  (thanks to @Tedu for
publishing the correct syntax which helped me.

So I (tried to ) show syntax  for that case on the hostname.if manual  file
Thanks to Nikolai for helping me with the patch generation


hostname.if.5patch
Description: Binary data


Re: Who are the ACPI hackers?

2017-09-23 Thread Mike Larkin
On Sat, Sep 23, 2017 at 11:16:54AM +0200, Gellert Farkas wrote:
> Hi,
> 
> I'm not quite sure of the process or exact protocol, but would it be
> possible for those responsible for ACPI related bugs have a look at my
> previous post? https://marc.info/?l=openbsd-tech=150607863024523
> 
> I don't want to be pushy and I am in no rush for a fix, I just want to
> ensure that these reports are seen by the correct individuals
> responsible.
> 
> I could look into this myself and if I work it out, I could provide a
> patch, but I don't want to duplicate work if this is already in hand
> and a known issue.
> 
> Thanks in advance (and please be gentle with me) ;)
> 
> G.
> 

If it's the same bug that you linked to in that original post, you should
see if you can figure out why acpiec isn't attaching.

-ml



Re: [patch] ftp(1): change mtime for http/https links

2017-09-23 Thread Ted Unangst
Raf Czlonka wrote:
> This is unrelated to your diff but what I do instead is to check
> the BUILDINFO file - it's tiny and all the information you need,
> is already there.

While we're on the subject, I'll point out that sometimes only the base sets
change, but not the x sets. If you download SHA256 you can download only files
that differ. (This also may work better if you switch mirrors or the
timestamps drift for other reasons.) It's just a few lines of shell, though I
don't have them handy atm.

(And for bonus points, you can use SHA256.sig and verify it's correct, then
verify that BUILDINFO hasn't been tampered with, etc...)

ftp/http should still do the right thing, of course.



Re: [patch] ftp(1): change mtime for http/https links

2017-09-23 Thread Raf Czlonka
On Sat, Sep 23, 2017 at 10:12:32AM BST, Ted Unangst wrote:
> Raf Czlonka wrote:
> > This is unrelated to your diff but what I do instead is to check
> > the BUILDINFO file - it's tiny and all the information you need,
> > is already there.
> 
> While we're on the subject, I'll point out that sometimes only the base sets
> change, but not the x sets. If you download SHA256 you can download only files
> that differ. (This also may work better if you switch mirrors or the
> timestamps drift for other reasons.) It's just a few lines of shell, though I
> don't have them handy atm.
> 
> (And for bonus points, you can use SHA256.sig and verify it's correct, then
> verify that BUILDINFO hasn't been tampered with, etc...)
> 
> ftp/http should still do the right thing, of course.

Hi Ted et al.

I've mentioned BUILDINFO only as an example of the smallest file
to download which, at the same time contains very useful information.

This is what I use:

BSD="bsd.rd bsd"
test "$(sysctl -n hw.ncpu)" -ge "2" && BSD="$BSD bsd.mp"
ftp -o BUILDINFO.new -V ${SNAP_PATH}/BUILDINFO > /dev/null 2>&1 &&
cmp -s BUILDINFO.new BUILDINFO || mv BUILDINFO.new BUILDINFO &&
ftp -V ${SNAP_PATH}/SHA256.sig > /dev/null 2>&1 &&
for i in INSTALL.${arch} $BSD $SETS BUILDINFO
do
signify -q -C -p $KEY -x SHA256.sig $i > /dev/null 2>&1 ||
ftp -V ${SNAP_PATH}/${i} > /dev/null 2>&1
done

I don't think $KEY, $SNAP_PATH and $SETS require any explanation.

Regards,

Raf



Re: malloc.c: better double free check

2017-09-23 Thread Ted Unangst
Otto Moerbeek wrote:
> Hi,
> 
> Malloc maintains a list if 16 slots of chunks to be freed. On free a
> chunk is put in a random slot and the existing chunk in that slot is
> actually freed. Currently, the code only checks the slot selected for
> a double free.
> 
> This diff adds code to check all slots. It also removes the option to
> disable delayed free. 

I thought we were already doing this, so ok. :)



Who are the ACPI hackers?

2017-09-23 Thread Gellert Farkas
Hi,

I'm not quite sure of the process or exact protocol, but would it be
possible for those responsible for ACPI related bugs have a look at my
previous post? https://marc.info/?l=openbsd-tech=150607863024523

I don't want to be pushy and I am in no rush for a fix, I just want to
ensure that these reports are seen by the correct individuals
responsible.

I could look into this myself and if I work it out, I could provide a
patch, but I don't want to duplicate work if this is already in hand
and a known issue.

Thanks in advance (and please be gentle with me) ;)

G.



Re: relayd http read line

2017-09-23 Thread Sebastian Benoit
Alexander Bluhm(alexander.bl...@gmx.net) on 2017.09.22 19:54:56 +0200:
> Hi,
> 
> The relayd regression tests for chunked http traffic fail sometimes.
> Ktrace reveals that this happens when the \r and \n at the end of
> a header line are read in separate chunks.  Then evbuffer_readline()
> interpretes the \r as the end of the first line and the \n as an
> additional empty line.  So relayd gets out of sync with the http
> protocol.
> 
> The function evbuffer_readln() has been added with libevent 1.4.13
> in 2010.  With the parameter EVBUFFER_EOL_CRLF the parsing works
> reliably.
> 
> ok?

looks good, ok benno@
 
> bluhm
> 
> Index: usr.sbin/relayd/relay.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/relayd/relay.c,v
> retrieving revision 1.226
> diff -u -p -r1.226 relay.c
> --- usr.sbin/relayd/relay.c   28 Aug 2017 17:31:00 -  1.226
> +++ usr.sbin/relayd/relay.c   22 Sep 2017 16:50:51 -
> @@ -1679,8 +1679,10 @@ relay_close(struct rsession *con, const 
>   (void)print_host(>se_in.ss, ibuf, sizeof(ibuf));
>   (void)print_host(>se_out.ss, obuf, sizeof(obuf));
>   if (EVBUFFER_LENGTH(con->se_log) &&
> - evbuffer_add_printf(con->se_log, "\r\n") != -1)
> - ptr = evbuffer_readline(con->se_log);
> + evbuffer_add_printf(con->se_log, "\r\n") != -1) {
> + ptr = evbuffer_readln(con->se_log, NULL,
> + EVBUFFER_EOL_CRLF);
> + }
>   log_info("relay %s, "
>   "session %d (%d active), %s, %s -> %s:%d, "
>   "%s%s%s", rlay->rl_conf.name, con->se_id, relay_sessions,
> Index: usr.sbin/relayd/relay_http.c
> ===
> RCS file: /data/mirror/openbsd/cvs/src/usr.sbin/relayd/relay_http.c,v
> retrieving revision 1.66
> diff -u -p -r1.66 relay_http.c
> --- usr.sbin/relayd/relay_http.c  28 May 2017 10:39:15 -  1.66
> +++ usr.sbin/relayd/relay_http.c  22 Sep 2017 16:44:05 -
> @@ -169,14 +169,16 @@ relay_read_http(struct bufferevent *bev,
>   goto done;
>   }
>  
> - while (!cre->done && (line = evbuffer_readline(src)) != NULL) {
> - linelen = strlen(line);
> + while (!cre->done) {
> + line = evbuffer_readln(src, , EVBUFFER_EOL_CRLF);
> + if (line == NULL)
> + break;
>  
>   /*
>* An empty line indicates the end of the request.
>* libevent already stripped the \r\n for us.
>*/
> - if (!linelen) {
> + if (linelen == 0) {
>   cre->done = 1;
>   free(line);
>   break;
> @@ -594,7 +596,7 @@ relay_read_httpchunks(struct bufferevent
>   struct evbuffer *src = EVBUFFER_INPUT(bev);
>   char*line;
>   long longllval;
> - size_t   size;
> + size_t   size, linelen;
>  
>   getmonotime(>se_tv_last);
>   cre->timedout = 0;
> @@ -625,13 +627,13 @@ relay_read_httpchunks(struct bufferevent
>   }
>   switch (cre->toread) {
>   case TOREAD_HTTP_CHUNK_LENGTH:
> - line = evbuffer_readline(src);
> + line = evbuffer_readln(src, , EVBUFFER_EOL_CRLF);
>   if (line == NULL) {
>   /* Ignore empty line, continue */
>   bufferevent_enable(bev, EV_READ);
>   return;
>   }
> - if (strlen(line) == 0) {
> + if (linelen == 0) {
>   free(line);
>   goto next;
>   }
> @@ -660,7 +662,7 @@ relay_read_httpchunks(struct bufferevent
>   break;
>   case TOREAD_HTTP_CHUNK_TRAILER:
>   /* Last chunk is 0 bytes followed by trailer and empty line */
> - line = evbuffer_readline(src);
> + line = evbuffer_readln(src, , EVBUFFER_EOL_CRLF);
>   if (line == NULL) {
>   /* Ignore empty line, continue */
>   bufferevent_enable(bev, EV_READ);
> @@ -671,7 +673,7 @@ relay_read_httpchunks(struct bufferevent
>   free(line);
>   goto fail;
>   }
> - if (strlen(line) == 0) {
> + if (linelen == 0) {
>   /* Switch to HTTP header mode */
>   cre->toread = TOREAD_HTTP_HEADER;
>   bev->readcb = relay_read_http;
> @@ -680,7 +682,7 @@ relay_read_httpchunks(struct bufferevent
>   break;
>   case 0:
>   /* Chunk is terminated by an empty newline */
> - line = evbuffer_readline(src);
> + line = evbuffer_readln(src, , EVBUFFER_EOL_CRLF);
>   

Re: [patch] ftp(1): change mtime for http/https links

2017-09-23 Thread Jesper Wallin
Yeah, fully understandable.  I'll bump this once 6.2 is out.

I'll apply the changes Philip suggested (thanks!) and then build a
release to verify that everything works.


On Fri, Sep 22, 2017 at 11:35:03PM +0100, Stuart Henderson wrote:
> I like this, but it's rather late in the release cycle to be adding
> features to ftp(1), could you send a reminder when we're at 6.2-current?
> (Also, if you haven't already done so, check that "make release" and the
> installer still work).
> 



Re: malloc.c: better double free check

2017-09-23 Thread Otto Moerbeek
On Fri, Sep 22, 2017 at 04:35:39PM -0400, Daniel Micay wrote:

> A linear search works well for the current small quarantine (16) but won't 
> work
> well if you ever want to have a larger / configurable quarantine size. It 
> would
> also be nice to make this fast enough to enable by default.
> 
> We (CopperheadOS) use an open addressed hash table for this based on the
> existing hash table since we use a larger quarantine with a FIFO queue
> alongside the random array and a configuration size. Ideally the code would be
> shared with the existing hash table but I didn't want to make it into an
> invasive change downstream.
> 
> These are the three downstream patches for OpenBSD malloc in our copy of 
> Bionic
> (Android libc), so I'd need to port them to the current upstream code to apply
> cleanly. They're currently applied after other changes and it's a slightly
> older copy of the base code (after multi-pool support, but before the canary
> rework since we'll need to adapt that to our needs). Can get the general idea
> from the patches even though they're not going to apply cleanly though.
> 
> [1] quarantine double-free detection via hash table

Thanks for sharing this, I'll take a look soon. 

Thinking a bit about this: wouldn't a closed hash table be sufficient?
A collision would then either be a double free, otherwise just replace
old with new. You'll get a O(1) lookup and insert and simpler code.

-Otto

> 
> diff --git a/libc/bionic/omalloc.c b/libc/bionic/omalloc.c
> index 23af59501..4f4e1290c 100644
> --- a/libc/bionic/omalloc.c
> +++ b/libc/bionic/omalloc.c
> @@ -157,6 +157,7 @@ struct dir_info {
>   struct region_info free_regions[MALLOC_MAXCACHE];
>   /* delayed free chunk slots */
>   void *delayed_chunks[MALLOC_DELAYED_CHUNK_MASK + 1];
> + void *delayed_chunks_set[(MALLOC_DELAYED_CHUNK_MASK + 1) * 4];
>   size_t rbytesused;  /* random bytes used */
>   char *func; /* current function */
>   int mutex;
> @@ -292,6 +293,22 @@ hash(void *p)
>   return sum;
>  }
>  
> +static inline size_t
> +hash_chunk(void *p)
> +{
> + size_t sum;
> + uintptr_t u;
> +
> + u = (uintptr_t)p >> MALLOC_MINSHIFT;
> + sum = u;
> + sum = (sum << 7) - sum + (u >> 16);
> +#ifdef __LP64__
> + sum = (sum << 7) - sum + (u >> 32);
> + sum = (sum << 7) - sum + (u >> 48);
> +#endif
> + return sum;
> +}
> +
>  static inline
>  struct dir_info *getpool(void)
>  {
> @@ -983,6 +1000,56 @@ delete(struct dir_info *d, struct region_info *ri)
>   }
>  }
>  
> +void delayed_chunks_insert(struct dir_info *d, void *p)
> +{
> + size_t index;
> + size_t mask = sizeof(d->delayed_chunks_set) / sizeof(void *) - 1;
> + void *q;
> +
> + index = hash_chunk(p) & mask;
> + q = d->delayed_chunks_set[index];
> + while (q != NULL) {
> + if (p == q)
> + wrterror(d, "double free", p);
> + index = (index - 1) & mask;
> + q = d->delayed_chunks_set[index];
> + }
> + d->delayed_chunks_set[index] = p;
> +}
> +
> +void delayed_chunks_delete(struct dir_info *d, void *p)
> +{
> + size_t mask = sizeof(d->delayed_chunks_set) / sizeof(void *) - 1;
> + size_t i, j, r;
> + void *q;
> +
> + i = hash_chunk(p) & mask;
> + q = d->delayed_chunks_set[i];
> + while (q != p) {
> + if (q == NULL)
> + wrterror(d, "pointer missing from address tracking 
> table", p);
> + i = (i - 1) & mask;
> + q = d->delayed_chunks_set[i];
> + }
> +
> + for (;;) {
> + d->delayed_chunks_set[i] = NULL;
> + j = i;
> + for (;;) {
> + i = (i - 1) & mask;
> + if (d->delayed_chunks_set[i] == NULL)
> + return;
> + r = hash_chunk(d->delayed_chunks_set[i]) & mask;
> + if ((i <= r && r < j) || (r < j && j < i) ||
> + (j < i && i <= r))
> + continue;
> + d->delayed_chunks_set[j] = d->delayed_chunks_set[i];
> + break;
> + }
> + }
> +}
> +
> +
>  /*
>   * Allocate a page of chunks
>   */
> @@ -1474,11 +1541,21 @@ ofree(struct dir_info *argpool, void *p)
>   if (!mopts.malloc_freenow) {
>   if (find_chunknum(pool, r, p) == (uint32_t)-1)
>   goto done;
> +
> + if (p == NULL)
> + goto done;
> +
> + delayed_chunks_insert(pool, p);
> +
>   i = getrbyte(pool) & MALLOC_DELAYED_CHUNK_MASK;
>   tmp = p;
>   p = pool->delayed_chunks[i];
> - if (tmp == p)
> - wrterror(pool, "double free", p);
> +
> + if 

Re: malloc.c: better double free check

2017-09-23 Thread Theo Buehler
On Sat, Sep 23, 2017 at 02:05:34PM +, Otto Moerbeek wrote:
> On Sat, Sep 23, 2017 at 05:28:57AM -0400, Ted Unangst wrote:
> 
> > Otto Moerbeek wrote:
> > > Hi,
> > > 
> > > Malloc maintains a list if 16 slots of chunks to be freed. On free a
> > > chunk is put in a random slot and the existing chunk in that slot is
> > > actually freed. Currently, the code only checks the slot selected for
> > > a double free.
> > > 
> > > This diff adds code to check all slots. It also removes the option to
> > > disable delayed free. 
> > 
> > I thought we were already doing this, so ok. :)
> 
> And here's the manpage diff.
> 
>   -Otto
> 
> Index: malloc.conf.5
> ===
> RCS file: /cvs/src/share/man/man5/malloc.conf.5,v
> retrieving revision 1.11
> diff -u -p -r1.11 malloc.conf.5
> --- malloc.conf.5 31 Oct 2016 10:07:18 -  1.11
> +++ malloc.conf.5 23 Sep 2017 14:04:14 -
> @@ -56,18 +56,11 @@ at exit.
>  This option requires the library to have been compiled with -DMALLOC_STATS in
>  order to have any effect.
>  .It Cm F
> -.Dq Freeguard .
> -Enable use after free detection.
> +.Dq Freecheck .
> +Enable more extenisve double free and use after free detection.

with
s/extenisve/extensive

ok tb (as is the .c diff)

> +All chunks in the delayed free list will be checked for double frees.
>  Unused pages on the freelist are read and write protected to
>  cause a segmentation fault upon access.
> -This will also switch off the delayed freeing of chunks,
> -reducing random behaviour but detecting double
> -.Xr free 3
> -calls as early as possible.
> -This option is intended for debugging rather than improved security
> -(use the
> -.Cm U
> -option for security).
>  .It Cm G
>  .Dq Guard .
>  Enable guard pages.
> 



Re: malloc.c: better double free check

2017-09-23 Thread Otto Moerbeek
On Sat, Sep 23, 2017 at 05:28:57AM -0400, Ted Unangst wrote:

> Otto Moerbeek wrote:
> > Hi,
> > 
> > Malloc maintains a list if 16 slots of chunks to be freed. On free a
> > chunk is put in a random slot and the existing chunk in that slot is
> > actually freed. Currently, the code only checks the slot selected for
> > a double free.
> > 
> > This diff adds code to check all slots. It also removes the option to
> > disable delayed free. 
> 
> I thought we were already doing this, so ok. :)

And here's the manpage diff.

-Otto

Index: malloc.conf.5
===
RCS file: /cvs/src/share/man/man5/malloc.conf.5,v
retrieving revision 1.11
diff -u -p -r1.11 malloc.conf.5
--- malloc.conf.5   31 Oct 2016 10:07:18 -  1.11
+++ malloc.conf.5   23 Sep 2017 14:04:14 -
@@ -56,18 +56,11 @@ at exit.
 This option requires the library to have been compiled with -DMALLOC_STATS in
 order to have any effect.
 .It Cm F
-.Dq Freeguard .
-Enable use after free detection.
+.Dq Freecheck .
+Enable more extenisve double free and use after free detection.
+All chunks in the delayed free list will be checked for double frees.
 Unused pages on the freelist are read and write protected to
 cause a segmentation fault upon access.
-This will also switch off the delayed freeing of chunks,
-reducing random behaviour but detecting double
-.Xr free 3
-calls as early as possible.
-This option is intended for debugging rather than improved security
-(use the
-.Cm U
-option for security).
 .It Cm G
 .Dq Guard .
 Enable guard pages.



Re: malloc.c: better double free check

2017-09-23 Thread Daniel Micay
On Sat, 2017-09-23 at 09:32 +0200, Otto Moerbeek wrote:
> On Fri, Sep 22, 2017 at 04:35:39PM -0400, Daniel Micay wrote:
> 
> > A linear search works well for the current small quarantine (16) but
> > won't work
> > well if you ever want to have a larger / configurable quarantine
> > size. It would
> > also be nice to make this fast enough to enable by default.
> > 
> > We (CopperheadOS) use an open addressed hash table for this based on
> > the
> > existing hash table since we use a larger quarantine with a FIFO
> > queue
> > alongside the random array and a configuration size. Ideally the
> > code would be
> > shared with the existing hash table but I didn't want to make it
> > into an
> > invasive change downstream.
> > 
> > These are the three downstream patches for OpenBSD malloc in our
> > copy of Bionic
> > (Android libc), so I'd need to port them to the current upstream
> > code to apply
> > cleanly. They're currently applied after other changes and it's a
> > slightly
> > older copy of the base code (after multi-pool support, but before
> > the canary
> > rework since we'll need to adapt that to our needs). Can get the
> > general idea
> > from the patches even though they're not going to apply cleanly
> > though.
> > 
> > [1] quarantine double-free detection via hash table
> 
> Thanks for sharing this, I'll take a look soon. 
> 
> Thinking a bit about this: wouldn't a closed hash table be sufficient?
> A collision would then either be a double free, otherwise just replace
> old with new. You'll get a O(1) lookup and insert and simpler code.

I wouldn't really want to have a random chance of missing a double-free
even if the chance is small though.

It's a copy of the hash table used to track regions with minor tweaks so
it'd be possible to make the existing code able to handle both but it
would mean turning it into macros. I'm not sure which is the lesser evil
for just 2 uses of a fairly simple data structure.



Re: [patch] ftp(1): change mtime for http/https links

2017-09-23 Thread Jesper Wallin
> On Sat, Sep 23, 2017 at 09:43:12AM +0200, Jesper Wallin wrote:
> Yeah, fully understandable.  I'll bump this once 6.2 is out.
> 
> I'll apply the changes Philip suggested (thanks!) and then build a
> release to verify that everything works.
> 
>
Woups, seems like I managed to break ftp(1) in the installer due to
pledge being a bit too tight.  Here is an updated version of the patch
and with Philips changes as well.


Index: fetch.c
===
RCS file: /cvs/src/usr.bin/ftp/fetch.c,v
retrieving revision 1.163
diff -u -p -r1.163 fetch.c
--- fetch.c 7 Mar 2017 08:00:23 -   1.163
+++ fetch.c 23 Sep 2017 21:28:49 -
@@ -210,6 +210,7 @@ url_get(const char *origline, const char
int status;
int save_errno;
const size_t buflen = 128 * 1024;
+   time_t mtime = -1;
 
direction = "received";
 
@@ -647,7 +648,7 @@ noslash:
if (pledge("stdio rpath inet dns tty",  NULL) == -1)
err(1, "pledge");
} else {
-   if (pledge("stdio rpath wpath cpath inet dns tty", 
NULL) == -1)
+   if (pledge("stdio rpath wpath cpath fattr inet dns 
tty", NULL) == -1)
err(1, "pledge");
}
}
@@ -860,6 +861,12 @@ noslash:
if (restart_point)
filesize += restart_point;
 #endif /* !SMALL */
+#define LASTMOD "Last-Modified: "
+   } else if (strncasecmp(cp, LASTMOD, sizeof(LASTMOD) - 1) == 0) {
+   struct tm tm;
+   cp += sizeof(LASTMOD) - 1;
+   if (strptime(cp, "%a, %d %b %Y %T %z", ) != NULL)
+   mtime = mktime();
 #define LOCATION "Location: "
} else if (isredirect &&
strncasecmp(cp, LOCATION, sizeof(LOCATION) - 1) == 0) {
@@ -1043,8 +1050,21 @@ cleanup_url_get:
fclose(fin);
else if (s != -1)
close(s);
-   if (out >= 0 && out != fileno(stdout))
+   if (out >= 0 && out != fileno(stdout)) {
+
+   if (mtime != -1) {
+   struct timespec tv[2];
+   tv[0].tv_nsec = UTIME_NOW;
+   tv[1].tv_sec = mtime;
+   tv[1].tv_nsec = 0;
+   if (futimens(out, tv) == -1)
+   fprintf(ttyout,
+   "Can't change modification time on %s to %s\n",
+   savefile, ctime());
+   }
+
close(out);
+   }
free(buf);
free(proxyhost);
free(proxyurl);
Index: ftp.c
===
RCS file: /cvs/src/usr.bin/ftp/ftp.c,v
retrieving revision 1.100
diff -u -p -r1.100 ftp.c
--- ftp.c   22 Aug 2016 16:27:00 -  1.100
+++ ftp.c   23 Sep 2017 21:28:49 -
@@ -1217,8 +1217,8 @@ break2:
ut.modtime = mtime;
if (utime(local, ) == -1)
fprintf(ttyout,
-   "Can't change modification time on %s to %s",
-   local, asctime(localtime()));
+   "Can't change modification time on %s to %s\n",
+   local, ctime());
}
}
}



Re: USB KVM switch under Xorg spams read IO errors on detach (filling up /var)

2017-09-23 Thread Aaron Fineman
Moving bugs@ and Matthieu to BCC, addings tech@.

Since no one else has fixed this yet, I did. This bug is a combination
or two things. 1.) When a wsmouse goes away on a KVM, it becomes
detached, but not disconnected, and 2.) some mice still have things to
be read (or think they do) when they're detached. Wskbd does the right
thing here, and disconnects from wsdisplay when the keyboard detached.
>From the code, it looks like wsmux also does the right thing. However,
the wskbd disconnect mechanism is tied to the console/console keyboard
mechanism. Having a console mouse as a concept does not make much sense
(except moused?), however this was the easiest code path to hook into.

Problems I need to solve:
1.) Why does my mouse not attach to a wsmux? My dmesg is currently full
of garbage, how can I get a clean dmesg (other than rebooting). Also,
how do I debug why my mouse isn't attaching to a wsmux appropriately?
>From reading the wscons code, it seems like this would be the best
solution to my problem, and remove the need for this patch.
2.) What is the proper codepath to hook into during the ums detach to
trigger the disconnect? I wasn't having luck figuring out the right
place to skip faking a console mouse. Can someone with experience in the
usb/wscons stack chime in here? 
3.) The mouse ends up starting disconnected with this patch, and needs a
KVM toggle back and forth to get a connect triggered on top of an
attach. What did I mess up while attaching here?

Diff linked and inlined: http://ix.io/A2u
---

Index: sys/dev/hid/hidms.c
===
RCS file: /cvs/src/sys/dev/hid/hidms.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 hidms.c
--- sys/dev/hid/hidms.c 22 May 2016 22:06:11 -  1.3
+++ sys/dev/hid/hidms.c 20 Sep 2017 01:49:39 -
@@ -61,6 +61,8 @@ int   hidmsdebug = 0;
 #define MOUSE_FLAGS_MASK(HIO_CONST | HIO_RELATIVE)
 #define NOTMOUSE(f) (((f) & MOUSE_FLAGS_MASK) !=
 HIO_RELATIVE)
 
+inthidms_is_console;
+
 int
 hidms_setup(struct device *self, struct hidms *ms, uint32_t quirks,
 int id, void *desc, int dlen)
@@ -259,7 +261,7 @@ hidms_setup(struct device *self, struct 
 }
 
 void
-hidms_attach(struct hidms *ms, const struct wsmouse_accessops *ops)
+hidms_attach(struct hidms *ms, const struct wsmouse_accessops *ops, int
console)
 {
struct wsmousedev_attach_args a;
 #ifdef HIDMS_DEBUG
Index: sys/dev/hid/hidmsvar.h
===
RCS file: /cvs/src/sys/dev/hid/hidmsvar.h,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 hidmsvar.h
--- sys/dev/hid/hidmsvar.h  8 Jan 2016 15:54:13 -   1.1
+++ sys/dev/hid/hidmsvar.h  20 Sep 2017 01:49:39 -
@@ -69,11 +69,13 @@ struct hidms {
struct hid_location sc_loc_w;
struct hid_location sc_loc_btn[MAX_BUTTONS];
 
+   char sc_console_mouse;  /* we are the console mouse */
+
struct tsscale  sc_tsscale;
int sc_rawmode;
 };
 
-void   hidms_attach(struct hidms *, const struct wsmouse_accessops *);
+void   hidms_attach(struct hidms *, const struct wsmouse_accessops *,
int console);
 int hidms_detach(struct hidms *, int);
 voidhidms_disable(struct hidms *);
 int hidms_enable(struct hidms *);
Index: sys/dev/i2c/iatp.c
===
RCS file: /cvs/src/sys/dev/i2c/iatp.c,v
retrieving revision 1.3
diff -u -p -u -p -r1.3 iatp.c
--- sys/dev/i2c/iatp.c  24 Sep 2016 18:32:18 -  1.3
+++ sys/dev/i2c/iatp.c  20 Sep 2017 01:49:39 -
@@ -196,7 +196,7 @@ int iatp_detach(struct device *, int);
 int iatp_activate(struct device *, int);
 
 int iatp_ioctl(void *, u_long, caddr_t, int, struct proc *);
-intiatp_enable(void *);
+intiatp_enable(void *, int);
 voidiatp_disable(void *);
 
 int iatp_read_reg(struct iatp_softc *, uint16_t, size_t, void *);
@@ -319,7 +319,7 @@ iatp_activate(struct device *self, int a
 }
 
 int
-iatp_enable(void *v)
+iatp_enable(void *v, int on /* unused */)
 {
struct iatp_softc *sc = v;
 
Index: sys/dev/i2c/ims.c
===
RCS file: /cvs/src/sys/dev/i2c/ims.c,v
retrieving revision 1.1
diff -u -p -u -p -r1.1 ims.c
--- sys/dev/i2c/ims.c   12 Jan 2016 01:11:15 -  1.1
+++ sys/dev/i2c/ims.c   20 Sep 2017 01:49:39 -
@@ -39,7 +39,7 @@ struct ims_softc {
 
 voidims_intr(struct ihidev *addr, void *ibuf, u_int len);
 
-intims_enable(void *);
+intims_enable(void *, int);
 voidims_disable(void *);
 int ims_ioctl(void *, u_long, caddr_t, int, struct proc *);
 
@@ -110,7 +110,7 @@ ims_attach(struct device *parent, struct
if (hidms_setup(self, ms, 0, iha->reportid, desc, size) != 0)
return;
 
-   hidms_attach(ms, _accessops);
+   hidms_attach(ms, _accessops, 0);
 }
 
 int
@@ -133,7 +133,7 @@ ims_intr(struct ihidev *addr, void