tcpip.c:264
/* Keep this list sorted */
InsertHeadList(ListEntry, &OutInstance->ListEntry);
This should probably be InsertTailList(), since you want to insert
before the current ListEntry
Am 12.11.2014 12:39, schrieb jgardou(a)svn.reactos.org:
> Author: jgardou
> Date: Wed Nov 12 11:39:13 2014
> New Revision: 65388
>
> URL: http://svn.reactos.org/svn/reactos?rev=65388&view=rev
> Log:
> [TCPIP]
> - Comment out an optimisation which doesn't work.
> Reviews of why would be most appreciated.
>
> Modified:
> branches/tcpip_revolution/drivers/network/tcpip/entities.c
>
> Modified: branches/tcpip_revolution/drivers/network/tcpip/entities.c
> URL: http://svn.reactos.org/svn/reactos/branches/tcpip_revolution/drivers/networ…
> ==============================================================================
> --- branches/tcpip_revolution/drivers/network/tcpip/entities.c [iso-8859-1] (original)
> +++ branches/tcpip_revolution/drivers/network/tcpip/entities.c [iso-8859-1] Wed Nov 12 11:39:13 2014
> @@ -309,9 +309,11 @@
> return STATUS_SUCCESS;
> }
>
> +#if 0
> /* The list is sorted, so we can cut the loop a bit */
> if (ID.tei_instance < Instance->InstanceId.tei_instance)
> break;
> +#endif
>
> ListEntry = ListEntry->Flink;
> }
>
>
>
Let me make a simple arrogant comment:
Don't try to fix hacks that I spent years trying to fix (and failed). They
just can't be fixed :P
Best regards,
Alex Ionescu
On Mon, Nov 10, 2014 at 1:45 AM, <pschweitzer(a)svn.reactos.org> wrote:
> Author: pschweitzer
> Date: Mon Nov 10 09:45:43 2014
> New Revision: 65352
>
> URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev
> Log:
> [NTOSKRNL]
> So... Because actual ReactOS mood is to worship hacks instead of looking
> for proper fixes to have decent behavior: reenable the IopParseDevice hack.
>
> But, so far, only reenable it for the 1st stage: the most intensive
> storage stack stage (unless you start playing with partitions & formating
> in 3rd stage).
>
> CORE-8732 #resolve #comment Bug is now properly hidden with r65352
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/file.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c
> URL:
> http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r…
>
> ==============================================================================
> --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10
> 09:45:43 2014
> @@ -404,6 +404,27 @@
> /* Check if we can simply use a dummy file */
> UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly));
>
> + /* FIXME: Small hack still exists, have to check why...
> + * This is triggered multiple times by usetup and then once per boot.
> + */
> + if (ExpInTextModeSetup &&
> + !(DirectOpen) &&
> + !(RemainingName->Length) &&
> + !(OpenPacket->RelatedFileObject) &&
> + ((wcsstr(CompleteName->Buffer, L"Harddisk")) ||
> + (wcsstr(CompleteName->Buffer, L"Floppy"))) &&
> + !(UseDummyFile))
> + {
> + DPRINT1("Using IopParseDevice() hack. Requested invalid
> attributes: %lx\n",
> + DesiredAccess & ~(SYNCHRONIZE |
> + FILE_READ_ATTRIBUTES |
> + READ_CONTROL |
> + ACCESS_SYSTEM_SECURITY |
> + WRITE_OWNER |
> + WRITE_DAC));
> + DirectOpen = TRUE;
> + }
> +
> /* Check if this is a direct open */
> if (!(RemainingName->Length) &&
> !(OpenPacket->RelatedFileObject) &&
>
>
>
Hi,
> + if (Sector->BytesPerSector * Sector->SectorsPerCluster > 32 * 1024)
> + {
> + return FALSE;
> + }
FAT supports cluster sizes until 64KB ;-) At least the WinNT series can
work with them.
Best regards,
Michael Fritscher
Thank you for working on this hack (partial) removal!
After all, having it only in the 1st stage is a win over having it
enabled all the time.
Regards,
Aleksey
On 10.11.2014 12:45, pschweitzer(a)svn.reactos.org wrote:
> Author: pschweitzer
> Date: Mon Nov 10 09:45:43 2014
> New Revision: 65352
>
> URL: http://svn.reactos.org/svn/reactos?rev=65352&view=rev
> Log:
> [NTOSKRNL]
> So... Because actual ReactOS mood is to worship hacks instead of looking for proper fixes to have decent behavior: reenable the IopParseDevice hack.
>
> But, so far, only reenable it for the 1st stage: the most intensive storage stack stage (unless you start playing with partitions & formating in 3rd stage).
>
> CORE-8732 #resolve #comment Bug is now properly hidden with r65352
>
> Modified:
> trunk/reactos/ntoskrnl/io/iomgr/file.c
>
> Modified: trunk/reactos/ntoskrnl/io/iomgr/file.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/iomgr/file.c?r…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/iomgr/file.c [iso-8859-1] Mon Nov 10 09:45:43 2014
> @@ -404,6 +404,27 @@
> /* Check if we can simply use a dummy file */
> UseDummyFile = ((OpenPacket->QueryOnly) || (OpenPacket->DeleteOnly));
>
> + /* FIXME: Small hack still exists, have to check why...
> + * This is triggered multiple times by usetup and then once per boot.
> + */
> + if (ExpInTextModeSetup &&
> + !(DirectOpen) &&
> + !(RemainingName->Length) &&
> + !(OpenPacket->RelatedFileObject) &&
> + ((wcsstr(CompleteName->Buffer, L"Harddisk")) ||
> + (wcsstr(CompleteName->Buffer, L"Floppy"))) &&
> + !(UseDummyFile))
> + {
> + DPRINT1("Using IopParseDevice() hack. Requested invalid attributes: %lx\n",
> + DesiredAccess & ~(SYNCHRONIZE |
> + FILE_READ_ATTRIBUTES |
> + READ_CONTROL |
> + ACCESS_SYSTEM_SECURITY |
> + WRITE_OWNER |
> + WRITE_DAC));
> + DirectOpen = TRUE;
> + }
> +
> /* Check if this is a direct open */
> if (!(RemainingName->Length) &&
> !(OpenPacket->RelatedFileObject) &&
>
>
You add parentheses to conform to coding style (our coding style
guidelines do not require it) and on the other hand you convert a 2 line
if statement into one line, which does not conform to our coding style?
Am 09.11.2014 03:26, schrieb hbelusca(a)svn.reactos.org:
> Author: hbelusca
> Date: Sun Nov 9 02:26:49 2014
> New Revision: 65337
>
> URL: http://svn.reactos.org/svn/reactos?rev=65337&view=rev
> Log:
> [NTOS:PNPMGR]
> - Remove an unneeded ExFreePool(DeviceInstance.Buffer); call in IopGetInterfaceDeviceList because at this point DeviceInstance is not yet initialized. Fixes MSVC build.
> - No need to check for DeviceInstance.Buffer being NULL or not (in IopDeviceStatus), because in case it was NULL the IopCaptureUnicodeString call already failed.
> - Add some brackets to conform to code style.
>
> Modified:
> trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c
>
> Modified: trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/io/pnpmgr/plugpla…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/io/pnpmgr/plugplay.c [iso-8859-1] Sun Nov 9 02:26:49 2014
> @@ -199,8 +199,7 @@
> }
> _SEH2_EXCEPT(EXCEPTION_EXECUTE_HANDLER)
> {
> - if (Name.Buffer)
> - ExFreePool(Name.Buffer);
> + if (Name.Buffer) ExFreePool(Name.Buffer);
> Status = _SEH2_GetExceptionCode();
> }
> _SEH2_END;
>
Am 09.11.2014 02:46, schrieb hbelusca(a)svn.reactos.org:
> Author: hbelusca
> Date: Sun Nov 9 01:46:31 2014
> New Revision: 65336
>
> URL: http://svn.reactos.org/svn/reactos?rev=65336&view=rev
> Log:
> [NTVDM]: Use variable-length buffers in DisplayMessage, in case we display a very long message (uses the _vscwprintf CRT function, not available on Win2k. You need to recompile NTVDM with WIN2K_COMPLIANT define if you want to be able to run it on win2k. In that case DisplayMessage uses a quite large enough buffer for its needs). If somebody knows an alternative to _vscwprintf that does the very same job, and which exists on Win2k, I would be happy to use it instead.
Since _vscwprintf will do the whole work already anyway, you could as
well directly print it into the static buffer. You could use _vsnwprintf
or StringCbPrintfW, which internally uses the former, and use the result
to decide whether the buffer was large enough. This will be more
performant, since you only need to print once, when the buffer is large
enough.
Oh... Jérôme, I only just saw that you added this in r65140...
And my change does break the msi tests again. :\
Any idea what's going wrong here?
I'm relatively certain my change is correct because
vfatFCBInitializeCacheFromVolume takes one reference, and VfatCloseFile
invoked via ObDereferenceObject will remove that reference again.
So apparently we're leaking a directory reference somewhere else? :(
Not sure if your previous investigation into this issue can provide any
pointers. Otherwise I'll have to start digging for the leak all over
again...
Thanks.
-Thomas
On 2014-11-05 19:52, tfaber(a)svn.reactos.org wrote:
> --- trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] (original)
> +++ trunk/reactos/drivers/filesystems/fastfat/cleanup.c [iso-8859-1] Wed Nov 5 18:52:11 2014
> @@ -92,7 +92,6 @@
> pFcb->FileObject = NULL;
> CcUninitializeCacheMap(tmpFileObject, NULL, NULL);
> ObDereferenceObject(tmpFileObject);
> - vfatReleaseFCB(IrpContext->DeviceExt, pFcb);
> }
>
> CcPurgeCacheSection(FileObject->SectionObjectPointer, NULL, 0, FALSE);
>
>
Doesn't this change Windows behaviour?
No, luckily it does not change *Windows* behaviour.
It does not even change ReactOS behaviour, but only, because it was
already broken before.
Since MS implemented this function in an arbitrary and hard to
comprehend way, we need to follow this pattern. This means, the function
must not fail on process reference failure, unless certain conditions
are met, otherwise we will fail with the wrong Status code.
To fix the situation, we could remember the fact that the process
couldn't be referenced (possibly by setting Process to NULL) and later
check that after other checks were done. The alternative is referencing
the process individually in each and every case, which will make the
function even more huge and does not really help with it's readability.
Or we can factor our each case and implement it as a separate function.
It would add a lot of code duplication, but might help a bit with
readability and maintainability.
Am 03.11.2014 10:52, schrieb jgardou(a)svn.reactos.org:
> Author: jgardou
> Date: Mon Nov 3 09:52:08 2014
> New Revision: 65210
>
> URL: http://svn.reactos.org/svn/reactos?rev=65210&view=rev
> Log:
> [NTOS/PS]
> - Do not leak a reference to the process object when setting quotas.
>
> Modified:
> trunk/reactos/ntoskrnl/include/internal/ps.h
> trunk/reactos/ntoskrnl/ps/query.c
> trunk/reactos/ntoskrnl/ps/quota.c
>
> Modified: trunk/reactos/ntoskrnl/include/internal/ps.h
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/include/internal/…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/include/internal/ps.h [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/include/internal/ps.h [iso-8859-1] Mon Nov 3 09:52:08 2014
> @@ -303,7 +303,7 @@
> NTSTATUS
> NTAPI
> PspSetQuotaLimits(
> - _In_ HANDLE ProcessHandle,
> + _In_ PEPROCESS Process,
> _In_ ULONG Unused,
> _In_ PVOID QuotaLimits,
> _In_ ULONG QuotaLimitsLength,
>
> Modified: trunk/reactos/ntoskrnl/ps/query.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/query.c?rev=65…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ps/query.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ps/query.c [iso-8859-1] Mon Nov 3 09:52:08 2014
> @@ -1528,6 +1528,7 @@
> /* Validate the number */
> if ((BasePriority > HIGH_PRIORITY) || (BasePriority <= LOW_PRIORITY))
> {
> + ObDereferenceObject(Process);
> return STATUS_INVALID_PARAMETER;
> }
>
> @@ -1918,11 +1919,12 @@
>
> case ProcessQuotaLimits:
>
> - return PspSetQuotaLimits(ProcessHandle,
> + Status = PspSetQuotaLimits(Process,
> 1,
> ProcessInformation,
> ProcessInformationLength,
> PreviousMode);
> + break;
>
> case ProcessWorkingSetWatch:
> DPRINT1("WS watch not implemented\n");
>
> Modified: trunk/reactos/ntoskrnl/ps/quota.c
> URL: http://svn.reactos.org/svn/reactos/trunk/reactos/ntoskrnl/ps/quota.c?rev=65…
> ==============================================================================
> --- trunk/reactos/ntoskrnl/ps/quota.c [iso-8859-1] (original)
> +++ trunk/reactos/ntoskrnl/ps/quota.c [iso-8859-1] Mon Nov 3 09:52:08 2014
> @@ -292,14 +292,13 @@
> NTSTATUS
> NTAPI
> PspSetQuotaLimits(
> - _In_ HANDLE ProcessHandle,
> + _In_ PEPROCESS Process,
> _In_ ULONG Unused,
> _In_ PVOID QuotaLimits,
> _In_ ULONG QuotaLimitsLength,
> _In_ KPROCESSOR_MODE PreviousMode)
> {
> QUOTA_LIMITS_EX CapturedQuotaLimits;
> - PEPROCESS Process;
> PEPROCESS_QUOTA_BLOCK QuotaBlock, OldQuotaBlock;
> BOOLEAN IncreaseOkay;
> KAPC_STATE SavedApcState;
> @@ -368,19 +367,6 @@
> }
> _SEH2_END;
>
> - /* Reference the process */
> - Status = ObReferenceObjectByHandle(ProcessHandle,
> - PROCESS_SET_QUOTA,
> - PsProcessType,
> - PreviousMode,
> - (PVOID*)&Process,
> - NULL);
> - if (!NT_SUCCESS(Status))
> - {
> - DPRINT1("Failed to reference process handle: 0x%lx\n", Status);
> - return Status;
> - }
> -
> /* Check the caller changes the working set size limits */
> if ((CapturedQuotaLimits.MinimumWorkingSetSize != 0) &&
> (CapturedQuotaLimits.MaximumWorkingSetSize != 0))
> @@ -418,7 +404,6 @@
> /* Check if the caller has the required privilege */
> if (!SeSinglePrivilegeCheck(SeIncreaseQuotaPrivilege, PreviousMode))
> {
> - ObDereferenceObject(Process);
> return STATUS_PRIVILEGE_NOT_HELD;
> }
>
> @@ -460,8 +445,6 @@
> Status = STATUS_SUCCESS;
> }
>
> - /* Dereference the process and return the status */
> - ObDereferenceObject(Process);
> return Status;
> }
>
>
>
>