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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
On a debian lenny installation with a kernel that calls itself 2.6.28, I could
repeatably block smbd using splice. According to the output of netstat, the
recvq of the TCP connection was full and at the same time according to strace
smbd was stuck in a splice syscall trying to read from that TCP connection. We
can not protect ourselves from this condition, as nobody will ever notify us
that something is broken. So sadly we can't use splice yet at all. Maybe in
2.6.29...
According to the splice(2) manpage, one of the file descriptors *must* be a
pipe. With this patch I could successfully run splice(2) on a debian lenny
installation.
Jeremy, please check!
The warning:
../librpc/gen_ndr/ndr_spoolss.c: In function ‘ndr_pull_spoolss_EnumPrinterData’:
../librpc/gen_ndr/ndr_spoolss.c:14792: warning: passing argument 1 of ‘memset’ discards qualifiers from pointer target type
In some case the pidl generated code needs to memset a const struct
field. This causes the above warning. This patch discardeds the const
in this case. I'm open to a more elegant fix, but this eliminates the
warning and should be relatively safe.
Without this, we end up adding more than one timed event. In the event handler
print_notify_event_send_messages() only one event will be deleted, all others
will fire indefinitely.
Incrementing the next vuid did not correctly overflow
Now we survive BENCH-SESSSETUP with -o 100000. Takes a while though :-)
Thanks a lot to Ofer Tal <otsmb@shmoop.org> for reporting #5933
Ofer Tal <otsmb@shmoop.org> fully correctly noted that we're incrementing
num_validated_vuids twice per session setup, but decrement it only once.
Looking at sesssetup.c we always call register_initial_vuid() before
register_existing_vuid(), so there's no point in incrementing it in
register_existing_vuid().
Jeremy, please check!
When we don't know how to handle a type for the python bindings,
we should not generate invalid C code.
Jelmer: please fix do the full fix for this.
metze
