Re: Updates to /bin/bash

Re: Updates to /bin/bash

[Mark_H_Johnson.RTS]

On this issue [updates to active files...] how does the typical distribution
update process handle this? For example, if I'm doing a package update using a
typical tool [gnoRPM, kpackage, etc.] what is happening behind the scenes to
prevent disaster? The situation where I've booted from CD-ROM & doing a major
distribution update would be safe doing a simple replacement. OTOH, if I get an
"urgent" patch that I need to apply, must I track down all the jobs that are
currently using the files being updated, get them stopped, do the update, and
then restart them to be "safe"? [and I'll quit doing the "dangerous" updates
that I've been doing through ignorance] If so, is that going to kill the use of
Linux in high availability situations [or must I run redundant systems to work
around this]?

The alternative I've seen in other OS's is to retain the old file "hidden" on
the file system [old inode]. All new references go to the new copy [new inode],
all old references refer to the hidden one [old inode]. When the [old inode]
reference count goes to zero, the hidden one is finally deleted. If the volume
is improperly dismounted [e.g., system crash] prior to the last user getting
done, the fsck done at reboot does the cleanup instead.
--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>


|--------+----------------------->
|        |          Andrea       |
|        |          Arcangeli    |
|        |          <andrea@suse.|
|        |          de>          |
|        |                       |
|        |          05/04/00     |
|        |          01:43 PM     |
|        |                       |
|--------+----------------------->
  >----------------------------------------------------------------------------|
  |                                                                            |
  |       To:     Trond Myklebust <trond.myklebust@fys.uio.no>                 |
  |       cc:     "Juan J. Quintela" <quintela@fi.udc.es>, linux-mm@kvack.org, |
  |       linux-kernel@vger.rutgers.edu, (bcc: Mark H Johnson/RTS/Raytheon/US) |
  |       Subject:     Re: classzone-VM + mapped pages out of lru_cache        |
  >----------------------------------------------------------------------------|



On 4 May 2000, Trond Myklebust wrote:

>Not good. If I'm running /bin/bash, and somebody on the server updates
>/bin/bash, then I don't want to reboot my machine. With the above

If you use rename(2) to update the shell (as you should since `cp` would
corrupt also users that are reading /bin/bash from local fs) then nfs
should get it right also with my patch since it should notice the inode
number changed (the nfs fd handle should get the inode number as cookie),
right?
[snip]




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Updates to /bin/bash

[Matthew Vanecek]

Mark_H_Johnson.RTS@raytheon.com wrote:
> 
> On this issue [updates to active files...] how does the typical distribution
> update process handle this? For example, if I'm doing a package update using a
> typical tool [gnoRPM, kpackage, etc.] what is happening behind the scenes to
> prevent disaster? The situation where I've booted from CD-ROM & doing a major
> distribution update would be safe doing a simple replacement. OTOH, if I get an
> "urgent" patch that I need to apply, must I track down all the jobs that are
> currently using the files being updated, get them stopped, do the update, and
> then restart them to be "safe"? [and I'll quit doing the "dangerous" updates
> that I've been doing through ignorance] If so, is that going to kill the use of
> Linux in high availability situations [or must I run redundant systems to work
> around this]?
> 

Well, the executable is loaded into memory once started.  For the most
part, you can overwrite the executable (or other file) on the disk, as
long as you have permissions to do so.  So, no, you don't have to track
down all the other processes and stop them, in order to replace the file
on disk.  Be careful, though, with things like your libc.  If you
overwrite *that* with an invalid version, you're pretty much screwed,
without a rescue disk set.

Other operating systems, AFAIK, implement an operating-system level
locking mechanism, whereby the OS locks the file and won't let it be
overwritten.  On Linux (and Unix in general, I guess), there are a
couple of different types of lock, and if you have a program which
performs, say, a partial file lock, you cannot be guaranteed that that
lock will be respected--unless and until every application written
implements the same type of locking and also checks to see if a file is
locked before doing something to it.

> On 4 May 2000, Trond Myklebust wrote:
> 
> >Not good. If I'm running /bin/bash, and somebody on the server updates
> >/bin/bash, then I don't want to reboot my machine. With the above
> 

You wouldn't have to reboot.  Why would you think you need to reboot?
This isn't Winbloze, for god's sake.  All it means is that new bash
processes will use the updated version, while old processes would still
be using the old version--it's loaded in memory, remember?  Hell, you
can even overwrite the libc on a running system.

> If you use rename(2) to update the shell (as you should since `cp` would
> corrupt also users that are reading /bin/bash from local fs) then nfs
> should get it right also with my patch since it should notice the inode
> number changed (the nfs fd handle should get the inode number as cookie),
> right?

My understanding of rename(2) is that it only returns EBUSY on
directories, and not on individual files.  BTW, I don't see the message
this was in reference to on lkml--what was your patch?


-- 
Matthew Vanecek
Visit my Website at http://mysite.directlink.net/linuxguy
For answers type: perl -e 'print
$i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
*****************************************************************
For 93 million miles, there is nothing between the sun and my shadow
except me. I'm always getting in the way of something...
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Updates to /bin/bash

[Trond Myklebust]

>>>>> " " == Matthew Vanecek <linuxguy@directlink.net> writes:

    >> On 4 May 2000, Trond Myklebust wrote:
    >>
    >> >Not good. If I'm running /bin/bash, and somebody on the server
    >> >updates /bin/bash, then I don't want to reboot my
    >> >machine. With the above
    >>

     > You wouldn't have to reboot.  Why would you think you need to
     > reboot?  This isn't Winbloze, for god's sake.  All it means is
     > that new bash processes will use the updated version, while old
     > processes would still be using the old version--it's loaded in

NO. This behaviour is exactly what Andreas patch would break. New
processes would get a mixture of old and new versions because the page
cache itself would be out of sync.

     > memory, remember?  Hell, you can even overwrite the libc on a
     > running system.

That is only true of files on local storage. We are discussing NFS,
which is a stateless file system.

Cheers,
  Trond
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Updates to /bin/bash

[Andrea Arcangeli]

On Fri, 5 May 2000, Trond Myklebust wrote:

>NO. This behaviour is exactly what Andreas patch would break. New

My patch won't hurt the bash update as far I can tell.

In clean 2.2.15 and clean 2.3.99-pre7-pre6 you don't unmap the page from
the ptes, so if nfs doesn't keep to do the pageins from the inode pointed
by the nfsfilehandle, then you'll get a mixture anyway even if you drop
the mapped pages from the cache (and nfs probably can't keep do to the
pageins from the old file if somebody replaced bash on the real fs but in
the worst case nfs should notice that and it should abort the `bash`
execution and to never do the silent mixture).

New executed bash are not an issue since they will get a new inode present
on the server and so they won't risk to do the mixture.

All above thoughts assumes the admin correctly uses remove(2) to upgrade
bash (otherwise the mixture would happen also on top of ext2).

About the stability issue I looked some more and maybe the VM is not
subject to stability issues by dropping a mapped cache-page from the cache
(however the thing keeps to look not robust to me). Everything depends on
the page->index that have to be not clobbered after dropping the page from
the cache (while page->index is supposed to have a meaning only on
pagecache or swapcache).

Andrea


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Updates to /bin/bash

[Steve Dodd]

[I don't seem to have the start of this thread..]

On Thu, May 04, 2000 at 07:14:12PM -0500, Matthew Vanecek wrote:

> Well, the executable is loaded into memory once started.  For the most
> part, you can overwrite the executable (or other file) on the disk, as
> long as you have permissions to do so. [..]

Err, no, the executable is paged in and out as required. Updating a running
executable simply means you must make sure to create a *different* inode
for the new version, instead of scribbling over the existing one, i.e.:

cp /mnt/foo/bar /bin/bar.new
rm /bin/bar
mv /bin/bar.new /bin/bar

When the last user of the old version goes away, the inode for it is deleted.
New users see the new version.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

Re: Updates to /bin/bash

[Mark_H_Johnson.RTS]

Just to recap & make sure I have this straight.

 (1) IF I'm dealing with local files & do NOT have the area NFS mounted, then
the typical methods of updating files is OK.

 (2) IF I'm dealing with NFS mounted files, all bets are off. Please confirm
that I should take some action (e.g., remount the volume) to make sure the state
is purged after the updates are made.

I can see that how the second situation works has an impact on diskless (or
small disk) workstations [seems to cause lots of administrative headaches that I
would like to avoid]. I'm in the middle of planning the deployment of a few
clustered systems (head node w/ up to 40 compute nodes) as well as 100-200
workstations for development. If I understand this right, I should spend a
little more money to put bigger disks on each machine & have most of the OS and
tools hosted on each machine. Then use rdist or similar method to keep the
machines updated. Restrict the use of NFS mounting (with appropriate controls)
for the items I just "have to share". [this may also explain why we've had
problems on our currently deployed systems using NFS... Hmm.]

Thanks for the explanations.
--Mark H Johnson
  <mailto:Mark_H_Johnson@raytheon.com>


|--------+---------------------------->
|        |          Trond Myklebust   |
|        |          <trond.myklebust@f|
|        |          ys.uio.no>        |
|        |                            |
|        |          05/05/00 02:14 AM |
|        |          Please respond to |
|        |          trond.myklebust   |
|        |                            |
|--------+---------------------------->
  >----------------------------------------------------------------------------|
  |                                                                            |
  |       To:     Matthew Vanecek <linuxguy@directlink.net>                    |
  |       cc:     linux-kernel@vger.rutgers.edu, linux-mm@kvack.org, (bcc: Mark|
  |       H Johnson/RTS/Raytheon/US)                                           |
  |       Subject:     Re: Updates to /bin/bash                                |
  >----------------------------------------------------------------------------|



>>>>> " " == Matthew Vanecek <linuxguy@directlink.net> writes:

    >> On 4 May 2000, Trond Myklebust wrote:
    >>
    >> >Not good. If I'm running /bin/bash, and somebody on the server
    >> >updates /bin/bash, then I don't want to reboot my
    >> >machine. With the above
    >>

     > You wouldn't have to reboot.  Why would you think you need to
     > reboot?  This isn't Winbloze, for god's sake.  All it means is
     > that new bash processes will use the updated version, while old
     > processes would still be using the old version--it's loaded in

NO. This behaviour is exactly what Andreas patch would break. New
processes would get a mixture of old and new versions because the page
cache itself would be out of sync.

     > memory, remember?  Hell, you can even overwrite the libc on a
     > running system.

That is only true of files on local storage. We are discussing NFS,
which is a stateless file system.

Cheers,
  Trond
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/