IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Found by Michael Hanscho <samba@micha.priv.at> with a WinCE client.
Autobuild-User: Volker Lendecke <vlendec@samba.org>
Autobuild-Date: Fri Jan 14 17:42:05 CET 2011 on sn-devel-104
Since commit 7022554, smbds share a printcap cache (printer_list.tdb),
therefore ordering of events between smbd processes is important when
updating printcap cache information. Consider the following two process
example:
1) smbd1 receives HUP or printcap cache time expiry
2) smbd1 checks whether pcap needs refresh, it does
3) smbd1 marks pcap as refreshed
4) smbd1 forks child1 to obtain cups printer info
5) smbd2 receives HUP or printcap cache time expiry
6) smbd2 checks whether pcap needs refresh, it does not (due to step 3)
7) smbd2 reloads printer shares prior to child1 completion (stale pcap)
8) child1 completion, pcap cache (printer_list.tdb) is updated by smbd1
9) smbd1 reloads printer shares based on new pcap information
In this case both smbd1 and smbd2 are reliant on the pcap update
performed on child1 completion.
The prior commit "reload shares after pcap cache fill" ensures that
smbd1 only reloads printer shares following pcap update, however smbd2
continues to present shares based on stale pcap data.
This commit addresses the above problem by driving pcap cache and
printer share updates from the parent smbd process.
1) smbd0 (parent) receives a HUP or printcap cache time expiry
2) smbd0 forks child0 to obtain cups printer info
3) child0 completion, pcap cache (printer_list.tdb) is updated by smbd0
4) smbd0 reloads printer shares
5) smbd0 notifies child smbds of pcap update via message_send_all()
6) child smbds read fresh pcap data and reload printer shares
This architecture has the additional advantage that only a single
process (the parent smbd) requests printer information from the printcap
backend.
Use time_mono in housekeeping functions As suggested by Björn Jacke.
Since commit eada8f8a, updates to the cups pcap cache are performed
asynchronously - cups_cache_reload() forks a child process to request
cups printer information and notify the parent smbd on completion.
Currently printer shares are reloaded immediately following the call to
cups_cache_reload(), this occurs prior to smbd receiving new cups pcap
information from the child process. Such behaviour can result in stale
print shares as outlined in bug 7836.
This fix ensures print shares are only reloaded after new pcap data has
been received.
Pair-Programmed-With: Lars Müller <lars@samba.org>
pass this in as the &now parameter. Push this call inside of
event_add_to_select_args() to the correct point so it doesn't
get called unless needed.
Jeremy.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Thu Dec 23 01:08:11 CET 2010 on sn-devel-104
This fixes a crash in the echo responder when the client started to send the
NetBIOS-Level 0x85-style keepalive packets. We did not correctly check the
packet length, so the code writing the signing seqnum overwrote memory after
the malloc'ed area for the 4 byte keepalive packet.
Autobuild-User: Jeremy Allison <jra@samba.org>
Autobuild-Date: Thu Oct 7 19:47:35 UTC 2010 on sn-devel-104
Without this, we can get a writable pipe end, but the writev call on the pipe
will block.
Autobuild-User: Volker Lendecke <vlendec@samba.org>
Autobuild-Date: Wed Oct 6 13:57:30 UTC 2010 on sn-devel-104
Previously, only one fd handler was being called per main message loop
in all smbd child processes.
In the case where multiple fds are available for reading the fd
corresponding to the event closest to the beginning of the event list
would be run. Obviously this is arbitrary and could cause unfairness.
Usually, the first event fd is the network socket, meaning heavy load
of client requests can starve out other fd events such as oplock
or notify upcalls from the kernel.
In this patch, I have changed the behavior of run_events() to unset
any fd that it has already called a handler function, as well
as decrement the number of fds that were returned from select().
This allows the caller of run_events() to iterate it, until all
available fds have been handled.
I then changed the main loop in smbd child processes to iterate
run_events(). This way, all available fds are handled on each wake
of select, while still checking for timed or signalled events between
each handler function call. I also added an explicit check for
EINTR from select(), which previously was masked by the fact that
run_events() would handle any signal event before the return code
was checked.
This required a signature change to run_events() but all other callers
should have no change in their behavior. I also fixed a bug in
run_events() where it could be called with a selrtn value of -1,
doing unecessary looping through the fd_event list when no fds were
available.
Also, remove the temporary echo handler hack, as all fds should be
treated fairly now.
If select returns -1, we can't rely on the fd sets. The current code might loop
endlessly because when putting an invalid fd (the closed socket?) on the read
set, a select implementation might choose not to touch it but directly return
with EINVAL. Thus run_events will see the socket readable, which leads to a
"return true", and thus a NT_STATUS_RETRY -> same game again.
We should never get into this situation, but to me the logfiles given in bug
7518 do not reveal enough information to understand how this can happen.
Found by the CodeNomicon test suites at the SNIA plugfest.
http://www.codenomicon.com/
If an invalid NetBIOS session request is received the code in name_len() in
libsmb/nmblib.c can hit an assert.
Re-write name_len() and name_extract() to use "buf/len" pairs and
always limit reads.
Jeremy.
This completely removes the DEBUG(0, ..) error message from write_data(). I've
gone through all callers of write_data() and made sure that they have their own
equivalent error message printing.
