[SCM] Samba Shared Repository - branch master updated
Jeremy Allison
jra at samba.org
Tue Jan 7 12:36:17 MST 2014
On Tue, Jan 07, 2014 at 12:43:04PM +0100, Stefan Metzmacher wrote:
> The branch, master has been updated
> via 6b586c3 s4:librpc: remove recv_data from transport
> via 9d2557d s4:librpc: factor out xxx_send_request() to dcerpc_send_request()
> via 4459131 s4:librpc: factor out xxx_send_read() to dcerpc_send_read()
> via 9832eb6 s4:librpc: factor out xxx_shutdown_pipe() to dcerpc_shutdown_pipe()
> via 30ca477 s4:librpc: factor out xxx_dead() to dcerpc_transport_dead()
> via 3193c27 s4:librpc: remove server_name from transport
> via 383ba3d s4:librpc: make 'struct dcerpc_pipe_connect' private
> via 27d0d32 s4:librpc: remove unused dcerpc_smb2.c
> via a9bb84c s4:librpc: implement dcerpc_pipe_open_smb2() in dcerpc_smb.c
> via 7352f7f s4:librpc: make use of dcerpc_pipe_open_smb_send/recv for SMB2
> via 45fc961 s4:librpc: pass dcecli_connection instead of dcerpc_pipe to dcerpc_secondary_smb_send()
> via bebc05a s4:librpc: use dcerpc_binding_dup() instead of talloc_reference()
> via a08ee93 s4:librpc: pass smbXcli_{conn,session,tcon} to dcerpc_pipe_open_smb_send()
> via f7b1ff2 s4:librpc: don't talloc_reference smbcli_tree
> via e6474ba s4:librpc: keep smbcli_tree/smb2_tree as talloc child of dcecli_connection
> via d230f73 s4:librpc: use tstream_smbXcli_np in dcerpc_smb.c
> via 2ec65ea s4:librpc: use tstream in dcerpc_sock.c
> via 01ea63e s4:librpc: make it possible for the transport to specify the max_xmit/recv_size
> via 0059929 libcli/smb: s/tstream_cli_np/tstream_smbXcli_np
> via 8ec4163 libcli/smb: s/TSTREAM_CLI_NP/TSTREAM_SMBXCLI_NP
> via 024fc73 libcli/smb: move source3/libsmb/cli_np_tstream.c to tstream_smbXcli_np.c
> via acbd12a s3:libsmb: add a TSTREAM_CLI_NP_DESIRED_ACCESS define as collection of individual flags
> via eb8869a s3:libsmb: add tstream_cli_np_ref as protection to talloc_free(smbXcli_conn)
> via 46d29d4 s3:libsmb: do not use cli_state internally within cli_np_tstream
> via 6ebbce9 s3:libsmb: let cli_np_tstream use smb1cli_readx
> via 68d8aa4 s3:libsmb: let cli_np_tstream use smb1cli_writex
> via c25f19e s3:libsmb: let cli_np_tstream use smb1cli_close
> via a8c6a05 s3:libsmb: let cli_np_tstream use smb1cli_trans
> via 7ebb081 s3:libsmb: let cli_np_tstream use smb1cli_ntcreatex
> via 3d90e93 libcli/smb: add smb1cli_readx*
> via cb295d7 libcli/smb: add smb1cli_writex*
> via b9d19e8 libcli/smb: add smb1cli_close*
> via 50f910f libcli/smb: add smb1cli_ntcreatex*
> via ef28ed6 libcli/smb: move some *TRANSACT_* flags to smb_constants.h
> via 306cba4 libcli/smb: move some FILE_* flags to smb_constants.h
> via 54c0bde midltests: add tests with v1_enum and NDR64
> via 2ba9453 pidl:NDR/Client: avoid useless memcpy()
> via f50b561 pidl:NDR/Client: fix dcerpc_function() with [out,ref] pointers
> via 662fc2d pidl:NDR/Client: simplify tevent_req_nterror() usage
> via 02c34fe pidl:NDR/Client: add missing TALLOC_FREE(subreq) after dcerpc_binding_handle_call_recv()
> via 3a0fa36 pidl:Samba3/ServerNDR: skip DCERPC pipe elements and leave NULL pointers.
> via d821661 s4:librpc/rpc: update alloc_hint for each fragment
> via ce84ade s4:librpc/rpc: remove unused rpc_request->ndr structure
> via cc899e8 s4:rpc_server: don't support functions DCERPC pipes in remoted backend
> via ef568f4 librpc/rpc: read the full header in dcerpc_read_ncacn_packet_next_vector()
> via cd46437 dcerpc.idl: add DCERPC_NCACN_PAYLOAD_OFFSET
> via 4289750 librpc: fix possible memory leak
> via a0f781c s4:librpc: fix memory leaks in dcerpc_request_recv_data()
> via b61f717 s4:librpc: fix memory leak in ncacn_pull()
> via 70d8ac6 librpc/ndrdump: free some temporary memory while parsing dcerpc pipe chunks
> via 4cc3388 s4:pyrpc: fix talloc hierachie in dcerpc_InterfaceObject
> via 13ccc5b s4:torture:spoolss_win: fix valgrind problem in test_EnumJobs()
> from 0dc30b9 samba_upgradedns: message the user if they need to change smb.conf
Really nice cleanup. Well done !
Only another 185 usages of talloc_reference() to
exterminate and we're free of it :-) :-).
Jeremy.
More information about the samba-technical
mailing list